FR 2930705 A1 20091030 FR 0902094 A 20090429 La présente invention concerne le domaine des services à valeur ajoutée dans des réseaux de télécommunications sans fil. Plus spécifiquement, l'invention décrit des techniques d'installation et de démarrage d'applications Java sur des stations mobiles faciles à utiliser. Sur des réseaux de télécommunications sans fil (tels que GSM et d'autres réseaux), de nombreux dispositifs mobiles et stations mobiles (MS) (tels que les téléphones mobiles et les assistants numériques personnels) peuvent exécuter des applications Java. De telles applications sont typiquement converties au format de pseudo-code binaire Java décrit dans le brevet US n° 5 815 661 de Gosling, s'accompagnent de données en fichiers JAR et sont installées dans la mémoire de la MS. Des applications interagissent typiquement avec la MS par le biais de jeux standardisés d'interfaces de programmation d'application tels que le profil de dispositif d'informations mobile (MIDP) version 2.0 décrit dans JSR-118 de Sun Microsystems. De telles applications sont appelées MIDIets. L'interface d'utilisateur graphique d'une MS compatible avec MIDP comprend typiquement des moyens de démarrage de MIDIets, tels que des menus, des icônes, ou une application spéciale appelée gestionnaire de MIDIet. On a découvert que ce procédé de démarrage de MIDIets présentait les limitations suivantes qui portent préjudice à l'acceptation des MIDIets sur le marché. Tout d'abord, pour démarrer les MlDlets, l'utilisateur doit typiquement appuyer sur une séquence complexe de touches et/ou naviguer dans plusieurs couches de menu. Deuxièmement, l'aspect et le toucher de ces touches et/ou menus ne sont pas standardisés entre les différentes marques et les différents modèles de dispositifs mobiles. Un autre procédé de démarrage de MlDlets est l'architecture Push MIDP décrite dans JSR-118 de Sun Microsystems. L'API d'architecture Push permet d'enregistrer une MlDlet avec l'architecture Push de la MS, de sorte que la MS démarre automatiquement la MlDlet lorsqu'un événement de déclenchement spécifique survient. L'événement de déclenchement est typiquement un message court (SMS) entrant contenant un élément d'informations d'adressage de port d'application tel que spécifié par GSM TS 03.40. II est à noter que l'architecture Push n'a pas pour but de permettre à l'utilisateur de démarrer une MlDlet ; les fournisseurs de services utilisent plutôt typiquement l'architecture Push pour déclencher le traitement d'informations internes, telles que des messages entrants dans un service de messagerie instantané. Les navigateurs WAP, les passerelles et serveurs constituent une autre caractéristique des réseaux de télécommunications sans fil. Un utilisateur peut typiquement utiliser le navigateur WAP d'une MS pour télécharger, installer et exécuter une MlDlet, bien que ce procédé présente la même limitation que les procédés mentionnés précédemment. La norme WAP comprend également un mécanisme appelé Push WAP. Push WAP permet à un fournisseur de services d'envoyer un SMS qui amène la MS à ouvrir et afficher une adresse WAP sans nécessiter la saisie manuelle de l'adresse par l'utilisateur. Il existe trois types de messages Push WAP : les messages d'indication de service (SI) sont encodés en WBXML et contiennent du texte ainsi que l'adresse WAP ; les messages de chargement de service (SL) sont encodés en WBXML et ne contiennent que l'adresse WAP ; les SMS cliquables sont des SMS de texte ordinaire contenant l'adresse WAP. La fonctionnalité de données de service supplémentaires peu structurées (USSD) est une caractéristique standard des réseaux GSM et est décrite à l'origine dans GSM TS 02.90, 03.90 et 04.90. L'USSD fournit un canal de communication de texte uniquement, bidirectionnel, interactif et orienté session entre des stations mobiles et des serveurs dans le réseau mobile terrestre public (PLMN). Une demande USSD initiée côté mobile est typiquement utilisée pour démarrer un dialogue interactif entre l'utilisateur d'une MS et une application exécutée sur un ordinateur distant tel qu'un HLR ou une plate-forme de service USSD. Les numéros spéciaux sont une caractéristique des réseaux de télécommunications. La plupart des réseaux peuvent être configurés de sorte que lorsqu'un abonné compose un numéro spécifique (tel qu'un numéro court ou un numéro non géographique ou un numéro premium), l'appel n'est pas acheminé comme un appel vocal normal, mais est contrôlé par un serveur spécial. Un tel comportement est supporté, par exemple, par les normes INAP (décrite dans la recommandation ITU Q.1218 et Q.1228) et CAMEL (décrite dans 3GPP TS 23.078). Une autre particularité des réseaux de télécommunications sans fil est l'API de téléphonie mobile (MTA) spécifiée dans JSR-253 de Sun Microsystems. La MTA permet à une MlDlet de recevoir une notification des appels vocaux sortants et des demandes USSD initiées côté mobile. Un objet de l'invention consiste à proposer un procédé d'installation et de démarrage de MIDIets sur des stations mobiles qui soit facile à mémoriser et familier pour les utilisateurs. Un deuxième objet consiste à proposer un procédé qui fonctionne de manière identique avec la plupart des marques et des modèles de stations mobiles. Un troisième objet consiste à proposer un procédé qui fonctionne de manière identique avec de nombreux opérateurs de réseau. L'invention concerne un procédé comprenant : en réponse à une demande de service d'utilisateur au niveau d'un dispositif mobile, la détermination de la disponibilité d'une application de service 20 appropriée sur le dispositif mobile ; et si l'application de service appropriée est disponible sur le service mobile, la réception d'un ordre d'activation pour un service demandé, et, l'activation du service demandé sur le dispositif mobile avec l'ordre d'activation. 25 Le procédé peut en outre comprendre : si l'application de service appropriée n'est pas disponible sur le dispositif mobile, le téléchargement de l'application de service appropriée sur le réseau sans fil, et l'exécution de l'application de service téléchargée. L'ordre d'activation peut comprendre une adresse WAP où l'application de 30 service est disponible pour une installation. Le réseau sans fil peut être un réseau mobile terrestre public ; le dispositif mobile peut être un dispositif cellulaire ; l'ordre d'activation peut être un message de déclenchement d'architecture Push MIDP ; l'application de service peut être une MlDlet. 35 La demande d'activation de service peut être une demande USSD initiée côté mobile ou un appel sortant du dispositif mobile vers un numéro spécial. L'invention concerne également un procédé, comprenant : en réponse à la réception d'une demande d'utilisateur pour l'activation d'un service sur un réseau sans fil à partir d'un dispositif mobile, la détermination de la disponibilité d'une application de service appropriée sur le dispositif mobile ; et si l'application de service appropriée n'est pas disponible sur le dispositif mobile, la transmission d'un ordre d'installation au dispositif mobile, et la transmission d'un ordre d'activation au dispositif mobile, l'ordre d'activation étant configuré pour exécuter l'application de service appropriée sur le dispositif mobile. L'ordre d'installation peut comprendre une adresse de téléchargement à laquelle l'application de service appropriée est disponible. L'adresse de téléchargement est, par exemple, une adresse WAP. Ce procédé peut en outre comprendre : la mise à jour d'un statut d'installation de l'application de service appropriée sur le dispositif mobile. L'ordre d'activation peut être un message de déclenchement d'architecture Push MIDP ; le réseau sans fil peut être un réseau mobile terrestre public ; le dispositif mobile peut être un dispositif cellulaire ; l'application de service peut être une MlDlet. La demande d'activation de service peut être une demande USSD initiée côté mobile ou un appel sortant du dispositif mobile vers un numéro spécial. L'invention concerne en outre un système, comprenant : un réseau sans fil ; un fournisseur de services en communication avec un dispositif mobile par le biais du réseau sans fil, le fournisseur de services étant configuré pour, en réponse à une demande de service d'utilisateur déterminer la disponibilité d'une application de service appropriée sur le dispositif mobile, si l'application de service appropriée est disponible sur le service mobile, transmettre un ordre d'activation au dispositif mobile sur le réseau sans fil, et si l'application de service appropriée n'est pas disponible sur le dispositif mobile, transmettre un ordre d'installation au dispositif mobile sur le réseau sans fil. Le système peut en outre comprendre : une base de données stockant une liste d'applications de service installées sur le dispositif mobile ; et/ou un serveur en communication avec le réseau sans fil et le fournisseur de services, le service transférant des informations entre le dispositif mobile et le fournisseur de services. Le réseau sans fil supporte au moins un élément parmi : des communications de données et des communications vocales. Dans un mode de réalisation de l'invention, un fournisseur de services informe un utilisateur qu'il peut accéder à un service en composant un code USSD. Lorsque l'utilisateur compose le code USSD, la MS reconnaît le code en tant que code USSD et envoie un message USSD au PLMN par une connexion sans fil. Le PLMN reconnaît que le message USSD est associé au service et notifie le fournisseur de services. Le fournisseur de services reconnaît la notification comme une demande d'activation pour le service, formate un message de déclenchement d'architecture Push avec un port d'application qui correspond à celui d'une MIDIet installée précédemment, et l'envoie à la MS. A la réception du message de déclenchement d'architecture Push, la MS démarre la MIDIet. Dans un autre mode de réalisation de l'invention, un fournisseur de services informe un utilisateur qu'il peut accéder à un service en composant un numéro spécial. Lorsque l'utilisateur compose le numéro spécial, la MS initie un appel vocal sur une connexion sans fil. Le PLMN reconnaît que l'appel vocal est associé au service et notifie le fournisseur de services. Le PLMN peut soit rejeter l'appel vocal, soit le connecter à un message vocal préenregistré qui informe l'utilisateur du traitement de sa demande. Le fournisseur de services reconnaît la notification comme une demande d'activation pour le service, formate un message de déclenchement d'architecture Push avec un port d'application qui correspond à celui d'une MIDIet précédemment installée et l'envoie à la MS. A la réception du message de déclenchement d'architecture Push, la MS démarre la MIDIet. Les deux modes de réalisation peuvent être améliorés comme suit, de sorte que la MIDIet est installée automatiquement. A la réception de la demande d'activation de la MS, le fournisseur de services interroge une base de données pour déterminer si la MS a déjà installé la MIDIet. Si cela n'est pas le cas, le fournisseur de services renvoie un Push WAP à la MS contenant l'adresse WAP ou un fichier JAD ou JAR contenant la MlDlet. La MS reçoit le message Push WAP, télécharge le fichier JAD ou JAR, et installe la MlDlet. La MlDlet signale au fournisseur de services qu'elle a été installée avec succès (typiquement en envoyant une demande de WAP ou HTTP), et le fournisseur de services met à jour la base de données en conséquence. Les deux modes de réalisation peuvent également être améliorés afin de renforcer l'efficacité de l'envoi du message de déclenchement d'architecture Push à la MS. Le fournisseur de services s'assure que le message de déclenchement d'architecture Push est délivré à la MS avant que le PLMN ne rejette ou ne mette fin au dialogue USSD ou à l'appel vocal. Dans ce cas, le PLMN peut transmettre le message SMS à la MS sur un canal de signalisation sans fil (tel qu'un SDCCH ou un SACCH ou un FACCH) qui est déjà attribué à des fins de contrôle du dialogue USSD ou de l'appel vocal, évitant ainsi le coût d'établissement d'un nouveau canal de signalisation. Il est prévu que les deux modes de réalisation puissent être améliorés en tirant parti de l'API de téléphonie mobile afin de réduire la latence et le trafic sur le réseau. Une MlDlet invoque un procédé, par exemple, TelephonyManager.addTelephonyManagerListener() pour s'inscrire à la réception de demandes d'activation de service. Lorsque l'utilisateur compose une demande d'activation de service, la mise en oeuvre MTA avertit la MlDlet en invoquant TelephonyManagerListener.notifyOutgoingUnstructuredService() ou TelephonyManagerListener.notifyOutgoingCall(). La MlDlet reconnaît la notification comme une demande d'activation de service et adopte le comportement correspondant. La MlDlet peut également invoquer un procédé, par exemple, Call.terminate() ou UnstructuredService.terminate() afin d'éviter l'envoi de messages inutiles au PLMN. Tandis que l'invention est décrite dans le contexte des réseaux GSM, il est entendu que certains des aspects inventifs peuvent être appliqués de manière similaire à des réseaux de télécommunications sans fil actuels ou à venir, tels que les réseaux 3G/UMTS et les réseaux CDMA. La figure 1 est un tableau de séquence d'un premier exemple de message pour fournir des applications à des dispositifs mobiles sur un réseau sans fil. La figure 2 est un tableau de séquence d'un deuxième exemple de message pour fournir des applications à des dispositifs mobiles sur un réseau sans fil. La figure 3 est un tableau de séquence d'un troisième message pour fournir des applications à des dispositifs mobiles sur un réseau sans fil. La figure 4 est un exemple de système pour fournir des applications à des dispositifs mobiles sur un réseau sans fil. La figure 5 est un exemple de procédure pour fournir des applications à des dispositifs mobiles sur un réseau sans fil. Un procédé et un système sont proposés pour installer et exécuter automatiquement les applications de service appropriées sur un dispositif mobile en réponse à une demande d'utilisateur concernant un service. Le processus d'installation est simplifié pour l'utilisateur et est identique du point de vue de l'utilisateur pour les différents dispositifs mobiles et supports sans fil. La figure 1 est un tableau de séquence d'un premier exemple de message pour fournir des applications à des dispositifs mobiles sur un réseau sans fil. La demande d'activation de service peut être, par exemple, un code USSD #100#. Un fournisseur de services peut informer un utilisateur qu'il peut accéder à un service en composant un code USSD spécifié associé à un service, par exemple #100#. Lorsque l'utilisateur compose le code USSD, le dispositif mobile transmet le code au PLMN, où il est reconnu et transféré vers un fournisseur de services associé. Le fournisseur de services formate un message de déclenchement d'architecture Push avec un port d'application qui correspond à celui d'une application précédemment installée et l'envoie au dispositif mobile. A la réception du message de déclenchement d'architecture Push, le dispositif mobile démarre une application pour fournir le service demandé. Un dispositif mobile ou une station mobile 100 peut être en communication sans fil avec un PLMN 102 sur un réseau sans fil. Le PLMN 102 peut être en communication avec un fournisseur de services 104. Le fournisseur de services 104 peut fournir un service demandé au dispositif mobile 100. En 106, un utilisateur peut entrer le code USSD spécifié associé à un service demandé, tel que #100#, dans le dispositif mobile 100. Le dispositif mobile peut transmettre le code au PLMN 102 sur le réseau sans fil. En 108, le PLMN 102 peut recevoir le code USSD et invoquer un sous-programme de manipulation. Par exemple, le PLMN 102 peut accéder à une table de conversion pour déterminer la validité du code USSD et le service auquel le code est associé. En 110, le PLMN 102 peut déterminer un fournisseur de services approprié pour invoquer et transmettre un ordre au fournisseur de services 104 avec la demande d'utilisateur. Le fournisseur de services 104 peut répondre avec une réponse au PLMN 102. La réponse peut être un accusé de réception ou un autre message. En 112, le PLMN 102 peut transmettre une réponse au dispositif mobile 100 démarrant l'application pour assurer le service demandé. A titre d'exemple, la réponse peut indiquer que la demande du dispositif mobile a été traitée et qu'une réponse du fournisseur de services 104 est prévue. En 114, le dispositif mobile 100 peut recevoir la réponse du PLMN 102. En 116, le fournisseur de services 104 peut formater un message de déclenchement d'architecture Push avec un port d'application correspondant à celui d'une application précédemment installée, et transmettre le message au dispositif mobile 100. En 118, le dispositif mobile 100 peut recevoir le message du fournisseur de services 104. En 120, le dispositif mobile 100 peut déclencher l'architecture Push selon les instructions du message du fournisseur de services 104. En 122, l'application, telle qu'une MIDIet, peut être démarrée pour assurer le service demandé. Dans un mode de réalisation en variante, il est possible d'accéder au service en composant un numéro spécial. Lorsque l'utilisateur compose un numéro spécial, le dispositif mobile initie un appel vocal sur une connexion sans fil. Le PLMN reconnaît l'appel vocal vers le numéro spécial et le service associé, et en avertit le fournisseur de services. Le PLMN peut rejeter l'appel vocal ou le connecter à un message vocal préenregistré informant l'utilisateur du traitement de sa demande. Le fournisseur de services reconnaît la demande d'activation pour le service, formate un message de déclenchement d'architecture Push avec un port d'application correspondant à celui d'une MlDlet précédemment installée et l'envoie au dispositif mobile. A la réception du message de déclenchement d'architecture Push, le dispositif mobile démarre la MIDIet. Dans un mode de réalisation en variante, l'efficacité de l'envoi du message de déclenchement d'architecture Push au dispositif mobile peut être améliorée. Le fournisseur de services peut s'assurer que le message de déclenchement d'architecture Push est délivré au dispositif mobile avant que le PLMN ne rejette et ne mette fin au dialogue USSD ou à l'appel vocal. Dans ce cas, le PLMN peut transmettre le message SMS à la MS sur un canal de signalisation sans fil (tel qu'un SDCCH ou un SACCH ou un FACCH) qui est déjà attribué à des fins de contrôle du dialogue USSD ou de l'appel vocal, évitant ainsi le coût d'établissement d'un nouveau canal de signalisation. La figure 2 est un tableau de séquence d'un deuxième exemple de message pour fournir des applications à des dispositifs mobiles sur un réseau sans fil. Si l'application de service n'est pas disponible sur le dispositif mobile, le système peut installer automatiquement la MlDlet lorsque l'utilisateur a accès au service pour la première fois. Un dispositif mobile ou une station mobile 200 peut être en communication sans fil avec un PLMN 202 sur un réseau sans fil. Le PLMN 202 peut être en communication avec un fournisseur de services 204. Le fournisseur de services 204 peut fournir un service demandé au dispositif mobile 200. En 206, un utilisateur peut entrer le code USSD spécifié associé à un service demandé, tel que #100#, dans le dispositif mobile 200. Le dispositif mobile peut transmettre le code au PLMN 202 sur le réseau sans fil. En 208, le PLMN 202 peut recevoir le code USSD et invoquer un sous-programme de manipulation. Par exemple, le PLMN 202 peut accéder à une table de conversion pour 25 déterminer la validité du code USSD et le service auquel le code est associé. En 210, le PLMN 202 peut déterminer un fournisseur de services approprié pour invoquer et transmettre un ordre au fournisseur de services 204 avec la demande d'utilisateur. Le fournisseur de services 204 peut interroger une 30 base de données accessible avec un identifiant de dispositif mobile transmis pour déterminer si l'application demandée est déjà installée sur le dispositif mobile. Le fournisseur de services 204 peut répondre avec une réponse au PLMN 202. La réponse peut être un accusé de réception ou une indication du fait que l'installation demandée doit être installée. 35 En 212, le PLMN 202 peut transmettre une réponse au dispositif mobile 200. A titre d'exemple, la réponse peut indiquer que la demande du dispositif mobile a été traitée et qu'une réponse du fournisseur de services 204 est prévue. En 214, le dispositif mobile 200 peut recevoir la réponse du PLMN 202. En 216, le fournisseur de services 204 peut formater un Push WAP vers le dispositif mobile contenant l'adresse WAP d'un fichier JAD ou JAR contenant l'application demandée, telle qu'une MlDlet. En 218, le dispositif mobile 200 peut recevoir le message du fournisseur de services 204. En 220, le dispositif mobile peut traiter le message Push WAP reçu. En 222, le dispositif mobile peut démarrer automatiquement un navigateur WAP installé et passer l'adresse WAP intégrée au navigateur. En 224, le navigateur peut tenter de télécharger l'application demandée. En 226, le fournisseur de services 204 peut recevoir la demande du dispositif mobile pour l'application demandée. L'application demandée, sous une forme pouvant être installée (telle qu'un fichier JAD ou JAR) peut être transmise au dispositif mobile 200. En 228, le dispositif mobile 200 peut recevoir les fichiers d'installation et installer l'application demandée. En 230, le dispositif mobile 200 peut exécuter l'application demandée et fournir le service demandé à l'utilisateur. En 232, le dispositif mobile 200 peut transmettre un message au fournisseur de services 204 indiquant que l'application demandée a été installée avec succès. Le fournisseur de services 204 peut mettre à jour une entrée appropriée dans sa base de données. La figure 3 est un tableau de séquence d'un troisième message pour fournir des applications à des dispositifs mobiles sur un réseau sans fil. Pour réduire la latence et le trafic sur le réseau lorsque la station mobile supporte l'API de téléphonie mobile, l'application de service installée peut intercepter toutes les demandes concernant le service associé. Lorsqu'une telle demande est interceptée, l'application de service commence à exécuter et termine la demande de service avant une transmission sur le réseau sans fil, ce qui empêche l'envoi de messages inutiles lorsque l'application de service est déjà installée et s'exécute sur le dispositif mobile. Un dispositif mobile 300 supportant une MTA peut exécuter une MlDlet 35 302. En 304, au moment de l'exécution, la MlDlet peut invoquer un procédé, tel que TelephonyManager.addTelephonyManagerListener() pour s'inscrire à la réception de demande d'activation de service du dispositif mobile 300. En 306, l'utilisateur peut composer une demande d'activation de service, tel qu'un code USSD #100#. La mise en oeuvre MTA du dispositif mobile 300 avertit la MlDlet 302 de la demande en invoquant un procédé, tel que TelephonyManagerListener.notifyOutgoingUnstructuredService Q ou TelephonyManagerListener. notifyOutgoingCallQ. En 308, la MlDlet 302 reçoit et reconnaît la notification comme une demande d'activation de service et fournit le service demandé. En 310, la MlDlet 302 peut également invoquer Call.terminate() ou UnstructuredService.terminate() pour empêcher l'envoi de messages inutiles au PLMN, lorsque la MlDlet 302 est déjà installée et s'exécute sur le dispositif mobile 300. On appréciera le fait que les procédures ci-dessus peuvent s'exécuter sur 15 divers types de réseaux sans fil, tels que les réseaux GSM, les réseaux 3G/UMTS et les réseaux CDMA. La figure 4 est un exemple de système de fourniture d'applications à des dispositifs mobiles sur un réseau sans fil. Un dispositif mobile 400 peut être, par exemple, un téléphone cellulaire, un assistant numérique 20 personnel, ou tout autre dispositif mobile configuré pour des communications sans fil. Un réseau sans fil 402 peut être, par exemple, un réseau GSM, un réseau 3G/UMTS, un réseau CDMA, un réseau de données ou tout autre réseau sans fil configuré pour permettre des communications sans fil vers le 25 dispositif mobile 400. Un serveur 404 peut être en communication avec le dispositif mobile 400 sur le réseau sans fil 402. Le serveur 404 peut être configuré pour administrer le réseau sans fil 402 et acheminer des communications entre des dispositifs, sur le réseau sans fil 402 et hors de celui-ci. 30 Un fournisseur de services 406 peut être en communication avec le serveur 404 et être configuré pour fournir un service demandé à des dispositifs mobiles. A titre d'exemple, le service peut comprendre la fourniture d'un contenu choisi par l'utilisateur à un dispositif mobile d'utilisateur 400. Le fournisseur de services 406 peut comprendre les logiciels, données et 35 logiques requis pour assurer le service demandé. Il convient d'apprécier que le fournisseur de services 406 puisse être configuré pour fournir plus d'un type de service demandé. II convient également d'apprécier qu'un nombre quelconque de fournisseurs de services puisse exister sur le système pour fournir un nombre quelconque de services demandés. Une base de données d'installation 408 peut être configurée pour stocker des informations concernant le fait qu'une application de service a été installée ou non sur le dispositif mobile 400. Des informations supplémentaires telles que le numéro de version de l'application installée, une date et une heure d'installation, et d'autres informations peuvent également être stockées. Il convient d'apprécier le fait que dans un environnement à dispositifs mobiles multiples et à services multiples, la base de données 408 puisse stocker des informations concernant les applications installées sur des dispositifs mobiles pertinents. II convient d'apprécier qu'un système puisse comprendre un nombre quelconque de dispositifs mobiles, de réseaux sans fil, de serveurs, de fournisseurs de services et de bases de données d'installation. La figure 5 est un exemple de procédure de fourniture d'applications à des dispositifs mobiles sur un réseau sans fil. A titre d'exemple, la procédure peut s'exécuter sur un serveur et un fournisseur de services. II convient d'apprécier que le serveur et le fournisseur de services puissent s'exécuter sur la même machine ou sur des machines distinctes en communication l'une avec l'autre. Le réseau sans fil peut être un PLMN. En 550, le serveur peut recevoir une demande d'utilisateur pour l'activation d'un service provenant d'un dispositif mobile. L'utilisateur peut entrer la demande sous la forme d'un code USSD ou composer un numéro spécial, comme évoqué plus haut. Le dispositif mobile peut être un dispositif cellulaire. En 552, le serveur peut éventuellement tester l'installation et la disponibilité de l'application de service sur le dispositif mobile. En variante, le serveur peut simplement transférer la demande au fournisseur de services qui testera ensuite l'installation et la disponibilité de l'application de service sur le dispositif mobile. L'application de service peut être une MlDlet. En 554, le serveur ou fournisseur de services peut exécuter une installation à distance de l'application de service demandée, le cas échéant. A titre d'exemple, une adresse WAP peut être fournie au dispositif mobile à partir de l'emplacement auquel l'application de service demandée peut être téléchargée et installée. En 556, le serveur ou fournisseur de services peut éventuellement mettre à jour un statut d'installation de l'application de service sur le dispositif mobile dans une base de données d'installation. La base de données d'installation peut stocker le statut d'installation d'une pluralité d'applications de service sur une pluralité de dispositifs mobiles dans le système et éliminer les installations redondantes sur les dispositifs mobiles. En 558, le serveur ou fournisseur de services peut transmettre un ordre d'activation au dispositif mobile, activant l'application de service et fournissant le service demandé. Si l'application de service ne s'exécute pas encore sur le dispositif mobile, l'ordre peut exécuter l'application de service. L'ordre d'activation peut être une architecture Push MIDP. Un exemple de mode de réalisation de la présente invention est un procédé. Le procédé peut comprendre, en réponse à une demande de service d'utilisateur au niveau d'un dispositif mobile, la détermination de la disponibilité d'une application de service appropriée sur le dispositif mobile. Le procédé peut comprendre, si l'application de service appropriée n'est pas disponible sur le dispositif mobile, la transmission d'une demande d'installation à un fournisseur de services sur un réseau sans fil. Le procédé peut comprendre la réception d'un ordre d'installation pour un service demandé. Le procédé peut comprendre l'activation du service demandé sur le dispositif mobile avec l'ordre d'installation. Le procédé peut comprendre le téléchargement de l'application de service appropriée sur le réseau sans fil. Le procédé peut comprendre l'exécution de l'application de service téléchargée. Le réseau sans fil peut être un réseau mobile terrestre public. Le dispositif mobile peut être un dispositif cellulaire. L'ordre d'installation peut être un message Push WAP. L'application de service peut être une MlDlet. L'ordre d'installation peut comprendre une adresse WAP à laquelle l'application de service est disponible pour une installation. La demande d'activation de service peut être une demande USSD initiée côté mobile. La demande d'activation de service peut être un appel sortant du dispositif mobile vers un numéro spécial. Un autre exemple de mode de réalisation de la présente invention peut être un procédé. Le procédé peut comprendre, à la réception d'une demande d'utilisateur pour l'activation d'un service sur un réseau sans fil à partir d'un dispositif mobile, la détermination de la disponibilité d'une application de service appropriée sur le dispositif mobile. Le procédé peut comprendre, si l'application de service appropriée n'est pas disponible sur le dispositif mobile, l'exécution d'une installation à distance de l'application de service appropriée. Le procédé peut comprendre la transmission d'un ordre d'installation au dispositif mobile, l'ordre d'installation étant configuré pour exécuter l'application de service appropriée sur le dispositif mobile. L'ordre d'installation peut comprendre une adresse de téléchargement à laquelle l'application de service appropriée est disponible. L'adresse de téléchargement peut être une adresse WAP. Le procédé peut comprendre la mise à jour d'un statut d'installation de l'application de service appropriée sur le dispositif mobile. L'ordre d'installation peut être un message d'architecture Push WAP. Le réseau sans fil peut être un réseau mobile terrestre public. Le dispositif mobile peut être un dispositif cellulaire. L'application de service peut être une MlDlet. La demande d'activation de service peut être une demande USSD initiée côté mobile. La demande d'activation de service peut être un appel sortant du dispositif mobile vers un numéro spécial. Un autre exemple de mode de réalisation de la présente invention peut être un système. Le système peut comprendre un réseau sans fil. Le système peut comprendre un fournisseur de services en communication avec le réseau sans fil. Le fournisseur de services peut être configuré pour, en réponse à la réception d'une demande d'utilisateur pour l'activation d'un service reçue sur le réseau sans fil, transmettre un ordre d'installation. Le système peut comprendre un dispositif mobile en communication avec le fournisseur de services sur le réseau sans fil. Le dispositif mobile peut être configuré pour, en réponse à une demande de service d'utilisateur au niveau d'un dispositif mobile, déterminer la disponibilité d'une application de service appropriée sur le dispositif mobile. Le dispositif mobile peut être configuré pour, si l'application de service appropriée n'est pas disponible sur le dispositif, transmettre une demande d'installation au fournisseur de services sur le réseau sans fil et activer le service demandé sur le dispositif mobile avec un ordre d'installation reçu. Le système peut comprendre une base de données stockant une liste d'applications de service installées sur le dispositif mobile. Le système peut comprendre un serveur en communication avec le réseau sans fil et le fournisseur de services, le serveur transférant des informations entre le dispositif mobile et le fournisseur de services. Le réseau sans fil peut supporter au moins un élément parmi : les communications de données et les communications vocales. L'homme du métier appréciera le fait que les exemples et les modes de réalisation précédents sont donnés à titre d'exemple et ne limitent pas la portée de la présente invention. II est entendu que toutes les permutations, améliorations, équivalences et combinaisons qui lui sont apportées sont apparentes pour l'homme du métier à la lecture de la spécification et à l'étude des dessins et sont comprises dans l'esprit et la portée de la présente invention. II est donc entendu que les revendications annexées qui suivent comprennent toutes ces modifications, permutations et équivalences dans l'esprit et la portée de la présente invention. REVENDICATIONS1. Procédé, comprenant : en réponse à une demande de service d'utilisateur au niveau d'un dispositif mobile, la détermination de la disponibilité d'une application de service appropriée sur le dispositif mobile ; et si l'application de service appropriée est disponible sur le service mobile, la réception d'un ordre d'activation pour un service demandé, et, l'activation du service demandé sur le dispositif mobile avec l'ordre d'activation. 2. Procédé selon la revendication 1, comprenant en outre : si l'application de service appropriée n'est pas disponible sur le dispositif mobile, le téléchargement de l'application de service appropriée sur le réseau sans fil, et l'exécution de l'application de service téléchargée. 3. Procédé selon la revendication 2, dans lequel l'ordre d'activation comprend une adresse WAP où l'application de service est disponible pour une installation. 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel le réseau sans fil est un réseau mobile terrestre public. 5. Procédé selon l'une quelconque des revendications 1 à 4, dans 25 lequel le dispositif mobile est un dispositif cellulaire. 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel l'ordre d'activation est un message de déclenchement d'architecture Push MIDP. 7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel l'application de service est une MIDIet. 8. Procédé selon l'une quelconque des revendications 1 à 7, dans 30lequel la demande d'activation de service est une demande USSD initiée côté mobile ou un appel sortant du dispositif mobile vers un numéro spécial. 9. Procédé, comprenant : en réponse à la réception d'une demande d'utilisateur pour l'activation d'un service sur un réseau sans fil à partir d'un dispositif mobile, la détermination de la disponibilité d'une application de service appropriée sur le dispositif mobile ; et si l'application de service appropriée n'est pas disponible sur le dispositif mobile, la transmission d'un ordre d'installation au dispositif mobile, et la transmission d'un ordre d'activation au dispositif mobile, l'ordre d'activation étant configuré pour exécuter l'application de service appropriée sur le dispositif mobile. 10. Procédé selon la revendication 9, dans lequel l'ordre d'installation comprend une adresse de téléchargement où l'application de service appropriée est disponible. 11. Procédé selon la revendication 10, dans lequel l'adresse de téléchargement est une adresse WAP. 12. Procédé selon l'une quelconque des revendications 9 à 11, comprenant en outre : la mise à jour d'un statut d'installation de 25 l'application de service appropriée sur le dispositif mobile. 13. Procédé selon l'une quelconque des revendications 9 à 12, dans lequel l'ordre d'activation est un message de déclenchement d'architecture Push MIDP. 14. Procédé selon l'une quelconque des revendications 9 à 13, dans lequel le réseau sans fil est un réseau mobile terrestre public. 15. Procédé selon l'une quelconque des revendications 9 à 14, dans 35 lequel le dispositif mobile est un dispositif cellulaire. 30 16. Procédé selon l'une quelconque des revendications 9 à 15, dans lequel l'application de service est une MlDlet. 17. Procédé selon l'une quelconque des revendications 9 à 16, dans lequel la demande d'activation de service est une demande USSD initiée côté mobile ou un appel sortant à partir du dispositif mobile à un numéro spécial. 18. Système, comprenant : un réseau sans fil ; un fournisseur de services en communication avec un dispositif mobile par le biais du réseau sans fil, le fournisseur de services étant configuré pour, en réponse à une demande de service d'utilisateur déterminer la disponibilité d'une application de service appropriée sur le dispositif mobile, si l'application de service appropriée est disponible sur le service mobile, transmettre un ordre d'activation au dispositif mobile sur le réseau sans fil, et si l'application de service appropriée n'est pas disponible sur le dispositif mobile, transmettre un ordre d'installation au dispositif mobile sur le réseau sans fil. 19. Système selon la revendication 18, comprenant en outre : une base de données stockant une liste d'applications de service installées sur le dispositif mobile. 20. Système selon la revendication 18 ou 19, comprenant en outre : un serveur en communication avec le réseau sans fil et le fournisseur de services, le service transférant des informations entre le dispositif mobile et le fournisseur de services. 21. Système selon l'une quelconque des revendications 18 à 20, dans lequel le réseau sans fil supporte au moins un élément parmi : des 35 communications de données et des communications vocales.