INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Un autre but de l'invention est de proposer un système logiciel permette en outre de s'affranchir des inconvénients évoqués ci-dessus propos de l'ensemble des systèmes existants.
Et autre but encore de l'invention est de fournir une solution logicielle adaptée aux contraintes inhérentes à la conception des systèmes embarqués.
Le temps de chargement et déchargement est insignifiant par rapport aux autres traitements. # Optimisation des ressources par le gestionnaire de dépendances Le gestionnaire de dépendances gère un compteur d'utilisation pour chaque composant. Ce compteur compte le nombre importeurs du composant, c'est-à-dire de composants qui importent fonctionnalité du composant auquel le compteur est associé. Un composant est déchargé dès que compteur d'utilisation a décru jusqu'à 0.
Lorsqu'un composant n'est plus utilisé, le gestionnaire dépendances libère automatiquement les ressources utilisées pour composant.
# Précisions sur les fonctionnalités réalisées par un élément matériel a dit que la partie implémentation d'un composant pouvait correspondre à un code (qui comprend un ou plusieurs programmes afin remplir la fonctionnalité du composant), mais également à implémentation matérielle par des éléments de hardware comprenant des circuits électroniques.
Ainsi, une fonctionnalité peut être réalisée par un composant C1 qui l'implémente en utilisant un circuit électronique (circuit de décompression vidéo exemple). Mais cette fonctionnalité peut également être réalisee par composant C1 qui l'implémente totalement par logiciel. Si pour application, le circuit électronique est bien présent et fonctionne correctement, le système utilisera le composant C1. Si par contre, le circuit électronique n'est pas présent ou s'il ne fonctionne pas correctement, le système utilisera le composant C1', de façon transparente pour les autres composants. Dans tous les cas, la fonctionnalité est réalisée.
De même, si une fonctionnalité est aujourd'hui réalisée par du code logiciel, elle pourra être réalisée plus tard par un composant qui l'implémente en utilisant un circuit électronique, de façon totalement transparente pour les autres composants, schéma de la figure 9 illustre le remplacement d'un composant C1 par autre composant, C'1, qui exporte la même fonctionnalité.
C1 étant en cours d'exécution comme indiqué en 900, un composant C2 qui possède un canal de communication avec C1 et lui est ainsi relié dans le graphe des liens demande en 901 au GD le remplacement de C1 par C'1. GD demande alors à C1 de sauvegarder son état courant (etape 902), ce que C1 réalise en 903. GD charge et initialise ensuite C'1 (904 et 905).
Si le chargement ou l'initialisation de C'1 ne se sont pas correctement effectués (étape 906), le GD retourne une erreur au demandeur C2.
Si le chargement et l'initialisation de C'1 se sont correctement déroulés, GD transmet en 908 l'état courant de C1 à C'1, afin que se mette dans le même état.
A fins, C'1 interprète l'état courant transmis (909) et l'accepte ou le rejette (910).
S'il le rejette, le GD décharge C'1 (911) et le déinitialise (912). GD retourne ensuite un message d'erreur au demandeur C2 (913 et 914).
Si maintenant C'1 accepte l'état courant de C1, le GD met à jour son graphe (916) en y remplaçant C1 par C'1. II reconstruit ensuite les canaux de communication pour C'1 (917) ; ces canaux sont ceux qui étaient utilisés pour C1. Ensuite le GD déinitialise et décharge C1 (918 et 919).
Le remplacement s'étant effectué correctement, GD en informe C2 (920, 921) ; celui-ci peut continuer son traitement.
On a décrit ci-dessus le principe du système selon l'invention, sa mise en application (entre autres en référence à la figure 6).
Précisons qu'il est également possible de paramétrer l'interface du composant C1 pour que, lorsque le GD recherche un composant qui exporte une fonctionnalité importée par C1, il poursuive sa recherche dans l'ensemble des composants chargés dans le système et transmette à C1 une vue de chacun des composants du graphe des liens qui exporte cette fonctionnalité, dans une étape équivalente à l'étape 627 de la figure 6.
En fonction des critères de choix paramétrés, C1 pourra alors choisir le composant qui lui convient parmi ceux identifiés par le GD.
Précisons également que le système selon l'invention nécessite dans sa version actuelle quatre composants au minimum pour fonctionner, comme représenté sur la figure 10a (sur laquelle les flèches indiquent les fonctionnalités transmises entre composants - ce type de figure est ainsi une représentation du graphe des liens).
amphiphile, et au moins une substance capable de moduler la réponse immunologique audit antigène.
La substance capable de moduler la réponse immunologique à l'antigène présent dans la composition de l'invention est de préférence un adjuvant. Parmi ceux-ci, l'invention envisage des produits bactériens (endotoxines, composants de la paroi), des cytokines, des oligonucléotides (CpG). On peut citer plus particulièrement parmi celles-ci : - des enterotoxines bactériennes, comme CT, CTB, LT, - des dérivés liposaccharidiques, comme MPL et dérivés de lipide A, - des dérivés de la saponine type QS21, - des sels d'ammonium et leurs dérivés, comme l'alum, - des protéines type DT, TT, ou un mélange de ceux-ci.
Comme indiqué précédemment, le rapport pondéral substance/particules est compris entre environ 1% et 20%, de préférence entre environ 5% et 10%.
L'invention est tout particulièrement adaptée à la préparation de composition, plus particulièrement, pour l'administration mucosale, notamment nasale, mais tout autre mode d'administration, par exemple parentérale, peut être envisagée.
D'autres caractéristiques et avantages de l'invention apparaîtront des exemples qui suivent
concernant (i) l'effet chez la souris du BVSM sur l'immunogénicité d'un split Influenza trivalent à celui de différents adjuvants, et (ii) l'effet chez la souris de la co-administration de la formulation et de différents adjuvants sur l'immunogénicité d'un split Influenza trivalent.
Les différentes formules (adjuvant BVSM Ag) sont administrées à jO et 21 selon le schéma suivant : Contrôle PBS i. n.
C : Contrôle naïf i. n.
AS : Ag s. c.
AN : Ag i. n.
FA : Ag + BVSM i. n.
Ax : Ag + Adj X i. n.
FX : Ag + BVSM + Adj X i. n.
L'immunogénicité est évaluée après le rappel, à j35 : - au niveau sérique, détection par ELISA des IgG spécifiques de chaque split monovalent - au niveau muqueux, détection par ELISA dans les sécrétions nasales et/ou vaginales des IgA spécifiques de chaque split monovalent.
Il sera fait référence dans ce qui suit aux dessins en annexe dans lesquels : La figure 1 représente l'analyse au Biacore (résonance plasmonique de surface) de l'association de la CTB avec les BVSM en fonction de la concentration en CTB.
La figure 2 représente l'analyse au Biacore de l'association du MPL avec les BVSMTM en fonction de la concentration en MPL.
Le matériau composite selon l'invention peut être préparé par le procédé qui consiste à : - enduire le vernis photopolymérisable sur au moins l'une des surfaces du support ;
- photoréticuler le vernis sur ledit support à l'aide d'un rayonnement U.V. ayant une longueur d'onde comprise entre 280 et 500 nm.
Ce procédé, qui est avantageusement un procédé continu (en ligne), peut être mis en #uvre selon les modes opératoires représentés sur les Fig.let 2 sur lesquelles : . FIG. 1 est un schéma classique de revêtement d'un support à l'aide d'un vernis et polymérisation U.V.
. FIG. 2 est un schéma classique de fabrication d'un stratifié constitué de deux supports séparés par une couche de vernis et polymérisation U.V.
Selon l'un ou l'autre de ces schémas, le support (1) est imprégné d'une couche de vernis (2) en faisant passer ledit support entre deux tambours (A) et (B), le tambour (A) étant en contact permanent avec le vernis photoréticulable, le tambour (B) tournant dans le sens inverse du tambour (A) permettant d'obtenir un revêtement uniforme du vernis sur ledit support.
Le support ainsi revêtu du vernis est ensuite dirigé vers le rayonnement ultraviolet (3), après avoir éventuellement été revêtu d'un second support (1') selon le mode opératoire représenté sur la Figure 2.
Le matériau composite obtenu après la polymérisation est ensuite stocké sur un cylindre de stockage (non représenté) ou directement découpé en feuilles et emballé selon des procédures classiques.
L'imprégnation du support par le vernis polymérisable est avantageusement réalisée à la température ambiante.
La photopolymérisation U. V. est réalisée à l'aide d'un rayonnement U.V. obtenu avec des lampes ayant une puissance de 100 à 250 W/cm par exemple à l'aide de lampes au mercure de 127 W/cm ou 220 W/cm , de lampes au mercure dopées au fer de 160 W/cm ou de lampes au mercure dopées au gallium de 160 W/cm.
La vitesse de défilement du support/vernis sous le rayonnement U.V. n'est pas critique ; elle varie en fonction des lampes utilisées et de la nature du support. On indiquera toutefois que les vitesses allant de 5 m/min à 20 m/min sont tout à fait appropriées.
Le matériau composite selon l'invention est doué d'excellentes propriétés de stabilité à la chaleur et de souplesse.
Ce matériau convient particulièrement bien comme support de circuits imprimés.
La présente invention va maintenant être décrite plus en détail par les exemples illustratifs ci-après : Exemple 1 : matériaucomposite A On a utilisé comme support un tissu de verre de 70 à 95 g/m2 .
On a revêtu ledit support selon le schéma opératoire représenté sur la Figure 1 à l'aide du vernis A dont la composition est la suivante : 50 parties pondérales (pp) d'époxyde novolaque modifié acrylate, dilué dans 30% d'hexanediol diacrylate 50 pp d'acrylate aliphatique 10 pp d'acrylate d'éthyle hexyle 1 pp d'agent débullant 2 pp de photoinitiateur n l : "Irgacure 907" 0,2 de photoinitiateur n 2 : isopropylthioxanthone La viscosité Brookfield dudit vernis à 20 C était de 550 mPa.s.
Ce matériau composite présentait une souplesse de 172 N/m et une température de transition vitreuse de 160 C.
Exemple 2 : matériau composite B On a répété le mode opératoire de l'exemple 1 en utilisant le vernis B ayant la composition ci-après : 68 pp d'époxyde bis-phénol A modifié acrylate 32 pp de diacrylate hexanediol 1 pp d'agent débullant 2 pp de photoinitiateur constitué d'un mélange de benzophénone et d'une propanone (produit connu sous la dénomination commerciale "Esacure KT55".
# Déclaration du composant Une fois qu'un module exécutable a ainsi été créé pour chaque composant du projet, le programmeur doit déclarer l'existence de ces composants pour que ceux-ci soient pris en compte par le système. Cette déclaration est effectuée en 611, étape lors de laquelle le programmeur déclare chaque composant à un "loader", les loaders étant eux-mêmes des composants spécifiques du système selon l'invention. Lors de cette étape 611, le loader auprès duquel on déclare un composant mémorise le composant dans une liste individuelle du loader qui rassemble l'ensemble des composants qui ont été déclarés auprès de lui.
Cette étape 611 est également une étape qui concerne globalement le projet en cours de développement, l'ensemble des composants développés pour un projet étant déclaré auprès d'au moins un loader chaque loader correspondant à un media du système informatique (disque, réseau, etc..) sur lequel sont stockés les composants associés à loader. # Chargement du composant dans le système On a décrit ci-dessus les étapes de création et de déclaration d'un "projet" qui peut comprendre plusieurs composants. On va décrire ci- dessous mise en oeuvre de ces composants, qui est illustrée dans la partie inférieure de la figure 6.
En 620, un composant C1 appelle une fonctionnalité F1 lui est nécessaire Deux possibilités se présentent pour cet appel # soit la fonctionnalité F1 est définie avec la propriété loadtime dans l'interface du composant C1 (la propriété loadtime est décrite plus haut). Dans ce cas, le GD va chercher et charger dans le système le composant qui remplit cette fonctionnalité F1, préalablement au chargement du composant C1.
#' Si composant nécessite lui-même une fonctionnalité loadtime , GD chargera alors également le composant nécessaire pour remplir cette fonctionnalité, toujours préalablement au chargement du composant C1. GD chargera ainsi récursivement tous les composants nécessaires pour remplir les différentes fonctionnalités loadtime qu'il va rencontrer (on va expliquer plus bas comment charger un composant dans le système), # soit la fonctionnalité F1 est définie avec la propriété runtime (la propriété runtime est décrite plus haut). Le composant C1 doit alors faire un appel explicite ' une autre fonctionnalité, depmgr , fournie par le GD, pour appeler la fonctionnalité runtime F1. Pour ce faire, la fonctionnalité depmgr doit impérativement être déclarée avec la propriété loadtime dans l'interface de C1 afin de pouvoir utiliser cette interface dès le chargement et l'initialisation de C1 (voir plus haut le traitement des fonctionnalité loadtime ).
C1 pourra alors importer la fonctionnalité runtime F1 appelée en 620 au moment précis ou il doit l'utiliser. Le composant qui remplit cette fonctionnalité F1 sera alors chargé par GD.
Si ce composant nécessite une fonctionnalité au moment de son chargement (fonctionnalité déclarée loadtime dans son interface), le composant remplissant cette fonctionnalité loadtime sera également chargé.
chargera ainsi récursivement tous les composants nécessaires pour remplir les différentes fonctionnalités loadtime qu'il va rencontrer (on expliquer plus bas comment charger un composant dans système).
La fonctionnalité F1 demandée initialement en 620 ne sera donc disponible pour C1 que si toutes les fonctionnalités loadtime rencontrées lors de sa résolution sont également résolues. une seule fonctionnalité demandée au chargement par C1 (fonctionnalité déclarée loadtime ) n'est pas résolue, C1 ne sera pas chargé. C1 pourra en effet pas remplir sa mission fonctionnelle car il ne pourra pas utiliser une autre fonctionnalité qui lui est nécessaire.
Si la fonctionnalité que C1 doit importer n'est pas remplie un des composants du projet auquel appartient C1 et avec lequel il déclaré auprès d'un des loaders du système, le système, comme on va le montrer, identifie dans un autre projet un composant permettant de fournir cette fonctionnalité à C1.
A ces fins GD, qui est chargé en permanence dans la mémoire vive du système, recherche dans son "graphe des liens" si le fichier objet d'interface d'un des composants du graphe des liens indique que ce composant fournit la fonctionnalité demandée par C1.
Pour ce faire, le GD interprète la version binaire du fichier d'interface qui est stockée dans le composant exécutable, et chargée/transmise par les composants loaders au GD à l'exécution.
Le cherche d'abord les interfaces possédant même nom que celle demandée (importée). Lorsqu'il en trouve, il vérifie ensuite à l'intérieur de celles-ci que toutes les propriétés de la fonctionnalité demandée soient présentes et les contraintes et conditions éventuelles (version supérieure à 0.6.2, etc.) satisfaites.
Le graphe des liens du GD est une liste des composants qui sont chargés dans le système, c'est-à-dire qui sont non seulement déclarés comme on l'a décrit ci-dessus à propos de l'étape 611, mais dont le fichier d'interface objet a été importé dans une zone de mémoire vive de la cible, et qui est en relation avec d'autres composants du graphe des liens pour échanger des fonctionnalités fournies et/ou demandées.
Le graphe des liens, qui est mémorisé dans une zone de mémoire vive de la cible, est ainsi une image instantanée des composants chargés, ce graphe des liens pouvant évoluer de manière dynamique. Le graphe des liens est unique et associé au GD.
Si GD détermine lors de l'étape 621 que la fonctionnalité appelée par C1 fournie par un des composants du graphe liens (que l'on nommera C2 composant appelé , alors que C1 composant appelant il établit un canal de communication entre composant C2 et le composant C1 en important en 627 des caractéristiques du composant C2 dans composant C1.
Plus précisément, le GD construit pour C1 une structure de données appelée view (vue) qui offre, une vue sur les imports devant être réalisés. Cette view contient la valeur des propriétés ainsi que les pointeurs sur les fonctions importées (ou sur du code qui permet indirectement de les atteindre, comme par exemple un appel système, une migration de threads, etc). Cette vue est directement issue des éléments générés par le compilateur de dépendances dans les fichiers include .
maintenant le GD détermine en 621 que la fonctionnalité appelée par C1 'est fournie par aucun des composants du graphe des liens, il va interroger les listes des loaders du système les unes après autres, afin de déterminer si un des composants déclarés auprès de loaders offre la fonctionnalité demandée par C1. Cette interrogation des loaders est représentée par l'étape 622.
Lors de cette interrogation, le GD utilise une fonctionnalité loader qui possède les fonctions nécessaires pour lister les composants que chaque loader voit. La fonctionnalité loader permet au GD de comparer une fonctionnalité exportée par un composant du loader, à la fonctionnalité devant être importée. Elle permet également au GD de charger et décharger un composant individuel, du média auquel est associé le loader vers la mémoire vive de la cible.
précise que chacun des loaders du système selon l'invention est associé @ un média particulier permettant de stocker des composants ; chaque loader pourra ainsi être associé à un disque de mémoire, ou à tout autre support d'enregistrement, de type CD ROM par exemple. La pluralité des loaders sera illustrée en particulier en référence à la figure 7.
Si un tel composant est localisé dans la liste d'un des loaders du système (étape 623), le premier loader dont la liste comprend un tel composant transmet en 625 au gestionnaire de dépendance l'interface objet du composant C2 identifié, et le GD transmet lui-même en 626 au composant C1 la vue de ce composant C2. (étape 627).
La vue de C2 a été mémorisée par le GD dans une zone mémoire du système qui est créée dynamiquement par le GD, au chargement du composant C2, et qui sera détruite en même temps que ce composant sera déchargé. Cette zone se trouve dans le même espace d'adresses que le composant qui peut y accéder. Si maintenant la recherche du GD pour identifier dans la liste d'un des loaders un composant fournissant la fonctionnalité demandée avère infructueuse lors de l'étape 623, le système s'arrête en 624.
Dans cas où un composant C2 offrant la fonctionnalité demandée par C1 a identifié et les caractéristiques de C2 ont été importées dans C1 en 627, le gestionnaire de dépendance va opérer différemment selon que le composant C2 fait déjà partie du graphe des liens ou non (étape 628). Si C2 appartient déjà au graphe des liens, le GD passe directement à l'étape 633 de création d'un canal de communication entre C1 C2. Pour ce faire, le système utilisera soit un des quatre modes de communication décrits ci-dessous, soit un mode spécifique créé spécialement, en fonction des caractéristiques spécifiées dans l'interface de C1 et/ou C2 Les appels directs C'est la méthode la plus rapide. La fonctionnalité ou méthode demandée est directement appelée, et son résultat directement retourné. II n'y a aucun code intermédiaire. Le gestionnaire de dépendances choisit ce moyen lorsque les deux composants sont sur la même machine, dans le même espace d'adresses, et au même niveau de privilèges.
On définit un espace d'adresses comme une zone de mémoire logique dans laquelle des adresses de code ou de données ont une signification pour tous les composants accédant à cette zone. Un pointeur sur du code ou des données peut être transmis tel quel d'un composant à un autre et, sans que sa valeur ne soit modifiée, permettra d'accéder aux mêmes données.
Dans l'invention, le terme espace d'adresses implique également des privilèges communs, un espace d'adresse définissant un espace ou une classe d'objets ayant le même niveau de privilèges : les objets pointés d'un même espace d'adresse peuvent ainsi être accédés de la même manière par les différents composants. Et on peut ainsi par exemple définir un espace utilisateur de niveau de privilèges inférieur, et un espace superviseur de niveau supérieur.
La cohérence des pointeurs entre l'espace utilisateur de chaque processus, et l'espace superviseur (système) est respectée (le processeur du système informatique ayant accès aux deux espaces en même temps), mais le code utilisateur ne peut pas référencer des données situées en espace superviseur .
Les privilèges sont des possibilités d'accès entre composants ; il est possible d'utiliser dans l'interface source les niveaux de privilèges suivants
Niveau ` Description Inprocess Le module est exécuté dans le même espace d'adresses que son appel nt spawn Le composant est exécuté dans son propre processus, créé lors de son chargement On précise que lorsqu'un composant marqué spawn est chargé, le GD demande automatiquement à un composant scheduler dédié à l'ordonnancement de créer un processus qui sera lancé par C1 t et un espace d'adresses correspondant . Le composant est alors contenu dans l'espace d'adresses de ce processus, et fonctionne en tant qu'entité active (il est possible d'effectuer des traitements sans autre action que le lancement du composant), et non passive comme dans le cas d'un composant non marqué spawn (qui lui attend simplement d'être appelé pour effectuer un traitement). Le GD différencie ce niveau de privilèges du composant avnt l'étape 621. I i 1o Le module effectue des opérations d'entrées/sorties (driver) Supervisor Le composant doit être exécuté en mode superviseur (niveau j 1 de privilèges le plus élevé). j Pour affecter un de niveaux de privilèges à un composant, le programmeur fixe le paramètre correspondant dans la définition du module du composant, qui est contenue à l'intérieur d'un texte du type inprocess supervisor module f /* Définition module */ Des exemples de tels appels sont les suivants # composant superviseur vers composant superviseur, # composant utilisateur (c'est-à-dire du niveau de privilèges inférieur) vers composant utilisateur dans le même espace d'adresses (telle une application utilisant un composant gérant une bibliothèque de fonctions partagées et passives).
Cette méthode est la seule employée si le composant mémoire ne fournit pas de protection, ce qui peut être le choix de l'ingénieur qui construit le système pour son produit, ce qui fournit un système extrêmement rapide en l'absence de protection.
Le composant mémoire ne fournit pas de protection lorsque ce composant n'offre qu'un seul espace d'adresses, de système . Ce type de gestion de mémoire n'offre aucune protection (tout fonctionnant dans même espace et pouvant potentiellement detruire ou modifier le code les données appartenant à d'autres composants), mais est le seul possible sur certaines cibles ne possédant pas de (memory management unit ). Les appels système L'invocation est déroutée vers un appel système, Celui ci transfère les paramètres de la pile utilisateur vers la pile superviseur, change de niveau privilèges, effectue l'appel, retourne au niveau de privilèges inférieur, retourne le résultat de manière directe.
Cette méthode est sélectionnée lorsqu'un composant utilisateur (non privilégié) fait appel à une fonctionnalité d'un composant superviseur, à condition que cette dernière autorise les composants non privilégiés à l'utiliser.
Cette autorisation se fait au niveau du langage de description des dépendances, par le mot clé "promote". Et de manière plus générale, les mots-clé suivants peuvent être associés à un composant (dans la syntaxe du langage développé par la Demanderesse, les mots clés sont simplement préfixés à la propriété ou méthode dont ils doivent altérer le fonctionnement