Method and system for content delivery to user

Abstract

Method and system for content streaming to user The method for streaming a content to a user device intended to play said content, comprises : - a step of streaming a first part of the content, followed by a step of streaming a second part of the content, wherein said first part of the content is without DRM protection and said second part of the content is DRM- protected; - a DRM authentication process for authenticating the user device and providing the user device with a DRM license for the content, carried out at least partially while streaming the first part of the content, enabling playback of the first part to begin before completion of the DRM authentication process (940), and allowing playback of the second part when the DRM authentication process is complete (940).

Description

Method and system for content delivery to userTECHNICAL FIELD

[0001] The present disclosure relates to digital content streaming or delivering and security, for example live or on-demand video streaming.BACKGROUND

[0002] In the context of live or on-demand content streaming, DRM (Digital Rights Management) is generally used for the purposes of content protection and unauthorized distribution of the content. A DRM-protected content is encrypted to prevent unauthorized access and piracy. The use of DRM further disallows users from sharing the content illegally.

[0003] To access a DRM-protected content, a user device needs a DRM license. This DRM license includes necessary encryption key(s) to decrypt the content and usage rights. The usage rights may include at least part of the following data:- user device information on the requesting user device,- content permission information specifying what the user can do (view, copy, etc.),- access duration defining how long the content is accessible,- geographic restrictions specifying allowed regions for access,- watermarking information about visible or invisible watermarks,- usage limits limiting the allowed views or downloads.

[0004] Users of digital content streaming services frequently encounter delays when initiating playback or when switching from one stream to another stream (e.g., from one TV channel to another TV channel), which can lead to increased wait times for users and affect the overall viewing experience. These delays are often due to security checks and user authentication processes that occur before starting the content streaming and playback.

[0005] Content delivery systems often face the challenge of reducing the time it takes for users to access streaming video content, commonly referred to aszapping time. This delay primarily arises from the requirement to perform a series of operations and checks before content playback can start on the user device. Among these preliminary steps, security checks such as Digital Rights Management (DRM) authentication process, access checking to the content based on the user's geographical location and session management are particularly time-consuming. These security checks are completed to ensure content security and compliance with distribution rights, but they contribute significantly to a latency experienced by users when attempting to access live or Video On Demand (VOD) content or switching from one streamed content to another streamed content.

[0006] Existing solutions to this problem have focused on optimizing various components involved in the content delivery process. These approaches have not adequately addressed the delay caused by the security checks.

[0007] Accordingly, there is a need for improving the situation, in particular for reducing the zapping time associated with streaming or delivering content to a user device.SUMMARY

[0008] The present disclosure concerns a method for streaming a content to a user device intended to play said content, comprising :- a step of streaming a first part of the content, followed by a step of streaming a second part of the content, wherein said first part of the content is without DRM protection and said second part of the content is DRM- protected;- a DRM authentication process for authenticating the user device and providing the user device with a DRM license for the content, carried out at least partially while streaming the first part of the content, enabling playback of the first part (i.e., the act of playing the first part) to begin before completion of the DRM authentication process, and allowing playback of the second part (i.e., the act of playing the second part) when the DRM authentication process is complete.

[0009] The second part of the content may be distinct from the first part of the content and follows said first part temporally.

[0010] The present disclosure concerns a method for delivering content to a user device, performed by a content delivery system, that significantly reduces the initial zapping time or delay associated with streaming or delivering content. The method involves delivering a first part of the content without DRM protection followed by a second part that is D RM -protected. The first part and second part of the content may be two distinct portions of the same content, the second content part following the first content part temporally. The two parts may together form the content. Concurrently, a DRM authentication process authenticates the user device and provides the user device with a DRM license for the content. This process is executed at least partially during the delivery of the first part of the content, thereby allowing content playback (i.e., the act of playing or rendering the content, for example by displaying it on a screen) to begin more rapidly than in conventional systems. The present method offer an improved user experience by minimizing the delay between content selection and playback, while still maintaining the necessary security measures to protect the content from unauthorized use.

[0011] The first part of the content may have a predetermined duration.

[0012] In an embodiment, the method may include adjusting the duration of the first part of the content using a result of analyzing collected data related to DRM license acquisition time across a plurality of devices.

[0013] In an improved embodiment, the duration of the first part of the content may be adjusted based on device attributes specific to said user device intended to playback the content.

[0014] In an embodiment, the method may comprise a step of retrieving a pre-calculated duration from a database, based on the device attributes specific to the user device intended to play the content. Said database may store a plurality of pre-calculated durations and associated device attributes.

[0015] In a particular embodiment, the method may populate said database as a result of analyzing the data related to DRM license acquisition time collected across the plurality of devices. The collected data may include time values for DRM license acquisition and associated device attributes. Analyzing the collected data may include:- classifying the devices into groups, each group being associated with a set of at least one device attribute,- calculating at least one metric representative of the time values for DRM license acquisition within each group, and deriving a duration of a first part of content for said group.

[0016] This method enables optimization of the time required for initiating content playback (i.e. , the act of playing or rendering the content, for example by displaying it on a screen integrated or connected to the user device) while maintaining content protection, potentially improving user experience by reducing waiting times and ensuring seamless transition to fully protected content.

[0017] In an embodiment, the method may comprise the steps of- generating two different, first and second, versions of the same content, each version being split into chunks, wherein the first version is in a first format without DRM protection and the second version is in a second format that is DRM-protected;- generating a combined manifest file for the content, said combined manifest file listing a combination of chunks from the second version and of chunks from the first version; and- transmitting the combined manifest file to the user device.

[0018] Advantageously, the step of generating the combined manifest file may be executed by a manifest manipulator from a first manifest file (220A) generated for the first version of the content and a second manifest file (220B) generated for the second version of the content.

[0019] The method may include generating two manifest files respectively for the two versions of the content and combining said two manifest files to generate the combined manifest file listing the combination of chunks from the first version of the content and of chunks from the second version of the content.

[0020] Advantageously, the combined manifest file allows to control switching between the two versions of the same content, more precisely from the first version to the second version of the content.

[0021] The use of a manifest manipulator facilitates generation of the combined manifest file.

[0022] In an embodiment, the step of generating the combined manifest file can be carried out just-in-time, or dynamically, as the content is requested or selected by the user device (i.e., in response to, or upon, requesting or selecting the content by the user device)

[0023] In an embodiment, the steps of creating the two versions of the content split into chunks may be carried out just-in-time, or dynamically, as the content is requested or selected by the user device (i.e., in response to, or upon, requesting or selecting the content by the user device).

[0024] In an embodiment, the method may comprise a step of providing the same content to two packagers that respectively create the two versions of the content split into chunks.

[0025] In an embodiment, the method may comprise the steps of- encrypting the first part of the content with a secret key; and- transmitting the secret key to the user device during a secure communication session with said user device.

[0026] A first data security technique designed to secure data in transit could be used to protect the secret key during its transmission to user device, wherein said first data security technique includes at least one of the techniques of obfuscation, white-box cryptography and remote attestation.

[0027] Furthermore, a second data security technique designed to secure data during storage could be used to protect the secret key during its storage in the user device, wherein said second data security technique includes at least one of the techniques of obfuscation, white-box cryptography and remote attestation.

[0028] Advantageously, the secret key may be periodically changed.

[0029] Alternatively, the secret key may a user-specific key that is specifically generated for the user or the user device, and the step of creating the first version of the content and encrypted with the secret key may be carried out just-in-time, or dynamically, as the content is requested by the user device (i.e., in response to, or upon, requesting or selecting the content by the user device).

[0030] The method may further include a step of watermarking the first part of the content.

[0031] Thus, different security measures can be applied to prevent unauthorized access, use and distribution of the first part of the content, so as to strengthen the security of the present content delivery or streaming method.

[0032] The present disclosure also concerns:- a content streaming system comprising at least one processor configured to perform the steps of the method previously defined; and- a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method previously defined.

[0033] The present disclosure further concerns a distributed system including the content streaming system as above defined and a user device comprising at least one processor configured to:- perform a DRM authentication process for authenticating with a DRM server and obtaining a DRM license for the content;- receive a secret key during a secure communication session with the content streaming system;- receive a first part of the content followed by a second part of the content, wherein said first part of the content is encrypted with the secret key and without DRM protection and said second part of the content is DRM- protected; and- decrypt only the first part of the content with the secret key.BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Other features, purposes and advantages of the disclosure will become more explicit by means of reading the detailed statement of the non- restrictive embodiments made with reference to the accompanying drawings.

[0035] FIG. 1 illustrates a block diagram of the system architecture for delivering or streaming content to a user device, according to an embodiment.

[0036] Figure 2 illustrates a flow chart diagram of a method for delivering or streaming a content to a user device according to an embodiment,

[0037] FIG. 3A / 3B illustrates a timeline diagram for two different embodiments of content streaming.

[0038] FIG. 4 illustrates a flow chart diagram of an ingestion process for preparing, packaging and uploading content to a content delivery network (CDN), according to an embodiment.

[0039] FIG. 5 illustrates a flow chart diagram of a content streaming process including user authentication, DRM license acquisition, and playback on a user device, according to an embodiment.

[0040] FIG. 6 illustrates a flow chart diagram depicting the content streaming process transitioning from a non-DRM format to a DRM-protected format, according to an embodiment.

[0041] FIG. 7 illustrates a flow chart diagram of a content streaming process including user authentication, DRM license acquisition, and playback on a user device, according to another embodiment.DETAILED DESCRIPTION

[0042] The following detailed description describes various features and functions of the disclosed systems and methods with reference to the accompanying figures. In the figures, similar symbols identify similar components, unless context dictates otherwise. The illustrative system, device and method embodiments described herein are not meant to be limiting. It may be readily understood by those skilled in the art that certain aspects of the disclosed systems, devices and methods can be arranged and combined in a wide variety of different configurations, all of which are contemplated herein.

[0043] One of the challenges faced by content streaming systems is the lengthy zapping time, which refers to the delay users experience when accessing a content and starting its playback (i.e., the act of playing or rendering the content) on a user device. This delay is primarily caused by the need to perform various security checks before distribution and playback of the content can begin. While these security checks are necessary to ensure content security and compliance with distribution rights, they significantly contribute to a latency users encounter when trying to access a content and / or switch from one content to another content, for example when using live or Video On Demand (VOD) content distribution services.

[0044] Existing solutions have focused on optimizing different components of the content streaming process but have not effectively addressed the problem of reducing the lengthy zapping time caused by security checks. Currently, a complete DRM handshake and other security verifications must be completed before video playback can start, resulting in noticeable lag thatcan negatively impact the user experience, especially in situations where quick access to the content is crucial.

[0045] The present disclosure concerns an innovative method and system for streaming content to a user device that significantly reduces the zapping time associated with content streaming (i.e., the initial time when accessing a content before content playback can begin). The method involves streaming an initial or first portion of the content without DRM protection, followed by a second portion that is DRM -protected. Simultaneously, a DRM authentication process authenticates the user device and provides it with a DRM license for the content. This DRM authentication process is partially executed during the streaming of the first portion of the content, enabling faster video playback compared to conventional systems. The second portion of the content may be distinct from the first portion of the content and follow it temporally. The two parts may together form the content. This approach enhances the user experience by minimizing the delay between content selection and playback- i.e., the time between selecting content and viewing it on a screen included in or connected to the user device while maintaining the necessary security measures to prevent unauthorized use of the content.

[0046] First Embodiment

[0047] FIG. 1 shows a content delivery or streaming system 600, a content source 100 for providing digital contents to the system 600, and a user device 700 configured to use a content delivery or streaming service provided by the system 600, according to a first embodiment.

[0048] The content streaming system 600 has different components that may include:- two packagers 200A, 200B;- a manifest manipulator 300;- a content delivery network (CDN) 400; and- a content management and delivery platform 500.

[0049] The platform 500, for example a digital experience platform (DXP), has content management and delivery capabilities. It manages access and entitlements to contents. The components of the platform 500 may include a content management system (CMS) and one or more DRM servers. The platform 50 may have a front-end system that provides a user interface for browsing, selecting, and playing contents. This front-end system may be part of the CMS.

[0050] The platform 500 may be responsible for initiating a DRM handshake, also referred as a DRM authentication process or a DRM license acquisition process, and ensuring that the user device 700 is authorized to access the content, as will be described later in more detail in the description of the method.

[0051] Optionally, the platform 500 may include other components such as a personalization engine responsible for adapting experiences based on user data, an integration layer for connecting with other systems (Customer Relationship Management (CRM) system, eCommerce, etc.), and / or analytics and reporting tools to measure and optimize performance. These components will not be described in detail in the present description.

[0052] The content source 100 serves as an origin of contents. The content source 100 is responsible for providing contents to the two distinct packagers 200A, 200B. Optionally, the content source 100 may optionally prepare, or pre-process, the digital contents by transcoding them into a fragmented format, for example fMP4 (fragmented MP4). A plurality of content sources may be provided to provide contents to the system 600.

[0053] The packagers 200A, 200B have the role of preparing the contents for delivery through the CDN 400. The preparation of a content for delivery through the CDN 400 includes breaking or splitting or fragmenting the content into smaller content segments, or chunks, for smoother streaming, and generating a manifest file, or manifest, listing the content segments for streaming.

[0054] The two packagers 200A, 200B are configured to generate two different versions of the same content split or fragmented into chunks or segments, respectively in a first format 210A and in a second format 21 OB. The first format 210A may be without DRM protection, while the second format 21 OB may be a DRM-protected format. The content segments in the first format and the content segments in the second format represent segments of the same content that are prepared for streaming to the user device 700.

[0055] Furthermore, the two packagers 200A, 200B are configured to respectively generate two different manifest files, respectively first and second manifests 220A, 220B. The first manifest file 220A lists the content segments or chunks in the first format without DRM protection, while the second manifest file 220B lists the content segments or chunks in the second format DRM-protected. The manifest files 220A, 220B also contain metadata about the content segments 210A, 210B, including information such as sequence numbers, durations, and resource locators like URLs for accessing the content segments.

[0056] The packager 200B has also a role of protecting the content using DRM. For that purpose, the packager 200B is configured to encrypt the content segments with at least one encryption key received upon request from the DRM server of the platform 500, to ensure that the content segments of the second version of the content 210B can only be decrypted by authorized users with the correct key(s). Furthermore, the packager 200B is configured to embed DRM-related metadata, such as key IDs and license resource locators like URLs, into the corresponding manifest file 220B. This DRM-related metadata is necessary for the user device 700 to request the correct DRM license from the DRM server.

[0057] It should be noted that the packager 200A that prepares the content segments in the first format does not encrypt the content segments with encryption key(s) received from a DRM server, so that access and playbackof the first version of the content (i.e. , content segments in the first format) by a user device - and therefore viewing the first version of the content - does not require a DRM license. However, in an embodiment, the packager 200A may be configured to encrypt the content segments with an encryption key, advantageously a secret or symmetric key (e.g., an AES key), that may be directly transmitted by the platform 500 to the user device without requiring a DRM license, as will be described later in more detail in the second embodiment.

[0058] The manifest manipulator 300 is a component that can modify manifest files that list the available content segments or chunks and optionally qualities of a content stream. This component 300 is configured to take the two manifest files 220A, 220B respectively from the two packagers 200A, 200B and to generate a combination of these manifest files. In the present disclosure, the manifest manipulator 300 is configured to combine the manifest files 220A, 220B so as to control switching between the two versions of the same content respectively in the first format and in the second format. More precisely, the manifest manipulator 300 is adapted to manipulate the first manifest file 220A and the second manifest file 220B and combine them to ensure that the content streaming or delivery starts with a first part of the content without DRM protection, followed by a second part of the content that is DRM-protected. For example, the manifest manipulator 300 can modify the second manifest file 220B listing the DRM-protected content segments, by using the first manifest file 220A listing the content segments without DRM protection (e.g., it can replace the content segments listed at the beginning of the second manifest file 220B by the corresponding content segments listed at the beginning of the first manifest file 220A). In another embodiment, the manifest manipulator 300 may be configured to modify the first manifest file 220A listing the content segments without DRM protection, by using the second manifest file 220B listing the DRM-protected content segments, in aa analogous way.

[0059] The content delivery network (CDN) 400 is responsible for distributing contents to user devices. The CDN 400 is an infrastructure that supports the delivery of contents across digital channels. The CDN 400 can distribute contents across a network of servers that are geographically distributed to ensure that the content is delivered efficiently and with high availability.

[0060] The user device 700 may be a smartphone, TV set, computer, tablet, or any other computing device. It is the endpoint of the content delivery system 600. The user device 700 has communication capabilities through any suitable communication channel. It can connect to the platform 500 and the CDN 400 over one or more network(s), including but not limited to, the Internet, local area networks (LAN), wide area networks (WAN), cellular networks (e.g., 4G, 5G), and Wi-Fi networks. The user device 700 may be configured to interact with the platform 500 to authenticate and obtain access to a content, and with the CDN 400 to receive a manifest file and the content segments for playback.

[0061] A method for delivering a specific content, referred as “CT”, to the user device 700 will now be described according to an embodiment. This method can be carried out by the system 600.

[0062] The method for delivering the content CT to the user device 700 may include a content ingestion process 800 and a content streaming workflow or process 900, as shown in figure 2.

[0063] The ingestion process 800 may include preparing, packaging and uploading the content CT to the CDN 400, making it ready for delivery to one or more user devices.

[0064] The content streaming workflow 900 may include user authentication, content browsing and selection, DRM license acquisition, CDN content requests, content delivery and content playback, ensuring a secure and smooth streaming experience for the user.

[0065] Figure 4 illustrates the ingestion process 800, according to an embodiment. This process 800 comprises a step 810 of content provisioning in which the content CT is sent by the content source 100 to the system 600. This content provisioning step 810 can be performed well in advance. The content provisioning step 810 may include providing the same content CT to the first packager 200A and second packager 200B. The provided content CT can be in a raw format. Alternatively, it can be in a fragmented format, for example fMP4 (fragmented MPP4), to facilitate its packaging by the packagers 200A, 200B.

[0066] The ingestion process 800 may further include a step 820 and a step 830 for preparing two different versions of the same content CT, respectively in a first format and in a second format. The first format may be without DRM protection, while the second format may be a DRM -protected format.

[0067] In the step 820, the first packager 200A prepares a first version of the content CT in the first format (without DRM protection) for delivery through the CDN 400. The preparation of the content CT includes breaking or fragmenting the content CT into smaller content segments, or chunks, 210A and generating a manifest file 220A listing the content segments in the first format for streaming. The manifest file 220A further includes metadata about the content segments 210A in the first format including information such as sequence numbers, durations, and resource locators like URLs for accessing the content segments in the first format.

[0068] In the step 830, the second packager 200B also prepares a second version of the content CT in the second format DRM-protected for delivery through the CDN 400. The preparation of the second version of the content CT may include:- breaking or fragmenting the content CT into smaller content segments, or chunks, 210B,- encrypting the content segments with one or more encryption key(s) obtained upon request from the DRM server of the platform 500, and- generating a manifest file 220B listing the content segments in the second format for streaming.

[0069] The manifest file 220B further includes:- metadata about the content segments 21 OB in the second format including information such as sequence numbers, durations, and resource locators like URLs for accessing the content segments in the second format;- DRM-related metadata, such as key ID(s) and license resource locators like URL(s), for acquiring a DRM license necessary to decrypt the content segments 21 OB in the second format.

[0070] The steps 820, 830 can be carried out in parallel. Alternatively, these steps could be executed sequentially.

[0071] In a variant, the two packagers 200A, 200B may be replaced by one single packager configured to generate the two different versions of the content CT, respectively in the first format and in the second format.

[0072] In a step 860, the content segments 210A in the first format without DRM protection and the content segments 210B in the second format DRM- protected are uploaded or transmitted from the packagers 200A, 200B to the CDN 400.

[0073] The ingestion process 800 further includes a step 840 of generating a combined manifest file 220C, based on the two manifest files 220A, 220B. This combined manifest file 220C is adapted to control switching from the first version of the content CT without DRM protection (i.e., from the content segments without DRM protection) to the second version of the content CT that is DRM-protected (i.e., from the DRM-protected content segments), as will be described later.

[0074] The step 840 of generating the combined manifest file 220C may be carried out just-in-time, or dynamically, as the content CT is requested or selected by the user device 700 (i.e., in response to, or upon, requesting or selecting the content CT by the user device 700). In other words, the step840 may be executed in real time as the user device 700 requests the content CT, just before the content CT is delivered to the user device 700, not in advance. Executing the step 840 just-in-time as the content CT is requested or selected by the user device 700 (i.e., in response to, or upon, requesting or selecting the content CT by the user device 700) allows to dynamically adapt the combined manifest file 220C to what is requested by the user device 400 and / or the moment it is requested. This is particularly useful when the user device 400 wants to switch from one stream to another stream, for example from one TV channel to another TV channel.

[0075] However, in another embodiment, the combined manifest file 220C could be generated in advance before the user device 700 requests the content CT.

[0076] The steps of packaging 820, 830 could be executed just-in-time or dynamically as the content CT is requested or selected by the user device 700 (i.e., in response to, or upon, requesting or selecting the content CT by the user device 700), or in advance before the user device 700 requests the content CT.

[0077] In a step 850, the combined manifest file 220C is uploaded or transmitted to the CDN 400.

[0078] Figures 5 and 3A illustrate the content streaming workflow or process 900 for streaming and playing back the content CT on the user device 700, according to an embodiment.

[0079] The process 900 may include a user authentication step 910, a step 920 of content selection and data provisioning, a step 930 of manifest acquisition, a step 940 of DRM license acquisition, a step 950 of content streaming or delivery, and a step 960 of content playback.

[0080] In the user authentication step 910, the user device 700 authenticates with the platform 500, for example the Digital Experience Platform (DXP), to verify the user’s identity and access rights. For example, the user device 700may initiate a login request by providing user credentials (e.g., username / email and password) to the platform 500, and the platform 500 may verify the provided credentials against a user database or an external authentication service. Optionally, a multi-factor authentication process may be applied. Upon successful authentication, the platform 500 may create a secure communication session with the user device 700. The platform 500 may issue an access token (JWT or similar) to the user’s device 700, for subsequent requests to verify the user’s identity and access rights.

[0081] In the step 920, the user device 700 may browse an available content catalog provided by the platform 500 through its user interface, and select the desired content, here the content CT, for streaming (i.e., for delivery). Upon selection of the content CT, the platform 500 may provide the user device 700 with one or more resource locators, such as URLs, to access the content hosted on the CDN 400. In an embodiment, the platform 500 provides the user device 700 with a resource locator like an URL to the combined manifest file 220C. For security reasons, the URLs may be signed and / or CDN tokens may be provided by the platform 500 so as to ensure that only authorized user devices can access the content on the CDN 400. In this way, access to the CDN may be controlled via signed URLs or CDN-specific tokens.

[0082] In a step 930, the combined manifest file 220C is delivered to the user device 700. In an embodiment, the user device 700 may request the combined manifest file 220C to the CDN 400 using the URL provided by the platform 500. Any other mechanism for delivering the combined manifest file 220C to the user device 700 may be used. For example, the manifest 220C may be directly provided by the platform 500 to the user device 700.

[0083] As previously described, the combined manifest file 220C may contain DRM-related metadata for acquiring a DRM license for the content CT and resource locators like URLs pointing to segments of the content CT.

[0084] In a step 950, the user device 700 requests content segments to the CDN 400 from the URLs specified in the combined manifest file 220C.

[0085] With reference to figure 6, the combined manifest file 220C controls a process of delivering or streaming the requested content CT to the user device 700 that includes:- 950A: streaming a first or initial part CT1 of the content CT in the first format without DRM protection, said first or initial part CT1 including content segments in the first format without DRM protection;- 950B followed by streaming a second part CT2 of the content CT that is DRM-protected format, said second part CT2 including content segments in the second DRM-protected format.

[0086] In other words, the delivery or streaming of the content CT to the user device 700 starts by delivering the first part of the content CT 1 without DRM protection (i.e., without DRM encryption) in step 950A, followed by delivering the second part of the content CT2 that is DRM-protected in step 950B.The first part CT1 and second part CT2 of the content CT may be distinct portions of the same content CT. The second portion CT2 of the content may follow the first portion of the content CT1 temporally. Both portions CT1 , CT2 may together form the content CT.

[0087] As the content segments 210A of the first part CT1 and the content segments 210B of the second part CT2 are being downloaded in the successive steps 950A, 950B, the user device 700 executes a content playback, or playing, or rendering, step 960 in which these downloaded content segments 210A, 210B are played or rendered by the user device 700 and can be viewed (and / or listened) by a user, as will be described later in more detail.

[0088] From the combined manifest file 220C, the user device 700 further carries out a process of DRM authentication, also called a DRM license acquisition process 940. For that purpose, the user device 700 may parse the combined manifest file 220C, extract the DRM-related information, and connect to the DRM license server (e.g., within the platform 500) using alicense acquisition URL provided in the manifest file 220C to carry out the DRM license acquisition process 940.

[0089] The DRM license acquisition process 940 includes security checks to ensure that the content CT is only accessible to authorized users and that it is protected from unauthorized distribution or usage. This DRM license acquisition process 940 is well-known by the person skilled in the art. It may involve the steps, performed by the DRM server, of:- receiving, from the user device 700, a DRM license request including user and content information;- authenticating or verifying the identity of the user to ensure the user has the right to access the requested content, here CT (for example, the DRM license request may contain a token or authentication information to authenticate the user and / or user device),- checking if the user has the appropriate permissions or entitlements to access the requested content CT,- if the user has been authenticated with the appropriate entitlements (i.e., if the step of authenticating the user and the step of verifying if the user has the appropriate entitlements have been successful), generating or creating a DRM license that contains the necessary decryption key(s) and usage rights to decrypt and use the content,- securely transmitting the DRM license to the user device 700.

[0090] The user device 700 stores the DRM license securely and can use it to decrypt and access the requested content CT.

[0091] The "entitlements" refer to the rights and permissions for example associated with a user's account that determine whether the user is authorized to access specific content. The verification of the user’s entitlements performed by the DRM server may include for example :- verification of an active subscription that includes access to the selected content;- confirmation that the user has purchased or rented the content;- determination of the user's access level or tier, which may grant permissions to certain types of content; and / or- ensuring the user is accessing content from a location where it is licensed for distribution.

[0092] The DRM server checks these entitlements to decide if the user is allowed to receive a license for the requested content.

[0093] Playback 960A of the first part of the content CT1 (i.e., the content segments without DRM protection) can start and execute without delay after delivery of the combined manifest file 220C. This is because playback of the first part of the content CT1 - i.e., the act of playing or rendering the first part of the content CT1 (when CT1 can be viewed by a user) - does not require to acquire and use a DRM license to play the content segments 210A that are without DRM protection. As a result, the first part of the content CT1 can be viewed without delay.

[0094] The DRM authentication process 940, also called DRM license acquisition process, is carried out at least partially while delivering or streaming the first part of the content CT1. Consequently, the DRM license acquisition process 940 can be carried out at least partially while the first part of the content CT1 (i.e., the content segments without DRM protection) is played or rendered on the user device 700 (and can thus be viewed by a user). In an embodiment, the DRM authentication process 940 may start as soon as the combined manifest file 220C has been received. Advantageously, the DRM authentication process 940 may be completed before streaming or delivering the second part of the content CT2. Alternatively, the DRM authentication process 940 could start while delivering the first part of the content CT1 and be completed while beginning the streaming of the second part of the content CT2.

[0095] Playback 960B of the second part of the content CT2 - i.e., the act of playing or rendering the second part of the content CT2 (when CT2 can be viewed by a user) - follows playback 960A of the first part of the content CT1 .The switching between the act of playing the first part CT1 and the act of playing the second part CT2 is controlled by the combined manifest file 220C. The user device 700 uses the key(s) from the DRM license acquired in the step 940 to decrypt the second part of the content CT2 that is DRM -protected (i.e., the DRM-protected content segments). This ensures that the content CT, or at least the second part CT2, can be viewed or used only on an authorized device and according to the specified usage rights.

[0096] The first part of the content CT1 may have a predetermined duration. This predetermined duration may be adjusted based on an expected duration to achieve the DRM authentication process 940. This expected duration could be predetermined for example based on historical data. For example, the predetermined duration of CT1 may be comprised between 1 second and 20 seconds, for example between 2 seconds and 10 seconds. However, this range may depend on the system configuration.

[0097] In an embodiment, the duration of the first part of the content CT1 played or rendered by the user device 700 may be adjusted using a result of analyzing collected data related to DRM license acquisition time across a plurality of devices. For example, the duration of the first part of the content CT1 may be adjusted based on a statistical analysis of the collected data from the plurality of devices.

[0098] The system may collect data related to DRM license acquisition time across a plurality of devices, for example across all devices in the system 600 - or across a subgroup of them - when they perform DRM authentication (i.e., DRM license acquisition), storing the collected data in a big database such as a data warehouse. Then, the collected data can be aggregated and analyzed, for example statistically, to determine at least one metric representative of DRM license acquisition time values (i.e., how long it takes to acquire a DRM license) collected from the devices. This metric may include an average DRM license acquisition time. It may further include a minimum DRM license acquisition time, a maximum DRM license acquisition time, and / or any otherrelevant data representative of the collected DRM license acquisition time values.

[0099] The system can then determine an optimal duration for a first part of content to be streamed based on the determined metric(s) (e.g., the average DRM license acquisition time). For example, this optimal duration may be equal to the average DRM license acquisition time increased by a predetermined amount of time.

[0100] The data analysis and determination of the optimal duration of the first part of content may be performed by the content delivery system 600. Alternatively, it could be performed by another dedicated computing device or system.

[0101] In an improved embodiment, the duration of the first part of the content requested by the user device 700 may be adjusted based on device attributes specific to this user device 700.

[0102] In this embodiment, the collected data related to DRM license acquisition time across a plurality of devices not only includes DRM license acquisition time values but also device attributes (i.e., device parameters or device metadata) related to the devices, such as device type, model, year of manufacture, network connection type, geographical location, or any other attribute that may impact (i.e., considered as a factor in) the DRM license acquisition time. The system 600 may then:- classify the devices into groups, each group being associated with a different set of one or more device attributes,- calculate at least one metric representative of the time values for DRM license acquisition within each group, (i.e., for each group or each set of attribute(s)), and derive, from the calculated metric(s), an optimal duration of a first part of content for said group.

[0103] In this way, the system can determine a plurality of durations of first part of content, each associated with a different set of device attributes (orgroup), and store the durations and associated sets of device attributes in the database.

[0104] For example, the system may determine that a TV device model released in 2021 by a manufacturer A requires an average of 7 seconds to complete the DRM authentication process, whereas a 2025 model from the same manufacturer A completes the process in just 2 seconds.

[0105] When the user device 700 requests or selects the content CT in step 920, the system 600 may determine device attributes specific to that user device 700. For example, these attributes may include the device type, model, operating system version, network connection type, geographical location, etc. The system then uses these attributes to adjust the duration of the first part CT1 of the requested content CT for that specific device 700. For that purpose, it may retrieve from the database a pre-calculated duration, using the device attributes specific to the user device 700, for example by matching this set of specific device attributes with one set of device attributes in the database. In this way, the set of device attributes specific to the user device 700 is used as a dynamic input data in the adaptation or adjustment of duration of the first part of the content CT 1 . The system can thus dynamically adjust the duration of the first part CT1 of the requested content CT based on the device attributes of the requesting device 700.

[0106] As above described, the system may pre-calculate durations for various sets of device attributes based on the analyzed data. These precalculated durations are stored in the database, along with their associated device attributes. When the user device 700 requests content, the system retrieves the appropriate pre-calculated duration by matching the device's attributes with those stored in the database. This approach allows the system to optimize performance and reduce computational overhead.

[0107] Alternatively, the optimal duration of a requested content may be calculated in real time.

[0108] If no exact match is found for the attributes of the requesting user device 700, a default duration can be used.

[0109] The system can continuously update the database of durations and associated device attributes as it gathers more data from devices accessing content. It may perform batch processing of the collected data, for example, once or several times a day, to recalculate and update the optimal durations for different device attribute combinations. This approach allows the system to adapt to changing conditions and improvements in device performance over time, ensuring that the duration of the first part of a requested content is always optimized for the best user experience while maintaining security.

[0110] Optionally, the method may use a feedback loop to adjust the durations based on error ratio. This error ratio can be computed by the system based on error messages or data received from devices. As used herein, the term "error ratio" represents the proportion of user devices that fail to complete the DRM authentication or DRM license acquisition process within the allotted time for the first part of the content, resulting in playback errors. The error ratio is typically expressed as a percentage and is used by the system to determine if adjustments to the duration of the first part of the content are necessary to optimize the user experience while maintaining content security. For example, if the duration of the first part of the content is too short, the user device does not obtain the license in time and generates an error message. Based on a statistical analysis of the error messages received from the devices, the system may determine whether or not the precalculated duration(s) of the first part of content are too short and should be adjusted. For example, it may calculate an error ratio across devices within a given group of devices associated with a given set of device attributes and compare it to a tolerance threshold. If the calculated error ratio exceeds this tolerance threshold, it is determined that the duration of the first part of content is too short on that group of devices and should be increased by an adjustment value. For example, it may be acceptable to have up to 2% oferrors. If the error ratio exceeds 2%, the duration associated with that group may be increased.

[0111] The system may use an algorithmic approach and / or train a classifier using machine learning to adapt the duration of the first part of the content based on collected data related to DRM license acquisition times.

[0112] The present method for delivering the content CT to the user device 700 involves delivering the first part of the content CT1 that is without DRM protection and can be played or rendered by the user device 700 without delay and, concurrently, executing the DRM license acquisition process 940 that can be completed before streaming the second part of the content CT2 or (optionally) while streaming of this second part of the content CT2 begins. Thanks to that, the present method for delivering content to a user device significantly reduces the initial zapping time associated with streaming or delivering content. By delivering the first part of the content CT1 without DRM protection followed by the second part CT2 that is DRM-protected, the method allows content playback (i.e., the act of viewing, playing or rendering the content) to begin more rapidly than in conventional systems. The DRM authentication process, which authenticates the user device 700 and provides the user device 700 with a DRM license for the content CT, is executed at least partially during the delivery of the first part of the content CT1. This approach minimizes the delay between content selection and playback (i.e., the act of viewing, playing or rendering the content) and thus improves the user experience, while still maintaining the necessary security measures to protect the content from unauthorized use.

[0113] Second Embodiment

[0114] The second embodiment is illustrated in figures 7 and 3B. It is based on the first embodiment and only differs from it by the features described below.

[0115] In the second embodiment, the first part of the content CT1 is encrypted with at least one encryption key k so that, in the step of streaming950A, the streamed content segments of the first part of the content CT1 are encrypted with this key k. The first part of the content CT1 encrypted with the key k is noted [CT1]k. For example, the key k is a secret or symmetrical key such as an AES key. The encryption of the content segments of the first part of the content [CT1]k can be carried out by the packager 200A when packaging the content CT in the step 820.

[0116] The key k can be shared by the packager 200A and the platform 500.

[0117] Figure 7 illustrates the process or workflow 900’ of content streaming or delivery according to the second embodiment. This workflow is similar to the workflow according to the first embodiment, but differs from it in that it includes a step 925 of delivering the secret key k to the user device 700. In the step 925, the key k can be securely transmitted by the platform 500 to the user device 700 for example during the secure communication session with the user device 700 in the step 920 of content selection and data provisioning.

[0118] In this second embodiment, the first part of the content [CT1]k delivered or streamed to the user device 700 in the step 950A is encrypted with the key k, but is still without DRM protection.

[0119] In the step 960A of playing back the first part of the content CT1 , the content segments of [CT 1 ]k are decrypted with the key k by the user device 700. This can be performed without delay, as the acquisition of the key k does not require executing time-consuming security checks.

[0120] The key k could be periodically changed by the system 600 to improve security.

[0121] The same key k could be used for different user devices and / or users. Alternatively, the key k can be a user-specific key or a user device-specific key, specifically generated, for example by the platform 500, for the user or for the user device 700. In that case, the step 820 of creating the version of the content CT without DRM protection but encrypted with the key k may becarried out just-in-time as the content CT is requested or selected by the user device 700 (i.e., in real time, as the user device 700 requests or selects the content CT - in response to, or upon, requesting or selecting the content by the user device - not in advance).

[0122] In a variant, a data security technique designed to secure data in transit and / or storage may be used to protect the encryption key k during its transmission to the user device 700 and / or its storage in the user device 700. Thus, the encryption key may be secured for its transmission to and / or storage in the user device 700 by obfuscation, white-box cryptography, remote attestation, and / or any other appropriate technology designed to secure data in transit and / or storage.

[0123] In another embodiment, the first part of the content CT1 or [CT1]k may be watermarked for the purpose of identifying the source of an unauthorized distribution.

[0124] The method including the processes 800 and 900 or 900’ may include one or more operations, functions, or actions as illustrated by one or more of blocks 810-860 and 910-960. Although the blocks are illustrated in a sequential order, these blocks may in some instances be performed in parallel, and / or in a different order than those described herein. Also, the various blocks may be combined into fewer blocks, divided into additional blocks, and / or removed based upon the desired implementation.

[0125] In addition, for the method including the processes 800 and 900 and other processes and methods disclosed herein, the flowchart shows functionality and operation of one possible implementation of present embodiments. In this regard, each block may represent a module, a segment, a portion of a manufacturing or operation process, or a portion of program code, which includes one or more instructions executable by a processor for implementing specific logical functions or steps in the process. The program code may be stored on any type of computer readable medium, for example, such as a storage device including a disk or hard drive. The computerreadable medium may include non-transitory computer readable medium, for example, such as computer-readable media that stores data for short periods of time like register memory, processor cache and Random Access Memory (RAM). The computer readable medium may also include non-transitory media, such as secondary or persistent long-term storage, like read only memory (ROM), optical or magnetic disks, compact-disc read only memory (CD-ROM), for example. The computer readable media may also be any other volatile or non-volatile storage systems. The computer readable medium may be considered a computer readable storage medium, for example, or a tangible storage device.

[0126] FINAL CONSIDERATIONS

[0127] Although an overview of the inventive subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of embodiments of the present invention. For example, various embodiments of features thereof may be mixed and matched or made optional by a person of ordinary skill in the art. Therefore, the Detailed Description is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Claims

CLAIMS1. A method for streaming a content to a user device (700) intended to play said content, comprising :- a step of streaming (950A) a first part of the content, followed by a step of streaming (950B) a second part of the content, wherein said first part of the content is without DRM protection and said second part of the content is DRM-protected;- a DRM authentication process (940) for authenticating the user device (700) and providing the user device with a DRM license for the content, carried out at least partially while streaming the first part of the content, enabling playback of the first part to begin before completion of the DRM authentication process (940), and allowing playback of the second part when the DRM authentication process is complete (940).

2.

2. The method according to claim 1 , wherein the second part of the content is distinct from the first part of the content and follows said first part temporally.

3. The method according to claim 1 or 2, wherein the first part of the content has a predetermined duration.

4. The method according to claim 1 or 2, comprising a step of adjusting the duration of the first part of the content using a result of analyzing data related to DRM license acquisition time collected across a plurality of devices.

5. The method according to claim 4, wherein the duration of the first part of the content is adjusted based on device attributes specific to the user device (700) intended to play the content.

6. The method according to claim 5, comprising a step of retrieving a precalculated duration from a database, based on the device attributes specific to the user device (700) intended to play the content, wherein said database stores a plurality of pre-calculated durations and associated device attributes.

7. The method according to claim 6, further comprising populating said database as a result of analyzing the data related to DRM license acquisition time collected across the plurality of devices, wherein the collected data includes time values for DRM license acquisition and associated device attributes, and analyzing the collected data includes classifying the devices intro groups, each group being associated with a set of at least one device attribute, calculating at least one metric representative of the time values for DRM license acquisition within each group, and deriving a duration of a first part of content for said group.

8. The method according to any of claims 1 to 7, comprising the steps of- generating (820, 830) two different, first and second, versions of the same content, each version being split into chunks, , wherein the first version is in a first format without DRM protection and the second version is in a second format that is DRM-protected;- generating (840) a combined manifest file (220C), said combined manifest file (220C) listing a combination of chunks from the second version of the content and of chunks from the first version of the content;- transmitting (850, 930) the combined manifest file (220C) to the user device (700).

9. The method according to claim 8, wherein the step (840) of generating the combined manifest file (220C) is executed by a manifest manipulator (300) from a first manifest file (220A) generated for the first version of the content and a second manifest file (220B) generated for the second version of the content .

10. The method according to any of claims 8 and 9, wherein the step (840) of generating the combined manifest file (220C) is carried out dynamically as the content is requested by the user device (700).11 . The method according to any of claims 8 to 10, wherein the steps (820, 830) of creating the two versions of the content split into chunks are carried out dynamically as the content is requested by the user device (700).

12. The method according to any of claims 8 to 11 , comprising a step of providing the content to two packagers (200A, 200B) that respectively create the two versions of the content split into chunks.

13. The method according to any of claims 1 to 12, comprising the steps of- encrypting the first part of the content with a secret key; and- transmitting (925) the secret key to the user device (700) during a secure communication session with said user device (700).

14. The method according to claim 13, wherein a first data security technique designed to secure data in transit is used to protect the secret key during its transmission to user device, wherein said first data security technique includes at least one of the techniques of obfuscation, white-box cryptography and remote attestation.

15. The method according to claim 13 or 14, wherein a second data security technique designed to secure data during storage is used to protect the secret key during its storage in the user device, wherein said second data security technique includes at least one of the techniques of obfuscation, white-box cryptography and remote attestation.

16. The method according to any of claims 13 to 15, wherein the secret key is periodically changed.

17. The method according to claim 13 or 15, when dependent on any of claims 8 to 12, wherein- the secret key is a user-specific key that is specifically generated for the user or the user device;- the step of creating the first version of the content encrypted with the secret key is carried out dynamically as the content is requested by the user device.

18. The method according to any of claims 1 to 17, comprising a step of watermarking the first part of the content.

19. The method according to any of claims 1 to 18, wherein the DRM authentication process (940) includes the steps, performed by a DRM server, of:- receiving, from the user device, a DRM license request including user and content information ;- authenticating the user and verifying if the user has appropriate entitlements to access the content;- generating a DRM license containing at least one key and usage rights to decrypt and use the requested content;- transmitting the DRM license to the user device.

20. A content streaming system (600) comprising at least one processor configured to perform the steps of the method according to any of claims 1 to 19.21 . A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method according to any of claims 1 to 19.

22. A distributed system including the content streaming system (600) according to claim 20 and at least one user device (700), said user device (700) comprising at least one processor configured to:- perform a DRM authentication process for authenticating with a DRM server and obtaining a DRM license for the content;- receive a secret key during a secure communication session with the content streaming system;- receive a first part of the content followed by a second part of the content, wherein said first part of the content is encrypted with the secret key and without DRM protection and said second part of the content is DRM- protected; and- decrypt only the first part of the content with the secret key.

Images