WO2002009384A2 - Pont entre reseaux domestiques base sur une interface utilisateur - Google Patents

Pont entre reseaux domestiques base sur une interface utilisateur Download PDF

Info

Publication number
WO2002009384A2
WO2002009384A2 PCT/EP2001/007898 EP0107898W WO0209384A2 WO 2002009384 A2 WO2002009384 A2 WO 2002009384A2 EP 0107898 W EP0107898 W EP 0107898W WO 0209384 A2 WO0209384 A2 WO 0209384A2
Authority
WO
WIPO (PCT)
Prior art keywords
upnp
havi
cluster
ddi
functionalities
Prior art date
Application number
PCT/EP2001/007898
Other languages
English (en)
Other versions
WO2002009384A3 (fr
Inventor
Jan R. Moonen
Original Assignee
Koninklijke Philips Electronics N.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics N.V. filed Critical Koninklijke Philips Electronics N.V.
Priority to EP01965096A priority Critical patent/EP1293081A2/fr
Priority to KR1020027003858A priority patent/KR20020035644A/ko
Priority to JP2002514977A priority patent/JP2004505360A/ja
Publication of WO2002009384A2 publication Critical patent/WO2002009384A2/fr
Publication of WO2002009384A3 publication Critical patent/WO2002009384A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2805—Home Audio Video Interoperability [HAVI] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/281—Exchanging configuration information on appliance services in a home automation network indicating a format for calling an appliance service function in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2814—Exchanging control software or macros for controlling appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2832—Interconnection of the control functionalities between home networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/282—Controlling appliance services of a home automation network by calling their functionalities based on user interaction within the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H04L12/2827—Reporting to a device within the home network; wherein the reception of the information reported automatically triggers the execution of a home appliance functionality

Definitions

  • the invention relates to home networks, and especially to bridging networks that have clusters with different software architectures.
  • a bridge serves to transparently represent a device, complying with a first standard in a network cluster of a first type, as a device complying with a second standard in a network cluster of a second type.
  • the result is a single unified view of the home network available to software applications written for the first standard and as well those written for the second standard.
  • Home networking standards generally address either the lower levels of the protocol stack (up to transport level, e.g., HomePNA, HomeRF) or the higher levels (from transport level to application level). In the remainder of this description reference is made in general to the second type of home networking standards. Examples of these standards are HAVi, UPnP and Jini.
  • a home networking standard offers one of two ways for applications (or clients) to control devices (or servers): programmatic control and UI (user-interface)- based control.
  • Programmatic control refers to control that is based on sending standardized messages to a device, or control that is based on calling a standardized API, resulting in messages sent to a device. This kind of control is useful for applications that control devices without any direct user-interaction being required.
  • both the controller and the controllable device use a pre-determined set of messages that can be exchanged. That is, the controller has to know the type of controllable device in advance.
  • Ul-based control refers to control that uses sending user interactions from a controlling device to a controllable device.
  • the user interacts with a UI client or browser, and user actions lead to messages sent to a UI server on the controllable device.
  • the messages are exchanged using a particular UI protocol, examples of which are HTML (used in UPnP) and DDI (used in HAVi).
  • DDI stands for Data Driven Interaction and refers to a protocol that is executed between applications or DCMs, whose User Interface needs to be displayed, on one side and a display device on the other.
  • the DDI target is part of a device's DCM.
  • DCM Device Control Module.
  • a DCM is a software element that represents a single device or functionality on the HAVi network.
  • the DCM exposes the HAVi defined APIs for that device.
  • DCMs are dynamic in nature: if a device is inserted or removed from the network, a DCM for that device needs to be installed or removed, respectively, in the network. DCMs are central to the HAVi concept and the source of flexibility in accommodating new devices and features into the HAVi network.
  • the DDI supports user interaction with the appliance.
  • UI protocol does not define the kind of information or control conveyed by it, it merely defines how to encapsulate user actions and send them from client to server. Additionally, it defines how user interface elements (also called widgets) are described and sent back from server to client for display purposes. This implies that Ul-based control is possible even when the controller application does not know the type of controllable device.
  • a UI protocol enables a device to present features that go beyond the standardized device type capabilities, in other words, it enables a standardized device to distinguish itself from the competition.
  • a natural approach is to translate between the programmatic interface of a device type in a first software architecture of standard A to the programmatic interface of the device type in a second software architecture in a standard B different from standard A, and vice versa.
  • a natural approach is to translate the UI interface of a device type in standard A to the UI interface of the device type in standard B, and vice versa.
  • the inventor has realized that certain problems are associated with this approach and has analyzed the bridging in further detail so as to provide a solution.
  • Fig.1 is a diagram to clarify that there is more than these options.
  • the diagram of Fig.1 shows part of a home network 100 that has a cluster 102 with a software architecture complying with a standard A, and a cluster 104 with a software architecture of a standard B.
  • Network 100 has a device 106 of a certain type X residing on network 100 in cluster 102.
  • Clusters 102 and 104 are to be bridged so that device 106 can be controlled from cluster 104 through a software representation 108.
  • device 106 and its representation 108 in cluster 104 in principle can have Ul-based control interfaces 110 and 112, respectively, and programmatic control interfaces 114 and 116, respectively.
  • the diagram lists four bridging options 118, 120, 122 and 124.
  • Bridge 118 provides a translation from UI interface 110 to programmatic interface 116.
  • a UI interface is much more flexible (or less standardized) than a programmatic interface, so translating from a UI interface to a programmatic interface is very difficult, and, for existing home networking standards such as HAVi and UPnP, impossible. This leaves three other options:
  • - A bridge 120 for a translation of UI interface 110 in standard A to UI interface 112 in standard B Whether this is feasible or not depends on the similarity of standards A and B. For example, translating a UPnP device UI to a HAVi device UI is very difficult, since UPnP allows HTML plus any kind of scripting in a device UI. HAVi uses the DDI protocol for device UI, and while HTML is probably translatable to DDI, translating HTML plus scripting is probably not feasible.
  • - A bridge 122 for a translation of programmatic interface 114 in standard A to programmatic interface 116 in standard B Whether this is possible or not depends largely on the domains covered by standards A and B.
  • UI interface 112 in standard B This type of translation requires that the programmatic interface of devices in standard A be available, at run-time, as data for translation purposes. This requires a 'white-box' device description mechanism, where an application can retrieve, at run time, all the information about the device's interface. In other words, an application does not need to rely on built-in knowledge of the interface of the device type, it can retrieve this knowledge at run-time.
  • This type of translation further requires that the data types used in the programmatic interface be mapped as 'modally compatible' GUI elements.
  • the current invention is based on the insight that the translation of a programmatic interface in a standard A to a UI in standard B can be used as a bridge.
  • the requirements are discussed posed on both standards involved for this bridging to work.
  • Embodiments are given below of the bridging option in the form of a translation scheme for a UPnP programmatic interface to a HAVi device UI (DDI target).
  • the invention relates to a method of enabling to bridge a first cluster of first functionalities and a second cluster of second functionalities in a home network.
  • the first cluster has a first software architecture that provides control of the first functionalities through a programmatic interface.
  • UPnP is an example of such an architecture.
  • the second cluster has a second software architecture that provides control of the second functionalities through a Ul-based interface.
  • HAVi is an example of the latter architecture.
  • the method in the invention comprises providing a translation of the programmatic interface to the Ul-based interface.
  • the method comprises generating a HAVi DDI target software element from a UPnP device description document.
  • the method of the invention can be implemented by a service provider.
  • the user notifies the service provider of the new devices added to his/her network, whereupon the provider can generate the translation module to be installed on the user's network as part of a bridge.
  • the invention also relates to a home network with these clusters using different software architectures.
  • the first cluster has a first software architecture that provides control of the first functionalities through a programmatic interface
  • the second cluster has a second software architecture that provides control of the second functionalities through a Ul-based interface.
  • the network has a bridge between the first and second clusters for translating the programmatic interface to the Ul-based interface.
  • the network preferably comprises a generator for generating a HAVi DDI target from a UPnP device description document.
  • An aspect of the invention resides in bridging software for use on a home network, wherein the network comprises a first cluster of first functionalities and a second cluster of second functionalities.
  • the first cluster has a first software architecture that provides control of the first functionalities through a programmatic interface
  • the second cluster having a second software architecture that provides control of the second functionalities through a Ul-based interface.
  • the bridging software is operative to couple the first and second clusters based on translating the programmatic interface to the Ul-based interface.
  • the software comprises a generator for generating a HAVi DDI target from a UPnP device description document in the UPnP - HAVi network.
  • Fig.1 is a block diagram illustrating the options for bridging
  • Figs.2A and 2B are a table with UPnP and HAVi information items referred to throughout the explanation below;
  • Fig.3 is a diagram with a portion of a home network
  • Figs. 4, 5 and 6 are diagrams illustrating interactions between UPnP and HAVi clusters in a home network. Throughout the Figures, same reference numerals indicate similar or corresponding features.
  • the UPnP standard defines the programmatic interface of a device through an XML document called the "description document”. An application can retrieve this document, through HTTP, at run-time, so UPnP satisfies the 'white-box' criterion.
  • HAVi defines the programmatic interface of a device through publication of an API expressed in IDL.
  • the API definition is tied to a unique identifier called the FCM type.
  • FCM Functional Component Module.
  • a DCM contains an FCM for each controllable function within the represented device.
  • HAVi defines FCM's and corresponding API's for functions such as a tuner, VCR, HDD- based storage, AV display, camera's and modems.
  • a HAVi application can retrieve this FCM type from a controlled device, and is able to control the device programmatically based upon its built-in knowledge about the interface linked to the FCM type. Since the HAVi application needs to know the interface linked to the FCM type in advance, HAVi does not satisfy the 'white box' criterion.
  • Jini an application retrieves the programmatic interface of a device by using a lookup service that returns a remote (RMI) reference to the device's Java object representation.
  • Java RMI Remote Method Invocation
  • Java has facilities for 'reflection', it is possible to determine, at run time, the interface (in terms of Java member variables and methods) of a remote object (device) reference. Hence, Java satisfies the 'white-box' criterion.
  • the programmatic interface of a UPnP device may use any of the following types: Boolean, Integer (called i4), Floating point (called r8), String, DateTime (data and time information) or HEX-encoding binary data (called bin.hex or bin.bin64). These types can be mapped in a straightforward manner to common GUI elements found in most UI protocols, including DDI (used in HAVi) and HTML (used in UPnP). See Figs. 2A and 2B. Jini does not define a specific device UI protocol.
  • the programmatic interface of a Jini device may use any Java object.
  • the programmatic interface of a HAVi device may use any IDL type.
  • both HAVi and Jini device interfaces can, in general, not easily be mapped to a UI.
  • a UI mapping is possible for a particular device type that uses a subset of the rich data type features of IDL or Java.
  • a UI mapping is feasible for a Jini interface that uses only basic Java types (no Java objects).
  • the programmatic interface of a UPnP device is described in a description document.
  • This document specifies a root device with zero or more (sub) devices. Each device may have another list of sub devices, etc.
  • a device without any sub devices (a 'leaf in the tree) contains a single service.
  • a service consists of a list of state variables and a list of actions. Services don't have sub services. State variables have a 'name' field, 'type' field, and optionally fields to restrict the range of the type. Actions have a 'name' field and a list of parameters.
  • Each parameter is described by a 'name' field, and a field called 'relatedState Variable'. This field has to refer to a state variable name, and it indirectly defines the type of the action parameter.
  • An aspect of this invention is to generate a HAVi DDI Target from a UPnP device description document. The translation concerns both static aspects of the DDI Target as well as dynamic aspects.
  • DDI elements or widgets need to be defined for UPnP data type; the organization of all DDI elements corresponding to a UPnP service needs to defined; the organization of all DDI elements corresponding to a UPnP device needs to defined.
  • DDI navigation between devices and services needs to be defined; initialization and termination of a 'session' between application and device needs to be defined; the effect of asynchronous changes at the controlled UPnP device needs to be defined; the effect of user actions that are forwarded to the generated DDI target needs to be defined.
  • UPnP data types occur in two ways in a service description, namely, directly: as type of a state variable, and indirectly: through reference of a ⁇ relatedStateVariable> for an action parameter.
  • Some DDI elements are 'interactive': they allow a user to interact with them.
  • a button is interactive, while a text label is not interactive.
  • some interactive DDI elements may be 'temporarily' non-interactive or disabled. To express this, interactive DDI elements have an 'interactivity' field. Since UPnP allows state changes through actions only, DDI elements representing action parameters will set this field to ENABLED. DDI elements representing the current value of a device's state variable, however, will have this field set to DISABLED. Some UPnP data types may have additional specifiers that indicate a particular restriction on the range of value that it may hold. This can could be used to generate more appropriate DDI elements, in some cases. Static: Translating a UPnP service to a DDI structure
  • a service consists of a list of state variables and a list of actions.
  • State variables have a 'name' field, 'type' field, and optionally fields to restrict the range of the type.
  • Actions have a 'name' field and a list of parameters. Each parameter is described by a 'name' field, and a field called 'relatedState Variable'. This field has to refer to a state variable name, and it indirectly defines the type of the action parameter.
  • elements may be organized in a group, in order to suggest some sort of coupling to a DDI display engine (called Ddi controller ). This coupling may be used to determine the organization of elements on the screen, or to determine navigation.
  • Ddi controller DDI display engine
  • a UPnP service can be translated to the following DDI structure:
  • DdiPanel contains two DdiGroup elements and a DdiPanelLink element:
  • the 'elements' field of this group should contain DDI elements obtained from translating all UPnP state variables according to the type mapping described earlier. All of these Ddi elements should have their Interactivity attribute set to DISABLED.
  • DdiGroup element with groupName set to "Actions”.
  • the 'elements' field of this group contains DdiGroup elements for each individual UPnP action.
  • Each of these DdiGroup elements contains: - A DdiButton element which both 'pressedLabeF and 'releasedLabel' fields set to the ⁇ name> field of the action. This element represents invoking the action on the UPnP device.
  • Ddi elements for each input parameter of the action, according to the type mapping applied to the ⁇ relatedStateVariable> field of the action parameter. All of these Ddi elements should have their Interactivity attribute set to DISABLED.
  • a DdiPanelLink element representing the 'parent' device will its linkName field set to the parent device's ⁇ deviceType> or ⁇ friendlyName> field.
  • it could have the linkBitMap field set to one of the available and HAVi-compatible ⁇ icon> values in the parent device description.
  • a device description document in UPnP specifies a root device with zero or more (sub) devices. Each device may have another list of sub devices, etc. Additionally, each device has certain fields associated with this, such as a device icon, a manufacturer name, etc..
  • a (root or sub) device can be translated to the following DDI structure:
  • DdiPanel element with panelName set to the ⁇ deviceType> or ⁇ friendlyName> field of the device.
  • the DdiPanel contains DdiPanelLink elements, one for each sub device or service that it contains.
  • a DdiPanelLink element representing a sub device should have its linkName field set to the sub device's ⁇ deviceType> or ⁇ friendlyName> field.
  • it could have the HnkBitMap field set to one of the available and HAVi-compatible ⁇ icon> values in the device description.
  • a DdiPanelLink element representing a service should have its linkName field set to the service's ⁇ serviceType> field.
  • Each non-root sub device should have:
  • a DdiPanelLink element representing the 'parent' device will its linkName field set to the parent device's ⁇ deviceType> or ⁇ friendlyName> field.
  • it could have the HnkBitMap field set to one of the available and compatible ⁇ icon> values in the device description. All DdiPanelLinks should have the Interactivity field set to ENABLED.
  • the panel could contains DdiText elements, with the Interactivity field set to DISABLED and the textContent field holding the string value for any of the following UPnP device description fields:
  • FIG. 3 is a diagram of part 300 of home network 100.
  • Network 100 has a root device 302: a TV/VCR combo, and two sub devices: a TV 304 and a VCR 306 .
  • TV 304 has three services: an Audio service 308, a Video service 310 Video and a Tuner service 312.
  • VCR 306 has also three services: a Clock service 314, a Tuner service 316 and a Tape service 318.
  • the example shows the use of the ⁇ friendlyName> field ("My BedRoom Fun”), the ⁇ manufacturer> field ("Philips”), the ⁇ modelName> field (“AZ1010”), the
  • Tape service 318 shows a string state variable 320 named "Transport” with ⁇ allowedValueList> specifier: ⁇ "playing", “stopped”, “recording” ⁇ . Furthermore, it shows three actions: “Play”, “Stop” and “Rec”, where the "Rec” action has a single string parameter related to a state variable (not shown here) with ⁇ allowedValueList> specifier: ⁇ "standard”, “long”, “extended” ⁇ .
  • each (root or sub) device and each service is mapped to a separate DdiPanel element.
  • DdiPanelLink elements are used to traverse from the root device down to services via zero or more intermediate sub devices. Additionally, on each level, except on the root device level, a DdiPanelLink is used to travel up in the device hierarchy.
  • ACT_SELECTED When a user on the DDI controller device clicks on the panel, a user action of type ACT_SELECTED will be sent to the DDI target.
  • the DDI target shall respond to this by returning the targetPanel of representing the sub device/service (in case of navigating down the hierarchy) or the parent device (in case of navigating up the hierarchy).
  • the DDI target does not need to communicate with the UPnP device that it represents.
  • a DDI target After a DDI target receives a DDI subscription in step 402 it retrieves the UPnP description document in step 404. Based on the description document the DDI target is able to construct in step 406 the DdiPanel structure as well as all DdiElements it contains. Additionally, the DDI target subscribes to UPnP device state changes, in step 408, using the GENA mechanism.
  • "GENAA” stands for Generic Eventing Notification within UPnP context. Eventing is the ability of a source device to initiate a connection at any time to one or more other devices that want to receive events from the source device. Events are used to establish synchronization among multiple devices.
  • events are mainly used for asynchronous notification of state changes.
  • TCP/IP provides the support for connections to carry event information.
  • GENA adds conventions for establishing relationships between interested devices and an addressing scheme to allow delivery of the event messages.
  • GENA uses HTTP addressing and encapsulation. Separate subscriptions in step 410 are needed for each service. Since a GENA SUBSCRIBE returns the current values of all state variables, the DDI target is 'synchronized' with the UPnP device and is able to return the correct values for all DDI elements when the DDI controller requests them.
  • a DDI target may subscribe to state changes immediately after the description document is retrieved (shown above) or in a 'just- in-time' fashion, just before the DDI controller requests the panel containing the state variable values. After a DDI target receives a DDI unsubscription in step 412 it unsubscribes itself in step 414 from state variable changes .
  • Fig.6 shows the message that results when a user interacts with the UPnP device, through the display of the device running the DDI controller.
  • the mode of operation is that the user first modifies the widgets corresponding to the action parameters and, when the user is done, presses the button that invokes the action on the device.
  • the result of the action, including any output parameter, is shown using widgets that are in 'disabled' or 'non- interactive' mode.
  • Fig.6 shows that typically a user first modifies the widgets corresponding to the action parameters. These lead to “UserAction' messages sent to the DDI target. The target will not forward these interactions to the UPnP device, but rather use them to locally update the parameter values, represented by the widgets. When the user is done, he/she presses the button that represents the action on the device. On the "RELEASE' event of the DdiButton, the DDI target will construct a SOAP (Simple Object Access Protocol) request using the current parameter values, and sent it to the UPnP device.
  • SOAP Simple Object Access Protocol
  • the SOAP action is executed synchronously, and when the action is executed successfully, the DDI Target will complete the user action by returning a DDI "change report" for the output parameter widgets, if there are any.
  • the output parameter values are extracted from the SOAP response message.
  • SOAP SOAP
  • this is a protocol created with contributions from many industrial partners and that allows applications to communicate with each other over the Internet, providing a framework for, e.g., connecting Web sites and applications to create Web services.
  • Web services link sites and applications together to perform functions that the individual components alone are not able to perform.
  • the action invoked on the controlled device will also change the state of the device and a GENA NOTIFICATION message will be sent, some time later, to the DDI Target indicating new values for all changed state variables. This in turn will lead to NotfyDdiChange messages, as described earlier, and ultimately to some visual change on the display of the DDI controller device.
  • Fig.6 illustrates the situation wherein there is no error, that is, the SOAP response that eventually gets issued by the UPnP device has return code OK.
  • the DdiTarget can use the AlertPanel facility in DDI to indicate failure to the user.
  • the 'alert panel' can contains a DdiText element holding the SOAP response ⁇ faultString> field. This is shown in Fig.7.
  • U.S. serial no. 09/165,682 (attorney docket PHA 23,484) filed 10/2/98 for Eugene Shteyn for CONTROL PROPERTY IS MAPPED ONTO MOD ALLY COMPATIBLE GUI ELEMENT relates to a home network system comprising an electronic device and a controller coupled to the device.
  • the device exposes an abstract representation of its functionality to the controller.
  • the controller enables controlling the device's functionality through interaction with the abstract representation.
  • the abstract representation specifies a modality of controlling the functionality. Under control of the modality specified, the system associates the controlling of the functionality with a modally compatible controlling capability of the controller.
  • the modality exposed can be, for example, "Boolean", "float”, “integer array”.
  • modality refers to an attribute that denotes the character of the controllability of the functionality.
  • the modality of the functionality is mapped onto a modaly compatible capability of the controller without the controller actually having to know what the functionality of the device is all about.
  • the modality is semantically a Boolean.
  • the Boolean control property can then be mapped onto a UI element that has a Boolean character and assumes one of two states such as an "on/off switch or "high/low” lever. When the user then interacts with this element, the functionality mapped onto it is put into one of the two states.
  • the abstract representation gets uploaded, preferably including a UI (for, e.g., voice control) or GUI, and the user receives a context to determine the consequences of his/her interactions with the UI.
  • the control property can be mapped onto a GUI element that can assume one of three or more discrete states such as a dial for channel selection on a device, for selection among multiple devices, etc.
  • the specified modality is semantically a range of floating-point values
  • a mapping is feasible onto a continuously variable control feature, e.g., brightness of an image on a display or sound volume.
  • the specified modality is semantically an array. An array comprises more than a single component.
  • an array of Booleans could thus be mapped onto a cluster of GUI elements to implement, e.g., a menu selection among different devices or a check box list.
  • An array of floating point modalities could be mapped onto a cluster of GUI elements that represent sliders, e.g., for adjusting a camera angles and zoom factors of camera's in the home security system that is controlled via the home network. Note that the controller does not need to have a clue about the functionality or functionalities of the device being controlled. All it needs to do is subjecting a functionality to a control application based on the semantics of its modality.
  • U.S. serial no. 09/160,490 (attorney docket PHA 23,500) filed 9/25/98 for Adrian Turner et al., for CUSTOMIZED UPGRADING OF INTERNET-ENABLED DEVICES BASED ON USER-PROFILE relates to a server system that maintains a user profile of a particular end-user of consumer electronics network-enabled equipment and a data base of new technical features for this type of equipment. If there is a match between the user-profile and a new technical feature, and the user indicates to receive information about updates or sales offers, the user gets notified via the network of the option to obtain the feature.
  • U.S. serial no. 09/189,535 (attorney docket PHA 23,527) filed 11/10/98 for Eugene Shteyn for UPGRADING OF SYNERGETIC ASPECTS OF HOME NETWORKS relates to a server that has access to an inventory of devices and capabilities on a user's home network.
  • the inventory is for example a look-up service as provided by HAVi or Jini architecture.
  • the server has also access to a data base with information of features for a network.
  • the server determines if the synergy of the apparatus present on the user's network can be enhanced based on the listing of the inventory and on the user's profile. If there are features that are relevant to the synergy, based on these criteria, the user gets notified.
  • U.S. patent 5,959,536 (attorney docket PHA 23,169) issued to Paul Chambers and Saurabh Srivastava for TASK-DRIVEN DISTRIBUTED MULTIMEDIA CONSUMER SYSTEM relates to a control system comprises multiple consumer electronics devices and task-driven control means coupled to the devices for controlling an interaction among the devices.
  • the control means acts on respective software representations of each respective one of the consumer devices.
  • By encapsulating the variable complexity of the task within a software representation it can be made as simple or as sophisticated as needed to bring the capabilities up to a common level. Since the level of interface is common to the devices, applications can uniformly manipulate devices which embody very different levels of sophistication.

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Computer And Data Communications (AREA)
  • User Interface Of Digital Computer (AREA)
  • Stored Programmes (AREA)
  • Small-Scale Networks (AREA)

Abstract

Selon cette invention, un réseau domestique comprend un groupe UPnP et un groupe HAVi. UPnP utilise des interfaces de dispositifs régies par programme et basées sur des messages standardisés envoyés entre les dispositifs. HAVi utilise également des interfaces régies par programme, mais a besoin de connaître le type de dispositif correct et FCMs à l'avance. De plus, les standards courants UPnP et HAVi ne définissent pas les dispositifs qui peuvent être facilement mappés l'un sur l'autre en raison de différences sémantiques. Pour surmonter ce problème, les groupes sont reliés par des ponts en représentant un dispositif UPnP sur le groupe HAVi, le document descriptif du dispositif UPnP étant utilisé pour générer une cible HAVi DDI afin de pouvoir commander à partir de l'interface utilisateur les dispositifs UPnP par une interface utilisateur HAVI.
PCT/EP2001/007898 2000-07-25 2001-07-09 Pont entre reseaux domestiques base sur une interface utilisateur WO2002009384A2 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP01965096A EP1293081A2 (fr) 2000-07-25 2001-07-09 Pont entre reseaux domestiques base sur une interface utilisateur
KR1020027003858A KR20020035644A (ko) 2000-07-25 2001-07-09 유아이-기반 홈 네트워크 브릿지
JP2002514977A JP2004505360A (ja) 2000-07-25 2001-07-09 Ｕｉベースのホームネットワークのブリッジング

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US62464800A 2000-07-25 2000-07-25
US09/624,648 2000-07-25

Publications (2)

Publication Number Publication Date
WO2002009384A2 true WO2002009384A2 (fr) 2002-01-31
WO2002009384A3 WO2002009384A3 (fr) 2002-11-21

Family

ID=24502782

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2001/007898 WO2002009384A2 (fr) 2000-07-25 2001-07-09 Pont entre reseaux domestiques base sur une interface utilisateur

Country Status (5)

Country Link
EP (1) EP1293081A2 (fr)
JP (1) JP2004505360A (fr)
KR (1) KR20020035644A (fr)
CN (1) CN1708969A (fr)
WO (1) WO2002009384A2 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1355136A2 (fr) * 2002-04-18 2003-10-22 Thomson Licensing S.A. Procédé de géneration d'une interface utilisateur graphique sur un dispositif HAVi pour commander un dispositif non-HAVi
EP1355485A1 (fr) * 2002-04-18 2003-10-22 Deutsche Thomson-Brandt Gmbh Méthode pour la génération d'un interface utilisateur sur un appareil HAVi pour le contrôle d'un appareil non-HAVi
WO2004066556A1 (fr) * 2003-01-23 2004-08-05 Thomson Licensing S.A. Mise a jour de parametres dans un reseau domestique multistandard relie
DE10339648A1 (de) * 2003-07-03 2005-01-20 Deutsche Thomson-Brandt Gmbh Verfahren zur Steuerung einer Netzwerkstation in einem Netzwerk eines ersten Typs von einer Netzwerkstation in einem Netzwerk eines zweiten Typs sowie Verbindungseinheit zur Verbindung der Netzwerke des ersten und zweiten Typs
EP1511228A1 (fr) * 2003-08-27 2005-03-02 Thomson Licensing, Inc. Procédé de commande des appareils reliés à un réseau hétérogène et dispositif mettant en oeuvre ce procédé
EP1617333A1 (fr) * 2003-04-24 2006-01-18 Mitsubishi Denki Kabushiki Kaisha Dispositif video, unite a module video, et procede d'exploitation du dispositif video
EP1665632A1 (fr) * 2003-09-23 2006-06-07 Lg Electronics Inc. Systeme de reproduction de contenus de medias a base upnp et procede associe
JP2007505388A (ja) * 2003-09-09 2007-03-08 コニンクリユケ フィリップス エレクトロニクス エヌ．ブイ． 制御インタフェースの選択
CN100345427C (zh) * 2003-10-01 2007-10-24 Lg电子株式会社 家庭网络系统与用以操作该系统的方法
KR100916030B1 (ko) * 2002-10-19 2009-09-08 엘지전자 주식회사 Ｄｄｉ 엘레멘트 표시장치
US7839528B2 (en) 2004-11-11 2010-11-23 Canon Kabushiki Kaisha Information acquiring method, information appending apparatus, information acquiring apparatus, and program
WO2013006013A2 (fr) * 2011-07-06 2013-01-10 Samsung Electronics Co., Ltd. Appareil et procédé de réalisation d'une interface d'utilisateur
CN101098964B (zh) * 2004-11-12 2013-03-20 诺维信阿德宁生物技术公司 具有抗微生物活性的多肽及编码该多肽的多核苷酸
EP2993831A1 (fr) * 2014-09-03 2016-03-09 BSH Hausgeräte GmbH Procede et dispositif de determination et d'affichage d'accessoires et de services pour appareils menagers en reseau

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100456457B1 (ko) * 2002-12-03 2004-11-09 한국전자통신연구원 유니버셜 플러그앤 플레이 전력선 통신 어댑터 장치 및 그제어방법
KR100984810B1 (ko) * 2004-02-02 2010-10-01 삼성전자주식회사 ＵＰｎＰ 디바이스가 ＰＬＣ 디바이스를 컨트롤할 수있도록 브릿징하는 장치 및 방법
KR100657001B1 (ko) * 2005-03-02 2006-12-19 엘지전자 주식회사 홈네트워크 제어 시스템
KR100745642B1 (ko) 2006-10-31 2007-08-02 삼성전자주식회사 ＵＰｎＰ 네트워크 시스템에서의 ＯＢＪＥ 네트워크 기기서비스 장치 및 그 방법
CN101505251B (zh) * 2008-02-04 2011-07-20 广达电脑股份有限公司 家用网络系统及其允入控制方法
CN102035760B (zh) * 2009-09-24 2012-12-05 北京闪联云视信息技术有限公司 家庭网络互联装置、家庭网络服务系统和设备发现方法
US20120096340A1 (en) * 2010-10-13 2012-04-19 Sony Pictures Technologies Inc. Reformatting web pages in bd platform
JP2020523162A (ja) * 2017-06-14 2020-08-06 インペディメッド・リミテッド 指標の決定

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999035753A2 (fr) * 1998-01-06 1999-07-15 Sony Electronics, Inc. Procede et systeme relatifs a un reseau audio-video
EP1058422A1 (fr) * 1999-06-02 2000-12-06 THOMSON multimedia Méthodes pour le pontage entre un sous-réseau de HAVi et un sous-réseau UPnP et le dispositif d'UPnP pour appliquer lesdites méthodes
WO2001001632A2 (fr) * 1999-06-25 2001-01-04 Koninklijke Philips Electronics N.V. Liaison entre plusieurs architectures logicielles de reseau domestique

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999035753A2 (fr) * 1998-01-06 1999-07-15 Sony Electronics, Inc. Procede et systeme relatifs a un reseau audio-video
EP1058422A1 (fr) * 1999-06-02 2000-12-06 THOMSON multimedia Méthodes pour le pontage entre un sous-réseau de HAVi et un sous-réseau UPnP et le dispositif d'UPnP pour appliquer lesdites méthodes
WO2001001632A2 (fr) * 1999-06-25 2001-01-04 Koninklijke Philips Electronics N.V. Liaison entre plusieurs architectures logicielles de reseau domestique

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"SPECIFICATION OF THE HOME AUDIO/VIDEO INTEROPERABILITY (HAVI) ARCHITECTURE" HAVI SPECIFICATION, XX, XX, November 1998 (1998-11), pages 1-25,1-196,198-280,282-384, XP002935300 *
.: "Universal Plug and Play Device Architecture, UPnP, Version 1.0" ., June 2000 (2000-06), XP002210614 *

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1297133C (zh) * 2002-04-18 2007-01-24 汤姆森许可贸易公司 在havi设备上产生控制非havi设备的用户接口的方法
EP1355485A1 (fr) * 2002-04-18 2003-10-22 Deutsche Thomson-Brandt Gmbh Méthode pour la génération d'un interface utilisateur sur un appareil HAVi pour le contrôle d'un appareil non-HAVi
EP1355136A3 (fr) * 2002-04-18 2004-03-10 Thomson Licensing S.A. Procédé de géneration d'une interface utilisateur graphique sur un dispositif HAVi pour commander un dispositif non-HAVi
EP1355136A2 (fr) * 2002-04-18 2003-10-22 Thomson Licensing S.A. Procédé de géneration d'une interface utilisateur graphique sur un dispositif HAVi pour commander un dispositif non-HAVi
KR100916030B1 (ko) * 2002-10-19 2009-09-08 엘지전자 주식회사 Ｄｄｉ 엘레멘트 표시장치
WO2004066556A1 (fr) * 2003-01-23 2004-08-05 Thomson Licensing S.A. Mise a jour de parametres dans un reseau domestique multistandard relie
US7984191B2 (en) 2003-01-23 2011-07-19 Thomson Licensing Updating parameters in a bridged multistandard home network
US7865622B2 (en) 2003-01-23 2011-01-04 Thomson Licensing Updating parameters in a bridged multistandard home network
EP2244422A1 (fr) 2003-01-23 2010-10-27 Thomson Licensing Mise à jour de paramètres dans un réseau domestique multistandard relie
CN100387009C (zh) * 2003-01-23 2008-05-07 汤姆森许可贸易公司 向第二类型网络中的网络站点提供改变的输入参数的方法
EP1617333A1 (fr) * 2003-04-24 2006-01-18 Mitsubishi Denki Kabushiki Kaisha Dispositif video, unite a module video, et procede d'exploitation du dispositif video
EP1617333A4 (fr) * 2003-04-24 2008-09-17 Mitsubishi Electric Corp Dispositif video, unite a module video, et procede d'exploitation du dispositif video
DE10339648A1 (de) * 2003-07-03 2005-01-20 Deutsche Thomson-Brandt Gmbh Verfahren zur Steuerung einer Netzwerkstation in einem Netzwerk eines ersten Typs von einer Netzwerkstation in einem Netzwerk eines zweiten Typs sowie Verbindungseinheit zur Verbindung der Netzwerke des ersten und zweiten Typs
FR2859341A1 (fr) * 2003-08-27 2005-03-04 Thomson Licensing Sa Methode de controle entre appareils connectes a un reseau heterogene et appareil implementant la methode
EP1511228A1 (fr) * 2003-08-27 2005-03-02 Thomson Licensing, Inc. Procédé de commande des appareils reliés à un réseau hétérogène et dispositif mettant en oeuvre ce procédé
JP2007505388A (ja) * 2003-09-09 2007-03-08 コニンクリユケ フィリップス エレクトロニクス エヌ．ブイ． 制御インタフェースの選択
EP1746777A3 (fr) * 2003-09-23 2010-06-02 LG Electronics Inc. Système de reproduction de données de média basées sur UPnP et procédé correspondant
EP1665632A4 (fr) * 2003-09-23 2010-06-02 Lg Electronics Inc Systeme de reproduction de contenus de medias a base upnp et procede associe
EP1665632A1 (fr) * 2003-09-23 2006-06-07 Lg Electronics Inc. Systeme de reproduction de contenus de medias a base upnp et procede associe
CN100345427C (zh) * 2003-10-01 2007-10-24 Lg电子株式会社 家庭网络系统与用以操作该系统的方法
US7839528B2 (en) 2004-11-11 2010-11-23 Canon Kabushiki Kaisha Information acquiring method, information appending apparatus, information acquiring apparatus, and program
CN101098964B (zh) * 2004-11-12 2013-03-20 诺维信阿德宁生物技术公司 具有抗微生物活性的多肽及编码该多肽的多核苷酸
WO2013006013A2 (fr) * 2011-07-06 2013-01-10 Samsung Electronics Co., Ltd. Appareil et procédé de réalisation d'une interface d'utilisateur
WO2013006013A3 (fr) * 2011-07-06 2013-04-11 Samsung Electronics Co., Ltd. Appareil et procédé de réalisation d'une interface d'utilisateur
EP2993831A1 (fr) * 2014-09-03 2016-03-09 BSH Hausgeräte GmbH Procede et dispositif de determination et d'affichage d'accessoires et de services pour appareils menagers en reseau

Also Published As

Publication number Publication date
KR20020035644A (ko) 2002-05-13
CN1708969A (zh) 2005-12-14
EP1293081A2 (fr) 2003-03-19
WO2002009384A3 (fr) 2002-11-21
JP2004505360A (ja) 2004-02-19

Similar Documents

Publication Publication Date Title
EP1293081A2 (fr) Pont entre reseaux domestiques base sur une interface utilisateur
EP1131919B1 (fr) Liaison entre plusieurs architectures logicielles de reseau domestique
US7111079B2 (en) Architecture of a bridge between a non-IP network and the web
KR100647449B1 (ko) 특성 루트를 통해서 소프트웨어 오브젝트들을 제어하기위한 시나리오를 식별하는 호출
EP1188291B1 (fr) Modele de commande de dispositif distant guide par donnees, avec adaptateur general de messagerie entre interface de programmation et reseau
US7089307B2 (en) Synchronization of controlled device state using state table and eventing in data-driven remote device control model
US7171475B2 (en) Peer networking host framework and hosting API
US7602756B2 (en) Dynamic self-configuration for ad hoc peer networking
EP1046259B1 (fr) Procede et systeme relatifs a un reseau audio-video
Moon et al. Design of a universal middleware bridge for device interoperability in heterogeneous home network middleware
US20030200340A1 (en) Method for generating a user interface on a HAVi device for the control of a Non-HAVi device
EP1351447A1 (fr) Gestion et contrôle d'appareils audio-vidéo en réseau
KR20040065571A (ko) Ｈａｖｉ-ｕｐｎｐ 브리징
WO2002001833A1 (fr) Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau
Baldus et al. WWICE: an architecture for in-home digital networks
EP1355136B1 (fr) Procédé de géneration d'une interface utilisateur graphique sur un dispositif HAVi pour commander un dispositif non-HAVi

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CN JP KR

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2002 514977

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 1020027003858

Country of ref document: KR

Ref document number: 018021573

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1020027003858

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2001965096

Country of ref document: EP

AK Designated states

Kind code of ref document: A3

Designated state(s): CN JP KR

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

WWP Wipo information: published in national office

Ref document number: 2001965096

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2001965096

Country of ref document: EP