A system and method for maintaining the history and settings of distributed media content.

Abstract

The history and preferences of decentralized media content can be stored and maintained by a media playback system that includes one or more blockchain-enabled playback devices. Content record sets (such as content experience record sets and content network record sets) can be stored via a decentralized ledger and updated, at least partially, based on media consumption events performed or detected by playback devices, service providers, or other participants. Access to such decentralized data can also facilitate the playback of media content for specific users, devices, homes, or environments.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This international application claims the benefit of U.S. Provisional Patent Application No. 63 / 589,762, filed on October 12, 2023, and U.S. Provisional Patent Application No. 63 / 516,343, filed on July 28, 2023, and the entire contents of each of these applications are hereby incorporated by reference in their entirety for all purposes.

[0002] This disclosure relates to consumer products, and more particularly, to methods, systems, products, features, services, and other elements directed to media playback, and to some aspects thereof.

Background Art

[0003] Until 2002, when Sonos, Inc. began developing a new type of playback system, options for accessing and listening to digital audio in an out-of-the-way setting were limited. Sonos filed one of its first patent applications in 2003, titled "Method for Synchronizing Audio Playback between Multiple Networked Devices," and began selling its first media playback system in 2005. The Sonos Wireless Home Sound System allows people to experience music from multiple sources via one or more networked playback devices. Through a software control application installed on a controller (e.g., smartphone, tablet, computer, voice input device), people can play their desired music in any room equipped with a networked playback device. Media content (e.g., songs, podcasts, video sound) is streamed to the playback device, allowing different media content to be played in each room equipped with a playback device. It's also possible to group multiple rooms for synchronized playback of the same media content, and / or to listen to the same media content synchronized in all rooms.

[0004] The features, aspects, and advantages of the technology disclosed herein can be better understood by referring to the following description, the appended claims, and the appended drawings, as set forth below. Those skilled in the art will understand that the features shown in the drawings are for illustrative purposes only and that variations are possible, including different features and / or additional features and their arrangement. [Brief explanation of the drawing]

[0005] [Figure 1A] This is a partial cross-sectional view of an environment including a media playback system configured according to the disclosed aspects of the technology. [Figure 1B]Figure 1A is a schematic diagram of the media playback system and one or more network components. [Figure 1C] This is a block diagram of the playback device. [Figure 1D] This is a block diagram of the playback device. [Figure 1E] This is a block diagram of a combined regeneration device. [Figure 1F] This is a block diagram of a network microphone device. [Figure 1G] This is a block diagram of the playback device. [Figure 1H] This is a schematic diagram of the control device. [Figure 1I] This is a schematic diagram of the corresponding media playback system zone. [Figure 1J] This is a schematic diagram of the corresponding media playback system zone. [Figure 1K] This is a schematic diagram of the corresponding media playback system zone. [Figure 1L] This is a schematic diagram of the corresponding media playback system zone. [Figure 1M] This is a schematic diagram of the media playback system area. [Figure 2] This is a schematic diagram of a media playback system including one or more distributed ledgers according to the disclosed aspects of the technology. [Figure 3] This figure shows an example of a content experience record set according to the technology of this disclosure. [Figure 4] This figure shows an example of a content network record set according to an aspect of the technology disclosed herein. [Figure 5] This is a schematic diagram illustrating the interaction of a media playback system including a distributed ledger according to an aspect of the technology of this disclosure. [Figure 6] This flowchart illustrates an example of a method for accessing and updating content record data via a distributed ledger according to the technology of this disclosure. [Figure 7] This flowchart illustrates an example of a method for accessing and updating content record data via a distributed ledger according to the technology of this disclosure. [Figure 8] This flowchart illustrates an example of a method for accessing and updating content record data via a distributed ledger according to the technology of this disclosure. [Figure 9] This flowchart illustrates an example of a method for accessing and updating content record data via a distributed ledger according to the technology of this disclosure. [Figure 10] This is a schematic diagram illustrating a blockchain-enabled playback device comprising a generating media component, a generating context, and a control component according to an aspect of the technology of this disclosure. [Figure 11] This is a functional block diagram illustrating the methods of creating and playing back generated media according to the technology of this disclosure. [Figure 12] This is a schematic diagram showing an embodiment of a positioning system architecture according to the technology of this disclosure. [Figure 13] This block diagram shows an example of a system including a personalization service according to the technology of this disclosure. [Figure 14] This flowchart illustrates an example of a method related to a blockchain-enabled playback device that includes a generated media component and / or a generated context and control component. [Figure 15] This flowchart illustrates an example of a method related to a blockchain-enabled playback device that includes a generated media component and / or a generated context and control component. [Figure 16] This flowchart illustrates an example of a method related to a blockchain-enabled playback device that includes a generated media component and / or a generated context and control component. [Figure 17] This flowchart illustrates an example of a method related to a blockchain-enabled playback device that includes a generated media component and / or a generated context and control component.

[0006] The drawings are intended to illustrate some examples of the present technology, but those skilled in the art will understand that the technology disclosed in this specification is not limited to the arrangements and means shown in the drawings.

Mode for Carrying Out the Invention

[0007] I. Overview Current approaches for maintaining user data related to media content consumption rely on a centralized data storage where the user data is substantially confined to the service or platform on which the content was originally consumed. Additionally, in some examples, the user data is restricted in its availability to the user in any form or is not accessible at all and remains within the corresponding platform or service only. As a result, data reflecting the history and preferences of content consumption is maintained in an application layer controlled by entities other than the user, substantially creating a "walled garden" and increasing the user's switching costs between applications. For practical purposes, user data often cannot be carried or used in other ways outside the limited scope of a given application itself.

[0008] The emergence of trustless, decentralized networks unlocks the potential for content discovery, curation, and consumption in a way that is not constrained by the limitations imposed by traditional content providers and platforms. For example, the systems and methods described herein provide a decentralized maintenance of users' media content history and preferences. By leveraging decentralized data storage, user access and control can be prioritized, and data can be aggregated across a wide range of devices, services, and environments to gain a comprehensive view of a particular user's content consumption history and preferences. This approach allows users to regain control of their own content history and preference data. Furthermore, by empowering users in this way, service providers can offer features and experiences that are constantly expanding and improving.

[0009] In various examples of the present technology, a blockchain integrated network device (e.g., a playback device) is configured to enable communication with one or more distributed ledgers (e.g., Bitcoin, Ethereum, or other blockchains) to access, store, and update a record set associated with a particular user, device, or environment. For example, content data associated with a particular user can be stored via a distributed ledger that is openly accessible to any user or network participant. The content data can include, for example, a content experience record set (CERS) that includes a history of content consumption events and related data. Additionally or alternatively, the content data can include a content network record set (CNRS) that includes data regarding devices, platforms, content services, etc. that form the overall ecosystem of the user's content consumption. In operation, one or both of these record sets (or any other auxiliary record set having different data) can be stored via the distributed ledger. Further, a user can be given the right to access and / or modify their data in a permissionless manner. In various implementations, access to the data may be restricted in a way that requires the user's permission, for example, enabling the user to disclose only a subset of the data to a particular entity.

[0010] In addition to allowing direct access by users, various other entities may also be granted access to user data stored via distributed ledgers. For example, a user might want to grant a specific media service provider access to their CERS data, thereby enabling the automatic generation of playlists based on their aggregated listening history. As will be discussed in more detail below, using one or more distributed ledgers to maintain user data on media content consumption history and preferences enables a variety of applications that would otherwise be impossible or unattainable. Furthermore, blockchain-integrated playback devices in particular can beneficially enable users to leverage the advantages of distributed storage of their user data by providing a simple and streamlined interface for managing their own data.

[0011] In various examples of this technology, blockchain-enabled playback devices also include hardware and / or software that enables the device to engage in various tasks involving artificial intelligence and / or generative artificial intelligence, such as generative media components and / or generative context and control components. The combination of these functions enables, for example, (a) multiple types of artificial intelligence capabilities and / or (b) unique and personalized media experiences that leverage both distributed ledger technology and advanced generative artificial intelligence technologies.

[0012] As described above, blockchain-enabled playback devices can interact with one or more distributed ledgers, such as public blockchains (e.g., Bitcoin, Ethereum) or other suitable distributed data structures. This blockchain integration enables secure, transparent, and user-controlled management of media consumption history and preferences across various platforms and services. Integrating a generated media component into such a blockchain-enabled playback device further enhances its capabilities. A generated media component, which may include one or more generated media modules, is configured to generate novel synthetic media content based on various inputs and algorithms. This may include, for example, the creation of original audio streams, the modification of existing audio content, or the generation of accompanying visual or haptic outputs, as well as other examples known and / or to be developed in the future. By leveraging data stored in a distributed ledger as input to the generation process, playback devices can create highly personalized and context-aware media experiences. Additionally or alternatively, the output of the generated media module may be written to a distributed ledger.

[0013] Additionally or alternatively, the integration of generation context and control components enables blockchain-enabled playback devices to dynamically adapt their behavior based on a wide range of inputs. These components could include, for example, positioning system applications that determine the relative location of a device within an environment, or personalization services that learn and predict user preferences over time. By combining these capabilities with data and generation media components stored on the blockchain, playback devices can offer improved customization and responsiveness in media playback, as well as improved curation, conditioning, and / or sharing of information among playback devices and / or across playback device networks used to enable such experiences.

[0014] The combination of blockchain functionality, generated media components, and generated context and control components offers clear benefits to users and other participants in the media ecosystem. Users can enjoy dynamically created content that not only reflects their personal preferences and history (recorded and shared via the blockchain) but also adapts in real time to the current context and environment. This combination of technologies enables a more immersive, personalized, and interactive media experience that can evolve and improve over time as technologies, including those involving artificial intelligence, continue to advance.

[0015] Some examples described herein may refer to functions performed by given actors such as “user,” “listener,” and / or other entities, but it should be understood that these are for illustrative purposes only. The claims should not be construed as requiring any action by such exemplary actors unless expressly required by the terminology of the claims themselves.

[0016] In the figures, the same reference number identifies elements that are generally similar and / or identical. To facilitate the description of any particular element, the most important digit or number of digits of the reference number refer to the figure in which the element is first introduced. For example, element 110a is first introduced and described with reference to Figure 1A. Many of the details, dimensions, angles, and other features shown in the figures are merely examples illustrating specific examples of the disclosed art. Other examples may have different details, dimensions, angles, and features without departing from the spirit or scope of this disclosure. Furthermore, those skilled in the art will understand that further examples of the various disclosed arts are implementable without relying on some of the details described below.

[0017] II. Preferred Operating Environment Figure 1A is a partial cross-sectional view of a media playback system 100 placed in an environment 101 (e.g., a house). The media playback system 100 comprises one or more playback devices 110 (individually identified as playback devices 110a-n), one or more network microphone devices ("NMDs") 120 (individually identified as NMDs 120a-c), and one or more control devices 130 (individually identified as control devices 130a, 130b).

[0018] As used herein, the term “playback device” can generally refer to a network device configured to receive, process, and / or output data from a media playback system. For example, a playback device may be a network device configured to receive and process audio content. In some examples, a playback device includes one or more transducers or speakers powered by one or more amplifiers. However, in other examples, a playback device includes either (or neither) speakers or amplifiers. For example, a playback device may include one or more amplifiers configured to drive one or more speakers located outside the playback device via corresponding wires or cables.

[0019] Furthermore, as used herein, the term NMD (i.e., “Network Microphone Device”) can generally refer to a network device configured for audio detection. In some examples, the NMD is a standalone device configured primarily for audio detection. In other examples, the NMD is integrated into a playback device (or vice versa).

[0020] The term "control device" can generally refer to a network device configured to perform functions relevant to facilitating user access, control, and / or configuration of the media playback system 100.

[0021] Each playback device 110 is configured to receive audio signals or data from one or more media sources (e.g., one or more remote servers, or one or more local devices) and to play the received audio signals or data as sound. One or more NMDs 120 are configured to receive spoken word commands, and one or more control devices 130 are configured to receive user input. In response to received spoken word commands and / or user input, the media playback system 100 can play audio through one or more of the playback devices 110. In certain examples, the playback devices 110 are configured to start playing media content in response to a trigger. For example, one or more of the playback devices 110 may be configured to play a morning playlist when relevant trigger conditions (e.g., the presence of a user in the kitchen, detection of operation of a coffee machine) are detected. In some examples, the media playback system 100 is configured to play audio from the first playback device (e.g., playback device 110a) in synchronization with a second playback device (e.g., playback device 110b). The interactions between the playback device 110, NMD 120, and / or control device 130 of the media playback system 100 configured according to various examples of this disclosure will be described in more detail below with reference to Figures 1B to 1H.

[0022] In the example shown in Figure 1A, environment 101 consists of a home having multiple rooms, spaces, and / or playback zones, including (clockwise from top left) a master bathroom 101a, master bedroom 101b, second bedroom 101c, family room or den 101d, office 101e, living room 101f, dining room 101g, kitchen 101h, and outdoor patio 101i. Specific examples and illustrations are described below in the context of a home environment, but the technologies described herein may be implemented in other types of environments. In some examples, for example, the media playback system 100 may be implemented in one or more commercial establishments (e.g., restaurants, malls, airports, hotels, retail stores or other shops), one or more vehicles (e.g., sports utility vehicles, buses, automobiles, ships, boats, airplanes), multiple environments (e.g., a combination of a home environment and a vehicle environment), and / or another suitable environment where multi-zone audio may be desirable.

[0023] The media playback system 100 can consist of one or more playback zones, some of which may correspond to rooms in the environment 101. The media playback system 100 may be established with one or more playback zones, and additional zones may be added or removed thereafter to establish the configuration shown, for example, in Figure 1A. Each zone may be given a name corresponding to a different room or space, such as office 101e, master bathroom 101a, master bedroom 101b, second bedroom 101c, kitchen 101h, dining room 101g, living room 101f, and / or outdoor patio 101i. In some embodiments, a single playback zone may include multiple rooms or spaces. In certain embodiments, a single room or space may include multiple playback zones.

[0024] In the example shown in Figure 1A, the master bathroom 101a, second bedroom 101c, office 101e, living room 101f, dining room 101g, kitchen 101h, and outdoor patio 101i each include one playback device 110, while the master bedroom 101b and den 101d include multiple playback devices 110. In the master bedroom 101b, playback devices 110l and 110m may be configured to play audio content synchronously, for example, as individual playback devices 110, as a combined playback zone, as an integrated playback device, and / or any combination thereof. Similarly, in the den 101d, playback devices 110h-j may be configured to play audio content synchronously, for example, as individual playback devices 110, as one or more combined playback devices, and / or as one or more integrated playback devices. Additional details regarding combined and integrated playback devices are described below with respect to Figures 1B and 1E.

[0025] In some embodiments, one or more playback zones within environment 101 may each play different audio content. For example, one user may be grilling in patio 101i and listening to hip-hop music being played by playback device 110c, while another user is preparing food in kitchen 101h and listening to classical music being played by playback device 110b. In another example, playback zones may play the same audio content in sync with another playback zone. For example, a user may be in office 101e and listening to the same hip-hop music being played by playback device 110c in patio 101i, while also being played by playback device 110f. In some embodiments, playback devices 110c and 110f play the hip-hop music in sync such that the user perceives the audio content as playing seamlessly (or at least substantially seamlessly) as they move between different playback zones. Further details regarding audio playback between playback devices and / or playback zones can be found, for example, in U.S. Patent No. 8,234,395, entitled “System and method for synchronizing operations among a plurality of independently clocked digital data processing devices,” which is incorporated herein by reference in its entirety.

[0026] a. Suitable media playback system Figure 1B is a schematic diagram of the media playback system 100 and the cloud network 102. For ease of illustration, certain devices of the media playback system 100 and the cloud network 102 are omitted in Figure 1B. One or more communication links 103 (hereinafter referred to as "link 103") are provided to connect the media playback system 100 and the cloud network 102.

[0027] Link 103 may comprise, for example, one or more wired networks, one or more wireless networks, one or more wide area networks (WANs), one or more local area networks (LANs), one or more personal area networks (PANs), one or more communication networks (e.g., one or more Global System for Mobiles (GSM) networks, Code Division Multiple Access (CDMA) networks, Long-Term Evolution (LTE) networks, 5G communication networks, and / or other suitable data transmission protocol networks). Cloud network 102 is configured to deliver media content (e.g., audio content, video content, photographs, social media content) to media playback system 100 in response to requests transmitted from media playback system 100 via link 103. In some examples, cloud network 102 is further configured to receive data (e.g., voice input data) from media playback system 100 and, in response, transmit commands and / or media content to media playback system 100.

[0028] The cloud network 102 comprises computing devices 106 (identified individually as a first computing device 106a, a second computing device 106b, and a third computing device 106c). The computing devices 106 may comprise individual computers or servers, such as a media streaming service server for storing audio and / or other media content, an audio service server, a social media server, a media playback system control server, and so on. In some examples, one or more computing devices 106 comprise a single computer or server module. In certain examples, one or more computing devices 106 comprise one or more modules, computers, and / or servers. Furthermore, although the cloud network 102 has been described above in the context of a single cloud network, in some examples, the cloud network 102 comprises multiple cloud networks comprising connected computing devices. Additionally, although Figure 1B shows the cloud network 102 having three computing devices 106, in some examples, the cloud network 102 comprises fewer (or more) computing devices 106.

[0029] The media playback system 100 is configured to receive media content from the network 102 via link 103. The received media content may include, for example, a uniform resource identifier (URI) and / or a uniform resource locator (URL). For example, in some examples, the media playback system 100 can stream, download, or otherwise retrieve data from the URI or URL corresponding to the received media content. The network 104 communicates with link 103 and at least some of the devices of the media playback system 100 (e.g., one or more of the playback device 110, NMD 120, and / or control device 130). The network 104 may include, for example, a wireless network (e.g., a WiFi® network, Bluetooth®, Z-Wave network, ZigBee®, and / or other suitable wireless communication protocol network) and / or a wired network (e.g., a network including Ethernet®, Universal Serial Bus (USB®), and / or other suitable wired communication). As used herein, and as will be understood by those ordinarily skilled in the art, “WiFi®” can refer to several different communication protocols, including, for example, Institute of Electrical and Electronics Modules (IEEE) 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ad, 802.11af, 802.11ah, 802.11ai, 802.11aj, 802.11aq, 802.11ax, 802.11ay, 802.15, etc., which are communication protocols transmitted at 2.4 gigahertz (GHz), 5 GHz, and / or other suitable frequencies.

[0030] In some examples, network 104 comprises a dedicated communications network used by the media playback system 100 to send messages between individual devices and / or to and from media content sources (e.g., one or more computing devices 106). In certain examples, network 104 is configured to be accessible only to devices within the media playback system 100, thereby reducing interference and conflict with other home devices. However, in other examples, network 104 comprises an existing home communications network (e.g., a home Wi-Fi® network). In some examples, link 103 and network 104 comprise one or more identical networks. In some examples, for example, link 103 and network 104 comprise communications networks (e.g., an LTE network, a 5G network). Furthermore, in some embodiments, the media playback system 100 is implemented without network 104, and the devices comprising the media playback system 100 can communicate with each other, for example, via one or more direct connections, PANs, communications networks, and / or other suitable communications links.

[0031] In some examples, audio content sources may be periodically added to or removed from the media playback system 100. In some examples, for instance, the media playback system 100 performs indexing of media items when one or more media content sources are updated, added, and / or removed from the media playback system 100. The media playback system 100 can scan some or all folders and / or directories accessible to the playback device 110 for identifiable media items and generate or update a media content database containing metadata (e.g., title, artist, album, track length) and other relevant information (e.g., URI, URL) for each identifiable media item found. In some examples, for instance, the media content database is stored in one or more of the playback device 110, an NMD (Network Microphone Device) 120, and / or a control device 130.

[0032] In the example shown in Figure 1B, playback devices 110l and 110m constitute group 107a. Playback devices 110l and 110m can be located in different rooms within the home and can be temporarily or permanently grouped into group 107a based on user input received by the control device 130a and / or another control device 130 of the media playback system 100. When placed within group 107a, playback devices 110l and 110m may be configured to play the same or similar audio content synchronously from one or more audio content sources. In certain examples, for example, group 107a includes a coupling zone in which playback devices 110l and 110m constitute the left and right audio channels of multi-channel audio content, respectively, thereby producing or enhancing the stereo effect of the audio content. In some examples, group 107a further includes playback device 110. However, in other examples, the media playback system 100 omits other grouped arrangements of group 107a and / or playback device 110.

[0033] The media playback system 100 includes NMDs 120a and 120d, each having one or more microphones configured to receive voice utterances from a user. In the example shown in Figure 1B, NMD 120a is a standalone device, and NMD 120d is integrated into the playback device 110n. NMD 120a is configured to receive, for example, voice input 121 from user 123. In some examples, NMD 120a transmits data associated with the received voice input 121 to a Voice Assistant Service (VAS) configured to (i) process the received voice input data and (ii) send corresponding commands to the media playback system 100. In some embodiments, for example, the computing device 106c comprises one or more modules and / or servers of a VAS (e.g., a VAS operated by one or more of SONOS®, AMAZON®, GOOGLE®, APPLE®, MICROSOFT®). Computing device 106c can receive audio input data from NMD 120a via network 104 and link 103. In response to receiving the audio input data, computing device 106c processes the audio input data (e.g., "Play Hey Jude by The Beatles") and determines that the processed audio input includes a command to play the song (e.g., "Hey Jude"). Computing device 106c then sends a command to media playback system 100 from an appropriate media service (e.g., via one or more computing devices 106) to play "Hey Jude" by The Beatles on one or more playback devices 110.

[0034] b. Recommended playback device Figure 1C is a block diagram of a playback device 110a having input / output 111. The input / output 111 may include analog I / O 111a (e.g., one or more wires, cables, and / or other suitable communication links configured to transmit analog signals) and / or digital I / O 111b (e.g., one or more wires, cables, or other suitable communication links configured to transmit digital signals). In some embodiments, analog I / O 111a is, for example, an audio line-in input connection that constitutes an auto-detection 3.5mm audio line-in connection. In some examples, digital I / O 111b includes a Sony / Philips Digital Interface Format (S / PDIF) communication interface and / or cable and / or Toshiba Link (TOSLINK) cable. In some examples, digital I / O 111b includes a High-Definition Multimedia Interface (HDMI®) interface and / or cable. In some examples, digital I / O 111b includes one or more wireless communication links, for example, radio frequency (RF), infrared, WiFi®, Bluetooth®, or other suitable communication protocols. In certain examples, analog I / O 111a and digital 111b may not necessarily include cables, but may include interfaces (e.g., ports, plugs, jacks) configured to accept connectors for cables that transmit analog and digital signals, respectively.

[0035] The playback device 110a can receive media content (e.g., audio content consisting of music and / or other sounds) from the local audio source 105 via, for example, an input / output 111 (e.g., a cable, wire, PAN, Bluetooth® connection, ad-hoc wired or wireless communication network, and / or another suitable communication link). The local audio source 105 may comprise, for example, a mobile device (e.g., a smartphone, tablet, laptop computer) or another suitable audio component (e.g., a television, desktop computer, amplifier, phonograph, Blu-ray player, memory for storing digital media files). In some embodiments, the local audio source 105 includes a local music library on a smartphone, computer, network-attached storage (NAS), and / or another suitable device configured to store media files. In certain examples, one or more of the playback device 110, NMD 120, and / or control device 130 include the local audio source 105. However, in other examples, the media playback system completely omits the local audio source 105. In some examples, the playback device 110a does not include input / output 111 and receives all audio content via network 104.

[0036] The playback device 110a further comprises an electronic device 112, a user interface 113 (e.g., one or more buttons, knobs, dials, touch-sensitive surfaces, displays, touchscreens), and one or more transducers 114 (hereinafter referred to as "transducers 114"). The electronic device 112 is configured to receive audio from an audio source (e.g., a local audio source 105) via an input / output 111 and one or more computing devices 106a-106c (Figure 1B) via a network 104, amplify the received audio, and output the amplified audio for playback via one or more transducers 114. In some examples, the playback device 110a optionally includes one or more microphones 115 (e.g., a single microphone, multiple microphones, a microphone array) (hereinafter referred to as "microphones 115"). In a specific example, for instance, a playback device 110a having one or more optional microphones 115 can operate as an NMD configured to receive voice input from a user and perform one or more corresponding operations based on the received voice input.

[0037] In the example shown in Figure 1C, the electronic device 112 comprises one or more processors 112a (hereinafter referred to as "processor 112a"), memory 112b, software components 112c, network interface 112d, one or more audio processing components 112g (hereinafter referred to as "audio processing components 112g"), one or more audio amplifiers 112h (hereinafter referred to as "amplifiers 112h"), and power supply 112i (e.g., one or more power supplies, power cables, power outlets, batteries, induction coils, Power-over Ethernet (PoE) interfaces, and / or other suitable power sources). In some examples, the electronic device 112 optionally includes one or more other components 112j (e.g., one or more sensors, video displays, touchscreens, battery charging bases).

[0038] The processor 112a may include a clock-driven computing component configured to process data, and the memory 112b may include a computer-readable medium (e.g., a tangible, non-temporary computer-readable medium, data storage loaded with one or more software components 112c) configured to store instructions for performing various operations and / or functions. The processor 112a is configured to execute instructions stored in the memory 112b to perform one or more operations. An operation may include, for example, causing a playback device 110a to acquire audio data from an audio source (e.g., one or more of the computing devices 106a-106c (Figure 1B)), and / or another playback device 110a. In some examples, the operation may further include causing a playback device 110a to transmit audio data to another playback device 110a, and / or another device (e.g., one of the NMD 120). In certain examples, the operation further includes causing playback device 110a to pair with one or more other playback devices 110 in order to enable a multi-channel audio environment (e.g., stereo pair, combined zone).

[0039] The processor 112a may be further configured to perform an operation in which the playback device 110a synchronizes the playback of audio content with that of one or more other playback devices 110. As those skilled in the art will understand, during synchronized playback of audio content across multiple playback devices, the listener will preferably not perceive any time delay difference between the playback of audio content by playback device 110a and the playback of audio content by one or more other playback devices 110. Additional details regarding audio playback synchronization between playback devices are described, for example, in U.S. Patent No. 8,234,395, which is incorporated by reference above.

[0040] In some examples, memory 112b is further configured to store data associated with playback device 110a, such as one or more zones and / or zone groups to which playback device 110a is a member, audio sources accessible to playback device 110a, and / or playback queues to which playback device 110a (and / or another of one or more playback devices) is associated. The stored data may include one or more state variables that are updated periodically and used to describe the state of playback device 110a. Memory 112b may also include data associated with the state of one or more other devices of the media playback system 100 (e.g., playback device 110, NMD 120, control device 130). In some embodiments, for example, the state data is shared among at least some of the devices of the media playback system 100 at predetermined time intervals (e.g., every 5 seconds, every 10 seconds, every 60 seconds) so that one or more devices have the most up-to-date data associated with the media playback system 100.

[0041] The network interface 112d is configured to facilitate data transmission between the playback device 110a and one or more other devices on a data network, such as link 103 and / or network 104 (Figure 1B). The network interface 112d is configured to send and receive data corresponding to media content (e.g., audio content, video content, text, photographs) and other signals (e.g., non-transient signals) including digital packet data having Internet Protocol (IP) based source addresses and / or IP-based destination addresses. The network interface 112d can parse the digital packet data so that the electronic device 112 can properly receive and process the data directed to the playback device 110a.

[0042] In the example shown in Figure 1C, the network interface 112d comprises one or more wireless interfaces 112e (hereinafter referred to as "wireless interface 112e"). The wireless interface 112e (e.g., a suitable interface with one or more antennas) may be configured to wirelessly communicate with one or more other devices (e.g., one or more of other playback devices 110, NMD 120, and / or control devices 130) that are connected to the network 104 (Figure 1B) according to a suitable wireless communication protocol (e.g., WiFi®, Bluetooth®, LTE). In some examples, the network interface 112d optionally includes a wired interface 112f (e.g., an interface or receptacle configured to receive network cables such as Ethernet®, USB-A, USB-C, and / or Thunderbolt cables) configured to communicate with other devices via a wired connection according to a suitable wired communication protocol. In certain examples, the network interface 112d includes the wired interface 112f but excludes the wireless interface 112e. In some examples, the electronic device 112 completely excludes the network interface 112d and sends and receives media content and / or other data via a separate communication path (e.g., input / output 111).

[0043] The audio component 112g is configured to process and / or filter data, including media content, received by the electronic device 112 (e.g., via the input / output 111 and / or network interface 112d) to generate an output audio signal. In some examples, the audio processing component 112g includes, for example, one or more digital-to-analog converters (DACs), audio preprocessing components, audio enhancement components, digital signal processors (DSPs), and / or other suitable audio processing components, modules, circuits, etc. In certain examples, one or more of the audio processing components 112g may include one or more subcomponents of the processor 112a. In some examples, the electronic device 112 omits the audio processing component 112g. In some embodiments, for example, the processor 112a executes instructions stored in memory 112b to perform audio processing operations for generating the output audio signal.

[0044] The amplifier 112h is configured to receive and amplify the audio output signal generated by the audio processing component 112g and / or processor 112a. The amplifier 112h may include electronic devices and / or components configured to amplify the audio signal to a level sufficient to drive one or more transducers 114. In some examples, for example, the amplifier 112h includes one or more switching or Class D power amplifiers. However, in other examples, the amplifier includes one or more other types of power amplifiers (e.g., linear gain power amplifiers, Class A amplifiers, Class B amplifiers, Class AB amplifiers, Class C amplifiers, Class D amplifiers, Class E amplifiers, Class F amplifiers, Class G amplifiers and / or Class H amplifiers, and / or other suitable types of power amplifiers). In certain examples, the amplifier 112h includes two or more suitable combinations of the aforementioned types of power amplifiers. Furthermore, in some examples, individual amplifiers 112h correspond to individual transducers 114. However, in other examples, the electronic device 112 includes a single amplifier 112h configured to output the amplified audio signal to multiple transducers 114. In some other examples, the electronic device 112 omits the amplifier 112h.

[0045] The transducer 114 (e.g., one or more speakers and / or speaker drivers) receives the amplified audio signal from the amplifier 112h and renders or outputs the amplified audio signal as sound (e.g., an audible sound wave having a frequency between approximately 20 Hz and approximately 20 kHz). In some examples, the transducer 114 may comprise a single transducer. However, in other examples, the transducer 114 may comprise multiple audio transducers. In some examples, the transducer 114 may comprise two or more types of transducers. For example, the transducer 114 may include one or more low-frequency transducers (e.g., subwoofers, woofers), mid-frequency transducers (e.g., midrange transducers, midwoofers), and one or more high-frequency transducers (e.g., one or more tweeters). As used herein, “low frequency” can generally refer to audible frequencies below about 500 Hz, “mid frequency” can generally refer to audible frequencies between about 500 Hz and about 2 kHz, and “high frequency” can generally refer to audible frequencies above about 2 kHz. However, in certain examples, one or more of the transducers 114 may include transducers that do not conform to the aforementioned frequency ranges. For example, one of the transducers 114 may include a mid-woofer transducer configured to output sound at frequencies between about 200 Hz and about 5 kHz.

[0046] For illustrative purposes, Sonos, Inc. currently offers (or has offered) certain playback devices for sale, including, for example, “SONOS ONE,” “PLAY:1,” “PLAY:3,” “PLAY:5,” “PLAYBAR,” “PLAYBASE,” “CONNECT:AMP,” “CONNECT,” and “SUB.” Other suitable playback devices may be used additionally or alternatively to implement the playback devices of the exemplary examples disclosed herein. Furthermore, those skilled in the art will understand that playback devices are not limited to the exemplary examples described herein, or to the Sonos product offerings. In some examples, for example, one or more playback devices 110 comprise wired or wireless headphones (e.g., over-ear headphones, on-ear headphones, in-ear earphones). In other examples, one or more playback devices 110 comprise a docking station for a personal mobile media playback device and / or an interface configured to interact with the docking station. In certain examples, the playback device may be integrated with another device or component, such as a television, a lighting fixture, or some other device for indoor or outdoor use. In some examples, the playback device omits a user interface and / or one or more transducers. For example, Figure 1D is a block diagram of a playback device 110p that has inputs / outputs 111 and electronic equipment 112, but lacks a user interface 113 or transducer 114.

[0047] Figure 1E is a block diagram of a coupled playback device 110q, which includes a playback device 110q (Figure 1C) that includes a playback device 110a (Figure 1C) acoustically coupled with a playback device 110i (e.g., a subwoofer) (Figure 1A). In the illustrated example, playback devices 110a and 110i are separate playback devices 110 housed in separate enclosures. However, in some examples, the coupled playback device 110q comprises a single enclosure housing both playback devices 110a and 110i. The coupled playback device 110q can be configured to process and reproduce different sounds from uncoupled playback devices (e.g., playback device 110a in Figure 1C) and / or paired or coupled playback devices (e.g., playback devices 110l and 110m in Figure 1B). In some examples, for instance, playback device 110a is a full-range playback device configured to render low-frequency, mid-frequency, and high-frequency audio content, and playback device 110i is a subwoofer configured to render low-frequency audio content. In some embodiments, playback device 110a is configured to render only the mid-frequency and high-frequency components of a particular audio content when coupled with a first playback device, and playback device 110i is configured to render the low-frequency components of a particular audio content. In some examples, coupled playback device 110q includes additional playback devices and / or another coupled playback device.

[0048] c. Suitable Network Microphone Device (NMD) Figure 1F is a block diagram of the NMD120a (Figures 1A and 1B). The NMD120a includes one or more audio processing components 124 (hereinafter referred to as "audio components 124") and several components described with respect to the playback device 110a (Figure 1C), which includes a processor 112a, memory 112b, and microphone 115. The NMD120a optionally includes other components also included in the playback device 110a (Figure 1C), such as a user interface 113 and / or transducer 114. In some examples, the NMD120a is configured as a media playback device (e.g., one or more of the playback devices 110) and further includes, for example, an audio component 112g (Figure 1C), an amplifier 114, and / or one or more other playback device components. In certain examples, the NMD120a includes, for example, an Internet of Things (IoT) device such as a thermostat, alarm panel, fire detector, and / or smoke detector. In some examples, the NMD120a includes only the microphone 115, the voice processing 124, and some of the components of the electronic device 112 described above with respect to Figure 1B. In some embodiments, for example, the NMD120a includes the processor 112a and memory 112b (Figure 1B), while omitting one or more other components of the electronic device 112. In some examples, the NMD120a includes additional components (e.g., one or more sensors, a camera, a thermometer, a barometer, a hygrometer).

[0049] In some examples, the NMD can be incorporated into the playback device. Figure 1G is a block diagram of a playback device 110r equipped with an NMD 120d. The playback device 110r may comprise many or all of the components of the playback device 110a, and further include a microphone 115 and an audio processor 124 (Figure 1F). The playback device 110r optionally includes an integrated control device 130c. The control device 130c may include, for example, a user interface (e.g., user interface 113 in Figure 1B) configured to receive user input (e.g., touch input, voice input) without using a separate control device. However, in other examples, the playback device 110r receives commands from another control device (e.g., control device 130a in Figure 1B).

[0050] Referring again to Figure 1F, the microphone 115 is configured to acquire, capture, and / or receive sound from the environment (e.g., environment 101 in Figure 1A) and / or the room in which the NMD 120a is located. The received sound may include, for example, speech, audio playback by the NMD 120a and / or another playback device, background noise, ambient noise, etc. The microphone 115 converts the received sound into an electrical signal to generate microphone data. The voice processor 124 receives and analyzes the microphone data to determine whether there is voice input in the microphone data. The voice input may include, for example, an activation word following a speech that includes a user request. As those skilled in the art will understand, an activation word is a word or other voice cue that signifies the user's voice input. For example, when querying the AMAZON® VAS, the user may say the activation word "Alexa". Other examples include "OK, Google" to invoke GOOGLE® VAS and "Hey, Siri" to invoke APPLE® VAS.

[0051] After detecting the activation word, the voice processing unit 124 monitors microphone data for user requests associated with the voice input. User requests may include commands to control third-party devices such as a thermostat (e.g., NEST® thermostat), lighting fixtures (e.g., PHILIPS HUE® lighting fixtures), or media playback devices (e.g., Sonos® playback devices). For example, a user might say the activation word "Alexa" followed by "Set the thermostat to 68 degrees" to set the temperature in their home (e.g., environment 101 in Figure 1A). The user might say the same activation word followed by "Turn on the living room" to turn on the lighting fixtures in the living room area of ​​the home. Similarly, a user might say the activation word followed by a request to play a specific song, album, or music playlist on a playback device in the home.

[0052] d. Suitable control device Figure 1H is a partial schematic diagram of the control device 130a (Figures 1A and 1B). As used herein, the term “control device” can be used interchangeably with “controller” or “control system.” Among other features, the control device 130a is configured to receive user input related to the media playback system 100 and, in response, cause one or more devices within the media playback system 100 to perform actions or operations corresponding to the user input. In the illustrated example, the control device 130a comprises a smartphone (e.g., iPhone®, Android phone) with media playback system controller application software installed. In some examples, the control device 130a comprises, for example, a tablet (e.g., iPad®), a computer (e.g., laptop computer, desktop computer), and / or other suitable devices (e.g., television, car audio head unit, IoT device). In a particular example, the control device 130a comprises a dedicated controller for the media playback system 100. In other examples, as described above with respect to Figure 1G, the control device 130a is integrated into another device within the media playback system 100 (e.g., one or more of the playback device 110, NMD 120, and / or other suitable devices configured to communicate over a network).

[0053] The control device 130a includes an electronic device 132, a user interface 133, one or more speakers 134, and one or more microphones 135. The electronic device 132 comprises one or more processors 132a (hereinafter referred to as "processor 132a"), memory 132b, software components 132c, and a network interface 132d. The processor 132a can be configured to perform functions related to facilitating user access to, control, and configuration of the media playback system 100. The memory 132b may include data storage on which one or more software components executable by the processor 112a to perform those functions can be loaded. The software components 132c may include applications and / or other executable software configured to facilitate control of the media playback system 100. The memory 112b may be configured to store, for example, software components 132c, media playback system controller application software, and / or other data related to the media playback system 100 and the user.

[0054] The network interface 132d is configured to facilitate network communication between the control device 130a and one or more other devices within the media playback system 100, and / or one or more remote devices. In some examples, the network interface 132d is configured to operate according to one or more appropriate communication industry standards (e.g., infrared, wireless, wired standards including IEEE 802.3, and wireless standards including IEEE 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.15, 4G, and LTE). The network interface 132d can be configured to transmit and / or receive data to, for example, the playback device 110, the NMD 120, other devices within the control device 130, one of the computing devices 106 in Figure 1B, one or more devices with other media playback systems, etc. The transmitted and / or received data may include, for example, control commands for the playback device, state variables, and configurations for playback zones and / or zone groups. For example, based on user input received by user interface 133, network interface 132d can send playback device control commands (e.g., volume control, audio playback control, audio content selection) from control device 130 to one or more playback devices 110. Network interface 132d can also send and / or receive configuration changes, such as adding / removing one or more playback devices 110 to / from a zone, adding / removing one or more zones to / from a zone group, forming a combined player or integrated player, or separating one or more playback devices from a combined player or integrated player. Details of zones and groups are shown in Figures 1I to 1M.

[0055] The user interface 133 is configured to receive user input and facilitates control of the media playback system 100. The user interface 133 includes media content art 133a (e.g., album art, lyrics, video), a playback status indicator 133b (e.g., elapsed time and / or remaining time indicator), a media content information area 133c, a playback control area 133d, and a zone indicator 133e. The media content information area 133c may include the display of relevant information (e.g., title, artist, album, genre, release year) about the media content currently being played and / or media content in the queue or playlist. The playback control area 133d may include selectable icons (e.g., via touch input and / or via a cursor or another appropriate selector) for one or more playback devices in a selected playback zone or zone group to perform playback actions such as play or pause, fast forward, rewind, skip to next, skip to previous, start / end shuffle mode, start / end repeat mode, start / end crossfade mode, etc. The playback control area 133d may also include selectable icons for changing equalization settings, playback volume, and / or other preferred playback behaviors. In the illustrated example, the user interface 133 comprises a display presented on the touchscreen interface of a smartphone (e.g., iPhone®, Android phone). However, in some examples, user interfaces of various formats, styles, and interactive sequences may be implemented on one or more network devices to provide equivalent control access to the media playback system.

[0056] One or more speakers 134 (e.g., one or more transducers) may be configured to output sound to the user of the control device 130a. In some examples, one or more speakers comprise individual transducers configured to output low frequencies, medium frequencies, and / or high frequencies in corresponding ways. In some embodiments, for example, the control device 130a is configured as a playback device (e.g., one of the playback devices 110). Similarly, in some examples, the control device 130a is configured as an NMD (e.g., one of the NMDs 120) that receives voice commands and other sounds via one or more microphones 135.

[0057] One or more microphones 135 may include, for example, one or more condenser microphones, electret condenser microphones, dynamic microphones, and / or other suitable types of microphones or transducers. In some examples, two or more microphones 135 are arranged to capture location information of an audio source (e.g., speech, audible sound) and / or are configured to facilitate filtering of background noise. Furthermore, in certain examples, the control device 130a is configured to operate as a playback device and NMD. However, in other examples, the control device 130a omits one or more speakers 134 and / or one or more microphones 135. For example, the control device 130a may omit the speaker or microphone and instead consist of a part of the electronic equipment 132 and a device (e.g., a thermostat, an IoT device, a network device) with a user interface 133 (e.g., a touchscreen).

[0058] e. Appropriate playback device configuration Figures 1I to 1M show exemplary configurations of playback devices in zones and zone groups. Referring first to Figure 1M, in one example, a single playback device may belong to a zone. For example, playback device 110g in the second bedroom 101c (Figure 1A) may belong to zone C. In some implementations described below, multiple playback devices can be “combined” to form “combined pairs,” which together form a single zone. For example, playback device 110l (e.g., left playback device) can be combined with playback device 110l (e.g., left playback device) to form zone A. The combined playback devices may have different playback responsibilities (e.g., channel responsibilities). In another embodiment described below, multiple playback devices can be merged to form a single zone. For example, playback device 110h (e.g., front playback device) may be merged with playback device 110i (e.g., subwoofer) and playback devices 110j and 110k (e.g., left and right surround speakers, respectively) to form a single zone D. In another example, playback devices 110g and 110h can be merged to form a merged group or zone group 108b. The merged playback devices 110g and 110h do not necessarily have to be specifically assigned different playback responsibilities. That is, the merged playback devices 110h and 110i can each play audio content as they would if they were not merged, apart from playing audio content synchronously.

[0059] Each zone within the media playback system 100 may be provided for control as a single user interface (UI) entity. For example, Zone A may be provided as a single entity called the master bathroom. Zone B may be provided as a single entity called the master bedroom. Zone C may be provided as a single entity called the second bedroom.

[0060] Coupled playback devices may have different playback responsibilities, such as responsibility for a specific audio channel. For example, as shown in Figure 1-I, playback devices 110l and 110m may be coupled to produce or enhance the stereo effect of audio content. In this example, playback device 110l may be configured to play the left channel audio component, while playback device 110k may be configured to play the right channel audio component. In some implementations, such stereo coupling is sometimes referred to as “pairing”.

[0061] Furthermore, the coupled playback devices may have additional and / or different respective speaker drivers. As shown in Figure 1J, playback device 110h, named front, may be coupled with playback device 110i, called sub. Front device 110h can be configured to render the mid-to-high frequency range, and sub device 110i can be configured to render the low frequencies. However, if not coupled, front device 110h can be configured to render the full frequency range. As another example, Figure 1K shows front device 110h and sub device 110i further coupled with left playback device 110j and right playback device 110k, respectively. In some implementations, the right device 110j and left device 110k can be configured to form surround or "satellite" channels in a home theater system. The coupled playback devices 110h, 110i, 110j, and 110k can form a single zone D (Figure 1M).

[0062] Merged playback devices do not need to be assigned playback responsibilities, and each playback device can render the full range of audio content it is capable of. Nevertheless, merged devices may be represented as a single UI entity (i.e., a zone, as described above). For example, playback devices 110a and 110n in the master bathroom have a single UI entity in zone A. In one embodiment, playback devices 110a and 110n can each output the full range of audio content that each playback device 110a and 110n is capable of synchronously.

[0063] In some examples, an NMD is coupled or merged with another device to form a zone. For example, NMD120b may be coupled with playback device 110e to form a zone F called the Living Room. In other examples, a standalone network microphone device may be in a zone by itself. However, in other examples, a standalone network microphone device may not be associated with a zone. Further details regarding associating a network microphone device and a playback device as a designated or default device can be found, for example, in U.S. Patent Application Publication No. 15 / 438,749, which was referenced earlier.

[0064] The zones of individual, combined, and / or merged devices can be grouped to form zone groups. For example, referring to Figure 1M, zone A can be grouped with zone B to form zone group 108a containing the two zones. Similarly, zone G may be grouped with zone H to form zone group 108b. As another example, zone A may be grouped with one or more other zones CI. Zones A-I can be grouped and ungrouped in numerous ways. For example, three, four, five, or more (e.g., all) of zones A-I may be grouped. Once grouped, the zones of individual and / or combined playback devices can play audio synchronously with each other, as described in U.S. Patent No. 8,234,395, which was referenced earlier. Playback devices may be dynamically grouped and ungrouped to form new or different groups that play audio content synchronously.

[0065] In various examples, zones within an environment may be the default names of zones within a group or a combination of names of zones within a zone group. For example, zone group 108b may be assigned a name such as "Dining + Kitchen," as shown in Figure 1M. In some examples, zone groups may be given unique names selected by the user.

[0066] Certain data may be stored in the memory of a playback device (e.g., memory 112b in Figure 1C) as one or more state variables that are periodically updated and used to describe the state of a playback zone, playback device, and / or associated zone group. The memory may also include data that is shared from time to time between devices, associated with the state of other devices in the media system, so that one or more of the devices have the most up-to-date data associated with the system.

[0067] In some examples, memory can store instances of various variable types related to state. Variable instances may be stored with identifiers (e.g., tags) corresponding to their type. For example, a particular identifier might be a first type "a1" to identify a zone's regeneration device, a second type "b1" to identify regeneration devices that can be combined within a zone, and a third type "c1" to identify a zone group to which a zone can belong. As a relevant example, an identifier associated with second bedroom 101c may indicate that the regeneration device is the only regeneration device in zone C and not within a zone group. An identifier associated with den may indicate that the den is not grouped with other zones but contains combined regeneration devices 110h-110k. An identifier associated with dining room may indicate that the dining room is part of the dining + kitchen zone group 108b and that devices 110b and 110d are grouped together (Figure 1L). An identifier associated with kitchen may indicate the same or similar information by indicating that the kitchen is part of the dining + kitchen zone group 108b. Other exemplary zone variables and identifiers are described below.

[0068] In yet another example, the media playback system 100 may also have variables or identifiers that represent other associations between zones and zone groups, such as identifiers associated with areas, as shown in Figure 1M. Areas may include clusters of zone groups and / or zones that are not within a zone group. For example, Figure 1M shows an upper area 109a containing zones A-D and a lower area 109b containing zones E-I. In one embodiment, areas may be used to refer to clusters of zone groups and / or zone groups of zones that share one or more zones and / or other clusters. In another embodiment, this is different from zone groups that do not share zones with other zone groups. Further examples of techniques for implementing areas can be found, for example, in U.S. Patent Application Publication No. 15 / 682,506, filed August 21, 2017, entitled “Room Association Based on Name”, and U.S. Patent No. 8,483,853, filed September 11, 2007, entitled “Controlling and manipulating groupings in a multi-zone media system”. Each of these applications is incorporated herein by reference in whole. In some examples, the media playback system 100 does not have to implement areas, in which case the system does not have to store variables associated with areas.

[0069] III. Maintaining the diversification of media content history and user preferences a. Overview As mentioned earlier, user data regarding media content consumption is typically maintained using a centralized approach, resulting in fragmented user data across various different platforms, devices, and / or services. For example, a Spotify user's listening history at home may not be easily aggregated with their Apple Music listening history at work or with media content played through local content sources. Another example is a user's listening history via a Sonos playback system, which may not be easily matched with their listening event history via their smartphone.

[0070] Various aspects of this technology relate to using distributed ledger technology to store, modify, and / or manage access to user data across various different devices, service providers, and platforms. In particular, the systems and methods described herein provide decentralized maintenance of a user's media content history and preferences, thereby enabling the user to reclaim control over their data from the so-called walled garden that traditionally constrained this data.

[0071] Figure 2 is a schematic diagram of a system 200 including one or more distributed ledgers 202 according to an aspect of the technology of this disclosure. In various examples and as will be described in more detail elsewhere in this specification, the distributed ledger 202 may include public, permissionless blockchains such as Bitcoin, Ethereum, or many others. The distributed ledger 202 may be used to manage the storage, modification, and / or access of user data (e.g., user data relating to media content consumption).

[0072] As shown in Figure 2, System 200 includes various network participants (e.g., participating users 204, participating hardware providers 206, participating service providers 208, and individual regeneration devices 210a, regeneration networks 210b, and / or intermediate devices 211). For the purposes of this specification, these entities are “participants” in that they directly or indirectly exchange, provide, and / or consume data with the distributed ledger 202 in order to maintain and / or utilize data generated or acquired by the various participants. In addition to participants 204, 206, and 208, System 200 may include one or more individual devices 210 (represented by regeneration devices 210) and one or more regeneration networks 210b that may include collections of regeneration devices associated with each other (e.g., organized as a single household, account, zone, or otherwise associated with each other). Furthermore, system 200 optionally includes one or more intermediate devices 211, which can facilitate interaction between the various participants 204, 206, 208, 210 and the distributed ledger 202, as described below. Communication between these various entities and devices can be performed via network 102, which, as described above, may include any suitable wired or wireless network connection or a combination thereof (e.g., WiFi® network, Bluetooth®, Z-Wave network, ZigBee®, Ethernet® connection, Universal Serial Bus (USB)® connection, etc.).

[0073] As will be described in more detail below, system 200 is configured to maintain user data that may include various record sets 212. In the illustrated example, record sets 212 include a Content Experience Record Set (CERS) 214, a Content Network Record Set (CNRS) 216, and an auxiliary record set 218. These record sets 212 can be stored, updated, and / or accessed, directly or indirectly, through the distributed ledger 202. In some examples, record sets 212 may include data from multiple different participants, including one or more participating users 204, one or more participating hardware providers 206 (e.g., manufacturers or retailers of playback devices), and / or one or more participating service providers 208 (e.g., media content services, voice assistant services, Internet of Things (IoT) platforms, etc.). Thus, data from various sources can be aggregated and stored via the distributed ledger 202.

[0074] In the illustrated example, the record set 212 may be stored directly in the distributed ledger 202. Furthermore, the distributed ledger 202 may contain, interact with, or implement one or more tokens 220 (including fungible and / or nonfungible tokens (NFTs)), smart contracts 222, and / or decentralized autonomous organizations (DAOs) 224. In various examples, these decentralized objects and entities may be used to facilitate the storage, modification, and / or provision of access rights to user data.

[0075] Additionally or alternatively, the record set 212 may be stored in one or more intermediate devices 211 that facilitate the management of data via the distributed ledger 202. As will be described in more detail below, the intermediate devices 211 may include data access controls 226 that allow participants to have more granular control over which data is exposed to the distributed ledger 202. In various examples, the intermediate devices 211 may function as an identity hub that stores some or all of a participant's record set 212 and allows them to selectively expose or disclose the record set data via the distributed ledger 202 and / or to other participants in the system 200. As described herein, data referred to as being stored in or via a blockchain or other distributed ledger may be stored (and / or accessed) directly via such a blockchain or distributed ledger, or via an intermediate device, local data storage, or other such component that is not itself a distributed ledger or blockchain. In such cases, an intermediate device, local data storage, or other such component may contain a pointer to blockchain data, and the data accessed thereby refers to the data that will ultimately be stored via the blockchain.

[0076] b. Examples of distributed ledgers As described above, system 200 includes and / or can communicate with one or more distributed ledgers 202, which can store, instantiate, or communicate with one or more tokens 220, smart contracts 222, and / or decentralized autonomous organizations (DAOs). Suitable examples of distributed ledgers 202 include Bitcoin, Ethereum, Solana, Avalanche, Polygon, and many other public distributed ledgers. In various examples, system 200 may include one or more distributed ledgers 202, which may optionally communicate directly with one another. While some examples described herein relate to permissionless blockchains, various examples may utilize any suitable distributed ledger technology, including private or semi-private blockchains (e.g., Hyperledger Fabric, Corda, etc.) and non-blockchain implementations such as directed acyclic graphs (DAGs) (e.g., Nano, IOTA, etc.). Optionally, a distributed ledger 202 may include so-called "Layer 2" blockchains that operate on top of their respective "Base Layer" blockchains. Examples of such Layer 2 networks include the Lightning Network (Bitcoin), the Raiden Network (Ethereum), Plasma (Ethereum), the Base Network (Ethereum), and many others.

[0077] In various examples, participants using a distributed ledger 202 can trade with each other in a peer-to-peer manner, and the operation of the distributed ledger 202 can be decentralized so that no central entity controls the operation of the network. Such a distributed ledger 202 can be used to track the creation, exchange, and redemption of certain real-world assets, such as currencies. This approach enables robust auditing of asset transactions due to the substantial immutability of the data stored on the blockchain. Currencies are just one of many types of assets that may be desirable to track on a distributed ledger. Other types of assets may differ from currencies in one or more behaviors that govern the creation, exchange, and / or redemption of assets. Furthermore, different blockchain architectures may differ in terms of policies and protocols, and even in terms of the tools used to program asset behavior.

[0078] In various examples, a distributed ledger 202 can represent and manage transactions that involve one or more tokens 220. Generally, a distributed ledger 202 in which each unit of an asset is represented by some form of digital token 220 can be programmed to assign a set of behaviors appropriate to the asset it represents. For example, "fungible" behavior allows one asset to be exchanged for other assets of the same class. All units of a particular denomination of currency (e.g., dollars) are fungible because they have the same value as all other units of the same denomination. In contrast, ownership of real estate is "non-fungible" because its value depends on the size, location, and other aspects of the designated property. For each asset represented as a token 220, the appropriate fungible or non-fungible behavior is programmed into the class of that token in the distributed ledger 202 that tracks that asset.

[0079] According to some embodiments, tokens 220 traded via a distributed ledger 202 may be non-fungible. Such non-fungible tokens (NFTs) may be unique and not interchangeable with any other tokens. NFTs may include and / or be associated with unique media content, domain names, digital artwork, digital collectibles (e.g., Bored Ape Yacht Club, memes), event tickets, parts of virtual worlds, digital objects used in games, avatars or characters, utility items (e.g., certain functions such as providing voting rights or governance rights). In various examples, an NFT may include the relevant data itself to facilitate media playback (e.g., raw audio data for a music NFT may be stored on-chain), or an NFT may include a pointer (e.g., a URL or URI) to data stored elsewhere (e.g., audio data stored on a server maintained by the issuer of the music NFT or other appropriate storage location). In further examples, NFTs may themselves point to other data stored on-chain that may be used to facilitate media playback.

[0080] Whether fungible or nonfungible, such tokens 220 can be stored via a digital wallet by the appropriate entities (e.g., participants such as participating users 204, hardware providers 206, and / or service providers 208). A digital wallet can be a device, physical medium, program, or service that stores public and / or private keys for blockchain transactions. In some examples, a digital wallet can store multiple public / private key pairs for various different blockchains, and as a result, a user can store assets associated with different blockchains in a single wallet. Examples include MetaMask, Phantom, Coinbase Wallet, and Ledger Nano. In operation, a user can sign a blockchain transaction via a wallet using the appropriate private key (or by allowing the wallet to sign the transaction with the private key). If the transaction signature is valid, the transaction is confirmed and added to the corresponding block in the blockchain.

[0081] In some examples, ownership of a particular token 220 may be a prerequisite for accessing specific media content. For example, consider an artist (as a participating user 204) who wants to provide access to their media content only to selected fans (who could also be participating users 204). As an example, the artist's followers may be required to hold a particular NFT or other token 220 in order to access the artist's media content. In yet another example, a particular curated playlist or radio station may be accessible only to users holding a particular NFT or other token 220. A similar concept is described in the jointly owned international application PCT / US23 / 66776, filed on 9 May 2023, entitled "Generating Digital Media Based on Blockchain Data," which is incorporated herein by reference in its entirety for all purposes.

[0082] Optionally, data corresponding to the token 220 (e.g., an NFT) (e.g., data facilitating the playback of specific media content) can be stored or embedded via a physical medium. For example, data corresponding to an NFT can be embedded in a vinyl record, a physical card or ticket, a poster, or any other suitable technology for storing data via a physical medium (e.g., NFC or other RF tag). The NFT can be read by a suitable device (e.g., a device associated with the participating hardware provider 206, a blockchain-integrated playback device 210, etc.), which can then initiate playback of the appropriate media content.

[0083] In some examples, user data (e.g., record set 212) can be stored in whole or in part via the distributed ledger 202, as will be described in more detail elsewhere in this specification. For example, media consumption history, preferences, and / or other relevant information about a participating user 204 can be stored via the distributed ledger 202 to provide a persistent and immutable data record. This may include media consumption history as well as specific media content created by the user (e.g., in the case of an artist or group). In some examples, a "follower" of a particular user can subscribe to that user's listening history by accessing data stored via the distributed ledger 202. Because blockchains are typically permissionless and transparent, followers can freely access the listening history (or other content data associated with a particular network address).

[0084] In various examples, the distributed ledger 202 can be configured to automatically execute transactions under one or more conditions. Such self-executing transactions are sometimes called smart contracts 222. A smart contract 222 may contain computer code stored on the distributed ledger 202 that is configured to execute only under specific circumstances and in specific ways. For example, a smart contract may be configured to execute a specific transaction when a threshold is exceeded, at a specific time, based on one or more other transactions, or based on any other appropriate criteria. In some examples, a record set 212 (e.g., a Content Experience Record Set (CERS) 214, a Content Network Record Set (CNRS) 216, or any other appropriate record set) can be automatically modified, sent to a designated recipient, have access granted or revoked, or take any other appropriate action based on a smart contract 222. Therefore, one or more participants 204, 206, or 208 interacting with the smart contract 222 through the distributed ledger 202 can cause the smart contract to update the record set 212, access the record set 212, and / or change the permissions associated with the record set 212.

[0085] Bitcoin Ordinals are an example of a standard for implementing smart contract-like functionality and storing information or rules on the Bitcoin blockchain, which can be leveraged by blockchain-enabled playback devices. Unlike other smart contracts on platforms like Ethereum, Ordinals utilize Bitcoin's unique scripting language to directly inscribe data into individual satoshis, the smallest unit of Bitcoin. This approach enables the creation of unique non-fungible tokens (NFTs) and the storage of arbitrary data on the Bitcoin network. In the context of media playback systems, Ordinals can be used to encode and store various types of information related to a user's media experience, such as ownership of specific content, playback rules, or even small media files themselves. Blockchain-enabled playback devices can interact with such Ordinals to verify content ownership, enforce usage restrictions, and access embedded metadata. Additionally or alternatively, Ordinals may be used to encode and store any of the various types of record set information described herein, including any information described herein with respect to other exemplary embodiments of NFTs, and / or any information described in relation to Figures 3 and / or 4. While Ordinals are provided as examples, any suitable smart contract implementation may be used in combination with the blockchain-integrated playback devices described herein.

[0086] One organizational structure unique to distributed ledgers is the Decentralized Autonomous Organization (DAO) 224. A DAO 224 is typically a community-driven entity without a central authority. Such a DAO 224 can be fully autonomous and transparent, with smart contracts providing the basic rules and executing agreed-upon decisions. Community voting can be cast through token holders using on-chain transactions. Based on the results of a particular vote, a smart contract can execute specific transactions or other code to implement the decisions of the DAO members. Typically, a DAO 224 issues tokens (e.g., token 220) to users in exchange for currency investment or donations, or free of charge (e.g., via an "airdrop"). Token holders then typically hold certain voting rights, which may be proportional to their holdings. In some examples, token holders also receive monetary benefits, such as a share of transaction fees collected by the DAO. For example, a DAO224 associated with a specific artist or media content could hold specific music royalties, which, when collected, could be partially distributed to holders of appropriate NFTs or other tokens 220 (for example, a participating user 204 holding the appropriate token 220 could receive economic benefits from the artist DAO224, at least partially based on the user's ownership of the token 220). Optionally, the entire transaction could be conducted automatically and without permission via a distributed ledger 202.

[0087] In some cases, the DAO itself may function as a network participant in System 200, representing or being facilitated by, for example, one or more of a specific user 204, hardware provider 206, or service provider 208. For example, in contrast to traditional approaches, a local DAO may be responsible for controlling home or business devices and / or services associated with System 200 and / or additional systems, without the need for a remote, centralized platform.

[0088] c. Examples of participants As shown in Figure 2, System 200 can include a number of different network participants that directly or indirectly interact with the distributed ledger 202 to store, manage, modify, and / or access user data. As illustrated, participants may include participating users 204, participating hardware providers 206, and / or participating service providers 208. In some examples, the communication protocol used when various data are collected and written to the distributed ledger 202 includes a mechanism for various participants to add themselves to the network or be added to the network so that they have read and / or write access rights to the distributed ledger 202. In the case of a public and permissionless blockchain (e.g., Bitcoin, Ethereum), such a mechanism may also be public and permissionless, and as a result, any entity can freely interact with the distributed ledger 202 without relying on centralized authority for providing permissions or granting access. In some cases, a centralized or quasi-centralized authority may manage access to the network, ensuring that only authorized participants are granted read and / or write access to data stored via the distributed ledger 202. Additionally or alternatively, the centralized or quasi-centralized authority may facilitate the authentication and / or verification of data added to the distributed ledger 202, so that viewers can verify that the data written to the distributed ledger 202 is a legitimate part of the content protocol or system involved. In this way, it is possible to prevent malicious actors from spoofing data against the distributed ledger 202 by falsely claiming to contribute to a participant's record set 212.

[0089] In various embodiments, one or more participants may have one or more associated identifiers used to interact with the distributed ledger 202. These identifiers may be unique to that participant, and consequently, all access to the distributed ledger 202 is mediated by these unique identifiers. Various techniques are available for assigning and managing identifiers for persistent interaction with the distributed ledger 202. One approach involves a distributed ID (DID) that can function as a component of a Self-Sovereign Identity System using distributed ledger technology. Various DID methods have been proposed, providing a set of specific rules, conventions, and procedures that define how DIDs are created, resolved, updated, and invalidated within a particular blockchain or distributed ledger system. Examples of DID methods include did:ethr (Ethereum DID method), which uses the Ethereum blockchain for DID creation and management; did:ion (Microsoft's ION DID method), which uses the Bitcoin blockchain for DID creation and management; and did:wheb (Web DID method), a more general method for DIDs that uses HTTP for resolution and is not dependent on a specific blockchain. In the case of public blockchains (e.g., Bitcoin and Ethereum), any participant can freely create DIDs in a trustless environment. In the case of permissioned blockchains (e.g., Hyperledger Fabric, Corda, etc.), managed access may be required to generate DIDs. In various examples, DIDs can utilize public / private key pairs so that each DID is associated with a public key for identification and a private key for authentication and access control. The DID itself may be a string conforming to a specific syntax (e.g., did:method:specific-id). Optionally, each DID is globally unique and serves as a universal reference to identity on the blockchain.Another suitable approach is to use the Ethereum Name Service (ENS) to establish persistent identifiers that participants can use to interact with the distributed ledger 202.

[0090] MicroStrategy's Orange platform is another example of a decentralized identity (DID) implementation that can be integrated into blockchain-enabled playback devices. Orange leverages the Bitcoin network to create and manage self-sovereign digital identities, enabling users to maintain control over their personal data as they interact with various services and devices. The protocol employs a specific method called Bitcoin Inscription DID (did:btc), which uses UTXOs for DID control and writes identity data directly to the blockchain through Bitcoin transactions. In the context of the media playback ecosystem, an identity platform like Orange, which is created, deployed, and managed "centrally," can provide a secure, user-centric way to manage identity across multiple devices and platforms. Users can associate their Orange-based DID with Content Experience Record Sets (CERS) and Content Network Record Sets (CNRS), thereby ensuring consistent, portable (i.e., decentralized and distributed) information, including media preferences, across different playback devices.

[0091] In some cases, interoperability standards may be used to enable communication between different DID and identity systems. For example, standards and formats developed by the W3C's Distributed Identity Working Group may be used to facilitate interoperability between different DID and identity systems.

[0092] A specific DID may be associated with specific data, which may be stored directly on-chain or via an intermediate device communicating with the distributed ledger 202. In some examples, a DID may be associated with a DID document containing metadata and a public key associated with that particular DID. This document may provide information on how to communicate with the subject of the DID, as well as endpoints for services such as verification methods, authentication, or other related services. In some examples, user content data (e.g., record sets 212 such as CERS214, CNRS216, or auxiliary record set 218) may be stored in whole or in part via a DID document. In some examples, a DID may be linked to an off-chain storage system (e.g., an InterPlanetary File System (IPFS) or a distributed file system) to store larger datasets associated with a particular identifier.

[0093] In some cases, it may be beneficial for one or more participants to verify the claims associated with their respective DIDs without disclosing the underlying information or source data. For example, zero-knowledge proofs (ZKPs) can be used to prove to the other party (verifier) ​​that a participant possesses certain information or knowledge without disclosing the information itself (e.g., proving that a participant knows a password without disclosing the actual password). Various examples of ZKPs are possible, including zk-SNARKs, zk-STARKs, or other appropriate techniques.

[0094] Another similar approach involves verifiable credentials, which are a means of providing proof or evidence of specific attributes or claims associated with an identifier (e.g., age, citizenship) without disclosing the underlying data. For example, a participating hardware provider 206 could issue verifiable credentials to a purchaser proving that the purchaser has purchased a particular playback device. The purchaser (as a participating user 204) could then present their verifiable credentials to prove the purchase or ownership of the device without disclosing the underlying data. Verifiable credentials can take the form of structured data that includes information about the subject, the issuing entity, the claims being made, and a cryptographic signature to ensure the integrity and authenticity of the credentials.

[0095] In some examples, one or more “identity hubs” may be used to facilitate interaction with the distributed ledger 202 using DID. In operation, the identity hub may be operated by an intermediate device 211 or instantiated within a specific participant (e.g., user 204, hardware provider 206, and / or service provider 208). The identity hub (or similar entity) may also be implemented by individual regeneration devices 210 and / or regeneration networks 210b. The identity hub can function as an intermediary that stores data (e.g., DID documents or other appropriate data), which may be encrypted to ensure that only the owner of the identity hub or authorized users hold the keys necessary for access and decryption. The owner maintains fine-grained control over who can access the stored information, including the ability to grant or revoke permissions to specific entities or applications. When interacting with third parties, individuals may selectively disclose relevant information from their identity hub depending on the context and requirements. Furthermore, the identity hub may incorporate functionality for revoking or expiring permissions, allowing the owner to stop data access as needed. In some cases, while leveraging the underlying blockchain for authentication and key management, off-chain storage solutions can be used for larger or less sensitive identity-related data. Furthermore, the identity hub may incorporate an event logging mechanism. These logs comprehensively record all access requests and actions performed within the hub. This audit trail can significantly improve transparency and accountability, proving beneficial for compliance and security.

[0096] For example, participating users 204 may include individuals such as general users (e.g., consumers of media content, purchasers of media playback devices, etc.). Additionally or alternatively, participating users 204 may include businesses and commercial users, as well as artists, tastemakers, influencers, or other such individuals involved in the creation or consumption of media content. As described throughout, data concerning a user's content consumption history, media preferences, and / or any other relevant data may be stored, modified, and / or shared with other entities by the distributed ledger 202. Furthermore, participating users 204 may read data from the distributed ledger 202 for use in playback, for example, by retrieving playlists from other users shared via the distributed ledger 202.

[0097] The participating hardware provider 206 may include a platform associated with a playback device (e.g., a SONOS media playback platform, a smart TV platform for managing various content sources, etc.), as well as a manufacturer or retailer of such playback devices. Additionally or alternatively, the participating hardware provider 206 may include individual playback devices (e.g., an audio playback device 210, a smart TV, etc.), a group of such devices in the same household, or a provider of other such configurations. In various examples, the participating hardware provider 206 may provide data to and read data from the distributed ledger 202. For example, the hardware provider 206 may access a user's aggregated media content history and preferences via the distributed ledger and leverage such data to facilitate media playback (e.g., generating playlists, adjusting playback of requested content according to the user's preferences, etc.).

[0098] In some cases, participating hardware providers 206, such as platforms associated with playback devices, can provide specific infrastructure services related to the decentralized maintenance of user content history and preferences. For example, such a platform may maintain a cross-service content database (e.g., a library that universally identifies all content regardless of a particular media service). Such a database can aggregate various metadata about the content, in addition to basic identification information. Such metadata may include various content IDs that can be used for content across different content services (e.g., a universal ID may have associated IDs, such as a first ID for content retrieval via Spotify, a second ID for retrieval via Apple Music, etc.). Thus, this database may be used by system 200 to divorce content information from specific service providers.

[0099] As another example, a participating hardware provider 206, such as a media playback platform, may act as an issuer and / or verifier of verifiable credentials to assist in the management of formal credentials within System 200. Such credentials may include verified registrations of specific participants, such as a service provider 208, additional hardware providers 206, artists, and / or other commercial actors. Such credentials can demonstrate to the end user that a particular account claiming to be associated with a specific person or entity (e.g., Taylor Swift's DID) is indeed associated with that person or entity.

[0100] Participating service providers 208 may include media content services (e.g., music content providers such as Spotify and Pandora, and video content providers such as Netflix and Hulu). Additionally or alternatively, participating service providers 208 may include voice assistant services (e.g., Google Assistant, Amazon's Alexa, Apple's Siri, etc.). In additional examples, participating service providers 208 may include any entity that supplies system inputs related to media playback (e.g., Sonos as a universal track ID provider), lyrics database providers, providers of supplementary content or information provided by artists or labels, and supplementary content from social media influencers. In various examples, participating service providers 208 may also provide data to and read data from the distributed ledger 202. For example, service providers 208 may access a user's aggregated media content history and preferences via the distributed ledger and leverage such data to facilitate media playback (e.g., generating playlists, tailoring voice-based search results to user preferences, etc.).

[0101] In various examples, individual devices 210 take the form of blockchain-enabled replay devices 210. For example, a replay device 210 may be configured to interact with a distributed ledger 202 to perform specific operations specific to the distributed ledger 202, such as mining, staking, and transaction verification. In some examples, a blockchain-enabled replay device 210 may include appropriate hardware components (e.g., sufficient memory to store some or all of the blockchain history, one or more dedicated processors (e.g., GPU, ASIC, etc.)) so that the blockchain-enabled replay device 210 is configured to perform operations associated with the distributed ledger 202. Examples include mining (e.g., mining Bitcoin or other proof-of-work cryptocurrencies), verification (e.g., acting as a validator for Ethereum or other proof-of-stake cryptocurrencies), or enforcing a consensus mechanism to confirm or verify transactions added to the distributed ledger 202, such as other such operations. In some cases, the blockchain-enabled playback device 210 may be configured to function as a node of the distributed ledger 202 (e.g., a full node that stores a complete implementation of the distributed protocol, an archive node, a pruning node, a mining node, a lightning node, a second-layer node (e.g., a lightning node that operates on the Bitcoin blockchain)).

[0102] In some cases, blockchain-enabled playback devices can utilize dedicated high-frequency audio transducers for data communication, particularly in devices that do not typically have high-frequency drivers such as tweeters. These transducers can operate in the ultrasonic or quasi-ultrasonic frequency range, making them virtually inaudible to the user, and can be integrated into various components of media playback systems, including subwoofers, LP turntables, audio / video components, and even data storage devices such as smart wallets. This approach enables secure, localized data transmission via acoustic waves, providing a channel to replace or complement conventional wireless communication methods. Further details regarding the use of acoustic signatures for communicating information between devices are described in U.S. Patent No. 8,930,005, “Acoustic Signatures in a Playback System,” issued 6 January 2015, which is incorporated herein by reference in its entirety for all purposes. Additionally or alternatively, audible audio signals (e.g., using conventional audio transducers configured to output audible audio signals) can be used for data transmission between playback devices.

[0103] One particularly advantageous application of this technology is its ability to communicate with air-gap devices such as encrypted smart wallets. For security reasons, such air-gap devices are isolated from standard network communication channels and are preferably selectively connected to the internet only, or not directly connected at all. By equipping these security-critical devices with dedicated high-frequency transducers and one or more microphones, blockchain-integrated devices can establish an acoustic data channel for secure information exchange. This communication method can enhance the overall system security by enabling highly sensitive operations, such as cryptographic key management and transaction signing, to be performed on devices physically isolated from the network, while maintaining a functional connection to the blockchain-enabled audio ecosystem. Further details regarding the use of high-frequency transducers for data communication are described in International Patent Application PCT / US2024 / 17126, filed on 23 February 2024, entitled “Playback Devices with Dedicated High-Frequency Transducers,” which is incorporated herein by reference in its entirety for all purposes.

[0104] In various examples of this technology, the concept of a blockchain-enabled playback device extends beyond traditional home audio systems to encompass a wide range of environments and devices. This broad definition includes, but is not limited to, automobiles, mobile devices, augmented reality (AR) and augmented reality (XR) personal devices, and other platforms enabling media playback outside the home. For example, a vehicle's audio system could be integrated as a blockchain-enabled playback device, allowing for a seamless integration and continuation of the user's media experience from home to car, or vice versa. This integration could be particularly advantageous in the context of autonomous vehicles, where the car can evolve into an extension of the home living space. As autonomous driving technology becomes more widespread, vehicles could transform into mobile entertainment and productivity hubs, potentially becoming fully integrated into the user's blockchain-enabled media ecosystem. Similarly, mobile devices and AR / XR wearables could function as portable blockchain-enabled playback devices, maintaining a consistent user experience and preferences across various contexts and locations. This expanded concept reflects the potential of blockchain technology to provide a unified framework for managing media experiences across diverse platforms, environments, playback devices, and / or playback device networks.

[0105] d. Example of a recordset As shown in Figure 2, the system 200 can maintain one or more record sets 212, which may include, among other examples, a Content Experience Record Set (CERS) 214, a Content Network Record Set (CNRS), and / or an auxiliary record set 218. In some examples, the various record sets 212 may be unique to individual users (optionally associated with a single identifier such as the DID mentioned above). As previously stated, at least a portion of the data may be stored directly on-chain via the distributed ledger 202 (e.g., all data is written directly to blocks on the blockchain, allowing public access to it). Additionally or alternatively, some or all of the data may be stored off-chain via, for example, an "Identity Hub" or other intermediate device or service, a blockchain-integrated playback device 210, or other off-chain storage device. In such cases, the on-chain data may contain pointers to the off-chain data, thereby allowing the user selective access to specific data (e.g., a subset of record sets 212, a subset of CERS, etc.) via the distributed ledger 202.

[0106] Figure 3 shows an exemplary structure of CERS data 300. In various examples, CERS data 300 can reflect an aggregated history of a user's content consumption history. In the illustrated example, CERS data 300 is organized according to content consumption events, but other structures may be used. For each content consumption event, corresponding data may be recorded. As shown in Figure 3, the corresponding data may include event time (e.g., time, duration, scrub information) and the associated playback device and / or platform used. The corresponding data may further include any identified user preferences (e.g., preferred service provider, other preferences such as playback settings (e.g., EQ, crossfade, etc.)) and entities that add specific records. For example, a record of a given media consumption event may be added to CERS by a playback device, hardware provider, media content service, or other entity, and the identity of this entity may be associated with the corresponding entry in CERS.

[0107] Continuing to refer to Figure 3, the CERS data 300 includes the source of the record (e.g., how the record information was identified as being associated with a particular user) and content metadata (e.g., track name, artist name, album name, universal ID, etc.). Finally, the CERS data 300 may include a record of all transport controls performed during the consumption event (e.g., pause, skip, etc.). Any additional data associated with the media consumption event may also be stored as CERS data 300 for storage via the distributed ledger 202.

[0108] Figure 4 shows an exemplary structure of CNRS data 400. In various examples, CNRS data 400 can reflect records of various devices, platforms, content services (etc.) that form an overall network or ecosystem of a user's content consumption. CNRS data 400 can be divorced from specific content consumption events. On the other hand, appropriate items from CNRS associated with a user may be referenced by CERS in relation to any given consumption event (e.g., to identify a specific playback device or platform associated with the user).

[0109] In operation, CNRS can contain a wide range of data, including many alternative fields for potential populations. Figure 4 shows an exemplary structure of CNRS data 400, with only a few selected examples shown. As illustrated in Figure 4, CNRS data 400 can include participant categories (e.g., individual users, devices, platforms, content services, voice services, etc.), as well as associated provider names (e.g., company names associated with a platform, affiliated entities, etc.). Specific information about devices, user types, or account types, as well as network ID information, can also be stored via CNRS. Playback settings of entities (preferred or actual), such as equalization and brightness, as well as configuration data (e.g., grouping or pairing of playback devices, rooms, or locations, etc.) can also be stored. CNRS data 400 may further include time information indicating when a particular entity was registered, activity or inactivity times, purchase date (for devices), etc. Finally, additional metadata such as assigned names, location information, and / or any other appropriate information associated with the entity's CNRS can be included in the CNRS data. In operation, the CNRS data 400 may be maintained and / or accessed via the distributed ledger 202, as described elsewhere in this specification.

[0110] In addition to CERS214 and CNRS216, one or more auxiliary record sets 218 may be stored and / or accessed via the distributed ledger 202. In various examples, other arbitrary types of data or record sets may be implemented instead of, or in addition to, the exemplary information reflected in CERS214 and CNRS216. Furthermore, auxiliary record sets 218 may be maintained as record sets of a different type or hierarchy than CERS214 or CNRS216. For example, such auxiliary record sets 218 may not be defined or required by system 200 for operation via the distributed ledger 202, but may be implemented at the discretion of a third party. In some examples, such various data may be stored in a smart contract associated with the distributed ledger 202 (e.g., smart contract 222).

[0111] One exemplary auxiliary record set 218 includes a playlist. For example, a user can create a playlist of media content. The underlying data of the playlist may then be stored as a smart contract 222 or NFT220, and a pointer to that smart contract 222 or NFT220 may be stored in the user's CERS214. The creation of the playlist (and its associated playlist ID) may be stored in the user's CERS214, along with a reference to the network address and criteria of the corresponding smart contract 222 or NFT220. Furthermore, the CERS214 may maintain playback, interaction, editing, and / or preference information associated with that playlist. Separately, the user can attach various access rights or conditions to the smart contract 222 that runs the playlist for future interactions by others (e.g., only certain users can access the playlist, payment is required for access to the playlist, editing or addition rights are restricted, etc.). Optionally, users can establish a payment gateway for public access to the playlist (for example, by specifying a receiving address to receive cryptocurrency via distributed ledger 202, thereby automatically granting access to the playlist (for example, via smart contract 222)).

[0112] Another example of the auxiliary record set 218 is an aggregated playlist. A third party (e.g., a hardware provider platform) may generate a playlist based on mining CERS information of selected public users (e.g., all users in the Boston metropolitan area). The aggregated playlist may be stored and / or maintained via the distributed ledger 202, as described above. Optionally, the third-party owner of the aggregated playlist may optionally use a smart contract 222 to demand payment for access or to grant access to the aggregated playlist (e.g., based on subscription, membership, etc.).

[0113] In some cases, the auxiliary record set 218 may relate to premium information or experiences provided by the hardware provider 206 or other appropriate entity. For example, the hardware provider 206 (or other third party) may provide access to information or settings for delivering a unique content experience. As an example, such an entity may provide artist-curated equalization or other playback settings for use with a specific playback device configuration when listening to content by a particular artist. As another example, the unique content experience may include supplemental content associated with given media content (e.g., artist narratives accompanying the song, visual content accompanying the song, extended versions of the song, etc.). The third party may optionally use a smart contract 222 to require payment or authentication information for access to such a unique content experience, or to restrict access in other ways.

[0114] In another embodiment, the auxiliary record set 218 may include additional information beyond media content consumption and preferences. Examples include additional sensor data (e.g., sensor data from the playback device or other network sensors that reflect data characterizing the user's environment), contextual awareness information (e.g., the user's presence, the relative position of the playback device, the user's activity level, etc.), or any other appropriate data.

[0115] In various examples, device characteristics and / or settings may be included within auxiliary record sets 218, CERS214, and / or CNRS216. Appropriate examples include device model, version number, and capabilities (e.g., number and type of audio transducers, supported wireless communication protocols, audio processing capabilities, etc.). Further examples may include settings or configurations that may be associated with a particular playback event (e.g., calibration / equalization settings, volume, etc.).

[0116] As another example, an auxiliary record set may encompass a wide range of data related to the environmental context used to personalize media playback. Details of such data related to environmental context and control using machine learning are described in U.S. Provisional Application No. 63 / 516,343, filed July 28, 2023, entitled “Perspnalozation Techniques for Media Playback Systems,” which is incorporated herein by reference in its entirety for all purposes. As an example, such an auxiliary record set may include data collected from various sensors, general device metadata, and comprehensive positioning or localization information, whether in raw, formatted, or conditioned form. Sensor data may be derived from a variety of different sources, such as Bluetooth®, WiFi®, ultra-wideband (UWB) technology, acoustic signaling, ultrasound, or other signaling and communication means that facilitate localization, acoustic topology mapping, or similar spatial and contextual information. Such auxiliary record sets can also incorporate input data representing user interaction with the media playback system, along with relevant contextual information such as date, time, and location. Device configuration data may also be included, including the identity of the affected playback device, current volume settings, status and configuration of combined groups, and the device's current location. User interaction data may include volume adjustments, selection of audio content sources (e.g., playlists, streaming channels, radio stations), and commands to group or ungroup playback devices. Additionally or alternatively, auxiliary record sets may include movement or localization information that potentially indicates user movement of portable playback devices, such as through a positioning system application. Such data collection can enable machine learning applications for enhanced in-home context awareness and control.

[0117] e. Exemplary methods for maintaining, accessing, and modifying record sets via a distributed ledger. Figure 5 is a schematic diagram illustrating the interaction of a media playback system involving a distributed ledger. As illustrated, the primary ledger 202a (e.g., Bitcoin, Ethereum, or any other distributed ledger 202 mentioned above) can take the form of a blockchain where data is stored in a series of blocks 502a-h, with each block reflecting all the data from the preceding block in addition to adding newly added data. In this way, any particular block 502 reflects the entire history of the primary ledger 202a up to that point. In the example shown in Figure 5, the CERS and CNRS data are first written to the primary ledger 202a in block 502b (labeled as CERS1 and CNRS1). Subsequently, the updated CERS and CNRS data are written to the primary ledger 202a in block 502g (labeled as CERS2 and CNRS2). These updated CERS and CNRS data entries may reflect, for example, any interactions, media consumption events, or other activities that occurred between the previous entry recorded in block 502a. In this way, updates to the CERS and CNRS data can be continuously written to the primary ledger 202a, maintaining up-to-date information accessible to other network participants in the media playback system communicating with the primary ledger 202a.

[0118] As shown in Figure 5, CERS and CNRS data can be retrieved from various entities. For example, a first playback device 210a can directly write data to the primary ledger 202 for entry into CERS and CNRS. Additionally or alternatively, the first playback device 210a can send its own data to a first participating hardware provider 206a, which can then send the associated data to the primary ledger 202a for entry into CERS and CNRS. The first participating hardware provider 206a can also be associated with a media playback platform 206b (e.g., a SONOS media playback platform), which in turn can be associated with second, third, and fourth individual playback devices 210b, 210c, and 210d, respectively. These playback devices 210b, 210c, and 210d are, for example, the same It may be a home or part of an environment, each of which can transmit its own data to the media playback platform 206b, which can transmit this data (and optionally additional data collected at the media playback platform 206b level) to the first participating hardware provider 206a. As will be discussed later with respect to Figures 10 to 17, in some embodiments, the blockchain-enabled playback device may also include software and / or hardware that enables functions related to artificial intelligence, including a generating media component and / or a generating context and control component. Among the examples, any of the devices depicted in Figure 5 can take the form of such a blockchain-enabled device that includes a generating media component and / or a generating context and control component.

[0119] In another embodiment, an individual playback device (e.g., a first playback device 210a) can aggregate data from other playback devices (e.g., a sixth playback device 210f and a seventh playback device 210g). This aggregated data (e.g., data from each of the first, sixth, and seventh playback devices 210a, 210f, and 210g) can be transmitted from the first playback device 210a to the primary ledger 202a. Additionally or alternatively, such aggregated data may first be transmitted from the first playback device 210a to a hardware provider, a playback network (e.g., a home), a media platform, or other entity, which then performs layered verification to the primary ledger 202a. In yet another embodiment, each individual playback device may communicate directly with the primary ledger 202a without any data aggregation by any intermediate.

[0120] Therefore, the first participating hardware provider 206a can aggregate data from various playback devices 210a-d and media playback platform 206b. Optionally, and as illustrated in Figure 5, the first participating hardware provider 206a can implement a secondary ledger 202b that can store some or all of the data collected from various devices. Additionally or alternatively, the secondary ledger 202b may be a non-blockchain database that aggregates data collected from various different devices and platforms. The first participating hardware provider 206a may, as appropriate, transmit data to the primary ledger 202a periodically, continuously, or otherwise for entry into CERS and CNRS.

[0121] In some embodiments, the secondary ledger 202b may be implemented at the level of a media playback platform 206b, one or more individual playback devices 210, or a playback network (e.g., a collection of individual playback devices 210 grouped together in an environment such as a home). In such scenarios, one or more devices may work together to implement a private or semi-private blockchain operating using conventional blockchain protocols, and individual devices in the network (e.g., within the same home) may function as nodes of that particular blockchain.

[0122] In various examples, CERS and / or CNRS data may be updated according to various timing schemes (for example, data from various devices, providers, and platforms may be incorporated into CERS and / or CNRS and written to the primary ledger 202a). In some examples, data may be updated at regular intervals (e.g., every minute, every hour, every day). Data may also be updated in response to specific trigger events or conditions. For example, CERS data may be updated following each media consumption event. Similarly, CNRS data may be updated following the addition of a new device or service to a user's account associated with the media playback platform 206b. In another example, CERS and / or CNRS data may be updated based on user prompts or instructions received from another network device. In one exemplary use case, if a user wants to stop paying for a particular service but wants to retain access to their listening history through that service, they can instruct the CERS and / or CNRS data to be updated so that the data can be migrated to a different media content service.

[0123] As shown in Figure 5, the CNRS and CERS data may also reflect contributions from a second participating hardware provider 206c, which can receive data from a fifth playback device 210e. Optionally, the second participating hardware provider 206c may differ from the first participating hardware provider 206a (e.g., SONOS vs. SAMSUNG). Furthermore, the first participating service provider 208a and the second participating service provider 208b can provide data to update the CERS and / or CNRS via the primary ledger 202a. In this way, data on media content consumption (e.g., consumption history, preferences, or other relevant information) can be aggregated from various entities within the user's ecosystem, and data from all different sources can contribute to the CERS and / or CNRS stored via the primary ledger 202a. Thus, each different entity can communicate with the primary ledger 202a individually, openly, and permissionless, thereby enabling the user to aggregate data across various entities that might otherwise be reluctant to share information or cooperate with each other.

[0124] As shown in Figure 5, CERS and / or CNRS data can be updated over time. This may reflect additional data newly received from one or more entities (e.g., first participating hardware provider 206a, second participating service provider 208b, etc.) following the previous entry in the primary ledger 202a (i.e., block 502b of the primary ledger 202a). In some examples, data may be collected from some or all entities for each “update” to the CERS and / or CNRS, even if no new data has been generated or acquired during that interval.

[0125] Figure 5 shows the simultaneous updating of CERS and CNRS data, but in various embodiments, these datasets may be updated individually and / or according to different schedules or trigger conditions, etc. Furthermore, although CERS and CNRS data are shown, the same architecture can be used to update additional data associated with a specific entity, including auxiliary record sets associated with media content, or data not associated with media content.

[0126] In some cases, multiple parties may submit records associated with the same event. For example, if a user plays media content streamed from a first participating service provider 208a (e.g., Spotify) via a first playback device 210a, both the first playback device 210a and the first participating service provider 208a may submit corresponding data to the primary ledger 202a to update the CERS. In this example, the first playback device 210a may capture such data, among other information that may be specific (proprietary) to the first playback device 210a and / or the first participating hardware provider 206a to which it is associated, such as media content identification information (either directly obtained or inferred), identification information of the playback device and system configuration associated with the event, and broader status information. On the other hand, the first participating service provider 208a (e.g., Spotify) may capture data about the media playback event. This data includes absolute information about content IDs, relevant media information specific to media content services (e.g., playlists or albums), broader taste or preference information corresponding to that content, and other information specific to the service provider's perspective regarding the event.

[0127] In such cases, both the first replay device 210a and the first participating service provider 208a can transmit data about the event, along with all of their own unique information about the event, for the user to be added to the CERS stored via the primary ledger 202a. In some embodiments, such entries may be automatically identified and reconcile (e.g., by using a smart contract to collect data from various entries and perform reconcile before outputting the updated CERS to the primary ledger 202a). Additionally or alternatively, a user interface may be provided that allows the user to manually interact with the CERS (or CNRS or other data stored on-chain). This interface may include tools for the user to indicate potentially duplicate entries, and options for performing reconcile by merging entries, deleting one of the entries, or otherwise reconcile two. In operation, such reconcile may take the form of the CERS being updated when it is next written to the primary ledger 202a. Furthermore, while the primary ledger 202a can maintain an immutable history of the previous state of the CERS, users querying the primary ledger 202a to access the CERS can access updated versions that reflect the alignment. In addition, in some embodiments, in addition to the edited version, a “raw” unedited and / or unaligned version of the CERS data (or CNRS or other data) may be maintained. In some cases, different versions of the data may be used in different ways and for different applications.

[0128] In various embodiments, individual participating entities (e.g., participating user 204, hardware provider 206, playback device 210, etc.) can interact with the primary ledger 202a directly or through one or more intermediates. In some examples, the use of intermediates can simplify or improve the user experience by managing on-chain interactions on behalf of the user or other participating entities. Furthermore, because blockchain data storage can be expensive and inefficient, it may be useful to maintain at least some of the relevant data through intermediate computing devices and write that data directly to the primary ledger 202a periodically, in whole or in part. In at least some cases, access through intermediates also provides users with more granular control over data permissions. For example, a record set may ultimately be maintained in the primary ledger 202a (or by ultimate reference), while in some examples, user data may be stored through intermediate devices that are not accessible to the public. Because public blockchains are generally transparent and permissionless, and all data written to them can be made visible, it may be beneficial to provide a mechanism for disclosing only selected user data to external observers.

[0129] For example, an individual playback device (e.g., a first playback device 210a) can directly interact with the primary ledger 202a itself to contribute data to the CERS and / or CNRS data stored on-chain. In another example, a participating provider (e.g., a first participating hardware provider 206a) can interact with the on-chain record set on behalf of a playback device (e.g., a first playback device 210a) and / or a user that is part of the participating provider's platform. In such an example, the first participating hardware provider 206a can process the information in batches (e.g., hourly, daily, weekly, or event-driven), thereby reducing the cost of interacting with the primary ledger 202a. In various embodiments, the first participating hardware provider 206a can perform updates continuously or in response to instructions from a user or other network entity. In some examples, user instructions may be provided by prompts in a user interface presented to the user via the platform (e.g., a control device associated with the media playback platform 206b) or in response to other user activity.

[0130] In some cases, due to privacy concerns or considerations of cost and efficiency, it may be impractical or undesirable to directly store all relevant user data on the primary ledger 202a. In such scenarios, the data may be stored via a secondary ledger 202b, which is kept private by the first participating hardware provider 206a or other participating entity. Optionally, the secondary ledger 202b may be configured to allow access to user data only by using the same secret key that users or other entities use to access user data stored via the primary ledger 202a. Alternatively, a separate peer-to-peer network (e.g., InterPlanetary File System (IPFS)) may be used for storing data, including CERS and CNRS data. In yet another embodiment, a participating entity may function as an identity hub for storing encrypted user data associated with DID. As previously mentioned, the identity hub can enable granting or revoking permissions for specific entities or applications, providing the owner with fine-grained control over who can access the stored information. This allows participants to selectively disclose relevant information from their identity hub to the primary ledger 202a (for example, by selecting only specific media consumption events to disclose, or only specific device or platform information). In the example, any appropriate participant can function as an identity hub. In a particular example, a dedicated intermediate service device 211 functions as an identity hub to enable fine-grained control over which user data is disclosed to the primary ledger 202a.

[0131] In an example where an individual regeneration device 210a implements an identity hub (or other local storage service that can communicate with the distributed ledger 202), such a regeneration device 210a can store data associated with a particular user. Other data similarly associated with that particular user may be stored via a second regeneration device (e.g., another regeneration device in the same home). In some examples, data may be stored redundantly across multiple regeneration devices associated with the user. Data may also be stored on regeneration devices owned and / or controlled by a particular user, while simultaneously being stored by a provider (e.g., a cloud service provider). Any of these storage examples could be a primary or secondary repository of user data, depending on the desired configuration. In some cases, one instance may be accessible via the distributed ledger 202, while other instances may only function as offline backups that can be restored to an online system as needed.

[0132] Using an identity hub (for example, implemented as an intermediate device 211) or other appropriate approach, participants (e.g., end users 204) can choose to make their data (e.g., a record set 212 (Figure 2)) completely private, publicly accessible, available, or otherwise aggregated under a high degree of control. Thus, users can enjoy the benefits provided by making their data available. These benefits include mutual benefits from participating in experiences enabled by data aggregation, "unlocking" various benefits offered by other participants (e.g., exclusive access to certain media content), and even direct (on-chain) payments for access to the user's data (among many other potential examples). In some embodiments, participants can selectively make their data (e.g., CERS, CNRS, or other data) available to specific participants (e.g., providers, end users, etc.). Furthermore, data can be made accessible with varying degrees or tiers of access rights; for example, some users (spouses or friends) may be given full access, while other participants (e.g., media content services) may be given only limited access.

[0133] In various cases, CERS data maintained by a given participating hardware provider, service, or platform may remain proprietary to that participating entity. This configuration may provide individual providers with the ability to tailor the nature of their interaction with the primary ledger 202a to their specific interests and business objectives. However, in at least some cases, once a version of the data is added to the primary ledger 202a (e.g., written to a block on the blockchain as CERS data, CNRS data, or other such data), the transmitted data belongs to the associated user. For example, the associated user may freely access, transfer, and / or modify the data in any way they deem appropriate and without any restrictions imposed by other entities (e.g., by adding further data to the record via the primary ledger 202a).

[0134] In various embodiments, each hardware provider, platform, service provider, or other participant may provide user tools or interfaces to enable users to manage their own data (e.g., to and from the primary ledger 202a, or to and from intermediate devices that store the data). For example, the user may be prompted to approve the updated data before it is sent to the primary ledger 202a for incorporation into the CERS data.

[0135] Optionally, a given end user may have multiple different identifiers, which may be maintained separately or linked to one another according to the user's preferences. For example, a user may want to have a first identifier associated with family media content enjoyed by all members of the household, and a second identifier associated with personal media content that the user enjoys but the rest of the household does not. In various embodiments, different identifiers may have different functions, rights, restrictions, or other configurations, depending on their designation. For example, a fully public identifier may be associated with immutable and fully viewable public data. In contrast, a fully private identifier may be fully editable, while only selected aspects are publicly accessible to external observers. As described above, a user may optionally link and / or transfer data, which are such associated identifiers. Among the examples, a user may have an identifier that explicitly corresponds to a real-world identity (e.g., the user's real name), or it may be a pseudonymous identifier. Furthermore, a given individual may have or operate multiple identifiers (e.g., a personal ID as a consumer, a second personal ID as a social influencer or tastemaker, an artist ID as a content creator, and / or a business ID as a service or hardware provider). In various examples, multiple different entities (e.g., participants in System 200) may assist in verifying or otherwise validating a given user ID. Verification and / or validation can enhance inter-service interaction by correlating interactions (e.g., Spotify and Sonos may each have separate and independent verification processes, but the user can benefit from each, and the resulting ID benefits from both). In some embodiments, such identifiers may be included as metadata to be recorded in the record set (e.g., who is viewing / listening, which user profile is accessing a given content, etc.).

[0136] Figures 6–9 are flowcharts of exemplary methods 600, 700, 800, and 900 for accessing and / or updating content record data via a distributed ledger. Methods 600, 700, 800, and 900 may be implemented by any of the devices or systems described herein (e.g., System 200, or entities described herein, e.g., Participating User 204, Hardware Provider 206, Service Provider 208, and / or Replay Device 210), or by any other devices or systems currently known or to be developed later. Various examples of methods 600, 700, 800, and 900 include one or more operations, functions, or actions indicated by blocks. Although the blocks are illustrated in order, these blocks may be executed in parallel and / or in an order different from the order disclosed and described herein. Also, various blocks may be combined into fewer blocks, split into additional blocks, and / or deleted, depending on the desired implementation.

[0137] In addition, for methods 600, 700, 800, 900, and other processes and methods disclosed herein, flowcharts illustrate the functionality and operation of possible implementations of several examples. In this regard, each block may represent a module, segment, or portion of program code containing one or more instructions executable by one or more processors for implementing a particular logical function or step in a process. Program code may be stored in any type of computer-readable medium, such as a storage device including, for example, a disk or hard drive. Computer-readable mediums may include non-temporary computer-readable mediums, such as tangible non-temporary computer-readable mediums that store data for short periods, such as register memory, processor cache, and random access memory (RAM). Computer-readable mediums may also include non-temporary mediums such as secondary or persistent long-term storage devices, such as read-only memory (ROM), optical or magnetic disks, and compact disk read-only memory (CD-ROM). Computer-readable mediums may also be any other volatile or non-volatile storage systems. Computer-readable mediums may be considered, for example, computer-readable storage media or tangible storage devices. In addition, for the methods and other processes and methods disclosed herein, each block in Figures 6 to 9 may represent a circuit wired to perform a specific logical function in the process.

[0138] Referring to Figure 6, method 600 begins at block 602, which involves accessing data stored via a distributed ledger. In various implementations, data may be stored (in whole or in part) directly on the distributed ledger, or data may be stored via other devices (e.g., intermediate devices, user devices, etc.) with pointer data stored directly on the distributed ledger. The distributed ledger may be a public blockchain such as Ethereum, Bitcoin, or Solana, or optionally a private or semi-private blockchain, or a non-blockchain ledger, as described above. In various examples, the data may include any of the record sets already described herein (e.g., Content Experience Record Set (CERS), Content Network Record Set (CNRS), Auxiliary Record Set, etc.). As described above, there are cases where such data is stored directly on the distributed ledger itself, and other instances where the blockchain stores a pointer (e.g., a URL or URI) that points to the location where the data is stored.

[0139] In block 604, method 600 includes playing media content based at least in part on accessed data. For example, the accessed data may include specific media content (e.g., audio data stored via an NFT, or a pointer to media content stored elsewhere, or a playlist of media content), in which case block 604 may include playing that specific media content. In some examples, the accessed data obtained in block 602 may include specific content preferences, such as equalization settings, brightness or color settings (in the case of visual content), or other such playback settings. In such cases, the media played in block 604 may be played using settings or other playback characteristics informed by data stored via a distributed ledger, or using settings or other playback characteristics seeded by distributed ledger data and generated in real time.

[0140] Figure 7 illustrates exemplary method 700, which begins in block 702 with the reception of an indication of a content consumption event. Examples of appropriate content consumption events include starting or changing media playback, changing a media content playlist, or any other activity associated with a user's consumption of media content. In some examples, the indication of such an event may be obtained by the same playback device involved in the event (e.g., the playback device the user went through when starting playback of a particular song). Alternatively, the indication of such an event may be obtained from a different device. For example, a control device associated with a media playback system may detect a content consumption event and send its indication to a different network device, such as a blockchain-integrated network device.

[0141] In block 704, method 700 includes adding data to a distributed ledger based at least in part on the received indication. As previously mentioned with respect to Figure 5, a Content Experience Record Set (CERS) may be stored, maintained, and / or updated via one or more distributed ledgers. Among other examples, a blockchain-integrated network device (e.g., a suitable playback device or other computing device) may have data reflecting a content consumption event written to the distributed ledger in a manner such as updating the CERS, appending data to the CERS, or otherwise adding data to the distributed ledger. In various examples, the data may be written directly via the network device (e.g., a blockchain-integrated playback device) that received the indication in block 702. Alternatively, the data may be provided to one or more intermediates, which may write the data to the distributed ledger.

[0142] Referring to Figure 8, Method 800 begins in block 802 with the reception of an indication of a Content Network event. A Content Network event may include any changes to various data associated with the Content Network Record Set (CNRS) described above. Examples of a suitable Content Network event include: a new association of a user with a particular media playback platform, content service, audio service, or playback device; the addition of a playback device to the user's media content platform and / or home; any changes to the grouping or joining of the user's playback devices; the use of a new network ID by the user to access media content; changes to playback settings (e.g., equalization, brightness, or other visual changes for video playback); or any other changes to data that may be stored via the corresponding Content Network Record Set (CNRS) associated with the user. In some examples, the indication of such an event may be obtained by the same device that was involved in the event (e.g., the control device used when the user associated a new media content service with their media playback system). Alternatively, the indication of such an event may be obtained from a different device.

[0143] In block 804, method 800 includes adding data to a distributed ledger based at least in part on the received indication. As previously mentioned with respect to Figure 5, the CNRS may be stored, maintained, and / or updated via one or more distributed ledgers. Among other examples, a blockchain-integrated network device (e.g., a suitable playback device or other computing device) may have data reflecting a content network event written to the distributed ledger in a manner such as updating the CNRS, appending data to the CNRS, or otherwise adding data to the distributed ledger. In various examples, the data may be written directly via the network device (e.g., a blockchain-integrated playback device) that received the indication in block 804. Alternatively, the data may be provided to one or more intermediates, which may write the data to the distributed ledger.

[0144] Figure 9 illustrates another exemplary method 900 in which a single aggregation regeneration device can collect information from various different transmitting regeneration devices and then update a distributed ledger based on the aggregated information. As illustrated, method 900 begins in block 902 with the aggregation regeneration device receiving first content information from a first transmitting regeneration device. Then, in block 904, the aggregation regeneration device receives second content information from a second transmitting regeneration device. The content information may include, but is not limited to, the data types related to CERS described above with respect to Figure 3, any appropriate information.

[0145] In the example, the aggregation regeneration device, the first transmitting regeneration device, and / or the second transmitting regeneration device may be located within the same environment (e.g., the same home, as part of the same regeneration network, connected via a local area network, or other such association). Additionally or alternatively, at least one of the first transmitting regeneration device or the second transmitting regeneration device may be located remotely from the aggregation regeneration device (e.g., connected via a wide area network connection).

[0146] In block 906, the aggregated playback device stores the first and second content information. In various embodiments, this data storage may include local storage on the aggregated playback device itself, storage via other local devices on the same local network, remote storage via a cloud server, or storage using a private or semi-private distributed ledger (e.g., a private blockchain as described above).

[0147] Method 900 continues to block 908 and includes adding data to a distributed ledger based at least in part on the stored first and second content information. As previously mentioned with respect to Figure 5, CERS (or other content information) may be stored, maintained, and / or updated via one or more distributed ledgers. Among the examples, an aggregated regeneration device may be a blockchain-integrated network device (e.g., a suitable regeneration device or other computing device) that causes data reflecting the first and second content information to be written to the distributed ledger in a manner that updates, appends to, or otherwise adds data to the distributed ledger. In various examples, data may be written directly via the aggregated regeneration device. Alternatively, data may be provided to one or more intermediates, which may write the data to the distributed ledger.

[0148] f. Example of exporting user data using a distributed ledger The use of distributed ledgers can improve the usability of user data associated with media services and / or facilitate its export, potentially leading to improvements in both data portability and user management of personal information. As mentioned above, blockchain-enabled user data management allows users to manually submit their past media consumption data to a blockchain-based record set, thereby increasing data interoperability across various streaming services.

[0149] Modern streaming platforms typically offer users the ability to download a wide range of personal data related to their use of the service. For example, a given service may provide “account data” and “extended streaming history,” and / or other such similar app usage information. This data typically includes a wide range of information, such as listening history, playlists, search queries, libraries, following information, payments, user data (e.g., username, email, location, etc.), favorited content, customer service history, reasoning information, voice input, and user interactions. Any of this information (or other such information related to user interactions with media content services) may form part of the user’s CERS or CNRS as described above.

[0150] The process of sending this data to a blockchain record set may involve several steps. First, a user can download their personal data from the streaming service platform. This downloaded data (often in a format like JSON) then undergoes transformation and extraction processes to conform to the format of the blockchain record set. This step can generally involve curating or conditioning the downloaded data, which may include, for example, extracting only the information that maps to available records, transforming the data from its original format to a blockchain-compatible format, and tailoring the transformation process to each specific service to accommodate variations in data structure and content.

[0151] The user can then submit the downloaded and / or converted data to a blockchain record set through a designated interface. The system may store a conditioned / cleaned version of the data conforming to a standard record set, and / or a "raw" version of the original data for storage purposes. Among other things, this process may include additional unique information not directly related to playback events, such as content added to the user's library over time, locally downloaded content, details of user-created playlists, artists and other users "liked" or "followed," search query history, and audio request history for content.

[0152] This approach allows users to directly contribute their listening history to their own CERS and / or CNRS, rather than relying solely on submissions made by the service. Submitted data can be combined with or used to complement information from other sources, including data submitted directly by the service provider. This aligns with various data portability laws and regulations around the world, including, for example, the data portability requirements of GDPR, and can help eliminate data silos that exist between different content services by enabling users to transfer their personal data for use with other services. Furthermore, the use of blockchain technology in this context can ensure that submitted data is securely stored, immutable, and accessible across different platforms. This gives users greater control over their personal data and enables them to maintain a more comprehensive and portable record of their media consumption history.

[0153] g. Exemplary methods for managing additional data via a distributed ledger In addition to, or as an alternative to, the technology of using a distributed ledger to manage users' media content consumption data as described above, aspects of this technology can be usefully applied to other contexts such as reputation management, rights management, and / or artist compensation management. For example, in addition to, or as an alternative to simply recording data, a distributed ledger can be used to enable participation in actual content experiences. An example of this is maintaining records of ownership of content or other digital assets (e.g., media content owned by a user, supplementary content associated with media content, etc.). Such ownership may be reflected in tokens held by the user (e.g., tokens protected by a private key held by the user, tokens held in the user's wallet, etc.). In some examples, holding a particular token (e.g., an NFT or other token) may be a requirement for accessing a particular experience or content.

[0154] In some embodiments, a user may wish to broadcast their user data stored in a distributed ledger. For example, this could be when sharing curated playlists with followers, when an artist shares content, or for other purposes. Optionally, CERS data may record and / or maintain personally curated content such as playlists, and may also maintain records of how much such playlists have been accessed by others.

[0155] In an additional embodiment of this technology, the interaction with the distributed ledger described herein may be used to facilitate rights management and related artist compensation for the use of underlying media content. For example, user data related to content consumption (e.g., CERS data) may be used to build and / or manage a platform for paying artists compensation based on the number of plays, based on viewing (and / or browsing) information. Such a platform may be built and / or managed by a participating hardware provider. Additionally or alternatively, such a platform may be built as a DAO. In this case, automated input regarding media consumption events may be sent to a relevant smart contract, which may trigger the transfer of tokens (e.g., cryptocurrency) to execute payments from listeners (or other participating entities) to artists.

[0156] As another example, participants (e.g., individual users) could build their own systems for sending payments or tips to artists they frequently watch. For instance, a user might choose to add the equivalent of $100 worth of cryptocurrency to the platform annually, and this amount could be used to pay or tip specific artists based on a percentage corresponding to their total cross-platform viewing history.

[0157] As the availability of on-chain data related to content consumption, content networks, etc., increases, it may be beneficial to provide artists, labels, and other commercial entities with analytical services that evaluate and / or monitor content activity (recorded by users who choose to share their data), offering additional insights into listening preferences and trends. Such analytical services may be operated by participating entities such as hardware providers or service providers. Because such data can capture user behavior across a range of platforms and services, the resulting analytics may provide a more accurate and comprehensive view of user engagement with specific content.

[0158] In an additional embodiment of this technology, an interface for artists may be provided to enable artists to provide supplementary content to their fans. Such supplementary content may include, for example, exclusive media content that the artist wishes to share only with selected fans (e.g., artist interviews, alternative versions of media content, accompanying visual artwork, etc.). Access may be gated via a distributed ledger as described above. For example, a participating entity may access the supplementary content only if it proves ownership of the corresponding token (e.g., an NFT) or ownership of a particular album or other content item. A participating hardware provider, service provider, or other participating entity may provide an interface that allows artists to easily upload supplementary data, which is then stored on-chain and restricted to access only through designated users. In some examples, this can be achieved using smart contracts as described above.

[0159] While this document describes exemplary configurations, applications, and use cases related to the use of distributed ledgers for maintaining, storing, updating, and / or accessing user data (e.g., content experience data, content network data, and / or any other suitable data), the technology can be extended to other configurations (e.g., using other types of publicly or semi-publicly accessible data structures other than blockchain or distributed ledgers). In addition, the technology can be extended to applications beyond media content consumption, such as maintaining, accessing, and owning other user data that reflects real-world activities, other online activities, or both.

[0160] Another exemplary use case for blockchain-enabled playback devices involves verifying one or more aspects of blockchain data, such as verifying the data's origin (probance), confirming that the data originated from a human, verifying consistency with other data sources, or other such data verification. As blockchain-enabled playback devices increasingly rely on distributed ledger data for personalized experiences and content management, verifying the origin of this data becomes increasingly important. Leveraging blockchain data makes it possible to verify that the data originates from a known and desired source. This verification process can be particularly important in distinguishing data generated from real-world human sources from data generated by machine learning or AI systems, which may be particularly desirable in applications where such data is used to train AI models. The proliferation of AI-generated synthetic data is becoming an increasingly significant concern. In the near future, the ratio of AI-generated data to human-generated data is predicted to reach 10:1 to 1000:1. This large gap highlights the critical need for robust verification mechanisms to authenticate human-derived data, and blockchain technology is well-suited to address this problem.

[0161] To address these challenges, blockchain-enabled playback devices can implement various strategies for verifying the origin of data when acquiring or storing blockchain-based information. One approach involves verifying that the data is cryptographically signed with the private key of a known and trusted individual or entity. This digital signature serves as proof of the data's origin and integrity, linking the data to a specific identity within the blockchain ecosystem.

[0162] Additionally or alternatively, blockchain-enabled playback devices may incorporate mechanisms for verifying the authenticity of data through specific representations or attestations. These may include explicit declarations of the data's authenticity, or detailed metadata about its origin, such as timestamps, location data, or information about the generation process. Such attestations may be directly encoded in the blockchain transaction or smart contract associated with the data.

[0163] The verification process can be applied not only to data directly stored on the blockchain, but also to centrally stored data that uses blockchain-based signatures or proofs to verify its origin. In the latter case, even when the data itself is off-chain, the blockchain functions as a decentralized and immutable ledger of data authenticity.

[0164] By implementing these source verification mechanisms, blockchain-enabled playback devices can ensure the integrity and authenticity of the data they use for personalization, content recommendations, and other critical features. This approach not only enhances the reliability of the media playback experience but also contributes to a broader ecosystem of trusted and verifiable data for use in various contexts.

[0165] As another example, blockchain technology can be used to verify software activation licenses and usage, for example, in the context of media codecs and specialized playback standards. For instance, a blockchain-based system may be implemented to verify and record the use of proprietary audio technologies, such as Dolby Atmos, in consumer devices like soundbars. In this scenario, each decoding event, such as the playback of home theater content using the Dolby Atmos standard, can be recorded as a transaction on a distributed ledger. This immutable record can serve as proof that a particular device was lawfully licensed and actively used the technology. Software providers like Dolby can use this blockchain-based verification system to track usage, ensure compliance with license agreements, and potentially implement more flexible usage-based licensing models. A similar approach can be utilized in encoding scenarios. In addition, the system can provide consumers with transparency regarding the functionality and usage of their devices, while providing manufacturers with a tamper-proof method to demonstrate compliance with licensing requirements.

[0166] IV. Blockchain-enabled playback devices with generation components In some implementations, a blockchain-enabled playback device may further include a generating media component and / or a generating context and control component. In various examples, each of these components may receive input from a blockchain or other distributed ledger and / or write output to a blockchain or other distributed ledger. Figure 10 shows a schematic diagram of a blockchain-enabled playback device 1000, which may include three component groups: a distributed ledger component 1002, a generating media component 1004, and a generating context and control component 1010. These components may work together, for example, by sharing information with each other and with one or more blockchains, to generate a personalized and responsive media playback ecosystem that leverages both on-chain data and real-time contextual information.

[0167] The distributed ledger component 1002 facilitates interaction with one or more blockchain networks (as described herein) and enables the device to access, store, and update data on the distributed ledger. This functionality allows the playback device to maintain and / or utilize a distributed record of user preferences, listening history, and other relevant data. In various implementation embodiments, the distributed ledger component 1002 may be used to interact with one or more generative components, such as an artificial intelligence inference model implemented by the playback device or by a media playback system including the playback device. Such an artificial intelligence inference model may use the distributed ledger component 1002 to take input from a blockchain or other distributed ledger and / or write output to a blockchain or other distributed ledger.

[0168] The generating media component 1004 includes a generating media module 1006 capable of generating novel synthetic generated media content 1008. These components can leverage artificial intelligence algorithms and models to generate or modify media content in real time, providing users with a unique, dynamically generated listening experience. Further details regarding preferred generating media components can be found in international patent application PCT / US2021 / 072454, filed November 17, 2021, entitled “Playback of Generative Media Content,” which is incorporated herein by reference for all purposes.

[0169] The generation context and control component 1010 encompasses various applications and services that notify and guide the behavior of the playback device or other components of the media playback system including the playback device. These include a positioning system application 1012 with a common positioning API 1014, and a localization application 1016. The generation context and control component 1010 may further include a personalization service 1018. These components work together to analyze the device environment and user behavior, enabling context-aware adjustments to both the generated media output and the overall playback experience. In various examples, the generation context and control component 1010 may provide output in the form of system recommendations relating, for example, to media playback, the configuration of the media playback system, or the user's environment, the media playback system, or other aspects of those components. Further details regarding preferred generation contexts and control components can be found in U.S. Provisional Application No. 63 / 516,343, filed on 28 July 2022, entitled "Personalization Techniques for Media Playback Systems," which is incorporated herein by reference for all purposes.

[0170] Interactions between these component groups enable the blockchain-enabled playback device 1000 to provide personalized and dynamic media playback. By combining secure, decentralized data management with advanced generative capabilities and context awareness, the device can generate audio experiences tailored to each user's preferences, environment, and current situation. As will be described in more detail below, the blockchain-enabled playback device 1000, which may be equipped with generative components, can use blockchain data as both input and output for its generative model, building a dynamic and interconnected ecosystem of personalized audio experiences. As input, the generative media component 1004 may utilize data stored on the blockchain, such as user preferences, listening history, and collaborative filtering data from the Content Experience Record Set (CERS), to notify the generation of new audio content. For example, the generative model may generate original music based on the user's preferred genres and artists recorded on the blockchain.

[0171] Similarly, the generation context and control component 1010 can adapt playback settings in real time using blockchain data regarding device configuration and environmental preferences. Regarding output, device 1000 can record and return metadata of the generated content, user interactions with the generated content, and performance metrics of the generation model to the blockchain. For example, if device 1000 generates a personalized playlist, the playlist structure and user engagement data can be stored on the blockchain for future reference or sharing. In addition, the device can provide improvements to the generation model itself, such as updated parameters or new training data, by recording these advancements on the blockchain for other devices to access and incorporate. This bidirectional data flow between the blockchain and the generation component can generate a system for continuously evolving and improving the personalized media content experience.

[0172] a. Exemplary generated media component The integration of both blockchain and generative media technologies could deliver highly personalized and dynamic media content experiences. For example, by leveraging data stored on a distributed ledger as input parameters for AI models such as generative AI and / or generative media models, blockchain-enabled playback devices could generate tailored content, drawing from various data sources that may be available across one or more blockchains. This approach could also enable a more personalized understanding of user preferences, listening history, and environmental factors, all of which could inform the generation process.

[0173] Blockchain data such as the aforementioned Content Experience Record Set (CERS) and Content Network Record Set (CNRS) can provide a rich source of information for generated media models. As previously mentioned, these decentralized records may include detailed histories of user interactions, preferred audio characteristics, and even collaborative filtering data from similar users. When fed into a generation algorithm, this blockchain-derived data enables the generation of media content that not only reflects individual preferences but can also incorporate broader trends and patterns observed across the network.

[0174] Additionally or alternatively, the output of a generated media model and the resulting generated media content may be recorded or otherwise stored on a distributed ledger, in whole or in part. This process can, in some cases, create a feedback loop where the generated content and associated playback data become part of the history recorded on the user's blockchain. By writing this information to a distributed ledger, the system ensures a transparent and immutable record of the generated media experience, which can then be used to further refine future content generation. This cyclical data flow between the blockchain and the generation system enables continuous improvement and personalization of the media content experience.

[0175] In some embodiments, the generated media content may include any media content (e.g., audio, video, images, audiovisual output, haptic output, text, olfactory, or any other suitable media content) that is dynamically created, synthesized, and / or modified by a non-human via one or more algorithms or models (e.g., neural networks such as transformer models or similar preferred models). This creation or modification may occur for real-time or near-real-time playback. Additionally or alternatively, the generated media content may be generated or modified asynchronously (e.g., in advance of playback being requested), and certain items of the generated media content may then be selected for playback at a later point in time. As used herein, a “generated media module” includes any system implemented in software, a physical model, or a combination thereof that is capable of generating generated media content based on one or more inputs. In some examples, such generated media content may include novel synthesized media content that can be created entirely from scratch, or created by mixing, combining, manipulating, or otherwise modifying one or more existing media contents. Throughout the discussion herein, some examples refer to audio content (e.g., music, spoken word, and / or other sounds), but the technologies disclosed herein may, in some examples, be applied to other types of media content, such as video, audiovisual, haptic, text, or others.

[0176] Figure 11 shows a system 1100 for managing the generation and playback of generated media content. As shown in Figure 11, the system 1100 includes a generated media group coordinator 1000a that communicates with at least one generated media group member 1000b. One or both of the coordinator device 1000a and the group member device 1000b can take the form of the blockchain-enabled playback device 1000 described in relation to Figure 10. Communication between devices may take place over one or more networks, which may include any suitable wired or wireless network connection, or a combination thereof (e.g., WiFi® network, Bluetooth®, Z-Wave network, ZigBee, Ethernet connection, Universal Serial Bus (USB) connection, etc.). Optionally, one or more remote computing devices may also communicate with the group coordinator 1000a and / or group member 1000b, and the remote computing devices may form part of the generated media group. In operation, these devices may communicate with each other and / or with other components (e.g., sensor data sources, control device 130, media content sources, or any other suitable data sources or components) to facilitate the generation and playback of generated media content.

[0177] In various examples, some or all of devices 1000a and / or 1000b may be located together in the same environment (e.g., the same home, store, etc.). In some examples, at least some of devices 1000a and / or 1000b may be located geographically separated from each other, for example, in different homes, in different cities, etc.

[0178] The coordinator device 1000a and / or member device 1000b may include some or all of the components of the playback devices 110, 210 or the network microphone device 120 described above with respect to Figures 1A to 1H. For example, the coordinator device 1000a and / or member device 1000b may optionally include playback components (e.g., transducers, amplifiers, audio processing components, etc.), or such components may be omitted in some cases.

[0179] In some examples, the coordinator device 1000a may be a playback device itself and may also function as a member device 1000b. In these scenarios, the coordinator device 1000a may comprise a portable playback device such as a mobile device (e.g., a smartphone, a battery-powered audio and / or video device, a laptop, or a tablet), or a wearable device such as an AR and / or XR headset or a smartwatch. In other examples, the coordinator device 1000a may be connected to one or more member devices 1000b (e.g., via a direct wired connection or via a network), but the coordinator device 1000a itself does not play generated media content. In various examples, the coordinator device 1000a may be implemented as a bridge-like device on a local network, a playback device that is not itself part of a generated media group (i.e., the playback device itself does not play generated media content), and / or a remote computing device (e.g., a cloud server).

[0180] In various examples, one or more devices may include a generating media module 1006 on top of it. Such a generating media module 1006 can generate new synthesized media content based on one or more inputs, for example, using a preferred generating media content model. As shown in Figure 11, in some examples, a coordinator device 1000a may include a generating media module 1006 for generating generated media content, which can then be sent to member device 1000b for simultaneous and / or synchronous playback. Additionally or alternatively, some or all of member devices 1000b (e.g., member device 1000b as shown in Figure 11) may include a generating media module 1006 that can be used by member device 1000b to locally generate generated media content based on one or more inputs. In various examples, the generated media content may be generated via a remote computing device using one or more input parameters optionally received from a local device. This generated media content can then be sent to one or more local devices for coordination and / or playback.

[0181] In some examples, at least some of the member devices 1000b do not include the generation media module 1006 on them. Alternatively, in some examples, each member device 1000b may include the generation media module 1006 on it and be configured to generate the generation media content locally. In at least some examples, none of the member devices 1000b do not include the generation media module 1006 on them. In such cases, the generation media content may be generated by the coordinator device 1000a. Such generation media content may then be sent to the member devices 1000b for simultaneous and / or synchronous playback.

[0182] In some examples, the coordinator device 1000a can facilitate playback of generated media content through multiple different playback devices (which may or may not include the coordinator device 1000a itself). In operation, the coordination component of the coordinator device 1000a is configured to facilitate synchronization of both the production of the generated media (e.g., using one or more generated media modules 1006 which may be distributed among various devices) and the playback of the generated media. For example, the coordinator device 1000a may send timing data to member device 1000b to facilitate synchronized playback. Additionally or alternatively, the coordinator device 1000a may send inputs, generated media model parameters, or other data related to the generated media module 1006 to one or more member devices 1000b so that member devices 1000b can produce generated media locally (for example, using a locally stored generated media module 1006), and / or so that member devices 1000b can update or modify the generated media module 1006 based on inputs received from the coordinator device 1000a.

[0183] In some implementations, the generated media module 1006 is configured to produce generated media based on one or more inputs using a generated media content model (or multiple generated models). The inputs may include sensor data, user input (e.g., received from the control device 130, or user input via direct user interaction with the coordinator device 1000a or member device 1000b), and / or media or other content sources. For example, the generated media module 1006 may produce and continuously modify generated media by adjusting various characteristics of the generated audio based on one or more input parameters (e.g., sensor data related to one or more users to devices 1000a, 1000b).

[0184] A suitable media content source may, in various examples, include one or more local and / or remote media content sources. For example, a media content source may include one or more local audio sources as described above (e.g., audio received via input / output connections, such as from a mobile device (e.g., a smartphone, tablet, laptop computer) or another suitable audio component (e.g., a television, desktop computer, amplifier, phonograph, Blu-ray player, memory for storing digital media files)). Additionally or alternatively, a media content source may include one or more remote computing devices accessible via a network interface (e.g., via communication over network 102). Such remote computing devices may include, for example, individual computers or servers such as media streaming service servers that store audio and / or other media content. Additionally or alternatively, a media content source may be a blockchain or other distributed ledger as described herein.

[0185] In various examples, the media available through the media content source may include pre-recorded audio segments in the form of a complete sound, a musical piece, a portion of a musical piece (e.g., a sample), or any audio component (e.g., pre-recorded audio of a particular instrument, a synthesized beat or other audio segment, spoken word or non-musical audio such as natural sounds). In operation, such media may be utilized by the generating media module 1006 to create new generated media content for playback through one or more devices, for example, by combining, mixing, overlapping, manipulating, or otherwise modifying the extracted media content. In some examples, the generated media content may take the form of a combination of pre-recorded audio segments (e.g., pre-recorded musical pieces, spoken word recordings, etc.) and new synthesized audio overlaid on the created pre-recorded audio. As used herein, “generated media content” or “generated media content” may include any such combination.

[0186] As described above, the generating media module 1006 may include any system capable of producing generated media content based on one or more inputs, which may be embodied in software, a physical model, or a combination thereof. In various examples, the generating media module 1006 may utilize a generating media content model which may include one or more algorithms or mathematical models that determine how media content is generated based on relevant input parameters. In some examples, the algorithms and / or mathematical models themselves may be updated over time, for example, based on instructions received from one or more remote computing devices (e.g., cloud servers associated with a music service or other entity), or based on inputs, blockchain data, or any other suitable inputs received from other group member devices in the same or different environments. In some examples, different devices within a group may have different generating media modules 1006 on them, for example, a first member device may have a different generating media module 1006 than a second member device. In other cases, each device in a group having a generating media module 1006 may include substantially the same model or algorithm.

[0187] Any suitable algorithm or combination of algorithms can be used to produce generated media content. Examples of such algorithms include those using machine learning techniques (e.g., Generative Adversarial Networks (GANs), neural networks, etc.), formal grammars, Markov models, finite-state automata, and / or any other suitable algorithm. Transformer models, originally developed for natural language processing tasks, have been successfully adapted for media generation. These models are well-suited to modeling complex audio structures because they utilize self-attention mechanisms to capture long-range dependencies within sequential data. In the context of audio generation, transformer-based architectures such as OpenAI's Jubekox have demonstrated the ability to generate multi-instrumental music with a consistent long-term structure, and even incorporate stylistic elements and rudimentary lyrics. These models can be conditioned based on various inputs, including genre, artist style, and even textual descriptions, allowing for fine-grained control over the generated audio content.

[0188] As another example, spread models are emerging as a powerful alternative for high-fidelity audio synthesis. These models work by learning to reverse the stepwise noise addition process, effectively reconstructing audio from pure noise. Notable examples in the audio domain include Google's AudioLM and Meta AI's AudioGen. Diffuse models have demonstrated exceptional ability to generate realistic ambient sounds, speech, and music. They excel at capturing fine audio details and maintaining consistency over long periods. Furthermore, spread models have shown promise in tasks such as audio generation from text and audio inpainting, where missing audio segments are naturally reconstructed.

[0189] Both transformer and diffusion models can be integrated into blockchain-enabled playback devices. By utilizing on-chain data as conditioning input, these models can generate not only high-quality audio content but also personalized audio tailored to individual user preferences and listening history. For example, a transformer model could leverage a user's CERS data to generate music that reflects that user's preferred genres, artists, and song structures. Similarly, a diffusion model could use CNRS data to synthesize ambient soundscapes tailored to a user's typical listening environment or device configuration.

[0190] Generative models can also be classified based on their data type and modeling approach. Continuous latent models like AudioLDM and RAVE employ iterative refinement techniques, while discrete latent models like MusicGen and LLM utilize next-to-token prediction or autoregressive methods. Models that directly handle raw audio data, such as MaskGIT and WaveGAN, use mask prediction and one-step generation approaches, respectively. Each of these models offers unique capabilities and trade-offs in generating audio content. For example, MusicLM and MusicGen, introduced in 2023, represent a significant advance in bridging the modality of text and music. Other notable models in the evolution of this technology include SoundStream, Encodec, CLIP, CLAP, and AudioLM from several years ago, as well as more recent developments such as Stable Audio, Suno, and UDio from 2024. In addition to audio-only models, more general-purpose (and optionally multimodal) models may be used (e.g., OpenAI's ChatGPT®, Anthropic's Claude.ai, Meta's Llama, Google's Gemini, or other suitable models).

[0191] In various applications, the generative media module 1006 can utilize either adaptive or deterministic models. Each approach offers distinct advantages in media content creation. Deterministic models follow a fixed set of rules or parameters to generate output, producing consistent results for the same input. These models are predictable and precisely controllable, making them suitable for applications where reproducibility is desired. In contrast, adaptive models dynamically adjust their behavior based on real-time feedback or changing contextual input. These models can learn and evolve their output strategies over time, potentially generating more diverse and context-aware content. In the field of generative audio, adaptive models can adjust musical elements such as tempo, harmony, or instrumentation in response to user interaction, environmental factors, or biometric data. This adaptability enables a more responsive and personalized audio experience, which may be better suited to the dynamic characteristics of blockchain-enabled playback devices. However, the choice between an adaptive and a deterministic approach often depends on the specific use case, and some applications benefit from a hybrid approach that combines elements of both model types. In various examples, the generation media module 1006 can utilize any suitable generation algorithm that currently exists or may be developed in the future.

[0192] As discussed above, producing generated media content (e.g., audio content) may involve modifying various characteristics of the media content in real time and / or algorithmically generating new media content in real time or near real time. In the context of audio content, this may be achieved by storing a large number of audio samples in a database that can be accessed remotely via a network by coordinator device 1000a and / or member device 1000b, or the audio samples may be maintained locally on devices 1000a and 1000b themselves. Audio samples may be associated with one or more metadata tags corresponding to one or more audio characteristics of the sample. For example, a particular sample may be associated with a metadata tag indicating that the sample contains audio of a particular frequency or frequency range (e.g., bass / midrange / treble), or of a particular instrument, genre, tempo, key, release date, geographical location, timbre, reverb, distortion, sonic texture, or any other audio characteristics that may become apparent.

[0193] In operation, the generating media module 1006 (for example, the module of the coordinator device 1000a and / or the second member device 1000b) may retrieve specific audio samples based on associated tags and mix the audio samples to create generated audio. The generated audio may evolve in real time as the generating media module 1006 retrieves audio samples with different tags and / or different audio samples with the same or similar tags. The audio samples retrieved by the generating media module 1006 may depend on one or more inputs from various user inputs, such as sensor data, time, geographical location, weather, or physiological inputs such as mood selection or heart rate. Thus, as the inputs change, the generated audio changes accordingly. For example, if the user selects a calm or relaxed mood input, the generating media module 1006 may retrieve and mix audio samples with tags corresponding to audio content that the user may find calming or relaxing. Examples of such audio samples may include audio samples tagged as having a low tempo or low harmonic complexity, or audio samples that have been predetermined to be calming or relaxing and tagged as such. In some examples, audio samples may be identified as calming or relaxing based on an automated process that analyzes the temporal and spectral content of the signal. Other examples are similarly possible. In any example herein, the generating media module 1006 may adjust the characteristics of the generated audio by taking and mixing audio samples associated with different metadata tags or other preferred identifiers.

[0194] Modifying the characteristics of generated audio may include manipulating one or more of the following: volume, balance, removal of specific instruments or timbres, tempo, gain, reverb, spectral equalization, timbre, or the sonic texture of the audio. In some examples, generated audio may be played differently on different devices, for example, certain characteristics of the generated audio may be emphasized on the specific playback device closest to the user. For example, the nearest playback device may emphasize a particular instrument, beat, timbre, or other characteristic, while the remaining playback devices may function as background audio sources.

[0195] As described elsewhere in this specification, the media content module 1006 may be configured to produce media intended to guide the user's mood and / or physiological state in a desired direction. In some examples, the user's current state (e.g., mood, emotional state, activity level, etc.) is monitored or measured periodically and / or iteratively (e.g., at predetermined intervals) to ensure that the user's current state is transitioning to a desired state, or at least not moving in the opposite direction to the desired state. In such examples, the generated audio content may be modified to guide the user's current state toward the final desired state.

[0196] In any example herein, the generating media module may use hysteresis to avoid abrupt adjustments to the generated audio that could negatively impact the listening experience. For example, if the generating media module modifies the media based on the user's position input relative to the playback device, the playback device may abruptly change the generated audio in one of the ways described herein if the user moves rapidly closer to or further away from the playback device. Such abrupt adjustments can be unpleasant for the user. To mitigate these abrupt adjustments, the generating media module 1006 may be configured to employ hysteresis by delaying adjustments to the generated audio for a predetermined period when user movement or other activity triggers an adjustment. For example, if the playback device detects that the user has moved within a threshold distance of the playback device, instead of immediately performing one of the adjustments described above, the playback device may wait for a predetermined time (e.g., a few seconds) before making an adjustment. If the user remains within the threshold distance after the predetermined time has elapsed, the playback device can proceed with adjusting the generated audio. However, if the user is no longer within the threshold distance after the predetermined time has elapsed, the generating media module 1006 may refrain from adjusting the generated audio. The generation media module 1006 may similarly apply hysteresis to the adjustment of other generation media described herein.

[0197] As described above, the generation media module 1006 can produce generation media based at least in part on input parameters which may include sensor data and / or other suitable input parameters. With respect to sensor input parameters, the sensor data source may include data from any suitable sensor, regardless of where it is located relative to the generation media group and whatever values ​​are measured thereby. Examples of suitable sensor data include physiological sensor data, such as data obtained from biometric sensors, wearable sensors, etc. Such data may include physiological parameters such as heart rate, respiratory rate, blood pressure, electroencephalogram, activity level, movement, and body temperature.

[0198] Suitable sensors include wearable sensors configured to be worn or carried by a user, such as headsets, watches, mobile devices, brain-machine interfaces (e.g., Neuralink), headphones, microphones, or other similar devices. In some examples, the sensor may be a non-wearable sensor or fixed to a fixed structure. The sensor can provide sensor data, which may include, for example, data corresponding to brain activity, voice, position, movement, heart rate, pulse, body temperature, and / or sweating. In some examples, the sensor may correspond to multiple sensors. For example, as described elsewhere in this specification, the sensor may correspond to a first sensor worn by a first user, a second sensor worn by a second user, and a third sensor not worn by a user (e.g., fixed to a fixed object or structure). In such examples, the sensor data may correspond to multiple signals received from each of the first, second, and third sensors.

[0199] The sensor may be configured to acquire or generate information that roughly corresponds to the user's mood or emotional state. In one example, the sensor is a wearable brain-sensing headband, which is one of many examples of sensors described herein. Such a headband may include, for example, an electroencephalogram (EEG) headband with multiple sensors on it. In some examples, the headband may correspond to one of the Muse™ headbands (InteraXon; Toronto, Canada). The sensors may be positioned at various locations on the inner surface of the headband to correspond, for example, to the user's brain anatomical structures (e.g., the frontal, parietal, temporal, and sphenoid bones). Thus, each sensor may receive different data from the user. Each sensor may correspond to an individual channel that can be streamed from the headband to system devices 1000a and / or 1000b. Such sensor data may be used to detect the user's mood, for example, by classifying the frequencies and intensities of various brain waves or by performing other analyses. Further details regarding the use of a brain-sensing headband for generated audio content can be found in international patent application PCT / US2021 / 071260, filed on 24 August 2021, entitled “Mood Detection and / or Influence Via Audio Playback Devices,” which is incorporated herein by reference in its entirety.

[0200] In some examples, the sensor data source includes data obtained from sensor data of networked devices (e.g., Internet of Things (IoT) sensors such as networked lights, cameras, temperature sensors, thermostats, presence detectors, and microphones). Additionally or alternatively, the sensor data source 218 may include environmental sensors (e.g., those that measure or indicate weather, temperature, time / day / week / month, etc.). In some implementations, the input may take the form of data from the generation context and control component 1010, which are described in more detail below. These inputs may be obtained directly from other network devices such as playback devices and / or playback device networks, and / or via a blockchain. In some examples, for instance, the input may be associated with a DAO (or possibly multiple DAOs) and stored on a blockchain ledger (or multiple ledgers). Such personalization information (e.g., media content usage patterns, localization information, recommendation engine output, etc.) may be used as input to the generation media module 1006 for the production of generated audio tailored to a specific user, environment, or context.

[0201] In some examples, the generating media module 1006 may utilize inputs in the form of playback device capabilities (e.g., number and type of transducers, output power, other system architecture), device location (e.g., location relative to other playback devices, or location relative to one or more users). Additional examples of creating and modifying generated audio as a result of user and device location are described in further detail in U.S. Patent No. 11,409,495, co-owned, issued 9 August 2022, entitled "Audio Conflict Resolution," which is incorporated herein by reference in its entirety. Additional inputs may include device states of one or more devices in a group, e.g., thermal state (e.g., generated content may be modified to reduce temperature if a particular device is at risk of overheating), battery level (e.g., bass output may be reduced in a portable playback device with low battery), and bonding state (e.g., whether a particular playback device is configured as part of a stereo pair, bonded to a subwoofer, or part of a home theater setup). Any other suitable device characteristics or states can also be used as input for the creation of generated media content.

[0202] Another exemplary input parameter includes the presence of a user. For example, when a new user enters a space where generated audio is playing, the user's presence may be detected (e.g., via proximity sensors, beacons, etc.), and the generated audio may be changed in response. This change may also be based on the number of users (e.g., ambient meditation audio if there is one user, relaxing music if there are two to four users, and party or dance music if there are more than four users). The change may also be based on the identity of the presenting users (e.g., user characteristics, listening history, or a user profile based on other such characteristics).

[0203] For example, a user may wear a biometric device that can measure various biometric parameters, such as heart rate or blood pressure, and report those parameters to devices 1000a and / or 1000b. The generating media module 1006 of these devices 1000a and / or 1000b can use these parameters to further adapt the generated audio, for example, by increasing the tempo of the music in response to the detection of a high heart rate (which may indicate that the user is engaged in an activity involving strenuous movement) or decreasing the tempo of the music in response to the detection of high blood pressure (which may indicate that the user is stressed and may benefit from calming music).

[0204] In yet another example, one or more microphones in a playback device (e.g., microphone 115 in Figure 1F) may detect the user's voice. The captured voice data can then be processed for, for example, determining the user's mood, age, or gender, identifying a specific user from among multiple users in a household, or for any other such input parameters. Other examples are similarly possible.

[0205] As shown in Figure 11, various types of interactions can exist between the coordinator device 1000a and the member device 1000b. The interactions and processes described herein may be applied to interactions involving multiple additional coordinator devices 1000a and / or member devices 1000b. As shown in Figure 11, the coordinator device 1000a includes a generating media module 1006a that receives inputs including input parameters 1102 (e.g., sensor data, media content, model parameters for the generating media module 1006a, blockchain data (e.g., CERS or CNRS data), or other such inputs) and clock and / or timing data 1104. In various examples, the clock and / or timing data 1104 may include synchronization signals to synchronize playback and / or to synchronize the generated media being produced by various devices in the group. In some examples, the clock and / or timing data 1104 may be provided by an internal clock, processor, or other such component housed within the coordinator device 1000a itself. In some examples, the clock and / or timing data 1104 may be received from a remote computing device via a network interface.

[0206] Based on these inputs, the generating media module 1006a may output generated media content 1008a. Optionally, the output generated media content 1006a may itself function as input to the generating media module 1006a in the form of a feedback loop. For example, the generating media module 1006a may produce subsequent content (e.g., audio frames) using a model or algorithm that at least partially depends on previously generated content.

[0207] In the illustrated example, member device 1000b similarly includes a generating media module 1006b, which may be substantially the same as the generating media module 1006a of coordinator device 1000a, or may differ in one or more embodiments. The generating media module 1006b may similarly receive input parameters 1102 and clock and / or timing data 1104. These inputs may be received from coordinator device 1000a, from other member devices, from other devices on the local network (e.g., a locally networked smart thermostat providing temperature data), and / or from one or more remote computing devices (e.g., a cloud server providing clock and / or timing data 1104, or weather data, or any other such input). Based on these inputs, the generating media module 1006b may output generated media content 1008b. This produced generated media content 1008b may optionally be fed back to the generating media module 1006b as part of a feedback loop. In some examples, the generated media content 1008b may include, or be composed of, generated media content 1008a (produced via the coordinator device 1000a) and transmitted to the member device 1000b via the network. In other cases, the generated media content 1008b may be produced independently and separately from the generated media content 1008a produced via the coordinator device 1000a.

[0208] The generated media contents 1008a and 1008b can then be played back via devices 1000a and 1000b themselves and / or by other devices in the group. In various examples, the generated media contents 1008a and 1008b may be configured to be played back simultaneously and / or synchronously. In some cases, the generated media contents 1008a and 1008b may be substantially identical or similar to each other, with each generated media module 1006 utilizing the same or similar algorithms and the same or similar inputs. In other cases, the generated media contents 1008a and 1008b may be different from each other, while remaining configured for synchronous or simultaneous playback.

[0209] b. Exemplary generation context and control components Figures 12 and 13 provide additional details regarding the interaction between the generation context and control components and blockchain data in a blockchain-enabled playback device. The generation context and control component 1010 (Figure 10), including localization and positioning system applications, can both retrieve data from and provide data to the blockchain source. This bidirectional flow of information enables dynamic interaction between historical and persistent data stored on-chain and real-time, dynamic data generated by the playback device and its environment.

[0210] Localization and positioning system application data may be supplied from the blockchain and may form its own distinct “set of records” within the broader blockchain ecosystem. This data can be used in combination with information stored locally on a device, information on other devices within the same home / network, information on devices associated with a community and / or DAO, or information in conventional cloud storage. For example, a user’s playback and listening history or media environment configuration may be retrieved from the blockchain (e.g., by accessing CERS or CNRS) to provide a comprehensive and portable record of preferences and behavior. On the other hand, current device positioning information, which may require higher confidentiality and real-time accuracy, may be stored locally within the home network for improved privacy and reduced latency.

[0211] In some implementations, sensitive and personal information can be stored on-chain, provided appropriate privacy protection technologies are employed. For example, zero-knowledge proofs can be used to verify specific attributes or conditions without revealing the underlying data, allowing users to enjoy the benefits of blockchain-based data management while maintaining their privacy.

[0212] Interaction between blockchain data and generation context and control components enables a more personalized approach to media playback. In an exemplary approach, historical data from the blockchain can inform long-term preferences and patterns, while real-time context data enables immediate responsiveness to the user's current environment and situation. In some examples, context data and / or input data may be collected and shared between devices within the MPS100 to support generation context and control operations. A suitable example of context data can be found in international application PCT / US2022 / 077185, filed on 28 September 2022, entitled "Spatial Mapping of Media Playback System Components," which is incorporated herein by reference for all purposes.

[0213] In some implementations, generative models are used for contextual and control purposes, as will be described in more detail below. Further details regarding preferred generative models can be found in international patent application PCT / US2024 / 029969, filed on 17 May 2024, entitled "Learned Device Targeting," which is incorporated herein by reference for all purposes.

[0214] Further details regarding the mapping of contextual or environmental data relating to subscriber devices can be found in International Patent Application PCT / US2024 / 026459, filed on 26 April 2024, entitled “Providing Miidscapes and Other Media Experiences,” which is incorporated herein by reference in its entirety for all purposes. As an example, such data relating to the mapping of provider contextual or environmental data relating to subscriber devices may be stored via a distributed ledger (e.g., as part of CERS or CNRS). The use of blockchain enables verified experiences, allowing individual subscribers to verify and trust that the simulated moodscape at their location corresponds to the provider's moodscape (optionally in real time). Additionally or alternatively, to facilitate the creation of suitable moodscapes as described in the aforementioned application, personalization models (as described in more detail below) may be used to tailor the moodscape to the listener's context and environmental conditions.

[0215] In certain embodiments, a positioning system may be implemented to determine the relative positioning of devices in an environment and, optionally, to control or modify the behavior of one or more devices based on their relative position. Positioning information or localization information can be obtained through various technologies, and in some cases optionally, using sensors, examples of which are listed below. In certain examples, one or more devices within the MPS100, such as one or more blockchain-enabled playback devices 1000, playback device 110, NMD120, or control device 130, may host a localization application that can implement the ability to process localization information to improve the user experience in the MPS100. Examples of such functions include advanced acoustic manipulation (e.g., functions directed towards psychoacoustic effects during audio playback) and autonomous device configuration / reconfiguration (e.g., functions directed towards detecting and configuring new devices or devices that have been moved or otherwise modified in any way). The requirements these functions impose on localization information vary; some require low-latency and high-precision localization information, while others can operate using high-latency and low-precision localization information.

[0216] In a particular example, a positioning system may be implemented within the MPS 100 using various different devices to generate localization information utilized by several application functions. However, the number, arrangement, and configuration of these devices may vary from example to example. Additionally or alternatively, the communication technologies and / or sensors employed by the devices may vary. In consideration of these many variables within any particular MPS, and the inefficiencies that this variability imposes on the development and maintenance of MPS application functions, some examples disclosed herein utilize one or more blockchain-enabled regeneration devices 1000, 110, NMD 120, or control devices 130 to implement a positioning system using a common positioning application programming interface (API) that decouples positioning / localization information from specific devices or underlying activation technologies, as conceptually shown in Figure 12.

[0217] Referring to Figure 12, any one or more blockchain-enabled playback devices 1000, 110, NMD 120, or control device 130 ("MPS devices") within the MPS 100 may host the positioning system application 1200. In certain embodiments, one or more remote computing devices may facilitate the hosting of the application. The positioning system application 1200 implements an application programming interface (API) that exposes positioning / localization information and associated metadata to the MPS application function 1202. The MPS function 1202 may include various functions related to various user experiences and modes of operation of the MPS 100. For example, the MPS function 1202 may include one or more VAS functions 1204, such as a speech disambiguation function or an arbitration function between different NMDs receiving the same speech input. The MPS function 1202 may also include one or more MPS and / or device configuration functions 1206, such as automatic home theater configuration or reconfiguration, dynamic accommodation of portable playback devices in a home theater environment, dynamic room assignment for portable playback devices or their associated docks, and context-aware orientation of the control device 130. The MPS function 1202 may further include one or more other functions 1208 that use positioning / localization information. To support these and other MPS functions 1202, positioning / localization information may be used to determine various information relating to the location of MPS devices in an environment. For example, positioning / localization information may be used by several MPS functions 1202 to track which playback devices 110 or NMD 120 are in a particular room or space (e.g., which playback devices are in living room 101f, which room playback device 110d is in, or which playback device 110 is closest to the control device 130).Positioning / localization information can be further used to determine the distance and / or direction between playback devices 110 (with varying levels of precision), or to determine the acoustic space around the NMD 120 or playback devices 110 equipped with an NMD (e.g., which playback device 110's sound can be heard from the NMD 120a). Thus, positioning / localization information can be used to determine information regarding the topology of the MPS 100 within the environment 101, which can then be used to automatically and dynamically generate or modify the user experience on the MPS 100 and support the MPS functions 1202.

[0218] The positioning / localization information and metadata published by the positioning system application 1200 may vary depending on the needs of the underlying communication technology and / or sensor function 1210 and / or specific MPS function 1202 within the MPS device used to acquire the information. For example, a specific MPS device may have one or more network interfaces supporting one or more of the following: Bluetooth® 1212, WiFi® 1214, or ultra-wideband (UWB) technology (UWB 1216, short-range radio frequency communication technology). Furthermore, a specific MPS device may be equipped to support acoustic signaling 1218, ultrasound 1220, or signaling via other signaling and / or communication means 1222. A specific technology 1210 may be suitable for a specific MPS function 1202, while other technologies may be more useful in other situations. For example, UWB1216 can provide high-precision distance measurement, while WiFi1214 (e.g., using RSSI signal strength measurement) or ultrasound1220 can provide “room-level” topology information (e.g., presence detection indicating that a particular MPS device is in a particular room or space in environment 101). In some examples, a combination of different techniques 1210 may be used to improve the accuracy and / or certainty of the information derived from positioning / localization information received from one or more MPS devices via a positioning system application 1200. For example, in some cases, as will be further described below, presence detection may be performed primarily using ultrasound1220, but RSSI measurement may be used to confirm the presence detection and / or to provide more accurate localization information in addition to the presence detection.

[0219] Examples of MPS devices with ultrasonic presence detection are disclosed in U.S. Patent Application Publications 2022 / 0066008 and 2022 / 0261212, each incorporated herein by reference in whole for all purposes. An example of localizing an MPS device based on RSSI measurement is disclosed in U.S. Patent Application Publication 2021 / 0099736, which is incorporated herein by reference for all purposes. An example of performing MPS device position estimation using WiFi1214 is disclosed in U.S. Patent Application Publication 2021 / 0297168, which is incorporated herein by reference for all purposes.

[0220] In addition to the positioning / localization information itself, some examples of the positioning system application 1200 may expose metadata that identifies the localization capabilities of the host MPS device, such as accuracy and latency information and the availability of various underlying functions 1210. Therefore, the positioning system application 1200 enables each of the MPS functions 1202 to identify the localization capabilities present within its host MPS device and utilize a common set of API calls to access the positioning / localization information made available through the identified capabilities 1210.

[0221] As shown in Figure 12 and described above, the positioning system application 1200 can interoperate with MPS devices that support various localization capabilities such as Bluetooth 1212, WiFi 1214, UWB 1216, acoustic signaling 1218, and / or ultrasound 1220. In some examples, the positioning system application 1200 includes one or more adapters configured to communicate with the MPS device using the syntax and semantics specific to the localization capability 1210 of the MPS device. This architecture protects the MPS function 1202 from the complexities of interoperating with each type of MPS device. In some examples, each adapter can receive and process a stream of positioning / localization data from the MPS device using one or more of the communication capabilities 1210. The adapter can interoperate with the storage engine in the positioning system application 1200, which analyzes and merges the positioning / localization data acquired by the adapter (e.g., using a set of configurable rules) to generate a data structure containing the positioning / localization information and metadata described above. These data structures are then accessed in response to API calls received by the positioning system application 1200 to support the MPS function 1202, and the positioning / localization information and metadata are retrieved. In some examples, the positioning / localization information and metadata can identify the device's location relative to other devices, its absolute location (e.g., within a coordinate system), its presence (e.g., within a structure, within a room, or as a simple Boolean value), and / or the orientation of the device.

[0222] For example, in some cases, positioning / localization information is represented as two-dimensional (e.g., as coordinates in the Cartesian plane), three-dimensional (e.g., as coordinates in Cartesian space), or as coordinates in another coordinate system. In certain cases, positioning / localization information is stored in one or more data structures that include one or more records of typed and assigned fields to store a portion of the information. For example, in at least one example, a record is configured to store a timestamp associated with a value indicating the location coordinates of a portable playback device acquired at a time given by an associated timestamp. Furthermore, in at least one example, a record is configured to store a timestamp associated with a value indicating the velocity of a portable playback device acquired at a time given by an associated timestamp. Furthermore, in at least one example, a record is configured to store a timestamp associated with a value indicating the segments (start and end coordinates) of movement of a portable playback device acquired at a time given by an associated timestamp. Other examples of positioning / localization information and structures configured to store it will be evident in light of this disclosure.

[0223] The APIs and adapters implemented by the positioning system application 1200 may conform to various architectural styles and interoperability standards. For example, in one example, the API is a web service interface implemented using the Representational State Transfer (REST) ​​architectural style. In this example, API communication is encoded in Hypertext Transfer Protocol (HTTP) and JavaScript Object Notation (JSON) and / or Extensible Markup Language (XML). In some examples, a portion of the HTTP communication is encrypted for enhanced security. Alternatively, or additionally, in some examples, the API is implemented as a .NET web API that responds to HTTP POSTs to a specific URL (API endpoint) with localization data or metadata. Alternatively, or additionally, in some examples, the API is implemented using simple File Transfer Protocol (FTP) commands. Also, in some examples, the adapter is implemented using a proprietary application protocol accessible via a User Datagram Protocol (UDP) socket. Therefore, the adapters and APIs described herein are not limited to any particular embodiment.

[0224] In addition to complying with the interoperability standards described above, APIs and adapters implemented by positioning system applications may also comply with standards that facilitate seamless interaction with distributed ledger technologies. This coordination enables efficient storage and retrieval of positioning and contextual data on the blockchain network, ensuring data integrity and enabling cross-platform compatibility. For example, APIs could be designed to interact with decentralized identity (DID) systems, allowing users to maintain self-sovereign control over their location data while still benefiting from the capabilities of the positioning system. Furthermore, the use of standardized data formats and protocols could enable positioning systems to write data directly to blockchain-based record sets, contributing to a comprehensive and interoperable ecosystem of spatial and contextual information.

[0225] The embodiments and aspects are directed toward personalization technologies within a media playback system that can improve the user experience, increase user awareness of new and existing features within the media playback system, and / or encourage user engagement with the media playback system. The technologies disclosed herein may collect household pattern data (e.g., device configuration settings such as volume and playlist selection, device movement within the environment, bonding information, etc.) to be used to predict user preferences, while taking steps to maintain user privacy, as will be further described below. In addition, the personalization technologies may include aspects for addressing uncertainty in deciding whether to perform system personalization actions and / or train a personalization model, or how to do so, in order to minimize friction in user adoption and exploration.

[0226] Routines are a crucial aspect of how users interact with technology, particularly how they engage with audio and music through media playback systems. Users typically listen in different ways at different times of the day. This can range from quiet background music to help them concentrate during work hours to creating a party atmosphere when friends are invited over in the evening. While general trends and changes in routines can provide useful information, the technologies disclosed herein offer further value through their ability to adapt personalization to the behavior of individual users. For example, one user might consistently select a particular type of playlist or radio station on a playback device in one room each morning, setting the volume quite high, which could indicate a training routine, while keeping the playback device inactive during the day and opting for lower volume settings in the evening. Another user might consistently set the volume of one or more players relatively low throughout the day, but slightly increase it in the early evening. Since listening behavior can vary significantly among different users, user-specific personalization may be more valuable than relying on a general rule-based architecture.

[0227] Various recommendation systems exist that offer approaches to a certain degree of personalization. These recommendation systems generally present suggestions to a user from a set of items based on other items previously selected by the user. For example, if a user has previously watched programs A, B, and C, a streaming service may recommend program D because collected data indicates that users who have watched programs A, B, and C will also typically watch program D. This approach relies on collecting vast amounts of data from a vast number of users. In contrast to this list-based approach, the technology disclosed herein monitors a user's specific user interactions with their media playback system to detect individual behavioral patterns and proposes or applies unique personalization settings to that user based on the detected patterns. In this context, a user can be an individual person associated with a particular media playback system, or a group of people (e.g., a household). In a specific example, rather than identifying potential correlations (as done in the recommendation system approach described above), the personalization techniques disclosed herein determine when a trend or pattern was established within a particular media playback system and determine that it is relatively likely that the user would want the system configuration or behavior to be automated in accordance with this pattern in the future.

[0228] Unlike conventional recommendation systems, certain examples involve context awareness as a crucial aspect in determining and applying personalization features. As mentioned above, routines play a significant role in the user's interaction with the media playback system, and these routines can change over time. For example, a user may have different routines on weekdays and weekends, in summer and winter, or during school holidays and semesters. As will be further discussed below, the embodiments and examples disclosed herein incorporate the influence of context in the system's predictions, enabling the system to adapt to changing behaviors over both long-term and short-term timeframes. In particular, as mentioned above, the examples apply continuous learning and confidence metrics to robustly determine patterns and apply personalization only in highly confident scenarios, thereby reducing the likelihood of suggesting undesirable personalization settings.

[0229] As will be explained in more detail below, one example of a personalization setting is volume personalization. There are many scenarios in which appropriate or inappropriate volume can significantly impact a user's perception of a playback device or media playback system. For example, a user might wake up early in the morning, press "play" on a kitchen playback device to start their morning playlist, and be surprised to find the sound starting at an excessively loud decibel level because the playback device retained the settings from the previous night when the music was being enjoyed at a much louder volume. In such a scenario, the user might quickly press the "volume down" button multiple times in an attempt to lower the volume as quickly as possible. For example, the user might press the "volume down" button 10 or 20 times in a row, which represents a very frustrating user experience. The aspects and examples can provide a better user experience by enabling the media playback system 100 to learn and predict from user behavior, based on context (e.g., time of day) and perceived behavioral patterns, when the user might want a sound that fills the room and when they might want a quieter, more subdued volume level. For example, machine learning models can be applied to learn from user behavior to facilitate smarter volume (or other) interactions, thereby increasing user trust and reducing the likelihood of frustrating interactions.

[0230] Further examples of volume personalization and playback device grouping personalization are described below. However, given the interests of this disclosure, it will be understood that the personalization techniques and approaches discussed herein may be applied to various other functions, configurations, and / or behaviors of one or more playback devices (or NMDs) within a media playback system.

[0231] Referring to Figure 13, a block diagram of an example of a personalization service that may be implemented within a media playback system such as the media playback system 100 described above is shown. The personalization service 1304 receives data from the player user data source 1302 and provides personalization commands to the player 1306. Based on the commands received from the personalization service 1304, the player 1306 may automatically apply personalization settings, as will be described in more detail below, or it may present the user with suggestions for personalization settings. The player 1306 may be, for example, any of the blockchain-enabled playback devices 1000, 110, or 210 described above, or any NMDs 120 or 320. The player user data source 1302 may include one or more blockchain-enabled playback devices 1000, 110, 210, NMDs 120, 310, or control devices 130 within the media playback system 100.

[0232] As shown in Figure 13, in one example, the personalization service 1304 includes a data collector 1308, a model selector 1310, and multiple model managers 1312A-N. Each model manager 1312 is associated with its respective machine learning model 1322. For simplicity, only the components of model manager 1312A are shown in Figure 13, but it will be understood that all other model managers 1312 also contain the same components. As illustrated, model manager 1312A includes a data injection engine 1314, training data 1316, a trainer 1318, one or more sets of one or more parameters ("parameters") 1320 for each machine learning model 1322, each machine learning model 1322, and a recommendation engine 1324. Each of these components will be described in more detail below. The personalization service 1304 may be implemented in whole or in part on one or more network devices within the media playback system 100 (e.g., blockchain-enabled playback device 1000, playback devices 110, 210, NMD 120, 320, or control device 130), or in whole or in part on, for example, a cloud network device 102. The personalization service 1304 may be implemented in software, or using any combination of hardware and software capable of performing the functions disclosed herein.

[0233] In a particular example, the data collector 1308 collects input data from the player user data source 1302. The input data collected by the data collector 1308 may include any type of data representing a user interaction with the media playback system 100, as well as contextual information associated with the user interaction (such as date, time, and location), and device configuration data (e.g., identification of the playback device affected by the user interaction, current volume level setting, whether the device is in a combined group and, if so, which other players it is combined with, and the current location of the playback device). In various examples, the player user data source 1302 may be, or include, blockchain data such as CERS, CNRS, or other preferred data accessed via a distributed ledger. For example, the input data associated with a user interaction may include commands to increase or decrease the volume, commands to select a specific audio content source such as a particular playlist, audio streaming channel, or radio station, and commands to group or ungroup one or more playback devices. The input data may also include movement or localization information, such as movement of a portable playback device from one location to another, which may be acquired via the positioning system application 1200 described above. Data collection may occur at various intervals over time. For example, a data collection event may occur each time the user interacts with a network device in the media playback system, or it may occur at other periodic or aperiodic times. The input data collected at each data collection event is used by the personalization service 1304 to learn the user's routines and to suggest or apply personalization settings when the learned routines are established.

[0234] In a particular example, Model 1322 is a parameterized machine learning model configured to operate based on one or more features extracted from collected input data. Examples of features may include time, day of the week, type of user interaction (e.g., volume up / down, play, grouping), and previous / existing settings of the corresponding playback device (e.g., previous volume setting of the playback device, or previous grouping setting of the playback device). Each Model 1322 associated with each of the Model Managers 1312A-N may operate based on different features. For example, different models may be applied to different personalization configurations such as a volume level model and a grouping model, and different features may be associated with these different personalization configurations. In one example of a volume level model, a set of features that could be used to learn volume interaction trends might include time from the start of the day (so the model can learn how volume interactions change over time), time from the start of the week (so the model can learn how volume interactions change over time), previous volume (which can provide volume-related context to the interaction), and the type of interaction (e.g., volume up, volume down, or play; so the model can determine whether to increase, decrease, or keep the volume the same based on a given current volume level). Similarly, as can be seen in consideration of the interests of this disclosure, relevant sets of features can be selected for other personalization models.

[0235] In addition to selecting an appropriate feature set for each personalization model, different types of machine learning models can be chosen for different applications. To give a specific example, it is desirable to select a machine learning model that can adapt to diverse and different contexts and routines that change over time, can handle uncertainty (e.g., by using confidence indicators as described above), and can learn on relatively small amounts of data (e.g., hundreds to thousands of data points rather than millions). In one example, model 1322 is a Gaussian process (GP) model. Gaussian process models do not require large datasets, facilitate the estimation of uncertainty in principle-based models, and can be tailored to specific tasks or patterns in the data through the selection and / or construction of the covariance function (kernel). Gaussian process models can be used to interpret data with strong periodic components (as many user behavior patterns have) by using a periodic kernel. Therefore, Gaussian process models can be configured to encode periodic information related to user routines, which can be particularly important due to the strong periodicity present in many user interactions.

[0236] Examples of kernels that can be used with the Gaussian process model 1322 include the Gaussian kernel, the Matern kernel, and the periodic kernel. In addition to these kernels, some examples also use a white noise kernel to account for variations in the input data.

[0237] The Gaussian kernel is described by the following function: TIFF2026528723000002.tif3259 In function F1, l represents the length scale, which is a trained parameter of the model. Using a Gaussian kernel, the similarity between data points increases with the square of their distance.

[0238] The Mateen kernel is a generalization of the Gaussian kernel, allowing control over the smoothness of the corresponding function F2 via the parameter ν. This additional flexibility makes the Mateen kernel adaptable to "real-world" data that can be highly variable. The Mateen kernel is described by the following function F2: In function F2 of TIFF2026528723000003.tif31121, l represents the length scale, which is a trained parameter of the model, and ν is the smoothness parameter.

[0239] The periodic kernel is described by the following function: In function F3 (TIFF2026528723000004.tif3275), l represents the length scale and p represents the periodicity; both are trained parameters of the model. Using a periodic kernel, data points are considered similar if they occur in a similar region of the periodic function. For example, 7 PM on Tuesday might be similar to 6:45 PM on Wednesday.

[0240] In some examples of Model 1322, multiple kernels are combined in the Gaussian process model to generate a more expressive covariance function. In addition, as will be further detailed below, in some examples, multiple Model 1322s are combined to improve the predictive performance of the system based on the available input data.

[0241] Continuing to refer to Figure 13, in some examples, the data collector 1308 may process the input data according to various features associated with the model 1322 to identify different player user data types and categorize the data accordingly. In addition, the data collector 1308 may also tag or categorize the input data based on a specific context or identity associated with a given data collection event. For example, the data collector 1308 may categorize data received via voice commands from user A separately from data received via voice commands from user B, thereby enabling the system to learn different patterns and personalization predictions for the two individual users. In another example, input data associated with a particular playback device or group of playback devices may be tagged to be associated with that particular playback device or group of playback devices. This may enable the system to learn different patterns regarding the same function (e.g., volume personalization) that can be applied to different playback devices. For example, a user may consistently select a specific volume setting when using playback device 110f in office 101e, and a different volume setting when using playback device 110c on patio 101i. The player user data type may also be based on the type of command or activity detected, such as volume level data type, bonding group data type, audio content selection data type, etc. Thus, for each data collection event, data collection may categorize the corresponding input data into one or more player user data types. The data collector may also apply a timestamp to each collected player user data type, as many potential behavioral patterns have a time component, as described above. Therefore, time information can be important for the system to correctly determine behavioral patterns and trends. The timestamp may include time in addition to date information.

[0242] When input data is collected by the data collector 1308 during a data collection event, the personalization service 1304 can provide the input data processed by the data collector 1308 to one or more model managers 1312A-N, which can then be used to train their respective models 1322 and / or to generate personalization recommendations. As described above, different model managers 1312 (each with its own model 1322) may be used for different personalization settings, such as volume personalization or bonding personalization. Therefore, a particular sample of input data acquired during a given data collection event may be relevant to one or more model managers 1312 but not to others. For example, input data corresponding to a command to group two playback devices and localization information for the two playback devices may be relevant to the bonding personalization model but not to the volume personalization model. Therefore, the model selector 1310 can evaluate the input data samples acquired by the data collector 1308 and guide the input data samples to the appropriate model manager 1312.

[0243] c. Exemplary method relating to a blockchain-enabled playback device comprising a generating media component and / or a generating context and control component. Integrating blockchain functionality, generated media components, and generated context and control components within a playback device enables a range of useful applications. When combined in whole or in part, these technologies can enable the delivery of enhanced, personalized, and context-aware media experiences. The following sections outline several exemplary ways in which this integration is possible, demonstrating how blockchain-enabled playback devices can utilize on-chain data as input for generated media creation, how real-time contextual information can influence both interaction with the blockchain and media generation, and how the output of the generation process can be recorded and utilized via a distributed ledger. The following examples are for illustrative purposes only, and many other such use cases are possible.

[0244] Figures 14–17 are flowcharts of exemplary methods 1400, 1500, 1600, and 1700, which may be implemented by any device or system described herein (e.g., blockchain-enabled regeneration device 1000 or any other device described herein), or any other device or system currently known or to be developed in the future. Various examples of methods 1400, 1500, 1600, and 1700 include one or more operations, functions, or actions indicated by blocks. The blocks are shown sequentially, but these blocks may be executed in parallel and / or in an order different from the order disclosed and described herein. Also, various blocks may be combined into fewer blocks, split into additional blocks, and / or deleted, based on the desired implementation.

[0245] Figure 14 illustrates Method 1400 for generating media content using a blockchain-enabled playback device with an integrated generating media component. This method leverages data and / or real-time positioning information stored on the blockchain to generate a unique, contextualized audio experience. The method begins at block 1402, where the playback device retrieves first input parameters via a distributed ledger. These parameters may include persistent or historical information, such as user preferences, listening history, or other relevant data stored on the blockchain. For example, this data could provide a context of the user's relatively long-term behavior and preferences, which can inform the generation process.

[0246] In block 1404, the playback device acquires a second input parameter containing positioning system application information. This information represents dynamic, real-time data about the device's current context, such as the device's location in a room, the presence of other devices or users, or environmental factors. The positioning system application may utilize various technologies to collect this data, such as ultrasonic sensors, WiFi triangulation, or other localization methods. For example, the information acquired in relation to block 1404 may not be acquired via the blockchain, but instead directly from another network device, playback device, and / or playback device network.

[0247] Furthermore, in some implementations of methods similar to Method 1400, the playback device does not have to obtain the second input parameter, or may optionally obtain it in certain implementations. Moreover, such a second input parameter does not have to be obtained via the blockchain, or may optionally obtain it in certain implementations. That is, the playback device may obtain one or more sets of input parameters, and all such input parameters may be obtained solely via the blockchain, or via a combination of the blockchain and direct acquisition from other devices and / or networks.

[0248] In block 1406, the playback device produces generated media content via the generated media module based on at least acquired input parameters, such as the first and second input parameters. In one example, this step involves using both blockchain-derived historical data and real-time positioning data as inputs for the generated model within the generated media module. In some implementations, producing generated media content related to block 1406 may be based on additional inputs and / or information other than the input parameters acquired in relation to block 1402 and / or block 1404. In alternative implementations, producing generated media content may be based on the first input parameter, such as those detailed with respect to block 1402, and the playback device does not necessarily have to acquire and use the second input parameter.

[0249] In some implementations, input data may be pre-conditioned into a format suitable for the generative model. This preconditioning can occur at various stages, including (i) during initial collection / storage, (2) after data storage but before use, or (3) immediately before use for generation. In case (1), raw data may be processed and formatted as it is collected to ensure it is immediately ready for use in the generative model. In case (2), the regeneration device may periodically process stored data into an appropriate format to create a pre-conditioned dataset ready for rapid use. And in case (3), the regeneration device can format data on demand to reflect the latest information, but this may potentially increase processing time. The choice of when to pre-condition the data may depend on factors such as the computing power of the regeneration device, the desired responsiveness of the system, and the rate at which the underlying data changes. Additionally or alternatively, input parameters obtained from the blockchain may be validated before, during, or after use (e.g., to verify the source (probance) or other parameters as described above) to produce the generative media content.

[0250] By combining historical data stored on the blockchain with real-time positioning information, the generated media module can create audio content that is not only personalized to the user's long-term preferences but also responsive to the environment and context at any given time. This can result in generated audio that adapts its style, tempo, or other characteristics based on the user's location in the room, the time of day, or the presence of other individuals, while maintaining all consistency with the user's established tastes and preferences.

[0251] After creating the generated media content in relation to block 1406, the playback device may then play the generated media content. In one example, this may include the playback device itself playing the generated media content. In another example, this may include the playback device playing the generated media content to one or more other network devices, playback devices, and / or playback device networks, optionally together with the playback device itself.

[0252] Figure 15 illustrates Method 1500 for producing personalized recommendations using a blockchain-enabled playback device with integrated personalization services. This method combines data stored on the blockchain with locally stored information to generate contextualized, adaptive recommendations for media playback. The method begins at block 1502, where the playback device retrieves initial input data via a distributed ledger. This data can represent relatively persistent historical information stored on-chain, which may include long-term user preferences, comprehensive listening history, and aggregated behavioral patterns. The blockchain layer ensures the secure and tamper-proof storage of this data, ensuring its integrity and availability across different devices or platforms.

[0253] In block 1504, the regeneration device acquires second input data via a local data source. This second input data may include dynamic real-time information from a positioning system application and potentially other local sensors. It may include data such as the current location of the regeneration device in the room, the number of users present, the time, or other contextual information that can be determined by sensors or direct user input.

[0254] In block 1506, the playback device generates personalized recommendations based on first and second input data. In various examples, the personalized recommendations may be system recommendations relating to, for example, media playback, the configuration of the media playback system, or other aspects of the user's environment. This step may also include a personalization service acting as a recommendation engine processing both blockchain-derived historical data and real-time local data to generate “live” personalized recommendations tailored to the current context of the playback device and its environment. In some implementations, generating personalized recommendations in relation to block 1506 may be based on additional inputs and / or information other than the input parameters obtained in relation to block 1502 and / or block 1504. In alternative implementations, generating personalized recommendations may be based on first input parameters, such as those detailed in relation to block 1502, and the playback device does not necessarily have to obtain and use second input parameters. Additionally or alternatively, input parameters obtained from the blockchain may be validated before, during, or after using the input parameters to create personalized recommendations (for example, to verify their origin or other parameters as described above).

[0255] For example, a personalization service can leverage historical data from the blockchain to understand long-term trends and preferences, while real-time data enables immediate responsiveness to current circumstances. For instance, the service may recommend different content or playback settings based on whether the user is alone or in a group, or it may adjust recommendations based on the time of day and the user's typical listening patterns during that time period. Further details regarding the use of blockchain data in content generation can be found in international patent application PCT / US2023 / 066776, filed 9 May 2023, entitled "Generating Digital Media Based on Blockchain Data," which is incorporated herein by reference for all purposes.

[0256] Furthermore, playback devices can record transactions reflecting the playback of specific tracks on a blockchain layer, continuously enriching the historical dataset. This creates a feedback loop where current playback decisions inform future recommendations, allowing the system to learn and adapt over time.

[0257] The personalized recommendations produced in block 1506 may encompass various aspects of the media playback experience, such as content selection (e.g., suggesting specific tracks, albums, or playlists that match both historical preferences and the current context), playback settings (e.g., recommending appropriate volume levels, equalization settings, or spatial audio configurations based on room layout and user presence), and / or device configurations (e.g., suggesting optimal grouping of playback devices, or suggesting movement between devices as the user moves between different spaces).

[0258] After creating personalized recommendations in relation to block 1506, the playback device may then have the playback device implement the personalized recommendations. In one example, this may include the playback device itself implementing the personalized recommendations. In another example, this may include the playback device having one or more other network devices, playback devices, and / or playback device networks implement the personalized recommendations, optionally together with the playback device itself.

[0259] Figure 16 illustrates a method 1600 for a blockchain-enabled playback device to acquire and store data about a locally generated model. The process begins at block 1602, during which the playback device acquires data about the locally generated model. This data may include user interactions, environmental inputs, or performance metrics of the generated model itself. The acquired data may be related to the playback device's local context and may potentially capture unique usage patterns or environmental factors that influence the output of the generated model. The locally generated model may be a generated media model (e.g., the generated media module described above) or a model for the generated context and control (e.g., the personalization service or recommendation engine described above).

[0260] In block 1604, the method proceeds to store the data via a distributed ledger. This step involves preparing the acquired data for storage on the blockchain, which may include formatting, compression, or encryption as needed. The distributed ledger may be a public blockchain for widely shareable data, a private blockchain for more sensitive information, or an intermediate ledger for temporary storage or further processing. By storing this data on a distributed ledger, the regenerative device contributes to a decentralized knowledge base that can improve the generative model across the entire network of devices.

[0261] Figure 17 illustrates method 1700 for verifying and utilizing personalization information in a blockchain-enabled playback device. The process begins at block 1702, where the playback device retrieves personalization information. This information may include user preferences, listening habits, or other data related to personalizing the media playback experience.

[0262] Moving on to block 1704, this method involves verifying personalization information via a distributed ledger. This step uses blockchain technology to authenticate the origin of the data, ensuring that the data originates from genuine human activity and not from AI-generated or synthetic sources. In some cases, authentication may include Proof of Personhood (PoP) or other preferred protocol to verify that the source is human. In some cases, PoP verification may be stored on a different blockchain than the underlying data being verified. In other cases, the PoP is stored on the same blockchain (and possibly within the same block on the blockchain) as the underlying data. This verification process helps maintain the integrity and reliability of the personalization data used by the system.

[0263] Finally, in block 1706, this method concludes by modifying the behavior of the media playback system, including the playback device, based on the verified personalization information. This step includes applying the verified personalization data to tailor the media playback experience. The modifications may include adjusting playback settings, curating content, or changing the behavior of the generated media module to match the verified user preferences and behavior.

[0264] In some cases, blockchain-enabled playback devices may be used to support (and / or be integrated into) augmented reality (XR) devices such as head-up displays, virtual reality visors or goggles, smart glasses, or any other suitable augmented reality form factor. Many augmented reality devices desire to generate out-loud, immersive audio that adapts to both the playback device's position and the viewer's position within the virtual scene. This dynamic audio generation creates a more realistic and engaging XR environment where sound operates in a way that reflects the acoustic characteristics of the real world. Further details regarding the production and management of out-loud audio accompanying augmented reality displays can be found in U.S. Patent No. 11,483,670 “Torgerson '670”, co-owned and published on 25 October 2022, entitled “Systems and Methods of Providing Spatial Audio Associated with a Simulated Environment,” which is incorporated herein by reference for all purposes.

[0265] The positioning of audio playback devices plays a crucial role in shaping these virtual scenes. By adjusting the virtual scene based on the physical location of speakers or other audio output devices, the system can create a more seamless integration between digital content and the user's physical environment. For example, if the user has a surround sound system, the virtual scene may be adjusted to take advantage of the position of each speaker for optimal audio placement within the XR experience. Torgerson '670 describes, for example, transmitting the positions of the device and / or listener to a media content provider (or other preferred service), which then provides appropriately spatialized audio to deliver a realistic 3D audio experience. In some examples, playback device 1000 generates 3D audio (e.g., synthesized 3D audio) based on data received via a personalization service 1018, a positioning system application, and / or one or more of the aforementioned blockchain data sources, rather than from an external or remote media content provider. In some examples, the 3D audio is generated via a DAO rather than a media content provider.

[0266] In some examples, an XR-enabled media playback system (or DAO) may adjust one or more aspects of visual virtual content based on the playback device's location data and / or the room's acoustic characteristics. For example, in response to receiving the playback device's position relative to a wall and / or one or more dimensions of a room, the system may adjust the boundaries of a virtual scene. For example, in some XR applications, matching the size of the virtual scene to the size of the room may provide an improved listening environment for the user. In some cases, the system may adjust the boundaries of a virtual scene to match, or slightly larger than, the area defined by the playback device. In some embodiments, the system may adjust the boundaries of a virtual scene to be smaller than the area defined by the playback device.

[0267] Leveraging blockchain technology in this context offers new possibilities for generating synthetic XR content. By accessing real-world device location and user personalization data stored on a distributed ledger, XR-enabled media playback systems (or DAOs) can create customized, contextually relevant virtual scenes. This blockchain-based approach ensures that the generated content is not only personalized but also maintains a verifiable history of user preferences and device configurations, enabling a consistent experience across different XR sessions and locations.

[0268] In some implementations, the personalization and / or location data may be made available as part of a "digital twin" metaverse (either via a blockchain or in some other way). By making the personalization and location data available via a blockchain, users can create virtual instances that closely reflect their real-world setup. This means that the position of devices, audio preferences, and other personalized settings in the virtual space can be automatically configured to match the user's physical environment. Such synchronization between the real world and the virtual world enhances the immersion of the XR experience and provides a seamless transition between the physical and digital realms.

[0269] Furthermore, the use of blockchain in this context provides additional benefits such as data portability and interoperability. Users can carry their personalized XR preferences and device configurations across different platforms and applications regardless of the specific XR system in use, ensuring a consistent experience. This blockchain-enabled continuity not only enhances the comfort and familiarity of users within the virtual environment but also enables a more complex and interconnected XR ecosystem where real-world and virtual-world elements coexist and interact with each other.

[0270] V. Conclusion The above descriptions of the playback device, control device, playback zone configuration, and media content source are merely providing some examples of the operating environments in which the functions and methods described below can be implemented. Other operating environments and configurations of media playback systems, playback devices, and network devices not explicitly described herein may also be applicable and suitable for the implementation of the functions and methods.

[0271] The foregoing description has disclosed various exemplary systems, methods, apparatuses, and articles of manufacture among numerous others, including firmware and / or software executed on hardware among other components. It is understood that such examples are merely exemplary and should not be considered limiting. For example, any or all of the firmware, hardware, and / or software aspects or components may be embodied solely in hardware, solely in software, solely in firmware, or in any combination of hardware, software, and / or firmware. Thus, the examples provided are not the only way to implement such systems, methods, apparatuses, and / or articles of manufacture.

[0272] Furthermore, the reference to "example" herein means that a particular feature, structure, or characteristic described in connection with the example may be included in at least one exemplary example or embodiment of the invention. This term appearing in various places in this specification does not necessarily refer to the same example, nor are separate examples or alternative examples mutually exclusive of other examples. As such, the examples described herein can be combined with other examples, as will be understood explicitly or implicitly by those skilled in the art.

[0273] This specification broadly presents exemplary environments, systems, procedures, steps, logical blocks, processes, and other symbolic representations that directly or indirectly resemble the operation of network-connected data processing devices. These process descriptions and representations are typically used by those skilled in the art to most effectively convey the substance of the work to others skilled in the art. Many specific details are provided to provide a complete understanding of the Art. However, it will be understood by those skilled in the art that certain examples of this disclosure can be implemented without specific details. In other embodiments, well-known methods, procedures, components, and circuits are not described in detail to avoid unnecessarily obscuring the aspects of the examples. Accordingly, the scope of this disclosure is defined by the appended claims rather than by the description of the examples above.

[0274] Where any of the appended claims is read to cover purely software and / or firmware implementations, at least one of the elements in at least one example is expressly defined herein as including a tangible, non-temporary medium such as memory, DVD, CD, Blu-ray, etc., for storing the software and / or firmware.

[0275] The disclosed technology is illustrated, for example, by the various examples described below. These various examples of the disclosed technology are described as numbered examples (1, 2, 3, etc.) for convenience. These are given as examples and are not intended to limit the disclosed technology. Note that any of the dependent examples can be combined in any combination and placed in their respective independent examples. Other examples can be presented in a similar manner.

[0276] Example 1. A method comprising: accessing data stored in a distributed ledger to obtain a Content Experience Record Set (CERS); receiving a request to play media content via a playback device and which is associated with a CERS; playing the media content via the playback device; and modifying the CERS after playing the media content.

[0277] Example 2. A method relating to any one of the preceding examples, wherein sending a request to update the CERS includes sending a request to add a record entry to the CERS based on the playback of the media content.

[0278] Example 3. A method relating to any one of the preceding examples, wherein the CERS includes a set of media consumption events and event information corresponding to each media consumption event in the set.

[0279] Example 4. A method relating to any one of the preceding examples, wherein the event information includes one or more of the following: event time; associated playback device; associated playback group; associated home; associated playback network; associated media service; user preference; entity associated with adding a record of the media consumption event; source data corresponding to the record of the media consumption event; media content metadata; transport control associated with the media consumption event; a pointer to a smart contract containing playlist data; or a pointer to a non-fungible token containing playlist data.

[0280] Example 5. A method relating to any one of the preceding examples, wherein a particular media consumption event includes one or more of the following: starting media playback; changing media playback; loading a media playlist; or changing a media playlist.

[0281] Example 6. A method relating to any one of the preceding examples, wherein the CERS is associated with an identifier.

[0282] Example 7. A method relating to any one of the preceding examples, wherein the identifier is a unique distributed identifier associated with a user, device, or account.

[0283] Example 8. A method relating to any one of the preceding examples, wherein the CERS is stored in the distributed ledger.

[0284] Example 9. A method relating to any one of the preceding examples, wherein the CERS includes first data stored in the distributed ledger, and modifying the CERS includes adding additional data to the first data of the CERS stored in the distributed ledger.

[0285] Example 10. A method relating to any one of the preceding examples, wherein the CERS is stored via an intermediate computing device that communicates with the distributed ledger.

[0286] Example 11. A method relating to any one of the preceding examples, wherein the CERS includes first data stored via an intermediate computing device, modifying the CERS includes updating the first data of the CERS stored in the intermediate computing device, and the method further includes adding second data to the distributed ledger that reflects the modified CERS data stored in the intermediate computing device.

[0287] Example 12. A method relating to any one of the preceding examples, wherein first pointer data corresponding to first data of the CERS is stored directly in the distributed ledger, and adding second data reflecting the modified CERS data stored in the intermediate computing device to the distributed ledger includes adding an entry to the distributed ledger indicating that the first pointer data corresponds to the modified CERS data.

[0288] Example 13. A method relating to any one of the preceding examples, wherein the intermediate computing device supports an intermediate distributed ledger (e.g., a temporary blockchain; a private blockchain, etc.) for storing the CERS.

[0289] Example 14. A method relating to any one of the preceding examples, wherein the intermediate distributed ledger is supported by multiple intermediate computing devices (e.g., multiple playback devices in a home).

[0290] Example 15. A method relating to any one of the preceding examples, wherein at least a portion of the CERS is stored directly in the distributed ledger.

[0291] Example 16. A method relating to any one of the preceding examples, wherein at least a portion of the CERS is stored in an intermediate computing device rather than being stored directly in the distributed ledger.

[0292] Example 17. A method relating to any one of the preceding examples, wherein the data is first data, and modifying the CERS includes writing second data to a distributed ledger.

[0293] Example 18. A method according to any one of the preceding examples, wherein causing the CERS to be changed includes sending a request to update the CERS to an intermediate computing device, and the intermediate computing device causes data including a batch of updates for a plurality of different CERSs associated with different identifiers to be written to a distributed ledger.

[0294] Example 19. A method according to any one of the preceding examples, further comprising receiving an input to approve the update of the CERS before causing the CERS to be changed.

[0295] Example 20. A method according to any one of the preceding examples, wherein receiving the request includes receiving the request via the playback device; and causing the CERS to be changed includes sending a request to change the CERS via the playback device.

[0296] Example 21. A method according to any one of the preceding examples, wherein receiving the request includes receiving the request via one or more computing devices associated with a media content service; playing the media content via the playback device includes sending the media content to the playback device for playback from the one or more computing devices associated with the media content service; and causing the CERS to be changed includes sending a request to change the CERS via the one or more computing devices associated with the media content service.

[0297] Example 22. A method according to any one of the preceding examples, wherein causing the CERS to be changed does not include sending a request to change the CERS via the playback device.

[0298] Example 23. A method relating to any one of the preceding examples, further comprising causing the CERS to output a user prompt indicating redundancy identified.

[0299] Example 24. A method relating to any one of the preceding examples, further comprising sending a verification command to update the CERS after the user prompt has been output.

[0300] Example 25. A method relating to any one of the preceding examples, further comprising accessing second data stored in the distributed ledger in order to obtain a Content Network Record Set (CNRS).

[0301] Example 26. A method relating to any one of the preceding examples, wherein the CERS is associated with an identifier and the CNRS is associated with the same identifier.

[0302] Example 27. A method relating to any one of the preceding examples, wherein the CNRS includes recording of a device, media playback system, and / or media content service associated with the identifier.

[0303] Example 28. A method relating to any one of the preceding examples, wherein the distributed ledger is a first distributed ledger maintained by a plurality of first distributed computing devices, a first instance of the CERS is stored through the first distributed ledger, a second instance of the CERS is stored through a second distributed ledger maintained by a plurality of second distributed computing devices, and modifying the CERS includes modifying both the first instance and the second instance of the CERS in the first distributed ledger and the second distributed ledger, respectively.

[0304] Example 29. A method relating to any one of the preceding examples, wherein changing the CERS includes changing the CERS based on one or more trigger conditions.

[0305] Example 30. A method relating to any one of the preceding examples, wherein changing the CERS based on one or more trigger conditions includes changing the CERS at predetermined intervals (e.g., hourly, daily, weekly, monthly); after each media consumption event; after a threshold number of media consumption events; or after a user prompt.

[0306] Example 31. A method relating to any one of the preceding examples, wherein the CERS includes publicly accessible CERS data, and the method further includes updating a comprehensive content record set after the media content has been played, wherein the comprehensive content record set includes both the publicly accessible CERS data and data that is not publicly accessible.

[0307] Example 32. A method relating to any one of the preceding examples, wherein the regeneration device is a first regeneration device, and the method further comprises accessing data stored in the distributed ledger via a second device in order to obtain CERS.

[0308] Example 33. A method relating to any one of the preceding examples, wherein the second device includes a second playback device associated with the first playback device (e.g., within the same household).

[0309] Example 34. A method relating to any one of the preceding examples, wherein the second device is not associated with the first playback device (e.g., a device belonging to another user, a device associated with a participating service provider, etc.).

[0310] Example 35. A method relating to any one of the preceding examples, further comprising signing a transaction associated with the distributed ledger via the replay device.

[0311] Example 36. A method relating to any one of the preceding examples, further comprising causing the regeneration device to transfer one or more tokens associated with the distributed ledger to a destination address.

[0312] Example 37. A method relating to any one of the preceding examples, further comprising interacting with a smart contract running via the distributed ledger via the playback device.

[0313] Example 38. A method relating to any one of the preceding examples, further comprising verifying a transaction via the distributed ledger through the replay device.

[0314] Example 39. A method relating to any one of the preceding examples, further comprising staking one or more tokens via the distributed ledger via the regeneration device.

[0315] Example 40. A method relating to any one of the preceding examples, further comprising causing the token reward associated with the distributed ledger to be received at a designated recipient address via the regeneration device.

[0316] Example 41. A method relating to any one of the preceding examples, wherein the designated recipient address is associated with the playback device or a user account associated with the playback device.

[0317] Example 42. A method relating to any one of the preceding examples, wherein the regeneration device comprises a blockchain-enabled regeneration device having one or more dedicated processors configured to interact with the distributed ledger.

[0318] Example 43. A method relating to any one of the preceding examples, wherein the one or more dedicated processors are configured to perform mining, staking, or verification processes associated with the distributed ledger.

[0319] Example 44. A method relating to any one of the preceding examples, wherein the blockchain-enabled playback device is configured to run a node of the distributed ledger.

[0320] Example 45. A method relating to any one of the preceding examples, wherein the blockchain-enabled device is configured to run the wallet associated with the distributed ledger.

[0321] Example 46. A method comprising: obtaining a first input parameter in a playback device via a distributed ledger (e.g., on-chain persistent / historical information); obtaining a second input parameter in the playback device including positioning system application information (e.g., dynamic real-time information); and generating generated media content via a generated media module of the playback device based on the first and second input parameters (e.g., preconditioning positioning / personalization model data to appropriate prompts for input to a generated model).

[0322] Example 47. A method comprising: obtaining first input data via a distributed ledger (e.g., on-chain persistent / historical information) in a playback device; obtaining second data via a local data source (e.g., positioning system application information such as dynamic / real-time and / or information stored on a local device / network; examples include user location, activity, number of users present, time, or other inputs); and generating personalized recommendations for media playback based on the first and second input data (e.g., dynamically updated "live" personalization recommendations) by the playback device.

[0323] Example 48. A method in a playback device comprising: acquiring data relating to a local generative model (e.g., a personalization service or a generative media module; the data may be for immediate use via the generative model); and storing the data via a distributed ledger (e.g., a public, private, and / or intermediate ledger).

[0324] Example 49. A method comprising: acquiring personalization information (e.g., positioning system and / or personalization service information) in a playback device; verifying the personalization information via a distributed ledger (e.g., verifying the source, verifying the source as human-generated activity rather than AI-generated or synthesized); and modifying the operation of a media playback system including the playback device based on the personalization information.

[0325] Example 50. A method comprising: obtaining first information via a blockchain in a playback device; obtaining second information in the playback device; and executing a generative model by the playback device, wherein executing the generative model includes: generating a generative model output based on at least the obtained first information and the obtained second information; and implementing the generative model output.

[0326] Example 51. A method according to claim A1, wherein the second information includes one or more of the following: (a) information obtained from another playback device; (b) information obtained via a sensor of the playback device; or (c) a control command obtained via a control device.

[0327] Example 52. A method according to any one of Examples 50-51, wherein obtaining the first information includes: obtaining information about an off-chain memory system from a blockchain; and accessing the off-chain memory system.

[0328] Example 53. A method according to any one of Examples 50 to 52, wherein the generation model includes a generation media module.

[0329] Example 54. A method according to any one of Examples 50-53, wherein the generative model includes a machine learning model.

[0330] Example 55. A method according to any one of Examples 50-54, wherein the generative model includes a recommendation engine.

[0331] Example 56. A method according to any one of Examples 50-55, wherein the generative model includes a parameterized machine learning model.

[0332] Example 57. A method according to any one of Examples 50 to 56, wherein the generative model includes a Gaussian process model.

[0333] Example 58. A method according to any one of Examples 50-57, wherein the generative model output includes generated media content.

[0334] Example 59. A method according to Example 58, wherein performing the generated model output includes playing back at least a portion of the generated media content by the playback device.

[0335] Example 60. A method according to Example 58, wherein performing the generated model output includes playing at least a portion of the generated media content on another playback device.

[0336] Example 61. A method according to any one of Examples 50 to 56, wherein the generative model output includes a system recommendation.

[0337] Example 62. A method according to Example 61, wherein executing the generative model output includes having at least a portion of the system recommendations executed by the playback device.

[0338] Example 63. A method according to Example 61, wherein executing the generative model output includes having at least a portion of the system recommendation executed by another playback device.

[0339] Example 64. A method according to any one of Examples 50 to 63, wherein the generative model is a first generative model, the generative model output is a first generative model output, and the method further comprises executing a second generative model by the playback device, the execution of the second generative model comprising: generating a second generative model output.

[0340] Example 65. A method according to Example 64, wherein the first generative model output includes generated media content and the second generative model output includes system recommendations.

[0341] Example 66. A method according to any one of Examples 50 to 65, further comprising verifying one or more aspects of the acquired first information.

[0342] Example 67. A method according to any one of Examples 50-66, further comprising storing at least a portion of the generated generative model output via a blockchain.

[0343] Example 68. A method according to any one of Examples 50-67, further comprising storing the indication for execution of the generated generative model output via a blockchain.

[0344] Example 69. A method according to any one of Examples 50-68, further comprising storing at least a portion of the acquired second information via a blockchain.

[0345] Example 70. One or more tangible, non-temporary, computer-readable media that, when executed by one or more processors, store instructions causing the one or more processors to perform the method described in any one of the preceding examples.

[0346] Example 71. A media playback system comprising one or more processors and one or more computer-readable media as described in Example 70.

[0347] Example 72. A playback device comprising one or more processors and one or more computer-readable media as described in Example 70.

Claims

1. The steps involve accessing data stored in a distributed ledger to retrieve a Content Experience Record Set (CERS), The steps include receiving a request associated with the CERS to play media content via a playback device, The steps include playing the media content via the playback device, The steps include: causing the CERS to change after the media content is played; Methods that include...

2. The method according to claim 1, wherein the step of sending a request to update the CERS includes sending a request to add a record entry to the CERS based on the playback of the media content.

3. The method according to claim 1 or 2, wherein the CERS includes a set of multiple media consumption events and event information corresponding to each media consumption event in the set.

4. The aforementioned event information is, Event time, Related playback devices, Related regeneration groups, Related families, Related playback networks, Related media services, User preferences, The entity to which the record of the aforementioned media consumption event has been added, Source data corresponding to the recording of the aforementioned media consumption event, Media content metadata, Transport control related to the aforementioned media consumption event, A pointer to a smart contract containing playlist data, or A pointer to a non-fungible token containing playlist data, including the playlist itself. The method according to claim 3, comprising one or more of the above.

5. The method according to claim 3 or 4, wherein a specific media consumption event includes one or more of the following: initiating media playback, changing media playback, loading a media playlist, or changing a media playlist.

6. The method according to any one of claims 1 to 5, wherein the CERS is associated with an identifier.

7. The method according to claim 6, wherein the identifier is a unique distributed identifier associated with a user, device, or account.

8. The method according to any one of claims 1 to 7, wherein the CERS is stored in a distributed ledger.

9. The CERS includes first data stored in a distributed ledger, The method according to claim 8, wherein the step of modifying the CERS includes adding additional data to the first data stored in the distributed ledger.

10. The method according to any one of claims 1 to 7, wherein the CERS is stored via an intermediate computing device that communicates with a distributed ledger.

11. The CERS includes first data stored via the intermediate computing device, The step of changing the CERS includes updating the first data stored in the intermediate computing device, The method according to claim 10, further comprising the step of adding a second data reflecting the modified CERS data stored in the intermediate computing device to a distributed ledger.

12. The first pointer data corresponding to the first data of the CERS is stored directly in the distributed ledger. The method according to claim 11, wherein the step of adding the second data to a distributed ledger includes adding an entry to the distributed ledger indicating that the first pointer data corresponds to the modified CERS data.

13. The method according to any one of claims 10 to 12, wherein the intermediate computing device supports an intermediate distributed ledger for storing the CERS.

14. The method according to claim 13, wherein the intermediate distributed ledger is supported by a plurality of intermediate computing devices.

15. The method according to any one of claims 1 to 14, wherein at least a portion of the CERS is stored directly in a distributed ledger.

16. The method according to any one of claims 1 to 15, wherein at least a portion of the CERS is stored in an intermediate computing device without being directly stored in a distributed ledger.

17. The aforementioned data is the first data, The method according to any one of claims 1 to 16, wherein the step of modifying the CERS includes writing the second data to a distributed ledger.

18. The method according to any one of claims 1 to 17, wherein the step of modifying the CERS includes sending a request to update the CERS to an intermediate computing device, the intermediate computing device causing the updates of a plurality of CERS associated with different identifiers to be written to a distributed ledger as a batch.

19. The method according to any one of claims 1 to 18, further comprising the step of receiving input approving the update of the CERS before modifying the CERS.

20. The step of receiving the request includes receiving the request via a playback device, The method according to any one of claims 1 to 19, wherein the step of changing the CERS includes sending a request to change the CERS via a playback device.

21. The step of receiving the request includes receiving the request via one or more computing devices associated with the media content service, The step of playing the media content via the playback device includes transmitting the media content to the playback device for playback from one or more computing devices associated with the media content service, The method according to any one of claims 1 to 20, wherein the step of modifying the CERS includes transmitting a request to modify the CERS via one or more computing devices associated with the media content service.

22. The method according to any one of claims 1 to 21, wherein the step of changing the CERS does not include sending a request to change the CERS via the playback device.

23. The method according to any one of claims 1 to 22, further comprising the step of outputting a user prompt indicating the redundancy identified in the CERS.

24. The method according to claim 23, further comprising the step of sending a verification command to update the CERS after outputting the user prompt.

25. The method according to any one of claims 1 to 24, further comprising the step of accessing second data stored in a distributed ledger in order to obtain a Content Network Record Set (CNRS).

26. The aforementioned CERS is associated with an identifier, The method according to claim 25, wherein the CNRS is associated with the same identifier.

27. The method according to claim 26, wherein the CNRS includes records of devices, media playback systems, and / or media content services associated with the identifier.

28. The aforementioned distributed ledger is a first distributed ledger maintained by multiple first distributed computing devices, The first instance of CERS is stored via the first distributed ledger, The second instance of CERS is stored via a second distributed ledger maintained by multiple second distributed computing devices. The method according to any one of claims 1 to 27, wherein the step of modifying the CERS includes modifying both the first instance of the CERS and the second instance of the CERS in the first distributed ledger and the second distributed ledger, respectively.

29. The method according to any one of claims 1 to 28, wherein the step of changing the CERS includes changing the CERS based on one or more trigger conditions.

30. Modifying the CERS based on one or more of the trigger conditions is: At predetermined intervals (for example, every hour, every day, every week, every month), After each media consumption event, After a threshold number of media consumption events, or After the user prompt, The method according to claim 29, comprising modifying the CERS.

31. The aforementioned CERS includes publicly accessible CERS data, The method further includes the step of updating a comprehensive content record set after playing the media content, The method according to any one of claims 1 to 30, wherein the comprehensive content record set includes both the publicly accessible CERS data and the data that is not publicly accessible.

32. The aforementioned playback device is a first playback device, The method according to any one of claims 1 to 31, further comprising the step of accessing data stored in the distributed ledger via a second device in order to obtain the CERS.

33. The method according to claim 32, wherein the second device includes a second playback device associated with the first playback device (for example, within the same household).

34. The method according to claim 32, wherein the second device is not associated with the first playback device (for example, a device belonging to another user, a device associated with a participating service provider, etc.).

35. The method according to any one of claims 1 to 34, further comprising the step of signing a transaction associated with a distributed ledger via the playback device.

36. The method according to any one of claims 1 to 35, further comprising the step of transferring one or more tokens associated with the distributed ledger to a destination address via the regeneration device.

37. The method according to any one of claims 1 to 36, further comprising the step of interacting with a smart contract being executed via the distributed ledger via the playback device.

38. The method according to any one of claims 1 to 37, further comprising the step of verifying a transaction via the distributed ledger through the playback device.

39. The method according to any one of claims 1 to 38, further comprising the step of staking one or more tokens via the distributed ledger via the regeneration device.

40. The method according to any one of claims 1 to 39, further comprising the step of causing the token reward associated with the distributed ledger to be received at a designated recipient address via the playback device.

41. The method according to claim 40, wherein the designated recipient address is associated with the playback device or a user account associated with the playback device.

42. The method according to any one of claims 1 to 41, wherein the playback device comprises a blockchain-enabled playback device having one or more dedicated processors configured to interact with the distributed ledger.

43. The method according to claim 42, wherein the one or more dedicated processors are configured to perform mining, staking, or verification processes associated with the distributed ledger.

44. The method according to claim 42 or 43, wherein the blockchain-enabled playback device is configured to run a node of the distributed ledger.

45. The method according to any one of claims 42 to 44, wherein the blockchain-enabled device is configured to run the wallet associated with the distributed ledger.

46. The method according to any one of claims 1 to 45, further comprising the step of using the playback device to execute a generation model based on at least the CERS data to generate a generation model output.

47. The aforementioned generation model includes a recommendation engine, The method according to claim 46, wherein the output of the generation model includes a system recommendation.

48. The generation model includes a generation media module, The method according to claim 46, wherein the generation model output includes generated media content.

49. One or more tangible, non-temporary, computer-readable media that, when executed by one or more processors, stores instructions causing the one or more processors to perform the method according to any one of claims 1 to 19.

50. One or more processors, The one or more computer-readable media described in claim 49, A media playback system equipped with the following features.

51. One or more processors, The one or more computer-readable media described in claim 49, A playback device equipped with the following features.

Images