INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Dans un mode de réalisation préféré, le polymère précéramique est un polycarbosilane thermodurcissable partiellement réticulé et présentant une température d’extrusion supérieure à 50°C, et de préférence comprise entre 55 et 65°C. Ce polycarbosilane est issu d’un traitement de réticulation thermique ou chimique ayant induit une réticulation partielle et réversible du polymère permettant d’élever sa température d’extrusion et de transition vitreuse. Par réticulation partielle et réversible on entend que le polymère conserve son caractère thermofusible, et en contraste d’une réticulation critique irréversible faisant perdre le caractère thermofusible. Dans un autre mode de réalisation, la matière thermoplastique est choisie parmi une polyméthylaminoborazine (précurseur de nitrure de bore (BN)), un polyalkylaminoalane (précurseur de nitrure d'aluminium), ou un polyborosilazane (précurseur de carbonitrure de bore et de silicium), ces derniers se présentant sous forme solide à température ambiante.
Bien entendu, la température d’extrusion de la composition de l’invention est également contrôlée par l’addition de charges inorganiques. Dans un mode de réalisation préféré, la composition présente une température d’extrusion ≥ à 70°C, et de préférence entre 75 et 120°C.
L’invention propose également de contrôler la taille de particules de charges inorganiques afin d’optimiser la rhéologie de la composition, ainsi que l’homogénéité des pièces céramiques. Dans un mode de réalisation, la composition est destinée à sa mise en forme par FDM, et les charges inorganiques présentent une taille de particule moyenne ≤ à 10 µm, ou ≤ à 5 µm, et de préférence ≤ à 1 µm. Dans un autre mode de réalisation, la composition est mise en forme par un procédé d’injection et/ou pressage et les charges inorganiques présentent une taille de particule moyenne ≤ à 100 µm, et de préférence ≤ à 10 µm.
Une analyse via un dispositif d’IRM 3T à séquences en écho de spin a permis de quantifier la masse maigre et la masse grasse des souris. Comme attendu, les souris nourries avec un régime HFD présentent une quantité de masse maigre significativement plus faible que les souris contrôles (F (2, 22) = 35,11, p<0,001), sans effet de la supplémentation. Cependant, les souris HFD non supplémentées présentent une quantité de masse grasse significativement plus importante que les souris contrôles (F (2, 22) = 36,59, p<0,001). Mais la supplémentation en fraction P permet de diminuer significativement les quantités de masse grasse chez les souris nourries avec un régime HFD (F (2, 22) = 36,59, p<0,01).
La supplémentation en fraction P protège ainsi contre la prise de masse grasse induite par le régime HFD.
B. Impact d’une supplémentation en extrait d’algue du genre Ulva (perméat) sur les paramètres comportementaux
a) Evaluation des troubles de type anxieux
Le comportement de type anxieux des animaux a été évalué dans le test du labyrinthe en croix surélevé. Deux bras opposés sont sans parois (ouverts) et les deux autres ont des parois de 10 cm de haut (fermés). Au centre se situe une plateforme ouverte sur les quatre bras. Les souris sont placées sur la plateforme centrale au début du test et sont libres d’explorer le labyrinthe pendant 5 min. Le temps passé dans les différentes zones a été mesuré par le système de vidéo-tracking SMART (Bioseb). Ce dispositif permet de déterminer l’état d’anxiété des animaux qui vont spontanément éviter les bras ouverts naturellement anxiogènes et préférer les bras fermés. Il a été montré au moyen de ce dispositif que des traitements pharmacologiques par des anxiolytiques étaient efficaces pour contrecarrer l’aversion naturelle procurée par les bras ouverts.
Comme attendu, les animaux nourris avec un régime HFD et non supplémentés présentent une diminution significative du temps passé dans les bras ouverts du labyrinthe en croix surélevé (F (2, 20) = 7,376, p ). La supplémentation en fraction P restaure le temps d’exploration des animaux dans les bras ouverts (F (2, 20) = 7,376, p<0,01). La supplémentation en fraction P protège ainsi de la mise en place des troubles de type anxieux induits par le régime HFD.
Evaluation des altérations mnésiques
Afin d’évaluer les effets chroniques du traitement sur la mémoire, les souris sont testées dans le labyrinthe aquatique de Morris.
Le test du labyrinthe aquatique mis au point par Morris (Morris R. Developments of a water-maze procedure for studying spatial learning in the rat. J Neurosci Methods. 1984 May;11(1):47–60.), permet de mesurer les capacités d’apprentissage et de mémoire spatiale chez l’animal. Dans ce protocole expérimental, cette épreuve met plus particulièrement en jeu la mémoire spatiale de référence dépendante de l’hippocampe. L’animal est placé dans une piscine et doit apprendre à localiser une plateforme refuge en utilisant les indices visuels répartis sur les murs de la salle.
Pour effectuer ce test, nous disposons d’une piscine circulaire (150 cm de diamètre), remplie d’eau (35 cm de profondeur, température : 22±2°C), rendue opaque par l’ajout de peinture blanche. La plateforme (10 cm de diamètre) est immergée à 5 cm sous la surface de l’eau et se trouve à 30 cm du bord de la piscine. Le protocole choisi se déroule en 4 étapes ( ) : 1-l’habituation : permet aux souris de se familiariser à la nage et au fait de monter sur une plateforme. Cette étape se déroule dans une bassine circulaire (65 cm de diamètre) remplie d’eau claire. 2-l’apprentissage indicé : permet d’évaluer la présence de déficits moteurs ou visuels et accentue la familiarisation. Les animaux doivent trouver la plateforme immergée indiquée par un indice. 3-l’apprentissage spatial de référence : les animaux doivent trouver une plateforme immergée et non visible en utilisant les indices visuels distaux. 4-le test de restitution : permet d’évaluer la mémoire spatiale. Les souris sont placées dans la piscine en absence de plateforme et doivent chercher pendant 1 min l’endroit où la plateforme était initialement positionnée.
Les déplacements de la souris sont enregistrés par un système de vidéo-tracking (SMART), qui permet pour chaque essai d’obtenir la latence pour atteindre la plateforme ainsi que la distance totale parcourue dans la piscine. La vitesse de nage des souris est déduite de ces valeurs. Le temps passé dans les différents quadrants ainsi que la distance parcourue et le nombre d’entrées dans le quadrant cible sont calculés.
Dans notre protocole, les animaux contrôles nourris avec un régime équilibré ne présentent pas d’altération cognitive et discriminent de façon significative le quadrant cible par rapport à une exploration au hasard (p ). De façon intéressante, la supplémentation en fraction P permet de restaurer les capacités cognitives des animaux puisqu’ils différencient de façon statistiquement significative le quadrant cible par rapport au hasard (p<0,05). Il n’y a pas de différence d’apprentissage entre les groupes.
DISPOSITIF AEROSOL DELIVRANT UNE COMPOSITION A BASE DE POLYCONDENSAT D’OXYDE D’ETHYLENE ET D’OXYDE DE PROPYLENE ET DE POLYMERE FIXANT La présente invention concerne un dispositif aérosol comprenant une composition de coiffage des fibres kératiniques qui peut être dispensée sans gaz propulseur, par pulvérisation mécanique.
Les produits de coiffage sont habituellement utilisés pour construire, structurer la coiffure et lui apporter une tenue. Ils se présentent usuellement sous forme de lotions, gels, mousses, crèmes, sprays, etc…et sont généralement appliquées sur des cheveux, lesquels sont mis en forme avant d’effectuer un brushing ou un séchage.
Les produits de coiffage en dispositif aérosol actuellement connus ne donnent toutefois pas une entière satisfaction, autant sur la distribution du produit de coiffage que sur le produit de coiffage lui-même.
Lorsque la vérification réussie, l’utilisateur/administrateur U3 est reconnu comme ayant la permission d’envoyer des requêtes à l’autorité de certification locale. Les informations de son certificat sont avantageusement mémorisées pour utilisation ultérieure par l’autorité de certification locale, notamment la clé publique K_U3 du certificat Certif_U3.
Une utilisation ultérieure possible consiste par exemple, dans une étape 430, à ce que l’utilisateur/administrateur U3 se connecte à l’annuaire LDAP pour donner des droits d’accès à l’utilisateur temporaire U4, comme des droits d’accès à tout ou partie des services offerts par le ou les serveurs de bordure S2 du réseau de périphérie.
La illustre, dans sa partie basse, les étapes d’un procédé 500 d’authentification d’un utilisateur temporaire, comme l’utilisateur U4, disposant d’un certificat éphémère auprès d’un serveur offrant un service, comme le serveur S2, d’un réseau de périphérie en mode dégradé.
Lorsque l’utilisateur temporaire U4 cherche à accéder à un service offert par le serveur de bordure S2, alors, dans une étape 550, il se connecte au serveur S2 et lui transmet son certificat éphémère ECertif_U4, afin que le serveur S2 puisse l’authentifier.
Dans une étape 560, le serveur S2 vérifie l’authenticité du certificat éphémère ECertif_U4, en vérifiant l’autorité de certification locale qui l’a signé et avantageusement le parent qui a généré la clé publique EK_U4 à partir de sa propre clé, à savoir l’utilisateur/administrateur. Le serveur S2 peut éventuellement consulter les informations de validité/révocation contenues dans l’annuaire LDAP.
Pour ce faire, le serveur S2 utilise la clé publique de l’autorité de certification locale ACL2 ayant émis le certificat ECertif_U4, en l’occurrence la clé publique K_ACL2 de l’ACL2.
De plus, avantageusement, le serveur S2 utilise la clé publique K_U3 de l’utilisateur/administrateur U3 pour vérifier la dérivation de clés, c’est-à-dire qu’il y a bien cohérence entre la clé publique parent (celle de U3) et clé publique enfant (celle de U4).
Le serveur S2 connaît la clé publique K_U3 par exemple en interrogeant l’annuaire local LDAP.
Lorsque l’authentification échoue, le serveur rejette la demande de connexion de l’utilisateur temporaire.
Lorsque l’authentification réussit, dans une étape 570, le serveur utilise les informations contenues dans le certificat éphémère ECertif_U4 (notamment la clé publique EK_U4) pour crypter les communications avec l’utilisateur temporaire (le serveur indiquant à cet utilisateur sa clé publique de manière à lui permettre de crypter les communications).
En variante, le serveur S2 peut, après avoir vérifié l’authenticité de l’émetteur du certificat (étape 560), interroger l’annuaire LDAP pour savoir si le certificat éphémère ECertif_U4 est valide et/ou est non-révoqué (étape similaire aux étapes 230-240-250).
On notera que c’est bien la clé K_U3 qui est utilisée pour l’authentification de l’utilisateur/administrateur U3 auprès de l’ACL2 et la clé K_ACL2 pour l’authentification de l’utilisateur temporaire U4 auprès du serveur S2.
Pour la mise en œuvre de l’étape 330 de génération de clés éphémères par l’équipement de l’utilisateur/administrateur, ce dernier exécute un module de dérivation de clé 61.
En cryptographie, une fonction de dérivation de clé est une fonction qui permet de dériver une ou plusieurs clés en utilisant une fonction pseudo-aléatoire. La fonction de dérivation de clé peut être utilisée pour renforcer des clés en les étirant ou pour obtenir des clés d’un certain format.
En particulier, les algorithmes de dérivation de clés enfant – CKD (en anglais « Child Key Derivation ») permettent, à partir de la clé d’un parent et d’un indice , de calculer une clé enfant. Par exemple, l’algorithme « BIP32 » est utilisé.
Deux opérations de dérivation de clé sont réalisées par le module de dérivation de clé 61: la première permet de dériver la clé publique enfant (i.e. la clé publique éphémère EK_U4) à partir de la clé publique parent (i.e. la clé publique K_U3) ; et la seconde permet de dériver la clé privée enfant (i.e. la clé privée éphémère Ek_U4) à partir de la clé privée parent (i.e. la clé privée k_U3).
En particulier, le terminal 5 ou l’application comprend des moyens pour : calculer un arbre de hachage, par exemple un arbre de Merkle (pour l’anglais « Merkle tree ») à partir du jeton non-fongible 2 lui-même ou d’un fichier numérique 2’ lié audit jeton non-fongible, par exemple une photographie ou une image électronique dudit jeton non-fongible s’il s’agit d’un bien matériel ; enregistrer cet arbre de hachage dans le coffre-fort de gestion 16, en tant qu’information liée audit jeton non-fongible, en l’associant à l’adresse 10 et à la valeur rationnelle de rétribution à verser au créateur 1 en cas de vente dudit jeton non-fongible.
Sur la , le terminal 5 effectue cet enregistrement en réalisant une étape 27 d’écriture pour inscrire l’arbre de hachage et les informations à lui associer dans le coffre-fort de gestion 16. Cette inscription est irréversible, l’arbre de hachage ne pouvant plus être changé par la suite.
En parallèle, le procédé prévoit : l’envoi par le créateur 1 au serveur répertoire 23 d’une notification 28 comprenant le fichier numérique 2’ lié au jeton non-fongible 2 et les adresses numériques respectives 10, 17 dudit créateur et du coffre-fort de gestion 16 dudit créateur sur la chaîne de blocs ; la comparaison par le serveur répertoire 23 dudit fichier numérique avec l’arbre de hachage enregistré dans le coffre-fort de gestion 16 ; en cas de succès de cette comparaison, l’enregistrement dudit fichier numérique dans une base de données 24 dudit serveur répertoire, en l’associant aux adresses numériques 10, 17.
En relation avec la , le terminal 5 comprend des moyens pour envoyer au serveur répertoire 23 : une requête 29 pour se connecter audit serveur répertoire, qui contient l’adresse numérique 10 de son coffre-fort personnel 9 ; après s’être connecté audit serveur répertoire, la notification 28 mentionnée ci-dessus, afin de requérir l’enregistrement du fichier informatique 2’ lié à son jeton-non fongible 2 dans ledit serveur répertoire.
Le serveur répertoire 23 lance ensuite successivement : une procédure 30 pour contrôler le référencement des coffres-forts 9, 16 du créateur 1 dans le coffre-fort central 14, en vérifiant la présence de leurs adresses numériques 10, 17 respectives dans ledit coffre-fort central ; une procédure 31 pour comparer le fichier informatique 2’ communiqué dans la notification 28 avec l’arbre de hachage inscrit dans le coffre-fort de gestion 16 ; une procédure 32 pour enregistrer le fichier 2’ dans sa base de données 24 en cas de succès de cette comparaison ; l’envoi au terminal 5 d’une notification 33 pour indiquer l’état d’enregistrement de son fichier 2’ dans ledit serveur répertoire.
La représente plus en détail la connexion du créateur 1 au serveur répertoire 23 préalablement au référencement d’un nouveau jeton-non fongible 2, 2’ créé par ledit créateur dans ledit serveur répertoire et dans le coffre-fort de gestion 16 associé audit créateur. En particulier, le serveur répertoire 23 comprend une interface de programmation 34 spécialement adaptée pour gérer la connexion du créateur 1 et l’authentification de son coffre-fort de gestion 16 nécessaires au référencement des nouveaux jetons non-fongibles 2.
En premier lieu, le créateur 1 envoie via son terminal 5 la requête en connexion 29 représentée sur la , et contenant l’adresse numérique 10 de son coffre-fort personnel 9. L’interface de programmation 34 reçoit la requête 29 puis : vérifie le référencement du coffre-fort personnel 9 du créateur 1 sur la chaîne de blocs, en vérifiant notamment la présence de son adresse numérique 10 dans le coffre-fort central 14 et dans une base de données 24 dudit serveur répertoire ; envoie en retour au terminal 5 une notification 35 contenant un premier numéro généré aléatoirement par ladite interface de programmation.
Le terminal 5 ou l’application lance ensuite une procédure 36 adaptée pour : générer un second numéro aléatoire ; signer les premier et second numéros aléatoires au moyen de la clé privée 7a liée audit terminal ; envoyer à l’interface de programmation 34 une notification 37 contenant l’adresse numérique 10, les numéros aléatoires signés et l’adresse numérique 17 du coffre-fort de gestion 16 associé audit créateur.
A la réception de cette notification 37, l’interface de programmation 34 : vérifie la signature des numéros aléatoires pour identifier la clé publique 7b liée à la clé privée 7a ayant servi à ces signatures, et vérifie ensuite la concordance entre cette clé publique 7b et l’adresse numérique 10 envoyée dans la notification 37 ; vérifie notamment la présence dans le coffre-fort de gestion 16 la présence de l’adresse numérique 10 liée au créateur 1, afin de vérifier son enregistrement en tant qu’adresse parente, attestant l’appartenance de ce coffre-fort de gestion 16 au créateur 1 ; accorde audit créateur 1 l’accès à la base de données 24 en cas de succès de cette vérification, et notamment l’accès à une section 24’ de ladite base contenant spécifiquement l’ensemble des fichiers 2’ préalablement enregistrés par ledit créateur, afin de permettre audit créateur d’y enregistrer de nouveaux fichiers 2’.
Lors de la création d’un jeton non-fongible 2, le procédé prévoit plus particulièrement, grâce à des moyens techniques adaptés intégrés au terminal 5 ou à l’application qui y est installée, de : enregistrer au moins un arbre de hachage lié audit jeton non-fongible dans une entrée 38 d’une liste principale 39 d’indexation au sein du coffre-fort de gestion 16, en l’associant à un identifiant unique 40 pour ledit jeton non-fongible et à une valeur rationnelle d’un montant d’achat à verser en rétribution au créateur 1 lors d’une vente dudit jeton non-fongible ; générer pour ledit jeton non-fongible, après enregistrement de son arbre de hachage dans la liste principale 39 : une première sous-liste secondaire 40a de vente dudit jeton non-fongible, et d’enregistrer dans une première entrée 41 de ladite sous-liste de vente l’adresse numérique 10 dudit créateur sur la chaîne de blocs, ainsi qu’une information sur un montant en cryptomonnaie requis pour l’achat dudit jeton non-fongible ; une deuxième sous-liste secondaire 40b de détention dudit jeton non-fongible, et d’enregistrer dans une première entrée 42 de ladite sous-liste de détention l’adresse numérique 10 dudit créateur sur la chaîne de blocs, en tant que propriétaire du jeton non-fongible 2.
En particulier, les identifiants uniques 40 sont listés successivement dans la première cellule 43 de respectivement une entrée 38 de la liste principale 39, ladite liste étant incrémentée au fur et à mesure du remplissage des entrées 38, qui se fait à chaque fois qu’un jeton non-fongible 2 est référencé dans le coffre-fort de gestion 16. Le nombre d’entrées 38 disponibles dans la liste principale 39 correspond au nombre maximal de jeton non-fongibles 3 pouvant être gérés grâce au coffre-fort 16, et est fixé par le créateur 1 dans la liste de variables présentée précédemment.
Chaque entrée 38 de la liste principale 39 comprend plusieurs cellules 43a, 43b alignées horizontalement, en plus de la première cellule 43 de gauche de ladite entrée, indiquant l’identifiant unique 40 attribué au jeton non-fongible 2 lors de sa création, ces autres cellules 43a, 43b pouvant comprendre respectivement une information parmi les informations suivantes : l’arbre de hachage du jeton non-fongible 2, généré sur le terminal 5 comme indiqué précédemment ; le nom du jeton non-fongible 2 ; la description du jeton non-fongible 2 ; le cas échéant, l’adresse d’un lieu sécurisé où est conservé le jeton non-fongible 2, s’il s’agit d’un bien physique ; la valeur rationnelle de rétribution (pour l’anglais « retribution rate »), qui correspond par exemple à un pourcentage du montant d’achat du jeton non-fongible 2 devant revenir à son créateur 1 en cas de vente ou de cession dudit jeton à tout nouvel acheteur.
En relation avec la , la première entrée 41 de la sous-liste 40a de vente d’un jeton non-fongible 2 donné comprend plusieurs cellules 41a-41i alignées horizontalement, dont la première cellule de gauche 41a qui comprend un indicatif « 1 » marquant la création dudit jeton non-fongible, chacune des autres cellules 41b-41i pouvant comprendre respectivement une information parmi les informations suivantes : l’adresse numérique 10 du créateur 1, en tant que propriétaire du jeton non-fongible 2 ; le marqueur temporel de création de la transaction ; le code d’affichage de cette transaction dans le serveur répertoire 23, choisi parmi : le code « 0 », indiquant que cette transaction ne doit pas être affichée sur le serveur 23 (et donc ne doit pas être lisible par tout utilisateur 3 consultant ledit serveur) ; le code « 1 », indiquant que ladite transaction peut être affichée sur le serveur 23 pour pouvoir être lisible par tout utilisateur 3, 1 ; le code de vente de cette transaction, choisi parmi : un code prédéfini tel que : le code « 0 », indiquant que le jeton non-fongible 2 n’est pas à vendre ; ou le code « 1 », indiquant que n’importe quel utilisateur 3 fournissant le montant en cryptomonnaie requis peut acheter le jeton non-fongible 2 ; ou le code « 2 », indiquant que le jeton non-fongible 2 est vendu aux enchères ; ou un code personnalisé, consistant par exemple en l’adresse numérique 11 d’un utilisateur 3 auquel la vente de ce jeton non-fongible 2 est exclusivement réservée ; une donnée alphanumérique correspondant au montant en cryptomonnaie requis pour l’achat du jeton non-fongible 2 ; un jeton de paiement, sur lequel le montant en cryptomonnaie requis doit être transféré pour acheter le jeton non-fongible 2 au créateur 1 ; un marqueur temporel de délai d’achat, au-delà de laquelle la transaction doit être finalisée ; une donnée alphanumérique indiquant la fonction de la transaction, par exemple une vente simple, une mise à jour d’une transaction précédente, une vente aux enchères….
De même, comme représenté la , la première entrée 42 de la sous-liste 40b de détention de ce même jeton non-fongible 2 comprend également plusieurs cellules 42a-42e alignées horizontalement, dont la première cellule de gauche 42a qui comprend un indicatif « 1 » marquant la création dudit jeton non-fongible, chacune des autres cellules 42b-42e pouvant comprendre respectivement une information parmi les informations suivantes : l’adresse numérique 10 du créateur 1 sur la chaîne de blocs, en tant que propriétaire et responsable actuel du jeton non-fongible 2 ; une chaîne de caractères alphanumériques identifiant spécifiquement l’enregistrement de cette entrée 42 ; une chaîne de caractères alphanumériques correspondant à un texte lisible par un utilisateur humain 1, 3, et pouvant notamment être renseigné manuellement par le créateur 1 propriétaire du jeton non-fongible 2, indiquant la localisation physique dudit jeton non-fongible (s’il s’agit d’un bien physique) ; le marqueur temporel d’enregistrement de cette entrée 42.
Comme représenté sur les figures 5 et 6, tout utilisateur 3 présent sur la chaîne de blocs peut consulter le serveur répertoire 23 pour identifier les créateurs 1 de jetons non-fongibles 2, afin d’obtenir la liste des coffres-forts de gestion 16 d’au moins un créateur 1 donné, et ainsi consulter les données relatives à un jeton non-fongible 2 dudit créateur qu’il souhaite éventuellement acheter.
Sur la , l’utilisateur 3 se connecte à la chaîne de blocs au moyen de son terminal 6, qui peut notamment comprendre une application et/ou des moyens techniques similaires à ceux installé(e)s sur le terminal 5 du créateur 1, puis, grâce à des moyens techniques spécifiques installés sur ledit terminal ou dans ladite application, envoie une requête 45 au serveur répertoire 23, qui envoie en retour audit terminal une notification 46 contenant les adresses numériques 10, 10a, 10b de l’ensemble des créateurs 1 référencés dans ledit serveur répertoire.