EP1815702A1

EP1815702A1 - Method of assessing compatibility between applications and processing devices

Info

Publication number: EP1815702A1
Application number: EP05801408A
Authority: EP
Inventors: Marc Niccolini
Original assignee: Gemplus Card International SA; Gemplus SA
Current assignee: Thales DIS France SA
Priority date: 2004-11-17
Filing date: 2005-11-04
Publication date: 2007-08-08
Also published as: FR2878109B1; WO2006053835A1; US20090124251A1; JP2008521107A; CN101099400A; FR2878109A1

Abstract

The invention relates to a method of assessing compatibility between at least one application (A1, A2, A3, A4) and at least one processing device (D1, D2) that hosts and/or executes and/or interacts with at least said application. The inventive method is characterised in that it comprises a comparison between: (i) at least one profile (DCT1) from among the profiles associated with the devices describing respectively the functions supported by each device and (ii) at least one profile (ACT1) from among the profiles associated with the applications describing respectively the functions used by each application, in order automatically to establish an analysis of the functional compatibility between one or more applications and one or more devices.

Description

METHOD FOR EVALUATING COMPATIBILITY BETWEEN APPLICATIONS AND PROCESSING DEVICES

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"). In the remainder of the description, when the term "SIM card" is used, 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.

Regarding embedded applications, 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).

In this context, today there are several application development technologies.

In particular, the technology called "SIM Toolkit", where the application, called STK application, runs in the SIM card.

In a practical way, a specific piece of software ("cardlet") is implemented in the SIM card of the terminal for the execution of a given function (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. The operation is as follows: the SIM card then sends 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. These can be commands related to SIM-screen dialogs, SIM-keyboard, SIM-radio interface, etc.

The functions provided by this standard make it possible to develop a very large number of distinct applications on the smart card, in order to provide users of so-called "value-added" mobile telephony services. The reader may use the GSM 11.14 standard and the 3GPP standard for more information. At present, the growth of STK technology is limited by the fact that mobile operators deploy by default STK applications using only functions that are certain to be fully supported by the terminals concerned, so as to guarantee compatibility of the applications developed with most of the terminals. Because of these compatibility issues that may arise, operators are reluctant to deploy STK applications with advanced features.

In addition, when a user changes mobile terminal, the mobile operator can not automatically check whether the applications installed in the SIM remain compatible with the new terminal. Similarly, when the user changes the SIM card, 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.

To do this, 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.

In the J2ME runtime environment, when an application uses programming functions or interfaces that are not supported by the terminal, an error occurs and the application is not usable.

In addition, no means are currently provided to the mobile operator to automatically recover an incompatibility or error status.

The aforementioned drawbacks are not limited to the evoked performance environments and meet in the same way in other environments such as for example "Windows Mobile" or "Brew".

Also, it appears that no solution is provided in the state of the art, allowing mobile operators or service providers to automatically know if applications will be fully functionally compatible with processing devices. may host and / or run these applications or simply interact with them. The present invention therefore aims to overcome the aforementioned drawbacks.

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.

According to one embodiment, 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. According to a variant, 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. According to another variant, 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.

According to another variant, said at least one other application being stored in a SIM card with which said terminal cooperates, 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. Advantageously, 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 .

Advantageously, 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.

Preferably, the method comprises triggering specific actions according to the established compatibility diagnosis.

According to one embodiment, 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.

Advantageously, 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.

Finally, the invention relates to a smart card, characterized in that it incorporates a software module according to the invention.

Other characteristics and advantages of the present invention will emerge more clearly on reading the following description given by way of illustrative and nonlimiting example and with reference to the appended figures in which:

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

- Figure 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. In general, 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.

For the following description of an embodiment of the invention, we consider more specifically an assembly consisting of the combination of a mobile terminal and a SIM card with which the terminal cooperates. The invention is however not limited to such a combination of devices.

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. To do this, it is used that 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.

Thus, 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.

For example, according to the 3GPP TS 51.014 v.4.3.0 standard, 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.

It should be noted that if the client device consists of both the mobile terminal and a SIM card, then 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. In the exemplary embodiment, 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.

If the application is linked to another application of the device for its execution, this other application can be stored in the terminal or the SIM card, this information can also be coded in the application profile.

All the functions supported by a terminal (or the SIM card) as well as those used by an application are described in their profiles. The structure of a profile associated with an application and the structure of a profile associated with a terminal (or SIM card) are similar, allowing profiles to be compared partially or fully.

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.

To do this, 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.

Thus, in the example described, 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. Thus, 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).

Once the configuration table is updated, 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 ... Finally, 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.

We will now describe in more detail an embodiment given by way of example, allowing the establishment of a functional compatibility diagnosis by the module 40 according to different scenarios. Thus, in a first scenario corresponding to that described in FIG. 2, 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:

Cl (i) = FdI (i) Fa FaI (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;

FaI (i), the corresponding bit of the Al profile indicating whether this function is used by Al; and © symbolizing the exclusive OR logical operation.

Thus, if at least one position i can be identified such that [(Cl (i) = 1) AND (FdI (i) = O)], then this means that there is a functional incompatibility between D1 and Al for the function corresponding to position i.

According to this scenario, 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.

According to the diagnosis 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. Indeed, 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.

According to this scenario, 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:

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

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 ; Fd2 (i), the bit encoding the possibility for D2 to support the function described at position i in the profile of D2 and Fa3 (i), the corresponding bit of the profile of A3 indicating whether this function at position i is used by A3. So, if at least one position i can be found such that [(Cl (i) = 1) AND (FdI (i) = O)] OR

[(C2 (i) = 1) AND (Fd2 (i) = O)], then this means that there is a functional incompatibility between Dl and

A3 and / or D2 and A3. 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.

According to one embodiment, 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. However, the launch of the compatibility module may be conditioned by other types of events.

In the example of Figure 3, 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. 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 ourselves 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.

Using the configuration example of FIG. 2, 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. However, 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.

According to this scenario, in view of the configuration table, 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:

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

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

C3 (i) = Fd1 (i) Fa Fa4 (i), (l≤i≤n)

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.

Thus, if at least one position i can be found such that: [(Cl (i) = 1) AND (FdI (i) = 0)] OR [(C2 (i) = 1) AND (Fd2 (i) = 0)] OR [(C3 (i) = 1) AND

(FdI (i) = 0)] OR [(C4 (i) = 1) AND (Fd2 (i) == O)], then it means that there is a functional incompatibility between Dl and A2 and / or D2 and A2 and / or D1 and A4 and / or D2 and A4. A functional compatibility diagnosis may be established consisting for example of a list of the functions used by the application

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).

To do this, the terminal profile as described in the "SIM Toolkit" environment is extended to include the J2ME functions supported by the terminal. We then add bytes to the terminal profile, which are dedicated to J2ME functions, as shown in the example of Figure 4. It is the same for the application profiles. 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. In the example of FIG. 4, 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. In addition, 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.

Indeed, the embodiment described refers to profiles whose structure is constituted by sequences of bytes. However, without departing from the scope of the present invention, the application and terminal profiles could have another structure. For example, 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.

Claims

A method for evaluating the compatibility between at least one application (A1, A2, A3, A4) and at least one processing device (D1, D2) hosting and / or executing and / or interacting with at least said application, characterized in that it comprises the comparison between at least one profile (DCT1) among profiles associated with the devices respectively describing functions supported by each device and at least one profile (ACT1) among profiles associated with the applications respectively describing functions used by each application, to automatically establish a functional compatibility diagnosis between one or more applications and one or more devices.

2. Method according to claim 1, characterized in that an application being provided for interacting during its execution with functions supported by a device of the mobile terminal type (D1), 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.

3. Method according to claim 2, characterized in that the application being hosted in a SIM card device (D2) with which cooperates the mobile terminal (D1), the establishment of the functional compatibility diagnosis further comprises the comparison between the profile associated with said application and a profile associated with the SIM card (DCT2) describing the functions supported by said card.

4. Method according to claim 2 or 3, characterized in that 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. other application and the profile associated with said terminal.

5. Method according to claim 4, characterized in that said at least one other application being stored in a SIM card with which cooperates said terminal, the establishment of the compatibility diagnosis further 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.

6. Method according to any one of claims 2 to 5, characterized in that 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 related, which are not supported by the terminal or the card.

7. Method according to any one of the preceding claims, characterized in that the profiles are stored and updated in a configuration table (20), which stores the execution environment associated with each application and the links between each application for their execution.

8. Method according to any one of the preceding claims, characterized in that it comprises the triggering of specific actions according to the compatibility diagnosis established.

9. The method of claim 8, characterized in that the triggering of specific actions comprises an upgrade or devices or a deactivation of the functions used by the application or applications, which are unsupported.

10. Method according to any one of the preceding claims, characterized in that it is implemented on the client side.

11. Method according to any one of claims 1 to 10, characterized in that it is implemented server side.

12. Software module for evaluating the compatibility between at least one application (Al, A2, A3, A4) and at least one processing device (D1, D2) hosting and / or executing and / or interacting with at least said application , characterized in that comprises instructions (10, 40, 50) for controlling the execution of the method according to any one of claims 1 to 11 by a computer system.

13. Mobile terminal, characterized in that it integrates a software module according to claim 12.

14. Smart card, characterized in that it integrates a software module according to claim 12.