Method for receiving content on a user's device via cdn

Description

1 / 43 METHOD FOR RECEIVING CONTENT ON A USER'S DEVICE VIA CDN FIELD OF TECHNIQUE

[001] The present invention relates to the field of streaming or transmitting digital content through a content delivery network. BACKGROUND

[002] Many over-the-top (OTT) media service providers that offer digital content streaming services directly to end users via the Internet are using a content delivery network (CDN) to enable the delivery of digital content to end users.

[003] To prevent unauthorized user devices from accessing content, a CDN access token can be generated by the service provider, transmitted to the authorized user device, and then used by the authorized user device to request the content from the content delivery network.

[004] A key issue with CDN access tokens is that authorized user devices can share them with unauthorized user devices, allowing unauthorized user devices to use the service provider's CDN without valid authorization.

[005] To solve this problem, a known solution involves linking CDN access tokens to the IP addresses of the user's devices. However, this solution is not appropriate, for example, if the user's device is moving from a Wi-Fi network to a mobile network. In such a situation, the user's device's IP address may change, which can result in an interruption in the content streaming session through the CDN and, consequently, a poor user experience. In practice, this solution Petition 870250086872, dated 09 / 25 / 2025, pp. 61 / 110 2 / 43 ção is rarely used by service providers.

[006] The problem of illegal sharing of CDN access tokens has existed for years, but until recently it was considered a minor problem because access to and use of content is generally protected by another layer of authorization based on Digital Rights Management (DRM). The content can be encrypted, and the decryption key is embedded and protected in a DRM license that is transmitted to the user's device. The DRM license may also include usage rules to restrict the use of the content. However, some DRM licenses have been hacked recently. For example, a hacker can subscribe to a content streaming service from a legitimate service provider, posing as a legitimate user, request content, and obtain a DRM license for the requested content.The hacker exploits a weakness in the DRM license to extract the decryption key from the DRM license, decrypt that decryption key, and share it with multiple users to allow them to access content through the content delivery network without subscribing to the legitimate service provider. A pirate content server or portal can grant access to multiple content items to illegitimate users by subscribing to the pirate service, sharing the DRM keys to decrypt the content. Illegitimate users can set up content streaming sessions with the legitimate service provider's content delivery network, receive encrypted content segments, and decrypt them with the DRM key provided by the pirate service portal. Users of the pirate service do not need to subscribe to the legitimate service provider's content streaming service and generate an additional network load for the content delivery network.

[007] Due to recent hacking problems related Petition 870250086872, dated 09 / 25 / 2025, page 62 / 110 3 / 43 of the DRM licenses, the problem of unauthorized users accessing content through a content delivery network has become a major issue.

[008] Therefore, there is a need to improve this situation. In particular, it is desired to prevent unauthorized users from accessing content through a content delivery network, CDN. SUMMARY

[009] The present invention relates to a method for receiving content on a user device, comprising the steps, performed by the user device, of: Send an access request to access content from a content provider's system; to receive, from the content provider's system, an access token for said content, said access token including an encrypted session key and a digital rights management (DRM) license, including said session key; and to transmit a content request including the received access token to a content delivery network and, in response, receive from the content delivery network's content data the requested content, in a communication session; The content request additionally includes an authentication tag obtained by performing a cryptographic operation, executed by a DRM client module on the user's device, to sign and / or encrypt, using the received DRM license session key, input data that is based on at least part of the content request.

[0010] According to the present invention, the DRM technique is used to link the access token to the device. The authentication tag is generated by a DRM client module of the user device based on the DRM license that incorporates the session key and Petition 870250086872, dated 09 / 25 / 2025, page 63 / 110 4 / 43 allows proof that the user device has access to the session key, the CDN. Furthermore, the user device is acting as a relay to transmit to the CDN the encrypted session key embedded within the access token received from the content provider's system.

[0011] In one embodiment, the cryptographic operation is used to: - sign, with the session key, at least part of the content request; and - Encrypt, using the session key, a hash value of at least part of the content request.

[0012] Thus, the user device's DRM client module can sign the content request, or a portion of the content request, or a concatenation of different elements of the content request, with the session key. Alternatively or additionally, the user device's DRM client module can encrypt a hash value of the content request, or a portion of the content request, or a concatenation of different elements of the content request, with the session key. The signed and / or encrypted hash value allows the user device to prove to the CDN that it has access to the session key. This access to the session key is protected by DRM.

[0013] In one embodiment, the access request includes DRM license dispute data. Advantageously, said DRM license dispute data includes only user data, for example, user device identification information (e.g., a user device identifier or DID (unique identifier) ​​of the user device). Advantageously, the DRM license dispute data included in the access request to access the content is not specific to the content or any content. It does not include content information. Petition 870250086872, dated 09 / 25 / 2025, page 64 / 110 5 / 43

[0014] The present invention also relates to a method, implemented by a content provider system, comprising the steps of: - Receive an access request to access content from a user's device; - Generate a session key for a communication session to receive the requested content on the user's device via a content delivery network. - generate an access token including the aforementioned session key in encrypted form; - to generate, through a DRM license server, a DRM license including said session key; and - transmit the access token and DRM license to the user's device.

[0015] The content provider's system generates a session key for a communication session between the CDN and the user's device to deliver content. This communication session can occur later if the user's device requests said content from the CDN.

[0016] Once generated, this session key is embedded within a DRM license that is transmitted to the user's device, so that a DRM client module on the user's device can use it, for example, to sign and / or decrypt input data. This allows the session key to be securely transmitted to the user's device and used securely within the user's device. Furthermore, this session key is encrypted and then included in the access token that is transmitted to the user's device to access said content. This access token is intended to be used by the user's device to request the content. This allows the content provider's system Petition 870250086872, dated 09 / 25 / 2025, page 65 / 110 6 / 43 securely transmit the session key to the CDN via the user's device.

[0017] In one embodiment, the request for access to the content includes DRM license dispute data, and the DRM license is generated based on the received DRM license dispute data. As previously indicated, the DRM license dispute data may include only user data, for example, user device identification information, and may not be content-specific.

[0018] In one embodiment, the access token generation step includes a digital signature operation of the access token. This makes it possible to prove that the access token was generated by the content provider's system, in particular for the CDN, when the user's device requests content from the CDN using the access token.

[0019] For example, the access token generation step may include - Encrypt the session key and include the session key, in encrypted form, in the access token before signing the access token, or - Include the session key in the access token, and then encrypt and sign the access token.

[0020] Advantageously, the session key is generated exclusively for said communication session.

[0021] The present invention also relates to a method, implemented by a content delivery network, for delivering content to a user device, comprising the steps of: - Receive from a user device at least one content request including an access token for the requested content and an authentication tag; - determine a session key based on the token of Petition 870250086872, dated 09 / 25 / 2025, page 66 / 110 7 / 43 Access received by performing a decryption; - verify the validity of the user device's authentication tag with the specified session key; and - To transmit content data related to the requested content in response to a received content request, if the user's device authentication tag is valid, within a communication session.

[0022] If the CDN receives a content request from a user device, it may extract a session key from the access token within the content request, performing a decryption operation. If the session key was encrypted and then included in the access token, the CDN extracts the encrypted session key from the access token and then decrypts the session key. If the session key was included in plain text in the access token before the access token was encrypted, the CDN decrypts the access token and extracts the session key.

[0023] Once the session key has been extracted from the access token, it is used by the CDN to verify the validity of the authentication tag. The CDN can verify whether the user device, from which the authentication tag was received, also has access to the same session key.

[0024] The authentication tag may include at least one of - a digital signature of at least part of the content request, and - a hash value, in encrypted form, of at least part of the content request; and the authentication tag validity verification step may include at least one of: - verify the digital signature using the session key; and - decrypt the hash value using the session key. Petition 870250086872, dated 09 / 25 / 2025, page 67 / 110 8 / 43 Calculate a hash value for at least part of the received content request and verify that the decrypted hash value and the calculated hash value match each other.

[0025] In one embodiment, the method may additionally comprise a step to verify the validity of the access token, where the content data transmission step is performed only if the access token is valid.

[0026] In this way, the CDN can verify whether the access token was generated by the content provider's system, for example, based on an access token signature calculated by the content provider's system.

[0027] The present invention also relates to: - a user device configured to execute the steps of the previously defined method; - a content service provider system including a DRM license server, configured to execute the steps of the previously defined method; - a content delivery network, configured to execute the steps of the previously defined method. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Other features, purposes, characteristics and advantages of the invention will become clearer by reading the detailed description of the non-restrictive embodiments made with reference to the accompanying drawings.

[0029] Figure 1 shows a distributed system for delivering digital content to a plurality of user devices, according to a modality.

[0030] Figure 2 shows a simplified block diagram of a method for delivering digital content to a user device, according to a modality. Petition 870250086872, dated 09 / 25 / 2025, pp. 68 / 110 9 / 43

[0031] Figure 3 shows a communication diagram of a configuration phase (START) of the method in Figure 2, according to one modality.

[0032] Figure 4 shows a communication diagram of a content information phase A for obtaining access to the content of the method in Figure 2, according to a modality.

[0033] Figure 5 shows a communication diagram of a content reception phase B of the method in Figure 2, according to a modality. DETAILED DESCRIPTION

[0034] 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 the context dictates otherwise. The illustrative embodiments of system, device, and method described herein are not intended 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 in this document.

[0035] Figure 1 shows a distributed system 1000 for providing digital content to a plurality of user devices 300. The system 1000 includes a content provider system, or content provider backend, 100, and a content delivery network (CDN) 200. The user devices 300 are connected to the content provider system 100 and the content delivery network 200 through one or more communication networks 400 including, for example, the Internet. The content provider system 100 is connected to the content delivery network 200 through one or more communication channel(s) or network(s). Petition 870250086872, dated 09 / 25 / 2025, pp. 69 / 110 10 / 43

[0036] The content provider system or backend 100 assumes the role of managing access to digital content. In one embodiment, the content provider system 100 includes a content management system (CMS) 110, a CDN access token generator 120, and a DRM license server 130. Optionally, the content provider system 100 may additionally include another DRM license server 135 and a data analytics server or system 150.

[0037] The content provider or backend system 100 offers a content service, for example, a content streaming service, to user devices 300 and provides access to the content for user devices 300, the content being delivered to user devices 300 by the CDN 200. The digital content can be videos, audios, text files, software, games or any other types of data.

[0038] User devices 300 can interact with a user interface 140, such as a website, of the content provider system 100, through a communication network (e.g., the Internet) 400, to authenticate themselves, receive information about available content, request access to specific content, and receive content access data, such as a content access token, also called a CDN access token, to access the requested content through the content delivery network 200. For example, the user interface 140 is implemented with a CMS (Application Programming Interface) API that is part of the backend 100, and the user device 300 includes an application that may contain an application or frontend code configured to make web service calls to the CMS API.

[0039] The 110 content management system is configured to manage digital content and provide access to content. Petition 870250086872, dated 09 / 25 / 2025, pp. 70 / 110 11 / 43 digital for user devices 300. In one embodiment, the content management system 110 is configured to provide access to digital content on the user interface 140 for user devices 300 (e.g., website visitors).

[0040] The 110 content management system is also configured to manage customer or user information (e.g., user or customer subscriptions), for example, for customers or users who have subscribed to the content service.

[0041] A subscriber to the content service provided by the 100 system may be referred to as a customer. A customer account may be assigned by the 100 content provider system to each customer. A customer may log into their customer account with a 300 user device by performing an authentication process based on customer credentials (e.g., combination of user ID and password, biometric data, etc.). A customer may have the right to use different user devices to log into their customer account.

[0042] In operation, the content management system 110 is configured to authenticate a user device 300 based on user or user device or client credentials, receive an access request for a given content from the user device 300, and, if the authentication of the user device 300 has been successful, transmit a CDN access token for the requested content to the user device 300 to allow access to the content through the CDN 200, as will be described in more detail later.

[0043] The management of content and clients, and / or users, of a content service is well known to those skilled in the art and will not be described in further detail.

[0044] Furthermore, in the present invention, the management system Petition 870250086872, dated 09 / 25 / 2025, pp. 71 / 110 12 / 43 content delivery 110 is configured to generate session information for communication sessions between the content delivery network 200 and user devices 300 to deliver content to user devices 300.

[0045] A communication session between the content delivery network 200 and a user device 300 to deliver content to said user device 300 can be characterized by several parameters or metadata, such as: - User information including, for example, user or customer identification information (e.g., user ID) and / or user device information including, for example, user device identification information, - content information, including, for example, content identification information or a content identifier, and - optionally, time information, including, for example, timestamp data (e.g., timestamp data indicating when user device 300 requested the content from content provider system 100) and, optionally, a session expiration duration starting, for example, from the moment user device 300 requested the content from content provider system 100.

[0046] The session information generated for a communication session to receive requested content on a user device 300 from CDN 200 includes a session key and, optionally, a session identifier, or session ID, associated with the session key.

[0047] The session key is a cryptographic key, for example, a symmetric key, intended to be used for a communication session by a user device 300 and the CDN 200. It is generated by the content provider system 100, for example, by Petition 870250086872, dated 09 / 25 / 2025, page 72 / 110 13 / 43 content management system 110. The session key can be generated exclusively for a communication session between CDN 200 and a user device 300 to receive the requested content. The session keys generated for different communication sessions between CDN 200 and different user devices 300 are advantageously different from each other.

[0048] The session identifier, or session ID, allows you to identify the communication session, particularly if there are multiple sessions between a user device 300 and the content delivery network 200. The session identifier uniquely identifies a communication session. However, using a session identifier is optional.

[0049] In one embodiment, the content provider system 100 can use multiple CDN systems, or content delivery networks, simultaneously. In this case, the content management system 110 can be configured to generate session information for a given content on each CDN. Let us consider that the content provider system 100 uses N content delivery networks, with N > 1. In this case, the content provider system 100 is configured to generate N different session keys for N communication sessions between the content delivery networks N and a requesting user device 300, respectively, and N different CDN access tokens.

[0050] The content management system 110 is implemented with software and hardware. In one embodiment, the content management system 110 is a server that implements content management software. The operation of the content management system 110 will be described in more detail later, in the description of a method 500.

[0051] In one embodiment, the DRM license server, or be Petition 870250086872, dated 09 / 25 / 2025, page 73 / 110 14 / 43 DRM provider, 130 is connected to the content management system 110 via a local connection or a communication network. It can be configured to generate DRM licenses for session keys. Session keys are intended to be used in communication sessions between the content delivery network 200 and user devices 300 to deliver user-requested content to user devices 300. A DRM license for a session key is a data structure that includes the session key, for example, in encrypted form. For example, the session key is encrypted with a key linked to the requesting user device 300. The session key is securely embedded or included in the DRM license, for example, by encryption.

[0052] The DRM license for a session key may additionally include usage rules and / or metadata. In one embodiment, the DRM license includes a usage rule indicating that the session key is authorized to be used for encryption and / or signing with said session key. Optionally, the DRM license includes a session identifier in the metadata.

[0053] In one embodiment, the DRM license may include multiple session keys, for example, if content provider system 100 uses multiple CDN systems to deliver content to user devices. Alternatively, if content provider system 100 uses N CDN systems to deliver content to user devices, it could generate N DRM licenses for the N different session keys generated (i.e., one DRM license per session key).

[0054] In one embodiment, the DRM license server, or DRM server, 135 is also connected to the content management system 110, via a local connection or a communication network. It can be configured to generate licenses for Petition 870250086872, dated 09 / 25 / 2025, pp. 74 / 110 15 / 43 DRM for digital content. As is well known to those skilled in the art, a DRM license for one or more pieces of content is a data structure including a cryptographic key, or content key, in encrypted form, to decrypt one or more pieces of digital content. The DRM license may include other data, such as usage rules. For example, a usage rule is a rule that authorizes only the decryption of one or more pieces of content with the content key.

[0055] In this embodiment, the DRM server 130 used to protect session keys and the DRM server 135 used to protect content keys are two separate DRM servers, respectively dedicated to session keys and content keys.

[0056] DRM server 130 and DRM server 135 may use different DRM implementations or techniques, respectively, for session keys and content keys.

[0057] Alternatively, DRM server 130 and DRM server 135 can be merged or combined into a single DRM server.

[0058] Content management system 110 can perform authorization operations to obtain DRM licenses from DRM server 130 or DRM server 135 for user-requested content. Alternatively, DRM server 130 and / or DRM server 135 can perform the authorization operations.

[0059] The DRM server 130 can be a separate entity, as shown in Figure 1, or it can be combined with the content management system 110. Similarly, the DRM server 135 can be a separate entity, as shown in Figure 1, or it can be combined with the content management system 110. Petition 870250086872, dated 09 / 25 / 2025, pp. 75 / 110 16 / 43

[0060] The CDN access token generator 120 assumes the role of generating CDN access tokens for digital content requested by user devices 300. It can be a server. A token is a data structure, or a message, that is digitally signed and / or encrypted. The signature ensures the integrity of the token, while encryption ensures confidentiality.

[0061] The content management system 110 can perform authorization or authentication operations to obtain CDN access tokens from the CDN access token generator 120 for user-requested content. Alternatively, the CDN access token generator 120 can perform the authorization or authentication operations. In either case, the authentication and authorization operations are advantageously performed before delivering CDN access tokens or other data to user devices 300 from the content provider system 100.

[0062] A CDN access token generated for a given piece of content is linked to information about the content to which it provides access. In one embodiment, the CDN access token is linked to a network address, such as a URL, of the content, for example, to a network address, or URL, of a directory or memory location on CDN 200 where the content data of said content (for example, a content manifest file, content segments or fragments, and any other resources needed to use or play the content) are stored. The URL of that directory or memory location may be designated as a content base URL.

[0063] In one embodiment, the URLs of all data related to a piece of content, for example, the URLs of the content manifest and the URLs of the content segments or fragments, can be derived from the base content URL. An illustrative example of differe Petition 870250086872, dated 09 / 25 / 2025, pp. 76 / 110 17 / 43 of the URLs for a specific piece of content, named mycontent, are given below: - Base content URL: https: / / cdn.domain.com / mycontent / - Content manifest URL: https: / / cdn.domain.com / mycontent / manifest.mpd First video segment of the content: https: / / cdn.domain.com / mycontent / video-sd / 1.mp4

[0064] There are different ways to link the CDN access token to the content's network address, which will be described later.

[0065] The CDN access token can be signed with a cryptographic key from the content provider system 100. This cryptographic key can be a private key from a pair of public and private asymmetric keys from the content provider system 100. Alternatively, this cryptographic key can be a secret symmetric key that is shared by the content provider system 100 and the content delivery network 200.

[0066] Furthermore, in the present invention, the CDN access token contains session information about a communication session between the content delivery network 200 and a user device 300 to deliver the content to which the CDN access token provides access. This communication session may occur in the future to deliver the content (i.e., the content for which the CDN access token was generated) to the user device 300 through the content delivery network 200. The session information includes the session key, in encrypted form, and optionally, the session identifier, assigned to the communication session. In the CDN access token, the session key is encrypted with a cryptographic key. In an exemplary embodiment, the cryptographic key used to encrypt the session key in the CDN access token Petition 870250086872, dated 09 / 25 / 2025, page 77 / 110 18 / 43 CDN is a secret symmetric key shared by the CDN access token generator 120 and the content delivery network 200. Alternatively, the cryptographic key may be asymmetric, i.e., a private key from a pair of private and public keys of the CDN access token generator 120. In this case, CDN 200 has access to a public key certificate of said public key.

[0067] In another embodiment, the CDN access token is encrypted by the CDN access token generator 120 with a cryptographic key (for example, a symmetric key shared by the CDN access token generator 120 and CDN 200, or a private asymmetric key associated with a CDN-accessible public key). In this case, the session key is encrypted by the CDN access token's cryptography.

[0068] In another mode, the CDN access token can be encrypted and signed by the CDN access token generator 120.

[0069] The CDN access token generator 120 can be a separate entity, as shown in Figure 1, or it can be combined with the content management system 110.

[0070] The data analysis server 150 assumes the role of registering or recording information and / or parameters of the communication sessions configured by the content provider system 100 to deliver requested content to user devices 300 through the content delivery network 200. The information or parameters recorded about a communication session may include at least part of a session identifier, user information (e.g., a user or client identifier), user device information (e.g., a user device identifier), content information (e.g., a content identifier), and time information (e.g., time stamp data). Petition 870250086872, dated 09 / 25 / 2025, pp. 78 / 110 19 / 43 date / time stamp indicating when the user device requested the content and, optionally, the expiration duration). The information recorded about a communication session can be used later in case there is a problem with said communication session, for example, to revoke it. The date / time stamp data and, optionally, the expiration duration can be used to time-limit access to the content requested by the user device 300. They can be applied directly by the CDN 200.

[0071] Although shown separately, the content management system 110, the CDN access token generator 120, the DRM license servers 130, 135, the analytics server 150 and / or other server(s) may be combined. Entities 110, 120, 130, 135, 150 and / or other servers may be computing devices and may comprise memory storing data and also storing computer executable instructions which, when executed by one or more processors, cause the server(s) to perform the steps described herein.

[0072] The content delivery network 200 is a geographically distributed network of edge nodes or servers 210. Its function is to deliver or transmit digital content to user devices 300 through the edge nodes 210. As is known, the content delivery network 200 may also comprise a CDN origin server, not shown, whose function is to receive content from the content provider system 100 and cache it in each of the plurality of CDN edge servers or nodes 210.

[0073] Digital content can be encrypted. It can also be segmented or divided into content segments or fragments. Content segments or fragments can be associated with a manifest file or playlist, as described. Petition 870250086872, dated 09 / 25 / 2025, pp. 79 / 110 20 / 43 later.

[0074] In one embodiment, the content delivery network 200 may additionally include a configuration database 220, a configuration server 230 and a revocation list management server 240.

[0075] The configuration server 230 assumes the role of managing the main data shared or agreed upon by the CDN 200 and the content provider system 100.

[0076] The revocation list management server 240 is responsible for creating and updating a revocation list including session identifiers that have been revoked.

[0077] The configuration database 220 is for storing the key data agreed upon by the CDN 200 and the content provider system 100 and the revocation list. It can be accessed by the edge nodes 210.

[0078] In one embodiment, the delivery of content to a user device 300 via CDN 200 is performed based on access data (e.g., CDN access token) received from the content provider system 100. In operation, a user device 300 may initially interact with the content provider system 100, for example, via user interface 140, request access to certain content from the content provider system 100, receive access data (e.g., CDN access token) from the content provider system 100 to access the requested content, and then receive the requested content from the content delivery network 200 based on the received access data (e.g., CDN access token). The received content may need to be decrypted using a content DRM license, as described later.

[0079] Although shown separately, the database of Petition 870250086872, dated 09 / 25 / 2025, pages 80 / 110 21 / 43 configuration 220, configuration server 230 and revocation list management server 240 and / or other database(s) and other server(s) may be combined. Entities 220, 230, 240 and / or other servers may be computing devices and may comprise memory storing data and also storing computer executable instructions which, when executed by one or more processors, cause the server(s) to execute the steps described herein.

[0080] User devices 300 can be any type of user device or user equipment 300, including computer, laptop, PC, desktop, smartphone, tablet, etc. However, the term user device should be broadly interpreted to cover any computing device.

[0081] Although the 300 user devices are illustrated in Figure 1 as smartphones, as discussed above, other embodiments are possible. Thus, the 300 exemplary smartphone is not intended to be limiting.

[0082] User devices 300 are configured to interact with the content provider system 100 to request access to digital content and then fetch or receive the requested content through the content delivery network 200.

[0083] In one embodiment, a user device 300 may include a content usage module 310, for example, a content player module and a content decryption module 320, as illustrated in Figure 3.

[0084] The content usage module 310 can be configured to communicate with the content provider system 100 to request access to digital content, communicate with the content delivery network 200 to receive or download the requested content, and then use the content, for example, to play it. Petition 870250086872, dated 09 / 25 / 2025, pp. 81 / 110 22 / 43

[0085] In one embodiment, the 320 content decryption module includes a DRM client module. The 320 DRM client module is configured to perform cryptographic operations, actions, or functions, such as decrypting, encrypting, digitally signing, and / or verifying a digital signature.

[0086] The DRM client module 320 of the user devices 300 and the DRM servers 130, 135 use the same DRM technology, for example, Widevine® or PlayReady®.

[0087] User device 300 can be implemented with hardware and software. It may include one or more processors, application(s), and a DRM client. The operations, functions, and / or actions that user device 300 is configured to perform will be described in more detail in the method 500 description.

[0088] Figure 2 is a simplified block diagram representing a 500 method, according to an embodiment. The 500 method shown in Figure 2 presents an embodiment of a method that could be used with the content provider system 100, the content delivery network 200, and the user devices 300, for example.

[0089] The operations of method 500 presented below are for illustrative purposes only. Method 500 may include one or more operations, functions, or actions, as illustrated by one or more of the blocks and arrows. Although the blocks may be illustrated in a sequential order, these blocks may, in some cases, be performed in parallel and / or in a different order than described here. Furthermore, the various blocks may be combined into fewer blocks, divided into additional blocks, and / or removed based on the desired implementation.

[0090] In addition, for method 500 and other processes and methods revealed herein, the flowchart shows the functionality and operation. Petition 870250086872, dated 09 / 25 / 2025, page 82 / 110 23 / 43 tion of a possible implementation of the present modalities. In this sense, each block can represent a module, a segment, a portion of a manufacturing or operational process, or a portion of the program code, which includes one or more instructions executable by a processor to implement specific logical functions or steps in the process. The program code can be stored on any type of computer-readable media, for example, as a storage device including a disk or hard drive. Computer-readable media can include non-transient computer-readable media, for example, computer-readable media that stores data for short periods of time, such as register memory, processor cache, and random access memory (RAM).Computer-readable media can also include non-transient media, such as long-term secondary or persistent storage, such as read-only memory (ROM), optical or magnetic discs, compact-disc read-only memory (CD-ROM), for example. Computer-readable media can also be any other volatile or non-volatile storage system. Computer-readable media can be considered a computer-readable storage medium, for example, or a tangible storage device.

[0091] Furthermore, for method 500 and other processes and methods disclosed herein, each block may represent circuits that are connected to perform specific logical functions in the process, for example.

[0092] Method 500 may include a method for receiving or delivering digital content on a user's device 300.

[0093] Method 500 may include a setup phase (START), a content access acquisition phase, a phase of Petition 870250086872, dated 09 / 25 / 2025, page 83 / 110 24 / 43 delivery of content B and, optionally, a session revocation management phase C.

[0094] The configuration phase (START) may include steps 502, 504, 506, shown in Figure 3.

[0095] In step 502, the content delivery network 200 and the content provider system 100 agree on the main data. In one embodiment, step 502 can be executed by the logical configuration module 230 of the CDN 200 and the content management system 110 of the content provider system 100.

[0096] In one embodiment, the agreed key data may include two sets of keys: one used for authenticating CDN access tokens and one used for session key confidentiality. Different cryptographic schemes or algorithms, based on symmetric key(s) or asymmetric keys, are possible for each set of key(s).

[0097] In another embodiment, a single key set can be used with a cryptographic scheme or algorithm to provide authenticity (integrity) and confidentiality. In this way, it is possible to provide confidentiality of CDN access tokens and confidentiality of session keys, using a key set(s). For example, the AES-GCM scheme could be used, which allows authenticity and encryption with a single symmetric key.

[0098] In the present embodiment, which is merely illustrative and not limiting, the agreed data includes a cryptographic key k1 for session key confidentiality, in other words, for encrypting session keys. The cryptographic key k1 may be a secret symmetric key shared between the content delivery network 200 and the content provider system 100. It may be stored in the configuration database 220 of the content delivery network 200, in a 504 step, and in a memory of the generator of Petition 870250086872, dated 09 / 25 / 2025, page 84 / 110 25 / 43 CDN access token 120 and / or in a content management system memory 110, in a 506 step.

[0099] In one variant, a pair of asymmetric public and private keys can be used for session key confidentiality. In this case, the private key can be stored in memory if the CDN access token generator 120, while a corresponding public key certificate can be stored in the configuration database 200 of the content delivery network 200.

[00100] In the present embodiment, the agreed key data may additionally include an asymmetric key pair, including a K2pUb public key and a K2pr private key, for authenticity (integrity) of the CDN access tokens, i.e., to sign the CDN access tokens and verify the signatures. The K2pr private key may be stored in a memory of the CDN access token generator 120 and / or in a memory of the content management system 110. A public key certificate, including the K2pUb public key and information about the owner of the K2pUb and K2pr keys signed by a certification authority, may be stored in the configuration database 220 of the content delivery network 200.

[00101] Alternatively or additionally, the agreed key data may include a secret symmetric key, shared by the content provider system 100 and the content delivery network 200, to sign CDN access tokens and verify signatures. This secret key may be stored in the CDN configuration database 220 and in a memory of the CDN access token generator 120 and / or in a memory of the content management system 110.

[00102] The key data stored in database 220, here the secret key k1 and the public key K2pUb and / or the certificate of Petition 870250086872, dated 09 / 25 / 2025, page 85 / 110 26 / 43 public key K2pUb, are accessible by 210 edge nodes of CDN 200.

[00103] The configuration phase, including steps 502 to 506, can be run periodically, for example, once a day. Phase A of obtaining access to the content.

[00104] Phase A may include steps 508 to 535.

[00105] In an optional 508 step, the user device 300 can interact with the user interface (e.g., a website) of the content management system 110 to query and / or receive information about digital content available in the user interface 140. The 508 step can be performed by module 310.

[00106] In a 510 step, the 500 method includes the DRM client module 320 generating and providing DRM license dispute data, or DRM dispute data, to the content player module 310, for example, upon request. The DRM dispute data may include all data that is necessary for the license server 130 to create a license and handle license revocation. The generated DRM license dispute data may include information about the user device 300, such as a unique device identifier and, optionally, a device model and version(s). The DRM dispute data may additionally include a device digital certificate including a public key from a public and private asymmetric key pair of the user device 300. The DRM dispute data is not content-specific. In other words, it does not contain any information about a specific piece of content.In one embodiment, they contain only information about the user's device or, more generally, user data. The DRM dispute format is specific to the DRM technique. DRM license dispute data can be digitally signed by the CLI module. Petition 870250086872, dated 09 / 25 / 2025, page 86 / 110 27 / 43 DRM 320 entity to avoid changes in the transition.

[00107] Then, in a 512 step, user device 300 requests access to certain content from content provider system 100. For this purpose, module 310 transmits an access request for the specific content with the DRM license dispute data generated in step 510 to content management system 110. The access request may include information about the user, such as a user identifier and / or user credentials (e.g., a user identifier and password combination, or biometric data, etc.). Alternatively, instead of user credentials, the access request may include a user access token previously received by user device 300 from content provider system 100 during a login operation. The access request additionally includes information that identifies the requested content, such as a content identifier (ID).The access request may additionally include the DRM license dispute data generated in step 510. Alternatively, the DRM license dispute data may be transmitted separately (i.e., not in the request). The access request may be a request for an address of the requested content on CDN 200, such as a content URL. For example, the access request may have the following simplified form: Get the URL of the content (user credentials, DRM dispute data, content ID).

[00108] Note that DRM license dispute data is generated or provided by the DRM client module 320 in step 510, before requesting content access from the content provider system 100 in step 512.

[00109] The content management system 110 receives the access request from user device 300 (step 512). Petition 870250086872, dated 09 / 25 / 2025, page 87 / 110 28 / 43

[00110] Then, in a 514 step, the content management system 110 can verify the received user credentials or user access token. If the user credentials (or user access token) are valid, the content management system 110 authorizes user device 300 to access the content management system 110. If the user credentials (or user access token) are not valid, the content management system 110 denies access to user device 300. In this case, the content management system 110 can send an error message to user device 300 and terminate the process.

[00111] In a 516 step, if user device 300 has been authorized to access the content by content management system 110, content management system 110 generates session information including a session key and, optionally, a session identifier, or session ID, for a communication session that may be about to begin between the content delivery network 200 and user device 300 to receive the requested content. The generated session information may be associated with session parameters or metadata including, for example: - information about the user, for example, a user identifier and / or information about the user's device 300, for example, a user device identifier, - Information about the requested content, for example, a content identifier, - and, optionally, timestamp data indicating when the access request was received by the content management system 110 and an expiration duration.

[00112] The session key and session parameters or metadata Petition 870250086872, dated 09 / 25 / 2025, pp. 88 / 110 29 / 43 are associated (session ID, user and / or device ID, content ID, timestamp data) and are assigned to a communication session between CDN 200 and user device 300 to receive the requested content on user device 300 from CDN 200. The session key and associated metadata can be transmitted to analytics server 150.

[00113] The session identifier uniquely identifies the communication session between CDN 200 and user device 300 to receive the requested content. In one embodiment, the session identifier is randomly generated.

[00114] The session key is specific, unique, to the communication session, for example, a streaming session, between CDN 200 and user device 300 to receive the requested content. The communication session is, for example, identified by a content identifier, a user device identifier and, optionally, timestamp data. In one embodiment, the session key is randomly generated. For example, it is a binary code of x bits (for example, x = 128 or 256, which is only an illustrative and non-limiting example).

[00115] So, in a 520 step, the 120 access token generator generates a CDN access token to grant access to the requested content, for example, upon request 518 from CMS 110. The 518 request from CMS 110 may include the session key and, optionally, the session identifier, generated in step 516. Alternatively, the 120 access token generator may have access to the session key and session identifier stored in memory or a database.

[00116] The CDN access token that grants access to specific content includes data and a signature. For example, it can be implemented as a JSON (JavaScript Object Notation) structure. Petition 870250086872, dated 09 / 25 / 2025, pp. 89 / 110 For example, 30 / 43, as a JSON Web Token (JWT), or include plain text. It is linked to a network address, here a URL, on the CDN 200 of the requested content. For example, it is linked to the content base URL of the requested content. As indicated earlier, there are different ways to link the CDN access token to the network address or URL of the content to which it provides access. The list below provides non-limiting examples of this linking, in the case of a content URL being used as the content network address: The content URL is included in the CDN access token. - A hash value of the content URL is included in the CDN access token; - A hash value of the content URL is included in the CDN access token signature calculation without copying that hash value into the CDN access token itself, which has the advantage of reducing the size of the CDN access token, since the CDN access token needs to be included in a CDN content request to be usable anyway, and that CDN content request includes the content URL.

[00117] Furthermore, in the present invention, the CDN access token also contains the session key, in encrypted form, and optionally, the session identifier, generated in step 516.

[00118] In this embodiment, to provide confidentiality for the session key, the session key is encrypted by the CDN access token generator 120, for example, with the key k1 shared by the content provider system 100 and CDN 200. The encrypted session key is included in the CDN access token.

[00119] In addition, to provide authenticity (integrity) of Petition 870250086872, dated 09 / 25 / 2025, pages 90 / 110 31 / 43 CDN access token, the CDN access token including the encrypted session key is signed by the CDN access token generator 120, for example, with the K2pr private key.

[00120] As previously described, other cryptographic schemes could alternatively be used to provide confidentiality for the session key and authenticity for the CDN access token. For example, a private asymmetric key could be used to encrypt the session key. In another example, a secret symmetric key shared by CDN 200 and content provider system 100 could be used to sign the CDN access token.

[00121] Alternatively, a cryptographic scheme or algorithm that provides authenticity (integrity) and confidentiality and uses a single key set(s) can be used. The key set(s) includes, for example, a single symmetric key shared by CDN 200 and content provider system 100 or a single pair of public and private asymmetric keys from content provider system 100. In this case, the session key can be included in the CDN access token which is then encrypted and signed, by the CDN access token generator 120, with the secret symmetric key or with the private asymmetric key. In this case, the session key is encrypted by the encryption of the CDN access token.

[00122] Next, in a 522 step, the access token generator 120 transmits the generated CDN access token to the content management system 110.

[00123] In step 524, the content management system 110 requests the DRM license server 130 to create a DRM license for the session key. The request may include the DRM dispute data received from the user device 300 in step 512, the session key, and optionally, the identifier of Petition 870250086872, dated 09 / 25 / 2025, pp. 91 / 110 32 / 43 session. Step 524 can be performed before or in parallel with step 518.

[00124] In a 526 step, the DRM server 130 generates a DRM license for a session key, based on the DRM dispute data. The generated DRM license includes the session key, which is protected, for example, by encryption and, optionally, one or more usage rules and metadata.

[00125] Usage rules indicate for what use by the DRM client the session key is intended or permitted. For example, usage rules indicate that the session key can only be used by the DRM client to sign and / or encrypt input data. Optionally, usage rules may include an expiration date consistent with, or aligned with, the expiration date of the CDN access token. Other usage rules may be implemented for the session key.

[00126] Metadata may include the session identifier. This session identifier does not need to be encrypted. Furthermore, it is optional.

[00127] Then, in a step 528, the DRM server 130 transmits the generated DRM license to the content management system 110.

[00128] Then, in a step 530, the content management system 110 transmits the CDN access token and the DRM license to the user device 300, in response to the access request (step 512). The content management system 110 may send the CDN access token together with the DRM license (i.e., together with the DRM license).

[00129] The transmitted CDN access token and the transmitted DRM license are associated with each other or paired, as both include the same session key in encrypted form and the Petition 870250086872, dated 09 / 25 / 2025, pp. 92 / 110 33 / 43 same session identifier (optional) which may not be encrypted. The session key may be in a first encrypted form in the CDN access token and in a second encrypted form, different from the first encrypted form, in the DRM license.

[00130] In this embodiment, in order to have access to a plurality of contents, for example, a number X of contents, the user device 300 transmits X access requests to the content provider system 100, one per content (each access request including the content ID of a requested content) and receives X pairs of CDN access tokens and DRM licenses for X session keys, respectively.

[00131] Alternatively, user device 300 may transmit an access request for a plurality of contents, for example, for contents X, to content provider system 100. In this case, the access request may include N content identifiers, respectively, for content N. In response, content provider system 100 may transmit N sets or pairs of CDN access tokens and DRM licenses for N different session keys, respectively for the N contents.

[00132] In a 532 step, the content management system 110 records or logs information and / or parameters and / or metadata related to the request / response process, including steps 508 to 530, on the analytics server 150. The recorded information includes, for example, the session identifier and parameters or metadata of the corresponding communication session. These parameters or metadata may include the user identifier, the user device identifier, the content identifier, and / or timestamp data.

[00133] In a step 534, the content usage module 310 (e.g., player module) receives the DRM license and token. Petition 870250086872, dated 09 / 25 / 2025, pp. 93 / 110 34 / 43 access the CDN and, in a 535 step, import the DRM license into the DRM 320 client module. After importing the DRM license into the DRM 320 client module, the session key can be used by the DRM 320 client module to sign and / or encrypt input data (i.e., data entered into the DRM 320 client module).

[00134] Although the communication session, which is about to begin between user device 300 and CDN 200, is identified by a session identifier, as discussed above, other modalities that do not use session identifiers to identify communication sessions are possible. Thus, the example of the session identifier is not intended to be limiting. Phase B of content delivery or streaming.

[00135] After phase A, method 500 includes phase B in which user device 300 downloads or receives the requested content from the content delivery network 200, upon request(s), during a communication session between the CDN 200 and user device 300, for example, a playback session of the requested content.

[00136] Phase B can be performed after the user device 300 receives the CDN access token and DRM license, preferably upon receiving them.

[00137] Phase B includes a 540 step of generating one or more CDN content requests to request content data from the requested content, executed by user device 300.

[00138] An initial CDN content request may request a content manifest or playlist file of the requested content. Then, subsequent CDN content requests may request the content segments, fragments, and / or other resources needed to use or play the requested content, based on Petition 870250086872, dated 09 / 25 / 2025, pp. 94 / 110 35 / 43 in the manifest file.

[00139] A content manifest or playlist file contains information about the network addresses (e.g., URLs) of content segments, fragments, or other resources of the requested content. Segment network addresses (e.g., segment URLs) are relative addresses. They can be constructed from a root portion of the network address received from the manifest file by adding segment identifiers, such as indexes or segment numbers, contained in the manifest file.

[00140] In block 542, step 540 includes module 310 creating, preparing, or editing the CDN content request. The CDN content request may include the following elements: - a network address, such as a URL, of the requested content data (e.g., manifest file, content segment, fragment, other resource needed to use or play the content) and - the CDN access token as previously received from content provider system 100 for the requested content (step 530).

[00141] The CDN access token included in the CDN content request comprises the session key in encrypted form (either by session key-specific encryption or by CDN access token encryption), as received from the content provider system 100.

[00142] Furthermore, in block 546, step 540 includes module 310 obtaining an authentication tag by performing a cryptographic operation, carried out by a DRM client module 320, to sign and / or encrypt, with the received DRM license session key, input data that is based on at least part of the content request. In other words, the DRM client module 320 Petition 870250086872, dated 09 / 25 / 2025, pages 95 / 110 36 / 43 performs a signing and / or encryption operation with the DRM license session key on input data, said input data being based at least in part on the CDN content request, to produce the authentication tag. The input data is provided by module 310 to DRM module 320 in block 544.

[00143] Depending on the modality, the input data may include the CDN content request, or a portion of the CDN content request, or a concatenation of different elements or components of the CDN content request. For example, the input data includes the network address or URL embedded in the CDN content request. Optionally, it may additionally include one or more CDN content request headers, for example, the userAgent header and / or CDN content request query parameters. If the input data includes different elements, such as the URL, one or more headers, and query parameters, these different elements may be concatenated before being provided as input data to the DRM 320 client module.

[00144] In one variant, the input data provided to the DRM client module 320 in block 544 includes a hash value of the above-described data (for example, a hash value of the CDN content request, or a hash value of a portion of the CDN content request, or a hash value of a concatenation of different elements or components of the CDN content request). The hash value may be calculated by means of processing or computation of the user device 300, external to the DRM client module 320.

[00145] So, in step 546, the DRM 320 client module uses the DRM license including the session key, which was previously Petition 870250086872, dated 09 / 25 / 2025, pages 96 / 110 37 / 43 imported (step 535), to sign and / or encrypt the received input data.

[00146] In a mode where the input data includes the CDN content request, or a portion of the CDN content request, or a concatenation of different elements of the CDN content request, the input data is advantageously signed by the DRM 320 client module with the session key. For example, the input data is signed using a cryptographic function such as hash-based message authentication code (HMAC). In this case, the authentication tag includes the signature of the input data.

[00147] In another mode where the input data includes a hash value, this hash value can be encrypted by the DRM 320 client module with the session key. In this case, the authentication tag includes the hash value in encrypted form.

[00148] Thus, the output of the signing or encryption operation performed by the DRM client module 320 in step 546 includes a signature and / or an encrypted hash value, such as an authentication tag. This output is returned to module 310 in step 548.

[00149] In one embodiment, the authentication tag may include either a signature of at least part of the content request or an encrypted hash value of at least part of the content request.

[00150] Next, module 310 proceeds with the inclusion of the authentication tag, which includes the signature and / or encrypted hash value generated in step 546, in the CDN content request, in step 542 of the CDN content request preparation. As Petition 870250086872, dated 09 / 25 / 2025, pp. 97 / 110 38 / 43 Yes, the CDN content request includes the network address (e.g., a URL) of the requested content data, the CDN access token as received from the content management system 110, and the authentication tag computed by the DRM client module 320 with the session key. For example, the CDN content request is in the form of an HTTP request, including the URL with query parameters and headers. The CDN access token and authentication tag can be provided as query parameters or HTTP request headers.

[00151] Then, in a 550 step, module 310 transmits the CDN content request to a CDN edge node 210 from CDN 200. Thus, edge node 210 receives the CDN content request including the requested content network address or content URL, the CDN access token, and the authentication tag.

[00152] In a 552 step, edge node 210 verifies the validity of the CDN access token.

[00153] For this purpose, edge node 210 can verify the signature of the CDN access token to determine if the signature is valid. If the CDN access token was signed with the private key K2prdo of content provider system 100, edge node 210 uses the associated public key K2pUb to verify the signature. If the CDN access token was signed with a secret symmetric key shared by content provider system 100 and CDN 200, edge node 210 uses this shared secret key to verify the signature.

[00154] In addition, edge node 210 can verify whether the content to which the CDN access token provides access matches the content requested in the CDN content request. How this verification is performed depends on how the CDN access token is constructed. Illustrative examples are given below: Petition 870250086872, dated 09 / 25 / 2025, pp. 98-110 39 / 43 - If the content URL is included in the CDN access token, edge node 210 is configured to compare the content URL in the CDN access token and the content URL in the CDN content request, and grant access to the content to the user's device if both URLs match; - If a hash value of the content URL is included in the CDN access token, edge node 210 is configured to compare the hash value of the CDN access token and a hash value calculated from the content URL of the CDN content request, and grant access to the content if both hash values ​​match; - If a hash value of the content URL is included in the CDN access token signature calculation, edge node 210 is configured to verify the CDN access token signature using a hash value of the content URL from the CDN content request.

[00155] If the CDN access token is valid (i.e., the signature has been successfully verified and the content to which the CDN access token provides access matches the content requested in the CDN content request), edge node 210 determines the session key based on the CDN access token. For this purpose, edge node 210 can extract the session key, in encrypted form, from the CDN access token in a 554 step. Then, in a 556 step, edge node 210 decrypts the session key, for example, with the secret key k1 shared by content provider system 100 and CDN 200. In another embodiment, edge node 210 decrypts the session key with a public key from content provider system 100.

[00156] In another mode in which the CDN access token was encrypted by the content provider system 100, the node Petition 870250086872, dated 09 / 25 / 2025, pp. 99 / 110 Edge 210 40 / 43 can decrypt the CDN access token and then extract the session key from the CDN access token. In this case, verifying the validity of the CDN access token may include successfully decrypting the CDN access token.

[00157] If the CDN access token is not valid, edge node 210 denies access to the requested content to user device 300 and may send an error message to user device 300.

[00158] Once decrypted (step 556), the session key is then used by edge node 210 to verify the validity of the authentication tag of the CDN content request, in a step 558. If the authentication tag includes a signature of at least part of the content request, edge node 210 verifies the signature to determine if the authentication tag is valid. If the authentication tag includes a hash value in encrypted form, edge node 210 decrypts the hash value, calculates the hash value based on the received CDN content request, and compares the decrypted hash value and the calculated hash value to verify that they match, meaning the authentication tag is valid.

[00159] A valid authentication tag allows edge node 210 to determine that the requesting user device 300 has access to the session key. If the authentication tag received with the CDN content request is valid, the method proceeds with steps 560 (optional), 562 described below.

[00160] Optionally, if the authentication tag is valid, edge node 210 can verify that the session identifier of the communication session between CDN 200 and the requesting user device 300 has not been revoked, in a 560 step. For example, edge node 210 can internally cache a revocation list including the session identifiers of communication sessions. Petition 870250086872, dated 09 / 25 / 2025, pages 100 / 110 41 / 43 that have been revoked. The revocation list can be received from configuration database 220 and updated periodically. To verify that the session identifier of the current communication session has not been revoked, edge node 210 searches for the corresponding session identifier in the cached revocation list. If no match is found, edge node 210 determines that the session identifier has not been revoked. If a match is found, edge node 210 determines that the session identifier has been revoked and therefore denies access to the requested content to user device 300.

[00161] If the authentication tag is invalid, edge node 210 denies access to the requested content to user device 300 and may send an error message to user device 300.

[00162] If access to the requested content by user device 300 is authorized, edge node 210 transmits the requested content data (e.g., a content manifest or playlist file, content segments or fragments, or other resources needed to use or play the requested content) to user device 300 in a 562 step.

[00163] Steps 540 to 562 are performed for each CDN content request from user device 300 to edge node 210.

[00164] User device 300 may need to obtain a DRM license incorporating a content key for the requested content, for example, if the requested content is encrypted and / or the use of the content is limited by usage rules. In this embodiment, the DRM license for the requested content is delivered by DRM server 135, different from the DRM server 130 used to deliver the session keys. User device 300 may receive the DRM license for the requested content from DRM server 135. Petition 870250086872, dated 09 / 25 / 2025, pages 101 / 110 42 / 43 upon request, in a known manner. Then, upon receiving the content segments, fragments and / or other resources, in encrypted form, of the requested content, the user device 300 can decrypt them. Decryption can be performed by the DRM client module 320 using the DRM license received for the requested content. Phase C of revocation management

[00165] The purpose of phase C is to manage a revocation list including session identifiers related to communication sessions between CDN 200 and user devices that have been detected as illegal. Phase C is optional.

[00166] An anti-piracy system 500 is responsible for monitoring communications or data flows between the CDN 200 and user devices 300 and, optionally, between the content provider system 100 and user devices 300, to detect a pirated data flow. The anti-piracy system 500 may use watermark detection to detect a pirated flow or any other suitable anti-piracy technique.

[00167] After detecting a pirate communication session between CDN 200 and a user device 300, the anti-piracy system 500 can request the session identifier of the pirate communication session from the analysis server 150 and then transmit it to the revocation list management server 240.

[00168] The revocation list management server 240 can update the revocation list by adding the received session identifier and register the updated revocation list in the configuration database 220, which can be accessed by the edge nodes 210.

[00169] CDN 210 edge nodes can maintain a copy of the revocation list in their internal cache and update it regularly.

[00170] The present method depends on a DRM system for im Petition 870250086872, dated 09 / 25 / 2025, pages 102 / 110 43 / 43 request the use of a CDN access token without the use of a session key that is provided by content provider system 100 to user device 300 and CDN 200, through user device 300. The session key is transmitted, in encrypted form, in a DRM license transmitted to user device 300. It is therefore protected by DRM, but can be used to perform signing and / or encryption operations by the DRM client module 320 of the user device. The session key is also transmitted, in encrypted form, to CDN 200, through user device 300, within CDN access tokens. In the CDN access tokens, the session key is protected by encryption with a key shared by content provider system 100 and CDN 200. Final considerations

[00171] Although an overview of the subject matter of the present invention has been presented with reference to specific exemplary embodiments, various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the embodiments of the present invention. For example, various embodiments of the same may be mixed and matched or made optional by a person skilled in the art. Therefore, the Detailed Description should not be interpreted in a limiting sense, and the scope of various embodiments is defined only by the appended claims together with the full range of equivalents to which such claims are entitled. Petition 870250086872, dated 09 / 25 / 2025, pp. 103 / 110

Claims

1 / 4 CLAIMS 1. A method for receiving content on a user device (300), characterized in that it comprises the steps, performed by the user device (300), of: sending (512) an access request to access content to a content provider system (100); receiving (534) from the content provider system (100) an access token for said content, said access token including an encrypted session key and a Digital Rights Management, DRM license, including said session key; and transmitting (550) a content request including the received access token to a content delivery network and, in response, receiving (562) from the content delivery network the requested content data, in a communication session;wherein the content request further comprises an authentication tag obtained by performing a cryptographic operation (546), executed by a DRM client module (320) of the user device (300), to sign and / or encrypt, with the received DRM license session key, input data that are based on at least part of the content request.; 2. Method according to claim 1, characterized in that cryptographic operation (546) is used to: - sign, with the session key, at least part of the content request; and - encrypt, with the session key, a hash value of at least part of the content request.

3. Method, according to claim 1 or 2, characterized in that the access request includes DRM license dispute data. Petition 870250086872, dated 09 / 25 / 2025, p. 51 / 110 2 / 4 4. Method, according to claim 3, characterized in that said DRM license dispute data includes only user data.

5. Method, executed by a content provider system (100), characterized in that it comprises the steps of: - receiving an access request to access content from a user device (300); - generating (516) a session key for a communication session to receive said content on the user device (300) through a content delivery network (200); - generating (520) an access token including said session key in encrypted form; - generating (526), ​​by a DRM license server (130), a DRM license including said session key; and - transmitting (530) the access token and the DRM license to the user device (300).

6. A method according to claim 5, characterized in that the access request for the content includes DRM license dispute data and the DRM license is generated based on the received DRM license dispute data.

7. Method according to claim 5 or 6, characterized in that the (520) access token generation step includes a digital signature operation of the access token.

8. Method according to claim 7, characterized in that step (520) of access token generation includes - encrypting the session key and including the session key, in encrypted form, in the access token before signing the access token, or - including the session key in the access token and then encrypting and signing the access token. Petition 870250086872, dated 09 / 25 / 2025, p. 52 / 110 3 / 4 9. A method, according to any one of claims 6 to 8, characterized in that the session key is generated exclusively for said communication session.

10. A method, executed by a content delivery network (200), for delivering content to a user device (300), characterized in that it comprises the steps of: - receiving (550) from a user device (300) at least one content request including an access token for the requested content and an authentication tag; - determining (554) a session key based on the received access token by performing a decryption; - verifying (558) the validity of the user device's authentication tag with the determined session key; and - transmitting (562) content data related to the requested content in response to the received content request, if the user device's authentication tag is valid, in a communication session.

11. Method according to claim 10, characterized in that the authentication tag includes at least one of - a digital signature of at least part of the content request, and - a hash value, in encrypted form, of at least part of the content request; and the step (558) of verifying the validity of the authentication tag includes at least one of: - verifying said digital signature with the session key; and - decrypting the hash value with the session key, calculating a hash value of at least part of the received content request and verifying whether the decrypted hash value and the calculated hash value correspond to each other.

12. Method, according to any one of claims 10 and 11, characterized in that it further comprises a step (552) for verifying the validity of the access token, wherein the step (562) for transmitting content data is performed only if the access token is valid.

13. User device characterized in that it is configured to execute the steps of the method, as defined in any one of claims 1 to 4.

14. Content service provider system, characterized in that it includes a DRM license server, configured to execute the steps of the method, as defined in any one of claims 5 to 9.

15. Content delivery network, characterized in that it is configured to execute the steps of the method, as defined in any one of claims 10 to 12. Petition 870250086872, dated 09 / 25 / 2025, pp. 54 / 110

Images