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)
• Computing Systems (AREA)
• Multimedia (AREA)
• Computer And Data Communications (AREA)
• User Interface Of Digital Computer (AREA)
• Small-Scale Networks (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=24502782

Family Applications (1)

Country Status (5)

Families Citing this family (22)

Family Cites Families (3)

• 2001
  • 2001-07-09 WO PCT/EP2001/007898 patent/WO2002009384A2/en not_active Application Discontinuation
  • 2001-07-09 KR KR1020027003858A patent/KR20020035644A/ko not_active Application Discontinuation
  • 2001-07-09 CN CNA018021573A patent/CN1708969A/zh active Pending
  • 2001-07-09 JP JP2002514977A patent/JP2004505360A/ja active Pending
  • 2001-07-09 EP EP01965096A patent/EP1293081A2/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events