PROCEDE DE GESTION DU DECLENCHEMENT D'UNE APPLICATION DANS UN TERMINAL DE SERVICE NOTAMMENT DANS UN TERMINAL DE TELECOMMUNICATION.
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 1' 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
1' application .
Cette information se présente dans l'exemple sous la forme de 6 octets comme détaillé ci-dessous :
Octet
Octet2: b8 b7 b6 b5 b4 b3 b2 bl
T_ Application supporte GAIT- (Caractéristiques dépendant du) Application supporte DEN- (Caractéristiques dépendant du ) RΓO RΓU RΓU RΓU RΓU RΓΠ
Octet3:
Octet4:
Le tableau suivant illustre un exemple d' information déclarée dans une application et sa signification. Les données sont en hexadécimal.
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 1' 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 »
ANNEXE 2
Commande "PUT DATA"
Commande DATA pour TAG 00C2h
Commande λ GET DATA"
10
Commande DATA pour TAG 00Ch2
Réponse DATA pour TAG 00C2h.
Commande Λ,GET STATUS'
10