Brevet FR2910208A1 — publié le 20080620

BALADODIFFUSION SUR TELEPHONE MOBILE L'invention concerne le domaine de la téléphonie mobile et, plus particulièrement, l'accès à des contenus de type balado (podcast en anglais) par les téléphones mobiles. L'invention se rapporte à un procédé et à un système associé de téléchargement sur un terminal mobile d'un contenu numérique mis à jour épisodiquement (balado) et renseigné dans un premier flux de données (fil RSS - Really Simple Syndication) comprenant des indications de mise à jour dudit contenu numérique, ledit premier flux de données étant généré à une première adresse numérique par au moins un serveur informatique d'un réseau informatique, le procédé comprenant les étapes suivantes : - un dispositif informatique vérifie, via ledit réseau informatique, les indications de mise à jour générées à ladite première adresse numérique, ledit dispositif informatique télécharge ledit contenu numérique renseigné dans ledit premier flux de données en cas de mise à jour, ledit contenu numérique téléchargé étant stocké sur le dispositif informatique. Un balado (podcast) est un fichier numérique, généralement au contenu multimédia (son, vidéo, ...), qui par l'entremise d'un abonnement à un fil RSS ou équivalent, auquel il est rattaché, peut être téléchargé automatiquement à l'aide d'un logiciel agrégateur et destiné à être écouté ou visionné ultérieurement sur un équipement mobile, type baladeur numérique. Le fil RSS est une technologie, généralement mais non exclusivement, basée sur le format XML (Extensible Markup Language) par laquelle un site Web transmet, sur requête de l'agrégateur, la liste des modifications récentes du site, et notamment celles d'un fichier balado auquel le fil est rattaché. Techniquement, un fil RSS est un document XML rendu accessible par un site Web à une adresse URL (Uniform 2910208 2 Resource Locator) associée, ce document incluant l'ensemble des modifications effectuées et l'adresse URL à laquelle le balado est disponible au téléchargement. L'intérêt majeur de ces fils RSS est d'avoir connaissance des 5 changements d'un site Web, et donc d'un fichier à télécharger, sans avoir besoin d'accéder à celui-ci pour vérifier l'ensemble du contenu. La mise en pratique de cette technologie requiert au poste de l'utilisateur de disposer d'un agrégateur. Un agrégateur est une application logicielle qui permet de suivre plusieurs fils de syndication 10 en même temps, tels que RSS ou Atom et d'avertir, par conséquent, l'utilisateur d'un contenu mis à jour sur un site Web. En pratique, suite à l'abonnement (inscription) de l'utilisateur à des fils RSS (ceux des sites auxquels l'utilisateur s'intéresse), l'agrégateur vérifie périodiquement l'état de ces fils RSS et indique, le cas échéant, à 15 l'utilisateur une éventuelle mise à jour. L'agrégateur permet alors le téléchargement automatique d'un fichier mis à jour qui est rattaché au fil RSS mis à jour. La genèse et les développements de cette technologie restent 20 cantonnés au domaine informatique et aux sites Web. L'accès à de tels contenus n'est principalement possible que par le réseau Internet. Un objectif de l'invention est de permettre la récupération de fichiers balados sur le terminal mobile d'un usager par la voie des réseaux de 25 communication. Depuis que la téléphonie mobile offre des solutions d'accès direct au réseau Internet et aux sites Web associés, il est désormais recherché l'accès aux contenus balados depuis ces terminaux mobiles. 30 En raison d'une part de la taille limitée de la mémoire des téléphones portables et de la bande passante des réseaux cellulaires, et d'autre part, de la taille des fichiers podcastés (fichiers balados téléchargés), il est néanmoins, aujourd'hui, difficile de mettre en place le même 2910208 3 système d'abonnement sur téléphone portable que sur ordinateur personnel. C'est pourquoi des premières solutions propriétaires ont été 5 développées pour répondre à cette attente du marché de la téléphonie mobile. On connaît tout d'abord, par la demande de brevet US-2006/0155698, un système permettant à un utilisateur sur téléphone mobile d'être 10 averti, par SMS (Short Message Service) ou message vocal, d'une mise à jour de site Web disposant de fils RSS. Le système comprend notamment un agrégateur en ligne (c'est-à-dire sur le réseau Internet) qui scrute les fils RSS pour le compte de l'utilisateur. A détection d'une modification, cet agrégateur envoie un message SMS formaté ou un 15 message vocal pour avertir l'utilisateur. L'utilisateur retourne alors, par la voie informatique traditionnelle, sur le site Web pour constater les changements. L'utilisateur récupère éventuellement le fichier souhaité sur son ordinateur personnel et le charge sur son terminal mobile par des mécanismes traditionnels (connexion USB - Universal Serial Bus, 20 Bluetooth ou équivalente). Ce système concerne la notion de modification des sites Web et ne s'adresse nullement au domaine des balados (fichiers multimédias à télécharger) qui nécessitent le rapatriement du fichier multimédia sur le terminal mobile. 25 Un premier inconvénient de cette solution est qu'elle ne permet pas la récupération de fichiers multimédias associés à un fil RSS en tout lieu par le simple biais du téléphone mobile. Un autre inconvénient de cette solution est que l'abonnement de 30 l'utilisateur à un fil RSS requiert une connexion Internet afin d'accéder à l'agrégateur et paramétrer celui-ci. Un problème qui se pose au regard de cette demande de brevet est alors celui de proposer un système et/ou un procédé permettant à l'utilisateur d'accéder, lors de la notification d'une mise à jour, aux 2910208 4 fichiers balados sans que l'utilisateur ait à intervenir directement sur le réseau Internet et sur les équipements informatiques associés à ce réseau (par exemple un serveur Web). 5 On connaît cependant des solutions comme Mobilcast de Mélodéo ou Pod2mob (noms commerciaux) permettant, par l'intermédiaire d'une application dédiée et chargée sur le téléphone mobile, d'accéder à une pluralité de balados préchargés sur un serveur dédié du réseau de télécommunication mobile. Au lancement de l'application embarquée, 10 cette dernière effectue une mise à jour des balados accessibles, puis l'utilisateur, par simple clic, procède au téléchargement du balado choisi. Cette solution s'apparente à une simple méthode de téléchargement de contenus sur un téléphone mobile. 15 La solution Mobilcast permet également d'enrichir la liste des podcasts accessibles par mobile en indiquant, depuis une interface dédiée de site Web, un nouveau balado destiné aux mobiles à partir d'une liste prédéfinie par le fournisseur. Cette liste prédéfinie permet au fournisseur de configurer à l'avance les contenus balados pour mobile. 20 En outre, un temps de latence important est constaté entre la sélection d'un nouveau balado par l'interface Web et son accessibilité sur le serveur de téléphonie mobile. Un inconvénient de ces solutions réside dans le fait que l'utilisateur 25 doit déclencher volontairement une action (accès au portail mobile dédié) pour récupérer la liste des balados nouvellement disponibles sur le serveur et donc mis à jour. Un but de l'invention est aussi de rendre le suivi des modifications de contenus intrinsèquement indépendant d'une action de l'utilisateur. 30 On connaît également la solution Kimia (nom commercial) qui, à partir d'une liste de balados définie, vérifie d'éventuelles mises à jour et effectue, le cas échéant, un transcodage de ceux-ci au format mobile pour les rendre disponibles sur son serveur Web. L'utilisateur mobile 2910208 5 est alors averti de la mise à jour des balados par voie de courriel et doit se rendre sur le site Web dédié pour accéder aux fichiers mis à jour. Une telle solution est conforme au procédé évoqué précédemment. 5 Un inconvénient majeur des solutions connues de l'art antérieur est que les contenus de type balado disponibles à l'utilisateur sont limités à ceux qui ont été au préalable chargés ou indiqués sur le serveur central (soit Web soit de téléphonie mobile). Un but de l'invention est donc de permettre à l'utilisateur d'accéder à n'importe quel contenu du type 10 balado disponible, notamment ceux du réseau Internet. Les limitations techniques de ces solutions connues sont, dans ce dessein, un frein à l'accès en tout lieu de n'importe quel contenu de type balado. Un autre inconvénient de ces solutions connues réside dans le fait que le téléphone mobile de l'utilisateur ne suffit pas pour accéder à un 15 balado. Notamment, la solution Kimia requiert l'accès au balado mis à jour par la voie d'un site Internet et après notification par courriel alors que Mobilcast requiert d'accéder au site Internet du fournisseur pour ajouter un nouveau balado à la liste des balados pour mobiles disponibles sur le portail (serveur) de téléphonie mobile. 20 Un autre inconvénient de la solution Kimia réside dans le caractère intrusif des notifications de mise à jour (par courriel dans ce cas). Ces problèmes de l'art antérieur sont résolus par l'utilisation d'un dispositif-passerelle entre les réseaux informatiques (celui auquel 25 appartiennent les balados et fils RSS) et de télécommunication mobile, ce dispositif officiant comme agrégateur de contenus entre ces deux réseaux. Depuis son terminal mobile, l'utilisateur paramètre alors ce dispositif avec l'adresse d'un fil RSS de son choix. Le dispositif retourne alors au mobile l'adresse de téléchargement du contenu mis à 30 sa disposition au travers du réseau mobile sur cette passerelle. Ainsi, il est aisé de configurer ce dispositif pour un nouveau balado de son choix. L'automatisation du processus de récupération et formatage du balado par ce dispositif permet, lorsque couplé à l'invention, de rendre accessible rapidement des balados à l'utilisateur mobile là où 2910208 6 l'art antérieur nécessite un délai important (requête à faire sur le serveur Web, temps de latence dans le traitement de la demande, délai pour la mise à disposition sur le serveur de téléphonie mobile). En outre, il est désormais possible de paramétrer un nouveau balado 5 sans l'intermédiaire du réseau Internet et de sites Web. Ainsi, l'invention permet un accès illimité à tout balado de son choix, dans un délai rapide, en tout endroit et par l'intermédiaire unique du terminal mobile. 10 Dans ce dessein, l'invention a, tout d'abord, pour objet un procédé de téléchargement sur un terminal mobile tel que mentionné précédemment, comprenant en outre : - une étape initiale d'enregistrement de ladite première adresse 15 numérique (URL1) par le dispositif informatique, ledit enregistrement étant réalisé suite à l'envoi d'une première requête comprenant ladite première adresse numérique (URL1) par le terminal mobile à destination du dispositif informatique, - une étape d'envoi, par le dispositif informatique au terminal mobile, 20 d'une deuxième adresse numérique (URL2) du dispositif informatique de sorte à permettre le téléchargement dudit contenu numérique téléchargé par le terminal mobile au travers d'un réseau de télécommunication mobile, et - une étape selon laquelle le terminal mobile se connecte à ladite 25 deuxième adresse numérique (URL2) via le réseau de télécommunication mobile et télécharge ledit contenu numérique mis à jour depuis le dispositif informatique, Lors de l'étape initiale, l'utilisateur indique à la plateforme centrale (dispositif informatique) une nouvelle adresse de fil RSS sans limitation 30 à celles préenregistrées sur le serveur. Il est entendu que l'enregistrement de l'adresse signifie que celle-ci n'était pas encore connue de la plateforme, c'est-à-dire nullement enregistrée dans une quelconque liste d'adresses pré-paramétrées. L'utilisation d'adresses 2910208 7 au format URL permet notamment d'indiquer de nouveaux fils RSS de façon totalement indépendante de l'adresse de la plateforme. Ladite première requête déclenche l'ensemble des étapes depuis l'enregistrement de l'adresse jusqu'à la récupération ultérieure de mise 5 à jour du balado et du fil RSS en passant par la récupération initiale de ceux-ci, c'est-à-dire suite à l'inscription d'un nouveau fil RSS (nouvelle adresse) de l'utilisateur sur la plateforme. En retour à la configuration de la plateforme, cette dernière envoie au mobile les indications (deuxième adresse) permettant de récupérer le 10 balado sur la plateforme. Il s'agit notamment d'une adresse URL soit du balado directement soit d'un fil équivalent RSS généré par la plateforme et indiquant l'adresse où télécharger le balado depuis la plateforme. Cette deuxième alternative est préférable en ce qu'elle reste conforme aux mécanismes de la baladodiffusion, c'est-à-dire que, 15 via le fil RSS généré à la nouvelle (deuxième) adresse, le téléphone mobile est averti d'une éventuelle mise à jour sans accéder au contenu. Le téléphone mobile de l'utilisateur est quant à lui muni d'une application embarquée de type agrégateur pour la gestion des fils RSS 20 auxquels il est inscrit par le biais de la plateforme. Dans son rôle de relais de balados, il est prévu que ledit dispositif informatique génère, à ladite deuxième adresse numérique (URL2), un deuxième flux de données comprenant des indications de mise à jour dudit contenu numérique en fonction dudit premier flux de données. Puis, le terminal 25 mobile vérifie, via le réseau de télécommunication mobile, les indications de mise à jour générées à ladite deuxième adresse numérique (URL2), le téléchargement par le terminal mobile dudit contenu numérique téléchargé étant fonction de la détection d'une mise à jour sur la deuxième adresse numérique. 30 On remarque ainsi que le fil RSS initial est propagé sur le réseau de télécommunication mobile. De la sorte, les mécanismes du fil RSS sont déportés sur ce réseau permettant au terminal mobile, via l'agrégateur embarqué, d'être informé des mises à jour de contenus. Les principes habituels relatifs aux fils RSS peuvent alors être appliqués, à savoir 2910208 8 notamment le téléchargement automatique du contenu en cas de mise à jour. Dans un mode de réalisation, il est prévu que les flux de données 5 renseignent chacun l'adresse numérique (URL1', URL2') de stockage du contenu numérique correspondant. La simple connaissance du fil RSS permet ainsi soit à la plateforme soit à l'agrégateur du téléphone mobile d'avoir accès au contenu (via ces adresses URL1' et URL2') par simple lecture des informations du fil RSS. En outre, cette configuration 10 permet de simplifier la gestion de la plateforme puisqu'une seule adresse initiale lui est fournie et en réponse une seule adresse est fournie au téléphone mobile. Dans la pratique, le fil RSS est au format XML et comprend une balise prédéfinie renseignant l'adresse URL à laquelle le contenu balado est téléchargeable. 15 Dans le mode de réalisation automatisé, l'agrégateur embarqué lit directement l'adresse URL2' dans le fil RSS récupéré à l'adresse URL2, procède au téléchargement du balado à l'adresse URL2' en cas de mise à jour et le stocke sur le téléphone mobile de l'utilisateur. 20 Le réseau de téléphonie mobile présente de nombreuses contraintes relatives aux ressources soit des terminaux (mémoire disponible, capacité de traitement) soit du réseau en lui-même (débit, bande passante, ...). Pour s'adapter aux limitations du réseau, il est prévu que, lorsque lesdits flux de données sont des fichiers de balisage (type 25 XML), le procédé comprend une étape de conversion dudit premier flux de données en ledit deuxième flux de données, ladite conversion comprenant la suppression et la substitution de balises ainsi que la modification de ladite première adresse numérique en ladite deuxième adresse numérique. 30 La suppression vise principalement à alléger la taille du fichier XML qui est récupéré par le terminal mobile, en ne conservant qu'un historique limité des modifications enregistrées dans le fichier (par exemple les dix derniers enregistrements) et en épurant les balises inutiles, par exemple des balises utilisées uniquement par iTunes (nom commercial). 2910208 9 La substitution de balises a pour vocation de satisfaire, le cas échéant, le langage d'interprétation embarqué dans le mobile. A titre d'exemple, une balise nommée sur un site anglophone pourra être substituée par une balise interprétée par l'agrégateur du 5 terminal mobile. Enfin, l'adresse du balado dans le fichier XML du fil RSS est mise à jour pour indiquer désormais celle à laquelle est accessible le balado sur la plateforme. 10 Eventuellement, on prévoit aussi une étape de conversion dudit contenu numérique balado en un format multimédia compatible à celui dudit terminal mobile, ladite conversion étant réalisée par ledit dispositif informatique après téléchargement dudit contenu. A titre d'exemple, le balado initial peut être converti aux dimensions 176x144 15 points et au format Mpeg 4 (Moving Picture Experts Group 4) ou 3GP. Cependant un grand nombre de formats peut être utilisé. On envisage également de transmettre auparavant, par exemple dans la première requête émise depuis le terminal mobile, des données d'indication sur le(s) format(s) compatible(s) avec le terminal en question. 20 Particulièrement, la conversion dudit contenu numérique téléchargé précède la conversion dudit premier flux de données. Cet ordre présente l'avantage de disposer d'un balado déjà converti lorsque le fil RSS l'est à son tour. Ainsi, l'accès au fil RSS mis à jour et le 25 téléchargement du balado associé ne sont pas réalisés sur un fichier à moitié converti ou non encore converti. Dans un mode de réalisation avancé, ledit dispositif informatique comprend une première base de données de contenus numériques qu'il 30 stocke, et vérifie si ladite première adresse (URL1) de la première requête correspond à un contenu référencé dans ladite première base, et, si la vérification est positive, ledit dispositif transmet ladite deuxième adresse (URL2) en réponse à la première requête ; si la vérification est négative, ledit dispositif enregistre ladite première 2910208 10 adresse (URL1) dans une deuxième base de données et acquitte ladite première requête auprès du terminal mobile. Ce mécanisme permet à la fois une gestion transparente et rapide de la requête du terminal mobile. Le terminal est de suite averti que soit le balado est disponible 5 û première adresse déjà en base et transmission de la deuxième adresse û soit qu'il doit entrer dans un cycle d'attente le temps que la plateforme récupère et mette à disposition le balado (ledit dispositif acquitte uniquement la première requête). Dans ce dernier cas, il est prévu que : 10 - le dispositif informatique télécharge ledit contenu numérique renseigné dans le premier flux de données généré à la première adresse (URL1) ; - le dispositif informatique convertit ledit contenu numérique téléchargé et le premier flux de données en des formats compatibles 15 avec le terminal mobile ; - une fois les conversions effectuées, le dispositif informatique envoie ladite deuxième adresse numérique (URL2) audit terminal mobile. Par ces étapes, la plateforme récupère le balado, le convertit au format requis en même temps que le fil RSS et rend ceux- ci accessibles au 20 terminal mobile en lui transmettant la deuxième adresse. Pour économiser l'énergie du téléphone, il est prévu qu'après l'acquittement, le téléphone coupe sa connexion avec la plateforme. Ainsi, pour avertir celui-ci, l'envoi de la deuxième adresse numérique 25 est effectué en réponse à une requête ultérieure du terminal mobile. En pratique, on prévoit, de façon similaire à ce que fait un agrégateur traditionnel pour vérifier les mises à jour, que le téléphone mobile (via son application agrégateur embarquée) requête périodiquement la plateforme jusqu'à l'obtention de la nouvelle adresse. 30 Selon une variante toutefois intrusive, l'envoi de la deuxième adresse numérique est effectué sous la forme d'un envoi poussé (push en anglais) audit terminal mobile. Par exemple, par un message texte sur le téléphone ou une notification réseau forcée affichant un message sur 2910208 11 le téléphone (par exemple une commande prenant la main sur l'application embarquée pour remonter la notification). Dans ce cas, on considère que cette notification est émise en réponse à la requête initiale de l'utilisateur même si un délai de traitement s'est écoulé 5 depuis. Dans un mode de réalisation, ladite deuxième adresse numérique est l'adresse de stockage sur le dispositif informatique dudit contenu numérique téléchargé. 10 L'invention a également pour objet une plateforme pour le téléchargement sur un terminal mobile d'un contenu numérique mis à jour épisodiquement et renseigné dans un premier flux de données comprenant des indications de mise à jour dudit contenu numérique, 15 ledit premier flux de données étant généré à une première adresse numérique (URL1) d'un réseau informatique, la plateforme comprenant : - des moyens pour enregistrer, à réception d'une première requête d'un terminal mobile, ladite première adresse numérique (URL1) ; généralement ces moyens sont composés d'une interface de 20 communication avec le terminal mobile, type interface sur le réseau de téléphonie mobile, d'une application logicielle pour le traitement de la requête et une base de données pour stocker cette adresse numérique dans un format adapté. - des moyens de vérification, via le réseau informatique, des 25 indications de mise à jour générées à ladite première adresse numérique. - des moyens pour télécharger et stocker ledit contenu numérique renseigné dans ledit premier flux de données en cas de mise à jour, - des moyens pour transmettre au terminal mobile, suite à la première 30 requête, une deuxième adresse numérique (URL2) du dispositif informatique utilisée pour réaliser le téléchargement dudit contenu numérique par le terminal mobile au travers d'un réseau de télécommunication mobile. 2910208 12 Des moyens logiciels de vérification peuvent être utilisés pour détecter une éventuelle mise à jour. Cette dernière est détectée si les données dont dispose la plateforme diffèrent de celles présentes à l'adresse indiquée, par exemple (i) à l'initialisation du système, du fait que la 5 plateforme n'a pas encore accédé au site, le fil RSS lu à l'adresse URL1 diffère de ce qui est enregistré sur la plateforme de telle sorte que cette dernière considère qu'une mise à jour a eu lieu et donc procède aux étapes suivantes de téléchargement, ou (ii) ultérieurement lorsque le site Web et son contenu sont mis à jour de telle sorte que les 10 données du fil RSS de ce site diffèrent de celles stockées sur la plateforme. Dans un mode de réalisation, il est prévu que les moyens pour enregistrer comprennent des première et deuxième bases de données, 15 la première base stockant ladite première adresse numérique à réception de la première requête lorsque cette première adresse n'est pas enregistrée dans la deuxième base de données ; les moyens pour télécharger et stocker sont agencés pour déplacer ladite première adresse enregistrée dans la première base de données 20 vers la deuxième base de données lorsque ledit contenu numérique a été téléchargé et mis à la disposition dudit terminal mobile sur le réseau de télécommunication mobile. Ce déplacement s'effectue simplement par effacement de la première adresse dans la première base et son enregistrement dans la deuxième base. Ceci facilite la 25 détection d'une adresse déjà présente dans la plateforme, c'est-à-dire une adresse dont le contenu est déjà accessible au format adapté aux mobiles. Des traitements inutiles de téléchargement et conversion de contenus déjà enregistrés sont ainsi évités. 30 Eventuellement, les moyens pour télécharger et stocker comprennent un moyen logiciel de conversion dudit contenu numérique et dudit premier flux de données en un contenu numérique adapté et un second flux de données adapté au format dudit terminal mobile. 2910208 13 Le terme plateforme (équivalant au terme dispositif informatique) doit être compris dans un sens large, notamment par le fait qu'elle peut être composée de plusieurs équipements assignés aux différentes fonctions qui sont développées par la suite, notamment un équipement peut 5 traiter le fil RSS et la deuxième adresse numérique URL2 alors qu'un second équipement peut être utilisé comme moyen de stockage et de mise à disposition sur le réseau mobile des balados convertis (à l'adresse URL2'). 10 L'invention a également pour objet un système pour le téléchargement sur un terminal mobile d'un contenu numérique mis à jour épisodiquement et renseigné dans un premier flux de données comprenant des indications de mise à jour dudit contenu numérique, le système comprenant : 15 - au moins un serveur informatique générant ledit premier flux de données à une première adresse numérique (URL1), - une plateforme précédemment présentée, et - au moins un terminal mobile comprenant des moyens pour établir, sur le réseau de télécommunication mobile, une connexion avec 20 ladite deuxième adresse numérique (URL2) et télécharger ledit contenu numérique depuis ledit dispositif informatique. Dans la pratique, le balado et le fil RSS sont disponibles sur le même serveur Web. Selon une variante, le fil RSS généré à la première adresse URL1 sur un serveur Web renseigne l'adresse de stockage 25 URL1' du balado dur un autre serveur Web du réseau Internet. On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées : 30 ù la Fig. 1 représente un exemple d'architecture système dans laquelle l'invention est mise en oeuvre ; 2910208 14 les Fig. 2, 3 et 5 sont des ordinogrammes représentant différentes étapes du processus selon l'invention (général pour Fig. 2, dédié terminal mobile pour Fig. 3 et dédié plateforme centrale pour Fig. 5 ; et 5 û la Fig. 4 est un chronogramme des échanges de données entre les équipements de l'architecture selon la Fig. 1. Dans l'exemple de réalisation ici détaillé, le terme "podcast" est utilisé pour désigner un balado comme défini précédemment. 10 En référence à la Fig. 1, des podcasts (fichiers multimédias) et leurs fils RSS sont mis à disposition d'usagers sur le réseau Internet 1 selon les mécanismes connus de fils RSS dans le domaine de l'Internet. Les serveurs Web 2 stockent les fichiers multimédias et diffusent les fils 15 RSS associés à ces médias. Ci-dessous est illustré un exemple simplifié de fil RSS : - ... - ... 20 - ... ... ... 25 ... - ... ... ... 30 2910208 - Ce fil délimité par les balises se compose notamment d'une section générale (ici et ) et de plusieurs éléments 5 délimités par les balises et . Chacun de ces éléments définit une donnée datée et comprend un grand nombre de champs (tous non représentés), notamment des champs utilisés par le lecteur iTunes (nom commercial). Dans le cadre des podcasts, les items successifs représentent lesindications de versions mises à jour, par 10 exemple le premier élément renseigne les informations relatives à la version actuelle (notamment sa date), le deuxième élément les informations relatives à la version précédente, etc... Une plateforme centrale 3 appartient également au réseau Internet 1. 15 Cette plateforme comprend trois éléments : - une Base de Données 31 pour stocker des informations sur les podcasts abonnés ; - un Serveur Web et FTP 32 pour héberger les podcast transcodés - un automate 33 contenant un serveur Web pour transcoder le fichier 20 RSS et les médias ; La plateforme est également munie d'une interface (non représentée) avec un réseau de télécommunication mobile 4 tel que ceux utilisés traditionnellement par les téléphones mobiles (GSM, GPRS, EDGE, UMTS, ...). 25 Un utilisateur final est équipé d'un téléphone portable 5 capable de se connecter et communiquer à travers le réseau 4. Le téléphone 5 est muni d'un logiciel 51 permettant l'interfaçage avec la plateforme 3 sur le réseau 4. Ce logiciel (application embarquée) permet notamment à 30 l'utilisateur d'accéder à un portail de podcasts mis à disposition sur la plateforme 3 de façon sensiblement similaire aux solutions de l'art antérieur. 15 2910208 16 Notamment, la base de données 31 comprend une table Podcast_Portail 31a référençant une liste de podcasts prédéfinis d'éditeurs partenaires et hébergés par le serveur 32. Cette table contient les attributs : (URL_1, URL_2, ). URL_1 définit 5 l'adresse du podcast sur le réseau Internet 1 et URL_2 l'adresse sur la plateforme 3 à partir de laquelle les téléphones mobiles 5 peuvent accéder aux podcasts. permet d'identifier simplement à l'utilisateur le podcast concerné, par exemple par une chaîne de caractères. Voici un exemple de table Podcast_Portail comprenant deux 10 entrées : Entrée 1 - URL_1 : http://www.lequipe.fr/podcast_rss.xml, URL_2 : http://plateforme/Data/lequipe/Format_mobile/rss.xml - : L'équipe ; 15 Entrée 2 : - URL_1 : http://www.BFM.com/BFMchannel9.xml, - URL_2 : http://plateforme/Data/BFM/Format_mobile/rss.xml - : BFM En se connectant avec son téléphone 5 sur le portail précité, 20 l'utilisateur accède à la liste prédéfinie issue de la table 31a et par des mécanismes traditionnels télécharge le contenu multimédia associé. Egalement, selon des mécanismes déjà connus, l'utilisateur s'inscrit au fil RSS associé à ce contenu souhaité, ce qui paramètre l'application embarquée 51 dans le téléphone pour périodiquement se connecter au 25 fil RSS de la plateforme et télécharger si nécessaire automatiquement le contenu mis à jour. L'application 51 officie alors comme agrégateur de contenu au sens où il est compris dans le domaine des fils RSS sur l'Internet. 30 Pour la mise en oeuvre de l'invention, la base de données 31 comprend également une table Podcast_Abonné 31b référençant l'ensemble des podcasts demandés par les usagers par le biais de la présente invention et une table Podcast_Traitement 31c référençant les podcasts demandés par les usagers mais non encore disponibles au 2910208 17 téléchargement du fait que la demande est en cours de traitement comme nous le verrons par la suite. La table Podcast_Traitement 31c contient l'attribut : (URL_1). Il s'agit 5 de l'adresse demandée par l'utilisateur. Voici un exemple : Entrée 1 : URL_1 : http://tfl.lci.fr/xml/rss/O,,150,00.xml La table Podcast_Abonné 31b contient les attributs : (URL_1, URL_2, 10 ). Elle a un format similaire à la table Podcast_Portail, mais son contenu diffère en ce qu'elle référence l'ensemble des podcasts volontairement demandés par les utilisateurs. Suite au traitement (que nous verrons pas la suite) du podcast enregistré dans la table Podcast_Traitement ci-dessus, la table 15 Podcast_Abonne comprend l'enregistrement suivant : - URL_1 : http://tfl.lci.fr/xml/rss/O,,23,00.xml - URL_2 : http://dispositif_inormatique.com/Data/... ...LCI La meteo/Format mobile/RSS.xml - : LCI Météo 20 L'automate transcodeur 33 contient, quant à lui, une base de données contenant une table Podcast_Transcodé référençant les podcasts qui sont déclarés disponibles sur la plateforme podcast 3. Cette table contient l'attribut ( , URL_1), par exemple : 25 - : LCI Météo - URL 1 : http://tfl.lci.fr/xmI/rss/0ä23,00.xml En pratique, l'automate 33 reçoit les médias et le flux RSS du serveur Web 32, transcode les médias vers des formats lisibles pour le mobile (par exemple .3gp) (plusieurs formats d'encodage peuvent être 30 envisagés) et réduit la taille du fichier RSS, notamment en éliminant les tags iTunes et en ne conservant que les 20 derniers médias. Le téléphone mobile 5 embarque une application rich-média 51 de lecture de podcasts basée sur la technologie Bluestreak (nom 2910208 18 commercial). Une application rich-média est un système ou une application logicielle qui permet, sur un terminal et notamment un terminal mobile, d'accéder à la fois à des contenus de type image, de type son, de type texte et de type vidéo, l'ensemble des contenus étant 5 joués (exécutés pour en réaliser un rendu soit sonore soit visuel à l'utilisateur) en parallèle et non de manière linéaire. Grâce à cette application, il est possible de lire un fichier RSS de taille raisonnable, c'est-à-dire inférieur à 400 ko (kilo-octets) en raison de la mémoire limitée du téléphone. 10 Trois fichiers XML sont stockés sur le téléphone pour classer les podcasts enregistrés sur le téléphone: - Abonnement.xml 52 qui référence les podcasts abonnés (c'est-à-dire les adresses de fils RSS) et liste des médias (fichiers multimédias) enregistrés sur la carte mémoire du téléphone, 15 -Podcast_Demandés.xml 53 qui référence les podcasts des nouveaux podcasts demandés, - Hors_Abonnement.xml 54 qui liste des podcasts et fils RSS sur lesquels l'utilisateur ne s'est pas abonné, mais a déjà procédé au téléchargement de ceux-ci. 20 L'application 51 offre la possibilité à l'utilisateur de s'abonner à tout type de podcasts en entrant l'adresse URL du podcast désiré. Demande d'abonnement à un podcast non lisible sur le mobile 25 Le téléphone 5 possède des moyens pour se connecter sur le réseau Internet 2 à travers le réseau de téléphonie mobile 4. De tels moyens sont bien connus de l'art antérieur. Ainsi l'utilisateur qui navigue sur Internet soit depuis un ordinateur soit depuis son téléphone mobile se trouve intéressé par un podcast Bouygues (nom commercial) 30 comprenant un flash d'information audio et un fil RSS à l'adresse http://www.bouygues.com/rss.xml . En référence aux Fig. 1, 2 et 4, l'utilisateur déclenche une fonction de l'application embarquée sur le mobile 5 dont l'exécution envoie (I, 200) 2910208 19 une requête http ajout_podcast(http://www.bouygues.com/rss.xml) à la plateforme 3 au travers du réseau de téléphonie mobile 4. Une alternative est que depuis le portail précité, l'utilisateur entre dans 5 une rubrique autre podcast et renseigne manuellement l'adresse (url) http://www.bouygues.com/rss.xml du podcast qu'il souhaite recevoir sur son mobile. Le mobile stocke (II) l'url du podcast dans le fichier local 10 Podcast_demande.xml 52 sur la mémoire du téléphone. Ce fichier a la forme d'un document XML listant par des balises , et , les adresses, noms de podcast demandés et la date de la requête. L'objectif de ce fichier 52 est de conserver une trace des podcasts demandés pour que le mobile s'informe, par la 15 suite, de la disponibilité du podcast demandé. De son côté, le serveur Web 32 de la plateforme 3, traite (100) la requête ajout_podcast(http://www.bouygues.com/rss.xml) et interroge la base de données 31 pour déterminer si le podcast a déjà été demandé 20 par un autre mobile ou si la conversion du podcast est déjà réalisée par la plateforme (III, 102). Si le podcast demandé par l'utilisateur n'est pas présent dans la table Podcast_Portail 31a ou Podcast_Abonné 31b (sortie NON de 102), le 25 serveur Web 32 renvoie au mobile que sa demande est bien prise en compte (106, 202) et enregistre l'adresse URL_1= http://www.bouygues.com/rss.xml dans la table Podcast_Traitement 31c (104). 30 Si le podcast demandé par l'utilisateur est dans la table Podcast_Portail 31a ou Podcast_Abonné 31b (sortie OUI de 102), alors le serveur 32, qui peut avoir déjà acquitté la requête (202), informe le mobile 5 que le podcast est disponible en envoyant, en réponse à la requête Ajout_Podcast, les paramètres du podcast demandé (URL_1, 2910208 20 URL_2, ) récupérés de la table concernée (IV, 108, 204). En référence à la Fig. 3, le mobile recevant (150) les paramètres du 5 podcast (URL1, URL2, ), ajoute URL_2 et dans le fichier Abonnés.xml 53 et supprime URL_1 dans le fichier Podcast_Demandé.xml 52 (152). La présence de URL_2 dans le fichier Abonnés.xml induit à mise à jour régulière du podcast conformément aux mécanismes traditionnels relatifs au suivi des mises 10 à jour au travers de fils RSS (l'application embarquée 51 officie alors comme agrégateur de contenus). Conversion du podcast au format mobile. 15 La présence de l'url http://www.bouygues.com/rss.xml dans la table Podcast_Traitement 31c entraîne le processus de conversion du podcast au format mobile. De nouveau en référence aux Fig. 1 et 4, le serveur Web 32 de la plateforme lance le téléchargement (206 ù téléchargement du fil RSS, 208 ù téléchargement du fichier podcast), 20 via le réseau Internet 1 : -du flux RSS du podcast, et - des médias du podcast Les répertoires Nom_Podcast (ici "Bouygues") et Format_Internet sont créés dans un répertoire local Data (sur le serveur Web 32) : Data\Bouygues. 25 Les médias et le flux RSS téléchargés sont stockés dans ce répertoire (V, Fig. 1) Data\Bouygues\Format_Internet. Le serveur Web 32 génère un fichier "nom_podcast.bat" pour l'opération de transcodage. Ce fichier contient le nom et l'adresse dans 30 le répertoire local des médias à convertir et le format de conversion audio/vidéo. Ci-dessous est un exemple simplifié d'un tel fichier : 2910208 21 5 10 15 20 Les balises définissent le fichier initial à convertir et les balises précisent l'emplacement de stockage du fichier une fois converti. Des paramètres ( ) sont définis à la fois pour paramétrer l'encodage vidéo et l'encodage audio. 25 Enfin, le serveur 32 envoie (VI, 210) la requête Transcode avec comme paramètre l'adresse du fichier .bat et l'adresse du RSS pour convertir les médias à l'automate de transcodage 33 : Transcode(http://plateforme/Data/Bouygues/Format lnternet/nom_podc ast.bat, http://plateforme/Data/Bouygues/Format lnternet/RSS.xml) 30 A la réception de la requête Transcode comprenant les paramètres indiqués ci-dessus, l'automate 33 : (a). crée le répertoire Bouygues dans l'arborescence locale de ses fichiers : d:/Data/A_transcoder si le répertoire n'existe pas, 2910208 22 (b). télécharge les médias et le fichier RSS (téléchargés sur le serveur 32) par ftp (File Transport Protocol) dans le répertoire d:/Data/A_transcoder/Bouygues, transcode (VII, Fig. 1) les médias et le fichier RSS. L'automate 33 5 convertit les médias du podcast en Mpeg4 dans un conteneur .3gp et le fichier RSS est allégé par suppression des tags iTunes et référencement des dix derniers médias du podcast. Notamment, l'automate transcodeur 33 effectue la conversion du fichier RSS par un composant C/C++. Son rôle est de télécharger le fichier 10 RSS et de parcourir le fichier pour y appliquer des règles de substitution ou suppression de tags dans le but d'alléger la taille du fichier RSS.xml. Le fichier RSS est également modifié pour que les adresses url des fichiers multimédias pointent vers les fichiers multimédias qui sont stockés sur le serveur Web 32 (VII, Fig. 1) : le 15 fichier RSS qui indiquait initialement http://www.bouygues.com/medias/flash.wav est modifié pour désormais pointer sur http://plateforme/Data/Bouygues/Format Mobile/flash.mpg En reprenant l'exemple de fil RSS présenté ci-dessus, l'on obtient de 20 façon schématique le fichier suivant (suppression des balises iTunes) dans lequel seul un nombre prédéfini d'éléments ( ) a été conservé (les vingt dernières versions du média par exemple). - ... 25 - ... - ... ... ... 30 ... - 2910208 23 (c). upload (VIII, Fig. 1 ; 212) les médias et le fichier RSS convertis sur la plateforme podcast du serveur Web 32, (d). supprime les fichiers dans d:/Data/A_transcoder/Bouygues, (e). consulte la table Podcast_Transcodé :, 5 o Si Nom_Podcast (ici Bouygues ) n'est pas déjà dans la table Podcast_Transcodé, le podcast est nouveau et n'est pas encore déclaré comme disponible sur la plateforme 3 : ^ l'automate 33 envoie (214) la requête Upgrade(Nom_Podcast) au serveur 32 pour l'avertir 10 d'ajouter Nom_Podcast et l'URL_2 générée dans la table Podcast_Abonné 31b de sa base de données et supprimer Nom_Podcast de la table Podcast_Traitement 31c, ^ et écrit le champ Bouygues dans la table 15 Podcast_Transcodé. o Si Nom_Podcast est déjà dans la table Podcast_Transcodé (c'est-à-dire il ne s'agit que d'une simple mise à jour du podcast), le podcast est déclaré comme disponible sur la plateforme podcast ; aucune requête n'est alors envoyée, 20 puisque le "upload" vient écraser les anciens fichiers. Notification de disponibilité au mobile A la lecture du fichier Podcast_demandés.xml 53, le mobile 5 envoie 25 (IX, 154, 216, 220), à intervalles de temps, la requête : Disponible(URL://RSS_Bouygues.XML) au serveur Web 32 pour savoir si le podcast demandé (ou les podcasts demandés) est disponible. Dans le cas où le podcast demandé a été traité, le serveur Web 32 30 renvoie (108, 222) les paramètres du podcast demandé (URL_1,URL_2, ) où URL_2 est l'adresse sur la plateforme du podcast converti dans le format adapté pour le mobile. Dans l'autre cas, le serveur répond au mobile que la demande est bien prise en compte (218). 2910208 24 Eventuellement, la notification de la disponibilité du podcast peut aussi être transmise par push d'un message au mobile. 5 Abonnement du mobile au podcast Le mobile reçoit l'adresse du fichier RSS transcodé au format mobile (suite au message 108 ou 222), il l'ajoute (X, Fig. 1 ; 152) à sa table local Podcast_Abonné.xml pour que ce dernier entre dans le processus 10 de mise à jour des podcasts. Mise à jour des podcasts 15 Les podcasts sont des fils d'informations régulièrement mis à jour. Pour que les nouveaux médias soient notifiés et lisibles sur le mobile, la plateforme doit mettre à jour le flux RSS et les médias au format du mobile. En référence à la Fig. 5, partant des adresses URL présentes dans les 20 tables Podcast_portail 31a et Podcast_Abonné 31b, le serveur Web 32 vérifie (300) les flux RSS attachés à ces adresses. Cette vérification est cyclique avec des périodes qui peuvent varier d'un podcast à l'autre parce que, par exemple, l'utilisateur a configuré une période de vérification. 25 Le serveur Web identifie les nouveaux médias par comparaison (302) du flux RSS et des médias contenus sur le répertoire Format_Internet du dossier associé au podcast. En cas d'absence de différence dans la comparaison (sortie NON de 302), le serveur Web 32 reprend son cycle de vérification. 30 En cas de différence dans cette comparaison (sortie OUI de 302), les nouveaux médias sont téléchargés (304) et mis au bon format par envoi de la requête Transcode.php(Nom_Podcast.bat,RSS.XML) à l'automate transcodeur (306). 2910208 25 Le processus de mise à jour se fait de façon à ce que les médias soient convertis (306) et uploadés (téléchargés vers le serveur) (308) sur le serveur Web 32 avant l'upload du nouveau fichier RSS au format mobile. 5 Le serveur Web 32 rentre alors de nouveau dans le cycle décrit ci- dessus de vérification des fils RSS (300). En parallèle, le téléphone 5 vérifie (156) les fils RSS convertis et générés par la plateforme 3 qui sont présents dans le fichier 10 Abonnés.xml 53 (également Hors_Abonnement.xml 54). Les mécanismes traditionnels de comparaison de fil RSS (158) et de téléchargement du podcast (160) en cas de mise à jour sont appliqués. REVENDICATIONS 1. Procédé de téléchargement sur un terminal mobile (5) d'un contenu numérique mis à jour épisodiquement et renseigné dans un premier flux de données comprenant des indications de mise à jour dudit contenu numérique, ledit premier flux de données étant généré à une première adresse numérique (URL1) par au moins un serveur informatique (2) d'un réseau informatique (1), le procédé comprenant les étapes suivantes : - un dispositif informatique (3) vérifie (302), via ledit réseau informatique, les indications de mise à jour générées à ladite première adresse numérique (URL1), - ledit dispositif informatique télécharge (304) ledit contenu numérique renseigné dans ledit premier flux de données en cas de mise à jour, ledit contenu numérique téléchargé étant stocké sur le dispositif informatique (3), caractérisé en ce que le procédé comprend, en outre, une étape initiale d'enregistrement de ladite première adresse numérique (URL1) par le dispositif informatique, ledit enregistrement étant réalisé suite à l'envoi d'une première requête comprenant ladite première adresse numérique (URL1) par le terminal mobile à destination du dispositif informatique, une étape d'envoi (IV, 108, 204, 222), par le dispositif informatique au terminal mobile, d'une deuxième adresse numérique (URL2) du dispositif informatique de sorte à permettre le téléchargement dudit contenu numérique téléchargé par le terminal mobile au travers d'un réseau de télécommunication mobile (4), et une étape selon laquelle le terminal mobile se connecte à ladite deuxième adresse numérique (URL2) via le réseau de télécommunication mobile et télécharge ledit contenu numérique mis à jour depuis le dispositif informatique, 2. Procédé selon la revendication 1, comprenant en outre les étapes suivantes : 2910208 27 - ledit dispositif informatique (3) génère, à ladite deuxième adresse numérique (URL2), un deuxième flux de données comprenant des indications de mise à jour dudit contenu numérique en fonction dudit premier flux de données, 5 - le terminal mobile (5) vérifie, via le réseau de télécommunication mobile (4), les indications de mise à jour générées à ladite deuxième adresse numérique (URL2), - le téléchargement par le terminal mobile (5) dudit contenu numérique téléchargé étant fonction de la détection d'une mise à 10 jour sur la deuxième adresse numérique. 3. Procédé selon la revendication précédente, dans lequel les flux de données renseignent chacun l'adresse numérique (URL1', URL2') de stockage du contenu numérique correspondant. 15 4. Procédé selon la revendication 3, dans lequel lesdits flux de données sont des fichiers de balisage, le procédé comprenant une étape de conversion (VII) dudit premier flux de données en ledit deuxième flux de données, ladite conversion comprenant la suppression 20 et la substitution de balises ainsi que la modification de ladite première adresse numérique (URL1) en ladite deuxième adresse numérique. 5. Procédé selon l'une des revendications précédentes, comprenant en outre une étape de conversion (VII) dudit contenu numérique en un 25 format multimédia compatible à celui dudit terminal mobile, ladite conversion étant réalisée par ledit dispositif informatique (3) après téléchargement dudit contenu. 6. Procédé selon la revendication 5 en dépendance de la 30 revendication 4, dans lequel la conversion dudit contenu numérique téléchargé précède la conversion dudit premier flux de données. 7. Procédé selon l'une quelconque des revendications précédentes, dans lequel ledit dispositif informatique (3) comprend une première 2910208 28 base de données (31b) de contenus numériques et vérifie (III, 102) si ladite première adresse (URL1) de la première requête correspond à un contenu référencé dans ladite première base (31b), et si la vérification est positive, transmet (IV, 108, 204) ladite deuxième 5 adresse (URL2) en réponse à la première requête ; si la vérification est négative, enregistre (104) ladite première adresse (URL1) dans une deuxième base de données (31c) et acquitte (106, 202) ladite première requête auprès du terminal mobile. 10 8. Procédé selon la revendication précédente, comprenant, suite à l'enregistrement dans la deuxième base de données (31c), les étapes suivantes : - le dispositif informatique (3) télécharge (V, 206, 208) ledit contenu numérique renseigné dans le premier flux de données généré à la 15 première adresse (URL1) ; - le dispositif informatique (3) convertit (VII) ledit contenu numérique téléchargé et le premier flux de données en des formats compatibles avec le terminal mobile (5) ; - une fois les conversions effectuées, le dispositif informatique (3) 20 envoie (108, 222) ladite deuxième adresse numérique (URL2) audit terminal mobile. 9. Procédé selon la revendication 8, dans lequel l'envoi de la deuxième adresse numérique est effectué en réponse à une requête 25 ultérieure (IX, 154, 216, 220) du terminal mobile. 10. Procédé selon la revendication 8, dans lequel l'envoi de la deuxième adresse numérique est effectué sous la forme d'un envoi poussé audit terminal mobile. 11. Procédé selon la revendication 1, dans lequel ladite deuxième adresse numérique est l'adresse de stockage (URL2') sur le dispositif informatique (3) dudit contenu numérique téléchargé. 30 2910208 29 12. Plateforme (3) pour le téléchargement sur un terminal mobile (5) d'un contenu numérique mis à jour épisodiquement et renseigné dans un premier flux de données comprenant des indications de mise à jour dudit contenu numérique, ledit premier flux de données étant généré à 5 une première adresse numérique (URL1) d'un réseau informatique (1), la plateforme comprenant : o des moyens pour enregistrer (31), à réception d'une première requête d'un terminal mobile, ladite première adresse numérique (URL1), 10 o des moyens de vérification (32), via le réseau informatique, des indications de mise à jour générées à ladite première adresse numérique, o des moyens pour télécharger et stocker (32) ledit contenu numérique renseigné dans ledit premier flux de données en cas 15 de mise à jour, o des moyens pour transmettre (32), au terminal mobile, une deuxième adresse numérique (URL2) du dispositif informatique utilisée pour réaliser le téléchargement dudit contenu numérique par le terminal mobile au travers d'un réseau de 20 télécommunication mobile. 13. Plateforme selon la revendication précédente, dans laquelle les moyens pour enregistrer comprennent des première et deuxième bases de données (31b, 31c), la première base (31c) stockant ladite 25 première adresse numérique à réception de la première requête lorsque cette première adresse n'est pas enregistrée dans la deuxième base de données (31b) ; les moyens pour télécharger et stocker sont agencés pour déplacer ladite première adresse enregistrée dans la première base de données 30 (31c) vers la deuxième base de données (31b) lorsque ledit contenu numérique a été téléchargé et mis à la disposition dudit terminal mobile (5) sur le réseau de télécommunication mobile (4). 2910208 30 14. Plateforme selon la revendication précédente, dans laquelle les moyens pour télécharger et stocker comprennent un moyen logiciel de conversion dudit contenu numérique et dudit premier flux de données en un contenu numérique adapté et un second flux de données adapté 5 au format dudit terminal mobile (5). 15. Système pour le téléchargement sur un terminal mobile (5) d'un contenu numérique mis à jour épisodiquement et renseigné dans un premier flux de données comprenant des indications de mise à jour 10 dudit contenu numérique, le système comprenant : - au moins un serveur informatique (2) générant ledit premier flux de données à une première adresse numérique (URL1), - une plateforme (3) selon l'une des revendications 12 à 14, et -au moins un terminal mobile (5) comprenant des moyens pour 15 établir, sur le réseau de télécommunication mobile (4), une connexion avec ladite deuxième adresse numérique (URL2) et télécharger ledit contenu numérique depuis ledit dispositif informatique (3).