FR2857193A1 - Procede permettant a une application embarquee sur un terminal de communiquer avec une application residente en carte sim - Google Patents

Abstract

Procédé de communication de données entre une application embarquée dans un terminal de communication et une application résidente dans une carte SIM, dans lequel il est tout d'abord procédé à l'ouverture d'un canal de communication entre le terminal de communication et la carte SIM, ensuite il est procédé au lancement d'une application résidente déterminée destinée à recevoir ou comportant les données à échanger, puis il est procédé à l'envoi par la carte SIM d'une commande SIM Application Toolkit « Get Input » à laquelle il est répondu par le terminal de communication par une autre commande SIM Application Toolkit « Terminal Response », et enfin une fois les données échangées en paramètres de ces commandes, il est procédé à une fermeture du canal de communication.

Description

2857193 i

Domaine de l'invention La présente invention se rapporte au domaine des terminaux mobiles de communication, téléphones portables ou PDA communicants, et elle concerne plus particulièrement un procédé pour assurer une communication bidirectionnelle entre une application embarquée sur ce terminal et une application localisée sur une carte SIM de ce terminal.

Art antérieur La carte SIM (Subscriber Identity Module) est indispensable au io fonctionnement d'un terminal mobile. Elle permet entre autre l'authentification de l'abonné sur le réseau de télécommunications, le chiffrement des échanges (vocaux ou de données) ainsi que la personnalisation du terminal mobile. Elle permet aussi l'accès à des services à valeur ajoutée lorsque ces services y sont implémentés sous la is forme de petits programmes applicatifs, appelés applets ou encore cardlets , tournant sur une machine virtuelle JAVATM. Le dialogue avec la carte SIM respecte alors le protocole connu sous l'appellation de SIM Toolkit.

Sur les terminaux les plus récents, les développeurs souhaitent pouvoir mettre en oeuvre des services de plus en plus sophistiqués et donc réaliser des applications utilisant à la fois les possibilités offertes par la carte SIM et celles offertes par le terminal mobile. Or, pour réaliser ces applications dites distribuées , il est nécessaire d'établir un lien logique entre le système d'exploitation (OS) du terminal et la carte SIM.

Or, Ce lien logique, c'est à dire la possibilité de faire communiquer une application située sur l'OS du terminal mobile avec une application située sur la carte SIM, n'est possible pratiquement qu'en recourant à un serveur applicatif distant au travers du réseau de télécommunications (par appel vocal, SMS, USDD). Il en résulte nécessairement une lenteur dans la communication, un coût pour cette communication, une utilisation et donc 2857193 2 une charge du serveur bien inutile et aussi une contrainte de disponibilité du réseau de télécommunications.

On connaît avec le brevet US2002/0199027, une solution pour établir un canal de communication entre une application du terminal et une application de la carte SIM. Toutefois, cette solution suppose une modification du système d'exploitation de la carte SIM et un détournement de la norme GSM11.11 qui annule l'intérêt du contrôle de cohérence assuré par cette norme.

io Objet et définition de l'invention La présente invention a pour objet de pallier ces inconvénients en proposant un procédé de dialogue direct bidirectionnel entre le terminal mobile et la carte SIM, donc sans passer par le réseau de télécommunications, et sans enfreindre les normes existantes.

Ce but est atteint par un procédé de communication de données entre une application embarquée dans un terminal de communication et une application résidente dans une carte SIM, dans lequel il est tout d'abord procédé à l'ouverture d'un canal de communication entre le terminal de communication et la carte SIM, ensuite il est procédé au lancement d'une application résidente déterminée destinée à recevoir ou comportant les données à échanger, puis il est procédé à l'envoi par la carte SIM d'une commande SIM Application Toolkit Get Input à laquelle il est répondu par le terminal de communication par une autre commande SIM Application Toolkit Terminal Response , et enfin une fois les données échangées en paramètres de ces commandes, il est procédé à une fermeture du canal de communication.

Ainsi, tout en respectant la norme GSM, il est établit très simplement une communication entre une application embarquée dans un terminal de communication et une application résidente dans une carte SIM, les données échangées entre ces applications transitant en parmètres dans la paire de commandes Get Input/Terminal Response.

L'ouverture d'un canal de communication comporte le transfert vers le terminal de communication d'une liste des applications résidentes disponibles dans la carte SIM. De préférence, le premier envoi de la commande Get Input est effectué sans passage de données et ladite fermeture de canal comporte l'envoi d'une commande Terminal Response sans passage de données si une commande Get Input est toujours en suspend.

Selon la couche transport mise en oeuvre, il peut être procédé à une conversion desdites données échangées.

io Pour procéder à un échange de données d'une longueur supérieure à une longueur déterminée (avantageusement 255 octets), il est procédé à plusieurs échanges successifs de paires de commande Get Input / Terminal Response portant à chaque échange sur une partie déterminée et différente desdites données.

is Selon l'invention, ledit échange de données est effectué au moyen des fonctions suivantes: une fonction d'ouverture du canal de communication (Openchannel), une fonction de lancement de l'application résidente choisie 20 (Runcardlet), une fonction d'envoi de données de l'application embarquée vers l'application résidente (Senddata), une fonction de réception dans l'application embarquée de données envoyées par l'application résidente (Receivedata), et 25. une fonction de fermeture du canal de communication (Closechannel).

De préférence, ledit terminal de communication peut être un téléphone mobile ou un assistant numérique personnel (PDA).

Brève description des dessins

Les caractéristiques et avantages de la présente invention ressortiront mieux de la description suivante, faite à titre indicatif et non limitatif, en regard des dessins annexés sur lesquels: - la figure 1 est une vue schématique de l'architecture matérielle d'un terminal de communication mettant en oeuvre le procédé de communication selon l'invention, - la figure 2 est une vue schématique de l'architecture logicielle d'un terminal de communication mettant en oeuvre le procédé de io communication selon l'invention, - les figures 3, 4, 5, 6 et 7 sont des diagrammes explicitant les principales fonctions du procédé de communication selon l'invention, mises en oeuvre dans le terminal, - la figure 8 est un diagramme illustrant un protocole de communiqcation 15 particulier mis en oeuvre avec le procédé de communication selon l'invention, et - les figures 9 et 10 sont des diagrammes explicitant les principales fonctions du procédé de communication selon l'invention, mises en oeuvre dans la carte SIM.

Description détaillée d'un mode de réalisation préférentiel La figure 1 illustre de façon simplifiée la structure matérielle d'un terminal de communication dans lequel est mis en oeuvre la présente invention. Ce terminal comporte classiquement des moyens de traitement de l'information de type microcontrôleur 10 auquel est reliée, de préférence par une liaison parallèle 12, une interface homme/machine 14 (clavier, écran, microphone et haut parleur du terminal par exemple). Ce microcontrôleur qui comporte classiquement un processeur de traitement 10A, une mémoire de programme 10B et une mémoire de données 10C, est relié par un lien série 16 à un module de radiocommunication sans fil 18 constituant le modem du terminal et donc apte à émettre et à recevoir 2857193 5 via une antenne 20 des messages radio vocaux ou de données en provenance d'autres terminaux ou stations de communication. Ce module de radiocommunication sans fil est lui même relié, par un ensemble de contacts électriques 22, à un module d'identification d'abonné ou carte s SIM 24. Cette carte SIM comporte classiquement des moyens de traitement 24A et des moyens mémoire de programme 24B et des moyens mémoire de données 24C.

L'architecture logicielle de ce terminal est illustrée à la figure 2. Le microcontrôleur intègre un système d'exploitation (OS terminal 30) et des io programmes applicatifs, par exemple au moins une application terminal 32. Le modem intègre également un système d'exploitation (OS modem 34). Enfin, la carte SIM comporte un système d'exploitation (OS carte 36) ainsi que des programmes applicatifs, par exemple au moins une application carte 38, dont une machine virtuelle JAVATM. Le transfert de ls données entre l'OS carte et l'OS modem s'effectue au moyen d'un jeu de commandes et de procédures appelé SIM Application Toolkit (que l'on nommera commandes SAT dans la suite de la description) qui permet à la carte SIM d'envoyer des commandes au module de radiocommunication et de recevoir des comptes rendus correspondants de façon à piloter l'interface homme/machine. Pour plus d'informations sur ces commandes on se reportera utilement à la norme GSM 11.14 de l'ETSI. Ainsi, la carte SIM peut notamment piloter l'affichage à l'écran d'un menu ou d'un texte déterminé, la saisie de données au clavier par l'utilisateur, l'envoi de messages courts, le lancement d'une tonalité, l'établissement d'un appel vocal, etc. Le transfert de données entre l'OS modem et l'OS terminal s'effectue quant à lui classiquement au travers de commandes AT. Pour plus d'informations sur ces commandes on se reportera utilement à la norme GSM 07.07. L'envoi de commande par l'OS terminal respecte la syntaxe AT+xxxx, la réponse venant de l'OS modem respectant pour sa part la syntaxe +yyyy. L'OS modem peut aussi envoyer certaines indications à l'OS terminal, indépendamment de toute commande. i0 15

2857193 6 Selon la présente invention, il est proposé de permettre à l'application 32 embarquée sur le terminal d'établir un canal de communication bidirectionnelle avec l'application 38 localisée sur la carte SIM. Pour cela, il est ajouté des modules logiciels complémentaires 40, 42 implémentés sous forme d'APIs logicielles (Application Program interface) à la fois dans le microcontrôleur 10 et dans la carte SIM 24 et un filtre logiciel 44 implémenté sur le seul microcontrôleur. Le premier module 40 résidant dans le terminal permet dans une phase d'initialisation, lorsque le filtre correspondant 42 est activé, de créer un canal de communication avec une application carte déterminée et le second module 44 résidant sur la carte SIM permet à l'application carte sélectionnée de dialoguer alors avec l'application terminal.

Le premier module logiciel comporte les quatre primitives ou fonctions différentes suivantes: OpenChannel() RunCardlet(cardletlD) (cardletlD) est fourni.

Envoie les données (request) passées en paramètre.

Copie les données entrantes dans le tampon (message) fourni.

Ferme le canal de communication.

1. La fonction OpenChannel() Cette fonction illustrée à la figure 3 est exécutée lors de la mise sous tension du modem et après validation du code d'identification personnel (PIN) de la carte SIM. Elle initialise un canal de communication vers le modem compatible SIM Toolkit, demande et analyse la liste des applications carte disponibles dans la carte SIM.

Pour ce faire, le modem envoie un ordre vers la carte SIM. Cet ordre est la commande SAT Terminal Profile . Cet ordre indique à la Ouvre un canal de communication.

Lance l'application carte dont l'identifiant SendDATA(request, length) ReceiveData(message, length) Close Channel() 2857193 7 carte SIM quelles sont les commandes pro-actives supportées par le terminal. A chaque ordre envoyé par le terminal à la carte SIM, celle-ci répond par deux octets appelés SW1 SW2. Puisque la carte ne peut envoyer par elle-même un ordre au terminal, elle utilise les octets de réponse SW1 SW2 pour indiquer au terminal qu'il y a une commande venant de la carte SIM en instance. Les valeurs prises par SW1 SW2 sont alors 91XX, XX indiquant la longueur des données que la carte SIM veut envoyer au terminal. Lorsque la commande a été correctement exécutée par la carte SIM, celle-ci normalement répond par l'indication 90 00.

io Dans ce cas présent, suite à l'envoi par le modem de la commande Terminal profile, et après présentation et validation du code PIN, la carte SIM répond par 91XX. Le modem va alors envoyer en retour la commande SAT Fetch avec l'indication de longueur XX, et la carte SIM répond par l'émission du message contenant la commande SAT pro-active Set-Up is menu . La commande Set-Up Menu envoyée par la carte SIM contient une liste d'items, chaque item étant identifié par un N d'ordre compris entre 1 et 255, et une chaîne de caractères ASCII constituant le descriptif de l'application. A la réception de ce message, le modem envoie une indication +STIN vers l'application terminal avec comme paramètre O. ce paramètre indique à l'application terminal qu'il y a une commande pro-active Set-up Menu qui est arrivée dans le modem. L'application terminal doit alors chercher le contenu de cette commande. Ceci est réalisé par la commande AT+ STGI=O (Sim Tool Kit Get Information) . Cette commande AT est générique et permet de rapatrier toute commande pro-active stockée temporairement dans le modem. AT+STGI contient un paramètre, qui est celui contenu dans l'indication précédente +STIN. Dans ce cas, ce paramètre est mis à 0, qui correspond à la commande Set-Up Menu. Le modem répond alors par une commande AT+STGI <menu infos> où menu- infos contient les informations décrivant les différentes applications cartes présentes dans la carte SIM. Chaque application carte est définie par son identifiant et son nom. Ces informations sont stockées dans le premier module logiciel qui les restituera à l'application terminal à sa demande.

2. RunCardlet(cardletlD) Cette fonction illustrée à la figure 4 qui intervient après l'ouverture du canal vers le modem par la fonction Open Channel() lance l'application carte dont l'identifiant est fourni par le paramètre cardletlD et exécute la sélection dans le menu principal. Pour ce faire, l'application terminal envoi au modem la commande AT+STGR ( Sim Toolkit Give Response) avec pour paramètres 0, 1, Y et 0 = Sélection d'un item dans le menu principal, io 1 = Sélection de l'item par l'utilisateur et Y = identifiant de l'application carte correspondant au paramètre passé cardletlD.

Ceci provoque l'envoi par le modem vers la carte SIM d'un ordre envelope contenant la commande SAT Menu Selection . Cet ordre va alors provoquer le déclenchement de l'application carte dont l'identifiant cardletlD a été passé dans le paramètre y. L'application carte utilisant le premier module logiciel API terminal va alors initier une commande proactive. Celle-ci est notifiée par la carte SIM au modem par le biais du message 91XX. Le modem indique à l'application terminal le bon déroulement du lancement de l'application carte puis retranscrit l'indication de commande proactive par un +STIN:3 pour l'application terminal.

L'application terminal et l'application carte sont alors à même de communiquer en détournant l'utilisation normale de la commande SAT Get Input et sa réponse. Cette commande a été initialement définie pour l'affichage d'un message sur l'écran du mobile, et elle demande la saisie par l'usager d'une suite de caractères. Une fois ces caractères saisis, ceux-ci sont renvoyés à la carte SIM. Avec l'invention, l'information, en provenance de la SIM, véhiculée à la place de l'invite de saisie du Get Input est traitée par l'application terminal et non affichée à l'écran. La réponse n'est pas tapée par l'utilisateur mais définie également par l'application terminal.

2857193 9 Le canal utilisé par l'application terminal et l'application carte peut être considéré comme half-duplex: au démarrage de l'application carte, c'est elle qui a la possibilité de communiquer puisqu'elle est en mesure d'envoyer des données par un Get Input alors que l'application terminal ne peut pas répondre à un Get Input qui n'a pas encore été envoyé. Or, il est naturel que l'application terminal soit la première à envoyer des données vers l'application carte (et non l'inverse) puisque étant celle qui est à l'initiative de l'utilisation du premier module logiciel. Donc, pour donner la possibilité à l'application terminal d'initier le dialogue, lo l'application carte au démarrage va envoyer systématiquement une commande Get Input sans information.

3. SendData(request, length) Cette fonction illustrée à la figure 5 répond au Get Input actuellement en attente. Pour ce faire, la réponse Terminal Response envoyée par le modem est déclenchée par la commande AT+ STGR (Sim Toolkit Give Response) venant de l'application terminal avec comme paramètres 3,1, <CR> ascii buffer <CZ> ce qui signifie: 3: Type de commande = Get Input 1: Transmission de la réponse donnée par l'utilisateur "ascii buffer" : buffer de données transmis de l'application terminal vers l'application carte. <CR> marque le début et <CZ> la fin du buffer de données.

La réponse de l'application terminal est traduite par le modem en Terminal Response pour la carte SIM. Celle-ci poursuit l'exécution de l'application carte qui était en attente sur cette commande proactive. L'application carte utilisant à nouveau le premier module logiciel, elle va provoquer une nouvelle utilisation de la commande Get Input. On notera l'utilisation particulière des données ascii buffer qui normalement correspondent à une réponse textuelle de l'utilisateur du terminal mais avec l'invention sont détournées pour permettre le dialogue direct avec l'application terminal.

2857193 i0 4. ReceiveData(message, length) Cette fonction illustrée à la figure 6 vérifie que la commande proactive courante correspond à un Get Input. Pour cela, l'application terminal envoi au modem la commande AT+STGI=3 (Sim Toolkit Give Information), le paramètre 3 de la commande +STGI permet de récupérer les données envoyées par la commande proactive Get Input. En réponse, le modem répond par l'indication +STGI:1,0,0,255,0, ascii buffer , ce qui signifie: io 1: Format = SMS Alphabet Default 0: Pas d'écho 0: Taille minimum pour la réponse de l'utilisateur 255: Taille maximum pour la réponse de l'utilisateur 0: Pas d'information d'aide.

is "ascii buffer " : buffer de données transmis de l'application carte vers l'application terminal Dans son utilisation détournée, cette commande permet la transmission par la carte SIM d'un message de longueur de 255 octets maximum. Cette commande pro-active provoque normalement l'affichage du message sur l'écran du mobile (question à laquelle l'utilisateur répond). Dans le cas de la présente réalisation, ce message n'est pas dirigé pour affichage, mais est dirigé vers l'application terminal de façon a permettre le dialogue direct.

5. CloseChannel() Cette fonction illustrée à la figure 7 est appelée par l'application terminal quand l'utilisation du premier module logiciel est terminée. Si un Get Input est actuellement en suspend, une réponse vide sera envoyée à la carte SIM.

Dans la description des fonctions représentées dans les diagrammes précédents, il est fait référence à la paire Get Input/ Terminal Response. Comme indiqué, le volume des données est limité à 255 octets pour chaque commande et chaque réponse. En réalité, ce volume est réduit de moitié, car une contrainte apparaît au niveau des commandes AT. Les données échangées par commande AT ne doivent pas contenir certains caractères du type: virgule, + , etc.. En outre, si la couche de transport ne permet pas de transfert en ascii, il peut être nécessaire d'effectuer une conversion des données. En hexadécimal, un octet prend les valeurs de 00 à FF. Le codage opéré est le suivant: 0 à F sont codés en ascii, c'est à dire de 30 en hexadécimal (pour 0) à 46 en hexadécimal (F). Ce codage conduit à une réduction par 2 du volume des données utiles transmises.

Puisque chaque paquet de données utiles transporté par Get Input ou Terminal Response n'est que de 127 octets, il est nécessaire de concevoir un protocole pour pouvoir transporter des messages de longueur supérieure à 127. A cet effet, la première trame envoyée se présente sous la forme ci-dessous (Paquet #1 avec encodage) : LG1 LG2 LG3 LG4 D1 D2 D3 D4 D5 D6.. . Dn LG=longueur des données contenues dans l'ensemble des paquets et Dl à Dn données à transférer Les paquets suivants qui transporteront le reste des données se 20 présenteront sous la forme ci-dessous Dn+1 Dn+2 ÉÉÉ Dm Dans le diagramme de la figure 8, l'envoi par l'application terminal vers la carte SIM contient 765 octets. Nous supposons que ces données ont subi préalablement le codage tel que spécifié précédemment. Puisque 25 le Terminal Response ne peut envoyer que 255 octets à la fois, le mécanisme suivant a été conçu par les inventeurs: Le premier Terminal Response contient dans le champ données la longueur du message qui sera envoyé, et le premier paquet de données (dont la longueur est notée 255 à laquelle il faut retrancher la longueur de l'en-tête). A la réception de ce paquet, le module logiciel 44 côté carte SIM analyse la longueur du message qu'il doit recevoir, puisque cette longueur (données utiles) correspond à l'envoi de 3 paquets de la part du terminal, et renvoie une commande pro-active Get Input avec un contenu de longueur nulle (car la carte SIM n'est pas en phase d'envoi de données) pour déclencher une seconde réponse du terminal (Terminal Response).

Dans l'exemple ci-dessus, une troisième phase Get Input /terminal Response est déclenchée. Ensuite, la carte ayant reçu le contenu du message (382 octets utiles), elle ne provoque pas l'envoi d'un nouveau Get Input. Le module logiciel 44 renvoie les 382 octets utiles reçus au module logiciel 38 par le biais du message noté "Receive data completed".

De son côté, le module logiciel 40 qui a terminé l'ensemble des envois nécessaires à la transmission des 382 octets renvoie un code de confirmation au module logiciel 32. Le module logiciel (44) côté carte SIM contrôle le volume des données reçues, et signale la présence d'un message reçu à l'application lorsque les échanges ont permis d'acheminer 1s tout le contenu du buffer passé par l'application terminal.

Le second module logiciel comporte deux primitives ou fonctions détaillées ci-dessous: 1. SendDataCardlet ()oxx, length) Cette fonction illustrée à la figure 9 envoi un Get Input, avec l'indication de la longueur du buffer à envoyer. Cette fonction déclenche donc le Get Input et envoie le contenu du buffer. La cinématique des échanges est la même que celle du ReceiveData côté terminal et ne sera donc pas décrite en détail.

2. ReceiveDataCardlet (yyyy, length) Cette fonction illustrée à la figure 10 traite les données reçues par le Terminal Response actuellement en attente. Les données lues sont copiées dans le buffer passé en paramètre. La cinématique des échanges est la même que celle du SendData côté terminal et ne sera donc pas décrite en détail.

Ces deux modules complémentaires ne sont activés que dans le cas où l'on souhaite établir le canal bidirectionnel entre les applications terminal et carte. Dans le cas contraire, le traitement des commandes est totalement transparent.

Les applications pouvant être construites autour de ce procédé sont très nombreuses: paiement, authentification, contrôle d'accès, validation de ticket, etc. On peut par exemple utiliser ce procédé pour réaliser une application distribuée de porte monnaie électronique (PME) sur téléphone mobile: É Application réalisant l'IHM du PME: affichage des logos, menus, demande de rechargement vers un serveur dans le réseau.

lo Application sécurisée de porte-monnaie dans la carte SIM implémentée sous forme d'application java et de fichier content le compteur de monnaie sécurisé.

On peut aussi utiliser ce procédé pour réaliser une application de billettique sur téléphone mobile avec le stockage sécurisé des tickets dans la carte SIM et le reste de l'application notamment l'IHM sur le terminal mobile.

L'invention s'appuie sur un ensemble de fonctions nouvelles qui permettent d'exporter certaines commandes proactives de la carte SIM Tool Kit: déclenchement d'une application carte par l'ordre envelope, - mécanisme d'échange basé sur la commande proactive Get Input et l'ordre Terminal Response envoyé par le mobile.

L'utilisation de ce mécanisme est permise par la disponibilité d'un ensemble de commandes AT qui permettent de véhiculer des commandes 25 proactives et les réponses correspondantes entre le modem et l'extérieur.

Claims (10)

REVENDICATIONS

1. Procédé de communication de données entre une application embarquée dans un terminal de communication et une application résidente dans une carte SIM, dans lequel il est tout d'abord procédé à l'ouverture d'un canal de communication entre le terminal de communication et la carte SIM, ensuite il est procédé au lancement d'une application résidente déterminée destinée à recevoir ou comportant les données à échanger, puis il est procédé à l'envoi par la carte SIM d'une commande SIM Application Toolkit Get Input à laquelle il est répondu par le terminal de communication par une autre commande SIM Application Toolkit Terminal Response , et enfin une fois les données échangées en paramètres de ces commandes, il est procédé à une fermeture du canal de communication.

2. Procédé selon la revendication 1, caractérisé en ce que ladite ouverture d'un canal de communication comporte le transfert vers le terminal de communication d'une liste des applications résidentes disponibles dans la carte SIM.

3. Procédé selon la revendication 1 ou la revendication 2, 20 caractérisé en ce que le premier envoi de la commande Get Input est effectué sans passage de données.

4. Procédé selon la revendication 1, caractérisé en ce que ladite fermeture de canal comporte l'envoi d'une commande Terminal Response sans passage de données si une commande Get Input est toujours en suspend.

5. Procédé selon la revendication 1, caractérisé en ce qu'il est procédé à une conversion desdites données échangées.

6. Procédé selon la revendication 1, caractérisé en ce que, pour procéder à un échange de données d'une longueur supérieure à une 30 longueur déterminée, il est procédé à plusieurs échanges successifs de paires de commande Get Input / Terminal Response portant à chaque échange sur une partie déterminée et différente desdites données.

7. Procédé selon la revendication 6, caractérisé en ce que ladite longueur déterminée est égale à 255 octets.

8. Procédé selon la revendication 1, caractérisé en ce que ledit échange de données est effectué au moyen des fonctions suivantes: une fonction d'ouverture du canal de communication (Openchannel), une fonction de lancement de l'application résidente choisie 10 (Runcardlet), une fonction d'envoi de données de l'application embarquée vers l'application résidente (Senddata), une fonction de réception dans l'application embarquée de données envoyées par l'application résidente (Receivedata), et 15. une fonction de fermeture du canal de communication (Closechannel).

9. Procédé selon la revendication 1, caractérisé en ce que ledit terminal de communication est un téléphone mobile.

10. Procédé selon la revendication 1, caractérisé en ce que ledit 20 terminal de communication est un assistant numérique personnel (PDA).