Multimedia content distribution method and associated system

Abstract

One aspect of the invention relates to a method for distributing multimedia content to a user device, the multimedia content being distributed by a service provider and owned by a content owner, access to the multimedia content being managed by a content provider, comprising: Storing (11), in a blockchain, a smart contract including a rule for distributing the multimedia content and a rule for creating a unique token; Distributing (13), by the content provider, a unique token for accessing the multimedia content to the user device; Distributing (14), by the service provider's server, the multimedia content to the user device; Executing the smart contract including: Storing (15), in the blockchain, a proof-of-read comprising the unique token and a secret; Verifying (16) whether the reading by the user device complies with the distribution rule. Figure to be published with the abstract: Figure 3

Description

Title of the invention: Method for distributing multimedia content and associated system. TECHNICAL FIELD OF THE INVENTION

[0001] The technical field of the invention is that of multimedia content distribution.

[0002] The present invention relates to a method of distributing content via a blockchain and in particular a distribution of content that reliably verifies predefined technical reading rules. TECHNOLOGICAL BACKGROUND OF THE INVENTION

[0003] With the democratization of digital content consumption, content distribution systems via computer networks, particularly the Internet, have become central to accessing information, entertainment, and education for billions of people worldwide. Key players in this process include content owners (COs), content providers (CPs), and service providers (SPs). The decentralized nature and multiplicity of these players have generated significant trust challenges among them.

[0004] Traditionally, content distribution involves contractual relationships between content owners and content providers, where content owners grant distribution licenses to content providers to make their content available to end users through the services provided by the service providers. However, this distribution chain is often subject to trust issues. Content providers can potentially violate the terms of license agreements by distributing content without authorization or by infringing the intellectual property rights of content owners. Similarly, service providers may advertise larger audiences than the audiences actually achieved.

[0005] A lack of transparency and traceability in content distribution transactions can lead to costly litigation, lost revenue for content owners, and disruptions for end users. Furthermore, traditional digital rights management (DRM) and content usage tracking mechanisms often prove insufficient to ensure secure content distribution and the equitable sharing of profits derived from such distribution.

[0006] Thus, there is a need for a content distribution system that guarantees trust between content owners, content providers and service providers. Summary of the invention

[0007] The invention offers a solution to the problems mentioned above, by proposing a content distribution method using a blockchain and at least one smart contract.

[0008] One aspect of the invention relates to a method for distributing at least one multimedia content to at least one user device, the user device being configured to consume the multimedia content, the multimedia content being distributed by a service provider, the multimedia content being owned by a content owner, access to the multimedia content being managed by at least one content provider, the method being implemented by a computer network comprising at least one server of at least one service provider storing the multimedia content, an application programming interface and the user device, the method comprising: • Store, in a blockchain deployed on the computer network: • at least one initial smart contract including at least one rule for distributing multimedia content and one rule for creating a unique token, • at least one metadata element associated with the multimedia content to be distributed, • at least one address of the multimedia content to be distributed, • Request access to multimedia content from the content provider via the user device, • Distribute, by the content provider, at least one unique token for accessing multimedia content to the user's device, the unique token having been constructed according to the unique token creation rule of the first smart contract, • Distribute multimedia content to the user's device via the service provider's server, • Execute the smart contract, which includes: • Store, in the blockchain, proof of reading the multimedia content by the user's device, the proof of reading including the user's device's unique token and at least one secret constructed from the multimedia content, • Check if playback by the user device complies with the multimedia content distribution rule and issue an indication of compliance with the multimedia content distribution rule to the content owner.

[0009] Thanks to the invention, certain trust barriers existing in the prior art are removed. Content can be distributed by service providers whom neither the content owner nor the content provider knows a priori, and whom they have no reason to trust. The service provider is assured that the content it relays and distributes is indeed content whose distribution has been authorized by the content owner. The invention also ensures that each distribution of content passing through these service providers complies with technical rules resulting from an agreement between the content owner and the content provider, and that all consumption of the content will be visible and analyzable to them.

[0010] Indeed, in the prior art, checks on compliance with content ownership (in English "infringement rules") are carried out randomly and manually (a human operator is needed to track down infringing use of the content), and are therefore not very effective, whereas the invention allows the content owner to be automatically informed of the violation of the content distribution rules and to automatically stop the distribution of the content.

[0011] The object of the invention is not a substitute for a known digital rights management (DRM) system, as its purpose is not to secure the content itself. However, the invention is indeed a digital rights management system in that it allows a rights holder or distributor to be automatically notified and to stop the distribution of content through a content provider and / or a service provider when such distribution violates content distribution rules. In this sense, although the invention does not physically encrypt the content, it enables the management of rights for one or more rights holders at the content distribution level.

[0012] By removing these trust locks, the invention allows a content owner to have their content distributed by more service providers than in the prior art, because it is certain that the content redistributed using the process according to the invention will comply with the predefined distribution rules.

[0013] In addition to the characteristics mentioned in the preceding paragraph, the distribution method according to one aspect of the invention may have one or more additional characteristics from among the following, considered individually or according to all technically possible combinations: • The rule for broadcasting multimedia content is a predetermined minimum broadcast quality. • The rule for broadcasting multimedia content is a predetermined minimum average broadcast bitrate. • The token is distributed to the user's device by the content provider. • The service provider does not have authorization to access the proof-of-read token stored in the blockchain. • at least one second smart contract is stored in the blockchain, the second smart contract comprising at least one media delivery agreement between the content owner and the content provider, the media delivery agreement comprising at least one media content identifier and at least one media content delivery rule. • multimedia content is distributed to a plurality of user devices and the number of consumers of the multimedia content is read in the proofs of reading stored in the blockchain. • Issuing an indication of compliance with the multimedia content distribution rule to the content owner includes issuing an alert to the content owner when the multimedia content distribution rule is not verified. • the content is distributed to multiple user devices, access to the multimedia content being managed by a plurality of content providers, the process being implemented by a computer network comprising at least one server for each service provider from among a plurality of service providers storing the multimedia content, and in which a plurality of contracts are stored in the blockchain, each smart contract comprising at least one rule for distributing the multimedia content and one rule for creating a unique token associated with one content provider from among the plurality of content providers and with one service provider from among the plurality of service providers.

[0014] Another aspect of the invention relates to a content delivery system comprising at least one server storing multimedia content, an application programming interface and a user device configured to consume the multimedia content, the system being characterized in that it is configured to implement the method according to the invention.

[0015] Another aspect of the invention relates to a computer program product comprising instructions which lead the system according to the invention to execute the process according to the invention.

[0016] Another aspect of the invention relates to a computer-readable medium on which the computer program according to the invention is recorded.

[0017] The invention finds in particular an interesting application in the distribution of paid sports content, which is currently a large-scale broadcasting ecosystem requiring strong trust between the actors.

[0018] The invention and its various applications will be better understood by reading the following description and examining the accompanying figures. BRIEF DESCRIPTION OF THE FIGURES

[0019] The figures are presented for illustrative purposes only and are in no way limiting of the invention. • Figure 1 shows a schematic representation of a content distribution method according to the invention, • Figure 2 shows a schematic representation of a content distribution system according to the invention, • Figure 3 shows a detailed schematic representation of a content distribution method according to the invention. DETAILED DESCRIPTION

[0020] Unless otherwise specified, the same element appearing on different figures has a unique reference.

[0021] Fig. 1 shows a schematic representation of a content distribution method according to the invention.

[0022] The multimedia content distribution method according to the invention implements a blockchain and at least one smart contract to ensure trust between network actors and in particular compliance with technical broadcasting rules.

[0023] A system configured to implement method 1 according to the invention is schematically represented in [Fig. 2]. Such a system is a communication network, i.e., the arrows represent communication links between entities, for example via the Internet protocol suite, or by any other electronic communication method. System 2 comprises a first computer server BC, configured to store a blockchain.

[0024] A blockchain, also known as a block chain, allows for the secure and immutable recording of transactions or data. A blockchain comprises a series of cryptographically linked and secured data blocks. Each block contains a set of verified and time-stamped transactions and is chronologically linked to previous blocks, thus forming a continuous chain. Transaction validation and the creation of new blocks are, for example, carried out by network participants through a process called "consensus." The blockchain ensures transparency, immutability, and security of the data recorded on it.

[0025] According to the invention, the blockchain comprises at least one smart contract. A smart contract is a self-executing agreement that runs within a blockchain network. Smart contracts include rules and conditions, which can be complex, to oversee transactions and interactions between participants. A smart contract is a software entity designed to be autonomous and capable of monitoring the predefined conditions of the agreement, collecting relevant data, and making real-time decisions based on these conditions. Through the use of the blockchain, the smart contract ensures the transparency, security, and immutability of contractual transactions, while minimizing the need for human intervention.

[0026] In a preferred embodiment of the invention, a blockchain is deployed on a computer server BC. A computer server BC is a computer. In other embodiments of the invention, the blockchain can be decentralized, that is, distributed across a plurality of computers.

[0027] The term "computer" refers to a device comprising at least one processor and one memory. The memory stores instructions which, when executed by the processor, cause the processor, and therefore the computer, to carry out the actions assigned to it. Thus, in the following description, when an action is attributed to a computer, this action is in fact encoded as instructions stored in the computer's memory and executed by the computer's processor.

[0028] A blockchain is "deployed" on a computer when the computer's memory stores the blockchain and an interface allows interaction with the blockchain stored by the computer. In the invention, such an interface is preferably an application programming interface, also called an API. The application programming interface allows interaction with the blockchain by reading the blockchain through read access, or by writing to the blockchain through write access. The blockchain can include many different parameters, allowing only certain actors to read and / or write, or allowing only certain actions. These parameters are predefined, meaning they are stored in at least one configuration file before the blockchain is used.

[0029] Preferably in the invention, the blockchain is a so-called "consortium" blockchain, that is, a blockchain whose access is limited to a certain number of selected entities or participants. This configuration makes it possible to benefit from several advantages of blockchains, such as transparency, security, and immutability, while offering better control over who can see certain data, who can participate in the network, and how consensus is reached.

[0030] When consensus is required, for example to perform blockchain validation, a preferred embodiment implements a Raft-type consensus. Such a consensus will not be described in this document because it is not central to the invention and because it is already known.

[0031] In the invention, at least one first type of smart contract is stored on the blockchain. Preferably, a second type of smart contract is also stored on the blockchain. Each smart contract created and stored on the blockchain, whether of the first or second type, is associated with a triplet of service provider (SP), content provider (CP), and content owner (CO). Thus, it is possible to create several different contracts for several content providers (CP) and / or several service providers (SP). Each contract created is associated with only one triplet of service provider (SP), content provider (CP), and content owner (CO), and to distribute the content via another service provider (SP) or another content provider (CP), another contract must be created.This ensures the confidentiality of data proving content consumption, and compliance with content distribution rules.

[0032] A first type of smart contract is a content access contract, for example, named ContentAccess. Such a smart content access contract specifies, for a given piece of content, at least one content distribution rule and at least one unique token creation rule. The content distribution rule is at least one technical rule related to a user reading the content. The unique token creation rule specifies a unique token generation method used to generate and distribute a token to the user reading the content.

[0033] A second type of smart contract is a broadcasting contract, for example called BroadcastSettlement. Such a broadcasting contract specifies various characteristics of an agreement between several actors for the broadcasting of content.

[0034] In the invention, smart contracts comprise classes and functions executable via an application programming interface. The application programming interface (API) can be used by each actor independently of the other actors. Each actor may have restricted access to the interface, having access to a limited number of functions, or may have full access to the interface. Preferably, each actor has restricted access to the interface and therefore to the blockchain and the smart contract functions.

[0035] Examples of functions and classes of each of the types of smart contracts will now be described.

[0036] In the invention, broadcast contracts Cl “BroadcastSettlement” must necessarily include at least one variable for identifying available content.

[0037] For example, broadcast contracts Cl “BroadcastSettlement” may include a class “Available Content” or “AvailableContent”, which may include, in particular: • A status of the content: broadcastable, available, unavailable • A content identifier, • A content owner (CO), • A content name, • A price linked to the content • A date the content was added, • An end date for the availability of the content.

[0038] The class presented above is only an example of a class and the invention covers of course any combination of the variables taken independently, as well as any other variable.

[0039] In the invention, broadcasting contracts Cl “BroadcastSettlement” must necessarily include at least functions for retrieving content, adding available content, and obtaining access to available content.

[0040] The smart broadcast contract Cl “BroadcastSettlement” includes, for example, the following functions: • Retrieve available content: “queryAllAvailableContent”, • Retrieve available content from a class variable: « queryAvailableContent, • Add content available on the blockchain “coAddAvailableContent”, • Obtain access to available content (for example, through a purchase) “cpBuyAccess”.

[0041] The functions presented above are only examples of function and the invention covers of course any combination of functions taken independently.

[0042] In the invention, the C2 ContentAccess contracts must necessarily include at least one variable for identifying the broadcast content, identifying the viewer and verifying the broadcast session.

[0043] For example, C2 Content Access contracts “ContentAccess” may include a “Content Distributed” or “ContentBeingSupplied” class, which may include, in particular: • Content status: currently being broadcast, not broadcast, unavailable • An identifier for the broadcast content, • A price linked to the content • A spectator identifier, • A verification of the broadcast session, • A release date for the content.

[0044] The class presented above is only an example of a class and the invention covers of course any combination of the variables taken independently, as well as any other variable.

[0045] In the invention, the C2 ContentAccess contracts must necessarily include at least functions for retrieving content, adding broadcastable content, adding a viewer, adding proof of broadcast, and verifying proof of broadcast.

[0046] The C2 smart contract for accessing content “ContentAccess” includes, for example, the following functions: • Retrieve the delivered content: “queryAllSuppliedContent”, • Retrieve content served from a variable of the class: “querySuppliedContent”, • Add broadcastable content from content available on the blockchain (by the content provider)* cpAddContent, • Add a viewer, with their ID and public key (provided by the content provider) “cpAddViewerldAndPublicKey”, • Add a proof of broadcast (by the service provider) “spAddViewershipProof”, • Verify the proof of delivery (by the content provider) “cpVerifyProof”.

[0047] The functions presented above are only examples of function and the invention covers of course any combination of functions taken independently.

[0048] The content distribution method 10 shown in [Fig.1] uses a blockchain deployed on a computer network, for example deployed on a server, as well as the two types of smart contracts defined previously.

[0049] The content distribution method 10 is also presented in more detail in [Fig. 3], which represents the exchanges between the actors of an embodiment of a method according to the invention. This method only shows the exchanges between a specific triplet of service provider SP, content provider CP, and content owner CO, but it can be duplicated to any triplet of service provider SP, content provider CP, and content owner CO defined in a smart contract stored in the blockchain.

[0050] The process 10 includes a first step 11 of adding new content to the content distribution system. This step 11 comprises several substeps 111 to 116.

[0051] A first substep 111 is a substep for storing new multimedia content in the blockchain. "Multimedia content" is understood to mean content in a media format such as text, image, video, audio, etc., used to present, for example, information or entertainment to a user. To this end, the (legal) owner of the multimedia content (OC) issues a request in step 111 to the blockchain, using the application programming interface (API). This request, for example, implements the "coAddContent" function of the broadcast contract Cl "BroadcastSettlement" described earlier. The multimedia content is not stored directly in the blockchain, but a reference to this multimedia content is stored in the blockchain in step Cil, during the execution of the "coAddContent" function by the smart broadcast contract.Thus, the blockchain stores at least one address of the multimedia content to be distributed and, preferably, at least one piece of metadata associated with that content. The address of the multimedia content to be distributed is, for example, an IP address (from the Internet Protocol suite). For instance, if the multimedia content is stored on a CP server in [Fig. 2], an address of the content on that CP server is stored on the blockchain. Metadata associated with the content is, for example, the storage size of the content (in bits or bytes), the duration of the content, a specific characteristic of the content, the owner of the content, the genre of the content, or any other metadata about the content.

[0052] In substeps 112 and 113, the content owner (CO) informs the content provider(s) (CP) of the existence of new content published on the blockchain. These two substeps, 112 and 113, can be automated, for example, via a smart contract (e.g., the broadcast contract) that monitors the addition of new content to the blockchain. This new content information can be published via the application programming interface (API) to the content provider(s) (CP), for example, through the use of a specific software application by the content provider(s) (CP).

[0053] In optional substeps 114 to 116, a broadcast agreement is reached between the content owner (CO), at least one content provider (CP), and at least one service provider (SP). This agreement is stored on the blockchain by the broadcast smart contract Cl, "BroadcastSettlement," in substep C12, which is not optional. This agreement defines, in particular, rules for broadcasting the content, and, for example, the remuneration of the various actors in the triplet: service provider (SP), content provider (CP), and content owner (CO). To reach this agreement, negotiations can take place off-chain or via the blockchain, for example, using an auction system.

[0054] In the invention, it is necessary to have at least one technical rule for content delivery associated with the content; therefore, step C12 is necessary. A content delivery rule includes at least one technical delivery rule, for example, a minimum delivery quality, for example, defined according to a minimum average delivery bitrate. Such a bitrate is, for example, expressed in megabytes per second. Other technical rules for content delivery may include, for example, a maximum number of content consumptions, a maximum number of simultaneous connections to the server delivering the content, a predefined level of security and encryption of the stream, a type of User Agent (defining the type of user devices: TV, computer, smartphone, etc.), a predefined Quality of Experience (QoE), content limitation by IP address geolocation, and content limitation by IP address blacklisting (anti-VPN).

[0055] In parallel with step 11, that is, possibly simultaneously with step 11 or before or after step 11, a user U registers, during steps Ull to U14, with a content provider CP. Such registration is, for example, a subscription to the service of the content provider CP, for example, to a remote viewing platform, or a registration for the service provided by the content provider CP, or even a purchase of content from the content provider CP. During a step Ull, the user uses a user device, for example, a computer, a smartphone, or a tablet, to issue a registration request. The user device is configured to consume multimedia content, that is, it includes at least one means of consuming the content, for example, a screen if the content includes photos or videos, a speaker if the content includes sound, etc.The user device also includes network communication means to receive multimedia content and send network requests. This request is received by an online application (APP) at stage U12, and transmitted at stages U13 and U14 to the content provider (CP), for example, to the CP's server. This allows the CP to know the user (U) and for the user (U) to use the content distribution service offered by the CP.

[0056] After (optional) registration of user U with the content provider CP, user U can request access to multimedia content added to the blockchain and belonging to a content owner CO, and offered by a content provider CP via the service provider SP with which user U is registered.

[0057] To achieve this, in step 12, several sub-steps are carried out.

[0058] First, user U uses their user device to request access to content at a substep 121, for example by selecting multimedia content from a plurality of multimedia content offered in the software application APP belonging, for example, to the service provider SP. The plurality of available multimedia content may have been retrieved by the service provider SP using a content retrieval function from the C2 content access smart contract.

[0059] In a substep 122, the online application APP, for example offered as a service via the internet, receives and transmits the request to the content provider CP, which has the authorization to provide the content as defined in the smart broadcast contract Cl.

[0060] The CP content provider receives the request at substep 123.

[0061] In response to the request received in substep 123, the content provider CP distributes a unique token in step 13. Such a unique token is also called a "secret." To distribute a unique token, step 13 comprises several substeps. In a first substep 131, the content provider CP sends the content distribution request via the content access smart contract C2, using the application programming interface (API), for example, by using a unique token generation function of the smart contract C2. The content access smart contract C2 generates such a unique token using a function it understands, the function being based on a generation rule it understands. For example, the unique token is generated following an asymmetric encryption principle: user U receives a private key, and the smart contract publishes a public key associated with user U on the blockchain.The private key is then the unique token. The private key is, for example, generated using elliptic curve cryptography (ECC). The public key, which allows verification of the signature generated with the private key (token), is stored on the blockchain, and the private key is stored locally, for example, on a server of the content provider CP. This private key, acting as a token, is distributed to the user in step 13, after their registration in step 11, to access the content.

[0062] The unique token generated by the smart contract C2 is then transmitted to the application APP that user U uses to access its content. The application APP receives this token in substep 132, and user U therefore possesses this unique token in substep 133. The application APP is, for example, a website in a web browser that uses, for example, a language such as JavaScript to store and manipulate user U's secret. An advantage of the invention is that the generated unique token never passes through the service provider SP or its servers, which therefore cannot create false broadcasts because it cannot declare a broadcast without the unique token, as will be described later.

[0063] After receiving authorization to access the content via the receipt of the unique token, user U will receive the multimedia content, for example in the form of a video stream broadcast in the APP application that he uses on his user device in step 14.

[0064] To this end, step 14 comprises a plurality of substeps 141 to 145. The application APP will first issue a content request in substep 141 to the service provider SP, i.e., to the server of the service provider SP. The service provider SP receives the request in substep 142 and checks whether the user U is registered with them (steps U11 to U14), then issues the multimedia content in substep 143 to the user U, who receives it in the application APP in substep 144 and plays the multimedia content in substep 145. The multimedia content was, for example, stored on the servers of the content provider CP, then transmitted to the server(s) of the service provider SP for distribution via the application APP.

[0065] A nonce is generated by the service provider SP (i.e., by its SP server) and accompanies the multimedia content during its transmission. This nonce will serve to create a signature to prove the presence of the service provider SP in the distribution of the multimedia content. In step 143, when the content is sent to user U, the service provider SP calls a function of the content access smart contract C2, using the application programming interface API, for example, using a nonce generation function of the smart contract C2. The content access smart contract C2 generates such a nonce using a function it understands, the function being based on a generation rule it understands, and transmits it to the application APP, or, alternatively, to the service provider SP so that it transmits the multimedia content concurrently with the nonce.

[0066] According to the invention, during viewing, i.e., during the distribution of the content, hardware execution traces are recorded. These hardware execution traces are, for example, and in any possible combination: an identifier of the user U who consumed the content, an identifier of their user device, an identifier of the application APP that distributed the content, an identifier of the browser in which the application APP was executed, an identifier of the distributed content, an average content distribution rate, an instantaneous content distribution rate, a content distribution timestamp, an identifier of the service provider SP that distributed the content to user U. A set of one or more of the hardware execution traces specified in the preceding sentence forms a content session, for example represented by a vector comprising, in each column, a value of the expected information.

[0067] Content sessions are generated and issued regularly by the APP application in step 15. These content sessions further include a signature of the nonce received from the service provider SP by the unique token of the user U, for example, by a predefined computer program. This allows all parties to verify that the service provider SP has indeed delivered the content because it provided the nonce, and that the user U was indeed authorized to consume the content because they possess both the nonce from the service provider SP and the unique token provided by the content provider.

[0068] Once the content sessions are generated, for example by the APP application, they are transmitted to be stored in the blockchain.

[0069] Two embodiments are possible at this stage. In a first embodiment, the content sessions are transmitted to the service provider SP, which is responsible, via its SP server and via the application programming interface API, for using the proof addition function of the content access smart contract C2 to store at step C23 the proof(s) of broadcasting which are the content sessions in the blockchain.

[0070] Alternatively, in a second embodiment shown in [Fig. 2], a PI proxy server is present and links to the BC server on which the blockchain is deployed. Such a PI proxy server is, for example, an HTTP proxy (for "HyperText Transfer Protocol"), and is therefore preferably a software application. One advantage of having a PI proxy server is the ability to perform authentication of the proof before it is stored in the blockchain, rather than after it is stored. Indeed, the proof (content session) received from the APP application includes the unique token signed by the nonce.The PI proxy server then has access to the public key associated with the private key (the unique token) and authenticates the proof (content session) by verifying the signature included in each content session. Before using the API, it uses the proof addition function of the C2 content access smart contract to store the broadcast proof(s) (content sessions) on the blockchain at step C23. This allows the PI proxy server to reject unsigned or incorrectly signed requests, such as requests for content access or proof storage. Another advantage of the PI proxy server is that it only uses the header portion of the transmitted packets, allowing the service provider (SP) to transparently broadcast its content using the actual data portion of the packets as it sees fit.Yet another advantage of the PI proxy server is that it allows you to modify the terms of smart contracts and apply these changes quickly and reliably, for example by rejecting any request. including the nonce of a service provider SP that has been excluded from a pre-existing broadcast contract.

[0071] The invention makes it possible to create, from the blockchain, lists of content sessions for each content broadcast by a triplet of service provider SP, content provider CP and content owner CO, and to verify the authenticity and technical compliance of the broadcast of the multimedia content.

[0072] Thus, the method 1 according to the invention includes a step 16 of verification of compliance with a technical rule included in a smart contract, by the smart contract for accessing content C2. This verification step 16 can be executed automatically on a regular basis, or following a request issued by one of the actors, mainly by the content owner CO or by the content provider CP, who are most likely to want to verify the authenticity of the stored evidence and compliance with the rules by the dissemination of the content.

[0073] This verification 16 includes a call to a function of the content access smart contract C2, using the application programming interface API, for example by calling a proof verification function of the smart contract C2. This proof verification function will verify the authenticity of the proof via the signature included in the proof, and will verify compliance with the rules defined in the content delivery smart contract Cl. To verify the authenticity of the proof, the same verification as that offered by the proxy server PI can be carried out.

[0074] To verify compliance with the rules, the smart contract function C2 can read the various hardware execution traces and compare them to the defined rules, or it can use the hardware execution traces to calculate a value that will be compared to the defined rules. For example, if a rule in the contract defines a minimum average bit rate, the smart contract function C2 can retrieve the average bit rate from the proof, or calculate an average bit rate and compare it to the minimum average bit rate of the contract C1. If the average bit rate exceeds the minimum average bit rate predefined in the contract, the rule is respected and the broadcast can be counted as a broadcast of the content, thus providing technical assurance to the content owner CO and / or the content provider CP regarding the exact number of broadcasts that complied with the defined technical rules, thereby enabling, for example, reliable counting and / or fair compensation for the various stakeholders.This allows us to count the number of consumers or consumptions of content that have complied with the distribution rules, obtained from the proofs of consumption stored in the blockchain.

[0075] The invention also optionally includes the issuance of an alert (not shown) when a broadcast does not comply with the rules of the broadcast contract Cl or when authentication is not verified. This alert is preferably issued For each content session whose verification fails, the content owner (CO), content provider (CP), and / or service provider (SP) can act quickly to prevent fraudulent distribution. This action can also be automated following a negative verification result; that is, the distribution of content for that session can be automatically stopped, for example, via the proxy server (PI) or by acting directly on one of the CP and / or SP servers.

Claims

1. Demands A method for distributing at least one multimedia content to at least one user device, the user device being configured to consume the multimedia content, the multimedia content being distributed by at least one service provider, the multimedia content being owned by a content owner, access to the multimedia content being managed by at least one content provider, the method being implemented by a computer network comprising at least one server of the service provider storing the multimedia content, an application programming interface, and the user device, the method comprising: - Store (11), in a blockchain deployed on the computer network: • at least one initial smart contract including at least one rule for distributing multimedia content and one rule for creating a unique token, • at least one metadata element associated with the multimedia content to be distributed, • at least one address of the multimedia content to be distributed, - Request (12), via the user device, from the content provider, access to multimedia content, - Distribute (13), by the content provider, at least one unique token for accessing multimedia content to the user device, the unique token having been constructed according to the unique token creation rule of the first smart contract, - Distribute (14), via the service provider's server, the multimedia content to the user's device, - Execute the smart contract, which includes: • Store (15), in the blockchain, proof of reading the multimedia content by the user device, the proof of reading comprising the user device's unique token and at least one secret constructed from the multimedia content, • Check (16) whether playback by the user device complies with the multimedia content distribution rule and issue an indication of compliance with the rule of distributing multimedia content to the content owner.

2. A method according to claim 1 wherein the multimedia content broadcasting rule is a predetermined minimum broadcast quality.

3. A method according to claim 2 wherein the multimedia content broadcasting rule is a predetermined minimum average broadcast rate.

4. A method according to any one of the preceding claims wherein the token is distributed to the user device by the content provider.

5. A method according to any one of the preceding claims in which the service provider does not have permission to access the proof-of-read token stored in the blockchain.

6. A method according to any one of the preceding claims wherein at least one second smart contract is stored in the blockchain, the second smart contract comprising at least one media delivery agreement between the content owner and the content provider, the media delivery agreement comprising at least one media content identifier and at least one media content delivery rule.

7. A method according to any one of the preceding claims wherein the multimedia content is distributed to a plurality of user devices and wherein a number of consumers of the multimedia content are read into the read proofs stored in the blockchain.

8. A method according to any one of the preceding claims wherein the issuing of an indication of compliance with the multimedia content distribution rule to the content owner includes issuing an alert to the content owner when the multimedia content distribution rule is not verified.

9. A method according to any one of the preceding claims, wherein the content is distributed to multiple user devices, access to the multimedia content being managed by a plurality of content providers, the method being implemented by a computer network comprising at least one server for each service provider among a plurality of service providers storing the content multimedia, and in which a plurality of contracts are stored in the blockchain, each smart contract comprising at least one rule for distributing multimedia content and one rule for creating a unique token associated with one content provider from among the plurality of content providers and with one service provider from among the plurality of service providers

10. Content delivery system comprising at least one server storing multimedia content, an application programming interface and a user device configured to consume the multimedia content, the system being characterized in that it is configured to implement the method according to any one of claims 1 to 9.

11. Product computer program comprising instructions which cause the system according to claim 10 to perform the process according to any one of claims 1 to 9.

12. Computer-readable medium on which the computer program according to claim 11 is recorded.

Images