FR3076022A1 - Virtualisation d'un objet connecte - Google Patents

Virtualisation d'un objet connecte Download PDF

Info

Publication number
FR3076022A1
FR3076022A1 FR1763260A FR1763260A FR3076022A1 FR 3076022 A1 FR3076022 A1 FR 3076022A1 FR 1763260 A FR1763260 A FR 1763260A FR 1763260 A FR1763260 A FR 1763260A FR 3076022 A1 FR3076022 A1 FR 3076022A1
Authority
FR
France
Prior art keywords
characteristic
avatar
connected object
enrichment
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR1763260A
Other languages
English (en)
Inventor
Stephane Petit
Fabrice Marc
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1763260A priority Critical patent/FR3076022A1/fr
Priority to PCT/FR2018/053224 priority patent/WO2019129946A1/fr
Priority to US16/958,291 priority patent/US20210058265A1/en
Priority to EP18833096.3A priority patent/EP3732859A1/fr
Publication of FR3076022A1 publication Critical patent/FR3076022A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/281—Exchanging configuration information on appliance services in a home automation network indicating a format for calling an appliance service function in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/59—Network arrangements, protocols or services for addressing or naming using proxies for addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/131—Protocols for games, networked simulations or virtual reality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/285—Generic home appliances, e.g. refrigerators

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé de virtualisation d'un objet connecté (O3) d'un réseau de communications (1,3). L'objet connecté possède au moins une caractéristique de base (CB1_O3...CBN_O3). Le procédé comporte les étapes suivantes : - obtention (E20) d'au moins un identifiant (ID) et d'au moins une caractéristique de base (CB1_O3...CBN_O3) de l'objet connecté à virtualiser ; - obtention (E22) d'au moins une caractéristique d'enrichissement (CE1_O3...CEN_O3)); - création (E21, E23) d'un avatar (AV_O3) comportant : - une première structure de données (SDB_O3) comportant la caractéristique de base (CB1_03,...CBN_O3) de l'objet connecté ; - une seconde structure de données (SDE_O3) comportant la caractéristique d'enrichissement (CE1_O3,...CEN_O3) ; - des instructions de programmes (PE1_O3... PEN_O3) de mise en oeuvre de la caractéristique d'enrichissement (CE1_O3,...CEN_O3) ; - une structure de gestion d'adresses, dite proxy (PY 03) comportant une correspondance au moins entre une adresse de l'avatar (@AV_OV3) et une adresse de l'objet connecté (@O3).

Description

Virtualisation d’un objet connecté.
Domaine technique L'invention se rapporte au domaine général des réseaux de télécommunication et plus particulièrement à l’Internet des objets.
Bat de la technique
Depuis maintenant quelques années, l’Internet des Objets - ou loT pour Internet of Things - se déploie dans le milieu du grand public et dans le monde professionnel. Les objets connectés sont par exemple des objets domestiques comme des ampoules, des lampes, des radiateurs ou encore des appareils audio, vidéo, des compteurs d’électricité, des véhicules, des systèmes d’arrosage, etc. Les objets connectés dialoguent entre eux via plusieurs catégories de réseaux, qu’ils soient filaires ou sans fil.
Oes objets peuvent être issus du monde de la domotique, mais aussi plus largement peuvent être des objets quelconques. Un arrêt de bus, qui n’est pas un objet connecté traditionnel, peut cependant représenter un intérêt pour un utilisateur, souhaitant accéder par exemple à des fonctionnalités telles que les horaires de passage, les alertes, etc. Dans le même ordre d’idées, un contenu multimédia peut être vu comme un objet connecté.
Ces objets sont généralement limités en termes de fonctionnalités, notamment celles qui ne sont pas en relation directe avec le service mis en œuvre grâce à l’objet tel qu’initialement prévu par son constructeur. L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique. L’invention A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de virtualisation d’un objet connecté d’un réseau de communications, ledit objet connecté possédant au moins une caractéristique, dite caractéristique de base, ledit procédé étant caractérisé en ce qu’il comporte les étapes suivantes sur un dispositif de virtualisation, pour obtenir un avatar apte à représenter l’objet connecté : obtention d’au moins un identifiant de l’objet connecté à virtualiser ; obtention d’au moins une caractéristique de base de l’objet connecté à virtualiser ; obtention d’au moins une caractéristique d’enrichissement pour l’objet connecté ; création de l’avatar, ledit avatar comportant au moins : ledit au moins un identifiant de l’objet connecté ; une première structure de données comportant ladite au moins une caractéristique de base de l’objet connecté ; une seconde structure de données comportant ladite au moins une caractéristique d’enrichissement ; des instructions de programme de mise en oeuvre de ladite au moins une caractéristique d’enrichissement ; une structure de gestion d’adresses, dite proxy, comportant une correspondance au moins entre au moins une adresse de l’avatar et au moins une adresse de l’objet connecté.
Par « objet connecté », on entend ici toute entité physique ou logique apte à rendre un service à un utilisateur dans un réseau de communications, par exemple : • équipements personnels connectable (Smartphone, montre connectée, casque connecté, home automation, etc.), • équipements de l’espace public auxquels l’utilisateur peut avoir accès, • objets « virtuels » personnels, résultant de traitement de données personnelles, • objets « virtuels « de l’espace public, résultant de traitement de données publiques et/ou de données partagées (Open Data, Big Data), • contenus (films, musique) et accès à des contenus.
Un objet connecté comporte un ensemble de caractéristiques : • fonctions (donner l’heure, la température, streamer un flux vidéo, etc.) ; • flux associés aux fonctions en entrée ou en sortie de l’objet : commandes, réponses, messages, flux de données, par exemple audiovisuels, etc. On considère ici le terme « flux » au sens large. Par exemple, un message (commande, requête, réponse, acquittement, etc.) est un flux de données limité dans le temps.
Par « virtualisation », on entend la création d’un objet virtualisé associé à un objet connecté et disposant d’une adresse pour accéder à l’objet connecté. L’objet virtuel, après sa création, offre, ou expose, les caractéristiques de l’objet connecté et des caractéristiques d’enrichissement sélectionnées selon des modes de réalisation qui seront décrits par la suite.
Par « objet virtualisé », on entend un objet qui comporte l’objet connecté et son encapsulation selon la présente invention, c’est-à-dire un avatar de l’objet.
Par « avatar », on entend une représentation, ou encapsulation enrichie de l’objet ; l’avatar comprend donc : • une ou plusieurs caractéristiques de l’objet, de base ou enrichies, et dans ce dernier cas un ensemble de fonctions, ou instructions de programme de mise en oeuvre, associées ; • une structure proxy pour permettre d’accéder à l’objet connecté via l’avatar de l’objet virtualisé ; cette structure proxy est dédiée à l’objet connecté.
Par adresse de l’objet connecté, on entend n’importe quel type d’adresse correspondant à l’accès de tout ou partie des caractéristiques de l’objet connecté. Une telle adresse peut être physique (http://192.145.1-1) ou symbolique (zoom.ov3@mypasserelle.fr pour accéder à la fonction zoom de l’objet caméra via la passerelle domestique). Elle peut prendre la forme d’une adresse universelle (URI, URL), d’une adresse IP, etc.
Selon l’invention, les fonctions accessibles ou les flux générés d’un objet connecté peuvent être encapsulés dans un objet virtualisé de manière à ce que l’objet connecté soit caché derrière l’objet virtualisé.
Avantageusement, un utilisateur de l’objet connecté n’y accède plus directement mais via son avatar. L’utilisateur invoque donc l’avatar pour accéder à l’objet connecté. Cette encapsulation des données permet notamment de protéger l’objet et de le rendre indépendant. Par exemple, l’objet connecté (physique) peut être mis en veille et réveillé par son avatar lorsqu’une requête est adressée à l’objet virtualisé. L’objet virtualisé, c’est-à-dire l’entité formée par l’objet connecté et son avatar, peut mettre en œuvre les caractéristiques de l’objet connecté et des caractéristiques d’enrichissement sélectionnées selon des modes de réalisation qui seront décrits par la suite.
Avantageusement, les caractéristiques de base de l’objet peuvent être complétées par d’autres caractéristiques gérées non pas par l’objet connecté lui-même mais par l’objet virtualisé qui lui correspond. Par exemple, une webcam, objet physique, peut-être dotée d’une surcouche matérielle ou logicielle permettant de gérer ses horaires d’accès. A l’objet physique de départ (caméra connectée) disposant de fonctions de base (capture d’image, de vidéos, zoom, rotations, etc.) et de flux associés (commande de prise d’image, de zoom, flux de sortie audiovisuel, etc.) on ajoute donc de nouvelles fonctions (par exemple une fonction horloge) associées à de nouveaux flux (par exemple, la commande d’horodatage et le flux de sortie horodaté). Ces nouvelles caractéristiques (fonctions et flux) sont portées par l’avatar. Lorsque l’objet virtuel est utilisé, il peut être fait appel à ses caractéristiques de base (capturer une image) et/ou à ses caractéristiques d’enrichissement (horodater l’image). S’il est fait appel à une caractéristique de base, c’est l’objet connecté lui-même qui est mis en œuvre par l’avatar (par exemple pour capturer l’image), en d’autres termes les commandes, messages etc. lui sont retransmis par l’avatar (via son proxy) et les réponses reçues par l’avatar avant retransmission. S en revanche c’est une caractéristique d’enrichissement qui est invoquée, c’est le programme de mise en œuvre de cette caractéristique de l’avatar de l’objet qui est utilisé (puisque l’objet connecté ne connaît pas cette caractéristique, il lui est impossible de la mettre en œuvre).
Ainsi, l’invention permet d’enrichir un objet de caractéristiques qui n’en font pas partie selon ses spécifications initiales. Notamment dans le cas d’un objet physique, l’invention permet de le compléter par des fonctions utiles qui n’ont pas été prévues par le constructeur.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est en outre caractérisé en ce que l’étape d’enrichissement comporte les sous-étapes de : réception d’une requête d’enrichissement de l’objet comportant au moins une caractéristique d’enrichissement requise ; comparaison de la caractéristique d’enrichissement requise aux caractéristiques d’enrichissement de l’avatar ; en fonction des résultats de la comparaison, validation dans l’avatar de ladite caractéristique d’enrichissement ;
Par validation on entend la dotation effective de la caractéristique enrichie à l’objet virtualisé. La caractéristique enrichie est alors accessible au travers de l’objet virtualisé. En effet, elle pouvait être préalablement inscrite dans l’avatar sans être pour autant autorisée pour la mise en œuvre. La validation l’autorise.
Avantageusement selon ce mode, l’utilisateur peut demander un enrichissement de son objet connecté. Pour cela, il établit une requête à destination du dispositif de virtualisation. Par exemple, il peut demander d’enrichir sa caméra par une horloge. Les modalités de la requête peuvent prendre toute forme à la portée de l’homme du métier. Par exemple on peut imaginer que l’utilisateur dispose sur son smartphone, ou sur son PC, d’une représentation de l'objet virtualisé « caméra », dans lequel il vient glisser une icône d’horloge. Dans ce cas, si l’avatar dispose d’une caractéristique « horloge », cette caractéristique est validée dans l’avatar et devient disponible en tant que caractéristique d’enrichissement de l’objet virtualisé, au même titre que les caractéristiques de base.
Selon un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, un procédé tel que décrit ci-dessus est en outre caractérisé en ce l’étape d’enrichissement comporte une validation de l’ensemble des caractéristiques d’enrichissement disponibles dans la seconde structure de données de l’avatar.
Avantageusement selon cette variante, l’enrichissement est fait automatiquement. Toutes les caractéristiques d’enrichissement qui ont été obtenues et renseignées dans la structure de l’avatar sont ajoutées automatiquement à l’objet virtualisé. Par exemple si l’avatar dispose d’une caractéristique « horloge » et d’une caractéristique « température », ces caractéristiques sont activées dans l’avatar et deviennent disponibles en tant que caractéristiques d’enrichissement de l’objet virtualisé, au même titre que les caractéristiques de base.
Selon un autre aspect fonctionnel, l’invention concerne aussi un procédé de mise en oeuvre d’un objet virtualisé d’un objet connecté dans un réseau de communications, ledit objet virtualisé comportant un avatar de l’objet connecté, le procédé étant caractérisé en ce qu’il comporte les étapes suivantes sur un dispositif de mise en œuvre de l’objet virtualisé : obtention d’un message pour utiliser l’objet virtualisé, ledit message comportant au moins une caractéristique à mettre en œuvre ; obtention de l’avatar de l’objet virtualisé, ledit avatar comportant au moins : une identification de l’objet connecté ; une première structure de données comportant au moins une caractéristique de base de l’objet connecté ; une seconde structure de données comportant au moins une caractéristique d’enrichissement ; des instructions de programmes de mise en œuvre de ladite au moins une caractéristique d’enrichissement ; une structure de gestion d’adresses, dite proxy comportant une correspondance au moins entre au moins une adresse de l’avatar et au moins une adresse de l’objet connecté ; comparaison de la caractéristique à mettre en œuvre aux caractéristiques de l’avatar ; en fonction des résultats de la comparaison : mise en œuvre de l’objet connecté si la caractéristique à mettre en œuvre est une caractéristique de base, et/ou mise en œuvre du programme de mise en œuvre d’une caractéristique d’enrichissement si la caractéristique à mettre en œuvre est une caractéristique d’enrichissement.
Les objets selon cet aspect fonctionnent de l’invention procurent au moins les mêmes avantages que ceux procurés par le procédé selon le premier aspect fonctionnel. Les caractéristiques optionnelles évoquées pour le premier aspect peuvent aussi s’appliquer. Notamment, l’objet virtualisé encapsule et enrichit l’objet connecté de manière à pouvoir accéder non seulement aux caractéristiques (fonctions et flux) de l’objet connecté mais également aux fonctions enrichies de l’objet virtuel grâce à son avatar.
On notera de surcroît que : le message pour utiliser/mettre en œuvre l’objet virtualisé peut provenir de l’objet connecté lui-même (par exemple s’il remonte la température toutes les heures, ou si un événement a déclenché l’objet - cas d’une ouverture de porte) ou d’un équipement quelconque du réseau (terminal de l’utilisateur, serveur dans le réseau, etc.), ou encore de l’objet virtualisé (qui surveille par exemple les alertes de l’objet connecté). la caractéristique requise (par l’objet lui-même ou par un équipement du réseau) peut correspondre à une fonction rendue : par l’objet physique (zoom, prise de vue de la caméra, etc.) ; par l’objet virtualisé (transmission de l’heure) ; ou par une combinaison des deux (horodatage, c’est-à-dire transmission de l’heure dans le flux)
Selon un aspect matériel, l'invention concerne également un dispositif de virtualisation d’un objet connecté d’un réseau de communications, ledit objet possédant au moins une caractéristique, dite caractéristique de base, le dispositif de virtualisation comportant : un module d’obtention d’au moins un identifiant et au moins une caractéristique de base de l’objet connecté ; un module de génération d’un avatar ; un module de génération d’une première structure de données comportant ladite au moins une caractéristique de base de l’objet connecté ; - un module d’obtention d’au moins une caractéristique d’enrichissement pour l’objet connecté ; un module de génération d’une seconde structure de données comportant ladite au moins une caractéristique d’enrichissement pour l’objet connecté; - un module d’obtention des instructions de programme de mise en œuvre de ladite au moins une caractéristique d’enrichissement ; un module de gestion d’adresses, pour générer une structure de données, dite proxy, comportant au moins une correspondance entre une au moins une adresse de l’avatar et au moins une adresse de l’objet connecté ;
Le terme module utilisé dans la présente description peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.)
Selon un autre aspect matériel, l'invention concerne également un dispositif de mise en œuvre d’un objet virtualisé d’un objet connecté dans un réseau de communications, le dispositif de mise en œuvre comportant : un module pour obtenir un message pour utiliser l’objet virtualisé, ledit message comportant au moins une caractéristique à mettre en œuvre ; - un module pour obtenir l’avatar de l’objet virtualisé ; un module pour obtenir une première structure de données comportant au moins une caractéristique de base de l’objet connecté ; un module pour obtenir une seconde structure de données comportant au moins une caractéristique d’enrichissement ; un module pour obtenir des instructions de programme de mise en œuvre de ladite au moins une caractéristique d’enrichissement; un module pour obtenir une structure de gestion d’adresses, dite proxy, comportant une correspondance au moins entre au moins une adresse de l’avatar et au moins une adresse de l’objet connecté ; un module pour comparer la caractéristique à mettre en œuvre aux caractéristiques de l’avatar ; un module pour mettre en œuvre, en fonction des résultats de la comparaison : l’objet connecté si la caractéristique à mettre en œuvre est une caractéristique de base, et/ou le programme de mise en oeuvre d’une caractéristique d’enrichissement si la caractéristique à mettre en oeuvre est une caractéristique d’enrichissement.
Selon un autre aspect matériel, l'invention concerne également une passerelle domestique comprenant un dispositif de virtualisation et/ou un dispositif de mise en œuvre tels que décrits auparavant.
Selon un autre aspect matériel, l'invention concerne également un objet virtualisé comportant : un objet connecté disposant d’au moins un identifiant, une caractéristique de base et une adresse ; un avatar dudit objet connecté, comprenant : - une identification de l’objet connecté ; - une première structure de données comportant au moins une caractéristique de base de l’objet connecté ; - une seconde structure de données comportant au moins une caractéristique d’enrichissement de l’objet connecté ; - des instructions de programmes de mise en œuvre de ladite au moins une caractéristique d’enrichissement ; - une structure de gestion d’adresses, dite proxy, comportant au moins une correspondance entre au moins une adresse de l’avatar et au moins une adresse de l’objet connecté.
Selon un autre aspect matériel, l’invention concerne encore un programme d’ordinateur apte à être mis en œuvre sur un dispositif de virtualisation tel que décrit ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de virtualisation défini au-dessus.
Selon un autre aspect matériel, l’invention concerne encore un programme d’ordinateur apte à être mis en œuvre sur un dispositif de communication tel que décrit ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de communication défini au-dessus.
Selon encore un autre aspect matériel, l’invention a trait à un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes de l’un quelconque des procédés définis ci-dessus.
Les objets selon les aspects matériels de l’invention procurent au moins les mêmes avantages que ceux procurés par le procédé selon le premier aspect fonctionnel. Les caractéristiques optionnelles évoquées pour le premier aspect peuvent s’appliquer aux aspects matériels. L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.
Les figures:
La figure 1 représente le contexte général de l’invention, montrant des objets connectés et virtuels d’un utilisateur d’un réseau local selon l’état de l’art.
La figure 2 illustre un objet virtualisé selon un mode de réalisation de l’invention.
La figure 3 illustre un avatar objet selon un mode de réalisation de l’invention.
La figure 4 représente une architecture d’un dispositif de virtualisation d’objets et/ou de mise en œuvre d’objets virtualisés selon un mode de réalisation de l’invention.
La figure 5 représente un chronogramme de virtualisation d’un objet et de mise en œuvre subséquente de l’objet virtualisé selon un mode de réalisation de l’invention.
Description détaillée d'un exemple de réalisation illustrant l'invention
La figure 1 représente le contexte général de l’invention selon l’état de l’art, montrant des objets connectés et virtuels d’un utilisateur d’un réseau local ou LAN (Local Area Network) 1. Selon cet exemple non limitatif, le réseau LAN est un réseau domestique connecté à un réseau de type étendu, ou WAN (Wide Area Network), 3, par exemple un réseau Internet. Plus largement, un réseau LAN pourrait être un réseau d’entreprise ou être limité à un seul objet connecté au réseau Internet (par exemple une Webcam de plage) et le réseau WAN 3 pourrait être de n’importe quel type (cellulaire, GSM - Global System for Mobile Communications, UMTS -Universal Mobile Télécommunications System, Wifi - Wireless, etc.) sans sortir du cadre de l’invention.
Un élément de gestion du réseau (2) (une passerelle résidentielle, professionnelle, un hub, etc.) et des équipements terminaux, appelés dans la suite objets connectés ou plus simplement objets (Oi) sont connectés sur le réseau local 1. Il s’agit respectivement selon l’exemple d’un casque connecté (01), d’un smartphone (02), d’une caméra connectée (03), d’un capteur de température (04). Ces objets sont aptes à communiquer sur le réseau local et peuvent être accédés de l’intérieur ou de l’extérieur du réseau local via la passerelle de service (2). D’autres objets situés dans le réseau étendu (3) présentent un intérêt pour un utilisateur du réseau local : objets publics : on a représenté à titre d’exemple un arrêt de bus (07) auquel sont associées des informations de trafic, horaires, etc. et un pluviomètre (06), ainsi qu’une une bicyclette partagée (08) objets privés sur le réseau public : à laquelle sont associées des informations de localisation, état, etc. On a représenté à titre d’exemple un compte de réseau social (09) de l’utilisateur.
On notera que ces objets sont de nature hétérogène : - objet physique : il s’agit d’un équipement physique ayant la capacité de se connecter à Internet. Il peut être fournisseur de flux d’informations, en temps réel ou non, et/ou actionneur au sens où le fait de recevoir un flux d’informations particulier (par exemple, de commandes) va provoquer de sa part une action associée à une fonction. Ces objets peuvent différer par leur système d’exploitation (Windows, Linux, Android, etc.), leur type de connexion au réseau (Ethernet, Wifi, Bluetooth, etc.), et les fonctions/actions dont ils sont capables: mesurer la température, communiquer sur des réseaux sociaux, mettre en oeuvre une recette de cuisine, lire un contenu multimédia, enregistrer une vidéo de surveillance, la transmettre, détecter un mouvement, allumer une lampe, etc. - objet virtuel : un objet virtuel n’est pas matérialisé par un équipement physique. Il ne s’agit que d’une représentation simulée par une entité numérique. Il s’agit par exemple d’une fonction d’horodatage, de localisation, etc. - objet physique/virtuel : dans ce cas l’équipement physique existe et est accessible aux personnes physiques (par exemple via une interface graphique) mais il est incapable de produire ou de traiter un flux d’informations. Par contre, son activité peut être simulée par une entité numérique.
On notera que de surcroît, ces objets, physiques, virtuels ou physique/virtuel, peuvent être aussi caractérisés en termes de propriété et d’accès (ils peuvent être personnels, partagés, ou publics) sans sortir du cadre de l’invention.
Le tableau ci-dessous illustre ces définitions : la colonne de gauche indique la nature de l’objet (physique, virtuel ou physique/virtuel) et la ligne du haut son type (personnel ou public).
Table 1 : typologie des objets connectés
On peut dès maintenant noter que chacun des objets présente un certain nombre de caractéristiques (fonctions et/ou flux d’entrée/sortie) mais pourrait être utilement enrichi de caractéristiques qu’il ne possède pas nativement. Selon quelques exemples : la caméra ne dispose pas d’informations horaires ; or il peut être utile d’horodater ses données ; la bicyclette ne dispose pas de compteur de kilomètres ; or il peut être utile de connaître le nombre de kilomètres parcourus ; l’arrêt de bus ne dispose pas d’informations de trafic ; or il peut être utile de connaître son prochain horaire de passage, de savoir si le bus est à l’heure, s’il est chargé ou non, etc. Ces informations (trafic, horaires) sont disponibles auprès du système d’information de l’exploitant ; il peut être intéressant de considérer l’arrêt de bus physique (objet non connecté) comme un arrêt de bus virtualisé auquel on a adjoint les fonctions de trafic et horaires.
On va maintenant décrire un mode de réalisation de l’invention à l’appui de la figure 2, dont le but est d’offrir à l’utilisateur un objet virtualisé, éventuellement enrichi, correspondant à un objet connecté.
Dans l’exemple qui suit, l’objet connecté est un objet physique (une caméra) mais il pourrait être virtuel (une horloge) sans perte de généralité.
Selon cet exemple, l’objet caméra du réseau local de l’utilisateur (03) va être enrichi d’une « fonction » dont il ne dispose pas nativement : une fonction d’horodatage (FH) provenant du réseau étendu ; les flux de la caméra peuvent être horodatés et par ailleurs l’heure peut être transmise en réponse à une requête vers l’objet virtualisé. La caméra est donc dotée, via une surcouche matérielle ou logicielle, d’une caractéristique (fonction et flux) supplémentaire.
L’objet résultant est un objet virtualisé, c’est-à-dire un objet particulier correspondant à un objet connecté, apte au minimum à rendre ses fonctions et traiter des flux d’informations vers ou depuis l’objet connecté (physique ou virtuel).
Selon ce mode de réalisation de l’invention, l’objet virtualisé correspondant à un objet connecté est représenté comme une entité rendant des fonctions et possédant des flux d’entrée et de sortie. Tous les flux de l’objet connecté passent par un ensemble logiciel assimilable à un proxy, l’avatar objet, construit sur les flux issus ou en direction de l’objet. Cet avatar objet représente l’objet sur le réseau. On notera que l’objet connecté, s’il dispose des ressources nécessaires, hardware et software, peut être autonome à la condition de supporter les fonctions de l’avatar objet. L’avatar est donc une interface « standardisée » avec des capacités qui peuvent être également standardisées (horodatage). Il s’agit en quelque sorte d’une surcouche de l’objet (encapsulation).
Selon ce mode de réalisation de l’invention, qui sera détaillé plus précisément à l’appui des figures suivantes, le propriétaire de l’objet l’installe dans un premier temps sur sa passerelle domestique. Un dispositif de virtualisation sur la passerelle construit pour l’objet un avatar. Par la suite, l’avatar est accessible via une nouvelle adresse qui sert à accéder à l’objet. Cet avatar peut aussi être typiquement mis en œuvre dans le réseau de l’opérateur si la passerelle domestique est virtualisée, ou encore dans le réseau (cloud) à la condition de mettre en œuvre une liaison sécurisée entre l’avatar qui se trouve dans le réseau et l’objet. De même, certains objets pourraient directement intégrer l’avatar (objets connectés) ou l’implémenter (dans un cas de représentation informatique d’un objet physique). L’avatar créé agit comme un proxy entre l’objet connecté et les requêtes qui lui sont faites. On rappelle qu’un proxy (PY) est un composant logiciel qui joue le rôle d'intermédiaire en se plaçant entre deux entités pour faciliter les échanges. En l’occurrence, le proxy (PY) de l’avatar est placé entre l’utilisateur de l’objet, par exemple un site Web sur un smartphone, et l’objet connecté sur le LAN/WAN. Le proxy redirige les flux de manière transparente pour l’utilisateur, vers et depuis l’objet connecté. L’avatar peut avoir son propre proxy, ou alternativement, être rattaché à un proxy qui regroupe un ensemble d’avatars.
Une fois l’avatar créé, le type de l’objet peut être identifié et par exemple grâce à une base de référencement, ou grâce à l’avatar qui comporte lui-même les informations, on peut récupérer les informations concernant les interfaces (flux, fonctions) de l’objet et ainsi les montrer, ou exposer, par exemple dans une interface graphique associée à l’objet virtuel. Par exemple l’avatar associé à la caméra a des caractéristiques de zoom, le balayage, de format de codage, prise d’image fixe, etc. et de plus, selon l’exemple proposé plus haut, des fonctions d’horodatage. L’objectif est de pouvoir adapter aux besoins de l’utilisateur l’ensemble des objets connectés quelle que soient leurs caractéristiques propres, via un mécanisme d’enrichissement.
La figure 3 représente de manière plus détaillée une architecture possible pour un avatar objet selon un mode de réalisation de l’invention. Selon cet exemple, c’est l’objet connecté 03 (la caméra) qui est considéré pour aboutir à un objet virtualisé (0V3). L’avatar (AV_03) comporte : une identification (I D_03) de l’objet connecté ; une première structure de données (SDB_03) comportant au moins une caractéristique de base (CB1_03,... CBN_03) de l’objet connecté (zoom, capture d’image, flux vidéo, commande de capture, etc.) ; une seconde structure de données (SDE 03) comportant au moins une caractéristique d’enrichissement (CE103,... CEN03) de l’objet connecté (horodatage, température, etc.); des instructions de programme de mise en œuvre (PE1_03 ... PEN 03) des caractéristiques d’enrichissement (CE1_03... CEN03) ; en effet les caractéristiques d’enrichissement ne sont pas mises en œuvre sur l’objet connecté, contrairement aux caractéristiques de base. Il faut donc prévoir une surcouche logicielle pour mettre en œuvre ces caractéristiques (par exemple : récupérer l’heure, la transmettre dans un flux, horodater le flux, etc.) une structure de gestion d’adresses, dite proxy (PY_03) comportant une correspondance entre une au moins une adresse de l’avatar (@AV_0V3) et au moins une adresse de l’objet connecté (@03). On rappelle que l’adresse peut être de n’importe quel type et adresser tout ou partie des caractéristiques de l’objet connecté. Par ailleurs soit l’objet a son propre proxy ; de manière schématique dans ce cas l’objet sera accessible via une adresse de type /ma__caméra - soit il est rattaché à un proxy qui comporte un ensemble d’avatars ; de manière schématique dans ce cas l’objet sera accessible via une adresse de type proxy_objets/ma_caméra (et un autre objet, par exemple un thermomètre connecté, sera accessible via proxy_ objets/mon_ thermomètre.
La figure 4 représente une architecture d’un dispositif de virtualisation d’objets et/ou de mise en oeuvre d’objets virtualisés selon un mode de réalisation de l’invention.
Le dispositif de virtualisation comprend : - des mémoires (M) associées à un processeur (CPU). Les mémoires peuvent être de type FiOM (de l’anglais Ftead Onty Memorÿ) ou RAM (de l’anglais Random Access Memorÿ). Blés peuvent prendre la forme d’une carte amovible (SD, flash, etc.). Une partie de la mémoire M peut contenir notamment, selon l’invention, les avatars correspondant aux objets virtualisés. un module de communication (GOMM), pour la communication avec les objets connectés, avec l’utilisateur, et avec différentes entités du réseau local et ou/étendu ; ce module peut être de type WiFI, Bluetooth, ETHERNET etc. et utiliser tout protocole adéquat pour dialoguer avec ces entités (http, RTP, ...) ; un module d’obtention des caractéristiques de base (GETB), permettant par exemple de découvrir un objet physique dont la référence lui est communiquée (par exemple, une caméra) et en déduire les caractéristiques de base (fonctions et flux) pertinentes de l’objet ; un module d’obtention des caractéristiques enrichies (GETE), permettant d’obtenir un ensemble de caractéristiques enrichies pouvant être associées à des objets connectés (par exemple, l’horodatage, la température, le trafic, etc.) ; selon l’exemple de la figure 3, ces données sont lues dans une base (BD__CE) de caractéristiques ; cette base peut être située sur le dispositif de virtualisation ou non (elle peut être dans le cloud, sur un équipement quelconque du réseau local ou étendu, etc.) ; un module de génération d’avatars (CRAV) en charge de virtualiser les objets qui lui sont fournis, c’est-à-dire de générer un avatar pour un objet connecté, en l’enrichissant de fonctions sont il ne dispose pas à l’origine. un module de gestion de proxys (PY) qui permet d’associer une structure proxy (FY_Oi) à un ou plusieurs avatars objet et par la suite de gérer les flux vers et en provenance de l’objet. un module de mise en œuvre des avatars (EXAV) qui permet, une fois l’objet virtualisé, c’est-à-dire son avatar créé, d’accéder à l’objet virtualisé (accès aux caractéristiques de base correspondant aux caractéristiques de l’objet connecté et/ou accès aux caractéristiques d’enrichissement offertes par l’avatar). On notera que pour des raisons de simplification, le module EXAV a été placé sur le dispositif de virtualisation. Cependant il pourrait faire partie d’un dispositif de mise en œuvre des avatars distinct du dispositif de virtualisation.
Une base d’avatars (BD AV) ; cette base peut se situer sur le dispositif de virtualisation ou à l’extérieur. Elle contient les avatars des objets virtualisés. un module d’interface utilisateur (MlU), pour rendre disponible, ou exposer, à l’utilisateur, une adresse d’accès (@AV_G3) audit avatar (AV 03) et les caractéristiques de l’avatar de l’objet (par exemple sous la forme d’un objet graphique qui peut être transmis à l’utilisateur, comme représenté à la figure 4 suivante : représentation de l’objet sous forme de pictogrammes et fonctions associées).
La figure 5 représente un chronogramme de virtualisation d’un objet connecté et de mise en œuvre subséquente de l’objet virtualisé.
Elle détaille en particulier la création d’un avatar d’objet sur le dispositif de virtualisation d’objets situé selon cet exemple sur une passerelle domestique, et l’utilisation ultérieure de cet objet par son propriétaire. Elle comprend les phases principales de virtualisation (déclaration de l’objet connecté, création et enrichissement de l’avatar), d’exposition de l’objet virtualisé (mise à disposition de l’utilisateur) puis de mise en œuvre de l’objet virtualisé selon des exemples.
Selon ce mode de réalisation, les dispositifs de virtualisation (DV) et de mise en œuvre des objets virtualisés (DMO) sont confondus et se trouvent sur la passerelle de service. Toute autre localisation de l’un et/ou l’autre de ces deux dispositifs pourrait être envisagée : dans le réseau local, dans le réseau étendu, portés par un serveur, un terminal, un objet connecté, etc. i. virtualisation de l’obiet
Le but de cette phase est de créer un objet virtualisé (0V3) représentant un objet connecté (03). On rappelle que l’objet virtualisé correspond à l’objet connecté et son avatar.
Lors d’une étape E10/E30 préliminaire, l’utilisateur déclare un objet connecté. Selon cet exemple, il s’agit d’une caméra connectée (03) du réseau local. L’objet connecté à virtualiser est donc physique mais il pourrait être virtuel sans perte de généralité (par exemple, l’arrêt de bus présenté plus haut à l’appui de la figure 1 est représenté par un système informatique). N’importe quel autre objet pourrait être considéré sans perte de généralité, comme décrit à l’appui de la figure 1. Plusieurs méthodes peuvent être utilisées : l’objet connecté se déclare lui-même auprès de la passerelle de service (nom de la caméra, modèle, etc.) ; l’utilisateur rentre lui-même les caractéristiques de l’objet ; etc.
Lors d’une étape E20, le dispositif de virtualisation reçoit la déclaration de l’objet et prépare un objet virtualisé, ou avatar, possédant les caractéristiques de l’objet (physique ou virtuel) qui vient d’être déclaré. Pour obtenir ces caractéristiques, la passerelle (module DEC) peut selon les cas : interroger un site de référencement de l’objet pour recevoir ses caractéristiques de fonctions et de flux (par exemple, le site du constructeur pour une caméra) ; recevoir cette information de la part de l’objet connecté ou du propriétaire.
Lors d’une étape E21, le dispositif de virtualisation (CFIAV) virtualise l’objet, c’est-à-dire crée pour cet objet une structure de données et un ensemble de caractéristiques logicielles (ou matérielles) associées, appelée avatar (AV). L’avatar est une surcouche logicielle de l’objet qui possède/présente les fonctions et les flux de l’objet. On rappelle qu’il comporte une structure portant les caractéristiques de base de l’objet connecté et une structure portant les caractéristiques d’enrichissement possibles de l’objet avec les programmes de mise en oeuvre associés. Par ailleurs il est associé à un proxy permettant de faire le lien entre les adresses de l’objet virtualisé et les adresses de l’objet connecté.
De tels avatars sont schématisés ci-dessous à titre d’exemple explicatif pour l’objet « caméra » (table 2) et l’objet « bicyclette » (table 3) :
Table 2 : exemple d’avatar d’une caméra virtualisée
Table 3 : exemple d’avatar d’une bicyclette enrichie
Selon le mode de réalisation de la figure 4, les caractéristiques d’enrichissement (et les programmes associés) sont extraits d’une base de caractéristiques d’enrichissement (BDCE).
Selon un mode de mise en oeuvre, toutes les caractéristiques d’enrichissement insérées dans l’avatar à l’étape précédente sont validées automatiquement dans l’objet virtuel, c’est-à-dire que ces caractéristiques de l’objet virtuel peuvent être mises en œuvre.
Selon un autre mode de réalisation, toutes les caractéristiques d’enrichissement insérées dans l’avatar à l’étape précédente sont proposées mais ne sont pas validées automatiquement. Dans ce cas, lors d’une étape E12, l’utilisateur demande un enrichissement effectif de l’objet avec une caractéristique d’enrichissement. Selon l’exemple représenté, il demande d’enrichir la caméra d’une fonction d’horloge (CE). A cet effet il peut par exemple saisir dans une interface graphique un pictogramme de l’objet connecté, un pictogramme d’un objet horloge, et rapprocher les deux pictogrammes. Toute autre méthode peut être envisagée pour aboutir à la transmission d’un message portant un identifiant de l’objet (identifiant ID 03 de l’objet connecté, ou son adresse, ou l’adresse de l’avatar en cours de création si cette adresse a été transmise à l’utilisateur, etc) et au moins une caractéristique d’enrichissement.
On notera que les deux modes de réalisation peuvent être combinés si une partie seulement des caractéristiques d’enrichissement est validée automatiquement.
Le dispositif de virtualisation reçoit cette demande à l’étape E22 et la traite à l’étape E23. Il vérifie que l’avatar est bien pourvu de la caractéristique d’enrichissement demandée,
puis il valide cette caractéristique dans l’avatar si c’est le cas. Enfin, il mémorise l’avatar dans la base de données d’avatars.
De manière facultative, l’avatar est également pourvu d’une représentation de l’objet virtualisé. Cette représentation peut être de n’importe quel type (graphique, textuelle, sonore, etc.). Elle est accessible par exemple sur le smartphone de l’utilisateur, qui peut recevoir cette représentation et « voit » alors l’objet virtualisé sous la forme d’une IHM ; par exemple, la représentation associée à l’objet caméra peut montrer/exposer avec la représentation de la caméra: - les fonctions arrêt sur image, ralenti, rembobinage, avance rapide. les commandes correspondant aux flux d’entrée associés (par exemple en cliquant sur un bouton, l’utilisateur peut rembobiner la vidéo) ; - le flux de sortie de la caméra ; etc. A l’issue de ces étapes, l’objet virtualisé possède donc un avatar comprenant au minimum les caractéristiques de base de l’objet connecté, un proxy pour y accéder de manière transparente via l’adresse de l’avatar, et éventuellement une représentation graphique.
De manière facultative, l’utilisateur (sur son smartphone) et le proxy peuvent échanger un secret au cours des étapes E14 et E24, afin de pouvoir communiquer par la suite de manière sécurisée. ii. Exposition de l’obiet (mise à disposition de l’obietï
Lors des étapes E25, E15, le dispositif de virtualisation fournit au propriétaire de l’objet connecté l’adresse de l’objet virtualisé, c’est-à-dire l’adresse avatar (@AV_03) contenue dans le proxy de l’avatar. Grâce à cette adresse, l’utilisateur peut accéder à l’objet virtualisé ; de surcroît, lors de cette étape, le dispositif de virtualisation peut aussi fournir une représentation (IHM) de l’objet via son module d’interface utilisateur (MUI).
Le propriétaire de l’objet connecté muni de l’adresse de l’avatar objet (@AV_03) et éventuellement du secret partagé (S) et d’une représentation (IHM) de l’objet, peut maintenant se connecter à l’avatar, par exemple via une interface graphique qui s’affiche sur son smartphone. iii. mise en œuvre de l’obiet
Selon un exemple de mise en œuvre de l’objet virtualisé, le propriétaire de l’objet connecté décide, au cours d’une étape E16, de mettre en œuvre l’objet virtualisé. A cet effet, il prépare un message à destination de l’objet virtualisé (sur l’adresse @AV_G3 qui lui a été communiquée précédemment) en demandant une caractéristique de base (CB1) et une caractéristique d’enrichissement (CE1) de l’objet, selon cet exemple une capture de caméra (CB1 = capture image, voir par exemple table 2) et un horodatage de l’image capturée (Œ1 = horodatage).
Le dispositif de mise en oeuvre de l’objet virtualisé sur la passerelle (module EXAV) reçoit ce message lors d’une étape E26 et l’analyse. A cet effet, il interroge la base de données d’avatars pour obtenir l’avatar (AV3) de l’objet.
Grâce à l’avatar, il reconnaît la première caractéristique comme une caractéristique de base (CB1 = capture image, voir par exemple table 2, se trouve dans la structure de base) et la seconde caractéristique comme une caractéristique d’enrichissement (CE1 = horodatage). A la suite de cette analyse, il peut donc : lors d’une étape E27, transmettre l’ordre de capture d’image à l’objet connecté caméra (03) et récupérer en retour le flux de capture ; lors d’une étape E28, faire appel au programme de l’avatar lié à la caractéristique d’enrichissement « horodatage » (voir table 2) ; puis lors d’une étape E29 retransmettre le flux horodaté au terminal de l’utilisateur. 11 va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention.
Notamment pour ce qui concerne la mise en œuvre de l’objet virtualisé, de nombreuses variantes peuvent être envisagées : - la mise en œuvre peut être déclenchée par l’objet connecté lui-même, par exemple si celui-ci est un capteur de mouvement, il peut déclencher une mise en œuvre de l’objet virtuel « caméra » 0V3 lorsqu’il détecte un mouvement. Le signal de détection est reçu par l’objet virtualisé, éventuellement enrichi avant d’être par exemple transmis à un serveur à distance. - la mise en œuvre peut être déclenchée par l’objet virtualisé lui-même ; l’avatar de l’objet virtualisé surveille l’objet connecté. Il lui transmet lots d’une étape similaire à l’étape E27 un ordre de capture d’image ; il récupère la capture, éventuellement l’enrichit (par horodatage...) et le transmet à un serveur à distance. - etc.

Claims (10)

  1. Revendications
    1. Procédé de virtualisation d’un objet connecté (03) d’un réseau de communications (1,3), ledit objet connecté possédant au moins une caractéristique, dite caractéristique de base (C£1_03...CBN_03), ledit procédé étant caractérisé en ce qu’il comporte les étapes suivantes sur un dispositif de virtualisation, pour obtenir un avatar (AV 03) apte à représenter l’objet connecté : obtention (E20) d’au moins un identifiant (ID) de l’objet connecté à virtualiser ; obtention (E20) d’au moins une caractéristique de base (CB1_03...CBN_03) de l’objet connecté à virtualiser ; obtention (E22) d’au moins une caractéristique d’enrichissement (Œ1_03...CEN_03) pour l’objet connecté ; création (E21, E23) de l’avatar (AV_03), ledit avatar comportant au moins : ledit au moins un identifiant (ID) de l’objet connecté ; une première structure de données (SDB 03) comportant ladite au moins une caractéristique de base (CB1_03,... CBN03) de l’objet connecté ; une seconde structure de données (SDE_03) comportant ladite au moins une caractéristique d’enrichissement (CE1_03,...CEN_O3) ; des instructions de programmes (PE1_03 ... PEN_03) de mise en oeuvre de ladite au moins une caractéristique d’enrichissement (Œ1_03,...CEN_O3) ; une structure de gestion d’adresses, dite proxy (PY_03) comportant une correspondance au moins entre au moins une adresse de l’avatar (@AV_0V3) et au moins une adresse de l’objet connecté (@03).
  2. 2. Procédé de virtualisation d’un objet connecté (03) selon la revendication 1, caractérisé en ce l’étape d’enrichissement comporte en outre les sous-étapes de : réception d’une requête d’enrichissement de l’objet (E22) comportant au moins une caractéristique d’enrichissement requise (Œ) ; - comparaison de la caractéristique d’enrichissement requise (CE) aux caractéristiques d’enrichissement de l’avatar (Œ1_03..CEN_03) ; en fonction des résultats de la comparaison, validation dans l’avatar de ladite caractéristique d’enrichissement (Œ1_G3).
  3. 3. Procédé de virtualisation d’un objet connecté (03) selon la revendication 1, caractérisé en ce en ce l’étape d’enrichissement comporte une validation de l’ensemble des caractéristiques d’enrichissement disponibles dans l’avatar.
  4. 4. Procédé de mise en oeuvre d’un objet virtualisé (0V3) d’un objet connecté (03) dans un réseau de communications (1,3), ledit objet virtualisé (0V3) comportant un avatar de l’objet connecté, le procédé étant caractérisé en ce qu’il comporte les étapes suivantes sur un dispositif de mise en oeuvre de l’objet virtualisé (DMO): obtention d’un message (E26) pour utiliser l’objet virtualisé, ledit message comportant au moins une caractéristique à mettre en oeuvre (Œ1, CB1) ; obtention (E26) de l’avatar de l’objet virtualisé (AV 03), ledit avatar comportant au moins : une identification (ID) de l’objet connecté ; une première structure de données (SDB 03) comportant au moins une caractéristique de base (CB1_03,...CBN_G3) de l’objet connecté ; une seconde structure de données (SDE_03) comportant au moins une caractéristique d’enrichissement (Œ1_03,...CEN_O3) ; des instructions de programmes (PE1_03 ... PEN_03) de mise en oeuvre de ladite au moins une caractéristique d’enrichissement (Œ1_03,...CEN_O3) ; une structure de gestion d’adresses, dite proxy (PY_03) comportant une correspondance au moins entre au moins une adresse de l’avatar (@AV_0V3) et au moins une adresse de l’objet connecté (@03) comparaison (E26) de la caractéristique à mettre en oeuvre (Œ1_03, CB1_03) aux caractéristiques de l’avatar (Œ1_03...ŒN_03) ; en fonction des résultats de la comparaison : mise en œuvre (E27) de l’objet connecté si la caractéristique à mettre en œuvre est une caractéristique de base, et/ou mise en œuvre (E28) du programme de mise en œuvre d’une caractéristique d’enrichissement si la caractéristique à mettre en œuvre est une caractéristique d’enrichissement.
  5. 5. Dispositif de virtualisation (DV) d’un objet connecté (03) d’un réseau de communications (1,3), ledit objet possédant au moins une caractéristique, dite caractéristique de base (œi_03...CBN_03), le dispositif de virtualisation comportant : un module d’obtention (GETB) d’au moins un identifiant et au moins une caractéristique de base (CB1_G3...CBN_G3) de l’objet connecté ; un module de génération (CRAV) d’un avatar (AV_03); un module de génération (CRAV) d’une première structure de données (SDBG3) comportant ladite au moins une caractéristique de base (CB1_03,... CBN_03) de l’objet connecté ; un module d’obtention (GETE) d’au moins une caractéristique d’enrichissement (Œ1_03...CEN_03) pour l’objet connecté ; un module de génération (CRAV) d’une seconde structure de données (SDE 03) comportant ladite au moins une caractéristique d’enrichissement (CE103) pour l’objet connecté ; un module d’obtention (GETE) des instructions de programmes de mise en œuvre de ladite au moins une caractéristique d’enrichissement (CE1_03,...CEIM_O3) ; un module de gestion d’adresses (PY) pour générer une structure de données, dite proxy, comportant au moins une correspondance entre une au moins une adresse de l’avatar (@AV_0V3) et au moins une adresse de l’objet connecté (@03) ;
  6. 6. Dispositif de mise en œuvre (DMO) d’un objet virtualisé (0V3) d’un objet connecté (03) dans un réseau de communications (1,3), le dispositif de mise en œuvre comportant : un module pour obtenir (OOMM) un message (E26) pour utiliser l’objet virtualisé, ledit message comportant au moins une caractéristique à mettre en œuvre (Œ1, CB1) ; un module pour obtenir (EXAV) l’avatar de l’objet virtualisé (AV 03) : un module pour obtenir (EXAV) une première structure de données (SDB 03) comportant au moins une caractéristique de base (CB1_03,... CBN_Q3) de l’objet connecté ; un module pour obtenir (EXAV) une seconde structure de données (SDE 03) comportant au moins une caractéristique d’enrichissement (Œ1_03,...CEN_O3) ; un module pour obtenir (EXAV) des instructions de programmes (PE1J33 ... PEN_03) de mise en œuvre de ladite au moins une caractéristique d’enrichissement (Œ1_03,... ŒN_03) ; un module pour obtenir (EXAV) une structure de gestion d’adresses, dite proxy (PY_03) comportant une correspondance au moins entre au moins une adresse de l’avatar (@AV_0V3) et au moins une adresse de l’objet connecté (@03) un module pour comparer (EXAV, CPU) la caractéristique à mettre en oeuvre (Œ1_03, CB103) aux caractéristiques de l’avatar (Œ103...CEN 03) ; un module pour mettre en œuvre (EXAV), en fonction des résultats de la comparaison : l’objet connecté si la caractéristique à mettre en œuvre est une caractéristique de base, et/ou le programme de mise en œuvre d’une caractéristique d’enrichissement si la caractéristique à mettre en œuvre est une caractéristique d’enrichissement.
  7. 7. Passerelle domestique (2) comprenant un dispositif de virtualisation selon la revendication 5 et/ou un dispositif de mise en œuvre selon la revendication 6.
  8. 8. Objet virtualisé (OV3) comportant : un objet connecté (03) disposant d’au moins un identifiant (ID), une caractéristique de base (CB1 _03...CBN_03) et une adresse (@03) ; un avatar (AV_03) dudit objet connecté, comprenant : - une identification (ID) de l’objet connecté ; - une première structure de données (SDB 03) comportant au moins une caractéristique de base (CB1_03,...CBN_Q3) de l’objet connecté ; une seconde structure de données (SDE 03) comportant au moins une caractéristique d’enrichissement (CB1_03,...CBN_G3) de l’objet connecté ; - des instructions de programmes (PE1_03..PEN_03) de mise en œuvre de ladite au moins une caractéristique d’enrichissement ; une structure de gestion d’adresses, dite proxy (PY_03), comportant au moins une correspondance entre au moins une adresse de l’avatar (@AV_0V3) et au moins une adresse de l’objet connecté (@03).
  9. 9. Programme d’ordinateur apte à être mis en œuvre sur un dispositif de virtualisation selon la revendication 5, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de virtualisation défini selon la revendication 1.
  10. 10. Programme d’ordinateur apte à être mis en œuvre sur un dispositif de mise en œuvre selon la revendication 6, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de mise en œuvre d’un objet virtualisé défini selon la revendication 4.
FR1763260A 2017-12-27 2017-12-27 Virtualisation d'un objet connecte Withdrawn FR3076022A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1763260A FR3076022A1 (fr) 2017-12-27 2017-12-27 Virtualisation d'un objet connecte
PCT/FR2018/053224 WO2019129946A1 (fr) 2017-12-27 2018-12-12 Virtualisation d'un objet connecté
US16/958,291 US20210058265A1 (en) 2017-12-27 2018-12-12 Virtualisation of a connected object
EP18833096.3A EP3732859A1 (fr) 2017-12-27 2018-12-12 Virtualisation d'un objet connecté

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1763260A FR3076022A1 (fr) 2017-12-27 2017-12-27 Virtualisation d'un objet connecte

Publications (1)

Publication Number Publication Date
FR3076022A1 true FR3076022A1 (fr) 2019-06-28

Family

ID=61750363

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1763260A Withdrawn FR3076022A1 (fr) 2017-12-27 2017-12-27 Virtualisation d'un objet connecte

Country Status (4)

Country Link
US (1) US20210058265A1 (fr)
EP (1) EP3732859A1 (fr)
FR (1) FR3076022A1 (fr)
WO (1) WO2019129946A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023228507A1 (fr) * 2022-05-23 2023-11-30 パナソニックＩｐマネジメント株式会社 Dispositif de gestion, système, et procédé de commande

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007081941A2 (fr) * 2006-01-11 2007-07-19 Lyle Corporate Development Personnage de jeu électronique et procédé associé
US20100285880A1 (en) * 2009-05-11 2010-11-11 Disney Enterprises, Inc. System and method for interaction in a virtual environment
US20160191673A1 (en) * 2014-12-29 2016-06-30 Facebook, Inc. Application service delivery through an application service avatar

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007081941A2 (fr) * 2006-01-11 2007-07-19 Lyle Corporate Development Personnage de jeu électronique et procédé associé
US20100285880A1 (en) * 2009-05-11 2010-11-11 Disney Enterprises, Inc. System and method for interaction in a virtual environment
US20160191673A1 (en) * 2014-12-29 2016-06-30 Facebook, Inc. Application service delivery through an application service avatar

Also Published As

Publication number Publication date
EP3732859A1 (fr) 2020-11-04
WO2019129946A1 (fr) 2019-07-04
US20210058265A1 (en) 2021-02-25

Similar Documents

Publication Publication Date Title
EP1023796B1 (fr) Dispositif et procede de controle dans un reseau d'appareils domestiques
EP2057632A1 (fr) Procede de gestion d'un programme multimedia, serveur, terminaux, signal et programmes informatiques correspondants
US20090210801A1 (en) N-way multimedia collaboration systems
WO2016107996A1 (fr) Boitier de communication et de gestion d'equipements
EP3241121A1 (fr) Systeme de gestion de donnees d'equipements utilsateurs
FR3022657A1 (fr) Procede de partage de navigation sur une page web affichee par un navigateur web
WO2019129946A1 (fr) Virtualisation d'un objet connecté
EP3241308B1 (fr) Boitier d'interconnexion d'equipements utilisateurs
EP2633440B1 (fr) Indexation et execution d'applications logicielles dans un reseau
FR2778046A1 (fr) Procede de gestion d'objets dans un reseau de communication et dispositif de mise en oeuvre
EP2748976A1 (fr) Système de gestion de périphériques domestiques
EP3241316B1 (fr) Methode de communication entre un gestionnaire d'action distant et un boitier de communication
WO2019229328A2 (fr) Agrégation d'objets connectés
FR2887717A1 (fr) Procede de creation d'un terminal eclate entre un terminal de base et des equipements connectes en serie
EP3560147B1 (fr) Automatisation des échanges entre objets communicants
WO2018100269A1 (fr) Dispositif et procédé de stockage et partage de données d'objets connectés à un réseau internet, et procédé de restitution de données provenant d'objets connectés
EP3596688A1 (fr) Procédé d'enrichissement d'un contenu numérique par données spontanées
FR2964523A1 (fr) Mise a disposition d'informations par un terminal mobile dans un reseau.
JP6590215B2 (ja) 情報通信装置、情報通信システム、情報取得方法及び制御プログラム
FR2999854A1 (fr) Procede et systeme pour visionner en direct l'ambiance dans des lieux de divertissement.
FR3017505A1 (fr) Procedes de controle et de proposition de controle d'un equipement connecte a un reseau de communication, equipements, systeme, produits programmes d'ordinateur et supports de donnees correspondants
FR2975554A1 (fr) Procede d'adaptation d'un contenu en fonction du recepteur du contenu
EP1853040A1 (fr) Système de communication et terminaux de visualisation à basse consommation convenant à un tel système
EP3110109A1 (fr) Procédé et dispositif de mise à jour des capacités d'un objet connecté à un réseau de communications
FR3026516A1 (fr) Dispositif et procede de transfert bidirectionnel de donnees entre un terminal de communication et un module compatible isobus

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20190628

ST Notification of lapse

Effective date: 20200906