WO2009150313A1 - Procédé de validation de messages destiné à un terminal de transmission, terminal de transmission, site de régie, système de transmission et fournisseur d'applications impliqués dans un tel procédé - Google Patents

Procédé de validation de messages destiné à un terminal de transmission, terminal de transmission, site de régie, système de transmission et fournisseur d'applications impliqués dans un tel procédé Download PDF

Info

Publication number
WO2009150313A1
WO2009150313A1 PCT/FR2009/000559 FR2009000559W WO2009150313A1 WO 2009150313 A1 WO2009150313 A1 WO 2009150313A1 FR 2009000559 W FR2009000559 W FR 2009000559W WO 2009150313 A1 WO2009150313 A1 WO 2009150313A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
terminal
identification
site
head
Prior art date
Application number
PCT/FR2009/000559
Other languages
English (en)
Inventor
Hervé HABABOU
Vidal Chriqui
Original Assignee
Hababou Herve
Vidal Chriqui
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hababou Herve, Vidal Chriqui filed Critical Hababou Herve
Publication of WO2009150313A1 publication Critical patent/WO2009150313A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user

Definitions

  • a message validation method for a transmission terminal, transmission terminal, control site, transmission system and application provider involved in such a method is a method for generating a transmission signal.
  • the present invention relates to a method for validating messages to be performed on messages appearing in screen areas of a transmission terminal, this method involving, in particular:
  • WAP network browser
  • JAVA provider of at least one application
  • a management site proposing at least one zone as part of said application to be displayed on said terminal
  • an identification at the head (AU) defining, among others, said transmission terminal, the method comprising the following steps:
  • the present invention relates to a transmission system involved by the method.
  • the present invention relates to a management site involved in said validation process.
  • the present invention also relates to a transmission terminal involved in said validation process.
  • the present invention also relates to an application provider involved in said validation process.
  • the main concern of the advertiser is to know the impact of its advertising on the public.
  • the number of clicks on his advertisement or the number of appearances of his advertisement is, therefore, a particularly important data for him.
  • the advertiser is also willing to pay for the sites, which display its ads, on the one hand, based on the number of appearances and also on the other hand, the number of clicks that users have made on his commercial.
  • the internet world has also extended to mobile phones which also provide access to Internet-type networks and which therefore offer the user banner ads that solicit the user.
  • IP address taken from a quota of addresses reserved for their operator. This number of addresses is rather limited, and an IP address can be used by other users. This criterion of the IP address can not be retained for mobile phones, among others.
  • Mobile phones use, a browser designed, most often, to treat the protocols of the Mobile Internet adapted to their possibilities including WAP ("Wireless Application Protocol"), Wi-fi or Wi-Max.
  • WAP Wireless Application Protocol
  • Wi-fi Wi-fi
  • Wi-Max Wi-Max
  • the server mentioning an advertiser's advertising will be paid by the advertiser.
  • the user will be identified, for a small part, by his address DP, not necessarily significant, as it has just been said, but especially by his UA ("User Agent” which includes various data concerning, including the brand of its mobile, type, model, version, etc. This is considered an acceptable criterion.
  • the invention proposes to solve this problem:
  • FIG 1 shows a system in which the method of the invention is implemented
  • FIG.2 shows a first diagram explaining the method of the invention
  • FIG.3 shows a second diagram explaining, in a variant, the method of the invention.
  • the system shown in Figure 1 comprises a mobile terminal 1 (such as a phone supporting the features of the Mobile Internet, a personal assistant, or well any other device capable of supporting this new technology) and being able to operate a mobile application.
  • This terminal must, in a first step, connect to a gateway 3, by radio which assigns an IP address required by the WEB network 5.
  • This IP address can also be assigned to other mobile terminals.
  • the mobile can thus have access to sites involved in the invention.
  • a first site is a JAVA 7 application site
  • another site is an advertising network site 9 which provides advertising banners intended to give a link to sites advertisers 10, 12 and others ...
  • JAVA applications that run on the terminal independently of the browser.
  • These applications may use an advertising network site 9 which provides addresses for commercial advertiser sites 10, 12, associated with advertising areas Publ, Pub2 appearing on screen 15 of the terminal 1 and the user is invited to click on it so as to display, on the screen of the terminal, an advertising message coming from the advertiser sites 10, 12.
  • This management site 9 collects various advertisements, including that of an advertiser 10, to be displayed on the screen 15 of the terminal 1. Once the user has clicked on an area assigned to the advertiser 10, it is up to the management site to mention to this advertiser 10, the action of the user.
  • a JAVA application When on the terminal, two applications operate concurrently, in the context of the example described, a JAVA application and the WAP browser, the application JAVA is unable to communicate appropriate identification information.
  • An example of a string of characters found in a UA is for example:
  • the terminal 1 with the two applications that work concomitantly: the application concerning the WAP browser and the application running in the JAVA environment, for example,
  • the StI installation step starts.
  • this site provides, for a requested JAVA application, the JAD descriptive file. Since this first request HR1 was made from the WAP browser, this request contains the UA header of the WAP browser which is considered to be a sufficiently precise element to define a user. This header is embedded in the JAD file which is indicated by JAD + UA in Figure 2.
  • JAD + UA we download the completed JAD file, describing the application. If the user, in view of the JAD file, is satisfied with the application, he makes a second request HR2 to cause the JAR download of the application. Step St2, which follows is his installation.
  • Step St3 shows the action of the user who triggers a request HR3 accompanied by the UA to the server of advertising agency 9 which, in return, provides the commercial ADV.
  • the JAVA application gives the PR hand to the WAP browser (step St4) which allows it to return to the site 9 (HR4 phase) and then it is possible to make a redirection RD to the site of the advertiser 10 (step St5 ).
  • FIG. 3 shows another embodiment.
  • the user uses a JAVA application or a server of such applications for which the measure of incorporating the AU into the JAD file has been provided.
  • This application can also be contained in the PC of the user whose mobile can be connected via the system known under the trade name "Bluetooth” or via an infrared system, or simply by a cable.
  • step STl 1 where from its WAP browser, the user makes a download request (DR phase) on a site T which is worth it in return for obtaining the JAD file of the application.
  • the download request can also be initiated from the PC in question.
  • the user requests the download of the IR application.
  • Step StI 2 which follows, is the INST installation of the application.
  • a link to a site 9 ' can be activated by a request HRl 1.
  • the site 9' provides an advertising banner ADV10 which may be of interest to the user.
  • start step Stl4 The user must use his WAP browser (PRlO phase).
  • PRlO phase As it sends a request from its WAP browser, it is accompanied by a descriptive UA and is directed to the site 9 '(HRl phase 2). Then follows the phase of AU storage at the site 9 '.
  • This UA is then stored St (UA) at the site 9 'which redirects the request RD 10 to the advertiser site 5.
  • the user wants to reconnect to the advertising site, he makes a request HRl 3 from its application JAVA but this time, it is accompanied by the AU.
  • the advertising message ADVl 1 is then sent to the user thus providing other links on which the user is invited to click. For this, we switch to the WAP browser (PR12 phase) which performs this connection accompanied of course the descriptive UA (HR14 phase).
  • the management site 9 redirects to the advertiser concerned this request (phase RDI 1).
  • log log which shows the accesses on the advertising zones with opposite identifiers.
  • AU transmitted in accordance with the invention thus validates the perception of advertising and also good or bad clicks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé de validation de messages impliquant : un navigateur de réseaux (WAP); un fournisseur (7) d'une application (JAVA); un site de régie (9) proposant une zone (Pub1), (Pub2) dans le cadre de ladite application à être visualisé sur un terminal de transmission (1); une identification d'en tête (UA) définissant ledit terminal. Selon l'invention, le procédé comporte les étapes suivantes : requête de demande d'application (HR1) sur un fournisseur d'applications choisi par l'utilisateur; 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

Procédé de validation de messages destiné à un terminal de transmission, terminal de transmission, site de régie, système de transmission et fournisseur d'applications impliqués dans un tel procédé.
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 (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é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,
- 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 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.
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 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'apparition et/ou le nombre de clics ne soit pas faussé par des manœuvres 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 l'« 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 la répétition inopportune 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 Ia 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 DP, 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 connue 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é à 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, 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 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ées à 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 ré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. H 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 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. 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 (Application 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 terminal 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 StI d'installation démarre. Après la première requête HRl faite auprès du serveur d'applications 7, ce site fournit, pour une application JAVA demandée, Ie fichier descriptif JAD. Comme cette première requête HRl 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.l). 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 Ia dénomination commerciale « Bluetooth » ou via un système par infrarouge, ou alors tout simplement par un câble. Ceci est effectué dans l'étape STl 1 où depuis son navigateur WAP, l'utilisateur effectue une demande de téléchargement (phase DR) sur un site T 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 StI 2, 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 HRl 1. En retour le site 9' fournit une bannière publicitaire ADV10 qui peut intéresser l'utilisateur. Si l'utilisateur veut accéder à des informations que lui propose la bannière, commence, alors, l'étape Stl4. L'utilisateur doit faire appel à son navigateur WAP (phase PRlO). 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 HRl 2). 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 St 15. 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.JA VA-tips.org^JAVA-me-tips/midp/an-example-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 publicitaire, il effectue une requête HRl 3 depuis son application JAVA mais cette fois-ci, elle est accompagnée de l'UA. Le message publicitaire ADVl 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 HR14). Le site de régie 9' redirige vers l'annonceur concerné cette requête (phase RDI 1).
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 1 'UA et même de l 'adapter au type de la machine que l 'utilisateur possède.

Claims

REVENDICATIONS.
1- 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, notamment :
- 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é 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. 6- Procédé de validation de 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 dans lequel le procédé de validation de l'une des revendications 1 à 7 est mis en application, 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 proposant des zones à cliquer apparaissant au sein de ladite application adapté au procédé selon l'une des revendications 1 à 4, 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 adapté au procédé selon l'une des revendications 1 à 4 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.
11- Terminal pour un utilisateur percevant des zones en conformité selon Ie procédé de l'une des revendications 1 à 4, 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.
PCT/FR2009/000559 2008-05-20 2009-05-14 Procédé de validation de messages destiné à un terminal de transmission, terminal de transmission, site de régie, système de transmission et fournisseur d'applications impliqués dans un tel procédé WO2009150313A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0802723 2008-05-20
FR0802723A FR2931572A1 (fr) 2008-05-20 2008-05-20 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

Publications (1)

Publication Number Publication Date
WO2009150313A1 true WO2009150313A1 (fr) 2009-12-17

Family

ID=40202082

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/000559 WO2009150313A1 (fr) 2008-05-20 2009-05-14 Procédé de validation de messages destiné à un terminal de transmission, terminal de transmission, site de régie, système de transmission et fournisseur d'applications impliqués dans un tel procédé

Country Status (2)

Country Link
FR (1) FR2931572A1 (fr)
WO (1) WO2009150313A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020007393A1 (en) * 2000-05-18 2002-01-17 Hamel Lawrence Arthur System and method for implementing click-through for browser executed software including ad proxy and proxy cookie caching
JP2003296228A (ja) * 2002-03-29 2003-10-17 Gigaflops Japan Inc 主コンテンツに加えて広告表示機能を付帯させたｊａｖａアプレット
WO2007087251A2 (fr) * 2006-01-25 2007-08-02 Greystripe, Inc. Systeme et procede pour gerer un contenu dans des applications mobiles preexistantes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020007393A1 (en) * 2000-05-18 2002-01-17 Hamel Lawrence Arthur System and method for implementing click-through for browser executed software including ad proxy and proxy cookie caching
JP2003296228A (ja) * 2002-03-29 2003-10-17 Gigaflops Japan Inc 主コンテンツに加えて広告表示機能を付帯させたｊａｖａアプレット
WO2007087251A2 (fr) * 2006-01-25 2007-08-02 Greystripe, Inc. Systeme et procede pour gerer un contenu dans des applications mobiles preexistantes

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BLECHSCHMIDT T ET AL: "Personalization of End User Software on Mobile Devices", MOBILE COMMERCE AND SERVICES, 2005. WMCS '05. THE SECOND IEEE INTERNAT IONAL WORKSHOP ON MUNICH, GERMANY 19-19 JULY 2005, PISCATAWAY, NJ, USA,IEEE, 19 July 2005 (2005-07-19), pages 130 - 137, XP010883191 *
KRIKKE J: "Samurai romanesque, J2ME, and the battle for mobile cyberspace", IEEE COMPUTER GRAPHICS AND APPLICATIONS, IEEE SERVICE CENTER, NEW YORK, NY, US, vol. 23, no. 1, 1 January 2003 (2003-01-01), pages 16 - 23, XP011095445, ISSN: 0272-1716 *

Also Published As

Publication number Publication date
FR2931572A1 (fr) 2009-11-27

Similar Documents

Publication Publication Date Title
CN102301658B (zh) 广告投放方法、广告服务器和广告系统
EP1473904B1 (fr) Procédé et système d'accès à un réseau poste à poste
US8694377B2 (en) Method and apparatus for presenting advertisements
EP2179368B1 (fr) Procédé et appareil de surveillance internet par partie tierce au moyen d'outils de surveillance.
EP1763195B1 (fr) Système et procédé de diffusion de contenus personnalisés et éventuellent interactifs à destination de terminaux rattachés à un réseau de communication
US20090157504A1 (en) System and method for advertising to a target demographic of internet users
US20030080997A1 (en) Anonymous network-access method and client
GB2502872A (en) Targeting advertising
CN103269479A (zh) 一种话单处理方法、装置和系统
EP1376410A1 (fr) Procédé de gestion d'informations de contexte par serveur intermédiaire
JP2005108236A (ja) サービスのダイナミック・ネットワークのオンデマンド割当てのための方法およびシステム
CN103139720B (zh) 一种减少手机广告网络流量的处理方法及系统
FR2908212A1 (fr) Applications pour le profilage d'utilisateurs de services de telecommunications
EP1380149B1 (fr) Dispositif de generation d'un fichier multimedia a destination d'un terminal de telecommunications et fichier multimedia associe
US20060159068A1 (en) Supporting service requests during media data transfer
EP2513788A1 (fr) Pre-chargement de contenu entre un serveur de contenu et au moins un terminal
WO2009150313A1 (fr) Procédé de validation de messages destiné à un terminal de transmission, terminal de transmission, site de régie, système de transmission et fournisseur d'applications impliqués dans un tel procédé
EP1625723A1 (fr) Systeme de gestion de contexte pour un reseau comportant un essemble heterogene de terminaux
US20030169718A1 (en) System for returning rates back to content providers, gateway used for the system, and method of doing the same
EP1479212A1 (fr) Dispositif et procede d intermediation entre fournisseurs de services et leur utilisateurs
EP2105854A1 (fr) Procédé de détermination de données complémentaires relatives à au moins un contenu, procédé pour transmettre ces données complémentaires, dispositif de traitement et serveur d'applications associés
EP1430736A1 (fr) Systeme et procede de gestion d'acces d'un terminal mobile a un reseau de communication
WO2006061496A1 (fr) Terminal, systeme et procede de gestion des ressources necessaires a la restitution d'une page web
EP1626355A1 (fr) Procédé d'affichage d'une carte et d'accès à des ressources d'information relatives aux endroits figurant sur cette carte
EP1494419B1 (fr) Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09761864

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09761864

Country of ref document: EP

Kind code of ref document: A1