INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Cet agent actif, provenant de sources naturelles, présente une activité anti-biofilmique. Sans être lié par la théorie, il semble que les particules de soie peuvent agir à différents stades de la formation de biofilm, sur des cibles moléculaires disparates et avec divers mécanismes d'action. Il s'agit notamment de l'inhibition de la formation et de l'adhésion du biofilm, de la régulation à la baisse des facteurs de détection du quorum et de la perturbation du biofilm préformé.
De préférence, le diamètre des particules de soie est compris entre 3 et 7µm, par exemple 5 micromètres.
Avantageusement, la composition comprend entre 1 et 10% et plus particulièrement entre 2,5 et 5% en poids de particules de soie.
Avantageusement, la composition comprend en outre un prébiotique associé à un post-biotique.
Avantageusement, le prébiotique est un fructo-oligosaccharide et le post-biotique est un extrait de Lactobacillus lactis.
La composition est une composition destinée à être utilisée sur la peau. La composition peut être sous la forme d’une crème, d’un lait ou d’une pommade.
La composition est élaborée à partir d’une émulsion, en particulier d’une émulsion de type huile dans eau.
Avantageusement, la composition est sous la forme d’une crème élaborée à partir d’une émulsion, en particulier un émulsion huile dans eau, comprenant une phase aqueuse et une phase huileuse comprenant les particules de soie.
L’invention concerne également une composition telle que définie précédemment pour son utilisation comme médicament, de préférence un médicament à usage topique.
L’invention concerne également une composition telle que définie précédemment pour son utilisation dans le traitement d’atopie cutanée (dermatite atopique) et de l’acné ou la prévention d’atopie cutanée et de l’acné.
L’invention concerne également une utilisation cosmétique (non thérapeutique) d’une composition telle que définie précédemment pour l’hydratation de la peau ou la cicatrisation de la peau.
L’écrou de base 3 est destiné à être vissé sur l’embout 1 en tirant et pressant le deuxième embout 2 par sa collerette 21 pour appuyer sa lèvre d’étanchéité 211 contre la surface d’étanchéité 13 du premier raccord 1.
La surface de l’organe de serrage 4, à l’opposé de celle de la (deuxième) couronne d’accrochage 42 est une surface d’appui 44 pour un élément de ressort de compression 5 entourant le palier 34 de l’écrou 3.
L’élément de ressort de compression 5 est pris en sandwich entre la surface d’appui 44 et un écrou de précontrainte 6 pour être vissé sur le segment fileté 35 de l’écrou de base 3 et serrer l’élément de ressort 4 contre l’organe de serrage 3 et ainsi la deuxième couronne d’accrochage 41 contre la première couronne d’accrochage 33.
Comme le montre la vue en coupe de la partie B de la , l’écrou de serrage 4 est un écrou chapeau qui couvre à la fois l’élément de ressort de compression 5 et l’écrou de précontrainte 6 de façon à éviter tout déréglage du couple de serrage de consigne.
Le sous-ensemble 100a du raccord 100 comprenant l’écrou 3, l’organe de serrage 4, l’élément de ressort de compression 5 et l’écrou de précontrainte 6 est préréglé au couple de serrage de consigne CS. L’assemblage des conduites C1, C2 par le raccord 100 consiste à fixer les deux embouts 1, 2 à l’extrémité respective des conduites C1, C2 puis à visser le sous-ensemble 100a (emmanché sur l’embout 2 avant la fixation de celui-ci à la conduite C2), sur le segment fileté 12 de l’embout 1. Le premier embout 1 est tenu par un outil appliqué à sa surface de prise d’outil 11 et le sous-ensemble 100a est manœuvré en utilisant sa surface de prise d’outil 43. Le mouvement de vissage se poursuit jusqu’à ce que les couronnes radiales d’accrochage 33, 42 patinent et ne transmettent plus de couple supérieur au couple de serrage de consigne CS. De manière avantageuse, les dents formées par les couronnes d’accrochage permettent le desserrage sans limitation de couple puisque dans le sens de dévissage de l’écrou de serrage, les dents s’entraînent par les crans formés par les faces verticales des dents.
Le serrage du raccord 100 est fait par le vissage de l’écrou de base 3 sur le segment fileté 12 du premier embout 1, en étant entraîné en rotation pour son vissage par l’organe de serrage 4 monté libre en rotation sur un palier 34 et coopérant par sa surface d’accrochage 42 avec la première surface d’accrochage 33 de l’écrou de base 3. L’organe de serrage 4 est poussé contre l’écrou de base 3 par l’élément de ressort de compression 5 lui-même poussé par l’écrou de précontrainte 6 vissé par son taraudage 61 sur l’écrou de base 3. Le serrage de l’élément de ressort de compression 5 par le vissage réglé de l’écrou de précontrainte 6 permet de régler le couple de consigne CS par lequel l’écrou de serrage 4 entraîne l’écrou de base 3 pour son vissage sur le premier embout 1.
Le serrage de l’écrou de base 3 sur l’embout 1 peut se faire jusqu’à atteindre le couple de consigne fixé par l’écrou de précontrainte 6 et l’élément de ressort de compression 5.
Dans plusieurs modes de réalisation des procédés de gestion selon l’invention, l’entité de gestion NSP reçoit une demande de création d’une nouvelle tranche depuis l’entité de gestion CSP. Cette demande contient l’identifiant ID1 d’une tranche déjà existante TR1, cet identifiant pouvant être remplacé par toute autre référence permettant de retrouver les informations pertinentes relatives à la tranche TR1. La tranche TR1 est déjà fournie par l’entité NSP à l’entité CSP et est utilisée par cette dernière pour fournir une partie de ses services de communication. La référence à la tranche TR1 permettra de s’assurer que les contraintes respectives à la préexistence de cette tranche TR1 seront bien prises en compte lors de la création de la nouvelle tranche. L’entité de gestion NSP transmet la demande reçue de création d’une nouvelle tranche à une entité de gestion NOP.
L’entité de gestion NOP a la charge de l’orchestration des fonctions réseau virtualisées dans le réseau de télécommunications 5G. A ce titre, c’est l’entité de gestion NOP qui va effectivement créer CRT la nouvelle tranche de réseau demandée. En effet, la création d’une tranche de réseau, comme déjà expliqué, comprend la réservation de ressources matérielles, l’activation d’instances de fonctions virtuelles réseau et de liaisons de communication entre ces instances. Il s’agit donc d’une opération d’orchestration des fonctions réseau virtualisées du réseau de télécommunications 5G qui résulte en la création d’une nouvelle tranche de réseau.
Comme pour les autres entités de gestion, l’entité de gestion NOP peut être opérée par la même organisation que celle qui opère le réseau de télécommunications 5G ou bien être opérée par une organisation différente et disposer dans ce cas d’une relation contractuelle avec l’organisation qui opère le réseau 5G. En général, cependant, l’entité de gestion NOP est bien opérée par l’opérateur du réseau 5G.
Un réseau 5G peut comprendre une seule entité de gestion NOP, en charge de l’orchestration des fonctions virtualisées pour toutes les tranches, mais on peut aussi imaginer un fonctionnement avec plusieurs entités de gestion NOP. Par exemple, des entités de gestion NOP distinctes peuvent créer et orchestrer des tranches de réseau pour des domaines fonctionnels distincts ; l’une s’occupera des tranches de réseau dédiées aux services de télécommunication, l’autre aux services pour véhicules connectés, l’autre pour les services aux entreprises etc. D’autres types de découpes sont bien sûr possibles.
Dans des modes de réalisation de l’invention, l’entité de gestion NOP va, à partir d’un identifiant ID1 d’une première tranche de réseau TR1 déjà existante, sélectionner un ensemble de fonctions réseau virtualisées appartenant à la première tranche de réseau TR1, puis créer CRT une deuxième tranche de réseau TR2 comprenant les fonctions réseau virtualisées sélectionnées précédemment appartenant à la première tranche de réseau TR1 et comprenant d’autres fonctions virtualisées. L’identifiant ID1 peut être, dans plusieurs modes de réalisation, celui reçu dans la demande de création d’une nouvelle tranche TR2 reçue par l’entité de gestion NOP. La sélection des fonctions consiste dans la plupart des modes de réalisation de l’invention à retenir les fonctions réseau virtualisées qui doivent être partagées entre l’ensemble des tranches réseau orchestrées par l’entité de gestion NOP. On a vu par exemple que les fonctions relatives à la gestion de la carte SIM devaient l’être pour assurer l’accès aux tranches par le réseau mobile public PLMN. D’autres critères de sélection peuvent être appliqués. La création CRT de la nouvelle tranche de réseau TR2 sera ensuite réalisée par l’entité de gestion NOP en reprenant les instances de fonctions réseau virtualisées sélectionnées précédemment dans la tranche TR1.
Comme indiqué précédemment, une tranche de réseau TR1, TR2 est une instanciation de l’ensemble des fonctions virtuelles de réseau. Sur la , les instances de fonctions virtuelles sont représentées par des points et des cercles inclus dans TR1 et TR2. Les relations entre instances, indiquant les échanges de données entre instances par exemple, sont représentées par des flèches. On remarque sur la que deux instances de fonctions virtuelles de réseau de TR2, représentées par des cercles, sont reliées à une instance de fonction virtuelle de réseau de TR1, représentée par un cercle plein. Cette représentation en cercle plein indique que cette instance de fonction virtuelle est partagée entre les deux tranches TR1, TR2. Autrement dit, la fonctionnalité de cette fonction réseau est rendue, au sein de la tranche TR2, par une instance de fonction virtuelle réseau de la tranche TR1. Les relations entre instances de fonction virtuelle réseau au sein de la tranche TR2 doivent donc partiellement inclure des instances en dehors de la tranche TR2, ce qui est indiqué sur la par deux flèches « sortant » de la tranche de réseau TR2.
La création CRT d’une tranche de réseau TR2 est une opération dite d’orchestration qui va comprendre la réservation de ressources matérielles, l’instanciation de fonctions virtuelles réseau sur ces ressources matérielles, l’établissement de relations entre instances, l’affectation d’identifiants aux différentes instances etc. Les notions d’orchestration sont bien connues dans l’état de l’art et ne sont pas davantage détaillées ici. L’objet de la présente demande de brevet est un ensemble de procédés précédant la création CRT de la tranche TR2 en tant que telle. La représente donc l’état final obtenu à la suite d’un exemple de réalisation des procédés de la présente demande de brevet, exemple de réalisation qui aboutit à la création CRT de la tranche de réseau TR2, dont une instance de fonction de réseau virtuelle est partagée avec la tranche TR1. La tranche de réseau TR1, quant à elle, est représentée sur la comme étant préexistante à l’exemple de réalisation des procédés de la présente demande de brevet.
Une fois que la tranche TR2 est créée CRT, les fonctions virtuelles de réseau sont instanciées et permettent à la tranche de réseau TR2 de remplir l’ensemble des fonctions d’un réseau de télécommunications. Les fonctions virtuelles de réseau de la tranche de réseau TR1 sont quant à elles déjà instanciées, précédemment à l’opération de création CRT de la tranche de réseau TR2. Autrement dit, une tranche de réseau TR1, TR2 est un réseau de télécommunications virtuel qui s’exécute sur des ressources matérielles.
Dans d’autres modes de réalisation de l’invention, d’autres étapes s’intercalent entre la sélection des fonctions réseau virtualisées de la tranche TR1 et la création CRT de la nouvelle tranche de réseau TR2.
Après la sélection de fonctions réseau virtualisées appartenant à la première tranche de réseau TR1, dans notre exemple, l’entité de gestion NOP va définir au moins une description de tranche de réseau. L’ensemble des descriptions de tranches de réseau ainsi définies est dénommé D sur la . Une description de tranche de réseau est un objet informatique qui permet de représenter une tranche de réseau. Cette représentation pourra alors être utilisée dans des traitements informatiques, et en particulier pourra permettre la création CRT de la tranche de réseau décrite, mais également pourra permettre un choix ou une confirmation de la tranche de réseau à créer.
La description d’une tranche de réseau comprendra donc par exemple des informations relatives à la réservation de ressources matérielles, aux fonctions utilisées pour l’instanciation des fonctions réseau virtualisées, à la mise en place de liaisons de communication entre fonctions réseau virtualisées et en général toute autre information utile à la création et au fonctionnement de la tranche de réseau décrite. Une description de tranche de réseau peut être vue comme un fichier de configuration pour l’objet informatique qu’est la tranche de réseau, ou même comme un fichier de build , au sens de la construction d’un objet informatique. D’autres paramètres tels que par exemple des identifiants, des paramètres de qualité de service, des coûts d’utilisation ou tout autre paramètre peuvent être présents dans une description de tranche de réseau. Une description de tranche de réseau peut par exemple être exprimée dans un langage permettant d’exprimer des données complexes et structurées tels que le langage XML (acronyme de l’anglais eXtensible Markup Language ) ou le langage YAML (acronyme de l’anglais Yet Another Markup Language ) ou le langage JSON (acronyme de l’anglais JavaScript Object Notation ) ou tout autre langage, ou dans un mélange de ces possibilités.
Les descriptions de tranches de réseau définies par l’entité de gestion NOP peuvent, dans certains modes de réalisation, s’appuyer sur des patrons ou modèles prédéfinis qui laissent ouvertes plusieurs options de définitions pour des fonctions réseau spécifiques, et en limitent d’autres à un choix unique. De cette manière, l’entité de gestion NOP n’a pas à réaliser tous les choix nécessaires à la création d’une tranche de réseau. Certains peuvent être prédéfinis. L’étape de choix réalisée par l’entité de gestion NOP, dans ces modes de réalisation, présente à la fois une bonne dynamicité selon les options laissées ouvertes tout en ayant une plus grande simplicité qui permet une réalisation plus facile de l’opération de définition de l’ensemble D des descriptions par l’entité de gestion NOP.
L’ensemble D de descriptions de tranches de réseau définies par l’entité de gestion NOP représente l’ensemble des descriptions des tranches de réseau que l’entité de gestion NOP est disposée à créer CRT à la suite de la réception d’une demande de création CRT d’une nouvelle tranche de réseau TR2, demande comprenant l’identifiant ID1 d’une première tranche de réseau TR1 déjà existante. Dans des modes de réalisation de l’invention, l’entité de gestion NOP va donc transmettre à l’entité de gestion NSP en charge de fournir des tranches de réseau l’ensemble D de descriptions définies précédemment de tranches de réseau.
L’entité de gestion NSP va donc recevoir, dans plusieurs modes de réalisation de l’invention, depuis l’entité de gestion NOP, l’ensemble D de descriptions de tranches de réseau. L’entité de gestion NSP va alors transmettre à l’entité de gestion CSP l’ensemble D de descriptions de tranches de réseau reçu précédemment. Dans plusieurs modes de réalisation de l’invention, cette transmission par l’entité de gestion NSP se fait sans changer l’ensemble D de descriptions de tranches de réseau reçu précédemment.
L’entité de gestion CSP va donc recevoir un ensemble D de descriptions de tranches de réseau. Cet ensemble D est reçu consécutivement à la demande de création d’une nouvelle tranche de réseau par l’entité de gestion CSP, la demande contenant l’identifiant ID1 d’une première tranche de réseau TR1 déjà existante. La présence de l’identifiant ID1 a permis à l’entité de gestion NOP de procéder à la sélection de fonctions présentes dans la tranche TR1 devant être partagées et la définition des tranches de réseau regroupées dans l’ensemble D prend en compte cette sélection. La création d’une des tranches de réseau dont la description est présente dans l’ensemble D pourrait donc répondre à la demande émise par l’entité de gestion CSP, qui pourrait par la suite utiliser la tranche de réseau créée pour fournir des services de communication.
L’entité de gestion CSP va donc procéder à un choix parmi l’ensemble D de descriptions reçu d’une description D2 d’une tranche de réseau TR2 à créer. Ce choix pourra être informé par tout un ensemble de données, par exemple relatives au coût des tranches de réseau proposées, ou à des paramètres de qualité de service attendues, ou à des données de localisation des fonctions réseau virtualisées ou à toute autre considération. L’opération de choix permet de s’assurer que la création d’une tranche de réseau se fera bien en accordance avec les besoins de l’entité de gestion CSP qui va ensuite utiliser la tranche de réseau créée pour fournir des services de communication. Le choix se fait parmi des descriptions de tranche de réseau pouvant être créées qui prend en compte la tranche de réseau TR1 déjà existante. On a donc, grâce à l’invention, à la fois de la dynamicité dans la création de tranches de réseau au lieu d’avoir un ensemble de tranches de réseau prédéfinies fixé par l’opérateur de réseau 5G, et une prise en compte des contraintes de partage entre les tranches des instances de certaines fonctions réseau virtualisées.
Deux types de clés enfant peuvent être dérivées :
- une clé enfant « renforcée » (« hardened »), en utilisant un indice , auquel cas on ne peut pas prouver qu’une clé enfant est liée à une clé parent ;
- une clé enfant normale ou non-renforcée (« non-hardened »), en utilisant un indice , auquel cas on peut prouver qu’une clé enfant est liée à une clé parent, en utilisant seulement ces deux clés.
Dans la variante avantageuse de l’invention, le module de dérivation de clé 61 permet de dériver des clés enfant non-renforcées de sorte qu’il soit possible pour un serveur, pour des raisons de traçabilité, de retrouver l’utilisateur/administrateur qui a généré la paire de clés éphémères pour l’utilisateur temporaire, c’est-à-dire qui a identifié cet utilisateur temporaire comme un utilisateur légitime du système 10 et lui a permis de s’enrôler sur le réseau de périphérie.
Au-delà de la certification des clés éphémères par l’ACL, l’utilisateur/administrateur délivre le certificat créé, et révoque et/ou met à jour les certificats éphémères en services. On retrouve les fonctions similaires à celles de l’instance centrale de l’IGC.
La révocation possible d’un certificat enfant n’interfère pas sur la validité du certificat parent.
Lorsque l’utilisateur temporaire U4 ayant été enregistré par l’utilisateur/administrateur U3 du réseau de périphérie 16 en mode dégradé sur l’AC locale, ACL2, de ce réseau de périphérie, se déplace vers un autre réseau de périphérie, qui lui fonctionne en mode connecté, par exemple le réseau 18, l’authentification de l’utilisateur U4 est faite de la manière suivante.
Dans un premier temps , le serveur S4 auquel cherche à se connecter l’utilisateur U4 vérifie la validité du certificat de l’utilisateur ECertif_U4.
Pour cela, le serveur S4 dérive tout d’abord la clé publique parent K_U3 de l’utilisateur/administrateur qui a généré la clé publique enfant EK_U4 de l’utilisateur U4. Ceci est possible lorsqu’il s’agit d’une clé enfant non-renforcée.
Ensuite, le serveur S4 vérifie que le certificat ECertif_U4 de l’utilisateur U4 a bien été signé par l’AC locale du réseau de périphérie sur lequel U3 est un utilisateur/administrateur. Le serveur S4 utilise pour cela la clé publique de l’AC locale K_ACL2. Cette dernière est connues puisque échangée régulièrement au sein du système 10.
De plus, le serveur S4 interroge l’instance centrale de l’IGC 20 pour savoir si le certificat Certif_U3 de l’utilisateur/administrateur U3 est bien valide et n’a pas été révoqué.
Si toutes ces informations sont correctes, alors le certificat temporaire ECertif_U4 de l’utilisateur U4 est révoqué et ce dernier doit enclencher la procédure classique pour obtenir un certificat de la part de l’instance centrale de l’IGC, comme c’est normalement le cas en mode connecté.
Lorsque l’utilisateur temporaire U4 ayant été enregistré par l’utilisateur/administrateur U3 du réseau de périphérie 16 en mode dégradé sur l’AC locale, ACL2, de ce réseau de périphérie, se déplace vers un autre réseau de périphérie qui fonctionne cette fois-ci en mode déconnecté, par exemple le réseau 18, l’authentification de l’utilisateur U4 est faite de la manière suivante.
Si les deux réseaux de périphérie 16 et 18 peuvent communiquer entre eux, un partage de contexte de sécurité est réalisé lors de la fédération de ces deux réseaux de périphérie.
Au cours de ce partage de contexte, sont notamment partagées les clés publiques des autorités de certification locales des deux réseaux de périphérie (pour la validation des certificats éphémères) et avantageusement les clés publiques des utilisateurs/administrateurs de chaque réseau de périphérie (pour vérifier le lien parent / enfant de la génération de clés éphémères).
Au cours de ce partage de contexte, il également préférable de mettre à jour les droits des utilisateurs temporaires dans les annuaires LDAP des deux réseaux de périphérie et les listes des deux réseaux de périphérie relatives à la validité/révocation des certificats des utilisateurs temporaires.
- un type de personnalité particulier d’un utilisateur donné UT’, par exemple un niveau d’ouverture d’esprit, un niveau d’extraversion, un niveau d’empathie, notamment en exploitant certaines traces numériques générées par l’utilisateur UT’ lorsque ce dernier communique à l’aide d’un terminal de communication TC’, par exemple via sa messagerie électronique, via des messages de type SMS, via des vidéos, des commentaires, etc. postés sur des réseaux sociaux, etc.
Le dispositif d’apprentissage DAP’ est identique au dispositif d’apprentissage DAP décrit plus haut. Pour cette raison, il ne sera pas décrit plus avant.
Une fois l’apprentissage effectué, en P11’, le module de modélisation numérique et/ou graphique MDG’ procède à une modélisation numérique et/ou graphique de tous les éléments qui composent l’environnement réel ER’ ou les environnements réels ER1’, ER2’, ER3’, ainsi que de la pluralité d’actions ACT1’, ACT2’, ACT3’ réalisées. La pluralité d’actions modélisées est notée ACTm1’, ACTm2’, ACTm3’.
Dans l’exemple du service de paiement par smartphone, la modélisation concerne non seulement le et/ou les utilisateurs impliqués dans ce service, sous la forme d’avatars respectifs AV_UT’ ou respectivement AV_UT1’, AV_UT2’, AV_UT3’, ou encore d’autres avatars AVU’ ou AVU1’, AVU2’, AVU3’, mais aussi, les objets (smartphone, produit ou service, boutique, etc.), les discussions établies lors de l’utilisation du service, la scène (un centre commercial, une boutique de quartier, etc.) composant l’environnement réel ER’ ou chacun des environnements réels ER1’, ER2’, ER3’.
En P12’, le module MIA’ stocke la pluralité d’actions modélisées ACTm1’, ACTm2’, ACTm3’ dans la base de connaissance BC’, via l’interface d’accès IAC’.