INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Selon le présent mode de réalisation, dans le moteur à quatre temps 100, le premier taux de variation de position de papillon des gaz R1 est une quantité de variation de la position de papillon des gaz P par le premier temps unitaire ou le premier angle de rotation de vilebrequin unitaire, et le second taux de variation de position de papillon des gaz R2 est une quantité de variation de la position de papillon des gaz P par le second temps unitaire plus court que le premier temps unitaire ou le second angle de rotation de vilebrequin unitaire plus court que le premier angle de rotation de vilebrequin unitaire.
Selon cette configuration, la quantité d'injection de carburant lorsque la soupape d'admission est ouverte reflétant davantage la situation d'accélération rapide est acquise dans la situation d'accélération rapide, et la quantité d'injection de carburant lorsque la soupape d'admission est fermée avec une influence supprimée de vibrations, de bruits ou analogues est obtenue dans la situation d'accélération progressive. Par conséquent, il est possible d'améliorer davantage la capacité de réaction et la précision de la commande d'injection de carburant dans laquelle du carburant est injecté pendant chacune de la période de fermeture de soupape T1 lorsque la soupape d'admission 31 est fermée et de la période d’ouverture de soupape T2 lorsque la soupape d'admission 31 est ouverte dans un cycle de combustion, dans une situation d'accélération dans laquelle la position du papillon des gaz 33 passe à une position pour un état d'ouverture plus large du papillon des gaz 33.
Selon le présent mode de réalisation, dans le moteur à quatre temps 100, le dispositif de commande 60 est en outre configuré pour calculer la valeur de différence ou la valeur différentielle de temps pour la position du papillon des gaz 33 sur un intervalle de temps prédéterminé, le premier taux de variation de position de papillon des gaz R1 est une valeur obtenue en effectuant un traitement de lissage sur la valeur de différence calculée ou la valeur différentielle de temps calculée en utilisant le premier degré de lissage, et le second taux de variation de position de papillon des gaz R2 est une valeur obtenue en effectuant un traitement de lissage sur la valeur de différence calculée ou la valeur différentielle de temps calculée en utilisant le deuxième degré de lissage inférieur au premier degré de lissage.
Selon cette configuration, la valeur de différence sur un intervalle de temps prédéterminé ou la valeur différentielle de temps pour la position du papillon des gaz 33 est calculée, un traitement de lissage est effectué sur la valeur de différence ou la valeur différentielle de temps en utilisant le premier degré de lissage pour obtenir le premier taux de variation de position de papillon des gaz R1, et un traitement de lissage est effectué en utilisant le deuxième degré de lissage inférieur au premier degré de lissage pour obtenir le second taux de variation de position de papillon des gaz R2. Par conséquent, il est possible d'améliorer davantage la capacité de réaction et la précision de la commande d'injection de carburant dans laquelle du carburant est injecté pendant chacune de la période de fermeture de soupape T1 et de la période d'ouverture de soupape T2.
Selon la présente invention, dans le moteur à quatre temps 100, le premier taux de variation de position de papillon des gaz R1 est une valeur obtenue en calculant la valeur de différence sur un intervalle de temps prédéterminé ou la valeur différentielle de temps pour le résultat de traitement dans lequel un traitement de lissage est effectué sur la valeur de détection de la position du papillon des gaz 33 sur un intervalle de temps prédéterminé en utilisant le troisième degré de lissage, et le second taux de variation de position de papillon des gaz R2 est une valeur obtenue en calculant la valeur de différence sur un intervalle de temps prédéterminé ou la valeur différentielle de temps pour le résultat de traitement dans lequel un traitement de lissage est effectué sur la valeur de détection de la position du papillon des gaz 33 sur un intervalle de temps prédéterminé en utilisant le quatrième degré de lissage inférieur au troisième degré de lissage.
pour chaque bloc de la pluralité de blocs, la réception, depuis un serveur de confiance, d’une entrée d’accès propre au dispositif receveur et spécifique du fichier et du bloc, ACL-R-FBi, la détermination de ID-P-FBi à partir de ACL-R-FBi et le déchiffrement du bloc au moyen de ID-P-FBi ; la construction d’un deuxième arbre de Merkle à partir des blocs déchiffrés du premier ensemble de blocs de la pluralité de blocs et la vérification d’une concordance du deuxième arbre de Merkle avec les blocs déchiffrés du deuxième ensemble de blocs de la pluralité de blocs ; en absence de concordance : la création d’une contestation comprenant un ensemble de blocs non déchiffrés de la pluralité de blocs, ledit ensemble étant constitué au moins d’un bloc contesté et d’un bloc d’une vérification de Merkle du bloc contesté ; et la transmission, au serveur de confiance, de la contestation et, pour chacun des blocs de la contestation, d’une valeur d’identification propre au dispositif receveur et spécifique du fichier et du bloc, V-R-FBi.
- la est un schéma représentant un système de partage de fichiers informatiques entre dispositifs informatiques de plusieurs organisations ;
- la est un schéma illustrant les différentes étapes du procédé selon l’invention ;
- la illustre les différents blocs constituant l’encodage du fichier ;
- la illustre le chiffrement des différents blocs de l’encodage du fichier par le dispositif propriétaire ;
- la illustre le déchiffrement du fichier par le dispositif propriétaire ;
- la illustre une vérification de preuve de Merkle par le serveur de confiance.
L’invention porte sur la réalisation de transactions équitables entre des entités d’un réseau intégrant une gestion de droits d’accès à des fichiers chiffrés. On considère que les entités ont préalablement partagé ensemble un protocole de gestion des droits d’accès.
La représente schématiquement un système 1 de partage de fichiers entre des dispositifs informatiques de plusieurs organisations Org1, Org2, Org3, …, connectés sur un même réseau N, de préférence un réseau de télécommunications à distance. Le réseau N est typiquement un réseau Internet, Intranet, téléphonique 3G, 4G, 5G, DECT, Bluetooth, etc.
Dans le présent exemple, les organisations Org1, Org2, Org3 sont des organisations de gestion de données géophysiques et/ou environnementales. On entend par « données géophysiques » des données relatives aux caractéristiques physiques de la Terre, typiquement issues de mesures. Il peut s’agir de données géologiques et/ou sismiques et/ou gravimétriques et/ou atmosphériques et/ou spatiales, etc. On entend par « données environnementales » des données ayant trait à l'environnement biologique et humain d’une zone, par exemple des données biologiques et/ou sonores et/ou chimiques et/ou hydrologiques et/ou énergétiques et/ou relatives au traitement de déchets. Ces données sont typiquement des données sensibles mises sélectivement à disposition des organisations.
Les organisations Org1, Org2, Org3 sont par exemples distantes les unes des autres, et peuvent appartenir à des territoires différents. Chacune des organisations Org1, Org2, Org3 est par exemple une collectivité territoriale et/ou une société privée intervenant pour la collecte ou le traitement de données et/ou une association intervenant pour la collecte ou le traitement de données et/ou une organisation propriétaire de serveurs de stockage et/ou de calcul.
On considère ici que chacune des organisations Org1, Org2, Org3 est indépendante. Les organisations souhaitent par exemple mettre en commun sélectivement une partie de leur matériel et de leurs données, afin que chacune d’entre elles puisse s’appuyer sur au moins une partie des ressources et des données des autres organisations.
On présente désormais, en relation avec la , une architecture de téléchargement d’un contenu multimédia.
Dans notre exemple, le téléchargement est de type progressif basé sur l’utilisation du streaming adaptatif HAS. Précisons à nouveau ici que l’invention ne se limite pas à la technologie HAS mais s’étend à toutes autres technologies de téléchargement de données.
Un serveur de contenus numériques SRV se trouve selon cet exemple dans le réseau étendu WAN mais il pourrait indifféremment être situé une passerelle domestique ou tout autre équipement capable d’héberger un tel serveur de contenus.
Le serveur de contenus SRV reçoit par exemple des chaînes de contenus de télévision numérique en provenance d’un réseau de télévision diffusée, non représenté, et/ou des vidéos à la demande, et les met à disposition de terminaux clients.
Un terminal de lecture client, par exemple un décodeur peut entrer en communication avec le serveur de contenus SRV pour recevoir un ou plusieurs contenus (films, documentaires, séquences publicitaires, etc.).
Les terminaux clients peuvent être de toute sorte, par exemple un décodeur STB, un ordinateur PC, un téléphone mobile MOB, etc.
Les modes de réalisation se baseront sur un décodeur STB.
Il est fréquent, dans ce contexte client-serveur, de recourir, pour échanger les données entre un terminal client STB et le serveur SRV, à une technique de téléchargement progressif adaptatif, en anglais « adaptive streaming », abrégé en HAS basée sur le protocole HTTP. Ce type de technique permet notamment d'offrir une bonne qualité de contenus à l’utilisateur en tenant compte des variations de bande passante qui peuvent se produire sur la liaison entre le terminal client STB, et une passerelle de services , et/ou entre cette dernière et le serveur de contenus SRV.
Classiquement, comme on le verra en référence à la , différentes qualités peuvent être encodées pour le même contenu d’une chaîne, correspondant par exemple à différents débits d’encodage. Plus généralement, on parlera de qualité pour se référer à une certaine résolution du contenu numérique (résolution spatiale, temporelle, niveau de qualité associée à la compression vidéo et/ou audio) avec un certain débit d’encodage. Chaque niveau de qualité est lui-même découpé sur le serveur de contenus en segments temporels (aussi appelés « segments » de contenu par l’homme du métier, en anglais segments).
La description de ces différentes qualités et de la segmentation temporelle associée, ainsi que les segments de contenu, sont décrits pour le terminal client et mis à sa disposition via leurs adresses Internet (URI : Universal Ressource Identifier). L’ensemble de ces paramètres (qualités, adresses des segments, etc.) est en général regroupé dans un fichier de paramètres, dit fichier de description ou « manifest ». On notera que ce fichier de paramètres peut être un fichier informatique ou un ensemble d’informations descriptives du contenu, accessible à une certaine adresse.
Le terminal de lecture STB, dans un contexte de téléchargement adaptatif progressif, peut adapter les requêtes d’accès qu’il transmet au serveur pour recevoir et décoder le contenu demandé par l’utilisateur à la qualité qui lui correspond au mieux. Dans notre exemple, si les contenus sont disponibles aux débits 400 kb/s (kilobits par seconde) (Résolution 1, ou niveau 1, noté N1), 800 kb/s (N2), 1200 kb/s (N3) 2100 kb/s (N4) 3000 kb/s (N4) et que le terminal client dispose d’une bande passante de 3000 kb/s, il peut demander le contenu à n’importe quel débit inférieur à cette limite, par exemple 2100 kb/s. De manière générale, on note « Ci@Nj » le contenu numéro i avec la qualité j (par exemple le j-ième niveau Nj de qualité décrit dans le fichier de description).
La passerelle de service GTW est dans cet exemple une passerelle domestique qui assure le routage des données entre un réseau étendu WAN et le décodeur STB, gère les contenus numériques en assurant notamment leur réception en provenance du réseau et leur décodage grâce au décodeur STB.
Dans cet exemple, pour visualiser un contenu, le terminal client STB interroge tout d’abord la passerelle de service GTW pour obtenir une adresse du fichier de description du contenu (par exemple, C1) souhaité. La passerelle de service répond en fournissant au terminal l’adresse du fichier de description. Dans la suite, on supposera que ce fichier est un fichier de type manifest selon la norme MPEG-DASH et on se réfèrera indifféremment, selon le contexte, à l’expression « fichier de description » ou « manifest».
Alternativement, ce fichier peut être récupéré directement auprès d’un serveur Internet local ou externe au réseau local, ou se trouver déjà sur la passerelle de service ou sur le terminal au moment de la requête.
Un exemple de fichier manifest, qui sera décrit ci-dessous en référence à la , comporte la description de contenus disponibles dans plusieurs qualités différentes (N1 = 400 kb/s, N2 = 800 kb/s, N3 = 1200 kb/s, …).
Une fois qu’elle dispose des adresses de segments correspondant au contenu souhaité, la passerelle de service GTW procède à l’obtention des segments via un téléchargement à ces adresses. On notera que ce téléchargement s’opère ici, traditionnellement, au travers d’une URL HTTP, mais pourrait également s’opérer au travers d’une adresse universelle (URI) décrivant un autre protocole (dvb://monsegmentdecontenu par exemple).
Ingrédients (nom INCI) Invention 1 Comparatif Acide tannique (Brewtan F - Ajinomoto Omnichem Nv) 15 15 PPG-5-CETETH-20 (Procetyl AWS-LQ-(AP) – Croda) 15 - Red 7 (Unipure Red LC 3079 OR – Sensient) 10 10 Ethanol Qsp 100 Qsp 100
Etaler la composition (D) sur toute la surface 3 fois de suite pour avoir un dépôt homogène. Renouveler l’opération sur deux autres bandes. Laisser sécher le dépôt sur plaque chauffée à 34°C pendant 30 minutes. Si une composition (M) est utilisée, alors l’appliquer par-dessus la composition de la première étape, sur toute la surface, 3 fois de suite, pour avoir un dépôt homogène. Faire de même sur les deux autres bandes. Laisser sécher à nouveau le dépôt sur plaque chauffée à 34°C pendant 30 minutes. Prendre éventuellement une photo de chaque support avec le dépôt (maquillé) avant la sollicitation.
Revenant à l’exemple précédent, les organisations Org1, Org2, Org3 souhaitent pouvoir solliciter les serveurs de calcul I3, I3’ afin de disposer de leur puissance de calcul pour effectuer des traitements sur les données géophysiques et/ou environnementales auxquelles l’un quelconque des dispositifs I1, I1’, I2, I2’, I2’’. Pour ce faire, on souhaite attribuer un accès (typiquement uniquement en lecture) à l’un des fichiers chiffrés f1 et/ou f2 pour l’un des serveurs de calcul I3 et/ou I3’, de manière sélective et préférentiellement temporaire.
En référence à la , on considère ci-après un dispositif propriétaire P d’un fichier (par exemple le serveur I2’’ de l’organisation Org3) et un dispositif receveur R (par exemple le serveur de calcul I3 de l’organisation Org3) qui souhaite disposer d’un accès au fichier. Le fichier, chiffré par le dispositif propriétaire P, est stocké sur un serveur de stockage S. Le dispositif propriétaire P et le dispositif receveur R mettent en œuvre une transaction équitable au sens d’un protocole de type fairswap par l’intermédiaire d’un serveur de confiance T.
En référence à la , le fichier a préalablement été chiffré par le dispositif propriétaire (étape n°1 désignée par ENC) et transmis sous sa forme chiffrée Z (étape n°2) au serveur de stockage S. Le chiffrement du fichier F est plus particulièrement réalisé comme suit, en référence aux figures 3 et 4. Le dispositif propriétaire P vient tout d’abord découper le fichier en une pluralité de n blocs B1, B2, B3, B4, …, Bn formant un premier ensemble de blocs. Le dispositif propriétaire P vient ensuite construire un premier arbre de Merkle MT1 à partir du premier ensemble de blocs. Ce premier arbre de Merkle MT1 comprend une pluralité de nœuds H1, H2, …, Hm qui forme un deuxième ensemble de blocs. Les blocs B1, B2, B3, B4, …, Bn du premier ensemble et les blocs H1, H2, …, Hm sont réunis dans un vecteur Y. Le dispositif propriétaire vient ensuite générer un encodage Z du fichier en chiffrant, lors d’une opération ENC, chacun des blocs du premier et du deuxième ensemble, par une valeur d’identification propre au dispositif propriétaire et spécifique du fichier et du bloc (valeur notée ID-P-FBi pour le bloc Bi dans ce qui suit). L’encodage Z comprend ainsi un premier ensemble de blocs chiffrés ZB1, ZB2, ZB3, ZB4, …, ZBn résultant du chiffrement des blocs B1, B2, B3, B4, …, Bn issus du découpage du fichier Z et un deuxième ensemble de blocs chiffrés ZH1, ZH2, ZH3, …, ZBm résultant du chiffrement des blocs H1, H2, H3, …, Hm correspondant aux nœuds du premier arbre de Merkle MT1. Cet encodage Z est transmis au serveur de stockage S, le cas échéant avec la valeur racine Hm de l'arbre de Merkle MT1 du fichier F.
La valeur d’identification propre au dispositif propriétaire P et spécifique du fichier F et du bloc Bi, ID-P-FBi, dépend de la clé privée Up du dispositif propriétaire. Cette valeur d’identification est construite de telle sorte qu’un tiers ne peut pas obtenir cette valeur en connaissant simplement une identité du bloc Bi, sans connaître la clé privée Up. La valeur d’identification dépend ici également de l’identité du fichier F et de l’identité du bloc Bi. Autrement dit, les valeurs d’identification du dispositif propriétaire diffèrent pour chaque fichier, et pour chaque bloc au sein d’un même fichier.
De préférence, les différentes valeurs d’identification semblent aléatoires du point de vue d’un tiers qui ne connaîtrait pas la clé privée utilisée, mais ces valeurs sont déterministes pour l’utilisateur ayant connaissance de la clé privée utilisée. Ces valeurs peuvent correspondre aux résultats d’une fonction d’identification ID telle que ID-P-FBi = ID(Up, F, Bi). Dans un exemple de réalisation, la valeur ID-P-FBi est obtenue comme suit : ID-P-FBi = ID(Up, F, Bi) = Up+ sha256(concatenation(Up, F, Bi)), où Up est la clé privée du dispositif propriétaire, F est le nom du fichier, Bi est le i-ème bloc du vecteur Y, « concatenation » correspond à la fonction concaténation et « sha256 » correspond à une fonction de hachage cryptographique connue opérant sur une taille de mots de 32 bits. On comprend qu’il est possible d’employer une autre fonction de hachage ici.
Toujours en référence à la , le dispositif receveur R vient ensuite (étape n°3) télécharger l’encodage Z du fichier depuis le serveur de stockage S, le cas échéant avec certaines métadonnées associées au fichier comme par exemple son nom et la valeur racine Hm du premier arbre de Merkle.
Puis, pour chaque bloc de la pluralité de blocs chiffrés ZB1, …, ZBn, ZH1, …, ZHm de l’encodage du fichier, le dispositif receveur R vient déterminer une valeur d’identification du dispositif receveur associée au fichier et au bloc chiffré (notée V-R-FBi pour le bloc n°i).
Dans un premier mode de réalisation, la valeur V-R-FBi est calculée au moyen de la fonction d’identification ID présentée ci-dessus. Ainsi, V-R-FBi = ID(Ur, F, Bi) = Ur+ sha256(concatenation(Ur, F, Bi)) où Ur est la clé privée du dispositif receveur, F est le nom du fichier, Bi est le i-ème bloc chiffré de l’encodage Z. Cette valeur est ensuite transmise (étape n°4) au tiers de confiance T, par exemple après chiffrement au moyen d’une clé publique du dispositif propriétaire. Le dispositif receveur R peut par ailleurs calculer, pour chaque bloc chiffré de l’encodage Z, une valeur de hachage de V-R-FBi et transmettre cette valeur de hachage au serveur de confiance T.
Un deuxième mode de réalisation permet d’éviter le chiffrement à clé publique pour transmettre les valeurs V-R-FBi et de devoir poster au serveur de confiance l’ensemble des valeurs de hachages de ces valeurs V-R-FBi. Dans ce deuxième mode de réalisation, la valeur V-R-FBi est exploitée pour déterminer une première valeur de Diffie-Hellman, i.e. un nombre transmis par l’un des agents d’un protocole de Diffie-Hellman à l’autre des agents afin que ces agents puissent élaborer une clé partagée de Diffie-Hellman. Toute variante du protocole de Diffie-Hellman peut ici être utilisée, comme par exemple celle basée sur les courbes elliptiques (de l'anglais « Elliptic curve Diffie–Hellman », abrégé ECDH). Dans ce deuxième mode de réalisation, le dispositif receveur procède au tirage aléatoire de deux nombres g et p, détermine la première valeur de Diffie-Hellman selon g V -R- FBi [p] et transmet au tiers de confiance T cette la première valeur de Diffie-Hellman g V -R- FBi [p] ainsi que les nombres g et p.
Dans une première variante, la valeur V-R-FBi est calculée au moyen de la fonction d’identification ID présentée ci-dessus. Ainsi, V-R-FBi= ID(Ur, F, Bi) et la première valeur de Diffie-Hellman associée au i-ème bloc chiffré s’écrit g ID(Ur, F, Bi) [p]. Dans une seconde variante, le dispositif receveur R procède, pour chacun des blocs chiffrés de l’encodage Z, au tirage aléatoire d’une valeur xi. La première valeur de Diffie-Hellman associée au i-ème bloc chiffrée s’écrit alors g (xi) mod p.
Lors d’une étape optionnelle, le dispositif receveur R peut par ailleurs transmettre au serveur de confiance T la valeur du nœud-racine de l'arbre de Merkle du fichier attendu (dont il a par exemple connaissance au moyen des métadonnées) et/ou la valeur du nœud-racine d’un arbre de Merkle construit sur l’ensemble des blocs chiffrés ZB1, …, Zbn et ZH1, …, ZHm.
Lors d’une étape n°5, le dispositif propriétaire P vient récupérer depuis le serveur de confiance T l’ensemble des informations postées par le dispositif receveur R sur le serveur de confiance T.
Lorsque l’étape optionnelle mentionnée ci-dessus est mise en œuvre, le dispositif propriétaire P vient vérifier que la ou les valeurs des nœud-racines transmis par le dispositif receveur R au serveur de confiance sont correctes. Dans la négative, l’échange est arrêté.
Dans le cadre du premier mode de réalisation, le dispositif propriétaire P vient récupérer du serveur de confiance T les valeurs V-R-FBi (éventuellement chiffrées au moyen de la clé publique du dispositif propriétaire) et le cas échéant les valeurs de hachage associées. Le dispositif propriétaire P procède si besoin au déchiffrement des V-R-FBi au moyen de sa clé privée Up. Le cas échéant, le dispositif propriétaire peut, pour chaque bloc de la pluralité de blocs, calculer une valeur de hachage de V-R-FBi (éventuellement après déchiffrage) et comparer la valeur calculée à la valeur de hachage correspondante reçue du serveur de confiance.
Puis, pour chaque bloc de la pluralité de blocs, le dispositif propriétaire P vient générer une entrée d’accès propre au dispositif receveur et spécifique du fichier et du bloc, ACL-R-FBi, à partir de ID-P-FBi et de V-R-FBi. Cette entrée d’accès ACL-R-FBi est ensuite transmise au serveur de confiance T (étape n°6 sur la ). Dans un exemple de réalisation, cette entrée d’accès correspond à la différence des deux valeurs d’identification ACL-R-FBi = ID-P-FBi - V-R-FBi.
Dans le cadre du deuxième mode de réalisation, le dispositif propriétaire P vient récupérer du serveur de confiance les nombres g et p, et pour chaque bloc de la pluralité de blocs, la première valeur de Diffie-Hellman correspondante g V -R- FBi [p]. Le dispositif propriétaire P génère une valeur aléatoire T et détermine une deuxième valeur de Diffie-Hellman g T [p]. Le dispositif propriétaire P vient par ailleurs déterminer la clé partagée de Diffie-Hellman selon (g V -R- FBi [p]) T [p] = g V -R- FBi *T [p], générer une entrée d’accès propre au dispositif receveur et spécifique du fichier et du bloc, ACL-R-FBi, à partir de ID-P-FBi et de la clé partagée de Diffie-Hellman. Cette entrée d’accès ACL-R-FBi est ensuite transmise au serveur de confiance T avec la deuxième valeur de Diffie-Hellman g T [p]. Dans un exemple de réalisation, l’entrée d’accès correspond à la différence entre la valeur d’identification propre au dispositif propriétaire et spécifique du fichier et du bloc et la clé partagée de Diffie-Hellman : ACL-R-FBi = ID-P-FBi - g V -R- FBi *T [p].