Brevet FR2852118A1 — publié le 20040910

L'invention concerne un procédé de gestion du déclenchement d'une application dans un terminal de service et notamment dans terminal de télécommunication tel qu'un téléphone mobile. L'invention s'applique à tout terminal et aux cartes à puces susceptibles de déclencher une application ou d'exécuter une application sur l'arrivée d'un événement de déclenchement. L'invention s'applique également aux applications comprenant des règles de déclenchement en fonction de l'arrivée d'au moins un événement prédéfini. Dans le contexte d'un terminal de télécommunication de type téléphone mobile, on entend par arrivée d'un événement de déclenchement d'une application, par exemple l'arrivée d'un message court (SMS) ou le début d'un appel effectué sur le téléphone mobile par l'utilisateur. L'invention s'applique dès lors que des applications, pour des raisons historiques sont liées à des événements de déclenchement si bien que leur déclenchement est lié à l'arrivé d'un événement de déclenchement, lorsque le terminal doit être capable de fonctionner avec des environnements réseaux différents, autrement dit dans un contexte multi-technologie d'accès réseau. En effet, il existe aujourd'hui en particulier dans les télécommunications une concurrence entre plusieurs technologies supportées par les différents opérateurs. De façon pratique chaque opérateur de réseau téléphonique propose une ou plusieurs technologie d'accès réseau et des programmes applicatifs ci-après dénommés applications, compatibles avec la technologie d'accès réseau de l'opérateur à savoir GSM, UMTS, CDMA, IDEN, ANSI-136, etc. On recherche aujourd'hui des solutions permettant des accès multi-technologie c'est-à-dire des solutions qui permettent qu'un terminal de service et en particulier un téléphone mobile défini selon des normes et technologies spécifiques puisse fonctionner dans un contexte multi technologies. La présente invention se situe précisément dans le contexte d'accès réseau multi technologies. La présente invention permet en effet, à un téléphone mobile défini selon des normes et technologies spécifiques de fonctionner dans un contexte d'accès réseau multi technologies. Plus précisément avec la solution proposée par la présente invention, une application définie par exemple selon la norme GSM et incompatible avec l'accès UMTS, n'entraînera pas un disfonctionnement du téléphone en étant déclenchée. La présente invention a plus particulièrement pour objet un procédé de gestion du déclenchement d'une application dans un terminal placé dans un environnement composé de plusieurs technologies d'accès, caractérisé en ce qu'il comprend : - à l'arrivée d'un événement de déclenchement d'une application, - la mise en #uvre d'un mécanisme de test de l'application à partir d'informations contenues dans l'application testée, permettant de connaître ou de déduire la ou les technologies d'accès réseau supportées par l'application. Selon un mode de réalisation, le mécanisme de test est dans le système d'exploitation du terminal et sa mise en #uvre comprend : - la vérification par le terminal : - d'informations concernant la ou des technologies d'accès réseau courantes, - d'informations contenues dans l'application lui permettant de connaître ou de déduire la ou les technologies supportées par l'application, - le déclenchement de l'application uniquement dans le cas où ces informations sont compatibles. Selon un autre mode de réalisation, le mécanisme de test est dans l'application, et sa mise en #uvre comprend : - la vérification par le terminal : - d'informations concernant la ou des technologies d'accès réseau courantes, - d'informations contenues dans l'application lui permettant de connaître ou de déduire la ou les technologies supportées par l'application, - la poursuite de l'exécution de l'application uniquement dans le cas où ces informations sont compatibles. Selon une autre caractéristique, les informations contenues dans l'application comportent des paramètres de déclenchement à partir de différents modes de fonctionnement de l'application déclarés, permettant de déterminer les aptitudes de l'application c'est-à-dire la ou les technologies d'accès réseau supportés par l'application. Avantageusement, le mécanisme comporte quatre modes de fonctionnement dont l'un est basé sur des caractéristiques de l'application, l'autre sur l'identification de l'application et le troisième sur des attributs de l'application, un quatrième mode est pris par défaut lorsque aucun des trois autres modes n'est déclaré. Plusieurs modes de fonctionnement peuvent être déclarés pour une même application. Le mode par défaut correspond au cas où l'application est indifférente à la technologie d'accès réseau. Selon une autre caractéristique, le mécanisme utilise des commandes prévues pour lui permettre d'installer une nouvelle application contenant les informations permettant de connaître ou de déduire la ou les technologies supportées par ladite application ou de mettre à jour ces informations ou de lire ces informations. Un autre objet de la présente invention concerne un terminal de service comprenant des moyens de mémorisation de programme pour mémoriser un programme correspondant au système d'exploitation et une ou plusieurs applications, principalement caractérisée en ce qu'il comporte en outre des moyens de mise en #uvre d'un mécanisme de test d'au moins une application à partir d'informations contenues dans l'application testée, ces informations permettant au système d'exploitation de connaître ou de déduire la ou les technologies d'accès réseau supportées par l'application testée et de vérifier sa compatibilité avec l'accès réseau courant utilisé par le terminal. Selon une application particulière, le terminal est un terminal de télécommunication du type téléphone mobile équipé d'une carte à puce et il est apte à fonctionner avec un environnement d'accès réseau multi technologie. La ou les application(s) testée(s) et le mécanisme de test sont placés dans la carte à puce du terminal. Un autre objet de l'invention concerne une carte à puce de terminal de télécommunication principalement caractérisée en ce qu'elle comporte des moyens de mise en #uvre d'un mécanisme de test d'au moins une application qui, à partir d'informations contenues dans l'application testée, permet au système d'exploitation de la carte de connaître ou de déduire la ou les technologies d'accès réseau supportées par l'application testée et de vérifier sa compatibilité avec l'accès réseau courant utilisé par le terminal. Le mécanisme de test est un programme chargé dans une mémoire de programme non volatile de la carte, appelé par le système d'exploitation de la carte à puce ou intégré dans ledit système. Un autre objet de l'invention concerne également toute application susceptible d'être exécutée par un terminal de service ou une carte à puce équipant ce terminal placé dans un environnement composé de plusieurs technologies d'accès réseau dés lors quelle comprend des règles de déclenchement en fonction de l'arrivée d'au moins un événement prédéfini et dès lors qu'elle comporte en outre des informations permettant de connaître ou de déduire la ou les technologies d'accès réseau qu'elle supporte. Selon un mode de réalisation, l'application peut comporter également un mécanisme de test qui va lui permettre, à partir des informations quelle contient, de connaître ou de déduire elle même la ou les technologies d'accès réseau supportées. D'autres particularités et avantages de l'invention apparaîtront clairement à la lecture de la description qui est donnée ci-après à titre d'exemple non limitatif et en regard des dessins annexés sur lesquels: - la figure 1, représente un diagramme fonctionnel d'un mécanisme permettant la mise en #uvre du procédé selon l'invention, - la figure 2, représente schématiquement une carte à puce apte à mettre en #uvre le procédé selon l'invention. La description qui va suivre concerne plus particulièrement l'application de l'invention à un terminal de télécommunication tel qu'un téléphone mobile. Dans une telle application, les applications testées et le mécanisme de test sont dans la carte à puce associée au téléphone mobile. Pour cela, selon le procédé, on prévoit que toute application installée dans une carte à puce de téléphone mobile comprenne une information qui permet à la carte à puce de savoir directement à partir de cette information ou de déduire de cette information quelle est, ou quelles sont les technologies d'accès supportées par l'application. Dans l'exemple qui va être décrit, il est prévu que l'information se présente sous la forme d'une donnée comportant plusieurs octets dont un octet permet de paramétrer le ou les modes de fonctionnement de l'application. Ainsi, le système d'exploitation de la carte peut, connaissant le (ou les ) mode(s) de fonctionnement de l'application, connaître ou déduire les aptitudes de l'application à supporter l'une ou l'autre des technologies d'accès existantes. Un ou plusieurs autres octets permettent de déclarer les technologies existantes susceptibles d'être supportées par l'application et un ou plusieurs autres octets sont prévus pour définir des technologies futures susceptibles d'être supportées par cette application. En allant lire les informations contenues dans un champ réservé de l'application, la carte est renseignée sur les possibilités de cette application et va pouvoir avec le mécanise prévu qui peut être intégré dans son système d'exploitation, prendre la décision ou non d'activer une application. La carte va prendre ou non la décision de déclencher l'application si la technologie courante (technologie utilisée par la carte) est compatible avec l'information contenue dans l'application. Pour cela, le système d'exploitation de la carte et plus précisément la partie dédiée toolkit framework au traitement des commandes toolkit va mettre en #uvre le mécanisme de test illustré par le schéma de la figure 1, lors de l'arrivée d'un événement de déclenchement d'une application. Pour connaître la technologie courante, il existe trois solutions possibles à savoir : - Une commande Terminal Profile qui décrit les capacités du téléphone mobile, - Une commande Provide Local Information envoyée par la carte au téléphone mobile puis au réseau, - Le système d'exploitation de la carte possède implicitement l'information. Il est dans ce cas capable de mettre en #uvre un processus pour que la carte reçoive du réseau l'information. Dans l'exemple donné, la carte déduit la technologie d'accès réseau supportée par une application à partir des paramètres de déclenchement contenus dans l'application, ces paramètres permettant de déclarer de 1 à 3 modes de fonctionnement pour une application, et un quatrième mode étant pris par défaut lorsque aucun des trois autres n'est déclaré. Le test comporte dans l'exemple une succession de test des trois modes déclarés, chaque mode pris individuellement ne permettant pas obligatoirement de donner une réponse complète sur la technologie supportée par l'application. Les modes déclarés sont les suivants : Le mode 0 : C'est le mode qui est pris par défaut par le système d'exploitation de la carte lorsque aucun mode n'est déclaré dans l'application. Aucun mode n'est déclaré lorsque les champs d'enregistrement des paramètres de mode sont vides. Le mode 0 signifie que l'application est indépendante des technologies d'accès réseau et qu'elle peut être activée sous n'importe laquelle des technologies réseau. Le mode 1 : Ce mode est utilisé lorsque le paramètre mode 1 est déclaré dans le champ prévu de l'application. Ce mode signifie que le système d'exploitation est capable de déduire les aptitudes de l'application à partir de la hiérarchie d'héritage, des classes dérivées et des interfaces implémentées. Il s'agit typiquement d'une application Java. Dans le cas d'une application Java, l'application est étendue à partir de classes ou implémente une interface déterminée. L'environnement d'exécution de Java est capable de savoir qui sont ces classes et l'interface et ainsi de savoir quelles sont les aptitudes dont l'application a hérité car les classes et l'interface impliquées sont habituellement standard et connues. Grâce à cela il est possible pour la carte (le système d'exploitation) de déterminer si l'application supporte ou non une technologie d'accès particulière. Le mode 2 : Ce mode est utilisé lorsque le paramètre de mode 2 est déclaré dans le champ prévu de l'application. Ce paramètre indique que le système d'exploitation est capable de déduire les aptitudes de l'application au moyen de son identification (son nom) ou autres éléments qui lui permettent d'être reconnue. L'application possède un code d'identification (Application Identifier : AID), en général de 1 à 16 octets, qui permet de l'identifier de façon unique sur une carte. Ce code d'identification (ou nom) peut contenir une information sur sa présentation (package), les classes ou associations. A partir de ces informations il est possible au système d'exploitation de déduire les aptitudes de l'application à supporter ou nom l'une ou l'autre des technologies d'accès réseau. Le mode 3 : Ce mode est utilisé lorsque le paramètre 3 est déclaré dans le champ prévu de l'application. Ce mode signifie que le système d'exploitation de la carte est capable de déduire les aptitudes de l'application à partir d'attributs quelle contient ou qui lui sont associés. Certains attributs peuvent codés en dur dans les classes, assignés pendant une extentiation ou associés à l'application durant son installation. A partir de ces éléments le système d'exploitation peut déduire les aptitudes de l'application à supporter une technologie d'accès réseau ou non. Ainsi, par exemple, lorsqu'une application est installée, certains paramètres d'installation sont fournis pour identifier les technologies d'accès que l'application peut supporter, ces paramètres sont stockés sur la carte et associé à l'application. Lorsqu'un événement de déclenchement survient, le système d'exploitation de la carte récupère les paramètres et détermine si l'application peut supporter ou non la technologie d'accès de la carte (accès courant). Si la technologie supportée par l'application est compatible avec la technologie courante de la carte alors la carte déclenche l'application, sinon la carte ne déclenche pas l'application. Les tableaux qui suivent sont donnés à titre d'exemple. Ils représentent une illustration de l'information contenue dans une application pour permettre comme on l'a vu de connaître ou de déduire la ou les technologies d'accès réseau supportées par l'application. Cette information se présente dans l'exemple sous la forme de 6 octets comme détaillé ci-dessous : Octet (byte): b8 b7 b6 b5 b4 b3 b2 b1 Mode 1 Mode 2 Mode 3 RFU Application supporte GSMCaractéristiques dépendant du réseau) Application supporte UMTSCaractéristiques dépendant du) réseau Application supporte cdmaOne- (Caractéristiques dépendant du réseau) Application supporte cdma2000- (Caractéristiques dépendant du réseau) Octet 2: b8 b7 b6 I b5 I b4 I b3 I b2 I bl Application supporte GAIT- (Caractéristiques dependant du) Application supporte iDEN- (Caractéristiques dépendant du ) RFU RFU RFU RFU RFU RFU Octet 3: b8 b7 b6 b5 b4 b3 b2 b1 RFU RFU RFU RFU RFU RFU RFU RFU Octet 4: b8 b7 b6 b5 b4 b3 b2 b1 RFU #RFU RFU RFU RFU RFU RFU RFU Le tableau suivant illustre un exemple d'information déclarée dans une application et sa signification. Les données sont en hexadécimal. Activation selective Description de mode Octet 1 Octet 2 Octet 3 Octet 4 'Olh' 'XXh' 'XXh' 'XXh' L'application utilise Mode 1, ces aptitudes peuvent être déduites de ces héritages. '02h' 'XXh' 'XXh' 'XXh' L'application utilise Mode 2, ces aptitudes peuvent être déduites à partir de son identification. '14h' '00h' '00h' 'OOh' L'application utilise Mode 3 pour indiquer qu'elle ne supporte que l'accès GSM. '34h' '00h' 'OOh' 'OOh' L'application utilise Mode 3 pour indiquer qu'elle supporte l'accès GSM et UMTS L'application utilise Mode 3 pour '85h' 'OOh' '00h' 'OOh' indiquer qu'elle supporte CDMA2000, et Mode 1 est utilise en même temps pour indiquer ses aptitudes dans ce contexte. On va maintenant décrire le procédé mis en #uvre par le mécanisme illustré par le diagramme fonctionnel de la figure 1. Les étapes y sont référencées de 1 à 11. A l'arrivée d'un événement d'activation 1, le système d'exploitation identifie l'application concernée 2, et vérifie si cette application est dans la carte 3. Si l'application n'est pas dans la carte le mécanisme prend fin 4. Lorsque l'application est dans la carte, le système d'exploitation vérifie si le mode 1 est déclaré 5. Si ce mode est déclaré, le système d'exploitation déduit quel est l'accès réseau supporté par l'application et si cet accès est compatible avec l'accès courant 6. S'il y a incompatibilité, le mécanisme prend fin et attend un nouvel événement d'activation pour une application. Dans le cas où il y a compatibilité 6 ou dans le cas où le mode 1 n'est pas déclaré, le système d'exploitation vérifie si le mode 2 est déclaré 7. Si c'est le cas, le système d'exploitation déduit quel est l'accès réseau supporté par l'application et si cet accès est compatible avec l'accès courant 8. S'il y a incompatibilité, le mécanisme prend fin et attend un nouvel événement d'activation pour une application. Dans le cas où il y a compatibilité 8 ou dans le cas où le mode 2 n'est pas déclaré, le système d'exploitation vérifie si le mode 3 est déclaré 9. Si ce mode est déclaré, le système d'exploitation déduit quel est l'accès réseau supporté par l'application et si cet accès est compatible avec l'accès courant 10. S'il y a incompatibilité, le mécanisme prend fin et attend un nouvel événement d'activation pour une application. Dans le cas où il y a compatibilité 10 ou dans le cas où le mode 3 n'est pas déclaré, le système d'exploitation active l'application 11. En effet, comme on l'a vu précédemment, si aucun des modes n'est déclaré cela signifie que l'application est indépendante de la technologie d'accès réseau le mode 0 par défaut est appliqué. Il est prévu en outre avec ce mécanisme, l'utilisation de plusieurs commandes. Une première commande permet d'installer une nouvelle application sur une carte. Cette commande comporte tous les paramètres que l'on vient de décrire et est envoyée avec l'application nouvelle à charger dans la carte. Cette commande est dénommée INSTALL et sa structure de donnée est donnée en annexe 1 de la description. Cette commande INSTALL est donc envoyée à la carte avec l'application à travers une liaison Hertzienne sous la forme d'un message SMS par exemple. Dans l'exemple donné la commande comporte cinq octets d'en-tête, qui permettent de spécifier la nature de ladite commande et de 0 à 255 octets de données. La structure de donnée illustrée en annexe montre que le premier octet de donnée spécifie la longueur de l'application AID (Application Identifier) du fichier de chargement load file , les X octets suivants spécifient la valeur de cet AID, l'octet X+2 spécifie la longueur de l'AID de la classe application, les octets suivants la valeur de cet AID, etc. Une deuxième commande est prévue, il s'agit de la commande PUT DATA . Cette commande permet au système d'exploitation de la carte, de pouvoir effectuer une mise à jour des paramètres de déclenchement d'une application après son installation. Cette commande est détaillée en annexe 2 de la description. Une troisième commande est prévue, il s'agit de la commande GET DATA . Cette commande permet de lire les paramètres de déclenchement de l'application. Cette commande est détaillée en annexe de la description. Une quatrième commande peut être prévue, il s'agit de la commande GET STATUS pour permettre de retrouver les paramètres de déclenchement d'une application. Un exemple de réponse en retour de cette commande est illustré en annexe à la description. La figure 2 illustre de façon schématique et simplifiée, une mémoire MEM d'une carte à puce C. Cette mémoire représente la ou les mémoires de programme d'une carte à puce de téléphonie mobile. La mémoire illustrée MEM contient des programmes tels que le système d'exploitation de la carte à puce et au moins un programme d'application A. Selon l'invention le programme du système d'exploitation OS de la carte comporte ou fait appel au mécanisme M illustré par la figure 1. L'application A chargée dans la carte comporte quant à elle les informations c'est-à-dire les paramètres de déclenchement précédemment décrits qui permettent à la carte de savoir ou de déduire quelles sont les technologies d'accès réseau, supportées par l'application. Dans une variante d'exécution, le mécanisme de test peut être implanté au sein même de l'application. Dans ce cas l'application est déclenchée et au début de son exécution le test est mis en #uvre. Si le test révèle que l'application est compatible avec l'accès courant alors l'exécution se poursuit sinon l'exécution est arrêtée. ANNEXE 1 Structure de données de la commande INSTALL M/O 1 longueur DESCRIPTION (1) M 1 Longueur AID fichier Chargement M 5 à 16 Champ AID fichier Chargement M 1 Longueur AID Classe application M 5 à 16 AID Classe application M 1 Longueur AID Instance M 5 à 16 Champ AID Instance O 1 Longueur AID Privilege O 0 à 1 Champ Privilege M 1 Longueur AID Paramètres Installation O 14 Paramètres Installation au format TLV : :~~~~~~~~~~~~~~~~~~~~~~~ M/O @Longeur DESCRIPTION O 1 Indicateur du Système champ paramètres spécifiques (= EFh) O 1 Paramètres spécifiques Système AID longueur O #10 Paramètres spécifiques champ au format TLV : M/O [Longueur DESCRIPTION O 1 Indicateur C8h O 1 Longueur prochain champ O 2 Installation taille mémoire non ~~~~~~ ~~~~~~ volatile 0 1 Indicateur C7h O 1 Longueur prochain champ O 2 Installation taille mémoire non ~~~~~~~ volatile O 1 Indicateur Cah O 1 Longueur du prochain champ O 0 or 6+2n Paramètres spécifiques ~~~~~ ~~~~~~~~~~~~ ~~~~~~ Application GSM O 1 Indicateur C9h O 1 Longueur du prochain champ O 0 to 32 Champ Application Paramètres spécifiques (non ~~~~~ formaté) O 1 IndicateurCBh O 1 Longueur du prochain champ : 4 ~~~ ~~~~~~~~ O 4 Paramètres selectifs de déclenchement M 1 Longueur du prochain champ (non vérifié) O 0 Reservé pour le champ "Install token" (delegation non supportée) ANNEXE 2 Commande "PUT DATA" {description- VALEUR CHAMP .yx.#?5r E,. ; ;- bzz, titeirt.w z; EEN i.,",,W',"H' =,a: ^"';#P:' "bzz CLA 80h or 84h INS Dah P1 DonnéeObject Indicateur Paramètre: '00h' P2 DonnéeObject Indicateur Paramètre: 'C2h' Lc Donnée Longueur plus Donnée Entrée "Token Length "(si présent) et longueur MAC (si présent) Champ Donnée, entrée Donnée "Token" (si présent), et MAC (si présent) Données Commande DATA pour TAG 0OC2h ',Longueur Description 1 '\Indicateur AID : '4Fh' @1 @AID longueur Donnée : '05h-10h' 5-16 @ AID Donnée Application: 'XX...' 1 'Indicateur Paramètre 'CBh' 1 @ Longueur Paramètres sélectifs de déclenchement : '04h' 4 ' ; Donnée Paramètres sélectifs de déclenchement : 'XXXXXXXX, Commande "GET DATA" CHAMP DESCRIPTION- VALEUR CLA 80h or 84h INS Cah P1 DonnéeObject Paramètre Indicateur: '00h' P2 DonnéeObject Paramètre Indicateur: 'C2h' Lc Longueur Donnée plus longueur MAC (si présent) Champ Donnée et MAC (si présent) Donnée Commande DATA pour TAG 0OCh2 @Longueur Description @1 IndicateurAID : '4Fh' 1 Longueur Donnée AID : '05h-10h' 5-16 Donnée AID Application 'XX...' 1 Indicateur Paramètres sélectifs de déclenchement : 'XX' (non analysé) 1 Longueur Paramètres sélectifs de déclenchement 'XX' (non analysé) 4 Donnée Paramètres sélectifs de déclenchement : 'XXXXXXXX' (non analysé) ANNEXE 3 Réponse DATA pour TAG 0OC2h. -Longueur Description 1 IndicateurAID : '4Fh' 1 Longueur Donnée AID : '05h-10h' 5-16 @Donnée AID Application : 'XX...' @1 Indicateur Paramètres sélectifs de déclenchement : 'CBh' 1 @Longeur Paramètres sélectifs de déclenchement : '04h' @4 '* Donnée Paramètres sélectifs de déclenchement : .:l ?0 "CC 0''1' kfi' 0 'XXXXXXXX' Commande "GET STATUS" Longueur Valeur Signification 1 'xx' Longueur de AID 1-n 'xxxx...' AID 1 'xx' Etat cycle de vie 1 'xx' Privilèges Ap lication 4 @'xxxxxxxx' Paramètres sélectifs de f . !-> ,"*l ' ~ , , - déclenchement REVENDICATIONS 1. Procédé de gestion du déclenchement d'une application dans un terminal placé dans un environnement composé de plusieurs technologies d'accès, caractérisé en ce qu'il comprend : - à l'arrivée d'un événement de déclenchement d'une application, - la mise en #uvre d'un mécanisme de test de l'application à partir d'informations contenues dans l'application testée, permettant de connaître ou de déduire la ou les technologies d'accès réseau supportées par l'application. 2. Procédé de gestion du déclenchement d'une application selon la revendication 1, caractérisé en ce que le mécanisme de test est dans le système d'exploitation du terminal et en ce que sa mise en #uvre comprend : - la vérification par le terminal : - d'informations concernant la ou des technologies d'accès réseau courante, - d'informations contenues dans l'application lui permettant de connaître ou de déduire la ou les technologies supportées par l'application, - le déclenchement de l'application uniquement dans le cas où ces informations sont compatibles. 3. Procédé de gestion du déclenchement d'une application, selon la revendication 1, caractérisé en ce que le mécanisme de test est dans l'application, et en ce que sa mise en #uvre comprend : - la vérification par le terminal : - d'informations concernant la ou des technologies d'accès réseau courante, - d'informations contenues dans l'application lui permettant de connaître ou de déduire la ou les technologies supportées par l'application, - la poursuite de l'exécution de l'application uniquement dans le cas où ces informations sont compatibles. 4. Procédé de gestion du déclenchement d'une application selon l'une quelconque des revendications précédentes, caractérisé en ce que les informations contenues dans l'application comportent des paramètres de déclenchement à partir de différents modes de fonctionnement de l'application déclarés, permettant de déterminer les aptitudes de l'application c'est-à-dire la ou les technologies d'accès réseau supportés par l'application. 5. Procédé de gestion du déclenchement d'une application, selon la revendication 4, caractérisé en ce que le mécanisme comporte quatre modes de fonctionnement dont l'un est basé sur des caractéristiques de l'application, l'autre sur l'identification de l'application et le troisième sur des attributs de l'application, un quatrième mode qui est pris par défaut lorsque aucun des trois autres modes n'est déclaré. 6. Procédé de gestion du déclenchement d'une application selon la revendication 5, caractérisé en ce que plusieurs modes de fonctionnement peuvent être déclarés pour une même application. 7. Procédé de gestion du déclenchement d'une application, selon la revendication 5 ou 6, caractérisé en ce que le mode par défaut correspond au cas où l'application est indifférente à la technologie d'accès réseau. 8. Procédé de gestion du déclenchement d'une application selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il utilise en outre des commandes prévues pour permettre à ce mécanisme d'installer une nouvelle application contenant les informations permettant de connaître ou de déduire la ou les technologies supportées par ladite application, ou de mettre à jour ces informations ou de lire ces informations. 9. Terminal de service comprenant des moyens de mémorisation de programme pour mémoriser un programme correspondant au système d'exploitation et une ou plusieurs applications, caractérisée en ce qu'il comporte en outre des moyens de mise en #uvre d'un mécanisme de test d'au moins une application à partir d'informations contenues dans l'application testée, ces informations permettant au système d'exploitation de connaître ou de déduire la ou les technologies d'accès réseau supportées par l'application testée et de vérifier sa compatibilité avec l'accès réseau courant utilisé par le terminal. 10. Terminal de service selon la revendication 9, caractérisé en ce que ce terminal est un terminal de télécommunication du type téléphone mobile équipé d'une carte à puce et apte à fonctionner avec un environnement d'accès réseau multi technologie et caractérisé en ce que l'application testée et le mécanisme de test sont placés dans la carte à puce. 11. Carte à puce de terminal de télécommunication, caractérisée en ce qu'elle comporte des moyens de mise en #uvre d'un mécanisme de test d'au moins une application qui, à partir d'informations contenues dans l'application testée, permet au système d'exploitation de la carte de connaître ou de déduire la ou les technologies d'accès réseau supportées par l'application testée et de vérifier sa compatibilité avec l'accès réseau courant utilisé par le terminal. 12. Carte à puce de terminal de télécommunication selon la revendication 11, caractérisée en ce que le mécanisme de test est un programme chargé dans une mémoire de programme non volatile de la carte, appelé par le système d'exploitation de la carte à puce ou intégré dans ledit système. 13. Application susceptible d'être exécutée par un terminal de service ou une carte à puce équipant ce terminal placé dans un environnement composé de plusieurs technologies d'accès réseau, et comprenant des règles de déclenchement en fonction de l'arrivée d'au moins un événement prédéfini, caractérisée en ce qu'elle comporte en outre des informations permettant de connaître ou de déduire la ou les technologies d'accès réseau qu'elle supporte. 14. Application selon la revendication 13, caractérisée en ce qu'elle comporte en outre un mécanisme de test lui permettant, à partir des informations quelle contient, de connaître ou de déduire la ou les technologies d'accès réseau supportées.