Brevet FR3162335A1 — publié le 20251121

Un aspect de l’invention concerne un procédé de distribution de contenu multimédia à un dispositif utilisateur, le contenu multimédia étant distribué par un fournisseur de service et détenu par un propriétaire de contenu, l’accès au contenu multimédia étant géré par un fournisseur de contenu, comprenant : Stocker (11), dans une chaine de blocs, un contrat intelligent comprenant une règle de diffusion du contenu multimédia et une règle de création de jeton unique, Distribuer (13), par le fournisseur de contenu, un jeton unique d’accès au contenu multimédia au dispositif utilisateur, Distribuer (14), par le serveur du fournisseur de service, le contenu multimédia au dispositif utilisateur, Exécuter le contrat intelligent comprenant : Stocker (15), dans la chaîne de blocs, une preuve de lecture comprenant le jeton unique et un secret, Vérifier (16) si la lecture par le dispositif utilisateur respecte la règle de diffusion. Figure à publier avec l’abrégé : Figure 3 Méthode de distribution de contenu multimédia et système associé DOMAINE TECHNIQUE DE L’INVENTION Le domaine technique de l’invention est celui de la distribution de contenu multimédia. La présente invention concerne un procédé de distribution de contenu via une chaîne de blocs et en particulier une distribution de contenu vérifiant de manière certaine des règles techniques de lecture prédéfinies. ARRIERE-PLAN TECHNOLOGIQUE DE L’INVENTION Avec la démocratisation de la consommation de contenus numérique, les systèmes de distribution de contenu à travers des réseaux informatiques, en particulier sur Internet, sont devenus des éléments centraux de l'accès à l'information, au divertissement et à l'éducation pour des milliards de personnes à travers le monde. Les acteurs clés dans ce processus comprennent les propriétaires de contenu (CO de l’anglais « Content Owner »), les fournisseurs de contenu (CP de l’anglais « Content Provider ») et les fournisseurs de services (SP de l’anglais « service providers »). La nature décentralisée et la multiplicité des acteurs ont engendré des défis significatifs de confiance entre ces acteurs. Traditionnellement, la distribution de contenu implique des relations contractuelles entre les propriétaires de contenu et les fournisseurs de contenu, où les propriétaires de contenu accordent des autorisations de distribution aux fournisseurs de contenu pour rendre leur contenu disponible aux utilisateurs finaux via les services fournis par les fournisseurs de services. Cependant, cette chaîne de distribution est souvent sujette à des problèmes de confiance. Les fournisseurs de contenu peuvent potentiellement violer les termes des accords de licence en distribuant le contenu sans autorisation ou en enfreignant les droits de propriété intellectuelle des propriétaires de contenu. De même, les fournisseurs de services peuvent annoncer de plus grandes audiences que les audiences réellement réalisées. Le manque de transparence et de traçabilité dans les transactions de distribution de contenu peuvent entraîner des litiges coûteux, des pertes de revenus pour les propriétaires de contenu et des perturbations pour les utilisateurs finaux. De plus, les mécanismes traditionnels de gestion des droits numériques (DRM de l’anglais « Digital Right Management ») et de suivi de l'utilisation du contenu se révèlent souvent insuffisants pour garantir une distribution sécurisée du contenu et un partage équitable des bénéfices provenant de cette distribution. Ainsi, il existe un besoin d’avoir un système de distribution de contenu qui garantit la confiance entre les propriétaires de contenu, les fournisseurs de contenu et les fournisseurs de service. L’invention offre une solution aux problèmes évoqués précédemment, en proposant un procédé de distribution de contenu utilisant une chaîne de blocs at au moins un contrat intelligent. Un aspect de l’invention concerne un procédé de distribution d’au moins un contenu multimédia à au moins un dispositif utilisateur, le dispositif utilisateur étant configuré pour consommer le contenu multimédia, le contenu multimédia étant distribué par un fournisseur de service, le contenu multimédia étant détenu par un propriétaire de contenu, l’accès au contenu multimédia étant géré par au moins un fournisseur de contenu, le procédé étant mis en œuvre par un réseau informatique comprenant au moins un serveur du au moins un fournisseur de service stockant le contenu multimédia, une interface de programmation applicative et le dispositif utilisateur, le procédé comprenant : Stocker, dans une chaine de blocs déployée sur le réseau informatique : au moins un premier contrat intelligent comprenant au moins une règle de diffusion du contenu multimédia et une règle de création de jeton unique, au moins une métadonnée associée au contenu multimédia à distribuer, au moins une adresse du contenu multimédia à distribuer, Requérir, par le dispositif utilisateur auprès du fournisseur de contenu, l’accès au contenu multimédia, Distribuer, par le fournisseur de contenu, au moins un jeton unique d’accès au contenu multimédia au dispositif utilisateur, le jeton unique ayant été construit selon la règle de création de jeton unique du premier contrat intelligent, Distribuer, par le serveur du fournisseur de service, le contenu multimédia au dispositif utilisateur, Exécuter le contrat intelligent comprenant : Stocker, dans la chaîne de blocs, une preuve de lecture du contenu multimédia par le dispositif utilisateur, la preuve de lecture comprenant le jeton unique du dispositif utilisateur et au moins un secret construit à partir du contenu multimédia, Vérifier si la lecture par le dispositif utilisateur respecte la règle de diffusion de contenu multimédia et émettre une indication du respect de la règle de diffusion du contenu multimédia au propriétaire de contenu. Grâce à l’invention, certains verrous de confiance existants dans l’art antérieur sont levés. Le contenu peut être distribué par des fournisseurs de service, que ni le propriétaire de contenu ni le fournisseur de contenu ne connaissent à priori, et à qui ils n’ont pas de raison de faire confiance. Le fournisseur de service est assuré que le contenu qu’il relaie et diffuse est bien un contenu dont le propriétaire de contenu a autorisé la distribution. L’invention assure aussi que chaque distribution de contenu passant par ces fournisseurs de service respecte des règles techniques issues d’un accord entre le propriétaire de contenu et le fournisseur de contenu, et que toute consommation du contenu leur sera visible et analysable. En effet, dans l’art antérieur, les vérifications faites sur le respect de la propriété des contenus (en anglais « infringement rules ») sont réalisées de manière aléatoire et manuelle (il faut un opérateur humain pour traquer l’utilisation contrevenante du contenu), et donc peu efficace, tandis que l’invention permet au propriétaire du contenu d’être automatiquement informé de la violation des règles de distribution de contenu et de stopper automatiquement la distribution du contenu. L’objet de l’invention ne se substitue pas à un système de gestion des droits numérique (DRM) connu, car il n’a pas pour objectif de sécuriser le contenu à proprement parler. En revanche, l’invention est bien un système de gestion de droits numériques en ce qu’elle permet à un ayant droit ou à un diffuseur d’être notifié automatiquement et de stopper la diffusion des contenus au travers d’un fournisseur de contenu et/ou d’un fournisseur de service lorsque cette diffusion enfreint les règles de diffusion de contenu. En ce sens, bien que l’invention ne chiffre pas physiquement le contenu, elle permet la gestion des droits à un ou des détenteurs de droits au niveau de la distribution des contenus. En levant ces verrous de confiance, l’invention permet à un propriétaire de contenu de faire distribuer son contenu par plus de fournisseurs de service que dans l’art antérieur, car il est certain que le contenu redistribué en utilisant le procédé selon l’invention respectera les règles de diffusion prédéfinies. Outre les caractéristiques qui viennent d’être évoquées dans le paragraphe précédent, le procédé de distribution selon un aspect de l’invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles : la règle de diffusion de contenu multimédia est une qualité de diffusion minimale prédéterminée. la règle de diffusion de contenu multimédia est une débit moyen de diffusion minimal prédéterminé. le jeton est distribué au dispositif utilisateur par le fournisseur de contenu. le fournisseur de service n’a pas l’autorisation d’accéder au jeton de la preuve de lecture stocké dans la chaine de blocs. au moins un deuxième contrat intelligent est stocké dans la chaine de blocs, le deuxième contrat intelligent comprenant au moins un accord de diffusion multimédia entre le propriétaire de contenu et le fournisseur de contenu, l’accord de diffusion multimédia comprenant au moins un identifiant du contenu multimédia et au moins la règle de diffusion du contenu multimédia. le contenu multimédia est diffusé à une pluralité de dispositifs utilisateurs et dans lequel le nombre de consommateurs du contenu multimédia est lu dans les preuves de lecture stockées dans la chaine de blocs. l’émission d’une indication du respect de la règle de diffusion du contenu multimédia au propriétaire de contenu comprend l’émission d’une alerte au propriétaire de contenu lorsque la règle de diffusion du contenu multimédia n’est pas vérifiée. le contenu est distribué à plusieurs dispositifs utilisateurs, l’accès au contenu multimédia étant géré par un pluralité de fournisseurs de contenu, le procédé étant mis en œuvre par un réseau informatique comprenant au moins un serveur pour chaque fournisseur de service parmi une pluralité de fournisseurs de service stockant le contenu multimédia, et dans lequel une pluralité de contrats sont stockés dans la chaine de blocs, chaque contrat intelligent comprenant au moins une règle de diffusion du contenu multimédia et une règle de création de jeton unique associée à un fournisseur de contenu parmi la pluralité de fournisseurs de contenu et à une fournisseur de service parmi la pluralité de fournisseurs de service. Un autre aspect de l’invention concerne un système de diffusion de contenu comprenant au moins un serveur stockant un contenu multimédia, une interface de programmation applicative et un dispositif utilisateur configuré pour consommer le contenu multimédia, le système étant caractérisé en ce qu’il est configuré pour mettre en œuvre le procédé selon l’invention. Un autre aspect de l’invention concerne un produit programme d'ordinateur comprenant des instructions qui conduisent le système selon l’invention à exécuter le procédé selon l’invention. Un autre aspect de l’invention concerne un support lisible par ordinateur, sur lequel est enregistré le programme d'ordinateur selon l’invention. L’invention trouve notamment une application intéressante dans la distribution de contenu sportif payant, qui est actuellement un écosystème de diffusion à large échelle nécessitant une confiance forte entre les acteurs. L’invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l’examen des figures qui l’accompagnent. BREVE DESCRIPTION DES FIGURES Les figures sont présentées à titre indicatif et nullement limitatif de l’invention. La FIG. 1 montre une représentation schématique d’un procédé de diffusion de contenu selon l’invention, La FIG. 2 montre une représentation schématique d’un système de diffusion de contenu selon l’invention, La FIG. 3 montre une représentation schématique détaillée d’un procédé de diffusion de contenu selon l’invention. DESCRIPTION DETAILLEE Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique. La FIG. 1 montre une représentation schématique d’un procédé de distribution de contenu selon l’invention. Le procédé de distribution de contenu multimédia selon l’invention met en œuvre une chaine de blocs et au moins un contrat intelligent pour assurer la confiance entre les acteurs du réseau et notamment le respect de règles techniques de diffusion. Un système configuré pour mettre en œuvre le procédé 1 selon l’invention est représenté schématiquement à la FIG. 2 . Un tel système est un réseau de communication, c’est-à-dire que les flèches représentent des liens de communication entre les entités, par exemple via la suite de protocoles Internet, ou selon toute autre méthode de communication électronique. Le système 2 comprend un premier serveur informatique BC, configuré pour stocker une chaine de blocs. Une chaîne de blocs, également connue sous le nom de blockchain, permet d'enregistrer de manière sécurisée des transactions ou des données de manière immuable. Une chaine de blocs comprend une série de blocs de données liés et sécurisés cryptographiquement. Chaque bloc contient un ensemble de transactions vérifiées et horodatées, et est relié aux blocs précédents de manière chronologique, formant ainsi une chaîne continue. La validation des transactions et la création de nouveaux blocs sont par exemple effectuées par des participants du réseau via un processus appelé « consensus ». La chaine de blocs assure une transparence, une immuabilité et une sécurité des données qui y sont inscrites. Selon l’invention, la chaine de blocs comprend au moins un contrat intelligent, aussi appelé « smart contract ». Un contrat intelligent est un accord auto-exécutable qui s’exécute au sein d'un réseau de chaine de blocs. Les contrats intelligents comprennent des règles et des conditions qui peuvent être complexes, afin de superviser les transactions et les interactions entre les participants. Un contrat intelligent est une entité logicielle conçue pour être autonome et capable de surveiller les conditions prédéfinies de l’accord, de recueillir des données pertinentes et de prendre des décisions en temps réel en fonction de ces conditions. Grâce à l'utilisation de la chaine de blocs, le contrat intelligent assure la transparence, la sécurité et l'immutabilité des transactions contractuelles, tout en minimisant la nécessité d'intervention humaine. Dans un mode de réalisation préférentiel de l’invention, une chaine de blocs est déployée sur un serveur informatique BC. Un serveur informatique BC est un ordinateur. Dans d’autres modes de réalisation de l’invention, la chaine de blocs peut être décentralisée, c’est-à-dire répartie sur une pluralité d’ordinateurs. Par « ordinateur » on entend un dispositif comprenant au moins un processeur et une mémoire. La mémoire stocke des instructions qui, lorsqu’elles sont exécutées par le processeur, conduisent le processeur et donc l’ordinateur à mettre en œuvre les actions qui lui sont attribuées. Ainsi, dans la suite de la description, lorsqu’on prête une action à un ordinateur, cette action est en fait encodée sous forme d’instructions stockées dans la mémoire de l’ordinateur et exécutées par le processeur de l’ordinateur. Une chaine de blocs est « déployée » sur un ordinateur lorsque la mémoire de l’ordinateur stocke la chaine de blocs et qu’une interface permet d’interagir avec la chaine de blocs stockée par l’ordinateur. Une telle interface est préférentiellement dans l’invention une interface de programmation d’application, aussi appelée API pour « Application Programming Interface ». l’interface de programmation d’application permet d’interagir avec la chaine de blocs en lisant la chaine de blocs par un accès en lecture, ou en écrivant sur la chaine de blocs par un accès en écriture. La chaine de blocs peut comprendre de nombreux paramètres différents, n’autorisant la lecture et/ou l’écriture qu’à certains acteurs, ou n’autorisant certaines actions qu’à certains acteurs. Ces paramètres sont prédéfinis, c’est-à-dire qu’ils sont stockés dans au moins un fichier de configuration avant l’utilisation de la chaine de blocs. Préférentiellement dans l’invention, la chaine de blocs est une chaine dite « de consortium », c’est-à-dire une chaine de blocs dont l'accès est limité à un certain nombre d'entités ou de participants sélectionnés. Cette configuration permet de bénéficier de plusieurs avantages des chaines de blocs, tels que la transparence, la sécurité et l'immuabilité, tout en offrant un meilleur contrôle sur qui peut voir certaines données, qui peut participer au réseau et comment les consensus sont atteints. Lorsqu’un consensus est nécessaire, par exemple pour réaliser une validation de la chaine de blocs, un mode de réalisation préférentiel met en œuvre un consensus de type Raft. Un tel consensus ne sera pas décrit dans le présent document car il n’est pas le cœur de l’invention et car il est connu. Dans l’invention, au moins un premier type de contrat intelligent est stocké dans la chaine de blocs. Préférentiellement, un deuxième type de contrat intelligent est aussi stocké dans la chaine de blocs. Chaque contrat intelligent créé et stocké dans la chaine de blocs, qu’il soit du premier type ou du deuxième type, est associé à un triplet fournisseur de service SP, fournisseur de contenu CP et propriétaire de contenu CO. Ainsi, il est possible de créer plusieurs contrats, différents, pour plusieurs fournisseurs de contenu CP et/ou plusieurs fournisseur de service SP. Chaque contrat créé n’est associé qu’à un unique triplet fournisseur de service SP, fournisseur de contenu CP et propriétaire de contenu CO, et, pour diffuser le contenu via un autre fournisseur de service SP ou un autre fournisseur de contenu CP, un autre contrat doit être créé. Cela permet de s’assurer de la confidentialité des données de preuve des consommations du contenu, et du respect des règles de distribution de contenu. Un premier type de contrat intelligent est un contrat d’accès au contenu, par exemple nommé ContentAccess. Un tel contrat intelligent d’accès au contenu spécifie, pour un contenu donné, au moins une règle de distribution du contenu et au moins une règle de création de jeton unique. La règle de distribution du contenu est au moins une règle technique liée à la lecture du contenu par un utilisateur. La règle de création de jeton unique spécifie une méthode de génération de jeton unique utilisée pour générer et distribuer un jeton à l’utilisateur lisant le contenu. Un deuxième type de contrat intelligent est un contrat de diffusion, par exemple nommé BroadcastSettlement. Un tel contrat de diffusion spécifie différentes caractéristiques d’un accord entre plusieurs acteurs pour la diffusion d’un contenu. Dans l’invention, les contrats intelligents comprennent des classes et des fonctions exécutables via une interface de programmation d’application. L’interface de programmation d’application (API) peut être utilisée par chaque acteur indépendamment des autres acteurs. Chaque acteur peut avoir un accès restreint à l’interface, ayant accès à un nombre limité de fonctions, ou peut avoir un accès complet à l’interface. Préférentiellement, chaque acteur a un accès restreint à l’interface et donc à la chaine de blocs et aux fonctions des contrats intelligents. Des exemples de fonctions et des classes de chacun des types de contrats intelligents vont maintenant être décrits. Dans l’invention, les contrats de diffusion C1 « BroadcastSettlement » doivent nécessairement comprendre au moins une variable d’identification d’un contenu disponible. Par exemple, les contrats de diffusion C1 « BroadcastSettlement » peuvent comprendre une classe « Contenu Disponible » ou « AvailableContent », qui peut comprendre notamment : Un état du contenu : diffusable, disponible, indisponible, Un identifiant du contenu, Un propriétaire du contenu (CO), Un nom de contenu, Un prix associé au contenu Une date d’ajout du contenu, Une date de fin de disponibilité du contenu. La classe présentée précédemment n’est qu’un exemple de classe et l’invention couvre bien entendu toute combinaison des variables prises indépendamment, ainsi que toute autre variable. Dans l’invention, les contrats de diffusion C1 « BroadcastSettlement » doivent nécessairement comprendre au moins des fonctions de récupération de contenu, d’ajout de contenu disponible, et d’obtention d’accès au contenu disponible. Le contrat intelligent de diffusion C1 « BroadcastSettlement » comprend par exemple les fonctions suivantes : Récupérer les contenus disponibles : « queryAllAvailableContent », Récupérer un contenu disponible à partir d’une variable de la classe : « queryAvailableContent », Ajouter un contenu disponible sur la chaine de blocs « coAddAvailableContent », Obtenir un accès à un contenu disponible (par exemple, par un achat) « cpBuyAccess ». Les fonctions présentées précédemment ne sont que des exemples de fonction et l’invention couvre bien entendu toute combinaison des fonctions prises indépendamment. Dans l’invention, les contrats d’accès au contenu C2 « ContentAccess » doivent nécessairement comprendre au moins une variable d’identification du contenu diffusé, d’identification du spectateur et de vérification de la session de diffusion. Par exemple, les contrats d’accès au contenu C2 « ContentAccess » peuvent comprendre une classe « Contenu diffusé » ou « ContentBeingSupplied », qui peut comprendre notamment : Un état du contenu : en cours de diffusion, non diffusé, non disponible, Un identifiant du contenu diffusé, Un prix associé au contenu Un identifiant de spectateur, Une vérification de la session de diffusion, Une date de diffusion du contenu. La classe présentée précédemment n’est qu’un exemple de classe et l’invention couvre bien entendu toute combinaison des variables prises indépendamment, ainsi que toute autre variable. Dans l’invention, les contrats d’accès au contenu C2 « ContentAccess » doivent nécessairement comprendre au moins des fonctions de récupération de contenu, d’ajout de contenu diffusable, d’ajout de spectateur, d’ajout de preuve de diffusion, et de vérification de preuve de diffusion. Le contrat intelligent d’accès au contenu C2 « ContentAccess » comprend par exemple les fonctions suivantes : Récupérer les contenus diffusés : « queryAllSuppliedContent », Récupérer un contenu diffusé à partir d’une variable de la classe : « querySuppliedContent », Ajouter un contenu diffusable à partir d’un contenu disponible sur la chaine de blocs (par le fournisseur de contenu)« cpAddContent », Ajouter un spectateur, avec son identifiant et sa clé publique (par le fournisseur de contenu) « cpAddViewerIdAndPublicKey », Ajouter une preuve de diffusion (par le fournisseur de service) « spAddViewershipProof », Vérifier la preuve de diffusion (par le fournisseur de contenu) « cpVerifyProof ». Les fonctions présentées précédemment ne sont que des exemples de fonction et l’invention couvre bien entendu toute combinaison des fonctions prises indépendamment. Le procédé de distribution de contenu 10 représenté à la FIG. 1 utilise une chaine de blocs déployée sur un réseau informatique, par exemple déployée sur un serveur, ainsi que les deux types de contrats intelligents définis précédemment. Le procédé de distribution de contenu 10 est aussi présenté plus en détail à la FIG. 3 , qui représente les échanges entre les acteurs d’un mode de réalisation d’un procédé selon l’invention. Ce procédé ne présente les échange qu’entre un triplet fournisseur de service SP fournisseur de contenu CP et propriétaire de contenu CO spécifique, mais il peut être dupliqué à tout triplet fournisseur de service SP, fournisseur de contenu CP et propriétaire de contenu CO défini dans un contrat intelligent stocké dans la chaine de blocs. Le procédé 10 comprend une première étape 11 d’ajout d’un nouveau contenu au système de distribution de contenu. Cette étape 11 comprend plusieurs sous étapes 111 à 116. Une première sous-étape 111 est une sous-étape de stockage, dans la chaine de blocs, du nouveau contenu multimédia. Par « contenu multimédia » on entend un contenu dans un format de médias tel qu’un format texte, image, vidéo, sonore etc., utilisé pour présenter par exemple des informations ou du divertissement à un utilisateur. Pour cela, le propriétaire (juridique) du contenu multimédia (CO) émet une requête dans une étape 111 à destination de la chaine de blocs, en utilisant l’interface de programmation d’application (API). Cette requête met par exemple en œuvre la fonction « coAddContent » du contrat de diffusion C1 « BoradcastSettlement » présenté précédemment. Le contenu multimédia n’est pas stocké directement dans la chaine de blocs, mais une référence à ce contenu multimédia est stockée dans la chaine de blocs à une étape C11, lors de l’exécution de la fonction « coAddContent » par le contrat intelligent de diffusion. Ainsi, dans la chaine de blocs, est stockée au moins une adresse du contenu multimédia à distribuer et préférentiellement au moins une métadonnée associée au contenu multimédia à distribuer. L’adresse du contenu multimédia à distribuer est par exemple une adresse IP (de la suite de protocoles internet). Par exemple, si le contenu multimédia est stocké sur un serveur CP de la FIG. 2 , une adresse du contenu sur le serveur CP est stockée sur la chaine de blocs. Une métadonnée associée au contenu est par exemple la taille de stockage du contenu (en bits ou en octets), le durée du contenu, une spécificité liée au contenu, le propriétaire du contenu, un genre du contenu, ou toute autre métadonnée du contenu. Aux sous-étapes 112 et 113, le propriétaire du contenu (CO) informe le ou les fournisseur(s) de contenu (CP) de l’existence d’un nouveau contenu publié sur la chaine de blocs. Ces deux sous-étapes 112 et 113 peuvent être automatisées, par exemple via un contrat intelligent (par exemple le contrat de diffusion) qui surveille les ajouts de nouveau contenu sur la chaine de blocs. Cette information de nouveau contenu peut être publiée via l’interface de programmation d’application (API), à destination du ou des fournisseur(s) de contenu (CP), par exemple par l’utilisation par le(s) fournisseur(s) de contenu (CP) d’une application logicielle spécifique. Aux sous-étapes 114 à 116, optionnelles, un accord de diffusion est trouvé entre le propriétaire de contenu CO, au moins un fournisseur de contenu CP et au moins un fournisseur de service SP. Cet accord est stocké dans la chaine de blocs par le contrat intelligent de diffusion C1 « BroadcastSettlement » à la sous-étape C12, qui n’est pas optionnelle. Cet accord définit notamment des règles de diffusion du contenu, et par exemple les rémunérations des différents acteurs du triplet fournisseur de service SP, fournisseur de contenu CP et propriétaire de contenu CO. Pour trouver cet accord, les négociations peuvent avoir lieu hors de la chaine de blocs (« off-chain » en anglais) ou via la chaine de blocs, par exemple en utilisant un système d’enchères. Dans l’invention, il est nécessaire d’avoir au moins une règle technique de diffusion du contenu associée au contenu, c’est pourquoi l’étape C12 est nécessaire. Une règle de diffusion du contenu comprend au moins une règle technique de diffusion, par exemple une qualité de diffusion minimale, par exemple définie selon un débit moyen de diffusion minimal. Un tel débit est par exemple exprimé en mégaoctets par seconde. D’autres règles techniques de diffusion du contenu peuvent être par exemple un nombre maximal de consommations du contenu, nombre maximal de connexions simultanées au serveur diffusant le contenu, un niveau de sécurisation et de chiffrement du flux prédéfini, un type d’Agents Utilisateurs (définissant le type de dispositifs utilisateurs : TV, ordinateur, smartphone etc), une qualité d’expérience QoE prédéfinie, une limitation de contenus par géolocalisation d’adresses IP, une limitation de contenus par liste noire d’adresses IP (anti VPN). Parallèlement à l’étape 11, c’est-à-dire éventuellement simultanément à l’étape 11 ou avant ou après l’étape 11, un utilisateur U s’enregistre, lors des étapes U11 à U14, auprès d’un fournisseur de contenu CP. Un tel enregistrement est par exemple un abonnement au service du fournisseur de contenu CP, par exemple à une plateforme de visionnage à distance, ou une inscription au service fourni par le fournisseur de contenu CP, ou encore un achat du contenu auprès du fournisseur de contenu CP. Lors d’une étape U11, l’utilisateur utilise un dispositif utilisateur, par exemple un ordinateur, un smartphone ou une tablette, pour émettre une requête d’enregistrement. Le dispositif utilisateur est configuré pour consommer le contenu multimédia, c’est-à-dire qu’il comprend au moins un moyen de consommation du contenu, par exemple un écran si le contenu comprend de la photo ou de la vidéo, un haut-parleur si le contenu comprend du son etc. Le dispositif utilisateur comprend aussi des moyens de communication réseau pour recevoir le contenu multimédia et émettre des requêtes réseau. Cette requête est reçue par une application en ligne APP à une étape U12, et transmise aux étapes U13 et U14 au fournisseur de contenu CP, par exemple au serveur du fournisseur de contenu CP. Cela permet au fournisseur de contenu CPde connaître l’utilisateur U et à l’utilisateur U d’utiliser le service de distribution de contenu proposé par le fournisseur de contenu CP. Après enregistrement (optionnel) de l’utilisateur U auprès du fournisseur de contenu CP, l’utilisateur U peut requérir l’accès à un contenu multimédia ajouté à la chaine de blocs et appartenant à un propriétaire du contenu CO, et proposé par un fournisseur de contenu CP via le fournisseur de service SP auprès duquel l’utilisateur U est enregistré. Pour cela, dans une étape 12, plusieurs sous-étapes sont réalisées. Tout d’abord, l’utilisateur U utilise son dispositif utilisateur pour requérir l’accès au contenu à une sous-étape 121, par exemple en sélectionnant un contenu multimédia parmi une pluralité de contenus multimédias proposés dans l’application logicielle APP appartenant par exemple au fournisseur de service SP. La pluralité de contenus multimédia disponibles peut avoir été récupérée par le fournisseur de service SP en utilisant une fonction de récupération des contenus disponibles du contrat intelligent d’accès au contenu C2. Dans une sous-étape 122, l’application en ligne APP, par exemple proposée en tant que service via internet, reçoit et transmet la requête au fournisseur de contenu CP, qui a l’autorisation de fournir le contenu tel que défini dans le contrat intelligent de diffusion C1. Le fournisseur de contenu CP reçoit la requête à la sous-étape 123. En réponse à la requête reçue à la sous-étape 123, le fournisseur de contenu CP distribue un jeton unique à l’étape 13. Un tel jeton unique est aussi nommé un « secret ». Pour distribuer un jeton unique, l’étape 13 comprend plusieurs sous-étapes. Lors d’une première sous-étape 131, le fournisseur de contenu CP envoie la requête de distribution de contenu via le contrat intelligent d’accès au contenu C2, en utilisant l’interface de programmation d’application API, par exemple en utilisant une fonction de génération de jeton unique du contrat intelligent C2. Le contrat intelligent d’accès au contenu C2 génère un tel jeton unique en utilisant une fonction qu’il comprend, la fonction se basant sur une règle de génération qu’il comprend. Par exemple, le jeton unique est généré en suivant un principe de chiffrement asymétrique : l’utilisateur U reçoit une clé privée, et le contrat intelligent publie dans la chaine de blocs une clé publique associée à l’utilisateur U. La clé privée est alors le jeton unique. La clé privée est par exemple générée par une méthode de cryptographie sur les courbes elliptiques, en anglais « Elliptic Curve Cryptography » ou ECC. La clé publique, qui permet la vérification de la signature générée avec la clé privée (jeton) est enregistrée dans la chaine de blocs, et la clé privée est enregistrée en local, par exemple dans un serveur du fournisseur de contenu CP. Cette clé privée, faisant office de jeton, est distribuée à l’utilisateur à l’étape 13, après son enregistrement à l’étape 11 pour accéder au contenu. Le jeton unique généré par le contrat intelligent C2 est alors transmis à l’application APP qu’utilise l’utilisateur U pour accéder à son contenu. L’application APP reçoit ce jeton à la sous-étape 132 et l’utilisateur U détient donc ce jeton unique à la sous-étape 133. L’application APP est par exemple un site internet dans un navigateur web qui utilise par exemple un langage tel que le javascript pour stocker et manipuler le secret de l’utilisateur U. Un avantage de l’invention est que le jeton unique généré ne transite jamais par le fournisseur de service SP ou par ses serveurs, qui ne peut donc pas créer de fausses diffusion car il ne peut déclarer de diffusion sans le jeton unique, comme sera décrit par la suite. Après avoir reçu l’autorisation d’accéder au contenu via la réception du jeton unique, l’utilisateur U va recevoir le contenu multimédia, par exemple sous la forme d’un flux vidéo diffusé dans l’application APP qu’il utilise sur son dispositif utilisateur à l’étape 14. Pour cela, l’étape 14 comprend une pluralité de sous-étapes 141 à 145. L’application APP va tout d’abord émettre dans une sous-étape 141 une requête de contenu à destination du fournisseur de service SP, c’est-à-dire à destination du serveur du fournisseur de service SP. Le fournisseur de service SP reçoit la requête à une sous-étape 142 et vérifie si l’utilisateur U est enregistré auprès de lui (étapes U11 à U14) puis émet le contenu multimédia à une sous-étape 143, à destination de l’utilisateur U, qui le reçoit dans l’application APP à la sous-étape 144 et lit le contenu multimédia à la sous-étape 145. Le contenu multimédia était par exemple stocké dans les serveurs du fournisseur de contenu CP, puis transmis vers le ou les serveurs du fournisseur de service SP, pour diffusion via l’application APP. Un nonce est généré par le fournisseur de service SP (c’est-à-dire, par son serveur SP) et accompagne le contenu multimédia lors de sa transmission. Ce nonce servira à créer une signature pour prouver la présence du fournisseur de service SP dans la diffusion du contenu multimédia. A l’étape 143, lorsque le contenu est émis vers l’utilisateur U, le fournisseur de service SP appelle une fonction du contrat intelligent d’accès au contenu C2, en utilisant l’interface de programmation d’application API, par exemple en utilisant une fonction de génération de nonce du contrat intelligent C2. Le contrat intelligent d’accès au contenu C2 génère un tel nonce en utilisant une fonction qu’il comprend, la fonction se basant sur une règle de génération qu’il comprend, et la transmet à l’application APP, ou, alternativement, au fournisseur de service SP pour qu’il transmette le contenu multimédia concomitamment avec le nonce. Selon l’invention, lors du visionnage, c’est-à-dire lors de la diffusion du contenu, des traces d’exécution matérielle sont consignées. Ces traces d’exécution matérielle sont par exemple, et selon toute combinaison possible : un identifiant de l’utilisateur U ayant consommé le contenu, un identifiant de son dispositif utilisateur, un identifiant de l’application APP ayant diffusé le contenu, un identifiant du navigateur dans lequel était exécutée l’application APP, un identifiant du contenu diffusé, un débit moyen de diffusion de contenu, un débit instantané de diffusion du contenu, un horodatage de diffusion du contenu, un identifiant du fournisseur de service SP ayant diffusé le contenu à l’utilisateur U. Un ensemble d’une ou plusieurs des traces d’exécution matérielle spécifiées dans la phrase précédente forme une session de contenu, par exemple représentée par un vecteur comprenant, dans chaque colonne, une valeur de l’information attendue. Les sessions de contenu sont générées et émises régulièrement par l’application APP à l’étape 15. Ces sessions de contenu comprennent en outre une signature du nonce reçu du fournisseur de service SP par le jeton unique de l’utilisateur U, par exemple par un programme informatique prédéfini. Cela permet à tous les acteurs de s’assurer que le fournisseur de service SP a bien diffusé le contenu car il a fourni le nonce et que l’utilisateur U avait bien l’autorisation de consommer le contenu car il dispose et du nonce du fournisseur de service SP et du jeton unique fourni par le fournisseur de contenu. Une fois les sessions de contenu générées, par exemple par l’application APP, celles-ci sont transmises pour être stockées dans la chaine de blocs. Deux modes de réalisation sont possibles à ce stade. Dans un premier mode de réalisation, les sessions de contenu sont transmises au fournisseur de service SP, qui se charge, via son serveur SP et via l’interface de programmation d’application API, d’utiliser la fonction d’ajout de preuve du contrat intelligent d’accès au contenu C2 pour stocker à l’étape C23 la ou les preuves de diffusion que sont les sessions de contenu dans la chaine de blocs. Alternativement, dans un deuxième mode de réalisation représenté à la FIG. 2 , un serveur proxy P1 est présent et fait le lien avec le serveur BC sur lequel est déployée la chaine de blocs. Un tel serveur proxy P1 est par exemple un proxy http (pour « HyperText Transfer Protocol »), et est donc préférentiellement une application logicielle. Un avantage d’avoir un serveur proxy P1 est la capacité de réaliser une authentification de la preuve avant son stockage dans la chaine de blocs, plutôt qu’après son stockage. En effet, la preuve (session de contenu) reçue de l’application APP comprend le jeton unique signé par le nonce. Le serveur proxy P1 a alors accès à la clé publique associée à la clé privée qu’est le jeton unique, et authentifier la preuve (session de contenu) en vérifiant la signature comprise dans chaque session de contenu, avant, via l’interface de programmation d’application API, d’utiliser la fonction d’ajout de preuve du contrat intelligent d’accès au contenu C2, de stocker à l’étape C23 la ou les preuves de diffusion que sont les sessions de contenu dans la chaine de blocs. Ainsi, le serveur proxy P1 peut rejeter les requêtes non signées ou mal signées, par exemple les requêtes d’accès au contenu ou de stockage de preuve de diffusion. Un autre avantage du serveur proxy P1 est que le serveur proxy P1 n’utilise que la partie « en-tête » des paquets transmis, et que le fournisseur de service SP peut alors de diffuser son contenu en utilisant la partie « utile » des paquets comme il l’entend, de manière transparente. Encore un autre avantage du serveur proxy P1 est qu’il permet de modifier les termes des contrats intelligents et d’appliquer ces modifications rapidement et de manière fiable, en rejetant par exemple toute requête comprenant le nonce d’un fournisseur de service SP ayant été exclu d’un contrat de diffusion préexistant. L’invention permet de créer, à partir de la chaine de blocs, des listes de sessions de contenu pour chaque contenu diffusé par un triplet fournisseur de service SP, fournisseur de contenu CP et propriétaire de contenu CO, et de vérifier l’authenticité et le respect technique de la diffusion du contenu multimédia. Ainsi, le procédé 1 selon l’invention comprend une étape 16 de vérification du respect de règle technique comprise dans un contrat intelligent, par le contrat intelligent d’accès au contenu C2. Cette étape 16 de vérification peut être exécutée automatiquement de manière régulière, ou suite à une requête émise par un des acteurs, principalement par le propriétaire de contenu CO ou par le fournisseur de contenu CP, qui sont les plus à même de vouloir vérifier l’authenticité des preuves stockées et le respect des règles par la diffusion du contenu. Cette vérification 16 comprend un appel d’une fonction du contrat intelligent d’accès au contenu C2, en utilisant l’interface de programmation d’application API, par exemple en appelant une fonction de vérification de preuve du contrat intelligent C2. Cette fonction de vérification de preuve va vérifier l’authenticité de la preuve via la signature comprise dans la preuve, et va vérifier le respect des règles définies dans le contrat intelligent de diffusion de contenu C1. Pour vérifier l’authenticité de la preuve, la même vérification que celle proposée par le serveur proxy P1 peut être menée. Pour vérifier le respect des règles, la fonction du contrat intelligent C2 peut lire les différentes traces d’exécution matérielle et les confronter aux règles définies, ou peut utiliser les traces d’exécution matérielle pour calculer une valeur qui sera confrontée aux règles définies. Par exemple, si une règle du contrat définit un débit moyen minimal, la fonction du contrat intelligent C2 peut récupérer le débit moyen dans la preuve, ou calcul un débit moyen et le confronter au débit moyen minimal du contrat C1. Si le débit moyen dépasse le débit moyen minimal prédéfini dans le contrat, la règle est respectée et la diffusion peut compter comme une diffusion du contenu, donnant ainsi une sécurité technique au propriétaire du contenu CO et/ou au fournisseur de contenu CP du nombre exact de diffusions ayant respecté les règles technique définies, permettant ainsi par exemple un comptage fiable et/ou une juste rémunération des différents acteurs. Cela permet de compter un nombre de consommateurs ou de consommations du contenu ayant respecté les règles de diffusion, obtenu à partir des preuves de consommation stockées dans la chaine de blocs. L’invention comprend aussi, optionnellement, l’émission d’une alerte (non représenté) lorsqu’une diffusion ne respecte pas les règles du contrat de diffusion C1 ou lorsque l’authentification n’est pas vérifiée. Cette alerte est préférentiellement émise pour chaque session de contenu dont la vérification n’obtient pas un résultat positif, permettant au propriétaire du contenu CO, au fournisseur du contenu CP et/ou au fournisseur de service SP d’agir rapidement pour empêcher la diffusion frauduleuse. L’action peut aussi être automatisée suite à une vérification menant à un résultat négatif, c’est-à-dire que la diffusion du contenu pour cette session de contenu peut être automatiquement interrompue, par exemple via le serveur proxy P1 ou en agissant directement au niveau d’un des serveurs CP et/ou SP. Procédé de distribution d’au moins un contenu multimédia à au moins un dispositif utilisateur, le dispositif utilisateur étant configuré pour consommer le contenu multimédia, le contenu multimédia étant distribué par au moins un fournisseur de service, le contenu multimédia étant détenu par un propriétaire de contenu, l’accès au contenu multimédia étant géré par au moins un fournisseur de contenu, le procédé étant mis en œuvre par un réseau informatique comprenant au moins un serveur du fournisseur de service stockant le contenu multimédia, une interface de programmation applicative et le dispositif utilisateur, le procédé comprenant : Stocker (11), dans une chaine de blocs déployée sur le réseau informatique : au moins un premier contrat intelligent comprenant au moins une règle de diffusion du contenu multimédia et une règle de création de jeton unique, au moins une métadonnée associée au contenu multimédia à distribuer, au moins une adresse du contenu multimédia à distribuer, Requérir (12), par le dispositif utilisateur auprès du fournisseur de contenu, l’accès au contenu multimédia, Distribuer (13), par le fournisseur de contenu, au moins un jeton unique d’accès au contenu multimédia au dispositif utilisateur, le jeton unique ayant été construit selon la règle de création de jeton unique du premier contrat intelligent, Distribuer (14), par le serveur du fournisseur de service, le contenu multimédia au dispositif utilisateur, Exécuter le contrat intelligent comprenant : Stocker (15), dans la chaîne de blocs, une preuve de lecture du contenu multimédia par le dispositif utilisateur, la preuve de lecture comprenant le jeton unique du dispositif utilisateur et au moins un secret construit à partir du contenu multimédia, Vérifier (16) si la lecture par le dispositif utilisateur respecte la règle de diffusion de contenu multimédia et émettre une indication du respect de la règle de diffusion du contenu multimédia au propriétaire de contenu. Procédé selon la revendication 1 dans lequel la règle de diffusion de contenu multimédia est une qualité de diffusion minimale prédéterminée. Procédé selon la revendication 2 dans lequel la règle de diffusion de contenu multimédia est une débit moyen de diffusion minimal prédéterminé. Procédé selon l’une des revendications précédentes dans lequel le jeton est distribué au dispositif utilisateur par le fournisseur de contenu. Procédé selon l’une des revendications précédentes dans lequel le fournisseur de service n’a pas l’autorisation d’accéder au jeton de la preuve de lecture stocké dans la chaine de blocs. Procédé selon l’une des revendications précédentes dans lequel au moins un deuxième contrat intelligent est stocké dans la chaine de blocs, le deuxième contrat intelligent comprenant au moins un accord de diffusion multimédia entre le propriétaire de contenu et le fournisseur de contenu, l’accord de diffusion multimédia comprenant au moins un identifiant du contenu multimédia et au moins la règle de diffusion du contenu multimédia. Procédé selon l’une des revendications précédentes dans lequel le contenu multimédia est diffusé à une pluralité de dispositifs utilisateurs et dans lequel un nombre de consommateurs du contenu multimédia est lu dans les preuves de lecture stockées dans la chaine de blocs. Procédé selon l’une des revendications précédentes dans lequel l’émission d’une indication du respect de la règle de diffusion du contenu multimédia au propriétaire de contenu comprend l’émission d’une alerte au propriétaire de contenu lorsque la règle de diffusion du contenu multimédia n’est pas vérifiée. Procédé selon l’une des revendications précédentes dans lequel le contenu est distribué à plusieurs dispositifs utilisateurs, l’accès au contenu multimédia étant géré par un pluralité de fournisseurs de contenu, le procédé étant mis en œuvre par un réseau informatique comprenant au moins un serveur pour chaque fournisseur de service parmi une pluralité de fournisseurs de service stockant le contenu multimédia, et dans lequel une pluralité de contrats sont stockés dans la chaine de blocs, chaque contrat intelligent comprenant au moins une règle de diffusion du contenu multimédia et une règle de création de jeton unique associée à un fournisseur de contenu parmi la pluralité de fournisseurs de contenu et à une fournisseur de service parmi la pluralité de fournisseurs de service Système de diffusion de contenu comprenant au moins un serveur stockant un contenu multimédia, une interface de programmation applicative et un dispositif utilisateur configuré pour consommer le contenu multimédia, le système étant caractérisé en ce qu’il est configuré pour mettre en œuvre le procédé selon l’une des revendications 1 à 9. Produit programme d'ordinateur comprenant des instructions qui conduisent le système selon la revendication 10 à exécuter le procédé selon l’une des revendications 1 à 9. Support lisible par ordinateur, sur lequel est enregistré le programme d'ordinateur selon la revendication 11.