INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Ce codage neuro-flou est réalisé en plusieurs étapes successives : définition des sous-groupes de caractéristiques, choix et placement des cellules de codage affectées à chaque groupe, détermination des paramètres de la région d'influence de chaque cellule.
Les détails de cette procédure sont exposés dans le document référencé [8].
Une fois les données codées, elles sont analysées par le perceptron multicouche qui en calcule la classe.
' Le système expert flou Dans un mode de réalisation le système de l'invention comporte une seule branche de traitement basée sur un tel système expert flou Le système expert flou (expert SEF) s'applique également aux données de haut niveau.
Dans la figure 11, on représente un système expert flou à cinq règles (une règle par ligne).
Pour chaque ligne, les cinq colonnes de gauche représentent les prémisses et correspondent à cinq entrées : l'heure, la latitude, la longitude, la magnitude et la date. Les prémisses sont composées d'ensembles flous en forme de gaussiennes qui recouvrent les domaines de la variable d'entrée conduisant à un renforcement de l'activité de la règle.
Les codes JVM produits par les compilateurs Java existants satisfont à différents critères, lesquels sont énoncés ci-après : Cl : les arguments de chaque instruction appartiennent bien aux types attendus par cette instruction ; C2 : la pile ne déborde pas ;
C'3 : pour chaque instruction de branchement, le type de la pile au niveau de ce branchement est le même qu'au niveau des cibles possibles pour ce branchement ; C'4 : une valeur de type t écrite dans un registre en un point du code et relue depuis ce même registre en un autre point du code est toujours relue avec le même type t ; La mise en #uvre du procédé de vérification objet de la présente invention, implique que les critères C'3 et C'4 vérifiés par le code objet soumis à vérification soient remplacés par les critères C3 et C4 ci-après : C3 : la pile est vide à chaque instruction de branchement et à chaque cible de branchement ; C4 : un même registre est utilisé avec un seul et même type dans tout le code d'un sous-programme.
En référence aux critères précités, on indique que les compilateurs Java garantissent seulement les critères plus faibles C'3 et C'4, le processus de vérification objet de la présente invention et le protocole de gestion correspondant garantissent en fait des critères C3 et C4 plus contraignants permettant d'assurer la sécurité d'exécution et de gestion des appliquettes.
La notion de normalisation recouvrant la transformation des codes en codes normalisés peut présenter différents aspects, dans la mesure où le remplacement des critères C'3 et C'4 par les critères C3 et C4, conformément au processus de vérification objet de la présente invention, peut être réalisé de manière indépendante pour assurer que la pile est vide à chaque instruction de branchement et à chaque cible de
branchement, respectivement que les registres ouverts par l'appliquette sont typés, à chaque registre ouvert correspondant un seul type de donnée attribué pour l'exécution de l'appliquette considérée, ou, au contraire, de manière conjointe, afin de 'satisfaire à l'ensemble du processus de vérification objet de la présente invention.
Le procédé de transformation d'un code objet en code objet normalisé selon l'invention sera en conséquence décrit selon deux modes de mise en #uvre distincts, un premier mode de mise en #uvre correspondant à la transformation d'un code objet satisfaisant aux critères Cl, C2, C'3, C'4 en un code objet normalisé satisfaisant aux critères Cl, C2, C3, C'4 correspondant à un code normalisé à instruction de branchement ou cible de branchement vide, puis, selon un deuxième mode de réalisation, dans lequel le code objet classique satisfaisant aux mêmes critères de départ, est transformé en un code objet normalisé satisfaisant aux critères Cl, C2, C'3, C4 par exemple correspondant à un code normalisé faisant appel à des registres typés.
Le premier mode de réalisation du procédé de transformation de code, objet de la présente invention, sera maintenant décrit en liaison avec la figure 4a. Dans le mode de réalisation illustré en figure 4a, le code classique de départ est réputé satisfaire aux critères C1+C2+C'3 et le code normalisé obtenu du fait de la transformation est réputé satisfaire aux critères C1+C2+C3.
Selon la figure précitée, le procédé de transformation consiste, pour chaque instruction courante Ii du code ou du sous-programme, à annoter chaque
instruction, en une étape 500, par le type de données de la pile avant et après l'exécution de cette instruction.
Les données d'annotation sont notées AIi et sont associées par la relation Ii#AIi en instruction courante considérée.
Les données d'annotation sont calculées au moyen d'une analyse du flot des données relatif à cette instruction.
Les types de données avant et après exécution de l'instruction sont notés tbei et tael respectivement. Le calcul des données d'annotation par analyse du flot des données est un calcul classique connu de l'homme du métier et, à ce titre, ne sera pas décrit en détail.
L'opération réalisée à l'étape 500 est illustrée au tableau T6 introduit en annexe dans lequel, pour une appliquette ou sous-programme d'appliquette comportant 12 instructions, les données d'annotation Ali constituées par les types des registres et les types de la pile sont introduites.
L'étape 500 précitée est alors suivie d'une étape 500a consistant à positionner l'index i sur la première instruction Ii=Il . L'étape 500a est suivie d'une étape 501 consistant à détecter, au sein des instructions et de chaque instruction courante Ii, l'existence de branchements notés IB ou de cibles de branchement CIB pour lesquels la pile d'exécution n'est pas vide. Cette détection 501 est réalisée par un test conduit à partir des données d'annotation Ali du type des variables de pile alloué à chaque instruction courante, le test étant noté pour l'instruction courante : Ii est une IB ou CIB et pile(AI) vide.
Sur réponse positive au test 501, c'est-à-dire en présence d'une détection d'une pile d'exécution non vide,
le test précité est suivi d'une étape consistant à insérer des instructions de transfert des variables de pile de part et d'autre de ces branchements IB ou de ces cibles de branchement CIB, afin de vider le contenu de la pile d'exécution dans des registres temporaires avant ce branchement et de rétablir la pile d'exécution à partir des registres temporaires après ce branchement. L'étape d'insertion est notée 502 sur la figure 4a. Elle est suivie d'une étape de test 503 d'atteinte de la dernière instruction noté Ii=dernière instruction ? Sur réponse négative au test 503, une incrémentation 504 i=i+l est effectuée pour passage à l'instruction suivante et retour à l'étape 501. Sur réponse positive au test 503, une étape de Fin est lancée. Sur réponse négative au test 501,1e procédé de transformation est poursuivi par un branchement vers l'étape 503 en l'absence d'insertion d'instruction de transfert. La mise en #uvre du procédé de transformation d'un code classique en un code normalisé à instruction de branchement à pile vide tel que représenté en figure 4a, permet d'obtenir un code objet normalisé pour le même fragment de programme de départ dans lequel la pile des variables de pile est vide à chaque instruction de branchement et à chaque instruction de cible de branchement, en l'absence de modification de l'exécution du fragment de programme. Dans le cas d'un environnement Java, les instructions de transfert de données entre pile et registre sont les instructions load et store de la machine virtuelle Java.
On utilise de préférence un agent tensioactif anionique choisi parmi les alkyl(C12-C14) sulfates de sodium, de triéthanolamine ou d'ammonium, les alkyl (C12-C14)éthersulfates de sodium, de triéthanolamine ou d'ammonium oxyéthylénés à 2,2 moles d'oxyde d'éthylène, le cocoyl iséthionate de sodium et l'alphaoléfine(C14-C16) sulfonate de sodium et leurs mélange avec : - soit un agent tensioactif amphotère tel que les dérivés d'amine dénommés disodiumcocoamphodipropionate ou sodiumcocoamphopropionate commercialisés notamment par la société RHONE POULENC sous la dénomination commerciale "MIRANOL C2M CONC" en solution aqueuse à 38 % de matière active ou sous la dénomination MIRANOL C32, - soit un agent tensioactif amphotère de type zwittérionique tel que les alkylbétaïnes en particulier la cocobétaïne commercialisée sous la dénomination "DEHYTON AB 30" en solution aqueuse à 32 % de MA par la société HENKEL.
La composition de l'invention peut également contenir au moins un additif choisi parmi les épaississants, les parfums, les agents nacrants, les conservateurs, les filtres solaires siliconés ou non, les vitamines, les provitamines, les polymères anioniques ou non ioniques, les protéines non cationiques, les hydrolysats de protéines non cationiques, l'acide méthyl-18 eicosanoique, les hydroxyacides, le panthénol, et tout autre additif classiquement utilisé dans le domaine cosmétique qui n'affecte pas les propriétés des compositions selon l'invention .
La quantité et la qualité de la base lavante sont celles suffisantes pour conférer à la composition finale un pouvoir moussant et/ou détergent satisfaisant.
Ainsi, selon l'invention, la base lavante peut représenter de 4 % à 50 % en poids, de préférence de 6 % à 35 % en poids, et encore plus préférentiellement de 8 % à 25 % en poids, du poids total de la composition finale.
Les compositions de l'invention peuvent également se présenter sous forme d'aprèsshampooing à rincer ou non, de compositions pour permanente, défrisage, coloration ou décoloration, ou encore sous forme de compositions à rincer, à appliquer avant ou après
une coloration, une décoloration, une permanente ou un défrisage ou encore entre les deux étapes d'une permanente ou d'un défrisage.
Les compositions de l'invention peuvent encore se présenter sous la forme de compositions lavantes pour la peau, et en particulier sous la forme de solutions ou de gels pour le bain ou la douche ou de produits démaquillants.
Toutefois, la présente invention est applicable à tout système embarqué reprogrammable par l'intermédiaire d'un téléchargement d'appliquette écrite dans le code d'une machine virtuelle comprenant une pile d'exécution, des registres ou variables locales et dont le modèle d'exécution est fortement typé, chaque instruction du code de l'appliquette ne s'appliquant qu'à des types de données spécifiques. Le protocole de gestion d'un fragment de programme téléchargé sur un système embarqué reprogrammable, objet de la présente invention, sera maintenant décrit de manière plus détaillée en liaison avec la figure 2.
En liaison avec la figure précitée, on indique que le code objet constitutif du fragment de programme ou appliquette est constitué par une suite d'instructions exécutables par le microprocesseur du système embarqué par l'intermédiaire de la machine virtuelle précédemment mentionnée. La machine virtuelle permet d'interpréter le code objet précité. Le système embarqué est interconnecté
à un terminal par l'intermédiaire d'une liaison série par exemple.
En référence à la figure 2 précédemment mentionnée, le protocole de gestion objet de la présente invention consiste au moins, au niveau du système embarqué, à détecter en une étape 100a, 100b, une commande de téléchargement de ce fragment de programme. Ainsi, l'étape 100a peut consister en une étape de lecture de la commande précitée et l'étape 100b en une étape de test de la commande lue et de vérification de l'existence d'une commande de téléchargement.
Sur réponse positive à l'étape de détection 100a, 100b précitée d'une commande de téléchargement, le protocole objet de la présente invention consiste ensuite à lire à l'étape 101 le code objet constitutif du fragment de programme considéré et à mémoriser temporairement le code objet précité dans la mémoire réinscriptible du système informatique embarqué. L'étape de lecture du code objet et de mémorisation temporaire de ce dernier dans la mémoire réinscriptible est désignée par chargement du code de l'appliquette sur la figure 2.
L'étape précitée est alors suivie d'une étape 102 consistant à soumettre l'ensemble du code objet mémorisé temporairement à un processus de vérification, instruction par instruction, du code objet précité.
Le processus de vérification consiste au moins en une étape d'initialisation de la pile des types et du tableau des types de données représentant l'état de la machine virtuelle au début de l'exécution du code objet mémorisé temporairement, ainsi qu'en une succession d'étapes de vérification instruction par instruction par
discrimination de l'existence, pour chaque instruction courante, notée Ii, d'une cible telle qu'une cible d'instruction de branchement notée CIB, une cible d'appel d'un gestionnaire d'exceptions ou une cible d'un appel de sous-routine. Une vérification et une actualisation de l'effet de l'instruction courante Il sur la pile des types et sur le tableau des types de registres est effectuée.
Lorsque la vérification est réussie à l'étape 103a, le protocole objet de la présente invention consiste à enregistrer à l'étape 104 le fragment de programme téléchargé dans un répertoire de fragments de programmes disponibles et à envoyer à l'étape 105 au lecteur un accusé de réception positif.
Au contraire, dans le cas d'une vérification non réussie du code objet à l'étape 103b, le protocole objet de l'invention consiste à effacer à l'étape 106 le fragment de programme enregistré momentanément en l'absence d'enregistrement de ce fragment de programme dans le répertoire de fragments de programmes disponibles et, à une étape 107, à adresser au lecteur un code d'erreur. Les étapes 107 et 105 peuvent être réalisées soit séquentiellement après les étapes 106 respectivement 104, soit en opération multitâche avec celles-ci.
En référence à la même figure 2, sur réponse négative à l'étape consistant à détecter une commande de téléchargement à l'étape 100b, le protocole objet de la présente invention consiste à détecter, en une étape 108, une commande de sélection d'un fragment de programme disponible dans un répertoire de fragments de programmes et, sur réponse positive à l'étape 108, la sélection d'un fragment de programme disponible étant détectée, à appeler
à l'étape 109 ce fragment de programme disponible sélectionné en vue de son exécution. L'étape 109 est alors suivie d'une étape d'exécution 110 du fragment de programme disponible appelé par l'intermédiaire de la machine virtuelle en l'absence de toute vérification dynamique de types de variables, des droits d'accès aux objets manipulés par le fragment de programme disponible appelé ou du débordement de la pile d'exécution lors de l'exécution de chaque instruction.
Dans le cas où une réponse négative est obtenue à l'étape 108, cette étape consistant à détecter une commande de sélection d'un fragment de programme disponible appelé, le protocole objet de la présente invention consiste à procéder, à une étape 111, au traitement des commandes standard du système embarqué.
En ce qui concerne l'absence de vérification dynamique de type ou de droit d'accès aux objets de type JavaCard par exemple, on indique que cette absence de vérification ne compromet pas la sûreté de la carte car le code de l'appliquette a nécessairement passé avec succès la vérification.
D'une manière plus spécifique, on indique que la vérification de code effectuée, conformément au procédé objet de l'invention, sur la carte à microprocesseur ou sur le système informatique embarqué est plus sélective que la vérification habituelle de codes pour la machine virtuelle Java telle que décrite dans l'ouvrage intitulé "The Java Virtual Machine Specification" précédemment mentionné dans la description.
Toutefois, tout code de la machine virtuelle Java correct au sens du vérificateur Java traditionnel peut
de durée de vie IDjk un numéro de registre rk de telle manière que deux intervalles adjacents dans le graphe d'interférences reçoivent des numéros de registres différents.
Cette opération peut être réalisée à partir de tout processus adapté. A titre d'exemple non limitatif, on indique qu'un processus préférentiel peut consister : a) à choisir un sommet de degré minimal dans le graphe d'interférences, le degré minimal étant défini comme un nombre de sommets adjacents minimal, et de le retirer du graphe. Cette étape peut être répétée jusqu'à ce que le graphe soit vide. b) Chaque sommet précédemment retiré est réintroduit dans le graphe d'interférences dans l'ordre inverse de leur retrait, le dernier enlevé étant le premier réintroduit et successivement dans l'ordre inverse de l'ordre de retrait. Ainsi, à chaque sommet réintroduit, peut être attribué le plus petit numéro de registre qui est différent des numéros attribués à tous les sommets adjacents.
Enfin, par l'étape 602, représentée en figure 4b, le processus de transformation et de réallocation réécrit les instructions d'accès aux registres figurant dans le code du sous-programme de l'appliquette considérée. Un accès à un registre donné dans l'intervalle de durée de vie correspondant est remplacé par un accès à un registre différent dont le numéro a été attribué pendant la phase d'instanciation encore désignée par phase de coloriage.
Une description plus détaillée d'un système informatique embarqué permettant la mise en #uvre du protocole de gestion et du processus de vérification d'un
fragment de programme ou appliquette conforme à l'objet de la présente invention et d'un système de développement d'une appliquette sera maintenant donnée en liaison avec la figure 6.
En ce qui concerne le système embarqué correspondant portant la référence 10, on rappelle que ce système embarqué est un système du type reprogrammable comportant les éléments essentiels tels que représentés en figure lb. Le système embarqué précité est réputé interconnecté à un terminal par une liaison série, le terminal étant lui-même relié par exemple par l'intermédiaire d'un réseau local, le cas échéant d'un réseau lointain, à un ordinateur de développement de l'appliquette portant la référence 20. Sur le système embarqué 10 fonctionne un programme principal qui lit et exécute les commandes envoyées sur la liaison série par le terminal. En outre, les commandes standard pour une carte à microprocesseur, telles que par exemple les commandes standard du protocole ISO 7816, peuvent être mises en #uvre, le programme principal reconnaissant de plus deux commandes supplémentaires, l'une pour le téléchargement d'une appliquette, et l'autre pour la sélection d'une appliquette préalablement chargée sur la carte à microprocesseur.
Conformément à l'objet de la présente invention, la structure du programme principal est réalisée de manière à comporter au moins un module de programme de gestion et de vérification d'un fragment de programme téléchargé suivant le protocole de gestion d'un fragment de programme téléchargé précédemment décrit dans la description en liaison avec la figure 2.
En outre, le module de programme comporte également un module de sous-programme de vérification d'un fragment de programme tétléchargé suivant le procédé de vérification tel que décrit précédemment dans la description en liaison avec les figures 3a à 3j.
Dans ce but, la structure des mémoires, en particulier de la mémoire permanente non inscriptible, mémoire ROM, est modifiée de manière à comporter notamment, outre le programme principal, un module 17 de gestion de protocole et de vérification, ainsi que mentionné précédemment. Enfin, en ce qui concerne la mémoire non volatile réinscriptible de type EEPROM, celleci comporte avantageusement un répertoire d'appliquettes, noté 18, permettant la mise en #uvre du protocole de gestion et du processus de vérification objets de la présente invention.
En référence à la même figure 6, on indique que le système de développement de l'appliquette conforme à l'objet de la présente invention, permettant en fait la transformation d'un code objet classique ainsi que mentionné précédemment dans la description et satisfaisant aux critères C1+C2+C'3+C'4 dans le cadre de l'environnement Java en un code objet normalisé pour le même fragment de programme comprend, associé à un compilateur classique Java 21, un module de transformation de code, noté 22, lequel procède à la transformation de code en code normalisé selon le premier et le deuxième mode de réalisation précédemment décrits dans la description en liaison avec les figures 4a, 4b et 5a, 5b.
On comprend en effet que, d'une part, la normalisation du code objet d'origine en un code objet normalisé à
instruction de branchement à pile vide et en un code normalisé faisant appel à des registres typés, d'autre part, ainsi que mentionné précédemment dans la description, permet de satisfaire aux critères de vérification C3 et C4 imposés par le procédé de vérification objet de la présente invention.
Le module de transformation de code 22 est suivi d'un convertisseur JavaCard 23, lequel permet d'assurer la transmission par un réseau distant ou local vers le terminal et, par l'intermédiaire de la liaison série, vers la carte à microprocesseur 10. Ainsi, le système de développement de l'appliquette 20 représenté en figure 6 permet de transformer les fichiers de classe compilés produits par le compilateur Java 21 à partir des codes source Java de l'appliquette en des fichiers de classe équivalents mais qui respectent les contraintes supplémentaires C3, C4 imposées par le protocole de gestion et le module de vérification 17 embarqués sur la carte à microprocesseur 10. Ces fichiers de classe transformés sont convertis en une appliquette téléchargeable sur la carte par le convertisseur JavaCard standard 23.
Différents éléments particulièrement remarquables de l'ensemble des éléments du protocole, des procédés et des systèmes objets de la présente invention, seront maintenant donnés à titre indicatif.
Vis-à-vis des processus de vérification de l'art antérieur tels que mentionnés dans l'introduction à la description, le procédé de vérification objet de la présente invention apparaît remarquable en ce qu'il concentre l'effort de vérification sur les propriétés de
typage des opérandes qui sont essentielles à la sécurité de l'exécution de chaque appliquette, c'est-à-dire du respect des contraintes de type associées à chaque instruction et absence de débordement de pile. D'autres vérifications n'apparaissent pas essentielles en termes de sécurité, en particulier la vérification que le code initialise correctement chaque registre avant de le lire pour la première fois. Le procédé de vérification objet de la présente invention opère au contraire par initialisation à zéro de tous les registres à partir de la machine virtuelle lors de l'initialisation de la méthode afin de garantir que la lecture d'un registre non initialise ne peut compromettre la sécurité de la carte.
On notera que les parties externes E de l'actionneur seront avantageusement réalisées de manière à limiter les courants induits.
Bien entendu, l'invention n'est pas limitée au mode de réalisation décrit et illustré qui n'a été donné qu'à titre d'exemple.
PROCEDE ET INSTALLATION DE TRAITEMENT D'UN SUBSTRAT TEL QU'UN CIRCUIT INTEGRE PAR UN FAISCEAU FOCALISE DE PARTICULES ELECTRIQUEMENT NEUTRES L'invention concerne le traitement d'un substrat tel qu'un circuit intégré à l'aide d'un faisceau de particules appliqué sur au moins une portion de surface du substrat.
Dans tout le texte, le terme "traitement" englobe en particulier les micro-usinages (gravures de matériau électrique, semi-conducteur ou conducteur, dépôts de matériau conducteur, à l'aide d'un faisceau focalisé en présence de gaz appropriés) notamment pour corriger les défauts des circuits intégrés après leur fabrication ; les tests de qualité (détection et/ou localisation des défauts) ; l'analyse physico-chimique et l'imagerie en général, notamment par détection des particules secondaires. De plus, le terme "particule" englobe les particules élémentaires, les ions, les atomes, et les molécules.