FR2920937A1

FR2920937A1 - Procede de diffusion d'informations d'une plateforme integrant un serveur et une base de donnees vers un terminal mobile

Info

Publication number: FR2920937A1
Application number: FR0757522A
Authority: FR
Inventors: Christophe Edet
Original assignee: Individual
Current assignee: Individual
Priority date: 2007-09-12
Filing date: 2007-09-12
Publication date: 2009-03-13

Abstract

La présente invention concerne un procédé de diffusion d'informations d'une plateforme (12) intégrant un serveur et une base de données (13, 14) vers un terminal mobile (10) utilisant le protocole WAP. Une application particulièrement intéressante de l'invention se situe dans le domaine de la diffusion d'informations intégrant des photos ou des vidéos vers des terminaux mobiles. Les informations peuvent notamment, mais non exclusivement, concerner des biens immobiliers.

Description

La présente invention concerne un procédé de diffusion d'informations d'une plateforme intégrant un serveur et une base de don-nées vers un terminal mobile utilisant le protocole WAP. Une application particulièrement intéressante de l'invention se situe dans le domaine de la diffu- sion d'informations intégrant des photos ou des vidéos vers des terminaux mobiles tels que des téléphones mobiles suite à une requête de l'utilisateur dudit terminal. Les informations peuvent notamment, mais non exclusive-ment, concerner des biens immobiliers. Le protocole WAP ( Wireless Application Protocol en anglais), dit aussi Internet mobile, est un protocole de communication dont le but est de permettre d'accéder à Internet à l'aide d'un terminal mobile tel que par exemple un téléphone portable ou un assistant personnel du type PDA ( Personal Digital Assistant en anglais). Les opérateurs de téléphonie mobile proposent un accès à des sites ou des portails Web accessibles via ces terminaux compatibles avec le protocole WAP. Toutefois, la diffusion de sites internet sur les téléphones portables pose certaines difficultés. Ainsi, les sites Internet sont construits au format HTML qui est le for-mat le plus couramment utilisé ; le format HTML a été adapté à la téléphonie mobile : le format le plus répandu est à ce titre le format WML conçu pour le protocole WAP. Dès lors que le format d'origine du site à diffuser est un site au format HTML, on observe un affichage dégradé du site sur certains terminaux mobiles intégrant un navigateur conçus pour fonctionner uniquement en WML. En outre, il existe un très grand nombre de modèles de terminaux mobiles présentant des dimensions d'écran variables ainsi que des capacités de défilement ( scrolling en anglais) également variables. Dès lors, on conçoit aisément que des sites prévus pour fonctionner sur un écran d'ordinateur, ne s'affiche de façon optimale sur un écran de téléphone mobile.

Par ailleurs, il est de plus en plus fréquent de diffuser à partir de sites des informations du type photos ou vidéos ; certains terminaux mobiles ne sont pas équipés d'applications permettant la lecture de ces photos et/ou vidéo. En outre, ces photos et/ou vidéos peuvent être enregistrées dans un format qui n'est pas lisible par le terminal mobile. A l'heure actuelle, pour lire une séquence vidéo avec un téléphone mobile, le format le plus communément répandu est le format 3GP. Les fichiers avec l'extension .3GP ( 3rd Generation Partnership Project en anglais) sont des vidéos compressées prévues pour être diffusées à travers les réseaux mobiles de troisième génération. Ils ont généralement pour extension .3gp ou .3g2. On peut également trouver des terminaux mobiles lisant des fichiers au format MPEG4. Dès lors, un fichier .AVI ou MPEG4 (formats classiques utilisés lors de la capture de séquences vidéo par une caméra numérique) ne pourra pas être lu sur un terminal ne lisant que des fichiers au format 3GP. Dans ce contexte, la présente invention vise à fournir un procédé de diffusion d'informations d'une plateforme intégrant un serveur et une base de données vers un terminal mobile utilisant le protocole WAP permettant de s'affranchir des problèmes précités. A cette fin, l'invention propose un procédé de diffusion d'informations d'une plateforme intégrant un serveur et une base de données vers un ter- minai mobile utilisant le protocole WAP, ladite base de données stockant des caractéristiques de traitement et d'affichage associées à une pluralité de terminaux mobiles et ledit procédé comportant les étapes suivantes : -ledit terminal mobile demande un accès au dit serveur, ladite de- mande d'accès étant faite soit directement au dit serveur soit en pas- sant par un opérateur de télécommunication mobile, - ledit serveur détecte le modèle dudit terminal, - ledit serveur interroge ladite base de données en comparant ledit modèle détecté avec les modèles de ladite base afin de récupérer les caractéristiques de traitement et d'affichage associées au dit terminal, - si ledit modèle détecté n'est pas présent dans ladite base, le serveur envoie un message au dit terminal lui indiquant l'incompatibilité dudit terminal avec ladite plateforme, - si ledit terminal est présent dans ladite base, ledit serveur propose une page d'accueil construite par ledit serveur en utilisant un langage dynamique à partir desdites caractéristiques de traitement et d'affichage, ladite page d'accueil comportant au moins un champ de saisie d'une demande d'informations par l'utilisateur dudit terminal, - ledit serveur interroge ladite base de données pour vérifier l'existence d'au moins une réponse à ladite demande d'informations, - si au moins une réponse à ladite demande d'informations existe, ledit serveur délivre ladite réponse au dit terminal, le contenu de ladite ré- ponse étant déterminé en utilisant un langage dynamique en fonction desdites caractéristiques de traitement et d'affichage dudit terminal. On entend par terminal mobile tout type de terminaux mobiles tels que par exemple un téléphone portable ou un assistant personnel du type PDA. Par ailleurs on entend par base de données, un système de gestion de base de données (SGBD) permettant à la fois la gestion et l'accès à la base de données, étant entendu que le système de gestion de base de données peut héberger plusieurs bases de données, qui sont destinées à des logiciels ou des thématiques différentes. Le terme de base de données couvre également une pluralité de SGBD.

Grâce à l'invention, on effectue une quadruple vérification suite à la demande d'accès au serveur de l'utilisateur du terminal mobile : Dans un premier temps, la plateforme intégrant le serveur commence par détecter le modèle de terminal utilisé. Dans un second temps, le serveur s'assure que le modèle de terminal détecté est apte à recevoir sa page d'accueil ; prenons le cas d'un terminal qui ne peut pas recevoir de page construite en WML : la page d'accueil étant en WML, le serveur prévient alors l'utilisateur que l'application doit être inter-rompue. Le serveur peut également décider de diffuser la page d'accueil dans un format accepté par le navigateur du terminal : ce format peut être du WML ou du xHTML par exemple. Dans un troisième temps, le serveur vérifie dans sa base de données, s'il existe au moins une réponse associée à la demande de l'utilisateur.

Dans un quatrième temps, toujours à partir du modèle de terminal détecté et en réponse à la saisie de l'utilisateur, le serveur décide à partir d'un langage dynamique s'il peut ou non diffuser des données spécifiques telles que des données vidéo ou des photos susceptibles d'être intégrées à la ré- ponse faite à l'utilisateur. Le procédé selon l'invention utilise donc avantageusement la détection du modèle de téléphone portable associée à un programme conçu en langage dynamique interrogeant les bases de données de la plateforme pour construire une réponse adaptée au modèle de terminal.

Par ailleurs, on peut noter que le procédé selon l'invention nécessite pour sa mise en oeuvre un investissement relativement faible et qu'il peut être utilisé avec la majorité des téléphones mobiles (la plupart des téléphones utilise aujourd'hui le protocole WAP). Le procédé selon l'invention peut également présenter une ou plu- 15 sieurs des caractéristiques ci-dessous, considérées individuellement ou selon toutes les combinaisons techniquement possibles : Avantageusement, le procédé selon l'invention comporte les étapes suivantes : - si lesdites caractéristiques de traitement et d'affichage dudit terminal autorisent l'affichage de vidéos et/ou photos présentant un format 3GP ou un format MPEG4 et que certaines vidéos et/ou photos présentant ce format sont associées à ladite réponse, ces vidéos et/ou photos sont proposées à l'utilisateur dudit terminal dans ledit contenu de ladite réponse, - si lesdites caractéristiques de traitement et d'affichage dudit terminal n'autorisent pas l'affichage de vidéos et/ou photos présentant un format 3GP ou un format MPEG4 et que certaines vidéos et/ou photos présentant ce format sont associées à ladite réponse, ces vidéos et/ou photos ne sont pas proposées à l'utilisateur dudit terminal dans ledit contenu de ladite réponse. Préférentiellement, le procédé selon l'invention comporte au moins une des étapes suivantes : 20 25 30 - un fournisseur de données exporte ses données, par exemple sous forme de flux RSS, vers ladite base de données de ladite plateforme. - ledit serveur extrait les données destinées à ladite base de données à partir de données stockées dans des bases de données de fournis- seur, par exemple à l'aide de robots, - un fournisseur utilise un localisateur url privé de connexion à ladite plateforme qui lui permet de déposer ses données. La page d'accueil peut être envoyée dans un format WML ou xHTML. Avantageusement, le format de la page d'accueil est déterminé en fonction desdites caractéristiques de traitement et d'affichage. Avantageusement, le procédé selon l'invention comporte les étapes suivantes : - ledit terminal envoie un minimessage, dit aussi SMS Short mes-sage service , à l'opérateur de télécommunication mobile, ledit mi- nimessage comportant un code de service, - ledit opérateur de télécommunication mobile reconnaît ledit code de service et renvoie au dit terminal un minimessage contenant un localisateur url d'accès. Préférentiellement, ladite étape pendant laquelle ledit terminal mobile demande un accès au dit serveur se déroule selon les étapes suivantes : - ledit terminal mobile demande un accès au dit serveur via un accès à un localisateur url, ladite demande transitant par ledit opérateur de télécommunication mobile, - ledit opérateur mobile rajoute au dit localisateur url un identifiant uni- que associé au dit terminal mobile avant envoi au dit serveur, - ledit identifiant est stocké dans ladite base de données de ladite pla- teforme. Selon un mode de réalisation préféré, un compteur de temps correspondant à la réception de l'identifiant est également stocké dans ladite base de données de ladite plateforme. De manière préférentielle, le procédé selon l'invention comporte une étape de vérification de la solvabilité dudit utilisateur dudit terminal après que l'utilisateur dudit terminal ait accepté une proposition commerciale pour la fourniture des informations demandées Le procédé selon l'invention trouve une application particulièrement intéressante dans le domaine des recherches d'informations immobilières.

Ainsi, de manière particulièrement avantageuse, ledit champ de saisie per-met la saisie d'une référence immobilière sur laquelle l'utilisateur dudit terminal souhaite obtenir des informations. D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est donnée ci-dessous, à titre indicatif et nul- lement limitatif, en référence à la figure 1 annexée qui est une représentation schématique simplifiée des différentes étapes du procédé selon l'invention. Le procédé selon l'invention comporte une série d'étapes se déroulant entre un terminal mobile client 10 tel qu'un téléphone mobile ou un PDA fonctionnant suivant le protocole WAP, un opérateur de téléphonie mobile 11 et une plateforme éditeur 12 intégrant : - un serveur non représenté, - un système de gestion de base de données (SGBD) clients 13, - un système de gestion de base de données (SGBD) de références 14. Les SGBD peuvent être interrogés en utilisant un langage du type SQL ( Structured query language en anglais). Le terminal 10 peut se connecter à un réseau mobile 15 de l'opérateur 11, ledit réseau mobile 15 étant connecté par au moins une pas- serelle à un réseau de transmission de données 16 tel que le réseau Inter-net selon un protocole du type HTTP ( Hypertext Transfer Protocol en anglais) ou HTTPS ( Hypertext Transfer Protocol Secured en anglais), donnant accès à la plateforme 12. Selon une première étape 1, l'accès au service WAP est réalisé par l'envoi par le terminal mobile 10 d'un minimessage ou SMS ( Short Mes-sage Service' en anglais) à un numéro dédié à un service particulier, par exemple un numéro correspondant à un service relatif à des informations sur des biens immobiliers. Ce numéro dédié peut être un numéro court à cinq chiffres, le SMS contenant un code associé au service mentionné ci-dessus. Selon l'étape 2, l'opérateur en téléphonie mobile 11 reconnaît le code du service et délivre en retour au terminal 10 un SMS contenant un chemin d'accès à une url ( Uniform Resource Locator en anglais), littéralement localisateur uniforme de ressource . Selon l'étape 3, l'utilisateur du terminal 10 active le chemin d'accès et demande la page d'accueil du service. Conformément à l'étape 4, l'opérateur 11 va ajouter dans l'en-tête ( header en anglais) de la requête de l'utilisateur un identifiant (ou alias) UID ( User Identifier en anglais) unique de la carte SIM du terminal mobile 10. La génération de cet identifiant unique peut être obtenu par différents procédés propres à chaque opérateur. Cet identifiant peut par exemple être calculé à partir du numéro de téléphone de l'utilisateur mais reste de préférence anonyme pour des raisons de confidentialité. Le chemin d'accès ainsi que l'identifiant sont envoyés à la plateforme 12 selon le protocole HTTP ou HTTPS. En référence à l'étape 5, le serveur de la plateforme 12 récupère dans les en-têtes à la fois l'identifiant de l'utilisateur ainsi que le paramètre user-agent prévu dans le protocole http. Le paramètre de user-agent permet de déterminer le modèle du terminal mobile 10. On utilise pour cela un langage dynamique tel que Coldfusion pour interroger les en-têtes. ColdFusion est un langage à base de balises syntaxiquement proche du langage HTML et qui permet aux développeurs d'effec- tuer rapidement des opérations telles qu'interagir avec une base de données du type SQL ou afficher dynamiquement des informations sur des pages Web. D'autres langages dynamiques tels que PHP, ASP ou JSP peuvent également être utilisés. Un exemple de code source permettant cette récupération est donné ci-dessous : ri sotte <output> <set x GetHttp{tequesiData( <bop collection = ##x.headers# item = ittp_item"> #http_item# #StructFind(x.headers, http_item)# <flow> < output mile si ous renvoie ttt l r t?1 jf/lltt'?f t ftll Value CF 0=1 33680. CFTOKEN-ESE?3117; urt du se{veurd'appli{-utioo {le type" ?r':! {exu'l{tm:, application/yod xhtnill+xmI f , c{,-o{k xh u applicatirznfynd wap {nt e{ii c appli s = va r hiv.o, apis mUserAlias:373641738227

Nokia6630i1.0 (4.03.40) SymbianOSf8.0 Series6012.6 profitefMIDP-2.0 Configuration7CLDC-1.1 MODE TT .r heep- is l att it, se 'tOS4 t;c s 2;1.1--43 s fr - hop iindsl udssok{ (Sri7? 5 z l'" GPRS ~uti?'.C5if39Y:::1 CET HTTPt1.1 L'interrogation des en-têtes (voir ci-dessus) renvoie l'identifiant de l'utilisateur (ici : 373641738227) ainsi que le modèle du terminal (ici : Nokia 6630).

A partir du modèle du terminal, le serveur recherche dans un SGBD non représentée (intégrant pour chaque modèle de terminal des informations techniques du terminal telles que les caractéristiques d'affichage et de traitement du terminal) la présence du terminal détecté grâce au user-agent et ses caractéristiques associées. Ces caractéristiques incluent no- tamment : la prise en charge ou non des fonctions image, vidéo, streaming, téléchargement, le protocole d'affichage du terminal (WML, xHTML, Java...). Si le modèle de terminal 10 n'est pas dans le SGBD, la plateforme 12 indique à l'utilisateur l'incompatibilité du terminal 10 avec le procédé proposé et l'échange s'arrête. Un exemple de code source illustrant le processus est donné ci-dessous: 8 WAP-Network-info Cr- i- er' r User-Agent X-Nokia-C )NNEt Tï 3 C,crmec<:-in t nt.. -'r et r, cade source 5.1-b. .set Terminal_User-Agent = #http_Use{_Agent#} <output> <query name='GET TM" datasource= notreBDD."> SELECT UserAgent, autres,... FROM notrebdddeterminaux </guérit> sloop quer}=L GET_TM"> <if Terminal Modele CONTMNS'# GET_TM.UserAgent#'> il Si le mr :bi existe ds notre Bï.1C7, on racup ,re tou •, aw ,, tre a{ ;:ng, chargement lar.gt u s u un Appiication.video = Application.inaage = Application.iangage_supporte = Etc... fi on initialisé fapplicadicin Application.initialized = 1 <'eiue> Io ;en- _zai cu eu pas trouvé ds notre BDD, on in Modèle non supporté <abort> -fit> </bop> </output> t c.o& 9.1 La plateforme 12 enregistre l'UID dans le SGBD clients 13 qui regroupe les informations relatives à l'utilisateur. La plateforme 12 stocke également dans le SGBD clients 13 un compteur de temps correspondant à la date de réception de l'UID. Rappelons que l'UID est anonyme par rapport au numéro de téléphone du client mais est unique. Le fait de stocker l'identifiant UID et un compteur associé permettra ensuite d'identifier le client lorsque celui-ci se connectera à nouveau ainsi que de gérer les droits de l'utilisateur en fonction de son abonnement (et notamment la durée de son abonnement par rapport au temps écoulé sur le compteur). En d'autres termes, si l'utilisateur se reconnecte, la plateforme 12 peut immédiatement vérifier si l'utilisateur est encore dans sa période d'abonnement. La plateforme 12 permet également de proposer au client, à chaque nouvelle visite, des contenus adaptés ou de le laisser accéder à des

rubriques spécifiques de l'application. Cette étape permet également de refuser l'accès à un utilisateur identifié comme douteux . L'identification complète de l'utilisateur et du modèle de terminal 10 étant réalisée, la plateforme construit dynamiquement (à nouveau à l'aide d'un langage dynamique tel que Coldfusion) la page d'accueil du service qui

va être proposée sur le terminal mobile 10. Ainsi le format de la page d'accueil peut être par exemple en WML ou en xHTML selon que le terminal accepte ou non ces formats (on a cette information via les caractéristiques du terminal). Un exemple de code source permettant une telle implémentation est donnée ci-dessous : ..ri..f>,iu d ap; ation, i.iaitianterrent <a prise r, _ targ> ou iuin des fonctions tur.cn cor.Datiblt d ta:ariral oeu;icri <if App{ication.langage_supporte = xHTML> <IDOCTYPE html PUBLIC "-l/W'APFORUMI/DTD XHTML Moule 1.Qf1E I http./i w.wapfor lm.org/DTDfxhIml-mabile1G? d <html xmins="http /fwww.w3argf1? 99ixhtnnl"> <head> <title> <ftitle> K"Ihead> <body> Etc

<else Application.langage_supporte = WML> <?xml version =1 .0' encoding='iso-8859-1"?> <IDOCTYPE wml PUBLIC "-IJW'APFORUMUDTD WML 'I.i/IEN" p rg`DTD/wmll 1 dtd">. <wml> <card> <!if> Fin cade source 5.3 La page d'accueil s'affiche donc sur le terminal 10 ; cette page d'accueil comprend au moins un champ de formulaire permettant à l'utilisateur de saisir une référence alphanumérique correspondant par exemple à un bien immobilier (exemple d'une référence sur un panneau d'appartement à vendre dans la rue). La page d'accueil peut également contenir un moteur de recherche plus complet avec différents champs à renseigner : nombre de pièces, superficie, prix...

Selon l'étape 6, l'utilisateur entre ladite référence dans le champ de saisie et valide cette entrée.

Le SGBD de références 14 locale de la plateforme 12 intègre les don-nées de différents fournisseur de données ; en restant dans le domaine des données immobilières, l'alimentation du SGBD 14 de références passe par une contractualisation avec le fournisseur. La fourniture des données peut se faire de différentes manières.

Le fournisseur peut tout d'abord exporter, par exemple sous forme de flux au format RSS (habituellement utilisé pour diffuser les mises à jour de sites dont le contenu change fréquemment, typiquement les sites d'information) ses données vers le SGBD de références 14.

Il est également possible d'utiliser des robots spécifiques pour chaque fournisseur qui permettent d'extraire les données directement à partir des différents serveurs de fournisseur.

Une autre solution peut consister à utiliser une url privée sur la plate-forme 12 (Intranet ou extranet) qui permettent aux fournisseurs de déposer leurs données. Les données sont non seulement des données textuelles relatives aux biens immobiliers mais également des images ou des vidéos du bien immobilier proposé. Pour pouvoir lire de la vidéo avec la plupart des terminaux mobiles, il est préférable de proposer des fichiers du type 3GP : les fichiers avec l'ex-tension .3GP (3rd Generation Partnership Project) sont des vidéos compres- sées prévues pour être diffusées à travers les réseaux mobiles de troisième génération. Ils ont généralement pour extension .3gp ou .3g2. On peut également avoir des terminaux qui lisent des fichiers au format MPEG4 (on notera toutefois que de nombreux terminaux mobiles ne lisent le format MPEG4).

Des séquences capturées avec une caméra numérique formant un fi-chier au format AVI ne seront pas lisibles par la majorité des terminaux mobiles. Dès lors, il est préférable d'enregistrer uniquement des vidéos au format 3GP et éventuellement au format MPEG4 dans le SGBD de référen- ces 14. Une solution peut consister pour le fournisseur de données à capturer les photos ou vidéos du bien immobilier (ou de tout autre type de bien selon l'application) à l'aide d'un terminal mobile de façon à avoir directement un fichier au format ad hoc et à proposer et/ou exporter ces fichiers vers le SGBD de références 14. Ces fichiers peuvent même être transférés directement vers la plateforme 12 à partir du terminal mobile du fournisseur de données. Selon l'étape 7, la plateforme 12 vérifie dans le SGBD de références 14 si au moins une réponse correspond à la référence saisie par l'utilisateur (dans le cas d'une page d'accueil multi-champs, selon les cas, on peut décider qu'il faut au moins une réponse répondant soit à l'ensemble de champs saisis soit à au moins un champ saisi).

Si aucun bien ne correspond à la requête de l'utilisateur, la plateforme 12 envoie un message d'erreur (ou indique qu'il n'y a pas de biens disponibles) à l'utilisateur et le redirige au début de l'application. Si la référence est détectée dans le SGBD 14, la plateforme 12 col- lecte l'ensemble des informations (textuelles, vidéo, image) utiles à la délivrance du contenu et envoie à l'utilisateur une page de dialogue d'achat sur laquelle l'utilisateur a la possibilité d'accepter la transaction proposée (plu-sieurs types de transaction peuvent être proposés, par exemple avec ou sans abonnement sur une durée prédéterminée).

Le système de paiement peut être hébergé indifféremment par l'opérateur 11 ou par la plateforme 12. Dans le cas d'un système de paiement hébergé par l'opérateur 11, selon les étapes 8 et 9, si l'utilisateur accepte la transaction, la validation de la transaction fait appel à une passerelle ( gateway en anglais) de dialo- gue entre l'opérateur 11 et la plateforme 12; c'est l'opérateur 11 qui va débiter l'utilisateur et donc vérifier la solvabilité du client. Si l'opérateur est solvable, il informe la plateforme 12. On peut noter qu'en cas de temps de réponse trop long entre la plateforme 12 et l'opérateur 11, une désactivation ( timeout en anglais) est prévue.

Pour certains opérateurs, c'est la plateforme qui héberge le système de paiement et c'est donc la plateforme qui demande à l'opérateur si l'utilisateur est ou non solvable. Il y a donc toujours la vérification de la solvabilité par l'opérateur mais ce n'est pas le client qui demande à l'opérateur s'il est solvable (c'est la plate-forme qui propose le dialogue d'achat au client et qui demande ensuite à l'opérateur se l'utilisateur est solvable). Si l'utilisateur n'est pas solvable, un message d'erreur est envoyé sur le terminal 10. Dans le cas contraire, l'opérateur 11 renvoie à la plateforme 12 via la passerelle les informations relatives à la transaction.

Selon l'étape 10, la plateforme 12 enregistre les informations relatives à la transaction dans le SGBD clients 13 et délivre les informations concernant la référence saisie par l'utilisateur.

Les informations relatives au bien immobilier sont ainsi proposées à l'utilisateur conformément aux caractéristiques du terminal 10. Un exemple de code source permettant de générer l'affichage des informations sur le terminale 10 est donné ci-dessous : iode source affichage du tien en fonction du type de terrai{{{{1 Application.fangage supporte=WML> <?xml version=1 .0" encoding="iso-8859-i"?> <1DOCTYPE wml PUBLIC '-IPWAPFORUM1/DTDWML 1 1?IEN"'http:flwww_,wapforum.orgîDTD;wrr7111_cttd"> 1 > card> Type de bien : #BDD_type de bien# Nb chambres : #BDD nb chambre# Descriptif détaillé : #BDD_descriptif# Prix : #BBD_prix# ETC ._. le 1 .e les ;ad su. o a les proposes (>a + '[ < t arr,c ment ou en xfi ariain g <if Api ! on.vic o'_ Oui> loop sur les video #BDD video# <Ioop sur les videos> <else> i Sinon, un {b°' reopose rien ... <f> Si r {1e terminai supporte les images fpg,gifl, on <if Application images = Oui> sloop sur les photos> #BDD_photo# eloop sur les photos> Ise> propose den ... <li I On termine en fournissant les contacts du professionnel Agence x Adresse : ` ne é propos du numéro de téléphone : une fonction permet d'appeler d{recteo< t r.3{ s avoir è composer nrrmere. Tél : <appel> +330000000000 </appel> </tard> 11> Ainsi, le procédé selon l'invention permet d'afficher le résultat en prenant en compte les caractéristiques du terminal susceptible d'autoriser par exemple: les formats WML ou xHTML, les vidéos ou pas, - si le terminal lit les vidéos : diffusion en téléchargement ou en streaming, les images ou pas. Il est également possible d'appeler directement le contact en charge du bien immobilier sans composer le numéro de téléphone dudit contact. La page de réponse aura toujours un haut et un bas de page com- mun avec en son centre des informations adaptées au terminal. Bien entendu, l'invention n'est pas limitée au mode de réalisation qui vient d'être décrit.

On notera ainsi que l'invention bien que préférentiellement décrite dans le cas de biens immobiliers, peut s'appliquer à d'autres types de service (service de rencontre ù demande d'informations sur des spectacles) dès lors qu'une demande d'information d'un client à partir d'un terminal mobile est nécessaire. Enfin, on pourra remplacer tout moyen par un moyen équivalent.

Claims

REVENDICATIONS

1. Procédé de diffusion d'informations d'une plateforme intégrant un serveur et une base de données vers un terminal mobile utilisant le proto-cote WAP, ladite base de données stockant des caractéristiques de traite-ment et d'affichage associées à une pluralité de terminaux mobiles et ledit procédé comportant les étapes suivantes : - ledit terminal mobile demande un accès au dit serveur, ladite de-mande d'accès étant faite soit directement au dit serveur soit en pas- sant par un opérateur de télécommunication mobile, - ledit serveur détecte le modèle dudit terminal, - ledit serveur interroge ladite base de données en comparant ledit modèle détecté avec les modèles de ladite base afin de récupérer les caractéristiques de traitement et d'affichage associées au dit terminal, -si ledit modèle détecté n'est pas présent dans ladite base, le serveur envoie un message au dit terminal lui indiquant l'incompatibilité dudit terminal avec ladite plateforme, - si ledit terminal est présent dans ladite base, ledit serveur propose une page d'accueil construite par ledit serveur en utilisant un langage dynamique à partir desdites caractéristiques de traitement et d'affichage, ladite page d'accueil comportant au moins un champ de saisie d'une demande d'informations par l'utilisateur dudit terminal, - ledit serveur interroge ladite base de données pour vérifier l'existence d'au moins une réponse à ladite demande d'informations, - si au moins une réponse à ladite demande d'informations existe, ledit serveur délivre ladite réponse au dit terminal, le contenu de ladite ré- ponse étant déterminé en utilisant un langage dynamique en fonction desdites caractéristiques de traitement et d'affichage dudit terminal.

2. Procédé selon la revendication 1 caractérisé en ce qu'il comporte les étapes suivantes : - si lesdites caractéristiques de traitement et d'affichage dudit terminal autorisent l'affichage de vidéos et/ou photos présentant un format 3GP ou un format MPEG4 et que certaines vi-déos et/ou photos présentant ce format sont associées à ladite réponse, ces vidéos et/ou photos sont proposées à l'utilisateur dudit terminal dans ledit contenu de ladite réponse, - si lesdites caractéristiques de traitement et d'affichage dudit terminal n'autorisent pas l'affichage de vidéos et/ou photos présentant un format 3GP ou un format MPEG4 et que certaines vidéos et/ou photos présentant cette extension ou ayant ce format sont associées à ladite réponse, ces vidéos et/ou photos ne sont pas proposés à l'utilisateur dudit terminal dans ledit contenu de ladite réponse.

3. Procédé selon l'une des revendications précédentes caractérisé en ce qu'il comporte au moins une des étapes suivantes : - un fournisseur de données exporte ses données, par exemple sous forme de flux RSS, vers ladite base de données de ladite plateforme. - ledit serveur extrait les données destinées à ladite base de données à partir de données stockées dans des bases de données de fournisseur, par exemple à l'aide de robots, - un fournisseur utilise un localisateur url privé de connexion à ladite plateforme qui lui permet de déposer ses données.

4. Procédé selon la revendication précédente caractérisé en ce que ledit page d'accueil est envoyée dans un format WML ou xHTML.

5. Procédé selon la revendication précédente caractérisé en ce que le format de la page d'accueil est déterminé en fonction desdites caractéristi- ques de traitement et d'affichage.

6. Procédé selon l'une des revendications précédentes caractérisé en ce qu'il comporte les étapes suivantes : - ledit terminal envoie un minimessage, dit aussi SMS Short mes-sage service , à l'opérateur de télécommunication mobile, ledit minimessage comportant un code de service, - ledit opérateur de télécommunication mobile reconnaît ledit code de service et renvoie au dit terminal un minimessage contenant un localisateur url d'accès.

7. Procédé selon l'une des revendications précédentes caractérisé en ce que ladite étape pendant laquelle ledit terminal mobile demande un accès au dit serveur se déroule selon les étapes suivantes : - ledit terminal mobile demande un accès au dit serveur via un accès à un localisateur url, ladite demande transitant par ledit opérateur de télécommunication mobile, - ledit opérateur mobile rajoute au dit localisateur url un identifiant uni- que associé au dit terminal mobile avant envoi au dit serveur, -ledit identifiant est stocké dans ladite base de données de ladite pla-teforme.

8. Procédé selon la revendication précédente caractérisé en ce qu'un compteur de temps correspondant à la réception de l'identifiant est égale-ment stocké dans ladite base de données de ladite plateforme.

9. Procédé selon l'une des revendications précédentes caractérisé en ce qu'il comporte une étape de vérification de la solvabilité dudit utilisateur dudit terminal après que l'utilisateur dudit terminal ait accepté une proposition commerciale pour la fourniture des informations demandées

10. Procédé selon l'une des revendications précédentes caractérisé en ce que ledit champ de saisie permet la saisie d'une référence immobilière sur laquelle l'utilisateur dudit terminal souhaite obtenir des informations.