FR 2819131 A1 20020705 FR 0017207 A 20001228 PROCEDE ET ARCHITECTURE DE COMMUNICATION ENTRE UN SERVEUR ET UN EQUIPEMENT DE TELEPHONIE MOBILE VIA UN RESEAU DE TYPE INTERNE ET UN RESEAU DE TELEPHONIE MOBILE L'invention concerne un procédé de communication entre un serveur et un équipement de téléphonie mobile comprenant un système embarqué à puce électronique via un réseau de type Internet et au moins un segment de transmissions de téléphonie mobile. Elle s'applique plus particulièrement aux téléphones mobiles du type stockant des applications embarquées sur une carte munie de moyens de traitement de l'information et de mémorisation, incluant un module fonctionnel connu sous l'abréviation"SIM" (pour"Subscriber Identity Module" ou"Module d'identification d'abonné"). Il s'agit notamment d'appliquettes (ou "applets"selon la terminologie anglo-saxonne) accédant à des services existants sur des serveurs d'entreprises, via un réseau de type Internet. L'invention concerne encore une architecture pour la mise en oeuvre du procédé. Dans le cadre de l'invention, le terme"réseau"doit être compris dans son sens le plus général. Notamment, en ce qui concerne le segment de transmissions de téléphonie mobile, le réseau inclut les composants de transmission proprement dits du réseau (sous-systèmes de radiotransmission, câbles de transmissions, faisceaux hertziens, sous- systèmes"filaires"terrestres, etc. ), mais aussi tous les systèmes raccordés au réseau de téléphonie mobile (stations de base, contrôleurs de station, commutateurs, annuaires, etc., et, de façon plus générale, tous systèmes de traitement informatique de données et serveurs raccordés au réseau), y compris les postes, équipements ou stations mobiles détenus par les utilisateurs (abonnés) du réseau de téléphonie mobile. Une des normes les plus utilisées en Europe est la norme de transmission"GSM" (acronyme pour"Groupe spécial Systèmes Mobiles publics de radiocommunications fonctionnant dans la bande des 900 MHz"). Les équipements de téléphonie mobile, qui forment les systèmes embarqués à puce électronique précités, peuvent être des téléphones portatifs ou des terminaux plus complexes, par exemple un terminal cumulant les fonctionnalités de téléphone et d'organiseur. Pour simplifier, sans restreindre en quoi que ce soit la portée de l'invention, ces dispositifs seront appelés ci-après"téléphones mobiles". Egalement pour simplifier, on supposera ci-après que le module "SIM"est porté par une carte à puce. Un logiciel d'exploitation de la carte à puce est également prévu (dit"OS", pour"Operating System"). Dans l'état actuel des techniques, les téléphones mobiles des réseaux"GSM"ne sont plus seulement utilisés pour téléphoner. On peut les utiliser aussi pour traiter et envoyer des données numériques. Dans le cadre de l'invention, le terme"Internet"doit également être compris dans son sens le plus général. Il englobe, outre le réseau Internet proprement dit, les réseaux privés d'entreprises ou similaires, du type dit "Intranet", et les réseaux les prolongeant vers l'extérieur, du type dit "Extranet", de façon générale tout réseau dans lequel les échanges de données s'effectuent selon un protocole du type Internet. Cependant pour fixer les idées, sans que cela limite en quoi que ce soit la portée de l'invention, on se placera ci-après dans le cas du réseau Internet proprement dit, sauf mention contraire. Il existe aujourd'hui en téléphonie mobile deux technologies principales de développement d'applications de type dit"client/serveur" : 1) La technologie dite"WAP" (pour"Wireless Application Protocol"), dans laquelle l'application cliente est un logiciel navigateur s'exécutant dans le téléphone mobile et, plus généralement, dans un équipement mobile du type système embarqué à puce électronique. Ce standard a pour but de permettre à des utilisateurs d'accéder au réseau Internet à partir de leurs téléphones mobiles, via une liaison sans fil. 2) La technologie dite"SIM Toolkit", où l'application cliente s'exécute dans la carte"SIM". Cette technologie repose sur des interfaces programmatiques offrant une grande richesse de fonctionnalités dans la partie"client"de l'application. Cette technologie fait d'ores et déjà partie des services complémentaires offerts par certains opérateurs de téléphonie mobile des réseaux"GSM". De façon pratique, une pièce de logiciel spécifique est implémentée dans la carte à puce"SIM"du téléphone. Les fonctionnalités apportées par cette norme permettent de développer un très grand nombre d'applications distinctes sur la carte à puce, ce dans le but de fournir aux utilisateurs des services dits"à valeur ajoutée". Pour une description plus détaillée de la technologie"Sim Toolkit", on se reportera avec profit à la norme"GSM 11.14". La technologie"WAP"a, certes, des avantages, par exemple celui d'utiliser les standards d'Internet côté serveur. Les services sont développés avec les mêmes architectures que ceux développés pour Internet. Par contre, la technologie"WAP"n'est pas sans inconvénients. Le contenu des services peut être développé soit en langage dit"WML" (pour"Wireless Markup Language"), auquel cas les outils existant pour le développement en langage"HTML" (pour"HyperText Markup Language") ne peuvent pas être tous utilisés, soit sous forme plus conventionnelle, directement à l'aide du langage"HTML", auquel cas une passerelle de traduction"HTML-WML"est nécessaire. En outre, dans le cas du"WAP", l'application cliente reste limitée à des fonctionnalités offertes par un simple navigateur qui demande des pages aux serveurs et les interprète. Une autre limitation de la technologie "WAP"est la nécessité d'utiliser des téléphones mobiles intégrant un navigateur"WAP". Or un navigateur"WAP"est d'un type spécifique, car il présente des caractéristiques différentes des navigateurs de type"WEB" classiques. Enfin, bien que cette technologie présente l'avantage de permettre l'accès au réseau Internet, elle ne couvre pas toutes les fonctionnalités des applications"Sim Toolkit". A titre d'exemple non limitatif, une application"WAP"ne peut pas, comme dans le cas des applications "Sim Toolkit", commander des appels téléphoniques. De plus, une application"WAP"ne peut pas garantir le même degré de sécurité que celui offert par les applications"Sim Toolkit". En effet, celles-ci utilisent des clés secrètes enregistrées dans les cartes à puce"SIM". Par exemple, une application"WAP"ne peut pas demander l'authentification d'une application sur un serveur quelconque. Pour sa part, la technologie"SIM Toolkit", outre le fait d'assurer un grand degré de sécurité, a l'avantage d'offrir des interfaces programmatiques standards lui offrant une grande richesse de fonctionnalités pour la partie cliente de l'application, appelée appliquette ou"applet", selon la terminologie anglo-saxonne. Elle n'est cependant pas non plus dépourvue d'inconvénients. En particulier, il n'existe aucun standard établi pour le développement des services côté serveur. Les fournisseurs de serveurs offrent en conséquence des interfaces programmatiques propriétaires bâties sur des protocoles également propriétaires. Cette contrainte constitue un inconvénient, non seulement du fait de l'aspect"propriétaire"en soi, mais surtout du fait que les développeurs d'une application donnée doivent tenir compte d'un grand nombre de paramètres et exigences qui ne sont pas liés directement à cette application : grand degré de parallélisme à assurer (c'est-à-dire plusieurs requêtes clientes arrivant sur le serveur en même temps), niveau de performances du serveur, etc. Il serait donc hautement souhaitable de dissocier les aspects liés étroitement aux caractéristiques du serveur et à son contexte (transmissions, protocoles, etc) des aspects liés au développement des applications proprement dit. Il serait notamment souhaitable que les applications puissent être développées selon des procédures standards et que le protocole Internet également standard"HTTP" (pour"HyperText Transfer Protocol) puisse être mise en oeuvre. L'invention vise à pallier les inconvénients des procédés de l'art connu, et dont certains viennent d'être rappelés, et à répondre aux besoins qui se font sentir. Aussi, le procédé de l'invention propose, en mettant en oeuvre) la technologie"SIM Toolkit"précitée, une solution permettant la connexion des "applets"du client aux services standards Internet. Le développement d'applications repose alors sur des standards, ce aussi bien du côté client que du côté serveur, contrairement à l'art connu. Les outils classiques de développement Internet peuvent donc être utilisés aussi pour des applications serveur, et un téléphone mobile supportant la technologie"SIM Toolkit", de façon plus générale un équipement mobile, peut être utilisé pour des applications clientes. Pour ce faire, selon une caractéristique avantageuse, il est fourni, selon le procédé de l'invention, une application de type serveur dont le rôle est celui d'une passerelle entre les téléphones mobiles et les serveurs. La fonction principale de cette passerelle est de transformer des messages de requêtes provenant des téléphones mobiles en requête"HTTP", donc selon un protocole standard Internet. L'invention a donc pour objet principal un procédé de communication entre un serveur et un équipement de téléphonie mobile comprenant un système embarqué à puce électronique via un réseau de type Internet et au moins un réseau de téléphonie mobile, lesdits réseaux transmettant des données selon un premier protocole, de type Internet, et un second protocole, de type téléphonie mobile, respectivement, ledit équipement mobile stockant au moins une application posant des requêtes d'accès à un service localisé dans ledit serveur et transmises sous la forme de messages numériques véhiculant des données émises par ledit équipement de téléphonie mobile, lesdits réseaux étant connectés l'un à l'autre via une première passerelle d'interface et de conversion bilatérale desdits premier et second protocoles de transmission, caractérisé en ce qu'il comprend une conversion supplémentaire transformant lesdites requêtes provenant d'un équipement mobile en requêtes selon le protocole Internet de type"HTTP"et la transmission de ces requêtes aux dits services sans modifications desdites données véhiculées par lesdits messages numériques, en ce que lesdits services sont des services standards d'un serveur"HTTP", et en ce que, lesdits messages véhiculant au moins un premier paramètre constitué par un identificateur de chacune desdites applications stockées dans ledit équipement mobile, il comprend, à partir de cet identificateur, la génération d'une adresse Internet du type"URL", pointant sur un desdits services. L'invention a encore pour objet une architecture pour la mise en oeuvre de ce procédé. L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : Les figures 1A et 1B représentent schématiquement une architecture selon l'art connu, respectivement physique et logique, d'un système permettant des communications entre un équipement de téléphonie mobile et un serveur via un segment de téléphonie mobile et un réseau de type Internet ; Les figures 2A et 2B représentent schématiquement un exemple d'architecture selon l'invention, respectivement physique et logique, d'un système permettant des communications entre un équipement de téléphonie mobile et un serveur via un segment de téléphonie mobile et un réseau de type Internet ; - la figure 3 illustre schématiquement un exemple de réalisation pratique d'architecture selon l'invention ; et - la figure 4 est une figure de détail illustrant une variante de réalisation d'une l'architecture selon l'invention. Dans ce qui suit, sans en limiter en quoi que ce soit la portée, on se placera ci-après dans le cadre de l'application préférée de l'invention, sauf mention contraire, c'est-à-dire dans le cas d'un téléphone mobile stockant des"applets"embarqués sur une carte"SIM". On va tout d'abord rappeler brièvement un exemple d'architecture selon l'art connu par référence aux figures 1A et 1 B. La figure 1A représente schématiquement l'architecture physique d'un système permettant des communications entre un téléphone mobile 1 et un serveur 3. Le poste téléphonique portable 1, comprend des circuits électroniques classiques : mémoires, processeur, etc. (non représentés). Ces derniers peuvent être couplés à une carte à puce"SIM"10 à l'aide d'un lecteur (non représenté). La carte à puce"SIM"10 comprend également des circuits électroniques classiques (non représentés), notamment un processeur et des moyens de mémoire dans lesquels peuvent être enregistrées des applications"Sim Toolkit", sous la forme d'une ou plusieurs "applet (s)", sous la référence générale A. Le téléphone mobile 1 est relié à un réseau mobile de transmission RM, par exemple à la norme"GSM"précitée. Ce type de réseau est bien connu de i'Homme de Métier. Il n'est donc pas nécessaire de le décrire plus avant, ni ses différents composants. On pourra se référer avec profit, à titre d'exemple non limitatif, à l'article de jean CELLMER, intitulé"Réseaux cellulaires, Système GSM", paru dans les "Techniques de l'Ingénieur", Volume TE 7364, novembre 1999, pages 1 à 23. Le réseau mobile RM est connecté à un réseau de type Internet Rl via une passerelle"Serveur", d'un type classique dit"O. T. A." (pour"Over The Air") 2. Cette passerelle 2 assure des fonctions de conversion de protocole et d'interface bien connues. Des serveurs, dont un seul 3 a été représenté, sont connectés au réseau Internet Rl, directement ou via des pare-feu ("fire-wall") et un éventuel réseau Intranet (non représentés). Le serveur 3 assure des services 4, représentés sous la référence unique 4. Ces services sont, comme il a été indiqué constitués d'applications propriétaires. La figure 1B est une représentation logique schématique de l'architecture physique représentée sur la figure 1A. Pour fixer les idées, on a supposé que la carte"SIM"10 (figure 1A) stockait n applications, constituées par exemple par des"applets" référencées AM1,..., AMX,..., AMn ; la lettre M désignant le côté"téléphone mobile". Dans l'exemple de réalisation représenté sur la figure 1 B, on considère que les communications sur le tronçon de réseau"sans fil', c'est-àdire le réseau de téléphonie mobile RM, s'effectuent en utilisant la technologie dite de"service à messages courts" (service dit"GSM-Data"), connue sous le sigle"SMS" (pour"Short Message Service"), suivant l'une des deux normes ETSI 03.40 ou ETSI 03. 48. Ces messages ont typiquement une longueur de 160 septets ou de 140 octets, selon les applications. Conformément à ces normes, l'identificateur d'un service (ou numéro de service) pour une"applet"est appelé"TAR" ("Toolkit Applet Reference") et est codé sur 3 octets. Les identificateurs de services ont été référencés N1 à Nn. Lorsque le téléphone mobile 1 requiert un des services 4, offert par un serveur 3, et correspondant à l'une des applications AM1 à AMn, par exemple l'application AMX, un message"SMS"est transmis au serveur 3, via les différents segments du réseau global, RM et Rl, et la passerelle"O. T. A." 2. Le message en question véhicule notamment l'identificateur (TAR") de l'application AMX, soit Nx, c'est-à-dire également celui du service correspondant. Les applications des services 4 ont été référencées AS1,.... ASx,..., Asn ; la lettre S désignant le"côté serveur". Le message permet donc d'adresser le service Asx du serveur 3. Comme il a été rappelé, chaque application propriétaire Asx doit pouvoir gérer un certain nombre de contraintes : parallélisme, génération de "threads", de nouvelles instances de l'application, etc., ce qui constitue un inconvénient important. En outre, les développeurs d'applications peuvent ne pas posséder les compétences nécessaires pour traiter ce type de problèmes, non directement liés aux services 4 à offrir par le serveur 3 en réponse à une requête du"client", c'est-à-dire du téléphone mobile 1 (figure 1A). Un exemple d'architecture pour la mise en oeuvre d'un mode de réalisation du procédé selon l'invention va maintenant être décrit par référence aux figures 2A et 2B. Comme précédemment, la figure 2A est relative à une architecture physique et la figure 2B est une représentation logique schématique de cette architecture physique. Sur ces figures, les éléments identiques aux figures 1A et 1B portent les mêmes références et ne seront re-décrits qu'en cas de besoin. On retrouve en effet les principaux composants de l'architecture de la figure 1A : téléphone mobile 1, réseau de téléphonie mobile MB, passerelle"O. T. A." 2, réseau Internet 3. Les services présents sur le serveur 3 sont désormais référencés 4', pour la raison qui va être développée ciaprès. Par contre, l'interconnexion entre le réseau Internet RI et le réseau de téléphonie mobile (sans fil) MB, et sa passerelle"O. T. A." 2, ne s'effectue plus directement, mais via une passerelle supplémentaire 5, disposée en cascade. Il s'agit d'une application serveur. La fonction principale de cette passerelle 5 est de transformer les messages des requêtes provenant des téléphones mobiles, par exemple du téléphone mobile 1, en requête au protocole"HTTP", un des protocoles standards de transmission sur le réseau Internet, comme il a été rappelé. Comme le montre la figure 2A, la chaîne de liaison d'un téléphone mobile 1 jusqu'au serveur"HTTP"3 devient transparente pour le développement d'applications client/serveur pour les téléphones mobiles. De cette manière, un service"HTTP"peut être développé en utilisant les outils et plates-formes standards de développement bien connus en technologie Internet, tels que les"servlets","ASP" (pour"Active Server Pages"),"JSP" (pour"Java Server Pages"),"ASP","JSP"et"JAVA"étant des marques déposées,"JavaScript", applications ou scripts"CGI" (pour "Common Gateway Interface"), etc. En d'autres termes, les applications développées deviennent standards. Elles ont été référencées A's1,.... 'Sx,...,/\'sn, sur) a figure 2B. Les messages"SMS"véhiculent toujours les identificateurs ("TAR"), N1 à Nn. Cette disposition reste inchangée. Selon une caractéristique du procédé selon l'invention, la passerelle 5 comporte un service d'administration maintenant une correspondance entre les identificateurs ("TAR"), N1 à Nn, les "applets SIM ToolKit", Am1,..., AMx,.... AMn, et des adresses Internet de type"URL" (pour"Unified Resource Locator") permettant l'accès aux services correspondants : applications ications A's1,..., A'Sx,..., A'sn. Les applications standards, A's1,..., A'sx,..., A'sn, peuvent se présenter sous la forme d'objets informatiques appelés"servlets", en langage"JAVA" (marque déposée), bien connus dans la technologie Internet. Ces"servlets"peuvent être stockés dans ce qui est appelé des conteneurs ou"containers"selon la terminologie anglo-saxonne. La passerelle 5 reçoit du téléphone mobile 1 une requête contenant des données utilisateur formatées par une"applet SIM ToolKit", par exemple AMx, qui comportent, entre autre, l'identificateur de cette "applet", soit Nx. La passerelle 5 identifie alors l' "URL" du service correspondant à cet identificateur ("TAR") Nx del'"applet SIM ToolKit"/\Mx et envoie une requête"HTTP"à l'adresse"URL"correspondante, en y joignant les données émise par l'utilisateur, c'est-à-dire le téléphone mobile 1. Cette opération est effectuée en préservant l'intégrité des données émises. En d'autres termes, le processus reste transparent pour l'utilisateur ou client. Après traitement de la requête"HTTP", le service (application A'Sx, dans l'exemple décrit) transmet sa réponse sous la forme de données formatées à la passerelle 5, qui à son tour se charge de la faire parvenir au téléphone mobile 1. Selon le procédé de l'invention, le développement de solutions Internet pour un téléphone mobile (ou plus généralement un équipement de téléphonie mobile comprenant un système embarqué à puce électronique) revient alors à ne s'intéresser qu'au développement d'une"applet SIM Toolkit"sur le téléphone mobile ainsi qu'au service Internet associé sur le serveur, sans se préoccuper d'autres contraintes. En effet, les applications standards"HTTP"savent gérer ces contraintes : traitement en parallèle extensif, génération de nouvelles instances d'une même application, etc. On doit bien comprendre que la passerelle 5, bien qu'il soit suggéré sur la figure 2A qu'elle soit à proximité de la passerelle"O. T. A." 2, peut être avantageusement localisée dans l'enceinte du serveur 3 ou en front de ce serveur. On va maintenant décrire, en regard de la figure 3, un exemple de réalisation pratique d'une architecture pour la mise en oeuvre du procédé selon l'invention. Sur ces figures, les éléments identiques aux figures précédentes portent les mêmes références et ne seront re-décrits qu'en tant que de besoin. Les communications entre le téléphone mobile 1 et le serveur "O. T. A." 2 s'effectuent à l'aide messages courts"SMS", comme précédemment. Les communications entre le serveur"O. T. A" 2 et la passerelle 5 sont effectuées à l'aide d'une conversion de protocole, mais sur une session au protocole"TCP/IP" (pour"Transport Control Protocol/tnternet Protocol"), qui caractérise la couche protocolaire dite de transport. Les données émises par le client (téléphone mobile 1) sont transmises sans modifications. Par définition, la passerelle 5, qui est conforme à l'une des caractéristiques de l'invention, est constituée de circuits spécifiques. Elle comprend notamment une table 50 associant les identificateurs ("TAR"), N1 à Nn, des applications "client", AM1 à AMn, (figure 2B) à des adresses "URL", URL1,..., URLx,..., URLn, associées aux adresses des services correspondant aux applications"client"précitées. De façon pratique, la table 50 peut être réalisée à l'aide de positions de mémoire, de registres ou d'organes similaires. Le serveur 3 comprend un serveur"HTTP"30 proprement dit. De façon pratique, afin de faciliter l'implémentation des services sous forme de"servlets"précitées, une"API" (pour"Application Programming Interface") unique 31, que l'on peut appeler"O. T. A. Servlet API"est avantageusement fournie aux développeurs d'applications. Cette "API"leur permet de disposer des paramètres habituels des messages courts tels que : heure d'émission, numéro de téléphone, format des données, etc., sans avoir à effectuer eux-mêmes une programmation spécifique de chaque application constituant un des services offerts par le serveur. Le développement d'une"API"est une tâche à la portée de l'Homme de Métier et ne nécessite pas d'être décrite plus avant. En d'autres termes, cette"API"permet notamment de connaître la configuration des champs des messages"SMS"transmis par le téléphone mobile 1 au serveur "HTTP"30. Pour traiter les requêtes reçues et pour certains types d'application, les"servlets"peuvent accéder à des composants dits de métiers tels que des"EJB" ("Enterprise Java Beans"), afin de satisfaire des traitements requerrant l'accès à des bases de données, par exemple. Ces composants ont été représentés, sur la figure 3, stockés dans un conteneur particulier 34. Le serveur 3 peut stocker également d'autres composants, tels des "servlets""O. T. A" 32 ou d'autres types de"servlets", sous la référence unique 33. Dans des variantes supplémentaires du procédé selon l'invention, les "URLs" peuvent être fonction non seulement de l'identificateur d'application appelante ("TAR"), mais aussi d'un ou plusieurs autres paramètres tels que, par exemple, le numéro de téléphone du client (téléphone mobile 1). La figure 4 illustre schématiquement une table, référencée 50', associée à la passerelle 5 (figure 3) à deux séries d'entrées, symbolisées par une colonne identifiants, N1 à Nx et une colonne numéros de téléphones, Tell à 7einz et une série de sorties : colonne, URL 1 à URLn. Il s'ensuit qu'une"URL"particulière, par exemple URLx, est donnée par la fonction suivante : URLx = f (Nx, Telex) A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés. Elle présente de nombreux avantages, et notamment les suivants : - les applications embarquées sur les téléphones mobiles, par exemple des"applets"embarquées sur une carte"SIM", peuvent d'accéder aux services existants sur des serveurs d'entreprises, à la technologie"HTTP" - aucune modification n'est nécessaire dans l'implémentation de ces services, et tous les standards d'aujourd'hui sur Internet peuvent être utilisés pour fournir des services en lignes à un téléphone mobile, de façon plus générale à un système embarqué à puce électronique ; et - la chaîne de liaison entre une application cliente du téléphone mobile et application serveur est implémentée de façon transparente. Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 2A à 4. En particulier, les transmissions sur le segment de téléphonie sans fil peuvent s'effectuer selon d'autres normes que la norme"GSM"précitée. On peut citer, à titre d'exemples non limitatifs, les normes"GPRS"ou"UTMS", en cours d'implémentation. Bien que l'on ait supposé implicitement que tous les services correspondant aux applications"SIM Toolkits"d'un équipement mobile étaient implémentés sur un même serveur, il tout à fait possible de les répartir sur plusieurs serveurs"HTTP"qui seront adressés grâce aux"URLs" déduites des identificateurs d'applications et, éventuellement, de paramètres supplémentaires, comme explicité en regard de la figure 4. REVENDICATIONS 1. Procédé de communication entre un serveur et un équipement de téléphonie mobile comprenant un système embarqué à puce électronique via un réseau de type Internet et au moins un réseau de téléphonie mobile, lesdits réseaux transmettant des données selon un premier protocole, de type Internet, et un second protocole, de type téléphonie mobile, respectivement, ledit équipement mobile stockant au moins une application posant des requêtes d'accès à un service localisé dans ledit serveur et transmises sous la forme de messages numériques véhiculant des données émises par ledit équipement de téléphonie mobile, lesdits réseaux étant connectés l'un à l'autre via une première passerelle d'interface et de conversion bilatérale desdits premier et second protocoles de transmission, caractérisé en ce qu'il comprend une conversion supplémentaire transformant lesdites requêtes provenant d'un équipement mobile (1) en requêtes selon le protocole Internet de type "HTTP"et la transmission de ces requêtes aux dits services (4') sans modifications desdites données véhiculées par lesdits messages numériques, en ce que lesdits services sont des services standards d'un serveur"HTTP" (3), et en ce que, lesdits messages véhiculant au moins un premier paramètre constitué par un identificateur (N1-Nn) de chacune desdites applications (AM1-AMn) stockées dans ledit équipement mobile (1), il comprend, à partir de cet identificateur (N1-Nn), la génération d'une adresse Internet (URLI-URLn) du type"URL", pointant sur un desdits services (4'). 2. Procédé selon la revendication 1, caractérisé en ce que le dit second protocole de transmission est conforme à la norme"GSM"et en ce que lesdites applications (AM1-AMn) stockées dans ledit équipement mobile (1) sont des applications du type dit"SIM Toolkit", conformes à la norme "GSM 11. 14". 3. Procédé selon la revendication 1, caractérisé en ce que lesdits messages numériques sont du type dit de"service à messages courts" ("SMS"), conformes aux normes"ETSI 03. 40" ou"ETSI 03. 48". 4. Procédé selon la revendication 1, caractérisé en ce que ladite génération d'adresses"URL"s'effectue à l'aide d'une table (50) associant au moins une première série d'entrées constituées par lesdits identificateurs (N1-Nn) d'applications (AM1-AMn) et une série de sorties constituées par lesdites adresses"URL" (L/RL1-L/RL/ ?), chacune desdites adresse"URL"pointant sur un desdits services (4'). 5. Procédé selon la revendication 1, caractérisé en ce que, lesdits messages véhiculant au moins des deuxièmes paramètres (Tell-Tein) associés à chacune desdites applications (AM1-AMn) stockées dans lesdits équipements de téléphonie mobile (1), ladite génération d'adresses "URL" (URLI-URLn) s'effectue à l'aide d'une table (50) comprenant au moins une première série d'entrées constituées par lesdits identificateurs (N1-Nn) d'applications (AM1-AMn) et une deuxième série d'entrées constituées par lesdits deuxièmes paramètres (Te/1-Teln), et en ce que ladite génération d'adresses"URL" (L ? L1-L ? Ln) est obtenue par l'association d'une combinaison constituée desdits premiers (N1-Nn) et deuxièmes (Tell-Tein) paramètres avec une série de sorties constituées par lesdites adresses "URL" (URL1-URLn), chacune desdites"URL" (L/RL1-L/RL/ ?) pointant sur un desdits services (4'). 6. Procédé selon la revendication 1, caractérisé en ce que lesdits services sont constitués par des objets informatiques du type dit"servlet". 7. Architecture d'un système de transmission de données numériques pour mettre en communication un serveur et un équipement de téléphonie mobile comprenant un système embarqué à puce électronique via un réseau de type Internet et au moins un réseau de téléphonie mobile, lesdits réseaux transmettant des données selon un premier protocole, de type Internet, et un second protocole, de type téléphonie mobile, respectivement, ledit équipement mobile stockant au moins une application posant des requêtes d'accès à un service localisé dans ledit serveur et transmises sous la forme de messages numériques véhiculant des données émises par ledit équipement de téléphonie mobile, lesdits réseaux étant connectés l'un à l'autre via une première passerelle d'interface et de conversion bilatérale desdits premier et second protocoles de transmission, caractérisée en ce qu'elle comprend une seconde passerelle (5), disposée en cascade avec ladite première passerelle (2) et opérant une conversion supplémentaire transformant lesdites requêtes provenant d'un équipement mobile en requêtes selon le protocole Internet de type"HTTP"et transmettant ces requêtes aux dits services (4') du serveur (3), sans modifications desdites données véhiculées par lesdits messages numériques, en ce que lesdits services (4') sont des services standards d'un serveur"HTTP" (3), et en ce que, lesdits messages véhiculant au moins un premier paramètre constitué par un identificateur (N1-Nn) de chacune desdites applications (URL1-URLn) stockées dans ledit équipement mobile (1), ladite seconde passerelle (5) comprend une table (50) associant au moins un identificateur (N1-Nn) à une adresse Internet (URL 1-URLn) du type "URL" associée à un desdits services (4'), de manière à aiguiller ladite requête vers ce service. 8. Architecture selon la revendication 7, caractérisée en ce que ledit équipement de téléphonie mobile est un téléphone mobile (1). 9. Architecture selon la revendication 8, caractérisée en ce que ledit téléphone mobile comprend une carte à puce électronique (10), lesdites applications (AM1-AMn) étant stockées par des moyens de mémoire de ladite puce électronique.