INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
On note également qu’en limitant cette durée, on évite ou on limite le phénomène de dissolution de la couche diélectrique 3 qui peut se produire pendant la période de transition. Ce phénomène de dissolution conduit à une perte d’épaisseur de cette couche diélectrique, cette perte étant proportionnelle à la durée de la période de transition Tt élevée à la puissance n, (Tt)^n, n pouvant varier entre 2 et 4 selon la température, l’épaisseur initiale de la couche diélectrique et le débit de gaz porteur. Lorsque la durée de la période de transition Tt est excessive, l’épaisseur de la couche diélectrique est susceptible de devenir insuffisante pour permettre la formation d’une couche de piégeage de charges de qualité satisfaisante.
La couche diélectrique 3 peut être formée à une température supérieure, inférieure ou égale à la température de formation de la couche de piégeage de charges 4.
PROCEDE DE PREPARATION D’UN SUBSTRAT SUPPORT MUNI D’UNE COUCHE DE PIEGEAGE DE CHARGES DOMAINE DE L’INVENTION La présente invention concerne un procédé de préparation d’un substrat support comprenant une couche de piégeage de charges. Elle concerne également un procédé de report d’une couche mince sur un tel substrat support pour former un substrat composite. Ces substrats support et composite trouvent une application notable dans le domaine des dispositifs intégrés radiofréquences, c’est-à-dire des dispositifs électroniques traitant des signaux dont la fréquence est comprise entre environ 3kHz et 300GHz, par exemple dans le domaine des télécommunications (téléphonie, Wi-Fi, Bluetooth…).
Le serveur de société de gestion d’authentification 600 peut être un serveur qui utilise une page web, une page app, un programme ou une application lié à un service d’authentification d’actif réel utilisant un DID et un NFT pour stocker une empreinte numérique de surface, des informations de produit, une image de produit, un code d’identification unique (numéro de série), etc., de telle sorte que des informations d’authentification sont conditionnées dans le NFT et émettre le NFT. Le NFT émis peut être transmis au terminal utilisateur 100 via le serveur de fourniture de service d’authentification 300.
Ici, le serveur de société de gestion d’authentification 600 peut être mis en œuvre en tant qu’ordinateur capable d’accéder à un serveur ou un terminal par le biais d’un réseau. Ici, l’ordinateur peut inclure, par exemple, la navigation, un notebook équipé d’un navigateur web, un ordinateur de bureau, un ordinateur portable et analogues. Dans ce cas, le serveur de société de gestion d’authentification 600 peut être mis en œuvre en tant que terminal capable d’accéder à un serveur ou terminal distant par le biais d’un réseau. Le serveur de société de gestion d’authentification 600 est un dispositif de communication mobile dans lequel la portabilité et la mobilité sont garanties, et des exemples de celui-ci peuvent inclure tous les types de dispositifs de communication sans fil de poche tels qu’un PCS, GSM, un PDC, un PHS, un PDA, IMT-2000, CDMA-2000, W-CDMA, un terminal WiBro, un smartphone, un smartpad, une tablette PC, et analogues.
La est un schéma de configuration de blocs illustrant un serveur de fourniture de service d’authentification inclus dans le système de la , et les figures 3A, 3B et 4 sont des schémas pour décrire un mode de réalisation dans lequel le service d’authentification d’original d’actif réel à l’aide du DID et du NFT selon le mode de réalisation de la présente invention est mis en œuvre.
En se référant à la , le serveur de fourniture de service d’authentification 300 peut inclure une unité de stockage 310, une unité d’enregistrement 320, une unité de distribution 330, une unité d’authentification 340, une unité de détection d’authentification anormale 350, une unité de gestion d’historique 360 et une unité de confirmation d’origine 370.
Lorsque le serveur de fourniture de service d’authentification 300 selon un mode de réalisation de la présente invention ou d’autres serveurs (non illustrés) qui fonctionnent conjointement avec celui-ci transmettent une application, un programme, une page app, une page web, etc., liés à un service d’authentification d’actif réel à l’aide d’un DID et d’un NFT à au moins un terminal utilisateur 100, à au moins un terminal acheteur 400, à au moins une autorité certifiée 500 et à au moins un serveur de société de gestion d’authentification 600, l’au moins un terminal utilisateur 100, l’au moins un terminal acheteur 400, l’au moins une autorité certifiée 500 et l’au moins un serveur de société de gestion d’authentification 600 peuvent installer ou ouvrir l’application, le programme, la page app, la page web, etc. liés au service d’authentification d’actif réel à l’aide du DID et du NFT. De plus, en utilisant un script exécuté dans un navigateur web, le programme de service peut être entraîné dans l’au moins un terminal utilisateur 100, l’au moins un terminal acheteur 400, l’au moins une autorité certifiée 500 et l’au moins un serveur de société de gestion d’authentification 600. Ici, le navigateur web est un programme qui permet l’utilisation de services World Wide Web (WWW), et se rapporte à un programme qui reçoit et affiche de l’hypertexte écrit en langage de balisage hypertexte (HTML), et inclut, par exemple, Netscape, Explorer, Chrome et analogues. De plus, l’application se rapporte à une application sur un terminal, et inclut, par exemple, une app exécutée dans un terminal mobile (smartphone).
En se référant à la , l’unité de stockage 310 peut stocker, dans une base de données d’informations d’authentification, des informations d’authentification incluant un code d’identification unique d’un produit et une empreinte numérique de surface selon des caractéristiques de surface du produit sur la base d’informations véritables confirmées par au moins un serveur d’autorité certifiée 500 lorsque l’authenticité du produit, qui est un actif réel, est déterminée. Dans la présente invention, l’« actif réel » correspond à tous les actifs réels incluant les choses réelles générales et une image d’une chose réelle et/ou un objet immatériel. De plus, l’« empreinte numérique de surface » peut être des caractéristiques de surface uniques d’une chose réelle elle-même, une empreinte numérique de surface d’une chose réelle générale peut être des caractéristiques de surface uniques sur une surface de la chose réelle, et l’empreinte numérique de surface de l’image d’une chose réelle peut être une marque d’un motif d’empreinte numérique de surface généré de manière artificielle. Les informations d’authentification peuvent en outre inclure des informations de produit, une image de produit, une garantie et des informations d’autorité de certification d’un produit. Dans le cas où l’authenticité d’un produit, qui est un actif réel, est reçue à partir d’au moins un serveur d’autorité certifiée 500, lorsque les informations d’authentification incluant un code d’identification unique du produit et une empreinte numérique de surface selon des caractéristiques de surface du produit sont stockées dans la base de données d’informations d’authentification sur la base d’informations véritables, l’unité de stockage 310 peut demander la génération d’informations d’authentification à conditionner dans un NFT et demander l’émission du NFT en transmettant les informations véritables au serveur de société de gestion d’authentification à réception des informations véritables en provenance d’au moins un serveur d’autorité certifiée 500 pour émettre une balise d’empreinte numérique de surface. Dans ce cas, l’empreinte numérique de surface peut être une empreinte numérique de surface numérisée traitée en grossissant la totalité ou une partie des caractéristiques physiques de l’image de produit du produit, ce qui est divulgué en détail dans le brevet précédemment enregistré du présent demandeur, enregistrement de brevet coréen n°10-2120051 (publié le 17 juin 2020), et par conséquent, une description détaillée de ceci sera omise.
Initialement, les experts d’une autorité certifiée différencient chaque produit, mais lorsque les données de ces experts s’accumulent et que la quantité de données accumulées devient assez grande pour construire un ensemble de données d’apprentissage, un ensemble de données étiqueté qui peut différencier quels produits sont véritables et quels produits sont des ensembles de données contrefaits peut être construit. Lorsqu’un algorithme à intelligence artificielle est modélisé après apprentissage, les employés de l’autorité certifiée ont seulement besoin de vérifier ou d’inspecter le cas d’erreurs. L’intervention humaine est minimisée.
À cette fin, une mesure pour déterminer l’image d’entrée en tant que produit véritable ou en tant que contrefaçon en référence à une image originale peut être définie comme suit. La première mesure de comparaison est une différence absolue moyenne (MAD), et est une expression qui mesure la différence absolue moyenne mesurée en comparant l’image d’entrée à l’image originale stockée dans le serveur de fourniture de service d’authentification 300. Après avoir déplacé l’image originale de m et n tailles dans les directions horizontale et verticale, une valeur de différence entre chaque composante de couleur de l’image d’entrée et de l’image originale est obtenue, et une moyenne de valeur absolue de celle-ci est obtenue. C’est-à-dire, elle peut être mesurée par les expressions 1 et 2 suivantes.
[Expression 1]
[Expression 2]
La deuxième mesure de comparaison est l’auto-similitude (SSIM). C’est un procédé de mesure de SSIM basé sur des caractéristiques statistiques de chaque composante de couleur d’une image d’entrée. Souvent, elle est utilisée comme valeur numérique qui peut objectivement évaluer la qualité d’une image. Pour la mesure par SSIM, des valeurs de moyenne, de variance et de covariance de l’image sont utilisées. La SSIM a une valeur entre 0 et 1 et plus elle a une valeur proche de 1 plus elle est proche de l’original. µIN et µORG désignent la luminosité moyenne de l’image d’entrée et de l’image originale, respectivement. µIN et µORG désignent un écart standard de l’image d’entrée et de l’image originale, µINORG désigne une covariance entre elles, et c1 et c2 désignent des facteurs de correction.
[Expression 3]
La troisième mesure de comparaison est le nombre de pixels de grande erreur. Comme l’illustre l’Expression 4, le nombre de pixels de grande erreur est une valeur obtenue en mesurant le nombre dans le cas où l’erreur par rapport à chaque composante de couleur entre l’image d’entrée et l’image originale dépasse une certaine taille α.
[Expression 4]
La quatrième mesure de comparaison est le nombre de pixels de contour. Le nombre de pixels de contour par rapport à l’image d’entrée est examiné par Cany Edge. Ceci est utilisé pour détecter un flou de mouvement lors de la capture d’une image montée sur un téléphone mobile. Une déformation par la caméra, telle que du flou, provoque une déformation due à une dégradation de qualité globale dans laquelle l’image d’entrée ne peut pas être déterminée comme étant véritable ou fausse.
La cinquième mesure de comparaison est une mesure d’une valeur de M2. Un deuxième moment est utilisé comme caractéristique statistique d’une image, et est mesuré comme dans l’Expression 5.
Dans le mode de réalisation décrit ici, l’entité 5 de vérification est chargée en outre, via son module 5E de vérification, de vérifier si les informations d’identification nouvellement détectées et/ou l’identité numérique IDNUM(U) ne comportent pas des événements qu’il convient de signaler au fournisseur du service DYOS, par l’intermédiaire de l’entité 4 de contrôle.
Un tel événement est par exemple : la découverte, à partir des données analysées par le module 5E de vérification, d’une nouvelle plateforme de collecte de données impliquée lors de l’accès au service S. L’identification du type de la plateforme de collecte de données ainsi découverte peut être statique, par exemple à partir d’une liste maintenue et établie par le fournisseur du service DYOS, ou au contraire dynamique, via la détection de connexions récurrentes vers des noms de domaines donnés. S’il dispose d’une adresse IP pour cette nouvelle plateforme, le module 5E de vérification peut interroger une base de données (ex. base WHOIS) pour résoudre l’identité de la plateforme associée à cette adresse IP ; un niveau d’exposition de tout ou partie des informations d’identification de l’utilisateur U supérieur à un seuil donné. Un tel niveau d’exposition peut être estimé par le module 5E de vérification pour l’utilisateur U en considérant un encodage de bits particulier associant un certain nombre de bits aux informations d’identification de sorte à caractériser leur contribution à l’identification de l’utilisateur U. Une telle approche permet avantageusement de mesurer de façon unifiée et globale l’exposition d’un utilisateur au travers des informations d’identification détectées. Il convient de noter que même si les informations d’identification ne révèlent pas elles-mêmes en soi directement l’identité de l’utilisateur U (i.e. ne sont pas des informations de type PII, pour « Personally Identifiable Information » en anglais), d’autres informations (ex. localisation GPS) véhiculées dans des paquets de données émis par l’équipement utilisateur 3 de l’utilisateur U couplées à ces informations d’identification peuvent permettre d’établir des profils uniques, et donc in fine de tracer l’utilisateur U. Ainsi, selon cet encodage particulier, plus le nombre de bits nécessaires pour caractériser le niveau d’exposition est grand, plus la probabilité d’identifier l’utilisateur est moindre. A titre d’exemple nullement limitatif, un niveau d’exposition codé sur 32 bits est meilleur qu’un niveau d’exposition codé sur 16 bits ; une nouvelle information d’identification de l’utilisateur U détectée par l’entité 5 de vérification dans les données qu’elle vient d’analyser ; une information d’identification de l’utilisateur U transmise à une entité tierce qui ne respecte pas les CGU approuvées par l’utilisateur U, ou une réglementation en vigueur en matière de confidentialité (ex. règlement RGPD de l’Union Européenne), ou encore une déclaration faite par le fournisseur du service S indiquant sa politique en matière de collecte d’informations d’identification et le ou les traitements opérés sur les informations d’identification collectées (ex. stockage, partage), etc. ; etc.
Sur détection d’un tel événement, le module 5E de vérification envoie un signalement de l’événement au fournisseur du service DYOS et plus particulièrement ici, à l’entité 4 de contrôle.
Outre la conformité des informations d’identification détectées sur la connexion principale avec la déclaration du fournisseur de service S, dans le mode de réalisation décrit ici, l’entité 5 de vérification, via son module 5E de vérification, est également configurée pour examiner les informations d’identification véhiculées sur chaque connexion secondaire qu’elle gère (c’est-à-dire qu’elle audite) et pour déterminer si ces informations d’identification et le traitement qui en est fait par les infrastructures collectant ces informations d’identification sont conformes aux déclarations faites par les opérateurs de ces infrastructures, autrement dit conformes aux politiques de collecte et de traitement d’informations annoncées par ces opérateurs.
A cet effet, on suppose dans le mode de réalisation décrit ici, que ces politiques sont publiées en utilisant une URI de type « well-known » telle que décrite dans le document IETF RFC 8615, et appelée par exemple ici « telemetry-claims ». Le module 5E de vérification est alors en mesure de récupérer, en envoyant une requête (ex. requête HTTP GET) à cette URI, lesdites politiques en question pour chaque service annexe au service S invoqué dans une connexion secondaire (C2), (C2’), …, établie en marge de la connexion principale (C1), et ainsi obtenir la liste des informations d’identification et les traitements opérés le cas échéant selon ces politiques. On suppose ici que le corps du message de réponse ciblant ladite URI, reçu par le module 5E de vérification, comprend un objet structuré selon un format JSON (pour « JavaScript Object Notation » en anglais), identifié par un nouvel identifiant « media-type » appelé par exemple « application/telemetry-claims », et indiquant les données collectées et utilisées par l’infrastructure du service annexe concerné, quel(s) traitement(s) est/sont appliqué(s) le cas échéant sur les données (ex. si ces données sont enregistrées), etc. L’objet JSON peut également indiquer si un organisme d’audit a déjà certifié ces indications, et le cas échéant, donner l’identité de l’organisme en question ainsi qu’un lien vers le rapport d’audit établi par cet organisme. On peut noter que l’organisme en question peut être le fournisseur du service DYOS lui-même, auquel cas l’entité 5 de vérification a un accès direct au rapport d’audit dans le mode de réalisation décrit ici. L’audit en question peut être un audit sur site (ex. au niveau d’un serveur X selon la connexion considérée) ou une procédure DYOS précédemment exécutée et impliquant l’infrastructure du service annexe considéré.
Le module 5E de vérification vérifie alors, pour chaque connexion dont il est chargé, la conformité des informations d’identification véhiculées sur cette connexion avec les informations d’identification et les traitements déclarés qu’il a obtenus en ciblant les URI « well-known ». S’il n’y a pas conformité, il le signale à l’entité 4 de contrôle.
On note que le module 5E de vérification peut également corréler les déclarations et les informations d’identification qu’il a détectées avec les audits précédemment réalisés le cas échéant et signaler toute déviation par rapport aux déclarations. Il peut également, si un audit a déjà été réalisé dans le cadre de la procédure DYOS, modifier et/ou compléter dynamiquement le rapport d’audit correspondant. Il peut également enregistrer localement une alarme pour ce service.
L’entité 4 de contrôle relaie chaque signalement reçu de l’entité 5 de vérification à l’entité 6 de coordination (étape E60), afin que des mesures soient prises si nécessaire en fonction de l’événement signalé (ex. information de l’utilisateur U, (étape F40).
En variante, on peut envisager un signalement à d’autres entités, comme par exemple à l’équipement utilisateur 3, etc.
Dans le mode de réalisation qui vient d’être décrit, les vérifications exécutées dans le cadre de l’audit sont mises en œuvre par le module 5E de l’entité 5 de vérification. Dans un autre mode de réalisation, tout ou partie de ces vérifications peuvent être mises en œuvre par une autre entité du système 1 de vérification, comme par exemple l’entité 4 de contrôle. Un tel mode de réalisation est avantageux notamment lorsque le système 1 de vérification comprend plusieurs entités 5 de vérification alimentant l’identité numérique IDNUM(U) et gérées par une même entité 4 de contrôle.
On note que la procédure DYOS qui vient d’être décrite permet de réaliser un audit non seulement de la connexion principale établie pour accéder à un service, mais également les connexions secondaires établies en marge de cette connexion principale, et ce, en différents points de ces connexions. Elle peut être combinée à un audit sur site, réalisé par exemple au niveau du serveur autoritaire fournissant le service en question. La procédure DYOS proposée par l’invention permet ainsi un audit global du service S permettant de valider ou d’invalider le respect par ce service et par les services sous-jacents (annexes) sollicités pour accéder à ce service, des données personnelles d’un utilisateur.
En outre, la procédure DYOS peut être mise en œuvre de façon récursive. Ainsi, la procédure qui vient d’être décrite s’applique aussi à chaque connexion secondaire établie en complément (c’est-à-dire en marge) de la connexion principale, pour les connexions établies en complément de ladite connexion secondaire (désignées ensuite par connexions de niveau supérieur), puis à partir de chaque connexion de niveau supérieur établie en complément de chaque connexion secondaire, etc. Pour mieux décrire ce cas de figure, on désigne ci-après par « connexion de niveau N » la connexion principale et « connexions de niveau N+1 » les connexions secondaires établies en complément de la connexion principale, puis « connexions de niveau N+2 », les connexions secondaires établies en complément de chaque connexion de niveau N+1, etc. et plus généralement « connexions de niveau N+x » les connexions établies en complément des connexions de niveau N+(x-1). Pour gérer un tel cas de figure, on peut appliquer de façon récursive la procédure qui vient d’être décrite à une connexion du niveau N+(x-1) (considérée comme connexion principale) et aux connexions du niveau N+x établies en complément de cette connexion (considérées dans la procédure DYOS comme des connexions secondaires de la connexion principale de niveau N+(x-1)). Le mécanisme d’audit proposé par la procédure DYOS peut ainsi avantageusement s’appliquer à l’ensemble des connexions (c-à-d., toutes les connexions du niveau N au niveau N+(x-1)). L’identité numérique de l’utilisateur prise en compte pour l’audit réalisé par la procédure DYOS peut alors tenir compte de l’ensemble des informations d’identification collectées à tous les niveaux considérés.
Dans le mode de réalisation décrit ici, on a considéré une architecture du système 1 de vérification s’appuyant sur une entité de coordination et sur une entité de contrôle. Toutefois, il est possible également d’avoir plusieurs entités de coordination et plusieurs entités de contrôle. Par ailleurs, une même entité de vérification peut être gérée par plusieurs entités de contrôle.
Procédé de gestion d’une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d’une valeur d’un paramètre de performance intermédiaire Domaine de l'invention Le domaine de l'invention est celui de la transmission de données. Plus précisément, l'invention concerne l’amélioration de la coopération entre deux équipements de communication constituant les extrémités d’un chemin comprenant au moins un équipement intermédiaire.
Art antérieur et ses inconvénients Le chiffrement de bout en bout (en anglais, End-to-end encryption ou E2EE ) est une technique utilisée dans les systèmes de communication où seuls les équipements de communication ayant établi une connexion entre eux peuvent accéder au contenu de certaines données transmises au moyen de la connexion, les données utiles à l’acheminement pouvant être non chiffrées.
Les systèmes de chiffrement de bout en bout sont conçus pour résister à toute tentative de surveillance ou de modification des données, car aucun tiers ne peut déchiffrer, et donc accéder aux données ainsi communiquées s’il ne possède pas les clés de sécurité utilisées pour le chiffrement et le déchiffrement.
Pourtant, avec cette machine utilisant la gravité et la flottabilité dans deux environnements distincts l'eau et l'air, on arrive à générer un mouvement qui ne demande aucune source extérieure.
Chaque machine construite se voit devenir pour celui qui l'utilise une énergie gratuite et sans pollution.
Un grand atout pour la planète qui se voit libérer de notre impact écologique et donnant un axer plus facile à toute la population à l'énergie.
DISPOSITIF ASSURANT LA MISE EN FONCTION D’UN MOTEUR ACTIONNE SOUS L’IMPULSION D’ENERGIES NATURELLES. Le domaine de l'invention est celui de la conversion d’énergies.
Cette invention peut notamment trouver son application dans le domaine de la conversion de l’énergie hydraulique de sorte à activer un moteur hydraulique pouvant être joint à une génératrice de courant électrique.
Toutefois, les sources d’énergie dites « propres » tels que les sources d’énergie hydrolienne, éolienne, ou solaire ont toujours été exploitées. Quant aux énergies fossiles, elles sont de plus en plus à la source de maux climatiques et sanitaires programmés.
La présente invention découle de l’observation d’un phénomène physique relatif au principe des vases communicants.