FR2968874A1 - Gestion de service dans un reseau - Google Patents

Abstract

L'invention concerne notamment un serveur de gestion de contexte pour personnaliser une offre de contenus numériques pour un utilisateur d'un système de diffusion audio-visuelle à travers un réseau de communication en fonction d'un contexte. Le système comprend un module d'interface utilisateur, un module de diffusion de contenus numériques, et un module de contrôle du module de diffusion. Le serveur comprend au moins un module agencé pour recevoir des informations de contexte. L'invention concerne également un module d'interface utilisateur, un module de diffusion de contenus numériques, un module de contrôle de module de diffusion, un système de diffusion audio-visuelle vers un dispositif utilisateur, comprenant les trois modules précités, un procédé de personnalisation d'une offre de contenus numériques, un programme d'ordinateur mettant en œuvre ledit procédé et un support stockant ce programme d'ordinateur.

Description

GESTION DE SERVICE DANS UN RESEAU

L'invention concerne un réseau de communication de type Internet, ou IP pour `Internet Protocol', et plus particulièrement une gestion de services offerts dans un tel réseau de manière personnalisée. Ce type de réseaux permet d'offrir différentes fonctions telles que, par exemple, des services téléphoniques (VoIP pour `Voice over IP'), de la vidéo téléphonie (V2oIP pour `Voice and Video Internet Protocol') ou encore de la diffusion vidéo (IPTV pour Internet Protocol TeleVision').

Les fonctions offertes aux utilisateurs leur permettent de plus en plus d'autonomie et de plus en plus de choix. Il en est notamment ainsi de services de type `nTS' (pour `network Time Shifting' en anglais) qui permettent à un utilisateur de visionner un programme de télévision en décalage par rapport à sa programmation de diffusion, ou encore des services de type `nPVR' (pour `network Personal Video Recorder' en anglais) qui permettent d'enregistrer au niveau du réseau un contenu 1 5 numérique pour un utilisateur. Dans les systèmes de télévision sur IP (ou IPTV, de l'anglais Internet Protocol TV), les services de télévision numérique sont notamment fournis aux utilisateurs s'appuyant sur le protocole IP (Internet protocol) au dessus d'une connexion haut débit. Les services de téléphonie sur IP peuvent être combinés avec de la téléphonie sur IP et des services de données. 20 La prise en compte du contexte pourrait permettre une personnalisation des services IPTV adaptée à chaque utilisateur (d'une manière différenciée), et adaptée à l'environnement de l'utilisateur (dispositif et réseau). L'article "Personalized TV Service through Employing Context-Awareness in IPTV/IMS Architecture", publié à la conférence FMN 2010, de S. SONG et al, concerne notamment des procédés et un système s'appuyant sur le protocole SIP. Dans cet article, 25 il est proposé notamment d'étendre l'architecture IPTV/IMS afin d'inclure la prise en compte du contexte et de permettre des services IPTV personnalisés dans le cadre d'une architecture IMS. Une architecture possible selon cet article comprend quatre parties : un serveur prenant en compte le contexte (CAS, de l'anglais Context-Aware Server), un équipement utilisateur prenant en compte le contexte (CAUE, de l'anglais Context Aware User Equipment), des modules de domaines de 30 services et un module de domaine de réseau. Le CAS est situé de façon centrale dans le coeur de réseau de l'opérateur pour permettre des services personnalisés pour l'utilisateur, qu'il soit chez lui ou en déplacement (par exemple à l'hôtel). Le CAS comprend quatre modules: i) un module de gestion prenant en compte le contexte (CAM, pour Context-Aware 35 Management Module). Ce module rassemble les informations de contexte obtenues de l'utilisateur, d'un serveur applicatif et du réseau, et dérive des informations de contexte de plus haut niveau par inférence de contexte. ii) un module de base de données de contexte (CDB). Ce module stocke les informations de contexte rassemblées et obtenues par inférence, et fournit une interface de requête à un module de déclenchement de service (ST). iii) un module de déclenchement de service (ST). Ce module offre deux fonctions: personnalisation de services établis, en fonction des diverses informations de contexte, et découverte et configuration de services personnalisés pour les utilisateurs en fonction des différents contextes. Le module ST communique dynamiquement avec le module CDB pour observer les informations de contexte avant de déclencher les services, et communique avec un module de protection de la vie privée (PP) pour vérifier si les services peuvent utiliser les informations de contexte ou s'il existe des contraintes de vie privée. iv) un module de protection de la vie privée (PP, de l'anglais Privacy Protection) module. Ce module effectue des contrôles pour déterminer quelles données peuvent être utilisées en vérifiant si les services prêts à être activés ont l'autorisation d'accéder aux informations de contexte requises ou à un sous ensemble, en fonction de différents niveaux de protection de la vie privée. Le CAUE comprend un module d'acquisition de contexte client (CCA, de l'anglais Client Context Acquisition) et un module de gestion de services locaux (LSM, de l'anglais Local Service Management). Le module CCA découvre les sources de contexte dans la sphère locale et collecte l'information de contexte brute (information de contexte d'utilisateur et de contexte de dispositif) puis l'envoie au module CAM situé dans le serveur CAS. Le module LSM contrôle et gère l'exécution des services locaux à l'aide du suivi du module CCA et de la comparaison dynamique du contexte avec ses règles stockées, de façon à activer un service correspondant de façon personnalisée.

Les modules de domaines de services situés au niveau des serveurs applicatifs comprennent un module d'acquisition de contexte de service (SCA, de l'anglais Service Context Acquisition) qui collecte de l'information de contexte de service et la transmet au module CAM, et un module d'acquisition de contexte de fourniture de media (MDCA, de l'anglais Media Delivery Context Acquisition) qui observe la fourniture de contenu et acquiert dynamiquement de l'information de contexte réseau durant la fourniture de service et l'envoie au module CAM. Dans le domaine réseau, un module d'acquisition de contexte réseau (NCA, de l'anglais Network Context Acquisition) collecte de l'information de bande passante en consultant le sous-système de contrôle de ressource et d'admission (RACS, de l'anglais Resource and Admission Control Sub-System) avant l'établissement de chaque session de service et envoie l'information acquise au module CAM.

Ce système prenant en compte le contexte a été introduit dans une architecture IPTV basée sur IMS pour permettre à cette architecture IPTV de prendre en compte le contexte et de fournir de nouveaux services personnalisés. Dans ce système IPTV basé sur IMS et prenant en compte le contexte, le coeur IMS est responsable du contrôle de la signalisation et du transfert de l'information de contexte de l'équipement utilisateur prenant en compte le contexte, du module de domaine de service et du module de domaine de réseau vers le serveur prenant en compte le contexte, ce qui facilite le déploiement de tels CAS grâce au plan de contrôle (en anglais « control plane ») permettant de transférer la signalisation. Cependant cette solution basée sur l'IMS s'appuie sur le protocole SIP, ce qui limite son application en excluant les applications non-SIP et impose le déploiement d'une architecture IMS. Le protocole SIP n'est pas encore très largement déployé et les solutions proposées dans cet article ne sont donc pas toujours utilisables. De surcroît, les solutions proposées dans cet article pour un service IPTV dans une architecture IMS ne sont pas directement transposables à d'autres architectures « dedicated IPTV system », telles qu'une architecture NGN IPTV. En effet, l'intégration du CAS dans une architecture IMS se fait simplement du fait que le serveur CAS est considéré comme un service vis à vis du réseau coeur IMS. Le serveur S-CSCF est prévu pour communiquer avec un serveur applicatif via une interface SIP. Pour un service IPTV sur une architecture de type NGN, un tel serveur n'est pas prévu. Il n'est pas possible de transposer directement cette intégration du CAS dans des architectures « dedicated IPTV system ».

L'invention vise à améliorer la situation. Selon un premier mode de réalisation, l'invention se rapporte à un serveur de gestion de contexte pour personnaliser une offre de contenus numériques (tels que des films ou de la télévision, sous forme de vidéo à la demande) pour un utilisateur d'un système de diffusion audio-visuelle à travers un réseau de communication en fonction d'un contexte. Le contexte est une information qui prend en compte les circonstances dans lesquels le contenu est délivré. Le contexte peut ainsi concerner la charge (par exemple en pourcentage de bande passante disponible) ou le débit disponible du ou des réseaux impliqués dans la fourniture de contenu numérique ainsi que la nature de ce(s) réseau(x) (notamment la technologie sous-jacente utilisée, telle que GSM, GPRS, 3G, EDGE, ADSL, câble, Ethernet sur paire torsadée, fibre optique, satellite, Bluetooth, infrarouge, etc.), le nombre de routeurs à traverser pour atteindre le dispositif de l'utilisateur, le type de dispositif employé par l'utilisateur pour percevoir le contenu numérique (baladeur MP3, smart phone, assistant personnel, ordinateur portable, ordinateur fixe, serveur, télévision, radio, etc.), l'heure, le lieu (par exemple le pays, la ville, l'adresse précise voire la pièce dans laquelle l'utilisateur se trouve), la date, la langue à employer, l'âge de l'utilisateur, son sexe, sa catégorie socioprofessionnelle, son poids, sa taille, son statut marital, ses habitudes alimentaires, ses goûts artistiques, ses habitudes de consommation, l'existence d'enfants éventuels, ou encore l'activité courante de l'utilisateur (déjeuner, sieste, sport, déplacement en voiture, en avion, en train, etc.). Le serveur est par exemple un serveur physique (matériel électronique) ou un serveur logiciel chargeable sur un serveur physique. Le système comprend un module d'interface utilisateur, un module de diffusion de contenus numériques, et un module de contrôle du module de diffusion.

Ces trois modules sont par exemple des modules logiciels exécutés par un microprocesseur, ou des modules électroniques (électronique câblée, microcontrôleur avec une mémoire chargeant un logiciel adapté, etc.). Le serveur comprend au moins un module de communication appartenant au groupe comprenant : - un premier module, agencé pour recevoir en provenance du module d'interface utilisateur des premières informations de contexte relatives à au moins un dispositif dudit utilisateur et/ou à l'utilisateur ; - un deuxième module, agencé pour recevoir en provenance du module de diffusion de contenus numériques des deuxièmes informations de contexte relatives au réseau pour une session établie de l'utilisateur ; et, - un troisième module, agencé pour recevoir en provenance du module de contrôle des troisièmes informations de contexte relatives au réseau lors d'une initialisation d'une session de l'utilisateur. Les trois modules du groupe sont par exemple des modules logiciels exécutés par un microprocesseur, ou des modules électroniques (électronique câblée, microcontrôleur avec une mémoire chargeant un logiciel adapté, etc.). Le contexte selon le premier mode de réalisation est déterminé à partir des informations de contexte (premières informations de contexte et/ou deuxièmes informations de contexte et/ou troisièmes informations de contexte) reçues par l'au moins un module de communication. Selon un mode de réalisation possible, les trois modules du groupe sont un seul et même module (par exemple un module CAM).

Ceci permet, de manière avantageuse, d'offrir des contenus numériques tenant compte du contexte, dans un cadre autre qu'une architecture SIP, les architectures SIP n'étant pour l'instant pas très répandues. En effet, avec le développement des services IPTV NGN, la coopération entre les opérateurs de réseaux et les fournisseurs de services devient cruciale. L'architecture IPTV de type NGN permet l'interopérabilité entre plusieurs opérateurs. Ne pas se lier à une architecture IMS qui est basée sur le protocole SIP permet d'accroître les possibilités de coexistence de différents systèmes IPTV appartenant à différents opérateurs de réseaux et fournisseurs de services. Cela améliore la compatibilité des services IPTV. Ce premier aspect de l'invention permet ainsi de proposer des solutions qui étendent les architectures IPTV de type NGN existantes en intégrant la prise en compte du contexte.

Dans ce type d'architecture, l'interfonctionnement de service n'est pas prévu. Par exemple, un service de présence interfonctionne uniquement avec l'équipement utilisateur UE par l'intermédiaire d'un module d'interface utilisateur. La mise en oeuvre de la solution connue pour l'architecture IMS présente l'inconvénient de prévoir un rôle central au module d'interface utilisateur pour communiquer les informations de contexte. Une telle solution n'est pas optimale et peut entraîner des problèmes de charge au niveau du module d'interface utilisateur. Selon un deuxième mode de réalisation concernant une mise en oeuvre particulière du premier mode de réalisation, le premier module est agencé pour recevoir des quatrièmes informations de contexte relatives au service, émises par un module de découverte de service du système et relayées par le module d'interface utilisateur. Ceci est avantageux car cela permet 1 0 d'enrichir les informations de contexte et de cibler davantage le contenu fourni. Selon un troisième mode de réalisation concernant une mise en oeuvre particulière du premier ou du deuxième mode de réalisation, le serveur comprend un module de déclenchement de service pour proposer une offre de contenus numériques personnalisée en fonction du contexte, et le troisième module est également agencé pour transmettre ladite offre au module de contrôle. Ceci 15 est avantageux car cela permet non seulement d'adapter du contenu fourni, mais également de proposer à l'utilisateur des contenus spécifiques. Selon un quatrième mode de réalisation concernant une mise en oeuvre particulière du premier, du deuxième ou du troisième mode de réalisation, le serveur comprend un module de déclenchement de service pour personnaliser un guide de programme en fonction du contexte et le 20 premier module est également agencé pour transmettre ledit guide de programme personnalisé au module d'interface utilisateur. Ceci permet d'améliorer la personnalisation du contenu. Ce module de déclenchement de service diffère notamment du module ST du serveur CAS selon l'article de Song et al., en ce qu'il permet de personnaliser un guide de programmes (EPG) en fonction d'informations contextuelles pour le fournir à un équipement utilisateur par l'intermédiaire d'un 25 module d'interface utilisateur. Un cinquième mode de réalisation de l'invention se rapporte à un module d'interface utilisateur pour système de diffusion audio-visuelle, le module comprenant un premier module de communication agencé pour relayer à un serveur de gestion de contexte selon le premier mode de réalisation des informations de contexte relatives à un dispositif d'un utilisateur et/ou à un 30 utilisateur. Le module selon le cinquième mode de réalisation est par exemple un module logiciel exécuté par un microprocesseur, ou un module électronique (électronique câblée, microcontrôleur avec une mémoire chargeant un logiciel adapté, etc.). Le cinquième mode de réalisation permet de partager des informations de contexte afin par exemple d'adapter un contenu ou de proposer des contenus particuliers. 35 Selon un sixième mode de réalisation, un module selon le cinquième mode de réalisation comprend des moyens d'enregistrement de l'utilisateur auprès dudit serveur préalablement à l'activation du premier module de communication pour ledit utilisateur. Selon un septième mode de réalisation, le premier module de communication d'un module selon le cinquième ou le sixième mode de réalisation est également agencé pour relayer des informations de contexte relatives au service reçues en provenance d'un module de découverte de service du système. Selon un huitième mode de réalisation, un module selon le cinquième, le sixième ou le septième mode de réalisation comprend un deuxième module de communication, agencé pour relayer vers le dispositif de l'utilisateur un guide de programme reçu en provenance du serveur de gestion de contexte. Le module selon les cinquième, sixième, septième et huitième modes de réalisation peut être avantageusement mis en oeuvre dans le cadre de la norme ETSI TISPAN, par exemple dans le cadre de la version actuelle de cette norme, à savoir ETSI TS 182 028, 2008, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN integrated IPTV subsystem Architecture". Ce module est alors par exemple un module de type CFIA (de l'anglais Customer Facing IPTV Application). Ce module peut avantageusement comprendre des moyens d'authentification et d'autorisation de l'utilisateur. Un neuvième mode de réalisation se rapporte à un module de diffusion de contenus numériques pour système de diffusion audio-visuelle. Le module comprend un moyen d'acquisition d'informations de contexte relatives au réseau pour une session établie d'un utilisateur et des moyens agencés pour transmettre des informations de contexte reçues par le moyen d'acquisition à un serveur de gestion de contexte selon le premier mode de réalisation. Dans le cadre de la norme ETSI/TISPAN, le module est par exemple de type MF (de l'anglais Media Function), et le moyen d'acquisition est par exemple de type MDCA. Ce neuvième mode de réalisation permet de partager des informations de contexte afin par exemple d'adapter un contenu ou de proposer des contenus particuliers. Un dixième mode de réalisation se rapporte à un module de contrôle de module de diffusion pour système de diffusion audio-visuelle. Le module de contrôle comprend des moyens de transmission agencés pour relayer des informations de contexte relatives au réseau lors d'une initialisation d'une session vers un serveur de gestion de contexte selon le premier mode de réalisation. Dans le cadre de la norme ETSI/TISPAN, le module est par exemple de type IPTV-C (de l'anglais IPTV Control Function). Ce dixième mode de réalisation permet de partager des informations de contexte afin par exemple d'adapter un contenu ou de proposer des contenus particuliers.

Un onzième mode de réalisation se rapporte à un système de diffusion audio-visuelle vers un dispositif utilisateur, comprenant un module d'interface utilisateur selon le cinquième mode de réalisation, un module de diffusion de contenus numériques selon le neuvième mode de réalisation et un module de contrôle de module de diffusion selon le dixième mode de réalisation. Un douzième mode de réalisation concerne un procédé de personnalisation d'une offre de contenus numériques pour un utilisateur d'un système de diffusion audio-visuelle à travers un réseau de communication en fonction d'un contexte. Le procédé comprend l'envoi d'informations de contexte d'un module d'interface utilisateur selon le cinquième mode de réalisation, d'un module de diffusion de contenus numériques selon le neuvième mode de réalisation et d'un module de contrôle de module de diffusion selon le dixième mode de réalisation vers un serveur selon le 1 0 premier mode de réalisation, via le réseau de communication. Selon un aspect de l'invention, le procédé de gestion établit trois interfaces non-SIP de type utilisant le protocole de transfert hypertexte http, qui présente l'avantage d'être de mise en oeuvre aisée. L'utilisation du protocole HTTP comme protocole de signalisation pour transmettre l'information de contexte et pour contrôler les services tenant compte du contexte est avantageuse 15 car elle permet d'étendre aisément les services à des services tiers, tels que, par exemple, des services de WEB TV ou des applications de réseaux sociaux (tels que Skype ou Facebook), et de façon générale des applications NGN. Selon un aspect de l'invention, le procédé de gestion comprend la réception, par le serveur de gestion de contexte, via l'une au moins des trois interfaces non-SIP, d'informations de contexte 20 relatives à un dispositif d'utilisateur et/ou à un utilisateur destinataire du contenu numérique, d'informations de contexte relatives au réseau pour une session établie de l'utilisateur, ainsi que d'informations de contexte relatives au réseau lors d'une initialisation d'une session de l'utilisateur. Avantageusement, le procédé de gestion comprend en outre la réception d'informations de contexte relatives au service de fourniture de contenu numérique. 25 La combinaison des quatre contextes est avantageuse car elle permet l'envoi de contenu numérique mieux ciblé. Un contexte donné peut être composé de plusieurs éléments, par exemple des informations de contexte d'utilisateur peuvent comprendre l'âge de l'utilisateur, sa taille, son sexe et son poids. Les informations de contexte relatives à un dispositif d'utilisateur et/ou à un utilisateur ont vocation à être transmises via l'interface non-SIP entre le serveur de gestion de 30 contexte prenant en compte le contexte (désigné par l'acronyme CAS, pour Context-Aware Server) et le module d'interface utilisateur. Ceci permet la fourniture de services TV avancés, adaptant le contenu au contexte de l'utilisateur et de son environnement, qui simplifie la compatibilité des différents systèmes IPTV et permet une meilleure coopération entre les différents opérateurs de réseaux et de services. Ceci permet également une meilleure qualité de service (QoS). Dans le 35 cadre d'une architecture IPTV NGN, les informations de contexte relatives au dispositif sont typiquement transmises d'un dispositif (tel qu'une Set Top Box) vers le module d'interface utilisateur CFIA pour être transférées au serveur de gestion de contexte. Les informations de contexte relatives à l'utilisateur sont quant à elles typiquement envoyées d'un module de gestion de profil UPSF (User Profile Server Function en anglais) de l'entité de gestion de contenus vers le module CFIA (de la même entité de gestion de contenus), qui le fait suivre au serveur de gestion de contexte. Les informations de contexte relatives au service de fourniture de contenu numérique peuvent être transmises d'un module SD&S (Service Discovery and Selection en anglais) de l'entité de gestion de contenus vers le module CFIA (de la même entité de gestion de contenus), qui le fait suivre au serveur de gestion de contexte. Les informations de contexte relatives au réseau peut être transmis des modules MF et CFIA vers le serveur de gestion de contexte. Les interfaces non-SIP proposées permettent ainsi avantageusement d'échanger les informations de contexte pertinentes et ainsi de fournir du contenu numérique plus approprié. Selon un aspect de l'invention, la mise en oeuvre du procédé implique un module de déclenchement de service du serveur de gestion de contexte, le procédé comprenant un échange entre une base de données mémorisant des contextes et le module de déclenchement de service afin de découvrir les services disponibles. Ceci peut s'appuyer notamment sur un contexte du service de fourniture de contenu numérique obtenu d'un module SD&S dans le cadre ETSI/TISPAN. Selon un aspect de l'invention, le procédé comprend l'envoi, par un module de déclenchement de service à un dispositif de collecte de contexte d'une requête de mise en place ou de personnalisation d'un service d'offre de contenu numérique. Selon un aspect de l'invention, le procédé comprend l'envoi, à un dispositif de collecte de contexte, d'un contenu numérique personnalisé en fonction du contexte présent dans la base de données.

Un treizième mode de réalisation concerne un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé selon le douzième mode de réalisation et/ou ses variantes, lorsque ce programme est exécuté par un processeur. Un quatorzième mode de réalisation se rapporte à un support de stockage non transitoire lisible par ordinateur sur lequel est stocké le programme d'ordinateur selon le treizième mode de réalisation (par exemple un CD, un DVD, une mémoire Flash, une mémoire ROM, un disque dur portable, un disque Blu-ray, etc.). Le dispositif utilisé par l'utilisateur pour visualiser le contenu appartient typiquement (ou est typiquement sous le contrôle) de l'utilisateur souhaitant obtenir le contenu numérique, et peut être par exemple un téléphone portable, un smart phone, un assistant personnel (de type PDA), un ordinateur portable, une tablette, une Set Top Box, ou encore une télévision numérique.

D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation.

L'invention sera également mieux comprise à l'aide des dessins, sur lesquels : - la figure 1 illustre une architecture IPTV étendue selon un mode de réalisation de l'invention , - la figure 2 illustre différents protocoles et interfaces utilisés dans le cadre d'un mode de réalisation de l'invention ; - la figure 3 illustre une procédure d'initialisation de service contextuel selon un mode de réalisation de l'invention ; - la figure 4 illustre un échange de messages dans le cadre de la transmission dynamique d'une information de contexte d'utilisateur et/ou de dispositif selon un mode de réalisation de l'invention ; - la figure 5 illustre un échange de messages dans le cadre de la transmission dynamique d'une information de contexte de service selon un mode de réalisation de l'invention ; - la figure 6 illustre un échange de messages dans le cadre de la transmission d'une information de contexte de réseau lors d'une initialisation de session selon un mode de réalisation de l'invention ; - la figure 7 illustre un échange de messages dans le cadre de la transmission dynamique d'une information de contexte de réseau selon un mode de réalisation de l'invention ; - la figure 8 illustre une notification par un module de déclenchement de service de l'existence d'un nouveau service personnalisé ; et - la figure 9 illustre une communication entre un module ST et un module MF afin de déclencher la fourniture d'un contenu personnalisé. Selon un mode de réalisation de l'invention, on intègre un système prenant en compte le contexte (tel que celui proposé dans l'article précité de S. SONG) avec une architecture NGN IPTV, formant un système de diffusion audio-visuelle et on définit des extensions aux protocoles existants pour permettre une communication entre le système prenant en compte le contexte et l'entité mettant en oeuvre l'architecture NGN IPTV, la communication permettant le transfert et le traitement de différentes informations de contexte concernant l'utilisateur, les dispositifs, les réseaux, ou encore le contenu numérique. On rend ainsi possible la personnalisation des services TV en termes de sollicitation de contenu, de sélection de contenu et d'adaptation de contenu.

L'architecture NGN IPTV utilisée peut être celle définie par l'ETSI/TISPAN, et peut inclure les fonctions suivantes : - Découverte et sélection de services (SD&S pour « Service Discovery and Selection »). La fonction SD&S fournit les informations d'attachement de service et de sélection de service (par exemple une liste de services disponibles qu'un utilisateur peut parcourir et sélectionner, les services correspondant à de l'offre de contenu numérique). On parle également de module SD&S pour désigner le module mettant en oeuvre la fonction SD&S; - Un module d'interface utilisateur pour l'application IPTV (CFIA pour « Customer Facing IPTV Application). La fonction CFIA est en charge de l'interface avec l'utilisateur et permet notamment de provisionner le service IPTV et de mettre en oeuvre une fonction d'authentification et d'autorisation vérifiant les droits d'accès de l'utilisateur en fonction du profil utilisateur stocké dans un module UPSF. On parle également de module CFIA pour désigner le module mettant en oeuvre la fonction CFIA; - La fonction de serveur de profil utilisateur (UPSF). On parle également de module UPSF pour désigner le module mettant en oeuvre la fonction UPSF. Le module UPSF est en charge d'héberger un ensemble d'informations liées à un utilisateur et d'informations de sécurité de l'utilisateur (notamment des informations de contrôle d'accès pour l'authentification et l'autorisation); - la fonction de contrôle IPTV, mise en oeuvre par un module de contrôle d'un module de diffusion IPTV-C. Le module IPTV-C fournit les fonctions de sélection et de gestion d'une fonction de diffusion MF; - la fonction de diffusion MF, responsable du contrôle et de la fourniture de flux de media à l'équipement utilisateur (UE, de l'anglais User Equipment), qui peut être par exemple un téléphone portable ou une Set Top Box, dont un utilisateur peut se servir pour consulter un contenu numérique. Les services applicatifs, par exemple le service de vidéo à la demande VoD ou le service de télévision en temps réel « Live », sont des Media Delivery Function qui sont intégrés dans le 25 module MF. La figure 1 représente une extension d'une architecture NGN IPTV par intégration d'un serveur prenant en compte le contexte (CAS), également appelé serveur de gestion de contexte, pour personnaliser des services IPTV. Il est possible d'utiliser le module UPSF pour stocker des informations de contexte 30 utilisateur statiques, telles que l'âge ou le sexe de l'utilisateur, les services auxquels il est abonné, ainsi que ses préférences. Selon un mode de réalisation, un module SCA est intégré dans le module SD&S et est agencé pour acquérir des informations de contexte de service utilisant un guide de services électronique (ESG, de l'anglais Electronic Service Guide) reçu par le module SD&S de la part d'un fournisseur de contenus, et qui inclut une description du contenu et du média. Un module d'acquisition de contexte de fourniture de média MDCA peut être intégré dans le module MF afin d'acquérir dynamiquement des informations sur l'état de réseau durant une session. Le module MF peut employer le protocole RTCP (pour « Real Time Transport Control Protocol », décrit dans le document de l'IETF RFC 3550) pour contrôler la fourniture de contenu en rassemblant dynamiquement des statistiques d'informations de contexte réseau pour une session de média en cours, par exemple des informations concernant les pertes de paquets, la gigue, ou le temps aller-retour (« round-trip delay » en anglais), les informations reflétant le contexte réseau.

Un module d'acquisition de contexte réseau NCA peut également être intégré au sein d'un sous-système de contrôle de ressources et d'admission RACS afin de collecter les informations de contexte lors de l'initialisation d'une session (telles que la bande passante). Enfin, il est possible de mettre en place un module d'acquisition de contexte client CCA et un module de gestion de services locaux LSM au sein de l'équipement utilisateur UE (smart phone, etc.).

Après chaque acquisition d'informations de contexte (liées par exemple à l'utilisateur, au dispositif, au réseau et aux services offerts), un module de gestion prenant en compte le contexte (CAM) du serveur de gestion de contexte CAS déduit des informations collectées des informations de contexte de plus haut niveau, qui peuvent être stockées dans une base de données de contexte CDB. Un module de déclenchement de service ST peut communiquer de façon continue avec le module CDB pour suivre l'évolution de l'information de contexte, en fonction de laquelle le module ST peut découvrir un besoin de personnaliser des services établis ou de configurer de nouveaux services. Dans cette optique, le module ST peut obtenir des informations de contexte stockées de la part de la base de données de contexte CDB et les utiliser lors du déclenchement d'un service correspondant. Avant de déclencher le service, le module ST peut communiquer avec un module PP pour vérifier si le service correspondant peut complètement utiliser l'information de contexte existante. S'il n'existe pas de contrainte de protection de la vie privée, le module ST peut activer les services personnalisés. On peut envisager notamment deux techniques d'activation des services personnalisés. Selon une première technique, décrite ultérieurement en relation avec la figure 8, le module ST personnalise un guide de programme électronique (« personalized EPG » en anglais) comme une sorte de personnalisation de contenu (ou recommandation de service) correspondant au contexte utilisateur courant et notifie l'utilisateur de l'existence d'un nouveau service personnalisé en lui envoyant (c'est-à-dire en envoyant à son équipement utilisateur UE) le guide de programme électronique personnalisé. Le module ST utilise un message HTTP NOTIFY pour notifier l'utilisateur. Selon un mode de réalisation, il est proposé d'utiliser un nouveau message HTTP NOTIFY étendant le message HTTP POST classique en encapsulant l'information de notification de service, comme illustré ci-dessous : POST HTTP/1.1 HOST CAS/NOTIFY LOCATION: UE Content-type: text/xml Content-Length: (...) <?xml version="1.0" encoding="UTF-8"?> <context xmlns="urn:ietf:params:xml:ns:context" xmins:rpid="urn:ietf:params:xml:ns:pidf:rpid"> <notify> <entity></entity> <service> <description></description> <pird:content type></content type> </service> </notify> Selon une deuxième technique, décrite ultérieurement en relation avec la figure 9, le module ST propose une offre de contenus numériques personnalisée et envoie au module IPTV-C un message HTTP NOTIFY encapsulant l'information de service pour déclencher un service (par 20 exemple adaptation de contenu selon le contexte utilisateur) comme illustré ci-dessous : POST HTTP/1.1 HOST CAS/NOTIFY LOCATION: IPTV-C Content-type: text/xml 25 Content-Length: (...) <?xml version="1.0" encoding="UTF-8"?> <context xmlns="urn:ietf:params:xml:ns:context" xmins:rpid="urn:ietf:params:xml:ns:pidf:rpid"> <notify> 30 <entity></entity> <service> <description></description> <rpid:bandwidth></bandwidth> <rpid:device><device> 35 </service> </notify> Afin de mettre en oeuvre l'adaptation de contenu, le module IPTV-C sélectionne le module MF approprié et lui fait suivre l'information de service, puis ce dernier modifie le contenu en fonction de l'information de contexte reçue.

40 Sur la figure 1, dans une étape 1, on transmet des informations de contexte relatives à l'utilisateur et au dispositif utilisateur. Dans une étape 2, on transmet des informations de contexte relatives au service. Dans une étape 3, on transmet des informations de contexte relatives au réseau. Dans une étape 4, on détermine des informations de contexte de plus haut niveau, appelées contexte, à partir des informations de contexte reçues par inférence et on stocke le contexte dans la 45 base de données CDB. Les étapes 1 à 4 sont de nouveau mises en oeuvre lorsque des modifications sont détectées. Dans une étape 5, le module ST communique avec la base de données CDB pour 10 15 obtenir le contexte et découvrir les services. Dans une étape 6, le module ST communique avec le module PP pour vérifier s'il y a des contraintes de protection de la vie privée. Dans une étape 7, le module ST peut proposer une offre de contenus numériques personnalisée en fonction du contexte et envoyer une requête au module de contrôle IPTV-C pour configurer les services ou personnaliser les services. Toujours dans cette étape 7, le module ST peut personnaliser un guide de programme en fonction du contexte et transmettre ce guide de programme personnalisé au module CFIA. Dans une étape 8, un contenu adapté est envoyé à l'équipement utilisateur UE. La figure 2 représente différents protocoles et interfaces utilisés dans une architecture IPTV basée sur NGN et prenant en compte le contexte selon un mode de réalisation de l'invention.

Les protocoles utilisés à travers les interfaces Tr, Ss', Ss, Gq', Xd, Sa, Sh sont décrits dans la norme ETSI/TISPAN. Selon cette norme, le module de contrôle IPTV-C communique avec l'équipement utilisateur UE directement ou par l'intermédiaire du module d'interface utilisateur CFIA. Le module de contrôle IPTV-C contrôle le module MF. On utilise les interfaces Tr, Ss, Ss', Sh, Gq' pour transférer des informations de contexte, et on définit trois nouvelles interfaces Ca, Cc, Ca' utilisées par les modules CFIA, IPTV-C et MF pour communiquer avec le serveur CAS pour transférer également des informations de contexte. Le protocole utilisé dans ces trois nouvelles interfaces est le protocole HTTP. Ces nouvelles interfaces permettent ainsi d'intégrer le service de gestion de contexte de façon simple dans l'architecture IPTV NGN. Le serveur CAS communique avec le module CFIA au travers de l'interface Ca, notamment pour : - recevoir des informations de contexte relatives à au moins un dispositif dudit utilisateur et/ou à l'utilisateur et des informations de contexte relatives au service, émises par un module de découverte de service du système et relayées par le module CFIA, et - transmettre un guide de programmes personnalisé en fonction du contexte.

Le serveur CAS communique avec le module MF au travers de l'interface Ca', notamment pour recevoir des informations de contexte relatives au réseau pour une session établie de l'utilisateur. Le serveur CAS communique avec le module IPTV-C au travers de l'interface Cc, notamment pour : - recevoir des informations de contexte relatives au réseau lors d'une initialisation d'une session de l'utilisateur, et - proposer une offre de contenus numériques personnalisée en fonction du contexte. Les procédures de communication mises en oeuvre dans le cadre de l'architecture IPTV NGN et prenant en compte le service de gestion de contexte comprennent notamment les procédures d'enregistrement contextuel de service, et la transmission d'informations de contexte entre l'utilisateur final, le réseau, les serveurs de contenu et/ou domaines de services, et le serveur CAS.

La procédure d'enregistrement contextuel de service complète la procédure classique d'initialisation et d'authentification de service IPTV afin de transférer les informations statiques de contexte acquises. Après authentification, le module CFIA enregistre l'équipement utilisateur IPTV UE auprès du serveur CAS au moyen de l'interface Ca en utilisant un nouveau message HTTP REGISTER complétant le message HTTP POST classique en encapsulant les informations d'enregistrement de l'utilisateur comme illustré ci-dessous : POST /users HTTP/1.1 Host: CAS/REGISTER Content-Type: application/xml Content-Length: (...) <?xml version="1.0" encoding="UTF-8"?> <context xmins="urn:ietf:params:xml:ns:context"> <registration> <user></user> </registration> </context> L'information statique de contexte est stockée dans le module UPSF. Selon un mode de 20 réalisation de l'invention, il est proposé d'étendre le message Diameter de réponse d'attribution de serveur (Diameter Server-Assignment-Answer message, défini dans 3GPP TS 29.229: "Cx Interface based on Diameter - Protocol details") qui est envoyé par le module UPSF au module CFIA pour inclure l'information statique de contexte en ajoutant un attribut AVP (Attribute Value Pair) de contexte statique de l'utilisateur (« User- Static-Context» en anglais). Ce message 25 Diameter étendu est illustré ci-dessous : <Server-Assignment-Answer> :.= < Session-Id > {Vendor-Specific-Application-Id} [Result-Code] [Experimental-Result] {Auth-Session-State} {Origin-Host} {Origin-Realm} [User-Name] [Supported-Features] [User-Data] [Charging-Information] [Associated-Identities] [Loose-Route-Indication] [User-Static-Context] 40 Selon un mode de réalisation, on utilise un message HTTP POST pour transmettre l'information de contexte statique de l'utilisateur, stockée dans le module UPSF, au serveur CAS. La représentation de l'information de contexte dans ce message s'appuie par exemple sur le format RPID (défini dans le document de l'IETF RFC4480), complété pour inclure des attributs 15 30 35 d'information de contexte pour représenter le contexte statique de l'utilisateur (concernant par exemple les préférences de l'utilisateur, les services auxquels l'utilisateur est abonné et l'âge de l'utilisateur). Le message HTTP POST est illustré ci-dessous : POST /users HTTP/1.1 Host: CAS/Context Content-Type: application/xml Content-Length: (...) <?xml version="1.0" encoding="UTF-8"?> <context xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmins:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="pres:user public@home. net"> <dm:person id="1234"> <rpid: preference><rpid:preference/> <rpid: subscription><rpid:subscription/> <rpid:age><rpid:age/> </dm:person>

</context> La figure 3 illustre un échange de messages lors d'une procédure d'initiation de service 20 contextuel selon un mode de réalisation. Le message 1 permet à un équipement utilisateur UE d'envoyer un message HTTP au module CFIA pour initialiser le service IPTV. Durant cette étape, l'équipement utilisateur UE exécute une procédure d'authentification de manière similaire à un scenario de service IPTV classique. 25 Les messages 2, transmis du module CFIA au serveur CAS, et 3, du serveur CAS au module CFIA, permettent d'enregistrer l'équipement utilisateur UE auprès du service de gestion de contexte CAS pour le compte de l'équipement utilisateur UE en utilisant un message http POST. Le message 4 correspond au téléchargement, à partir du serveur de profil UPSF, du profil utilisateur par le module CFIA après authentification réussie de l'utilisateur. Le protocole Diameter 30 est utilisé pour inclure dans le profil une information de contexte statique de l'utilisateur en ajoutant un attribut AVP de contexte statique d'utilisateur. Le message 5 permet au module CFIA d'envoyer l'information de contexte statique de l'utilisateur au serveur CAS en utilisant un message HTTP POST. Lorsque le serveur CAS accepte l'information de contexte, il envoie un message 6 de réponse 200 0K au module CFIA qui le relaie 35 (message 7) à l'équipement utilisateur UE. Selon un mode de réalisation, une procédure de transmission dynamique d'information de contexte d'utilisateur et/ou de dispositif (le dispositif désignant l'équipement utilisateur UE) est 10 15 16 proposée pour permettre au module CCA de l'équipement utilisateur UE de mettre à jour, dans le serveur CAS, l'information de contexte d'utilisateur et/ou de dispositif qu'il acquiert dynamiquement. Il est proposé d'utiliser un message HTTP POST pour transmettre l'information de contexte. La représentation de l'information de contexte dans le message HTTP POST suit par exemple le format RPID, en le complétant pour inclure des attributs d'information de contexte représentant le contexte d'utilisateur et de dispositif, par exemple la localisation de l'utilisateur (telle que : intérieur ou extérieur), la localisation du dispositif, les types de réseaux supportés, les formats de média supportés, la taille de l'écran, ou encore le type de réseau. Le message HTTP POST est illustré ci-dessous : POST . user . HTTP/1.i Hast: CAS/context Content-Type application% xml Content-Length: (...) .?xml "v`_.rion.-" ... O" encod.7.rig "UTF-3"^ <:c ;t i: xt x_::.1ris="urn. i_e?:f üararr.s:xc:: .r s p:id:f " xm1ns:dm "urn:ietf ,Darams:xml: s:pidf:data--model" xm1ns d_"urn . et params : -_ml : n,s : rpid`° ent; ="raresuser public@horre,n et <dm:person id="1234"> <rpid:place-type><rpid:home/></rpid:place-type> <rpid:location><rpid:salon/></rpid:location> <rpid:network-type><rpid: ADSL/></rpid: network-type> </dm:person> <dm:device id="1"> <rpid:location><rpid:salon/></rpid:location> <rpid:supported_network_type> <rpid:fix><rpid:supported_network_type> <rpid:supportedmedia_format><rpid:mpeg2/><rpid:supportedmedia_format> <rpid: screen_size><><rpid:screen_size> </dm: device> c:ortexl:> La figure 4 illustre un échange de messages correspondant à cette procédure de transmission dynamique d'informations de contexte relatives à un dispositif ou à un utilisateur. Le message 1 correspond à la transmission au module CFIA (et la mise à jour dynamique) de l'information de contexte acquise par l'équipement utilisateur UE, concernant par exemple l'information de contexte de l'utilisateur et du dispositif. Le message HTTP POST étendu est utilisé. Le module CFIA relaie ce message (message 2) au serveur CAS au moyen de l'interface Ca. Le message 3 permet au CAS d'envoyer un message de confirmation de prise en compte de contexte CA-OK (Context-Aware OK) au module CFIA, qui le relaie (message 4) à l'UE, pour confirmer à ce dernier la mise à jour effective, ce qui s'apparente à un message 200 0K dans le cadre du protocole HTTP. Les messages 1 à 4 sont répétés lorsque le dispositif UE découvre de nouvelles informations de contexte.

La procédure de transmission dynamique d'information de contexte de service est similaire à la procédure de transmission dynamique de l'information de contexte utilisateur au serveur CAS ainsi qu'à la procédure de mise à jour dynamique d'information de service lorsque le message HTTP POST est utilisé. La représentation de l'information de contexte dans le message HTTP POST suit le format RPID, complété pour inclure des attributs d'informations de contexte représentant le contexte de service (par exemple l'heure de commencement et de fin du service, le type de contenu numérique, ou encore le type de codec). Le message HTTP POST incluant les attributs représentant le contexte de service est illustré ci-dessous : POST /users HTTP/1.2, F ost: CAS,'Context. Content-Type: application/ xm Content-Length: { ,) ?ana. version-'1.0" enco;lirq-"U':['x'-8"?> <context xmIns="uir::iet `params:xmi:n`. pidf" xmins et "uin : ietf `params : xmi : ns : pidf : data-modei t" xmins pid=''urn: iett par ams xml : r::. pidf , rpi " er:t ity="pres SD nd:S@home . net' - <dm:content> <rpid:content-type></rpid: content-type> <rpid:starttime></rpid:starttime> <rpid:endtime></rpid:endtime> <rpid:codec></rpid:codec> </dm content> !content La figure 5 illustre l'échange de messages correspondant à cette procédure de transmission dynamique d'information de contexte de service. Le message 1 correspond à la transmission au module CFIA (et la mise à jour dynamique) de l'information de contexte acquise par le SCA grâce à l'extraction de l'information de contexte de service depuis l'ESG reçu du module SD&S. Le module CFIA le relaie au serveur CAS (message 2) au moyen de l'interface Ca. Le message HTTP POST est utilisé. La représentation de l'information de contexte dans le message HTTP POST suit le format RPID. Le message 3 correspond à l'envoi par le serveur CAS d'un message CA-OK (Context-Aware OK) au module CFIA. Ce message est relayé vers le module SD&S (message 4). Ce message s'apparente à un message 200 0K dans le protocole HTTP.

Les messages 1 à 4 sont répétés lorsque le module SD&S reçoit de nouvelles informations de contexte. La procédure de transmission d'information de contexte réseau durant l'initialisation de session s'opère, selon un mode de réalisation, en complétant le processus de réservation de ressources selon l'état de l'art. Dans l'état de l'art, le module IPTV-C recevant la requête de service

envoie un message AA-Request selon le protocole Diameter au sous-système RACS pour réserver une ressource. En fonction des ressources disponibles, le RACS décide de réserver ou non une ressource pour le service. Un message AA-answer est envoyé par le RACS au module IPTV-C pour l'informer du résultat de la requête de réservation de ressource (succès ou échec). Le processus est complété de façon à également envoyer une information de bande passante au module IPTV-C, en intégrant un module NCA dans le RACS et en faisant générer par ce module NCA un message AA-Answer de contexte (CAA-Answer) étendant le message AA-Answer par l'ajout d'un attribut AVP d'information de QoS (qualité de service, de l'anglais quality of service) qui peut par exemple comprendre une information de bande passante. Un exemple de message de ce type est illustré ci-dessous : CAA-Answer message <CAA-Answer> :._ < Session-Id > Auth-Application-ID Origin-Host } Origin-Realm } Result-Code ] Experimental-Result Error-Message ] Error-Reporting-Host [QoS-Information] QoS-Information AVP Format 25 QoS-Information ::= < AVP Header: 1016> [Traffic-Descriptor] La figure 6 illustre l'échange de messages correspondant à cette procédure de transmission d'information de contexte réseau. Le message 1 correspond à une requête d'initialisation classique envoyée par l'utilisateur 30 souhaitant commencer à obtenir le service vers le module IPTV-C, et s'appuie sur un message de type RTSP (Real Time Streaming Protocol). Le message 2 correspond à la requête de réservation de ressource, dans laquelle le module IPTV-C recevant le message 1 contacte le RACS en utilisant le message AA-Request du protocole Diameter. 35 Le message 3 correspond à la réponse à la requête de réservation de ressource, dans laquelle un message CAA-Answer du protocole Diameter modifié, contenant une information de ressource (bande passante), est envoyé par le module NCA du RACS au module IPTV-C. { { { } ] Le message 4 correspond à la transmission d'information de contexte réseau lors d'une initialisation d'une session (en l'occurrence, une information de bande passante) par le module IPTV-C au serveur CAS au moyen de l'interface Cc, utilisant un message HTTP POST. Selon un mode de réalisation, une procédure permet à un module MDCA de transmettre dynamiquement au CAS une information de contexte réseau liée à la session en cours. Un message HTTP POST est utilisé, la représentation de l'information de contexte réseau suivant le format RPID modifié pour inclure des attributs d'information de contexte représentant le contexte réseau (par exemple la gigue, les pertes de paquets et les retards). Un tel message incluant des attributs représentant un contexte réseau est représenté ci-dessous : POST /users HTTP/1.1 Host: CAS/context Content-Type: application/xml Content-Length: (...) <?xml version="1.0" encoding="UTF-8"?> <context dm="urn:ietf:params:xml:ns:pidf" xmins:dm="urn:ietf:params:xml:ns:pidf:data-model" xmins:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity=" IPTV-C@home.net"> <dm:network id="1234"> <rpid:network_state> <jitter> </jitter> <packet_loss> </packet_loss> <delay> </delay> </network state> </dm:network> </context>

La figure 7 illustre un échange de messages correspondant à cette procédure qui permet à un module MDCA d'un module MF de transmettre dynamiquement au serveur CAS une information de contexte réseau liée à la session en cours.

30 Le message 1 correspond à l'extraction de l'information de contexte réseau liée à la session en cours par un module MDCA, s'appuyant sur un protocole RTP (Real-time Transport Protocol) et des rapports/statistiques RTCP durant la session en cours. Le message 2 correspond à la transmission d'information de contexte par un module MDCA au serveur CAS, grâce à un message HTTP POST au moyen de l'interface Ca'. La 35 représentation de l'information de contexte dans le message HTTP POST suit le format RPID. La figure 8 illustre une notification par un module de déclenchement de service de l'existence d'un nouveau service personnalisé. Le module ST peut notifier un utilisateur de l'existence du nouveau service en lui envoyant directement un EPG personnalisé en tant que personnalisation de contenu correspondant au contexte actuel de l'utilisateur.

20 25 Le message 1 (message HTTP GET envoyé par un équipement utilisateur) correspond à une requête de l'utilisateur d'un guide de programme personnalisé transmise vers le module CFIA. Ce dernier relaie le message (message 2) vers le serveur CAS. Le serveur CAS, plus précisément le module ST du serveur CAS, transmet un message 3 au moyen de l'interface Ca à destination du module CFIA qui le relaie (message 4) vers l'équipement utilisateur. Les messages 3 et 4 sont des messages HTTP Notify étendant les messages HTTP POST classiques en encapsulant de l'information de service. Ils contiennent l'EPG personnalisé généré par le module ST selon l'information de contexte stockée dans la CDB. La figure 9 illustre une communication entre un module ST et un module MF afin de déclencher la fourniture d'un contenu personnalisé. Le module ST envoie à au module IPTV-C un message HTTP NOTIFY (message 1) encapsulant l'information de service pour déclencher un service (par exemple adaptation de contenu selon le contexte utilisateur). Afin d'achever l'adaptation de contenu, le module IPTV-C sélectionne le module MF approprié et lui fait suivre l'information de service (message 2). Le module MF peut ainsi prendre en compte cette information durant l'adaptation de contenu. Les modes de réalisation décrits ci-dessus à titre d'exemples n'ont aucun caractère limitatif Les modes de réalisation décrits permettent un déploiement aisé en s'appuyant sur des architectures existantes (par exemple celles qui sont standardisées par ETSI/TISPAN) pouvant être complétées en s'appuyant sur des protocoles standardisés par l'IETF. Ceci permet une personnalisation avancée des services IPTV basée sur des informations de contexte riches et pouvant être liées à la vie quotidienne des utilisateurs (préférences utilisateur, localisation, proximité des dispositifs pertinents, réseaux disponibles et leur proximité, contexte de service, etc.). Ceci est particulièrement avantageux pour les utilisateurs mobiles et en particulier pour l'accès nomade à des services IPTV d'une façon personnalisée, puisqu'il n'y a pas d'association fixe entre un identifiant d'un utilisateur et un terminal. En effet, le système est capable de distinguer chaque utilisateur de manière personnalisée en prenant en compte les équipements de celui-ci et les caractéristiques du réseau, quel que soit l'équipement utilisé pour accéder aux services et le lieu de l'accès (domicile, déplacement, etc.).

Claims (14)

1. REVENDICATIONS1. Serveur de gestion de contexte pour personnaliser une offre de contenus numériques pour un utilisateur d'un système de diffusion audio-visuelle à travers un réseau de communication en fonction d'un contexte, le système comprenant un module d'interface utilisateur, un module de diffusion de contenus numériques, et un module de contrôle du module de diffusion, le serveur comprenant au moins un module de communication appartenant au groupe comprenant : - un premier module, agencé pour recevoir en provenance du module d'interface utilisateur des premières informations de contexte relatives à au moins un dispositif dudit utilisateur et/ou à l'utilisateur ; - un deuxième module, agencé pour recevoir en provenance du module de diffusion de contenus numériques des deuxièmes informations de contexte relatives au réseau pour une session établie de l'utilisateur ; et, - un troisième module, agencé pour recevoir en provenance du module de contrôle des troisièmes informations de contexte relatives au réseau lors d'une initialisation d'une session de l'utilisateur, le contexte étant déterminé à partir des informations de contexte reçues par l'au moins un module 20 de communication.
2. 2. Serveur de gestion de contexte selon la revendication 1, dans lequel le premier module est agencé pour recevoir des quatrièmes informations de contexte relatives au service, émises par un module de découverte de service du système et relayées par le module d'interface utilisateur.
3. 3. Serveur selon la revendication 1, comprenant un module de déclenchement de service pour proposer une offre de contenus numériques personnalisée en fonction du contexte et dans lequel le troisième module est également agencé pour transmettre ladite offre au module de contrôle. 30
4. 4. Serveur selon la revendication 1, comprenant un module de déclenchement de service pour personnaliser un guide de programme en fonction du contexte et dans lequel le premier module est également agencé pour transmettre ledit guide de programme personnalisé au module d'interface utilisateur. 35
5. 5. Module d'interface utilisateur pour système de diffusion audio-visuelle, le module comprenant un premier module de communication agencé pour relayer à un serveur de gestion de 25 contexte selon la revendication 1 des informations de contexte relatives à un dispositif d'un utilisateur et/ou à un utilisateur.
6. 6. Module selon la revendication 5, comprenant des moyens d'enregistrement de l'utilisateur auprès dudit serveur préalablement à l'activation du premier module de communication pour ledit utilisateur.
7. 7. Module selon la revendication 5, dans lequel le premier module de communication est également agencé pour relayer des informations de contexte relatives au service reçues en provenance d'un module de découverte de service du système.
8. 8. Module selon la revendication 5, comprenant un deuxième module de communication, agencé pour relayer vers le dispositif de l'utilisateur un guide de programme reçu en provenance du serveur de gestion de contexte.
9. 9. Module de diffusion de contenus numériques pour système de diffusion audio-visuelle, le module comprenant un moyen d'acquisition d'informations de contexte relatives au réseau pour une session établie d'un utilisateur et des moyens agencés pour transmettre des informations de contexte reçues par le moyen d'acquisition à un serveur de gestion de contexte selon la revendication 1.
10. 10. Module de contrôle de module de diffusion pour système de diffusion audio-visuelle, le module de contrôle comprenant des moyens de transmission agencés pour relayer des informations de contexte relatives au réseau lors d'une initialisation d'une session vers un serveur de gestion de contexte selon la revendication 1.
11. 11. Système de diffusion audio-visuelle vers un dispositif utilisateur, comprenant un module d'interface utilisateur selon la revendication 5, un module de diffusion de contenus numériques selon la revendication 9 et un module de contrôle de module de diffusion selon la revendication 10.
12. 12. Procédé de personnalisation d'une offre de contenus numériques pour un utilisateur d'un système de diffusion audio-visuelle à travers un réseau de communication en fonction d'un contexte, le procédé comprenant l'envoi d'informations de contexte d'un module d'interface utilisateur selon la revendication 5, d'un module de diffusion de contenus numériques selon la revendication 9 et d'un module de contrôle de module de diffusion selon la revendication 10 vers un serveur selon la revendication 1, via le réseau de communication.
13. 13. Programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé selon la revendication 12, lorsque ce programme est exécuté par un processeur.
14. 14. Support de stockage non transitoire lisible par ordinateur sur lequel est stocké le programme d'ordinateur selon la revendication 13.