EP1815702A1 - Procede d'evaluation de la compatibilite entre des applications et des dispositifs de traitement - Google Patents

Procede d'evaluation de la compatibilite entre des applications et des dispositifs de traitement

Info

Publication number
EP1815702A1
EP1815702A1 EP05801408A EP05801408A EP1815702A1 EP 1815702 A1 EP1815702 A1 EP 1815702A1 EP 05801408 A EP05801408 A EP 05801408A EP 05801408 A EP05801408 A EP 05801408A EP 1815702 A1 EP1815702 A1 EP 1815702A1
Authority
EP
European Patent Office
Prior art keywords
application
terminal
profile
card
applications
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05801408A
Other languages
German (de)
English (en)
Inventor
Marc Niccolini
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SA
Original Assignee
Gemplus Card International SA
Gemplus SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gemplus Card International SA, Gemplus SA filed Critical Gemplus Card International SA
Publication of EP1815702A1 publication Critical patent/EP1815702A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/64—Retargetable
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72406—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by software upgrading or downloading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/183—Processing at user equipment or user record carrier

Definitions

  • the present invention relates to a method for automatic evaluation of the compatibility between applications and processing devices capable of hosting and / or executing and / or interacting with such applications, which may include but not be limited to: mobile equipment type mobile phone, PDA (for "Personal Digital Assistant") or other, a PC-type computer, or even a server-type application server, etc.
  • the invention applies more particularly, but not exclusively, to devices of the type storing embedded applications on a smart card, such as a UICC card, provided with information processing and storage means, and including in particular a module Functional known under the abbreviation "SIM” (for "Subscriber Identity Module” according to the English terminology or “Subscriber identification module”).
  • SIM Subscriber Identity Module
  • SIM card the latter must be interpreted in a non restrictive manner as being a multi-application smart card.
  • the devices of the aforementioned type comprise a mobile terminal (or ME for "Mobile Equipment” according to the English terminology), cooperating with such a SIM card.
  • these include Java applications (or "applets” according to the English terminology) that can be downloaded, then executed, either on the SIM card (we speak more specifically of "cardlets” according to the English terminology), or on the terminal (it is more specifically referred to as “midlets” according to the English terminology).
  • SIM Toolkit where the application, called STK application, runs in the SIM card.
  • cardlet a specific piece of software
  • sending short messages generating a tone, establishing a call, accessing the card.
  • Internet make banking transactions, etc.
  • the terminal includes a set of commands and procedures called "SIM Application Toolkit", whereby applications created on the SIM can interact with the terminal functions.
  • SIM Application Toolkit a command of "SIM Application Toolkit” type to the terminal, which executes it if the corresponding function is supported by the terminal, then reports to the SIM card the good or bad execution of the command.
  • the mobile operator can not automatically check whether the applications installed in the SIM remain compatible with the new terminal.
  • the mobile operator can not automatically check whether the applications installed on the new SIM card and the applications stored in the terminal remain compatible with the global environment (card, mobile terminal, cardlets, midlets).
  • the applications can also be developed according to J2ME technology (for "Java 2 Micro Edition"), in which the application (in this case the terminology “midlet”) can be executed in a terminal with a platform J2ME, dedicated to the development and execution of downloadable applications for such terminals.
  • the platform comprises three main modules: a virtual machine, a programming interface (API) adapted to the type of terminal targeted and listing the usable functions, that is to say the operations that can be executed by the terminal, implemented by an application, and a configuration module defining the resources of the terminal.
  • API programming interface
  • the subject of the invention is thus a method for evaluating the compatibility between at least one application and at least one processing device hosting and / or executing and / or interacting with at least said application, characterized in that it comprises the comparing at least one profile among profiles associated with devices respectively describing functions supported by each device and at least one profile among profiles associated with the applications respectively describing functions used by each application, to automatically establish a functional compatibility diagnosis between a or applications and one or more devices.
  • an application being designed to interact during its execution with functions supported by a device of the mobile terminal type, the establishment of the functional compatibility diagnosis comprises the comparison between the profile associated with said terminal describing the functions supported by said terminal and the profile associated with said application.
  • the application being hosted in a SIM card device with which the mobile terminal cooperates, the establishment of the functional compatibility diagnosis furthermore comprises the comparison between the profile associated with said application and a profile associated with the card. SIM describing the functions supported by said card.
  • the application being linked for its execution to at least one other application, the establishment of the functional compatibility diagnosis further comprises the comparison between the profile associated with said at least one other application and the profile associated with said terminal.
  • the establishment of the compatibility diagnosis furthermore comprises the comparison between the profile associated with said at least one other application and a profile associated with the SIM card describing the functions supported by said card.
  • the establishment of the functional compatibility diagnosis comprises the determination of a list of the functions used by the application and / or said at least one other application to which it is linked, which are not supported by the terminal or the card .
  • the profiles are stored and updated in a configuration table, which stores the execution environment associated with each application and the links between each application for execution.
  • the method comprises triggering specific actions according to the established compatibility diagnosis.
  • the triggering of specific actions comprises an upgrade of the device (s) or a deactivation of the functions used by the application (s), which are unsupported.
  • the method is implemented on the client side, or server side, or shared server and client side.
  • the invention also relates to a software module for evaluating the compatibility between at least one application and at least one processing device hosting and / or executing and / or interacting with at least said application, characterized in that it comprises instructions for controlling the execution of the method according to the invention by a computer system.
  • the invention also relates to a mobile terminal, characterized in that it integrates a software module according to the invention.
  • the invention relates to a smart card, characterized in that it incorporates a software module according to the invention.
  • FIG. 1 illustrates an exemplary description based on a sequence of bits that serves to identify a device or an application
  • FIG. 2 illustrates an exemplary functional architecture for implementing the method according to the invention, based on a mobile terminal combined with a SIM card, hosting and executing a plurality of applications;
  • FIG. 3 illustrates an exemplary implementation in a "SIM Toolkit" environment, and
  • FIG. 4 illustrates an example of implementation in a "J2ME" environment.
  • the present invention is thus intended to allow an automatic evaluation of the functional compatibility between a set of applications and a set of processing devices hosting and / or executing and / or interacting with the applications.
  • at least one host device which stores and executes the application and at least one device said connected, which does not store the application but which is necessary for the execution of certain actions required by the application, is considered.
  • the application may also call and use another application to which it is linked for execution, which other application may be stored in the same host device or in a different connected device.
  • the invention will therefore make it possible to automatically establish a functional compatibility diagnosis between applications and such a set on which the applications can be downloaded, stored and executed, either in the SIM card or in the terminal.
  • This diagnosis can be established before downloading the application concerned or alternatively after the application has been downloaded.
  • the applications and each processing device are respectively described by a unique identifier and a profile.
  • FIG. 1 illustrates for this purpose an exemplary structure for describing the characteristics of a DCT processing device and describing the characteristics of an ACT application, on which a compatibility diagnosis according to the invention can be based.
  • the description of the characteristics of a client device DCT such as a mobile terminal, comprises a terminal identifier DIN, described by a sequence of bits Id (1), ..., Id (n), typically the number IMEI terminal (for "International Mobile Equipment Identity” in English), and a profile associated with the DPD terminal, including, in the form of a sequence of bit Fd (I), Fd (2) ..., Fd (n) ), the list of functions or group / class of functions supported by the terminal.
  • the terminal profile contains the list of "SIM Application Toolkit” type functions that are supported by the terminal.
  • a bit is used to encode each function of this type.
  • a bit set to "1” then means that the relevant function encoded by this Fd (i) bit is supported by the terminal and one bit set to "0" means that the function concerned is not supported by the terminal.
  • the client device consists of both the mobile terminal and a SIM card
  • a description of the characteristics of the SIM card including in the same way an identifier and a profile will be allocated to it.
  • Each application stored or intended to be in the SIM or in the terminal is also described by a unique application identifier AIN and a related application profile APD.
  • the structure of the application profile must be comparable to the structure of the terminal profile, but may be different or not equivalent to the latter.
  • the application profile describes, in the form of a sequence of bits Fa (I), Fa (2) ..., Fa (n), the list of functions used by the application in question.
  • a bit set to "1” then means that the function concerned encoded by this bit Fa (i) is used by the application and a bit set to "0" means that the function concerned is not used.
  • this other application can be stored in the terminal or the SIM card, this information can also be coded in the application profile.
  • FIG. 2 illustrates for this purpose an example of a functional architecture for implementing the method according to the invention, based on a set of processing devices consisting of a mobile terminal D1 combined with a SIM card D2 with which it cooperates , storing and executing a plurality of applications, A1, A2, A3 and A4. More specifically, the applications A1 and A2 are stored in the terminal D1, while the A3 and A4 applications are stored in the SIM card D2.
  • a configuration module 10 in the form of a piece of software, is provided for managing and updating a configuration table 20, describing the combination of hardware and software components of the set formed by D1 and D2 and Al to A4, so as to be able to determine the essential characteristics of operation of the different applications according to their execution environment.
  • the configuration module comprises a synchronization module 30, the role of which is to obtain, in (1) in FIG. 2, the current description of the characteristics of the devices and applications cooperating together.
  • the synchronization module is for example implemented during the startup phase of the terminal.
  • the configuration table 20 is then updated if necessary.
  • the synchronization module 30 makes it possible to obtain the description of the characteristics DCT1 of the terminal D1 formed by the terminal identifier and the terminal profile as previously described and, in the same way, the description of the DCT2 characteristics of the SIM card D2, as well as the descriptions of the ACT1 to ACT4 characteristics respectively associated with the applications A1 to A4.
  • the configuration module is therefore able to detect and update configuration changes (for example a device change by the user, an upgrade of the functions supported by the terminal, etc.) via its synchronization module.
  • the updated table 20 then stores the profiles associated with devices D1, D2 and applications A1 to A4.
  • the configuration table 20 also stores the execution environment associated with each application and the links between each application for execution.
  • the table describes for each application A1 to A4, the following information: the terminal device D1 or SIM card D2 in which it is stored for its execution (Dev.H), the device D1 or D2 possibly necessary for the execution of some actions required by the application (Dev.C), as well as the application to which it is possibly linked for its execution (Appli.L).
  • a compatibility module in the form of a piece of software, can be implemented in (3) to automatically establish a functional compatibility diagnosis between the different applications and devices, based on a comparison of their respective profiles according to the configuration information defined in the table.
  • the compatibility module can be implemented on demand or automatically, for example in the event of a change of mobile terminal by the user, when the device is turned on, when downloading a new application, on demand of a server etc ...
  • a decision module 50 can be provided to cooperate with the accounting module. The decision module is provided in (4) to trigger specific actions according to the functional compatibility diagnosis established by the compatibility module.
  • the compatibility module 40 performs a functional compatibility diagnosis between the application A1, stored in the terminal, and the terminal device D1. As we have seen, such a diagnosis is based on a comparison of the respective profiles of Al and Dl.
  • the compatibility module 40 executes a comparison algorithm consisting of a bit-by-bit comparison, based on the exclusive OR logic function, of the respective bit sequences FdI (i) and FaI (i). constituting the profiles of Dl and Al.
  • the algorithm can then be written in the following way:
  • FaI (i) the corresponding bit of the Al profile indicating whether this function is used by Al; and ⁇ symbolizing the exclusive OR logical operation.
  • the functional compatibility diagnosis established by the module 40 may consist of indicating the presence of at least one functional incompatibility or, more precisely, may include the determination of a list of the functions used by the application. Al, which are not supported by the terminal Dl. Different levels of diagnosis can thus be provided.
  • specific actions can then be implemented by the decision module, such as for example an upgrade of the functions supported by the terminal or a deactivation of the functions used by the application, which are not supported.
  • Such a diagnosis can be established in the same way according to a second scenario, aiming for example at evaluate the functional compatibility between the application A3, stored in the card, and on the one hand, the terminal D1 and on the other hand, the card D2.
  • the configuration table shows that the application A3 stored in the D2 card needs the terminal Dl, supposed to perform certain actions required by Al.
  • the establishment of the functional compatibility diagnosis then comprises, in addition to the comparison between the profile associated with A3 and the profile associated with the terminal D1, the comparison between the profile associated with A3 and the profile associated with the card D2. describing the functions supported by the card.
  • the algorithm can then be written in the following way for the two comparisons:
  • C2 (i): Fd2 (i) Fa Fa3 (i), (l ⁇ i ⁇ n) with FdI (i), the bit coding the possibility for D1 to support the function described at position i in the profile of Dl ;
  • a compatibility diagnosis functional can be established consisting for example of a list of functions used by the application A3, which are not supported by the terminal or the card.
  • a case of practical use of this scenario typically concerns the so-called "SIM Toolkit" technology, where the application A3, called STK application, runs in the SIM card.
  • the compatibility module compares the different SIM, terminal and application profiles, as illustrated in FIG. 3, simply by comparing the bit sequences of these profiles as defined by the aforementioned 3GPP standard.
  • the configuration module and the compatibility module are stored in the SIM card of the terminal.
  • the compatibility module can then be launched automatically, once the configuration table is updated, or when the user wants to use an application.
  • the launch of the compatibility module may be conditioned by other types of events.
  • the application "SIM Toolkit” concerned is provided to use the "launch browser” function, as described by the bit placed at "1" indicated by an arrow at the level of the byte No. 9 of the application profile.
  • the "launch browser” function allows a "SIM Toolkit” application to launch a browser to access the Internet on a WAP terminal (for "Wireless Application Protocol”).
  • the application of the algorithm described with reference to the second scenario above by the compatibility module leads to establish a diagnosis of incompatibility for this function between the application "SIM Toolkit” and the terminal, the latter not supporting the "launch browser” function, as described by the bit set to "0" indicated by an arrow at octet No. 9 of the terminal profile.
  • SIM Toolkit In the "SIM Toolkit” environment, the comparison between application and SIM profiles is not necessary. In fact, conventionally, the functional perimeter of the card is greater than that of the application. The environment where the functions used by the application can be limited therefore corresponds rather to that of the terminal. We can therefore limit our in practice to compare the functions used by the application with the functions supported by the terminal. However, the SIM Toolkit applications being executed in the SIM card, it may be interesting to compare the functions of the application with those supported by the card.
  • a third scenario can still be envisaged, aiming, for example, to evaluate the functional compatibility of the application A2, stored and executed in the terminal D1.
  • the configuration table 20 shows that the application A2, stored in the terminal D1, needs the card D2, which is supposed to perform certain actions required by A2 and is further linked to the application A4 for its execution, which, stored in the card D2, needing the terminal Dl for its execution.
  • the establishment of the functional compatibility diagnosis can then comprise, in addition to the comparison of the profile associated with A2 with respectively the profile associated with the terminal D1 and the profile associated with the card D2. comparing the profile associated with the application A4 with respectively the profile associated with the terminal D1 and the profile associated with the card D2.
  • the algorithm implemented by the compatibility module can then be written in the following manner for the four comparisons:
  • C4 (i) Fd2 (i) Fa Fa4 (i), (l ⁇ i ⁇ n) with FdI (i), the bit encoding the possibility for D1 to support the function described at position i in the profile of D1; Fd2 (i), the bit encoding the possibility for D2 to support the function described at position i in the profile of D2, Fa2 (i), the corresponding bit of the profile of A2 indicating whether this function at position i is used by A2 and Fa4 (i), the corresponding bit of the A4 profile indicating whether this function at position i is used by A2.
  • A2 which are not supported by the terminal or the card.
  • a case of practical use of this scenario typically concerns the so-called "J2ME” technology, where the client application runs in a terminal with a J2ME platform.
  • the practical use case could be for example a Java application (A2) according to the JSR177 specification, allowing communication between the Java terminal and a SIM card supporting advanced functions, the application then being able for example to access cryptographic functions of signature provided by an advanced SIM application (A4).
  • the terminal profile as described in the "SIM Toolkit” environment is extended to include the J2ME functions supported by the terminal.
  • the configuration module must then be able to retrieve the extended profiles associated with the terminal and the SIM card as well as the extended profiles associated with the applications.
  • the concerned Java application (A2) is designed to use a message signature function, as described by the bit placed at "1" indicated by an arrow at the level of byte no. 23 of the application profile A2.
  • the message signing function is provided by the SIM A4 application, which supports this function, as described by the bit set to "1" indicated by an arrow at byte No. 23 of the A4 application profile.
  • the card itself supports this function as shown in its profile.
  • the application of the algorithm described with reference to the third scenario above by the compatibility module then leads to establish a diagnosis of incompatibility for this function between the Java application and the terminal, the latter not supporting the function of message signature concerned, as described by the bit set to "0" indicated by an arrow at octet No. 23 of the terminal profile.
  • the invention therefore enables a mobile operator to know whether an application to be downloaded, either in the SIM card or in the terminal, is compatible with the terminal (and possibly the SIM card). If a diagnosis establishing a functional incompatibility is established, it is then possible to upgrade the functions of the terminal and / or the card and / or disable certain functions of the application.
  • the three main modules for implementing the method of the invention namely the configuration module, the compatibility module and the module They can be implemented and distributed separately, either on the client side, on the SIM card and / or the mobile terminal, on the server side, or on the client and server side at the same time.
  • the embodiment described with reference to the various scenarios for the comparison of the application and terminal profiles enabling the establishment of the functional compatibility diagnosis is not limited to the mentioned approach based on a comparison of the binary sequences constituting the profiles.
  • the embodiment described refers to profiles whose structure is constituted by sequences of bytes.
  • the application and terminal profiles could have another structure.
  • they could consist of a series of objects classified in trees describing the functions supported, in which case the comparison of the profiles to obtain the functional compatibility diagnosis could be based on an analysis of the object structure type.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Stored Programmes (AREA)
  • Telephone Function (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Complex Calculations (AREA)

Abstract

L'invention concerne un procédé d'évaluation de la compatibilité entre au moins une application (A1, A2, A3, A4) et au moins un dispositif de traitement (D1, D2) 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 (DCT1) parmi des profils associés aux dispositifs décrivant respectivement des fonctions supportées par chaque dispositif et au moins un profil (ACT1) 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.

Description

PROCEDE D'EVALUATION DE LA COMPATIBILITE ENTRE DES APPLICATIONS ET DES DISPOSITIFS DE TRAITEMENT
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.

Claims

REVENDICATIONS
1. Procédé d'évaluation de la compatibilité entre au moins une application (Al, A2, A3, A4) et au moins un dispositif de traitement (Dl, D2) 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 (DCTl) parmi des profils associés aux dispositifs décrivant respectivement des fonctions supportées par chaque dispositif et au moins un profil (ACTl) 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.
2. procédé selon la revendication 1, caractérisé en ce qu'une application étant prévue pour interagir lors de son exécution avec des fonctions supportées par un dispositif de type terminal mobile (Dl), 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.
3. Procédé selon la revendication 2, caractérisé en ce que l'application étant hébergée dans un dispositif de type carte SIM (D2) avec laquelle coopère le terminal mobile (Dl), 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 (DCT2) décrivant les fonctions supportées par ladite carte.
4. Procédé selon les revendication 2 ou 3, caractérisé en ce que 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.
5. Procédé selon la revendication 4, caractérisé en ce que 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.
6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que 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.
7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les profils sont mémorisés et mis à jour dans une table de configuration (20), qui mémorise l'environnement d'exécution associé à chaque application et les liens existant entre chaque application pour leur exécution.
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend le déclenchement d'actions spécifiques selon le diagnostic de compatibilité établi.
9. Procédé selon la revendication 8, caractérisé en ce que 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.
10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est mis en œuvre côté client.
11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il est mis en œuvre côté serveur.
12. Module logiciel d'évaluation de la compatibilité entre au moins une application (Al, A2, A3, A4) et au moins un dispositif de traitement (Dl, D2) hébergeant et/ou exécutant et/ou interagissant avec au moins ladite application, caractérisé en ce qu'il comprend des instructions (10, 40, 50) pour commander l'exécution du procédé selon l'une quelconque des revendications 1 à 11 par un système informatique.
13. Terminal mobile, caractérisé en ce qu'il intègre un module logiciel selon la revendication 12.
14. Carte à puce, caractérisé en ce qu'elle intègre un module logiciel selon la revendication 12.
EP05801408A 2004-11-17 2005-11-04 Procede d'evaluation de la compatibilite entre des applications et des dispositifs de traitement Withdrawn EP1815702A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0412193A FR2878109B1 (fr) 2004-11-17 2004-11-17 Procede d'evaluation de la comptabilite entre des applications et des dispositifs de traitement
PCT/EP2005/055748 WO2006053835A1 (fr) 2004-11-17 2005-11-04 Procede d'evaluation de la compatibilite entre des applications et des dispositifs de traitement

Publications (1)

Publication Number Publication Date
EP1815702A1 true EP1815702A1 (fr) 2007-08-08

Family

ID=34950652

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05801408A Withdrawn EP1815702A1 (fr) 2004-11-17 2005-11-04 Procede d'evaluation de la compatibilite entre des applications et des dispositifs de traitement

Country Status (6)

Country Link
US (1) US20090124251A1 (fr)
EP (1) EP1815702A1 (fr)
JP (1) JP2008521107A (fr)
CN (1) CN101099400A (fr)
FR (1) FR2878109B1 (fr)
WO (1) WO2006053835A1 (fr)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006096923A1 (fr) 2005-03-18 2006-09-21 Seeker Wireless Pty Limited Emplacement mobile ameliore
WO2006096922A1 (fr) 2005-03-18 2006-09-21 Seeker Wireless Pty Limited Procédé et système de localisation mobile améliorés
JP2008537667A (ja) 2005-04-08 2008-09-18 シーカー ワイアレス プロプライエタリー リミテッド モバイルの位置検出
RU2008120700A (ru) 2005-10-24 2009-12-10 Сикер Уайрлесс Пти Лимитед (Au) Управление поддержкой мобильных услуг
US20080027945A1 (en) * 2006-07-28 2008-01-31 Nichols Paul H Methods, systems and computer program products for downloading a Java application based on identification of supported classes
CA2659826C (fr) 2006-09-07 2013-08-13 Nokia Corporation Gestion d'informations se rapportant a des applications de module securise
WO2008055302A1 (fr) * 2006-11-07 2008-05-15 Seeker Wireless Pty Limited Fourniture de services mobiles améliorée
JPWO2008087729A1 (ja) * 2007-01-18 2010-05-06 三菱電機株式会社 アプリケーション設定端末、アプリケーション実行端末及び設定情報管理サーバ
EP3211553B1 (fr) 2007-01-31 2019-03-06 Nokia Technologies Oy Gestion d'applications apparentées à des modules sécurisés
WO2009036497A1 (fr) 2007-09-17 2009-03-26 Seeker Wireless Pty Limited Systèmes et procédés pour déclencher des communications vocales et/ou de données selon l'emplacement vers ou depuis des terminaux radio mobiles
WO2009067766A1 (fr) 2007-11-26 2009-06-04 Seeker Wireless Pty Limited Procédés et systèmes pour la création et l'adaptation de zone
WO2009124348A1 (fr) 2008-04-07 2009-10-15 Seeker Wireless Pty Limited Collecte efficace des caractéristiques d'un émetteur sans fil
JP5502865B2 (ja) * 2008-08-08 2014-05-28 エスケープラネット株式会社 端末機とスマートカードとの間のインターフェースシステム及びその方法、そしてこれに適用されるスマートカード
SE0950235L (sv) * 2009-04-09 2010-02-23 Smarttrust Ab Metod för att identifiera en mobiltelefon
WO2010125473A1 (fr) * 2009-04-30 2010-11-04 France Telecom Procédé et système de gestion de système mobile d'exploitation
US8244236B2 (en) 2010-04-29 2012-08-14 Wavemarket, Inc. System and method for aggregating and disseminating mobile device tag data
US8538480B2 (en) * 2010-03-30 2013-09-17 Qualcomm Incorporated Methods and apparatus for device applet management on smart cards
US8504077B2 (en) 2010-12-04 2013-08-06 Wavemarket, Inc. System and method for monitoring and disseminating mobile device location information
EP2461613A1 (fr) * 2010-12-06 2012-06-06 Gemalto SA Procédés et système pour la manipulation de données d'une UICC
CN102111749B (zh) * 2011-02-18 2014-05-07 宇龙计算机通信科技(深圳)有限公司 推送定制应用的方法以及服务器和移动终端
US9459863B2 (en) 2013-10-11 2016-10-04 Google Inc. System for assessing an application for tablet compatibility and quality
JP5766309B2 (ja) * 2014-01-06 2015-08-19 ノキア コーポレイション セキュアモジュールアプリケーションに関連する情報の管理
US9973921B2 (en) * 2015-03-27 2018-05-15 Nvidia Corporation Conflict detection
US10311500B2 (en) * 2016-09-01 2019-06-04 Facebook, Inc Methods and systems for developer onboarding for software-development products
US20180205818A1 (en) * 2017-01-13 2018-07-19 Qualcomm Incorporated Mechanism for indicating transport infrastructure compatibility to contactless application installers

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63196936A (ja) * 1987-02-10 1988-08-15 Nec Corp プログラム起動チエツク方式
JPH09190404A (ja) * 1996-01-11 1997-07-22 Sony Corp 電子回路カード装置及び接続状態の認識方法
DE19816575A1 (de) * 1997-11-28 1999-01-28 Mannesmann Ag Verfahren zum endgeräteseitigen Abwickeln mindestens eines auf eine Spezialapplikation, insbesondere auf einen Verkehrstelematikdienst bezogenen Vorgangs und Karte zum Durchführen des Verfahrens
JP3578266B2 (ja) * 2000-01-06 2004-10-20 インターナショナル・ビジネス・マシーンズ・コーポレーション アプリケーションの起動方法、アプリケーションの起動のためのソフトウエア・プロダクト
CA2345852C (fr) * 2000-05-02 2008-11-18 Honda Giken Kogyo Kabushiki Kaisha Pile a combustible avec compose pour etancheifier une membrane d'electrolyte polymere solide
WO2001093613A1 (fr) * 2000-05-26 2001-12-06 Cegetel Sa Procede de dialogue entre un module d'identification d'abonne, cooperant avec un terminal au sein d'un radiotelephone, et un dispositif local
FR2810841B1 (fr) * 2000-06-22 2005-07-29 Bull Cp8 Procede pour le traitement et la transmission de donnees numeriques sur un reseau de telephonie mobile, notamment a la norme "gsm", et systeme embarque a puce electronique
US20020095312A1 (en) * 2000-09-22 2002-07-18 Tammy Wheat Facilitating realtime information interexchange between a telecommunications network and a service provider
TW480762B (en) * 2001-02-15 2002-03-21 Asia Pacific Fuel Cell Tech Modulized battery single cell and modulized battery unit of a proton exchange membrane fuel cell
ATE383038T1 (de) * 2003-08-01 2008-01-15 Research In Motion Ltd Verfahren und vorrichtungen zur initialisierung eines teilnehmeridentifizierungsmodul
DK1680720T3 (da) * 2003-11-07 2012-05-07 Telecom Italia Spa Fremgangsmåde og system til autentificering af en bruger af et databehandlingssystem

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006053835A1 *

Also Published As

Publication number Publication date
US20090124251A1 (en) 2009-05-14
FR2878109A1 (fr) 2006-05-19
WO2006053835A1 (fr) 2006-05-26
CN101099400A (zh) 2008-01-02
FR2878109B1 (fr) 2007-02-02
JP2008521107A (ja) 2008-06-19

Similar Documents

Publication Publication Date Title
EP1815702A1 (fr) Procede d'evaluation de la compatibilite entre des applications et des dispositifs de traitement
JP2008521107A5 (fr)
EP3395089B1 (fr) Module d'identite de souscripteur embarque comprenant des profils de communication.
EP3542563B1 (fr) Installation d'un profil dans un module d'identité de souscripteur embarque
EP3648490A1 (fr) Gestion de profils d'abonne simultanement actifs dans une carte euicc en utilisant plusieurs liaisons distinctes
EP3395090B1 (fr) Procede de controle d'un module d'identite de souscripteur embarque
FR2800963A1 (fr) Procede de mise a jour d'un programme principal execute par un module de radiocommunication et/ou de donnees associees a ce programme principal, et module de radiocommunication correspondant
EP3531729B1 (fr) Configuration d'un module d'identité de souscripteur embarqué
FR2904748A1 (fr) Procede et dispositif de personnalisation definitive d'un terminal de radiocommunication, terminal, carte sim, serveur, produit programme d'ordinateur et moyen de stockage correspondants
FR2892837A1 (fr) Telechargement de donnees dans des objets communicants portables presents dans un reseau de radiocommunications pendant une campagne
WO2015092307A1 (fr) Procédé de test et de mise à jour du système d'un terminal par un module d'identité de souscripteur et dispositifs associés
FR2822627A1 (fr) Module de radiocommunication hebergeant et executant un logiciel client, et procede correspondant de mise en oeuvre d'un logiciel client de pilotage
FR2905819A1 (fr) Procede de gestion de l'architecture logicielle d'un circuit de radiocommunication,application,produit programme d'ordinateur et circuit correspondants.
WO2015150689A1 (fr) Procede de configuration securisee d'une application dans un terminal utilisateur
EP2793498B1 (fr) Elément sécurisé pour terminal de télécommunications
EP2936769B1 (fr) Gestion de l'accès a une pluralité de modules sécurité incorporés dans un dispositif de traitement de données
FR3037753A1 (fr) Procede et systeme ameliores de selection d'une application par defaut dans un element securise
FR3037685A1 (fr) Procede et systeme ameliores de selection implicite d'une application dans un element securise, a partir d'un message recu
FR3059196A1 (fr) Procede de gestion des acces a une infrastructure de telecommunication, produit programme d'ordinateur et infrastructure associes
WO2003030572A1 (fr) Module de radiocommunication executant un logiciel principal dont les couches basses sont ouvertes a un logiciel client egalement execute par le module
EP3000224A1 (fr) Procédé d'auto-adaptation d'une qualité de signal, dispositifs et programme d'ordinateur correspondants
WO2021019162A1 (fr) Adaptation dynamique d'un environnement d'exécution d'élément sécurisé à des profils
WO2008025853A2 (fr) Procédé de contrôle à distance d'un terminal de radiocommunication
FR3080508A1 (fr) Procede de gestion des acces a une infrastructure de telecommunication par un modem et dispositifs associes
EP2073510A1 (fr) Procédé d'enrichissement d'un annuaire électronique provoqué par un changement dans le téléphone associé, et dispositif lié

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070618

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20090217

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GEMALTO SA

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/08 20060101AFI20110916BHEP

Ipc: G06F 9/445 20060101ALI20110916BHEP

RTI1 Title (correction)

Free format text: ASSESSING COMPATIBILITY BETWEEN APPLICATIONS AND PROCESSING DEVICES

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120306