WO2009071836A1 - Procédé de gestion de l'interface utilisateur d'un terminal mobile associé à un module de sécurité et terminal mobile associé - Google Patents

Procédé de gestion de l'interface utilisateur d'un terminal mobile associé à un module de sécurité et terminal mobile associé Download PDF

Info

Publication number
WO2009071836A1
WO2009071836A1 PCT/FR2008/052124 FR2008052124W WO2009071836A1 WO 2009071836 A1 WO2009071836 A1 WO 2009071836A1 FR 2008052124 W FR2008052124 W FR 2008052124W WO 2009071836 A1 WO2009071836 A1 WO 2009071836A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
mobile terminal
interface
security module
identifier
Prior art date
Application number
PCT/FR2008/052124
Other languages
English (en)
Inventor
David Picquenot
Ahmad Saif
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Publication of WO2009071836A1 publication Critical patent/WO2009071836A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M19/00—Current supply arrangements for telephone systems
    • H04M19/02—Current supply arrangements for telephone systems providing ringing current or supervisory tones, e.g. dialling tone or busy tone
    • H04M19/04—Current supply arrangements for telephone systems providing ringing current or supervisory tones, e.g. dialling tone or busy tone the ringing-current being generated at the substations

Definitions

  • the present invention relates to the field of telecommunications, and more particularly to the management of applications hosted on a secure element of a mobile terminal.
  • This security module can be a memory module of the terminal or a removable medium (for example a subscriber chip card) inserted in the terminal.
  • contactless applications a number of them may be so-called “contactless” applications. These applications are executed at the request of an external equipment, called “contactless terminal”.
  • HMI human machine interface
  • This program allows for example the execution of a ringtone or the display of a particular wallpaper when the associated application is activated.
  • the parameters (ring type, for example) used by this program are determined by the service provider.
  • the user can not easily change these settings. Thus, he can not configure his terminal to have, for example, the same ringing for all transport applications. To achieve this functionality, it must contact each service provider that has installed a transport application on the security module attached to its handheld and the associated interface program, asking it to download a new interface program containing the parameters. changed.
  • the invention provides a method for managing the user interface of a mobile terminal associated with a security module containing at least one application.
  • this method comprises: a prior step of recording in the mobile terminal at least one interface parameter in association with an application identifier and for at least one user interface function; during the installation of an interface application associated with an application installed on the security module, a step of receiving an identifier of said application; o according to said received application identifier, an association step, a link to said at least one registered parameter in association with said identifier and for the corresponding user interface function; o A backup step in a memory area accessible by the interface application of said association.
  • the interface parameters used for this user interface function correspond to the user's choice. of the mobile terminal without the latter calling on the service provider.
  • the application identifier is an identifier relating to the type of application. This feature allows the user to quickly recognize the type of application for which a transaction is performed. For example, he can configure his mobile terminal to hear a short ring for transport applications and a longer ring for payment applications.
  • the application identifier is the name of the application.
  • the user can choose interface parameters adapted to the application. For example, he can choose a wallpaper by application, for the display of the messages of end of transaction. The display of the wallpaper allows it to be quickly informed of the application used.
  • the application identifier is published in a memory zone of the mobile terminal accessible in writing by the interface application and the reception step is a step of reading said memory zone.
  • the method further comprises, during the installation of an interface application, a step of determining the interface application to be installed.
  • the determining step comprises a step of synchronizing the mobile terminal with the associated security module.
  • the synchronization step comprises a step of comparing information relating to at least one application installed on the security module with information relating to at least one interface application of the mobile terminal. This comparison allows the mobile terminal to determine the interface applications, associated with the applications installed on the security module, which are not installed in the mobile terminal and therefore need to be downloaded.
  • the synchronization step comprises a step of comparing a first value representative of the applications installed on the security module and stored in the security module with a second value representative of the applications installed on the security module stored in the terminal. mobile. This comparison allows the mobile terminal to quickly determine if it has all the application interfaces associated with applications installed on the security module.
  • the invention also relates to a mobile terminal associated with a security module containing at least one application comprising:
  • the invention finally relates to a computer program comprising instructions for: recording in the mobile terminal at least one interface parameter in association with an application identifier, and for at least one user interface function, when installation of an interface application associated with an application installed on the security module:
  • FIG. 1 is a general diagram presenting the context of the invention
  • FIG. 2 is a flowchart illustrating the various steps of the method of the invention
  • FIG. 3 is a block diagram representing a mobile terminal according to the invention
  • FIG. 4 is a diagram illustrating the contents of a first particular memory zone; of the security module according to one embodiment
  • FIG. 5 is a diagram illustrating the content of a second particular memory zone of the security module according to one embodiment.
  • a user has a mobile terminal 100, for example a mobile phone or a PDA (for "Personal Digital Assistant" in English).
  • a mobile terminal 100 for example a mobile phone or a PDA (for "Personal Digital Assistant" in English).
  • This mobile terminal 100 includes a contactless communication module 10 allowing a dialogue between the terminal 100 and a device 200 subsequently called "contactless terminal".
  • the contactless module 10 is for example an NFC-compatible module (for "Near Field Communication” in English).
  • the mobile terminal 100 also includes a secure module 20 which is for example a removable memory card compatible with the specifications of GlobalPlatform (GlobalPlatform Card Specification - version 2.2 March 2006).
  • this module may be a secure memory area of the mobile terminal or a removable medium of another type (for example a SIM or UICC type of subscriber card (for "Universal Integrated Circuit Card”) or a memory card hosting a secure element (SD card, Embedded Secure control ...)).
  • One or more applications have been stored in the memory of the security module 20. Among these applications, one or more are applications that can be used in contactless mode and operate using the contactless module 10.
  • Such an application is, for example, a transport application. This application is then used each time the mobile carrier has his mobile in front of a terminal 200 located at the entrance of the means of transport.
  • the contactless terminal 200 emits a magnetic field.
  • the mobile user When the mobile user is in front of the terminal, his mobile terminal enters the magnetic field emitted by the terminal 200.
  • a dialogue between the application stored on the module 20 and the terminal contactless 200 makes it possible to carry out a transaction.
  • This dialogue between the secure module 20 and the contactless terminal 200 is made via the contactless module 10.
  • the exchange of messages between the contactless module and the secure module is then performed in a conventional manner, for example using the protocol SWP for "Single Wire Protocol" or the S 2 C interface for "Sigln-SigOut-Connection".
  • a number of messages will then be exchanged between the application and the contactless terminal.
  • the mobile terminal also comprises a communication module 30 allowing communication, via a communication network R, with remote servers, for example with an SP service platform or servers SP1, SP2, SP3 service providers.
  • This communication is for example an "OTA" communication (for "Over The Air"), that is to say a conventional wireless communication.
  • the mobile terminal is connected to the network R for a wired telephone line.
  • the user records in the mobile terminal at least one parameter relating to the user interface in association with an application identifier for at least one user interface function (HMI function).
  • HMI function user interface function
  • the mobile terminal receives, when a step E21, an identifier of the application AP1, for example, an identifier indicating that the application AP1 is a transport application.
  • the mobile terminal associates, according to the identifier received in step E21, a link to the parameter recorded during the previous step of recording El.
  • This link is, for example, the address of the ring tone to be used for transport applications.
  • This link is then recorded, during a step E25, in a memory area of the mobile terminal, accessible by the interface application associated with the application APl.
  • the associated interface application launched at the end of the transaction executes the ringing determined by the registered link.
  • the mobile terminal 100 also comprises a microprocessor 12, a rewritable memory 14 (EPROM or EEPROM), a memory zone 15 (ROM or Eprom), a RAM area 16 and a screen 18 and a keyboard 19.
  • a microprocessor 12 a rewritable memory 14 (EPROM or EEPROM), a memory zone 15 (ROM or Eprom), a RAM area 16 and a screen 18 and a keyboard 19.
  • the microprocessor 12 executes a program, recorded in an area of the memory 14 or 15, implementing the steps of the method of the invention.
  • the security module 20 comprises a microprocessor 22, a rewritable memory 24 (EPROM or EEPROM), a memory zone 25 (ROM or Eprom), and a RAM area 26
  • An IP-rated application installed in the memory 14 or 15 of the mobile terminal makes it possible to manage the different applications present on the security module 20 as well as their respective interfaces.
  • this app allows a user of the mobile terminal to easily obtain the list of "contactless" services to which he has subscribed, as well as the associated parameters.
  • This application also provides a list of all the services to which the user can subscribe. In addition, it offers a simplified interface to the user when subscribing to a new service.
  • This IP application is launched each time the user turns on his mobile terminal and / or at the request of the user.
  • This IP application works in association with an application IC installed in the memory 24 or 25 of the security module 20.
  • the application IC manages and stores in a zone ZC of the memory 24 of the security module the LC list of the applications installed on the security module as well as parameters associated with each of the applications.
  • the IP application queries the IC application of the security module to obtain this list.
  • the user uses a configuration menu available on the mobile terminal.
  • this menu is proposed by the IP application.
  • This configuration menu allows him, for example, to choose the ringtone S 1 for transport applications and the ring tone S2 for payment applications. These choices are then recorded in a zone C of the memory 14 of the mobile terminal
  • a default choice is saved when installing the IP application in the mobile device. Thus, if the user does not make a choice, this default choice will be used.
  • the user then wants to install a new contactless application, for example an APl transport application. For this, he chooses the function "adding a new service" proposed on the screen 18 of the mobile terminal 100 by a menu of the IP application. Following this choice, the IP application connects to a remote server managing all services, for example to the SP service platform and gets in return a list of services that can be installed on the mobile terminal 100. This list is displayed on the handheld screen. The user can then select the APl transport application. Its choice is transmitted to the service platform SP which redirects the request to the service provider SP2 managing this application.
  • the SP2 service provider communicates with the IP application via the network R to obtain user data necessary to configure the service, for example a subscription number. Then, it transmits the APl application and an MPI interface application (or "midlet”) associated with this application to the SP service platform.
  • the service platform SP proceeds to download the application AP1 in a memory of the security module 20 associated with its mobile terminal.
  • the download can be done directly by the SP2 service provider.
  • the service platform updates the LC list managed by the IC application of the security module. For this purpose, it transmits to the application IC, via the network R, information concerning the application AP1 that has just been downloaded. In the embodiment described, this information is the URL of the MPI application interface associated with the application AP1, the identifier AID APl application and the name of the service. Following receipt of this information, the IC application of the security module updates its LC list of applications present on the security module.
  • downloading the MPI interface application to the mobile terminal requires a step of synchronizing the IP application with the security module 20. This step described in the following description, is performed following a restart of the IP application and allows it to determine that the MPI interface application must be downloaded.
  • the IP application controls the downloading of the MPI interface application without performing the synchronization step of the IP application with the security module 20.
  • the IP application of the mobile terminal is then addressed to the SP services platform to obtain the download of the MPI interface application (or "midlet") in an area of the memory 14 of the mobile terminal.
  • the IP application requests the MPI application to publish its information, for example by using a "register” command.
  • This command allows the MPI application to publish its information in a shared database (called RMS for "Record Management System”).
  • RMS allows a first application to share data with a second application.
  • This second application must know the name of the first application that exports its RMS database to read published shared information.
  • This principle is used here between the MPI application and the IP application.
  • the MPI application registered in a zone B of the memory 14 of the mobile terminal, accessible to the IP application, the information to be shared, that is to say, information readable by the IP application. More precisely and as illustrated in FIG. 5, this information is recorded in a BMP1 area of the memory B.
  • any other publication method known to those skilled in the art can be used as, for example , sending a local web command.
  • the information published in the BMP1 area by the MPI interface application is: the name N1 of the application AP1, its identifier IdI, its logo L1, an identifier of the type of application T1.
  • the list of published information may contain more items, fewer items, or different items. Nevertheless, since the list of information to be published is also used by the application IC, the list of elements of this list must be determined before compilation of the IP application and transmitted to the service providers likely to download applications in a security module. associated with a mobile terminal containing such an IC application.
  • a list change involves modifying the IP application on the one hand and, on the other hand, forces the service providers of each downloaded application to modify the associated interface application. In step E21 described with reference to FIG.
  • the IP application reads in the shared information zone BMP1 an application identifier.
  • This can be an application-specific IdI, the name of the application or the Tl application type identifier.
  • the application identifier is the Tl type identifier. for example an identifier of the transport type TR.
  • the IP application determines that the ring tone S to be used for this application is stored at the address ADA (address of the ringtone Sl).
  • the IP application associates with the ringing function S, a link to the ringtone assigned to the transport applications. In the embodiment described, this link is the address C (S 5 TR) of the memory C in which the address (ADA) of the ringer Sl has been stored in association with the ringing function S and the identifier of type of application TR.
  • the link is saved in a mobile terminal memory accessible by the IP application and the MPI interface application.
  • this step consists, for the IP application to publish this information in an RMS-based database shared by the IP application and the MPI interface application.
  • This BIP1 memory zone of the mobile terminal represented in FIG. 5, is accessible for reading and writing by the IP application and is accessible only in reading by the MPI interface application. It is not accessible by the other interface applications downloaded to the mobile terminal 100.
  • the list of information published by the IP application to an interface application must be identical for all interface applications.
  • this list includes only the ringing function.
  • Other functions may of course be provided.
  • the list can contain the ringing function, the screen function (for displaying a particular wallpaper), the font size to be used to display messages on the handheld screen, or any other function. interface.
  • the application MPI interface is woken by receiving an event from the contactless module of the mobile indicating that a communication contactless has been established with the APl application and the ringing function must be activated.
  • the MPI interface application then reads in the BIPl zone published by the IP application and accessible by the MPI interface application, the link
  • the configuration saved in the previous step El can be modified.
  • the user using the setup menu can choose the S2 ringtone for transport applications.
  • the address ADA contained in the table C is then replaced by the ADB address of the ring S2.
  • the APl application is activated and accordingly the MPI interface application, the ringing S2 is activated.
  • the interface parameter registered during the configuration step El is the address of a ring.
  • the interface parameter may be another parameter of the interface function user.
  • this parameter can be a value representing the sound level of a ringtone.
  • a plurality of interface parameters may be associated with an application identifier for a user interface function. For example, a first parameter determines the type of ringing (music 1, music 2 ...) and a second parameter determines the sound level of this ring.
  • the address C (S 5 TR) then contains these two parameters.
  • the MPI interface application When executing the MPI interface application and more particularly when calling the user interface function, the MPI interface application then reads in the BIPl zone published by the IP application and accessible by the application of MPI interface, the link C (S 5 TR). The MPI interface application retrieves the two parameters contained at this address C (S 5 TR) and starts the execution of the ring program with these two parameters.
  • the invention has been described with a single user interface function.
  • the invention also applies to the case where several user interface functions are used in association with one or more application identifiers.
  • the interface parameter "ring type” can be associated with the "transport” application identifier for the "ringing" user interface function.
  • the "character size” parameter to the same "transport” identifier for the "display” user interface function.
  • each interface application publishes information in a zone shared by it and the IP application (BMP1, BMP2, etc.) and the IP application publishes information in a zone (BIP1, BIP2, ...) shared with each interface application.
  • the configuration step El makes it possible to associate a parameter with an HMI function and with an application identifier which is a type of application (transport, payment, etc.).
  • the application identifier is for example the name of the application, a logo or any other application identifier published by the interface application.
  • the configuration can also be made from several identifiers; an order of priority among the identifiers to be used must then be defined. For example, the user can choose a ring type common to all payment-type applications except for a particular payment application for which he chooses another type of ringing.
  • the mobile terminal has registered in an area
  • H2 representative of the applications installed on the security module, transmitted by the security module.
  • an IC application of the security module maintains a list of the applications present in the security module. More precisely, this list LC, recorded in a zone ZC of the memory
  • this information is, for example, the storage URL of the application interface associated with the application (that is to say the address for downloading and installing the application). interface application, the application identifier and the name of the service.
  • the IC application calculates, from the data in this table, a value H1 representative of the applications installed on the security module.
  • the value H1 is a digest of the table or is obtained by applying a hash function to the LC table.
  • the value H1 is also stored in the ZC memory of the security module.
  • the IP application When starting the mobile terminal and / or launching the IP application, the IP application is addressed to the IC application of the security module to obtain the value H1 recorded in the security module. The IP application then compares the value H1 with the value H2 stored in the mobile terminal.
  • the application is addressed to the security module to obtain the LC list and compares the information contained in this list with the information stored in the LM list of the mobile terminal. This determines the name of the service for which the interface application was not downloaded.
  • the IP application updates the information of its list LM and replaces in the memory Z the value H2 by the value
  • this method also makes it possible to download all the necessary interface programs when the security module is inserted in another mobile terminal.

Abstract

L'invention se rapporte à un procédé de gestion de l'interface utilisateur d'un terminal mobile (100) associé à un module de sécurité (20) contenant au moins une application. Selon l'invention, ce procédé comprend une étape préalable d'enregistrement dans le terminal mobile d'au moins un paramètre d'interface (ADA) en association avec un identifiant d'application (TR) et pour au moins une fonction d'interface utilisateur (S); et, lors de l'installation d'une application d'interface associée à une application installée sur le module de sécurité, une étape de réception d'un identifiant (TR) de ladite application; une étape d'association, en fonction dudit identifiant d'application reçu; d'un lien (C(S5TR) vers ledit au moins un paramètre (ADA) enregistré en association avec ledit l'identifiant (TR) et pour la fonction d'interface utilisateur correspondante et une étape de sauvegarde dans une zone mémoire (BIPl) accessible par l'application d'interface de ladite association. L'invention concerne également un terminal mobile mettant en œuvre ce procédé.

Description

Procédé de gestion de l'interface utilisateur d'un terminal mobile associé à un module de sécurité et terminal mobile associé
La présente invention se rapporte au domaine des télécommunications, et plus particulièrement à celui de la gestion des applications hébergées sur un élément sécurisé d'un terminal mobile.
La plupart des terminaux mobiles existants permettent, non seulement d'établir des communications téléphoniques, mais également d'exécuter un certain nombre d'applications téléchargées dans un module sécurisé lié au terminal. Ce module de sécurité peut être un module mémoire du terminal ou un support amovible (par exemple une carte à puce d'abonné) inséré dans le terminal.
Parmi les applications présentes sur le module de sécurité, un certain nombre d'entre elles peuvent être des applications dites "sans contact". Ces applications sont exécutées à la demande d'un équipement extérieur, appelé "borne sans contact". Un module spécifique, dit "module sans contact", installé sur le terminal mobile, permet le dialogue entre le module de sécurité et la "borne sans contact".
Le téléchargement de telles applications peut être effectué, via le terminal mobile, entre un serveur d'un fournisseur de services et le module sécurisé. Le fonctionnement de telles applications ne nécessitent généralement pas d'utiliser les fonctions du terminal mobile. Cependant, des fonctions d'interface homme machine (en abrégé "IHM") du terminal mobile peuvent être sollicitées en parallèle de l'exécution d'une application installée sur le module de sécurité. Ceci nécessite l'installation sur le terminal mobile, par le même fournisseur de services, d'un module logiciel (appelé "programme d'interface" ou "application d'interface") associé à l'application.
Ce programme permet par exemple l'exécution d'une sonnerie ou l'affichage d'un fond d'écran particulier lorsque l'application associée est activée.
Les paramètres (type de sonnerie par exemple) utilisés par ce programme sont déterminés par le fournisseur de service. L'utilisateur ne peut pas aisément modifier ces paramètres. Ainsi, il ne peut pas configurer son terminal pour avoir, par exemple, la même sonnerie pour toutes les applications de transport. Pour obtenir cette fonctionnalité, il doit contacter chaque fournisseur de services ayant installé une application de transport sur le module de sécurité lié à son terminal mobile et le programme d'interface associé, en lui demandant de télécharger un nouveau programme d'interface contenant les paramètres modifiés.
La présente invention améliore la situation de l'état de l'art. A cet effet, l'invention vise un procédé de gestion de l'interface utilisateur d'un terminal mobile associé à un module de sécurité contenant au moins une application. Selon l'invention, ce procédé comprend : une étape préalable d'enregistrement dans le terminal mobile d'au moins un paramètre d'interface en association avec un identifiant d'application et pour au moins une fonction d'interface utilisateur; - lors de l'installation d'une application d'interface associée à une application installée sur le module de sécurité, o une étape de réception d'un identifiant de ladite application; o en fonction dudit identifiant d'application reçu, une étape d'association, d'un lien vers ledit au moins un paramètre enregistré en association avec ledit l'identifiant et pour la fonction d'interface utilisateur correspondante; o une étape de sauvegarde dans une zone mémoire accessible par l'application d'interface de ladite association.
Ainsi, lors de l'appel d'une fonction d'interface utilisateur par une application d'interface associée à une application du module de sécurité, les paramètres d'interface utilisés pour cette fonction d'interface utilisateur correspondent au choix de l'utilisateur du terminal mobile sans que celui-ci fasse appel au fournisseur de service.
Selon une caractéristique de réalisation, l'identifiant d'application est un identifiant relatif au type d'application. Cette caractéristique permet à l'utilisateur de reconnaître rapidement le type de l'application pour laquelle une transaction est effectuée. Par exemple, il peut configurer son terminal mobile pour entendre une sonnerie brève pour les applications de type transport et une sonnerie plus longue pour les applications de type paiement.
Selon une autre caractéristique de l'invention, l'identifiant d'application est le nom de l'application. Ainsi, l'utilisateur peut choisir des paramètres d'interface adaptés à l'application. Par exemple, il peut choisir un fond d'écran par application, pour l'affichage des messages de fin de transaction. L'affichage du fond d'écran lui permet ainsi d'être informé rapidement de l'application utilisée.
Dans un mode de réalisation particulier, l'identifiant d'application est publié dans une zone mémoire du terminal mobile accessible en écriture par l'application d'interface et l'étape de réception est une étape de lecture de ladite zone mémoire.
Selon un autre mode de réalisation, le procédé comporte en outre, lors de l'installation d'une application d'interface, une étape de détermination de l'application d'interface à installer. Dans un mode de réalisation particulier, l'étape de détermination comprend une étape de synchronisation du terminal mobile avec le module de sécurité associé.
Avantageusement, l'étape de synchronisation comprend une étape de comparaison d'informations relatives à au moins une application installée sur le module de sécurité avec des informations relatives à au moins une application d'interface du terminal mobile. Cette comparaison permet au terminal mobile de déterminer les applications d'interfaces, associées aux applications installées sur le module de sécurité, qui ne sont pas installées dans le terminal mobile et qui doivent donc être téléchargées
Avantageusement, l'étape de synchronisation comprend une étape de comparaison d'une première valeur représentative des applications installées sur le module de sécurité et stockée dans le module de sécurité avec une deuxième valeur représentative des applications installées sur le module de sécurité stockée dans le terminal mobile. Cette comparaison permet au terminal mobile de déterminer rapidement s'il dispose de l'ensemble des applications d'interfaces associées aux applications installées sur le module de sécurité. L'invention concerne également un terminal mobile associé à un module de sécurité contenant au moins une application comprenant :
- des moyens d'enregistrement d'au moins un paramètre d'interface en association avec un identifiant d'application pour au moins une fonction d'interface utilisateur; des moyens de réception d'au moins un identifiant de ladite application; des moyens d'association, en fonction dudit identifiant d'application reçu, d'un lien vers ledit au moins un paramètre d'interface et pour la fonction d'interface utilisateur correspondante; - des moyens de sauvegarde dans une zone mémoire accessible par l'application d'interface de ladite association.
L'invention concerne enfin un programme d'ordinateur comportant des instructions pour : enregistrer dans le terminal mobile au moins un paramètre d'interface en association avec un identifiant d'application, et pour au moins une fonction d'interface utilisateur, lors de l'installation d'une application d'interface associée à une application installée sur le module de sécurité :
- recevoir un identifiant de ladite application; - associer, en fonction dudit identifiant d'application reçu, un lien vers ledit au moins un paramètre d'interface enregistré en association avec ledit identifiant, et pour la fonction d'interface utilisateur correspondante;
- sauvegarder dans une zone mémoire accessible par l'application d'interface de ladite association; lorsqu'il est exécuté par un terminal mobile.
D'autre particularités et avantages de la présente invention apparaitront dans la description suivante d'un mode de réalisation donné à titre d'exemple non limitatif, en référence aux dessins annexés dans lesquels : - la figure 1 est un schéma général présentant le contexte de l'invention, la figure 2 est un organigramme illustrant les différentes étapes du procédé de l'invention, la figure 3 est un schéma bloc représentant un terminal mobile selon l'invention, - la figure 4 est un schéma illustrant le contenu d'une première zone mémoire particulière du module de sécurité selon un mode de réalisation, la figure 5 est un schéma illustrant le contenu d'une deuxième zone mémoire particulière du module de sécurité selon un mode de réalisation.
En référence à la figure 1, un utilisateur dispose d'un terminal mobile 100, par exemple un téléphone mobile ou un PDA (pour "Personal Digital Assistant" en anglais).
Ce terminal mobile 100 comporte un module de communication sans contact 10 permettant un dialogue entre le terminal 100 et un équipement 200 appelé par la suite "borne sans contact". Le module sans contact 10 est par exemple un module compatible NFC (pour "Near Field Communication" en anglais).
Le terminal mobile 100 comporte également un module sécurisé 20 qui est par exemple une carte à mémoire amovible compatible avec les spécifications de GlobalPlatform (GlobalPlatform Card Spécification - version 2.2 de mars 2006). A titre d'alternative, ce module peut être une zone mémoire sécurisée du terminal mobile ou un support amovible d'un autre type (par exemple une carte d'abonné de type SIM ou UICC (pour "Universal Integrated Circuit Card") ou une carte à mémoire hébergeant un élément sécurisé (SD card, Embeded Secure contrôler ...)). Une ou plusieurs applications ont été stockées dans la mémoire du module de sécurité 20. Parmi ces applications, une ou plusieurs sont des applications qui peuvent être utilisées en mode sans contact et fonctionnent en utilisant le module sans contact 10. Une telle application est, par exemple, une application de transport. Cette application est alors utilisée à chaque fois que le porteur du mobile présente son mobile devant une borne 200 située à l'entrée du moyen de transport.
La borne sans contact 200 émet un champ magnétique. Lorsque l'utilisateur du mobile se présente devant la borne, son terminal mobile entre dans le champ magnétique émis par la borne 200. A l'initiative de la borne sans contact, un dialogue entre l'application stockée sur le module 20 et la borne sans contact 200 permet de réaliser une transaction. Ce dialogue entre le module sécurisé 20 et la borne sans contact 200 est effectué via le module sans contact 10. L'échange des messages entre le module sans contact et le module sécurisé s'effectue alors de façon classique, par exemple en utilisant le protocole SWP pour "Single Wire Protocol" ou l'interface S2C pour "Sigln-SigOut-Connection". En fonction de l'application sélectionnée, un certain nombre de messages vont ensuite être échangés entre l'application et la borne sans contact. Le terminal mobile comporte également un module de communication 30 permettant une communication, via un réseau de communication R, avec des serveurs distants, par exemple avec une plateforme de services SP ou des serveurs SPl, SP2, SP3 de fournisseurs de services. Cette communication est par exemple une communication "OTA" (pour "Over The Air"), c'est-à-dire une communication sans fil classique. A titre d'alternative, le terminal mobile est relié au réseau R pour une ligne téléphonique filaire.
Le procédé conforme à l'invention va maintenant être décrit, en référence à la figure 2.
Lors d'une étape préalable d'enregistrement El, l'utilisateur enregistre dans le terminal mobile au moins un paramètre relatif à l'interface utilisateur en association avec un identifiant d'application pour au moins une fonction d'interface utilisateur (fonction IHM). Par exemple, pour indiquer qu'il souhaite associer une sonnerie déterminée (sonnerie A) aux applications de transport, il enregistre dans le terminal mobile un paramètre relatif à cette sonnerie "A", par exemple l'adresse de cette fonction, en association avec un identifiant d'application de transport et la fonction d'interface utilisateur "sonnerie".
Ultérieurement, suite à l'installation d'une nouvelle application APl, référencée en figure 3, dans le module de sécurité 20 et d'une application d'interface associée à cette application APl dans le terminal mobile, le terminal mobile reçoit, lors d'une étape E21, un identifiant de l'application APl, par exemple, un identifiant indiquant que l'application APl est une application de transport.
Lors de l'étape E23 suivante, le terminal mobile associe, en fonction de l'identifiant reçu à l'étape E21, un lien vers le paramètre enregistré lors de l'étape préalable d'enregistrement El. Ce lien est, par exemple, l'adresse de la sonnerie à utiliser pour les applications de transport.
Ce lien est ensuite enregistré, lors d'une étape E25, dans une zone mémoire du terminal mobile, accessible par l'application d'interface associée à l'application APl.
Ainsi, lorsqu'une transaction est effectuée par l'application APl, l'application d'interface associée lancée en fin de transaction exécute la sonnerie déterminée par le lien enregistré.
Un mode de réalisation détaillé du terminal selon l'invention va maintenant être décrit.
En référence à la figure 3, le terminal mobile 100 comporte également un microprocesseur 12, une mémoire réinscriptible 14 (EPROM ou EEPROM), une zone mémoire 15 (ROM ou Eprom), une zone mémoire vive 16 ainsi qu'un écran 18 et un clavier 19.
Le microprocesseur 12 exécute un programme, enregistré dans une zone de la mémoire 14 ou 15, mettant en œuvre les étapes du procédé de l'invention. Le module de sécurité 20 comporte un microprocesseur 22, une mémoire réinscriptible 24 (EPROM ou EEPROM), une zone mémoire 25 (ROM ou Eprom), et une zone mémoire vive 26
Une application notée IP installée dans la mémoire 14 ou 15 du terminal mobile, permet de gérer les différentes applications présentes sur le module de sécurité 20 ainsi que leurs interfaces respectives. Par exemple, cette application permet à un utilisateur du terminal mobile d'obtenir facilement la liste des services "sans contact" auxquels il a souscrit, ainsi que les paramètres associés. Cette application permet également d'obtenir la liste de l'ensemble des services auxquels l'utilisateur peut souscrire. De plus, elle offre une interface simplifiée à l'utilisateur lors de la souscription à un nouveau service.
Cette application IP est lancée à chaque fois que l'utilisateur met en marche son terminal mobile et/ou à la demande de l'utilisateur.
Cette application IP fonctionne en association avec une application IC installée dans la mémoire 24 ou 25 du module de sécurité 20. L'application IC gère et stocke dans une zone ZC de la mémoire 24 du module de sécurité la liste LC des applications installées sur le module de sécurité ainsi que des paramètres associés à chacune des applications.
Lorsqu'un utilisateur du terminal mobile demande, à l'aide d'un menu proposé par l'application IP, la liste des applications présentes, l'application IP interroge l'application IC du module de sécurité pour obtenir cette liste.
Lors de l'étape préalable El de configuration, l'utilisateur utilise un menu de configuration disponible sur le terminal mobile. Dans ce mode de réalisation, ce menu est proposé par l'application IP.
Ce menu de configuration lui permet par exemple de choisir la sonnerie S 1 pour les applications de transport et la sonnerie S2 pour les applications de paiement. Ces choix sont ensuite enregistrés dans une zone C de la mémoire 14 du terminal mobile
100. Par exemple, comme illustré sur la figure 4, une adresse "ADA" de la sonnerie
S 1 qui représente un paramètre d'interface, est stockée en association avec l'identifiant d'application "transport" TR et la fonction d'interface utilisateur "sonnerie" S et l'adresse "ADB" de la sonnerie S2 est stockée en association avec l'identifiant d'application "paiement" P et la fonction d'interface utilisateur "sonnerie" S.
Un choix par défaut est enregistré lors de l'installation de l'application IP dans le terminal mobile. Ainsi, si l'utilisateur n'effectue pas de choix, ce choix par défaut sera utilisé. L'utilisateur souhaite, par la suite, installer une nouvelle application sans contact, par exemple une application de transport APl. Pour cela, il choisit la fonction "ajout d'un nouveau service" proposé sur l'écran 18 du terminal mobile 100 par un menu de l'application IP. Suite à ce choix, l'application IP se connecte à un serveur distant gérant l'ensemble des services, par exemple à la plateforme de services SP et obtient en retour une liste des services pouvant être installés sur le terminal mobile 100. Cette liste est affichée sur l'écran du terminal mobile. L'utilisateur peut alors sélectionner l'application de transport APl. Son choix est transmis à la plateforme de services SP qui redirige la demande vers le fournisseur de services SP2 gérant cette application. Si nécessaire, le fournisseur de services SP2 dialogue avec l'application IP, via le réseau R, pour obtenir des données de l'utilisateur nécessaires pour configurer le service, par exemple un numéro d'abonnement. Puis, il transmet l'application APl ainsi qu'une application d'interface (ou "midlet") MPI, associée à cette application, à la plateforme de services SP.
De façon connue, la plateforme de services SP procède au téléchargement de l'application APl dans une mémoire du module de sécurité 20 associé à son terminal mobile.
A titre d'alternative, le téléchargement peut être effectué directement par le fournisseur de services SP2.
Le téléchargement de l'application APl terminé, la plateforme de services met à jour la liste LC gérée par l'application IC du module de sécurité. Pour cela, elle transmet à l'application IC, via le réseau R, des informations concernant l'application APl venant d'être téléchargée. Dans le mode de réalisation décrit, ces informations sont l'adresse URL de l'application d'interface MPI associée à l'application APl, l'identifiant AID de l'application APl et le nom du service. Suite à la réception de ces informations, l'application IC du module de sécurité met à jour sa liste LC des applications présentes sur le module de sécurité.
Dans ce mode de réalisation, le téléchargement de l'application d'interface MPI dans le terminal mobile nécessite une étape de synchronisation de l'application IP avec le module de sécurité 20. Cette étape décrite dans la suite de la description, est réalisée suite à un redémarrage de l'application IP et permet à celle-ci de déterminer que l'application d'interface MPI doit être téléchargée.
A titre d'alternative, l'application IP commande le téléchargement de l'application d'interface MPI sans réaliser l'étape de synchronisation de l'application IP avec le module de sécurité 20.
L'application IP du terminal mobile s'adresse alors à la plateforme de services SP pour obtenir le téléchargement de l'application d'interface (ou "midlet") MPI dans une zone de la mémoire 14 du terminal mobile. Suite à l'installation de cette application MPI dans le terminal mobile, l'application IP demande à l'application MPI de publier ses informations, par exemple en utilisant une commande "register". Cette commande permet à l'application MPI de publier dans une base partagée (appelée RMS pour " Record Management System") ses informations. RMS est un mécanisme décrit dans les spécifications MIDP (pour "Mobile Information Device Profile") émises par le JCP (Java Community Process) (http ://jcp .org/en/j sr/detail?id= 118). RMS permet a une première application de partager des données avec une seconde application. Cette seconde application doit connaître le nom de la première application qui exporte sa base RMS pour y lire les informations partagées publiées. Ce principe est utilisé ici entre l'application MPI et l'application IP. L'application MPI inscrit dans une zone B de la mémoire 14 du terminal mobile, accessible à l'application IP, les informations à partager, c'est-à-dire des informations accessibles en lecture par l'application IP. Plus précisément et comme illustré sur la figure 5, ces informations sont enregistrées dans une zone BMPl de la mémoire B. A titre d'alternative, toute autre méthode de publication connue de l'homme de l'art peut être utilisée comme, par exemple, l'envoi d'une commande web locale.
Dans le mode de réalisation décrit, les informations publiées dans la zone BMPl par l'application d'interface MPI sont : le nom Nl de l'application APl, son identifiant IdI, son logo Ll, un identifiant de type d'application Tl. A titre d'alternative, la liste des informations publiées peut contenir plus d'éléments, moins d'éléments ou des éléments différents. Néanmoins, la liste des informations à publier étant également utilisée par l'application IC, la liste des éléments de cette liste doit être déterminée avant compilation de l'application IP et transmise aux fournisseurs de service susceptibles de télécharger des applications dans un module de sécurité associé à un terminal mobile contenant une telle application IC. Un changement de liste implique de modifier l'application IP d'une part et d'autre part oblige les fournisseurs de services de chaque application téléchargée à modifier l'application d'interface associée. A l'étape E21 décrite en référence à la figure 2, l'application IP lit dans la zone d'information partagée BMPl un identifiant d'application. Cela peut être un identifiant IdI propre à l'application, le nom de l'application ou encore l'identifiant de type d'application Tl. Dans l'exemple décrit ici, l'identifiant d'application est l'identifiant de type Tl par exemple un identifiant de type transport TR. Par lecture des informations de configuration stockées dans la mémoire C, l'application IP détermine que la sonnerie S à utiliser pour cette application est enregistrée à l'adresse ADA (adresse de la sonnerie Sl). Lors de l'étape E23 décrite à la figure 2, l'application IP associe alors à la fonction sonnerie S, un lien vers la sonnerie attribuée aux applications de transport. Dans le mode de réalisation décrit, ce lien est l'adresse C(S5TR) de la mémoire C dans laquelle l'adresse (ADA) de la sonnerie Sl a été stockée en association avec la fonction sonnerie S et l'identifiant de type d'application TR.
Lors de l'étape E25 suivante, le lien est sauvegardé dans une mémoire du terminal mobile accessible par l'application IP et par l'application d'interface MPI. Dans ce mode de réalisation, cette étape consiste, pour l'application IP à publier ces informations dans une base de type RMS, partagée par l'application IP et par l'application d'interface MPI. Cette zone mémoire BIPl du terminal mobile, représentée sur la figure 5, est accessible en lecture et en écriture par l'application IP et n'est accessible qu'en lecture par l'application d'interface MPI. Elle n'est pas accessible par les autres applications d'interface téléchargées sur le terminal mobile 100. La liste des informations publiées par l'application IP à destination d'une application d'interface doit être identique pour toutes les applications d'interface.
Dans le mode de réalisation décrit ici cette liste ne comprend que la fonction sonnerie. D'autres fonctions peuvent bien évidemment être prévues. La liste peut par exemple contenir la fonction sonnerie, la fonction écran (permettant d'afficher un fond d'écran particulier), la taille de la police de caractères à utiliser pour afficher des messages sur l'écran du terminal mobile ou toutes autres fonctions d'interface.
Cette liste des fonctions doit être déterminée à l'avance. En effet, une modification de cette liste entraîne une modification d'une part de l'application IP et d'autre part, de chaque application d'interface associée à une application installée sur le module de sécurité du terminal mobile.
Dans une phase ultérieure, par exemple suite à l'exécution d'une transaction par l'application APl, l'application d'interface MPI est réveillée par la réception d'un événement provenant du module sans contact du mobile indiquant qu'une communication sans contact a été établie avec l'application APl et la fonction sonnerie doit être activée. L'application d'interface MPI lit alors dans la zone BIPl publiée par l'application IP et accessible par l'application d'interface MPI, le lien
C(S5TR). Ce lien étant une adresse mémoire, l'application d'interface récupère l'adresse ADA contenue à cette adresse C(S5TR) et exécute le programme de sonnerie située à l'adresse ADA, c'est-à-dire la sonnerie S 1.
A tout moment, lorsque l'utilisateur le souhaite, la configuration enregistrée lors de l'étape préalable El peut être modifiée. Par exemple, l'utilisateur, à l'aide du menu de configuration peut choisir la sonnerie S2 pour les applications de transport. L'adresse ADA contenue dans le tableau C est alors remplacée par l'adresse ADB de la sonnerie S2. Lorsque l'application APl est activée et en conséquence l'application d'interface MPI, la sonnerie S2 est activée.
Dans le mode de réalisation décrit, le paramètre d'interface enregistré lors de l'étape de configuration El est l'adresse d'une sonnerie. A titre d'alternative, le paramètre d'interface peut être un autre paramètre de la fonction d'interface utilisateur. Par exemple, ce paramètre peut être une valeur représentant le niveau sonore d'une sonnerie.
Dans un autre mode de réalisation, plusieurs paramètres d'interface peuvent être associés à un identifiant d'application pour une fonction d'interface utilisateur. Par exemple, un premier paramètre détermine le type de la sonnerie (musique 1, musique 2...) et un deuxième paramètre détermine le niveau sonore de cette sonnerie. L'adresse C(S5TR) contient alors ces deux paramètres. Lors de l'exécution de l'application d'interface MPI et plus particulièrement lors de l'appel de la fonction d'interface utilisateur, l'application d'interface MPI lit alors dans la zone BIPl publiée par l'application IP et accessible par l'application d'interface MPI, le lien C(S5TR). L'application d'interface MPI récupère les deux paramètres contenus à cette adresse C(S5TR) et lance l'exécution du programme de sonnerie avec ces deux paramètres.
L'invention a été décrite avec une seule fonction d'interface utilisateur. L'invention s'applique également au cas où plusieurs fonctions d'interface utilisateur sont utilisées en association avec un ou plusieurs identifiant d'application. Par exemple, lors de l'étape El de configuration, on peut associer d'une part le paramètre d'interface "type de sonnerie" à l'identifiant d'application "transport" pour la fonction d'interface utilisateur "sonnerie" et d'autre part le paramètre "taille des caractères" au même identifiant "transport" pour la fonction d'interface utilisateur "affichage". Lors de cette même étape ou dans un autre mode de réalisation, on peut également associer le paramètre "logo" à l'identifiant d'application "paiement" pour la fonction d'interface utilisateur "affichage" pour afficher un logo enregistré par l'utilisateur lors de chaque transaction de paiement.
L'invention a été décrite avec un module de sécurité contenant une seule application sans contact. Elle s'applique également au cas où plusieurs applications avec ou sans contact sont installées sur le module de sécurité. Dans ce cas, autant d'applications d'interface que d'applications ont été chargées dans la mémoire du terminal mobile. Comme illustré figure 5, chaque application d'interface publie des informations dans une zone partagée par elle et l'application IP (BMP1,BMP2,...) et l'application IP publie des informations dans une zone (BIP1,BIP2,...) partagée avec chaque application d'interface.
Dans le mode de réalisation décrit, l'étape de configuration El permet d'associer un paramètre à une fonction d'IHM et à un identifiant d'application qui est un type d'application (transport, paiement, ... ) .
Dans un autre mode de réalisation, l'identifiant d'application est par exemple le nom de l'application, un logo ou tout autre identifiant d'application publié par l'application d'interface.
La configuration peut également s'effectuer à partir de plusieurs identifiants; un ordre de priorité parmi les identifiants à utiliser doit alors être défini. Par exemple, l'utilisateur peut choisir un type de sonnerie commun à toutes les applications de type paiement sauf pour une application de paiement particulière pour lequel il choisit un autre type de sonnerie.
Un procédé de synchronisation entre le terminal mobile 100 et le module de sécurité 20 va maintenant être décrit.
Lors d'une utilisation précédente, le terminal mobile a enregistré dans une zone
Z de la mémoire 14 du terminal mobile, la liste LM des applications d'interface téléchargées dans ce terminal. Il a également enregistré dans cette zone Z une valeur
H2 représentative des applications installées sur le module de sécurité, transmise par le module de sécurité.
D'autre part, comme décrit précédemment, une application IC du module de sécurité maintient à jour une liste des applications présentes dans le module de sécurité. Plus précisément, cette liste LC, enregistrée dans une zone ZC de la mémoire
24, est un tableau contenant pour chaque application téléchargée dans le module de sécurité, des informations relatives à cette application. Dans le mode de réalisation décrit, ces informations sont, par exemple, l'URL de stockage de l'application d'interface associée à l'application (c'est-à-dire l'adresse permettant de télécharger et d'installer l'application d'interface, l'identifiant de l'application et le nom du service.
Lors de chaque modification de ce tableau LC, l'application IC calcule, à partir des données de ce tableau, une valeur Hl représentative des applications installées sur le module de sécurité. Par exemple, la valeur Hl est un condensé du tableau ou est obtenue par application d'une fonction de hachage au tableau LC.
La valeur Hl est également enregistrée dans la mémoire ZC du module de sécurité. Lors du démarrage du terminal mobile et/ou du lancement de l'application IP, l'application IP s'adresse à l'application IC du module de sécurité pour obtenir la valeur Hl enregistrée dans le module de sécurité. L'application IP compare ensuite la valeur Hl avec la valeur H2 stockée dans le terminal mobile.
Si ces valeurs ne sont pas identiques, cela signifie que le terminal mobile et le module de sécurité ne sont pas synchronisés, c'est-à-dire qu'au moins un programme d'interface associé à une des applications n'est pas téléchargé dans le terminal mobile, et une procédure de synchronisation est exécutée.
Pour cela, l'application s'adresse au module de sécurité pour obtenir la liste LC et compare les informations contenues dans cette liste avec les informations stockées dans la liste LM du terminal mobile. Elle détermine ainsi le nom du service pour lequel l'application d'interface n'a pas été téléchargée. L'application IP met à jour les informations de sa liste LM et remplace dans la mémoire Z la valeur H2 par la valeur
Hl. Puis, à l'aide de l'URL de l'application d'interface lue dans la liste LC, elle commande le téléchargement de ce programme d'interface. Dans le cas où le module de sécurité est amovible, ce procédé permet également de télécharger l'ensemble des programmes d'interface nécessaires lorsque le module de sécurité est inséré dans un autre terminal mobile.

Claims

REVENDICATIONS
1. Procédé de gestion de l'interface utilisateur d'un terminal mobile (100) associé à un module de sécurité (20) contenant au moins une application caractérisé en ce qu'il comprend : une étape préalable d'enregistrement (El) dans le terminal mobile d'au moins un paramètre d'interface (ADA) en association avec un identifiant d'application (TR) et pour au moins une fonction d'interface utilisateur (S); - lors de l'installation d'une application d'interface associée à une application
(APl) installée sur le module de sécurité, o une étape de réception (E21) d'un identifiant (TR) de ladite application; o en fonction dudit identifiant d'application reçu, une étape d'association (E23) d'un lien (C(S5TR) vers ledit au moins un paramètre (ADA) enregistré en association avec ledit l'identifiant (TR) et pour la fonction d'interface utilisateur correspondante; o une étape de sauvegarde (E25) dans une zone mémoire (BIPl) accessible par l'application d'interface de ladite association.
2. Procédé selon la revendication 1 caractérisé en ce que l'identifiant d'application est un identifiant relatif au type d'application.
3. Procédé selon la revendication 1 caractérisé en ce que l'identifiant d'application est le nom de l'application.
4. Procédé selon l'une des revendications précédentes dans lequel l'identifiant d'application est publié dans une zone mémoire (BMPl) du terminal mobile accessible en écriture par l'application d'interface et dans lequel l'étape de réception est une étape de lecture de ladite zone mémoire.
5. Procédé de gestion selon l'une des revendications précédentes caractérisé en qu'il comporte en outre, lors de l'installation d'une application d'interface, une étape de détermination de l'application d'interface à installer.
6. Procédé selon la revendication 5 dans lequel l'étape de détermination comprend une étape de synchronisation du terminal mobile avec le module de sécurité associé.
7. Procédé selon la revendication 6 dans lequel l'étape de synchronisation comprend une étape de comparaison d'informations relatives à au moins une application installée sur le module de sécurité avec des informations relatives à au moins une application d'interface du terminal mobile.
8. Procédé selon la revendication 6 dans lequel l'étape de synchronisation comprend une étape de comparaison d'une première valeur (Hl) représentative des applications installées sur le module de sécurité et stockée dans le module de sécurité avec une deuxième valeur (H2) représentative des applications installées sur le module de sécurité stockée dans le terminal mobile.
9. Terminal mobile (100) associé à un module de sécurité (20) contenant au moins une application (APl) caractérisé en ce qu'il comprend : des moyens d'enregistrement d'au moins un paramètre d'interface (ADA) en association avec un identifiant d'application (TR) pour au moins une fonction d'interface utilisateur (S); des moyens de réception d'au moins un identifiant (TR) de ladite application, des moyens d'association, en fonction dudit identifiant d'application reçu, d'un lien (C(S5TR) vers ledit au moins un paramètre d'interface (ADA) et pour la fonction d'interface utilisateur correspondante; des moyens de sauvegarde dans une zone mémoire (BIPl) accessible par l'application d'interface de ladite association.
10. Programme d'ordinateur caractérisé en ce qu'il comporte des instructions pour la mise en œuvre des étapes du procédé selon l'une des revendications 1 à 8, lorsqu'il est exécuté par un processeur du terminal mobile.
PCT/FR2008/052124 2007-11-28 2008-11-25 Procédé de gestion de l'interface utilisateur d'un terminal mobile associé à un module de sécurité et terminal mobile associé WO2009071836A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0759382 2007-11-28
FR0759382A FR2924297A1 (fr) 2007-11-28 2007-11-28 Procede de gestion de l'interface utilisateur d'un termninal mobile associe a un module de securite et terminal mobile associe

Publications (1)

Publication Number Publication Date
WO2009071836A1 true WO2009071836A1 (fr) 2009-06-11

Family

ID=39768051

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2008/052124 WO2009071836A1 (fr) 2007-11-28 2008-11-25 Procédé de gestion de l'interface utilisateur d'un terminal mobile associé à un module de sécurité et terminal mobile associé

Country Status (2)

Country Link
FR (1) FR2924297A1 (fr)
WO (1) WO2009071836A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3053148A1 (fr) * 2016-06-23 2017-12-29 Orange Procede et dispositif de gestion d'une application logicielle sur un terminal

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
NOKIA: "Nokia N95 User guide", NOKIA, 2006, XP002498111, Retrieved from the Internet <URL:http://static.tigerdirect.com/pdf/NokiaN95usermanualUS.pdf> [retrieved on 20081001] *
SOFTPEDIA: "Sound Association 3.02", SOFTPEDIA, 26 August 2006 (2006-08-26), XP002498110, Retrieved from the Internet <URL:http://www.softpedia.com/get/System/System-Miscellaneous/Sound-Association.shtml> [retrieved on 20080929] *
SONNENWALD D H ET AL: "InfoSound: an audio aid to program comprehension", 19900102; 19900102 - 19900105, vol. ii, 2 January 1990 (1990-01-02), pages 541 - 546, XP010010509 *

Also Published As

Publication number Publication date
FR2924297A1 (fr) 2009-05-29

Similar Documents

Publication Publication Date Title
JP2014112410A (ja) 電話通信およびデジタルメディアサービスを提供するシステム、方法、および装置
WO2000069191A1 (fr) Terminal radiotelephonique avec une carte a puce dotee d&#39;un navigateur
EP2795878A1 (fr) Procede de partage d&#39;un contenu multimedia entre un deux utilisateurs
FR3039738A1 (fr) Procede de gestion d&#39;un profil enregistre dans un element securise, et element securise correspondant
EP1551193A1 (fr) Procédé de personnalisation automatique d&#39;un terminal mobile en fonction du module d&#39;identification de l&#39;utilisateur et terminal mobile personnalisable
EP1834469B1 (fr) Dispositif de connexion automatique au réseau Internet
WO2009071836A1 (fr) Procédé de gestion de l&#39;interface utilisateur d&#39;un terminal mobile associé à un module de sécurité et terminal mobile associé
US20200304627A1 (en) Incoming Voice Calling Method and Terminal
FR2911751A1 (fr) Procede et installation de telecommunication pour la fourniture d&#39;un service a l&#39;utilisateur d&#39;un equipement personnel, support de donnees correspondant
WO2007042720A2 (fr) Notification de reception de messages asynchrones
EP3035723B1 (fr) Procédé de transmission de données en relation avec une communication
EP2153629A2 (fr) Procede de selection d&#39;une application installee sur un module securise, terminal et module de securite associes
EP1894407B1 (fr) Procede et dispositif de securite pour la gestion d&#39;acces a des contenus multimedias
FR3089372A1 (fr) Procédé et dispositif de gestion d&#39;un réseau domestique.
EP1208519B1 (fr) Systeme et procede de chargement de commandes dans une carte a circuit integre
EP4268441A1 (fr) Procédé de traitement d&#39;une requête d&#39;établissement d&#39;une communication
KR20060118246A (ko) 이동 통신 단말기의 웹 컨텐츠 관리 방법
WO2015128561A1 (fr) Procede et dispositif de decouverte des capacites de communication relatives a un utilisateur d&#39;un terminal
FR2785137A1 (fr) Procede de commande d&#39;un telephone mobile
FR3079711A1 (fr) Procede de gestion d&#39;acces a un contenu numerique.
FR2919142A1 (fr) Procede de controle d&#39;un fournisseur de services a partir d&#39;un terminal mobile
EP1041802A1 (fr) Procédé de gestion de la fonction renvoi d&#39;appel dans un téléphone portable
WO2006075060A1 (fr) Procede de tranfert de message entre deux terminaux de communication
EP1550962A1 (fr) Système et procédé informatiques de chargement de données
EP1662409A1 (fr) Localisation de fichier

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08856350

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08856350

Country of ref document: EP

Kind code of ref document: A1