FR2900519A1 - Procede de diffusion vers au moins un telephone mobile de contenus multimedia - Google Patents

Abstract

Pour rendre la diffusion de contenus multimédia sur un téléphone (101) mobile totalement silencieuse pour l'utilisateur et non préjudiciable pour le réseau de téléphonie mobile, on fait gérer ces diffusions par un serveur (104) de gestion de diffusions. Le serveur de gestion de diffusions gère alors une liste 105 d'abonnements à des flux de données. La récupération de ces flux de données est contrôlée par le serveur de gestion de diffusions qui est alors apte à prendre en compte la charge du réseau et à provoquer le téléchargement des données par le téléphone mobile au moment le plus opportun.

Description

Procédé de diffusion vers au moins un téléphone mobile de contenus

multimédia

La présente invention a pour objet un procédé de diffusion vers au moins un téléphone mobile de contenus multimédia. Le domaine de l'invention est celui de la téléphonie mobile et plus particulièrement celui de la diffusion de contenus multimédia dans les réseaux de téléphonie mobile. Un but de l'invention est de permettre à un utilisateur d'un téléphone mobile d'accéder à une grande variété de contenus multimédia.

Un autre but de l'invention est de parvenir au but précédent en maintenant un dimensionnement raisonnable de l'architecture du réseau de téléphonie mobile. Dans ce document on considère un contenu multimédia au sens le plus large de l'expression, c'est-à-dire tout fichier comportant des données de textes, des données de sons et/ou des données d'images fixes ou animées. Dans l'état de la technique on connaît la diffusion de contenus multimédia vers des dispositifs fixes comme des ordinateurs personnels raccordés au réseau Internet par une connexion permanente à haut débit.

Une telle diffusion est connue, par exemple dans le domaine du téléchargement de fichiers musicaux que ce soit via des offres dites "légales" ou via des réseaux dits "paire à paire" ( peer to peer ). Ces solutions sont basées sur le fait que les dispositifs destinataires de la diffusion sont connectés en permanence à Internet, disposent d'un débit de réception illimité ou assimilé, et surtout disposent d'une autonomie électrique réellement illimitée. Transposer une telle solution sur un téléphone mobile reviendrait, à brève échéance, à écrouler les réseaux de téléphonie mobile et à diviser l'autonomie des téléphones mobiles par quatre ou plus. Dans l'état de la technique on connaît aussi la diffusion en temps réel aussi appelée "streaming". Cependant cette solution requiert une action de l'utilisateur qui doit se connecter au flux de données et le "consommer", c'est-à-dire profiter de sa restitution visuelle et/ou sonore, au fur et à mesure de la réception des données. Ce mode de diffusion impose donc lui aussi une connexion permanente et une autonomie permanente. En effet le flux est joué au fur et à mesure qu'il est reçu. La consommation d'un téléphone mobile serait donc double (réception + restitution) en cas de streaming. Dans l'état de la technique on connaît enfin les flux RSS (Rich Site Summary ou Really Simple Syndication, c'est-à-dire sommaire d'un site enrichi ou syndication vraiment simple). Les flux RSS sont en fait des fichiers XML dynamiques dont une application lecteur affiche les contenus qui sont mis à jour régulièrement. Ce système est très utilisé pour diffuser les nouvelles des sites d'information (actualité, sciences, informatique, etc.) ou des blogs (sites de particuliers), ce qui permet de consulter ces dernières sans visiter le site, ou bien de les formater à sa guise, etc....

L'utilisation des flux RSS a aussi été popularisée par le podcasting , ou baladodiffusion, qui est un moyen de diffusion de fichiers sonores et/ou vidéo, que l'on nomme podcasts en anglais, sur Internet. Par l'entremise d'un abonnement à un flux RSS, la baladodiffusion permet aux utilisateurs d'automatiser le téléchargement d'émissions sonores ou vidéo, notamment pour leur baladeur numérique, sur le disque dur de leur ordinateur personnel, pour une écoute ultérieure. Cependant les flux RSS ou le podcastinq requièrent une application qui surveille en permanence les serveurs mettant ces flux à disposition. C'est, entre autres, cette surveillance qui est la plus consommatrice de ressources et d'autonomie. Elle consiste en effet en une interrogation régulière des serveurs de diffusion. Elle est aussi connue sous le nom de "polling". Pour la mettre en oeuvre il faut donc une connexion quasi permanente à Internet, ce qui est incompatible avec le monde de la téléphonie mobile comme on l'a vu précédemment. Leur mise en oeuvre est donc indissociable de l'utilisation, et donc de l'achat, d'un ordinateur et d'une connexion haut débit. Cela est à la fois onéreux et encombrant. Dans l'invention, pour résoudre ces problèmes, un utilisateur d'un téléphone mobile déclare un abonnement non pas à une application de lecture de flux RSS de son téléphone, mais à un serveur de gestion de diffusions. C'est alors le serveur de gestion de diffusions qui effectue la surveillance des serveurs de diffusion. Le serveur de gestion de diffusions avertit le téléphone de l'abonné lorsqu'un flux est mis à jour et, dans une variante, selon un plan de charge du réseau. Lorsque le téléphone est averti d'une mise à jour d'un flux, il se connecte au serveur de diffusion concerné pour récupérer le flux proprement dit. Une fois le téléchargement effectué, le téléphone notifie alors son utilisateur de la présence d'un nouveau contenu multimédia jouable. Le téléchargement est donc réalisé de façon totalement silencieuse du point de vue de l'utilisateur, et optimale du point de vue des ressources du téléphone mobile.

Dans une variante de l'invention, le téléphone mobile se connecte à un serveur de diffusion via un serveur mandataire qui gère les contenus et leur format. Un tel serveur peut donc avoir préchargé un contenu et adapté son format aux capacités de restitution du téléphone mobile. Dans une variante de l'invention, un téléphone mobile ayant fini ou avorté un téléchargement envoie un message de statut, ce qui permet au serveur de gestion de diffusions de gérer des cas d'erreurs. Ce mode de réalisation permet aussi d'inscrire l'invention dans un schéma de gestion de droits numériques. En effet, la réception d'un message de statut sert alors de déclencheur à un processus d'obtention de droits pour la restitution du contenu téléchargé. Dans une autre variante, le serveur de gestion de diffusions prend en compte la bande passante dont dispose un téléphone mobile pour déterminer la pertinence de l'émission d'un message de notification de mise à jour. Ainsi, si le téléphone dispose d'une bande passante importante, car connecté à une borne locale WiFi par exemple, il est plus apte à suivre un flux de données à fréquence de mise à jour élevée. L'invention a donc pour objet un procédé de diffusion vers au moins un téléphone mobile de contenus multimédia, caractérisé en ce qu'il comporte les étapes suivantes: - un utilisateur d'un téléphone mobile s'inscrit sur un serveur de gestion de diffusions à au moins un flux de données délivré par au moins un serveur de diffusion, - le serveur de gestion de diffusions interroge à intervalles réguliers le serveur de diffusion pour déterminer si le flux de diffusion a été mis à jour, - si le flux de diffusion a été mis à jour, le serveur de gestion de diffusions produit et envoie un message de notification de mise à jour au téléphone mobile, - lorsqu'il reçoit un message de notification de mise à jour le téléphone mobile se connecte au serveur de diffusion pour télécharger la version mise à jour du contenu véhiculé par le flux de données, lorsqu'il a fini un téléchargement, en échec ou en succès, le téléphone mobile notifie l'utilisateur de la fin du téléchargement. Avantageusement l'invention est aussi caractérisée en ce que le serveur de gestion de diffusions émet le message de notification de mise à 5 jour en fonction de la charge du réseau. Avantageusement l'invention est aussi caractérisée en ce qu'en réponse au message de notification de mise à jour, le téléphone mobile produit et émet vers le serveur de gestion de diffusions un message de statut du téléchargement du flux de données par le téléphone mobile. 10 Avantageusement l'invention est aussi caractérisée en ce que si le message de statut est positif et si le type de contenu véhiculé par le flux le requiert, le serveur de gestion de diffusions produit et émet un message de notification de fin de téléchargement vers un serveur de gestion de droits, le serveur de gestion de droits produisant alors à son tour un message de 15 déblocage et l'émettant vers le téléphone mobile. Avantageusement l'invention est aussi caractérisée en ce que le message de déblocage est un message électronique de type message court. Avantageusement l'invention est aussi caractérisée en ce qu'optionnellement, le téléphone mobile utilise un serveur mandataire pour le 20 téléchargement du flux de données. Avantageusement l'invention est aussi caractérisée en ce que le serveur mandataire transcode le flux de données en fonction des capacités de restitution du téléphone mobile. Avantageusement l'invention est aussi caractérisée en ce que le 25 serveur mandataire est le serveur de gestion de diffusions. Avantageusement l'invention est aussi caractérisée en ce que le téléphone mobile produit et émet vers le serveur de gestion de diffusions un message de notification de bande passante, cette information de bande passante étant alors enregistrée par le serveur de gestion de diffusions 30 comme paramètre de production des messages de notification de mise à jour. L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention. Les figures montrent : 35 Figure 1 : Une illustration de moyens permettant la mise en oeuvre du procédé selon l'invention. Figure 2 : Une illustration d'étapes du procédé selon l'invention. Figure 3 : Une illustration d'étapes d'une variante du procédé selon l'invention dans laquelle un message de statut de téléchargement est géré.

Figure 4 : Une illustration d'étapes d'une variante du procédé selon l'invention dans laquelle un contenu multimédia est soumis à une gestion de droits de type DRM (Digital Rights Management). Figure 5 : Une illustration d'étapes d'une variante du procédé selon l'invention dans laquelle les téléchargements sont réalisés via un serveur mandataire. Figure 6 : Une illustration d'étapes d'une variante du procédé selon l'invention dans laquelle le serveur de gestion de diffusions prend en compte la bande passante à laquelle le téléphone mobile a accès. La figure 1 montre un dispositif 101 mobile connecté à un réseau 102 de téléphonie mobile via une station de base 103. Dans la description qui suit on considère que le dispositif 101 est un téléphone mobile. Dans la pratique le dispositif 101 est tout dispositif apte à se connecter à un réseau de téléphonie mobile. L'invention est adaptée à tous les types de réseaux de téléphonie mobile supportant les messages courts (SMS) et l'acheminement de contenus multimédias via des protocoles tels que TCP/IP. Ces réseaux sont donc au moins les réseaux de deuxième génération, les réseaux de deuxième génération et demie, les réseaux de troisième génération et tous réseaux à venir. Dans l'invention, lorsque l'on prête une action à un dispositif, cette action est en fait réalisée par un microprocesseur du dispositif commandé par des codes instructions enregistrés dans une mémoire de programme du dispositif. La figure 1 montre aussi que le réseau 102 comporte un serveur 104 de gestion de diffusions. Le serveur 102 est connecté à l'architecture du réseau 102 en tant qu'élément de ce réseau. Le téléphone 101 et le serveur 104 sont donc aptes à communiquer l'un avec l'autre en tant qu'élément d'un même réseau de téléphonie mobile. Dans l'invention le serveur est apte à communiquer via des protocoles tels que SMS, TCP, FTP, HTTP, WTP... selon le mode de mise en place de l'invention.

Selon l'invention le serveur 104 comporte une mémoire 105 d'inscription. Une telle mémoire peut être vue comme une table dont chaque ligne est un enregistrement qui correspond à un abonnement à un flux de données. Un abonnement est ici décrit par un champ 105.1 comportant une URL, un champ 105.2 comportant un identifiant de l'utilisateur abonné, un champ 105.3 TTL comportant une fréquence à laquelle un flux de données est susceptible d'être mis à jour et un champ 105.4 drapeau indiquant si le flux de données a été mis à jour ou non. Un flux/fil de données multimédia est disponible sur un serveur de données et est donc identifié par une URL (Universel Resource Locator, pour adresse universelle d'une ressource). Cette URL correspond alors à un fichier de description du flux de données multimédia. Cette description comporte une URL correspondant aux données multimédia et des informations sur le flux, comme sa période de mise à jour, la date de sa dernière mise à jour, son auteur, son titre, une description sommaire, cette liste n'étant pas exhaustive. Une telle description est donc, par exemple, selon un format RSS ou équivalent. Le champ 105.2 est, dans le contexte de la téléphonie mobile, un numéro de téléphone (IMSI) ou un numéro d'identification du type IMEI, MAC, etc..

Le champ 105.3 comporte une période à laquelle le flux de données multimédia décrit est susceptible d'être mis à jour par son auteur. Cette information est obtenue par le serveur 104 depuis un serveur de diffusion grâce au fichier de description du flux de données identifié par le champ 105.1. Cette information de période est associée, sur le serveur 104, à une date de dernière lecture de la description du flux. Cette date permet, en comparant avec la date de la dernière mise à jour de la description du flux de données de déterminer s'il y a eu mise à jour du flux de données multimédia depuis la dernière interrogation. Le champ 105.4 est un drapeau qui, dans un mode de mise en oeuvre de l'invention, indique si le flux de données à été mis à jour depuis la dernière interrogation par le serveur. Ce champ est réinitialisé par le serveur 104 au moment d'un abonnement à un flux de données et en fonction du résultat du téléchargement du flux de données par l'abonné audit flux. La figure 1 montre aussi que le serveur 104 comporte un mémoire 106 de stockage qui lui permet, dans une variante d'enregistrer les données des flux de données. Cette mémoire associe alors des données à une URL. Un abonné à un flux de données se connectera alors au serveur 104 pour récupérer les données, et non pas au serveur identifié par l'URL. On parle alors de fonctionnement en mode serveur mandataire / proxy.

Le serveur 104 comporte aussi, dans une variante, une mémoire 107 permettant d'associer à un identifiant 107.1 d'utilisateur des informations relatives à l'utilisateur. L'identifiant 107.1 est du même type que l'identifiant 105.2. Les informations sont, par exemple, une information 107.2 de bande passante accessible à l'utilisateur, une information 107.3 de nombre maximum d'abonnements pour l'utilisateur, la liste n'étant pas exhaustive. La figure 1 montre encore que le réseau 102 comporte une passerelle 108 permettant aux dispositifs du réseau 102 d'accéder au réseau 109 Internet et vice et versa. Le réseau 109 comporte lui au moins un serveur 110 de diffusion dont le contenu est adressable via le champ 105.1.

Selon une variante de l'invention le réseau 109 comporte aussi un serveur 111 de gestion de droits numériques (DRM) qui est accessible soit via le réseau 109, soit directement par le réseau 102 via des messages SMS ou assimilés. Ici on assimile les messages MMS à des messages SMS. La figure 1 montre encore un poste 112 de type ordinateur personnel connecté au réseau 109 Internet via un réseau 113 d'un FAI (Fournisseur d'accès à Internet). La figure 2 montre une étape 201 dans laquelle le téléphone 101 teste si l'utilisateur du téléphone 101 souhaite s'inscrire à un flux de données. L'utilisateur manifeste cette volonté par le lancement d'une application permettant l'inscription à un flux de données. Cette application est peut être une application dédiée et installée sur le téléphone mobile. Une telle application est par exemple écrite dans un langage tel que Java ou bien directement prévue pour le système d'exploitation du téléphone mobile. Cette application peut aussi être un navigateur Internet se connectant à un site d'inscription. Dans une variante de l'invention, le site d'inscription est hébergé par le serveur 104 lui-même. Si l'utilisateur manifeste la volonté de s'inscrire à un flux de données, alors on passe d'une étape 201 à une étape 202 d'inscription. Sinon le téléphone poursuit la gestion des événements. On considère ici en effet, comme c'est effectivement le cas, que le téléphone est doté d'un système d'exploitation multitâche, qu'il soit préemptif ou coopératif. Le téléphone réagit donc à des événements qui sont signalés au système d'exploitation par des mécanismes classiques dans les systèmes d'exploitation multitâches.

Dans l'étape 202 l'utilisateur produit un message 299 d'inscription comportant au moins trois champs. Un premier champ 299.1 est un champ code instruction indiquant la nature du message, un deuxième champ 299.2 est un champ comportant l'URL du flux de données auquel l'utilisateur souhaite s'abonner et un troisième champ 299.3 est un identifiant de l'abonné. Ce message d'inscription est soit produit via des saisies manuelles, soit via la consultation d'un annuaire, une solution n'excluant pas l'autre. On remarque ici que selon le mode de connexion entre le dispositif utilisé par l'utilisateur pour s'abonner et le serveur 104, le troisième champ peut être facultatif. En effet dans un mode de réalisation la première opération que doit exécuter l'utilisateur pour s'abonner est de se connecteur au serveur d'abonnement. On considère que le serveur d'abonnement est ici le serveur 104. Lors de cette connexion l'utilisateur doit s'authentifier, l'identité de l'utilisateur étant alors au final connue du serveur d'abonnement. Dans un autre mode de réalisation, l'utilisateur utilise son téléphone et une application dédiée pour s'abonner. Dans ce cas, ledit téléphone est connecté au réseau 102 et est connu de ce réseau. Le serveur 104 faisant partie du réseau 102 connaît l'identité de l'utilisateur. Dans encore un autre mode de réalisation, l'identité de l'utilisateur est connue via les entêtes du message contenant les deux premiers champs. En effet de nombreux protocoles de communications, dont TCP/IP et SMS, prévoient qu'un message comporte un champ expéditeur contenant un identifiant de l'utilisateur expédiant le message. Dans la pratique, tous les messages décrits ici, sauf indication contraire, sont émis comme des messages SMS, ou via un protocole du type 30 TCP/IP par exemple sous la forme d'une requête HTTP. Le message 299 une fois produit est expédié vers le serveur 104. On note ici que le serveur 104 est lui aussi doté d'un système d'exploitation multitâche gérant des événements. A la fin de l'étape 202 le téléphone poursuit la gestion des 35 événements.

On note ici qu'un utilisateur peut s'inscrire, ou plus exactement inscrire son téléphone, à un flux de données depuis n'importe quel dispositif capable de se connecter au serveur 104 d'abonnement. Ainsi l'utilisateur du téléphone 101 peut s'inscrire à un flux de données depuis le poste 112.

L'étape 202 n'est donc pas nécessairement mise en oeuvre par le téléphone 101. L'expédition du message se fait donc, selon le mode de réalisation choisi, par l'envoi d'un message de type SMS, ou par la validation d'un formulaire dans un navigateur Internet.

Le serveur 104, dans une étape 203, teste à intervalles réguliers s'il a reçu un message d'abonnement. Si c'est le cas, il passe à une étape 204 d'enregistrement de l'abonnement, sinon il poursuit la gestion des événements. Dans l'étape 204, le serveur 104 utilise le contenu du message 299 pour enregistrer un nouvel enregistrement dans la mémoire 105. Le champ 105.1 de ce nouvel enregistrement se voit attribuer la valeur du champ 299.2. Le champ 105.2 de ce nouvel enregistrement se voit attribuer la valeur du champ 299.3. Puis le serveur se connecte au flux de données identifié par le champ 105.1 pour obtenir la description du flux de données et mettre à jour le champ 105.3. Par défaut le champ 105.4 est positionné à 1 ce qui signifie qu'un nouveau contenu est disponible. Dans une variante de l'invention, la création du nouvel enregistrement est conditionnée par le contenu de la mémoire 107 associé au contenu du champ 105.2. En effet si le serveur 104 peut associer à l'identifiant de l'utilisateur, via la mémoire 107, un nombre maximal d'abonnements alors le serveur vérifie dans la mémoire 105 le nombre d'abonnements dont est titulaire l'utilisateur. Si le nombre d'abonnements dont est titulaire l'utilisateur est supérieur au nombre d'abonnements maximal auquel l'utilisateur peut prétendre, alors la création du nouvel enregistrement n'est pas réalisée.

Dans la pratique à la fin de l'étape 204, le serveur émet vers le dispositif utilisé par l'utilisateur pour s'abonner un message décrivant le résultat de l'opération d'abonnement. L'utilisateur sait ainsi si oui ou non il est effectivement abonné à un nouveau flux de données. L'étape 204 est suivie, à plus ou moins court terme selon la planification des tâches sur le serveur 104, par une étape 205 d'interrogation des serveurs de données référencés dans la mémoire 105. Dans l'étape 205, le serveur 104 parcourt en séquence les enregistrements de la mémoire 105 et pour chaque enregistrement éligible à l'interrogation, le serveur 104 interroge le serveur de données concerné en utilisant le contenu du champ 105.1 de l'enregistrement éligible. Un enregistrement 105.1 est éligible à l'interrogation si la dernière interrogation le concernant est disante dans le temps d'au moins le contenu du champ 105.3. En d'autres termes un enregistrement de la mémoire 105 est éligible à l'interrogation selon une période décrite par le champ 105.3 de l'enregistrement concerné. Une telle interrogation (GET URL par exemple en http) permet au serveur 104 d'obtenir la description du flux de données et en particulier la date de dernière mise à jour du flux. Si cette date obtenue est supérieure à la date de dernière mise à jour connue du serveur 104 alors cela signifie que le flux de données correspondant a été mis à jour, le serveur positionne alors la valeur du champ 105.4 correspondant à 1. Dans la pratique, si des initialisations de champs 105.4 sont à réaliser, elles sont faites dans une étape 206. L'étape 205 est suivie, à plus ou moins court terme selon la planification des tâches sur le serveur 104, par une étape 207 de notification des utilisateurs. Dans l'étape 205, le serveur 104 parcourt la mémoire 105 pour déterminer si des flux de données ont été mis à jour. Un flux de données à été mis à jour si le champ 105.4 d'un enregistrement le décrivant vaut 1. Si de tels enregistrements existent, alors le serveur passe à une étape 208 de notification des utilisateurs. Dans l'étape 208, pour chaque enregistrement de la mémoire 105 dont le champ 105.4 vaut 1, le serveur 104 produit et émet un message 298 de notification de mise à jour. Une fois le message 298 produit et émis, le serveur 104 réinitialise le champ 105.4 à zéro. Dans une variante de l'invention, le champ 105.4 n'est réinitialisé que sur réception d'un message de statut en réponse au message de notification de mise à jour. Un message de notification de mise à jour comporte un champ 298.1 indiquant la nature du message et un champ 298.2 comportant un identifiant d'un abonnement ou, de manière équivalente, le contenu du champ 105.1 de l'enregistrement en cours de traitement. Ce message est alors envoyé à l'utilisateur identifié par le contenu du champ 105.2 du champ en cours de traitement. Dans une variante de l'invention, la fréquence d'émission des messages de notification de mise à jour est contrôlée par le serveur 104. Ce contrôle est réalisé via le contenu de la mémoire 107. La mémoire 107 permet en effet d'associer à chaque utilisateur une information 107.2 de bande passante. Si l'utilisateur dispose d'une bande passante élevée, alors il peut recevoir des messages de notification de mise à jour fréquemment, sinon il ne le peut pas. Ce mode de contrôle est pertinent car un message de notification de mise à jour est suivi d'une tentative de téléchargement d'un contenu multimédia par le téléphone destinataire de message de notification. Si le message de notification ne consomme que peu de bande passante, il n'en est pas de même pour les contenus multimédia. Dans l'invention, limiter le nombre de messages de notification de mise à jour revient donc à contrôler l'utilisation de la bande passante. Ainsi, si un utilisateur dispose d'une bande passante élevée alors il pourra être notifié à chaque fois qu'un des flux de données auxquels il est abonné a été mis à jour. Dans le cas contraire, le serveur 104 cherche à optimiser la bande passante de l'abonné. Cette optimisation est, par exemple, le non envoi de message de notification durant certaines plages horaires, ou le plafonnement du nombre de messages de notification émis par intervalle de temps, un intervalle de temps s'exprimant en heures. Ainsi un utilisateur abonné à un flux de données ayant une période de rafraîchissement de cent vingt secondes mais disposant d'une faible bande passante ne recevra que deux ou trois messages de notification par heure pour ce flux. Les messages de notification de mise à jour sont envoyés vers le téléphone 101 soit par des SMS et un mécanisme dit de 'pushRegistry', soit via un socket que le téléphone 101 maintient ouvert dans l'attente d'un tel message. L'intérêt d'un tel mode de fonctionnement est qu'il ne requiert aucune intervention de la part de l'utilisateur du téléphone. Le message ainsi reçu est automatiquement pris en compte et traité par le téléphone mobile. Au cours d'une étape 209, le téléphone 101 vérifie s'il a reçu un message de notification de mise à jour. Parmi les messages reçus, un tel message est identifiable grâce à son champ 298.1 code instruction. Si un tel message a été reçu alors le téléphone passe à une étape 210 de téléchargement, sinon il continue la gestion des événements. Dans l'étape 210, le téléphone 101 utilise le contenu du champ 298.2 pour se connecter au serveur de données dont l'adresse est décrite par le champ 210. Via le contenu du champ 298.2, le téléphone 101 récupère alors la description d'un flux de données. Cette description comporte à son tour une URL que le téléphone 101 utilise pour récupérer, de manière silencieuse, les données correspondant au flux de données, c'est-à-dire un contenu multimédia. Le contenu multimédia est enregistré dans une mémoire de stockage du téléphone mobile pour une restitution ultérieure. Cette récupération se fait, par exemple, via une requête HTTP GET sur l'URL que comporte la description. Bien entendu, d'autres protocoles sont envisageables. En fait le protocole utilisé est fixé par l'URL elle-même.

Dans une variante de l'invention, lorsque le téléchargement est fini le téléphone passe à une étape 211 de production et d'émission d'un message 297 de statut du téléchargement. Un message de statut comporte un champ 297.1 code instruction correspondant à la nature du message, un champ 297.2 identifiant l'URL objet du téléchargement (dans la pratique l'URL du flux de données elle-même) et un champ 297.3 comportant un code de statut. Un tel code de statut est, par exemple, téléchargement réussi, un code d'erreur HTTP, capacité de stockage maximale atteinte, perte du réseau en cours de téléchargement, la liste n'étant pas exhaustive. L'étape 210, ou 211, est suivie d'une étape 212 de notification de l'utilisateur de la présence d'un nouveau contenu multimédia à restituer. Cette notification se fait de manière similaire à celles qui existent pour prévenir l'utilisateur de la présence d'un nouvel SMS ou d'un appel en absence. Apartir de cette notification, l'utilisateur peut restituer le contenu multimédia. Dans une variante de l'invention, l'étape 207 est suivie, à plus ou moins court terme selon la planification des tâches sur le serveur 104, par une étape 213 de traitement des messages de statut. Dans l'étape 213, le serveur détermine s'il a reçu un message de statut de téléchargement. Si oui, alors il passe à une étape 214 de traitement du message 297 de statut. L'étape 214 comporte une étape 301 d'analyse du code de statut. Le code de statut correspond à la valeur du champ 297.3. Si le code de statut correspond à une erreur alors le serveur passe à une étape 302 de traitement de l'erreur, sinon il passe à une étape 303 de validation du téléchargement. Dans l'étape 303, le serveur utilise le contenu du champ 297.2 pour déterminer un enregistrement dans la mémoire 105. Une fois cet enregistrement trouvé, le serveur initialise le champ 105.4 de cet enregistrement à 0. Dans l'étape 302, le serveur 104 traite les cas d'erreurs. Divers cas d'erreurs sont ici énumérés pour une bonne appréhension de l'application, sans pour autant que cette énumération ne soit exhaustive. Par exemple dans le cas d'un téléchargement interrompu (batterie du téléphone vide, perte de couverture réseau, ...), le serveur planifie suivant un calendrier de réessai un nouveau message de notification de mise à jour et donc une nouvelle tentative de téléchargement. Dans un autre exemple, dans le cas d'une erreur 401 ou 404 HTTP, le serveur décide de supprimer l'abonnement correspondant dans la mémoire 105, le contenu multimédia correspondant n'étant visiblement plus accessible. Dans un autre exemple, si l'utilisateur interrompt son téléchargement en cours, celui-ci est annulé par le serveur 104. Encore, dans un autre exemple, si aucune notification n'est envoyée par le téléphone dans un délai paramétré sur le serveur 104, le téléchargement est supposé avoir échoué et le serveur 104 planifie une nouvelle tentative également suivant un calendrier de réessai. Enfin, dans un autre exemple, si la mémoire du téléphone est pleine au début du téléchargement, le serveur 104 reçoit une notification indiquant que le téléchargement ne peut avoir lieu du fait de la mémoire insuffisante. L'utilisateur est alors informé par un message SMS envoyé par le serveur 104 qu'il doit libérer de la mémoire sur son téléphone et le serveur 104 planifie un nouveau téléchargement du contenu multimédia suivant un calendrier de réessai. Dans une variante de l'invention, après l'étape 303, le serveur passe à une étape 304 de détermination d'une DRM. Dans la pratique, la description d'un flux de données comporte une information relative à la soumission de la restitution du contenu multimédia à l'acquittement d'un droit. Cette information peut donc être enregistrée par le serveur 104 dans la mémoire 105 au moment de l'abonnement. Cette information identifie un serveur de droits ou serveur DRM. Si une information de DRM est présente dans l'enregistrement de la mémoire 105 correspondant au message de statut de téléchargement et si le code de statut correspond à un téléchargement finalisé, alors le serveur passe de l'étape 304 à une étape 305 de notification du titulaire des droits. Sinon le serveur poursuit la surveillance des événements. Dans l'étape 305 le serveur 104 produit un message de notification de téléchargement finalisé au titulaire des droits sur le contenu multimédia téléchargé. Ce message de notification de téléchargement finalisé comporte un identifiant de l'utilisateur ayant téléchargé le contenu multimédia et un identifiant du contenu multimédia téléchargé. Ce message va donc permettre au titulaire des droits de produire un message de déblocage. Le message de déblocage est classiquement un message court comportant un identifiant du contenu multimédia et une clé de déblocage de la lecture du contenu multimédia. En règle générale un contenu multimédia comporte son propre identifiant et les lecteurs comportent les mécanismes de recherche de clé de déblocage.

La figure 4 illustre le fait qu'à un moment dépendant du séquencement des tâches par le téléphone 101, le téléphone 101 va regarder s'il a reçu un message de déblocage dans une étape 401. Si un tel message a été reçu, alors le téléphone passe à une étape 402 d'enregistrement des droits, sinon il poursuit la gestion des événements.

Dans l'étape 402, le téléphone 101 inscrit les droits reçus via le message de déblocage dans une mémoire de droits du téléphone 101. Dans la mesure où ces droits sont reçus via un SMS, l'inscription des droits dans la mémoire de droits du téléphone peut requérir optionnellement une validation de l'utilisateur du téléphone. Dans les mécanismes utilisés habituellement dans le monde de la téléphonie mobile (download OMA par exemple), cette confirmation n'est pas requise. La figure 4 illustre qu'à un moment dépendant de la gestion des événements par le téléphone 101, le téléphone dans une étape 403 va déterminer si l'utilisateur souhaite restituer un contenu multimédia. Si oui, le téléphone passe à une étape 404 de détermination des droits requis pour la restitution du contenu, sinon le téléphone poursuit sa gestion des événements. Si oui, cela signifie qu'un utilisateur du téléphone 101 a sélectionné pour activation un fichier correspondant au contenu multimédia. Dans l'étape 404, le téléphone ouvre le contenu multimédia pour y lire si sa restitution est soumise à des droits. Si elle ne l'est pas, alors le téléphone 101 passe à une étape 405 de restitution, sinon le téléphone 101 parcourt la mémoire de droits du téléphone 101 pour déterminer si l'utilisateur du téléphone 101 est titulaire des droits requis pour la restitution du contenu multimédia. S'il possède les droits, alors le téléphone passe à l'étape 405, sinon le téléphone poursuit sa gestion des événements. Dans l'étape 405, le téléphone 101 restitue le contenu multimédia sélectionné à l'étape 403. La figure 5 illustre une variante pour l'étape 210. La figure 5 illustre le fait que la requête GET émise par le téléphone 101 pour récupérer le contenu multimédia n'est pas émise directement vers le serveur de diffusion identifié par l'URL du message de notification de mise à jour mais vers un serveur mandataire qui dans une variante de l'invention peut être le serveur 104. Ainsi, une des tâches du serveur 104 est de déterminer, dans une étape 501, si le serveur 104 reçoit une requête GET. Si tel est le cas, alors le serveur 104 passe à une étape 502 de parcours de la mémoire 106 pour déterminer si le contenu correspondant à l'URL demandée est présent dans cette mémoire 106. Si c'est le cas, alors le serveur 104 passe à une étape 503 de 25 formatage du contenu multimédia. Sinon le serveur 104 passe à une étape 504 de récupération du contenu multimédia correspondant à l'URL. Pour ce faire, le serveur 104 produit et émet une requête de type GET URL sur Internet. Dans une étape 505, le serveur 104 enregistre le contenu de la 30 réponse à la requête émise à l'étape 504. Si la réponse à la requête de type GET URL émise par le serveur 104 à l'étape 504 est un message d'erreur, alors ce message d'erreur est retransmis au téléphone 101 et le processus s'arrête là. De l'étape 505, le serveur 104 passe à l'étape 503. 35 L'étape 503 est une étape facultative dans laquelle le serveur 104, en fonction d'une connaissance des capacités de restitution du terminal 101, détermine si le contenu multimédia est adapté au terminal 101. Si le contenu est adapté alors le serveur 104 passe à une étape 506 d'émission du contenu multimédia vers le téléphone 101, sinon le serveur 104 passe à une étape 507 de transcodage du contenu multimédia. Dans l'étape 507, le serveur détermine d'abord s'il n'existe pas dans la mémoire 106 une version du contenu multimédia adapté au téléphone 101 et si ce n'est pas le cas, alors le serveur 104 produit une telle version. Le serveur 104 passe alors à l'étape 506.

Dans l'étape 506, le serveur émet la version adaptée du contenu multimédia vers le téléphone 101 en réponse à la requête de type GET émise à l'étape 210. Dans la variante de l'invention décrite pour la figure 5, l'étape 214 peut comporter des étapes supplémentaires de gestion du contenu de la mémoire 106. Il est en effet alors intéressant d'effacer des contenus de cette mémoire en fonction des messages de statut de téléchargement reçus et des résultats des interrogations effectuées à l'étape 205 de manière à ne conserver dans la mémoire 106 que des contenus pertinents, c'est-à-dire des contenus susceptibles d'être demandés par un utilisateur abonné à un flux de données. Dans une autre forme de la variante décrite pour la figure 5, le serveur 104 exécute, selon un séquencement prédéfini, une tâche 215 de préenregistrement des contenus multimédia. Dans l'étape 215, le serveur 104 parcourt la mémoire 105 à la recherche des contenus multimédia susceptibles d'être demandés par les téléphones mobiles des utilisateurs abonnés à des flux de données. Ces contenus multimédia sont ceux pour lesquels les champs 105.4 valent 1. Alors pour chacun de ces flux le serveur 104 enregistre, et éventuellement adapte, le contenu multimédia dans la mémoire 106. Cela permet au serveur 104 d'être plus réactif lorsque qu'un utilisateur va effectivement demander un contenu multimédia. La figure 6 illustre une variante de l'invention dans laquelle le téléphone 101 surveille, via une étape 601, la bande passante à laquelle il a accès. Dans la pratique, il s'agit soit d'une bande passante correspondant à un réseau de téléphonie mobile de deuxième génération, soit d'une bande passante correspondant à un réseau de troisième génération, soit encore d'une bande passante correspondant à une boucle locale aérienne (Wi max) ou bien encore d'une bande passante correspondant à une connexion de type haut débit via un point d'accès domestique WiFi. Lorsque le téléphone 101 détecte un changement de la bande passante à laquelle il a accès, alors il passe à une étape 602 dans laquelle il produit un message 699 de notification de bande passante. Le message 699 comporte un champ 699.1 correspondant à un code instruction décrivant la nature du message 699, un champ 699.2 (optionnel comme pour le message 299) correspondant à un identifiant de l'utilisateur du téléphone 101 et un champ 699.3 décrivant la bande passante. De sont coté, le serveur 104 surveille, via une étape 603 la réception de message de notification de bande passante. Si un tel message est reçu, alors le serveur 104 passe à une étape 604 d'enregistrement des informations contenues dans ce message.

Dans l'étape 604, le serveur 104 utilise le contenu du champ 699.2 pour déterminer un enregistrement dans la mémoire 107. Une fois cet enregistrement déterminé, le serveur 104 utilise le contenu du champ 699. 3 pour mettre à jour le contenu du champ 107.2. Avec l'invention il est donc possible pour un utilisateur du réseau 102 de s'abonner à un flux de données correspondant à une émission/publication hebdomadaire et de consulter cette émission/publication sur son téléphone mobile sans avoir à se soucier de la télécharger lui-même. Avec l'invention et ses variantes, même les contenus DRM sont chargés de manière silencieuse.

De plus l'invention permet de ne pas surcharger le réseau 102 avec des pollings intempestifs et/ou avec des téléchargements consommateurs de bande passante pendant une période de grande utilisation du réseau.

Claims (9)

REVENDICATIONS

1 - Procédé de diffusion vers au moins un téléphone (101) mobile de contenus multimédia, caractérisé en ce qu'il comporte les étapes suivantes: - un utilisateur d'un téléphone mobile s'inscrit (202) sur un serveur (104) de gestion de diffusions à au moins un flux de données délivré par au moins un serveur (110) de diffusion, - le serveur de gestion de diffusions interroge (205-206) à intervalles réguliers le serveur de diffusion pour déterminer si le flux de diffusion a été mis à jour, - si le flux de diffusion a été mis à jour, le serveur de gestion de diffusions produit et envoie (207-208) un message de notification de mise à jour au téléphone mobile, - lorsqu'il reçoit (209) un message de notification de mise à jour le téléphone mobile se connecte (210) au serveur de diffusion pour télécharger la version mise à jour du contenu véhiculé par le flux de données, - lorsqu'il a fini un téléchargement, en échec ou en succès, le téléphone mobile notifie (212) l'utilisateur de la fin du téléchargement.

2 - Procédé selon la revendication 1 caractérisé en ce que le serveur de gestion de diffusions émet le message de notification de mise à jour en fonction (208) de la charge du réseau.

3 - Procédé selon l'une des revendications 1 ou 2 caractérisé en ce qu'en réponse au message de notification de mise à jour, le téléphone mobile produit et émet (211) vers le serveur de gestion de diffusions un message de statut du téléchargement du flux de données par le téléphone mobile.

4 - Procédé selon la revendication 3, caractérisé en ce que si le message de statut est positif et si le type de contenu véhiculé par le flux le requiert, le serveur de gestion de diffusions produit et émet (305) un message de notification de fin de téléchargement vers un serveur de gestion de droits, le serveur de gestion de droits produisant alors à son tour un message de déblocage et l'émettant vers le téléphone mobile.

5 - Procédé selon la revendication 4, caractérisé en ce que le message de déblocage est un message électronique de type message court.

6 - Procédé selon l'une des revendications 1 à 5 caractérisé en ce quele téléphone mobile utilise (501-507) un serveur mandataire pour le téléchargement du flux de données.

7 - Procédé selon la revendication 6 caractérisé en ce que le serveur mandataire transcode (507) le flux de données en fonction des capacités de 5 restitution du téléphone mobile.

8 - Procédé selon l'une des revendications 6 ou 7, caractérisé en ce que le serveur mandataire est le serveur de gestion de diffusions.

9 - Procédé selon l'une des revendications 1 à 8, caractérisé en ce que le téléphone mobile produit et émet (601-602) vers le serveur de gestion 10 de diffusions un message de notification de bande passante, cette information de bande passante étant alors enregistrée par le serveur de gestion de diffusions comme paramètre de production des messages de notification de mise à jour.