CN101897209A - 用于即时状态和位置的情境感知机制的方法和系统 - Google Patents

Abstract

一种用于在计算执行环境中执行以由服务或应用创建方面的方法，所述方面是与源或服务有关的应用级抽象，所述方法包括：定义有关服务方面；将服务方面作为所命名的方面插入执行环境中的情境感知层，所述情境感知层适于从多种应用类型或服务调用；以及将所命名的方面与情境感知层中的逻辑关联，以支持应用或服务功能。

Description

用于即时状态和位置的情境感知机制的方法和系统

相关申请的交叉引用

本申请要求2007年12月14日提交的美国临时专利申请61/013,813以及2008年5月29日提交的美国临时专利申请61/056,889的权益，其全部内容被合并于此作为参考。

技术领域

本公开涉及应用情境感知，特别涉及移动网络中的应用情境感知。

背景技术

应用拥有功能实用工具，所述功能实用工具具有被称为情境的重要特征。情境被定义为“作为其他某些事物的环境并赋予其他某些事物含义的信息的集合”。例如，在即时状态(presence)应用、位置应用等中可以找到情境的示例。

对于即时状态信息，即时状态元数据提供含义，并且即时状态信息是情境的基础。含义被施加于特定功能或应用内功能的特定特征或者含义作为特定功能或应用内功能的特定特征的一部分，以建立处理步骤的适当集合。

在一示例中，可操作于第一用户的移动设备上的即时消息(IM)客户端应用可能需要确立其他个体或对等体是否可达以允许第一用户发起IM聊天会话的功能。在IM客户端内，可能还需要建立对等用户状态图标以表示第二用户的功能。在第一情形下，情境涉及第二用户是否可达以发起聊天。在第二情形下，第一用户的IM客户端基于第二用户的状态以及显示正确的状态图标、标记或体现的可用性，辨别并导出状态图标。在IM客户端的情境中，由于可达性涉及到对等状态图标特征，可能不相关，然而可达性有助于为发起的聊天功能提供方便。

以上表明，在即时状态环境中，情境在可以如何计算个体的即时状态信息以导出包括可达性、可用性等的即时状态相关方面起重要作用。将理解的是，情境还适用于除了即时状态以外的其他情形。

即时状态服务从一个或多个即时状态源捕捉即时状态信息。一旦采集到该数据，即时状态服务编辑所捕捉的元数据，并将原始即时状态元数据文档分发给已授权的观看者。OMA-即时状态服务平台是即时状态服务的示意性示例。OMA-即时状态使能器以极为详细的书面形式概述与即时状态信息的公布和消费有关的语义和策略。

发明内容

本公开提供了用于由服务或应用创建方面的计算执行环境内的方法，所述方面是与源或服务有关的应用级抽象，所述方法包括：定义有关服务方面；将服务方面作为所命名的方面插入执行环境的情境感知层，所述情境感知层适于从多种应用类型或服务调用；以及将所命名的方面与情境感知层中的逻辑关联，以支持应用或服务功能。

本公开还提供了一种执行环境，包括：具有应用类型的客户端应用，所述客户端应用采用服务方面来执行，所述服务方面是与源或服务有关的应用级抽象；以及情境感知层，适于：将服务方面插入或封装为所命名的方面；从多种应用类型或服务调用；以及将所命名的方面与情境感知层中的逻辑关联，以支持应用或服务功能点。

附图说明

参照附图将更好地理解本公开，附图中：

图1是示出了示例即时状态平台以及无线一键通客户端和服务器的框图；

图2是示出了用于导出可达性方面的客户端设备上的示例处理方法的流程图；

图3是示出了已加入了即时状态情境感知机制的示例即时状态系统的框图；

图4是示出了以加入了即时状态情境感知机制并且即时状态情境感知机制分布在服务器和代理之间的示例即时状态系统的框图；

图5是示出了即时状态情境感知机制已被添加至PoC服务器的示例即时状态系统的框图；

图6是示出了即时状态情境感知机制已被添加至即时状态平台的示例即时状态系统的框图；

图7是示出了已加入了位置情境感知机制的示例位置系统的框图；

图8是示出了已加入了通用情境感知机制的示例通用系统的框图；

图9是当利用P/CAM时确定可达性的示例方法的流程图；

图10是用于利用P/CAM确定顾客是否合适接收广告的示例方法的流程图；

图11是示出了用于利用P/CAM确定推送客户端是否能够使内容推送至它的示例方法的流程图；

图12是示出了用于策略建立的调用流的示例调用流图；

图13是示出了用于OMA/PRS环境内的方面的调用流的示例调用流图；以及

图14是用于方面触发的调用流的示例调用流图。

具体实施方式

术语：

在本描述中，采用了以下术语，并且这些术语的定义如下：

情境          作为其他某些事物的环境并赋予其他某些事物含义。

OMA           开放移动联盟

PEEM          策略评估、实施、和管理使能器

即时状态信息  即时状态的基本单元(例如，活动或情绪是即时状态信息)。

即时状态服务  从即时状态源接收即时状态信息的实体或平台。

即时状态源    涉及代表1+呈现体的即时状态信息的实体。

呈现体      使即时状态信息同其联系的实体。

观看者      希望消费即时状态信息的实体。

情境感知层  可以是接入层、应用抽象层或代理层的层。该层可以利用方面。该层可以部署在网络上，并且可适于处理来自多种类型的多个客户端的请求。该层可以包括情境感知机制如x/CAM(非特定(通用)情境感知机制)或特定机制，如即时状态(p/CAM)和位置(L/CAM)。

描述：

图1示出了在无线一键通(PoC)系统的情境中采用的示例即时状态平台的框图。即时状态平台的使用仅仅是一个示例，诸如位置或通用平台等的其他平台也是可能的。此外，在诸如IM等其他情境中，可以采用即时状态平台(或者其他位置或通用平台)。特别地，在图1中，用户设备110与基站112通过无线通信(如蜂窝)系统通信，基站112接着与所属领域技术人员公知的互联网协议网络120或其他网络通信。将理解的是，基站112可以是用于任意已知无线通信(如蜂窝、PCS、iDEN等)服务的基站。此外，设备110可以通过其他方式(如蓝牙TM等短程无线通信、通过WiFi或WLAN、通过USB或串行端口等有线连接或者通过计算机调制解调器)与网络120通信。事实上，连接至网络120的其他方式对于所属领域技术人员可能是已知的。

在图1的系统中，具有PoC客户端的台式机114(如与用户设备110类似或不同的计算设备)能够通过广域网118和网络120与一个或多个用户设备110通信。

即时状态平台130从网络120向用户设备110或台式机114接收或发出即时状态信息流。即时状态平台130适于存储与客户端状态有关的原始数据，并在接收到新状态数据时更新客户端记录。即时状态平台130还适于向观看者提供即时状态信息。因此，即时状态信息从即时状态平台130流入和流出。

无线一键通(PoC)服务器140存在于图1的系统中，并且在一实施例中可以代表呈现体或观看者来公布状态信息。所属领域技术人员参照图1将理解，可以由应用来执行对即时状态元数据的消费和理解，以实现与感兴趣的主题相关的应用的情境内的功能或特征。在该情况下，应用可以是PoC服务器、PoC客户端或IM客户端等。

用户设备110、台式机114和PoC服务器140可以充当图1示例中的观看者和即时状态源。

所属领域技术人员还将理解，需要对即时状态元数据进行消费和理解以实现应用的情境内的功能或特征增加了客户端应用的复杂度。不利地，该复杂度具有增加相关内存占用以及应用的总的处理、功耗和网络带宽要求的净效应。此外，即时状态相关应用还变得易受对基本元数据的改变和添加或改变即时状态平台语义或策略的影响。例如，错误修正或OMA标准的改变可能需要更新或改变客户端应用，以在将来正确地理解元数据。此外，可以在即时状态语义中添加或改变元数据。

以上具有如下净效应：频繁对在用户的执行环境内部署的应用进行改变以适当保持适当的观看者和/或呈现体场景。还存在额外的时间开销和与给定应用的部署相关的开销。

进一步参照图2的示例对此进行了示意。下面参照图2，图2示出了示例事务的流程图，在示例事务中，PoC客户端应用发送对感兴趣的主题的PoC-警报。在这种情况下，第一用户Alice希望利用其PoC客户端(观看者)向呈现体Bob发送PoC警报。

该过程起始于框210并前进至框212，在框212中，PoC客户端获取或被即时状态服务器通知Bob的即时状态文档。所属领域技术人员将理解，在框212中，当将服务实现为Bob和Alice能够彼此一键通话时，订阅即时状态服务器以提供与Bob有关的即时状态文档，或者当PoC希望与Bob通信时从即时状态服务器进行获取并且接收该信息作为即时状态文档。

接着，处理前进至框214，在框214中，进行检查以查看即时状态文档是否包含任何PoC警报服务元组。将理解的是，该检查是为了查看即时状态文档是否有与该服务(在这种情况下是PoC警报服务)的服务标识符相关的任何内容。

如果在框214中，即时状态文档包含PoC-警报服务元组，处理前进至框216，在框216中，PoC客户端细查即时状态文档，以根据OMA即时状态语义找到相关PoC-警报服务元组。将理解的是，这提供了一种提取正在请求的服务的相关信息的方式。在这种情况下，客户端为此采用了OMA即时状态语义的内嵌知识。

接着，处理前进至框218，在框218中，PoC客户端根据OMA即时状态语义找到最相关人员元素。将理解的是，即时状态文档可以包括多个人员元素。OMA/即时状态定义了用于确定最相关人员的语义。

接着，过程在框220中检查以查看Bob是否愿意PoC-警报与其联系并且对于经解析的服务元组其是否可用。将理解的是，术语“愿意”和“可用”专用于即时状态，并且已预定义了用于解析某人是否“愿意”和/或“可用”的标准。

如果Bob“愿意”并且“可用”，处理前进至框222，在框222中，PoC客户端建立联系方式，联系方式包括用于对Bob的PoC警报服务的设备。将理解的是，可以提供多个地址，并且可以提供这些地址的优先级。

接着，处理前进至框224，在框224中，进行检查，以查看Bob是否是“可联系的”。再次，这在即时状态语义内具有特定含义，并且指示，如果Bob“愿意”并且“可用”，则可以建立联系方式。

如果Bob是“可联系的”，处理前进至框226。在框226，进行检查，以查看联系方式是否有效。如果联系方式过期或者太旧那么联系方式可能无效，并且已设定了情境方式有效性的时限等等。

从框214、220、224或226起，如果得到否定结论，处理前进至框230，指示Bob不可达，并且过程终止于框232。

从框226起，如果联系方式有效，处理前进至框240，在框240中，识别即时状态文档中的每个设备元素。对于每个即时状态文档，处理前进至框242，在框242中，将设备标识符与联系方式匹配。如果匹配，处理前进至框250。否则，处理前进至框244，在框244中，进行检测，以查看是否有更多的设备元素可用。如果有，过程返回框240和242。否则，处理前进至框230，在框230中，认为Bob不可达，并且过程终止于框232。

在框250，过程隔离在设备内的网络可用中每个网络的子元素，并且在框252进行检查，以查看网络是否等于针对PoC警报服务的所需或适用的网络类型以及网络是否可用。这是客户端应用基于策略做出的判决，或者这可以是内嵌在与P/CAM层交谈的客户端(或服务器)中的。如果框252的过程接收到肯定结果时，处理前进至框260，在框260中认为Bob可达，并且接着过程终止于框262。

否则，处理前进至框254，在框254中，进行检查，以查看是否存在可以利用的其他网络子元素，并且如果存在，处理前进至框250和252，再次进行检查，以查看网络是否等于所需或适用的网络类型以及是否可用。从框254起，如果没有其他网络子类型可用，前进至框230，在框230中认为Bob不可达，并且过程终止于232。

以上关于图1和2，对即时状态信息的情境理解可以内嵌于每个客户端应用。每个客户端应用能够接收不同或相同的即时状态元数据的集合，并且在多个申请人共享相同的原始即时状态元数据时，情境理解独立连系每个申请人的这一事实增加了两个不同的客户端应用在关于特定即时状态方面得到不同结论的可能。这可能无法提供期望结果，并且可能导致互操作性问题，特别是在以互不相关和一致的方式共享或处理特定即时状态方面的客户端应用间的互操作性问题。

例如，基于每个客户端应用的即时状态处理步骤的细微变化，根据相同的原始即时状态文档导出人员可达性的电子邮件和IM客户端对关于某人是否可达可能得到不同的结论。这可能导致电子邮件客户端得出该人可达，而IM客户端确定该个体不可达。除了糟糕的服务质量，这可能导致互操作性的问题，例如由于状态匹配错误，当浏览个体的电子邮件时无法从电子邮件客户端产生IM聊天会话。

将原始即时状态信息抽象为基于情境规则和策略支持“即时状态方面”的专门的情境感知层使得应用有可能协同工作以获得导出的功能，并且作为混合情境即时状态的结果执行智能工作流。例如，项目经理希望主持项目状态会议。该项目经理在她的台式机执行环境上(例如从企业电子邮件/日历应用)建立会议邀请，以会见参与者。作为用户发起邀请的结果，代表邮件/日历应用工作的即时状态-情境平台可能能够支持以下类型的功能：

·基于参与者可用性确定适当的时间；

·基于情境策略，为会议预定适当的会议室；

·基于参与者位置(和企业策略)，确定是否必须预定会议桥(并且在会议请求中向适当个体反映此事)；

·基于会议仲裁人通过应用给出的提示和策略，要求符合给定标准的相关参与者(例如销售组成员、开发组成员、质量保证(QA)组成员、具有特定技术或知识的个体等)。

此外，各种应用服务器能够集成即时状态情境感知机制(P/CAM)，以通过减小通信和处理步骤的数量，获得效率。例如，移动广告服务器可以与P/CAM集成，以使其即时状态方面简化和流线化，以聚焦于诸如传送情境相关移动广告等核心功能。

本公开提供了用于建立情境的方法和系统，其中，机制与服务器平台相连以支持给定应用。在即时状态情况下，情境感知整个或部分地驻留在网络内，并代表各种实体(如给定的呈现体和/或观看者)向应用或多个应用提供即时状态/位置或其他有关方面的合成场景。对于每种情况，这是通过将规则、触发以及与即时状态的有关方面(如可用性、可联系性、可达性、状态等)相对的策略关联至情境感知层中来实现的。可以扩展或覆盖规则或触发，以向不同类型的应用或使能器提供应用特有的行为。

可以将情境感知复制给与即时状态或位置服务平台相连的即时状态或位置情境感知机制，以向客户端应用或服务提供与位置有关的方面。位置情境感知机制(L/CAM)利用位置使能器所期望的位置信息，位置信息存储在即时状态服务或其他位置信息存储器中。例如，可以利用GPS、基站或扩展的蜂窝塔信息来导出位置。

将位置特有规则和策略相对于与位置有关的方面(如在地理区域内、与谁相邻、我是否还在那儿等)关联至位置情境感知层中。至于P/CAM，可以扩展或覆盖规则或触发，以向不同类型的应用或使能器提供附加的/应用特有的行为。

类似地，“通用”情境感知层(情境感知机制)可以包含P/CAM、L/CAM和特定应用情境感知机制的组合。一示例可以是移动广告平台，其中，将即时状态、位置和活动相关信息组合使用，以使感兴趣的广告以用户为目标。其他通用平台可以包括网络地址名册服务、网络社区服务等。

所属领域技术人员将理解，情境感知机制适用于有线以及无线执行环境和计算域。该方式具有多种益处，包括运行在用户执行环境内的相关应用复杂度的显著降低。位于网络上的情境感知平台允许给定客户端应用或使能器聚焦于其核心能力，如IM客户端中的聊天、位置客户端中可视化人员的位置等。功能是通过(例如在执行时)注入适用策略以及通过调用与客户端应用或使能器相关的特定规则和/或触发，以代表用户提供实用工具来实现的。

在又一实施例中，情境感知平台或情境感知层包括一致工作的x/CAM服务器和x/CAM客户端或代理。此外，在x/CAM的某些实施例中，与上述P/CAM和/CAM相同的分布式或非分布式方面也是可能的。例如，在某些实施例中，情境感知层可以仅存在于服务器侧。情境感知层客户端或代理内嵌于执行环境。情境感知平台的接口可以是以web为中心的。示例包括可扩展标记语音(XML)web服务，如简单对象访问协议(SOAP)、代表性状态传输(REST)或基于超文本传输协议(HTTP)的XML。以上支持情境感知层部署情形，借助情境感知层部署情形，应用或使能器能够直接与情境感知机制交互或操纵情境感知机制，以更精密地对适当行为进行建模。例如，与P/CAM代理处于相同位置的移动广告服务器可用于覆盖即时状态策略以更好地将即时状态与平台的基本功能匹配。例如，移动广告服务器可以集成或利用x/CAM‘层’。这样的x/CAM可以是P/CAM、L/CAM和特定广告/CAM的超集。

下面参照图3。图3示出了即时状态平台的系统图，其中，PoC客户端应用利用P/CAM作为情境感知层。将理解的是，图3利用与图1类似的网络方面，其中加入了P/CAM。

在图3中，用户设备310通过基站312与网络320通信。此外，台式机314(例如与用户设备310类似或不同的计算设备)通过广域网316与网络320通信。

即时状态平台330适于存储已从客户端接收到的原始数据和状态更新。

此外，存在PoC服务器340，并且PoC服务器340适于代表用户公布和消费状态信息。

即时状态情境感知机制服务器350提供情境感知层，与网络320通信，并通过网络320从客户端接收策略、动态规则和/或触发，还通过网络320公布和接收即时状态方面。

即时状态情境感知机制服务器350还与即时状态平台330通信，以提供和接收即时状态信息流。

图3还示出了网络320和即时状态平台330间的链路332。将理解的是，虽然即时状态平台330和P/CAM服务器350间有通信链路，但为了允许想要与本平台直接通信的客户端与平台直接通信或针对P/CAM服务器350可能尚未知晓的新信息或高级信息提供与平台的通信，不可省去该链路332。

基于以上内容，P/CAM服务器350接收策略、规则和触发，并适于基于这些规则和逻辑向诸如设备310或台式机314等的客户端或PoC服务器340提供和接收即时状态方面。

将理解的是，在其他实施例中，P/CAM的各个方面或功能可以分布在整个网络中，并且在某些实例中，整个P/CAM可以被置于网络内的其他设备或客户端上。

下面参照图4。图4示出了与图1和3类似的系统，其中，P/CAM功能已通过P/CAM代理分布在各种设备上。

特别的，用户设备410通过基站412与网络420通信。此外，台式机414(例如与用户设备410类似或不同的计算设备)通过广域网416与网络420通信。

即时状态平台430适于存储已从客户端接收到的原始数据以及状态更新。

此外，PoC服务器440适于与网络420通信并代表客户端应用公布和消费状态信息。

体现为P/CAM服务器450的情境感知层适于与网络420通信，并适于接收策略、规则和阈值，并通过P/CAM代理460向诸如用户设备410和台式机414等的客户端提供和从诸如用户设备410和台式机414等的客户端接收即时状态方面，或者通过P/CAM代理462向PoC服务器440提供和从PoC服务器440接收即时状态方面。

P/CAM 450还适于与即时状态平台430通信，以接收和发送即时状态信息流。

在图4的实施例中，可以分布P/CAM服务器450的某些功能，以便允许在例如设备410、台式机414或PoC服务器440上执行P/CAM的全部功能或其部分。用户设备410或台式机414上的P/CAM代理460以及PoC服务器440上的P/CAM代理462示出了这点。在这种情况下，情境感知层包括P/CAM服务器450以及P/CAM代理460和/或462。

P/CAM代理460或62可以包含预定义的规则和/或策略。此外，在某些实施例中，P/CAM代理460或462能够用于操纵即时状态信息或与主机执行环境上的元数据或客户端进行互操作。

将理解的是，在某些实施例中，整个P/CAM可以位于客户端或其他服务器上。

下面参照图5。图5示出了P/CAM服务器(情境感知层)内嵌于PoC服务器内的系统图。

特别地，在图5中，用户设备510通过基站512与网络520通信。此外，台式机514(例如与用户设备510类似或不同的计算设备)通过广域网516与网络520通信。

即时状态平台530适于存储从客户端接收的关于即时状态的原始数据和更新。

PoC服务器540适于与网络520通信，并代表客户端公布或消费状态。

PoC服务器540还包括内嵌的P/CAM 550。P/CAM 550与即时状态平台530通信，以交换即时状态信息流，并且还通过网络520通信以接收策略信息、规则和阈值以及此外接收和公布即时状态方面。特别的，通信552向P/CAM 550提供策略和动态过载规则，而通信554向网络520提供即时状态方面。

此外，可以将实现定义为集成在使能器内的P/CAM层(例如作为即时状态平台自身的一部分)。后一实现(如图6所示)还可以支持一种改变，借助该改变体现为P/CAM客户端/代理的情境感知层驻留在移动设备上和/或作为相关使能器(如MobAd服务器)的一部分。

下面参照图6。图6示出了P/CAM服务器内嵌于即时状态平台630内的系统图。

特别的，在图6中，用户设备610通过基站612与网络620通信。此外，台式机614(例如与用户设备610类似或不同的计算设备)通过广域网616与网络620通信。

即时状态平台630适于存储从客户端接收的关于即时状态的原始数据和更新。

PoC服务器640适于与网络620通信，并代表客户端公布或消费状态。

即时状态平台630还包括内嵌的P/CAM 650。P/CAM 650与即时状态平台630通信，以交换即时状态信息流，并且还通过网络620通信，以接收策略信息、规则和阈值，并且还接收和公布即时状态方面。通信652表示正在从网络620接收的策略/动态过载规则。通信654表示正在即时状态平台630和网络620间发送和接收的即时状态方面。通信656表示即时状态平台630和网络620间的即时状态信息流。

参照图3、4、5和6将理解，情境感知通过减少用户执行环境和即时状态平台间传输的数据量降低了网络延迟。这在CPU使用、电池耗电和网络带宽是宝贵资源的无线领域中是有帮助的。此外，由于情境对即时状态平台的特定细节进行了抽象，客户端应用或使能器对于即时状态平台的模型或语义的基本改变不那么脆弱并且明显地耐受性更强。

将理解的是，上述图3、4、5和6是参照P/CAM提供的。然而，此处示例系统和方法同样可与位置平台和L/CAM或通用平台和x/CAM一起应用。此外，这些平台的组合也是可能的。P/CAM、L/CAM、X/CAM或组合形成情境感知层。

参照图7，用户设备710通过基站712与网络720通信。此外，台式机714能够通过广域网716与网络720通信。位置平台730适于提供和存储与用户设备710的位置有关的原始数据，还适于从用户设备710接收更新并存储该信息。

位置服务器740还适于与网络720通信，并且能够提供各种客户端的位置。

L/CAM 750可以是与网络720和位置平台730通信的孤立服务器。在可选实施例中，L/CAM服务器可以与位置服务器位于同一位置，如参考标记755所示。在其他实施例中，L/CAM代理可以位于诸如用户设备710上的代理760等设备上或位于诸如代表762等位置服务器上。在使用代理760和762的情况下，可以将L/CAM的各种功能或所有功能分布至用户设备或位置服务器。

在其他实施例中，L/CAM可以是位置平台730的一部分，如L/CAM770所示。

参照图8，提供了通用环境。在图8中，用户设备810通过基站812与网络820通信。此外，台式机814(例如与用户设备810类似或不同的计算设备)通过广域网816与网络820通信。此外，通用平台830适于存储各种设备的数据和状态。诸如通用服务器840等其他服务器可以存在于网络内，并能够通过网络820通信。

此外，通用x/CAM 850适于与网络820和通用平台830通信。在其他实施例中，x/CAM能够位于服务器840上，并且这被示为x/CAM 855。

在其他实施例中，x/CAM可以具有分别位于用户设备810或服务器840上的代理860或862。

在其他实施例中，x/CAM可以是通用平台830的一部分，如x/CAM870所示。

图8示出了如何将平台(无论该平台是即时状态、位置、通用还是组合平台)抽象为使用情境感知机制的情境感知层，以支持多种应用类型或使能器。

以上可以利用策略和规则/触发来实现。以下提供了与该机制有关的过程。

根据一实施例，情境或机制(无论其是即时状态、位置还是通用的)可以包括一个或多个策略、方面、规则和触发。下面分别详细描述。以下描述是参照即时状态情境或机制介绍的。然而，这并非是限制性的，并且所属领域技术人员可以理解以下内容同样适用于位置或通用情境或机制。

策略：

策略在应用生命期的适当时刻与特定的即时状态情境相关联，以指定即时状态、位置或通用相关方面的行为或处理。策略就规则/逻辑流如何操作增加扩增规则/逻辑流，以代表客户端应用或使能器提供对方面的更精确和更有意义的计算。将理解的是，策略可以应用于一种类型的应用、独立应用、或者甚至用于，并且可以向其提供关于如何计算方面的设置。

可以使用开放移动联盟的(OMA)策略、执行和管理(PEEM)/策略表示语言(PEL)来表示策略。PEL定义了通用和可扩展语法，其中，可以用规则设置语音表示的策略。PEL基于因特网工程任务组(IETF)请求评述(rfc)4745。如OMA-SUP-XSD_XSD_xdm_extensions-V1_0中详细记载的，可以通过OMA XDM(XML文档管理)一般策略扩展，在PEEM的范围内增强(如rfc 4745所指定的)条件和/或行为。还可以根据IETF rfc 4745来表示策略。

将理解的是，PEEM是OMA定义其使能器所需的一般功能的持续不断的标准成果。

作为示例，下表描述了在计算即时状态方面中由即时状态情境使用的有关即时状态策略。这些策略具有对OMA即时状态平台的适用性。然而，可以根据需要添加给定策略或将给定策略从给定情境中删除，并且该概念适用于多个即时状态平台。在下表中，以斜体示出了适用情况下的缺省值。

策略	描述	值
			opt-in-source	指示哪个即时状态元素是服务选择进入的指示符。缺省值指示对于给定通信服务选择进入是无关的。	willing|ignore
applicable-network-type	指示给定通信服务的适用网络类型。	IMS，SIP，<token>，...
			threshold-value-equals	用qn-elem建立被记为label的阈值与value的相等比较运算。如果策略应用于xml-ns并且结果目标同value匹配，可以应用布尔值‘真’或‘1’或‘是’。	<label><qn-elem><value>
threshold-value-less-than	与相等相同，除了比较运算符是小于(＜)。	<label><qn-elem><value>
			threshold-value-greater-than	与相等相同，除了比较运算符是大于(＞)。	<label><qn-elem><value>

unavailable-activies-set	指示从观看者的角度将呈现出联系不可用的活动的子集。该集合可定义为空，指示活动对可用性无影响。	busy，holiday，meal，in-transit，permanent-absence，sleeping，unknown，worship
			undef-servcaps-sub-element	指示如何理解在即时状态元数据中不存在或省略特定的<servcaps>子元素。	unknown|unsupported
undef-barring-state	指示如何理解在即时状态元数据中不存在或省略<barring-state>子元素。	ignore|active|terminated
			undef-registration-state	指示如何理解在即时状态元数据中不存在或省略<registration-state>子元素。	ignore|active|terminated
undef-willingness	指示如何理解对于给定comm.服务不存在或省略<willingness>。	(open，indefinite)    |(closed，indefinite)  |(open，time-ofs-value)|(closed，time-ofs-value)

表1：即时状态策略

以上表1定义了各种策略和策略的值。如表中所示，存在各种策略，并且提供了对策略和值的描述。

在该表的第一行中，第一策略为“opt-in-source”。该策略用于指示哪个即时状态元素是服务选择进入的指示符。缺省值指示选择进入对于给定通信服务是无关的。

对于opt-in-source策略可能的值是willing或ignore。将理解的是，这些值可由诸如服务提供者等各种实体选择。选择策略的实体能够选择利用哪个值。因此，例如，服务提供者可以选择忽略针对第一策略的选择进入源。

表1中描述的第二策略是applicable-network-type，指示给定通信服务的适用网络类型。如表中所示，缺省为IMS。然而，其他值包括会话发起协议(SIP)或令牌，并且可由选择实体选择。

第三策略是“threshold-value-equals”，并且可用于以限定名XML元素建立被记为label的阈值与value的相等比较运算。如果将策略应用于xml-ns命名空间并且结果目标与value匹配，可以应用布尔值‘1’或‘真’或‘是’。

表1中的下一策略是“threshold-value-less-than”。该策略与threshold-value-equals策略相似，只不过它利用小于比较符。

类似地，下一策略是“threshold-value-greater-than”，该策略与上述threshold-value策略相似，只不过利用大于比较符。

下一策略是“unavailable-activities-set”，并且可以包括对在应用、服务或使能器的情境下不可用的联系进行呈现的活动的子集。在缺省设置下，这是未知的，但它可以包括诸如忙碌、节假日、用餐等内容。

下一策略是“undef-servcaps-sub-element”，并且指示未定义服务能力以及应用将如何理解这些能力。例如，表1指示如果服务是未定义的，其可以被看作不支持。

表1中的下一策略是“un-def-barring-state”，并且指示如何理解在即时状态元数据中不存在或省略barring-state XML元素，并且可以包括状态是激活的或者是终止的。缺省值是状态将被忽略。

类似地，“undef-registration-state”指示如何理解不存在或省略registration-state XML元素，并且在以上表1的示例中，缺省情况下为忽略，但还可以包括激活和终止。

表1中定义的最后的策略是“undef-willingness”，并指示了如何理解对于给定通信服务不存在或省略willingness XML元素，并且可以包括由状态(开或关)以及有效期(不确定期限或预设有效期)构成的对。

所属领域技术人员将理解，以上表1仅作为示例，并且根据系统或用户的需要，其他策略也是可能的。

为了支持前表中的策略，P/CAM需要附加的XML类型和元素定义，以扩展PEL一般策略“动作”。以下XML图示文档提供了与可以如何扩展这些动作以供P/CAM使用的进一步的细节。

<？xml version＝″1.0″encoding＝″UTF-8″？>

<xs:schema

targetNamespace＝″urn:oma:xml:xdm:extensions:cam″

xmlns＝″urn:oma:xml:xdm:extensions:cam″

xmlns:xs＝″http://www.w3.org/2001/XMLSchema″

elementFormDefault＝″qualified″attributeFormDefault＝″unqualified″>

<！--This import brings in the XML language attribute xml:lang-->

<xs:import namespace＝″http://www.w3.org/XML/1998/namespace″

  schemaLocation＝″http://www.w3.org/2001/xml.xsd″/>

<！--P/CAM specific″actions″child element extensions to-->

<！--namespace urn:ietf:params:xml:ns:common-policy-->

<xs:element name＝″opt-in-source″type＝″OptlnSourceType″/>

<xs:element name＝″applicable-network-type″type＝″ApplicableNetworkType″/>

<xs:element name＝″threshold-value-equals″type＝″ThresholdEqType″/>

<xs:element name＝″threshold-value-less-than″type＝″ThresholdLtType″/>

<xs:element name＝″threshold-value-greater-than″type＝″ThresholdGtType″/>

<xs:element name＝″unavailable-activities-set″type＝″UnavailActivityType″/>

<xs:element name＝″undef-servcaps-sub-elements″

      type＝″UndefServCapsSubElemsType″/>

<xs:element name＝″undef-barring-state″type＝″UndefBarringStateType″/>

<xs:element name＝″undef-registration-state″

      type＝″UndefRegistrationStateType″/>

<xs:element name＝″undef-willingness″type＝″UndefWillingnessType″/>

<！--Type definitions defined by this document-->

<！--OptlnSource indicator-->

<xs:simpleType name＝″OptlnSourceType″>

<xs:annotation>

  <xs:documentation>

  Policy:opt-in-source

  The associated service(s)use′willing′，or′ignore′as opt-in indicator.

  The default is′ignore′which means no opt-in indicator is relevant.

  </xs:documentation>

</xs:annotation>

   <xs:rest riction base＝″xs:token″>

       <xs:pattern value＝″willing|ignore″/>

   </xs:restriction>

</xs:simpleType>

<！--NetType-->

<xs:simpleType name＝″NetType″>

   <xs:restriction base＝″xs:string″>

       <xs:pattern value＝″IMS|SIP|[a-zA-Z][a-zA-Z0-9][a-zA-Z0-9]+″/>

   </xs:restriction>

</xs:simpleType>

<！--ApplicableNetworkType indicator-->

<xs:simpleType name＝″ApplicableNetworkType″>

<xs:annotation>

  <xs:documenfation>

  Policy:applicable-network-type

  Indicator of applicable network type(s)for the given

        communication service.

  </xs:documentation>

</xs:annotation>

   <xs:list itemType＝″NetType″/>

</xs:simpleType>

<！--Threshold indicator types-->

<xs:complexType name＝″BaseThresholdType″abstract＝″true″>

   <xs:annotation>

<xs:documentation>

Base type definition for threshold types.Specifies′label′which

is used to identify the specific threshold，along with the qualified name.

       </xs:documentation>

     </xs:annotation>

     <xs:all>

<xs:element name＝″label″type＝″xs:token″/>

<xs:element name＝″qn-elem″type＝″xs:QName″/>

<xs:element name＝″value″type＝″xs:anyType″/>

    </xs:all>

</xs:complexType>

<xs:complexType name＝″ThresholdEqType″>

   <xs:annotation>

<xs:documentation>

 Policy:threshold-value-equals

 Comparison operation(equality)threshold for′label′for qualified

 element name′qn-elem′with value specified as′value′.

</xs:documentation>

    </xs:annotation>

    <xs:complexContent>

    <xs:extension base＝″BaseThresholdType″/>

    </xs:complexContent>

  </xs:complexType>

<xs:complexType name＝″ThresholdLtType″>

   <xs:annotation>

<xs:documentation>

 Policy:threshold-value-less-than

 Comparison operation(less-than)threshold for′label′for qualified

 element name′qn-elem′with value specified as′value′.

</xs:documentation>

    </xs:annotation>

    <xs:complexContent>

    <xs:extension base＝″BaseThresholdType″/>

    </xs:complexContent>

</xs:complexType>

<xs:complexType name＝″ThresholdGtType″>

   <xs:annotation>

<xs:documentation>

 Policy:threshold-value-greater-than

 Comparison operation(greater-than)threshold for′label′for qualified

 element name′qn-elem′with value specified as′value′.

</xs:documentation>

    </xs:annotation>

    <xs:complexContent>

    <xs:extension base＝″BaseThresholdType″/>

    </xs:complexContent>

</xs:complexType>

<！--Unavailable activities indicator-->

<xs:simpleType name＝″UnavailActivityType″>

   <xs:annotation>

<xs:documentation>

 Policy:unavailable-activities-set

 Used to describe all activities related to an application or enabler

 that would render an individual unavailable.

</xs:documentation>

</xs:annotation>

    <xs:list itemType＝″xs:QName″/>

</xs:simpleType>

<！--UndefServCapsSubElems indicator-->

<xs:simpleType name＝″UndefServCapsSubElemsType″>

   <xs:annotation>

<xs:documentation>

 Policy:undef-servcaps-sub-elements

 Indicate how to interpret the absence or omission of specific

    &It；servcaps&gt；sub-elements in presence metadata.Value of′unknown′

    is considered the default which does not give the context any

          hints as to how to deal with missing/absent

          &It；servcaps&gt；sub-elements.

    </xs:documentation>

         </xs:annotation>

    <xs:restriction base＝″xs:token″>

         <xs:pattern value＝″unknown|unsupported″/>

    </xs:restriction>

 </xs:simpleType>

 <！--UndefBarringState indicator-->

 <xs:simpleType name＝″UndefBarringStateType″>

 <xs:annotation>

   <xs:documentation>

    Policy:undef-barring-state

    Indicate how to interpret the absence or omission of specific

    &It；barring-state&gt；sub-elements in presence metadata.

   </xs:documentation>

 </xs:annotation>

 <xs:restriction base＝″xs:token″>

    <xs:pattern value＝″ignore|active|terminated″/>

       </xs:restriction>

 </xs:simpleType>

 <！--UndefRegistrationState indicator-->

 <xs:simpleType name＝″UndefRegistrationStateType″>

 <xs:annotation>

   <xs:documentation>

     Policy:undef-registration-state

     Indicate how to interpret the absence or omission of specific

     &It；registration-state&gt；sub-elements in presence metadata.

             Default value of′ignore′indicates that the sub-element has

             no meaning in this context.

   </xs:documentation>

 </xs:annotation>

    <xs:restriction base＝″xs:token″>

   <xs:pattern value＝″ignore |active|terminated″/>

    </xs:restriction>

  </xs:simpleType>

  <！--UndefWillingnessType indicator-->

  <xs:simpleType name＝″UndefWillingnessType″>

         <xs:annotation>

     <xs:documentation>

       Policy:undef-willingness

       Indicator of how to interpret absence or omission of

       &It；willingness&gt；sub-element for the given service.

       Default value is′closed/indefinite′.

    </xs:documentation>

        </xs:annotation>

        <xs:restriction base＝″xs:token″>

     <xs:enumeration value＝″open/indefinite″/>

     <xs:enumeration value＝″closed/indefinite″/>

     <xs:enumeration value＝″open/time-ofs-value″/>

     <xs:enumeration value＝″closed/time-ofs-value″/>

         </xs:restriction>

     </xs:simpleType>

</xs:schema>

以上XML图示在以<xs:element name＝“opt-in-source”type＝“OptInSourceType”/>起始的行中提供了对元素名称的定义。针对以上表1中的剩余策略，进一步定义了元素名称。

所属领域技术人员将看到，以上XML图示的其余部分定义了表1的描述和值字段所指示的策略类型。特别的，对于“OptInSouceType”，将xs:pattern value设置为willing或ignore。因此，以上提供了附加的XML类型和元素定义，从而扩展了PEL一般策略动作。

通过扩展一般策略动作，可以将P/CAM策略并入一般策略PEL‘规则集’XML文档。‘规则集’可应用于用户范围或全局范围。例如，‘规则集’可适用于一种类型的服务或特定应用。规则集还可适用于独立的用户或用户组。

由P/CAM服务器自身或支持P/CAM的客户端/代理通过各种PEEM请求者接口来操纵和评估与P/CAM相关的策略。即，应用或认证协议可以向PEEM请求者接口提供诸如请求者标识等特定的元数据以及PEEM服务器可用的其他元元素，作为应用规则的基础。

以下是一般策略PEL规则集XML文档的示例，由单个规则‘a101’构成。该规则与服务使能器(如PoC警报)相关，并且定义了作为同目标资源匹配的结果应用的特定策略设置/值。在这种情况下，目标资源是服务标识符自身。所属领域技术人员将理解，该示例形成了一般策略扩展‘ext:service[@enabler]’属性的值与OMA即时状态所定义的OMA PoC警报服务id之间的故意关联。

参照图12对以上进行示意，图12示出了诸如境感知层(CAL)等感知层如何能够预加载策略类型XSD的给定集合。将理解的是，这些是以上表1所示的类型。

AL-客户端设备1210与AL 1212通信，AL 1212与PEEM 1214通信。

AL 1212向PEEM 1214发送loadPolicyExtention(xsd，service-id)消息1220，PEEM 1214对消息进行处理，如箭头1222所示。PEEM 1214接着向AL 1212发送接受消息1224。

稍后，支持AL的客户端设备1210尝试启动并同诸如PoC警报服务等AL 1212服务使能器进行认证。这是利用authenticate(watcher-id，service-id，user-id)消息1230来实现的。

作为启动和认证的一部分，AL 1212向PEEM 1214发送pellnit(watcher-id，service-id，user-id)消息1240。PEEM 1214对策略进行评估(如箭头1242所示)，并在消息1244中返回该策略。评估1242允许PEEM关于每个服务器或每个用户应用策略设置的特定集合。

AL 1212启动情境(箭头1244)，并且可选地作为消息1250将AL情景返回AL客户端设备1210。

作为示例，匹配准则可以是与OMA使能器(如PoC警报)有关的服务id。其他匹配准则可以基于用户或组范围。

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！--Sample policy ruleset for OMAPoCAlert service.-->

<！--A ruleset may apply on a per-user or global basis.-->

<cr:ruleset     xmlns＝″urn:ietf:params:xml:ns:common-policy″

          xmlns:ext＝″urn:oma:xml:xdm:extensions″

           xmlns:cr＝″urn:ietf:params:xml:ns:common-policy″

   xmlns:cs＝″urn:oma:xml:xdm:extensions:cam″

 xmlns:rpid＝″urn:ietf:params:xml:ns:pidf:rpid″>

      <！--A rule forPoCalert service，establish context policies-->

 <cr:rule id＝″a101″>

          <cr:conditions>

         <ext:service-list>

                     <！-Match against a specific OMAenabler by service-I D...-->

           <ext:service enabler＝″org.openmobilealliance.PoC-alert″/>

         </ext:service-list>

          </cr:conditions>

          <cr:actions>

                        <！--Following policy values for document scope...-->

              <cs:undef-servcaps-sub-elements>

                unsupported

              </cs:undef-servcaps-sub-elements>

              <cs:undef-willingness>

                closed/indefinite

              </cs:undef-willingness>

              <cs:opt-in-source>willing</cs:opt-in-source>

              <cs:unavailable-activities-set>

                 rpid:busy rpid:sleeping

              </cs:unavailable-activities-set>

              <cs:undef-registration-state>

                   terminated

              </cs:undef-registration-state>

              <cs:undef-barring-state>

                  ignore

              </cs:undef-barring-state>

              <cs:applicable-network-type>

                  IMS

              </cs:applicable-network-type>

         </cr:actions>

   </cr:rule>

</ruleset>

所属领域技术人员将理解，以上定义了规则‘a101’。在这种情况下，服务id被定义为“org.openmobilealliance.PoC-alert”OMA PoC警报服务，并且P/CAM策略扩展被定义为XML命名空间“urn:oma:xml:xdm:extensions:cam”的一部分。因此，以上是关于以上表1定义的图示的表现。以下参照表1A示出了基于规则‘a101’启动的情境感知层值。

策略	值
		opt-in-source	willing
applicable-network-type	IMS
		unavailable-activies-set	rpid:busy rpid:sleeping
undef-servcaps-sub-element	unsupported

undef-barring-state	ignore
		undef-registration-state	terminated
undef-willingness	(closed，indefinite)

表1A-策略设置/值(OMAPoC警报服务)

将理解的是，PEEM可以利用多种应用策略和多种服务，或者可以作为规则集的一部分建立特例。

如XML中所见的动作定义了针对文档范围的特定的策略值。

方面：

方面是与源有关的应用级抽象，例如，即时状态方面是与即时状态有关的应用级抽象。即时状态方面可以被看作对于P/CAM客户端应用或使能器的即时状态情境的概念接口。以下表2概述了适用即时状态方面的基本集合，该适用即时状态方面的基本集合可以并入以供即时状态情境感知机制使用并向客户端应用公开。对于每个即时状态方面，提供了描述以及就IETF rfc 4479中概述的标准即时状态数据模型而言该方面涉及的关联。

特别地，为了对在交互工作的组件和用户设备的全异集合中的情境相关行为进行指定和应用，需要一般机制来封装与即时状态平台有关的方面。即，方面捕捉与给定应用或使能器有关的第一级抽象。与即时状态平台有关的方面将描述或涉及即时状态的基本指示。可以将方面扩大为还封装了其他指示。例如，可以并入(或推断)位置，以导出或计算即时状态平台内的相关方面。以下表2关于“谁在附近”方面对此进行了示意。

本公开针对即时状态平台所需的任意数量的方面提供机制。这些方法可以包括诸如可用性和可达性等一般方面。还可以包括应用所特有的方面。存在着即时状态平台或管理接口内的机制，以将方面的适当集合与给定服务关联。方面关联本质上的情境的，并且可适用于不同级别。例如，给定方面可适用于诸如所有OMA无线一键通(即PoC)兼容服务等服务使能器。

方面可能还适用于用户或组级别。

对于每个方面，可以定义规则或逻辑的相关集合，其概述了实现给定方面所需的步骤或处理。逻辑还标识了与相关方面的计算有关的原始即时状态/数据指示符/元素。给定方面可以将两个或更多个预定义规则组合在一起，作为其逻辑处理的一部分。此外，可以将基本逻辑作为库或例程来重用，以支持即时状态平台内的方面。该库可以将方面包括为可以并入的其他高级模块或组件。这允许多种客户端应用类型利用情境感知层。

在一实施例中，即时状态方面是可扩展的。例如，如果给定服务或使能器需要特定功能，即时状态平台可以根据需要支持一个或多个方面中的扩展或重定义。

所属领域技术人员将理解，可以将表2修改或扩展为支持其他即时状态平台或应用/使能器要求。表2所示的特定的即时状态方面示意了OMA即时状态平台。

即时状态方面	描述	关联	可见性	一般可见性
					选择进入	呈现体愿意参与针对给定服务或应用的会话。	人员->服务。	OTA，服务器	服务器
可用	呈现体可用于使用给定服务或应用进行通信。	人员->服务。	OTA，服务器	服务器
					联系方式	针对给定服务或应用，呈现体的最适用的联系方法。	人员(地址)->服务。	OTA，服务器	服务器
可联系	呈现体愿意、可用，并且对于给定服务或应用具有当前有效的联系方式。	人员(地址)->服务。	OTA，服务器	服务器
					可达	对于给定服务或应用呈现体是可联系的。注意：可达的肯定指示表示了呈现体愿意、可用、可联系，并且它们的设备在通过所定义的服务建立通信的覆盖内。	人员->服务->设备	OTA，服务器	OTA
你在哪儿	呈现体当前位置。	人员、人员->服务->	OTA，服务器	OTA
							设备
个人体现	呈现体当前个人图标表示。	人员	OTA，服务器	OTA
					服务体现	呈现体针对给定服务或应用的当前图标表示。	人员->服务	OTA，服务器	OTA

个人兴趣	呈现体当前兴趣或爱好。	人员(扩展信息)	OTA，服务器	服务器
					谁在订阅我	当前具有对于给定呈现体的‘待处理’订阅的观看者。	人的信息	OTA，服务器	服务器
谁在附近	位于附近并满足可选准则集(如对足球感兴趣)的零个或多个呈现体的列表。	人员->服务	OTA，服务器	OTA或服务器
					谁被阻塞	已经终止的订阅或针对给定呈现体被阻塞的观看者。	人的信息，一般策略	OTA，服务器	服务器
合格的会话参与者	呈现体是否可达以及是否满足可选准则集以参与相关服务的会话。	人员->服务->设备，共享用户简档，其他XDMS元数据	OTA，服务器	服务器
					会话应答模式	指示呈现体是自动(无干预)还是手动(用户必须接受或拒绝)模式接受给定服务的传入会话的指示符。	人员->服务	OTA，服务器	OTA

表2：即时状态方面

表2定义了适用于即时状态平台的各个即时状态/应用/服务方面。对于每个方面，存在简短的描述以及该方面与标准即时状态数据模型的关联或适用性。此外，声明了可见性。可见性描述了查阅相关方面的适用位置。一般可见性定义或声明了可能查阅相关方面的最常见或相关的位置。对可见性的选择包括与服务器相对的无线方式(OTA)。将理解的是，“服务器”可以显现在网络侧应用服务器中。

在以上表2的第一行中，定义了选择进入方面，选择进入方面指示呈现体愿意参与针对给定服务或应用的给定会话。如表2中所示，人员与服务相关联。

表2的第二行指示即时状态方面是“可用”的。该方面指示呈现体可用来使用给定服务或应用进行通信，并且再次地存在人员和服务间的关联。

表2中的下一行指示联系方式的即时状态方面。提供了针对给定服务或应用，呈现体最适用的联系方法，并且关联位于人员地址和服务之间。

表2的下一行指示‘可联系’方面。该方面示出了呈现体是否愿意、可用，并且对于给定服务或应用具有当前有效的联系方式。再次，在这种情况下，关联位于人员地址和服务之间。

该表的下一行是“可达”方面。这表示对于给定服务或应用，呈现体是可联系的。可达的肯定指示表示，呈现体愿意、可用、可联系，并且它们的设备位于通过所定义的服务建立通信的覆盖内。因此，关联位于人员、服务和设备之间。

“你在哪儿”是表2中定义的下一方面，并且示出了呈现体的当前位置。如所示的，该方面的关联在于人员、以及人员、服务、和设备处。

表2中还定义了其他方面，并且其他方面包括各种关联。

对于OMA即时状态实现，示例即时状态平台调用流可能看起来与图13所示的相似。所属领域技术人员将理解，图13表示情境感知层可以配置在客户端设备和OMA即时状态/XDM层之间。在一实施例中，接入层可以是应用层或代理。这样的情境感知层可以是应用(例如具有分开或集成的情境感知层的移动广告应用)的单独的层或内层。

如图13所示，方面“可达”可以在后端包括进一步处理，该进一步处理并入规则以及可能的在计算中使用其他方面。如前所述，这些方面可以存在于方面的标准库内，以在需要时在更高级应用内重用。

下面参照图13。图13示出了与接入层(AL)1312(如情境感知层(CAL))通信的客户端设备1310，接入层(AL)1312继而与OMAPRS/XDM实体1314通信。

客户端设备1310发送关于即时状态方面“可达”的查询，如通信1320所示。继而，接入层(AL)1312向OMAPRS/XDM 1314发送HTTP/GET请求1322。

OMAPRS/XDM 1314进行认证(如1330所示)，并以HTTP/1.1<pidf>1332的形式返回响应。

接入层(AL)1312接着检查过程是否可达(如箭头1340所示)。针对方面“可达”的AL内的处理调用其它规则，例如“可联系”、“联系方式”、“可用”以及“选择进入或愿意”。

1340所示的箭头确定呈现体不可达并在消息1350中返回。

如图13所示，可达查询1320和不可达响应1350以无线方式传输。然而，这仅仅意在作为示例，在不同的实施例中，其他通信技术可能是适用的。

规则/触发：

情境感知机制方案的第三分支由规则和/或触发组成。以下示例使用即时状态作为示例。

规则驻留在即时状态情境内，并建立基于基本即时状态平台提供的元数据计算即时状态方面所需的步骤序列或逻辑流。规则在概念上与数据库存储的流程或用户定义的功能(UDF)类似。应用客户端或独立用户可以改变或补充基本或缺省即时状态规则。例如，客户端注入动态规则可以覆盖或扩展基本规则行为。此外，规则并入应用或使能器所关联的即时状态情境，以扩大或提供围绕对元数据的理解的提示。这允许应用或服务根据需要直接影响一个或多个即时状态方面的结果。

以下表3用OMA即时状态平台的特定伪逻辑示出了与即时状态相关方面的计算有关的规则的集合。应当注意的是，这仅仅是即时状态情境所公开的规则/逻辑的子集。可以根据即时状态情境的需要改变规则的组成或粒度。此外，如上参照图3-6所述，呈现体或观看者可以继续获取或被基本即时状态平台通知原始即时状态信息，以在情境不适用的情况下达成特定结论。将理解，这可能在特定情形下发生。

如以下表3所使用的，‘def’指示“已定义”，并表示实体存在并且是利用合理的值建立的，而‘undef’表示“未定义”(‘def’的补集)。因此，‘Undef’具有诸如零、空或无效等值。

以下表3中的‘有效’表示相关实体仍包含及时或有意义的数据。

规则	描述	■For each<tuple>‘t’in list witht.service-id＝＝service-id○Items.add(‘t’)■IfItems.size＝＝1
					○Res＝＝Items[0]■Else○Res＝resolveService(Items)■Return Res
findServicePresInfo	返回针对服务‘列表’内的给定服务或应用最适用的即时状态信息元素‘svc’。注意：伪逻辑方法‘resolveService()’实现OMA-TS-PresV2_0      Section(5.2.3)中概述的语义。	■Switch(opt-in-sou rce policy)■Case willing:○Uwp＝undef-willingness policy○If svc.willingness undef■Return Uwp○Else■Return svc.willingness■Case session-participation:○ReturnWillingness(svc.session-participation，indefinite)■Default://ignore○Return Willingness(open，indefinite)

hasOptedInForService	利用opt-in-source策略来建立用户‘p’通信给定服务或应用‘svc’的意愿。该意愿是有序对(open|closed，indefinite|time-ofs-value)。注意：伪逻辑方法实现OMA-TS-PresV2_0    Section(10.4.1)中概述的语义。	■Urs＝undef-registration-state policy■Ubs＝undef-barring-state policy■Uas＝unavailable-activities-set policy■If(p.activities valid and<activities>non-em pty-set)○For each<activities>‘a’in p:■If(‘a’match 1+elementin Uas)■Return false■If(svc.reg-state undef)○If(Urs＝＝‘ignore’)■Reg-state＝active○Else■Reg-state＝Urs■Else○Reg-state＝svc.reg-state■If(svc.bar-state undef)○If(Ubs＝＝‘ignore’)■Bar-state＝active○Else■Bar-state＝Ubs■Else○Bar-state＝svc.bar-state■If(Reg-State＝＝‘active’AND Bar-state＝＝‘active’AND    svc.status.basic＝＝‘open’)○Return true■Return false
			isAvailable	返回布尔值，布尔值指示呈现体‘p’可用于针对给定服务或应用进行通信‘svc’。NOTE：伪逻辑方法实现OMA-TS-PresV2_0    Section(10.4.3)中概述的语义。在该方法中，逻辑还将活动(如果被策略所指向)作为可用性计算的因素。	■Return svc.contact
			establishContactMeans	针对给定服务或应用服务‘svc’返回适用联系‘c’。注意：伪逻辑遵循rfc 3863。	■W＝hasOptedInForService(p，svc)■If(W valid AND isAvailable(p，svc))○C＝establishContactMeans(svc)○If(C def AND svc.deviceID def)■Cm＝ContactMeans(Contact，svc.deviceID(s)，w.validity)■Return Cm

isContactable	如果针对给定服务或应用‘svc’，呈现体‘p’是可联系的，返回有效联系方式，联系方式由元组(contact，ldev，validity)构成。NOTE：伪逻辑方法实现OMA-TS-PresV2_0 Section(10.4)中概述的语义。	■Ant＝applicable-network-type policy■If(cm valid)○For each‘d->deviceID’in ldev:■Find‘dev’in<device>elements wheredev.deviceID＝＝‘d->deviceID’■If match■For each<network>‘n’in‘dev’:■If(‘n’.id match1+element inAnt and‘n’available)■Return true■Return false
			isReachable	返回布尔值，指示是否可通过所需网络类型、给定可联系联系方式到达适用设备‘dev’。	■For each<tuple>‘t’in list with t.service-id＝＝service-id○Items.add(‘t’)■IfItems.size＝＝1○Res＝Items[0]■Else○Res＝resolveService(Items)■Return Res

表3：规则

以上表3描述了多个规则。所定义的第一规则是‘findServicePresInfo’，返回针对服务列表内的给定服务或应用最适用的即时状态信息元素。如伪逻辑中所指示的，对于列表中的每个元组t进行检查，以查看‘t’的服务id是否同期望的服务id匹配，并且如果匹配，元组t被添加至列表。此后，一旦完成编辑，如果该项大小为1，则返回该项。否则，调用函数‘resolveService’。所属领域技术人员将理解，‘resolveService’函数是OMA特有的查找最相关服务的函数。

关于表3的其余部分，定义了类似的规则，其中利用各种伪逻辑来定义在实现规则时将返回什么。

可以利用OMA的PEEM/PEL来指定即时状态规则和/或逻辑流。以下是PEEM/PEL‘抽象过程’文档的示例，其表征了在以上表3的伪逻辑中所示的‘findServicePresInfo’规则的逻辑流：

<process name＝″findServicePresInfo″

          targetNamespace＝″http://example.com/ws-bp/purchase″

          xmlns＝″http://docs.oasis-open.org/wsbpel/2.0/process/abstract″

      xmlns:pcam＝″http://pcam.example.com/wsdl/oma-pres-pcam″>

<documentation xml:lang＝″EN″>

   A WS-BPEL process for finding the appropri ate service tuple(s).

</documentation>

<！--Input/output parameters:-->

<！--presinfo-inbound body containing service-ID，and presence info-->

<！--theResult-the most relevant service tuple for service-ID-->

<variables>

   <variable name＝″presinfo″messageType＝″##opaque″/>

   <variable name＝″matchingTupleList″messageType＝″##opaque″/>

   <variable name＝″theResult″messageType＝″##opaque″/>

</variables>

<partnerLinks>

   <partnerLink name＝″service″partnerLinkType＝″##opaque″

      partnerRole＝″##opaque″/>

   <partnerLink name＝″customer″partnerLinkType＝″##opaque″

      partnerRole＝″##opaque″

      myRole＝″##opaque″/>

</partnerLinks>

<sequence>

   <receive partnerLink＝″customer″operation＝″findServicePresInfoRequest″

      variable＝″presinfo″createlnstance＝″yes″>

</receive>

<forEach counterName＝″i″parallel＝″no″>

    <！--Iterate over $presinfo.msg/tuple and find all matches-->

    <！--between$presinfo.msg/service-id and-->

    <！--$presinfo.msg/tuple[i]/service-description/service-id-->

    <！--Store in matchingTuple List    -->

</forEach>

<if>

    <condition opaque＝″yes″>$matchingTupleList.num-items＝＝1</condition>

    <flow>

        <！--$theResult is the first item in $matchingTupleList-->

    </flow>

    <else>

       <！--$theResult is the outcome of invoking resolveService-->

       <！--method with$matchingTupleList-->

             </else>

         </if>

         <reply partnerLink＝″service″portType＝″##opaque″

                 operation＝″##opaque″variable＝″theResut″>

         </reply>

    </sequence>

</process>

规则/触发分支的其他部分是触发。触发驻留在即时状态情境内，并基于在即时状态平台中检测到的基本即时状态状态改变对步骤序列(或逻辑流)进行关联。触发在概念上与数据库触发类似。默认情况下，触发是初始通知。根据需要，触发可由应用客户端或者独立用户定义。例如，客户端注入动态触发可以覆盖或扩展基本触发行为。

表4利用特定触发特有的伪逻辑列出了与即时状态相关方面的计算有关的触发的集合。应当注意的是，还可以用相应的触发定义来定义方面。

触发	描述	伪逻辑
			onOptIn/Out	当确定呈现体已针对给定服务或应用选择进入/离开时调用的应用定义触发。	·notification(default)
onUn/Available	当确定呈现体针对给定服务或应用不可用/可用时调用的应用定义触发。	·notification(default)
			onUn/Reachable	当确定呈现体针对给定服务或应用不可达/可达时调用的应用定义触发。	·notification(default)
onNearby/onOutOfRange	当呈现体位于附近或它们已移出给定服务或应用的指定范围时调用。	·notification(default)
			on-pending-subscription	当呈现体具有一个或多个处于‘待处理’状态的订阅时调用。	·notification w/list<AOR>(default)
on-terminated-subscription	当呈现体具有一个或多个处于‘终止’状态的订阅时调用。	·notificationw/list<AOR>(default)
			on-update-note	呈现体何时添加或更新个人记事。	·notification w/note-text(default)
on-is-in/eligible-session-partiei pant	呈现体何时不可达/可达并且对于给定服务或应用不合格/合格。	·notification(default)

表4：触发

以上表4中的第一触发指示，当呈现体选择进入或离开给定服务或应用时将会调用触发。该触发允许当在该情境内发生相关状态时执行特定功能。如果客户端希望P/CAM在发生给定事件时(当调用触发时)执行动作，可以由应用客户端定义伪逻辑。

表4定义的其他触发具有类似功能，并在满足预定义条件时调用。

触发是利用OMA的PEEM/PEL(策略表示语言)定义的，并且基本与即时状态规则类似。因此，可以针对表4的触发适配以上参照规则使用的代码示例。

触发在复杂的即时状态感知系统中是有用的。触发提供了要针对给定情形定义和应用的网络发起的封装。在一实施例中，触发向客户端或服务提供简单的通知，或者可以并入完全在网络内执行的复杂的事务逻辑。这在网络带宽和处理资源有限的无线领域是有帮助的。

例如，无线内容传送服务可能基于用户状态和他们的相关设备能力要求特定行为。即，已针对体育播报/警报服务选择进入的具有不同设备的用户可以以不同方式接收内容。例如，与具有拥有内建媒体处理能力的特征完全的个人数字助理/智能电话相比，具有极为简单的基于文本的无线设备并且仅能接收具有棒球相关内容和/或指向附加信息的基于web的URL的短消息服务(SMS)的第一用户需要不同的数据。第二用户可以接收多媒体警报消息，多媒体警报消息包含体育“当天赛事”的短的全彩视频剪辑。

上述每种情况示意了用于传送与每个用户设备相关的适当/即时内容的内容传送服务的基本复杂度。即，典型地，对于给定用户状态、以及他们的相关兴趣和用于接收内容的有关设备能力，内容传送服务有一定的理解。与情境感知即时状态能力结合工作的内容传送服务就是这样的平台。此外，代表内容传送服务公开有关“方面触发”的情境感知平台提供了用于向相关订户库通知或推送有关信息的有用方式。

具有相关触发的方面是在连续或指定的基础上的“受监控方面”。即，当实体(人或逻辑实体)得到或有资格获得相关方面触发时，相关触发“启动”，逻辑或动作集合发生。逻辑本质上是情境的，并且允许定义和执行服务和/或用户特有的动作。该动作可以是向适当的客户端设备发送或推送有关信息。关于方面，可以将方面触发扩大为封装诸如位置等各种非即时状态指示符。

本系统和方法包括针对服务/即时状态平台所需的任意数量的方面的机制。这可以包括一般方面触发的集合，如“可用性”、“选择进入”、“可达”等以及应用特有的触发。在一实施例中，方法存在于用于将方面触发的适当集合与给定服务相关联的即时状态平台或管理接口内。方面触发的关联在本质上是情境的，并且可以适用于不同级别。例如，给定方面触发可以适用于诸如OMA无线一键通兼容服务等服务使能器。此外，触发可以适用于一种类型的服务或以一种类型的服务为范围。例如，这可以使“可用性”适用于所有类型的服务。此外，触发可适用于用户或组级别。

参照图2和9将理解，通过将方面抽象为情境感知层简化了对客户端是否“可达”的确定。此外，触发可以调用方面或者可以代表触发调用方面。这可以通过基本服务使能器来实现，无需任何客户端设备的参与。触发可以调用所定义的方面和/或可以并入由包括对其他方面的调用的规则/流程组成的逻辑。

缺省情况下，方面触发将向相关客户端发回适当的通知。然而，服务、类型服务、使能器、用户或组可以修改/定义触发，所述触发专门在网络内执行动作无需任何客户端参与。

以下参照图14示出了调用流。方面触发不需要代表客户端或服务的相关订阅。假定在网络内计算或导出触发，作为方面触发的结果，感兴趣的观察者(客户端设备或交互工作的服务/使能器)可以接收自发的或异步通知。可以利用不同的通信方式处理通知。例如，作为方面触发启动的结果，客户端设备可以接收SMS通知。此外，其他服务响应于相关触发，可以接收OMASIP/PUSH 1.0通知。

通信的内容对于触发是特定的，并且可以包括诸如对于一个或多个呈现体的记录的地址、有关的一个或多个方面的方面指示符或标记、URL、用于接收实体确保方面被导向或与适当观察者相关联的服务或应用路由标记等项目。

每个接收通知的客户端或服务可以根据相关的传输协议进行响应。此外，方面触发指示可以是持久的。即，如果针对给定的“感兴趣的观察者”计算了触发但该观察者不可达，可以保持或对方面指示进行排队，直到给定用户能够适当接收到相关触发为止。这对给定通知可以比给定客户端用户会话长的情形是有用的。

参照图14，客户端设备1410与服务使能器1412通信，服务使能器1412与感知层(AL)1414(如情境感知层(CAL))通信或与感知层(AL)1414(如情境感知层(CAL))集成。

如图14可见，利用消息1420建立触发，此刻AL 1414设置触发(如1422中所示)，并对触发进行评估(如1424中的箭头所示)。

箭头1422建立触发。这可以包括覆盖或扩展触发的缺省步骤，从各种源获得数据/对数据进行评估，以及可能地向一个或多个用户发出通知。

箭头1424所示的评估表示，当触发启动时，封装记录的地址、方面或应用信息，并将通知发送至客户端设备或服务。用箭头1430示出了该通知。

在某些情况下，可以返回响应或确认，并且箭头1432示出了这点。

如图14所示，接着，AL 1414可以继续监控或评估触发是否应当启动，如箭头1450所示。

以上策略、方面和规则/阈值可以利用WSBPEL 2.0形式的web服务事务过程执行语言。WSBPEL 2.0提供了表示在P/CAM方案中(整体或部分)实现即时状态规则或触发所需的逻辑序列的机制。用于指定逻辑流和(通过web服务描述语言(WSDL)类型绑定)调用原语的正式语言(如PEEM/PEL)代表用户或服务向即时状态情境提供规则和/或触发的无限组合。还应当注意的是，可以创建更复杂的情境流，并(通过伙伴链接)将情境流链接在一起，以执行工作流和或即时状态相关的和与所连接的平台情境相关的事务逻辑。类似地，如果适用，触发还可以调用规则。在其他实施例中，可以利用传统编程语言(如Java)或制图工具(如被翻译成规则的序列、流程图、用例图)来执行表示规则。

所属领域技术人员将理解，使用情境感知层通过减少移动设备和网络间流动的信息量以及通过从移动设备中移除处理节省了设备和网络资源。

为了与本系统和方法比较，以下关于图1示出信息流的示例。特别的，当Alice希望向Bob发送PoC警报时，可能进行以下XDM获取：

GET/pidf-manipulation/users/sip:bob@example.com/index/～～/tuple/service-desciption/service-id＝％22org.openmobilealliance:PoC-alert％22 HTTP/1.1

作为响应，返回如下示意的‘原始即时状态文档’：

    HTTP/1.1200/OK

    Etag:“eti87”

    Content-Type:application/pidf+xml

    ...

    <？xml version＝″1.0″encoding＝″UTF-8″？>

    <presence xmlns＝″urn:ietf:params:xml:ns:pidf″

         xmlns:pdm＝″urn:ietf:params:xml:ns:pidf:data-model″

  xmlns:rpid＝″urn:ietf:params:xml:ns:pidf:rpid″

         xmlns:caps＝″urn:ietf:params:xml:ns:pidf:caps″

         xmlns:op＝″urn:oma:xml:prs:pidf:oma-pres″

         xmlns:xsi＝″http://www.w3.org/2001/XML Schema-instance″

         entity＝″sip:bob@example.com″>

          <！--Document returned to agent，from presentity Bob...-->

          <tuple id＝”a1232”>

             <！--User‘Bob’basic availability(available)...-->

       <staus>

           <basic>open</basic>

       </status>

       <！--User‘Bob’willingness(willing)...-->

       <op:willingness>

           <op:basic>open</op:basic>

       </op:willingness>

       <！--User‘Bob’registration state...-->

       <op:registration-state>active</op:registration-state>

       ...

       <！--User‘Bob’service description...-->

       </op:service-description>

         <op:service-id>org.openmobilealliance:PoC-alert</op:service-id>

           <op:version>1.0</op:version>

           <op:deseription>PoCAlert Service v 1.0</op:description>

      </op:service-description>

      <！--User‘Bob’contact means...-->

      <contact priority＝”0.90”>sip:bob@example.com</contact>

      <！--User‘Bob’deviceID...-->

      <pdm:deviceID>urn:uuid:d27459b7-8213-4395-aa77-ed859</pdm:deviceID>

      <timestamp>2007-02-22T20:07:07Z</timestamp>

          </tuple>

<！--Additional service tuple forPoC-Alert...-->

<tuple id＝”a1233”>

     <status>

          <basic>open</basic>

     </status>

     <op:willingness>

         <op:basic>open</op:basic>

     </op:willingness>

     <op:registration-state>active</op:registration-state>

     <caps:servcaps>

         <caps:audio>true</caps:audio>

         <caps:text>true</caps:audio>

         <caps:video>false</caps:video>

     </caps:servcaps>

     ...

     </op:service-description>

         <op:service-id>org.openmobilealliance:PoC-alert</op:service-id>

         <op:version>1.0</op:version>

         <op:description>PoCAlert Service v1.0</op:description>

     </op:service-description>

     <contact priority＝”0.90”>sip:bob@example.com</contact>

     <pdm:deviceID>urn:uuid:d27459b7-8213-4395-aa77-ed859</pdm:deviceID>

     <timestamp>2007-02-22T22:07:27Z</timestamp>

</tuple>

<！--Person definition for Bob(as authorized for class‘forFriends’...-->

<pdm:person id＝”a1234”>

   <！--Activities(meeting)...-->

   <rpid:activities>

       <rpid:meeting/>

   </rpid:activities>

   <rpid:class>forFriends</rpid:class>

    <！--Place Additional service tuple forPoC-Alert...-->

    <rpid:place-type><lt:office/></rpid:place-type>

    <pdm:timestamp>2007-02-22T22:07:07Z</pdm:timestamp>

</pdm:person>

<！--Device associated withPoC-Alert...-->

<pdm:device id＝”a1235”>

    <op:network-availability>

        <op:network id＝”IMS”>

            <op:active>

        </op:network>

    </op:network-availability>

    <pdm:deviceID>urn:uuid:d27459b7-8213-4395-aa77-ed859</pdm:deviceID>

    <pdm:timestamp>2007-02-22T22:07:07Z</pdm:timestamp>

</pdm:device>

</presence>

因此，以上示意了传统系统和方法返回的大(就字节或字符数而言)即时状态文档，需要巨大的电池资源以进行接收以及网络资源以进行发送。

所属领域技术人员将理解，以上所示的结果‘原始即时状态文档’还可以通过OMA/Presence SIP:NOTIFY请求(代表授权的观看者)来传送。对于该示例，XDM获取用于简化网络流。

下面参照图9。图9示出了当利用情境感知层(P/CAM)时移动设备上的示例过程。图9的方法代替并简化了图2的方法。

在图9中，过程起始于框910，并前进至框912，在框912中，调用P/CAM以建立‘Bob’的‘可达’即时状态方面和服务‘PoC警报’。框912等待返回结果，并且基于结果过程可以前进至框920，框920指示‘不可达’，并且终止于框922。可选地，过程从框912前进至框930，框930指示‘Bob可达’并终止于框932.

由上将理解的是，PoC警报客户端内的可达性此时是单独的处理框(可达/不可达)。应当注意的是，给定情境感知应用的处理框的数量同复杂度和与应用或服务相关的即时状态有关功能的数量成正比减少。

将图2中概述的传统PoC客户端应用和图9中情境感知客户端应用间的网络带宽需求比较，提供了一个数量级的网络开销降低。将针对传统PoC客户端的利用原始即时状态信息的XDM获取与针对情境感知‘可达’即时状态方面的SOAP方法调用(作为示例部署情形)比较，以下是请求的示例：

POST/CAM-1HTTP/1.1

...

HOST:pcam.example.com

Content-Type:text/xml；charset＝″utf-8″

...

<！--SOAP request...-->

<SOAP-ENV:Envelope

  xmlns:SOAP-ENV＝″http://schemas.xmlsoap.org/soap/envelope/″

SOAP-ENV:encodingStyle＝″http://schemas.xmlsoap.org/soap/encoding/″>

<SOAP-ENV:Body>

    <pcam:reachable xmlns:pcam＝″http://pcam.example.com/wsdl/oma-pres-pcam″>

      <aor>sip:bob@example.com</aor>

      <service>org.openmobilealliance:PoC-alert</service>

    </pcam:reachable>

  </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

以下是响应的示例：

HTTP/1.1200/OK

Connection:close

...

Content-Type:text/xml；charset＝″utf-8″

...

<！--SOAP response...-->

<SOAP-ENV:Envelope

  xmlns:SOAP-ENV＝″http://schemas.xmlsoap.org/soap/envelope/″

  SOAP-ENV:encodingStyle＝″http://schemas.xmlsoap.org/soap/encoding/″>

  <SOAP-ENV:Body>

   <pcam:reachableResp xmlns:pcam＝″http://pcam.example.com/wsdl/oma-pres-pcam″>

        <result>reachable</result>

   </pcam:reachable>

  </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

因此，以上示意了所需传输的数据的减少，以及客户端所需处理的减少。

以下参照图10示出了另一示例。提供图10，以示出广告代理‘Ad-Inc.’希望以通用移动广告活动到达消费者的示例。Ad-Inc想要基于特定准则优化对资源受约束设备的广告传送。例如，广告活动由小视频序列构成，因此设备必须是可达的，具有特定的媒体能力，并且具有少量电池电量使得广告能够i)适当地呈现在设备上，并且ii)不引起设备损失大量电池，从而热闹预期消费者并引起与正在做活动的品牌的负面关联。移动广告使能器“MobAd”通过以适当的逻辑流引入策略(如PEEM/PEL)‘过程’文档向P/CAM指定被称为‘广告合格性’的新的即时状态方面。类似地或组合地，MobAd应用可以指定位置方面。

在图10中，过程起始于框1010并前进至框1012，在框1012中，调用P/CAM以建立设备是‘广告合格的’、呈现体顾客的即时状态方面和服务’MobAd’。

框1012等待来自P/CAM的响应，并根据结果前进至框1020，在框1020中，顾客被认为不是“广告合格的”。过程从框1020前进至框1022并且终止。

相反，从框1012起，如果来自P/CAM的结果将顾客看作“广告合格的”，过程可以前进至框1030。将理解的是，‘广告合格’可以被看作方面以上表2中定义的‘合格会话参与者’的特定变体。接着，处理前进至框1032并终止。

与图10中MobAd广告合格性即时状态方面有关的处理框明显少于独立MobAd代理或客户端自身处理该元数据所需的处理框需要的处理框。需要向图2所示的逻辑流添加附加的复杂度，以支持解决阈值策略和媒体能力的附加逻辑。可替代地，作为新的即时状态方面(即时状态方面构建块)将该逻辑并入情境感知层并将它们连系在一起，以代表MobAd(广告合格性)计算情境即时状态。

参照图11示出了另一示例。图11示出了示例情形，其中，动态内容传送(DCD)服务器希望经由驻留在用户设备上的DCD客户端向支持DCD的客户端应用(DECA)发送DCD内容。DCD服务器被看作支持DCD的客户端应用(呈现体)的观看者。DCD服务器想要在仅当DCD客户端可达且在DCD客户端推送内容后相关设备的存储容量高于预定义存储门限时，才将内容发送至相关的支持DCD的客户端应用。这样，DCD服务器寻求确保所推送或以其他方式发送的内容不会非期望地耗尽设备的存储容量。为此，DCD通过以适当的逻辑流引入PEEM/PEL‘过程’文档来向P/CAM建立新的被称为‘内容可推送’的即时状态方面。再次，该方面类似于‘合格会话参与者’方面，只不过此处已针对DCD使能器对准侧或方面进行适配、覆盖或其他方式的配置。在本情况下，客户端是可达的，并且具有给定存储空闲空间。

参照图11，过程起始于框1110。接着，处理前进至框1112，在框1112中，调用P/CAM建立呈现体‘顾客’的‘内容可推送’即时状态方面和服务‘DCD’。来自P/CAM的结果确定过程是前进至框1120并判决DECA不是‘内容可推送的’还是前进至框1130并判决DECA是‘内容可推送的’。

过程分别从框1120和1130前进至框1122或框1132，并终止。

图11中与DCD内容可推送即时状态方面相关的处理框由P/CAM执行，从而DCD服务器简单地调用P/CAM中的规则，提供诸如设备ID、服务id和内容大小等输入参数。此时可以作为新的即时状态方面(即时状态方面构建块)将该规则并入情境感知层并将它们连系在一起，以代表DCD(内容可推送)计算情境即时状态。

以下示例中示意了上述内容。

即时消息客户端

使用情境感知层的一示例客户端应用是即时消息应用。此处，即时消息应用被称为“MyFriendlyChat”。

在大学环境中，例如，许多朋友可能在他们的移动设备上加载了“MyFriendlyChat”应用。在该示例中，用户Alice是完成了一天课程的大学学生。她正前往学院餐厅，并想要知道是否有她的朋友在她附近以和她一起用餐。

Alice拿出她的无线设备并启动“MyFriendlyChat”应用并调用“邀请附近朋友聊天”功能。该功能利用即时状态和位置返回位于预定距离内并具有可达状态的朋友的列表。“MyFriendlyChat”应用返回活动朋友列表，显示Bob和Jane在附近并且可达。

Alice在她的设备上输入短消息，令她的朋友知道她正要取学院餐厅。Bob和Jane从接收到来自Alice的消息，并回复他们将马上与她会合。

以上示出了同时利用即时状态和位置以确定并向用户返回相关信息的客户端应用。特别地，“邀请附近朋友聊天”功能要求知道附近朋友的位置以及即时状态信息，以允许即时消息发生。

在即时消息的传统模型下，将需要查询即时状态平台以获得原始数据的列表，原始数据的列表接着必须由客户端应用进行处理。此外，在这种情况下，还可以要求查询位置平台以找到朋友列表中的个体的位置。

根据本公开，方面可以被抽象为位于网络内的情境感知层。情境感知层可以是诸如位置和即时状态平台等平台的一部分、专用服务器的一部分、即时状态或位置服务器的一部分、或者可以分布在这些实体之间。在某些情况下，无线设备或另一计算机上可以存在情境感知层的代理。

客户端应用的功能被置于情境感知层内，从而在变化的客户端应用间提供一致结果，并且还减少了移动设备和网络间需要的信令。

对于上述内容，“MyFriendlyChat”客户端应用在OMA/PRS实现中起观看者和即时状态源的功能，并且在情境感知层实现中起即时状态源的功能。

情境感知层利用预定义方面来确定是否能够到达Bob和Jane。在这种情况下，方面可以是“合格会话参与者”，其被定义为基于给定准则选择一个或多个呈现体。在这种情况下，对于应用“MyFriendlyChat”覆盖方面“合格会话参与者”以从组列表中选择那些“愿意、可达并且在附近的”“朋友”。被覆盖的即时状态方面是在指示来自在无线设备上执行的“MyFriendlyChat”客户端的任意方面前配置的。

至于调用流，客户端应用必须确定谁愿意、可达并且在附近，以发起消息数据报，从而邀请这些“朋友”吃饭。为了实现该功能，假定“MyFriendlyChat”应用通过OMAPRS/RLS组件订阅Alice的朋友列表的成员。

此后，客户端应用仅需要基于情境感知层结果，向合格会话参与者发起通信。

可以对方面应用各种规则，以使其进一步变窄。例如，当确定谁在附近并且可达时，可以对朋友的子集施加限制。因此，规则可以是当发出请求时仅返回大学朋友。

继续以上示例，一旦Alice、Bob和Jane到达餐厅，Alice可以在她的移动设备上设置方面触发，以在她的任何朋友在预定时段内位于餐厅的特定距离范围内的情况下对她发出警报。例如，Alice可以在她的设备上设置触发，以指示如果任何“朋友”在接下来的半小时内位于0.5公里内则应当向她发送警报。

在该示例中，Jim满足这些准则并且Alice在她的移动设备上接收到Jim已进入指定区域的通知，因此Alice能够邀请Jim加入该组。

将理解的是，以上示意了方面触发的示例。特别的，触发是针对方面“合格会话参与者”建立的，并且可以调用触发，例如，一旦为真，“isEligibleSessionParticipant”可以引起向Alice发送警报。将理解的是，这样的警报可以包括可听音调、震动、或任何这样的向用户指示已经满足触发条件的通知。

再次，利用情境感知层有助于使用触发，并且减少了移动设备和网络间的通信，从而节省了电池书名和移动设备上的处理能力和移动设备。

移动广告情形

在上述内容的另一示例中，汽车公司XYZ Motor Cars希望广告活动迎合新的运动型汽车型号的推出。XYZ Motor Cars雇佣Split-second广告公司进行广告宣传，Split-second利用ABC Telecom作为无线服务/内容传送提供商。

Split-second确定了新汽车型号的广告活动，以年龄在23到30岁的对自行车、野营、橡皮艇感兴趣的个体为目标。广告包含与不同运动一起使用的新型号的各种相片、视频片段等。

Jack、Phyllis、Lynn和George都同意接收与广告相关的内容。Andrew属于XYZ Motors的目标市场，但未选择接收广告内容。Jack，Lynn和George属于XYZ Motors的目标市场。

对于以上情形，ABC广告公司针对广告活动配置它们的无线广告平台。在无线广告平台内建立触发，其中触发监控满足给定广告活动的Split-second准则、选择接收广告、“可达”、并且具有接收相关视频剪辑能力的适当识别的个体。

ABC开始活动，以迎合XYZ的新型号的推出日期，导致以上定义的情境感知层触发启动。

稍后，Jack、Lynn和George接收包含与XYZ Motors介绍的新汽车有关的信息在内的消息。广告内容针对每个设备进行了适当的适配。例如，Jack可能接收到具有到XYZ Motor的推出网站的WAP-URL的WAP-Push SMS，而Lynn和George都接收到附有短视频剪辑的多媒体消息(MMS)。

由于Phyllis和Andrew不满足广告活动的准则，不联系他们。然而，如果未来但仍在广告活动期间，Andrew选择接收无线广告消息，XYZMotor公司广告将被发送至Andrew。

以上是利用各种方面实现的。“可达”方面可用于确定是否能够到达Jack、Lynn和George以向其发送广告消息。诸如“选择进入”等方面可用于确定用户是否已选择接收广告。

还可以利用触发。在这种情况下，诸如“isEligibleSessionParticipant”等触发被用于返回一个或多个用户，所述一个或多个用户选择进入无线广告以及内容传送服务、可达、并且拥有具有媒体能力的适当集合的设备。在这种情况下，方面触发的缺省动作可以是导引情境感知层发起适合于用户的内容。因此，例如，可以向客户端设备上的广告应用发送无直接无线指示。

情境感知层可以包括诸如“MobileAdvertisingPreferences”等信息，“MobileAdvertisingPreferences”定义了存储在适当XDMS中的一组移动广告特定的偏好。位于设备中的无线广告客户端可以调用该实体，以返回移动广告有关的偏好。

其他信息可以包括“ContentDeliveryPreferences”，“ContentDeliveryPreferences”具有存储在适当XDMS中的一组内容传送偏好stored in an适当XDMS。设备中的无线广告客户端或其他组件可以调用该实体以返回内容传送/服务/应用/设备偏好。

广告示例提供了利用两个一起工作的单独使能器的情境感知层。特别地，利用移动广告和内容传送使能器获得特定的功能点。在即时状态服务中，这样的交互是不可能的。

研究表明，在特定条件下，利用情境感知层的数据传输节约在约40％和约75％之间。因此，情境感知层的使用提供了对网络资源和移动设备上电池寿命的节约。

情境感知层还通过允许在情境感知层定义方面、规则、策略和触发提供多个和变化的客户端应用的连接。这提供了情境感知层能够为多个客户端应用服务并且无需针对每个特定的客户端应用重新创建的优势。

此处描述的实施例是具有与本申请的技术要素相对应的要素的结构、系统或方法的示例。该书面描述可以使所属领域技术人员能够实现和使用具有与本申请的技术要素相对应的类似可替换要素的实施例。因此，本申请的技术的范围意在包括不同于此处描述的本申请的技术的其他结构、系统或方法，还包括同此处描述的本申请的技术具有非实质性差异的其他结构、系统或方法。

Claims (45)

1.一种用于由服务或应用创建方面的计算执行环境内的方法，所述方面是与源或服务有关的应用级抽象，所述方法包括：

定义有关服务方面；

将服务方面作为所命名的方面插入或封装入执行环境的情境感知层，所述情境感知层适于从多种应用类型或服务调用；以及

将所命名的方面与情境感知层中的逻辑关联，以支持应用或服务功能。

2.根据权利要求1所述的方法，其中，所述情境感知层包括服务器。

3.根据权利要求1所述的方法，其中，所命名的方面与即时状态、位置或通用方面中的至少一项有关，或者表示即时状态、位置或通用方面的所计算的或组合的指示。

4.根据权利要求1所述的方法，其中，对观察者公开的所命名的方面与应用的情境、组或范围有关。

5.根据权利要求1所述的方法，其中，对观察者公开的所命名的方面在多种应用类型或服务中是公共的。

6.根据权利要求1所述的方法，其中，所述方法还包括：

在应用生命期中的一刻，提供与所命名的方面相关的策略，所述策略指定所命名的方面的行为或处理。

7.根据权利要求6所述的方法，其中，所述策略是用开放移动联盟(OMA)策略评估执行和管理(PEEM)内的策略表示语言(PEL)表示的。

8.根据权利要求6所述的方法，其中，策略动作是通过扩展标记语言(XML)文档管理一般策略扩展提供的。

9.根据权利要求8所述的方法，其中，策略表示语言(PEL)规则集文档被创建以针对特定情境感知层并入扩展动作。

10.根据权利要求9所述的方法，其中，所述规则集文档与使能器标识符关联，以提供策略的范围，与应用或服务标识符关联，以提供策略的范围，并且其中，所述规则集文档适用于用户、组或范围。

11.根据权利要求1所述的方法，还包括：

建立规则和触发中的至少一个，以提供用于计算方面的步骤序列或逻辑。

12.根据权利要求11所述的方法，其中，所述触发是用开放移动联盟策略评估执行和管理(PEEM)表示语言定义的。

13.根据权利要求11所述的方法，其中，所述规则是用web服务事务过程执行语言定义的。

14.根据权利要求13所述的方法，其中，所述web服务事务过程执行语言是WSBPEL 2.0。

15.根据权利要求11所述的方法，其中，所述规则和策略中的至少一个包括门限。

16.根据权利要求11所述的方法，其中，所述规则作为函数或过程而被封装。

17.根据权利要求16所述的方法，其中，所述函数或过程定义了情境感知层在计算其他方面时使用的库或组件。

18.根据权利要求1所述的方法，其中，所命名的方面是情境感知层内组件库的一部分。

19.根据权利要求18所述的方法，其中，来自组件库的所命名的方面可以在计算其他方面时被调用。

20.根据权利要求1所述的方法，其中，方面是选择进入或愿意方面，用于确定呈现体是否愿意参与给定服务或应用的会话。

21.根据权利要求1所述的方法，其中，方面是可用方面，用于确定呈现体是否可用于利用给定服务或应用进行通信。

22.根据权利要求1所述的方法，其中，方面是联系方式方面，用于确定是否为呈现体提供了针对给定服务或应用的最适用的联系方法。

23.根据权利要求1所述的方法，其中，方面是联系方面，用于确定呈现体是否愿意、可用并且具有对于给定服务或应用的当前有效的联系方式。

24.根据权利要求1所述的方法，其中，方面是可达方面，使得呈现体对于给定设备上的给定服务或应用是可联系的。

25.根据权利要求1所述的方法，其中，方面是你在哪里方面，从而提供呈现体的当前位置。

26.根据权利要求1所述的方法，其中，方面是服务体现方面，从而为呈现体提供针对给定服务或应用的当前图标表示。

27.根据权利要求1所述的方法，其中，方面是个人兴趣方面，从而提供呈现体的当前兴趣、爱好、应用特定的用户偏好。

28.根据权利要求1所述的方法，其中，方面是谁在附近方面，从而提供位于附近并满足准则集的零个或更多个呈现体的列表。

29.根据权利要求1所述的方法，其中，方面是合格会话参与者方面，从而呈现体是可达的并且满足可选准则集，以参与相关服务的会话。

30.一种执行环境，包括：

具有应用类型的客户端应用，所述客户端应用采用服务方面来执行，所述服务方面是与源或服务有关的应用级抽象；以及

情境感知层，适于：

将服务方面作为所命名的方面而插入或封装；

从多种应用类型或服务调用；以及

将所命名的方面与情境感知层中的逻辑关联，以支持应用或服务功能点。

31.根据权利要求30所述的执行环境，其中，所述服务方面是与应用或服务有关的应用级抽象，并且与给定用户、组标识或给定数据相关。

32.根据权利要求30所述的执行环境，其中，基于应用、服务、给定用户、组标识或给定数据来扩展或增强所述方面。

33.根据权利要求31所述的执行环境，其中，基于应用、服务、给定用户、组标识或给定数据来扩展或增强所述服务方面。

34.根据权利要求30所述的执行环境，其中，所述服务方面与即时状态、位置或通用方面中的至少一个或组合有关。

35.根据权利要求30所述的执行环境，还包括：在情境感知层提供的、并且在应用生命期中的一刻与所述方面相关的测量，所述策略指定方面的行为或处理。

36.根据权利要求35所述的执行环境，其中，所述策略是用开放移动联盟(OMA)策略评估执行和管理(PEEM)内的策略表示语言(PEL)表示的。

37.根据权利要求36所述的执行环境，其中，策略动作是通过扩展标记语言(XML)文档管理一般策略扩展提供的。

38.根据权利要求37所述的执行环境，其中，策略表示语言(PEL)规则集文档被创建以并入特定抽象层需要的扩展动作。

39.根据权利要求38所述的执行环境，其中，所述规则集文档与使能器标识符关联，以提供策略的范围，或与应用或服务标识符关联，以提供策略的范围。

40.根据权利要求38所述的执行环境，其中，所述规则集文档适用于用户、组或范围。

41.根据权利要求30所述的执行环境，其中，所述情境感知层还适于：建立规则和触发中的至少一个，以提供用于计算方面的步骤序列或逻辑。

42.根据权利要求41所述的执行环境，其中，所述触发是用开放移动联盟策略评估执行和管理(PEEM)表示语言定义的。

43.根据权利要求41所述的执行环境，其中，所述规则是用web服务事务过程执行语言定义的。

44.根据权利要求43所述的执行环境，其中，所述web服务事务过程执行语言是WSBPEL 2.0。

45.根据权利要求41所述的执行环境，其中，所述规则和策略中的至少一个包括门限。

Images