Emulation of physical equipment

Technical area

0001The invention applies to any terminal equipped with a communication interface for an extension peripheral (storage, printing, viewing peripheral, etc.).

0002The invention applies most particularly to a system comprising an emulation device local to a user, enabling him to access terminals whose communication interfaces are difficult to access.

State of the art

0003Generally, the use of a terminal equipped with a communication interface is achieved by directly connecting, wired or wireless, the peripheral equipment (for example a storage, printing, viewing, recording, etc.) on the physical interface of the terminal, for example by means of a wired connection of the USB type (from the English <i>Universal Serial Bus</i>) or a wireless connection such as WIFI, etc.

0004But some terminals are sometimes too far away spatially from the user (they are in another room of the house, in a closet, in an attic, etc.)

0005In addition, some terminals, although potentially close to the user, have interfaces that are difficult to access (because they are physically located behind the terminal, below, above, etc.)

0006To remedy this problem, the protocols well known to those skilled in the art under the name “USB over IP” make it possible to encapsulate USB signals in TCP/IP frames and to transmit them to another equipment in an Internet network. (PI).

0007However, the use of such a protocol only makes it possible to deport interfaces of the USB type, and supposes a manual association between the terminal and the physical interface.

0008The document<patcit id="pcit0001" dnum="US8028040B1"><text>US 8028040 B1</text></patcit> provides a method and system for establishing connections between a virtualized host computer system and device interfaces associated with remote terminals. However, if the terminals have several physical interfaces of different types, such a system does not allow access simply to one of the interfaces of the terminal.

0009Today, there is no simple solution for automatically accessing, remotely, the interfaces of such terminals.

0010The invention offers a solution that does not have the disadvantages of the state of the art.

The invention

0011To this end, according to a functional aspect, the subject of the invention is a method for emulating a physical interface of a device capable of communicating in a network, said interface being capable of receiving at least one peripheral device.

0012An embodiment is detailed in support of independent claim 1 and its dependents. Other embodiments are provided by way of example.

0013The emulation process offers the advantage of ensuring two-way communication by exchanging messages between the peripheral equipment and the terminal, even when the peripheral equipment is not connected directly to the terminal but to another equipment on the network. . Everything happens in this case as if the physical interface of the emulation device were on the terminal. By “physical interface”, we mean here the hardware part of the interface (for example a connector) and the set of software modules which make it possible to manage it (also called pilots, or “drivers”). It is possible, in this way, to associate each of the physical interfaces of the emulation device with one or more terminals of the network. For example, the emulation device, which is close to the user, can comprise a USB interface and an SD interface to which a USB key and a digital camera card are respectively connected. The USB key can be associated with the personal computer (PC) of the user, which is in his room. The camera's (SD) card can be associated with the television, which has no such physical interface, and the user's tablet. The user can thus, without moving, view his photographs on his television and on his tablet, and transfer files from his PC as if the USB key were directly connected to him.

0014In this way, read and write accesses to the peripheral can be done remotely: the method according to the invention manages the communication transparently for the user and the terminal by directing (or "routing" in computer language) the given appropriately.

0015Pre-association allows equipment to be associated with one or more terminals temporarily. Indeed, it may be desirable for a peripheral, for example storage, to be sometimes associated with one terminal, sometimes with another, or even shared between several terminals. Such a prior matching step followed by an effective selection of the terminal equipment, for example via an interface offered to the user of the terminal, allows such an association over time. The pre-association step makes it possible to produce a list of possible associations between the terminals, their potential virtual interfaces and the physical interfaces available on the emulation device. Indeed, some associations having no physical meaning (for example, associating a gamepad with a near field communication (NFC) interface presents an unrealistic combination), it is a question, as soon as you become aware of the different network terminals, to provide the right associations. Thus, when the user connects one of his peripheral equipment (for example the gamepad) he will obtain the list of terminals that can potentially be associated with it, in this case the living room digital decoder whose services are perfectly appropriate using a gamepad.

0016Subsequently, an effective selection step makes it possible to choose one of the pre-associations. Everything then happens as if the peripheral were directly connected to the associated terminal (or terminals), for example the USB key can be associated with the user's PC, then with his tablet, then simultaneously with the PC and with the tablet.

0017Each of the terminals can declare its capabilities to the emulation device, for example when the terminal connects to the local network. The terminal can in particular, during this preliminary step, declare its physical interfaces (type, number, capacities, etc.), the services it offers (eg video games with joystick) as well as his possible wish to benefit from other interfaces which he does not have natively: for example a television which does not have an SD type interface may nevertheless have needs for such a virtual interface.

0018The definition of priorities can also make it possible to offer a quality of service to the user, by arbitrating the potential conflicts between the various terminals. For example, the priority which can be assigned to some of them can make it possible to resolve conflicts in the case where a USB interface is shared between two peripherals, access being given to the one which has the highest priority. Such a mechanism can also make it possible to advantageously share the distribution of the bandwidth between several terminals and several physical ports of the device.

0019It is possible not to require the user to explicitly select an association, in particular in the case where a terminal device is the only one of a given type: for example if there is only one PC connected to the network, it seems legitimate to automatically associate the USB key with it. This possibility is also useful to allow the user to define a default behavior for a given peripheral (for example the automatic association of a joystick to the digital set-top box, which is the equipment most likely to support such association).

0020The invention also relates to a method for managing a software interface on a terminal able to communicate in a network to manage a virtual software interface which connects it to a physical interface in the network. Subsequently, when the software interface is activated, that is to say when it has actually been associated with a physical interface, everything happens as if the terminal was actually dialoguing with this physical interface locally, the interface software taking on the role of this physical interface transparently for the terminal.

0021According to hardware aspects, the invention also relates to an emulation device, a terminal, a service gateway, a communication system and a computer program.

0022The invention will be better understood on reading the following description, given by way of example and made with reference to the appended drawings.

The figures:

0023<ul id="ul0001" list-style="none"><li>The<figref idref="f0001">figure 1</figref> represents a local network according to the state of the art.</li><li>The<figref idref="f0001">picture 2</figref> presents the general application of an embodiment of the invention in a local area network.</li><li>The<figref idref="f0002">picture 3</figref> represents a hardware architecture of a device according to the invention connected to a terminal of the local network.</li><li>The<figref idref="f0003">figure 4</figref> represents an embodiment of the invention.</li><li>The<figref idref="f0004">figure 5</figref> represents another embodiment of the invention.</li><li>The<figref idref="f0005">figure 6</figref> represents a timing diagram of the exchanges between a device and a terminal according to one embodiment of the invention.</li></ul>

Detailed description of an exemplary embodiment illustrating the invention

0024The<figref idref="f0001">figure 1</figref> represents a local network according to the state of the art.

0025The context of the local home network is given by way of example and could easily be transposed to that of a company network or any Internet network.

0026Conventionally, the local network comprises a service gateway (T3, BOX), in this example a home gateway which in particular ensures the routing of data in the local network, as well as between the broadband network (not shown) and the network local.

0027The local area network comprises three other terminals: a personal computer (T2, PC), a television set (T4, TV) and a digital television decoder (T5, STB).

0028Subsequently, terminal equipment, or more simply terminal, means any device capable of being connected to the home network (printer, scanning device, digital tablet, <i>smart phone,</i> hard drive, etc.) Classically, according to our example, the TV is in the living room, the home gateway in the office and the laptop in the user's bedroom.

0029In such a context, the user who wishes to recover a file on his USB key must go up to the room to connect the key to the USB port of his PC; he cannot connect his digital camera to the television which does not have appropriate connectors (no SD card reader); he must necessarily connect his joystick to the STB which may be difficult to access; he cannot share his USB key between two terminals (tablet and PC, for example).

0030The<figref idref="f0001">picture 2</figref> presents the general application of an embodiment of the invention in a local network, which solves all the problems mentioned above.

0031The general context of the <figref idref="f0001">picture 2</figref> is identical to that of the <figref idref="f0001">figure 1</figref> but according to the invention, the user has obtained an emulation device (C) which he has placed in a place which is easily accessible to him, for example on the table in his living room.

0032The invention proposes to simulate on the network (in our case, a local network of the IP type but alternatively the network can be of a different type) the physical layer of various peripherals. This simulation, or emulation, or even “virtualization”, makes it possible to have access to peripherals external to the terminal, these peripherals being seen as peripherals local to the terminal.

0033The invention proposes in other words to perform data routing from a server equipment (here, the emulation device) having physical interfaces to one or more terminal equipment in the network (domestic or broadband ), thus deporting the physical interfaces.

0034The emulation device (C) of the<figref idref="f0001">picture 2</figref> comprises a set of physical ports corresponding, for example, to the USB (Universal Serial Bus, a standard for serial communications), SD (Secure Digital), NFC (English Near Field Communication” for near-field communications), SATA (from English “Serial ATA” for connecting high-speed storage devices). The device has a screen (not shown) or alternatively a remote screen on the television.

0035On the example of the <figref idref="f0001">picture 2</figref>, the emulation device has two USB ports (S1, S2), an NFC interface (S4) and an SD interface (S3). The emulation device also embeds a set of programs according to the invention, which make it possible to successively ensure the recognition of the terminals, the association of the terminals and the peripherals, then the transfer of the data between the terminals and associated peripherals.

0036According to this example, the user connects the USB key and the gamepad to two USB ports of the emulation device then associates the USB key with two terminals (PC, TV) of the local network and the gamepad with the STB (T5 ).

0037The TV (T4) is also equipped with an adaptation device (<i>dongle</i>) Wifi/USB to be able to exchange data with the emulation device.

0038In general, this invention can be applied to any terminal connected to the local area network, to the broadband network, or via a WiFi/USB or Ethernet/USB adapter (dongle). Terminals can be natively compatible or made compatible by installing a specific driver.

0039This association can be done automatically, or via a user interface offered on the device.

0040Thereafter, everything happens as if the USB key was connected to the PC (T2) and to the TV (T4), and as if the gamepad was connected directly to the STB (T5).

0041The<figref idref="f0002">picture 3</figref> represents a hardware architecture of a device according to the invention (C) connected to a terminal (T2-T5) of the local network.

0042The emulation device (C) conventionally comprises memories (M) associated with a processor (CPU). The memories can be of the ROM type (from the English<i>Read Only Memory</i>) or RAM (from the English <i>Random Access Memory</i>) or Flash. The emulation device (C) communicates on the local network (9) via the ETH (Ethernet) module.

0043In accordance with the <figref idref="f0001">picture 2</figref>, The device comprises a set of physical interfaces (S1-S4) corresponding to the USB (S1, S2), SD (S4), NFC (NFC P, S4) standards. Each of these interfaces is managed by software for controlling the physical interface (USB P, SD P, NFC P). The device further comprises a SATA physical interface, not shown, managed by a “SATA P” driver.

0044In the context of this application, the term “physical interface” refers not only to the hardware but also to all the software drivers (in English “drivers”) which make it possible to access it.

0045All the modules communicate with each other conventionally via a data bus (12).

0046The emulation device (C) also comprises a PILAS module for PILotage of ASsociations, capable of ensuring the virtual association of a physical interface on the emulation device (C) with one or more software or virtual interfaces ( VS1-VS4), on a network terminal. The PILAS module notably accesses the memory of the emulation device (M) to create, consult and update the association table (TIV) which maps the physical interfaces of the emulation device and the virtual interfaces of the terminals . This table will be described a little later in support of the<figref idref="f0003">figure 4</figref> and <figref idref="f0004">5</figref>. The PILAS module may for example be a software program running in the memory of the emulation device, or a hardware and software assembly. The PILAS module can, alternatively, be located on another piece of equipment on the local network, or on an external server.

0047The emulation device (C) further comprises a PILIP module (PILotage of the Physical Interfaces) for controlling the communication between the physical interfaces of the emulation device and the various virtual interfaces on the remote terminals. In particular, it is responsible for reading the associations in the association table and consequently controlling the communication between a physical interface and a virtual interface (message routing, priorities, etc.)

0048The terminal (T2-T5) also includes memories (M) associated with a processor (CPU). It communicates on the local network (9) via the ETH (Ethernet) module. All its modules communicate with each other via a data bus (13). The terminal represented in this example comprises a set of virtual interfaces (VS1-VS4) corresponding to the USB, SD, NFC, SATA standards. Each of these interfaces is represented by a software module (USB V, SD V, NFC V, SATA V). A software interface, which is also called “virtual interface” indiscriminately in the rest of this application, is a software module running on the terminal and having the same access (to the terminal) as the software driver of an equivalent physical interface. . In other words, this software module manages all communications (read and/or write) with the terminal as if it were a software driver of an equivalent physical interface.

0049The device also comprises a management module PILIV (PILotage des Interfaces Virtuelles) of the various virtual interfaces, capable of ensuring the association of a virtual interface (software) with a physical interface on the emulation device (C). The PILIV module also accesses the memory of the termi to create, consult and update the association tables which allow it to know at a given moment the virtual interfaces which are available to it. The PILIV module can for example be a software program running in the memory of the terminal.

Figure 4 shows an embodiment of the invention

0050In this example, the three terminals T2 (PC), T3 (domestic gateway) and T4 (TV) as well as the emulation device (C) according to the invention are connected to the local area network (9) controlled by the gateway. In accordance with the<figref idref="f0001">picture 2</figref>, the emulation device (C) comprises four physical interfaces (S1-S4). It includes in memory a table, schematized in the lower part of the figure. This table (TIV - Table of Virtual Identifications), which allows the device to manage the associations between its physical interfaces and virtual interfaces on the various terminals, includes for each physical interface:<ul id="ul0002" list-style="dash"><li>a column <i>CBC</i> to indicate the source terminal which physically carries the interface (here, they are all on the emulation device C);</li><li>a column <i>I</i>/<i>F(T)</i> to indicate the reference of the physical interface, as well as its type (T), for example S1 (USB) for physical interface 1 of the USB type;</li><li>a column <i>(Ti)</i> per terminal (for example column T2 for terminal 2) comprising the list of virtual interfaces (VS1-VS4) of the terminal, in association with a physical interface (S1-S4).</li></ul>

0051Thus, according to this example, the terminals T3 and T4 both have a virtual interface VS3 corresponding to the physical interface number 3 (S3) on the emulation device. In other words, a physical SD card inserted into the SD compartment of the emulation device becomes accessible from the home gateway (T3) and the TV (T4).

0052To achieve this association, the emulation device has chained several steps beforehand which will be described later in support of the<figref idref="f0005">figure 6</figref> : • Discovery of terminals available in the network; • Discovery of the services and physical interfaces offered by each terminal; • Pre-association of virtual pilots to the different terminals (corresponding in our example to an initialization in memory of the TIV table), which can result in a table of the following form:<tables id="tabl0001" num="0001"><table frame="all"><title><i>Table 1: table of pre-associations (TAS)</i></title><tgroup cols="4"><colspec colnum="1" colname="col1" colwidth="22mm" /><colspec colnum="2" colname="col2" colwidth="17mm" /><colspec colnum="3" colname="col3" colwidth="19mm" /><colspec colnum="4" colname="col4" colwidth="16mm" /><thead valign="middle"><row><entry><i>CBC</i>/<i>IF (T)</i></entry><entry><i>T2 (PC)</i></entry><entry><i>T3 (BOX)</i></entry><entry><i>T4 (TV)</i></entry></row></thead><tbody valign="middle"><row><entry>C/S1 (USB)</entry><entry>Yes</entry><entry>Yes</entry><entry>Yes</entry></row><row><entry>C/S2 (USB)</entry><entry>Yes</entry><entry>Yes</entry><entry>No</entry></row><row><entry>C/S3 (SD)</entry><entry>Yes</entry><entry>Yes</entry><entry>Yes</entry></row><row><entry>C/S4 (NFC)</entry><entry>No</entry><entry>Yes</entry><entry>No</entry></row></tbody></tgroup></table></tables>

0053Each time a box in the table includes the mention "yes", the pre-association phase can make it possible to install the corresponding virtual driver on the terminal: for example, the terminal T4 being declared compatible with the interfaces S1 and S3 , the virtual drivers corresponding to these two types of interfaces (SD and USB) can be installed on the TV in anticipation of a later association.<ul id="ul0003" list-style="bullet"><li>Management of software drivers, terminal versions and updating if necessary.</li><li>Management of the association table (TIV), for example on user intervention: if the user requests a virtual SD interface on his television (T4), the terminal T4, having been declared compatible, will be able to be associated with the S3 interface of the emulation device.</li><li>Automatic management of the quality of service table, namely optimization of services according to the available bandwidth and prioritization of flows according to their type.</li></ul>

0054To achieve this association, in our example, a terminal for its part has previously chained several steps which will be described later in support of the <figref idref="f0005">figure 6</figref> : <ul id="ul0004" list-style="bullet" compact="compact"><li>Announcement of the terminal on the network:<ul id="ul0005" list-style="none"><li>∘ Announcement of services, physical interfaces, drivers, etc. offered by the terminal.</li><li>∘ Declaration of the physical peripherals offered by the terminal (hard disk, printer, etc.)</li></ul></li><li>Management of virtual drivers on the terminal (installations, updates, etc.)</li></ul>

Figure 5 shows another embodiment of the invention

0055This example is very similar to the one illustrated by the <figref idref="f0003">figure 4</figref>, but the emulation device (C) according to the invention uses not only its own physical ports but also the physical ports of the terminals: it can take over the physical USB port of the terminal 2 (T2, PC) and associate it subsequently to another terminal, thus ensuring the routing of data from the physical port of terminal 2 to the virtual port of terminal 3.

0056The table TIV includes an additional line to indicate the association of the physical interface A1 with the virtual interface VA1 on the terminal T3.

0057The<figref idref="f0005">figure 6</figref> represents a timing diagram of the exchanges between an emulation device and a terminal according to one embodiment of the invention.

0058During a step E1, a terminal registers with the emulation device (C) of the invention, for example the PC 2 of the <figref idref="f0001">figure 1</figref>. The terminal can manifest itself automatically to the emulation device in order to register and dynamically declare its own capabilities (available drivers, physical interfaces and connected peripherals, etc.). Alternatively, registration rules can be implicit. For example, if there is only one terminal in the local network, or a terminal of only one type (PC, etc.), the emulation device can initiate this discovery phase itself, in order to appropriate the characteristics of the terminal(s), and directly associate certain peripherals with certain terminals. For example, a USB key can be automatically associated with the PC of the local network, if this happens to be the only PC, or with several PCs of the local network; the gamepad can be systematically associated with the STB, etc.

0059The emulation device receives the recording request during a step E10.

0060During a step E11, the emulation device constructs a first table of possible associations (TAS) between the terminal and the physical ports which could potentially be associated with it. Such a table can be built according to our example as follows:<ul id="ul0006" list-style="dash"><li>The emulation device has three interfaces (S1, S2, S3);</li><li>It can associate with terminal 2 which has just declared itself the S1 interface (USB), the S2 interface (USB), the S3 interface (SD) although the terminal does not have it natively, but not the interface S4 (NFC).</li></ul>

0061This leads to the following table, as far as terminal 2 (T2) is concerned:<tables id="tabl0002" num="0002"><table frame="all"><title><i>Table 2: table of pre-associations for terminal 2</i></title><tgroup cols="3"><colspec colnum="1" colname="col1" colwidth="26mm" /><colspec colnum="2" colname="col2" colwidth="26mm" /><colspec colnum="3" colname="col3" colwidth="25mm" /><thead valign="middle"><row><entry><i>CBC</i>/<i>IF (T)</i></entry><entry><i>I</i>/<i>F(T)</i></entry><entry><i>T2</i></entry></row></thead><tbody valign="middle"><row><entry>C/S1 (USB)</entry><entry>S1 (USB)</entry><entry>YES</entry></row><row><entry>C/S2 (USB)</entry><entry>S2 (USB)</entry><entry>YES</entry></row><row><entry>C/S3 (SD)</entry><entry>S3 (SD)</entry><entry>YES</entry></row><row><entry>C/S4 (NFC)</entry><entry>S4 (NFC)</entry><entry>NO</entry></row></tbody></tgroup></table></tables>

0062The operation is repeated for each terminal which declares itself or is discovered by the emulation device, thus resulting in a table with several columns as presented previously.

0063Then it optionally sends back to the terminal, during a step E12, the result of the interfaces retained for a possible association.

0064Upon receipt of this message, the terminal updates (step E2) its list of supported drivers and physical interfaces, in order to increase in particular the hardware compatibility of the system. For example, the terminal can receive the following information:<ul id="ul0007" list-style="bullet"><li>one of its USB ports has been "virtualized" on the emulation device, i.e. any subsequent connection of a USB key to the associated physical port of the emulation device will lead to the same result as a direct connection to the terminal's USB port (refer to the <figref idref="f0003">figure 4</figref>).</li><li>a new SD port has been "virtualized" on the emulation device, that is to say that, although the terminal does not have an SD port natively, everything will happen later as if the associated SD port of the emulation device was physically on the PC.</li><li>a new NFC port has been “virtualized” on the <i>smart phone</i> of the PC user, i.e. any subsequent NFC communication addressed to the smartphone will end up at the user's PC.</li><li>etc</li></ul>

0065During a subsequent step E20, the user plugs a USB key into one of the physical ports (S1, S2) of the emulation device.

0066During step E13, the emulation device according to the invention detects the connection of the USB key to one of its interfaces (for example S2) and consults its interface pre-association table (TAS). Following this operation, it can offer the user (E14) a graphical interface showing all the terminals that have a virtual USB port, in our example terminals 2 (PC), 3 (domestic gateway) and 4 (TV). This step is optional because the association, as mentioned before, can be automatic.

0067It should be noted that the emulation device can allow several client terminals to simultaneously access a physical peripheral, and that it manages the arbitration in this case.

0068During a step E21, the client displays the information on possible associations in the form of a graphical interface offering the user a list of possible associations. The latter can choose by a simple selection (click) the association of a physical device with a given terminal.

0069During a step E22, the user chooses, for example via the graphical interface, to connect the USB key to his PC (T2).

0070This information is received in step E15 by the device which validates this association and updates the table of associations (TIV) to take this new association into account.

0071During a step E16 which may follow it, the emulation device prepares an acknowledgment for the terminal concerned which receives during a step E3 this information indicating to it that its virtual interface VS2 is now active and ready to operate.

0072During a step E17 which may follow it, the emulation device prepares a quality of service table which enables it to arbitrate the potential conflicts between the various terminals, in particular the priority which may be assigned to some of them. them (for example in the case where a USB interface is shared) and the allocation of bandwidth.

0073The emulation device is in fact capable of diagnosing the route leading from a physical peripheral to a host in order to predict the maximum bandwidth available on this link; the server maintains a flow prioritization table and is thus able to provide quality of service (QoS) to clients.

0074During a step E18, the emulation device receives a read and/or write request from the terminal (2) which requested this operation during step E4. During step E18, consulting its association table (TIV) allows the emulation device to redirect the read (resp. write) command to the interface associated with the terminal 2, here the USB port 2.

0075Step E23 finally corresponds to the physical writing or reading in the USB device, under the control of the emulation device (C).

0076It goes without saying that the embodiment which has been described above has been given purely as an indication and in no way limiting, and that many modifications can be easily made by those skilled in the art without departing from the scope. of the invention.

0077For example, a remote service in the broadband network can thus be identified at the home gateway, or at one of the terminals of the network, everything happening in this case thanks to the invention as if the service were in the network. local: for example, a user's data can be saved on a hard disk that is in the broadband network while it appears to be physically connected to the user's PC, etc.