FR2918527A1

FR2918527A1 - Procede et dispositif d'insertion d'une adresse dans une requete

Info

Publication number: FR2918527A1
Application number: FR0756218A
Authority: FR
Inventors: Anne Boutroux; Cedric Goutard
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2007-07-02
Filing date: 2007-07-02
Publication date: 2009-01-09

Abstract

Le procédé selon l'invention permet d'insérer une adresse (U(C_M)) dans une requête (R) envoyée par un terminal (10) à un serveur tiers (40), cette adresse permettant d'accéder à un fichier (f(C_M)). Ce procédé comporte, avant l'insertion de l'adresse :- une étape d'interception de la requête (R) ;- une étape d'obtention, à partir de la requête (R), d'un identifiant (C_M) d'une catégorie de terminaux ;- une étape d'obtention, à l'aide de cet identifiant, de l'adresse (U(C_M)) permettant d'accéder audit fichier (f(C_M)), ce fichier comportant des formats de contenus supportés par un terminal de la catégorie identifiée par l'identifiant ;et après l'insertion de cette adresse (U(C_M)) dans la requête, une étape d'envoi de la requête (R') comportant l'adresse au serveur tiers (40).

Description

Arrière-plan de l'invention La présente invention se rapporte au domaine

général des 5 télécommunications. L'invention concerne plus particulièrement les mécanismes permettant à un serveur de contenus et/ou de services auquel accède un terminal via Internet, de connaître les formats de contenus supportés par ce terminal, afin d'adapter les contenus et/ou les services qu'il lui délivre. 10 Ainsi, l'invention s'applique de façon privilégiée mais non limitative dans le contexte des télécommunications mobiles, dans lequel un terminal mobile accède au serveur d'un fournisseur de contenus et/ou de services sur Internet. Dans l'état actuel de la technique, il existe une norme, la norme 15 UAPROF (User Agent PROFile), qui permet à un terminal mobile d'insérer, dans un champ normalisé de la requête qu'il envoie à un fournisseur de services et/ou de contenus, une URL (Uniform Resource Locator). Cette URL permet au fournisseur de services et/ou de contenus d'accéder à un fichier de type UAPROF décrivant les caractéristiques de ce terminal 20 mobile (modèle, constructeur, taille de l'écran, capacités multimédia, etc.). Parmi ces caractéristiques, se trouvent notamment les formats de contenus supportés par le terminal mobile, et en particulier par son navigateur, c'est-àdire par l'application lui permettant d'accéder à Internet. Pour les terminaux GSM par exemple, ces fichiers UAPROF sont 25 générés par les constructeurs des terminaux. Cependant, la génération des fichiers UAPROF associés aux différents terminaux est facultative et souffre d'un manque de fiabilité. Ainsi, il n'existe pas nécessairement un fichier UAPROF associé à chaque terminal, ou plus précisément à chaque catégorie ou modèle de terminaux. Par ailleurs, il arrive fréquemment qu'un fichier UAPROF associé à un terminai contienne des erreurs ou encore qu'il ne soit pas complet et notamment qu'il ne comporte pas les formats des contenus supportés par le terminal. Il se peut même que ce fichier ne soit pas adapté au terminal auquel il est associé, par exemple, parce que l'on a associé à une catégorie de terminaux un fichier correspondant à une autre catégorie de terminaux. Face à ce manque de fiabilité, la plupart des fournisseurs de services et/ou de contenus n'utilisent pas les informations comprises dans le fichier UAPROF. Ils délivrent alors au terminal des contenus sans les adapter aux formats supportés par le terminal, encourant ainsi un risque non négligeable que ces contenus ne soient pas compatibles avec le terminal, aboutissent à une erreur du navigateur et induisent une plainte de l'utilisateur du terminal auprès du fournisseur de services et/ou de contenus.

Objet et résumé de l'invention Selon un premier aspect, la présente invention vise un procédé d'insertion d'une adresse dans une requête envoyée par un terminal à un serveur tiers, cette adresse permettant d'accéder à un fichier.

Conformément à l'invention, le procédé d'insertion comporte, avant l'insertion de l'adresse dans la requête : ù une étape d'interception de la requête - une étape d'obtention, à partir de cette requête, d'un identifiant d'une catégorie de terminaux une étape d'obtention, à l'aide de cet identifiant, de l'adresse permettant d'accéder au fichier, ce fichier comportant les formats de contenus supportés par un terminal de la catégorie identifiée par l'identifiant ; et après l'étape d'insertion de l'adresse dans la requête, une étape d'envoi 30 de la requête comportant l'adresse au serveur tiers.

Corrélativement, l'invention vise égaiement un dispositif d'insertion d'une adresse dans une requête envoyée par un terminal à un serveur tiers, cette adresse permettant d'accéder à un fichier. Conformément à l'invention, ce dispositif d'insertion comporte : des moyens pour intercepter la requête ; des moyens pour obtenir, à partir de cette requête, un identifiant d'une catégorie de terminaux ; des moyens pour obtenir, à l'aide de cet identifiant, l'adresse permettant d'accéder au fichier de la base de données, ce fichier 10 comportant les formats de contenus supportés par un terminal de la catégorie identifiée par l'identifiant ; des moyens pour insérer l'adresse dans la requête ; et des moyens pour envoyer la requête ainsi modifiée au serveur tiers. Les moyens pour intercepter la requête sont par exemple mis en 15 oeuvre par un proxy. Au sens de l'invention, une catégorie de terminaux peut désigner un modèle de terminaux. Ce modèle est par exemple identifié par une référence et un nom de constructeur ou une marque. En variante, une catégorie de terminaux peut désigner des terminaux ayant certaines 20 capacités communes ou supportant des formats de contenus identiques. Préférentiellement, les terminaux considérés dans l'invention seront des terminaux mobiles. Cependant, cette hypothèse n'est en aucun cas limitative, l'invention s'appliquant également à des terminaux fixes. Ainsi l'invention permet d'intercepter une requête émise par un 25 terminal à destination d'un serveur tiers particulier, pour y insérer une adresse permettant à ce serveur tiers d'accéder à un fichier d'une base de données fiable, comportant les formats de contenus supportés par le terminal. L'adresse insérée dans la requête est obtenue à l'aide d'un identifiant d'une catégorie de terminaux. Cette catégorie de terminaux est 30 préférentiellement la catégorie à laquelle appartient le terminal à l'origine de la requête. L'identifiant de cette catégorie est obtenu à partir de la requête émise par le terminal. Sur réception de la requête comportant l'adresse du fichier de formats, le serveur tiers peut consulter ce fichier et garantir la qualité des contenus délivrés au terminal en les adaptant aux formats supportés par ce terminal. Cette opération est avantageusement transparente pour l'utilisateur du terminal. Dans un mode particulier de réalisation de l'invention, le dispositif d'insertion selon l'invention est localisé chez un fournisseur d'accès à Internet. Par nécessité, un fournisseur d'accès dispose de sa propre base de données centralisée comportant les formats de contenus supportés par les différentes catégories de terminaux mobiles de ses abonnés. Cette base de données est donc par définition fiable et exhaustive (ou quasiment relativement à ses abonnés). Le dispositif d'insertion peut ainsi être placé avantageusement en coupure de flux en sortie de toute plateforme d'accès sans impact sur ces accès. Il peut par exemple être localisé sur un Proxy cache tel que ceux usuellement déployés en sortie de ce type de plateforme. Préférentiellement, l'adresse obtenue à l'étape d'obtention et 20 insérée dans la requête interceptée est une adresse de type URL. Au cours de l'étape d'insertion, l'adresse peut être insérée notamment dans un champ de l'entête de la requête interceptée (par exemple requête HTTP, HyperText Transfer Protocol). Ce champ est par exemple le champ normalisé de la norme UAPROF dans lequel sont insérés 25 par les terminaux mobiles les URL des fichiers UAPROF conformément à cette norme. Il s'agit par exemple du champ x-wap-profile ou du champ profile . Dans un mode particulier de réalisation de l'invention dans lequel les terminaux sont des terminaux mobiles, les fichiers des formats 30 supportés par les différentes catégories de terminaux ainsi que le champ de l'entete des -uêtes dans lequel est inséré l'URL, sont conformes à la norme UAPROF. De façon avantageuse, le serveur tiers n'a ainsi pas besoin de développer d'interface particulière de consultation de la base de données centralisée comportant les fichiers de format de contenus. Il peut accéder à ces fichiers via les adresses insérées dans les requêtes par le dispositif d'insertion selon l'invention et identifier les informations de formats qui lui sont utiles conformément à la norme UAPROF. L'invention offre ainsi une opération transparente du point de vue du serveur tiers du fournisseur de services, déjà adapté à traiter une requête émise par un terminal conformément à la norme UAPROF, c'est-à-dire comportant dans son entête un champ dans lequel se trouve une URL permettant d'accéder à un fichier UAPROF censé contenir les formats de contenus supportés par ce terminal.

Dans un mode particulier de réalisation de l'invention, le procédé d'insertion comporte en outre une étape d'obtention d'un code d'accès à la base de données. Conformément à l'invention, ce code d'accès ainsi obtenu est inséré avec l'adresse dans la requête. Corrélativement, le dispositif d'insertion selon l'invention comporte en outre des moyens pour obtenir un code d'accès à la base de données. Conformément à l'invention, ce code est inséré avec l'adresse par les moyens d'insertion du dispositif selon l'invention dans la requête interceptée. Ce code d'accès permet notamment de limiter l'accès à la base de données des fichiers de formats aux seuls fournisseurs de services et/ou de contenus partenaires du dispositif selon l'invention. Par ailleurs, lorsque ce code d'accès est temporaire, il permet également de limiter dans le temps les accès à la base de données. Ceci peut être utile notamment en cas de mise à jour de la base de données, par exemple pour mettre à jour les fichiers de formats associés aux différentes catégories ou pour ajouter une nouvelle catégorie de terminaux. L'adresse et le code d'accès peuvent également être cryptés ou chiffrés avant d'être insérés dans la requête. Les différentes clés alors nécessaires pour crypter et décrypter l'adresse et le code d'accès sont respectivement détenues par le dispositif d'insertion selon l'invention et le serveur tiers du fournisseur de services. Ceci permet notamment de sécuriser d'une part la transmission de l'adresse à destination du serveur tiers, mais également l'accès à la base de données du dispositif d'insertion, en limitant en particulier cet accès aux seuls fournisseurs de services qui disposent des clés nécessaires pour décrypter l'adresse. Selon un second aspect, l'invention vise également un système de télécommunications comportant : un terminal mobile adapté à envoyer une requête d'accès à un serveur tiers ; un dispositif d'insertion selon l'invention, adapté à insérer une adresse dans la requête d'accès envoyée par le terminal au serveur tiers ; et le serveur tiers, celui-ci étant apte à délivrer un contenu au terminal en 20 réponse à la requête émise par ce terminal, après avoir adapté le format du contenu en fonction d'une catégorie de terminaux. Dans un mode particulier de réalisation, les différentes étapes du procédé d'insertion sont déterminées par des instructions de programmes d'ordinateurs. 25 En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un dispositif d'insertion ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé 30 d'insertion tel que décrit ci-dessus.

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins et annexe qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif et dans lesquels : . . la figure i représente un système ae télécommunications conforme à

l'invention dans un mode particulier de réalisation ;

la figure 2 représente, sous forme d'organigramme, les principales étapes d'un procédé d'insertion conforme à l'invention, dans un mode

particulier de réalisation dans lequel le dispositif d'insertion mettant en oeuvre ce procédé est situé chez un fournisseur d'accès et de contenus

l'annexe 1 est un extrait d'un fichier UAPROF comportant les formats de contenus supportés par une catégorie de terminaux, dans un mode particulier de réalisation de l'invention, Description détaillée d'un mode de réalisation

La figure 1 représente un système de télécommunications 1

conforme à l'invention dans un mode particulier de réalisation. 15 Conformément à l'invention ce système de télécommunications 1

comporte :

un terminal mobile 10, adapté à communiquer sur Internet via un réseau de télécommunications mobile. Le terminal mobile 10 est notamment équipé d'un navigateur, lui permettant d'envoyer et de

20 recevoir des requêtes de type HTTP à destination et en provenance de différents serveurs de contenus et/ou de services ;

un serveur 40 d'un fournisseur de services et/ou de contenus FC sur Internet (serveur tiers au sens de l'invention) ;

un serveur 20 d'un fournisseur d'accès FAI à Internet. Ce fournisseur

25 d'accès FAI est par exemple l'opérateur de téléphonie mobile auprès duquel l'utilisateur du terminal mobile 10 est abonné pour communiquer avec son terminal ; et

une base de données interne 30 générée et maintenue, dans l'exemple décrit ici, par le fournisseur d'accès FAI.

Le terminai mobile 10 appartient à une catégorie de terminaux identifiée par un identifiant Cet identifiant est ici une référence correspondant au modèle du terminal 10. Il est par exemple constitué de la marque ou du nom du constructeur du terminal 10 ainsi que de sa référence. Par exemple C_M = Orange123. Dans la description qui suit, par souci de simplification, on pourra utiliser indifféremment les expressions terminal de catégorie C_M ou terminal C_M pour désigner un terminal appartenant à la catégorie de terminaux C_M, c'est-à-dire ici un terminal correspondant au modèle C_M. La base de données 30 du fournisseur d'accès FAI associe à chaque catégorie C de terminaux une URL U(C) et un fichier f(C) de type UAPROF comportant les formats de contenus supportés par les terminaux de la catégorie C. Ainsi, dans l'exemple décrit ici, en consultant la base de données 30 à l'aide de l'identifiant C_M de catégorie de terminaux mobiles, on obtient l'adresse URL U(C_M), qui permet d'accéder au fichier UAPROF f(C_M) décrivant les capacités d'un terminal appartenant à la catégorie C_M. On suppose que toutes les catégories de terminaux mobiles adaptés à communiquer sur le réseau de communications mobiles opéré par le fournisseur d'accès (et opérateur FAI) sont présentes dans la base de données 30. Un extrait d'un fichier UAPROF f(C) est donné en annexe décrite maintenant. Comme vu précédemment, ce fichier f(C) UAPROF comporte différentes informations, dont notamment, le nom du constructeur du terminal C (i.e., ici du modèle de terminal C), son modèle, la taille de son écran et les caractéristiques multimédia de ce terminal informations non représentées en annexe 1). Ce fichier est un fichier écrit en langage XM 10 comporte également les différents formats de contenus supportés par les terminaux C associés à ce fichier. Ainsi, à titre d'exemple, la ligne 19 du fichier f(C) de l'annexe 1 indique que le terminal mobile C supporte les contenus audio de format mp3 . De même, ce terminal supporte également les images au format bmp ou gif selon les lignes 23 et 24 de l'annexe 1. Les fichiers de la base de données 30 décrits ici sont des fichiers en langage XML conformes à la norme UAPROF. Ceci permet notamment de réaliser une opération transparente pour le fournisseur de services, déjà adapté à consulter et à gérer de tels fichiers. Celui-ci n'a pas besoin en conséquence de développer d'interface particulière pour isoler dans les fichiers de la base de données les informations concernant les formats de contenus supportés par les terminaux lui envoyant des requêtes. Cependant, cette hypothèse n'est en aucun cas limitative. D'autres formats de fichiers, écrits selon d'autres langages, peuvent être utilisés dans le cadre de l'invention. Le serveur 20 du fournisseur d'accès FAI comporte un Proxy 21. Dans l'exemple décrit ici, ce Proxy 21 intercepte les flux HTTP (requêtes et réponses), via le protocole normalisé 'CAP (Internet Content Adaptation Protocol). Ce protocole permet d'encapsuler les requêtes et les réponses HTTP ainsi interceptées et de les envoyer vers un service 22 de personnalisation implémentant une interface ICAP (appelé aussi service ICAP 22). Pour plus d'informations sur le protocole ICAP, l'homme du métier se référera au site www.i-cap.org/spec/rfc3507.txt, Le serveur 20 du fournisseur d'accès FAI est un dispositif d'insertion au sens de l'invention. Dans l'exemple décrit ici, ce serveur 20 a l'architecture matérielle d'un ordinateur, Il comporte notamment un processeur, une mémoire morte et une mémoire vive non représentés sur la figure 1, La mémoire morte du serveur 20 comporte notamment un programme informatique adapté à exécuter les principales étapes du procédé d'insertion selon l'invention, ces principales étapes étant représentées sous la forme d'un organigramme dans un mode particulier de réalisation de l'invention sur la figure 2 décrite maintenant. On suppose que le fournisseur de services et de contenus FC a convenu au préalable d'un accord de partenariat avec le fournisseur d'accès FAI, qui est également ici l'opérateur de téléphonie mobile auprès duquel l'utilisateur du terminal 10 est abonné. Conformément à cet accord, le fournisseur d'accès FAI intercepte toute requête d'accès émise par un terminal mobile à destination du fournisseur de services FC pour y insérer une adresse de type URL. Cette adresse permettra ensuite au fournisseur de services FC d'accéder à un fichier UAPROF comportant les formats de contenus supportés par le terminal mobile à l'origine de la requête d'accès. On suppose maintenant que le terminal mobile 10 émet une 15 requête HTTP R vers le site Internet du fournisseur de services FC (requête à destination du serveur 40). Cette requête R transite par le fournisseur d'accès FAI. Elle est interceptée à l'étape EU) par le Proxy 21 du serveur 20 du fournisseur d'accès FAT, placé en coupure de flux entre le terminal mobile 10 et le 20 serveur 40 du fournisseur de services FC. Ce Proxy 21 est par exemple un Proxy cache usuellement placé en sortie de plateforme chez un fournisseur d'accès. Au cours de l'étape E12, le Proxy 21 analyse la requête R et identifie au cours d'une étape E14 que le destinataire de cette requête R 25 est le serveur d'un fournisseur de services partenaire du fournisseur d'accès. La requête R est alors envoyée par le Proxy 21, via le protocole ICAP, au service de personnalisation ICAP 22, au cours d'une étape E18. Si au cours de l'étape E14, le Proxy 21 identifie que le 30 destinataire 40 de la requête R ne correspond pas à un fournisseur de 12 contenus et/ou de services partenaire du fournisseur d'accès FAT, alors il relaie sans modification la requête R vers le site destinataire 40, au cours d'une étape E16. Dans un autre mode de réalisation de l'invention, le Proxy 21 intercepte toutes les requêtes et les renvoie vers le service ICAP 22. C'est le service ICAP 22 qui identifie alors quelles sont les requêtes destinées à un fournisseur de contenus et/ou de services partenaire du fournisseur d'accès FAT, puis les traite conformément à l'invention. Les requêtes non destinées à un fournisseur de contenus et/ou de services partenaire du fournisseur d'accès FAI sont relayées sans modification via le Proxy 21 vers le site du fournisseur de contenus et/ou de services. On suppose ici que le service ICAP 22 fonctionne en mode requête c'est-à-dire qu'il est adapté à modifier une requête interceptée et transmise par le Proxy 21 selon le protocole ICAP.

Au cours d'une étape E20, le service ICAP 22 obtient à partir de la requête interceptée R un identifiant C_M de la catégorie de terminaux à laquelle le terminal 10 appartient. Cet identifiant est ici, comme mentionné précédemment, la référence (ou désignation) du modèle du terminal 10 (C_M=Orangel23). Dans l'exemple décrit ici, l'identifiant C_M a été inclus dans le champ user agent (agent utilisateur) de la requête R par le navigateur du terminal 10. Le service ICAP 22 extrait donc l'identifiant C_M de ce champ user agent de la requête R. Dans un autre mode de réalisation de l'invention, on suppose que l'identifiant de catégorie C_M désigne un ensemble de terminaux supportant les mêmes formats de contenus et n'est pas limité à un seul modèle de terminaux. On suppose alors qu'il existe au niveau du fournisseur d'accès FAI une base établissant pour chaque modèle de terminal un identifiant de la catégorie de terminaux à laquelle il est associé. Le service ICAP 22, après avoir extrait du champ user agent le modèle du terminai 10, obtient alors sur consultation de cette base, l'identifiant C_M correspondant au terminal 10. Dans un autre mode de réalisation de l'invention, l'identifiant de catégorie C_M peut être obtenu à partir d'un identifiant du terminal 10 auprès de l'opérateur FAI (par exemple le numéro de téléphone de l'utilisateur abonné du terminal 10). Une base associant à chaque numéro de téléphone un identifiant de catégorie de terminaux permet alors au service ICAP 22 de déduire du numéro de téléphone du terminal 10 l'identifiant de catégorie C_M lui correspondant.

L'identifiant C_M est ensuite utilisé par le service ICAP 22 pour interroger, au cours d'une étape E22, la base de données interne 30 du fournisseur d'accès FAI selon des principes connus de l'homme du métier. A l'issue de cette interrogation, le service ICAP 22 obtient l'URL U(C_M) permettant d'accéder au fichier UAPROF f(C_M) correspondant au modèle du terminal 10. Par exemple : U(C_M) = http://baseterminauxorange/recherche Dans cet exemple, l'adresse U(C_M) est la même pour des identifiants C_M distincts. Cependant, cette hypothèse n'est en aucun cas limitative. L'adresse U(C_M) peut être différente pour chaque identifiant.

Par exemple : U(C_M) = http://baseterminauxorange/recherche ? Entree=C_M Le service ICAP 22 obtient également au cours de cette étape, un code d'accès temporaire CAT à la base 30 pour le serveur 40 du fournisseur de services FC. Ce code d'accès CAT, généré par la base de données 30, est par exemple ici constitué d'une combinaison chiffrée de l'identifiant C_M, de la date, du site 40 et d'un code secret. Par exemple : CAT = 654765789. En variante, dans un autre mode de réalisation de l'invention, le code d'accès temporaire CAT est généré par le service ICAP 22.

Au cours d'une étape E24, le service ICAP 22 insère dans un champ de l'entête de la requête HTTP R, par exemple dans le champ xwap- profile ou profile selon la version WAP (Wireless Application Protocol) utilisée, l'URL U(C_M) et le code d'accès CAT. Dans le mode de réalisation décrit ici, le code d'accès est fourni en paramètre de l'URL U(C_M). Par exemple, le service ICAP 22 insère dans le champ x-wapprofile ou profile de la requête R : http://baseterminauxorange/recherche ? Entree = 654765789. La requête R ainsi modifiée, comportant dans son entête l'URL 10 U(C_M) et le code d'accès CAT, est notée R'. En variante, le code d'accès CAT peut être fourni également dans un champ de la requête HTTP différent du champ dans lequel est inséré l'URL. Dans un autre mode de réalisation de l'invention, le service ICAP 15 22 applique à l'URL U(C_M) et au code d'accès CAT un algorithme de chiffrement avant d'insérer ces éléments dans le champ de l'entête de la requête R. Cet algorithme est par exemple un algorithme de chiffrement utilisant une clé partagée par le fournisseur d'accès FAI et le fournisseur de services FC. De tels algorithmes sont connus de l'homme du métier et 20 ne seront pas décrits plus en détails ici. Ceci permet ainsi de garantir que seul un fournisseur de services FC partenaire du fournisseur d'accès FAI et disposant de la clé partagée peut accéder à la base 30 du fournisseur d'accès FAT. Au cours d'une étape E26, le service ICAP 22 envoie alors la 25 requête modifiée R' vers le Proxy 21, qui la transfère au cours d'une étape E28 vers le serveur 40 du fournisseur de services FC. Sur réception de la requête R', le serveur 40 émet une requête I vers l'URL U(C_M) de la base de données 30. Dans l'exemple décrit ici, le code d'accès temporaire CAT est fourni en paramètre de l'URL variante, code d'accès temporaire CAT peut être fourni dans l'entête de la requête' vers I'URL U(C_M). En réponse à cette requête, la base de données 30 délivre au serveur 40 le fichier UAPROF f(C JI) correspondant au terminal 10 identifié par l'identifiant C_ Le serveur 40 du fournisseur de services FC extrait alors du fichier f C jvl) les différents formats de contenus supportés par le terminal mobile 10. Il réalise alors l'adaptation du contenu demandé dans la requête R émise par le terminal 10 en fonction de ces formats, et retourne ce contenu au terminal 10 via la réponse A. Cette réponse transite ici par le Proxy 21 du serveur 20 du fournisseur d'accès FAI avant d'atteindre le terminal 10 et de s'afficher sur son navigateur.

Dans le mode particulier de réalisation de l'invention décrit précédemment, le dispositif d'insertion selon l'invention (serveur 20 du fournisseur d'accès FAI) comporte à la fois le Proxy 21 et le service ICAP 22. Cependant cette hypothèse n'est pas en aucun cas limitative. En effet, dans un autre mode de réalisation de l'invention, les différents moyens du dispositif d'insertion selon l'invention peuvent être répartis sur des entités physiques distinctes (par exemple le Proxy 21 et le service 'CAP 22 se trouvent sur deux serveurs distincts) reliées entre elles via des moyens d'interconnexion (ex. par un bus de données).

ANNEXE 1

< rdf:li >application/java </rdf:li > <<rdf:Ii>application/java-archive</rdf:Ij> <rdf:Ii>application/sdp</rdf:li> <rdf:Ii>application/smil</rdf:li> < rdf: >application/vnd.wap.connectivity-wbxmI </rdf:Ii> <rdf:li>application/vnd.wap.multipart.related</rdf:li> <rdf:Ii>application/vnd.wap.sic</rdf:Ij> < rdf: application/vnd.wap.wbxmI </rdf: > <rdf:Ii>application/vnd.wap.wmIc</rdf:Ii> < rdf:1i>applicationivnd.wap.wmIscriptc</rdf:Ii> <rdf:li>application/wml+xml</rdf:li> <rdf:li >application/xhtml+xml</rdf:li> < rdf: >application/x-java-archive</rdf:li > < rdf:li >applîcatiion/x-msmetafile</rdf:li> <rdf:Ii>application/x-pip</rdf:ii> <rdf:Ii>audio/mp3</rdf:Ii> <rdf:li>audio/mp4</rdf:ll><rdf:Ii>audio/mpeg</rdf:Ii> <rdf:Ii>audio/wav</rdf:11> <rdf:li>image/bmp</rdf:li> <rdf:li>image/gif</rdf:Ii> < rdf:li>image/jpeg < /rdf: > <rdf:li>image/jpg</rdf:11> <rdf:li>multîpart/mixed</rdf:li> <rdf:Ii>text/htmI</rdf:Ii> <rdf:li>textiplain</rdf:Ii>30

Claims

REVENDICATIONS

1. Procédé d'insertion (E24) d'une adresse (U(C_M)) dans une requête (R) envoyée par un terminal (10) à un serveur tiers (40), cette adresse permettant d'accéder à un fichier (f(C_M)) ledit procédé étant caractérisé en ce qu'il comporte, avant ladite insertion (E24) : - une étape d'interception (EH)) de ladite requête (R) ; - une étape d'obtention (E12), à partir de ladite requête (R), d'un identifiant (C_M) d'une catégorie de terminaux ù une étape d'obtention (E22), à l'aide dudit identifiant, de ladite adresse (U(C_M)) permettant d'accéder audit fichier (f(C_M)), ce fichier comportant des formats de contenus supportés par un terminal de ladite catégorie et après ladite insertion (E24) de ladite adresse (U(C_M)) dans ladite requête (R) : - une étape d'envoi (E28) de ladite requête (R) comportant ladite adresse audit serveur tiers (40).

2. Procédé selon la revendication 1 caractérisé en ce que, à ladite étape d'obtention (E22), l'adresse obtenue (U(C_M)) est une URL.

3. Procédé selon la revendication 1 ou 2 caractérisé en ce que au cours de ladite étape d'insertion (E24), ladite adresse est insérée dans un champ de l'entête de ladite requête (R).

4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte en outre une étape d'obtention (E22) d'un code d'accès (CAT) et en ce que, au cours de ladite insertion (E24), on insert également dans ladite requête (R) ledit code d'accès (CAT) ainsi obtenu.

5. Procédé selon la revendication 4, caractérisé en ce que ledit code d'accès (CAT) et ladite adresse (U(C_M)) sont cryptés avant d'être insérés dans ladite requête (R).

6. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé d'insertion selon l'une quelconque des revendications 1 à 5 lorsque ledit programme est exécuté par un ordinateur.

7. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'insertion selon l'une quelconque 10 des revendications 1 à 5.

8. Dispositif d'insertion (20) d'une adresse (U(C_M)) dans une requête (R) envoyée par un terminal (10) à un serveur tiers (40), cette adresse (U(C_M)) permettant d'accéder à un fichier (f(C_M)), ledit 15 dispositif (20) comportant : ù des moyens (21) pour intercepter ladite requête (R ù des moyens (21) pour obtenir, à partir de ladite requête (R), un identifiant (C_M) d'une catégorie de terminaux ù des moyens (22) pour obtenir, à l'aide dudit identifiant (CM) ladite 20 adresse (U(C_M)) permettant d'accéder audit fichier (f(C_M)), ce fichier comportant les formats de contenus supportés par un terminal de ladite catégorie ù des moyens (22) pour insérer ladite adresse (U(C_M)) dans ladite requête (R) ; 25 ù des moyens (21) pour envoyer ladite requête (R') comportant ladite adresse audit serveur tiers (40). 13. Dispositif d'insertion selon la revendication 8, caractérisé en ce qu'il comporte un proxy (21) mettant en oeuvre lesdits moyens pour 0 intercepter ladite requête. 14. Système de télécommunications (1) comportant un terminal (10), adapté à envoyer une requête d'accès (R) à un serveur tiers (40) ;un dispositif d'insertion (20) selon la revendication 8 ou 9, adapté à insérer une adresse (U(C_M)) dans ladite requête d'accès envoyée par ledit terminal audit serveur tiers et ledit serveur tiers (40), celui-ci étant apte à délivrer un contenu audit terminal (10) en réponse à ladite requête, après avoir adapté le format de ce contenu en fonction d'une catégorie de terminaux.