WO2008081114A2 - Téléphone mobile configurable - Google Patents

Téléphone mobile configurable Download PDF

Info

Publication number
WO2008081114A2
WO2008081114A2 PCT/FR2007/002000 FR2007002000W WO2008081114A2 WO 2008081114 A2 WO2008081114 A2 WO 2008081114A2 FR 2007002000 W FR2007002000 W FR 2007002000W WO 2008081114 A2 WO2008081114 A2 WO 2008081114A2
Authority
WO
WIPO (PCT)
Prior art keywords
software layers
software
mobile phone
mobile telephone
layers
Prior art date
Application number
PCT/FR2007/002000
Other languages
English (en)
Other versions
WO2008081114A3 (fr
Inventor
Eric Baissus
Original Assignee
Open Plug
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 Open Plug filed Critical Open Plug
Priority to EP07871796A priority Critical patent/EP2087423A2/fr
Publication of WO2008081114A2 publication Critical patent/WO2008081114A2/fr
Publication of WO2008081114A3 publication Critical patent/WO2008081114A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/66—Updates of program code stored in read-only memory [ROM]

Definitions

  • the invention relates to a mobile phone.
  • firmware is an ordered set of instructions and data stored in a manner that is functionally independent of a central memory of a telephone.
  • Such software is installed at the factory during the manufacture of the phone, so it must be replaced every time the phone is replaced.
  • a firmware is more generally all the software that does not need to be changed when customizing the phone software level and that cons must be changed when changing from a hardware implementation of the phone to another.
  • the software for low-level control over the radio communication of the phone is considered firmware. In the case where the implementation of the radio changes, this code will have to be modified.
  • Known mobile phones further include applications corresponding to all software providing functionality directly to the user of the mobile phone.
  • An application implements a user interface, which allows the user to control the software and view the result.
  • the user interface for dialing a phone number and launching the call is an application.
  • CMOS complementary metal-oxide-semiconductor
  • mediator software called “middleware” in English and corresponding to all the software that provides services to applications while being code independent of the hardware platform.
  • the same mediator software can be used by several different applications.
  • the mediator software is the set of software that is neither an application nor a part of the firmware.
  • the software in charge of implementing a telephone call requested by the aforementioned application and for this purpose sends a certain number of commands to the firmware controlling the radio interface is a mediator software called the call manager, or " CaII Manager "in English. This software can be used by several applications.
  • the "Contact” application which lists all the persons known by the user of the mobile phone and recorded in the mobile phone, can allow the user, once he has selected a person from his list of contact, call him.
  • the application "Contact” will use the services of the mediator software "CaII Manager”.
  • the interface between the mediator software and the applications will be called high interface.
  • This interface provides applications with the high-level services they need.
  • This interface is independent of the hardware platform of the mobile phone, at equivalent functionality level.
  • the code of the different software layers corresponding to the firmware, the mediator software and the applications is developed, compiled and then assembled so as to form a monoblock image.
  • This monoblock image is then loaded into a memory of the mobile phone to be executed by a processor of the hardware platform of the mobile phone.
  • the code can be modified, recompiled and reloaded, until a final code corresponding to a monoblock image is obtained.
  • the hardware parts of the mobile phone are first assembled, and then the final code is loaded into a memory of the mobile phone. This mobile phone can then be distributed to the customer.
  • this method does not allow a customization of the mobile phone by the user because the creation of the new code requires a complete-cycle-of-development that. is very expensive.
  • the new generated code can only be loaded according to a model corresponding to the model of the original code.
  • the application WO 01/1 1905 describes a mobile phone comprising such a JAVA engine for loading remote JAVA applications.
  • a middleware mediator software is assembled with the firmware in the phone's memory. Therefore, the possibilities of personalization of the mobile phone are limited by the presence of this middleware.
  • an interface engine is loaded at the factory, during the manufacture of the mobile phone. By downloading an interface file, it is then possible, via the interface engine, to modify the user interface.
  • the problem to be solved by the invention is to improve the possibilities of personalization in a mobile phone.
  • a mobile phone including:
  • a first assembled software block stored in the memory said first software block being devoid of high software layers and comprising only, in an assembled form: a firmware including a portion of code, capable, at runtime, of performing a functionality, loading means arranged to load high software layers in said mobile phone; o execution means capable of executing said high software layers subsequent to their loading by said loading means, so as to achieve said functionality.
  • the first software block is thus an assembly of the firmware, loading means and execution means.
  • the mobile phone according to the invention therefore does not include high software layers, and in particular no mediator software at the time of assembly in the form of the first logic code by means of the loading means and the assembled execution means.
  • a mediator software and applications can be loaded and executed in the mobile phone.
  • the mobile phone according to the invention is fully customizable by the loading of high software layers, including a mediator software.
  • said first assembled software block does not comprise high software layers.
  • the software block loaded into the memory of the hardware platform of the telephone already comprises, in a form assembled with the firmware, the mediator software and part or all applications.
  • Such customization is not possible with a telephone of the prior art.
  • the mobile phone since the manufacturing stage, all the low and high layers are assembled, at no time during the manufacturing stage of a mobile phone, the mobile phone does not include a block assembled without software mediator as in the invention.
  • said executing means can be arranged to redirect a call from said high software layers to said code portion of the firmware, so as to perform said functionality.
  • the loading means and the execution means form a low interface of the mobile telephone, that is to say an interface between the firmware and a mediator software.
  • the mediator software is however not assembled with the firmware.
  • said execution means may comprise: a proxy comprising a redirection table arranged so as to redirect said call from said high software layers to said portion of the firmware code.
  • said redirection table comprises a correspondence between functions that can be called by said software layers, and identical functions of the firmware.
  • the loading means comprise an installer arranged to modify function calls of said high software layers so as to direct calls to said proxy. In this way, it is ensured that the proxy will receive the calls to the functions, and can therefore redirect this call to a corresponding part of code in the firmware.
  • said loading means may be able to load said high software layers from a remote device of said mobile telephone by a data transport protocol.
  • said loading means may be able to load said high software layers from a second memory istincte of the first memory, to the first memory.
  • This second memory can be a SIM card or an external memory of the mobile phone.
  • the invention also relates to a system comprising a mobile telephone as previously described and high level assembled log layers comprising at least one software mediator and applications, said high software layers comprising code portions, coding, at runtime, for a call to services of said firmware, said high software layers being able to be executed by said execution means.
  • the invention also relates to a method for executing high software layers on a mobile telephone as described above, comprising steps in which: the high software layers are loaded in the mobile telephone;
  • This method therefore allows a simple personalization of the mobile phone as previously described, the execution being performed by the execution means adapted to redirect a call from the high software layers to the code portion of the firmware, so as to realize a functionality
  • this method may comprise steps in which said high log layers comprise a coding portion for a call to a function corresponding to a firmware service, and wherein:
  • said proxy redirects said call to a portion of code of said coding firmware, at execution, for said service.
  • the invention also relates to a method of manufacturing a mobile phone comprising steps in which: a firmware is developed comprising a piece of code able, at runtime, to perform a function;
  • - Loading means are developed capable of loading high software layers in said mobile phone; developing means capable of executing said high log layers after their loading by said loading means, so as to perform said functionality;
  • the firmware, said loading means and said execution means are assembled to form a first software block, so that said first software block is free of high software layers and only comprises, in an assembled form, the firmware, said means loading and said means of execution; - Loading into a memory of said mobile phone, said first software block.
  • FIG. 1 represents a mobile phone according to one embodiment of the invention
  • FIG. 2 represents a mobile phone according to an embodiment of the invention when a content has been loaded into the phone
  • FIG. 3 shows an engine included in a mobile phone according to one embodiment of the invention
  • FIG. 4 shows a method of executing a feature from a call of the high software layers.
  • FIG. 1 shows a mobile phone 1 according to one embodiment of the invention.
  • This mobile telephone 1 comprises, in a memory, a first assembled software block 6.
  • the first assembled block 6 comprises a firmware 2 and a motor 3 capable of performing in particular the loading and the execution of the high software layers comprising a mediator software and applications.
  • FIG. 2 there is shown the mobile phone 1 of FIG. 1 when the high software layers are loaded.
  • These high software layers may include mediator software 4 and applications 5.
  • the motor 3 is for example a component as described in WO 05/08509.
  • FIG. 3 An exemplary motor 3 according to one embodiment of the invention is illustrated in more detail in FIG. 3.
  • the engine 3 comprises a service controller 7 for providing a number of services to the high software layers 4 and 5 that can be loaded into the mobile phone 1.
  • the service controller 7 comprises one or more interfaces 73, for example of the API type, making it possible to link the motor 3 to the high software layers 4 and 5 that can be loaded into the mobile telephone 1.
  • the service controller also comprises a part of generic code 71 independent of lower layers of the mobile phone platform 1. This part of generic code 71 can therefore not be modified in case of modification of the lower layers of the mobile phone 1.
  • the service controller also comprises a specific code portion 72 dependent on low layers of the mobile phone platform 1. This specific code part 72 will therefore have to be modified in case of modification of the lower layers of the mobile phone 1.
  • the specific code portion 72 and the generic code portion 71 are such that a service associated with the interface 8 may be executed.
  • the interface 73 comprises for example a service for displaying a character on the screen of the mobile phone 1, for example in the form of a function display_car.
  • the motor 3 also comprises a charger 14 able to charge, possibly remotely, the high software layers in the terminal-mob ⁇ e_1 -, - dlen- verify-the-properties and store these high software layers 4 and 5 in the mobile terminal 1 .
  • the engine 3 further comprises a transport protocol controller 9 making it possible to use a transport protocol available on the lower layers of the mobile telephone 1 to perform the loading carried out by the charger 14.
  • This transport protocol is for example a known protocol. TCP / IP, WAP, or FTP type.
  • the data transport may be wired or wireless transport from a remote device capable of transferring data.
  • the engine 3 also includes an installer 10 responsible for installing the high software layers in the memory of the mobile phone 1.
  • the engine 3 also comprises a launcher 8, able to perform the launch of the execution of the high software layers loaded by the loader 14.
  • the launcher 8 is also able to perform all the execution of the high software layers if this execution requires a step interpretation of the code of high software layers by a mobile phone processor 1. In general, the launcher 8 thus allows the execution of the high software layers loaded by the charger 14.
  • the engine 3 includes a proxy 1 1 able to redirect service requests from the high software layers to the services offered by the service controller 7, when the high software layers are running.
  • the proxy 1 1 uses in particular a redirection table linking each service of the interface 73 with the location where this service is located in the low-level log layers of the mobile telephone 1, that is to say in particular -to ⁇ logLciel-2
  • This proxy 1 1 is for example as described in the application WO 05/08509 application under the name PLUG.
  • the proxy 1 1 is arranged to redirect a processor of the mobile phone 1 to the location where the desired service is located in the micrologel 2.
  • the proxy 1 1 comprises for this purpose a switching function, able to take as parameters, the identifiers of the target functions called by the high log layers. These identifiers are stored in a stack or register of the processor so as to ensure the redirection to the corresponding functions of the firmware 2.
  • the proxy switching function 1 1 is performed from a correspondence table between identifiers of the functions called by the high software layers and the addresses of these functions in the firmware 2.
  • the upper software layers 4 and 5 intended to be loaded into the mobile terminal 1 are now described in greater detail by means of, in particular, the charger 14.
  • the high software layers include code to be executed, usable data that can be used by the code, and specific data including for example the list of services used by the high software layers, as well as software layer identification information high. including their origin, version number, or certificate. These specific data are generated by a generator which will be described in more detail later.
  • mediator software 4 applications 5 as well as different parts of an interface with a user are coded in a manner known per se.
  • the code of the high software layers is thus programmed so as not to refer to the low software layers of the mobile terminal 1, but always to the interface 73 of the engine 3.
  • this code is manipulated by a generator.
  • the generator takes as input the source code or object to be included in the high software layers, compiles the different parts of the code, and assembles all the parts of code between them.
  • the generator first replaces the calls to the interface 8 by generic code called STUB.
  • This generic code STUB will be modified by the installer 1 0 of the engine 3 at the installation of the high software layers in the mobile phone 1 to allow the execution of the services on the firmware 2 of the mobile phone 1.
  • the use of a non-specific address of the STUB type makes it possible to detect this type of address and replace it with an input address of the proxy 1 1.
  • ком ⁇ онент ком ⁇ онент ком ⁇ онент ⁇ is replaced by a STUB function of the type stub (STIB).
  • STUB function of the type stub ком ⁇ онент ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
  • the generator uses a standard method of code generation by compilation and assembly well known to those skilled in the art.
  • the generator may also depend on the particularities of the languages supported by the engine 3, in particular C, C ++, JAVA or XM L.
  • the generator adds a certain number of additional information that will be used by the engine 3. For example, the generator will generate the specific data including the list services used by the original code, especially the function affiche_car. It can also add, in this specific data, a certain number of identifiers making it possible to guarantee for example the origin or even the integrity of the high software layers or a version number.
  • the high log layers 4 and / or 5 may also be encrypted.
  • the charger 14 examines, via the transport protocol controller 9, whether there are high software layers to be loaded into a memory of the mobile phone 1.
  • the high software layers may for example be contained in an external memory SIM of the mobile phone 1, or a memory card of the mobile phone 1, or remotely accessible in a database via a transport protocol.
  • This transport protocol can be any data transport protocol, for example Bluetooth, GPRS, WAP, or TC P / I P.
  • a notification is triggered so as to warn a user of the mobile phone 1.
  • This user can then accept or refuse the installation of the high software layers on his mobile terminal 1. If the user decides to accept the installation of the high software layers on his mobile phone 1, these high software layers are first loaded.
  • the loader 14 performs this loading step using one of the transport protocols provided by the transport protocol controller 9.
  • the loader 14 controls certain information of the high software layers to verify their integrity. For example, the loader 14 verifies that the display service required by the high software layers is available at the interface 73 of the motor 3.
  • the loader 14 may also need to request a certain number of certificates or authorizations before authorizing the loading of the high software layers.
  • the loading may in particular be authorized only in terms of a payment or the completion of a financial transaction. It may also be allowed only after verification of the rights of the user of the mobile phone 1 on the high log layers to be loaded.
  • the charger 14 then performs the loading of the high software layers.
  • the high software layers are then stored in an execution memory of the mobile phone 1 in a format executable by the engine 3 and in particular the launcher 8.
  • the storage in the executable format by the engine 3 can be carried out either in a just-in-time flow. download, once the load is complete.
  • the installer 1 0 is able to modify the STU B functions of the software layers so that the call to these functions STU B during execution translates into a call to proxy 1 1. To do this, the STUB function is redirected to the entry point of a proxy function of engine 3.
  • the proxy 1 1 which is actually called.
  • the proxy function char_display
  • this proxy function (char_display) will then be redirected to a displayed function because of the low software layers and in particular of the firmware 2.
  • New high software layers can then be loaded into the mobile phone 1 by the method as previously described.
  • the mediator software 5 has been previously loaded into the mobile phone 1.
  • the mediator software comprises a piece of code 12 encoding, at runtime, for a call to a function corresponding to a service that can only be provided by the firmware 2.
  • this function is implemented in the mediator software 5 in the form of a generic function STLJ B.
  • the installer 10 detects the STUB function corresponding to the code portion 12.
  • the installer 10 redirects then this function STU B to a proxy entry 1 1.
  • the proxy 1 via a redirection table, transforms this call into a call to an equivalent function 13 of the firmware 2 so as to perform the service corresponding to the called function.
  • the mobile phone 1 can in particular be marketed by a mobile phone manufacturer at a lower cost, the personalization of the telephone being performed subsequently by a user of the mobile phone 1 by loading the high software layers 4 and 5.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention se rapporte à téléphone mobile (1) comprenant : Une première mémoire; Un premier bloc logiciel assemblé (6), stocké dans ladite première mémoire, ledit premier bloc logiciel étant dépourvu de couches logiciel hautes et comprenant uniquement, sous une forme assemblée : - un micrologiciel (2) comprenant une partie de code (13), apte, à l'exécution, à réaliser une fonctionnalité, - des moyens de chargement (10, 14) agencés pour charger des couches logicielles hautes (4, 5) dans ledit téléphone mobile (1); - des moyens d'exécution (8, 11) aptes à exécuter lesdites couches logicielles hautes postérieurement à leur chargement par lesdits moyens de chargement, de sorte à réaliser ladite fonctionnalité.

Description

TELEPHONE MOBILE CONFIGURABLE
L'invention se rapporte à un téléphone mobile.
Les téléphones mobiles connus comprennent un micrologiciel, appelé « firmware » en langue anglaise. Un tel micrologiciel est un ensemble ordonné d'instructions et de données stockées d'une façon qui est fonctionnellement indépendante d'une mémoire centrale d'un téléphone. Un tel logiciel est installé à l'usine lors de la fabrication du téléphone, de sorte qu'il doit être remplacé à chaque fois que le téléphone est remplacé.
Dans le cadre de la présente demande, un micrologiciel est plus généralement l'ensemble du logiciel qui n'a pas lieu d'être modifié lorsque l'on personnalise le téléphone au niveau logiciel et qui par contre doit être changé lorsqu'on passe d'une implémentation matérielle du téléphone à une autre. Par exemple, le logiciel permettant de contrôler à bas niveau la communication radio du téléphone est considéré comme un micrologiciel. Dans le cas ou l'implémentation de la radio change, ce code la devra être modifié.
Les téléphones mobiles connus comprennent en outre des applications correspondant à l'ensemble des logiciels fournissant une fonctionnalité directement à l'utilisateur du téléphone mobile.
Une application implémente une interface utilisateur, qui permet à l'utilisateur de commander le logiciel et de visualiser le résultat.
Par exemple, l'interface utilisateur permettant de composer un numéro de téléphone et de lancer l'appel est une application.
Les téléphones mobiles connus comprennent également un logiciel médiateur, appelé « middleware » en langue anglaise et correspondant à l'ensemble du logiciel qui fournit des services aux applications tout en étant du code indépendant de la plateforme matérielle. Un même logiciel médiateur peut être utilisé par plusieurs applications différentes. Typiquement, le logiciel médiateur est l'ensemble du logiciel qui n'est ni une application, ni une partie du micrologiciel. Par exemple, le logiciel en charge de mettre en oeuvre un appel téléphonique demandé par l'application susmentionnée et qui pour cela envoie un certain nombre de commande au micrologiciel contrôlant l'interface radio est un logiciel médiateur appelé le gestionnaire d'appel, ou « CaII Manager » en langue anglaise. Ce logiciel peut être utilisé par plusieurs applications. Par exemple, l'application « Contact », qui liste toutes les personnes connues par l'utilisateur du téléphone mobile et enregistrées dans le téléphone mobile, peut permettre à l'utilisateur, une fois qu'il a sélectionné une personne de sa liste de contact, de l'appeler. Pour cela, l'application « Contact » va utiliser les services du logiciel médiateur « CaII Manager ».
Dans le cadre de la présente demande, on appellera couches logicielles hautes ou couches hautes, l'ensemble comprenant les applications et le logiciel médiateur, et couches logicielles basses, ou couches basses, le micrologiciel.
On appellera interface haute l'interface entre le logiciel médiateur et les applications. Cette interface fournit aux applications les services haut niveau dont elles ont besoin. Cette interface est indépendante de la plateforme matérielle du téléphone mobile, à niveau de fonctionnalité équivalent.
De façon connue en soi, lors de la construction d'un téléphone mobile, le code des différentes couches logicielles correspondant au micrologiciel, au logiciel médiateur et aux applications, est développé, compilées puis assemblées de sorte à former une image monobloc. Cette image monobloc est ensuite chargée dans une mémoire du téléphone mobile afin d'être exécutée par un processeur de la plateforme matérielle du téléphone mobile. Lors d'une phase de test, le code peut être modifié, recompilé et rechargé, jusqu'à obtention d'un code final correspondant à une image monobloc.
Dans l'usine de fabrication des téléphones mobiles, les parties matérielles du téléphone mobile sont d'abord assemblées, puis le code final est chargé dans une mémoire du téléphone mobile. Ce téléphone mobile peut alors être distribué vers la clientèle.
Il est connu de pouvoir modifier les fonctionnalités des logiciels d'un téléphone mobile, et ce, sans avoir à recommencer un développement complet du logiciel.
Afin de modifier les fonctionnalités des logiciels d'un téléphone mobile, on connaît l'existence de paramètres configurables accessibles par l'utilisateur. Les fonctionnalités d'un téléphone mobile peuvent donc être modifiées en modifiant ces paramètres, mais la personnalisation de téléphone mobile associée à cette modification est très restreinte.
Afin de modifier les fonctionnalités des logiciels d'un téléphone mobile, on connaît également le fait de charger dans le téléphone mobile une pluralité de jeux de codes finaux, inclus dans le même code monobloc, que l'utilisateur pourra sélectionner. Toutefois, les configurations sont fixées au moment de la construction du téléphone mobile et ne peuvent donc pas être modifiées par l'utilisateur. Encore une fois, les possibilités de personnalisation par cette méthode de multi-configuration sont donc faibles.
Afin de modifier les fonctionnalités des logiciels d'un téléphone mobile, on connaît également des procédés visant à remplacer l'ensemble du code final par un nouveau code final, par les airs ou par un câble. Pour ce faire, on génère un fichier de différence entre l'ancienne version du code et la nouvelle version du code, et on télécharge ce fichier de différence dans le téléphone mobile. Le nouveau code est alors construit directement à partir de l'ancien code et du fichier de différence à l'aide d'un moteur embarqué. Ce moteur embarqué est un code mis dans le téléphone mobile dès la fabrication du téléphone mobile.
Ce procédé est avantageux dans le cas de corrections de problèmes logiciels, appelés « bugs » en langue anglaise, car il permet de corriger des problèmes sans avoir à demander à l'utilisateur de retourner son téléphone mobile à l'usine.
Toutefois, ce procédé ne permet pas une personnalisation du téléphone mobile par l'utilisateur car la création du nouveau code nécessite-un-cycle-complet de-développement qui. est très coûteux.
Il est donc difficile de produire des versions différentes d'un même code selon différentes demandes.
Par ailleurs, le nouveau code généré ne pourra être chargé que selon un modèle correspondant au modèle du code d'origine.
En outre, un même code ne pourra pas être réutilisé d'un téléphone mobile à un autre si les plateformes matérielles des téléphones mobiles sont différentes.
Afin de modifier les fonctionnalités des logiciels d'un téléphone mobile, on connaît également le fait d'ajouter des applications à un téléphone mobile, en magasin ou via un téléchargement. Pour ce faire, des moteurs, par exemple des moteurs JAVA, sont embarqués dans le téléphone mobile à la fabrication et permettent à l'utilisateur de télécharger des applications JAVA à leur demande. Ces applications de personnalisation sont par exemple des jeux.
Toutefois, dans ce cas, seules les applications d u téléphone mobile peuvent être modifiées. La personnalisation du téléphone mobile est donc limitée.
En particulier, la demande WO 01 /1 1905 décrit un téléphone mobile comprenant un tel moteur JAVA permettant de charger des applications JAVA à distance. Toutefois, lors de l'assemblage d u téléphone mobile, il est clair pour l'homme du métier qu'un logiciel méd iateur « middleware » est assemblé avec le micrologiciel en mémoire du téléphone. Dès lors, les possibilités de personnalisation du téléphone mobile sont limitées par la présence de ce middleware.
-Oruconnaît-ausaLdes-ptocédés_pour— modifierJiinterface utilisateur de téléphone mobile. Pour ce faire, un moteur d'interface est chargé en usine, lors de la fabrication du téléphone mobile. En téléchargeant un fichier d 'interface, il est alors possible, via le moteur d'interface, de modifier l'interface utilisateur.
Toutefois, dans ce cas, seule l' interface utilisateur du téléphone mobile peut être modifiée. La personnalisation du téléphone mobile est donc également limitée.
Le problème que se propose de résoudre l'invention est d'améliorer les possibilités de personnalisation dans un téléphone mobile.
Ce problème est résolu par un téléphone mobile comprenant :
- Une mémoire ;
- Un premier bloc logiciel assemblé, stocké dans lad ite mémoire, ledit premier bloc logiciel étant dépourvu de couches logicielles hautes et comprenant uniquement, sous une forme assemblée : o un micrologiciel comprenant une partie de code, apte, à l'exécution, à réaliser une fonctionnalité, o des moyens de chargement agencés pour charger des couches logicielles hautes dans ledit téléphone mobile ; o des moyens d'exécution aptes à exécuter lesdites couches logicielles hautes postérieurement à leur chargement par lesdits moyens de chargement, de sorte à réaliser ladite fonctionnalité.
Selon l'invention, le premier bloc logiciel est donc un assemblage du micrologiciel, des moyens de chargement et des moyens d'exécution. En particulier, le téléphone mobile selon l'invention ne comprend donc pas de couches logicielles hautes, et notamment pas de logiciel médiateur au moment de l'assemblage sous la forme^du_μremier-_code logicieLJ3râce-aux_moyens de chargement et aux moyens d'exécution assemblé dans le premier code logiciel, un tel logiciel médiateur et des applications pourront être chargés et exécutés dans le téléphone mobile. Le téléphone mobile selon l'invention est donc entièrement personnalisable par le chargement de couches logicielles hautes, et notamment d'un logiciel médiateur.
En particulier, selon l'invention, ledit premier bloc logiciel assemblé ne comprend pas de couches logicielles hautes.
Au contraire, dans les téléphones mobiles connus de l'art antérieur, le bloc logiciel chargé dans la mémoire de la plateforme matérielle du téléphone comprend déjà, sous une forme assemblée avec le micrologiciel, le logiciel médiateur et une partie ou toutes les applications. Une telle personnalisation n'est donc pas possible avec un téléphone de l'art antérieur. Par ailleurs, puisque lors de l'étape de fabrication, l'ensemble des couches basses et hautes sont assemblées, à aucun moment de l'étape de fabrication d'un téléphone mobile, le téléphone mobile ne comprend un bloc assemblé sans logiciel médiateur comme dans l'invention.
Selon un mode de réalisation de l'invention, lesdits moyens d'exécution peuvent être agencés pour rediriger un appel desdites couches logicielles hautes vers ladite partie de code du micrologiciel, de sorte à réaliser ladite fonctionnalité.
Ainsi, une fois les couches logicielles hautes chargées dans le téléphone grâce aux moyens de chargement, des fonctionnalités spécifiques du micrologiciel peuvent être réalisées grâce à la redirection faite par les moyens d'exécution. Une exécution de ces fonctionnalités est donc possible même si les couches logicielles hautes ne sont pas assemblées avec le micrologiciel dans le même blox^LogicLeL-Ceci-permeUdonc-une-personnalisation du téléphone mobile par des couches logicielles hautes, et notamment un logiciel médiateur et des applications, tout en maintenant les fonctionnalités du micrologiciel.
De la sorte, l'utilisateur pourra personnaliser son téléphone mobile avec le logiciel médiateur et les applications de son choix. Le niveau de personnalisation d'un téléphone mobile est donc fortement amélioré selon l'invention.
Selon l'invention, les moyens de chargement et les moyens d'exécution forment une interface basse du téléphone mobile, c'est-à-dire une interface entre le micrologiciel et un logiciel médiateur. Dans le cadre de l'invention, le logiciel médiateur n'est toutefois pas assemblé avec le micrologiciel.
Afin de réaliser la redirection susmentionnée, dans le téléphone mobile, lesdits moyens d'exécution peuvent comprendre : - un proxy comprenant une table de redirection agencée de sorte à rediriger ledit appel desdites couches logicielles hautes vers ladite partie de code du micrologiciel.
Selon un exemple, ladite table de redirection comprend une correspondance entre des fonctions susceptibles d'être appelées par lesdites couches logicielles, et des fonctions identiques dud it micrologiciel.
Afin d'assurer que les appels des couches logicielles hautes seront redirigées vers des fonctions du micrologiciel, les moyens de chargement comprennent un installeur agencé pour modifier des appels de fonctions desdites couches logicielles hautes de sorte à diriger les appels vers ledit proxy. De la sorte, on garantit que le proxy recevra bien les appels aux fonctions, et pourra donc rediriger cet appel vers une partie de code correspondant dans le micπologiciel.
Afin de faciliter la personnalisation du téléphone mobile selon l'invention , lesdits moyens de chargement peuvent être aptes à charger lesdites couches logicielles hautes depuis un équipement distant dud it téléphone mobile par u n protocole de transport de données.
De même lesdits moyens de chargement peuvent être aptes à charger lesdites couches logicielles hautes depuis une deuxième mémoire d istincte de la première mémoire, vers la première mémoire. Cette deuxième mémoire peut être une carte SIM ou une mémoire externe du téléphone mobile.
L'invention se rapporte également à un système comprenant un téléphone mobile tel que précédemment décrit et des couches log icielles hautes assemblées comprenant au moins un logiciel médiateur et des applications, lesdites couches logicielles hautes comprenant des parties de codes, codant, à l'exécution , pour un appel à des services dudit micrologiciel, lesdites couches logicielles hautes étant aptes à être exécutées par lesdits moyens d'exécution.
L'invention se rapporte également à un procédé pour exécuter des couches logicielles hautes sur un téléphone mobile tel que décrit précédemment, comprenant des étapes dans lesquelles : - on charge lesd ites couches logicielles hautes dans le téléphone mobile;
- on exécute lesdites couches logicielles hautes.
En particulier, on peut notamment charger un logiciel médiateur appartenant aux couches logicielles hautes afin de personnaliser le téléphone mobile.
Ce procédé permet donc une personnalisation simple du téléphone mobile tel que précédemment décrit, l'exécution étant réalisée par les moyens d'exécution aptes à rediriger un appel des couches logicielles hautes vers la partie de code du micrologiciel , de sorte à réaliser une fonctionnalité
En particulier, ce procédé peut comprendre des étapes dans lesquelles lesdites couches log icielles hautes comprennent une partie codant pour un appel à une fonction correspondant à un service d udit micrologiciel, et dans lequel :
- ledit appel est redirigé vers led it proxy ;
- ledit proxy redirige ledit appel vers une partie de code dudit micrologiciel codant, à l'exécution, pour ledit service.
L'invention se rapporte également à un procédé de fabrication d'un téléphone mobile comprenant des étapes dans lesquelles : - on développe un micrologiciel comprenant une partie de code apte, à l'exécution, à réaliser une fonctionnalité;
- on développe des moyens de chargement aptes à charger des couches logicielles hautes dans ledit téléphone mobile ; - on développe des moyens d'exécution aptes à exécuter lesdites couches log icielles hautes postérieurement à leur chargement par lesdits moyens de chargement, de sorte à réaliser ladite fonctionnalité ;
- on assemble le micrologiciel, lesdits moyens de chargement et lesdits moyens d'exécution pour former un premier bloc logiciel, de sorte que ledit premier bloc logiciel soit dépourvu de couches logicielles hautes et comprenne uniquement, sous une forme assemblée, le micrologiciel, lesdits moyens de chargement et lesdits moyens d'exécution ; - on charge dans une mémoire dudit téléphone mobile, ledit premier bloc logiciel.
On décrit maintenant un mode de réalisation de l'invention en référence aux figures annexées dans lesquelles : - FIG. 1 représente un téléphone mobile conforme à un mode de réalisation de l'invention ;
- FIG. 2 représente un téléphone mobile conforme à un mode de réalisation de l'invention lorsqu'un contenu a été chargé dans le téléphone ; - FIG. 3 représente un moteur compris dans un téléphone mobile selon un mode de réalisation de l'invention ;
- FIG. 4 représente un procédé d'exécution d'un fonctionnalité issue d'un appel des couches logicielles hautes.
La FIG. 1 représente un téléphone mobile 1 conforme à un mode de réalisation de l'invention . Ce téléphone mobile 1 comprend , dans une mémoire, un premier bloc logiciel assemblé 6. Le premier bloc assemblé 6 comprend un micrologiciel 2 et un moteur 3 susceptible de réaliser notamment le chargement et l'exécution des couches logicielles haute comprenant un logiciel médiateur et des applications.
Sur la FIG. 2, on a représenté le téléphone mobile 1 de la FIG. 1 lorsque les couches logicielles hautes sont chargées. Ces couches logicielles hautes peuvent comprendre un logiciel médiateur 4 et des applications 5.
Le moteur 3 est par exemple un composant tel que décrit dans la demande WO 05/08509.
Un exemple de moteur 3 selon un mode de réalisation de l'invention est illustré plus en détail sur la FIG. 3.
Le moteur 3 comprend un contrôleur de service 7 permettant de fournir un certain nombre de services aux couches logicielles hautes 4 et 5 qui pourront être chargées dans le téléphone mobile 1 .
Le contrôleur de service 7 comprend une ou plusieurs interfaces 73, par exemple du type API, permettant de réaliser un lien entre le moteur 3 et les couches logicielles hautes 4 et 5 qui pourront être chargées dans le téléphone mobile 1.
Le contrôleur de service comprend également une partie de code générique 71 indépendante de couches basses de la plateforme du téléphone mobile 1. Cette partie de code générique 71 peut donc ne pas être modifiée en cas de modification des couches basses du téléphone mobile 1. Le contrôleur de service comprend également une partie de code spécifique 72 dépendant de couches basses de la plateforme du téléphone mobile 1. Cette partie de code spécifique 72 devra donc être modifiée en cas de modification des couches basses du téléphone mobile 1.
Pour chaque interface 73 du contrôleur de service 7, la partie de code spécifique 72 et la partie de code générique 71 sont tels qu'un service associé à l'interface 8 peut être exécuté.
L'interface 73 comprend par exemple un service permettant d'afficher un caractère sur l'écran du téléphone mobile 1 , par exemple sous la forme d'une fonction affiche_car.
Le moteur 3 comprend également un chargeur 14 apte à charger, éventuellement à distance, les couches logicielles hautes dans le terminal— mobϋe_1-,—dlen— vérifier— les-propriétés et de stocker ces couches logicielles hautes 4 et 5 dans le terminal mobile 1.
Le moteur 3 comprend en outre un contrôleur de protocole de transport 9 permettant d'utiliser un protocole de transport disponible sur les couches basses du téléphone mobile 1 pour exécuter le chargement réalisé par le chargeur 14. Ce protocole de transport est par exemple un protocole connu du type TCP/IP, WAP, ou FTP. Le transport de données peut être un transport filaire ou sans fil depuis un équipement distant apte à transférer des données.
Le moteur 3 comprend également un installeur 10 chargé de l'installation des couches logicielles hautes dans la mémoire du téléphone mobile 1. Le moteur 3 comprend également un lanceur 8, apte à réaliser le lancement de l'exécution des couches logicielles hautes chargées par le chargeur 14. Le lanceur 8 est également apte à réaliser toute l'exécution des couches logicielles hautes si cette exécution nécessite une étape d'interprétation du code des couches logicielles hautes par un processeur du téléphone mobile 1 . De façon générale, le lanceur 8 permet donc l'exécution des couches logicielles hautes chargées par le chargeur 14.
Le moteur 3 comprend enfin un proxy 1 1 apte à rediriger des demandes de services issues des couches logicielles hautes vers les services offerts par le contrôleu r de service 7, lorsq ue les couches logicielles hautes s'exécutent. Le proxy 1 1 utilise en particulier une table de redirection liant chaque service de l'interface 73 avec l'emplacement où se trouve ce service dans les couches log icielles basses du téléphone mobile 1 , c'est-à-dire notamment-versJejnicr-θlogLciel-2
Ce proxy 1 1 est par exemple tel que décrit dans la demande la demande WO 05/08509 sous l'appellation PLUG.
En particulier, le proxy 1 1 est agencé pour rediriger un processeur du téléphone mobile 1 vers l'endroit où se trouve le service désiré dans le microlog iciel 2. Le proxy 1 1 comprend pour ce faire une fonction d'aiguillage, apte à prendre en paramètre les identifiants des fonctions cibles appelées par les couches log icielles hautes. Ces identifiants sont stockées dans une pile ou un registre du processeur de sorte à assurer la redirection vers les fonctions correspondantes du micrologiciel 2. La fonction d'aiguillage d u proxy 1 1 est réalisée à partir d'une table de correspondance entre des identifiants des fonctions appelées par les couches logicielles hautes et les adresses de ces fonctions dans le microlog iciel 2. On décrit maintenant plus en détail les couches logicielles hautes 4 et 5 destinées à être chargées dans le terminal mobile 1 par l'intermédiaire notamment du chargeur 14.
Les couches logicielles hautes comprennent un code devant être exécuté, des données utilisables, pouvant utilisées par le code, et des données spécifiques comprenant par exemple la liste des services utilisés par les couches logicielles hautes, ainsi que des informations d'identification des couches logicielles haute comprenant notamment leur origine, numéro de version, ou certificat. Ces données spécifiques sont générées par un générateur q ui sera décrit plus en détail par la suite.
On décrit maintenant plus en détail la façon dont sont générées ces couches logicielles hautes destinées à être chargées dans le téléphone mobile selon l'invention.
Dans les couches logicielles hautes, un logiciel médiateur 4, des applications 5 ainsi que différentes parties d'une interface avec un utilisateur sont codées d'une façon connue en soi.
Lorsq ue ces couches logicielles hautes ont besoin d'utiliser les services des couches logicielles basses du téléphone mobile 1 , elles passent par un des services de l'interface 73 du moteur 3. Ainsi, les couches logiciel les hautes n'utilisent jamais d'interface avec les couches log icielles basses du terminal mobile 1 .
Le code des couches logicielles hautes est donc programmé de sorte à ne pas faire référence aux couches logicielles basses du terminal mobile 1 , mais toujours à l'interface 73 du moteur 3.
Par exemple, si ces couches logicielles hautes doivent utiliser un service d'affichage d'un caractère sur un écran du téléphone mobile 1 , elles feront référence, dans leur code, à l'interface 73 comprenant l'instruction affiche_car.
Une fois le code de ces couches logicielles hautes réalisé, ce code est manipulé par un générateur. Le générateur prend en entrée le code source ou objet à inclure dans les couches logicielles hautes, compile les différentes parties du code, et assemble toutes les parties de code entre elles.
Pour ce faire, le générateur remplace préalablement les appels à l'interface 8 par du code générique appelé STUB. Ce code générique STUB sera mod ifié par l'installeur 1 0 du moteur 3 à l'installation des couches logicielles hautes dans le téléphone mobile 1 afin de permettre l'exécution des services sur le micrologiciel 2 du téléphone mobile 1 . L'utilisation d'une adresse sans signification particulière du type STUB permet de détecter ce type d'adresse et de la remplacer par une adresse d'entrée du proxy 1 1 .
Par exemple, la fonction affiche_car est remplacée par une fonction STUB du type stub(affiche_car). L'utilisation de ces fonctions STU B sera détaillée par la suite.
Hormis cette spécificité, le générateur utilise un procédé standard de génération de code par compilation et assemblage bien connu de l'homme du métier. Le générateur peut en outre dépendre des particularités des langages supportés par le moteur 3, notamment C , C++, JAVA ou XM L.
En plus de ces modifications portant sur les fonctions STUB, le générateur ajoute un certain nombre d'informations additionnelles qui seront utilisées par le moteur 3. Par exemple, le générateur va générer les données spécifiques comprenant notamment la liste des services utilisés par le code originel, en particulier la fonction affiche_car. Il peut aussi ajouter, dans ces données spécifiques, un certain nombre d'identifiants permettant de garantir par exemple l'origine voire l'intégrité des couches logicielles hautes ou un numéro de version.
A ce stade, les couches log icielles hautes 4 et/ou 5 peuvent également être cryptées.
On décrit maintenant l'interaction entre le téléphone mobile 1 et les couches logicielles hautes selon l'invention.
Lorsque le téléphone mobile 1 est démarré, le chargeur 14 examine, via le contrôleur de protocole de transport 9, s'il existe des couches logicielles hautes à charger dans une mémoire du téléphone mobile 1 .
Les couches logicielles hautes peuvent par exemple être contenues dans une mémoire externe SIM du téléphone mobile 1 , ou une carte mémoire du téléphone mobile 1 , ou accessibles à distance dans une base de données via un protocole de transport. Ce protocole de transport peut être tout protocole de transport de données, par exemple Bluetooth, GPRS, WAP, ou TC P/I P.
Si des couches logicielles hautes à charger sont détectées par le chargeur 14, une notification est déclenchée de sorte à avertir un utilisateur du téléphone mobile 1 .
Cet utilisateur peut alors accepter ou refuser l'installation des couches logicielles hautes sur son terminal mobile 1 . Si l'utilisateur décide d'accepter l'installation des couches logicielles hautes sur son téléphone mobile 1 , ces couches logicielles hautes sont d'abord chargées.
Le chargeur 14 réalise cette étape de chargement en utilisant un des protocoles de transport fournis par le contrôleur de protocole de transport 9. Le chargeur 14 contrôle certaines informations des couches logicielles hautes afin de vérifier leur intégrité. Par exemple, le chargeur 14 vérifie que le service affiche_car nécessité par les couches logicielles hautes est bien d isponible au niveau de l'interface 73 du moteur 3.
Le chargeur 14 peut également être amené à demander un certain nombre de certificats ou d'autorisations avant d'autoriser le chargement des couches logicielles hautes. Le chargement peut notamment n'être autorisé qu'en fonction d'un paiement ou de la réalisation d'une transaction financière. I l peut également n'être autorisé qu'après vérification des droits de l'utilisateur du téléphone mobile 1 sur les couches log icielles hautes à charger.
Le chargeur 14 réalise alors le chargement des couches logicielles hautes. Les couches logicielles hautes sont alors stockées dans une mémoire d'exécution du téléphone mobile 1 dans un format exécutable par le moteur 3 et notamment le lanceur 8. Le stockage dans le format exécutable par le moteur 3 peut être réalisé soit en flux tendu lors du téléchargement, soit une fois le chargement terminé.
Une fois les couches logicielles chargées et stockées dans la mémoire d'exécution du terminal mobile 1 , l'installeur 1 0 est apte à modifier les fonctions STU B des couches logicielles afin que l'appel à ces fonctions STU B lors de l'exécution se traduise par un appel au proxy 1 1. Pour ce faire, la fonction STUB est redirigée sur le point d'entrée d'une fonction proxy du moteur 3.
Une fois cette installation terminée, le code des couches logicielles hautes peut être exécuté de manière connue en soi.
Lorsque le code des couches logicielles hautes fait appel à un service du moteur 3, c'est donc le proxy 1 1 qui est réellement appelé. Par exemple, lorsque le code des couches logicielles hautes cherche à accéder au service affiche_car, la fonction proxy(affiche_car) est en fait appelée.
Grâce à la table de localisation des services du proxy, cette fonction proxy(affiche_car) sera alors redirigée vers une fonction affiche car des couches logicielles basses et notamment du micrologiciel 2.
Ainsi, l'exécution des couches logicielles hautes s'effectue comme si le code de ces couches avait été assemblé avec le code des couches basses comme dans l'art antérieur.
De nouvelles couches logicielles hautes peuvent alors être chargées dans le téléphone mobile 1 par le procédé tel que précédemment décrit.
II est entendu que les couches logicielles hautes peuvent être exécutées sur n'importe quel type de terminal comprenant un moteur 3 tel que précédemment décrit.
On décrit maintenant un procédé d'exécution des couches logicielles hautes selon mode de réalisation de l'invention en référence à la FIG. 4. Sur la FIG. 4, le logiciel médiateur 5 a été préalablement chargé dans le téléphone mobile 1 . Le logiciel médiateur comprend un morceau de code 12 codant, à l'exécution, pour un appel à une fonction correspondant à un service ne pouvant être fourni que par le micrologiciel 2.
Selon l'invention, cette fonction est implémentée dans le logiciel médiateur 5 sous la forme d'une fonction génériq ue STLJ B. L'installeur 1 0 détecte alors 21 la fonction STUB correspondant à la partie de code 12. L'installeur 10 redirige alors cette fonction STU B vers une entrée du proxy 1 1 . A l'exécution , le proxy 1 1 , par l'intermédiaire d'une table de redirection , transforme 23 cet appel en un appel à une fonction équivalente 13 du micrologiciel 2 de sorte à réaliser le service correspondant à la fonction appelée.
Le chargement de différentes couches logicielles hautes comprenant notamment un logiciel médiateur 4 et des applications 5 comme précédemment décrit permet une personnalisation améliorée du téléphone mobile 1 .
Le téléphone mobile 1 peut notamment être commercialisé par un fabricant de téléphone mobile à moindre coût, la personnalisation du téléphone étant réalisée par le suite par un utilisateur du téléphone mobile 1 par le chargement des couches logicielles hautes 4 et 5.

Claims

REVENDICATIONS
1 . Téléphone mobile ( 1 ) comprenant : - U ne première mémoire ;
- Un premier bloc logiciel assemblé (6), stocké dans ladite première mémoire, ledit premier bloc logiciel étant dépourvu de couches logicielles hautes et comprenant uniquement, sous une forme assemblée : o un micrologiciel (2) comprenant une partie de code
(1 3), apte, à l'exécution, à réaliser une fonctionnalité, o des moyens de chargement ( 1 0, 14) agencés pour charger des couches logicielles hautes (4, 5) dans ledit téléphone mobile ( 1 ) ; o des moyens d'exécution (8, 1 1 ) aptes à exécuter lesdites couches logicielles hautes postérieurement à leur_chaπgemeαt-par_lesdits-moyens de chargement, de sorte à réaliser ladite fonctionnalité.
2. Téléphone mobile selon l'une des revendications 1 dans lequel ledit premier bloc logiciel est dépourvu de logiciel médiateur.
3. Téléphone mobile selon l'une des revendications 1 ou 2, dans lequel les moyens d 'exécution sont agencés pour rediriger un appel desdites couches logicielles hautes (4, 5) vers lad ite partie de code du micrologiciel, de sorte à réaliser ladite fonctionnalité.
4. Téléphone mobile (1 ) selon la revendication précédente dans lequel lesdits moyens d'exécution comprennent : - un proxy (1 1 ) comprenant une table de redirection agencée de sorte à rediriger ledit appel desd ites couches logicielles hautes vers ladite partie de code.
5. Téléphone mobile (1 ) selon la revendication précédente dans lequel ladite table de redirection comprend une correspondance entre des fonctions susceptibles d'être appelées par lesdites couches logicielles, et des fonctions identiques dudit micrologiciel.
6. Téléphone mobile ( 1 ) selon la revendication 4 ou 5 dans leq uel les moyens de chargement (10, 14) comprennent un installeur (1 0) agencé pour modifier des appels de fonctions desdites couches logicielles hautes de sorte à diriger les appels vers ledit proxy.
7. Téléphone mobile ( 1 ) selon l'une des revendications précédentes dans lequel lesdits moyens de chargement ( 1 0, 14) sont aptes à charger lesdites couches logicielles hautes depuis un équipement distant d udit téléphone mobile par un protocole de transport de données.
8 Téléphone mobile ( 1 ) selon l'une des revendications précédentes dans lequel lesd its moyens de chargement sont aptes à charger lesdites couches logicielles hautes depuis une deuxième mémoire distincte de ladite première mémoire, vers ladite première mémoire.
9. Téléphone mobile ( 1 ) selon la revendication précédente dans lequel ladite deuxième mémoire est une mémoire amovible.
10. Téléphone mobile ( 1 ) selon la revendication précédente dans lequel ladite mémoire amovible est une carte SI M dudit téléphone mobile.
1 1 . Système comprenant un téléphone mobile selon l'une quelconque des revend ications précédentes, et des couches logicielles hautes assemblées comprenant au moins un logiciel médiateur (4) et des applications (5), lesdites couches log icielles hautes comprenant des parties de codes, codant, à l'exécution, pour un appel à des services dudit micrologiciel (2) , lesdites couches logicielles hautes étant aptes à être exécutées par lesdits moyens d'exécution.
12. Procédé pour exécuter des couches logicielles hautes sur un téléphone mobile selon l'une quelconque des revendications, 1 à 1 0 comprenant des étapes dans lesquelles :
- on charge lesdites couches logicielles hautes dans le téléphone mobile ( 1 ) ;
- on exécute lesd ites couches logicielles hautes.
1 3. Procédé selon la revendication précédente comprenant des étapes dans lesquelles : - on charge un log iciel médiateur appartenant auxd ites couches logicielles hautes dans le téléphone mobile ( 1 ) ; ^_on_exécute ledit logicieLmédiateuc.
14. Procédé selon la revendication précédente dans lequel lesd ites couches logicielles hautes comprennent une partie codant pour un appel à u ne fonction correspondant à un service d udit micrologiciel (2), et dans lequel :
- ledit appel est redirigé (22) vers ledit proxy ;
- ledit proxy redirige (23) ledit appel vers une partie de code d udit micrologiciel codant, à l'exécution, pour ledit service.
15. Procédé de fabrication d'un téléphone mobile comprenant des étapes dans lesquelles :
- on développe un micrologiciel (2) comprenant une partie de code apte, à l'exécution, à réaliser une fonctionnalité;
- on développe des moyens de chargement ( 10, 14) aptes à charger des couches logicielles hautes (4, 5) dans ledit téléphone mobile ( 1 ) ; - on développe des moyens d'exécution (8, 11 ) aptes à exécuter lesdites couches logicielles hautes postérieurement à leur chargement par lesdits moyens de chargement, de sorte à réaliser ladite fonctionnalité ; - on assemble le micrologiciel, lesdits moyens de chargement et lesdits moyens d'exécution pour former un premier bloc logiciel, de sorte que ledit premier bloc logiciel soit dépourvu de couches logicielles hautes et comprenne uniquement, sous une forme assemblée, le micrologiciel, lesdits moyens de chargement et lesdits moyens d'exécution ;
- on charge dans une mémoire dudit téléphone mobile, ledit premier bloc logiciel.
PCT/FR2007/002000 2006-12-06 2007-12-05 Téléphone mobile configurable WO2008081114A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP07871796A EP2087423A2 (fr) 2006-12-06 2007-12-05 Téléphone mobile configurable

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0655340 2006-12-06
FR0655340A FR2909827B1 (fr) 2006-12-06 2006-12-06 Telephone mobile configurable

Publications (2)

Publication Number Publication Date
WO2008081114A2 true WO2008081114A2 (fr) 2008-07-10
WO2008081114A3 WO2008081114A3 (fr) 2008-10-09

Family

ID=38042733

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/002000 WO2008081114A2 (fr) 2006-12-06 2007-12-05 Téléphone mobile configurable

Country Status (3)

Country Link
EP (1) EP2087423A2 (fr)
FR (1) FR2909827B1 (fr)
WO (1) WO2008081114A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101710295A (zh) * 2009-10-10 2010-05-19 深圳市江波龙电子有限公司 一种智能存储卡与外部主机设备的通信系统及方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1994027220A1 (fr) * 1993-05-06 1994-11-24 Apple Computer, Inc. Procede et appareil pour vectoriser le contenu d'un dispositif a memoire rom sans modifier le code source sous-jacent
WO2001011905A1 (fr) * 1999-08-05 2001-02-15 Ericsson, Inc. Terminal d'abonne sans fil utilisant un code de commande java
WO2002050608A2 (fr) * 2000-12-19 2002-06-27 Smart Card Solutions Limited Dispositif informatique a microprocesseur ou micro-controleur integre

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1994027220A1 (fr) * 1993-05-06 1994-11-24 Apple Computer, Inc. Procede et appareil pour vectoriser le contenu d'un dispositif a memoire rom sans modifier le code source sous-jacent
WO2001011905A1 (fr) * 1999-08-05 2001-02-15 Ericsson, Inc. Terminal d'abonne sans fil utilisant un code de commande java
WO2002050608A2 (fr) * 2000-12-19 2002-06-27 Smart Card Solutions Limited Dispositif informatique a microprocesseur ou micro-controleur integre

Also Published As

Publication number Publication date
WO2008081114A3 (fr) 2008-10-09
EP2087423A2 (fr) 2009-08-12
FR2909827B1 (fr) 2009-05-22
FR2909827A1 (fr) 2008-06-13

Similar Documents

Publication Publication Date Title
JP2007526676A (ja) 自動化されたエアープラグイン装置認識およびソフトウェアドライバ・ダウンロード
US20050234825A1 (en) Method for loading an application in a device, device and smart card therefor
EP3123387B1 (fr) Sécurisation du chargement de données dans une mémoire non-volatile d'un élément sécurisé
WO2003096238A1 (fr) Procede pour charger une application dans un dispositif, dispositif et carte intelligente prevue a cet effet
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
WO2001035686A1 (fr) Procede de mise a jour d'un programme principal execute par un module de radiocommunication
FR2817055A1 (fr) Execution d'une application dans un objet electronique portable a faible capacite de memoire
WO2008081114A2 (fr) Téléphone mobile configurable
US20070078917A1 (en) Removable media player for mobile phones
WO2006072747A1 (fr) Dispositif de connexion automatique au reseau internet
EP0996300A1 (fr) " Procédé d'accès à un serveur de services à partir d'une station mobile, module d'identification d'abonné et terminal correspondants."
FR2902551A1 (fr) Dispositif de memorisation amovible et appareil electronique aptes a etre connectes l'un a l'autre et procede de sauvegarde de donnees d'environnement
EP1273999A1 (fr) Procédé et produit programme d'autorisation d'utilisation de logiciel
WO2020165518A1 (fr) Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire
KR100766593B1 (ko) 게임 컨텐츠 및 아이템 파일의 전송 방법, 시스템 및 서버
EP1503563A1 (fr) Procédé de sécurisation de requetes d'accès à des services, terminal et module logiciel pour mettre en oeuvre le procédé
EP2284751B1 (fr) Procédé de traçabilité et d'imputabilité dynamiques des échanges dans un environnement ouvert de type internet
FR2857476A1 (fr) Systeme permettant d'optimiser la gestion des composants logiciels integres dans un systeme embarque, notamment dans un telephone mobile
US8191150B2 (en) Method and arrangement relating to a communication device
FR3037753A1 (fr) Procede et systeme ameliores de selection d'une application par defaut dans un element securise
FR2924297A1 (fr) Procede de gestion de l'interface utilisateur d'un termninal mobile associe a un module de securite et terminal mobile associe
WO2021019162A1 (fr) Adaptation dynamique d'un environnement d'exécution d'élément sécurisé à des profils
WO2002037435A1 (fr) Carte a puce avec descripteur d'application
FR3091767A1 (fr) Autorisation du chargement d’une application dans un élément de sécurité.
FR2864294A1 (fr) Carte a microcircuit multi-compte permettant la restriction d'une fonctionnalite a un compte et procede de communication correspondant

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: 07871796

Country of ref document: EP

Kind code of ref document: A2

REEP Request for entry into the european phase

Ref document number: 2007871796

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007871796

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE