专利名称：信息处理装置和方法
技术领域：
本发明涉及一种信息处理装置和方法，更具体地说，涉及一种用于实现廉价系统的信息处理装置和方法，在该系统中，可以容易且可靠地控制连接到基于IEEE 802的网络的设备，并且这些设备可以相互通信。
背景技术：
现在，使用IEEE(Institute of Electrical and Electronics Engineers，电气和电子工程师协会)802网络的网络已经很普及。该IEEE 802是一种主要用于相互连接个人计算机的网络，并且根据通用即插即用(Universal Plug and Play，UPnP)协议，每台个人计算机可以控制其他个人计算机。
UPnP代码包括多种传输协议，如“设备描述”中用于描述机器信息的代码、SOAP(Simple Object Access Protocol，简单对象访问协议)、GENA(General Event Architecture，一般事件架构)等。
然而，这些代码没有编码成机器模型或命令系统，因此，产生一个问题是，机器不能相互通信以使一台机器能够控制另一台机器。
为了允许这种通信，需要开发一种新协议，并且为此，需要相当大量的时间和成本。
发明内容
本发明是鉴于上述情况而设计的，并且其目的在于，允许以低成本实现容易且可靠的通信。
本发明的一种信息处理装置，其特征在于，它包括捕获部件，用于从网络捕获包含根据IEEE 1394的AV/C命令的基于SOAP的命令；提取部件，用于从由捕获部件捕获的基于SOAP的命令中提取AV/C命令；以及执行部件，用于根据由提取部件提取的基于SOAP的命令，执行相应处理。
它还可以包括生成部件，用于生成AV/C命令；加入部件，用于将由生成部件生成的AV/C命令加入到基于SOAP的命令；以及发送部件，用于向网络发送其中包含由加入部件加入的AV/C命令的基于SOAP的命令。
执行部件可以发送对应于AV/C命令的最终响应。
执行部件在接收到AV/C命令之后的预定时间内不能发送最终响应时，发送“当中”。
执行部件可以包括一个设备模型，该设备模型具有根设备并且根设备具有用于执行预定操作的AV/C服务。
执行部件可以包括一个设备模型，该设备模型具有分别对应于根据IEEE1394的单元和子单元的根设备和嵌入设备，根设备和嵌入设备分别具有用于执行预定操作的AV/C服务。
执行部件可以包括一个设备模型，该设备模型具有分别对应于根据IEEE1394的单元和子单元的根设备和嵌入设备，对于每个AV/C命令操作码，根设备和嵌入设备分别具有用于执行预定操作的AV/C服务。
本发明的一种信息处理方法，其特征在于包括如下步骤捕获步骤，用于从网络捕获包含根据IEEE 1394的AV/C命令的基于SOAP的命令；提取步骤，用于从捕获步骤所捕获的基于SOAP的命令中提取AV/C命令；以及执行步骤，用于根据提取步骤所提取的基于SOAP的命令，执行相应处理。
本发明的一种记录介质的程序，其特征在于包括如下步骤捕获步骤，用于从网络捕获包含根据IEEE 1394的AV/C命令的基于SOAP的命令；提取步骤，用于从捕获步骤所捕获的基于SOAP的命令中提取AV/C命令；以及执行步骤，用于根据提取步骤所提取的基于SOAP的命令，执行相应处理。
本发明的一种程序使得执行如下步骤捕获步骤，用于从网络捕获包含根据IEEE 1394的AV/C命令的基于SOAP的命令；提取步骤，用于从捕获步骤所捕获的基于SOAP的命令中提取AV/C命令；以及执行步骤，用于根据提取步骤所提取的基于SOAP的命令，执行相应处理。
在本发明的信息处理装置、方法、记录介质和程序中，提取并执行加入到基于SOAP的命令中的AV/C命令。
附图简述
图1是应用本发明的网络系统结构图；图2是图1的UPnP设备2的结构方框图；图3是图1的UPnP设备2所包括的设备模型的结构图；
图4是AV/C命令帧的结构图；图5是ctype的说明图；图6是子单元类型(subunit_type)的说明图；图7是示出图1的网络系统的处理过程的流程图；图8是在图7的步骤S3输出的命令的结构图；图9是加入到图8的命令中的AV/C命令的结构图；图10是加入到图11的命令中的AV/C命令的响应的结构图；图11是在图7的步骤12的处理过程输出的响应的示例图；图12是图3的根设备所具有的UPnP设备描述的结构图；图13是图3的AV/C服务所具有的UPnP设备描述的结构图；图14是图3的根设备所具有的另一UPnP设备描述的结构图；图15是图3的AV/C服务所具有的UPnP设备描述的另一结构图；图16是图3的AV/C服务所具有的UPnP设备描述的另一结构图；图17是设备模型的另一结构图；图18是图17的根设备所具有的UPnP设备描述的结构图；图19是图17的AV/C服务所具有的UPnP设备描述的结构图；图20是设备模型的另一结构图；图21是图19的根设备所具有的AV/C代理设备描述的结构图；图22是图20的根设备所具有的UPnP设备描述的结构图；图23是图20的根设备所具有的UPnP设备描述的结构图；图24是设备模型之间的比较图。
最佳实施方式图1示出应用本发明的网络系统的结构。在该结构中，UPnP控制点1与IEEE 802网络11连接。
图2示出UPnP设备2的结构例子。在图2中，中央处理单元(CentralProcessing Unit，CPU)21根据存储在只读存储器(Read Only Memory，ROM)22中的程序或从存储部分28载入到随机访问存储器(Random Access Memory，RAM)23中的程序，执行各种处理。CPU 21执行各种处理所需的数据等也适当地存储在RAM 23中。
CPU 21、ROM 22和RAM 23通过总线24相互连接。输入-输出接口25也与总线24连接。
与输入-输出接口25连接的部件包括输入部分26，由键盘、鼠标等组成；输出部分27，由显示器如CRT和LCD、扬声器等组成；存储部分28，由硬盘等组成；以及通信部分29，由调制解调器、终端适配器等组成。通信部分29通过IEEE 802网络11执行通信处理过程。
驱动器30在需要时也与输入-输出接口25连接，并且磁盘41、光盘42、磁光盘43、半导体存储器44等适当地与之相连。然后，在需要时将从中读取的计算机程序安装到存储部分28中。
UPnP设备(在图1例子的情况下为UPnP控制点1和UPnP设备2)主要有六个功能定址(Addressing)、查找(Discovery)、描述(Deseription)、控制(Control)、事件(Eventing)和表现(Presentation)。
定址是这样一种功能，通过它每个UPnP设备获得IEEE 802网络11上的一个地址，并且，为此使用动态主机配置协议(Dynamic Host ConfigurationProtocol，DHCP)或自动IP。
查找是在定址后执行的，并且UPnP控制点1可以通过查找功能查找UPnP控制点1想要控制的目标设备。在此使用的协议是简单服务查找协议(Simple Service Discovery Protocol，SSDP)。当每个设备连接到IEEE 802网络11时，设备在IEEE 802网络11上以多址通信方式发送一条通知设备和设备本身所具有的服务的消息，(即，设备在不具体指定分组目的地的情况下发送分组)。通过接收该多址通信消息，UPnP控制点1可以了解哪个设备已连接到IEEE 802网络11。
相反，此时也可以是UPnP控制点1检查连接到IEEE 802网络11的设备。在这种情况下，UPnP控制点1通过使用想要查找的设备或服务作为关键字，在IEEE 802网络11上以多址通信方式发送检索命令。如果连接到IEEE802网络11的各个设备满足多址通信检索命令所规定的条件，则该设备执行响应检索命令的单址通信(即，设备通过指定目的地来发送分组)。从而，UPnP控制点1可以检测连接到IEEE 802网络11的设备。
而且，当每个设备从IEEE 802网络11断开时，该设备预先广播这一情况。
采用查找，在由UPnP控制点1查找的作为控制对象的设备所输出的SSDP分组中描述有设备描述的统一资源定位符(Uniform Resource Locator，URL)。UPnP控制点1通过访问该URL，能够从设备描述获得设备的更详细设备信息。设备信息包括图标信息、模型名称、制造商名称、产品名称等。
另外，设备信息描述设备所具有的服务信息。其中描述有服务详细信息的服务描述也可以根据在设备信息中描述的URL进行访问。
UPnP控制点1能够了解如何根据设备信息(设备描述)和服务信息(服务描述)来访问目标。
而且，在设备描述中，描述了后面将要说明的表现URL。
设备描述和服务描述采用可扩展标记语言(Extensible Markup Language，XML)来表示。
控制分为操作(Action)和查询(Query)两大组。操作是遵循服务描述的操作信息中所规定的方法来执行的，并且UPnP控制点1可以通过调用操作来控制目标。
另一方面，查询用于捕获服务描述的状态变量值。状态变量值表示设备状态。
在控制中，使用称作简单对象访问协议(SOAP)的传输协议。作为SOAP的表示语言，使用XML。
事件用于当执行状态变量值变更时使目标向UPnP控制点1通知这一变更。UPnP控制点1通过分析服务描述，可以根据状态变量(stateVariable)了解目标所拥有的变量。通过输出预订(Subscription)给目标，当变量中sendEvents为“yes”的变量发生改变时，UPnP控制点1可以从目标接收通知。在事件中，使用称为一般事件通知架构(General Event Notice Architecture，GENA)的传输协议。作为该协议的表示语言，使用XML。
表现用于向用户提供使用用户界面(User Interface，UI)的控制部件。通过访问设备描述中所描述的表现URL，用户可以获得用超文本标记语言(HyperText Markup Language，HTML)描述的表现页。通过该功能，目标可以备有应用。
UPnP设备2在内部提供图3所示的设备模型。该例子的设备模型由一个根设备61组成，并且该根设备61包括AV/C代理服务71。
AV/C服务71从UPnP控制点1发送的基于SOAP的命令中提取并处理AV/C命令。另外，AV/C服务71生成、加入并发送基于IEEE 1934 AV/C命令的控制内容到基于AV/C的命令。
图4示出AV/C命令帧的格式。
CTS域描述命令集类型。值“0”(十六进制)(二进制为“0000”)表示命令集为AV/C命令集。
ctype域描述分组是命令还是响应，并且如果分组是命令，则其中描述命令的功能分类，并且如果分组是响应，则描述命令处理结果的分类。
图5示出这种命令和响应的例子。如图所示，备有四种命令作为大命令组。
控制(ctype＝0000)是用于从外部控制功能的命令。
状态(ctype＝0001)是用于从外部查询状态的命令。
而且，一般查询(ctype＝0100)和特定查询(ctype＝0010)作为用于从外部查询是否支持控制命令的命令。前者是用于查询是否支持操作码的命令，并且后者是用于查询是否支持操作码和操作数的命令。
通知(ctype＝0011)是用于请求向外部通知状态改变的命令。然而，在本发明中没有使用该通知。
响应是根据命令的类型返回的。
作为对控制命令的响应，备有如下响应。
“未实现”(ctype＝1000)通知命令没有实现。“接受”(ctype＝1001)通知命令已被执行。“拒绝”(ctype＝1010)通知命令不能执行。
“当中”(ctype＝1111)通知命令正在处理中。
作为对状态命令的响应，除了“未实现”和“拒绝”之外，还有“转变中”和“稳定”。
“转变中”(ctype＝1011)通知状态正在转变。“稳定”通知状态不在转变且稳定。
作为对一般查询命令和特定查询命令的响应，存在“实现”和“未实现”。“实现”(ctype＝1100)通知命令被实现。
作为对通知命令的响应，存在“未实现”、“拒绝”、“当中”和“改变”。
“当中”首先通知“通知”已被接受。“改变”(ctype＝1101)在目标的状态发生改变后进行通知。然而，在本发明中，即使当接收到AV/C命令之后过去预定时间(例如，30秒)时难以输出最终响应，也输出“当中”。
图4的AV/C命令帧中的“子单元类型”表示命令的目的地。图6示出子单元类型的一个具体例子。
换句话说，子单元类型的值“00000”表示AV/C命令的目的地(子单元)是视频监视器。而且，值“00101”表示目的地是调谐器。
子单元类型的值“11111”表示命令发送给一个单元。这样，例如，控制装置电源的开关。
紧接在图4的“子单元类型”之后的是“子单元ID”。“子单元ID”用作一个区别号，用于在一个单元中存在多个相同种类的子单元的情况下进行区别。因而，命令的目的地归根到底是根据“子单元类型”和“子单元ID”来确定。
“操作码”表示命令操作，并且“操作数”表示命令的附加条件。
图6示出在“子单元类型”为调谐器的情况下“操作码”的例子。在调谐器的“操作码”的情况下，其值C8h表示直接选择信息类型，并且其值CBh表示直接选择数据。
通过这种方式，备有每个子单元的操作码表。而且，对每个操作码定义操作数。
例如，在执行调谐器的信道选择的情况下，此时的操作码选为直接选择信息类型，并且通过操作数指定信道参数如其频率和其信道号。
下一步，参照图7的流程图中的处理过程，通过以打开UPnP设备2的电源为例，描述UPnP控制点1控制UPnP设备2的处理过程。
在步骤S1中，UPnP控制点1调用基于SOAP的操作的请求分组，该分组描述一个用于控制UPnP设备2的规定操作的命令(本例为打开AV/C设备3的电源)(调用)。
图8示出从UPnP控制点1传输到UPnP设备2的基于SOAP的消息命令的例子。UPnP控制点1通过参考UPnP设备2所具有且后面将要描述的图12和图13所示的UPnP设备描述和UPnP服务描述，生成消息。
包含在事务(Transaction)中的数字“5”表示事务标签，用作识别返回响应对应于哪个命令，因为响应是对应于命令返回的。
命令(command)“00FFB270”表示由UPnP控制点1向UPnP设备2请求的AV/C命令描述的控制内容。
包含在命令的MSB侧上的“00FF”(十六进制数)对应于图9所示的AV/C电源控制命令的CTS“0000”、ctype“0000”、子单元类型“11111”和子单元ID“111”(二进制数)。也就是，如果十六进制数“00FF”用二进制表示，则二进制数为“0000000011111111”。
随后的“B2”对应于操作码，并且“70”对应于操作数。
由于表示命令内容的所有值通过文本表示，因此可以描述任何种类的AV/C命令。
回到图7，当UPnP设备2在步骤S11接收图8所示的操作调用时，UPnP设备2根据命令内容打开装置电源。
然后，在步骤S12，UPnP设备2的AV/C服务71生成如图10所示的对应于该处理过程的AV/C响应(AV/C电源响应)，存储到如图11所示的基于SOAP协议的操作响应中，并且发送给UPnP控制点1。
图11所示的事务(Transaction)中示出的数“5”对应于图8中的事务(Transaction)的值“5”，设为“5”(相同值)，用于表示操作响应是与图8的操作(命令)对应的操作(响应)。
响应(response)“09FFB270”对应于图10的AV/C电源响应中所描述的二进制数值“00001001111111111010001001110000”。
在步骤S2，UPnP控制点1接收响应。这样，UPnP控制点1可以确认UPnP设备2已打开装置电源。
根据AV/C的条款，规定AV/C设备在不能立即执行对应于接收请求的处理过程时，应返回“当中”作为响应。当AV/C设备完成对应于请求的处理过程之后，AV/C设备应立即在此时将最终响应返回给请求发送者。然而，从请求接收到返回最终响应的时间没有规定。
在本发明中，在步骤S11的处理过程中UPnP控制点1输出AV/C命令之后，AV/C服务71在步骤S25接收来自UPnP控制点1的命令，并且在步骤S12估计直到发送最终响应为止的时间。如果最终响应在先前设定的预定时间(例如30秒)内，则AV/C服务71不立即将“当中”发送给UPnP控制点1，而是等待直至完成对应于命令的处理，并且如果在30秒内完成处理过程，则将最终响应输出给UPnP控制点1。
另一方面，如果对应于命令的处理在30秒内没有完成，则AV/C服务71将“当中”输出给UPnP控制点1。另外，当完成处理过程时，发送最终响应。这样，UPnP控制点1至少可以确认是否能在30秒内完成所请求的处理过程。
为了执行上述处理过程，图3所示且UPnP设备2所具有(类似于UPnP控制点1的情况)的设备模型的根设备61包括图12所示的UPnP服务描述，并且AV/C服务71包括图13所示的UPnP服务描述。
这些描述对执行设备所具有的功能所需的参数和其他条件进行描述。当另一设备请求一个设备执行功能时，该另一设备参考描述，以添加该描述中所描述的条件，然后，该另一设备将命令发送给该设备。
图12中的deviceType[urnsony-corp:device:1394ProxyDevice:1]表示根设备61的类型是单元设备。FriendlyName[AV/C on UPnP Device(UpnP设备上的AV/C)]表示根设备61的友好名称。
UDN[nuid:upnp-avcupnp-root-0800460000000000]表示根设备61的特定编号。
在该UPnP设备描述中，提供一种服务类型ServiceType为[urn:schemas-upnp-org:service:avcService:1]且服务ID为[urn:sony-corp:ServiceId:1394ProxyService1]的服务。
SCPDURL[./scpd/proxyScpd.xml]表示AV/C服务71所具有的UPnP服务描述的URL(具体地说，图13所示的UPnP服务描述的URL)。
图13的UPnP服务描述对AV/C服务71所要执行的操作进行描述。[aveCommandSend]表示用于发送AV/C命令的操作。该操作包括如[avcCommand]和[avcResponse]的参数作为变元。这些参数的数据格式在[serviceStateTable]中描述为[bin.hex]。
图14、图15和图16分别表示UPnP设备描述和UPnP服务描述的其他例子。
在图14的例子中，提供一种服务ID(serviceId)为[urn:sony-corp:serviceId:avcService0]的服务。[./scpd/scpd.xml]表示图15和图16所示的UPnP服务描述的URL。
在图15和图16中，表示用于发送AV/C命令的操作[avcCommandSend]。在该操作中，定义有4个参数，即[avcCommand]、[InTrLabel]、[avcResponse]和[outTrLabel]。为此，分别定义[avcCommand]，[trLabel]，[avcResponse]和[trLabel]作为相关状态变量，并且它们的数据格式在[serviceStateTable]中分别定义为[bin.hex]。
需要注意的是，方向(direction)中的“in”表示该参数从具有该描述的装置输入到另一装置，并且“out”表示该参数从另一装置输出并且发送到具有该描述的装置。
表示即使当该变量的状态发生改变时，也不通知处于预订(SUBSCRIBE)状态的装置。
在上面描述中，虽然如图3所示1个根设备61只拥有1个AV/C服务71，但是，例如，可以如图17所示使根设备对应于单元并且使嵌入设备对应于子单元。另外，在该例子中，每个设备仅有一个AV/C服务。
具体地，在图17的例子中，根设备61具有AV/C服务71-1，并且根设备61所包括的嵌入设备81-1和81-2分别具有AV/C服务71-2和71-3。
图18和图19示出图17的根设备所具有的UPnP设备描述和AV/C服务71-1所具有的UPnP设备描述的结构的例子。
在图18的例子中，提供一种设备类型(deViceType)为[urn:sony-corp:device:unitDevice:1]的设备，该设备具有一种其中服务类型(serviceType)[urn:sony-corp:service:avcService:1]具有服务Id(serviceId)[urn:sony-corp:serviceID:avcService0]的服务。该SCPDUAL[./scpd/root/scpd.xml]例如描述图19的UPnP服务描述的URL。
另外，在该设备中，还描述一种设备类型(deviceType)为[urn:sony-corp:device:discDevice:1]的设备(对应于嵌入设备81-1)。该设备定义有一种服务类型(serviceType)为[urn:sony-corp:service:avcService:1]的服务。该SCPDURL[./scpd/disc0/scpd.xml]例如表示AV/C服务71-2所具有的服务描述的URL。
在图19中，描述了用于发送AV/C命令的操作[avcCommandSend]。该操作有2个参数[avcCommand]和[avcResponse]。这些参数的数据格式在serviceStatTable中定义为[bin.hex]。
图20示出设备模型结构的另一例子。在该例子中，以与图17的例子类似的方式，“根设备”对应于“单元”，并且“嵌入设备”对应于“子单元”。然而，在该例子中，以不同于图17的例子的方式，为对应于各自“服务”的AV/C命令的每个“操作码”定义1个“服务”。
具体地说，在图20的例子中，根设备61具有服务91-2，对应于与电源服务91-1不同的其他操作码。
另外，嵌入设备81-1具有服务92-2，对应于与服务92-1不同的AV/C命令操作码。
而且，嵌入设备81-2具有服务92-4，对应于与服务92-3不同的另一操作码。
对于每个服务，控制通过操作来实现，状态采用GENA通过查询和通知来实现。一般查询可以用设备描述来代替。
图21和图22示出图20例子中的根设备61所具有的UPnP设备描述的结构，并且图23示出图20的电源服务91-1所具有的UPnP服务描述的结构的例子。
图21的设备类型(deviceType)[urn:sony-corp:device:rootDevice:1]对应于图20的根设备，并且其服务类型(serviceType)[urn:sony-corp:service:avcPowerService:1]对应于图20的电源服务91-1。
设备类型(deviceType)[urn:sony-corp:device:discDevice:1]对应于图20的嵌入设备81-1，其服务类型(serviceType)[urn:sony-corp:service:avcPlayService:1]对应于播放服务92-1，并且其服务类型(serviceType)[urn:sony-corp:service:avcStopService:1]对应于嵌入设备81-1所具有的另一服务92-2。
对应于电源服务91-1的服务SCPDURL[./scpd/root/power/scpd.xml]例如描述图23的UPnP服务描述的URL。
服务类型(serviceType)为[urn:sony-corp:service:avcPlayService:1]的SCPDURL[./scpd/disc0/play/scpd.xml]描述播放服务92-1所包括的服务描述的URL。以类似的方式，服务类型(serviceType)为[urn:sony-corp:service:avcStopService:1]的SCPDURL[./scpd/disc0/stop/scpd.xml]描述播放服务92-3所包括的服务描述。
在图23的例子中，描述发送AV/C命令的操作[avcCommandSend]。有两个参数[avcCommand]和[avcResponse]添加到其上，并且它们各自的数据格式在serviceStateTable中定义为[bin.hex]。
图24示出图3、图17和图20的设备模型的特性的比较结果。需要注意的是，在图24中，类型A、类型B和类型C分别对应于图3、图17和图20的设备模型。
从类型A到类型C的比较，可以证实SSPD的分组大小大大不同。换句话说，当根设备为1时，SSPD的数目为3+2d+k。在此，d是嵌入设备的数目，并且k表示服务类型的数目。这样，当子单元的数目为N时，SSPD的分组大小，对于类型A为4，对于类型B为4+3N，对于类型C为3+2N+C。需要注意的是，给出大量对应操作码。
尤其在类型B的情况下(图17)，存在大量分组，达到子单元数目的数倍。鉴于这一点，当从网络通信量的角度考虑，类型A的例子具有较小的SSPD分组大小。
“通知”的通知单元在类型A和类型B的情况下都是“所有命令”，而对于类型C，它以“每个命令”为单元。
总而言之，可以认为类型A(图3)的例子最合适。
根据上面，虽然以从UPnP控制点1控制UPnP设备2为例，但是也可以从UPnP设备2控制UPnP控制点1。然而，在这种情况下，随着UPnP设备2变成上述UPnP控制点并且UPnP控制点变成UPnP设备，产生类似于上述的情况。
虽然上述处理过程顺序可以采用硬件实现，但是也可以采用软件实现。在处理过程顺序采用软件实现的情况下，构成软件的程序从网络、记录介质等安装到其中配备有特定硬件的计算机或者例如能够执行各种功能的通用个人计算机等中。
如图2所示，该记录介质不仅包括其中记录有程序、与装置主体分开、且分发以将程序提供给用户的包介质，包括磁盘41(包括软盘)、光盘42(包括CD-ROM(Compact-Disk Read-Only Memory，致密盘只读存储器)和DVD(Digital Versatile Disk，数字多功能盘))、光磁盘43(包括MD(Mini-Disk，微型盘))或半导体存储器44，还包括以预先安装在装置主体中的方式提供给用户的ROM 22或包含在存储部分28中的硬盘等。
需要注意的是，在本说明书中，描述记录在记录介质中的程序的步骤可以包括不一定遵循时间顺序的处理过程，从而包括并行处理过程或单独执行的处理过程，而明显不同于遵循按照所述顺序的时间顺序的处理过程。
另外，在本说明书中，应该理解，系统可以表示由多个装置组成的总体装置。
工业应用如上所述，根据本发明，提取并处理存储在基于SOAP的命令中的AV/C命令，从而允许实现一种廉价系统，其中，不需要开发新命令系统并且允许容易且可靠地控制连接到网络的装置。
权利要求
1.一种信息处理装置，连接到网络并且执行与其他信息处理装置的通信，其中，所述网络具有基于IEEE 802的SOAP的格式，所述信息处理装置的特征在于包括捕获部件，用于从所述网络捕获包含根据IEEE 1394的AV/C命令的基于所述SOAP的命令；提取部件，用于从由所述捕获部件捕获的所述基于SOAP的命令中提取所述AV/C命令；以及执行部件，用于根据由所述提取部件提取的所述基于SOAP的命令，执行相应处理。
2.如权利要求1所述的信息处理装置，其特征在于还包括生成部件，用于生成所述AV/C命令；加入部件，用于将由所述生成部件生成的所述AV/C命令加入到基于所述SOAP的命令；以及发送部件，用于向网络发送其中包含由所述加入部件加入的所述AV/C命令的基于所述SOAP的所述命令。
3.如权利要求1所述的信息处理装置，其特征在于，所述执行部件发送对应于所述AV/C命令的最终响应。
4.如权利要求3所述的信息处理装置，其特征在于，所述执行部件在接收到所述AV/C命令之后的预定时间内不能发送所述最终响应时，发送“当中”。
5.如权利要求1所述的信息处理装置，其特征在于，所述执行部件包括一个设备模型，所述设备模型具有根设备并且所述根设备具有用于执行预定操作的AV/C服务。
6.如权利要求1所述的信息处理装置，其特征在于，所述执行部件包括一个设备模型，所述设备模型具有分别对应于根据IEEE 1394的单元和子单元的根设备和嵌入设备，所述根设备和所述嵌入设备分别具有用于执行预定操作的AV/C服务。
7.如权利要求1所述的信息处理装置，其特征在于，所述执行部件包括一个设备模型，所述设备模型具有分别对应于根据IEEE 1394的单元和子单元的根设备和嵌入设备，对于每个AV/C命令操作码，所述根设备和所述嵌入设备分别具有用于执行预定操作的AV/C服务。
8.一种信息处理装置的信息处理方法，其中，所述信息处理装置连接到网络并且执行与其他信息处理装置的通信，所述网络具有基于IEEE 802的SOAP的格式，所述信息处理方法的特征在于包括捕获步骤，用于从所述网络捕获根据IEEE 1394的包含AV/C命令的基于所述SOAP的命令；提取步骤，用于从所述捕获步骤所捕获的所述基于SOAP的命令中提取所述AV/C命令；以及执行步骤，用于执行所述提取步骤所提取的所述基于SOAP的命令的对应处理。
9.一种用于记录信息处理装置的计算机可读程序的记录介质，其中，所述信息处理装置连接到网络并且执行与其他信息处理装置的通信，所述网络具有基于IEEE 802的SOAP的格式，所述程序的特征在于包括捕获步骤，用于从所述网络捕获包含根据IEEE 1394的AV/C命令的基于所述SOAP的命令；提取步骤，用于从所述捕获步骤所捕获的所述基于SOAP的命令中提取所述AV/C命令；以及执行步骤，用于根据所述提取步骤所提取的所述基于SOAP的命令，执行相应处理。
10.一种用于控制信息处理装置的程序，其中，所述信息处理装置连接到网络并且执行与其他信息处理装置的通信，所述网络具有基于IEEE 802的SOAP的格式，所述程序使计算机执行如下步骤捕获步骤，用于从所述网络捕获包含根据IEEE 1394的AV/C命令的基于所述SOAP的命令；提取步骤，用于从所述捕获步骤所捕获的所述基于SOAP的命令中提取所述AV/C命令；以及执行步骤，用于根据所述提取步骤所提取的所述基于SOAP的命令，执行相应处理。
全文摘要
一种信息处理装置和方法，其中，连接到IEEE802网络的设备可以相互通信。IEEE 802网络(11)连接到UPnP控制点(1)和UPnP设备(2)。UPnP控制点(1)通过根据在IEEE1394网络中使用的AV/C命令描述控制内容来控制UPnP设备(2)。UPnP控制点(1)将AV/C命令存储在IEEE 802网络(11)中使用的基于SOAP的命令。基于该SOAP的命令通过IEEE 802网络(11)传输到UPnP设备(2)。UPnP设备(2)从基于SOAP的命令中提取AV/C命令，并且执行相应处理。本发明可以应用于个人计算机。
文档编号H04Q9/00GK1465164SQ02802545
公开日2003年12月31日 申请日期2002年6月20日 优先权日2001年6月20日
发明者野田卓郎, 佐藤真, 青木幸彦, 嶋久登 申请人:索尼公司