Brevet FR2920620A1 — publié le 20090306

Fourniture de services média permettant la reprise de sessions interrompues L'invention a trait à la fourniture à distance de services média à la 5 demande, tels que, par exemple, vidéo à la demande (VoD, de l'anglais Video on Demand) ou audio à la demande (AoD, de l'anglais Audio on Demand). De tels services sont fournis, à un terminal abonné, par un serveur d'applications média sur lequel des données média (vidéo, son) sont 10 stockées et à partir duquel ces données sont transmises en flux au terminal, sur requête préalablement transmise par celui-ci. Le service suppose, bien entendu, que le terminal soit équipé d'un lecteur média (tel que Media Player� ou RealPlayer�) configuré pour lire û éventuellement après décryptage et/ou décompression û et restituer les 15 données média sur une interface graphique (écran) et/ou audio (haut- parleurs). De nombreux opérateurs estiment que les services média à la demande sont appelés à remplacer à moyen terme les services de diffusion classique (radio et surtout télévision) en proposant aux 20 utilisateurs abonnés des fonctionnalités plus souples, mêlant le direct et le différé. Ainsi, dans un service classique de VoD, il est possible, au cours d'une session média retransmettant une émission initialement diffusée en direct, d'interrompre à tout instant la restitution sur le terminal, pour 25 la reprendre ultérieurement à un moment choisi par l'utilisateur. Ce service, de type lecture/pause, est extrêmement apprécié car il dispense l'utilisateur d'être continuellement présent au cours de la diffusion. Toutefois, la session média elle-même ne doit pas être interrompue, car les données continuent d'être diffusées, en étant 30 simplement mises en cache dans le terminal pour une restitution ultérieure (en différé) au moment choisi par l'utilisateur. Un inconvénient majeur de ce type de service est que l'interruption d'une session média en cours oblige l'utilisateur souhaitant voir et/ou écouter la fin de l'émission à la reprendre depuis le début. 35 Il existe un autre type de service, appelé podcast, distinct de l'AoD et de la VoD, grâce auquel l'utilisateur peut télécharger des fichiers de données média sur son terminal pour les lire ensuite au moyen d'un lecteur média approprié (qui peut être le même que pour un service de VoD ou de AoD). Si le podcast permet à l'utilisateur d'accéder directement aux plages de son choix (à condition que son lecteur média le permette, ce qui est généralement le cas), en tant que service de fourniture de média en différé total il ne permet pas, par définition, la diffusion de données média en direct. En outre, il présente l'inconvénient que les fichiers podcastés doivent être sauvegardés localement sur le terminal, la lecture des données depuis un autre terminal obligeant l'utilisateur à podcaster de nouveau les fichiers sur le nouveau terminal. L'invention vise à améliorer les services de fourniture de services média à la demande. À cet effet, un objet de l'invention est un procédé de fourniture à distance d'un service média à la demande depuis un serveur d'applications média à un terminal muni d'un lecteur média et relié au serveur d'applications par l'intermédiaire d'un réseau de télécommunications, ce procédé comprenant les opérations consistant à: - établir une session média entre le serveur d'applications et le terminal, cette session comprenant la fourniture au terminal, par le serveur d'applications, d'un flux de données média ; -restituer sur le terminal, au moyen du lecteur média, les données média reçues au sein du flux, - créer un signet, associé aux données média et comprenant au moins deux pointeurs, à savoir : - un premier pointeur indiquant la provenance des données média, - un second pointeur indiquant un instant prédéterminé au sein de la session média, - mémoriser ledit signet. D'autres objets et avantages de l'invention apparaîtront à la lumière de la description faite ci-après en référence aux dessins annexés dans lesquels : - la figure 1 est un schéma illustrant l'architecture d'un système de communication permettant la mise en oeuvre d'un procédé de fournitures de services média à la demande selon l'invention ; - la figure 2 est un diagramme illustrant l'échange de données entre différents composants du système de communication de la figure 1, - la figure 3 représente un générateur de signets, tel qu'affiché sur 5 un terminal accédant à des services média à la demande ; - la figure 4 représente un panneau d'affichage de signets mémorisés lors d'une session média. Un système 1 de communication est illustré sur la figure 1. Ce système 1 est, de manière classique, organisé en trois couches : une 10 couche 2 de transport et d'accès, une couche 3 de contrôle et une couche 4 de services. Au niveau de la couche 2 de transport et d'accès, le système 1 de communication comprend au moins un terminal 5 muni d'un écran et intégrant un lecteur média tel que MediaPlayer ou RealPlayer. On 15 suppose que l'utilisateur du terminal 5 est abonné à un service de fourniture en ligne de média à la demande (VoD ou AoD). Le terminal 1 peut être fixe, tel qu'un ordinateur personnel, ou mobile, tel qu'un Assistant numérique personnel (PDA, Personal Digital Assistant) communicant ou encore un Smartphone. Dans ce dernier cas, le 20 terminal 2 est relié à un réseau 6 de mobiles permettant de transmettre des données média par l'interface air, par exemple un réseau de troisième génération (3G), un réseau WiFi, WiMax, etc. Il est à noter qu'un même utilisateur peut disposer, pour un même abonnement, de plusieurs terminaux 5, par exemple un terminal fixe et 25 un terminal mobile. Le ou chaque terminal 5 est relié à un réseau 7 de télécommunications de type IP (Internet Protocol), par exemple l'Internet. Dans le cas d'un terminal 5 mobile, cette liaison est assurée par l'intermédiaire du réseau 6 de mobiles 3G et d'une passerelle 8 ou 30 MGW (Media GateWay), comme cela est illustré sur la figure 1. Au niveau de la couche 3 de contrôle, le système de communication comprend un serveur 9 mandataire ou proxy, qui peut être intégré à une infrastructure IMS (1P Multimedia Subsystem) et est relié aux terminaux 5 par l'intermédiaire du réseau 7 (éventuellement 35 via une passerelle). Le proxy 9 intègre quatre modules fonctionnels : - un module proxy 10, configuré pour détecter et, sous certaines conditions décrites ci-après, intercepter des requêtes d'établissement de session en provenance du terminal 5 ; - un gestionnaire 11 de session - un module 12 HTML (HyperText Markup Language), et - un module 13 de gestion de signets, dont la fonction apparaîtra ci-après. Le système 1 de communication comprend en en outre, au niveau de la couche 4 de services, au moins un serveur 14 d'applications 10 média relié au proxy 9 (par exemple via l'Internet). Le serveur 14 d'applications média intègre (ou est relié à) une base de données 15 sur laquelle est mémorisé au moins un fichier 16 de données média, vidéo et/ou audio, appelé fichier source. En pratique, sur la base de données 15 sont mémorisés plusieurs fichiers 15 sources. II est à noter que des données média (vidéo et audio) peuvent être séparées sur plusieurs serveurs, un premier serveur d'application étant par exemple dédié à la vidéo tandis qu'un autre est dédié à l'audio. Le ou chaque fichier source 16 est identifié par une adresse, 20 communément appelée URL (de l'anglais Uniform Resource Locator), composée d'une chaîne de caractères à syntaxe normalisée, dont voici un exemple donné à titre purement illustratif : rtsp://stream 1. europe 1. fr:554/aod3/02 10_2006 01. ra où rtsp:// indique le protocole de communication utilisé, en 25 l'occurrence le protocole RTSP (Real Time Streaming Protocol ou protocole de diffusion en continu) défini par l'IETF dans le standard RFC2326 d'avril 1998 ; streaml.europel.fr:554 identifie le serveur 14 d'applications média ; et /aod3/02_10_2006_01.ra identifie le fichier 16 de données media mémorisé sur la base de données. Dans cet 30 exemple, l'extension .ra indique qu'il s'agit un fichier média lisible sur RealPlayer. Initialement, une première session média est établie entre le serveur 14 d'applications et le terminal 5, sur requête de celui-ci. Toute requête d'établissement émise par le terminal 5 à destination 35 du serveur 14 d'applications transite par le proxy 9, configuré pour détecter les requêtes, et dont le gestionnaire 11 de sessions mémorise les sessions média (en dressant la liste des URLs correspondantes) se déroulant entre le terminal 5 et le serveur 14 d'applications. Une fois la session établie, le serveur 14 d'applications envoie au terminal un flux de données média qui sont restituées par le lecteur média du terminal 5, éventuellement après avoir été décryptées et/ou décompressées. Le lecteur média affiche sur l'écran du terminal 5 un panneau de contrôle au sein d'une première fenêtre 17. Dans le cas de données vidéo, ce panneau de contrôle peut, comme cela est illustré sur la figure 2, inclure un écran virtuel 18 en incrustation, au sein duquel s'affiche la vidéo. Le module 13 de gestion de signets commande par ailleurs le lancement, au sein du terminal, lors de l'établissement de la session, d'une application 19 de génération de signets correspondant au flux de données média en cours de transmission. Ce générateur de signets comprend une interface utilisateur ou GUI (Graphical User Interface) qui, comme dans l'exemple illustré sur la figure 2, peut se présenter sous la forme d'un tableau inclus dans une fenêtre secondaire 20 ouverte dans l'écran du terminal 5. Selon un mode particulier de réalisation, le générateur de signets peut être inclus dans une page web de type HTML générée par le module HTML 12 du proxy 9 et affichée sur l'écran du terminal 5 par un navigateur web tel que Internet Explorer� ou Mozilla Firefox�. Ce tableau comprend plusieurs informations incluant l'adresse IP du terminal, le type de protocole employé, un identifiant associé au serveur d'applications et l'adresse ou URL du fichier source, telle que mémorisée par le gestionnaire 11 de session. Un bouton cliquable 21 est en outre incrusté dans le générateur de signets, pour permettre à l'utilisateur d'indexer la session, c'est-à-dire de créer un (ou plusieurs) signet(s) associé aux données média reçues et comprenant au moins deux pointeurs, à savoir : - un premier pointeur indiquant la provenance des données média, c'est-à-dire l'URL du fichier source, et - un second pointeur indiquant un instant prédéterminé au sein de la session média. Selon un mode de réalisation, cet instant prédéterminé correspond à un temps écoulé au sein de la session média, et plus précisément au temps écoulé entre le début de la session et la création du signet. Ce temps est par exemple mesuré par une horloge intégrée au proxy 9, ou bien reçue du serveur 14 d'applications en réponse à une requête d'obtention de paramètres (GET_PARAMETER suivant le protocole RTSP). À la création du signet, le navigateur web adresse au proxy une requête de type CGI (Common Gateway Interface) contenant le signet, lequel est alors mémorisé et associé par le module 13 de gestion des signets à la session correspondante au sein de la liste mémorisée par le gestionnaire 11 de session, afin de permettre une reprise ultérieure de la session à compter de l'instant précité, soit à partir du terminal 5 sur lequel le signet a été créé (par exemple un terminal fixe), soit à partir d'un autre terminal 5 (par exemple un terminal mobile). Une fois le signet créé par l'utilisateur (et mémorisé par le module 13 de gestion des signets), la session média peut être interrompue sur le terminal 5, par exemple sur commande de la fermeture du lecteur média. L'utilisateur peut accéder à la liste des sessions ainsi indexées (c'est-à-dire pour lesquelles des signets ont été créés) au moyen d'un panneau 22 d'affichage des signets mémorisés, qui se présente par exemple sous la forme d'un tableau incrusté dans la page web précitée (par exemple au-dessous du tableau 19 dressant la liste des sessions réalisées) et comprenant pour chaque signet, LURL du fichier source (l'affichage comprenant un hyperlien vers cet URL) et l'instant mémorisé. La liste des sessions indexées peut être rafraîchie automatiquement dans le navigateur web, sur commande du gestionnaire 13 des signets, au fur et à mesure de l'indexation des sessions par l'utilisateur. Le panneau 22 peut par ailleurs comprendre une fonctionnalité de suppression des signets, le tableau incluant par exemple, pour chaque signet, un bouton 23 cliquable sur activation duquel le signet est supprimé de la liste. L'URL de chaque session indexée inclut le pointeur temporel mémorisé sous forme d'une marque ou tag, détectable par le proxy 9. Lorsque l'utilisateur souhaite reprendre la session, par exemple depuis un autre terminal 5, il ouvre le navigateur web et, à partir de la liste des sessions indexées, lance une requête d'établissement de la session de son choix en cliquant sur LURL correspondante. Le navigateur lance le lecteur média, qui à son tour requiert l'établissement d'une session média. Cette requête transite par le serveur proxy 9, qui détecte dans l'URL demandée la présence du tag. Le proxy 9 intercepte alors la requête et génère une nouvelle requête à destination du serveur 14 d'applications, comprenant un champ d'instant initial (starttime) dont la valeur correspond au pointeur temporel. Le serveur 14 d'applications renvoie alors le flux média depuis I'URL requise, en débutant à l'instant requis, tel que mémorisé lors de 10 la création du signet. Comme nous l'avons vu, ce procédé est avantageux, par rapport aux procédés connus de fourniture de services média, en ce qu'il permet à un utilisateur de reprendre une session à compter d'un instant donné de son choix. En outre, il n'est pas nécessaire, dans la mesure 15 où les signets ne sont pas mémorisés localement mais au sein du serveur proxy 9 (et plus précisément par le module 13 de gestion des signets), de reprendre la session à partir d'un autre terminal 5. REVENDICATIONS 1. Procédé de fourniture à distance d'un service média à la demande depuis un serveur (14) d'applications média à un terminal (5) muni d'un lecteur média et relié au serveur (14) d'applications par l'intermédiaire d'un réseau (7) de télécommunications, ce procédé comprenant les opérations consistant à : - établir une session média entre le serveur (14) d'applications et le terminal (5), cette session comprenant la fourniture au terminal (5), par le serveur (14) d'applications, d'un flux de données média ; - restituer sur le terminal (5), au moyen du lecteur média, les données média reçues au sein du flux, caractérisé en ce qu'il comprend en outre les opérations consistant à : - créer un signet, associé aux données média et comprenant au 15 moins deux pointeurs, à savoir : - un premier pointeur indiquant la provenance des données média, - un second pointeur indiquant un instant prédéterminé au sein de la session média, 20 -mémoriser ledit signet. 2. Procédé selon la revendication 1, dans lequel l'instant prédéterminé correspond à un temps écoulé au sein de la session média. 3. Procédé selon la revendication 2, dans lequel l'instant 25 prédéterminé indiqué par le second pointeur correspond au temps écoulé entre le début de la session et la création du signet. 4. Procédé selon l'une des revendications 1 à 3, qui comprend les opérations consistant à : - émettre depuis un terminal (5) muni d'un lecteur média une requête 30 d'établissement d'une session média à destination du serveur (14) d'applications média, - activer un signet préalablement mémorisé, - établir une session média entre le serveur (14) d'applications média et le terminal (5), 35 - fournir au terminal (5) un flux de données médias depuis la provenance indiquée par le premier pointeur du signet activé, 9 - restituer sur le terminal (5) les données médias à compter de l'instant indiqué par le second pointeur du signet activé. 5. Procédé selon l'une des revendications 1 à 4, dans lequel le signet est mémorisé au sein d'un serveur (9) mandataire interposé entre le terminal (5) et le serveur (14) d'applications média, ce serveur mandataire (9) interceptant la requête d'établissement de session émise par le terminal (5) à destination du serveur (14) d'applications média. 6. Système (1) de communication comprenant : - un serveur (14) d'applications média, - un terminal (5) muni d'un lecteur média et relié au serveur (14) d'applications par l'intermédiaire d'un réseau (7) de télécommunications, - un serveur (9) mandataire interposé entre le serveur (14) d'applications média et le terminal (5), et configuré pour intercepter des requêtes d'établissement de session émise par le terminal (5) à destination du serveur (14) d'applications média et mémoriser au moins un signet associé à des données média fournies en flux par le serveur (14) d'applications média au terminal (5), ce signet comprenant au moins deux pointeurs, à savoir : - un premier pointeur indiquant la provenance des données média, - un second pointeur indiquant un instant prédéterminé au sein de la session média.30