La présente invention concerne la fourniture de services à la demande, comme par exemple de la vidéo à la demande, dans des établissements collectifs tels que par exemple des hôtels ou des hôpitaux. Ces établissements collectifs sont caractérisés par un nombre fini de récepteurs pouvant recevoir les services.

Les services de télédiffusion en chambre offerts par ces établissements sont essentiellement de deux types.

Les services de la première catégorie, les plus classiques, correspondent à la diffusion (« broadcast ») de programmes sur l'ensemble du parc de récepteurs ; c'est typiquement le cas de chaînes de télévision ou de radiodiffusion reçues par voie hertzienne, satellite ou câble, voire par un accès très haut débit (web-radios par exemple), et véhiculés via le réseau local du bâtiment jusqu'aux différents téléviseurs partageant ainsi la même infrastructure de réception. Tous les usagers reçoivent simultanément le même flux d'information. Les flux de données (audiovisuels ou autres) sont ici purement monodirectionnels puisque les utilisateurs consomment de façon passive ce qui leur est proposé. Chaque programme est diffusé une seule fois quelque soit le nombre de récepteurs ou d'utilisateurs simultanés ; les besoins en bande passante sur le réseau sont donc proportionnels au nombre de chaînes ou programmes. Dans le cadre d'un réseau à infrastructure de type coaxial standard, les chaînes de télévision sont reçues par une tête de station et rediffusés telles quelles sur le réseau local ou modulées sur des fréquences différentes et/ou dans un type de modulation différente. Ici, on entend par tête de station un système central de réseau permettant : la récupération de signaux de télécommunication (chaînes télévisuelles, internet, service de vidéo à la demande ou "VOD", etc.),

le traitement de ces signaux (modulation/démodulation, adaptation, multiplex, etc.), la diffusion adaptée des signaux traités auprès des terminaux du réseau.

Il peut être également avantageux de proposer dans les chambres un ou plusieurs services dédiés, comme par exemple une chaîne interne, diffusée depuis la tête de station. Les services de la seconde catégorie sont caractérisés par un mode interactif permettant de répondre aux demandes particulières de chaque utilisateur (ou récepteur). Un exemple typique est la Vidéo à la Demande (« VOD »), souvent mise en œuvre par diffusion payante à la demande de films parmi un catalogue remis à jour régulièrement par l'établissement. En mode interactif, les flux de données étant généralement bidirectionnels, un réseau de diffusion n'est plus suffisant et la mise en place d'une « voie de retour » est donc nécessaire. Les flux de données montant et descendant peuvent être véhiculés par le même réseau ou non. Les besoins en bande passante sur le réseau sont proportionnels au nombre d'utilisateurs simultanés. Comme traditionnellement les services interactifs viennent s'ajouter aux services de diffusion, leur déploiement nécessite un réseau capacitif (en débit).

Les services de diffusion sont historiquement bâtis sur des réseaux coaxiaux transmettant l'ensemble des services reçus par un système antennaire à tous les récepteurs. Une telle architecture peut servir un nombre illimité de récepteurs, le nombre maximum de services de diffusion est quant à lui borné par la bande passante disponible sur le réseau (classiquement 850 MHz) et celle utilisée par chaque service. Le passage du monde analogique au numérique a permis de multiplier par au moins un facteur 4 le nombre de services pouvant être offert en regroupant plusieurs services dans un multiplex occupant une seule bande de fréquences.

De longue date des services interactifs sont déployés sur ce type d'infrastructure coaxiale. L'interactivité et la voie de retour sont gérées grâce à un boîtier inséré entre le réseau coaxial et le récepteur. Classiquement le récepteur est un téléviseur et le boîtier est appelé « set-top box » (ou STB) et une partie de la bande passante du réseau coaxial est dédiée à la voie de retour. La grande majorité des déploiements réalisés dans les mondes de l'hôtellerie et de la santé se fondent sur des technologies propriétaires aussi bien pour la gestion de l'interactivité que pour l'allocation des ressources. Des fournisseurs d'accès aux services via le câble (ou « câblo-opérateurs ») ont contribué à l'établissement d'un standard avec les normes DOCSIS (pour « Data Over Cable Service Interface Spécification ») et l'« Edge QAM » régissant le transport de flux de données au protocole IP (« Internet Protocol ») sur réseau coaxial, ainsi que l'allocation dynamique des ressources de bande passante. Les boîtiers STB compatibles avec ces technologies sont cependant onéreux pour le monde des collectivités et ont un dimensionnement physique pensé pour le domicile des particuliers et non pour des chambres d'hôtel ou d'hôpital.

Pour palier aux limitations du monde coaxial, des solutions fondées sur les protocoles IP ont été développées pour fournir des services télévisuels numériques, de diffusion et interactifs, sur des infrastructures structurées (type Ethernet, sur paires torsadées, sur fibre optique, etc.), bidirectionnelles par nature, relaxant ainsi les contraintes de bande passante. De telles architectures sont très performantes mais également très onéreuses. Si elles répondent parfaitement au besoin des établissements de luxe, elles ne sont pas abordables pour tous les acteurs de l'hôtellerie. Elles nécessitent également des travaux lourds, pas toujours envisageables et dont les coûts peuvent être rédhibitoires. Les acteurs du monde de l'audiovisuel cherchent à optimiser l'utilisation des nouvelles technologies pour bâtir et normaliser de nouveaux services pour le grand public. À ce titre, la norme européenne émergente HbbTV (pour « Hybrid broadcast broadband Tele Vision ») propose d'utiliser simultanément le « broadcast » (ou diffusion) et le « broadband » (accès Internet haut débit) pour offrir respectivement des services de diffusion, comme les chaînes de télévision classiques, et des services à la demande comme la VOD et la télévision de rattrapage en différé (ou « catch up TV ») ainsi que des pages de contenu hypertexte, basés sur les technologies Web.

Dans un environnement hybride, le poste de télévision diffuse les services de télévision linéaires « broadcast » reçus par un syntoniseur hautes fréquences (en télévision numérique ou analogique), mais peut également afficher un flux audio ou vidéo en provenance d'un réseau « broadband », utilisant des normes de diffusion en flux (ou « streaming »). Parmi les normes de « streaming » reposant sur une diffusion broadband, on peut citer par exemple les protocoles normalisés RTP (pour « Real-time Transport Protocol ») ou encore RTSP (pour « Real Time Streaming Protocol »). Un tel flux est en général piloté par une application interactive, qui peut être signalée lors de la diffusion du service « broadcast », comme c'est le cas avec la norme HbbTV.

Ces services sont utilisables sur des téléviseurs dit « connectés » embarquant notamment un navigateur Web et un port physique Ethernet. Une des briques essentielles de ces nouvelles solutions est l'utilisation de débit adaptatif rendu possible par des têtes de station évoluées. Le principe du débit adaptatif est d'adapter le débit du flux de diffusion aux possibilités de bande passante entre le serveur et le « client » (terme adopté dans la suite pour désigner le poste de télévision connecté ou le terminal STB auquel il est relié). On peut citer par exemple la norme MPEG DASH (« Moving Picture Experts Group / Dynamic Adaptative Streaming over HTTP ») qui repose sur la diffusion d'un fichier dit « manifeste » contenant des informations sur les différents débits disponibles pour la diffusion, et sur le format de transport MPEG TS (TS pour « Transport Stream »).

Ces nouveaux matériels sont cependant extrêmement onéreux notamment car conçus pour servir un grand nombre d'utilisateurs. Ils ne sont donc pas financièrement abordables par un établissement collectif. L'idée d'une tête de station partagée n'est également pas envisageable par la plupart des établissements car cela requiert un débit Internet important pour de tels établissements dont les coûts sont prohibitifs pour une majorité des acteurs dans l'hôtellerie ou le domaine hospitalier par exemple.

L'utilisation de téléviseurs connectés en chambre pour la diffusion des services de télédiffusion peut entraîner des problèmes de qualité de service. En effet, de plus en plus de programmes de télédiffusion utilisent les nouvelles techniques de diffusion hybrides pour proposer des applications interactives offrant des services liés à ces programmes. Comme indiqué plus haut, en plus de l'accès à des informations interactives textuelles (informations sur les programmes, informations de météo, nouvelles) ces applications incluent la diffusion de vidéos, par exemple la télévision de rattrapage en différé (ou « catch-up TV »), la vidéo à la demande, etc.

Une norme telle que HbbTV permet aussi la diffusion de contenus multimédias directement dans le flux de transmission sous la forme de carrousels de données qui transportent alors les fichiers qui composent application interactive.

Dans un établissement collectif disposant d'un accès internet et de télévisions connectées, les utilisateurs peuvent ainsi faire appel à ces services connectés et notamment aux services de diffusion à la demande. Or, même si l'établissement dispose d'un accès à internet à très haut débit, le débit nécessaire pour diffuser simultanément, dans plusieurs chambres, plusieurs sessions de services de diffusion à la demande peut provoquer un engorgement du réseau informatique local, et entraîner une baisse notable de la qualité du service d'accès à un intranet ou à l'internet.

La présente invention vient améliorer la situation. Elle propose à cet effet un procédé mis en œuvre par une entité informatique pour fournir au moins des services à la demande, différenciés, à une pluralité de terminaux respectifs, avec des moyens de communication en mode de diffusion desdits services.

Ici, les services à la demande peuvent être de type :

« vidéo à la demande » (ou VOD), ou encore service informatif, par exemple une page d'accueil d'un portail en ligne d'un établissement collectif, ou une page d'information par exemple de catalogue de services (météo, numéro de chambre, note de minibar, etc., ou autres), ou encore simplement un service de fourniture de données de télévision, - ou autres.

Les terminaux peuvent être : des postes de télévision connectés, de simples téléviseurs reliés à un modem ou un terminal de type Set-Top-Box, ou encore des terminaux de type Set-Top-Box eux-mêmes, - ou encore des ordinateurs (fixes ou portables) comportant des moyens de connexion à un réseau local et des moyens de lecture d' au moins un flux commun décrit plus loin, etc.

La communication en « mode de diffusion » précitée concerne notamment une communication de type « broadcast ».

L'entité informatique précitée peut générer en particulier un flux indifférencié, commun aux terminaux, ce flux commun comportant au moins des tables de signalisation desdits services à la demande, chaque table de signalisation étant dédiée à un terminal et chaque terminal étant configuré pour lire la table de signalisation du service à la demande qui lui est dédiée et ignorer les autres tables de signalisation.

L'entité informatique reçoit, d'une partie au moins des terminaux, des requêtes de services à la demande, par voie de retour entre les terminaux et l'entité informatique. L'entité informatique étant connectée à une source de données de services à la demande, il est ainsi possible de conditionner la délivrance desdites données dans le flux commun en fonction desdites requêtes.

On comprendra ainsi qu'on entend par « voie de retour » la possibilité d'une communication bidirectionnelle entre chaque terminal et l'entité informatique précitée. Dans une réalisation, les requêtes sont formulées par exécution d'une application auprès d'un terminal. Par exemple, les tables de signalisation précitées peuvent pointer vers au moins une table de déclaration d'application interactive comportant au moins des données de lien vers un script de cette application. En variante, un terminal peut comporter un moyen de stockage d'un script préenregistré lié à cette application, lequel script préenregistré comporte au moins des données de lien vers un script de cette application. Par exemple, avec la technologie « Philips Net TV », un terminal tel qu'un poste de télévision peut ne stocker qu'un lien unique, de type URL (« Uniform Resource Locator » ou « Universal Resource Locator ») pointant vers la page d' accueil de cette application.

Côté entité informatique, chaque requête reçue comporte préférentiellement un identifiant de terminal ayant généré la requête, et l'entité informatique peut statuer alors sur cette requête par exemple en fonction de droits d'accès associés à ce terminal, en conditionnant la délivrance dans le flux commun de données sollicitées dans la requête.

Avantageusement, on peut prévoir une application interactive pour afficher sur un écran du terminal des informations sur un ou plusieurs services à la demande disponibles, et pour contrôler parallèlement une diffusion des données de service à la demande dans le flux commun par communication avec l'entité informatique.

Dans une réalisation avantageuse, le flux commun est généré conformément au standard DVB, et lesdites tables de signalisation précitées peuvent être des tables de correspondance des programmes (ou « PMT » pour « Program Map Table »). Plus particulièrement, le flux peut être au standard DVB selon la norme particulière HbbTV, notamment pour la transmission dans le flux commun de tables d'application interactive correspondant à des tables dites « d'information d'application » (ou « AIT » pour « Application Information Table »). L'application interactive peut suivre la norme CEA-2014 et notamment CE- HTML (« Consumer Electronics HTML ») et les normes dérivées (OIPF, HbbTV, etc.).

Dans une réalisation particulière, l'entité informatique et les terminaux peuvent communiquer via un réseau à infrastructure coaxiale, par transmission de données par des modems de type « DOCSIS ». On comprendra alors qu'avec un tel type d'infrastructure (réputée à faible bande passante), il convient de limiter les données non utiles susceptibles de surcharger l'infrastructure précitée. On indique ici que DOCSIS est une norme spécifique qui définit les conditions d'interface de communications et de soutien d'opération pour un système de données utilisant le système de télévision par câble. Il permet l' addition du transfert de données à vitesse élevé à un système existant de télévision par câble. Il est notamment utilisé pour fournir l' accès à Internet sur des infrastructures coaxiales.

Dans une forme de réalisation, on peut filtrer des requêtes provenant des terminaux, afin d'interdire un accès à des services distants (par exemple par la mise en place d'un pare -feu).

Dans une réalisation en particulier, l'entité informatique peut être agencée pour filtrer des applications dans des flux élémentaires, en amont du flux commun, selon au moins les étapes :

réception des flux élémentaires ;

lecture d'un contenu de tables de signalisation dans les flux élémentaires et de tables de déclaration d'application interactive associées à au moins un service à la demande de flux élémentaires correspondant ; et

suppression des tables de déclaration d'application interactive.

Dans une variante de cette réalisation, au lieu de supprimer les tables de déclaration d'application interactive précitées, il est possible de mettre en œuvre les étapes :

- modification des tables de signalisation par suppression d'entrées correspondant à des pointeurs vers lesdites tables de déclaration d' application interactive, remplacement des tables de signalisation par les tables modifiées dans le flux commun. Dans une autre forme de réalisation, l'entité informatique peut être agencée pour filtrer des applications dans des flux élémentaires, en amont du flux commun, selon au moins les étapes :

réception des flux élémentaires ;

lecture d'un contenu de tables de signalisation dans les flux élémentaires et de tables de déclaration d'application interactive associées à au moins un service à la demande de flux élémentaires correspondant ;

réécriture des tables de déclaration d'application interactive après suppression d'entrées correspondant à une définition de protocole de communication entre les terminaux et l'entité informatique.

L'entité informatique peut être agencée en outre pour modifier les tables de signalisation en ajoutant une entrée correspondant à une nouvelle table de déclaration d'application interactive et pour modifier des identifiants de flux d'origine, de sorte que toute application associée à un flux élémentaire est considérée par un terminal comme une seule et même application.

On comprendra que ces techniques de « filtrage » sur voie de retour sont avantageuses dans l'absolu, indépendamment de la nature du service à la demande (VOD, ou simple requête de données TV, ou requête de contenu informatif (numéro de chambre dans une page d'accueil, par exemple), ou autres).

Ainsi, la présente invention propose d'utiliser le réseau de diffusion (« broadcast ») en particulier pour diffuser des services à la demande. Elle propose notamment d'associer une application interactive au contenu de diffusion à la demande. Cette application interactive peut être chargée par exemple d'informer l'utilisateur sur le contenu visionné, et de contrôler la diffusion du flux en communicant avec le serveur (par le protocole HTTP par exemple). Cette application n'a pas besoin d'un débit de données important, et permet l'utilisation sur un réseau à infrastructure coaxiale, par exemple en faisant transmettre les données par de simples modems DOCSIS.

La présente invention vise aussi l'entité informatique en tant que telle (portant la référence S dans les figures commentées ci-après) pour la fourniture de services à la demande, différenciés, à une pluralité de terminaux respectifs, et reliée à des moyens de communication en mode de diffusion desdits services, l'entité comportant :

- des moyens générant un flux indifférencié, commun aux terminaux, le flux comportant au moins des tables de signalisation desdits services à la demande, chaque table de signalisation étant dédiée à un terminal,

- des moyens de réception, d'une partie au moins des terminaux, des requêtes de services à la demande, par voie de retour entre les terminaux et l'entité informatique,

- une connexion à une source de données de services à la demande pour conditionner la délivrance desdites données dans le flux en fonction desdites requêtes.

L'invention vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur. A ce titre, la figure 5 par exemple, commentée ci-après, peut représenter un organigramme de l'algorithme général d'un tel programme informatique, à titre d'exemple.

D'autres avantages et caractéristiques de l'invention apparaîtront ci-après à la lecture de la description donnée à titre d'exemples de réalisation non limitatifs, et à l'examen des dessins sur lesquels :

- la figure 1 illustre un exemple de réalisation pour la diffusion des flux, sans préciser ici la voie de retour et la diffusion d'applications connectées vers les terminaux (des postes de télévision dans l'exemple représenté),

- la figure 2 illustre l'exemple de réalisation de la figure 1 avec une voie de retour utilisant la norme DOCSIS (sur un même réseau coaxial que celui illustré sur la figure 1) ;

- la figure 3 est un schéma fonctionnel de mise en œuvre de l'exemple de réalisation représenté sur la figure 2 ;

- la figure 4 illustre un exemple d'agencement de tables de déclaration dans le flux que délivre l'entité informatique S de la figure 3 ; et

- la figure 5 illustre schématiquement les principales étapes du procédé mis en œuvre par l'entité informatique S selon un exemple de réalisation générale.

Un établissement hôtelier (ou équivalent) dispose d'un réseau de télévision numérique interne basé sur une infrastructure coaxiale, le service de télévision numérique étant diffusé depuis un serveur central du site (appelé aussi « tête de station »). Ce serveur distribue aux chambres des services de télévision reçus par des antennes ou diffusés depuis un serveur dédié (serveur de diffusion de flux de vidéo à la demande par exemple). Ces services de télévision peuvent signaler des applications interactives, comme on le verra plus loin en détails.

L'établissement est équipé d'une voie de retour, de la chambre vers le serveur central. Cette voie de retour peut reposer sur le même réseau coaxial (« IP » pour « Internet Protocol » sur câble coaxial, par exemple dans un système communiquant selon la norme DOCSIS, ou par courants porteurs en ligne), sur un réseau Wifi, un câblage en paire torsadée ou toute autre infrastructure.

L'établissement est équipé de terminaux consistant, dans l'exemple représenté en des téléviseurs connectés (directement ou via boîtiers STB) capables de recevoir des applications interactives signalées dans les flux de transmission. L'établissement est équipé d'un système de diffusion de contenus multimédias à la demande (par exemple de vidéo à la demande ou « VOD ») depuis le serveur central.

On cherche alors à filtrer les applications connectées, associées aux services de télédiffusion diffusés sur le réseau local, et à contrôler le programme de vidéo à la demande à l'aide d'une application connectée signalée dans les tables d'information associées au contenu numérique diffusé, plus particulièrement appliqué aux normes DVB (pour « Digital Video Broadcasting ») et HbbTV (pour « Hybrid broadcast broadband Tele Vision »). Selon une autre réalisation décrite plus loin, l'application connectée est une application globale préenregistrée dans un moyen de stockage de terminal. Dans ce cas, l'application est indépendante du flux (pas de signalisation a priori de l'application dans le flux).

On se réfère maintenant à la figure 1 sur laquelle est illustré un système en réseau pour la diffusion de flux. Ici, le système comporte une entité informatique S qui diffuse des flux auprès des terminaux TV1, TV2,..., TVN via un réseau câblé COAX (de type « coaxial » par exemple) et par lequel les terminaux sont raccordés à l'entité informatique S. L'entité informatique S est connectée à une unité de réception 12 récupérant des flux de données relatives à des services télévisuels. Ces flux peuvent provenir à titre d'exemple : d'une antenne terrestre A-T, dans le cadre d'une réception du flux de télévision (TV) par voie hertzienne,

- d'une antenne satellite A-S, dans le cadre d'une réception du flux de télévision (TV) par transmission satellite, et/ou

d'une antenne satellite A-C, dans le cadre d'une réception du flux de télévision (TV) par transmission par câble.

L'unité de réception 12 communique les flux TV reçus à un multiplexeur 13 de l'entité informatique S. Le multiplexeur 13 reçoit aussi un flux comportant des données (notamment vidéo-audio) de services à la demande en provenance par exemple d'un serveur de vidéos à la demande S_VOD. Le multiplexeur 13 est raccordé à une source de contenus multimédias 10 (diffusant des données multimédias de présentation de services, par exemple un film vidéo de présentation de l'hôtel, des bandes annonces des services à la demande, etc.). Le multiplexeur 13 est raccordé en outre à un générateur de tables de signalisation 11. De manière non limitative, on a représenté la source de contenus 10 et le générateur de tables 11 au sein de l'entité informatique S. Le générateur 11 permet de : modifier les tables de signalisation relatives au flux reçu par le multiplexeur 13 (qui est en provenance de l'entité de réception 12), et ajouter des tables de signalisation relatives à des services à la demande émis par le serveur S_VOD et/ou à des contenus multimédias venant de la source de contenus 10.

De la sorte, le multiplexeur 13 génère au moins un flux de données de services qu'il communique à un ou plusieurs modulateur(s) 14 qui diffuse(nt) ce flux (selon différentes fréquences par exemple) sur le réseau COAX à destination des terminaux TV1, TV2, TVN. On comprendra alors que ce flux correspond au « flux commun » précité, indifférencié, pour tous les terminaux TV1, TV2, TVN. Le modulateur 14 injecte les flux sur le réseau COAX par l'intermédiaire d'un coupleur d'antenne 15. Ici, on a représenté un serveur web 105 au sein de l'entité informatique S. Ce serveur web 105 comporte des contenus d'application interactive. Ces contenus sont délivrés par le serveur 105 sur requête des terminaux TV1, TV2, TVN (par exemple en tant que « serveur HTTP »). Comme décrit plus loin, les contenus sont transmis soit par une voie retour (par laquelle sont véhiculées les requêtes) soit par des carrousels de données du flux diffusé aux terminaux. Le serveur web 105 peut également interpréter des requêtes de contrôle de services à la demande en provenance des terminaux transmis par la voie de retour et, comme décrit plus loin, générer des consignes de délivrance de ces services auprès du serveur S_VOD.

L'entité informatique S peut être raccordée en outre à un réseau étendu RE de type « internet » pour communiquer avec des serveurs distants (non représentés sur la figure) par exemple pour d'autres services.

En outre, l'entité informatique S peut être connectée à un système de gestion de profils PMS (pour « Property Management System ») afin d'obtenir des informations particulières comme par exemple, dans le cadre d'un hôtel, le nom des clients occupant les chambres de l'établissement, les numéros de chambre, éventuellement des droits d'accès à certains services, etc.

On se réfère maintenant à la figure 2 pour décrire un système de même nature précisant la mise en œuvre d'une voie de retour. La voie de retour est assurée ici par une transmission via le réseau COAX en utilisant la norme DOCSIS. Les terminaux TV1, TV2, TVN sont connectés à des répartiteurs 23 permettant : d'une part, aux terminaux de recevoir les flux diffusés par le ou les modulateur(s) 14, et d'autre part, à des modems DOCSIS 21 de transmettre les données à destination des terminaux par une liaison 22 reliant le modem au terminal, et à transmettre les données émises par ce terminal via le réseau COAX. Un modem DOCSIS 21 permet notamment les échanges de données entre les terminaux et l'entité S, et plus particulièrement les requêtes HTTP en provenance des terminaux, et leurs réponses en provenance de l'entité S.

Pour ce faire, les données sont émises par les téléviseurs TV1, TV2, TVN aux modems DOCSIS 21 via la liaison 22 (câble Cat 5 et connecteurs RJ45 par exemple). Ainsi, les modems 21 modulent les données qui composent les requêtes des téléviseurs selon la norme DOCSIS et les envoient à l'entité informatique S. Le coupleur d'antenne 15 permet l'injection de plusieurs signaux sur le réseau COAX. Il reçoit en particulier les flux en provenance du ou des modulateur(s) 14 et d'un serveur CMTS. Le serveur CMTS (pour « Cable Modem Termination System »), conforme à la norme DOCSIS, est placé en interface entre le coupleur d'antenne 15 et l'entité informatique S afin de moduler et démoduler les données en provenance et/ou à destination des modems DOCSIS 21.

En référence à la figure 3, des antennes de réception A-T, A-S et A-C reçoivent des flux de télédiffusion et accessoirement des flux de diffusion provenant d'Internet (par exemple des web-radios). Par ailleurs, des fichiers vidéo 10 sont stockés en mémoire, par exemple pour diffuser une ou plusieurs chaînes supplémentaires (ou « chaîne interne ») sur le réseau local. La référence 12 désigne la réception des flux, avec démodulation et émission sous la forme de paquets TS (pour « Transport Stream ») encapsulés dans des paquets UDP (pour « User Data Protocol ») multicast ou unicast, formant un flux SPTS (Single Program Transport Stream : un seul service par flux UDP). La référence 11 désigne un module de génération de tables de signalisation MPEG2 PSI (« Program Spécifie information ») et DVB SI (« Service Information ») de type :

- PAT (pour « Program Association Table ») correspondant à une table d'association de programme qui liste les services avec un référencement des tables de correspondance de programme et fournit par ailleurs l'identifiant PID (pour « Packet Identifier ») des paquets relatifs à une table NIT (« Network Information Table ») comprenant des informations de réseau,

- PMT (pour « Program Map Table ») correspondant à une table de correspondance de programmes qui liste les composantes d'un service par l'identification des PID des paquets relatifs, - NIT (pour « Network Information Table ») correspondant à une table d'information de réseau qui comprend des informations à propos du réseau physique, et

- AIT (pour « Application Information Table ») correspondant à une table d'information d'application qui décrit un élément de service de type applicatif, tel qu'une application interactive,

- SDT (pour « Service Description Table ») correspondant à une table d'information de services.

Ces tables peuvent être préexistantes dans un premier flux que reçoit l'entité informatique S et cette entité génère à partir de ce premier flux un deuxième flux dont les tables PAT sont réécrites en fonction de la liste des services à diffuser dans chaque multiplex DVB en sortie. Les tables PMT d'origine peuvent être réécrites pour supprimer ou ajouter des informations sur des flux élémentaires (telles des informations sur les tables AIT). Les tables AIT d'origine peuvent être supprimées, modifiées, par exemple pour supprimer les informations concernant le protocole HTTP, ou remplacées. La table NIT peut être modifiée pour modifier les informations du réseau d'origine par exemple. La table SDT peut être modifiée pour prendre en compte les informations sur les services indifférenciés additionnels, ou supprimée pour empêcher la mise à jour automatique des postes de télévision.

Le serveur web 105 d'applications connectées génère le contenu des applications interactives. Il s'agit d'un serveur de type 'serveur Web' traitant les requêtes URL par le protocole HTTP. Il peut également diffuser des contenus multimédias, tels des vidéos promotionnelles, à diffuser dans des pages de l'application interactive (via HTTP également, ou via RTP / RTSP).

On peut prévoir en outre un système PMS de gestion clients PMS (pour « Property management System ») de l'hôtel ou plus généralement de l'établissement collectif.

Un serveur S_VOD de médias audiovisuels à la demande contient une base de données de contenus audiovisuels (tels que des films) et fournit les flux élémentaires des contenus audiovisuels à diffuser, avec : des tables de signalisation nécessaires au générateur de tables 11 pour pouvoir générer les tables PMT contenant les informations conformes au flux diffusé, et les flux élémentaires (vidéo, audio dans la langue sélectionnée par le client, etc.) au multiplexeur pour une diffusion sur le réseau. Le multiplexeur 13 reçoit alors plusieurs flux élémentaires et des tables d'information sous forme de paquets TS devant être multiplexés au sein d'un seul flux (multiplex). Le multiplexeur peut également filtrer des paquets par leur identifiant PID. En général, on peut prévoir plusieurs multiplex en sortie, sous forme de flux IP (TSoIP ou « Transport Stream over IP ») qui seront chacun modulés sur une fréquence différente par le ou les modulateurs 14 (généralement selon les normes DVB-C ou DVB-T).

Enfin, la référence COAX désigne le réseau câblé sur lequel transite les flux DVB jusqu'aux postes de télévision connectés et la référence 111 désigne un réseau au protocole IP, par exemple : - un réseau de type LAN/Ethernet sur paires torsadées ou similaire ;

- un réseau sans-fil de type Wifi ;

- le réseau coaxial précité sur lequel les données sont modulées selon la format normalisé DOCSIS ou une technique équivalente, le câble coaxial étant alors réparti en deux branches à l'arrivée en chambre, pour le connecteur antenne du poste de télévision et pour le connecteur antenne d'un modem, le connecteur

LAN (« Local Area Network ») du poste de télévision étant branché sur le modem (dans ce cas, on peut prévoir un appareil de type CMTS placé en tête de réseau pour jouer le rôle de pont entre les données modulées selon le format DOCSIS et le réseau LAN des serveurs) comme représenté à titre d'exemple sur la figure 2 ;

- un réseau de type CPL (courant porteur en ligne), technologie similaire à celle d'un réseau coaxial ;

- ou autre.

On indique qu'un pare-feu peut être utile en outre pour interdire par exemple toute communication extérieure avec les postes de télévision afin d'éviter une saturation du réseau 111.

Dans une réalisation, les différents modules 10, 11 , 105, et 13 peuvent être regroupés auprès de la même entité informatique S.

Ainsi, un serveur localisé en tête de station de l'établissement S_VOD diffuse un ensemble de médias audiovisuels à la demande sur le réseau local COAX. Ici par exemple, chaque téléviseur est identifié par le serveur web 105 au moyen de son adresse IP (adresse fixe affectée par un serveur DHCP (pour « Dynamic Host Configuration Protocol ») à partir de son adresse MAC, et est relié au réseau informatique 111.

Si un utilisateur sélectionne avec sa télécommande un portail interactif diffusé sur une des chaînes disponibles en chambre, ce portail peut par exemple être diffusé via la norme HbbTV, avec en particulier des tables de signalisation générées par le module 11 et le contenu de l'application peut être délivré par le serveur web 105. Des informations lui sont données à l'écran par le biais de l'application interactive sur la liste des contenus disponibles en VOD ainsi que leur tarif par exemple.

L'utilisateur sélectionne un contenu (un film unique ou une offre forfaitaire sur une durée donnée) et entre un code sur sa télécommande pour valider son achat. La session est alors ouverte et des informations sont affichées à l'écran pour indiquer au client comment visionner un film, comme par exemple changer de chaîne (« taper 0 »). Il convient de noter que le renvoi vers une autre chaîne peut être automatique. La session est fermée au bout d'un temps donné, par exemple le lendemain à midi ou lors du départ de l'utilisateur de l'établissement collectif (check-out dans un hôtel par exemple).

Le serveur de VOD S_VOD diffuse le contenu via des multiplex DVB sur un nombre C de canaux. Chaque multiplex peut diffuser au maximum M sessions simultanées parmi les N services signalés dans le flux. Le nombre M est défini par le débit disponible dans le multiplex, et dépend de la technique de diffusion (modulation, largeur de bande, etc.). Par exemple : pour une diffusion en DVB-C, QAM-128, le débit d'un multiplex est d'environ 44 Mpbs,

si chaque vidéo est encodée à 8 Mbps, on peut diffuser M = E(44/8) = 5 contenus simultanés dans un multiplex,

- avec 8 canaux disponibles (= 8 fréquences), on peut donc diffuser au total sur l'établissement M x C = 5 x 8 = 40 contenus simultanés.

Les téléviseurs sont, quant à eux, préréglés pour recevoir un seul des N services potentiellement diffusés dans le multiplex. Ils sont ensuite bloqués pour ne pas pouvoir recevoir les services diffusés dans le multiplex et qui ne leur sont pas destinés. Le plan de chaînes de chaque téléviseur réserve en particulier C chaînes à la VOD. La diffusion est effectuée sur l'une de ces chaînes selon un principe d'emplacement libre. Le plan de chaînes de chaque téléviseur comprend ainsi : les chaînes de télévision standard, et

les chaînes additionnelles :

o la chaîne portail de l'établissement collectif (qui diffuse une application connectée de type portail),

o les C chaînes dédiées à la VOD.

Pour régler le téléviseur, il est possible de générer un fichier de réglage sur une clé mémoire USB et utiliser une fonction dite « de clonage » des téléviseurs. Afin de reproduire dans le fichier de réglage la liste des chaînes de télévision standard, il est possible de : diffuser dans la chaîne portail une application spécifique de réglage (HbbTV ou équivalente) qui détecte le plan de chaînes (par exemple en faisant appel à des classes JavaScript de contrôle du plan de chaînes) ;

allumer un téléviseur du réseau coaxial et lancer une procédure de réglage automatique ;

sélectionner la chaîne portail et lancer l'application de réglage.

Dans une réalisation particulière, cette application

o détecte la liste des chaînes (nom et caractéristiques telles que

« original_network_id, transport_stream_id, service_id ») o et envoie ces informations au serveur.

Le serveur enregistre ces informations. Plus particulièrement, un utilitaire permet de générer le plan de chaîne complet de chaque téléviseur à partir de ces informations, sous forme d'un ou plusieurs fichiers de clonage. Pour chaque téléviseur, on peut alors copier le ou les fichiers sur une clé mémoire USB et l'utiliser pour le réglage des chaînes comme indiqué précédemment. Si l'application connectée dispose d'une interface API (pour « Application Programming Interface ») permettant de modifier le plan de chaînes, il est aussi possible de régler les chaînes additionnelles sur le téléviseur directement à partir d'une application de réglage.

Ainsi, lors de l'ouverture d'une session, un module de gestion de session VOD de l'entité informatique S (non représenté sur les figures) : - peut identifier le poste de télévision cible par son adresse IP (liée à son adresse

MAC par la base de donnée du serveur DHCP) ; en effet, lors de la négociation à l'initialisation de la connexion réseau, le serveur DHCP fournit une adresse IP aux postes de télévision connectés en fonction de leur adresse MAC ;

sélectionne l'un des M x C emplacements libres ; informe le serveur web 105 d'application du portail du numéro de chaîne sur laquelle la vidéo est disponible (typiquement l'un des C canaux réservés), informe le serveur VOD S_VOD de commencer à diffuser un service sur le multiplex choisi, en utilisant comme numéro de service (SID ou « service_id » pour « Service IDentifier ») le numéro préalablement réservé au poste de télévision, et indique éventuellement au module 11 de signaler l'application interactive permettant de contrôler la session de diffusion à la demande, ou

alternativement, cette application peut être activée directement par le poste de télévision (notamment lorsque l'application est préenregistrée dans le poste), soit lors d'un changement de chaîne, soit au démarrage.

Si les M x C emplacements sont occupés, la session ne peut être ouverte et un message est affiché à destination de l'utilisateur.

Sinon, une fois la session ouverte, l'application interactive peut intercepter les événements tels que l'appui sur un bouton de la télécommande. En réponse, l'application affiche une interface utilisateur à l'écran en superposition du contenu multimédia et/ou envoie des requêtes HTTP au serveur web 105. Ces requêtes peuvent consister par exemple à naviguer dans le contenu en cours avec notamment le lancement d'une action de : lecture,

mise en pause,

- déplacement dans le contenu à une position donnée (début, fin, position actuelle plus ou moins 30 secondes, etc.),

demande de la position actuelle et de la durée totale (afin d'informer l'utilisateur), ou autres.

Avantageusement, une application connectée, par exemple une application HbbTV, est signalée au téléviseur dans les tables d'information diffusant le contenu VOD. Cette application est signalée en mode « AUTOSTART » pour démarrer automatiquement lorsque la chaîne sur laquelle est diffusé le contenu VOD est sélectionnée. L'interface utilisateur est affichée lorsqu'une action est demandée, et cachée dans le cas contraire pour ne pas occuper une partie de l'image du programme de VOD. Alternativement, cette application connectée, par exemple une application suivant la norme CE-HTML (« Consumer Electronics HTML »), peut être déclarée lors du réglage du téléviseur, par exemple sous la forme d'une URL, et activée automatiquement par le téléviseur sur un événement tel que la mise sous tension ou la sélection d'une chaîne. Cette application peut effectuer par exemple les actions ci-après.

Si l'utilisateur n'a pas démarré la vision ou si le programme est en pause, il peut être proposé une présentation du contenu, avec :

o le titre du film, son affiche, une description succincte ;

o une information sur la position actuelle dans le programme (si en pause) ; o un rappel du mode d'emploi d'utilisation de la télécommande ; o une information sur la durée de session VOD.

L'application peut également proposer d'autres contenus existants, par exemple la liste des films faisant partie de l'offre commerciale souscrite par l'utilisateur.

L'application peut intercepter les événements tels que l'appui sur certaines touches de la télécommande, comme par exemple :

o la réception d'un ordre issu d'une touche PLAY, PAUSE, «, », ou autre, et l'envoi des ordres correspondants à l'entité S,

o la réception d'un ordre issu d'une touche « bouton rouge » par exemple, pour faire apparaître une barre de navigation,

o ou autres.

L'application peut en outre proposer une vérification des droits en interrogeant l'entité informatique S via des requêtes HTTP. En cas de réponse négative de l'entité informatique S, par exemple si l'utilisateur ne dispose pas des droits pour recevoir la chaîne sélectionnée (pas de session ouverte par exemple), l'application peut décider d'actions telles que :

o prévenir l'entité informatique S (procédure d' anti-piratage),

o sélectionner une autre chaîne du plan de chaînes du téléviseur, telle que la chaîne portail de l'établissement, ceci afin d'empêcher l'utilisateur de continuer de voir un contenu payant pour lequel il n' a pas été facturé.

On se réfère maintenant à la figure 4 pour décrire en particulier la génération des diverses tables de déclaration par l'entité S. La table PAT 201 déclare N services pour les N postes de télévision (TV1, TV2, TVN) du réseau local. Chaque poste de télévision TVj (j de 1 à N) est réglé pour ne recevoir que le service j et pour ignorer les autres services.

Dans l'exemple représenté, les tables PMT 202 et 203 sont respectivement à destination des téléviseurs TV1 et TV2. Ces tables pointent respectivement les flux élémentaires 204 et 205 (non limités à des contenus vidéo et audio) qui sont diffusés par le serveur de média audiovisuel à la demande S_VOD. Si aucune session de service de média audiovisuel à la demande n'est ouverte pour un poste de télévision particulier, les flux élémentaires correspondant ne sont pas diffusés et aucun média audiovisuel n'est affiché sur ce poste de télévision. À tout moment, on ne peut prévoir au plus que M sessions ouvertes pour un flux de transmission donné, soit au plus M tables PMT pointant des flux élémentaires présents dans le flux. En particulier, les autres tables PMT pointent des flux élémentaires absents du flux de transmission.

Toutes les tables PMT pointent également une application interactive signalée via une table AIT 207. Ici, cette table AIT déclare une application interactive hébergée par le serveur web 105 à l'adresse IP du réseau local (par exemple 192.168.10.1, de sorte que le point d'entrée de l'application est ici défini par l'URL : « http://192.168.10.1/index.html »).

On notera qu'il peut être judicieux de diffuser une partie des fichiers qui composent l'application interactive sous forme de carrousels de données afin d'éviter d'utiliser la bande passante limitée du réseau de données. Il suffit alors d'ajouter dans les tables PMT un descripteur de carrousel de données et d'associer à la table AIT un descripteur d'extension de domaine d'application par exemple pour donner à l'application l'autorisation d'accéder à ces données.

Le serveur web 105 étant connecté à un gestionnaire de sessions et au serveur de média audiovisuel à la demande S_VOD, il est bien entendu capable de générer des contenus différents selon qu'une session est ouverte ou non.

Par exemple, si aucune session n'est ouverte sur le poste TV1, ce dernier ne reçoit aucun média audiovisuel 204 en provenance du câble antenne (ce qui résulte simplement en un écran noir). L'application interactive est de préférence toujours signalée par la table PMT 202, et le poste de télévision TV1 peut ainsi afficher un message d'invite et/ou une page promotionnelle par-dessus cet écran noir.

Ensuite, si par exemple une session est ouverte sur le poste TV1, ce dernier reçoit le média audiovisuel 204 en provenance du serveur S_VOD. L'application interactive peut alors répondre à l'appui d'une touche de la télécommande en affichant par exemple une interface utilisateur de contrôle de la session indiquant la position courante dans le programme audiovisuel et permettant de mettre en pause, de reculer et/ou d'avancer le contenu multimédia de ce programme.

Afin d'éviter l'apparition d'un écran noir, et afin de contrôler les droits d'accès aux services à la demande, une routine de l'application interactive est exécutée périodiquement sur le poste de télévision (poste de l'utilisateur) pour vérifier l'état de la session à la demande auprès de l'entité informatique S via des requêtes de vérification. Par exemple, si la session a expiré, l'application peut afficher un message d'invite. Enfin, cette routine périodique joue avantageusement un rôle anti-piratage car elle peut permettre de vérifier, auprès du module de gestion de session VOD de l'entité informatique S, l'état de la session en fonction du numéro de service courant (SID), et pas seulement de l'adresse IP, afin d'empêcher un pirate de visualiser un service qui n'est pas destiné à ce poste de télévision.

Ci-après, on décrit le filtrage d'applications connectées, signalées par des services télévisuels en provenance notamment des antennes A-T, A-S et A-C et permettant en particulier de limiter la bande passante occupée par des services de telles applications (tels les services de télévision de rattrapage par exemple, ou encore de VOD, diffusés par internet).

On propose ici de filtrer les applications interactives signalées dans les chaînes de télédiffusion en provenance des sources A-T, A-C ou A-S, et diffusées sur le réseau local :

- en filtrant au niveau du réseau 111 précitée les liens URL provenant des postes de télévision pour interdire l'accès aux contenus VOD distants (par l'intermédiaire d'un pare-feu mis en œuvre par un routeur par exemple) ; - ou en supprimant la signalisation de l'application (par modification des tables PMT pour ne plus pointer sur les tables AIT ou simplement en supprimant les tables AIT) ;

- ou en supprimant la référence au protocole HTTP dans la table AIT : ainsi, si l'application est également diffusée par un carrousel de données, l'application reste disponible sous cette forme (le comportement étant alors le même que si le poste de télévision n'était simplement pas connecté au réseau internet). Toutefois, dans le cas où l'application, diffusée sous forme de carrousels de données, propose tout de même l'accès à des services à la demande distants, ou si cette application démarre une autre application interactive provenant du réseau internet, il est judicieux de continuer de filtrer les communications entre le réseau local (auquel sont connectés les postes de télévision) et le réseau extérieur (réseau internet) pour limiter la bande passante occupée ; - ou en remplaçant l'application interactive d'origine par une application tierce, comme par exemple une application dédiée à l'établissement de connexion à un portail de services par exemple.

Parmi ces quatre solutions ci-dessus, la troisième pourrait se présenter comme la plus efficace car elle permet à l'utilisateur d'accéder à une partie du contenu interactif sans toutefois engorger le réseau informatique. Néanmoins, dans les quatre situations, les services de diffusion à la demande des services d'origine restent de toute façon inaccessibles.

La première solution ci-dessus impose un filtrage des liens URL provenant des postes de télévision pour interdire leur accès aux contenus VOD distants (avec, à titre illustratif, la mise en œuvre susmentionnée d'un pare -feu).

Toutefois, les autres solutions s'appuient sur le filtrage des flux, la modification ou la génération de tables de signalisation, l'ajout ou la suppression de flux élémentaires, comme suit. La suppression de l'application (modification des tables PMT pour ne plus pointer sur les tables AIT et/ou suppression des tables AIT elles-mêmes) peut s'effectuer comme suit : réception des flux à filtrer au niveau de l'entité informatique S ;

lecture du contenu des tables PMT et identification des flux élémentaires et des tables AIT associées aux chaînes de télédiffusion ;

- suppression des entrées correspondant à des pointeurs vers des tables AIT ;

remplacement de la table PMT modifiée dans le flux sortant ;

et/ou suppression des tables AIT (par leur identifiant PID).

Les tables AIT sont identifiées dans les paquets transportés par le flux de transmission (au format DVB) par leur identifiant PID (pour « Packet Identifier »). Les tables de service PMT pointent notamment vers l'identifiant PID des tables AIT. Si l'on supprime l'identifiant PID des tables AIT dans les tables PMT, les tables PMT du flux ne peuvent plus correctement pointer vers les tables AIT (disparition de l'application interactive associée à la table PMT). Le filtrage des paquets de PID égal à celui d'une table AIT permet également de ne plus signaler l'application aux postes de télévision connectés.

La suppression de la référence au protocole HTTP dans la table AIT dans la troisième solution peut s'effectuer comme suit :

réception des flux à filtrer au niveau de l'entité informatique S ; lecture du contenu des tables PMT ;

identification des flux élémentaires et des tables AIT associées au service ;

lecture des tables AIT ;

réécriture des tables AIT après suppression des entrées correspondant à la définition du protocole HTTP ;

éventuellement filtrage des URL au niveau du réseau 111 tel que décrit dans la première solution.

Selon cette troisième solution, si l'application est également diffusée par un carrousel de données, elle reste disponible sous cette forme (le comportement étant alors le même que si le poste de télévision n'était pas connecté au réseau internet).

La quatrième solution consistant en un remplacement de l'application interactive d'origine par une application tierce, comme par exemple une application dédiée à l'établissement, peut se dérouler comme suit :

- réception des flux à filtrer au niveau de l'entité informatique S ;

lecture du contenu des tables PMT ;

identification des flux élémentaire et des tables AIT associées au service ;

suppression des entrées correspondant à des pointeurs vers des tables AIT ;

ajout d'une entrée correspondant à une nouvelle table AIT ;

- suppression des tables AIT d'origine (par leur identifiant PID) ;

ajout de la nouvelle table AIT, par exemple la table AIT 207.

modification des identifiants ONID (pour « Original Network IDentifier »), TSID (pour « Transport Stream IDentifier ») ou autres identifiants des flux d'origine de manière à ce que toutes les applications de tous les flux diffusés soient considérées comme une seule et même application : ainsi, et conformément à la norme HbbTV, l'application n'est pas interrompue lors du passage d'une chaîne à une autre et l'utilisateur peut à tout instant faire apparaître l'application par appui d'un code sur la télécommande (par exemple le « bouton rouge » précité). La modification des identifiants ONID et TSID par exemple permet d'établir une même application pour tous les services. Ainsi, lors d'un changement de services sur un terminal (changement de chaîne par exemple), ce terminal détecte que le nouveau service sélectionné comporte la même application que le service qu'il vient de quitter et il n'interrompt pas l'exécution de l'application interactive. En revanche, quand les deux applications sont considérées comme différentes, l'application interactive de départ est fermée et application interactive de la chaîne d' arrivée est démarrée. On se réfère maintenant à la figure 5 sur laquelle on a résumé les principales étapes du procédé mis en œuvre par l'entité informatique S selon une réalisation générale.

Dans une première étape SI, l'entité informatique S peut recevoir au moins un premier flux Oi comprenant des flux élémentaires de services (audio, vidéo, sous-titres, etc.) comme décrit précédemment. A titre d'exemple, ces flux élémentaires comportent des données de services télévisuels.

Dans une étape suivante S4, l'entité informatique S génère un flux commun Φ ₂ comportant au moins : - les données du flux Φι reçu à l'étape S 1 , et

des données associées à un ensemble de services de vidéo à la demande VOD _N à diffuser aux N postes de télévision connectés au réseau COAX.

Parmi cet ensemble de services de vidéo à la demande VOD _N , l'entité informatique S attribue au moins un service de vidéo à la demande respectivement à chacun des postes de télévision.

Pour ce faire, dans une étape préalable S2, l'entité informatique S génère les services de vidéo à la demande C ^VOD dédiés respectivement aux postes de télévisions TV1, TV2, TVN. A titre d'exemple, le service de vidéo à la demande C _j ^VOD est dédié au poste de télévision TVj (j=l,2,...,N). L'entité informatique S attribue à chacun des services de vidéo à la demande C ^VOD : des données de vidéo à la demande (data_VOD) récupérées auprès du serveur S_VOD, et

les tables de signalisation (signalisation_VOD) des données de vidéo à la demande, lesquelles tables sont récupérées auprès du générateur de tables de signalisation 11. Ainsi, chacun des services de vidéo à la demande C _j ^VOD dédiés aux postes de télévision TVj peut comporter des données (data_VOD)j et des tables de signalisation (signalisation_VOD)j propres à chacun des postes.

Comme décrit ultérieurement, on notera ici que les données de vidéo à la demande (data_VOD)j ne sont délivrées par le serveur S_VOD et diffusées par l'entité informatique S (via le flux commun Φ ₂ ) que si le poste de télévision TVj possède une session ouverte de service de vidéo à la demande auprès de l'entité, dans cet exemple de réalisation. A l'étape S3, l'entité informatique S génère ainsi l'ensemble de services de vidéo à la demande VOD _N comportant chacun des services de vidéo à la demande C _j ^VOD dédiés aux postes de télévision TVj, avant d'inclure (étape S4) cet ensemble VOD _N au flux commun Φ ₂ pour la diffusion des services à la demande à tous les postes de télévision membres du réseau COAX.

Dans une étape suivante S5, les postes de télévision reçoivent le flux commun Φ ₂ et procèdent à un test d'identification. A cette étape, les postes de télévision se réfèrent au service à la demande qui leur est dédié parmi l'ensemble de services de vidéo à la demande VOD _N reçu, et ceci en identifiant la table de signalisation de service (PMT) pour laquelle le poste TVj a été configuré. Dans le plan de services (appelé souvent « plan de chaînes TV ») dans lequel il a été programmé initialement, le poste TVj est configuré pour ne lire que la table PMT liée à un service donné et ignorer les autres tables. Ainsi, à l'étape S6, le poste TVj récupère le service de vidéo à la demande C _j ^VOD qui lui est dédié et ignore les services dédiés aux autres postes de télévision. Dans une étape suivante S7, le poste de télévision TVj procède à un test de détermination d'événements relativement à une application exécutée par le poste (application de navigation dans des contenus de vidéo à la demande par exemple). Ces événements peuvent provenir des actions précitées (par exemple appui sur un bouton de la télécommande du poste de télévision TVj par l'utilisateur). A cette étape S7, l'application du service de vidéo à la demande Appli (C _j ^VOD ) est mise en œuvre sur le poste TVj par exécution d'un contenu d'application Appli_F associé à cette application. Ce contenu Appli_F peut être récupéré (étape S 8) auprès du serveur web 105 de l'entité informatique S (et ceci, sur requête via la voie de retour 111) ou via le carrousel de données compris dans le flux commun Φ ₂ . Dans le cadre d'une récupération auprès du serveur web 105, on rappelle que le contenu de l'application Appli_F est récupéré grâce à : un lien décrit dans une table de signalisation d'application (AIT) diffusée via le flux commun Φ ₂ , ou

un lien enregistré dans un moyen de stockage du poste de télévision connecté TVj.

Par la suite, si un événement relatif à l'application est déterminé à l'étape S7, cet événement est interprété par l'application selon des requêtes REQ à destination du serveur web 105 de l'entité informatique S. A l'étape S9, la requête REQ est émise par le poste de télévision TVj selon un identifiant du poste. A titre purement illustratif, cet identifiant peut être une adresse du poste au sein du réseau COAX comme par exemple son adresse IP. Par exemple encore, dans le cadre d'une application de navigation au sein d'un contenu multimédia, on peut prévoir au moins une fonction « lecture » et une fonction « pause ». Lorsque le contenu multimédia est en pause, l'utilisateur peut sélectionner la fonction « lecture » de l'application en appuyant sur un bouton de la télécommande. Cet événement est interprété selon une requête REQ(IPj) comprenant la demande de lecture du contenu multimédia et est envoyée au serveur web 105 via la voie de retour 111, lequel serveur web 105 identifie la provenance de la requête via l'adresse IPj de l'émetteur (en l'occurrence, celle du poste TVj).

Lorsque l'entité informatique S reçoit la requête identifiée REQ(IPj) à l'étape S10, l'entité procède à un test de détermination des droits d'accès au service de vidéo à la demande du poste de TVj émetteur de la requête.

Lorsque le test de l'étape S 10 est satisfait (flèche O en sortie du test), le poste TVj a une session ouverte et possède des droits d'accès au service de vidéo à la demande. L'entité informatique S (étape SU) autorise alors le serveur S_VOD à délivrer les données de vidéo à la demande (data_VOD)j selon la requête REQ(IPj) du poste TVj, par exemple, avec une délivrance du contenu demandé par l'utilisateur via la requête de lecture précitée.

A l'étape suivante S12, l'entité informatique S récupère les données de vidéo à la demande (data_VOD)j délivrées par le serveur S_VOD et les attribue au service à la demande C _j ^VOD dédié au poste TVj avant de les diffuser dans le flux commun Φ ₂ .

Toutefois, lorsque le test de l'étape S 10 n'est pas satisfait (flèche N en sortie du test), le poste TVj n'a pas de session ouverte et l'entité informatique S ne satisfait pas la requête REQ(IPj). Le poste TVj peut à titre d'exemple être redirigé vers un portail PORT invitant l'utilisateur à ouvrir une session (en payant des droits d'accès par exemple) ou vers la page d'accueil de l'application de vidéo à la demande. Dans ce cas, l'entité informatique S ne reçoit pas du serveur S_VOD les données (data_VOD)j demandées par le poste TVj et ces données ne sont pas diffusées dans le flux commun Φ ₂ .

Bien entendu, on a décrit ci-avant un exemple de réalisation à titre purement illustratif et non limitatif, où les services à la demande sont ici des services de vidéo à la demande. Néanmoins, ce procédé s'étend à tout autre type de service à la demande (page d'accueil multimédia personnalisée, note de minibar, catalogue de prestations possibles selon le type de chambre ou de suite d'hôtel, etc.).