服务的客户端侧集成框架的制作方法

文档序号:12290021阅读:170来源:国知局
服务的客户端侧集成框架的制作方法与工艺

使用移动计算设备的一个方面在于该设备包括以及用户将安装各种app来执行一个或多个服务。通常来说,“app(小应用)”是针对于执行某一任务或者有关任务的小型集合的小型、特殊软件程序。很多时候,移动设备上的app的集合表示来自多个供应商的程序。此外,每一个app通常被设计为独立于其它app或应用进行操作,因此将维持其自己的用户数据集合(包括个人信息的与设备用户有关的数据)。

除了移动计算设备之外,个人/用户拥有和/或使用其它计算设备是非常普遍的。例如,在一天的日程之中,用户可能使用他或她的智能电话以及一个或多个其它计算设备(如,平板计算机、膝上型计算机、游戏控制台和桌面型计算机)。这些设备中的每一个设备(每一个均是计算设备)具有彼此不同的能力,并具有至少一些在所有其它设备上没有安装的app和/或应用,尽管在一些设备或所有设备之间也可能存在某些重叠的app。此外,这些计算设备中的每一个都存储和/或维持关于用户的个人信息(密码、偏爱、人口统计信息、帐户信息、位置等等)。

虽然app的集合可以为了用户的利益而提供特征/服务的健壮的集合,但用户通常是这些服务和这些app中的每一个所提供的内容的集成点。但是,越来越多的用户对于使他们的计算设备(或者计算设备集)理解他们自己变得感兴趣,并基于这种理解,提供针对于他们的特定需求和上下文而裁剪的个性化的辅助。



技术实现要素:

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

根据所公开的主题的方面,提供了用于提供对app和服务的客户端侧集成的系统和方法。在计算设备上执行的集成框架,提供各种app、应用、服务、传感器等等的集成。在接收到针对一个服务的请求时,集成框架访问在该集成框架中注册的相应多个提供者的多个服务的注册表。在集成框架中注册的每一个服务,都与信任级别的层次结构中的一个信任级别相关联。集成框架根据信任级别的层次结构,针对请求的服务的提供者,对注册表进行反复地搜索,其中该搜索以信任级别中的最受信任级别开始,到较不受信任的信任级别的顺序进行开始,直到发现所请求的服务的提供者为止,或者直到搜索了该层次结构的所有级别而没有发现所请求的服务的提供者为止。

附图说明

当结合附图进行考虑时,前述的方面以及所公开的主题的多个附带优点将变得能更容易理解,如通过参照下面的描述所更好理解的,其中:

图1示出了适合于实现所公开的主题的方面的示例性网络环境;

图2示出了在计算设备上执行的用于提供app和服务的客户端侧集成的各种组件和处理;

图3示出了移动计算设备上的app和服务的信任级别和执行顺序;

图4描绘了用于示出个人信息安全与增加的个性化(随着访问个人信息的相应数量的增加)的关系的图表;

图5根据所公开的主题的方面,示出了用于执行app和服务的示例性例程的流程图;

图6根据所公开的主题的方面,示出了用于与客户端侧集成框架进行交互的示例性例程的流程图;

图7示出了用于将app和服务集成到客户端侧集成框架的层次结构中的示例性例程的流程图;

图8是一个流程图,其示出了用于评估是否使用外层的服务(即使该服务可从最受信任的级别获得)的示例性例程;以及

图9示出了适合于实现所公开的主题的方面的示例性移动计算设备的框图。

具体实施方式

为了清楚说明起见,本文档中的术语“示例性”应当被解释成作为某事情的说明或示例,不应被解释为该事情的理想和/或主要说明。术语“个人信息”对应于相关联的用户的信息、数据、元数据、偏好、行为、以及用于与用户交互的规则。通常来讲,个人信息是关于相关联的用户的用于表示该用户的某个方面的信息。个人信息可以包括诸如(通过示例而不是限制的方式)性别、年龄、教育、人口统计数据、居留权、公民身份等等之类的数据。个人信息还可以包括偏好和兴趣、专业知识、能力等等。另外,个人信息可以包括用于在提供个人助理时,与相关联的用户进行交互的规则(其包括相关联的用户建立的规则以及通过如下所描述的分析来学习和/或推断的规则)。

如上面所提及的,术语“app”通常指代针对于在计算设备上执行任务或者有关的任务的小型组合的的小型、特殊软件程序。App可以预先安装在计算设备上,或者按照计算设备的用户的指示来安装。术语“应用”指代在计算设备上执行一个或多个任务的软件程序。通常,与app相比,应用在范围上是更广阔和健壮的,但app和应用均是软件程序。由于app和应用均是软件程序,并且均安装在适合于实现所公开的主题的方面的计算设备上,因此为了便于术语的简短起见(除非专门标识为相反情形),后续对于术语“app”的引用应当被解释成涵盖app和应用。

如下面所讨论的,集成框架对app和传感器进行集成,它们均本地布置在计算设备上,以及在其它设备(例如,兄弟设备)上可用的那些。当然,app和传感器、设备等等可以各自提供数据、流、功能、活动等等。为了便于说明本公开内容起见,在集成框架中注册的各个app、传感器、设备等等的数据、数据流、功能、特征、活动,将称为提供者(app、传感器、设备等等)所提供的服务(数据、流、功能等等)。

提供个性化助理的一种解决方案是部署在线服务,其中该在线服务可以通过使用很大数量的计算机和/或处理器(它们收集、存储、整理、分析和操纵从世界各地收集的很大量的数据),向大量的用户提供个性化的辅助。在该整体模型中,用户的各个计算机上的所有app依赖于该整体在线服务来提供该用户期望的服务。通常,用户(希望接收个性化帮助的那些人)经由app向在线服务订阅个人信息的各个项,并准许在线服务对该用户的生活的众多方面进行监测,以尽可能了解关于他们的个人信息。对用户可能采取的几乎每一个活动(尤其是关于他们的计算机)进行捕获和分析,以识别另外的个人信息;这些活动包括但不限于在线行为、购买、偏好、隶属关系、银行信息等等。随后,在线服务基于其收集和维持的用户的积累的个人信息,使用其计算能力来提供个性化辅助。

运行如上所述的大量的整体在线服务是昂贵的。为了保持这种大型在线服务的操作性,在线服务必须具有收入来源。另一方面,订户/各个用户想要免费地获得他们的个性化帮助。不是针对于个性化服务来直接向用户收取费用,而是整体在线服务通过对其用户的个人信息进行增值,来获得其收入来源。对应于该增值的常用短语是“广告资助”或者“供应商资助”。在线服务通过识别其用户之中具有各种特点、兴趣、人口统计和属性(如根据在线服务接收和了解的其用户的个人信息所确定的)的个体,并代表广告商向这些个体投放广告来对所识别的信息进行金钱化,从而对其用户的个人信息进行增值。当然,针对于用户来销售广告仅是整体在线服务(如上所述)可以对其用户的个人信息进行金钱化的一种方式。替代地,在线服务可以简单地销售联系人列表和/或信息。当然,销售关于用户的联系人列表和/或信息,提出了关于个人的隐私担忧的问题。

用户通常很高兴获得“免费”的个性化辅助,所以他们会容忍频繁呈现给他们的这些广告。此外,他们大多不知道在线服务拥有他们的多少个人信息并将其金钱化/暴露给第三方(例如,广告商、供应商、组织机构等等),并且他们可能会对此极不舒服。当然,在线服务可以告诉其用户这不会对其造成伤害来进行安抚,但在线服务是冲突的:在线服务通过向第三方提供其用户的个人信息来获得收入(无论是通过广告、销售联系人列表等等)。此外,提供给第三方的个人信息越具体,在线服务获得的货币报酬也越大。不幸的是,暴露的个人信息越具体,对于滥用该人员或者人群的被暴露个人信息的风险及潜在性就越大。

当然,即使不考虑向已知的第三方(其可能有显示用户的个人信息的约束,也可能没有)暴露个人信息的风险,频繁和不幸的场合示出,通过简单地存储大量的用户/订户所对应的大量个人信息,在线服务为身份窃贼产生了一个邀请、诱人的目标。所以,当个性化辅助的水平直接与知道的人员的个人信息的数量有关时,该人员的个人安全(如暴露风险或者滥用个人信息所带来的)也取决于在线服务所拥有的该人员的个人信息的量。如图4中所示,虽然理想情况是具有较高的个人安全(即,个人信息的安全)和较高的个性化,但整体在线服务的现实情况是随着个性化水平的增加,(关于一个人的个人信息的)个人安全的水平也降低。

与整体在线服务相比,并根据所公开的主题,在个人的自己计算设备(或者一些计算设备)上操作的个人守护进程,在2014年2月24日提交的标题为“Local Personal Daemon”的相关美国专利申请#14/187567中进行了阐述。如该相关申请中所阐述的,通过规定的方式,“守护进程”是在计算设备上运行的线程或者执行的进程,其是在计算设备的后台中执行的,而不是在计算机用户的直接控制之下执行。但是,当守护进程在计算设备的后台中运行时,计算机用户可以与守护进程进行交互,并通过该交互,指示守护进程的活动。此外,“个人守护进程”是在提供个性化辅助中访问、获取、推断、维持和操作计算机用户的个人信息的守护进程。个人守护进程对相关联的用户的活动的众多方面进行监测,以识别、推断和/或了解关于该用户的另外个人信息(当可获得时),以及推断和了解用于代表该用户进行动作(即,向该用户提供个性化帮助)的规则。另外,个人守护进程可以通过对话框和与用户的其它交互(其包括对先前推导的关于该用户的推论进行确认,请求用户偏好和其它个人信息等等),来了解和/或确认关于该用户的个人信息,特别是关于推断的信息和/或用于代表该用户进行动作的规则。“本地个人守护进程”是“本地”(即,在用户的计算设备上)执行的个人守护进程。由于本地个人守护进程在用户的计算设备上执行,但访问网络上的服务和信息,因此说本地个人守护进程是“在云的边缘上”操作。为了便于说明本公开内容起见,“个人守护进程”和“本地个人守护进程”应当被视作为是同义词。

在个人守护进程向相关的用户提供个人辅助的背景下,短语“个人助理”应当被解释成代表用户来执行一个或多个动作。通常,尽管不是专门的,但个人助理由与用户的当前背景的方面有关的一个或多个事件来触发。举例而言而非做出限制,个人助理的一个或多个动作可以包括:向用户提供采取某个特定动作的建议;代表用户获得数据和/或服务;根据用户的活动的分析,向用户确认个人信息的推论;代表用户来确认个人守护进程采取某个动作的用户授权;向用户提供关于一个或多个事件的通知;提供针对当前用户活动的替代;推荐场地;代表用户在计算设备上执行某个动作;推荐替代的和/或有关的活动或者项;等等。不同于对其用户的个人信息进行收集和增值的整体在线服务选项,除了该用户建立的规则和指示之外,以及根据这些规则和指示,个人守护进程并不与其它第三方共享相关联的用户的个人信息。

根据所公开的主题的方面,在用户的计算设备上执行的个人守护进程,变成在用户的计算设备上可用的各种服务或者通过用户的计算设备可获得的各种服务的集成点。该计算设备包括客户端侧集成框架,其中个人守护进程依赖该框架来向与该计算设备相关联的用户提供个性化帮助。如本领域普通技术人员所理解的,在该背景下,“框架”是提供特定的功能集的可执行处理和服务(其可在计算设备上执行)的集合。在本公开内容的情况下,该功能是服务的集成,其中这些服务包括本地服务以及并不位于本地计算设备上的那些服务。该集成框架是“客户端侧”集成框架,这是由于其实现在用户的(即,客户端的)计算设备上,而不是实现在云中的远程设备上,尽管集成框架可以与远程源进行协作并从其获得服务。一个这种客户端侧集成框架是在“Local Personal Daemon”专利申请中所讨论的On{Event}框架。根据所公开的主题的方面,以及如下面所进一步详细讨论的,该集成框架实现“本地第一”模式来获得服务。

现转到图1,图1是示出适合于实现所公开的主题的方面的示例性网络环境100的框图。如图所示,网络环境100包括一个或多个用户计算设备102-106。这些用户计算设备中的至少一些(例如,与用户101相关联的用户计算设备102)适合于被配置为托管个人守护进程和相应的集成框架。如本领域普通技术人员所容易理解的,通过示例的方式而不是限制的方式,适当的用户计算设备包括:平板计算设备;诸如计算设备102之类的智能电话设备;所谓的“phablet”计算设备(即,跨越典型的平板计算设备和智能电话设备的功能的计算设备);膝上型计算机;桌面型计算机;可穿戴计算设备;个人数字助理;游戏控制台等等。

此外,网络环境100还包括网络110,其中用户计算设备102-106通过该网络进行通信,访问分布在该网络之中的网络可访问设备和/或服务。例如,如图1中所示,网络服务提供者112-116也通信地连接到网络110。网络服务提供者是向其它人(其包括诸如用户101之类的用户)提供一个或多个服务的在线服务(由计算设备来支持)。通过示例的方式而不是限制的方式,这些网络服务提供者112-116包括:诸如网络服务提供者116之类的社交网络服务提供者;诸如搜索引擎114之类的搜索引擎;诸如业务信息提供者112之类的业务信息提供者;新闻服务(没有示出);天气服务(没有示出);在线游戏服务(没有示出);银行服务(没有示出)等等。事实上,似乎可以从在线服务获得期望的任何类型的服务(无论是收费的,还是免费的)。

根据所公开的主题的方面,如下面所进一步详细讨论的,将具有集成框架的用户计算设备(例如,用户计算设备102)实现成“云的边缘”设备,其意味着当发生本地处理时,计算设备可以通过网络110,从其它计算设备和网络服务提供者获得服务。

本领域普通技术人员应当容易理解的是,很多用户具有/使用一个以上的计算设备。事实上,通过示例的方式,通常用户具有智能电话以及平板计算设备、膝上型计算机和/或桌面型计算机。因此,根据所公开的主题的方面,在计算设备(例如,计算设备102)上操作的个人守护进程可以被配置为:与类似配置的“兄弟计算设备”(即,与同一用户相关联的计算设备,其每一个都配置在集成框架中),共享关于相关联的计算机用户101的个人信息。例如,用户计算设备102-104可以是计算机用户101的兄弟计算设备。如下面所进一步详细讨论的,在兄弟计算设备上的集成框架中注册的服务享受某个级别的信任,从而使得这些服务通常比可从其它源获得的服务更优选。

关于适当的用户计算设备的配置而言,图2示出了在适当配置的用户计算设备(例如,用户计算设备102)上托管的,用于提供app和服务的客户端侧集成的各种组件和处理的图200。用户计算设备102包括一个或多个app或服务,例如,在该计算设备上执行(或者可执行)的app 202-210。在计算设备102上的app之中包括:代表相关联的用户101来执行的个人守护进程206。

此外,集成框架220在适当配置的用户计算设备102上执行。集成框架220是可扩展事件/动作框架,即,该框架检测关于一个或多个传感器(例如,示例性传感器222-232)或服务的事件的发生,并作为响应,在用户计算设备上执行与所检测的事件相关联的一个或多个动作。传感器222-232对应于用户计算设备上的硬件传感器,例如,地理传感器、加速计、定时器、网络事件传感器、电源传感器、处理器负载传感器、光和声传感器等等。当然,app和服务202-210还可以注册成软件传感器,其在于:它们基于诸如签到、喜欢、文本消息等等之类的某种准则来生成事件。集成框架220是可扩展的,其在于:可以在该框架中增加/注册包括软件传感器的传感器,将动作作为服务来增加和/或删除;并且其它app和应用(其包括集成框架220)可以订阅这些传感器感测的事件。因此,虽然没有示出,但集成框架220包括订阅界面以及发布界面,其中一个或多个app或者应用可以通过订阅界面来订阅这些传感器的服务,并且服务的提供者(app、应用、传感器、设备等等)可以通过发布界面来向集成框架“发布”所提供的这些服务,以及如何调用该服务。此外,集成框架220还包括输入界面,各个传感器/服务222-232可以通过输入界面来向框架发送通知。除了上面所提及的服务的提供者之外,集成框架220还可以使用其它不太传统的提供者,其包括脚本、计算图和/或现有提供者上的业务流程。

关于集成框架220的可扩展性而言,应当理解的是,app(或应用)和服务可以在该集成框架中进行注册,以订阅来自其它传感器、服务和/或app的事件。在接收到对订阅的事件的通知时,进行订阅的app和服务可以随后使用来自订阅源的信息来生成另外的数据和/或功能。当然,这些进行订阅的app和服务可以发布它们通过集成框架220生成的数据、服务和/或功能,使得其它app也可订阅它们的服务。简而言之,app(或应用或服务)可以在集成框架220中注册成其它app和服务的服务/数据/功能的消费者,还可以注册成可以由其它服务和app进行使用的服务或数据或功能的发布者/生产者。

在所公开的主题的各个实施例中,作为设计实现特征,当app(或服务)作为另一个app(或者传感器或服务)的消费者进行订阅时,集成框架220可以对进行订阅的app提供用于接收所订阅的服务的信息和/或能力,而无需再进一步涉及集成框架220。当然,在替代的实施例中,集成框架220可以提供生产服务和消费服务之间的“链接”方面。

订阅/消费服务可以订阅用于提供特定的服务(或者数据或功能)的生产服务的全部或者特定的一些。例如,订阅服务或app可以订阅传感器以及发布服务,其中传感器用于检测/报告本地计算设备上的电池的当前功率电平,发布服务用于消费该传感器的数据,并生成关于以下的详细信息:在给定当前功率电平的情况下,本地计算设备可以继续按照当前处理水平进行操作多长的时间。在集成框架220下,app可以订阅具体的生产服务/app,或者替代地,根据期望的数据/服务/功能的类型来订阅一组生产服务/app。

根据所公开的主题的方面,在计算设备102上可用的传感器和服务222-232(其包括硬件和软件传感器和服务)被注册在集成框架220中。App、设备或者传感器的注册包括:向集成框架通知该注册的实体所提供的服务(或者服务集)的本质,向框架通知可以由该框架进行触发和接收的事件的本质。如上面所指示的,集成框架220中的注册向框架通知如何与服务的提供者进行通信,使得其可以被调用以提供该服务。通过注册表中的信息,其它app、应用或服务可以看到在整个系统上提供的数据和/或服务,并且订阅由该注册的服务/传感器所生成的事件(或者事件集),或者可以执行该注册的app/应用/传感器以从其服务和数据中获益。充当为用于相关联的用户的各种app和服务的集成点的个人守护进程206,订阅集成框架220的app和服务来向用户提供个人辅助。

根据所公开的主题的方面,服务在集成框架220中的注册被视为将服务安装在计算设备上的处理的一部分。根据一个实施例,在集成框架220中的注册可以根据与服务相关联的表现来发生。替代地,服务可以被配置为:作为初始化/安装过程的一部分,与集成框架来传输其注册信息。替代地,在安装了服务之后,集成框架220可以被配置为咨询注册信息的全局列表。在替代的实施例中,相关联的用户可以手动地向集成框架220增加服务的注册信息。

根据所公开的主题的方面,除了存储关于每一个提供者的服务的信息之外,在集成框架中注册的每一个服务与信任级别的层次结构中的信任级别相关联。该信任级别通常指示相关联的用户关于该服务的信任。转到图3,本地服务(即,位于具有集成框架220的计算设备上的那些服务)通常与最高级别的信任相关联,在图3中将其特征化为“我(me)”级别302。如已经所提及的,没有位于本地设备上的服务也可以注册在集成框架220中。事实上,兄弟计算设备上的服务占据类似较高的信任级别(第二最受信任的级别),在图3中指代为“我的”级别304。相关联的用户认为信任的那些服务(例如,来自于该用户是其成员,或者授权相关联的用户进行访问的网络上的设备的服务),可能符合减少的信任级别、第三最受信任的级别,其在图3中指代为“我们的”级别306。可用于计算设备102上的集成框架220,但并不必需与更高级别的信任相关联的那些服务,通常包括在最低级别的信任之中,其在图3中指代为“其它”级别308。

根据所公开的主题的方面,当集成框架220接收到针对服务的请求时,集成框架通常尝试利用最受信任的服务(即,其位于“我”信任级别之中)来满足请求。如果在最受信任级别中没有发现匹配服务,则集成框架220通常连续地查看外层以满足该请求,如通过箭头312所指示的。当然,有时从不位于本地计算设备上的服务提供者获得服务是有利的(尽管该服务在本地设备上可获得)。例如(通过示例的方式,而不是限制的方式),如果电池电量较低,并且已知特定的服务将消耗大量的能量,则从不同于本地计算设备的计算设备获得该服务是有利的。类似地,在判断是从本地计算设备上的提供者/传感器获得服务(那些“我”信任级别302的服务),还是从外部信任级别获得该服务(特别地,位于“我的”信任级别304中)时,可以考虑全部的处理可用性和容量、存储器约束、数据可用性、网络带宽、网络连接速率、一天中的时间等等。

此外,图3中还示出了ad hoc(自组网)信任级别310。根据所公开的主题的方面,为了相互通信、向其它设备提供数据等等的目的,用户可以临时地与另一个设备建立ad hoc网络(例如,两个移动设备之间的临时网络)。因此,集成框架220可以在该连接的持续时间期间,临时地将“ad hoc”信任级别310与该ad hoc网络上的设备的app/服务/传感器进行关联。当然,虽然图3中的ad hoc级别310示出了“ad hoc”级别310位于“我的”级别304和“我们的”级别306之间,但这只是用于说明目的,而不应被视作为关于所公开的主题进行限制。给予“ad hoc”级别310的信任级别可以可配置地放置在信任级别层次结构的其它位置中,也可以手动地由相关联的用户来确定。

根据所公开的主题的各个实施例,虽然上面关于图3的段落描述了集成框架220如何寻求来自外部计算设备的服务(当它们不可用于本地计算设备时(或者没有在本地计算设备上切实执行时)),但集成框架中的消息并不发送给这些其它计算设备。通常来讲,当集成框架220根据感测的事件或信号来寻求获得来自远程设备的服务时,调用专用于与远程设备进行通信的一个或多个服务,来向远程设备提交针对该服务的请求。

针对上面关于图3所讨论的模式来说,虽然可以在用户自己的移动计算设备上有利地实现以“我”级别来开始定位服务,并根据信任级别来向外延伸,但有时也可以授权不同的策略。例如,家长可能希望了解或者控制在孩子的移动计算设备上可用的各种特征。在这些环境中,根据家长为孩子所建立的策略,可以改变寻找服务的顺序:例如,家长可以识别被认为是最受信任的各种服务(在本地计算设备的那些之上),家长可以对于集成框架220会寻求所请求的服务的地方的信任级别进行限制等等。当然,商业上还可能希望实现用于他们向他们的雇员提供的移动设备的策略。

现转到图5,图5根据所公开的主题的方面,示出了用于获得服务的示例性例程500的流程图,例如其可以由用户的移动计算设备102上的集成框架220来实现。开始于方框502处,从注册在集成框架220中的服务的提供者接收针对服务的请求。在方框504处,以本地服务开始(即,最受信任的信任级别(“我”信任级别302)中的服务),搜索满足该请求的提供者/服务。在方框506处,针对能满足该请求的注册服务,对当前级别(初始时以最受信任级别来开始)进行搜索。在判断框508处,判断在当前信任级别上是否发现该服务。如果没有,则例程500转到判断框412处,如下面所描述的。但是,如果发现所请求的服务(即,其可以由处于当前级别的提供者来完成),则例程500转到方框510处,向所发现的该服务的提供者发出指令。其后,例程500终止。

在判断框512处,判断是否存在用于搜索服务的另一个更低的信任级别。如果没有,则其意味着所请求的服务是不可用的,则在方框514处,该例程返回没有找到所请求的服务的指示。替代地,如果存在要搜索的另一个级别,则例程500转到方框516处,选择下一个信任级别(如上面参照图3所描述的),并且该处理返回到如上所述的方框506。

现转到图6,图6根据所公开的主题的方面,示出了用于与客户端侧集成框架进行交互的示例性例程600的流程图,例如,可以由个人守护进程进行。开始于方框602处,提交关于在集成框架中注册的app或服务的服务信息的请求。在方框604处,接收关于该服务的信息。在判断框606处,判断所请求的服务信息是否标识当前可用(替代地,该服务是不可用的)。如果是,该例程转到方框608处,向所识别的服务提交请求。其后,例程600终止。

图7示出了用于将服务集成到客户端侧集成框架220的层次结构中的示例性例程700的流程图。开始于方框702处,集成框架220接收关于服务(或者app或传感器,经由如上面所讨论的输入接口)的信息。在方框704处,集成框架220确定信任级别的层次结构中的一个信任级别与该服务相关联。如上面所指示的,这些信任级别可以对应于该服务是否在本地设备上、在兄弟设备上、在受信任的设备网络上、在ad hoc网络上,或者相反。在方框706处,使用该信息(其包括相关联的信任级别),对集成框架220的注册表进行更新。其后,例程700终止。

针对上面在图5中关于例程500的方框510所讨论的评估而言,图8是示出一种示例性例程800的流程图,该例程800用于评估是否使用外层的服务(即使该服务可从更受信任的级别(例如,本地计算设备上)获得)。开始于方框802处,判断在当前级别(其可以对应于最受信任的级别,例如,在本地计算设备上)处可用的服务,是否还在信任层次结构中的另一个级别处可用。如果没有,则在方框804处,使用当前级别处的服务,例程800终止。但是,如果该服务在外部信任级别处可用,则例程转到方框806处。

在方框806处,对于关于外部级别的服务的使用的各种标准进行评估。如上面所指示的,这些标准可以包括(通过示例的方式,而不是限制的方式):当前计算的电池电量是否较低;是否已知特定的服务消耗大量的电量;另一个计算设备和本地计算设备的处理可用性和容量;存储器约束;本地计算设备与另一个计算设备相比的数据可用性;当前设备的网络带宽容量;本地计算设备的网络连接速率;一天中的时间;数据安全问题等等。基于该评估(或者一些评估),在判断框808处,判断是否使用外层的服务。如果不使用,则例程800返回到方框804,返回用于说明将使用当前级别处的服务的指示,其后例程800终止。替代地,在方框810处,返回将使用当前级别的(信任层次结构中的)外层处的服务的指示。其后,例程800终止。

关于上面所描述的各种例程和处理而言,虽然通过用于完成各种任务的分离步骤来表达这些例程/处理,但这些步骤也应当视作为在本质上是有逻辑的,其可以对应于或者不对应于特定实现的任何实际和/或分离步骤。在各个例程中呈现这些步骤的顺序,不应被解释为执行这些步骤的唯一顺序。此外,虽然这些例程包括所公开的主题的各种新颖特征,但在运行这些例程时,也可以执行(没有列出的)其它步骤。此外,本领域普通技术人员还应当理解,这些例程的逻辑步骤可以组合在一起,或者包括多个步骤。可以并行地或者串行地执行例程500-800的步骤。通常(但不是排外地),利用在如参照图8所描述的计算设备上执行的软件(例如,应用、系统服务、库等等),来体现各个例程的功能。在各个实施例中,还可以利用计算机系统上的硬件模块(包括但不限于片上系统、专门设计的处理器和/或逻辑电路等等),来体现各个例程中的全部或者一些。

通常,利用包括例程、功能、循环结构、选择符(如,if-then和if-then-else语句)、分配、算术运算等等的可执行代码,来实现这些例程/处理。这些例程中的每一个的精确实现,是基于包括以下各项的各种实现配置和决策:编程语言、编译器、目标处理器、操作环境和链接。本领域普通技术人员应当容易理解,在这些例程中标识的逻辑步骤可以利用任意数量的方式来实现,因此,上面所阐述的逻辑描述足够使得能实现类似的结果。

虽然利用应用(其还称为计算机程序)、app(小型的、通常单一或者缩窄目的的应用)和/或方法来体现的例程,对所公开的主题的很多新颖方面进行表达,但这些方面也可以体现成由计算机可读介质(其还称为计算机可读存储介质)进行存储的计算机可执行指令。如本领域普通技术人员所认识到的,计算机可读介质可以托管用于稍后获取和执行的计算机可执行指令。当执行计算机可读存储设备上保存的计算机可执行指令时,它们执行各种步骤、方法和/或功能(其包括上面关于各种例程来描述的那些步骤、方法和例程)。计算机可读介质的例子包括但不限于:诸如蓝光光碟、数字视频光碟(DVD)、激光光碟(CD)、光盘盒等等之类的光存储介质;包括硬盘驱动器、软盘、磁带等等的磁存储介质;诸如随机存取存储器(RAM)、只读存储器(ROM)、存储器卡、拇指驱动器等等之类的存储器存贮设备;云存储(即,在线存储设备)等等。但是,为了说明本公开内容起见,计算机可读介质明确地不包括载波波形和传播信号。

图9示出了适合于实现所公开的主题的方面的示例性移动计算设备的框图。该示例性移动计算设备900包括通过系统总线910的方式来相互连接的处理器902(或者处理单元)和存储器904。应当容易理解的是,存储器904通常(但不始终)包括易失性存储器906和非易失性存储器908。只要易失性存储器906被供电,其就保持或者存储信息。相比而言,即使当电源不可用时,非易失性存储器908也能够存储(或者保持)信息。通常而讲,RAM和CPU高速缓存是易失性存储器906的例子,而ROM、固态存储器设备、存储器存贮设备和/或存储器卡是非易失性存储器908的例子。

处理器902执行从存储器904中获取的指令,以执行各种功能,特别是关于执行用于向相关联的用户提供个人辅助的个人守护进程206。处理器902可以包括各种商业可用的处理器中的任何一个,例如,单处理器、多处理器、单核单元和多核单元。此外,本领域普通技术人员应当理解,可以利用其它计算机系统配置(其包括但不限于:个人数字助理、可穿戴计算设备、智能电话设备、平板计算设备、phablet计算设备、膝上型计算机、桌面型计算机等等)来实施所公开的主题的新颖方面。

系统总线910提供用于移动设备的各个部件进行相互通信的接口。系统总线910可以具有几种类型的总线结构中的任何一种,其中这些总线结构可以将各个部件(其包括内部部件和外部部件)相互连接在一起。此外,计算设备900还包括网络通信部件912,以便将计算设备900与其它网络可访问计算机、在线服务和/或网络实体以及计算机网络110上的其它设备相互连接在一起。网络通信部件912可以被配置为经由有线连接、无线连接或二者,通过网络110来与各种计算机和设备进行通信。

此外,计算设备900还包括可执行app/应用916。如本领域普通技术人员所理解的,应用对应于在计算设备(例如,计算设备900)上执行(通过其在处理器上的执行)一个或多个任务的可执行指令的集合。通常(但并不是排外地),在计算设备的用户的指示之下执行应用。在执行各项任务(如通过应用的复合所设计的)时,应用将计算设备上可用的特征组合在一起。虽然有时将术语“apps”使用成应用的速记名称,但替代地,app类似于对应于用于执行一个或多个任务的可执行指令的集合。但是,与应用相比,app通常(但不是排外地)针对于有限集合的任务,而这些任务通常聚焦于缩小的主题/特征。由于与应用的范围相比,app的范围通常更加受限,因此关于系统资源而言,app通常需要更小的内存占用,并通常适合于由有限资源的计算设备来执行。虽然app/应用918通常存储在存储器904中,但仅仅为了说明目的,可以从存储器904中单独地调用它们。

此外,示例性计算设备900还包括传感器918。通常,传感器对应于:对于与计算设备900有关的特定事件进行感测的各种硬件设备。通过示例的方式,而不是限制的方式,传感器918可以包括:加速计、触觉传感器、电容式传感器、音频传感器、光传感器、定时器、温度传感器、电源传感器(AC对比DC传感器、电压传感器等等)、无线信号传感器、地理位置传感器、磁传感器、高度计、生物传感器等等。传感器可以是基于通信信息,例如,互联网路由数据、HTTP请求/响应检查、MAC地址、蜂窝/无线三角测量等等。如本领域普通技术人员所理解的,适当配置的计算设备900可以是硬件传感器918的各种组合。此外,这些硬件传感器以及软件传感器(如下面所讨论的)被用于经由集成框架220来监测用户上下文。如上面所指示的,集成框架220是可扩展事件/动作框架,即,该框架检测关于一个或多个传感器(其包括传感器918)所发生的事件,并作为响应,在计算设备900上执行与所检测的事件相关联的动作。可扩展性在于:可以对包括软件传感器的传感器进行增加,用户可以订阅感测的事件。集成框架220将其信息(包括集成注册表)存储在集成数据存储914中。

关于集成框架220而言,本领域普通技术人员应当理解,可以存在用于实现该框架的各种替代方式,在一个实施例中,将框架220实现成建立在来自Node.js开发器的Node.js技术上的后台服务上。Node.js技术是可扩展的和健壮的,使得其可以与诸如传感器918之类的硬件传感器以及软件传感器接口。App和应用(其包括app/应用916)通过代码的方式,与Node.js处理进行接口。当然,虽然可以使用与Node.js不同的其它技术来实现集成框架220,但可以有利地采用Node.js,这是由于其享有托管计算设备(计算设备900)上的相对较小的内存占用,具有用于部署在大量的各种操作系统平台上的配置,并且编程语言享受广泛的支持。

关于示例性计算设备900的各种部件而言,本领域普通技术人员应当理解,可以将这些部件实现成存储在该计算设备的存储器中的可执行软件模块、实现成硬件模块(其包括SoC,片上系统)或者二者的组合。此外,可以将这些各个部件中的每一个部件实现成独立的、协作的处理或者设备,结合一个或多个计算机系统进行操作。当然,此外还应当理解,上面关于示例性计算设备900所描述的各种部件,应当被视作为用于执行本文所描述的各种功能的逻辑组件。如本领域普通技术人员所容易理解的,逻辑组件和/或子系统可以以一对一方式来直接对应于实际的离散部件,或者不是直接对应于离散的部件。在实际的实施例中,可以将每一个计算机系统的各个部件组合在一起,或者拆散在多个实际部件之中和/或在计算机网络上实现成协作的处理。

虽然描述了所公开的主题的各个新颖方面,但应当理解的是,这些方面只是示例性的,不应被解释为限制性的。在不脱离所公开的主题的保护范围的基础上,可以对这些各个方面进行变化和替代。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1