具体实施方式
在该说明书的范围内,使用概念“连接”、“接通”以及“耦合”既用于说明直接连接也用于说明间接连接、直接或间接接通以及直接或间接耦合。在图中相同或相似的元件具有相同的附图标记,只要这是合理的。
存在可学习的遥控装置,所述遥控装置同时发送IR(红外)信号和RF(无线电)信号。在此,RF(无线电)信号通常含有与IR信号相同的信息,但具有还可通过墙壁发送的优点。RF信号由通常附加设置的交换机设备接收,其中在本方法中,所述交换机设备被安置在至真正要控制的设备的视域内。交换机设备将通过无线电所得到的信息转换成IR信号,并因此控制在视域内的真正要控制的设备。用户因此可以通过如此所装配的遥控装置来控制设备,其中所述用户与所述设备不具有直接视觉接触,因为所述设备例如位于隔壁房间中。
通常,可以使可学习的遥控装置与一个或多个要控制的设备相匹配。这具体意味着,以与要控制的设备相适应的方式来选择由遥控装置要发送的控制指令。
在此,各个控制指令可以存储在遥控装置中。在这种情况下,用户大多通过手动输入描述设备制造商、设备类和/或设备类型的数字代码来通知遥控装置:针对要控制的设备当前应该使用哪组控制指令。
此外可能的是,可以使用原始遥控装置用于将各个控制指令逐步地传输至可学习的遥控装置。然后IR信号由可学习的遥控装置中的IR传感器读取,分配给键,并为了后续使用而相应地被存储。
在有些情况下还利用可学习的遥控装置传送软件程序,借助于所述软件程序可以更使用方便地进行编程。可以通过这种方式略微简化数字代码的手动输入或控制指令的手动传输,其方式是,将可学习的遥控装置例如通过串行接口连接在个人计算机(PC)上,且新的控制指令可以或者从计算机的内部数据库或者从因特网中的外部数据库读出。该方法特别适用于对控制指令的事后更新。
一些遥控装置允许用户独立于遥控装置的状态或独立于要控制的设备的状态而根据自己的想像来用功能占用键,其中在有些情况下还允许对多个指令的链接(对所谓的宏功能编程)。
在可学习的遥控装置中可以使用软键(Softkey)。软键是根据当前应用而用不同的功能所占用的键。名称“软”源于:键的功能并非固定地被预先给定,而是可以动态地被匹配。可学习的遥控装置中的软键的功能占用通常随着遥控装置的状态而改变(通过对菜单结构的选择根据在点击时的进展)。在大多数情况下,给软键分配显示器或至少一个相邻的显示器片段,以便可以向用户显示:相应的软键当前被哪种功能占用。在此大多借助于预定义的显示对象(如表形文字、文本组成部分(以及缩写)、两者的组合等)对功能占用进行显示。
在键和软键的功能占用的情况下,也可以给用户以下可能性,即借助于特定的计算机软件自身设计新的表形文字或者从多个预定义的显示对象中选出确定的表形文字并有针对性地分配给确定的键或确定的宏功能。
对于索尼爱立信(SonyEricsson)的移动无线电终端设备来说,可以使用所谓的HID配置文件。HID是蓝牙应用规范(Anwendungsprofil)的名称并且代表人机接口设备(即人机接口)。利用可具有XML文件和/或图像文件的HID配置文件,可以通知确定的索尼爱立信移动无线电终端设备:不同于本来的键盘占用在按压确定的键时应发出哪些控制命令。通过这种方式可以在一些索尼爱立信移动无线电终端设备中以专有的方式(即通过专有方法)改变键占用一段时间。借助于图像文件可以在所选择的移动无线电终端设备的监视器上将所改变的键占用显示给用户。HID配置文件可以通过通常的方式(例如电子邮件或MMS(多媒体消息业务))被转录到移动无线电终端设备中或者在那里被预先安装。
负责蓝牙技术标准化(Ad-hoc通信网络中的无线电传输技术的实例)的委员会蓝牙SIG除了物理的传输方法和协议层外还定义了应用规范(英文为:“Bluetooth Profiles”),所述应用规范应确保不同制造商的蓝牙设备的协同工作。在这种应用规范中可以定义用于专用应用场合的规则、协议和数据格式。在很多情况下,通过为每个协议层确定必用的协议部分或者为确定的协议层定义应用规范特定的参数,可以将应用规范理解为整个协议层模型的垂直截面。由此确保高度的互操作性。此外用户通过使用应用规范获得如下优点:所述用户不需要手动地使两个或多个终端设备相互协调。最重要的应用规范是通用接入规范(Generic Aecess Profile,GAP),所述通用接入规范具有用于建立通信和用于鉴权的基本功能,其中所有其它应用规范都基于该通用接入规范。
在常规的系统的情况下,在可学习的遥控装置最佳地匹配于要操作的设备之前,在可学习的遥控装置和用户之间高度的交互作用是必需的。因此远程装置的具有平常技术才能的用户通常被苛求。
在手动输入数字代码时还会产生另一问题:经常需要用户按顺序手动输入多个数字代码并逐个地试验所述数字代码,因为即使在相同制造商的设备类内或设备组内,不同的设备也期待不同的数字代码。
只有当可以由HID对方站通知移动无线电终端设备:在按压确定的键时由HID对方站期待哪些HID控制命令,利用HID配置文件的方法才起作用。因此需要不仅移动无线电终端设备而且HID对方站都统一使用相同的HID配置文件,但这在有关的常规设备之间不能被协商。在这种情况下存在功能失误,所述功能失误由于两个设备“各说各的”而引起,因为仅仅有关设备之一(或者发送机方或者接收机方)知道所发送的控制命令的不同分配。
图1示出根据本发明的一个实施例的具有遥控装置102和可遥控的设备104的通信系统100。
根据本发明的一个实施例,遥控装置102可以是借以产生控制信号或控制消息的设备或装置,用于对未安装在同一壳体中的设备、例如可遥控的设备104进行控制、换句话说进行遥控。遥控装置102原则上可以通过每一种任意通信连接(光的、有线的、无线的、基于无线电的、基于声的等)与可遥控的设备104连接。对于下面更详细说明的对本发明的实施出发点是,遥控装置102和可遥控的设备104按照蓝牙无线电通信连接相互连接,且按照该通信标准相互交换数据。
根据本发明的一个实施例,可遥控的设备104可以是通过遥控装置102可被遥控的设备,由此例如可以选择和执行可遥控的设备104的可预先给定的功能,或者例如可以改变可遥控的设备104的操作状态。
根据本发明的一个实施例,如下面还将详细说明的,遥控装置102产生遥控配置文件请求消息106,并将该遥控配置文件请求消息发送至遥控配置文件产生单元,所述遥控配置文件产生单元在本发明的一个实施例中在可遥控的设备104中被实现。利用遥控配置文件请求消息106请求一个或多个遥控配置文件,其中根据本分明的一个实施例,在所述遥控配置文件请求消息中含有遥控装置102的操作特性。
遥控装置102的和可遥控的设备104的上述和下述部件可以以硬件的方式、换句话说借助于一个或多个相应建立的电子电路来实现,或者以软件的方式、换句话说借助于一个或多个相应建立的计算机程序来实现,或者采用任意混合形式、换句话说以硬件或软件的任意部分来实现。
根据对遥控配置文件请求消息106的接收,可遥控的设备104通过设置于其中的下面还将详细说明的遥控配置文件产生单元产生一个或多个遥控配置文件。所述一个或多个遥控配置文件以遥控配置文件应答消息108的方式被发送至遥控装置102。
需要指出,在本发明的一种替代扩展方案中,遥控配置文件产生单元并非设置在可遥控的设备104中。在这种情况下,遥控配置文件请求消息106并非被发送至可遥控的设备104,而是直接被发送至在另一设备中所实现的遥控配置文件产生单元,或者由可遥控的设备104直接转发至该另一设备中,其中在所述另一设备中实现遥控配置文件产生单元。必要时,遥控配置文件请求消息106在传送至另一设备之前仍由可遥控的设备104修改,例如补充可遥控的设备104的识别特征。在这种情况下,遥控配置文件请求消息106的发送可以在第一接口上(例如在遥控装置102和可遥控的设备104之间)以无线的方式以及在第二接口上(例如在可遥控的设备104和其中实现遥控配置文件产生单元的另一设备之间)以有线的方式传输。在本实施例中,遥控配置文件产生单元(例如在使用为一个可遥控的设备或者为多个不同的可遥控的设备分别存储一个或多个配置文件的数据库的情况下)在使用遥控装置102的在遥控配置文件请求消息106中所含有的下面将详细说明的操作特性的情况下确定为在本发明的该实施例中在遥控配置文件请求消息106中所说明的、换句话说所识别的可遥控的设备所设置的遥控配置文件。在这种情况下,所产生的遥控配置文件例如同样以一个或多个遥控配置文件应答消息108被传递至遥控装置102。如果是按照上述说明而由可遥控的设备104所修改的遥控配置文件请求消息106,则遥控配置文件产生单元确定一个或多个与由遥控装置102和可遥控的设备104所组成的设备对相协调的遥控配置文件。
根据对遥控配置文件应答消息108的接收,遥控装置102从遥控配置文件应答消息108中确定一个或多个遥控配置文件,并将所确定的一个遥控配置文件或所确定的多个遥控配置文件存储在存储器中。
此外,遥控装置自动或半自动地(换句话说,在考虑遥控装置102的用户的情况下)至少部分地按照一个或多个所接收的遥控配置文件来配置,如下还要详细描述的那样。
为了对可遥控的设备104进行遥控,遥控装置102产生相应的控制信号和/或具有相应控制指令的控制消息,并将其以一个遥控消息或多个遥控消息110的方式发送至可遥控的设备104。
根据对一个遥控消息110或多个遥控消息110的接收,可遥控的设备104确定控制信号或控制指令,并按照指示来执行所述控制信号或控制指令。
图2示出根据本发明的一个实施例的遥控装置102的部件。
根据本发明的一个实施例,遥控装置102具有天线202、发送器204、接收器206、遥控配置文件请求消息产生单元208以及遥控配置单元210和存储器214。各个部件202、204、206、208、210和214通过单向或双向通信连接、例如通过计算机总线216相互耦合。
遥控配置文件请求消息产生单元208和遥控配置单元210可以被构造成独立的单独的部件。在本发明的一种替代扩展方案中,遥控配置文件请求消息产生单元208和遥控配置单元210通过共同所使用的可编程处理器、例如通过微处理器212以相应所设置的计算机程序流程(可替代地,计算机程序对象)的形式来实现。
发送器204和/或接收器206被设置用于按照相同的或不同的传输技术来发送或接收信号。
例如,发送器204和/或接收器206可以被设置用于按照下述传输技术中的一种或多种来发送/接收信号:
·例如借助红外信号的光传输技术(例如按照IrDA(红外数据协会));
·基于声的传输技术;
·基于无线电的传输技术,例如按照移动无线电传输技术,例如按照基于蜂窝的移动无线电传输技术,例如按照诸如GSM(全球移动通信系统)、3GPP(第三代合作伙伴项目)、例如UMTS(通用移动电信系统)、FOMA(自由移动的多媒体接入)、CDMA 2000(码分多址2000)、EDGE(增强型数据速率GSM演进)、GPRS(通用分组无线电业务)的移动无线电通信标准,例如按照诸如蓝牙无线技术和/或超宽带的近场无线电标准,等等。
在一个实施例中,发送器204被设置用于将遥控配置文件请求消息106发送至遥控配置文件产生单元,例如可遥控的设备104。
在一个实施例中,接收器206被设置用于接收至少一个如下面还将详细说明的遥控配置文件。
在一个实施例中,遥控配置文件请求消息产生单元208如此来设置,使得所述遥控配置文件请求消息产生单元产生遥控配置文件请求消息(例如106),其中遥控配置文件请求消息106含有遥控装置102的操作特性。
在本发明的一个实施例中,遥控装置102的操作特性例如是关于遥控装置102的硬件特征、遥控装置102的软件特征、遥控装置102的用户偏爱
以及遥控装置102的使用历史的信息,尽管在本发明的其它实施例中也可以设置对遥控装置102的操作进行表征的其它特征。
在本发明的一个实施例中,遥控装置102的操作特性含有遥控装置102的至少一个输入单元的特性和/或遥控装置102的至少一个输出单元的特性。
在本发明申请的范围内,输入单元可以包括多个输入元件。在此形成输入单元的输入元件可以是同一类型(例如键区的多个键),或者由不同的类型构成(键和麦克风)。原则上同样也适用于输出单元(例如显示单元的多个像素,或者灯和扬声器的组合)。
在本发明的一个实施例中,遥控装置102的至少一个输入单元的特性含有关于该至少一个输入单元的功能可编程性的信息(例如关于输入单元(例如具有多个键的键区)的输入元件(例如键)在其功能性方面是否可改变、即可编程的信息,必要时带有当前分配给相应输入元件的功能性的说明)、和/或关于至少一个输入单元的定位可编程性的信息(例如关于输入单元内的输入元件可以被定位于哪个位置或者该输入元件当前被布置在哪个位置的信息(例如对于输入元件是接触敏感的像屏上的基于软件的键的情况))。
在本发明的一个实施例中,关于遥控装置的硬件特征的信息含有至少一个下述信息:
·设备识别特征(例如设备的明确标识);
·不可编程的键的数量和位置(例如被固定标记的键的数量和位置);
·可编程的键的数量和位置;
·基于软件的键的数量和位置;
·至少一个显示单元的数量、特性和位置;
·存储器中(例如用于宏功能等)的可用存储空间(换句话说,可用的存储器大小);
·显示单元(例如显示器)或接触敏感的显示单元(例如接触敏感的显示器)的数量、特性和位置。
在本发明的一个实施例中,关于遥控装置102的软件特征的信息含有至少一个下述信息:
·软件识别特征(例如计算机程序的明确标识);
·关于用于显示图像元素(例如表形文字)或文本元素(例如文本组成部分)的由遥控装置102支持的编解码器的信息;
·关于由遥控装置支持的宏功能的信息;
·宏功能的最大允许链接深度。
在本发明的一个实施例中,关于遥控装置的用户偏爱的信息含有至少一个下述信息:
·用户优选使用至少一个输入单元的输入元件(在一个实施例中:用户感觉使用苹果iPod的用于导航的点击轮(Clickwheel)特别简单);
·用户优选使用至少一个输出单元的输出元件(在一个实施例中:用户最喜欢使用制造商LG Electronics的移动无线电电话的菜单导向(或人机接口(Human Machine Interface,HMI));
·用户习惯于制造商Panasonic(松下)的“颜色主题”(颜色图案)。
在一个实施例中,人机接口(HMI)是人机系统中的子系统,利用该子系统,通过用户界面使人机相互作用。为了可由人操作,人机接口特定地匹配于人的需求。通过HMI允许用户操作机器、观察设备状态并且必要时干预过程。例如在硬件技术上通过具有信号灯、扬声器、显示区和键的控制台,或者在软件技术上通过例如在终端上运行的可视化系统来提供信息。
在本发明的一个实施例中,关于遥控装置的使用历史的信息含有至少一个下述信息:
·关于遥控装置的至少一个先前配置的信息(在一个实施例中:后五个键盘占用(配置)已与制造商Yamaha(雅马哈)的HiFi设备协商一致(类型ID=“HiFi设备”,制造商ID=“Yamaha”));
·关于至少一个输入单元的输入元件的使用频率的信息;
·关于至少一个输出单元的输出元件的使用频率的信息(在一个实施例中:无声切换功能(其配属于终止键)自八个月以来就不再被使用)。
在本发明的一个实施例中,遥控装置的至少一个输出单元的特性含有至少一个下述信息:
·关于至少一个输出单元的功能可编程性的信息;
·关于至少一个输出单元的定位可编程性的信息。
上述分类说明了对参数的示例性选择,所述参数可以被考虑用于协商遥控装置102的配置细节(例如键盘占用)。
通过这种方式实现:也可完全以移动无线电终端设备的形式存在的通用遥控装置102的匹配可以在对键的最佳功能占用方面和在对显示器(只要存在)的最佳使用方面完全自动地实施(即在相关的设备之间被协商),并且因此用户和遥控装置之间的相互作用被减到最小。在这种情况下不仅要考虑用作遥控装置102的设备的硬件特性和软件特性(例如键盘布局),而且可选地还要考虑多个“软”准则,如用户关于其它设备、设备类、制造商的经验、熟悉性和偏好等。
此外本发明实施例的作用是:
·遥控装置102与要控制的设备104的匹配完全(可替代地,部分地)自动地实现;
·用于协商功能占用的方法提供完全的灵活性;
·在编程时在遥控装置和用户之间的相互作用可以被减到最小;
·为用户提供最佳地与其特定需求和偏好相匹配的操作装置;
·此外满足蓝牙SIG对其成员在开发新的蓝牙应用规范方面的期望。
在存储器214中存储有下面还将详细说明的例如由遥控配置文件产生单元所传输的遥控配置文件。
遥控配置单元210被设置用于按照至少一个遥控配置文件来配置遥控装置102(例如遥控配置单元210被设置用于对遥控装置102的键(在其功能和/或其定位或布置方面)进行编程)。
图3示出根据本发明的一个实施例的遥控装置102的俯视图。
除了通常的操作元件外(为清楚起见,在本说明书的范围内未对这些操作元件予以详细说明),遥控装置102具有一个或多个显示单元302(例如显示器,例如接触敏感的显示器(触摸屏))以及一个或多个扬声器304作为输出单元。
此外,遥控装置102具有带有多个数字键(例如数字键“0”、“1”、...、“9”)和/或一个或多个控制键(给其例如分配有(固定的或可变的)预先给定的功能)的键区306和一个或多个麦克风308作为输入单元。
图4示出根据本发明的一个实施例的可遥控的设备104的部件。
根据本发明的一个实施例,可遥控的设备104具有天线402以及遥控配置文件产生单元404。
在本发明的一个实施例中,遥控配置文件产生单元404具有:
·用于接收至少一个遥控配置文件请求消息的接收器408,其中遥控配置文件请求消息含有遥控装置的操作特性;
·用于在考虑所接收的遥控装置的操作特性的情况下产生遥控配置文件的遥控配置文件产生器410;
·用于将遥控配置文件发送至遥控装置的发送器406。
接收器408、发送器406和遥控配置文件产生器410通过单向的或双向的通信连接、例如通过计算机总线412相互耦合。
发送器406和/或接收器408被设置用于按照相同的或不同的传输技术发送或接收信号。发送器406和/或接收器408例如可以被设置用于按照下述传输技术中的一个或多个来发送/接收信号:
·例如借助红外信号的光传输技术(例如按照IrDA(红外数据协会));
·基于声的传输技术;
·基于无线电的传输技术,例如按照移动无线电传输技术,例如按照基于蜂窝的移动无线电传输技术,例如按照诸如GSM(全球移动通信系统)、3GPP(第三代合作伙伴项目)、例如UMTS(通用移动电信系统)、FOMA(自由移动的多媒体接入)、CDMA 2000(码分多址2000)、EDGE(增强型数据速率GSM演进)、GPRS(通用分组无线电业务)的移动无线电通信标准,例如按照诸如蓝牙无线技术和/或超宽带技术的近场无线电标准,等等。
在本发明的一个实施例中,遥控配置文件含有用于配置遥控装置102的指令和/或结构信息。遥控配置文件可以以预先给定的专有格式来设置;但在一个替代实施形式中,所述遥控配置文件也可以以标准化格式存在。
在本发明的一个实施例中,遥控配置文件以如下格式之一被编码:
·可扩展标记语言(XML);
·超文本标记语言(HTML);
·Java计算机程序代码。
此外,可遥控的设备104具有控制单元414用于执行控制指令,所述控制指令可以在本地由可遥控的设备104的用户输入(例如通过可遥控的设备104的下述输入单元)或者由遥控装置102传递至可遥控的设备104。控制单元414控制执行元件和/或传感器,所述执行元件和/或传感器同样设置在可遥控的设备104中用于执行所希望的(必要时通过遥控装置102所输入的)功能。执行元件通常由于英文术语“actuator”也被称为致动器。所述执行元件在控制和调节技术中称为零件(Gegenstück)。
图5示出根据本发明的一个实施例的可遥控的设备104的俯视图。
除了通常的操作元件外(为简明起见,在本说明书的范围内未对这些操作元件予以详细说明),可遥控的设备104具有一个或多个显示单元502(例如显示器,如接触敏感的显示器(触摸屏))以及一个或多个扬声器504作为输出单元。
此外,可遥控的设备104具有带有多个数字键(例如数字键“0”、“1”、...、“9”)和/或一个或多个控制键(给其例如分配有(固定的或可变的)预先给定的功能)的键区506和一个或多个麦克风508作为输入单元。
图6示出流程图600,其中示出了根据本发明的一个实施例的用于确定遥控装置的配置的方法。
在602中产生遥控配置文件请求消息106,其中遥控配置文件请求消息106含有遥控装置102的操作特性。
在604中,将遥控配置文件请求消息106从遥控装置102的发送器204发送至(例如包含在可遥控的设备104中的)遥控配置文件产生单元404。
在606中,至少一个遥控配置文件由遥控装置102的接收器206接收(例如由遥控配置文件产生单元404发送)。
在608中,遥控装置按照至少一个遥控配置文件(例如由遥控配置单元210)来配置。
图7示出流程图700,其中示出了根据本发明的一个实施例的用于产生遥控配置文件的方法。
在702中接收至少一个遥控配置文件请求消息106,其中遥控配置文件请求消息106含有遥控装置102的操作特性。
在704中,在考虑所接收的遥控装置102的操作特性的情况下(例如通过遥控配置文件产生器410)产生遥控配置文件。
在706中,将遥控配置文件(例如以遥控配置文件应答消息108的形式)发送至遥控装置102。
图8示出流程图800,其中示出了根据本发明的一个实施例的用于对可遥控的设备104进行遥控的方法。
在602中产生遥控配置文件请求消息106,其中遥控配置文件请求消息106含有遥控装置102的操作特性。
在604中,遥控配置文件请求消息106由遥控装置102的发送器204发送至(例如包含在可遥控的设备104中的)遥控配置文件产生单元404。
在606中,至少一个遥控配置文件由遥控装置102的接收器206接收(例如被遥控配置文件产生单元404发送)。
在608中,遥控装置按照至少一个遥控配置文件(例如由遥控配置单元210)来配置。
在802中,在使用所配置的遥控装置102的情况下对可遥控的设备104进行遥控。
图9示出消息流图900(事务图),其中示出了根据本发明的一个实施例的用于配置遥控装置102和用于对可遥控的设备104进行遥控的消息流。
在消息流图900的左侧示出了要控制的实体(Instanz)I、例如可遥控的设备104,在消息流图900的右侧示出了遥控装置(远程控制单元,RCU)102。对于在遥控装置RCU 102和用户之间的可选的相互作用,在图9中甚至在右方侧还示出了使用者(换句话说用户)902。在遥控装置102和用户902之间的相互作用通过相应的双箭头904、906示出(参见图9中的916和924)。
如图9中所示,根据本发明的一个实施例的方法具有三个阶段用于交换遥控特定的信息,例如初始化阶段958、协商阶段930和控制阶段932。
在遥控装置102和要控制的实体I(例如104)之间的接口934通过具有标签“L”的虚线来表示;该接口可以被设计为例如按照近区无线电传输技术标准(例如按照Ad-hoc通信网络标准)的空中接口。通过所述接口在遥控装置RCU 102和实体I(例如104)之间所交换的消息表示为细箭头并通过936、938、940、942标出。
在不限制一般性的情况下需要指出,如果多个要控制的实体(例如实体I1 1004、I2 1006、...、In 1008)处于同一设备D 1002上(例如见图10中的装置1000),且在设备D 1002和遥控装置102之间只有唯一的接口L 934,则也可以应用根据本发明的一个实施例的方法,其中借助于所述接口可以通过遥控装置102的天线202和通过设备D 1002的天线1010交换无线电信号。因此例如不同的个人计算机应用程序可以为其分别不同的目的而通过近区无线电传输技术蓝牙(Bluetooth)配置相同的遥控装置102。
在本发明的一个实施例中,图9的方法可以被分成三个阶段。
初始化阶段928具有下面将详细说明的过程908、910、912、914、916。
在908中,遥控装置RCU 102例如确定关于其键/导航摇杆的种类、数量、位置和标签、其软键的数量和位置、其显示器的特性和位置、触摸屏的能力和位置等的信息。附加地还可以确定用户902的偏好和经验,以及关于时间上已过去的配置过程的信息和关于用户902的使用行为的信息。这些信息的一部分例如可以从本地数据存储器中(例如从存储器214中)读出,另一部分可能新近被确定。对于这些信息中的一些来说(例如对于静态的硬件信息和/或软件信息来说),在有些情况下确定识别特征就足够了,而非各个细节。例如使用在两侧(即遥控装置102和可遥控的设备104)都已知的、遥控装置102的设备ID允许在对方站(例如可遥控的设备104)中将各个细节分配给所使用的遥控装置102,并此外还节省了带宽。
在910中,遥控装置RCU 102将初始化消息936与在908中所确定的信息一起发送给要控制的实体I(例如104),只要所述信息被考虑用于当前的协商过程。
在912中,应在以后接收和执行遥控装置RCU 102的控制命令的实体I(例如104)首先分析初始化消息936。实体I(例如104)基于其中所含有的参数,从上述四类别、即硬件特征和/或软件特征和/或用户偏爱和/或使用历史计算第一配置文件C,并为了以配置建议消息938的形式(例如以遥控配置文件应答消息108的形式)发送回而对其进行处理。在此,如果配置文件C具有分级结构,以便或者用户902(手动地)或者遥控装置RCU 102(自动地)可以根据使用场合接受配置建议的部分并拒绝配置建议的其它部分,则是有利的。对此下面还将在详细化的实施例中进一步予以更精确的探讨。在一个实施例中,配置文件C可以具有至少一个下述消息:即所述消息从实体I(例如104)的角度看(基于在初始化消息936中所传输的信息和/或识别特征)允许遥控装置RCU 102的最佳键盘占用。
在914中,实体I(例如104)将含有第一配置文件C的配置建议消息938发送回遥控装置RCU 102。第一配置文件C的分级结构既可以实现用于遥控装置RCU 102的补充配置建议的说明,又可以实现替代配置建议的说明。
在遥控装置RCU 102中,从第一配置建议消息938中所得到的第一配置建议(例如以第一配置文件C的形式)或者自动地或者在与用户902相互作用之后被分析。
这在916中示出。在此,根据本发明的一个实施例规定,实体I(例如104)将鉴权特征集成到第一配置建议消息938中,借助所述鉴权特征,遥控装置RCU 102可以毫无疑义地检查实体I(例如104)的类、制造商和/或类型。由于第一配置文件C的分级结构,遥控装置RCU 102可以完全或部分地接受或拒绝第一配置建议。
根据本发明的一个实施例,利用鉴权(英文为authentication)来表示对对方(例如人员或计算机程序,这里:第一配置建议消息938或下面还将详细说明的第二配置建议消息942的发起者)的身份的检查过程。
协商阶段930具有下面将详细说明的过程918、920、922、924。
在918中,遥控装置RCU 102将对先前所接收的第一配置建议消息938的应答消息940发送回实体I(例如104)。通过该应答消息940可以将遥控装置RCU102就第一配置文件C的被接受的或被拒绝的部分作出的决定通知给实体I(例如104)。
根据本发明的一个实施例规定,应答消息940还含有如下消息:在遥控装置RCU 102侧是否希望或需要继续对配置细节进行协商。
在920中,要控制的实体I(例如104)分析应答消息940,并在必要时提出新的配置建议,即例如第二配置文件C*。这里还根据一个实施例规定,第二配置文件C*具有分级结构,以便或者用户902(手动地)或者遥控装置RCU102(自动地)可以在以后根据应用场合接受或拒绝所述第二配置建议的部分。
在922中,实体I(例如104)重新将配置建议消息、例如含有第二配置文件C*的第二配置建议消息942发送回遥控装置RCU 102,旨在继续对配置细节、特别是键盘占用进行协商。这里也可以通过第二配置文件C*的分级结构来说明对遥控装置RCU 102的补充的或替代的配置建议。
类似于在916中的实施,遥控装置RCU 102在924中从第二配置建议消息942中得到第二配置文件C*并对其进行分析。对新的配置建议的使用/激活可以或者由遥控装置RCU 102自动地或者在与用户902相互作用之后被引起(视应用场合而定)。这里再次认为:第二配置建议消息942或第二配置文件C*含有鉴权特征,该鉴权特征已被实体I(例如104)集成,且借助该鉴权特征,遥控装置RCU 102可以毫无疑义地检查实体I(例如104)的类、制造商和/或类型。如果第二配置建议也完全或部分地未被接受,则根据本发明的一个实施例可以重新协商。
在这种情况下将会重新运行过程918、920、922、924,而且直至遥控装置RCU 102自动地或者用户902在与新的配置建议手动地相互作用之后最终同意所接收的配置建议消息,且遥控装置RCU 102按照上述边界条件(硬件特征、软件特征、用户偏爱和/或使用历史)最佳地匹配于实体I(例如104)为止。根据本发明的一个实施例规定,将两侧的运行的数量计算在内,且在超过先前所定义的阈值时不再允许进一步的迭代(iteration)并结束协商。
如果配置建议被接受,则遥控装置RCU 102最佳地被配置用以控制实体I(例如104),也就是说,例如在考虑到由四类别、即硬件特征、软件特征、用户偏爱和/或使用历史组成的边界条件的情况下进行对各个键的占用以及(例如结合软键)对显示器的使用。
控制阶段932具有下面将详细说明的过程926。
现在在926中,遥控装置RCU 102将控制命令发送至实体I(例如104)。这在图9中通过CC(控制命令)类型的消息944、946示出。实体I(例如104)又可以(可选地)对由遥控装置RCU 102所发出的控制命令的无误接收进行确认(例如通过图9中点划线所示的消息948、950)。
在事务图900的继续进程中,可以根据应用场合利用已有的技术对控制命令CC和可选的确认消息进行交换:
·遥控装置RCU 102发送IR信号,且不等待确认消息;
·遥控装置RCU 102发送RF信号,且等待实体I(例如104)的确认消息。在传输误差或有未识别的语法的情况下,可以通过确认消息中的误差码促使实体I(例如104)重新发送RF信号形式的控制命令CC;
·遥控装置RCU 102利用特定的蓝牙应用规范、例如AVRCP(音频/视频远程控制规范)或HID(人机接口设备)规范以通常的方式来控制实体I(例如104)。
用于交换为配置遥控装置102(初始化阶段928和协商阶段930)所可以考虑的信息的所述方法原则上可以在每一网络中(例如在每一通信网络中)被实现。在一个实施例中,规定这里所公开的方法在无线Ad-hoc通信网络中使用,所述无线Ad-hoc通信网络例如按照蓝牙通信标准被设计成单独的蓝牙应用规范。
下面说明一个实施例,在所述实施例中为了对车库门T1远程控制而匹配遥控装置RCU1 1100(见图11)。
在该实施例中将说明用新的功能对键的简单占用。
为此作出如下假定:
·遥控装置和车库门T1通过RF信号(无线电)相互通信;
·车库门T1提供如下可远程控制的功能性:
-门开;
-停止;
-门关。
·根据图11,遥控装置RCU1 1100具有天线1102以及三个带标签的键1104、1106、1108。
如果遥控装置RCU1 1100第一次进入车库门T1(例如可遥控的设备104)的控制单元的有效范围中,则遥控装置RCU1 1100以上述初始化消息936的形式将其“能力”通知给车库门T1的控制单元,该初始化消息936例如按照下表1来建立:
信息元素 |
存在 |
说明 |
消息类型 |
必用的 |
将该消息识别为初始化消息936 |
事务特征 |
必用的 |
表示消息对的相关性 |
版本标号 |
必用的 |
表明所使用的协议的版本号 |
接收实体ID |
可选的 |
被编址的实体的识别特征 |
发送实体ID |
可选的 |
发送实体的识别特征 |
配置ID |
可选的 |
已存储在遥控装置RCU1 1100中的配置文件的识别特征 |
发明有关的特征 |
必用的 |
关于硬件特征和/或软件特征和/或用户偏爱和/或硬件使用历史的细节信息。例如以XML文档的形式。 |
表1:根据本发明的一个实施例的
初始化消息936中的信息元素
具体而言,初始化消息936可以在使用这里未详细说明的文档类型定义(DTD)的情况下在XML编码中使用关于硬件特征和/或软件特征和/或用户偏爱和/或使用历史的各个信息。
表2和3示出根据实施例的两种可能的实施方案。
首先观察表2,在该表中只包含产品识别特征和对因特网中存储空间的参考(Referenz),其中从所述存储空间可动用其它信息用于下载。在这种情况下,接收初始化消息936的实体I(例如104)(这里为:车库门T1的控制单元)的任务是,确定遥控装置1100的所有所需要的特征,特别是多数静态的硬件特征和软件特征,并基于该受限的信息组产生配置建议C。为了确定硬件特征和软件特征,必要时从实体I(例如104)建立至例如因特网中的外部数据库的连接(例如图9中的912)。关于用户偏爱和/或关于遥控装置1100的使用历史的信息的信息(其全部多数是动态特性)不能通过表2中所示的XML文档被传输至设备D(例如104)。
表2:用于将对遥控装置特征的参考传递
至实体I的XML文档的示例性结构。
表3示出具有可实现这一点的另一构造结构的替代XML文档。
利用表3中示例性示出的XML文档可以针对每个有关的特征将细节通知给实体I(例如104)。
在本实例中,这是:
硬件特征:
遥控装置RCU1(参见图11)具有三个带标签的键;第一键1104的标签为“向上的箭头”,第二键1106的标签为“方块”,第三键1108的标签为“向下的箭头”;没有软键;没有显示器。
软件特征:
遥控装置RCU1 1100不支持对宏功能的编程。
用户偏爱:
用户902希望,应尽可能简单地进行对其遥控装置RCU1 1100的配置。
使用历史:
遥控装置RCU1 1100最终与公司“company_xyz”的产品ID为“002.608.197.409.041.975”的视频记录器“VCR”相协调。
表3:用于全面地将遥控装置特征传递至实体I
的XML文档的示例性替代结构。
与表2不同,利用这种详细的XML文档可以将明显更多的关于有关特征的信息通知给实体I(例如104)(这里为:车库门T1的控制单元),使得车库门T1的控制单元在这种情况下不必必须建立至例如因特网中的外部数据库的连接,而是可以直接计算配置建议(例如图9中的过程912)。
除了在表2和3中示出的示例性XML文档外,当然也可以使用混合形式以及具有其它、也即与XML不同的编码的变型方案,用以向要控制的实体I(例如104)通知遥控装置RCU1 1100的有关特征。
根据图9,现在在914中,具有与遥控装置RCU1 1100的有关特征相协调的第一配置文件C的第一配置建议消息938从车库门T1的控制单元被发送回遥控装置RCU1 1100。
第一配置建议消息938例如可以按照表4来建立:
信息元素 |
存在 |
说明 |
消息类型 |
必用的 |
将该消息识别为配置建议消息938 |
事务特征 |
必用的 |
表示消息对的相关性 |
版本标号 |
必用的 |
表明所使用的协议的版本号 |
接收实体ID |
可选的 |
被编址的实体的识别特征 |
发送实体ID |
可选的 |
发送实体的识别特征 |
迭代数 |
可选的 |
在每一轮中可被递增的计数器(在初始化阶段=0,在协商阶段>0)。 |
配置ID |
可选的 |
已存储在遥控装置RCU中的配置文件的识别特征 |
配置指令 |
可选的 |
利用该信息元素可以向遥控装置RCU表明,利用已存储的配置文件将发生什么:例如清除、补充、改写等。 |
配置建议 |
必用的 |
配置文件C。例如XML文件的形式。 |
表4:在配置建议消息938、942中可能的信息元素。
在表5中示出了根据本发明的一个实施例的第一配置文件C的结构。
表5:用于配置文件C的XML文档的示例性结构。
在第一配置建议消息938中,在使用这里未详细说明的文档类型定义(DTD)的情况下在XML编码中可以使用配置建议。
表5示出了根据本发明的一个实施例的可能的实施方案。
在第一段“硬件”中,按顺序列出了用于新的键功能的三个改变命令。原则上有两种占用键的可能性。两者在表5中示出并且区别在于关键字<new_command>(在键T1和T3的情况下)和<new_key_id>(在键T2的情况下)。
在第一情况<new_command>下,十六进制值“0x20”在按压第一键1104时直接作为新的控制代码被发出(或者“0x21”在按压第三键1108时被发出)。
在第二种情况<new_key_id>下,十六进制值“0x15”用作在ID“0x15”下存储在遥控装置RCU1 1100中的控制代码的参考,所述控制代码在每次按压第二键1106时应代替最初在那里所设置的控制代码而被发出。
使用表述<new_command>的优点在于,遥控装置RCU1 1100不必在内部存储器中存储有适当的控制代码,而使用表述<new_key_id>引起:在遥控装置RCU1 1100的内部存储器中针对每个键识别号(key_id)都应存储有相应的控制代码,并且两个设备(不仅实体I(例如104)而且遥控装置RCU1 1100)都必需具有关于当前相应的分配表的知识。
在该实例中,遥控装置RCU1 1100按照过程916在没有进一步协商(参见图9的过程918、920、922、924)的情况下从第一配置建议消息938接受配置建议。
现在可以切换到控制过程932中。
下面说明另一实施例,其中匹配遥控装置RCU1 1100用于对车库门T2进行远程控制。
在该实例中将详细探讨对遥控功能的协商。
为此作出如下假定:
·遥控装置和车库门T2通过RF信号(无线电)相互通信;
·车库门T2提供如下可远程控制的功能性:
-门开;
-停止;
-门关;
-照明接通;
-照明关断。
遥控装置RCU1 1100具有根据图11的三个带标签的键1104、1106、1108。
过程908、910、912可以类似于上述实例中的实施方案来进行。
此次认为,初始化消息936不含有关于键1104、1106、1108的标签的详细化说明,而是仅仅包含信息“有三个键”。
因为车库门T2的控制单元现在可以实现比在车库门T1的情况下更多的功能(现在:五个,此前只有三个),所以将具有其它内容的第一配置建议消息938发送回遥控装置RCU1 1100。
为此表6再次在使用这里未详细说明的文档类型定义(DTD)的情况下示出XML编码。
在第一段(通过具有序数“0”的关键字<alternative>来开启和结束)中,按顺序列出由实体I(例如104)(即由车库门T2的控制单元)所确定的所希望的用于占用键的三个改变命令。不同于上述实例,这里为更好的一目了然性仅说明对关键字<new_key_id>的使用。
在第二段(通过带有序数“1”的关键字<alternative>来开启和结束)中,给遥控装置RCU1 1100提供配置替代方案:不是用新的控制命令0x20(门开)占用第一键1104,用0x21(门关)占用第三键1108,而是为遥控装置RCU1 1100提供:用新的控制命令0x1B(灯开)占用第一键1104,用0x1C(灯关)占用第三键1108。第二键1106的功能占用(停止)保持未受影响;不为该功能占用提供替代方案。
也可以设想,在第二段中所定义的替代方案中,代替关键字<new_key_id>分别使用关键字<new_command>。
也可以在XML文档内说明其它不同的替代方案。实体I(例如104)(这里:车库门T2的控制单元)可以通过在XML结构中相应段的顺序或者通过编号(在使用序数的情况下)来表述替代方案(一种优选列表)的由其所计算的顺序。
表6中的实例示出在所使用的关键字<alternative>内的编号。也可以设想与此不同的其它编码。
表6:具有两种配置替代方案的用于配置
文件C的XML文档的示例性结构。
作为对根据表6含有配置文件C的第一配置建议消息938的接收的反应,遥控装置RCU1 1100现在应按照针对916的实施方案或者以自动化的方式或者通过向用户902的询问作出决定。在本实例中,遥控装置RCU1 1100由于其结构方式不可能与用户902相互作用,因为所述遥控装置没有显示器、没有扬声器等。因此在本实例中基于操作历史作出决定,并且遥控装置RCU1 1100决定接受在表6的XML文档的第一段中所含有的主建议(<alternative=“0”>)。
然而在本实例中遥控装置RCU1 1100不具有分配表,如所述分配表对于借助于关键字<new_key_id>的具体功能占用是前提条件。
假定遥控装置RCU1 1100在本实例中要求类型<new_command>的关键字。因此遥控装置RCU1 1100现在应开始根据图9的协商阶段930(参见过程918、920、922、924)并将该实际情况通知给实体I(例如104)。为此应答消息940由遥控装置RCU1 1100发送至车库门T2的控制单元(“实体I”)。该应答消息940例如可以按照表7来建立。
信息元素 |
存在 |
说明 |
消息类型 |
必用的 |
将该消息识别为应答消息940 |
事务特征 |
必用的 |
表示消息对的相关性 |
版本标号 |
必用的 |
表明所使用的协议的版本号 |
接收实体ID |
可选的 |
被编址的实体的识别特征 |
发送实体ID |
可选的 |
发送实体的识别特征 |
迭代数 |
可选的 |
在每一轮中可能递增的计数器(在初始化阶段=0,在协商阶段>0) |
协商标记 |
可选的 |
包含所述应答消息所涉及的先前所发送的配置建议消息的识别特征 |
协商建议 |
必用的 |
协商文件N。例如XML文档的形式。 |
表7:应答消息940中的可能的信息元素
表8示出在应答消息940中所含有的XML文档形式的协商文件N的可能结构。
表8:协商文件N的示例性结构
根据对920的实施方案,实体I(例如104)分析应答消息940,并产生新的配置建议、即第二配置文件C*,其中考虑到遥控装置希望交换两个功能占用替代方案(在<alternative=“0”>中通过<new_command>代替<new_key_id>)。
结果在表9中示出。现在通过改变关键字,在关键字之后的值也不同于上述XML文档中的值(表6)。
表9:示例性配置文件C*
在此情况下不再涉及对存放在分配表中的控制命令的参照,而是直接涉及应由遥控装置RCU1 1100使用的控制代码。
在922中,实体I将第二配置建议消息942(但其现在含有第二配置文件C*)发送回遥控装置RCU1 1100用以继续协商配置细节。遥控装置RCU1 1100分析在第二配置建议消息942中所含有的第二配置文件C*。
因为实体I在本实例中已完全接受遥控装置RCU1 1100的改变建议,所以在924中该实体I在无进一步重新协商的情况下接受第二配置建议。
现在可以切换到控制阶段中。
下面还将说明另一个实施例,其中另一遥控装置RCU2 1200(见图12)被匹配用于对车库门T2进行远程控制。
为此作出如下假定:
·遥控装置1200和车库门T2通过RF信号(无线电)相互通信;
·车库门T2提供如下可远程控制的功能性:
-门开;
-停止;
-门关;
-照明接通;
-照明关断。
·根据图12,遥控装置RCU2 1200配备有:天线1202;三个带标签的键1204、1206、1208;两个软键1210、1212和小显示器1214(例如用于显示750*250个像点)。在显示器1214上设有用于显示文本和/或表形文字的两个区域1216、1218,以便在侧上为两个软键1210、1212设置标签(beschriften)。作为替代方案,代替两个软键1210、1212和显示器1214也可以设置触摸屏(即接触敏感的显示器),该触摸屏将两个软键1210、1212和显示器1214的功能集于一身。
如果遥控装置RCU2 1200第一次进入车库门T2的控制单元的作用范围中,则遥控装置RCU2 1200以上面详细说明的初始化消息936的形式将其“能力”通知给车库门T2的控制单元。
这里初始化消息936同样在使用这里未详细说明的文档类型定义(DTD)的情况下在XML编码中也含有关于硬件特征和/或软件特征和/或用户偏爱和/或使用历史的全部细节。
表10示出这种示例性的XML文档:
表10:用于全面地将遥控装置特征传递
至实体I的XML文档的示例性结构
硬件特征:
遥控装置RCU2 1200(参见图12)具有三个带标签的键1204、1206、1208。第一键1204的标签为“向上的箭头”,第二键1206的标签为“方块”,第三键1208的标签为“向下的箭头”。存在两个软键1210、1212和小的显示器1214,该显示器具有可以两个区域1216、1218,所述两个区域可被考虑用于为软键设置标签(或者替代地:存在带有两个可配置的区域的触摸屏)。
软件特征:
遥控装置RCU2 1200支持对链接深度为最大三个功能的宏功能的编程。
用户偏爱:
用户902希望,应尽可能使其遥控装置RCU2 1200的配置匹配于其mp3播放器(例如“Pear”公司的“e-Pal”模型)的HMI(HMI-HumanMachine Interface,人机接口),其中用户非常熟悉对mp3播放器的操作。用户例如可以在其遥控装置RCU2 1200首次投入工作时例如借助于显示器1214和三个带标签的键1204、1206、1208和/或两个软键1210、1212(或者替代地:借助于触摸屏)通过菜单从存储在遥控装置RCU21200中的数据组中已选出这些设定。
使用历史:
在本实例中,为更好的一目了然性省去有关的信息。
根据图9,现在在914中,按照表4的具有与遥控装置RCU2 1200的有关特征相协调的第一配置文件C的第一配置建议消息938从车库门T2的控制单元被发送回遥控装置RCU2 1200。
表11示出用于在使用这里未详细说明的文档类型定义(DTD)的情况下在XML编码中的配置建议的可能实施方式。
在第一(在本实例中唯一的)段“硬件”中,按顺序用新的功能(即新的控制代码)占用带标签的键1204、1206、1208。然后针对两个软键1210、1212说明新的控制代码和由实体I所希望的标签。
接下来还有两个其它的参数,借助于所述参数,实体I接受用户在“看和感觉(look and feel)”方面的需求。为了创建类似于其mp3播放器的用户所熟悉的HMI(人机接口),应对像屏的背景照明和文字的颜色相应匹配。
在本实例中仅仅使用关键字<new_command>,所述关键字表明:十六进制值“0x32”应在按压第一键1204时直接作为新的控制代码被发出(“0x33”在按压第二键1206时被发出,等等)。为了更好的一目了然性,这里不使用另一关键字<new_key_id>,其中借助该另一关键字可以参考存储在遥控装置RCU2 1200中的控制代码,该控制代码应代替最初在那里所设置的控制代码在每次按压相应的键时被发出。
但原则上在本实例中混合形式也是可能的,且必要时可能完全有意义。
根据上述实施方案,遥控装置RCU2 1200在916中在没有进一步协商的情况下、即在本实例中不运行图9的过程918、920、922、924,从配置建议消息938中例如接受配置建议C。
表11:用于配置文件C的XML文档的示例性结构
如果遥控装置RCU 102能够将一个或多个配置文件C存储一段时间间隔,所述时间间隔明显长于实体I的实际控制时间间隔,则也可能的是,在初始化消息936中含有该已经存储的配置文件C的识别特征(表1中的信息元素“配置ID”表示该识别特征)。
在下次建立连接时,实体I可以借助于这种识别特征来检查,在本发明准则方面可用的配置文件C是否已存储在遥控装置RCU 102中。因此在初始化消息936之后的第一配置建议消息938不必强制地含有配置文件C形式的完整的配置建议,而是也可以包含配置文件R的参考(Referenz)形式的配置建议。由此有时可以节省带宽。
如果在实体I中的检查应得出,存储在遥控装置RCU 102中的配置文件C不再是当前的,或者与在准则方面遥控装置RCU 102的当前要求不相对应,则在第一配置建议消息938中也只可以将配置细节的δ(即偏差)传输至遥控装置102。
为此在第一配置建议消息938(表2)中存在两个信息元素:配置ID和配置指令。
然而此处不对细节予以进一步探讨,因为用于δ的例如XML文档形式的编码可能性趋向于无穷尽。
表12含有本说明书中常用的缩写的列表。
缩写 |
德文概念 |
英文概念 |
D |
设备 |
Device |
I |
实体 |
Instance |
RCU |
遥控装置 |
Remote Control Unit |
HMI |
人机接口 |
Human Machine Interface |
C |
配置文件 |
Configuration Data |
R |
对配置文件的参考 |
Reference to Configuration Data |
N |
协商文件 |
Negotiation Data |
CC |
控制指令 |
Control Command |
表12:缩写列表
在本发明的一个实施例中提出一种用于在遥控装置和利用该遥控装置可控制的实体之间自动交换遥控装置特定的信息的方法。
在此遥控功能性的细节例如在特别考虑硬件特征、软件能力和众多的“软”准则(如用户在其它设备(类)、操作概念和使用历史等方面的经验、熟悉性和偏好)的情况下在两个相关的设备之间被协商。
所产生的配置文件被遥控装置例如用于用相应的功能占用键、软键和显示器(区域)、导航摇杆、宏存储器、触摸屏(区域)等。
所述方法例如可以被用在无线Ad-hoc通信网络中。如果所选择的近无线电传输技术是蓝牙微微网(Piconetzwerk),那么这里所提出的方法可以实现为单独的蓝牙应用规范。
尽管首先已结合特定的实施例示出和说明了本发明,但熟悉本领域的技术人员应该理解,在不偏离本发明的如由下面的权利要求书所限定的本质和范围的情况下,可以对本发明的扩展方案和细节进行多种改变。因此本发明的范围由所附的权利要求书确定,且意图在于,处于权利要求书的含义其等效范围的有效范围内的全部改变都被权利要求书包括。