INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
- la base formulatoire représente de 40 à 100%, de préférence de 50 à 90% en poids ;
- la phase aqueuse représentant de 0 à 60%, de préférence de 10 à 50%, en poids ;
sur le poids total du bloc textural (a) représentant 100%.
Avantageusement, le rapport pondéral T, de la quantité de base formulatoire (f) sur la quantité de phase aqueuse (e), règle la texture de la formule finale, selon les règles de formulation suivantes :
T > 1 donne une crème
T =1 donne un sérum
T<1 donne une lotion.
De préférence, la phase aqueuse (e) contient au moins 90% d’eau, de préférence au moins 95% d’eau, de préférence au moins 98% d’eau, sur le poids total de phase aqueuse représentant 100%.
Dans le Kit selon l’invention, ledit au moins un bloc fonctionnel (b) comprend au moins un bloc choisi parmi les blocs suivants :
1) bloc sensoriel ou de fini peau, comprenant notamment des corps gras, tels que des huiles ;
2) bloc d’effet visuel, comprenant notamment des charges et/ou matières colorantes ;
3) bloc d’actif(s), comprenant notamment des agents hydratants, de fermeté, anti-age, clarifiants, ou anti-points noirs ;
4) bloc protecteur, comprenant notamment des filtres anti-UV ;
L'adénosine est notamment disponible dans le commerce sous forme de poudre auprès de la société PHARMA WALDHOF.
Lorsque le rapport d’incident comprend une analyse correcte du scénario et/ou lorsqu’il correspond à un modèle de rapport d’incident attendu, le rapport d’évaluation comprend une métrique indiquant que l’utilisateur a correctement analysé le scénario. Cette métrique peut par exemple être un pourcentage de réussite en fonction du nombre d’actions A identifiées correctement ou de la rapidité d’analyse en fonction du temps de réception du rapport d’incident R_i. Dans le cas contraire, la métrique indique que l’utilisateur n’a pas analysé correctement le scénario.
Le rapport d’évaluation généré à l’étape 36 peut alors être envoyé à l’interface homme-machine 131 pour affichage, ou à un système distant accessible depuis un réseau pour affichage, ou directement affiché par un dispositif implémentant l’orchestrateur 2, ou tout autre moyen pour l’utilisateur de prendre connaissance du rapport d’évaluation. Le rapport d’évaluation peut en outre être stocké dans une base de données, par exemple dans la base de données 25 ou dans une base de données distante, pour accès ultérieur à ce rapport d’évaluation.
En outre, chaque métrique Met se retrouvant dans le rapport d’évaluation peut être stockée dans la base de données 25 ou dans une autre base de données distante, pour permettre une comparaison de l’évolution des métriques lors de formations réalisées plusieurs fois à intervalles de temps séparés. Cela permet de prendre connaissance de l’évolution des connaissances de l’utilisateur.
Plusieurs exemples de scénarios vont maintenant être décrits.
Après le démarrage d’un exercice, l’orchestrateur 2 déclenche le scénario associé à l’exercice dans l’infrastructure informatique simulée 11.
L’utilisateur peut réaliser une investigation au sein de l’infrastructure informatique simulée 11 qui lui est accessible.
A l’issue de l’investigation, l’utilisateur peut : Créer un rapport d’incident R_i qui sera collecté par l’orchestrateur 2. Réaliser une mitigation à l’attaque A ou aux attaques A potentiellement présentes dans le scénario,
L’orchestrateur 2 exécute à intervalle régulier des scripts de tests T permettant de vérifier : Si la ou les potentielles attaques sont mitigées, Si les services impactés par le scénario sont toujours fonctionnels ou redevenus fonctionnels.
A la fin de l’intervalle de temps t associé à cet exercice ou lors d’une mitigation réussie et/ou après le rapport d’incident R_i soumis, la fin du scénario est déclenchée.
Au cours de la réalisation d’un ou plusieurs exercices, l’évaluation E automatisée est effectuée en prenant en compte la différence des réponses du formulaire donnés par l’apprenant avec les résultats attendus dans le modèle de l’exercice ainsi que les retours tests et des et d’utilisateurs légitimes.
La montre une représentation schématique d’un exemple de session de formation composée de 3 scénarios.
L’exemple de session de formation décrit dans la contient 3 scénarios S1 à S3: une attaque par énumération, une connexion à distance légitime et une attaque par déni de service via l’exécution d’un rançongiciel.
Dans le premier exercice de la session d’entrainement d’exemple, le scénario S1 comprend une attaque A par énumération qui cible un compte utilisateur d’un service particulier.
Pendant que l’attaque A par énumération se déroule, l’utilisateur U peut décider de bloquer cette attaque via différentes techniques de mitigation M, comme par exemple : Bloquer l’adresse IP de la source de l’attaque A, Verrouiller le compte utilisateur qui est la destination de l’attaque A.
Pendant l’exécution de cette attaque A, l’orchestrateur 2 va collecter les traces de l’attaque grâce aux tests T afin de déterminer si elle a été bloquée avec succès et va également lancer des scripts d’utilisateurs légitimes et collecter leurs traces grâce aux tests T afin de vérifier s’il y a eu des interruptions de services durant l’intervention de la mitigation.
L’utilisateur U peut également, en parallèle de, avant, ou après la mitigation M, compléter I un rapport d’incident R_i pour statuer de l’état de compréhension du système pendant l’attaque, ou il devra noter les informations clés de l’attaque, comme par exemple sa nature, le système impacté, les informations relatives à l’attaquant et / ou les lignes de fichiers de journalisation (logs) collectés pendant l’attaque.
Dans un mode de réalisation, l'outil inclut une interface de communication pour communiquer avec le distributeur. L'interaction entre l'outil et le distributeur est rendue possible par des dispositifs, notamment un capteur de proximité et la technologie Bluetooth® basse consommation , qui peuvent être utilisés pour allumer et éteindre le distributeur, fournir une distribution automatique et un retour haptique.
Dans un mode de réalisation, l'outil/applicateur possède un outil de diagnostic intégré pour personnaliser la recette et communiquer la recette au distributeur. Dans un mode de réalisation, la recette du distributeur est par exemple commandée par une application sur un téléphone intelligent,. Dans un mode de réalisation, le distributeur fonctionne sans connexion à l'application lorsque les recettes sont communiquées par l'outil.
Dans un mode de réalisation, l'outil inclut une ou plusieurs fonctions de traitement, telles que des traitements par la lumière, par le chaud, le froid, par des vibrations et/ou par des micro-courants.
Ce résumé présente une sélection de concepts sous une forme simplifiée qui sont décrits plus en détail ci-dessous dans la description détaillée. Ce résumé n'est pas destiné à identifier les particularités clés de l'objet revendiqué, ni n’est destiné à être utilisé comme une aide pour déterminer la portée de l'objet revendiqué.
Plus particulièrement, l’invention a pour objet un système, comprenant :
un distributeur configuré pour recevoir un jeu de cartouches de deux cartouches ou plus et pour distribuer une quantité spécifiée de formule à partir de chaque cartouche vers une zone de réception ; et
un outil ayant un applicateur avec une forme configurée pour mélanger les formules distribuées dans la zone de réception et une forme configurée pour recueillir la formulation mélangée et appliquer la formulation sur une surface, dans lequel l'outil est fixé à la surface extérieure du distributeur.
Le système selon l’invention peut comprendre l’une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toute combinaison techniquement possible :
- l'applicateur inclut un centre et des bords s'étendant depuis le centre vers l'extérieur, dans lequel le centre est plus épais que les bords, et les bords sont plus flexibles que le centre.
- l'applicateur a un embout se terminant au sommet du centre, l'applicateur est incliné depuis l’embout vers le bas jusqu'aux bords droit et gauche de l'applicateur.
- le distributeur inclut un commutateur ou un capteur qui est activé lorsque l'outil est retiré du distributeur.
- l'outil inclut :
une mémoire incluant une recette qui détermine la quantité de formule à distribuer pour un type de condition de la peau diagnostiqué ; et
une unité de commande qui permet de communiquer la recette au distributeur.
Par Speedmixer® (notamment DAC400), on entend plus particulièrement un mélangeur fonctionnant sur le principe d’une centrifugeuse asymétrique, par mouvement planétaire avec une accélération de 400G et une vitesse allant de 800 à 2750 tr/min.
Par composition performante, on entend une composition de base robuste aux différentes contraintes possibles (pH, sels, dilution, chauffage, émulsification à froid avec une énergie faible…) que peuvent imposer l'ajout d’autres (blocs de) matières premières en vue d’une diversification de textures.
Par composition « robuste » on entend en particulier une composition qui répond au moins aux critères ci-dessous (tels que définis et mesurés selon les protocoles spécifiés ci-après dans le tableau 1 des exemples):
•être stable à une large gamme de pH, pour permettre la protection anti-microbienne de la formule et l’activité pH-dépendante de certains actifs;
A la suite de cette exécution 51 de l’action, l’utilisateur réalise une investigation sur l’infrastructure informatique simulée 11. Cette investigation comprend au moins la mise en œuvre d’une mitigation à l’étape 42. La mitigation est initiée par l’utilisateur via l’interface homme-machine 131 puis mise en œuvre par la plateforme 1 dans l’infrastructure informatique simulée 11. Comme indiqué précédemment, une mitigation est une réponse au moins partielle à l’action A du scénario exécutée à l’étape 51.
Dans un mode de réalisation l’utilisateur met aussi en œuvre une étape 43 d’envoi d’un rapport d’incident R_i via l’interface homme-machine 131. Un tel rapport d’incident R_i comprend au moins une information sur une modification de l’infrastructure informatique simulée 11 ajoutée au rapport d’incident R_i par l’utilisateur via l’interface homme-machine 131. Cette information sur une modification de l’infrastructure informatique simulée 11 peut être égale ou correspondre à la modification de l’infrastructure informatique simulée 11 résultant de la mise en œuvre de l’action A du scénario, si l’utilisateur a bien identifié l’action A, ou peut être différente de la modification de l’infrastructure informatique simulée 11, si l’utilisateur a mal identifié l’action A. Dans le mode de réalisation dans lequel l’utilisateur a rempli un rapport d’incident R_i, le procédé 3 selon l’invention comprend une étape 32 de réception du rapport d’incident R_i, par le module de réception de rapport d’incident 23 de l’orchestrateur 2. Ce rapport d’incident R_i est ensuite analysé par le module d’évaluation de rapport d’incident 24 comme sera décrit plus loin dans la description. Cette étape 32 de réception de rapport d’incident est représentée en pointillés à la car elle n’est mise en œuvre que dans le mode de réalisation où l’utilisateur est évalué sur les réponses qu’il apporte aux actions A et sur sa capacité d’analyse restituée dans le rapport d’incident R_i.
Le procédé 3 selon l’invention comprend ensuite une étape optionnelle 33 de lancement de tests. Cette étape est optionnelle car elle peut être réalisée, dans un autre mode de réalisation, continuellement par le module de tests 122, qui envoie alors continuellement les résultats des tests à l’orchestrateur 2. Dans encore un autre mode de réalisation, le module de tests 122 ne réalise de tests qu’après l’exécution d’une action A par le module de scénario 121 et/ou après l’exécution d’une mitigation par le module de mitigation 131. Dans un tel cas, le module de tests 122 envoie alors les résultats des tests à l’orchestrateur 2 après qu’ils aient été mis en œuvre. Cette étape 33 comprend l’envoi d’une requête Rq_T, par l’orchestrateur de formation 2, de lancement de tests au module de test 122. La requête comprend au moins une indication du test à exécuter. La requête peut comprendre, dans un mode de réalisation dans lequel les tests T sont stockés en base de données 25, les tests T à lancer par le module de test 122.
Dans un mode de réalisation, les tests T sont stockés par la base de données 25 de l’orchestrateur 2, comme représenté à la . Dans un autre mode de réalisation non représenté, les test T sont stockés par le module de test 122 de la plateforme 1 et lancés suite à la réception de la requête Rq_T par le module de test 122. Un test T lancé sur l’infrastructure informatique simulée 11 simule ou correspond à un test lancé sur une infrastructure informatique réelle.
Un test T est une action de requêtage permettant d’obtenir une information relative à l’état de l’infrastructure informatique simulée 11. Une information relative à l’état de l’infrastructure simulée est par exemple une information sur la disponibilité d’un serveur simulé, une information sur une adresse attribuée, un fichier ou une partie d’un fichier de journalisation (aussi appelé « log »), ou toute autre donnée représentative d’au moins une partie de l’infrastructure informatique simulée 11.
Le procédé 3 selon l’invention comprend ensuite une étape 34 de réception de l’information relative à l’état de l’infrastructure informatique simulée 11 envoyée par le module de test 122 à l’orchestrateur 2. Cette information relative à l’état de l’infrastructure informatique simulée 11 est ensuite analysée par le module d’évaluation de rapport d’incident 24 comme sera décrit plus loin dans la description.
Le procédé 3 selon l’invention comprend ensuite une étape 35 d’arrêt du scénario. En effet, selon l’invention, plusieurs scénarios peuvent être joués avant la génération d’un rapport d’évaluation. Une étape 35 d’arrêt d’un scénario est alors nécessaire pour démarrer le scénario suivant et reprendre le procédé 3 à l’étape 31. Toutes les données servant à la génération du rapport d’évaluation sont alors stockées en base de données 25, et sont utilisées à l’étape 36 pour couvrir tous les scénarios.
L’étape 35 d’arrêt du scénario en cours comprend l’envoi d’une requête, par l’orchestrateur de formation 2, d’arrêt du scénario au module de scénario 121 de la plateforme 1, et est réalisée si au moins une des actions suivantes est réalisée lorsque l’un au moins des évènements suivants survient : si un temps prédéterminé t du scénario est atteint (« t? » à la ), correspondant à un temps maximal pour résoudre ou au moins mitiger, par l’utilisateur, les incidents liés au scénario. si l’orchestrateur de formation 2 reçoit (« R? » à la ), du module de test 121, l’information relative à l’état de l’infrastructure informatique simulée 11, et l’information relative à l’état de l’infrastructure informatique simulée 11 comprend une indication que la modification de l’infrastructure informatique simulée résultant d’un test suite à la mitigation corrige au moins en partie la modification de l’infrastructure informatique simulée 11 résultant des actions A du scénario. Pour vérifier que l’information relative à l’état de l’infrastructure informatique simulée 11 comprend une telle indication, l’orchestrateur 2 peut utiliser son module d’évaluation de mitigation 22, qui compare alors un état initial de l’infrastructure informatique simulée 11 aux modifications réalisées successivement par l’action A puis par la mitigation de l’utilisateur. L’état initial peut avoir été récupéré précédemment par une requête Rq_T auprès du module de test 122 après l’étape de démarrage 31.
Après l’étape d’arrêt du scénario 35, le procédé 3 selon l’invention comprend une étape 36 de génération d’au moins un rapport d’évaluation de la formation de l’utilisateur.
L’étape 36 de génération comprend plusieurs vérifications, notamment des comparaisons, que l’utilisateur a mis au point les bonnes réponses aux actions A du scénario et qu’il a bien analysé le scénario dans le mode de réalisation dans lequel l’utilisateur envoie un rapport d’incident R_i.
L’étape 36 comprend au moins la vérification, par le module d’évaluation de mitigation 22, que l’information relative à l’état de l’infrastructure informatique simulée 11 vérifie une première règle prédéfinie.
Cette première règle prédéfinie est vérifiée lorsque la modification de l’infrastructure informatique simulée 11 résultant de la mitigation par l’utilisateur, c’est-à-dire la deuxième modification, corrige au moins en partie la première modification de l’infrastructure informatique simulée 11 résultant de l’action A du scénario.
Cette vérification peut utiliser les résultats de la vérification précédente ayant abouti à l’arrêt du scénario.
Lorsque l’action a été correctement mitigée, c’est-à-dire lorsque la mitigation réalisée par l’utilisateur correspond à la mitigation attendue ou lorsque le résultat de la mitigation réalisée par l’utilisateur correspond à un état de l’infrastructure informatique simulée 11 attendu, le rapport d’évaluation comprend une métrique indiquant que l’utilisateur a répondu correctement au scénario. Cette métrique peut par exemple être un pourcentage de réussite en fonction du nombre de services rétablis ou des performances de l’infrastructure informatique simulée 11 atteintes après résolution totale ou partielle du scénario. Dans le cas contraire, la métrique indique que l’utilisateur n’a pas répondu correctement au scénario.
Dans le mode de réalisation dans lequel l’utilisateur a rempli et envoyé un rapport d’incident R_i à l’orchestrateur 2, la génération 36 du rapport d’évaluation comprenant en outre au moins la vérification que l’information sur une modification de l’infrastructure informatique simulée issue du rapport d’incident R_i, c’est-à-dire une modification identifiée par l’utilisateur, vérifie une deuxième règle prédéfinie.
La deuxième règle prédéfinie est vérifiée lorsque la modification de l’infrastructure informatique simulée 11 identifiée par l’utilisateur et restituée dans le rapport d’incident R_i correspond à la modification de l’infrastructure informatique simulée 11 résultant de l’action A du scénario. Cela indique alors que l’utilisateur a bien identifié l’action A. Dans un mode de réalisation, la deuxième règle prédéfinie comprend en outre la vérification que le rapport d’incident correspond à un modèle de rapport d’incident prédéfini. Ce modèle est alors stocké par la base de données 25 et est sert de point de comparaison pour le modèle d’incident reçu R_i. Cela permet de s’assurer que l’utilisateur rédige ses rapports d’incident comme attendu.
Au cours d'une étape de réinitialisation, postérieure à la première étape d'exposition, les charges photogénérées, préalablement accumulées aux nœuds de stockage 307 lors de la première étape d'exposition, sont évacuées par les circuits d'intégration 329A du circuit de lecture 103A.
Pour cela, au cours de l'étape de réinitialisation, les commutateurs 321A du circuit de commande 107A sont commandés séquentiellement, les uns après les autres, pour connecter leur borne d'entrée IN à leur première borne de sortie OUT1, le potentiel VON étant ainsi appliqué, via les pistes conductrices 323A, aux grilles des transistors de transfert 309 d'une même première portion de ligne de pixels PIX du premier groupe 101A de sorte que les transistors 309 soient à l'état passant. On transfère ainsi successivement, par exemple portion de ligne après portion de ligne, les charges photogénérées préalablement accumulées aux nœuds de stockage 307 des pixels PIX des différentes premières portions de lignes du premier groupe 101A de pixels PIX de la matrice 101 vers les circuits d'intégration 329A du circuit de lecture 103A.
Plus précisément, on commande par exemple d'abord le commutateur 321A connecté à la piste conductrice 323A de l'une des premières portions de lignes de pixels PIX de la matrice 101, par exemple la première portion de la ligne supérieure dans l'orientation de la , de sorte à appliquer le potentiel VON sur les grilles des transistors de transfert 309 de cette première portion de ligne. Cela a pour effet de transférer, ou vider, les charges photogénérées depuis les nœuds de stockage 307 des pixels PIX de la première portion de ligne vers les circuits d'intégration 329A, chaque nœud 307 étant relié à l'un des circuits 329A du premier circuit de lecture 103A durant cette opération. Les charges photogénérées en provenance des pixels PIX de la première portion de ligne sont alors évacuées via une sortie des circuits 329A. Une fois les charges évacuées, on commande par exemple le commutateur 321A connecté à la première portion de ligne de pixels PIX dont on vient de transférer les charges de sorte à appliquer le potentiel VOFF sur les grilles des transistors de transfert 309 de cette ligne, afin d'isoler les nœuds de stockage 307 des pixels PIX de cette première portion de ligne par rapport aux circuits d'intégration 329A. On répète ensuite les opérations ci-dessus sur une autre première portion de ligne de pixels PIX, par exemple une première portion de ligne adjacente à la première portion de ligne dont on vient de transférer les charges. Toutes les première portions de lignes de pixels PIX du premier groupe 101A de la matrice 101 sont ainsi balayées séquentiellement, par exemple de haut en bas dans l'orientation de la .
À titre d'exemple, l'étape de réinitialisation débute par exemple à un instant où au moins un doigt est placé sur le capteur d'images 100, à l'aplomb du premier groupe 101A de pixels PIX de la matrice 101.
Lors d'une deuxième étape d'exposition, des charges photogénérées par les photodétecteurs 303 des pixels PIX du premier groupe 101A de la matrice 101 sont à nouveau accumulées aux nœuds de stockage 307. À la différence de la première étape d'exposition précédemment décrite, la deuxième étape d'exposition correspond par exemple à une situation où les photodétecteurs 303 des pixels PIX de la matrice 101 sont exposés à de la lumière et où l'on souhaite capturer une image. La deuxième étape d'exposition présente par exemple une durée déterminée ajustée en fonction d'une luminosité ambiante, appelée durée d'intégration. Pour chaque portion de ligne de pixels PIX, la deuxième étape d'exposition débute au moment de l'ouverture (blocage) des transistors de transfert de la portion de ligne, suivant la réinitialisation.
Le procédé de commande du capteur d'images 100 comprend en outre une étape d'acquisition, postérieure à la deuxième étape d'exposition. À la différence de l'étape de réinitialisation, durant laquelle les charges photogénérées accumulées aux nœuds de stockage 307 des pixels PIX de la matrice 101 sont évacuées sans être intégrées, on prévoit, lors de l'étape d'acquisition, d'intégrer les charges photogénérées provenant des pixels PIX des premières portions de lignes du premier groupe 101A de la matrice 101.
Au cours de l'étape d'acquisition, les commutateurs 321A du premier circuit de commande 107A sont commandés séquentiellement, portion de ligne après portion ligne, de façon à transférer les charges photogénérées préalablement accumulées aux nœuds de stockage 307 des pixels PIX des différentes premières portions de lignes du premier groupe 101A de la matrice 101 vers les circuits d'intégration 329A du premier circuit de lecture 103A. La commande des commutateurs 321A s'effectue par exemple de façon analogue à ce qui a été précédemment exposé ci-dessus en relation avec l'étape de réinitialisation.
Bien que l'on ait décrit ci-dessus en relation avec la un cas dans lequel on souhaite capturer une image en utilisant uniquement les pixels PIX du premier groupe 101A de la matrice 101 du capteur d'images 100, les étapes ci-dessus sont bien entendu transposables par la personne du métier à un cas où l'on souhaite capturer une image en utilisant uniquement les pixels PIX du deuxième groupe 101B à partir des indications de la présente description.