FR 2804769 A1 20010810 FR 0001502 A 20000207 MICROCONTROLEUR ET PROCEDE POUR LA GESTION D'APPLICATIONS INTERACTIVES La présente invention concerne un microcontrôleur destine à être incorpore dans un objet portatif, notamment au format carte appelée carte à circuit intégré, coopérant avec un terminal. Elle concerne également un procédé de gestion d'applications tel microcontrôleur. L'invention trouve une application particulièrement avantageuse dans le domaine de la téléphonie. Dans le domaine de la téléphonie, le terminal est un téléphone portable appelé mobile comprenant généralement un écran et un clavier. Ledit mobile coopère avec la carte à circuit intégré appelee carte SIM. Cette dernière est fournie par un opérateur de télécommunications gérant réseau de télécommunication et permet à un utilisateur du mobile accès audit réseau. Une carte à circuit intégré se compose d'un corps de carte dans lequel est incorporé le microcontrôleur. Ce dernier comporté au moins une application appelée application toolkit basée sur un protocole de communication appelé protocole toolkit ># décrit dans les standards GSM 11.11 et GSM 11.14 édités par l'ETSI. Une application # A l'aide des applications toolkits et grâce à une fonctionnalité appelée en langage anglo-saxon Multiple Card définie dans le standard GSM 11.14, on peut également adresser une deuxième carte à circuit intégré connectée au mobile, en envoyant des commandes sur ladite deuxième carte à partir du microcontrôleur de la première carte. Cette deuxième carte peut être utilisée par un fournisseur de service, exemple une banque. Elle comporte un microcontrôleur comprenant application bancaire permettant d'effectuer des services connus de transactions bancaires ou de porte-monnaie électronique. La banque peut vouloir rendre accessible sur un mobile certains de ces services tels qu'une visualisation de l'état d'un compte bancaire ou un virement bancaire. Aussi, afin de permettre l'accès à un utilisateur du mobile auxdits services proposés par la banque, selon un dispositif connu de l'état de technique et divulgué dans ledit standard GSM 11.14, le microcontrôleur de la première carte comporte une application toolkit relative aukdits services bancaires, des commandes associées ainsi que données nécessaires à une exécution desdits services telles qu'une valeur de clef secrète permettant un échange sécurisé de données ou un numéro de compte bancaire. Cette application toolkit est généralement fournie par le fournisseur de service à l'opérateur. Ce dernier la met sur sa première carte. Dans l'application toolkit, on utilise la fonctionnalité Multiple Card pour permettre notamment d'exécuter dans le microcontrôleur de la deuxième carte des commandes telles qu'une lecture numéro de compte bancaire, numéro que l'on transfère par la suite dans la première carte. Dans le dispositif décrit ci-dessus se pose alors problème d'accès aux interfaces du terminal au moyen du microcontrôleur de la deuxième carte. En effet, au moyen de la deuxième carte, on ne peut communiquer directement avec le terminal. Seule la première carte peut directement dialoguer avec le terminal et accéder aux interfaces clavier/ écran/ réseau du terminal au moyen du protocole de communication toolkit . Par suite, seule une première carte peut accéder, via ledit terminal, à des serveurs distants tels qu'un serveur du fournisseur de service comprenant par exemple des données relatives au numéro de compte bancaire. Il serait intéressant que deuxième carte puisse également dialoguer directement avec le terminal. Ce dispositif présente encore de nombreux autres inconvénients, tels un partage des données du fournisseur entre la première carte et la deuxième carte. En effet, des données du fournisseur de service se trouvant dans le microcontrôleur de première carte de l'opérateur, ce dernier doit garantir à un fournisseur de service un degré suffisant de confidentialité de ces données comprenant couramment des données secrètes et ce en effectuant, généralement, une évaluation sécuritaire sur .sa propre première carte, évaluation qui est longue, complexe et très coûteuse, une adaptation d'une application d'un fournisseur de service à chaque nouvel ensemble de premières cartes de chaque nouvel opérateur. Un microcontrôleur d'un ensemble de premières carte d'un opérateur comporte généralement des caractéristiques différentes d'un microcontrôleur d'un autre ensemble de premières cartes du même opérateur ou d'un autre opérateur. Aussi, l'application du fournisseur doit être adaptée en fonction de chaque ensemble de premières cartes d'un opérateur donné ce qui entraîne une gestion lourde des applications, - une obligation pour un opérateur de fournir une carte comportant un microcontrôleur comprenant une grande capacité mémoire pour stocker l'ensemble des applications de l'ensemble des fournisseurs de service. Aussi, un problème technique à résoudre par l'objet de la présente invention est de proposer un microcontrôleur destiné à être incorporé dans un objet portatif, notamment au format carte coopérant avec un terminal, ainsi qu'un procédé de gestion d'applications d'un tel microcontrôleur, qui permettraient, de gérer, d'une part, moins un deuxième objet portatif d'un fournisseur de service, et, d'autre part, de permettre un échange de communications entre ledit deuxième objet portatif et ledit terminal tout en palliant aux différents inconvénients cités ci-dessus. solution au problème technique posé se caractérise, selon un premier objet de la présente invention, en ce que ledit microcontrôleur comprend un dispositif de gestion d'applications interactives d'un deuxieme objet portatif, ledit deuxième objet portatif comportant au moins une application interactive comprenant des commandes d'interface et des données permettant une interaction avec au moins une interface dudit terminal, ledit dispositif étant apte à gérer des échanges de données et une exécution desdites commandes d'interface entre ledit terminal et ledit deuxième objet portatif. Selon un second objet de la présente invention, cette solution se caractérise en ce que le procédé de gestion d'applications gère des échanges de données et une exécution de commandes d'interface entre ledit terminal et un deuxième objet portatif au moyen d'un dispositif de gestion d'applications interactives compris dans ledit microcontrôleur, ledit deuxième objet portatif comportant au moins une application interactive comprenant lesdites commandes d'interface et lesdites données permettant une interaction avec au moins une interface dudit terminal. Ainsi, comme on le verra en détail plus loin, le dispositif de l'invention permet de gérer au moins une application interactive d'un fournisseur qui est enregistrée directement dans un microcontrôleur dudit deuxième objet portatif et plus dans le premier microcontrôleur du premier objet portatif. On envoie et on exécute, grâce au dispositif de gestion, des commandes d'interface de ladite application interactive dudit deuxième objet portatif audit terminal ou des commandes dudit terminal vers ledit deuxième objet portatif. Ce dernier a ainsi accès aux interfaces clavier/ écran/ réseau du terminal, le premier microcontrôleur comprenant dispositif de gestion ne servant que d'intermédiaire dans les communications entre le terminal et le microcontrôleur du deuxième objet portatif. La description qui va suivre au regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut etre réalisée. La figure 1 est un schéma d'un microcontrôleur incorporé dans un premier objet portatif conforme à l'invention, par exemple, une carte à circuit intégré. La figure 2 est un schéma du microcontrôleur de la figure 1, d'un deuxième microcontrôleur d'un deuxième objet portatif et d'un terminal. La figure 3 est un autre schéma microcontrôleur du premier objet portatif, du deuxième microcontrôleur du deuxième objet portatif et du terminal de la figure 2. La figure 4 est un premier schéma de communication entre un dispositif de gestion du microcontrôleur du premier objet portatif, le deuxième microcontrôleur du deuxième objet portatif et le terminal de la figure 3. La figure 5 est un deuxième de communication entre un dispositif de gestion du microcontrôleur du premier objet portatif, le deuxième microcontrôleur du deuxième objet portatif et le terminal de la figure 3. La figure 6 est un troisième de communication entre un dispositif de gestion du microcontrôleur du premier objet portatif, le deuxième microcontrôleur du deuxième objet portatif et le terminal de la figure 3. La figure 7 est un quatrième de communication entre un dispositif gestion du microcontrôleur du premier objet portatif, le deuxième microcontrôleur du deuxième objet portatif et le terminal de la figure 3. Le present exposé de l'invention a trait à l'exemple des cartes à circuit intégré. Par carte à circuit intégré, on entend, par exemple, une carte au format ISO, une carte au format jeton couramment appelé dans le langage anglo-saxon format "plug-in", tel qu'un module d'identification abonné (SIM) ou encore une étiquette électronique. Néanmoins, il est bien entendu que l'invention s'applique de manière générale à tout microcontrôleur destiné à être incorporé tout autre objet portatif tel que par exemple une bague ou un porte clef. Il en est de même pour ledit deuxième objet portatif. Sur figure 1 est représenté un premier microcontroleur incorporé dans une première carte C 1 à circuit intégré. Ce microcontrôleur MC 1 comprend un élément 11 de commande exemple une unité centrale de traitement ou CPU), une mémoire 1 volatile réinscriptible, une mémoire 13 non volatile non réinscriptible, et un bloc 14 de contacts destiné à une connexion électrique/ électromagnétique avec par exemple un connecteur d'un lecteur de cartes contact/ sans contact placé dans un terminal T. Le microcontrôleur MC 1 comporte en outre un dispositif de gestion DSG d'applications interactives d'une carte à circuit intégré et une première application Al. La première carte C 1 est de préférence insérée dans le terminal T. Le dispositif DSG peut se trouver dans la mémoire 13 non volatile non réinscriptible ou dans la mémoire 12 non volatile reinscriptible. Il comporte des moyens d'aiguillage et d'exécution de commande M d'application interactive. Il comporte en outre les moyens suivants - des moyens de vérification d'application M étant aptes à verifer si ladite au moins application interactive A3 du deuxième objet portatif C2 est supportée par le dispositif de gestion DSG, - moyens d'information M2 étant aptes à informer le deuxième objet portatif C2 relativement notamment aux commandes et événements supportés par le terminal T et par dispositif de gestion DSG, - des moyens de sélection d'application étant aptes à séleétiônner ladite au moins application interactive. A3 du deuxième objet portatif C2, - des moyens de scrutation périodique M4 deuxième objet portatif C2 étant aptes à vérifier périodiquement si une commande d'interface de ladite application interactive A3 est en attente d'être envoyée. Enfin, le dispositif de gestion DSG comporte une commande applicative d'envoi de commande PERFORMCARDAPDU à la deuxième carte C2. Comme on le verra par la suite, les moyens d'information M2, les moyens de sélection M3 et les moyens de scrutation périodique M4 du deuxième objet portatif C2 comprennent ladite commande applicative d'envoi de commande PERFORMCARDAPDU. Comme montré à la figure 2, le terminal T comporte une interface écran S, une interface clavier K et une interface réseau N. Il est apte à coopérer avec une deuxième carte C2 à circuit intégre. Cette deuxième carte C2 peut être insérée ou non dans le terminal T. Elle comporte un microcontroleur MC2 comprenant une deuxième application A2 et au moins une application interactive A3. Pour alléger la description, on dira qu'une carte comporte les applications au lieu de dire que le microcontrôleur de carte comporte les applications et on parlera du dispositif de gestion DSG de la première carte C 1 au lieu de parler du dispositif de gestion DSG du microcontroleur de la première carte Cl. De même, exemple, on parlera de commande exécutée dans une carte tout en sachant que la commande est exécutée dans le microcontrôleur de la carte. Enfin, on parlera indifféremment de carte coopérant avec le terminal ou de microcontôleur coopérant avec le mobile. Dans l'exemple de la figure 3, la première carte C 1 est une carte fournie un opérateur d'un réseau de télécommunication, la deuxième carte C2 est une carte bancaire fournie par un fournisseur de service telle qu'une banque et le terminal T est un mobile communiquant avec le réseau de télécommunication dudit opérateur (non représenté). La première application A1 est, par exemple, une application téléphonique standard permettant un échange de communications avec le mobile T et avec le réseau de communication. Elle se trouve de préférence dans la mémoire 13 non volatile non reinscriptible du microcontrôleur MC 1 de la première carte Cl. La deuxième application A2 est, par exemple, une application bancaire standard permettant couramment de gérer opérations de transactions bancaires avec un terminal bancaire. Elle se trouve de préférence dans la mémoire 13 non volatile non réinscriptible de la deuxième carte C2. L'application interactive A3 est, par exemple, application bancaire mobile couramment appelée dans le langage anglo-saxon mobile banking . Elle se trouve de préférence dans la mémoire 12 non volatile reinscriptible de la deuxième carte C2. Ainsi, la banque si elle le souhaite peut modifier son application A3 sans contraintes. Ladite application interactive A3 utilise des données DATA et plus particulierement des données secrètes telles qu'un numero de compte bancaire NB. La deuxième carte C2 comporte toutes les données DATA, y compris les données secrètes, relatives à ladite application interactive A3. Lesdites données et ne sont par suite connues ni la première carte Cl, ni des autres deuxièmes cartes C2 qui pourraient venir coopérer avec le mobile. Par suite, une sécurité et une indépendance des données sont préservées. Ainsi un opérateur n'aura pas à garantir à un fournisseur de service un degré suffisant de confidentialité des données notamment secrètes dudit fournisseur et par suite n'aura pas besoin d'effectuer une évaluation sécuritaire sur sa propre première carte Cl. Les données DATA se trouvent de préférence dans la mémoire 12 non volatile réinscriptible. L'application interactive A3 permet une interaction avec au moins une interface du mobile. Elle est gérée au moyen du dispositif de gestion DSG de la première carte C 1 qui administre des échanges de données une exécution de commandes de l'application interactive A3 entre ledit mobile T et ladite au moins deuxième carte C2. On notera que le dispositif de gestion DSG se trouvant dans une première carte C 1 présente l'avantage qu'un opérateur pourra utiliser sa première carte C 1 dans tout terminal pouvant communiquer avec sa carte. I1 ne sera pas dépendant d'un fournisseur de terminal donné. Grace au moyens d'aiguillage et d'exécution de commande M du dispositif de gestion DSG, on aiguille au moins une commande provenant de l'application interactive A3 de ladite deuxième carte C2 vers le mobile T, on exécute ladite commande dans ledit mobile T et on envoie une réponse issue du mobile T vers cette même carte C2. De même, gràce à ces moyens, on aiguille au moins une commande provenant dudit mobile T vers ladite deuxième carte C2, on exécute ladite commande dans ladite deuxième carte C2 et on envoie une réponse issue de ladite deuxième carte C2 vers ledit mobile T. A cette fin, les moyens d'aiguillage M du dispositif de gestion DSG comprennent les moyens suivants - des moyens de recherche commande d'interface M5 étant aptes à rechercher une commande d'interface, provenant de l'application interactive la deuxième carte C2, en attente d'être envoyée, - des moyens de réception et de sauvegarde de commande d'interface M6 étant aptes à réceptionner et à sauvegarder la commande d'interface envoyée à partir de la deuxième carte C2, - des moyens d'envoi `et d'éxecution de commande d'interface M7 étant aptes à envoyer à exécuter dans le mobile T la commande d'interface provenant de la deuxième carte C2, - des moyens de sauvegarde de réponse d'exécution de commande d'interface étant aptes à sauvegarder une réponse d'exécution de commande d'interface issue du mobile T suite à l'exécution de ladite commande, - des moyens d'envoi de reponse M9 étant aptes à envoyer ladite réponse à la deuxième carte C2. Les moyens de recherche de commande M5 et les moyens d'envoi de réponse M9 comprennent ladite commande applicative d'envoi de commande PERFORMCARDAPDU. Ladite commande applicative PERFORMACARAPDU est apte à encapsuler une commande. De plus, elle est apte à déclencher, d'une part, l'envoi de la commande encapsulée dudit mobile à ladite deuxième carte C2, et, d'autre part, l'exécution de ladite commande dans ladite deuxième carte C2, lorsqu'elle est envoyée de la première carte C 1 audit mobile T par le dispositif de gestion DSG. La commande d'envoi commande PERFORMCARDAPDU est apte à encapsuler au moins commande appartenant à un groupe de commandes de gestion de protocole. Préférentiellement, des commandes appartenant à deux groupes différents peuvent être encapsulées (non représenté). Le premier groupe de commandes comporte notamment commandes envoyées par le mobile T, appelées commandes simples, telles que - commande d'état STATUS donnant à une deuxième carte C2 moyens d'indiquer au dispositif de gestion DSG qu'une commande commande d'interface est en attente d'être envoyée, - commande de sélection, - une commande de mise à jour de données.... Le deuxième groupe de commandes comporte notamment des commandes de gestion de protocole, appelés dans le standard GSM 11.14 commandes toolkit et protocole toolkit, telles que - une commande de propriété TERMINALPROFILE permettant d'indiquer notamment à une deuxième carte C2 quelles sont les commandes d'interface supportées par le mobile T et par ledit dispositif de gestion DSG, - commande de recherche FETCH permettant de chercher commande d'interface, d'un troisième groupe de commandes provenant d'une deuxième carte C2 et de l'envoyer au mobile, - commande de réponse TERMINALRESPONSE permettant d'envoyer, à partir du mobile vers une deuxième carte C2, une réponse provenant de l'exécution de la commande d'interface précédemment envoyée, - une commande d'indication d'événement ENVELOPE permettant d'envoyer à partir du mobile T vers une deuxième carte C2 un événement (sélection d'un menu, réception d'un message).... troisième groupe de commandes (non représenté) comporte notamment des commandes d'interface envoyées par carte, appelées dans le standard GSM 11.14 commandes proactives, telles - une commande d'affichage DISPLAYTEXT d'un message l'écran du terminal, - une commande de saisie de texte GETINPUT sur le clavier du terminal, une commande d'envoi de message SENDSMS au réseau de télécommunication.... Au moyen de l'application interactive mobile banking A3 se trouvant sur la deuxième carte C2, un utilisateur du mobile va, par exemple, pouvoir consulter un solde de son compte bancaire sur l'écran son mobile. On suppose que l'utilisateur a programmé une exécution automatique de l'application interactive A3 toutes les douze heures à partir d'un temps T0, afin d'avoir automatiquement toutes les douze heures l'affichage de son solde à l'écran de son mobile. Avant d'exécuter ladite application A3 on effectue préalablement les etapes suivantes montrées à la figure 4 une première étape S 1 d'information de la première carte 1 de la présence de ladite au moins deuxième carte C2, - une deuxième étape S2 d'activation de ladite au moins deuxième carte C2. Lors de la première étape S1, lorsqu'au moins une deuxième carte est connectée au mobile T, on envoie une commande d'information moyen du mobile T vers la première carte C 1 permettant de renseigner le dispositif de gestion DSG de la première carte C 1 l'état de ladite au moins deuxième carte C2. Par exemple, on envoie la commande appelée Envelope (EventDownLoad(CardreaderStatus) décrite dans la norme GSM 11.14. Lors la deuxième étape S2, on active la deuxième carte C2 en envoyant commande d'activation à partir de la première carte C 1 au moyen du dispositif de gestion DSG, par exemple on envoie la commande appelée PowerOnCard décrite dans la norme GSM 1 .14. Par suite, la deuxième carte C2 envoie une réponse d'activation audit mobile T, appelée couramment dans le langage anglo-saxon answer to reset . On notera que si deux deuxièmes cartes sont connectées un mobile, on active chaque carte par ordre de connexion dans ledit mobile Lorsque la deuxième carte C2 est connectée et activée, au moyen dispositif gestion DSG, on effectue les étapes suivantes montrées à la figure - une troisième étape S3 selon laquelle on vérifie si ladite au moins application interactive de la deuxième carte .C2 est supportée par le dispositif de gestion DSG, - une quatrième étape S4 selon laquelle on informe ladite deuxième carte relativement notamment aux commandes d'interface et événements supportés par le mobile T et par le dispositif de gestion DSG, - une cinquième étape S5 selon laquelle on sélectionne, si nécessaire, une application interactive dans la deuxième carte C2, - une sixième étape S6 selon laquelle on scrute périodiquement ladite deuxième carte C2 afin de vérifier périodiquement si une commande de l'application interactive est en attente d'être envoyée, - une septième étape S7 selon laquelle on recherche une commande, provenant de l'application interactive de la deuxième carte C2, en attente d'être envoyée, - une huitième étape S8 selon laquelle on réceptionne et on sauvegarde la commande envoyée à partir de la deuxième carte C2, - une neuvième étape selon laquelle, on envoie au mobile T et on exécute dans ledite mobile la commande provenant de la deuxième carte C2, - une dixième étape selon laquelle on sauvegarde une réponse d'exécution de commande issue du mobile T suite à l'exécution de ladite commande, - une onzième étape 1 selon laquelle on envoie ladite réponse à ladite deuxième carte C2, - une douzième étape S12 selon laquelle on recherche la commande en attente dans la deuxième carte C2 et ainsi de suite. Dans la troisième étape S3, on vérifie grâce aux moyens de vérification d'applications M 1 du dispositif de gestion DSG si l'application interactive mobile banking A3 de la carte C2 est supportée par le dispositif de gestion DSG. Par exemple, le dispositif de gestion DSG comporte une liste d'identifiants L AID uniques associés aux applications interactives qu'il peut gérer. Dans un premier mode de réalisation, si la deuxième carte C2 comporte plusieurs applications interactives, elle comporte une liste des identifiants desdites applications interactives. Pour chaque application interactive, on vérifie si on retrouve l'identifiant AID de l'application interactive de la deuxième carte C2 dans la liste LAID dudit dispositif DSG. Dans un autre mode de réalisation, si la deuxième carte C2 ne comporte qu'une application interactive, simultanément à l'envoi d'une réponse d'activation ( answer to reset ) au mobile T, on envoie l'identifiant de ladite application. La vérification se fait sur cet identifiant. Dans la quatrième étape, on indique, grâce aux moyens d'information M2, à la deuxième carte C2, les commandes d'interface et les événements supportés par ledit mobile T et par le dispositif de gestion DSG. A cet fin, on encapsule dans la commande applicative d'envoi de commande PERFORMCARDAPDU la commande de propriété TERMINALPROFILE. Ladite commande applicative PERFORMCARDAPDU comporte des paramètres PAR sauvegardés après qu'une commande de propriété TERMINALPROFILE a été envoyée précédemment par le mobile T à la première carte Cl. Les parametres PAR sont fonction des commandes d'interface et événement supportés par le mobile T. Préalablement à la sauvegarde des paramètres dans la premiere carte Cl, grâce à des moyens d'adaptation de paramètres (non représenté), on adapte lesdits paramètres PAR en fonction également du dispositif de gestion DSG. Ainsi, lesdits paramètres PAR sont également fonction des commandes d'interface et événements supportés le dispositif de gestion DSG. Dans un mode de réalisation non limitatif, chaque commande supportée est représentée par un élément binaire à un. commande non supportée est représentée par un élement binaire à zéro. envoie ladite commande applicative PERFORMCARDAPDU, encapsulant la commande de propriété TERMINALPROFILE, la première carte C 1 au mobile T. Le mobile envoie par la suite la commande de propriété TERMINALPROFILE à ladite deuxième carte C2. La commande est exécutée dans la carte et la carte est adaptee en fonction des paramètres vus précédemment. On évite ainsi que ladite deuxieme carte C2 fasse appel à une commande non supportée par ledit mobile T ou ledit dispositif de gestion DSG. Optionnellement, dans une cinquième étape S5, grâce aux moyens de sélection M3 du dispositif de gestion DSG, on sélectionne une application interactive se trouvant sur la deuxième carte C2. Dans un mode de réalisation non limitatif, l'application sélectionnée est celle sélectionnée par l'utilisateur, par exemple au moyen d'une commande d'indication d'événement ENVELOPE(MENUSELECTION) décrite dans le standard GSM 11.14. Cette cinquième étape n'est pas nécessaire lorsque l'identifiant de l'application interactive a été envoyé en même temps la réponse d'activation ( answer to reset ), comme vu précédemment, car l'application est sélectionnée automatiquement par défaut. Dans la sixième étape S6, gràce aux moyens scrutation périodique M4, on envoie périodiquement une commande d'état STATUS à partir du mobile T vers la deuxième carte C2 afin de vérifier si une commande interactive n'est pas en attente d'être envoyée. A cette fin, on effectue les étapes suivantes comme montrées à la figure 6 une première commande d'état STATUS est envoyee à partir du mobile T à la première carte C 1 et sauvegardée dans un tampon mémoire, lorsque la première carte C 1 est inactive c'est à dire qu'aucune opération n'est en cours d'exécution, un indicateur d'état 91XA, indiquant qu'une commande est en attente d'être envoyée par la première carte C1, est envoyé à partir du dispositif gestion DSG au mobile T, la commande de recherche de commande FETCH est envoyée du mobile à la carte C 1 afin de rechercher la commande en attente de la première carte C 1 dont une longueur XA a été indiquée dans l'indicateur d'état 91XA, la commande recherchée étant la commande applicative d'envoi de commande PERFORMCARDAPDU encapsulant la commande d'état STATUS, par suite, la commande applicative d'envoi de commande PERFORMCARDAPDU est envoyée à partir du dispositif de gestion DSG au mobile T, ladite commande encapsulant la commande d'état STATUS sauvegardée auparavant dans le tampon mémoire, - l'envoi de la commande d'état STATUS par le mobile T à la deuxième carte C2 est déclenché, et, - la commande d'état STATUS est exécutée dans la deuxième carte C2. Dans le cadre de notre application # Dans septième étape S7 montrée à la figure 6, on recherche la commande en attente comme suit - le mobile T transfère la réponse de la deuxième carte envoyant à la première carte C 1 la commande de réponse TERMINALRESPONSE ayant pour paramètre l'indicateur d'état 91XB, - un indicateur d'état 91XC, indiquant qu'une commande est en attente d'être envoyée par la première carte C1, est envoyé à partir du dispositif de gestion DSG au mobile T, - la commande de recherche de commande FETCH est envoyée du mobile la carte C 1 afin de rechercher la commande en attente de la première carte C 1, la commande recherchée étant la commande applicative d'envoi de commande PERFORMCARDAPDU encapsulant une autre commande de recherche de commande FETCHI, - la commande applicative d'envoi de commande PERFORMCARDAPDU est envoyée à partir du dispositif de gestion DSG mobile T, - par suite, l'envoi de la commande de recherche FETCH 1 par le mobile à la deuxième carte C2 est déclenché afin de rechercher la commande de saisie de numéro de compte GETINPUT NB de longueur XB, et, - la commande de saisie de numéro de compte GETINPUT NB est envoyée réponse à la commande de recherche FETCH 1, Dans la huitième étape, le dispositif de gestion DSG reçoit la commande et la sauvegarde selon les étapes suivantes le mobile transfère la réponse de la deuxième carte en envoyant ' la première carte C 1 la commande de réponse TERMINALRESPONSE ayant pour paramètre la commande de saisie GETINPUT NB, la commande de saisie est sauvegardée dans un tampon mémoire. Dans la neuvième étape, la commande de saisie de l'application interactive est envoyée au mobile et exécutée comme suit un indicateur d'état 91XD, indiquant qu'une commande est en attente d'être envoyée par la première carte Cl, est envoyé à partir du dispositif de gestion DSG au mobile T, la commande de recherche de commande FETCH est envoyée mobile à la carte C 1 afin de rechercher la commande en attente la première carte C1, la commande recherchée étant la commande de saisie GETINPUT NB de longueur XD, - la commande de saisie est récupérée dans le tampon mémoire, - la commande de saisie GETINPUT NB est envoyée au mobile T, - la commande de saisie provenant de la deuxième carte C2 est exécutée dans le mobile T. L'exécution de la commande de saisie GETINPUT se traduit par un affichage d'un message à l'écran du mobile invitant l'utilisateur à entrer le numéro de son compte NB. Lorsque l'utilisateur a tapé le numéro de son compte NB au clavier son mobile, la dixième étape est effectuée de la manière suivante le mobile T transfère la réponse de la commande de saisie GETINPUT NB en envoyant au dispositif de gestion DSG la commande de réponse TERMINALRESPONSE ayant pour paramètre le numéro NB du compte tapé, - la réponse qui est le numéro de compte tapé est sauvegardée dans un tampon mémoire. Dans la onzième étape, sur réception de la réponse, le dispositif de gestion DSG envoie le numéro de compte NB à la deuxième carte selon les étapes suivantes un indicateur d'état 91XE, indiquant qu'une commande est en attente d'être envoyée par la première carte Cl, est envoye à partir du dispositif de gestion DSG au mobile T, la commande de recherche de commande FETCH est envoyée du mobile à la carte C 1 afin de rechercher la commande en attente de la première carte Cl, la commande recherchée étant la commande applicative d'envoi de commande PERFORMCARDAPDU encapsulant la commande de réponse TERMINALRESPONSE ayant comme paramètre le numéro de compte NB, la commande applicative d'envoi de commande PERFORMCARDAPDU est envoyée à partir du dispositif gestion DSG au mobile T, la deuxième carte reçoit la réponse qui est le numéro de compte NB. Avec le numéro de compte bancaire, on doit maintenant interroger serveur de la banque comportant le solde dudit compte bancaire. Pour se faire, une autre commande de l'application interactive mobile banking de la deuxième carte C2 doit être envoyée. La commande en attente d'être envoyée est cette fois-ci un message d'interrogation SENDSMS à envoyer via le réseau de communication au serveur de la banque. Aussi, dans la douzième étape S12, comme il est montré à la figure 7, on recherche ladite commande en attente dans la deuxième carte conformément à la septième étape vue précédemment. Le dispositif de gestion DSG reçoit le message d'interrogation SENDSMS et l'envoie au mobile T, conformément à la huitième étape décrite précédemment. La commande d'interrogation est exécutée dans le mobile T. L'exécution de la commande se traduit par un envoi du message au serveur de la banque via le réseau de communication. Le serveur envoie une réponse d'acquittement de message DR au mobile T, qui conformément à la dixième étape décrite l'envoie au dispositif de gestion DSG. Sur reception de la réponse, le dispositif de gestion DSG envoie le message d'acquittement DR à la deuxième carte C2 conformément à la onzième étape. La deuxième carte C2 envoie un indicateur d'état 9000 indiquant 'aucune autre commande n'est en attente d'être envoyée. Par la suite, le serveur envoie le solde du numéro compte NB sur l'interface écran du mobile T. On notera que certaines commandes provenant d'une application interactive d'une deuxième carte C2, peuvent affecter le fonctionnement d'applications interactives se trouvant sur la première carte Cl. Par exemple, une commande d'insertion de menu SETUPMENU provenant la deuxième carte C2. Cette commande,permet..d'insérer un menu dans un menu système du terminal T qui apparaît sur l'écran S. La commande fait appel à différents identifiants ITEM_ correspondants à services que l'utilisateur pourra choisir dans le menu. Si l'application interactive de la première carte C 1 comporte également un menu et des identifiants, il risque d'y avoir un mélange entre les différents identifiants des différents menus interactifs. Aussi, le dispositif de gestion DSG comporte des moyens de renumérotation d'identifiants en fonction du menu sélectionné et du service sélectionne. Ainsi, l'objet de la présente invention permet une gestion d'applications interactives diverses et variées se trouvant sur une deuxième carte C2 coopérant avec ledit terminal et, notamment permet à toute deuxième carte C2 d'avoir aussi bien accès aux interface écran/clavier du terminal en vue d'établir un dialogue avec un utilisateur, qu'à des serveurs distants via une interface réseau auquel le terminal est connecté. Selon ce qui précède, l'objet de la présente invention présente de nombreux avantages aussi bien pour le fournisseur de service que pour le fournisseur de la carte comportant le dispositif de gestion, par exemple un opérateur. particulier, un premier avantage de l'objet de présente invention se trouve dans le fait qu'une adaptation de l'application interactive du fournisseur par rapport aux cartes de chaque nouvel operateur n'est plus nécessaire, puisque celle-ci se trouve la carte dudit fournisseur de service. Le fournisseur n'est plus dépendant des caractéristiques des premières cartes et un degré de sécurité suffisant respecté pour ses applications. Pour l'opérateur, la présente invention comporte un avantage selon lequel il n'est plus obligé de produire des cartes comportant une grande capacité mémoire. De plus, il n'est plus obligé de supporter une administration des différentes applications des fournisseurs de service ce qui simplifie la gestion de ses cartes. Un autre avantage est que l'opérateur n'a plus à définir un mécanisme de chargement d'applications de fournisseurs dans ses cartes après la mise en circulation desdites cartes. Un tel mécanisme se fait généralement au moyen de serveurs connectés au réseau dudit opérateur. Par suite, gràce à la présente invention, l'opérateur n'a plus à gérer ces applications au moyen de son réseau, ce qui auparavant créait une surcharge dudit réseau. Bien entendu, la présente invention s'applique à tout autre application, autre qu'une application bancaire, telle qu'une application de fidélité, qui implique une interaction entre au moins deux objets portatifs et un terminal. REVENDICATIONS 1 - Microcontrôleur destiné à être incorporé dans un premier objet portatif (C1), notamment au format carte, coopérant avec un terminal (T), caractérise en ce qu'il comprend un dispositif de gestion (DSG) d'applications d'un deuxième objet portatif (C2), ledit deuxième objet portatif (C2) comportant au moins une application interactive (A3) comprenant des commandes d'interface et des données permettant une interaction avec au moins une interface dudit terminal, ledit dispositif (DSG) étant apte à gérer des échanges de données et une exécution desdites commandes d'interface entre ledit terminal (T) et ledit deuxième objet portatif (C2). 2 - Microcontrôleur selon la revendication 1, caractérisé en ce que le terminal (T) avec lequel il coopère est un mobile. 3 - Microcontrôleur selon l'une quelconque des revendications 1 ou 2, caractérisé en ce le dispositif de gestion (DSG) comporte des moyens d'aiguillage et d'exécution (M) de commande d'application interactive. 4 - Microcontrôleur selon revendication 3, caractérisé en ce que lesdits moyens d'aiguillage et d'exécution de commande (M) comprennent - des moyens de recherche de commande d'interface (M5) étant aptes à rechercher une commande d'interface, provenant de l'application interactive du deuxième objet portatif (C2), en attente d'être envoyée, - des moyens de réception et de sauvegarde de commande d'interface (M6) étant aptes à réceptionner et à sauvegarder la commande d'interface envoyée à partir du deuxième objet portatif (C2), - des moyens d'envoi et d'exécution de commande d'interface (M7) étant aptes à envoyer et à exécuter dans le terminal (T) commande d'interface provenant du deuxième objet portatif (C2), - des moyens de sauvegarde de réponse d'exécution commande d'interface (M8) étant aptes à sauvegarder réponse d'exécution de commande d'interface issue du terminal (T) suite à l'exécution de ladite commande d'interface. des moyens d'envoi de réponse (M9) étant aptes à envoyer ladite réponse audit deuxième objet portatif (C2). - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 4, caractérisé en ce que le dispositif de gestion comporte en outre - des moyens de vérification d'application (M1) étant aptes à vérifier si ladite au moins application interactive du deuxième objet portatif (C2) est supportée par le dispositif de gestion (DSG), - des moyens d'information (M2) étant apte à informer le deuxième objet portatif (C2) relativement aux commandes d'interface et à des événements supportés par le terminal (T) et par le dispositif de gestion (DSG), des moyens de sélection d'application (M3) étant aptes à sélectionner ladite au moins application interactive du deuxième objet portatif (C2), des moyens de scrutation périodique (M4) du deuxième objet portatif (C2) étant aptes à vérifier périodiquement si une commande d'interface de ladite application interactive est en attente d'être envoyée. 6 - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 5, caractérisé en ce que le dispositif de gestion (DSG) comporte en outre une commande applicative d'envoi de commande (PERFORMCARDAPDU). - Microcontrôleur selon la revendication 6, caractérise en ce que ladite commande applicative d'envoi de commande (PERFORMCARDAPDU) est apte à encapsuler une commande. - Microcontrôleur selon la revendication 6, caractérise en ce que la commande applicative d'envoi de commande (PERFORMCARDAPDU) est apte à encapsuler au moins une commande appartenant à un groupe de commandes gestion de protocole. - Microcontrôleur selon la revendication 6, caractérisé en ce que ladite commande applicative (PERFORMCARDAPDU) d'envoi de commande est apte à déclencher, d'une part, l'envoi de la commande encapsulée dudit terminal (T) audit deuxième objet portatif (C2), et, d'autre part, l'exécution de ladite commande dans ledit deuxième objet (C2), lorsqu'elle (PERFORMCARDAPDU) envoyée du premier objet portatif (C1) audit terminal (T) par le dispositif de gestion (DSG). 10 - Microcontrôleur selon les revendications précédentes 4 et 6, caractérisé en ce que les moyens de recherche de commande (M5) les moyens d'envoi de réponse (M9) comprennent ladite commande applicative d'envoi de commande (PERFORMCARDAPDU). 1 - Microcontrôleur selon les revendications précédentes 5 et 6, caractérisé en ce que les moyens d'information (M2), les moyens de sélection (M3) et les moyens de scrutation périodique (M4) du deuxième objet portatif (C2) comprennent ladite commande applicative d'envoi de commande (PERFORMCARDAPDU). 12 - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 11, caractérisé en ce que ledit deuxième objet portatif (C2) comporte toutes les données (DATA), y compris des données secrètes, relatives à ladite moins application interactive (A3). 13 - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 12, caractérisé en ce ledit premier objet portatif (C1) est une carte à circuit intégré. 14 - Microcontrôleur selon l'une quelconque des revendications précédentes 1 à 13, caractérisé en ce ledit deuxième objet portatif (C2) est une carte à circuit intégré. 15 - Procédé de gestion d'applications à partir d'un microcontrôleur destiné à être incorporé dans un premier objet portatif (C1), notamment au format carte, coopérant avec un terminal (T), caractérisé en ce qu'il gère des échanges de données et une exécution de commandes d'interface entre ledit terminal (T) et un deuxième objet portatif (C2) au moyen d'un dispositif de gestion d'applications (DSG) compris dans ledit microcontrôleur, ledit deuxième objet portatif (C2) comportant au moins une application interactive (A3) comprenant lesdites commandes d'interface et lesdites données permettant une interaction avec au moins une interface dudit terminal (T). 16 - Procédé selon la revendication 15, caractérisé en ce que le terminal (T) avec lequel le microcontrôleur coopère est un mobile. 17 - Procédé selon l'une quelconque des revendications précédentes 15 ou 16, caractérisé en ce comporte une étape d'aiguillage et d'exécution de commande d'application interactive effectuée au moyen du dispositif de gestion (DSG). 18 - Procédé selon la revendication caractérisé en ce que l'étape d'aiguillage et d'exécution de commande comprend les étapes selon lesquelles - recherche une commande d'interface, provenant l'application interactive du deuxième objet portatif (C2), attente d'être envoyée, - réceptionne et on sauvegarde la commande d'interface envoyée à partir du deuxième objet portatif (C2), - envoie au terminal et on exécute dans ledit terminal (T) la commande d'interface provenant du deuxième objet portatif (C2), - sauvegarde une réponse d'exécution de commande d'interface issue du terminal (T) suite à l'exécution de ladite commande. - envoie ladite réponse audit deuxième objet portatif (C2). 19 - Procédé selon l'une quelconque des revendications précédentes 15 à 18, caractérisé en ce qu'il comporte en outre des étapes supplémentaires selon lesquelles - vérifie si ladite au moins application interactive de la deuxième carte (C2) est supportée par le dispositif de gestion (DSG), - informe le deuxième objet portatif (C2) relativement notamment aux commandes et événements supportés par le terminal (T) et par le dispositif de gestion (DSG), - on sélectionne, si nécessaire, une application interactive de la deuxième carte (C2), - on scrute périodiquement ledit deuxième objet portatif (C2) afin de vérifier périodiquement si une commande d'interface de ladite application interactive (A3) est en attente d'être envoyée, 20 - Procédé selon l'une quelconque des revendications précédentes 15 à 19, caractérisé en ce que le dispositif de gestion (DSG) comporte en outre une commande applicative d'envoi de commande (PERFORMCARDAPDU). 21 - Procédé selon la revendication 20, caractérisé en ce qu'il comporte une étape supplémentaire selon laquelle on encapsule une commande dans la commande applicative d'envoi de commande (PERFORMCARDAPDU). - Procédé selon la revendication 20, caractérisé en ce qu'il comporte les étape supplémentaire selon lesquelles - en envoyant ladite commande applicative (PERFORMCARDAPDU) d'envoi de commande, du premier objet portatif (C1) audit terminal (T) au moyen du dispositif gestion (DSG), on déclenche l'envoi de la commande encapsulée dudit terminal audit deuxième objet portatif (C2) et, on déclenche l'exécution de ladite commande dans ledit deuxième objet (C2). 23 - Procédé selon la revendication 20, caractérisé en ce qu'il comporte une étape supplémentaire selon laquelle on encapsule au moins une commande appartenant à un groupe de commandes de gestion de protocole. - Procédé selon les revendications précédentes 18 et 20, caractérisé en ce que les étapes de recherche de commande d'envoi de réponse utilisent ladite commande applicative d'envoi commande (PERFORMCARDAPDU). 25 - Procédé selon les revendications précédentes 19 et caractérisé en ce que les étapes d'information, de sélection et de scrutation périodique du deuxième objet portatif (C2) utilisent ladite commande applicative d'envoi de commande (PERFORMCARDAPDU). 26 - Procédé selon l'une quelconque des revendications précédentes 15 à 25, caractérisé en ce que ledit deuxième objet portatif (C2) comporte toutes les données (DATA), y compris des données secrètes, relatives à ladite moins application interactive. 27 - Procédé selon l'une quelconque des revendications précédentes 15 à 26, caractérisé en ce ledit premier objet portatif (Cl) est une carte à circuit intégré. 28 - Procédé selon l'une quelconque des revendications 15 à 27, caractérisé en ce que ledit deuxième objet portatif (C2) est une carte à circuit intégré.