La présente invention concerne un procédé d'évaluation automatique de la compatibilité entre des applications et des dispositifs de traitement susceptibles d'héberger et/ou d'exécuter et/ou d' interagir avec de telles applications, pouvant comprendre de manière non limitative, un équipement mobile type téléphone portable, PDA (pour « Personal Digital assistant ») ou autre, un ordinateur de type PC, ou bien encore un serveur type serveur d'applications, etc..

L'invention s'applique plus particulièrement, mais non exclusivement, aux dispositifs du type stockant des applications embarquées sur une carte à puce, telle une carte UICC, munie de moyens de traitement de l'information et de mémorisation, et incluant notamment un module fonctionnel connu sous l'abréviation "SIM" (pour "Subscriber Identity Module" selon la terminologie anglo-saxonne ou "Module d'identification d'abonné") . Dans la suite de la description, quand on utilisera le terme « carte SIM », ce dernier doit être interprété de façon non restrictive comme étant une carte à puce multi-applications . Les dispositifs du type précité comprennent un terminal mobile (ou ME pour "Mobile Equipement" selon la terminologie anglo- saxonne) , coopérant avec une telle carte SIM.

Concernant les applications embarquées, il s'agit notamment d'applications Java (ou "applets" selon la terminologie anglo-saxonne) pouvant être téléchargées,

puis exécutées, soit sur la carte SIM (on parle alors plus spécifiquement de "cardlets" selon la terminologie anglo-saxonne) , soit sur le terminal (on parle alors plus spécifiquement de "midlets" selon la terminologie anglo-saxonne) .

Dans ce contexte, il existe aujourd'hui plusieurs technologies de développement d'applications.

Notamment, la technologie dite "SIM Toolkit", où l'application, dite application STK, s'exécute dans la carte SIM.

De façon pratique, une pièce de logiciel spécifique ("cardlet") est implémentée dans la carte à puce SIM du terminal pour l'exécution d'une fonction donnée (envoyer des messages courts, générer une tonalité, établir un appel, accéder à l'Internet, effectuer des transactions bancaires, etc.) .

Le terminal comprend un jeu de commandes et de procédures appelés « SIM Application Toolkit », grâce auquel les applications créées sur la SIM peuvent interagir avec les fonctions du terminal. Le fonctionnement en est le suivant : la carte SIM envoie alors une commande de type "SIM Application Toolkit" au terminal, qui l'exécute si la fonction correspondante est supportée par le terminal, puis rend compte à la carte SIM de la bonne ou mauvaise exécution de la commande. Il peut s'agir de commandes liées aux dialogues SIM-écran, SIM-clavier, SIM-interface radio, etc.

Les fonctions apportées par cette norme permettent de développer un très grand nombre d'applications distinctes sur la carte à puce, dans le but de fournir

aux utilisateurs des services de téléphonie mobile dits "à valeur ajoutée". Le lecteur pourra se reporter utilement à la norme GSM 11.14 ainsi qu'à la norme 3GPP pour plus d' informations . A l'heure actuelle, l'essor de la technologie STK est limitée par le fait que les opérateurs mobiles déploient par défaut des applications STK utilisant uniquement des fonctions qui sont certaines d'être supportées entièrement par les terminaux concernés, de façon à garantir la compatibilité des applications développées avec la plus grande partie des terminaux. Du fait de ces problèmes de compatibilité susceptibles de se poser, les opérateurs sont donc réticents à déployer des applications STK avec des fonctionnalités avancées .

De plus, lorsqu'un utilisateur change de terminal mobile, l'opérateur mobile ne peut pas vérifier automatiquement si les applications installées dans la SIM demeurent compatibles avec le nouveau terminal. De même, lorsque l'utilisateur change de carte SIM, l'opérateur mobile ne peut pas vérifier automatiquement si les applications installées sur la nouvelle carte SIM et les applications stockées dans le terminal demeurent compatibles avec l'environnement global (carte, terminal mobile, cardlets, midlets) .

Les applications peuvent également être développées selon la technologie J2ME (pour "Java 2 Micro Edition"), dans laquelle l'application (on utilise dans ce cas la terminologie "midlet") peut être exécutée dans un terminal disposant d'une plate-forme

J2ME, dédiée au développement et à l'exécution d'applications téléchargeables pour de tels terminaux.

Pour ce faire, la plate-forme comprend trois modules principaux : une machine virtuelle, une interface de programmation (API) adaptée au type de terminal visé et recensant les fonctions utilisables, c'est-à-dire les opération pouvant être exécutées par le terminal, mises en œuvre par une application, et un module de configuration définissant les ressources du terminal.

Dans l'environnement d'exécution J2ME, lorsqu'une application utilise des fonctions ou des interfaces de programmation qui ne sont pas supportées par le terminal, une erreur se produit et l'application n'est pas utilisable.

De plus, aucun moyen n'est fourni actuellement à l'opérateur mobile pour récupérer automatiquement un statut d'incompatibilité ou d'erreur.

Les inconvénients précités ne se limitent pas aux environnements d'exécution évoqués et se rencontrent de la même façon dans d'autres environnements tels que par exemple « Windows Mobile » ou « Brew ».

Aussi, il apparaît qu'aucune solution n'est prévue dans l'état de la technique, permettant aux opérateurs mobiles ou aux fournisseurs de service de savoir automatiquement si des applications seront complètement compatibles d'un point de vue fonctionnel avec des dispositifs de traitement susceptibles d'héberger et/ou d'exécuter ces applications ou simplement d' interagir avec elles .

La présente invention a donc pour but de remédier aux inconvénients précités .

L'invention a ainsi pour objet un procédé d'évaluation de la compatibilité entre au moins une application et au moins un dispositif de traitement hébergeant et/ou exécutant et/ou interagissant avec au moins ladite application, caractérisé en ce qu'il comprend la comparaison entre au moins un profil parmi des profils associés aux dispositifs décrivant respectivement des fonctions supportées par chaque dispositif et au moins un profil parmi des profils associés aux applications décrivant respectivement des fonctions utilisées par chaque application, pour établir automatiquement un diagnostic de compatibilité fonctionnelle entre une ou des applications et un ou des dispositifs.

Selon un mode de réalisation, une application étant prévue pour interagir lors de son exécution avec des fonctions supportées par un dispositif de type terminal mobile, l'établissement du diagnostic de compatibilité fonctionnelle comprend la comparaison entre le profil associé audit terminal décrivant les fonctions supportées par ledit terminal et le profil associée à ladite application. Selon une variante, l'application étant hébergée dans un dispositif de type carte SIM avec laquelle coopère le terminal mobile, l'établissement du diagnostic de compatibilité fonctionnelle comprend en outre la comparaison entre le profil associé à ladite application et un profil associé à la carte SIM décrivant les fonctions supportées par ladite carte.

Selon une autre variante, l'application étant liée pour son exécution à au moins une autre application, l'établissement du diagnostic de compatibilité fonctionnelle comprend en outre la comparaison entre le profil associé à ladite au moins autre application et le profil associé audit terminal.

Selon une autre variante, ladite au moins autre application étant stockée dans une carte SIM avec laquelle coopère ledit terminal, l'établissement du diagnostic de compatibilité comprend en outre la comparaison entre le profil associé à ladite au moins autre application et un profil associé à la carte SIM décrivant les fonctions supportées par ladite carte. Avantageusement, l'établissement du diagnostic de compatibilité fonctionnelle comprend la détermination d'une liste des fonctions utilisées par l'application et/ou ladite au moins une autre application à laquelle elle est liée, qui ne sont pas supportées par le terminal ou la carte.

Avantageusement, les profils sont mémorisés et mis à jour dans une table de configuration, qui mémorise l'environnement d'exécution associé à chaque application et les liens existant entre chaque application pour leur exécution.

De préférence, le procédé comprend le déclenchement d'actions spécifiques selon le diagnostic de compatibilité établi.

Selon un mode de réalisation, le déclenchement d'actions spécifiques comprend une mise à niveau du ou des dispositifs ou une désactivation des fonctions

utilisées par la ou les applications, qui sont non supportées .

Avantageusement, le procédé est mis en œuvre côté client, ou côté serveur, ou de manière partagée côté serveur et client.

L'invention concerne également un module logiciel d'évaluation de la compatibilité entre au moins une application et au moins un dispositif de traitement hébergeant et/ou exécutant et/ou interagissant avec au moins ladite application, caractérisé en ce qu'il comprend des instructions pour commander l'exécution du procédé selon l'invention par un système informatique.

L'invention concerne encore un terminal mobile, caractérisé en ce qu'il intègre un module logiciel selon l'invention.

L'invention concerne enfin une carte à puce, caractérisé en ce qu'elle intègre un module logiciel selon l'invention.

D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures annexées dans lesquelles :

-la figure 1 illustre un exemple de description basée sur une suite de bits qui sert à identifier un dispositif ou une application;

-la figure 2 illustre un exemple d'architecture fonctionnel pour la mise en œuvre du procédé selon l'invention, basée sur un terminal mobile combiné avec une carte SIM, hébergeant et exécutant une pluralité d'applications ;

-la figure 3 illustre un exemple de mise en œuvre dans un environnement « SIM Toolkit », et

- la figure 4 illustre un exemple de mise en œuvre dans un environnement « J2ME ». La présente invention est ainsi prévue pour permettre une évaluation automatique de la compatibilité fonctionnelle entre un ensemble d'applications et un ensemble de dispositifs de traitement hébergeant et/ou exécutant et/ou interagissant avec les applications. De manière générale, on considère au moins un dispositif hôte, qui stocke et exécute l'application et au moins un dispositif dit connecté, qui ne stocke pas l'application mais qui est nécessaire pour l'exécution de certaines actions requises par l'application. L'application peut également appeler et utiliser une autre application à laquelle elle est liée pour son exécution, laquelle autre application pouvant être stockée dans le même dispositif hôte ou dans un dispositif différent connecté.

Pour la description qui va suivre d'un mode de réalisation de l'invention, on considère plus précisément un ensemble constitué de la combinaison d'un terminal mobile et d'une carte SIM avec laquelle le terminal coopère. L'invention ne se limite toutefois pas à une telle combinaison de dispositifs.

L'invention va donc permettre d'établir automatiquement un diagnostic de compatibilité fonctionnelle entre des applications et un tel ensemble sur lequel les applications peuvent être téléchargées, stockées et exécutées, soit dans la carte SIM, soit

dans le terminal. Ce diagnostic peut être établi avant le téléchargement de l'application concernée ou bien encore, selon une variante, après que l'application a été téléchargée. Pour ce faire, on utilise le fait que les applications et chaque dispositif de traitement sont décrits respectivement par un identifiant unique et un profil. La figure 1 illustre à cet effet un exemple de structure de description des caractéristiques d'un dispositif de traitement DCT et de description des caractéristiques d'une application ACT, sur lequel peut être basé un diagnostic de compatibilité selon 1' invention.

Ainsi, la description des caractéristiques d'un dispositif client DCT, tel qu'un terminal mobile, comprend un identifiant de terminal DIN, décrit par une suite de bits Id(1),..., Id(n) , typiquement le numéro IMEI du terminal (pour « International Mobile Equipment Identity » en anglais) , et un profil associé au terminal DPD, décrivant notamment, sous forme d'une suite de bit Fd(I), Fd(2)..., Fd(n), la liste des fonctions ou groupe/classe de fonctions supportées par le terminal.

Par exemple, selon la norme 3GPP TS 51.014 v.4.3.0, le profil terminal contient la liste des fonctions de type « SIM Application Toolkit » qui sont supportées par le terminal. Un bit est utilisée pour coder chaque fonction de ce type. Un bit placé à « 1 » signifie alors que la fonction concernée codée par ce bit Fd(i) est supportée par le terminal et un bit

placée à « 0 » signifie que la fonction concernée n'est pas supportée par le terminal.

Il est à noter que si le dispositif client est constitué à la fois du terminal mobile et d'une carte SIM, alors une description des caractéristiques de la carte SIM incluant de la même façon un identifiant et un profil sera allouée à celle-ci.

Chaque application, stockée ou destinée à l'être soit dans la SIM, soit dans le terminal est également décrite par un identifiant d'application unique AIN et un profil d'application associé APD. La structure du profil application doit être comparable à la structure du profil terminal, mais peut être différente ou non équivalente à cette dernière. Dans l'exemple de réalisation, le profil application décrit, sous forme d'une suite de bit Fa(I), Fa(2)..., Fa (n), la liste des fonctions utilisées par l'application en question. Un bit placé à « 1 » signifie alors que la fonction concernée codée par ce bit Fa (i) est utilisée par l'application et un bit placée à « 0 » signifie que la fonction concernée n'est pas utilisée.

Si l'application est liée à une autre application du dispositif pour son exécution, cette autre application pouvant être stockée dans le terminal ou la carte SIM, cette information peut également être codée dans le profil application.

Toutes les fonctions supportées par un terminal (ou par la carte SIM) ainsi que celles utilisées par une application sont donc décrites dans leurs profils. La structure d'un profil associé à une application et la structure d'un profil associé à un terminal (ou à

une carte SIM) sont similaires, permettant ainsi aux profils d'être comparés partiellement ou entièrement.

La figure 2 illustre à cet effet un exemple d'architecture fonctionnel pour la mise en œuvre du procédé selon l'invention, basée sur un ensemble de dispositifs de traitement formé d'un terminal mobile Dl combiné avec une carte SIM D2 avec laquelle il coopère, stockant et exécutant une pluralité d'applications, Al, A2, A3 et A4. Plus précisément, les applications Al et A2 sont stockées dans le terminal Dl, tandis que les applications A3 et A4 sont stockées dans la carte SIM D2.

Un module de configuration 10, se présentant sous la forme d'une partie de logiciel, est prévu pour gérer et mettre à jour une table de configuration 20, décrivant la combinaison des composants matériels et logiciels de l'ensemble formé par Dl et D2 et Al à A4, de façon à pouvoir déterminer les caractéristiques essentielles de fonctionnement des différentes applications selon leur environnement d'exécution.

Pour ce faire, le module de configuration comprend un module de synchronisation 30, dont le rôle est d'obtenir, en (1) sur la figure 2, la description courante des caractéristiques des dispositifs et applications coopérant ensemble. le module de synchronisation est par exemple mis en œuvre lors de la phase de démarrage du terminal. La table de configuration 20 est alors mise à jour si nécessaire.

Ainsi, dans l'exemple décrit, le module de synchronisation 30 permet d'obtenir la description des caractéristiques DCTl du terminal Dl, formée par

l'identifiant terminal et le profil terminal comme précédemment décrit et, de la même façon, la description des caractéristiques DCT2 de la carte SIM D2, ainsi que les descriptions des caractéristiques ACTl à ACT4 associées respectivement aux applications Al à A4.

Le module de configuration est donc capable de détecter et de tenir à jour les changements de configuration (par exemple un changement de dispositif par l'utilisateur, une mise à niveau des fonctions supportées par le terminal...) via son module de synchronisation.

La table 20 mise à jour mémorise alors les profils associés aux dispositifs Dl, D2 et aux applications Al à A4. La table de configuration 20 mémorise également l'environnement d'exécution associé à chaque application et les liens existant entre chaque application pour leur exécution. Ainsi, la table décrit pour chaque application Al à A4, les informations suivantes : le dispositif terminal Dl ou carte SIM D2 dans lequel elle est stockée pour son exécution (Dev.H), le dispositif Dl ou D2 éventuellement nécessaire pour l'exécution de certaines actions requises par l'application (Dev.C), ainsi que l'application à laquelle elle est éventuellement liée pour son exécution (Appli.L) .

Une fois la table de configuration mise à jour, un module de compatibilité, se présentant sous forme d'une partie de logiciel, peut être mis en œuvre en (3) pour établir automatiquement un diagnostic de compatibilité fonctionnelle entre les différentes applications et

dispositifs, basé sur une comparaison de leurs profils respectifs selon les informations de configuration définies dans la table.

Le module de compatibilité peut être mis en œuvre à la demande ou automatiquement, par exemple en cas de changement de terminal mobile par l'utilisateur, à la mise sous tension du terminal, en cas de téléchargement d'une nouvelle application, à la demande d'un serveur etc... Enfin, un module de décision 50 peut être prévu pour coopérer avec le module de comptabilité. Le module de décision est prévu en (4) pour déclencher des actions spécifiques selon le diagnostic de compatibilité fonctionnelle établi par le module de compatibilité.

Nous allons maintenant décrire plus en détail un mode de réalisation donné à titre d'exemple, permettant l'établissement d'un diagnostic de compatibilité fonctionnel par le module 40 selon différents scénarii. Ainsi, dans un premier scénario correspondant à ce qui est décrit figure 2, le module de compatibilité 40 effectue un diagnostic de compatibilité fonctionnelle entre l'application Al, stocké dans le terminal, et le dispositif terminal Dl. Comme on l'a vu, un tel diagnostic est basé sur une comparaison des profils respectifs de Al et Dl.

Le module de compatibilité 40 exécute un algorithme de comparaison consistant en une comparaison bit à bit, basée sur la fonction logique OU exclusif, des séquences de bit respectives FdI (i) et FaI (i)

constituant les profils de Dl et Al. L'algorithme peut alors s'écrire de la manière suivante :

Cl (i) = FdI (i) © FaI (i) (l≤i≤n) , avec FdI (i), le bit codant la possibilité pour Dl de supporter la fonction décrite à la position i dans le profil de Dl;

FaI (i) , le bit correspondant du profil de Al indiquant si cette fonction est utilisée par Al; et © symbolisant l'opération logique OU exclusif.

Ainsi, si au moins une position i peut être identifiée telle que [ (Cl (i) = 1) ET (FdI (i) = O)], alors cela signifie qu'il y a une incompatibilité fonctionnelle entre Dl et Al pour la fonction correspondante à la position i.

Selon ce scénario, le diagnostic de compatibilité fonctionnelle établi par le module 40 peut consister à indiquer la présence d'au moins une incompatibilité fonctionnelle ou encore, de façon plus précise, peut comprendre la détermination d'une liste des fonctions utilisées par l'application Al, qui ne sont pas supportées par le terminal Dl. Différents niveaux de diagnostic peuvent ainsi être fournis.

Selon le diagnostic fourni, des actions spécifiques peuvent alors être mises en œuvre par le module de décision, telles que par exemple une mise à niveau des fonctions supportées par le terminal ou une désactivation des fonctions utilisées par l'application, qui sont non supportées.

Un tel diagnostic peut être établi de la même façon selon un deuxième scénario, visant par exemple à

évaluer la compatibilité fonctionnelle entre l'application A3, stockée dans la carte, et, d'une part, le terminal Dl et, d'autre part, la carte D2. En effet, la table de configuration montre que l'application A3 stockée dans la carte D2 a besoin du terminal Dl, censé exécuter certaines actions requises par Al .

Selon ce scénario, l'établissement du diagnostic de compatibilité fonctionnelle comprend alors, en plus de la comparaison entre le profil associé à A3 et le profil associé au terminal Dl, la comparaison entre le profil associé à A3 et le profil associé à la carte D2 décrivant les fonctions supportées par la carte. L'algorithme peut alors s'écrire de la manière suivante pour les deux comparaisons:

Cl (i) := Fdl(i) ® Fa3(i), (l≤i≤n)

C2(i) := Fd2(i) © Fa3(i), (l≤i≤n) avec FdI (i) , le bit codant la possibilité pour Dl de supporter la fonction décrite à la position i dans le profil de Dl; Fd2 (i) , le bit codant la possibilité pour D2 de supporter la fonction décrite à la position i dans le profil de D2 et Fa3(i), le bit correspondant du profil de A3 indiquant si cette fonction à la position i est utilisée par A3. Ainsi, si au moins une position i peut être trouvée telle que [ (Cl (i) = 1) ET (FdI (i) = O)] OU

[(C2(i) = 1) ET (Fd2(i) = O)], alors cela signifie qu'il y a une incompatibilité fonctionnelle entre Dl et

A3 et/ou D2 et A3. Un diagnostic de compatibilité

fonctionnelle peut être établi consistant par exemple en une liste des fonctions utilisées par l'application A3, qui ne sont pas supportées par le terminal ou la carte. Un cas d'utilisation pratique de ce scénario concerne typiquement la technologie dite « SIM Toolkit », où l'application A3, dite application STK, s'exécute dans la carte SIM. Le module de compatibilité compare les différents profils SIM, terminal et application, comme illustrés en figure 3, en comparant simplement les séquences binaires de ces profils tels que définis par la norme 3GPP précitée.

Selon un mode de réalisation, le module de configuration et le module de compatibilité sont stockés dans la carte SIM du terminal. Le module de compatibilité peut alors être lancé automatiquement, une fois que la table de configuration est mise à jour, ou encore quand l'utilisateur veut utiliser une application. Toutefois, le lancement du module de compatibilité peut être conditionné par d'autres types d'événements .

Dans l'exemple de la figure 3, l'application « SIM Toolkit » concernée est prévue pour utiliser la fonction « launch browser », comme décrit par le bit placé à « 1 » indiqué par une flèche au niveau de l'octet n°9 du profil application. La fonction « launch browser » permet à une application « SIM Toolkit » de lancer un navigateur pour accéder à Internet sur un terminal WAP (pour « Wireless Application Protocol » en anglais) .

L'application de l'algorithme décrit en référence au deuxième scénario ci-dessus par le module de compatibilité conduit à établir un diagnostic d' incompatibilité pour cette fonction entre l'application « SIM Toolkit » et le terminal, ce dernier ne supportant pas la fonction « launch browser », comme décrit par le bit placé à « 0 » indiqué par une flèche au niveau de l'octet n°9 du profil terminal. Dans l'environnement « SIM Toolkit », la comparaison entre les profils application et carte SIM, n'est pas indispensable. En effet, classiquement, le périmètre fonctionnel de la carte est supérieur à celui de l'application. L'environnement où les fonctions utilisées par l'application peuvent être limitées correspond donc plutôt à celui du terminal. On peut donc se limiter en pratique à comparer les fonctions utilisées par l'application avec les fonctions supportées par le terminal. Cependant, les applications « SIM Toolkit » étant exécutées dans la carte SIM, il peut être intéressant de comparer les fonctions de l'application avec celles supportées par la carte.

En reprenant l'exemple de configuration de la figure 2, un troisième scénario peut encore être envisagé, visant par exemple à évaluer la compatibilité fonctionnelle de l'application A2, stockée et exécutée dans le terminal Dl. Or, la table de configuration 20 montre que l'application A2, stockée dans le terminal Dl, a besoin de la carte D2, censée exécuter certaines actions requises par A2 et est de plus liée à l'application A4 pour son exécution, laquelle, stockée

dans la carte D2, ayant besoin du terminal Dl pour son exécution.

Selon ce scénario, compte tenu de la table de configuration, l'établissement du diagnostic de compatibilité fonctionnelle peut alors comprendre, en plus de la comparaison du profil associé à A2 avec respectivement le profil associé au terminal Dl et le profil associé à la carte D2, la comparaison du profil associé à l'application A4 avec respectivement le profil associé au terminal Dl et le profil associé à la carte D2. L'algorithme mis en œuvre par le module de compatibilité peut alors s'écrire de la manière suivante pour les quatre comparaisons:

Cl (i) = Fdl(i) ® Fa2(i), (l≤i≤n)

C2(i) = Fd2(i) © Fa2(i), (l≤i≤n)

C3(i) = Fdl(i) © Fa4(i), (l≤i≤n)

C4(i) = Fd2(i) © Fa4(i), (l≤i≤n) avec FdI (i), le bit codant la possibilité pour Dl de supporter la fonction décrite à la position i dans le profil de Dl; Fd2 (i) , le bit codant la possibilité pour D2 de supporter la fonction décrite à la position i dans le profil de D2, Fa2 (i) , le bit correspondant du profil de A2 indiquant si cette fonction à la position i est utilisée par A2 et Fa4 (i) , le bit correspondant du profil de A4 indiquant si cette fonction à la position i est utilisée par A2.

Ainsi, si au moins une position i peut être trouvée telle que : [ (Cl (i) = 1) ET (FdI (i) = 0)] OU

[(C2(i) = 1) ET (Fd2(i) = 0)] OU [(C3(i) = 1) ET

(FdI (i) = 0)] OU [(C4(i) = 1) ET (Fd2 (i) == O)], alors cela signifie qu'il y a une incompatibilité fonctionnelle entre Dl et A2 et/ou D2 et A2 et/ou Dl et A4 et/ou D2 et A4. Un diagnostic de compatibilité fonctionnelle peut être établi consistant par exemple en une liste des fonctions utilisées par l'application

A2, qui ne sont pas supportées par le terminal ou la carte. Un cas d'utilisation pratique de ce scénario concerne typiquement la technologie dite « J2ME », où l'application cliente, s'exécute dans un terminal disposant d'une plate-forme J2ME. Le cas d'utilisation pratique pourrait être par exemple une application Java (A2) selon la spécification JSR177, autorisant la communication entre le terminal Java et une carte SIM supportant des fonctions évoluées, l'application pouvant alors par exemple accéder à des fonctions cryptographiques de signature fournies par une application SIM évoluée (A4) .

Pour ce faire, le profil terminal tel que décrit selon l'environnement « SIM Toolkit » est étendu pour comprendre les fonctions J2ME supportées par le terminal. On rajoute alors des octets au profil terminal, qui sont dédiés aux fonctions J2ME, comme cela apparaît dans l'exemple de la figure 4. Il en est de même pour les profils applications. Le module de configuration doit alors être capable de récupérer les profils étendus associés au terminal et à la carte SIM ainsi que les profils étendus associés aux applications .

Dans l'exemple de la figure 4, l'application Java concernée (A2) est prévue pour utiliser une fonction de signature de message, comme décrit par le bit placé à « 1 » indiqué par une flèche au niveau de l'octet n°23 du profil application A2. La fonction de signature de message est fournie par l'application SIM A4, qui supporte cette fonction, comme décrit par le bit placé à « 1 » indiqué par une flèche au niveau de l'octet n°23 du profil application A4. La carte elle-même supporte cette fonction comme le montre son profil.

L'application de l'algorithme décrit en référence au troisième scénario ci-dessus par le module de compatibilité conduit alors à établir un diagnostic d' incompatibilité pour cette fonction entre l'application Java et le terminal, ce dernier ne supportant pas la fonction de signature de message concernée, comme décrit par le bit placé à « 0 » indiqué par une flèche au niveau de l'octet n°23 du profil terminal. L'invention permet donc à un opérateur mobile de savoir si une application devant être téléchargée, soit dans la carte SIM, soit dans le terminal, est compatible avec le terminal (et éventuellement la carte SIM) . Si, un diagnostic établissant une incompatibilité fonctionnelle est établi, il est alors possible de mettre à niveau les fonctions du terminal et/ou de la carte et/ou de désactiver certaines fonctions de 1'application.

Les trois principaux modules permettant la mise en œuvre du procédé de l'invention, à savoir le module de configuration, le module de compatibilité et le module

de décision peuvent être implémentés et répartis séparément, soit côté client, sur la carte SIM et/ou le terminal mobile, soit côté serveur, soit côté client et serveur à la fois. De plus, le mode de réalisation décrit en référence aux différents scénarii pour la comparaison des profils application et terminal permettant l'établissement du diagnostic de compatibilité fonctionnelle ne se limite pas à l'approche évoquée basée sur une comparaison des séquences binaires constituant les profils.

En effet, le mode de réalisation décrit fait référence à des profils dont la structure est constituée par des suites d'octets. Toutefois, sans sortir du cadre de la présente invention, les profils application et terminal pourraient présenter une autre structure. Ils pourraient par exemple être constitués par une suite d'objets classés dans des arbres décrivant les fonctions supportées, auquel cas la comparaison des profils pour obtenir le diagnostic de compatibilité fonctionnelle pourrait être basée sur une analyse de type structure d'objet.