FR2996326A1 - Dispositif d'affichage numerique communicant - Google Patents

Abstract

Procédé de commande de la diffusion de médias par un dispositif d'affichage sous le contrôle d'un serveur centralisé (150) accédant à une base de données contextuelle (160), ledit procédé étant basé sur la transmission périodique par ledit dispositif affichage (200) d'une requête comportant un identifiant dudit dispositif et accompagné de champs (headers) définissant des informations contextuelles destinées à être reportées audit serveur (150) pour y être stockées dans ladite base de données (160), ledit serveur répondant à ladite requête au moyen d'une réponse définissant le media à diffuser, accompagnée de champs (headers) définissant une ou plusieurs actions à exécuter par ledit dispositif d'affichage (200), l'écran d'affichage étant un écran d'une tablette tactile ou celui d'un ordinateur utilisé lors d'une phase de veille.

Description

- 1 - Dispositif d'affichage numérique communicant Domaine technique de l'invention La présente invention concerne le domaine des systèmes d'affichage d'information en réseau et notamment un dispositif d'affichage numérique communicant, de type cadre numérique, permettant une gestion centralisée des 10 contenus affichés. Etat de la technique 15 De nombreux affichages en réseau sont distribués et répartis sur des lieux publics ou privés pour diffuser une information intermittente ou en continu. L'on connaît notamment l'affichage en hôtellerie qui est basée sur la 20 télévision présente dans les chambres et qui est largement utilisée pour diffuser un message multimédia dédié à destination du client de l'hôtel, du moins lorsque ce dernier ne regarde pas un programme spécifique sur la télévision. Cet affichage bien connu ne permet qu'une communication très "générique" en ce sens où tous les clients de l'hôtel ont vocation à recevoir la même information. 25 L'on connaît aussi des systèmes d'affichage exploitant des "tablettes' numérique offrant un contenu et des outils pour passer commande soit pas le biais d'application ou de service web. Mais de tels systèmes sont sophistiqués et onéreux. 30 Des systèmes exploitant les téléphones IP avec écran sont également utilisés dans certains hôtels. Pour les plus sophistiqués, ces écrans sont équipés d'une interface tactile du type HTML permettant de naviguer dans un service dédié S13_07-FR1 - 2 - (à l'instar des tablettes). Ils offrent notamment la possibilité de transmettre du contenu via le protocole SIP. Ce protocole permet d'ouvrir une session avec un téléphone à partir de son nom (qui peut être le nom de la chambre) pour lui pousser du contenu multimédia par HTTP. Le téléphone, identifié par le nom SIP dispose d'un serveur HTTP embarqué pour recevoir des messages. Un composant local dans l'infrastructure réseau de l'hôtel est alors nécessaire pour réaliser la correspondance entre le numéro de la chambre et l'adresse IP afin d'envoyer ce message avec le contenu multimédia à afficher.

Les cadres photos numériques sont des dispositifs très répandus, notamment dans les lieux publics et les chambres d'hôtel et ils constituent une solution élégante et peu onéreuse. Ils exploitent aujourd'hui deux technologies d'affichage de contenu à distance: les flux MRSS (Media Real Simple Syndication) ainsi que le standard DLNA (Digital Living Network Alliance).

Le standard DNLA permet de connecter toutes sortes d'appareils multimédia sur un réseau local. C'est une technologie basée sur UPnP (Universal Plug & Play) qui ne permet pas d'opérer un large réseau d'appareils et impose la mise en place du serveur de contenu sur le même réseau local (PC, NAS, DVD). Ce procédé n'est donc pas adapté à la gestion centralisée d'un grand nombre d'écrans. Le standard MRSS permet de s'abonner à du contenu multimédia mis en ligne sur le Web (URL) et de charger périodiquement ces données pour en afficher du contenu. L'ensemble des réglages se fait sur le cadre et la dynamique du message diffusé (slideshow suivant la terminologie anglo-saxonne) ne peut pas être complètement contrôlée par le fournisseur de contenu. Aucune de ces deux techniques MRSS et DNLA ne permet de piloter des cadres à distance depuis le serveur de contenu sur le réseau Internet.

Tel est le problème que l'on se propose à résoudre avec la présente invention. SB_07-FR1 - 3 - Exposé de l'invention La présente invention a pour but de proposer un procédé permettant un 5 déploiement à grande échelle de cadres numériques communicants permettant un affichage dynamique, continu ou intermittent, sous la commande d'un serveur centralisé commandant la diffusion de continus médias. C'est un autre but de la présente invention de réaliser un procédé de gestion 10 d'une multitude de cadres numériques déployés sur de nombreux sites distincts et sur plusieurs territoires, et facilitant la gestion contextuelle de la diffusion des médias sous la commande d'un serveur centralisé. C'est un troisième but de la présente invention de réaliser un nouveau type 15 de cadre numérique pouvant être aisément déployé sur un site donné, et reporter à un serveur centralisé des informations permettant une gestion centralisée de la diffusion de médias. C'est un quatrième but de la présente invention de réaliser un cadre 20 numérique peu onéreux à fabriquer et facile à déployer sur un site donnée, notamment une structure hôtelière, et ouvrant la possibilité de nouveaux services à la clientèle. L'invention réalise ces buts au moyen d'un procédé de commande de la 25 diffusion de médias par un dispositif d'affichage, sous le contrôle d'un serveur centralisé accédant à une base de données contextuelle, ledit procédé étant basé sur la transmission périodique par ledit dispositif affichage d'une requête comportant un identifiant dudit dispositif et accompagné de champs (headers) définissant des informations contextuelles destinées à être reportées audit serveur pour y être 30 stockées dans ladite base de données, ledit serveur répondant à ladite requête au moyen d'une réponse définissant le media à diffuser, accompagnée de champs (headers) définissant une ou plusieurs actions à exécuter par ledit dispositif d'affichage, l'écran d'affichage étant un écran d'une tablette tactile ou celui d'un ordinateur utilisé lors d'une phase de veille. SB_07-FR1 - 4 - Dans un mode de réalisation particulier, les requêtes sont des requêtes HTTP GET ou POST comportant l'identifiant du dispositif d'affichage et son adresse IP accompagné de champs (headers) définissant des informations contextuelles destinées à être reportées audit serveur pour y être stockées dans ladite base de données, et dont les réponses reçues du serveur comportent un fichier XML comportant une liste d'URL définissant les images à diffuser ainsi que leur durée d'affichage, ladite réponse comportant également des champs (headers) définissant une ou plusieurs actions à exécuter par ledit dispositif d'affichage.

De préférence, le dispositif d'affichage effectue une comparaison du fichier XML avec le fichier en cours de diffusion de manière à détecter une réponse qui serait transmise depuis un cache et non depuis le serveur. Dans cette situation, la détection entraîne la poursuite de la diffusion du média en cours d'affichage.

Dans un mode de réalisation particulier, les champs ou "headers" accompagnant les requêtes du dispositif d'affichage définissent des informations relevés par un ou plusieurs capteurs parmi les suivants: - un capteur de mouvement, notamment basé sur une détection infra-rouge; - un capteur de luminosité; - des moyens de localisation; - un ou plusieurs capteurs de sécurité; tel qu'un détecteur de fumée; - un capteur de type boussole.

Dans un mode de réalisation particulier, la réponse du serveur comporte une instruction dans un champ ou "header", venant définir l'une des actions suivantes: - la commande de la fréquence de mise à jour (polling) - l'affichage ou l'extinction de l'écran; - une procédure de vérification de la correspondance entre l'identifiant du 30 dispositif d'affichage et le numéro de la chambre; - une procédure de mesure des procédures de cache mises en oeuvre par le fournisseur d'accès au réseau internet; - une procédure d'affichage d'une note destiné au résidant de la chambre où est localisé le cadre numérique (200); SB_07-FR1 -5- - une procédure de découverte de l'environnement relatif aux réseaux sans fils visibles par le dispositif d'affichage, notamment en mode infrastructure. De préférence, la réponse transmise par le serveur est conforme au standard MRSS et comporte des « headers » supplémentaires venant définir des actions à exécuter par le dispositif d'affichage. De préférence, les dispositifs d'affichage sont installés dans des structures hôtelières sous le contrôle d'un serveur centralisé dans lequel la base de données comporte une table de correspondance entre les identifiants des dispositifs d'affichage et les numéros de chambres (ROOM NAME) ainsi que des informations relatives aux entrées et sorties (check-in; check-out) des chambres louées, de manière à pouvoir diffuser un media réellement contextuel au résidant de la chambre.

Dans un mode de réalisation particulier, les informations transmises par le dispositif d'affichage au serveur centralisé permettent de conduire une analyse de vraisemblance et de déterminer un éventuel mouvement de celui-ci. L'invention permet également la réalisation d'un dispositif de traitement de données comportant une unité centrale, de la mémoire et un dispositif d'affichage, ainsi que des moyens de mise en veille, ledit dispositif étant caractérisé en ce qu'il comporte des moyens de commande dudit dispositif d'affichage de manière à permettre la diffusion de médias sous le contrôle d'un serveur centralisé accédant à une base de données contextuelle, ledit procédé étant basé sur la transmission périodique par ledit ordinateur d'une requête comportant un identifiant et accompagné de champs (headers) définissant des informations contextuelles destinées à être reportées audit serveur pour y être stockées dans ladite base de données, ledit serveur répondant à ladite requête au moyen d'une réponse définissant le media à diffuser, accompagnée de champs (headers) définissant une ou plusieurs actions à exécuter par ledit ordinateur lors de sa phase de veille. L'invention est, en définitive, parfaitement adaptée à de nouvelles transactions offertes par le canal de cadres numériques, voire des tablettes SB_07-FR1 - 6 - numériques et/ou ordinateurs ayant un mode "veille" utilisé sous la forme d'un cadre numérique. Description des dessins D'autres caractéristiques, but et avantages de l'invention apparaîtront à la lecture de la description et des dessins ci-après, donnés uniquement à titre d'exemples non limitatifs. Sur les dessins annexés : La figure 1 illustre une vue synoptique d'une configuration typique de déploiement d'un ensemble de cadres numériques conformes à la présente invention. La figure 2 représente l'architecture d'un mode de réalisation d'un cadre 15 numérique conforme à la présente invention. La figure 3 illustre un mode de réalisation d'un procédé de mise à jour de l'information diffusée dans le cadre numérique de la figure 2. 20 La figure 4 illustre un mode de réalisation d'un procédé de découverte (DISCOVERY) permettant au cadre de la figure 2 de collecter des informations de contexte concernant l'environnement électromagnétique de la chambre. La figure 5 illustre un mode de réalisation d'un procédé permettant de venir 25 corriger automatiquement une erreur de correspondance dans la table de correspondance de la base 160. La figure 6 illustre un mode de réalisation d'un procédé permettant une interaction entre le cadre numérique et un dispositif mobile, de type téléphone 30 mobile intelligent. La figure 7 illustre un mode de réalisation d'un procédé de transaction entre un téléphone mobile de type intelligent, une tablette tactile etc... et le serveur 150. SB_07-FR1 - 7 - Description d'un mode de réalisation préféré L'on décrit à présent comment l'on peut déployer un ensemble d'écrans 5 d'affichage ou des cadres numériques au sein d'un lieu public ou privé, et spécifiquement une structure hôtelière comportant un ensemble de chambres destinées chacune à accueillir un ou plusieurs de ces cadres. La figure 1 est une vue synoptique d'une configuration typique d'un réseau 10 utilisé au sein d'une structure hôtelière et qui offre à la clientèle une connexion à un réseau Internet 100. A cet effet, l'on dispose en général au moins deux réseaux distincts. 15 Un premier réseau est destiné à la gestion administrative de l'hôtel - particulièrement sécurisé et protégé par un premier pare-feu 10, auquel est susceptible de venir se connecter un ensemble d'ordinateurs et de périphériques utilisés par le personnel de l'hôtel, comme par exemple l'ordinateur 11 de la Réception de l'hôtel, accédant à une base de donnée propre à la gestion de l'hôtel 20 (souvent désignée par l'appellation PMS ou Property Management System dans la pratique internationale). Typiquement la base de données PMS regroupe toutes les informations relatives aux réservations de chambre, aux consommations, aux flux des entrées (Check-in) et sorties (Check-out) etc... 25 Un second réseau - en général sans fil - est également mis en place et destiné à offrir à la clientèle un accès au réseau Internet, via un second pare-feu 20. Dans un mode de réalisation particulier, on considère un ensemble de N cadres numériques 200-1 à 200-n, notamment répartis au sein des différentes 30 chambres de l'hôtel, et qui disposent également d'un accès sans fil au réseau Internet, soit via un réseau spécifique, soit via le réseau sans fil dédié aux clients (via le pare-feu 200). SB_07-FR1 - 8 - En particulier, l'on peut configurer les points d'accès composant l'infrastructure du réseau sans fil de manière à offrir un BSSID (Basic Service Set IDentifier) dédié pour les écrans ou cadres numériques.

Il est à noter que le serveur 150 est également accessible via un portail spécifique - en dehors du contexte du réseau administrateur via le pare-feu 10 ou celui de la clientèle via le par-feu 20 - de manière à permettre à des tiers ou même le personnel de l'hôtel d'accéder au système du serveur 150, même depuis leur domicile, via un ordinateur 30.

Comme on le verra lors de l'exposé des différentes procédures décrites ci-après, le réseau de cadres numériques 200-1 à 200-n a vocation à diffuser un contenu média personnalisé ou "contextuel" sous la commande d'un serveur centralisé 150, en général localisé sur un autre territoire. Ce serveur dispose d'une base de données centrale 160 collectant une multitude de paramètres et de données afférentes, non seulement à l'hôtel, à ses chambres et aux prestations offertes par celui-ci, mais également des informations plus générales concernant la météorologie locale ou nationale, l'actualité dans divers pays ainsi que diverses informations locales ou nationales.

Le but de la constitution de la base de données centrale 160, pour l'opérateur du serveur central 150, est d'offrir à une multitude d'hôtels des services de diffusion de médias réellement personnalisés en fonction de la clientèle de l'hôtel (langue, profil etc...), de la catégorie particulière de la chambre dans laquelle réside cette clientèle, des données effectives de réservation des chambres (check-in; check-out ou entrées; sorties), mais également de circonstances nationales ou locales ou d'actualité (météorologiques, actualité), et bien d'autres informations utiles, pour permettre la diffusion d'une information réellement contextuelle, à haute valeur ajoutée pour l'hôtel.

On observera, par hasard, que si l'un des restaurants de l'hôtel affiche complet, un membre du personnel pourra transmettre une information destinée à être collectée au sein de la base de données 160 de manière à éviter que le serveur SB_07-FR1 -9- 150 ne diffuse une information promotionnelle pour le restaurant complet mais, au contraire, fasse la promotion d'un autre restaurant de l'hôtel. De la même manière, la base de données 160, gérée par le serveur 150, a 5 également vocation pour diffuser une information promotionnelle pour la piscine de l'hôtel, notamment lorsque que celle-ci subit une baisse de la fréquentation. Comme on le voit, il y a un grand intérêt pour une structure hôtelière de disposer d'un outil de communication et de diffusion réellement sophistiqué, et dont 10 la réalisation, en raison de sa complexité, n'est pas envisageable sur un plan local. Inversement, il est du plus grand intérêt, pour l'opérateur du serveur 150, de pouvoir mettre son outil, et des algorithmes complexes mis au point pour définir une information réellement contextuelle à haute valeur ajoutée, à la disposition d'un grand nombre de structures hôtelières. 15 Pour assurer au serveur 150 la possibilité de collecter une information précise et de grande qualité, l'on prévoit, dans un mode de réalisation particulier, un accès à une partie du système PMS de l'hôtel de manière à accéder à un certain nombre d'informations relatives aux chambres, notamment les dates et horaires 20 d'entrées (check-in), les dates et horaires de sortie (check-out), ainsi que certaines informations spécifiques complémentaires ( rate code associé à la chambre; market code etc...) en usage dans l'hôtellerie internationale. Le serveur 150 n'aura pas besoin, le plus souvent, d'avoir accès aux 25 informations nominatives de la clientèle (qui reste une information des plus sensibles) mais il suffira de pouvoir accéder à des informations générales relatives à son profil , telle que la nationalité etc... De cette manière, le serveur 150 est en mesure de centraliser - en général 30 de manière qui reste anonyme - les flux de réservations et l'occupation des chambres d'un hôtel prédéterminé, de manière à adapter en continu l'information diffusée sur les écrans 200-1 à 200-n. SB_07-FR1 - 10 - La base de données centralise également la correspondance (mapping) entre les identifiants des cadres et les chambres d'hôtel auxquels ces cadres sont affectés.

En outre, comme on le verra plus loin, la base de données contextuelle 160 a vocation également à recevoir une quantité d'informations générées par divers capteurs localisé au sein de chacun des cadres, de manière à venir compléter l'information stockée dans la base de données centrale 160.

Le serveur 150 dispose enfin d'un accès à un serveur de contenu multimédia 170, permettant de constituer la base de la diffusion des médias, et notamment des photographies numériques pouvant servir à la constitution des fichiers MRSS suivant les procédures décrites ci-après.

L'on décrit à présent en relation avec la figure 2 l'architecture d'un cadre numérique 200 qui peut être utilisé pour réaliser chacun des cadres 200-1 à 200-n illustrés dans la figure 1. Le cadre numérique 200 présente une structure organisée suivant la constitution générale d'un cadre numérique classique, c'est à dire architecturé autour d'un processeur ou d'une unité centrale 2010 disposant d'un accès à de la mémoire RAM 200 ou ROM 230 ( qui pourra être également tout type de mémoire permanente ou re-programmable telle que EEPROM).

Le cadre dispose d'une unité d'affichage 220, d'une unité de communication sans fil 270, répondant par exemple à une interface 802.11 (Wifi) et, optionnellement, d'une carte réseau LAN 240 (Local Access Network) pouvant servir à des fins de configuration. A titre optionnel, le cadre pourra disposer d'éléments supplémentaires, comme par exemple d'une unité audio, voire un générateur de parfums. D'une manière générale, l'architecture d'un tel dispositif de cadre numérique est bien connue d'un homme du métier et il n'est pas nécessaire ni même utile de venir alourdir l'exposé par de telles considérations générales. SB_07-FR1 Il suffit de noter que, dans un mode de réalisation particulier, le cadre numérique comporte une unité de capteurs, dotée d'au moins un capteur, par exemple choisi dans la liste nullement limitative qui suit: - un capteur de mouvement, notamment basé sur une détection infra-rouge; - un capteur de luminosité; - des moyens de localisation; - un ou plusieurs capteurs de sécurité ( détecteur de fumée etc..) - un capteur de type boussole etc...

L'on pourra aussi aménager un dispositif de bouton poussoir à l'avant ou à l'arrière du cadre de manière à permettre une interactivité minimale, étant entendu que l'on décrira plus loin un procédé d'interaction avec le cadre numérique qui sera bien plus élégant et sophistiqué. Néanmoins, dans certaines circonstances, un simple bouton poussoir pourra être utile, notamment en combinaison avec un miniappareil photo (situé à l'arrière du cadre) qui pourra utilement servir, par exemple, à la prise d'une photographie de la plaque d'identification de la chambre à laquelle est destinée le cadre numérique.

Les différentes informations générées par les différents capteurs pourront être collectées et reportées au serveur, au sein d'un fichier XML spécifique constituant une sorte de "signature numérique", dans le but de venir enrichir la base de données contextuelle 160, comme cela apparaîtra avec plus de précision dans la suite.

L'on décrit à présent, en relation avec la figure 3, le mécanisme général de mise à jour de contenus multimédias sous le contrôle du serveur centralisé 150.

SB_07-FR1 - 12 - 1. Procédé de mise à jour de l'information diffusée par le cadre numérique De manière à permettre à chaque cadre numérique 200 de diffuser une information réellement contextuelle, qui tient compte non seulement du profil de l'hôtel, de la chambre et du client qui y réside, mais également d'informations contextuelles diverses (notamment l'heure locale, la météo locale, l'actualité..., voire de circonstances diverses) l'on dispose d'un mécanisme de "polling" ou de mise à jour périodique exécuté par chacun des cadres numériques 200-n.

Ce mécanisme de mise à jour ("polling") est basé sur la transmission périodique au serveur centralisé 150 de requêtes HTTP (Hyper Text Trans fer Protocol) par chacun des cadres 200 via le pare-feu 20 (qui en général est perméable aux requête HTTP) et le réseau Internet. En réponse à ces requêtes, le serveur 150 transmet à chacun des cadres, un fichier MRSS ou tout fichier XML équivalent spécifique, individualisé, définissant les U.R.L. (Uniform Resource Locator) des images à télécharger/afficher avec leur durée d'affichage respective. De préférence, chaque cadre 200 transmet une requête HTTP qui pourra être un GET ou un POST, optionnellement associé à des champs ( Query strings ou 20 "headers") comportant des informations spécifiques décrites ci-après, pour solliciter les mises à jour du programme d'affichage (slide-show). Le procédé est décrit en relation avec la figure 3. 25 Dans une étape 300, le cadre 200-n transmet une requête HTTP comportant notamment l'identifiant du cadre, par exemple l'adresse MAC (Medium Access Layer) de l'unité 270 ou tout autre identifiant connu du serveur 150 permettant un accès à la base de données 160 dans le but de déterminer, en temps réel, le programme de diffusion (slideshow) couramment affiché. 30 Dans un mode de réalisation particulier, le cadre 200 accompagne cette requête HTTP GET ou POST d'un certain nombre de champs ("headers") destinées à la transmission d'informations contextuelles complémentaire propres au cadre numérique 200, dans le but de venir enrichir l'information contextuelle stockée au SB_07-FR1 - 13 - sein de la base 160 et qui pourront ainsi venir opportunément servir à la définition du programme d'affichage (slideshow) à afficher. C'est ainsi que, par exemple, lorsque le capteur détecte une luminosité faible au sein de la chambre, cette information, associée à l'heure locale déterminée par le serveur, pourra être interprétée par ce dernier comme étant un critère fort que le client de l'hôtel souhaite se reposer et qu'il n'est certainement pas opportun de diffuser un quelconque message lumineux.

Au contraire, dès l'arrivée du client dans sa chambre à la suite de la formalité de "check-in" auprès de la Réception de l'hôtel, que le serveur pourra détecter au moyen d'un accès aux informations de réservation (PMS) émanant du système d'administration de l'hôtel, le serveur 150 pourra juger opportun de diffuser un premier programme d'affichage de bienvenue, dans la langue maternelle du client, dans le but de présenter tout ou partie des prestations offertes par l'hôtel. Comme on le voit, la constitution d'une base de données centralisée 160, rassemblant de multiples informations émanant de diverses sources notamment celles émanant des cadres numériques, permet la réalisation d'un serveur centralisé réellement efficace, parce qu'officiant sur une grande échelle pour plusieurs dizaines de milliers de cadres numériques, de manière à diffuser une information promotionnelle à haute valeur ajoutée. Dans un mode de réalisation particulier, le cadre numérique 200 transmet également, dans un champ ("header) spécifique afférent à la requête GET ou POST, une demande sollicitant l'heure de la part du serveur 150. Cette information permettra au cadre de déterminer le bon acheminement des requêtes jusqu'au serveur 150 et notamment détectera toute tentative du fournisseur national d'accès au réseau INTERNET de se substituer au serveur 150 pour la transmission d'une réponse aux requêtes... Dans une étape 301, le serveur 150 reçoit la requête émanant du cadre 200 et stocke en mémoire les informations contextuelles, potentiellement contenues, dans un registre (logging). SB_07-FR1 - 14 - Puis, dans une étape 302 optionnelle, le serveur 150 procède à une analyse des informations contextuelles reportées par le cadre de manière à identifier, le cas échéant, d'un éventuel problème d'affectation dans la base de correspondance (mapping) de la base de données. Cette procédure sera décrite plus en détail ci- après. Pour l'instant, il suffit de noter que si un tel problème d'affectation devait être identifié par le serveur, ce dernier transmettrait alors au cadre numérique considéré un programme de diffusion générique, par exemple en langue anglaise. Puis, dans une étape 303, le serveur accède à la base de donnée 10 contextuelle 160 et prépare une réponse à la requête du cadre, en déterminant notamment s'il y a lieu de commuter le programme d'affichage sur un nouveau programme, comme ce que l'on voit sur la figure 3, avec le test de l'étape 304. Dans le cas où aucun nouveau programme s'avère être opportun , le procédé 15 poursuit avec une étape 305, qui est la préparation et la transmission d'une réponse comportant un code HTTP de type "304" (à ne pas confondre avec l'étape 304 ci-dessus), précisant qu'il n'y a pas lieu de modifier le fichier MRSS en cours d'affichage. Il est à noter, et ceci est un avantage significatif de la solution proposé, la réponse de type "304" peut en outre être associée à un ou plusieurs champs 20 ("headers") comportant, comme on le verra ci-après, un ensemble d'actions à exécuter sur le cadre considéré. Puis cette réponse HTTP de type "304" est reçue par le cadre 200 dans une étape 306, et le procédé poursuit sans attendre par l'exécution des instructions du 25 serveur 150 dans l'étape 313. Dans le cas contraire, si le test de l'étape 304 conduit à la détermination d'un nouveau programme à diffuser, le procédé poursuit avec une étape 307, dans laquelle la liste des images à afficher est construite au sein d'un fichier MRSS 30 contextuel, ou tout fichier XML équivalent, en tenant compte des nombreuses informations contextuelles stockées dans la base 160 et comportant la liste des URL des images à télécharger depuis le serveur de média 170 et à afficher sur le cadre numérique. S13_07-FR1 - 15 - Dans une étape 308, le serveur 150 construit une réponse de type "HTTP 200" -, comportant en annexe le fichier MRSS ou XML, éventuellement associés à un ou plusieurs champs ("headers") comportant, comme on le verra ci-après, un ensemble d'actions à exécuter sur le cadre considéré.

Comme on le voit, dans un mode de réalisation particulier, le serveur 150 est capable, en formalisant une réponse de circonstance destinée au cadre 200, de transmettre au moyen d'un jeu de champs ("headers") un ensemble d'actions que l'on décrira ci-après, et qui permettront une gestion amélioré du part de cadres numériques. Optionnellement, le serveur 150 peut également insérer une information de datage destinée au cadre de manière à lui permettre une évaluation du temps de transmission des requêtes et, par conséquent, une évaluation de la qualité de service de l'opérateur national. Puis, dans une étape 309, la réponse est reçue au sein du cadre 200 qui procède alors à son traitement.

En particulier, le cadre 200 procède, dans une étape 310, à la comparaison entre le fichier MRSS reçu et celui en cours de diffusion de manière à vérifier que les deux sont bien distincts. Il est en effet opportun de vérifier que l'opérateur national n'applique par une politique de "cache" inconvenante visant, dans un souci de préserver sa bande passante, à se substituer au serveur 150 pour renvoyer en réponse plusieurs fois le même fichier MRSS à afficher, alors même que le serveur 150 aurait son propre fichier MRSS à transmettre au cadre numérique considéré. Le test de l'étape 310 permet ainsi de valider la réception du fichier de manière à éviter de perturber le déroulement d'un programme en venant diffuser, de 30 manière anachronique, le même programme. Si les deux fichiers coïncident, alors le cadre 200 maintient la diffusion XML en cours d'affichage dans une étape 311 et reporte l'incident dans un registre SB_07-FR1 - 16 - approprié, de manière à pouvoir le reporter au serveur 150 lors de la prochaine requête HTTP GET ou POST. Si les deux fichiers sont bien distincts, alors le cadre procède 5 immédiatement, dans une étape 312, au téléchargement des nouvelles images identifiées dans le fichier XML et procède ainsi sans attendre la fin du programme en cours la diffusion du nouveau programme. Puis, dans une étape 313, le cadre 200 procède à l'exécution des instructions 10 accompagnant la réponse du serveur 150. Comme on le voit, on aménage parallèlement à la procédure de mise à jour (polling) , une véritable communication permettant l'échange d'informations contextuelles et de commandes à exécuter par la cadre. 15 Dans un mode de réalisation particulier les instructions susceptibles d'être reçues par le cadre 200 permettent l'exécution des actions suivantes: CHANGE SETTING: cette action permet de modifier la fréquence de la 20 période de "polling". Ainsi, cette action extrêmement utile permet de fixer une fréquence basse (par exemple une requête HTTP toutes les dix minutes) lors d'un affichage relativement "passif", et d'aménager une fréquence de "polling" relativement élevée (par exemple toutes les dix secondes) dans certaines circonstances, par exemple lors d'une transaction à finaliser avec le client comme 25 ce que l'on décrira dans la figure 6. DISPLAY OFF/ON : cette action permet de forcer l'extinction ou l'allumage de l'écran numérique, permettant ainsi de forcer une économie d'énergie lorsque la chambre d'hôtel n'est pas occupée. 30 CHECK ROOM NAME : cette action vise à permettre une éventuelle correction dans la table de correspondance entre l'identifiant du cadre numérique et le numéro de chambre auquel ce cadre est censé correspondre. SB_07-FR1 - 17 - CACHE TEST: cette action vise à permettre de rendre une mesure (metrics) relative à la politique de "cache" du fournisseur d'accès à Internet, et notamment en permettant de déterminer si le fournisseur d'accès respecte les directives de "cache control" ainsi qu'une mesure précise du temps de transit des instructions via le réseau et de retour. EXPRESS NOTE: cette action permet la transmission d'une note qui sera diffusée sur le cadre, à la place de ou en juxtaposition du médias couramment diffusé. Cette action permet donc à un membre du personnel de l'hôtel, par exemple depuis l'ordinateur portable 30 accédant au portail du serveur 150, de transmettre très simplement un message au résident de la chambre. DISCOVERY: cette action vise à initier une opération de découverte des points d'accès et, le cas échéant, des cadres numériques voisins les plus proches, 15 comme ce que l'on verra plus précisément en relation avec la figure 4. Les actions qui ont été décrites précédemment ne sont nullement limitatives et l'on pourra envisager de multiples autres actions susceptibles d'être exécutées à distance par le cadre numérique 200, en réception d'une instruction correspondante 20 accompagnant les réponses HTTP "200" ou "304". Dès lors que l'action correspondant à l'instruction reçue a été exécutée lors de l'étape 313, le procédé retourne à l'étape 300 pour procéder à un nouveau cycle de "polling" ou mise à jour. 25 Comme on le voit, le mécanisme de mise à jour qui est proposé permet une gestion à très grande échelle, puisque pouvant se déployant sur plusieurs milliers de cadres numériques susceptibles d'être répartis dans des centaines d'hôtels localisés dans divers continents, et ce sans qu'il soit nécessaire de prévoir le 30 moindre serveur local disposé au sein des réseaux locaux des hôtels ce qui, certainement, compliquerait significativement la gestion des cadres. Il en résulte une solution simple et pourtant très performante de gérer sur un plan international, au moyen d'un serveur centralisé, la diffusion d'une information S13_07-FR1 - 18 - contextuelle au sein de centaines de structures hôtelières, même lorsque celles-ci sont dépourvues de toute compétence particulière dans ce domaine. Par cette gestion centralisée, il en résulte la possibilité de diffuser une 5 information contextuelle d'un grand intérêt, basée sur un grand nombre d'informations de contexte disponible dans la base 160 mais également à partir d'une riche source documentaire que recèle le serveur de médias 170. Les clients bénéficient ainsi d'une information riche et variée, proprement 10 conditionnée en fonction de leur nationalité, de leur culture et de leur profil, et qui pourra être diffusée sur le cadre numérique disposé dans leur chambre, et ce sans requérir la moindre expertise technique ou marketing de la part du personnel de l'hôtel qui peut donc vaquer à d'autres tâches. 15 Par ailleurs, comme on va le voir dans la suite, le cadre numérique comporte un grand nombre de fonctionnalités permettant de rendre plus fiable la gestion de la diffusion d'une information réellement contextuelle, mais offre également la possibilité de nouveaux services. 20 2. Informations contextuelles reportées par le cadre numérique Les informations contextuelles reportées par le cadre permettent en premier lieu au serveur 150 de connaître l'état interne de celui-ci, ou la valeur de certains de ses registres. 25 C'est ainsi que, lors de la transmission des requêtes HTTP GET ou POST, un cadre 200 pourra reporter au serveur 150 l'état interne de ses registres, par exemple l'information relative à la luminosité de l'affichage ou toute autre information utiles au serveurs. 30 Plus généralement, les informations contextuelles générées par les capteurs pourront être reportées au serveur. C'est ainsi que le capteur de luminosité extérieur du cadre permettra de déterminer si les rideaux sont tirés de manière à en SB07-FR1 - 19 - tirer des conséquences opportunes pour la gestion du média à diffuser (ou à ne pas diffuser). Mais dans un mode de réalisation particulier, les informations contextuelles 5 reportées par le cadre visent également à accroître la fiabilité du procédé de diffusion à distance. En effet, la qualité de l'information diffusée sur les cadres numériques dépend pour une grande part de la qualité des médias qui sont stockés sur le 10 serveur 170 mais surtout du degré de sophistication et de la pertinence des algorithmes utilisés par le serveur 150 dans le choix de ces médias lors de l'exploitation de la base de données contextuelles 160. L'opérateur du serveur 150 est très certainement responsable à cet égard de 15 la qualité de l'information qui est diffusée sur les cadres. Pour autant cette information ne sera pertinente que pour autant la correspondance (mapping) entre les cadres et les numéros de chambres qui sera répertoriée au sein de la base 160 correspondra à la réalité "sur le terrain". 20 Or cette correspondance échappe, pour une grande part, au contrôle de l'opérateur du serveur 150, lequel ne peut vérifier, au jour le jour, qu'un cadre donné se trouve bien dans la chambre dans laquelle il est censé se trouver. Et ce tout spécifiquement lorsque l'hôtel et le serveur 150 sont distants de plusieurs milliers de 25 kilomètres.... Sans doute, l'on peut imaginer que l'opérateur et l'hôtelier seront soucieux, du moins lors d'une première installation des cadres numériques, de faire coïncider chaque cadre avec sa chambre effective. 30 Cependant, il n'est pas exclu qu'au cours de l'exploitation de la structure hôtelière, des cadres soient déplacés d'une chambre à l'autre (notamment pour remplacer des cadres défectueux), et ce sans en aviser a priori ou a posteriori l'opérateur du réseau 150. SB_07-FR1 - 20 - Pour permettre au serveur 150 de pouvoir compter sur une information de correspondance précise et fiable entre les identifiants des cadres et les numéros de chambre (ROOM NAME dans la pratique hôtelière), le cadre numérique 200 reporte des informations au serveur 150, générés par ses capteurs internes, qui non seulement seront utilisées pour la définition et la construction du message MRSS à diffuser, mais également pour détecter un éventuel problème de correspondance (mapping) au niveau de la base de données 160 entre l'identifiant du cadre et le numéro de la chambre "ROOM NAME" à laquelle ce cadre est censé correspondre.

A cet effet, dans un mode de réalisation particulier, le cadre numérique 200 comporte, comme on l'a vu avec l'exposé de la figure 2, un ensemble de capteurs destinés à collecter diverses informations, lesquelles informations sont transmises au serveur 150 via des champs ("headers") spécifiques, lors de l'étape 300 du procédé de la figure 3.

En particulier, le cadre comporte un capteur destiné à collecter une information de localisation. Dans un premier mode de réalisation, l'on pourra prévoir un capteur de type GPS (Global Positionning System), permettant de rassembler les coordonnées géographiques précises du cadre numérique 200. L'on peut sans doute imaginer que l'infrastructure de l'hôtel ne permette pas, dans toutes les chambres desservies par des cadres numériques, une réception adéquate du faible signal GPS transmis par les satellites. Néanmoins, dès lors qu'une telle information sera accessible, ce qui sera notamment le cas lorsque le cadre sera disposé proche d'une baie vitrée ou d'une terrasse, celle information pourra être enregistrée dans un registre approprié au sein du cadre de manière à pouvoir être reportée au serveur 150, par exemple lors de l'étape 300 du procédé de la figure 3. Alternativement, l'on pourra utiliser tout autre procédé de localisation, notamment le procédé décrit dans le brevet EP1330074, intitulé "dispositif de localisation d'appareils de réseau de données" déposé le 21 Janvier 2002, et inventé par l'inventeur de la présente demande de brevet, et basé sur l'utilisation d'un dispositif branché sur la prise électrique permettant l'alimentation du cadre numérique. SB_07-FR1 - 21 - Toute autre combinaison de procédés et moyens pouvant servir à une localisation utile est envisageable. Par ailleurs, dans la situation particulière où le serveur 150 ne dispose pas 5 d'une géolocalisation précise du cadre, notamment parce qu'une information GPS n'est pas accessible, le serveur 150 procède à l'analyse de l'ensemble des informations collectées par le cadre, a titre de signature, de manière à déterminer, sinon une localisation précise, du moins un ensemble d'informations concordantes permettant, le cas échéant, d'identifier un changement significatif et par conséquent 10 un potentiel déplacement du cadre numérique dans une autre chambre de l'hôtel. C'est ainsi que, la comparaison du niveau de luminosité capté par le cadre numérique 200, par rapport au niveau des voisins immédiats ou à celui capté à la même heure le jour précédent, permet au serveur 150 (lequel dispose par ailleurs 15 d'informations précises sur la météorologie locale) de pressentir un tel problème de correspondance (mapping) au sein de la base 160 entre le numéro de la chambre (ROOM NAME) et l'identifiant du cadre. Tout autre information, par exemple une information relative à l'alimentation 20 électrique du cadre ou encore une information relevée par une boussole électronique interne au cadre pourrait également servir à venir enrichir les informations de contexte qui sont reportées au serveur lors de l'étape 300. En pratique, toutes ces informations de contexte pourront être collectées au sein d'un fichier XML, et prendra ainsi la forme d'un véritable fichier de "signature" susceptible 25 de permettre la détection d'un mouvement du cadre numérique. Afin de renforcer la sécurité de la table de correspondance (mapping) stockée au sein de la base 160, le cadre numérique intègre, dans un mode de réalisation préféré, une fonction spécifique de "découverte" (DISCOVERY) de 30 l'environnement électromagnétique du cadre, pouvant être déclenchée sur instruction spécifique reçue de la part du serveur 150, et qui est à présent illustrée en relation avec la figure 4. SB_07-FR1 - 22 - Dans une première étape 401, le cadre 200 reçoit, au sein de la réponse HTTP "304" ou "200" émise par le serveur, une instruction DISCOVERY comprise dans un champ ("header") spécifique lors de l'étape 313 du procédé général de mise à jour de la figure 3.

Puis, dans une étape 402, le cadre 200 décode cette instruction et procède à une première recherche, en mode infrastructure, des réseaux sans fil (WIFI par exemple) de manière à identifier les points d'accès visibles ainsi que le rapport signal sur bruit (S/N) correspondant à ces points d'accès.

Puis dans une étape 403, le cadre 200 dresse une liste des points d'accès et des rapports S/N, et notamment des informations suivantes: BSSID (Basic Service Set IDentifier) SSID (Service Set IDentifier) le numéro du canal de fréquence sur lequel le point d'accès opère; la qualité du signal; un critère relatif au cryptage ; Ces diverses informations collectées par le cadre numérique sont alors intégrées au sein du fichier de signature de manière à venir enrichir les autres informations déjà présentes au sein de ce fichier. De cette manière, l'ensemble des informations pourra être reportée, soit via des champs (headers) spécifiques accompagnant les requêtes GET et/ou POST ou, alternativement, peut être intégré dans un fichier de signature spécifique, faisant l'objet d'une transmission via à une requête HTTP POST. Optionnellement, dans une étape 404, après avoir dressé la liste précédente, le cadre 200 met en oeuvre une procédure de découverte suivant un mode "adhoc", de manière à identifier, non plus les points d'accès utilisable en mode infrastructure, mais les autres cadres numériques situés dans les chambres voisines. A cet égard, l'on pourra faire deux observations: S13_07-FR1 - 23 - En premier lieu, cette procédure de découverte en mode adhoc suppose que le serveur aura envoyé une instruction de DISCOVERY semblable à tous les cadres censés se trouver dans un même voisinage, de manière à leur permettre de se découvrir mutuellement.

En second lieu, il n'est pas nécessaire que la procédure de découverte adhoc se déroule au-delà de la simple collecte des informations concernant les trois ou quatre plus proches voisins, permettant la mise à jour du fichier XML mentionné dans l'étape 403. En effet, il n'est pas requis, dans ce contexte donné, de io déterminer un quelconque routage entre les cadres numériques pour permettre l'établissement d'un réseau, en sorte que la procédure adhoc n'aura pas vocation à aboutir. Il suffit, pour rassembler une information riche en qualité, et répertorié dans le 15 fichier XML de signature (ou de DISCOVERY), de découvrir les plus proches voisins de manière à permettre l'enrichissement de la liste déjà dressée en mode infrastructure (ie la découverte des points d'accès) pour, finalement, reporter cette information au serveur 150. 20 Puis dans une étape 405, le cadre numérique transmet, lors du procédé de polling décrit précédemment, le fichier XML de DISCOVERY ou toute autre éléments d'information susceptible de constituer un élément de la signature de l'environnement électromagnétique du cadre numérique considéré. 25 Cette information est ensuite reçue par le serveur 150 qui peut alors la traiter dans une étape 406 et déterminer, en fonction des informations déjà stockées dans sa base de données 160, et déterminer, le cas échéant, un problème potentiel au niveau de la table de correspondance (mapping) dans la base 160. 30 Comme on le voit, les cadres numériques apportent de nouvelles fonctionnalités qui vont bien au-delà d'une simple diffusion de médias au sein d'un réseau local. SB_07-FR1 - 24 - Grâce aux nombreuses informations collectées par les capteurs, et qui peuvent être reportées au serveur 150, celui-ci peut, d'une part, vérifier de manière constante la précision de la table de correspondance utilisée au sein de la base 160.

L'on décrit à présent, en relation avec la figure 5, un procédé mis en oeuvre permettant de rétablir une erreur identifiée dans la table de correspondance (mapping) au sein de la base 160 pour un cadre numérique donné.

Dans une étape 501, le serveur 150 consulte la base de données pour lire les informations de "check-in" et de "check-out" permettant de déterminer la situation précise en ce qui concerne l'occupation de la chambre associée au cadre numérique 200 identifié comme problème.

Puis le procédé poursuit avec une étape 502 qui est un test pour déterminer si la chambre apparaît comme étant "occupée", c'est à dire si l'on se trouve dans une période entre un "check-in" et un "check-out". Dans l'affirmative, le procédé poursuit avec une étape 503 au cours de laquelle le serveur 150 procède à la diffusion, suivant le procédé décrit en relation avec la figure 3, d'une information générique, par exemple en langue anglaise de manière à prévenir toute difficulté potentielle avec le client résidant dans la chambre.

Dans le cas contraire, si le serveur 150 a identifié que la chambre correspondante n'est pas occupée, alors le serveur 150 programme, lors d'une étape 504, la diffusion d'un message d'alerte à destination du personnel de l'hôtel et notamment des femmes de chambres pouvant réceptionner ce message.

Il est à noter que, et c'est un avantage du présent mode de réalisation, en règle générale le serveur 150 commande dans un souci d'économie d'énergie l'extinction du cadre numérique en dehors des périodes d'occupation effective, en sorte que les femmes de ménage seront particulièrement sensibles à un cadre S13_07-FR1 - 25 - numérique affichant un message d'alerte alors que ce même cadre est d'ordinaire éteint. Une information de correction peut alors être saisie, dans une étape 505, pour rétablir le bon numéro de chambre (ROOM NAME), suivant des modalités diverses. A cet effet, l'on pourra imaginer diverses interactions possibles avec le cadre numérique, et notamment via l'utilisation du bouton poussoir mentionné précédemment.

Dans un mode de réalisation particulier, le cadre 200 comporte un mini- appareil photo, disposé à l'arrière du cadre, permettant de stocker une photo en basse résolution, et pouvant être commandé au moyen du dispositif de bouton poussoir mentionné précédemment. De cette manière, en répondant aux instructions affichées sur le cadre numérique, une femme de ménage ou un membre quelconque du personnel de l'hôtel peut procéder à la capture d'une photographie du numéro de chambre placardé sur la porte de l'hôtel . L'information de correction est ensuite transmise par le cadre 200, lors d'une étape 506, et réceptionnée par le serveur 150, qui peut la traiter et notamment 20 l'enregistrer. Le serveur 150 corrige en particulier, dans une étape 507, la table de correspondance (mapping) entre l'identifiant et le numéro de chambre (ROOM NAME), de manière à pouvoir ensuite, dans une étape 508, commuter sur le mode 25 de diffusion contextuel du médias. Le procédé qui vient d'être décrit permet très simplement de transmettre une information - en l'espèce un fichier d'image - au serveur 150 de manière à corriger une éventuelle non concordance dans la table de correspondance entre les cadres 30 et leurs numéros de chambres, qui pourrait être préjudiciable à la pertinence de l'information numérique diffusée par ceux-ci. Clairement toute autre méthode d'interaction est possible. SB_07-FR1 - 26 - Dans un mode de réalisation particulier, le cadre numérique, bien qu'il soit dénué de tout clavier, comporte en outre une fonctionnalité d'interaction avec un téléphone mobile ou intelligent (smartphone) de manière à permettre, ici également, de confirmer le numéro de chambre affecté au cadre. 3. Interaction avec le cadre numérique et nouveaux services Dans un mode de réalisation particulier, le cadre comporte une fonctionnalité particulière permettant une interaction des plus utiles avec un téléphone mobile, de type intelligent (smartphone), une tablette tactile etc... A cet effet, dès l'arrivée du client dans sa chambre, ce qui est détecté par le 15 serveur 150 en fonction de l'heure d'arrivée (Check-in), le cadre peut afficher un code QR destiné à comporter une URL pour l'installation d'une application et, de préférence, une URL en direction du serveur 150. De cette manière, le client de l'hôtel, dès lors qu'il arrive dans sa chambre, 20 peut voir son mobile dotée d'une fonction d'interaction, comme cela est décrit en relation avec la figure 6. Dans une étape 601, le procédé comporte la transmission, par le serveur 150, d'un affichage sur le cadre 200 distant, comportant un code QR. 25 Ce code QR peut être scanné par le client de l'hôtel, au moyen d'une application quelconque (en général pré chargée sur un téléphone mobile), de type MOBILE TAG ou autre. Ce code QR permet alors l'ouverture du navigateur du téléphone intelligent, à l'adresse pointée par l'URL présent dans le code QR. 30 Puis, dans une étape 602, le serveur reçoit une requête HTTP émanant de ce téléphone mobile comportant l'information d'identification du cadre numérique 200 ayant affiché le code QR, et stocke cette information. SB_07-FR1 - 27 - Dès réception de cette requête, le serveur 150 peut établir une correspondance, c'est à dire un lien entre le téléphone mobile d'où émane la requête reçue et le cadre numérique 200 identifié dans cette requête.

Il en résulte que le serveur est alors capable de commander l'affichage d'informations affichées quasi-simultanément sur le cadre numérique 200 et sur l'écran du téléphone mobile appartenant au client. A cet effet, dans une étape 603, le serveur 150 procède à la transmission, via le propre accès "données" (DATA) du téléphone du client, d'une page web, proprement formatée, comportant diverses informations et/ou d'outils permettant notamment une possible interaction entre le téléphone intelligent du client et l'affichage contextuel sur le cadre numérique 200.

Dans une étape 604, le serveur 150 procède à la commande de l'information contextuelle diffusée sur le cadre numérique 200, via le procédé de "polling" précédemment, de manière à venir soutenir l'interaction avec la page web affichée sur l'écran du mobile.

En particulier, dans une étape 604, le serveur 150 peut ainsi commander un double affichage sur l'écran du mobile et sur le cadre numérique 200, de manière à soutenir une véritable proposition de transaction simultanément affichées sur les deux éléments. En effet, le serveur 150 peut tout à fait détecter une correspondance entre les informations saisies par le client sur son téléphone mobile, et les informations potentiellement diffusées par le cadre numérique via son propre réseau wifi, formalisant une véritable transaction se déroulant au travers les deux réseaux et les deux sessions engagées avec le serveur. Le client peut ainsi, en recourant simplement à une URL affichée sur le "bureau" de son téléphone mobile intelligent, procéder à une réelle interaction qui apparaît en toute transparence et ce malgré le fait que chacun des deux dispositifs dispose de son propre réseau, et notamment du pare-feu 20 empêchant en principe toute requête directe transmise au cadre numérique 200. S13_07-FR1 - 28 - Cette interaction aboutit, en général avec l'étape 606, par la validation de la transaction considérée. Comme on le voit, le procédé permet de créer une véritable interaction qui est complètement transparente pour le client, lequel ne peut se douter de la réalité de ces sessions de communication parallèles qui sont initiées et gérées par le serveur centralisé, et qui permettent, de manière très avantageuse, d'encadrer et de finaliser toutes sortes de transactions possibles.

En particulier, l'on peut imaginer qu'un photographe professionnel ait pris un ensemble de photographies en haute définition durant le séjour du client et/ou de sa famille, et ait stocké ces mêmes photos dans un espace protégé du serveur 170. Le serveur pourra ainsi proposer, une transaction au client en commandant 15 un affichage sur le cadre numérique correspondant à un affichage sur le téléphone mobile intelligent de ce même client. Cette transaction peut porter, en particulier, sur la sélection d'une ou plusieurs photos affichées sur le cadre numérique, en vue de leur achat potentiel.

20 Cette sélection peut être effectuée très efficacement, via le clavier et l'écran du téléphone mobile permettant la saisie de données qui sont transmises au serveur 150 via l'accès DONNEES du téléphone mobile. Dès lors que le client formalise une telle sélection, l'information 25 correspondante est reçue par le serveur, lequel peut programmer une information de confirmation sur le cadre numérique et/ou l'écran du téléphone pour valider la transaction. Une fois la transaction validée, le serveur peut alors transmettre un lien au 30 téléphone mobile ou valider le téléchargement de la photographie correspondante. Comme on le voit, le nouveau procédé qui est décrit permet, en venant créer un lien au moyen du code QR affiché sur un cadre numérique donné et un SB_07-FR1 - 29 - téléphone mobile intelligent, d'ouvrir la voie vers une réelle interaction entre le propriétaire du téléphone et le cadre numérique commandé par le serveur 150. Avec la possibilité d'une vaste gammes d'applications et de nouveaux services qui est ainsi offerte à la clientèle de l'hôtel. En particulier, dès la validation de la transaction, l'achat des photos pourra être directement facturées au client lors de son départ de l'hôtel, lors de la formalité de "check-out". Le procédé qui vient d'être décrit en relation avec la figure 6 montre la 10 manière de procéder à une interaction entre le mobile du client et le cadre numérique grâce au code QR affiché sur le cadre numérique. Dans un mode de réalisation particulier, le code QR permet l'installation d'une application qui pourra être directement téléchargée depuis le serveur 150 et 15 qui est destinée à permettre au mobile de transmettre des informations de géolocalisation, similaires à celles décrites précédemment pour le cadre, dans le but de permettre une offre contextuelle de nouveaux services au titulaire du mobile. Un tel procédé est décrit en relation avec la figure 7.

20 Dans une étape 701, le procédé lance l'application et établit une connexion avec le serveur centralisé 150 via le propre accès de données du mobile. Puis, dans une étape 702, le procédé procède à la collecte d'informations 25 contextuelles, notamment liée à la localisation du mobile. A cet effet, l'on pourra collecter les informations potentiellement disponible du capteur GPS. Alternativement, dans un contexte "internet", dans lequel une telle information n'était pas disponible, le procédé procède à la collecte d'informations 30 d'infrastructures utilisées par les cadres numériques décrits précédemment, et notamment les points d'accès, leur caractéristiques (SSID) et les caractéristiques du signal. SB_07-FR1 - 30 - Ces informations contextuelles sont collectées pour ensuite, dans une étape 703, être transférées au serveur 150. Puis, dans une étape 704, le serveur 150 procède au traitement des données 5 collectées de manière à permettre l'exploitation de la base de données contextuelle 160 pour définir une offre de service circonstanciée, en tenant notamment compte des informations reportées par le mobile. Cette offre de service est ensuite transmise par ce dernier, pour être ensuite 10 réceptionnée, dans une étape 705, par le mobile. Dans une étape 706, l'utilisateur procède, le cas échéant, à la finalisation de la transaction de manière à valider le service qui est offert.

15 Puis, dans une étape optionnelle, un message de confirmation est transmis au mobile et, potentiellement, au cadre numérique correspondant à ce dernier. Comme on le voit, la mise en place du réseau général de cadres numériques, sous la commande d'un serveur centralisé, peut être le support d'un nouvel 20 ensemble de services qui peuvent être offerts à la clientèle des établissements hôteliers, par le vecteur des cadres numériques décrits mais également directement depuis les téléphone mobiles intelligents de la clientèle. L'on voit sur cet exemple simple le grand intérêt que l'on peut trouver dans le 25 déploiement d'un tel réseau. L'on notera enfin que bien que l'on ait décrit avec précision les modes de réalisation en relation avec un écran de type "cadre numérique", qui correspond clairement au mode de réalisation préféré, l'on pourra réaliser les écrans au moyen 30 de tout dispositif quelconque, et notamment à partir d'une tablette tactile, telle qu'on la trouve couramment dans les commerces grand publics et qui, contrairement au cadre numérique comportent également la possibilité d'afficher un clavier tactile sur l'écran. SB_07-FR1 -31 - De manière plus générale encore, l'on pourra recourir à un ordinateur de type portable - voire un ordinateur de bureau - lequel comportera une unité centrale, un clavier et un dispositif d'affichage. Un dispositif de mise en veille de l'ordinateur et des moyens de commande du dispositif d'affichage sont également disposés de 5 manière à mettre en oeuvre les procédures décrites précédemment pour le cadre numérique, dans le but de permettre - dans le mode de veille - la diffusion de médias sous le contrôle du serveur 150 accédant à la base de données contextuelle. Comme pour le cadre numérique, le procédé est basé sur la transmission périodique par l'ordinateur - durant la phase de veille - d'une requête 10 comportant un identifiant et accompagné de champs (headers) définissant des informations contextuelles destinées à être reportées au serveur 150 pour y être stockées dans la base de données. Le serveur répond à la requête au moyen d'une réponse définissant le media à diffuser, accompagnée de champs (headers) définissant une ou plusieurs actions à exécuter par ledit ordinateur lors de sa phase 15 de veille. Comme on le voit toutes les procédures qui ont été décrites en relation avec le cadre numérique sont alors applicables à l'ordinateur lorsque ce dernier est dans sa phase de veille de type" cadre numérique".

20 Comme on le voit, l'invention offre de multiples applications.

25 30 S13_07-FR1

Claims (10)

1. REVENDICATIONS1. Procédé de commande de la diffusion de médias par un dispositif d'affichage sous le contrôle d'un serveur centralisé (150) accédant à une base de données contextuelle (160), ledit procédé étant basé sur la transmission périodique par ledit dispositif affichage (200) d'une requête comportant un identifiant dudit dispositif et accompagné de champs (headers) définissant des informations contextuelles destinées à être reportées audit serveur (150) pour y être stockées dans ladite base de données (160), ledit serveur répondant à ladite requête au moyen d'une réponse définissant le media à diffuser, accompagnée de champs (headers) définissant une ou plusieurs actions à exécuter par ledit dispositif d'affichage (200), l'écran d'affichage étant un écran d'une tablette tactile ou celui d'un ordinateur utilisé lors d'une phase de veille.
2. 2. Procédé selon la revendication 1 caractérisé en ce que lesdites requêtes sont des requêtes HTTP GET ou POST comportant l'identifiant du cadre et son adresse IP accompagné de champs (headers) définissant des informations contextuelles destinées à être reportées audit serveur (150) pour y être stockées dans ladite base de données (160), et dont les réponses reçues du serveur comportent un fichier XML comportant une liste d'URL définissant les images à diffuser ainsi que leur durée d'affichage, ladite réponse comportant également des champs (headers) définissant une ou plusieurs actions à exécuter par ledit dispositif d'affichage (200).
3. 3. Procédé selon la revendication 2 caractérisé en ce que le dispositif d'affichage effectue une comparaison du fichier XML avec le fichier en cours de diffusion de manière à détecter une réponse qui serait transmise depuis un cache et non depuis le serveur (150), ladite détection résultant dans la poursuite du média en cours de diffusion par le cadre numérique.
4. 4. Procédé selon la revendication 2 ou 3 caractérisé en ce que le dispositif d'affichage transmet une requête HTTP GET ou POST accompagné de champs SB_07-FR1- 33 - (headers) définissant une ou plusieurs des informations relevés par un ou plusieurs capteurs parmi les suivants: - un capteur de mouvement, notamment basé sur une détection infra-rouge; - un capteur de luminosité; - des moyens de localisation; - un ou plusieurs capteurs de sécurité; tel qu'un détecteur de fumée; - un capteur de type boussole.
5. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que le serveur 10 (150) transmet une instruction dans un champ (header) accompagnant ladite réponse, venant définir l'une des actions suivantes: - la commande de la fréquence de mise à jour (polling) - l'affichage ou l'extinction de l'écran; - une procédure de vérification de la correspondance entre l'identifiant du 15 dispositif d'affichage et le numéro de la chambre; - une procédure de mesure des procédures de cache mises en oeuvre par le fournisseur d'accès au réseau internet; - une procédure d'affichage d'une note destinée au résidant de la chambre où est localisé le dispositif d'affichage (200); 20 - une procédure de découverte de l'environnement relatif aux réseaux sans fils visibles par le dispositif d'affichage, notamment en mode infrastructure.
6. 6. Procédé selon l'une des revendications précédentes caractérisé en ce que le serveur 150 transmet une réponse conforme au standard MRSS identifiant les URL 25 des photos à diffuser avec leur temps d'affichage, ladite réponse étant accompagnée de champs HTTP (headers) supplémentaires définissant des actions à exécuter par le cadre.
7. 7. Procédé selon l'une quelconque des revendications précédentes caractérisé en 30 ce que les dispositifs d'affichage sont installés dans des structures hôtelières sous le contrôle d'un serveur centralisé (150) dans lequel la base de données comporte une table de correspondance entre les identifiants des dispositifs d'affichage et les numéros de chambres (ROOM NAME) ainsi que des informations relatives aux entrées et sorties (check-in; check-out) des chambres louées. SB07-FR1- 34 -
8. 8. Procédé selon la revendication 7 caractérisé en ce que le dispositif d'affichage (200) transmet des informations au serveur (150) dans le but de permettre une analyse de vraisemblance et de déterminer un éventuel mouvement du dispositif d'affichage.
9. 9. Dispositif de traitement de données comportant une unité centrale, de la mémoire et un dispositif d'affichage, ainsi que des moyens de mise en veille, ledit dispositif étant caractérisé en ce qu'il comporte des moyens de commande dudit dispositif d'affichage de manière à permettre la diffusion de médias sous le contrôle d'un serveur centralisé (150) accédant à une base de données contextuelle (160), ledit procédé étant basé sur la transmission périodique par ledit ordinateur d'une requête comportant un identifiant et accompagné de champs (headers) définissant des informations contextuelles destinées à être reportées audit serveur (150) pour y être stockées dans ladite base de données (160), ledit serveur répondant à ladite requête au moyen d'une réponse définissant le media à diffuser, accompagnée de champs (headers) définissant une ou plusieurs actions à exécuter par ledit ordinateur lors de sa phase de veille.
10. 10. Dispositif de traitement de donnée selon la revendication 9 caractérisé en ce qu'il consiste en une tablette tactile ou un ordinateur comportant un clavier. SB_07-FR1