INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
En bref, les instructions nécessaires à la description du système comprennent les instructions de déclaration des modules M1 à M11 (on parle en général d'instructions d'instanciation des modules dans le jargon de l'homme du métier, pour désigner ces instructions), les instructions de connexion des ports d'entrée et des ports de sortie des modules, et les instructions d'initialisation des modules par appel de la fonction"dojnit"de chacun des modules.
Ainsi qu'il apparaît en comparant les Annexes 4 et 5, seules les instructions de connexion diffèrent entre le cas selon l'art antérieur et le cas selon l'invention. En effet les instructions de connexion des ports d'entrée et des ports de sortie des modules se font, selon l'invention, par appel de la fonction"In~i" ou"OutJ"correspondante.
L'organigramme de la figure 3 illustre de façon schématique les étapes d'un procédé d'exécution de la netlist de l'Annexe 5, qui consiste à exécuter séquentiellement les instructions qu'elle contient. Ces opérations sont exécutées par le noyau de simulation (processeur piloté par un programme adhoc) de SystemC.
Dans une étape 31, on se demande si la netlist contient encore une instruction à exécuter. Si la réponse est non, alors, dans une étape 32, on lance la simulation du système et/ou le traitement de la topologie. Cette étape 32 correspond à l'essence même des applications pour la conception et la
Par exemple, au début de l'utilisation de l'algorithme de Diffie-Hellman, le dispositif 100 ayant une adresse A génère une clé privée désignée "a". Une clé publique correspondante se présentera sous la forme Ta=ga, dans laquelle le paramètre "g" est un paramètre connu selon l'algorithme de Diffie-Hellman, c'est-à-dire, la clé DH. De manière analogue, le pare-feu 110 aura la clé privée "f" et la clé publique Tf=gf, tandis que le dispositif 140 aura la clé privée "b" et la clé publique Tb = gb.
Par la suite, le dispositif 100 peut transmettre la clé publique Ta au pare-feu 110, qui peut ensuite calculer une clé secrète Saf - (Ta)f = gaf. Le pare-feu transmet, de manière analogue, Tf au dispositif 100, qui peut alors
calculer la clé secrète Sfa = (Tf)a = gaf = Saf. Les dispositifs 100 et 110 partagent ainsi une clé sécrète commune, désignée ci-après "C".
Une fois que les dispositifs 100 et 110 partagent la même clé C, ils peuvent calculer chacun la même clé publique TC = gC. Le dispositif 140 possédant la clé privée "b", calcule en attendant la clé publique Tb = gb, comme cela a déjà été indiqué.
Par la suite, le dispositif 140 transmet Tb au parefeu 110, qui peut calculer la clé secrète SbC = (Tb)C = gbC. Le pare-feu transmet de manière analogue TC au dispositif 140, qui peut alors calculer la clé secrète SCb = (TC)b = gCb = SbC.
Pour terminer, afin de mettre à jour la clé secrète partagée C avec le dispositif 100, le pare-feu 110 envoie Tb au dispositif 100, et le dispositif 100 peut alors calculer la nouvelle clé secrète de la même manière que cela vient juste d'être réalisé par le pare-feu 110, en employant la clé secrète C qu'il possède déjà depuis une étape antérieure, c'est-à-dire: SbC = (Tb)C = gBC.
En résumé, les dispositifs 100 et 110 calculent une clé secrète partagée entre eux. Par la suite, les dispositifs 110 et 140 calculent une seconde clé secrète partagée entre eux, en employant la première clé secrète.
Pour terminer, le dispositif 100 est capable de calculer la seconde clé secrète en utilisant la première clé secrète et la clé publique du dispositif 140. Ainsi, les trois dispositifs partagent la (seconde) clé secrète, qui
peut être utilisée pour crypter/décrypter les paquets IPsec.
Une autre manière de décrire le même procédé est de dire que le dispositif 100 calcule la clé secrète en employant sa clé sécrète commune (C) établie avec le dispositif 110, la clé DH et les clés publiques du dispositif 140, tandis que le dispositif 140 calcule la même clé secrète en utilisant sa propre clé privée locale, la clé DH et la clé publique commune (TC) des dispositifs 100 et 110. La clé sécrète commune (SbC), une fois calculée par le pare-feu 110, devra seulement être mémorisée dans celui-ci, par exemple, dans un ensemble matériel de circuits intégrés qui n'est pas accessible par un administrateur du pare-feu.
On notera que dans cette description la clé secrète est calculée deux fois entre les dispositifs 100 et 110.
Cependant, le dispositif 140 peut également initier le ou les échanges. Dans les deux cas, seulement l'un des deux dispositifs terminaux devra réaliser le calcul de la clé secrète en deux étapes.
Tant que les associations SA entre le dispositif 100 et le pare-feu 110, et entre le pare-feu 110 et le dispositif 140, sont valides, la même clé secrète est valide. Les mêmes paramètres de durée de vie de clé devront habituellement être négociés des deux manières.
L'un ou l'autre des dispositifs 100 ou 140 pourra initier l'échange en mode rapide associé aux négociations SA de phase 2. A la Fig. 2, le dispositif 140 est
l'initiateur de la seconde phase démarrant avec le message PH2BI 250. Le pare-feu 110 reconstruit un message PH2FI 260 analogue, dans lequel la clé (publique) d'authentification du dispositif 140 est remplacée par un calcul des clés publiques des dispositifs 110 et 140 conjointement (compte-tenu que le dispositif 100 aura besoin du paramètre du dispositif 140 pour le calcul de clé secrète, comme cela vient d'être décrit).
Le dispositif 100 répond au pare-feu 110 avec ses propres paramètres dans le message PH2AA 270, et le parefeu 110 envoie le message incluant les mêmes valeurs de paramètre, à l'exception de la clé d'authentification du dispositif 100, qui est échangé pour une combinaison de lui-même et de la clé du pare-feu 110, avec le dispositif 140, dans le message PH2FA 280.
Ainsi, dans le but de quantifier la forme active des analogues nucléosidiques, il est essentiel d'utiliser des méthodes de dosage sensibles et spécifiques desdits nucléosides triphosphorylés, ci-après désignés ddNTPs.
Un des facteurs déterminants de l'échec thérapeutique des traitements anti-VIH s'expliquerait par une altération du métabolisme cellulaire pour les nucléosides (ddNs), ce qui entraînerait une concentration insuffisante de la molécule active dans le milieu intracellulaire, cause majeure des échappements thérapeutiques. Par conséquent, un des moyens d'appréhender l'échappement thérapeutique serait la détermination de la
concentration intracellulaire de ces molécules (nucléosides triphosphorylés et antiprotéases) par dosages immunologiques. Le suivi thérapeutique des patients ou TDM (Therapeutic Drug Monitoring) peut être alors envisagé pour optimiser l'administration de ces molécules en proposant des traitements personnalisés mais aussi permettre d'évaluer les associations.
Le catabolisme très important des antiprotéases par les enzymes hépatiques et intestinales ainsi que les mécanismes d'efflux conduisent à administrer des doses d'antiviraux très importantes aux malades pouvant générer des effets secondaires redoutables.
En ce qui concerne les analogues nucléosidiques, le problème est différent. Les doses administrées sont là aussi importantes car imposées par la pénétration limitée du nucléoside précurseur dans les cellules. Les différents métabolites phosphorylés du médicament affecteront tout aussi bien les polymérases virales que cellulaires. La toxicité des catabolites du médicament viendra se surajouter à la nonspécificité des analogues nucléosidiques. Dans ce contexte, le traitement anti-VIH, à cause des quantités élevées d'antiviraux administrées aux malades, affectera un grand nombre de compartiments cellulaires y compris ceux qui sont réservés à la différentiation des cellules souches induisant ainsi les effets secondaires qui rendent les traitements anti-VIH si contraignants et inconfortables.
Ainsi les taux plasmatiques et intracellulaires des molécules anti-VIH, utilisées le plus souvent en association, sont le reflet direct du métabolisme de l'organisme entier. La bonne connaissance des taux plasmatiques et intracellulaires des molécules anti-VIH est essentielle et diffère d'un individu à l'autre et d'un moment à l'autre de la maladie.
La mesure de ces paramètres permettrait aux cliniciens de déterminer les conséquences des associations, d'en optimiser leur utilisation et d'en adapter la posologie en fonction du malade et de l'évolution de sa maladie. Il est essentiel pour le clinicien d'avoir accès à la mesure du contenu intracellulaire qui est en étroite relation avec la concentration plasmatique et la charge virale. Cette dernière a un impact direct sur l'échappement thérapeutique.
Des méthodes de dosages intracellulaires des dérivés nucléosidiques ont été développées, Robbins, BL, et al. (1996) "Quantification of intracellular zidovudine phosphates by use of combined cartridge-radioimmunoassay methodology". Antimicrob. Agents Chemother. 40,2651-2654. ; Goujon, L. et al. (1998)"Monitoring of intracellular levels of 5'-monophosphate-AZT using an enzyme immunoassay". J.
Immunol. Methods, 218, 19-30. ; Robbins, BL. et al. (1998) A.
"Development of a new cartridge radioimmunoassay for determination of intracellular levels of lamivudine triphosphate in the peripheral blood mononuclear cells of human immunodeficiency virus) infected patients". Antimicrob.
Agents Chemother. 42,2656-2660.).
Mais ces méthodes n'offrent pas des performances suffisantes du point de vue de la sensibilité du test, nécessaires notamment pour détecter les faibles concentrations des analogues nucléosidiques présents dans les compartiments cellulaires et disponibles dans des échantillons de faible taille.
La présente invention a pour objet des méthodes de quantification des analogues nucléosidiques, permettant de pallier les inconvénients des dosages existants desdits
composés, qui sont utilisés par exemple, en tant que composés antiviraux Les méthodes de quantification des nucléosides au moyen de dosages immunologiques mis en oeuvre dans la présente invention présentent de nombreux avantages en termes de sensibilité et de rapidité car tant le temps de préparation des échantillons comme celui du dosage lui-même sont considérablement réduits.
Ils sont de plus, applicables à un grand nombre d'échantillons de taille réduite, tant en volume qu'en nombre de cellules. Ils constituent une méthode de quantification réalisable en mélange complexe, sensible, adaptée aux concentrations intracellulaires faibles, rapide et adaptée au suivi de patients en milieu hospitalier.
Il existe peu de travaux prenant en compte le métabolisme intracellulaire des nucléosides en raison de l'instabilité des dérivés triphosphorylés du fait que les liaisons pyrophosphates sont sensibles à l'hydrolyse et rapidement dégradées.
On a ajouté dans la cuve réactionnelle le substrat de luminescence Lumiphos 530 (Lumigen) et on a laissé incubé 15 min à 37 C.
On a lu la luminescence en unité RLU (Relative Luminescence Unit) à l'aide du photomultiplicateur H7155 (HAMAMATSU) et on a calculé le rapport de luminescence entre les échantillons contenant le virus et ceux sans le virus.
Tableau 1 : test de sensibilité
Luminescence RLU Conjugué VIH-1-VIH-1 + VIH-1 + Rapport Rapport (1/2000) (1/300) al a2 a3 a2/al a3/al ave exemple 1 1170 58342 3409 49,9 2,9 avec EMCH 8103 134104 10621 16,6 1,3 avec EMCH (dilution d'un 3731 61526 5033 16, 5 1, 35 facteur 2)
Les rapports obtenus avec le conjugué de l'invention et avec un conjugué préparé avec EMCH tels qu'indiqués ci-dessus montrent clairement l'amélioration de la sensibilité de détection lorsqu'on utilise un agent de couplage de l'invention, que la dilution soit importante ou non (2 dernières colonnes du tableau).
Il est à noter que, pour obtenir un niveau de détection contrôle (bruit de fond) comparable à celui obtenu avec le conjugué de l'invention, on a dilué d'un facteur 2 le conjugué préparé à partir de EMCH (dernière ligne). On a ainsi vérifié que, à bruit de fond comparable, le rapport de luminescence reste faible avec le conjugué préparé à partir de l'agent de couplage de l'art antérieur.
Exemple 6 : Comparaison de la stabilité d'un conjugué de l'invention et d'un conjugué obtenu avec l'agent de couplage EMCH Pour étudier la stabilité des conjugués, on a laissé vieillir les conjugués dilués comme indiqué dans l'exemple 5, dans une étuve à 37 C pendant 8, 15 et 30 jours et on a comparé leur comportement vis-à-vis des mêmes préparations, mais conservées à 4 C. Les résultats, en terme de pourcentage, sont indiqués dans le tableau 2 ci-dessous.
\ Tableau 2 : test de stabilité
8 jours à + 37 C 15 joursà + 37 C 30 jours à + 37 C Conjugué de l'invention-8, 7 %-13, 2 %-37, 1 % Conjugué avec EMCH-36, 7%-57, 3%-56, 8%
Les résultats du tableau 2 montrent clairement qu'en condition forcée de vieillissement, le conjugué préparé avec un agent de couplage de l'invention est bien plus stable que le conjugué préparé avec un agent de couplage de l'art antérieur.
La présente invention concerne un dispositif d'accouplement élastique entre le rotor d'une machine électrique tournante réversible et l'arbre primaire de la boîte de vitesses d'un moteur thermique d'un groupe motopropulseur hybride d'un véhicule automobile.
Les machines électriques tournantes des groupes motopropulseurs hybrides sont généralement implantées dans la boîte de vitesses, dans le carter d'embrayage du véhicule ou dans le carter de convertisseur si la boîte de vitesses est automatique. Cette implantation permet une liaison mécanique directe du rotor de la machine électrique avec l'arbre primaire de la boîte de vitesses. Cependant, si cette liaison est rigide, toutes les excitations et déformations de l'arbre primaire perturbent la machine électrique et, de même, les excitations et déformations de la machine électrique perturbent l'arbre primaire.
Le but de la présente invention est de réaliser une liaison entre l'arbre primaire de la boîte de vitesses et le rotor de la machine électrique au moyen d'un dispositif d'accouplement admettant des débattements significatifs pour permettre des déformations de l'arbre primaire indépendamment du rotor de la machine électrique.
A cet effet, l'invention propose un dispositif d'accouplement élastique entre le rotor d'une machine électrique tournante réversible et l'arbre primaire de la boîte de vitesses d'un moteur thermique d'un groupe motopropulseur hybride d'un véhicule automobile, le rotor étant solidaire d'un moyeu monté concentriquement à l'arbre primaire et à rotation relativement à un carter fixe, et qui est caractérisé en ce qu'il comprend un plateau annulaire solidaire en rotation de l'arbre primaire transversalement à ce dernier et un manchon en forme de soufflet interposé, concentriquement à l'arbre primaire, entre le plateau et un flasque du moyeu parallèle au plateau, le manchon en forme de soufflet
présentant une rigidité élevée en torsion et une souplesse radiale de façon à permettre l'accouplement en rotation et des déformations mécaniques relatives éventuelles entre le rotor et l'arbre primaire.
Après l'étape 42 comme après l'étape 43, on effectue alors, dans une étape 44, la connexion proprement dite du signal au port concerné. Ceci est réalisé, selon la manière habituelle en langage SystemC, par l'instruction suivante : ion~1 (p) A la figure 5, on a représenté un organigramme qui donne le détail des étapes mise en oeuvre lors de l'étape 36 (figure 3) à laquelle on appelle la fonction d'initialisation"dojnit"d'un module déterminé. Toujours à titre d'exemple, on considèrera dans ce qui suit le cas de l'appel de la fonction d'initialisation du module M6, par l'instruction suivante : M6. do~init (Circuit) Cette méthode reçoit en argument l'identifiant de l'objet d'extraction de topologie du système, c'est-à-dire la variable "Circuit" du module. La méthode commence par effectuer un test 51 pour savoir si la fonction"dojnit"a déjà été appelée auparavant, ce qui serait une erreur. A cet effet on teste la valeur de la variable interne"Circuit"qui doit avoir la valeur nulle (c'est-à-dire la valeur qui
lui a été attribuée lors de son initialisation par le constructeur du module). Un tel test est réalisé par exemple par l'instruction suivante : if (Circuit ! =0) Si la fonction"do~init"a déjà été appelée, alors, dans une étape 52, on gère l'erreur. Par exemple, on génère une interruption.
Si au contraire la fonction"dojnit"n'a pas été appelée auparavant, c'est-à-dire si c'est le premier appel de cette fonction pour le module concerné, alors, dans une étape 53, on stocke l'adresse de l'objet d'extraction de topologie dans la variable interne"Circuit"du module. Ceci se fait par exemple par une instruction telle que Circuit = & c Ensuite, dans une étape 54, on envoie à l'objet d'extraction de topologie toutes les infirmations sur les connexions déjà réalisées pour ce module, et qui ont été stockées dans les structures de stockage associées à chacun des ports d'entrée et/ou de sortie du module.
A cet effet, on appelle une méthode"do-send~info"permet d'envoyer vers l'objet d'extraction de topologie toutes les informations sur les connexions qui ont pu être réalisées auparavant par des appels antérieurs aux fonctions de connexion Inj et/ou Outj pour ce module.
Le détail de l'exécution de la fonction "do send info" va maintenant être explicité en regard de l'organigramme de la figure 6.
Dans une étape 61, on vérifie que le module appartient bien à un système et que l'on peut donc envoyer des informations vers l'objet d'extraction de topologie associé à ce système. Ceci est réalisé en testant la valeur de la variable "Circuit", par une instruction déjà présentée plus haut, du type if (Circuit ! = 0) .
Si la réponse est non, alors, dans une étape 62, on gère l'erreur par exemple en introduisant une interruption.
Si au contraire la réponse est oui, alors, dans une étape 63, on envoie l'adresse du module (donnée par le vocable this qui est un vocable prédéfini du langage C++) ainsi que son type fonctionnel ("Dec"pour le module M6) à l'objet d'extraction de topologie. Ceci est par exemple réalisé grâce à une méthode"MakeModule", par une instruction du type ci-dessous :
Circuit- > MakeModule (this,"Dec") On verra plus loin comment est gérée la mémoire pour enregistrer la liste des modules qui constituent le système.
Il s'agit ensuite d'enregistrer toutes les connexions qui ont été stockées pour chaque port du module. Pour cela, on parcourt la liste de pointeurs correspondant à la structure de stockage associée à chaque port du module, et on envoie vers l'objet d'extraction de topologie les adresses contenues dans cette structure de stockage, c'est-à-dire l'adresse de chacun des signaux connectés au port concerné déjà répertoriés.
Plus spécifiquement, dans une étape 64 on se demande si on a parcouru tous les ports du module. Tant qu'il en reste un non encore traité, on se demande dans une étape 65 si la structure de stockage associée à ce port est vide. Si la réponse est oui, c'est qu'aucun signal n'a encore été relié à ce port, et on retourne à l'étape 64. Si au contraire la réponse est non, c'est que au moins un signal a été relié à ce port pour réaliser une connexion. Pour chaque adresse de signal ainsi stockée (étape 66), on envoie dans une étape 67, l'adresse de ce signal à l'objet d'extraction de topologie grâce à la fonction "SetLien"déjà présentée plus haut.
A titre d'exemple, on peut considérer l'implémentation de la fonction "dosendinfo"qui est donnée à l'Annexe 6 en se limitant à la partie concernant le port d'entrée in~1 du module M6. Pour le port in~1, on va parcourir la liste repérée par la variable "hdln~1" grâce à la variable temporaire "ptr"qui est un pointeur sur liste de type"structure~liste". Chaque adresse de signal contenue dans cette liste sera enregistrée vers et enregistrée par l'objet d'extraction de topologie dont l'adresse est contenue dans la variable"Circuit" grâce à l'utilisation de la méthode"SetLien"qui a été décrite précédemment.
L'on parcourt ainsi toutes les listes correspondant aux ports d'entrée et de sortie du module (pour l'exemple du module M6 de type"Dec", il y a cinq listes : celles repérées par les pointeurs & hdln~1, & hdln~2, & hdln~3, & hdOut~1 et & hdOuC2) Une fois que toutes les informations relatives aux connexions réalisées antérieurement à l'appel de la fonction d'initialisation ont été envoyées vers l'objet d'extraction de topologie (c'est-à-dire lorsque le test de l'étape 64 donne
une réponse négative), les listes sont ensuite détruites, dans une étape 68, grâce à une fonction"DeleteListe"dont l'implémentation est à la portée de l'homme du métier et qui fait partie d'une bibliothèque accessible par les modules. Ceci est réalisé, par exemple pour la liste de stockage des connexions associés au port d'entrée in~1 du module M6, par une instruction du type suivant : DeleteListe ( & hdln~1))) Cette fonction"DeleteListe"permet de libérer l'espace mémoire réservé pour l'ensemble des éléments d'une structure de stockage associée à un port. Son implémentation est à la portée de l'homme du métier.
Il reste à exposer le traitement mis en oeuvre au niveau de l'objet d'extraction de topologie.
L'objet d'extraction de topologie reçoit l'adresse de chaque module qui lui est passée lors de l'appel de la fonction"MakeModule". Il reçoit aussi l'adresse de chaque signal relié à chaque port de chaque module, lors des appels aux fonctions de connexion inti et Outj respectives pour chacun de ces ports. Il stocke ces différentes adresses dans une structure de stockage de topologie déterminée. Dans un exemple, cette structure de stockage de topologie comprend un tableau et une liste générés dynamiquement par l'objet d'extraction de topologie. Lorsque l'ensemble des informations de topologie se rapportant au système ont été extraites, le tableau comporte autant de cellules renseignées qu'il y a de modules présents dans le système. Il est appelé tableau des modules dans la suite. De plus, la liste contient autant de cellules qu'il y a de connexions port/signal dans le système. Elle est appelée liste des connexions dans la suite.
Figure 3A : tracé en utilisant neuf marqueurs SIDP, parmi lesquels quatre et cinq ont respectivement été marqués à l'aide des fluorochromes HEX et FAM, ainsi qu'un standard de taille. La taille des produits d'amplification se trouve en abscisse, et l'intensité de la fluorescence en ordonnée. Dans cet exemple, seul deux marqueurs sont hétérozygotes et ont donné lieu à la détection de deux pics.
Figure 3B : le tableau indique, pour chaque pic, sa durée de migration jusqu'à la fenêtre de lecture, sa taille en nombre de bases, sa hauteur et sa surface.
L'invention sera mieux comprise à l'aide des exemples suivants, donnés à titre purement illustratif. Il est entendu que la présente invention ne se limite en aucune façon auxdits exemples.
EXEMPLES Le procédé de détection des anomalies génétiques présentées par les cellules tumorales selon l'invention a été appliqué à la mise en évidence des TV.
Il a été choisi de tester des régions chromosomiques fréquemment décrites dans la littérature comme présentant des DA à l'origine de TV, ceci afin de disposer d'éléments de comparaison. Ainsi, les bras chromosomiques suivants ont été étudiés : 9p, 9q, 17p, 10q, 13q, 6q, 3p et 5q.
1- Matériels et méthodes 1-1- Patients Le critère d'inclusion dans l'étude était la découverte d'une TV chez des personnes ne présentant pas d'antécédents de cancer uro-génital.
Les témoins étaient des patients hospitalisés pour divers motifs en urologie (calculs, incontinence urinaire, adénome prostatique....).
En définitive, seuls ont été exclus les patients et témoins ayant des antécédents de cancer uro-génital.
87 patients ont ainsi été retenus, répartis en 24 témoins et 63 cas.
Les caractéristiques histologiques des cas sont récapitulées dans le tableau V suivant.
pla pli pT2-4 Total G1 9 2 0 11 G2 18 6 3 27 G3 1 16 8 25 Total 28 24 11 63 1-2- Marqueurs Les marqueurs étaient des SIDP dont les séquences sont accessibles sur le site : http : //www. research. marshfieldclinic. orq.
1-2-1) Nombre de marqueurs étudiés Le taux d'hétérozygotie, et par là-même d'informativité, des microsatellites étant supérieur à celui des SIPD, un nombre plus important de marqueurs SIDP devaient être utilisés pour parvenir au même niveau d'informativité.