ITTO20110272A1 - PROCEDURE FOR REMOTE CONTROL OF A SET TOP BOX - Google Patents

Description

â € œProcedure for remote control of a set top boxâ €

TEXT OF THE DESCRIPTION

The present invention relates to a method for the remote control of a set top box suitable for receiving from a broadcast transmitter, on a respective broadcast communication channel, a set of services formed by multimedia streams, in particular audio, video, data and applications conforming to the MHP standard (Multimedia Home Platform), called set top box including a channel for a connection to a local network.

In domestic environments, the presence of electronic devices that can be controlled remotely by the user is increasing. Among these devices, the so-called set top boxes, non-portable television electronic devices intended to add multimedia functions to a television, monitor or video projector, assume pre-eminent importance. Among these set top boxes, for example, set top boxes for digital terrestrial and satellite are very popular.

Such set top boxes are usually controlled, and often only, by means of corresponding remote controls, but it is generally not possible to operate them through other remote control means, in particular remote control means that are already available to the user.

Solutions are known, such as for example Google TV, which involve interacting with a set top box or television apparatus via a remote control simulated by a software application run on a user terminal such as a smartphone, which interacts via a Wi-Fi channel with the set top box. However, these solutions refer to closed systems, in which the set top box integrates a specific proprietary application for smartphone control.

The present invention has the purpose of realizing a remote control process that solves the drawbacks of the prior art, allowing to control a generic set top box operating with the MHP platform, by means of remote control usually already available to the user. for other purposes, without pre-setting this set top box for such remote control at the factory.

According to the present invention, this object is achieved thanks to a process having the characteristics referred to specifically in the following claims. The invention also relates to a corresponding system.

Further characteristics and advantages of the invention will emerge from the following description with reference to the attached drawings, provided purely by way of non-limiting example, in which:

- figure 1 represents a basic diagram of a system implementing the process according to the invention;

- figure 2 shows a flowchart representative of operations of the process according to the invention;

Figure 3 shows a flow chart representative of steps of the method according to the invention performed at a user terminal;

- Figures 4a and 4b show a flow chart representative of the steps of the process according to the invention carried out on the set top box.

In short, the procedure for operating the remote control of a set top box according to the invention provides for sending commands to this set top box from a mobile terminal capable of communicating with a local network to which said set top box is connected, said set top box being designed to operate in response to these commands from the mobile terminal through an MHP application loaded therein, received at least in part through a DVB (Digital Video Broadcasting) broadcast transport stream, and capable of interpreting these commands from the terminal remote, which is loaded into a memory of this set top box, accessible for example by a microprocessor. This occurs in particular in order to implement commands for channel switching and other functions replicating a set of functionalities of the conventional remote control of the set top box.

Figure 1 describes a system implementing the process according to the invention, indicated as a whole with the numerical reference 10.

System 10 includes a set top box 20, for example for the reception of digital terrestrial television signals, while 30 indicates a conventional remote control of this set top box 20, i.e. a remote control configured to control the operations of the set top box by sending command signals C, in a per se known way, for example via infrared signals to a dedicated interface for remote control control. Reference 50 indicates a broadcasting center, or service broadcaster. These services correspond to logical entities that group together a set of SA audio streams, SV video and SD data, for example typically a television channel, which are transmitted in a transport stream 54 over the air, on a broadcast channel 53, i.e. broadcast, towards of the corresponding receivers, in general set top boxes such as the set top box 20. The set top box 20 is of the type configured to support the MHP (Media Home Platform) standard providing the middleware which acts as a software interface between digital interactive applications and the hardware of the set top box 20 where they are loaded and / or installed. For what is explained here and in the following regarding the MHP standard, reference is made to the publication â € œDigital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1.3â €, which is available at the URL http://www.mhp.org/specs/a068r3_mhp11.zip.

The set top box 20 shown in Figure 1 also has an interface for connecting a broadband channel 70, for example an ADSL channel, through which it can receive data and commands.

This set top box 20 is connected, for example, to a television set or to a display or projector, not shown in figure 1, by sending them signals and data, for example through a SCART cable. Furthermore, said set top box 20 comprises, in a per se known manner, a return channel 20a. The MHP middleware used in the set top boxes is in fact generally able to use different types of return channel (for example PSTN, ADSL, GSM, GPRS, UMTS, Ethernet and others) as long as the connection supports the TCP protocol stack / IP. The return channel 20 used by the solution described here must be of a type suitable for allowing connection to a local network (Local Area Network), in particular to a domestic LAN, supporting the TCP / IP standard, for example preferably à ̈ an Ethernet type channel. This return channel 20a is connected to a local network 60, of the wired or wireless type.

According to a preferred version, the local network 60 comprises or communicates with a network router 60a to which the return channel 20a is also connected.

Also the broadband channel 70 is preferably not connected directly to the set top box 20 but is connected to this router 60a, or to another router, to which the return channel 20a is connected, so that through the router 60 ° they are conveyed to the return channel 20 both the broadband signals on channel 70 and the signals exchanged with the local network 60.

A mobile user terminal 40 is also provided, for example a smartphone such as an Apple® iPhone, which is capable of exchanging signals on a channel 40a, preferably a channel with Wi-Fi wireless protocol, with said local network 60. A smartphone generally refers to a mobile communication terminal equipped with an operating system that allows the subsequent installation of software applications.

The system 10 of figure 1 is therefore representative of an integrated broadband-broadcast context in which the set-top box 20 receives over the air, tuning on a specific frequency, the transport stream 54 and also receives signals from the local network 60 and possibly from channel 70 of the ADSL type.

Transport stream 54 is for example an MPEG2 stream obtained by multiplexing elementary streams audio, video, data (applications) and control tables. In other words the transport stream 54 contains various services; each service is composed of elementary streams, SA audio, SV video and SD data (applications, subtitles, etc.).

In figure 1 in the broadcaster 50 a so-called multiplex 51 is shown, which represents a group of television services combined together for the OTA (On The Air) transmission and a respective transmitter 52 for transmitting the combined television services on the broadcast channel 53 in the transport stream 54.

The method according to the invention, with reference also to the flow diagram of Figure 2, generally comprises an operation G100 for preparing this set top box 20 to interpret event signals E sent by the terminal 40 to control operations of the set top box 20, by means of a xlet RC which allows remote control of the set top box 20, with xlet meaning an application suitable for operating on the MHP platform, loaded from the set top box 20 at least in part through this broadcast communication channel 53. This application, or xlet, RC is therefore not pre-installed by the factory, but received by the set top box 20, in part or entirely, via the transport stream 54 on the broadcast communication channel 53.

It is therefore envisaged, in general, to perform a G200 operation to start this xlet RC, for example by operating on the conventional remote control 30 by sending commands C for the activation of the xlet RC and transferring control to the mobile terminal 40 .

A G300 remote control operation of the set top box 20 by a user terminal 40 is therefore envisaged by sending event signals E from the user terminal 40 to said MHP RC xlet loaded in the set top box 20 . These event signals E interpreted by the xlet RC originate controls, indicated with A in figure 1, of operations that can be performed by the set top box 20. In figure 1 these controls A are indicated as sent through the middleware by way of example to a microcontroller MC of the set top box 20 which carries out the operations required by these controls A originating on the basis of the events E from the user terminal 40. These events E and controls A determine the execution of a channel change operation, but possibly also of other functions, such as access to menus or guides. These event signals E are exchanged through the local network 60 to which the set top box 20 is connected through the return channel 20a, possibly, as mentioned, through a network router, while the user terminal 40 is connected to it by means of , as mentioned, for example, of a Wi-Fi radio communication channel 40a.

Therefore, the user terminal 40 comprises installed a respective software module, for example an iPhone® app, indicated with IRC in Figure 1.

This IRC software module is configured to perform 40 operations through the user terminal, indicated as a whole with T100 in figure 3, which include a T110 identification or discovery operation of this MHP RC xlet active in one or more set top boxes 20 connected to the local network 60. After the user has selected the IRC software module, the user terminal 40 performs a discovery step to identify the controllable set-top boxes. This control of a set-top box 20 by a user terminal 40 can be mutually exclusive, as better detailed below with reference to the flow diagram of Figure 4.

The communication between the user terminal 40, seen as a client computer in a client / server communication protocol, and the set top box 20, seen as a server computer, is based on a request / response protocol. The client sends a request to the server. The server responds with a success message or an error code followed by response data. Client / server communication is based on the HTTP protocol.

In the exemplary embodiment, which envisages using an iPhone® smartphone as a user terminal, the Apple Bonjour protocol is used to identify the set top boxes 20 available on the local network.

This Apple Bonjour protocol operates on three main operations, each of which is a necessary part of zero-configuration network services:

an operation of publication of the service by the set top box 20, indicated with S115 in figure 4;

the T110 identification or discovery operation, in which the available services are acquired; a T120 resolution operation, which translates the name of the selected service and the port numbers for use.

For example, it is envisaged that the server, that is the set top box 20, operates in particular as a Multicast DNS responder and must publish the service relating to the xlet RC, a string that in the Bonjour protocol syntax is in the form _mediatemote._tcp. The application protocol â € œmediaremoteâ € must be registered to a so-called DNS-SD Web Site (as defined in the RFC2782 specification).

The detection operation T110 comprises that the user terminal 40 searches for PTR (pointer) records corresponding to the type of service sought. The DNS Multicast Responders operating in each set top box device 20 return their respective PTR records with the names of the service instances.

The resolution operation of the T120 service provides in particular that the user terminal 40, which operates as a client, performs a DNS lookup operation relating to an SRV record (service record) with the name of the service. The Multicast DNS responder replies with the SRV record which contains the current information.

Furthermore, this IRC software module is configured to perform T130 sending operations, through a respective user interface IU, the event signals E to remotely control said set top box 20.

As regards the syntax of the T130 operation for sending event signals E, the T100 software module on the user terminal 40 sends HTTP requests to a host address obtained during the T110 discovery and T120 DNS resolution operation, as well as to a data port, which usually has the value 6666.

The HTTP request format of said event signals E is for example:

http: // host: port / imr? command = <command>

For example, the event signal E for a command to set the volume (SetVolume) can be:

http: // host: port / imr? command = SetVolume & volume = 50

The server, that is the set top box 20, sends X replicas which are preferably in XML format with UTF-16 encoding for example of the type:

<? xml version = â € 1.0â € encoding = "UTF-16"?>

<response>

<code> 0 </code>

<reason> Success </reason>

<results> Results </results>

</response>

The response X of the xlet RC contains for example:

code field (code) (mandatory), which defines the response code;

reason field (optional), which reports a clear message describing the response code;

â € ¢ results field (optional), which can contain different data depending on the request.

The code and reason fields of the X replica with a description are listed below:

0 SUCCESS: successful operation

1 ERROR: operation failed; the server specifies an error message

2 DOPAIRING: the coupling must be carried out

3 PAIRINGUNDERWAY: the pairing process is in progress

4 DOCONNECT: Client must connect before sending commands

5 LOCKED: Another client is already connected to the server

The previous list refers to optional pairing operations between the terminal 40 and the set top box 20, i.e. operations in which the two devices agree to communicate with each other and establish a connection. For this pairing operation a password or is usually exchanged

passkey.

The communication can support commands such as:

Connect to establish the control session;

Disconnect to end the control session;

Pairing to pair client to server;

SessionKeepAlive to prevent the session from expiring.

The events E that the terminal 40 can send to determine through the RC application of corresponding controls A equivalent to the controls of the remote control 30, may include, by way of example, one or more of the following events E:

Back Back button

BlueKey Blue button

Enter Ok key

Exit Exit key or Exit from the current action

GetPercentage Gets the current playback position as a percentage of the length of the media being played

GetPlaySpeed Gets the current playback speed

GetVolume Gets the current volume setting (as a percentage of the maximum possible value)

GreenKey Green button

Mute Turns the sound on / off

MoveDown Down Button

MoveLeft Left Button

MoveRight Right Button

MoveUp - Up key

NumericKey Numeric keys from 0 to 9.

Pause Pause playback

Play Play the current media

PlayNext Next program

PlayPrev Previous program

RedKey Red button

SeekPercentage Sets the playback position of the current media as a percentage of the media length

SeekPercentageRelative adds / subtracts the current percentage of the current position of the media

SendText Sends text to the server

SelectServiceByNum Selects a DTT service by number

SetPlaySpeed Sets the playback speed to an integer value

SetVolume Sets the volume as a percentage of the maximum possible

ShowApps Shows the available applications

ShowGuide Shows the guide

ShowInfo Shows information about DTT events

ShowList Shows the channel list

ShowMenu Shows the menu

ShowTeletext Shows the teletext

Shutdown Causes Shutdown

Stop Stops the currently playing media

YellowKey yellow key.

When the IRC module is loaded onto the terminal 40, a request for the television services available on the set top box 20 is preferably made; after this phase it will be possible for the user to send events E from terminal 40 to which the xlet RC in the set top box 20, which is in particular a Java xlet, will react by changing service. If the detected service is not available, for example because it is no longer present or the antenna is not connected, an error message will be displayed on the interface of the associated TV.

It is also planned to send through the local network 60 so-called â € œheartbeatâ € signals, with a process similar to that of sending beacon frames in the 802.11 wireless standard, periodic to allow the xlet to become available again in case of non-termination. correct session.

The described RC xlet remains active until the user terminates it or changes channel using the remote control 30 of the set-top box 20.

When the user selects the service, the RC MHP xlet is launched automatically and becomes available for use by 40 terminals that are able to identify it transparently, through the T110 operation of detection or discovery. After the operations T110 and T120, the user terminal 40 knows the host IP address and the port port of the set top box 20 to be used to send the event signals E, ie the commands for emulation of the remote control 30.

With reference to the G300 remote control operation of the set top box 20, it is now detailed how the channel change operation is performed using the RC application.

This G300 operation preferably requires that the RC application that uses the channel change uses the Java Media Framework API.

In this context, the G300 operation also provides, when necessary, to use the network controller defined in the API DAVIC (Digital Audio-VIsual Council) for the frequency change.

The set top boxes that operate in accordance with the MHP standard are not built for real multitasking and the channel change involves the instant termination of all the applications present in the old service unless they are also reported in the AIT table of the new service. The MHP standard includes among its libraries of procedures or packages, the so-called API (Application Program Interface), the JavaTV service selection API, which allows you to change the service programmatically, however with the change of channel the application that made the the operation usually ends. It is foreseen according to the invention therefore to make use in the xlet RC of a different module of the MHP standard, which allows to present different audio / video streams without necessarily selecting a new service. The MHP middleware relies on the Java Media Framework defined by Sun Microsystems to control how audio and video contents are decoded and displayed; applications can also use this framework for viewing streams from other services present in the tuned transport stream. The Java Media Framework is not allowed to change frequency, but if this is necessary, the xlet RC can use the network controller defined in the API DAVIC (Digital Audio-VIsual Council) to carry out this operation. The change of frequency through the DAVIC API does not constitute a change of service for which no application of the destination tran sport stream can be loaded and launched both from the terminal and from the MHP applications. The frequency change obviously makes it impossible to access the departure service carousel.

Therefore, the G300 control operation for channel switching is expected to use the Java Media Framework. Java Media Framework allows the visualization of an audio and video stream of another service but since there has not been an actual change of channel from the remote control, the data of the original service will be maintained.

In this regard, the proposed procedure provides that with the reception of events E from the user terminal 40 the xlet RC obtains, in a transparent way to the user, the information relating to the chosen channel, i.e. a locator that specifies for the selected service:

- transport stream identifier tsid,

- original network identifier onid,

- service identifier sid.

If the transport stream identifier tsid received in the events E is different from the one currently used, the xlet RC proceeds to change frequency through the DAVIC API, tuning to the requested frequency. Then the RC xlet via Java Media Framework selects the required service components and displays them on the television.

In the diagram of Figure 3 it is indicated precisely as an example that the events E from the user terminal 40 generated in the operation T130 for sending event signals E contain the locator, that is the information tsid, onid, sid.

As an example, a pseudocode to perform this operation can have the following form.

The procedure for tuning using the DAVIC API can be:

public void tune (Locator locator) throws Exception {

try {

// Controller as scarce resource is reserved by application controller.reserve (selected, notifyObj);

reserved = true;

// Tune to a locator with tsid and onid data

controller.tune (locator);

}

catch (Exception e) {

// Error in the tuning phase

}

// Release of the tuner

controller.release ();

}

The procedure for starting a player to view a service can be: public void setSource (Locator l) throws Exception {

DataSource ds = null;

try {

// Create the locator for the resource (service) you want to view (tsid, onid and sid)

ds = Manager.createDataSource (new

MediaLocator (l.toExternalForm ()));

// Create the player with the required data source p = Manager.createPlayer (ds);

}

catch (Exception e) {

// Error starting the player

}

p.start ();

}

However, this pseudocode exemplifies the use in accordance with what is described in the MHP standard.

As already mentioned, this control operation G300 envisages using the return channel 20a as the communication channel. The MHP middleware by means of the â € œinteractive broadcastâ € and â € œinternet accessâ € profiles includes support for using the receiver's return channel 20a. As mentioned, the return channel requirement is that the connection must support TCP or UDP over IP.

Note that to manage these connections, the MHP middleware relies on the Sun Microsystems java.net libraries. Given the need to always keep the connection active, it is preferable that the set-top box 40 supports a connection of the â € œalwaysonâ € type, for example using a Telesystem 7900 HD or ADB 3810T set top box.

In the planned architecture, these java.net APIs are used by the xlet RC in communicating with the set-top box 20 with the following purposes:

â € ¢ send debugging information to verify the operation of the RC application;

â € ¢ receive E events from terminal 40 for channel change;

â € ¢ manage the initial handshake.

The handshake and control commands are transmitted over the local network 60.

With reference to figures 4a and 4b, a flow diagram is shown which is representative of a possible S300 implementation of operations performed by the set top box 20 in the context of the remote control operation G300.

In this diagram, S105 indicates an operation start step.

S110 indicates a start-up step of the xlet RC, which can take place via remote control 30, as also detailed in figure 5.

S115 indicates a publication step of the IMediaRemote service relating to the R application.

Following this publication step S115, the set top box 20 remains active for a procedure for detecting and executing events E received by the user terminal 40.

A step S120 is therefore envisaged to detect a possible change of channel on the remote control 30. In the affirmative one proceeds to a step 210 for the end of operations, in the negative case one proceeds to a step 125 in which it is evaluated whether a event E from user terminal 40.

If step S125 has a negative response, the control is returned upstream of step S120. If this is the case, a step S130 is carried out to check whether a unique, i.e. exclusive access by a given user terminal 40 is required.

In the event of a positive response to step S130, at a step S135 it is checked whether the set top box 20 has already been reserved by another user terminal 40. If this is the case, it passes to an access not allowed status S140. In the negative case, one passes to a block state S145 of events coming from other user terminals 40. Both from step S140 and from step S145 one then proceeds to a step S150 for sending the results of the relative step to the user terminal 40 and therefore the control It is reported upstream of step S120 to repeat the detection and execution of events E.

From step S130, if one is not in the condition in which a unique access is required or the device has already obtained the aforementioned unique access, one proceeds to step S155 to verify whether a volume change is required through events E from the user terminal 40. If this is true, the volume change is performed in one step 160 via the JMF API.

If a volume change is not required, from step S155 one proceeds to step S165 to check whether a channel change is required.

If so, in a step S170 it is checked whether a different frequency is requested for this channel change. If not, the visualization of the new audio / video components is performed directly in a step S180 via the JMF API. In the affirmative case in a step S175 the frequency change is made using the API / DAVIC and then step S180 is carried out where the display of the new audio / video components with API JMF is performed. From step S180 one proceeds to step S150 for sending the results of the relative step to the user terminal 40 and then the control is carried over to step S120 to repeat the detection and execution of events E.

If a channel change is not required from step S165, one passes to a step S185 in which it is checked whether the event E is related to a heartbeat operation.

In the affirmative case, in a step S190 the data relating to the corresponding user terminal 40 are updated to avoid the expiration of the session relating thereto, thus returning to step S120.

If a heartbeat event has not been received, it is checked in step S195 whether the unique control should be released and, if so, access to other user terminals is allowed, returning the control to the beginning of the steps channel change in step 120, through the step of sending the results S150.

If the verification at step 195 is also negative, an unrecognized event condition is signaled at step S205, returning the control to the beginning of the channel change steps at step S120, through step S150, restarting the detection and execution of events E.

The remote control 30 is expected to operate as follows, for example, by means of the respective commands C, to transfer control to the xlet RC and to the terminal 40:

- operate the remote control 30 to select a television service or channel on which the xlet RC is carried, for example Channel 5 or RAI1,

- consult the applications provided for this channel in the transport stream, which may include in general, in addition to the xlet RC, other applications, for example the Electronic Program Guide;

- select the RC xlet.

In this way the RC xlet is activated (step S105) and the corresponding published service (step S115).

The various ways in which the G100 setup operation can be carried out are detailed below.

This G100 setup operation generally provides that the xlet RC is transported to the set-top box 20 by means of the carousel of one of the OTA services in transport stream 54.

As mentioned, the xlet RC is loaded, at least in part, from the transport stream 54 to be installed in the set top box 20.

In fact, the control tables transmitted in the transport stream 54 contain all the information that allows the set top box 20 that receives them to use the transmitted contents:

- AIT (Application Information Table) containing data relating to applications; the AIT table contains in particular a descriptor for each application

present in the service.

- PAT (Program Association Table), PMT (Program MapTable) to identify elementary streams;

- further DVB tables

The AIT table is therefore expected to contain a descriptor for the remote control RC xlet; in the remainder of this description, the string iMediaRemote will be referred to as the name of the application indicated in the descriptor.

The AIT table also includes the following data:

name and identifier of the application and of the organization that developed it; data for loading classes;

arguments necessary for the launch of the application;

codes that identify how the application must be launched (auto-start or launched by the user) and when.

Upon receipt of the AIT table in the transport stream 54, the set top box 20, therefore, automatically or at the request of the user through the respective remote control 30, starts the xlet RC by loading the necessary classes from the broadcast channel 53 from which the transport stream 54 (DSM-CC carousel), thus loading the RC application completely via the tran sport stream 54, or via the broadband channel 70, i.e. loading only part of the RC application via the transport stream 54 .

The procedure includes two possible forms for the preparation:

- the RC application is loaded from the transport stream 54, when, for example, it is requested by the user via the remote control 30;

- the RC application is not directly usable by the user but through a second application, possibly presenting the user with an interface to allow the registration and display of any legal notes, it can be pre-loaded and associated to a specially created stored service. In general, the second application, which launches the RC application, is loaded on the set top box 20, coming for example from the transport stream 54. The xlet RC is downloaded from the tran sport stream 54, when it is required. Use, through the second launch application, which creates the stored service and associates it with the RC application.

If the second form is operated, upon completion of the installation on the set top box 20 of the xlet RC, a stored service will be present on the set top box 20, capable of appearing in the list of available television services and to which it is associated the xlet RC to allow remote control in response to the specific events E received from the user terminal 40, in particular the channel change.

The procedure according to the invention provides for the creation of stored services to which â € œstored applicationsâ € are associated as defined in the MHP standard, ie normal MHP applications that can be stored in the set top box 20 for its future use. In particular, it is envisaged to associate stand-alone applications on the set top box 20 to a stored service, which can be launched regardless of what is transmitted via broadcast. This allows the user to select the stored service and thus the corresponding RC channel change application regardless of what is being broadcast at any given time.

The life cycle of stand alone applications, such as that of common xlet applications, requires that at the change of channel the applications are terminated if not reported in the new AIT table

A stand-alone application does not have access to the carousel and, not being associated with a service, does not have a player for managing audio and video; the application can, however, create and start its own Java Multimedia Framework player for viewing other streams, and then perform the channel change operations as indicated for example with reference to figure 4.

As required by the MHP standard, this stand-alone application in order to be stored is indicated with a special descriptor called â € œapplication storage descriptorâ € in the AIT table which is associated with an ADF file (application descriptor file).

The proposed method therefore advantageously allows to use the user terminal 40, in particular a smartphone, which is already equipped both to connect to the local network 60 and to run software applications, to simulate the remote control of the set top box, sending the commands, essentially, through the local network.

Naturally, the principle of the invention remaining the same, the details of construction and the embodiments may vary widely with respect to those described and illustrated purely by way of example, without thereby departing from the scope of the present invention.

Claims (13)

CLAIMS 1. Method for the remote control of a set top box (20) adapted to receive from a broadcast transmitter (50) associated with a multimedia services multiplexer (51), on a respective broadcast communication channel (53), a set of services provided through multimedia streams (54), in particular audio, video, data and applications, compliant with the MHP (Multimedia Home Platform) standard, called set top box (20) including a channel for a connection to a local network (60), characterized by the fact that includes the operation of sending (G300) event signals (E) from a user terminal (40) to an MHP application (RC) capable of interpreting these event signals (E) to control operations of the set top box (20) , said MHP (RC) application being loaded into said set top box (20), said MHP (RC) application comprising at least one application part received through said broadcast communication channel (53), said event signals (E) being representative of a set of operations of the set top box (S100) that can be controlled by means of a remote control (30) of the set top box (20), called set of operations (S100) including in particular a channel change operation (165), called event signals (E) being exchanged through said local network (60) to which said set top box (20) and said user terminal (40) are connected. 2. Process according to claim 1, characterized in that it comprises preparing said user terminal (40), in particular by installing a corresponding software module, for: - identify this MHP (RC) application installed in one or more set top boxes (20) connected to said local network; - sending through a user interface (IU) of said user terminal (40) said event signals (E) to remotely control said set top box (20). Method according to claim 2, characterized in that it comprises sending said event signals (E) to remotely control said set top box (20) from the user terminal (40) through HTTP requests sent to a given address (host) and value of port (port). 4. Method according to claim 3, characterized in that it comprises providing from the set top box (20) a response (X) to said HTTP request of said user terminal (40), in particular in XML format, comprising at least one response code . 5. Process according to one or more of the preceding claims from 2 to 4, characterized in that it comprises obtaining said given address (host) and port value (port) by means of a resolution operation (T120) which translates the name of a selected service. Method according to one of claims 1 to 5, characterized in that it comprises fully loading said MHP (RC) application into said set top box (20) through said broadcast communication channel (53). Method according to one of claims 1 to 5, characterized in that it comprises installing said MHP (RC) application in the set top box (20) as a stored application associated with a stored service. 8. Process according to claim 7, characterized in that said MHP (RC) application is loaded into the set top box (20) as a standalone application stored in said stored service. Method according to one of the preceding claims, characterized in that it comprises sending event signals (E) representative of a channel change. 10. Method according to claim 9, characterized in that in response to said operation of sending event signals (E) representative of a channel change, said MHP (RC) application operates (165) by changing channel using the Java Application Programming Interface Media Framework. Method according to claim 9 or 10, characterized in that it comprises using a network controller defined in the Application Programming Interfaces DAVIC (Digital Audio-Visual Council) to effect a frequency change, if required by the channel change. 12. A method according to claim 11, characterized in that it comprises carrying out said frequency change if said event signals (E) representative of a channel change comprise a transport stream identifier (tsid) different from a transport stream identifier (tsid) currently used by the set top box (20). 13. System for the remote control of a set top box, comprising a broadcast transmitter (50) associated with a multiplexer of multimedia services (51), to transmit on a respective broadcast communication channel (53) a set of services formed by streams multimedia (54), in particular audio, video, data and applications, compliant with the MHP (Multimedia Home Platform) standard towards a set top box (20) and a remote terminal (40) capable of being communicated via a local network ( 60) with said set top box (20), characterized in that it is configured to implement the operations of the method according to at least one of claims 1 to 12.