EP1307998A2 - Liaison par pont entre reseaux locaux multistandards avec serveur - Google Patents

Liaison par pont entre reseaux locaux multistandards avec serveur

Info

Publication number
EP1307998A2
EP1307998A2 EP01958011A EP01958011A EP1307998A2 EP 1307998 A2 EP1307998 A2 EP 1307998A2 EP 01958011 A EP01958011 A EP 01958011A EP 01958011 A EP01958011 A EP 01958011A EP 1307998 A2 EP1307998 A2 EP 1307998A2
Authority
EP
European Patent Office
Prior art keywords
cluster
bridge
server
software
havi
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
EP01958011A
Other languages
German (de)
English (en)
Inventor
Jan R. Moonen
Yevgeniy E. Shteyn
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
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 NV filed Critical Koninklijke Philips Electronics NV
Publication of EP1307998A2 publication Critical patent/EP1307998A2/fr
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • 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
    • 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/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
    • 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

Definitions

  • the invention relates to the bridging of multiple networks based on different software architectures.
  • the invention relates in particular to home networking.
  • 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.
  • a device on a network is controlled through a set of messages complying with the interface of the device. Interoperability between devices and software applications depends upon standard interfaces with a unique identification. Once an application knows the unique identification of the device, it knows the interface of the device and it can control the device by sending it messages. To the application it makes no difference whether it is sending standard messages directly to the device itself, or indirectly via a software component that translates these messages into a different set of message that (eventually) achieve the same desired effect or state change at the controlled device. Hence, a bridge between networks of multiple different standards can be considered a multi-standard device.
  • the bridge complies with each of these multiple standards, and hosts software components that translate device interfaces from a first to a second standard and vice versa.
  • a bridge is used between a cluster of five devices complying with a standard A and three devices complying with a standard B, different from A.
  • the bridge hosts three translation modules for translating from A to B and five translation modules for translating from B to A. Accordingly, a software application capable of interacting with only standard A devices can now control all eight devices.
  • software representation i.e., the representation in software of a physical device or of a service on a network or a sub-set thereof so as to make the device or service accessible to the relevant messaging or controlling software.
  • a bridge performs the following functions: detection of the addition of a device in either of the bridged networks; identification of the type of the added device; locating the translation module for the identified device type if the device is likely to be of interest to the other network; and installing the translation module on the other network according to the procedure required by the standard used by that network.
  • a bridge is unable to contain all embedded translation modules for all possible, relevant devices that become available in the future.
  • the inventors propose a solution wherein a bridge is connected to a server, e.g., on the Internet.
  • This server offers a lookup service for some set of standards, and allows a bridge to locate and download the appropriate translation modules for use in the home network.
  • the invention relates to a method of providing a service to a user of a home network.
  • the method comprises enabling a component of a first cluster in the network to interact with a second cluster of the home network.
  • the first cluster has a first software architecture
  • the second cluster has a second software architectures different from the first one.
  • the first and second clusters are coupled through a bridge.
  • the method comprises enabling a server external to the clusters, e.g., on the Internet, to receive a reference of a component having a first software representation in the first cluster.
  • the bridge may provide this reference.
  • the method further comprises enabling to provide to the bridge a translation module, associated with the reference, for at least partially representing the component on the second cluster upon the module being installed on the bridge.
  • a service provider thus can maintain and update a data base of translation modules for any multiple standards being used in home networks. This partitioning and delegation of functionalities has many advantages as discussed below.
  • the invention allows the bridge to be fairly "light-weight” or low-cost, as it does not need to have embedded translation modules for all possible devices of all standards that it could be connected to in the home. Storage and computation power is only needed for the devices that are actually bridged (i.e., storage is not needed for the ones that are potentially bridged), and only when they are bridged (e.g., "just-in-time”-bridging, i.e., at the time of connecting the new device to the network). Further, the invention renders the home network as a whole extensible and future-proof.
  • the bridge-server operator is able to obtain information about the configuration of the individual user's home network. This information can be used to the advance of both the user and the manufacturers and service providers. See, for example, U.S. Serial No. 09/160,490 (attorney docket PHA 23,500) filed 9/25/1998 for Adrian Turner et al., for CUSTOMIZED UPGRADING OF INTERNET-ENABLED
  • 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. In this sense, U.S. serial no. 09/189,535 relates to the concept of an "application suggestor".
  • a further advantage of the invention resides in the fact that the server operator is enabled to measure market demands for particular devices to be bridged to a specific standard. The device manufacturer or another relevant third party can be notified of the emerging demand. When the new translation modules become available on the server, bridges that have sent requests for translation modules in the past with which the server could not comply, can now be notified of an upgrade.
  • the bridge can be implemented as a software component on a device of a specific cluster on the home network in order to provide a bridge to another cluster.
  • a HAVi set top box can have a software component for bridging the HAVi cluster to, e.g., a UPnP cluster on the network.
  • a PC that controls the UPnP cluster can have a software component that serves to bridge the UPnP cluster of the home network to the HAVi cluster.
  • Fig.l is a block diagram illustrating the principle of the bridging between two networks according to the invention.
  • Fig.2 is a block diagram illustrating bridging HAVi to UPnP
  • Fig.3 is a block diagram illustrating bridging UPnP to HAVi.
  • same reference numerals indicate similar or corresponding features.
  • an aspect of the invention relates to connecting a bridge to a server, e.g., on the Internet.
  • This server offers a lookup service for some set of standards, and allows a bridge to locate and download the appropriate translation modules in the home network that eventually enables a device on a sub-network of a first architecture to work with devices on a sub-network of a second architecture.
  • Fig.l is a diagram of a home network system 100 with a first cluster 102 of devices 104, 106 and 108 that comply with a first software architecture standard, herein-after called standard A.
  • System 100 comprises a second cluster 110 of devices 112, 114 and 116 that comply with a second software architecture standard, herein-after called standard B.
  • Clusters 102 and 110 are interconnected through a bridge 118.
  • translation modules are introduced. These modules need to participate in both clusters 102 and 110.
  • the modules typically need components local to the clusters, such as lower-level communication software, in order to be capable of this participating. Rather than having each translation module comprising its own communication software it is more efficient to provide this software as an element of platform components 120 of bridge 118.
  • the process of the invention is now illustrated with an example wherein B- device 116 is going to be added to system 100.
  • the first step comprises physically connecting B-device 116 to B-cluster 110, or "booting" B-device 116.
  • bridge 118 detects B-device 116 as a new addition, either because bridge 118 scans B-cluster 110 or its registry/directory/look-up service (not shown) periodically or because B-cluster 110 actively notifies bridge 118.
  • Bridge 118 comprises a software component 122, referred to as Installation Manager, that handles the installation of further software components needed to integrate B-device 116 into system 100.
  • Installation Manager a software component 122, referred to as Installation Manager, that handles the installation of further software components needed to integrate B-device 116 into system 100.
  • An aspect hereof is discussed in, e.g., U.S. serial no. 09/340,272 (attorney docket PHA 23,634).
  • a software component referred to as the Reference Factory, is capable of extracting information from any of the software representations of devices registered.
  • This Reference Factory is capable of querying the inventory of services or of getting notified of a new software representation according to the methods of the relevant software architecture.
  • Installation Manager 122 receives or retrieves information descriptive of newly added B-device 116.
  • the descriptive information is possibly reformatted before being sent to a bridge server 124 via the Internet 126.
  • bridge 118 preferably provides information about the local execution environment of home network 100. This information is relevant to the software components that server 124 downloads onto bridge 118.
  • the relevant information regarding the environment relates to the software architectures present, in this case the A-standard cluster 102 and the B-standard cluster 110.
  • the information may also relate to the memory available, the type of operating system(s) being used, virtual machines present, platform libraries, etc., on bridge 118.
  • server 124 is able to select the proper translation module or modules that fits or fit in best with the network environment of system 100.
  • server 124 Upon receipt of the descriptive and environment information, server 124 uses a look-up service that needs to match the information, descriptive of B-device 116, with a translation module for representing B-device 116 in A-cluster 102.
  • server 124 has a plurality of look-up services available: one for each ordered pair (X,Y), wherein X and Y are the standards supported by server 124.
  • two look-up services are needed: (X,Y) and (Y,X).
  • server 124 may only support uni-directional bridging.
  • Devices such as devices 104-108 and 112-116, are often composite objects.
  • a TV set typically comprises Display, Amplifier and Tuner components.
  • Server 124 could first try to translate the composite object as a whole into a new composite device with an equivalent functionality. If that does not succeed server 124 could translate as much subsidiary components as possible on a one-to-one basis. This then would result in a partial, but still useful, mapping. For example, if A-cluster 102 has not available a definition of a
  • a B-type TV could still be bridged to A-cluster 102 as a monitor-like display/amplifier device. If a one-to-one relationship does not exist between particular subsidiary components in standard A and standard B, then a one-to-many or many-to-many mapping could be used.
  • standard A might define volume control and equalizer effects as a single subsidiary component, whereas standard B distinguishes them as separate subsidiary components. In this case, a device in B-cluster 110 that contains just the volume control component, but not the equalizer component, cannot be bridged to A-cluster 102.
  • a device in A-cluster 102 that contains a single amplifier component can be bridged to network B by applying a one-to-two mapping of the subsidiary components.
  • a particular set of subsidiary components in A-cluster 102 matches with another set of subsidiary components in B-cluster 110 under a many-to-many mapping.
  • a matching translation module 128 is downloaded to the bridge, installed on platform 120 and registered in accordance with the protocol of standard A. This enables other applications and devices of A-cluster 102 to discover and use device 116 through module 128. The installation and registering of module 128 may be postponed until after it has been run on the execution environment of bridge 118.
  • the invention is explained below with an example illustrating the bridging of HAVi and Universal Plug and Play (UPnP) home networks with reference to Figs.2 and 3.
  • the HAVi, Home API, and Jini standards for software architectures in the home networking field have been discussed to some detail in U.S. serial no.
  • a DCM Device Control Module
  • 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.
  • Universal Plug and Play UPF is an open network architecture that is designed to enable simple, ad hoc communication among distributed devices and software applications from multiple vendors.
  • UPnP leverages Internet technology and extends it for use in non-supervised home networks.
  • UPnP aims at controlling home appliances, including home automation, audio/video, printers, smart phones, etc.
  • UPnP distinguishes between Control Points (CPs) and controlled devices (CDs).
  • CPs comprise, e.g., browsers running on PCs, wireless pads, etc., that enable a user to access the functionality provided by controlled devices.
  • UPnP defines protocols for discovery and control of devices by CPs.
  • UPnP does not define a streaming mechanism for use by Audio/Video devices.
  • Some of the discovery and control protocols are part of the UPnP specification while others are separately standardized by the IETF (Internet Engineering Taks Force). Interaction between CPs and devices is based on the Internet protocol (IP).
  • IP Internet protocol
  • UPnP allows non-IP devices to be proxied by a software component running on IP-compliant devices. Such a component, called Controlled Device (CD) proxy, is responsible for translation and forwarding of UPnP interactions to the proxied device.
  • CD Controlled Device
  • a UPnP device has a hierarchy of sub-devices with at the lowest level services. Both devices and services have standardized types.
  • a device type determines the sub-devices or services that it is allowed to contain.
  • a service type defines the actions and state variables that a service is allowed to contain. State variables model the state of the device, actions can be invoked by a CP in order to change that state. The description of the state variables and the action is called the SCP (Service Control Protocol).
  • SCP Service Control Protocol
  • a UPnP device provides a description of itself in the form of an XML document. This document contains, among other things, the service types that it supports.
  • a device may have a presentation server for direct UI control by a CP.
  • UPnP relies on AutoIP, which provides a means for an IP device to get a unique address in the absence of a DHCP server.
  • UPnP defines a discovery protocol, based on UDP multicast, called SSDP (Simple Service Discovery Protocol). SSDP is based on devices periodically multicasting announcements of the services that they provide. An announcement contains a URL to which service actions are to be sent: the control server.
  • CPs may query the UPnP network for particular device or services types or instances.
  • UPnP relies on GENA (Generic Event Notification Architecture) to define a state variable subscription and change notification mechanism based on TCP.
  • GENA Generic Event Notification Architecture
  • a CP After a CP has detected a service it wants to use (via SSDP), it controls the service by sending SCP actions to the control server URL or querying for state variables. Actions are sent using HTTP POST messages. The body of these messages are defined by the SOAP (Simple Object Access Protocol) standard. SOAP defines a remote procedure call mechanism based on XML.
  • the translation modules, or software representations, of HAVi devices in UPnP are called Controlled Device (CD) proxies, while the software representations of UPnP devices in HAVi are called Device Control Modules (DCMs).
  • CD Controlled Device
  • DCMs Device Control Modules
  • HAVi to UPnP bridging Fig 2 is a block diagram of a home network system 200 illustrating the bridging from HAVi to UPnP, and shows in bold arrows the sequence of steps to bridge a HAVi device, here a digital camera, to UPnP.
  • System 200 has a UPnP cluster formed by devices 202, 204, and 206.
  • Device 202 comprises a light
  • device 204 comprises an MP3 player
  • device 206 comprises a printer.
  • System 200 has a HAVi network cluster formed by a TV 208, and a digital video recorder 210. The clusters are connected through bridge 118.
  • a HAVi Camera 214 is physically plugged into the HAVi's 1394 network, thus making Camera device 214 an active HAVi node.
  • this addition is discovered by the HAVi Event Manager, residing on platform components group 218.
  • the HAVi platform listens and reacts to the HAVi NewSoftwareElement event, or listens to a HAVi NetworkReset event to discover Camera 214 as new device.
  • a step 220 the registration attributes of the DCM of Camera 214 and its FCM components are retrieved from the HAVi Registry on platform 218, and are encoded in some format understood by a bridge server 222, for example XML, and are sent to bridge server 222 using HTTP POST.
  • Bridge 118 may use a HAVi Webproxy FCM to implement this.
  • a look-up component maps a HAVi device description, in the form of DCM/FCM registration attributes, to a UPnP CD proxy 226 for that device. Since UPnP CD proxies and HAVi DCMs are composite objects, the location process might be implemented on the sub device (component) level, as described earlier.
  • a device software representation is DCM
  • FCM functional components
  • a device In UPnP, a device is a hierarchical structure of sub devices with at the lowest level services. FCMs serve the same purpose as services.
  • the mapping of HAVi device to UPnP CD proxy 226 might be from complete DCM to complete CD proxy, or partially from FCMs to proxy services.
  • the mapping of FCM to service might be 1 -to- 1 , 1 -to-many or many-to-many.
  • CD proxy 226 is run on the execution environment of bridge 118. This involves installing an http server for the unique URL of CD proxy 226.
  • CD proxy 226 sends out periodic announcement messages, and responds to discover messages. This enables the other UPnP applications and devices to discover and use the HAVi Camera 214 through the CD proxy 226.
  • Fig.3 illustrates the steps to bridge a UPnP device, here printer 206 to HAVi cluster 208, 210, 214 in system 200.
  • printer 206 is physically plugged into the UPnP network, and 'powering-up' the UPnP device.
  • a next step 304 involves listening and reacting on the UPnP device announcement message.
  • the device description document of printer 206 is retrieved from the URL embodied in the announcement message, and the document is sent to bridge server 222 using HTTP POST.
  • a step 308 involves a look-up component that maps a UPnP device description, in the form of a description document (in XML), to a HAVi DCM for that device, here printer 206. Since UPnP CD proxies and HAVi DCMs are composite objects, the location process might be implemented on the sub device (component) level, as described earlier.
  • a device software representation is DCM
  • FCM functional components
  • UPnP a device is a hierarchical structure of sub devices with, at the lowest level, services. Services that are part of a UPnP device can be found in the device description document.
  • FCMs serve the same purpose as services.
  • the mapping of HAVi device to UPnP CD proxy might be from complete DCM to complete CD proxy, or partially from FCMs to services.
  • the mapping of FCM to service might be 1-to-l, 1 -to-many or many-to-many.
  • a step 310 involves running a downloaded Printer DCM 312 in the execution environment of bridge 118. This involves calling the DCM's Install method.
  • a step 314 involves DCM 312 and its FCMs to create HAVi software elements, and using those to register with the HAVi registry component (which is part of platform components 218 available on bridge 118).
  • a step 316 the HAVi registry posts global NewSoftwareElement events for DCM 312 and all FCMs that are part of it. This enables the other HAVi applications and devices to discover and use UPnP Printer 206 through Printer DCM 312.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Small-Scale Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)

Abstract

La présente invention concerne un pont qui relie des premier et second groupes de dispositifs dans un réseau local. Ces groupes possèdent diverses architectures de logiciels. Ce pont est connecté à un serveur sur Internet. Ce serveur offre un service de consultation de certains ensembles de normes, et permet à un pont de localiser et de télécharger les modules de traduction appropriés pour qu'un dispositif donné du premier groupe puisse interagir avec le second groupe.
EP01958011A 2000-07-26 2001-07-20 Liaison par pont entre reseaux locaux multistandards avec serveur Ceased EP1307998A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US61663200A 2000-07-26 2000-07-26
US616632 2000-07-26
PCT/EP2001/008552 WO2002009350A2 (fr) 2000-07-26 2001-07-20 Liaison par pont entre reseaux locaux multistandards avec serveur

Publications (1)

Publication Number Publication Date
EP1307998A2 true EP1307998A2 (fr) 2003-05-07

Family

ID=24470330

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01958011A Ceased EP1307998A2 (fr) 2000-07-26 2001-07-20 Liaison par pont entre reseaux locaux multistandards avec serveur

Country Status (5)

Country Link
EP (1) EP1307998A2 (fr)
JP (1) JP2004505499A (fr)
KR (1) KR20020035645A (fr)
CN (1) CN1398469A (fr)
WO (1) WO2002009350A2 (fr)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100406078B1 (ko) * 2001-12-31 2003-11-14 엘지전자 주식회사 홈 네트워크 디바이스, 홈 네트워크 콘트롤 디바이스, 홈네트워크에서의 디스크립션 파일 재구성 시스템 및 그 방법
KR100442256B1 (ko) * 2002-02-28 2004-07-30 엘지전자 주식회사 홈 네트워크 시스템의 규격 호환장치 및 방법
EP1345357A1 (fr) * 2002-03-12 2003-09-17 Thomson Licensing S.A. Procédé de communication entre un serveur HTTP et un client
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
EP1361713A1 (fr) * 2002-05-06 2003-11-12 Sony International (Europe) GmbH Passerelle
WO2003107596A1 (fr) * 2002-06-13 2003-12-24 Siemens Aktiengesellschaft Procede pour la creation d'un pont entre sous-reseaux jini et upnp et systemes pour la mise en oeuvre de ce procede
EP1396962A1 (fr) * 2002-08-05 2004-03-10 Sony International (Europe) GmbH Interface de service de bus
GB0218174D0 (en) * 2002-08-06 2002-09-11 Koninkl Philips Electronics Nv A network establishment and management protocol
KR100498284B1 (ko) * 2002-08-06 2005-07-01 엘지전자 주식회사 ＵＰｎＰ 기반 네트워크의 동기화 시스템 및 방법
EP1529378B1 (fr) * 2002-08-06 2014-06-18 Koninklijke Philips N.V. Protocole de creation et de gestion d'un reseau
DE10251004B4 (de) 2002-11-02 2014-04-10 Abb Ag Busfähige Anschluss-und Steuerungseinrichtung für einen dezentralen Einsatz in Niederspannungs-Verbraucheranlagen
KR100493883B1 (ko) 2003-01-02 2005-06-10 삼성전자주식회사 애플리케이션 관리 시스템 및 방법
DE10302477A1 (de) * 2003-01-23 2005-02-24 Deutsche Thomson-Brandt Gmbh Verfahren zur Verfügbarmachung eines Eingabeparameters einer Netzwerkstation eines Netzwerks eines ersten Typs in einem Netzwerk eines zweiten Typs sowie Verbindungseinheit zur Verbindung der Netzwerke des ersten und zweiten Typs
KR100638017B1 (ko) 2003-05-30 2006-10-23 엘지전자 주식회사 네트워크 디바이스
KR100596755B1 (ko) 2003-05-30 2006-07-04 엘지전자 주식회사 홈 네트워크 시스템
KR100605218B1 (ko) 2003-05-30 2006-07-31 엘지전자 주식회사 홈 네트워크 시스템
CN1836402B (zh) * 2003-05-30 2012-04-25 Lg电子株式会社 家庭网络系统及其配置系统
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
KR100541942B1 (ko) * 2003-08-11 2006-01-10 삼성전자주식회사 홈네트워크의 홈디바이스원격관리장치 및 그 방법
KR100596398B1 (ko) 2003-12-18 2006-07-03 한국전자통신연구원 공개 플랫폼 기반의 게이트웨이 상에서의 멀티 서비스제공 방법 및 그 시스템
KR100584712B1 (ko) 2003-12-26 2006-05-30 한국전자통신연구원 홈 게이트웨이와 오에스지아이 플랫폼을 이용한 홈네트워크 미들웨어 간 상호운용 서비스 장치 및 그 방법
DE102004018980A1 (de) 2004-04-20 2005-12-08 Deutsche Thomson-Brandt Gmbh Verfahren zur Steuerung eines Gerätes in einem Netzwerk verteilter Stationen sowie Netzwerkstation
KR20060035176A (ko) * 2004-10-21 2006-04-26 엘지전자 주식회사 이종 네트워크 제어 시스템 및 방법
KR100666694B1 (ko) * 2005-01-17 2007-01-11 삼성전자주식회사 ＯＳＧｉ 기반의 홈 게이트웨이 장치 및 그의 기기등록방법
KR100637080B1 (ko) 2005-02-23 2006-10-23 삼성전자주식회사 홈네트워크의 서비스 프레임워크
US8460256B2 (en) 2009-07-15 2013-06-11 Allegiance Corporation Collapsible fluid collection and disposal system and related methods
WO2008118397A1 (fr) 2007-03-23 2008-10-02 Allegiance Corporation Système d'élimination et de collecte de fluide ayant une collecte interchangeable et d'autres caractéristiques et procédés associés
US9889239B2 (en) 2007-03-23 2018-02-13 Allegiance Corporation Fluid collection and disposal system and related methods

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0849913A2 (fr) * 1996-12-18 1998-06-24 Sony Corporation Systèmes, dispositifs et procédés de communication de données

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3660443B2 (ja) * 1996-10-15 2005-06-15 株式会社東芝 データ転送制御システム及び中継装置
US6085236A (en) * 1998-01-06 2000-07-04 Sony Corporation Of Japan Home audio video network with device control modules for incorporating legacy devices
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
GB9921049D0 (en) * 1999-09-07 1999-11-10 Koninkl Philips Electronics Nv Clustered networked devices

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0849913A2 (fr) * 1996-12-18 1998-06-24 Sony Corporation Systèmes, dispositifs et procédés de communication de données

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CORCORAN: "Mapping Home-network Appliances to TCP/IP sockets Using a Three-tiered Home Gateway Architecture", 1998 IEEE, 17 June 1998 (1998-06-17), pages 729 - 736, XP000851577 *
CORCORAN: "System Architecture and Implementation of CEBus/Internet Gateway", 1997 IEEE, November 1997 (1997-11-01), pages 1051 - 1062, XP000768558 *
P. CORCORAN, J. DESBONNET: "Browser and Applet Interfaces to CEBus networks", 1997 IEEE, 11 June 1997 (1997-06-11), pages 328 - 329, XP010250002 *
See also references of WO0209350A3 *

Also Published As

Publication number Publication date
CN1398469A (zh) 2003-02-19
JP2004505499A (ja) 2004-02-19
KR20020035645A (ko) 2002-05-13
WO2002009350A2 (fr) 2002-01-31
WO2002009350A3 (fr) 2002-04-11

Similar Documents

Publication Publication Date Title
WO2002009350A2 (fr) Liaison par pont entre reseaux locaux multistandards avec serveur
US7085814B1 (en) Data driven remote device control model with general programming interface-to-network messaging adapter
US7702795B2 (en) Peer networking host framework and hosting API
US6779004B1 (en) Auto-configuring of peripheral on host/peripheral computing platform with peer networking-to-host/peripheral adapter for peer networking connectivity
US7602756B2 (en) Dynamic self-configuration for ad hoc peer networking
EP1286501A1 (fr) Méthode pour le pontage entre un réseau UPnP et un réseau HAVi
US7187661B2 (en) Gathering of device discovery information
JP2002189649A (ja) インターネットを基盤にしたネットワークシステムにおけるサービス提供方法
US20050078679A1 (en) Methods for establishing a connection between a first and a second device over a bridge connecting a havi-subnetwork to another subnetwork
WO2002001833A1 (fr) Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau
JP4523418B2 (ja) ＨＡＶｉ規格に基づく機器をＯＳＧｉプラットフォームのデバイスコントロールモジュールにより制御するための方法および装置
KR20040013465A (ko) ＵＰｎＰ 기반 네트워크의 동기화 시스템 및 방법
US6959186B2 (en) Communication system and device for controlling a plurality of electronic devices
EP2168305B1 (fr) Procédé de réception et d'émission de message d'événement, dispositif commandé, et point de commande
KR100952280B1 (ko) 댁내에 설치되는 주거 게이트웨이의 재부팅을 원격으로제어하는 방법
Kastner et al. Discovering internet services: Integrating intelligent home automation systems to plug and play networks
Islam Universal Plug and Play

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030226

AK Designated contracting states

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

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20040622

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20061231