FR2979509A1 - Procede et serveur pour le suivi des utilisateurs au cours de leur navigation dans un reseau de communication - Google Patents

Abstract

Procédé de suivi d'applications de navigation (B) pour réseau de communication (N), dans lequel un serveur de suivi contient un ensemble d'éléments de suivi, et met en œuvre - une étape (E1) de réception d'une requête d'éléments de suivi provenant d'une application de navigation (B) - une étape (E2) de détermination si la requête est une première requête provenant de l'application de navigation, - dans le cas positif, une étape (E3) de calcul d'un identifiant pour l'application de navigation, puis une étape (E4) de détermination d'une valeur de durée de cache associée à chaque élément de suivi de l'ensemble, et une étape (E5) de transmission à l'application de navigation de l'ensemble des éléments de suivi et des valeurs associées ; - dans le cas négatif, une étape (E6) de détermination de l'identifiant de l'application de navigation à partir des éléments de suivi demandés dans la requête,

Description

Procédé et serveur pour le suivi des utilisateurs au cours de leur navigation dans un réseau de communication La présentation invention concerne le suivi des utilisateurs au cours de leur navigation dans un réseau de communication. Au sein du réseau Internet et plus spécifiquement dans le réseau de contenu Web, il est connu de chercher à suivre les utilisateurs au cours de leur navigation afin de leur apporter des services personnalisés.

Par exemple, un site de commerce enligne, l'utilisateur peut sélectionner plusieurs produits, à des moments distincts de sa navigation, et les insérer dans un « panier d'achat » virtuel. Il peut effectuer le paiement ultérieurement. Le site doit donc être capable d'identifier l'utilisateur afin de lui affecter un panier d'achat personnel.

Une autre application classique est ta présentation d'annonces (notamment publicitaires) adaptés au profil de l'utilisateur. Pour ce faire, il importe donc de suivre la navigation de L'utilisateur et donc de disposer de moyens de suivi de l'application de navigation qu'il utilise.

Une première solution à cette problématique a été apportée par l'utilisation de données d'identification appelées « cookies ». Ces données sont transmises par Le serveur à l'application de navigation qui les stocke, sous forme d'un fichier, dans la mémoire du terminal de communication sur lequel elle est déployée. Lors de chaque nouvelle requête vers le serveur, l'application attache ces données et est 25 donc aisément reconnue, de façon univoque, par le serveur. La figure 1 illustre ce mécanisme dans le cas d'un suivi par un serveur tiers. Ce serveur tiers ST, « de suivi », est fonctionnellement différent du serveur de contenu SC. Il s'agit par exemple d'un serveur d'annonces publicitaires. L'application de navigation B (ou navigateur ou encore « browser », selon la 30 terminologie en langue anglaise souvent employée) transmet une requête de contenu M1 à un serveur de contenu SC selon le protocole HTTP (HyperText Transfer Protocol) tel que défini par l'IETF (Internet Engineering Task Force). Cette requête M1 identifie une ressource particulière (généralement une page web ou un fichier multimédia) via son URL (Unified Resource Locator). À sa réception, le serveur de contenu SC transmet une réponse M2 contenant la page web demandée. Cette page web contient un lien vers le serveur de suivi ST. Ce tien peut se matérialiser sous la forme d'un encart (par exemple une bannière) dont le contenu est fourni par ce serveur de suivi. Afin de récupérer ce contenu supplémentaire, l'application de navigation B transmet une nouvelle requête M3, destinée cette fois au serveur de suivi ST. Cette requête contient l'identifiant de ressource qui était contenu dans la réponse M2, mais également les données d'identification (- cookie ») pour ce serveur de suivi et un identifiant du serveur de contenu SC précédemment visité. À sa réception, le serveur de suivi ST peut prendre connaissance des données d'identification pour d'une part fournir, dans un message M4, un contenu supplémentaire (un encart publicitaire, par exemple) adapté à l'utilisateur, mais également mémoriser les informations reçues pour construire un profil de l'utilisateur. Ce profil peut notamment garder trace des serveurs de contenu SC visités afin de déterminer les centres d'intérêts de l'utilisateur. Ce mécanisme pose toutefois des problèmes. L'utilisation de « cookies » fait l'objet de nombreuses critiques quant au 20 respect de la vie privée. Sous la pression, ce mécanisme pourrait être abandonné mais avant tout les applications de navigation peuvent être configurées pour ne pas transmettre ces données d'identification. Certaines applications comme « Safari » sont même configurées par défaut pour ne pas envoyer de données d'identification à des parties tierces (par exemple 25 les sites non directement visités, mais fournissant de la publicité). Par ailleurs, les utilisateurs peuvent eux-mêmes supprimer les « cookies » stockées sur leur disque dur, pour protéger leur vie privée en limitant la transmission de données personnelles, par erreur, pour libérer de l'espace sur leur disque dur, etc. 30 Des alternatives commencent donc à apparaître pour palier les insuffisances du mécanisme par « cookies ». L'alternative principale se base sur l'empreinte du type d'applications de navigation et sur l'adresse IP du terminal de communication sur laquelle elle est déployée. Cette empreinte (ou « fingerprint » en anglais) est constituée des éléments d'informations transmis dans une requête HTTP. Il s'agit notamment d'un identifiant du type de navigateur (Safari, Internet Explorer, Firefox, Mozilla, Chrome...), d'un numéro de version et de la plate-forme ou système d'exploitation du terminal de communication (Windows, Linux, iOS, Android...). Cette solution n'est pas satisfaisante non plus. En effet, il existe des situations où le couple adresse IP / empreinte est te 10 même pour deux instances d'application de navigation distinctes. C'est le cas lorsque l'utilisateur ouvre deux sessions sur une même machine. C'est aussi le cas lorsqu'une entreprise définit une politique pour les logiciels installés sur son réseau de communication de sorte que tous les terminaux de communication utilisent la même version du même type de navigateur. L'empreinte 15 sera donc la même pour tous les équipements de l'entreprise. Par ailleurs, un choix d'infrastructure réseau classique fait que le réseau de communication de l'entreprise est relié au réseau public via un NAT (« Network Address Translator »), de sorte que plusieurs équipements de l'entreprise peuvent être vus par un serveur extérieur avec la même adresse IP. 20 Le même type de situation survient au sein d'un domicile privé où plusieurs des terminaux de communication (ordinateur) de la maison sont configurés de la même façon. Le serveur externe ne pourra pas distinguer les différents membres de la famille. Il en résulte un grand nombre de cas où le couple adresse IP / empreinte ne 25 forme pas un identificateur univoque pour une instance de navigateur. Le but de la présente invention est d'améliorer la situation en proposant un nouveau mécanisme. Un premier objet de la présente invention est un procédé de suivi 30 d'applications de navigation pour réseau de communication, dans lequel un serveur de suivi contient un ensemble d'éléments de suivi, et met en oeuvre - une étape de réception d'une requête d'éléments de suivi provenant d'une application de navigation une étape de détermination si la requête est une première requête provenant de l'application de navigation, dans le cas positif, une étape de calcul d'un identifiant pour l'application de navigation, puis une étape de détermination d'une valeur de durée de cache associée à chaque élément de suivi de l'ensemble, et une étape de transmission à l'application de navigation de l'ensemble des éléments de suivi et des valeurs associées ; dans le cas négatif, une étape de détermination de l'identifiant de l'application de navigation à partir des éléments de suivi demandés dans la requête, Selon des modes de réalisation de l'invention, la détermination si une requête est une première requête peut être faite en fonction du nombre d'éléments de suivi demandés dans ladite requête.

Le procédé peut également comporter une première étape préalable d'émission par l'application de navigation d'une requête de contenu vers un serveur de contenu, et de transmission par ce serveur de contenu du contenu demandé et d'un encart contenant des liens vers les éléments de suivi. L'identifiant peut être constituée d'une première partie contenant des 20 informations d'identification transmises dans ladite requête et d'une seconde partie constituée d'un compteur. Le nombre d'éléments de suivi dans l'ensemble d'éléments de suivi peut être égal à la longueur de ce compteur exprimée en bits. La valeur d'un bit b(i) de poids i et la valeur de durée de cache associée à 25 l'élément de suivi de rang i peuvent être liées par la relation suivante : si b(i)=1, v(i)=max si b(i)=0, v(i)=0 dans laquelle 'max' est la valeur maximale possible pour une durée de cache. L'identifiant peut être en outre précédé d'une première partie indiquant des 30 redirections chaînées. Ces redirections chaînées peuvent être indiquées par le bit de poids correspondant dans cette première partie. À chaque redirection de ces redirections chaînées peut être associée une valeur de cache nulle ou à une valeur maximale possible pour une valeur de cache. Alternativement, à chaque redirection de ces redirections chaînées peut être associée un code de redirection 301 ou 302.

Un second objet de la présente invention est un serveur de suivi contenant un ensemble d'éléments de suivi et des moyens pour mettre en oeuvre le procédé précédemment défini ainsi que les mises en oeuvres indiquées. Un troisième objet de la présente invention est un serveur comportant un serveur de suivi tel que défini ci-avant et un serveur de contenu.

Ainsi, grâce à l'invention, il devient possible d'identifier l'utilisateur sans utiliser de « cookie » ou plus généralement sans devoir nécessiter l'installation de fichiers ou d'information sur le terminal de l'utilisateur. Il est en outre possible de pouvoir discriminer les navigateurs déployés sur une 15 même machine ou sur un même réseau et d'identifier ainsi chacun d'eux. L'identifiant de l'application de navigation ne transite pas explicitement sur le réseau de communication, y compris sur le lien liant le terminal de communication au serveur de suivi. À ce titre, l'invention est robuste vis-à-vis des tentatives d'usurpation d'identité et autres attaques malveillantes. 20 L'invention, ses caractéristiques et ses avantages apparaîtront de façon plus claire dans la description de mises en oeuvre qui va suivre en liaison avec les figures annexées. La figure 1, déjà commenté, illustre un mécanisme de l'état de la technique. 25 Les figures 2 et 3 schématisent deux mises en oeuvre architecturales de l'invention. La figure 4 est un organigramme des différentes étapes mises en oeuvre par un serveur de suivi selon l'invention. La figure 5 est une illustration d'une mise en oeuvre de l'invention utilisant un 30 mécanisme de redirection avec 2 valeurs de codes de redirection. Plusieurs mises en oeuvre du serveur de suivi selon l'invention sont envisageables.

Il est à noter que le serveur de suivi ST peut être une application logicielle qui peut être déployée sur un serveur physique dédié ou partagé avec d'autres applications. Elle peut également être déployée sur un ensemble de machines physiques (« cluster ») selon un mode de fonctionnement réparti ou pair-à-pair.

En outre, ce serveur de suivi ST peut être localisé avec le serveur de contenu SC sur une même machine physique ou dans un même « cluster » de machines physiques, ainsi qu'illustré par la figure 2. Dans la figure 3, le serveur de suivi ST est délocalisé par rapport au serveur de 10 contenu SC. Le serveur de suivi ST peut être une machine dédiée à cette activité de suivi ou bien être une machine (ou un groupe de machines) hébergeant plusieurs applications logicielles. Ces deux architectures techniques peuvent être le reflet de choix 15 commerciaux. Dans le premier cas, les deux serveurs sont administrés par une même organisation. La société en charge du contenu peut également déployer le serveur de suivi. Si la société en question passe par un hébergeur pour déployer le serveur de contenu, celui-ci peut également proposer de déployer un serveur de suivi. Il 20 peut s'agir d'une prestation facturable ou inclue dans un forfait. Le second cas peut correspond à une société tierce spécialisé dans les services web et offrant notamment un service de suivi. La société de contenu ou son hébergeur peut établir un contrat de prestation afin qu'elle assure le suivi de ses visiteurs. Elle peut alors transmettre des rapports sur ces visiteurs en fonction des 25 informations collectées et du contrat souscrit. Le premier cas peut correspondre à un site de commerce enligne et à ta gestion du panier virtuel par la société en charge du contenu. L'invention ne dépend pas de l'architecture et du modèle commercial choisis. 30 Dans un premier temps une application de navigation (ou navigateur) B transmet une requête de contenu M1 à un serveur de contenu SC contenant une U RL.

Le serveur de contenu SC répond par un ou plusieurs messages M2 contenant le contenu demandé. Ce contenu est typiquement une page web, par exemple au format HTML (HyperText Markup Language). Elle peut être stockée statiquement sur le serveur de contenu SC ou bien 5 construite à la volée dynamiquement à partir du contenu d"une base de données (mySQL...) et de scripts en langage PHP. Ce contenu contient une portion relative au serveur de suivi ST. Cette portion peut être transmis préalablement par le serveur de suivi ST au serveur de contenu 10 SC ou être manuellement configurée par un administrateur. La configuration d'une telle portion est connue en soi, dans la mesure où la majorité des sites web incluant des portions de contenu tiers (encarts publicitaires, etc.) fonctionne selon ce principe. Le contenu de cet encart est propre à l'invention. 15 Selon l'invention, cet encart contient un ensemble de liens vers des éléments de suivi. Ces éléments de suivi sont stockés sur le serveur de suivi ST. Il s'agit de fichiers de type quelconque (image, texte, etc.). Il est souhaitable qu'ils soient de taille minime afin d'éviter de dégrader les performances des communications et d'occuper trop d'espace sur te serveur de suivi. 20 Cet encart peut, en langage HTML, être matérialisé par une section <DIV>. Un exemple d'un tel encart peut être : <DIV class=ST> <img src=http://www.st.com/tracker/elt_1.png> <img src=http: / /www.st.com /tracker/elt_2. png> 25 <img src=http://www.st.com/tracker/elt_3.png> </div> Dans cet exemple l'adresse www.st.com est une adresse factice correspondant à celle du serveur ST. La classe « ST » correspond également à la fonctionnalité de 30 suivi et est une chaîne de caractère à usage interne permettant de contrôler le rendu graphique de la section <DIV> à l'aide de feuille de style (fichier .css), mais sans effet technique. Les fichiers « elt_1.png », « elt_2.png », « elt_3.png » sont trois éléments de suivi, ici des images au format png. À la réception de ce message M2, le navigateur B doit récupérer les éléments de suivi afin de pouvoir produire la page et l'afficher sur l'écran du terminal de communication sur lequel il est déployé. Il transmet donc une requête M3 d'éléments de suivi vers le serveur sur suivi. Typiquement, cette requête est formée de messages GET conformes au protocole HTTP, un message GET correspondant à un élément de suivi. À partir de la section DIV de l'exemple, te navigateur B peut construire trois messages GET adressé au serveur www.st.com GET tracker/elt_l .png GET tracker/elt_2.png GET tracker/elt_3.png Cette étape de réception d'une requête en élément de suivi est référencée comme El sur l'organigramme de ta figure 4. A la réception de cette requête, le serveur de suivi ST peut mettre en oeuvre une deuxième étape E2 de détermination si cette requête est une première requête provenant de l'application de navigation B. Cette détermination peut être faite en fonction du nombre d'éléments de suivi demandés dans la requête M3. Si l'ensemble des éléments de suivi est demandé, il s'agit d'une première requête. Dans le cas contraire, comme nous le verrons plus tard, c'est qu'il ne s'agit pas d'une première requête : Il existe des éléments de suivi dans la mémoire cache du navigateur qui ne sont pas redemandés. Dans l'exemple illustré, il s'agit d'une première requête. Le serveur de suivi ST 30 peut alors mettre en oeuvre : une étape E3 de calcul d'un identifiant pour l'application de navigation B, puis une étape E4 de détermination d'une valeur de durée de cache associée à chaque élément de suivi de cet ensemble, et une étape E5 de transmission au navigateur B de l'ensemble de ces éléments de suivi et des valeurs calculées.

Cet identifiant peut être un compteur, incrémenté à chaque nouveau navigateur entrant en relation avec le serveur de suivi ST. Selon une mise en oeuvre préférentielle de l'invention, cet identifiant est composé d'une première partie contenant des informations d'identification transmises dans la requête M3, et d'une seconde partie formée de ce compteur.

Ces informations d'identification peuvent être l'empreinte du navigateur B et peuvent correspondre à l'entête « User Agent » des messages M3 conformes au protocole HTTP. Cet entête est une chaîne de caractères précisant le logiciel utilisé pour se connecter à un serveur HTTP. Comme évoqué précédemment, il comporte généralement le type de navigateur (Mozilla, 1E, Chrome, etc.) et un numéro de version. Le compteur permet de différentier de façon univoque les navigateurs possédant la même empreinte. Par rapport à une mise en oeuvre où l'identifiant est formée du seul compteur, cette mise en oeuvre permet de réduire la taille du compteur et donc le nombre d'éléments de suivi. Ainsi, on peut réduire les ressources mémoires sur le serveur de suivi et dans la mémoire cache du navigateur, ainsi que te volume d'information à transmettre.

Il est également possible d'utiliser l'adresse IP d'émission de la requête M3. Cela permet de réduire encore l'espace nécessaire pour le compteur, puisque celui ne servira plus qu'à discriminer les navigateurs appartenant à un même espace IP et ayant la même empreinte.

Il convient donc de définir préalablement la longueur du compteur, c'est-à- dire d'estimer le nombre maximum attendu de navigateurs possédant la même empreinte et appartenant au même espace IP. Ce nombre peut être configuré avec une valeur par défaut et modifiable par un administrateur.

Cette longueur n (en bits) peut s'exprimer en fonction du nombre maximum N du compteur par la formule : n=[log2(N)]+1 Le serveur de suivi ST mémorise n éléments de suivi. Ces éléments de suivi sont des fichiers de différents types (images, texte, etc.). Ils ne sont pas nécessairement tous du même type. L'étape E4 suivante consiste à déterminer une valeur de durée de cache associée à chaque élément de suivi de cet ensemble de n éléments.

Il existe en effet un mécanisme permettant aux navigateurs de stocker dans une mémoire de cache tout ou partie des éléments téléchargés. Ainsi, lors d'une seconde visite sur une même page web, le navigateur ne téléchargera pas à nouveau les éléments déjà présents dans la mémoire cache. Ce mécanisme permet de minimiser le volume de données transmis.

La mémoire cache peut être sur le disque dur ou dans la mémoire vive du terminal de communication sur lequel est déployé le navigateur. Selon un mode de réalisation de l'invention, les valeurs de durée de cache sont déterminées à partir de l'écriture binaire du compteur.

Ainsi, ce compteur peut s'écrire bn...b3-b2-b1, où bi est le bit de poids i. La valeur v(i) pour l'élément correspondant au bit de poids i est donnée selon la formule suivante : si b(i)=1, v(i)=max si b(i)=0, v(i)=0 dans laquelle max est la valeur maximale possible pour une durée de cache. Il peut également s'agir d'une valeur arbitrairement longue, suffisamment pour que le cache n'expire pas entre deux requêtes du même navigateur. L'étape suivante E5 consiste à transmettre à l'application de navigation B tes 30 éléments de suivi eux-mêmes et les valeurs de durée de cache qui ont été déterminés pour chacun d'entre eux. Cette transmission peut être réalisée en autant de messages M4 que de messages M3 dans la requête.

En effet, selon le protocole HTTP, à chaque message GET correspond un message de réponse « 200 OK » contenant l'élément demandé. Dans l'exemple ci-dessus, il y aura donc trois messages contenant les éléments de suivi elt_1.png, elt_2.png, elt_3.png.

Chaque message de réponse peut contenir la valeur de durée de cache correspondant dans l'entête HTTP. Dans le cas où b(i)=0, un tel entête peut ressembler à : Status Code: 200 OK Cache-control: private, no-transform, max-age=0 content-type: text/xml Content-lenght: 670 server: jetty(6.1.x) Dans le cas où b(i)=1, un tel entête peut ressembler à : Status Code: 200 OK Cache-control: private, no-transform, max-age=2147483647 content-type: text/xml Content-lenght: 670 server: jetty(6.1.x) Le paramètre max-age de la ligne cache-control contient la valeur v(i) qui vaut soit 0, soit La valeur maximale autorisée. Ce paramètre est défini au paragraphe 14.9.3 du RFC 2616 de l'IETE Il peut être utile d'indiquer également te paramètre « private » afin d'éviter que les « proxies » (éléments intermédiaires de proximité mettant en oeuvre un mécanisme de cache) situés entre le navigateur B et le serveur ne mettent en cache ces éléments de suivi et ainsi interfèrent avec le mécanisme de l'invention. Ce mot-clé indique que la gestion du mécanisme de cache pour ces éléments de suivi est « privée », c'est-à-dire de la seule responsabilité du client (le navigateur B) et du serveur. Dans l'exemple à trois éléments de suivi décrit précédemment, on suppose que l'identifiant calculé est 3, soit en binaire « 011 ». Les valeurs de cache sont donc 0 pour elt_3.png, et max (c'est-à-dire ici 2147483647 secondes) pour elt_2.png et elt_1.png.

Les éléments de suivi sont mémorisées dans la mémoire cache du navigateur B. Lorsque le même navigateur B transmet au serveur de contenu SC une nouvelle requête, il reçoit comme précédemment une portion relative au serveur de suivi ST. S'il s'agit de la même page, cette portion peut être identique à celle 10 reçue précédemment (sauf si, par exemple, elle a été mise à jour entretemps). De façon connue en soi, le navigateur est adapté pour récupérer les éléments de suivi afin de pouvoir produire la page et l'afficher sur l'écran du terminal de communication sur lequel il est déployé. Cette récupération se fait en fonction des 15 éléments déjà présents dans la mémoire cache et en fonction de la valeur de durée de cache associée. Lorsque la valeur associée a été fixé à 0 par le serveur, quelque soit le délai entre cette requête et la précédente, le navigateur doit redemander l'élément au serveur de suivi ST. Il transmet donc un message GET requérant l'élément en 20 question. Si la valeur associée a été fixée à « max le navigateur B utilise l'élément de suivi mémorisé pour te produire à l'utilisateur, sans transmettre de message au serveur de suivi. Dans notre exemple, l'application de navigation transmet donc deux messages 25 GET adressés au serveur www.st.com : GET tracker/elt_1.png GET tracker/elt_2.png Le comportement du navigateur est provoqué par les informations transmises 30 par le serveur de suivi ST conformément à l'invention, mais le navigateur lui-même obéit au comportement standard d'un navigateur conforme au protocole HTTP. L'invention n'implique aucune modification au niveau de l'application de navigation ou du terminal de communication.

Le serveur de suivi ST reçoit cette requête d'éléments de suivi dans une étape El. L'étape E2 consiste à déterminer s'il s'agit d'une première requête ou non.

Dans la mesure où la totalité des éléments de suivi n'est pas redemandé (l'élément elt_3.png n'est pas demandé), te serveur ST peut en déduire qu'il ne s'agit pas d'une première requête, et donc que le navigateur B est déjà « connu ». Le serveur de suivi ST peut alors déclencher une étape E6 de détermination de l'identifiant de ce navigateur. Cette détermination se fait à partir des éléments de suivi demandés dans la requête, selon un mécanisme inverse de celui utilisé pour générer l'identifiant. Dans la mise en oeuvre décrite, le rang des éléments de suivi permet d'écrire l'identifiant sous une forme binaire. Les éléments elt_l .png et elt_2.png étant demandés, les bits de poids 1 et 2 sont mis à 1; et l'élément elt_3.png n'étant pas demandé le bit de poids 3 est mis à 0. L'identifiant du navigateur s'écrit donc en binaire « 011 », soit 3. L'identifiant étant connu, le serveur de suivi ST peut mettre en oeuvre différentes stratégie de suivi. Il peut mémoriser les informations récoltées, notamment les adresses URL consultées sur les serveurs de contenu, et ainsi construire un profil de l'utilisateur du navigateur basé sur son historique de navigation. En fonction de ce profil, il peut déterminer des encarts publicitaires adaptés.

Il peut également utiliser ces informations pour construire des statistiques sur les visiteurs d'un site de contenu particulier ou un ensemble de site. Selon une variante de l'invention, il est possible d'utiliser le mécanisme de redirection du protocole HTTP pour réduire la longueur n du compteur et donc le nombre d'éléments de suivi à utiliser. Ce mécanisme de redirection repose sur les messages 302 et 307 du protocole HTTP. Il peut être indiqué dans la portion relative au serveur de suivi ST une adresse URL1. Cette adresse URL1 est configurée dans le serveur de suivi ST comme redirigé vers une adresse URL2. Lors d'une première visite, le navigateur suit ta redirection, mais lors d'une seconde visite, la redirection est mémorisée par le navigateur qui interroge alors 5 directement la seconde adresse URL2. Il est possible d'utiliser ce comportement pour identifier les utilisateurs, en chaînant plusieurs redirections r1, r2, r3, r4, r5. Lorsqu'un utilisateur se connecte pour la première fois à un site, il suit la redirection chaînée : r1 -> r2 -> r3 -> r4 -> r5. Il télécharge automatiquement les 10 éléments de redirection r1, r2, r3, r4, r5. Le serveur peut mettre des valeurs de cache différentes pour chaque élément de redirection, par exemple une valeur nulle pour r2 et r5 et une valeur très élevée pour les autres éléments. Ainsi, lors d'une visite ultérieure, le navigateur se rend directement à 15 l'adresse indiquée par r2 et suit le chemin suivant : r2 -> r5. Il sera donc possible d'en déduire que le navigateur a en cache les éléments r1, r3 et r4 et, à partir de ces informations, de discriminer plusieurs utilisateurs. Une alternative peut consister à utiliser des codes de redirections différents plutôt que des valeurs de cache différentes. On peut par exemple utiliser le code 20 de redirection 301 et le code de redirection 302. En chaînant des redirections avec ces deux valeurs de code, on peut obtenir un arbre binaire tel qu'illustré sur la figure 5. Dans cette figure, on suppose que les branches montantes correspondent à une valeur de code 301 et les branches descendantes correspondent à une valeur de code 302. 25 Les navigateurs ont généralement une valeur maximum du nombre de redirections tolérées (par exemple 5). Aussi, ce mécanisme ne permet de discriminer qu'un nombre limité d'utilisateurs, ici 25=32 Selon un mode de réalisation de l'invention, ce mécanisme est utilisé en 30 complément de l'utilisation des éléments de suivi afin d'en réduire te nombre à gérer. Cette mise en oeuvre de l'invention permet ainsi de diminuer les ressources nécessaires à l'invention sur les serveurs, dans la mémoire de cache du navigateur et lors des transmissions sur le réseau de communication.

Pour ce faire, l'identification de l'application de navigation peut être précédée d'une première partie (de poids fort) indiquant des éléments de redirection. De façon similaire à ce qui a été décrit précédemment comme mise en oeuvre possible de l'écriture de l'identifiant à partir des éléments de suivi, cette première partie peut s'écrire rk...r3-r2-r1 où ri est te bit de poids i et k le nombre de redirections possibles. Les redirections chaînées peuvent être indiquées par le bit de poids correspondant dans ladite première partie.

La valeur v(i) pour l'élément de redirection correspondant au bit de poids i est donnée selon la formule suivante : si ri=1, v(i)=max si ri=0, v(i)=0 dans laquelle max est la valeur maximale possible pour une durée de cache. Il 15 peut également s'agir d'une valeur arbitrairement longue, suffisamment pour que le cache n'expire pas entre deux requêtes du même navigateur. Une autre formule possible peut se baser sur des codes de redirection différents : si ri=1, v(i)=301 20 si ri=0, v(i)=302 L'identifiant du navigateur avec la première partie peut s'écrire rk...r3-r2-r1- bn...b3-b2-b1. La longueur globale est égale à k+n.

Claims (12)

1. REVENDICATIONS1) Procédé de suivi d'applications de navigation (B) pour réseau de communication (N), dans lequel un serveur de suivi contient un ensemble d'éléments de suivi, et met en oeuvre une étape (E1 ) de réception d'une requête d'éléments de suivi provenant d'une application de navigation (B) une étape (E2) de détermination si ladite requête est une première requête provenant de ladite application de navigation, dans le cas positif, une étape (E3) de calcul d'un identifiant pour ladite application de navigation, puis une étape (E4) de détermination d'une valeur de durée de cache associée à chaque élément de suivi dudit ensemble, et une étape (E5) de transmission à ladite application de navigation de l'ensemble desdits éléments de suivi et desdites valeurs ; dans le cas négatif, une étape (E6) de détermination de l'identifiant de Ladite application de navigation à partir des éléments de suivi demandés dans ladite requête,
2. 2) Procédé selon la revendication précédente dans lequel la détermination si une requête est une première requête est faite en fonction du nombre d'éléments de suivi demandés dans ladite requête.
3. 3) Procédé selon l'une des revendications précédentes, comportant une première étape préalable d'émission par ladite application de navigation d'une requête de contenu vers un serveur de contenu, et de transmission par ledit serveur de contenu du contenu demandé et d'un encart contenant des liens vers lesdits éléments de suivi.
4. 4) Procédé selon l'une des revendications précédentes, dans lequel ledit identifiant est constituée d'une première partie contenant des informations d'identification transmises dans ladite requête et d'une seconde partie constituée d'un compteur.
5. 5) Procédé selon la revendication précédente dans lequel le nombre d'éléments de suivi dans ledit ensemble est égale à la longueur dudit compteur exprimée en bits.
6. 6) Procédé selon la revendication précédente dans lequel la valeur d'un bit b(i) de poids i et la valeur de durée de cache associée à l'élément de suivi de rang i sont liées par la relation suivante si b(i)=1, v(i)=max si b(i)=0, v(i)=0 dans laquelle 'max' est la valeur maximale possible pour une durée de cache.
7. 7) Procédé selon la revendication précédente, dans lequel ledit identifiant est précédé d'une première partie indiquant des redirections chaînées.
8. 8) Procédé selon la revendication précédente, dans lequel lesdites redirections chaînées sont indiquées par le bit de poids correspondant dans ladite première partie.
9. 9) Procédé selon l'unes revendications 7 ou 8, dans lequel à chaque redirection desdites redirections chaînées est associée une valeur de cache nulle ou à une valeur maximale possible pour une valeur de cache.
10. 10) Procédé selon l'unes revendications 7 ou 8, dans lequel à chaque 25 redirection desdites redirections chaînées est associée un code de redirection 301 ou 302.
11. 11) Serveur de suivi contenant un ensemble d'éléments de suivi et des moyens pour mettre en oeuvre le procédé selon l'une des revendications précédentes. 30
12. 12) Serveur comportant un serveur de suivi selon la revendication précédente et un serveur de contenu.