FR2971384A1 - Procede et dispositif de gestion dynamique du mode d'acces a au moins une premiere ressource d'une application publiee, produit programme d'ordinateur et terminal correspondants. - Google Patents

Abstract

L'invention concerne un procédé de gestion dynamique du mode d'accès à au moins une première ressource d'une application publiée, ladite application publiée comprenant une pluralité de ressources accessibles par une pluralité de terminaux selon au moins deux modes d'accès distincts. Selon l'invention, le procédé comprend, pour ladite au moins une première ressource : • une première étape de détermination d'un mode d'accès optimisé à ladite première ressource, tenant compte d'au moins un premier critère prédéterminé ; • une première étape de modification du mode d'accès courant à ladite première ressource vers ledit mode d'accès optimisé déterminé.

Description

Procédé et dispositif de gestion dynamique du mode d'accès à au moins une première ressource d'une application publiée, produit programme d'ordinateur et terminal correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui de la transmission et de la diffusion d'informations numériques. Plus précisément, l'invention concerne une technique de gestion des ressources d'une application TV accessible par une pluralité de terminaux via au moins deux modes d'accès distincts.

L'invention s'applique notamment, mais non exclusivement, à une application conforme à la norme suivante : HbbTV ETSI TS 102 796 V1.1.1. (2010-06) (« Hybrid Broadcast Broadband TV » en anglais, pour « Télévision Hybride Diffusé Connecté »), dans laquelle une partie des ressources d'une application est accessible via un mode diffusé (par exemple via une diffusion en utilisant un réseau hertzien de type TNT) et une partie via un mode connecté (par exemple en utilisant un réseau IP). 2. ARRIÈRE-PLAN TECHNOLOGIQUE On s'attache plus particulièrement dans la suite de ce document à décrire la problématique existante dans le domaine de la télévision hybride et de la publication d'applications de ce type, à laquelle ont été confrontés les inventeurs de la présente demande de brevet. L'invention ne se limite bien sûr pas à ce domaine particulier d'application, mais présente un intérêt pour toute technique de transmission ou de diffusion d'informations devant faire face à une problématique proche ou similaire. La norme HbbTV définit un sous-ensemble de technologies WEB (HTML, Javascript, CSS (« Cascading Style Sheets » en anglais pour « feuilles de style en cascade »), AJAX (« Asynchronous Javascript and XML »), ...) utilisées pour créer des applications compatibles avec les terminaux récepteurs de programmes de HbbTV. Ces applications HbbTV sont publiées et accessibles via un signal de type TNT, c'est-à-dire dans un mode diffusé, et/ou via une liaison réseau de type IP, c'est-à-dire en mode connecté.

En pratique, certaines ressources d'une application, encore appelées sous-applications, ou pages, sont accessibles en mode diffusé, et d'autres en mode connecté.

Par ailleurs, une application est structurée de sorte que ses ressources soient indépendantes. Au niveau d'un terminal récepteur, la partie diffusée de l'application est reçue sous la forme d'un carrousel, mémorisé dans le terminal récepteur. Une fois le carrousel entièrement reçu, les ressources de cette partie diffusée de l'application sont donc directement accessibles dans le terminal récepteur. Pour ce qui est de la partie de l'application accessible en mode connecté, les ressources sont téléchargées au fur et à mesure de la navigation dans l'application, via des requêtes http par exemple.

Ainsi, il est possible de naviguer entre les différentes ressources d'une application (par exemple une page météo, une page résultats sportifs, ...), via des liens qui pointent vers les ressources, en mode d'accès diffusé ou connecté. Dans le cas d'une ressource diffusée, le lien est par exemple de la forme « dvb://tfl.b8/mapage.html », et dans le cas d'une ressource accessible en mode connecté, le lien est par exemple de la forme « httpi/monserveur/mapage.html ». C'est le fournisseur de l'application qui définit, au moment de la création de l'application, quelles ressources seront accessibles en mode diffusé et quelles ressources le seront en mode connecté. Cette répartition tient compte par exemple de contraintes techniques (bande passante limitée pour le mode diffusé, nécessité de rendre certaines ressources accessibles en mode diffusé afin de ne pas léser les utilisateurs n'ayant pas le mode connecté, ...), de considérations commerciales (ressources publicitaires accessibles de préférence en mode diffusé, ...), .... En revanche, un inconvénient de cette technique actuelle réside dans le fait que cette répartition des modes d'accès aux ressources, définie au moment de la création de l'application, ne tient pas compte de l'utilisation ultérieure que feront les terminaux récepteurs de ces différentes ressources de l'application. Cette répartition n'est donc potentiellement pas optimale, notamment en terme d'utilisation de la bande passante de diffusion, en fonction des comportements des utilisateurs. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.

Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique permettant d'optimiser l'utilisation de la bande passante pour la partie diffusée d'une application, tout en respectant certaines contraintes prédéfinies par le fournisseur de l'application. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit transparente pour l'utilisateur. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant une implémentation peu coûteuse . 4. EXPOSÉ DE L'INVENTION L'invention propose une solution nouvelle qui ne présente pas l'ensemble de ces inconvénients de l'art antérieur, sous la forme d'un procédé de gestion dynamique du mode d'accès à au moins une première ressource d'une application publiée, l'application publiée comprenant une pluralité de ressources accessibles par une pluralité de terminaux selon au moins deux modes d'accès distincts. Selon l'invention, un tel procédé comprend, pour au moins la première ressource : - une première étape de détermination d'un mode d'accès optimisé à la première ressource, tenant compte d'au moins un premier critère prédéterminé ; 20 - une première étape de modification du mode d'accès courant à la première ressource vers le mode d'accès optimisé déterminé. Ainsi, l'invention repose sur une approche nouvelle et inventive consistant à gérer dynamiquement, c'est-à-dire lorsqu'une application est publiée et en cours d'accès par des utilisateurs, les modes d'accès aux différentes ressources de l'application, dans 25 un contexte où il existe au moins deux modes d'accès distincts aux ressources d'une même application (par exemple un mode d'accès connecté et un mode d'accès diffusé). Pour ce faire, l'invention prévoit de déterminer, àpartir d'au moins un critère, un mode d'accès optimisé pour une ressource et de modifier le mode d'accès courant de cette ressource vers le mode d'accès optimisé. 10 15 Selon un aspect particulier de l'invention, le mode d'accès courant de la première ressource est un mode connecté et le mode d'accès optimisé de la première ressource est un mode diffusé. En effet, lorsqu'il est constaté par exemple qu'une ressource, dont le mode d'accès courant est un mode connecté, est très fréquemment utilisée, il est préférable et plus efficace de la diffuser, de manière à la rendre disponible (en mode diffusé donc) pour tous les utilisateurs, sans qu'ils n'aient à émettre de requêtes d'accès à la ressource. Ainsi, l'invention, selon ce mode de réalisation, permet de modifier le mode d'accès connecté à une ressource en un mode d'accès diffusé, pour un fonctionnement optimisé de l'application. Par exemple, le mode connecté correspond à un mode de transmission par réseau IP, dans lequel les ressources sont accessibles via des requêtes de type http, et le mode diffusé correspond à une diffusion sur un réseau hertzien de type TNT. Il est à noter que le mode d'accès d'une ressource est «transparent» pour l'utilisateur, et un changement de mode d'accès d'une ressource également. Par exemple, l'application est une application de type HbbTV. Selon un autre aspect de l'invention, le procédé comprend, pour au moins une deuxième ressource de l'application dont le mode d'accès courant correspond au mode d'accès optimisé déterminé pour la première ressource : - une deuxième étape de détermination d'un mode d'accès possible à la deuxième ressource, tenant compte d'au moins un deuxième critère prédéterminé ; - une deuxième étape de modification du mode d'accès courant à la deuxième ressource vers le mode d'accès possible déterminé. Ainsi, l'invention prévoit également de modifier le mode d'accès d'au moins une autre ressource de l'application, par exemple pour libérer de la bande passante pour la diffusion de la première ressource dont le mode d'accès passe de mode connecté à mode diffusé. Pour ce faire, on détermine si une deuxième ressource peut passer d'un mode 30 d'accès diffusé à un mode d'accès connecté, et si c'est le cas, son mode d'accès est alors modifié. 25 Selon un mode de réalisation de l'invention, les première et deuxième étapes de modification modifient au moins un lien d'accès respectivement aux première et deuxième ressources au sein de l'application. Selon un autre mode de réalisation, compatible avec le précédent, les première et deuxième étapes de modification modifient au moins une partie du code de programme de l'application permettant d'accéder respectivement aux première et deuxième ressources au sein de l'application. Ainsi, la modification du mode d'accès d'une ressource consiste à modifier, dans l'application, les liens ou le code, par exemple du code Javascript, permettant d'y accéder. Par exemple, les premier et deuxième critères prédéterminés appartiennent au groupe comprenant : - un nombre d'accès préalables à au moins une desdites ressources de ladite application ; - une information représentative d'un instant ; - une priorité d'accès ; - une disponibilité de bande passante ; - un ordre de modification d'accès à au moins une desdites ressources de ladite application ; - etc. Ainsi, la détermination d'un mode d'accès optimisé d'une ressource tient compte de critères tels que le nombre d'accès préalables à cette ressource, à l'instant où l'on détermine un mode d'accès optimisé pour cette ressource, ou certains paramètres définis par le fournisseur de l'application, pour un fonctionnement optimal de l'application.

Par exemple, lorsqu'il a été constaté qu'il serait optimal qu'une ressource soit diffusée alors que son mode d'accès courant est un mode connecté, l'invention prévoit, selon une première variante, de s'assurer que la diffusion de cette ressource est possible, par exemple en vérifiant la disponibilité de bande passante. Selon une autre variante, l'invention prévoit de vérifier que les priorités associées aux ressources définies par le fournisseur de l'application sont respectées. Par exemple, certaines ressources sont identifiées comme prioritaires pour être diffusées, et non accessibles en mode connecté, pour des raisons techniques, commerciales, etc. Selon encore une variante, l'instant auquel on envisage de passer une ressource du mode connecté au mode diffusé est également pris en considération. Une plage horaire peut également être prise en considération. Il est également possible de tenir compte d'un ordre de modification de l'accès courant d'une ou plusieurs ressources, par exemple émis par un client (au sens commercial) de l'application. Par exemple, un tel client a la possibilité de requérir qu'une des ressources qu'il gère soit diffusée, plutôt qu'accessible en mode connecté, ou vice versa. Selon un autre aspect de l'invention, le procédé comprend en outre : - une étape de construction d'une application modifiée à partir de l'application publiée et des modes d'accès modifiés ; - une étape de publication de l'application modifiée.

Ainsi, une fois certains modes d'accès à certaines ressources modifiés, l'application est reconstruite, en tenant compte de ces modifications, puis republiée sous sa forme modifiée, de façon à ce que ces modifications soient appliquées. On rappelle que cette republication est « sans impact » sur les utilisateurs. L'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, comprenant des instructions de code de programme pour la mise en oeuvre des étapes du procédé de gestion dynamique du mode d'accès décrit précédemment. Un autre aspect de l'invention concerne un dispositif de gestion dynamique du mode d'accès à au moins une première ressource d'une application publiée, l'application publiée comprenant une pluralité de ressources accessibles par une pluralité de terminaux selon au moins deux modes d'accès distincts. Selon l'invention, un tel dispositif comprend, pour au moins la première ressource : - des premiers moyens de détermination d'un mode d'accès optimisé à la première ressource, tenant compte d'au moins un premier critère prédéterminé ; - des premiers moyens de modification du mode d'accès courant à la première ressource vers le mode d'accès optimisé déterminé. Un tel dispositif se situe par exemple au niveau d'une tête de réseau TNT/IP et peut comprendre toutes les caractéristiques du procédé décrites ci-dessus. Un autre aspect de l'invention concerne un terminal apte à accéder à et à décoder une application publiée comprenant une pluralité de ressources accessibles par une pluralité de terminaux selon au moins deux modes d'accès distincts, les modes d'accès des ressources de l'application étant gérés dynamiquement par un dispositif de gestion dynamique du mode d'accès tel que décrit précédemment. Un tel terminal est par exemple un terminal récepteur de type HbbTV. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 illustre les principales étapes du procédé de gestion dynamique du mode d'accès selon un mode de réalisation de l'invention ; - la figure 2 présente un organigramme illustrant un exemple de système mettant en oeuvre le procédé de gestion dynamique du mode d'accès illustré en figure 1, selon un mode de réalisation de l'invention ; - les figures 3a et 3b illustrent respectivement un exemple d'application avant et après la mise en oeuvre du procédé de gestion dynamique du mode d'accès, selon un mode de réalisation de l'invention ; - la figure 4 présente un exemple de structure détaillée d'un dispositif de gestion dynamique du mode d'accès selon un mode de réalisation de l'invention. 6. DESCRIPTION DÉTAILLÉE 6.1 Principe général Le principe général de l'invention repose principalement sur l'observation de l'utilisation, par les terminaux récepteurs, de certaines ressources d'une application 25 30 publiée comprenant une pluralité de ressources accessibles par une pluralité de terminaux selon au moins deux modes d'accès distincts, afin d'optimiser la répartition de ces modes d'accès, en les modifiant et republiant l'application ainsi modifiée. La modification des modes d'accès aux différentes ressources de l'application peut également reposer sur des contraintes prédéfinies par le fournisseur de l'application, ou sur une requête de modification d'accès par un client. En particulier, la modification d'un mode d'accès connecté d'une ressource en un mode d'accès diffusé permet d'optimiser la disponibilité de cette ressource pour tous les utilisateurs.

La modification d'un mode d'accès d'une ressource consiste, comme déjà indiqué ci-dessus, à modifier, dans l'application, les liens d'accès à cette ressource ou le code, par exemple du code Javascript, permettant d'y accéder. Par la suite, on considère indifféremment ces deux types de modification, même si, par souci de simplification d'écriture, on parle uniquement de modification de liens d'accès. 6.2 Description d'un mode de réalisation On présente maintenant, en relation avec la figure 1, les principales étapes du procédé de gestion dynamique du mode d'accès à au moins une ressource R1 d'une application publiée, selon un mode de réalisation de l'invention.

La première étape 10 de détermination d'un mode d'accès optimisé pour la ressource R1 considère tout d'abord un premier critère, afin de déterminer un mode d'accès optimisé pour cette ressource R1. Par exemple, ce premier critère correspond au nombre d'accès préalables à cette ressource, permettant de déterminer si elle est fréquemment requise ou non, et de déterminer ou non un mode d'accès optimisé. Selon d'autres exemple, un tel premier critère correspond à une contrainte fixée par le fournisseur de l'application, comme une priorité de certaines ressources pour le mode diffusé, ou encore une requête de modification de l'accès courant de certaines ressources gérées par un client de l'application.

En particulier, on considère un exemple d'application dans lequel une ressource R1 est disponible via un mode d'accès connecté, c'est-à-dire par exemple accessible via des requêtes http à un réseau de type IP. On considère également dans cet exemple que le premier critère correspond au nombre d'accès préalables à cette ressource R1, c'est-à- dire au nombre de requêtes http reçues, en provenance des différents terminaux récepteurs. Par ailleurs, on considère que les ressources de l'application peuvent également être disponibles en diffusion, c'est-à-dire via un mode d'accès diffusé, par exemple via un signal TNT. Par exemple, le nombre d'accès préalables à la ressource R1 peut être comparé à un seuil prédéterminé, au fur et à mesure de l'utilisation de l'application, et la détermination d'un mode d'accès optimisé peut intervenir lorsque le nombre d'accès est supérieur à ce seuil prédéterminé. La comparaison peut être mise en oeuvre de manière périodique, par exemple toutes les minutes après la publication de l'application. Si le nombre de requêtes http à la ressource R1 est supérieur à un seuil prédéterminé, alors un mode d'accès optimisé est déterminé pour cette ressource, par exemple un mode diffusé dans le cadre de cet exemple. En effet, lorsqu'une ressource est très fréquemment utilisée, il est optimal de la rendre accessible en diffusion, de façon à ce que tous les terminaux récepteurs l'aient à disposition, sans avoir à effectuer une requête à chaque fois.

Une fois un mode d'accès optimisé déterminé pour la ressource R1, l'étape 11 de modification de l'accès courant de R1 modifie l'accès courant en accès optimisé. Par exemple, la ressource R1 passe d'un mode d'accès connecté à un mode d'accès diffusé. Il est à noter que d'autres critères peuvent être pris en considération dans la détermination d'un mode d'accès optimisé à une ressource, en plus du premier critère.

On décrit maintenant plus en détails ces différentes étapes ainsi que les différents éléments d'un système mettant en oeuvre ces étapes, selon un mode de réalisation de l'invention. Un tel système est par exemple illustré en figure 2, et comprend en particulier les moyens d'un dispositif de gestion dynamique du mode d'accès (modules 20, 21 et 22).

Une application HbbTV, composée de plusieurs ressources R1 ... Rn, est disponible pour une pluralités de récepteurs HbbTV, avec une partie des ressources accessible en mode connecté, notée partie Broadband, et une partie des ressources accessible en mode diffusé, notée partie Broadcast.

Selon ce mode de réalisation de l'invention, les requêtes http émises par la pluralité de récepteurs HbbTV sont analysées par un module 20 d'analyse de requêtes http, lequel compte en particulier le nombre de requêtes émises, afin de déterminer si une ressource Ri est fréquemment utilisée ou non. Dans un premier cas, le module 20 reçoit des requêtes http d'accès à des ressources, les analyse et les retransmet au serveur http 23 en charge de fournir aux récepteurs HbbTV le résultat de leurs requêtes, c'est-à-dire l'accès aux ressources requises. Dans un deuxième cas, les requêtes http reçues et analysées par le module 20 peuvent être des requêtes d'information uniquement, c'est-à-dire des requêtes servant uniquement à comptabiliser les requêtes http parallèlement transmises par les récepteurs HbbTV au serveur http 23. Dans ce cas, ces requêtes d'informations ne sont pas retransmises par le module 20 au serveur http 23, qui a reçu directement les requêtes http d'accès aux ressources par les récepteurs HbbTV. Dans un troisième cas, le serveur http 23 reçoit des requêtes http d'accès à des ressources, en provenance des récepteurs HbbTV et les retransmet au module d'analyse 20, afin que celui-ci les analyse. Le module 20 transmet ensuite les résultats de son analyse au module 21 de détermination d'un mode d'accès optimisé, encore appelé module de décision. Par exemple, les résultats de son analyse peuvent consister en un nombre d'accès déjà effectuées à une ressource, pour chaque ressource. Dans ce cas, l'analyse consiste uniquement à compter le nombre de requêtes http pour chaque ressource. Dans un autre exemple, l'analyse peut non seulement consister à compter le nombre de requêtes, mais également à comparer ce nombre de requêtes à un seuil prédéterminé. Dans ce cas, les résultats de son analyse peuvent consister en une information indiquant, pour chaque ressource, si le nombre d'accès est supérieur ou inférieur au seuil prédéterminé, ou une information indiquant, pour les ressources concernées, que le nombre d'accès est supérieur au seuil prédéterminé. Par exemple, le module 20 fournit des informations au module 21 de manière périodique, par exemple toutes les minutes à partir du moment où l'application a été rendu accessible aux récepteurs HbbTV. Selon un autre exemple, le module 20 ne fournit des informations au module 21 que lorsque certains critères sont atteints, par exemple lorsque le nombre d'accès à une ressource a dépassé un seuil prédéterminé. Le module 21 de décision détermine, notamment à partir des informations reçues du module 20 d'analyse, un mode d'accès optimisé, pour une ou plusieurs ressources de l' application. En particulier, lorsque le nombre de requêtes http à une ressource est supérieur à un seuil prédéterminé, le module 21 de décision va déterminer s'il est possible, en fonction d'un certain nombre d'autres critères, de modifier l'accès à cette ressource et de la rendre accessible en mode diffusé. Par un exemple, un premier critère pris en compte par le module 21 correspond au taux d'occupation de la bande passante dédiée à la partie diffusée de l'application HbbTV. En effet, cette bande passante étant limitée, il convient de vérifier que la diffusion d'une ressource, auparavant accessible en mode connecté, est compatible avec l'occupation de la bande passante. Ainsi, si tel n'est pas le cas, par exemple si toute la bande passante est déjà utilisée pour diffuser certaines ressources de l'application, ou si la diffusion de cette ressource nécessite plus de bande passante que celle disponible, alors le module de décision 21 est apte à modifier l'accès courant diffusé d'une ressource en un accès connecté, de façon à libérer de la bande passante. Par exemple, le module 21 de décision peut avoir connaissance du taux de fréquentation des ressources en mode diffusé et ainsi connaître les ressources peu utilisées, qu'il peut décider de basculer en mode d'accès connecté. Pour ce faire, l'invention prévoit que les accès aux ressources diffusées sont connus du module 21, alors que classiquement ces accès consistent à aller chercher la ressource auparavant stockée sur le terminal récepteur, une fois le carrousel entièrement reçu, et ne correspondent donc pas à des requêtes émises par le terminal récepteur. Par exemple, des requêtes d'information, de petite taille et rapides à traiter, peuvent être transmises lors de la navigation d'un utilisateur dans l'application, permettant ainsi de connaître l'utilisation en cours des ressources, et en particulier des ressources diffusées. Par ailleurs, un autre critère pouvant être pris en considération par le module 21 afin de déterminer s'il est possible de modifier l'accès courant d'une ressource en mode d'accès optimisé, correspond à des informations fournies par le fournisseur de l'application, au moment de la création de l'application. Par exemple, le fournisseur de l'application indique quelles sont les ressources prioritaires pour la diffusion, c'est-à-dire celles qui ne doivent pas basculer en mode connecté, ou quelles sont les ressources prioritaires pour l'accès en mode connecté (par exemple pour des raison techniques). Selon un autre exemple, le fournisseur indique des plages horaires pour lesquelles certaines ressources doivent être de préférence, ou impérativement, accessibles en mode diffusé, ou des plages horaires pour lesquelles aucune contrainte spécifique n'est indiquée. Un autre critère pouvant être pris en considération correspond à un ordre, ou une requête, transmis par un client gérant une ressource et souhaite que celle-ci soit accessible via un mode d'accès différent de son mode d'accès courant. Ainsi, le module 21 tient compte de ces différentes informations à sa disposition pour déterminer ou non un mode d'accès optimisé pour une ou plusieurs ressources. Il est à noter que le module 21 peut déterminer un mode d'accès optimisé d'une ressource à partir d'un seul de ces critères, celui-ci ne correspondant pas forcément au nombre d'accès préalables à la ressource. Le module 21 peut ainsi déterminer le mode d'accès optimisé d'une ressource en fonction uniquement d'un ordre d'un client, ou d'une contrainte fixée par le fournisseur de l'application. Par exemple, le module 21 peut avoir à sa disposition, à un instant t, les informations suivantes : - une information transmise par le module 20 indiquant que le nombre d'accès à la ressource R1, dont le mode d'accès courant est un mode connecté, est supérieur à un seuil prédéterminé ; - une information indiquant que la bande passante réservée pour la diffusion de l'application est pleinement utilisée ; - une information indiquant que les ressources R2 et R3 actuellement diffusées sont très peu utilisées ; - une information indiquant que la bande passante nécessaire à la diffusion de la ressource R1 est égale à celle nécessaire à R2, et égale à celle nécessaire à R3 ; - aucune contrainte particulière par le fournisseur de l'application pour cette ressource R1 ni pour cette ressource R3 ; - une information transmise par le fournisseur d'accès indiquant que la ressource R2 ne doit pas basculer en mode d'accès connecté.

Selon ce mode de réalisation de l'invention, le module de décision 21 peut déterminer d'une part que le mode d'accès à la ressource R3 doit passer du mode diffusé au mode connecté, libérant ainsi une partie de la bande passante, et d'autre part, que le mode d'accès à la ressource R1 doit passer du mode connecté au mode diffusé. Ces deux modifications de mode d'accès aux ressources R1 et R3 sont ensuite transmises, par le module 21 de décision, au module 22 de modification de l'application. Ce module 22 est en charge des modifications des liens d'accès aux ressources dans l'application, ainsi que de la construction et de la publication d'une application modifiée, avec les liens modifiées. Ce module 22 de modification de l'application conserve à tout moment l'application initiale, telle que le fournisseur de l'application l'a créée, avec la répartition initiale entre les ressources accessibles en mode connecté et celles accessibles en mode diffusé. Ce module 22 peut ainsi, à partir de l'application initiale, et à partir d'informations transmises par le module de décision 21 pour modifier les modes d'accès de certaines ressources, construire une application modifiée et la publier.

Par exemple, pour modifier l'accès à une ressource, le module 22 parcourt toute l'application à la recherche des liens d'accès à cette ressource, et modifie chaque lien en fonction du mode d'accès optimisé requis. Ainsi, dans le cas décrit ci-dessus, le module 22 parcourt toute l'application, fichier par fichier, d'une part pour modifier les liens d'accès de l'application R3 du mode courant diffusé au mode connecté, et d'autre part pour modifier les liens d'accès de l'application R1 du mode courant connecté au mode diffusé. Une fois tous ces liens modifiés, le module 22 construit une application modifiée à partir des fichiers comprenant des liens modifiés et des fichiers initiaux de l'application (c'est-à-dire ceux ne comprenant aucun lien d'accès aux ressources R1 ou R3). Dans cette application modifiée, la répartition des ressources entre le mode diffusé et le mode connecté est différente de celle de l'application initiale, et le module 22 transmet alors la partie Broadband (partie des ressources accessible en mode connecté) de l'application modifiée à un serveur HTTP 23, en charge de mettre à disposition des récepteurs HbbTV les ressources Broadband, et la partie Broadcast (partie des ressources accessible en mode diffusé ) de l'application modifiée à un module de diffusion TNT 24, en charge de la diffusion des ressources Broadcast vers les récepteurs HbbTV. Par exemple, de manière connue, ce module de diffusion 24 génère la signalisation MPEG/DVB nécessaire à la diffusion des ressources de l'application, encapsule les fichiers correspondant à ces ressources pour pouvoir les diffuser, comme déjà indiqué ci-dessus, sous la forme d'un carrousel DSM-CC, puis multiplexe, module et émet le signal ainsi obtenu. On présente maintenant, en relation avec les figures 3a et 3b, un exemple de l'évolution de la structure de mise à disposition d'une application de type HbbTV. La figure 3a représente une application initiale en cours d'utilisation, à un instant t. Les sous-applications, ou ressources, A, B, C, E et F (représentées en traits pleins) sont accessibles en mode courant diffusé, c'est-à-dire qu'une fois le carrousel diffusé entièrement reçu par un récepteur, celui-ci peut accéder à ces ressources directement, sans avoir besoin d'émettre de requêtes supplémentaires. Les ressources D, G et H (représentées en traits pointillés) sont quant à elles accessibles en mode courant connecté, c'est-à-dire que lorsqu'un utilisateur souhaite y accéder, son terminal récepteur doit émettre une requête HTTP, pour chaque ressource, afin de charger son contenu. A cet instant t, le procédé selon l'invention permet de savoir que les ressources G et H sont très fréquemment requises. En effet, le module 20 d'analyse a transmis une information au module 21 de décision indiquant que le serveur HTTP reçoit un grand nombre de requêtes HTTP pour chacune de ces deux ressources. Il est donc optimal de modifier le mode d'accès à ces ressources, en les diffusant. Pour ce faire, le module 21 de décision doit modifier le mode d'accès de ressources actuellement diffusées, afin de libérer de la bande passante pour les ressources G et H. Par exemple, le module 21 de décision décide de modifier le mode d'accès courant diffusé des ressources B, E et F en mode connecté et de modifier le mode d'accès courant connecté des ressources G et H en mode diffusé. Pour ce faire, le module 22 a tenu compte de critères prédéterminés, par exemple des contraintes indiquées par le fournisseur d'application (déjà décrites ci-dessus). Les décisions de modification des modes d'accès des ressources B, E et F et G et H sont transmises au module 22 de modification de l'application, afin qu'il modifie tous les liens d'accès à ces ressources, partout dans l'application, créant ainsi une application modifiée. Cette application modifiée est ensuite publiée et ses parties Broadband et Broadcast respectivement transmises vers le serveur HTTP 23 et le module de diffusion 24. La structure de l'application ainsi modifiée selon ce mode de réalisation du procédé de gestion dynamique du mode d'accès de l'invention est illustrée en figure 3b, à l'instant t+l. A partir de cet instant, tout nouvel utilisateur peut accéder aux ressources G et H directement (une fois le carrousel entièrement reçu), sans avoir besoin d'émettre de requêtes supplémentaires.

Pour un utilisateur ayant déjà téléchargé ces ressources lorsqu'elles étaient accessibles en mode connecté (version initiale de l'application), selon un premier cas, il continue à utiliser les ressources préalablement téléchargées, sans avoir besoin d'émettre une requête supplémentaire. Selon un deuxième cas, l'invention prévoit de «forcer» le mode d'accès optimisé, c'est-à-dire que l'accès aux ressources G et H est « forcé » en mode diffusé, les téléchargements préalablement effectuées n'étant plus accessibles. La figure 4 présente la structure d'un dispositif selon un mode de réalisation particulier de l'invention.

Un tel dispositif comprend une mémoire 40 constituée d'une mémoire tampon, une unité de traitement 41, équipée par exemple d'un microprocesseur g, et pilotée par le programme d'ordinateur 42, mettant en oeuvre le procédé de gestion dynamique du mode d'accès selon un mode de réalisation de l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 42 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 41. L'unité de traitement 41 reçoit en entrée au moins une application comprenant une pluralité de ressources accessibles par une pluralité de terminaux selon au moins deux modes d'accès distincts, par exemple une application de type HbbTV. Le microprocesseur de l'unité de traitement 41 met en oeuvre les étapes du procédé de gestion dynamique du mode d'accès décrit précédemment, selon les instructions du programme d'ordinateur 42, pour décider si le mode d'accès courant à au moins une ressource de l'application peut être modifié en un mode d'accès optimisé et modifier l'application en conséquence. Pour cela, le dispositif de gestion dynamique du mode d'accès comprend, outre la mémoire tampon 40, pour au moins une première ressource, des premiers moyens de détermination d'un mode d'accès optimisé à la première ressource, tenant compte d'au moins un premier critère et des premiers moyens de modification du mode d'accès courant à la première ressource vers la mode d'accès optimisé déterminé. Ces moyens sont pilotés par le microprocesseur de l'unité de traitement 41.30

Claims (11)

1. REVENDICATIONS1. Procédé de gestion dynamique du mode d'accès à au moins une première ressource d'une application publiée, ladite application publiée comprenant une pluralité de ressources accessibles par une pluralité de terminaux selon au moins deux modes d'accès distincts, caractérisé en ce qu'il comprend, pour ladite au moins une première ressource : - une première étape de détermination d'un mode d'accès optimisé à ladite première ressource, tenant compte d'au moins un premier critère ; - une première étape de modification du mode d'accès courant à ladite première ressource vers ledit mode d'accès optimisé déterminé.
2. 2. Procédé de gestion dynamique du mode d'accès selon la revendication 1, caractérisé en ce que ledit mode d'accès courant de ladite première ressource est un mode connecté et ledit mode d'accès optimisé de ladite première ressource est un mode diffusé.
3. 3. Procédé de gestion dynamique du mode d'accès selon la revendication 2, caractérisé en ce que ladite application est une application de type HbbTV.
4. 4. Procédé de gestion dynamique du mode d'accès selon la revendication 1, caractérisé en ce qu'il comprend, pour au moins une deuxième ressource de ladite application dont le mode d'accès courant correspond au mode d'accès optimisé déterminé pour ladite première ressource : - une deuxième étape de détermination d'un mode d'accès possible à ladite deuxième ressource, tenant compte d'au moins un deuxième critère prédéterminé ; - une deuxième étape de modification dudit mode d'accès courant à ladite deuxième ressource vers ledit mode d'accès possible déterminé.
5. 5. Procédé de gestion dynamique du mode d'accès selon les revendications 1 et 4, caractérisé en ce que lesdites première et deuxième étapes de modification modifient au moins un lien d'accès respectivement auxdites première et deuxième ressources au sein de ladite application.
6. 6. Procédé de gestion dynamique du mode d'accès selon les revendications 1 et 4, caractérisé en ce que lesdites première et deuxième étapes de modification modifient aumoins une partie du code de programme de ladite application permettant d'accéder respectivement auxdites première et deuxième ressources au sein de ladite application.
7. 7. Procédé de gestion dynamique du mode d'accès selon la revendication 4, caractérisé en ce que lesdits premier et deuxième critères prédéterminés appartiennent au groupe comprenant : - un nombre d'accès préalables à au moins une desdites ressources de ladite application ; - une information représentative d'un instant ; - une priorité d'accès ; - une disponibilité de bande passante ; - un ordre de modification d'accès à au moins une desdites ressources de ladite application.
8. 8. Procédé de gestion dynamique du mode d'accès selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comprend en outre : - une étape de construction d'une application modifiée à partir de ladite application publiée et desdits modes d'accès modifiés ; - une étape de publication de ladite application modifiée.
9. 9. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un 20 microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre des étapes du procédé de gestion dynamique du mode d'accès selon les revendications 1 à 8.
10. 10. Dispositif de gestion dynamique du mode d'accès à au moins une première ressource d'une application publiée, ladite application publiée comprenant une pluralité 25 de ressources accessibles par une pluralité de terminaux selon au moins deux modes d'accès distincts, caractérisé en ce qu'il comprend, pour ladite au moins une première ressource : - des premiers moyens de détermination d'un mode d'accès optimisé à ladite première ressource, tenant compte d'au moins un premier critère 30 prédéterminé ; 15- des premiers moyens de modification du mode d'accès courant à ladite première ressource vers ledit mode d'accès optimisé déterminé.
11. 11. Terminal apte à accéder à et à décoder une application publiée comprenant une pluralité de ressources accessibles par une pluralité de terminaux selon au moins deux modes d'accès distincts, les modes d'accès desdites ressources de ladite application étant gérés dynamiquement par un dispositif de gestion dynamique du mode d'accès selon la revendication 10.10