CN105706025A - 基于上下文和策略的传感器选择 - Google Patents

Abstract

本文所讨论的实施例基于上下文和策略来实现传感器选择，以提供多种不同的传感器类型和配置，和检测多种不同的现象。在至少一些实施例中，使用传感器集线器来从各个功能单元接收针对传感器数据的请求，并基于针对策略的上下文的应用来选择传感器以提供该传感器数据，其中所述策略指定用于传感器选择的参数。

Description

基于上下文和策略的传感器选择

发明内容

提供本概要部分以便用简化的形式介绍将在以下的详细描述中进一步描述的概念选择。本概要部分并不是旨在标识要求保护的主题的关键特征或本质特征，也不是旨在用于帮助确定要求保护的主题的范围。

本文所讨论的实施例基于上下文和策略来实现传感器选择，以提供多种不同的传感器类型和配置，和检测多种不同的现象。在至少一些实施例中，使用传感器集线器来从各个功能单元接收针对传感器数据的请求，并基于针对策略的上下文的应用来选择传感器以提供该传感器数据，其中所述策略指定用于传感器选择的参数。

附图说明

参照附图描述具体实施方式。在这些附图中，附图标记的最左侧数字标识该附图标记第一次出现时的附图。说明书和附图中的不同实例对于相同附图标记的使用，可以指示类似或相同的项。

图1是可操作用于使用本文所讨论的技术的示例性实现中的环境的视图。

图2示出了根据一个或多个实施例的传感器配方(recipe)的示例性实现。

图3示出了根据一个或多个实施例的策略的示例性实现。

图4根据一个或多个实现，示出了用于生成唤醒事件的示例性场景。

图5根据一个或多个实现，示出了用于确定设备位置的示例性场景。

图6根据一个或多个实现，示出了用于对用户进行认证的示例性场景。

图7是根据一个或多个实施例，描述用于配置传感器集线器的方法中的步骤的流程图。

图8是根据一个或多个实施例，描述用于确定是否生成唤醒事件的方法中的步骤的流程图。

图9是根据一个或多个实现，描述用于代理(broker)传感器数据的方法中的步骤的流程图。

图10示出了如参照图1所描述的示例性系统和计算设备，它们被配置为实现本文所描述的技术的实施例。

具体实施方式

概述

很多计算设备都具有多个传感器，可以利用这些传感器来感测不同类型的与设备有关的现象。这些传感器的示例包括位置传感器、方位传感器、音频传感器、视频传感器(例如，相机)、触摸传感器、生物识别传感器、气候传感器(如，用于温度、压力、湿度等等)、网络活动、时间等等。在至少一些实施例中，基于一个或多个传感器来定义“传感器系统”。例如，方位传感器系统可以包括诸如陀螺仪、加速计等等之类的传感器的集合。可以对来自传感器系统的不同传感器的数据进行处理和/或组合，以确定各种状况。此外，在确定各种状况(例如，与设备有关的状况、环境状况等等)时，可以考虑来自多个传感器系统的输入。

本文所讨论的实施例基于上下文和策略来实现传感器选择，以提供多种不同的传感器类型和配置，和检测多种不同的现象。通常，可以使用传感器集线器来从多个传感器接收传感器输入，以不同的方式对该输入进行融合以生成各种各样的不同传感器类型和传感器实例。在至少一些实施例中，可以对不同的传感器进行融合，以生成用于检测物理现象(例如，视觉输入、音频输入、触摸输入、振动、移动等等)的融合的传感器。此外，融合的传感器还可以被配置为检测逻辑现象，例如，系统中的各种处理和/或设备的逻辑状态、系统中的某些逻辑事件的发生等等。

在至少一些实现中，传感器融合通常包括：根据指定传感器的不同组合以感测不同的现象的传感器“配方”，对多个不同的传感器(例如，传感器系统)进行组合。例如，可以定义多个传感器配方，其每一个指定用于对设备位置进行感测的不同传感器组合。可以定义另一组的传感器配方，其每一个指定用于对用户标识进行感测(例如，用于对用户进行认证以访问各种资源)的不同传感器组合。如本文所进一步详细描述的，可以定义用于对各种不同的现象进行感测的传感器配方。

根据各种实现，可以基于针对特定设备和/或用户的上下文和策略，来选择传感器配方。“上下文”通常指代系统可访问状态，其通知系统如何对传感器输入进行解释。上下文的例子包括：用户标识、用户角色(如，工作角色、个人角色等等)、检测的行为模式、时间、用户偏好、环境信息、位置、天气、针对各种上下文考量的历史值等等。在至少一些实现中，还可以利用系统学习来生成上下文信息。

可以实施一些策略(例如，基于上下文)来选择用于提供传感器数据的传感器，以及指定如何使用传感器数据(如，使用哪个传感器配方来获得特定类型的传感器数据)。通常，传感器策略指定用于选择传感器配方以提供传感器数据的规则和参数。例如，可以通过向应用于本场景的传感器策略应用该特定场景中的上下文，来实施传感器策略。在至少一些实现中，传感器策略控制允许什么系统行为或者不允许什么系统行为。下面将详细描述示例性策略考量。

在至少一些实现中，可以通过“策略生成人员”，对策略进行显式地配置和/或更新，其中授权了该策略生成人员生成和配置策略。这种策略生成人员的例子包括：应用开发人员、操作系统开发人员、信息技术(IT)人员等等。此外，可以利用系统逻辑和/或系统学习，以基于监测的系统行为和/或事件来建议系统策略和/或对系统策略进行改变。在至少一些实施例中，策略被配置为依赖于特定的上下文来进行应用。

根据一种或多种实现，传感器集线器和传感器系统提供具有事件生成的功率隔离，以进行系统功率控制。例如，可以在独立的功率域中(其中，可以独立于系统的其它部件(如，独立于中央处理单元(CPU))，来对该功率域进行供电)，来实现传感器集线器。在至少一些实现中，可以将传感器系统实现成孤立的子系统，每一个子系统具有处于独立的功率域中的可编程处理器。因此，当系统的其它部件是不活动和/或关闭的时，可以打开传感器系统(例如，连同传感器集线器一起)。

除了本文所讨论的实现之外，传感器集线器可以生成针对于其所连接到的传感器系统的功率请求，并且可以向系统级别功率控制机制发送事件。例如，当其它系统部件(如，CPU)是不活动时，传感器集线器可以打开并监测传感器输入。此外，传感器集线器可以被配置为生成唤醒事件，以响应于传感器输入来唤醒CPU和/或图形处理单元(GPU)。此外，还可以生成唤醒事件以唤醒系统存储控制器以及从传感器集线器到存储器的有关片上路径，和/或唤醒用于请求访问存储器和/或处理资源的传感器系统。下面将讨论各种其它细节和实现。

在下面的讨论中，首先描述可操作用于使用本文所描述的技术的示例性环境。接着，标题为“示例性场景”的段落根据一个或多个实施例来描述一些示例性操作场景。此后，标题为“示例性过程”的部分根据一个或多个实施例来描述一些示例性过程。最后，标题为“示例性系统和设备”的部分根据一个或多个实施例，来描述可操作用于使用本文所讨论的技术的示例性系统和设备。

在根据一个或多个实施例来给出示例性实现的概述之后，现在考虑可以使用示例性实现的示例性环境。

示例性操作环境

图1是一种示例性实现中的环境100的视图，其中该示例性实现可操作用于使用基于本文所描述的上下文和策略，来进行传感器选择的技术。所示出的环境100包括计算设备102的例子，其中该计算设备102可以以各种方式进行配置。例如，计算设备102可以被配置用于移动用途，比如，移动电话、平板计算机、膝上型计算机、可穿戴设备等等。例如，计算设备102的范围可以从具有大量的存储器和处理器资源的全资源设备，到具有有限的存储器和/或处理资源的低资源设备。

计算设备102包括输入/输出模块104，该模块表示与输入的处理和计算设备102的输出渲染有关的功能单元。输入/输出模块104可以对各种各样的不同输入进行处理，例如，与输入设备的键、显示设备所显示的虚拟键盘的键相对应的功能有关的输入，以用于识别手势和导致执行与这些手势相对应的操作(其中，这些手势可以通过附件设备和/或显示设备的触摸屏功能单元等等来识别)。因此，输入/输出模块104可以通过识别并利用不同类型的输入，来支持各种各样的不同输入技术。

如图1中所进一步示出的，计算设备102包括用于向该设备提供不同的功能单元的应用106和操作系统108。预期通常与计算设备相关联的各种应用106，包括但不限于：用于将多个办公产品模块集成在一起的生产套件、web浏览器、游戏、多媒体播放器、文字处理器、电子表格程序、照片管理器等等。操作系统108表示用于对该计算设备的各种资源(例如，硬件资源、软件资源、处理、服务等等)进行抽象和管理的功能单元。

多个传感器系统110安装在计算设备102上和/或与计算设备102操作性关联。通常，传感器系统110被配置为感测相对于计算设备102的各种现象。各个传感器系统110包括一个或多个类型和实例的传感器112。传感器112的例子包括加速计、相机、麦克风、生物识别传感器、触摸输入传感器、位置传感器、环境传感器(例如，用于温度、压力、湿度等)等等。传感器112中的一个或多个可以被配置为检测其它类型的现象，例如，时间(如，内部和/或外部时间)、各种类型的设备状态、逻辑状态、处理状态(如，应用状态)等等。在至少一些实现中，传感器112可以表示存储的能使用成配方的一部分的数据。例如，可以使用布尔值来表示能利用成传感器配方的一部分的传感器数据(如，作为虚拟传感器)。传感器112可以包括本文没有明确提及的各种其它类型和实例的传感器。

传感器系统110可以各自与不同类型的现象相关联。例如，一种特定的传感器系统110可以被配置为例如经由相机和/或其它类型的光传感器来感测图像输入。另一种传感器系统110可以被配置为例如经由麦克风来检测音频输入。另一种传感器系统110可以被配置为检测计算设备102的各种内部状态属性(例如，处理状态、逻辑状态、应用状态、硬件状态等等)。因此，传感器系统110可以进行组合，以提供计算设备102的感测能力的阵列。

根据本文所描述的技术，可以根据本文所讨论的实施例，以各种方式对由传感器系统110所获得和/或来自传感器系统110的传感器数据进行处理和/或组合。例如，可以以各种方式对来自不同传感器系统110的传感器数据流进行融合，以提供多种多样的不同的传感器配置和行为。

此外，传感器系统110还包括传感器系统处理器114，后者表示用于该传感器系统的数据处理单元。例如，在至少一些实现中，各传感器系统110包括相应的传感器系统处理器114，后者向该传感器系统110提供数据处理、高速缓存和编程能力。

此外，计算设备102还包括处理系统116和计算机可读介质118，它们表示可以与计算设备102相关联，并用于提供各种各样的设备功能单元的处理部件、介质、存储器和存储部件和/或设备的各种不同类型和组合。在至少一些实施例中，处理系统116和计算机可读介质118表示可以用于通用计算操作的处理能力和存储器/存储设备。根据一种或多种实现，处理系统116表示计算设备102的中央处理单元(CPU)。

此外，计算设备102还包括传感器集线器120，后者表示用于基于本文所讨论的上下文和策略，执行用于传感器选择的技术的各个方面的功能单元。可以利用各种方式来实现传感器集线器120，例如，通过可以独立于计算设备102的其它功能单元来操作的单独环境。例如，在一个或多个实现中，可以通过具有诸如处理部件、各种类型的存储器、可编程逻辑等等之类的自包含资源的片上系统/电路(例如，作为片上系统(SoC)的一部分)，来实现传感器集线器120。例如，传感器集线器120使得基于本文所讨论的上下文和策略的传感器选择的技术的各个方面能够在计算设备102的通常操作之外执行。

根据各种实现，传感器集线器120表示传感器系统110和计算设备102的其它功能单元(例如，操作系统108和应用106等等)之间的逻辑的抽象层。例如，传感器集线器120可以对来自不同功能单元的针对传感器数据的请求进行处理，并使用在传感器集线器120内部的逻辑，选择传感器系统110中的一个或多个来提供传感器数据。因此，各种实现无需涉及选择特定的传感器系统110来提供传感器数据流的功能单元，就可以实现用于从传感器集线器120请求特定类型的传感器数据，并接收该特定类型的传感器数据的数据流的功能单元。例如，传感器集线器120可以向计算设备102的其它功能单元显示为单个传感器表示，其中将向该单个传感器表示提交针对不同类型的传感器数据的请求，并从该单个传感器表示接收不同类型的传感器数据的流。

在至少一些实现中，可以独立于计算设备102的其它部件，例如通过独立的功率域来对传感器集线器120进行供电。例如，当计算设备102的其它部件(例如，处理系统116)处于低功率模式时(例如，休眠和/或关闭)，传感器集线器120可以保持开机。因此，一个或多个实现在计算设备102处于低功率模式和/或关闭的情况下，实现基于上下文和策略来执行传感器选择的方面。

因此，传感器集线器120还表示可以独立于与外部系统部件(如，处理系统116、操作系统108等等)的交互，来执行与基于本文所讨论的上下文和策略来进行传感器选择的技术有关的各种处理。下面给出这些逻辑和处理的例子。

传感器集线器120包括集线器处理器122、上下文模块124、策略模块126和配方模块128。集线器处理器122表示传感器集线器120的处理单元，并且可以执行本文所讨论的各种逻辑的存储和/或执行。

上下文模块124表示用于对不同的状态状况进行解释和/或处理的功能单元，其中这些状态状况涉及针对传感器数据的请求和/或与传感器有关的行为。在本文的其它地方详细描述了上下文信息的例子。在至少一些实现中，可以对上下文进行编程性定义，使得可以基于各种检测到的状态状况来指定定制上下文130。上下文模块124可以包括用于对原始状态信息进行解释，以及用于将环境状况的特定集合与定制上下文130进行相关的逻辑。在至少一些实现中，上下文信息可以包括存储的信息、流传输到计算设备102和/或流传输自计算设备102的信息、以及观测的信息(例如，环境状态信息)。

策略模块126表示用于存储、管理和配置策略132的功能单元。通常，策略132指定用于基于上下文和策略来实现传感器选择的技术的不同规则和参数。虽然策略132中的某些可以是特定于传感器的，但策略132可以另外地或替代地表示对本地和/或全局系统行为进行管理，并也可以应用于传感器行为的通用策略。在至少一些实现中，策略模块126可以使得呈现GUI，其中该GUI实现策略132的用户配置。下面讨论关于策略的另外细节。

配方模块128表示用于存储、管理和配置传感器配方134的功能单元。通常，传感器配方134指定用于对不同的现象进行感测的传感器的不同实例和组合。在至少一些实现中，各个传感器配方134可以包括来自不同传感器系统110的传感器。因此，传感器配方134实现对来自多个传感器系统110的传感器的融合，以创建可以对各种类型的现象进行感测和/或检测的传感器的定制组合。例如，可以基于策略132，选择传感器配方134中的不同一个，来感测不同的现象。根据一种或多种实现，传感器集线器120可以导致呈现图形用户界面(GUI)，其中该GUI实现传感器配方134的用户配置。下面讨论关于配方的另外细节。

此外，计算设备102还包括功率控制器136，后者表示用于针对计算设备102的不同功能单元来执行功率管理的功能单元。例如，功率控制器136可以实现计算设备102的各种功能单元在不同的活动状态之间进行转换(例如，在正常操作模式、休眠模式、关闭模式等等之间进行转换)。如本文所详细描述的，传感器集线器120可以从传感器系统110接收传感器数据，并基于该传感器数据，可以提示功率控制器136使计算设备102的不同功能单元在不同的功率状态之间进行转换。

图2根据一个或多个实施例，示出了传感器配方134的示例性实现。通常，传感器配方134指定可以用于对不同的现象进行感测的传感器的不同实例、类型和/或组合。

位置配方200指定可以用于检测位置(例如，计算设备102和/或计算设备的用户的位置)的传感器的不同实例和组合。例如，位置配方200a指定可以使用GPS坐标来检测用户的位置(例如，基于用户的设备所检测的GPS坐标)。位置配方200b指定可以使用蜂窝电话三角测量和无线网络信息来检测用户的位置。位置配方200c指定可以使用无线网络信息加上高度检测信息来检测用户的位置。

存在性配方202指定可以用于检测用户存在性的传感器的不同实例和组合。用户存在性的例子包括：“空闲”、“繁忙”、“在开会”、“在呼叫”、“离开”、“办公室”等等。因此，可以使用存在性配方202来检测用户的存在性状态。存在性配方202a指定可以使用用户指定的存在性信息来确定用户的存在性状态。用户指定的存在性信息的例子包括用户设置的状态信息，例如，位于在线聊天服务、社交媒体平台、互联网协议承载语音(VoIP)服务上等等。

存在性配方202b指定可以使用触摸传感器输入加上呼叫状态来确定用户的存在性状态。例如，如果触摸输入设备检测到用户正在握持他们的移动设备，但蜂窝电话功能单元没有检测到有呼叫正在进行，则可以确定用户是空闲的。另一方面，如果检测到蜂窝呼叫在进行之中，则可以确定用户是“繁忙的”和/或“在呼叫”。存在性配方202c指定可以使用图像检测加上一天中的时间来确定用户存在性。例如，可以激活一个和/或多个相机来检测该用户是否是可检测的(例如，位于该摄像头的观看区域之内)。如果相机检测到用户，并且一天中的时间正处于正常的营业时间期间，则可以确定用户是“空闲的”。否则，如果相机没有检测到用户，和/或如果检测到用户，但一天中的时间是在营业时间之后，则可以确定用户是“离开的”。

认证配方204指定可以用于对用户的标识进行认证(例如，用于进行访问，以对计算设备进行解锁和/或实现对受保护资源的访问)的传感器的不同实例和组合。认证配方204a指定可以使用用户证书的输入来对用户进行认证。用户证书的例子包括用户名、密码、个人识别号(PIN)等等。

认证配方204b指定可以使用生物识别认证加上个人识别号(PIN)的输入来对用户进行认证。生物识别认证的例子包括指纹匹配、人脸识别、眼部识别等等。认证配方204c指定可以使用生物识别加上语音识别来对用户进行认证。

活动配方206指定可以用于对用户参与的活动的类型进行检测的传感器的不同实例和组合。活动配方206a指定可以使用运动传感器来检测用户活动。例如，如果用户正在快速地移动，并且检测到跑步的运动，则可以确定用户正在锻炼(例如，跑步)。如果用户正在快速地移动，但是检测到很小的非平移运动，则可以确定用户在运输过程中(例如，开车)。

活动配方206b指定可以使用图像检测加上运动感测来检测用户活动。例如，如果检测到用户的图像，但检测到很小的运动或者没有检测到运动，则可以确定用户在家中或者在工作。活动配方206c指定可以使用用户输入检测来检测用户活动。例如，可以对用户正提供的用户输入的类型进行分析。如果用户正在向与工作有关的文档提供输入，则可以确定用户正在工作。如果用户正在阅读某个社交媒体站点，则可以确定用户在参与休闲活动。

因此，可以通过配方来指定不同类型和实例的传感器，来对不同类型的现象进行感测。根据各种实现，可以将各个传感器配方134视作为虚拟传感器，其中可以实现这些虚拟传感器以检测现象。例如，虽然特定的传感器配方134可以指定来自不同传感器系统的传感器的多个实例，但配方可以简单地向其它功能单元(例如，操作系统108)显示为传感器的实例，传感器的实例可以称为对不同的现象进行感测。只是为了举例的目的，给出了这些特定类型和实例的配方，但应当理解的是，实现也可以使用本文没有明确讨论的不同类型和实例的配方。

在至少一些实现中，传感器配方134可以包括用于指示将如何对来自该配方中指定的各个传感器的传感器数据进行解释和/或融合的数据。因此，传感器配方不仅包括特定的传感器或者传感器的集合，而且还包括用于对原始传感器输入进行处理以获得复杂的环境信息的逻辑。因此，实现可以通过传感器配方134，使得来自不同传感器系统的传感器能够融合成可以在多个传感器域上提供传感器数据的集成的“虚拟传感器”。此外，可以通过用于将来自不同传感器系统110的传感器数据流合并成相干数据流，以便各个功能单元进行使用的不同传感器配方，来定义多个不同的虚拟传感器。

图3根据一个或多个实施例，示出了策略132的示例性实现。通常，策略132表示可以用于选择各种传感器和传感器配方134，以便对不同的现象进行感测的不同类型和实例的策略。在至少一些实现中，策略132中的一个或多个可以由企业实体、政府实体、终端用户等等进行定义。策略132可以是特定于传感器场景，和/或可以表示应用于一般的机构和个人行为(其包括但不限于与传感器有关的行为)的通用策略。

认证策略300指定用于不同的上下文中的认证过程的规则和参数。例如，认证策略300可以指定在不同的上下文中，允许哪些认证过程和不允许哪些认证过程。

资源访问策略302指定用于确定可以访问哪些类型的资源、谁可以访问特定的资源、以及可以访问特定的资源的条件的规则和参数。资源的例子包括数据资源(例如，内容、文件等等)、硬件资源(例如，计算设备、输出设备、通信设备等等)、网络资源(例如，网络连接)、物理资源(例如，会议室、办公室等等)、个人资源等等。

隐私策略304指定用于保护隐私关注的规则和参数。例如，可以实现隐私策略304以保护用户隐私、企业秘密、数据保密等等。

安全策略306指定用于保护资源安全的规则和参数。例如，安全策略306可以指定用于管理谁可以访问特定的资源，以及可以如何访问这些资源的规则和参数。

合法策略308指定基于合法考虑的规则和参数。例如，可以实施合法策略308以确保传感器使用不违反特定的司法权中的法律。

用户安全策略310指定可以实现以保护用户安全的规则和参数。例如，用户安全策略310可以指定在某些场景中可以使用或者不能使用，以防止可能的不安全行为或者状况的传感器的类型。

用户偏好策略312指定基于用户偏好的用于传感器使用的规则和参数。根据各种实现，用户偏好可以由用户进行明确地指示，和/或可以根据用户行为进行推断。

位置策略314指定用于选择和使用传感器以确定用户和/或设备位置的规则和参数。例如，位置策略314可以指定可以用于查明用户和/或设备位置的传感器输入和/或信息的类型。在至少一些实现中，位置策略314可以在指定用于确定用户和/或设备位置的规则和参数时，考虑其它策略(例如，对于保护安全、隐私、合法考虑等等感兴趣)。

数据完整性策略316指定用于查明是否和/或如何使用不满足数据完整性的某些标准的传感器数据的规则和参数。例如，数据完整性标准可以指定传感器数据中允许的错误数量、来自传感器的最小数据速率、特定传感器的允许的和/或不允许的数据类型等等。例如，数据完整性策略316可以指定：如果来自特定传感器的传感器数据不满足数据完整性标准(例如，该数据具有太多的错误和/或其不具有正确的形式或格式)，则将不使用该传感器数据。因此，可以忽略使用该特定传感器的配方。此外，如果在使用特定的传感器来提供传感器数据时，其发生故障，则可以(例如，动态地)选择不包括该传感器的不同传感器配方。因此，数据完整性策略316可以提供用于围绕传感器数据的质量和形式来强制传感器数据标准的方式。

用户角色策略318指定用于基于用户的不同角色，来选择传感器配方的规则和参数。例如，用户可以具有不同的角色，例如，管理员、用户、客户等等。此外，特定的用户可以根据该用户在给定的时间所位于的位置和/或该用户在给定的时间执行动作的容量，来担任不同的角色。例如，当用户在家中时，可以认为该用户正在承担“消费者角色”，而当用户在工作时，则可以认为该用户正在承担“企业角色”。在至少一些实现中，可以通过不同的许可和/或用户属性，来区分不同的角色。因此，用户角色策略318可以指定可以用于特定的用户角色的传感器的特定类型和/或实例，并且还可以指定不能用于特定的用户角色的传感器的不同类型和/或实例。在至少一些实现中，可以基于当前在特定系统上活动的用户帐户(例如，登录到该系统的用户)，在该系统上应用用户角色策略318。

因此，可以使用不同的策略来选择用于对不同的现象进行感测的特定配方。可以对策略进行组合和/或定制，以适合不同的场景和/或环境。只是为了举例的目的，给出了这些特定类型和实例的策略，但应当理解的是，可以根据一种或多种实现，来实现本文没有明确提及的各种各样的策略。

在讨论了实施例可以操作的示例性环境之后，现在根据一个或多个实施例，考虑使用本文所讨论的技术的一些示例性实现场景。

示例性场景

下面的讨论描述了用于基于上下文和策略技术来进行传感器选择的一些示例性场景，其中可以使用先前所描述的系统和设备和/或本文没有明确讨论的其它系统和设备来实现这些技术。这些场景的方面可以利用硬件、固件、软件或者其组合来实现。

图4根据一种或多种实现，示出了用于生成唤醒事件的示例性操作场景400。场景400包括上面所介绍的计算设备102的各种部件，例如，传感器系统110、传感器集线器120、处理系统116和功率控制器136。根据场景400，处理系统116初始时处于不活动和/或低功率状态(例如，关闭状态或休眠状态)。但是，传感器系统110和传感器集线器120处于活动状态。

在场景400中，例如经由传感器112中的一个或多个所感测到的特定类型的现象，将传感器输入402提供给传感器系统110。传感器输入402可以包括活动输入，例如，作为针对输入设备(如，触摸屏、键盘等等)的用户输入。替代地或另外地，传感器输入402可以包括被动输入(例如，各种检测到的偶然现象)。被动输入可以包括用户存在性的检测，例如，经由相机来检测用户的图像，检测用户的声音等等。此外，被动输入还可以包括系统和/或环境状态的各种改变，例如，特定的时钟时间的发生、某种应用和/或处理状态的发生、某种物理现象的检测(例如，光亮度、温度等等)等。

基于传感器输入402，传感器系统110向传感器集线器120传输传感器数据404。传感器数据404可以包括响应于传感器输入402和/或源自于传感器系统110向传感器输入402所应用的处理而获得的传感器输入，而产生的原始传感器数据。传感器集线器120基于与传感器输入402有关的上下文406(如应用于策略132中的一个或多个)，对传感器数据404进行处理。通常而言，上下文406通常用于描述传感器输入402的前后输入的状态状况(例如，环境和/或系统状态)。例如，上下文406可以指示计算设备102的当前状态状况，例如，处理系统116处于不活动状态。上下文406可以指示各种其它状态信息，例如，一天中的时间、位置、日历事件等等。

根据一种或多种实现，策略132指定用于在不同的上下文中，对传感器输入进行解释和/或处理的规则和参数。在该示例性场景400中，策略132包括唤醒策略408，后者响应于传感器输入，指定用于生成唤醒事件的规则和参数。通常来讲，“唤醒事件”指代可以导致不同的功能单元从不活动状态转换到活动状态的通知和/或加电事件。例如，唤醒策略408可以指定：可以导致将生成唤醒事件的上下文和传感器输入的组合，和/或不会导致生成唤醒事件的上下文和传感器输入的组合。

继续该场景400，唤醒策略408指定基于传感器数据404的类型和接收到传感器数据404时的上下文406，将生成唤醒事件。因此，集线器处理器122生成唤醒事件410。随后，传感器集线器120将唤醒事件410传输给功率控制器136。响应于接收到该唤醒事件136，功率控制器136使得处理系统116转换到活动状态(例如，正常操作功率状态)。随后，处理系统116可以发起各种处理，例如，发起系统启动进程、唤醒计算设备102的其它功能单元等等。

虽然场景400示出了唤醒事件410使得处理系统116在活动状态之间进行转换，但应当理解的是，唤醒事件410可以另外地或替代地传输到其它功能单元，以实现该功能单元在活动状态之间的转换。

因此，场景400示出了在各种实现中，当系统的其它部件(例如，CPU、GPU等等)不活动时，传感器集线器120可以根据上下文和策略，对传感器输入进行接收和处理。这种方式实现了独立于系统的主处理装置，关于如何对传感器输入进行处理，以及是否生成某些事件来进行判断，因此实现了节省系统功率和资源。

图5根据一种或多种实现，示出了用于确定设备位置的示例性操作场景500。在至少一些实现中，场景500表示上面所讨论的场景400的继续。根据一种或多种实现，场景500包括设备502，后者表示计算设备102的实现。

在该场景500中，发起针对设备502的位置的位置请求504。该位置请求504可以是在设备502的内部发起的(例如，由与设备502相关联的应用和/或服务来发起)。替代地或另外地，位置请求504可以是在设备502的外部发起的。

响应于该位置请求504，确定用于该位置请求504的上下文506。通常，上下文506包括所存在的与位置请求504有关的不同状态状况。在至少一些实现中，上下文506可以是特定于设备502的，例如，设备502的内部状态信息、经由设备502的传感器所检测到的状态状况、用于设备502的标识信息(例如，设备和/或用户标识符)等等。另外地或替代地，上下文506可以包括在发起位置请求504时的状况，例如，发起该请求504的实体的标识符、发起该请求504的时间和/或日期、针对位置请求的用户偏好等等。因此，在至少一些实现中，上下文506可以包括在处理位置请求504时可以考虑的各种各样的不同实例和类型的状态信息。在该特定的例子中，上下文506指示该设备502具有较差的GPS信号接收。例如，该设备502可以在室内和/或处于来自GPS卫星的GPS信号被部分地或整体地阻塞的位置。

继续该场景500，向策略508应用上下文506，以确定用于确定该设备502的位置的传感器配方。策略508可以包括各种类型和/或实例的策略。例如，策略508可以表示策略132中的一个或多个的实现，上面参照图3讨论了它们的例子。在该场景500中，策略508指定：如果设备502具有较差的GPS接收和/或没有GPS接收，则选择不涉及GPS信号的位置配方来确定位置。因此，基于所应用于策略508的上下文506，选择位置配方200的位置配方200b。如图所示，位置配方200b不包括GPS，因此其符合策略508。

因此，使用如位置配方200b所指定的小区三角测量和无线网络信息，来确定设备502的位置信息510。例如，该设备502的蜂窝功能单元与蜂窝基站进行交互，来查明用于该设备502的基于小区的位置信息。此外，基于该设备502所连接到的无线和/或有线网络(如，宽带网络)，来确定网络位置信息。对位置信息510进行处理，以估计该设备502的位置。响应于位置请求504，向诸如设备502的功能单元和/或其它请求实例返回所估计的位置。

图6根据一种或多种实现，示出了用于对用户进行认证的示例性操作场景600。根据一种或多种实现，场景600包括设备602，后者表示计算设备102的实现。在至少一些实现中，场景600可以表示上面所讨论的场景400和/或场景500的扩展。

在该场景600中，发起认证请求604，例如，由设备602的功能单元和/或设备602外部的功能单元发起。在该特定的例子中，发起认证请求604，以对用于访问受保护资源(例如，企业电子邮件帐户、受保护内容等等)的用户进行认证。

响应于该认证请求604，确定上下文606。在本文的其它地方讨论了不同上下文考量的例子。通常，上下文606包括与该认证请求604有关的状态信息。根据场景600，上下文606指示认证请求604是基于针对访问受保护的企业资源的请求。

继续该场景600，向策略608应用上下文606，以查明将用于认证过程的传感器配方。例如，关于认证而言，传感器可以指代用于输入和/或接收认证信息的各种不同功能单元。策略608可以包括各种类型和/或实例的策略。例如，策略608可以表示上面参照图3所讨论的策略132中的一个或多个(例如，认证策略300)的实现。

在该场景600中，策略608指定不准许用于访问受保护的企业资源的认证目的的一种或多种类型和/或实例的传感器。例如，策略608指定不将生物识别传感器识别成用于企业认证的有效认证传感器。例如，企业实体可以确定某些生物识别传感器是容易欺骗的，因此对于访问受保护的企业资源的认证来说是不被信任的。因此，基于所应用于策略608的上下文606，选择认证配方204的认证配方204a。如图所示，认证配方204a不包括生物识别传感器，因此符合策略608。由于认证配方204b、204c包括生物识别传感器，故认证配方204b、204c不符合策略608，因此不能呈现为用于认证请求604的可用选项。所以，在至少一些实现中，可以将策略使用成过滤器，其使得当响应于针对传感器数据的请求来识别传感器时，将不符合的配方和/或传感器排除在外。

继续该场景600，使用认证配方204a所识别的传感器，对认证信息610进行收集。例如，提示用户向设备602提供用户证书。可以用多种方式来提供用户证书，例如，通过用户名、密码、认证模式(如，基于图像的模式)的触摸和/或键盘输入和/或其它类型的用户证书。如果认证信息610与准许访问受保护资源的用户简档相匹配，则可以准许用户访问该资源。

只是为了举例的目的，给出了这些示例性场景，但应当理解的是，在没有明确示出或讨论的各种各样的其它场景中，也可以使用本文所讨论的技术。在根据本文所描述的技术来描述一些示例性场景之后，现在考虑根据一种或多种实现来讨论一些示例性过程。

示例性过程

下面的部分根据一个或多个实施例，描述用于基于上下文和策略进行传感器选择的一些示例性过程。这些示例性过程可以用于图1的环境100、图10的系统1000和/或任何其它适当的环境之中。在至少一些实施例中，自动地实现针对各种过程所描述的步骤，并独立于用户交互。

图7是根据一个或多个实施例，描述一种方法中的步骤的流程图。例如，该方法描述了根据一种或多种实现来配置传感器集线器的示例性方式。

步骤700定义传感器策略。例如，基于不同的上下文，并针对传感器的不同类型、实例和组合，来定义传感器策略。在至少一些实施例中，可以响应于特定策略参数的用户输入，来定义传感器策略。替代地或另外地，可以基于例如根据用户偏好、系统行为、环境属性等等所推断的参数，来定义传感器策略。当传感器策略是特定于传感器的时，在基于传感器的考量之外，传感器策略可以替代地或另外地基于也应用于系统和行为的通用策略。

步骤702配置传感器配方。如本文其它地方所详述的，传感器配方指定不同类型、实例和/或组合的传感器。例如，配方可以包括单一传感器或者多个传感器的组合。如本文所使用的，术语“传感器”应被广泛地解释成包括能够检测不同的现象(例如，物理现象、系统状态现象、逻辑状态等等)的任何功能单元。

根据各种实现，配置各个配方以检测特定类型的现象。此外，可以定义多种不同的配方以检测特定类型的现象。例如，可以定义多种光检测配方，每一个配方包括用于对于与光有关的现象进行感测的不同类型和/或组合的光传感器。

可以基于传感器配置的改变，来配置和重新配置传感器配方。例如，如果在设备上安装新的传感器，则可以将该传感器增加到现有的配方中。替代地或另外地，可以针对传感器来定义新配方。根据各种实现，传感器配方的配置和重新配置是请求传感器数据的功能单元(例如，操作系统)不可见的。例如，可以经由传感器集线器的配置，并独立于操作系统来配置和重新配置配方。

步骤704将传感器策略和传感器配方作为传感器集线器的一部分来进行部署。例如，传感器集线器可以接收针对传感器输入的请求，并可以基于所应用于传感器策略的请求的上下文，来选择用于提供传感器输入的配方。

图8是根据一个或多个实施例，描述一种方法中的步骤的流程图。例如，该方法描述了根据一种或多种实现来确定是否生成唤醒事件的示例性方式。在至少一些实现中，该方法是上面参照图7所描述的方法的扩展。

步骤800监测传感器输入的指示。例如，传感器集线器120持续处于活动状态，其使传感器集线器120能够接收指示传感器输入的传感器数据。在至少一些实现中，传感器集线器120持续处于活动状态，而系统的其它部件(例如，CPU)处于不活动状态。

步骤802接收用于指示对传感器的传感器输入的传感器数据。例如，传感器集线器120从传感器系统110接收用于指示将传感器输入提供给传感器系统110的传感器112的传感器数据。在至少一些实现中，当系统处于低功率模式时(例如，当CPU和/或GPU关闭或者休眠时)，接收该传感器数据。

步骤804基于输入上下文和传感器策略，对传感器数据进行处理。例如，传感器集线器120查明与传感器输入相关联的上下文(例如，与该传感器输入有关的状态状况)。传感器集线器120向传感器策略应用该传感器数据(例如，传感器输入的类型)以及其上下文。在至少一些实现中，该传感器策略包括：当系统处于不活动状态时所应用的唤醒策略。

步骤806查明该传感器策略是否指示将生成唤醒事件。例如，传感器集线器120基于传感器数据和上下文来评估该传感器策略的规则和/或参数，以确定该传感器策略是否指示：基于该传感器数据和上下文，将生成唤醒事件。例如，传感器策略可以指定将导致唤醒事件的特定类型的传感器输入(例如，触摸输入)，以及不会导致唤醒事件的特定类型的传感器输入(例如，单独的加速计输入)。此外，传感器策略还可以指定：特定类型的传感器输入将会生成唤醒事件的上下文，以及该类型的传感器输入将不会生成唤醒事件的上下文。因此，在一些上下文中，特定类型的传感器输入可能导致将生成唤醒事件，而在其它上下文中，该类型的传感器输入可能不会导致生成唤醒事件。

如果传感器策略指示将生成唤醒事件(“是”)，则步骤808生成唤醒事件。例如，传感器集线器120生成用于指示系统将转换到正常操作模式的唤醒通知。步骤810向系统功能单元传输该唤醒事件。例如，传感器集线器120向功率控制器发送该唤醒事件，使得CPU和/或其它功能单元从不活动状态转换到活动状态。

如果传感器策略指示将不生成唤醒事件(“否)，则该方法返回到步骤800。例如，传感器集线器120不会响应该传感器输入来生成唤醒事件，并继续对额外的传感器输入进行监测。

图9是根据一个或多个实施例，描述一种方法中的步骤的流程图。例如，该方法描述了根据一种或多种实现来代理(broker)传感器数据的示例性方式。在至少一些实现中，该方法是上面参照图7和/或图8所描述的方法的扩展。

步骤900从功能单元接收针对特定类型的传感器数据的请求。例如，传感器集线器120从功能单元接收针对特定类型的传感器数据的请求。可以请求传感器数据的功能单元的例子包括处理功能单元(例如，CPU、GPU等等)、操作系统、应用、服务、设备等等。

步骤902查明该请求的上下文。如本文所讨论的，上下文通常指代与传感器输入有关和/或与针对传感器输入的请求有关的各种状态状况。状态状况可以指代环境状态、设备状态、逻辑状态等等。在至少一些实现中，上下文可以包括用于请求功能单元的标识和/或类型。例如，可以将上下文信息包括成针对传感器数据的请求的一部分。

上下文可以随时间发生改变(例如，响应于状态和/或环境状况的改变)。因此，根据各种实现，当向特定的策略或者策略集合应用动态上下文时，上下文的改变可能导致选择不同的配方。

步骤904将该请求的上下文应用到针对该特定类型的传感器数据的传感器策略。如本文所详述的，传感器策略指定用于与传感器有关的行为的规则和参数，例如，用于提供传感器数据的传感器和传感器配方的选择。根据各种实现，传感器策略可以是特定于特定类型和/或实例的传感器，并且可以指定用于基于不同的上下文来选择传感器的规则和参数。上文讨论了可以使用的不同传感器策略的例子。

在至少一些实现中，可以使用请求的传感器数据的类型来定位要应用的传感器策略。例如，可以将传感器数据类型使用成查询属性来定位相应的传感器策略。例如，考虑功能单元请求计算设备的位置数据。传感器集线器120可以查询应用于位置请求和/或位置传感器的传感器策略，并因此可以定位和使用与位置请求/位置传感器相关的传感器策略，从而为该设备位置请求选择传感器配方。

步骤906基于传感器策略来选择传感器配方。例如，上下文应用于传感器策略，可以指示符合传感器策略的一个或多个传感器类型和/或传感器配方，故可以用于响应于请求来提供传感器数据。如本文所讨论的，传感器配方通常包括：可以提供该特定类型的传感器数据的传感器的一个或多个实例。上文讨论了不同传感器配方的例子。

步骤908实现将该特定类型的传感器数据从识别为传感器配方的一部分的传感器，提供到请求功能单元。例如，传感器集线器120可以通知传感器配方中所指定的传感器系统发送传感器数据。在至少一些实现中，传感器集线器120可以充当为传感器数据路由器，使得传感器集线器120从传感器系统接收传感器数据，随后从传感器集线器120路由到请求功能单元。替代地或另外地，传感器集线器120可以代理从传感器系统到请求功能单元的传感器数据通信，而无需自身对实际传感器数据进行路由。

在至少一些实现中，上面所描述的方法的方面是请求传感器数据的功能单元不可见的。例如，操作系统和/或其它功能单元可以简单地向传感器集线器提交针对特定类型的传感器数据的请求。随后，传感器集线器可以独立于请求功能单元，向相关的传感器策略应用上下文，以识别用于提供该传感器数据的候选传感器配方(例如，如上面参照步骤902、904、906所描述的)。随后，传感器集线器通知该配方中所标识的传感器发送用于请求功能单元的传感器数据。在选择用于提供该传感器数据的特定传感器时，无需涉及请求功能单元，就可以将该传感器数据提供给请求功能单元。因此，基于不同的上下文和不同的传感器策略，可以使用不同的传感器和传感器系统来提供特定类型的传感器数据和/或传感器数据的组合。

在考虑了前述的示例性过程之后，现在考虑讨论可以用于实现本文在一个或多个实施例中讨论的技术的方面的示例性系统和设备。

示例性系统和设备

图10示出了包括示例性计算设备1002的通常位于1000处的示例性系统，其表示可以实现本文所描述的各种技术的一个或多个计算系统和/或设备。例如，上面所讨论的计算设备102可以体现成计算设备1002。例如，计算设备1002可以是服务提供商的服务器、与客户端相关联的设备(例如，客户端设备)、片上系统和/或任何其它适当的计算设备或计算系统。

如图所示的示例性计算设备1002包括彼此之间通信耦合的处理系统1004、一个或多个计算机可读介质1006和一个或多个输入/输出(I/O)接口1008。虽然没有示出，但计算设备1002还可以包括用于将各个部件进行彼此之间耦合的系统总线或者其它数据和命令传送系统。系统总线可以包括不同的总线结构中的任何一个或者其组合，例如，存储器总线或存储器控制器、外围设备总线、通用串行总线和/或使用各种总线体系结构中的任何一种的处理器或局部总线。此外，还可以预期诸如控制和数据线之类的各种其它例子。

处理系统1004表示使用硬件来执行一个或多个操作的功能单元。因此，将处理系统1004示出成包括硬件元件1010，该硬件元件1010可以被配置成处理器、功能模块等等。这可以包括使用硬件实现成专用集成电路或者使用一个或多个半导体形成的其它逻辑设备。硬件元件1010不受形成它们所用的材料或者本文所使用的处理机制的限制。例如，处理器可以包括半导体和/或晶体管(如，电子集成电路(IC))。在该上下文中，处理器可执行指令可以是电子可执行的指令。

将计算机可读介质1006示出为包括存储器/存储设备1012。存储器/存储设备1012表示与一个或多个计算机可读介质相关联的存储器/存储设备容量。存储器/存储设备1012可以包括易失性介质(例如，随机存取存储器(RAM))和/或非易失性介质(例如，只读存储器(ROM)、闪存、光盘、磁盘等等)。存储器/存储设备1012可以包括固定介质(例如，RAM、ROM、固定硬盘驱动器等等)以及可移动介质(例如，闪存、可移动硬盘驱动器、光盘等等)。可以利用如下面所进一步描述的各种其它方式来配置计算机可读介质1006。

输入/输出接口1008表示允许用户向计算设备1002输入命令和信息，以及还允许使用各种输入/输出设备来向用户和/或其它部件或设备呈现信息的功能单元。输入设备的例子包括键盘、光标控制设备(例如，鼠标)、麦克风(例如，用于语音识别和/或语音输入)、扫描仪、触摸功能单元(例如，配置为检测物理触摸的电容式传感器或其它传感器)、相机(例如，其可以使用诸如红外频率之类的可视或者非可视波长将不涉及触摸的移动作为手势进行检测)等等。输出设备的例子包括显示器设备(例如，监视器或投影仪)、扬声器、打印机、网络卡、触觉响应设备等等。因此，可以利用如下面所进一步描述的各种方式来配置计算设备1002，以支持用户交互。

本文可以在软件、硬件元件或程序模块的通常背景下描述各种技术。通常，这些模块包括用于执行特定的任务或者实现特定的抽象数据类型的例行程序、程序、对象、单元、部件、数据结构等等。如本文所使用的术语“模块”、“功能单元”和“部件”通常表示软件、固件、硬件或者其组合。本文所描述的技术的特征是独立于平台的，其意味着这些技术可以在具有各种处理器的各种各样的商业计算平台上实现。

所描述的模块和技术的实现可以存储在某种形式的计算机可读介质上，或者通过某种形式的计算机可读介质进行发送。计算机可读介质可以包括能由计算设备1002进行存取的各种介质。举例而言，但非做出限制，计算机可读介质可以包括“计算机可读存储介质”和“计算机可读信号介质”。

“计算机可读存储介质”可以指代与仅仅的信号传输、载波波形或者信号本身相比，实现信息的持久存储的介质和/或设备。计算机可读存储介质并不包括信号本身。计算机可读存储介质包括利用适合于存储诸如计算机可读指令、数据结构、程序模块、逻辑单元/电路或其它数据之类的信息的方法或技术来实现的硬件(比如，易失性和非易失性、可移动和不可移动介质和/或存储设备)。计算机可读存储介质的例子可以包括，但不限于：RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能光碟(DVD)或其它光存储设备、硬盘、盒式磁带、磁带、磁盘存储或其它磁存储设备、或者其它存储设备、有形介质、或者适合于存储期望的信息并能够由计算机进行存取的制品。

“计算机可读信号介质”可以指代配置为例如经由网络，向计算设备1002的硬件发送指令的信号承载介质。通常，信号介质可以体现计算机可读指令、数据结构、程序模块、或者调制的数据信号(如，载波波形、数据信号或其它传输机制)中的其它数据。信号介质还包括任何信息传送介质。术语“调制的数据信号”意味着其特性中的一个或多个以下面的方式进行设置或改变的信号：对该信号中的信息进行编码。举例而言，但非做出限制，通信介质包括诸如有线网络或直接有线连接之类的有线介质，以及诸如声波、射频(RF)、红外线和其它无线介质之类的无线介质。

如先前所描述的，硬件元件1010和计算机可读介质1006表示以硬件形式来实现的指令、模块、可编程设备逻辑和/或固定设备逻辑，其中在一些实施例中，可以使用该硬件形式来实现本文所描述的技术的至少一些方面。硬件元件可以包括集成电路或片上系统的部件、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、复杂可编程逻辑器件(CPLD)、以及硅或其它硬件设备中的其它实现。在该背景下，硬件元件可以操作成用于执行由硬件元件以及硬件设备(其用于存储要执行的指令，例如，先前所描述的计算机可读存储介质)体现的指令、模块和/或逻辑所定义的程序任务的处理设备。

此外，还可以使用上述的组合来实现本文所描述的各种技术和模块。因此，可以将软件、硬件或程序模块和其它程序模块实现成在某种形式的计算机可读存储介质上体现和/或由一个或多个硬件元件1010来实现的一个或多个指令和/或逻辑。计算设备1002可以被配置为实现与软件和/或硬件模块相对应的特定指令和/或功能。因此，可由计算设备1002作为软件来执行的模块的实现方式，可以至少部分地利用硬件(例如，通过使用该处理系统的计算机可读存储介质和/或硬件元件1010)来实现。所述指令和/或功能可由一个或多个制品(例如，一个或多个计算设备1002和/或处理系统1004)进行执行/操作，以实现本文所描述的技术、模块和示例。

如图10中所进一步示出的，当在个人计算机(PC)、电视设备和/或移动设备上运行应用时，该示例性系统1000实现普适环境以获得无缝的用户体验。当在使用应用、播放视频游戏、观看视频等等时，将服务和应用从一个设备转移到下一个设备时，这些服务和应用在所有三种环境下对于共同的用户体验以基本类似的方式进行运行。

在该示例性系统1000中，多个设备通过中央计算设备来互连。该中央计算设备可以位于所述多个设备的本地，也可以位于所述多个设备的远程位置。在一个实施例中，该中央计算设备可以是通过网络、互联网或者其它数据通信链路连接到所述多个设备的一个或多个服务器计算机的云。

在一个实施例中，这种互连体系结构实现在多个设备之间传送功能单元，以便向所述多个设备的用户提供共同的并且无缝的体验。所述多个设备中的每一个设备可以具有不同的物理要求和能力，并且中央计算设备使用平台来实现体验向设备的传送，其中该体验被裁剪为适应该设备并且对所有设备都是共同的。在一个实施例中，创建目标设备的类，对体验进行裁剪以适应通用类的设备。可以通过设备的物理特征、使用类型或者其它共同特性，来定义设备的类。

在各种实现中，计算设备1002可以假定各种各样的不同配置，例如，用于计算机1014、移动设备1016和电视1018用途。这些配置中的每一种配置包括具有通常不同的构造和能力的设备，因此计算设备1002可以根据这些不同的设备类中的一个或多个进行配置。例如，计算设备1002可以实现成计算机1014设备类，其包括个人计算机、桌面型计算机、多屏幕计算机、膝上型计算机、上网本等等。

此外，还可以将计算设备1002实现成移动设备1016设备类，其包括诸如移动电话、便携式音乐播放器、便携式游戏设备、平板计算机、可穿戴设备、多屏幕计算机等等之类的移动设备。此外，还可以将计算设备1002实现成电视1018设备类，其包括具有或者连接到休闲观赏环境下的通常更大屏幕的设备。这些设备包括电视、机顶盒、游戏控制台等等。

本文所描述的技术可以通过计算设备1002的这些各种配置来支持，并且不限于本文所描述的技术的特定例子。例如，参照传感器系统110和/或传感器集线器120所讨论的功能单元，可以通过使用分布式系统(例如，经由平台1022，在“云”1020上)来全部地或者部分地实现，如下面所描述的。

云1020包括和/或表示用于资源1024的平台1022。平台1022抽象云1020的硬件(例如，服务器)和软件资源的基本功能单元。资源1024可以包括：当在远离计算设备1002的服务器上执行计算机处理时所可以使用的应用和/或数据。此外，资源1024还可以包括在互联网上和/或通过用户网络(如，蜂窝网络或Wi-Fi网络)来提供的服务。

平台1022可以抽象用于将计算设备1002与其它计算设备进行连接的资源和功能。此外，平台1022还可以进行服务以抽象资源的调整，从而提供相应水平的规模来满足对通过平台1022所实现的资源1024的需求。因此，在互连的设备实施例中，本文所描述的功能单元的实现可以分布在整个系统1000之中。例如，该功能单元可以经由对云1020的功能单元进行抽象的平台1022以及在计算设备1002上部分地实现。

本文讨论了可以实现以执行本文所讨论的技术的众多方法。可以利用硬件、固件或软件或者其某种组合，来实现这些方法的方面。将这些方法示出为一组步骤，这些步骤指定由一个或多个设备执行的操作，并且不必限于为了执行相应模块的操作而所示出的顺序。此外，根据一个或多个实现，参照特定方法所示出的操作可以与不同方法的操作进行组合和/或互换。可以经由上面参照环境100所讨论的各种实体之间的交互，来实现这些方法的方面。

结论

虽然以特定于结构特征和/或方法动作的语言，描述了示例性实现，但应当理解的是，所附权利要求书中定义的实现方式并不必限于所描述的特定特征或动作。相反，这些特定的特征和动作只是公开成实现所主张的特征的示例性形式。

Claims (10)

1.一种可操作用于导致生成针对计算设备的中央处理单元(CPU)的唤醒事件的系统，所述系统包括：

传感器系统，其中每一个传感器系统都包括一个或多个传感器；以及

传感器集线器，其可操作地连接到所述传感器系统，并被配置为独立于所述CPU来接收和处理来自所述传感器系统的传感器输入，所述传感器集线器进一步被配置为执行包括以下各项的逻辑：

传感器配方，其中每一个传感器配方都定义所述传感器系统中的一个或多个传感器系统的集合，所述传感器配方中的至少一个传感器配方包括来自不同传感器系统的传感器；

传感器策略，其指定用于基于特定的上下文来确定将使用所述传感器配方中的哪一个传感器配方来提供传感器输入的参数；以及

指令，其由所述传感器集线器可执行以执行包括以下各项的操作：当所述CPU处于低功率模式时，接收用于指示对所述传感器系统中的一个或多个传感器系统的传感器输入的传感器数据；以及基于所述传感器策略中的一个或多个传感器策略，对所述传感器数据进行处理以导致生成所述唤醒事件，从而将所述CPU从所述低功率模式唤醒。

2.如权利要求1所述的系统，其中，所述传感器集线器是实现为片上系统(SoC)的至少一部分的。

3.如权利要求1所述的系统，其中，所述传感器集线器被配置为：当所述CPU处于关闭模式时，执行所述逻辑。

4.如权利要求1所述的系统，其中，所述传感器集线器进一步被配置为执行逻辑，以执行包括以下各项的操作：

查明来自功能单元的针对特定类型的传感器数据的请求的上下文；以及

向所述传感器策略中的一个或多个传感器策略应用所述请求的所述上下文；以及

基于所述上下文向所述传感器策略中的所述一个或多个传感器策略的应用，选择所述传感器配方中的至少一个传感器配方，其中，所述传感器配方中的所述至少一个传感器配方指定将使用的以提供所述特定类型的传感器数据的一个或类型的传感器。

5.如权利要求4所述的系统，其中，所述操作还包括：

识别与用于提供所述特定类型的传感器数据的所述一个或类型的传感器相对应的所述传感器系统中的一个或多个传感器系统；以及

将所述特定类型的传感器数据从所述传感器系统中的所述一个或多个传感器系统路由到所述功能单元。

6.如权利要求4所述的系统，其中，所述操作是独立于所述CPU来执行的。

7.一种独立于计算设备的主处理装置可操作的传感器集线器，所述传感器集线器包括：

至少一个处理单元；以及

存储在所述传感器集线器上的指令，其由所述至少一个处理单元可执行，以执行包括以下各项的操作：

从所述计算设备的功能单元接收针对特定类型的传感器数据的请求；

查明针对传感器数据的所述请求的上下文；

向一个或多个传感器策略应用所述请求的所述上下文以选择传感器配方，其中所述传感器配方指定将用于提供所述传感器数据的一个或类型的传感器，所述应用是独立于所述计算设备的所述主处理装置来执行的；以及

导致所述特定类型的传感器数据从所述一个或多个传感器提供到所述计算设备的所述功能单元。

8.如权利要求7所述的传感器集线器，其中，所述计算设备的所述功能单元包括：在其上安装所述传感器集线器的所述计算设备的操作系统(OS)，并且其中，所述传感器集线器被配置为独立于所述OS来选择所述传感器配方，并识别与所述一个或多个类型的传感器相对应的一个或多个传感器系统。

9.一种独立于计算设备的主处理装置可执行的计算机实现的方法，所述方法包括：

从所述计算设备的功能单元接收针对特定类型的传感器数据的请求；

查明所述请求的上下文，其中所述上下文包括关于所述请求的一个或多个状态状况；

向一个或多个传感器策略应用针对所述特定类型的传感器数据的所述请求的所述上下文，以识别传感器配方，其中所述传感器配方指定将用于提供所述特定类型的传感器数据的一个或多个传感器，所述应用是独立于所述计算设备的所述主处理装置来执行的；以及

导致所述特定类型的传感器数据从所述一个或多个传感器提供到所述计算设备的所述功能单元。

10.如权利要求9所述的计算机实现的方法，其中，所述功能单元包括操作系统(OS)，并且其中，所述查明和所述应用是独立于所述OS来执行的。