基于ui的家用网络桥接的制作方法

文档序号:7645232阅读:193来源:国知局
专利名称:基于ui的家用网络桥接的制作方法
技术领域
本发明涉及家用网络,尤其涉及桥接包含软件结构不同的群集的网络。
背景技术
看起来不会出现可用于家庭中每一设备的一个通用网络标准。多种软件结构标准共存,并将不断出现新的标准。将为新的设备开发出新的标准接口,所述设备的问题由这些标准来专门解决。设计家庭应用程序以智能地使用家中可用的所有设备,但是不能处理当前使用的所有网络标准或者在将来变得可用。类似地,设备自身将不能支持现存的每种家用网络标准。因此,不同的子网或群集之间需要桥接器,每一桥接器遵守一种特定标准。桥接器用于透明地将符合第一种网络集群中的第一标准的一个设备表示为符合第二种网络集群中的第二标准的一个设备。结果是可用于为第一标准撰写的软件应用程序和为第二标准撰写的软件应用程序的家用网络的统一观点。
家用网络标准通常解决了协议栈的较低层(最高到传输层,例如HomePNA、HomeRF)或较高层(从传输层到应用层)。在下述的说明中,一般参照第二种家用网络标准。这些标准的例子是HAVi、UpnP和Jini。
家用网络标准通常提供两种应用程序(或客户机)方式之一控制设备(或服务器)编程控制和基于UI(用户接口)的控制。
编程控制是指基于向设备发送标准化消息的控制,或基于调用一个标准化API,导致向设备发送消息的控制。这种控制对于控制设备的应用程序是有用的,而不需要任何直接的用户交互作用。在这种情况下,控制器和可控制的设备使用可以被交换的一组预定的消息。即,控制器必需预先知道可控制设备的类型。
基于UI的控制是指使用从一个控制设备向一个可控制设备发送用户交互作用的控制。在此,用户与一个UI客户机或浏览器交互作用,用户动作导致消息被发送给可控制设备上的一个UI服务器。使用一个特定的UI协议来交换消息,它的例子是HTML(在UpnP中使用)和DDI(在HAVi中使用)。缩写“DDI”表示数据驱动交互作用(DataDriven Interaction),是指在一侧上的需要显示其用户接口的应用程序或DCM和另一侧上的一个显示设备之间执行的一种协议。DDI的目标是一个设备的DCM的一部分。缩写“DCM”表示设备控制模块。一个DCM是表示HAVi网络上的一个设备或功能的软件单元。DCM表示用于该设备的HAVi定义的API。DCM本质上是动态的如果一个设备被插入或者从网络中删除,相应地,需要在网络中安装或删除用于该设备的DCM。DCM是HAVi概念的中心和将新的设备和特性容入HAVi网络的灵活性的根源。DDI支持与设备的用户交互作用。
本质在于UI协议并未定义信息的种类或由其传输的控制,它仅仅定义了如何打包用户动作并将它们从客户机发送给服务器。另外,它定义了如何描述用户接口单元(也称作小器具(widget))并将其从服务器发送回客户机以显示。这意味着即使控制器应用程序并不知道可控制设备的种类也可以进行基于UI的控制。
只要控制器和可控制设备使用相同的UI协议通信,并且用户在场,就可以控制可控制设备。另外,UI协议使一个设备能够呈现超出标准化设备类型性能的特性,换句话说,它使得标准化设备能够区分其自身和与其竞争的设备。
发明概述当在家用网络标准之间进行桥接控制时,通常的方法是将标准A的第一软件结构中设备类型的编程接口转换成不同于标准A的标准B的第二软件结构中设备类型的编程接口,和反之。类似地,通常的方法是将标准A中的设备类型的UI接口转换成标准B中设备类型的UI接口,和反之。本发明人意识到了与这种方法相关的某些问题,并更详细地分析了桥接从而提供一种解决方案。


图1用图来说明存在多种选择。图1图示家用网络100的一部分,该网络包括具有符合标准A的软件结构的一个群集102和具有标准B的软件结构的群集104。网络100具有位于群集102中的网络100上的X型设备106。群集102和104被桥接以便可以从群集104通过软件表示108来控制设备106。假设设备106及其在群集104中原理上的表示108可以分别具有基于UI的控制接口110和112和编程控制接口114和116。该图列出了四种桥接选择118、120、122和124。
桥接器118提供从UI接口110到编程接口116的转换。如前所述,UI接口比编程接口更加灵活(或者较低的标准化),所以从一个UI接口转换成一个编程接口非常困难,并且对于诸如HAVi和UpnP的现有家用网络标准是不可能的。这留下其它三个选项-用于将标准A中的UI接口110转换成标准B中的UI接口112的桥接器120。根据标准A和B的类似性,这是可行或者不可行的。例如,将一个UpnP设备UI转换成一个HAVi设备UI非常困难,因为UPnP在设备UI中允许HTML和任意一种脚本。HAVi将DDI协议用于设备UI,同时HTML可以转换成DDI,而转换HTM加上脚本几乎是不可能的。
-用于将标准A中的编程接口114转换成标准B中的编程接口116的桥接器122。根据标准A和B所覆盖范围的大小,这是可能或不可能的。例如,如果UpnP定义日光灯的编程接口,HAVi并不定义日光灯的“语义上相同”的编程接口,则这种设备不能用编程方式来桥接。
-用于将标准A中的编程接口114转换成标准B中的UI接112的桥接器124。这种转换需要在运行期间标准A中设备的编程接口可以作为用于转换目的的数据被使用。这需要“白盒”设备描述机制,其中一个应用程序可以在运行期间检索与设备接口有关的所有信息。换句话说,应用程序不需要依靠内建该种设备接口的信息,它可以在运行期间获得该信息。这种转换还需要在编程接口中使用的数据类型可以被映射为“模态兼容”GUI单元。在这种情况下,参考共同待审的Eugene Shteyn于1998年2月10日提交的美国申请,序列号为09/165,682,标题为将控制属性映射到模态兼容GUI单元上(CONTROL PROPERTY IS MAPPED ONTO MODALLY COMPATIBLE GUIELEMENT)。将标准A中的编程接口转换成标准B中的UI还需要由标准B的UI机制支持该组模态兼容的GUI单元。还需要编程接口的抽象层适合于用户层交互作用。
上述所有的转换可以在一种桥接设备中共存。事实上,一个桥接器应当以尽可能多的方式来表示另一网络中的设备,因为它并不知道哪一个接口最适合于桥接器另一侧上的应用程序/用户。
本发明基于标准A中编程接口到标准B中UI的转换可以被用作一个桥接器的认识。在下文中,在涉及桥接工作的两个标准上讨论要求。下面以UPnP编程接口到HAVi设备UI(DDI目标)的转换方案的形式给出桥接选择的实施例。
本发明涉及一种在家用网络中能够将第一功能的第一群集桥接到第二功能的第二群集的方法。第一群集具有第一软件结构,它通过一个编程接口提供第一功能的控制。UpnP是这样一种结构的例子。第二群集具有第二软件结构,它通过一个基于UI的接口提供第二功能的控制。HAVi是后一种结构的例子。本发明中的方法包括提供编程接口到基于UI的接口的转换。在UPnP-HAVi的例子中,该方法包括从一个UpnP设备描述文件生成一个HAVi DDI目标软件单元。
本发明的方法可以由一个服务提供者来实现。用户通知服务提供者新的设备被添加给他/她的网络,在此基础上提供者可以生成转换模块以作为桥接器的一部分被安装在用户网络上。
本发明还涉及具有这些使用不同软件结构的群集的家用网络。第一群集具有通过一个编程接口提供第一功能控制的第一软件结构,第二群集具有通过一个基于UI的接口提供第二功能控制的第二软件结构。该网络具有一个第一和第二群集之间的桥接器,用于将编程接口转换成基于UI的接口。该网络最好包括一个生成器,用于根据一个UPnP设备描述文件生成一个HAVi DDI目标。
本发明的一个方面在于用于在家用网络上使用的桥接软件,其中该网络包括第一功能的第一群集和第二功能的第二群集。第一群集具有通过一个编程接口提供第一功能控制的第一软件结构,第二群集具有通过一个基于UI的接口提供第二功能控制的第二软件结构。桥接软件是为根据编程接口到基于UI的接口的转换耦合第一和第二群集而运行的。该软件包括一个生成器,用于在UPnP-HAVi网络中从一个UpnP设备描述文件生成一个HAVi DDI目标。
附图简要说明通过例子并参考附图,将更加详细地解释本发明,在附图中图1是表示桥接选择的方框图;图2A和2B是在下述说明中提到的UPnP和HAVi信息项的表格;图3图示家用网络的一部分;图4、5和6图示家用网络中UPnP和HAVi群集之间的交互作用。
在所有的附图中,相同的参考号表示类似或相应的部件。
详细实施例UPnP标准通过一个称作“描述文件”的XML文件来定义一个设备的编程接口。应用程序可以通过HTTP在运行期间提取该文件,所以UpnP满足“白盒”标准。
HAVi通过用IDL表述的API的出版物定义了一个设备的编程接口。API定义依靠于称作FCM类型的唯一标识符。缩写“FCM”表示功能组件模块。一个DCM(参见上文)包含一个FCM,用于所表示的设备中的每个可控制的功能。当前,HAVi定义了FCM和相应的API,用于诸如调谐器、VCR、基于HDD的存储器、AV显示器、照相机和调制解调器的功能。在运行期间,HAVi应用程序可以从一个被控制的设备中提取这种FCM,并能够根据其内建的与链接到该种FCM的接口有关的信息来程序化地控制该设备。因为HAVi应用程序需要预先知道链接到该种FCM的接口,HAVi并不符合“白盒”标准。
在Jini中,一个应用程序通过使用一个查找业务来提取一个设备的编程接口,所述查找业务返回一个到设备的Java目标表示的远程(RMI)参考。Java RMI(远程方法调用)被用于向被控制的设备发出控制命令。因为Java具有“反射”功能,可以在运行期间确定远程目标(设备)参考的接口(以Java成员变量和方法)。因此,Java满足“白盒”标准。
UpnP设备的编程接口可以使用下面类型中的任何一种布尔、整数(称作i4)、浮点(称作r8)、字符串、日期时间(数据和时间信息)或十六进制编码二进制数据(称作bin.hex或bin.bin64)。这些种类可以被直接映射到在大多数UI协议中发现的通用GUI单元,所述协议包括DDI(在HAVi中使用)和HTML(在UpnP中使用)。参见图2A和2B。Jini并未定义一个具体的设备UI协议。
Jini设备的编程接口可以使用任一Java目标。HAVi设备的编程接口可以使用任意一种IDL类型。因此,HAVi和Jini设备接口通常不能被轻易地映射到一个UI。当然,可以想象对于使用IDL或Java的富数据类型特性的子集的一种特定设备类型,可以进行一个UI映射。例如,对于仅使用基本Java类型(无Java目标)的一个Jini接口,可以进行一个UI映射。
总之,定义一种UPnP设备的编程接口到HAVi中DDI UI的普通转换是最有价值的。
UPnP到编程接口到HAVi DDI UI的转换UPnP设备的编程接口在一个描述文件中被描述。该文件指定一个具有零个或多个(子)设备的根设备。每个设备可以具有另外一个子设备等的列表。没有任何子设备的一个设备(该树中的一个“叶”)包含一个单独的业务。一个业务由一个状态变量列表和一个动作列表组成。业务并不具有子业务。状态变量具有“名称”字段、“类型”字段和可选字段以限制种类的范围。动作具有“名称”字段和参数列表。每个参数由一个“名称”字段和一个称作“相关状态变量”的字段来描述。这个字段必须参考状态变量名称,并且它间接地定义动作参数的类型。
本发明的一个方面是从UpnP设备描述文件生成一个HAVi DDI目标。该转换同时涉及DDI目标的静态方面和动态方面。
对于静态方面需要为UpnP数据类型定义DDI单元或小器具;需要定义对应于一个UpnP业务的所有DDI单元的体系结构;需要定义对应于一个UpnP设备的所有DDI单元的体系结构。
对于动态方面需要定义设备和业务之间的DDI导航;需要定义应用程序和设备之间的一个“对话”的开始和结束;需要定义受控UpnP设备上异步改变的效果;需要定义被转发给所生成的DDI目标的用户动作的效果。
下面将进一步详细描述这些方面。
静态将UpnP数据类型转换成HAVi DDI单元UpnP数据类型在业务描述中以两种方式出现,即直接地作为一种状态变量的类型,和间接地通过用于一个动作参数的<relatedStateVariable>的参考。
一些DDI单元是“交互作用的”它们允许一个用户与它们交互作用。例如,一个按钮是交互作用的,而一个文本标签不是交互作用的。根据环境,一些交互作用的DDI单元可以是“临时”非交互作用的或停用的。为了表示这一点,交互作用DDI单元具有一个“交互作用”字段。因为UpnP允许仅通过动作来改变状态,表示动作参数的DDI单元将把这个字段设置为ENABLED(使能)。然而,表示一个设备状态变量当前值的DDI单元将把这个字段设置为DISABLED(停用)。
一些UpnP数据类型可以具有附加的说明符,表示对其可能的数值范围的特别限制。在一些情况下,这可以被用于生成一些更合适的DDI单元。
静态将一个UpnP业务转换成一个DDI结构一种业务包括一个状态变量列表和一个动作列表。状态变量具有一个“名称”字段、“类型”字段和可选的用于限制类型范围的字段。动作具有一个“名称”字段和一个参数列表。每个参数用一个“名称”字段和一个称作“相关状态变量”的字段来描述。这个字段必须参考一个状态变量名称,它间接地定义动作参数的类型。
在DDI中,单元可以以组的形式被组织,从而建议某一种类耦合到一个DDI显示引擎(称作Ddi控制器)。这种耦合可以被用于确定屏幕上单元的组织结构,或者确定导航。一个UpnP业务可以被转换成下述DDI结构-一个DdiPanel单元,panelName设置为业务的<serviceType>字段。DdiPannel包含两个DdiGroup单元和一个DdiPaneLink单元;-一个DdiGroup单元,groupName设置为“State variable”。这一组的“element”字段应当包含根据上述映射类型从转换所有的UpnP状态变量获得的DDI单元。所有这些Ddi单元应当具有它们被设置为DISABLED的交互作用属性。
-一个DdiGroup单元,groupName被设置为“Actions”。这一组的“elements”字段包含用于每个独立的UpnP动作的DdiGroup单元。每个这些DdiGroup单元包括-DdiButton单元,它的“pressedLabel”和“releasedLabel”字段被设置为动作的<name>字段。
-Ddi单元,根据应用于动作参数的<relatedState Variable>字段的类型映射,用于动作的每个输入参数。所有这些Ddi单元应当具有它们的被设置为DISABLED的交互作用属性。
-Ddi单元,根据应用于动作参数的<relatedState Variable>字段的类型映射,用于动作的每个输出参数。所有这些Ddi单元应当具有它们的被设置为ENABLED的交互作用属性。
-DdiPanelLink单元,表示“父”设备将其linkName字段设置为父设备的<deviceType>或<friendlyName>。可选地,它可以将linkBitMap字段设置为父设备描述中的可用和HAVi兼容的<icon>数值。
静态UpnP设备到DDI结构的转换UpnP中的一个设备描述文件指定一个具有零个或多个(子)设备的根设备。每个设备可以具有另一个子设备等列表。另外,每个设备具有与此相关的某些字段,例如设备图标、制造商名称等。一个(根或子)设备可以被转换成下述DDI结构-一个DdiPanel单元,panelName被设置为设备的<deviceType>或<friendlyName>字段。DdiPanel包含多个DdiPanelLink单元,每个用于它所包含的每个子设备或业务。
-一个DdiPanelLink单元,表示一个子设备应当使它的linkName字段设置为子设备的<deviceType>或<friendlyName>字段。可选地,它可以将linkBitMap字段设置为设备描述中的可用和HAVi兼容的<icon>数值之一。
-一个DdiPanelLink单元,表示一个业务应当使它的linkName字段设置为该业务的<serviceType>字段。
每个非根子设备应当具有-一个表示“父”设备的DdiPanelLink单元将使它的linkName字段设置为父设备的<deviceType>或<friendlyName>字段。可选地,它可以将linkBitMap字段设置为设备描述中的可用和HAVi兼容的<icon>数值之一。
所有的DdiPanelLink应当使它的交互作用字段设置为ENABLED。可选地,面板可以包含DdiText单元,交互作用字段设置为DISABLED,textContent字段保存用于下述任何一个UpnP设备描述字段的字符串值<deviceType>;<friendlyName>;<modelDescription>;<modelName>;<modelNumber>;<modelURL>;<manufacturer>;
<manufacturerURL>;<serialNumber>;<UDN>
最后,它可以将一个DdiIcon单元设置为设备描述中的可用和兼容的<icon>值之一。
在图3中表示示例性UI,其可以根据以此方式结构的DDI目标由DDI控制器提供。
图3图示了家用网络100的一部分300。网络100具有一个根设备302一个TV/VCR组合和两个子设备一个TV 304和一个VCR 306。TV 304具有三种业务音频业务308、视频业务310和调谐器业务312。VCR 306也具有三种业务时钟业务314、调谐器业务316和磁带业务318。这个例子表示了<friendlyName>字段(“我卧室的娱乐(MyBedRoom Fun)”)、<manufacturer>字段(“飞利浦”)、<modelName>字段(“AZ1010”)、<modelDescription>字段(“19TV/VCR组合”)和<icon>字段(TV图片)。磁带业务318表示名称为“传输”的一个字符串状态变量320,带有<sllowedValueList>说明符{“播放”、“停止”、“记录”}。而且,它表示三种动作“播放”、“停止”和“记录”,其中“记录”动作具有涉及一个状态变量(在此未图示)的单个字符串参数,带有<allowedValueList>说明符{“标准”、“长”、“扩展”}。
动态导航设备的用户接口如上所述,每个(根或子)设备和每种业务被映射到一个独立的DdiPanel单元。DdiPanelLink单元用于从根设备经零个或多个中间子设备向下横移到业务。另外,在每一层上,除了根设备层之外,DdiPanelLink被用于在设备层中向上移动。当DDI控制器设备上的一个用户点击面板时,ACT_SELECTED类型的用户动作将被发送给DDI目标。DDI目标应当通过返回表示子设备/业务(在向下层导航的情况下)或父设备(在向上层导航的情况下)的targetPanel来对其响应。DDI目标并不需要与它所表示的UpnP设备通信。
动态开始/结束一个对话DDI控制器和所生成的DDI目标之间的对话在图4中图示。在DDI目标在步骤402中接收一个DDI预约之后,它在步骤404中检索UpnP描述文件。根据该描述文件,DDI目标能够在步骤406中构建DdiPanel结构和它所包含的所有DdiElement。另外,在步骤408中,使用GENA机制,DDI目标预约UpnP设备的状态变化。“GENAA”代表UpnP环境下的普通事件发生通知(Generic Eventing Notification)。事件发生是源设备在任何时间上初始化到希望从源设备接收事件的一个或多个其它设备的连接的能力。事件用于在多个设备之间建立同步。在UpnP中,事件主要用于状态变化的异步通知。TCP/IP为连接提供支持以承载事件信息。GENA添加用于建立所感兴趣的设备之间关系的规约和一种寻址方案以允许事件消息的发送。GENA使用HTTP寻址和打包。对于每个业务都需要步骤410中的各个预约。因为一个GENA预约返回所有状态变量的当前值,DDI目标与UpnP设备“同步”,并且当DDI控制器请求它们时能够返回用于所有DDI单元的正确值。在描述文件被检索(如上面所表示的)之后,或者以一种“实时”方式,恰在DDI控制器请求包含状态变量值的面板之前,DDI目标可以立即预约状态变化。在DDI目标在步骤412中接收一个DDI取消预约之后,它在步骤414中自己取消对状态变量变化的预约。
动态在UpnP设备上的异步改变当一个对话已经在一个DDI控制器和一个DDI目标之间建立时,设备依然可以通过其它一些控制以异步方式改变状态。这可以是另一个HAVi或UpnP应用程序,或者甚至可以是用户按下物理设备人工控制面板上的一些物理按钮。这种情况在图5中被示意性地图示。
动态在DDI控制器上的用户动作图6表示当用户通过运行DDI控制器的设备的显示器与UpnP设备交互作用时产生的结果消息。操作模式是用户首先修改与动作参数对应的小器具,当用户做完之后,在设备上按下调用该动作的按钮。使用“停用”或“非交互作用”模式中的小器具来显示动作的结果,包括任意的输出参数。
图6表示典型地一个用户首先修改对应于动作参数的小器具。这导致“UserAction”消息被发送给DDI目标。目标不会将这些交互作用转发给UpnP设备,但是使用它们来本地更新用小器具表示的参数值。当用户完成之后,他/她在设备上按下表示动作的按钮。在DdiButton的“RELEASE”事件时,DDI目标将使用当前的参数值来构建一个SOAP(简单目标访问协议),并将其发送给UpnP设备。同步地执行SOAP动作,当该动作被成功执行时,DDI目标将通过为输出参数小器具返回一个DDI“改变报告”来完成用户动作,如果有的话。从SOAP响应消息提取输出参数值。
对于SOAP,这是由许多工业参与方共同建立的一个协议,并允许应用程序在互联网上相互通信,提供一个框架,例如用于连接网站和应用程序以创建Web业务。Web业务将站点和应用程序相互链接以执行各个组件单独不能执行的功能。
典型地,在受控设备上调用的动作也将改变设备的状态,并且在一定时间之后,一个GENA NOTIFICATION消息将被发送给DDI目标表示用于所有已改变状态变量的新值。这又将导致NotfyDdiChange消息,如前所述,并最终导致DDI控制器设备的显示屏上的某种图像变化。
图6表示没有错误的情况,即最终由UpnP设备发出的SOAP响应已经返回编码OK。在错误的情况下,DdiTarget可以使用DDI中的AlertPanel功能程序来向用户指示故障。“告警面板”可以包含保存SOAP响应<faultSting>字段的一个DdiText单元。这在图7中被图示。
Eugene Shteyn于1998年10月2日提交的美国专利申请,序列号为09/165,682(代理人编号PHA 23,484),标题为“控制属性被映射到模态兼容GUI单元上”,涉及一种家用网络系统,包括一个电子设备和一个连接到该设备的控制器。该设备将其功能的简单描述提供给控制器。控制器能够通过与简单描述的交互作用来控制设备的功能。简单描述指定一种控制功能的模态。在指定模态的控制下,系统使功能的控制与控制器的模态兼容控制能力相关。所表示的模态例如可以是“布尔”、“浮点”、“整数阵列”。
术语“模态”是指表示功能可控制性特征的属性。在本发明中,功能性的模态被映射到控制器的模态兼容性能上,而不需要控制器必须知道设备的功能性都是关于什么。例如,假设模态在语义上是一个布尔值。则布尔控制属性可以被映射到一个具有布尔字符的UI单元上,假设两个状态之一,例如一个“开启/关闭”开关或“高/低”控制杆。当用户随后与这个单元交互作用时,映射到其上的功能性被放入给两个状态之一。在HAVi系统中,简单描述被上载,最好包括一个UI(例如话音控制)或GUI,并且用户接收一种环境以确定他/她与UI交互作用的结果。如果模态是一组离散值,控制属性可以被映射到一个GUI单元上,可以假设三个或多个离散状态之一,例如用于设备上的信道选择和用于在多个设备之间选择的拨号等。如果被指定的模态在语义上是一个浮点数值范围,轻易地进行到连续可变控制特性上的映射是可行的,例如显示器上图像的亮度或音量。在另一个例子中,指定的模态在语义上是一个阵列。该阵列包括多于一个的分量。例如,一个布尔阵列因而可以被映射到一组GUI单元上以实现例如在不同设备之间的菜单选择或检查框列表。一个浮点模态阵列可以被映射到一组GUI单元上,表示滑动器,例如用于调整通过家用网络控制的家庭安全系统中照相机的摄像角度和放大比。注意控制器并不需要知道被控制设备的功能的有关信息。它所需要做的仅是使一个功能根据其模态的语义受一个控制应用程序的控制。
Eugene Shteyn于1999年6月25日提交的美国专利申请,序列号为09/340,272(代理人编号PHA 23,634),标题为“桥接多家用网络软件结构”,涉及不同软件结构的家用网络的桥接。参考设备的软件表示和第一网络上的业务被自动创建。参考在语义上足以能够为第二网络自动创建至少部分功能相同的软件表示,以便可以从第二网络访问第一网络的设备和业务。这个文件还进一步详细讨论了HAVi的一些方面。这个文件还解决了HAVi、家用API和Jini软件结构。
Adrian Turner等人于1998年9月25日提交的美国专利申请,序列号为09/160,490(代理人编号PHA 23,500),标题为“根据用户简档启动互联网的设备的定制升级”涉及一种服务器系统,它维持用户电子网络装置的特定终端用户的用户简档和用于这种装置的新技术特性的数据库。如果用户简档和一种新的技术特性之间匹配,则用户指示接收更新或销售出价的有关信息,用户通过选择网络被通知以获得特性。
Eugene Shteyn于1998年11月10日提交的美国专利申请,序列号为09/189,535(代理人编号PHA 23,527),标题为“家用网络协作方面的升级”,涉及一种服务器,它访问设备的目录和用户家用网络上的性能。目录例如是由HAVi或Jini结构提供的一个查找业务。服务器还访问一个包含网络特性信息的数据库。服务器确定是否可以根据目录列表和用户简档来增强在用户网络上存在的设备之间的协作。根据这些标准,如果存在涉及协作的特性,则用户被通知。
授权给Paul Chambers和Saurabh Srivasta的美国专利5,959,536(代理人编号PHA 23,169),标题为“任务驱动分布式多媒体用户系统”涉及一种控制系统,包括多个用户电子设备和连接到该设备用于控制设备之间交互作用的任务驱动控制装置。该控制装置作用于每个用户设备的相应软件表示。通过将任务的可变复杂性封装在一个软件表示中,可以根据需要复杂或简单以将性能提高到常规水平。因为接口的层次为设备所共有,应用程序可以统一地管理设备,每一设备具有不同的复杂度。
权利要求
1.一种能够在家用网络中桥接第一功能的第一群集和第二功能的第二群集的方法,其中-第一群集具有第一软件结构,它通过编程接口提供第一功能的控制;-第二群集具有第二软件结构,它通过一个基于UI的接口提供第二功能的控制;-该方法包括提供编程接口到基于UI接口的转换。
2.权利要求1的方法,其中第一软件结构符合UpnP,第二软件结构符合HAVi。
3.权利要求2的方法,其中提供包括从一个UpnP设备描述文件生成一个HAVi DDI目标软件成分。
4.一种家庭网络,包括-第一功能的第一群集;和-第二功能的第二群集;其中-第一群集具有第一软件结构,通过编程接口提供第一功能的控制;-第二群集具有第二软件结构,通过基于UI的接口提供第二功能的控制;-该网络具有第一群集和第二群集之间的一个桥接器,用于将编程接口转换成基于UI的接口。
5.权利要求4的网络,其中第一软件结构符合UpnP,第二软件结构符合HAVi。
6.权利要求5的网络,包括一个生成器,用于从一个UpnP设备描述文件生成一个HAVi DDI目标软件成分。
7.在家用网络上使用的桥接软件,其中-该网络包括第一功能的第一群集和第二功能的第二群集;-第一群集具有第一软件结构,它通过编程接口提供第一功能的控制;-第二群集具有第二软件结构,它通过基于UI的接口提供第二功能的控制;-操作桥接软件以便根据编程接口到基于UI接口的转换耦合第一群集和第二群集。
8.权利要求7的软件,用于耦合符合UpnP的第一软件结构和符合HAVi的第二软件结构。
9.权利要求8的软件,包括一个生成器,用于从一个UpnP设备描述文件生成一个HAVi DDI目标软件成分。
全文摘要
一个家庭网络包括一个UpnP群集和一个HAVi群集。UpnP使用基于在设备之间发送的标准化消息的编程设备接口。HAVi也使用编程接口,但不必预先知道正确的设备类型和FCM。另外,当前的UpnP和HAVi标准并未定义由于语义不同可被轻易地相互映射的设备。为了克服这个问题,通过表示HAVi群集上的一个UpnP设备来桥接这些群集,其中UpnP设备的描述文件用于生成一个HAVi DDI目标以便通过一个HAVi UI能够进行UpnP设备的基于UI的控制。
文档编号H04L12/66GK1708969SQ01802157
公开日2005年12月14日 申请日期2001年7月9日 优先权日2000年7月25日
发明者J·R·穆恩 申请人:皇家菲利浦电子有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1