FR2980664A1 - Prise en compte de la localisation dans la determination de la disponibilite des objets physiques dans l'internet des objets - Google Patents

Abstract

Procédé de déploiement d'une application associée à un utilisateur d'un terminal de communication sur un ensemble d'objets physiques d'un environnement, chaque objet physique offrant au moins un service et l'application possédant au moins un point d'interface, comportant une étape de mise en correspondance du au moins un point d'interface avec au moins un service disponible offert par un objet physique, dans lequel la disponibilité d'un service d'un objet physique est fonction de la localisation de l'objet physique et de la localisation d'un autre utilisateur.

Description

Prise en compte de la localisation dans la détermination de la disponibilité des objets physiques dans l'internet des objets La présente invention est relative au domaine technique de l'internet des objets. On entend par « internet des objets » un ensemble de solutions technologiques permettant d'interconnecter au réseau Internet des objets physiques appartenant à l'environnement d'un utilisateur. Ces objets physiques peuvent être des équipements électroménagers (fours, réfrigérateurs...), des équipements audio-vidéo (téléviseurs, chaînes Hi-Fi...) ou tout autre équipement que l'on peut trouver dans une habitation, dans un bureau (lampes, équipements de chauffage..) ou en extérieur, notamment en zone urbaine (panneaux d'affichages, éclairage public...).

L'utilisateur peut interagir avec ces objets physiques d'une part par leur interface physique habituelle, mais également par le réseau internet en utilisant un terminal de communication. Ce terminal de communication peut être un ordinateur, fixe ou portable, un terminal mobile de type « smartphone », etc.

L'utilisateur peut ainsi accéder à une interface de contrôle, notamment à une interface web, afin de contrôler ces objets physiques. Ces mécanismes sont notamment décrits dans les différents travaux autour du « web des objets ». On peut par exemple citer l'article de D. Guinard et V. Trifa, « Towards the Web of Things: Web Mashup for Embedded Devices », dans Proc. 2nd Workshop on Mashups, Enterprises Mashups and Lightweight Composition on the Web (MEM'09), 2009. Ces travaux visent également à permettre de considérer les objets physiques comme des ressources pouvant être utilisées par des services (ou applications) afin d'élargir les possibilités d'interactions de l'utilisateur avec ces objets physiques et avec les services disponibles sur le web ou sur son terminale de communication. Ce champ de recherche est encore passablement vierge et seules quelques solutions existent. Les solutions aujourd'hui disponibles sont statiques, au sens où la mise en correspondance entre objets physiques et applications est effectuée lors du développement de l'application.

Une telle approche est insuffisante pour au moins deux raisons: Tout d'abord, la disponibilité des objets physiques varie avec le temps. Certains deviennent indisponibles car occupés pour d'autres tâches ou en panne. D'autres apparaissent suite à son introduction dans un espace (achat, déplacement..), à une réparation ou à la terminaison d'une tâche qui l'accaparait jusqu'alors. Ensuite, les utilisateurs sont mobiles. En se déplaçant d'espace en espace, l'application utilisée par l'utilisateur doit pouvoir agir avec d'autres objets physiques présents.

Un des buts de l'invention est de proposer une solution qui soit dynamique, c'est-à-dire dans laquelle la mise en correspondance entre une application et les objets physiques est effectuée dynamiquement en fonction de la disponibilité de ces objets physiques.

Un autre but de l'invention est d'inclure dans la détermination de la disponibilité des objets physiques, la problématique de la gestion des accès concurrents.

Pour ce faire, l'invention a pour premier objet un procédé de déploiement d'une application associée à un utilisateur d'un terminal de communication sur un ensemble d'objets physiques d'un environnement, chaque objet physique offrant au moins un service et l'application possédant au moins un point d'interface. Ce procédé comporte une étape de mise en correspondance de ce (ou de ces) point d'interface avec au moins un service disponible offert par un objet physique. La disponibilité d'un service d'un objet physique est fonction de la localisation de cet objet physique et de la localisation d'un autre utilisateur.

Selon un mode de réalisation de l'invention, les objets physiques sont associés à un au moins un utilisateur principal, et l'autre utilisateur est cet utilisateur principal.

La disponibilité peut dépendre de la proximité de cet utilisateur principal de cet objet physique. La disponibilité peut dépendre d'une visibilité de l'objet physique, fonction de la localisation de cet objet physique et de la localisation d'un autre utilisateur, et d'une accessibilité, fonction d'une catégorie d'utilisateurs à laquelle appartient l'utilisateur et du service. Si l'objet physique n'est pas visible pour l'utilisateur, on peut déterminer que le service n'est pas disponible sans avoir à déterminer l'accessibilité.

L'invention a également pour objet un dispositif de contrôle d'accès pour déploiement d'une application sur un ensemble d'objet physique d'un environnement, comportant une interface pour recevoir des requêtes d'accès à un service offert par un objet physique de l'ensemble, provenant de l'application, associée à un utilisateur d'un terminal de communication, et des moyens de traitement pour traiter la requête d'accès et déterminer la disponibilité du service en fonction de la localisation de l'objet physique et de la localisation d'un autre utilisateur.

Selon un mode de réalisation de l'invention, les moyens de traitement peuvent comprendre un module de gestion de priorité, un module de contrôle d'accès, un module de gestion de l'accessibilité et un module de gestion de la visibilité. L'autre utilisateur peut être un utilisateur principal associé à l'objet 30 physique et les moyens de traitement peuvent être prévus pour déterminer la disponibilité du service en fonction de la proximité de l'utilisateur principal de l'objet physique.

L'invention a également pour objet un dispositif de déploiement d'une application sur un ensemble d'objets physiques d'un environnement, l'application étant associée à des points d'interface. Le dispositif comporte : - des moyens de stockage de représentations, chaque représentation étant associé à un objet physique donné parmi cet ensemble et présentant des associations entre services offerts et états possibles pour l'objet physique donné, - un dispositif de contrôle d'accès tel que précédemment défini, pour déterminer des services disponibles offerts par les objets physiques de cet ensemble, - des moyens de traitement pour effectuer au moins une mise en correspondance entre un point d'interface associé à l'application et au moins un des services disponibles, en fonction des représentations et en fonction de l'état courant des objets physiques. - Des moyens d'activation pour déployer l'au moins une mise en correspondance en connectant l'application et l'objet physique. L'invention a également pour objet une application logicielle mettant en oeuvre le procédé précédemment défini.

Ainsi, par l'utilisation de la localisation de l'objet physique et des autres utilisateurs, le déploiement de l'application dépend de la proximité d'un utilisateur plus prioritaire de l'objet physique en question.

L'invention, ses caractéristiques et ses avantages apparaîtront de façon plus claire dans la description de mises en oeuvre qui va suive en liaison avec les figures annexées. La figure 1 représente un premier exemple de mise en oeuvre de l'invention. La figure 2 représente un deuxième exemple de mise en oeuvre de l'invention et montre les conséquences possibles du déplacement d'un utilisateur. La figure 3 schématise une architecture fonctionnelle possible d'un dispositif de contrôle d'accès selon l'invention. La figure 4 schématise une vue graphique d'une représentation d'un objet physique. Dans l'exemple de la figure 1 sont représentés 4 espaces, Eext, Elb, Elr, Ebr, correspondant à 4 espaces physiques distincts.

L'espace Eext correspond à l'espace extérieur au domicile des utilisateurs U1 et U2. Dans la réalité, cet espace peut être décomposé en une multitude d'espaces différents (rue, bureau, centre commercial, etc.), mais cette décomposition n'apportant rien à la clarté de l'exposé, on ne parlera dans la suite que d'un espace extérieur global Eext. L'espace Elb correspond à un espace intermédiaire entre l'extérieur et le domicile proprement dit. Il peut s'agir du perron d'une maison, du palier d'un immeuble résidentiel etc. Cet environnement peut posséder un objet physique 03. Cet objet physique peut par exemple être une boîte aux lettres.

L'espace Elr correspond au salon ou à la pièce principale de l'habitation. Il comporte deux objets physiques 01 et 02. L'objet 01 est un téléviseur, et l'objet 02 est une lampe. Le téléviseur 01 offre deux services S1a et S1b. La lampe 02 offre un unique service S2. L'espace Ebr correspond à une chambre à coucher. Il comporte un objet 04 20 offrant un service S4. Cet objet physique 04 peut par exemple être un cadre photo numérique. Plusieurs espaces peuvent former un environnement. Ainsi, les espaces Elb, Elr, Ebr forment l'environnement du domicile ED, tandis que l'environnement 25 extérieur est composé dans cet exemple de l'unique espace extérieur Eext. Dans le cadre de l'invention, l'environnement représente une zone géographiquement délimitée. Il peut s'agir d'une zone paramétrable. Elle peut être définie comme une zone au sein duquel l'utilisateur peut physiquement interagir avec l'objet physique ; ce peut être en outre une zone au sein de laquelle un 30 utilisateur adopte certains comportements distincts de ceux adoptés dans une autre zone. Les services S1a, S1b, S2, S3, S4 représentent les fonctions disponibles pour un objet physiques et qui sont rendues disponibles via le « web des objets ». Par exemple, pour la télévision 01, le service Sla peut être une fonction d'affichage de textes sur l'écran. Cet affichage de textes peut se faire en surimpression de l'affichage courant du téléviseur. Un objet complexe comme un téléviseur peut offrir un grand nombre de services, même si deux sont simplement représentés sur la figure. Le service S2 de l'objet lampe 02 peut être un service de changement de 10 couleur. Le service S3 de la boite aux lettres 03 peut être un accès au statut et éventuellement au contenu de la boite. Il est en effet possible d'imaginer pouvoir raccorder une boîte aux lettres 15 physique au web des objets afin, notamment, de pouvoir accéder à distance à son statut. Son statut peut être basique et indiquer s'il existe un courrier dans la boîte ou non. Ce mode de réalisation peut être fait avec un capteur simple (caméra vidéo, senseur de poids, détecteur d'ouverture de la boîte par le facteur, etc.). Son statut peut être rendu plus élaboré par l'apposition d'étiquettes de type RFID sur 20 les courriers et la mise en place d'un lecteur approprié au niveau de la boîte aux lettres. Le service S4 du cadre numérique 04 peut être une fonction d'affichage de texte. Cette fonction peut être identique que la fonction S1 a. Il est donc à noter 25 que plusieurs objets peuvent posséder la même fonction. Un utilisateur U1 est dans l'espace Elr du salon. Il utilise un terminal de communication M1 sur lequel est déployée une application A1. Cette application possède deux points d'interface P1 a, et P1 b. 30 Cette application peut être une application de surveillance et de lecture de messages électroniques. Le point d'interface P1 a correspondant à la fonction de lecture des messages, et le point d'interface Plb correspond à une fonction de notification de l'arrivée d'un nouveau message. Un utilisateur U2 est dans l'espace extérieur Eext. Il utilise un terminal de communication M2 sur lequel est déployée une application A2 possédant deux points d'interface P2a et P2b. Cette application A2 peut être une application de consultation d'une boîte aux lettres. Le point d'interface P2a correspond à une fonction de récupération des informations sur la boîte aux lettres, tandis que le point d'interface P2b est une fonction d'affichage des informations récupérées (statuts et/ou contenu). L'invention comporte une mise en correspondance entre le ou les points d'interface des applications et les services disponibles offerts par les objets physiques d'un environnement.

Des exemples de réalisations techniques d'une telle mise en correspondance seront donnés plus loin. L'application A2 ne peut pas être déployée car ses points d'interface ne 20 peuvent pas tous être mis en correspondance avec des services offerts par des objets : l'environnement dans lequel se situe l'utilisateur U2 ne contient aucun objet physique permettant l'affichage de message. Le point d'interface P2b ne peut donc pas être satisfait et l'application ne peut pas être déployée. L'application Al est déployée dans l'environnement du domicile et plus 25 précisément dans l'espace Elr du salon de ce domicile. Le point d'interface Pla est mis en correspondance avec le service S1 a et le point d'interface P1 b est mis en correspondance avec le service S2. Ainsi, à l'arrivée d'un nouveau message, l'application Al peut faire changer la couleur de la lampe 02 pour notifier l'utilisateur U1 et afficher le message sur la télévision 01. 30 On suppose dans cet exemple que l'utilisateur U2 se dirige vers son domicile. La figure 2 illustre la nouvelle situation provoquée par son entrée dans l'environnement du domicile dans le déploiement des applications Al et A2.

Selon l'invention, en effet, la disponibilité d'un service d'un objet physique est fonction de la localisation de cet objet physique et de la localisation d'un autre utilisateur. L'entrée de l'utilisateur U2 dans le même environnement que l'utilisateur U1 a donc des conséquences sur la détermination de la disponibilité des services. Différentes mises en oeuvre sont possibles pour déterminer la disponibilité d'un service à partir de la localisation des deux utilisateurs U1 et U2.

Selon un mode de réalisation de l'invention, la disponibilité peut par exemple être déterminée comme la combinaison entre l'accessibilité du service et la visibilité de l'objet auquel le service appartient.

L'accessibilité est déterminée par un mécanisme de droits d'accès au service. Ces droits d'accès peuvent être déterminés en fonction de catégories auxquelles les différents utilisateurs sont affectés.

Dans le cadre du domicile de l'exemple, il est possible d'avoir une première catégorie pour les deux parents, puis une catégorie, de droits inférieurs, pour les enfants. On peut également définir une catégorie, avec des droits d'accès encore inférieure, pour un cercle d'amis et éventuellement une quatrième catégorie pour les simples visiteurs, avec des droits d'accès minimaux Ces catégories et l'affectation de chaque utilisateur connu à une catégorie peuvent être configurées manuellement par l'utilisateur principal (par exemple celui qui installe l'objet physique) ou un administrateur (société de service, installateur d'un équipement ou du système de gestion des droits d'accès etc.) Ces catégories peuvent être définies pour un objet physique ou bien, plus finement, pour chaque service offert par un objet physique. Le tableau suivant illustre un exemple d'affectation de droits d'accès à chaque service d'un objet « téléviseur », 01, pour chaque catégorie d'utilisateurs. «0» indique qu'un utilisateur de la catégorie indiquée en colonne a accès au service indiqué sur la ligne correspondante. « N » indique qu'il n'y a pas accès. Utilisateur Cercle Amis Visiteurs principal familial Affichage d'un message (S1) 0 0 0 0 Traitement vidéo 0 0 0 0 Affichage d'une image 0 0 N N Affichage d'une vidéo 0 0 0 N Changement de chaîne 0 0 N N Contrôle du volume sonore 0 N N N Contrôle parental 0 N N N Bien évidemment, d'autres mises en oeuvre sont possibles. Il est notamment possible de définir d'autres catégories d'utilisateurs (notamment pour des environnements qui ne sont pas des environnements de domicile), ou bien de définir des droits d'accès plus fin que la dichotomie accès/non-accès (0/N).

Il est également possible de ne définir qu'une accessibilité globale pour tous les services d'un même objet physique. Cette possibilité peut être intéressante pour des objets physiques simples, notamment possédant peu de services, mais appauvrit les possibilités offertes par l'invention si mise en oeuvre pour des objets physiques complexes. La visibilité d'un service peut, quant à elle, dépendre de la localisation de l'objet physique et d'un utilisateur. Pour ce faire, le dispositif de contrôle d'accès dispose de moyens pour connaître la localisation des différents utilisateurs. Il peut pour se faire interroger des serveurs connectés via un réseau de communication, notamment un serveur de présence. Également, les terminaux de communication M1, M2 peuvent transmettre leur localisation dans la requête qu'ils transmettent pour se déployer La localisation peut être fournie par l'objet physique lui-même (lors de sa déclaration auprès du système, par exemple), ou par un administrateur qui configure ce paramètre, par exemple lors de l'installation de l'objet physique.

On suppose dans l'exemple des figures 1 et 2 que l'utilisateur U2 jouit d'un rôle particulier pour l'objet 01. Il peut être un utilisateur principal de cet objet 01. Un utilisateur principal peut être défini en quelque sorte comme le propriétaire de l'objet. Certains objets peuvent être mis en commun par les deux parents par exemple : cela peut être le cas du téléviseur 01. D'autres peuvent avoir un utilisateur principal unique (montre, réveil matin, etc.). On suppose également que l'utilisateur U2 ne possède pas de rôle particulier pour la lampe 02.

Selon un mode de réalisation de l'invention, la disponibilité d'un service d'un objet physique dépend de la localisation du (ou des) utilisateurs principaux de cet objet physique. Plus celui-ci est proche de l'objet physique, moins l'objet peut être rendu - visible » aux autres utilisateurs. À la limite, si l'utilisateur principal est à coté de l'objet physique, celui-ci lui appartient complètement et personne d'autres ne peut en utiliser les services. Si, au contraire, il est très éloigné de l'objet physique, ses services peuvent devenir accessibles à tous. Ce mode de réalisation de l'invention présente de nombreux avantages pour l'utilisateur principal d'un objet physique : - on peut laisser ouvert les services de ses propres objets sans craindre de ne pas pouvoir les utiliser pour soi quand on en a besoin, ni d'être dérangé par l'intrusion d'un autre utilisateur (incrustation de textes alors qu'on regarde la télé, même si cet autre utilisateur a effectivement le droit d'accès au service « affichage d'un message ») - Pas de besoin de - revendiquer » par une action son propre objet physique : il devient disponible par sa seule présence à proximité. En corolaire, la communauté en bénéficie aussi puisque, l'utilisateur ayant moins à craindre de conférer des droits d'accès importants aux autres utilisateurs, ceux-ci disposent d'un plus grand nombre de services offerts par les objets physiques d'un environnement. On peut raisonnablement penser que ce mécanisme peut permettre le développement du « web des objets » en diminuant la réticence naturelle des utilisateurs à maintenir fermé l'utilisation de leurs objets par autrui. Le tableau suivant illustre un exemple de détermination de la visibilité d'un objet en fonction des catégories d'utilisateurs et de la proximité de l'utilisateur principal.

A coté proche Éloigné Utilisateur principal 0 0 0 Cercle familial N 0 0 Amis N 0 0 Visiteurs N N 0 Les colonnes « à coté », « proche », « éloigné » exprime la proximité de l'utilisateur principal U2 de l'objet physique considéré. Cette proximité découle directement de la localisation de l'utilisateur U2 et de celle de l'objet physique.

Cet exemple montre des valeurs discrètes de la proximité et de la visibilité ayant pour valeur binaire, 0 ou N, respectivement « visible » ou « non visible »). Il est possible de mettre en oeuvre une fonction continue fournissant une valeur de visibilité par rapport à une valeur également continue de proximité (par exemple exprimée en mètres). Selon un mode de réalisation de l'invention, la disponibilité d'un service offert par un objet dépend de la visibilité de l'objet et de l'accessibilité du service. Ces deux mécanismes, visibilité et accessibilité, peuvent fonctionner en cascade : si l'objet n'est pas visible pour un utilisateur, aucun service n'est disponible, mais s'il est visible, alors la disponibilité d'un service dépend de son accessibilité. Autrement dit, si l'objet physique n'est pas visible pour l'utilisateur, on détermine que le service n'est pas disponible sans avoir à calculer l'accessibilité. La figure 3 schématise une architecture fonctionnelle permettant de mettre en oeuvre un tel mécanisme.

Les moyens de traitement du dispositif de contrôle d'accès sont composés de plusieurs modules fonctionnels. Ces modules fonctionnels peuvent être des modules logiciels d'une même application logicielle, ou bien appartenir à des applications distinctes, et possédant des interfaces prédéfinies ou standardisés.

Ils peuvent être déployés sur des plateformes matériel distinctes et communiquer via le réseau de télécommunication. Ils peuvent être déployés sur le terminal de communication de l'utilisateur, sur un objet physique, ou sur un serveur. Dans l'exemple de la figure 3, le dispositif de contrôle d'accès DCA 15 comporte : un module de gestion de priorité, PU (Priority Unit) un module de contrôle d'accès, ACU (Access Control Unit), un module de gestion de l'accessibilité, AU (Accessability Unit), un module de gestion de la visibilité, VU (Visibility Unit), 20 Le module de contrôle d'accès ACU est le module principal du dispositif. C'est lui qui orchestre les autres modules et qui reçoit les requêtes d'accès M1 reçues d'une application A à travers une interface INT. Cette application est associée à un utilisateur d'un terminal de communication T. 25 La requête contient au moins un identifiant du service auquel l'application souhaite accéder. Cet identifiant peut contenir un couple formé d'un identifiant d'objet physique et d'un identifiant du service parmi ceux de cet objet physique. Le module de contrôle d'accès ACU transmet la requête d'accès M2 au 30 module de gestion de la visibilité VU. Celui-ci a accès à des informations D1 relatives à un autre utilisateur de l'objet physique en question, et à des informations D2 relatives au service demandé. Comme dit précédemment, cet autre utilisateur peut être un utilisateur principal de l'objet physique.

Parmi ces informations D1, D2 figurent la localisation respectivement de l'autre utilisateur et de l'objet physique. Le module de gestion de la visibilité VU peut alors calculer une proximité entre l'autre utilisateur et l'objet physique à partir de ces deux valeurs de localisation, puis déterminer la visibilité de l'objet. Selon un mode de réalisation de l'invention, la requête M2 retransmis du module de contrôle d'accès ACU au module de gestion de la visibilité VU contient un identifiant de l'utilisateur U ou, tout du moins, un indicateur de la catégorie à laquelle il appartient. Le module de visibilité peut alors déterminer une valeur binaire de visibilité oui/non. Cette valeur est retournée dans un message de réponse M3 destiné au module de contrôle d'accès ACU. Si l'objet physique n'est pas visible, le module de contrôle d'accès ACU peut directement en déduire que l'application A ne peut pas accéder au service demandé et il peut retourner un message de réponse M8 indiquant que l'accès est refusé. Si l'objet physique est visible, le module de contrôle d'accès ACU peut retransmettre la requête dans un message M4 adressé au module de gestion de l'accessibilité AU. Celui-ci détermine l'accessibilité de la fonction demandée ainsi que décrit précédemment. Ce peut donc être directement à partir de la catégorie à laquelle appartient l'utilisateur U. Il peut renvoyer au module de contrôle d'accès ACU un message de réponse M5 contenant une réponse qui peut être binaire oui/non. Si la réponse est négative (le service n'est pas accessible), le module de 25 contrôle d'accès ACU peut directement transmettre un message M8 de refus d'accès à l'application A. Si la réponse est positive, le module de contrôle d'accès ACU peut interroger le module de gestion de priorité PU, en lui transmettant la requête dans un message M6. Ce module peut gérer les conflits générés par des accès concurrents à 30 une même fonction. Il peut gérer les priorités sur la base des catégories auxquelles appartiennent les utilisateurs concurrents, de priorités établis de façon additionnelle par l'utilisateur principal ou par un administrateur du système ou de l'objet physique, de priorités accordés à des applications, etc.

Trois situations sont alors possibles. Il n'y a pas d'accès concurrent sur ce service : le module de gestion de priorité PU peut apporter une réponse M7 autorisant l'application A à accéder au 5 service demandé. Il y a un accès concurrent et cet utilisateur est prioritaire sur celui U dont émane la requête : le module de gestion de priorité PU peut apporter une réponse M7 interdisant l'application A d'accéder au service demandé. Il y a accès concurrent et l'utilisateur U est prioritaire sur celui à l'origine de 10 l'accès concurrent : le module de gestion de priorité PU peut alors mettre en place un système de préemption. Il peut apporter une réponse M7 autorisant l'application A à accéder au service demandé, et envoyer une notification à l'application concurrente pour lui demander d'interrompre son utilisation du service. 15 D'autres mécanismes peuvent également être déployés comme une mise en file d'attente, etc. Cette figure 3 n'illustre qu'une possibilité d'architecture fonctionnelle des moyens de traitement du dispositif de contrôle d'accès. D'autres mises en oeuvre 20 sont bien évidemment possibles. En revenant à la figure 2, lorsque l'utilisateur U2 entre dans l'espace Elb, le dispositif de contrôle d'accès calcule la nouvelle proximité entre cet utilisateur U2 et les objets physiques 01, 02 présents dans l'espace. Cette proximité peut 25 prendre la valeur « à coté » selon le tableau précédent. L'application A2 nécessite les deux services S3 et S1a. Pour l'utilisateur U2, ces services sont - visibles : il est l'utilisateur principal pour 01 et on suppose que 30 l'utilisateur principal de l'objet 03, s'il existe, n'est pas à proximité, et - accessibles : on suppose qu'il appartient à une catégorie pour laquelle les services demandés des objets physiques 01 et 03 sont accessibles. - Il appartient à une catégorie « supérieure » par rapport à l'utilisateur U1 (qui appartient, par exemple, à la catégorie « Cercle familial »), et est donc prioritaire pour l'utilisation de l'objet 01. Il n'y a pas d'accès concurrents à l'objet 03 Par conséquent, les deux services S1 a et S3 lui sont disponibles et l'application A2 peut donc se déployer en mettant en correspondance les points d'interface P2a et P2b avec les services S3 et S1 a, respectivement. La situation change également pour l'utilisateur U1 : le service Sla devient non-visible du fait de la proximité de l'utilisateur principal. Il n'est donc plus disponible pour l'application Al qui doit donc se déconnecter. Le système peut permettre à l'application Al de dynamiquement retrouver un objet physique permettant de satisfaire les requis du point d'interface Pl a. Cette mise en correspondance dynamique d'un point d'interface avec un service sera expliquée plus loin.

L'objet 04 offre un service S4 similaire car permettant l'affichage d'un message textuel sur un écran. L'application Al se déploie donc automatiquement sur ce service S4. L'utilisateur U2 n'étant pas utilisateur principal de l'objet 02, le service S2 reste disponible et donc le point d'accès Plb reste en correspondance avec ce service S2. L'utilisateur U1 est alors incité à se déplacer dans l'espace Ebr afin de visualiser le contenu des messages arrivants, mais il peut rester dans l'espace Elr où il sera notifié de l'arrivée d'un message via la lampe 02.

Dans cet exemple de mise en oeuvre, le redéploiement de l'application A 1 à la suite du changement de situation se fait donc a minima. Une autre mise en oeuvre aurait pu être de choisir de reployer dynamiquement l'application dans l'espace le plus proche où l'ensemble des points d'interface peuvent être mises en correspondance.

Il est à noter que le déploiement se fait pour un environnement qui peut contenir plusieurs espaces. Ainsi, l'utilisateur U2 utilise l'objet 03 qui est en dehors de son espace Elb, mais dans le même environnement. De même, l'utilisateur U1 utilise l'objet 02 qui est en dehors de son espace Ebr, mais dans le même environnement du domicile ED. Il est à noter par ailleurs que d'autres mises en oeuvre et d'autres façons de déterminer la disponibilité d'un service sont possibles. Par exemple, la disponibilité d'un service peut se baser uniquement sur son accessibilité telle que définie précédemment et la localisation des utilisateurs peut n'intervenir que pour lever des conflits entre utilisateurs d'une même catégorie : celui le plus proche de l'objet physique possède les droits d'accès au détriment du plus éloigné. En ce cas, le système détermine la disponibilité en fonction de la localisation des deux utilisateurs en concurrence. Il est également possible de déterminer la disponibilité en combinant accessibilité et visibilité en cascade comme préalablement décrit mais suivant un ordre inverse : on calcule d'abord l'accessibilité du service et si le service est accessible, alors on détermine sa visibilité. Selon l'invention, le déploiement d'une application dans un espace donné peut se faire par une étape de mise en correspondance des points d'interface de cette application avec les services disponibles et offerts par un objet physique 20 appartenant à l'environnement. Les points d'interface permettent à une application d'interagir avec l'environnement (logiciel et télécom) dans lequel elle se trouve. Typiquement, ces points d'interface appartiennent à un groupe comportant des points d'entrée, des 25 points de sorties et des points d'événements. Ils peuvent être obligatoires ou optionnels. Un point d'entrée obligatoire indique que des données sont nécessaires pour permettre à l'application de fonctionner. Un point de sortie obligatoire indique que l'application fournit obligatoirement des données. Par exemple, une application de type réseau social (Facebook, Myspace, 30 Mixi...) peut avoir une sortie photo, une sortie vidéo, une sortie RSS, etc. Les associations entre une application et ses points d'interface peuvent être mémorisées sous la forme de représentations abstraites. L'exemple ci-dessous illustre une représentation possible pour une application de téléphonie pour personnes malentendantes. Dans cet exemple, la représentation est fournie en langage XML (eXtensible Markup Language) mais d'autres formats de représentation sont bien évidemment possibles. <needs> <resource class="input" occur="mandatory"> <event class="ringing"/> </resource> <sequence> <resource class="output" occur="optional" kind="light"> <service class="scintillate"/> </resource> <resource class="output" occur="optional" kind="text"> <service class="display"/> </resource> </sequence> </needs> On peut également donner un exemple de représentation d'une application comme « Facebook » : <needs> <sequence> <resource class="output" occur="optional" kind="display"> <service class="video_streann"/> </resource> <resource class="output" occur="optional" kind="display"> <service class="slideshow"/> </resource> <resource class="output" occur="optional" kind="sound"> <service class="text_to_speech"/> </resource> </sequence> </needs> Pour des applications existante que l'on souhaite pouvoir ainsi interfacer, il peut être nécessaire de prévoir une couche d'adaptation prévue pour utiliser les API (Application Programming Interface) de cette application existante (par exemple, l'API « Facebook graph API » permet de récupérer et d'ajouter des photos, des vidéos, des messages...) ou bien, s'il n'existe pas d'API, pour traiter la représentation HTML de l'application afin d'en extraire les informations de sortie (texte, image, flux RSS...). Il est possible que la représentation sémantique soit insérée dans du code HTML. Il est alors intéressant d'utiliser une autre mise en oeuvre de l'invention basée sur un microformat. Un microformat est une approche de formatage de données basé sur le web, qui cherche à réutiliser le contenu existant comme les métadonnées, en n'utilisant que des classes et attributs XHTML et HTML. Un exemple utilisant un tel microformat peut être : <div class="needs"> <div class="resource"> <span class="occur>mandatory</span> input <span class="event">ringing</span> </div> <div class="sequence"> <div class="resource"> <span class="occur>optional</span> output <span class="kind">light</span> <span class="service">scintillate</span> </div> <div class="resource"> <span class="occur>optional</span> output <span class="kind">text</span> <span class="service">display</span> </div> </div> </div> Ces représentations qui comprennent au moins les associations avec les points d'interface peuvent être mémorisées dans un serveur d'applications. Celui-ci peut être de différentes natures : il peut s'agir d'un serveur administré par une société de service. Il peut également s'agir d'un centre de ressources de type market place » ou « applications store », qui assurent l'intermédiaire entre des 10 applications existantes afin de les rendre compatibles avec le web des objets. Ce centre de ressources peut ne pas héberger les applications elles-mêmes mais fournir, entre autres, les représentations abstraites associées. Les objets physiques peuvent également être associés à des 15 représentations. Ces représentations présentent au moins des associations entre services offerts et états possibles de l'objet considéré. La figure 4 montre une vue graphique d'une telle représentation. Cette vue graphique peut être de type « réseau de Pétri » par exemple. Elle montre que l'objet physique possède deux états E1, E2. Pour chacun de ces états, différents 20 services sont offerts : f1, f2 dans l'état E1, et f1, f3, f4 dans l'état E2. Un même service peut être disponible dans plusieurs états. Cet exemple à deux états peut être une lampe éteinte/allumée, un téléphone raccroché/décroché, une télévision allumée/éteinte, etc. Les représentations peuvent être fournies selon un langage de métadonnées 25 comme RDFa ou microformat. RDFa est une syntaxe qui permet de décrire des données structurées dans une page web. RDFa est un standard en cours d'élaboration au W3C (WWW Consortium), où il a atteint le statut de recommandation le 14 octobre 2009. Cette syntaxe est conforme au modèle RDF (pour « ressource Description Framework ») 30 et permet de mettre en oeuvre le web sémantique. Un exemple concret pour une lampe peut être comme suit : <html xnnlns="http://www.w3.org/1999/xhtnnl" xnnlns:foaf="http://xnnlns.conn/foaf/0.1/" xnnlns:dc="http://purl.org/dc/elennents/1.1r xnnlns:wot-ownership="http://wot. org/ownership#" xnnlns:wot-core="http: / /wot.org/core#" xnnlns:wot-lifecycle="http://wot. org/lifecycleer xnnlns:wot-webhook="http: / /wot.org/webhook#" xnnlns:webhook="http://webhooks.org/specr xnnlns:lannp="http: / /wotorg/lannps/vocaber> <body> <div id="444" typeof="lamp:TableLamp" about="http://sonnewhere.conn/lannps/444"> <h3><a property="wot-core:nanne" rel="wot-core:self" href="http://sonnewhere.conn/lannps/444">Bob's desk lannp</a></h3> <div rel="wot-ownership:owner">Owned by <a typeof="foaf:Person" property="foaf:nanne" href="http://sonnewhere.conn/users/222">Bob</a></div> <script type="text/javascript;version=1.8" src="restapi.js" rev="wotcore:api" resource="http://sonnewhere.conn/lannps/444"></script> <div rel="wot-lifecycle:statechart" resource="http://sonnewhere.conn/lannps/444/scxnnl"> <p>The lamp's state is: <img src="switch_on.png" rev="wot-core:image" resource="[_:switchon]" onclick="lamps.switchOff(444)" style="cursor:pointer"/> <p about="http://sonnewhere.conn/lannps/444" rel="wot-lifecycle:state"> <span typeof="wot-lifecycle:State" property="wot-lifecycle:value" resource="Uswitchony> lannp.switch.on </span> </p> </div> <div rel="wot-core: hasOperation"> To <b><i><span typeof="wot-core:Functionality" property="wotcore:hasName" resource="[_:blink]">blink</span></i></b> the lamp, you can click on this button<br/> <img src="blink.png" rev="wot-core:api" resource="[_:blink]" onclick="larnp.blink(444)" style="cursor:pointer"/> </div> </div> </body></htrnl> Ces représentations peuvent être fournies par les objets physiques eux- mêmes. Certains objets peuvent en effet être commercialisés avec les moyens logiciels permettant de rendre disponibles une représentation de leurs capacités à des dispositifs extérieurs. Elles peuvent également être fournies par un tiers ou par un administrateur. Des dispositifs d'adaptation peuvent être en charge d'interfacer les objets physiques avec le réseau de communication, et donc avec le web des objets. Ces dispositifs d'adaptation peuvent notamment rendre disponibles les représentations associées à chaque objet physique. Ils peuvent être embarqués dans les objets physiques eux-mêmes ou bien déportés dans le réseau de communication.

Les représentations peuvent être mémorisées dans des moyens de stockage. Ces moyens de stockage peuvent être co-localisés avec un dispositif d'adaptation, et notamment embarqués dans les objets physiques. Il est également possible de disposer d'une base accessible à un ou plusieurs dispositifs d'adaptation.

Un dispositif de contrôle peut en outre être prévu pour rechercher tout ou partie des objets physiques dans un environnement donné. Il peut pour se faire interroger la base évoquée ci-dessus. Il peut ensuite interroger le dispositif de contrôle d'accès décrit plus haut, afin de connaître la disponibilité des services offerts par les objets physiques 30 trouvés. Des moyens de traitement peuvent ensuite chercher à mettre en correspondance les points d'interface de l'application avec les services offerts par les objets physiques trouvés par le dispositif de contrôle et indiqués comme disponibles par le dispositif de contrôle d'accès. Cette mise en correspondance se fait en fonction des représentations des objets physiques mais aussi en fonction de l'état courant des objets physiques (une 5 lampe ne présente pas les mêmes services si elle est éteinte ou allumée) Cette mise en correspondance peut être effectuée manuellement, via une interface homme-machine permettant à l'utilisateur de choisir les objets physiques qu'il souhaite utiliser. 10 La mise en correspondance peut également être automatique. Selon un mode de réalisation, cette mise en correspondance peut se faire en appariant des services offerts et disponibles et des points d'interface dont les descriptions présentent une forte corrélation sémantique. 15 Pour ce faire, des valeurs sémantiques peuvent être attachées aux services et aux points d'interfaces, au moyen de leurs représentations. Par exemple, les représentations des objets physiques peuvent contenir un mot-clé associé à chaque service offert. Ce mot-clé peut être l'identifiant du service lui-même ou bien être complémentaire à cet identifiant. Dans le cas d'une 20 lampe, ce mot-clé peut être « blink » pour un service de clignotement de la lampe ou « color » pour un service de changement de couleur. Ce mot-clé peut être inséré dans une ligne « resource= ». Des mots clés peuvent également être associés aux points d'interface des applications requis. Dans l'exemple précédemment décrit, un mot clé est inséré 25 dans un attribut « kind ». Il prend ici deux valeurs « light » et « text ». Ce mot-clé peut être l'identifiant du point d'interface lui-même ou bien être complémentaire à cet identifiant. Une mise en oeuvre peut consister à mettre en correspondance des services 30 offerts et disponibles avec des points d'interface ayant le même mot-clé. D'autres mécanismes sont toutefois possibles pour rechercher l'optimisation de la corrélation sémantique entre services et points d'interface. Il est en outre important de prendre en compte différents facteurs : - une valeur sémantique peut être plus générale que l'autre. Par exemple, un service peut être « afficher image » alors que l'application a un point de sortie « afficher photo ». Il peut être intéressant que les moyens de traitement puissent déterminer qu'une image est une généralisation du concept « photo » et que la mise en correspondance est possible même si les mots-clés sont différents. - Des mots-clés peuvent être synonymes. Par exemple, - photo » et photographie », « vidéo » et « film ». Cette situation peut notamment survenir si l'on utilise des équipements ou des applications provenant de différents fabricants, chacun utilisant un vocabulaire propre. Il peut alors être utile de pouvoir s'affranchir d'une mise en correspondance purement syntaxique et basée sur l'égalité entre mots clés. Un besoin peut donc exister d'effectuer une corrélation plus fine. Pour cela, les moyens de traitement peuvent utiliser une ontologie. Cette ontologie peut être disponible sur le web, ou bien être plus locale et livrée avec les moyens de traitement SM. Dans ce dernier cas, il peut être prévu des mises à jour afin d'intégrer des évolutions, des nouveaux fabricants, des nouveaux services, des nouveaux équipements...

Cette ontologie peut être décrite de différentes façons, selon différentes modélisations, notamment RDF schema, qui sont issues des travaux du W3C. Par l'utilisation d'une ontologie, il devient possible d'effectuer des corrélations entre des concepts synonymes (« video », « film »...) ou proche (« image », « photo »...).

Par exemple, le point d'interface - scintillate » que l'on trouve dans les exemples donnés plus haut peut être mis en correspondance avec le service - blink » de l'exemple de lampe. Il peut arriver qu'un même point d'interface puisse être mis en 30 correspondance avec plusieurs services d'un même objet physique ou de plusieurs objets physiques. Dans ce cas, plusieurs options peuvent être prises par les moyens de traitement : - l'ensemble des choix possibles peuvent être proposés à l'utilisateur via l'interface homme-machine d'un terminal de communication ou d'un objet physique qu'il est déjà en train d'utiliser. - il peut être prévu d'utiliser un profil de l'utilisateur. Ce profil peut comporter des préférences, notamment au sujet de ses équipements préférés. Il peut être ainsi possible d'indiquer que l'utilisateur préfère voir ses vidéos sur la télévision. A défaut (télévision éteinte), il préfère les voir sur l'écran d'ordinateur. Ce profil peut être entièrement paramétré par l'utilisateur, mais il peut également être prévu d'utiliser l'historique des choix et actions de l'utilisateur pour le définir au moins en partie. Il peut être proposé en outre de mettre en correspondance un point d'interface avec un service d'un objet non disponible dans l'état actuel de cet objet physique. Cette proposition peut permettre d'enrichir les choix possibles pour l'utilisateur, ou bien de proposer au moins un choix lorsqu'aucun ne serait autrement possible.

Par exemple, si aucun écran n'est allumé alors que survient un appel de vidéophonie, il peut être proposé d'en allumer un. Également, pour visualiser une vidéo de l'application « Facebook », si uniquement l'écran du cadre numérique est allumé, il peut être proposé d'allumer un écran de dimension plus importante comme la télévision Là encore, l'ensemble des choix possibles peut être proposé ou bien un échantillon plus limité. La limitation des choix peut être effectuée en fonction d'un profil de l'utilisateur. Elle peut également être effectuée en fonction d'une notion de coût.

Ce coût peut prendre en compte : - le nombre d'actions nécessaires pour mettre l'objet physique concerné dans un état où l'opération est disponible ; - la durée de ces actions (par exemple, allumer un ordinateur pour afficher la vidéo d'un appel de vidéophonie entrant peut ne pas être adapté compte tenu du temps de « boot » nécessaire que cela implique) - la consommation d'énergie impliquée par chaque action, etc.

Le tableau ci-dessous illustre différentes situations pouvant survenir pour une application de téléphonie pour personnes malentendantes telle que précédemment décrite. La colonne de droite indique 3 situations et la colonne de gauche des mises en correspondance pour ces situations. Seuls les 3 points de sortie « Ringing », Blink » et « Display » précédemment évoqués sont pris en compte, et il n'est indiqué que l'objet physique de la mise en correspondance et non le service offert, celui-ci en découlant de façon évidente. Cas normal Ringing -> téléphone Blink -> lampe Display -> TV TV éteinte Ringing -> téléphone Blink -> lampe Display -> cadre numérique TV éteinte, téléphone Ringing -> réveil Blink -> lampe décroché Display -> cadre numérique Les moyens de traitement peuvent contrôler que l'ensemble des points d'interface obligatoires sont effectivement mis en correspondance avec un service d'un objet physique. Dans le cas contraire, ils peuvent notifier à l'utilisateur que celui-ci doit compléter sa configuration dans le cas d'une mise en correspondance manuelle ou que l'application ne peut pas être déployée dans l'environnement actuel. Enfin, le dispositif selon l'invention comporte des moyens d'activation pour déployer la ou les mises en correspondance ainsi effectuées en connectant l'application et l'objet physique concernés. Pour cela, les moyens d'activation peuvent communiquer avec les objets physiques directement ou par l'intermédiaire des dispositifs d'adaptation en utilisant les protocoles, langages et mécanismes disponibles.

Notamment peuvent être utilisés les mécanismes DPWS (pour « Device Profile for Web Services »), REST (pour « Representational State Transfer »), WDSL 2.0, etc. Ce mécanisme DPWS est notamment décrit sur les liens h "schemas.x s a /20 6/02/dev r et http: /downLoad. microsoft.com /download/b/ 5 / 3/b53ea430-db -440c-a308- df97b10280b7/introducing dpws.pdf En utilisant ces technologies, les moyens d'activation peuvent établir la communication entre les points d'interface des applications et les services des objets physiques. Pour ce faire, l'application peut utiliser l'API fournie par le dispositif d'adaptation décrite en RDFa dans la représentation HTML qu'il fournit lui-même. En outre, les moyens d'activation peuvent contrôler en temps-réel la disponibilité des objets physiques et l'état des connexions entre applications et objets physiques. En cas de rupture de la connexion, ils peuvent ainsi envoyer un message aux moyens de traitement pour que ceux-ci déclenchent une nouvelle mise en correspondance avec un autre objet physique disponible. C'est ainsi le cas du passage de la situation de la figure 1 à la situation de la figure 2. Le service Sla devient indisponible et la connexion entre l'application Al et ce service est rompue. Les moyens de traitement peuvent alors dynamiquement rechercher un nouveau service pouvant être mis en correspondance avec le point d'interface P1 a devenu « non satisfait ». Le service S4 de l'objet physique 04 est trouvé et l'application Al peut être redéployée en temps-réel sur ce service. Les moyens d'activation peuvent maintenir la relation avec les objets physiques par l'intermédiaire des dispositifs d'adaptation. Ceux-ci peuvent disposer par exemple d'un mécanisme de souscription auquel les moyens d'activation peuvent s'abonner pour être informés automatiquement des événements des objets physiques. Alternativement, les moyens d'activation peuvent régulièrement envoyer des requêtes pour s'assurer que les objets physiques sont toujours disponibles.5

Claims (4)

1. REVENDICATIONS1) Dispositif de contrôle d'accès pour déploiement d'une application sur un ensemble d'objet physique d'un environnement, comportant une interface pour recevoir des requêtes d'accès à un service offert par un objet physique dudit ensemble, provenant de ladite application, associée à un utilisateur d'un terminal 10 de communication, et des moyens de traitement pour traiter ladite requête d'accès et déterminer la disponibilité dudit service en fonction de la localisation dudit objet physique et de la localisation d'un autre utilisateur.
2. 2) Dispositif de contrôle d'accès selon la revendication précédente, dans 15 lequel lesdits moyens de traitement comprennent un module de gestion de priorité (PU), un module de contrôle d'accès (ACU), un module de gestion de l'accessibilité (AU) et un module de gestion de la visibilité (VU).
3. 3) Dispositif de contrôle d'accès selon l'une des revendications précédentes, 20 dans lequel ledit autre utilisateur est un utilisateur principal associé audit objet physique et dans lequel lesdits moyens de traitement sont prévus pour déterminer ta disponibilité dudit service en fonction de la proximité dudit utilisateur principal dudit objet physique. 25
4. 4) Dispositif de déploiement d'une application sur un ensemble d'objets physiques d'un environnement comportant un dispositif de contrôle d'accès selon l'une des revendications précédentes, ladite application étant associée à des points d'interface, comportant en outre : des moyens de stockage de représentations, chaque représentation 30 étant associé à un objet physique donné parmi ledit ensemble et présentant des associations entre services offerts et états possibles pour ledit objet physique donné, ledit dispositif de contrôle d'accès, déterminant des services disponiblesofferts par tes objets physiques dudit ensemble, des moyens de traitement pour effectuer au moins une mise en correspondance entre un point d'interface associé à ladite application et au moins un desdits services disponible, en fonction desdites représentations et en fonction de l'état courant desdits objets physiques. Des moyens d'activation pour déployer t'au moins une mise en correspondance en connectant ladite application et ledit objet physique. 10