Système d'échange de données informationnelles spécifiques entre deux sites web, procédé, serveur et programme d'ordinateur correspondants.

1. Domaine de l'invention

Le domaine de l'invention est celui de l'échange d'information entre sites web. Plus précisément, l'invention concerne la normalisation des échanges d'informations entre sites web, permettant aux sites d'homogénéiser les informations qu'ils détiennent et d'établir un référencement mutuel.

La grande majorité des sites web, par exemple les sites web dits de

« carnets de route » (« weblogs », également appelés « blogs ») ou les pages personnelles, proposent de l'information sous la forme de pages HTML qui sont construites dynamiquement, à partir de contenus de bases de données multimédia.

Cependant, ces pages HTML varient sensiblement en termes de présentation de l'information. Les bases de données contenant l'information à afficher sont quant à elles très disparates, tant en termes de structure que de contenus, et nécessitent des moyens de construction des pages HTML très hétérogènes.

2. Solutions de l'art antérieur 2.1 Art antérieur

On connaît déjà plusieurs techniques d'échange d'information entre des sites Web. Les informations échangées sont cependant très parcellaires et les formats d'échange sont disparates.

Ainsi, les sites web (pages personnelles, « weblogs », sites commerciaux...) disposent fréquemment d'une rubrique "sites préférés" dans laquelle le créateur du site web indique la liste des sites web qu'il a l'habitude de consulter ou des sites qui sont en rapport avec la thématique de son propre site. Cette liste fait apparaître le nom des sites ainsi que leur URL (Uniform Resource Locator).

Pour le propriétaire du site web, l'ajout d'un autre site à sa liste de "sites préférés" passe alors par l'ajout d'un couple {nom_site, URL_site}, comprenant le nom du site à ajouter, ainsi que l'URL à partir de laquelle il peut être atteint. Cet ajout statique peut se faire de deux façons :

Par l'ajout de code HTML dans le cas de l'utilisation d'un éditeur HTML ;

Par la saisie d'un formulaire dans le cas de l'utilisation d'un assistant de création de sites Web et enregistrement de ce couple dans une base de données.

Cette technique permet d'établir des référencements entre les sites unilatéralement à l'initiative du détenteur du site web qui veut en référencer un autre.

Dans le domaine des « blogs », l'information est mise à disposition par le site web souhaitant se faire référencer sous la forme d'un fil RSS. Ce fil RSS est un document XML contenant la liste des derniers articles publiés sur le site web. Pour le site Web proposant ce fil RSS, c'est un moyen de mettre à disposition des autres sites la liste des dernières nouveautés du site considéré dans un format structuré. Cette technique permet d'échanger des informations entre les sites unilatéralement à l'initiative du détenteur du site web qui veut se faire référencer.

Toujours dans le domaine des « blogs », le format OPML (Outline Processor Markup Language, pour « Langage à balise de traitement d'ensembles ») est un format d'échange de listes de « blogs » entre des sites web.

Ce format est implémenté sous la forme d'un fichier XML qui sert de point d'entrée à des aggrégateurs de sites, utilisés pour référencer de multiples

« blogs ». Cette technique permet également l'échange d'informations unilatéralement.

Pour finir, certains sites web disposent de moyens de description des personnes et des relations qu'elles entretiennent entre elles, toujours sous la forme d'un fichier XML respectant le format FoaF (Friend of a Friend, pour « Ami d'un

Ami »). Ce fichier particulier respecte une sémantique RDF (Resource Description Framework pour « cadre de description de ressource ») complexe.

2.2 Inconvénients de l'art antérieur

Ces techniques de l'art antérieur présentent de nombreux inconvénients.

Pour ce qui est de l'ajout manuel d'une URL d'un site web dans un autre site, un inconvénient de cette technique de l'art antérieur est l'absence de rapport bilatéral entre les deux sites web. En effet, le site web qui a ajouté dans sa liste de sites

préférés un lien vers un autre site n'a pas obtenu d'autorisation de la part de ce dernier. De plus, le lien créé est statique et ne permet pas au site web qui en référence un autre d'être au courant des dernières nouvelles ou des dernières évolutions du site référencé. Pour ce qui est des échanges basés sur RSS, OPML ou FoaF, un autre inconvénient de ces techniques de l'art antérieur est que ces formats n'offrent qu'une vue parcellaire d'un site web dynamique. Le format RSS ne propose qu'une vue des derniers articles publiés. Le format OPML propose la mise à disposition, sous forme structurée, de la liste des sites préférés pour un échange avec d'autres sites. Le format FoaF permet quant à lui de réaliser une description du propriétaire du site et de ses relations avec d'autres personnes. Ces normes d'échange ne permettent donc de mettre à disposition que des vues d'un site, et non l'intégralité de ce dernier. De plus, les fichiers utilisant ces normes sont mis à disposition par le site web souhaitant diffuser de l'information. En conséquence, à aucun moment, le site qui met à disposition de l'information n'est averti de l'utilisation effective de ces informations ni de la forme de cette utilisation. Dans le cas d'informations à caractère professionnel sensible ou personnel, ce manque de visibilité est un inconvénient majeur de ces techniques de l'art antérieur. En effet, elles ne permettent pas de certifier que l'utilisation qui est faite des informations est conforme aux souhaits de l'utilisateur.

Un autre inconvénient de ces techniques de l'art antérieur est que ces formats ne sont pas adaptés pour préciser les modes de relation existants entre deux sites web. Ceci ne permet pas aux utilisateurs et aux personnes visitant les sites mis en relation de valider clairement la provenance des informations qui sont présentées ni d'en vérifier la véracité. 3. Objectifs de l'invention

L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.

Plus précisément, un objectif de l'invention est de fournir une technique qui instaure un échange bilatéral d'information entre les sites web entrant dans un

processus de référencement mutuel, particulièrement adaptée aux sites web dynamiques.

Un autre objectif de l'invention est de proposer une telle technique d'échange bilatéral d'information permettant de s'assurer de la mise à jour dynamique des référencements entre les sites web.

L'invention a également pour objectif de fournir une telle technique permettant la description complète d'un site web, en intégrant l'ensemble des informations disponibles quant à ses dernières mises à jour, sites reliés, intervenants, etc. Encore un autre objectif de l'invention est de fournir une telle technique qui puisse garantir le contrôle de la diffusion des informations mises à disposition sur un site web.

Un autre objectif de l'invention est de fournir une telle technique permettant de préciser les relations entre les sites web. Par ailleurs, l'invention a aussi pour objectif de fournir une telle technique qui permette la structuration et le typage des échanges d'information entre les sites web.

Un dernier objectif de l'invention est de proposer une telle technique qui n'induise pas ou peu de complexité accrue des sites web. 4. Résumé de l'invention

Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un système d'échange de données, entre au moins un premier site web, hébergé sur un premier serveur et d'au moins un deuxième site web, hébergé sur un deuxième serveur, lesdites données étant véhiculées par le biais d'un réseau de communication.

Selon l'invention, lesdites données étant des données informationnelles spécifiques dudit au moins premier et/ou dudit au moins deuxième site web, un tel système comprend : au moins un support descriptif desdites données informationnelles spécifiques associées audit au moins un premier site web et/ou audit au

moins un deuxième site web ; des moyens de traitement de commandes d'échange d'au moins certaines desdites données informationnelles spécifiques, entre lesdits au moins premier et au moins deuxième sites web, lesdites commandes émanant d'un desdits sites web participant audit système à destination d'un autre site web participant audit système.

Ainsi, l'invention repose sur une approche nouvelle de l'échange de données entre des sites web, selon laquelle l'échange est régi par des moyens de traitement de commandes se basant sur des informations contenues dans un support descriptif, par exemple sous la forme d'un document XML. Les échanges de données sont réalisés bilatéralement par les moyens de traitement, qui communiquent entre eux en échangeant des données valides, issues des supports descriptifs, sans l'intervention des utilisateurs sur le contenu des échanges. Ainsi l'échange d'information est normalisé et séquence, afin de garantir la validité et l'exactitude des données échangées.

Avantageusement, lesdites données informationnelles spécifiques appartiennent au groupe comprenant au moins : des données générales relatives audit site web ; des données spécifiques relatives au propriétaire dudit site web ; - une liste de sites web liés audit site web contenant également des types de relation entretenue avec ledit site web ; une liste de personnes liées au propriétaire dudit site web contenant également des types de relation entretenue avec le propriétaire dudit site web. Ainsi, la définition de ces données informationnelles spécifiques permet de décrire les sites web, de borner les informations échangées entre les sites web et de connaître de façon précise les types de données échangées.

De manière préférentielle lesdits types de relation entretenue avec ledit site web appartiennent au groupe comprenant au moins : - site web préféré ;

site web à éviter ; liste de sites web dits de « carnet de route » (« bloglist ») ; liste d'amis.

La définition de ces types de relation permet de clarifier des modes de dépendance entre les différents sites web qui entretiennent des relations. Ainsi la nature de la relation étant identifiée, il est possible de différentier les comportements des sites web entrant en relation et d'offrir des possibilités de traitement de la bilatéralité des échanges.

De manière préférentielle, lesdits moyens de traitement de commandes sont accessibles depuis lesdits sites web dudit réseau.

De cette façon, les communications entre les sites web souhaitant échanger des données informationnelles spécifiques ne sont pas contraintes par l'obtention d'autorisations d'accès.

Selon un mode de mise en œuvre préférentiel, lesdits moyens de traitement de commandes se présentent sous la forme d'une URL (Uniform Resource Locator) de commande.

L'utilisation d'une URL (Uniform Resource Locator) permet alors de ne pas avoir à mettre en place un nouveau procédé de communication complexe, et d'utiliser les protocoles définis par les URL. Cette URL de commande, et plus généralement les moyens de traitement de commandes, peuvent être publics, dans le cas par exemple où le réseau de communication est le réseau mondial Internet. Dans le cas où ce réseau est de type intranet, l'URL de commande est accessible à tous les sites web de l'intranet considéré. Avantageusement, ladite URL de commande accepte des requêtes de demande d'information et/ou des requêtes de mise à jour d'information et fournit des réponses et/ou des données en fonction desdites requêtes.

La définition de ces requêtes permet de décrire précisément les types d'échanges entre les sites web. De manière préférentielle, lesdites requêtes de demande d'information et

lesdites requêtes de mise à jour d'information sont composées : d'un type de traitement à réaliser ; d'au moins un paramètre nécessaire à l'accomplissement dudit type de traitement. Ainsi, la composition des requêtes induit une sécurité de fonctionnement supplémentaire dans la mesure où seules les requêtes respectant ce format seront traitées par l'URL de commande.

Selon un mode de mise en œuvre préférentiel, lesdits types de traitement à réaliser appartiennent au groupe comprenant : - Ajout dudit premier site web à une liste de sites préférés dudit deuxième site web ;

Suppression dudit premier site web d'une liste de sites préférés dudit deuxième site web ;

Acceptation par ledit deuxième site web d'un ajout dudit deuxième site web à une liste de sites web préférés dudit premier site web ;

Refus par ledit deuxième site web d'un ajout dudit deuxième site web à une liste de sites préférés dudit premier site web ;

Récupération d'un document XML d'information associé à un site web (

Abonnement dudit premier site web à au moins une notification d'ajout d'au moins une information nouvelle dans ledit deuxième site web ;

Désabonnement dudit premier site web à ladite notification d'ajout ;

Récupération par ledit premier site web d'au moins une information contenue dans ledit support descriptif associé audit deuxième site web.

La sécurité du fonctionnement du système est donc renforcée, puisque les types de traitement sont définis. Il est ainsi impossible de faire réaliser des traitements qui ne soient pas autorisés par l'URL.

Avantageusement, ledit au moins un paramètre nécessaire à l'accomplissement dudit type de traitement appartient au groupe comprenant :

Un identifiant d'un propriétaire dudit premier et/ou dudit deuxième site web ;

Ladite URL de commande dudit premier et/ou dudit deuxième site web ;

Un type de notification ;

Au moins un paramètre de notification ;

Un identifiant de ladite au moins une information à récupérer. Ainsi, les paramètres des commandes complètent la capacité du système à assurer un fonctionnement prédictible et sécurisant de l'échange des données informationnelles spécifiques.

Selon un mode de mise en œuvre préférentiel, lesdites réponses sont des réponses au format HTTP contenant un document XML indiquant un échec ou une réussite ou ladite au moins une information à récupérer.

Les requêtes au format HTTP sont automatiquement prises en charge par toutes les plateformes d'hébergement des sites web. Le protocole http, pour l'émission et la réception des requêtes est donc un gage d'interopérabilité entre les systèmes, garantissant le fonctionnement du système chez l'ensemble des hébergeurs.

L'utilisation de XML pour la génération des réponses aux commandes et pour le transfert des données informationnelles spécifiques permet de garantir une interopérabilité maximale entre les sites web souhaitant échanger des données informationnelles spécifiques. En effet le langage XML est accepté par l'ensemble des plateformes d'hébergement des sites web. De plus, toutes ces plateformes disposent de moyens permettant le décodage des documents XML. XML est en outre particulièrement bien adapté à ce type d'échange car il permet de définir des documents ayant une structure arborescente. Une telle structure permet de traiter l'information de manière efficace et participe à la rapidité de traitement des données échangées.

Avantageusement, chacun desdits sites web est associé sélectivement à l'un desdits supports descriptifs comprenant lesdites données informationnelles spécifiques audit site web correspondant.

Ainsi, chaque site web dispose des informations qui lui sont propres et qui ne sont pas partagées avec les autres sites web du même type. Ceci garantit la

confidentialité des informations associées au site web propriétaire de son support descriptif.

L'invention concerne aussi un procédé d'échange de données, entre au moins un premier site web, hébergé sur un premier serveur et au moins un deuxième site web, hébergé sur un deuxième serveur, au moyen d'un réseau de communication.

Selon l'invention, lesdites données étant des données informationnelles spécifiques dudit au moins premier et/ou dudit au moins deuxième site web, un tel procédé d'échange de données comprend une étape d'émission d'au moins une commande d'échange d'au moins certaines desdites données informationnelles spécifiques, par ledit au moins premier site web vers une URL de commande dudit deuxième site web.

Comme déjà indiqué précédemment ci-dessus en relation avec le système d'échange de données de l'invention, dans un tel procédé, les données informationnelles spécifiques sont stockées sur au moins un support descriptif et appartiennent au groupe comprenant au moins : des données générales relatives audit site web ; des données spécifiques relatives au propriétaire dudit site web ; une liste de sites web liés audit site web contenant également des types de relation entretenue avec ledit site web ; une liste de personnes liées au propriétaire dudit site web contenant également des types de relation entretenue avec le propriétaire dudit site web.

En outre, dans le cadre de ce procédé d'échange de données, lesdits types de relation entretenue avec ledit site web appartiennent au groupe comprenant au moins : site web préféré ; site web à éviter ; liste de sites web dits de « carnet de route » (« bloglist ») ; - liste d'amis.

Avantageusement, dans un tel procédé d'échanges de données de l'invention, ladite commande d'échange est une requête de demande d'information et/ou une requête de mise à jour d'information. De telles requêtes sont préférentiellement composées : - d'un type de traitement à réaliser ; d'au moins un paramètre nécessaire à l'accomplissement dudit type de traitement.

Selon une caractéristique avantageuse d'un tel procédé d'échange, ladite étape d'émission appartient au groupe comprenant : - une étape d'émission d'une requête d'ajout dudit premier site web à une liste de sites préférés dudit deuxième site web ; une étape d'émission d'une requête de suppression dudit premier site web d'une liste de sites préférés dudit deuxième site web ; une étape d'émission d'une requête d'ajout dudit deuxième site web à une liste de sites préférés dudit premier site web ; une étape d'émission d'une requête de récupération par ledit premier site web d'un document XML d'information associé audit deuxième site web ; une étape d'émission d'une requête d'abonnement dudit premier site web à au moins une notification d'ajout d'au moins une information nouvelle dans ledit deuxième site web ; une étape d'émission d'une requête de désabonnement dudit premier site web à ladite notification d'ajout ; une étape d'émission d'une requête de récupération d'au moins une information contenue dans ledit support descriptif associé audit deuxième site web.

De façon préférentielle, pour un tel procédé d'échange de données de l'invention, ledit au moins un paramètre nécessaire à l'accomplissement dudit type de traitement appartient au groupe comprenant :

Un identifiant d'un propriétaire dudit premier et/ou dudit deuxième site web ;

Ladite URL de commande dudit premier et/ou dudit deuxième site web ;

Un type de notification ;

Au moins un paramètre de notification ;

Un identifiant de ladite au moins une information à récupérer. En outre, de façon avantageuse, un tel procédé comprend également une étape de réception d'une réponse à ladite commande émise par le premier site web, en fonction d'un traitement réalisé par le deuxième site web, ladite réponse comprenant au moins certaines desdites données informationnelles spécifiques en provenance d'au moins un support descriptif associé audit deuxième site web. Avantageusement, une telle réponse est une réponse au format HTTP contenant un document XML indiquant un échec ou une réussite ou ladite au moins une information à récupérer.

L'invention concerne également un produit programme d'ordinateur pour l'échange de données, entre au moins un premier site web, hébergé sur un premier serveur et au moins un deuxième site web, hébergé sur un deuxième serveur, au moyen d'un réseau de communication, téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Selon l'invention, un tel produit programme d'ordinateur comprend des instructions de code de programme pour la mise en œuvre des étapes du procédé d'échange de données décrit ci-dessus.

L'invention concerne encore un serveur d'échange de données dans un système d'échange de données, entre au moins un premier site web, hébergé sur un premier serveur et au moins un deuxième site web, hébergé sur un deuxième serveur, au moyen d'un réseau de communication. Un tel serveur comprend des moyens de mise en œuvre de l'ensemble des étapes du procédé d'échange de données décrit ci-dessus.

L'invention concerne également un deuxième procédé d'échange de données, entre au moins un premier site web, hébergé sur un premier serveur et au moins un deuxième site web, hébergé sur un deuxième serveur, au moyen d'un réseau de communication.

il

Selon l'invention, lesdites données étant des données informationnelles spécifiques dudit au moins un premier et/ou dudit au moins un deuxième site web, ce deuxième procédé comprend une étape de traitement d'au moins une commande d'échange d'au moins certaines desdites données informationnelles spécifiques, reçue sur une URL de commande dudit au moins un deuxième site web.

Comme déjà indiqué précédemment ci-dessus en relation avec le système et le premier procédé d'échange de données de l'invention, dans ce deuxième procédé, les données informationnelles spécifiques sont stockées sur au moins un support descriptif et appartiennent au groupe comprenant au moins : des données générales relatives audit site web ; des données spécifiques relatives au propriétaire dudit site web ; une liste de sites web liés audit site web contenant également des types de relation entretenue avec ledit site web ; - une liste de personnes liées au propriétaire dudit site web contenant également des types de relation entretenue avec le propriétaire dudit site web.

En outre, dans le cadre de ce deuxième procédé d'échange de données, lesdits types de relation entretenue avec ledit site web appartiennent au groupe comprenant au moins : site web préféré ; site web à éviter ; liste de sites web dits de « carnet de route » (« bloglist ») ; liste d'amis. Avantageusement, selon ce deuxième procédé d'échange de données de l'invention, ladite étape de traitement de commande est mise en œuvre par accès depuis lesdits sites web du réseau à une URL de commande.

De façon avantageuse, le deuxième procédé d'échange de données de l'invention comprend également une étape de fourniture de réponses et/ou de données audit premier site web, en fonction desdites commandes reçues. Ces

commandes sont des requêtes de demande d'information et/ou des requêtes de mise à jour d'information, et sont composées : d'un type de traitement à réaliser ; d'au moins un paramètre nécessaire à l'accomplissement dudit type de traitement.

Préférentiellement, lesdites réponses sont des réponses au format http contenant un document XML indiquant un échec ou une réussite ou ladite au moins une information à récupérer.

Avantageusement, ladite étape de traitement d'une commande d'échange met en œuvre un type de traitement appartenant au groupe comprenant : acceptation par ledit deuxième site web d'un ajout dudit deuxième site web à une liste de sites web préférés dudit premier site web ; refus par ledit deuxième site web d'un ajout dudit deuxième site web à une liste de sites préférés dudit premier site web ; - fourniture audit premier site web d'un document XML d'information associé au deuxième site web ; fourniture audit premier site web d'au moins une information contenue dans ledit support descriptif associé audit deuxième site web.

De manière préférentielle, ledit deuxième procédé comprend également une étape de mise à jour, en fonction dudit traitement, d'au moins un support descriptif desdites données informationnelles dudit deuxième site web.

Une telle étape de mise à jour consiste par exemple à : ajouter le premier site web à une liste de sites préférés du deuxième site web ; - supprimer le premier site web d'une liste de sites préférés du deuxième site web ; ajouter le premier site web à une liste de sites abonnés à au moins une notification d'ajout d'au moins une information nouvelle dans le deuxième site web ; - supprimer le premier site web d'une liste de sites abonnés à au moins une

notification d'ajout d'au moins une information nouvelle dans le deuxième site web ; ajouter le premier site web à une liste de sites référençant le deuxième site web ; - supprimer le premier site web d'une liste de sites référençant le deuxième site web.

Avantageusement, ladite étape de traitement utilise ledit au moins un paramètre nécessaire à l'accomplissement dudit type de traitement, véhiculé par ladite commande, et qui appartient au groupe comprenant : - Un identifiant d'un propriétaire dudit premier et/ou dudit deuxième site web ;

Ladite URL de commande dudit premier et/ou dudit deuxième site web ;

Un type de notification ;

Au moins un paramètre de notification ; - Un identifiant de ladite au moins une information à récupérer.

L'invention concerne également un produit programme d'ordinateur pour l'échange de données, entre au moins un premier site web, hébergé sur un premier serveur et au moins un deuxième site web, hébergé sur un deuxième serveur, au moyen d'un réseau de communication, téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Selon l'invention, un tel produit programme d'ordinateur comprend des instructions de code de programme pour la mise en œuvre des étapes du deuxième procédé d'échange de données décrit ci-dessus.

L'invention concerne encore un serveur d'échange de données dans un système d'échange de données, entre au moins un premier site web, hébergé sur un premier serveur et au moins un deuxième site web, hébergé sur un deuxième serveur, au moyen d'un réseau de communication. Un tel serveur comprend des moyens de mise en œuvre de l'ensemble des étapes du deuxième procédé d'échange de données décrit ci-dessus. Avantageusement les deux procédés d'échange de données précédents

peuvent être mis en œuvre de concert afin de fournir un procédé global de gestion des données informationnelles spécifiques d'un site web. Ainsi, il n'est pas nécessaire de disposer de plusieurs entités de traitement relatives à chacun des deux procédés. 5. Liste des figures

D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 illustre l'architecture d'un système permettant l'échange de données informationnelles spécifiques, conformément à l'invention ; la figure 2 illustre, de façon schématique, la structure matérielle du serveur de la figure 1 ; la figure 3 décrit la structure logique du flux d'information et de traitement aboutissant à l'échange des données informationnelles spécifiques entre deux sites web ; la figure 4 illustre une demande d'ajout d'un « weblog » « A » dans la liste des sites web préférés d'un « weblog » « B » ; la figure 5 illustre une demande de suppression d'un « weblog » « A » dans la liste des sites web préférés d'un « weblog » « B » ; les figures 6 et 7 illustrent les différents états d'un « blog » contenu dans une « bloglist » ; la figure 8 présente un échange d'obtention des informations générales d'un « weblog » ; - la figure 9 présente le mécanisme de notification de l'ajout des derniers articles d'un « weblog » « A » à un « weblog » « B » via le flux RSS du

« blog » « A » ; les figures 10, 11 et 12 illustrent le mécanisme d'abonnement, de désabonnement et la notification de l'ajout des derniers articles d'un « weblog » « A » à un « weblog » « B » via les services de courrier

électronique, SMS (Short Message Service), MMS (Multimédia Message

Service); la figure 13 présente le mécanisme d'obtention des informations sur le propriétaire d'un « Weblog » ; - la figure 14 présente le mécanisme d'obtention des informations sur les

« weblogs » préférés d'un « weblog » ; la figure 15 illustre l'obtention des informations sur les « weblogs » se référant à un « weblog ».

6. Description détaillée de l'invention 6.1 Rappel du principe de l'invention

Dans le cadre de la présente invention, on s'intéresse donc à l'échange de données informationnelles spécifiques entre des sites web, en se basant sur un support structuré d'échange de données informationnelles et sur des moyens spécifiques permettant de concrétiser les échanges. Le principe général de l'invention repose sur le traitement bilatéral d'échange de données informationnelles. Ces données informationnelles sont définies dans un fichier propre au site web en question. L'échange des données est réalisé automatiquement entre les sites web. Ainsi, l'utilisateur n'a pas à se préoccuper de la cohérence ou de la validité de ces données. Les sites web sont quant à eux répartis dans l'ensemble du réseau Internet et disposent chacun d'un support de données informationnelles et de moyens de traitements des commandes d'échange des données informationnelles.

La figure 1 est une illustration simplifiée d'un exemple d'architecture mettant en œuvre un mode de réalisation de l'invention. Le site web 101, hébergé au sein d'un serveur 10, contient des moyens de traitement des commandes d'échange des données informationnelles 102 liés à un support de données informationnelles 103 contenant des données informationnelles spécifique du site web 101.

La structure du serveur 10 est illustrée schématiquement par la figure 2. Il comprend également une mémoire M 21, et une unité de traitement 20 équipée

d'un microprocesseur μP, qui est piloté par un programme d'ordinateur (ou application) Pg 22. L'unité de traitement 20 reçoit en entrée, via un module d'interface d'entrée réseau E 23, des requêtes et/ou des réponses clients 24, que le microprocesseur μP traite, selon les instructions du programme Pg 22, pour générer des commandes et/ou des réponses 26, qui sont transmises via un module d'interface de sortie réseau S 25.

Un exemple particulier d'implémentation du système de la figure 1 peut être obtenu à partir du socle technique suivant, qui comprend :

Un serveur de gestion du protocole http (serveur Web) 10 qui peut être par exemple de type IIS, Apache, Netscape, SUN iPlanet (marques déposées).

C'est lui qui héberge le site web 101 ;

Une URL de commande 102, faisant office de moyens de traitement des commandes d'échange des données informationnelles. Elle peut avantageusement être basée sur : - Le langage java et être implémentée sous la forme de modules indépendants (« servlet ») ou sous la forme d'un générateur dynamique de contenu JSP (« Java Server Page »), par exemple IBM WebSphere, BEA Web Logic, Netscape Enterprise server, Oracle Application Server, SUN Iplanet (marques déposées), - Un langage de type ASP/COM (ASP .NET, Microsoft Transaction

Server (marques déposées)),

Une implémentation de Services Web ou un langage de type PHP ; Un fichier XML structuré 103, qui contient les données informationnelles spécifiques du site web 101. Dans un autre mode de réalisation, les données informationnelles spécifiques (103) du site web peuvent également être placées dans un fichier texte classique ou encore dans une base de données privée du site web.

Par la suite, on présente notamment le cas d'un mode de réalisation du support des données informationnelles spécifiques, sous la forme d'un fichier XML, dans le cadre de sites web dits de « carnet de route » (« blogs », également

appelés « weblogs »), ainsi qu'un mode de réalisation des moyens de traitement des commandes d'échange de ces données, sous la forme d'une adresse Internet (URL) accessible pour ces sites.

Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en œuvre dans de nombreux autres domaines, et par exemple dans le cadre de sites web définissant des relations de personne à personne et plus généralement dans tous les cas où les objectifs listés par la suite sont intéressants.

6.2 Support des données informationnelles spécifiques. Selon l'invention, les données informationnelles spécifiques propres à chaque site web sont organisées au sein d'un support descriptif. Ces données informationnelles induisent une structure spécifique dans le support. Dans un mode particulier de réalisation de l'invention, ce support est un fichier XML. Dans ce mode de réalisation, les données informationnelles sont les suivantes : - Des informations générales sur un site Web :

Le titre du site web ; L'adresse du site web ;

L'adresse du flux RSS contenant les nouveautés du site Web, lorsque le site dispose d'une telle adresse. - Des informations sur le propriétaire du site web :

Le nom complet (Nom et prénom concaténés, par exemple). Il peut aussi s'agir du nom d'une entreprise ou d'une association ; Une adresse : il peut s'agir d'une adresse postale ou d'une adresse de courrier électronique par exemple. - Des informations sur la liste des sites web liés à ce site web :

Une liste des sites préférés du site web, si ce dernier possède des liens vers des sites préférés ;

Une liste des sites se référant à ce site web en tant que site préféré, si tel est le cas ; - Pour chaque site web des deux listes précédentes, les éléments

suivants sont souhaitables : Nom du site web ; Adresse du site web ;

Adresse d'accès aux moyens de traitement des commandes d'échange des données informationnelles du site web.

Dans un autre mode de réalisation particulier de l'invention il est également possible d'ajouter aux données informationnelles spécifiques les éléments suivants :

Dans les informations générales sur un site web : - Le thème du site web ;

Une description du site web ;

Une date de création et une date de dernière modification du site web ;

Une liste des catégories permettant d'organiser les articles publiés dans le site web.

Dans les informations sur le propriétaire du site web : Les prénoms et noms séparés ;

Un numéro de téléphone (pour l'envoi de messages, par exemple) ou encore un numéro de connexion à un service de messagerie instantanée;

Une adresse de l'emplacement d'une photo du propriétaire du site web ;

Une adresse d'un document FoaF associé au propriétaire du site web. Dans ce mode de réalisation, en vue de l'implémentation de l'invention au sein de sites web dits de « carnets de route » (« weblogs »), la DTD (Document Type Définition) décrivant le fichier XML des données informationnelles spécifiques serait le suivant :

<?xml version="1.0" encoding="iso-8859-l" ?> <!ELEMENT blogml

(gênerai,owner,bloglist,otherInformations? )> <!ELEMENT gênerai

(title,url,thème? ,description? ,dateCreated? , dateModified? ,catégories? ,rssFeed)>

<!ELEMENT owner

(name, firstname? , surname? ,mobileNumber? , email,phot oUrl?,seeAlso?)>

<!ELEMENT bloglist (in,out)>

<!ELEMENT otherlnformations (information+)>

<!ELEMENT title (#PCDATA)>

<!ELEMENT url (#PCDATA)> <!ELEMENT thème (#PCDATA)>

<!ELEMENT description (#PCDATA)>

<!ELEMENT dateCreated (#PCDATA)>

<!ELEMENT dateModified (#PCDATA)>

<!ELEMENT catégories (category+)> <!ELEMENT category (name,description?,url)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT rssFeed (#PCDATA)>

<!ELEMENT firstname (#PCDATA)>

<!ELEMENT lastname (#PCDATA)> <!ELEMENT mobileNumber (#PCDATA)>

<!ELEMENT email (#PCDATA)>

<!ELEMENT photoUrl (#PCDATA)>

<!ELEMENT seeAlso (#PCDATA)>

<!ELEMENT in (blog*)> <îELEMENT OUt (blog*)>

<!ELEMENT blog (name,url,urlCmd)>

<!ELEMENT urlCmd (#PCDATA)>

<!ELEMENT information (#PCDATA)>

<ATTLIST blogml version CDATA #REQUIRED>

<ATTLIST blog state (active Iwaiting | accepted | refused) #REQUIRED notification (none |mail | sms |mms) ' none ' notifParam CDATA #IMPLIED>

<ATTLIST information name CDATA #REQUIRED>

Dans ce cas de figure, cette DTD de description est appelée « BlogML ».

Dans un mode de réalisation alternatif de l'invention, cette structure de définition des données informationnelles spécifiques peut être décrite au sein d'une base de données qui présenterait les mêmes éléments et les mêmes définitions d'éléments et d'attributs que le fichier XML.

Encore dans un autre mode de réalisation, la structure peut aussi être implémentée sous une forme simplifiée au sein d'un fichier texte.

6.3 Description des commandes de l'URL de traitement des échanges de données informationnelles spécifiques.

Le transfert d'information entre les sites web est défini par le principe des requêtes émises par le site web requérant l'information. Ces requêtes comportent : des commandes permettant d'identifier les actions à réaliser par l'URL de traitement des échanges de données ; des paramètres nécessaires à la réalisation de ces actions.

On donne ici une liste non exhaustive des commandes pouvant être implémentées au sein de l'URL :

Lors de la réception de ces requêtes, l'URL réceptrice de la commande réalise les traitements demandés par la commande et fournit une réponse à destination du site web requérant l'information. Dans ce mode de réalisation, la réponse fournie au site web requérant l'information est un document XML. Dans un autre mode de réalisation, il est envisageable que les traitements liés à la commande ne soient pas réalisés par l'URL de commande elle-même, mais par un serveur distant, présent sur le réseau Internet par exemple.

Dans un mode particulier de réalisation de l'invention, lié à l'échange des données informationnelles spécifiques aux sites web dits de « carnets de route », on présente une liste non exhaustive des commandes implémentées par l'URL (on rappelle que par « bloglist » on entend la liste des « blog » préférés d'un site web donné) :

Les commandes précédentes peuvent être largement complétées en fonction des fonctionnalités envisagées pour l'échange de données.

6.4 Description du format de réponse aux requêtes émises par les rURL de traitement des échanges de données informationnelles spécifiques.

Dans un mode de réalisation spécifique de l'invention, et à l'exclusion de commandes particulières, les commandes issues de l'URL de traitement des échanges de données informationnelles spécifiques renvoient une réponse « http » contenant un document XML indiquant l'échec ou la réussite de la demande. La DTD de ce document XML peut alors être la suivante :

<?xml version="1.0" encoding="iso-8859-l" ?> <!ELEMENT CmdResp EMPTY> <ATTLIST CmdResp type (ERRORI OK) #REQUIRED message CDATA #IMPLIED>

Dans un autre mode de réalisation, les réponses pourraient être renvoyées sous la forme de codes retours identifiant le bon ou le mauvais fonctionnement de la requête.

6.5 Description d'une URL de traitement des échanges de données informationnelles spécifiques

On présente en relation avec la figure 3 un mode de réalisation d'une URL de commande de traitement des échanges des données informationnelles spécifiques entre deux sites web dits de « carnets de route » (« weblog »).

A chaque « weblog » (respectivement 101 et 111) est associée une unique URL de commande (respectivement 102 et 112) qui permet d'envoyer des commandes à ce « weblog ». Cette URL est mise à disposition des lecteurs du « weblog ». Dans un mode de réalisation particulier, cette URL de commande peut être accessible depuis la page d'accueil du « weblog », à l'aide d'un lien hypertexte vers cette URL, par exemple.

Les URL de commandes 102 et 112 accèdent et mettent à jour respectivement les données informationnelles spécifiques contenues dans les fichiers XML 103 et 113.

Lors de la demande d'échange d'information entre le « weblog » 101 et le « weblog » 111 , le principe du mode de réalisation du système est le suivant :

Via le serveur 10, le « weblog » 101 émet sur le réseau de communication

12 une requête HTTP (HyperText Transfert Protocol, pour « protocole de transfert hypertextuel) 13 à destination du « weblog » 111 ;

Le serveur 11 réceptionne la requête 12 et la transmet (114) à l'URL de commande 112 ;

L'URL 112 exécute les traitements nécessaires à la réalisation de la commande en consultant et/ou en mettant à jour (115) le fichier XML 113 ;

L'URL 112 construit une réponse 116 à destination de l'URL de commande 102 du « weblog » 101 ;

La réponse 116 est acheminée 14 au serveur 10 par le réseau de communication 12 ; - Le serveur 10 transmet (104) cette réponse à l'URL de commande 102 ;

L'URL de commande 102 réalise les traitements nécessaires pour la prise en compte de la réponse et/ou met à jour (105) le fichier XML 103.

Dans les descriptions suivantes on détaille des modes de réalisation précis d'ajout, de suppression, de notification et d'échange des données contenues dans les fichiers XML.

6.5.1 Ajout/Suppression d'un « weblog » « A » de la « bloglist » (liste de blog) d'un « weblog » « B ».

6.5.1.1 Ajout d'un « weblog » « A » dans la « bloglist » d'un « weblog » « B ». On présente en relation avec la figure 4 un mode de réalisation d'un échanges des données informationnelles spécifiques entre deux sites web dits de « carnets de route » (« weblog ») visant à ajouter un « weblog » « A » dans la liste des sites préférés d'un « weblog » « B ». Dans ce mode de réalisation, les URL de commande (respectivement l'URL de commande « A » et l'URL de commande « B ») émettent et réceptionnent les requêtes et renvoient les réponses associées aux requêtes reçues. Les traitements liés à la manipulation des données sont régis par des applicatifs serveur (respectivement l'applicatif serveur « A » et l'applicatif serveur « B »).

La demande d'ajout 41 d'un « blog » « A » 50 à la « bloglist » d'un « blog » « B » 40 est composée des étapes suivantes :

L'applicatif serveur « B » du « blog » « B » (40) : ajoute un nœud 42 <blog> dans le nœud "<bloglistxin>" du document blogML « B » ; envoie une action "addblogTobloglist" 43 à l'URL de commande « A » ;

L'URL de commande « A » réceptionne et traite (51) l'action "addblogTobloglist" en requêtant l'action "getblogML" 52 à l'URL de commande du « blog » « B » (40) ;

L'URL de commande « B » réceptionne et traite (44) l'action "getblogML" et envoie le document blogML « B » en guise de réponse 45 ;

L'URL de commande « A » réceptionne 53 le document blogML « B » et vérifie 54 le nœud <blog> correspondant à « A » dans le document blogML « B » :

Si une anomalie est détectée (55) lors de la vérification 54, l'URL de commande « A » envoie une réponse 56 contenant une

notification d'erreur à l'action "addblogTobloglist et le processus se termine.

Si aucune anomalie n'est détectée (55) lors de la vérification 54, l'URL de commande « A » envoie une réponse 56 contenant une notification de prise en compte de l'action "addblogTobloglist" et le processus se poursuit ;

L'applicatif serveur « A » vérifie alors (57) que le propriétaire « A » est informé de la demande d'ajout :

Si tel est le cas, l'applicatif serveur « A » ajoute un nœud <blog> dans le nœud "<bloglistxout>" du document blogML « A » (58) ;

Si le propriétaire « A » n'est pas informé de la demande, l'applicatif serveur « A » reste en état d'attente jusqu'à ce que le propriétaire « A » ait été informé ;

Quand le propriétaire « A » a été informé 58 de la demande, l'applicatif serveur vérifie 59 que le propriétaire « A » accepte la demande d'ajout de la part du blog « B ».

Si tel est le cas, l'applicatif serveur « A » positionne (510) l'attribut "state" du nœud <blog> créé à la valeur "accepted" et envoie 512 une action"acceptblog" à l'URL de commande « B » ; - Si le propriétaire « A » n'accepte pas l'ajout, l'applicatif serveur

« A » positionne (511) l'attribut "state" du nœud <blog> créé à la valeur "refused" et envoie 513 une action"refuseblog" à l'URL de commande « B » ;

En fonction de la réponse du « blog » « A », l'applicatif serveur « B » réceptionne et traite soit l'action "refuseblog " 46, soit l'action

"acceptblog" 47 ;

Quelle que soit l'action traitée (46 ou 47), l'applicatif serveur « B » vérifie

48 le nœud <blog> correspondant à « A » dans le document blogML « B » puis transmet 49 une requête "getblogML" à l'URL de commande « A » ; L'URL de commande « A » réceptionne et traite 514 la requête

"getblogML", puis envoie 515 sous la forme d'une réponse à cette requête le document blogML « A » ;

L 'URL de commande « B » réceptionne 410 le document blogML « A » et vérifie le nœud <blog> correspondant à « A » dans le document blogML « A » :

Si une anomalie est détectée (412) lors de la vérification 411, l'URL de commande « B » envoie une réponse 413 contenant une notification d'erreur à l'action "refuseblog" ou "acceptblog" et le processus se termine. - Si aucune anomalie n'est détectée (412) lors de la vérification 411, l'URL de commande « B » envoie une réponse 413 contenant une notification de prise en compte de l'action "refuseblog" ou "acceptblog" et le processus se poursuit ; L'applicatif serveur « B » vérifie 414 le type d'action : - En cas de refus (action "refuseblog") l'applicatif serveur

« B » positionne 415 l'attribut "state" du nœud <blog> correspondant à « A » dans le document blogML « B » à la valeur "refused" ;

En cas d'acceptation (action "acceptblog") l'applicatif serveur « B » positionne 416 l'attribut "state" du nœud

<blog> correspondant à « A » dans le document blogML « B » à la valeur "accepted" ;

L'applicatif serveur « B » vérifie 417 que le propriétaire « B » est informé de la réponse du «weblog» « A » : - Si le propriétaire « B » n'est pas informé de la réponse, l'applicatif serveur « B » reste en état d'attente 417 jusqu'à ce que le propriétaire « B » ait été informé ; Si le propriétaire « B » est informé, l'applicatif serveur « B » : - Supprime 418 le nœud <blog> correspondant à

« A » dans le document blogML « B », dans le cas où la réponse de l'URL de commande « A » est négative (action "refuseblog") ; Positionne 419 l'attribut "state" du nœud <blog> correspondant à « A » dans le document blogML

« B » à la valeur "active".

Les étapes de traitement de la demande d'établissement de lien du « blog » « B » vers le « blog » « A » sont alors terminées.

6.5.1.2 Suppression d'un « weblog » « A » de la « bloglist » d'un « weblog » « B ».

On présente en relation avec la figure 5 un mode de réalisation d'un échange des données informationnelles spécifiques entre deux sites web dits de « carnets de route » (« weblog ») visant à supprimer un « weblog » « A » 51 dans la liste des sites préférés d'un « weblog » « B » 50. Dans ce mode de réalisation, les URL de commande (respectivement l'URL de commande « A » et l'URL de commande « B ») émettent et réceptionnent les requêtes et renvoient les réponses associées aux requêtes reçues. Les traitements liés à la manipulation des données sont régis par des applicatifs serveur (respectivement l'applicatif serveur « A » et l'applicatif serveur « B »). Lorsque le propriétaire « B » souhaite supprimer 501 le « Blog » « A » 51 de sa « bloglist », une action "deleteBlogFromBlogList" 503 est envoyée à l'URL de commande « A » avec en paramètre le nom du propriétaire « B » et l'URL de commande « B ». Le document BlogML « B » est alors mis à jour par l'applicatif serveur « B » en supprimant le nœud <blog> correspondant au « Blog » « A » 51 du nœud <in> du nœud <bloglist> 502.

Lors de la réception 511 de l'action "deleteBlogFromBlogList" par l'URL de commande « A », l'applicatif serveur « A » vérifie que le « blog » « B » 50 a bien supprimé le « blog » « A » de la « Bloglist » « B ». Pour cela, il va consulter le document BlogML « B » en envoyant une action "getBlogML" 512 à l'URL de commande « B ». L'applicatif serveur « B » réceptionne cette demande 504 et

renvoie 505 le document BlogML « B ». L'applicatif serveur « A » vérifie 513 que le nœud <blog> le concernant a bien été supprimé. Cette vérification permet d'éviter de "fausses demandes de suppression" envoyées par un tiers.

Si jamais une anomalie est identifiée lors de cette vérification 515, il renvoie 516 une réponse de type <CmdResp type="ERROR" message="La commande a échoué"/>.

Sinon, il renvoie 516 une réponse <CmdResp type="OK" />, le propriétaire « A » est informé de sa suppression de la « Bloglist » « B » et le document BlogML « A » est mis à jour 517 par l'applicatif serveur « A » en supprimant le nœud <blog> précédemment créé du nœud <out> du noeud

<bloglist>.

6.5.1.3 Les différents états d'un « Blog » d'une « bloglist ». On présente en relation avec la figure 6 les différents états possibles des blogs apparaissant dans le nœud <in> du document BlogML : Lors d'une demande d'ajout 60 du « blog » « A » à la « bloglist » du

« blog » « B » :

L'état est dans un premier temps marqué comme « Waiting » en attendant la réponse du propriétaire « A » ;

Si le propriétaire « A » n'accepte pas l'ajout 62, l'état est alors marqué 63 comme « Refused ». Cette information est transmise 64 au « blog » « B » qui supprime le « blog » « A » de sa « bloglist » ; Si le propriétaire « A » accepte l'ajout 65, l'état est alors marqué 66 comme « Accepted ». Cette information est transmise 67 au « blog » « B » pour qu'il la valide. L'état passe alors à « Active » 68 ; On présente en relation avec la figure 7 les différents états possibles des blogs apparaissant dans le nœud <out> du document BlogML :

Quand le « blog » refuse 70 d'être référencé, l'état est « Refused » 71 ; Quand le « blog » accepte 72 d'être référencé, l'état est « Accepted » 73. 6.5.2 Obtention des informations générales d'un « weblog ». On présente en relation avec la figure 8 un mode de réalisation de

l'obtention des informations générales d'un « weblog ». Dans ce mode de réalisation, les URL de commande (respectivement l'URL de commande « A » et rURL de commande « B ») émettent et réceptionnent les requêtes et renvoient les réponses associées aux requêtes reçues. Les traitements liés à la manipulation des données sont régis par des applicatifs serveur (respectivement l'applicatif serveur « A » et l'applicatif serveur « B »).

L'obtention 801 des informations générales d'un « weblog » « A » 81 par un « weblog » « B » 80 se fait via l'envoi 802 de l'action "getBlogML" à l'URL de commande « A » qui la réceptionne 811. Cette commande, par l'intermédiaire de l'applicatif serveur « A », renvoie 812 en retour une réponse « http » contenant le document BlogML du « blog » « A ». Après réception 803 par l'URL de commande « B », un dispositif doté d'un extracteur XML peut ensuite extraire 804 les informations générales du « blog » « A » 81 contenu dans le nœud <general>. Ces informations peuvent être : - Le titre ;

L'URL du blog ;

Le thème ;

La description ;

La date de création ; - La date de dernière modification ;

La liste des catégories ;

L'URL du flux RSS du blog.

Ces informations sont alors mises à disposition 805 de l'applicatif serveur « B ». 6.5.3 Obtention des derniers articles publiés dans un « weblog ».

On décrit ici deux modes de réalisation de l'obtention par un « weblog »

« B » des derniers articles publiés dans un « weblog » « A ». Dans ce mode de réalisation, les URL de commande (respectivement l'URL de commande « A » et l'URL de commande « B ») émettent et réceptionnent les requêtes et renvoient les réponses associées aux requêtes reçues. Les traitements liés à la manipulation des

données sont régis par des applicatifs serveur (respectivement l'applicatif serveur « A » et l'applicatif serveur « B »).

Pour le propriétaire du « Blog » « B », au moins deux méthodes sont alors envisageables pour être informé des derniers articles publiés dans un « Blog » « A » : via le flux RSS du « Blog » « A » ; via la notification par courrier électronique/SMS (« Short Message Service »)/MMS (« Multimedia Message Service ») lors de l'ajout d'articles ; 6.5.3.1 via le flux RSS du « Blog » « A ».

On présente en relation avec la figure 9 un mode de réalisation de l'obtention, par un « weblog » « B » 90, des derniers articles publiés dans un « weblog » « A » 91 par le biais d'un flux RSS.

L'obtention 901 de l'URL du flux RSS d'un « weblog » « A » 91 se fait via l'envoi 902 de l'action "getBlogML" à l'URL de commande « A ». Après réception

911 par cette dernière, la commande renvoie en retour une réponse 912 « http » contenant le document BlogML du « blog » « A » 91. Après réception 903 par l'URL de commande « B », un dispositif doté d'un extracteur XML peut ensuite extraire 904 l'URL du flux RSS du « blog » « A » 91 contenu dans le nœud <general>.

L'URL du flux RSS du « blog » « A » 91 est alors mise à disposition 905 de l'applicatif serveur « B ».

Cette URL est interprétable par de nombreux outils du marché (aggrégateurs de news, lecteurs de fils RSS) dont le rôle est de scruter de manière périodique (tous les jours, toutes les heures...) ce type de flux afin de détecter la publication de nouveaux articles.

6.5.3.2 la notification par email/SMS/MMS lors de l'ajout d'articles. On présente en relation avec les figures 10, 11 et 12, un mode de réalisation de l'obtention des derniers articles publiés dans un « weblog » grâce à une notification par email/SMS/MMS.

Dans un premier temps, on détaille l'abonnement au service de notification. Puis on décrit le désabonnement. Enfin, on détaille les actions menées lors de l'ajout d'un nouvel article à un « Blog »

Abonnement à la notification : Pour être notifié 1001 par mail/SMS/MMS lors de l'ajout de nouveaux articles dans le « blog » « A » 101, le propriétaire du « blog » « B » 100 (via son applicatif serveur « B ») peut envoyer l'action 1003 "subscribeToNotification" à l'URL de commande « A », avec notamment en paramètre le type de notification (mail/SMS/MMS) et son adresse mail ou n° de mobile. Le nœud <blog> correspondant au « blog » « A » 110 dans le document

BlogML « B » est alors mis à jour 1002 par l'applicatif serveur « B » en positionnant à "mail", "sms" ou "mms" la valeur de l'attribut "notification" du nœud <blog>. L'exemple XML ci-dessous détaille la structure de ce nœud : <blogml>

<bloglist> <in>

<blog state≈" active" notification="mail | sms |mms"> <name>Nom du» blog »A</name>

<url>URL du» blog »A</url> <urlCmd>URL "Command" du» blog »A</urlCmd> </blog> </in>

</bloglist> </blogml>

Lors de la réception 1011 de l'action "subscribeToNotification" par l'URL de commande « A », l'applicatif serveur « A » vérifie que le « blog » « B » 100 est bien le demandeur de l'abonnement à la notification. Pour cela, il va consulter le document BlogML « B » en envoyant 1012 une action "getBlogML" à l'URL de commande « B ». L'URL de commande « B » réceptionne 1004 cette requête et renvoie 1005 son document BlogML « B » en réponse. Après réception 1013 par l'URL de commande « A », l'applicatif serveur « A » vérifie 1014 que le nœud <blog> le concernant a bien son attribut "notification" positionné à "mail", "sms" ou "mms". Cette vérification permet d'éviter de "fausses demandes de notification" envoyées par un tiers.

Si une anomalie est identifiée 1015 lors de cette vérification, il renvoie une réponse 1016 de type <CmdResp type="ERROR" message="La commande a échoué"/>.

Sinon, il renvoie une réponse 1016 de type <CmdResp type="OK" />, et l'applicatif serveur « A » met à jour 1017 le document BlogML « A » en : positionnant à « mail », « sms » ou « mms » la valeur de l'attribut "notification" du nœud <blog> correspondant au « blog » « B » 100 ; ajoutant l'attribut "notifParam" (renseigné avec l'adresse mail ou le numéro de mobile du propriétaire « B ») du nœud <blog> correspondant au « blog » « B » 100.

L'exemple XML ci-dessous détaille la structure de ce nœud : <blogml>

<bloglist> <out>

<blog notification="mail I sms |mms" notifParam="email ou numéro mobile du propriétaire B">

<name>Nom du» blog »B</name> <url>UKL du» blog »B</url>

<urlCmd>URL "Command" du» blog »B</urlCmd> </blog> </out> </bloglist>

</blogml>

Ainsi, lorsque de nouveaux articles sont ajoutés au « blog » « A » 100, l'applicatif serveur « A » disposera dans le document BlogML « A » des informations nécessaires pour notifier le propriétaire « B ». Désabonnement de la notification ;

Pour être désabonné 1101 de la notification, le propriétaire du « blog » « B » 110 doit (via son applicatif serveur « B ») envoyer 1103 l'action "unsubscribeToNotification" à l'URL de commande « A ».

Le nœud <blog> correspondant au « blog » « A » dans le document BlogML « B » est alors mis à jour 1102 par l'applicatif serveur « B » en positionnant à "none" la valeur de l'attribut "notification" du nœud <blog>, comme décrit dans l'exemple de document XML suivant : <blogml>

<bloglist> <in> <blog state≈" active" notification="none">

<name>Nom du» blog »A</name> <url>URL du» blog »A</url> <urlCmd>URL "Command" du» blog »A</urlCmd> </blog> </in>

</bloglist> </blogml>

Lors de la réception 1111 de l'action "unsubscribeToNotification" par l'URL de commande « A », l'applicatif serveur « A » vérifie que le « blog » « B »

110 est bien le demandeur du désabonnement à la notification. Pour cela, il va consulter le document BlogML « B » en envoyant 1112 une action "getBlogML" à l'URL de commande « B ». L'URL de commande « B » réceptionne 1104 cette requête et renvoie 1105 son document BlogML « B » en réponse. Après réception 1113 par l'URL de commande « A », l'applicatif serveur « A » vérifie 1114 que le nœud <blog> le concernant a bien son attribut "notification" positionné à "none".

Cette vérification permet d'éviter de "fausses demandes" envoyées par un tiers.

Si une anomalie est identifiée 1115 lors de cette vérification, il renvoie une réponse 1116 de type <CmdResp type="ERROR" message="La commande a échoué"/>

Sinon 1115, il renvoie une réponse 1116 de type <CmdResp type="OK" />, et l'applicatif serveur « A » met à jour 1117 le document BlogML « A » en positionnant à "none" la valeur de l'attribut "notification" et en supprimant l'attribut "notifParam" du nœud <blog> correspondant au « blog » « B » 110, comme décrit dans l'exemple de document XML suivant : <blogml>

<bloglist>

<out>

<blog state="accepted" notification="none"> <name>Nom du» blog »B</name> <url>URL du» blog »B</url> <urlCmd>URL "Command" du» blog »B</urlCmd> </blog>

</out>

</bloglist> </blogml>

Ajout d'un article :

Lorsque le propriétaire « A » ajoute 1201 un article à son « blog A » 120, l'applicatif serveur « A » va automatiquement consulter 1202 le document

BlogML « A » pour identifier les « blogs » du nœud <out> du nœud <bloglist> s'étant abonnés à la notification. Pour chaque « blog » ayant demandé à être notifié, il extrait 1203 la méthode de notification (mail, sms ou mms) et le paramètre associé (adresse mail ou n° de mobile). Ensuite, il effectue les traitements d'envoi 1204 de mail, sms ou mms afin d'informer les blogs à notifier de la publication d'un nouvel article dans le « blog » « A » 120.

A la réception de cette notification 1211 par le « blog » « B » 121, le nouvel article peut être consulté 1212 dans le « blog » « B » 121.

6.5.4 Obtention des informations sur le propriétaire d'un « weblog ». On présente en relation avec la figure 13, un mode de réalisation de l'obtention par le « weblog » « B » 130 des informations sur le propriétaire d'un « weblog » « A » 131.

L'obtention 1301 des informations sur le propriétaire d'un « weblog »

« A » 131 se fait via l'envoi 1302 de l'action "getBlogML" à l'URL de commande « A ». Une fois réceptionnée 1311 par l'URL de commande « A », cette commande renvoie 1312 en retour une réponse « http » contenant le document

BlogML du « blog » « A ». Après réception 1303 par l'URL de commande « B », un dispositif doté d'un extracteur XML peut ensuite extraire 1304 les informations sur le propriétaire du « blog » « A » 131 contenues dans le nœud <owner>. Ces informations peuvent être :

Le nom complet du propriétaire ; Le nom et/ou le prénom ; L'adresse de courrier électronique ; Le numéro de téléphone mobile ; - L'URL d'une photo du propriétaire ;

L'URL du document FOAF du propriétaire.

Ces informations sont alors mises à disposition 1305 de l'applicatif serveur « B ».

6.5.5 Obtention des informations sur les « weblogs » préférés d'un « weblog ». On présente en relation avec la figure 14, un mode de réalisation de l'obtention par le « weblog » « B » 140 des informations sur les « weblogs » préférés d'un « weblog » « A » 141.

L'obtention 1401 des informations sur les « weblogs » préférés d'un

« weblog » « A » se fait via l'envoi 1402 de l'action "getBlogML" à l'URL de commande « A ». Une fois réceptionnée 1411 par l'URL de commande « A », cette commande renvoie 1412 en retour une réponse « http » contenant le document BlogML du « blog » « A » 141. Après réception 1403 par l'URL de commande « B », un dispositif doté d'un extracteur XML peut ensuite extraire

1404 les informations du « blog » « A » 141 contenues dans le nœud <in> du nœud <bloglist>. Pour chaque « blog » de cette liste, les informations suivantes peuvent être accessibles :

Le nom du « blog » ; L'URL du « blog » ;

L'URL de commande du « blog » (ce qui peut donner accès à toutes les informations de ce « blog » via l'action "getBlogML").

Ces informations sont alors mises à disposition 1405 de l'applicatif serveur « B ».

6.5.6 Obtention des informations sur les « weblogs » se référant à un « weblog ». On présente en relation avec la figure 15, un mode de réalisation de l'obtention par le « weblog » « B » 150 des informations sur les « weblogs » se référant à un « weblog » « A » 151.

L'obtention 1501 des informations sur les « weblogs » se référant à un « weblog » « A » se fait via l'envoi 1502 de l'action "getBlogML" à l'URL de commande « A ». Une fois réceptionnée 1511 par l'URL de commande « A »,

cette commande renvoie 1512 en retour une réponse « http » contenant le document BlogML du « blog » « A » 151. Après réception 1503 par l'URL de commande « B », un dispositif doté d'un extracteur XML peut ensuite extraire 1504 les informations du « blog » « A » 151 contenues dans le nœud <out> du nœud <bloglist>. Pour chaque « blog » de cette liste, les informations suivantes peuvent être accessibles :

Le nom du « blog » ;

L'URL du « blog » ;

L'URL de commande du « blog » (ce qui peut donner accès à toutes les informations de ce « blog » via l'action "getBlogML").

Ces informations sont alors mises à disposition 1505 de l'applicatif serveur « B ».

Il est clair que l'invention ne se limite pas à ces descriptions de modes de réalisation. Les traitements réalisés par les URL de commande, notamment, peuvent être localisés sur d'autres serveurs et/ou faire l'objet d'une centralisation.

Encore dans un autre mode de réalisation, il est possible également que les fichiers XML contenant les données informationnelles spécifiques des sites web soient également localisés sur d'autres serveurs et/ou faire l'objet d'une centralisation afin de garantir, par exemple, la confidentialité de certaines données présentes dans ces fichiers.