Group playback

Abstract

In particular, there is disclosed a player device (10, 10a, 10b, 10c, 10d) for participating to a synchronized group media playback in a group (210) of player devices (10, 10a, 10b, 10d), the player device (10) being configured to control at least one hardware media renderer unit (1), the player device (10) being configured to: receive, from a remote cloud backend system (4), an information (37a, 38) of being part of the group (210) in a same local network, and, once having received the information (37a) of being part of the group (210): participate to a primary election, among the group (210), the primary election electing a primary player device (10a), the remaining player device or player devices (10b, 10d) in the group (210) being defined secondary player device or secondary player devices (10b, 10d); in case of the player device (10) being elected primary player device (10a), receive media content (51, 51a) from a content distribution network (5, 5a) and retransmit the media content (51, 51a) to the secondary player devices (10b, 10d), and in case of the player device not being elected primary player device (10a) and therefore resulting a secondary player (10b, 10d), receive media content (51, 51a) from the primary player device (10a), both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media renderer unit (1) to render the media content (51, 51a).

Description

[0001] Cl N240903PEP-2025001663. DOCX 1

[0002] Group Playback

[0003] Description

[0004] It is often difficult to control multiple remote playback devices receiving streams from remote. Techniques are here provided which address such a task.

[0005] Summary

[0006] According an example there is provided, inter alias, a player device for participating to a synchronized group media playback in a group of player devices, the player device being configured to control at least one hardware media Tenderer unit, the player device being configured to: receive, from a remote cloud backend system, an information of being part of the group in a same local network, and, once having received the information of being part of the group: participate to a primary election, among the group, the primary election electing a primary player device, the remaining player device or player devices in the group being defined secondary player device or secondary player devices; in case of the player device being elected primary player device, receive media content from a content distribution network and retransmit the media content to the secondary player devices, and in case of the player device not being elected primary player device and therefore resulting a secondary player, receive media content from the primary player device, both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit to render the media content.

[0007] According an example there is provided, inter alias, a backend system for assisting a streaming of remote media content towards a group of player devices connected to each other through a local network to perform a synchronized group media playback, the backend system comprising: an interface to at least one remote content distribution network, CDN, to receive content retrieval information to allow a reception of the media content from the CDN; an interface to user application to receive content selection selecting media content to be rendered; a device manager configured to: define at least one group formed by a plurality of remote player devices; command, to the remote player devices of the group, a content reception based on the content selection received from the user interface, and Cl N240903PEP-2025001663. DOCX 2 provide information of being part of the group to the remote player devices selected as being in the group, and provide the content retrieval information, to allow a reception of the media content from the CDN.

[0008] According an example there is provided, inter alias, a user application for requesting a streaming of a remote media content to group of player devices connected to each other through a local network to participate in a synchronized group media playback, the user application being configured to: provide, to a backend system, content selection selecting media content to be rendered; and provide commands on the player devices which shall be part of the group.

[0009] According an example there is provided, inter alias, a method for assisting a streaming of remote media content towards a group of player devices connected to each other through a local network to perform a synchronized group media playback, the method comprising: interfacing with at least one remote content distribution network, CDN, to receive content retrieval information to allow a reception of the media content from the CDN; interfacing with user application to receive content selection selecting media content to be rendered; defining at least one group formed by a plurality of remote player devices; commanding, to the remote player devices of the group, a content reception based on the content selection received from the user interface, and providing information of being part of the group to the remote player devices selected as being in the group, and providing the content retrieval information, to allow a reception of the media content from the CDN.

[0010] According an example there is provided, inter alias, a method for a user application requesting a streaming of a remote media content to group of player devices connected to each other through a local network to participate in a synchronized group media playback, comprising: providing, to a backend system, content selection selecting media content to be rendered; and providing commands on the player devices which shall be part of the group. Cl N240903PEP-2025001663. DOCX 3

[0011] Fig. 1 shows an example of an ecosystem involving the present technique.

[0012] Fig. 2 shows an example of a group according to the present technique.

[0013] Figs. 3A-3H show examples of an operational sequence according to the present technique.

[0014] Figs. 4A and 4B examples of an operational sequence according to the present technique. Fig. 5 illustrates procedures to be done by a device maker for producing the user device. Fig.

[0015] 6A illustrates an embodiment of the player device;

[0016] Fig. 6B illustrates an example of the cloud backend;

[0017] Fig. 6C illustrates an implementation of a user application apparatus;

[0018] Fig. 6D illustrates an implementation of the ecosystem.

[0019] Fig. 7 illustrates a sequence of messages for the purpose of user information handover

[0020] Here, reference is mostly made to an ecosystem in which there are a plurality of player devices 10 (lOa-lOd), an assisting system 4 (backend), at least one content distribution network (CDN) 5, a user application 3 for permitting control of a user 99. Notably:

[0021] 1) Each player device 10 may have an interface for a remote connection with the assisting system 4 and with each other player device 10 in the same local network

[0022] 2) The assisting system 4 may have: a) an interface for a remote connection with each player device 10 (e.g. forming at least one virtual device 110) b) an interface for a remote connection with the user application 3 c) an interface for a remote connection with at least one CDN 5

[0023] 3) Each CDN 5 may have: a) an interface for a remote connection with at least one player device (see below, a group primary player device and / o a virtual device primary player device) b) an interface for a remote connection with the assisting system 4

[0024] (but no interface with the user application 3, in some examples)

[0025] 4) The user application 3 may have: a) an interface for a remote connection with the assisting system 4

[0026] (but in principle no interface connected to player devices 10 or to at least one CDN 4).

[0027] Fig. 1 shows an example of an ecosystem of which the present invention is part. Fig. 1 shows a player device 10 (which may be instantiated in devices 10a, 10b, 10c, 10d). Each device 10 may control a device hardware 1 (which may be a display device and / or speakers (e.g. loudspeakers) and / or a hardware connection to the speakers. The device hardware 1 may be implemented in the same hardware in which the device 10 (10a-10d) is implemented, and it Cl N240903PEP-2025001663. DOCX 4 may also be that the device hardware 1 is the same hardware implementing the device 10 (10a-10d). Or, the hardware device 1 may be directly connected with contact (e.g. through a direct electric connection in closed vicinity) with the hardware implementing the device 10 (10a-10d). The hardware 1 may only have relay capabilities. The hardware device 1 may be controlled through a HAL 11. The device 10 (10a, 10b, 10c, 10d) may be configured to receive, from CDV 5 (5a) a media content 51 (which may include streams 51a) and / or from update network 6 (6b) update information 61b in some examples; notably, the update information 61 b may be sent from a different entity from 5a), from a media content distribution network (CDN) 5. The CDN 5 can be involved in a “content service”, based on an application programming interface, API, installed on the device 10 (e.g., in particular in the SDK / player 2, see below) for the connection with the CDN 5, which hosts the media content 51 to be received. There may be a plurality of content services (e.g., content media providers in concurrence with each other) which can be selectively chosen by the user of the user application 3. A cloud backend system 4 may control the player device 10 (10a, 10b, 10c, 10d), e.g., through content control 38 (e.g., 37a) and / or playback control (command) 34. The player device 10 may include a device software development kit (SDK) / player 2 (which may be integrated in the player device 10, or which may be directly connected to the player device 10 with only or substantially only replay capabilities). Fig. 1 does not show that the SDK / player 2 may have a HAL controlling block which controls the HAL 11 of the device hardware 1. The SDK player 2 may be part of, or may include at least a part of, an application layer platform which is generated by the developer of the player device 10 (or by a developer which implements the player device 10 onto a hardware or low-level platform of the player device 10). The SDK) / player 2 may also be called “media runtime device software”.

[0028] The media CDN 5 (5a) which provides the content is not the same as the cloud backend system 4. The content 51 is therefore not transported through the same connection as the control commands 34 and 38 (it may be that they both share the same physical connection, but anyway the content 51 and the control commands 34 and 38 are not in the same session).

[0029] The device SDK / player 2 may provide the media content (e.g., audio and / or video streams) to a content decryption service 28, which can therefore decrypt the media content 27 (combing from 51). The decrypted media content 29a may therefore be provided to a hardware media renderer unit 1. The hardware media Tenderer unit 1 may include a hardware abstraction layer (HAL) 11. The HAL 11 may be provided by an operating system. The HAL 11 may control the rendering of the audio and / or video. The HAL 11 (which may be integrated in the device SDK / player 2) may be controlled by hardware control and / or hardware events 26, e.g. sent by the device SDK / player 2. The device SDK / player 2 may provide the hardware control and Cl N240903PEP-2025001663. DOCX 5 hardware events 26 based, in particular, on the control 34 and 38 accepted by the cloud backend system 4. The player device 10 may be connected to a local network (e.g., LAN) 220.

[0030] The device SDK / player 2 may include a web browser 21. The device SDK / player 2 may include a media player 22. The device SDK / player may contain a cache 23 (e.g. in the media player 22). The device SDK / player 2 may contain a group playback entity 24.

[0031] The device SDK / player 2 may contain an updater 25, which may receive updated media content from the update CDN 6b. As can be seen from Fig. 1 , the player device 10 may receive content control 38 (e.g. content control commands), which may include, for example, information on queues 37 (it will be seen that there may also be a queue identifier 37a e.g. uniquely identifying the queue 37). Fig. 1 shows many queues 37, because it may be possible that information on multiple queues 37 is sent for multiple, different devices 10 (see also below). The content control 38 may provide information on the media content to be rendered (e.g. through the information on the queues 37), e.g. together with address (e.g., URLaddress) of where the media content 51 is to be retrieved (e.g. address of locations associated to the CDN 5, 5a). The cloud backend system 4 may transmit playback control commands 34. The playback control (command) 34 may include, for example, well-known commands, such as “PLAY” “PAUSE”, “STOP”, “FAST FORWARD”, “REWIND”. The command 38 therefore controls the rendering by the hardware devices 1 of the player devices 10a, 10b, 10d of the group 210, but has not a direct control on the reception of the stream 51 from the remote CDN 5. The cloud backend system 4 may therefore include a playback manager 33 and a device manager 35 which send the playback control 34, and the content control commands 38 respectively. It is to be noted that the device manager 35 may substantially have knowledge on the properties of the player device 10. The knowledge of the properties of the player device 10 may be achieved, for example, from setup information, which can be obtained, for example, at a time of a user’s subscription. The device manager 35 may have a virtual replica of the player device and may therefore have the substantial control of the operations of the player device 10. Both the playback manager 33 and the device manager 35 may be controlled through control commands 31 and 32 respectively. The playback control 31 may be received from a user application 3, which may be executed in a user equipment (e.g., a smart phone, mobile phone, tablet, assigned computer) of property of the user and / or may be integrated in the player device 10 (despite Fig. 1 suggesting that the user equipment and the player device 10 are not integrated in the same device, but they could be). The control device setup commands 32 may command the device management 35 on the groups to be formed between the device 10 and other devices (e.g., devices 10a, 10b, 10c, 10d) (it will be shown that the groups to be formed can be, in some examples, identified by the queues 37 to be reproduced). Therefore, the particular group may be defined by the user through the application 3. Cl N240903PEP-2025001663. DOCX 6

[0032] The application 3 may be provided e.g. by the cloud backend system 4 (or by an app store, such as Google Play Store, e.g. in a certified manner) to the user equipment or other device for controlling the player device 10 (and more in general all the player devices 10a-10d). The application 3 may present a user interface for obtaining settings (and / or comments and for commanding the devices 10a, 10b, 10c, 10d) to render content.

[0033] Even if between the application 3, the cloud backend system 4, the player device 10 and the media CDN 5 (5a) it is shown that the arrows are mostly directed towards one direction only, it is to be understood that these arrows mostly refer to the directions of the commands. It is notwithstanding possible that feedback information is transmitted in any different direction. For example, the application 3 may receive feedback from the cloud backend system 4 (e.g. to reproduced in a user interface), which in turn may receive the feedback from the player device 10. Also, the direction of the lines 51a and 61 b could be understood bidirectional, since one device (e.g. the primary device 10a, see below) may be the device which requests the transmission to the media CDN 5 (5a) and keep some contacts with the media CDN 5 (5a) (e.g. by sending requests relating to which representation of adaptation set of the media content to receive, e.g. in response to the reception of a manifest and based on the monitoring of the reception speed, and so on). It will be shown that the lines 51a can actually be deactivated for all the devices 10 (10b, 10c, 10c) which are not the primary devicelOa (see below). It is also to be noted that the connections 51a and 61 b may actually pass through the connection 220 (e.g. through a router).

[0034] The connections 51a and / or the connection 34 and 38 and / or the connection 31 and 32 and / or the local connection 220 may be either wireless connections, or wired connections, or partially wired and partially wireless connections. It is here mostly imagined that the connections 31 and 32 between the application (and the user equipment) and the cloud backend system 4 are mostly remote (e.g., through a mobile phone network, a telephone network, an internet connection, a TCP / IP connection, and so on). The cloud backend system 4 may be a cloud entity and may include a plurality of servers dislocated geographically. In any case, the cloud backend system 4 may include at least one server (e.g., a proxy server or connected to a proxy server) which may send at least one of the commands 34 and 38 to the player devices 10. (e.g., through a remote connection, including a mobile phone network, an internet, a telephone network, and so on). The devices 10 (10a, 10b, 10c, 10d) may be, instead, part of a local network (e.g. including a wireless local connection such as Wi-Fi, WLAN and / or a wired connection (e.g., a wired LAN, a internet, an intranet, and so on). The local network 220 may be partially wired and partially wireless (e.g., some devices 10 may be a wired connection to Cl N240903PEP-2025001663. DOCX 7 the local network 220, while other ones may be wirelessly connected to the wireless network 220.

[0035] Fig. 2 shows an example of a plurality of primary player devices 10 (each indicated with a particular letter after 10, e.g., 10a, 10b, 10c, 10d). Each of the devices 10 (10a-10d) may be like the device 10 of Fig. 1 (e.g. the same) and the local network 220 may be the same. Each of the player devices 10 (10a, 10b, 10c, 10d) may be connected with the cloud backend system 4, so as to receive commands 34 and 38 from the cloud backend system 4. In principle, each of the devices 10 (10a, 10b, 10c, 10d) may be connectable to the media CDN 5 (5a).

[0036] As explained above, the player devices 10 (10a, 10b, 10c, 10d) may participate to a synchronized group media playback (e.g., video playback and / or audio playback) together with the other player devices 10. Each player device 10, as explained above, may control the hardware media render unit 1 with the media content 51 . As can be seen in Fig. 2, there is the possibility that an active group 210 is formed by a plurality of player devices, in this case devices 10a, 10b and 10d (player device 10c not being active, i.e. not being in the active group 210). This choice may be made, for example, by the user (e.g., through the application 3, routed through the command 32, the device management 35, the control device queues 36, the content control 38, the player device 10 and in particular the device SDK 2, the hardware control and / or other events 26, the HAL 1 1 , and the hardware media renderer unit 1 ). It will be shown that there is the possibility that the information on the group 210 is intrinsically defined by the queue identifier 37a. In any case, what is most important is that from the plurality of player devices 10a, 10b, 10c, 10d, there is extrapolated a group of plural player devices (10a, 10b, 10d) which is meant at performing the synchronized group media playback. (It will be shown later that the synchronized media playback may include the synchronous rendering of sound and / or video content).

[0037] Fig. 3A shows an example of provision of the formation of the groups (e.g. group 210). In this case, information 37a is provided to the player devices 10a, 10b, 10d. As shown in Fig. 3A, information 37a is provided to player devices 10a, 10b and 10d (it is imagined that the information arrives in through the local network 220, i.e., that the content control 38 is transmitted through the local network 220 (e.g., through a router) but this is unnecessary (the information 37a could arrive through a remote connection)). The information 37 may be sent, for example, as addressed data packets (e.g. data packets which are uniquely sent to player devices 10a, 10b, 10d, while the data packets are not sent to the player device 10c). Therefore, each of the devices 10a, 10b and 10d understands that it is part of the active group 210. Fig. 3B does not show the device 10c which has been excluded from the group 210. It is Cl N240903PEP-2025001663. DOCX 8 to be noted that the device 10c can be in principle part of another active group (not shown) together with other player devices (not shown) (e.g. by following a different content command 38). As shown in Fig. 3C (and subsequently 3D), when receiving the information 37a of being part of the group 210, each player device (10a, 10b, 10d) in the group 210 sends a broadcast message 212. The broadcast message 212 may indicate to which group the player device is part of (e.g., each broadcast message 210 will have a field in which the information 37a is written). As shown in Fig. 3E (and 3F), each player device 10a, 10b, 10d of the group 210 also receives the broadcast messages 212 from the other player devices in the group. For example, the player device 10a reads the broadcast messages 212 sent from the player devices 10b and 10d; the player device 10b receives the broadcast messages 212 from the player devices 10a and 10d and so on. It will be shown that the broadcast message 212 sent by each player device 10a, 10b, 10d may also include (apart from the identification of the player device from which it originates) discriminating information attributed to itself (i.e. the sending player device) and / or the status of itself (i.e. the sending player device). The discriminating information may include at least one performance indicator of the sending player device which sends the broadcast information 212. The stability indicator may reflect the stability of the player device over time. The more unexpected reboots, crashes or corrupted received frames, the lower the stability will be. The discriminating information may include a performance indicator. The performance indicator may include the amount of RAM, CPU, available flash storage space, availability of hardware decoders and so on. The discriminating information may include the random value (e.g., a random integer value). The discriminating information may include at least a unique identifier of the sending player device.

[0038] The player devices 10a, 10b, 10d therefore elect (through election 749b) the primary player device 10a by examining the discriminating information of all the player devices in the group 210. For example, a rating may be defined for each player device 10a, 10b, 10d of the group 210 based on at least one of or a combination of the performance indicator, stability value, random value and unique identifier and defining the one which has the highest rating. Accordingly, the primary device may be elected implicitly without any device deciding which shall be the primary player device 10a. In particular, the cloud backend system 4 has no interest in deciding which will be the primary player device 10a, whose decision will only be defined by the devices in the group. An optional election result information (not shown in Figs. 3A-3H but shown as 349c in Fig. 4B) may be optionally be used, to inform the backend system 4 of the elected device 10a.

[0039] The primary player 10a, once elected, will be the one connected with the CDN 5 (5a) for receiving the media content 51 (also here the media content is shown as being obtained Cl N240903PEP-2025001663. DOCX 9 through the local network 220, e.g., throughout, but this is not strictly necessary) and the media content (51 ) could be received, for example, through remote network connection. Subsequently (Fig. 3H), the media content 51 (51 a) will be sent as content 218 to the secondary player devices 10b, 10d.

[0040] In the example of Figs. 3C, 3D, 3E, 3F it is shown that a broadcast message 212 is sent only indicating the information 37a of being part of the group or not while the discriminating information is sent only subsequently in a response message 214. Notwithstanding, it may also be possible that the response message 214 is not sent at all and only the broadcast message 212 is sent having, together with information 37a, also the discriminating information directed and coded there.

[0041] It is to be noted that the information 37 of being part of the group 210 may be implicit in the queue identifier 37a. Indeed, the content control commands 38 provides the information on the queue 37 together with the unique queue identifier 37a. This unique queue identifier 37a may therefore be implicitly understood as the group identifier since all the player devices 10 that share the same queue 37 end up being part of the same group 210. In particular in this case, the broadcast message 212 may be simply a notification that the player device 10 (10a, 10b, 10d) will render a particular queue of media content and the response message 240 will be the message containing the discriminating information.

[0042] Accordingly, while the cloud backend system 4 does not been to care of which device is the primary device 10a, the transmission of the media content 51 (51 a) may be uniquely performed by only the primary player device 10a, which therefore greatly reduces the amount of payload to be received.

[0043] In some cases, it is possible that the primary device 10a disappears or is anyhow not responsible of the transmission anymore or is too slow (e.g. the retransmissions of media content arrive with delay over a predetermined delay-threshold and / or arrive with error rate over a predetermined error-rate threshold). In that case, a new election may be performed by the player devices of the group. The further election may be the same of the previous election. The further election may take into consideration at least discriminating information attributed to the sending player devices and / or the status of the sending player device, exactly like in the previous election. In some examples, the previous primary player device 10a may also participate in the further election, but in other cases it may be excluded. In some examples, the discriminating information provided by each primary player device 10 (10a, 10b, 10d) may be in updated version (i.e., it may contain information which has been obtained during the Cl N240903PEP-2025001663. DOCX 10 distributed playback, and may include, for example, an updated performance indicator, at least one stability value attributed to the sending player device, at least one new random value, and / or unique identifier of the sending player device). In alternative examples, the choice of the new primary player device may be inherent in the previous election: for example, there may be performed a rating of all the player devices 10 in the group 210, in such a way that, when it is understood that the previous primary device 10a is not available anymore, then the second player device in the rating automatically takes over and start operating as a new primary device.

[0044] The player device 10 (10a-10d) may have a physical interface (e.g., buttons etc.) to receive commands for user’s command for playback event (e.g. “PLAY” “PAUSE”, “STOP”, “FAST FORWARD”, “REWIND”). In case of the player device 10 being the primary player device (10a), it may adopt the user’s command for playback event, and transmit, to the secondary player devices (10b, 10d), the user’s command for playback event. In the case of the player device 10 being a secondary player (10b, 10d), it may send a request to the primary player device 10a for accepting the user’s command for playback event controlling. In case the primary player device 10a for accepts the request, then the primary player device 10a will send a command for playback event to the secondary player devices 10b, 10d. Hence, all the player devices 10a, 10b, 10d of the group 210 will adopt the user’s command for playback event. E.g. in case of command “STOP”, all the player device 10a, 10b, 10d will stop the reproduction of the media content.

[0045] In some cases, it is possible to command urgent events to be adopted immediately (e.g., volume control). In this case, even if the player device is a secondary player device, it may notwithstanding control its hardware Tenderer unit 1 to adopt the command. Then the secondary player device may (in some examples) send a request to the primary player device to adopt the urgent command. The primary device will adopt the urgent command, and will send a request with the urgent command to the other secondary player devices.

[0046] Notably, the primary player device 10a may synchronize the other player devices 10a, 10d of the group 210. For example: the primary player device (10a), sends, to each secondary player device, synchronization information; each secondary player device (10b, 10d) receives the synchronization information and synchronizes its rendering to the received synchronization information. Cl N240903PEP-2025001663. DOCX 11

[0047] Notably, the device hardware 1 may be controlled through a HAL 11 , which in turn is controlled by control and / or hardware control and / or hardware events 26. The cloud backend system 4 (having knowledge of the particular version of the HAL 11) may therefore provide, to the primary player device 10a an address of the media content according to a format compatible with the particular version of the HAL 11. Therefore, there is the possibility that the primary player device 10a does not receives application program interfaces, APIs, during the synchronized group media playback. The advantage is considerable, because otherwise the primary player device 10a should also retransmit the APIs to the other player devices 10b and 10d of the group 210, uselessly clogging the local connection 220. Notably, the cloud backend system 4 has therefore knowledge of the HAL version of each player device 10, but does not need to care of which player device will be elected.

[0048] More in general, each player device (or at least one of them) may send to cloud backend system 4 configuration data. The configuration data may include configuration data of the controlled hardware media Tenderer unit 1. The cloud backend system 4 may therefore define the group 210 based on the configuration data of the player devices at disposal. The configuration data may include configuration data of an operating system used by the player device. Further, the cloud backend system 4 (having knowledge of the configuration data) may provide, to the primary player device 10a, an address of the media content according to a format compatible with the particular version of the HAL 11. Therefore, the primary plyer device 10a and the CDN 5 (5a) shall have a reduced handshaking, without the exchange of configuration data.

[0049] Each player device (or at least one of them) may send to cloud backend system 4 information on playback capabilities and / or playback conditions. For example, information on the capability of video displaying (and / or video display quality, such as video resolution) may be provided to the cloud backend system 4. In addition or alternatively, information on the capability of audio rendering (and / or audio quality, such as resolution) may be provided to the cloud backend system 4. Based on the information on playback capabilities and / or playback conditions, the cloud backend system 4 may decide which format of media content to be provided by the CDN 5 (5a) to the primary player device 10a. For example, if in the group 210 all the player devices have video capabilities but no audio capabilities, then the cloud backend system 4 will refrain from addressing the primary device 10a to also receive audio content. If, instead, in the group 210 all the player devices have both video capabilities and audio capabilities, then the cloud backend system 4 will address the primary device 10a to also receive audio content. Cl N240903PEP-2025001663. DOCX 12

[0050] The configuration data may include configuration data of the controlled hardware media renderer unit 1. The cloud backend system 4 may therefore define the group 210 based on the configuration data of the player devices at disposal. The configuration data may include configuration data of an operating system used by the player device. Further, the cloud backend system 4 (having knowledge of the configuration data) may provide, to the primary player device 10a, an address of the media content according to a format compatible with the particular version of the HAL 11. Therefore, the primary plyer device 10a and the CDN 5 (5a) shall have a reduced handshaking, without the exchange of configuration data.

[0051] It is possible to apply the present technique to a video-wall application. The synchronized group media playback may include a video wall playback where multiple, adjacent player devices of the same group (210) cooperate to generate a video wall displaying a global video content, each player device displaying a portion of the global video content. The player device (10) may: in case of being the primary player device (10a), receive the media content (51 , 51a) of the global video content from the content distribution network (5, 5a), separate the global video content among a plurality of video content portions, and retransmit, to each player device (10) of the group (210) a video content portion to be displayed synchronously; and in case of being a secondary player device (10b, 10d), receive the video content portion from the primary player deice (10a) and render the received video content portion.

[0052] Despite the fact that the video-wall application may have the possibility of separating the vides content among the plurality of video content portions, and retransmit them to the different secondary player devices (10b, 10d), it may be that the media (e.g. audio and / or video) stream 51 is not processed by the primary player device 10a, but only relayed (e.g. as it is) to the secondary player devices 10b, 10d. This choice may imply, for example, that each of the secondary player devices 10b, 10d shall processed and / or decoded and / or decrypt the media stream 51 of its own. However, this has the advantage that the primary player device 10a shall not waste time and computational power for processing and / or decoding and / or decrypting the media stream 51. In other cases, instead, the primary player device 10a may decode the media stream 51 , process it (e.g. by deleting some portions, e.g. by suppressing at least one audio and / or video channel) and retransmitting the content 51 (as 218, Figs. 3G and 3H), either in re-encoded form or in uncompressed form. In addition or alternatively, the primary player device 10a may (either after having decoded, processed, and, optionally, re-encoded, or without any deciding and / or processing) decrypt the content 51 and retransmit it (either reencrypted or not re-encrypted) to the secondary player devices (10b, 10d). Cl N240903PEP-2025001663. DOCX 13

[0053] In examples above, it is often referred to the queue 37. However, instead of the queue 37, it is also possible that the cloud backed system 4 also sends other information to the player devices 10, to define the group 210. The cloud backed system 4 may send more general content retrieval information (more general than the information on the queue) 37 informing of media content to be retrieved from the CDN 5 and to be subsequently rendered, so that: the primary player device (10a), receives, from the CDN (5, 5a), the media content indicated in the content retrieval information and retransmits the media content to the secondary player device or secondary player devices (10b, 10d); and the secondary player devices (10b, 10d), receive, from the primary playback device 10a, the media content associated with the content retrieval information.

[0054] For example the content retrieval information (37) may include at least one address of the media content to be retrieved and / or information to be provided to the CDN (5) to request the media content. In this case: the cloud backed system 4 sends to the player devices 10 the at least one address of the media content to be retrieved and / or information to be provided to the CDN (5) to request the media content; the primary player device 10a, receives, from the CDN (5, 5a), the media content indicated in the content retrieval information; and the primary player device 10a retransmit to the secondary player devices (10b, 10d), the media content.

[0055] The content retrieval information (37) may include authenticating information (e.g. in combination with the queue information or other content retrieval information) for authenticating at least one player device to receive the media content from the CDN (5). In this case: the cloud backed system 4 sends to the player devices 10 the authenticating information (e.g. in combination with other retrieval information, such as a queue information and / or at least one address of the media content to be retrieved and / or information to be provided to the CDN 5 to request the media content); the CDN 5 checks the authenticating information (either independently, or by requesting further authenticating information from the cloud backed system 4); once authenticated, the primary player device 10a, receives, from the CDN (5, 5a), the media content; and the primary player device 10a retransmit to the secondary player devices (10b, 10d), the media content. Cl N240903PEP-2025001663. DOCX 14

[0056] In any of the cases above, the content retrieval information 37 may be identified (e.g. uniquely) by an identifier 37a. The identifier 37a may, in some cases, also be used to identify a particular group 210.

[0057] The cloud backend system 4 may operate as an authenticating system which authenticates the primary player device 10a. For example, the cloud backend system 4, may send to the primary player device 10a authenticating information for receiving the media content, so that the primary player device 10a, by sending the authenticating information for receiving the media content to the CDN (5, 5a), results authorized to receive the media content (51 , 51a) from the CDN (5, 5a). The cloud backend system 4, therefore, may receive authenticating information for receiving the media content from the CDN (5, 5a) and may provide them to the primary player device 10a.

[0058] On the other side, the cloud backend system 4, may receive authenticating information from all the player devices 10a, 10b, 10c, 10d for being part of the group 210. The authenticating information for being part of the group 210 may be credential managed by the cloud backend system 4 at the time of subscribing to the service, provided by the cloud backend system 4, at the time of a user (owner of the player devices 10a, 10b, 10c, 10d) subscribes to the service provided by the cloud backend system 4. In examples, only the player devices which are correctly authenticated with the authenticating information for being part of the group 210 can participate to the synchronized group media playback.

[0059] In some examples, once the cloud backend system 4 has received the authenticating information for being part of the group 210 by at least one of the player devices 10a, 10b, 10c, 10d, it provides authenticating information to the CDN (5, 5a) indicating which player devices 10a, 10b, 10c, 10d are authenticated. Alternatively, as explained above, the cloud backend system 4, sends to the primary player device 10a authenticating information for receiving the media content, so that the primary player device 10a, by sending the authenticating information for receiving the media content to the CDN (5, 5a), results authorized to receive the media content (51, 51a) from the CDN (5, 5a).

[0060] The cloud backend system 4 (which may be a system for assisting the streaming and rendering of the remote media content 51) may comprise an interface for interfacing to the CDN 5 (5a). The cloud backend system 4 may include an interface for interfacing with the player devices 10 (10a, 10b, 10c, 10d). The cloud backend system 4 may be connected with the mobile application 3 (e.g. through a remote connection, e.g. through a suitable interface). The mobile application 3 may be installed in a user equipment, which may be the same as Cl N240903PEP-2025001663. DOCX 15 one of the player devices 10 (10a, 10b, 10c, 10d) and / or may a different external device. The mobile application 3 may be configured for obtaining requests from any playback commands. The mobile application 3 may in addition or alternatively, provide content commands 31 and 32 (i.e., commands 32 indicating which media content to be played back, which will cause the generation, by the cloud backend system 4 and in particular by the device manager 35, of the queue 37 to be rendered, and the generation of the group 210). The cloud backend system 4 (and in particular the playback manager 33) may receive, from the mobile application 3, playback command requests 31 (e.g. “PLAY” “PAUSE”, “STOP”, “FAST FORWARD”, “REWIND”). The playback manager 33 of the backend system 4 may send the playback command requests 31 in according to versions 34 e.g. only to the primary player device 10a (and not to the totality of the player devices 10a, 10b, 10d of the group 210), hence minimizing the playback control traffic (34). If the primary player device 10a receives the backend’s command 34 for playback event from the cloud backend system 4, it will replay the command 34 (e.g. through messages like messages 218 in Figs. 3G and 3H), each of the receiving secondary devices 10b, 10d will adopt the command 34. Instead, it has been noted that it is preferable that each device 10 of the group 210 (whether it is the primary 10a or the secondary 10b, 10d) receives content control commands 38 (e.g. including information 37, 37a, which may also implicitly define groups in some examples). It will be shown that an information 749c (Fig. 4B) may be sent from one of the devices 10a, 10b 10d of the group 210 to indicate which is the elected primary 10a.

[0061] The cloud backend system 4 may define the group 210 formed by multiple remote player devices 10 (10a, 10b, 10c, 10d), being connected with each other through the local connection 220. The group 210 may provide a semantically unitary media scene to a user 99 in some cases. The player devices 10 (10a, 10b, 10c, 10d) may therefore participate to the synchronized media playback, where each player device 10 (10a, 10b, 10c, 10d) could have a particular role in the media rendering (in some cases, however, they may all perform the same playback, without differences).

[0062] As explained above, the cloud backend system 4 may be interfaced with the CDN 5 (5a) to authorize the primary playback device 10a to receive the media content 51 (51a). The authorization may be routed through the remote connection between the cloud backend system 4 and the CDN 5 (5a). The cloud backend system 4 may perform an authorization procedure to authorize the player devices 10 forming the group 210 to receive the media 51 (51a). Importantly, the group 210 can be considered as one single device receiving the media stream (and this is important for the subscription). The cloud backend system 4 may provide, to the CDN 5, authentication data for authenticating at least one of the remote player devices Cl N240903PEP-2025001663. DOCX 16 which receives the media content from the CDN. In addition or alternatively, the cloud backend system 4 may receive from the CDN 5 an authenticating information and provide the authenticating information to at least one of the remote player devices, so that the primary player device 10a, by presenting the authenticating information to the CDN 5, can receive the media content from the CDN.

[0063] Examples of Figs. 4A and 4B

[0064] Fig. 4A and 4B illustrate a procedure showing a sequence of steps / message between the user 99, the user application 3, the cloud backend system 4, the media runtime device software 2 (e.g. in the primary player device 10a) and the content service (CDN) 5 (5a) for playing content with the cloud ecosystem. The playing of content of the uploading of content within the ecosystems involves of the corresponding participants of the ecosystem such as device makers, content services, users. Furthermore, it is to be noted that the heavy-weight data or content is retrieved directly by the media runtime device, Owhile the cloud backend only handles the playback commands. The data of authorized devices 10 (e.g. 10a, 10b, 10c, 10d) and authorized content services for a user are stored and retrieved from databases that are part of the cloud backend. These databases contain all data that is necessary for authorized access to a content service, where tokens are needed for access. When, in the Fig. 4A, Fig. 4B diagram such data is looked-up in the cloud backend, it is retrieved from a corresponding database 208.

[0065] Furthermore, it is to be noted that the illustration in Fig. 4A makes clear that each message, such as message 700, between the user application 3 and the cloud backend system 4 refers to two actions of the entities involved. The first action is that the user application sends out the message 700 via the cloud backend interface 304, and the second action performed by the cloud backend system 4 is that the cloud backend system 4 receives the message 700 via the application interface 206.

[0066] Subsequently, Fig. 4A and Fig. 4B are discussed in more detail.

[0067] In the action 602, the user 99 opens the user application 3 running on the user application apparatus. In step 603, the user logs into the user application and, in reply to this logging into the app, the user authenticates itself via the message 700 from the user application to the cloud backend. Then, in order to further use the cloud backend, the user receives a token (which is an authenticating information) including the user’s permissions and the corresponding user I D in message 605. The user token is used in all calls to the cloud backend to identify the user and to check if access is allowed for the requested function for the user. Cl N240903PEP-2025001663. DOCX 17

[0068] Then, in order to finally come to a playing of a media content, the user application sends a request for a list of content services illustrated at 702. All content services that are authorized in the cloud backend are returned. Each content service is either authorized or not authorized by the user. Hence, due to the fact that the cloud backend replies to this message 702, with a full selection of content services authorized in the ecosystem, the selection what is valid for the specific user is performed in step 704. Here, the cloud backend checks, which content services are actually authorized for the user.

[0069] Then, for each identified content service, it is checked, if the user is allowed to use the content service, if the user is not allowed, the content service is removed from the result. In a step 708, it is checked, whether the content service allows the user. Probably, the user is denied for some reason, for example by not paying a bill, etc. This is done in step 708. Then, in step 710, the cloud backend returns a list of allowed content services to the user application.

[0070] This list is presented to the user via the user interface in the user application and the user then selects a content service from the list provided 710 in the step 712. Then, based on the selected content service, the user application 3 requests a list of content in message 714.

[0071] In response to that, the cloud backend system 4 looks up, whether credentials (which are authenticating information) for this content services are stored in the cloud backend. This is done in step 716, and when such user credentials for the requested content service are found, an authentication message 718 is sent from the cloud backend to the content service via the communication interface 204 of the cloud backend. The result message 720 is illustrated in Fig. 4A and the result message can, for example, comprise a certain token (which is an authenticating information), from the content service, or any other positive authentication result.

[0072] In response to the positive result 720, the cloud backend requests content metadata in a message 722 from the content service 5 (5a), and the content service 5 (5a) sends back the requested content metadata in message 724. The content metadata in message 724 may also be authenticating information, which is provided to the content service 5 to receive, under authorization, the content 51 (51a).

[0073] This list of content is then forwarded from the cloud backend to the user application in step 725 for display to the user 99 via the user interface 302. Cl N240903PEP-2025001663. DOCX 18

[0074] The user 99 selects a content for replay as shown in action 726 and, then, the user application requests allowed devices 10 (e.g. 10a, 10b, 10c, 10d) for the selected content from the cloud backend.

[0075] As illustrated in action 730, a list of devices 10 (e.g. 10a, 10b, 10c, 10d) that are authorized by the user is looked-up and, then, processed by means of steps 732 to 742.

[0076] This procedure represents the check, if a certain device 10 (e.g. 10a, 10b, 10c, 10d) is allowed from the list of devices 10 (e.g. 10a, 10b, 10c, 10d) that have been originally authorized by the user. Any negative answer in the list consisting of item 732 to 742 will exclude a corresponding device under consideration from the result.

[0077] Step 732 starts the processing sequence. However, the sequence of steps between 732 to 742 is arbitrary and any other sequence also provides a useful result.

[0078] Instead 734, it is determined, whether the content service under consideration allows the device brand of the user device. The information for answering this question is located in certain database 208 in the backend.

[0079] In step 736, it is determined, whether the device maker allows the content service 5 under consideration.

[0080] This is also determined from a certain database.

[0081] Furthermore, in step 738, it is determined whether the device maker allows the playback of the content that has been selected to play in step 726.

[0082] Furthermore, in step 740, it is determined, whether the user actually allows to playback the content on the device. This procedure is useful, when, for example, a certain profile of allowed content has been installed in the cloud backend, for example for the purpose of children control.

[0083] Now, it can be that the child acts as a certain user 99, and therefore, it can easily be that the child requests a content to play that, however, is not allowed to be played back on the device as defined earlier when establishing the certain profile in a library of the cloud backend. Cl N240903PEP-2025001663. DOCX 19

[0084] Finally, it is determined whether the actual user device 10 (e.g. 10a, 10b, 10c, 10d) under consideration is online and ready.

[0085] Only when all the answers in the list are positively answered, a device 10 (e.g. 10a, 10b, 10c, 10d) survives in the list of allowed devices that is referred back from the cloud backend system 4 to the user application via message 744.

[0086] Then, the user 99 (e.g. through the user application 3) may reply through an action 745 (which may trigger action 748 which may include, or be an instantiation of the control device setup commands 32 in Fig. 1) for selecting the group 210 of devices (e.g. 10a, 10b, 10d which will form the group 210 as requested by command 38) from the list of allowed devices (e.g. the list including 10a, 10b, 10c, 10d). Then, the user 99 (e.g. through the user application 3) may start the playback of the selected content on the selected group 210 of devices via action 746 (which may trigger action 748 which may include, or be an instantiation of, playback command request 31 in Fig. 1). This user action 746 may result in the message 31 from the user application 3 to the cloud backend system 4 that requests the playback for the selected content on the selected devices (e.g. 10a, 10b, 10d, intended to form the group 210), where this message is illustrated at 748 in Fig 4B.

[0087] At this point, the procedure of Figs. 3A-3F may start. The backend system 4 (e.g. the device manager 35) may send (action 749a) content retrieval information 37, 37a (e.g. queue and queue identifier, or more in general group and group identifier) as 36 and 38 to the selected devices 10a, 10b, 10d (the unselected device 10c being excluded, for example, from receiving the information 37 and 37a) forming the group 210 identified by the identifier 37a. The election 749b (see Figs. 3C-3F) may occur. Optionally a message 749c (election result) from one of the player devices 10 (e.g. from the elected primary device 10a, but it could also be sent by any of devices 10b, 10c, 10d, according to the invention) indicates that the device 10a has been elected as primary.

[0088] The content metadata (including authorization information) may be sent (750) from the cloud backend system 4 to the media runtime device software 2 on the primary user device 10a (while the device 10c excluded from the group 210 and the secondary devices 10a and 10d may be excluded from receiving the content metadata with the authorization information). This content metadata 750 can, for example, be or include a playable URL or any other data, by which the media runtime device software 2 running on the group of user devices 10 (10a, 10b, 10d) can request the content via a message 752 from the user device 10a via the connection to the typically remote data instances illustrated at 51 in Fig. 1. The request 752 may include Cl N240903PEP-2025001663. DOCX 20 or be accompanied by authentication information (e.g., obtained in message 748 from the backend system 4) which allows the CDN 5 to determine that the device 10a is authorized to receive the content. Then, as soon as the playable URL, for example, is received by the remote data instance 5, the remote data instance 5 streams back the content 51 as shown in message 756 (only to the primary device 10a) and this takes place via media interface of the primary user device 10a and the content is replayed as illustrated at 754 (of course, at 754 the primary device 10a forwards the content 51 as 218 to the secondaries, like in Figs. 3G and 3H). The authenticating information from the primary player device 10a to the CDN 5 may be verified by the CDN 5. Or, the unique address of the primary player device 10a may be verified by the CDN 5, the unique address of the primary player device 10a serving as authenticating information.

[0089] Fig. 4B additionally illustrates the procedures that are done, when the user 99 wishes to control the playback via message 760. This control can, for example, be a pause action, a stop action, etc. As soon as the user application 3 has received a message from the user such as message 760, the user application 3 replies with a request control playback message 762 (which may include or embody the playback control command 31 of Fig. 1) to the cloud backend system 4. Only when the cloud backend system 4 confirms that such a procedure is allowed, where this check is not illustrated in Fig. 4B, the cloud backend system 4 requests control playback via message 764 (which may include or embody the playback control 38) from the media runtime device software 2 of the primary device 10a. As soon as the control message 764 (e.g. 38) is received by the user device via the user application 3, the user application 3may react with an execution of the playback control illustrated at 766 and report this executed control via step 768 back to the cloud backend 4 and a corresponding confirmation is sent from the cloud backend system 4 back to the user application via message 770. As explained above and below, however, commands may also be provided directly on the primary playback device 10a (which are then forwarded to the secondary devices 10b and 10d) and / or on the secondary devices (10b, 10d), which are notwithstanding forwarded to the primary device 10a).

[0090] It is to be emphasized that the order of the selection of the content service 712, the selection of the content to play 726, and the selection of the devices from the list of allowed device 745 can also be done in a different order. Furthermore, in case of only a single content service and only a single user device, several checks and messages can be omitted in order to nevertheless implement the full control of the cloud backend system 4 over the user device, which the media runtime device software 2 is installed. Cl N240903PEP-2025001663. DOCX 21

[0091] In general terms, the user application 3 may receive from the backend system 4 a list of content services 5 (e.g., different content providers in competition between each other), and request to the user 99 a selection of a preferred content service. Once the user has selected the preferred content service, the user application may transmit to the backend system 4 information on the selected content service. (This is not necessary in the cases in which there is only one single content service at disposal).

[0092] The user application 3 may receive (e.g. once the preferred content service has been selected) from the backend system 4 a list of content provided by the specific selected content service 5, and request to the user 99 a selection of a preferred content 51 to be received. Once the user has selected the preferred media content 51 , the user application 3 may transmit (e.g. as part of the command 32) to the backend system 4 information on the selected media content 51. The request may indicate a queue 37.

[0093] In parallel or before or after, the user application may receive (e.g. at 744) a list of player devices 744 allowed to be part of the synchronized group playback (e.g. allowed to be part of the group 210). The list may also provide the capabilities of each selectable player device (e.g.,. audio capabilities, video capabilities, etc.), so that the user application 3 may display the capabilities of each selectable player device. The user 99 may select through the user application 3 the player devices 10a, 10b, 10d to be part of the group 210 from a list of selectable player devices provided by the backend system 4. The user application 3 may transmit to the backend system 4 the group information as part of the command 32. The backend system 4 (and in particular the device manager 35) may therefore apply the content queue 37a (or other group identifier) and send the information on the queue 37 and the queue identifier 37 to all the selected player devices 10a, 10b, 10d. The user application 3 and the backend system 4 will be uninterested to the election procedure (but in some cases, simply a notification (749c) of which is the primary device 10a will be received by the backend system 4 from the primary device 10a or another of the player devices 10.

[0094] Synchronization

[0095] It is now explained a technique according to which the primary player device 10a can synchronize the playback between the whole group 210. Notably, the backend system 4 can be completely agnostic on the synchronization.

[0096] At first, the primary player device 10a may send, periodically, in the local connection 220, a beacon packet having a clock signal data field in which there is encoded information on the current time according to the primary player device 10a (the current time may include, for Cl N240903PEP-2025001663. DOCX 22 example, the current time as known by the primary player device 10a from its internal clock, or the playback time which is an incremental time of the media stream as authored currently played back by the device hardware 1 of the primary player device 10a). Accordingly, each secondary player device (10b, 10d) has knowledge of the current time at the primary player device 10a. There may be provided solutions for also taking into account the delay in the transmission of the beacon signal (for example, the secondary player device 10b, 10d may measure the time instant at which the beacon packet is received and add it to the time indicated in the clock signal data field in the beacon packet). In any case, each secondary player device (10b, 10d) may resynchronize to the clock of the primary player device 10a.

[0097] Moreover, each secondary player device (10b, 10d) may transmit an acknowledgment packet in which it replies to the beacon packet. Each secondary player device (10b, 10d) may also indicate, in a time stamp data field of the acknowledgement packet, the playback time (i.e. incremental time of the media stream as authored and which is currently played back by the device hardware 1 of itself, secondary player device 10b or 10d) which is currently rendered (e.g., an indication of which second of film is currently displayed). Accordingly, the primary player device 10a has the knowledge of the latency impairing the playback at each secondary player device (10b, 10d). The primary player device 10a may calculate the delay of each secondary player device (10b, 10d), by keeping into account the time necessary for receiving the acknowledgement packet after having transmitted the beacon packet: for example, the time delay from the primary player device’s transmission of the beacon packet and the primary player device’s reception of the acknowledgment packet from each secondary player device (10b, 10d) may permit to estimate the actual time instant at which a particular media content (e.g. a particular photogram and / or a particular audio frame) is rendered by each secondary player device (10b, 10d). The latency may be estimated, for example, as the time delay for receiving the acknowledgment packet divided by two, thus inferring the latency of each secondary player device (10b, 10d) in the group 210. By inferring the time instant in which each secondary player device (10b, 10d) has actually rendered a particular media content, the primary player device 10a may also synchronize all the secondary player devices (10b, 10d) and its device hardware 1. For example, the primary player device 10a may indicate, in one field in the beacon packet, also the latency of each of the secondary player devices (10b, 10d). Therefore, each secondary player device (10b, 10d) will know its own latency and will resynchronize the rendering of its media content to the timing of the primary player device 10a (e.g. causing its playback time to coincide with the playback time of the primary device 10a by subtracting the latency from the currently rendered playback time). The primary player device 10a may also transmit a presentation time stamp encoded in a presentation time stamp field of the beacon packet, indicating its playback time, i.e. the timing instant which is currently Cl N240903PEP-2025001663. DOCX 23 played back by its device hardware 1 (or anyway, the scheduled time which the primary player device 10a wants a particular media content to be rendered). The primary player device 10a may control the rendering of the media content based on the latency of the secondary player devices (10b, 10d): for example, the primary player device 10a may reschedule the rendering of the media content base on the maximum latency among the secondary player device (10b, 10d), so as to permit all the device hardware 1 to be synchronous.

[0098] Alterative techniques may be taken into consideration.

[0099] More in general, it may be required that:

[0100] 1) The primary player device 10a provides, to the secondary player devices 10b, 10d, information on its own timing.

[0101] 2) Each secondary player device 10b, 10d synchronizes to the timing of the primary player device 10a.

[0102] For example, it may be required that:

[0103] 1) The primary player device 10a provides (e.g. in the beacon message), to the secondary player devices 10b, 10d, information on its current playback time (e.g. which time instant of the media stream as authored is currently played back).

[0104] 2) Each secondary player device 10b, 10d provides, to the primary player device 10a, information on its current playback time.

[0105] 3) The primary player device 10a calculates the latency of each secondary device 10b, 10d, and indicates to each of them, in a subsequent message, the latency information of each secondary device 10b, 10d, so that each secondary device 10b, 10d changes the playback time to be rendered to be its previous playback time in accordance with the latency.

[0106] For example, it may be that:

[0107] 1) The primary player device 10a provides (e.g. in the beacon message), to the secondary player devices 10b, 10d, information on its own timing (e.g. information on the playback time currently rendered and / or information on its own internal time from its own clock).

[0108] 2) Each secondary player device 10b, 10d provides information on its own timing (e.g. information on the playback time currently rendered).

[0109] 3) From the information on each own timing of the secondary player devices, the primary player device 10a obtains the knowledge on the latency of each secondary player device, and provides resynchronization information (e.g., to each of the secondary player devices. Cl N240903PEP-2025001663. DOCX 24

[0110] For example, it may be that:

[0111] 1) The primary player device 10a provides (e.g. in the beacon message), to the secondary player devices 10b, 10d, information on its own timing (e.g. information on the playback time currently rendered and / or information on its own internal time from its own clock).

[0112] 2) Each secondary player device 10b, 10d provides information on its own timing (e.g. information on the playback time currently rendered).

[0113] 3) From the information on each own timing of the secondary player devices, the primary player device 10a obtains the knowledge on the latency of the each secondary player device 10b, 10d in the group 210, and in particular of the latest of the secondary player device 10b, 10d in the group 210.

[0114] 4) Subsequently, the primary player device 10a provides resynchronization information to each of the secondary player devices indicating the latency that has to be observed to each of the secondary devices 10b, 10d in the group 210, to be synchronized with each other

[0115] For example, it may be: the primary player device 10a sends information on its own timing to each secondary player device (10b, 10d) in the group (210) (the information on its own timing including either information on the playback time which is currently rendered or the internal timing as obtained from its internal clock), each secondary player device (10b, 10d) in the group sends information on the playback time which is currently rendered by itself (the secondary player device), thereby providing knowledge on the latency impairing itself (the secondary player device) between the playback time at the primary player device and the playback time at each secondary player device; and the primary player device 10a sends resynchronization information to each secondary player device in the group 210, the resynchronization information indicating the latency impairing the secondary player device; and so that each resynchronization information resynchronizes its internal clock or its playback time based on the latency.

[0116] More in the specific, it may be: the primary player device 10a sends information on its own timing (e.g. including either information on the playback time which is currently rendered or the internal timing as obtained from the primary device’s internal clock) to each secondary player device (10b, 10d) in the group (210), Cl N240903PEP-2025001663. DOCX 25 each secondary player device in the group provides information on the playback time which is currently rendered by itself (the secondary player device), thereby obtaining knowledge on the latency impairing each secondary player device in the group between the playback time at the primary player device and the playback time at each secondary player device, so that the primary player device 10a determines the latest secondary player devices among the latest secondary devices in the group; and the primary player device 10a sends resynchronization information to each secondary player device in the group indicating additional latency to be observed by the addressed secondary device, so that the addressed secondary player device resynchronizes to the secondary player device in the group which is impaired by highest latency; and both the primary player device 10a and the secondary player devices (10b, 10d) resynchronize to the latest secondary device by synchronizing the playback time by inserting the additional latency.

[0117] Discussion

[0118] Group Playback is a functionality, that allows Devices 10 which have one or more speakers, and / or one or more video displays (collectively indicated with 1), each device 10 being connected to a SoC (silicon on chip) 1 which can control the speaker(s) and / or display(s) (in Fig. 1 the reference numeral 1 may indicate indifferently the SoC and any of the speaker(s) and display(s)) and that are provided with the Media Runtime Device Software and could be located in the same local area network (LAN), each Device connected to the internet, to play back the same content in the same order at the same time.

[0119] Such devices 10 (10a, 10b, 10c, 10d) as referenced above are referred to as Player device(s) hereafter. Players 10 (10a, 10b, 10c, 10d) can be grouped by the Cloud Backend 4 arbitrarily and the layout of groups is not restricted, i.e. , any combination of Players 10 can compose a group (see Fig. 2, where the group 210 is formed by the players 10a, 10b, 10d).

[0120] A Player 10 (10a, 10b, 10c, 10d) can be member of none, one, or multiple groups. At playback time only one group containing the same Player 10 (10a, 10b, 10c, 10d) can be active, i.e., the Player 10 (10a, 10b, 10c, 10d) consumes content from one group (e.g. 210 in Fig. 2) at a time. The group that is currently selected and active, that a Player 10 (10a, 10b, 10c, 10d) is part of, is called ACTIVE GROUP hereafter (indicated with 210 in Fig. 2).

[0121] The Active Group 120 and its content are controlled and changed by the Cloud backend system 4. The Player 10 (10a, 10b, 10c, 10d) only plays a passive role and reacts to playback changes sent by the Cloud backend system 4. Cl N240903PEP-2025001663. DOCX 26

[0122] The references to the content that will be played back is contained in an ordered queue (e.g. 37 in Fig. 1). The content of the queue 37 is fully controlled by the Cloud backend system 4. Each queue 37 contains an identifier that uniquely identifies the queue 37 and an indicator, if it is the content of an Active Group 210.

[0123] On activation of a Group Playback (i.e. playback of player devices 10a, 10b, 10c in Fig. 2, each Player 10 (i.e. 10a, 10b, 10d) of the Active Group 210 receives a queue 37 that is flagged as group queue from the Cloud Backend 37. All Players 10 (10a, 10b, 10d) that belong to the Active Group 210 share the same queue 37 with the same unique identifier. When a Group Playback is activated, all Players 10 (10a, 10b, 10d) that belong in the same LAN network (or more in general local network) 220 in the group 210 organize themselves by determining a primary Player and declaring all others as secondaries. This is called Primary Election hereafter. In Fig. 2, the primary player is indicated with 10a, and the secondary players are indicated with 10b and 10d.

[0124] Primary election

[0125] Every Player 10 (10a, 10b, 10d) of the Active Group 210 sends a broadcast message 212 containing the unique queue identifier to the local network. If a Player 10 (10a, 10b, 10d) receives a broadcast message 212, it responds to it (with response message 214) in case its own queue identifier matches the broadcasted one (this is what occurs to players 10a, 10b, 10d). The response message 214 contains a performance indicator of the HW, a stability value and a random integer value for disambiguation. If a primary Player 10a is already existing, the response messages 214 contain the address of the primary player 10a. This allows for joining an existing Group Playback 210.

[0126] The performance indicator may be based on one or more of the following capabilities: the amount of RAM, CPU cores, current CPU load, available flash storage space, availability of hardware decoders and other identifiers relevant to the performance of a hardware device.

[0127] The stability indicator reflects the stability of a Player 10 over time. That means, that it degrades on unexpected reboots, crashes and other not anticipated, unexpected behavior.

[0128] After a short time, everyone in the group that shares the same queue identifier must have received an answer from all other Players 10 (10a, 10b, 10d) in the group 210.

[0129] In case the response messages do not contain an address of a primary, player 10a the Players 10 (10a, 10b, 10d) will elect the one that replied with the highest performance indicator and Cl N240903PEP-2025001663. DOCX 27 the highest stability indicator and highest random number (compared by that order) as the new primary player 10a. The primary Player 10a will initiate playback and the secondary devices 10b, 10d will connect to it, and receive the content (as 218) from the primary Player 10a.

[0130] Streaming / playing media

[0131] Only the primary Player device 10a in the local area network (LAN) (or more in general in the local network) 220 connects to and transfers media data (51), while playing back, from the media application content distribution network (CDN) 5 (5a) and then distributes the content locally (218) to the secondary Player devices 10b, 10d in the LAN 220.

[0132] A protocol such as Distributed Playback can be used to ensure that all devices 10 (the primary player device 10a and all the secondary Player devices 10b, 10d) are then playing in perfect time sync in the LAN 220.

[0133] Failure handling

[0134] In case the primary Player device 10a guits the network 220 or becomes unreachable, the secondary Player devices 10b, 10d will determine a new primary Player device out of the secondaries 10b, 10d that will take over its responsibilities.

[0135] Technically, the secondaries 10b, 10d notice that the connection to the (gone) primary Player device 10a is not responsible anymore. They restart the primary election and determine a new primary Player device (e.g. one between 10a and 10d). After the primary player device has been determined, it will resume the media playback via the Player device at the last known position and media content and continues where the (now dead) primary left off. The secondaries connect to the new primary and continue as well.

[0136] Human input

[0137] The Player devices 10 (10a, 10b, 10c, 10d) support a human interface e.g., via buttons like start, stop, pause, fast forward, rewind, or arbitrary keyboard buttons or anything else on the device or the software running on that device. When human input is received on the primary Player device 10a, it is directly processed on the primary Player device 10a. When human input is received on one of the secondary Player devices 10b, 10d, this secondary Player device 10b, 10d sends the human input events to the primary who then processes them locally via its Media Runtime Player Software.

[0138] Video wall

[0139] A special case of Group Playback is the video wall playback. Primary election and playback via primary and secondary Player devices may work as described before. Cl N240903PEP-2025001663. DOCX 28

[0140] For video wall playback, each Player device 10 (10a, 10b, 10d) receives information that determines the part of the screen it will display (position, width, height) through the queue that it received from the Cloud backend system 4. The information can be resent by the Cloud backend system 4 any time, which allows to dynamically change the video wall configuration.

[0141] The Player device 10 (10a, 10b, 10d), regardless of it being primary or secondary, will then crop the received video accordingly and display only the specific part.

[0142] Further embodiments of the invention are based on a specific ecosystem as described below, but it is noted that the group playback invention can also be used without the specific ecosystem, i.e. , operates on its own using functionalities that do not cooperate in the specific ecosystem.

[0143] Cloud Ecosystem

[0144] This preferred embodiment used the group playback invention within a new cloud ecosystem, which consists of (or more in general comprises) multiple parts and roles:

[0145] 1. Cloud Ecosystem - a uniform cloud media platform connecting Users, Devices, and Content Services via the Cloud Backend and providing the Management Services.

[0146] 2. Device Maker - any party designing and / or manufacturing Devices. It includes also private technical savvy users acting as such Device Maker by installing the Media Runtime Device Software on a device of their own (e.g., a private camera connected to an SoC of a User).

[0147] 3. Device Brand - a commercial brand under which a Device Maker offers Devices

[0148] 4. Content Services - any party having cloud services for sending (downstream from cloud service) or receiving (upstream to cloud service) content on or from a Device (examples for sending are e.g., services like Spotify, Netflix, or advertising content services, business radio services, private streaming services, content management systems (including systems handling scheduling, delivery and curation) and for receiving can be e.g., a service to store digital camera data in the cloud).

[0149] 5. Media App - a descriptor defining and enabling the connection between the Content Services, the Cloud Backend and the Device. And enabling a Content Service additional functionality by communicating with the Device via the Media Runtime Device Software, like e.g., like saving content on a Device. A Media App is only available in the Cloud Backend, the Device and the Media Runtime Device Software do not have information about the Media App, providing additional security and separation of concerns. 240903PEP-2025001663. DOCX 29

[0150] 6. Device - a hardware device having at least one CPU and a connection to the internet, having Device Capabilities and having integrated the Media Runtime Device Software. A Device is uniquely identified by a Device ID and can have a User as its owner.

[0151] 7. Media Runtime Device Software - embedded software running on a device and communicating both with the device hardware and with the Cloud Backend, and supporting Formats and other capabilities depending on the Device Capabilities. The Media Runtime Device Software is independent of specific Media Apps, and is compiled to many OS and SoCs systems.

[0152] 8. Cloud Backend - cloud services enabling and maintaining the connection and control of the Media Runtime Device Software of all Devices. Through this connection enabling the Cloud Ecosystem. The Cloud Backend has its own Web APIs (e.g., REST APIs). Media Apps are used in the Cloud Backend to communicate content for playback from and to Devices.

[0153] 9. Device Capabilities - the list of all hardware capabilities of a device supported by the Cloud Ecosystem. This includes all supported Formats, and including capabilities like supported audio and video codecs for encoding and for decoding, performance capabilities, security capabilities such as secure boot, DRM capabilities, payment capabilities, etc.

[0154] 10. Device ID - a unique identifier for each Device

[0155] 11. App - an application using the Management Services to manage the Devices and the Account. Optionally, an App can have its own Media Runtime Device Software making the App a Device itself. An App can be a mobile app running on a smart phone or tablet or can be running in a browser or an application running on a PC.

[0156] 12. User - a user with an Account. Users can own their own Devices or use Devices of any other user (e.g., colleagues, or family members).

[0157] 13. Role - each User has one or more roles to define the rights of the User

[0158] 14. Account - a unique user with a free or paid subscription to the Cloud Ecosystem

[0159] 15. Formats - at least one of audio, video, pictures, text and interactive (web) content playing / displaying, and / or generating at least one of audio, video, pictures, text and interactive (web) content. Examples for playing are (i.) speakers for audio, (ii.) screens, TVs for video and pictures, (iii.) screens, keyboard for interactive content. Examples for generating are (i.) microphones for audio, (ii.) cameras for video and pictures.

[0160] 16. Play, Playback, playback or played or play - is broadly defined as playing Formats on a Device and / or generating Formats on a Device

[0161] 17. Store - a service of the Cloud Backend enabling Users to search, find, select and unselect Media Apps and authenticate them with the new Cloud Ecosystem using Cl N240903PEP-2025001663. DOCX 30 the Content Services credentials, and vice-versa. This allows the Cloud Ecosystem to e.g., access content from Content Services.

[0162] 18. Management Services - Services in the Cloud Ecosystem available via the Cloud Backend for participants to control and manage some or all aspects for one or many Devices (e.g., managing Devices including onboarding and offboarding, play gueue management, playback management, etc.).

[0163] The ecosystem is a system consisting of (or more in general comprising)

[0164] - An unlimited number of Devices

[0165] - An unlimited number of Users

[0166] - An unlimited number of Media Apps

[0167] Enabling access to each User’s Devices and Content Services over Apps and / or Management Services, with the possibility to delegate rights to other Users.

[0168] Giving Content Services full control over (i.) minimum Device Capabilities a Device must have to be allowed and able to play their content (for example codec support, secure boot, DRM, etc.) for the purpose of e.g., ensuring best possible playback guality, and / or the minimum security reguirements (ii.) Devices from which Device Brand(s) will be allowed to play their content, or to not play their content, (iii.) which Devices get access to which Media App enabling a Content Service for example to exclusively one Device Brand, or any combination / permutation, (iv.) allow Content Services to extend their own applications the capability to manage Devices with their own Media Apps (e.g., remote control).

[0169] Giving Device Makers full control over (i.) which Media Apps they want to allow on their Devices, (ii.) which Device Capabilities of the Cloud Ecosystem the Device should support and make available to the Cloud Ecosystem, (iii.) allow Device Makers to extend their own applications the capability to manage Devices via Management Services (e.g., Device onboarding to the Cloud Ecosystem).

[0170] Giving Users full control over (i.) selecting Media Apps via the Store and authenticate the Cloud Ecosystem with them, (ii.) using Apps and the Management Services to manage and control the Devices they own, (iii.) permissions of the Media Apps which Device Capabilities they can access via the Management Services (e.g., for a Device with a speaker and a microphone, a User should explicitly allow the Media App to control playback on the speaker, and to play from the microphone, i.e. to access the microphone input and send it to the Content Service), (iv.) delegating User’s rights partially or fully to other Users using e.g., Roles.

[0171] Advantages of our ecosystem are, amongst others: Cl N240903PEP-2025001663. DOCX 31

[0172] Separation of Devices and Media Runtime Device Software versus the Content Services enabling any Content Service to run on any Device just based on the Device Capabilities, the Media App service mapping, the Device Maker and Content Services restrictions and the User choices only, fully managed in real-time in the cloud.

[0173] The ecosystem can run on any supported Device running the Media Runtime Device Software, regardless of OS and SoC.

[0174] - Any participant keeps the control it wants, at any time.

[0175] Description of Further Embodiments of the group playback invention

[0176] One preferred application is in a store and the store has for example 20 speakers that are all provided with the device SDK / player functionality software. The result of this group playback is that the group of 20 Player devices “organizes itself” in that one Player device is found to be the primary Player device and the other Player devices are found to be the secondary Player devices. Then, only the primary Player device connects to the media application content distribution network in order to download the content to be played by all speakers and, then, the content is locally distributed from one speaker to the other speakers via the device SDK / player.

[0177] The first point is the self-organization of the speakers and this is triggered (e.g., via an instruction from the cloud backend system 4 or via any other action). Then, the primary Player device communicates with the content distribution network on the one hand and the cloud on the other hand.

[0178] Additionally, the secondary Player devices do not have any communication with the content distribution network, but do have a communication with the cloud backend system 4. Furthermore, the content provider is informed that the content is locally redistributed, etc. Furthermore, it is preferred that, in this procedure, there is the feature that each device can be individually controlled via HAL events. These HAL events are processed when, for example, a secondary device is controlled, for example by a human user that pushes the stop button. This can be communicated to the cloud or to the primary device 10a.

[0179] When anything occurs with the primary device or secondary device such as that the device is not active anymore such as a shortage of power, a broken connection or a hardware breakdown, then it is preferred that a control instance looks for a replacement primary device and / or a replacement secondary device. Cl N240903PEP-2025001663. DOCX 32

[0180] Additionally, another application scenario is a video wall with, for example, 20 video screens that together represent a “big picture”. Each individual screen shows different content of a big picture. Preferably, the system cares for the distribution of the individual “picture parts” to the individual video screens so that the replay is synchronized.

[0181] Examples of Figs. 6A-6D and 5 and 7

[0182] Fig. 6A illustrates a user device 100 (indicated above as 10, 10a) comprising a device hardware 102 (indicated above as 1) and a media runtime device software 2. This media runtime device software is running on the user device and is configured for controlling the device hardware as illustrated by the connection between block 2 and 102. The media runtime device software comprises a control interface 112 to a cloud backend in order to exchange messages between the media runtime device software in the device and the cloud backend. The user device comprises a media interface to a typically remote data instance for connecting to a remote data instance typically via a playable URL (unique resource locator) in order to then obtain a stream of media data from the remote data instance. Alternatively, the media interface can also send a request for a URL to the remote data instance and, then, receives this data from the data instance via the media interface and, then, an upload from the user device 100 to the remote data instance can be performed when the data instance is a data sink such as the YouTube platform or the TikTok platform. The data that are uploaded via the media interface 114 are typically data acquired by the user device hardware, which is, for example, a camera or a microphone.

[0183] For replaying a data stream received via the media interface 114, the user device typically has a display or speakers or both. Particularly, the media runtime device software 2 is configured to receive data for controlling the device hardware via the control interface 112 and to receive or transmit content via the media interface 114. Thus, it is made sure that the high volume data traffic only takes place via the media interface 114, and this high-volume traffic is kept out from the cloud backend, since the media interface 114 is not interfacing with the cloud backend.

[0184] In an embodiment, the media runtime device software is configured to receive, via the control interface, metadata comprising information identifying the data instance under consideration and an access information such as a playable URL combining the metadata and the identification of the data instance to be accessed. Based on this information, the media runtime device software is configured to access the data instance using the received access information via the media interface 114. Cl N240903PEP-2025001663. DOCX 33

[0185] In one embodiment, the data instance is a content provider. In such an implementation, the media runtime device software 2 is configured to receive playback metadata identifying an intended content data for playback and the access information via the control interface 112, and to send the playback metadata to the content provider via the media interface 114 and to receive the content for playback from the content provider via the media interface 114.

[0186] In the embodiment, the user device comprises a hardware abstraction (HAL) layer 11 interfacing the device hardware on the one hand and the media runtime device software 2 on the other hand. The hardware abstraction layer 11 is configured for detecting a playback event. The media runtime device software is configured to receive the playback event from the hardware abstraction layer 11 via control line 26. However, this playback event is not immediately executed, but is forwarded to the cloud backend via the control interface 112. When a confirmation on the playback event from the cloud backend is received via the control interface 112, then the hardware abstraction layer 11 is instructed by the media runtime device software 2 to perform the playback event. However, when no such confirmation for the playback event is received from the cloud backend or when an explicit “action forbidden” message is received from the cloud backend, then the playback event is not executed.

[0187] Thus, it is made sure that the content provider has full control not only on the fact that an unintended decryption is forbidden, but also how the media data is handled in the user device.

[0188] Nevertheless, in order to give the user of the user device as much control as possible, a pressing of a certain switch on the user device which is typically, a start button, a stop button, a fast forward or fast rewind or pausing button, is nevertheless detected, but not immediately executed as is done, in contrast, in prior art devices. Instead, this hardware event is forwarded to the cloud backend and only when the cloud backend confirms this event, then this event is actually executed.

[0189] The user device comprises a secure storage for storing a unique device ID which is required for identifying the user device with respect to the cloud backend. The device hardware is also configured to only replay content identified via a command received via the control interface and received via the media interface. In a further embodiment, the media runtime device software or “SDK kit” is configured to also have a web browser functionality 21 , a media player functionality 22, and a content decryption functionality 28. In a further embodiment, the media runtime device software 2 is configured to receive a playable unique resource locator (URL) from the control interface, and the user device then interfaces with the specific remote data instance, from which the playable URL is coming from via the media interface to stream media data located at the playable URL at the content provider via the media interface 114. Other Cl N240903PEP-2025001663. DOCX 34 ways to access a data source or data sink platform different from via a playable URL can be performed as well.

[0190] Fig. 6B illustrates an implementation of the cloud backend 200 that has a user device interface 202 for interfacing with the user device such as the user device 100 of Fig. 6A. The cloud backend comprises a communication interface for interfacing with a typically remote data instance such as any one of the data instances indicated at 400 in Fig. 6D, where individual data instances 401 , 402, 403, 404, 405 are illustrated. These remote data instances also correspond to the media CDN 5 of Fig. 1.

[0191] The cloud backend 4 (200) is configured to provide messages to the user device interface for controlling the user device to handle media data and to receiving messages from the user device via the user device interface 202. The cloud backend is configured to communicate to the data instance via the communication interface 204 regarding an authorization of a user of the user device, where this communication comprises receiving data from the data instance or sending data to the data instance. However, this data does not comprise media data to be downloaded or to be uploaded from the user device to the data instances. The cloud backend comprises an application interface 206 for interfacing with a management application such as the user application 300 illustrated in Fig. 6C or 6D.

[0192] The cloud backend 200 (4) additionally comprises, for performing the corresponding tasks, libraries / data bases 208 that can be distributed in the cloud or that can also be located on a single server. The cloud backend also comprises a processing engine 210 that can also be a distributed processing engine or a concentrated processing engine. The playback / upload control of the user device is performed by the cloud backend typically without high-volume traffic in the cloud backend. Only control data is communicated within the cloud backend and control data is received via the cloud backend interfaces 202, 204, 206 and corresponding control data is output via these interfaces as well.

[0193] Fig. 6C illustrates an apparatus 300 (e.g. using user application 3) for performing a user application which comprises a user interface 302 which is exemplarily a human machine interface such as a touch screen interface or a speech interface in order to provide messages to a user or to receive messages from a user. The apparatus comprises a cloud backend interface 304 for communicating with a cloud backend such as the cloud backend of Fig. 6B or the corresponding elements located in the cloud backend in Fig. 1 comprising a playback management element, device queues, or a device management element 35 for example. Cl N240903PEP-2025001663. DOCX 35

[0194] The apparatus is configured to communicate, via the user interface 302, to receive user commands regarding a selection of one or more data instances and a selection of content to be sent to a data instance or to be retrieved from a data instance and to display messages for the user, to communicate via the cloud backend interface 304 regarding the selection of the one or more viewed data instances to be accessed by the user devices, and to communicate via the cloud backend interface regarding the selected content for sending from the user device to a corresponding data instance or for sending from the data instance to the user device. Hence, the cloud backend interface 304 cares for the selection of data instances for the selection and control of user devices, and for the selection of media content for the upload and download.

[0195] Fig. 6D illustrate an overview of the cloud ecosystem and how the individual interfaces are connected to each other in the four greater “entities”:

[0196] The user device 100 (above indicated as 10, 10a, 10b...) with the media runtime device software 2. The user application apparatus 300 (carrying the user application 3) with the user interface 302 on the one hand and the cloud backend interface on the other hand.

[0197] The remote data instances 401 , 402, 403, 404, 405, with the high volume data connection 51 between the media interface 114 of the user device 100 and the media interface of the corresponding data instances.

[0198] The cloud backend for communicating with the remote data instances, the user device 100 and the user application apparatus 300.

[0199] The user application apparatus 300 for communicating with the cloud backend and the user herself of himself.

[0200] In an embodiment, the user device is responsible for playback of content from the remote data instances, and this device, in a minimum implementation, only consists of logic to ensure this capability and, additionally, has the ability to display the playback state in case of a screen connected to the user device or integrated in the user device. The user device only reacts and performs actions based on commands received from the cloud backend via the control interface 112 and there is no local ability to change what is being played. The user device only operates in conjunction with the cloud backend except for already cached or pre-fetched content which will continue to play even without the connection to the cloud backend. Any buttons included in the hardware of the user device can remain active, but not active in the sense that a command implemented by a button is immediately executed, but only active in Cl N240903PEP-2025001663. DOCX 36 the sense that the command is detected, forwarded to the cloud backend, confirmed by the cloud backend and only when the confirmation is there, executed in the hardware of the user device. The user device supports all playback capabilities provided by the media runtime device software including playback of DRM protected content and synchronized playback.

[0201] Devices on the same local network can be used in a group playback leveraging synchronized playback, where the synchronization and distribution of content is performed locally. This is realized by electing one device as the primary device, this primary device will receive a content stream and will distribute it over the local network to all other participating devices. This primary device is elected algorithmically among all participating devices and can change in the course of active playback, specifically in case of devices becoming online or offline in the course of playback.

[0202] The user device also provides an interface for onboarding purposes that allows an app on a mobile device to provide network information to the user device in order to connect it to a local network. The actual hardware used in the user device is, in an abstract representation, a hardware abstraction layer being provided by a device maker and used together with the media runtime device software. The HAL is used to control network interfaces, receive signal input signals and receive status information for further use from the media runtime device software 2, among other needed abstractions to interact with provided hardware such as audio or video output. The device always identifies itself towards all other participants in the ecosystem based on a unique device ID securely stored on the user device 100.

[0203] The cloud backend comprises multiple services with detailed responsibilities. The cloud backend 200 is the main control and management interface within the ecosystem, where all changes in the ecosystem are managed and controlled via the cloud backend 200. Exemplarily, the cloud backend comprises a device management element 35 illustrated in Fig. 1. In this device management, it is made sure that every user device is registered as owned by a user. Users have the ability to see their own devices, to name these devices, to tag these devices, and to deregister them. Users can create and delete device groups which allows using a device group like a single device.

[0204] The cloud backend comprises a playback management that enables the users of the ecosystem to control various playback aspects of the owned devices of the user. Exemplarily, playback of audio, images, and videos is supported as well as an upload of audio data, video data or image data or media data. Cl N240903PEP-2025001663. DOCX 37

[0205] Users can control single devices, view content from content providers and control the playback thereof independently from the local network. This means that the controlling device such as a mobile phone, browser or tablet or generally the user application apparatus 300 can be connected to any network. The playback control includes start, stop, seek, skip, and other functionalities offered by the content provider the content is coming from. Restrictions set by the content provider are respected, for example, skip limits, etc. Users can create playlists that can be composed of items from any content provider of any supporting media type. The user- created playlists can be queued on a device owned by the user. The device can offer any playback control operations directly via buttons and the user can control playback directly from there. However, such control via the buttons is not immediately executed but is only executed when confirmed by a message originating from the user device interface 202 of the cloud backend 200. Users can control playback targeting a device group containing arbitrary devices the user owns. Each separate network segment of the device group will play the content synchronously and technically act as one device. Users can control playback targeting a virtual device and the content will be played according to the virtual device definition.

[0206] Additionally, the cloud backend comprises a content service management that allows the end user to connect to content services or, as named before, data instances that are integrated via the functionalities performed by the user application apparatus 300. End users need to have a subscription / account for the corresponding service at the remote data instance they want to connect and the corresponding user application must allow the user to have access to the service.

[0207] The cloud backend additionally comprises a media app management functionality that defines all meta data for content services, decryptions, translations, icons as well as a specification on how to access content via an API or an URL or URI for web applications. The media app management also allows service providers to specify the requirements their service has towards a device (codecs, screen resolution, DRM, etc.). It also allows a content service to configure restrictions for the service allowing to restrict a service availability by device meta data (manufacturer, type, model, etc.), regions or accounts. These restrictions can be formed by using deny lists and allow lists.

[0208] Additionally, an update management is provided in the cloud backend. In general, devices receive updates of their running device media player software over the air. For that, the devices check frequently if there is a new software version available for a specific device model and install it accordingly. The update will be installed when the device is not performing playback, however, devices performing continuous playback will forcefully install the updates after a defined time. Update packages are stored on the distributed CDN (Content Delivery Cl N240903PEP-2025001663. DOCX 38

[0209] Network) illustrated at 5 in Fig. 1 to ensure high availability and low latency. An update package contains a specific version of the media runtime device software that runs on the device and informative meta data for the update mechanism to be able to select the correct update package. Update packages can be private, so that they can be restricted for development purposes for specific manufacturers, device models or users. The updates are managed through the cloud backend 200 and the device manufacturers. Manufacturers can define if their device models receive a specific version of the update or not.

[0210] The user application apparatus 300 relies on rendering the web frontend exemplarily within a native application. On top of rendering the web frontend, the user application is also integrated in a playback device also allowing remote control via the web frontend or other applications. On top of these functionalities, a further purpose of the user application apparatus 300 is to provide support for onboarding of devices.

[0211] The onboarding of devices is happening by using a camera of a mobile device to scan a QR code. The QR code contains information about the device ID (uniquely identifying the device) as well as optionally information about a local wireless access-point of the device. After scanning the QR code, the user application 300 will connect the mobile device to the wireless access-point of the device. In the next step, the device itself is providing the mobile app with a list of available wireless networks that the device can connect to. The user can select the wireless network to connect to and will be asked to provide the necessary wireless network password. This information is transferred from the user application to the device on which the user application is running and, then, a connection to the wireless network and a connection to the cloud backend 200 are established.

[0212] As illustrated in Fig. 5, a device maker 500 is performing several procedures to generate a cloud service-ready user device.

[0213] Particularly, the device maker 500 may produce a hardware device with the hardware device (e.g. 1 ) and, then, as illustrated in item 501 , put the media runtime device software 2 on the device 1 . Furthermore, as illustrated in item 502 a set of unique device IDs is acquired and, then, as illustrated in step 503, the device IDs are securely put on the device, one device ID per device.

[0214] Furthermore, the device manufacturers create and configure a device descriptor as illustrated in item 504 and, additionally, set rules for allowing or disallowing certain media apps as illustrated in 505. Cl N240903PEP-2025001663. DOCX 39

[0215] In an embodiment, these rules are stored in the cloud backend 4 and, particularly, in the certain libraries or databases of the cloud backend.

[0216] Fig. 7 illustrates an example procedure of onboarding of the user application apparatus 300 to become a user device. This is done implicitly after the user 99 downloads 601 the app from a store and logs into the app for the first time. Particularly, for this purpose, the user 99 starts the app in step 602, and the user application receives, via the user interface 302, a starting message of the app 602. Then, the application apparatus 300 displays a login screen and receives a login message 603 from the user 99.

[0217] When the user is logged in, the application 300 receives a device ID that is internally assigned to the user 99 so that the user 99 becomes the owner of the user device 900, on which the user application is running, i.e., the owner of the user application apparatus. In an embodiment illustrated in Fig. 7, the user application sends out credentials to the cloud backend 200. This occurs by sending out the message 604 via the cloud backend interface 304 of the user application to the application interface 206 of the cloud backend. Then, in reply to this message 604, the cloud backend 200 (4) replies, via the application interface 206, with a message 605 comprising a token, which is received from the user application 300.

[0218] Then, using this token, and when the starting is performed for the first time as illustrated in item 606, the application retrieves, from the apparatus, on which the user application is running, a MAC information (media access control information), or an I MEI (International mobile equipment identity) information and sends this data via a message 607 to the cloud backend 200 via the application interface 206 of the cloud backend. In response to this data, the cloud backend creates a device ID as illustrated in block 608 and, additionally, stores device data derived using the IMEI or the MAC data and outputs the device ID using a message 610 via the application interface to the cloud backend interface 304 of the user application. The user application then stores this device ID in the apparatus, on which the user application is running. Now, the device, in which the user application 300 is running has a unique device ID known and managed by the cloud backend 200. Therefore, in order to be able to finally become a device, it is only required that, for example, using the device ID, the media runtime device software already existing on the apparatus, in which the user application is running, is activated, or this data is downloaded so that the device, in which the user application is running, is implemented to be a compliant device.

[0219] Description of Further Embodiments of the Ecosystem

[0220] A preferred embodiment is illustrated in the enclosed figure illustrating several elements of the invention. The hatched line indicates what is included in the typically device 10 (which may be Cl N240903PEP-2025001663. DOCX 40 a mobile device, such as a mobile phone or tablet, or a fixed device, such as a TV with a fixed display and / or speaker(s) (e.g. loudspeaker(s))) owned by the user. The Media CDN (content delivery network) 5 can also be located anywhere in the cloud (like that indicated as 5b). In this embodiment, the mobile device 10 has an interface for interfacing with the Media CDN 5a in the cloud.

[0221] A “final” or endpoint device 1 is the device HW that typically consists of (or more in general comprises) a replay functionality such as a speaker (e.g. loudspeaker) or a video screen and some interface buttons such as stop buttons, pause buttons, etc.

[0222] This “device HW” 1 interfaces with a “device SDK / player” 2. This functional unit “device SDK / player” 2 interfaces, on the one hand, with a media provider 5 (5a) or, generally, with a distributed content delivery network (media App CDN) 5 (5a).

[0223] Furthermore, the “device SDK / player” 2 interfaces with the cloud backend system 4.

[0224] Furthermore, there exists a app 3 (application) on the user’s mobile (or stationary) device (e.g. 10, or a different device) such as the user’s mobile phone, tablet or even a user’s stationary computer. This app 3 (e.g. on the mobile device) mainly interfaces with the cloud backend system 4 and interfaces, via the onboarding functionality, with the device SDK / player unit 2. However, the app 3 to be stored, for example, on the user’s mobile device or on the user’s stationary computer does not interface with the final playback device 1 or “device HW” 2.

[0225] Furthermore, this app 3 does not interface with the media app content delivery network 5 (5a) that comprises, for example, a streaming platform such as Netflix, Spotify, Amazon Prime, etc.

[0226] Seen from the perspective of the cloud backend system 4, the cloud backend system 4 interfaces on the one hand, with the app 3 on the user’s mobile or stationary device, with the media app content delivery network 5 (5a) (not shown in Fig. 1), and with the device SDK / player 2. However, the cloud backend system 4 does not interface directly to the actual replay device 1 or “device HW”.

[0227] Due to the fact that the cloud backend system 4 is distributed in a cloud, this functional unit maintains, among others, several databases that include, among others, functionalities that represents the actual interface between the media app content delivery network (media app CDN) 5 (5a) and the cloud backend system 4. Cl N240903PEP-2025001663. DOCX 41

[0228] Generally, at least four instances will cooperate with each other or with only selected ones of all instances. These are the final replay hardware device (1), the device SDK / player (2), the app (3) on the user’s mobile / stationary device, the cloud backend (4) and the distributed content delivery network (CDN) (5).

[0229] The present invention allows a distributed Communication between the Content Data (e.g. 51 , 51a) and the Control Data (e.g. 32, 34, 36, 38).

[0230] It is preferred that the cloud backend system 4 only communicates with the media application content distribution network 5 with respect to control data (e.g. 31 , 32) that only require a low volume of data transmission. On the other hand, the actual content such as video or audio content (51 , 51a) is directly transmitted from the distributed content delivery network (CDN) 5 to the actual hardware device 1 via the device SDK / player functionality which is or includes a software program stored on a storage of the actual player device 2. This distributed transmission of content data (51 , 51a) on the one hand and control data (31 , 32, 34, 36, 38) on the other hand has the advantage of only having low volume traffic in the cloud backend system 4. The high volume traffic only occurs between the content delivery network 5 such as the streaming provider and the device SDK / player unit 2 (e.g. stored in a storage of the end point device 10) including the “device HW” instance 1.

[0231] Furthermore, the controlled situation in that the user’s access to the content delivery network or streaming provider 5 (5a) is only done via the cloud backend system 4 is advantageous for the content provider 5, since the content provider can trust the cloud backend system 4 and can also trust the hardware end point device 10, since all the replay functionalities are controlled by the device SDK / player instance 2 that tightly cooperates with the cloud backend system 4. In case of a security breach the cloud backend system 4 can easily bar the compromised device 10 or a class or group of compromised devices (e.g., from the same producer or distributor) by building and maintaining a corresponding “no go” database.

[0232] A specific functionality provided to the user of the hardware player 1 is to also press buttons on the device implementing the speaker (e.g. loudspeaker) or the video screen device giving the user the impression that the user has the full control over the replay functionalities, although these Hardware Abstraction Layer (HAL) events (indicated with 26 in Fig. 1) are not forwarded directly to the streaming website, but only via the cloud backend system 4 (e.g. through the command chain 31-34-26).

[0233] Furthermore, embodiments of the cloud backend system 4 make sure that correct reports back to the artist with respect to Copyrights, etc. are assured by the cloud backend system 4. Cl N240903PEP-2025001663. DOCX 42

[0234] Further functionalities regarding the good control for the content provider 5 such as databases stored with user data etc. are preferred for this invention.

[0235] An inventively encoded signal can be stored on a digital storage medium or a non-transitory storage medium or can be transmitted on a transmission medium such as a wireless transmission medium or a wired transmission medium such as the Internet.

[0236] Although some aspects have been described in the context of an apparatus, it is clear that these aspects also represent a description of the corresponding method, where a block or device corresponds to a method step or a feature of a method step. Analogously, aspects described in the context of a method step also represent a description of a corresponding block or item or feature of a corresponding apparatus.

[0237] Depending on certain implementation requirements, embodiments of the invention can be implemented in hardware or in software. The implementation can be performed using a digital storage medium, for example a floppy disk, a DVD, a CD, a ROM, a PROM, an EPROM, an EEPROM or a FLASH memory, having electronically readable control signals stored thereon, which cooperate (or are capable of cooperating) with a programmable computer system such that the respective method is performed.

[0238] Some embodiments according to the invention comprise a data carrier having electronically readable control signals, which are capable of cooperating with a programmable computer system, such that one of the methods described herein is performed.

[0239] Generally, embodiments of the present invention can be implemented as a computer program product with a program code, the program code being operative for performing one of the methods when the computer program product runs on a computer. The program code may for example be stored on a machine readable carrier.

[0240] Other embodiments comprise the computer program for performing one of the methods described herein, stored on a machine readable carrier or a non-transitory storage medium.

[0241] In other words, an embodiment of the inventive method is, therefore, a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer. Cl N240903PEP-2025001663. DOCX 43

[0242] A further embodiment of the inventive methods is, therefore, a data carrier (or a digital storage medium, or a computer-readable medium) comprising, recorded thereon, the computer program for performing one of the methods described herein.

[0243] A further embodiment of the inventive method is, therefore, a data stream or a sequence of signals representing the computer program for performing one of the methods described herein. The data stream or the sequence of signals may for example be configured to be transferred via a data communication connection, for example via the Internet.

[0244] A further embodiment comprises a processing means, for example a computer, or a programmable logic device, configured to or adapted to perform one of the methods described herein.

[0245] A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein.

[0246] In some embodiments, a programmable logic device (for example a field programmable gate array) may be used to perform some or all of the functionalities of the methods described herein. In some embodiments, a field programmable gate array may cooperate with a microprocessor in order to perform one of the methods described herein. Generally, the methods are preferably performed by any hardware apparatus.

[0247] The above described embodiments are merely illustrative for the principles of the present invention. It is understood that modifications and variations of the arrangements and the details described herein will be apparent to others skilled in the art. It is the intent, therefore, to be limited only by the scope of the impending patent claims and not by the specific details presented by way of description and explanation of the embodiments herein.

[0248] Some aspects

[0249] 1. Apparatus, method or computer program for operating a Player device as described above.

[0250] 2. Apparatus, method or computer program of aspect 1 , wherein the Player device is a primary Player device or a secondary Player device.

[0251] 3. Apparatus, method or computer program for controlling a Player device as described above, wherein the apparatus, method or computer program is separate from the Player device such as the primary Player device and / or the secondary Player device. Cl N240903PEP-2025001663. DOCX 44

[0252] 4. Apparatus, method or computer program for communicating between the Player device and the controller as described above.

[0253] 5. Apparatus, method or computer program of one of the preceding aspects, wherein the controller is an element of the ecosystem and comprises a cloud backend.

[0254] 6. System, method or computer program, comprising a primary Player device, a plurality of secondary Player devices and a controller being separate from the primary Player device and the plurality of secondary Player devices as described above.

[0255] Summarizing of aspects above

[0256] According to an example there is provided, inter alia, a player device (e.g. 10, 10a, 10b, 10c, 10d) for participating to a synchronized group media playback in a group (e.g. 210) of player devices (e.g. 10, 10a, 10b, 10d), the player device (e.g. 10) being configured to control at least one hardware media Tenderer unit (e.g. 1), the player device (e.g. 10) being configured to: receive, from a remote cloud backend system (e.g. 4), an information (e.g. 37a, 38) of being part of the group (e.g. 210) in a same local network, and, once having received the information (e.g. 37a) of being part of the group (e.g. 210): participate to a primary election, among the group (e.g. 210), the primary election electing a primary player device (e.g. 10a), the remaining player device or player devices (e.g. 10b, 10d) in the group (e.g. 210) being defined secondary player device secondary player or devices (e.g. 10b, 10d); in case of the player device (e.g. 10) being elected primary player device (e.g. 10a), receive media content (e.g. 51 , 51a) from a content distribution network (e.g. 5, 5a) and retransmit the media content (e.g. 51 , 51a) to the secondary player devices (e.g. 10b, 10d), and in case of the player device not being elected primary player device (e.g. 10a) and therefore resulting a secondary player (e.g. 10b, 10d), receive media content (e.g. 51 , 51a) from the primary player device (e.g. 10a), both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (e.g. 1) to render the media content (e.g. 51 , 51a).

[0257] The player device may receive a content retrieval information (e.g. 37) from the remote cloud backend system (e.g. 4) informing of media content to be retrieved from the CDN (e.g. 5) and to be subsequently rendered, so as to: in case of the player device (e.g. 10) being elected primary player device (e.g. 10a), receive, from the content distribution network (e.g. 5, 5a), the media content indicated in the content Cl N240903PEP-2025001663. DOCX 45 retrieval information and retransmit the media content to the secondary player device or secondary player devices (e.g. 10b, 10d); and in case of the player device (e.g. 10) being a secondary player device (e.g. 10b, 10d), receive, from the primary playback device (e.g. 10a), the media content indicated in the content retrieval information.

[0258] The content retrieval information (e.g. 37) may include at least one address of the media content to be retrieved and / or information to be provided to the CDN (e.g. 5) to request the media content.

[0259] The content retrieval information (e.g. 37) may include at least one queue information (e.g. 37) which informing of a queue of media content to be rendered according to a predetermined order.

[0260] The content retrieval information (e.g. 37) may include, or is accompanied by, authenticating information to authenticate at least one player device to receive the media content from the CDN (e.g. 5).

[0261] The player device may receive an identifier (e.g. 37a) identifying the content retrieval information (e.g. 37), the identifier (e.g. 37a) being also the information (e.g. 37a) of being part of the group (e.g. 210).

[0262] The player device may receive a queue information (e.g. 37) from the remote cloud backend system (e.g. 4) informing of a queue of media content to be rendered, so that: in case of the player device (e.g. 10) being elected primary player device (e.g. 10a), receiving, from the content distribution network (e.g. 5, 5a), the media content according to an order defined by the queue (e.g. 37) and retransmitting the media content to the secondary player device or secondary player devices (e.g. 10b, 10d); and in case of the player device (e.g. 10) being a secondary player device (e.g. 10b, 10d), receiving, from the primary playback device (e.g. 10a), the media content according to the order defined by the queue (e.g. 37).

[0263] The queue information includes a queue identifier which identifies the group (e.g. 210) and which is also the information (e.g. 37a) of being part of the group (e.g. 210).

[0264] The player device may once having received the information (e.g. 37a) of being part of the group (e.g. 210) Cl N240903PEP-2025001663. DOCX 46 transmit, through the local network (e.g. 220), to the other player devices (e.g. 10a, 10b, 10d) of the group (e.g. 210), information (e.g. 214) including at least discriminating information attributed to the player device and / or the status of the player device, receive, through the local network (e.g. 220), information (e.g. 214) from the other player devices (e.g. 10a, 10b, 10d) of the group (e.g. 210), each including at least discriminating information attributed to the sending player devices and / or the status of the sending player device, thereby defining the primary player device (e.g. 10a) based on the discriminating information of all the player devices of the group (e.g. 210).

[0265] The discriminating information may include at least one performance indicator of the sending player device.

[0266] The discriminating information may include at least one stability value attributed to the sending player device.

[0267] The discriminating information may include at least one random value.

[0268] The discriminating information may include at least one unique identifier of the sending player device.

[0269] The player device may apply a predetermined rule shared with the other player devices of the group (e.g. 210) to elect the primary player device (e.g. 10a) by examining the discriminating information of all the player devices in the group (e.g. 210).

[0270] The player device (e.g. 10b, 10d) may be a secondary player (e.g. 10b, 10d), and in the case of not receiving the media content (e.g. 51a) and / or a heartbeat message from the primary player device (e.g. 10a) for a time delay over a predetermined delay threshold, participate to a further election to elect a new primary player device, and, in the case of the player device being elected as new primary device, receive media content (e.g. 51 , 51a) from a content distribution network (e.g. 5, 5a) and retransmit the media content (e.g. 51 , 51a) to the secondary player devices (e.g. 10b, 10d), and in case of the player device not being elected new primary player device (e.g. 10a) and therefore resulting a secondary player (e.g. 10b, 10d), receive media content (e.g. 51 , 51a) from the new primary player device (e.g. 10a), and Cl N240903PEP-2025001663. DOCX 47 both in case of being elected new primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (e.g. 1) to render the media content (e.g. 51 , 51a).

[0271] The player device (e.g. 10b, 10d) may be a secondary player (e.g. 10b, 10d), and in the case of receiving the media content (e.g. 51a) and / or heartbeat messages from the primary player device (e.g. 10a) with an error rate over a predetermined error-rate threshold, participate to a further election to elect a new primary player device, and, in the case of the player device being elected as new primary device, receive media content (e.g. 51 , 51a) from a content distribution network (e.g. 5, 5a) and retransmit the media content (e.g. 51 , 51a) to the secondary player devices (e.g. 10b, 10d), and in case of the player device not being elected new primary player device (e.g. 10a) and therefore resulting a secondary player (e.g. 10b, 10d), receive media content (e.g. 51 , 51a) from the new primary player device (e.g. 10a), and both in case of being elected new primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (e.g. 1) to render the media content (e.g. 51 , 51a).

[0272] The further election may be performed as the primary election.

[0273] The previous primary player device may be excluded from the primary election.

[0274] The player device may have a knowledge of the first secondary node to be automatically elected in case of the primary player device is not available, and: in case of the player device being the new primary player device, receive the media content (e.g. 51 , 51a) from the content distribution network (e.g. 5, 5a) and retransmit the media content (e.g. 51 , 51a) to the secondary player devices (e.g. 10b, 10d), and in the case of the player device not being elected the new primary player device and therefore resulting a secondary player (e.g. 10b, 10d), receive media content (e.g. 51 , 51a) from the new primary player device (e.g. 10a), both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (e.g. 1) to render the media content (e.g. 51 , 51a).

[0275] The at least one physical interface for receiving a physical user’s command for playback event, may be configured so that: Cl N240903PEP-2025001663. DOCX 48 in case of the player device (e.g. 10) being the primary player device (e.g. 10a), adopt the user’s command for playback event, and transmit, to the secondary player devices (e.g. 10b, 10d), the user’s command for playback event, and in case of the player device being a secondary player (e.g. 10b, 10d), send a request to the primary player device (e.g. 10a) for accepting the user’s command for playback event.

[0276] The player device may receive a backend’s command for playback event from the cloud backend system, the player device being configured to adopt the command irrespective of the player device being the primary player device or a secondary player device.

[0277] The at least one physical interface for receiving a command immediate playback event, configured so that: adopt the user’s command for immediate playback event by controlling the at least one hardware media Tenderer unit (e.g. 1) to adopt the command for immediate playback event both in the case of the player device being a primary device and in the case of the player device being a secondary node.

[0278] The player device may in the case of being a secondary player device, also send a request to the primary player device (e.g. 10a) for accepting the user’s command for immediate playback event.

[0279] The command for immediate playback event may regard at least the playback sound volume.

[0280] The player device may receive the media content without application program interface, APIs.

[0281] The player device may send configuration data to the cloud backend system (e.g. 4).

[0282] The configuration data may include configuration data of the controlled hardware media Tenderer unit (e.g. 1).

[0283] The configuration data may include configuration data of an operating system used by the player device.

[0284] The configuration data may include information on a hardware abstraction layer, HAL (e.g. 11), controlling the hardware media Tenderer unit (e.g. 1). Cl N240903PEP-2025001663. DOCX 49

[0285] The synchronized group media playback may include a video wall playback where multiple, adjacent player devices of the same group (e.g. 210) cooperate to generate a video wall displaying a global video content, each player device displaying a portion of the global video content, the player device (e.g. 10) being configured to: in case of being the primary player device (e.g. 10a), receive the media content (e.g. 51, 51a) of the global video content from the content distribution network (e.g. 5, 5a), separate the global video content among a plurality of video content portions, and retransmit, to each player device (e.g. 10) of the group (e.g. 210) a video content portion to be displayed synchronously; and in case of being a secondary player device (e.g. 10b, 10d), receive the video content portion from the primary player device (e.g. 10a) and render the received video content portion.

[0286] The player device may be configured to send, to the cloud backend system (e.g. 4), positional information.

[0287] The player device may be configured to send, to the cloud backend system (e.g. 4), information regarding its capabilities and / or conditions.

[0288] The player device may send, to the cloud backend system (e.g. 4), authenticating information for being admitted to the group and to receive the media content.

[0289] The player device may receive from the cloud backend system (e.g. 4), in case of being the primary playback device (e.g. 10a), authenticating information for receiving the media content (e.g. 51 , 51a) from the CDN (e.g. 5, 5a), and to send the authenticating information to the CDN to be authenticated.

[0290] The player device may, in case of being the primary player device (e.g. 10a), transmit, to each player device (e.g. 10) of the group (e.g. 210), synchronization messages; and in case of being a secondary player device (e.g. 10b, 10d), receive the synchronization messages and render the received video content portion according to a synchronization controlled by the synchronization information.

[0291] The player device may, in case of being the primary player device (e.g. 10a): Cl N240903PEP-2025001663. DOCX 50 send information on its own timing to each secondary player device (e.g. 10b, 10d) in the group (e.g. 210), the information on its own timing including either information on the playback time which is currently rendered or the internal timing as obtained from its internal clock, receive in response, from each secondary player device in the group, information on the playback time which is currently rendered by the secondary player device, thereby obtaining knowledge on the latency impairing each secondary player device in the group between the playback time at the primary player device and the playback time at each secondary player device; and send resynchronization information to each secondary player device in the group indicating the latency impairing the secondary player device; and in case of being a secondary player device (e.g. 10b, 10d): receive information on the primary player device’s own timing from the primary player device (e.g. 10a), the information on the primary player device’s own timing including either information on the primary player device’s playback time which is currently rendered or the internal timing as obtained from the primary player device’s playback time internal clock, send in response, to the primary player device, information on its playback time which is currently rendered; and receive resynchronization information from the primary player device which indicates the latency impairing the secondary player device; and resynchronize the internal clock based on the latency.

[0292] The player device may in case of being the primary player device (e.g. 10a): send information on its own timing to each secondary player device (e.g. 10b, 10d) in the group (e.g. 210), the information on its own timing including either information on the playback time which is currently rendered or the internal timing as obtained from its internal clock, receive in response, from each secondary player device in the group, information on the playback time which is currently rendered by the secondary player device, thereby obtaining knowledge on the latency impairing each secondary player device in the group between the playback time at the primary player device and the playback time at each secondary player device, and determining the latest among the secondary player devices in the group; and send resynchronization information to each secondary player device in the group indicating additional latency to be observed to resynchronize to the secondary player device impaired by highest latency in the group; and in case of being a secondary player device (e.g. 10b, 10d): receive information on the primary player device’s own timing from the primary player device (e.g. 10a), the information on the primary player device’s own timing including either Cl N240903PEP-2025001663. DOCX 51 information on the primary player device’s playback time which is currently rendered or the internal timing as obtained from the primary player device’s playback time internal clock, send in response, to the primary player device, information on its playback time which is currently rendered; and receive resynchronization information from the primary player device which informs on additional latency to be observed to synchronize to the secondary player device being impaired by highest latency; and resynchronize by inserting in the playback time the additional latency.

[0293] In examples there is provided, inter alia, a backend system (e.g. 4) for assisting a streaming of remote media content towards a group (e.g. 210) of player devices (e.g. 10, 10a, 10b, 10d) connected to each other through a local network (e.g. 220) to perform a synchronized group media playback, the backend system comprising: an interface to at least one remote content distribution network, CDN (e.g. 5, 5a), to receive content retrieval information to allow a reception of the media content from the CDN (e.g. 5); an interface to user application (e.g. 3) to receive content selection (e.g. 32) selecting media content to be rendered; a device manager (e.g. 35) configured to: define at least one group (e.g. 210) formed by a plurality of remote player devices (e.g. 10); command (e.g. 38), to the remote player devices (e.g. 10) of the group, a content reception based on the content selection (e.g. 31) received from the user interface, and provide information (e.g. 37a) of being part of the group (e.g. 210) to the remote player devices (e.g. 10) selected as being in the group, and provide the content retrieval information (e.g. 37), to allow a reception of the media content from the CDN (e.g. 5, 5a).

[0294] The content retrieval information (e.g. 37) may include at least one address of the media content to be retrieved and / or information to be provided to the CDN (e.g. 5) to request the media content.

[0295] The content retrieval information (e.g. 37) may include authenticating information of at least one player device to receive the media content from the CDN (e.g. 5).

[0296] The backend system may insert an identifier (e.g. 37a) identifying the content retrieval information (e.g. 37), the identifier (e.g. 37a) being also the information (e.g. 37a) of being part of the group (e.g. 210). Cl N240903PEP-2025001663. DOCX 52

[0297] The backend system may receive, from a user application (e.g. 3), a command (e.g. 32) indicating a selection of the media content, to be played back, the device manager (e.g. 35) being configured to provide the selected media content in a content command (e.g. 38) to be provided to the remote player devices (e.g. 10).

[0298] The backend system may define and send a queue information (e.g. 37) to the remote player devices (e.g. 10) informing of a queue of media content to be rendered.

[0299] The queue information may include a queue identifier, which identifies the group (e.g. 210) and which is also the information (e.g. 37a) of being part of the group (e.g. 210).

[0300] The backend system may generate the group based on at least one configuration data

[0301] The backend system may send a backend’s command (e.g. 34) for playback event to the group (e.g. 210) of player devices (10), but the command 34 is preferably sent to the primary device 10a only (and the primary device 10a will retransmit the command 34 to the secondary devices 10b, 10d of the group 210). The user application 3 may be agnostic of the elected primary 10a.

[0302] The backend system (e.g. 4) may receive the user command (e.g. 31) for playback event, to trigger the backend’s command (e.g. 34) for playback event.

[0303] The backend system may receive configuration data from the player devices, to thereby define the group (e.g. 210) based on the configuration data.

[0304] The backend system may receive configuration data from the player devices, to thereby decide a version of the media content to be received by the group (e.g. 210) based on the configuration data, thereby providing the content retrieval information to the remote player devices for retrieving the decided version of the media content.

[0305] The configuration data may include configuration data of hardware media Tenderer unit (e.g. 1) controlled by the player devices.

[0306] The configuration data may include configuration data of an operating system used by the player device. Cl N240903PEP-2025001663. DOCX 53

[0307] The configuration data may include information on a hardware abstraction layer, HAL (e.g. 11), at the player devices (e.g. 10) for controlling hardware media Tenderer unit (e.g. 1).

[0308] The synchronized group media playback may include a video wall playback where multiple, adjacent player devices of the same group (e.g. 210) cooperate to generate a video wall displaying a global video content, each player device displaying a portion of the global video content.

[0309] The backend system may receive, from at least one of the player devices (e.g. 10), positional information, so as to decide a version of the media content to be received by the group (e.g. 210) based on the configuration data, thereby providing the content retrieval information to the remote player devices for retrieving the decided version of the media content.

[0310] The backend system may receive, from at least one of the player devices (e.g. 10), positional information, so as to define the group based on the vicinity of different remote player devices from each other.

[0311] The backend system may receive from the remote player devices information regarding their capabilities and / or conditions, so as to decide a version of the media content to be received by the group (e.g. 210) based on the capabilities and / or conditions, thereby providing the content retrieval information to the remote player devices for retrieving the decided version of the media content.

[0312] The backend system may receive from the remote player devices information regarding their capabilities and / or conditions, so as to so as to define the group based on capabilities and / or conditions of the remove plyer devices.

[0313] The backend system may transmit, from each remote player device, authenticating information for being admitted to the group and for receiving the media content, the backend system being configured to check the validity of the authenticating information for being admitted to the group and, only in case of the authenticating information for being admitted to the group being and for receiving the media content valid, admitting the remote player device to the group.

[0314] The backend system may receive, from the CDN, authenticating information for receiving the media content (e.g. 51 , 51a) from the CDN (e.g. 5, 5a), and Cl N240903PEP-2025001663. DOCX 54 to transmit to the remote player devices, and for receiving the media content for receiving the media content (e.g. 51 , 51a) from the CDN (e.g. 5, 5a).

[0315] In examples there is provided, inter alia, an user application for requesting a streaming towards a group (e.g. 210) of player devices (e.g. 10, 10a, 10b, 10d) connected to each other through a local network (e.g. 220) to participate in a synchronized group media playback, the user application being configured to: provide, to a backend system, content selection (e.g. 32) selecting media content to be rendered; and provide commands on the player devices which shall be part of the group.

[0316] According an example there is provided, inter alias, a player device (e.g., 10, 10a, 10b, 10c, 10d) for participating to a synchronized group media playback in a group (e.g., 210) of player devices (e.g., 10, 10a, 10b, 10d), the player device (e.g., 10) being configured to control at least one hardware media Tenderer unit (e.g., 1), the player device (e.g., 10) being configured to: receive, from a remote cloud backend system (e.g., 4), an information (e.g., 37a, 38) of being part of the group (e.g., 210) in a same local network, and, once having received the information (e.g., 37a) of being part of the group (e.g., 210): participate to a primary election, among the group (e.g., 210), the primary election electing a primary player device (e.g., 10a), the remaining player device or player devices (e.g., 10b, 10d) in the group (e.g., 210) being defined secondary player device or secondary player devices (e.g., 10b, 10d); in case of the player device (e.g., 10) being elected primary player device (e.g., 10a), receive media content (e.g., 51 , 51a) from a content distribution network (e.g., 5, 5a) and retransmit the media content (e.g., 51 , 51a) to the secondary player devices (e.g., 10b, 10d), and in case of the player device not being elected primary player device (e.g., 10a) and therefore resulting a secondary player (e.g., 10b, 10d), receive media content (e.g., 51 , 51a) from the primary player device (e.g., 10a), both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (e.g., 1) to render the media content (e.g., 51 , 51a).

[0317] According an example there is provided, inter alias, a player device, configured to receive a content retrieval information (e.g., 37) from the remote cloud backend system (e.g., 4) Cl N240903PEP-2025001663. DOCX 55 informing of media content to be retrieved from the CDN (e.g., 5) and to be subsequently rendered, so as to: in case of the player device (e.g., 10) being elected primary player device (e.g., 10a), receive, from the content distribution network (e.g., 5, 5a), the media content indicated in the content retrieval information and retransmitting the media content to the secondary player device or secondary player devices (e.g., 10b, 10d); and in case of the player device (e.g., 10) being a secondary player device (e.g., 10b, 10d), receive, from the primary playback device (e.g., 10a), the media content indicated in the content retrieval information.

[0318] According an example there is provided, inter alias, a player device, wherein the content retrieval information (e.g., 37) includes at least one address of the media content to be retrieved and / or information to be provided to the CDN (e.g., 5) to request the media content.

[0319] According an example there is provided, inter alias, a player device, wherein the content retrieval information (e.g., 37) includes at least one queue information (e.g., 37) which informing of a queue of media content to be rendered according to a predetermined order.

[0320] According an example there is provided, inter alias, a player device, wherein the content retrieval information (e.g., 37) includes, or is accompanied by, authenticating information to authenticate at least one player device to receive the media content from the CDN (e.g., 5).

[0321] According an example there is provided, inter alias, a player device, configured to receive an identifier (e.g., 37a) identifying the content retrieval information (e.g., 37), the identifier (e.g., 37a) being also the information (e.g., 37a) of being part of the group (e.g., 210).

[0322] According an example there is provided, inter alias, a player device, configured to receive a queue information (e.g., 37) from the remote cloud backend system (e.g., 4) informing of a queue of media content to be rendered, so that: in case of the player device (e.g., 10) being elected primary player device (e.g., 10a), receiving, from the content distribution network (e.g., 5, 5a), the media content according to an order defined by the queue (e.g., 37) and retransmitting the media content to the secondary player device or secondary player devices (e.g., 10b, 10d); and in case of the player device (e.g., 10) being a secondary player device (e.g., 10b, 10d), receiving, from the primary playback device (e.g., 10a), the media content according to the order defined by the queue (e.g., 37). Cl N240903PEP-2025001663. DOCX 56

[0323] According an example there is provided, inter alias, a player device, wherein the queue information includes a queue identifier which identifies the group (e.g., 210) and which is also the information (e.g., 37a) of being part of the group (e.g., 210).

[0324] According an example there is provided, inter alias, a player device, configured, once having received the information (e.g., 37a) of being part of the group (e.g., 210) to: transmit, through the local network (e.g., 220), to the other player devices (e.g., 10a, 10b, 10d) of the group (e.g., 210), information (e.g., 214) including at least discriminating information attributed to the player device and / or the status of the player device, receive, through the local network (e.g., 220), information (e.g., 214) from the other player devices (e.g., 10a, 10b, 10d) of the group (e.g., 210), each including at least discriminating information attributed to the sending player devices and / or the status of the sending player device, thereby defining the primary player device (e.g., 10a) based on the discriminating information of all the player devices of the group (e.g., 210).

[0325] According an example there is provided, inter alias, a player device wherein the discriminating information includes at least one performance indicator of the sending player device.

[0326] According an example there is provided, inter alias, a player device, wherein the discriminating information includes at least one stability value attributed to the sending player device.

[0327] According an example there is provided, inter alias, a player device, wherein the discriminating information includes at least one random value.

[0328] According an example there is provided, inter alias, a player device, wherein the discriminating information includes at least one unique identifier of the sending player device.

[0329] According an example there is provided, inter alias, a player device, configured to apply a predetermined rule shared with the other player devices of the group (e.g., 210) to elect the primary player device (e.g., 10a) by examining the discriminating information of all the player devices in the group (e.g., 210).

[0330] According an example there is provided, inter alias, a player device, configured: in the case of the player device (e.g., 10b, 10d) being a secondary player (e.g., 10b, 10d), and in the case of not receiving the media content (e.g., 51a) and / or a heartbeat message from the primary player device (e.g., 10a) for a time delay over a predetermined Cl N240903PEP-2025001663. DOCX 57 delay threshold, participate to a further election to elect a new primary player device, and, in the case of the player device being elected as new primary device, receive media content (e.g., 51 , 51a) from a content distribution network (e.g., 5, 5a) and retransmitting the media content (e.g., 51 , 51a) to the secondary player devices (e.g., 10b, 10d), and in case of the player device not being elected new primary player device (e.g., 10a) and therefore resulting a secondary player (e.g., 10b, 10d), receive media content (e.g., 51 , 51a) from the new primary player device (e.g., 10a), and both in case of being elected new primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (e.g., 1) to render the media content (e.g., 51 , 51a).

[0331] According an example there is provided, inter alias, a player device, configured: in the case of the player device (e.g., 10b, 10d) being a secondary player (e.g., 10b, 10d), and in the case of receiving the media content (e.g., 51a) and / or heartbeat messages from the primary player device (e.g., 10a) with an error rate over a predetermined error-rate threshold, participate to a further election to elect a new primary player device, and, in the case of the player device being elected as new primary device, receive media content (e.g., 51 , 51a) from a content distribution network (e.g., 5, 5a) and retransmitting the media content (e.g., 51 , 51a) to the secondary player devices (e.g., 10b, 10d), and in case of the player device not being elected new primary player device (e.g., 10a) and therefore resulting a secondary player (e.g., 10b, 10d), receive media content (e.g., 51 , 51a) from the new primary player device (e.g., 10a), and both in case of being elected new primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (e.g., 1) to render the media content (e.g., 51 , 51a).

[0332] According an example there is provided, inter alias, a player device, wherein the further election is performed as the primary election.

[0333] According an example there is provided, inter alias, a player device, wherein the previous primary player device is excluded from the primary election.

[0334] According an example there is provided, inter alias, a player device, configured to have a knowledge of the first secondary node to be automatically elected in case of the primary player device is not available, and: Cl N240903PEP-2025001663. DOCX 58 in case of the player device being the new primary player device, receive the media content (e.g., 51 , 51a) from the content distribution network (e.g., 5, 5a) and retransmit the media content (e.g., 51 , 51a) to the secondary player devices (e.g., 10b, 10d), and in the case of the player device not being elected the new primary player device and therefore resulting a secondary player (e.g., 10b, 10d), receive media content (e.g., 51 , 51a) from the new primary player device (e.g., 10a), both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (e.g., 1) to render the media content (e.g., 51 , 51a).

[0335] According an example there is provided, inter alias, a player device, further comprising at least one physical interface for receiving a physical user’s command for playback event, configured so that: in case of the player device (e.g., 10) being the primary player device (e.g., 10a), adopt the user’s command for playback event, and transmit, to the secondary player devices (e.g., 10b, 10d), the user’s command for playback event, and in case of the player device being a secondary player (e.g., 10b, 10d), send a request to the primary player device (e.g., 10a) for accepting the user’s command for playback event.

[0336] According an example there is provided, inter alias, a player device, configured to receive a backend’s command for playback event from the cloud backend system, the player device being configured to adopt the command irrespective of the player device being the primary player device or a secondary player device.

[0337] According an example there is provided, inter alias, a player device, further comprising at least one physical interface for receiving a command immediate playback event, configured so that: adopt the user’s command for immediate playback event by controlling the at least one hardware media Tenderer unit (e.g., 1) to adopt the command for immediate playback event both in the case of the player device being a primary device and in the case of the player device being a secondary node.

[0338] According an example there is provided, inter alias, a player device configured, in the case of being a secondary player device, to also send a request to the primary player device (e.g., 10a) for accepting the user’s command for immediate playback event.

[0339] According an example there is provided, inter alias, a player device, wherein the command for immediate playback event regards at least the playback sound volume. Cl N240903PEP-2025001663. DOCX 59

[0340] According an example there is provided, inter alias, a player device, configured to receive the media content without application program interface, APIs.

[0341] According an example there is provided, inter alias, a player device, configured to send configuration data to the cloud backend system (e.g., 4).

[0342] According an example there is provided, inter alias, a player device, wherein the configuration data include configuration data of the controlled hardware media Tenderer unit (e.g., 1).

[0343] According an example there is provided, inter alias, a player device, wherein the configuration data include configuration data of an operating system used by the player device.

[0344] According an example there is provided, inter alias, a player device, wherein the configuration data include information on a hardware abstraction layer, HAL (e.g., 11), controlling the hardware media Tenderer unit (e.g., 1).

[0345] According an example there is provided, inter alias, a player device, wherein the synchronized group media playback includes a video wall playback where multiple, adjacent player devices of the same group (e.g., 210) cooperate to generate a video wall displaying a global video content, each player device displaying a portion of the global video content, the player device (e.g., 10) being configured to: in case of being the primary player device (e.g., 10a), receive the media content (e.g., 51 , 51a) of the global video content from the content distribution network (e.g., 5, 5a), separate the global video content among a plurality of video content portions, and retransmit, to each player device (e.g., 10) of the group (e.g., 210) a video content portion to be displayed synchronously; and in case of being a secondary player device (e.g., 10b, 10d), receive the video content portion from the primary player deice (e.g., 10a) and render the received video content portion.

[0346] According an example there is provided, inter alias, a player device, wherein the player device is configured to send, to the cloud backend system (e.g., 4), information regarding its capabilities and / or conditions.

[0347] According an example there is provided, inter alias, a player device, configured to send, to the cloud backend system (e.g., 4), authenticating information for being admitted to the group and to receive the media content. Cl N240903PEP-2025001663. DOCX 60

[0348] According an example there is provided, inter alias, a player device, configured to receive from the cloud backend system (e.g., 4), in case of being the primary playback device (e.g., 10a), authenticating information for receiving the media content (e.g., 51, 51a) from the CDN (e.g., 5, 5a), and to send the authenticating information to the CDN to be authenticated.

[0349] According an example there is provided, inter alias, a player device, configured: in case of being the primary player device (e.g., 10a), transmit, to each player device (e.g., 10) of the group (e.g., 210), synchronization messages; and in case of being a secondary player device (e.g., 10b, 10d), receive the synchronization messages and render the received video content portion according to a synchronization controlled by the synchronization information.

[0350] According an example there is provided, inter alias, a player device, configured to: in case of being the primary player device (e.g., 10a): send information on its own timing to each secondary player device (e.g., 10b, 10d) in the group (e.g., 210), the information on its own timing including either information on the playback time which is currently rendered or the internal timing as obtained from its internal clock, receive in response, from each secondary player device in the group, information on the playback time which is currently rendered by the secondary player device, thereby obtaining knowledge on the latency impairing each secondary player device in the group between the playback time at the primary player device and the playback time at each secondary player device; and send resynchronization information to each secondary player device in the group indicating the latency impairing the secondary player device; and in case of being a secondary player device (e.g., 10b, 10d): receive information on the primary player device’s own timing from the primary player device (e.g., 10a), the information on the primary player device’s own timing including either information on the primary player device’s playback time which is currently rendered or the internal timing as obtained from the primary player device’s playback time internal clock, send in response, to the primary player device, information on its playback time which is currently rendered; and receive resynchronization information from the primary player device which indicates the latency impairing the secondary player device; and resynchronize the internal clock based on the latency. Cl N240903PEP-2025001663. DOCX 61

[0351] According an example there is provided, inter alias, a player device, configured to: in case of being the primary player device (e.g., 10a): send information on its own timing to each secondary player device (e.g., 10b, 10d) in the group (e.g., 210), the information on its own timing including either information on the playback time which is currently rendered or the internal timing as obtained from its internal clock, receive in response, from each secondary player device in the group, information on the playback time which is currently rendered by the secondary player device, thereby obtaining knowledge on the latency impairing each secondary player device in the group between the playback time at the primary player device and the playback time at each secondary player device, and determining the latest among the secondary player devices in the group; and send resynchronization information to each secondary player device in the group indicating additional latency to be observed to resynchronize to the secondary player device impaired by highest latency in the group; and in case of being a secondary player device (e.g., 10b, 10d): receive information on the primary player device’s own timing from the primary player device (e.g., 10a), the information on the primary player device’s own timing including either information on the primary player device’s playback time which is currently rendered or the internal timing as obtained from the primary player device’s playback time internal clock, send in response, to the primary player device, information on its playback time which is currently rendered; and receive resynchronization information from the primary player device which informs on additional latency to be observed to synchronize to the secondary player device being impaired by highest latency; and resynchronize by inserting in the playback time the additional latency.

[0352] According an example there is provided, inter alias, a player device, configured in case of being elected primary player device (e.g., 10a), receive, from the content distribution network (e.g., 5, 5a), the media content indicated in the content retrieval information and retransmit the media content to the secondary player device or secondary player devices (e.g., 10b, 10d) by relaying, without any modification of the media content (e.g., 51); and Cl N240903PEP-2025001663. DOCX 62 in case of the player device (e.g., 10) being a secondary player device (e.g., 10b, 10d), receive, from the primary playback device (e.g., 10a), the media content (51), and decode the media content (51) before rendering the media content (e.g., 51).

[0353] According an example there is provided, inter alias, a 37b. The player device of any of the preceding claimed, configured: in case of being elected primary player device (e.g., 10a), receive, from the content distribution network (e.g., 5, 5a), the media content indicated in the content retrieval information and retransmit the media content to the secondary player device or secondary player devices (10b, 10d), decrypting the media content, and retransmitting the media content (51) to the secondary player devices; and in case of the player device (10) being a secondary player device (10b, 10d), receive, from the primary playback device (10a), the decrypted media content (51) before decoding and rendering it.

[0354] According an example there is provided, inter alias, a backend system (e.g., 4) for assisting a streaming of remote media content towards a group (e.g., 210) of player devices (e.g., 10, 10a, 10b, 10d) connected to each other through a local network (e.g., 220) to perform a synchronized group media playback, the backend system comprising: an interface to at least one remote content distribution network, CDN (e.g., 5, 5a), to receive content retrieval information to allow a reception of the media content from the CDN (e.g., 5); an interface to user application (e.g., 3) to receive content selection (e.g., 32) selecting media content to be rendered; a device manager (e.g., 35) configured to: define at least one group (e.g., 210) formed by a plurality of remote player devices (e.g., 10); command (e.g., 38), to the remote player devices (e.g., 10) of the group (e.g., 210), a content reception based on the content selection (e.g., 31) received from the user interface, and provide information (e.g., 37a) of being part of the group (e.g., 210) to the remote player devices (e.g., 10) selected as being in the group, and provide the content retrieval information (e.g., 37), to allow a reception of the media content from the CDN (e.g., 5, 5a). Cl N240903PEP-2025001663. DOCX 63

[0355] According an example there is provided, inter alias, a backend system, wherein the content retrieval information (e.g., 37) includes at least one address of the media content to be retrieved and / or information to be provided to the CDN (e.g., 5) to request the media content.

[0356] According an example there is provided, inter alias, a backend system, wherein the content retrieval information (e.g., 37) includes authenticating information of at least one player device to receive the media content from the CDN (e.g., 5).

[0357] According an example there is provided, inter alias, a backend system, configured to insert an identifier (e.g., 37a) identifying the content retrieval information (e.g., 37), the identifier (e.g., 37a) being also the information (e.g., 37a) of being part of the group (e.g., 210).

[0358] According an example there is provided, inter alias, a backend system, configured to receive, from a user application (e.g., 3), a command (e.g., 32) indicating a selection of the media content, to be played back, the device manager (e.g., 35) being configured to provide the selected media content in a content command (e.g., 38) to be provided to the remote player devices (e.g., 10).

[0359] According an example there is provided, inter alias, a backend system, configured to define and send a queue information (e.g., 37) to the remote player devices (e.g., 10) informing of a queue of media content to be rendered.

[0360] According an example there is provided, inter alias, a backend, wherein the queue information includes a queue identifier, which identifies the group (e.g., 210) and which is also the information (e.g., 37a) of being part of the group (e.g., 210).

[0361] According an example there is provided, inter alias, a backend system, configured generate the group based on at least one configuration data

[0362] According an example there is provided, inter alias, a backend system, configured to send a backend’s command (e.g., 34) for playback event to the group (e.g., 210) of player devices (e.g., 10).

[0363] According an example there is provided, inter alias, a backend system, configured to receive the user command (e.g., 31) for playback event, to trigger the backend’s command (e.g., 34) for playback event. Cl N240903PEP-2025001663. DOCX 64

[0364] According an example there is provided, inter alias, a backend system, configured to receive configuration data from the player devices, to thereby define the group (e.g., 210) based on the configuration data.

[0365] According an example there is provided, inter alias, a backend system configured to receive, from at least one of the player devices (e.g., 10) of the group (e.g., 210), information (e.g., 749c) indicating a result of an election of a primary player device (e.g., 10a) among the player devices (e.g., 10b, 10d) of the group (e.g., 210), so as to address the backend’s command (e.g., 34) for playback event to the elected primary device (e.g., 10a) without sending the backend’s command (e.g., 34) for playback event to the other player devices (e.g., 10b, 10d) of the group (e.g., 210).

[0366] According an example there is provided, inter alias, a backend system, configured to receive configuration data from the player devices, to thereby decide a version of the media content to be received by the group (e.g., 210) based on the configuration data, thereby providing the content retrieval information to the remote player devices for retrieving the decided version of the media content.

[0367] According an example there is provided, inter alias, a backend system wherein the configuration data include configuration data of a hardware media Tenderer unit (e.g., 1) controlled by the player devices.

[0368] According an example there is provided, inter alias, a backend system, wherein the configuration data include configuration data of an operating system used by at least one of the player devices.

[0369] According an example there is provided, inter alias, a backend system, wherein the configuration data include information on a hardware abstraction layer, HAL (e.g., 11), at the player devices (e.g., 10) for controlling a hardware media Tenderer unit (e.g., 1).

[0370] According an example there is provided, inter alias, a backend system, wherein the synchronized group media playback includes a video wall playback where multiple, adjacent player devices of the same group (e.g., 210) cooperate to generate a video wall displaying a global video content, each player device displaying a portion of the global video content. Cl N240903PEP-2025001663. DOCX 65

[0371] According an example there is provided, inter alias, a backend system, configured to receive from the remote player devices information regarding their capabilities and / or conditions, so as to decide a version of the media content to be received by the group (e.g., 210) based on the capabilities and / or conditions, thereby providing the content retrieval information to the remote player devices for retrieving the decided version of the media content.

[0372] According an example there is provided, inter alias, a backend system, configured to receive from the remote player devices information regarding their capabilities and / or conditions, so as to so as to define the group based on capabilities and / or conditions of the remove plyer devices.

[0373] According an example there is provided, inter alias, a backend system, configured to transmit, from each remote player device, authenticating information for being admitted to the group and for receiving the media content, the backend system being configured to check the validity of the authenticating information for being admitted to the group and, only in case of the authenticating information for being admitted to the group being and for receiving the media content valid, admitting the remote player device to the group.

[0374] According an example there is provided, inter alias, a backend system, configured receive, from the CDN, authenticating information for receiving the media content (e.g., 51 , 51a) from the CDN (e.g., 5, 5a), and to transmit to the remote player devices, and for receiving the media content for receiving the media content (e.g., 51 , 51a) from the CDN (e.g., 5, 5a).

[0375] According an example there is provided, inter alias, a user application for requesting a streaming of a remote media content to group (e.g., 210) of player devices (e.g., 10, 10a, 10b, 10d) connected to each other through a local network (e.g., 220) to participate in a synchronized group media playback, the user application being configured to: provide, to a backend system (e.g., 4), content selection (e.g., 31) selecting media content to be rendered; and provide commands (e.g., 32) on the player devices which shall be part of the group (e.g., 210).

[0376] According an example there is provided, inter alias, a user application, configured to receive from the backend system (e.g., 4) a list of content services (e.g., 5), and request to the user (e.g., 99) to perform a selection of a preferred content service, and, once the preferred content Cl N240903PEP-2025001663. DOCX 66 service has been selected, to the backend system (e.g., 4) information on the selected content service.

[0377] According an example there is provided, inter alias, a user application, configured to receive from the backend system (e.g., 4) a list of content which may be performed by the synchronized group media playback, and request the user (e.g., 99) to select a preferred content (e.g., 51) to be received, and, selected the preferred media content (e.g., 51), to transmit to the backend system (e.g., 4) information on the selected media content (e.g., 51).

[0378] According an example there is provided, inter alias, a user application, wherein the information on the selected media content (e.g., 51) indicates a queue (e.g., 37) of media content (e.g., 51) to be received and played back.

[0379] According an example there is provided, inter alias, a user application, configured to receive a list of player devices (e.g., 744) allowed to be part of the synchronized group playback, and to request the user (e.g., 99) to select at least two player devices (e.g., 10a, 10b, 10d) to be part of the group (e.g., 210) from the list, and, once the at least two player devices have been selected, to transmit to the backend system (e.g., 4) information on the group information as part of the command (e.g., 32).

[0380] According an example there is provided, inter alias, a backend system (e.g., 4), configured to provide, to the user application (e.g., 3), a list of content services (e.g., 5) as part of the at least one CDN (e.g., 5), and receive, from the user application (e.g., 3), a selection of a preferred content service, so that the content retrieval information (e.g., 37) provided to the player devices (e.g., 10) is an address of the preferred content service.

[0381] According an example there is provided, inter alias, a backend system (e.g., 4), configured to provide the user application (e.g., 3) with a list of content which can be provided by the specific selected content service (e.g., 5), and to receive a selection of the content from the user application (e.g., 3).

[0382] According an example there is provided, inter alias, a backend system (4), configured to provide (e.g., 744) the user application (e.g., 3) with a list of player devices (e.g., 10a-10d) which can be part of the group (e.g., 210), and to receive, from the user application (e.g., 3), a selection of preferred player devices (e.g., 10a-10d) which will form the group (e.g., 210). Cl N240903PEP-2025001663. DOCX 67

[0383] According an example there is provided, inter alias, a method for a synchronized group media playback of a player device in a group (e.g., 210) of player devices (e.g., 10, 10a, 10b, 10d), the method controlling at least one hardware media Tenderer unit (e.g., 1), including: receiving, from a remote cloud backend system (e.g., 4), an information (e.g., 37a, 38) of being part of the group (e.g., 210) and, once having received the information (e.g., 37a) of being part of the group (e.g., 210): participating to a primary election, among the group (e.g., 210), the primary election electing a primary player device (e.g., 10a), the remaining player device or player devices (e.g., 10b, 10d) in the group (e.g., 210) being defined secondary player device or secondary player devices (e.g., 10b, 10d); in case of being elected primary player device (e.g., 10a), receiving media content (e.g., 51 , 51a) from a content distribution network (e.g., 5, 5a) and retransmitting the media content (e.g., 51 , 51a) to the secondary player devices (e.g., 10b, 10d), and in case of not being elected primary player device (e.g., 10a) and therefore resulting a secondary player (e.g., 10b, 10d), receiving media content (e.g., 51 , 51a) from the primary player device (e.g., 10a), both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (e.g., 1) to render the media content (e.g., 51 , 51a).

[0384] According an example there is provided, inter alias, a method for a method for assisting a streaming of remote media content towards a group (e.g., 210) of player devices (e.g., 10, 10a, 10b, 10d) connected to each other through a local network (e.g., 220) to perform a synchronized group media playback, the method comprising: interfacing with at least one remote content distribution network, CDN (e.g., 5, 5a), to receive content retrieval information to allow a reception of the media content from the CDN (e.g., 5); interfacing with user application (e.g., 3) to receive content selection (e.g., 32) selecting media content to be rendered; defining at least one group (e.g., 210) formed by a plurality of remote player devices (e.g., 10); commanding (e.g., 38), to the remote player devices (e.g., 10) of the group (e.g., 210), a content reception based on the content selection (e.g., 31) received from the user interface, and providing information (e.g., 37a) of being part of the group (e.g., 210) to the remote player devices (e.g., 10) selected as being in the group, and Cl N240903PEP-2025001663. DOCX 68 providing the content retrieval information (e.g., 37), to allow a reception of the media content from the CDN (e.g., 5, 5a).

[0385] According an example there is provided, inter alias, a method for a user application requesting a streaming of a remote media content to group (e.g., 210) of player devices (e.g., 10, 10a, 10b, 10d) connected to each other through a local network (e.g., 220) to participate in a synchronized group media playback, comprising: providing, to a backend system (e.g., 4), content selection (e.g., 31) selecting media content to be rendered; and providing commands (e.g., 32) on the player devices which shall be part of the group (e.g., 210).

[0386] According an example there is provided, inter alias, a non-transitory storage unit storing instructions which, when executing in a processor, cause the processor to perform a method.

[0387] Further aspects

[0388] It is to be mentioned here that all alternatives or aspects as discussed before and all aspects as defined by independent claims in the following claims can be used individually, i.e., without any other alternative or object than the contemplated alternative, object or independent claim. However, in other embodiments, two or more of the alternatives or the aspects or the independent claims can be combined with each other and, in other embodiments, all aspects, or alternatives and all independent claims can be combined to each other.

[0389] Although some aspects have been described in the context of an apparatus, it is clear that these aspects also represent a description of the corresponding method, where a block or device corresponds to a method step or a feature of a method step. Analogously, aspects described in the context of a method step also represent a description of a corresponding block or item or feature of a corresponding apparatus.

[0390] Depending on certain implementation requirements, embodiments of the invention can be implemented in hardware or in software. The implementation can be performed using a digital storage medium, for example a floppy disk, a DVD, a CD, a ROM, a PROM, an EPROM, an EEPROM or a FLASH memory, having electronically readable control signals stored thereon, Cl N240903PEP-2025001663. DOCX 69 which cooperate (or are capable of cooperating) with a programmable computer system such that the respective method is performed.

[0391] Some embodiments according to the invention comprise a data carrier having electronically readable control signals, which are capable of cooperating with a programmable computer system, such that one of the methods described herein is performed.

[0392] Generally, embodiments of the present invention can be implemented as a computer program product with a program code, the program code being operative for performing one of the methods when the computer program product runs on a computer. The program code may for example be stored on a machine readable carrier.

[0393] Other embodiments comprise the computer program for performing one of the methods described herein, stored on a machine readable carrier or a non-transitory storage medium.

[0394] In other words, an embodiment of the inventive method is, therefore, a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer.

[0395] A further embodiment of the inventive methods is, therefore, a data carrier (or a digital storage medium, or a computer-readable medium) comprising, recorded thereon, the computer program for performing one of the methods described herein.

[0396] A further embodiment of the inventive method is, therefore, a data stream or a sequence of signals representing the computer program for performing one of the methods described herein. The data stream or the sequence of signals may for example be configured to be transferred via a data communication connection, for example via the Internet.

[0397] A further embodiment comprises a processing means, for example a computer, or a programmable logic device, configured to or adapted to perform one of the methods described herein.

[0398] A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein. Cl N240903PEP-2025001663. DOCX 70

[0399] In some embodiments, a programmable logic device (for example a field programmable gate array) may be used to perform some or all of the functionalities of the methods described herein. In some embodiments, a field programmable gate array may cooperate with a microprocessor in order to perform one of the methods described herein. Generally, the methods are preferably performed by any hardware apparatus.

[0400] The above described embodiments are merely illustrative for the principles of the present invention. It is understood that modifications and variations of the arrangements and the details described herein will be apparent to others skilled in the art. It is the intent, therefore, to be limited only by the scope of the impending patent claims and not by the specific details presented by way of description and explanation of the embodiments herein.

Claims

Cl N240903PEP-2025001663. DOCX 71Claims1. A player device (10, 10a, 10b, 10c, 10d) for participating to a synchronized group media playback in a group (210) of player devices (10, 10a, 10b, 10d), the player device (10) being configured to control at least one hardware media Tenderer unit (1), the player device (10) being configured to: receive, from a remote cloud backend system (4), an information (37a, 38) of being part of the group (210) in a same local network, and, once having received the information (37a) of being part of the group (210): participate to a primary election, among the group (210), the primary election electing a primary player device (10a), the remaining player device or player devices (10b, 10d) in the group (210) being defined secondary player device or secondary player devices (10b, 10d); in case of the player device (10) being elected primary player device (10a), receive media content (51 , 51a) from a content distribution network (5, 5a) and retransmit the media content (51 , 51a) to the secondary player devices (10b, 10d), and in case of the player device not being elected primary player device (10a) and therefore resulting a secondary player (10b, 10d), receive media content (51 , 51a) from the primary player device (10a), both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (1) to render the media content (51 , 51a).

2. The player device of claim 1 , configured to receive a content retrieval information (37) from the remote cloud backend system (4) informing of media content to be retrieved from the CDN (5) and to be subsequently rendered, so as to: in case of the player device (10) being elected primary player device (10a), receive, from the content distribution network (5, 5a), the media content indicated in the content retrieval information and retransmitting the media content to the secondary player device or secondary player devices (10b, 10d); and in case of the player device (10) being a secondary player device (10b, 10d), receive, from the primary playback device (10a), the media content indicated in the content retrieval information.

3. The player device of claim 2, wherein the content retrieval information (37) includes at least one address of the media content to be retrieved and / or information to be provided to the CDN (5) to request the media content.Cl N240903PEP-2025001663. DOCX 724. The player device of claim 2 or 3, wherein the content retrieval information (37) includes at least one queue information (37) which informing of a queue of media content to be rendered according to a predetermined order.

5. The player device of any of claims 2-4, wherein the content retrieval information (37) includes, or is accompanied by, authenticating information to authenticate at least one player device to receive the media content from the CDN (5).

6. The player device of any of claims 2-5, configured to receive an identifier (37a) identifying the content retrieval information (37), the identifier (37a) being also the information (37a) of being part of the group (210).

7. The player device of any of the preceding claims, configured to receive a queue information (37) from the remote cloud backend system (4) informing of a queue of media content to be rendered, so that: in case of the player device (10) being elected primary player device (10a), receiving, from the content distribution network (5, 5a), the media content according to an order defined by the queue (37) and retransmitting the media content to the secondary player device or secondary player devices (10b, 10d); and in case of the player device (10) being a secondary player device (10b, 10d), receiving, from the primary playback device (10a), the media content according to the order defined by the queue (37).

8. The player device of any of claims 2-7, wherein the queue information includes a queue identifier which identifies the group (210) and which is also the information (37a) of being part of the group (210).

9. The player device of any of the preceding claims, configured, once having received the information (37a) of being part of the group (210) to: transmit, through the local network (220), to the other player devices (10a, 10b, 10d) of the group (210), information (214) including at least discriminating information attributed to the player device and / or the status of the player device, receive, through the local network (220), information (214) from the other player devices (10a, 10b, 10d) of the group (210), each including at least discriminating information attributed to the sending player devices and / or the status of the sending player device, thereby defining the primary player device (10a) based on the discriminating information of all the player devices of the group (210).Cl N240903PEP-2025001663. DOCX 7310. The player device of claim 9, wherein the discriminating information includes at least one performance indicator of the sending player device.

11. The player device of claim 9 or 10, wherein the discriminating information includes at least one stability value attributed to the sending player device.

12. The player device of any of claims 9-11 , wherein the discriminating information includes at least one random value.

13. The player device of any of claims 9-12, wherein the discriminating information includes at least one unique identifier of the sending player device.

14. The player device of any of claims 9-13, configured to apply a predetermined rule shared with the other player devices of the group (210) to elect the primary player device (10a) by examining the discriminating information of all the player devices in the group (210).

15. The player device of any of the preceding claims, configured: in the case of the player device (10b, 10d) being a secondary player (10b, 10d), and in the case of not receiving the media content (51a) and / or a heartbeat message from the primary player device (10a) for a time delay over a predetermined delay threshold, participate to a further election to elect a new primary player device, and, in the case of the player device being elected as new primary device, receive media content (51 , 51a) from a content distribution network (5, 5a) and retransmitting the media content (51 , 51a) to the secondary player devices (10b, 10d), and in case of the player device not being elected new primary player device (10a) and therefore resulting a secondary player (10b, 10d), receive media content (51 , 51a) from the new primary player device (10a), and both in case of being elected new primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (1) to render the media content (51, 51a).

16. The player device of any of the preceding claims, configured: in the case of the player device (10b, 10d) being a secondary player (10b, 10d), and in the case of receiving the media content (51a) and / or heartbeat messages from the primary player device (10a) with an error rate over a predetermined error-rate threshold, participate to a further election to elect a new primary player device, and, in the case of the player deviceCl N240903PEP-2025001663. DOCX 74 being elected as new primary device, receive media content (51 , 51a) from a content distribution network (5, 5a) and retransmitting the media content (51 , 51a) to the secondary player devices (10b, 10d), and in case of the player device not being elected new primary player device (10a) and therefore resulting a secondary player (10b, 10d), receive media content (51 , 51a) from the new primary player device (10a), and both in case of being elected new primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (1) to render the media content (51, 51a).

17. The player device of any of the claims 15 and 16, wherein the further election is performed as the primary election.

18. The player device of any of the claims 15 and 16 and 17, wherein the previous primary player device is excluded from the primary election.

19. The player device of any of the preceding claims, configured to have a knowledge of the first secondary node to be automatically elected in case of the primary player device is not available, and: in case of the player device being the new primary player device, receive the media content (51, 51a) from the content distribution network (5, 5a) and retransmit the media content (51 , 51a) to the secondary player devices (10b, 10d), and in the case of the player device not being elected the new primary player device and therefore resulting a secondary player (10b, 10d), receive media content (51 , 51a) from the new primary player device (10a), both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (1) to render the media content (51 , 51a).

20. The player device of any of the preceding claims, further comprising at least one physical interface for receiving a physical user’s command for playback event, configured so that: in case of the player device (10) being the primary player device (10a), adopt the user’s command for playback event, and transmit, to the secondary player devices (10b, 10d), the user’s command for playback event, and in case of the player device being a secondary player (10b, 10d), send a request to the primary player device (10a) for accepting the user’s command for playback event.Cl N240903PEP-2025001663. DOCX 7521. The player device of any of the preceding claims, configured to receive a backend’s command for playback event from the cloud backend system, the player device being configured to adopt the command irrespective of the player device being the primary player device or a secondary player device.

22. The player device of any of the preceding claims, further comprising at least one physical interface for receiving a command immediate playback event, configured so that: adopt the user’s command for immediate playback event by controlling the at least one hardware media Tenderer unit (1) to adopt the command for immediate playback event both in the case of the player device being a primary device and in the case of the player device being a secondary node.

23. The player device of claim 22, configured, in the case of being a secondary player device, to also send a request to the primary player device (10a) for accepting the user’s command for immediate playback event.

24. The player device of claim 22 or 23, wherein the command for immediate playback event regards at least the playback sound volume.

25. The player device of any of the preceding claims, configured to receive the media content without application program interface, APIs.

26. The player device of any of the preceding claims, configured to send configuration data to the cloud backend system (4).

27. The player device of claim 26, wherein the configuration data include configuration data of the controlled hardware media Tenderer unit (1).

28. The player device of claim 26 or 27, wherein the configuration data include configuration data of an operating system used by the player device.

29. The player device of any of claims 26-28, wherein the configuration data include information on a hardware abstraction layer, HAL (11), controlling the hardware media Tenderer unit (1).Cl N240903PEP-2025001663. DOCX 7630. The player device of any of the preceding claims, wherein the synchronized group media playback includes a video wall playback where multiple, adjacent player devices of the same group (210) cooperate to generate a video wall displaying a global video content, each player device displaying a portion of the global video content, the player device (10) being configured to: in case of being the primary player device (10a), receive the media content (51 , 51a) of the global video content from the content distribution network (5, 5a), separate the global video content among a plurality of video content portions, and retransmit, to each player device (10) of the group (210) a video content portion to be displayed synchronously; and in case of being a secondary player device (10b, 10d), receive the video content portion from the primary player deice (10a) and render the received video content portion.

31. The player device of any of the preceding claims, wherein the player device is configured to send, to the cloud backend system (4), information regarding its capabilities and / or conditions.

32. The player device of any of the preceding claims, configured to send, to the cloud backend system (4), authenticating information for being admitted to the group and to receive the media content.

33. The player device of any of the preceding claims, configured to receive from the cloud backend system (4), in case of being the primary playback device (10a), authenticating information for receiving the media content (51 , 51a) from the CDN (5, 5a), and to send the authenticating information to the CDN to be authenticated.

34. The player device of any of the preceding claims, configured: in case of being the primary player device (10a), transmit, to each player device (10) of the group (210), synchronization messages; and in case of being a secondary player device (10b, 10d), receive the synchronization messages and render the received video content portion according to a synchronization controlled by the synchronization information.

35. The player device of any of the preceding claims, configured to: in case of being the primary player device (10a): send information on its own timing to each secondary player device (10b, 10d) in the group (210), the information on its own timing including eitherCl N240903PEP-2025001663. DOCX 77 information on the playback time which is currently rendered or the internal timing as obtained from its internal clock, receive in response, from each secondary player device in the group, information on the playback time which is currently rendered by the secondary player device, thereby obtaining knowledge on the latency impairing each secondary player device in the group between the playback time at the primary player device and the playback time at each secondary player device; and send resynchronization information to each secondary player device in the group indicating the latency impairing the secondary player device; and in case of being a secondary player device (10b, 10d): receive information on the primary player device’s own timing from the primary player device (10a), the information on the primary player device’s own timing including either information on the primary player device’s playback time which is currently rendered or the internal timing as obtained from the primary player device’s playback time internal clock, send in response, to the primary player device, information on its playback time which is currently rendered; and receive resynchronization information from the primary player device which indicates the latency impairing the secondary player device; and resynchronize the internal clock based on the latency.

36. The player device of any of claims 1-34, configured to: in case of being the primary player device (10a): send information on its own timing to each secondary player device (10b, 10d) in the group (210), the information on its own timing including either information on the playback time which is currently rendered or the internal timing as obtained from its internal clock, receive in response, from each secondary player device in the group, information on the playback time which is currently rendered by the secondary player device, thereby obtaining knowledge on the latency impairing each secondary player device in the group between the playback time at the primary player device and the playback time at each secondary player device, and determining the latest among the secondary player devices in the group; and send resynchronization information to each secondary player device in the group indicating additional latency to be observed to resynchronize to the secondary player device impaired by highest latency in the group; and in case of being a secondary player device (10b, 10d):Cl N240903PEP-2025001663. DOCX 78 receive information on the primary player device’s own timing from the primary player device (10a), the information on the primary player device’s own timing including either information on the primary player device’s playback time which is currently rendered or the internal timing as obtained from the primary player device’s playback time internal clock, send in response, to the primary player device, information on its playback time which is currently rendered; and receive resynchronization information from the primary player device which informs on additional latency to be observed to synchronize to the secondary player device being impaired by highest latency; and resynchronize by inserting in the playback time the additional latency.

37. The player device of any of the preceding claims, configured in case of being elected primary player device (10a), receive, from the content distribution network (5, 5a), the media content indicated in the content retrieval information and retransmit the media content to the secondary player device or secondary player devices (10b, 10d) by relaying, without any modification of the media content (51); and in case of the player device (10) being a secondary player device (10b, 10d), receive, from the primary playback device (10a), the media content (51), and decode the media content (51) before rendering the media content (51).

38. The player device of any of the preceding claimed, configured: in case of being elected primary player device (10a), receive, from the content distribution network (5, 5a), the media content indicated in the content retrieval information and retransmit the media content to the secondary player device or secondary player devices (10b, 10d), decrypting the media content, and retransmitting the media content (51) to the secondary player devices; and in case of the player device (10) being a secondary player device (10b, 10d), receive, from the primary playback device (10a), the decrypted media content (51) before decoding and rendering it.

39. A backend system (4) for assisting a streaming of remote media content towards a group (210) of player devices (10, 10a, 10b, 10d) connected to each other through a local network (220) to perform a synchronized group media playback, the backend system comprising: an interface to at least one remote content distribution network, CDN (5, 5a), to receive content retrieval information to allow a reception of the media content from the CDN (5);Cl N240903PEP-2025001663. DOCX 79 an interface to user application (3) to receive content selection (32) selecting media content to be rendered; a device manager (35) configured to: define at least one group (210) formed by a plurality of remote player devices (10); command (38), to the remote player devices (10) of the group (210), a content reception based on the content selection (31) received from the user interface, and provide information (37a) of being part of the group (210) to the remote player devices (10) selected as being in the group, and provide the content retrieval information (37), to allow a reception of the media content from the CDN (5, 5a).

40. The backend system of claim 39, wherein the content retrieval information (37) includes at least one address of the media content to be retrieved and / or information to be provided to the CDN (5) to request the media content.

41. The backend system of any of claims 39-40, wherein the content retrieval information (37) includes authenticating information of at least one player device to receive the media content from the CDN (5).

42. The backend system of any of claims 39-41 , configured to insert an identifier (37a) identifying the content retrieval information (37), the identifier (37a) being also the information (37a) of being part of the group (210).

43. The backend system of any of claims 39-42, configured to receive, from a user application (3), a command (32) indicating a selection of the media content, to be played back, the device manager (35) being configured to provide the selected media content in a content command (38) to be provided to the remote player devices (10).

44. The backend system of any of claims 39-43, configured to define and send a queue information (37) to the remote player devices (10) informing of a queue of media content to be rendered.

45. The backend system of claims 44, wherein the queue information includes a queue identifier, which identifies the group (210) and which is also the information (37a) of being part of the group (210).Cl N240903PEP-2025001663. DOCX 8046. The backend system of any of claims 39-45, configured generate the group based on at least one configuration data47. The backend system of any of claims 39-46, configured to send a backend’s command (34) for playback event to the group (210) of player devices (10).

48. The backend system of any pf claims 39-46, configured to receive the user command (31) for playback event, to trigger the backend’s command (34) for playback event.

49. The backend system of any of claims 39-48, configured to receive configuration data from the player devices, to thereby define the group (210) based on the configuration data.

50. The backend system of any of claims 39-49, configured to receive, from at least one of the player devices (10) of the group (210), information (749c) indicating a result of an election of a primary player device (10a) among the player devices (10b, 10d) of the group (210), so as to address the backend’s command (34) for playback event to the elected primary device (10a) without sending the backend’s command (34) for playback event to the other player devices (10b, 10d) of the group (210).

51. The backend system of any of claims 39-50, configured to receive configuration data from the player devices, to thereby decide a version of the media content to be received by the group (210) based on the configuration data, thereby providing the content retrieval information to the remote player devices for retrieving the decided version of the media content.

52. The backend system of any of claims 49-51 , wherein the configuration data include configuration data of a hardware media Tenderer unit (1) controlled by the player devices.

53. The backend system of any of claims 49-52, wherein the configuration data include configuration data of an operating system used by at least one of the player devices.

54. The backend system of any of claims 49-53-, wherein the configuration data include information on a hardware abstraction layer, HAL (11), at the player devices (10) for controlling a hardware media Tenderer unit (1).

55. The backend system of any of claims 49-54, wherein the synchronized group media playback includes a video wall playback where multiple, adjacent player devices of the sameCl N240903PEP-2025001663. DOCX 81 group (210) cooperate to generate a video wall displaying a global video content, each player device displaying a portion of the global video content.

56. The backend system of any of claims 39-55, configured to receive from the remote player devices information regarding their capabilities and / or conditions, so as to decide a version of the media content to be received by the group (210) based on the capabilities and / or conditions, thereby providing the content retrieval information to the remote player devices for retrieving the decided version of the media content.

57. The backend system of any of claims 39-56, configured to receive from the remote player devices information regarding their capabilities and / or conditions, so as to so as to define the group based on capabilities and / or conditions of the remove plyer devices.

58. The backend system of any of claims 39-57, configured to transmit, from each remote player device, authenticating information for being admitted to the group and for receiving the media content, the backend system being configured to check the validity of the authenticating information for being admitted to the group and, only in case of the authenticating information for being admitted to the group being and for receiving the media content valid, admitting the remote player device to the group.

59. The backend system of any of claims 39-58, configured receive, from the CDN, authenticating information for receiving the media content (51 , 51a) from the CDN (5, 5a), and to transmit to the remote player devices, and for receiving the media content for receiving the media content (51 , 51a) from the CDN (5, 5a).

60. A user application for requesting a streaming of a remote media content to group (210) of player devices (10, 10a, 10b, 10d) connected to each other through a local network (220) to participate in a synchronized group media playback, the user application being configured to: provide, to a backend system (4), content selection (31) selecting media content to be rendered; and provide commands (32) on the player devices which shall be part of the group (210).

61. The user application of claim 60, configured to receive from the backend system (4) a list of content services (5), and request to the user (99) to perform a selection of a preferred content service, and, once the preferred content service has been selected, to the backend system (4) information on the selected content service.Cl N240903PEP-2025001663. DOCX 8262. The user application of claim 60 or 61 , configured to receive from the backend system (4) a list of content which may be performed by the synchronized group media playback, and request the user (99) to select a preferred content (51) to be received, and, selected the preferred media content (51), to transmit to the backend system (4) information on the selected media content (51).

63. The user application of claim 62, wherein the information on the selected media content (51) indicates a queue (37) of media content (51) to be received and played back.

64. The user application of any of claims 60-63, configured to receive a list of player devices (744) allowed to be part of the synchronized group playback, and to request the user (99) to select at least two player devices (10a, 10b, 10d) to be part of the group (210) from the list, and, once the at least two player devices have been selected, to transmit to the backend system (4) information on the group information as part of the command 32.

65. The backend system (4) of any of claims 39-59, configured to provide, to the user application (3), a list of content services (5) as part of the at least one CDN (5), and receive, from the user application (3), a selection of a preferred content service, so that the content retrieval information (37) provided to the player devices (10) is an address of the preferred content service.

66. The backend system (4) of any of claims 39-59 and 65, configured to provide the user application (3) with a list of content which can be provided by the specific selected content service (5), and to receive a selection of the content from the user application (3).

67. The backend system (4) of any of claims 39-59 and 65 and 66, configured to provide (744) the user application (3) with a list of player devices (10a-10d) which can be part of the group (210), and to receive, from the user application (3), a selection of preferred player devices (10a-10d) which will form the group (210).

68. A method for a synchronized group media playback of a player device in a group (210) of player devices (10, 10a, 10b, 10d), the method controlling at least one hardware media renderer unit (1), including: receiving, from a remote cloud backend system (4), an information (37a, 38) of being part of the group (210) and, once having received the information (37a) of being part of the group (210):Cl N240903PEP-2025001663. DOCX 83 participating to a primary election, among the group (210), the primary election electing a primary player device (10a), the remaining player device or player devices (10b, 10d) in the group (210) being defined secondary player device or secondary player devices (10b, 10d); in case of being elected primary player device (10a), receiving media content (51 , 51a) from a content distribution network (5, 5a) and retransmitting the media content (51 , 51a) to the secondary player devices (10b, 10d), and in case of not being elected primary player device (10a) and therefore resulting a secondary player (10b, 10d), receiving media content (51 , 51a) from the primary player device (10a), both in case of being elected primary player device and in case of being a secondary player device, control the at least one hardware media Tenderer unit (1) to render the media content (51 , 51a).

69. A method for assisting a streaming of remote media content towards a group (210) of player devices (10, 10a, 10b, 10d) connected to each other through a local network (220) to perform a synchronized group media playback, the method comprising: interfacing with at least one remote content distribution network, CDN (5, 5a), to receive content retrieval information to allow a reception of the media content from the CDN (5); interfacing with user application (3) to receive content selection (32) selecting media content to be rendered; defining at least one group (210) formed by a plurality of remote player devices (10); commanding (38), to the remote player devices (10) of the group (210), a content reception based on the content selection (31) received from the user interface, and providing information (37a) of being part of the group (210) to the remote player devices (10) selected as being in the group, and providing the content retrieval information (37), to allow a reception of the media content from the CDN (5, 5a).

70. A method for a user application requesting a streaming of a remote media content to group (210) of player devices (10, 10a, 10b, 10d) connected to each other through a local network (220) to participate in a synchronized group media playback, comprising: providing, to a backend system (4), content selection (31) selecting media content to be rendered; and providing commands (32) on the player devices which shall be part of the group (210).CIN240903PEP-2025001663.DOCX 8471. A non-transitory storage unit storing instructions which, when executing in a processor, cause the processor to perform a method according to any of claims 68-70.

Images