JP2004505360A - Bridging UI-based home networks - Google Patents

Abstract

The home network includes a UPnP cluster and a HAVi cluster. UPnP uses a programmatic device interface based on standardized messages sent between devices. HAVi uses a programmatic interface, but needs to know the appropriate device type and FCM in advance. In addition, the current UPnP and HAVi standards do not define devices that can be easily mapped to each other due to semantic differences. To solve this problem, the cluster is bridged by representing the UPnP devices of the HAVi cluster. Here, the UPnP device description document is used to generate a HAVi DDI target, allowing UI-based control of the UPnP device through the HAVi UI.

Description

[0001]
[Field of the Invention]
The present invention relates to home networks, and more particularly, to bridging networks having clusters with different software architectures.
[0002]
[Background of the Invention]
It is unlikely that there is a single general applicable network standard for each device in the home. Multiple standards for software architecture coexist and new standards will emerge. New standard interfaces are developed for new device types specifically targeted by those standards.
[0003]
Home applications have been designed to make intelligent use of all devices available in the home. However, home applications cannot handle each of the network standards in use, nor will they be available in the future.
[0004]
Similarly, the devices themselves cannot support existing home network standards. For these reasons, bridges are needed between different subnetworks or clusters, each bridge corresponding to a particular respective standard.
[0005]
The bridge is responsible for transparently representing devices corresponding to a first standard in a first type of network cluster and corresponding to a second standard in a second type of network cluster. The result is a single integrated home network look that is available to software applications written for the first standard, as well as software applications written for the second standard.
[0006]
Home networking standards are generally directed to either a lower level protocol stack (to the transport level, eg, HomePNA, HomeRF), or an upper level protocol stack (from the transport level to the application level).
[0007]
In the remainder of this description, reference will generally be made to a second type of home network standard. Examples of these standards are HAVi, UPnP and Jini. Typically, home network standards provide one of two methods, programmatic control and user-interface (UI) -based control for an application (ie, client) to a controller (ie, server).
[0008]
Programmatic control refers to control based on sending a standardized message to a device, that is, control based on calling a standardized API and consequently sending a message to the device. This type of control is useful for applications that control the device without the required direct user interaction. In this case, both the controller and the controllable device use a predetermined set of exchangeable messages. That is, the controller must know in advance the type of device that can be controlled.
[0009]
UI-based control refers to control using sending user interaction from a control device to a controllable device. Here, the user interacts with the UI client, that is, the browser, and sends a message to the UI server of the controllable device according to the user's action.
[0010]
Messages are exchanged using a specific UI protocol, examples of which are HTML (used in UPnP) and DDI (used in HAVi). The acronym "DDI" stands for Data Driven Interaction and refers to the protocol that runs between the application or DCM whose user interface needs to be displayed and the display device.
[0011]
The DDI target is part of the device's DCM. The acronym “DCM” stands for Device Control Module. DCM is a software element and represents a single device or function on a HAVi network. The DCM makes the HAVi defined API visible for the device.
[0012]
DCM is dynamic in nature. When a device is inserted or removed from the network, the DCM for that device needs to be attached or removed from the network. DCM is at the heart of the HAVi concept and a source of flexibility in accommodating new devices and features in HAVi networks. DDI supports user interaction with devices.
[0013]
Essentially, the UI protocol does not define the type of information or control conveyed by the protocol, how it encompasses the user's actions, and how the client's actions are transmitted from the client to the server. It only defines whether to send to.
[0014]
In addition, the UI protocol defines how user interface elements (or referred to as small devices "Widgets") are described and how they are sent back from the server to the client for display purposes. This means that UI-based control is possible without the controller application knowing the type of device that can be controlled.
[0015]
The controller and the controllable device communicate using the same UI protocol, and can control the controllable device as long as the user is present. In addition, the UI protocol allows a device to provide capabilities beyond the capabilities of a standardized device type. In other words, the UI protocol allows a standardization device to distinguish itself from conflicts.
[0016]
[Summary of the Invention]
When bridging controls between home network standards, the approach of the present invention is to use the standard A second software architecture of standard B, which differs from the standard A, from the device type programmatic interface in the first software architecture of standard A. From the device type programmatic interface in the standard B second software architecture to the device type programmer in the standard A first software architecture different from the standard B Is to convert to a tick interface.
[0017]
Similarly, the approach of the present invention translates the UI type of the device type in standard A into the UI type of the device type in standard B, and vice versa. To a UI interface of the type The inventor has analyzed the bridging in more detail so that a problem is associated with this approach and provides a solution.
[0018]
FIG. 1 is a conceptual diagram that clarifies that there are more than these options. The conceptual diagram of FIG. 1 shows a part of a home network 100 having a cluster 102 based on a software architecture based on the standard A and a cluster 104 based on a software architecture based on the standard B.
[0019]
Network 100 has certain Type X devices 106 that reside on network 100 in cluster 102. Clusters 102 and 104 will be bridged so that device 106 can be controlled from cluster 104 through a software representation (type X bridged device) 108.
[0020]
It is assumed that the device 106 and its representation 108 in the cluster 104 can have, in principle, UI-based control interfaces 110 and 112, respectively, and programmatic control interfaces 114 and 116, respectively. In the conceptual diagram, four bridging options 118, 120, 122 and 124 are listed.
[0021]
Bridge 118 provides a conversion from UI interface (UI) 110 to programmatic interface (PROGR) 116. As mentioned above, the UI interface is more flexible (or not standardized) than the programmatic interface.
[0022]
Therefore, conversion from the UI interface to the programmatic interface is very difficult, and is not possible for existing home network standards such as HAVi and UPnP. This leaves three other options.
[0023]
The bridge 120 is for converting the UI interface 110 of the standard A into the UI interface 112 of the standard B. Whether this transformation is feasible depends on the similarity of standards A and B.
[0024]
For example, it is very difficult to convert a UPnP device UI to a HAVi device UI because UPnP can add any kind of script in the device UI to HTML. HAVi uses the DDI protocol for the device UI, HTML can be converted to DDI, and converting scripted HTML is not feasible.
[0025]
The bridge 122 is for converting the standard A programmatic interface 114 into the standard B programmatic interface 116. Whether this conversion is possible or not depends largely on the domains covered by standards A and B.
[0026]
For example, if UPnP defines the light valve's programmatic interface and HAVi does not define the light valve's “semantically equivalent” programmatic interface, then this device type cannot be bridged in a programmatic way. .
[0027]
The bridge 124 is for converting from the programmatic interface 114 in the standard A to the UI interface 112 in the standard B. This type of conversion requires that the device's programmatic interface in standard A be available at runtime as data for conversion. This requires a "white box" device description mechanism, allowing the application to recover at run time all information about the device's interface.
[0028]
In other words, the application does not need to rely on the built-in knowledge of the device type interface, and can recover this knowledge at runtime. This type of conversion further requires that the data types used in the programmatic interface be mapped as "formally compatible" GUI elements.
[0029]
In this context, pending US patent application Ser. No. 09 / 165,682 (Attorney Docket No. PHA23,484) filed on Feb. 1, 1998 by Eugene Shteyn, entitled "CONTROL PROPERTY IS MAPPED ONTO MODULY COMPATIBLE GUIDE ELEMENT". Please refer to.
[0030]
The conversion from a programmatic interface in standard A to a UI in standard B further requires that a set of formally compatible GUI elements be supported by the standard B UI mechanism. It also requires that the abstraction level of the programmatic interface be suitable for user-level interactions.
[0031]
All of the above transformations may coexist in a bridge implementation. In fact, the bridge should represent devices in other networks in as many ways as possible, because it does not know which interface is most suitable for the application / user on the other side of the bridge.
[0032]
The present invention is based on the insight that a translation from a programmatic interface in standard A to a UI in standard B can be used as a bridge. In the following, requirements are discussed for both standards involved for this bridging to work. Embodiments are provided below with bridge options in the form of a change scheme from a UPnP programmatic interface to a HAVi device UI (DDI target).
[0033]
The invention relates to a method for enabling a bridge between a first cluster of a first function and a second cluster of a second function. The first cluster has a first software architecture that provides control of a first function through a programmatic interface. UPnP is an example of such an architecture. The second cluster has a second software architecture that provides control of a second function through a UI-based interface. HAVi is an example of the latter architecture. The method in the present invention comprises providing a translation from a programmatic interface to a UI-based interface. In the UPnP-HAVi example, the method comprises generating a HAVi DDI target software element from the UPnP device description document.
[0034]
The method of the present invention can be implemented by a service provider. The user notifies the service provider that a new device has been added to his / her network, and in response, the provider creates a conversion module that is installed on the user's network as part of the bridge. Can be.
[0035]
The invention also relates to a home network having these clusters using different software architectures. The first cluster has a first software architecture that provides control of a first function through a programmatic interface, and the second cluster provides control of a second function through a UI-based interface. It has a second software architecture. The network has a bridge between the first cluster and the second cluster to convert a programmatic interface to a UI-based interface. Preferably, the network comprises a generator for generating a HAVi DDI target from a UPnP device description document.
[0036]
One aspect of the present invention resides in bridging software for use in a home network. The bridging network comprises a first cluster of a first function and a second cluster of a second function. The first cluster has a first software architecture that provides control of a first function through a programmatic interface, and the second cluster provides control of a second function through a UI-based interface. It has a second software architecture. Bridging software operates to combine the first cluster with the second cluster based on converting the programmatic interface to a UI-based interface. The software includes a generator for generating a HAVi DDI target from a UPnP device description document in a UPnP-HAVi network.
[0037]
[Embodiment of the invention]
The present invention will be described in detail by way of example with reference to the accompanying drawings. Throughout the drawings, the same reference numerals indicate the same or corresponding functions.
The UPnP standard defines a device's programmatic interface through an XML document called a "description document". Applications can retrieve this document at runtime through HTTP, and UPnP thus satisfies the "white box" criteria.
[0038]
HAVi defines a device's programmatic interface through the generation of an API expressed in IDL. The API definition is tied to a unique identifier called the FCM type. The acronym "FCM" stands for Functional Component Module. The DCM (see above) includes an FCM for each controllable function in the device being represented.
[0039]
Currently, HAVi defines FCMs and corresponding APIs for features such as tuners, VCRs, HDD-based storage, AV displays, cameras and modems. At runtime, the HAVi application can retrieve this FCM type from controllable devices and control the device programmatically based on embedded information about the interface linked to the FCM type. HAVi does not satisfy the "white box" criteria because the HAVi application needs to know in advance the interface linked to the FCM type.
[0040]
In Jini, applications search for a device's programmatic interface by using a lookup service that sends back a remote (RMI) with reference to the device's Java object representation. Java (R) RMI (Remote Method Invocation) is used to generate control commands to the controlled device. Java has the capability for "reflection" so that at runtime, the interface (in terms of Java (R) member variables and methods) of a remote object (device) reference can be determined. Therefore, Java (R) satisfies the "white box" criteria.
[0041]
The UPnP device programmatic interface uses one of the following types: Boolean, integer (called i4), floating point (called r8), string, date time (data and time information) or HEX encoded binary data (called bin.hex or bin.bin64).
[0042]
These types can be mapped in a simple manner to common GUI elements found in most UI protocols, including DDI (used in HAVi) and HTML (used in UPnP). Please refer to FIG. 2A and FIG. 2B. Jini does not define a UI protocol for a particular device.
[0043]
The Jini device's programmatic interface may use any Java object. The HAVi device's programmatic interface may use any IDL type. Therefore, the interfaces of HAVi and Jini devices generally cannot be easily mapped to a UI.
[0044]
Of course, one can imagine that for certain device types that use a subset of the rich data types, such as IDL or Java, UI mapping is possible. For example, UI mapping can be implemented for a Jini interface using only basic Java (R) types (without Java (R) objects). In short, defining a broad translation from the programmatic interface of a UPnP device to a DDI UI in HAVi seems to be most valuable.
[0045]
[Convert UPnP Programmatic Interface to HAVi DDI UI] The programmatic interface of the UPnP device is described in the description document. This document specifies a root device that has zero or more (sub) devices. Each device has another list of sub-devices and the like. Devices without any sub-devices ("leaves" in the tree) contain one service.
[0046]
The service is composed of a list of state variables (State Variable, see FIG. 2) and a list of actions. Services have no subservices. The state variable has a “name” field, a “type” field, and an optional field that limits the range of the type. Actions have a "name" field and a list of parameters.
[0047]
Each parameter is described by a “name” field and a field called “related state variable“ related State Variable ””. This field must refer to the state variable name and indirectly defines the type of the action parameter. An aspect of the present invention is to generate a HAVi DDI target from a UPnP device description document. The transformation involves both the static and the dynamic aspects of the DDI target.
[0048]
For the static aspect, DDI elements (DDI ELEMENT, see FIG. 2) or widgets need to be defined for UPnP data types (UPnP DATA TYPE). The organization of all DDI elements corresponding to UPnP services needs to be defined. The organization of all DDI elements corresponding to a UPnP device needs to be defined.
[0049]
For the dynamic aspect, DDI navigation between devices and services needs to be defined. The start and end of a "session" between the application and the device needs to be defined. The effect of the asynchronous change on the controlled UPnP device needs to be defined, and the effect of the user action sent to the generated DDI target needs to be defined. These aspects are described in detail below.
[0050]
[Static: Convert UPnP data type to HAVi DDI element]
UPnP data types occur in two ways in service descriptions. In other words, it is directly the type of the state variable, and indirectly through reference to the <related state variable> for the action parameter.
[0051]
Some DDI elements are "interactive". Users can interact with those DDIs. For example, buttons are interactive and text labels are not. Depending on the context, the interactive DDI element may be "temporarily" non-interactive, or disabled. To express this, interactive DDI has an "interactivity" field.
[0052]
Since UPnP allows state changes only through actions, the DDI element representing the action parameter sets this field to ENABLED. However, the DDI element representing the current value of the device state variable will set this field to DISABLED.
[0053]
The UPnP data type may have additional specifiers (ADD.SPECIFIERS, see FIG. 2) indicating certain restrictions on the range of values to keep. This additional specifier can be used to generate a more appropriate DDI element in some cases.
[0054]
[Static: Convert UPnP service to DDI structure]
A service is composed of a list of state variables and a list of actions. The state variable has a "name" field, a "type" field, and an optional field for limiting the range of the type. An action has a "name" field and a parameter list. Each parameter is described by a field called a "name" field and a "relational state variable". This field must refer to the state variable name and indirectly defines the type of the action parameter.
[0055]
In DDI, elements are organized into groups to indicate some kind of binding to the DDI display engine (called a Ddi controller). This combination may be used to determine the organization of the elements on the screen or may be used to determine navigation.
[0056]
The UPnP service can be converted into the following DDI structure.
A DdiPanel element with a PanelName set in the <serviceType> field of the service. DdiPanel includes two DdiGroup elements and a DdiPanelLink element. DdiGroup element with groupName set to "State Variable" State Variable "". The "element" field of this group should contain the DDI element obtained from transforming all UPnP state variables according to the type mapping described above. All of these Ddi elements should have an interactive attribute set to DISABLED.
A DdiGroup element with groupName set to "Action". The "element" field of this group contains a DdiGroup element for each individual UPnP action.
[0057]
Each of these DdiGroup elements includes:
A DdiButton element in which both the “press label“ pressedLabel ”” and the “release label“ releasedLabel ”” fields are set in the <name> field of the action. This element represents initiating a UPnP device action.
A Ddi element for each input parameter of the action according to the type mapping applied to the <relational state variable> of the action parameter. All of these Ddi elements should have an interactive attribute set to DISABLED.
A Ddi element for each output parameter of the action according to the type mapping applied to the <relational state variable> of the action parameter. All of these Ddi elements should have an interactive attribute set to ENABLED.
The DdiPanelLink element indicates that the “parent“ parent ”” device is its LinkName field set in the <deviceType> or <FriendlyName> field of the parent device. Optionally, it may also have a linkBitMap field set to one of the available and HAVi compatible <icon> values in the description of the parent device.
[0058]
[Static: Convert UPnP device to DDI structure]
The device description document in UPnP usage defines a root device with zero or more (sub) devices. Each device may have another list of sub-devices or the like. In addition, each device has certain fields associated with it, such as device icons, manufacturer names, and the like.
[0059]
The (root or sub) device is converted to a DDI structure as follows.
A DdiPanel with a panelName set in the device's <deviceType> or <friendlyName> field. The DdiPanel includes a DdiPanelLink element, one for each sub-device or service included in the DdiPanel.
A DdiPanelLink element that represents a sub-device should have its linkName field set to the <deviceType> or <friendlyName> field of the sub-device. Optionally, it may also have a linkBitMap field set to one of the available and HAVi compatible <icon> values in the device description.
The DdiPanelLink element representing a service should have a linkName field set in the service's <serviceType> field.
[0060]
Each non-root sub-device should have:
The DdiPanelLink element representing the "parent" device is its linkName field set in the <deviceType> or <friendlyName> field of the parent device. Optionally, it can have a linkBitMap field set to one of the available and compatible <icons> in the device description.
All DdiPanelLinks should have an interactivity field set to ENABLED. Optionally, the panel can include a DdiText element, the interactivity field is set to DISABLED, and the textContent field holds a string value for any of the following UPnP device description fields.
<DeviceType>;
<FriendlyName>;
<ModelDescription>;
<ModelName>;
<ModelNumber>;
<Model URL>;
<Manufacturer>;
<Manufacturer URL>;
<SerialNumber>;
<UDN>;
Finally, the panel can have a DdiIcon element set to one of the available and compatible <icon> values in the device description.
[0061]
FIG. 3 shows an exemplary UI provided by the DDI controller from the DDI target thus constructed.
FIG. 3 is a diagram showing a part 300 of the home network 100. The network 100 has a TV / VCR combo and two sub-devices, a root device 302, a TV 304 and a VCR 306. The TV 304 has three services: an audio service (AUDIO) 308, a video service (VIDEO) 310, and a tuner service (TUNER) 312. The VCR 306 also has three services: a clock service (CLOCK) 314, a tuner service (TUNER) 316, and a tape service (TAPE) 318.
[0062]
In this example, “My BedRoom Fun” is indicated in the <friendlyName> field, and “PHILIPS” is indicated in the <manufacturer (manufacturer)> field. Also, “AZ1010” is shown in the <modelName (model name)> field, “19 TV / VCR COMBO” is shown in the <modelDescription (model description)> field, and a picture of TV is shown in the <icon> field. Have been.
[0063]
The tape service 318 shows a string state variable 320 named “Transport” with the <AllowedValueList> specifier {“playback“ playing ””, “stop“ stopped ””, “recording“ recording ””}. Further, three actions “ACTIONS” of “playback“ Play ””, “stop“ Stop ””, and “recording“ Rec ”” are shown, and the “Rec” action is represented by an <AllowedValueList> specifier “standard standard "," long "long", "extended"} have one string parameter associated with a state variable (not shown).
[0064]
[Dynamic: Device UI operation]
As mentioned above, each (root or sub) device and each service is mapped to a separate DdiPanel element. The DdiPanelLink element is used to pass from the root device to the service through zero or more intermediate sub-devices.
[0065]
In addition, for each level except the root device level, the DdiPanelLink element is used to navigate in the device hierarchy. When the user of the DDI controller device clicks on the panel, the type ACT_SELECTED is sent to the DDI target.
[0066]
The DDI target should respond to the type ACT_SELECTED by sending back a targetDevice representing the subdevice / service (if operating down the hierarchy) or the parent device (if operating up the hierarchy). It is. DDI targets do not require communication with the UPnP they represent.
[0067]
[Dynamic: Session start / end]
FIG. 4 shows a session between a DDI controller and a general-purpose DDI target. After the DDI target receives the DDI subscription in step 402, in step 404, the DDI target searches for a UPnP description document. Based on the descriptive document, in step 406, the DDI target can build a DdiPanel structure, like all the DdiElements it contains.
[0068]
Further, in step 408, the DDI target subscribes to the UPnP device state change using the GENA mechanism. “GENA” represents Generic Eventing Notification with UPnP context. Eventing is the source device's ability to optionally initiate a connection to one or more other devices that are willing to receive events from the source device.
[0069]
Events are used to establish synchronization between multiple devices. Within UPnP, events are mainly used for asynchronous notification of state changes. TCP / IP provides connection support for conveying event information. GENA adds conventions to establish a relationship between the device of interest and an addressing scheme to enable the transmission of event messages. GENA uses HTTP-specified addressing and encryption. A separate subscription in step 410 is required for each service.
[0070]
Because GENA SUBSCRIBE sends back the current values of all state variables, the DDI target is synchronized with the UPnP device, and the correct values are used when the DDI controller requests the correct values of all DDI elements. You can send it back. The DDI target subscribes to a state change immediately after the descriptive document has been retrieved (above), or immediately after the DDI controller has requested a panel containing the state variable values.
In step 412, after the DDI target receives the DDI unsubscription, in step 414, the DDI target unsubscribes itself from a change in state variable.
[0071]
[Dynamic: Asynchronous change in UPnP device]
When a session is established between the DDI controller and the DDI target, it is possible to change the device state in an asynchronous manner through other controls. This may be another HAVi or UPnP application, or a user pressing a physical button on a manual control panel of a physical device. This scenario is schematically illustrated in FIG.
[0072]
[Dynamic: User action in DDI controller]
FIG. 6 shows the messages that occur when a user interacts with a UPnP device through the display of the device running the DDI controller. In the operation mode, the user first changes the widgets corresponding to the action parameters, and presses a button for activating the action of the device when the user changes the widgets.
[0073]
The result of the action includes output parameters and is shown using widgets to be "disabled" or "non-interactive mode". These will be "UserAction" messages sent to the DDI target. This target forwards these interactions to the UPnP device, rather than using them to locally update the parameter values represented by widgets. When the user transfers, he / she presses a button that represents a device action.
[0074]
For DdiButton's release "RELEASE" event, the DDI target constructs a SOAP (Simple Object Access Protocol) request using the current parameter values and sends the request to the UPnP device. The SOAP action is performed dynamically, and when the action is successfully performed, the DDI target completes the user action by sending back the DDI "change report" for output parameters widgets, if any.
[0075]
With respect to SOAP, this is a protocol created by contributions from many industry partners, which allows applications to use, for example, the Internet, which provides a framework for connecting Web sites and applications to create Web services. Can communicate with one another. The Web service links a site and an application to each other, and executes a function that cannot be performed by only individual elements.
[0076]
Typically, actions initiated on the controlled device also change the state of the device, and a GENA NOTIFICATION message is sent to the DDI target indicating new values for all changed state variables. This in turn causes NotifyDdiChange messages as described above, and ultimately causes some visual change in the display of the DDI controller device.
[0077]
FIG. 6 shows a state in which no error exists, that is, a state in which the SOAP response finally generated by the UPnP device has a return code OK. In the case of an error, DdiTarget can indicate failure to the user using the AlertPanel function in DDI. The “alert panel” may include a DdiText element holding a SOAP response <faultString> field. This is shown in FIG.
[0078]
In U.S. Patent Application Serial No. 09 / 165,682 (Attorney Docket No. PHA23,484), "CONTROL PROPERTY IS MAPPED ONTO MODULY COMPLIABLE GUIDE ELEMENT", filed February 10, 1998 by Eugene Shteyn, is an electronic device. And a home network system comprising a controller coupled to the device. The device makes the abstract representation of its functionality visible to the controller. The controller allows controlling the functionality of the device through interaction with the abstract representation. Abstract expressions specify the mode of control of functionality. Under the prescribed mode of control, the system associates functional control with the formal compatible control capabilities of the controller. The styles that can be seen can be, for example, “Boolean”, “Float”, “Integer array”.
[0079]
The term "modality" refers to attributes that characterize the control of functionality. In the present invention, the mode of functionality is mapped to the formally compatible capabilities of the controller without having to know which functions of the device are all. For example, suppose the style is semantically Boolean. A Boolean control property has a Boolean property and can be mapped to a UI element that assumes one of two states, such as an "on / off" switch or a "high / low" lever. .
[0080]
When a user interacts with this element, the functionality mapped to this element performs one of two states. In the HAVi system, an abstract representation is uploaded, preferably including a UI (eg, voice control) or GUI, and the user receives context to determine the outcome of his / her interaction with the UI.
[0081]
If the modality is a set of discrete values, the characteristics of the control may assume one of three or more discrete states, such as a dial for channel selection of a device, a dial for selection between multiple devices. Can be mapped to a possible GUI element. If the particular modality is semantically a range of floating point values, the mapping can be performed, for example, with respect to continuously variable control features such as brightness or volume of the image on the display.
[0082]
In another example, the specified format is a semantic sequence. The array comprises one or more components. For example, an array of Boolean algebras may be mapped to a cluster of GUI elements, for example, to implement a menu selection or checkbox list between different devices.
[0083]
The floating point style arrangement can be mapped to a GUI element representing a slider for adjusting the camera angle and camera zoom element in a home security system controlled via a home network, for example. Note that the controller need not have any clue as to the functionality of the device being controlled. What the controller needs is to make the functionality dependent on the control application based on the semantics of the modality.
[0084]
In U.S. Patent Application Serial No. 09 / 340,272 (Attorney Docket No. PHA23,634), "BRIDGING MULTIPLE HOME NETWORK SOFTWARE ARCHITECTURE", filed on June 25, 1999 by Eugene Stheyn, is a home network of different software architectures. Regarding bridging.
For the first network, references to software representations of devices and services are created automatically. The reference is semantically sufficient to enable automatic creation of at least a portion of a function equivalent to a software representation of the second network, and to remove devices and services of the first network from the second network. Make it accessible. This document specifies addresses for HAVi, home API and Jini software architecture.
[0085]
In U.S. Patent Application Serial No. 09 / 160,490 (Attorney Docket No. PHA23,500), "CUSTOMIZED UPGRADING OF INTERNET-ENABLED DEVICE BASED ON USER-PROFILE", filed September 25, 1998 by Adrian Turner, Consumer electronics network-enabled equipment and a server system that maintains a specific end-user user profile consisting of a database of new technical features for this type of device.
If there is a match between the user profile and the new technical feature, it indicates that the user will receive information about updates or sales offers, and the user will be notified via a network of options for obtaining the feature. Is done.
[0086]
In U.S. Patent Application Serial No. 09 / 189,535 (PHA23,527), "UPGRADING OF SYNERGETIC ASPECTS OF HOME NETWORKS," filed November 10, 1998, by Eugene Shtey, provides access to device inventory, and It relates to a server having the capability for the user's home network.
Inventory is, for example, a lookup service as provided by the HAVi or Jini architecture. In addition, the server has access to a database having information of functions for the network. The server determines whether the interaction of the devices present on the user's network is scalable based on the inventory list and the user's profile. If a function related to synergy exists, the user is notified based on these criteria.
[0087]
U.S. Pat. No. 5,959,536 (Attorney Docket No. PHA23,169) filed by Paul Chambers and Saurab Srivastava on Nov. 10, 1998, entitled "TASK-DRIVEN DISTRIBUTED MULTIMEDIA CONSUMER SYSTEM," Consumer electronic devices and a control system comprising task-driven control means connected to the devices for controlling interaction between the devices.
The control means operates on a respective software representation of each one of the consumer devices. By encrypting the variable complexity of the tasks in the software representation, the variable complexity can be simplified or refined as required to increase performance to a common level. Because the level of interface is common to devices, applications can uniformly operate devices that implement very different levels of sophistication.
[Brief description of the drawings]
FIG.
FIG. 4 is a block diagram illustrating options for bridging.
FIG. 2A
FIG. 4 is a diagram illustrating a table based on UPnP and HAVi information items referred to through the embodiment of the present invention;
FIG. 2B
FIG. 4 is a diagram illustrating a table based on UPnP and HAVi information items referred to through the embodiment of the present invention;
FIG. 3
It is a figure by a part of home network.
FIG. 4
FIG. 3 is a diagram illustrating an interaction between a UPnP cluster and a HAVi cluster in a home network.
FIG. 5
FIG. 3 is a diagram illustrating an interaction between a UPnP cluster and a HAVi cluster in a home network.
FIG. 6
FIG. 3 is a diagram illustrating an interaction between a UPnP cluster and a HAVi cluster in a home network.
FIG. 7

Claims (9)

A method enabling bridging a first cluster of a first function and bridging a second cluster of a second function, the method comprising:
The first cluster has a first software architecture that provides control of the first function through a programmatic interface, and the second cluster has control of the second function through a UI-based interface. Having a second software architecture to provide;
Providing a translation of the programmatic interface to the UI-based interface. The first software architecture corresponds to UPnP, and the second software architecture corresponds to HAVi;
The method of claim 1. The step of providing includes generating a HAVi DDI target software component from a UPnP device description document.
The method of claim 2. A first cluster of a first function;
A second cluster of second functions,
The first cluster has a first software architecture that provides control of the first function through a programmatic interface, and the second cluster has control of the second function through a UI-based interface. Having a second software architecture to provide;
A home network having a bridge between the first cluster and the second cluster for converting the programmatic interface to a UI-based interface. The first software architecture corresponds to UPnP, and the second software architecture corresponds to HAVi;
The network according to claim 4. The providing step includes a generator for generating a HAVi DDI target software component from a UPnP device description document.
The network according to claim 5. Bridging software for use in a home network including a first cluster of a first function and a second cluster of a second function, comprising:
The first cluster has a first software architecture that provides control of the first function through a programmatic interface, and the second cluster has control of the second function through a UI-based interface. Having a second software architecture to provide;
Operative to couple the first software and the second software based on converting the programmatic interface to the UI-based interface;
Bridging software. 8. Bridging software according to claim 7, for combining the first software architecture corresponding to UPnP and the second software architecture corresponding to HAVi. 9. The bridging software of claim 8, including a generator for generating a HAVi DDI target software component from a UPnP device description document.

Images