Guest device usage

Abstract

There is disclosed an assisting system (4) for assisting in providing at least one content between a remote shared device (10) and a remote content provider (5), the assisting system being configured to: (514) receive, from a taking-over remote user application (3) executing in a taking-over remote user equipment, UE, a request (514) for a temporary provision of the at least one content, the request (514) being associated with shared device identification information (502) identifying the shared device (10) and with taking-over user account information (503) identifying a taking-over user account; (750) in case of the temporary provision of the at least one content being authorized, provide content metadata to the remote shared device (10) to start a temporary content provision session in which the at least one content is temporarily provided by the remote content provider (5) to the remote shared device (10); receive, from the taking-over remote user application (3), commands (31, 32) for controlling the provision of the at least one content; send, to the remote shared device (10), command information (34, 38) indicative of the commands (34, 38) received from the taking-over remote user application (3), so that the provision of the at least one content is controlled.

Description

[0001] CIN240905PEP-2025002612.DOCX 1

[0002] Guest Device Usage Description

[0003] There are devices which, for performing tasks (e.g., media streaming) require to be controlled by a user equipment (e.g. mobile phone) in which a user application executes. However, in some cases a user can have the user equipment with themselves, but not the device. For this reason, it may happen that the user cannot use a device, despite the device being in the neighborhood.

[0004] Summary

[0005] The invention is defined in the independent claims.

[0006] According to examples there is provided, inter alias, an assisting system for assisting in providing at least one content between a remote shared device and a remote content provider , the assisting system being configured to: receive, from a taking-over remote user application executing in a taking-over remote user equipment, UE, a request for a temporary provision of the at least one content, the request being associated with shared device identification information identifying the shared device and with taking-over user account information identifying a taking-over user account; in case of the temporary provision of the at least one content being authorized, provide content metadata to the remote shared device to start a temporary content provision session in which the at least one content is temporarily provided by the remote content provider to the remote shared device ; receiving, from the taking-over remote user application , commands for controlling the provision of the at least one content; sending, to the remote shared device , command information indicative of the commands received from the taking-over remote user application , so that the provision of the at least one content is controlled.

[0007] According to examples there is provided, inter alias, a player client device for receiving and rendering at least one media stream from a remote media content provider , the player client device comprising: an interface to a remote media content provider , configured for receiving at least one media stream from the remote media content provider; CIN240905PEP-2025002612.DOCX 2 an interface to a remote assisting system , configured for receiving, from the remote assisting system , assistance for receiving the at least one media stream; an interface to a hardware device to control the rendering of the at least one stream by the hardware device; wherein the player client device is configured, through the interface to the remote assisting system , to send to, or receive from, the assisting system shared device identification information identifying the player client device , wherein the player client device is further configured to receive content metadata information from the remote assisting system indicative of the at least one media stream to be received, so as to start a temporary media stream reception session for temporarily receiving the content, wherein the player client device is further configured to control the hardware device to provide a version of the shared device identification information in different physical format, so that a user equipment can acquire the shared device identification information .

[0008] According to examples there is provided, inter alias, a user equipment, UE , for controlling a provision of the at least one content between a remote shared device and a remote content provider , the user equipment having a user application executing therein, the user application being associated to a takin-over user account, the UE being configured to, in accordance with the user application : provide a request, to an assisting system , for the provision of the at least one content to thereby initiate a temporary content provision of the at least one content to the remote shared device , wherein the request includes taking-over user account information , which identifies the taking-over user account; receive, in case of the taking-over being a, confirmation of the authorization having been granted, and subsequently: provide a user interface for receiving, from the remote user application , commands for controlling the provision of the at least one content; send, to the assisting system , the commands to the assisting system .

[0009] Figures

[0010] Fig. 1 shows an example of an architecture in which the invention lives.

[0011] Figs. 2A and 2B show examples of operations.

[0012] Fig. 3 shows an example of grouping multiple devices.

[0013] Figs 4A-4C show operations according to an example. CIN240905PEP-2025002612.DOCX 3

[0014] Fig. 5 illustrates procedures to be done by a device maker for producing the user device.

[0015] Fig. 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 below it is shown how to provide a temporary provision of at least one content (e.g. transmission of media stream) through a shared device 10 (also 10b in some examples below), so that the shared device 10 can be temporarily provided with the content and controlled by a particular user equipment (UE) 3’ or user application 3, even if the shared device 10 is not previously associated with the user equipment (UE) 3’ or user application 3.

[0021] Fig. 1 shows an example of the ecosystem in which the invention lives. Fig. 1 shows a client device 10 which is here mostly identified as a shared device. The shared device takes this name because it can be controlled by different users. The device 10 is also called player device, since in most of the examples it will be a device for rendering media content (e.g., audio and / or video). In other examples, however, the device 10 may be an actuating device, to perform an actuating operation based on rules obtained from remote. The device 10 is also called client device because it operates, in a client / server fashion, with a server system. The shared player may have a shared device identification information uniquely identifying the device.

[0022] The shared device 10 may have, executing therein, a higher layer player or device SDK (software development kit). A player 2 (player device) may control, through control line 26, a hardware device 1. The hardware device 1 may render a media stream 51 (51a) and therefore may include and / or be connected to a video display and one or more loudspeakers. The hardware device 1 may have replay capabilities. The player device 2 may CIN240905PEP-2025002612.DOCX 4 be also controlled through a hardware abstraction layer (HAL) 11, through control line 26, which may be internal to the shared device 10.

[0023] Fig. 1 also shows a remote content provider 5 which may be a media remote content provider. A remote content provider 5 may be a media content distributing network 5. Fig. 1 shows a media CDN 5b (sending media stream 51a).

[0024] The device 10 may be updated through updating data 61 (61b) sent by the updating network 6 (6b). The organization managing the updating network 6 (6b) may be different from the organization managing the CDN 5 (5a). The organization managing the updating network 6 (6b) can be the same of the organization managing the assisting system 4 (backend).

[0025] In the Ecosystem there is provided a user equipment (UE) 3’ with a user application 3 executing therein. The user equipment 3’ may be used for controlling the content to be provided (e.g., commanding the media stream 51 to be downloaded and / or the actuation to be performed) and also the former playback control (e.g., typical controls like “Play”, “Stop”, “Fast Forward”, “Rewind”). It is noted that the user equipment 3’ is not meant at being integrated in the shared device 10. Indeed, the user equipment 3’ is normally a property of the human user, while the shared device 10 could be property of another user. Indeed, the provisions of contents discussed here are mostly controlled by a user equipment, which is not originally associated with the shared device 10. The user application 3 (and the user equipment 3’) has user account information 503 providing information on the user account (and probably also on the user equipment in which the user application 3 executes). The user account may be emitted by an organization managing an assisting system 4 (cloud backend system).

[0026] The assisting system 4 (cloud backend) is configured for assisting the remote shared device 10 in receiving the at least one content (e.g., the reception of the at least one media stream 51) from the remote content provider 5. CIN240905PEP-2025002612.DOCX 5

[0027] The assisting system 4 may be cloud-like dislocated. Notably:

[0028] • The remote shared device 10 and the remote content provider 5 are connected to each other thorough a remote connection.

[0029] • The user equipment (in which the user application 3 is executing) and the assisting system 4 are connected to a different remote connection.

[0030] • The assisting system 4 and the shared device 10 are connected to each other through another remote connection.

[0031] • The player 2 and the hardware device 1 are connected to each other through a local connection.

[0032] In principle, the shared device 10 does not have an authorization for receiving the at least one content from the remote content provider 5. On the other side, the user application 3 is not natively associated with the shared device 10. The assisting system 4 has, in its database, a priori knowledge on both the shared device 10, the user application 3, and is also interfaced with the remote content provider 5. Therefore, the assisting system 4 may be interposed between all of the user application 3, the shared device 10, and the remote content provider 5 for assisting the provision of the content (e.g., the transmission and / or rendering of a media stream).

[0033] In particular, it is explained, with particular reference to Figs. 1, 2A, and 2B, how the shared device 10 is coupled with the user application 3 (and the user equipment in which the user application 3 executes). At first the user application 3, here also called “taking-over user application”, executes in a taking-over user equipment. The user of the wording “taking- over” is justified by the fact that the device 10 is a shared device, and a user application may take control of it through the assisting system 4.

[0034] At first, as for Fig. 2A, the taking-over user application 3 may acquire the shared device identification information 502, i.e. an information which uniquely identifies the shared device 10. It will be shown later that there are some ways for taking over the shared device identification information 502. It will be shown that it is possible for the taking-over UE 3’ CIN240905PEP-2025002612.DOCX 6 to acquire automatically the shared device identification information 502. Then, the taking- over UE 3’ (e.g. controlled by the taking-over user application 3) sends a request 514 for authorization for a provision of the at least one content (e.g., provision of a media stream). The request 514 for the authorization provides information on (or more in general is associated to) the shared device identification information 502 (which identifies the shared device 10) and the taking-over user account information 503 which identifies the user account (taking-over user account) of the taking-over user application. Therefore, the taking-over user application 3 provides the request 514 to authorize the provision of a content. The request 514 for authorization is associated with the shared device application information 502 (e.g. the request 514 may provide the identification of the shared device 10) and taking-over user account information 503 which identifies uniquely the taking- over user account associated with the taking-over user application 3.

[0035] Through process 516, the assisting system 4 checks whether the taking-over user account information 503 (and in some examples also the shared device identification information 502) grants the taking-over authorization. In case of the authorization being granted (e.g. at process 520, in the content provider 5, and as indicated in the message 522), the assisting system 4 will use (518) an authenticating method with the remote content provider 5. The content provider 5 may provide content metadata to the remote shared device 10. The content metadata may be metadata indicative of the service to be provided (i.e., indicative of the media streams to be downloaded). At this point, the assisting system may inform the user application 3 of the successful authorization. The provision of the content (i.e., the download of the media stream 51) may start as soon as the user equipment 3, controlled by the user, sends a command (31, 32) for controlling the provision at the at least one content.

[0036] It is to be noted that provision of the at least one content may be controlled by the user application 3 in at least one of the two following ways:

[0037] • Through playback control (playback command 31 from the taking-over user application 3 to the assisting system 4, and playback control information 34 from the assisting system 4 to the shared device 10, providing commands controlling the media content playback, e.g. commands like “Play”, “Stop”, “Fast Forward”, “Rewind”, CIN240905PEP-2025002612.DOCX 7 e.g. without commanding, or without directly commanding, the provision of the content, such as the transmission of the media stream 51 from the content provider 5).

[0038] • Through content control (i.e., content command information 32, received from the taking-over application, and indicating which content to be provided, e.g., which media stream 51 to be downloaded, and content control 38 from the assisting system 4 to the shared device 10, indicating which content to be provided, e.g., which stream to the downloaded, without commanding, or without directly commanding, the playback).

[0039] It is now explained how the user equipment 3’ (in particular the taking-over user application 3) may acquire the shared device identification information 502 and / or howto couple the taking-over user application 3 with the shared device 10. The shared device 10 may provide the shared device identification information 502 to the taking-over UE. For example, the shared device identification information 502 as outputted by the shared device 10 (and in particular by the hardware device 1) may be a visual information 512, such as a barcode or a QR code. In some cases, the shared device information 502 as provided by the shared device 10 may be readable information (e.g., readable signs). The taking-over UE 3’, having an embedded camera or another acquiring unit, may acquire the shared device information 502. When subsequently the taking-over user application 3 will send the request 514 for receiving the content, the request 514 will be associated with the shared device identification information 502.

[0040] It is to be noted that the shared device identification information 502 as outputted by the device 10 may be encrypted and the taking-over user application 3 and / or the assisting system 4 will decrypt it to understand the features of the shared device 10 (is addressed).

[0041] In some cases, the shared device identification information 502 may be shared with the assisting system, e.g., during an installation procedure. In that case, the assisting system 4 may provide the shared device identification information 502 to the shared device or the shared device 10 may provide the shared device identification information 502 to the CIN240905PEP-2025002612.DOCX 8 assisting system 4. Then, the assisting system 4 may keep, in its database, the shared device identification information 502, and may use it in the future, as soon as the taking-over use application 3 sends the request 514 for the authorization. In some cases, the shared device identification information 502 as outputted by the shared device 10 may be updated (e.g. through the updating network 6 or 6b, through the updating data 61 or 61b) during time. In some cases, it may be the assisting system 4 which provides update information for the shared device identification information 502, so that the device 10 subsequently changes the shared device identification information 502 based on the update. In some other cases, the update may be implicit and defined by an algorithm known by both the shared device 10 and the assisting system 4.

[0042] As explained below, in some cases there may be the possibility that a group 210 of shared devices 10 is formed (e.g. in a local connection 220, e.g. a LAN, .g. wireless or wired). In the group 210, there may be multiple player devices 10a, 10b, 10c, lOd but only one of them (primary device 10a) may be the device that actually receives the media content 51 from the remote contact provider 5, and subsequently forwards the received media content 51 to the other shared devices 10b, 10c, lOd (called secondary devices) through the local connection.

[0043] It may be that the particular shared device 10b is rendered part of a particular group of devices (e.g. for participating to a synchronized playback). The other devices 10 may be either other shared devices (for which the same procedure has been carried out) or other shared devices. In some examples, the assisting system 4 may decide that at least one device is enrolled in the group and / or is banned from the group. This may be commanded, for example, by the taking-over a user application 3 through a command 32. In Fig. 3, the device 10c is not in the group 210, e.g. for decision of the user. The definition of the group 210 and of the devices 10a, 10b, lOd which are part of the group 210 may be made by the user application 3 and may be provided, for example, by the assisting application to the devices 10a, 10b, lOd. The decision on which device is the primary device 10a is here not important (it could be made by the user equipment 3, by the assisting system 4, and / or could be made by the devices 10a, 10b, lOd themselves, e.g. through a voting and / or by CIN240905PEP-2025002612.DOCX 9 taking into account parameters on the status of the devices. Moreover, it is here not relevant whether the devices 10a and lOd are shared devices or devices stably associated with the user account of the taking over user application 3’: the device 10b is here the shared device 10 of Figs. 1-2B, and the other devices 10a and lOd may be indifferently shared devices or non-shared devices. It is maintained, however, that all the devices 10a, 10b, and lOd are associated, temporarily or stably, with the user account 3 of the UE 3’.

[0044] With reference to the groups the assisting system 4 may selectively operate between: a first, restricted mode; and a second, unrestricted mode.

[0045] When operating in the second, unrestricted mode, the assisting system 4 may assist the remote shared device lOn and / or other remote device(s) (10a, lOd) to be enrolled in the group 210 and / or to be expelled from the group 210. When operating in the first, restricted mode, the assisting system 4 has the capability of enrolling in the group 210 and / or expelling from the group 210 disabled. The first, restricted mode may be in the cases in which in the restrictive mode the capability of enrolling in a group and / or expelled from a group is disabled. In some cases, the second unrestricting mode is default in the cases of all the devices in the group being non-shared devices but devices previously associated with the taking-over user application 3 (in particular the taking-over user account). In some cases, the first restricted mode may be the default mode in case of at least one device being a shared device (and all the other devices being indifferently shared devices or devices already associated with the taking-over user application. However, in case of user application 3 commanding (e.g. through command 32) a different operating mode, the assisting system 4 will change the operating mode and will send command information 38 (e.g. as part of the content control) to the devices 10a, 10b, lOd. In these cases, the group 210 can be changed also in the case of at least one shared device 10 being in the group.

[0046] It is to be noted that the provisions of content discussed above are meant to be temporary: the shared device 10b is not meant to be stably coupled with the taking-over UE (taking- over account), but only for a predetermined time span. In some cases, the temporary CIN240905PEP-2025002612.DOCX 10 content provision session may be concluded (stopped) in correspondence of a pre-defined concluding condition. Hence, subsequently, this content is not provided anymore (e.g., the media stream is not provided anymore). For example, the pre-defined concluding condition may be a condition on a time limit being elapsed.

[0047] In particular, it is possible that the shared device 10 is actually normally associated with a master UE and / or a master user application which is not shown in Fig. 1 (and is, therefore, a sharable device). The master UE or master user application may be the user application which normally is entitled to control the sharable device 10. The master UE or master user application therefore may allow the sharable device 10 to be temporarily controlled, through the temporary content provision session, by the taking-over user application or taking-over a UE (and to therefore become a shared device). The master UE and / or master user application may enable and disable the capability of initiating the temporary content provision session. If the taking-over UE 3’ tries to take over the control of the shared device 10, the assisting system 4 will refuse the take-over. Even in the cases discussed above relating to the pre-defined concluding condition may be controlled by the master UE and / or master user application: The master UE and / or master user application may indicate a time span during which the taking-over UE may control the shared device. In other cases, it is possible that the main UE and / or main taking-over user application trigger an immediate conclusion of the temporary content provision session. Advantageously, while the hardware capabilities of the shared device 10 are exploited for the temporary provision of the content and for the playback (or the actuation), the data of the master user account are not shared by the taking-over user account. For example, the assisting system 4 will refrain from providing chronology information on previously contents previously provided to the master user application and / or master UE.

[0048] The knowledge of the master user can facilitate the coupling of the taking-over user application 3 with the shared device 10, e.g. like in Fig. 2A. Fig. 2A shows that the human user provides the shared device identification information 502, e.g. by manual input (e.g. by operating through a link received from the assisting system 4 or from an organization commanded by the assisting system 4 or by the master user, the link causing the triggering CIN240905PEP-2025002612.DOCX 11 of the provision of the shared device identification information 502 to the user application 3). The taking-over user therefore may skip the QR code reading. In this case, the shared device identification information 502 may be constituted by the information on a master user account, which is determined by the assisting system 4 as being the associated to the shared device 10. The shared device identification information 502 may be a password, in some cases, and may be protected with encryption techniques in some examples.

[0049] In some cases, however, if there is a set of sharable devices 10 at disposal because the master user account may have a set of sharable devices associated with. In this case, it is necessary for the assisting system 4 to restrict the set of the sharable devices 10 each of which could become the shared device. The assisting system 4, once has the knowledge of the master user account already know the all the instances (one for each sharable device) of the sharable device identification information 502: the assisting system 4 shall only, receive the command on which, among all the sharable devices, is to selected as shared device. In this case, it is possible to send an indication to the user application 3, which may request the user which sharable device to choose. The human user may perform the choice through the user interface, and the selection will be sent to the assisting system 4 as one of the control commands 32. The assisting system 4 will notify the sharable device 10 that it is become a shared device.

[0050] In examples above, the master user (e.g. owner of the shared device 10) may be the only one which is allowed by the assisting system to stably disassociate the device 10 with its own account.

[0051] It is also possible, in some examples, to share one shared device 10 among multiple user accounts (i.e., multiple human users). For example, the master user may concede that multiple users (e.g., authorized users) temporarily access to the content provision. However, one single user will control the shared device 10 at time. To cope with this issue, rules (e.g., priorities between users) may be defined. The assisting system 4 may therefore receive, e.g. through the master user application, of indications of rules for choosing one user instead of one other (e.g., a user being given priority over another one). It may be CIN240905PEP-2025002612.DOCX 12 defined, for example, that in case of the request for authorization by a higher-priority user, then the lower priority user loses the temporary content provision, at the advantage of the higher-priority user, which is the winner user.

[0052] The elements of Fig. 1

[0053] Fig. 1 shows an example of an ecosystem in particular in the case of providing media content (the same may be obtained, however, for generic contents to be provided, and not only media streams to be transmitted). Fig. 1 shows the shared device 10. The shared device 10 may control the shared device hardware 1 (which may be a display device and / or loudspeakers and / or a hardware connection to the loudspeakers). The shared device 10 may receive the content e.g. media content 51 (51a), from the content provider 5, e.g. media content distribution network (CDN) 5 (sending content 51a). The assisting system (cloud backend system) 4 may control the shared device 10 (10a, 10b, 10c, lOd), e.g., through content control 38 and / or playback control 34. The shared device 10 may include a device software development kit (SDK) / player 1, which is a software instance.

[0054] The assisting system 4 may control the playback and the reception of the media streams through control commands 34, 48. The media content provider 5 which provides the content is not the same as the cloud backend system (assisting system) 4. The content 51 (51a) is transported through remote connection different from the remote connection through which the control commands 34 and 38 are sent (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).

[0055] 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, 51a). The decrypted media content 29a may therefore be provided to a hardware media renderer unit 1. The hardware media renderer unit 1 may include the 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 may be controlled by hardware control and / or hardware events 26, e.g. sent by the device CIN240905PEP-2025002612.DOCX 13

[0056] SDK / player 2. The device SDK / player 2 may provide the hardware control and hardware events 26 based, in particular, on the control 34 and 38 accepted by the cloud backend system 4 (assisting system). The shared device 10 may be connected to a local network (e.g., LAN) 220. 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.

[0057] The device SDK / player 2 may contain an updater 25, which may receive updating data from the update network 6b (6). The updating network 6 (6b) can be, for example, managed by parties different from those which manage the CDN 5 (it may be managed, for example, by the same organization managing the could backend, in some examples). The updating network 6 may update the player SDK 2, e.g. where necessary. As can be seen from Fig. 1, the shared device 10 may receive content control 38 (e.g. content control commands), which may include, for example, information on queues or more in general on content 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 or more in general of the content 37), e.g. together with address (e.g., URL address) of where the media content 51 (51a) is to be retrieved (e.g. address of locations associated to the CDN 5, 5a). The cloud backend (assisting system) 4 may transmit playback control commands 34. The playback control 34 may include, for example, well- known commands, such as “PLAY" “PAUSE", “STOP", “FAST FORWARD", “REWIND". The cloud backend (assisting 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 shared device 10. The device manager 35 may have a virtual replica of the shared device 10 and may therefore have the substantial control of the operations of the shared 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 CIN240905PEP-2025002612.DOCX 14 equipment (e.g., a smart phone, mobile phone, tablet, assigned computer) of property of the user and / or may be integrated in the shared device 10. 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, lOd) (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 UE 3’.

[0058] The UE 3’ may be provided e.g. by the cloud backend system (assisting 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 shared device 10 (and more in general all the shared devices lOa-lOd). The application 3 may present a user interface for obtaining settings to render content.

[0059] Even if between the UE 3’, the cloud backend system (assisting system) 4, the shared 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 most relevant commands. It is notwithstanding possible that feedback information may be transmitted in any different direction. For example, the UE 3’ may receive feedback from the cloud backend (assisting 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 51b 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).

[0060] Description of Further Embodiments of the Ecosystem

[0061] 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 mobile device owned by the user. However, the Media CDN (content delivery network) does not necessarily need to be located in the device as a library or any other collection of media, but CIN240905PEP-2025002612.DOCX 15 can also be located anywhere in the cloud. In this embodiment, the mobile device has an interface for interfacing with the Media CDN in the cloud.

[0062] A “final” or endpoint device is the device HW that typically consists of a replay functionality such as a loudspeaker or a video screen and some interface buttons such as stop buttons, pause buttons, etc.

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

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

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

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

[0067] Seen from the perspective of the cloud backend system 5, the cloud backend system 5 interfaces on the one hand, with the app on the user’s mobile 3 or stationary device 3, with the media app content delivery network, and with the device SDK / player. However, the cloud backend system 3 does not interface directly to the actual replay device or “device HW" 1. CIN240905PEP-2025002612.DOCX 16

[0068] In the cases in which the cloud backend system 4 is distributed in a cloud, this functional unit maintains, among others, several databases that include, among others, “Live Services” functionalities that represents the actual interface between the media app content delivery network (media app CDN) 5 and the cloud backend system 4 (assisting system).

[0069] Fig. 4A to 4C illustrate a procedure showing a sequence of steps / message between the user 99, the taking over user application 3, the cloud backend system 4 (assisting system 4), the media runtime device software 2 (e.g. in the shared player device 10) and the content service (CDN) 5 (5a) (content provider) 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 (providers), users. Furthermore, the heavy-weight data or content is retrieved directly by the media runtime device, while the assisting system 4 only handles the playback commands. The data of authorized devices (among which the shared device) 10 and authorized providers for the user 99 are stored and retrieved from databases that are part of or are accessible by the assisting system 4. These databases contain all data that is necessary for authorized access to a content provider, where tokens are needed for access. When, in the Fig. 4A, Fig. 4B diagram such data is looked-up in the assisting system, it is retrieved from a corresponding database.

[0070] Furthermore, Fig. 4A makes clear that each message between the taking-over user application 3 and the assisting system 4 refers to actions of the entities involved. The first action is that the user application sends out the message 700 via the assisting system interface, and the second action performed by the assisting system 4 is that the assisting system 4 receives the message 700 via the application interface 206.

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

[0072] In the action 602, the user 99 opens the user application 3 running on the user application apparatus. In action 603, the user logs into the user application and, in reply to this logging CIN240905PEP-2025002612.DOCX 17 into the user application 3, the user authenticates itself via the message 700 from the user application 3 to the assisting system 4. The message 700 may be an example of the action 514 (request for authorization for the temporary provision of the content). The message 700 may therefore provide the information 503 (taking-over user account), to which the request 514 for authorization of taking-over (which can be received subsequently) will therefore be associated. Then, in order to further use the assisting system 4, the user application 3 receives a token (which is an authenticating information) including the user’s permissions and the corresponding user ID in message 605. The user token may be used in all calls to the assisting system 4 to identify the user and to check if access is allowed for the requested function for the user.

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

[0074] Then, for each identified content provider 5, it is checked, whether the user 99 (or user application 3) is allowed to use the content service (content provider), if the user is not allowed, the content provider is removed from the result. In a step 708, it is checked, whether the content provider 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 assisting system returns a list of allowed content providers to the user application.

[0075] This list is presented to the user via the user interface in the user application and the user then selects a content provider from the list provided 710 in the step 712. Then, based on the selected content provider, the user application 3 requests a list of content in message 714. CIN240905PEP-2025002612.DOCX 18

[0076] In response to that, the assisting system 4 looks up, whether credentials (which are authenticating information) for this content providers are stored in the assisting system. This is done in step 716, and when such user credentials for the requested content provider are found, an authentication message 718 is sent from the assisting system to the content provider via the communication interface 204 of the assisting system. The message 718 may be an example of the message 518.

[0077] 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 provider 5, or any other positive authentication result.

[0078] In response to the positive result 720, the assisting system 4 requests content metadata in a message 722 from the content provider 5 (5a), and the content provider 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 provider 5 to receive, under authorization, the content 51 (51a).

[0079] This list of content is then forwarded from the assisting system to the user application in step 725 for display to the user 99 via the user interface 302.

[0080] 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, lOd) for the selected content from the assisting system. It is to be noted that only the device 10a is, in this case, the shared device, while the other devices may be property of the user 99.

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

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

[0083] Notably, the procedure is also performed, in parallel, as 731, to check whether a particular device 10 is allowed to take over. In practice, the list consisting of item 732 to 742 not only refers to the authorized devices 10 (e.g., those which are property of the user 99), but also the guest devices which may be taken over by the user 99. The list of items 732-742 is indicative, and any combination of those checks (or other checks) may be performed.

[0084] 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.

[0085] Instead 734, it is determined, whether the content provider 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.

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

[0087] This could also be determined from a certain database.

[0088] 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.

[0089] 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 assisting system, for example for the purpose of children control.

[0090] 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 CIN240905PEP-2025002612.DOCX 20 device as defined earlier when establishing the certain profile in a library of the assisting system.

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

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

[0093] Then, the user 99 (e.g. through the user application 3) may act 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 devices (e.g. 10a) from the list of allowed devices (e.g. the list including 10a, 10b, 10c, lOd), the guest devices for which it is allowed to take over being selectable through 745. Then, the user 99 (e.g. through the user application 3) may start the playback of the selected content on the selected devices via action 746 (which may trigger action 748 which may include, or be an instantiation of, playback command request 31 in Fig. 1, but also the shared device identification information 502). This user action 746 may result in the message 31 from the user application 3 to the assisting system that requests the playback for the selected content on the selected devices, where this message is illustrated at 748 in Fig 4B.

[0094] The content metadata (including authorization information) may be sent (750) from the cloud assisting system 4 to the media runtime device software 2 on the shared user device 10a. 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 shared user device 10 (10a) 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 or be accompanied by authentication information (e.g., obtained in message 748 from the assisting system) 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 CIN240905PEP-2025002612.DOCX 21 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 shared device 10a) and this takes place via media interface of the user device 10a and the content is replayed as illustrated at 754. The authenticating information from the player device 10a to the CDN 5 may be verified by the CDN 5. Or, the unique address of the player device 10a may be verified by the CDN 5, the unique address of the player device 10a serving as authenticating information.

[0095] Fig. 4C 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 assisting system. Only when the assisting system confirms that such a procedure is allowed, where this check is not illustrated in Fig. 4C, the assisting system requests control playback via message 764 (which may include or embody the playback control 38) from the media runtime device software 2 of the 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 assisting system 4 and a corresponding confirmation is sent from the assisting system back to the user application via message 770. As explained above and below, however, commands may also be provided directly on the device 10a.

[0096] It is to be emphasized that the order of the selection of the content service (content provider) 712, the selection of the content to play 726, and the selection of the devices (including the devices to which the user takes over) from the list of allowed device 745 can also be done in a different order. Furthermore, in case of only a single content provider and only a single user device, several checks and messages can be omitted in order to nevertheless implement the full control of the assisting system over the user device, which the media runtime device software 2 is installed. CIN240905PEP-2025002612.DOCX 22

[0097] In general terms, the user application 3 may receive from the backend system 4 a list of content providers 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 provider, the user application may transmit to the backend system 4 information on the selected content provider. (This is not necessary in the cases in which there is only one single content provider at disposal).

[0098] The user application 3 may receive (e.g. once the preferred content provider has been selected) from the backend system 4 a list of content provided by the specific selected content provider 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.

[0099] 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 a synchronized group playback. 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 to be part of a group 210 from a list of selectable player devices provided by the backend system 4. The backend system 4 (and in particular the device manager 35) may therefore apply the content queue 37a and send the information on the queue 37 and the queue identifier 37 to all the selected player devices. The user application 3 and the backend system 4 will be uninterested to the election procedure of which is the device 10a will be received by the backend system 4 from the device 10a or another of the player devices 10.

[0100] Therefore; the assisting system (4) is configured to:

[0101] (514) receive, from the taking-over remote user application (3), a request (514) for a temporary provision of the at least one content, the request (514) being associated with shared device identification information (502) identifying the shared device (10) and with taking-over user account information (503) identifying a taking-over user account; CIN240905PEP-2025002612.DOCX 23

[0102] (750) in case of the temporary provision of the at least one content being authorized, provide content metadata to the remote shared device (10) to start a temporary content provision session (777) during which the at least one content 51 is temporarily provided by the remote content provider (5) to the remote shared device (10); receive, from the taking-over remote user application (3), commands (31, 32) for controlling the provision of the at least one content; send, to the remote shared device (10), command information (34, 38) indicative of the commands (34, 38) received from the taking-over remote user application (3), so that the provision of the at least one content is controlled.

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

[0104] 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.

[0105] 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.

[0106] 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 CIN240905PEP-2025002612.DOCX 24 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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.

[0111] 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 CIN240905PEP-2025002612.DOCX 25 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 ways to access a data source or data sink platform different from via a playable URL can be performed as well.

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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 CIN240905PEP-2025002612.DOCX 26 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.

[0116] 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.

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

[0118] 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.

[0119] 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.

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

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

[0122] 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 CIN240905PEP-2025002612.DOCX 27 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 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.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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, CIN240905PEP-2025002612.DOCX 28 images, and videos is supported as well as an upload of audio data, video data or image data or media data.

[0127] 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.

[0128] 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 / accountfor 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.

[0129] 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.

[0130] 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, CIN240905PEP-2025002612.DOCX 29 devices performing continuous playback will forcefully install the updates after a defined time. Update packages are stored on the distributed CDN (Content Delivery 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.

[0131] 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.

[0132] 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.

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

[0134] 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.

[0135] 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. CIN240905PEP-2025002612.DOCX 30

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

[0137] 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.

[0138] 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.

[0139] 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 IMEI (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.

[0140] Discussion CIN240905PEP-2025002612.DOCX 31

[0141] Within the Cloud Ecosystem every Device 10 (lOa-lOd) may have exactly one owner account (which can be a user or a company). All Content Services are also associated with one account. Services can’t be shared with other accounts. For Devices 10 on the other hand there can be a need to share the device 10 (or rather allow using the device for playback) with a different account.

[0142] Scenarios for sharing a device with a different account include:

[0143] • Family members wanting to use a device

[0144] • Friends wanting to play some content while visiting

[0145] • Hotel Guests wanting to use a device within their Hotel Room during a stay

[0146] • Playing content on a health & fitness device during exercise

[0147] • Allowing a sub -contractor to control playback on a device

[0148] In order to be able to use a shared device the user may also need to have a user Account with Content providers connected, it is important to know that only the device 10 is being shared and the Content provider of the original (master) account are not being shared.

[0149] Sharing a device 10 with a different account can happen in two ways:

[0150] 1. Sharing a device with a known account (master user account)

[0151] In case the account that a device should be shared with is known (known email address) this account can directly be added to a device and hence allow the device being used by that account.

[0152] 2. Sharing a device with an unknown account

[0153] If the account is not known or for convenience it is also possible to create a QR code (e.g. embodying the shared device identification information 502) that can be scanned by the user equipment 3’ and the device 10 will be usable for that account. This QR code can either be accessed within the Mobile App 3 or can also be displayed on a device itself (in case the device has a display) CIN240905PEP-2025002612.DOCX 32

[0154] Besides the actual sharing part for the device 10 there are options available to limit certain aspects of using at least one the shared device operation modes:

[0155] • Sharing device 10 only for playback, no changes to the device possible (i.e., no renaming, adding to group, using in group playback, ...)(e.g. first, restricted mode, see above)

[0156] • Sharing device 10 that can be integrated in groups, used with group playback etc. (e.g. second, unrestricted mode, see above)

[0157] • Sharing device 10 in full, making the sharing account a temporary owner of the device, the device can be renamed, grouped, etc. it can also be re-shared from the temporary owner (but it can’t be deleted) (third fully unrestricted more).

[0158] The owner (mater user) can also decide to only share a device 10 for a limited time period, this can mean sharing a device for an unlimited amount of time, weeks, days, hours or even minutes (as an example of pre-defined concluding condition). This allows to provide most flexibility to handle shared devices.

[0159] It is also possible to have a device 10 in an always shared mode, where after a shared device 10 is returned, it will automatically create a new share QR code. In particular this is useful for hospitality as well as health & fitness use-cases.

[0160] An account that has a shared device will always, in some examples, have the option to return the device 10 to the original owner (e.g. by request of the master user). It will also be visible if a device is shared or not within the user Application 3.

[0161] The device owner (master user) may also remain in full control, only the owner can remove a device, the owner also always can remove an account from a shared device. Providing the most flexibility.

[0162] With this capability Devices 10 can easily be shared among different users, while maintaining clear ownership and control, not requiring physical interaction with the device CIN240905PEP-2025002612.DOCX 33 or even the necessity to be on the same network as all control is still fully handled from the cloud. It also maintains secure access to services, as these remain in the account and the devices have no information on services.

[0163] Further embodiments

[0164] Owner (master user) can decide on priority if devices 10 are shared between multiple users.

[0165] Owner (master user) can decide to shared devices 10 with multiple or only one user and can also define if a temporary owner can re-share the device with one or multiple other accounts.

[0166] Cloud Ecosystem

[0167] This preferred embodiment used the group playback invention within a new cloud ecosystem, which consists of multiple parts and roles:

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

[0169] 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).

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

[0171] 4. Content Services (content provider, CDN) 5 - 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). CIN240905PEP-2025002612.DOCX 34

[0172] 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.

[0173] 6. Device (10, 10a, 10b, 10c, lOd) - 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.

[0174] 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.

[0175] 8. Cloud Backend 4 - 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.

[0176] 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.

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

[0178] 11. App or user application (3) - an application e.g. 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 CIN240905PEP-2025002612.DOCX 35 running on a smart phone or tablet or can be running in a browser or an application running on a PC.

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

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

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

[0182] 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, (hi.) screens, keyboard for interactive content. Examples for generating are (i.) microphones for audio, (ii.) cameras for video and pictures.

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

[0184] 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 the Content Services credentials, and vice-versa. This allows the Cloud Ecosystem to e.g., access content from Content Services.

[0185] 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 queue management, playback management, etc.).

[0186] The ecosystem is a system consisting of

[0187] - An unlimited number of Devices 10 (lOa-lOd)

[0188] - An unlimited number of Users

[0189] - An unlimited number of Media Apps 3

[0190] 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.

[0191] - 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, CIN240905PEP-2025002612.DOCX 36 secure boot, DRM, etc.) for the purpose of e.g., ensuring best possible playback quality, and / or the minimum security requirements (ii.) Devices from which Device Brand(s) will be allowed to play their content, or to not play their content, (hi.) 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).

[0192] 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, (hi.) allow Device Makers to extend their own applications the capability to manage Devices via Management Services (e.g., Device onboarding to the Cloud Ecosystem).

[0193] 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, (hi.) 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.

[0194] Advantages of our ecosystem are, amongst others:

[0195] - 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.

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

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

[0198] Description of Further Embodiments of the Guest Device Usage invention CIN240905PEP-2025002612.DOCX 37

[0199] A preferred use case of an embodiment is that one is in the fitness studio and exercises on a treadmill. Then, the person uses her or his mobile phone 3’ can then connect to the treadmill display (which may be the hardware device 1, to which may be controlled by the hardware device 1). In an embodiment, the device SDK / player 2 is stored on the treadmill display hardware so that the treadmill display corresponds to the “device HW” 1. The treadmill display 1 can show e.g., a QR code (502) and the onboarding procedure takes place. Notably, the treadmill does not belong to the user of the treadmill but belongs to the manager or owner of the gym. Hence, in order to move forward, a communication between the different instances takes place which is different from the communication procedure in the situation where the user owns the hardware device (device HW) 1 or the user does not own the device in case of the treadmill example or in case of a television set in a hotel room, for example, where a “guest solution” is implemented.

[0200] In an embodiment, the cloud backend 4 already interacts when a user with a mobile app 3 checks in with the gym even before the user actually comes into touch with the treadmill or with any other sport installation in the gym.

[0201] Description of Further Embodiments of the Ecosystem

[0202] 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 mobile device owned by the user. However, the Media CDN (content delivery network) does not necessarily need to be located in the device as a library or any other collection of media, but can also be located anywhere in the cloud. In this embodiment, the mobile device has an interface for interfacing with the Media CDN in the cloud.

[0203] A “final” or endpoint device is the device HW that typically consists of a replay functionality such as a loudspeaker or a video screen and some interface buttons such as stop buttons, pause buttons, etc. CIN240905PEP-2025002612.DOCX 38

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

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

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

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

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

[0209] Due to the fact that the cloud backend 4 is distributed in a cloud, this functional unit maintains, among others, several databases that include, among others, “Live Services” functionalities that represents the actual interface between the media app content delivery network (media app CDN) 5 and the cloud backend 4.

[0210] Generally, at least four instances will cooperate with each other or with only selected ones of all instances. These are the final replay hardware deceive (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). CIN240905PEP-2025002612.DOCX 39

[0211] The present invention allows a distributed Communication between the Content Data and the Control Data.

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

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

[0214] A specific functionality provided to the user of the hardware player is to also press buttons on the 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 are not forwarded directly to the streaming website, but only via the cloud backend. CIN240905PEP-2025002612.DOCX 40

[0215] Furthermore, embodiments of the cloud backend make sure that correct reports back to the artist with respect to Copyrights, etc. are assured by the cloud backend.

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

[0217] 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.

[0218] 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.

[0219] 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.

[0220] 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.

[0221] 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. CIN240905PEP-2025002612.DOCX 41

[0222] 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.

[0223] 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.

[0224] 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.

[0225] 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.

[0226] 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.

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

[0228] 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. CIN240905PEP-2025002612.DOCX 42

[0229] 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.

[0230] Some aspects

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

[0232] 2. Apparatus, method or computer program for controlling a user device, wherein the apparatus, method or computer program is separate from the user device.

[0233] 3. Apparatus, method or computer program for communicating between the user device and the controller as described above.

[0234] 4. Apparatus, method or computer program of one of the preceding aspects, wherein the user device and / or the controller is / are an element of an ecosystem as described above, the ecosystem comprising a cloud backend.

[0235] 5. System, method or computer program for implementing a guest device procedure between a user device and a controller being separate from the user device as described above.

Claims

CIN240905PEP-2025002612.DOCX 43Claims1. An assisting system (4) for assisting in providing at least one content between a remote shared device (10) and a remote content provider (5), the assisting system being configured to:(514) receive, from a taking-over remote user application (3) executing in a taking- over remote user equipment, UE, a request (514) for a temporary provision of the at least one content, the request (514) being associated with shared device identification information (502) identifying the shared device (10) and with taking-over user account information (503) identifying a taking-over user account;(750) in case of the temporary provision of the at least one content being authorized, provide content metadata to the remote shared device (10) to start a temporary content provision session in which the at least one content is temporarily provided by the remote content provider (5) to the remote shared device (10); receive, from the taking-over remote user application (3), commands (31, 32) for controlling the provision of the at least one content; send, to the remote shared device (10), command information (34, 38) indicative of the commands (34, 38) received from the taking-over remote user application (3), so that the provision of the at least one content is controlled.

2. The assisting system of any of the preceding claims, configured to (700) initially authenticate the user application, so that the taking-over user account information (503) is subsequently already associated with the subsequently provided request (514) for authorization.

3. The assisting system of any of the preceding claims, configured to (700) initially authenticate the user application, configured to provide (744) to the user application (3) a list of devices from which the user application is allowed to temporarily receive the at least one content, and further configured to receive a selection of the allowed device (748) as the request for temporary provision of the at least one content (514).

4. The assisting system of any of the preceding claims, configured to provide to the user application (3) a list (725) of the contents which can be provided by the remote content provider (5), and to receive from the user application, in response, a selection (728) of the content to be provided.CIN240905PEP-2025002612.DOCX 445. The assisting system of claim 4, wherein the selection of the content to be provided is performed before the request for authorization (514) or together with the request for authorization (514).

6. The assisting system of any of the preceding claims, wherein the provision of the at least one content includes the transmission of at least one media stream (51) from the remote content provider (5) to the remote shared device (10), wherein the remote shared device (10) is configured to render the at least one media stream.

7. The assisting system of any of the preceding claims, configured to send to, or receive from, the remote shared device (10), shared device identification information (502) to be provided to the taking-over UE, the shared device identification information (502) identifying the shared device (10) and being meant to be acquired by the taking-over UE to be part of the shared device identification information (502); the assisting system (4), in checking (731) whether the shared device identification information (502) and the taking-over user account information (503) grants the authorization, being configured to check whether the shared device identification information (502) from the taking-over user application (3) corresponds to the shared device identification information (502) shared with the remote shared device (10).

8. The assisting system of claim 7, wherein the shared device identification information (502) is encrypted.

9. The assisting system of any of claims 7-8, wherein the shared device identification information (502) is a visual information.

10. The assisting system of claim 9, wherein the shared device identification information (502) is or at least includes a QR code.

11. The assisting system of any of claims 9-10, wherein the shared device identification information (502) is or at least includes a barcode.

12. The assisting system of any of claims 9-11, wherein the shared device identification information (502) is or at least includes readable signs.CIN240905PEP-2025002612.DOCX 4513. The assisting system of any of claims 9-12, wherein the shared device identification information (502) is or at least includes a string.

14. The assisting system of any of the preceding claims, configured to send to, or receive from, the remote shared device (10), update shared device identification information (502) to subsequently change the previous shared device identification information (502) with the update shared device identification information (502).

15. The assisting system of any of the preceding claims, configured to share, with the remote shared device (10), a update taking-over rule to derive taking-over update information for the shared device identification information (502), to subsequently change the previous shared device identification information (502) using the update shared device identification information (502) based on the update taking-over rule.

16. The assisting system of any of the preceding claims, configured to assist the remote shared device (10a) and at least one other remote device (10b) having, or receiving, authorization.

17. The assisting system of claim 16, configured to assist the remote shared device (10a) and the at least one other remote device (10b) to participate, within a group, to a synchronized coordinate operation, ruled by the content received from the content provider.

18. The assisting system of claim 17, configured to assist the remote shared device (10a) and / or the at least one other remote device (10b) to be enrolled in the group and / or to be expelled from the group.

19. The assisting system of claim 18, configured to provide, to receive commands (32) from the user application (3) on the remote shared device (10a) and / or the at least one other remote device (10b) to be enrolled in the group and / or to be expelled from the group.

20. The assisting system of any of claims 16-19, configured to selectively operate between a first, restricted mode, and a second, unrestricted mode, configured:CIN240905PEP-2025002612.DOCX 46 when operating in the second, unrestricted mode, to assist the remote shared device (10a) and / or the at least one other remote device (10b) to be enrolled in the group and / or to be expelled from the group, and when operating in the first, restricted mode, to disable the capability of enrolling in a group and / or expelling from a group.

21. The assisting system of any of clams 17-20, configured to operate in the second, unrestricted mode only when no remote shared device (10) is authorized, but only at least one remote unshared device (10) is authorized.

22. The assisting system of any of the preceding claims, wherein the shared device is already associated to a pre-established user account, a pre-associated user application (3) and pre-associated UE, wherein configured to operate in the unrestricted mode, when the shared device has no taking-over authorization.

23. The assisting system of any of the preceding claims, configured to conclude the temporary content provision session in correspondence of a pre-defined concluding condition, so that, subsequently, no provision of the content occurs.

24. The assisting system of claim 23, wherein the pre-defined concluding condition is a condition on a time limit being elapsed.

25. The assisting system of any of the preceding claims, configured to be connected with a master user application and / or a master UE enabling and / or disabling the capability of performing the temporary content provision session with the taking-over user application.

26. The assisting system of claim 25 when depending on claim Ila, wherein the master user application and / or master UE is configured to define the pre-defined concluding condition.

27. The assisting system of any of claims 25-26, configured to not share information of a master user account associated with the master user application and / or master UE.

28. The assisting system of any of claims 25-27, configured to not provide access and / or to not provide chronology information on previously contents previously provided to the master user application and / or master UE.CIN240905PEP-2025002612.DOCX 4729. The assisting system of any of claims 25-28, configured to receive, as the shared device identification information (502) identifying the shared device (10), information on a master user account, the assisting system (4) being configured, based on the information on a master user account, to derive the shared device identification information (502) and / or to restrict a search of the shared device identification information (502) to a restricted set of shared devices associated with the shared device (10).

30. The assisting system of any of claims 25-29, configured to receive, from the master user application and / or a master UE, a rule for solving multiple UEs concurrently requesting authorization, so as to grant the temporary content provision to a winning UE chosen according to the rule.31 A player client device (10) for receiving and rendering at least one media stream from a remote media content provider (5), the player client device comprising: an interface to a remote media content provider (5), configured for receiving at least one media stream from the remote media content provider; an interface to a remote assisting system (4), configured for receiving, from the remote assisting system (4), assistance for receiving the at least one media stream; an interface to a hardware device (1) to control the rendering of the at least one stream by the hardware device; wherein the player client device is configured, through the interface to the remote assisting system (4), to send to, or receive from, the assisting system (4) shared device identification information (502) identifying the player client device (10), wherein the player client device is further configured to receive content metadata information from the remote assisting system (4) indicative of the at least one media stream to be received, so as to start a temporary media stream reception session for temporarily receiving the content, wherein the player client device is further configured to control the hardware device (1) to provide a version of the shared device identification information (502) in different physical format, so that a user equipment can acquire the shared device identification information (502).

32. The player client device of claim31, wherein the shared device identification information (502) is encrypted.CIN240905PEP-2025002612.DOCX 4833. The player client device of claim 32, wherein the hardware device (1) include a video display (252) and the player client device is configured to display the shared device identification information (502) as a visual information.

34. The player client device of claim 33, wherein the shared device identification information (502) is or at least includes a QR code.

35. The player client device of any of claims 33-34, wherein the shared device identification information (502) is or at least includes a barcode.

36. The player client device of any of claims 33-35, wherein the shared device identification information (502) is or at least includes readable signs.

37. The player client device of any of claims 32-36, wherein the shared device identification information (502) is or at least includes a string.

38. The player client device of any of claims 31-37, configured to send to, or receive from, the remote assisting system (4), update shared device identification information (502) to subsequently change the previous shared device identification information (502) with the update shared device identification information (502).

39. The player client device of any of claims 31-37, configured to share, with the remote assisting system (4), a update taking-over rule to derive update shared device identification information (502), to subsequently change the previous shared device identification information (502) using the update shared device identification information (502) based on the update taking-over rule.

40. A user equipment, UE (3’), for controlling a provision of the at least one content between a remote shared device (10) and a remote content provider (5), the user equipment having a user application (3) executing therein, the user application (3) being associated to a takin-over user account, the UE being configured to, in accordance with the user application (3): provide a request (514), to an assisting system (4), for the provision of the at least one content to thereby initiate a temporary content provision of the at least one content to the remote shared device (10), wherein the request includes taking-over user account information (503), which identifies the taking-over user account;CIN240905PEP-2025002612.DOCX 49 receive, in case of the taking-over being a, confirmation of the authorization having been granted, and subsequently: provide a user interface for receiving, from the remote user application (3), commands (31, 32) for controlling the provision of the at least one content; send, to the assisting system (4), the commands to the assisting system (4).

41. A method for assisting in providing at least one content between a remote shared device (10) and a remote content provider (5), the method comprising:(514) receiving, from a taking-over remote user application (3) executing in a taking-over remote user equipment, UE, a request (514) for a temporary provision of the at least one content, the request (514) being associated with shared device identification information (502) identifying the shared device (10) and with taking-over user account information (503) identifying a taking-over user account;(750) in case of the temporary provision of the at least one content being authorized, providing content metadata to the remote shared device (10) to start a temporary content provision session in which the at least one content is temporarily provided by the remote content provider (5) to the remote shared device (10); receiving, from the taking-over remote user application (3), commands (31, 32) for controlling the provision of the at least one content; sending, to the remote shared device (10), command information (34, 38) indicative of the commands (34, 38) received from the taking-over remote user application (3), so that the provision of the at least one content is controlled.

42. A method for receiving and rendering at least one media stream from a remote media content provider (5), comprising: receiving at least one media stream from the remote media content provider; receiving, from the remote assisting system (4), assistance for receiving the at least one media stream; controlling the rendering of the at least one stream by the hardware device; sending to, or receiving from, the assisting system (4), shared device identification information (502) identifying the player client device (10), receiving content metadata information from the remote assisting system (4) indicative of the at least one media stream to be received, so as to start a temporary media stream reception session for temporarily receiving the content,CIN240905PEP-2025002612.DOCX 50 controlling the hardware device (1) to provide a version of the shared device identification information (502) in different physical format, so that a user equipment can acquire the shared device identification information (502).

43. A method for controlling a provision of the at least one content between a remote shared device (10) and a remote content provider (5), the method using a user application (3), the user application (3) being associated to a takin-over user account, the method comprising: providing a request (514), to an assisting system (4), for the provision of the at least one content to thereby initiate a temporary content provision of the at least one content to the remote shared device (10), wherein the request includes taking-over user account information (503), which identifies the taking-over user account; receiving, in case of the taking-over being a, confirmation of the authorization having been granted, and subsequently: providing a user interface for receiving, from the remote user application (3), commands (31, 32) for controlling the provision of the at least one content; sending, to the assisting system (4), the commands to the assisting system (4).

44. A non-transitory storing unit storing instructions which, when executed by a processor, cause the processor to perform the method of any of claims 41-43.

Images