FR2846174A1 - Systeme de telecommunications entre un terminal mobile et un serveur via internet - Google Patents

Abstract

Pour rechercher une information, un terminal mobile (TM) dialogue en mode PUSH avec un serveur (SW) relié à internet (RP). Une information demandée (OCV) pouvant dépendre de la localisation géographique du terminal et incluse dans une première requête en mode PULL depuis le terminal via un serveur d'accès (SA) peut être indisponible dans une base de données (BI) du serveur (SW). Si l'information demandée (OCV) est trouvée postérieurement dans la base, un moteur de recherche (MR) génère un message (MCR) pour commander dans un serveur initiateur (PI) la transmission d'une deuxième requête (RQ2) contenant l'adresse URL de l'information demandée au terminal mobile (TM) via un serveur de message court (SC) ou une passerelle proxy PUSH (PPG) au cours d'une deuxième session.

Description

Système de télécommunications entre un terminal mobile et un serveur via

internet La présente invention concerne de manière 5 générale des communications pour des services entre un terminal radiotéléphonique mobile dans un réseau de radiotéléphonie cellulaire et un serveur d'information relié à un réseau de paquets à débit

élevé tel qu'internet.

Actuellement, les échanges entre des terminaux d'usager fixes et un serveur d'information web à travers le réseau internet fonctionnent selon un dialogue client/usager-serveur. Chaque usager décide 15 d'interroger le serveur pour récupérer des

informations lues dans le serveur au moyen de requêtes transmises depuis le terminal d'usager vers le serveur et de réponses du serveur au terminal. Ce mode de fonctionnement fondé sur l'initiative de 20 l'usager qui est "actif", est appelé mode PULL.

A contrario, dans un autre mode appelé mode PUSH plus récent, utilisé principalement pour transmettre de la publicité aux usagers, le serveur décide de transmettre des requêtes avec de l'information ciblée 25 vers un ou plusieurs terminaux d'usager fixes. Chaque

usager dont le terminal reçoit une requête en mode PUSH est "passif" puisqu'il reçoit de l'information sans l'avoir demandée, c'est-à-dire sans action préalable dans son terminal pour obtenir 30 l'information.

Pour un terminal radiotéléphonique mobile dans lequel est implémenté un mini-navigateur pour le protocole de communication WAP (Wireless Application Protocol), seulement le mode PULL pour transmettre des requêtes à un serveur (portail) WAP à travers le

réseau internet est possible.

Par ailleurs, dans le cadre du service de messages courts SMS (Short Message Service), le mode 5 PUSH est principalement utilisé. Un serveur de message court SMSC (Short Message Service Center) transmet en effet des messages vers un terminal d'usager à la requête du terminal d'un autre usager, fixe ou mobile. Mais le mode PULL est également mis 10 en oeuvre dans le service SMS puisqu'un terminal d'usager est capable d'envoyer un message court vers

un terminal d'un autre usager destinataire.

La présente invention vise à pallier l'absence 15 du mode PUSH dans des communications entre un

terminal radiotéléphonique mobile et un serveur d'information à travers le réseau internet et le réseau de radiotéléphonie desservant le terminal.

Grâce à l'invention, la transmission d'information 20 par le serveur au terminal d'usager peut être

différée, particulièrement à la suite d'une requête d'information qui est transmise par le terminal en mode PULL et qui est ainsi mise en attente dans le serveur tant que l'information requise n'est pas 25 disponible dans le serveur.

A cette fin, un système de télécommunications entre un terminal radiotéléphonique mobile dans un réseau de radiotéléphonie cellulaire et un serveur 30 d'information connecté à un réseau de paquets qui est relié au réseau de radiotéléphonie à travers un serveur d'accès, est caractérisé en ce que le serveur d'information comprend un moyen pour mémoriser temporairement une première requête contenant un 35 identificateur du terminal mobile et transmise au cours d'une première session depuis le terminal mobile à travers le serveur d'accès lorsqu'une information demandée dans la première requête n'est pas disponible dans une base de données liée au 5 serveur d'information, un moyen pour rechercher périodiquement l'information demandée dans la base de données, et un moyen pour générer un message de commande de requête au début d'une deuxième session entre le serveur d'information et le terminal mobile 10 dès que l'information demandée est trouvée dans la base de données par le moyen pour rechercher, et le système comprend un moyen requérant pour transmettre une deuxième requête au terminal mobile au cours de la deuxième session en réponse au message de commande 15 de requête transmis par le serveur d'information à

travers le réseau de paquets.

Selon une première réalisation, le moyen requérant peut comprendre un serveur initiateur de requête relié au réseau de paquets pour créer une 20 deuxième requête encapsulée dans au moins un message court en réponse au message de commande de requête transmis par le serveur d'information et après qu'un identificateur du terminal mobile contenu dans le message de commande de requête soit reconnu dans une 25 base de données liée au serveur initiateur, et un moyen pour transmettre le message court relatif à la deuxième requête vers le terminal mobile à travers le

réseau de radiotéléphonie.

Selon une deuxième réalisation, le moyen 30 requérant peut comprendre un serveur initiateur de requête relié au réseau de paquets pour créer au moins une deuxième requête selon un protocole d'accès en mode PUSH en réponse au message de commande de requête transmis par le serveur d'information et 35 après qu'un identificateur du terminal mobile contenu dans le message de commande de requête soit reconnu dans une base de données liée au serveur initiateur, et une passerelle proxy pour transmettre la deuxième requête au terminal mobile à travers le réseau de 5 radiotéléphonie selon un protocole de transport analogue à celui entre le terminal mobile et le

serveur d'accès.

Selon encore une autre réalisation, les première et deuxième réalisations sont combinées. Dans cette 10 autre réalisation, le moyen requérant peut comprendre un serveur initiateur de requête relié au réseau de paquets pour créer une deuxième requête encapsulée dans au moins un message court lorsqu'un identificateur du terminal mobile contenu dans le 1 5 message de commande de requête est reconnu en association avec une adresse de serveur de message court dans une base de données liée au serveur initiateur et pour créer une autre deuxième requête lorsque l'identificateur du terminal mobile est 20 reconnu en association avec une adresse de passerelle proxy dans la base de données liée au serveur initiateur, en réponse au message de commande de requête transmis par le serveur d'information, un moyen pour transmettre le message court relatif à la 25 deuxième requête vers le terminal mobile à travers le

réseau de radiotéléphonie, et une passerelle proxy pour transmettre l'autre deuxième requête au terminal mobile à travers le réseau de radiotéléphonie selon un protocole de transport analogue à celui entre le 30 terminal mobile et le serveur d'accès.

Selon un autre aspect de l'invention, le système de télécommunications est utilisé dans certaines applications pour exploiter la localisation géographique du terminal mobile, par exemple pour 35 transmettre des offres de covoiturage au terminal

mobile en fonction de la localisation de celui-ci.

Dans ce cas, le serveur d'information peut comprendre un moyen pour identifier une cellule du réseau de radiotéléphonie o le terminal mobile est situé dès 5 que le serveur d'information reçoit la première requête, et un moyen pour sélectionner au moins le nom d'une ville sensiblement située dans le voisinage de la cellule identifiée afin de transmettre au terminal mobile le nom de la ville dans une réponse à 10 la première requête à travers le serveur d'accès entre le réseau de paquets et le réseau de radiotéléphonie. D'autres caractéristiques et avantages de la 15 présente invention apparaîtront plus clairement à la

lecture de la description suivante de plusieurs réalisations préférées de l'invention en référence

aux dessins annexés correspondants dans lesquels: - la figure 1 est un bloc-diagramme schématique 20 d'un système de télécommunications selon une réalisation complète préférée combinant les réalisations selon les figures 2 et 3; - la figure 2 est un bloc-diagramme schématique d'un système de télécommunications selon une première 25 réalisation de l'invention relative à la transmission de deuxièmes requêtes à travers un serveur de message court; et - la figure 3 est un bloc-diagramme schématique d'un système de télécommunications selon une deuxième 30 réalisation de l'invention relative à la transmission de deuxièmes requêtes à travers une passerelle proxy

en mode PUSH.

Dans la figure 1, on a représenté 35 schématiquement les principaux réseaux de télécommunications et les principaux moyens fonctionnels intervenant dans un système de télécommunications entre un terminal radiotéléphonique mobile TM d'un usager US et un 5 serveur d'information SW pour échanger entre eux des

messages du type requêtes et réponses.

Le terminal radiotéléphonique TM est inclus dans un réseau de radiotéléphonie cellulaire numérique RR de type GSM dont la partie fixe est schématisée par 10 la zone de localisation o le terminal mobile TM est situé à un instant donné. La partie fixe du réseau RR contient une station de base BTS qui couvre la cellule radio CEL o se trouve le terminal TM à un instant donné. La station de base BTS est reliée à 15 travers un contrôleur de station de base BSC à un commutateur du service mobile MSC relié à au moins un commutateur du réseau téléphonique commuté RTC. Un enregistreur de localisation des visiteurs VLR est relié au commutateur MSC et enregistre des 20 caractéristiques des usagers et des terminaux localisés dans la zone de localisation, telles que les identités et profils d'abonnement des terminaux mobiles. Le réseau de radiotéléphonie RR comprend également un enregistreur de localisation nominale 25 HLR relié aux commutateurs du service mobile à travers le réseau de signalisation du réseau de radiotéléphonie RR. L'enregistreur HLR contient une base de données ayant enregistrée les identités et profils des terminaux mobiles, telles que l'identité 30 internationale IMSI (International Mobile Subscriber Identity) et le numéro téléphonique international MSISDN (Mobile Station Integrated Services Digital Number) de l'usager US, et l'adresse de l'enregistreur VLR auquel est rattaché le terminal mobile TM, mise à jour lors de transferts du terminal

mobile entre deux zones de localisation.

Pour les besoins de 1 'invention, le réseau de radiotéléphonie RR relie le terminal mobile TM au 5 serveur d'information SW à travers un serveur d'accès SA interconnectant le réseau téléphonique commuté RTC ou un réseau numérique à intégration de services RNIS ou un réseau de paquets à débit élevé RP du type internet desservant le serveur SW. Le serveur d'accès 10 SA peut contenir une passerelle qui est un serveur de conversion entre le protocole de transport WTP (Wireless Transfer Protocol) et de session WSP (wireless Session Protocol) compatible avec des applications WAP dans le terminal mobile TM d'une 15 part et le protocole de transport HTTP (HyperText Transfer Protocol) applicable dans le serveur SW d'autre part, afin d'échanger des données conservées au format WML (Wireless Markup Language) ou XHTML (extensible Hypertext Markup Language) et échangées 20 entre le terminal TM et les serveurs SW. Le protocole WTP permet d'échanger des requêtes et des réponses entre le terminal mobile TM, en tant que client, et le serveur d'accès SA pour des applications implémentées en langage WML ou XHTML. Le serveur 25 d'accès SA, en tant que client, transmet des requêtes au serveur d'information SW et reçoit des réponses de celui-ci selon des paquets formatés pour le réseau internet RP selon les protocoles de transport et de réseau TCP/IP (Transmission Control Protocol/Internet 30 Protocol). En pratique, le serveur d'accès SA échange des messages numériques via un serveur d'accès NAS (Network Access Server), non représenté, situé entre

les réseaux RTC et RP.

Le serveur d'information SW est un serveur de 35 site web qui peut servir de portail aux terminaux mobiles dans le réseau cellulaire RR afin d'accéder à diverses applications implémentées dans le serveur SW et dans d'autres serveurs à travers le réseau

internet RP.

Comme déjà dit, le couple terminal mobile TM/serveur SW fonctionne d'une manière connue selon le modèle client/serveur. A titre d'exemple, il est supposé que le serveur d'information SW héberge un 10 site de covoiturage. Une base de données BI, par exemple une mémoire non volatile de type disque dur du serveur SW, enregistre des informations disponibles concernant des annonces de conducteurs qui offrent leurs automobiles pour effectuer chacun 15 un trajet respectif entre une ville de départ et une

ville d'arrivée à une date ou une période déterminée.

A chaque offre de covoiturage OCV dans la base BI sont associées le nom et les coordonnées notamment téléphonique et de courrier électronique du 20 conducteur. L'usager US du terminal mobile TM peut être un passager potentiel qui cherche une offre de covoiturage lui convenant. Le service de covoiturage s'adresse particulièrement à une clientèle jeune et citadine ne possédant pas de moyen de locomotion et 25 se déplaçant souvent. Ce service est particulièrement d'intérêt pour les déplacements de proximité dans les grandes agglomérations les jours de grève de transport en commun et pour certains trajets de weekend ou lors des périodes annuelles de congés. 30 Pour des sessions SO et Si décrites cidessous, des communications sont établies entre des terminaux mobiles du réseau RR et le serveur d'information SW d'une manière connue en mode PULL, c'est-à-dire par 35 transmission au moins d'une première requête d'un terminal mobile au serveur et d'une réponse à cette première requête depuis le serveur au terminal

mobile, à travers le serveur d'accès SA.

La session initiale SO consiste à sélectionner 5 l'application de covoiturage du type WAP dans le terminal mobile d'un conducteur par exemple dans le réseau de radiotéléphonie RR, le conducteur requérant d'abord une réponse contenant un formulaire d'inscription par le serveur d'information SW. Le 10 conducteur remplit le formulaire d'inscription dans lequel sont précisées une offre de covoiturage OCV comportant des villes de départ et d'arrivée d'un trajet et une ou plusieurs dates ou périodes de disponibilité ainsi que les coordonnées du 15 conducteur. Le formulaire d'inscription rempli est transmis sous forme de plusieurs premières requêtes RQ1 selon le protocole WTP au serveur d'accès SA qui transcode chaque première requête en au moins une requête selon le protocole HTTP transmise au serveur 20 SW à travers le réseau internet RP. A la réception de la requête RQ1, le serveur SW enregistre l'offre OCV du conducteur ainsi que ses coordonnées dans la base de données BI. En variante, l'inscription du conducteur peut être réalisée classiquement depuis un 25 terminal fixe relié au réseau internet RP directement par l'intermédiaire de requêtes selon le protocole HTTP. Lorsque l'usager US du terminal mobile TM, en 30 tant que client du service de covoiturage, souhaite trouver un conducteur pour un trajet déterminé, l'usager US lance une connexion WAP au serveur d'information SW depuis son terminal mobile TM au début d'une première session Si. L'usager US requiert 35 un formulaire d'inscription et remplit celui-ci, comme à la session S0 pour le conducteur, pour indiquer la ville de départ et la ville d'arrivée du trajet déterminé et au moins une date ou une période déterminée, ainsi que le nom et les coordonnées de l'usager. En réponse aux requêtes de formulaire RQ1 transmises par le terminal TM de l'usager US au serveur SW à travers le serveur d'accès SA, un moteur de recherche MR dans le serveur SW lance une 10 recherche dans la base de données BI par comparaison des données de trajet déterminé communiquées par l'usager US à celles des offres de covoiturage enregistrées OCV. Si au moins une offre OCV est compatible avec le trajet souhaité par l'usager US, 15 le serveur SW établit une réponse RES1 encapsulée

dans un paquet TCP/IP transmis dans le réseau internet RP, transcodée en au moins une réponse WTP dans le serveur d'accès SA et reçue par le terminal mobile TM. La session Sl entre le terminal TM en mode 20 connecté et le serveur SW est ainsi terminée.

Selon l'invention, lorsque le terminal mobile TM ouvre une première session S avec le serveur SW pour rechercher une offre de covoiturage OCV, le serveur SW transmet une réponse RES1 contenant au moins le 25 nom NV d'une ville sensiblement dans le voisinage du terminal mobile TM. La ville est déterminée en fonction d'une localisation géographique du terminal mobile TM grâce à deux modules logiciels IDC et SV et une base de données BV faisant correspondre 30 respectivement des identificateurs de cellule radio IC à des listes de noms de ville NV, comme montré à la figure 1. Dans la base BV, l'identificateur IC d'une cellule CEL couverte radioélectriquement par une station de base BTS dans le réseau de 35 radiotéléphonie cellulaire RR est associé à une liste respective de noms NV de villes. Les villes dans la liste sont sensiblement situées dans le voisinage de la cellule, c'est-à-dire sont contenues dans la zone de couverture de la cellule et le cas échéant, sont 5 situées à proximité de la cellule lorsque la cellule ne contient aucune ville et est incluse dans une zone

de localisation notamment rurale.

En réponse à au moins une première requête RQ1 du terminal TM de l'usager US pour rechercher une 10 offre de covoiturage OCV satisfaisante, le serveur SW ne procède à une localisation géographique du terminal TM que si le serveur SW a reçu une autorisation de localisation du terminal TM par exemple inscrite dans le formulaire d'inscription de 15 l'usager US. Le module d'identification de cellule IDC dans le serveur SW consulte à travers le réseau internet RP un serveur de localisation de terminal mobile LOC en lui transmettant l'identificateur de l'usager US sous la forme du numéro téléphonique 20 MSISDN que le serveur SW a extrait dans la première

requête de formulaire RQ1.

Le serveur de localisation LOC est constamment en communication avec l'enregistreur de localisation nominale HLR à travers une ligne spécialisée du 25 réseau téléphonique commuté RTC ou de tout autre réseau, tel que le réseau de signalisation dans le réseau de radiotéléphonie RR, ou bien est intégré à l'enregistreur HLR. L'identificateur de cellule IC (Cell Identity) est, pour chaque terminal mobile 30 connecté TM, mis à jour par l'enregistreur HLR au fur et à mesure des transferts (handovers) du terminal mobile d'une cellule à une autre cellule. Le terminal mobile TM est ainsi localisé géographiquement à la cellule radio près dans le réseau de radiotéléphonie 35 RR. En correspondance avec l'identificateur d'usager MSISDN, le serveur LOC retourne l'identificateur de cellule IC au serveur SW dans lequel le module de sélecteur de ville SV recherche les noms de ville de départ NV associés à l'identificateur IC de la 5 cellule radio CEL contenant le terminal TM, dans la base de données BV. La liste des noms de ville de départ NV correspondant à l'identificateur IC, ou de préférence les noms d'une ou de deux villes de départ les plus proches de la cellule, et au moins une offre 10 de covoiturage satisfaisante OCV lue dans la base BI et concernant l'une des villes de départ précitées sont transmises en réponse au terminal TM à travers les réseaux RP et RR. Si l'usager US souhaite une autre ville de départ, il saisit le nom de cette 15 ville de départ dans son terminal TM qui la communique dans une première requête au serveur SW qui lance ensuite une recherche d'offre de covoiturage concernant le nom de ville saisi dans la

base BI.

En variante, au lieu que le module d'identification de cellule IDC dans le serveur SW interroge le serveur de localisation LOC, le module IDC interroge directement le terminal d'usager TM. En effet, comme il est connu, toute station de base BTS 25 dans le réseau cellulaire RR transmet un canal balise (beacon channel) qui sert principalement à des mesures de puissance pour gérer l'itinérance et le transfert de cellules. En particulier, le canal balise contient un sous-canal BCCH (Broadcast Control 30 CHannel) qui diffuse des données relatives à la cellule CEL depuis la station de base correspondante BTS. Outre des informations concernant des niveaux minimum-maximum de puissance et des numéros de zones de localisation ainsi que de fréquences de cellules 35 voisines, le canal BCCH diffuse l'identité CI (Cell Identity) de la station de base BTS couvrant la cellule CEL o le terminal mobile se trouve. Ainsi, le terminal mobile TM mémorise en permanence l'identité CI de la cellule CEL o il est situé. 5 L'identité CI en tant qu'identificateur de cellule est retournée au serveur d'information SW en réponse à l'interrogation précédente du module IDC pour que le sélecteur SV sélectionne dans la base BV au moins le nom d'une ville sensiblement située dans le 10 voisinage de la cellule identifiée par

l'identificateur reçu IC.

Si aucune offre de covoiturage OCV satisfaisant la requête RQ1 transmise par le terminal mobile TM de 15 l'usager US n'est disponible dans la base de données BI, le serveur SW maintient temporairement la requête RQ1 avec l'identificateur MSISDN de l'usager US dans une mémoire de requête ME en attente de réponse différée. La première session S est ainsi terminée. 20 Par exemple, un jour de grève de transport en

commun, dans une grande agglomération, l'usager US souhaite comme tous les matins aller à son bureau.

L'usager connecte son terminal radiotéléphonique mobile TM au serveur de service de covoiturage SW et 25 lance au cours de la première session Sl à l'aide au moins d'une requête RQ1 une recherche de conducteur susceptible de passer près de chez lui et pouvant le rapprocher de son bureau. S'il existe une offre de covoiturage OCV disponible à cet instant dans la base 30 BI, l'adresse URL (Uniform Resource Locator) de l'offre disponible accompagnée d'un texte descriptif de l'offre est transmise par le serveur SW au terminal TM via le serveur d'accès SA. Sinon, la requête RQ1 est écrite dans la mémoire ME pour une 35 certaine durée et lorsqu'un conducteur présentera une offre satisfaisante OCV, l'usager US sera prévenu au cours d'une deuxième session S2 à l'initiative du

serveur SW, comme décrit ci-après.

L'invention propose deux réalisations pour que 5 le serveur réponde à l'usager US du terminal TM dès qu'une offre de covoiturage satisfaisante OCV est disponible dans la base BI au cours de la deuxième session S2 à la suite d'une inscription d'un

conducteur ultérieurement à la première session Si.

Pour ces deux réalisations montrées respectivement aux figures 2 et 3, le système de télécommunications selon l'invention comprend un serveur initiateur PI pour une transmission en mode PUSH. Des informations sont transmises depuis le 15 serveur d'information SW au terminal mobile TM sans action préalable de l'usager et donc en ouvrant une deuxième session S2 à la requête du serveur SW. Dans le mode PUSH, le serveur SW transmet une information au terminal TM sans nécessiter une requête préalable 20 transmise par le terminal TM qui peut être en mode connecté ou en mode non connecté. Le serveur initiateur PI contient principalement un outil de programmation API (Application Programming Interface) qui créé des requêtes RQ2 en mode PUSH selon le 25 protocol PAP (Push Access Protocol) en réponse à un message de commande de requête MCR transmis selon le protocole TCP/IP dans le réseau internet RP par le serveur SW. Par exemple, le serveur initiateur PI transmet des messages selon l'un des langages 30 spécifiques SI (Service Indication) et SL (Service Loading) pouvant contenir une adresse URL pour que l'usager consulte un document ayant cette adresse URL dans la base de données BI du serveur SW, ce document contenant par exemple au moins partiellement l'offre 35 de covoiturage d'un conducteur. La requête RQ2 en mode PUSH peut être du type SL (Service Loading) pour une connexion automatique du terminal TM à l'adresse URL contenue dans le message, ou du type SI (Service Indication) pour que l'usager du terminal TM valide 5 la connexion au site WAP désigné par l'adresse URL contenue dans le message en langage SI ou SL

originaire du serveur SW.

Le serveur initiateur PI assure une

compatibilité des requêtes et réponses échangées avec 10 tous les terminaux mobiles actuellement en service.

Le serveur initiateur PI est associé à une base de données BTP contenant notamment des identificateurs MSISDN d'usagers/clients et des caractéristiques des terminaux mobiles TM de ces usagers/clients pouvant 15 traiter des requêtes RQ2 en mode PUSH.

Selon la première réalisation montrée à la figure 2, le système de télécommunications comprend un serveur de services de message court SC (short 20 message Service Center) qui est externe au réseau de radiotéléphonie RR et qui est relié à au moins un commutateur MSC et à l'enregistreur HLR bien souvent à travers un réseau d'accès RA tel qu'un réseau de transmission de paquets de type X.25. En variante, le 25 serveur SC est intégré à un commutateur MSC dans le réseau de radiotéléphonie RR. Le serveur SC est relié au serveur initiateur PI à travers un réseau de télécommunications intermédiaire RI qui peut être un réseau de transmission de paquets X.25, ou un réseau 30 numérique à intégration de services RNIS, ou bien

encore le réseau téléphonique commuté RTC.

Le serveur d'information SW contient un moteur de recherche MR pour rechercher périodiquement dans la base de données BI une offre de covoiturage OCV 35 satisfaisant la requête RQ1 auparavant transmise par le terminal TM et enregistrée dans la mémoire ME au cours de la première session Si. Si une offre satisfaisante OCV est trouvée dans la base de données BI par le moteur de recherche, un module générateur 5 de message de commande de requête GM inclus dans le serveur SW établit un message de commande de requête MCR au début d'une deuxième session S2. Le message MCR contient par exemple une adresse URL désignant l'offre de covoiturage satisfaisante OCV trouvée dans 10 la base BI ainsi que l'identificateur MSISDN de

l'usager US à l'origine de la demande d'information.

Le message MCR est transmis sous la forme d'au moins un paquet TCP/IP au serveur initiateur PI à travers

le réseau internet RP.

Le serveur PI extrait les données du message de commande de requête reçu MCR dans le paquet reçu et crée une deuxième requête RQ2 en mode PUSH adaptée aux caractéristiques du terminal mobile TM si la base de données BTP contient un identificateur d'usager 20 MSISDN identique à celui extrait du message MCR. Le serveur PI encapsule la requête RQ2 en mode PUSH dans un message court SM (Short Message) qui lui-même est encapsulé par exemple dans un paquet X.25 lorsque le

réseau intermédiaire RI est de ce type.

Après consultation de l'enregistreur de localisation nominale HLR pour y lire l'adresse du couple MSC/VLR de la zone de localisation o le terminal mobile TM est situé, le serveur SC envoie le message court SM contenant la requête RQ2 en mode 30 PUSH au terminal mobile TM à travers le réseau de radiotéléphonie RR. L'usager US du terminal TM prend alors connaissance de l'adresse URL incluse dans la requête RQ2 si la requête RQ2 est du type SI et dans la mesure o le terminal TM est en mode connecté, 35 c'est-à-dire n'est pas éteint ou n'est pas hors de la couverture radioélectrique du réseau RR. Sinon, comme il est connu, le serveur de message court SC ne reçoit pas d'acquittement du terminal TM et le signale aux enregistreurs VLR et HLR afin que 5 l'enregistreur HLR signale la mise en état de veille ou en mode connexion du terminal TM pour que le serveur SC tente de luitransmettre le message court SM. L'usager US sélectionne l'hyperlien dans la 10 boîte de message qui est interfacée avec le navigateur WAP dans le terminal TM, correspondant à l'adresse URL afin que le serveur SW transmette quelques mini-pages WAP contenant l'offre de covoiturage recherchée OCV. 15 Selon la deuxième réalisation montrée à la

figure 3, le système de télécommunications selon l'invention comprend, outre le serveur initiateur PI, une passerelle proxy PPG (Push Proxy Gateway) en mode 20 PUSH.

Au lieu d'utiliser le mode PUSH à travers le protocole de message court selon la première réalisation, la passerelle PPG met en oeuvre le mode PUSH selon la configuration OTA (Over-The-Air) à 25 travers le réseau téléphonique commuté RTC et le réseau de radiotéléphonie RR, c'est-à-dire en mode circuit. La passerelle PPG interconnecte ainsi le serveur initiateur PI au réseau RTC. La deuxième requête RQ2 fournie par le serveur PI est transmise à 30 la passerelle PPG selon le protocole PAP/HTTP éventuellement à travers le réseau RTC et/ou un réseau intermédiaire RI. Après avoir identifié le serveur PI, la passerelle PPG transcode la requête RQ2 en un message SI ou SL qu'elle transmet au 35 terminal mobile TM à travers les réseaux RTC et RR

selon le protocole de transport WTP déjà utilisé entre le terminal mobile TM et le serveur d'accès SA.

La passerelle PPG peut avoir accès directement à la base BTP de terminaux d'usager en mode PUSH ou peut 5 posséder sa propre base de données contenant les identificateurs et les caractéristiques des terminaux

mobiles TM.

En variante, la passerelle proxy PPG est

supportée par une plate-forme commune au serveur 10 initiateur PI et/ou au serveur d'accès SA.

En réponse à un message de commande de requête MCR contenu dans un paquet TCP/IP transmis par le serveur SW à travers le réseau internet RP au début d'une deuxième session S2, le serveur PI extrait le 15 message de commande de requête MCR, comme dans la première réalisation, puis le transmet selon le protocole PAP/HTTP à la passerelle PPG qui transforme le message MCR en au moins une deuxième requête RQ2 au format WAP afin que le terminal mobile TM reçoive 20 la deuxième requête selon le protocole WTP. L'usager devant le terminal TM décide ensuite de consulter l'adresse URL contenue dans la requête RQ2, si celleci est du type SI, et correspondant à l'offre de

covoiturage satisfaisante OCV.

En variante, la passerelle proxy PPG est reliée au réseau de radiotéléphonie RR à travers un réseau à commutation par paquets avec gestion de la mobilité et accès par voie radio GPRS (General Packet Radio Service) à la place du réseau téléphonique commuté 30 RTC. Le réseau GPRS présente avantageusement des débits de paquets dans lequel des deuxièmes requêtes RQ2 en mode PUSH sont encapsulées, supérieures au débit dans le réseau RTC, ou bien dans les canaux de signalisation du réseau de radiotéléphonie RR 35 transportant les messages courts SM. Dans cette variante, la plate-forme supportant la passerelle PPG et de préférence également le serveur initiateur PI peut également supporter un noeud passerelle GGSN (Gateway GPRS Support Node). Les paquets contenant 5 des requêtes RQ2 et provenant du réseau internet RP à travers le serveur initiateur PI sont acheminées par le noeud passerelle GGSN vers un noeud de service SGSN (Serving GPRS Support Node) qui est relié à au moins un contrôleur de station de base BSC dans le réseau 10 de radiotéléphonie RR. Le noeud de service SGSN, non

représenté, est relié à l'enregistreur de localisation nominale HLR afin d'orienter les paquets reçus vers la cellule CEL contenant le terminal mobile TM en fonction de l'identificateur de terminal 15 MSISDN contenu dans les requêtes RQ2.

Selon une autre variante combinant les figures 2 et 3, comme montrée à la figure 1, le serveur initiateur PI est capable de communiquer avec le 20 serveur de message court SC et avec la passerelle proxy PUSH PPG en dépendance d'applications implémentées dans le terminal mobile TM de l'usager US. Lorsque le serveur PI reçoit un message de commande de requête MCR via le réseau internet RP, il 25 consulte la base BTP en fonction de l'identificateur MSISDN du terminal mobile TM auquel est destiné le message MCR. Le serveur PI dirige la requête RQ2: soit vers le serveur de message court SC si le terminal mobile ne contient pas une application pour 30 recevoir directement des deuxièmes requêtes WTP via le réseau commuté RTC ou le réseau de paquet GPRS, c'est-à-dire si l'identificateur MSISDN du terminal mobile contenu dans le message MCR est reconnu en association avec une adresse du serveur de message 35 court SC dans la base de données BTP; soit vers la passerelle PPG dans le cas contraire, c'est-à-dire si l'identificateur MSISDN du terminal mobile contenu dans le message MCR est reconnu en association avec une adresse de la passerelle proxy PPG dans la base de données BTP. L'invention n'est pas limitée au covoiturage, mais est applicable pour toute recherche d'information dans un serveur pour laquelle la 10 réponse RQ2 à une première requête RQ1 doit être

différée parce que l'information demandée est prévisible et n'est pas immédiatement disponible.

Selon un autre exemple, la base BI contient des documents sur un thème prédéterminé qui sont 15 régulièrement mis à jour en fonction de données prévisibles par des usagers, telles que le résultat

d'une compétition ou d'une élection.

Claims (9)

REVENDICATIONS

1 - Système de télécommunications entre un terminal radiotéléphonique mobile (TM) dans un réseau 5 de radiotéléphonie cellulaire (RR) et un serveur d'information (SW) connecté à un réseau de paquets (RP) qui est relié au réseau de radiotéléphonie à travers un serveur d'accès (SA), caractérisé en ce que le serveur d'information (SW) comprend un moyen 10 (ME) pour mémoriser temporairement une première requête (RQ1) contenant un identificateur (MSISDN) du terminal mobile (TM) et transmise au cours d'une première session (Sl) depuis le terminal mobile (TM) à travers le serveur d'accès (SA) lorsqu'une 15 information demandée (OCV) dans la première requête n'est pas disponible dans une base de données (BI) liée au serveur d'information (SW), un moyen (MR) pour rechercher périodiquement l'information demandée dans la base de données, et un moyen (GM) pour 20 générer un message de commande de requête (MCR) au début d'une deuxième session (S2) entre le serveur d'information (SW) et le terminal mobile (TM) dès que l'information demandée (OCV) est trouvée dans la base de données (BI) par le moyen pour rechercher, et le 25 système comprend un moyen requérant (PI, SC, PPG)

pour transmettre une deuxième requête (RQ2) au terminal mobile (TM) au cours de la deuxième session en réponse au message de commande de requête (MCR) transmis par le serveur d'information (SW) à travers 30 le réseau de paquets (RP).

2 - Système conforme à la revendication 1, dans lequel le moyen requérant comprend un serveur initiateur de requête (PI) relié au réseau de paquets 35 (RP) pour créer une deuxième requête (RQ2) encapsulée au moins dans un message court (SM) en réponse au message de commande de requête (MCR) transmis par le serveur d'information (SW) et après qu'un identificateur (MSISDN) du terminal mobile contenu 5 dans le message de commande de requête (MCR) soit

reconnu dans une base de données (BTP) liée au serveur initiateur, et un moyen (SC) pour transmettre le message court (SM) relatif à la deuxième requête (RQ2) vers le terminal mobile (TM) à travers le 10 réseau de radiotéléphonie (RR).

3 - Système conforme à la revendication 1, dans lequel le moyen requérant comprend un serveur initiateur de requête (PI) relié au réseau de paquets 15 (RP) pour créer au moins une deuxième requête (RQ2) selon un protocole d'accès en mode PUSH en réponse au message de commande de requête (MCR) transmis par le serveur d'information (SW) et après qu'un identificateur (MSISDN) du terminal mobile contenu 20 dans le message de commande de requête (MCR) soit reconnu dans une base de données (BTP) liée au serveur initiateur, et une passerelle proxy (PPG) pour transmettre la deuxième requête (RQ2) au terminal mobile (TM) à travers le réseau de 25 radiotéléphonie (RR) selon un protocole de transport analogue à celui entre le terminal mobile (TM) et le

serveur d'accès (SA).

4 - Système conforme à la revendication 1, dans 30 lequel le moyen requérant comprend un serveur initiateur de requête (PI) relié au réseau de paquets (RP) pour créer une deuxième requête (RQ2) encapsulée dans au moins un message court (SM) lorsqu'un identificateur (MSISDN) du terminal mobile contenu 35 dans le message de commande de requête (MCR) est reconnu en association avec une adresse de serveur de message court (SC) dans une base de données (BTP) liée au serveur initiateur et pour créer une autre deuxième requête (RQ2) lorsque l'identificateur 5 (MSISDN) du terminal mobile est reconnu en association avec une adresse de passerelle proxy (PPG) dans la base de données (BTP) liée au serveur initiateur, en réponse au message de commande de requête (MCR) transmis par le serveur d'information 10 (SW), un moyen (SC) pour transmettre le message court (SM) relatif à la deuxième requête (RQ2) vers le terminal mobile (TM) à travers le réseau de radiotéléphonie (RR), et une passerelle proxy (PPG) pour transmettre l'autre deuxième requête (RQ2) au 15 terminal mobile (TM) à travers le réseau de radiotéléphonie (RR) selon un protocole de transport analogue à celui entre le terminal mobile (TM) et le

serveur d'accès (SA).

5 - Système conforme à la revendication 3 ou 4, dans lequel le serveur d'accès (SA) et la passerelle proxy (PPG) sont supportés par une plateforme commune.

6 - Système conforme à l'une quelconque des

revendications 3 à 5, dans lequel le serveur initiateur (PI) et la passerelle proxy (PPG) sont

supportés par une plate-forme commune.

7 - Système conforme à l'une quelconque des

revendications 3 à 6, dans lequel la passerelle proxy (PPG) est reliée au réseau de radiotéléphonie (RR) à travers un réseau à commutation par paquets avec gestion de la mobilité et accès par voie radio 35 (GPRS).

8 - Système conforme à l'une quelconque des

revendications 1 à 7, dans lequel le serveur d'information (SW) comprend un moyen (IDC) pour 5 identifier une cellule (CEL) du réseau de

radiotéléphonie (RR) o le terminal mobile (TM) est situé dès que le serveur d'information reçoit la première requête (RQ1), et un moyen (SV, BV) pour sélectionner au moins le nom d'une ville (NV) 10 sensiblement située dans le voisinage de la cellule identifiée (CEL) afin de transmettre au terminal mobile le nom de la ville dans une réponse (RES1) à la première requête (RQ1) à travers le serveur

d'accès (SA).

9 - Système conforme à la revendication 8, comprenant un serveur de localisation de terminal mobile (LOC) connecté au réseau de paquets (RP) et à un enregistreur de localisation nominale (HLR) dans 20 le réseau de radiotéléphonie (RR) afin que le moyen pour identifier (IDC) lise dans le serveur de localisation un identificateur (IC) de la cellule (CEL) o le terminal mobile est situé en correspondance avec l'identificateur (MSISDN) du 25 terminal mobile (TM) contenu dans la première requête

(RQ1).

- Système conforme à la revendication 8, dans lequel le terminal mobile (TM) transmet au serveur 30 d'information (sW) une première requête (RQ1)

contenant un identificateur (IC) de la cellule (CEL) o le terminal mobile est situé en réponse à une invitation de localisation géographique transmise par le moyen pour identifier (IDC) dans le serveur 35 d'information.