用于控制通知服务中的动作的方法和布置的利记博彩app
【专利摘要】提供用于控制向预订监视器(A)提供与呈现体(B)有关的通知的通知服务器(200)中的动作的方法和布置。在除了常规通知之外还从请求方(A、B或208)接收(2:1)对附加动作的请求时，在动作规则库(202)中激活(2:3)动作规则。动作规则包括用于执行所请求附加动作的触发条件。在接收(2:4)涉及呈现体的事件发布时，针对动作规则来检查(2:6)事件发布，以便确定事件发布是否满足触发条件。如果是的话，则运行(2:7)附加动作。由此，附加动作能够在事务通知服务的框架之内付诸实施并且自动控制。
【专利说明】用于控制通知服务中的动作的方法和布置
【技术领域】
[0001]一般来说，本发明涉及用于控制与通知服务中涉及的监视器或呈现体(presentities )相关的动作的方法和布置。
【背景技术】
[0002]消息传递服务在通信网络中的终端用户之间变得越来越普遍。一具体示例是通过通信网络基本上使与特定客户端相关的数据对其它客户端可用的呈现服务。在呈现服务中，客户端的呈现数据被收集和存储在呈现服务器中，并且然后能够传递给预订那个呈现数据的客户端。在这个上下文中，“客户端”通常是通信网络中的终端用户，但是在一些实际情况下，它也能够是诸如应用、传感器或计数器之类的“机器功能”。
[0003]呈现数据可涉及客户端的各种参数和特性，包括与例如终端状态、能力、选择和设定相关的信息以及与诸如可用性、地理位置和物理环境之类的客户端的当前状况相关的信息。呈现数据还可包括更多个人的信息，例如兴趣和需要、当前活动、个人特性、情绪等。客户端可预订其它客户端的所选呈现数据或者“更新”，以便接收具有这种信息的通知。
[0004]每当客户端的任何呈现数据被引入、更新、改变或删除时，这种类型的信息通常在呈现服务器中基于从与客户端关联的诸如用户终端、M2M(机器对机器)装置和接入网之类的任何“呈现源”所接收的发布来以连续的原则收集。在这个领域中，术语“监视器”表示预订和接收呈现数据的客户端，而“呈现体”表示发布呈现服务器中可用于任何经授权监视器的呈现数据的客户端。相应地，呈现服务器向监视器发送通知中的所发布呈现数据，通常采取XML (可扩展标记语言)文档的形式。
[0005]协议SIP(会话初始协议)通常用作通过通信网络的呈现数据的上述操控的框架。称作“SIP PUBLISH”的SIP消息由呈现体用于向呈现服务器发送呈现数据供发布。称作“SIP SUBSCRIBE”的另一个SIP消息由监视器用于请求呈现体的呈现数据。称作“SIPNOTIFY”的又一个SIP消息由呈现服务器用于向监视器传递新呈现数据。备选地，HTTP(超文本传输协议)能够用于呈现服务中，例如，呈现体可使用常规“HTTP PUT”消息或者HTTPPOST消息来发布数据。
[0006]图1示出用于提供呈现数据的常规过程，其涉及监视器A、呈现体B以及将呈现体B的呈现数据存储于数据存储装置102中的呈现服务器100。第一动作1:1a —般说明，通过按照常规例程，从B或者从B的接入网(未示出)发送的到呈现服务器100的频繁发布消息来相对呈现体B发布呈现数据。呈现数据的这类发布或更新常常称作“事件”，该术语将用于本描述中。下一个动作1:1b说明，数据存储装置102按照动作1:1a的发布来更新。按照现行例程，动作1:1a和1:1b可在后台始终继续进行。
[0007]在动作1:2，监视器A发送呈现体B的呈现数据的预订请求，其中可指定预期预订时限的超时参数。备选地，每当监视器想要信息时预订请求可以是一次性请求。呈现服务器100则在动作1:3中从数据存储装置102检索呈现体B的呈现数据，并且在初始通知消息中将其发送给监视器A，如另一个动作1:4中所示。如步骤1:4中的虚线箭头所示，取决于预订模型，监视器A可在另外的时机(例如按照预设预定时间、以常规间隔或者每当呈现数据被改变时或者只是每请求一次地)接收这类通知。
[0008]除了只是向预订监视器发送通知之外，有时还期望执行通过用呈现服务器发布呈现体数据引起或产生的附加动作。例如，处理或操控所发布数据的某个逻辑可以是与一些状况或条件下执行相关的。每当某种条件正在现行时，还可期望向监视器或呈现体或者甚至向第三方发送特定消息。当前，没有对于能够如何实现这个方面的解决方案是可用的，这被确定为问题。
【发明内容】
[0009]本发明的目的是解决上述问题和缺点的至少一部分。有可能通过使用如所附独立权利要求中限定的方法和布置来实现这些目的及其它目的。
[0010]按照一个方面，提供一种用于控制向预订监视器提供与呈现体有关的通知的通知服务器中的动作的方法。在这种方法中，还从请求方接收除了发送所述通知之外并且与涉及呈现体的事件发布相关的附加动作的请求。通知服务器则激活动作规则库中的动作规贝U，该动作规则包括用于执行所请求附加动作的触发条件。当接收涉及呈现体的事件发布时，通知服务器针对所述动作规则来检查事件发布，以便确定事件发布是否满足动作规则中的触发条件。如果发现满足触发条件，则通知服务器相应地运行或发起附加动作。
[0011]按照另一方面，提供一种在通知服务器中配置成向预订监视器提供与呈现体有关的通知的布置。通知服务器布置包括第一接收模块，第一接收模块适合于从请求方接收除了所述通知之外并且与涉及呈现体的事件发布相关的附加动作的请求。该布置还包括规则操控模块，规则操控模块适合激活动作规则库中的动作规则，该动作规则包括用于执行所请求附加动作的触发条件。该布置还包括:第二接收模块，其适合接收涉及呈现体的事件发布；以及规则检查模块，其适合针对所述动作规则来检查事件发布，以便确定事件发布是否满足动作规则中的所述触发条件。通知服务器中的动作模块适合在满足动作规则中的触发条件时运行或发起所述附加动作。
[0012]通过使用上述解决方案，除了按照事务(ongoing)通知服务的常规通知之外，任何所需的附加动作还能够通过通知服务的现有和当前使用的框架自动发起，使得附加动作通过呈现体的事件发布来触发。具有一个或多个触发条件的动作规则能够自由选择或创建，以便提供对将要运行附加动作的方式和时间的定制或个性化控制。请求方可以是下列之一:监视器、呈现体、第三方以及与监视器或呈现体关联的管理者。
[0013]上述方法和布置可按照不同可选实施例来配置和实现。在一些可能的实施例中，触发条件涉及下列至少一个:事件发布的类型、时刻、星期或季节以及事件发布中的报告参数的值。在其它实施例中，附加动作或触发条件可涉及特定呈现体或监视器或者一般涉及任何呈现体或监视器。
[0014]为了激活动作规则，新动作规则可被创建或定义并且安装在动作规则库中，或者备选地，可在动作规则库中选取已经现有的动作供激活。此外，通知服务器可接收XCAP消息中或者SUBSCRIBE消息中的附加动作的请求。
[0015]在其它实施例中，还有可能使通知服务器执行下列至少一个:基于预设访问规则来授权请求方，以及在激活所述动作规则之前，基于预设认证规则来认证请求方。[0016]附加动作可涉及下列至少一个:用于处理或操控事件发布中的信息的逻辑以及向监视器或呈现体或者向第三方发送电子邮件。动作规则可确定下列至少一个:通知是否将要发送给监视器，以及附加动作的报告、结果或输出是否将要包含在通知中。在呈现体和监视器由不同的通知服务器来提供服务的情况下，通知服务器还可接收作为来自另一个通知服务器的通知的事件发布。
[0017]通过以下详细描述，本解决方案的其它可能特征和有益效果将变得显而易见。
【专利附图】
【附图说明】
[0018]现在将通过示范实施例并且参照附图更详细地描述本发明，其中:
图1是按照现有技术的示出具有通知的常规呈现服务的通信情况。
[0019]图2是按照一些可能实施例的示出在通知服务器中能够如何控制附加动作的框图。
[0020]图3是按照其它可能实施例的示出用于在通知服务器中控制附加动作的配置过程的流程图。
[0021]图4是按照其它可能实施例的示出用于在通知服务器中控制附加动作的运行时过程的流程图。
[0022]图5是按照其它可能实施例的更详细示出通知服务器的框图。
[0023]图6是按照其它可能实施例的示出当呈现体和监视器由不同通知服务器来提供服务时能够如何控制附加动作的框图。
【具体实施方式】
[0024]简言之，提供一种在通知服务器中的解决方案，该解决方案按照事务通知服务、例如呈现服务向预订监视器定期发送与呈现体有关的通知。这种解决方案使通知服务器能够除了只是向监视器发送通知之外还按照动作规则来控制涉及呈现体的所接收事件发布所触发的附加动作的执行。动作规则包括附加动作的定义或描述以及控制将要运行动作的时间的触发条件。在这种解决方案中，附加动作的控制能够通过通知服务中当前使用的消息传递框架、例如呈现框架和/或尤其是SMPLE呈现中使用的XCAP消息和XML文档来实现，但是该解决方案并不局限于通知服务的任何特定消息传递框架。
[0025]作为举例而不是限制，通知服务器可以是按照程度不同的普通呈现服务或者相似通知服务、例如按照以上对于图1所述的方式向监视器发送包含呈现体的所发布信息或者更新的通知的呈现服务器等。术语“事件发布”用于表示通过按照常规例程，从呈现体本身或者从呈现体的接入网(未示出)所发送，用于在动作1:1a发布数据的上述消息的任一种发送给呈现服务器100的涉及呈现体的任何所发布数据、例如呈现数据和类似更新。
[0026]这种解决方案中的上述“附加动作”可以是除了按照事务通知服务向监视器发送通知的动作之外的、与涉及呈现体的事件发布相关或者由其触发的任何动作。附加动作在这个上下文中可涉及例如用于处理或操控事件发布中的信息的逻辑或者向监视器或呈现体或者向第三方发送具有某个消息的电子邮件。这种解决方案并不局限于任何特定附加动作。按照上述机制，如果满足预定义动作规则中的触发条件，则附加动作将由通知服务器来运行或者至少由其发起。例如，附加动作可以是，除了送往监视器的常规通知之外，假如满足触发条件，还将要把包含呈现体的所发布数据的电子邮件发送给第三方。
[0027]参照图2中所示的通信情况，现在将描述按照这种解决方案、如何能够在通知服务器200中控制这种附加动作的示例。假定通知服务器200还基本上按照常规或者不是常规的任何通知服务、例如呈现服务来向预订监视器A提供与呈现体B有关的通知。但是，向监视器A发送通知并不局限于这种解决方案中的任何特定方案。例如，通知可因无论什么原因而被抑制，或者通知还可包含附加动作的输出或结果，诸如此类。此外，监视器A可由与呈现体相同的通知服务器200或者由如图中虚线所示的另一个通知服务器210、例如作为允许对诸如呈现体B之类的用户列表的预订的服务器的所谓RLS (资源列表服务器)来提供服务。在这里所述的解决方案中，通知服务的现有机制和框架按照有用方式用于除了实际通知服务之外还实现和触发所需附加动作，如下所述。
[0028]第一行动2:1示出，除了常规通知之外，通知服务器200还接收附加动作的请求，附加动作与涉及呈现体的事件发布相关或者由其触发。一般从“请求方”接收动作请求，“请求方”可能是监视器A、呈现体B或者与A或B或者与第三方(未示出)关联的管理者208。在监视器A由独立通知服务器210来提供服务的情况下，请求可经由服务器210来自监视器A(未示出)。请求方可在SUBSCRIBE消息中或者在XCAP PUT消息中或者在当前使用的通知服务框架内的任何其它类型的消息中发送动作请求，并且还可引用存储装置212中已经定义的现有附加动作。备选地，请求方在一些情况下可在动作请求中的XML文档中来定义或描述所请求附加动作，XML文档通常无论如何在正常呈现框架中使用。
[0029]在这种解决方案中，所请求附加动作通过每当在通知服务器200接收到涉及呈现体B的事件发布时激活将要应用的动作规则来实现。但是，在这个示例中激活动作规则之前，请求方可基于数据库206中保持的预设认证规则来认证(如行动2: 2a所示)，以便基本上确定请求方是否有效和可靠。此外，请求方还可基于另一个数据库204中所保持的预设访问规则来授权(如行动2:2b所示)，以便确定是否能够允许请求方实施所请求动作。行动2: 2a和2: 2b可按照任何顺序进行。请求方的这个授权和认证基本上可按照与监视器提交呈现体的数据的预订请求时相同的方式来执行。
[0030]假定行动2:2a和2:2b (若被运行的话)的输出为肯定，使得请求方是可信的并且被允许，则下一个行动2:3示出，通知服务器200激活动作规则库202中的所请求附加动作的动作规则。还假定通知服务器200具有用于基于在行动2:1所接收的动作请求来创建或选择适当动作规则的逻辑。激活动作规则可包括在动作规则库中创建和安装新动作规则，或者选择和激活动作规则库中已现有的动作规则，下面更详细描述。
[0031]被激活动作规则还在动作规则库中关联到呈现体B，使得涉及那个呈现体的事件发布能够触发动作按照动作规则来运行。如果附加动作按照某种方式涉及监视器A，则被激活动作规则还关联到监视器A。在呈现体B和监视器A分别由不同的通知服务器200和210来提供服务的情况下，动作规则可由另一通知服务器210来操控，以及触发附加动作的事件发布可在服务器210采用来自通知服务器200的通知的形式来接收，其稍后将参照另一个示例更详细描述。
[0032]具体来说，动作规则包括每当在服务器200接收到涉及呈现体B的事件发布时将要评估的用于执行附加动作的触发条件。附加动作或触发条件触发条件通过涉及特定呈现体或监视器可以是“特定的”或者通过一般涉及任何呈现体或监视器可以是“通用的”。[0033]例如，触发条件可涉及下列一个或多个:事件发布的类型、时刻、星期或季节以及事件发布中的报告参数的值等。在后一种情况下，触发条件可以是，如果报告参数值超过或者备选地没有超过预设等级，则应当运行附加动作。其示例可以是，当M2M装置发送具有超过触发条件中设置的阈值的温度值的事件发布时，动作规则规定，告警消息将要作为附加动作发送给紧急中心。
[0034]在另一个示例中，触发条件可涉及事件发布的时间或者涉及当前位置，以及动作规则可规定，附加动作应当分别仅在星期天的上午10与下午5点之间或者仅当监视器或呈现体位于某个区域时运行。此外，请求方可基于多个动作规则和/或触发条件来请求附加动作，其也有可能通过这种解决方案付诸实施。
[0035]在行动2:3激活动作规则时，如可选行动2: 3a所示可检查适合于动作请求的任何动作是否在具有预定义动作的存储装置212中已经定义。在那种情况下，从存储装置212选择已现有的动作以适合请求，以及所选动作作为动作规则在库202中被安装和激活。否贝U，新动作规则可相应地创建以适合请求，并且安装在动作规则库202中。在那种情况下，通知服务器200可管理新动作规则并且通过使用XCAP将其上传到库202。
[0036]上述行动2:l-2:3(2:3a)基本上涉及用于建立控制通知服务器中的动作的机制的配置过程。以下行动确切来说涉及附加动作的控制付诸实施时的运行时过程，其当通知服务器200接收涉及呈现体B的事件发布时开始于行动2:4。另一个行动2:5示出，通知服务器200可按照事务通知服务向监视器A发送常规通知，但是备选地根据通知服务可抑制通知，但是这对本解决方案同样不太重要。
[0037]下一个行动2:6示出，通知服务器200针对库202中的动作规则来检查所接收事件发布，以便确定事件发布是否满足动作规则中的触发条件。根据上述检查的输出，如果认为满足动作规则中的触发条件，则运行附加动作，如示意行动2:7所示。如何发起和执行实际动作有点超出本解决方案的范围。例如，通知服务器200可自行运行动作，或者可触发另一个节点或功能、例如为监视器A提供服务的独立通知服务器210来运行动作。此外，向监视器发送通知的所示行动2:5可在行动2:7的附加动作的执行之后执行，以及这个通知甚至可包含所运行动作的某个报告、结果或输出。
[0038]这样，由呈现体的事件发布所触发的任何所需附加动作能够通过通知服务的现有和当前使用的框架来自动发起。如上所述，动作规则及其一个或多个触发条件能够自由选择或创建，以便提供对将要运行附加动作的方式和时间的定制或个性化控制。换言之，动作规则基本上包括关于附加动作将要如何执行的定义或描述以及用于确定将要执行附加动作的时间的触发条件。此外，监视器和呈现体均可通过影响访问规则204和/或认证规则206来得到对于是否能够允许请求方实现动作规则的控制。
[0039]现在将参照图3来描述用于控制向预订监视器提供与呈现体有关的通知的通知服务器中的动作的过程。这个过程基本上对应于上述配置过程，并且包括可在通知服务器、例如图2的通知服务器200中运行的各种步骤或行动。这个示例再次涉及可以是上述示例中的呈现体、监视器和管理者的任一个的“请求方”。
[0040]在第一所示行动300中，通知服务器从请求方接收除了所述通知之外并且与涉及呈现体的事件发布相关或者由其触发的附加动作的请求，其基本上对应于上述行动2:1。在这个示例中，然后在行动302例如根据预设访问规则和/或认证规则来确定是否能够允许请求方实施附加动作，其基本上对应于上述行动2:2a和2:2b。如果不允许，则适当拒绝消息可在行动304发送给请求方。
[0041]如果在行动302允许请求方，则通知服务器在另一行动306识别所请求附加动作。然后在行动308确定动作是否已经存在于具有预定义动作的存储装置、例如图2的存储装置212中。如果没有，则通知服务器在另一行动310基于所请求附加动作来定义新动作。新动作还可基于当前访问规则。另一方面，如果在行动308发现适合的预定义动作已经存在，则在行动312选择预定义动作以满足所接收动作请求。
[0042]最后，在行动314按照请求采用所创建或者所选动作以及至少一个触发条件在动作规则库中定义和激活动作规则，基本上对应于上述行动2: 3，从而完成这种解决方案的配置阶段。激活动作规则基本上表示它针对输入事件发布被应用或“施行”。应当注意，在动作314，所激活动作规则还在动作规则库中按照适当方式关联到呈现体。
[0043]动作规则可在动作规则库中定义为XML文档或类似的，并且基本上包括附加动作的定义或描述以及用于分别确定将要执行附加动作的方式和时间的触发条件。例如，所创建或选择的动作规则甚至可确定通知是否将要发送给监视器以及附加动作的报告、结果或输出是否将要包含在通知中。在那种情况下，有可能基本上通过动作规则来控制通知服务中的通知的流。如上所述，一个以上触发条件可在动作规则中定义。
[0044]下一个图4基本上示出图3的过程的延续，如虚线箭头所示，并且表示这个过程的运行时阶段。在第一所示行动400，通知服务器从呈现体本身或者从配置成提供与呈现体相关的事件发布的网络或其它节点来接收涉及呈现体的事件发布，其基本上对应于上述行动2:4。如上所述，在呈现体和监视器由例如包括为监视器提供服务的RLS的不同通知服务器来提供服务的情况下，事件发布可作为来自另一个通知服务器的通知来接收。
[0045]然后，基本上对应于上述行动2:6，在下一行动402中，例如通过首先将呈现体的所接收事件发布映射到在上述行动314关联到该呈现体的已激活动作规则，通知服务器针对以上被激活动作规则来检查或评估事件发布。随后，在另一所示行动404确定事件发布及其环境是否满足动作规则中的触发条件。这种评估能够按照一系列不同方式、例如按照以上对于行动2:3所述的触发条件的示例来执行，并且本发明并不局限于这个方面。
[0046]如果通知服务器确定对于所接收事件发布不满足触发条件，则如行动406所示不运行附加动作，以及按照常规过程、例如向监视器发送通知来操控事件发布。另一方面，如果发现满足触发条件，则例如除了向监视器发送常规通知之外，附加动作还由通知服务器在最终所示行动408中运行或者至少发起或触发,其基本上对应于上述行动2:7。
[0047]关于如何能够在通知服务器中实现完成上述解决方案的布置的更详细但非限制性示例通过图5的框图示出。因此，通知服务器500配置成例如按照以上对于图2-4的任一个所述的方式向预订监视器提供与呈现体有关的通知。
[0048]按照这种布置，通知服务器500包括第一接收模块500a，第一接收模块500a适合于从请求方502接收除了所述通知之外并且与涉及呈现体的事件发布相关或者由其触发的附加动作的请求“A-Req”。通知服务器500还包括规则操控模块500b，规则操控模块500b适合激活动作规则库500c中的动作规则“AR”，该动作规则包括用于执行所请求附加动作的触发条件。被激活动作规则AR还关联到呈现体B，以便对其映射任何输入事件发布。
[0049]通知服务器500还包括:第二接收模块500d，其适合接收涉及呈现体B的事件发布“EP”;以及规则检查模块500e，其适合针对以上被激活动作规则来检查事件发布，以便确定事件发布是否满足动作规则中的触发条件。通知服务器500还包括动作模块500f，动作模块500f适合在认为满足动作规则中的触发条件时运行或者至少发起附加动作“Ac”。
[0050]应当注意，图5只在逻辑意义上示出通知服务器500中的各种功能模块或单元，而技术人员实际上使用适当软件和硬件部件能够随意地实现这些功能。因此，本解决方案的这个方面一般并不局限于通知服务器500的所示结构，而其功能模块500a-500f可配置成在适当的情况下按照以上对于图2-4的任一个所述的特征进行操作。
[0051]上述功能模块500a_500f能够在通知服务器500中作为包含代码部件的计算机程序的程序模块来实现，其中代码部件在由通知服务器500中的处理器“P”运行时使服务器500执行上述功能和动作。处理器P可以是单个CPU(中央处理器)，或者可包括两个或更多处理单元。例如，处理器P可包括通用微处理器、指令集处理器和/或相关芯片组和/或诸如ASIC(专用集成电路)之类的专用微处理器。处理器P还可包括用于高速缓存的存储
装直。
[0052]计算机程序可由通知服务器500中采取连接到处理器P的存储器“Μ”的形式的计算机程序产品来承载。计算机程序产品或存储器M包括计算机可读介质，其上存储了计算机程序。例如，存储器M可以是闪速存储器、RAM (随机存取存储器)、ROM (只读存储器)或者EEPR0M(电可擦除可编程ROM)，以及程序模块在备选实施例中可分布于采取通知服务器500中的存储器的形式的不 同计算机程序产品上。
[0053]上述通知服务器500和功能模块500a-500f可配置成或者适合于按照各个可选实施例进行操作。例如，规则操控模块500b还可适合通过在动作规则库500c中安装新动作规则，或者通过在动作规则库中选择已现有的动作(A)供激活，来激活动作规则。规则操控模块500b可从具有预定义动作A的存储装置500g来选择和取出已现有的动作A。
[0054]在另一个可能的实施例中，第一接收模块500a还适合接收XCAP消息或者SUBSCRIBE消息中的附加动作的请求。在另一个可能的实施例中，规则操控模块500b还适合执行下列至少一个:如相应虚线箭头所指示的，基于预设访问规则504来授权请求方，以及在激活动作规则之前，基于预设认证规则506来认证请求方。第二接收模块500d还可进一步适合接收作为来自另一个通知服务器的通知的事件发布，其中呈现体和监视器由不同的通知服务器提供服务。
[0055]图6示出涉及如上所述常规通知的通知服务中的另一种通信情况，其中监视器A和呈现体B由具有相应动作规则库600a和600b的不同通知服务器600和602来提供服务。各通知服务器600和602可具有例如图2的存储装置212中的其自己的预定义动作集合。现在将描述关于本解决方案能够如何用于实现如始发于呈现体B的事件发布所触发的、月艮务器600和602中的附加动作的可能示例。在其变体中，还有可能仅在服务器602中而不在服务器600中实现附加动作。通知服务器602可以是RLS。
[0056]第一行动6:1示出，除了常规通知之外，通知服务器600还从请求方604接收附加动作的请求，附加动作与涉及呈现体B的事件发布相关或者由其触发。请求方604可以是呈现体B或者第三方等。下一个行动6:2示出，通知服务器600在动作规则库600a中激活所请求附加动作的动作规则，其基本上如对于上述行动2:3所述。
[0057]但是，在这个示例中，除了常规通知之外，通知服务器602在行动6:3也从监视器A(因而作为请求方)接收对另一个附加动作的请求，另一个附加动作同样与涉及呈现体的事件发布相关或者由其触发。请求备选地可从第三方来接收。下一个行动6:4示出，通知服务器602例如按照上述方式激活在动作规则库602a中的所请求附加动作的动作规则。因此，行动6.2和6:4的每个动作规则基本上包括关于附加动作将要如何运行的定义以及关于将要何时运行该动作的触发条件，如上所述。应当注意，上述两个动作规则相互无关，并且可涉及不同动作和/或触发条件。
[0058]下一个行动6:5示出，通知服务器600接收涉及呈现体B的事件发布，以及通知服务器600在另一行动6:6来检查事件发布是否满足库600a中的动作规则中的触发条件。然后，如果满足触发条件，则在另一行动6:7来运行或者至少发起动作。在这个示例中，在另一行动6:8，常规通知还从通知服务器600发送给另一通知服务器602，其然后可在通知中转发或者不转发给加入事务通知服务的监视器A的通知服务器602 (未示出)。在这个示例中，在行动6:8由通知服务器602所接收的通知实际上是涉及呈现体B的事件发布。因此，通知服务器602基本上也通过在另一行动6:9检查库602a中的动作规则的触发条件，并且然后在满足触发条件时在另一行动6:10运行或者至少发起动作，来执行上述过程。
[0059]实现由始发于呈现体B的事件发布所触发的附加动作的上述过程能够按照不同方式来修改。例如，通知服务器可从一个以上请求方、例如从监视器和呈现体接收对附加动作的请求。在那种情况下，当接收涉及呈现体的事件发布时，通知服务器将检查对监视器所激活的动作规则，并且还检查对呈现体所激活的动作规则。然后，将根据事件发布是否满足相应动作规则中的触发条件来运行或发起动作。因此，这些动作规则可具有不同触发条件，使得对应动作将相互无关地运行或者不运行。因此，事件发布可在通知服务器602中而不在通知服务器600中触发附加动作，反过来也是一样。
[0060]还有可能的是，两个通知服务器(例如600和602)可具有用于操控其相应动作规则的共同动作规则库，即，库600a和600b可组合为单个动作规则库。一个或多个附加动作也可以是通用的，并且应用于任何呈现体和/或监视器。此外，两个通知服务器600和602也可具有其自己的用于预定义动作的存储装置或者用于其的共同的存储装置。
[0061]虽然已经参照具体的示范实施例描述了本发明，但是，描述一般仅意在说明本发明的概念，而不应当被理解为限制本发明的范围。例如，在本描述中通篇使用了术语“通知服务器”、“呈现体”、“监视器”、“请求方”、“事件发布”、“附加动作”和“触发条件，但是也可能使用具有这里所述特征和特性的任何其它对应节点、功能和/或参数。本发明由所附权利要求书限定。
【权利要求】
1.一种用于控制向预订监视器(A)提供与呈现体(B)有关的通知的通知服务器(200)中的动作的方法，所述方法包括: -从请求方(A，B或208)接收(2:1)除了所述通知之外并且与涉及所述呈现体的事件发布相关的附加动作的请求， -激活(2:3)动作规则库(202)中的动作规则，所述动作规则包括用于执行所请求附加动作的触发条件， -接收(2:4)涉及所述呈现体的事件发布， -针对所述动作规则来检查(2:6)所述事件发布，以便确定所述事件发布是否满足所述动作规则中的所述触发条件，以及 -如果满足所述动作规则中的所述触发条件，则运行(2:7)或发起所述附加动作。
2.如权利要求1所述的方法，其中，所述请求方是下列之一:所述监视器(A)、所述呈现体(B)、第三方以及与所述监视器或者所述呈现体关联的管理者(208)。
3.如权利要求1或2所述的方法，其中，所述触发条件涉及下列至少一个:事件发布的类型、时刻、星期或季节以及所述事件发布中的报告参数的值。
4.如权利要求1-3中的任一项所述的方法，其中，所述附加动作或者所述触发条件涉及特定呈现体或监视器或者一般涉及任何呈现体或监视器。
5.如权利要求1-4中·的任一项所述的方法，其中，激活所述动作规则包括在所述动作规则库中创建和安装新动作规则，或者在所述动作规则库中选择已现有的动作供激活。
6.如权利要求1-5中的任一项所述的方法，其中，在XCAP消息或者在SUBSCRIBE消息中接收对附加动作的请求。
7.如权利要求1-6中的任一项所述的方法，所述方法还包括下列至少一个:基于预设访问规则(204)来授权(2:2a)所述请求方，以及在激活所述动作规则之前，基于预设认证规则(206)来认证(2:2b)所述请求方。
8.如权利要求1-7中的任一项所述的方法，其中，所述附加动作涉及下列至少一个:用于处理或操控所述事件发布中的信息的逻辑，以及向所述监视器或所述呈现体或者向第三方发送电子邮件。
9.如权利要求1-8中的任一项所述的方法，其中，所述动作规则确定下列至少一个:通知是否将要发送给所述监视器，以及所述附加动作的报告、结果或输出是否将要包含在所述通知中。
10.如权利要求1-9中的任一项所述的方法，其中，所述事件发布作为来自另一个通知服务器的通知来接收，其中所述呈现体和监视器由不同的通知服务器(600，602)提供服务。
11.一种在通知服务器(500)中的配置成向预订监视器提供与呈现体(B)有关的通知的布置，所述布置包括: -第一接收模块(500a)，其适合于从请求方(502)接收除了所述通知之外并且与涉及所述呈现体的事件发布相关的附加动作的请求(A-Req)， -规则操控模块(500b)，其适合激活动作规则库(500c)中的动作规则(AR)，所述动作规则包括用于执行所请求附加动作的触发条件， -第二接收模块(500d)，其适合接收涉及所述呈现体的事件发布(EP)，-规则检查模块(500e)，其适合针对所述动作规则来检查所述事件发布，以便确定所述事件发布是否满足所述动作规则中的所述触发条件，以及 -动作模块(500f)，其适合在满足所述动作规则中的所述触发条件时运行或发起所述附加动作(Ac)。
12.如权利要求11所述的布置，其中，所述请求方是下列之一:所述监视器、所述呈现体(B)、第三方以及与所述监视器或所述呈现体关联的管理者。
13.如权利要求11或12所述的布置，其中，所述触发条件涉及下列至少一个:事件发布的类型、时刻、星期或季节以及所述事件发布中的报告参数的值。
14.如权利要求11-13中的任一项所述的布置，其中，所述附加动作或者所述触发条件涉及特定呈现体或监视器或者一般涉及任何呈现体或监视器。
15.如权利要求11-14中的任一项所述的布置，其中，所述规则操控模块(500b)还适合通过在所述动作规则库中创建和安装新动作规则(AR)，或者通过在所述动作规则库中选择已现有的动作(A)供激活,来激活所述动作规则。
16.如权利要求11-15中的任一项所述的布置，其中，所述第一接收模块(500a)还适合接收XCAP消息或者SUBSCRIBE消息中的对附加动作的所述请求。
17.如权利要求11-16中的任一项所述的布置，其中，所述规则操控模块(500b)还适合执行下列至少一个:基于预设访问规则(504)来授权所述请求方，以及在激活所述动作规则之前，基于预设认证规则(506)来认证所述请求方。
18.如权利要求11-17中的任一项所述的布置，其中，所述附加动作涉及下列至少一个:用于处理或操控所述事件.发布中的信息的逻辑，以及向所述监视器或所述呈现体或者向第三方发送电子邮件。
19.如权利要求11-18中的任一项所述的布置，其中，所述动作规则确定下列至少一个:通知是否将要发送给所述监视器，以及所述附加动作的报告、结果或输出是否将要包含在所述通知中。
20.如权利要求11-19中的任一项所述的布置，其中，所述第二接收模块(500d)还适合将所述事件发布作为来自另一个通知服务器的通知来接收，其中所述呈现体和监视器由不同的通知服务器(600，602)提供服务。
【文档编号】H04L29/08GK103444154SQ201180069484
【公开日】2013年12月11日 申请日期:2011年3月23日 优先权日:2011年3月23日
【发明者】C.博伯格, M.克莱恩, A.林德格伦, P.奥维布拉特 申请人:瑞典爱立信有限公司