FR 2878685 A1 20060602 FR 0412727 A 20041130 Déclenchement de session pro-active depuis une applet dans une carte à puce La présente invention concerne une application distribuée sous forme d'une première partie dans un terminal et d'une deuxième partie dans une carte à puce, dite également carte à microcontrôleur ou carte à circuit intégré, connectée au terminal. Selon un exemple préféré auquel on se référera dans la suite de la description, le terminal est un terminal radio mobile dans un réseau de radiocommunications cellulaire numérique, et la carte à puce est un module d'identité d'usager amovible du type UICC (Universal Integrated Circuit Card). L'invention se rapporte ainsi à un terminal ouvert dans lequel est implémenté un sys :ème d'exploitation ouvert qui autorise un téléchargement dynamique d'applications additionnelles au-dessus du système d'exploitation, réparties chacune pour partie dans le terminal et pour partie dans une carte à puce. Une telle carte à puce permet de stocker des applications et comporte une application principale SIM (Subscriber Identity Module) ou USIM pour communiquer avec l'extérieur via une interface de communication dans le terminal et authentifier l'usager de la carte. Seule ladite application principale accède de manière synchronisée à l'interface de communication dans le terminal. Aucune des deuxièmes parties des applications distribuées ne peut accéder de manière synchronisée à l'interface de communication. Ainsi les premières parties des applications distribuées et l'interface de communication bien qu'indépendants et exécutables sur le système d'exploitation du terminal peuvent accéder de manière séparée à la carte à puce. Par exemple une commande établie par une première partie d'une application distribuée et transmise à la carte à puce peut conduire à une action nécessitant une réponse de la carte à puce incluant une commande pro-active devant recourir à l'interface de communication dans le terminal, comme un établissement d'appel. Cependant la première partie d'application n'étant pas capable d'interpréter la commande pro-active ne peut pas déclencher une session pro-active. D'autre part, l'interface de communication n'ayant pas interrogé la carte à puce et n'étant donc pas à l'origine de la commande pro-active établie ne peut pas également l'interpréter, ce qui conduit à un blocage. L'invention a pour objectif de surmonter le défaut de synchronisation entre la première partie d'une application distribuée et l'interface de communication afin que la deuxième partie de l'application puisse délivrer à l'interface de communication une commande pro-active interprétable par celle-ci. Pour atteindre cet objectif, un procédé pour déclencher une action dans une interface de communication d'un terminal incluant une première partie d'une application, depuis une deuxième partie de l'application installée dans une carte à puce connectée au terminal, est caractérisé en ce qu'il comprend les étapes suivantes après une commande désignant l'action et transmise par la première partie d'application à la deuxième partie d'application: mise en sommeil de la première partie d'application, mise en veille de la deuxième partie d'application et mémorisation de paramètres de l'action désignée dans la carte à puce, réveil de la deuxième partie d'application suite à une commande d'événement transmise par l'interface de communication et lecture des paramètres d'act=_on mémorisés, et établissement d'une commande selon les paramètres d'action lus dans la deuxième partie d'application réveillée et transmission de la commande établie à l'interface de communication. La commande ainsi établie et transmise à l'interface de communication est une commande pro-active qui peut déclencher une communication avec l'extérieur du terminal tel qu'un autre terminal ou un serveur. L'invention a aussi pour objet une carte à puce connectée à un terminal pour mettre en oeuvre le procédé de l'invention. La carte à puce comprend, lorsqu'après une commande désignant l'action et transmise par la première partie d'application â la deuxième partie d'application: un moyen pour mettre en sommeil la première partie d'application, un moyen pour mettre en veille la deuxième partie d'application et mémoriser des paramètres dE l'action désignée dans la carte à puce, un moyen pour réveiller la deuxième partie d'application suite à une commande d'événement transmise par l'interface de communication et lire les paramètres d'action mémorisés, et un moyen pour établir une commande selon les paramètres d'action lus dans la deuxième partie d'application réveillée et transmettre la commande établie à l'interface de communication. L'invention se rapporte encore à un programme d'ordinateur apte à être mis en uvre dans une carte à puce selon l'invention connectée à un terminal. Le programme comprend des instructions de code qui, lorsque le programme est chargé et exécuté sur ladite carte à puce, réalisent les étapes selon le procédé de l'invention. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention, données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels: - la figure 1 est un bloc-diagramme schématique d'un terminal radio mobile et d'une carte à :Duce incluant des moyens selon une réalisation préfêrée mettant en oeuvre l'invention; et - la figure 2 est un algorithme du procédé pour déclencher une action dans une interface de communication du terminal depuis une deuxième partie d'application, selon l'invention. Dans un terminal 1 du type terminal radio mcbile et une carte à puce 2 montrés à la figure 1 sont représentés des blocs fonctionnels dont la plupart assurent des fonctions ayant un lien avec l'invention et peuvent correspondre à des modules logiciels et/ou matériels. Le terminal mobile 1 est inclus dans un réseau de radiocommunications cellulaire numérique RR par exemple du type GSM, GPRS ou UMTS et peut communiçuer avec d'autres terminaux M, T et des serveurs S à travers le réseau RR, un réseau téléphonique commuté RTC et l'internet IN par exemple. La carte à puce 2 constitue un module d'identité d'usager du type UICC (Universal Integrated Circuit Card) amovible du terminal mobile 1. La carte à puce est une carte SIM (Subscriber Identity Module) lorsque le réseau RR est du type GSM ou GPRS. La carte à puce contient l'application USIM lorsque le réseau RR fonctionne en accès multiple à répartition par codes CDMA (Coded Division Multiple Access) selon la troisième génération (3GPP) du type UMTS (Universal Mobile Telecommunications System). En variante, le terminal mobile 1 est un petit équipement tel qu'un assistant numérique personnel (PDA) pouvant communiquer avec des réseaux et échanger des commandes et des réponses avec une carte à puce. Selon d'autres exemples, le terminal est un terminal fixe comme un terminal bancaire accueillant une carte à puce de débit ou de crédit, ou un dispositif portable de transmission de messages, ou un ordinateur personnel (PC) doté d'un lecteur de carte à puce. Plus généralement, la carte à puce est un objet électronique portable tel qu'une carte de débit: ou crédit, un porte-monnaie électronique, une carte à puce additionnelle ou tout autre dispositif électronique petit ou miniature. En général, le terminal 1 contient en tant que périphérique un lecteur 11 qui est lié à un port d'entrée/sortie 21 de la carte à puce 2 avec ou sans contact électrique. Outre le lecteur de carte à puce 11, le terminal 1 du type radiotéléphonique mobile comprend classiquement un processeur 12, des mémoires 13 et une interface radio 14 reliés par un bus 15. Les mémoires 13 regroupent diverses mémoires telles qu'une mémoire morte ROM, une mémoire non volatile EEPROM et une mémoire RAM. Lorsque le terminal est par exemple un ordinateur personnel, les mémoires 13 comprennent un disque dur. L'interface radio 14 transpose en fréquence, convertit numériquement, démodule et décode des messages reçus via le réseau fixe dans le réseau RR, et inversement transmet des messages. Le terminal 1 comprend d'autres périphériques à l'interface d'usager avec le processeur 12 tels qu'un clavier, un affict.eur graphique, un haut-parleur et/ou un microphone. Les mémoires 13 dans le terminal 1 contiennent notamment un système d'exploitation OS par exemple du type BREW, PALM OS, SYMBIAN, WINDOWS MOBILE, ou NUCLEUS, un environnement d'exécution comme par exemple une machine virtuelle Java JVMT et diverses applications et données, et peuvent contenir également un navigateur B. Dans la suite de la description, on se référera à une machine virtuelle Java. En particulier, dans la mémoire non volatile des mémoires 13 sont implémentées des premières parties APT d'applications AP distribuées également dans la carte à puce 2, un gestionnaire d'installation d'application GIA pouvant être inclus dans la machine virtuelle JVMT, et un chargeur CAPC. Les applications AP sont écrites initialement dans un langage de haut niveau du type orienté objet tel que le langage Java compatible avec la machine virtuelle JVMT. Les premières parties APT d'applications AP sont appelées aussi MIDlet (Mobile Information Device applet). Le gestionnaire GIA programmé en langage Java et exécutable dans le terminal sert à installer diverses applications dans les mémoires 13 et à lancer leurs exécutions, et en particulier à installer et lancer la première partie APT de chaque application AP. Les applications AP sont téléchargées dans le terminai et la carte à puce par exemple depuis un serveur d'application SA géré par exemple par l'éditeur de la carte à puce 2 ou bien tout autre éditeur. En lia:_son avec le gestionnaire GIA, le chargeur CAPC charge une deuxième partie APC de chaque application AP depuis le terminal dans la carte à puce. Le chargeur CAPC crée un lien entre la machine virtuelle JVMT et le gestionnaire GIA implémentés dans le terminal et une machine virtuelle Java JVMC et un outil informatique 01 implémentés dans la carte à puce 2 pour instaLler les deuxièmes parties APC des application A:? à travers un protocole de communication prédéterminé. En variante, les parties APT et APC d'une application AP ne sont pas téléchargées et ont été installées dans le terminal 1 et la carte à puce 2 lors de la fabrication de ceux-ci. Typiquement le protocole de communication prédéterminé est un protocole asynchrone à l'alternat ayant des unités de données de protocole (APDU) constituées par des commandes COM transmises depuis le terminal 1 à la carte à puce 2 et des réponses REP transmises depuis la carte à puce 2 au terminai 1. Selon ce protocole, parfois désigné par SIM Application Toolkit selon la norme 3GPP TS 51.014 ou ETSI 102.223, les commandes sont toujours déclenchées à l'initiative du terminal et la carte à puce est pro-active afin d'initier des actions mais encore sous la commande du terminal. Pour que les premières parties APT des applications AP communiquent respectivement avec les deuxièmes parties APC des applications AP conformément au protocole de communication prédéterminé, une interface d'accès IA pour accéder aux ressources et données dans la carte à puce est implémentée dans les mémoires 13 par exemple sous la forme d'un programme Java API (Application Programming Interface) conforme à la spécification JSR 177 dans le cas d'un terminal J2ME supportant la technologie Java. Les mémoires 13 comprennent encore une interface de communication IC, encore appelée moteur SIM Toolkit, afin que l'application principale SIM ou USIM ou toute autre application dans la carte à puce 2 communique avec le "monde extérieur" via le terminal 1, par exemple avec un serveur S ou un terminal M, T relié à l'internet IN. L'interface de communication IC gère des commandes et réponses échangées entre le "monde extérieur" et l'application principale SIM ou USIM par exemple pour les adapter à des messages courts échangés avec un serveur de messages courts du réseau RR et empaquetant des données transmises et reçues par le serveur S ou le terminal M à travers l'internet IN. La carte à puce 2 comprend classiquement sous forme intégrée un microprocesseur 22, une mémoire non réinscriptible 23 du type ROM, une mémoire non volatile 23 du type EEPROM et une mémoire 25 du type RAM destinée essentiellement à échanger des données avec le terminal 1 à travers le port d'entrée/sortie 21 et le lecteur 11. Les mémoires 23 et 24 contiennent les codes et les données par exemple d'un système d'exploitation OSC et de la machine virtuelle JVMC conforme à la spécification Java Card, ou de tout autre système d'exploitation propriétaire. La mémoire non volatile 24 contient des applicatio:s, comme l'application SIM ou USIM, initialement installées lors de la fabrication de la carte et l'outil d'installation 0I. La mémoire 24 comporte également un espace mémoire pour mémoriser les deuxièmes parties APC des applications distribuées AP transmises par le serveur SA au terminal 1 et téléchargées par le chargeur CAPC coopérant avec l'outil d'installation 0I à travers le lecteur 11, le port 21 et la mémoire RAM 25. Les deuxièmes parties d'application APC constituent des applets STK (SIM ToolKit). En référence maintenant à la partie supérieure de la figure 2 relative à une session par exemple du type SAT (SIM Application Toolkit), on rappelle quelques échanges de commandes COM transmises par le terminal 1 à la carte à puce 2 et de réponses REP transmises par la carte à puce 2 au terminal 1 selon le protocole de communication prédéterminé qui impose que chaque couple de commande et réponse soit déclenché à l'initiative du terminal car la carte bien que pro-active est esclave du terminal. A des étapes E0, au début de la session entre des première partie APT et deuxième partie APC d'une application AP, la première partie d'application requiert une ouverture de session à l'interf=ace d'accès IA qui établit une commande ENVELOPE ENV pour transférer la désignation de l'action dans la deuxième partie d'application APC, en l'occurrence une action pour obtenir (SELECT ITEM) une page. La partie d'application APC dans la carte 2 retourne par exemple une liste de services désignés chacun par un nom et/ou un icone, compressée dans le champ de données d'une réponse REP à l'interface d'accès IA pour que la partie d'application APT fournisse une page de noms et/ou d'icones correspondant aux services et commande l'affichage de cette page sur l'écran du terminal 1. Puis l'usager du terminal sélectionne le nom ou l'icone d'un service et navigue dans un sous-menu correspondant afin que par l'intermédiaire de couples de commande ENV et réponse REP la première partie d'application APT transmette des sélections dans des pages et la deuxième partie d'application APC transmette des pages à afficher. A ce stade, comme déjà signalé à propos de la technique antérieure dans le préambule de la description et comme montré à une étape El danE la figure 2, une sélection de l'usager peut conduire à une action (TERMINAL RESPONSE) nécessitant une réponse incluant une commande pro-active. L'ac:ion peut particulièrement être relative à une communication avec une entité M, T, S extérieure au terminal 1, qui recourt à l'interface de communication IC. L'action correspond à une commande pro-active relative par exemple à une demande d'établissement d'appel (SET-UP CALL) ou une demande d'envoi de message court (SEND SHORT MESSAGE) établie par la deuxième partie d'application APC et destinée à l'interface de communication IC dans le terminal 1. La commande pro-active ne peut pas être interprétée par la première partie d'application APT qui ne peut gérer aucune session pro-active. En outre, l'interface de communication IC restera inactive puisqu'elle n'a pas interrogé (FETCH) la carte à puce pour cette commande pro-active. Selon l'invention, le défaut de synchronisation entre la première partie d'application APT (MIDlet) et l'interface de communication IC est surmonté grâce à des étapes E2 à E6 succédant à l'étape El et montrées à la figure 2. Après l'étape El, la deuxième partie d'application APC ne répond pas par une commande pro-active, mais la partie d'application APC s'enregistre dynamiquement dans une table d'événements incluse dans la carte afin d'être réveillée lors de l'apparition de l'événement status. La partie d'application APC bascule alors à un état de veille après l'avoir signalé par une réponse REP 'Ox 90 00' sans données à la première partie d'application APT qui termine ainsi momentanément la communication avec la deuxième partie d'application APC et se met en sommeil, à l'étape E2. L'état de veille à l'étape E3 engendre dans la carte à puce 2 un transfert de paramètres de l'action désignée par la prem=_ère partie d'application APT à l'étape El pour les écrire dans un espace d'événement de la mémoire 24, et la mise d'un bit d'état BE à un premier état logique "0" dans la carte 2. Pendant les étapes EO à E2, l'interface de communication IC continue d'interroger périodiquement la carte à puce 2. Ainsi à la suite de la réponse REP 'Ox 90 00', une prochaine commande d'événement ENV(status event) est transmise à l'étape E4 par l'interface de communication IC à la deuxième partie d'application APC et interroge la carte à puce sur l'intention de celle-ci d'envoyer une commande pro-active. Dans la carte à puce, la deuxième partie d'application APC à l'état de veille BE = "0" est à l'écoute de toute demande d'événement et est réveillée par une commande d'événement 'ste.tus event', à l'étape E5. La partie d'application APC lit les paramètres de l'action désignée par la partie d'application APT à l'étape El, dans l'espace d'événement de la mémoire 24 de la carte à puce. Le bit d'état BE est mis à un deuxième état logique "1" pour que la partie d'application APT ainsi réveillée établisse une réponse REP avec la commande pro-active correspondant aux paramètres lus de l'action désignée, comme par exemple une demande d'établissement d'appel (SET UP CALL) ou une demande d'envoi de message court (SEND SMS). La partie d'application APC efface dynamiquement son enregistrement relatif à l'événement status dans la table d'événements, sauf, si elle doit exécuter d'autres commandes, comme illustré par les étapes ci-après EOa. A l'étape E6, la commande pro-active dans la réponse REP est établie selon les paramètres de l'action lus dans la mémoire 24 et transmise par la partie d'application réveillée APT à l'interface=_ de communication IC du terminal 1. L'interface IC traite alors d'une manière classique la commande pro-active, en requérant l'établissement d'un appel auprès du réseau fixe du réseau RR ou transmettant un message court au serveur de messages courts, selon les deux exemples précités. En variante de l'étape El, la deuxième partie d'application APC est activée par un événement externe ou interne au terminal mais indépendant de la première partie d'application APT afin que la deuxième partie APC réponde suivant l'étape E8, par exemple en lançant le navigateur. Si la première partie d'application APT doit continuer une exécution d'établissement de commande après la réponse REP 'Ox 90 00' sans données de la deuxième partie d'application APC, la partie d'application APT se met en sommeil, simulant une occupation à l'étape E2, jusqu'à ce qu'elle reço:_ve une commande pro-active particulière de type "push" qui va la pousser à se réveiller, après les étapes E4 à E6. Comme montré en bas de la figure 2, la commande pro-active particulière est par exemple une commande de lancement de navigateur LAUNCH BROWSER qui est établie et transmise par la deuxième partie d'application APC à une étape E8 succédant à une étape E7 et qui contient des données et une adresse locale URL (Uniform Resource Locator) pour interpréter les données afin de lancer le navigateur-B dans le terminal 2. Au cours de l'étape E7, l'interface de communication IC a transmis une commande d'événement précédente 'status event' à la deuxième partie d'application APC, après les étapes E4 à E6 et l'exécution de l'action désignée dans l'interface de communication IC, précédant les étapes E7 et E8. La commande pro-active particulière LAUNCH BROWSER crée une dynamique entre les parties d'application APT et APC suivant le sens de la deuxième partie d'application APC vers la première partie d'application APT. L'interaction entre les parties d'application APT et APC est poursuivie à la suite de l'étape E8 par des échanges classiques de commandes et réponses EOa.analogues aux étapes EO et pouvant être poursuivies par des étapes Ela à E6a selon l'invention, comme montré en bas de la figure 2. REVENDICATIONS 1 - Procédé pour déclencher une action dans une interface de communication (IC) d'un terminal (1) incluant une première partie (APT) d'une application (AP), depuis une deuxième partie (APC) de l'application installée dans une carte à puce (2) connectée au terminal, caractérisé en ce qu'il comprend les étapes suivantes après une commande désignant l'action et transmise (El) par la première partie d'application à la deuxième partie d'application: mise en sommeil (E2) de la première partie d'application (APT), mise en veille (E3) de la deuxième pa:tie d'application (APC) et mémorisation de paramètre: de l'action désignée dans la carte à puce, réveil (E5) de la deuxième partie d'applica:ion (APC) suite à une commande d'événement transmise (E4) par l'interface de communication (IC) et lecture des paramètres d'action mémorisés, et établissement (E6) d'une commande selon les paramètres d'action lus dans la deuxième partie d'application réveillée (APC) et transmission de la commande établie à l'interface de communication (IC). 2 - Procédé conforme à la revendication 1, selon lequel l'action désignée est relative à une communication avec une entité (M, T, S) extérieure au terminal (1). 3 - Procédé conforme à la revendication 1 ou 2, comprenant, après exécution de l'action désignée dans l'interface de communication (IC) et transmission (E7) d'une commande d'événement depuis l'interface de communication (IC) à la deuxième partie d'application (APC), une transmission (E8) d'une commande particulière depuis la deuxième partie d'application à la première partie d'application (APT) pour réveiller la première partie d'application. 4 - Procédé conforme à la revendication 3, selon lequel la commande particulière lance un navigateur (B) dans le terminal (1). - Carte à puce (2) connectée à un terminal (1) pour déclencher une action dans une interface de communication (IC) du terminal incluant une première partie (APT) d'une application (AP), au moyen d'une deuxième partie (APC) de l'application installée dans la carte à puce (2), caractérisée en ce qu'elle comprend, lorsqu'après une commande désignant l'action et transmise (El) par la première partie d'application à la deuxième partie d'application un moyen (E2) pour mettre en sommeil la première partie d'application (APT), un moyen (E3) pour mettre en veille la deuxième partie d'application (APC) et mémoriser des paramètres de l'action désignée dans la carte à puce, un moyen (ES) pour réveiller la deuxième pa.:'tie d'application (APC) suite à une commande d'événement transmise (E4) par l'interface de communication (IC) et lire les paramètres d'action mémorisés, et un moyen (E6) pour établir une commande salon les paramètres d'action lus dans la deuxième partie d'application réveillée (APC) et transmettre la commande établie à l'interface de communication (:CC). 6 - Programme d'ordinateur apte à être mis en oeuvre dans une carte à puce (2) connectée à un terminal (1), pour déclencher une action dans une interface de communication (IC) du terminal incluant une première partie (APT) d'une application (AP), depuis une deuxième partie (APC) de l'application installée dans la carte à puce (2), caractérisé en ce qu'il comprend des instructions de programme qui, lorsque le programme est chargé et exécuté sur ladite carte à puce, réalisent les étapes suivantes après une commande désignant l'action et transmise (El) par la première partie d'application à la deuxième pa:_tie d'application: mise en sommeil (E2) de la première partie d'application (APT), mise en veille (E3) de la deuxième partie d'application (APC) et mémorisation de paramètre; de l'action désignée dans la carte à puce, réveil (E5) de la deuxième partie d'application (APC) suite à une commande d'événement transmise (E4) par l'interface de communication (IC) et lecture des paramètres d'action mémorisés, et établissement (E6) d'une commande selon les paramètres d'action lus dans la deuxième partie d'application réveillée (APC) et transmission de la commande établie à l'interface de communication (IC).