EP3732859A1 - Virtualisation d'un objet connecté - Google Patents

Virtualisation d'un objet connecté

Info

Publication number
EP3732859A1
EP3732859A1 EP18833096.3A EP18833096A EP3732859A1 EP 3732859 A1 EP3732859 A1 EP 3732859A1 EP 18833096 A EP18833096 A EP 18833096A EP 3732859 A1 EP3732859 A1 EP 3732859A1
Authority
EP
European Patent Office
Prior art keywords
characteristic
avatar
connected object
enrichment
virtualized
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
EP18833096.3A
Other languages
German (de)
English (en)
Inventor
Stéphane 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
Publication of EP3732859A1 publication Critical patent/EP3732859A1/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

Definitions

  • the invention relates to the general field of telecommunication networks and more particularly to the Internet of Things.
  • Connected objects are, for example, household objects such as light bulbs, lamps, radiators, audio, video, electricity meters, vehicles, watering systems, etc. Connected objects interact with each other via several categories of networks, whether wired or wireless.
  • a bus stop which is not a traditional connected object, may however be of interest to a user, wishing to access, for example, features such as transit times, alerts, etc.
  • multimedia content can be seen as a connected object.
  • the invention offers a solution that does not have the drawbacks of the state of the art.
  • the subject of the invention is a method of virtualization of an object connected to a communications network, said connected object having at least one characteristic, called a basic characteristic, said method being characterized in what it involves the following steps on a virtualization device, to obtain an avatar able to represent the connected object:
  • an address management structure comprising at least one correspondence between at least one address of the avatar and at least one address of the connected object.
  • connected object is meant here any physical or logical entity capable of rendering a service to a user in a communications network, for example:
  • flows associated with the input or output functions of the object commands, responses, messages, data streams, for example audiovisual, etc.
  • flow in the broad sense.
  • a message command, request, response, acknowledgment, etc.
  • a data flow limited in time.
  • virtualization is meant the creation of a virtualized object associated with a connected object and having an address to access the connected object.
  • the virtual object after its creation, offers, or exposes, the characteristics of the connected object and selected enhancement characteristics according to embodiments which will be described later.
  • virtualized object is meant an object that includes the connected object and its encapsulation according to the present invention, that is to say an avatar of the object.
  • avatar is meant a representation, or enriched encapsulation of the object; the avatar therefore includes: • one or more characteristics of the object, basic or enriched, and in the latter case a set of functions, or implementation program instructions, associated;
  • address of the connected object is meant any type of address corresponding to the access of all or part of the characteristics of the connected object.
  • Such an address can be physical (http://192.145.1.1) or symbolic (zoom.ov3@mypasserelle.fr to access the zoom function of the camera object via the home gateway). It can take the form of a universal address (URI, URL), an IP address, etc.
  • the accessible functions or the generated flows of a connected object can be encapsulated in a virtualized object so that the connected object is hidden behind the virtualized object.
  • a user of the connected object does not access it directly but via his avatar.
  • the user invokes the avatar to access the connected object.
  • This encapsulation of the data makes it possible in particular to protect the object and to make it independent.
  • the connected (physical) object can be paused and woken by its avatar when a request is made to the virtualized object.
  • the virtualized object that is, the entity formed by the connected object and its avatar, can implement the characteristics of the connected object and the selected enhancement characteristics according to embodiments that will be described later.
  • the basic characteristics of the object can be supplemented by other characteristics managed not by the connected object itself but by the virtualized object that corresponds to it.
  • a webcam physical object
  • To the physical object of departure (connected camera) having basic functions (image capture, videos, zoom, rotations, etc.) and associated flows (image capture, zoom control, output flow audiovisual, etc.) so new functions (for example a clock function) associated with new streams (for example, the timestamp command and the timestamped output stream) are added.
  • new functions for example a clock function
  • new features functions and flows
  • the virtual object When the virtual object is used, its basic characteristics (capturing an image) and / or its enhancement characteristics (time stamping the image) can be used.
  • a basic characteristic is the connected object itself which is implemented by the avatar (for example to capture the image), in other words the commands, messages etc. they are relayed by the avatar (via his proxy) and the responses received by the avatar before retransmission. If on the other hand it is an enrichment characteristic which is invoked, it is the program of implementation of this characteristic of the avatar of the object which is used (since the connected object does not know this characteristic, it is impossible for him to implement it).
  • the invention makes it possible to enrich an object with characteristics that are not part of it according to its initial specifications. Particularly in the case of a physical object, the invention allows to complete it with useful functions that have not been provided by the manufacturer.
  • a method as described above is further characterized in that the enrichment step comprises the substeps of:
  • Validation means the actual endowment of the enriched feature to the virtualized object.
  • the enriched feature is then accessible through the virtualized object. Indeed, it could be previously registered in the avatar without being authorized for the implementation.
  • the validation authorizes it.
  • the user can request an enrichment of his connected object. For this, it establishes a request to the virtualization device. For example, he may ask to enrich his camera with a clock.
  • the terms of the request can take any form within the reach of the skilled person. For example one can imagine that the user has on his smartphone, or on his PC, a representation of the virtualized object "camera", in which it comes to slide a clock icon. In this case, if the avatar has a "clock" feature, this feature is validated in the avatar and becomes available as an enrichment feature of the virtualized object, as well as basic features.
  • a method as described above is further characterized in that the enrichment step includes a validation of the set of enrichment features available in the second data structure of the avatar.
  • the enrichment is done automatically. All the enrichment features that were obtained and entered into the avatar structure are automatically added to the virtualized object. For example if the avatar has a characteristic "clock” and a characteristic "temperature”, these characteristics are activated in the avatar and become available as features of enrichment of the virtualized object, in the same way as basic features.
  • the invention also relates to a method for implementing a virtualized object of an object connected in a communications network, said virtualized object comprising an avatar of the connected object, the method being characterized in what it comprises the following steps on a device for implementing the virtualized object:
  • said avatar comprising at least:
  • a first data structure comprising at least one basic characteristic of the connected object
  • said proxy comprising a correspondence at least between at least one address of the avatar and at least one address of the connected object;
  • the characteristic to be implemented is a basic characteristic, and / or
  • the virtualized object encapsulates and enriches the connected object so that it can access not only the characteristics (functions and flows) of the connected object but also the enriched functions of the virtual object thanks to its avatar.
  • the message to use / implement the virtualized object can come from the connected object itself (for example if it raises the temperature every hour, or if an event triggered the object - case of an opening gate) or any device on the network (user's terminal, server in the network, etc.), or the virtualized object (which for example monitors the alerts of the connected object).
  • the characteristic required can correspond to a function rendered:
  • time stamp that is, transmission of the time in the stream
  • the invention also relates to a device for virtualization of a connected object of a communications network, said object having at least one characteristic, called basic characteristic, the virtualization device comprising:
  • a module for generating a first data structure comprising said at least one basic characteristic of the connected object
  • a module for generating a second data structure comprising said at least one enrichment characteristic for the connected object
  • a module for obtaining program instructions for implementing said at least one enrichment characteristic an address management module, for generating a data structure, called a proxy, comprising at least one correspondence between at least one address of the avatar and at least one address of the connected object;
  • module used in the present description can correspond as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms. or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .)
  • the invention also relates to a device for implementing a virtualized object of an object connected in a communications network, the implementation device comprising:
  • a module for obtaining a message for using the virtualized object said message comprising at least one characteristic to be implemented
  • proxy a module for obtaining an address management structure, called proxy, comprising a correspondence at least between at least one address of the avatar and at least one address of the connected object;
  • the connected object if the characteristic to be implemented is a basic characteristic, and / or the program for implementing an enrichment characteristic if the characteristic to be implemented is an enrichment characteristic.
  • the invention also relates to a home gateway comprising a virtualization device and / or an implementation device as described above.
  • the invention also relates to a virtualized object comprising:
  • a connected object having at least one identifier, a basic feature and an address
  • an avatar of said connected object comprising:
  • a first data structure comprising at least one basic characteristic of the connected object
  • a second data structure comprising at least one enrichment characteristic of the connected object
  • an address management structure comprising at least one correspondence between at least one address of the avatar and at least one address of the connected object.
  • the invention also relates to a computer program adapted to be implemented on a virtualization device as described above, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the virtualization method defined above.
  • the invention further relates to a computer program adapted to be implemented on a communication device as described above, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the communication method defined above.
  • the invention relates to a recording medium readable by a data processor on which is recorded a program comprising program code instructions for executing the steps of any one of the methods. defined above.
  • the objects according to the material aspects of the invention provide at least the same advantages as those provided by the method according to the first functional aspect.
  • the optional features mentioned for the first aspect can be applied to the material aspects.
  • FIG. 1 represents the general context of the invention, showing connected and virtual objects of a user of a local network according to the state of the art.
  • Figure 2 illustrates a virtualized object according to one embodiment of the invention.
  • Figure 3 illustrates an object avatar according to one embodiment of the invention.
  • FIG. 4 represents an architecture of a device for virtualization of objects and / or implementation of virtualized objects according to one embodiment of the invention.
  • FIG. 5 represents a chronogram of virtualization of an object and of subsequent implementation of the virtualized object according to one embodiment of the invention.
  • FIG. 1 represents the general context of the invention according to the state of the art, showing connected and virtual objects of a user of a Local Area Network (LAN) 1.
  • the LAN is a home network connected to a Wide Area Network (WAN), 3 for example an Internet network.
  • WAN Wide Area Network
  • a LAN could be a corporate network or be limited to a single object connected to the Internet (eg a Beach Webcam) and WAN 3 could be of any type (cellular, GSM - Global System for Mobile Communications, UMTS - Universal Mobile Telecommunications System, Wifi - Wireless, etc.) without departing from the scope of the invention.
  • a network management element (2) (a residential, professional gateway, a hub, etc.) and terminal equipments, hereafter referred to as connected objects or simply objects (Oi), are connected to the local network 1. It is acts respectively according to the example of a connected headset (01), a smartphone (02), a connected camera (03), a temperature sensor (04). These objects are able to communicate on the local network and can be accessed from inside or outside the local network via the service gateway
  • a bus stop (07) has been represented by way of example, which is associated with traffic information, timetables, etc. and a rain gauge (06) and a shared bicycle (08)
  • - private objects on the public network associated with location information, status, etc.
  • a user's social network account (09) is shown.
  • These objects may differ by their operating system (Windows, Linux, Android, etc.), their type of network connection (Ethernet, Wifi, Bluetooth, etc.), and the functions / actions they are capable of: measuring the temperature, communicate on social networks, implement a cooking recipe, play multimedia content, record a surveillance video, transmit it, detect a movement, light a lamp, etc.
  • a virtual object is not materialized by a physical device. It is only a representation simulated by a digital entity. This is for example a time stamp function, location, etc.
  • the left column indicates the nature of the object (physical, virtual or physical / virtual) and the top line its type (personal or public).
  • each of the objects has a certain number of characteristics (functions and / or input / output flows) but could be usefully enriched with characteristics that it does not possess natively. According to some examples:
  • the camera does not have hourly information; now it may be useful to time-stamp his data;
  • the bicycle does not have a kilometer counter; it may be useful to know the number of kilometers traveled;
  • the bus stop does not have traffic information; however, it may be useful to know the next hour of passage, whether the bus is on time, whether it is charged or not, etc.
  • This information (traffic, timetables) is available from the operator's information system; it may be interesting to consider the physical bus stop (object not connected) as a virtualized bus stop to which the traffic and time functions have been added.
  • FIG. 2 An embodiment of the invention will now be described in support of FIG. 2, the purpose of which is to offer the user a virtualized object, possibly enriched, corresponding to a connected object.
  • the connected object is a physical object (a camera) but it could be virtual (a clock) without loss of generality.
  • the camera object of the user's local network (03) will be enriched with a "function" which he does not have natively: a timestamp function (FH) from the wide area network; the streams of the camera can be time stamped and the time can be transmitted in response to a request to the virtualized object.
  • the camera is equipped, via a hardware or software overlay, with an additional feature (function and flow).
  • the resulting object is a virtualized object, that is to say a particular object corresponding to a connected object, able at least to render its functions and process information flows to or from the connected object (physical or virtual ).
  • the virtualized object corresponding to a connected object is represented as an entity rendering functions and having input and output flows. All the flows of the connected object go through a proxy-like software package, the object avatar, built on the flows coming from or in the direction of the object. This object avatar represents the object on the network. It should be noted that the connected object, if it has the necessary resources, hardware and software, can be autonomous provided that it supports the functions of the object avatar.
  • the avatar is therefore a "standardized” interface with capabilities that can also be standardized (timestamp). It is a kind of overlay of the object (encapsulation).
  • the owner of the object installs it initially on his home gateway.
  • a virtualization device on the gateway built for the object an avatar.
  • the avatar is accessible via a new address that serves to access the object.
  • This avatar can also be typically implemented in the network of the operator if the home gateway is virtualized, or in the network (cloud) provided to implement a secure connection between the avatar that is in the network. network and the object.
  • some objects could directly integrate the avatar (connected objects) or implement it (in a case of computer representation of a physical object).
  • the created avatar acts as a proxy between the connected object and the requests made to it.
  • a proxy is a software component that acts as an intermediary between two entities to facilitate exchanges.
  • the proxy (PY) of the avatar is placed between the user of the object, for example a website on a smartphone, and the object connected to the LAN / WAN.
  • the proxy redirects flows transparently to the user, to and from the connected object.
  • the avatar can have its own proxy, or alternatively, be attached to a proxy that groups together a set of avatars.
  • the type of the object can be identified and for example thanks to a base of referencing, or thanks to the avatar which includes itself the information, one can recover the information concerning the interfaces (flow , functions) of the object and so show them, or expose, for example in a graphical interface associated with the virtual object.
  • the avatar associated with the camera has zoom, scan, encoding format, still image capture, and so on. and in addition, according to the example proposed above, timestamp functions.
  • the goal is to be able to adapt to the needs of the user all connected objects regardless of their own characteristics, through an enrichment mechanism.
  • Figure 3 shows in more detail a possible architecture for an object avatar according to an embodiment of the invention.
  • it is the connected object 03 (the camera) which is considered to lead to a virtualized object (OV3).
  • the avatar (AV_03) contains:
  • ID_03 an identification of the connected object
  • a first data structure comprising at least one basic characteristic (CB1_03, ... CBN_03) of the connected object (zoom, image capture, video stream, capture command, etc.);
  • SDE_03 a second data structure comprising at least one enrichment characteristic (CE1_03, ... CEN_03) of the connected object
  • proxy PY_03
  • PY_03 an address management structure, called proxy (PY_03) comprising a correspondence between at least one address of the avatar (@ AV_OV3) and at least one address of the connected object (@ 03). It is recalled that the address can be of any type and address all or part of the characteristics of the connected object. otherwise
  • the object has its own proxy; schematically in this case the object will be accessible via an address of type / my_camera - Or it is attached to a proxy that includes a set of avatars; schematically in this case the object will be accessible via an address of proxy_ objects / my_camera (and another object, for example a thermometer connected, will be accessible via proxy_ objects / my_ thermometer).
  • FIG. 4 represents an architecture of a device for virtualization of objects and / or implementation of virtualized objects according to one embodiment of the invention.
  • the virtualization device includes:
  • the memories can be type ROM (English Read On / y Memor ⁇ ) or RAM (English Random Access Memor ⁇ ). They can take the form of a removable card (SD, flash, etc.). Part of the memory M may contain in particular, according to the invention, the avatars corresponding to the virtualized objects.
  • a communication module for communication with the connected objects, with the user, and with different entities of the local network and or / extended;
  • this module can be of type WiFI, Bluetooth, ETHERNET etc. and use any appropriate protocol to interact with these entities (http, RTP, ...);
  • GETB Basic Characteristic Obtaining Module
  • a module for obtaining enriched characteristics (TEAP), making it possible to obtain a set of enriched characteristics that can be associated with connected objects (for example, time stamp, temperature, traffic, etc.); according to the example of FIG. 3, these data are read in a base (BD_CE) of characteristics; this database can be located on the virtualization device or not (it can be in the cloud, on any equipment of the local or wide area network, etc.);
  • a module for generating avatars in charge of virtualizing the objects that are provided to it, that is to say to generate an avatar for a connected object, by enriching it with functions are it does not have 'origin.
  • a proxies management module which makes it possible to associate a proxy structure (PY_Oi) with one or more object avatars and subsequently to manage the flows to and from the object.
  • an avatars implementation module (EXAV) that allows, once the virtualized object, that is to say its created avatar, to access the virtualized object (access to the basic characteristics corresponding to the characteristics of the virtualized object) the connected object and / or access to the enrichment features offered by the avatar). Note that for reasons of simplification, the EXAV module has been placed on the virtualization device. However it could be part of an avatar implementation device separate from the virtualization device.
  • a base of avatars (BD_AV); this database can be located on the virtualization device or outside. It contains the avatars of virtualized objects.
  • a user interface module (MIU), to make available, or expose, to the user, an access address (@ AV_03) to said avatar (AV_03) and the characteristics of the avatar of the object (for example in the form of a graphic object that can be transmitted to the user, as shown in Figure 4 below: representation of the object in the form of pictograms and associated functions).
  • MIU user interface module
  • Figure 5 shows a timeline of virtualization of a connected object and subsequent implementation of the virtualized object.
  • an object avatar on the object virtualization device located according to this example on a home gateway, and the subsequent use of this object by its owner. It includes the main phases of virtualization (declaration of the connected object, creation and enrichment of the avatar), exposure of the virtualized object (provision of the user) and implementation of the object virtualized according to examples.
  • the virtualization (DV) and virtualized object implementation (DMO) devices are merged and are on the service gateway. Any other location of one and / or the other of these two devices could be considered: in the local network, in the wide area network, carried by a server, a terminal, a connected object, etc.
  • the goal of this phase is to create a virtualized object (0V3) representing a connected object (03).
  • V3 representing a connected object (03).
  • the virtualized object is the connected object and its avatar.
  • the user declares a connected object.
  • it is a connected camera (03) of the local network.
  • the object connected to virtualize is therefore physical but it could be virtual without loss of generality (for example, the bus stop presented above in support of FIG. 1 is represented by a computer system). Any other object could be considered without loss of generality, as described in support of Figure 1.
  • the connected object declares itself to the service gateway (name of the camera, model, etc.);
  • the virtualization device receives the declaration of the object and prepares a virtualized object, or avatar, having the characteristics of the object (physical or virtual) that has just been declared.
  • the gateway module DEC can according to the case:
  • an object referencing site to receive its function and flow characteristics (for example, the manufacturer's site for a camera);
  • the virtualization device virtualizes the object, that is to say creates for this object a data structure and a set of associated software (or hardware) characteristics, called avatar (AV ).
  • avatar is a software overlay of the object that possesses / presents the functions and flows of the object. It is recalled that it comprises a structure carrying the basic characteristics of the connected object and a structure bearing the possible enrichment characteristics of the object with the associated implementation programs. Moreover, it is associated with a proxy making it possible to link the addresses of the virtualized object with the addresses of the connected object.
  • the enrichment characteristics are extracted from a base of enrichment characteristics (BD_CE).
  • all the enrichment features inserted in the avatar in the previous step are automatically validated in the virtual object, that is to say that these characteristics of the virtual object can be implemented.
  • all the enrichment features inserted in the avatar in the previous step are proposed but are not validated automatically.
  • the user requests an effective enrichment of the object with an enrichment characteristic.
  • it asks to enrich the camera with a clock function (CE).
  • CE clock function
  • it can for example enter in a graphical interface a pictogram of the connected object, a pictogram of a clock object, and bring the two pictograms closer together.
  • Any other method can be envisaged to result in the transmission of a message bearing an identifier of the object (identifier ID_03 of the connected object, or its address, or the address of the avatar being created if this address has been passed to the user, etc.) and at least one enrichment feature.
  • the two embodiments may be combined if only part of the enrichment features is automatically validated.
  • the virtualization device receives this request in step E22 and processes it in step E23. It checks that the avatar has the required enrichment feature, then it validates this characteristic in the avatar if it is the case. Finally, it memorizes the avatar in the database of avatars.
  • the avatar is also provided with a representation of the virtualized object.
  • This representation can be of any type (graphic, text, sound, etc.). It is accessible for example on the smartphone of the user, who can receive this representation and "sees" then the virtualized object in the form of an HMI; for example, the representation associated with the camera object can show / expose with the representation of the camera:
  • the virtualized object therefore has an avatar comprising at least the basic characteristics of the connected object, a proxy to access it transparently via the address of the avatar, and possibly a representation. graphic.
  • the user (on his smartphone) and the proxy can exchange a secret during the steps E14 and E24, in order to subsequently communicate securely.
  • the virtualization device provides the owner of the connected object with the address of the virtualized object, that is to say the avatar address (@ AV_03) contained in the proxy of the avatar. With this address, the user can access the virtualized object; in addition, during this step, the virtualization device can also provide a representation (HMI) of the object via its user interface module (MUI).
  • HMI user interface module
  • CB1 image capture, see for example table 2
  • IEC timestamp
  • the implementation device of the virtualized object on the gateway receives this message during a step E26 and the analysis. For this purpose, it queries the database of avatars to obtain the avatar (AV3) of the object.
  • IEC timestamp
  • step E29 retransmit the timestamped stream to the terminal of the user.
  • the implementation can be triggered by the connected object itself, for example if it is a motion sensor, it can trigger an implementation of the virtual object "camera" OV3 when it detects a movement.
  • the detection signal is received by the virtualized object, possibly enriched before being for example transmitted to a remote server.
  • the implementation can be triggered by the virtualized object itself; the avatar of the virtualized object monitors the connected object. It transmits to it lots of a step similar to step E27 an image capture command; it recovers the capture, possibly enriches it (by timestamp %) and transmits it to a remote server. etc.

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_03,… CEN_O3); - des instructions de programmes (PE1_O3 … PEN_O3) de mise en œuvre de la caractéristique d'enrichissement (CE1_03,… CEN_O3); - une structure de gestion d'adresses, dite proxy (PY_O3) 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.
Etat de la technique
Depuis maintenant quelques années, l'Internet des Objets - ou IoT 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.
Ces 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 œ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é.
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 œuvre, 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. Si 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 œuvre 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 œuvre 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 œuvre 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 œuvre d'une caractéristique d'enrichissement si la caractéristique à mettre en œuvre 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 œuvre 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 phvsiaue/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é (OV3). L'avatar (AV_03) comporte :
une identification (ID_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 (CE1_03,... CEN_03) 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... CEN_03) ; 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_OV3) 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 œuvre 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 ROM (de l'anglais Read On/y Memorÿ) ou RAM (de l'anglais Random Access Memorÿ). Elles 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 (COMM), 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 (PY_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 (MIU), pour rendre disponible, ou exposer, à l'utilisateur, une adresse d'accès (@AV_03) 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 (CRAV) 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 œuvre 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 (BD_CE).
Selon un mode de mise en œuvre, 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 œuyre 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_03 qui lui a été communiquée précédemment) en demandant une caractéristique de base (CB1) et une caractéristique d'enrichissement (CEI) 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 (CEI = horodatage).
Le dispositif de mise en œuvre 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 (CEI = 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.
Il 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 » OV3 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

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 (CB1_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 (CE1_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,... CBN_03) de l'objet connecté ;
une seconde structure de données (SDE_03) comportant ladite au moins une caractéristique d'enrichissement (CE1_03,... CEN_03) ;
- des instructions de programmes (PE1_03 ... PEN_03) de mise en œuvre de ladite au moins une caractéristique d'enrichissement (CE1_03,... CEN_03) ; une structure de gestion d'adresses, dite proxy (PY_03) comportant une correspondance au moins entre au moins une adresse de l'avatar (@AV_OV3) et au moins une adresse de l'objet connecté (@03).
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 (CE) ;
comparaison de la caractéristique d'enrichissement requise (CE) aux caractéristiques d'enrichissement de l'avatar (CE1_03...CEN_03) ;
en fonction des résultats de la comparaison, validation dans l'avatar de ladite caractéristique d'enrichissement (CE1_03).
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. Procédé de mise en œuvre d'un objet virtualisé (OV3) d'un objet connecté (03) dans un réseau de communications (1,3), ledit objet virtualisé (OV3) 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é (DMO):
- obtention d'un message (E26) pour utiliser l'objet virtualisé, ledit message comportant au moins une caractéristique à mettre en œuvre (CEI, 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_03) de l'objet connecté ;
une seconde structure de données (SDE_03) comportant au moins une caractéristique d'enrichissement (CE1_03,... CEN_03) ;
- des instructions de programmes (PE1_03 ... PEN_03) de mise en œuvre de ladite au moins une caractéristique d'enrichissement (CE1_03,... CEN_03) ; une structure de gestion d'adresses, dite proxy (PY_03) comportant une correspondance au moins entre au moins une adresse de l'avatar (@AV_OV3) et au moins une adresse de l'objet connecté (@03)
comparaison (E26) de la caractéristique à mettre en œuvre (CE1_03, CB1_03) aux caractéristiques de l'avatar (CE1_03...CEN_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. 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 (CB1_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_03...CBN_03) 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 (SDB_03) 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 (CE1_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 (CE1_03) 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,... CEN_03) ; 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_OV3) et au moins une adresse de l'objet connecté (@03) ;
6. Dispositif de mise en œuvre (DMO) d'un objet virtualisé (OV3) d'un objet connecté (03) dans un réseau de communications (1,3), le dispositif de mise en œuvre comportant :
un module pour obtenir (COMM) un message (E26) pour utiliser l'objet virtualisé, ledit message comportant au moins une caractéristique à mettre en œuvre (CEI, 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_03) 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 (CE1_03,... CEN_03) ; un module pour obtenir (EXAV) des instructions de programmes (PE1_03 ... PEN_03) de mise en œuvre de ladite au moins une caractéristique d'enrichissement (CE1_03,... CEN_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_OV3) et au moins une adresse de l'objet connecté (@03) un module pour comparer (EXAV, CPU) la caractéristique à mettre en œuvre (CE1_03, CB1_03) aux caractéristiques de l'avatar (CE1_03...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. 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. 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_03) de l'objet connecté ;
une seconde structure de données (SDE_03) comportant au moins une caractéristique d'enrichissement (CB1_03,... CBN_03) 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_OV3) et au moins une adresse de l'objet connecté (@03).
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. 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.
EP18833096.3A 2017-12-27 2018-12-12 Virtualisation d'un objet connecté Withdrawn EP3732859A1 (fr)

Applications Claiming Priority (2)

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é

Publications (1)

Publication Number Publication Date
EP3732859A1 true EP3732859A1 (fr) 2020-11-04

Family

ID=61750363

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18833096.3A Withdrawn EP3732859A1 (fr) 2017-12-27 2018-12-12 Virtualisation d'un objet connecté

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

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8047915B2 (en) * 2006-01-11 2011-11-01 Lyle Corporate Development, Inc. Character for computer game and method
US8721443B2 (en) * 2009-05-11 2014-05-13 Disney Enterprises, Inc. System and method for interaction in a virtual environment
US10205797B2 (en) * 2014-12-29 2019-02-12 Facebook, Inc. Application service delivery through an application service avatar

Also Published As

Publication number Publication date
FR3076022A1 (fr) 2019-06-28
US20210058265A1 (en) 2021-02-25
WO2019129946A1 (fr) 2019-07-04

Similar Documents

Publication Publication Date Title
EP1023796B1 (fr) Dispositif et procede de controle dans un reseau d'appareils domestiques
EP3241118A1 (fr) Boitier de communication et de gestion d'equipements
JP2007515030A (ja) メディアコンテンツの取得を可能とする識別データを保持する記憶システム
EP3241121A1 (fr) Systeme de gestion de donnees d'equipements utilsateurs
EP3054629A1 (fr) Procédé de contrôle d'un équipement multimédia à partir d'un terminal mobile, programmes d'ordinateur, équipement multimédia et serveur correspondants
EP3732859A1 (fr) Virtualisation d'un objet connecté
EP2633440B1 (fr) Indexation et execution d'applications logicielles dans un reseau
US20250023741A1 (en) Authenticating video data utilizing a contextual identifier
WO2016108001A1 (fr) Boitier d'interconnexion d'equipements utilsateurs
FR2778046A1 (fr) Procede de gestion d'objets dans un reseau de communication et dispositif de mise en oeuvre
EP3241316B1 (fr) Methode de communication entre un gestionnaire d'action distant et un boitier de communication
EP2575327B1 (fr) Procédé de partage d'une application web entre plusieurs terminaux informatiques reliés à un réseau de communication
EP3803568B1 (fr) Agrégation d'objets connectés
WO2013030163A1 (fr) Système de gestion de périphériques domestiques
FR2964523A1 (fr) Mise a disposition d'informations par un terminal mobile dans un reseau.
Kim An efficient implementation of key frame extraction and sharing in Android for wireless video sensor network.
EP3560147B1 (fr) Automatisation des échanges entre objets communicants
EP3549322A1 (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
FR2999854A1 (fr) Procede et systeme pour visionner en direct l'ambiance dans des lieux de divertissement.
FR2887717A1 (fr) Procede de creation d'un terminal eclate entre un terminal de base et des equipements connectes en serie
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
EP3624417A1 (fr) Communication sécurisée entre un module cam et un terminal mobile disposant d'une connexion au réseau internet
FR3003714A1 (fr) Mecanisme de deploiement d'un service dans un reseau domestique
FR2969886A1 (fr) Procede d'execution d'une action par un terminal de communication, terminal, serveur, systeme de communication et programme d'ordinateur correspondants

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200716

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20210923