CN100580731C

CN100580731C - 遥控装置

Info

Publication number: CN100580731C
Application number: CN200680023929A
Authority: CN
Inventors: 希安·詹姆斯; 尼尔·哈里斯; 约翰·特纳; 蒂姆·豪斯
Original assignee: Symbian Software Ltd
Current assignee: Nokia Inc
Priority date: 2005-06-29
Filing date: 2006-06-29
Publication date: 2010-01-13
Anticipated expiration: 2026-06-29
Also published as: EP1899935A1; US20170046946A1; EP3032512B1; US20200184805A1; JP5061360B2; CN101213582A; GB0513312D0; US9406219B2; HK1199669A1; EP1899935B1; US10607479B2; GB2427733A; WO2007000605A1; US20190272740A1; EP3680874A1; JP5479513B2; JP2009500886A; US9922550B2; JP2012120240A; EP3032512A1

Abstract

一种遥控框架使得多个目标设备能够由多个遥控设备进行控制而与载体类型无关。以一种优选实施方式，任一目标设备也都可作为一个控制设备，而任何控制设备也都可作为目标设备。该框架还使得任何运行于任何目标设备上的应用程序都能够由任何控制设备进行控制。

Description

遥控装置

技术领域

本发明涉及用于使多个设备能够被遥控的方法。

背景技术

为了避免有疑虑，在以下本发明的描述中，术语“设备”用于指能够被任何类型的外部设备通过任何类型的有线或无线连接所遥控的实体。

无线遥控的第一示范是由Nikola Tesla进行的，他于1898年在Madison Square Gardens的电气展览会上在专门建造的池塘上展示了一艘无线电控制的船。美国专利613,809就基于该发明而诞生。

尽管有着这一古老血统，又大约50年，用于家用电气和电子设备的遥控技术商业开发才真正出现，即当其最终才由Zenith在电视方面最先开发出来。它们的第一个电视遥控器“Lazy Bones”，出现于1950年，且其通过长长的导线连接到电视。虽然电视的有线遥控并不是长期使用的技术(主要是因为用户在电线上磕磕绊绊)，但是它们总是为了用于其他许多种电器而已被持续地制造出来，从传统的有线遥控器(例如用于幻灯机和录音机的那些)到更现代的设备，例如数字可携式摄像机：索尼RMVD1是该后一技术的最近的实例。

正是无线遥控当前构成这种设备的大多数。在1955年，Zenith的“Flashmatic”是首次出现的无线电视遥控器；它通过对电视机中的光电电池所制造的可见光信号进行操作。第二年，Robert的“Space Commander”成为Zenith的第一个真正实用的无线遥控器；它是由机械操作的超声设备。超声保持为遥控技术的基础，直到20世纪80年代红外发射设备的开发。虽然在红外所要求的视线(line-of-sight)通信不实际的情况下一般使用RF(射频)，但是现在红外仍然是遥控设备可选择的技术。

虽然无线遥控仍然是更普遍的种类，但值得注意的是有线遥控正进行某种回归，尤其是在任何情况下都需要导线的电器上；最清楚的这种实例就是带有音频功能的电器。这包括移动电话，其可通过被插入到免提头戴式耳机上的音频头内的模块中的按钮来控制，并且以相当复杂的形式在尖端数字音乐播放器上(所有市场领导者诸如Apple iPod^TM，Creative Zen^TM，以及iRiver^TM具有可选的或整体的有线遥控器)来控制。

总之，在设法操作电器的人和该电器本身之间有着紧密物理接触的以下任一情况下，当代电气和电子设备的遥控器如今用得极为普遍：

·不可能；如在诸如飞机或轮船等交通工具模型的情况下

·别扭；如在诸如通常安装在墙或天花板高处上的空调机等电器的情况下

·不便，因为它需要物理变更或费力，这被认为对于使用环境来说是不合适的；像在现代视听和音响设备(例如，电视、DVD和音乐播放器)的场合下。

直到最近，设备遥控技术仍限于若干相关的方法：

·遥控设备与其打算控制的电器一起被制造和销售，并且与其紧密结合；专有的信号和协议被用于通信。红外设备也是如此。虽然存在有由红外数据协会(IrDA，见http://www.irda.org/)开发的红外通信标准，但是它并未被遥控器所利用。实际上有“许多不同的编码系统在使用，并且通常不同的制造者使用不同的代码和不同的数据率进行传输。”(来自http://www.epanorama.net/links/irremote.html)。

应该指出，关于这点，可编程遥控器(其可用于来自许多不同的制造商的设备)的存在并不证明它们都遵从共同的标准。这些可编程设备能够仿真各个不同制造商的操作模式、传输协议、数据速率和控制代码而不是仅能够在各种环境都起作用的单一模式中运行。

·遥控设备被提供所有的专用和非可扩展的设备；它们具有固定一组能力并且不能执行除了在制造时就已嵌入的那些功能以外的任何功能。

·类似地，所有待被遥控的电器不得不专门为此设计；其能力就被固定并且它们不能执行除了在制造电器时就已嵌入的那些功能以外的任何功能。

然而，电器正日益变得功能多样并可进行编程；该趋势是使它们建立在通用计算机中所采用的相同类型的中央处理器和存储器周围。有基本证据表明，在这种情况情况下，越来越有可能陷于上述的局限。

在遥控技术领域，建立在用在可编程计算机中的相同类型的中央处理器和存储器组件周围的电器现在通常能够利用标准化的通信技术。这些标准是：

·蓝牙(见Bluetooth Special Interest Group网站在http://www.bluetooth.com/)。这是低功率短距离无线联网协议，其在设计用于特定环境的各种配置文件(profile)中实施。蓝牙最普通的一种应用是在移动电话的无线头戴式耳机中，利用免提或头戴式耳机配置文件，它们中的任何一个都使得头戴式耳机能够遥控移动电话。

·火线/IEEE 1394(见1394同业公会网站：http://www.1394ta.org/或电气和电子工程师协会高性能串行总线桥工作组P1394.1http://grouper.ieee.org/groups/1394/1/index.html)。这是第一个运行在导线上的快速串行协议，其越来越多地被用于多媒体电器的遥控；该标准包括数字遥控命令组。

·ANSI/CEA-2027；这是较新的标准，2004年7月才完成，并且来自于消费者电子协会(CEA)。它定义了可用于对通过使用IP(互联网协议)的家用网络互连的音频/视频设备控制的接口。

虽然存在诸如这些的日益增多的标准的使用，值得注意的是许多公司并没有像它们应该那样多地利用它们。例如，尽管Apple发明了火线，但是他们并不在其自己的遥控器上使用该技术；人们不得不尽力让工程师转而使用iPod遥控器中的专有协议，这些协议中的一些在http://www.maushammer.com/systems/ipod-remote/ipod-remote.html中进行了描述。

像上述基于标准的技术一样，在设备结合了可编程数字计算机的情况下，将两个连接到一起使得一个能够控制另一个(假定两个都能运行兼容的软件)，这也就变得很显然了。因此，在给定传统遥控器功能超集的许多情况下，较大的固定设备(例如个人计算机)能够被较小的移动设备(例如蜂窝式电话)控制。这种技术的许多实例存在，它使得移动电话能够用于通过蓝牙技术来控制个人计算机上的媒体播放器以及其他应用程序，例如Bemused(http://www.compsoc.man.ac.uk/～ashley/bemused/)以及蓝牙遥控(http://www.labtech.epitech.net/remotecontrol)等蓝牙技术，这两者都控制Windows PC。当也存在对Linux的执行时(例如http://www.iptelnow.de/HOWTO/BT_REMOTE/bt_remote.html)，Salling Clicker使移动电话能够控制Apple Macintosh(http://www.homepage.mac.com/jonassalling/Shareware/Clicker)。

如上所述的现有技术显示了从专用、不灵活且专有的遥控器到通用、灵活且基于标准的技术方案的逐渐演化。

然而，上述的所有基于标准的解决方案都受限于它们都是针对载体技术这个事实，并且经常也是针对用于载体的传输协议。本领域技术人员将会有许多用于遥控信令的可能的载体存在的启示，包括但不限于：

·蓝牙(使用若干个有可能的配置文件中的任一个)；

·无线以太网(802.11)，使用任何基于IP的信令方法；

·红外线(专有的和IrDA)；

·专有的RF技术方案；

·IEEE 1394(火线)，利用IEEE 1394命令集或ANSI/CEA-2027；

·USB(通用串行总线)，包括USB-OTG(On-The-Go)；

·其他有线技术方案，包括RS-232串行协议。

被设计成与使用这些载体中的任何一个一起工作的电器当前都不能与其他任何类型的载体一起工作，不管该遥控器是否使用标准协议。被设计成与其定做的有线遥控器一起使用的MP3或其他音乐播放器都不能与普通的火线、USB、蓝牙或红外遥控设备一起使用，即使它可能具有这种可用的工业标准接口。

即便具有使用相同载体的遥控设备，在实施不兼容协议的情况下，电器也许还不能工作。例如，众所周知，蓝牙头戴式耳机和免提配置文件是相当不同的，仅支持头戴式耳机配置文件的蓝牙启动的移动电话将不会对仅支持免提配置文件的蓝牙外围设备起作用；这种不兼容已经困扰了许多消费者，这是由于没有容易的方法来改它。

发明内容

因此，本发明的一个目标是提供一种遥控器接口，其通过提供通用遥控器接口来至少缓解上述的由遥控技术方案和具体载体技术之间紧密耦合所引起的问题，该通用遥控器接口可由运行在设备上的应用软件使用以接收至或自任一种遥控设备的命令，而与可能用于传输那些命令的协议或载体无关。

相同的通用软件接口还可以由遥控设备使用以发送命令到电器，也与任何协议或载体无关。

此外，任何结合有可编程计算设备(其实施了该通用软件接口)的设备都能够不仅能用其接收来自遥控设备的命令，而且能够用其(连同适当的应用程序)将自身作为遥控设备。

根据本发明的第一方面，提供了一种能够使一个或多个目标设备由一个或多个控制器设备通过使用经由多个载体中的至少一个所发送的命令进行遥控的方法，该载体包括但不限于：

·固定导线，包括USB和简单的串口

·红外线

·超声波

·RF，包括但不限于蓝牙和802.11无线联网

其中，一个或多个目标设备配置为运行多个应用程序，遥控装置配置为包括目标选择器，所述目标选择器用于确定将所述遥控装置接收到的命令传递给目标设备上的哪个应用程序，通用遥控器接口配置为，无论发信的控制器设备或所述控制器设备用于将所述命令发送给遥控装置的载体的类型如何，所述一个或多个目标设备都能够接收所述命令。

根据本发明的第二方面，提供了一种被安排为根据第一方面的方法进行操作的计算设备。

根据本发明的第三方面，提供了一种用于使计算设备根据第一方面的方法进行操作的操作系统。

附图说明

现在将参照附图通过进一步的实例来描述本发明的实施例。

图1示出了根据本发明的遥控体系结构；

图2示出了根据本发明的遥控体系结构的结构化纵览；以及

图3示出了根据本发明的遥控体系结构的实际实施例。

具体实施方式

在以下描述中，本发明的通用接口被称作遥控装置。它可由任何运行在设备上的应用程序或软件使用；然而，遥控装置内部使用载体插件程序模块来发送或接收外部遥控命令。插件程序可被定义为可执行代码的可替换的项，其向能够在运行时加载或调用它的松散连接的应用程序或服务提供特定服务。

每个唯一的载体需要其自己的插件程序。每个载体插件程序外部地执行相同的通用应用编程接口(API)，但是被内部地定制以利用相关载体技术的特定特征和要求来发送和接收到遥控设备和来自遥控设备的命令。

实例载体插件程序是有线头戴式耳机、红外遥控器、以及蓝牙音频视频遥控协议(AVRCP)。

图1示意性示出了该体系结构的一个优选实施方式，用于既能够作为遥控器又能够作为受控设备的设备。本发明的实施方式也可以包括可替代设备，其封装了多个控制器和控制功能，它们都能够同时以离散的可靠和安全的方式执行；多媒体和家用安全属于控制的复杂性是关于保证这种设备的技术领域。然而，应该指出，虽然该优选的实施方式既能够控制设备且其自身又能够被遥控，本发明也可在缺少这些能力中的一个并且适合于专用遥控器或可选地适合于需要控制的专用设备的版本中实施。

图1中的箭头示出了根据本发明的典型体系结构的命令流以及控制流。

图1示出了运行在正被用作受控电器的装置6上的音频应用程序2和视频应用程序4。这些应用程序接收来自遥控服务器8的命令，遥控服务器8提供了用于将这种命令传递给所有应用程序的一致的目标客户端API 10，而与它们起源于的遥控器或用于传输它们的载体的类型无关。

图1还示出了遥控器应用程序12，其也能运行在设备(当被用作遥控器时)上。这使用其自己的控制器客户端API 14来通过遥控服务器8发送命令；再次，该API对于任何目的设备和载体类型都是一致的。

遥控服务器8具有分别为AVRCP、有线遥控和红外的14、16、18插件程序可用，并具有可能扩展的多个插件程序(图1中的框20仅示出一个)。在该实施例中，遥控服务器包括目标选择器22。目标选择器执行三个角色：

1)对于输入的命令，它确定哪个目标应用程序应该接收该命令。

2)对于离去的命令，如果遥控应用程序未能指定这些，则它确定将被控制的缺省载体和设备。本领域中普通技术人员将意识到存在可被用户或设备用于确定缺省载体的许多机构(例如，一些类型的控制面板)。

3)对于由遥控应用程序(其值得将被控制的设备)发送的离去的命令，它被用作看门者；它允许或拒绝在载体级的通信。

图1中的虚线24表示实施本发明的设备的边界。当设备被用作受控的设备时，命令通过该边界被接收或“进入”。当该设备被用作遥控器时，命令通过该边界被传递或“发出”。这些命令的载体的性质被封装在遥控服务器8内。

应该指出，在图1的底部示出的其他设备26可自身运行遥控装置，但是它们不必这样；插入到服务器的模块可被设计以在任何类型的载体上实施任何协议。

为受控设备的额外的遥控器添加支持仅是添加额外的插件程序模块到在那个设备上的遥控装置的问题。所以，USB遥控器仅需要USB插件程序(未示出)可用于遥控服务器；例如代替图1中的扩展框20。这可被提供为在开放操作系统上的可安装的软件模块；可选地，它可被提供为硬件升级，通过例如无线电或服务中心升级的方式，或用户可插入的模块，例如可被操作系统识别的EPROM。

添加由遥控器控制额外设备的能力被通过添加插件程序模块到那个设备自身的遥控装置而类似地管理。

现在将要被描述的本发明的实例是本发明在运行SymbianOS^TM(用于由Symbian有限公司生产的移动电话的高级操作系统)蜂窝式电话上的实施；因此它使用对于构建具有该操作系统的设备(如在关于Symbian OS的各种教科书(例如由J.Stichbury，Wiley解释的Symbian OS 2004，ISBN 0470021306)Sysmbian OS)中描述的，以及在各种由Symbian有限公司出版的各种开发工具箱(例如，在http://www.symbian.com/developer/techlib/sdl.html))这个领域的技术人员来说是很熟悉的术语和惯用语。本领域技术人员当然理解此处描述的简单实施方式也可被修改以运行在许多不同的操作系统以及许多不同的设备上。

该示例性遥控系统(RemCon)显示了本发明如何能够用于控制电话，尤其是如何用于从蓝牙立体声头戴式耳机控制诸如运行在电话上的MP3播放器的音乐应用程序。正被控制的应用程序被称作目标。例如，在该例子中，用户可与头戴式耳机进行交互以执行例如播放、暂停、以及“下一曲目”等功能：该头戴式耳机被用作电话的遥控器。

更寻常地，电话可被另一个设备通过任何适当的载体或协议进行控制。因此，为了展示本发明的可扩展性，所描述的另一个最初的实施方式是相对基本的插件程序的实施方式，其通过使用任意的自然(naive)协议的串行传输进行工作。

本发明的遥控系统还允许将设备用作其他设备的遥控器。该在这种功能的设备上的应用程序被控制器。例如，设备可被用于电视的遥控。

就可被用于发射和接收遥控消息的传输和协议(统称为载体)来说，系统是可扩展的。虽然在这一描述中，头戴式耳机一般被设想为蓝牙头戴式耳机，但很明显，有可能支持其他类型的头戴式耳机，例如有线头戴式耳机。

独立于载体可扩展性，就可被发送和接收的信息来说，系统也是可扩展的。因此，遵循新的载体协议也可涉及支持新消息。

系统也允许多个客户端应用程序同时使用它。不仅仅是一个控制器和一个目标，而是多个目标同时作为多个控制器。

控制器客户端发送命令和接收响应。目标客户端接收命令和发送响应。因此，控制器API允许无连接的操作(这种情况下，命令由设备制造商决定的系统进行路由)以及面向连接的操作(这种情况下，客户端指定用于远端一方的载体和任何相关寻址信息)客户端能够监控在任何时间点现存的各种连接的状态。因此，系统是不知载体的(bearer-agnostic)。

图2示出了系统的体系结构概观。

图2中所示的组件中的一些组件执行标准协议，其对于本领域技术人员是公知的。这些包括：

·AVCTP(音频视频控制传输协议)

·AVDTP(音频-视频分配传输协议)

·AVRCP(音频视频遥控协议)

·L2CAP(逻辑链路控制器和适配协议)

·RTP(实时协议)

·SBC(子带编码译码器)

图2中所示的其他组件特定于该实施方式。

·媒体播放器应用程序(Media Player app)使用多媒体框架(MMF)通过AVDTP来发送音频到蓝牙头戴式耳机。MMF由MMF客户端API和MMF控制器插件程序表示。媒体播放器应用程序也是RemCon目标，并且通过AVRCP接收来自头戴式耳机的遥控命令(比如下一个曲目、暂停等)。

·遥控器应用程序(Remote Controller app)是RemCon控制器并且通过AVRCP向远端设备发送遥控命令

·DevSound也被设想为RemCon控制器；这是它如何直接通过音频策略服务器(Audio Policy Server)设定远程音量(即，媒体音量被看作系统属性，并不基于每个媒体播放器应用程序来处理)。

·RemCon目标API和RemCon控制器API包括上面提到的命令可扩展性。

·RemCon服务器包括载体可扩展性框架和上面也提到的消息路由策略。

现在将提供该设计的主要组件的概观。

RemCon

至多有运行在设备上的Remcon服务器的单个实例。它是瞬态服务器；也就是说，它不会总是使用，并且为了节省资源，当没有客户端时它就关闭。

载体

载体被实施为RemCon的插件程序，并且其所有都实例化了标准接口。

该遥控系统的特定实施方式与AVRCP和到蓝牙系统的AVCTP扩展等实施方式相关。因此：

·AVRCP作为载体插件程序被传递到RemCon

·AVCTP作为蓝牙协议模块的一部分而被传递

它也与上述的参考串行载体相关。

服务器被设计为

a)与这些组件一起工作以及

b)尽可能与任何其他可想到的载体一起工作，即保持不知载体的

虽然存在两种可能类型的载体，面向连接的和无连接的，但该实施方式需要无连接的载体仿真面向连接的行为。因此载体API是面向连接的，正如AVRCP载体插件程序。

面向连接的载体的实例化导致它开始倾听到来的连接。这种载体接受到来的连接并且通知RemCon服务器。

应该注意，为了试图连接到特定远程设备，RemCon服务器也能命令载体。

控制器

控制器实体向远程目标发送消息，并且及时答复(field)任何给出的响应。

当处于无连接模式的控制器发送命令时，待被使用的实际载体(以及在那些载体内的特定连接)就由插件程序指定，通常针对设备并且由其制造商提供，此处已知为目标选择器插件程序(TSP)；这在以下连同目标一起更详细地论述。当处于面向连接模式的控制器发送命令时，所用的连接是已经由控制器打开的连接。TSP未被旁路；然而它能够控制该控制器是否可在那个时刻发送该命令到所指定的遥控器(remote)。

载体被用于传输命令并接收响应。服务器维护对每个控制器所发送的命令的了解。通过连接而进入的响应由服务器引导到最近已经通过那个连接发送适当的启动命令的那个控制器客户端。

控制器API也包含NotifyConnectionsChange API，其通过系统中的所有载体来传递关于所有连接的信息。

目标

如同控制器客户端一样，可能存在一个以上的同时操作的客户端。目标操作比控制器操作更成问题，这是因为载体协议不一定封装到来的命令将用于哪个目标。哪个目标需要及时答复特定的到来的命令不仅在运行时变化，而且在方式上变化，在该方式中，目标(客户端)可能未控制、甚或不了解。以示图的方式，如果用户正在使用MP3播放器应用程序听音乐，而呼叫进来并被用户接听，那么目标应用程序(用于控制由头戴式耳机启动的音量控制变化)就从MP3播放器应用程序转换到电话应用程序。如果设备用户接口(UI)在“多媒体音量”和“呼叫音量”之间保持差别，则这些应用程序中的每一个都需要听取音量控制变化以更新其自身的屏上显示。

实际上，系统正试图模拟用户所想的的东西在任一时间正被遥控的情形。对于当前的实践，这通常是很直接的；用户使用电视遥控器来控制电视，使用视频遥控器来控制视频录(摄)像机。这使得物理控制器和目标之间的映射显式化。

然而，对于在由单个遥控器(头戴式耳机)控制的电话上运行的多个目标应用程序，该映射更含糊。以下的因素是可用于建立映射的因素：

(a)在设备的只读存储器(ROM)中的应用程序顺序

(b)应用程序是否在前台(foreground)

(c)用户操作的最近的历史

(d)应用程序的相对的被认为的重要性(例如，呼叫起作用的时候，对于电话应用程序来说，就可能是最重要的)

(e)如果MP3播放器知道音乐的高声部分已经开始了，则降音命令更有可能被下发给MP3播放器，而不是其他任何应用程序

(f)如果MP3播放器记住并知道在开始音乐播放表中的特定曲目之后用户通常马上执行“下一个曲目”，则用户可能这次也想跳过下一个曲目

(g)如果用户正在听从提供“用户排名(user rating)”曲目服务的网站流出的音乐，并且该用户选择了其他用户认为是不好的曲目的“下一个曲目”，则该用户可能也是那样想的。

上述这些可能性只是示例性的，使得能清楚看到，对于通用的操作系统来说，向映射问题提供确定的回答是不可能的。设备的制造商，其决定用户接口，因而经常被更好地配置(place)以决定映射。

因此，提供了一种机制，称作目标选择器插件程序(TargetSelector Plug-in，TSP)，其可由设备制造商用来实施一组规则，该规则根据其用户接口系统变得最有意义。因此，为TSP提供当前客户端目标处理ID的列表，并且被预期向RemCon指示(通过处理ID)目标客户端的列表以接收消息。

由于不能预期目标知道哪个载体将向它们传递命令，故当目标客户端连接到遥控系统时，所有可用的载体都必须被加载并且开始倾听到来的连接。注意，目标客户端不知道载体，但它并不是完全不知道这些载体的存在。先前提到的NotifyConnectionsChange API也是目标可用的。

目标选择器插件程序(TSP)

TSP负责决定三件事：

1.对于每个到来的命令，传递命令到哪个(些)目标；

2.对于处于无线连接模式的控制器，传递离去的命令到哪个(些)远程目标(即，将命令传递到哪个(些)载体远程地址)；以及

3.对于处于面向连接模式的控制器，是否允许或拒绝控制器请求向特定的遥控器发送特定命令。

RemCon提供了TSP接口的单一参考实施方式。为了有针对性的目的，该接口被提供了一阵列潜在的接受方。以此方式，就能够显示一阵列预定的接受方，并且消息将被传递到每个接受方。

如前所述，为设备制造商提供TSP以根据其自己特定的接口策略进行实施。

在工作的设备中，只读存储器(ROM)建立时就提供单个TSP。逻辑上，系统中只有一个这样的程序插件，由于逻辑上只有一种正确的方式来回答关于仅具备一个UI的设备的问题。命令实际上由RemCon传递；因为TSP仅由RemCon查询，所以它知道将消息传递到哪里。

出于这些目的，通过进程ID以及安全ID来识别目标客户端：RemCon控制目标客户端的建立，使得每个客户端进程仅允许有一个客户端。对于每个命令，将当前打开的目标客户端的ID的列表给TSP，使得它知道哪些目标是可用的。TSP也任意地引发其他目标客户端应用程序的打开，并且将它们的ID添加到该阵列。

远程目标通过载体唯一标识符(UID)和针对载体的连接信息封装的结合进行标识。针对载体的连接信息封装类型应该已经公开给了第三方，所以面向连接的控制器能够正确地工作。

为了其实施的最大灵活性，TSP API通过请求-回拨(request-callback)机制而起作用。回拨可为同步或异步的。TSP被设计为能够理解由RemCon传递给它的用于寻址的任何命令，充分满足寻址命令的目的。这不仅包括核心API命令，而且包括扩展命令。如果TSP“弄错”命令，则那个命令将不被传递。

目标听取机制

存在系统中仅有一个TSP实例的情况。因此从许多载体中到来的事件在被通过异步API发送到TSP之前在RemCon中排队。对于目标，一旦命令已经被“寻址”到，就将其交给那些被选定的目标客户端，假定它们每一个都有未完成的接收请求。

当有关的目标的接收请求完成时，目标就处理给定的数据并且(通常)重新发送(repost)该请求。如果当目标X在那个时间点没有未完成的“接收请求”时，TSP显示目标X应该接收命令，则那个命令被排队，直到目标X发出(post)接收请求。到来的响应也以此方式排队。

扩展API

框架支持到内核API(Core API)的扩展(extension)，例如为了支持特定于各种设备制造商的API。控制器客户端并不一定知道，何时发送命令、它将通过哪个载体发送。因此，在“服务器侧”执行把命令封装成针对载体的格式。

扩展API包括：

(a)客户端侧DLL(动态链接库)，其为“新”消息和用于发送和接收那些消息的API提供唯一的标识符，以及

(b)用于每个现存的载体插件程序的“转换器”插件程序。服务器管理这些插件程序，并且及时答复来自载体的请求而将消息转换为针对载体的格式以及转换来自针对载体的格式的消息。

如果没有找到用于在特定载体格式和特定扩展API之间进行转换的转换器插件程序，则那个载体就不能处理来自那个API的多个消息并将它们丢弃。

转换器

转换器是插件程序，负责在以下两者之间进行转换：

(a)一个客户端侧API的消息格式(无论其是否为内核API还是扩展)，以及

(b)一个载体的消息格式。

因此，原则上系统中存在有N个转换器，其中，N是载体数量和API数量的乘积。实际上，N可以比它小，因为

a)扩展API可选择不支持多个载体，以及

b)载体协议可能不支持扩展。

在以下的描述中，特定的转换器(Converter)将根据以下的约定进行命名：Converter(A，B)是在API A消息格式和载体B消息格式之间进行转换的转换器。例如，RemCon工作将提供Converter(Core，Serial)和Converter(ExtApil，Serial)，并且AVRCP将提供Converter(Core，Avrcp)和Converter(ExtApil，Avrcp)。

图3中示出了本发明的一个实际实施例，其中，示出了以下的可执行对象：

(a)RemCon服务器

(b)在客户端侧API的三个动态链接库(DLL)

○RemCon内核API

○RemCon中间客户端侧(用于扩展的框架)

○RemCon客户端内部客户端侧

(c)提供曲目名和绝对音量的API(Song Title and AbsoluteVolume API)的扩展API(ExtaApil)

(d)TargetSelectorPlug-in，TSP的基本DLL

(e)参考(或称引用)TSP

(f)BearerPlug-in，用于载体插件程序的基本DLL，参考SerialBearer，以及AVRCP载体

(g)ConveterPlug-in，用于转换器插件程序的基本DLL

○Converter(Core，Serial)

○Converter(ExtApil，Serial)

○Converter(Core，AVRCP)

○Converter(ExtApil，AVRCP)

这些组件的类定义通常如下：

RemCon

class CRemConServer：public CPolicyServer，public

MRemConTargetSelectorPluginObserver

CRemConServer是RemCon服务器的具体服务器类型。服务器拥有并控制命令队列。它是RemCond的核心，处理所有消息路由。

Class CRemSession：public CSession2

CRemSession是具体服务器侧的会话类型。

每个所附的客户端侧RRemCon句柄都将被创建一个实例。

会话及时答复来自客户端侧的所有IPC调用。

它具有一个用于保留客户端进程ID的成员(member)。这被会话用于确保每个客户端进程至多只有一个目标会话的完全实例化的实例被生成。

这种及时答复客户端请求的目的，为每个这样的异步API保留RMessage2成员，用于以后完成。

class CBearerManager：public CBase，public MRemConBearerObserverCBearerManager是CRemConServer拥有的单元素

它在实例化时，加载所有载体插件程序。它是到载体的接口。

载体

此处描述载体API的设计以及参考串行载体的设计。注意，每个载体都被要求支持每个可能的API中的所有和每一个消息。它允许在试图发送消息时通过返回KErrNotSupported而这样做，但是简单地忽略或丢弃消息是不允许的。实际上，识别API的UID被载体用于将消息转发到正确的转换器。如果没有用于那个API的转换器，则KErrNotSupported是正确的响应。如果找到了转换器但是它却不支持特定的消息(由于针对载体的原因)，则返回KErrNotSupported作为响应。

载体API

概要

载体将为插件程序。载体使用转换器插件程序(原则上，每个载体都具有一个用于每个扩展API的插件程序再加上一个用于内核API(Core API)的一个插件程序)，以在针对载体协议的消息格式和客户端友好的不知载体的消息格式之间转换每个消息。如果没有为特定的载体/API对提供转换器插件程序，则那个载体将不能发送或接收属于那个API的消息。

RemCon允许载体支持多个同时连接。

载体在服务器启动时被实例化。载体的实例化导致它倾听到来的连接。到来的连接被载体通过其自己的策略自动接收。这可包括针对协议的或其他的安全策略；虽然很明显希望确保RemCon安全，但是本发明并未指定或依赖任何特定的安全模型。

然后RemCon被通知新的连接和相关(远程地址等)参数的存在。载体被允许支持多路复用或多个“遥控信道”。RemCon由载体通知任何载体连接的状态。

载体API能够支持多个同时发送的命令和响应。如果载体能够支持排队，则RemCon将能够在一个或多个连接上、在那个载体上发出许多同时未完成的发送命令。如果载体并不支持排队，则它必须返回错误给RemCon，RemCon将相应地完成客户端的原始请求。

一项发送请求的完成时序的可能性包括：

(a)一旦载体已经通过传送尽力发送请求，

(b)当载体已经承担了消息的责任，即，当载体已经发送了请求或对用于发送的请求进行了排队，以及

(c)当响应到达时。

对于无连接的控制器，一旦命令已经被TSP寻址，则所得到的寻址消息被通过相关的载体连接发送。如果有任何失败的话，特定命令的操作就被异常终止并且控制器就被通知有关的那个错误。

RemCon没有提供用于查询可用的载体插件程序的API；这可根据需要通过使用正常的操作系统(OS)工具来实现，因为所有插件程序的性质和它们能够使用的接口都是公共信息。

同时只能支持一个连接的面向连接的载体当其被创建时将开始听。当它被连接时(通过接受连接或当由面向连接的控制器驱动时)，它将连接的状态通知RemCon。如果由于任何原因连接终止，则载体通知RemCon。

支持多个连接(例如AVRCP)的面向连接的载体当其被创建时将开始听。如果通过使用收听者而建立了连接，它将继续倾听(其他的)到来的连接。RemCon被保持最新的连接状态。

无线连接的载体必须仿真载体API的面向连接的行为。串口载体支持无连接的行为，并且它能够指示给RemCon，当Com端口被成功打开时，它被“连接了”。如果打开端口存在问题，则它将在暂停之后再次尝试连接。

相关API

(注意，以‘@’开始的行记载了API参数(param)或返回(return)条件)

class CRemConBearerPlug-in：public CBase

virtual void ConnectRequest(const TRemConAddress& aAddr)＝0；由RemCon调用以使载体连接到另一方。

@param aAddr远程地址信息。

virtual void DisconnectRequest(const TRemConAddress& aAddr)＝0；由RemCon调用以使载体与另一方断开。

@param aAddr远程地址信息。

发送消息

virtual TInt SendCommand(TUid aInterfaceUid，

TUint a OperationId，

TUint a TransactionId，

RBuf8& a Data，

const TRemConAddress& aAddr)＝0；

virtual TInt SendResponse(TUid alnterfaceUid，

TUint a OperationId，

TUint a TransactionId，

RBuf8& a Data，

const TRemConAddress& aAddr)＝0；

由RemCon调用以在一个连接上发送消息。载体必须通过返回来同步地指示请求的完成(即，它已经发送了消息或对它进行了排队以用于发送)。

@param aInterfacedUid客户端API接口的UID

@param aOperationId API内的操作ID

@param aTransactionId 该命令或响应所属的交易的标识符。

@param aData针对API的消息数据。如果载体返回KErrNone，则它被RemCon认为已经取得了其所有权。

@param aAddr远程地址信息

@返回错误

注意在接收了SendCommand请求后，载体被要求生成至少一个响应(是否真正地来自遥控器方(remote party))

接收消息

virtual TInt GetResponse(TUid&aInterfaceUid，

TUint& a TransactionId，

TUint& a OperationId，

RBuf8& a CommandData，

TRemConAddress&aAddr)＝0；

virtual TInt GetCommand(TUid&aInterfaceUid，

TUint&a TransactionId，

TUint&a OperationId，

RBuf8& a CommandData，

TRemConAddress& aAddr)＝0；

由RemCon调用以拾取先前通过载体使用NewCommand或NewResponse通知给它的消息。

@param aInterfacedUid客户端API接口的UID

@param aOperationId API内的操作ID

@param aTransactionId命令或响应的交易ID。

@param aData针对API的消息数据。所有权由载体返回。

@param aAddr远程地址信息

virtual void ClientStatus(TBool aControllerPresent，TBool

aTargetPresent)＝0；

这由RemCon调用以指示当前是否存在任何控制器客户端aControllerPresent)以及当前是否存在任何目标客户端(aTargetPresent)。

它通过以下两者而被调用：

(a)当控制器客户端的数量从0到1或从1到0变化时，以及

(b)当目标客户端的数量从0到1或从1到0变化时。

如果任何控制器存在，则aControllerPresent将为真，否则为EFalse。执行者被提醒不要与ETrue进行对比。提供该API以通过AVRCP有助于服务发现协议(SDP)记录的创建和销毁。RemCon不关心失败，因此void返回类型。

virtual TSecurityPolicy SecurityPolicy()＝0；

@返回需要使用(连接、发送、接收)该传输的能力。

RemCon有足够的能力来使用任何可想到的传输，但是它需要检查控制器客户端是否具有能力。该API被调用使得RemCon能够控制控制器客户端请求。对于面向连接的控制器，当客户端试图将其自身与载体相联系时，执行检查。对于无连接的控制器，在TSP已经选择特定载体用于客户端传输之后，执行检查。

Class MRemconBearerObsever

CRemConBearerPlug-in具有对该类对象的引用(或称参考)，其用于把请求的完成发信号通知给RemCon。

virtual TInt MrcboConnectlndicate(const TRemConAddress& aAddr)＝0；当到来的连接已经被建立时，由载体调用。

@param aAddr远程地址信息。

@返回错误。

virtual void MrcboDisconnectlndicate(const TRemConAddress&

aAddr)＝0；

当连接已经从远端断开时，由载体调用。

@param aAddr远程地址信息。

virtual TInt MrcboConnectConfirm(const TRemConAddress&aAddr，TInt

aError)＝0；

由载体调用以指示离去的连接请求的完成(CRemConBearPlug-in::connect)。

@param aAddr远程地址信息。

@param aError错误。

@返回错误。如果这不是KErrNone，则载体丢弃连接。

virtual CRemConConverter&MrcboConverter(TUid aInterfaceUid，TUid

aBearerUid)＝0；

由载体调用以指示断开请求的完成(CRemConBearPlug-in::Disconnect)。

@param aAddr远程地址信息。

@param aError错误。

到来的消息

virtual TInt MrcboNewResponse(const TRemConAddress&aAddr)＝0；

virtual TInt MrcboNewCommmand(const TRemConAddress&aAddr)＝0；

当新消息在其将要被RemCon拾取的队列中可用时，由载体进行调用。RemCon将调用Get Response或GetCommand。

@param aAddr远程地址信息。

virtual CRemConConverter&MrcboConverter(TUid aInterfaceUid，TUid

aBearerUid)＝0；

转换器的存取器。给出的两个UID可用于唯一地标识转换器。转换器由RemCon管理并且仅由载体通过该接口进行存取。

@param aBearerUid载体实施的UID。

@param aInterfaceUid接口的UID。

串行载体

串行载体是载体接口的具体实施。

CRemConSerialBearer来源于CRemConBearerPlug-in。它拥有Active Objects，其使用RComm::Read和RComm::Write来在串行线上接收和发送数据-这些通过观察器界面来通知完成。

CRemConSerialBearer在实例化时打开通信端口，并且立即向RemCon显示“连接完成”。当它从RemCon接收发送命令的请求时，它将API UID和操作UID封装入固定宽度的缓冲器(使用适当的转换器)并且通过串行线将其发送而不需要重试。当RComm::Write完成时，CRemConSerialBearer被通知，并且它调用在观察器上的SendComplete。当它从RemCon接收一项接收命令的请求时，它为固定的缓冲器大小排队RComm::Read。当这完成时，使用适当的转换器将字符串解压成API UID和操作ID，其被通过ReceiveComplete通知给观察器。

TSP

概述

TSP是插件程序。

class CRemConTargetSelectorPlug-in：public CBase

virtual void AddressOutgoingCommand(TUid aInterfaceUid，TUint

aOperationId，const TClientlnfo&aSender，

TSglQue<TRemConAddress>&aConnections，

TSglQue<TBearerSecurity>&aBearerSecurity)＝0；

这由RemCon调用以寻址所给定的离去的(即，从无连接的控制器)命令(aInterfaceUid/aOperationId)。当被传入时aConnections为空。TSP附加零或更多TRemoteAddresses并且调用RemCon上的OutgoingCommandAddressed。TSP可异步地完成它。RemCon通过相关连接信息将命令引导到所给定的载体。

virtual void PermitOutgoingCommand(TUid aInterfaceUid，TUint

aOperationId，const TClientlnfo&a Sender，const TRemConAddress&

aConnection)＝0；

当面向连接的控制器试图发送命令时，这由RemCon调用。TSP使用ETrue(允许发送)或EFalse(不允许发送)调用OutgoingComandPermitted。

virtual void AddresslncomingCommand(TUld aInterfaceUid，TUint

aOperation Id，TSglQue<TClientInfo>&aClients)＝0；

这由RemCon调用以寻址所给定的到来的命令。aClients，当被传入时，包含当前的目标客户端集。TSP从该集合添加或去除零或更多的项并且调用在RemCon上的IncomingCommandAddressed。TSP可异步地完成它。TSP不受限地启动客户端应用程序并且将适当的TClientInfo(至少用它们的进程ID插值(populate))添加到集合。RemCon将命令引导到给定的客户端，而无需假定它们中的任何一个仍尚存。

class MRemConTargetSelectorPluginObserver

由RemCon实施。

virtual void MrctspoOutgoingCommandAddressed(TInt aError)＝0；

由TSP调用以指示先前的AddressOutgoingCommand请求已经被回答了。(通过引用而传递的阵列已经被正确地插值)。在任何时刻NB只有一个AddressOutgoingCommand可能未完成，但是一次可能有多于一个AddressOutgoingCommand和AddressIncomingCommand未完成。

virtual void MrctspoOutgoingCommand Permitted(TBool alsPermitted)＝0；

由TSP调用以指示它已经决定了由最近对PermitOutgoingCommand的调用所表示的控制器发送(the controllersend)是否得到允许。

virtual void MrctspoIncomingCommandAddressed(TInt aError)＝0；

由TSP调用以指示先前的AddressIncomingCommand请求已经被答复(通过引用而传递的阵列被正确的插值)。应该指出任何时候可能只有一个AddressIncomingCommand未完成，但是同时可能有多于一个AddressOutgoingCommand和AddressIncomingCommand未完成。

TClientInfo

这是包装客户端会话的进程ID以及当前发送消息(current sendmessage)的一种简单类型，其可能出于安全的目的而被使用。

客户端侧

概述

RemCon客户端侧对发送并接收命令及响应给予支持。它也是可扩展的。它具有三个层，如图3所示：

1.“内部”客户端侧，其最接近服务器，由单个含RRemCon的DLL构成，

2.“中间”层，由单个DLL构成，其(a)将来自内部客户端侧的消息传递到适当的“外部”DLL，(b)提供API接口所基于的抽象接口，以及(c)为最后的客户端提供中央会话创建和控制点，以及

3.“外部”层，由实际的API DLL构成。Core API DLL和“扩展API 1”DLL(支持曲目名和绝对音量消息)在该层中提供。第三方可在该层中添加其他的API。该层中的每个DLL都由其“APIUID”唯一标识。

内部客户端侧发送和接收通用数据。数据包括接口UID(与特定的外部层DLL有关)、在那个接口中的操作的ID、以及任何相关的数据。接口UID和操作ID一起构成唯一的消息标识符。

客户端静态地链接到它们想要使用的一个或多个外部层DLL并且链接到中间层。在实例化时，客户端调用在中间层DLL上的方法以向中间层登记来自外部层DLL的对象(通过其接口UID)。中间层表示打开RemCon会话的方法。

当客户端发送消息时，外部层DLL添加其接口UID，并且中间层仅仅将该数据整个全转发给RemCon。当接收到命令时，TSP决定它将要传递到哪个(些)目标。当接收到响应时，RemCon将其交给发送原始请求的控制器客户端。RemCon服务器仅仅将消息传递给在“内部”客户端侧的所指出的目标RRemCon会话，其将消息传递到中间层。中间层分析该消息的接口UID，并且，如果它具有带有那个UID的登记的外部层对象，则它将消息传递给那个外部层对象。外部层DLL分析操作ID，可选地分解相关的(描述符)数据，并且通过其自己的API将消息交给最后的客户端。内部客户端侧(RRemCon)

“中间”客户端侧是最接近服务器的。它包括单个的R类、RRemCon、以及一些辅助类型。

优选地，在RemCon在这点存取时实施某些类型的安全控制以避免将控制交给任何可能滥用或误用它的实体。该发明是对于任何特定的安全模型不可知的。

RemCon API的内部层是客户端不能访问的。

class RRemCon：public RSessionBase

RemCon是用于RemCon服务器的客户端侧的会话类型的抽象基类。它仅被用于在系统的调试建立时提供服务器堆故障调试API。这些在此处没有详细描述。以下的API可从派生的具体类的实例得到。

IMPORT_C TVersion()const；

返回RemCon服务器的版本。该API是唯一的(除了Close)能够在连接前被调用的。

IMPORT_C TInt Connect()；

这是标准的会话句柄连接方法。如果句柄创建成功，则向RemCon服务器进行进一步的IPC调用以将客户端的“类型”设置为目标或控制器。

IMPORT_Cvoid Send(TRequestStatus&aStatus，TUid aInterfaceUid，

TUint aOperationId，TUint&aNumRemotes，const TDesC8&aData＝

KNullDesC8())；

由“目标”使用Send来向命令发送响应，并且由“控制器”使用Send来发送命令。

当目标客户端发送响应时，它在传送原始命令的载体上被发送。该寻址由RemCon自身执行。aInterfacedUid包含消息所属的接口(内核、或扩展)的UID。aOperationald是在那个接口内的操作的ID。aData是任何相关的数据。如果客户端是目标(即，发送响应)，并且RemCon服务器未记得已经向这个客户端传递了相应的命令，则客户端将会恐慌。

在完成时，aNumRemotes包含消息被发送到的遥控器(remotes)的数量。如果消息是一条响应，或来自面向连接的控制器，那么，这将在成功时为1，在失败时为0。如果客户端是无连接控制器，则aNumRemotes指示TSP已请求该命令发送到的遥控器中有多少成功了(在载体级)。注意TSP可以说发送命令到0遥控器。这不并认为是错误而认为是成功的情况。

IMPORT_C TInt SendCancel()；

取消客户端对完成异步发送请求的兴趣(interest)。

IMPORT_C void Receive(TRequestStatus& aStatus，TUid&aInterfaceUid，

TUint&aOperationid，TDes8&aData)；

目标使用Receive来接收命令，并且控制器使用Receive来接收对命令的响应。

目标在TSP机制下，有效地接收来自所有载体的命令，。控制器客户端依靠RemCon使响应被传递给它们，其中RemCon记得发起每个命令的控制器以及命令由其发出的连接。

IMPORT_C TInt ReceiveCancel()；

取消客户端对完成异步接收请求的兴趣。

IMPORT_C TInt GetConnections(TSglQue<TRemConAddress>&

aConnections)；

在所有载体上当前尚存的连接的同步获得器(getter)。

TRemConAddress指示载体(通过其实施UID)和针对载体的连接信息。如果连接在阵列中，则它作为载体级连接存在于RemCon中。如果它不在于阵列中，则它不作为载体级连接存在于系统中。没有其他的状态是相关的。成功时，客户端负责该队列中的项。

IMPORT_C void NotifyConnectionsChange(TRequestStatus&aStatus)；

通知对载体连接状态的改变。在完成时，客户端优选地使用GetConnections来检查实际的连接。

IMPORT_C TInt NotifyConnectionsChangeCancel()；

取消客户端对载体连接状态变化通知完成的兴趣。

class RRemConController：public RRemCon

这是具体的控制器会话类型。

IMPORT_C TInt GoConnectionOriented(const TRemConAddress&

aConnection)；

利用所给定的地址使得控制器面向连接。该地址用于发送来自该会话的所有命令，并且所有的响应将来自该遥控器(或由相应的载体生成)。假如客户端没有关于安全的问题，则RemCon相应地完成GoConnectionOriented。这是RemCon自身所做的唯一的安全检查，并且它是所有的位于面向连接的客户端和载体之间的。每个命令也都被TSP在发送时“允许”。

IMPORT_C TInt GoConnectionless()；

利用所给定的遥控器，使得控制器无连接。TSP将用于寻址每个被发送的命令。

IMPORT_C void ConnectBearer(TRequestStatus&aStatus)；

控制器客户端可以调用该API以试图利用先前向GoConnectionOriented登记的TRemConAddress来创建载体级连接。该API仅能由面向连接的控制器使用。

IMPORT_C TInt ConnectBearerCancel()；

取消客户端对“连接载体”请求完成的兴趣。

IMPORT_C void DisconnectBearer(TRequestStatus&aStatus)；

控制器客户端可以调用该API以试图利用先前向GoConnectionOriented登记的TRemConAddress来销毁载体级连接。该API仅能由面向连接的控制器使用。

IMPORT_C TInt DisconnectBearerCancel()；

取消客户端对“断开连接”请求完成的兴趣。

class RRemConTarget：public RRemCon

这是具体的目标会话类型。

TRem ConA ddress

这是打包UID(载体的实施UID)和用于保持针对载体的连接信息的窄缓存区的简单类型。

中间层

class CRem ConIn terfaceSelector：public CBase

这是具体的类。它拥有一个RRemConController和一个RRemConTarget会话，并且，对于每一个，Active Object都维持一项有关该会话的接收请求。它是客户端与RemCon进行交互的核心。客户端实例化CRemConInterfaceSelector。期望的API接口的实例被创建，由CRemConInterfaceSelector所拥有。然后它们打开控制器和/或目标会话(通过选择器的API)，然后，(a)利用接口来发送命令并且等待响应，或(b)也利用接口来等待命令并且发送响应。

IMPORT_C void OpenControllerL()

由客户端使用来打开控制器会话。它默认为无连接。

IMPORT_C void OpenTargetL()；

由客户端使用来打开目标会话。

提供其他的API以打包RRemCon*API。

class CRemConInterfaceBase：public CBase

这是用于API接口的基类，包括Core API。

接收消息

virtual void MrcibNewResponse(TUint aOperationld，const TDesC8&

aData)＝0；

virtual void MrcibNewCommand(TUint aOperationld，const TDesC8&

aData)＝0；

当适当类型的消息进入且接口UID属于CRemConInterfacedBase的实例化时，这些就由中间层调用。

外部层

所提供的组件包括“核”API外部层DLL。它提供CRemConInterfaceBase的实施，一个用于控制器客户端，一个用于目标客户端。它还提供了测试“扩展”外部层DLL以推出曲目名和绝对音量API(Song Titleand Absolute Volume API)。

转换器

转换器是插件程序，实施该接口，并且是无所有权的(stateless)。

API主要包括两个函数

·用于从针对载体的到针对接口的形式进行转换的第一函数

·用于在相反的方向转换的第二函数

应该指出载体并不是必须使用转换器。它可硬编码其所有转换代码。然而，这假定载体将知道如何转换任何将来的API扩展。如果载体仅打算支持已经存在的消息组而不是为了可扩展性转换器应该被优选地使用，这是完全可接受的。

class CRemConConverterPlugin：public CBase

virtual TInt InterfaceToBearer(TUid aInterfaceUid，TUint aOperationld，

const TDesC8&aData，TRemConMessageType aMsgType，TDes8&

aBearerData)const＝0；

由载体调用以将针对接口的数据(接口UID、操作ID、消息类型和数据)转换为针对载体的(封装的)形式。

virtual TInt BearerToInterface(const TDesC8&aBearerData，TUid&

aInterfaceUid，TUint&aOperationld，TRemConMessageType&aMsgType，

TDes8&aData)const＝0；

由载体调用以将针对载体的数据(封装的)转换为针对接口的数据(接口UID、操作ID、消息类型和数据)。

virtual TBool SupportedUids(const TUid&aInterfaceUid，const TUid&

aBearerUid)const＝0；

由RemCon调用以查明是否该转换器在该接口和该载体之间进行转换。

virtual TBool SupportedInterface(const TDesC8&aInterfaceData，const

TUid&aBearerUid)const＝0；

由RemCon调用以查明是否该转换器在该接口和该载体之间进行转换。aInterfaceData是以针对载体的格式的接口标识符。

服务器系统的典型操作情况可如下：

启动

示例性客户端启动代码

客户端必须做下面的：

CRemConInterfaceSelector＊ iInterfaceSelector

CRemConInterfaceSelector::NewL()；

然后，客户端必须创建它们想要使用的接口的实例。例如，对于希望用作目标且使用Core API的应用程序：

CRemConCoreApiTarget＊iCorelf＝

CRemConCoreApiTarget::NewL(＊iInterfaceSelector，＊this)；

其中，“this”执行MRemConCoreApiTargetObserver。iCorelf现在由接口选择器拥有，该接口选择器由客户端拥有。

MRemConCoreApiTargetObserver具有用于在各种到来的CoreAPI命令被传递时通知执行器(implementer)的虚函数。CRemConCoreApiTarget也具有用于允许应用程序发送对这些命令的响应的方法。

然后客户端需要创建控制器或目标会话。CRemConInterfaceSelector的每个实例都只有一个可以被创建。每个客户端进程都只有一个目标可被连接。

创建控制器会话：

iInterfaceSelector-＞OpenControllerL()；

在无连接模式下控制器会话被打开(所发送的任何命令都将通过TSP进行路由)。为了使得控制器面向连接，可跟随以下：

TRemConAddress addr；

addr.BearerUid()＝TUid::Uid(0×1020453C)；

//No bearer-specific connection data.

iInterfaceSelector-＞GoConnectionOrientedL(addr)；

客户端可能希望在该时刻建立载体级连接，以使得第一命令发送得更快：

TRequestStatus stat；

iInterfaceSelector-＞ConnectBearer(stat)；

User::WaitForRequest(stat)；

在上面的例子中，使用具有实施UID 0x1020453C的载体。这是测试串行载体。由面向连接的控制器所发送的任何命令都被引导到在该呼叫中所给定的特定连接。

为了打开目标会话，以下就被调用：

iInterfaceSelector-＞OpenTargetL()；

服务器侧

通过第一会话(控制器或目标)的连接，RemCon服务器在其自己的进程中被启动。如果服务器已经在运行，则会话将简单地被连接。

首先，创建CRemConServer的单元素(singleton)实例。在C++构造之后该服务器做的第一件事是使用其唯一的服务器名通过StartL将其自身向内核进行登记。如果已经有了正在运行的服务器的实例(因为由试图进行连接的多于一个的服务器侧所引发竞争条件)，StartL将离开，并且初期的服务器将被毫无痕迹地去掉。这确保在系统中仅总是(至多)有一个单个完全实例化的RemCon服务器。

在StarL之后，服务器通过相关的动作，着手创建以下对象：

(a)可能需要的任何操作系统对象，例如插件程序的任何系统登陆对象或框架对象(例如Symbian的公共对象模块)

(b)关闭定时器。这被用于当没有连接的会话时终止服务器。它仅在最后的会话关闭时启动。

(c)单元素连接历史对象，用于支持GetConnections和NotifyConnectionsChange API。

(d)CBearerManager的单元素实例。载体管理器的创建应该导致(在其ConstructL)所有载体插件程序被枚举和实例化。这导致面向连接的载体开始倾听到来的连接。测试串行(无连接)载体打开其COM端口，并且立即通过ConnectComplete回叫，就好像它已经被请求进行离去的连接。如果在该系统中没有载体实施。则RemCon将会恐慌(panic)。这是因为，如果它是有效的设备结构，则RemCon不应该已被实施。

(e)CMessageQueue的五个实例，用于日志记录消息。对于以下中每一个都有一个：离去的悬而未决的寻址或由TSP授权的许可；离去的已经被发出的命令(来自遥控器的悬而未决的响应)；到来的命令悬而未决的通过TSP的寻址；到来的消息，其为被发出的悬而未决的客户端接收请求响应；到来的命令，其已经被传递到控制器会话(等候来自控制器的响应)。

(f)转换器管理器的单元素实例。这形成了每个转换器的一个实例。

(g)TSP的单元素实例。如果系统中不存在正好一个TSP接口的实施，则RemCon将会恐慌。TSP可执行任何它想要的实例化，但是RemCon根本不期望它做任何事，除了成功地返回可被用于寻址命令的对象。

所有上述动作同步发生。从这一点开始，系统被成功地实例化。在此之后，在服务器启动代码中立即调用CActiveScheduler::Start，并且任何进一步的动作都异步发生。这些动作包括：

(a)对通过来自远端的载体的连接的改变。如果到来的连接出现，则载体告诉RemCon。如果连接被远程地丢弃，则也告诉RemCon。RemCon使用该信息完成客户端通知。

(b)完成RemCon发起的对用于特定连接的载体的连接或断开的请求。RemCon以与远程触发的连接变化相同的方式处理这些。连接和断开请求由客户端发起。当RemCon想要通过特定的连接发送消息时，它并不首先检查它存在(只要载体存在)——RemCon仅将消息给载体并且留下载体来处理这一消息。

(c)从载体到来的消息

(d)到来的客户端请求。如果客户端关闭其会话，则，如果它是最后的会话，则服务器将开始关闭。下面描述一种典型的关闭情况。如果客户端试图发送消息，则消息将被TSP或明确地被客户端寻址(如果它是面向连接的话)。

关闭

为了从RemCon断开，客户端必须删除任何接口对象，然后删除接口选择器。最后打开的会话的关闭引发服务器的关闭。

当会话关闭时，它的析构函数(destructor)被调用。这就无条件地把事件通知给服务器，其从队列中去除属于那个会话的任何命令，并且跟踪打开的会话的数量。如果打开的会话的数量降到零，则关闭定时器启动。当关闭定时器激起时，服务器通过调用CActiveScheduler::Stop来终止其自身。如果任何新会话到达(在任何时候)，则关闭定时器被取消，以确信当会话被请求时服务器并未被终止。

当调用CActiveScheduler::Stop时，在对CActiveScheduler::Start调用之后，执行就返回到服务器启动代码。服务器对象被立即销毁。以下的事件也按下列顺序出现：

(a)载体管理器被销毁。这取消了所有对载体的请求并且同时销毁它们。载体的销毁被安排得毫无痕迹地进行操作，适当地关闭连接并取消对它们的服务提供商的自请求。

(b)此时关闭定时器可被安全地销毁。

(c)消息阵列被销毁

(d)TSP被销毁。然而，可能有对其未完成的请求，举例来说，如果存在当前正被TSP寻址的到来的命令的话。因此，TSP被安排来取消任何未完成的请求并在此时自净化。

(e)转换器管理器被销毁。它销毁所有的转换器实例。

(f)销毁连接历史对象。

(g)任何已被创建的操作系统对象现在也都被销毁。

一旦已经启动，服务器的销毁就是不可挽回的。当服务器关闭正在发生时，如果客户端试图连接，则内核(kernel)将完成客户端想连接到错误信息的尝试。在这种情况下，客户端侧然后将重启服务器并且再次试图连接。

离去的命令和到来的响应

离去的命令场景能够以控制器客户端使用由实例化的接口提供的API来发送命令开始，例如：

TRequestStatus stat；

iCoreIf>Play(stat)；

User::WaitForRequest(stat)；

Core API将例如播放请求等转换为通用“操作ID”和相关的数据(例如播放速度)。它用其接口UID将该数据传递到中间层。中间层使用其控制器会话来发送消息给服务器。

服务器检查控制器会话。CRemConMessage被构造为包含连接地址(如果控制器是面向连接的)、接口UID、操作ID、相关的数据、消息类型(命令或响应)、以及发起会话的ID。

如果会话是面向连接的控制器，则该消息被放在“离去的对TSP悬而未决的访问”队列上并且被交给TSP以取得授权许可。如果得到许可，则消息被放在“离去的被发送的”队列上，并且被传递到具有给定的连接地址的正确的载体。载体同步指示该请求-如果它出错则将消息从“离去的被发送的”队列中去除-的接收。客户端的发送请求就被立即完成。如果许可被TSP否决了，则利用KErrPermissionDenied来完成客户端的请求。

如果控制器是无连接的，则将消息放在“离去的对TSP悬而未决的访问”队列上，并将消息给TSP以进行(可能异步地)寻址。当TSP完成寻址请求时，将消息从“离去的对TSP悬而未决的访问”队列中去除，并且N个拷贝被插在在“离去的被发送的”队列上。每个由TSP表示的地址有一个，并且也向具有相关寻址信息的正确载体发送N次。任何错误直到这点返回到队列中，并且弄错该客户端。在该方案中TSP的目的实际上是插值消息的连接地址字段以使其被发送出去。

在稍后的点，遥控器可对已经被发送的命令发送响应。针对“离去的被发送的”队列，该响应的远端地址、接口UID和操作ID被检查。如果发现了匹配项，则发起命令的源会话ID被用于寻址所到来的对客户端控制器的响应。如果未发现匹配命令，则将响应丢弃。响应被用于完成客户端接收响应，并且“离去的被发送的”队列被清除该命令，其现在已经被匹配了。应该指出，中间层(CRemConInterfaceSelector)在它具有的任何连接控制器或目标上保留未完成的接收请求。“到来的悬而未决接收”队列可被用于在客户端不具有悬而未决的接收请求时，对响应和命令这两者都进行排队。

在客户端侧，由服务器将新响应传递给特定的控制器会话。拥有的接口选择器接通接口UID并且调用接口上的NewResponse。接口检查操作ID并且可选地分解相关的数据，并且，例如，调用在观察器(客户端)上的PlayResponse。

总之，客户端进行异步请求以发送命令。请求被完成，并且在稍后的时间，客户端使PlayResponse在其上被调用。

如果TSP把播放命令(Play Command)引导到多个遥控器，并且它们的每个都生成响应，PlayResponse则将结束在客户端上被调用多次。

到来的命令和离去的响应

该方案以传递到来的命令到RemCon的载体开始。RemCon生成含CRemConMessage的远端地址、接口UID、操作ID、相关数据、以及消息类型(命令或响应)。该消息被放入“到来的悬而未决的地址”队列，并且发送到TSP用于寻址。

该方案中TSP的目的实际上是插值地址的会话ID字段。一旦这被完成，就将消息从“到来的悬而未决的地址”队列中去除，并且N个拷贝被添加到“到来的被传递的”队列，并且每个都被传递到相关的目标客户端：如果在该会话中命令到达时客户端没有未完成的接收响应，则可使用“到来的悬而未决的接收”中间层检查接口UID，将消息转发给正确的接口对象。接口分解消息并且调用例如在客户端上的播放，从而指示播放命令已经被接收到。

客户端可选择发送响应。它调用PlayResponse，其通过中间层的目标会话发送消息给RemCon。服务器在“到来的被传递的”队列中查找与会话ID、接口UID和操作ID匹配的命令，并且使用所找到的命令的远端地址来寻址对正确载体的响应。所找到的命令从队列中被去除并被销毁。

遥控客户端应用程序可按如下被实施。该方案涉及利用现存的远程控制(遥控)API来实施遥控系统的客户端。

首先，它确定该应用程序是否用于控制器或目标。如果它被要求来遥控其他设备，则需要控制器应用程序。如果它被要求来被遥控，则要求目标应用程序。它被允许在任何一个时刻既为控制器又为目标。

如果控制器被要求，则有必要知道与哪个遥控器通信，并且通过哪个载体。如果该信息是已知的，则应用程序可以面向连接的模式操作，这种情况下，将载体和遥控器的地址明确地告诉遥控系统。如果信息未知，则它被要求以无连接模式(默认的)操作。在这种情况下，命令由系统(具体地，由设备制造商提供的目标选择器插件程序)进行路由。

然后必须确定哪些API被要求使用。Core API被提供，其覆盖许多基本操作，包括播放、停止、等等。(也提供TrackInfo和Absolute Volume API，但是并不要求较低级的执行能够通过蓝牙发送和接收这种消息)。

现在将对控制器设置进行说明。

第一步是创建CRemConInterfaceSelector的实例。这是客户端侧的核心，拥有服务器和接口对象上的会话，并且在它们之间路由信息。

CRemConInterfaceSelector＊sel＝CRemConInterfaceSelector::NewL()；

下一步，期望的API的控制器接口的一个实例被创建(在该例子中Core API)。

CRemConCoreApiController＊cont＝

CRemConCoreApiController::NewL(＊this，＊sel)；

该代码假定这是实现MRemConCoreApiControllerObserver的类型的对象。该项混入(mixin)确定如何传递到来的响应(对你的命令)。cont的所有权现在位于sel。

现在必须告诉接口选择器将控制器会话与服务器进行连接。

sel-＞OpenControllerL()；

在这点上，控制器会话是无连接的。任何被发送的命令将由TSP寻址。如果待被控制的载体和遥控器是已知的，则可以使用以下代码。

TRemConAddress addr；

addr，BearerUid()＝xxx；//xxx＝the bearer’s UID

addr.Addr()＝yyy；//the yyy＝remote’s address in

bearer-specific form

sel-＞GoConnectionOrientedL(addr)；

一旦GoConnectionOrientedL成功，则应用程序是面向连接的，并且控制器会话被专用于与所指定的单一遥控器进行通信。TSP并不寻址特定的命令，但是仍然允许或拒绝每个被发送的命令。注意，通过该操作没有建立与该遥控器的载体级连接。

有可能再次变为无连接，通过使用：

sel-＞GoConnectionlessL()；

一旦是面向连接的，为了减小所发送的第一命令的等待时间，能够明确地建立与遥控器的载体级连接，如下：

TRequestStatus stat；

sel-＞ConnectBearer(stat)；

User::WaitForRequest(stat)；

当第一(以及任何后续的)命令被发送的时候，如果没有这样做，则服务器将试图根据要求而建立连接。ConnectBearer被提供作为用于减小等待时间的设施。

载体级连接可被拆断，如下：

TRequestStatus stat ；

sel-＞DisconnectBearer(stat)；

User::WaitForRequest(stat)；

值得注意，载体级连接不应该被任意控制。仅可能控制应用程序当前“面向连接”于其上的载体级连接。这是由于ConnectBearer和DisconnectBearer中缺少TRemConAddress参数。

还应该注意，遥控器可在其自己的要求下建立或拆断应用程序连接。如果遥控器拆断连接，则下一个被发送的命令将导致服务器试图将其再次拉回。这可招致未被预期的延迟。如果再次连接失败，则发送失败。尽管所有这些，应用程序都将保持面向连接：连接方向独立于任何实际的载体级连接。

如果载体级连接的状态被认为有兴趣(interest)，则以下的有关于CRemConInterfaceSelector的API可被使用：

IMPORT_C TInt

GetConnections(TSglQue<TRemConAddress>&aConnections)；

IMPORT_C void

NotifyConnectionsChange(TRequestStatus&aStatus)；

IMPORT_C TInt NotifyConnect ionsChangeCancel()；

GetConnections提供在系统中的所有当前尚存的连接。

NotifyConectionsChange仅指示何时设置已经改变。

发送命令和接收响应

cont现在可被用于按如下来发送命令：

TRequestStatus stat ；

cont-＞Play(stat)；

User::WaitForRequest(stat)；

通过MRemConCoreApiControllerObserver接口传递响应。

在任何时候都只有一个发送(send)命令是未完成的。如果无连接控制器正被实施，则TSP可能已经将该命令寻址到多个遥控器。在这种情况下，单个发送命令可导致多个响应，并且在认为适当时，这些被过滤或使用。

如果TSP已经将命令发送到多个遥控器，并且那些发送中的一个或多个失败，则将从失败的发送中的一个提供错误值。也提供命令被成功发送到的遥控器的数量。载体必须对它们发出的每个命令都给出响应。取决于载体，该响应实际上可能或可能不是来自于遥控器。在载体级，发送或者成功或者失败——或者载体负责发送或者不负责发送。因此，甚至“成功”的发送都可能实际上并未导致传输到所请求的遥控器。

注意，被发送到遥控器的每个命令都涉及在服务器的堆中被分配的内存，其仅在客户端关闭或在响应被接收到时才被释放。如果有好的理由相信不要求通信的任何遥控器都不再存在，则它被优选地安排来阻止发送命令给那个遥控器，以减小服务器中的存储器中的负载。

拆掉

为了清除在遥控系统中的参与，所有未完成的异步请求都应该被取消，并且接口选择器应该被删除。

目标

设置

其非常类似于控制器设置，除了不存在面向连接的概念以外。目标实施混入(mixin)——通过该混入接口选择器传递到来的命令并且实例化一个对象以发送响应。所有到来的命令都由TSP寻址。离去的响应隐式(implicitly)地被寻址到发起的命令所来自的遥控器。

CRemConInterfaceSelector＊sel＝

CRemConInterfaceSelector::NewL()；

CRemConCoreApt＊targ＝

CRemConCoreApiTarget::NewL(＊this，＊sel)；

Targ的所有权现在位于sel。

客户端现在打开服务器上的目标会话。

sel-＞OpenTargetL()；

接收命令和发送响应

到来的命令通过(在上述情况中)MRemConCoreApiTargetObserver混入而给出。

接收到命令后，它被要求发送响应。

TRequestStatus stat；

cont-＞PlayResponse(stat，response)；

User::WaitForRequest(stat)；

在任何时刻都只能有一个响应未完成。如果命令来得很快，就需要把对它们的请求进行排队。然而，应该记住，传递到目标的每个命令都涉及在服务器的堆中所分配的内存，其仅在客户端关闭或当响应被发送之后才被释放。

拆掉

为了清除在遥控系统中所包含的内容(involvement)，所有未完成的异步请求都应该被取消，并且接口选择器应该被删除。

新的遥控API可按如下实施。

为了实施新API，需要着手两件工作：创建外部层DLL，以及创建转换器家族。

外部层DLL

外部层DLL的工作是：

(a)向客户端提供友好的API，

(b)在客户端API中的字段/项(term)和DLL的内部数据格式(这将既包括操作ID也包括针对操作的数据的字段的布局)之间进行转换，以及

(c)根据需要，公开尽可能多的上述内容，以(i)授权客户端使用API，以及(ii)对转换器的实施器授权。

遵循在Core API中所建立的模式，可跟随以下步骤：

○创建针对remconinterfacebase.lib的静态DLL链接

○为API分配新UID。

○为新API中每个控制器和目标类型来定义类，每个都派生自CRemConInterfaceB ase。

○为控制器提供NewL和析构函数方法、以及公共的输出方法来发送命令，并且为目标提供NewL和析构函数方法、以及公共的输出方法来发送响应。

○为每个控制器和目标、为将被告知到来的响应和命令的客户端分别定义观察器混入。

○在每个接口中，

CRemConInterfaceBase::MrcibNewMessage都可能被实施以对到来的消息解码并且调用正确的混入方法。

○指定操作标识符，以及在API中的每个消息的格式。这些都将被用于创建转换器。

转换器

当客户端使用外部层DLL来发送消息时，载体接收以下信息：消息所来自的API的UID、消息的操作ID，以及含有任何针对操作的数据的描述符。在针对操作数据中的数据格式和载体所要求的格式之间进行转换是转换器的工作。

转换器API在remotecontrol\converterplug-in\public(但是实际上#include from epoc32\include\remcon)中。Core Serial转换器位于remotecontrol\test\converters\Core Serial。

遵循在Core Serial转换器中所建立的模式，应该为转换器分配新的实施UID，从而实施作为ECOM插件程序的转换器API。

CRemConConverterPlug-in::SupportedUids (const TUid&aInterfaceUid，const TUid&aBearerUid)应该被实施，以确定是否支持在给定的API和给定的载体之间消息格式的转换。

CRemConConverterPlug-in::SupportedInterface(const TDesC8&aInterfaceData，const TUid&aBearerUid)然后被实施以回答相同的支持问题，除了以略微不同的方式提出的问题以外。在这种情况下，API按所给定载体的格式的包进行标识。剩余的转换器实施则相对直截了当。

转换器是无所有权的同步数据处理机。为了进行转换，转换器不得不知道API的操作ID、以及API的UID。

然而，载体必须明确地请求转换器的帮助以“理解”消息。如果载体不这样做，则没有转换器将被调用-载体基本上对API关闭了，除了它已经知道如何对其进行转换的那些API以外。取决于载体，这可能完全有效。

然而，如果实施新API，则必须为每个现存的载体提供转换器。如果没有提供该信息，则框架就不能(failing)有效地通知载体如何在其格式和新API的格式之间转换消息：基本上，这等于是说不能在那个特定的载体上使用新API。取决于特定框架之需要，这也可能是可以的。

转换器不仅需要格式化由API公开的信息，而且也需要格式化来自载体的信息。然而，在事情的本质上，载体格式更可能作为已公开的规范(例如AVRCP)存在，而并不是专有的遥控API。

TSP可如下被实施。

首先，用新实施UID来实施一个执行TSP API的插件程序。

应该准备TSP，使其能够回答以下问题：

(a)服务器应该将以下到来的命令传递到哪些当前被连接的(即被连接到服务器的)目标客户端(利用接口UID和操作ID，以及关于目标客户端的信息的集合，包括它们的安全ID)

(b)服务器应该将以下离去的命令传递到哪个(些)遥控器(利用接口UID和操作ID，以及关于试图发送命令的控制器客户端的信息，包括它的安全ID和它的RMessage2，以及用于载体的TSecurityPolicys的集合)

应该记住，如果TSP给客户端X一个命令，则它有效地授权客户端X精确通过已传递原始命令的载体来发送一个响应。

ROM中必须只有一个这样的DLL。

新的遥控载体可如下被实施。

用新的实施UID来创建一个执行载体API的插件程序。

载体API是面向连接的。被发送和传递的所有消息都与特定的接收方地址或特定的发送方地址相关。服务器负责在发出被发送到特定遥控器的载体级之前，建立到那个遥控器的载体级连接。

真实的载体可能实际上不是面向连接的。例如，测试串行载体仅通过串行缆工作。因此，(a)它不具有针对载体的远端地址格式(所以“远端地址”仅由串行载体UID构成)，以及(b)它不得不通过基本上在启动时“指示”到来的连接来仿真面向连接的行为(当它首先打开串行端口时)。该“连接”从不会断掉。

在服务器启动时，载体被实例化，并且应该立即开始倾听到来的连接。每个连接都由服务器指示。

可从上述说明书中看出，本发明提供了通用的遥控装置，它比当前的非通用框架提供相当大的优点，包括：

·有助于创建可被遥控的应用程序。因为现有的遥控技术方案总是依赖一个载体技术，它迄今还没有可能提供用于通用遥控器的应用程序，除非已开发应用程序来使用特定的有关的载体技术。

·设备制造商利用新技术来发行售后附件的能力在设备制造时是不被提供的。在没有本发明的情况下，任何这种附件都会需要以新版的任何可控的应用程序来运送。

·拥有多个当前同时运行在该设备上的可控的应用程序的能力：在存在多于一个应用程序的情况下，它为选择若干可能的目标应用程序中的一个提供了一种机制。

虽然参照特定实施例描述了本发明，应该意识到在不脱离所附的权利要求限定的范围的情况下，可以实施各种修改。

本发明的这种修改的一种可能的例子可适用于具有多个音频应用程序的计算设备，所有这些音频应用程序都已经登记为用于接收遥控命令。这种具有多个音频应用程序的计算设备可包括：具有许多能够播放音频数据的多媒体应用程序(例如MP3播放器、收音机、浏览器插入程序(其能够播放来自互联网的流音频、声音备忘或听写(dictation)应用程序)、以及本地语音邮件存储)的移动电话。

如果所有这些应用程序都已经登记为用于接收遥控命令，则在一个应用程序已经播放音频的情况下，本实施例将通过使遥控管理器能将这种设备上的遥控命令传递到已经播放音频的应用程序，来使这种命令能被正确传递。

Claims

1.一种使一个或多个目标设备能够被一个或多个控制器设备所遥控的方法，所述控制器设备通过使用经由多个载体中的至少一个所发送的命令来进行遥控，所述载体包括：

·固定导线，包括USB和简单串口

·红外线

·超声波

·RF，包括蓝牙和802.11无线联网

2.根据权利要求1所述的方法，其中，至少一个目标设备，除了作为用于接收来自控制器设备的命令的目标设备以外，还能够作为用于将命令传输到目标设备的控制器设备。

3.根据权利要求1或2所述的方法，其中，至少一个控制器设备，除了作为用于将命令传输到目标设备的控制器设备以外，还能够作为用于接收来自控制器设备的命令的目标设备。

4.根据前述权利要求1所述的方法，其中，所述通用遥控器接口被提供利用针对特定类型载体的插件程序模块的能力。

5.根据权利要求4所述的方法，其中，目标设备和/或控制器设备被安排来使得用于其他载体的附加插件程序模块能够在制造后被添加。

6.根据权利要求1所述的方法，其中，所述多个应用程序包括音频应用程序，所述命令通过所述目标选择器被路由到当前正播放音频的所述应用程序。

7.根据权利要求1所述的方法，其中，所述目标选择器是插件程序。

8.根据前述权利要求1所述的方法，其中，所述遥控器接口被配置为服务器。

9.根据权利要求8所述的方法，其中，所述服务器被配置为瞬态服务器。

10.根据权利要求8或9所述的方法，其中，所述目标选择器就被安排在所述服务器内。

11.根据权利要求1所述的方法，其中，所述方法配置为基于以下因素中的任意一个或多个因素在控制器设备和目标设备之间传送命令：

a.在所述目标设备的只读存储器(ROM)中的应用程序次序

b.应用程序是否在前台

c.用户操作的最近历史

d.应用程序的相关的被认为的重要性。

12.根据权利要求1所述的方法，其中，至少一个目标设备和/或至少一个控制器设备被选择以包括移动电话。