Brevet FR2890520A1 — publié le 20070309

Exécution d'une commande pro-active élaborée dans un terminal La présente invention concerne un procédé pour 5 exécuter des commandes pro-actives élaborées dans un terminal, comme un terminal mobile. Actuellement, un terminal en liaison avec une carte à puce offre des ressources graphiques élaborées pour un affichage détaillé de données relatives à des services interagissant avec l'usager du terminal, par exemple un terminal mobile. L'affichage de services SIM Toolkit est géré par la carte à puce qui est associée au terminal et qui utilise des ressources graphiques peu performantes en comparaison de celles du terminal. L'invention a pour objectif d'exécuter une commande pro-active élaborée dans un terminal afin d'utiliser des ressources élaborées du terminal, par exemple graphiques, à la place de ressources primitives d'une carte à puce associée au terminal. Pour atteindre cet objectif, l'invention est orientée vers un procédé pour exécuter une commande élaborée par une première partie d'une application installée dans un terminal. La commande élaborée est relative à une deuxième partie de l'application installée dans une carte à puce communiquant avec le terminal. Un identificateur de commande associé à une commande pro-active est transmis par la première partie d'application à la carte à puce. Le procédé est caractérisé en ce qu'il comprend les étapes de: dans la carte à puce, si l'identificateur de commande transmis est inclus dans une liste de commandes, identifier la commande pro-active comme une commande élaborée par la deuxième partie d'application en réponse à une commande d'événement et mémoriser la commande élaborée, dans la carte à puce, en réponse à une requête d'interrogation transmise par la première partie d'application, transmettre par une application de contrôle la commande élaborée mémorisée à la première partie d'application du terminal, et dans le terminal, exécuter la commande élaborée reçue par la première partie d'application en utilisant des ressources élaborées du terminal. L'utilisation des ressources élaborées du terminal améliore l'affichage des commandes élaborées relatives à la carte à puce. Cet affichage amélioré rivalise ainsi avec celui des commandes relatives au terminal et rend possible l'utilisation de textes colorés et d'images animées par exemple en ayant recours aux fortes capacités de traitement du terminal. Ainsi, l'invention contribue au développement de l'utilisation des services SIM Toolkit. De surcroît, l'invention encourage l'utilisation de mémoires à fortes capacités pour stocker par exemple des images. L'invention concerne également un dispositif pour exécuter une commande élaborée par une première partie d'une application installée dans un terminal, ladite commande élaborée étant relative à une deuxième partie de l'application installée dans une carte à puce communiquant avec le terminal, la première partie d'application transmettant un identificateur de commande associé à une commande pro-active à la carte à puce. Le dispositif est caractérisé en ce qu'il comprend: un moyen dans la carte à puce pour identifier la commande pro-active comme une commande élaborée en réponse à une commande d'événement et mémoriser la commande élaborée, si l'identificateur de commande transmis est inclus dans une liste de commandes, un moyen dans la carte à puce pour transmettre la commande élaborée mémorisée à la première partie d'application du terminal, en réponse à une requête d'interrogation transmise par la première partie d'application, et un moyen dans le terminal pour exécuter la commande élaborée reçue en utilisant des ressources élaborées du terminal. L'invention a aussi pour objet une carte à puce pour exécuter une commande élaborée par une première partie d'une application installée dans un terminal communiquant avec la carte à puce, ladite commande élaborée étant relative à une deuxième partie de l'application installée dans la carte à puce, la première partie d'application transmettant un identificateur de commande associé à une commande pro-active à la carte à puce. La carte à puce est caractérisée en ce qu'elle comprend: un moyen pour identifier la commande pro-active comme une commande élaborée en réponse à une commande d'événement et mémoriser la commande élaborée, si l'identificateur de commande transmis est inclus dans une liste de commandes, et un moyen pour transmettre la commande élaborée mémorisée à la première partie d'application du terminal, en réponse à une requête d'interrogation transmise par la première partie d'application, afin que la première partie d'application exécute la commande élaborée reçue en utilisant des ressources élaborées du terminal. Enfin, l'invention se rapporte à un programme d'ordinateur apte à être mis en oeuvre dans un dispositif pour exécuter une commande élaborée par une première partie d'une application installée dans un terminal, ladite commande élaborée étant relative à une deuxième partie de l'application installée dans une carte à puce associée au terminal. Le programme comprend des instructions qui, lorsque le programme est chargé et exécuté dans ledit dispositif, réalisent les étapes du 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 à puce incluant des moyens selon une réalisation préférée de l'invention; et - la figure 2 est un algorithme du procédé pour exécuter une commande élaborée selon l'invention. Comme montré à la figure 1, dans un dispositif comprenant un terminal, tel qu'un terminal mobile TM, et une carte à puce CP pouvant communiquer avec le terminal 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 TM est inclus dans un réseau de radiocommunications cellulaire numérique RR par exemple du type GSM, GPRS ou UMTS et peut communiquer 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 CP, dite également carte à microcontrôleur ou carte à circuit intégré, constitue un module d'identité d'usager du type UICC (Universal Integrated Circuit Card) amovible du terminal mobile TM. La carte à puce est par exemple une carte munie d'une application SIM (Subscriber Identity Module) lorsque le réseau RR est du type GSM ou GPRS, ou d'une application USIM (Universal Subscriber Identity Module) ou RUIM (Removable User Identity Module) lorsque le réseau RR fonctionne en accès multiple à répartition par codes CDMA (Coded Division Multiple Access) de la troisième génération (3GPP) du type UMTS (Universal Mobile Telecommunications System) ou UTRAN (UMTS Terrestrial Radio Access Network), ou de la troisième génération (3GPP2) du type CDMA 2000. En variante, le terminal mobile TM 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 mobile TM est remplacé par tout terminal avec lequel peut communiquer une carte à puce, et peut être un dispositif portable de transmission de messages, ou un ordinateur personnel (PC) doté d'un lecteur de carte à puce, ou un terminal fixe comme un terminal bancaire accueillant une carte à puce de débit ou de crédit. Plus généralement, la carte à puce CP 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. Le terminal TM contient en tant que périphérique un lecteur LT qui est lié à un port d'entrée/sortie PES de la carte à puce CP avec ou sans contact électrique. Outre le lecteur de carte à puce LT, le terminal mobile TM comprend classiquement une interface radio IR, un processeur PT et des mémoires MT. Les différents éléments du terminal mobile sont reliés entre eux par un bus bidirectionnel BT. Les mémoires MT 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 mobile est par exemple un ordinateur personnel, les mémoires MT comprennent un disque dur. L'interface radio IR transpose en fréquence, convertit numériquement, démodule et décode des messages reçus via le réseau RR, et inversement transmet des messages. Le terminal mobile TM comprend d'autres périphériques à l'interface d'usager avec le processeur PT tels qu'un clavier, un afficheur graphique, un haut-parleur et/ou un microphone. Les mémoires MT dans le terminal TM contiennent notamment un système d'exploitation OS par exemple du type SYMBIAN, WINDOWS MOBILE, BREW, PALM OS, ou LINUX, un environnement d'exécution comme par exemple une machine virtuelle Java JVMT programmée en langage Java, par exemple J2ME (Java ME) , et un espace de données ED pour mémoriser des données telles que des paramètres et des indicateurs. 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 MT, sont implémentées des premières parties APT d'applications AP distribuées également dans la carte à puce CP, 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 ou le langage C avec un système d'exploitation de type BREW. Les premières parties APT d'applications AP, parmi lesquelles une première partie d'application met en oeuvre particulièrement l'invention, sont appelées aussi MIDlet (Mobile Information Device applet). Le gestionnaire GIA programmé en langage Java et exécutable dans le terminal mobile sert à installer diverses applications dans les mémoires MT 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 terminal mobile TM et la carte à puce CP par exemple depuis un serveur d'application SA géré par l'éditeur de la carte à puce CP ou bien tout autre éditeur. En liaison avec le gestionnaire GIA, le chargeur CAPC charge une deuxième partie APC de chaque application AP depuis le terminal mobile 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 mobile et une machine virtuelle Java JVMC et un outil informatique 0I implémentés dans la carte à puce CP pour installer les deuxièmes parties APC des applications AP à 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 mobile TM et la carte à puce CP 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 transmises depuis le terminal mobile TM à la carte à puce CP et des réponses transmises depuis la carte à puce CP au terminal mobile TM. Selon ce protocole, parfois désigné par SIM Application Toolkit (SAT) selon la norme 3GPP TS 51.014 ou ETSI 102.223, les commandes sont toujours déclenchées à l'initiative du terminal mobile et la carte à puce est pro-active afin d'initier des actions mais encore sous la commande du terminal mobile. 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 MT 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 MT 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 CP communique avec le "monde extérieur" via le terminal mobile TM, 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 CP comprend classiquement sous forme intégrée un ou plusieurs microprocesseurs PC, une mémoire non réinscriptible M1 du type ROM ou Flash, une mémoire non volatile M2 du type EEPROM ou Flash et une mémoire M3 du type RAM ou SRAM destinée essentiellement à échanger des commandes, ou requêtes, et réponses avec le terminal mobile TM à travers le port d'entrée/sortie PES et le lecteur LT. Les différents éléments de la carte sont reliés entre eux par un bus bidirectionnel BC. Les mémoires M1 et M2 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. Les mémoires M1 et/ou M2 contiennent des applications, comme l'application SIM ou USIM, initialement installées lors de la fabrication de la carte et l'outil d'installation 0I. Les mémoires M1 et/ou M2 comportent é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 mobile TM et téléchargées par le chargeur CAPC coopérant avec l'outil d'installation 0I à travers le lecteur LT, le port PES et la mémoire RAM M3. Dans les mémoires M1 et/ou M2 est également mémorisée une application de contrôle AC communiquant avec les deuxièmes parties d'application APC via une interface appropriée. L'application de contrôle AC et les deuxièmes parties d'application APC constituent des applets STK (SIM ToolKit). Par ailleurs, l'algorithmique de l'application AC peut être implémenté directement dans le moteur SIM Toolkit. Dans les mémoires Ml et/ou M2 est mémorisée une liste LC de commandes proactives CP qui sont des commandes élaborées. Par exemple les commandes élaborées sont des commandes pro-actives connues entièrement de type IHM (Interface Homme-Machine) . 10 "Display Text" pour l'affichage de texte, "Get Inkey" pour la saisie d'un caractère, "Get Input" pour la saisie d'une chaîne de caractères, "Select Item" pour sélectionner une ligne dans un menu, ou "Set Up Menu" pour inclure une liste d'objets dans un menu affiché 15 par le terminal mobile. Selon d'autres exemples, les commandes pro-actives élaborées selon l'invention sont une éjection de carte dans le terminal, un affichage de séquence vidéo et une vibration du terminal. La liste de commandes LC contient en outre des commandes pro-actives qui contiennent chacune une partie de commande élaborée. Par exemple des commandes pro-actives partiellement élaborées sont: "Close Channel", "Get Service Information", "Launch 25 Browser", "Open Channel", "Play Tone", "Receive Data" "Run At Command" "Send Data" "Send DTMF" Send Short Message", Send SS, Send USSD, Set Up Call", ou "Service Search". Les parties de commande de type élaboré des commandes incluses dans la liste LC sont appelées commandes élaborées CE. Par conséquent, les commandes entièrement de type élaboré sont aussi des commandes élaborées CE. Toutes les autres commandes qui ne sont pas 35 incluses dans la liste LC et les parties de commande qui ne sont pas de type élaboré sont appelées commandes de service CS. Ainsi, chaque commande pro-active contenant une partie de commande de type élaboré regroupe une commande élaborée CE et une commande de service CS. Par exemple, la commande "Send Short Message" contient une commande élaborée CE pour afficher le signalement de l'envoi d'un message court et une commande de service CS pour envoyer le message court au réseau RR. En référence à la figure 2, le procédé d'exécution d'une commande élaborée CE selon une réalisation préférée de l'invention comprend des étapes El à E17. Lors d'une session par exemple du type SAT (SIM Application Toolkit), des commandes transmises par le terminal mobile TM à la carte à puce CP et des réponses transmises par la carte à puce CP au terminal mobile TM sont communiquées 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 mobile car la carte à puce bien que pro-active est esclave du terminal mobile. Initialement à une étape E0, après connexion de la carte à puce CP au terminal, la première partie d'application APT selon l'invention dans le terminal transmet la liste de commandes élaborées LC à la carte à puce dont la mémoire M2 la mémorise. La carte à puce CP a en outre mémorisé un indicateur de commande élaborée ICE à un premier état logique "0" et un indicateur de service IDS à un premier état logique "0" dans la mémoire M2 ou M3. En variante, un opérateur ayant remis la carte à puce à l'usager du terminal modifie la liste de commandes LC ou associe sélectivement un droit d'utilisation à des commandes élaborées de la liste de commandes LC, en fonction de l'évolution de l'abonnement de l'usager. Par exemple, si l'usager est en défaut de paiement d'abonnement relatif à des services, l'utilisation de commandes élaborées pour accéder aux dits services n'est pas autorisée. A l'étape El, l'usager du terminal mobile TM souhaitant accéder à un service délivré par la carte à puce CP sélectionne sur l'écran du terminal mobile TM un item correspondant audit service et associé à une commande pro-active CPA. Par exemple, une première partie d'application APT fournit une page de noms et/ou d'icones correspondant à des services et commande l'affichage de cette page sur l'écran du terminal TM. L'usager du terminal sélectionne alors un item comme le nom ou l'icone d'un service, afin d'initier une session entre la première partie APT d'une application mettant en oeuvre particulièrement l'invention dans le terminal et l'application de contrôle AC dans la carte à puce. La sélection de l'usager conduit à une action nécessitant une réponse incluant une commande pro- active. Par exemple, l'action est relative à l'obtention (SELECT ITEM) d'une page dans un sous-menu correspondant. Selon un autre exemple, l'action est relative à une communication avec une entité M, T, S extérieure au terminal TM, qui recourt à l'interface de communication IC, l'action correspondant à 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). A l'étape E2, au début de ladite session, la première partie d'application APT requiert une ouverture de session à l'interface d'accès IA qui établit une commande pour transmettre un identificateur de commande IDC à l'application de contrôle AC, l'identificateur de commande IDC étant associé à la commande pro-active CPA sélectionnée. A l'étape E3, l'application de contrôle AC mémorise l'identificateur de commande reçu IDC dans la mémoire M2 de la carte à puce CP. En outre, l'indicateur de service IDS est mis à un deuxième état logique "1". A l'étape E4, l'application de contrôle AC ne répond pas par une commande pro-active, mais l'application de contrôle AC s'enregistre dynamiquement dans une table d'événements incluse dans la carte afin d'être réveillée par une commande "status event" par exemple. L'application de contrôle AC bascule alors à un état de veille après l'avoir signalé par une réponse 'Ox 90 00' sans données à la première partie d'application APT qui termine ainsi momentanément la communication avec l'application de contrôle AC et se met en sommeil/attente. L'état de veille à l'étape E4 engendre dans la carte à puce CP un transfert de paramètres de l'action désignée par la première partie d'application APT pour les écrire dans un espace d'événement de la mémoire M2. Pendant les étapes El à E4, l'interface de communication IC interroge périodiquement la carte à puce CP. Ainsi à la suite de la réponse 'Ox 90 00', une commande d'événement "status event" est transmise à l'étape E5 par l'interface de communication IC à l'application de contrôle AC et interroge la carte à puce sur l'intention de celle-ci d'envoyer une commande pro-active. A l'étape E6, l'application de contrôle AC à l'état de veille est à l'écoute de toute demande d'événement et est réveillée par la commande d'événement "status event". L'application de contrôle AC lit l'indicateur de service IDS dans la mémoire M2. Si l'indicateur de service IDS est au deuxième état "1", l'application de contrôle AC transmet à la deuxième partie d'application APC une requête d'appel relative à la commande pro-active sélectionnée CPA associée à l'identificateur de commande IDC, et remet l'indicateur de service IDS est à l'état "0" à l'étape E7. Si l'indicateur de service IDS est au premier état "0", le procédé se termine, comme indiqué à une étape F, signifiant qu'aucun item associé à la commande pro-active CPA n'a été sélectionné dans le terminal mobile TM. En revenant à la réception de la requête d'appel à l'étape E7, la deuxième partie d'application APC vérifie si l'identificateur de commande IDC transmis à l'étape E2 est inclus dans la liste de commandes LC dans la mémoire M2, à l'étape E8. Si l'identificateur de commande IDC n'est pas inclus dans la liste de commandes LC, la deuxième partie d'application APC lit les paramètres de l'action mémorisés dans l'espace d'événement de la mémoire M2 de la carte à puce. La deuxième partie d'application APC établit alors une réponse avec la commande pro-active correspondant aux paramètres lus de l'action, la commande pro-active CPA étant une commande de service CS. Ladite réponse est transmise à l'interface de communication IC du terminal mobile TM, qui à l'étape E9 traite alors d'une manière classique la commande pro-active, par exemple en requérant l'établissement d'un appel auprès du réseau fixe du réseau RR. Si à l'étape E8 l'identificateur de commande IDC est inclus dans la liste de commandes LC, la deuxième partie d'application APC analyse la commande pro-active CPA associée à l'identificateur de commande IDC à l'étape E10. Dans le cas où la commande pro-active CPA ne contient qu'une partie de commande de type élaboré, la commande pro-active CPA est directement identifiée comme commande élaborée CE. Dans le cas où la commande proactive CPA contient une partie de commande de type élaboré et une commande de service CS, la deuxième partie d'application APC extrait la partie de commande de type élaboré de la commande pro-active CPA, c'est-à- dire la commande élaborée CE, afin d'identifier la commande pro-active CPA comme commande élaborée CE. La commande de service CS correspondant à l'autre partie de la commande pro-active CPA sera traitée ultérieurement, de manière similaire à l'étape E9. Selon la variante où l'opérateur associe de manière sélective un droit d'utilisation à des commandes élaborées, seules les commandes élaborées autorisées sont identifiées et les commandes non autorisées ne sont pas identifiées. A l'étape E11, la deuxième partie d'application APC lit les paramètres de l'action dans l'espace d'événement de la mémoire M2 de la carte à puce. La deuxième partie d'application APC établit alors une réponse avec la commande élaborée CE correspondant aux paramètres lus de l'action et transmet la commande élaborée CE à l'application de contrôle AC. La deuxième partie d'application APC efface dynamiquement son enregistrement relatif à l'événement "event status" dans la table d'événements. La deuxième partie d'application active APC est alors en attente d'un compte rendu de l'exécution de la commande élaborée CE par la première application de carte APT. A l'étape E12, l'application de contrôle AC mémorise la commande élaborée CE reçue dans un registre tampon de la mémoire M2. En outre, l'application de contrôle AC met l'indicateur de commande élaborée ICE à un deuxième état logique "1" dans la mémoire M2. A l'étape E13, la première partie d'application APT transmet une requête d'interrogation à l'application de contrôle AC afin de vérifier l'état de l'indicateur de commande élaborée ICE. Pendant les étapes E3 à E11, la première partie d'application APT interroge périodiquement l'application de contrôle AC en transmettant ladite requête d'interrogation, après avoir transmis l'identificateur de commande IDC à la carte à puce à l'étape E2. A l'étape E14, l'indicateur de commande élaborée ICE étant au deuxième état logique "1", l'application de contrôle AC forme une réponse incluant la commande élaborée CE et la transmet à la première partie d'application APT. En outre, l'indicateur de commande élaborée ICE est mis au premier état logique "0" dans la mémoire M2, pour indiquer que la commande élaborée CE a été transmise. A l'étape E15, la première partie d'application APT exécute la commande élaborée CE reçue en utilisant des ressources élaborées du terminal mobile TM. Par exemple, pour un service de météo, la première partie d'application APT affiche une image du soleil pour indiquer un temps ensoleillé. Selon un autre exemple, pour un envoi de message court, la première partie d'application APT affiche le signalement de l'envoi du message court, en introduisant une image animée. A l'étape E16, la première partie d'application APT établit le compte rendu CR de l'exécution de la commande élaborée CE et le transmet à la deuxième partie d'application APC. Le compte rendu CR fournit notamment des informations relatives au déroulement de l'exécution de la commande élaborée CE. A l'étape E17, la deuxième partie d'application APC analyse le compte rendu reçu CR afin de continuer le traitement du service demandé par l'usager du terminal mobile TM. Par exemple, en réponse au compte rendu CR, la deuxième partie d'application APC exécute la commande de service CS incluse dans la commande pro-active dont la partie de commande élaborée vient d'être exécutée. Selon l'exemple précité de l'envoi de message court, la deuxième partie d'application APC transmet la commande de service CS extraite de la commande pro-active précédemment reçue CPA à l'interface de communication IC afin que le terminal transmette le message court au réseau RR, comme à l'étape E9. L'invention décrite ici concerne un procédé et un dispositif pour exécuter une commande élaborée CE par une première partie APT d'une application AP installée dans un terminal mobile TM, ladite commande élaborée étantrelative à une deuxième partie APC de l'application installée dans une carte à puce CP communiquant avec le terminal. Selon une implémentation préférée, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans le dispositif et en particulier pour partie dans la carte à puce et pour partie dans le terminal. Le programme comporte des instructions de programme qui, lorsque ledit programme est chargé et exécuté dans le dispositif dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes du procédé selon l'invention. En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur sur ou dans un support d'informations, adapté à mettre en oeuvre l'invention. REVENDICATIONS 1 - Procédé pour exécuter une commande élaborée (CE) par une première partie (APT) d'une application (AP) installée dans un terminal (TM), ladite commande élaborée étant relative à une deuxième partie (APC) de l'application installée dans une carte à puce (CP) communiquant avec le terminal, et un identificateur de commande (IDC) associé à une commande pro-active (CPA) étant transmis (E2) par la première partie d'application (APT) à la carte à puce, caractérisé en ce qu'il comprend les étapes de: dans la carte à puce, si l'identificateur de commande transmis (IDC) est inclus (E8) dans une liste de commandes (LC), identifier (ElO) la commande pro-active (CPA) comme une commande élaborée (CE) par la deuxième partie d'application (APC) en réponse à une commande d'événement (E5) et mémoriser (E12) la commande élaborée (CE), dans la carte à puce, en réponse à une requête d'interrogation transmise (E13) par la première partie d'application (APT), transmettre (E14) par une application de contrôle (AC) la commande élaborée mémorisée (CE) à la première partie d'application (APT) du terminal, et dans le terminal, exécuter (E15) la commande élaborée reçue (CE) par la première partie d'application (APT) en utilisant des ressources élaborées du terminal. 2 - Procédé conforme à la revendication 1, comprenant en outre une transmission (EO) de la liste de commandes (LC) par le terminal (TM) à la carte à puce (CP). 3 - Procédé conforme à la revendication 1 ou 2, comprenant en outre dans la carte à puce (CP) les étapes de: mémoriser (EO) un indicateur de commande élaborée (ICE) à un premier état, et après la mémorisation de la commande élaborée (CE), mettre (E12) l'indicateur de commande élaborée (ICE) à un deuxième état afin de transmettre la commande élaborée (CE) au terminal (TM). 4 - Procédé conforme à l'une quelconque des revendications 1 à 3, comprenant en outre dans le terminal (TM) une étape de transmettre (E16) à la carte à puce (CP) un compte rendu (CR) relatif à l'exécution de la commande élaborée (CE). - Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel la commande pro-active (CPA) comprend une commande élaborée (CE) et une commande de service (CS), et la deuxième partie d'application (APC) analyse la commande pro-active (CPA) pour en extraire la commande élaborée (CE) afin d'identifier (ElO) la commande pro-active comme commande élaborée. 6 - Procédé conforme à la revendication 5, selon lequel la deuxième partie d'application (APC) transmet la commande de service (CS) extraite de la commande pro-active (CPA) au terminal. 7 - Procédé conforme à l'une quelconque des revendications 1 à 6, comprenant une autorisation sélective d'au moins une commande élaborée afin de n'identifier aucune commande élaborée n'ayant pas été autorisée. 8 - Dispositif pour exécuter une commande élaborée (CE) par une première partie (APT) d'une application (AP) installée dans un terminal (TM), ladite commande élaborée étant relative à une deuxième partie (APC) de l'application installée dans une carte à puce (CP) communiquant avec le terminal, la première partie d'application (APT) transmettant un identificateur de commande (IDC) associé à une commande pro-active (CPA) à la carte à puce, caractérisé en ce qu'il comprend: un moyen (APC) dans la carte à puce pour identifier la commande pro-active (CPA) comme une commande élaborée (CE) en réponse à une commande d'événement et mémoriser la commande élaborée (CE), si l'identificateur de commande (IDC) transmis est inclus dans une liste de commandes (LC), un moyen (AC) dans la carte à puce pour transmettre la commande élaborée mémorisée (CE) à la première partie d'application (APT) du terminal (TM), en réponse à une requête d'interrogation transmise par la première partie d'application (APT), et un moyen (APT) dans le terminal pour exécuter la commande élaborée reçue (CE) en utilisant des ressources élaborées du terminal. 9 - Carte à puce (CP) pour exécuter une commande élaborée (CE) par une première partie (APT) d'une application (AP) installée dans un terminal (TM) communiquant avec la carte à puce, ladite commande élaborée étant relative à une deuxième partie (APC) de l'application installée dans la carte à puce, la première partie d'application (APT) transmettant un identificateur de commande (IDC) associé à une commande pro-active (CPA) à la carte à puce, caractérisée en ce qu'elle comprend: un moyen (APC) pour identifier la commande pro-active (CPA) comme une commande élaborée (CE) en réponse à une commande d'événement et mémoriser la commande élaborée (CE), si l'identificateur de commande (IDC) transmis est inclus dans une liste de commandes (LC), et un moyen (AC) pour transmettre la commande élaborée mémorisée (CE) à la première partie d'application (APT) du terminal, en réponse à une requête d'interrogation transmise par la première partie d'application (APT), afin que la première partie d'application (APT) exécute la commande élaborée reçue (CE) en utilisant des ressources élaborées du terminal. - Programme d'ordinateur apte à être mis en oeuvre dans un dispositif pour exécuter une commande élaborée (CE) par une première partie (APT) d'une application (AP) installée dans un terminal (TM), ladite commande élaborée étant relative à une deuxième partie (APC) de l'application installée dans une carte à puce (CP) communiquant avec le terminal, et un identificateur de commande (IDC) associé à une commande pro-active (CPA) étant transmis (E2) par la première partie d'application (APT) à la carte à puce (CP), caractérisé en ce qu'il comprend des instructions qui, lorsque le programme est chargé et exécuté dans ledit dispositif, réalisent en outre les étapes de: si l'identificateur de commande (IDC) transmis est inclus dans une liste de commandes (LC), identifier (E10) la commande pro-active (CPA) comme une commande élaborée (CE) par la deuxième partie d'application (APC) en réponse à une commande d'événement et mémoriser (E12) la commande élaborée (CE), en réponse à une requête d'interrogation transmise par la première partie d'application (APT), transmettre (E14) par une application de contrôle (AC) la commande élaborée mémorisée (CE) à la première partie d'application (APT) du terminal (TM), et exécuter (E15) la commande élaborée reçue (CE) par la première partie d'application (APT) en utilisant des ressources élaborées du terminal (TM).