WO2008087374A2 - SYSTÈME ET PROCÉDÉ DESTINÉS À ACCÉDER À DISTANCE À DES RÉSEAUX UNIVERSELS PRÊT-À-L'EMPLOI (UPnP) - Google Patents

SYSTÈME ET PROCÉDÉ DESTINÉS À ACCÉDER À DISTANCE À DES RÉSEAUX UNIVERSELS PRÊT-À-L'EMPLOI (UPnP) Download PDF

Info

Publication number
WO2008087374A2
WO2008087374A2 PCT/GB2008/000007 GB2008000007W WO2008087374A2 WO 2008087374 A2 WO2008087374 A2 WO 2008087374A2 GB 2008000007 W GB2008000007 W GB 2008000007W WO 2008087374 A2 WO2008087374 A2 WO 2008087374A2
Authority
WO
WIPO (PCT)
Prior art keywords
upnp
networks
network
server
xmpp
Prior art date
Application number
PCT/GB2008/000007
Other languages
English (en)
Other versions
WO2008087374A3 (fr
Inventor
Steven Bennett
Iain Barclay
Richard Sewell
Kevin Vernon
Original Assignee
Electric Pocket Limited
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 Electric Pocket Limited filed Critical Electric Pocket Limited
Publication of WO2008087374A2 publication Critical patent/WO2008087374A2/fr
Publication of WO2008087374A3 publication Critical patent/WO2008087374A3/fr

Links

Classifications

    • 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/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/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users

Definitions

  • the present invention relates generally to networking and more particularly to accessing devices and services on one network from another network.
  • the invention relates to systems and methods for allowing a client application on a network to discover remote Universal Plug and Play (UPnP) devices and services on another network and retrieve associated content from these devices/services.
  • UFP Universal Plug and Play
  • UDP Universal Plug and Play
  • PCs personal computers
  • UPnP enables such devices to connect seamlessly and simplifies the implementation of networks in the home (e.g. for data sharing, communications and entertainment) and corporate environments.
  • UPnP (http://www.upnp.org ' ) defines and publishes the standards (e.g. network protocols) that define UPnP networking.
  • UPnP is built upon open, Internet-based communication standards including IP, TCP, UDP HTTP and XML and enables data communication between any two devices under the command of any control device on the UPnP network.
  • Any operating system and any programming language can be used to build UPnP products.
  • the foundation for UPnP networking is IP addressing.
  • IP addressing In UPnP networking a device can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request and learn about the presence and capabilities of other devices. This is achieved by following various steps in the UPnP networking process. These steps are well known and understood in the art.
  • the first step in UPnP networking is discovery in which the UPnP discovery protocol is used to advertise the device's services to control points on the network.
  • the UPnP discovery protocol allows that control point to search for devices of interest on the network.
  • the UPnP discovery protocol is based on the Simple Service Discovery Protocol (SSDP).
  • SSDP Simple Service Discovery Protocol
  • the further steps in the UPnP networking process include description, (in which the control point retrieves the device's description from the URL provided by the device in the discovery step), control, event notification, and presentation.
  • UPnP data such as audio files, video or still images
  • music files can be transferred from one device to another in a UPnP network of devices in a user's home. It may sometimes be desirable to remotely access a UPnP network in order to retrieve media content associated therewith.
  • a user may desire to browse and play music from their home PC on a Smartphone via the cellular data network.
  • a user who is visiting a friend may wish to be able to access music files or images stored on their home UPnP network in order to play/view them on the friend's home UPnP network.
  • UPnP UPnP
  • UPnP UPnP
  • Previous proposed solutions to these goals have relied on internet messaging protocols such as Simple Object Access Protocol (SOAP) and/or other Web services to relay UPnP messages between the networks.
  • SOAP Simple Object Access Protocol
  • SOAP Simple Object Access Protocol
  • Intel Corporation's Intel ® Device Relay which uses SOAP to effectively mirror a UPnP device on one network onto a different network.
  • a method of linking separate UPnP networks comprising using XMPP to encapsulate and relay UPnP protocol messages between the networks.
  • the method may comprise using XMPP to encapsulate and relay UPnP protocol messages between a first network (for example a home network) and a remote network so as to allow devices and content on the first network to be accessed from the remote network.
  • a “remote network” in the context of this application is one from which it is not possible to discover UPnP Media Servers and Devices using standard UPnP protocol and services.
  • the Extensible Messaging and Presence Protocol is the lETF's formalisation of the base XML streaming protocols for instant messaging and presence developed within the Jabber community and is an open XML technology for real-time communications, which powers a wide range of applications including instant messaging, presence, media negotiation and generalised XML delivery among others.
  • the core protocol is defined by the RFC 3920 and RFC 3921 standards.
  • One significant advantage of using XMPP to encapsulate and relay the UPnP protocol messages in the present invention is that it enables firewalls and NAT routers to be traversed automatically.
  • UPnP Discovery and Description requests are encapsulated in
  • XMPP message stanzas For example, in a preferred embodiment UPnP Discovery requests and responses are encapsulated into XMPP headline message stanzas and UPnP Description requests and responses are encapsulated into XMPP chat message stanzas.
  • a system for linking two separate UPnP networks comprising a server software object for installing on a first one of said UPnP networks, client software for installing on a device for connection to a second one of said UPnP networks, and an XMPP server accessible to both said first UPnP network and said device.
  • the first UPnP network and the device may, for example, access the XMPP server via the internet.
  • the server software object and client software are preferably configured to encapsulate and relay UPnP protocol messages (sometimes alternatively referred to as "IJPnP protocol traffic " ' or simply "UPnP traffic”) between said first and second UPnP networks, via the XMPP server.
  • the device may be a mobile device.
  • the device may be a mobile phone or any other device, hand-held or otherwise, enabled with the facility to communicate over a cellular data network (for example a messaging device such as a Blackberry device).
  • a cellular data network for example a messaging device such as a Blackberry device
  • the device may alternatively simply be enabled with the facility to communicate over a wifi or wired internet network.
  • the device may, for example, be a laptop or desktop PC which is located remotely from the first UPnP network and is capable of connecting to the internet.
  • the first UPnP network may be located in a first house and said laptop or desktop PC may be located in a second house containing the second UPnP network.
  • the method where the method is used to link two UPnP networks, respective data processing units in each of the UPnP networks are preferably uniquely identified and the method preferably includes establishing a one-to-one communication channel between the two networks for relaying UPnP protocol traffic therebetween.
  • said communication channel may be configured so as to carry solely UPnP protocol traffic.
  • the method includes filtering UPnP protocol traffic between the two networks. Most preferably, the traffic is filtered so that the tunnel does not carry UPnP Service
  • the method may include encrypting the encapsulated UPnP protocol messages prior to relay thereof.
  • the method may further comprise creating a separate TCP data connection or "tunnel" between the two UPnP networks for sending large objects such as, for example, music files and word documents between the two networks.
  • This tunnel may, for example, comprise a peer to peer connection to transmit content data (e.g. music files) from one network to the other, or alternatively, a relay connection.
  • content data e.g. music files
  • a relay connection e.g., a peer to peer connection to transmit content data (e.g. music files) from one network to the other, or alternatively, a relay connection.
  • Techniques for creating such connections are well-known, for example libjingle, ICE and STUN.
  • the data content of the object may instead be sent via XMPP encapsulation and relay. Encryption and/or secure protocols may be used for sending the content data.
  • the client software and the server software object are preferably configured so as to create and register a new pair of respective network addressable identities or "IDs'" and a pair of corresponding passwords with the XMPP server.
  • the client software and server software object are configured to do this upon their installation. This enables a one-to-one communication channel to be established between the client software and server software object, for relaying UPnP traffic therebetween via the XMPP server.
  • the client software and server software object are configured to, upon initiation of the client software, establish mutual presence on the XMPP service provided by the XMPP server and to subsequently communicate with each other over XMPP using XMPP Messaging and Query/Response services.
  • the client software and server software object are configured to transmit received relayed UPnP protocol messages on their own respective one of said networks so that UPnP devices on said respective networks can receive them.
  • the software components may each be configured to listen for UPnP traffic on their own respective one of said networks and encapsulate and relay this UPnP traffic to the complementary software component on the other (remote) network.
  • the software components are configured so as to be capable of differentiating between traffic addressed to local and remote device IDs and to ignore traffic that has local relevance only and relay the rest of the traffic to the remote network.
  • the software components may be configured to encrypt the encapsulated UPnP traffic.
  • a method of linking two separate UPnP networks comprising establishing a one- to-one communication channel between the two networks which channel carries solely UPnP protocol traffic.
  • a system for linking separate UPnP networks comprising a server software object for installing on a first one of said UPnP networks, client software for installing on a device for connection to a second one of said UPnP networks, and an intermediate network server accessible to both said first network and said device, and wherein the server software object and the client software are configured to establish a communication channel therebetween via said network server which channel carries solely UPnP protocol traffic.
  • the client software receives only UPnP SSDP advertisement and discovery response messages from the home network, i.e. the server software object preferably does not transmit discovery search requests from the home network to the away network, and the client software preferably does not transmit SSDP advertisements from the away network to the home network. This has the advantage of reducing the bandwidth and processing requirement of the system.
  • Figure 1 is a schematic drawing of a system according to one embodiment of the invention.
  • Figure 2 is a flow diagram illustrating message flow in the system of Figure 1.
  • Figure 1 illustrates an inventive network configuration for accessing a home media server from a mobile device (which in this embodiment is a hand-held mobile phone) which is remote from the home media server.
  • the system comprises: a home network 1 with UPnP enabled media server 2 and a desktop PC 3a with a server software object 3 (hereinafter referred to as “the Server” 3) installed thereon, optionally behind a NAT firewall 4: a mobile device 5 with client software 6 (hereinafter referred to as the Client software 6) installed thereon, the mobile device being connected to a network 7 which is remote from the home network 1 (this remote network 7 is hereinafter referred to as the "away” network) and has its own UPnP enabled media server 11 (not shown in Fig.l) and is optionally behind a remote firewall and NAT 9; and an XMPP server 10 accessible to both the home network and the mobile device (e.g. via the internet).
  • the Server 3 and Client software 6 are complementary pieces of software as will be described below.
  • the home media server 2 is on the same machine as the Server 3 (but in other possible embodiments they may be on separate machines).
  • the Client software 6 consists of a modified UPnP Media Controller 12, Media renderer 14 and a UPnP proxy service 16 (hereinafter referred to as the "Client Proxy").
  • the proxy service 16 may be integrated in the Client software 6 or in a separate software object (not shown).
  • the Client software 6 and the Server 3 know each other's XMPP IDs. This is accomplished at installation time by creating and registering a new pair of IDs and passwords with the XMPP server 10 and setting them in the Server 3 and Client software configuration files.
  • the Server 3 is always logged onto the XMPP service provided by the XMPP server 10.
  • the Client software 6 When the Client software 6 is started it logs onto the same XMPP service, spots the presence of its complementary Server 3 and sends its presence information to the Server 3.
  • Server 3 and Client software 6 then communicate to each over XMPP using the XMPP Messaging and Query/response services.
  • the UPnP Media Controller 12 of the Client software 6 issues a UPnP discovery request 20 (multicast) on its local host interface.
  • the UPnP Client Proxy 16 listens for multicasts on the local host interface. It encapsulates 22 the content (headers) of any discovery request it hears into an XMPP headline message stanza using Base64 encoding and sends 24 the XMPP headline message stanza to the XMPP server addressed to the Server 3.
  • Listening to the local host interface as well as the normal (i.e. local) network interface is an important part of the solution according to this embodiment. If the away network 7 doesn ' t support multicasting (e.g. Carrier Mobile phone internet networks) then listening only on the normal network interface will not hear requests.
  • the XMPP message stanza type (headline or chat) is used to distinguish between encapsulated discovery requests/responses/notifications and encapsulated description requests/responses.
  • the XMPP message arrives at the home network Server 3.
  • the encapsulated UPnP discovery request is extracted and base64 decoded from the XMPP message ( i.e. "unpacked") 26 and sent via UDP multicast 27 (the standard UPnP method) on both the local network and local host network interfaces of the home network desktop PC 3a.
  • Responses 29 to the multicast requests are received by the Server 3.
  • the content of the response is base64 encoded and encapsulated 28 in an XMPP headline message.
  • the message is sent 30 to the Proxy 16 of the Client software (via the XMPP server).
  • the Client Proxy 16 extracts (i.e. Unpacks) 32 the discovery response and sends it via UDP unicast (the standard UPnP method) 34 to the IP address and port that the original Discovery request came from (i.e. the modified UPnP Media Controller 12).
  • UDP unicast the standard UPnP method
  • the modified UPnP Media controller 12 needs to identify whether the discovery response is for a device on its local network (the away network 7) or the remote network (the home network 1) so that it can send the subsequent description requests directly on the local network or via the XMPP encapsulation relay technique. It uses the IP address the response came from and the IP address of the service description in the response to do this.
  • the modified UPnP Media Controller 12 and Client Proxy 16 on the same device and the assumption that there is no media server on the device 5 it is sufficient to spot if it came from a local host. If it did the response is marked 56 as being from a local device. If it did not then it is a response from a remote service and is marked 58 as such.
  • This algorithm is extended and modified for the cases where the Away UPnP Media Controller 12 and Away Client Proxy 16 are not on the same IP address or a media server is present on the same IP address or local host 7. if the IP addresses don't match then it is remote. If the IP addresses match it is local. For the case where the remote media server URL has the same IP address as the Client software the IP addresses will match and an attempt to open a socket to the URL address is used to determine if it is local (socket success) or remote (socket open fails).
  • Subsequent Service Notifications on the home network 1 are encapsulated and relayed via the Server 3 to the Client software 6 using the same methods as for discovery request responses.
  • Various levels of filtering are implemented by the Client software 6 and Server 3 to minimise UPnP traffic relaying depending on the specific implementation requirements. For instance, in this client/server implementation, Service Discovery requests from the home network 1 are not needed and therefore are not relayed to the away network 12. Similarly Service notifications on the away network 12 are not needed or relayed to the home network 1. It will though be appreciated that if the invention were to be used in a full bridging implementation then these messages would be needed and therefore would not be filtered.
  • the next phase in UPnP is Service Description.
  • the Client software 6 asks the devices it has discovered what services they provide using Service Description requests .
  • the modified UPnP Media Controller 12 of the Client software 6 on the away network 7 t encapsulates 40 the contents of the service description requests 38 (http get) for remote devices into an XMPP chat message using base64 encoding. It adds an XMPP ID element to the message that identifies the IP address and port that the request was sent from (e.g. 192.168.1.1 :8912) and sends it 42 to the Server 3 in the home network 1.
  • the XMPP message stanza type (headline or chat) is used to distinguish between encapsulated discovery traffic and encapsulated description requests.
  • the Server 3 unpacks 44 the Service Description request and opens a socket and makes a service request 45 on its network to the URL address in the request. It tags the socket with the id of the XMPP message so that if the request from the Client is segmented (split over 2 or more tcp segments) then the ID in the XMPP message can be be used to select the same socket at the Server end to send it over (e.g. a simple session method).
  • the Server 3 When the Server 3 gets a response 46 it encapsulates it 47 in an XMPP chat message, adds the source IP address and port that the response was sent from to the IP address and Port from the encapsulated discovery requested ID (e.g. if the response came from 192.168.2.1 :54533 then the ID is set to 192.168.1.1 :8912/192.168.2.1 :54533) and sets the id element of the message to it. It then sends 48 the XMPP chat message to the Client Proxy 16.
  • ID e.g. if the response came from 192.168.2.1 :54533 then the ID is set to 192.168.1.1 :8912/192.168.2.1 :54533
  • the Client Proxy 16 unpacks 50 the encapsulated response and uses the first part of the id of the message (e.g. 192.168.1.1 :8912) to determine where to send the response 52 to (http response) on the away network 12 and if to use an existing socket (e.g. if the response is segmented).
  • the first part of the id of the message e.g. 192.168.1.1 :8912
  • the content of the local and remote UPnP devices can be browsed 54.
  • the Client software 6 knows if the parent nodes (devices) of the browse tree are local or remote from the service discovery and notification phases. If the UPnP device is remote the browse requests are encapsulated and relayed in the same way as for Service Description requests.
  • the child nodes inherit the local/remote attribute so that when the user has browsed Io the remote data object that they want to obtain (e.g. a music track or album, photo, video footage) the URL in the UPnP description object is used to make a request for the data and the client uses the local/remote attribute to determine whether to make a local request (e.g. http get) or make a remote request using the XMPP encapsulation and relaying technique.
  • the local/remote attribute e.g. http get
  • the data content of the object can be sent back via XMPP encapsulation for small data objects.
  • a separate TCP data connection is made between the Client software 6 and Server 3. This may be a direct peer to peer connection or indirect via a relay.
  • the methods for creating this connection are well known (e.g. see Libjngle, ICE and STUN).
  • the bitrate of the source media files is transcoded before the files are transferred to the Client software 6, in order to ensure that desired end to end bandwidth requirements are met.
  • the above-described embodiment may be used to send a variety of types of data content from a home network to a remote network.
  • the method or system may be used to:
  • (d) send application specific data from a home network to an away network to be used by an application on the away network.
  • network connections in the above described embodiment may be via any suitable means such as, for example, wired network connections or WiFi.
  • the Client software 6 need not be installed on a mobile device: instead it could, for example, be installed on a personal computer (PC) which is connected to the same XMPP server 10 as the Server 3. This PC may form a component of the away UPnP network 7 or be otherwise connected to the away network 7.
  • PC personal computer
  • the mobile device 5 may be a Smartphone equipped with a Music Player application which is capable of playing music files retrieved from the home network using the above-described method for encapsulating and relaying UPnP protocol messages using XMPP.
  • more than two UPnP networks may be linked in a similar manner as described above, using XMPP to encapsulate and relay UPnP protocol messages between the networks.
  • an intermediate network server utilising a different technology to XMPP may be used to perform the encapsulation and relay of UPnP protocol messages between the networks.
  • Instant Messaging and Presence protocols such as Open Mobile Alliance ' s IMPS (see http://en.wikipedia.org/wiki/IMPS and http://www.openmobilealliance.org/release_program/imps_vl_3.html) , SIP/SIMPLE (http://en.wikipedia.org/wiki/SIMPLE and http://www.ietf.org/html.charters/simple- charler.html) and proprietary protocols such as Yahoo! Messenger, AOL's AIM (AOL Instant Messenger) and Microsofts MSN Messenger could be used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé et un système destinés à permettre à une application client sur un réseau de découvrir à distance des dispositifs universels prêt-à-l'emploi et à extraire un contenu associé de ces dispositifs/services. Dans son mode de réalisation préféré, le procédé et le système utilisent un XMPP afin d'encapsuler et relayer des messages de protocole UPnP entre les réseaux. Dans ce mode de réalisation, un canal de communication biunivoque est établi entre un objet de logiciel de serveur (3) installé sur un réseau local (1) et un logiciel client (6) placé sur un dispositif (5) tel qu'un téléphone mobile relié à un réseau à distance ('distant') (7), afin de relayer uniquement le trafic UPnP, par l'intermédiaire d'un serveur XMPP (10). Le trafic UPnP supporté par le canal peut être filtré de manière à réduire les besoins en largeur de bande.
PCT/GB2008/000007 2007-01-17 2008-01-02 SYSTÈME ET PROCÉDÉ DESTINÉS À ACCÉDER À DISTANCE À DES RÉSEAUX UNIVERSELS PRÊT-À-L'EMPLOI (UPnP) WO2008087374A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0700901A GB2445791A (en) 2007-01-17 2007-01-17 Interconnection of Universal Plug and Play Networks using eXtensible Messaging and Presence Protocol Streams
GB0700901.2 2007-01-17

Publications (2)

Publication Number Publication Date
WO2008087374A2 true WO2008087374A2 (fr) 2008-07-24
WO2008087374A3 WO2008087374A3 (fr) 2008-11-06

Family

ID=37846521

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2008/000007 WO2008087374A2 (fr) 2007-01-17 2008-01-02 SYSTÈME ET PROCÉDÉ DESTINÉS À ACCÉDER À DISTANCE À DES RÉSEAUX UNIVERSELS PRÊT-À-L'EMPLOI (UPnP)

Country Status (2)

Country Link
GB (1) GB2445791A (fr)
WO (1) WO2008087374A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010141714A3 (fr) * 2009-06-03 2011-02-24 Qualcomm Incorporated Systèmes et procédés permettant de créer des systèmes plug-and-play (prêt à utiliser) virtuels universels
CN102118378A (zh) * 2010-01-05 2011-07-06 深圳市闪联信息技术有限公司 3c协同设备、通信系统和通信方法
CN102413112A (zh) * 2010-09-26 2012-04-11 深圳市闪联信息技术有限公司 一种实现设备关联的方法、关联服务器与系统
CN103716281B (zh) * 2012-09-28 2017-05-24 联想(北京)有限公司 控制方法、电子设备和服务器

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2372960B1 (fr) * 2008-12-12 2014-09-10 Panasonic Corporation Système de réseau de communication
US9325518B2 (en) 2010-03-03 2016-04-26 France Telecom Controlling a device of a remote network from a local network
AU2011211426A1 (en) * 2010-08-16 2012-03-01 Lantronix, Inc. Various methods and apparatuses for tunneling of UDP broadcasts
EP2469768A1 (fr) 2010-12-22 2012-06-27 France Telecom Procédé d'interfaçage de dispositifs UPnP
CN102571861B (zh) * 2010-12-23 2015-09-30 华为终端有限公司 远程访问的方法、服务器和网络系统
CN103001959B (zh) * 2012-11-29 2015-04-15 东软集团股份有限公司 家庭间设备发现方法和系统
US9560145B2 (en) * 2013-07-20 2017-01-31 Cisco Technology, Inc. XMPP based UPNP device architecture for cloud computing in a network environment
EP3063964B1 (fr) 2013-10-28 2021-11-24 Koninklijke KPN N.V. Découverte et commande de dispositif à dispositif dans un réseau étendu
CN106294510A (zh) * 2015-06-11 2017-01-04 工业和信息化部电信研究院 一种关联方法和系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1742153A1 (fr) * 2004-04-22 2007-01-10 Canon Kabushiki Kaisha Procédé de confirmation, dispositif de connexion, procédé de communication et programme

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2535751A1 (fr) * 2006-01-31 2007-07-31 Bing-Lam Luk Mecanisme medical pret a utiliser

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1742153A1 (fr) * 2004-04-22 2007-01-10 Canon Kabushiki Kaisha Procédé de confirmation, dispositif de connexion, procédé de communication et programme

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DAVE FRASER: "Making the Most of Ubiquitous Wi-Fi: The Service Enabled Device"[Online] 12 August 2006 (2006-08-12), XP002495171 Retrieved from the Internet: URL:http://www.convergedigest.com/bp/bp1.asp?ID=447&ctgy=> [retrieved on 2008-09-09] *
SAINT-ANDRE P ET AL: "Extensible Messaging and Presence Protocol (XMPP): Core; rfc3920.txt" IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 October 2004 (2004-10-01), XP015009693 ISSN: 0000-0003 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010141714A3 (fr) * 2009-06-03 2011-02-24 Qualcomm Incorporated Systèmes et procédés permettant de créer des systèmes plug-and-play (prêt à utiliser) virtuels universels
CN102461124A (zh) * 2009-06-03 2012-05-16 高通股份有限公司 用于产生虚拟通用即插即用系统的系统和方法
JP2012529125A (ja) * 2009-06-03 2012-11-15 クアルコム，インコーポレイテッド 仮想ユニバーサルプラグアンドプレイシステムを作成するシステムおよび方法
US8516071B2 (en) 2009-06-03 2013-08-20 Qualcomm Incorporated Systems and methods for creating virtual universal plug-and-play systems
KR101411145B1 (ko) 2009-06-03 2014-06-23 퀄컴 인코포레이티드 가상 유니버셜 플러그-앤-플레이 시스템을 생성하는 시스템 및 방법
CN105208118A (zh) * 2009-06-03 2015-12-30 高通股份有限公司 用于产生虚拟通用即插即用系统的系统和方法
KR101614194B1 (ko) * 2009-06-03 2016-04-20 퀄컴 인코포레이티드 가상 유니버셜 플러그-앤-플레이 시스템을 생성하는 시스템 및 방법
CN102118378A (zh) * 2010-01-05 2011-07-06 深圳市闪联信息技术有限公司 3c协同设备、通信系统和通信方法
CN102413112A (zh) * 2010-09-26 2012-04-11 深圳市闪联信息技术有限公司 一种实现设备关联的方法、关联服务器与系统
CN103716281B (zh) * 2012-09-28 2017-05-24 联想(北京)有限公司 控制方法、电子设备和服务器

Also Published As

Publication number Publication date
WO2008087374A3 (fr) 2008-11-06
GB2445791A (en) 2008-07-23
GB0700901D0 (en) 2007-02-28

Similar Documents

Publication Publication Date Title
WO2008087374A2 (fr) SYSTÈME ET PROCÉDÉ DESTINÉS À ACCÉDER À DISTANCE À DES RÉSEAUX UNIVERSELS PRÊT-À-L'EMPLOI (UPnP)
CN105409183B (zh) 用于在html5应用中实现任何网络功能客户端或服务器的系统和设备
EP2438745B1 (fr) Systèmes et procédés permettant de créer des systèmes plug-and-play (prêt à utiliser) virtuels universels
KR100978336B1 (ko) 리모트 액세스
US20030063608A1 (en) Multicast discovery protocol uses tunneling of unicast message
JP2008236344A (ja) プロキシ装置、ネットワークシステムおよび通信方法
US20150089025A1 (en) Method And Apparatus For Sharing DLNA Device
KR20070117503A (ko) 범용 플러그 앤 플레이 디바이스에 원격 액세스하는 방법및 시스템
US20090282470A1 (en) Content aggregation server on virtual universal plug-n-play network
Park et al. A dynamic control middleware for cyber physical systems on an IPv6‐based global network
KR100906677B1 (ko) ＵＰｎＰ 네트워크의 원격지 보안 접속 시스템 및 방법
US20130064250A1 (en) Remotely accessing and controlling user equipment in a private network
KR100429902B1 (ko) 공중망에서 사설망 내의 디바이스를 제어하기 위한 장치및 방법
CN103973638B (zh) 访问控制方法、电子设备和服务器
Belimpasakis et al. Remote access to universal plug and play (UPnP) devices utilizing the Atom publishing protocol
Cui et al. Research and Implementation of WEBRTC Signaling via websocket-based for real-time multimedia communications
KR100953093B1 (ko) 이종 ＵＰｎＰ네트워크를 통한 멀티미디어 서비스 방법 및 시스템
US9503274B2 (en) System facilitating user access to content stored or exposed on connected electronic communication devices
Hwang et al. Personal mobile A/V control point for home-to-home media streaming
Kim et al. Internet home network electrical appliance control on the internet with the UPnP expansion
Belimpasakis et al. A survey of techniques for remote access to home networks and resources
CN105323125A (zh) 一种跨家庭网络的处理方法及http网关、dlna设备
Chen et al. Integrating service discovery technologies in OSGi platform
Grimmett et al. UPnP: Breaking out of the LAN
Belimpasakis et al. User created content in the extended home

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08701728

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08701728

Country of ref document: EP

Kind code of ref document: A2