专利名称：UPnP设备之间的远程访问的制作方法
UPnP设备之间的远程访问
背景技术：
通用即插即用(UPnP)技术建立允许联网UPnP设备彼此交互的协议。有了 UPnP， 设备可以动态地加入网络、获得网际协议(IP)地址、传达其能力、并获知其它设备的在场 和能力。设备随后可直接彼此通信，从而能够发现并控制设备。可被配置成实现UPnP协议 的设备的示例包括计算机、服务器、打印机、电话、数码相机、录像机、因特网个人电器、或个 人数字助理。通常，一个UPnP设备用作控制点并且另一 UPnP设备将服务展示给该控制点。控 制点是局域网(LAN)上调用服务上的动作的实体。例如，控制点可请求将数据传送到控制 点的服务。UPnP设备的不同类别与不同的服务集和嵌入式设备相关联。例如，DVD播放器 中的服务与打印机中的服务不同。特定设备提供的服务集以及与该特定设备相关联的属性 列表被称为该设备必须主存的设备和服务内描述文档。较佳地，这些描述文档用可扩展标 记语言(XML)来编写。由于UPnP服务发现和事件管理(eventing)机制的本质，UPnP技术受到限制，因 为其只能应用于连接到支持多播的很好地控制的LAN环境的UPnP设备。S卩，UpnP不允许 设备跨诸如例如因特网中出现的网络边界彼此访问。随着诸如便携式计算机等的便携式联网设备的越来越普及，通常位于同一网络上 的设备可能变为分开的。例如，可访问家里的基于UPnP的打印机或媒体服务器的膝上型计 算机将无法在该膝上型计算机位于诸如例如咖啡店等远程位置时访问这些设备。提供本背景来介绍以下概述和详细描述的简要上下文。本背景不旨在帮助确定所 要求保护的主题的范围，也不旨在被看作将所要求保护的主题限于解决以上所提出的问题 或缺点中的任一个或全部的实现。发明概述提供了一种用于允许通用即插即用(UPnP)技术在因特网或其他广域通信网络上 使用的方法。在一个说明性示例中，第一启用UPnP的设备将诸如流媒体等UPnP服务通过 因特网提供给各个用户。第一启用UPnP的设备向诸如Windows Live等在线身份提供者提 供被授权从远程位置访问第一启用UPnP的设备的那些用户的用户ID。当用户希望从第一 启用UPnP的设备接收UPnP服务时，用户使用他的用户ID来登录到在线身份提供者并从在 线提供者接收与第一启用UPnP的设备相关联的IP地址。用户的媒体播放器或其他应用程 序根据该IP地址来构造URL并联系该URL处的启用UPnP的设备。启用UPnP的设备向用 户提供其上可用的媒体库的列表。最后，用户的媒体播放器可使用可从该媒体库获得的内 容或其他信息来调用所需UPnP服务。在另一说明性示例中，关于第一启用UPnP的设备的联系信息在通过因特网远程 地访问第一启用UPnP的设备的第二启用UPnP的设备上预先提供。以此方式，消除了对在 线第三方的需求。在一个特定实现中，联系信息被合并在第一启用UPnP的设备的设备描述 文档中，该文档本身在第二启用UPnP的设备上预先提供。提供本概述是为了以简化的形式介绍将在以下详细描述中进一步描述的一些概念。本概述不旨在标识所要求保护的主题的关键特征或本质特征，也不旨在用于帮助确定 所要求保护的主题的范围。本发明的其它特征和优点在参考附图继续阅读以下对实施例的 详细描述后将变得显而易见。附图简述
图1是支持通用即插即用(UPnP)移动设备上的UPnP应用程序的体系结构的一个 示例的高级框图。图2示出典型的UPnP协议栈。图3示出其中多个UPnP设备彼此嵌套或嵌入的安排的一个示例。详细描述图1是支持通用即插即用(UPnP)移动设备110上的UPnP应用程序的体系结构的 一个示例的高级框图。在该示例中驻留在同一房屋上的UPnP设备130、131和132通过LAN 112彼此通信。UPnP设备130、131和132可通过LAN 112根据常规UPnP协议彼此访问。提供用于建立连接到LAN 112和通信网络或支持多个数据通信协议的WAN 105的 设备之间的通信的网络网关121。这种通信网络通常是异构网络，即由多个逻辑网络构成的 物理网络。这种网络的一个示例是因特网。移动设备110通过使用诸如例如IEEE 802.11 等合适协议的无线链路与异构网络105进行通信。根据以下描述的各技术，移动设备110可 与使用UPnP协议的UPnP设备130、131和132中的任一个进行通信。在一个特定实现中， UPnP设备130、131和132中的一个是流媒体服务器而移动设备110是接收流传输内容并使 用诸如微软公司的Windows Media Player、苹果公司的Quicktime以及RealNetworks公司 的RealOne播放器等呈现应用程序来呈现该流传输内容的膝上型计算机。虽然膝上型计算 机和流媒体服务器在以下讨论中不时地被引用，但是此处描述的各方法和技术更一般地适 用于希望彼此建立远程连接的任意两个UPnP设备。应该注意，在某些情况下，单个流媒体 服务器可实现多个UPnP设备，对服务器的每一用户有一个。每一 UPnP设备共享该用户的 媒体库。在其他情况下，多个UPnP设备按照以下结合图3将描述的方式来嵌套。UPnP设备130、131和132以及移动设备110实现诸如图2中示出的UPnP协议 栈。该协议栈包括TCP/IP网络协议栈10、HTTP层18、HTTPU (用户数据报协议(UDP)上的 HTTP单播)层20、HTTPMU(UDP上的HTTP多播)层22、SSDP(简单服务发现协议)层24、 GENA (通用事件通知体系结构)层26、SOAP (简单对象访问协议)层28、UPnP设备体系结 构定义层30、UPnP论坛工作委员会定义层32和UPNP厂商定义层34。TCP/IP协议栈10包 括IP层16、TCP层14和UDP层12。TCP/IP联网协议栈10用作其上构建其余UPnP协议的 基础。UPnP设备可使用TCP/IP协议套件中的许多协议，包括TCP、UDP、IGMP (因特网组播 协议)、ARP (地址解析协议)和IP以及诸如DHCP (动态主机配置协议)和DNS (域名系统) 等TCP/IP服务。TCP/IP为UPnP设备之间的网络连接提供了基础协议栈。移动设备110或UPnP设备130-132可用作到UPnP服务的控制点。如上所述，UPnP 控制点(CP)调用UPnP服务上的动作。控制点可发现设备、检索设备和服务描述、调用服务 上的动作、查询状态变量、从服务接收事件以及其他类似任务。如果UPnP设备130-132中 的一个是流媒体服务器，则移动设备110用作从该服务器接收并呈现流媒体的控制点。如图3所示且如上所述，在某些情况下，每一启用UPnP的设备可包括一个或多个 服务和可任选的嵌套(即，嵌入式)设备和服务的容器，而不是具有实现多个UPnP设备的单个机器。例如，UPnP设备90包括提供两个服务94和96的单个设备92，而UPnP设备98 包括提供服务102的单个设备100，而UPnP设备104包括提供服务108和提供服务112和 114的嵌入式设备110的根设备106。不同类别的UPnP设备与不同的服务集和嵌入式设备 相关联。标识给定设备、其服务和任何嵌入式设备及其服务的信息由该设备主存的XML描 述文档来提供。UPnP网络中的最小控制单元是服务。服务展示动作并用状态变量对其状态进行建 模。例如，时钟服务可被建模为具有定义时钟的状态的状态变量，即当前时间和允许控制服 务的两个动作即设置时间和获得时间。与设备描述类似，服务信息是由UPnP论坛标准化的 XML服务描述的一部分。指向这些服务描述的指针(例如，URL)包含在服务描述文档内。如前所述，UPnP网络中的控制点是能够发现并控制其他设备的控制器。例如，如图 3所示，控制点包括如控制点114所描绘的用于控制其他设备的设备(例如，PC 38)以及如 控制点117所描绘的可由其他设备控制的设备中的控制器。在发现设备之后，控制点可以 检索设备描述并获得相关联的服务列表；检索感兴趣的服务的服务描述；调用动作来控制 服务；和/或订阅服务的事件源。发现过程假定要被发现的设备已经获得一 IP地址。在讨论了发现过程本身之后， 下面将讨论通过异构网络的UPnP访问的上下文中的获得IP地址的方式。发现UPnP设备涉 及在网络上搜索来寻找满足控制点始发的搜索准则的至少一个设备。作为响应，匹配搜索 准则的UPnP设备的统一资源定位符(URL)随后被发送到该控制点。该控制点随后使用这 一 URL来检索设备或服务描述文档。设备描述文档用XML来表达并且通常包含设备信息， 诸如制造商的名称、设备的型号、序列号、设备提供的服务列表以及嵌入式设备列表等。设 备描述文档还包含用于呈现设备和列举所有服务的URL，包括用于控制和事件管理的URL。 下表示出设备描述文档的一个示例，斜体的占位符用于与设备描述对应的实际元素和值。<" ？ xml version = “ 1.0" ‘ ？ ><root xmlns = “ urn:schemas-upnp-org:device-l-O〃 ><specVersion><mmor>l</major><mmor>0</mmor></specVersion><URLBase> 所有相关 URL 的基础 URL</URLBase>〈device〉<deviceType>urn:schemas-upnp-org:device. deviceType:v</deviceType><friendlyName> 用户友好的短标题 </friendlyName>Manufacturer) IlJitlti名禾尔 </manufacturer><manufacturerURL> 到制造商站点的 URL</manufacturerURL><modelDescription> ffl^if WixfeH </modelDescription><mo del Name)模型名称 </mode IName ><modelNumber> 型号 </modelNumber><modelURL> 到模型站点的 URL</modelURL>
<serialNumber> 制造商的序列号 </serialNumber><UDN>uuid:UUID</UDN><UPC>通用产品代码</UPC><iconList><icon><mimetype> 图像 / 格式 </mimetype><width> 水平像素 </width>〈height〉垂直像素〈/height〉<depth> 色深度 <depth><url> 到图标的 URL</url></icon>声明其他图标的XML (如果存在)放在这里</iconList><serviceList><service><serviceType>urn schemas-upnp-org:service:serviceType:v</serviceType><serviceld>urn:upnp-org:serviceld:serviceld</ serviceld><SCPDURL> 用于控制的 URL</controlURL><controlURL> 用于事件管理的 URL</eventSubURL></service>UPnP论坛工作委员会定义的其他服务的声明(如果存在)放 在这里UPnP厂商添加的其他服务的声明(如果存在)放在这里</serviceList><deviceList>UPnP论坛工作委员会定义的嵌入式设备的描述(如果存在)放在 这里UPnP厂商添加的嵌入式设备的描述(如果存在)放在这里</deviceList><presentationURL> 用于呈现的 URL</presentationURL>〈/device〉</root>如前所述，常规UPnP发现过程假定UPnP设备通过单个很好地控制的LAN环境来 连接。常规UPnP发现过程不允许UPnP设备当其在不同网络上时发现彼此。例如，在图1 中，移动设备110不能使用常规UPnP发现过程来发现UPnP设备130、131和132中的任一 个。在一个实现中，对常规UPnP发现过程的这种限制可以在诸如图1中示出的在线身份提供者140等第三方的帮助下克服。希望向移动设备110提供UPnP服务的UPnP设备 130,131和132中的任一个需要向在线身份提供者140注册。出于说明的目的，假定UPnP 设备130是希望将流媒体服务提供给移动设备110的流媒体服务器。在这种情况下，UPnP 设备130向在线身份提供者140注册，并且在线身份提供者140进而将此处被称为机器ID 的标识符分配到UPnP设备130。在线身份提供者140可由任何适当方作为在线服务来提供。这种服务的一个示例 是Windows Live提供的服务，Windows Live可提供可用作机器ID的Windows Live ID。类 似地，Google也可提供类似的服务，该服务向UPnP设备130提供可用作机器ID的Google ID。事实上，在某些情况下，UPnP设备可具有多个机器ID，每一个由不同的在线身份提供者 140提供。UPnP设备130维护被授权通过诸如移动设备110等远程设备从其接收UPnP服务 的每一远程用户所采用的用户ID的列表。应该注意，用户ID被分配到各个用户而非用户 用来与UPnP设备进行通信的各个设备。用户ID可以是对于用户而言方便的任何ID。在某 些情况下，该用户ID可以是用户已经出于其他目的而采用的ID，诸如例如Hotmail ID。UPnP设备130将其用户ID的列表提供给在线身份提供者140。UPnP设备还向在 线身份提供者140发布其IP地址中的一个或多个。使用用户ID允许UPnP设备130将对 UPnP设备130的访问仅限于授权的用户。然而在某些实现中，用户ID可能不是必须的。例 如，在某些实现中，可以将机器ID (或与其对应的IP地址)提供给请求该ID的任何用户。在操作中，当授权用户希望从UPnP设备130接收流媒体(或另一 UPnP服务)时， 用户使用他的用户ID来登录到在线身份提供者140。一旦登录，要接收远程UPnP服务的应 用程序，诸如在流媒体服务情况下的流媒体播放器，向在线身份提供者140查询该用户被 授权访问的机器ID的列表。当然，用户将只接收先前已经通知在线身份提供者140该用户 事实上是授权用户的那些UPnP设备的机器ID (在不需要用户ID的那些实现中，可以向请 求该ID的任何用户而非仅仅授权用户提供机器ID)。应用程序选择一个机器ID并请求在 线身份提供者140提供对应于该机器ID的一个或多个IP地址。给定要提供UPnP服务的UPnP设备130的IP地址，应用程序按某种预定 方式从中构建URL。例如，如果IP地址是10. 1.2.3，则应用程序可将URL构造为 https://10. 1. 2. 3:10245/WMPNSSv4/Libraryhfo。该 URL 允许用户访问 UPnP 设备上可用 的媒体库列表。应用程序接着将GET或POST请求发送到该URL，并且UPnP设备130用列举 了该服务器上可用的各个媒体库的XML文档来响应。对于每一媒体库，存在一个或多个远 程URL。应用程序随后可连接到每一远程URL来调用该UPnP服务。在另一实现中，常规UPnP发现过程的限制可在不需要在线服务提供者的情况下 克服。然而，在这种情况下，希望实现远程UPnP访问的UPnP设备需要先前已经通过诸如图 1中的LAN 112等同一网络彼此通信。这个约束是日常情况中常常遇到的约束。例如，如果 移动设备110是膝上型计算机并且UPnP设备130、131和132中的一个是流媒体服务器，则 有时将在同一房屋上使用膝上型计算机来通过LAN 112从服务器接收流媒体。当然，在某 一稍后时间，用户可能希望从远程位置使用膝上型计算机，这需要其通过因特网或其他异 构网络访问流媒体服务器。当膝上型计算机和流媒体服务器首先根据UPnP协议通过LAN彼此建立通信时，他们可交换允许他们随后通过异构网络远程地执行发现过程的信息。即，该信息在设备上预 先提供。该信息包括在膝上型计算机上预先提供的联系信息(例如，名称或其他标识符)。 在稍后时间，膝上型计算机在其想要通过异构网络建立UPnP连接时可使用该信息来寻找 媒体服务器的IP地址。在一个示例中，联系信息被包括在设备描述文档中。因为膝上型计算机和媒体服 务器先前已经通过LAN建立了本地UPnP连接，所以膝上型计算机在其想要通过因特网建立 远程UPnP连接时将已经拥有该文档。例如，“远程访问URL”可被包括在设备描述文档中。 该URL可指定应该用于从远程位置到媒体服务器的任何UPnP连接的“前缀”(例如，基础 URL)。另选地，联系信息可包括媒体服务器的IP地址和端口号。除了提供适当的联系地址 之外，设备描述文档中仅仅出现远程访问URL指示媒体服务器实际上支持远程UPnP连接。 当然，设备描述文档中出现远程访问URL不保证媒体服务器实际上正在接受来自远程位置 的传入连接，因为这个特征可能已经被用户关闭。可被包括在设备描述文档中的句法的一般形式如下<remoteConfig><remoteUrl>https//smith-residence, example, com:10245/WMPNSSv4/libraryl 123/</remoteUrl><remoteUrl>https://10. 1. 2. 3:10245/WMPNSSv4/libraryl 123/</remoteUrl></remoteConfig>在该示例中，句法示出可被包括在设备描述文档中的两个“远程访问URL”。当客户机发送获得远程库的列表的请求时，服务器所返回的XML文档可能具有以 下句法<server><library〉<UDN>该UPnP设备的唯一设备名称</UDN><friendlyName> 该 WnP 设备的人类可读名称 </friendlyName><remoteUrl>https//smith-residence, example, com:10245/WMPNSSv4/libraryl 123/</remoteUrl><remoteUrl>https://10. 1. 2. 3:10245/WMPNSSv4/libraryl 123/</remoteUrl></library><librarv><UDN>该UPnP设备的唯一设备名称<UDN><friendlyName> 该 WnP 设备的人类可读名称 </friendlyName><remoteUrl>
https//smith-residence, example, com:10245/WMPNSSv4/libraryl 124/</remoteUrl><remoteUrl>https://10. 1. 2. 3:10245/WMPNSSv4/libraryl 124/</remoteUrl></library></server>在该示例中，媒体服务器实现两个UPnP设备，其中每一个设备共享媒体库。对 于每一媒体库，存在两个“远程URL”。除T “UDN”、"friendlyName (友好名称)”和 "remoteUrl (远程Url)，，之外，可以有其他XML标签。例如，也可包括诸如“modelName (模 型名称)”、“modelNumber (型号)”和“serialNumber (序列号)”等标签。其中UPnP设备的远程访问通过在远程设备上预先提供信息来完成的实现可由其 本身使用或者作为对其中采用在线身份提供者的实现的附属或补充。例如，可用于提供附 加IP地址或者如果在线身份提供者缓慢或不可用时预先提供可用作备份进程。在移动设备110试图与位于诸如LAN 112等专用网络上的UPnP设备建立远程连 接时产生的另一问题是UPnP设备可能具有只对连接到该专用网络的其他设备可用的专用 (非全局唯一)IP地址。作为结果，移动设备110将不能找到连接到专用网络的UPnP设备 的适当的IP地址。克服该问题的方式可通过回头参考图1来说明。如图所示，网络地址转 换器(NAT) 205与网关121相关联。NAT 205具有对连接到公共异构网络105的设备可用的 公共IP地址。NAT 205还将专用IP地址分配到连接到LAN 112的任何设备，诸如UPnP设 备130-132。NAT 205被设计成通过使专用网络(例如，LAN 112)能够使用非注册(专用) IP地址来进行IP地址简化和转换。NAT 205用作将专用网络与公共网络连接到一起的路由 器。NAT 205将LAN 112中使用的专用地址转换成公共IP地址。作为该功能的一部分，NAT 205可被配置成只将一个公共地址广告给异构网络105，该公共地址表示整个LAN 112。只要分组被转发给对LAN 112外置的设备，NAT 205分配端口并为所分配的端口 提供单个外部连接。为了执行该操作，NAT 205将连接到LAN 112的UPnP和其他设备的地 址和端口信息存储在路由表中。NAT 205从公共异构网络接收分组并将所接收的分组中的 目的地地址和端口号与路由表中的进行比较。NAT 205将分组中继到连接到LAN并与该目 的地地址和端口号对应的设备。虽然UPnP设备可以采用任何适当的NAT技术来执行网络地址转换，但特别合适的 技术是在RFC 4380中描述的Teredo。特别地，Teredo是有利的，因为其允许位于网际协议 第4版(IPv4)的NAT之后的具有网际协议第6版(IPv6)能力的设备与具有IPv6能力的 外部设备进行通信。使用NAT来将专用IP地址映射到公共IP地址需要移动设备知道该NAT的IP地 址。然而，因特网服务供应商分配到NAT的公共IP地址可能改变。因此，移动设备需要知 道NAT的当前IP地址。如果远程访问URL包括UPnP设备的IP地址，则该地址在移动设备 试图远程地连接到一个UPnP设备时可能已经改变。因此，远程访问URL不应该包括UPnP 设备的IP地址。相反，远程访问URL应该包括诸如名称等UPnP设备的标识符。远程访问URL中使用的名称可以是DNS名称，诸如“smith-residence, example.com. ”。使用DNS名称的一个问题是该名称必须在DNS服务器上发布并且移动设备必须使 用DNS协议来将该名称解析成IP地址。然而，对于终端用户而言使用DNS是复杂的，因为 在DNS服务器上发布名称常常不是免费的，或者至少需要用户作出某些配置。可以采用来 代替DNS的替换协议是对等名称解析协议(PNRP)。PNRP是对等分布式名称解析系统。它 不需要中央服务器、是免费的而且不需要用户来配置。当PNRP名称被包括在远程访问URL 中时，它看起来非常像DNS名称，但是用“.pnrp.net”结尾。PRNP名称的一个示例是etworkvc-ttakv7b3b.p070cd7bdbl0737ab08dfbf725b0e6f4afa988a41. pnrp. net.在某些实现中，在远程访问URL中使用Windows Live ID来代替DNS或PNRP名称。 Windows Live ID通常结合通过微软提供的Windows Live产品而变得可用的各种因特网服 务来使用。在使用UPnP来建立远程连接时产生的另一问题是UPnP协议不提供许多安全特 征。因为它被设计成在单个LAN上的设备之间使用，所以连接到LAN上的所有设备都被假定 为是可信的。进一步的假设是没有窃听者正在访问LAN。然而，当移动设备通过使用UPnP 协议的异构网络远程地连接到另一设备时，安全问题变得重要。例如，当UPnP设备从远程 位置接收连接时，设备需要确定其是否能够信任该远程设备。类似地，远程设备需要确保其 连接到了正确的目的地。另外，保护在两个设备之间传递的数据变为一个严重的问题。为了加强UPnP连接的安全性，在某些实现中，所有UPnP请求通过诸如HTTPS(带 有安全套接字层加密的HTTP)等安全应用层通信协议而非HTTP(超文本传输协议)来发 送。HTTPS加密所有数据。另外，还采用客户机侧认证。如果是UPnP是流媒体服务器的情况，则也有独立于UPnP连接操作的流传输连接。 在LAN中，流传输连接或链路通常使用HTTP或RTSP协议。然而，在流传输到因特网或其他 异构网络上的远程设备时，流传输连接或链路也可使用HTTPS。为简明起见，在某些实施例 中，流媒体服务器通过同一 TCP端口(例如，1024 上的HTTPS接收UPnP请求和流传输请 求。在其他实现中，不同的TCP端口可用于UPnP请求和流传输请求。通常，HTTPS仅允许客户机(例如，用作UPnP控制点的移动设备)认证服务器(例 如，流媒体服务器)。这通过使服务器呈现公钥证书来实现。然而最近，HTTPS已经延伸到 也支持客户机侧认证。在这种模式中，客户机也被要求来呈现密码证书。这允许双方彼此 互相认证。因此，在某些实现中，采用HTTPS的客户机侧认证功能。通常，证书由可信证书授权机构来签署。例如，在采用在线身份提供者的情况下， 证书可以是由在线身份提供者提供并由适当的授权机构(例如，Windows Live)签署的SSL 证书。UPnP设备可通过检查其签名来验证该证书并且如果用户ID在被允许访问特定媒体 库的ID列表上则授予客户机访问权。然而，在某些实现中，不使用这些证书授权机构，因为 让授权机构签署证书的过程可能不是免费的而且可能需要用户干预。相反，每一 UPnP设备 向其自身发放证书。这些证书被称为自签署证书。客户机和服务器通过将其与可信证书列 表进行比较来认证证书。可信证书从LAN上的UPnP设备获得。在预先提供的情况下，作为期间将设备描述文档提供给移动设备的预先提供步骤 的一部分，在某些情况下，每一 UPnP设备还可提供其认证证书，该证书可由在线服务提供 者在采用这一服务提供者的那些情况下发放。或者，可以采用自签署证书。虽然证书可被包括在设备描述文档中，但是这可能是有问题的，因为证书可能相当大。相反，在某些情况 下，使证书通过作为UPnP设备主存的UPnP服务的内容目录服务或连接管理器服务中的新 UPnP动作而变得可用可能是优选的。一旦远程设备使用HTTPS连接，它将证书呈现给UPnP 设备，该证书可与已知证书列表进行比较。为了阻止欺诈者使用别人的证书，私钥与每一证 书相关联。SSL要求消息用该私钥来签署。欺诈者不能使用该证书，因为他们不知道正确的 私钥。因为认证证书是与UPnP设备描述文档一起预先提供的，所以不仅流媒体服务器 而且移动设备(UPnP控制点)必须是UPnP设备。当然，移动设备可能不需要指定“远程访 问URL”，因为作为控制点它一般不从服务器接收传入UPnP连接。在某些实现中，可以呈现诸如用户名和口令等拥有这些凭证的一方在建立远程连 接时必须证明其拥有的其他类型的凭证，而不是出于认证目的来呈现SSL证书。如前所述，在预先提供的情况下，设备描述文档中存在远程访问URL不保证媒体 服务器实际上正在接受来自远程位置的传入连接，因为这一特征可能已经被用户关闭。帮 助移动设备确定远程访问当前是否被启用的一种方式是通过内容目录服务(CDQ。CDS通 常用于枚举UPnP设备上可用的内容(视频、音乐、图片等等)。在当前情景中，CDS被扩展 成允许移动设备来确定远程访问当前是被启用还是禁用。即，移动设备能够调用新动作来 确定远程访问特征的状态。如果状态改变，则CDS将事件通知发送到移动设备以及任何其 他感兴趣的控制点。这种方法的一个限制是其只在移动设备和UPnP设备两者在同一 LAN 上时才有效，而当移动设备和UPnP设备彼此进行远程通信时无效。因此，这种技术仅向移 动设备提供了 UPnP设备的最后已知状态而非其当前状态。然而虽然不是结论性的，但该信 息作为暗示UPnP设备的当前状态仍然可被证明是有用的。
权利要求
1.一种用于通过广域通信网络105在通用即插即用(UPnP)控制点110和UPnP设备 130之间建立通信的方法，所述方法包括通过所述广域通信网络105访问用于远程地联系所述UPnP设备130的联系信息；通过所述通信网络105联系至少部分地从所述联系信息中确定的网络地址处的所述 UPnP设备130以根据UPnP协议建立网络链路；以及通过所述网络链路调用所述UPnP设备提供的服务。
2.如权利要求1所述的方法，其特征在于，还包括通过所述广域通信网络来联系第三 方以获得所述联系信息。
3.如权利要求2所述的方法，其特征在于，联系所述第三方包括使用所述UPnP设备 130先前提供给所述第三方的用户标识符来访问所述第三方。
4.如权利要求2所述的方法，其特征在于，还包括从所述第三方接收所述UPnP设备 130的机器标识符。
5.如权利要求4所述的方法，其特征在于，还包括请求并接收与所述机器标识符相关 联的IP地址。
6.如权利要求5所述的方法，其特征在于，还包括至少部分地基于所述IP地址来构造 所述网络地址。
7.如权利要求1所述的方法，其特征在于，还包括在所述UPnP控制点上预先提供所述联系信息。
8.如权利要求7所述的方法，其特征在于，所述联系信息被包括在所述UPnP控制点 110上预先提供的所述UPnP设备130的设备描述文档中。
9.如权利要求1所述的方法，其特征在于，所述联系信息包括统一资源定位符(URL)。
10.如权利要求1所述的方法，其特征在于，所述网络链路符合安全套接字层上的超文 本传输协议(HTTPS)。
11.如权利要求1所述的方法，其特征在于，还包括在调用所述UPnP设备提供的服务之 前将所述UPnP设备的认证凭证呈现给所述UPnP控制点。
12.如权利要求1所述的方法，其特征在于，还包括在调用所述UPnP设备提供的服务之 前从所述UPnP设备接收认证凭证。
13.如权利要求1所述的方法，其特征在于，所述UPnP控制点是移动设备而所述UPnP 设备是流媒体服务器。
14.如权利要求7所述的方法，其特征在于，还包括当所述UPnP控制点和所述UPnP设 备根据所述UPnP协议通过LAN彼此通信时预先提供所述联系信息。
15.如权利要求14所述的方法，其特征在于，还包括从所述UPnP设备接收指示远程访 问是被启用还是禁用的状态信息，其中所述状态信息在所述UPnP控制点和所述UPnP设备 通过所述LAN彼此通信时接收。
16.一种用于允许位于彼此的远程的第一和第二 UPnP设备之间的交互的方法，所述方 法包括通过访问第一 UPnP设备的联系信息来执行所述第一 UPnP设备的UPnP发现过程；以及使用所述联系信息来在所述第一 UPnP设备和第二 UPnP设备之间建立UPnP网络通信 链路，所述第二 UPnP设备包括UPnP控制点。
17.如权利要求16所述的方法，其特征在于，所述UPnP发现过程包括使用所述联系信 息来获得所述第一 UPnP设备的IP地址。
18.如权利要求16所述的方法，其特征在于，所述UPnP发现过程包括通过因特网来联 系第三方以获得所述联系信息。
19.如权利要求18所述的方法，其特征在于，还包括从所述第三方接收所述第一UPnP 设备的IP地址。
20.如权利要求16所述的方法，其特征在于，所述UPnP发现过程包括访问包括所述联 系信息的预先提供的设备描述文档。
全文摘要
通用即插即用(UPnP)技术可在因特网或其他广域通信网络上使用。在一个说明性示例中，第一启用UPnP的设备通过因特网将诸如流媒体等UPnP服务提供给各个用户。第一启用UPnP的设备向在线身份提供者提供被授权从远程位置访问第一启用UPnP的设备的那些用户的用户ID。当用户希望从第一启用UPnP的设备接收UPnP服务时，用户使用他的用户ID来登录到在线身份提供者并从在线提供者接收与第一启用UPnP的设备相关联的IP地址。用户的应用程序从IP地址中构造URL并联系该URL处的启用UPnP的设备。用户的应用程序随后可调用所需UPnP服务。
文档编号H04L29/06GK102077546SQ200980124865
公开日2011年5月25日 申请日期2009年6月25日 优先权日2008年6月25日
发明者A·E·克莱门茨, E·A·埃雷迪亚, S·艾亚尔 申请人:微软公司