Updating parameters in a bridged multistandard home network
Abstract
A method for providing an input parameter from a first network station that communicates with a gateway (14) based on a network protocol of a first type, in which a second network station is connected by means of the gateway link (14) to a first network station, a communication being between the second network station and a third network station based on a network parameter of a second type, failing the network parameter of the second type in having a dedicated process to inform the third network station about the change of the input parameter in a normal operating state, characterized in that the second network station, which refers to the input parameter is before of anything disconnected by the gateway (14) of the network, when the information regarding the change of the input parameter for the second network station is received, because in the network station (14) a step of generating an XML + application description is carried out with the information about the change of the input parameter that is mapped on an information element that is known in the second network parameter type, and the second network station that continuation connected back to the network, so that the third network station in the network is informed about the input parameter changed in a connection phase when reading the application description of XM Updated.

Term
Term ended
Projected expiry passed 29 December 2023, 2.7 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
5 claims: 3 independent, 2 dependent
- 1ES 2 389 762 T3 REIVINDICACIONES 1. Un método para proporcionar un parámetro de entrada desde una primera estación de red que se comunica con una puerta de enlace (14) basándose en un protocolo de red de un primer tipo, en el que una segunda estación de red está conectada por medio de la puerta de enlace (14) a una primera estación de red, estando una comunicación entre la segunda estación de red y una tercera estación de red basada en un parámetro de red de un segundo tipo, fallando el parámetro de red del segundo tipo en tener un proceso dedicado para informar a la tercera estación de red acerca del cambio del parámetro de entrada en un estado de operación normal, caracterizado porque la segunda estación de red, que se refiere al parámetro de entrada es antes de nada desconectada por la puerta de enlace (14) de la red, cuando la información relativa al cambio del parámetro de entrada para la segunda estación de red es recibida, porque en la estación de red (14) se lleva a cabo una etapa de generar una descripción de aplicación de XML + con la información acerca del cambio del parámetro de entrada que es mapeada sobre un elemento de información que es conocido en el parámetro de red del segundo tipo, y la segunda estación de red es a continuación conectada de nuevo en la red, de manera que la tercera estación de red de la red es informada acerca del parámetro de entrada cambiado en una fase de conexión cuando lee la descripción de aplicación de XML actualizada.
- 2El método de acuerdo con la reivindicación 1, en el que la desconexión y la conexión de nuevo de la segunda estación de red que se refiere al parámetro de entrada son llevadas a cabo de acuerdo con el Protocolo de Descubrimiento de Servicio Simple SSDP, en particular utilizando el mensaje de desconexión ssdp::adiós y el mensaje de conexión ssdp::conectado.
- 3El método de acuerdo con la reivindicación 1 ó 2, en el cual el parámetro de entrada es un nombre de dispositivo y es mapeado en el elemento de información NombreAmigable de la descripción de aplicación de XML.
- 4El método de acuerdo con una de las reivindicaciones precedentes, en el cual se proporciona un menú de introducción de texto (60) para la introducción definida por el usuario del parámetro de entrada desde una estación de red (20) y es superpuesto en una unidad de visualización, y sobre la cual el texto actual de un campo de texto seleccionado (61) es superpuesto, siendo el texto introducido con la ayuda de las teclas de números en un control remoto.
- 5Una unidad de conexión (14) para la conexión de una primera estación de red a una segunda estación de red, que tiene medios para recibir información acerca de un cambio en el parámetro de entrada para la segunda estación de red, basándose la comunicación entre la primera estación de red a la unidad de conexión (14) en un parámetro de red de un primer tipo, estando la comunicación entre la segunda estación de red y una tercera estación de red basada en un parámetro de red de un segundo tipo, fallando el parámetro de red del segundo tipo en tener un proceso dedicado para informar a la tercera estación de red acerca del cambio en el parámetro de entrada en un estado de operación normal, teniendo medios de desconexión que están adaptados para la desconexión de la segunda estación de red en la red, cuando se recibe la información relativa al cambio del parámetro de entrada para la segunda estación de red, teniendo medios de generación de una descripción de XML (28) para generar una descripción de XML actualizada, siendo la información acerca del cambio en el parámetro de entrada mapeada sobre un elemento de información que es conocido en el parámetro de red del segundo tipo, y teniendo medios de conexión, que están adaptados para conectar una vez más la segunda estación de red, de manera que la tercera estación de red sea informada acerca del parámetro de entrada cambiado en una fase de conexión cuando se lee la descripción de aplicación de XML actualizada.
Independent claims5
52 paragraphs in 3 sections, as filed
ES 2 389 762 T3
DESCRIPTION
Parameter update in a bridged multistandard local network.
The invention relates to the technical field of local networks. In particular the invention resides in the area where a first network station is connected to a second network station, for example to a UPnP-based local network station, through a gateway.
Background of the Invention
Various local network standards for networking applications in the home area are now available. In particular, the IEEE 1394 bus standard has established itself in the field of entertainment electronics. This enables communication between applications for entertainment electronics at a very high data rate. Data rates of 100, 200 and 400 Mbit / s are supported. This is sufficient to transmit asynchronous data packets for the control of network stations, as well as isochronous video and audio data streams, in parallel. The IEEE 1394 standard, however, specifies only the lower layers of the ISO / OSI reference model for data communication, that is, the bit transmission layer (Physical layer), the data protection layer (Data protection layer). Data Link) and parts of the switching layer (Network Layer). The upper layers, that is, the transport layer, the communication control layer (Session Layer), the presentation layer and the application layer, are therefore not specified.
A consortium of entertainment electronics companies has also taken on the task of defining the upper layers for data exchange between entertainment electronics applications. This standard is known by the abbreviation HAVi, where HAVi stands for Local Audio / Video Interoperability. This standard specifies a so-called Interoperability Middleware, which ensures that products from different manufacturers understand each other, that is, they cooperate to carry out tasks together over the network.
Another consortium of companies, particularly Microsoft-led computer industry companies, has started a different initiative to specify network control software based on the existing Internet Protocol (IP - Internet Protocol). This network system has turned out to be known by the abbreviation of UPnP (Connect and Play Universal - Universal Plug and Play, in English). In this system, the specification does not refer primarily to electronics applications for entertainment, but other applications can also be integrated into the network, in particular such as personal computers, domestic applications in the white range, such as refrigerators, microwave ovens, washing machines, heating controllers, light controllers, alarm system controllers, etc.
Even though the two local network standards HAVi and UPnP are sometimes seen as competing, at least in part they serve different purposes and a scenario is assumed in which the two can exist side by side in a home environment, and are connected to each other through a gateway. It would then be possible to control the applications in the UPnP network from the HAVi network side and vice versa. The unit of connection between the two networks is referred to as the gateway in the following text. The term "gateway" is often not the same as the other term "bridge circuit", which is also used. In some cases, however, the difference between a bridge circuit and a gateway is that a bridge circuit transmits the data packets in the data protection layer to the respective other network while, on the contrary, in In the case of a gateway, the data packets are actually transmitted at a higher level in the ISO / OSI reference model.
Work on HAVi and UPnP networking gateways so far has always been based on a so-called "proxy-based gateway" approach. This hides the following: In order for UPnP network stations to be visible from a HAVi application, UPnP applications are represented on the HAVi side at the gateway by so-called HAVi-DCMs. DCM in this case stands for Device Control Module. These additional DCMs are then connected to the HAVi network and can be addressed from the HAVi applications. A DCM is in this case required for each UPnP network station. If the network station offers different functionalities, such as a television having the function of a tuner, an amplifier and a display unit, then several of the so-called FCMs can be provided for each dCm. An FCM is in this case a so-called functional component module, by means of which an application functionality is thus covered.
On the contrary, HAVi network stations should also be managed from the UPnP side. On the UPnP side, a HAVi application is represented by a so-called UPnP device. This means that a corresponding UPnP device is also provided at the gateway for each HAVi network station. There is a description of an XML application call for each UPnP device. In this case, XML stands for the Extension Markup Language description language. The corresponding feature for a HAVi FCM on the UPnP side is a so-called service. Various UPnP services can thus be described in one UPnP device. The conversion between HAVi and UPnP DCM / FCM device / services should be as
ES 2 389 762 T3 complete as possible. However, if the two standards are compared, it is clear that such a complete conversion is not always possible.
UPnP applications invariably originate from areas beyond entertainment electronics applications, so the functionalities of such applications, such as a washing machine, cannot easily be mapped into the normal functionalities of electronics applications for entertainment. How this can nevertheless be achieved successfully for the representation of UPnP applications on the HAVi side is apparent from the previous European Patent Application EP 02 090 147.6 of the same applicant.
In WO-A-02/09384 a local network is described comprising a UPnP group and a HAVi group. A bridge is proposed to represent a UPnP device in the HAVi group, where the UPnP device description is used to generate a HAVi DDI target to allow UI-based control of UPnP devices through a HAVi UI.
From WO-A-01/01632 it is known to translate a HAVi software element into an XML representation to allow a station to participate in a UPnP network. It is proposed that this type of representation can be created "in the moment" each time by connection request.
From document US-A-2002/0083743 a host system for multiple slave networks is known with which a UPnP network and for example a USB or Bluetooth network is connected. In a description of the UPnP protocol stack it is proposed that devices are required through the discovery process to ensure that the network is kept up to date.
Invention
During the development work concerning the joining of the different local networks on the basis of HAVi and UPnP, the inventor has encountered a problem in that it is also not possible to complete one-to-one conversion between the functionalities of HAVi and UPnP. . On the HAVi side, functionality such as this is the ability to assign a user-defined name to a HAVi network station. This can be freely chosen by the user, and can also be changed retrospectively. The HAVi specification in this context states that the UserPreferredName (UserPreferredName) parameter can be defined for each application. If this application name changes, then the changes are signaled by so-called events for all other HAVi network stations which can then make the appropriate change visible, if they are equipped with a display unit. If the application name changes it is also intended to be visible on the UPnP side, then the UserPreferredName parameter must be mapped to a corresponding information element. In the associated XML application description. The only element that can be used for this purpose on the UPnP side has the designation “FriendlyName” (FriendlyName) and is part of the XML application description. The UPnP specification is, however, predicated on the application descriptions of XML which are documents that cannot be changed. Specifically, there is no ability to inform UPnP applications that, for example, the description of the previously started XML application has changed and should therefore be updated for UPnP applications, so to speak.
However, the invention aims to provide the ability to allow the change of application names consistently visible on the UPnP network. The solution according to the invention comprises that the UPnP network stations are forced once more to read the updated XML application description whose application name has been changed to exit and then to enter once more.
A software module is advantageously provided in the gateway, which evaluates the application name change event and then ensures that the disconnect message is sent to the UPnP network, initiating the reinitialization of the associated XML description. and ensuring that the message for the appropriate application to connect again is sent to the UPnP network. In particular, the discovery message of the type ssdp :: bye (ssdp :: byebye) can be advantageously used as a disconnect message. The discovery message of the type ssdp :: connected (ssdp :: alive) can be advantageously used as the input message. The software item in the XML application description that best represents the application name has the FriendlyName designation on the UPnP side.
An advantageous development of the invention provides a text input menu to be provided for user-defined input of the application name, this menu being superimposed on a display unit on the HAVi side, and being designed so that text can be entered with the help of the number keys on a remote control.
Drawings
Exemplary embodiments of the invention will be explained in more detail in the description that follows and illustrated in the drawings, in which:
ES 2 389 762 T3
Figure 1 shows an illustration of two local networks that are connected to each other via a gateway;
Figure 2 shows the procedure for the method according to the invention, and the interaction of the software components in the HAVi application whose application name has been changed, and in the gateway, and;
Figure 3 shows the text input menu according to the invention.
Description of the invention
Figure 1 shows the basic structure of two local networks that are connected to each other by means of a gateway. A UPnP-based local network is shown on the left side of Figure 1. Reference numeral 10 denotes a monitoring camera, as an example of a UPnP application. Reference numeral 11 denotes a light control unit as another example of a UPnP network station. Reference numeral 12 also denotes a personal computer, which is also integrated into the UPnP network. UPnP applications are connected via an n13 network connection. The widely used and well-known Ethernet Bus should be mentioned as a typical example of a network connection 13 such as this one.
An example of a local network that is designed in accordance with the HAVi standard is shown on the right hand side of Figure 1. Reference numeral 19 denotes a so-called overhead television box, which is a receiver for digital television. Reference numeral 20 denotes a digital TV. Digital televisions such as these typically no longer have their own reception section, but instead receive the digital video and audio data from some other application, for example from the top box of the television 19. In the illustrated situation, the data Video and audio are, however, transported via network cable to digital television 20. Reference numeral 21 denotes a video recorder. The network cable is marked by the reference number 22. In the assumed example of a HAVi network, this network cable 22 is made up of the so-called IEEE 1394 bus.
Gateway 14 is illustrated in the center of Figure 1 and connects the two networks to each other. For this purpose, on the one hand a so-called IP stack 15 and on the other hand a so-called HAVi stack 16 is provided at the gateway 14. The IP stack 15 and the HAVi stack 16 contain all the software components that are required for participation in the connected network respectively. In addition, the gateway 14 contains other software components, which are not listed separately. However, the illustration schematically shows that data is exchanged between the two software stacks 15 and 16. Reference numeral 17 in this case denotes the data path for the audio and video data streams. Reference numeral 18, in constant, denotes the data path for control messages that need to be exchanged between the two software stacks.
The HAVi standard as well as the UPnP specification have been published. Version 1.1 of the HAVi specification is now available. The precise title is: The HAViSpecification “Specification of the Home Audio / Video interoperability (HAVi) Architecture”, Version 1.1, May 15, 2001. The UPnP specification can be obtained from Microsoft. Other information is also available on the official website for the UPnP system. For this purpose, reference should be made to the website www.UPnP.org.
Since the components of the HAVi system and the UPnP system are not all important in explaining the present invention, only the essential components will be explained in more detail in the text that follows. For other details, express reference is made to the two specifications mentioned above.
In Figure 2, the same reference numbers denote the components also illustrated in Figure 1. The major software components of the gateway 14 are shown on the left side of Figure 2. The major software components of the digital television 20 are shown on the right hand side of Figure 2. As already explained with reference to Figure 1, the gateway 14 contains an Internet Protocol stack 15 for communication on the UPnP network, and a HAVi stack 16 for communication on the HAVi network. The IEEE 41 1394 interface is shown at the lowest level of the HAVi 16 stack. This is not typically in the form of a software component. Actually, the IEEE 1394 standard stipulates that both the bit transmission layer and the data protection layer must be in the form of hardware. Two separate ICs are typically used for this purpose. Furthermore, the so-called media manager 40 is in the form of a software component. This is part of the switching layer and the transport layer, and forms an interface between the other software elements and the IEÉE 1394 bus. The so-called message exchange system 39 is implemented on top of the media manager 40. In the HAVi standard, this component is a very important component, since the message exchange system is used whenever two different software modules they want to exchange data with each other. The message exchange system is independent of the network layer and the transport layer in the ISO / OSI reference model.
Another model in the HAVi stack is a so-called event handler 34. The object of the event handler 34 is to inform the different software elements of the network of changes / events that have occurred. Events such as these occur in particular when an application is added to the network or when it is disconnected from the network. Another software component of the HAVi 16 stack is a so-called register 35. The 4 available software items
ES 2 389 762 T3 network is listed in the registry. The registry offers the service of searching for specific software items. A piece of software that wants to communicate with other pieces of software on the network must be registered in the registry. Another software element of the HAVi 16 stack is a so-called DCM manager 36 whose purpose is to install the DCMs (Device Control Modules, in English - Device Control Modules) in the respective network station.
The applications that are implemented in the network access a number of so-called FCMs (Functional Component Modules, in English - Functional Component Modules). The functionalities of various types of FCMs are specified in the HAVi standard itself. These include a Tuner FCM, a VCR FCM, a Clock FCM, a Camera FCM, an AV Disc FCM, an Amplifier FCM, a Visualizer FCM, an AV Visualizer FCM, a Modem FCM. and a Network Proxy FCM.
The resource manager 37 has the task of monitoring whether specific resources are still available on the network for a respectively demanding task, or whether they have already been allocated. This allocates appropriate resources to application programs, as long as they are free.
A so-called flow manager 38 is also provided as another component in the HAVi stack, and is responsible for establishing connections between subscriber stations in the network. The AV data streams can then be transmitted over the connections that have been established.
Various DCM modules are also set in the gateway, on top of the software elements, which have already been described, in the HAVi stack. A DCM is a piece of software that is used on the HAVi side to control a corresponding HAVi application. An associated HAVi DCM is therefore installed at the gateway for each UPnP application, in order to control UPnP applications. By way of example, reference numeral 30 denotes the DCM for monitoring camera 10 in the UPnP network. The DCM 31 is used to control the personal computer 12 in the UPnP network. An associated DCM 33 is also provided at the HAVi gateway 14 for the light control unit 11. According to the HAVi specification, the other DCMs of the HAVi network can also be installed in the HAVi gateway 14, but they do not need it, as shown in the example in Figure 2. Reference number 32 it also denotes the application program for the gateway 14. The functions that this module performs will be explained in more detail in the following text.
The IP stack 15, which is also provided on the gateway 14, is not shown with all its components. The configuration of an IP stack such as this is known from the prior art. Therefore, only three main components are illustrated, in order to simplify the illustration. The first of these is a so-called http network server 27 which contains the different XML application descriptions for the HAVi network applications, i.e. an XML 23 application description for the video recorder 21, a description XML application description 24 for the television top box 19 and an XML application description 25 for digital television 20. A unit for implementing the SSDP protocol is also provided as one more component of the IP stack 15, and is denoted by the reference number 29. The SSDP Protocol (Simple Service Discovery Protocol) it is also assumed to be known. Another component is also an XML 28 application description production unit. This is also seen as a conventional implementation for the gateway technology that is available today. The component does not need to be viewed as part of the IP 15 stack, and can also be implemented as a separate unit from it.
The individual software elements of the HAVi stack are also listed separately for digital television 20. Since these components are denoted by the same letter abbreviations as those of the HAVi stack 16 of the gateway 14, there is no need to explain these parts again in detail.
The digital television 20 in the example embodiment is assumed to be a so-called FAV (Full AV Device) application. An application such as this is equipped with a very large number of HAVi software elements. The special feature is that a FAV application also has a so-called Java virtual machine built into it. The application is thus capable of converting Java code into executable program code, and then executing it in an appropriate manner. The FAV application has the ability to load a DCM from the same other FAV network application with the DCM for the FAV application. Figure 2 therefore shows that the DCMs 43 and 45 for controlling the video recorder 21 and the television top box 19 are also installed together with the DCM for digital television 44. The illustration also shows a user interface 42 as well.
The way in which various software elements interact when the user-defined application name 20 for digital television changes in the HAVi network will now be described in detail in the following text. The User Preferred Name input parameter is provided to the HAVi system in order to identify a user-defined application name. This parameter is part of every DCM. However, the parameter is also stored, for example, in the register for the respective application. The user would like to assign a single name to the individual applications on the network. If there are two or more applications in the same network category, for example a television that is located in the living room and a television in the bedroom, then you should
ES 2 389 762 T3 it will be easily possible to distinguish between these applications. For example, for this purpose, the user can give the name "Living room TV" to the television in the living room. Once the name has been entered via the user interface, the user interface 42 will inform the DCM for digital television 20, with the assistance of the Message Exchange system 51, that a new User Preferred Name parameter has been Entered for television, marked with the ♦ tag. For this purpose, User Interface 42 uses the DCM :: SetUserPreferredName (SetUserPreferredName) service that is available from DCM. In addition to updating the parameter in the DCM itself, this service also Starts the new record of the new name in record 47, which is Identified by the ♦ tag. Once all the inputs relative to this parameter have been updated, the DCM 44 then issues a notification to the event manager 46. This stage is marked by the tag ·, and is carried out by the DCM 44 generating a so-called UserPreferredNameChangedEvent (UserPreferredNameChangedEvent, in English). Since this event is classified as a global event within the HAV¡ system, this results in the event handler 46 transmitting this event. The label denotes the notification of the gateway 14 via the User Preferred Name Event Changed for digital television 20. All the software elements of the gateway 14 that are of interest to this event have been registered in the event manager 34. Specifically, the gateway software module 32 for the event manager 34 has been able to register for the UserPreferredName Changed Event. The event manager 34 will then inform the software of the gateway 32 of the arrival of the Event of User Preferred Name Changed relative to digital television 20, see label ·. The notification from the software of the gateway 32 then leads the issuance of a notification to the UPnP protocol stack 15 for the gateway. This is identified by the mark · in Figure 2. Since the UPnP protocol stack 15, however, does not accept any specified HAV¡ messages, the software at the gateway 32 has to initiate a translation of this message into the format that the UPnP stack 15 can understand. The associated UPnP message that can be understood by the UPnP stack 15 can be based on the so-called SOAP protocol (Simple Object Access Protocol), the gateway software 32 therefore so much so that he has to initiate, or carry out himself, a conversion of the HAV¡ message to the form of a SOAP message. Since both systems are specified, this conversion could be carried out without any other difficulties. The SSDP unit 29 then converts the corresponding SOAP message based on the SSDP protocol to an SSDP discovery message. Alternatively, this may also be implemented such that the software in the gateway 32 informs the software module representing the HAV application as a UPnP application of the change to the name. This module then uses the SSDP module 29 to generate the discovery message ssdp :: goodbye (DTV), which is broadcast on the UPnP network to all other subscriber stations. This is identified by the + mark.
This notification results in the digital television 20 being disconnected from the UPnP network. This means that a UPnP application that is currently fully displaying the network structure, including HAV applications, on a display unit will briefly mask the digital television 20 from the display. Once the digital television 20 has been disconnected, the software of the gateway 32 then ensures at the stage marked by the + mark that the XML application description production unit 28 generates a new XML description for digital television 20. This is done by the software module 32 by replacing the old "FriendlyName" with the new "User Preferred Name", which is received for each event, in the XML document and replacing the old description 25 on the Network server 27 by the new one. The associated stage is identified by the + mark.
Once the new application description has been produced, the gateway software 32 once again produces a SOAP message for the SSDP module 29, label +. This SOAP message is converted by the SSDP module into an SSDP discovery message, this being, to be precise, the ssdp: connected (DTV) message. Digital television 20 once again uses this message to connect to the UPnP network once again, tag Θ. Converting the DCM 44 to the associated XML description 25 only takes a little time, for example a few milliseconds. The incoming message is therefore also transmitted only for a short time after the disconnect message to the UPnP network. Disconnection of the DTV application 20 in the meantime is therefore not perceived, or is barely perceived, by the user. When digital television 20 comes back in, UPnP applications are again prompted to load the XML description for digital television 20. Once this process is complete, the new application name is also updated in the UPnP network and is taken into account in the display, that is, that the new name of the application will be shown in the respective display unit.
This procedure ensures consistency of names between networks. The procedure that involves having the HAV¡ application disconnect beforehand and then reconnect ensures that the name of the HAV¡ network application is never inconsistent in any phase.
The following text also provides an explanation of how text input for a text field can advantageously be entered into a user interface by means of a conventional remote control. Figure 3 shows a text input menu according to the invention, which is identified by reference numeral 60 in the figure. The illustration also shows a text field within the user interface for
ES 2 389 762 T3 controlling digital television 20 which is located in the HAV¡ network. This text field is provided with the reference number 61, which corresponds to the input field for the User Preferred Name input parameter. The illustration shows that the standard TV input is currently entered in this field. Once the user has focused on this text field, that is, selected it using the remote control, the input menu 60 is initiated by pressing the "text entry key" on the remote control. After pressing the “text input key” on the remote control, a check is carried out to determine if a text input field has been selected that can be located in a havlet, in an application or in the UI itself of the FAV.
The text input menu appears in the form of a window on the television display unit. A larger text input window 62 is provided within the text input menu 60. The normal keys of a remote control are symbolized together with this text input window. These include number keys, cursor control keys, a selection key, and different colored keys whose importance is in each case indicated in abbreviated form next to the colored symbol. The symbols above the number keys in each case show which letters can be selected using that number key for text input. The text is therefore entered by means of a remote control using the numeric keys, for example in the way known from mobile phones. In this context, it is also possible to integrate an automatic word identification in the text input tool. For example, the T9 word identification system is also used in mobile phones. As illustrated in Figure 3, once the text entry menu has been automatically opened, the current content of the selected text field is automatically copied into the text entry field 62. The blinking of the cursor below this then indicates that the individual letters in the standard input can be changed. Once the new name has been entered, the new entry is copied into text field 61 by pressing the OK enter key. If "OK" is pressed in the "text input tool", the corrected text is copied into the text input field 61, and is selected. This results once again in the same state as before the text input, but the text in the text input field has been changed. To finish entering text, press “OK” once more. In the state before starting and after finishing the “text tool”, a correct numeric keypad can be used to enter text or else to enter numbers using the numeric keys on the remote control.
The text input tool can be in the form of a central tool within the HAVi 42 UI of digital television 20. The text input tool is provided for the situation where no numeric keypad is actually provided for the television. digital, but just a normal remote control. Programming conversion for this text input aid can be carried out as follows. The HAVi 42 user interface monitors whether the remote control's text key has been pressed. In this case, the only keys that are displayed in the text entry tool are those that are required to enter the text. Since the text key is used before the text input tool has been activated and is no longer needed after that, it is no longer illustrated in Figure 3.
After pressing the "text input key" on the remote control, a check is carried out to determine if a text input field has been selected, which may be located in a havlet, in an application program or in the the FAV's own user interface program.
After text entry is complete, the text entry tool is deactivated, and the text that has just been edited is copied into the previously selected text entry field. This is thus a universal text input aid, which can be used for all havlets / applications in the HAVi network.
The invention can be used in particular for a gateway that is used for connecting a HAVi network to a UPnP network. However, it is also feasible to use it for gateways that connect other networks to each other, for example a HAVi network to an OSGi network or a network such as EHS that relies on the transmission of network data to a network of IP such as UPnP or OSGi.
Contents3
3 sheets
Sheet 1 Sheet 2 Sheet 3
20 members in 10 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 10302477 | Germany | A | |
| 10302477 | Germany | A | |
| 10302477 | Germany | – | |
| 10302477 | – | – | – |
| DE2003102477 | – | – | – |
Members20
| Document | Office | Kind | |
|---|---|---|---|
| WO2004066556A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2003292267A1 | Australia | A1 | |
| DE10302477A1 | Germany | A1 | |
| KR20050095622A | Republic of Korea | A | |
| EP1586175A1 | European Patent Office (EPO) | A1 | |
| CN1739263A | China | A | |
| JP2006513650A | Japan | A | |
| MXPA05007670A | Mexico | A | |
| CN100387009C | China | C | |
| US2008209536A1 | United States of America | A1 | |
| EP1586175B1 | European Patent Office (EPO) | B1 | |
| JP4511947B2 | Japan | B2 | |
| DE60333393D1 | Germany | D1 | |
| EP2244422A1 | European Patent Office (EPO) | A1 | |
| US7865622B2 | United States of America | B2 | |
| KR101011105B1 | Republic of Korea | B1 | |
| US2011022731A1 | United States of America | A1 | |
| US7984191B2 | United States of America | B2 | |
| EP2244422B1 | European Patent Office (EPO) | B1 | |
| ES2389762T3This record | Spain | T3 |
Numbers
- Publication
- 2389762
- Publication, DOCDB
- 2389762
- Publication, EPODOC
- ES2389762T
- Application
- 10169438
- Application, DOCDB
- 10169438
- Application, EPODOC
- ES20100169438T
Titles2
- Spanish
- Actualización de parámetros en una red local multiestándar puenteada
- English
- Parameter update in a bridged multistandard local network
Classification
- CPC, 9
- H04L12/2818
- H04L12/28
- H04L12/2805
- H04L12/2834
- H04L12/4625
- H04L12/66
- H04L2012/2849
- H04L12/46
- H04L9/40
- IPC, 3
- H04L12 28
- H04L12 46
- H04L12 66