FR2808911A1

FR2808911A1 - Procede et systeme de recherche et de comparaison d'informations sur au moins un produit determine propose sur le reseau internet

Info

Publication number: FR2808911A1
Application number: FR0006170A
Authority: FR
Inventors: Bertrand Jouffroy
Original assignee: INFOMEDIATION
Current assignee: INFOMEDIATION
Priority date: 2000-05-15
Filing date: 2000-05-15
Publication date: 2001-11-16

Abstract

Il s'agit d'un procédé et d'un système de recherche et de comparaison d'informations sur Internet. Un premier fichier de sites ayant été formé et un programme étiquette spécifique ayant été affectée à chacun des sites dudit premier fichier, on saisit, suite à une action d'un utilisateur, au moins un champ de recherche correspondant à un produit déterminé, on recherche sur Internet le ou les sites ayant un programme étiquette, on recherche puis on analyse les pages de chacun desdits sites grâce à son programme étiquette, on en extrait les informations correspondant au produit déterminé recherché, on ajoute ces informations à un deuxième fichier de résultats, dit fichier de résultats, on consolide les informations ainsi obtenues par au moins un critère de consolidation, pour former un troisième fichier de résultats consolidés, on affiche au moins en partie le contenu dudit fichier consolidé sous forme d'un tableau de résultats, et on sélectionne alors le produit.

Description

PROCEDE ET SYSTEME DE RECHERCHE ET DE COMPARAISON D'INFORMATIONS SUR AU MOINS UN PRODUIT DETERMINE PROPOSE SUR LE RESEAU INTERNET
La présente invention concerne un procédé et un système de recherche et de comparaison d'informations sur au moins un produit déterminé répertorié sur au moins un site du réseau Internet.

Elle concerne également un système mettant en #uvre un tel procédé.

Elle trouve une application particulièrement importante bien que non exclusive dans le domaine de la vente en ligne de produits tels que des livres, des CD-ROM ou plus généralement d'articles divers, par exemple dans le domaine de la téléphonie ou de la hi-fi.

On connaît déjà des moteurs de recherche ou des systèmes permettant de rechercher et de trouver des produits sur le réseau Internet.

De tels systèmes nécessitent d'accéder séquentiellement à chacun des sites Internet dans lesquels le mot clé correspondant au produit recherché est apparu, d'en extraire à tout le moins visuellement, les informations le concernant et d'effectuer ensuite un choix entre les différentes informations obtenues pour sélectionner le produit correspondant aux informations considérées comme préférées, par exemple pour sélectionner le meilleur prix.

Ces opérations sont fastidieuses, assez longues et ne donnent pas toujours un résultat fiable ou répétitif, certains sites apparaissant comme pertinents lors d'une première recherche, puis disparaissant lors d'une seconde recherche entreprise à une autre période, et ce de façon aléatoire.

De plus, de telles recherches font apparaître beaucoup d'informations inutiles, surtout lorsque la recherche est mal formulée ou formulée de façon incomplète.

La présente invention vise à fournir un procédé et un système de recherche et de comparaison d'informations répondant mieux que ceux antérieurement connus aux exigences de la pratique, notamment en proposant l'accès aux informations recherchées de façon plus rapide, en temps réel ou sensiblement en temps réel, en limitant les informations non pertinentes et en proposant un affichage permettant une comparaison véritablement efficace.

Dans ce but, la présente invention propose essentiellement un procédé de recherche et de comparaison d'informations sur au moins un produit déterminé répertorié sur au moins un site du réseau Internet, caractérisé en ce que un premier fichier de sites ayant été formé à partir des sites présents sur Internet, et un programme étiquette spécifique (tag) ayant été développé pour

chacun des sites dudit premier fichier, dit fichier de sites, on saisit, suite à une action d'un utilisateur, au moins un champ de recherche correspondant au produit déterminé, par le biais d'un dispositif connecté au réseau Internet , on recherche sur Internet le ou les sites ayant un programme étiquette, on recherche puis on analyse les pages de chacun desdits sites grâce à son programme étiquette, on en extrait les informations correspondant au produit déterminé recherché, on ajoute ces informations à un deuxième fichier de résultats, dit fichier de résultats, on effectue un traitement algorithmique de consolidation sur ce deuxième fichier, pour consolider les informations ainsi obtenues par au moins un critère de consolidation, pour former un troisième fichier de résultats consolidés, dit fichier consolidé, on affiche au moins en partie le contenu dudit fichier consolidé correspondant aux informations sur le produit issues des différents sites, sous forme d'un tableau de résultats, on sélectionne alors le produit à partir dudit tableau, suite à une seconde action de l'utilisateur, et on affiche lesdites informations sur le produit, ses caractéristiques et le site auquel il appartient.

Les pages des sites peuvent être de façon connue en elles-mêmes en HTML, DHTML, XML...

Les programmes étiquettes (ci-après appelés également tags ou custom tags) permettent de retranscrire les requêtes de l'utilisateur dans le mode de réalisation utilisable par le site concerné.

Un tel procédé permet de proposer sur Internet un service très proche de celui qu'obtiendrait un utilisateur s'il avait affaire à une personne physique, comme un libraire par exemple. Tout se passe en effet comme si il y avait utilisation de la mémoire oubliée de l'utilisateur pour l'aider à affiner sa demande avant de lancer la recherche.

Dans des modes de réalisation avantageux on a de plus recours à l'une et/ou à l'autre des dispositions suivantes : - chaque site répondant de plus à au moins un critère d'identification le rattachant à une catégorie spécifique la recherche du ou des sites ayant une étiquette sur Internet s'effectue uniquement parmi les sites appartenant à la ou auxdites catégories spécifiques.

- les sites sont des sites marchands, et l'utilisateur commande de plus directement en ligne le produit sélectionné ; - le procédé comporte de plus une étape de gestion en parallèle des recherches et analyse des pages HTML, agencée pour permettre l'interrogation simultanément ou sensiblement simultanément en temps réel des sites muni d'étiquettes, éventuellement

après sélection complémentaire par critère d'identification ; - le procédé est appliqué à la recherche et à la comparaison du prix de livres et/ou de petits objets.

- le produit étant un livre, on utilise le code ISBN comme critère de consolidation ; on utilise au moins deux critères d'identification du site concerné, comme par exemple un critère lié à une catégorie spécifique de sites (libraire, disquaire, revendeur de matériel électronique, etc.) et la langue ou le pays d'émission.

L'invention propose également un système de recherche et de comparaison d'informations sur au moins un produit déterminé répertorié sur au moins un site du réseau Internet, chaque site comprenant au moins un critère d'identification de la catégorie spécifique à laquelle il appartient, caractérisé en ce qu'il comprend - des moyens de stockage d'un premier fichier de sites formé à partir des sites présents sur Internet, un programme étiquette étant développé pour chacun des sites dudit premier fichier, - un dispositif connecté au réseau Internet , de saisie, suite à une première action d'un utilisateur, d'au moins un champ de recherche correspondant au produit déterminé recherché dans une catégorie de site spécifique, - des moyens de recherche sur Internet du ou des sites ayant un programme étiquette et appartenant à

ladite catégorie de sites spécifique du produit recherché, - des moyens de recherche, de calcul et d'analyse des pages de chaque site grâce à son programme étiquette, des moyens d'extraction des informations correspondant au produit déterminé recherché, - des moyens d'addition de ces informations à un deuxième fichier de résultats, - des moyens de traitement algorithmique de consolidation sur ce deuxième fichier, pour consolider les informations ainsi obtenues par au moins un critère de consolidation, pour former un troisième fichier de résultats consolidés, - des moyens d'affichage d'au moins une partie du contenu de ce troisième fichier correspondant aux informations sur le produit issues des différents sites, sous forme d'un tableau de résultats consolidés, - des moyens de sélection du produit à partir dudit tableau, suite à une seconde action de l'utilisateur, - et des moyens d'affichage des caractéristiques dudit produit, et du site auquel il appartient.

Avantageusement, les sites étant des sites marchands, le système comprend des moyens de commande directement en ligne du produit une fois sélectionné, par exemple sécurisés.

Dans un autre mode de réalisation avantageux le système comprend des moyens permettant l'ajout de nouvelles catégories de produits ou de sites sans

modification des étapes de traitement algorithmique mettant en #uvre le critère de consolidation.

L'invention sera mieux comprise à la lecture de la description des modes de réalisation donnés ci-après à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent dans lesquels :
La figure 1 est un diagramme bloc montrant les principales étapes mises en #uvre dans un mode de réalisation de l'invention.

La figure 2 est une vue schématique du système de recherche et de comparaison mis en #uvre selon l'invention.

La figure 3 est un diagramme bloc montrant les étapes d'un mode de réalisation du procédé selon l'invention, appliqué à la recherche et à la comparaison de prix.

La figure 4 est un diagramme bloc montrant les étapes d'un autre mode de réalisation du procédé selon l'invention.

La figure 5 est un exemple d'affichage d'informations correspondant au procédé selon l'invention.

La figure 1 décrit les étapes principales du procédé de recherche et de comparaison d'informations correspondant à des produits répertoriés sur des sites marchands du réseau Internet.

Les sites ont été préalablement triés et affectés d'étiquettes (ou tags en terminologie anglo-saxonne)

pour constituer de ce fait une liste stockée dans un premier fichier.

L'utilisateur pose sa question en 1 en renseignant un champ de moteur de recherche de façon connue en elle-même.

Cette question est reformatée en 2 et transmise simultanément aux sites marchands faisant partie du fichier de sites.

L'outil logiciel utilisé est par exemple le logiciel vendu sous la dénomination COLD FUSION (marque déposée) de la société américaine ALLAIRE.

Il simule la même requête chez tous les sites marchands étiquetés.

Les réponses (par exemple pages HTML des sites pertinents) sont ensuite rapatriées en 3 où elles sont analysées puis consolidées (étape 4) par le biais d'au moins un critère, ce qui permet de rassembler les informations pertinentes correspondant au produit recherché sous forme d'un tableau stocké dans un second fichier, et ce en évitant les faux amis et/ou les doublons.

Une étape 5 d'affichage d'une présélection de produits est alors effectuée pour permettre à l'utilisateur de sélectionner de façon complémentaire (étape 6) les produits encore pertinents.

On peut à ce stade considérer que l'utilisateur est aidé par le procédé mis en #uvre comme il aurait pu l'être pour une personne physique (un libraire par exemple), pour affiner le choix du produit pour

lequel les informations recherchées sont les plus pertinentes.

L'affichage de la sélection affinée est alors effectué en 7 puis l'utilisateur commande (étape 8) l'affichage (étape 9) de la fiche produit sélectionnée in fine.

Une commande éventuelle peut alors être réalisée de façon connue en elle-même par clicks successifs en 10.

On a représenté sur la figure 2 un système 11 de recherche et de comparaison d'informations sur des produits selon le mode de réalisation de l'invention plus particulièrement décrit ici
Le système 11 comprend un dispositif 12 comprenant un micro-ordinateur 13 muni d'un clavier 14, d'une souris 15 et d'un modem 16 de connexion avec le réseau Internet 17.

Il comporte également connecté au réseau Internet un serveur 18, propriétaire, par exemple comportant une console fabriquée par la société américaine SUN MICROSYSTEM, munie de moyens processeurs (19) de recherche sur Internet des sites à étiquettes correspondant également et par exemple au produit appartenant à une catégorie de site spécifique, - de moyens de stockage du fichier site (20), - de moyens processeurs (19') constitués par un ou plusieurs microprocesseurs, de recherche, de calcul et d'analyse des pages HTML de chaque site ayant une

étiquette, en utilisant un algorithme d'un type qui va être décrit ci-après à titre d'exemple non limitatif - de moyens (19'') d'extraction des informations correspondant au produit recherché, - de moyens (19''') d'addition de ces informations à un deuxième fichier (21) de résultats et de moyens (19') de consolidation sur ce deuxième fichier, pour former un troisième fichier 22 donnant un tableau de résultats consolidés.

Le dispositif 12 comprend par ailleurs des moyens 23 d'affichage du troisième fichier, des moyens de sélection (14,15) du produit à partir du tableau de résultats consolidés et des moyens d'affichage (19, 23) de la fiche produit sélectionnée.

Le système comprend par ailleurs plusieurs sites marchands 24, 25,... comportant de façon connue en elle-même, des ordinateurs 26, 27,... munis de moyens d'interface 28, 29,... connectés au réseau Internet, et de mémoires de masse, de stockage de bases de données 30, 31... mises à jour régulièrement et donnant les informations sur les produits qu'ils répertorient.

On va maintenant décrire en référence aux figures 3,4 et 5 les étapes du procédé de recherche et de comparaison selon le mode de réalisation de l'invention plus particulièrement décrit ici, appliqué à la recherche de livres au meilleur prix.

Dans la suite, on utilisera les mêmes numéros de références pour désigner les mêmes éléments ou étapes. Le langage informatique auquel il est fait référence pour la description est le langage utilisé par la société américaine ALLAIRE pour son programme COLD FUSION (marque déposée), mais tout autre langage peut bien entendu être utilisé.

L'utilisateur met tout d'abord en #uvre la page 40 dite formulaire en utilisant le dispositif 12.

Pour ce faire, il saisit (étape 41) le ou les champs de recherche, en suivant l'instruction affichée sur l'écran de l'ordinateur (42)(voir figure 5) Trouver directement
Il renseigne de ce fait au moins l'un des 3 champs : auteur, titre, ISBN, qui lui sont présentés.

Il utilise ainsi la page formulaire dont l'action est engendrée par une page comparaison.cfm. qui va être précisée par la suite.

Un paramètre requesttimeout (par exemple d'une valeur de 500 secondes), permet avantageusement de fixer un temps d'attente maximum.

Préalablement, et comme on a pu le voir ci-avant, un classement des sites marchands a été effectué, en constituant une table dite WebMarchand , par exemple à partir des critères suivants : # partenaire : classement selon le champ Web~reduction~val. Les partenaires sont les sites marchands qui acceptent de proposer une réduction,

c'est-à-dire dont le paramètre n'est pas nul (table WebMarchand) # nom : classement selon le champ Web~Nom (table WebMarchand) : ordre alphabétique sur le nom du marchand # nationalité : classement selon l'ordre alphabétique du champ Web~nationalite (table WebMarchand) .

Un mode de réalisation de la table WebMarchand est donné ci-après à titre d'exemple non limitatif.

TABLEAU N 1

<tb>
<tb> Web <SEP> March <SEP> and <SEP> Transactions
<tb> Web <SEP> idTEXTE(35) <SEP> Num <SEP> Transadion <SEP> LONG
<tb> Web~nom <SEP> TEXTE(10() <SEP> ID <SEP> Membre <SEP> LONG
<tb>

Wëb~adresse1 TEXTE(200) 1 CE mp Ole LOI'l3 Web~ad-esse2 TEXTE(200) IDVIébMachadTEXTE(35)

<tb>
<tb> Web~op <SEP> TEXTE(20) <SEP> DateTransadion <SEP> DATE
<tb> Web~ville <SEP> TEXTE(50) <SEP> Date <SEP> MAJ <SEP> DATE
<tb> Web~tel <SEP> TEXTE(50) <SEP> NumeroCommandë <SEP> TEXTE(255)
<tb>

Web~fa<TEXTE(50) + Monlart~Hf DOUBLE V\feb~clienl~ad-esse1 TEXTE(20() C)< Description TEXTE(255) V\eb~chenLactesse2 TEXTE(201 RefBarenie TEXTE(255) Web ç6ent TEXTE(2Q Wé d iat ville TEXTE(501 Web cliert teITEXTE(50 0 Wdo~di et fax TEXTE(50)

<tb>
<tb> Web~dient~email <SEP> TEXTE(1 <SEP> OQ <SEP> @
<tb> Web <SEP> riationaide <SEP> LON3 <SEP> Membre
<tb>

Web redudicn %el DOUBLE ############# V\éb - #sai1ion LON3 mem id LON3 V\éb=lJ'1 TEXTE(20C) mEm-nomTE>ÇrE(5q Web Ig Fra1 is BOOL mem~penomTEXTE(5 WdbJg~Andas BOOL mem-emailTEXTF(5q Vlbb~kZESPnoIB00L men Io3mTEXTE(201 WàJ -19 Italien n B ODL me m~pwd TEXTE(2() V\eb=Allem a1d BODL mem~point LONG Web Pai MasterCord B COL mem~cl\lllte TEXTE(5Q Web~P a~Am a-ica1Express BOJL Web Pa DinetsClubBCOL

V\eb~PaL VisaCéJ'd BOJL

<tb>
<tb> Web~Pai~Carte <SEP> Bleue <SEP> BOOL
<tb> Web~Pai~JCB <SEP> BOOL
<tb>

Web~PaLCctinOJa BOJL \Aéb-PaLKargourou BCOL . i Web Pai Aurore BOOL cagone webmardad Web Pà~CebelemB00L Meb IdTexte(35) WàJ~PaU<Ieb()( BOJL c<t Ki Texte(5Q Web Pà~CybeashB00L ordre LON3 Web Pai Milicert BOOL WàJ~PaUJgcash BOJL ############ V\éb~PaLCheqJe BOJL WebYà~CortleRemooursemert BOJL

<tb>
<tb> Web~Pai~Mand <SEP> at <SEP> BOOL
<tb> Web~Pai~Prelevement <SEP> BODL <SEP> Categme
<tb>

Web...f'aYéJ'Viremert BOJL Ca id LONG Web~Pai~EurcCheqJe BOJL Cat P arert id LONG Web Pai~Autre BOOL Cat -libelle Texte(200) V\13 b -Trans-Ileline BOOL Cat DateCrea DATE Web~Trans~Pay(ine BOOL Caï reduc max DOUBLE V\eb- Trans- Teleoommer# BOJL Cat- ncr b m éJ'cl'end LOI'l3 WàJ~Tra1s~SEt BODL WEb Trans a/ box BCOL '###################

<tb>
<tb> Web~Trars~SSL <SEP> B <SEP> OOL
<tb> Web~Trans~SIPS <SEP> BOOL
<tb>

WàJ~Tra1s~C)beIlT1l1 BOJL Bareme Ponts Vlkb Trans BanqJesPqulalre; BOOL WEb -Tra1s- CIC BOJL fl8aemeTexte(255) Vlkb~Trans~Autre BCDL Barème ENT Web -rivr T7elechaigemert BOOL WEb~flVcReais BOOL Web~rlVr~SQJs<l8h BOJL Taix NA

<tb>
<tb> Web~Irvr~Aute <SEP> BOOL
<tb> Web <SEP> com~Fa< <SEP> BOOL <SEP> RefTaux~TVA <SEP> LONG
<tb> Web~com~Tel <SEP> BOOL <SEP> Taux~TVA <SEP> SI <SEP> MPLE
<tb> Web~nom~email <SEP> BOOL
<tb>

Web-Transacton seciid se BOOL

<tb>
<tb> WebJ <SEP> ogin <SEP> TEXTE(30)
<tb> Web~pass <SEP> word <SEP> TEXTE(30)
<tb>

Web~master~nomTEXTE(30) Web~mast er~emaa TE XTE(5C}

<tb>
<tb> Web~valide <SEP> BOOL
<tb> Web~prod <SEP> BOOL
<tb> Web <SEP> Stgjiom <SEP> TEXTE(100)
<tb> Web~Stg~nom <SEP> TE <SEP> TEXTE(200)
<tb>

SUITE TABLEAU N 1

<tb>
<tb> Web <SEP> March <SEP> and
<tb> Web~Stg~nom <SEP> TEXTE(100)
<tb> Web~Stg~adess <SEP> e1 <SEP> TEXTE(200)
<tb> Web~Stg~adess <SEP> e2 <SEP> TEXTE(20()
<tb> Web~Stg~op <SEP> TEXTE <SEP> (20)
<tb>

Web Stg viIIeTEXTE(50t

<tb>
<tb> Web~Stg~tel <SEP> TEXTE <SEP> (50)
<tb>

Web~Stg~fa< TEXTE(50) Web~StLcrlE!nLaetesse1 TEXTE(20Q Web~S)g~c)ient~a<tesse2 TEXTE(200) Web Stg çlient cpTEXTE(20t W~S d ientylle TE XTE(50) Web Stg~cfiert ieITEXTE(50t Vléb~Sf8~diat fcTEXTE(50t

<tb>
<tb> Web~Stg~dient~email <SEP> TEXTE(101
<tb> Web~Stg~nationelrte <SEP> LONG
<tb>

Vléb~S iedudia~v'al DOUBLE WebJS)g~dëscnpt!on LONG Web~Sfc~irl TEXTE(20C)

<tb>
<tb> Web~Stg~Ig~Francais <SEP> BOOL
<tb> Web~Stg~Ig~Anglais <SEP> BOOL
<tb>

Web~Stg~I9...Espnol BCDl

<tb>
<tb> Web~Stg~Ig~Italien <SEP> BOOL
<tb>

Web Stg~ig~AllenadB00L Web~Stg~Pai~MasterCa-d BOOL Web~Sta~Pa~Americ9iExptess BOOL Web Stg~pà Diners(lubBOOL Vb~Stg~Pa!~Eu)DCard BOOS Web S Pai VsaCad BCOL Web~Stg~Pai~CarteHoie BOOL We b~S )g~Pa !~JC B B OOL Wà:J~St!LPai~Cdincga BOOL Vléb~S~Pai KargourouB00L

<tb>
<tb> Web~Stg~Pai~Aurore <SEP> BOOL
<tb>

Web~Stgj' a~Cetelem BOOl

<tb>
<tb> Web~Stg~Pai~Klebox <SEP> BOOL
<tb> Web~Stg~Pai~Cybercash <SEP> BOOL
<tb>

W~Stg~Pai~Milicert BOCL Mb Slg Pa gcash B COL Web Stg~Pai CheéB00L '~'########## Web~Slgj'éi~CortIeRan roursemert BCDl MYS Web~Stg~Pa~Mandat BOOL tcuspays id LONG Wéo~5tg~Pai~Prelevemert BOOL touspays nomTEXTE(35) Web~Stg~Pa~Par\/iremeftBOOL #############

<tb>
<tb> Web~Stg~Pai~EuroCheque <SEP> BOOL
<tb>

Wà:J~St!LPai~Auve BCDl Web~S Trans~MelineBOOL fcivilite Wà:J SI!L Trars Pa}4ine B CDl ########### Web S Trans TeleoommeraeB00L AbrariatonTexte(259 Wé~5-Tras Sé BOOL Cil.1lile Te)(IE255) Wëb~S(g~Trais~Paybo< BOOL '############

<tb>
<tb> Wëb~Stg~Trans~SSL <SEP> BOOL
<tb>

Web~S<g~Trans~S)PSBOOL \ll.eb~Stg~Tr s~CellnLt BCDl Admin Web Stg Ttans Bar)(uesPcpu!a!resBOOL adm~id LOt13 V*b "Sfe -Trans"01C BOOL a mWeb-SIg- Tlans- Auve BOOL Iogin TeJde(3Q \ll.eb'=-SlgJivr:.. TeiedJaigemert BOOL Passwrd Texte(3q Wé~Stg livr Rdais BOOL Web Stg~livr Sous48h BOOL Vlkb Stg livr Aute BOOL <###########.############## Web~St3~com~F3< BOOL WebAvantages Datde mcdifica5on - bzz Vb Stg #m TeiBOOL .,.....##. de la base courante Vlkb~5-com~email B OOL M afele physlq.e de la base courante Véb~5-Transaction sewseB00L Web Stg I agin TEXTE(30 Vlkb~S~pswQdTEXTE(3A SQLsener70 Rév 0 Auteur rcatderan Web Stg masfer~nomTEXTE(3g 1 Wtjb~Stq~maEter~emai)TEXrE(5C) l'-brndefictier' WAPhys Entreprise Web~tag TE XT-E(5() ~~~~~~~~~~~~~~~~ WphA.nh,,p

<tb>
<tb> Web~photo <SEP> BOOL
<tb>

Une étape de recherche 43, dans la page dite de consolidation 44 des sites marchands est ensuite réalisée, ces derniers étant étiquetés et classés en catégories.

Puis une étape 45 de sélection des sites marchands étiquetés est effectuée.

Pour ce faire, on recharge la page (par la fonction javascript changer()) en passant en paramètre un nom correspondant à la catégorie cochée. La liste des sites affichés est alors actualisée suivant ce paramètre.

Par exemple # Pour la nationalité française : le paramètre est Nfrancaise, qui correspond à : Web Nationalite est l'ID de la France dans la table Pays .

# Avec sites en français : le paramètre est
LFrancais, qui correspond à : Web~lg~Francais est vrai dans la table WebMarchand .

# Avec paiement sécurisé : paramètre est
TSecurise, qui correspond à : Web Transaction securise est vrai dans la table
WebMarchand .

# Avec paiement par chèque : le paramètre est
PCheque, qui correspond à : Web~Pai~Cheque est vrai dans la table WebMarchand .

L'actualisation est faite dans la requête Tri Web Marchand.

Les étapes suivantes sont les étapes d'appel et d'interrogation 46 des sites marchands étiquetés.

Ces étapes constituent le début d'une boucle 47 consistant à récupérer les résultats des sites affectés avantageusement d'un ou plusieurs programmes étiquettes, (également parfois appelés ci-après custom tags ).

Pour ce faire, on identifie l'ensemble des Custom tags correspondant à un site marchand.

On retire de l'ensemble les sites correspondant aux programmes étiquettes ayant renvoyé une erreur (si le site correspondant est arrêté par exemple), et on conserve les tableaux 48 renvoyés par les pages 49 de sites étiquetés, remplissant les critères de sélection du produit (étape 50), en passant par l'affichage 51 des pages HTML, et leur analyse 52.

Dans le mode de réalisation plus particulièrement décrit ici à titre d'exemple, on recherche ainsi tous les custom tags de la base de données (champ Web~tag de la table webmarchand) grâce à la requête LWeb. Ces étiquettes sont alors stockées dans un tableau liste erreur.

Pour chacun de ces sites, il y a alors essai d'appel de l'étiquette trouvée. Si ce n'est pas possible, le site marchand correspondant est retiré de la liste liste erreur.

La méthode de test de l'existence des custom tags est donc d'essayer de les appeler, et de

capturer l'erreur si c'est impossible d'obtenir une réponse positive (tag <cftry>/<cfcatch>).

Un ajout dans le tableau 48 est alors réalisé (étape 53) avant l'étape de consolidation 54 des résultats ici en utilisant le numéro ISBN du livre recherché pour éliminer les faux amis ou doublons.

En d'autres termes, les tableaux récupérés des custom tags sont croisés dans un tableau commun, puis triés par numéro ISBN pour former le tableau consolidé ou tableau resultat~tab,. En même temps que les tableaux récupérés sont consolidés, on compte le nombre de produits trouvés, qui constitue également le nombre de lignes dudit tableau consolidé.

Le tri du tableau Resultat~tab ou tableau consolidé 55 autorise une présentation des lignes du tableau correspondant au même produit à la suite les unes des autres.

Le tableau trié est ensuite transformé en résultat de requête (de nom consolidation) grâce au custom tag queryNew qui, à partir d'un tableau en entrée renvoie un résultat similaire à celui renvoyé par une requête SQL.

Une page XML correspondant au tableau consolidé (tag CFWDDX) est ainsi générée, et va permettre le passage à la page 56 de comparaison. Cette page XML n'est pas utilisée pour la page de consolidation 44, mais sert uniquement pour le passage des données en vue de leur affichage.

L'étape suivante est en effet l'étape 57 d'affichage.

Plus précisément et pour afficher les données, on groupe le résultat de consolidation comme pour une requête SQL sur le critère ISBN : cela retire de consolidation les lignes qui suivent celle dont le numéro ISBN est différent de la ligne précédente. Les numéros ISBN sont alors uniques dans consolidation.

Enfin, on réalise l'étape 58 d'appel de la page de comparaison, ce qui autorise la sélection par l'utilisateur.

Lorsque ce dernier choisit un produit, la fonction envoi est appelée. Elle reçoit en paramètres le numéro ISBN, le nom du livre et l'auteur.

Cette fonction envoi soumet alors un formulaire caché (placé juste après le <body> de la page) avec les données reçues et la catégorie du site correspondant aux produits recherchés ( ici librairie). Ce formulaire appelle la page comparaison.cfm pour la mise en oeuvre de l'étape de comparaison et qui va maintenant être détaillée encore plus précisément.

# appel
La page reçoit en paramètres la catégorie du produit, le numéro ISBN, l'auteur et le titre, ainsi que la page XML générée.

# classement et sélection des sites :
Le fonctionnement est exactement le même que pour la page formulaire (annuaire/home.cfm), à la

différence près qu'à chaque rechargement de la page les paramètres ISBN, catégorie, titre, auteur et XML sont également passés en paramètres.

# structuration des informations
Le tableau XML reçu (champ) est transformé en tableau consolidation, toujours avec le tag CFWDDX.

Il est agrégé avec les informations de la base de données dans le tableau consolidationI. en joignant sur le champ site qui correspond au web~tag de la table webmarchand.

Les colonnes correspondant à la base de données sont générées par la requête imarchand, et les colonnes correspondant aux informations produit (ISBN, etc...) sont générées grâce à l'instruction queryAddRow. La requête est au préalable groupée sur l'ISBN comme dans la phase de consolidation.

# affichage
On trie ensuite les résultats de consolidationI suivant le mode choisi (custom tag cf~sortquery). Le résultat est alors mis dans comparaisonT.

On boucle ensuite sur la tableau comparai sonT, (tag CFOUTPUT), et on affiche chacune des colonnes de ce résultat de requête.

# Lien " acheter "
Suivant le type de marchand choisi (avec ou sans réduction), on passe des paramètres différents au fichier identification.cfm.

Si réduction : partenaire=yes
Sinon : partenaire=no

Dans les 2 cas, les paramètres suivants sont également envoyés en URL : LienFiche, cat (catégorie), webid (nom du web marchand).

Dans certains cas, des sites marchands privilégiés, qualifiés de Partenaire, sont en effet prévus et il convient (étape 59) de vérifier leur caractère.

Ces sites proposent par exemple des réductions.

Auquel cas, on affiche une page d'identification, puis on envoie vers la page LienFiche passée en paramètre.

Dans le cas où il n'y a pas de réduction, on n'affiche pas ce formulaire, et on propose toujours le lien vers la fiche produit 60.

Le figure 4 montre les étapes d'un autre mode de réalisation du procédé selon l'invention mettant en scène l'essentiel des étapes décrites en référence à la figure 3, parmi lesquelles un cycle 61 de gestion d'appel parallèle est par ailleurs ajouté.

Pour limiter encore la durée de la recherche, les appels aux custom tags étant normalement séquentiels, par exemple en mettant en oeuvre une boucle CF. dans la page consolidation.cfm , un mode avantageux de l'invention propose en effet de paralléliser les appels custom tags des sites du réseau.

Une telle parallélisation s'effectue par l'intermédiaire d'un objet DCOM intitulé objets WebAvantage. Parallel .

Il s'agit ici plus précisément d'un objet MultiThread qui a pour but de paralléliser les appels Custom~Tag et qui comprend six propriétés et une méthode (Cf. référence 62).

Les propriétés sont - intTimeOut : le timeout passé par la page précédente.

- stHostRoutage : le serveur hébergeur de la page routage.cfm - stPortRoutage : le port du serveur hébergeur de la page routage.cfm - stURLRoutage : l'URL de la page de routage.cfm - stURLList : Un paquet XML de la liste des Hosts, des ports et des pages Custom~Tag.

Plus précisément il y a deux colonnes dans la liste, Racine et Page :
Racine : c'est l'URL racine des custom tags, ex ; /webavantages/custom~tags Page : le répertoire et le nom de Tags ex ; /alapage/alapage.cfm - stAttribut : Un paquet XML contient la liste des Meta~Champs de recherche associé à la catégorie recherchée.

Il va être revenu ci-après sur le concept de Mata~Champs.

# stResult : C'est le résultat des appels des pages Custom~Tag en format paquet XML .

# La méthode est Start () : C'est le méthode qui déclenche les appels parallèles. Elle correspond

à des instructions classiques en langage SCOLL
FUSION.

En référence à la figure 3, on notera que la page formulaire.cfm 40 reste inchangée.

Par contre la page de consolidation peut maintenant être détaillée.

Initialisation de l'objet DCOM 70
1. Rechercher tous les tags (étape 63), de la catégorie et la nationalité recherchée, de la base de données (champ Web~tag de la table webmarchand) grâce à la requête LWeb. Ces tags sont stockés dans le tableau liste erreur.

2. Construire une liste (62) pour tous les Hosts et tous les WebTags des WebMarchand, ensuite, sérialiser la liste en paquet XML, stURLList.

La liste stURLList contient ;
Racine
URL
3. Définir la liste des champs de recherche à passer aux custom tags , c'est à dire ceux dont le champ MetaChamp~Recherche de la table Meta~Champs vaut Vrai, bien sur de la catégorie recherchée.

<cfloop query= "QlisteChamps"> <cfset resultat = StructInsert(lesParametres,

MetaChamp~nom, evaluate(MetaChamp nom))> </cfloop> <cfset resultat = StructInsert(lesParametres,

"RequestTimeOut", #Trim(url.RequestTime0ut)#

<cfset résultat = Structlnsert(IesParametres, "limi te", #Trim (limi te) #) > <cfset resultat = Structlnsert(lesParametres, "cat", #Trim(url.cat)#
4. Sérialiser la structure du paquet XML, xmlAttribut.

5. Initialiser l'objet DCOM avec <cfobject type="COM" name="objParallel"

class= "WebAvantage. Parallel" action="CREATE">
6. Définir ces paramètres : intTimeOut . Le timeout passé par la page formulaire.cfm. stURLList : Un paquet XML de la liste des URLs des Custom Tags. stAttribut : Un paquet XML des champs recherchés.

7. Exécuter la fonction Start() de l'objet.

<cfset tampon = objPara11e1 . Start () >, la variable tampon n'est pas utilisée.

Récupération des résultats des customs tags :
Les résultats des tags (64) sont retournés en format " paquet XML " dans la propriété stResultat de l'objet DCOM.

Le contenu du paquet XML (65) renvoyé par l'objet DCOM est une liste, chaque ligne dans la liste se compose de : PAGE . le chemin de la page Tag passé.

BODY : le résultat retourné par le Tag se forme de paquet XML.

ERRORCODE* . deux valeurs possibles :

-1 ; le résultat du Tag est erroné à cause de TimeOut.

Le code erreur retourné par la page Tag.

ERRORDESC* : la description d'erreur, deux valeurs possibles :
Une chaîne " Erreur fatale pour le cas d'erreur ERRORCODE=-1.

La description d'erreur retournée par la page Tag.

Exemple .

<xml> <TAG> <PAGE>xxxxxx< /PAGE> <BODY><paquet XML></BODY> <ERRORCODE>0123</ERRORCODE> <ERRORDESC>Description d'Erreur</ERRORDESC> </TAG> </xml>
Désérialiser les paquets XML et retirer l'ensemble des lignes ayant renvoyé une erreur ou un résultat vide.

Le contenu du <paquet XML> du tag <BODY> détermine l'état de la ligne :
Un tableau : résultat de Tag.

Pas de résultat.

Erreur.

Désérialiser le paquet XML de <BODY> :
La page routage.cfm (80) retourne un paquet XML (64) , ce paquet est retourné par l'objet DCOM dans un autre paquet XML (65) dans le tag <BODY>.

Déserialiser le paquet, avec (tag cfwddx), peut donner trois valeurs :
Soit un tableau qui représente le résultat de Custom Tag ;
Soit une chaîne qui représente le retour vide de la recherche sur le site ;
Soit une chaîne qui représente le retour d'erreur du Tag.

Gestion des données (66) renvoyées par les custom tags 90 :
Il n'y a presque rien à changer dans cette partie.

Les tableaux récupérés des custom tags, par l'intermédiaire du paquet XML dans le tag <BODY>, doivent simplement être adaptés à l'utilisation dans cette page.

Les étapes de passage des paramètres 46 d'affichage 57 et croisement des résultats, et d'appel de la page de comparaison 58 restent inchangées par rapport à celles de la figure 3.

On a représenté ci-après sous la forme du tableau N 2 la description de la page routage.cfm 80.

Page <SEP> de <SEP> Routage <SEP> Lot <SEP> n 1
<tb> F
<tb> Routage <SEP> 0
<tb> Contenu <SEP> Un <SEP> paquet <SEP> xml, <SEP> le <SEP> résultat <SEP> d'appel <SEP> du <SEP> Custom <SEP> Tag.
<tb>

Cette <SEP> page <SEP> est <SEP> appelée <SEP> par <SEP> l'objet <SEP> DCOM <SEP> "webAvantage",
<tb> celui <SEP> ci <SEP> est <SEP> défini <SEP> dans <SEP> la <SEP> page <SEP> consolidation.cfm.
<tb>

# <SEP> Les <SEP> fonctionnalités <SEP> de <SEP> cette <SEP> page <SEP> sont <SEP> : <SEP>
<tb> 1. <SEP> Exécuter <SEP> les <SEP> appels <SEP> des <SEP> Custom <SEP> Tags <SEP> passés <SEP> par <SEP> l'objet
<tb> DCOM.
<tb>

2. <SEP> Récupérer <SEP> et <SEP> traiter <SEP> les <SEP> résultats <SEP> des <SEP> tags.
<tb>

3. <SEP> Retourner <SEP> les <SEP> résultats <SEP> sérialiser <SEP> dans <SEP> un <SEP> paquet <SEP> XML
<tb> pour <SEP> l'objet <SEP> DCOM
<tb> # <SEP> Les <SEP> entrés <SEP> URLs <SEP> de <SEP> la <SEP> page <SEP> sont <SEP> : <SEP>
<tb> 1. <SEP> Racine <SEP> : <SEP> le <SEP> chemin <SEP> racine <SEP> du <SEP> Tag
<tb> 2. <SEP> Page <SEP> : <SEP> le <SEP> chemin <SEP> de <SEP> la <SEP> page <SEP> Custom <SEP> Tag <SEP> en <SEP> question.
<tb>

3. <SEP> Attribut <SEP> : <SEP> un <SEP> paquet <SEP> XML <SEP> contient <SEP> les <SEP> attributs <SEP> à <SEP> passer
<tb> au <SEP> tag <SEP> (dans <SEP> le <SEP> tag <SEP> CFMODULE).
<tb>

# <SEP> La <SEP> sortie <SEP> de <SEP> la <SEP> page <SEP> : <SEP>
<tb> Retourner <SEP> un <SEP> paquet <SEP> XML <SEP> à <SEP> l'objet <SEP> DCOM <SEP> contient <SEP> une <SEP> des
<tb> valeurs <SEP> suivantes <SEP> : <SEP>
<tb> 1. <SEP> Un <SEP> tableau <SEP> : <SEP> si <SEP> le <SEP> résultat <SEP> de <SEP> recherche <SEP> du <SEP> tag <SEP> est
<tb> positif.
<tb>

2. <SEP> Une <SEP> chaîne <SEP> "vide" <SEP> si <SEP> le <SEP> résultat <SEP> de <SEP> recherche <SEP> est <SEP> vide
<tb> 3. <SEP> Une <SEP> chaîne <SEP> "erreur" <SEP> dans <SEP> le <SEP> cas <SEP> d'erreur.
<tb>

La <SEP> structure <SEP> du <SEP> paquet <SEP> XML
<tb> <xml>
<tb> <BODY>
<tb> soit <SEP> le <SEP> résultat <SEP> du <SEP> tag
<tb> soit <SEP> vide
<tb> soit <SEP> erreur
<tb> </BODY>
<tb> </xml>
<tb> # <SEP> Les <SEP> traitements <SEP> : <SEP>
<tb> 1. <SEP> Construire <SEP> la <SEP> strTemplate <SEP> à <SEP> partir <SEP> de <SEP> url.Host,
<tb> url.Port <SEP> et <SEP> url.Page
<tb> 2. <SEP> Désérialiser <SEP> le <SEP> paquet <SEP> XML <SEP> des <SEP> attributs <SEP> dans
<tb> strAttribut
<tb> <cfwddx <SEP> action="WDDX2CFML"
<tb> input="#url.Attribut#" <SEP> output="strAttribut">
<tb> 3. <SEP> Appeler <SEP> le <SEP> Custom <SEP> Tag <SEP> en <SEP> question, <SEP> le <SEP> tag <SEP> CFMODULE.
<tb>

<cfmodule <SEP> template="#strTemplate#"
<tb> attributecollection=#strAttribut#>
<tb> 4. <SEP> Construire <SEP> et <SEP> sérialiser <SEP> le <SEP> paquet <SEP> XML <SEP> à <SEP> retourner <SEP> en
<tb> fonction <SEP> de <SEP> résultat <SEP> du <SEP> Tag.
<tb>

~~~~~~ <SEP> 5. <SEP> Afficher <SEP> le <SEP> paquet <SEP> XML <SEP> dans <SEP> le <SEP> BODY
<tb>
TABLEAU N 2

Dans un mode de réalisation avantageux de l'invention, il est prévu des moyens permettant l'ajout de nouvelles catégories de produit ou de sites correspondant à ces produits sans modifier en rien le code des pages de consolidation et de comparaison.

Pour ce faire, il est créé un Méta-Schéma c'est-àdire que l'on rend la notion de catégorie. Ce MétaSchéma est contenu dans la base de données relationnelle du site WebAvantages placé dans le serveur 11 du système selon l'invention.

Sont ainsi définies des Méta-Données, à savoir, Pour chaque catégorie : - noms des champs à rapatrier, - ordre d'affichage de ces champs dans la page de consolidation, - largeur de chacune des colonnes du tableau de consolidation, - champ(s) sur lesquels on consolide, - image titre de la page de consolidation, - noms des champs de recherche (éventuellement : on peut générer la page de saisie des champs de recherche), - taille maximum de ces champs, - taille affichée de ces champs, - ordre d'affichage de ces champs de recherche (si on génère la page de recherche), - type de chacun de ces champs de recherche (checkbox, texte, liste déroulante, radio button), et

éventuellement la liste d'items associés, et la valeur par défaut.

- phrase d'introduction dépendante de la catégorie dans la page de recherche, - choix des champs affichés sur la page de comparaison : attention, il ne sera pas possible par ce moyen de générer des pages de comparaison de présentation différente suivant les catégories. Le tableau récapitulatif de bas de page est indépendant de la catégorie, - ordre des champs affichés sur la page de comparaison.

Remarque : il aurait aussi été possible d'ajouter des champs à la table Categorie sans créer la table MetaCategorie.

Un mode de réalisation du Schéma relationnel des Méta-Données est décrit ci-après en référence au tableau suivant :

<tb>
<tb> MetaCategone <SEP> MetaLibelle
<tb> MetaCat <SEP> ID <SEP> LONG <SEP> MetaLibelle <SEP> ID <SEP> LONG
<tb>

MetaCat~imageConsolidation TEXTE(255) MetaLibelle libelle TEXTE(255) MetaCat~phraselntro TEXTE(255) MetaLibelle Ordre LONG MetaCat~fiche~custom BOOL MetaLibelle~MetaChamp ID LONG (IE)

<tb>
<tb> Meta~Libelle-vide <SEP> BOOL
<tb> a <SEP> pour <SEP> champs <SEP> @
<tb>
<tb> MetaChamp
<tb> MetaChamp <SEP> ID <SEP> LONG <SEP>
<tb> MetaChamp~nom <SEP> TEXTE(100)
<tb> MetaChamp <SEP> ordreCons <SEP> INT <SEP> (IE)
<tb>

MetaChamp IargeurCons LONG a pour liste croptioris

<tb>
<tb> MetaChamp~consolide <SEP> BOOL <SEP> (IE)
<tb> MetaChamp~recherche <SEP> BOOL <SEP> (IE)
<tb> MetaChamp~rechercheTailleMax <SEP> LONG
<tb>

MetaChamp rechercheTaineAfîMax LONG Méta Schéma Date de modification 26/03/00

<tb>
<tb> MetaChamp~rechercheOrdre <SEP> LONG <SEP> (IE) <SEP> ocnema <SEP> 11 <SEP> 29 <SEP> 45
<tb> MetaChamp~rechercheType <SEP> INT <SEP> Modifications <SEP> de <SEP> la <SEP> base <SEP> de <SEP> données <SEP> pour <SEP> gérer <SEP> le <SEP> Méta-Schéma
<tb> MetaChamp~rechercheDefaut <SEP> TEXTE(50)
<tb> MetaChamp~comparaison <SEP> BOOL <SEP> (IE)
<tb>

,# MetaChamp comparaisonOrdre LONG (lE) ############!#######!############### MetaChamp=MetaCat~ID LONG (lE) (IE) SQL server 7 Rév 0 Auteur ncauderan MetaChamp rntemeOrdre LONG (IE) metasche 1ma Entreprise WebAÏntages MeîSreTINT0"0 Nomdefichler metaschema Entrepnse WebAvantages TABLEAU N 3

Description de cette architecture MetaCategorie # MetaCat~ID: ID de la catégorie correspondant à cette MetaCategorie.

# MetaCat~imageConsolidation: nom complet de l'image titre de la page de consolidation

#MetaCathraselntro . Texte complet de la phrase d'introduction de la recherche # MetaCat~fiche~custom: champ bit indiquant si cette catégorie de produit offre une fiche de présentation spécifique pour la page comparaison.cfm. Si ce champ est VRAI, la page de comparaison va inclure la fiche qui se trouve dans

fiche~custom/fiche#MetaCat~ID#. Sinon, elle utilise la fiche modele fiche~generique.cfm MetaChamp Un MetaChamp est lié à une et une seule Me taCa tegori e .

# MetaChamp~ID : ID automatique d'un MetaChamp # MetaChamp~nom : libellé du MetaChamp # MetaChamp~ordreCons : numéro d'ordre de ce champ pour l'affichage du tableau de consolidation. Si sa valeur est 0, alors ce champ n'apparaît pas dans le tableau récapitulatif de consolidation. Si sa valeur est non nulle, il correspond au numéro de la colonne HTML du tableau de consolidation.

# MetaChamp~largeurCons : largeur de la colonne du tableau HTML de consolidation correspondant à ce champ. Cette valeur n'a de sens que si MetaChamp~ordreCons est non nul.

# MetaChamp~consolide : champ bit indiquant si ce champ fait partie de la clé pour cette catégorie de produit. Dans le cas des livres, seul le
MetaChamp ISBN aurait ce bit à VRAI. Il est tout à fait possible que plusieurs champs fassent partie de la clé, auquel cas c'est la concaténation de ces champs qui identifie le produit.

#MetaChanp rechercheTaiJJeAffMax : Taille maximum indiquant la largeur du champ de recherche dans le formulaire de recherche. Cette valeur n'est utilisée que si la valeur MetaChamp~rechercheType correspond à un champ texte. Cela correspond au champ size du champ text .

# MetaChamp~rechercheTailleMax correspond soit à un champ texte, soit à une liste à choix multiples. Dans le premier cas, cela correspond au champ MAXLENGTH du champ text et dans le second au nombre maximum d'items sélectionnables dans la liste à choix multiples.

# MetaChamp~rechercheOrdre : Ordre d'affichage des différents champs dans la page de recherche. Si MetaChamp~rechercheOrdre vaut 0, alors ce champ n'est pas affiché dans la page de recherche.

# MetaChamp~rechercheType: indicateur du type de champ de recherche. Ce champ n'est utilisé que si

MetaChamp~rechercheOrdre est différent de 0, sinon sa valeur est indéterminée.

Ce champ peut prendre les valeurs suivantes : # 1 : champ texte # 2 : champ liste # 3 : case à cocher # 4 : radio bouton # 5 : champ liste à choix multiple (ce type n'est plus pris en compte pour le moment) # MetaChamp~rechercheDefaut : Valeur par défaut du champ, c'est à dire valeur pré-remplie dans le formulaire de recherche. Ce peut être : ./ La valeur d'un champ texte # L'item sélectionné d'une liste déroulante ou d'une liste de boutons radio # MetaChamp~comparaison: flag indiquant si le
MetaChamp est affiché dans la page de comparaison des prix # MetaChamp~comparaison~ordre: dans le cas ou
MetaChamp-comparaison est VRAI, ce champ indique l'ordre d'affichage dans la page de comparaison.

# MetaChamp~MetaCat~ID : clé externe # MetaChamp~interneOrdre : Pour chaque champs ramené par les custom tags, indique le numéro de la colonne correspondant à ce champs dans le tableau ramené par chaque custom tag.

# MetaChamp~enteteCons: dans le cas où MetaChamp~ordreCons est non nul, ce champ indique

l'ordre d'affichage en entête du tableau de consolidation. Dans le cas des livres, Titre et
Auteur ont les valeurs " 1 " et " 2 ". Si ce champ est nul, il n'apparaît pas en entête du tableau.

MetaLibelle Cette table contient les différents libellés associés à un MetaChamp. Pour une liste déroulante, ce sera la liste des items, pour des boutons radio, les libellés associés à ces boutons radio etc.

# MetaLibelle~ID : clé primaire

#Met:aLijbe.He~2ijbe2Ie : libellé en clair # MetaLibelle~ordre : ordre d'affichage # MetaLibelle~MetaChamp~ID : clé externe # MetaLibelle vide . dans le cas d'une liste à choix simple : libellé en cas de sélection de l'item correspondant à " aucun choix ".

On a décrit ci-après les modifications du code entre les deux modes de réalisation de pages de recherche (annuaire/home.cfm) décrits ci-avant, c'est-à-dire le cas où le Méta-Schéma est mis en #uvre par rapport à celle où elle n'est pas mise en #uvre.

Les modifications de cette page sont les suivantes : - la phrase d'introduction. La phrase : Entrez un ou plusieurs des éléments suivants pour trouver le livre que vous cherchez, au meilleur prix est remplacée par le champs CHAMP~INTRO,

- La génération dynamique des champs de recherche.
Ici les champs auteur, titre, ISBN ne sont donc plus codés en dur. Au lieu de cela, on boucle sur les champs liés à la table METACATEGORIE suivant l'ordre ORDRE~RECHERCHE de la table METACHAMPS, et on affiche les champs dont le champs ORDRE~RECHERCHE est différent de 0.

Les pages (annuaire/intermediaire.cfm), intermédiaires de recherche sont identiques.

La page (annuaire/consolidation.cfm) de consolidation prévoit quant à elle les opérations suivantes :
Récupération des champs de recherche
L'appel à la page de consolidation est l'action du " form " de la page annuaire/intermédiaire.cfm. Les paramètres reçus sont les suivants : - RequestTimeout . temps maximum pour un appel à un custom tag (500 secondes actuellement par défaut) - Cat . ID de la catégorie - Form.* : les champs de recherche de la catégorie cat
Récupération des champs à passer aux custom tags
Les champs à passer aux custom tags sont les champs de recherche, c'est-à-dire ceux dont le champ MetaChamp~recherche de la table MetaChamp vaut VRAI. Ces MetaChamps sont récupérés de la base décrite en référence aux tableaux n 1 ou 3 et mis dans une liste listeChamps.

Vérification des champs absents
Les champs RequestTimeout et cat sont toujours passés.

Pour les champs Form.* (issus de la pageintermediaire.cfm) ; ces champs sont toujours définis ici, même si l'utilisateur ne les a pas sélectionnés (à l'exception notable des checkbox, et des listes à choix multiples sans élément sélectionné).

Donc pour les champs checkbox ou liste à choix multiple, il faut écrire un CFPARAM pour ces champs avec une valeur de "".

L'algorithme est le suivant :
ListeMetaChamps = liste des MetaChamps de recherche associés à la catégorie cat
Pour chaque élément leMetaChamp de ListeMetaChamps
Si le rechercheType de ce MetaChamp est checkbox ou Liste à choix multiple alors
Générer le tag CFPARAM correspondant au nom de ce MetaChamp
Fin Si
Fin Pour
Recherche des custom tags
Selon la première méthode, la recherche de custom tags se fait de la façon suivante : <cfquery name="LWeb" datasource="#DataSourceName#"> SELECT
W.web~tag FROM WebMarchand as W,categorie~webmarchand as WC where

W. web id=WC. weh id

and WC.cat-id='#Trim(url.cat)#' and web~prod=l </cfquery>
Avec la seconde méthode, il suffit uniquement d'ajouter :
And web~tag <>" "
Appel des custom tags
Tous les appels des custom tags sont à modifier pour prendre en compte le méta-schéma. Avec la première méthode, l'appel aux différents custom tags se fait de la façon suivante :

<cfmodule template="../custom tags/#ind#/#ind#.cfm' mode=#Trim (mode) # type=#Trim(type) # auteur=#Trim (auteur) # ti tre=#Trim (ti tre) isbn=#Trim(isbn) #

limi te=#Trim (limite) # >
Avec cette technique, il est impossible de passer des paramètres dépendants de la catégorie recherchée.

Seules les valeurs des paramètres passés sont en effet dynamiques. Avec la seconde méthode, les noms des paramètres deviennent également dynamiques. Pour cela, les custom tags sont appelés en utilisant l'attribut particulier attributecollection.

L'ajout des champs de recherche se fait de la façon suivante : <cfset lesParametres =StructNew()>

<cfset resultat=Structlnsert (lesParametres, leChamp, evaluate (leChamp))> </cfloop>
Il faut ensuite également ajouter de la même façon les champs limite, RequestTimeOut et cat.

L'appel à chaque custom tag se fait de la façon suivante :

<cfmodule template="../custom~tags/#ind#/#ind#.cfm" attributecollection=#lesParametres#>
Avec cette technique, il n'y a donc presque rien à changer dans les custom tags eux-mêmes.

L'attribut attributecollection est automatiquement transformé en une liste de paramètres comme si ceuxci étaient directement passés.

Les types de recherche sont alors définis dans les custom tags eux-mêmes sont alors définis. Au lieu de passer le type de recherche au module (titre, auteur, titreauteur, isbn), les champs étant dynamiques, c'est à l'intérieur du custom tag (statique) qu'on particularise le type.

Chaque custom tag correspond pour l'instant à un webmarchand particulier. Or un webmarchand peut comprendre plusieurs catégories.

Un paramètre " mode " étant passé au custom tag pour spécifier que la requête concernait les livres, avec la seconde méthode c'est en utilisant le paramètre " cat " (catégorie) passé au module qu'on distinguera les différents traitements.

La gestion des données renvoyées par les custom tags est effectuée selon la première méthode en utilisant le code indiqué en annexe 1.

Ce code cependant est très dépendant de la catégorie utilisée.

Pour y remédier, la seconde méthode propose l'algorithme suivant :
ListeChamps = Selection des noms des champs ramenés par les custom tags de cette catégorie suivant l'ordre Me taChamp~interneOrdre
Clé = Selection des noms des champs ramenés par les custom tags de cette catégorie ayant la propriété MetaChamp~consolide VRAIE.

Pour chaque site SITETAG ayant un custom tag
Ordre = ordre associé à ce site pour cette catégorie
Pour chaque ligne de résultat renvoyée par SITETAG
Insérer dans le tableau de résultat les colonnes
Clé,ordre,ListeChamps,SITETAG
Fin Pour
Fin Pour
Transformation des données en requêtes
La transformation du tableau de résultat avec la première méthode utilise le code indiqué en annexe 2.

Pour rendre ce code indépendant de la catégorie, la seconde méthode propose l'algorithme suivant :

consolida tion=QueryNew ("Si te, cle" & ListeChamps)
Pour chaque ligne LIGNETABLEAU du tableau de résultats
Créer une nouvelle ligne dans la requête de consolidation
Dans la première colonne de la requête, insérer la colonne site de LIGNETABLEAU
Dans la seconde colonne de la requête, insérer la colonne cle de LIGNETABLEAU

Pour chaque ELEMENT de ListeChamps
Insérer la colonne ELEMENT dans la colonne correspondante de LIGNETABLEAU
Fin Pour
Fin Pour
Envoi des paramètres à la page de comparaison des prix via XML
Cela se fait par la fonction javascript envoi.

Utilisation du XML : <CFWDDX ACTION="CFML2WDDX" INPUT="#consolidation#"

OUTPUT="wresul tat-requete'r> permet de transformer du code cfml en code xml qui reçoit le contenu de la requête " consolidation " et renvoit une chaîne de caractères en xml contenant tous les résultats de la requête. On insère cette chaîne dans la table resultatxml de la BDD. On passe ensuite l'ID du contenu inséré dans le form afin de récupérer les données dans la page de comparaison.

Affichage des informations
Avec la seconde méthode, la consolidation se fait désormais sur le champ CLE et non plus sur le champ ISBN.

Pour chaque catégorie de produit, seules certaines informations sont alors affichées sur la page de consolidation : ce sont celles dont le METACHAMP correspondant possède une propriété METACHAMP~ordreCons strictement supérieure à 0.

Certains champs sont aussi affichés en entête du tableau.

L'algorithme d'affichage est donc par exemple le suivant :
Pour tout les METACHAMP dont METACHAMP ordreCons > 0
Récupérer le nom du champ NOMMETACHAMP, la valeur LARGEURMETACHAMP correspondant au champ METACHAMP~largeurCons et le champ METACHAMP~enteteCons
Pour tout les METACHAMP dont METACHAMP~enteteCons > 0
Créer une colonne de tableau HTML dont l'intitulé est NOMMETACHAMP et la largeur LARGEURMETACHAMP
Fin Pour
Fin Pour
Pour chaque ligne LALIGNE de la requête consolidation //lère ligne
Pour tout les METACHAMP dont METACHAMP~ordreCons > 0 et METACHAMP enteteCons > 0
Créer une colonne de tableau HTML dont le contenu est la colonne correspondante de LALIGNE et de largeur LARGEURMETACHAMP
Fin Pour //2nde ligne
Pour tout les METACHAMP dont METACHAMP~ordreCons > 0 et METACHAMP~enteteCons = 0
Afficher l'intitulé NOMMETACHAMP et le contenu qui est la colonne correspondante de LALIGNE
Fin Pour
Fin Pour
La page de comparaison (annuaire/comparaison.cfm) peut quant à elle être décrite comme suit :

Récupération des données du XML
On récupère l'ensemble des informations contenues dans la table Resultatxml grâce au champ Id passé en hidden dans le form précédent.

On fait le traitement inverse à celui effectué dans consolidation.cfm

<CFWDDX ACTION="WDDX2CFML" .TNP!7'r="#Cresu2(:a<:.Res~cont:enu#" OUTPUT="consolidation">
On récupère ainsi la requête " consolidation avec toutes les infos. Pour isoler le produit en question, il suffit de vérifier si le champ " cle" de la requête consolidation correspond bien au champ " cle passé en url via la fonction javascript envoi ()
Enfin la fiche descriptive du produit s'obtient de la façon suivante
On a récupéré au préalable le champ MetaCat-fiche-custom et MetaCat-Id grâce au paramètre " cat " passé en url.

Si le champ est nul, on inclut la fiche générique " annuaire/fiche~custom/fiche~generique.cfm " du produit qui ne présente aucune particularité ( en boucle, les intitulés et contenus des champs sont affichés ligne par ligne ). Si le champ web~photo du webmarchand est non nul, on place la photo s'il elle existe sur la droite de la fiche.

Si le champ est non nul, on inclut la fiche customisée nommée " fiche#MetaCat-Id# " où les champs peuvent être disposés d'une manière spécifique selon la catégorie.

Comme il va de soi et comme il résulte de ce qui précède la présente invention n'est pas limitée au mode de réalisation plus particulièrement décrit.

Elle en autorise au contraire toutes les variantes et notamment celles où les moyens d'interrogation sont vocaux et le dispositif est un téléphone mobile.

ANNEXE 1 <cfloop list="#liste~erreur#" index="inde">  <!--- récupération de l'ordre --- <cfquery name="recup~ordre" datasource="#datasourcename#"> select cw.ordre from categorie~webmarchand as cw, webmarchand as w where w.web tag = '#inde#' and cw.web~id = w.web~id </cfquery> <cfset total=inde & " TotalResults"> <CFLOOP INDEX="ind" FROM=1 TO="#evaluate(total)#">

ANNEXE 2 <cfset consolidation=QueryNew("Site,ISBN,Titre,Auteur,Edition,Prix,LienFiche" )> <CFLOOP INDEX="ind" FROM=1 TO="#Evaluate(nbre)#">

<CFSET newrow OueryAddot('consoJidat:-Lon,i> <CFSET temp = QuerySetCell (consolidation, "Si te", ListGetAt (resul ta t~tab [ind] , 8, ") ) > <CFSET temp = QuerySetCell (consolidation, "ISBN" ,ListGetAt (resultat~tab [ind] , 1, " , ") ) > <CFSET temp = QuerySetCell (consolidation, "Ti tre", ListGetAt (resul ta t~tab [ind] ,3, ") ) > <CFSET temp =

QuerySetCell (consolidation, "Auteur", ListGetAt (resul tat~tab [ind] , 4, ", ") )> <CFSET temp =

QuerySetCeII(consolidation,"Edition ListGetAt(resultat tab(indJ,5,"," " ))> <CFSET temp =

QuerySetCell (consolidation, "prix" , ListGetAt (resultat~tab[ind], 6,",")) <CFSET temp = QuerySetCell (consolidation, "Li enFi che" , ListGetAt (resul ta t~tab [ind] , 7, " ,"))> </CFLOOP>

Claims

REVENDICATIONS

1. Procédé de recherche et de comparaison d'informations sur au moins un produit déterminé répertorié sur au moins un site du réseau Internet, caractérisé en ce que un premier fichier de sites ayant été formé à partir des sites présents sur Internet, et un programme étiquette spécifique ayant été développé pour chacun des sites dudit premier fichier, dit fichier de sites, on saisit, suite à une action d'un utilisateur, au moins un champ de recherche correspondant au produit déterminé, par le biais d'un dispositif connecté au réseau Internet , on recherche sur Internet le ou les sites ayant une étiquette, on recherche puis on analyse les pages de chacun desdits sites grâce à son programme étiquette, on en extrait les informations correspondant au produit déterminé recherché, on ajoute ces informations à un deuxième fichier de résultats, dit fichier de résultats, on effectue un traitement algorithmique de consolidation sur ce deuxième fichier, pour consolider les informations ainsi obtenues par au moins un critère de consolidation, pour former un troisième fichier de résultats consolidés, dit fichier consolidé,

on affiche au moins en partie le contenu dudit fichier consolidé correspondant aux informations sur le produit issues des différends sites marchands, sous forme d'un tableau de résultats, on sélectionne alors le produit à partir dudit tableau, suite à une seconde action de l'utilisateur, et on affiche ledit produit, ses caractéristiques et le site marchand auquel il appartient.

2. Procédé selon la revendication 1, caractérisé en ce que, chaque site comprenant au moins un critère d'identification de la catégorie de sites spécifique à laquelle ledit site appartient, l'utilisateur saisit le champ de recherche correspondant au produit déterminé dans une catégorie de sites spécifique, et la recherche du ou des sites ayant une étiquette sur Internet s'effectue également parmi les sites appartenant à ladite catégorie de sites spécifique.

3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, les sites sont des sites marchands, et en ce que l'utilisateur commande de plus directement en ligne le produit sélectionné.

4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte de plus une étape de gestion des appels en parallèle, agencée pour permettre l'interrogation simultanément ou sensiblement simultanément en temps réel pour tous les sites muni d'étiquettes, éventuellement après sélection complémentaire.

5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est appliqué à la recherche et à la comparaison du prix de livres et/ou de petits paquets.

6. Procédé selon la revendication 4, caractérisé en ce que le produit étant un livre, on utilise le code ISBN comme critère de consolidation.

7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que on utilise au moins deux critères d'identification du site concerné.

8. Système de recherche et de comparaison d'informations sur au moins un produit déterminé répertorié sur au moins un site du réseau Internet, chaque site comprenant au moins un critère d'identification de la catégorie spécifique à laquelle il appartient, caractérisé en ce qu'il comprend - des moyens de stockage d'un premier fichier de sites ayant été formé à partir des sites présents sur Internet, un programme étiquette étant développé pour chacun des sites dudit premier fichier, - un dispositif connecté au réseau Internet , de saisie, suite à une action d'un utilisateur, d'au moins un champ de recherche correspondant au produit déterminé dans une catégorie de site spécifique, - des moyens de recherche sur Internet du ou des sites ayant un programme étiquette et appartenant à

ladite catégorie de site spécifique du produit recherché, - des moyens de recherche, de calcul et d'analyse des pages HTML de chaque site ayant une étiquette, en utilisant un algorithme de comparaison avec le champ de recherche correspondant au produit déterminé recherché, des moyens d'extraction des informations correspondant au produit déterminé recherché, - des moyens d'addition de ces informations à un deuxième fichier de résultats, - des moyens de traitement algorithmique de consolidation sur ce deuxième fichier, pour consolider les informations ainsi obtenues par au moins un critère de consolidation, pour former un troisième fichier de résultats consolidés, - des moyens d'affichage d'au moins une partie du contenu de ce troisième fichier correspondant aux informations sur le produit issues des différends sites marchands, sous forme d'un tableau de résultats consolidés, - des moyens de sélection du produit à partir dudit tableau, suite à une seconde action de l'utilisateur, et des moyens d'affichage des caractéristiques dudit produit, et du site auquel il appartient.

9. Système selon la revendication 8, caractérisé en ce que, les sites étant des sites marchands, le système comprend des moyens de commande directement en ligne du produit une fois sélectionné.

10. Système selon les revendications 8 et 9, caractérisé en ce qu'il comprend de plus des moyens permettant l'ajout de nouvelles catégories de produits ou de sites sans modification des étapes de traitement algorithmique mettant en scène le critère de consolidation.

11. Système selon l'une quelconque des revendications 8,9 et 10 caractérisé en ce qu'il comporte de plus des moyens de gestion des appels en parallèle, agencés pour permettre l'interrogation simultanément ou sensiblement simultanément en temps réel pour tous les sites.