FR2952204A1 - Procede de generation d'un flux web et un systeme associe - Google Patents

Abstract

La présente invention concerne un procédé de génération d'un flux web (10) composé d'entrées (12) correspondant à des éléments de contenu (14), et un système associé. Le procédé comprend les étapes consistant à: a. déterminer (E110) un nombre (NIA) d'éléments de contenu à ajouter à un flux web (10), en fonction d'un nombre (NI) d'éléments de contenu à publier disponibles (20) et d'une période prédéfinie de visibilité (T) associée audit flux web, b. sélectionner (E120) ledit nombre d'éléments de contenu (14) parmi lesdits éléments de contenu à publier (20), et c. créer (E135, E140), dans ledit flux web (10), des entrées (12) correspondant auxdits éléments sélectionnés (22).

Description

La présente invention concerne un procédé de génération d'un flux web et un système associé. Les flux web notamment de syndication, ou "Web Feecf' selon la terminologie anglo-saxonne, sont largement utilisés sur l'Internet notamment, pour informer des utilisateurs sur des contenus disponibles (résumé d'articles publiés sur le site web), pour les avertir de la mise à jour de contenus (photos, mise à jour de logiciels, etc.) sur un site web ou encore pour délivrer des informations structurées telle que la météo. Ces flux sont généralement publiés par le site web en question et accessibles par les utilisateurs s'étant abonné à ces flux, au travers notamment d'un agrégateur de flux web ou d'un lecteur de flux web. Les flux web prennent la forme d'un document, généralement basé sur le format XML ("eXtensible Markup Language"), définissant dans une première partie, un ensemble de propriétés relatives à ce flux (par exemple son nom, l'adresse à laquelle il peut être trouvé, ou la date de la dernière mise à jour), puis, dans une seconde partie, un ensemble d'entrées associées aux contenus. Chaque entrée du flux web décrit des éléments de contenu (ou "items") au moyen d'un identifiant unique au sein du flux web et d'informations relatives au contenu: par exemple, une date de publication, un titre, éventuellement un résumé et d'autres détails. Ainsi, chaque entrée représente un ou des éléments de contenu (article, photo,...) publiés sur un ou plusieurs serveurs web. Du fait que ces flux web sont écrits dans un format XML standard destiné à décrire la publication d'un contenu, les flux web peuvent facilement être traités par des applications, contrairement aux fichiers HTML ("HyperText Markup Language") que l'on visualise dans un navigateur web lorsque l'on consulte un site internet.

Des applications ont pu ainsi voir le jour, par exemple celle par laquelle un site Internet affiche automatiquement, sur ses propres pages, un résumé des contenus publiés sur un autre site web. Grâce au flux web, cette application est devenue aisée à mettre en place, puisqu'elle consiste, pour le premier site Internet, à simplement récupérer le flux web de l'autre site par un abonnement classique et ainsi obtenir un résumé des contenus de l'autre site. Egalement, la mise en place de lecteurs de flux ("Feed Reader" selon la terminologie anglo-saxonne) offre de multiples possibilités pour un utilisateur. Un lecteur de flux est un programme auquel l'utilisateur va indiquer certains flux web à surveiller. C'est ce que l'on appelle s'abonner à un flux web. Le lecteur se charge alors de récupérer périodiquement le flux web dans le but de déterminer si des mises à jour ont été effectuées. Le cas échéant, le lecteur de flux peut indiquer à l'utilisateur, par exemple au moyen d'un affichage spécifique, que de nouvelles données sont disponibles.

Le lecteur peut également afficher directement le flux web tel que périodiquement récupéré, offrant ainsi des applications de type météo, bourse, dernières nouvelles, etc. Un avantage notable du flux web est qu'en s'abonnant, l'utilisateur n'a plus besoin d'aller sur chaque site pour vérifier si des mises à jour ont été effectuées. En effet, il lui suffit de consulter son lecteur de flux, et si certaines mises à jour l'intéressent, il peut alors se rendre sur le site concerné afin d'obtenir plus de détails, éventuellement via un lien directement intégré dans les entrées du flux web. Les standards principaux de flux web sont connus sous les 25 terminologies RSS, pour "Really Simple Syndication" (Syndication Vraiment Simple) dans la version RSS 2.0, et Atom (RFC 4287 de l'IETF). La figure la montre un exemple de flux RSS, dans lequel une entrée <item> (correspondant à un élément de contenu) comprend un titre <title>, un lien <link> (adresse à laquelle la ressource peut être consultée), une 30 description <description>, une date de publication <pubDate> et un identifiant <guid>.

La figure lb montre un exemple de flux web selon le format concurrent Atom, dans lequel on observe la présence, au sein d'une entrée <entry>, d'un titre <title>, d'un lien <link>, d'un identifiant <id>, d'une date de mise à jour <updated> et d'un résumé <summary>. Le format Atom a été développé pour résoudre certains problèmes inhérents au format RSS, notamment concernant les données contenues dont le type peut être indiqué avec Atom, ou encore vis-à-vis de la gestion de contenu en plusieurs langues. Afin de garantir une consultation efficace des entrées des flux et de ne pas surcharger les utilisateurs avec un trop grand nombre d'informations, ces flux web contiennent généralement un nombre limité d'entrées. Par exemple, avec une limite de 20 entrées, le flux web en question contient les 20 derniers éléments de contenus publiés. Dans les mécanismes actuellement mis en oeuvre, la mise à jour des flux web consiste à ajouter de nouvelles entrées correspondant aux éléments de contenu à publier (ceux qui n'ont jamais été insérés dans le flux web) dès que ceux-ci sont disponibles. C'est notamment le cas des plateformes de blog. Certaines options permettent toutefois de définir une date ou une fréquence à laquelle les nouveaux articles du blog doivent être publiés dans le flux RSS.

Or, il est courant, dans certains cas, que les éléments de contenu à publier deviennent disponibles à un rythme irrégulier, auquel cas il peut arriver que le nombre d'éléments de contenu à publier dans le flux web excède le nombre d'entrées formant ce flux. Dans notre exemple, même si l'on a 100 nouveaux éléments de contenu à publier, seuls 20 peuvent être décrits dans le flux web. Avec les mécanismes classiques, le flux va donc décrire uniquement les 20 derniers éléments de contenu, les 80 premiers éléments n'apparaissant eux pas dans le flux web. De même, dans le cas où ces 100 éléments de contenu à publier seraient obtenus dans un court intervalle de temps (par exemple un nouvel élément à chaque minute), même si tous les éléments sont à un moment décrits dans le flux, la période pendant laquelle ils seront visibles dans le flux sera courte (ici, 20 minutes). Cette période de visibilité peut être jugée insuffisante : en effet, dans de nombreux cas, la fréquence de consultation d'un flux web par un utilisateur est généralement sensiblement inférieure (par exemple une ou deux fois par jour) à cette fréquence de visibilité.

Dans les deux cas, il résulte donc que les 80 premiers éléments de contenu n'ont pas une bonne visibilité. Il existe donc un besoin d'améliorer, au travers des flux web, la visibilité de nouveaux éléments de contenu à publier qui sont créés à un rythme irrégulier.

La présente invention vise à résoudre les inconvénients des techniques antérieures et, en particulier, à répondre à ce besoin. Dans ce dessein, l'invention concerne notamment un procédé de génération d'un flux web composé d'entrées correspondant à des éléments de contenu, le procédé comprenant les étapes consistant à : a. déterminer un nombre d'éléments de contenu à ajouter à un flux web, en fonction d'un nombre d'éléments de contenu à publier disponibles et d'une période prédéfinie de visibilité associée audit flux web, b. sélectionner ledit nombre d'éléments de contenu parmi lesdits éléments de contenu à publier, et c. créer, dans ledit flux web, des entrées correspondant auxdits éléments sélectionnés. L'invention permet de sélectionner des éléments de contenu à ajouter effectivement dans le flux, ces éléments à ajouter étant un sous-ensemble de l'ensemble d'éléments de contenu à publier disponibles. Les éléments disponibles sont les nouveaux éléments de contenu correspondant aux éléments jamais insérés dans le flux et qui sont disponibles à l'être. La période de visibilité définit une durée minimale pendant laquelle on souhaite que chaque élément de contenu apparaisse dans le flux web. La première réalisation de la détermination des éléments de contenu à publier dans le flux peut définir un instant initial. Ensuite, on mesure le temps à partir de cet instant, et à chaque multiple de la période de visibilité, on peut répéter l'étape de détermination. Ainsi, on pourra par exemple réaliser la détermination chaque jour à minuit. Selon l'invention, on adapte le nombre d'éléments à ajouter en fonction du débit d'entrée, c'est-à-dire de tous les éléments disponibles à cet instant plus ceux futurs fonction de la période de visibilité définie (et qui arriveront donc pendant cette période). Ainsi, on anticipe le trafic à venir pour ajuster au mieux les ajouts. Aussi, l'invention permet de ne pas insérer nécessairement tous les éléments de contenu à publier, certains pouvant être mis de côté pour une insertion lors de la période suivante sans inconvénient important pour l'utilisateur. En ajustant le nombre d'éléments insérés périodiquement lors d'une période de visibilité, l'invention permet de réguler la création irrégulière des éléments de contenus, tout en permettant une meilleure visibilité ou exposition de ces éléments pendant cette période.

L'invention s'applique en particulier aux contenus dont une publication immédiate via le flux web n'est pas nécessaire. En effet, s'il est préférable pour un site traitant l'actualité de publier aussi vite que possible les informations qui lui parviennent, ce n'est pas nécessaire pour un site sur lequel sont publiés des articles de fond, ni pour un site sur lequel une personne publie ses photos. Dans la plupart des cas, on crée une entrée pour chacun des éléments de contenu sélectionné. Toutefois, dans un mode de réalisation, le procédé comprend une étape consistant à grouper lesdits éléments sélectionnés en sous-groupes, et une étape d'ajout, audit flux web, d'une entrée par sous-groupe ainsi formé. Grâce à ce regroupement, on utilise une seule entrée du flux web pour insérer les informations relatives à plusieurs éléments de contenu à publier. Cette disposition permet de réguler l'insertion des éléments de contenu à publier alors que le nombre de ces derniers peut s'avérer être occasionnellement très élevé.

En particulier, ledit regroupement des éléments est fonction d'un critère de priorité associée à chacun desdits éléments. On permet ainsi de favoriser certains contenus dont la diffusion via le flux web doit être la plus immédiate possible. Notamment, au moins deux sous-groupes sont créés selon le critère de priorité, et le procédé comprend une étape de détermination d'un nombre d'entrées à créer dans ledit flux pour chacun desdits sous-groupes. En variante ou en combinaison, ledit regroupement des éléments est fonction d'un critère temporel de création desdits éléments. Cette disposition s'appuie sur le fait que deux éléments de contenu temporellement proches ont de grandes chances d'être proches en termes de contenu. On obtient ainsi des regroupements sensiblement thématiques qui facilitent la visibilité pour l'abonné.

En particulier, on itère, de façon récursive sur un groupe composé d'éléments ordonnés selon un critère temporel, un découpage dudit groupe au niveau du plus grand intervalle temporel séparant deux éléments consécutif, de telle sorte à former un nombre prédéfini de sous-groupes. Le nombre prédéfini de sous-groupes correspond généralement au nombre de nouvelles entrées à créer dans le flux web à générer. Cette réalisation est notamment simple à mettre en oeuvre. En variante, il est également possible de procéder à des regroupements par similitude de contenu, par exemple au niveau de mots clés, de catégories d'éléments de contenu, etc.

Selon une caractéristique particulière, les éléments de contenu à publier comprennent des attributs, et on détermine, pour la création d'une entrée d'un sous-groupe, un ensemble d'attributs à conserver dans ladite entrée en fonction du nombre d'éléments de contenu constituant ledit sous-groupe. Il est ainsi possible d'ajuster la quantité d'information insérée dans chaque entrée en fonction d'un nombre d'éléments, afin de limiter la taille de celles-ci et de celle du flux web. Dans un mode de réalisation de l'invention, ladite détermination d'un nombre d'éléments de contenu comprend le calcul d'un nombre garantissant un maximum prédéterminé d'éléments non sélectionnés parmi lesdits nouveaux éléments. La régulation selon l'invention permet ainsi d'étaler l'insertion des contenus sur plusieurs périodes de visibilité, toute en évitant la surcharge pour les périodes suivantes.

En particulier, ladite détermination d'un nombre d'éléments comprend l'estimation d'un nombre de nouveaux éléments à publier susceptibles d'arriver pendant ladite période de visibilité. Dans ce cas, on peut l'ajouter, audit nombre garantissant un maximum. On anticipe alors le nombre d'éléments de contenu à publier qu'il y aura lieu de traiter lors de la période de visibilité suivante, en limitant celui-ci au maximum prédéfini précédemment. Et notamment, on prévoit d'estimer un nombre prédit de nouveaux éléments susceptibles d'arriver pendant ladite période de visibilité, à partir de données historiques dudit flux web représentatives de statistiques d'arrivées, pendant les périodes de visibilité passées, d'éléments de contenu à publier. En effet, la connaissance de l'historique des mises à jour précédentes du flux web permet de savoir s'il est probable ou non que davantage d'éléments de nouveaux contenus à publier soient fournis dans un avenir proche. Selon cette disposition, on adapte donc la régulation en tenant compte de cette connaissance. Dans un mode de réalisation de l'invention, l'étape de sélection comprend une étape préalable d'ordonnancement desdits éléments à publier, et ladite sélection est opérée selon l'ordre résultant des éléments à publier. On permet ainsi de favoriser certains contenus, par exemple des contenus plus récents que certains autres à ajouter au flux web (les contenus disponibles moins récents étant potentiellement en attente d'insertion dans le flux depuis plus longtemps), mais dont on souhaite qu'ils soient ajoutés rapidement. Ainsi à titre d'exemple, si un flux décrit les photos d'un utilisateur, cet utilisateur peut souhaiter favoriser des photos en lien avec une certaine actualité (anniversaire d'un proche, événement auquel il a assisté...) par rapport à des photos de vacances. En particulier, de façon similaire au regroupement des éléments évoqué précédemment, on peut prévoir que ledit ordonnancement est fonction d'une information de priorité associée à chacun desdits éléments de contenu à publier. En variante ou en combinaison, ledit ordonnancement est fonction d'un critère temporel relatif à la création desdits éléments de contenu à publier.

Cette disposition permet notamment de favoriser la diffusion d'un contenu dans un délai raisonnable. Notamment ce critère temporel peut être appliqué de manière subsidiaire pour des éléments à publier ayant une même information de priorité.

Selon une caractéristique de l'invention, les entrées créées se substituent à des entrées d'une version précédente dudit flux web, et le nombre d'entrées créées est strictement inférieur au nombre d'entrées dudit flux web. On conserve ainsi un nombre constant d'entrées dans le flux web et au moins une entrée de la version précédente du flux. Cette entrée conservée constitue un indicateur, pour l'abonné du flux, pour savoir s'il a raté ou non une version précédente dudit flux web. En variante bien sûr, on peut substituer l'ensemble des entrées du flux, afin de fournir une rotation plus importante du nombre d'éléments de contenu.

Dans un mode de réalisation de l'invention, les entrées créées sont insérées dans ledit flux web à différents instants répartis dans ladite période de visibilité. On note que l'on retire généralement, à chaque insertion, les entrées les plus anciennes ou les moins prioritaires. Cette insertion diffuse sur la période permet un changement plus progressif du flux web.

Par ailleurs, on peut prévoir que le procédé comprend, postérieurement à ladite sélection, la réception d'au moins un nouvel élément de contenu à publier auquel est associé une information de première priorité, et la substitution, par ledit nouvel élément de contenu reçu, d'un desdits éléments sélectionnés, non encore ajouté audit flux web et auquel est associée une information de priorité inférieure à la première priorité, éventuellement la plus basse. Ainsi, grâce à l'insertion diffuse, il est possible d'insérer immédiatement tout nouvel élément d'ordre prioritaire reçu dans l'intervalle (période de visibilité), sans avoir à attendre la période suivante. Selon une caractéristique de l'invention, on conserve, lors dudit ajout des entrées, au moins une entrée dite "disponible" dans le flux web, et on substitue, au cours de ladite période de visibilité, l'entrée disponible par une nouvelle entrée décrivant un nouvel élément de contenu prioritaire reçu pendant cette période de visibilité. Ainsi, il est possible de mettre à jour aisément le flux web lors de la réception d'un nouvel élément prioritaire pendant la période de visibilité courante. Selon une autre caractéristique de l'invention, après écoulement de ladite période de visibilité, on réitère les étapes a), b) et c) sur les éléments de contenu non sélectionnés et des éléments de contenu nouvellement reçus pendant ladite période de visibilité. En effet, il se peut que des nouveaux éléments de contenus soient reçus durant cette période de temps. Dans ce cas, on applique à nouveau le traitement sur l'ensemble des éléments de contenu à publier, y compris les éventuels éléments de contenus nouvellement reçus. Si nécessaire, on peut prolonger ladite période de visibilité d'une durée inférieure à une durée prédéterminée, avant de procéder à la nouvelle itération des étapes. Cette prolongation permet de prendre en compte de nouveaux éléments reçus de façon régulière en fin de période de visibilité.

En d'autres termes, l'invention peut concerner un procédé de publication d'éléments de contenu qui comprend une première génération d'une première version du flux web selon le procédé décrit précédemment, puis la publication pendant une première période de visibilité, desdits éléments de contenu sélectionnés, au travers de la diffusion dudit flux web dans cette première version, et une deuxième génération d'une deuxième version du flux web à partir des éléments de contenu non sélectionnés lors de la première génération et d'éléments de contenu nouvellement reçus pendant ladite première période de visibilité, puis la publication pendant une deuxième période de visibilité consécutive à ladite première période de visibilité, desdits éléments de contenu alors sélectionnés, au travers de la diffusion dudit flux web dans cette deuxième version. Concernant la réitération des étapes, on réalise notamment un nombre prédéfini d'itérations des étapes a), b) et c), et la somme des nombres d'éléments sélectionnés lors desdites itérations est inférieur à un nombre maximal prédéfini pour l'ensemble des itérations. On crée ainsi une période principale (délimitée par l'ensemble des itérations) et des périodes secondaires (chaque itération) offrant une réactivité importante (nouveaux ajouts lors des périodes secondaires) tout en garantissant une visibilité pour les utilisateurs pendant la période principale. Selon une autre caractéristique de l'invention, lesdites détermination et sélection d'éléments sont opérées sur un premier équipement, lesdits éléments de contenu sélectionnés étant transmis depuis ledit premier équipement vers un serveur web, et ledit ajout est opéré sur ledit serveur web à réception desdits éléments sélectionnés. Cette application particulière permet de réguler un flux web de serveur web alors même que l'on ne contrôle pas la génération de celui-ci au niveau de ce serveur web. L'invention concerne également un procédé de génération d'une pluralité de flux web comprenant la génération de chacun desdits flux web comme décrit précédemment, lesdits flux web ayant des périodes de visibilité associées différentes. Notamment, ces dernières peuvent être des multiples de la période la plus faible: 1j, 2j, 1 semaine, etc. Cela permet, pour un même site web, de mettre à disposition plusieurs flux avec des vitesses de rafraîchissement différentes, en fonction des habitudes des utilisateurs. L'invention permet alors que chacun de ces flux web offre suffisamment de visibilité pour tous les contenus.

Corrélativement, l'invention concerne un dispositif de génération d'un flux web composé d'entrées correspondant à des éléments de contenu, le dispositif comprenant : a. un module de détermination apte à déterminer un nombre d'éléments de contenu à ajouter à un flux web, en fonction d'un nombre d'éléments de contenu à publier et d'une période prédéfinie de visibilité associée audit flux web, b. un moyen de sélection apte à sélectionner ledit nombre d'éléments parmi lesdits éléments de contenu à publier, et c. un moyen de création apte créer, dans ledit flux web, des entrées correspondant auxdits éléments sélectionnés.

Le dispositif de génération d'un flux web présente des caractéristiques et avantages analogues au procédé de génération selon l'invention. De façon optionnelle, le dispositif peut comprendre des moyens se rapportant aux caractéristiques du procédé de génération exposé précédemment. Un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprend des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de génération conforme à l'invention lorsque ce programme est chargé et exécuté par le système informatique. Un programme d'ordinateur lisible par un microprocesseur, comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé de génération conforme à l'invention, lorsqu'il est chargé et exécuté par le microprocesseur. Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - les figures la et lb représentent deux exemples de flux web respectivement selon le format RSS et selon le format Atom; - la figure 2 illustre un exemple de mise en oeuvre de la présente invention; - la figure 3 représente, sous forme d'ordinogramme, des étapes générales de génération d'un flux web selon l'invention; - la figure 4 représente, sous forme d'ordinogramme, des étapes de détermination d'un nombre d'éléments de contenu à ajouter au flux web, mise en oeuvre lors de la génération de la figure 3; - la figure 5 représente, sous forme d'ordinogramme, des étapes de sélection d'éléments de contenu à publier, mise en oeuvre lors de la génération de la figure 3; - la figure 6 représente, sous forme d'ordinogramme, des étapes 5 de regroupement d'éléments de contenu à publier, mis en oeuvre lors de la génération de la figure 3; - la figure 7 représente, sous forme d'ordinogramme, des étapes de création d'entrées de flux web à partir des éléments de contenus sélectionnés, mise en oeuvre lors de la génération de la figure 3; et 10 - la figure 8 montre une configuration matérielle particulière d'un dispositif de génération de flux web apte à une mise en oeuvre du procédé selon l'invention. On illustre tout d'abord l'invention par un exemple en référence à la figure 2. 15 Dans cet exemple, le flux web 10 est constitué de sept entrées 12 notées A à G, chaque entrée représentant un élément de contenu 14. A l'instant t, on dispose également d'un ensemble 20 de neuf éléments de contenu à publier, notés H à P, qui sont à ajouter au flux web 10. Dans cet exemple, on définit une période de visibilité T d'une journée. Cette valeur est par exemple 20 pertinente si l'on estime qu'en moyenne, chaque personne abonnée au flux le regarde une fois par jour. De plus, l'historique de soumission des éléments de contenu à publier montre que, lorsque l'on reçoit un nombre important de tels éléments de contenu, il est fréquent de recevoir, dans un futur proche, de nouveaux 25 éléments à publier. Le nombre d'éléments 20 étant supérieur au nombre d'entrées 12 dans le flux, on peut estimer préférable d'ajouter un nombre élevé de ces éléments au flux 10 car sinon, on risque de recevoir de nouveaux éléments à publier, et alors un engorgement. 30 Cependant, le nombre d'éléments à publier étant simplement légèrement supérieur au nombre d'entrées dans le flux, il n'est pas nécessaire d'opérer de groupement d'éléments. Comme illustré par la suite, le groupement d'éléments est utilisé dans le cas où le nombre d'éléments à publier est nettement supérieur au nombre d'entrées. Dans notre exemple, bien qu'il soit possible de choisir sept éléments à publier 20 pour les insérer dans le flux (auquel cas on renouvelle l'ensemble des entrées du flux), il est choisi de renouveler six entrées 12, en conservant la plus récente G. Cette dernière permet à l'utilisateur, qui consulte le flux, de savoir s'il a manqué certaines entrées (ayant déjà vu cette entrée G, l'utilisateur sait qu'il n'a rien manqué). Ensuite, on sélectionne les six éléments à publier 22 les plus anciens parmi les neuf, ici les éléments H-M, puis l'on crée une nouvelle entrée 12 pour chacun d'eux en remplacement des entrées les plus anciennes A-F. On obtient ainsi le flux web 10 diffusé pendant la période t1 =[t; t+T]. A l'issue de ce traitement de sélection et création, il reste donc trois éléments à publier 24, ici les éléments N-P, à ajouter au flux. En l'absence de nouveaux éléments à publier obtenus pendant que la période de visibilité s'écoule, ces trois éléments N-P sont ajoutés comme de nouvelles entrées au bout d'une journée (la période de visibilité). En revanche, si de nouveaux éléments de contenu à publier 26 sont obtenus durant cette période, comme illustré ici avec les éléments Q-Z, un nouveau traitement est mis en place pour déterminer le nombre d'éléments à sélectionner, pour les sélectionner et enfin pour créer des entrées correspondantes dans le flux 10. Le traitement d'une période de visibilité à l'autre peut être différent en raison notamment du nombre de ces éléments à publier sélectionnables et du caractère prioritaire de certains de ces éléments.

Dans l'exemple de la figure 2, des entrées correspondant aux éléments à publier N-S sont insérées dans le flux 10 à t+T afin d'être présentes dans le flux pendant la période de visibilité t2=[t+T; t+2T]. Les éléments non sélectionnés sont alors T-Z et utilisés lors de la modification du flux en t+2T. On constate donc que grâce à l'invention, la visibilité de chaque élément de contenu est améliorée. Ainsi, un utilisateur qui consulte le flux au moins une fois par période de visibilité ne manquera pas d'élément.

On décrit maintenant un mode de réalisation de l'invention en référence aux figures 3 à 7. On considère tout d'abord un flux web 10 dont le nombre d'entrées est limité à NEF entrées, par exemple NEF=25.

On notera toutefois que l'invention s'applique également au cas d'un flux dont le nombre d'entrées 12 n'est pas limité, auquel cas on peut, pour les besoins de l'invention, fixer arbitrairement une valeur NEF sur la base de laquelle les traitements suivants vont être réalisés, comme décrit ci-après. On fixe ou détermine par ailleurs la période de visibilité T. Cette période est définie relativement à la période attendue de consultation du flux 10 par les utilisateurs de ce flux. Elle peut notamment être fixée arbitrairement, par exemple T=24 heures ce qui permet à un utilisateur consultant le flux 10 une fois par jour d'être certain de ne manquer aucune entrée. Elle peut en variante être calculée à partir de statistiques sur la fréquence de consultation moyenne des utilisateurs, et donc varier avec le temps. Selon l'invention telle qu'illustrée précédemment en référence à la figure 2, cette période de visibilité T détermine une période minimale durant laquelle le nombre d'entrées 12 ajoutées au flux 10 n'excède pas la limite NEF du flux. On définit par ailleurs une valeur maximale, notée MAX, de nouvelles entrées 12 pouvant être ajoutées au flux 10 pendant une période de visibilité T. Par définition, MAX doit être inférieur ou égal à NEF, sans quoi on ne pourra pas garantir qu'un utilisateur consultant le flux une fois par période T ne manquera pas d'entrée. De plus, pour que l'utilisateur soit certain de ne pas avoir manqué d'entrée, on prévoit de conserver au moins une entrée commune dans le flux 10 pendant deux périodes de visibilité T successives. Dans notre exemple de la figure 2, on a MAX = NEF-1, cette relation assurant la conservation d'au moins une entrée entre deux périodes successives, tout en maximisant le nombre de nouvelles entrées possibles.

En référence maintenant à la figure 3, on décrit les étapes générales d'ajout régulé d'éléments dans un flux web 10 pour une période de visibilité T. Le procédé débute à l'étape E100 par l'obtention d'un flux web 10 composé d'entrées 12, d'une période de visibilité T, et d'un ensemble 20 de NI éléments de contenu à publier. De façon optionnelle, on obtient également des informations concernant les précédentes mises à jour du flux 10, sous forme d'un historique de ces mises à jour par exemple. On détaille l'utilisation de telles informations ci-après en référence à l'étape E230 de la figure 4.

Le traitement général se poursuit à l'étape E110 par la détermination du nombre d'éléments 20 à ajouter au flux 10, nombre noté NIA. Cette étape est détaillée ci-après en référence à la figure 4. NIA étant connu, on sélectionne, lors de l'étape E120 (détaillée ci-après en référence à la figure 5), les NIA éléments 22 à ajouter au flux 10, parmi les NI éléments de contenu à publier 20 disponibles. Si NIA est inférieur à NI, les éléments non sélectionnés 24 sont conservés et seront ajoutés ultérieurement. On évalue alors, au test E130, si NIA est supérieur au nombre MAX correspondant au nombre maximum d'entrées pouvant être ajoutées au flux 10 pendant la période de visibilité T. Dans l'affirmative, il existe plus d'éléments sélectionnés 22 pour être ajoutés que d'entrées 12 pouvant être créées. Par conséquent, on procède, lors de l'étape E135, détaillée par la suite en référence à la figure 6, à un regroupement des NIA éléments de manière à obtenir MAX entrées.

Dans la négative (si NIA n'est pas supérieur à MAX) ou bien suite à l'étape E135, on procède à la création et l'ajout des nouvelles entrées lors de l'étape E140. De façon connue en soi, la création consiste généralement à remplir les champs XML de l'entrée avec les informations de contenu correspondantes (<title>, <link>, <description>, <pubDate> et <guid> par exemple). Le traitement prend alors fin à l'étape E190 et le flux web 10 ainsi créé est transmis pendant la période de visibilité T qui s'ensuit.

Par la suite, d'éventuels nouveaux éléments de contenu à publier 26 sont reçus pendant la période de visibilité T. A l'issue de celle-ci, le procédé est répété pour traiter l'ensemble des éléments de contenu à publier alors à disposition.

On notera qu'il n'est pas strictement nécessaire de répéter le procédé à l'expiration exacte de la période de visibilité T, mais que cette dernière peut être prolongée le cas échéant, par exemple d'un maximum de T/10. En effet, si l'on remarque que l'on reçoit des nouveaux éléments juste avant la fin de la période, on peut choisir de repousser légèrement la nouvelle mise en oeuvre du procédé de sélection, afin de continuer à recevoir des nouveaux éléments régulièrement. On prend ainsi en compte un maximum d'éléments durant la prochaine exécution du traitement. En référence maintenant à la figure 4, on décrit l'étape E110 de détermination du nombre NIA d'éléments à ajouter au flux 10.

A l'étape E200, on initialise le nombre NIA à la valeur PRI correspondant au nombre d'éléments prioritaires parmi les NI nouveaux éléments. S'il n'y a pas d'élément prioritaire, NIA est initialisé à zéro. Pour cette mise en oeuvre, on peut prévoir d'associer, aux éléments de contenu, un niveau de priorité. A titre d'exemple, on peut se satisfaire de deux niveaux de priorité pour distinguer d'un côté, les éléments prioritaires (à insérer en priorité dans le flux 10), et de l'autre côté, les éléments non prioritaires (ajoutés au flux 10 une fois qu'il n'y a plus d'élément prioritaire à ajouter). Le niveau de priorité peut être une propriété réelle des éléments ou être fixé manuellement par un utilisateur. En variante, il peut être déduit de propriétés existantes. Ainsi, si l'on prend le cas où chaque élément est une mise à jour de logiciel, et que chaque mise à jour est caractérisée par un niveau de criticité, alors on peut décider que les mises à jour critiques sont vues comme prioritaires, tandis que les autres ne le sont pas.

D'autres approches plus complexes de priorité peuvent être mises en oeuvre ayant un grand nombre de priorités possibles. De telles priorités sont calculées pour chaque élément de contenu en fonction par exemple de son ancienneté, de son intérêt, de son type de donnée, etc. Un seuil de priorité, ajustable si nécessaire, permet par exemple de distinguer les éléments prioritaires de ceux qui ne le sont pas. L'intérêt de cette initialisation NIA de l'étape E200 est de garantir que tous les éléments prioritaires soient ajoutés lors de la première mise à jour du flux 10 suivant l'ajout de ces éléments à l'ensemble 20 des éléments à publier dans le flux. Ensuite, on teste à l'étape E210 si le nombre NI d'éléments à publier 20 disponibles est supérieur à rg.MAX, où rg est un paramètre de ratio de 10 groupement. Cette valeur 'rg' a pour but de définir une limite au nombre NI d'éléments, au-dessus de laquelle on estime qu'il y a trop d'éléments à ajouter. Dans ce cas, on prévoit d'ajouter, au flux 10, un grand nombre d'éléments par l'intermédiaire du groupement d'éléments comme décrit par la suite en 15 référence à la figure 6 et à l'étape E135. 'rg' est défini strictement supérieur à 1. Notamment, si l'on prend une valeur rg=2, lorsque l'on a deux fois plus d'éléments à publier 20 que le nombre maximal MAX de nouvelles entrées ajoutées au flux 10 durant une période de visibilité T, on procède à des groupements de manière à augmenter le nombre d'éléments ajoutés compte 20 tenu du nombre fixe MAX d'entrées disponibles, et donc à éviter un engorgement. Dans l'affirmative de l'étape E210, on cherche à fixer NIA de manière à ce que le nombre d'éléments restant à ajouter après l'ajout des NIA éléments soit inférieur ou égal à MAX. Pour cela, on pourrait prendre NIA = max(NI û 25 MAX, PRI), ce qui serait équivalent à ajouter, aux éléments prioritaires PRI, (NI û PRI û MAX) éléments non-prioritaires si jamais PRI est inférieur à NI û MAX. Dans ce cas, le nombre d'éléments restant à ajouter après l'ajout des NIA éléments est bien inférieur ou égal à MAX. De plus, on notera que, dans le cas où le ratio de groupement 'rg' est 30 supérieur ou égal à 2, NIA est supérieur à MAX, ce qui implique nécessairement la mise en oeuvre de groupements (étape E135).

Toutefois, si l'on prend une valeur de 'rg' comprise entre 1 et 2, la valeur NIA peut être inférieure à MAX, ce qui n'est pas avantageux puisqu'il est possible d'ajouter MAX entrées. C'est pourquoi l'on choisit, à l'étape E220, NIA = max(NI û MAX, 5 PRI, MAX). A l'étape E230, on détermine si l'on a connaissance de l'historique des mises à jour précédentes du flux 10. Dans l'affirmative, on détermine, à l'étape E240, le nombre prédit NP de nouveaux éléments à publier qui seront reçus pendant la prochaine période 10 de visibilité T. Ce nombre peut être calculé de différentes manières à partir des informations d'historique. On indique ici deux exemples à titre illustratif : - simple moyenne du nombre de nouveaux éléments reçus durant chaque période T précédente; 15 - recherche, dans l'historique, de situations analogues à la situation courante (similarité de motif représentant une suite d'éléments consécutifs, similarité du nombre d'éléments reçus, etc.), puis examen et déduction du nombre de nouveaux éléments obtenus pendant la période T suivante pour chacune de ces situations. 20 Une fois le nombre prédit NP connu, on l'ajoute au nombre NIA. De cette manière, si NP nouveaux éléments sont obtenus durant la prochaine période de visibilité T, on anticipe pour que le nombre NI d'éléments à publier 20 lors de la prochaine période vaille au plus MAX, de sorte à pouvoir ajouter tous ces éléments comme de nouvelles entrées 12 dans le flux 10 lors de la 25 prochaine mise en oeuvre du traitement de sélection et d'ajout selon l'invention. De manière similaire, si l'on ignore l'historique des mises à jour du flux (négative de l'étape E230), on ajoute, à NIA, un nombre supposé NS, lors de l'étape E250. Ce nombre NS est le nombre supposé de nouveaux éléments à publier reçus durant la prochaine période de visibilité T: NS = f(T). 30 Contrairement au nombre prédit NP, ce nombre supposé NS n'est pas déterminé à partir d'informations d'historiques. NS peut être par exemple fixé comme une certaine fraction de NEF, par exemple NEF/5 (si NEF vaut 25, cela signifie que l'on suppose que l'on a cinq nouveaux éléments par période T). Cette fraction peut être ajustée si on modifie la période T. On peut aussi prendre simplement NS = 0, en particulier si l'on suppose que les nouveaux éléments arrivent de manière très irrégulière.

A l'issue des étapes E240 et E250, on affecte à NIA, la valeur minimale entre NIA et NI: NIA = min(NIA, NI), lors de l'étape E280. Cette étape garantit que la valeur NIA reste inférieure ou égale à NI. Le procédé prend alors fin à l'étape E290. Dans la négative de l'étape E210 (NI n'est pas supérieur à rg.MAX), on évalue à l'étape E260 si la valeur NIA est inférieure à MAX, c'est-à-dire s'il y a moins d'éléments prioritaires qu'il n'y a d'entrées 12 à créer. C'est notamment le cas s'il n'y a pas d'élément prioritaire puisque, dans ce cas, NIA vaut 0. Dans l'affirmative, on change la valeur de NIA à l'étape E270 en choisissant comme nouvelle valeur la plus petite valeur entre MAX et NI: NIA = min(MAX, NI), de sorte à permettre l'insertion d'éléments de contenu non prioritaires à publier. Puis, le traitement prend fin (étape E290). Dans le cas où NIA n'est pas inférieure à MAX (négative de l'étape E260, signifiant qu'il y a un nombre d'éléments prioritaires supérieur au nombre MAX), le traitement prend fin directement (étape E290), correspondant au souhait d'ajouter tous les éléments prioritaires et uniquement ceux-là. On voit donc que cette détermination du nombre NIA vise à ajouter autant d'éléments à publier 20 que possible durant chaque période T. En particulier, dès que NI est supérieur à MAX, on ajoute au moins MAX éléments, et si NI est inférieur à MAX, alors tous les éléments sont ajoutés.

Toutefois, il convient de remarquer que selon les valeurs de MAX et de 'rg', des comportements sensiblement différents sont possibles. Ainsi, si l'on prend par exemple MAX = NEF û 1, et rg = 2, il est possible d'ajouter, au flux 10, un grand nombre d'éléments 20 rapidement: lors de chaque période, si NI est supérieur à MAX, on ajoute au moins NEF û 1 entrées 12, soit un renouvellement quasi complet flux 10 ; dans le cas où NI dépasse le double de MAX, il y a au maximum MAX éléments 20 qui ne sont pas ajoutées, ce qui signifie qu'au pire, les éléments sont publiés durant la deuxième période de visibilité T après leur réception. Ces paramètres conviennent notamment lorsque l'on souhaite une publication rapide des éléments de contenu dans le flux 10. A l'opposé, si l'on fixe les paramètres suivants: MAX = 1 et rg = 100, au lieu d'ajouter très rapidement les entrées au flux, il est probable que l'on stockera, pendant de nombreuses périodes T, un certain nombre d'éléments. Par exemple, si on reçoit 25 nouveaux éléments de contenu, alors il faudra attendre 25 périodes avant que le dernier ne soit ajouté au flux 10. Ces paramètres conviennent ainsi dans le cas où l'on souhaite avoir une nouvelle entrée 12 lors de chaque période T. Suivant l'application visée, il est donc possible de définir différemment les paramètres (MAX, rg) intervenant dans le choix de NIA. De plus, indépendamment des paramètres MAX et rg évoqués, il est aussi possible de modifier, dans le cas où l'on groupe les éléments (étape E135), le calcul de NIA à l'étape E220. Dans ce cas, la formule NIA = NI ù MAX aboutit à l'ajout d'un grand nombre d'éléments, mais on peut souhaiter utiliser une formule plus progressive, par exemple NIA = MAX + (NI ù rg.MAX)*ka, où ka est une constante positive inférieure ou égale à 1. Avec une telle formule, dans le cas où NI vaut rg.MAX, on ajoute MAX éléments, comme on le ferait (via les étapes E260 et E270) dans le cas où NI vaudrait rg.MAX ù 1 : on assure donc une forme de continuité quelle que soit la valeur de 'rg'. Une fois la détermination du nombre NIA d'éléments à ajouter au flux effectuée, il convient de procéder à la sélection de ces éléments parmi les éléments de contenu à publier 20 disponibles. Cette opération, correspondant à l'étape E120, est décrite maintenant en référence à la figure 5, où l'on cherche à sélectionner K (K valant généralement NIA sauf pour certaines variantes décrites plus loin) éléments. La sélection débute par l'obtention, à l'étape E300, de critères d'ordonnancement par ordre décroissant d'importance. Les critères d'ordonnancement considérés peuvent être choisis parmi un ensemble composé de données temporelles (date et heure à laquelle l'élément a été créé), d'une information de priorité (élément prioritaire ou non) ou d'autres attributs d'élément (langue de l'élément de contenu, type de l'élément de contenu, etc.). A titre d'exemple, on peut prendre, comme premier critère, le niveau de priorité, et, comme second critère, les données temporelles (et en l'absence d'un niveau de priorité, les données temporelles seules). A l'étape E310, on détermine s'il reste un critère C non pris en compte. Dans l'affirmative, on ordonne les éléments à publier 20 suivant le critère C (étape E320), puis l'on retourne à l'étape E310 pour considérer un critère suivant moins important. Si l'on a plus d'un critère C, alors chaque critère n'est pas appliqué de manière absolue pour ordonner la liste, mais relativement à l'ordonnancement préalablement obtenu, c'est-à-dire qu'un critère C2 intervenant après un critère Cl viendra uniquement modifier l'ordonnancement d'éléments étant équivalents pour le critère Cl.

Ainsi, dans le cas où les deux critères considérés sont le niveau de priorité et les données temporelles, on ordonne donc les éléments à publier de manière à avoir d'abord ceux dont le niveau de priorité est haut, puis ceux dont le niveau de priorité est bas, et on ordonne ensuite chacun de ces deux groupes en fonction des informations temporelles, l'élément le plus ancien arrivant en premier. Dans la négative de l'étape E310 (il ne reste plus de critère à considérer), les éléments sont ordonnés, et il suffit de sélectionner les K premiers dans la liste ordonnée. Le traitement prend alors fin à l'étape E390.

Disposant de ces NIA éléments sélectionnés 22, un regroupement peut être opéré (E135) pour satisfaire la contrainte des MAX entrées disponibles, si NIA > MAX. Ce regroupement vise ainsi à intégrer au sein d'au moins une même entrée 12 du flux, plusieurs éléments de contenu sélectionnés. Cette opération est décrite maintenant en référence à la figure 6, où l'on cherche à regrouper les NIA éléments sélectionnés 22 en NE entrées (NE = MAX généralement).

Le traitement débute à l'étape E400 par l'obtention des NIA éléments considérés. A l'étape E410, on détermine si des éléments prioritaires sont présents parmi les NIA éléments et si le critère de priorité est pris en compte.

Dans la négative, les NIA éléments sont groupés en NE entrées lors de l'étape E480, décrite ci-après en référence à la figure 7, et le traitement prend fin à l'étape E490. Dans l'affirmative, on dénombre, à l'étape E420, le nombre NIAP d'éléments prioritaires à ajouter, ainsi que le nombre NIANP d'éléments non prioritaires à ajouter. En fonction de ces nombres NIAP et NIANP, on va alors déterminer un nombre NEP d'entrées 12 que l'on va utiliser pour décrire les NIAP éléments prioritaires, ainsi qu'un nombre NENP d'entrées 12 que l'on va utiliser pour décrire les NIANP éléments non prioritaires. On cherche ici à grouper les éléments de contenu prioritaires entre eux, et les éléments de contenu non prioritaires entre eux également. Bien entendu, un plus grand nombre de priorités peut être pris en compte, le procédé pouvant alors être adapté sans difficulté. Pour cela, on définit un facteur 'kp', strictement supérieur à 1, qui correspond à l'importance accordée aux éléments prioritaires par rapport aux éléments non prioritaires (et tendant à grouper plus ou moins les éléments prioritaires). Typiquement, 'kp' peut prendre la valeur 3. Cette valeur est fixée par exemple par la personne responsable de la publication des contenus. Ainsi, à l'étape E430, on détermine le nombre NEP en calculant par exemple la valeur kp*NIAP*NE / (kp*NIAP + NIANP) arrondie à l'entier supérieur. Si cette valeur est inférieure ou égale à NIAP, alors on la choisit comme valeur de NEP. Sinon, cela signifie que l'on dispose potentiellement de plus d'entrées que d'éléments prioritaires, et par conséquent on choisit NEP = NIAP. Ainsi, NEP = min(NIAP, [kp*NIAP*NE / (kp*NIAP + NIANP)1) où [xl est l'entier supérieur de x.

On crée alors, à l'étape E440, NEP entrées à partir des NIAP éléments prioritaires, en mettant en oeuvre les étapes décrites ci-après en lien avec la figure 7. Ensuite, à l'étape E450, on détermine la valeur NENP = min (NE û 5 NEP, NIANP). On crée alors, à l'étape E460, NENP entrées décrivant les NIANP éléments non prioritaires, en mettant en oeuvre les étapes décrites ci-après en lien avec la figure 7. Le traitement prend alors fin à l'étape E490. 10 Dans certains cas, les formules précédentes peuvent aboutir à une valeur de NEP égale au nombre NE d'entrées à créer, bien que NIANP soit non nul. Si l'on souhaite éviter de se retrouver dans cette situation, on peut décider que, à partir du moment où NIAP et NIANP sont non nuls, la valeur minimale de NEP et NENP est égale à 1. Dans ce cas, on décide que si NEP et NE sont 15 égaux à l'issue de l'étape E430, on diminue NEP de 1 ; de la sorte, NENP vaudra 1 et non O. On décrit maintenant, en référence à la figure 7, la création de L entrées 12 à partir de K éléments sélectionnés 26, notamment mise en oeuvre lors des étapes E440, E460 et E480 (respectivement L=NEP, K=NIAP ; 20 L=NENP, K=NIANP ; L=NE, K=NIA). On débute à l'étape E500 par l'obtention des K éléments à grouper en L entrées, K étant supérieur à L. On détermine alors, à l'étape E510, L groupes d'éléments parmi les K éléments. 25 Selon une première approche basique, on peut définir chaque groupe comme une succession de K/L éléments (arrondi à l'entier supérieur): par exemple le premier groupe étant composé du premier au rK/Llème élément, le deuxième groupe du [K/L+11ème au r2K/Llème élément, etc. Selon une autre approche, si on dispose des dates et heures de 30 création des éléments, on crée des groupes qui rassemblent des éléments ayant été créés à des instants proches. En effet, cette corrélation temporelle peut signifier une corrélation dans le contenu des éléments et donc une meilleure visibilité pour l'abonné au flux 10. Pour cela, on ordonne les éléments selon ces dates et heures de création, on mesure les intervalles de temps entre la création de deux éléments consécutifs, puis on crée, de façon récursive, des groupes en divisant un groupe en deux au niveau de l'intervalle le plus grand (le groupe de départ étant constitué par l'ensemble des K éléments). On procède ainsi L-1 une fois jusqu'à obtenir L groupes. Selon une autre approche, si l'on dispose par exemple de mots clés 10 ou de catégories associées aux K éléments, on procède à un regroupement par mêmes mots clés ou par similitude de catégorie. Une fois les groupes formés, on crée, pour chacun d'eux, une entrée 12 correspondante prévue pour être ajoutée au flux 10. Pour cela, à l'étape E520, on détermine s'il reste un groupe non 15 traité. Dans l'affirmative, on sélectionne, pour chaque élément composant le groupe, les détails de l'élément de contenu qu'il convient de préserver (étape E530), par exemple le titre, un résumé et une date de publication. Cette sélection E530 fait intervenir deux considérations 20 antagonistes : d'un côté, on souhaite préserver suffisamment de détails pour rendre chaque élément visible, mais de l'autre, on ne souhaite pas inclure trop de détails car il est important de conserver un flux 10 d'une taille raisonnable (d'où le nombre limité d'entrées 12). Par conséquent, on prévoit d'ajuster le niveau de détails conservés en fonction du nombre d'éléments présents dans le 25 groupe : si l'on a par exemple seulement deux éléments, alors on conserve l'essentiel des détails (par exemple le titre, l'adresse à laquelle l'élément est consultable, mais aussi le résumé ou le commentaire ou la description si de tels champs existent) ; en revanche, si l'on a une dizaine d'éléments, on ne conserve que les informations essentielles (par exemple le titre et l'adresse à 30 laquelle cet élément est consultable).

Une fois les détails à préserver pour chaque élément du groupe sélectionnés, on crée l'entrée 12 correspondante à l'étape E540, cette entrée comprenant l'ensemble des détails précédemment sélectionnés. Comme pour une entrée classique de flux web 10, une entrée décrivant un groupe d'éléments peut par exemple posséder un titre, une date de publication ou de mise à jour, un identifiant, ou encore un lien décrivant l'adresse à laquelle la ressource est consultable. Toutefois, puisqu'il existe plusieurs éléments dans cette unique entrée, on prévoit une logique pour décrire ces différents éléments dans cette unique entrée 12.

Concernant le titre, on peut par exemple indiquer le nombre d'éléments, ainsi que le titre de l'un des éléments (l'élément choisi peut alors être qualifié de principal û ce choix peut être basé sur des propriétés de l'élément, par exemple une priorité, une note choisie par le créateur de l'élément, ou un degré d'ancienneté). En particulier, si l'on connaît la nature des éléments (articles, photos, vidéos...), on peut ajouter, à la suite de l'un des titres, le nombre d'éléments en précisant leur nature (par exemple "Tour Eiffel et 10 autres photos" dans le cas où les éléments sont des photos et où l'une des photos a pour titre "Tour Eiffel"). Concernant l'adresse à laquelle la ressource peut-être consultée, on peut par exemple choisir l'adresse de l'élément principal ainsi défini. Ensuite, afin de décrire l'ensemble des éléments, on peut utiliser le champ/la balise <description> propre à une entrée d'un flux RSS, ou la balise <content> dans le cas d'un flux Atom. En effet, il est possible d'inclure différents liens dans ces champs, et notamment donc d'inclure un lien vers chaque élément, ainsi que le titre de chaque élément. Comme expliqué précédemment, s'il y a peu d'éléments (par exemple deux), on peut chercher à inclure davantage de détails (par exemple un éventuel résumé ou commentaire relatif à l'élément). Dans le cas d'un flux Atom, il est aussi possible d'ajouter des balises <link> avec un attribut <rel> de valeur "related", et des attributs <href> indiquant les adresses des éléments contenus dans cette entrée. En effet, ces balises visent à décrire des ressources en rapport avec l'entrée.

Après avoir créé l'entrée 12 à l'étape E540, on retourne alors à l'étape E520 pour traiter le groupe suivant. Quand il ne reste plus de groupe non traité, le traitement prend fin (étape E590). On voit donc que ce mode de réalisation de l'invention propose une méthode pour déterminer un nombre d'éléments de contenu à publier à un flux web durant une période de visibilité, période durant laquelle on reçoit d'autres nouveaux éléments de contenu et on suppose qu'un utilisateur abonné au flux consultera ce flux au moins une fois, ces éléments de contenu étant par la suite sélectionnés parmi les éléments de contenu restant à publier en utilisant un critère d'ordonnancement Dans le cas où le nombre d'éléments de contenu à publier devient trop grand, l'invention permet de grouper plusieurs éléments de contenu ensemble sous la forme d'une seule entrée dans le flux web considéré. Il en résulte une amélioration notable de la visibilité d'éléments de contenu publiés grâce à cette régulation de leur insertion dans les flux web. On présente maintenant différentes applications de la régulation selon l'invention. En particulier, elle s'applique au contrôle indirect de la génération d'un flux web par un site web. En effet, il n'est pas toujours possible de contrôler la génération du flux web sur le serveur web. Par exemple, si un utilisateur possède un compte sur un site fournissant un service de publication de photos en ligne qui génère un flux web décrivant les 25 dernières photos qu'il a envoyées, il lui est impossible de modifier le générateur de flux web fourni par ce site.

La mise en oeuvre de l'invention peut permettre à l'utilisateur de réguler l'envoi de ses photos sur le site et donc le flux web généré. Dans ce cadre, l'utilisateur indique par exemple une liste de photos et les informations relatives à son compte sur le site de publication de photos, et l'application se charge ensuite d'envoyer les photos au site de manière régulée: à chaque ajout de photo, le générateur de flux web du site met le flux à jour, et de ce fait, le flux est indirectement régulé.

Néanmoins, il convient de remarquer que dans un tel cas, les fonctionnalités relatives au groupement des éléments à publier (ici, groupement de plusieurs photos en une seule entrée du flux) ne peuvent être fournies, au mieux, que de manière dégradée. En particulier, puisque l'on ne contrôle pas la génération du flux, on ne peut pas grouper des contenus distincts dans une seule entrée, mais seulement fusionner ces contenus avant de les envoyer sur le serveur (où ils ne seront alors vus que comme un seul contenu accessible à une adresse, et non comme un ensemble de contenus, chaque contenu disposant de sa propre adresse).

En variante, si plusieurs services sont utilisés (par exemple un pour le stockage des contenus, et un pour la génération du flux), l'invention peut être utilisée pour envoyer de manière coordonnée les différentes informations utiles à chaque service. Une autre application de l'invention concerne la génération de 15 plusieurs flux web décrivant un même contenu. Comme on a pu voir précédemment, l'un des paramètres pris en compte par l'invention est la période de visibilité T, correspondant à la période pendant laquelle on suppose que l'utilisateur abonné va consulter le flux web. Toutefois, tous les abonnés n'ont pas le même rythme de consultation et 20 certains consultent de façon plus fréquente et d'autres de façon moins fréquente. Pour ceux-ci, on prévoit la génération parallèle de plusieurs flux web décrivant les mêmes contenus, chaque flux correspondant cependant à une période de consultation différente. On peut ainsi disposer, sur un site, d'un flux dont la période T 25 vaudrait une journée, d'un autre flux dont la période T vaudrait deux journées, et d'un troisième dont la période T vaudrait une semaine. En indiquant aux utilisateurs la période relative à chaque flux, ceux-ci peuvent alors s'abonner au flux qui correspond le mieux à leur fréquence de consultation. Cette disposition répartit les contenus de la semaine en sept périodes journalières pour le flux de 30 plus faible période de visibilité (et donc potentiellement sept fois plus d'entrées 12 que dans le cas d'une période T valant une semaine). Cela permet aux utilisateurs abonnés à ce flux journalier d'accéder à des entrées plus détaillées sur chaque élément de contenu. Comme évoqué précédemment, les périodes de visibilité peuvent être variables et tenir compte par exemple de contraintes professionnelles: si le flux web n'est par exemple pas consulté le week-end, il n'y a pas de mise à jour le samedi ou le dimanche. On décrit maintenant l'utilisation de l'invention dans le cadre des extensions FeedSync prévues pour les formats RSS et Atom. Les extensions FeedSync permettent la synchronisation de différentes versions d'un flux représentant les mêmes informations. Ainsi, si l'on utilise un flux Atom pour décrire une collection de photos, il se peut que l'on télécharge le flux sur son ordinateur portable ou son téléphone. Une fois ce flux téléchargé, certaines applications permettent, depuis un terminal donné, de visualiser la collection de photos sans être connecté à Internet, ainsi que de modifier la collection par l'ajout ou la suppression de photos par exemple. Dans ce cas, l'application va modifier le flux en local, et FeedSync propose une manière de décrire les modifications réalisées afin de permettre une éventuelle synchronisation ultérieure avec le flux web sur le serveur source.

Dans le même temps, il se peut que le flux présent sur le serveur soit lui aussi modifié, les modifications étant elles aussi décrites avec la syntaxe FeedSync, de telle manière qu'il est possible de synchroniser la version du flux présente sur le terminal de l'utilisateur et la version présente sur le serveur. En revanche, si l'on a modifié la version locale et la version sur le serveur sans utiliser un standard commun tel que FeedSync, alors il est particulièrement difficile, voire impossible, de synchroniser les données. Dans le cadre de la présente invention, on considère tout d'abord un appareil qui peut être connecté à un réseau et qui supporte FeedSync. Pour un flux web 10 donné décrivant un ensemble de contenus, il est possible de modifier le flux par ajout, suppression ou modification de contenus. Ces contenus peuvent représenter une quantité significative d'informations (par exemple un ensemble de photographies prises au moyen d'un appareil photo numérique), or s'ils sont décrits dans un flux, c'est que l'on souhaite les partager. Par conséquent, il s'avère utile de rendre ces contenus disponibles, et donc il est nécessaire de les envoyer depuis l'appareil utilisé vers un ou plusieurs autres appareils (par exemple un serveur web).

L'envoi de ces informations, pour un appareil aux capacités limitées, représente une charge non négligeable, et il est préférable que le traitement résultant n'empêche pas d'utiliser normalement l'appareil en question (par exemple, pour un appareil photo, il est souhaitable que même pendant l'envoi des photos l'on puisse continuer à prendre d'autres photos). De façon similaire, pour certains appareils s'appuyant sur un réseau à faible débit, il est préférable de ne pas utiliser toute la bande passante pour l'opération d'envoi des contenus à partager. On constate ici qu'au moins deux facteurs peuvent amener à souhaiter limiter la quantité de données traitées dans un tel scénario : les contraintes de l'appareil utilisé ainsi que celles du réseau. Aussi, on propose d'utiliser l'invention pour limiter le nombre de contenus envoyés vers un autre appareil. Dans ce cadre, on définit une période T pouvant être relativement courte (par exemple 2 minutes), et l'on fixe le nombre NIA d'éléments à ajouter (ici, des photos à envoyer) en fonction des contraintes de l'appareil et du réseau. En particulier, on peut souhaiter limiter la bande passante utilisée pour lire des données dans une mémoire (par exemple dans une carte mémoire d'appareil photo, afin de pouvoir continuer à utiliser son appareil photo normalement pour prendre d'autres photos ou pour regarder des photos précédemment prises). Dans le cas où la limitation est relative à la mémoire, on peut utiliser la taille moyenne des contenus et une bande passante maximale autorisée pour déterminer NIA. Avec une période T courte, il est possible d'ajuster NIA en fonction de l'utilisation de l'appareil (notamment en fonction d'échanges réseau parallèles).

En référence maintenant à la figure 8, il est décrit à titre d'exemple une configuration matérielle particulière d'un dispositif ou système de génération d'un flux web apte à une mise en oeuvre du procédé selon l'invention.

Un dispositif de traitement d'information mettant en oeuvre l'invention est par exemple un micro-ordinateur 50, une station de travail, un assistant personnel, ou un téléphone mobile connecté à différents périphériques. Selon encore un autre mode de réalisation de l'invention, le dispositif se présente sous la forme d'un appareil photographique muni d'une interface de communication pour autoriser une connexion à un réseau. Les périphériques reliés au dispositif selon l'invention comprennent par exemple une caméra numérique 64, ou un scanner ou tout autre moyen d'acquisition ou de stockage d'images, relié à une carte d'entrée/sortie (non représentée) et fournissant au dispositif des données.

Le dispositif 50 comporte un bus de communication 51 auquel sont reliés : - une unité centrale de traitement CPU 52 se présentant par exemple sous la forme d'un microprocesseur ; - une mémoire morte 53 dans laquelle peuvent être contenus les 20 programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Il peut s'agir d'une mémoire flash ou EEPROM; - une mémoire vive 54 qui, après la mise sous tension du dispositif 50, contient le code exécutable des programmes de l'invention nécessaires à la mise en oeuvre de l'invention. Cette mémoire vive 54 est de type RAM (à accès 25 aléatoire), ce qui offre des accès rapide comparés à la mémoire morte 53 ; - un écran 55 permettant de visualiser des données notamment vidéo et/ou de servir d'interface graphique avec l'utilisateur qui peut ainsi interagir avec les programmes de l'invention, à l'aide d'un clavier 56 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 57 30 ou un crayon optique ; - un disque dur 58 ou une mémoire de stockage, telle qu'une mémoire de type compact flash, pouvant comporter les programmes de l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention; - un lecteur de disquettes 59 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 63 et à y lire / écrire des données traitées ou à traiter conformément à l'invention ; et - une interface de communication 60 reliée au réseau de télécommunications 61, l'interface 60 étant apte à transmettre et à recevoir des données, notamment pour transmettre le flux web généré par l'invention. Le bus de communication 51 autorise une communication et une interopérabilité entre les différents éléments inclus dans le dispositif 50 ou reliés à celui-ci. La représentation du bus 51 n'est pas limitative et, notamment, l'unité centrale 52 est susceptible de communiquer des instructions à tout élément du dispositif 50 directement ou par l'intermédiaire d'un autre élément du dispositif 50.

Les disquettes 63 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non au dispositif de génération de flux web, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Le code exécutable permettant au dispositif de génération de flux web la mise en oeuvre de l'invention peut être indifféremment stocké en mémoire morte 53, sur le disque dur 58 ou sur un support numérique amovible tel que par exemple une disquette 63 comme décrite précédemment. Selon une variante, le code exécutable des programmes est reçu par l'intermédiaire du réseau de télécommunications 61, via l'interface 60, pour être stocké dans un des moyens de stockage du dispositif 50 (tel que le disque dur 58 par exemple) avant d'être exécuté.

L'unité centrale 52 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes de l'invention, les instructions ou portions de code logiciel étant stockées dans l'un des moyens de stockage précités. Lors de la mise sous tension du dispositif 50, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 58 ou la mémoire morte 53, sont transférés dans la mémoire vive 54 qui contient alors le code exécutable du ou des programmes de l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. On notera également que le dispositif mettant en oeuvre l'invention ou incorporant celle-ci est réalisable aussi sous la forme d'un appareil programmé. Par exemple, un tel dispositif peut alors contenir le code du ou des programmes informatiques sous une forme figée dans un circuit intégré à application spécifique (ASIC). Le dispositif ou système décrit ici et, particulièrement, l'unité centrale 52, sont susceptibles de mettre en oeuvre tout ou partie des traitements décrits en lien avec les figures 2 à 7, pour mettre en oeuvre les procédés objets de la présente invention et constituer tout ou partie des systèmes objets de la présente invention. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. Notamment, on a pu décrire ci-dessus l'ajout de nouvelles entrées 12 dans le flux web 10 aux instants t+n.T, avec n entier et t le temps écoulé depuis l'instant initial. En variante toutefois, l'ajout des nouvelles entrées 12, au lieu de se faire en une seule fois, peut être réparti sur l'ensemble de la période de visibilité T. Ainsi, si l'on détermine un ensemble de NIA éléments à ajouter sous la forme de NE entrées, on peut procéder à l'ajout d'une nouvelle entrée 12 tous les k.T/NE instants, k étant un entier variant entre 1 et NE. De plus, dans cette variante, si l'on reçoit des éléments de contenu prioritaires pendant la période T courante, il est possible de remplacer un ou plusieurs éléments sélectionnés 20 non prioritaires et non encore ajoutés par ces nouveaux éléments prioritaires, de manière à ajouter plus rapidement les éléments prioritaires nouvellement reçus.

Une adaptation de cette variante consiste à sélectionner un sous-ensemble d'éléments 20 à plusieurs reprises au cours de la période de visibilité T de manière à obtenir NIA éléments au total durant la période T. A chaque reprise, seule une partie des MAX nouvelles entrées possibles est utilisée (au prorata des éléments choisis parmi les NIA éléments par exemple). A titre d'exemple, il peut s'agir de sélectionner NIA/3 éléments à trois reprises au cours de la période T. Dans ce cas, on note que pour la sélection de la figure 5, K=N IA/3 et non pas NIA. Dans une autre variante, on choisit de réserver N entrées parmi les MAX entrées disponibles dans la période T, pour N mises à jour éventuelles effectuées durant cette période T: par exemple deux entrées pour deux mises à jour éventuelles à T/3 et 2T/3. Chacune de ces entrées réservées est alors destinée à décrire les éléments prioritaires reçus depuis la dernière mise à jour du flux.

Si aucun élément prioritaire n'a été reçu depuis la dernière mise à jour, l'entrée potentiellement disponible n'est pas utilisée. C'est la raison pour laquelle il convient de bien dimensionner le nombre d'entrées réservées pour les mises à jour intermédiaires. En pratique, on insère MAX-N nouvelles entrées en conservant donc les N+1 entrées les plus récentes de la version précédente du flux 10 (le "+1" provenant du fait que NEF=MAX+1). L'entrée potentiellement disponible correspond donc à une entrée déjà existante dans la version précédente du flux. Cette entrée est donc remplacée, le cas échéant, lors de la réception d'un nouvel élément de contenu prioritaire. Enfin, dans une autre variante, on définit une période principale TP, une période secondaire TS, où TP = k.TS (par exemple TP = 24h et TS = 1h), et on définit un nombre maximal MAX_TP d'entrées pouvant être ajoutées durant la période principale TP, ainsi qu'un nombre maximal MAX_TS d'entrées pouvant être ajoutées durant chaque période secondaire TS. On applique alors l'invention pour la période secondaire TS et le nombre maximal d'entrées ajoutées MAX_TS durant cette période, mais en tenant en outre compte du fait que l'on ne doit pas ajouter plus de MAX_TP entrées durant la période TP.

L'intérêt de cette variante vient du fait qu'elle permet de publier les éléments reçus avec une meilleure réactivité (période TS), tout en garantissant qu'un utilisateur respectant la fréquence de consultation TP ne manquera aucune entrée.

On note toutefois qu'il existe un risque, dans ce cas, de déséquilibre du nombre d'éléments décrits par chaque entrée, au long de la période principale TP. En effet, il peut arriver que pendant les premières périodes TS, peu d'éléments de contenus à publier soient disponibles et qu'ils soient décrits chacun avec un nombre conséquent d'entrées 12 (par exemple une entrée par élément de contenu). Puis, il peut arriver que pendant les périodes suivantes, un grand nombre de nouveaux éléments soit reçu alors que le nombre d'entrées pouvant encore être créées reste limité. Dans ce cas, des regroupements importants doivent avoir lieu et les éléments de contenu sont décrits très succinctement, les rendant moins visibles pour l'abonné.

On peut anticiper une telle situation en forçant des regroupements lors des premières périodes TS de la période principale TP, puis en relâchant cette contrainte de regroupement plus on s'approche des dernières périodes secondaires TS.

Claims (22)

1. REVENDICATIONS1. Procédé de génération d'un flux web (10) composé d'entrées (12) correspondant à des éléments de contenu (14), caractérisé en ce qu'il 5 comprend les étapes consistant à: a. déterminer (E110) un nombre (NIA) d'éléments de contenu à ajouter à un flux web (10), en fonction d'un nombre (NI) d'éléments de contenu à publier disponibles (20, 24, 26) et d'une période prédéfinie de visibilité (T) associée audit flux web, 10 b. sélectionner (E120) ledit nombre d'éléments de contenu (14) parmi lesdits éléments de contenu (20, 24, 26) à publier, et c. créer (E135, E140), dans ledit flux web (10), des entrées (12) correspondant auxdits éléments sélectionnés (22).
2. 2. Procédé selon la revendication 1, comprenant une étape 15 consistant à grouper (E135) lesdits éléments sélectionnés (22) en sous-groupes, et une étape d'ajout (E140), audit flux web, d'une entrée (12) par sous-groupe ainsi formé.
3. 3. Procédé selon la revendication 2, dans lequel ledit regroupement des éléments est fonction d'un critère de priorité associée à 20 chacun desdits éléments.
4. 4. Procédé selon l'une des revendications 2 et 3, dans lequel ledit regroupement des éléments est fonction d'un critère temporel de création desdits éléments.
5. 5. Procédé selon l'une des revendications 2 à 4, dans lequel les 25 éléments de contenu à publier (14) comprennent des attributs, et on détermine, pour la création d'une entrée (12) d'un sous-groupe, un ensemble d'attributs à conserver dans ladite entrée en fonction du nombre d'éléments de contenu constituant ledit sous-groupe.
6. 6. Procédé selon l'une des revendications précédentes, dans 30 lequel ladite détermination (E110) d'un nombre d'éléments (NIA) de contenu comprend le calcul (E220) d'un nombre garantissant un maximum prédéterminé (MAX) d'éléments non sélectionnés (24) parmi lesdits nouveaux éléments (20).
7. 7. Procédé selon l'une des revendications précédentes, dans lequel ladite détermination (E110) d'un nombre d'éléments (NIA) comprend l'estimation (E240, E250) d'un nombre (NP, NS) de nouveaux éléments à publier (26) susceptibles d'arriver pendant ladite période de visibilité (T).
8. 8. Procédé selon la revendication précédente, comprenant une étape d'estimation (E240) d'un nombre prédit (NP) de nouveaux éléments (26) susceptibles d'arriver pendant ladite période de visibilité, à partir de données historiques dudit flux web représentatives de statistiques d'arrivées, pendant les périodes de visibilité passées, d'éléments de contenu à publier.
9. 9. Procédé selon l'une des revendications précédentes, dans lequel l'étape de sélection (E120) comprend une étape préalable d'ordonnancement (E320) desdits éléments (20) à publier, et ladite sélection est opérée selon l'ordre résultant des éléments à publier.
10. 10. Procédé selon la revendication précédente, dans lequel ledit ordonnancement est fonction d'une information de priorité associée à chacun desdits éléments de contenu à publier.
11. 11. Procédé selon la revendication 9 ou 10, dans lequel ledit ordonnancement est fonction d'un critère temporel relatif à la création desdits éléments de contenu à publier.
12. 12. Procédé selon l'une des revendications précédentes, dans lequel les entrées (12) créées se substituent à des entrées d'une version précédente dudit flux web (10), et le nombre (NE) d'entrées créées est strictement inférieur au nombre (NEF) d'entrées dudit flux web.
13. 13. Procédé selon l'une des revendications précédentes, dans lequel les entrées créées sont insérées dans ledit flux web (10) à différents instants répartis dans ladite période de visibilité (T).
14. 14. Procédé selon l'une des revendications précédentes, comprenant, postérieurement à ladite sélection (E120), la réception d'au moins un nouvel élément de contenu à publier (14) auquel est associé une information de première priorité, et la substitution, par ledit nouvel élément de contenu reçu, d'un desdits éléments sélectionnés, non encore ajouté audit flux web et auquel est associée une information de priorité inférieure à la première priorité.
15. 15. Procédé selon l'une des revendications précédentes, dans lequel, après écoulement de ladite période de visibilité (T), on réitère les étapes a), b) et c) sur les éléments de contenu non sélectionnés (24) et des éléments de contenu (26) nouvellement reçus pendant ladite période de visibilité (T).
16. 16. Procédé selon l'une des revendications précédentes, dans lequel on réalise un nombre prédéfini d'itérations des étapes a), b) et c), et la somme des nombres (MAX TS) d'éléments sélectionnés (22) lors desdites itérations est inférieur à un nombre maximal (MAX TP) prédéfini pour l'ensemble des itérations.
17. 17. Procédé selon l'une des revendications précédentes, dans lequel lesdites détermination (E110) et sélection (E120) d'éléments sont opérées sur un premier équipement, lesdits éléments de contenu sélectionnés (22) étant transmis depuis ledit premier équipement vers un serveur web, et ledit ajout (E135, E140) est opéré sur ledit serveur web à réception desdits éléments sélectionnés.
18. 18. Procédé de génération d'une pluralité de flux web (10) comprenant la génération de chacun desdits flux web selon l'une quelconque des revendications précédentes, lesdits flux web (10) ayant des périodes de visibilité (T, TP, TS) associées différentes.
19. 19. Procédé de publication d'éléments de contenu comprenant une première génération d'une première version du flux web selon l'une quelconque des revendications précédentes, puis la publication pendant une première période de visibilité, desdits éléments de contenu sélectionnés, au travers de la diffusion dudit flux web dans cette première version, et une deuxième génération d'une deuxième version du flux web selon l'une quelconque des revendications précédentes, à partir des éléments de contenu non sélectionnés lors de la première génération et d'éléments de contenu nouvellement reçus pendant ladite première période de visibilité, puis la publication pendant une deuxième période de visibilité consécutive à ladite première période de visibilité, desdits éléments de contenu alors sélectionnés, au travers de la diffusion dudit flux web dans cette deuxième version.
20. 20. Dispositif de génération d'un flux web composé d'entrées correspondant à des éléments de contenu, caractérisé en ce qu'il comprend: a. un module de détermination apte à déterminer un nombre (NIA) d'éléments de contenu à ajouter à un flux web (10), en fonction d'un nombre (NI) d'éléments de contenu à publier disponibles (20) et d'une période prédéfinie de visibilité (T) associée audit flux web, b. un moyen de sélection apte à sélectionner ledit nombre d'éléments de contenu (14) parmi lesdits éléments de contenu à publier (20), et c. un moyen de création apte créer, dans ledit flux web (10), des entrées (12) correspondant auxdits éléments sélectionnés (22).
21. 21. Moyen de stockage d'informations, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé conforme à l'une quelconque des revendications 1 à 19 lorsque le programme est chargé et exécuté par le système informatique.
22. 22. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 19, lorsqu'il est chargé et exécuté par le microprocesseur.