Brevet FR2832583A1 — publié le 20030523

Procédé d'accès à une application interne d'un terminal de radiocommunication et terminal mettant en oeuvre ce procédé La présente invention concerne un procédé pour accéder à au moins une application interne d'un terminal de radiocommunication. L'invention concerne également un terminal de radiocommunication mettant en oeuvre ce procédé. Un des domaines d'application, non exclusif, de l'invention est celui des terminaux mobiles de radiocommunication, ou terminaux de radiocommunication, fonctionnant dans un système de radiocommunication cellulaire. L'invention s'applique notamment à un système selon le standard GSM (Groupe spécial Systèmes Mobiles). Un terminal mobile de radiocommunication est généralement utilisé avec une carte utilisateur à puce. Cette carte comprend généralement un identifiant de l'abonné et peut également comprendre des applications dites applications internes puisque enregistrées sur cette carte donc internes au terminal. Ces applications peuvent être de type purement GSM et permettre alors les échanges de données entre le terminal de radiocommunication et le réseau, ou encore de type bancaire et permettre des échanges avec une application externe de type bancaire située sur un site bancaire externe au terminal. Il est à noter que les applications dites internes au terminal de radiocommunication peuvent ne pas être supportées par une carte utilisateur mais directement implémentées dans le terminal de radiocommunication. Il est connu que, lorsqu'une application externe (par exemple, une application bancaire) désire accéder à l'application interne (par exemple bancaire) correspondante dans le terminal de radiocommunication, cette application externe commence le protocole de connexion avec le terminal de radiocommunication. Elle échange des données dites APDU (Applicative Protocol Data Unit en anglais : Unité d'échange de données de niveau applicatif) via l'interface logicielle dudit terminal ou API (Application Programming Interface en anglais : Interface de programmation de et vers l'application). Dans l'APDU, l'application externe indique son type (bancaire, ou autres) ou classe. Cette classe est indiquée dans l'un des octets de l'APDU, appelé octet"CLA". Le concept de plusieurs applications réunies sur une même carte ou dans le même terminal de radiocommunication est très avantageux pour l'abonné. En effet, celui-ci peut effectuer de façon simple et uniquement avec son terminal de radiocommunication de nombreuses opérations telles que le paiement d'une commande effectuée également depuis son terminal. Cependant, pour chaque application interne du terminal de radiocommunication, une API doit être implémentée. Or, le fait d'implémenter une API pour chaque application interne induit un coût en mémoire et en temps de développement relativement important. En outre, les échanges de données entre deux équipements terminaux de traitement de données, par exemple entre un terminal de radiocommunication et un terminal classique portable du type microordinateur portable, ne fonctionnent qu'avec l'échange de commandes dites AT entre les deux terminaux, via un modem. Ces commandes AT seront décrites plus précisément dans ce qui suit. Les commandes AT n'ont jusqu'à présent jamais été utilisées dans un contexte applicatif. Seules les API sont implémentées pour permettre l'échanges de données entre des applications. L'invention a pour but de présenter une solution à ces problèmes et de permettre l'échange de données entre applications via les commandes AT. L'invention, à cet effet, propose un procédé d'accès à au moins une application interne d'un terminal de radiocommunication opérant dans un réseau de radiocommunication susceptible de permettre des échanges bidirectionnels de données selon un standard de données mettant en oeuvre un canal de transfert acheminant des commandes dites AT, le terminal de radiocommunication comprenant un gestionnaire de commandes AT, caractérisé en ce que l'accès à l'application interne du terminal est réalisé par échange de commandes AT à travers ledit gestionnaire des commandes AT. Ainsi, l'invention permet l'accès à une des applications internes supportées par un terminal par l'application externe correspondante via un gestionnaire de commandes AT, élément déjà connu du terminal, avec un coût en mémoire et en temps minimisé. Dans un mode de réalisation particulier, les commandes AT sont échangées via le protocole HTTP (HyperText Transfer Protocol, en anglais). L'invention propose également un terminal supportant au moins une application interne et comprenant des moyens pour permettre des échanges bidirectionnels de données selon un standard de données mettant en oeuvre un canal de transfert acheminant des commandes AT, et des moyens de gestion des commandes AT, caractérisé en ce qu'il comporte des moyens d'accès à l'application interne du terminal par échange de commandes AT à travers les moyens de gestion des commandes AT. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, d'un mode de réalisation de l'invention, donné à titre illustratif et non limitatif, et des dessins énoncés ci-dessous. La figure 1 présente le schéma d'un terminal utilisant le principe de l'invention. La figure 2 est un diagramme d'une commande AT telle que décrite dans l'invention. La figure 1 présente un terminal de radicommunication 10 opérant dans un réseau de radiocommunication susceptible de permettre des échanges bidirectionnels de données entre le terminal et le réseau GSM selon un standard de données mettant en oeuvre un canal de transfert acheminant des commandes AT. Les terminaux de radiocommunication comprennent classiquement un gestionnaire de commande AT permettant la gestion des commandes AT échangées entre le terminal et le réseau GSM. Sur la figure 1, le terminal 10 comprend un gestionnaire de commandes AT 15, une carte utilisateur 20, qui supporte des applications internes i 22 et j 24 de nature différente, par exemple de type bancaire et type commande commerciale, susceptibles d'être accédées par les applications externes correspondantes. Un terminal 10 de ce type peut également comprendre des applications internes non supportées par une carte utilisateur mais simplement implémentées dans le terminal. Le gestionnaire de commandes AT 15 permet la gestion des commandes AT 30 qui lui sont envoyées et la transmission des commandes de et vers les applications internes i22 ou j24. Les applications internes i 22 et j 24 se comportent comme des clients vis à vis du gestionnaire de commandes AT 15. Les commandes AT 30 comprennent un entête 32 et un corps 34 qui seront détaillés ci-après. Le gestionnaire de commandes AT 15 comprend des ports de connexion 26. Lorsque les applications internes i 22 et i 24 communiquent avec l'application externe correspondante, elles contactent le gestionnaire de commande AT via le port qui leur est dédié. Par exemple, l'application i22 contacte le gestionnaire de commandes AT en spécifiant le numéro de port correspondant i 26 inclus dans l'entête 32 d'une commande AT 30, comme schématisé sur la figure 2. Chaque application externe désireuse de communiquer avec l'application interne correspondante, peut communiquer avec le gestionnaire de commandes AT 15 via le protocole d'interface réseau ou serveur HTTP (HyperText Transfer Protocol, en anglais). Ce serveur HTTP peut être implémenté dans le gestionnaire de commandes AT 15. L'application externe ouvre une connexion HTTP avec le gestionnaire de commandes AT 15 sur le port dédié en envoyant des commandes AT 30 de requête vers un des ports du gestionnaire de commandes AT 15 qui lui est dédié. L'application externe spécifie alors dans l'entête 32 de ses commandes AT 30 de requête le port qu'elle souhaite contacter, ainsi que le nombre de caractères que contient le corps 34 de la commande AT 30. Le corps 34 de la commande AT 30 comprend la requête écrite comme une suite de caractères alphanumériques. La commande AT 30 de réponse de la part du gestionnaire de commandes AT 15 est envoyée à travers la connexion HTTP. La commande AT 30 de réponse spécifie dans son entête 32 le statut de la requête. Par exemple, elle spécifie si la connexion avec l'application interne est possible ou non, ainsi que le nombre de caractères que contient le corps de la commande AT 30. Le corps 34 de la commande AT 30 comprend la réponse écrite comme une suite de caractères alphanumériques. Voici un exemple de requête d'une application externe vers une application interne au terminal et spécifique au contact avec le constructeur du terminal : GET/HTTP/1.1 (connexion HTTP ouvert) HOST : localhost : (précision quant au port i visé) Content-length : 7 (nombre de caractères du corps de la commande AT 30) AT+CGM ! (corps de la commande AT 30) Voici un exemple de réponse : HTTP/l. 1 (connexion autorisée par le gestionnaire de commandes AT 75) Content-length : 15 (nombre de caractères du corps de la commande AT 30) ALCATEL-MPD (corps de la commande AT 30) OK Un autre exemple d'utilisation de ces commandes AT dans un contexte applicatif peut être le suivant. Lorsque l'utilisateur du terminal de radiocommunication veut utiliser une application de type JAVA, il peut la télécharger dans son terminal. Ces applications vont exploiter l'environnement d'exécution du terminal et accéder aux applications internes du terminal. Au lieu d'utiliser des API JAVA conventionnelles qu'il aurait fallu implémenter dans le terminal, elles se connectent au gestionnaire de commande AT via le serveur HTTP. Elles accèdent ainsi aux applications internes du terminal en échangeant des commandes AT via le gestionnaire de commandes AT. Dans le gestionnaire de commandes AT 30, quatre ports sont classiquement disponibles et correspondent à des communications avec l'opérateur, le constructeur, un tiers (bancaire par exemple) et enfin à une communication non permise avec une application ne devant pas être accessible de l'extérieur. Lorsqu'une application externe veut accéder à une application interne le gestionnaire de commande AT 30 vérifie que le port concerné n'est pas celui non permis et autorise le cas échéant l'application externe à accéder à l'application interne. L'invention permet ainsi l'utilisation d'un élément déjà présent dans le terminal de radiocommunication : le gestionnaire de commande AT, dans un contexte applicatif. REVENDICATIONS 1. Procédé d'accès à au moins une application interne (22) d'un terminal de radiocommunication opérant dans un réseau de radiocommunication susceptible de permettre des échanges bidirectionnels de données selon un standard de données mettant en oeuvre un canal de transfert acheminant des commandes dites AT (30), le terminal de radiocommunication comprenant un gestionnaire de commandes AT (15), caractérisé en ce que l'accès à l'application interne du terminal (22) est réalisé par échange de commandes AT (30) à travers ledit gestionnaire des commandes AT (15). 2. Procédé selon la revendication 1, caractérisé en ce que les commandes AT (30) sont échangées via le protocole HTTP (HyperText Transfer Protocol, en anglais). 3. Procédé selon les revendications 1 à 2, caractérisé en ce les commandes AT (30) sont échangées sous forme de messages comprenant au moins un entête (32) et un corps (34), l'entête (32) contenant le nombre de caractères composant la commande AT (30) et le corps (34) contenant les caractères de la commande AT (30) proprement dite. 4. Terminal pour la mise en oeuvre le procédé selon les revendications 1 à 3, ledit terminal supportant au moins une application interne et comprenant des moyens pour permettre des échanges bidirectionnels de données selon un standard de données mettant en oeuvre un canal de transfert acheminant des commandes AT (30), et des moyens de gestion des commandes AT, caractérisé en ce qu'il comporte des moyens d'accès à l'application interne du terminal par échange de commandes AT (30) à travers les moyens de gestion des commandes AT.