FR2931572A1

FR2931572A1 - Procede de validation de messages destine a un termninal de transmission, terminal de transmission, site de regie, systeme de transmission et fournisseur d'applications impliques dans un tel procede

Info

Publication number: FR2931572A1
Application number: FR0802723A
Authority: FR
Inventors: Herve Habadou; Vidal Chriqui
Original assignee: Individual
Current assignee: Individual
Priority date: 2008-05-20
Filing date: 2008-05-20
Publication date: 2009-11-27
Also published as: WO2009150313A1

Abstract

Ce procédé de validation de messages est destiné à la validation de messages publicitaires qui apparaissant dans des zones d'écran d'un terminal de transmission (1). Ce procédé implique : - un navigateur de réseaux (WAP), - un fournisseur (7) d'au moins une application (JAVA), - un site de régie (9) proposant au moins une zone (Pub1, Pub2) dans le cadre de ladite application à être visualisé sur ledit terminal (1), - une identification d'en tête (UA) définissant, entre autres, ledit terminal de transmission. Ce procédé propose les étapes suivantes : - requête de demande d'application (HR1) sur un des fournisseurs d'applications, choisi par l'utilisateur via le navigateur (WAP), - téléchargement et installation (St1) de l'application (JAVA) sur ledit terminal (1), - visualisation desdites zones. - insertion (St2) de ladite identification (UA) d'en tête dans ladite application, -transmission (St3) de ladite identification d'en tête vers ledit site de régie (9).

Description

La présente invention concerne un procédé de validation de messages à effectuer sur des messages apparaissant dans des zones d'écran d'un terminal de transmission, ce procédé impliquant, notamment : - un navigateur de réseaux, - un fournisseur d'au moins une application , - un site de régie proposant au moins une zone dans le cadre de ladite application à être visualisée sur ledit terminal, - une identification d'en tête définissant, entre autres, ledit terminal de transmission, procédé comportant les étapes suivantes : - requête de demande d'application sur un des fournisseurs d'applications, choisi par l'utilisateur via le navigateur, - téléchargement et installation de l'application sur ledit terminal, - visualisation desdites zones. La présente invention concerne un système de transmission impliqué par le 15 procédé. La présente invention concerne un site de régie impliqué dans ledit procédé de validation. La présente invention concerne aussi un terminal de transmission impliqué dans ledit procédé de validation. 20 La présente invention concerne aussi un fournisseur d'application impliqué dans ledit procédé de validation. Dans le monde de l'internet, les sites que l'on explore, montrent le plus souvent des bannières ou messages publicitaires provenant d'annonceurs, que l'utilisateur est invité à regarder et sur lesquels, il peut être invité à cliquer. Le souci majeur de 25 l'annonceur est de connaître l'impact de sa publicité sur le public. Le nombre de clics sur sa publicité ou le nombre d'apparitions de sa publicité est, donc, une donnée particulièrement importante pour lui. L'annonceur est aussi prêt à rémunérer les sites, qui affichent ses annonces, d'une part, sur la base du nombre d'apparitions et aussi, d'autre part, du nombre de clics que les utilisateurs ont effectué sur son annonce publicitaire.

Le monde internet s'est aussi étendu aux téléphones mobiles qui procurent, aussi des accès à des réseaux de type internet et qui offrent donc à l'utilisateur des bannières publicitaires qui sollicitent l'utilisateur. Du fait de la rémunération des publicités, il est important que le nombre d'apparitions et/ou le nombre de clics ne soit pas faussé par des manoeuvres inopportunes voire même frauduleuses. Ainsi, par exemple, un nombre répété de clics provenant d'un même utilisateur, en un temps limité n'est pas significatif pour l'annonceur et n'a pas à être rémunéré. Ceci est facilement repéré dans le cadre de l'internet à domicile où les ordinateurs sont reliés au réseau par l'intermédiaire d'un fournisseur d'accès qui alloue une adresse IP (adresse définie par 1 ( Internet Protocole ) qui reste la même durant une certaine durée ou bien alors est fixe. Comme ces adresses sont transmises lors des requêtes, il est facile de se rendre compte de ces adresses, en considérant principalement l'adresse IP. Il n'en est pas de même pour les téléphones mobiles qui, lors de connexions sur leur réseau internet se voient affectés, provisoirement, d'une adresse IP prise parmi un contingent d'adresses réservées à leur opérateur. Ce nombre d'adresses est plutôt limité, et une adresse IP peut être utilisée par d'autres utilisateurs. Ce critère de l'adresse IP ne peut donc pas être retenu pour les téléphones mobiles, entre autres. Les téléphones portables emploient, un navigateur conçu, le plus souvent, pour traiter les protocoles de l'internet mobile adaptés à leurs possibilités dont le WAP( Wireless Application Protocol ), le Wi-fi ou le Wi-Max.. Tout comme dans le réseau internet, des sites explorés à l'aide dudit navigateur WAP font apparaître sur l'écran du terminal des bannières publicitaires_ pouvant inviter l'utilisateur à cliquer sur une zone afin d'obtenir des informations sur le ou les produits proposés. Si l'utilisateur a perçu la publicité d'un annonceur ou clique sur celle-ci, le serveur mentionnant la publicité d'un annonceur sera rétribué par ce dernier. Dans ce cas, l'utilisateur sera identifié, pour une petite partie, par son adresse IP, pas forcément significative, comme cela vient d'être dit, mais surtout par son UA ( User Agent qui comporte différentes données concernant, notamment la marque de son mobile, le type, le modèle, sa version, etc... Ceci est considéré comme un critère acceptable.

Dans le cadre des téléphones mobiles, survient une difficulté due aux applications propriétaires du type connu sous la dénomination commerciale JAVA notamment. On peut citer également des applications de ce genre connues sous les dénominations commerciales : Symbian, Windows Mobile, BlackBerry, iPhone, Flash Lite ou BREW qui rentrent dans le cadre de l'invention. Ces applications peuvent faire apparaître des publicités sur lesquelles, l'utilisateur peut cliquer. Dans ce cas, la requête qui en découle comporte un UA non significatif qui est difficilement interprétable par l'annonceur pour valider ce clic ou la perception de la publicité. Ceci provient du fait que la bannière publicitaire est demandée ou affichée à l'intérieur d'une application propriétaire (JAVA notamment) et que l'identification du terminal n'est pas comme au niveau de cette application JAVA. En effet, dans un téléphone mobile, chaque application est complètement isolée. Ainsi, une application ne peut chercher des informations sur une autre et en particulier sur l'application native et pré-installée qui est le navigateur WAP. L'invention propose de résoudre ce problème : Pour cela un procédé de validation du genre mentionné dans le préambule est remarquable en ce qu'il comporte les étapes supplémentaires suivantes: - insertion de ladite identification d'en tête dans ladite application, - transmission de ladite identification d'en tête vers ledit site de régie. La description suivante accompagnée des dessins ci-annexés, le tout donné à 20 titre d'exemple non limitatif, fera bien comprendre comment l'invention peut être réalisée. Dans les dessins, les figures représentent : la FIG 1 montre un système dans le quel le procédé de l'invention est mis en application, la FIG.2 montre un premier schéma explicitant le procédé de l'invention, 25 la FIG.3 montre un deuxième schéma explicitant, en variante, le procédé de l'invention. Le système montré à la figure 1, comporte un terminal mobile 1 (tel qu'un téléphone supportant les fonctionnalités de l'Internet Mobile, un assistant personnel ou bien tout autre appareil capable de supporter cette nouvelle technologie) et étant capable 30 de faire fonctionner une application mobile. Ce terminal doit, dans un premier temps, se connecter à une passerelle 3, par voie radio qui affecte une adresse IP nécessitée par le réseau WEB 5. Cette adresse IP peut être aussi affectée à d'autres terminaux mobiles. Le mobile peut avoir ainsi accès à des sites impliqués par l'invention. Un premier site est un site d'application JAVA 7, un autre site est un site de régie publicitaire 9 qui fournit des bannières publicitaires destinée à donner un lien vers des sites annonceurs 10, 12 et autres... De plus en plus souvent, les utilisateurs sont attirés par des applications JAVA qui fonctionnent sur le terminal de façon indépendante du navigateur. Ces applications peuvent faire appel à un site de régie publicitaire 9 qui fournit des adresses pour des sites d'annonceurs 10, 12 commerciaux, associées à des zones de publicité Publ, Pub2 surgissant sur l'écran 15 du terminal 1 et on invite l'utilisateur à cliquer dessus de sorte à faire apparaître, sur l'écran du terminal, un message publicitaire provenant des sites annonceurs 10, 12. Ce site de régie 9 recueille différentes publicités, dont celle d'un annonceur 10 à faire apparaître donc sur l'écran 15 du terminal 1. Une fois que l'utilisateur a cliqué sur une zone dévolue à l'annonceur 10, il appartient au site de régie de mentionner à cet annonceur 10, l'action de l'utilisateur. Comme déjà mentionné, il peut arriver que certains utilisateurs cliquent de nombreuses fois sur la bannière publicitaire de sorte à gonfler le nombre de clics. Il peut y avoir un intérêt car au nombre de clics est souvent liée une somme d'argent. Plus grave, certains utilisateurs peuvent faire appel à des automates qui se mettent à leur place pour faire gonfler ce nombre de clics. Il y a donc lieu de prévoir des mesures pour éviter ce genre d'abus. L'annonceur est aussi intéressé de connaître le nombre de fois qu'un utilisateur a regardé sa publicité. Pour cela, on va examiner la répétition d'informations d'identifications d'utilisateur. Une répétition importante signalera un utilisateur indélicat et les clics ne 25 seront pas comptabilisés et ne généreront pas de revenus. Lorsque sur le terminal, deux applications fonctionnent en concomitance, dans le cadre de l'exemple décrit, une application JAVA et le navigateur WAP, l'application JAVA est dans l'impossibilité de communiquer une information d'identification convenable. 30 Selon l'invention, on propose de fournir une information d'identification valable lorsque les bannières de publicité apparaissent dans le cadre de l'application

propriétaire ( JAVA ou autre ). Cette information d'identification est alors constituée par identification d'en tête UA générée par le navigateur WAP. Un exemple de chaîne de caractère que l'on trouve dans un UA est par exemple : Nokia6230i/2.0 (03.25) Profile/MIDP-2.0 Configuration/CLDC-1.1 Cette identification d'en tête est placée dans l'entête de chaque requête effectuée à partir du navigateur WAP. La figure 2 explicite un premier mode de réalisation du procédé de l'invention. Sur cette figure 2, on a porté des lignes verticales représentant les différents protagonistes impliqués par l'invention, c'est-à-dire : - le telniinal 1 avec les deux applications qui fonctionnent concomitamment : l'application concernant le navigateur WAP et l'application fonctionnant dans l'environnement JAVA, par exemple, - le serveur fournisseur d'applications 7, - le site de régie 9 et finalement, - l'annonceur 10. Après avoir mis en route son navigateur, l'utilisateur choisit un site qui impose une application JAVA, l'étape Stl d'installation démarre. Après la première requête HR1 faite auprès du serveur d'applications 7, ce site fournit, pour une application JAVA demandée, le fichier descriptif JAD. Comme cette première requête HR1 a été faite depuis le navigateur de réseau WAP, cette requête contient l'en-tête UA du navigateur WAP qui est considérée comme élément suffisamment précis pour définir un utilisateur. Cet en-tête est incorporé dans le fichier JAD ce qui est indiqué par JAD+UA sur la figure 2. On télécharge le fichier JAD, ainsi complété, décrivant l'application. Si l'utilisateur, au vu du fichier JAD est satisfait de l'application, il effectue une deuxième requête HR2 pour provoquer le téléchargement JAR de l'application. L'étape St2, qui suit consiste en son installation. Durant cette installation, l'UA est associé à l'application. Lors de l'exploitation de l'application, l'utilisateur est sollicité de cliquer sur une zone de publicité apparaissant dans une bannière (voir fig.1). L'étape St3 montre l'action de l'utilisateur qui déclenche une requête HR3 accompagné de l'UA auprès du serveur de régie publicitaire 9 qui, en retour, lui fournit l'annonce publicitaire ADV. Puis l'application JAVA donne la main PR au navigateur WAP (étape St4) qui lui permet de

revenir sur le site 9 (phase HR4) et ensuite il est possible de faire une redirection RD vers le site de l'annonceur 10 (étape St5).

La figure 3 montre un autre mode de réalisation. Selon ce mode, l'utilisateur fait appel à une application JAVA ou à un serveur de telles applications pour lequel la mesure d'incorporer l'UA dans le fichier JAD n'a été prévue. Cette application peut être aussi contenue dans le PC de l'utilisateur dont le mobile peut être relié via le système connu sous la dénomination commerciale ]3luetooth ou via un système par infrarouge, ou alors tout simplement par un câble. Ceci est effectué dans l'étape ST11 où depuis son navigateur WAP, l'utilisateur effectue une demande de téléchargement (phase DR) sur un site 7' ce qui lui vaut en retour l'obtention du fichier JAD de l'application. La demande de téléchargement peut être aussi initiée depuis le PC en question. Après consultation ou non de ce fichier, l'utilisateur demande le téléchargement de l'application IR. Le téléchargement de l'application JAR a effectivement lieu après. L'étape St12, qui suit, est l'installation INST de l'application. Dans cette application, comme dans le cas ci-dessus, un lien vers un site 9' peut être activé par une requête HR11. En retour le site 9' fournit une bannière publicitaire ADV10 qui peul: intéresser l'utilisateur. Si l'utilisateur veut accéder à des informations que lui propose la bannière, commence, alors, l'étape St14. L'utilisateur doit faire appel à son navigateur WAP (phase PR10). Comme il envoie une requête à partir de son navigateur WAP, celle-ci est accompagnée d'un UA descriptif et est dirigée vers le site 9' (phase HR12). Puis suit la phase de la mémorisation de l'UA au niveau du site 9'. Cet UA est alors emmagasiné St(UA) au niveau du site 9' qui redirige la requête RD 10 vers le site annonceur 5. Si, depuis son application JAVA, l'utilisateur persiste à consulter un annonceur, commence alors l'étape St15. L'utilisateur effectue, donc, une autre requête HR12, ceci est détecté par le site de régie publicitaire 9' qui retourne l'UA de l'utilisateur au moyen du RMS (phase UA(RMS)). On trouvera des références concernant l'utilisation de RMS sur le site suivant : http://www.JAVA-tips.org/JAVA-me-tips/mi dp/an-eaample-of-use-of -rms- for-storing-persistent-data.html D'autres alternatives peuvent être utilisées à la mémorisation de l'UA qui restent aussi dans le cadre de l'invention. Si l'utilisateur veut se reconnecter sur le site 4. 7 publicitaire, il effectue une requête HR13 depuis son application JAVA mais cette fois-ci. elle est accompagnée de l'UA. Le message publicitaire ADVI 1 est alors envoyé à l'utilisateur procurant ainsi d'autres liens sur lesquels l'utilisateur est invité à cliquer. Pour cela, on bascule sur le navigateur WAP (phase PR12) qui effectue cette connexion accompagnée bien entendu de l'UA descriptif (phase I-1RI4). Le site de régie 9' redirige vers l'annonceur concerné cette requête (phase RD11). Le stade final de validation s'effectue sur le journal des opérations (log) qui montre les accès sur les zones de publicité avec en regard des identificateurs. L'UA transmis en conformité avec l'invention permet donc de valider la perception de la publicité et aussi les bons ou les mauvais clics. Du fait de la bonne reconnaissance de l'utilisateur par son UA, il devient possible de modifier les publicités à afficher ou même de changer celles-ci en fonction de l'UA et même de l'adapter au type de la machine que l'utilisateur possède. De préférence, l'invention concerne un procédé de validation de messages à effectuer sur des messages apparaissant dans des zones d'écran d'un terminal de transmission, ce procédé impliquant, notamment : - un navigateur de réseaux (WAP), - un fournisseur d'au moins une application (JAVA), - un site de régie proposant au moins une zone dans le cadre de ladite application à être visualisé sur ledit terminal, - une identification d'en tête (UA) définissant, entre autres, ledit terminal de transmission, procédé comportant les étapes suivantes : - requête de demande d'application sur un des fournisseurs d'applications, choisi par l'utilisateur via le navigateur (WAP), - téléchargement et installation de l'application sur ledit terminal, - visualisation desdites zones. caractérisé en ce qu'il comporte les étapes supplémentaires suivantes: - insertion de ladite identification (UA) d'en tête dans ladite application, - transmission de ladite identification d'en tête vers ledit site de régie.

Le procédé comporte une étape supplémentaire : transmission de ladite identification d'en tête vers ledit site de régie depuis ladite application lors d'un clic effectué par l'utilisateur sur au moins une desdites zones. L'identification d'en tête est insérée dans la phase de téléchargement et installation de l'application. L'identification d'en tête est insérée dans ladite application lors d'un accès effectué sur ledit site de régie. Ladite application est du type JAVA, l'étape d'insertion de l'identification d'en tête consistant à utiliser un système d'enregistrement, notamment RMS offert par les possibilités des applications .JAVA. Ladite identification est une chaîne connue sous le nom de User Agent , Le procédé est destiné à un site de régie associé à plusieurs sites annonceurs et comporte une étape supplémentaire de transmission de validation de clic sur les sites clients impliqués.

L'invention concerne un système de transmission dans lequel le procédé de validation est mis en application, comprenant : - un terminal doté d'un navigateur, - au moins un fournisseur d'applications, pour l'installation d'une application dans le terminal, - un site de régie et - au moins un site annonceur, une identification d'en tête fournie par ledit navigateur étant insérée dans ladite application pour être utilisée comme critère de validation lors d'une demande de connexion vers ledit site annonceur.

Un site de régie proposant des zones à cliquer apparaissant au sein de ladite application adapté au procédé, comportant un moyen pour enregistrer l'identification d'en tête provenant d'un terminal et pour la retransmettre vers ledit terminal au sein de ladite application. Un fournisseur d'applications adapté au procédé caractérisé en un moyen pour enregistrer l'identification d'en tête provenant d'un terminal et pour l'insérer dans l'application.

Un terminal pour un utilisateur percevant des zones en conformité selon le procédé comporte des moyens pour faire fonctionner le navigateur et l'application et des moyens de fourniture de l'identification d'en tête en vue de l'insertion dans ladite application.

Claims

REVENDICATIONS1- Procédé de validation de messages à effectuer sur des messages apparaissant dans des zones d'écran d'un terminal de transmission (1), ce procédé impliquant, au moins : - un navigateur de réseaux (WAP), - un fournisseur d'au moins une application (JAVA), - un site de régie (9) proposant au moins une zone dans le cadre de ladite application à être visualisée sur ledit terminal, - une identification d'en tête (UA) définissant, entre autres, ledit terminal de transmission, procédé comportant les étapes suivantes : - requête de demande d'application sur un des fournisseurs d'applications, choisi par l'utilisateur via le navigateur (WAP), - téléchargement et installation de l'application sur ledit terminal, - visualisation desdites zones. caractérisé en ce qu'il comporte les étapes supplémentaires suivantes: - insertion de ladite identification (UA) d'en tête dans ladite application, - transmission de ladite identification d'en tête vers ledit site de régie.
2- Procédé selon la revendication 1, caractérisé en ce qu'il comporte une étape supplémentaire. - transmission de ladite identification d'en tête vers ledit site de régie depuis ladite application lors d'un clic effectué par l'utilisateur sur au moins une desdites zones.
3- Procédé selon la revendication 1 ou 2, caractérisé en ce que l'identification d'en tête est insérée dans la phase de téléchargement et installation de l'application.
4- Procédé selon la revendication 1 ou 2 caractérisé en ce que l'identification d'en tête est insérée dans ladite application lors d'un accès effectué sur ledit site de régie.
5- Procédé selon l'une des revendications 1 à 4, pour lequel ladite application est du type JAVA caractérisé en ce que l'étape d'insertion de l'identification d'en tête consiste à utiliser un système d'enregistrement, notamment RMS offert par les possibilités des applications JAVA.ii
6- Procédé de validation de messages selon l'une des revendication 1 à 5, caractérisé en ce que ladite identification est une chaîne connue sous le nom de User Agent .
7- Procédé selon l'une des revendications 1 à 3 destiné à un site de régie (9) associé à plusieurs sites annonceurs (10, 12) caractérisé en ce qu'il comporte une étape supplémentaire de transmission de validation de clic sur les sites clients (10, 12) impliqués
8- Système de transmission spécialement conçu pour la mise en oeuvre du procédé selon l'une des revendications 1 à 7, comprenant : - un terminal (1) doté d'un navigateur, - au moins un fournisseur d'applications (7), pour l'installation d'une application dans le terminal, - un site de régie (9) et - au moins un site annonceur (10, 12) caractérisé en ce qu'une identification d'en tête fournie par ledit navigateur est insérée dans ladite application pour être utilisée comme critère de validation lors d'une demande de connexion vers ledit site annonceur.
9- Site de régie spécialement conçu pour la mise en oeuvre du procédé selon l'une des revendications 1 à 7 proposant des zones à cliquer apparaissant au sein de ladite application, comportant un moyen pour enregistrer l'identification d'en tête provenant d'un terminal (1) et pour la retransmettre vers ledit terminal (1) au sein de ladite application.
10- Fournisseur d'applications spécialement conçu pour la mise en oeuvre du procédé selon l'une des revendications 1 à 7 caractérisé en ce qu'il comporte un moyen pour enregistrer l'identification d'en tête provenant d'un terminal et pour l'insérer dans 1' application.
11- Terminal pour un utilisateur spécialement conçu pour la mise en ouvre du procédé selon l'une des revendications 1 à 7 percevant au moins une des zones, caractérisé en ce qu'il comporte des moyens pour faire fonctionner le navigateur et l'application et des moyens de fourniture de l'identification d'en tête en vue de l'insertion dans ladite application.