CN101115094B - 提供通信业务的方法和***及触发器装置 - Google Patents

Abstract

本发明公开了一种提供通信业务的方法，步骤包括触发器装置接收客户端发送的业务触发信息并保存，触发器装置从状态服务器获取状态信息，根据获取的状态信息当触发条件满足时向业务服务器发送业务触发通知，业务服务器根据通知提供业务。还相应公开了一种提供通信业务的***和触发器装置。通过本发明使业务服务器可以实现基于状态信息来触发业务，不用扩展与各种状态服务器的接口，还提高了业务***的可扩展性和通用性。

Description

提供通信业务的方法和***及触发器装置

技术领域

本发明涉及通信领域，尤其涉及一种提供通信业务的方法和***及触发器装置。 

背景技术

目前有些通信业务中提供定时触发业务的特性，如在短消息业务SMS(Short Message Service)中，用户可以使用业务提供商SP(Service Provider)提供的定时提醒短消息功能，使用户在某个设定的时刻获得一条预先设置好内容的短消息。具体的实现步骤为：通过客户端预先设置一条定时提醒短消息，其中包括业务触发的时间条件和消息内容，保存在应用服务器中；当应用服务器检测到时间条件满足时，将预先设置的消息内容通过短消息中心SMSC(Short Message Service Center)发送给用户。 

而有些情形用户希望在某人处于某个状态时发送一条短消息或多媒体消息(Multimedia Messaging Service)给某些其他用户，或者发送给自己。在即时消息IM(Instant Messaging)、一键通PoC(Push to talk over Cellular)等通信业务中，用户希望业务服务器根据用户的状态信息(如呈现信息、位置信息等)发起群组通信会话等。 

发明内容

本发明给出了一种提供通信业务的方法，用以解决现有技术只能根据时间条件触发通信业务，而无法根据状态信息触发和提供通信业务的问题。 

本发明提供通信业务的方法包括步骤： 

触发器装置接收客户端发送的包含触发条件的业务触发信息并保存； 

触发器装置从状态服务器获取与业务触发信息相关的状态信息，所述状态 信息为呈现信息或位置信息； 

根据获取的状态信息当触发条件满足时触发器装置向业务服务器发送业务触发通知； 

业务服务器根据所述通知提供业务。 

进一步，所述的状态服务器为呈现服务器或位置服务器； 

当触发器装置从呈现服务器或位置服务器获取与业务触发信息相关的呈现信息或位置信息时，呈现服务器或位置服务器在鉴权成功后才向触发器装置返回呈现信息或位置信息。 

呈现服务器或位置服务器的鉴权步骤具体为：呈现服务器或位置服务器向通用权限管理服务器发送鉴权请求，通用权限管理根据授权配置进行鉴权并向呈现服务器或位置服务器返回鉴权结果；或者，呈现服务器或位置服务器根据授权配置进行鉴权。 

触发器装置从状态服务器获取与业务触发信息相关的状态信息之前，先根据业务触发信息向通用权限管理服务器发送鉴权请求，接到鉴权成功的结果后才向状态服务器获取状态信息。 

所述的触发器装置包括第一服务器和第二服务器； 

第一服务器接收客户端发送的包含触发条件的业务触发信息并保存； 

第二服务器从第一服务器获取业务触发信息，从状态服务器获取与业务触发信息相关的状态信息； 

根据获取的状态信息当触发条件满足时第二服务器向业务服务器发送业务触发通知。 

所述触发条件中包括时间条件和状态条件，则触发器装置在所述的时间条件满足时，才向状态服务器获取与所述状态条件相关的状态信息。 

在触发器装置向业务服务器发送业务触发通知后，还向所述客户端发送指示业务已经被触发的通知； 

触发器装置删除已经完成或过期的业务触发信息。 

所述的业务触发信息还包括指示业务类型、业务内容、联系人标识的信息。业务类型还可以同时指示业务内容信息，触发条件中也可以包含指示联系人标识的信息。 

进一步，所述触发条件中包含了对联系人的状态筛选条件，触发器装置根据获取的状态信息和所述的对联系人的状态筛选条件确定满足条件的联系人标识，向业务服务器发送包含业务内容和满足条件的联系人标识的业务触发通知。 

在发送业务触发通知时，触发器装置向所述业务类型对应的业务服务器发送包含业务内容和联系人标识的通知消息。 

一个业务触发信息中业务类型多于一个时，不同的业务类型关联不同的业务内容和联系人标识；在发送业务触发通知时，触发器装置分别向各业务类型对应的业务服务器发送其关联的联系人标识和业务内容。 

所述的业务触发通知中包括业务内容和联系人标识；业务服务器根据所述通知提供业务的步骤具体为：业务服务器向所述联系人标识提供所述的业务内容。 

触发器装置根据业务类型将联系人标识和业务内容封装到相应协议格式的消息； 

如果业务类型为短消息，则触发器装置使用SMPP协议发送联系人标识和业务内容给短消息中心； 

如果业务类型为多媒体消息，则触发器装置使用MM7接口协议发送联系人标识和业务内容给多媒体消息中心； 

如果业务类型为电子邮件，则触发器装置使用SMTP协议发送联系人标识和业务内容给电子邮件服务器； 

如果业务类型为即时消息，则触发器装置使用SIP MESSAGE协议发送联系人标识和业务内容给即时消息服务器。 

所述的状态服务器为呈现服务器，触发器装置通过发送包含与所述触发条件相应的过滤信息的订阅请求从呈现服务器获取呈现信息。 

在业务内容中存储资源链接，指向存储在内容服务器的资源内容； 

业务服务器根据所述通知提供业务的步骤具体为：业务服务器根据业务内容中的资源链接从内容服务器获取相应的资源内容，然后向所述的联系人标识提供所述的资源内容。 

本发明还提供了一种触发器装置，所述的装置用于接收客户端发送的包含触发条件的业务触发信息并保存，并从状态服务器获取与业务触发信息相关的状态信息，所述状态信息为呈现信息或位置信息，然后根据获取的状态信息检测到触发条件满足时向业务服务器发送业务触发通知。 

所述的装置包括第一服务器和第二服务器； 

第一服务器用于接收客户端发送的包含触发条件的业务触发信息并保存； 

第二服务器用于从第一服务器获取业务触发信息，从状态服务器获取与业务触发信息相关的状态信息，根据获取的状态信息检测到触发条件满足时向业务服务器发送业务触发通知。 

所述的装置还用于在接收到业务服务器发送的包含条件评估请求的消息时，向状态服务器订阅获取条件评估所需要的状态信息，在进行评估处理后将包含条件评估结果的消息返回给业务服务器。 

本发明还提供了一种提供通信业务的***，所述的***包括触发器装置，状态服务器和业务服务器； 

所述的触发器装置用于接收客户端发送的包含触发条件的业务触发信息并保存，从状态服务器获取与业务触发信息相关的状态信息，所述状态信息为呈现信息或位置信息，根据获取的状态信息当检测到触发条件满足时向业务服务器发送业务触发通知； 

所述的状态服务器用于向触发器装置提供状态信息； 

所述的业务服务器用于在接到业务触发通知时根据所述通知提供业务。 

所述***中的触发器装置还用于在接收到业务服务器发送的包含条件评估请求的消息时，向状态服务器订阅获取条件评估所需要的状态信息，在进行评估处理后将包含条件评估结果的消息返回给业务服务器。 

所述的***还包括内容服务器，用于存储业务触发信息中的资源链接所指向的资源内容，并向业务服务器提供资源内容。 

所述的***还包括通用权限管理服务器，用于接收状态服务器或触发器装 

置发送的鉴权请求，并根据授权配置进行鉴权，然后向状态服务器或触发器装置返回鉴权结果。 

所述***中的触发器装置包括第一服务器和第二服务器； 

第一服务器用于接收客户端发送的包含触发条件的业务触发信息并保存； 

第二服务器用于从第一服务器获取业务触发信息，从状态服务器获取与业务触发信息相关的状态信息，根据获取的状态信息检测到触发条件满足时向业务服务器发送业务触发通知。 

本发明有益效果如下： 

本发明的提供通信业务的方法和***以及触发器装置通过利用触发器装置接收客户端发送的包含触发条件的业务触发信息并保存，从状态服务器获取与业务触发信息相关的状态信息，然后根据获取的状态信息当触发条件满足时触发器装置通知业务服务器提供业务，使业务服务器可以实现基于状态信息来触发业务，而且不用扩展与各种状态服务器的接口，分配大量资源处理与其它状态服务器交互以及进行条件判断和评估的问题，还提高了业务***的可扩展性和通用性。 

附图说明

图1为本发明提供通信业务的方法基本流程图； 

图2为本发明提供通信业务的***结构图； 

图3为本发明具体实施例一的***结构图； 

图4为本发明具体实施例四的流程图。 

具体实施方式

为了便于本领域一般技术人员理解和实现本发明，现结合附图描绘本发明的实施例。 

本发明公开了一种提供通信业务的方法，基本流程如图1所示： 

步骤101、触发器装置接收客户端发送的包含触发条件的业务触发信息并保存； 

步骤102、触发器装置从状态服务器获取与业务触发信息相关的状态信息； 

步骤103、根据获取的状态信息当触发条件满足时触发器装置向业务服务器发送业务触发通知； 

步骤104、业务服务器根据所述通知提供业务。 

其对应的***结构图如图2所示，包括触发器装置，状态服务器和业务服务器，以及客户端。其中状态服务器可以为呈现服务器或位置服务器等，可以有多个，如***中同时设置有呈现服务器和位置服务器。此处的客户端是指设置业务触发信息的用户终端，可以是移动电话、计算机、个人数字助理PDA(Personal Digital Assistant)等，而在上述步骤104中业务服务器并不是仅限 定于只向该客户端提供业务，也可以向其他的客户端提供业务。业务服务器是指最终向用户提供具体业务的服务器，可以是PoC服务器、即时消息IM服务器、短消息中心SMSC、多媒体消息中心MMSC(Multimedia Messaging ServiceCenter)、电子邮件Email服务器或者应用服务器AS(Application Server)等，***中业务服务器也可以有多个，如同时存在SMSC和MMSC等。触发器装置向业务触发信息中业务类型对应的业务服务器发送业务触发通知。状态信息可以是任意自然人或非自然人呈现体的呈现信息或位置信息等，当然呈现业务中位置信息也可以作为一种呈现信息。下面结合具体实施例对本发明做进一步的详细说明。 

具体实施例一，本实施例中触发器装置包括第一服务器和第二服务器，状态服务器为呈现服务器，业务服务器为短消息中心SMSC、多媒体消息中心MMSC，***结构图如图3所示。第一服务器接收客户端发送的包含触发条件的业务触发信息并保存；第二服务器从第一服务器获取业务触发信息，从呈现服务器获取与业务触发信息相关的呈现信息；根据获取的呈现信息当触发条件满足时第二服务器向业务服务器发送业务触发通知。 

其中第一服务器可以为XML(Extensible Markup Language)文档管理服务器XDMS，以XML形式存储业务触发信息。客户端通过XCAP(XMLConfiguration Access Protocol)协议管理第一服务器中业务触发信息文档，如创建、修改和删除等。第二服务器可以直接通过XCAP协议从第一服务器中获取业务触发信息文档；或者使用会话初始协议SIP(Session Initiation Protocol)协议的订阅方法(SIP Subscribe)订阅第一服务器上存储的业务触发信息文档的变化，当文档发生变化时，可以接收到第一服务器发送的文档变化通知，如果通知中包含文档变化的具体内容，则可以根据通知更新第二服务器本地缓存的业务触发信息文档，否则第二服务器可以通过XCAP协议从第一服务器上获取最新的业务触发信息文档。 

第二服务器可以使用短消息点对点协议SMPP(Short Message Peer to Peer) 和短消息中心SMSC进行通信，当然运营商也可以选择通过其他的协议如***点对点协议CMPP(China Mobile Peer to Peer)协议等。第二服务器可以使用MM7接口或简单邮件传输协议SMTP(Simple Mail Transfer Protocol)和多媒体消息中心MMSC进行通信。 

下面结合一个完整的业务流程进行详细说明。 

A、用户通过客户端设置业务触发信息。 

客户端为支持XCAP协议的移动电话，通过PUT方法将业务触发信息保存到作为XDMS的第一服务器中。PUT消息体的具体内容举例如下，消息命令行和消息头可以包括： 

PUT http://URL HTTP/1.1 

Content-Type:application/trigger+xml 

Host:trigger.example.com 

消息体中业务触发信息内容以XML来描述： 

<triggerid=＂001＂> 

 <condition> 

   <presence> 

       <entity uri=＂sip:sunqianexample.com＂> 

           <display-name>sun qian</display-name> 

       </entity> 

       <changed to=＂open＂> 

            /pidf:presence/pidf:tuple/pidf:status/pidf:basic 

       </changed> 

   </presence> 

</condition> 

<action id=＂01＂> 

   <service>SMS</service> 

   <contact>tel uri:13048907033</contact>

   <content xml:lang=＂en＂>hello！</content> 

 </action> 

</trigger> 

其中<trigger>元素包含的内容即为业务触发信息，具有一个唯一标识id。业务触发信息主要包括： 

触发条件<condition>，包括状态条件，如呈现条件<presence>和位置条件<location>等。呈现条件<presence>还包括呈现体标识<entity>和呈现触发条件<changed>等。触发条件还可以包括时间条件，如时刻或时间段条件。 

触发动作<action>，包括业务类型<service>，业务内容<content>，联系人标识<contact>等。 

以上业务触发信息所表达的含义为：当呈现体＂sip:sunqianexample.com＂的呈现信息状态变为＂open＂时，向电话号码为13048907033的用户发送一条内容为＂hello！＂的短消息。 

以上的业务触发信息使用XML进行描述，当然也可以采用其他方式描述和存储，如关系数据表等，其内容和格式也不限于以上的描述。 

B、第一服务器保存业务触发信息，第二服务器从第一服务器获取业务触发信息。 

通常第二服务器订阅了第一服务器中XML文档的变化，因此当业务触发信息有变化如创建、修改或删除时，则可以及时通知第二服务器，第二服务器更新自己缓存的业务触发信息。当然第一服务器和第二服务器也可以合并在一起，第一服务器不用同步最新的业务触发信息到第二服务器，但是业务触发信息的数据安全性和共享性会差一些。 

C、第二服务器从呈现服务器获取与触发条件相关的呈现信息。 

第二服务器根据触发条件中呈现条件，包括呈现体标识和呈现触发条件，向呈现服务器订阅呈现体的呈现信息。呈现体标识通常为SIP URI，或者presURI等统一资源标识符，唯一标识一个呈现体资源。呈现触发条件指出哪些呈 现信息变为什么值，描述元素值或属性值的变化。因为呈现触发条件往往只涉及很少的呈现信息元素，没有必要订阅一个呈现体资源的全部呈现信息的变化，为了节省网络流量，可以在订阅消息中设置过滤信息，只获取呈现触发条件所涉及的呈现信息变化即可。含有过滤信息的订阅消息举例如下，其中消息命令行和消息头主要内容： 

SUBSCRIBE sip:sunqianexample.com SIP/2.0 

accept:application/simple-filter+xml 

from:<sip:userexample.com>；tag=47c1c9c0 

to:<sip:sunqianexample.com> 

p-asserted-identity:<sip:userexample.com> 

event:presence 

关于SIP协议的SUBSCRIBE和NOTIFY方法具体可以参考RFC3856。 

消息体包括过滤信息集，以XML描述： 

<？xml version=＂1.0＂encoding=＂UTF-8＂？> 

<filter-set xmlns=＂urn:ietf:params:xml:ns:simple-filter＂> 

  <ns-bindings> 

    <ns-binding prefix=＂pidf＂urn=＂urn:ietf:params:xml:ns:pidf＂/> 

  </ns-bindings> 

  <filter id=＂123＂uri=＂sip:sunqianexample.com＂> 

    <trigger> 

      <changed from=＂closed＂to=＂open＂> 

        /pidf:presence/pidf:tuple/pidf:status/pidf:basic 

      </changed> 

    </trigger> 

  </filter> 

</filter-set> 

其中在过滤信息<filter>中的<trigger>元素的内容和呈现触发条件是相对 应的。另外<filter>中除了可以设置何时即哪些呈现信息发生了哪些变化时发送通知外，还可以设置发送的通知中要包括哪些呈现信息，只发送呈现触发条件所需的呈现信息即可，减少通知数据包的大小。具体的可以用<waht>元素描述： 

<filter id=＂123＂uri=＂sip:sunqianexample.com＂> 

  <what><include type=＂xpath＂> 

       //pidf:tuple/pidf:status[pidf:basic=＂open＂]/pidf:basic 

  </include></what> 

</filter> 

把需要的呈现信息元素或属性使用xpath语言列在<include>元素中即可。 

一般呈现服务器对于呈现信息的订阅需要进行鉴权。当然如果第二服务器在向呈现服务器订阅之前已经对客户端进行了鉴权，或者呈现体资源的呈现信息是完全公开的，也可以不用鉴权，如对于一个代表广播电台或电视台的呈现体资源的呈现信息为节目单，则是完全公开的，无需鉴权即可提供。第二服务器可以先根据业务触发信息向通用权限管理服务器GPM发送鉴权请求，接到鉴权成功的结果后才向呈现服务器请求获取呈现信息。 

通常每个呈现体都有对应的授权配置，指示对哪些人可以提供哪些呈现信息。本发明中虽然是第二服务器向呈现服务器发起的订阅，但实际的订阅者即鉴权的对象应该是最初设置业务触发信息的客户端对应的用户。业务触发信息保存在第一服务器的用户目录下面，此处也包含了用户的统一资源标识符URI信息，第二服务器向呈现服务器发起的订阅请求消息中指出了实际是由业务触发信息拥有者的URI请求订阅的，呈现服务器根据呈现体的授权配置对此URI进行鉴权，确定是否提供以及提供哪些呈现信息。一般可以使用SUBSCRIBE消息中的p-asserted-identity字段值作为业务触发信息拥有者的URI进行鉴权。 

另外呈现服务器也可以向通用权限管理GPM(Global PermissionManagement)服务器发送鉴权请求，由通用权限管理根据授权配置进行鉴权，然后向呈现服务器返回鉴权结果，这样呈现服务器可以只处理核心的呈现信息订阅通知功能，将鉴权的功能分离出去，而GPM服务器可以作为一个公用的 鉴权功能部件同时为多种业务服务，如还可以同时为位置服务器提供鉴权。 

如果鉴权成功，则呈现服务器向第二服务器返回授权的呈现信息。如果第二服务器接收到鉴权失败的通知时，可以向客户端发送指示业务触发信息相关的呈现信息无法获得的通知。同时可以将该业务触发信息设置为挂起状态，不会再检测其触发条件。当用户又通过客户端对业务触发信息进行修改后，可以将其状态再设置为激活状态。 

D、根据获取的呈现信息当触发条件满足时，第二服务器向业务服务器发送业务触发通知。 

触发条件中除了呈现触发条件等状态条件外，还可以同时包括时间条件，指示触发业务的具体时刻或时间段。如上述步骤A中触发条件<condition>中还可以同时包括一个时间段条件<period>： 

<period> 

  <from>2006-07-01T17:00:00</from> 

  <until>2006-07-02T19:00:00</until> 

</period> 

包括一个开始时间<from>和结束时间<until>，其时间格式可以包括年、月、日、时、分、秒以及时区信息，指示只在该时间段内才能触发业务。当触发条件中同时包括时间条件和状态条件时，则第二服务器在所述的时间条件满足时，才向状态服务器获取状态信息。这样可以大大减少网络流量，因为时间条件的检测只需要在第二服务器内部进行即可，而状态条件的检测则需要第二服务器向状态服务器不断获取变化的状态信息才可以。 

如果该时间条件中没有限定年月日信息，则可以表示每天的该时间段；如果没有限定年月，则表示每月的该天该时间段，依次类推缺少其他信息的时间段表达方式。当然时间条件也可以表示时刻，当只有<from>或只有<until>元素时或者两个元素相同时就表示时刻；或者用另外的一个元素<timer>表示时刻条件，指示一个具体的时间点。 

当一个非周期性的时间条件对应的业务触发信息被执行完后，则该业务触 发信息可以由第二服务器自动删除，或者置为终止状态，处于终止状态的业务触发信息第二服务器不会去检测处理。另外多个时间条件之间第二服务器可以用逻辑或、逻辑与进行处理。 

如在一个预设的时间段内第二服务器向呈现服务器订阅的呈现信息满足了呈现触发条件，则第二服务器向业务服务器发送业务触发通知。通信***中会同时存在很多业务服务器，第二服务器根据业务类型确定向哪个业务服务器或哪个地址以何种协议发送业务触发通知，这可以预先配置在第二服务器中。 

如业务类型为短消息，则第二服务器使用SMPP协议发送联系人标识和业务内容给短消息中心；业务类型为多媒体消息，则第二服务器使用MM7接口协议发送联系人标识和业务内容给多媒体消息中心；如业务类型为电子邮件，则第二服务器使用SMTP协议发送联系人标识和业务内容给电子邮件服务器；如业务类型为即时消息，则第二服务器使用SIP MESSAGE协议发送联系人标识和业务内容给即时消息服务器。无论采用什么协议，本质上都要指出向哪些人发送什么内容的信息，或提供什么内容的业务。尽量采用业务服务器目前已经支持的协议类型，这样在应用本发明时，无需业务服务器扩展新的协议接口。 

本实施例中，第二服务器可以向短消息中心发送SMPP协议中的SUBMIT_SM命令，在其destination_addr字段中设置业务触发信息中的联系人标识<contact>：13048907033，在short_message字段中设置业务触发信息中的业务内容<content>：hello！。具体的SMPP协议可以参考相应的标准规范，如GSM03.40等短消息规范。 

一个业务触发信息中，可以触发多个业务类型的业务。如本实施例中，还可以同时包含另外一个业务类型为多媒体消息MMS的触发动作： 

<action id=＂02＂> 

    <service>MMS</service> 

    <contact>tel uri:13760463639</contact> 

    <content>http://content.example.com/mms.GIF</content> 

</action>

其多媒体消息业务内容可以为视频邮件，语音邮件，图像邮件或文本邮件等及其组合，其格式一般基于MIME(Multipurpose Internet Mail Extensions，RFC2045-2049)，第二服务器通过MM7接口将业务内容和联系人标识发送给MMSC，具体的MM7接口协议可参见3GPP TS23.140等多媒体消息和无线应用协议WAP(Wireless Application Protocol)相关标准规范。业务内容中可以直接存储MIME格式的多媒体消息内容，也可以只存储简单的文本、图片等数据或资源链接，当用MM7接口发送业务触发通知时再将这些数据或资源链接包装成MIME格式。采用资源链接可以不用在第一服务器中存储业务内容数据，而单独设置内容服务器，用于存储实际的业务内容数据如多媒体消息的内容，业务服务器在向用户提供业务时，业务服务器或用户终端可以从内容服务器获取具体的资源数据。 

本实施例中，除了触发一个短消息外，第二服务器还同时向MMSC通过MM7接口发送一个业务触发通知。可见一个业务触发信息中业务类型多于一个时，可以使不同的业务类型关联不同的业务内容和联系人标识；在发送业务触发通知时，第二服务器分别向各业务类型对应的业务服务器发送其关联的联系人标识和业务内容。 

当第二服务器发送业务触发通知成功后，可以向设置业务触发信息的客户端发送一个通知消息，指示业务已经已经被触发，为了更清晰及时得让用户了解业务的触发情况，可以在最初设置业务触发信息时，为每个业务触发信息设置一个业务触发名称，在上述的通知消息中包含该业务触发名称，以使用户了解哪个业务触发信息被执行了。简单得，第二服务器可以经过短消息中心SMSC向用户的移动电话发送一条包含业务触发名称的短消息通知消息即可。当然如果业务内容本来就是发送给设置业务触发信息的用户的，就没有必要发送上述通知消息了。 

可以在业务触发信息中增加通知动作<notify>信息，指示当业务触发通知发送成功后，要向哪些人以何种方式发送通知消息。如果没有设置通知动作 <notify>信息，则在业务触发通知发送成功后不通知用户。默认得通知方式可以为短消息。通知动作<notify>信息内容举例如下： 

<notify method=＂SMS＂> 

  <address>13760463639</address> 

  <note>success!</note> 

</notify> 

另外可选的，还可以在<notify>设置通知消息的内容<note>，如果设置了通知消息的内容<note>，则在业务触发通知发送成功后以method属性中设置的方式发送<note>中的内容。 

E、业务服务器根据所述通知提供业务。 

短消息中心SMSC或多媒体消息中心MMSC等业务服务器接收到业务触发通知后，将业务内容通过短消息或多媒体消息发送给联系人标识对应的移动电话。业务服务器除了可以发送消息之外，还可以发起业务会话，如即时消息IM会话、一键通PoC会话、会议电话等，通常会话的参与人数不少于2个。在下一个实施例中将详细描述触发业务会话的情形。 

如果***中只设置一个服务器作为触发器装置，则本实施例中步骤B中第一服务器和第二服务器交互可以省略，其他步骤的描述将第一服务器和第二服务器替换为触发器装置即可。 

具体实施例二，本实施例实现以下应用场景：在设定的时刻，对一个预定的群组中满足状态条件的用户发起群组会话，如即时消息IM会话、PoC会话等。设置的业务触发信息举例如下： 

<trigger id=＂002＂> 

 <condition> 

    <timer>2006-07-01T12:00:00+08:00</timer> 

    <group-filter uri=＂sip:mygroupexample.com＂> 

       <presence><sphere>home</sphere></presence> 

    </group-filter>

 </condition> 

 <actionid=＂als＂> 

      <service>PoC session</service> 

 </action> 

</trigger> 

本实施例中业务触发信息包含一个时间条件<timer>2006-07-01T12:00:00+08:00</timer>，以及对群组成员的状态筛选条件<group-filter>，其uri属性指定了要进行成员筛选的群组标识“mygroupexample.com”，呈现信息<presence>的<sphere>信息为“home”在家。在触发动作中本实施例没有特别指定业务内容和联系人标识，因为业务类型实际上已经指明了业务内容是要发起一个PoC会话，而根据<group-filter>部分筛选得到的群组成员即为联系人标识。即触发条件中也可以包含指示联系人标识的信息，业务类型也可以指示了业务内容信息。 

当触发器装置检测到时间条件满足时，先向存放群组信息的服务器获取群组“mygroupexample.com”的成员列表，如向共享群组服务器Shared GroupXDMS获取。然后向呈现服务器订阅获取成员列表的呈现信息，可以只订阅状态条件中需要的<sphere>信息，接收到呈现信息后触发器装置筛选出呈现信息<sphere>的值为home的成员，向PoC服务器发送业务触发通知指示要对筛选出的成员发起PoC会话。当然如果触发器装置检测到筛选的成员数量少于2人，则可以不发送业务触发通知，而是向设置业务触发信息的用户发送指示成员数量少于2人的通知，如可以通过SMTP协议发送一个包含通知内容的电子邮件给该用户。发送给PoC服务器的业务触发通知中包括筛选出的成员的URI也即联系人标识，和要对这些人发起PoC会话的指示信息。PoC服务器收到通知到向这些成员发起INVITE请求，建立PoC会话。 

业务触发通知也可以是触发器装置作为PoC客户端直接向PoC服务器发起的一个群组会话的SIP INVITE请求，当PoC服务器与成员建立会话连接之后，触发器装置再通过SIP BYE指令断开与PoC服务器的连接，而PoC会话 继续。 

或者触发器装置向PoC服务器发送一个SIP MESSAGE消息作为业务触发通知，其中在SIP MESSAGE消息体中包括筛选出的成员的URI也即联系人标识，和要对这些人发起PoC会话的指示信息，SIP MESSAGE消息的主要内容举例如下： 

MESSAGE sip:PoCServerdomain.com SIP/2.0 

From:sip:triggerdomain.com；tag=49513 

To:sip:PoCServerdomain.com 

Content-Type:application/trigger-notification+xml 

<？xml version=＂1.0＂encoding=＂UTF-8＂？> 

<trigger-notification> 

  <resource-lists><list> 

    <entry uri=＂sip:PoC-UserAdomain.com＂/> 

    <entry uri=＂sip:PoC-UserBdomain.com＂/> 

    <entry uri=＂sip:PoC-UserCdomain.com＂/> 

  </list></resource-lists> 

</trigger-notification> 

其中在<list>元素中给出了筛选出的成员的URI也即联系人标识，每个<entry>元素中的uri属性包含一个联系人标识，可以是SIP URI或TEL URI等，PoC服务器收到内容类型Content-Type为application/trigger-notification+xml的SIP MESSAGE消息，则会通过SIP INVITE请求对<list>元素中联系人标识发起PoC会话。这种方式可见触发器装置最初不用参与到PoC会话中。关于SIPINVITE和MESSAGE等可以参考RFC3261，RFC3428等相关的IETF标准，PoC业务规范可以参考OMA-TS-PoC-ControlPlane等标准。 

具体实施例三，状态信息除了可以是呈现信息外，特别的还可以是位置信息，当然位置信息本身也可以作为呈现信息，下面一段呈现信息的例子中就包含了以经纬度表示的位置信息：

<presence><person id=＂a123＂> 

<geopriv><location-info><location> 

          <Point gid=＂pointl＂srsName=＂epsg：1234＂> 

            <coordinates> 

              <X>322668S</X> 

              <Y>252513W</Y> 

            </coordinates> 

          </Point> 

</location></location-info></geopriv> 

</person></presence> 

关于位置信息作为呈现信息的扩展可以参考RFC4119。在业务触发信息中的状态条件也就可以包括位置条件，位置条件可以是经纬度区间，也可以是国家、城市、地区、街道等地理元素的名称标识，还可以包括进入、离开、位于某区域等与位置相关的事件信息。当触发器装置从呈现服务器获取位置信息时，具体可参见具体实施例一的实现方案。 

触发器装置也可以从位置服务器获取位置信息，如通过基于HTTP协议的Le和Ls接口协议从位置业务平台LSP即位置服务器获取位置信息，Le和Ls接口协议具体可以参考开放移动联盟OMA的Mobile Location Protocol(MLP)规范。如在业务触发信息中包含了位置条件： 

<trigger id=＂003＂> 

 <condition> 

    <position uri=＂13760463639＂type=＂ENTERING＂><civicAddress> 

        <A1>Shen Zhen</A1> 

    </civicAddress></position> 

 </condition> 

 <action id=＂1＂> 

    <service>SMS</service> 

    <contact>13048907033</contact>

    <content>张三已经到深圳!</content> 

 </action> 

</trigger> 

根据以上业务触发信息，触发器装置当从位置业务平台LSP获知用户13760463639的位置信息满足位置条件即进入中国深圳时，就向用户13048907033发送一条内容为“张三已经到深圳！”的短消息通知。 

具体的触发器装置可以通过周期性定位请求或区域触发定位请求从位置业务平台LSP获得位置信息，都是通过TLRR(Triggered Location ReportingRequest)实现，以下例子的<tlrr>信息中的事件<tlrr_event>定义了一个进入区域＂MS_ENTERING＂的事件，和业务触发条件中位置条件相对应。 

<tlrr ver=＂3.2.0＂> 

  <msids><msid>13760463639</msid></msids> 

  <tlrr_event> 

    <change_area type=＂MS_ENTERING＂loc_estimates=＂TRUE＂> 

      <target_area> 

        <name_area>Shen Zhen</name_area> 

      </target_area> 

    </change_area> 

  </tlrr_event> 

</tlrr> 

位置业务平台LSP检测到用户进入深圳Shen Zhen区域时，向触发器装置返回位置报告应答消息TLREP(Triggered Location Report)，触发器装置即可发送相应的短消息通知。 

触发器装置发送的定位请求消息的头部中包含了鉴权所需的信息，其中<requestor>字段对应了业务触发信息的创建者，如头部<hd>中包含： 

<hdr ver=＂3.2.0＂> 

  <requestor><id>13048907033</id></requestor> 

</hdr>

位置业务平台LSP检查<requestor>字段中的标识id是否有权限获取所请求的位置信息，一般可以根据被定位者如用户13760463639的授权配置如黑白名单列表等进行判断。当然通过GPM进行鉴权也可以，方法同具体实施例一，此处不再赘述。 

具体实施例四，触发器装置还可以为业务服务器进行条件评估，如判断用户的状态是否满足条件，或者预定的群组中哪些用户满足状态条件等。如图4流程图所示的步骤： 

401、触发器装置接收业务服务器发送的包含条件评估请求的消息； 

402、触发器装置向状态服务器订阅获取条件评估所需要的状态信息； 

403、触发器装置在进行评估处理后将包含条件评估结果的消息返回给业务服务器； 

404、业务服务器根据条件评估结果提供业务。 

如以下的条件评估信息<evaluation>的例子中包括业务用户信息即群组标识mygroupexample.com和筛选条件即成员的呈现信息需要满足的状态条件： 

<evaluation> 

   <group-filter uri=＂sip:mygroupexample.com＂> 

      <presence><sphere>home</sphere></presence> 

   </group-filter> 

</evaluation> 

触发器装置在接收到包含上述条件评估信息的条件评估请求后，先向存放群组信息的服务器获取群组成员列表，如果条件评估信息中直接包含了成员列表就不用去其他地方获取了；然后再向呈现服务器获取成员列表的与状态条件相关的呈现信息，将满足状态条件的成员用户列表包含在条件评估结果中返回给业务服务器。业务服务器可以据此对这些成员提供相应的业务，如发起PoC或IM会话等。这样各种业务服务器不用扩展与各种状态服务器的接口以及进行条件评估，而可以利用公用的触发器装置来实现条件评估，也提高了业务***的通用性和可扩展性。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (20)

1.一种提供通信业务的方法，其特征在于，包括步骤：

触发器装置接收客户端发送的包含触发条件的业务触发信息并保存，所述触发条件包括状态条件；

所述触发信息还包括指示业务类型、业务内容和联系人标识的信息；

触发器装置从状态服务器获取与业务触发信息相关的状态信息，所述状态信息为呈现信息；根据获取的状态信息当触发条件满足时触发器装置向所述业务类型对应的业务服务器发送包含业务内容和联系人标识的通知消息；

业务服务器根据所述通知向所述联系人标识提供所述的业务内容。

2.根据权利要求1所述的方法，其特征在于，所述的状态服务器为呈现服务器；

当触发器装置从呈现服务器获取与业务触发信息相关的呈现信息时，呈现服务器在鉴权成功后才向触发器装置返回呈现信息。

3.根据权利要求2所述的方法，其特征在于，呈现服务器的鉴权步骤具体为：呈现服务器向通用权限管理服务器发送鉴权请求，通用权限管理根据授权配置进行鉴权并向呈现服务器返回鉴权结果；或者，

呈现服务器根据授权配置进行鉴权。

4.根据权利要求1所述的方法，其特征在于，触发器装置从状态服务器获取与业务触发信息相关的状态信息之前，先根据业务触发信息向通用权限管理服务器发送鉴权请求，接到鉴权成功的结果后才向状态服务器获取状态信息。

5.根据权利要求1所述的方法，其特征在于，所述的触发器装置包括第一服务器和第二服务器；

第一服务器接收客户端发送的包含触发条件的业务触发信息并保存；所述触发信息还包括指示业务类型、业务内容和联系人标识的信息；

第二服务器从第一服务器获取业务触发信息，从状态服务器获取与业务触发信息相关的状态信息；

根据获取的状态信息当触发条件满足时第二服务器向所述业务类型对应的业务服务器发送包含业务内容和联系人标识的通知消息。

6.根据权利要求1所述的方法，其特征在于，所述触发条件中还包括时间条件，则触发器装置在所述的时间条件满足时，才向状态服务器获取与所述状态条件相关的状态信息。

7.根据权利要求1所述的方法，其特征在于，在触发器装置向业务服务器发送业务触发通知后，还向所述客户端发送指示业务已经被触发的通知；

触发器装置删除已经完成或过期的业务触发信息。

8.根据权利要求1所述的方法，其特征在于，所述触发条件中包含了对联系人的状态筛选条件，触发器装置根据获取的状态信息和所述的对联系人的状态筛选条件确定满足条件的联系人标识，向业务服务器发送包含业务内容和满足条件的联系人标识的业务触发通知。

9.根据权利要求1所述的方法，其特征在于，一个业务触发信息中业务类型多于一个时，不同的业务类型关联不同的业务内容和联系人标识；

在发送业务触发通知时，触发器装置分别向各业务类型对应的业务服务器发送其关联的联系人标识和业务内容。

10.根据权利要求1所述的方法，其特征在于，触发器装置根据业务类型将联系人标识和业务内容封装到相应协议格式的消息；

如果业务类型为短消息，则触发器装置使用SMPP协议发送联系人标识和业务内容给短消息中心；

如果业务类型为多媒体消息，则触发器装置使用MM7接口协议发送联系人标识和业务内容给多媒体消息中心；

如果业务类型为电子邮件，则触发器装置使用SMTP协议发送联系人标识和业务内容给电子邮件服务器；

如果业务类型为即时消息，则触发器装置使用SIP MESSAGE协议发送联系人标识和业务内容给即时消息服务器。

11.根据权利要求1所述的方法，其特征在于，所述的状态服务器为呈现服务器，触发器装置通过发送包含与所述触发条件相应的过滤信息的订阅请求从呈现服务器获取呈现信息。

12.根据权利要求1所述的方法，其特征在于，在业务内容中存储资源链接，指向存储在内容服务器的资源内容；

业务服务器根据所述通知提供业务的步骤具体为：业务服务器根据业务内容中的资源链接从内容服务器获取相应的资源内容，然后向所述的联系人标识提供所述的资源内容。

13.一种触发器装置，其特征在于，所述的装置用于接收客户端发送的包含触发条件的业务触发信息并保存，所述触发条件包括状态条件，所述触发信息还包括指示业务类型、业务内容和联系人标识的信息；并从状态服务器获取与业务触发信息相关的状态信息，所述状态信息为呈现信息，然后根据获取的状态信息检测到触发条件满足时向所述业务类型对应的业务服务器发送包含业务内容和联系人标识的通知消息。

14.根据权利要求13所述的装置，其特征在于，所述的装置包括第一服务器和第二服务器；

第一服务器用于接收客户端发送的包含触发条件的业务触发信息并保存；

第二服务器用于从第一服务器获取业务触发信息，从状态服务器获取与业务触发信息相关的状态信息，根据获取的状态信息检测到触发条件满足时向业务服务器发送业务触发通知。

15.根据权利要求13所述的装置，其特征在于，所述的装置还用于在接收到业务服务器发送的包含条件评估请求的消息时，向状态服务器订阅获取条件评估所需要的状态信息，在进行评估处理后将包含条件评估结果的消息返回给业务服务器。

16.一种提供通信业务的***，其特征在于，所述的***包括触发器装置，状态服务器和业务服务器；

所述的触发器装置用于接收客户端发送的包含触发条件的业务触发信息并保存，所述触发条件包括状态条件，所述触发信息还包括指示业务类型、业务内容和联系人标识的信息；从状态服务器获取与业务触发信息相关的状态信息，根据获取的状态信息当检测到触发条件满足时向所述业务类型对应的业务服务器发送包含业务内容和联系人标识的通知消息；

所述的状态服务器用于向触发器装置提供状态信息，所述状态信息为呈现信息；

所述的业务服务器用于在接到业务触发通知时根据所述通知向所述联系人标识提供所述的业务内容。

17.根据权利要求16所述的***，其特征在于，所述的触发器装置还用于在接收到业务服务器发送的包含条件评估请求的消息时，向状态服务器订阅获取条件评估所需要的状态信息，在进行评估处理后将包含条件评估结果的消息返回给业务服务器。

18.根据权利要求16所述的***，其特征在于，所述的***还包括内容服务器，用于存储业务触发信息中的资源链接所指向的资源内容，并向业务服务器提供资源内容。

19.根据权利要求16所述的***，其特征在于，所述的***还包括通用权限管理服务器，用于接收状态服务器或触发器装置发送的鉴权请求，并根据授权配置进行鉴权，然后向状态服务器或触发器装置返回鉴权结果。

20.根据权利要求16至19任一项所述的***，其特征在于，所述的触发器装置包括第一服务器和第二服务器；

第一服务器用于接收客户端发送的包含触发条件的业务触发信息并保存；

第二服务器用于从第一服务器获取业务触发信息，从状态服务器获取与业务触发信息相关的状态信息，根据获取的状态信息检测到触发条件满足时向业务服务器发送业务触发通知。

Images