Brevet FR2999849A1 — publié le 20140620

Procédé d'accès à un contenu muid media, terminal mobile, terminal fixe et module logiciel correspondants. Domaine de l'invention La présente invention concerne de manière générale l'accès à des contenus accessibles dans les réseaux de télécommunications et leur visualisation à partir d'un terminal. L'invention se rapporte de manière générale au domaine des télécommunications et plus particulièrement aux techniques qui mettent en jeu du streaming. Le mot streaming est utilisé par référence à la possibilité qu' à une application d'utiliser des flux de données synchronisées, par exemple audio ou vidéo, de manière continue alors que ces flux sont transmis au client par un réseau de données. Au niveau applicatif, on distingue souvent les services en direct (« live ») des services à la demande. Par exemples pour les services en direct on peut citer la fourniture de contenu radio ou de programmes TV en direct, et pour les services à la demande on peut citer la musique, les nouvelles de type podcast et la vidéo VOD à la demande. Les services de streaming dans un réseau paquet basé protocole IP font l'objet d'actions de normalisation, en particulier au sein du 3GPP. Le standard TS 26 234 (ETSI TS 126 234) spécifie les protocoles et codecs (codeurs décodeurs) associés à ces services. Le standard TS 22 233 (ETSI TS 122 233) spécifie l'architecture générale du réseau impliquée dans des services de streaming. Cette architecture est illustrée par les figures 1 et 2 qui correspondent respectivement à une architecture 2G/3G (UMTS) avec un coeur de réseau GPRS et une architecture 2G/3G/4G et un coeur de réseau EPC. Un service de streaming fonctionne sur un schéma client/serveur, il s'appuie sur au moins un serveur de contenu et un client destinataire du streaming Le serveur de contenu est situé derrière l'interface Gi. D'autres entités situées derrière cette interface Gi peuvent intervenir dans le service, en particulier des portails, des serveurs de profils, des serveurs de cache et de proxy. Un portail est un serveur qui permet l'accès à du contenu de streaming, par exemple il peut permettre de faire des recherches. Le portail le plus simple correspond à une page WEB((X)HTML)/WAP avec une liste de liens de contenu téléchargeable ou de streaming qui pointe vers un serveur généralement distant et situé derrière l'interface Gi. Les serveurs de profils stockent des profils d'équipements qui allient des données propres à l'utilisateur et des données spécifiques à l'équipement (terminal). Ces profils peuvent être utilisés pour contrôler la présentation du contenu muid media de streaming à l'utilisateur du terminal comme illustré par la figure 3. Le client (UE PSS client) initialise le service et se connecte au serveur de contenu sélectionné. Le serveur de profils peut être contacté lors d'une phase initiale. Les données propres à l'utilisateur permettent de paramétrer le service de streaming avec les préférences de l'utilisateur. Les données spécifiques au terminal sont utilisées par le service de streaming pour décider si le terminal du client est capable ou pas de recevoir le contenu de streaming La figure 4 est une représentation schématique du contenu d'un profil équipement qui se décompose en des données propres à l'utilisateur et en des données spécifiques à l'équipement (terminal). Les données propres à l'utilisateur comprennent essentiellement les préférences de l'utilisateur dans l'utilisation de cet équipement pour le service considéré. Les données spécifiques à l'équipement peuvent être décomposées en trois modules, un module de description des capacités matérielles du terminal (type du terminal, numéro de modèle, taille de l'écran, entrées/sorties, etc), un module de description des capacités logicielles du terminal (système d'exploitation (OperatingSystem), codeurs vidéo et audio compatibles, etc) et un module de plug-in matériel et logiciel. Dans le contexte de l'invention, il est effectué une distinction entre un terminal fixe et un terminal mobile. Le terminal fixe est classiquement une télévision ou un écran accessible via un réseau de télécommunication qui est utilisé pour visualiser un contenu vidéo et plus généralement pour restituer à l'utilisateur un contenu mufti média. Le terminal mobile est classiquement un téléphone mobile, par exemple un smartphone, qui permet d'établir une communication téléphonique et plus largement des communications de différents types en fonction de l'abonnement souscrit par le client auprès d'un opérateur mobile. Art antérieur Les utilisateurs de terminaux disposent souvent de plusieurs types de terminaux fixes et mobiles qu'ils configurent selon leurs préférences. Ils peuvent choisir par exemple de visualiser uniquement certaines chaînes de télévision comme leurs chaînes favorites qui sont alors mises en avant dans la page d' accueil, ils peuvent renseigner une grille de programmes et marquer des émissions qu'ils souhaitent visualiser. Aujourd'hui, l'utilisateur doit généralement configurer spécifiquement chaque terminal selon ses préférences. Exposé de l'invention L'invention a pour objet un procédé d'accès à un contenu mufti media accessible via un système de télécommunication, initialisé depuis un terminal mobile identifié auprès d'un opérateur mobile. Le procédé comprend : une phase de découverte par le terminal mobile d'un terminal fixe à proximité, comprenant une mémorisation par le terminal mobile de données de profil du terminal fixe, une transmission depuis le terminal mobile d'une requête d'activation d'un service d'accès à du contenu muid media enrichie de données de profil du terminal fixe à un serveur de gestion d'offre de services d'un fournisseur de contenu, une vérification d'une légitimité d'accès au contenu en fonction d'une offre de services souscrite par l'utilisateur du terminal mobile auprès du fournisseur de contenu, une sélection d'une application correspondant au service requis, à installer sur le terminal fixe, en fonction de données de profil du terminal fixe, une adaptation de l'application par le serveur de gestion d'offre en fonction de données de configuration de l'utilisateur relatives au service, une installation sur le terminal fixe de l'application téléchargée sur le terminal mobile. L'identifiant du terminal mobile correspond à l'identifiant attribué par l'opérateur mobile à l'utilisateur lors de la souscription d'une offre de communication avec un terminal mobile. Cet identifiant est connu sous l'acronyme MSISDN dans les standards GSM et UMTS et est connu plus communément comme étant le numéro de téléphone. Selon ces standards, cet identifiant est embarqué dans la carte SIM qui est inséré dans le terminal mobile. L'identifiant est alors associé au terminal mobile qui embarque la carte SIM. Selon l'invention, la requête d'activation du service part du terminal mobile et est transmise à une plateforme de fourniture de contenu muid média via un réseau d'accès mobile. Cette requête d'activation est paramétrée avec des données récupérées préalablement par le terminal mobile auprès du terminal fixe lors d'une phase de découverte. La plateforme vérifie l'éligibilité de l'accès à partir du terminal fixe au contenu en fonction de l'offre souscrite par l'utilisateur. La plateforme sélectionne l'application en fonction du terminal fixe. La plateforme adapte l' application à installer sur le terminal fixe pour accéder au contenu muid média en tenant compte d'une configuration personnelle de l'utilisateur relative au service demandé. L'utilisateur n' a pas besoin d'intervenir sur le terminal fixe, l'application est téléchargée sur le terminal mobile puis installée sur le terminal fixe, typiquement via une communication courte distance entre le terminal mobile et le terminal fixe. Ainsi, quel que soit le lieu où se situe le terminal fixe, sous réserve que celui-ci ait une connectivité IP, l'utilisateur du terminal mobile peut visualiser sur ce terminal fixe les services muid media d'une offre souscrite auprès d'un fournisseur de contenu tout en bénéficiant automatiquement sur ce terminal fixe de ses données de configuration. Ces données de configuration peuvent provenir des préférences de l'utilisateur enregistrées dans un profil associé à son terminal mobile ou éventuellement associé à un autre terminal fixe et/ou de données liées à l'usage de ce service par l'utilisateur. Ainsi, l'utilisateur n'est plus contraint de configurer manuellement le terminal fixe pour retrouver sa configuration personnelle. Selon l'invention, le terminal mobile est utilisé comme un terminal personnel de confiance afin de configurer de manière sécurisée pour l'utilisateur l'accès à son offre de contenu sur un nouveau terminal fixe. En outre, l'utilisateur peut privilégier l'utilisation de son terminal mobile pour s' abonner à de nouveaux services de contenu qui seront rendus disponibles sur un terminal fixe TV, en lançant une mise à jour de son offre de services. Le terminal mobile peut être ainsi utilisé comme terminal personnel privilégié pour des actions de souscription à des offres de contenu. Ces offres de contenus peuvent alors être délivrées sur un terminal fixe pour leur visualisation. Selon un mode de réalisation, le procédé d'accès à un contenu muid media est tel que : la phase de découverte comprend en outre une mémorisation par le terminal mobile de caractéristiques du réseau d'accès fixe, le terminal mobile transmet en outre les caractéristiques du réseau d'accès fixe au serveur de gestion d'offre de services du fournisseur de contenu, le terminal fixe ayant une adresse IP adressable via le système de télécommunication. Ce mode est plus particulièrement adapté lorsque le terminal fixe accède au système de télécommunication via un fournisseur d'accès internet (FAI) et que ce fournisseur d'accès est capable de fournir des données sur l'infrastructure du réseau d'accès fixe au moyen par exemple du protocole TR-69 défini par le Broadband Forum entre le terminal fixe et un serveur de l'opérateur du réseau d'accès. La mise en oeuvre de la récupération de ces données par le terminal mobile auprès du terminal fixe peut se faire en utilisant le protocole UPnP et la fonction Discovery. Plus particulièrement, le message SSDP Notify peut être renseigné de données du réseau d'accès fixe telles que latence, gigue et perte de paquets. Les données du réseau d'accès fixe peuvent être utilisées par le serveur de gestion d'offre pour déterminer si l'offre de services souscrite par l'utilisateur rend éligible le service demandé dans un contexte d'activation sur le terminal fixe. Selon un mode de réalisation, le procédé d'accès à un contenu muid media est tel que la requête d'activation est transmise depuis le terminal mobile via un réseau d'accès mobile cellulaire, et le procédé comprend en outre : la substitution par le réseau d'accès mobile d'un identifiant du terminal mobile présent dans la requête d'activation par un identifiant connu du fournisseur de contenu. Les réseaux d'accès mobiles de type cellulaire insèrent automatiquement l'identifiant du terminal mobile dans la requête d'activation, ie l'identifiant de l'utilisateur attribué par l'opérateur mobile lors de la souscription d'une offre de communication avec un terminal mobile. Ce mode est plus particulièrement adapté lorsque l'opérateur mobile et le fournisseur de contenu sont des entités économiques différentes. En ne transmettant qu'un alias de l'identifiant mobile au fournisseur de contenu, l'opérateur mobile garantit la confidentialité à l'utilisateur de son identifiant mobile. Cet identifiant correspond généralement au numéro de téléphone associé à ses données de souscription auprès de cet opérateur mobile. Vis-à-vis du fournisseur de contenu, l'opérateur mobile joue le rôle de tiers de confiance dans la gestion d'identité. Selon un mode de réalisation, le procédé d'accès à un contenu muid media est tel que : le serveur de gestion d'offre de services du fournisseur de contenu demande au terminal mobile de s'identifier en l'absence dans la requête d'activation d'un identifiant du terminal mobile. Les réseaux d'accès mobile de type cellulaire insèrent automatiquement l'identifiant du terminal mobile dans la requête d'activation. Ce mode s'applique donc plus particulièrement quand le terminal mobile n'est pas attaché à un réseau d'accès mobile cellulaire mais accède au système de télécommunication via un point d'accès, par exemple de type WiFi qui n'est pas interconnecté au réseau coeur mobile (« 3GPP core network » de la figure 1). Dans ce cas, le réseau d'accès ne sait pas insérer l'identifiant du terminal mobile puisqu'il ne s'agit pas d'un réseau d'accès mobile cellulaire. Selon un mode de réalisation, le procédé d'accès à un contenu mufti media comprend en outre : - la génération par le serveur de gestion d'offre de services du fournisseur de contenu d'une clé de configuration unique à partir d'un identifiant du terminal mobile, à partir des données de profil du terminal fixe et à partir du service requis, - l'insertion dans des paramètres de l'application à télécharger de la clé de configuration et de paramètres de routage pour un accès depuis le terminal fixe au contenu multi media par l'application à télécharger, - une requête d'activation de l'application à partir du terminal fixe paramétrée avec les paramètres de routage et la clé de configuration. Selon ce mode, le fournisseur de contenu génère une clé de configuration à partir de l'identifiant qu'il connait du terminal mobile et qui est associé à l'identité de l'utilisateur, c'est-à-dire soit l'identifiant mobile, soit l' alias de cet identifiant connu du fournisseur de contenu en particulier lorsque ce dernier n'est pas l'opérateur mobile. Cette clé permet d'authentifier et de certifier que la requête d' activation du contenu à partir du terminal fixe est associée au terminal mobile, donc à l'utilisateur qui est identifié avec certitude auprès de l'opérateur mobile. L'opérateur mobile peut donc garantir au fournisseur de contenu l'identité de l'utilisateur qui demande l'activation du service depuis son terminal mobile. Cette authentification et cette certification permettent d'assurer le mécanisme de paiement entre l'utilisateur, l'opérateur, le propriétaire du terminal fixe et le fournisseur de contenu. La génération de la clé est dynamique ce qui offre une très grande souplesse d'utilisation. Les paramètres de routage consistent par exemple en une URL qui pointe sur le portail d' accès au service de contenu sur un serveur de streaming. Ce mode permet une gestion de plusieurs configurations personnelles d'utilisateurs sur un même terminal fixe puisque la clé est fonction de l'identifiant du terminal mobile ie de l'utilisateur. Lors de la mise en route du terminal fixe, il peut être proposé à l'utilisateur de sélectionner un compte utilisateur avec la saisie d'un mot de passe qui permet d'identifier l'utilisateur. Ainsi la sélection du compte peut automatiquement permettre la sélection de la configuration de l'utilisateur pour ce terminal fixe puisque les données de personnalisation sont présentes dans l'application téléchargée. Selon un mode de réalisation, le procédé d'accès à un contenu mufti media comprend en outre : - la mémorisation dans une ou plusieurs bases de données de la clé de configuration et des paramètres de routage avec les données de configuration de l'utilisateur relatives au service dans un profil associé au terminal fixe. Le profil associé au terminal fixe est mémorisé par exemple dans la base de données de profils connue sous l'appellation Device Profile Server. Selon un mode de réalisation, le procédé d'accès à un contenu muid media est tel que le fournisseur de contenu gère une base de données qui contient pour un utilisateur donné, la liste des services souscrits et la liste des services activés par terminal avec la clé de configuration associée au terminal et au service, le procédé comprend en outre : la mise à jour de la base de données avec la clé de configuration générée pour le terminal fixe et le service demandé. Cette base de données permet de connaître la liste des services activés pour un utilisateur donné et par terminal. Elle permet donc de connaître l'ensemble des terminaux configurés pour les services activés de l'utilisateur. Une telle base est avantageuse plus particulièrement pour enrichir le système d'information du fournisseur de contenu et par exemple servir d'aide aux services après- vente lors d'un problème remonté par l'utilisateur. La clé de configuration permet de faire le lien avec la base de données de profils (« Device Profile Server ») pour obtenir les détails du profil d'un terminal donné. Lors de la configuration d'un nouveau terminal, le fournisseur de service peut récupérer un ensemble de préférences de l'utilisateur relatives à ses usages sur chacun des terminaux où il a activé un service donné. Par défaut, les préférences utilisées pour la configuration d'un nouveau terminal fixe sont celles du terminal mobile. Le fournisseur et/ou l'utilisateur peut paramétrer des règles de sélection de préférence parmi ses différentes configurations pour un service donné. Par exemple, une règle peut être de sélectionner les préférences associées à un terminal dont les caractéristiques sont les plus proches de celles du nouveau terminal sur lequel l' activation du service est demandée. Selon un mode de réalisation, le procédé d'accès à un contenu muid media comprend en outre : une transmission depuis le terminal mobile au serveur de gestion d'offre de services du fournisseur de contenu d'une requête de desactivation du service paramétrée avec la clé de configuration. Cette requête permet à l'utilisateur de lancer à son initiative la desactivation du service qu'il a pu activer sur le terminal fixe. Ce mode est particulièrement avantageux pour l'utilisateur dans un contexte où le terminal fixe est celui d'une chambre d'hôtel. L'utilisateur a ainsi la possibilité de contrôler la période pendant laquelle le service auquel il a souscrit auprès d'un fournisseur de contenu est actif. Ainsi, l'utilisateur peut rendre inactif l'accès à ce service à tout moment et plus particulièrement dès qu'il s'absente ou quitte définitivement sa chambre. Selon un mode de réalisation, le procédé d'accès à un contenu muid media comprend en outre : une transmission depuis le serveur de gestion d'offre de services du fournisseur de contenu au terminal fixe d'une requête de desactivation du service paramétrée avec la clé de configuration. Cette requête permet au fournisseur de service de lancer à son initiative la desactivation du service que l'utilisateur a pu activer sur le terminal fixe. Ce mode est particulièrement avantageux pour l'utilisateur dans un contexte où le terminal fixe est celui d'une chambre d'hôtel. Cette requête peut être déclenchée automatiquement lors du paiement par l'utilisateur de sa note d'hôtel. Ce mode assure donc un fonctionnement sécurisé à l'utilisateur en lui assurant un arrêt définitif après son départ de tout accès au service qu'il avait activé même s'il n'a pas pris lui-même l'initiative de desactiver ce service. Selon un mode de réalisation, le procédé d'accès à un contenu muid media comprend en outre : une transmission depuis le terminal mobile au serveur de gestion d'offre de services du fournisseur de contenu d'une requête de mise à jour du service paramétrée avec la clé de configuration. Cette requête permet à l'utilisateur de lancer la mise à jour du service activé. Ce mode est avantageux lorsque le fournisseur de contenu fait évoluer l'offre de services pour ses clients et par exemple enrichie le service déjà souscrit par l'utilisateur. Selon un mode de réalisation, le procédé d'accès à un contenu muid media comprend en outre : la réception par le terminal mobile d'un code de sécurité généré depuis le serveur de gestion d'offre de services du fournisseur de contenu, la fourniture du code de sécurité au terminal fixe, la transmission depuis le terminal fixe du code de sécurité au serveur de gestion d'offre de services du fournisseur de contenu, la transmission d'une requête d'autorisation d'activation du serveur de gestion d'offre de services du fournisseur de contenu au terminal fixe uniquement si le code de sécurité reçu est identique au code généré. Ce mode permet d'ajouter une sécurité supplémentaire au procédé d'accès en interdisant toute activation du service sur le terminal fixe en l'absence de fourniture d'un code de sécurité. Ce code est préalablement généré par le serveur d'offre du fournisseur de contenu et transmis au terminal mobile. La transmission du code au terminal mobile peut se faire par SMS, ou via une notification https. Le code peut ensuite être inséré par exemple via une saisie manuelle par l'utilisateur. Cette saisie peut intervenir à partir d'une télécommande du terminal fixe. La transmission depuis le terminal fixe peut se faire via une requête https. Selon un mode de réalisation, le procédé d'accès à un contenu muid media est tel que la phase de découverte met en oeuvre un lien point à point courte distance entre le terminal mobile et le terminal fixe. La phase de découverte se déroule par exemple selon un protocole UPnP (Universal Plug and Play) en empruntant un lien physique câblé ou sans fil point à point courte distance de type NFC, bluetooth, IR, USB, dongle avec WiFi... qui a pour avantage de limiter la zone de localisation dans laquelle peut se situer le terminal fixe que l'utilisateur peut configurer au moyen de son terminal mobile. La liaison courte distance permet de limiter physiquement le champ des terminaux fixes pouvant être configurés par l'utilisateur au moyen de son terminal mobile. Ceci est en particulier avantageux dans un hôtel puisque cette limitation physique réduit la possibilité de configurer la télévision d'une chambre voisine. Selon un mode de réalisation, le procédé d'accès à un contenu muid media est tel que la phase de découverte comprend une restitution à l'utilisateur de données de profil du terminal fixe pour confirmation par l'utilisateur de la poursuite du procédé avec ce terminal fixe. Cette demande de confirmation donne la possibilité à l'utilisateur de vérifier que le terminal fixe découvert par le terminal mobile est bien celui qu'il a l'intention de configurer. Ce mode est particulièrement avantageux dans un hôtel car il permet à l'utilisateur de vérifier qu'il n'est pas en train de configurer la télévision d'une chambre voisine. La mise en oeuvre peut se faire en utilisant le protocole UPnP et la fonction Discovery. L'utilisation du message SSDP Notify permet de renseigner par exemple la chaine de caractère "terminal TV de la chambre 111". L'affichage du n° de chambre dans lequel est situé le terminal fixe permet à l'utilisateur de s'assurer que son terminal mobile s'appaire au bon terminal fixe (la télévision située dans sa chambre) lors d'une découverte en Wifi. Ce mode réduit très fortement une configuration par erreur du terminal fixe d'une chambre voisine. L'invention a en outre pour objet un module logiciel comportant des instructions de programme telles que leur exécution par un terminal mobile met en oeuvre les étapes suivantes : une phase de découverte d'un terminal fixe à proximité du terminal mobile, comprenant une mémorisation par le terminal mobile de données de profil du terminal fixe, une transmission depuis le terminal mobile d'une requête d'activation d'un service d'accès à du contenu muid media enrichie de données de profil du terminal fixe à destination d'un serveur de gestion d'offre de services d'un fournisseur de contenu, un téléchargement d'une application correspondant au service requis sélectionnée en fonction des données de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, une installation sur le terminal fixe de l'application téléchargée sur le terminal mobile. L'invention a en outre pour objet un support d'informations comportant des instructions de programme adaptées à la mise en oeuvre des étapes suivantes lorsque ledit programme est chargé et exécuté dans un terminal mobile : une phase de découverte d'un terminal fixe à proximité du terminal mobile, comprenant une mémorisation par le terminal mobile de données de profil du terminal fixe, une transmission depuis le terminal mobile d'une requête d' activation d'un service d'accès à du contenu muid media enrichie de données de profil du terminal fixe à destination d'un serveur de gestion d'offre de services d'un fournisseur de contenu, un téléchargement d'une application correspondant au service requis sélectionnée en fonction des données de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, - une installation sur le terminal fixe de l'application téléchargée sur le terminal mobile. L'invention a en outre pour objet, un terminal mobile comprenant un module logiciel avec des instructions de programme telles que leur exécution met en oeuvre les étapes suivantes : une phase de découverte d'un terminal fixe à proximité du terminal mobile, comprenant une mémorisation par le terminal mobile de données de profil du terminal fixe, une transmission depuis le terminal mobile d'une requête d'activation d'un service d'accès à du contenu multi media enrichie des données de profil du terminal fixe à destination d'un serveur de gestion d'offre de services d'un fournisseur de contenu, un téléchargement d'une application correspondant au service requis sélectionnée en fonction des données de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, - une installation sur le terminal fixe de l'application téléchargée sur le terminal mobile. L'invention a en outre pour objet, un terminal fixe comprenant un module logiciel avec des instructions de programme telles que leur exécution met en oeuvre les étapes suivantes : une phase de découverte entre un terminal mobile et le terminal fixe, le terminal mobile étant à proximité du terminal fixe, comprenant une mémorisation par le terminal mobile de données de profil du terminal fixe, une phase d'installation sur le terminal fixe à partir du terminal mobile d'une application téléchargée au préalable sur le terminal mobile, l'application correspondant à un service d'accès à un contenu mufti media sélectionnée en fonction des données de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, une phase d'activation du service d'accès à un contenu mufti media entre le terminal fixe et un serveur de gestion d'offre de services d'un fournisseur du contenu mufti média. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des figures annexées, parmi lesquelles : - la figure 1, déjà commentée en relation avec l'art antérieur, est une illustration de l'architecture générale du réseau 2G/3G (UMTS) avec un coeur de réseau GPRS impliquée dans des services de streaming en référence au standard 3GPP TS 26 233, la figure 2, déjà commentée en relation avec l'art antérieur, est une illustration de l'architecture générale du réseau 2G/3G/4G avec un coeur de réseau EPC impliquée dans des services de streaming en référence au standard 3GPP TS 26 233, la figure 3, déjà commentée en relation avec l'art antérieur, est une illustration de l'architecture logique système du mécanisme de négociation des capacités mise en oeuvre dans un service de streaming PSS en référence au standard 3GPP TS 26 233, la figure 4, déjà commentée en relation avec l'art antérieur, est une représentation schématique du contenu d'un profil équipement d'un serveur de profils conforme au standard 3GPP TS 26 233, la figure 5 est une représentation schématique du contenu d'un profil équipement enrichi selon l'invention, - la figure 6 est un schéma de différents profils équipement enrichis avec les liens respectifs avec une base de données de services souscrits et de services actifs pour un utilisateur, selon l'invention, la figure 7 représente les différentes entités mises en jeu selon un premier mode de mise en oeuvre d'un procédé selon l'invention, - les figures 8-10 sont des schémas de principe des échanges (cati flow) entre les différentes entités représentées à la figure 7 selon un mode de réalisation d'un procédé selon l'invention, la figure 11 représente les différentes entités mises en jeu selon un deuxième mode de mise en oeuvre d'un procédé selon l'invention, - les figures 12-14 sont des schémas de principe des échanges (cati flow) entre les différentes entités représentées à la figure 11 selon un mode de réalisation d'un procédé selon l'invention, la figure 15 est un schéma de principe des échanges (cati flow) entre les différentes entités représentées à la figure 11 selon un mode de réalisation d'un procédé selon l'invention, - la figure 16 est un schéma de principe des échanges (cati flow) entre les différentes entitées représentés à la figure 11 selon un mode de réalisation d'un procédé selon l'invention, la figure 17 est un schéma d'une structure simplifiée d'un terminal mobile selon l'invention, la figure 18 est un schéma d'une structure simplifiée d'un terminal fixe selon l'invention. Description de modes de réalisation de l'invention Le principe général de l'invention repose sur l'utilisation d'un terminal mobile comme d'un terminal de confiance avec lequel l'utilisateur peut configurer d'autres terminaux, par exemple fixes pour visualiser des contenus muid media. L'utilisateur a souscrit un abonnement et plus généralement une offre de services auprès d'un opérateur mobile qui lui a attribué en retour un numéro d'appel. En référence à certains standards comme le GSM, ce numéro d'appel est généralement identique à un identifiant désigné par les acronymes MSISDN. En parallèle, l'utilisateur peut souscrire auprès de fournisseurs de contenu des offres complémentaires et plus généralement supplémentaires. Dans son environnement résidentiel, l'utilisateur peut partager un ou plusieurs terminaux fixes tels des équipements télévisuels (TV) avec des membres de sa famille. Chaque membre peut détenir un terminal mobile personnel. L'utilisateur peut ne pas partager les mêmes préférences ou usages de visualisation de contenu que les membres de sa famille Par suite, il peut être contraint de devoir configurer à chaque fois la TV qu'il utilise à un instant t pour obtenir une configuration qui corresponde à son offre de contenu, qui corresponde à son usage, qui corresponde à ses préférences. Selon un mode de réalisation de l'invention, l'utilisateur a la possibilité de configurer automatiquement un terminal fixe avec ses préférences et ses usages associés à son terminal mobile. Le terminal mobile récupère certains éléments de données du profil du terminal fixe et demande au fournisseur de contenu d'adapter son profil associé à son mobile au terminal fixe à partir des éléments de données du profil du terminal fixe qu'il lui transmet. Ceci permet donc à l'utilisateur d'étendre son offre de contenu à d'autres terminaux accessibles via un réseau fixe. Le standard 3GPP TS 26 234 spécifie un profil illustré par la figure 4 associé à un équipement terminal. Dans le contexe de l'invention, ce profil est utilisé par le service de contenu muid media, il est généralement mémorisé sur un serveur dit « device profil server ». Il est bien entendu que ce serveur peut en réalité correspondre à plusieurs serveurs. Le profil contient des données sur les capacités « matériel » du terminal désignées par les termes « Hardware capabilities », des données sur les capacités « logiciel » désignées par les termes « Software capabilities ». Ces capacités sont enrichies par l'utilisateur ou par le fournisseur de service au moyen de plug-in, désignés par les termes « Hardware/Software plug-in », par exemple une extension de la capacité mémoire, un module logiciel téléchargé. L'utilisateur peut saisir des paramètres classés dans les « User Preferences », par exemple le choix d'un son audio et non stéréo. L'invention se propose d'enrichir le profil d'un équipement avec deux modules, un module routage désigné par les termes « routing policies » et un module avec une clé de configuration désigné par les termes « Configuration key » comme illustré en figure 5. L'invention se propose en outre de gérer une base de données dans laquelle sont mémorisés les services souscrits et les services activés par l'utilisateur sur différents terminaux. La figure 6 représente cette base de données désignée par les termes "liste des services souscrits par l'utilisateur et liste des services activés pour l'utilisateur par terminal"(« subscribed and activated services per user ») ainsi que les différents profils associés à chaque terminal et le lien entre un profil et cette base de données. Selon un mode de réalisation, le système d'information SI gère la base de données "liste des services souscrits par l'utilisateur et liste des services activés pour l'utilisateur par terminal". Ainsi selon ce mode, le système d'information SI donne des éléments de réponse suite à un appel client relatif à un service non disponible. La plateforme de service gère généralement la base de données "device profile server" puisque le module « routing policies » fait référence à des données de configuration relatives à la plateforme de service telle que l'URL ou l'adresse IP pour permettre au terminal l'envoi de ces requêtes de service. Ces deux bases permettent de connaître l'ensemble des terminaux qui sont configurés pour donner l'accès aux services de l'utilisateur. La base de données "liste des services souscrits par l'utilisateur et liste des services activés pour l'utilisateur par terminal" donne la liste des services activés par terminal pour un utilisateur donné. Lors de la configuration d'un nouveau terminal, le fournisseur de service peut récupérer un ensemble de préférences de l'utilisateur relatives aux usages sur chacun des terminaux où les services sont activés. A minima, le fournisseur de service récupère les préférences de l'utilisateur pour le terminal mobile (par exemple smartphone) qui a une souscription active. Ainsi, l'invention permet d'exporter le profil associé à un service du terminal mobile vers un terminal fixe pour visualiser un contenu muid média sur ce terminal fixe. Le terminal mobile sert de terminal de confiance dans l'activation du service sur le terminal fixe. Selon un premier mode de mise en oeuvre de l'invention, l'opérateur mobile et le fournisseur de contenu sont des acteurs différents. Ce mode est détaillé en référence à la figure 7 qui représente les différentes entités mises en jeu et aux figures 8-10 qui sont des schémas de principe des échanges (cati flow) entre les différentes entités lors de l'exécution sur le terminal mobile des instructions de programme d'un module logiciel conforme à un mode de réalisation de l'invention. Le terminal mobile est identifié auprès d'un opérateur mobile OM, le terminal fixe « TV» est localisé par exemple dans un hôtel ou tout autre bâtiment telle une maison, un immeuble. Les terminaux mobiles et fixes sont respectivement accessibles via un réseau d'accès mobile et un réseau d'accès fixe par le système de télécommunication. Les réseaux d'accès mobile et fixe sont désignés par « Ntw » et distingués par deux traits verticaux Mob, Fix. Un fournisseur d'accès FAI autorise l'accès du terminal fixe TV au système de télécommunication via le réseau d'accès fixe. La plateforme d'offre de services PFS comprend un portail mobile TV de l'opérateur mobile OM et un portail TV du fournisseur de contenu FC, quatre traits verticaux lui sont attachés. Les traits référencés FE (Front End) correspondent à des fonctions qui mettent en oeuvre les échanges avec l'utilisateur, les traits référencés BE (Buck End) correspondent aux autres échanges respectivement du portail de l'opérateur mobile et du portail du fournisseur de contenu et le 4' trait correspond à la fonction de gestion des profils. Cette plateforme correspond à un ou plusieurs serveurs. Les serveurs du système d'information sont identifiés par le terme « SI », deux traits verticaux lui sont attachés. Le l' trait correspond au système d'information de l'opérateur mobile OM. Le 2e trait correspond au système d'information du fournisseur de contenu FC. Les séquences Sqx de messages échangés selon le mode de réalisation illustré sont listées ci-après. Sql : séquence «device discovery 0». Cette séquence correspond à la découverte depuis le terminal mobile d'un terminal fixe à proximité via un lien câblé (par exemple USB) ou un lien sans fil (wireless). Cette séquence est par exemple basée sur un protocole UPnP basé sur une notification SSDP. Sq2 : séquence «device_discovery (user agent device type)». Cette séquence correspond à la réponse du terminal fixe vers le terminal mobile. Le terminal fixe transmet des données de son profil tel que « user agent device type » en référence à l'Open Mobile Alliance qui a édité un document référencé User agent profile version 2.0 de février 2006 définissant le profil UAProf d'un agent utilisateur « User Agent Pofile ». Le terminal fixe transmet éventuellement en outre des caractéristiques « fixed access type » du réseau d'accès auquel il est connecté. Cette réponse est basée sur le même protocole que celui utilisé lors de la séquence Sql, par exemple le protocole UPnP. Sq3 : séquence «activation_request (mobile type, TV device type, service type)». Cette séquence correspond à la demande d'activation d'un service d'accès à du contenu muid media émise depuis le terminal mobile à destination du fournisseur de contenu. Elle contient des données sur le terminal mobile (mobile type), sur le terminal fixe (TV device type) ainsi que sur le service demandé (service type). Eventuellement elle contient des données sur le réseau d'accès fixe (fixed access type). Sq4 : séquence «activation_request enrichment (+0M_UI)». Cette séquence correspond à l'insertion de l'identifiant mobile du terminal mobile par le réseau d'accès mobile dans la requête d'activation « activation_request » émise par le terminal mobile. Cet identifiant est connu sous les acronymes MSISDN dans le cas d'un réseau d'accès 2G ou 3G (GSM, UMTS). Une telle séquence n'existe pas dans le cas d'un réseau d'accès sans fil, par exemple de type WiFi, non interconnecté avec le réseau coeur mobile (aussi appelé « 3GPP Core Network » en figure 1). Sq5 : lors des séquences 5.1, 5.2, 5.3, 5.4 les ressources de l'opérateur mobile OM analyse la requête de l'utilisateur. Sq5.1 : séquence « activation_request (TV device type, OM_UI, service type). Cette séquence correspond au passage de la requête d'activation entre les applications FE de la partie de la plateforme sous contrôle de l'opérateur mobile qui échangent avec les terminaux et les applications BE qui traitent les requêtes transmises par les applications FE pour traitement. Sq5.2 : séquence «Aliasing_request (service type, OM_UI)». Cette séquence depuis la partie de la plateforme sous contrôle de l'opérateur mobile à destination de son système d'information SI M correspond à la demande d'obtention d'une identité alias connue du fournisseur de contenu. Cet alias permet à l'opérateur de garantir à l'utilisateur que son identité mobile n'est pas communiquée au fournisseur de contenu. En outre, il permet à l'opérateur mobile de jouer le rôle de garant auprès du fournisseur de contenu en ce qui concerne l'identité de l'utilisateur qui invoque le service demandé. Sq5.3 : séquence «Aliasing_response (FC_UI)». Cette séquence en réponse au message précédent contient l'alias FC_UI connu du fournisseur de contenu de l'identité mobile OM_UI de l'utilisateur du terminal mobile. Sq5.4 : séquence « activation_request (TV device type, FC_UI, service type). Cette séquence correspond au passage de la requête d'activation de la séquence Sq5.1 entre la partie de la plateforme sous contrôle de l'opérateur mobile et la partie de la plateforme sous contrôle du fournisseur de contenu, la requête est transmise entre deux acteurs différents. Par suite, la séquence contient les paramètres/données nécessaires pour analyser la demande en fonction de l'offre de services souscrite par l'utilisateur auprès du fournisseur de contenu. La séquence contient ainsi le type de terminal fixe (TV device type), le service demandé (service type) et l'alias (FC_UI). Eventuellement, la séquence contient le type d'accès fixe (fixed access type). Sq6 : lors des séquences 6.1, 6.2 le fournisseur de contenu FC analyse la requête de l'utilisateur. Sq6.1 : séquence « fetch_subscribed_offer_data (FC_UI) » entre la plateforme PFS TV et le système d'information SI, dans l'environnement du fournisseur de contenu. La plateforme d'offre de services PFS TV interroge le système d'information SI du fournisseur de contenu pour obtenir en retour les données sur l'offre souscrite par l'utilisateur. Les échanges contiennent l'alias FC_UI. La plateforme récupère les services souscrits et l'ensemble des clés de configuration actives (configuration_keys) pour l'utilisateur FC_UI. 5q6.2 : séquence « fetch_device_capabilities (TV device type) » entre la partie de la plateforme PFS TV sous contrôle du fournisseur de service et une base de données d'équipements de différents fabricants. Lors de cet échange, la plateforme récupère les caractéristiques des moyens matériels et logiciels (device capabilities) dont bénéficie le terminal fixe. 5q6.3 étape «Check eligibility { subscribed offer, device capabilities }». Cette étape correspond à la vérification par la plateforme d'offre de services PFS TV de l'éligibilité de l'offre de service souscrite dans le contexte d'une activation du service sur le terminal fixe à partir des caractéristiques des moyens matériels et logiciels « device capabilities » dont bénéficie le terminal fixe. En fonction de ces moyens, la plateforme détermine si le terminal a les ressources suffisantes pour le service demandé. La vérification est effectuée dans l'environnement du fournisseur de contenu. 5q6.4 : séquence « activation_response(FC_UI) ». Cette séquence depuis la partie de la plateforme de service qui dépend du fournisseur de contenu est destinée au terminal mobile identifié par son alias. La plateforme d'offre de services PFS TV indique à l'utilisateur le statut du procédé. En fonction de l'offre souscrite et des caractéristiques du terminal fixe (TV device type), l'accès au service peut être refusé (access denied), l'accès au service peut être restreint (restricted access) ou l'accès au service peut être autorisé (installation under progress). 5q6.5 : étape « Aliasing (FC_UI, OM_UI) ». Lors de cette étape, la partie de la plateforme sous contrôle de l'opérateur mobile remplace l' alias par l'identité mobile de l'utilisateur. Sq6.6 : séquence « activation_response (0M_UI)». Cette séquence correspond à la séquence Sq6.3 avec l'identité du mobile au lieu de l'alias. Elle est en réponse à la séquence Sq3. Cet échange Sq6.5-Sq3 peut utiliser le protocole http. Sq6.7 : séquence « user service request for application download ( ) ». Cette séquence depuis le terminal mobile vers le fournisseur de contenu est une requête pour obtenir l'application à télécharger correspondant au service requis. Sq6.8 : séquence « Fetch user preferences (configuration_keys) » entre la partie de la plateforme PFS TV sous contrôle du fournisseur de service et la base de données de profils « Profile server ». En interrogeant la base de données de profils à partir du/des paramètre(s) « configuration_keys », la plateforme peut récupérer les préférences d'usage de l'utilisateur pour chacun des terminaux où le service demandé est actif. Sq7 : étape « application selection {device capabilities, OS, service type... } ». Cette étape correspond à la sélection par la plateforme PFS TV de l'application à télécharger sur le terminal mobile en fonction des capacités du terminal fixe et de l'offre muid média TV souscrite par l'utilisateur ainsi que le type de service demandé par l'utilisateur pour le terminal fixe TV. Sq8 : étape « routing policies selection » Lors de cette étape la plateforme PFS TV configure les paramètres de routage de l' application en fonction des capacités du terminal fixe. Cela correspond typiquement au paramétrage de l'URL de la plateforme (URL du Front End de la plateforme PFS TV qui est sous le contrôle du fournisseur de contenu) qui devient accessible au terminal fixe après téléchargement et installation via le terminal mobile. Ces paramètres de routage (routing policies) permettent au terminal fixe d' accéder au serveur du fournisseur de contenu pour la visualisation du contenu sur ce terminal. Sq9 : étape « service personalization ». Lors de cette étape, la plateforme PFS TV prend en compte les données de personnalisation (préférences d'usage) qui vont être exportées sur le terminal fixe. Les données incluent l'ensemble des données de personnalisation des services de l'utilisateur ainsi que des données d'usage connues de la plateforme PFS TV. En pratique, ces données peuvent correspondre à des cookies qui intègrent des préférences d'usages, des données de configuration et des données d'identité d'authentification implicite. Eventuellement, une pondération est effectuée pour donner une importance plus importante pour des usages associés à des terminaux de type proche de celui du terminal fixe. Par défaut, la plateforme prend en compte les usages antérieurs sur le terminal mobile (typiquement de type smartphone). Sql0 : étape « configuration_Key generation». Cette étape correspond à la génération par la plateforme PFS TV de la clé de configuration unique Configuration-Key à partir de l'alias FC_UI connu du fournisseur de contenu, de caractéristiques du terminal fixe déterminées à partir du type de terminal (TV device type) et du service demandé. Cette clé est utilisée à plusieurs fins : -durant la suite de la configuration du terminal TV fixe, ce dernier insère cette clé qui permet à la PFS TV de reconnaitre le contexte de configuration notamment en séquence Sq13, -durant l'usage du service, cette clé de configuration est présente dans les deux bases de données ("liste des services souscrits par l'utilisateur et liste des services activés pour l'utilisateur par terminal" et "device profile server") et permet au fournisseur de service de s'assurer que les données de configuration du terminal TV (« routing policies ») sont en cohérence avec les services souscrits et activés sur le terminal TV. La vérification de cette cohérence est notamment nécessaire en cas de notification par l'utilisateur de problème d'accès aux services de contenu. Sq.10bis : séquence "writing of configuration parameters in DB» de la plateforme vers les bases de données DB de profil et de services souscrits et de services activés, dans l'environnement du fournisseur de contenu. Cette séquence correspond à l'écriture des paramètres de configurations dans les bases de données Profile server et subscribed services, donc plus particulièrement les paramètres de routage (routing policies) et la clé de configuration (configuration_key). Sq11.1 : séquence « application_download (software, personalized preferences, FC_UI, routing policies, configuration key) » depuis la plateforme PFS TV à destination du terminal mobile. Cette séquence correspond au téléchargement sur le terminal mobile de l'application à installer sur le terminal fixe. Le téléchargement inclut le logiciel (software), les données de personnalisation (par exemple les chaînes Live favorites, VoD boolçmarkés, les liens de réseaux sociaux, la page d'accueil personnalisée (welcome screen personalisé)), l'alias FC_UI, les paramètres de routage (routing policies), la clé de configuration (configuration key). La clé de configuration permet l'authentification implicite de l'utilisateur pour les services du fournisseur de contenu. L'ajout de l' alias FC_UI connu du fournisseur de contenu à l'application à télécharger sur le terminal fixe permet de gérer plusieurs comptes sur le terminal fixe à partir de la page d' accueil des services du fournisseur de contenu. Sq11.2 : étape « Aliasing (FC_UI, OM_UI) ». Lors de cette étape, la partie de la plateforme sous contrôle de l'opérateur mobile remplace l' alias par l'identité mobile. Elle est similaire à l'étape 5q6.4. Sq11.3 : séquence « application_download (software, personalized preferences, OM_UI, routing policies, configuration key) ». Cette séquence correspond à la séquence Sq11.1 avec remplacement de l' alias par l'identifiant du terminal mobile. Cette séquence est en réponse à la séquence 5q6.7. Cet échange Sq6.7-Sq11.3 peut utiliser le protocole http. 5q12 : séquence « application install ». Cette séquence correspond à l'installation sur le terminal fixe de l'application TV téléchargée depuis le terminal mobile. Cette séquence est par exemple basée sur un protocole UPnP. Sql3 : séquence « activation_request (configuration_key) ». Cette séquence correspond à une demande d'activation du service depuis le terminal fixe à destination de la partie de la plateforme sous contrôle du fournisseur de contenu. Cette séquence peut être basée sur un protocole https. Sq14 : les séquences 14.1-14.4 correspondent à une exigence du fournisseur de contenu FC d'effectuer une dernière vérification avant l'activation du service. Ce jeu de séquences reste optionnel. Sq14.1 : séquence « Security code generation (Secure_code, FC_UI) depuis la partie de la plateforme sous contrôle du fournisseur de contenu vers la partie sous contrôle de l'opérateur mobile. Cette séquence contient un code (Secure_code) et 1' alias de l'utilisateur. Sq14.2 : étape « Aliasing (FC_UI, OM_UI) ». Lors de cette étape, la partie de la plateforme sous contrôle de l'opérateur mobile remplace 1' alias par l'identité mobile. Elle est similaire à l'étape Sq6.5 et à l'étape Sq11.2. Sq14.3 : séquence « Security code transfer (Secure_code) ». Cette séquence correspond à la transmission de la séquence Sq14.1 depuis la partie de la plateforme sous contrôle de l'opérateur mobile à destination du terminal mobile. Cette séquence peut être basée sur un mécanisme de type « push API ». A ce stade, l'utilisateur du terminal mobile doit saisir sur le terminal fixe le code reçu sur son terminal mobile. Sq14.4 : séquence « Security code insertion (Secure_code, configuration_key) » depuis le terminal fixe à destination du fournisseur de contenu. Compte tenu que le terminal fixe connait les paramètres de routage (routing policies) et la clé de configuration, il transmet le code saisi avec la même clé de configuration et en utilisant les paramètres de routage pour pointer sur le fournisseur de contenu. Cette séquence peut être basée sur un protocole https. La réception d'un code saisi identique au code émis termine la dernière vérification par le fournisseur de contenu. Sq15.1 : séquence « account_activation (configuration_key) ». Cette séquence correspond à l'activation du compte demandée par la plateforme de service au système d'information SI du fournisseur de contenu. 5q15.2 : séquence « successful_activation (configuration_key) » entre applications BE et FE de la partie de la plateforme sous contrôle du fournisseur de contenu. 5q15.3 : séquence « activation_response (configuration_key) » depuis la partie de la plateforme sous contrôle du fournisseur de contenu à destination du terminal fixe. Cette séquence correspond à la réponse à la séquence 5q13. L'échange 5q13-5q15.3 peut être basé sur un protocole http ou https. 5q15.4 : séquence «successful_activation» depuis la plateforme PFS à destination du terminal mobile. Cette séquence est destinée à informer le terminal mobile du succès de l'activation. Cette séquence contient 1' alias de l'utilisateur. 5q15.5 : étape « Aliasing (FC_UI, OM_UI) ». Cette séquence est similaire à la séquence Sq14.2. 5q15.6 : séquence « user notification ( ) » depuis la partie de la plateforme sous contrôle de l'opérateur mobile. Le message de notification contient l'identifiant mobile de l'utilisateur. La notification au terminal mobile peut inclure une indication que le service est disponible (service available). Cette séquence peut être basée sur un mécanisme de type « push API ». Selon un deuxième mode de mise en oeuvre, l'opérateur mobile et le fournisseur de contenu sont vus comme un seul acteur. La figure 11 illustre les différentes entités. Le principe des échanges reste celui décrit pour le premier mode. Certains échanges disparaissent compte tenu qu'il n'y a plus de distinction entre l'opérateur mobile et le fournisseur de mobile. Il n'y a plus selon ce mode d'utilisation d'alias, seul l'identifiant mobile 0M_UI est utilisé. Les figures 12, 13 et 14 sont des schémas de principe des échanges selon le mode de réalisation. Selon un mode de réalisation, l'utilisateur peut demander une mise à jour de son offre de services à destination de son terminal TV fixe, à partir de son terminal mobile comme la souscription à de nouveaux services TV ou le désabonnement à certains contenus. Cette demande peut nécessiter la mise à jour de l'application installée sur le terminal TV fixe. Ce mode est détaillé en référence à la figure 15 qui est un schéma de principe des échanges (call flow) entre les précédentes entités lors de l'exécution sur le terminal mobile des instructions de programme d'un module logiciel conforme au mode de réalisation de l'invention. Sq101 : séquence « update_account_request (configuration_key, requested_services)» depuis le terminal mobile à destination du fournisseur de contenu. Cette séquence correspond à la demande de mise à jour émise par le terminal mobile. Le message émis contient la clé de configuration associée au profil du terminal fixe. Il contient en outre les services à mettre à jour (requested_services). L'envoi du paramètre «Configuration_Key » permet de savoir quel profil de service est à mettre à jour lorsque plusieurs comptes appartenant à différents utilisateurs sont activés sur un même terminal TV fixe. 5q102 : séquence « update_account_request enrichment (+0M_UI)» par le réseau d'accès mobile à destination de la plateforme d'offre de services PFS TV du fournisseur de contenu. Cette séquence est similaire à la séquence 5q4 du premier mode. 5q103 : séquence « update_account_request (0M_UI, requested_services)» entre la plateforme PFS et le système d'information SI. La plateforme d'offre de services PFS interroge le système d'information SI du réseau mobile pour obtenir en retour les données mises à jour sur l'offre mobile souscrite par l'utilisateur. Les messages échangés contiennent l'identifiant du terminal mobile (0M_UI). 5q104 : étape « Check of Compatibility (subscribed offer, device capabilities) ». Cette étape correspond à la vérification par la plateforme d'offre de services PFS de la compatibilité de l'offre souscrite mise à jour dans le contexte d'une activation sur le terminal fixe. Cette étape est similaire à l'étape 5q6.3 du premier mode. 5q105 : étape « application update (device capabilities, OS,...). Cette étape optionnelle correspond à la mise à jour de la sélection par la plateforme PFS de l'application à télécharger sur le terminal en fonction des capacités du terminal fixe et de l'offre muid média mise à jour souscrite par l'utilisateur. Sq106 : étape « routing policies update». Lors de cette étape optionnelle la plateforme PFS met à jour les paramètres de routage de l'application. Cela correspond typiquement à la mise à jour du paramétrage de l'URL de l'application FE de la plateforme (i.e. URL qui permet au terminal TV fixe d'accéder à cette mise à jour des services) qui devient accessible au terminal fixe après téléchargement. Ces paramètres de routage (routing policies update) permettent au terminal fixe d'accéder au serveur du fournisseur de contenu pour la visualisation du contenu sur ce terminal associé à la mise à jour de la souscription. Sq107 : étape « service personalization update». Lors de cette étape optionnelle, la plateforme PFS met à jour les données de personnalisation (notamment issues des usages antérieurs sur le terminal mobile) qui vont être exportées sur le terminal fixe. Sq108 : étape « configuration_Key generation update». Cette étape optionnelle correspond à la mise à jour par la plateforme PFS de la clé de configuration unique Configuration-Key à partir de l'identifiant OM_UI du terminal mobile, de caractéristiques du terminal fixe déterminées à partir du type de terminal (device type) et de la mise à jour du service demandé. Sq108bis : séquence "writing of configuration parameters in databases » de la plateforme vers les bases de données de profil et de services souscrits. Cette séquence correspond à la mise à jour des paramètres de configurations dans les bases de données Profile server et subscribed services. Cette séquence est similaire à la séquence SqlObis du premier mode. Sq109 : séquence « application_download (personalized preferences, OM_UI, routing policies, configuration key) » depuis la plateforme PFS à destination du terminal mobile. Cette séquence optionnelle correspond au téléchargement sur le terminal mobile de la mise à jour de l'application déjà installée sur le terminal fixe. Le téléchargement inclut les données de personnalisation (chaînes Live favorites, VoD bookmarkés, liens réseaux sociaux, welcome screen personalisé) mises à jour, l'identifiant du terminal mobile OM_UI, les paramètres de routage (routing policies) mis à jour, la clé de configuration (configuration key) mise à jour. Cette séquence est similaire à la séquence Sq11.3 du premier mode. Sq109bis : séquence « application install ». Cette séquence correspond à l'installation sur le terminal fixe des mises à jour de l'application déjà téléchargée depuis le terminal mobile relative au service demandé. Cette séquence est similaire à la séquence 5q12 du premier mode. Sq110 : séquence « application_update» (configuration_key). Cette séquence optionnelle correspond au statut (successful/non successful) de la mise à jour de l'offre de service transmise depuis le terminal fixe à destination de la plateforme de services PFS. Sq111 : séquence « account_update ». Cette séquence correspond à la mise à jour du compte demandée par la plateforme de service au système d'information SI du fournisseur de contenu. Sq112 : séquence « user_notification (en option : account update) » depuis la plateforme PFS à destination du terminal mobile. Cette séquence correspond à une notification de la mise à jour vers le terminal mobile. Selon un mode de réalisation, l'utilisateur peut obtenir une mise à jour de son offre de service à partir d'un terminal fixe sur lequel un service de son offre est déjà activé. Ce mode est détaillé en référence à la figure 16 qui est un schéma de principe des échanges (cati flow) entre les précédentes entités lors de l'exécution sur les terminaux fixe et mobile des instructions de programme d'un module logiciel conforme au mode de réalisation de l'invention. 5q201 : séquence « update_account_request (configuration_key, requested_services)» depuis le terminal fixe à destination du fournisseur de contenu. Cette séquence correspond à la demande de mise à jour émise par le terminal fixe. Cette séquence est similaire à la séquence Sq101 de mise à jour à partir du terminal mobile. 5q202 : séquence « user notification (0M_UI, requested_services)» par le réseau d'accès mobile à destination du terminal mobile. Cette séquence correspond à une demande d'autorisation du terminal mobile pour poursuivre dans la mise à jour. Sq202bis : séquence « user confirmation ». Cette séquence est une réponse à la séquence Sq202. 5q203 : séquence « update_account_request (0M_UI, requested_services)» entre la plateforme PFS et le système d'information SI. Cette séquence est similaire à la séquence 5q103 du mode de mise à jour à partir du terminal mobile. 5q204 : étape « Check of Compatibility (subscribed offer, device capabilities) ». Cette séquence est similaire à la séquence 5q104 du mode de mise à jour à partir du terminal mobile. 5q205_Sq208bis : Ces séquences sont similaires aux séquences 5q105_Sq108bis du mode de mise à jour à partir du terminal mobile. 5q209 : séquence « application_download (personalized preferences, 0M_UI, routing policies, configuration key) » depuis la plateforme PFS à destination du terminal fixe. Cette séquence correspond au téléchargement sur le terminal fixe de la mise à jour de l'application déjà installée sur le terminal fixe. Le téléchargement inclut les données de personnalisation (chaînes Live favorites, VoD boolçmarkés, liens réseaux sociaux, welcome screen personalisé) mises à jour, l'identifiant du terminal mobile 0M_UI, les paramètres de routage (routing policies) mis à jour, la clé de configuration (configuration key) mise à jour. 5q210_5q212 : Ces séquences sont similaires aux séquences Sql1O_Sq112 du mode de mise à jour à partir du terminal mobile. La structure simplifiée d'un terminal mobile selon l'invention mettant en oeuvre un procédé d'accès à un contenu muid media selon l'invention est décrite ci-après et illustrée par la figure 17. Un tel terminal TM comprend une antenne ANT, une chaîne d'émission/réception E/R_IR pour l'émission/réception d'un signal selon une technologie courte distance, une chaîne d'émission/réception E/R_Rw pour l'émission/réception d'un signal selon une technologie radio, une mémoire MEM_TM comprenant une mémoire tampon RAM, une unité de traitement uP_TM équipée par exemple d'un microprocesseur et pilotée par un programme d'ordinateur Pg_TM pour une mise en oeuvre d'un procédé d'accès à un contenu muid media selon l'invention. A l'initialisation ou suite à une entrée de l'utilisateur via une interface homme machine (IHM), les instructions de code du programme d'ordinateur Pg_TM sont par exemple chargées dans la mémoire tampon avant d'être exécutées par le processeur de l'unité de traitement uP_TM. Le microprocesseur de l'unité de traitement uP_TM met en oeuvre en particulier les étapes suivantes selon les instructions du programme d'ordinateur Pg_TM, en coopérant avec les différents moyens du terminal : une phase de découverte Sql, Sq2 d'un terminal fixe TV à proximité du terminal mobile TM, comprenant une mémorisation par le terminal mobile de données de profil (device type) du terminal fixe, une transmission Sq3 depuis le terminal mobile d'une requête d'activation d'un service d'accès à du contenu muid media enrichie de données (device type) de profil du terminal fixe à destination d'un serveur (PFS TV) de gestion d'offre de services d'un fournisseur de contenu FC, un téléchargement Sq11.3 d'une application correspondant au service requis sélectionnée en fonction des données (device type) de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, une installation 5q12 sur le terminal fixe de l'application téléchargée sur le terminal mobile. Le terminal mobile peut mettre en oeuvre d'autres étapes en particulier celles détaillées dans les modes de réalisation préalablement décrits. Le moyen d'émission/réception E/R_IR coopère avec l'unité de traitement uP_TM plus particulièrement lors des phases de découverte et d'installation. Le moyen d'émission/réception E/R_Rw et l'antenne ANT coopèrent avec l'unité de traitement uP_TM plus particulièrement lors des phases de transmission et de téléchargement. La structure simplifiée d'un terminal fixe selon l'invention mettant en oeuvre un procédé d'accès à un contenu muid media selon l'invention est décrite ci-après et illustrée par la figure 18. Un tel terminal TV comprend une antenne ANT_TV, une chaîne d'émission/réception E/R_HF pour la réception d'un signal de télévision (conforme à un standard de diffusion par exemple de type DVB-T, DBT-T2, etc) transmis par exemple en HF, VHF, une chaîne d'émission/réception E/R_IR pour l'émission/réception d'un signal selon une technologie courte distance, une chaîne d'émission/réception E/R_IP pour l'émission/réception de messages selon un protocole IP, par exemple transmis en ADSL, une mémoire MEM_TV comprenant une mémoire tampon RAM, une unité de traitement uP_TV équipée par exemple d'un microprocesseur et pilotée par un programme d'ordinateur Pg_TV pour une mise en oeuvre d'un procédé d' accès à un contenu muid media selon l'invention. A l'initialisation ou suite à une entrée de l'utilisateur via une interface homme machine (IHM), les instructions de code du programme d'ordinateur Pg_TV sont par exemple chargées dans la mémoire tampon avant d'être exécutées par le processeur de l'unité de traitement ttP_TV. Le microprocesseur de l'unité de traitement ttP_TV met en oeuvre en particulier les étapes suivantes selon les instructions du programme d'ordinateur Pg_TV, en coopérant avec les différents moyens du terminal : une phase de découverte Sql, Sq2 entre un terminal mobile TM et le terminal fixe TV, le terminal mobile étant à proximité du terminal fixe, comprenant une mémorisation par le terminal mobile de données de profil « device type » du terminal fixe, une installation Sq12 sur le terminal fixe à partir du terminal mobile d'une application téléchargée (Sq11.3) au préalable sur le terminal mobile, l'application correspondant à un service d'accès à un contenu muid media sélectionnée en fonction des données (device type) de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, une phase d'activation 5q13, 5q15.3 du service d'accès à un contenu multi media entre le terminal fixe et un serveur de gestion d'offre de services d'un fournisseur du contenu muid média. Le terminal fixe peut mettre en oeuvre d' autres étapes en particulier celles détaillées dans les modes de réalisation préalablement décrits. Le moyen d'émission/réception E/R_IR coopère avec l'unité de traitement ttP_TV plus particulièrement lors des phases de découverte et d'installation. Le moyen d'émission/réception E/R_IP coopère avec l'unité de traitement ttP_TV plus particulièrement lors de la phase d'activation. Bien que dans le contexte de la description de l'invention, il soit effectué une distinction entre un terminal fixe et un terminal mobile, le procédé d'accès selon l'invention est totalement compatible d'une mise en oeuvre avec un terminal mobile en lieu et place du terminal fixe. Dans les revendications de procédé, il faut donc comprendre que les mots « terminal fixe » peuvent être remplacés par les mots « terminal mobile ». Ce dernier doit alors être considéré comme un second terminal mobile. REVENDICATIONS1. Procédé d'accès à un contenu mufti media accessible via un système de télécommunication, initialisé depuis un terminal mobile identifié (0M_UI) auprès d'un opérateur mobile (OM), caractérisé en ce que le procédé comprend : une phase de découverte (Sql, Sq2) par le terminal mobile d'un terminal fixe (TV) à proximité, comprenant une mémorisation par le terminal mobile de données de profil (device type) du terminal fixe, une transmission (Sq3, Sq4, Sq5.1, Sq5.2, Sq5.3, Sq5.4) depuis le terminal mobile à un serveur (PFS TV) de gestion d'offre de services d'un fournisseur de contenu (FC) d'une requête d'activation d'un service d'accès à du contenu mufti media enrichie de données (device type) de profil du terminal fixe, une vérification (Sq6, Sq6.1, Sq6.2, Sq6.3, Sq6.4, Sq6.5, Sq.6.6) d'une légitimité d'accès au contenu en fonction (Sq6.1) d'une offre de services souscrite par l'utilisateur du terminal mobile auprès du fournisseur de contenu (FC), une sélection (Sq7) d'une application correspondant au service requis, à installer (Sq12) sur le terminal fixe, en fonction de données (Sq6.2) de profil du terminal fixe, une adaptation (Sq 9) de l'application par le serveur de gestion d'offre en fonction de données de configuration de l'utilisateur relatives au service, une installation (Sq12) sur le terminal fixe de l'application téléchargée (Sq11.1, Sq11.2, Sq11.3) sur le terminal mobile. 2. Procédé d'accès à un contenu mufti media selon la revendication 1 dans lequel : la phase de découverte (Sql, 5q2) comprend en outre une mémorisation par le terminal mobile de caractéristiques (access type) du réseau d'accès fixe, le terminal mobile transmet en outre les caractéristiques du réseau d'accès fixe au serveur de gestion d'offre de services du fournisseur de contenu (FC), le terminal fixe (TV) ayant une adresse IP adressable via le système de télécommunication. 3. Procédé d'accès à un contenu multi media selon l'une des revendications 1 à 2 dans lequel la requête d'activation est transmise depuis le terminal mobile via un réseau d'accès mobile cellulaire, comprenant en outre : la substitution (5q5.2, 5q5.3) par le réseau d'accès mobile d'un identifiant (0M_UI) du terminal mobile présent dans la requête d'activation par un identifiant (FC_UI) connu du fournisseur de contenu. 4. Procédé d'accès à un contenu multi media selon l'une des revendications 1 à 2 dans lequel : le serveur (PFS TV) de gestion d'offre de services du fournisseur de contenu demande au terminal mobile de s'identifier en l'absence dans la requête d'activation d'un identifiant du terminal mobile (0M_UI). 5. Procédé d'accès à un contenu muid media selon l'une des revendications 1 à 4 comprenant enoutre : la génération (Sq10) par le serveur de gestion d'offre de services du fournisseur de contenu d'une clé de configuration unique à partir d'un identifiant (0M_UI, FC_UI) du terminal mobile, à partir des données (device type) de profil du terminal fixe et à partir du service requis, l'insertion dans des paramètres de l'application à télécharger de la clé de configuration et de paramètres de routage (routing policies) pour un accès depuis le terminal fixe au contenu muid media par l'application à télécharger, une requête d'activation (Sq13) de l'application à partir du terminal fixe paramétrée avec les paramètres de routage et la clé de configuration. 6. Procédé d'accès à un contenu multi media selon la revendication précédente comprenant en outre : la mémorisation (10bis) dans une ou plusieurs bases de données de la clé de configuration (configuration_key) et des paramètres de routage (routing policies) avec les données de configuration de l'utilisateur relatives au service dans un profil associé au terminal fixe. 7. Procédé d'accès à un contenu muid media selon la revendication précédente dans lequel le fournisseur de contenu gère une base de données qui contient pour un utilisateur donné, la liste des services souscrits et la liste des services activés par terminal avec la clé de configuration associée au terminal et au service, comprenant en outre : la mise à jour (SqlObis) de la base de données avec la clé de configuration générée pour le terminal fixe et le service demandé. 8. Procédé d'accès à un contenu muid media selon l'une des revendications 6 à 7 comprenant en outre : une transmission depuis le terminal mobile au serveur (PFS TV) de gestion d'offre de services du fournisseur de contenu (FC) d'une requête de desactivation du service paramétrée avec la clé de configuration (Configuration_Key). 9. Procédé d'accès à un contenu muid media selon l'une des revendications 6 à 8 comprenant en outre : une transmission depuis le serveur (PFS TV) de gestion d'offre de services du fournisseur de contenu (FC) au terminal fixe d'une requête de desactivation du service paramétrée avec la clé de configuration. 10. Procédé d'accès à un contenu muid media selon l'une des revendications 6 à 9 comprenant en outre : une transmission (5q101) depuis le terminal mobile au serveur (PFS TV) de gestion d'offre de services du fournisseur de contenu (FC) d'une requête de mise à jour du service paramétrée avec la clé de configuration. 11. Procédé d'accès à un contenu muid media selon l'une des revendications 1 à 10 comprenant enoutre : - la réception (Sq14.3) par le terminal mobile d'un code de sécurité généré depuis le serveur (PFS TV) de gestion d'offre de services du fournisseur de contenu (FC), - la fourniture du code de sécurité au terminal fixe, - la transmission (Sq14.4) depuis le terminal fixe du code de sécurité au serveur (PFS TV) de gestion d'offre de services du fournisseur de contenu (FC), - la transmission (Sq15.3) d'une requête d'autorisation d'activation du serveur (PFS TV) de gestion d'offre de services du fournisseur de contenu (FC) au terminal fixe uniquement si le code de sécurité reçu est identique au code généré. 12. Procédé d'accès à un contenu mufti media selon l'une des revendications 1 à 11 dans lequel la phase de découverte met en oeuvre un lien point à point courte distance entre le terminal mobile et le terminal fixe. 13. Procédé d'accès à un contenu mufti media selon l'une des revendications 1 à 12 dans lequel la phase de découverte comprend une restitution à l'utilisateur de données de profil du terminal fixe pour confirmation par l'utilisateur de la poursuite du procédé avec ce terminal fixe. 14. Module logiciel comportant des instructions de programme telles que leur exécution par un terminal mobile met en oeuvre les étapes suivantes : - une phase de découverte (Sql, Sq2) d'un terminal fixe (TV) à proximité du terminal mobile, comprenant une mémorisation par le terminal mobile de données de profil (device type) du terminal fixe, - une transmission (Sq3) depuis le terminal mobile d'une requête d'activation d'un service d'accès à du contenu mufti media enrichie de données (device type) de profil du terminal fixe à destination d'un serveur (PFS TV) de gestion d'offre de services d'un fournisseur de contenu (FC), - un téléchargement (Sq11.3) d'une application correspondant au service requis sélectionnée en fonction des données (device type) de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, - une installation (Sq12) sur le terminal fixe de l'application téléchargée (Sq11.3) sur le terminal mobile. 15. Support d'informations comportant des instructions de programme adaptées à la mise en oeuvre des étapes suivantes lorsque ledit programme est chargé et exécuté dans un terminal mobile : - une phase de découverte (Sql, 5q2) d'un terminal fixe (TV) à proximité du terminal mobile, comprenant une mémorisation par le terminal mobile de données de profil (device type) du terminal fixe, - une transmission (5q3) depuis le terminal mobile d'une requête d'activation d'un service d'accès à du contenu mufti media enrichie de données (device type) de profil du terminal fixe à destination d'un serveur (PFS TV) de gestion d'offre de services d'un fournisseurde contenu (FC), un téléchargement (Sq11.3) d'une application correspondant au service requis sélectionnée en fonction des données (device type) de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, une installation (Sq12) sur le terminal fixe de l'application téléchargée (Sq 11.3) sur le terminal mobile. 16. Terminal mobile comprenant un module logiciel avec des instructions de programme telles que leur exécution met en oeuvre les étapes suivantes : une phase de découverte (Sql, Sq2) d'un terminal fixe (TV) à proximité du terminal mobile, comprenant une mémorisation par le terminal mobile de données de profil (device type) du terminal fixe, une transmission (Sq3) depuis le terminal mobile d'une requête d' activation d'un service d'accès à du contenu mufti media enrichie des données (device type) de profil du terminal fixe à destination d'un serveur (PFS TV) de gestion d'offre de services d'un fournisseur de contenu (FC), un téléchargement (Sq11.3) d'une application correspondant au service requis sélectionnée en fonction des données (device type) de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, une installation (Sq12) sur le terminal fixe de l'application téléchargée (Sq11.3) sur le terminal mobile. 17. Terminal fixe (TV) comprenant un module logiciel avec des instructions de programme telles que leur exécution met en oeuvre les étapes suivantes : une phase de découverte (Sql, Sq2) entre un terminal mobile (TM) et le terminal fixe (TV), le terminal mobile étant à proximité du terminal fixe, comprenant une mémorisation par le terminal mobile de données de profil (device type) du terminal fixe, une phase d'installation (Sq12) sur le terminal fixe à partir du terminal mobile d'une application téléchargée (Sq11.3) au préalable sur le terminal mobile, l'application correspondant à un service d' accès à un contenu mufti media sélectionnée en fonction des données (device type) de profil du terminal fixe et adaptée en fonction de données de configuration de l'utilisateur relatives au service, une phase d'activation (Sq13, Sq15.3) du service d'accès à un contenu mufti media entre le terminal fixe et un serveur de gestion d'offre de services d'un fournisseur du contenu mufti média.35