CN102948136A - 用于通信网络中的通知的方法和装置 - Google Patents

Abstract

用于例如在在线服务中、在通信网络中提供关于多个在线实体(B1，B2，B3)并指向多个观察者(A1，A2，A3)的通知数据的方法和设备。操作用于通知服务器(300)的第一通知服务管理器(300a)对多个观察者特定通知进行缓冲(3:3)，以及向例如操作用于RLS实体(302)的第二通知服务管理器(302a)发送(3:5)包含所缓冲的通知的单个联合通知。第二通知服务管理器(302a)继而将联合通知分割(3:6)为原始的多个观察者特定通知，以及将其分别地发送(3:7)至相应的观察者。由此，可以避免从一个或多个通知服务器向例如一个或多个RLS实体传输多个个体通知。

Description

用于通信网络中的通知的方法和装置

技术领域

本发明总体上涉及用于在通信网络中向终端用户提供通知的方法和装置。

背景技术

在当今通信网络中，多媒体服务在终端用户之间变得日益流行。新兴服务的一个特定示例是所谓的“在线”服务，其主要使得与特定客户端有关的数据通过通信网络而可用于其他客户端。在在线服务中，收集客户端的在线数据，并将其存储在在线服务器中，该在线数据继而可以递送至订阅了该在线数据的客户端。在线数据可以涉及客户端的大量不同参数和特征，包括涉及例如终端状态、能力、选择和设置的信息，以及涉及客户端当前状态的信息，诸如地理位置、物理环境，和更加个人化的客户端信息，例如，当前兴趣和需求，个性，情绪等。

在引入、更新、改变或删除客户端的任何在线数据的任何时间，这种类型的信息由此基于从客户端接收的公布(publication)或者从客户端的接入网络接收的公布进行连续收集并存储于在线服务器中。客户端可以由此订阅一个或多个其他客户端的选定在线数据。在此描述中，术语“观察者”通常代表订阅了一个或多个其他终端用户在线数据的终端用户，而“在线实体”通常代表公布在线数据以令其可用于任何授权观察者的终端用户。

公知协议SIP(会话发起协议)典型地用作用于在通信网络上提供在线数据的上述订阅、公布和递送的框架。称为“SIP PUBLISH(SIP公布)”的SIP消息用于向在线服务器发送在线数据以供公布。称为“SIP SUBSCRIBE(SIP订阅)”的另一SIP消息由观察者使用，以订阅在线实体的在线数据。称为“SIP NOTIFY(SIP通知)”的又一SIP消息由在线服务器使用以向观察者提供更新的在线数据。

观察者通常订阅大量在线实体的在线数据。为了减小针对特定观察者的订阅和通知业务的量，已经开发出称为“RLS(资源列表服务器)”的信息递送服务器，该信息递送服务器借助于所谓的“后端订阅”来从在线实体相应的在线服务器收集在线实体的通知，以及向该观察者发送针对所有其在线实体的公共通知。以此方式，观察者不需要与多个在线服务器建立订阅，以及还可以减小所需订阅的数量和消息收发流量，因为RLS用作主要代表所涉及的在线服务器的单个点。

图1示出了根据现有技术的示例，包括在线服务器100，其操作以为充当在线实体的客户端B1、B2和B3的群组提供服务；和RLS102，其操作以向充当观察者的客户端A1、A2和A3的另一群组提供在线数据。在第一示出动作1:1中，每个观察者A1-A3向RLS 102发送针对在线实体B1-B3上在线数据的订阅请求，这典型地通过参考个人定义的用户列表实现。由此，尽管在此简化示例中，所有示出的观察者A1-A3订阅了所有示出的在线实体B1-B3，但是每个观察者可能具有用户列表中其自己的期望在线实体的集合。客户端当然可以充当观察者和在线实体二者。RLS因此在下一动作1:2中、针对每个观察者A1-A3与在线服务器100建立对应的后端订阅。

继而，进一步的动作1:3示出了在线实体B1-B3的在线数据被公布并存储在在线服务器100中，这是连续执行的，并且可以在动作1:1和1:2之前很可能已开始。根据常规解决方案，基本上在每次如动作1:3中进行发布时，在线服务器100向RLS 102发送通知消息，如动作1:4所示，当然，可以采用这样的解决方案，即，在线服务器在于指向特定观察者的通知消息中发送针对该观察者的公布数据之前累计该公布数据的量。RLS 102继而按期向相应的观察者A1-A3发送接收到的通知，如另一动作1:5所示。更多的在线服务器104可以同样地向RLS 102发送具有涉及其关联在线实体的已公布在线数据的通知，如另外的示意箭头所示。

鉴于在线数据具有大量的多样性，可以容易地理解，根据代表不同观察者的各种持续后端订阅，从在线服务器100、104向RLS 102发送的通知量可能非常大，这给传输和处理这些在线通知的网络施加了很大的负荷。而且，动作1:4的在线通知可以跨两个不同的运营商域发送，以及每个通知主要需要在服务器100与RLS 102之间建立单独的通信会话。后一问题至少可以部分通过建立所谓的“SIP隧道”得以克服，在“SIP隧道”中，可以通过相同的会话发送多个在线通知，如文档WO 2008/004962中描述的。

图2示出了另一场景，其中多个在线服务器200向多个RLS实体202发送在线通知。例如，每个在线服务器1，2…分别向每个RLS实体1，2…发送其通知，在向不同RLS实体202多次单独发送相同通知的情况下，会导致较大的流量负荷。如前所述，通知典型地跨不同的运营商域发送，这会使得处理大量消息需要更多的网络和节点资源。

发明内容

本发明的目的在于解决上述问题中的至少某些问题。可以通过使用在所附独立权利要求中定义的方法和设备来实现这些目标和其他目标。

根据一个方面，提供一种在操作用于至少一个通知服务器的第一通知服务管理器中的方法，用于在通信网络中提供关于多个在线实体并指向多个观察者的通知数据。在此方法中，随着接收了在线实体的已公布通知数据，第一通知服务管理器对具有所接收通知数据的多个个体观察者特定通知进行缓冲。在某些点，第一通知服务管理器根据所缓冲的观察者特定通知创建针对这些观察者的联合通知，以及向这些观察者发送联合通知。

根据另一方面，提供一种在可操作用于至少一个通知服务器的第一通知服务管理器中的设备，配置用于在通信网络中提供关于多个在线实体并指向多个观察者的通知数据。第一通知服务管理器包括接收模块，配置用于接收在线实体的已公布通知数据。第一通知服务管理器还包括通知模块，配置用于在至少一个通知缓冲器中对具有所接收的通知数据的多个个体观察者特定通知进行缓冲，以及配置用于根据所缓冲的观察者特定通知创建针对该多个观察者的联合通知。第一通知服务管理器还包括发送模块，配置用于向观察者发送联合通知。

根据另一方面，在第二通知服务管理器中提供一种方法，操作用于在通信网络中提供涉及多个在线实体且指向多个观察者的通知数据。在此方法中，第二通知服务管理器接收包括具有在线实体的通知数据并指向观察者的多个个体观察者特定通知的联合通知。第二通知服务管理器继而将联合通知分割为观察者特定通知，以及分别地提供观察者特定通知，以向相应的观察者分发。

根据另一方面，在第二通知服务管理器中提供一种设备，配置用于在通信网络中提供涉及多个在线实体并指向多个观察者的通知数据。第二通知服务管理器包括接收模块，配置用于接收包括具有在线实体的通知数据并指向观察者的多个个体观察者特定通知的联合通知。第二通知服务管理器还包括通知模块，配置用于将联合通知分割为观察者特定通知，以及提供模块，配置用于提供观察者特定通知，以向相应的观察者分发。

根据上述任一方面的本发明由此可以提供这样的优势，即，减小所需通知和订阅的量，以及由此节约带宽和处理资源。

上述方法和设备可以根据不同实施方式进行配置和实现。在一个实施方式中，第一通知服务管理器对缓冲的观察者特定通知进行压缩，以减小联合通知的大小，以及由此进一步节省带宽和处理资源，这可以以不同方式进行。例如，可以在具有单个SIP报头的SIP消息中发送联合通知，而不同的观察者特定通知作为多部分文档中的单独实体包括在SIP消息中。在另一示例中，联合通知包括使用公共模式、具有不同观察者特定通知的多个XML类型文档。联合通知中的通知信息也可以根据第一通知服务管理器和第二通知服务管理器已知的共享库进行压缩。

在其他实施方式中，在满足预定触发条件时，第一通知服务管理器创建和发送联合通知，其中该预定触发条件可以是预设时段已到期和/或所缓冲的观察者特定通知的量已超出预设限制。由此，可以保持通知的更新和/或缓冲器不会溢出。

第一通知服务管理器可以在用于多个RLS实体的单独通知缓冲器中对观察者特定通知进行缓冲，以及向每个RLS实体发送具有缓冲的观察者特定通知的单独联合通知。第一通知服务管理器可以操作用于一个运营商域中的多个通知服务器，以向相对的运营商域提供单个联系点。同样地，第二通知服务管理器可以操作用于一个运营商域中的多个RLS实体，以向相对的运营商域提供单个联系点。

本解决方案的其他可行特征和益处将从以下详细描述中变得显然。

附图说明

现在，将借助于示例性实施方式并参考附图来更详细地描述本发明，其中：

图1是示出了根据现有技术、具有在线服务器和RLS实体的通信场景的示意框图。

图2是示出了根据现有技术、涉及多个在线服务器和RLS实体的另一通信场景的示意框图。

图3是示出了根据示例性实施方式、具有在线服务器和RLS实体的通信场景的示意框图。

图4是示出了根据另一示例性实施方式、涉及多个在线服务器和RLS实体的另一通信场景的示意框图。

图5是根据另一示例性实施方式、具有由操作用于至少一个通知服务器的第一通知服务管理器执行的动作的流程图。

图6是根据另一示例性实施方式、具有由第二通知服务管理器执行的、操作用于提供指向多个观察者的通知数据的动作的另一流程图。

图7是根据其他示例性实施方式、示出了在操作用于至少一个通知服务器时的第一通知服务管理器的框图。

图8是根据其他示例性实施方式、示出了在操作用于至少一个RLS实体时的第二通知服务管理器的框图。

具体实施方式

简言之，本发明可以用于通过将多个观察者特定通知缓冲在操作用于通知服务器的管理实体中，以及继而向操作用于RLS实体的另一管理实体发送包含所缓冲的观察者特定通知的单个联合通知，避免从一个或多个通知服务器向一个或多个RLS实体传输众多个体通知。后一管理实体继而能够将联合通知分割为原始的多个观察者特定通知，以及分别地向RLS实体提供这些通知，以进一步传播至相应的观察者。

在此描述中，这些管理实体将分别称为第一和第二“通知服务管理器”。实际上，通知服务可以是上述在线服务，并且下述示例和实施方式通常涉及在线服务，当然，本发明不限于此。此处使用的术语“在线数据”由此可以理解为等同于“通知数据”。此外，术语RLS将用以简要地代表任何服务器或实体，其根据本解决方案进行操作以向订阅观察者递送关于任何种类的通知数据的信息，并且本发明并不限于使用观察者侧上任何特定类型的信息递送服务器或实体。例如，此处描述的RLS实体实际上可以是在线服务器，这取决于实现。

下述示例中的各种通知可以借助于SIP协议(例如，在SIPNOTIFY消息中)并基于针对通知数据建立的订阅进行传送。备选地，所描述的通知可以在不使用基于SIP的订阅的情况下进行传送，并且在下述示例中观察者针对在线实体的通知数据的个体“订阅”应当理解为用于向观察者递送这种通知的任何适当协定。

图3示出了当在在线服务的环境中使用时、本发明可以如何工作的第一示例，涉及服务于在线实体B1-B3群组的在线服务器300和服务于订阅在线实体B1-B3的在线数据的观察者A1-A3群组的RLS实体302。当然，任何数量的观察者可以订阅任何数量在线实体的任何类型在线数据，而实际上的数量通常远大于此示例中的数量，例如，以成千上万终端用户的量级。示意的第一通知服务管理器300a配置于在线服务器300中，以及示意的第二通知服务管理器302a配置于RLS实体302中。实际上，管理器300a和302a可以分别集成在在线服务器300和RLS 302内，或者可以实现为与在线服务器300和RLS 302连接的单独节点。还可行的是，第二通知服务管理器302a操作用于直接向观察者提供观察者特定通知，即，不涉及任何RLS实体。

第一动作3:1示出了RLS 302以常规方式代表观察者A1-A3、针对在线实体B1-B3的在线数据与在线服务器300建立个体后端订阅，例如，如以上动作1:1和1:2中描述的。在线实体B1-B3也同样地以常规方式在动作3:2中向在线服务器300公布其在线数据，这再次可以是或多或少的连续过程吞吐，导致对应的个体观察者特定通知待传送至RLS 302，以供进一步传播至观察者A1-A3。

在此过程中，在线服务器300中的第一通知服务管理器300a按期创建具有所接收在线数据的个体观察者特定通知，以及将观察者特定通知缓冲在关联至RLS 302的缓冲器，如进一步的动作3:3所示。第一通知服务管理器300a可以将通知中的在线数据供应至不止一个RLS，以及在该情况下，针对每个RLS维护通知缓冲器，这将在下文中更详细地描述。

在某个点，管理器300a创建包括所有缓冲的观察者特定通知的单个通知，如下一动作3:4所示，在此描述中，该单个通知称为“联合通知”。联合通知由此包括已针对特定观察者创建的并为从在线服务器300向观察者侧(例如，RLS 302)递送而缓冲的所有个体通知。联合通知继而在接下来的动作3:5中作为单个消息发送至第二通知服务管理器302a。由此，可以通过替代传统方式中在多个单独消息和/或会话中发送个体通知、而在单个会话中发送唯一的联合通知消息而节省更多的处理和带宽，尤其是当跨两个运营商域发送消息时更是如此。利用此解决方案，还可以以不同方式压缩联合通知，以进一步节约带宽和处理资源，这将在下文中更详细地描述。

在满足预定触发条件时，诸如，在预设时段已到期时，或者在所缓冲的观察者特定通知的量已超出预设限制时(即，缓冲器“满了”时)，可以触发联合通知的发送。取决于实现，触发条件可以包括这些条件中的仅一个或二者，使得联合通知在二者之一得到满足时便会发送。例如，缓冲器有时可能变满得非常快，并且是在预设时段到期之前，或者反之亦然。触发时段可以进行设置，以确保个体通知中的在线数据在递送之前不会在某些方面变得“过时”，仍然得到替代以传统方式在单独消息和/或会话中发送个体通知而发送单个联合通知消息的足够且期望的益处。

在接收联合通知时，第二通知服务管理器302a通过在动作3:6中从联合通知中提取观察者特定通知而分割该联合通知，以及创建主要向RLS 302提供的多个单独的观察者特定通知消息，RLS 302最终将这些消息分别地传播至观察者A1-A3，如在最后示出的动作3:7中所示。备选地，第二通知服务管理器302a可以直接向相应的观察者分发观察者特定通知，即，无需涉及任何RLS实体。只要后端订阅有效，在第一通知服务管理器300a中缓冲来自所接收公开的观察者特定通知以及向第二通知服务管理器302a发送联合通知的过程便可以继续。在联合通知中个体观察者特定通知中所寻址的观察者的集合由此可以在引入了新的后端订阅以及旧的后端订阅到期时随着时间改变。

图4示出了本发明还可以如何在涉及多个在线服务器400(每个服务于各种在线实体)和多个RLS实体402(每个服务于各种观察者)时进行工作的第二示例，尽管为了简化未在此附图中示出那些在线实体和观察者。示意的第一通知服务管理器400a配置用以操作用于在线服务器400，以及示意的第二通知服务管理器302a配置用以操作用于RLS实体402。在此示例中，RLS实体402和在线服务器400分别属于不同的运营商域A和B，尽管下述过程当然也可以应用于RLS实体402和在线服务器400属于相同运营商域时。第一和第二通知服务管理器400a和400b由此可以实现为分别与在线服务器400和RLS实体402连接的单独节点。

尽管此附图中未示出用于在RLS实体402和在线服务器400之间建立后端订阅的动作，但是假设，这已经以常规方式实现了。由此，假设每个RLS 402已代表各种观察者、针对在线实体的在线数据与一个或多个在线服务器400建立了个体后端订阅，基本上如针对图1和图3二者在上文所述。此外，假设，由在线服务器400服务的在线实体以常规方式或多或少地连续地公布其在线数据，如指向相应在线服务器400的箭头示意性示出的。

在此示例中，每个在线服务器400根据上述后端订阅创建具有所接收在线数据的多个个体观察者特定通知，以及将其发送至第一通知服务管理器400a，如第一动作4:1所示，只要正在公布在线数据，则上述动作可以以连续方式同样地继续。同时，管理器400a将所接收的观察者特定通知缓冲在针对相应的RLS实体402维持的不同通知缓冲器中，如进一步的动作4:2所示。应当注意，在此场景中，特定在线服务器可以具有与若干RLS实体的后端订阅，反之亦然。

在适当的时候，第一通知服务管理器400a创建联合通知(每个包含缓冲的观察者特定通知)，并在进一步的动作4:3中向第二通知服务管理器402a发送该联合通知，这可以在如上所述满足适当的触发条件时得以触发。由此，每个联合通知被引导至特定的RLS，并且包含在专门针对该RLS在第一通知服务管理器400a中维护的通知缓冲器中累积的观察者特定通知。如附图所示，联合通知“1”寻址到RLS“1”，联合通知“2”寻址到RLS“2”，等等。

以此方式，可以从多个在线服务器向每个RLS实体发送具有观察者特定通知的仅一个通知消息。实际上，共享的第一和第二通知服务管理器400a操作以“级联”跨运营商域A和B传送的多个个体观察者特定通知。第一通知服务管理器400a由此操作用于运营商域B中的多个在线服务器400，以及向相对的运营商域A提供单个联系点，以传送在线通知。同样地，第二通知服务管理器402a操作用于运营商域A中的多个RLS实体402，以及向相对的运营商域B提供单个联系点，用于接收在线通知。

还可行的是，仅在一侧采用共享的通知服务管理器400a，402a，使得第一通知服务管理器400a直接向RLS实体402发送联合通知，或者第二通知服务管理器402a直接从在线服务器400接收联合通知。以此方式，例如较之于针对图2描述的情况，可以节省更多的带宽和处理资源。例如，取决于使用的通信协议、信道和处理资源，可以限制联合通知消息的大小。

第二通知服务管理器402a继而在动作4:4中将每个接收的联合通知1，2，3，…分割为多个个体观察者特定通知，以及在最后示出的动作4:5中，向相应的RLS实体402分别地提供观察者特定通知。RLS实体402继而可以以常规方式进一步向相应的观察者传播观察者特定通知，如从相应的在线RLS实体402指出的箭头示意性所示。所接收联合通知1，2，3，…的分割是单独针对每个联合通知实现的，因为这些联合通知通常在不同的时刻到达，并且动作4:3-4:5应当视为针对每个联合通知的过程。

上述示例中的在线服务器300和400可以是处理任何通知服务的任何类型的通知服务器。如上所述，在第一通知服务管理器300a或400a中创建联合通知可以包括压缩所缓冲的观察者特定通知，这可以根据不同的实施方式实现。在一个实施方式中，第一通知服务管理器在具有单个SIP报头的SIP消息中发送联合通知，而不同的观察者特定通知作为多部分文档中的单独实体包括在SIP消息中。在另一实施方式中，联合通知包括利用公共模式、具有不同观察者特定通知的多个XML类型文档，该公共模式带有针对所有XML文档相同且有效的信息。

在又一实施方式中，例如，当跨不同运营商域发送联合通知或在相同的运营商域中发送联合通知时，根据两个通知服务管理器已知的共享预定义“库”来压缩联合通知中的在线信息。此库由此提供特定数据向缩写的“码”等的翻译。可以使用的压缩方法示例是“gzip”和“deflate”。此外，联合通知可以由第一通知服务管理器300a或400a进行加密，以及以加密形式发送，以便在接收时由第二通知服务管理器302a或402a进行解密。

现在将参考图5的流程图来描述第一通知服务管理器执行的过程。与图3和图4的示例类似，第一通知服务管理器操作用于至少一个通知服务器(例如，在线服务器)，以及配置用于在通信网络中提供涉及多个在线实体、指向多个观察者的通知数据。在第一可选动作500中，第一通知服务管理器例如针对与在线实体有关的通知数据、与一个或多个RLS实体建立观察者的个体后端订阅。如在上述图4的示例中，此动作不排除第一通知服务管理器可以与多个RLS实体建立这种观察者的后端订阅。在此上下文中，观察者针对在线实体通知数据的个体“订阅”可以是用于向观察者递送这种通知的任何适当协定，本发明在此方面不受限制。此外，针对通知数据的订阅可以由除第一通知服务管理器之外的实体(例如，服务于与第一通知服务管理器不同的观察者的另一适当节点)建立，以及在该情况下，动作500可以省略。

在下一动作502中，接收了在线实体的各种已公布通知数据，这基本上对应于图3的动作3:2，并且第一通知服务管理器创建具有所接收通知数据的多个个体观察者特定通知，并在进一步的动作504中，将其缓冲在与观察者相关联的缓冲器中。动作502和504基本上或多或少地连续执行。

继而，在进一步的动作506中，检查是否满足了用于为观察者(例如，由特定RLS服务的)制作联合通知的预定触发条件。预定触发条件可以是预设时段已到期，和/或所缓冲的数据量已超出预设限制，如上文所述。如果在动作506中未满足触发条件，则过程返回分别接收进一步的通知数据以及缓冲进一步的观察者特定通知的动作502和504。另一方面，如果在动作506中发现触发条件得以满足，则第一通知服务管理器在下一动作508中根据所缓冲的观察者特定通知来创建用于观察者的联合通知。

联合通知继而在最终示出的动作510中最终被发送至观察者，例如，对应的RLS。该过程继而可以从动作502重复，如虚线箭头所指示的。应当注意，图5中示出的过程也可以用于涉及对应的后端订阅、缓冲器和联合通知的不止一个RLS实体。在该情况下，动作506的触发条件因此可以分别应用于针对RLS实体维持的对应通知缓冲器。

现在将参考图6的流程图描述由第二通知服务管理器执行的过程。与图3和图4的示例类似，第二通知服务管理器可以操作用于至少一个RLS实体，以及配置用于例如根据在线服务、在通信网络中提供涉及多个在线实体并指向多个观察者的通知数据。假设一个或多个通知服务器例如已针对涉及在线实体的通知数据、与一个或多个RLS实体建立了观察者的个体后端订阅。

在第一动作600中，第二通知服务管理器接收联合通知，其包括具有在线实体通知数据并指向观察者的多个个体观察者特定通知，例如，根据上述动作510从第一通知服务管理器发送的联合通知。联合通知可以如上所述指向多个RLS实体之一。第二通知服务管理器继而在进一步的动作602中将所接收的联合通知分割为若干观察者特定通知，以及在最后示出的动作604中分别提供这些观察者特定通知，以供分发至相应的观察者。如上面针对图3和图4的示例所描述的，第二通知服务管理器可以集成在RLS实体中，或者实现为可以与一个或多个RLS实体连接的单独节点。第二通知服务管理器还可以直接向相应的观察者分发观察者特定通知，而无需涉及任何RLS实体。

在图7中，示出了根据此解决方案、在操作用于至少一个通知服务器(未示出)时的第一通知服务管理器700。例如，管理器700可以用于为图3、图4和图5的示例中的第一通知服务管理器提供上文描述的任一特征和实施方式。

第一通知服务管理器700配置用于在通信网络中提供涉及多个在线实体B1，B2，B3…并指向多个观察者(未示出)的通知数据。第一通知服务管理器700可以包括可选的订阅模块700a，配置用于针对在线实体通知数据、为观察者与至少一个RLS 702建立个体订阅S1，S2…。备选地，取决于实现，可以由与第一通知服务管理器700不同的、服务于观察者的另一节点来创建针对通知数据的订阅。管理器700进一步包括接收模块700b，配置用于接收在线实体的已公布通知数据，例如，如来自至少一个通知服务器(未示出)的通知消息所供应的。

管理器700还包括通知模块700c，配置用于在至少一个通知缓冲器700d中缓冲具有所接收通知数据的多个个体观察者特定通知，以及配置用于根据所缓冲的观察者特定通知来创建联合通知。管理器700还包括发送模块700e，配置用于向观察者(例如，服务于观察者的RLS实体)发送联合通知。

第一通知服务管理器700中的不同模块可以配置并适配用于提供其他可选的特征和实施方式。在一个示例性实施方式中，通知模块700c进一步配置用于通过压缩所缓冲的观察者特定通知来创建联合通知。此压缩可以以不同方式实现。例如，发送模块700e可以在具有单个SIP报头的SIP消息中发送联合通知，其中不同的观察者特定通知作为多部分文档中的单独实体包括在SIP消息中。另一可能性是通知模块700c进一步配置用于如上所述的根据第一和第二通知服务管理器已知的共享库来压缩联合通知中的信息。可以在联合通知跨不同运营商域发送时以及在相同的运营商域中发送时采用上述压缩。

通知模块700c也可以配置用于在满足预定触发条件时创建联合通知，该条件可以包括预设时段已到期和/或所缓冲的特定通知的量已超出预设限制。

在另一实施方式中，订阅模块700a进一步配置用于与多个RLS实体702建立观察者的后端订阅。在该情况下，通知模块700c进一步配置用于在针对相应的RLS实体维护的单独通知缓冲器700d中缓冲观察者特定通知，使得针对RLS1创建一个通知缓冲器，针对RLS2创建另一通知缓冲器，等等。在此场景中，发送模块700e进一步配置用于分别向每个RLS实体RLS1，RLS2…发送具有所缓冲的观察者特定通知的单独联合通知N1，N2…。当针对相应的RLS实体采用若干通知缓冲器700d时，每个联合通知N1，N2…独立于其他联合通知进行处理。

在图8中，示出了在根据本解决方案操作时的、例如用于至少一个RLS实体(未示出)的第二通知服务管理器800。例如，管理器800可以用于为图3、图4和图6的示例中的第二通知服务管理器提供上述的任何特征和实施方式。假设一个或多个在线或通知服务器PS1，PS2…已针对涉及在线实体的通知数据建立了观察者的个体后端订阅，第二通知服务管理器800配置用于提供指向观察者的、在线实体的通知数据。

第二通知服务管理器800包括接收模块800a，配置用于接收联合通知N1或N2，包括指向观察者且具有在线实体通知数据的多个个体观察者特定通知。联合通知N1或N2可以从通知服务器802接收或者从操作用于至少一个通知服务器802的第一通知服务管理器(未示出)接收。

管理器800进一步包括通知模块800b，配置用于例如基本上如上述动作3:6和4:4描述的、将接收的联合通知分割为上述观察者特定通知。管理器800还包括提供模块800c，配置用于分别地提供观察者特定通知，以向相应的观察者分发。

第二通知服务管理器800中的不同模块可以配置和适配用于提供进一步的可选特征和实施方式。在一个示例性实施方式中，如果已经通过压缩所缓冲的观察者特定通知而创建了联合通知，则通知模块800b进一步配置用于解压缩观察者特定通知，这可以由不同方式实现。例如，可以在具有单个SIP报头和多部分文档的SIP消息中接收联合通知，在该多部分文档中，不同的观察者特定通知作为单独实体包括在其中。备选地，联合通知可以包括使用公共模式、具有不同观察者特定通知的多个XML类型文档，其中公共模式带有对所有XML文档有效的信息，由此不需要复制XML文档。通知模块800b可以进一步配置用于如上所述的根据共享库解压缩联合通知中的通知信息。可以在联合通知跨不同运营商域发送时以及在相同运营商域内发送时采用上述解压缩。

第一和第二通知服务管理器700和800中的各种功能实体在此描述中称为“模块”，尽管其也可以称为单元、块、部件等。应当注意，图7和图8仅仅从逻辑角度示出了管理器700和800，本领域技术人员可以在现实中自由地使用适当的软件和硬件装置实现这些功能。由此，在适当的时候，本发明通常不限于管理器700和800的所示结构，而是其功能模块700a-e和800a-c可以分别配置用于根据在上文针对图3-图6描述的方法和过程进行操作。

上述功能模块700a-e和800a-c可以实现为计算机程序的模块，每个模块包括在由管理器700和800中的处理器运行时引起管理器700和800执行上述功能和动作的代码装置。计算机程序可以由计算机程序产品承载，每个包括计算机程序存储于其上的计算机可读介质。例如，每个计算机程序可以是闪存，ROM(只读存储器)或EEPROM(电可擦除可编程ROM)，以及上述计算机程序模块可以分发在采用管理器700和800中存储器形式的不同计算机程序产品上。

尽管已参照特定示例性实施方式描述了本发明，但是这些描述总体上仅意在示出发明性原理，而不应当用来限制本发明的范围。本发明由所附权利要求限定。

Claims (33)

1.一种在操作用于至少一个通知服务器(300，400)的第一通知服务管理器(300a，400a)中、在通信网络中提供关于多个在线实体(B1，B2，B3)并指向多个观察者(A1，A2，A3)的通知数据的方法，所述方法包括：

-接收(502)所述在线实体的已公布通知数据，

-对具有所接收通知数据的多个个体观察者特定通知进行缓冲(504)，

-根据所缓冲的观察者特定通知创建(508)针对所述观察者的联合通知，以及

-向所述观察者发送(510)所述联合通知。

2.如权利要求1的方法，其中创建所述联合通知包括压缩所述缓冲的观察者特定通知。

3.如权利要求2的方法，其中所述联合通知在具有单个SIP报头的SIP消息中发送，以及不同的观察者特定通知作为多部分文档中的单独实体包括在所述SIP消息中。

4.如权利要求2的方法，其中所述联合通知包括利用公共模式、具有不同观察者特定通知的多个XML类型文档。

5.如权利要求2的方法，其中所述联合通知中的通知信息根据所述第一通知服务管理器和第二通知服务管理器已知的共享库进行压缩。

6.如权利要求1-5中任一的方法，其中在满足预定触发条件时，创建并发送所述联合通知，所述触发条件包括以下至少之一：预设时段已到期和所缓冲的观察者特定通知的量已超出预设限制。

7.如权利要求1-6中任一的方法，其中所述联合通知以加密形式发送。

8.如权利要求1-7中任一的方法，其中所述第一通知服务管理器(400a)建立观察者与多个RLS实体(402)的个体订阅，在用于相应RLS实体的单独通知缓冲器中对所述观察者特定通知进行缓冲，以及向每个RLS实体发送具有所缓冲的观察者特定通知的单独联合通知。

9.如权利要求1-8中任一的方法，其中所述第一通知服务管理器(400a)操作用于一个运营商域中的多个通知服务器(400)，以向相对的运营商域提供单个联系点。

10.一种在操作用于至少一个通知服务器的第一通知服务管理器(700)中、配置用于在通信网络中提供关于多个在线实体(B1，B2，B3)并指向多个观察者(A1，A2，A3)的通知数据的设备，其中所述第一通知服务管理器包括：

-接收模块(700b)，配置用于接收所述在线实体的已公布通知数据，

-通知模块(700c)，配置用于在至少一个通知缓冲器中对具有所接收的通知数据的多个个体观察者特定通知进行缓冲，以及配置用于根据所缓冲的观察者特定通知创建针对所述观察者的联合通知，以及

-发送模块(700e)，配置用于向所述观察者发送所述联合通知。

11.如权利要求10的设备，其中所述通知模块(300c)进一步配置用于通过压缩所述缓冲的观察者特定通知来创建所述联合通知。

12.如权利要求11的设备，其中所述发送模块(700e)进一步配置用于在具有单个SIP报头的SIP消息中发送所述联合通知，不同的观察者特定通知作为多部分文档中的单独实体包括在所述SIP消息中。

13.如权利要求11的设备，其中所述联合通知包括利用公共模式、具有不同观察者特定通知的多个XML类型文档。

14.如权利要求11的设备，其中所述通知模块(700c)进一步配置用于根据所述第一通知服务管理器和第二通知服务管理器已知的共享库压缩所述联合通知中的通知信息。

15.如权利要求10-14中任一的设备，其中所述通知模块(700c)进一步配置用于在满足预定触发条件时，创建所述联合通知，所述触发条件包括以下至少之一：预设时段已到期和所缓冲的观察者特定通知的量已超出预设限制。

16.如权利要求10-15中任一的设备，其中所述联合通知以加密形式发送。

17.如权利要求10-16中任一的设备，其中已与多个RLS实体(702)建立用于观察者的个体订阅，所述通知模块(700c)进一步配置用于在用于相应RLS实体的单独通知缓冲器(700d)中对所述观察者特定通知进行缓冲，以及所述发送模块(700e)进一步配置用于向每个RLS实体发送具有所述缓冲的观察者特定通知的单独联合通知。

18.如权利要求10-17中任一的设备，其中所述第一通知服务管理器(700)操作用于在一个运营商域中的多个通知服务器，以向相对的运营商域提供单个联系点。

19.如权利要求10-18中任一的设备，进一步包括订阅模块(700a)，配置用于为所述观察者针对所述在线实体的通知数据与至少一个RLS建立个体订阅。

20.一种在第二通知服务管理器(302a，402a)中、操作用于在通信网络中提供涉及多个在线实体(B1，B2，B3)并指向多个观察者(A1，A2，A3)的通知数据的方法，所述方法包括：

-接收(600)包括具有所述在线实体的通知数据并指向所述观察者的多个个体观察者特定通知的联合通知，

-将所述联合通知分割(602)为所述观察者特定通知，以及

-分别地提供(604)所述观察者特定通知，以向相应的观察者分发。

21.如权利要求20的方法，其中对所述接收的联合通知中的所述观察者特定通知进行解压缩。

22.如权利要求21的方法，其中在具有单个SIP报头和多部分文档的SIP消息中接收所述联合通知，其中在所述多部分文档中，不同的观察者特定通知作为单独的实体包括在其中。

23.如权利要求21的方法，其中所述联合通知包括利用公共模式、具有不同观察者特定通知的多个XML类型文档。

24.如权利要求21的方法，其中所述联合通知中的通知信息根据第一通知服务管理器和第二通知服务管理器已知的共享库进行解压缩。

25.如权利要求20-24中任一的方法，其中所述联合通知以加密形式接收。

26.如权利要求20-25中任一的方法，其中所述第二通知服务管理器操作用于在一个运营商域中的多个RLS实体，以向相对的运营商域提供单个联系点。

27.一种在第二通知服务管理器(302a，402a)中、配置用于在通信网络中提供涉及多个在线实体(B1，B2，B3)并指向多个观察者(A1，A2，A3)的通知数据的设备，其中所述第二通知服务管理器包括：

-接收模块(800a)，配置用于接收包括具有所述在线实体的通知数据并指向所述观察者的多个个体观察者特定通知的联合通知(N1，N2…)，

-通知模块(800b)，配置用于将所述联合通知分割为所述观察者特定通知，以及

-提供模块(800c)，配置用于提供所述观察者特定通知，以向相应的观察者分发。

28.如权利要求27的设备，其中所述通知模块(800b)进一步配置用于对所述接收的联合通知中的所述观察者特定通知进行解压缩。

29.如权利要求28的设备，其中在具有单个SIP报头和多部分文档的SIP消息中接收所述联合通知，其中在所述多部分文档中，不同的观察者特定通知作为单独的实体包括在其中。

30.如权利要求28的设备，其中所述联合通知包括利用公共模式、具有不同观察者特定通知的多个XML类型文档。

31.如权利要求28的设备，其中所述通知模块(800b)进一步配置用于根据第一通知服务管理器和第二通知服务管理器已知的共享库对所述联合通知中的通知信息进行解压缩。

32.如权利要求27-31中任一的设备，其中所述联合通知以加密形式接收。

33.如权利要求27-32中任一的设备，其中所述第二通知服务管理器操作用于在一个运营商域中的多个RLS实体，以向相对的运营商域提供单个联系点。

Images