Method for receiving content in user equipment through CDN

Abstract

A method comprising the following steps performed by a user device (300): transmitting an access request to a content provider system (100) to access content; receiving an access token for the content from a content provider system (100), the access token comprising an encrypted session key and a digital rights management (DRM) license comprising the session key; and in a communication session, transmitting a content request including the received access token to a content delivery network, and in response, receiving content data of the requested content from the content delivery network; wherein the content request further comprises an authentication tag obtained by performing a cryptographic operation performed by a DRM client module (320) of the user device (300) that signs and / or encrypts input data based on at least a portion of the content request using a session key of the received DRM license.

Description

Technical Field

[0001] This disclosure relates to the field of streaming or sending digital content via content delivery networks. Background Technology

[0002] Many over-the-top (OTT) media service providers that supply digital content streaming services directly to end users via the Internet are using content delivery networks (i.e., CDNs) to deliver digital content to end users.

[0003] To prevent unauthorized user devices from accessing content, CDN access tokens can be generated by the service provider, sent to authorized user devices, and then used by the authorized user devices to request content from the content delivery network.

[0004] The main problem with CDN access tokens is that authorized user devices can share them with unauthorized user devices, which allows unauthorized user devices to use the service provider's CDN without valid authorization.

[0005] To address this issue, known solutions include binding CDN access tokens to the user's device's IP address. However, this solution is unsuitable, for example, if the user's device is moving from a Wi-Fi network to a mobile network. In this case, the user's device's IP address may change, potentially causing interruptions in content streaming sessions over the CDN and resulting in a poor user experience. In practice, service providers rarely use this solution.

[0006] The problem of shared, unauthorized CDN access tokens has existed for years, but it has only recently been recognized as a significant issue because access to and use of content is typically protected by an additional layer of authorization based on DRM (Digital Rights Management). Content can be encrypted, and the decryption key is embedded in and protected within a DRM license sent 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 recently been compromised. For example, a hacker can subscribe to a content streaming service from a legitimate service provider as a legitimate user, request content, and obtain a DRM license for the requested content. The hacker exploits weaknesses in the DRM license to extract the decryption key, decrypt it, and share it with multiple users, allowing them to access the content via the content delivery network without subscribing to a legitimate service provider. By sharing the DRM key used to decrypt the content, a pirated content server or portal can grant unauthorized users subscribed to a pirated service access to multiple pieces of content. Unauthorized users can then establish a content streaming session with the legitimate service provider's content delivery network, receive encrypted content segments, and decrypt them using the DRM key provided by the pirated service portal. Users of pirated services do not need to subscribe to content streaming services from legitimate service providers, nor do they need to generate additional network load for the content delivery network.

[0007] Due to recent hacking issues involving DRM licenses, access to content via content delivery networks by unauthorized users has become a major problem.

[0008] Therefore, it is necessary to improve this situation. Specifically, it is desirable to prevent unauthorized users from accessing content through the Content Delivery Network (CDN). Summary of the Invention

[0009] This disclosure relates to a method for receiving content in a user equipment, the method comprising the following steps performed by the user equipment:

[0010] Send an access request to the content provider's system to access the content;

[0011] Receive an access token for the content from the content provider's system, the access token comprising an encrypted session key and a Digital Rights Management (DRM) license including the session key; and

[0012] In a communication session, a content request, including the received access token, is sent to the content delivery network, and in response, the content data of the requested content is received from the content delivery network.

[0013] The content request also includes an authentication tag, which is obtained by performing a cryptographic operation performed by the DRM client module of the user device to sign and / or encrypt at least a portion of the input data based on the content request using the session key of the received DRM license.

[0014] According to this disclosure, DRM technology is used to bind access tokens to devices. The authentication tag is generated by the user device's DRM client module based on a DRM license embedded with a session key, and allows the user device to prove to the CDN that it has the right to access the session key. Furthermore, the user device acts as a relay to send the encrypted session key embedded within the access token received from the content provider's system to the CDN.

[0015] In one implementation, the cryptographic operation is used for:

[0016] - Sign at least a portion of the content request using the session key; and

[0017] - Encrypt at least a portion of the hash value of the content request using a session key.

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

[0019] In one implementation, the access request includes DRM license challenge data. Advantageously, the DRM license challenge data includes only user data, such as identification information of the user device (e.g., the user device identifier or UID (Unique Identifier) ​​of the user device). Advantageously, the DRM license challenge data included in the access request for accessing content is not specific to that content or to any content. It does not include content information.

[0020] This disclosure also relates to a method implemented by a content provider system, the method comprising the following steps:

[0021] - Receive access requests for content from user equipment;

[0022] - Generate a session key for a communication session used to receive requested content in a user device via a content delivery network.

[0023] - Generate an access token that includes the session key in encrypted form;

[0024] - A DRM license, including the session key, is generated by the DRM license server; and

[0025] - Send access tokens and DRM licenses to user devices.

[0026] The content provider system generates a session key for the communication session between the CDN and the user device, which is used to deliver content. If the user device requests the content from the CDN, the communication session can occur later.

[0027] Once generated, the session key is embedded within the DRM license sent to the user's device, allowing the DRM client module on the user's device to use it, for example, to sign and / or decrypt input data. This allows the session key to be securely sent to and used within the user's device. Furthermore, the session key is encrypted and then included in an access token, which is sent to the user's device to access the content. This access token is intended for use by the user's device to request content. This enables the content provider system to securely send the session key to the CDN via the user's device.

[0028] In one implementation, the access request for content includes DRM license challenge data, wherein the DRM license is generated based on the received DRM license challenge data. As previously indicated, the DRM license challenge data may include only user data, such as identification information of the user device, and may not be content-specific.

[0029] In one implementation, the step of generating an access token includes digitally signing the access token. This allows proof that the access token has been generated by the content provider's system, particularly when a user device requests content from the CDN using the access token.

[0030] For example, the steps to generate an access token may include:

[0031] - Encrypt the session key and include the encrypted session key in the access token before signing it, or

[0032] Include the session key in the access token, then encrypt and sign the access token.

[0033] Advantageously, the session key is generated uniquely for the communication session.

[0034] This disclosure also relates to a method for delivering content to a user device, performed by a content delivery network, the method comprising the following steps:

[0035] - Receive at least one content request from a user device, the at least one content request including an authentication tag and an access token for the requested content;

[0036] - By performing decryption, the session key is determined based on the received access token;

[0037] - Use the determined session key to check the validity of the user equipment's authentication tag; and

[0038] - In a communication session, if the authentication tag of the user equipment is valid, content data related to the requested content is sent in response to the received content request.

[0039] If a CDN receives a content request from a user's device, it can extract the session key from the access token within the content request by performing a decryption operation. If the session key has already been encrypted and then included in the access token, the CDN extracts the encrypted session key from the access token and then decrypts it. If the session key was already included in plaintext in the access token before it was encrypted, the CDN decrypts the access token and then extracts the session key.

[0040] Once the session key has been extracted from the access token, the CDN uses it to check the validity of the authentication tag. The CDN can check whether the user device that has received the authentication tag from it also has the right to access the same session key.

[0041] Certification labels may include at least one of the following:

[0042] - A digital signature of at least a portion of the content request, and

[0043] - A hash value in encrypted form of at least a portion of the content request; and

[0044] The steps to verify the validity of an authentication label may include at least one of the following:

[0045] - Verify the digital signature using the session key; and

[0046] - Use the session key to decrypt the hash value, calculate the hash value of at least a portion of the received content request, and check whether the decrypted hash value and the calculated hash value match each other.

[0047] In one implementation, the method may further include a step of checking the validity of the access token, wherein the step of sending content data is performed only if the access token is valid.

[0048] In this way, a CDN can check whether an access token has been generated by the content provider system, for example, based on the signature of the access token calculated by the content provider system.

[0049] This disclosure also relates to:

[0050] - User equipment, configured to perform steps of a previously defined method;

[0051] - Includes a content service provider system with a DRM license server, configured to perform the steps of a previously defined method;

[0052] - A content delivery network configured to perform steps of a previously defined method. Attached Figure Description

[0053] Other features, objects, and advantages of this disclosure will become clearer from the detailed description of the non-limiting embodiments with reference to the accompanying drawings.

[0054] Figure 1 A distributed system for providing digital content to multiple user devices, according to one embodiment, is shown.

[0055] Figure 2 A simplified block diagram of a method for delivering digital content to a user device according to one embodiment is shown.

[0056] Figure 3 An embodiment is shown. Figure 2 The communication diagram of the INIT method's configuration phase.

[0057] Figure 4 An embodiment is shown. Figure 2 The method of obtaining content information in the communication diagram of stage A is to access the content.

[0058] Figure 5 An embodiment is shown. Figure 2 The method's content reception phase B communication diagram. Detailed Implementation

[0059] The various features and functions of the disclosed systems and methods are described in detail below with reference to the accompanying drawings. In the drawings, similar symbols identify similar components unless the context otherwise requires. The illustrative embodiments of the systems, apparatus, and methods described herein are not intended to be limiting. Those skilled in the art will readily understand that certain aspects of the disclosed systems, apparatus, and methods can be arranged and combined in a variety of different configurations, all of which are envisioned herein.

[0060] Figure 1A distributed system 1000 for providing digital content to multiple user devices 300 is illustrated. System 1000 includes a content provider system or content provider backend 100 and a content delivery network (CDN) 200. User devices 300 are connected to the content provider system 100 and the content delivery network 200 via one or more communication networks 400, including, for example, the Internet. The content provider system 100 is connected to the content delivery network 200 via one or more communication channels or networks.

[0061] The content provider system or backend 100 assumes the role of managing access to digital content. In one implementation, 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 also include another DRM license server 135 and a data analytics server or system 150.

[0062] The content provider system or backend 100 supplies content services, such as content streaming services, to user device 300 and provides user device 300 with access to the content, which is delivered to user device 300 by CDN 200. Digital content can be video, audio, text files, software, games, or any other type of data.

[0063] User equipment 300 can interact with the user interface 140 (such as a website) of content provider system 100 via a communication network (e.g., the Internet) 400 to authenticate itself, receive information about available content, request access to given content, and receive content access data, such as a content access token, also known as a CDN access token, for accessing the requested content via content delivery network 200. For example, user interface 140 is implemented using a CMS API (Application Programming Interface) as part of backend 100, and user equipment 300 includes applications that may contain front-end applications or code configured to make network service calls to the CMS API.

[0064] Content management system 110 is configured to manage digital content and provide access to the digital content to user device 300. In one embodiment, content management system 110 is configured to provide access to digital content on user interface 140 to user device 300 (e.g., a website visitor).

[0065] The content management system 110 is also configured to manage, for example, client or user information (e.g., user or client subscriptions) for clients or users who have subscribed to content services.

[0066] Subscribers to the content services provided by System 100 can be referred to as clients. Client accounts can be assigned to each client by the content provider System 100. Clients can log in to their client accounts using user device 300 by performing an authentication process based on client credentials (e.g., a combination of user ID and password, biometric data, etc.). Clients may have the right to log in to their client accounts using different user devices.

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

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

[0069] Furthermore, in this disclosure, the content management system 110 is configured to generate session information for a communication session between the content delivery network 200 and the user equipment 300 for delivering content to the user equipment 300.

[0070] A communication session between the content delivery network 200 and the user equipment 300 for delivering content to the user equipment 300 can be characterized by various parameters or metadata such as:

[0071] - User information, including, for example, user or client identification information (e.g., user ID), and / or user device information, including, for example, user device identification information.

[0072] -Including content information such as content identification information or content identifiers, and

[0073] -Optional time information, which includes, for example, timestamp data (e.g., timestamp data indicating when user device 300 requested content from content provider system 100) and optionally, for example, the expiration duration of the session starting from the time when user device 300 requested content from content provider system 100.

[0074] Session information generated for a communication session used to receive requested content from CDN 200 in user equipment 300 includes a session key and a session identifier or session ID optionally associated with the session key.

[0075] A session key is a cryptographic key, such as a symmetric key, intended for use by user equipment 300 and CDN 200 in a communication session. It is generated by content provider system 100, for example, by content management system 110. A session key can be uniquely generated for a single communication session between CDN 200 and user equipment 300 for receiving requested content. Advantageously, session keys generated for different communication sessions between CDN 200 and different user equipment 300 are different from each other.

[0076] A session identifier, or session ID, allows the identification of a communication session, particularly when several sessions exist between user equipment 300 and content delivery network 200. A session identifier uniquely identifies a communication session. However, the use of a session identifier is optional.

[0077] In one implementation, the content provider system 100 may use several 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's consider that the content provider system 100 uses N content delivery networks, where N > 1. In this case, the content provider system 100 is configured to generate N different session keys and N different CDN access tokens for N communication sessions between the N content delivery networks and the requesting user device 300, respectively.

[0078] The content management system 110 is implemented using both software and hardware. In one implementation, 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 method 500.

[0079] In one implementation, a DRM license server or DRM server 130 is connected to the content management system 110 via a local connection or communication network. It can be configured to generate DRM licenses for session keys. The session key is intended for use in communication sessions between the content delivery network 200 and the user device 300 to deliver user-requested content to the user device 300. The DRM license for the session key is a data structure that includes, for example, the session key in encrypted form. For example, the session key is encrypted using a key bound to the requesting user device 300. The session key is securely embedded in or included in the DRM license, for example, through encryption.

[0080] A DRM license for a session key may also include usage rules and / or metadata. In one implementation, the DRM license includes usage rules that indicate that the session key is authorized for use in encryption and / or signing. Optionally, the DRM license includes a session identifier in the metadata.

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

[0082] In one implementation, the DRM license server or DRM server 135 is also connected to the content management system 110 via a local connection or communication network. It can be configured to generate DRM licenses for digital content. As is known to those skilled in the art, a DRM license for one or more pieces of content is a data structure that includes a cryptographic key or content key in an encrypted form for decrypting one or more pieces of digital content. A DRM license may include other data, such as usage rules. For example, usage rules are rules that authorize only the decryption of one or more pieces of content using the content key.

[0083] In this embodiment, the DRM server 130 for protecting the session key and the DRM server 135 for protecting the content key are two separate DRM servers dedicated to the session key and the content key, respectively.

[0084] DRM server 130 and DRM server 135 can use different DRM implementations or technologies for session keys and content keys, respectively.

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

[0086] Content management system 110 can perform an authorization operation to obtain a DRM license for the content requested by the user from DRM server 130 or DRM server 135. Alternatively, DRM server 130 and / or DRM server 135 can perform the authorization operation.

[0087] DRM server 130 can be as follows: Figure 1 The individual entity shown, or it can be combined with the content management system 110. Similarly, the DRM server 135 can be, as shown... Figure 1 The individual entity shown, or it may be combined with the content management system 110.

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

[0089] The content management system 110 can perform authorization or authentication operations to obtain a CDN access token for the content requested by the user from the CDN access token generator 120. Alternatively, the CDN access token generator 120 can perform authorization or authentication operations. In either case, it is advantageous to perform authentication and authorization operations before delivering the CDN access token or other data from the content provider system 100 to the user device 300.

[0090] A CDN access token generated for a given piece of content is bound to information about the content for which it provides access. In one implementation, the CDN access token is bound to a network address (such as a URL) of the content, for example, to the network address or URL of a directory or storage location in CDN 200 that stores the content data of the content (e.g., content manifest files, content segments or blocks, and any other resources required to use or play the content). The URL of this directory or storage location may be specified as a "content base URL".

[0091] In one implementation, the URLs of all content-related data (e.g., the URLs of the content manifest and the URLs of content segments or blocks) can be derived from the content's base URL. The following provides illustrative examples of different URLs for a given piece of content named "mycontent":

[0092] - Basic URL of the content: https: / / cdn.domain.com / mycontent /

[0093] - Manifest URL: https: / / cdn.domain.com / mycontent / manifest.mpd

[0094] - First video clip of the content: https: / / cdn.domain.com / mycontent / video-sd / 1.mp4

[0095] There are different ways to bind CDN access tokens to the network address of content, which will be described later.

[0096] CDN access tokens can be signed using a cryptographic key of the content provider system 100. This cryptographic key can be the private key of a pair of public and private asymmetric keys of the content provider system 100. Alternatively, the cryptographic key can be a secret symmetric key shared by the content provider system 100 and the content delivery network 200.

[0097] Furthermore, in this disclosure, the CDN access token contains session information about a communication session between the content delivery network 200 and the user equipment 300, for delivering content for which the CDN access token provides access. This communication session can occur in the future to deliver content (i.e., content for which a CDN access token has already been generated) to the user equipment 300 via the content delivery network 200. The session information includes a session key in encrypted form, and optionally includes a session identifier assigned to the communication session. In the CDN access token, the session key is encrypted using a cryptographic key. In one exemplary embodiment, the cryptographic key used to encrypt the session key in the CDN access token is a secret symmetric key shared by the CDN access token generator 120 and the content delivery network 200. Alternatively, the cryptographic key can be asymmetric, i.e., the private key in a pair of private and public keys of the CDN access generator 120. In this case, the CDN 200 can access the public key certificate of the public key.

[0098] In another implementation, the CDN access token is encrypted by the CDN access generator 120 using a cryptographic key (e.g., a symmetric key shared by the CDN access generator 120 and CDN 200, or a private asymmetric key associated with a public key accessible to the CDN). In this case, the session key is encrypted through the encryption of the CDN access token.

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

[0100] CDN access token generator 120 can be as follows: Figure 1 The individual entity shown, or it may be combined with the content management system 110.

[0101] Data analytics server 150 plays the role of recording or logging information and / or parameters of communication sessions configured by content provider system 100 for delivering requested content to user device 300 via content delivery network 200. The recorded information or parameters regarding the communication session may include at least a portion of session identifier, user information (e.g., user or client identifier), user device information (e.g., user device identifier), content information (e.g., content identifier), and time information (e.g., timestamp data indicating when the user device requested the content and optionally an expiration duration). In the event of problems with the communication session, the recorded information about the communication session can be used later, for example, to cancel the communication session. The timestamp data and optionally an expiration duration can be used to temporally restrict access to the requested content by user device 300. These can be directly implemented by CDN 200.

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

[0103] Content delivery network 200 is a geographically distributed network of edge nodes or servers 210. It has the capability to deliver or send digital content to user equipment 300 via edge nodes 210. As is known, content delivery network 200 may also include CDN origin servers (not shown) that have the capability to receive content from content provider system 100 and cache it in each of the multiple CDN edge servers or nodes 210.

[0104] Digital content can be encrypted. It can also be segmented or divided into content segments or blocks. Content segments or blocks can be associated with playlist or rundown files, as described later.

[0105] In one implementation, the content delivery network 200 may further include a configuration database 220, a configuration server 230, and an undo list management server 240.

[0106] Configuration server 230 assumes the role of managing key data shared or agreed upon by CDN 200 and content provider system 100.

[0107] The revocation list management server 240 is responsible for creating and updating revocation lists that include the identifiers of revoked sessions.

[0108] The configuration database 220 is used to store key data and revocation lists agreed upon by the CDN 200 and the content provider system 100. It can be accessed by the edge node 210.

[0109] In one implementation, content delivery to user equipment 300 via CDN 200 is based on access data (e.g., a CDN access token) received from content provider system 100. In operation, user equipment 300 may initially interact with content provider system 100, for example via user interface 140, request access to given content from content provider system 100, receive access data (e.g., a CDN access token) from content provider system 100 for the requested content, and then receive the requested content from content delivery network 200 based on the received access data (e.g., the CDN access token). The received content may require decryption using the content's DRM license, as described later.

[0110] Although shown separately, configuration database 220, configuration server 230, and undo list management server 240 and / or other databases and servers can be combined. Entities 220, 230, 240, and / or other servers can be computing devices and may include memory for storing data and also storing computer-executable instructions that, when executed by one or more processors, cause the server to perform the steps described herein.

[0111] User equipment 300 can be any type of user equipment or user gear 300, including computers, laptops, PCs, desktop computers, smartphones, tablets, etc. However, the term "user equipment" should be interpreted broadly to cover any computing device.

[0112] Although user equipment 300 is Figure 1 The example is illustrated as a smartphone, but as discussed above, other implementations are possible. Therefore, the example smartphone 300 is not intended to be limiting.

[0113] User equipment 300 is configured to interact with content provider system 100 to request access to digital content, and then obtain or receive the requested content through content delivery network 200.

[0114] In one implementation, user equipment 300 may include a content access module 310 (e.g., a content player module) and a content decryption module 320, such as... Figure 3 exemplified.

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

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

[0117] User equipment 300's DRM client module 320 and DRM servers 130 and 135 use the same DRM technology, such as Widevine. ® Or PlayReady ® .

[0118] User equipment 300 can be implemented using hardware and software. It may include one or more processors, applications, and DRM clients. The operations, functions, and / or actions that user equipment 300 is configured to perform will be described in more detail in the description of method 500.

[0119] Figure 2 It is a simplified block diagram of a representation method 500 based on an implementation scheme. Figure 2 The method 500 shown presents an implementation of a method that can be used with, for example, a content provider system 100, a content delivery network 200, and a user device 300.

[0120] The operation of method 500 presented below is intended to be illustrative. Method 500 may include one or more operations, functions, or actions, as illustrated by one or more of the boxes and arrows. Although the boxes may be illustrated in a sequential order, in some cases these boxes may be executed in parallel, and / or in an order different from that described herein. Furthermore, various boxes may be combined into fewer boxes, divided into additional boxes, and / or removed based on desired implementation methods.

[0121] In addition to the methods 500 and other processes and methods disclosed herein, the flowchart illustrates the functionality and operation of one possible implementation of this embodiment. In this regard, each block may represent a module, segment, part of a manufacturing or operational process, or part of program code comprising one or more instructions executable by a processor to implement a specific logical function or step in the process. The program code may be stored on any type of computer-readable medium, such as a storage device including a disk or hard disk drive. Computer-readable media may include non-transitory computer-readable media, such as computer-readable media that store data for short periods of time, such as register memory, processor cache, and random access memory (RAM). Computer-readable media may also include non-transitory media, such as secondary or persistent long-term storage devices, such as read-only memory (ROM), optical or magnetic disks, and optical disc read-only memory (CD-ROM). Computer-readable media may also be any other volatile or non-volatile storage system. Computer-readable media can be considered, for example, a computer-readable storage medium or a tangible storage device.

[0122] In addition, for the method 500 disclosed herein and other processes and methods, each box may represent, for example, a circuit connected to perform a specific logical function in the process.

[0123] Method 500 may include methods for receiving or delivering digital content in user equipment 300.

[0124] Method 500 may include a configuration phase INIT, a content access acquisition phase A, a content delivery phase B, and optionally a session cancellation management phase C.

[0125] The configuration phase INIT may include Figure 3 Steps 502, 504, and 506 are shown.

[0126] In step 502, the content delivery network 200 and the content provider system 100 agree on key data. In one implementation, step 502 may be performed by the configuration logic module 230 of the CDN 200 and the content management system 110 of the content provider system 100.

[0127] In one implementation, the agreed-upon key data may include two key sets: one key set for the authenticity of the CDN access token, and another key set for the confidentiality of the session key. Different cryptographic schemes or algorithms based on symmetric or asymmetric keys are possible for each key set.

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

[0129] In this embodiment, which is merely illustrative and not restrictive, the agreed data includes a cryptographic key k1 used for the confidentiality of the session key (in other words, for encrypting the session key). The cryptographic key k1 may be a secret symmetric key shared between the content delivery network 200 and the content provider system 100. In step 504, it may be stored in the configuration database 220 of the content delivery network 200, and in step 506, it may be stored in the memory of the CDN access token generator 120 and / or the memory of the content management system 110.

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

[0131] In this implementation, the agreed key data may further include a pair of asymmetric keys used for the authenticity (integrity) of the CDN access token (i.e., for signing and verifying the signature of the CDN access token), wherein the pair of asymmetric keys includes a public key K2. pub and private key K2 pr Private key K2 pr It can be stored in the memory of the CDN access token generator 120 and / or the memory of the content management system 110. The public key certificate, including public key K2, can be stored in the configuration database 220 of the content delivery network 200. pub And about key K2 pub and K2 pr The owner's information and the certificate authority's signature.

[0132] 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 for signing and verifying CDN access tokens. This secret key may be stored in the configuration database 220 of the CDN 200, the memory of the CDN access token generator 120, and / or the memory of the content management system 110.

[0133] The key data (here, secret key k1 and public key K2) stored in database 220 pub and / or public key K2 pub The certificate can be accessed by the edge node 210 of CDN 200.

[0134] The configuration phase, including steps 502 to 506, can be performed periodically (e.g., once a day).

[0135] Phase A of content access acquisition

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

[0137] In step 508 (optionally), user equipment 300 may interact with the user interface (e.g., a website) of content management system 110 to inquire about and / or receive information about digital content available on user interface 140. Step 508 may be performed by module 310.

[0138] At step 510, method 500 includes DRM client module 320 generating, for example, DRM license challenge data or DRM challenge data upon request and providing it to content player module 310. The DRM challenge data may include all the data required by license server 130 to create a license and handle license revocation. The generated DRM license challenge data may include information about user device 300, such as a unique device identifier and, optionally, device model and version. The DRM challenge data may also include a device digital certificate comprising the public key of a pair of public and private asymmetric keys for user device 300. The DRM challenge data is not content-specific. In other words, it does not contain any information about the content. In one embodiment, it contains only information about user device 300, or more generally, user data. The DRM challenge format is specific to DRM technology. The DRM license challenge data may be digitally signed by DRM client module 320 to prevent alteration of the conversion.

[0139] Then, in step 512, user equipment 300 requests access to the given content from content provider system 100. For this purpose, module 310 sends the access request for the given content along with the DRM license challenge data generated at 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 combination of user identifier and password, or biometric data, etc.). Alternatively, instead of user credentials, the access request may include a user access token previously received by user equipment 300 from content provider system 100 during a login operation. The access request also includes information identifying the requested content, such as a content identifier (ID). The access request may also include the DRM license challenge data generated at step 510. Alternatively, the DRM license challenge data may be sent separately (i.e., not in the request). The access request may be a request for the address (such as a content URL) of the requested content on CDN 200. For example, the access request may have the following simplified form:

[0140] Retrieve the content URL (user credentials, DRM challenge data, content ID).

[0141] It should be noted that before requesting access to the content from the content provider system 100 in step 512, DRM license challenge data is generated or provided by the DRM client module 320 in step 510.

[0142] The content management system 110 receives an access request from the user equipment 300 (step 512).

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

[0144] In step 516, if user equipment 300 has been authorized to access 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 use in a communication session that may soon begin between content delivery network 200 and user equipment 300 to receive the requested content. The generated session information may be associated with session parameters or metadata, including, for example:

[0145] - Information about the user, such as the user identifier, and / or information about the user device 300, such as the user device identifier.

[0146] - Information about the requested content, such as content identifiers.

[0147] -And optionally, timestamp data indicating when the access request has been received by the content management system 110 and the expiration duration.

[0148] A session key and associated session parameters or metadata (session ID, user and / or device ID, content ID, timestamp data) are assigned to the communication session between CDN 200 and user device 300 to enable user device 300 to receive the requested content from CDN 200. The session key and associated metadata may be sent to analytics server 150.

[0149] A session identifier uniquely identifies a communication session between CDN 200 and user equipment 300 for receiving requested content. In one implementation, the session identifier is randomly generated.

[0150] The session key is specific and unique for a communication session (e.g., a streaming session) between CDN 200 and user equipment 300 for receiving requested content. The communication session is identified, for example, by a content identifier, a user equipment identifier, and optionally timestamp data. In one implementation, the session key is randomly generated. For example, the session key is x bits of binary code (e.g., x = 128 or 256, which is merely an illustrative and not limiting example).

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

[0152] A CDN access token granting access to given content comprises data and a signature. For example, a CDN access token can be implemented as a JSON (JavaScript Object Notation) structure, such as a JSON Web Token (JWT), or it can consist of simple text. It is bound to the network address on the CDN 200 of the requested content, which is, in this case, a URL. For example, it is bound to the content's base URL. As previously indicated, there are different ways to bind a CDN access token to the network address or URL of the content it provides access to. The following list provides non-limiting examples of such bindings when the content URL is used as the content network address:

[0153] - The content URL is included in the CDN access token;

[0154] - The hash value of the content URL is included in the CDN access token;

[0155] - The hash value of the content URL is included in the calculation of the CDN access token signature without copying the hash value into the CDN access token itself. This has the advantage of reducing the size of the CDN access token, since the CDN access token needs to be included in the CDN content request to be usable anyway, and the CDN content request includes the content URL.

[0156] Furthermore, in this disclosure, the CDN access token also includes a session key in encrypted form generated in step 516, and optionally a session identifier.

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

[0158] Furthermore, to ensure the authenticity (integrity) of the CDN access token, the CDN access token, including the encrypted session key, is generated by the CDN access token generator 120, for example, using the private key K2. pr Come sign here.

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

[0160] Alternatively, a cryptographic scheme or algorithm that provides both authenticity (integrity) and confidentiality and uses a single key set can be used. The key set 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 of 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 CDN access token generator 120 using the secret symmetric key or private asymmetric key. In this case, the session key is encrypted through the encryption of the CDN access token.

[0161] Then in step 522, the access token generator 120 sends the generated CDN access token to the content management system 110.

[0162] In step 524, the content management system 110 requests the DRM license server 130 to create a DRM license for the session key. This request may include the DRM challenge data received from the user equipment 300 in step 512, the session key, and optionally a session identifier. Step 524 may be performed before or in parallel with step 518.

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

[0164] Use rules indicate to the DRM client what purpose they intend or permit the session key to be used. For example, a use rule may indicate that the session key can only be used by the DRM client to sign and / or encrypt input data. Optionally, the use rule may include an expiration date that coincides with or is aligned with the expiration date of the CDN access token. Other use rules can be implemented for the session key.

[0165] Metadata may include a session identifier. This session identifier does not need to be encrypted. Moreover, it is optional.

[0166] Then, in step 528, the DRM server 130 sends the generated DRM license to the content management system 110.

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

[0168] The CDN access token and the DRM license sent are associated with or paired with each other because they both include the same session key in encrypted form and the same session identifier (optionally) that 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 in the DRM license, which is different from the first encrypted form.

[0169] In this implementation, in order to have access to multiple contents, for example, X contents, the user equipment 300 sends X access requests to the content provider system 100, one access request for each content (each access request includes a content ID of the requested content), and receives X pairs of CDN access tokens and DRM licenses for X session keys respectively.

[0170] Alternatively, user equipment 300 may send an access request to content provider system 100 for multiple pieces of content (e.g., for X pieces of content). In this case, the access request may include N content identifiers, each for one of the N pieces of content. In response, content provider system 100 may send N sets or N pairs of CDN access tokens and DRM licenses for each of the N pieces of content, each set containing N different session keys.

[0171] In step 532, 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 in the analysis server 150. The recorded information includes, for example, a session identifier and parameters or metadata corresponding to the communication session. These parameters or metadata may include user identifiers, user device identifiers, content identifiers, and / or timestamp data.

[0172] In step 534, the content module 310 (e.g., a player module) receives the DRM license and CDN access token, and in step 535, the DRM license is imported into the DRM client module 320. After the DRM license is imported into the DRM client module 320, the session key can be used by the DRM client module 320 to sign and / or encrypt the input data (i.e., the data input into the DRM client module 320).

[0173] Although, as discussed above, the communication session to be initiated between user equipment 300 and CDN 200 is identified by a session identifier, other implementations that do not use session identifiers to identify communication sessions are possible. Therefore, the examples of session identifiers are not intended to be limiting.

[0174] Phase B of content delivery or streaming

[0175] Following phase A, method 500 includes phase B, wherein user equipment 300 downloads or receives requested content from content delivery network 200 upon request during a communication session (e.g., a playback session of requested content) between CDN 200 and user equipment 300.

[0176] Phase B can be implemented after the user equipment 300 receives the CDN access token and DRM license, preferably upon receipt of them.

[0177] Phase B includes step 540, performed by user equipment 300, which generates one or more CDN content requests to request content data for the requested content.

[0178] An initial CDN content request can request a manifest or playlist file for the requested content. Subsequent CDN content requests can then be based on the manifest file to request the content segments, chunks, and / or other resources needed to use or play the requested content.

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

[0180] At box 542, step 540 includes module 310 creating, preparing, or editing a CDN content request. A CDN content request may include the following elements:

[0181] - Network addresses, such as the URL of the requested content data (e.g., manifest files, content segments, chunks, other resources required to use or play the content), and

[0182] - Such as the CDN access token for the requested content previously received from the content provider system 100 (step 530).

[0183] The CDN access token included in the CDN content request includes a session key in encrypted form, such as one received from the content provider system 100 (either through specific encryption of the session key or through encryption of the CDN access token).

[0184] Furthermore, at block 546, step 540 includes module 310 obtaining an authentication tag by performing a cryptographic operation performed by DRM client module 320 to sign and / or encrypt input data based on at least a portion of a content request using the session key of the received DRM license. In other words, DRM client module 320 performs signing and / or encryption operations on input data based on at least a portion of a CDN content request using the session key of the DRM license to generate an authentication tag. At block 544, input data is provided by module 310 to DRM module 320.

[0185] Depending on the implementation, the input data may include a CDN content request, a portion of a CDN content request, or a cascade of different elements or components of a CDN content request. For example, the input data may include a network address or URL embedded in the CDN content request. Optionally, it may also include one or more headers of the CDN content request, such as a "userAgent" header, and / or query parameters of the CDN content request. If the input data includes different elements, such as a URL, one or more headers, and query parameters, those different elements may be cascaded before being provided as input data to the DRM client module 320.

[0186] In one variant, the input data provided to the DRM client module 320 at box 544 includes hash values ​​of the data described above (e.g., hash values ​​of CDN content requests, or hash values ​​of a portion of a CDN content request, or hash values ​​of concatenated different elements or components of a CDN content request). The hash values ​​may be calculated by a processing or computing component of the user equipment 300 outside the DRM client module 320.

[0187] Then, in step 546, the DRM client module 320 uses the DRM license, which includes the session key and has been previously imported (step 535), to sign and / or encrypt the received input data.

[0188] In implementations where the input data includes a CDN content request, a portion of a CDN content request, or a cascade of different elements of a CDN content request, the input data is advantageously signed by the DRM client module 320 using a session key. For example, a cryptographic function such as HMAC (Hash-Based Message Authentication Code) is used to sign the input data. In this case, an authentication tag includes the signature of the input data.

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

[0190] Therefore, the output of the signing or encryption operation performed by the DRM client module 320 in step 546 includes a signed and / or encrypted hash value as an authentication tag. In step 548, this output is returned to module 310.

[0191] In one implementation, the authentication tag may include both a signature of at least a portion of the content request and an encrypted hash of at least a portion of the content request.

[0192] Then, in step 542 of preparing the CDN content request, module 310 includes an authentication tag in the CDN content request, which includes the signature and / or encrypted hash value generated in step 546. Therefore, the CDN content request includes the network address (e.g., URL) of the requested content data, such as a CDN access token received from the content management system 110, and an authentication tag calculated by the DRM client module 320 using a session key. For example, the CDN content request may take the form of an HTTP request, which includes a URL with query parameters and headers. The CDN access token and authentication tag may be provided as query parameters or headers of the HTTP request.

[0193] Then, in step 550, module 310 sends a CDN content request to edge node 210 of CDN 200. Therefore, edge node 210 receives a CDN content request including the requested content network address or content URL, a CDN access token, and an authentication tag.

[0194] In step 552, edge node 210 checks the validity of the CDN access token.

[0195] 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 has already utilized the private key K2 of content provider system 100... pr To sign, edge node 210 uses the associated public key K2. pub To check the signature. If the CDN access token has been signed using a secret symmetric key shared by the content provider system 100 and CDN 200, the edge node 210 uses that shared secret key to check the signature.

[0196] Furthermore, edge node 210 can verify whether the content granted access by the CDN access token matches the content requested in the CDN content request. The method of implementing this verification depends on how the CDN access token is constructed. An illustrative example is given below:

[0197] - If the content URL is included in the CDN access token, the edge node 210 is configured to compare the content URL in the CDN access token with the content URL in the CDN content request, and if the two URLs match, grant access to the content to the user device.

[0198] - If the hash value of the content URL is included in the CDN access token, the edge node 210 is configured to compare the hash value from the CDN access token with the hash value calculated from the content URL of the CDN content request, and if the two hash values ​​match, grant access to the content.

[0199] - If the hash value of the content URL is included in the calculation of the CDN access token signature, the edge node 210 is configured to verify the signature of the CDN access token by using the hash value of the content URL from the CDN content request.

[0200] If the CDN access token is valid (i.e., the signature has been successfully verified, and the content granted access by the CDN access token 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, in step 554, edge node 210 can extract the encrypted session key from the CDN access token. Then, in step 556, edge node 210 decrypts the session key, for example, using a secret key k1 shared by content provider system 100 and CDN 200. In another embodiment, edge node 210 uses the public key of content provider system 100 to decrypt the session key.

[0201] In another implementation where the CDN access token has been encrypted by the content provider system 100, the edge node 210 can decrypt the CDN access token and then extract the session key from it. In this case, checking the validity of the CDN access token may include successfully decrypting the CDN access token.

[0202] If the CDN access token is invalid, the edge node 210 will deny the user device 300 access to the requested content and may send an error message to the user device 300.

[0203] Once decrypted (step 556), in step 558, the session key is then used by edge node 210 to check or verify the validity of the authentication tag for the CDN content request. If the authentication tag includes a signature of at least a portion of the content request, edge node 210 checks 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 a hash value based on the received CDN content request, and compares the decrypted hash value with the calculated hash value to check if they match, meaning the authentication tag is valid.

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

[0205] Optionally, if the authentication tag is valid, in step 560, edge node 210 may check whether the session identifier of the communication session between CDN 200 and requesting user equipment 300 has not been revoked. For example, edge node 210 may internally cache a revocation list of session identifiers for revoked communication sessions. The revocation list may be received from configuration database 220 and updated periodically. To check whether 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 user equipment 300 access to the requested content.

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

[0207] If access to the content requested by user device 300 is authorized, then in step 562, edge node 210 sends the requested content data (e.g., a content list or playlist file, content segments or blocks, or other resources required to use or play the requested content) to user device 300.

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

[0209] User equipment 300 may need to obtain a DRM license embedded with a content key for the requested content, for example, when the requested content is encrypted and / or its use is restricted by usage rules. In this embodiment, the DRM license for the requested content is delivered by DRM server 135, which is different from the DRM server 130 used to deliver the session key. User equipment 300 can receive the DRM license for the requested content from DRM server 135 in a known manner upon request. User equipment 300 can then decrypt content segments, blocks, and / or other resources in encrypted form of the requested content upon receipt. Decryption can be performed by DRM client module 320 using the DRM license received for the requested content.

[0210] Phase C of deregulation

[0211] The purpose of Phase C is to manage the revocation list, which includes session identifiers associated with communication sessions between the CDN 200 and user equipment that have been detected as invalid. Phase C is optional.

[0212] The anti-piracy system 500 is responsible for monitoring the communication or data flow between the CDN 200 and the user equipment 300, and optionally monitors the communication or data flow between the content provider system 100 and the user equipment 300 to detect pirated data flows. The anti-piracy system 500 may use watermark detection to detect pirated streams, or any other appropriate anti-piracy technology.

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

[0214] The revocation list management server 240 can update the revocation list by adding the received session identifier and record the updated revocation list in the configuration database 220 accessible to the edge node 210.

[0215] CDN edge node 210 can maintain a copy of the withdrawal list in its internal cache and update it periodically.

[0216] This method relies on a DRM system to prevent the use of CDN access tokens without using the session key provided by content provider system 100 to user device 300 and CDN 200 via user device 300. The session key is sent in encrypted form within a DRM license sent to user device 300. Therefore, the session key is DRM protected but can be used for signing and / or encryption operations performed by the DRM client module 320 of the user device. The session key is also sent in encrypted form to CDN 200 via user device 300 within the CDN access token. Within the CDN access token, the session key is protected by encryption using a key shared by content provider system 100 and CDN 200.

[0217] Ultimate considerations

[0218] Although an overview of the subject matter of the invention has been described with reference to specific example embodiments, various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the invention. For example, various embodiments of its features can be combined and matched or made optional by those skilled in the art. Therefore, the specific details should not be considered limiting, and the scope of the various embodiments is defined only by the appended claims and the full scope of their equivalents to which the claims are granted.

Claims

1. A method for receiving content in a user equipment (300), the method comprising the following steps performed by the user equipment (300): Send (512) an access request for accessing content to the content provider system (100); Receive (534) an access token for the content from the content provider system (100), the access token including an encrypted session key and a digital rights management (DRM) license including the session key; as well as In a communication session, a content request including the received access token is sent (550) to the content delivery network, and in response, the content data of the requested content is received (562) from the content delivery network. The content request further includes an authentication tag, which is obtained by performing a cryptographic operation (546) performed by the DRM client module (320) of the user equipment (300) to sign and / or encrypt input data based on at least a portion of the content request using the session key of the received DRM license.

2. The method according to claim 1, wherein the cryptographic operation (546) is used for: - Sign at least a portion of the content request using the session key; and - Encrypt at least a portion of the hash value of the content request using the session key.

3. The method according to claim 1 or 2, wherein the access request includes DRM license challenge data.

4. The method of claim 3, wherein the DRM license challenge data includes only user data.

5. A method implemented by a content provider system (100), the method comprising the following steps: - Receive access requests for content from user equipment (300); - Generate (516) a session key for a communication session used to receive the content in the user equipment (300) via a content delivery network (200). - Generate (520) an access token including the session key in encrypted form; - A DRM license including the session key is generated (526) by the DRM license server (130); as well as - Send (530) the access token and the DRM license to the user equipment (300).

6. The method of claim 5, wherein the access request for the content includes DRM license challenge data, and wherein the DRM license is generated based on the received DRM license challenge data.

7. The method of claim 5 or 6, wherein the step (520) of generating the access token includes digitally signing the access token.

8. The method of claim 7, wherein step (520) of generating the access token includes - Encrypt the session key and include the encrypted session key 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.

9. The method according to any one of claims 6 to 8, wherein the session key is uniquely generated for the communication session.

10. A method for delivering content to a user device (300) performed by a content delivery network (200), the method comprising the steps of: - Receive (550) at least one content request from user equipment (300), the at least one content request including an authentication tag and an access token for the requested content; - By performing decryption, the (554) session key is determined based on the received access token; - Use the determined session key to check the validity of the authentication tag of the user equipment (558); as well as - In a communication session, if the authentication tag of the user equipment is valid, in response to a received content request, send (562) content data related to the requested content.

11. The method of claim 10, wherein The certification label includes at least one of the following: - A digital signature of at least a portion of the content request, and - A hash value in encrypted form of at least a portion of the content request; and The step (558) of checking the validity of the certification label includes at least one of the following: - Use the session key to verify the digital signature; as well as - Use the session key to decrypt the hash value, calculate the hash value of at least a portion of the received content request, and check whether the decrypted hash value and the calculated hash value match each other.

12. The method according to any one of claims 10 and 11, the method further comprising the step (552) of checking the validity of the access token, wherein the step (562) of sending content data is performed only if the access token is valid.

13. A user equipment configured to perform the steps of the method according to any one of claims 1 to 4.

14. A content service provider system including a DRM license server, the content service provider system being configured to perform the steps of the method according to any one of claims 5 to 9.

15. A content delivery network configured to perform the steps of the method according to any one of claims 10 to 12.

Images