FR2839569A1 - Systeme, procede, ordinateur et outil de gestion d'encheres, et support informatique d'un tel outil - Google Patents

Abstract

L'invention concerne la gestion d'enchères. Elle se rapporte à un système qui permet à un promoteur d'un site commercial (14) de la toile (20) de remettre à jour des informations relatives à un listage de recherche dans une liste de résultats de recherche créée par un moteur de recherche sur Internet. Un système d'ordinateur (22) a une base de données (38) contenant des enregistrements de compte et des listages de recherche qui comprennent un terme de recherche à mot-clé, une enchère modifiable, une adresse URL, une description, et un titre, un solde de compte, et des codes de programmation en langage extensible à balises (XML) permettant l'addition d'un listage de recherche, le traitement de requêtes de recherche, et la création d'une liste de résultats de recherche.Application aux services de recherche sur Internet.

Description

<Desc/Clms Page number 1>

La présente invention concerne de façon générale le domaine de la recherche dans les bases de données. Plus précisément, elle concerne l'utilisation d'un langage extensible à balises dans un système et un procédé qui ont une influence sur la position dans une liste de résultats de recherche créée par un moteur de recherche d'un réseau d'ordinateurs.

Le brevet des Etats-Unis d'Amérique n 6 269 361 décrit un système et un procédé qui ont une influence sur la position dans une liste de résultats de recherche créée par un moteur de recherche d'un réseau d'ordinateurs. Dans un mode de réalisation décrit, le système et le procédé constituent un outil de gestion de comptes d'annonceur en ligne.

Des listages de recherche associés aux annonceurs sont conservés dans une base de données. Chaque listage de recherche a un terme associé de recherche et une enchère spécifiée par l'annonceur. A la suite d'une requête de recherche saisie par un utilisateur, des listages de recherche ayant des termes correspondants à la recherche sont affichés dans une liste de résultats de recherche. Les listages de recherche sont ordonnés de l'enchère la plus élevée à la plus basse, et peuvent être suivis de listages non payés dans la liste des résultats. L'enchère est une somme débitée du compte de l'annonceur lorsqu'un utilisateur clique sur un listage de recherche de la liste de résultats de recherche.

En outre, dans un mode de réalisation décrit dans ce brevet, des annonceurs ont un accès authentifié avec l'enregistrement en ligne pour l'obtention d'informations sur leurs comptes et pour la modification des listages de recherche. Des exemples d'actions des annonceurs sont l'observation des transactions passées, des options de notification de sélection, l'addition d'argent au compte de l'annonceur qui sélectionne une option correspondante, le changement d'une enchère ou d'un autre élément d'une liste de recherche, la création ou la suppression de listages de recherche, la réception d'une prévision de coût pour l'exécution d'un listage de recherche pendant un temps spécifié

<Desc/Clms Page number 2>

ou l'obtention de rapports d'activité. L'aptitude des annonceurs à changer leurs enchères provoque un classement dynamique tel que la position d'un listage de recherche dans une liste de résultats peut être modifiée par augmentation ou réduction de l'enchère associée, ou parce que d'autres listages de recherche ont changé de position.

Le système décrit définit ainsi un marché en ligne géré par un opérateur de marché au bénéfice des annonceurs et clients potentiels des annonceurs. Le marché est utilisé comme source d'informations par les clients potentiels et comme source de nouveaux clients par les annonceurs. Le marché est très concurrentiel en ce que les annonceurs sont en compétition pour attirer l'attention des clients potentiels par ajustement des enchères de leur listage de recherche afin que leur position sur une liste de résultats de recherche créée par le moteur de recherche soit influencée en réponse à une requête de recherche d'un client. Un exemple d'un tel marché en ligne est mis en oeuvre par Overture Systems, Inc, et est accessible sur Internet au site www.overture.com.

Le système breveté a été très satisfaisant pour les annonceurs voulant atteindre de nouveaux clients et pour les clients potentiels voulant avoir plus d'informations sur les produits des annonceurs. En fait, le système breveté a été si satisfaisant que de nombreux annonceurs ont placé un grand nombre de listages de recherche sur le marché en ligne et utilisent des gestionnaires à plein temps pour gérer leurs listages de recherche. Des fournisseurs tiers ont développé des outils qui simplifient l'accès aux listages de recherche sur le marché en ligne pour les annonceurs. Le cadre d'une certaine participation des annonceurs au marché a créé un besoin d'automatisation de la gestion des enchères par les annonceurs ou pour eux.

La demande de brevet des Etats-Unis d'Amérique n 09/922 028 déposée le 3 août 2001, cédée à la demanderesse et ayant le titre "System and Method For Providing Place and Price Protection In a Search Result List Generated By a Computer Network Search Engine", propose d'autoriser

<Desc/Clms Page number 3>

les annonceurs à fixer un coût maximal par clic (CPC) et/ou un rang voulu dans les résultats de recherche. Des listages de recherche de rang supérieur sont affichés plus tôt pour une personne qui recherche dans un ensemble de résultats de recherche et on suppose qu'un rang plus élevé est mieux pris en considération par les clients potentiels et est donc plus souhaitable. Le système ajuste le coût CPC d'un listage de recherche pour que celui-ci soit maintenu au rang voulu, lorsque ceci peut être réalisé sans dépassement de l'enchère ou du coût maximal CPC. Si le listage ne peut pas garder le rang voulu sans dépasser l'enchère, le système obtient le rang le plus élevé suivant que permet l'enchère.

En outre, la demande de brevet des Etats-Unis d'Amérique n 09/963 855 déposée le 26 septembre 2001 sous le titre "Automatic Advertiser Notification for a System and Method For Providing Place and Price Protection In a Search Result List Generated By a Computer Network Search Engine" par la demanderesse, propose l'utilisation d'un agent automatisé qui agit pour l'annonceur afin de contrôler les conditions spécifiées par l'annonceur. Lorsqu'une condition quelconque est remplie ou apparaît, un message est communiqué à l'annonceur avec un moyen pour l'annonceur de corriger la condition indésirable. Par exemple, si l'agent détermine que le rang d'un listage de recherche est tombé au-dessous d'un seuil, un message électronique peut être transmis à l'annonceur avec une possibilité de renvoi d'un message électronique au système pour spécifier comment la condition relative au rang doit être corrigée.

Bien que ces caractéristiques présentent une meilleure commodité pour les annonceurs qui veulent gérer les listages de recherche, elles n'ont qu'un succès limité pour aider l'annonceur qui doit gérer un grand nombre de listages de recherche ou pour un tiers qui veut publier des listages de recherche pour plusieurs annonceurs. Ainsi, un système et un procédé perfectionnés destinés à influencer la position dans une liste de résultats de recherche créée par un moteur de recherche de réseau d'ordinateur sont nécessaires.

<Desc/Clms Page number 4>

A titre d'introduction, on considère un mode de réalisation d'appareil et d'exécution de procédé de recherche de base de données destinés à créer une liste de résultats de recherche qui répond à des requêtes en langage extensible à balises XML provenant d'un client. Le langage XML constitue un moyen souple de création de formats communs d'informations et partage à la fois le modèle structurel et les données dans un réseau local ou distribué, par exemple Internet, des réseaux d'entreprises intranets et ailleurs. Le langage XML est une recommandation formelle de World Wide Web Consortium et est analogue au langage à balises à hypertexte HTML utilisé pour les anciennes pages de la toile (web). Le langage XML est une méta-syntaxe destinée à désigner des modèles de syntaxe qui permettent de structurer les données. XML et HTML sont des langages qui ont des symboles de balises pour décrire le contenu d'une page ou d'un fichier. Cependant, le langage HTML décrit le contenu d'une page de la toile uniquement par la manière dont elle doit être affichée et doit interagir. Le langage XML décrit le contenu en termes indiquant quelles données sont décrites et comment elles sont liées aux autres structures de données du modèle. Les langages HTML et XML utilisent tous deux des balises qui sont des mots séparés par <> et des attributs.

Le langage HTML spécifie un ensemble fini de balises et de significations ou utilisations pour chaque balise, c'est-àdire définit la signification de chaque balise et de chaque attribut. Le langage XML utilise des balises, mais il est extensible car, contrairement au langage HTML, les balises sont illimitées et se définissent elles-mêmes.

Un autre mode de réalisation actuel est un outil de gestion d'enchères destiné à fonctionner sur un ordinateur client pour la gestion de listages de recherche et d'informations de compte d'un ou plusieurs annonceurs. L'outil de gestion d'enchères est de préférence une application de bureau qui donne des rapports et gère des listages payés sur un serveur d'un marché en ligne. L'application cliente communique avec le serveur par une interface formée d'un programme d'application à base XML. L'outil de gestion

<Desc/Clms Page number 5>

d'enchères a des fonctions de rapport de l'activité des comptes, de modification des comptes et de changement manuel, synchronisé ou piloté par événement des listages de recherche.

D'autres caractéristiques et avantages de l'invention seront mieux compris à la lecture de la description qui va suivre d'exemples de réalisation, faite en référence aux dessins annexés sur lesquels : la figure 1 est un diagramme synoptique illustrant la relation entre un réseau de grande étendue et un mode d'exécution de système et de procédé de création d'un résultat de recherche à paiement à la place ; la figure 2 représente les éléments fonctionnels d'un outil de gestion d'enchères qui peut être exploité avec un ordinateur client du système de la figure 1 ; la figure 3 est un schéma des données d'enregistrement de comptes destinées à être utilisées dans un mode d'exécution du système et du procédé selon l'invention ; et la figure 4 représente un exemple de liste de résultats de recherche créée dans un mode d'exécution par le système et le procédé selon l'invention.

On se réfère maintenant aux dessins ; la figure 1 représente un exemple de système distribué 10 ayant une configuration d'architecture client-serveur utilisée dans un mode d'exécution de l'invention. Un client est un organe d'une classe ou d'un groupe qui utilise les services d'une autre classe ou d'un autre groupe auquel il est lié. Dans le contexte d'un réseau d'ordinateurs tels que Internet, un client est un processus tel qu'un programme ou une tâche qui lance une requête de service donné par un autre processus, connu sous le nom de programme serveur. Le processus client utilise le service demandé sans avoir à connaître les détails de fonctionnement relatifs au programme serveur ou au serveur lui-même. Dans les systèmes en réseau, un processus client est exploité habituellement sur un ordinateur qui a accès aux ressources partagées du réseau données par un autre ordinateur exploitant un processeur serveur correspondant. Cependant, il faut aussi noter que le processus client

<Desc/Clms Page number 6>

et le processus serveur peuvent être exécutés sur le même ordinateur.

Un serveur est par exemple un système d'ordinateurs distant accessible par un support de communication tel que Internet. Le processus client peut être actif sur un second système d'ordinateurs et peut communiquer avec le processeur serveur par un support de communication qui permet à plusieurs clients de tirer avantage des possibilités de regroupement d'informations du serveur. Le serveur agit donc essentiellement comme un fournisseur d'informations pour un réseau d'ordinateurs.

Le diagramme synoptique de la figure 1 représente donc un système distribué 10 qui comprend plusieurs ordinateurs clients 12, plusieurs serveurs de toile (web) d'annonceur 14, un serveur 22 de gestion de comptes, et un serveur de toile 24 à moteur de recherche, qui sont tous connectés à un réseau 20. Le réseau 20 est appelé dans la suite Internet.

Bien que le système et le procédé selon l'invention soient utiles spécifiquement pour Internet, il faut comprendre que les ordinateurs clients 12, les serveurs de toile 14 d'annonceur, le serveur 22 de gestion de comptes et le serveur 24 de toile de moteur de recherche peuvent être connectés par un ou plusieurs réseaux de types différents.

Ces réseaux peuvent être des réseaux locaux LAN, des réseaux étendus WAN et des réseaux régionaux atteints par des lignes téléphoniques, par exemple des services d'informations commerciales. Les processus client et serveur peuvent même comporter des programmes différents exécutés simultanément sur un même ordinateur.

Les ordinateurs clients 12 peuvent être des ordinateurs personnels classiques, des postes de travail ou des systèmes d'ordinateurs de toute autre dimension. Chaque client 12 comporte par exemple un ou plusieurs processeurs, des mémoires, des dispositifs d'entrée-sortie et une interface de réseau, par exemple un modem classique ou une carte d'interface avec le réseau. Les serveurs 14 de toile d'annonceur, le serveur 22 de gestion de comptes et le serveur 24 de toile de moteur de recherche peuvent avoir une

<Desc/Clms Page number 7>

configuration semblable. Cependant, les serveurs 14 de toile d'annonceur, le serveur 22 de gestion de comptes et le serveur 24 de toile de moteur de recherche peuvent comprendre chacun de nombreux ordinateurs connectés par un réseau privé séparé. En fait, le réseau 20 peut comprendre des centaines de milliers de réseaux individuels d'ordinateurs.

Des ordinateurs clients 12 peuvent exécuter des programmes 16 de navigation sur la toile, tels que les programmes de navigation "Netscape Navigator", "Microsoft Internet Explorer" ou "Mosaic", pour localiser les enregistrements ou pages 30 de la toile conservés sur le serveur 14 de l'annonceur. Les programmes 16 de navigateur permettent aux utilisateurs de saisir les adresses de pages spécifiques 30 de la toile qui doivent être récupérées. Ces adresses sont appelées adresses de localisation uniformes de ressource URL. En outre, lorsqu'une page a été récupérée, les programmes de navigation 16 peuvent donner accès à d'autres pages ou enregistrements lorsque l'utilisateur clique sur des hyperliens vers d'autres pages de la toile. Ces hyperliens sont placés dans les pages 30 de la toile et constituent un moyen automatique pour l'utilisateur de passer à l'adresse URL d'une autre page et de récupérer cette page. Les pages peuvent être des enregistrements de données qui comprennent des informations sous forme de textes ordinaires ou un contenu multimédia codé numériquement plus complexe, tel que des logiciels, des graphiques, des signaux d'audiofréquences, des séquences vidéo, etc.

Les ordinateurs clients 12 du mode de réalisation représenté comportent un outil 100 de gestion d'enchères. On décrit plus en détail dans la suite la mise en oeuvre de l'outil 100 de gestion d'enchères en référence à la figure 2.

Dans un premier mode de réalisation, les ordinateurs clients 12 exploitent chacun une interface XML 15. L'interface XML 15 comporte un code de programme ayant une configuration permettant la communication avec une interface XML complémentaire 17 du serveur 22 de gestion de comptes

<Desc/Clms Page number 8>

suivant un schéma XML établi, compris par les utilisateurs de logiciels clients et l'opérateur du marché en ligne. Des exemples de tels schémas sont indiqués dans les annexes C et D mais il faut noter que ces schémas ne sont que des exemples et ne limitent aucunement les schémas disponibles pour la mise en oeuvre de l'invention. Comme décrit dans la suite, le serveur 22 de gestion de comptes mémorise les informations relatives au compte de chaque annonceur. Les ordinateurs clients 12 peuvent avoir accès à ces informations et peuvent la remettre à jour avec l'interface XML 15 en communication avec l'interface XML 17 du serveur 22 de gestion de comptes. Un ordinateur client peut être exploité par un annonceur qui gère les listages de recherche d'annonceur. Dans une variante, l'ordinateur client peut être utilisé par un tiers qui gère les listages d'un ou plusieurs annonceurs. Dans ce mode de réalisation, les ordinateurs clients 12 n'interagissent pas avec le serveur 22 de gestion de comptes avec un programme de navigation mais plutôt avec l'interface XML 15. Un individu exploitant un ordinateur client 12 peut activer un programme de navigation, mais la communication réelle des données est commandée par l'interface XML 15.

Dans un mode de réalisation de l'invention illustré sur la figure 1, les ordinateurs clients 12 communiquent par le réseau 20 avec divers fournisseurs d'informations du réseau, y compris le serveur 22 de gestion de comptes, le serveur 24 à moteur de recherche et des serveurs 14 d'annonceur, avec les fonctionnalités données par le protocole de transfert d'hypertexte HTTP, bien que d'autres protocoles de communication, tels que FTP, SNMP, TELNET et un certain nombre d'autres connus puissent être utilisés. De préférence, le serveur 24 de moteur de recherche, le serveur 22 de gestion de compte et les serveurs 14 d'annonceur sont placés dans le réseau Internet ou accessibles par ce réseau.

Comme décrit précédemment, deux types de serveurs au moins sont mis en oeuvre dans un mode d'exécution du système et du procédé selon l'invention. Le premier serveur envisagé est le serveur 22 de gestion de comptes. Ce serveur 22

<Desc/Clms Page number 9>

comporte un support 32 de mémorisation d'ordinateur et un système 34 de traitement. Ce serveur 22 comprend aussi toute une variété de codes de programme, y compris l'interface XML 17. Ces codes de programme sont mémorisés sur un ou plusieurs supports de mémorisation de programme lisibles par ordinateur du serveur 22, par exemple le support de mémorisation 32.

Une base de données 38 est aussi conservée sur le support de mémorisation 32 du serveur 22 de gestion de comptes. La base de données 38 contient des informations de compte d'annonceur. Des informations de compte conservées dans la base de données 38 comprennent des informations relatives aux listages de recherche de chaque annonceur participant au marché en ligne établi par le système distribué 10. Ces informations comprennent des termes de recherche, des enchères, des titres et descriptions de listages de recherche et des adresses URL associées ainsi que d'autres informations comme décrit dans la suite plus en détail. En outre, des informations de compte comprennent des informations produites par le fonctionnement du système de marché, par exemple le rang actuel et l'enchère actuelle de chaque listage de recherche, le nombre de clics enregistrés pour les listages de recherche, une fréquence calculée de clics (CTR) et le solde du compte de l'annonceur.

Il faut noter d'après la description qui suit que le système et le procédé considéré peuvent être exploités avec un ou plusieurs codes de programme qui sont mémorisés sous forme d'instructions exécutables sur un support d'enregistrement d'ordinateur, tel que des mémoires ou des dispositifs de mémorisation de masse, sur le serveur 22 de gestion de comptes. L'interface XML 15 ou un programme classique de navigation 16 exécuté sur les ordinateurs clients 12 peuvent être utilisés pour l'accès aux informations de compte d'annonceur conservées sur le serveur 22. De préférence, l'accès au serveur 22 est réalisé à travers un pare-feu, non représenté, qui protège le programmes de gestion de compte et de mise en place des résultats de la recherche ainsi que les informations de compte contre la

<Desc/Clms Page number 10>

falsification depuis l'extérieur. Une sécurité supplémentaire peut être donnée par renforcement des protocoles classiques de communication, tels que "Secure HTTP" ou "Secure Sockets Layer".

Le second type de serveur envisagé est un serveur 24 de toile de moteur de recherche. Un programme de moteur de recherche permet aux utilisateurs du réseau, par navigation à l'adresse URL d'un serveur de toile à moteur de recherche ou à des sites d'autres serveurs de toile qui peuvent soumettre des requêtes aux serveurs 24 de toile à moteur de recherche par l'intermédiaire de leur navigateur 16, de saisir des requêtes à mots-clés pour identifier des pages intéressantes parmi les milliards de pages disponibles sur Internet. Dans un mode de réalisation préféré de l'inven- tion, le serveur 24 de toile à moteur de recherche crée une liste de résultats de recherche qui contient au moins en partie des inscriptions concernées obtenues et formatées à l'aide des résultats du processus d'enchères exécuté par le serveur 22 de gestion de comptes. Le serveur 24 de toile à moteur de recherche crée une liste de liens hypertextes vers des documents contenant l'information concernant les termes de recherche saisis par l'utilisateur sur l'ordinateur 12 du client. Le serveur 24 de toile à moteur de recherche transmet cette liste sous forme d'une page web à l'utilisateur du réseau et elle est affichée sur le navigateur 16 exécuté sur l'ordinateur client 12. Un exemple de serveur de toile 24 à moteur de recherche peut être trouvé par navigation à la page de toile à l'adresse URL http://www.overture.com/.

Le serveur 24 de toile à moteur de recherche est connecté au réseau Internet 20. Dans un mode de réalisation, ce serveur 24 comporte une base de données 40 de recherche qui comprend des enregistrements de listage de recherche utilisés pour la création des résultats de recherche en fonction des requêtes des utilisateurs. En outre, le serveur 24 peut aussi être connecté au serveur 22 de gestion de comptes. Ce serveur 22 peut aussi être connecté à Internet.

Les serveurs 24 et 22 selon l'invention correspondent à des

<Desc/Clms Page number 11>

besoins différents d'informations des utilisateurs exploitant les ordinateurs clients 12.

Par exemple, une première catégorie d'utilisateurs exploitant des ordinateurs clients 12 peut être constituée de fournisseurs d'informations de réseau tels que les promoteurs ou propriétaires de sites de toile de type commercial ayant des pages 30 de toile d'annonceur placées sur des serveurs 14 de toile d'annonceur. Ces promoteurs ou annonceurs peuvent vouloir avoir accès aux informations de compte se trouvant dans la mémoire 32 du serveur 22 de gestion de comptes. Un promoteur de site commercial de la toile, à l'aide du compte se trouvant sur le serveur 22, peut participer à une opération de mise aux enchères avec d'autres annonceurs. Un annonceur peut présenter une enchère pour un nombre quelconque de termes de recherche concernant le contenu de son site de toile. Dans un mode de réalisation de l'invention, la pertinence d'un terme de recherche enchéri pour un site de toile d'un annonceur est déterminée par un processus éditorial manuel avant l'insertion du listage de recherche contenant le terme de recherche et l'adresse URL du site de l'annonceur dans la base de données 40. Dans un autre mode d'exécution de l'invention, la pertinence d'un terme de recherche enchéri dans un listage de recherche pour le site de toile correspondant peut être évaluée par un programme d'ordinateur exécuté au processeur 34 du serveur 22 de gestion de comptes dans lequel le programme évalue le terme de recherche et le site correspondant de toile en fonction d'un ensemble de règles éditoriales préalablement définies.

Les enchères les plus élevées reçoivent un positionnement plus avantageux sur la page de la liste des résultats de recherche créée par le moteur de recherche 24 lorsqu'une recherche utilisant l'enchère pour le terme de recherche défini par l'annonceur est exécutée. En général, l'enchère pour un terme de recherche a n'importe quelle valeur économique donnée par l'annonceur et associée au terme de recherche pour l'apparition d'un événement convenablement accepté. Par exemple, dans un schéma de paiement à

<Desc/Clms Page number 12>

l'affichage, l'annonceur donne une valeur économique lorsque le listage de recherche de l'annonceur est présenté dans les résultats de recherche transmis à l'annonceur, que l'annonceur clique sur le listage de recherche ou non. Dans un autre schéma, l'annonceur donne une valeur économique lorsqu'une personne voit le listage de l'annonceur, clique sur le listage et exécute une action supplémentaire, par exemple l'enregistrement du site de l'annonceur ou la transmission d'un numéro de carte de crédit, etc. La valeur économique peut avoir toute forme commode et qui rencontre un accord mutuel, par exemple une somme déduite d'un compte, des points ou d'autres éléments de comptage ajoutés ou soustraits d'un compte ou d'un relevé de l'annonceur, etc.

Dans un mode de réalisation, l'enchère d'un annonceur est une somme monétaire déduite de son compte chaque fois que le site de la toile de l'annonceur est atteint par un hyperlien de la page de la liste de résultats de recherche ou soumis à un clic. Une personne qui recherche clique l'hyperlien avec un dispositif de saisie d'ordinateur pour déclencher une requête de récupération de l'information associée à l'hyperlien de l'annonceur. De préférence, chaque clic ou accès à l'hyperlien d'un liste de résultats de recherche est redirigé vers le serveur 24 de toile à moteur de recherche pour l'association du clic à l'identificateur de compte d'un annonceur. Cette action de redirection, qui n'apparaît pas pour la personne effectuant la recherche, donne accès aux informations d'identification de compte codées dans une page de résultats de recherche avant l'accès à l'adresse URL de l'annonceur dont l'hyperlien a été cliqué par la personne sur la liste de résultats de recherche. Les informations d'identification de compte sont enregistrées dans le compte de l'annonceur avec des informations provenant de la requête de récupération sous forme d'un événement de requête de récupération. Comme les informations obtenues par ce mécanisme correspondent de façon concluante à un identificateur de compte pour une adresse URL d'une manière qui n' est pas possible avec les relevés des systèmes serveurs classiques connus, des enregistrements précis des

<Desc/Clms Page number 13>

débits de compte sont conservés. De préférence, la description du site de toile de l'annonceur et l'hyperlien sur la page de la liste de résultats de recherche est accompagnée d'une indication du fait que le listage de l'annonceur est un listage payé. De préférence, chaque listage payé affiche une information de coût affiché pour l'annonceur qui est une somme correspondant au coût par clic payé par l'annonceur pour chaque référence au site de l'annonceur par l'intermédiaire de la liste de résultats de recherche.

Une seconde catégorie d'utilisateurs des ordinateurs clients 12 peut comprendre des personnes qui recherchent des informations spécifiques sur la toile. Ces personnes peuvent avoir accès, par leur navigateur 16, à une page 36 de toile de moteur de recherche résistant sur le serveur de toile 24.

Dans une variante, la communication peut être réalisée par l'interface XML de l'ordinateur client. La page 36 de toile du moteur de recherche comprend une boîte de requête dans laquelle une personne peut indiquer un terme de recherche comprenant un ou plusieurs mots-clés. Dans une variante, la personne peut recourir au serveur 24 par une boîte de requête présentant un hyperlien sur le serveur 24 et placée sur une page de toile conservée par un serveur de toile distant. Lorsque la personne a fini de saisir le terme de recherche, elle peut transmettre la requête au serveur 24 par un clic sur un hyperlien indiqué. Le serveur 24 crée alors une page de liste de résultats de recherche et transmet cette page à la personne exploitant l'ordinateur client 12.

La personne peut alors cliquer sur les liens d'hypertexte associés à chaque listage de la page de résultats de recherche pour avoir accès aux pages correspondantes de toile. Les liens d'hypertexte peuvent donner accès à des pages de toile n'importe où sur Internet et comportent des listages payés relatifs aux pages 18 de l'annonceur placées sur des serveurs 14 d'annonceur. Dans un mode de réalisation préféré de l'invention, la liste de résultats de recherche comprend aussi des listages non payés placés non comme résultats d'enchères d'annonceur mais créée par un moteur de

<Desc/Clms Page number 14>

recherche classique Internet tel que "Inktomi", 'Lycos" ou "Yahoo!". Les liens hypertextes non payés peuvent aussi comprendre des liens indexés manuellement dans la base de données 40 par une équipe éditoriale. De préférence, les listages non payés suivent les listages payés d'annonceur sur la page de résultats de recherche.

La figure 2 représente les éléments fonctionnels d'un outil 100 de gestion d'enchères qui peut être exploité avec un ordinateur client 12 du système de la figure 1. L'outil 100 de gestion d'enchères du mode de réalisation représenté comporte plusieurs menus 102, une fonction 104 de mise en place, une fonction 106 de rapport, une fonction 108 de gestion de listage de recherche et une fonction d'aide 110.

L'outil 100 de gestion d'enchères coopère avec l' interface XML 15 (figure 1) pour les rapports et la gestion des listages payés de recherche sur le marché en ligne établi par le système distribué 10 décrit en référence à la figure 1. L'outil 100 est une application cliente qui communique avec des serveurs tels que le serveur 22 de gestion de comptes et le serveur 24 de toile à moteur de recherche (figure 1) par l'intermédiaire de l'interface XML 15 de l'ordinateur client 12. L'outil 100 a des fonctions de rapport d'activité de compte, de modification de compte et de changement d'enchères de façon manuelle, synchronisée ou pilotée par des événements. L'outil 100 de gestion d'enchères peut gérer les listages de recherche d'un annonceur ou de plusieurs annonceurs. Malgré le nom commodément utilisé, l'outil 100 de gestion d'enchères peut avoir une configuration lui permettant de gérer tous les aspects des comptes d'un ou plusieurs annonceurs sur le marché en ligne.

A l'aide des communications XML entre l'ordinateur client et un serveur, l'outil 100 établit un lien descendant du serveur vers le client et un lien ascendant du client vers le serveur. Le lien descendant transmet des informations relatives à l'état actuel du marché et au compte du client. L'état du marché comprend un ensemble de listages de recherche. Chaque listage, dans un mode de réalisation, a un rang actuel de listages de recherche d'annonceur parmi tous

<Desc/Clms Page number 15>

les listages de recherche du terme associé de recherche, une enchère actuelle, un titre, une description et une adresse URL. D'autres informations, telles qu'un rang voulu ou un coût par clic maximal peuvent aussi être transmises. Les informations de compte de client comprennent par exemple le nombre de clics récemment facturé à l'annonceur et le solde de son compte. D'autres informations de compte de client, par exemple la fréquence de clics (CTR) pendant une période spécifiée, peut aussi être transmise. Le lien montant communique les requêtes du client, par exemple une requête de changement d'en-tête ou une requête d'addition d'un ou plusieurs nouveaux listages de recherche pour des termes spécifiés de recherche au compte de l'annonceur.

L'outil 100 de gestion d'enchères peut avoir une conf i- guration lui permettant de fonctionner avec une programmation régulière. Par exemple, l'outil 100 peut interroger périodiquement le serveur de gestion de comptes distants, par exemple toutes les cinq minutes. Dans un autre exemple, l'outil 100 permet des remises à jour automatiques d'enchères suivant un programme prédéterminé, par exemple toutes les heures. L'utilisateur de l'ordinateur client peut aussi déclencher des remises à jour manuelles d'enchères.

L'outil 100 de gestion permet à un utilisateur de définir des groupes de termes de recherche. De tels termes peuvent être regroupés suivant n'importe quelles règles qui peuvent être établies par l'utilisateur. Les groupes de termes de recherche peuvent être liés à des services ou produits particuliers, à des annonceurs particuliers, au fait que des enchères de plus d'un seul annonceur sont gérées, ou à tout autre paramètre commode du marché. L'outil 100 permet en outre à un utilisateur de créer des rapports pour des groupes définis et de programmer des remises à jour automatiques pour tous les termes du groupe. Une remise à jour automatique peut ajuster l'enchère actuelle, le rang actuel voulu et tout autre paramètre de listage de recherche. Une seule instance de l'outil 100 permet à un utilisateur de gérer de multiples annonceurs, comptes et

<Desc/Clms Page number 16>

listages. Chaque annonceur peut avoir plusieurs comptes et chaque compte contient habituellement plusieurs listages.

L'outil 100 de gestion d'enchères mémorise localement les informations ou les mémorise sur un support de mémorisation de l'ordinateur client. Les informations mémorisées comprennent l'état du marché, le compte du client et les définitions de groupes. Des actions déclenchées par l'outil 100 de gestion d'enchères qui modifient l'état du marché, telles que les changements d'enchères, sont aussi mémorisées localement et peuvent être vues dans des rapports produits par l'outil 100.

L'outil 100 peut être exécuté de toutes manières convenables par un ordinateur client déterminé. Dans un mode de réalisation, l'outil 100 de gestion d'enchères comporte un ou plusieurs codes de programme lisibles par ordinateur conservés sur un dispositif de mémorisation, tel qu'un disque dur ou une mémoire de l'ordinateur client 12. L'ordinateur client comporte un processeur et une interface de communication. Le processeur travaille avec les codes de programme de l'outil de gestion d'enchères pour remplir les fonctions décrites dans le présent mémoire. Dans un mode de réalisation préféré, l'outil 100 est une application qui peut être installée sur un ordinateur personnel ou un autre dispositif de traitement utilisant une ou plusieurs versions de systèmes d'exploitation "Microsoft Windows". De préférence, l'outil 100 a une fonction de remise à jour automatique qui peut déclencher une session de communication avec un site de la toile pour déterminer si une nouvelle version de l'application est disponible par téléchargement. Si la réponse est positive, l'utilisateur peut recevoir un message lui demandant de déclencher le processus de téléchargement et de remise à jour, qui est alors exécuté automatiquement.

Sur la figure 2, l'outil 100 de gestion d'enchères comporte des menus 102 qui permettent l'interaction de l'utilisateur avec l'outil 100. De préférence, dans un ordinateur client exploitant le système d'exploitation "Windows", les menus 102 correspondent aux fonctionnalités et conventions des menus "Windows" afin que le

<Desc/Clms Page number 17>

fonctionnement soit simplifié pour l'utilisateur. Cependant, les menus 102 peuvent être personnalisés en fonction d'applications particulières de l'outil 100. Dans d'autres systèmes d'exploitation, d'autres systèmes de menus peuvent être utilisés.

Les menus 102 constituent une interface d'utilisateur pour la saisie de données et la sélection d'options. Un premier menu peut être atteint pour la définition des termes de recherche ou des comptes d'annonceur à gérer. Un autre menu peut être atteint pour spécifier le format d'un rapport. Un autre menu peut être atteint pour le déclenchement d'une opération. D'autres types de menus peuvent aussi être incorporés. Les menus interagissent avec d'autres données et applications conservées sur l'ordinateur du client ou accessibles à partir de celui-ci, telles que l'interface XML 15 (figure 1).

Chaque menu respectif comprend des champs ou sous-menus surgissant convenables de type connu pour la réception et l'enregistrement des données saisies par l'utilisateur. Les données peuvent être introduites au clavier ou saisies d'une autre manière dans des champs spécifiés ou sélectionnées parmi les options données par un menu surgissant. En outre, les menus peuvent donner des options permettant à l'utilisateur de spécifier simplement tous les comptes d'un annonceur particulier. Si les informations ne sont pas conservées localement, l'outil 100 de gestion d'enchères peut déclencher une requête demandant au serveur de gestion de comptes d'obtenir des informations d'identification de compte pour l'annonceur spécifié. Par exemple, l'outil 100 peut transmettre des informations d'identification de l'annonceur à l'interface XML de l'ordinateur client. L'interface XML lance une requête au format convenable et communique la requête au serveur de gestion de comptes. La réponse est ensuite reçue et mémorisée par l'interface XML et les données demandées sont transmises à l'outil 100 de gestion d'enchères.

La fonction 104 de mise en place de l'outil 100 a une fonctionnalité d'initialisation et de modification du

<Desc/Clms Page number 18>

fonctionnement de l'outil 100. Elle comprend la définition des annonceurs et des comptes associés à contrôler, par exemple, par réception d'un utilisateur d'un identificateur de texte d'un annonceur et de détermination du numéro de compte d'annonceur ou de réception et de mémorisation de plusieurs termes de recherche à contrôler.

La fonction de mise en place 104 permet en outre la définition de groupes de termes de recherche et d'annonceur qui peuvent être liés de toutes manières commodes. Un groupe est une collection de listages de recherche définie par l'utilisateur. Un groupe unique peut comprendre des listages de plusieurs comptes et annonceurs. Un listage peut apparaître dans plusieurs groupes. Dans un mode de réalisation, toutes les définitions de groupes sont mémorisées localement dans l'ordinateur client. Dans d'autres modes de réalisation, les définitions de groupes peuvent être conservées entièrement ou partiellement à un emplacement distant, par exemple dans le serveur de gestion de comptes du marché en ligne. Au point de vue du serveur de gestion de comptes, une transaction de groupe comprend une liste d'opérations sur les listages de recherche individuelle. Les contenus et paramètres de groupes peuvent être spécifiés avec un ou plusieurs des menus 102 ou peuvent être établis par importation d'un fichier texte dans l'outil 100 de gestion d'enchères à partir d'un autre emplacement.

La fonction 104 de mise en place permet en outre la spécification d'opérations d'interrogation destinée à être exécutées par l'outil 100. Des exemples comprennent une interrogation programmée dans le temps en fonction d'un programme prédéterminé ou après une période d'interrogation et une interrogation pilotée par événement lorsqu'un événement spécifié s'est produit. Les informations de mise en place qui sont transmises à la fonction de mise en place 104 sont obtenues en général avec un ou plusieurs menus 104. Les informations de mise en place peuvent aussi être obtenues à partir de la mémoire de l'ordinateur client ou par accès au serveur 24 de gestion de comptes à l'aide de l'interface XML 15 de l'ordinateur client (figure 1). De préférence, un mot

<Desc/Clms Page number 19>

de passe ou des informations analogues sont nécessaires pour obtenir l'accès aux informations de compte de l'annonceur.

En outre, comme noté précédemment, la fonction de mise en place 104 a une fonction automatique de changement de version. Cette caractéristique peut être omise ou inhibée, selon le souhait de l'utilisateur.

L'outil 100 de gestion d'enchères comporte en outre une fonction 106 de rapport. Cette fonction 106 prépare des rapports d'informations d'utilisation relatives aux annonceurs, aux comptes et aux listages gérés par l'outil 100.

Des exemples de formats de rapport sont des formats de tableau dans lesquels les données brutes sont présentées et des formats graphiques dans lesquels les données brutes ont été traitées pour donner une illustration plus facilement compréhensible de l'état du marché et des informations de compte de client. L'aspect et la création des rapports peuvent être commandés par le menus 102.

La fonction 106 de rapport dans un mode de réalisation permet aussi l'observation des relevés de données conservées par l'outil 100. Chaque fois qu'un changement d'enchère est demandé, manuellement par l'utilisateur ou de façon programmée par l'outil 100, un enregistrement est ajouté à un fichier de relevé. Ce fichier est conservé dans l'ordinateur du client ou à tout autre emplacement commode. L'écriture dans le relevé indique soit une exception, telle que l'impossibilité de la connexion au serveur ou le défaut d'authentification, soit des détails sur un changement satisfaisant d'enchères, avec l'annonceur, le compte, le terme, l'ancienne enchère, l'ancien rang, la nouvelle enchère et le nouveau rang. D'autres informations peuvent aussi être conservées. La fonction 106 de rapport permet l'observation des données de relevé ou des rapports préparés pour l'interprétation et la présentation des données du relevé.

L'outil 100 de gestion d'enchères comprend en outre une fonction 108 de gestion de listages de recherche. Cette fonction 108 exécute la fonction primaire de l'outil 100 qui est la gestion des listages de recherche et plus précisément

<Desc/Clms Page number 20>

l'exécution des changements d'enchères. Dans d'autres modes de réalisation, la fonction 108 de gestion de listages de recherche commande aussi d'autres transactions telles que l'addition et la suppression de listages.

La fonction 108 de gestion de listages de recherche exécute à la fois les changements manuels et automatiques d'enchères. Les changements manuels sont spécifiés par un utilisateur. Un changement manuel est demandé par identification du listage, du compte et de l'annonceur, ainsi que de la nouvelle enchère ou de l'autre paramètre de listage qui doit être changé. Ces informations peuvent être saisies avec les menus 102. La fonction 108 de gestion de listages de recherche répond au changement manuel par interaction avec l'interface XML 15 qui déclenche à son tour une requête transmise au serveur 22 de gestion de comptes (figure 1).

Après que le changement a été effectué, une confirmation est transmise du serveur au client. La confirmation est reçue par l'interface XML 11, enregistrée et une indication peut être donnée à l'utilisateur.

Grâce au changement automatique d'enchères, la fonction 108 de gestion de listages de recherche remet à jour les paramètres spécifiés de listages spécifiés de recherche d'annonceur spécifié. Les caractéristiques particulières de tout processus automatique d'enchères peuvent être établies avec les menus 102. Tout paramètre d'un listage de recherche peut être modifié, y compris l' enchère, le rang voulu, le titre du listage de recherche, etc. Des listages de recherche qui doivent être changés peuvent être spécifiés par spécification d'un identificateur de groupe lorsque le contenu du groupe a déjà été défini. La synchronisation ou les événements qui déclenchent une opération de changement d'enchères peuvent être spécifiés pour la commande du processus de changement automatique d'enchères.

Chaque application de la fonction de changement d'enchères met en oeuvre les opérations suivantes :
1) éveil (lancement) au temps de programmation (par exemple une fois par heure),

<Desc/Clms Page number 21>

2) voir si la copie locale des informations d'état du marché est à l'état actuel,
3) si la copie locale n'est pas à jour, remise à jour de la copie locale,
4) comparaison de l'état du marché à des règles spécifiées pour l'identification des changements nécessaires, et
5) transmission des changements au serveur et enregistrement du succès ou du défaut.

Un utilisateur peut aussi spécifier ses préférences pendant la journée ou le jour de la semaine auquel l'utilisateur souhaite payer plus par clic, par exemple à un certain moment de la journée ou certains jours de la semaine. La fonction de changement automatique d'enchères peut être exécutée afin que ses préférences soient indiquées automatiquement.

L'outil 100 de gestion d'enchères comprend aussi une fonction d'aide 110. Cette fonction 110 donne un accès en ligne commode à des informations de référence que l'utilisateur peut demander à l'outil 100. Des exemples d'informations qui peuvent être donnés sont la liste des questions souvent demandées (FAQ), un index de sujet d'aide, une fonction de recherche d'informations donnée par la fonction d'aide, et un sous-programme "à propos" qui indique la version et d'autres informations de l'outil 100 de gestion d'enchères.

Dans un mode de réalisation, le système décrit est placé sur un support de mémorisation lisible par ordinateur, tel qu'un disque CD-ROM, un disque dur, une mémoire ou un autre dispositif de mémorisation. Le support de mémorisation comprend un premier code de programme qui exécute l'outil de gestion d'enchères pour la gestion des listes de recherche sur un serveur de gestion de comptes d'un marché en ligne et un second code de programme qui exécute une interface en langage à balises extensibles XML pour la communication avec une interface XML complémentaire du marché en ligne. Les codes de programme peuvent être en code source, en code objet ou en tout autre format. L'outil de gestion d'enchères

<Desc/Clms Page number 22>

est de préférence comme décrit dans le présent mémoire, mais il peut comprendre ou omettre diverses caractéristiques tout en donnant des fonctionnalités équivalentes. La fonction de gestion de listages de recherche sur un serveur de gestion de comptes comprend une ou plusieurs des fonctions suivantes : la récupération des listages de recherche, la récupération de l'état du marché, la récupération d'un ensemble d'identificateur de comptes d'un ou plusieurs annonceurs, la modification d'une enchère ou d'un autre paramètre d'un ou plusieurs listages de recherche, l'addition d'un ou plusieurs listages de recherche associés à un annonceur, et la suppression d'un ou plusieurs listages de recherche associés à un annonceur.

Comme noté, l'ordinateur client des modes de réalisation représentés communique avec le serveur de gestion de comptes par l'intermédiaire d'une interface 17 utilisant le langage XML. L'interface 17 supporte des applications de bureautique de l'ordinateur client et des outils automatiques de gestion de comptes avec un marché en ligne du type décrit dans le présent mémoire. L'interface 17 constitue une interface externe commune de sécurité mise en oeuvre au serveur de gestion de comptes 22 (figure 1) pour l' inter- action avec les systèmes d'annonceur du système 22.

L'interface XML 17 du serveur 22 et l'interface XML 15 de l'ordinateur client sont complémentaires et permettent donc des communications bidirectionnelles fiables des requêtes entre le client et le serveur et les réponses du serveur au client.

La réalisation et l'exécution de cette interface 17 reposent sur plusieurs hypothèses. L'interface 17 est une page de toile donnée par l'opérateur du marché en ligne. Les requêtes à l'interface 17 sont "postées" suivant le protocole HTTPS. Le client et le serveur émettent des commandes et des réponses avec un codage XML et des caractères UTF-8.

Toutes les communications correspondent à la spécification

XML spécifiée par http://www.w3c.orçr/L/. Toutes les appli- cations doivent utiliser un analyseur syntaxique XML ("parser") qui permet l'utilisation d'une quantité variable

<Desc/Clms Page number 23>

d'espaces blancs, d'éléments et de noms et valeurs d'attribut. Tous les participants évitent d'essayer d'extraire manuellement les données des documents XML par mise en oeuvre de modèles ("pattern") qui nécessitent des noms spécifiques de champ, etc. Toutes les requêtes transmises au serveur sont validées par rapport à un schéma officiel de requête. Toutes les réponses du serveur sont validées par rapport au schéma de réponse. Toutes les requêtes parvenant au serveur de gestion de comptes qui ne correspondent pas au schéma de requête sont immédiatement rejetées.

Les exemples donnés dans le présent mémoire concernent l'installation d'annonceurs de centres de trafic direct "DirecTraffic Center" fournis par Overture Services, Inc. L'homme du métier peut modifier et étendre ces exemples afin qu'ils s'appliquent à d'autres systèmes et d'autres fournisseurs de services.

Postage vers le serveur de gestion de comptes
L'interface 17 définit un certain nombre d'en-têtes HTTP et de paramètres nécessaires dans l'attenle d'une réponse du serveur 22 de gestion de comptes. L' en-tête de type de contenu est nécessaire pour toutes les requêtes de postage POST transmises au serveur. Dans un mode de réalisation, l'en-tête a la valeur suivante "application/x-www-form-urlencoded". En outre, l'en-tête de longueur de contenu doit être spécifiée et indique le nombre d'octets transmis au serveur. D'autres informations sont disponibles dans la spécification HTTP1.1 au site ftp://ftp.isi.edu/in-notes/rfc2616.txt. On indique dans la suite une liste d'autres paramètres utilisés pour le postage au serveur 22 avec une brève description. xml
Nécessaire. Ce paramètre contient le document XML à transmettre au serveur de gestion de comptes. Si l'en-tête de type de contenu est "application/x-www-form-urlencoded", la valeur du paramètre doit être codée sous forme d'adresse URL.

/go//xml/XMLrequestHandler-submit ~D:/go//xml/XMLrequestHandler.submit

<Desc/Clms Page number 24>

Nécessaires. Dans ce mode de réalisation, le serveur d'application utilise intérieurement ces paramètres. Les valeurs spécifiées pour chacun sont "blanc" (espace). contentType
Eventuel. La valeur de ce paramètre peut être "text/plan" ou "text/xml" (valeur par défaut).

Exemple POST

POST Isldtclxmllindex jhtml?DARGS= %2Ps%2Fdtc%Zxml%z'in.dex jhtml HTTP/1.0 Content-Length: 404

Content-Type: applicatio'n/x-www-form-urlencoded Xml=%3o%3fxm1--version J 3d%221.0%2z+ettcoding lo3d%22U1'F- 8%22%3f%3e%3cD'TCRequest-±r-xmlns /3axsi%3d%221xttp%3a%2lo2www.w3.or g%2fZ001 '/o2fXMLSchemainstarce%22±versiont%3d%221.0%22++uscmame%3d%22gototest%22±password %3d%22qblahblaht l 22"/oe±%3cActions%3e++++ / 3cGetAccountIds%2f%3t-f- %3c%zfAations%3e%3c%2fDTCRequest%3e&~nJgo2lxm1I3MLRequestlandler.s wbmit= &/go2/xFnl/XMLRequestHan,dIer.SLibmit=&contentType=textô/û2iplain ORDRE DES OPERATIONS
En général, il n'existe pas d'ordre spécifique pour soumettre les commandes au serveur XML. Le serveur traite les requêtes dans l'ordre de leur réception. Cependant, il existe un ordre logique que les clients du serveur XML peuvent vouloir suivre.

Avant que des listages puissent être récupérés ou que des enchères soient ajustées, l'ordinateur client récupère l'ensemble des identificateurs de compte avec lesquels il doit travailler. Dans un mode de réalisation, le serveur donne l'identificateur de compte et le marché pour lequel le compte est valable.

Lorsque l'ordinateur client peut travailler sur la liste des identificateurs de compte dont il dispose, il peut récupérer l'ensemble des listages de ce compte. Il donne alors l'attribut important d'identification de listages

<Desc/Clms Page number 25>

listingld qui est nécessaire pour les transactions d'établissement de listages SetListing. L'attribut listingld est statique (c'est-à-dire qu'il ne change pas) si bien que la même identité peut être utilisée indéfiniment pour se référer à un listage spécifique. Si le listage est supprimé et que son identité est utilisée, une erreur est renvoyée.

Cette fonction donne aussi l'attribut de terme de recherche searchTerm qui est nécessaire pour utiliser la fonctionnalité d'état du marché.

Lorsque l'ordinateur client dispose de l'ensemble des listages et des termes de recherche, il peut déterminer l'état actuel du marché pour les listages intéressants.

Cette fonction donne l'ensemble des listages de recherche dans l'ordre d'apparition pour une personne qui reçoit les résultats de recherche à la suite d'une requête transmise au serveur 24 de toile à moteur de recherche (figure 1).

L'ensemble des listages de recherche comprend les listages qui n'appartiennent pas à l'annonceur en cours. Le serveur désigne les listages que possède l'annonceur en cours par transmission de l'identité de listages.

D'après l'état de marché, l'ordinateur client peut établir une enchère pour chaque listage. Un mode de réalisation ne permet que des requêtes de changement de prix fixe d'enchères en une seule fois pour un listage. D'autres modes de réalisation permettent le changement de l'attribut ou du paramètre d'un listage de recherche.

AUTHENTIFICATION
Dans le mode de réalisation représenté, le premier bit d'information qui doit être donné pour chaque requête est une chaîne de version, un nom d'utilisateur enregistré et un mot de passe. Ces informations doivent être données dans la balise XML au niveau de la racine DTCRequest transmise au client. Toutes les commandes transmises au serveur doivent être contenues dans cette balise au niveau de la racine. Si l'une quelconque des informations de la balise de la racine manque ou est incorrecte, la requête est rejetée et toutes les commandes contenues sont ignorées. Par exemple

<Desc/Clms Page number 26>

<DTCRequest version""1 0" usemame="tesiuser" pas5word"test password"> <@- quenesandcommandsgohère --> </DTCRequest>
La version est une chaîne qui décrit la version de l'interface XML 17. Si elle ne correspond pas à la version qu'utilise le serveur 22, une erreur est transmise et toutes les commandes contenues dans la requête DTCrequest sont ignorées.

Le nom d'utilisateur correspond à un nom d'utilisateur préexistant. Le mot de passe doit être celui que l'utilisateur utilise pour s'enregistrer sur le serveur de gestion de comptes. Si le nom d'utilisateur ou le mot de passe n'est pas transmis ou est incorrect, une réponse est immédiatement transmise et toutes les commandes contenues dans la requête DTCRequest sont ignorées. La réponse peut avoir la forme <DTCResponce success-"false" reason = "Login failed"/>
Dans des modes de réalisation qui donnent accès aux administrateurs, lorsque le nom d'utilisateur et le mot de passe donné appartiennent à un administrateur, celui-ci peut exécuter n'importe laquelle des actions indiquées dans la suite pour n'importe quel compte d'utilisateur.

Lorsque les phases d'enregistrement et de vérification de version sont satisfaisantes, une réponse satisfaisante est transmise et toutes les commandes contenues sont traitées.

<DTCResponse success="true"> ...<!--processed commandresponses here--> </DTCResponse>
RECEPTION DE L'ENSEMBLE D'IDENTITES DE COMPTES
Il est possible que l'utilisateur ne connaisse pas l'ensemble des identités de comptes nécessaires aux commandes ultérieures. Cette fonction permet la transmission d'une requête pour une liste. Les administrateurs doivent

<Desc/Clms Page number 27>

donner un nom d'utilisateur pour lequel ils veulent recevoir les identités de compte. Par exemple : <Actions>

<GetAccountIdsdtcUsername="joebob"/> </Actions>
Normalement, les utilisateurs non administrateurs ne donnent pas leur nom d'utilisateur puisque le serveur en dispose déjà dans la balise DTCRequest : <Actions>

<GetAccountlds/> </Actions>
Si un utilisateur non administrateur spécifie un nom d'utilisateur dtcUsername, il est rejeté avec un code d'erreur indiquant qu'il ne dispose pas de la permission.

La réponse à la requête précitée aurait l'aspect suivant :

ActiQnslespons <GeîAccountMsR.e5ponse$uccess=''true''> <Account id=" 12345" market--l"US"> <Account id =''af345G" market=MUK7> </GetAccountldsResponse> 'lActionsesponse>
Le champ de marché est une énumération (définie dans le schéma) indiquant à quel marché appartient le compte.

RECUPERATION DES LISTAGES
Pour que les caractéristiques d'un listage soient modifiées, l'utilisateur doit d'abord transmettre une requête de récupération du listage. Toute requête de listages est contenue dans la balise XML d'actions "Actions". La balise d'actions contient l'identité de comptes pour

<Desc/Clms Page number 28>

toutes les requêtes et commandes contenues qui peuvent être transmises. L'identité de comptes est validée d'après la liste des identités de comptes pour un utilisateur normal.

Les administrateurs peuvent travailler sur n'importe quel ensemble d'identités de comptes.

Il est possible d'acquérir un ensemble de listages d'après certains critères ou, lorsqu'aucun critère n'est spécifié, tous les listages de l'identité de compte spéci- fiés sont obtenus. Le nombre maximal de listages renvoyés, lorsque l'attribut de nombre maximal n'est pas spécifié, est égal à 40. Lorsqu'aucun index initial n'est spécifié, la liste commence avec le résultat 1. Cette fonction par défaut ne donne pas le rang actuel pour chaque listage. Pour que ces informations soient obtenues, l'attribut indiquant l'inclusion du rang doit être spécifié avec une valeur élevée. On considère maintenant des exemples.

1) Recevoir tous les listages (jusqu'au nombre maximal) pour l'identité de comptes 12345.

<Actionsaccountld="12345"> <GetListings/> </Actions> 2) Recevoir tous les listages jusqu'à un nombre maximal de 10 dont le terme de recherche contient "car" pour l'identité de compte 12345.

<Actions accountÏd-"I2343"> <GetListings searchTerrn='Jcar" maxCount =' I 0'/> </Actions>
3) Recevoir tous les listages permis au maximum ayant une enchère comprise entre 0,05 et 0,10 avec l'information de rang actuel <Actions accountld="12345"> <GetListings lowBid="0.05" highBid'0.10" withRank="true"/> </Actions>

<Desc/Clms Page number 29>

D'autres critères valides de recherche comprennent : l'adresse URL le titre la description
Les critères de recherche qui ne reposent pas sur l'enchère donnent un accord lorsque la chaîne est contenue dans le champ du listage de recherche. Les critères de recherche reposant sur l'enchère sélectionnent les listages dont l'enchère est supérieure ou égale à l'enchère spécifiée dans l'attribut d'enchère inférieure lowBid ou est inférieure ou égale à l'enchère spécifiée dans l'attribut d'enchère supérieure highBid.

Lorsque l'exécution est satisfaisante, la réponse obtenue est analogue à la suivante :

<ActjonsResponse suceess="tnie"> <OetListingsResponse success="truefl> <Listing indexer 1 istingld="a23 11 .../> <Listing indexa listingxd="lz3ac34''rank=''3''...I </GetListingsResponse> </ActionsResponse>
L'identité de listages doit être utilisée pour se référer à une adresse de ligne particulière lors du change- ment de caractéristiques avec une requête d'établissement de listages (décrite dans la suite).

OBTENTION DE L'ETAT DU MARCHE
La fonction d'obtention de l'état du marché GetMarketStat est destinée à donner un instantané de l'état actuel du terme de recherche particulier. Ceci peut être utile pour l'observation des différences d'enchère entre les rangs différents afin que l'enchère puisse être changée de manière correspondante. La fonction comporte une identité de marché (nécessaire) et un terme de recherche (nécessaire) et renvoie l'état de marché tel qu'indiqué par le site du client "Overture". Par exemple, la demande porte sur les listages actuels classés de 1 à 5 sur le marché des Etats- Unis d'Amérique et le terme de recherche "cars".

<Desc/Clms Page number 30>

<GetMarketState market = '0' searchTerm = "cars" maxCount = '5'/>
La réponse est analogue à la réponse suivante.

<GetMarketStateRespanse success="true"> <Listing rank=" 1" titte="3nvoiceDea.lers.com - Buy New Cars Direct" description=;"Quick, easy, painless... It's new car buying made easy at InvoiceDealers.com! Get new carpricing before you visit the dealer at lnvoiceDealers.corn." siteHast="wvvr.inVOiGedealerS.cnm" bid="Q.43" currency="USD" ! <Listing rank="2" title="AutoMail Online - Instant Online Prices' descriptionT"Since 1991 The smartest way to buy a car. Online instant dealer price quotes with registration. Guaranteed lowest prices on the Internet. Over 5,000 quality dealers." sîtcHost=11www.automallonline.comn bid="0.42" currency="USD" /> <Listing rank="3" title="Extended Warranty for New or Used Cars" description=:"Get extended car warranty coverage for up to seven years or 150,000 miles. Save up to 60% offdealer prices. Click here for a free quote from the No. 1 online provider." siteHost=..www.wammtygold.com.. bid="0.38" currency="USD" t> <Listing rânk="4" title="New Car - GetLowest DealerPriée Fast" description="Ready to buy? Get multiple price quotes on anew car from localand online dealersfast. Submit simple, no-obligation formspowered bytbe leading automobilesites. Compare forbest deat." siteHost="www.pricequotes.com"

bid="0.37" currency=",1SD" l> <Listing rank="5" title"""'Lexus.com Official Site" description="Explore the models, build your Lexus, search for a certified pre-owned Lexus, or find a dealer." siteHost="mojofarm.mediaplex.com" bid="0.36" currency="USD" /> </GetMarketStateResponse> ETABLISSEMENT DE L'ENCHERE POUR UN LISTAGE
Dans un mode de réalisation, l'interface XML ne permet que des changements d'enchères fixes en une seule fois pour un listage particulier. D'autres modes de réalisation permettent la modification d'autres champs, d'autres comportements des enchères, etc.

Pour le changement de l'enchère, l'utilisateur place une balise d'action avec le numéro de compte qui contient le listage ou les listages à changer. L'attribut d'identité de comptes est validé après le nom d'utilisateur et le mot de passe donnés dans les étapes précédentes. Dans la balise d'établissement de listages, l'identité de listage, donnée dans la réponse d'obtention de listage, est spécifiée.

L'élément suivant nécessaire et l'élément de comportement

<Desc/Clms Page number 31>

d'enchère BidBehavior qui est suivi par l'élément fixe qui nécessite que l'enchère soit spécifiée comme attribut.

Par exemple, on a

<Actions accountIcFlJ 123 "> <SetListms!istmG!d="al23b455"> <BidBehavior> <Fixed bid="0.50"/> </BidBehavior> </SetListing> </Actjons>
Dans un mode de réalisation, considéré comme enchère pour les premières places, l'utilisateur peut spécifier que listage de recherche doit toujours apparaître parmi les trois premiers listages présentés dans les résultats de recherche. Lorsqu'un tel changement est souhaitable, l'élément "B2P" est transmis à la place de l'élément fixe. Pour l'élément B2P, le rang voulu et la valeur maximale maxCap (somme maximale que l'annonceur veut payer pour le rang voulu) sont nécessaires. Par exemple, on a

<Actions accountId=" 23''> <SetListing )Jstingïd="al23N55"> <$ICiBEIiâ'Vi0i> <B2P raak=" 1 " maxCap="0.50''l> </BidBehavior> </SetListing> </Actions>
Lorsque le résultat est satisfaisant, la réponse qui est reçue est analogue à la suivante : <ActionsResponse success="true">

<SetListingResponse Iistïngld="al23b455" success=ntrue"> lActionsResponse>
Lorsque le résultat n'est pas satisfaisant, le système transmet une phrase indiquant la raison du défaut de succès, par exemple :

<Desc/Clms Page number 32>

<ActionsResponse success="true">

<SetListingResponse listingld ="a123b45S" sttcces5="false" reason="Bid must be in theformat#.##"/> </ActionsRespon$e>
L'annexe A qui est associée donne un ensemble d'exemples de requêtes qui peuvent être utilisées par un client du serveur de gestion de comptes. De même, l'annexe B indique un ensemble d'exemples de réponses qui peuvent être renvoyées au client par le serveur à la suite de la requête transmise. L'annexe C représente un exemple de schéma XML pour les requêtes soumises par un client au serveur. L'annexe D est un exemple de schéma XML pour les réponses du serveur au client . Toutes ces annexes ne sont qu'illustratives et ne limitent pas la portée de l'invention.

La figure 3 est un schéma représentant les types d'informations contenues dans chaque enregistrement 300 de comptes d'annonceur dans la base de données 40 de recherche (figure 1). Cette base de données 40 contient des enregistrements de listages de recherche utilisés pour la création de résultats de recherche à la suite de requêtes d'utilisateur. D'abord, un enregistrement 300 contient un nom d'utilisateur 302 et un mot de passe 304, utilisés pour l'authentification en ligne comme décrit précédemment. L'enregistrement de comptes contient aussi des informations 310 de contact, telles qu'un nom de contact, un nom de société, une adresse physique, un numéro de téléphone et une adresse électronique.

Des informations 310 de contact sont utilisées de préférence pour diriger les communications vers l'annonceur lorsque celui-ci a demandé la notification d'événements clés. L'enregistrement 300 du compte contient aussi des informations de facturation 320, telles que le solde actuel et des informations de carte de crédit. Les informations 320 de facturation contiennent des données obtenues lorsque l'annonceur sélectionne l'option d'addition d'argent à son compte. En outre, certaines informations de comptabilité,

<Desc/Clms Page number 33>

telles que le solde actuel, peuvent déclencher des événements nécessitant une notification avec l'option de notification. La section 325 de suivi d'audit d'un enregistrement 300 de compte contient une liste de tous les événements qui ont eu accès à l'enregistrement 300. Chaque fois qu'un enregistrement 300 est atteint ou modifié par un administrateur ou un annonceur, une courte inscription décrivant l'événement de modification et/ou l'accès au compte est annexée à la section 330 de suivi d'audit de l'administrateur ou au compte d'annonceur qui a déclenché l'événement. Les informations de suivi d'audit peuvent alors être utilisées pour la création d'un historique des transactions effectuées par le propriétaire du compte à ce compte.

La section 330 d'informations commerciales contient des informations nécessaires pour l'exécution du processus de mise aux enchères en ligne du marché en ligne, et une position est déterminée pour la description d'un site sur la toile et d'un hyperlien à placer dans une liste de résultats de recherche créée par le moteur de recherche. Les données commerciales 330 pour chaque compte d'utilisateur 300 peuvent être organisées avec des comptes auxiliaires 340 en nombre allant de 0 à plusieurs. Chaque compte auxiliaire 340 comporte au moins un listage de recherche 344. Chaque listage de recherche correspond à une enchère sur un terme de recherche. Un annonceur peut utiliser des comptes auxiliaires pour organiser plusieurs enchères sur plusieurs termes de recherche ou pour organiser des enchères sur plusieurs sites de la toile. Les comptes auxiliaires sont aussi particulièrement utiles pour les annonceurs qui veulent suivre les performances de segments ciblés du marché. La superstructure des comptes auxiliaires est introduite pour le bénéfice des annonceurs voulant organiser leurs efforts publicitaires et n'affecte pas le procédé de fonctionnement du système et du procédé décrit. Dans une variante, la section d'informations commerciales ne doit pas comprendre la couche d'organisation des comptes auxiliaires mais peut simplement comprendre un ou plusieurs listages de recherche.

<Desc/Clms Page number 34>

Le listage 344 de recherche correspond à un terme de recherche et une enchère associée et contient des informations clés pour l'exécution du processus de mise aux enchères en ligne. Dans un mode de réalisation, chaque listage de recherche comprend les informations suivantes : le terme de recherche 352, la description 354 du site de la toile, l'adresse URL 356, l'enchère 358 et un titre 360. Le terme de recherche 352 comporte un ou plusieurs mots-clés qui peuvent être des mots courants en langue anglaise ou autre. Chaque mot-clé comprend à son tour une chaîne de caractères. Le terme de recherche est l'objet du processus de mise aux enchères en ligne. L'annonceur sélectionne un terme de recherche pour enchérir lorsqu'il concerne le contenu du site de l'annonceur sur la toile. Dans un cas idéal, l'annonceur peut sélectionner un terme de recherche qui est ciblé sur les termes qui risquent d'être saisis par les personnes qui cherchent des informations sur le site de l'annonceur bien que des termes de recherche moins courants puissent aussi être sélectionnés pour assurer une couverture étendue des termes de recherche concernés par l'enchère.

La description 354 du site de la toile est une courte description textuelle du contenu du site de l'annonceur sur la toile. La description 354 peut être affichée comme entrée relative à l'annonceur dans la liste des résultats de recherche. Le listage de recherche 344 peut aussi contenir un titre 360 du site de la toile qui peut être affiché sous forme d'un en-tête d'hyperlien sur l'entrée d'annonceur dans la liste de résultats de recherche. L'adresse URL 356 contient l'adresse de localisation uniforme de ressource du site de l'annonceur sur la toile. Lorsque l'utilisateur clique l'hyperlien disposé dans l'écriture de la liste des résultats de recherche pour l'annonceur, l'adresse URL est transmise au navigateur. Le navigateur a lui-même accès au site de l'annonceur en redirigeant le navigateur sur le site spécifié par l'adresse URL. L'adresse URL peut être affichée comme partie de l'inscription de l'annonceur dans une liste de résultats de recherche.

<Desc/Clms Page number 35>

L'enchère 358, dans un mode de réalisation, est une somme monétaire payée par un annonceur pour un listage. Cette somme est déduite du compte prépayé de l'annonceur ou est enregistrée sur des comptes d'annonceur facturés chaque fois qu'une recherche est exécutée par un utilisateur sur le terme correspondant de recherche et l'hyperlien de la liste de résultats de recherche est utilisé pour l'accès de la personne qui cherche au site de l'annonceur. Dans d'autres modes de réalisation, l'enchère peut être un autre type de valeur économique donnée par l'annonceur ou reçue par l'opérateur du marché en ligne.

Enfin, la valeur du rang est la valeur créée dynamiquement, de préférence par le système 34 de traitement du serveur 22 de gestion de comptes indiqué sur la figure 1 chaque fois qu'un annonceur fait une enchère ou qu'une recherche transmet une requête de recherche. La valeur du rang du listage de recherche de l'annonceur détermine l'emplacement de l'écriture de l'annonceur dans la liste de résultats de recherche créée lorsqu'une recherche est exécutée sur le terme correspondant. De préférence, le rang est une valeur ordinale déterminée directement d'après l'enchère 358 et plus l'enchère est élevée, plus le rang est élevé et plus la position sur la liste des résultats de recherche est avantageuse. De préférence, le rang 1 est affecté à l'enchère la plus élevée, et les valeurs ordinales les plus élevées suivantes (par exemple 2,3, 4,...) associées aux rangs inférieurs suivants sont affectées à des enchères successivement plus réduites.

Un exemple d'affichage de listes de résultats de recherche utilisées dans un mode d'exécution de l'invention est représenté sur la figure 4 qui affiche les premières inscriptions résultant d'une recherche sur l'expression "zip drives". Comme l'indique la figure 4, une inscription unique telle que l'inscription 710 de la liste des résultats de recherche comprend une description 720 du site de la toile, comprenant de préférence un titre et une courte description textuelle, et un hyperlien 730 qui, lorsqu'il est cliqué par une personne, dirige le navigateur de cette personne sur

<Desc/Clms Page number 36>

l'adresse URL où se trouve le site décrit de la toile.

L'adresse URL 740 peut aussi être affichée dans l'inscription 710a de la liste de résultats de recherche comme indiqué sur la figure 4. Le clic sur l'article du résultat de recherche se produit lorsque la personne distante voyant l'affichage 710 d'articles de résultats de la figure 4 sélectionne l'hyperlien 730 de l'affichage 710 ou clique sur lui. Pour qu'un clic soit exécuté, le clic de la personne qui cherche doit être enregistré par le serveur de gestion de comptes et redirigé vers l'adresse URL de l'annonceur par l'intermédiaire du mécanisme de redirection décrit précédemment.

Les inscriptions 710a à 710h de la liste de résultats de recherche peuvent aussi indiquer le rang du listage de recherche de l'annonceur. Le rang est une valeur ordinale, de préférence un nombre, créé et affecté au listage par le système de traitement 34 de la figure 1. Le rang est de préférence affecté par un processus de type logiciel qui établit une association entre l'enchère, le rang et le terme de recherche d'un listage de recherche. Le processus regroupe tous les listages de recherche qui correspondent à un terme de recherche particulier, trie les listages dans l'ordre de l'enchère la plus élevée à la plus faible, et affecte un rang à chaque listage dans l'ordre. L'enchère la plus élevée reçoit le rang le plus élevé, l'enchère la plus élevée suivante reçoit le rang le plus élevé suivant, jusqu'à l'enchère la plus faible qui reçoit le rang le plus bas. De préférence, le rang le plus élevé est 1 avec augmentation successive des valeurs ordinales (par exemple 2,3, 4,...) affectées dans l'ordre des rangs décroissants successivement. La corrélation entre le rang et l'enchère est indiquée sur la figure 4 sur laquelle chacune des inscriptions payées 710a à 710f de la liste indique l'enchère 750a à 750f pour cette inscription. De préférence, lorsque deux listages ayant le même terme de recherche ont aussi la même enchère, l'enchère qui a été reçue le plus tôt est affectée au rang le plus élevé. Les listages non payés 710g et 710h n' indiquent pas une enchère et sont affichés

<Desc/Clms Page number 37>

après le listage payé de plus faible rang. De préférence, des listages non payés sont affichés uniquement lorsque le nombre de listages pouvant remplir les quarante emplacements de la page de résultats de recherche est insuffisant. Les listages non payés sont créés par un moteur de recherche utilisant une base de données distribuées objet et des algorithmes de recherche de texte connus dans la technique.

Un exemple d'un tel moteur de recherche peut être exploité par Inktomi Corporation. La requête de recherche originale saisie par la personne distante est utilisée pour la création de listages non payés par le moteur de recherche classique.

On peut noter d'après ce qui précède que les modes de réalisation actuellement décrits concernent un procédé et un appareil perfectionnés de commande d'affichage des résultats de recherche dans une liste de résultats de recherche. Le système a été perfectionné par addition d'une interface XML au serveur de gestion de comptes et aux ordinateurs des clients. La communication entre le serveur et les clients pour la commande des listages de recherche d'un ou plusieurs annonceurs s'effectue en fonction d'un ou plusieurs schémas XML prédéterminés. Les schémas définissent les paramètres et valeurs pour cibles de données utilisées pour la gestion des comptes d'annonceur et des listages de recherche. De cette manière, les groupes de listages de recherche de plusieurs annonceurs peuvent être gérés efficacement par un utilisateur unique. En outre, les opérations automatiques peuvent être spécifiées pour la remise à jour des listages de recherche, pour l'obtention de l'état du marché, pour la réception d'informations de compte et pour la production de rapports. Le système et le procédé décrits peuvent être utilisés à la fois par les annonceurs pour la gestion de leurs propres comptes et de leurs propres listages de recherche et par des tiers pour la gestion des comptes et listages de recherche d'un ou plusieurs annonceurs.

Un avantage de l'invention est d'assurer des communications bidirectionnelles fiables des requêtes et réponses entre un client ayant un outil d'enchère pour gestion de

<Desc/Clms Page number 38>

comptes et un serveur d'outil d'enchère de gestion de comptes par utilisation d'interfaces XML complémentaires à la fois du côté du client et du serveur. Un autre avantage de l'invention est qu'elle permet la réalisation sur un réseau distribué d'une interface sécurisée courante de serveur extérieur destinée à être utilisée par des systèmes clients d'annonceur pour l'exécution de fonctions de gestion de comptes avec un marché commercial en ligne, comprenant la récupération de listages de recherche, la récupération de l'état du marché, la récupération d'un ensemble d'identificateurs de comptes d'un ou plusieurs annonceurs, la modification d'une enchère ou d'un autre paramètre d'un ou plusieurs listages de recherche, l'addition d'un ou plusieurs listages de recherche associés à un annonceur, et la suppression d'un ou plusieurs listages de recherche associés à un annonceur. Un autre avantage de l'invention est qu'elle permet l'automatisation de ces fonctions de gestion de comptes par utilisation d'un schéma commun pour la création des requêtes au serveur et d'un autre schéma commun pour la compréhension des réponses provenant du serveur.

Bien entendu, diverses modifications peuvent être apportées par l'homme de l'art aux systèmes, procédés, outils, ordinateurs et supports qui viennent d'être décrits uniquement à titre d'exemple non limitatif sans sortir du cadre de l'invention.

<Desc/Clms Page number 39>

ANNEXE A : de requêtes
Obtient identités des comptes (utilisateur normal) <?xml version="1.0" encoding="UTF-8"?> <DTCRequest

xmlrs.xsi="http-//%4ww.w3,org/2()01/XMLSChema-instanCe" version="1. 0" username="testacct" password="fictionalpass"> <Actions> <GetAccountIds/> </Actions> </DTCRequest> Obtient identités des comptes (utilisateur administrateur) <?xml version="1.0" encoding="UTF-8"?> <DTCRequest

xmlns;xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" username="testadminuser"

password="ficticnalpass"> <Actions> <GetAccountids dtcUsername="jimbob"/> </Actions> </DTCRequest> Obtient les listages

<?xml version="1.0" er.coding="UTF-8"?> <DTCRequest xmlns:xsi="http://www,w3.org/2001/XMLSchema-instance" version="1. 0" username="testacct" password="fictionalpass">

<Actions accountlD="10078915"> z get all listings by search terra --> <GetLiatings maxCountm"40" sear.chTerm="coupon"/> <!-- get all listings by url --> <GetListings maxCount="40"

url="http://www.gotO.COm"/>

<Desc/Clms Page number 40>

<!-- get all listings by title words with current rank info --> <GetListings maxCount="40" title="zero" withRank="true"/> </Actions> </DTCRequest> Obtient état du marché <?xml version="1.0" encoding="UTF-6"?> <DTCRequest

xmlns :xsi="http: //wwk. w3 , org/ 2 00 1/XMLS chaîna-instance" version="1.0" username="testacct" password="fictionalpass"> <Actions> <GetMarketState searchTerm="coupon" market="US"/> </Actions> </DTCRequest> Etablit listages <?xml version="1.0" encoding-"UTF-8"?> <DTCRequest

xmlns:xsl="http://www.w3.org/2001/XMLSchema-instance" version="1. 0"

username="testacct^ password--"fictionalpass"> <Actions accountID="10078815"> <!-- Change bid to $1.50 --> <SetListing listingID-"29153393"> <BidBehavior> <Fixed bid="1.50"/> </Bidbehavior> </SetListing>

<SetListing listingID="295'?'i3"> <BidBehavior> <B2P maxCap="1.50" rank="1"/> </BidBehavior> </SetListing> </Actior.s> </DTCRequest>

<Desc/Clms Page number 41>

ANNEXE B : exemples de réponses du serveur Obtient identités de comptes (utilisateur normal)

<?xml version-111.011 encoding="oTF-8^?> <DTCResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLOCation="dtc.xsd" success="true"> <ActicnsResponse>

<GetAccountidsResponse succès s= "t rue "> <Account id="12345" market="US"/> <Account id="af3456" market="UK"/> </GetAccountIdsResponse> </ActionsResponse> </DTCResponse> Obtient identités de comptes (utilisateur administrateur)

<?xml version-"!. 0" encoding="UTF'-8"?> <DTCResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="dtc,xsd" success="true"> <ActionsResponse> <GetAccountIdsResponse success="true"> <Account id="1245" market="US"/> <Account id="af3456" market="UK"/> </GetAccountIdsResponse>

</ACtionsResponse> </DTCResponse> Obtient listages <?xml version="1.0" encoding="UTF-8"?> <DTCResponse

xmlns:xsi="http:l/www.w3.org/2001/XMLSChema-instance" xsi:noNamespaceSchemaLocation="dtc.xsd" success="true"> <ActionsResponse> <GetListingsResponse sucess="true"> listing listingID="29153391"

url="http://mappedtocouponurl.com/" searchTerm="best web site for coupon" bid="C.13" title="Title mapped to 'coupon'

description="Dese mapped to 'coupon'"

<Desc/Clms Page number 42>

market="US" online="true"/>

<Listing listingID="29153393" url="http://mappedtocouponurl.co:n/" searçhTerm="coupon" bid="0.49" title="Title mapped to 'coupon'" description="Dasc mapped to 'coupon'" market-"US" online-"true"/> </GetListingsResponse> <GetListingsResponse success="true"> <Listing listingID="26929544" rank-"3" url="http://www.goto.com/"

s2archTerm="gototest123456789" bid="0.05" title="test" description="test," market="US" online="true"/> </GetListingsResponse> </ActionsResponse> </DTCResponse> Obtient état du marché

<?xml version="1.0" encoding="UTF-8"?> <DTCResponse xmlns:xsm"http://www.w3.org/2001/XMI,Schema-instance" xsi:noNamespaceSchemaT.ocation="dtc.xsd" success=''true"> <ActionsResponse> <GetMarketStateResponse success="true"> <Listing rank="l" title="Print Free Coupons from Your Computer!"description="Print free coupons from your computer at CoolSavings! You'll save big on groceries, clothes, baby and kid's stuff, home items and much more! Click here to enroll. It's

free!" siteHost="www~coolsavings.com" bid="0.39" currency="USD" /> <Listing rank="2" title="Get Free Local Coupons

at ClipACoupon!" description-"lt's totally free! Enroll now to print free money saving coupons when you want or need them. Print free coupons or receive great online deals from our local and national marchants."

si teHost="www. ci ipacoupon.com" bid="0.27" currency="USD" /> <Listing rank="3" title="The Online Coupon Resource" description-"Click here to visit lOOGreatCoupons.com. We can help to save you money on

<Desc/Clms Page number 43>

every online purchase from major online retailers like Amazon.com, BarnesandNoble.com, and Half.com."

siteliost="w-ww.100greatcoupons.com" bid="0.27" currency="USD" /> </GetMarketStateResponse> </ActionsResponse> </DTCResponse> Etablitlistages <?xml version="1.0" encoding="UTF-8"?> <DTCResponse

xmlns:xsi="http://www. w3.org/2001/XMLSchema-mstance" xsi:noNamespaceSchemaLocation="dtc.xsd" success="true"> <ActionsResponse success""true">

<SetListingResponse listingid"29153393" success="true"/> OetListingResponse listingID="29153323" success="true"/> </ActionsResponse> </DTCResponse>

<Desc/Clms Page number 44>

<?xml version*"!.C" cncoding="UTF-8"?> <!-- *.*..**...*+,....**..*.*.**v.*.....+*.******.****r.

"'j --> <!-- Copyright 2001, OVerture --> <!-- --> <@-- Schéma XML d'outil d'enchères pour accès par programme aux caractéristiques --> <!-- de DTC.

<!--

~w.****+...*.*..+*..*++....****.*..****..*+*+.**.**.**-**** ** --> <xsd:schema

xmlns:xsd="http://ww .w3~crg/2001/7CMLScbama" élément FormDef au lt=Mqualif ied"> <xsd:aleraent name""DTCRequest" type""D'1'CRequestType"" <i # *##* *# *** **** # Request Types i < im ( . # <xsd:comp3.exType nam6="RequestType*> <xsd:attribute name""aux" type"NonErnptySt"ing" use="optional"/> </x5d:cornplxType> <xsd:complexTypa nam6= " DTCRequMtType "> <x$d:complexConter.t> <xsd:extension base="Reque3tType"> <xsd:sequence> <xsd:element name"Action$u type="ActionType" minOccurs '1 ' maxOccurs='unbounded' /> </xsd:sequence> <xsd-attribute nal1\eKS"VerSl.on" typec"NonErnptySrinl1" use"="required"/> <xsd:attzibute name="username" typ9="MonEmptyString' use="required"/> <xsd:actribute 1Iame"password" type="NonEmptyStrinq" U9e'='"rquired"/> </xsd:extension> </xsd'ccmplexContent> </xsd:cvmplexType> <xsd:complexType name"ActionType"> <xsd:complexContent> <xsd:extension base="l\eques t Type "> <xsd:sequence>

<xsd: élément name-"GetAccountid3" type"AccounCIdType11 rninOcC1Jt""""'O' maxOccurs='unbounded'/>

<Desc/Clms Page number 45>

<xsd:element namea^GetMarket5tnte" type="MarketStateiype" minOccurs='0 ' naKOccur3='nbounde(I'/> <xsd:elemet,t nametr"GetListings" type="Getl.istingType" minOccurs='0' maxOccuE5'='unboundeci'/> <xsd:element nme::"$etListin9" type=--settistinrype,, it\inOccur3='0' max0ccurs='unbounded'/> <xsd:element name:*"AdctLi sting" type="AddListmgType" minOCCUrs='0' maxOccurs- ' unbounded ' /> <xsd:element name-I'DeleteLiating" type="DeleteListinqType" mit)Occurr:"" 0' m8xOc::urs= 'unbounded'f> </xsd: sequence> <xsd:attribute narne""accountId" type="NonEtlptySr.r ;.n9" USe="optional"/> </xsd:extension> </xsd:complexContent> </xsd:complexType>

<xsd:complexType name"AddüstingType"> <xsd:complexContent> <xsdrex2ension basc="ReqLe$tType'*> <xsd:attribute name="title" tyFQ"''NonE'nptyStrin3" uae="required"/> <xsd:attribute name="description"

typey"NOnEmptyString" use="required"/> <xsd:attribute names"url" type="NonEmptyStr ing" use="required"/> <xsd: attz ibl.1te name=s"se9rchTerni" type..,NonEmptystringuse*"required"/> <xsd:att.tibute name="bid" type="BidType" use="required"/> <xsd:attribute name-"isAdult"

type=*'xsci:boolean" use="optionaI"/>

</xsçl:exteneion> </xsd:complexContent> </xsd:complexType>

<X5d:complexîype name="DeleteListingType"> <x3d;complexContent> <xsd:extension ba5e- IlequestType"> <x5d:atcribute name="listingId" cype=-NonEmptyString" use="required'V> <xd:extension>

<Desc/Clms Page number 46>

</xsdtcomplexContenlt> </xsd:conplexType> <xsd:ccmplexType name""Jo Acco\lnt Id1ype" <xsd:ccmplexContent> <xsd:extension base= "Requos tTypc #'> <!-- The cltcusername attribute is valid only for administrative --> <!-- users Any y ottior time the usernane is pec.l.!1.ed, it --> <!-- will be ignored.

-->

<xsd:attribute name='dtcUsername" type="NOnemptyString" use="opticnal"/> </xsd:extension> </xsd:compJexContert' </5d:compIexType> <x.5dcc,rftplexTypo n"",,,"SetList::.n91ype"> <X9d:corcplexConten> <xscl:exten3lon base="RWListinqType"> <x9d:sequcnce> <xsd:element na e=I*aid8ehavior" type="BidBehaviorType" minOccurs='0'

maxOccurs=' 11 1> </xsd:sequence>

</x3d: exension> /xsci: compluxcontent> </xsd.complextype> <xsd:complexType name="NarketStateType"> cxsd;compl-excontent> <xsd!extension base:"RequestType"> <xsd:attribute name-"searchTerm" type="NonEmptyString" :.J...:":::equJ.red" /> <xsd:attribute name="matket" typ(='ir"Marî:etTj5e" uae "required"/> <xsd:attribute rlame"startIndex" type*"xs<i; integer" use-"optional"/> <Xed:attribute name="maxCount" type="xsd:integ2r" USE!"'''optlonarOt/> </xsd:extension> </xsd:complexContent> </ x.d: comp1 exTy>e> <xsd:complexType nome="GetListinqType"> <xsd:complexContent> <xsd:exter.sicn ba5e=".RequestType"> <xsd;attribute na:ne="tW 1e" type="NonEmptyStrmg" usc;.="opr 10:1a.l '1 /> cxsd:actribvte name="description" type="NonEmpty$tringuse "optional"!> <xsd'attribute names"url" t ype=-" tJonmptySrin9" use"" "optional" 1> <X3d:attribute name"lov8id" type="6idType" use""''' optional"!>

<Desc/Clms Page number 47>

<xsd:attribute name="highHid" typea"HidType" use="opcional"/> <xsd:attribute name="maxCount" type="xsd:inteqer" use="optional"/> <xsd:attribute name="aearehTerm" type "NonEmpcyString" ue="optiona.l" 1> <xsd:attribute name="market" type="MarketType"

uSe= "apt ional" /> <xsd:attribute name="startIndex" type="xsd:integer" use="optional"/> <xsd:attxibute name="NithRank" type="xsd:boolean" uae''"option9i"/> </xsd:extension> <!xsd:complexCOnter.t> </xsd:co'XIp1exTyp"> <xsd:complexType .iame="BidLehaviorType"> <xsd:complexContent> <xsd:exte,ision base="RequestType"> <xsd:sequence> <xsd:choice> <xsd:element name="Fixed"

type="Fixed?ype" mlnOccurs 1 1 ' 1 maxOccurs= 'l' /> <xsd:element name-"B2P" type="B2PType'1 minOccurs='I' max0ceurs-1111> </xsd:choice> </xsd:sequence>

</xsd:extenaion> </xsd:complexContenc>

</xsd:complextype> <xsd:complexType name="FixedType"> < 9d:coTftplexContenc> <xzd:Q.tenson base="RequestType"> <xsd:attribute name="bid" type="BidType" u3e="required"/> </Xsd!extension> </xsd:compl,-xContent> </xsê: co;nplexType> <xsd:simpieType name="BidType"> <xsd:restriction basG=nx3d;token"> <xaâ: pattern value"" [ 0- 9 j +\. [0-91 10-9} "/> </,çod:restriction> </xsd:simpleType> <xsd.complexType name="B2PType">

<xsd:complexConter,t> <xsd: extension base::::"RequestType"> <'-- The requested rank --> <xsd:attribute ame"rank" typee:"xsd: posi ti vernteger" use="required"/> <!-- How much the advertiser is willing to pay for the rank - -> <xsd:attribute name="maxCap" typer"xsd:float" use="required"/> </xsd:extension>

</ ){sècomplexÇ'onteTjt:> </:xsd: comp':'ex'1'ype:>

<Desc/Clms Page number 48>

<xsd; comp1.ex'l'ype na;n2.="RWLlstin9Type-> <xsd:complexContent> <XS(iextension base"Request3ype"> 1 ,xsd:attribute name-"listingid" type="NorLmptystring" u3e-"required"/> <xsd:attributs name="t 1. tle" twe'2"NonEmptyString" uge= "opt iona 1" 1> <xs9:zttribute r.ame"description" type=^NOnmptyString" vue"optlonal l> <xsd:attribute name-"Url" type="Non'''OptyString'' use="optional"/> </xsd:extension>

</>cscl:cOMP3.excontent> <ixsd:compiexType> <xsd:simpletype neme="HarketType"> <X8d:re$trictxon base="xsd:string"> <x5d:enumeration value"US" 1> <xBd: et'lumerZltion value=**0K'7> <xsd:enumezation value="'DE"/> </xsd:restriction> </xsd:simpleType>

<xsd:simpletype name=- hNonmpt.ySt.r 1ng"> <x5d:res cri et ion base="xsd:3tring"> <xsd:jriinl1ength valu@:::< Il"1> </xsd:restriction> </xsd:simpleType> </xsd:schema>

<Desc/Clms Page number 49>

ANNEXE D exemple de schéma de réponse

<?xm: vexsion="1.0" encoding="U?F-B"?> ** --> <!-- Copy :ight 2001, Overture --> <!-- --> <!-- Schéma XML d'outil d'enchères pour accès par programme aux caractéristiques --> <!-- de DTC --> <!-- ************ ** --> <xsd:schema

xmlns:xsd="http://vr.v3.org/2001/XMtSchema" elementFormDefault "qualified"> <xsd: element namee")TCRaspone" type="DTCResponBeType' 1> <xsd:complexType nane""Raspons0Type"> <xsd: attributs name="aux" typB=BNonEïïiptySCtfing" use="optional"/>

<l>c8d: CO:f\plex:rype> <x9d:complexType name="StatusResponseType"> <xsd:conLpl#xCor,tenc> <X'sd: xten9ion base="Respo1i$eType Po> <xsd ; attributs name=M5i:cte3s" type=" sd:Doolean11 ust;?=" reqt:ired" 1> <xsd: at tr ibute nûnB="rea3t>" t ype"NonEmptyStriI!9" use="optional"/> </xsd:extension>

</xsd:cOmplexCOntent> </xad : complexType> <xsd:complexType name="DTCResponseType"> <xsd:complexContent> <X3<1: extension base=" StQtusKespon6ê'!' "> <xsd:sequence> <xsd: élément name="fic*ionRe3ponsetI typG="Action5ResponseTypel> minOccurs='0'

maxOecurs= ' unbounded V> </xsd:sequence> </xsd:extension>

</xsd: cO:T1plexConten t> </xsd:ccple7ype> <xsd: corr.pl exType nèmew"ActionsEesponse?ypeI1> <xsd:sequence> <xsd:e].#m&r]t:name='"GetAccountId5R#Sp&nse" typa="etAccountTdsResponse2ype^ minOccurs='0 '

<Desc/Clms Page number 50>

maxOccurs='unbounded'/> <xsd: elel1lnt n311'1e= -GetMarketS ta tep.spol1se" typ= 'Mar ket5t a teResponseType" minOccur='0'

may.Occurs='unbQundecl'/> <xsd:element name="GetLrstingsAesponse t-ype-'"GetLis].ngP.espon3eType" minOccurs= # 0 ' maxOccuxsq'unbounded'l> <xsd:element name""SetXjistingRespon3e'1 typa=" L1S t ingRespon se Type" ttinOccurs=1 0l maxOccurs= 'unbûiinded* J> <x9d: element name=Jti\dd!.i3tir\gResponse" type="ResponseType" minOccurs='0' tt\Q.xOccur s=' unbou:'1ded' /> <..5dzalement n<sme="Del ceLi5t.ingRÊSponse" type="ListingResponseType" rnin.Occur.s 1 C 1 maxOccurs=' unbounded' 1>- </xsd:sequence> <xsd:a.tribute neme="accountZd" type=" KonEmp tyst ring use="optional"/> </xsd:compiexType>

<xsd:complexType namê="GetJ\ccou1'\ tldsRespon$eType"> <xsd:complexCor.tent> <xsd:extension base="Statu$RepongeTyp"> <xsd:sequence> <xsd.element name="Account"

type=-" Account Type minOccurs='0'

maxOccurs='unbounded'/> </xsd:sequence> </xsd:extension>

</xsd:complaxContent> <lxsd:complexType> <xsd.complex2ype name="RccountType"> <xsd:complexContent>

<xsd:extension lDaze-"Respon6eType"> <:K.5d. dt tI:iblJte namee"id" type='NonFmptyString" use="required"/> <xod: attribLJte namo="masket" type="MarketType" use="required"/> </xsd:extension>

</X5d:cornplexContant> </xsd-complexType> <xsd:complexTyroe n!.r.'I.e= "i;u:l.etSta teRespons'rype Il> <xsd:complexContent> <xsd:exter.aion base="M5Listingftesponserype"> <xsd:attribute name="market" type="MatketType" use="r3quiied"/> <xs0:attzibute came="searchTerm" type="NocEmptyString" use="requixed"/> </xsd:extension> </xsd:complexContent> </xsd:complexType>

<"50; comp} ex'l'ype na::r:e"HSListinqRe$pOnSêTypQ ">

<Desc/Clms Page number 51>

<xsd:complexContent>

<xsd: extension base="StatusResponseType"> <xsd:sequenca> <xsd:element nlI:neuLi6t in9" type="MSListingType" minOccurs="0" maxOccurs="100"/> </xsd:sequence> </xsd:extension>

</xsd: complexcontent> </xsd:comp=exType> <xsd; complexType name="GetListingResponseType"> <xsd complexCOl'1ten t> <xsd:excension base=llSt3tusRe$ponserype"> <xsd:sequence> <xsd:element name="Listing"

type="GetListingType^ minOccurs="0" maxOccurs="100"/> </xsd:sequence> </xsd:extension>

</xsd:coroplexContent> </xsd:complexType> <xsd:co.mplexType fl.ame= "List.1.ngResponsarype"> <xsd:complexContent> <xsd:extension basô="StatusRespor)3eType"> <xsd:attribvte name="list:ngtd" type= "NonEmptyStr U1g-' use="required"/> <xsd:attribute narne;:"conf1:t:"mationNumber" type="NonF-,nptyString" use="optional"/> </xsd:extension> </xsd:complexContent> </xsd:complexType>

<xsd:COmplexType name-"Required:,is:ingType"> <xsd:attribute name="title" type="NonErnpcyString" ue;e-"reqired"/> <xsd:attribute name"description^ type="NonEmptyStrin9" U3e'="recjujLred"/> <xsd:att);ibute name="bid" type-"BiclType" use="required"/> <xsd:attribute name="markec" type="MarketType" use=" requl red" /> <xsd:attribute name" eatchTerrn" typea("'NonEl'l1p tySt '( log" use="required"/>

</xstJ: coraplexTyp9> <xsd.complexType name="MSListmgType"> <X3d:complexContent> <x3d: extension base="RQquiredLi3tingTypel<> <xad:attribute name="W stingId" typer:::"Nonl:'.n1ptyString" use="optional"/> <x3d: attribute n.ame-:..! "ur 1" type~"NonEmptyScringt1 use="optional"/>

<Desc/Clms Page number 52>

<xsd:attribute name="currency" type="CUrzencyType" use="optxonal"1> <xsd:attribute name="rank" type="xs,5inzeyer" use="optional"/> </xsd:extens.ion>

</XsdrcomplexCon'ent> </xsd:complexType> <xsd : complexType namo="GetJLÎ5tingrype"> <xscl: comp iexcôr, ter,. t> <43d; eJ'itensiQn b53e="RequtredLigt;ingTyp'ï"> <xsd:actmbote name="IistingId" type="NonEmptyStr i09" use="required"/> <xsd:att:ribute name="url" typec"NonEmptyString" use= fi reql.1iredl' / <xsdattribute name "online" type-"xsd:bootean" l1se="requ..reé"/> <x::rd: 81: tr ibll te n3me*Kcijrrency*' typ="Cu.trency1ype use="optional"/> <xsd:attribute rame='rank" type=^xsd:integer" use="optional"/> </xsd:extension>

</xsd:côrnplexcontent> </xsd:complexType> <xsd:sampleType n8lJ\e"" "Cvr rencyTypell> <xsd:resLriction baae="NOnmptyString"> <xsd:enumeration value=^USD"/> <xsd:enumeration va111e="GBP"/> <xsd:enumeratlon value "EUR"/> </xsd:restricticn> </xsd:simpleType>

<x3d:5impleType name="BidType"> <xsd:restriction base="xsd:token"> <xsd:pattern value"10-91'\.(0-9(0-9]"i> </xsd:restriction> </xsd:simpleType>

<v.Sd:simpleType name="NonmptyString"> <xsd:restriction base="xsd: 9trinq"> <x.d:ml!\Length value=' 1'1> </xsd:restriction> </xsd:simpleType>

<xsd:simpleType na1'l\e::;"Mar:cetrypI'). <xsd:restriction baee-"xsd:String"> <xsd:enumeration valvea"US"/> <xsd:e.n1J.rneraton value:>t"Uk"/> <xsd:enumera aon value="DE"/> </xsd:restriction>

</xsd: s l;npleTyp> </xsd:schena>

Claims (35)

REVENDICATIONS

1. Système destiné à permettre à un promoteur d'un site commercial de la toile utilisant un réseau d'ordinateurs de remettre à jour des informations relatives à un listage de recherche dans une liste de résultats de recherche créée par un moteur de recherche sur Internet, caractérisé en ce qu'il comprend : un système d'ordinateur dans lequel est mémorisé une base de données (38) ayant au moins un enregistrement de compte pour chacun de plusieurs promoteurs de sites commerciaux de la toile à l'aide d'un réseau (20) d'ordinateurs, l'enregistrement de compte comprenant : au moins un listage de recherche qui comprend un terme de recherche ayant au moins un mot-clé, une enchère modifiable, une adresse URL correspondant à l'adresse d'un document résidant sur un serveur de réseau, une description, et un titre, un solde de compte, un code de programmation en langage extensible à balises (XML) sur le système d'ordinateur ayant une configuration permettant l'addition d'un listage de recherche à un compte d'un promoteur de site commercial de la toile lors de la réception d'une requête du promoteur du site commercial de la toile, un code de programmation ayant une configuration qui traite une requête de recherche provenant d'un ordinateur distant, la requête de recherche comprenant au moins un motclé, la requête de recherche étant reçue par le réseau (20) d'ordinateurs depuis l'ordinateur distant par l'intermédiaire d'un site de la toile qui est accessible publiquement sans authentification, et un code de programmation ayant une configuration qui crée une liste de résultats de recherche en réponse à la requête de recherche, la liste de résultats de recherche comprenant des listages de recherche de comptes sur la base de données (38), le terme de recherche de chaque listage de

<Desc/Clms Page number 54>

recherche de la liste de résultats de recherche créant un accord avec la requête de recherche, les listages de recherche de la liste de résultats de recherche étant disposés dans un ordre déterminé par utilisation des enchères des listages de recherche.

2. Système selon la revendication 1, caractérisé en ce qu'il comporte un code de programmation XML placé sur le système d'ordinateur et ayant une configuration permettant la suppression d'un listage de recherche d'un compte d'un promoteur de site commercial de la toile lors de la réception d'une requête provenant du promoteur du site commercial de la toile.

3. Système selon la revendication 1, caractérisé en ce qu'il comprend en outre un code de programmation XML placé sur le système d'ordinateur et ayant une configuration permettant la modification en temps pratiquement réel du listage de recherche d'un promoteur de site commercial de la toile lors de la réception d'une requête du promoteur du site commercial de la toile.

4. Système selon la revendication 1, caractérisé en ce qu'il comprend en outre un code de programmation XML ayant une configuration permettant la création d'un rapport d'activité pour un promoteur de site commercial de la toile lors de la réception d'une requête du promoteur de site commercial de la toile.

5. Système selon la revendication 1, caractérisé en ce qu'il comprend un code de programmation XML ayant une configuration permettant l'accès par enregistrement du promoteur du site commercial de la toile à la suite d'une authentification, l'accès par enregistrement du promoteur du site commercial de la toile donnant à ce promoteur l'accès pour la modification du compte du promoteur, le promoteur du site commercial de la toile n'ayant pas un accès lui permettant de modifier d'autres comptes que les siens.

6. Système selon la revendication 1, caractérisé en ce qu'il comprend en outre un code de programmation XML placé sur le système d'ordinateur et destiné à ajouter une somme monétaire au compte d'un promoteur de site commercial de la

<Desc/Clms Page number 55>

toile pratiquement en temps réel lors de la réception d'une requête provenant du promoteur du site commercial de la toile.

7. Système selon la revendication 6, caractérisé en ce qu'il comporte en outre : un historique des listages de recherche contenus dans l'enregistrement du compte du promoteur de site commercial de la toile, et des informations de traitement de paiement, telles que ces informations sont accessibles au système d'ordinateur et isolées de l'accès public par le réseau (20) d'ordinateurs, et un historique des paiements.

8. Système selon la revendication 1, caractérisé en ce qu'il comporte en outre une interface XML ayant une configuration destinée à recevoir des requêtes XML du promoteur du site commercial de la toile, et à communiquer une réponse XML au promoteur du site commercial de la toile à la suite d'une requête XML reçue.

9. Système selon la revendication 1, caractérisé en ce qu'il comporte en outre un schéma XML.

10. Procédé destiné à permettre à des promoteurs de sites de la toile utilisant un réseau (20) d'ordinateurs de remettre à jour des informations relatives à un listage de recherche contenu dans une liste de résultats de recherche créée par un moteur de recherche à la suite d'une requête de recherche reçue d'un ordinateur distant par le réseau (20) d'ordinateurs, caractérisé en ce qu'il comprend : la mémorisation d'au moins un enregistrement de compte pour chacun des promoteurs de sites de la toile du réseau (20) d'ordinateurs, l'enregistrement de compte au moins comprenant un identificateur de compte, et au moins un listage de recherche ayant un terme de recherche et une enchère modifiable, l'attribution à un promoteur de sites de la toile d'un accès par enregistrement authentifié, l'accès par

<Desc/Clms Page number 56>

enregistrement du promoteur du site de la toile permettant à ce promoteur de modifier l'enregistrement de compte du promoteur du site de la toile, la réception d'une requête en langage extensible à balises (XML) depuis le promoteur du site de la toile, la modification d' un listage de recherche de l'enregis- trement du compte lors de la réception de la requête XML, la réception d'informations saisies par un utilisateur par l'intermédiaire d'un dispositif de saisie, la recherche de l'enregistrement de compte au moins qui est mémorisé et l'identification d'au moins certains listages de recherche représentant un accord avec les informations saisies par l'utilisateur, et la mise en ordre d'une liste de résultats de recherche des listages de recherche identifiés, l'ordre correspondant aux enchères des listages de recherche.

11. Procédé selon la revendication 10, caractérisé en ce qu'il comporte en outre : la réception de la requête XML provenant du promoteur de site de la toile, et l'analyse syntaxique de la requête XML par rapport à un schéma XML pour l'identification de la requête XML.

12. Procédé selon la revendication 11, caractérisé en ce qu'il comprend en outre la transmission d'une réponse XML au promoteur du site de la toile, confirmant la modification de la liste de recherche.

13. Procédé destiné à permettre la gestion, par des promoteurs de sites de la toile utilisant un réseau (20) d'ordinateurs, d'un listage de recherche contenu dans une liste de résultats de recherche créée par un moteur de recherche à la suite d'une requête de recherche reçue d'un ordinateur distant par le réseau (20) d'ordinateurs, caractérisé en ce qu'il comprend : la mémorisation d'une base de données (38) de comptes ayant au moins un enregistrement de compte pour chacun de plusieurs promoteurs de sites de la toile d'un réseau (20) d'ordinateurs, l'enregistrement de compte au moins comprenant

<Desc/Clms Page number 57>

un identification de compte, et au moins un listage de recherche ayant un terme de recherche et une enchère modifiable, la mémorisation d'un schéma en langage extensible à balises (XML), la réception d'une ou plusieurs requêtes XLM d'un promoteur de sites de la toile pour la gestion d'un ou plusieurs listages de recherche du promoteur du site de la toile, et le traitement de l'enregistrement d'un compte au moins en fonction d'une requête XML.

14. Procédé selon la revendication 13, caractérisé en ce qu'il comporte en outre la transmission d'un état du marché au promoteur du site de la toile en réponse à la requête XML.

15. Procédé selon la revendication 14, caractérisé en ce que la transmission de l'état du marché comprend : le formatage d'une réponse XML comprenant des informations sur l'état du marché, et la communication de la réponse XML au promoteur de sites de la toile.

16. Procédé selon la revendication 13, caractérisé en ce que le traitement d'un enregistrement d'un compte au moins comprend la modification de l'enchère modifiable à la suite de la requête XML.

17. Procédé de gestion de listages de recherche d'un marché en ligne à l'aide d'un ordinateur client (12) capable de communiquer des données à un ordinateur serveur (22) de base de données (38) de comptes du marché en ligne, caractérisé en ce qu'il comprend : à l'ordinateur client (12), le formatage d'une requête en langage extensible à balises (XML) pour l'établissement d'une enchère d'une liste de recherche mémorisée dans le serveur (22) de base de données (38) de comptes, et à l'ordinateur du serveur, la communication de la requête XML au serveur de gestion de comptes du marché en ligne.

<Desc/Clms Page number 58>

18. Procédé selon la revendication 17, caractérisé en ce que le formatage de la requête XML comprend le formatage d'un message XML avec un identificateur de compte associé aux listages de recherche, un identificateur de listages correspondant au listage de recherche, et un comportement voulu des enchères.

19. Procédé selon la revendication 17, caractérisé en ce qu'il comprend la réception d'une réponse XML indiquant la fin satisfaisante de la requête d'établissement d'une enchère.

20. Procédé de gestion de listages de recherche d'un marché en ligne à l'aide d'un ordinateur client (12) échangeant des données avec un ordinateur de serveur (22) de base de données (38) de comptes du marché en ligne, caractérisé en ce qu'il comprend : à l'ordinateur client (12), le formatage d'une requête en langage extensible à balises (XML) pour la réception d'un ensemble d'identificateur de compte correspondant à des comptes associés à l'annonceur et mémorisés dans le serveur (22) de base de données (38) de comptes, et la communication de la requête XML de l'ordinateur client (12) à l'ordinateur du serveur (22) de base de données (38) de comptes du marché en ligne.

21. Procédé selon la revendication 20, caractérisé en ce que le formatage de la requête XML comprend le formatage d'un message XML avec un nom d'utilisateur associé à l'annonceur et une balise XML demandant l'ensemble des identificateurs de comptes associés au nom d'utilisateur.

22. Procédé selon la revendication 21, caractérisé en ce qu'il comprend, à l'ordinateur client (12), la réception d'une réponse XML qui comprend les identificateurs de comptes associés à l'annonceur.

23. Procédé de gestion de listages de recherche d'un marché en ligne à l'aide d'un ordinateur client (12) échangeant des données avec un ordinateur serveur (22) de base de données (38) de comptes du marché en ligne, caractérisé en ce qu'il comprend :

<Desc/Clms Page number 59>

à l'ordinateur client (12), le formatage d'une requête en langage extensible à balises (XML) pour la récupération de l'état du marché en ligne, et la communication de la requête XML de l'ordinateur client (12) à l'ordinateur serveur (22) de base de données (38) de comptes du marché en ligne.

24. Procédé selon la revendication 23, caractérisé en ce que le formatage de la requête XML comprend le formatage d'un message XML avec un identificateur de marché et un terme de recherche.

25. Procédé selon la revendication 24, caractérisé en ce qu'il comprend en outre, à l'ordinateur client (12), la réception, depuis l'ordinateur serveur (22) de base de données (38) de comptes, d'une réponse XML comprenant des informations de listage de recherche provenant d'un ou plusieurs listages de recherche associés aux termes de recherche du marché associé à l'identificateur.

26. Procédé de gestion de listages de recherche d'un marché en ligne à l'aide d'un ordinateur client (12) échangeant des données avec un ordinateur de serveur (22) de base de données (38) de comptes d'un marché en ligne, caractérisé en ce qu'il comprend : le formatage d'une requête en langage extensible à balises (XML) pour la récupération de listages de recherche associés à un annonceur du marché en ligne, et la communication de la requête XML à un serveur de gestion de comptes du marché en ligne.

27. Procédé selon la revendication 26, caractérisé en ce que le formatage de la requête XML comprend le formatage d'un message XML avec un identificateur de compte associé à l'annonceur.

28. Procédé selon la revendication 26, caractérisé en ce que le formatage de la requête XML comprend : au niveau de l'ordinateur client (12), le formatage d'un message XML avec un identificateur de compte associé à l'annonceur et un ou plusieurs éléments choisis parmi un terme de recherche, une enchère spécifiée,

<Desc/Clms Page number 60>

une adresse URL, un titre, et une description.

29. Outil (100) de gestion d'enchères destiné à la gestion de listages de recherche mémorisés dans un serveur de gestion de comptes d'un marché en ligne à partir d'un ordinateur client distant (12), caractérisé en ce qu'il comprend : un premier code de programme lisible par ordinateur et des données agissant sur l'ordinateur client distant (12) qui a une configuration permettant la communication par échange de données avec le serveur de gestion de comptes, le premier code de programme lisible par ordinateur et les données formant un système à menus, et un second code de programme lisible par ordinateur et des données agissant sur l'ordinateur client distant (12), le second code de programme lisible par ordinateur et les données formant une fonction de gestion de listages de recherche coopérant avec le système de menus pour la gestion d'un ou plusieurs listages de recherche en fonction des critères d'un utilisateur, spécifiés par le système de menus.

30. Outil (100) selon la revendication 29, caractérisé en ce qu'il comporte en outre un troisième code de programme lisible par ordinateur et des données qui forment une fonction de mise en place destinée à recevoir les saisies par les utilisateurs spécifiant des identificateurs d'annonceur et des identificateurs de comptes pour la gestion.

31. Outil (100) selon la revendication 29, caractérisé en ce qu'il comprend en outre un quatrième code de programme lisible par ordinateur et des données utilisées pour une fonction de rapport.

32. Ordinateur client (12) destiné à fonctionner en coopération avec un serveur de gestion de comptes d'un marché en ligne, le serveur de gestion de comptes mémorisant des listages de recherche associés à des annonceurs, l'ordinateur client (12) étant caractérisé en ce qu'il comprend : un outil (100) de gestion d'enchères, et

<Desc/Clms Page number 61>

une interface (15) en langage extensible à balises (XML) ayant une configuration permettant la communication de requêtes XML au serveur de gestion de comptes.

33. Ordinateur selon la revendication 32, caractérisé en ce que l'outil (100) de gestion d'enchères comporte : un système de menus, et une fonction de gestion de listages de recherche coopérant avec le système de menus pour la gestion d'un ou plusieurs listages de recherche dans le serveur de gestion de comptes en fonction des critères spécifiés par l'utilisateur par l'intermédiaire du système de menus.

34. Support de mémorisation lisible par ordinateur, caractérisé en ce qu'il comprend : un premier code de programme exécutant un outil (100) de gestion d'enchères pour la gestion de listages de recherche sur un serveur de gestion de comptes d'un marché en ligne, et un second code de programme exécutant une interface en langage extensible à balises (XML) destinée à communiquer avec une interface complémentaire XML du marché en ligne.

35. Support de mémorisation lisible par ordinateur, caractérisé en ce qu'il comprend un code de programme mettant en oeuvre un schéma en langage extensible à balises (XML) utilisé comme référence lors de la communication de requêtes XML d'un ordinateur client (12) agissant dans un marché en ligne à un serveur de gestion de comptes du marché en ligne.