在CPE和配套设备之间进行共享的制作方法

本发明一般涉及用于在用户预置装置(CPE)设备与在配套设备上运行的软件之间共享应用和授权上下文的系统和方法。

背景技术：

通常，包括用户预置装置(CPE)的IP使能设备需要授权证书来从资源提供商访问资源。诸如和等服务需要用户的证书才能访问这些资源。客户端应用通常以“访问_令牌”的形式缓存授权，因此，每当用户希望从资源提供商的网站访问资源时，用户不需要输入登录ID和密码。

附图说明

本发明从结合附图的以下详细描述中将被更全面的理解和认识，在附图中：

图1A和1B是用于在用户预置装置(CPE)设备和配套设备之间共享应用和授权上下文的系统的用户的简化图示，该系统根据本发明的实施例构造和操作；

图1C是描绘图1A中使用的系统的高级视图的框图；

图2是描述可以使用图1C的系统的简化用例集的用例图；

图3是图1C的系统的CPE设备的框图图示；

图4是示出在图1C的系统中使用的配套设备授权序列的数据流程图；

图5是示出在图1C的系统中用于共享应用上下文的方法的数据流程图；

图6是示出在图1C的系统中用于在与单个CPE设备通信的两个配套设备之间切换应用上下文的方法的数据流程图；

图7是示出对图5中所描述的用于共享应用上下文的方法的替代方法的数据流程图；

图8是示出对图5中所描述的用于共享应用上下文的方法的第二替代方法的数据流程图；

图9是本文描述的一个实施例的操作方法的流程图。

具体实施方式

概述

一种用于配套设备与用户预置装置(CPE)设备共享应用上下文和授权上下文的方法和系统，该方法和系统包括：由搜索请求发送器使用服务发现协议来发送搜索请求，从CPE设备接收对搜索请求的响应，在授权上下文创建处理器处创建授权上下文，该授权上下文包括授权对资源的访问的元数据，由授权上下文发送器向驻留于CPE设备上的应用发送授权上下文，在驻留于CPE上的应用和设备应用之间建立信任会话，由设备应用建立会话包括：从CPE请求数字证书，从CPE接收数字证书，以及验证数字证书，在应用上下文数据创建处理器处创建应用上下文数据，以及将所创建的应用上下文数据发送到CPE设备，其中应用上下文数据使CPE设备能够请求从资源提供商访问授权的资源。还描述了相关方法、系统和装置。

示例实施例

现在参考图1A和1B，图1A和1B是用于在用户预置装置(CPE)150设备和配套设备之间共享应用和授权上下文的系统的用户的简化图示，该系统根据本发明的实施例构造和操作。用户110正在使用配套设备120来观看内容项130。应当理解，内容项可以包括游戏、视频剪辑或电影、流送

音频或视频、音频文件、网站或任何其他适当的可以在配套设备120上观看的内容项，如本领域中已知的。配套设备120可以是任何合适的计算设备，例如智能手机、平板电脑、膝上型计算机或个人计算机等。

如上所述，通常的做法是在CPE 150监视器上呈现虚拟键盘和密码屏幕，并让用户通过虚拟键盘输入细节。这里有几个公认的问题：

如果CPE 150安装在公共场所，则当在CPE监视器上输入密码时，用户ID和密码可能被泄露。

如果用户必须按几个导航键以选择字符，则用户ID和密码的输入可能是复杂的。

用户需要在每个设备(即，每个配套设备120和CPE 150)上单独登录，并且不存在单个或统一登录的概念，即，如果用户已经登录到或在配套设备上的类似资源提供商服务，用户仍然需要通过提供用户ID和密码来单独登录CPE 150设备。例如，如果用户登录以在手持设备上从资源提供商访问资源，则用户将需要单独地再次通过CPE150设备上的认证和授权序列。也就是说，CPE 150需要在设备上对用户进行独立授权，其不同于在配套设备上对用户的授权。此外，本文描述的系统提供了通过单个认证序列来统一在该配套设备和至少一个其他配套设备上的资源授权许可的方式。

来自用户各自的配套设备的多个用户通常不能在家庭内网络中的CPE 150设备上快速执行用户上下文切换。例如，第一人可以登录CPE 150并访问她的资源，而第二人想要登录和切换上下文以访问他的资源。在当前实现中，第一人需要注销，然后第二人需要再次提供他的证书(用户ID和密码)。

在图1A的描述中，用户110正在观看在配套设备120上运行的适当应用140(见下文，参照图1B)上的网站TVmovie.com上的电影。例如，并且不限制前述的一般性，应用140可以包括web浏览器、专用媒体播放应用或与资源提供商直接通信的专用应用。应用140还可以包括操作系统服务或者支持硬件的服务。这样的应用的示例将包括但不限于使用来自服务的资源、来自服务的资源、来自暇务的资源等的应用140，如众所周知的。

在该特定情况下，CPE 150设备被描绘为电视监视器。电视本身可以包括CPE设备，CPE设备为电视提供操作系统、适当的硬件和软件以及应用层，应用层提供应用上下文切换和来自配套设备的资源共享以在电视监视器上显示，或者，电视监视器可以连接到CPE设备，CPE设备向其提供在电视监视器上显示内容所需的音频、视频或其他资源以及计算能力。电视/CPE设备150正在显示新闻广播者。也就是说，CPE设备150不显示在配套设备120上显示的来自TVmovie.com的内容。

在从图1A转到图1B之后，CPE设备150的显示已经改变，并且现在正在显示相同的内容项目，即TV上由配套设备120上运行的应用135传递的TVmovie.com网站上的电影。本示例中电影从它在配套设备120上的相同点继续。

假定在配套设备120上运行的应用140和在CPE设备150上运行的应用之间的隐式信任，以实现授权许可和应用上下文的共享。该隐式信任实现通过配套设备120上运行的应用140和资源提供商的交互而获得的授权许可与CPE设备应用150共享。

应当理解，如果两个应用的通信协议在它们之间是协调和同步的，则认为两个应用彼此“隐式信任”而不需要对共享通信的显式验证。当两个应用隐式信任彼此时，从一个应用接收的数据被另一个应用接受，而不需要对数据进行额外验证。隐式信任可以通过使用专有通信协议、在两个应用之间共享秘密或者本领域已知的任何其它适当方式来建立。

从配套设备120传送的授权许可和应用上下文使得CPE设备150/TV应用能够代表已认证和已授权的资源提供商(例如，内容提供者或所有者)访问资源。授权许可可采用唯一数据结构或句柄的形式，其可被交换用于获得访问_令牌，或者授权许可可以是资源提供商需要来标识资源提供商和由该资源提供商授予的显式资源访问的任何其它数据结构。

CPE设备150将使用访问令牌来控制对安全对象的访问并且控制用户在本地计算设备上执行各种系统相关操作的能力。在本说明书中，术语“访问_令牌”可以出现在系统内传送的各种数据元素的上下文中。应当理解，术语“访问_令牌”用于指代特定数据结构，而术语“访问令牌”用于指代由该数据结构表示的概念。通常，两个术语“访问令牌”和“访问_令牌”被理解为指代相同的项目。

作为示例，用户110去医生的办公室，并且在等待期间想要在医生办公室的等待区域内的大屏幕上播放来自他的“资源提供商”(例如Netflix)的电影。用户110在连接到医生办公室中的公共WiFi并且启动在他的手持设备上的配套设备120上运行的应用140后发现在医生办公室中提供大屏幕的CPE设备150/电视支持应用上下文切换特征，以从相同的资源提供商访问资源提供商的授权资源从而在大屏幕上显示内容。用户在配套设备120上登录到他的帐户，在从资源提供商接收到授权之后，将临时授权结构和应用上下文(资产元数据、当前位置、其他上下文信息等)“传递”到附接到医生办公室中的“大屏幕”的机顶盒(STB)上运行的应用(以下称为“app”)。STB应用交换具有访问令牌的授权结构，然后从“资源提供商”请求授权的资源以在大屏幕上开始流送电影。STB直接从“资源提供商”而不是从手持设备流送内容。当用户关闭此应用时，或者当他移出Wi-Fi范围时，STB-app关闭流并丢弃资源提供商发出的临时资源授权。

现在参考图1C，图1C是描绘图1A中使用的系统的高级视图的框图。图1C的系统包括配套设备120，其包括应用(“app”)165。应用165与资源提供商170通信并由其认证(步骤1)，资源提供商170响应于经由应用165的资源提供商认证，向应用165提供对授权资源的访问。

配套设备120执行搜索(步骤2)，以发现可用的CPE设备150。图1C中描述的系统可以包括多于一个CPE设备150。然而，为了便于描述，图1C中仅示出了一个CPE设备150。CPE设备150中的至少一个具有对应于配套设备应用165的CPE设备应用180。配套设备应用165将访问_令牌传递(步骤3)到CPE设备应用180。配套设备应用165传递授权结构和应用165的上下文和状态，以访问由资源提供商170提供的资源。

已经从CPE设备应用180接收到访问_令牌的资源提供商170然后建立授权并且向CPE设备应用180提供对所请求的资源的访问(步骤4)。然后，只要保持配套设备应用165和CPE设备应用180之间的连接，CPE设备应用180就能够使用诸如TV 190之类的CPE显示器来显示授权的资源(步骤5)。

在图1C的系统中，使用两个设备之间的常规安全机制在两个不同设备(即，配套设备120和CPE设备150)之间共享应用上下文。期望这两个设备运行由相同“应用提供商”开发的应用或者彼此隐式信任的应用。这些应用使用任何常规机制(SSL、客户端证书、通过HTTPS的基本授权等)交换信息。一旦在两个设备之间发生信息交换，则在第二设备(即CPE设备150)上运行的应用变得知晓第一设备(即，配套设备120)上可用的上下文。任何常规机制可以用于确定“共享上下文”时间的长度。

作为示例，配套设备120可以在CPE设备150上保持开放的套接字，或者可以连续向CPE设备150发送保持活动信号。由于这两个“app”(一个在配套设备120上运行，另一个在CPE设备150上运行)与相同的资源提供商170通信，因此它们可以共享以用户的名义从远程“资源提供商”访问资源所需要的“应用ID和“应用密钥”。因此，配套设备120可以将对应用的一些操作/方面脱离到CPE设备150，并且充当第二屏幕的角色。

应当理解，在“应用层”而不是“协议”层中启用该功能。因为“应用上下文”共享发生在“应用层”，所以应用可以自由地使用两个设备之间的任何安全机制。

现在参考图2，图2是描述可以使用图1C的系统的简化用例集的用例图。在第一用例中，用户A 210寻求用户授权(用例220)以在配套设备120上使用远程服务。下面参照图4更详细地描述用例220。

在第二用例230中，用户A 210向CPE设备150共享现在在配套设备120上被授权的当前应用及其上下文。下面参照图5更详细地描述第二用例230。

在第三用例250中，用户B 240通过在CPE设备150上切换应用上下文和访问令牌来控制CPE设备150。CPE设备150现在将显示在用户B 240的配套设备120上运行的应用165。下面参照图6更详细地描述第三用例250。

应当理解，在各种用例的以下讨论中的每一个中，不详细描述设备发现，因为设备发现的过程基于标准SSDP(简单服务发现协议)/UPNP(通用即插即用)协议。

现在参考图3，图3是图1C的系统的CPE设备150的框图图示。

CPE设备150包括至少一个处理器310，并且可以包括多于一个处理器310。处理器310中的一个可以是操作为执行根据本文所描述的方法的步骤的专用处理器。例如，处理器310可以执行创建授权上下文、建立信任、创建应用上下文数据等所需的步骤。另外，CPE设备150包括非暂态计算机可读存储介质(即存储器)320。存储器320可以存储处理器310中的至少一个可以执行的指令，以执行本文所描述的方法的步骤。CPE设备150还包括本领域中已知的典型和标准的硬件和软件组件。

另外，CPE设备150可以包括使得CPE设备150的用户110能够与CPE设备150交互的用户界面(通常是图形用户界面，GUI)330。典型的交互可以包括但不限于：开始和停止播放内容的命令，快进和后退播放内容(以比常规播放速度快的速度)，以及提高或降低音频音量。

CPE设备150还包括显示器340，内容项目在其上呈现(即展现)给用户。除了本领域已知的其他典型和标准的硬件和软件组件之外，CPE设备150还可以包括存储设备360。

CPE设备150还包括通信端口370，包括但不限于用于以下各项中的任一项的端口：IP通信(有线和/或无线)、蓝牙、IR以及本领域公知的其他适当协议。在本发明的实施例中，CPE设备150通信端口370使得能够在CPE设备150和配套设备120之间以及在CPE设备150和资源提供商之间进行通信(即，本领域已知的发送器和接收器)。

尽管在图中未示出，但本领域技术人员将理解，图3中所示的CPE设备150的许多组件在配套设备120(图1A)中具有对应的组件。也就是说，配套设备还包括至少一个处理器、存储器、存储设备、GUI和通信端口。还应当理解，处理器之一可以是操作为执行根据本文所描述的方法的步骤的专用处理器。另外，存储器可以存储处理器中的至少一个可以执行的指令，以执行本文所描述的方法的步骤。还应当理解，通信端口操作为充当被明确或隐含地提及为在本文所描述的方法和系统中使用的各种发送器/接收器。

现在参考图4，图4是示出在图1C的系统中使用的配套设备授权序列的数据流程图。图4更详细地描绘了第一用例，即图2的用例220。在图4的数据流程图中描绘的用例220示出了用户110从资源服务器的请求授权流程。图4示出了在配套设备120上运行的应用140用于以用户110的名义访问资源提供商上的资源的资源授权请求的一般流程。在图4和随后的描述中，用户110在这里被称为Alice 402，并且资源将被称为“FB”。

应当理解，在图4所示的序列之前，在配套设备120上运行的应用140的开发者已经注册了要请求的资源(例如，FB)的OAuth服务。开发者已经获得了开发者意图运行在配套设备120上的应用140以应用140(以下也被称为“app”140)的用户110的名义进行访问的资源组的所标识的范围(例如电子邮件地址、朋友的列表、图片、视频)、应用ID(唯一应用标识符)和客户端ID(唯一地标识开发者帐户的标识符)。

还应当理解，为了使Alice 402能够访问在配套设备120上运行的应用140(以下称为“配套应用”404)上的资源FB，Alice 402通过资源提供商建立账户，这一过程使用OAuth服务。本领域技术人员将理解，除了使用OAuth之外的其他方法也是可能的。例如，并且不限制前述内容的一般性，可以使用基于单点登录和资源提供商的组合的定制资源授权机制。OAuth已被用作示例，因为它被良好的记载并且是标准。

使用配套设备120GUI，Alice 402向配套应用404指示希望访问资源FB(406)。配套应用404做出从资源提供商410请求资源的显式请求(408)。资源提供商410向配套应用404响应对OAuth服务414的URL的重定向(412)，以及通知OAuth服务414哪些资源集正在被请求的范围信息。正在访问配套应用120的资源提供商然后可以选择授权配套应用120访问特定的资源集。例如，配套应用120可以仅被授权访问初始请求范围的集合的子集。

配套应用404然后向OAuth服务414发送登录页面请求(416)。作为响应，OAuth服务414将登录页面发送到配套应用404(418)。此时，Alice 402输入她的证书并将其提交给配套应用404(420)，配套应用404进而通过将当前证书语句转发到OAuth服务414(422)来将在步骤中提交的证书转发到OAuth服务414。应当理解，OAuth服务414实际上提供四种不同类型的授权(参见RFC 6749，tools.ietf.org/html/rfc6749)。在本示例中讨论的机制是类型授权码的授权许可。本领域技术人员将理解，所有这四种机制也可用于实施本发明。

OAuth服务414验证Alice的所呈现的证书(424)。在验证(424)之后，OAuth服务414生成访问_令牌并在服务FB内查找Alice 402的授权范围(426)。一旦OAuth服务414确定服务FB内的Alice 402的授权范围(426)，则OAuth服务414继续查找Alice的重定向URL并生成适当的授权码(428)。最后，基于对Alice的重定向URL的查找以及生成适当的授权码(428)的结果，OAuth服务414向配套应用404发送包含授权码的到重定向端点的重定向(430)。

响应于从OAuth服务414接收到重定向端点的重定向(430)，配套应用404然后向资源提供商410发送取回访问_令牌请求(432)。取回访问_令牌请求(432)包括授权码。资源提供商410在从配套应用404接收到具有适当生成的授权码的取回访问_令牌请求(432)时，进而向托管在OAuth服务414上的令牌端点发送包含授权码的HTTP POST请求(434)。响应于接收包含有效授码的HTTP POST请求(434)，OAuth服务414向资源提供商410发送访问_令牌(436)。资源提供商410然后存储接收到的访问_令牌(440)，并将访问_令牌转发到配套应用404(445)。

配套应用404缓存访问_令牌(450)。配套应用404然后从资源提供商410请求对FB资源的访问(460)。然后，资源提供商410向配套应用404提供对FB服务上的授权资源的访问(470)。

现在参考图5，图5是示出在图1C的系统中用于共享应用上下文的方法的数据流程图。图5更详细地描绘了第二用例，即图2的用例230。在图5的数据流程图中描绘的用例230示出了用于在配套应用404和CPE设备504(其对应于图1A和1B的CPE设备150)之间共享应用上下文的方法。继续图4的讨论，正在运行配套应用404的Alice402的配套设备120现在具有访问_令牌，并且因此能够访问资源FB。

配套应用404执行简单服务发现协议(SSDP)M-SEARCH(506)。如本领域中已知的，SSDP是基于UDP的协议，并且M-SEARCH是用于发现网络上的可用服务的多播搜索方法。响应于M-SEARCH(506)，CPE设备504发送单播寻址响应(508)，该响应包括CPE设备504的地址和端口号。

配套应用404然后向CPE设备504发送证书请求(即，接收数字证书的请求)(510)，作为响应，CPE设备504向配套应用404发送证书(515)。配套应用404然后验证接收到的证书(520)。

一旦在步骤520中验证了接收到的证书，则配套应用404和CPE设备504能够发起安全通信会话(525)。在安全通信会话(525)的框架内，配套应用404创建应用上下文数据(530)。应用上下文数据530至少包括：用户信息(例如用户id、名称)；授权结构(例如：交换和获取访问_令牌的代码、令牌端点信息、授权长度、授权刷新的ping接口、保持活动的套接字/端口)；和应用状态数据(例如正被请求的资源或资产、播放位置、电影的总长度、对于STB应用可能有用的其他元数据)。配套应用404将应用上下文数据530递送到CPE设备504(540)。CPE设备504然后存储和更新应用数据(550)。在存储和更新应用数据(550)之后，CPE设备504在对资源的请求中将访问_令牌发送到资源提供商510(560)。资源提供商510然后将所请求的资源(例如，FB)提供给CPE设备504(570)。应当理解，上述用户信息用于唯一地标识用户，使得安全通信会话525可以被销毁。

现在参考图6，图6是示出在图1C的系统中用于在与单个CPE设备150通信的两个配套设备120之间切换应用上下文的方法的数据流程图。图6更详细地描绘了第三用例，即图2的用例250。在图6的数据流程图中描述的用例250示出了用于将CPE设备504上的应用控制从第一配套应用404切换到第二配套应用604的方法。

在图6所示的方法的第一阶段(即步骤506-570)，第一配套应用404执行图5所示的步骤，以与CPE设备504共享其应用上下文。

在图6所示的方法的第二阶段，第二配套应用604(其功能上类似于配套应用404)执行步骤606-670，其分别对应于图5中示出且由第一配套应用404执行的步骤506-570。应当理解，当安全通信会话625由执行步骤606-670的第二配套应用604创建时，被创建以共享应用上下文的安全通信会话525被销毁。与第一安全通信会话525有关的所有元数据和状态被清除和丢弃。在一些情况下，配套应用604可以向OAuth服务器414作出明确请求，以销毁与资源提供商向CPE设备应用180提供的授权许可相关联的“访问_令牌”。

现在参考图7，图7是示出对图5中所描述的用于共享应用上下文的方法的替代方法的数据流程图。在图7的替代方法中，如上文参考图5所述的那样启动安全通信会话525。配套应用404首先向资源提供商705发送针对临时令牌的获取请求(710)，包括临时令牌中的访问令牌和有效长度。在步骤720中，资源提供商705通过向配套应用404发送所请求的临时令牌来响应。然后，配套应用404不是执行创建应用上下文数据的步骤530，而是创建应用上下文数据并且生成至少包括用户信息(如上所述)；temp_token(临时令牌)；和应用状态数据的应用上下文数据(730)。配套应用404将包括临时令牌的应用上下文数据730递送到CPE设备504(740)。CPE设备504然后存储和更新包括临时令牌的应用数据(750)。

在循环760中，CPE设备504从资源提供商705请求期望的资源(770)。对期望的资源的请求770包括临时令牌。所期望的资源由资源提供商705递送到CPE设备504(780)。针对每个资源请求770-资源递送780重复该循环。

当循环760结束时，配套应用404向资源提供商705发送销毁(临时令牌)指令(790)，从而使得临时令牌被销毁，并且防止用户402(图4)或伪装成用户402(图4)的其他人进一步使用CPE上的资源。

如图7所呈现的方案预先假定资源提供商705已被“定制”为支持使用在步骤730中生成的临时令牌。

现在参考图8，图8是示出对图5中所描述的用于共享应用上下文的方法的第二替代方法的数据流程图。在图8的替代方法中(如上面参考图4所述)，CPE设备504由资源提供商705授予其自己的访问令牌，因此配套应用404不需要与CPE设备504共享访问令牌。

用户402启动消费者应用404(406)。如上文参照图5所述的那样启动安全通信会话525。然而，应当理解，在图8中，图4的步骤4还没有被执行，因此，需要如上文参照图4所述的那样接收访问_令牌。然而，在图8所描述的方法中，在安全通信会话525内接收访问令牌，如现在所描述的。

一旦建立了安全通信会话525，则配套应用404从资源提供商705请求资源(808)。如上所述，资源请求808不伴随有访问令牌。资源提供商705利用到授权服务器805的重定向812来响应配套应用404。当作出授权请求时，以下数据被传递到OAuth服务器805：范围；状态；和重定向URL。范围定义了配套应用404以资源提供商705的名义正在请求的资源集。状态包括配套应用404在OAuth服务器805已经认证了资源提供商705并且重定向回资源提供商705的重定向URL之后所需的数据。

配套应用404然后向授权服务器805发送登录页面请求(816)。作为响应，授权服务器805向配套应用404发送登录页面(818)。在接收到登录页面818时，配套应用404向用户402呈现登录表单(819)，并且等待直到用户402提供了登录表单819所需的信息。应该理解，登录页面818和登录表单819包括相同的表单/页面。然而，为了在图中和本说明书中区分步骤818和819，在说明书中使用了不同的术语。当用户402将所需的登录证书提供给配套应用404(820)时，配套应用404通过对期望的资源的授权访问请求(825)来将登录证书传递到授权服务器805。应当理解，在图8的讨论中的授权访问请求的操作825与图4中通过重定向到重定向端点430的呈现证书422；验证证书424等的步骤中所描述的操作相同。然而，为了便于示出和描述，步骤422-430被缩写为图8中的授权访问请求的操作825的步骤。

授权服务器805用授权码830来回答配套应用404。配套应用404然后创建应用上下文数据835。应用上下文数据835至少包括(如上所述)：用户信息；授权码830；和应用状态数据。配套应用404将应用上下文数据835递送到CPE设备504(840)。

CPE设备504然后向资源提供商705提交包括授权码830的取回访问令牌请求845。资源提供商705通过向CPE设备504发送访问令牌来进行响应(850)。

在循环855中，CPE设备504现在能够访问资源提供商705上的期望资源。这是通过CPE设备504向资源提供商705发送访问资源请求860来实现的，并且响应于这些请求860，资源提供商705提供所请求的资源865。

在图8的机制中，配套应用404具有结束CPE设备504和资源提供商705之间的循环的能力。在这种情形中，配套应用404向授权服务器805发送撤销授权请求875。响应于配套应用404的撤销授权请求875，授权服务器805指示资源提供商705销毁的CPE设备504访问令牌(880)。响应于销毁访问令牌(880)的指示，资源提供商705销毁访问令牌(890)。如果CPE设备504现在尝试向资源提供商705发送访问资源请求860，则资源提供商705现在将不能验证访问资源请求860中的访问令牌的有效性。因此，资源提供商705将不向CPE设备504提供访问资源请求860中所请求的资源。

现在参考图9，图9是本文描述的一个实施例的操作方法的流程图。根据上述讨论认为图9是自解释的。

应当理解，如果需要，则本发明的软件组件可以ROM(只读存储器)形式实现。如果需要，软件组件一般可以使用常规技术在硬件中实现。还应当理解，软件组件可以被实例化，例如：作为计算机程序产品或在有形介质上。在一些情况下，可以将软件组件实例化为可由适当的计算机解释的信号，但是在本发明的某些实施例中可以排除这样的实例化。

应当理解，为了清楚起见，在分开的实施例的上下文中描述的本发明的各种特征也可以在单个实施例中组合提供。相反，为了简明起见，在单个实施例的上下文中描述的本发明的各种特征也可以单独地或以任何合适的子组合提供。

本领域技术人员应当理解，本发明不限于上文具体示出和描述的内容。相反，本发明的范围由所附权利要求及其等同形式限定。