CN102648614A - 用于处理通信系统所存储的数据的方法 - Google Patents

Abstract

用于处理与通信系统的用户有关的数据的方法、设备和计算机程序，该通信系统包括：存储与系统的用户有关的数据的数据库服务器和多个服务服务器。数据库服务器根据接收的请求(1101)修改(1103)其中为用户存储的第一数据，并且发送通知数据修改的第二消息(1109)到第一服务服务器，第二消息包括：用户的标识符、修改后的第一数据及处理与用户有关的数据的系统的第二服务服务器的标识符。第一服务服务器发送第三消息(2105)到第二服务服务器，请求修改其中与所述用户相关保存的数据。本发明的特征有助于降低分层系统中的信令，因为附加数据在第二消息中传递。

Description

用于处理通信系统所存储的数据的方法

技术领域

本发明涉及用于处理与通信系统的用户有关的数据的方法、设备和计算机程序，所述通信系统包括：存储与系统的用户有关的数据的数据库服务器和提供服务到利用这些数据的所述用户的多个服务服务器。

背景技术

通信系统在传统上通过使用多个单片（monolithic）服务服务器向其用户提供服务。术语“单片服务器”指一种设备，其包括允许它通过使用它在内部存储的数据来处理它能够接收的信令以及要发送的信令的处理和数据存储能力。换而言之，单片服务器布置成通过使用其内部处理部件以及通过使用它在内部存储的数据来服务于某个服务。

然而，诸如可扩展性和性能或部署/实现成本等因素开始驱向另一种解决方案，其中，一些单片服务器提供的功能性（比如说）是“分级的”，产生了分层架构。此种解决方案（后文也称为“数据分层架构”DLA）后的原理在于与不同服务器一起将服务逻辑处理功能从纯数据存储功能去耦。

数据分层架构DLA是一种物理基础设施，本质上包括：充当后端存储系统的数据库服务器(DBS)和访问DBS以获得和/或修改其中存储的数据以便提供它们分别服务于的服务的多个服务器。视诸如要存储的数据量、要求的访问可用性、数据分布/复制策略等因素而定，DBS能够包括一个数据库或多个数据库（例如，与分离的机器一起实现）。在任何情况下，将服务逻辑处理从纯数据存储去耦的原理允许使用商业可用的稳固DBS产品（这些产品能够充当DLA实现中的可靠后端存储装置），而不是设计高成本专有（单片）产品（这些产品必须处理：用于根据特定服务逻辑处理它们服务于的服务的高消息信令处理能力和与数据存储能力有关的高容量/弹性）。

另外，由于相同DBS能够用作服务于相同或不同服务的多个服务服务器的后端数据存储装置，因此，由于通信系统中特定服务产生的总信令例如能够沿适用于服务于所述特定服务并且也适用于DLA架构（例如，使用任何合适的负载平衡机制）的多个类似服务服务器分布，这些服务服务器随后应充当信令/处理前端。这允许甚至更降低用于生产和/或维护此种服务器的成本，因为能够减少每服务器的处理负载（由于某个服务产生的总信令能够在可用（前端）服务器之间被划分）。此外，这也为通信系统的运营商提供了可扩展性优点，因为它能够根据给定服务的信令需求调整（DLA适用）服务服务器的数量，并因此降低了其运营和资本支出。

相应地，最可能设想根据DLA适用的服务服务器是给定它们服务于的服务的特定特性时必须和信令消息的高速率一致和/或被要求处理大量数据以便提供所述服务的那些服务器。生成和/或维护这些服务器的成本因此能够得以降低，因为其复杂性能够得以降低（由于不要求它们具有高处理能力且同时具有高存储能力）。

除其它之外，设想根据DLA适用的服务服务器的示例有：归属位置寄存器(HLR)、归属订户服务器(HSS)。其它种类的服务器例如能够是（例如，通过web浏览器）为多个用户提供诸如以下基于web的应用的服务器：日历服务、银行/金融服务、个性化数据存储服务等；其中，它们需要用于与被服务用户有关的其服务操作的数据存储在后端存储系统(DBS)中。

例如，适用于DLA架构的HLR服务器随后能够包括用于处理例如移动交换中心/来访位置寄存器(MSC/VLR)或服务GPRS支持节点(SGSN)收发的移动应用部分(MAP)消息的信令和处理部件，而它将需要用于此类处理的数据（例如，与用于涉及用户的电路交换CS和/或分组交换PS域有关的用户的用户数据，如：用户和/或终端标识符、位置信息、补充服务数据、服务禁止数据等）应从后端DBS访问，后端DBS也能够存储其它种类的服务服务器（例如，HSS、web服务器、授权/认证AAA服务器等）的数据。类似地，例如，适用于DLA的HSS服务器能够包括用于处理例如呼叫会话控制功能(CSCF)和会话启动协议SIP应用服务器(AS)收发的DIAMETER (IETF RFC 3588)信令的信令和处理部件，而它需要用于与IP多媒体域IMS相关的此类处理的数据（例如，用于涉及用户的所谓“用户简档”数据）能够从与HLR服务器或其它种类的服务服务器使用的相同后端DBS访问。

DLA的另外优点是在包括提供服务到多个用户的多个服务服务器的通信系统中，不要求所有这些服务器适用于DLA特征，而只要求它们中的一些适用于DLA特征。例如，在包括IP多媒体域(IMS)的通信系统的情况中，系统的HSS服务器能够适用于DLA，而CSCF（和/或在一些情况下的AS）能够继续是（比如说）“单片”服务服务器，在本地处理（即，为使用进行存储和访问）它们为提供其相应服务而需要使用的数据。类似地，在包括例如GSM电路交换CS和/或分组交换PS域(GSM/GPRS)的移动通信系统的情况中，系统的HLR服务器能够适用于DLA，而在与如上所述相同的意义上，诸如MSC/VLR、SGSN等其它服务服务器继续是“单片”。

要注意到，诸如CSCF、MSC/VLR或SGSN等服务服务器在暂时基础上处理给定用户的数据（即，在通过它们注册和服务一些用户时在本地存储和使用这些用户的数据）。不同的是，诸如HSS、HLR或其它种类的订户服务器等其它服务服务器旨在在永久性基础上保存（比如说）这些数据（即，在CSCF、MSC/VLR等上本地暂时保存的数据）的一些数据的主副本及与其它用户（例如，非注册用户）有关，在本地存储（即，在单片实现中）或在后端DBS中访问的数据。此环境（即，数据的暂时处理机相对主处理机）也能够在其它种类的通信系统中出现，这也能够有利于使至少部分其网络基础设施相应地适用于DLA。

在涉及数据配备时，DLA也可能提供另外的优点。例如，在只包括多个单片服务服务器的系统中，在与用户有关的一些数据要被修改（例如，初始设置，改变其当前内容或删除）时，要求配备服务器配置有（或要求配备/管理终端的运营商知道）所述数据涉及的特定服务服务器，以便发送请求对应数据修改的消息到服务器。另外，单片实现中的服务服务器通常趋向于提供异类配备接口，有时是专有接口（即，非标准化信令接口）。另一方面，根据DLA布置的系统可能提供用于数据配备的单个点，即，DBS。此外，商业可用DBS产品通常提供公知/标准化的信令接口，如LDAP（“Light-weight Directory Access Protocol”，IETF RFC 4511），这些接口由其客户端用于读取和修改其中存储的数据，并且也能够用于数据配备目的。这些特征能够帮助简化配备进程，减少由于配备产生的消息信令，并且也防止出错，因为DLA的后端DBS能够为与多个用户有关的数据提供单点的访问和管理。不过，直接在DBS上执行数据配备带来了一些问题。例如，发送配备命令的服务器（或处理所述服务器的操作人员）将被要求在一些情况下预定某个数据修改对一些另外的有关数据的影响。在DLA架构中，这已导致了配备解决方案，所述配备解决方案涉及先发送配备命令（即，修改一些数据的请求）到对应前端，以及随后启动在前端与DBS之间的交互以便在其中存储配备命令涉及的数据修改。

另外，DLA内在的特性是对于一些服务器，外部信令趋向于增大，因为它们需要与DBS进行通信，以便获得它们提供其相应服务所要求的数据以及也在需要时更新这些数据。此外，由于这些数据的一些数据的暂时副本能够沿另外的服务服务器（例如，保持数据的暂时副本的服务器）分散，因此，在这些数据的一些数据在DBS中进行修改时，能够要求更多的外部信令以便保持数据一致性。除涉及服务器的性能外，外部信令依赖诸如路由器、桥接器、网关等网络元件，并且也依赖这些网络元件提供的带宽容量，带宽容量能够由于其它种类的信令业务（例如，不只是由于DLA有关业务）而变化，并且能够最终影响通信系统的性能。

因此，应希望提供至少部分允许减少DLA基础设施中的外部信令而不损害其内在益处的解决方案。

发明内容

本发明的方面涉及如独立权利要求中所要求权利的方法、服务器和计算机程序产品。本发明的实施例在从属权利要求中被陈述。

在数据库服务器根据接收的请求来修改其中为用户存储的第一数据时，它向第一服务服务器发送通知数据修改的消息。来自数据库服务器的该消息包含：用户的标识符，与修改后第一数据有关的信息以及处理与用户有关的数据以便向所述用户提供服务的第二服务服务器的标识符。所述消息中的数据能够由第一服务器用于进一步处理数据修改，而无需为获得附加信息而进一步向数据库服务器询问。第一服务服务器随后使用来自数据库服务器的所述消息中接收的数据，以便向识别的第二服务服务器发送另外的消息，该消息包括用户的标识符并请求修改其中与所述用户相关保存的数据。

根据一个实施例，来自数据库服务器的该消息也能够包括：与修改前第一数据有关的信息和/或与请求数据库服务器中的数据修改的数据操作的类型有关的信息和/或与另外的第二数据有关的信息，所述另外的第二数据在数据库服务器中与所述用户相关存储，其未受修改影响。

从数据库服务器中发送的该消息中包括的数据帮助第一服务器确定：关于向所述用户提供服务的另外的服务服务器中的影响，如何处理在数据库服务器中发生的数据修改的结果。根据本发明的实施例，第一服务器能够使用任何这些数据来确定是否发送另外的消息到第二服务服务器和/或选择用于发送所述消息的特定协议。

通过在来自数据库服务器的该消息中包括与已修改的给定第一数据有关的附加数据，能够减少服务服务器与数据库服务器之间另外的最终信令。在评估对给定数据的特定数据修改可对提供到涉及用户的服务的影响或者在为进一步处理数据修改，服务服务器必需访问和检查用户的另外数据，并且实现此类服务逻辑的服务服务器未在本地存储这些数据时，这特别有用。另外，数据库服务器无需知道关于给定服务给定数据的语义，也无需知道数据修改可能对某些服务服务器的影响，因为数据库服务器中存储的在给定数据与另外的有关数据之间的简单链接能够用于确定在所述给定数据的修改时必须向服务服务器发送哪些数据。

根据一个实施例，其中，通信系统包括第一和第二网络域，以及其中第一数据属于第一域中用户的数据，本发明还包括：将修改的第一数据转换成根据第二域的格式，以及由数据库服务器存储转换的修改的第一数据。此外，此特征允许在减少必需信令时同步提供到不同网络域中相同用户的类似服务，因为对于与第一域有关的数据请求的数据更改能够促使对于与第二域有关的数据也执行数据更改，而无需到数据库服务器的另外的明确数据更改请求。

第一和第二网络域能够分别包括以下的至少之一：移动网络电路交换CS域、移动网络分组交换PS域及因特网协议多媒体子系统域IMS。

附图说明

图1示出根据本发明的一个实施例的通信系统。

图2示意示出根据本发明的一个实施例的与第一网络域中和第二网络域中用户有关的数据的结构。

图3示出根据本发明的实施例的方法的步骤。

图4和5分别示意示出根据本发明的一个实施例的数据库服务器和服务服务器。

图6示出根据本发明的一个实施例的图1的一些服务器之间的简化信令流程。

具体实施方式

现在将参照图1-6描述本发明的示范实施例。

图1的系统示意示出包括两个网络域20、30的通信系统100的一些服务器，其中，一些服务服务器（21，22，31，32）已适用于数据分层架构DLA。

在图1的示例中，且为了说明的目的，假设网络域20包括如3GPP规范TS 23.228 V8.8.0（2009年3月；http://www.3gpp.org/ftp/Specs/archive/23_series/23.228/23228-880.zip）中描述的“因特网协议多媒体子系统”IMS，并且假设网络域30包括如GSM规范TS 100.522 V7.1.0（2000年1月；http://www.3gpp.org/ftp/Specs/archive/03_series/03.02/0302-710.zip）中描述的电路交换和分组交换蜂窝系统。两个域能够属于相同或不同运营商，其能通过在共同数据库系统存储库（DBS，11）中存储能够由系统100的服务服务器用于为其用户提供通信服务的其用户的数据而受益于DLA特征。

为了清晰的缘故，在图1的简化图示中未示出包括此类域（20，30）的通信系统中通常存在的另外的服务器及与提供连接到这些服务器的用户的终端的接入网络的细节，这些服务器的一些服务器能够对不同网络域是共同的。

根据图1所示示例，网络域30又包括两个网络（子）域：电路交换CS和分组交换PS域；其中，如技术人员所公知的，一些接入网络元件和服务服务器（例如，HLR）对CS和PS两者是共同的。在域30中，能够假设MSC/VLR 34和35及SGFSN 33是传统的单片服务器（在它们在本地处理（即，在本地存储和访问）某些用户的数据以便使用这些数据向这些用户提供其相应服务的意义上）。例如，除其它之外，MSC/VLR 34向通过它为其终端注册基于电路交换的服务的用户提供用于话音呼叫的呼叫控制服务。SGSN 33又向通过它为其终端注册基于分组交换的服务的某些用户提供分组连接控制服务。如本领域技术人员所公知的，由MSC/VLR 34和SGSN 33在本地保存的关于它们服务的用户的一些数据由对应HRL（例如，HLR 31或HLR 32）来提供。

也能够假设服务服务器CSCF 23和24及AS 25是单片服务器。例如，CSCF 23能够实现“服务”CSCF (S-CSCF)的角色，并且为通过它在IMS域20中注册其终端的用户启动或端接的多媒体会话提供多媒体会话控制服务。AS 25又能够是与CSCF 23和24（例如，如果它们是S-CSCF）协作以便控制可用于多媒体会话（例如，转发进入会话）的一些服务的执行的SIP应用服务器。为实现其相应功能，S-CSCF（例如，23、24）和AS（例如，25）也在本地存储与某些用户有关的数据，这些数据相应地在这些服务器中用于向这些用户提供某些服务。在与上述网络域30的情况中的类似方式中，在IMS网络域20中，CSCF和AS保存的一些数据由（比如说）归属服务器来提供，在IMS的特定情况中，归属服务器称为归属订户服务器HSS（例如，HSS 21或HSS 22）。

要注意的是，虽然HSS在一些3GPP规范中被描述为包含用于电路交换CS服务（例如，基本GSM话音服务）和分组交换PS服务（例如，基本GPRS服务）的HLR功能性和用于IMS服务的对应归属服务器功能性的功能实体，但它们未排除将总功能性划分到不同服务器中以便分别服务于HLR和HSS特定服务，主要是在信令接口和有关服务逻辑能够不同时（例如，用于在HLR、MSC/VLR与SGSN之间通信的MAP协议和用于在IMS域中HSS、CSCF与AS之间通信的DIAMETER协议）。在此方面，一些网络运营商能够发现，有用的是保持他们的（比如说）遗留HLR工作以用于他们的现有电路交换/分组交换蜂窝网络域（例如，GSM、GPRS），同时在他们开发其IMS网络基础设施的时候获得实现HSS ISM特定功能的新服务服务器。这是在本文中为说明目的而考虑的示例。

DLA提供的特征正好适合此情况，因为只要运营商的IMS订户的数量增长，例如只适用于IMS的HSS服务器便能够部署为（比如说）使用诸如DBS 11等共同后端数据存储库的处理前端。类似地，在涉及替换遗留（例如，单片）HLR时，和/或在增大HLR处理容量时，HLR前端服务器（例如，31，32）也能够部署为（比如说）随后能够使用共同的后端数据存储库(DBS 11)的仅轻量级处理机器（即，信令处理前端）。此外，处理前端能够适合服务于多于一个应用服务类型（例如，HLR和HSS应用）。

图1所示示例假设在域30中的HLR服务服务器（31，32）和在域20中的HSS服务服务器（21，22）均适用于DLA，因此，它们不永久性存储它们提供其相应服务需要的用户的数据，而是这些数据转而存储在诸如数据库存储系统DBS 11等后端数据存储库中。为此目的提供服务到系统100的用户的其它服务服务器（如，23、24、25、33、34、35）能够通过一个或多个互连网络和诸如负载平衡器、路由器等由标注INET-1、INET-2示意示出的网络元件，与HSS和HLR服务器（21、22、31、32）进行通信。所示示例也将服务器21、22、31和32考虑为专用服务器，其中，服务器21和22包括用于服务于HSS服务的处理和信令部件，而服务器31和32包括用于服务于HLR服务的处理和信令部件。然而，也能够设想到其中单个服务器布置成服务于两种服务（即，HLR和HSS）的其它情况。

一般而言，用于CS和/或PS服务的HLR服务器和用于仅IMS的HSS服务器是为通信系统的用户提供类似种类的服务的订户数据服务器。即，通过提供指派为服务于用于涉及用户的注册终端的通信的控制的对应服务服务器的标识符（例如，MSC/VLR、S-CSCF等），它们介入这些用户的终端的认证和注册进程，作为用户有关数据（例如，预订简档数据）的主处理机来行动，并且还充当用于端接通信（例如，端接呼叫、端接多媒体会话等）的“位置功能”。

相应地，如果预订网络域20的运营商提供的IMS服务的用户将其终端注册到此域中，则S-CSCF（例如，24）将查询HSS前端（21或22，例如，在负载平衡的基础上）以获得涉及的用户数据（通常称为“服务简档”）。在此进程中，HSS（21或22）将从DBS 11检索对应数据，将处理它们，并且如果结果是积极的（例如，如果允许注册），则将发送必需数据到S-CSCF (24)，以便它能够在本地存储数据并使用它们以用于通过所述终端相应地向所述用户服务另外的服务。同样地，如果预订网络域30的运营商提供的电路交换服务的用户将其终端注册到此域中，则此域的HLR（例如，31或32）将下载与所述用户有关的对应数据到涉及的MSC/VLR（例如，34）中，以便所述MSC/VLR能够基于这些数据，通过所述终端提供其服务到所述用户。

图1还示出配备服务器（PS，12），该配备服务器适用于直接与DBS 11交互以便执行与向系统100预订从IMS域20提供的服务和/或CS/PS域30提供的服务任意之一或两者的用户相关的数据配备任务。配备服务器12能够布置成例如经LDAP与DBS 11进行通信以设置，更改和/或删除与网络域20或30的用户有关的数据。例如，如果用户要求预订系统100的任何域，或者如果已经预订用户的一些数据要被修改（例如，要添加，删除或更改新用户标识符），则配备服务器优选与DBS 11进行通信以请求其中必需的数据修改。

为了说明本发明的实施例的缘故，以上描述假设用户预订有网络域30中服务服务器提供的基于蜂窝话音（电路交换CS）和/或数据分组（分组交换PS）的服务和网络域20中服务服务器提供的IP多媒体服务IMS的情况。

图2示意示出与预订例如通过网络域30和20提供的CS和IMS服务的用户有关的数据的逻辑树结构的示例。如更早所述，这些数据的对应（比如说）主副本存储在DBS 11中，如图2所示，副本能够布置成根据逻辑树命名/寻址方案存储和涉及目录条目与对应数据属性（即，数据属性的名称/描述和对应数据值）的LDAP目录，以及其中协作服务服务器（例如，12，21，22，31，32）发送消息到DBS，请求修改其中存储的数据的根据LDAP协议的数据操作。IETF RFC 4512“LDAP Directory Information Models”（例如，第2.2章）提供了有关用于LDAP的数据条目和对应数据属性的描述。修改适用于LDAP的DBS保存的数据的数据操作的示例有：LDAP“修改操作”、LDAP“添加操作”或LDAP“删除操作”。例如，与某个用户有关的数据(SUBS)能够指派到逻辑数据结构（映射到DBS 11中的目录条目，带有其对应属性），其包括：与CS域有关的数据(CS-DAT)、与IMS域有关的数据(IMS-DAT)及未明确与特定网络域有关和/或共同用于两个域的一些另外的数据(COM-DAT)，如计费或服务质量策略数据、漫游限制、地理定位信息等（CD-1，CD-2...，CD-N）。

例如，CS域的服务服务器使用的某个用户的数据(CS-DAT)除其它之外，能够包括在CS域中可使用的用户的一个或多个标识符（ID-CS-X，ID-CS-Y），如移动订户IDSN号MSISDN或国际移动订户身份IMSI。关于与例如CS域提供的补充服务有关，可由在所述域上的服务服务器使用的数据（CS-SRV#1，CS-SRV#2...，CS-SRV#N，CS-SRV#M），所述用户的数据例如能够包括呼叫转发信息（例如，包括激活状态，并且如果继续，则转发到目的地标识符）。

如果已预订，则除其它之外，与IMS有关的所述用户的数据(IMS-DAT)又能够包括指派到所述用户并可由IMS域的服务服务器使用的一个或多个用户标识符（ID-IMS-X，ID-IMS-Y），如采用NAI（网络接入标识符）形式的一个或多个私有用户标识符、采用SIP-URI（会话启动协议-统一资源标识符）形式的一个或多个公共用户标识符。关于与IMS域提供的服务有关，可由在所述域上的服务器使用的数据，所述用户的数据例如能够包括如3GPP规范29.228 V8.5.0（2009年3月）定义的所谓初始过滤器准则IFC，除其它之外，该准则用于确定是否要向某个目的地转发对于所述用户的进入SIP会话。

与CS域有关的用户的数据(CS-DAT)及与IMS域有关的数据也能够包括图2上为了简明而未示出的另外数据。例如，在某一时刻被指派为服务于所述用户并且为所述目的而在本地（CS或IMS）处理所述用户的数据的服务服务器的标识符；如MSC/VLR和/或S-CSCF标识符。

图2以简化方式示出的公知逻辑结构能够进一步增强以实现本发明的一有利实施例，例如，如201所示，通过在DBS 11内链接属于第一域（例如，CS）的某些数据与属于第二域（例如，IMS）的某些数据。优选的是，链接的数据分别属于具有类似功能性的两个域上的服务。例如，如果CS-SRV#M在用户的逻辑目录树(SUBS)上表示与呼叫转发服务有关的信息，则链接201能够有利地在DBS 11中与管控IMS服务的所述用户的“初始过滤器准则”IFC数据来确立，该链接在激活时，将在某些条件下（即，根据IFC内容来确定）向端接方转发寻址到所述用户的标识符的进入SIP会话，如IMS-SRV#N。类似地，链接的(102)数据（CS-SRV#M和IMS-SRV#N）能够分别表示与用于禁止在CS域中注册的用户终端的进入呼叫和禁止为在IMS域中所述用户注册的终端的进入SIP会话的服务的激活/去活状态有关的数据。

通常，在不同网络域中用户的服务有关数据在格式和内容上不同，其分别适用于在不同域上的服务服务器。使用转发有关GSM网络的CS域的话音呼叫和有关IMS的SIP会话为例，这些数据的格式能够大不相同。例如，在CS域中，有关CS-SRV#M的单个比特能够存储有关是否（是/否）激活呼叫转发服务的信息，并且例如字母数字阵列能够存储（如果激活）MSISDN目的地。在IMS域中，IFC的结构又能够包括：用于分析进入SIP“邀请”消息的内容的数据、为进一步处理而将所述消息转发到的应用服务器AS的标识符等。一般而言，关于分别与第一和第二域有关（并可由其使用）的用户的数据的格式的差别例如能够包括用于这些数据的不同编码格式，如为与第一网络域有关的数据使用基于ASN-1的编码，并且为第二网络域使用基于XML的编码。

链接201能够用于确定在DBS 11上对例如数据条目和/或存储用户的某些数据（例如，CS-SRV#M）的数据条目上的属性所做的修改是否对所述用户的其它数据（例如，IMS-SRV#N）有影响。具体而言，与第一网络域有关的用户的第一数据(CS-SRV#M)和与第二网络域有关的所述用户的第二数据(IMS-SRV#N)之间链接201的存在能够用于确定在对第一数据进行或请求修改时要对第二数据进行的修改，且反之亦然，以及在必需时执行对应的格式转换。

这些有用的特征能够减轻最终用户不得不请求激活或去活在不同网络域上的类似服务。例如，如果用户不想受任何进入通信（例如，GSM话音和IMS SIP会话）干扰并且想将它们全部禁止，和/或如果他想将所有其经GSM和IMS的进入通信转移到其办公室电话，或者想去活任何这些服务，则目前要求他在两个域前分别运行激活/去活过程。

在此类情况下，本发明向用户提供仅在涉及的网络域之一前运行激活/去活过程的解决方案，只要链接201和本文中所述对应功能性在DBS 11中为对应数据确立，这便将足以在所有涉及域中的必需数据。类似地，如果与这些服务有关的数据或其它数据要通过配备（例如，经配备服务器12）来设置，则此实施例允许简化进程，因为在遵循上面的示例后，配备服务器12将只需要发送消息到DBS 11，请求只修改与网络域之一有关的数据（例如，修改CS-SRV#M），其中，对应的有关数据（例如，IMS-SRV#N）将随后被修改而无需配备服务器12到DBS 11的任何另外的明确请求。后面将公开此转换特征的另外细节。

现在将参照图3到图5描述本发明的另外细节和实施例；其中，图3示出根据本发明的实施例的方法，并且图4和图5示意分别示出根据本发明的一个实施例的数据库服务器DBS 11和服务服务器（例如，HSS 21）的一些功能结构元件。如技术人员鉴于以上描述将明白的，参照图4或5所述的功能元件能够借助于专门适用于执行所述功能性的软件和/或硬件来实现。例如，本文中涉及的任何服务器（例如，11，21）能够在由包括计算机可读指令的计算机程序驱动的基于计算机的设备中实现，所述指令在其中加载和执行时，使得此类机器如这些指令指定和管控的一样，根据特定功能性来行动，并且产生技术结果（在其内部或外部之一或两者）。鉴于本描述，技术人员将只面临设计计算机程序产品的日常工作，计算机程序产品在加载到一个或多个基于计算机的设备中时，能够使得它们根据本文中所述任何实施例来行动。如所公知的，典型的基于计算机的设备至少包括处理器，并可访问存储适合由处理器执行的指令的存储器。

虽然关于方法步骤的本发明的实施例通过单个图形（图3）示出，但要注意，这些实施例包括分别由数据库服务器DBS (11)和由一个或多个服务服务器（21，22，31，32）执行的不同但协作的方法。虽然这将从前面的描述中明白，但这些（协作）方法的一些步骤的简短概述在下面描述。

除后面详细介绍的其它步骤外，数据库服务器DBS (11)中的方法包括：

-接收请求数据操作以修改与用户有关的数据的第一消息，

-根据接收的请求来修改与用户有关的第一数据，以及

-发送通知数据修改的第二消息到第一服务服务器(21)，该消息包括：用户的标识符、与修改步骤后第一数据有关的信息及在处理与用户有关的数据以便向所述用户提供服务的所述多个服务服务器中第二服务服务器(23)的标识符。

除后面详细描述的其它步骤外，服务服务器（例如，21）中的方法包括：

-从数据库服务器(11)接收通知与用户有关的第一数据的数据修改的第一消息，该消息包括：用户的标识符、与数据库服务器(11)上在修改步骤后第一数据有关的信息及处理与用户有关数据的系统的第二服务服务器（例如，23、24、25、33、34或35）的标识符，以及 

-在接收第一消息后，发送第二消息到第二服务服务器，第二消息包括用户的标识符并请求修改其中与所述用户相关保存的数据。

回到图3，在步骤1101中，DBS 11接收请求修改与某个用户有关的数据的第一消息。为了说明的缘故，能够假设消息来自配备服务器12。步骤1101的第一消息能够是例如用户经HTTP或WAP从其终端请求有关任何其简档数据的更改的结果，如激活，去活或修改给定补充服务，其中，此类请求自动到达配备服务器12（例如，由web门户重定向或代理），并且其中，服务器12可作为配备网关来行动。步骤1101的第一消息也能够是例如操作人员将配备或数据管理信息输入配备服务器12的结果。

在步骤1101中接收的消息例如能够包括添加新数据的请求（例如，LDAP“添加操作”）、删除新数据的请求（例如，LDAP“删除操作”）或修改一些数据的请求（例如，LDAP“修改操作”）。在本文中要注意的是，LDAP用作一示范实施例，并且在此描述中“修改”的含意不限于如在LDAP术语中“修改”的特定意义（即，只与LDAP“修改操作”有关）。相反，与本申请一起使用的“修改”术语除非另有规定，否则涉及：更改，添加或删除一些数据，在LDAP适用的DBS的特定情况下，这能够涉及存储用户的数据的条目（例如，图2中所示的任何元素）及在受影响条目内存储的任何属性。

为了接收外部消息（如在步骤1101中接收的消息），DBS 11包括适用于例如通过因特网协议TCP/IP通信基础设施，通过传送控制协议，使用LDAP协议从其它服务器（例如，12，21，22，31，32）接收通信的接收器单元41。在步骤1101中接收的消息包括用于DBS 11的必需数据，以便识别要修改的数据并使DBS可能实现要求的修改。例如，如果使用LDAP，则它包括可用于在DBS 11中确定涉及的用户以及被请求修改的所述用户的涉及数据（例如，CS-SRV#M）的标识符（例如，LDAPDN）。

随后，在步骤1103中，在DBS 11中的数据存储处理单元44从接收器单元41接收必需的信息，并且根据接收的请求在数据存储单元42中修改与涉及的用户有关的第一数据（步骤1101）。数据库管理服务器DBS 11的数据存储单元42能够包括不同存储装置，包括位于相同物理机器内或沿分离的数据库机器分布的盘和/或存储器芯片。

随后，进程能够通过从DBS 11向第一服务服务器（例如，21、22、31、32的任何服务器）发送第二消息(M2)（作为步骤1101和1103的结果）而继续，该消息通知数据修改并且包括：受步骤1101上接收的第一消息影响的用户的标识符和与修改步骤后第一数据有关的信息。与修改步骤后第一数据有关的信息优选包括根据接收服务服务器（21，22，31，32）能够理解以有利于其进一步处理的格式的第一数据的类型和更新的内容。第二消息的发送在图3中由步骤1109示出。

为发送第二消息（步骤1109），DBS 11包括发送单元43，发送单元例如能够与接收器单元41共享一些硬件和/或软件通信资源，如TCP/IP协议栈和/或物理连接线路，并且能够根据简单对象访问协议SOAP通过此通信基础设施操作以实现发送第二消息的目的（步骤1109）。此外，发送单元43能够适合也根据LDAP协议操作，例如，以根据LDAP回复步骤1101中接收的消息。

有利的是，第二消息还能够包括第一消息的处理不一定修改（步骤1103）但能够由DBS 11与修改的数据相关存储的一些另外数据，如处理与受影响用户有关的数据的系统的第二服务服务器的标识符（例如，23、24、25、33、34或35的标识符）及由DBS 11保存的与受影响用户（即，其数据在步骤1103上修改的用户）相关存储的其它数据。为实现此最新特征，DBS 11优选包括能够适用于访问数据存储装置42以便选择与受修改影响的用户有关的一些另外数据（图2，SUBS）的数据选择单元(45)。优选的是，一些种类的逻辑链接或类似机制在DBS 11中存储的用户的某些数据之间确立(SUBS)（图2中未示出的链接），这些链接可由数据选择单元45用于选择与进行了修改（步骤1101）的相同用户数据有关的哪些另外数据能够被包括在第二消息1109内。

在第二消息(1109)中引入处理与受修改影响的用户有关的数据的系统的第二服务服务器的标识符是本发明的一个特征，该特征有助于在DBS 11存储的用户的数据与能够沿多个服务服务器（例如，23、24、25、33、34、35）分散的这些数据的一些数据的临时副本之间提供数据一致性，并同时有助于通过在DBS 11中引入一些更改，减少用于执行此类同步的必需信令，这只要求查找和使用它保存的与修改的数据（步骤1101）相关的一些数据。

例如，在用户注册到IMS域20中时，此域的HSS应保存指派为服务于此类注册的S-CSCF的标识符。类似地，在用户注册到GSM系统的CS域（例如，30）中时，此域的HLR应保存指派为服务于此类注册的MSC/VLR的标识符。在诸如系统100等布置到DLA的系统中，这些服务服务器（即，指派的S-CSCF和指派的MSC/VLR）的标识符由对应服务器（例如，21、22、31、32）在后端存储DBS 11中存储为属于逻辑树（如图2所示）的对应“叶”的数据。例如，指派为服务于用于某个用户的CS注册的CS服务的服务MSC/VLR的标识符将属于所述用户的CS-DAT（图2中未示出的元素），并且指派为服务于用于某个用户的IMS注册的IMS服务的服务S-CSCF的标识符将属于所述用户的IMS-DAT（图2中未示出的特定元素）。

然而，根据本发明的一个实施例，如图3所示的进程继续到步骤1105，在该步骤中，根据后面将详细介绍的一些特定准则，先确定是否发送第二消息（M2，步骤1109），并且如果继续，随后在步骤1107上确定所述第二消息的目的地和/或有关所述消息的一些附加内容。为实现这些目的，DBS优选包括：用于根据第一数据、或根据第一消息的发送器和第一服务服务器是否相同或是否具有相同类型来确定是否发送第二消息的消息发送确定单元(48)。例如，消息发送确定单元48能够在步骤1105上检查与某些用户数据(SUBS)相关联的某一标志，以确定根据接收的请求(1101)所修改（或要进行修改）的数据是否要进行随后的通知（步骤1109），因此节省不必要的另外信令。

根据本发明的一个实施例，DBS 11还包括适用于根据在步骤1103上修改的数据，选择将步骤1109的消息通知发送到的服务服务器（例如，21，22，31或32）的服务器选择单元46。例如，图2所示的任何用户数据(SUBS)能够链接到（或包括）有关服务器（例如，21，22，31或32）的某些标识符，这些标识符能够由单元46用于在DBS 11中确定步骤1109上发送的数据修改通知的接收器。

视备选实现细节而定，服务器选择单元46能够通过使用在DBS 11中与其中存储的数据相关的某一附加信息，与数据选择单元45，并且甚至与发送器确定单元48协同工作，这有利于其相应的功能。例如，DBS中的附加的表能够保存以下信息之间的关系：

- [a]有关其中存储的某些数据的信息（例如，在LDAP中，这能够指某个对象和/或指对象的某个属性）；

- [b]有关所述数据涉及的应用的信息，其能够用于选择步骤1109的消息的服务服务器目的地；以及

- [c]有关与所述数据有关的一些另外数据的信息，其可能被需要用于以下之一或两者：在DBS中确定是否发送消息（步骤1109）和/或是否确定要在所述消息中包括在目的地服务服务器上第二消息的进一步处理可能需要的另外的有关数据(D2)。

随后，该表能够包括用于DBS保存的每个或一些数据的多个条目“a”、“b”和“c”。仅为DBS中存储的一些数据存储条目“a”、“b”和“c”的优点在于，用于某些数据的条目“a”的简单存在/不存在能够用于在步骤1105上确定（例如，由发送器确定单元48）是否必须在步骤1109上在随后的消息中通知所述某些数据上的修改，并因此有助于以简化的方式减少信令。

以图1所示系统情形100为例，条目能够包括：

-在“a”下能够在DBS中与用户相关存储的某些数据的信息（例如，数据的所述类型的标识符），如有关某个补充服务的信息；

-在“b”下有关数据是与HLR服务应用还是HSS服务器应用有关的信息，及甚至可用于将消息（例如，步骤1109的消息）路由到对应服务服务器（例如，在HSS应用情况下的服务服务器21或22或在HLR应用情况下的服务服务器31或32）的标识符。具体而言，在“b”下的信息能够由服务选择单元46用于确定步骤1109的消息的第一服务服务器（21，22，31或32）目的地；以及 

-在“c”下，有关必须具有其数据受步骤1103的修改影响的用户的注册状态条件的信息，和/或有关与所述用户有关并且在DBS中与用户相关存储的一些附加数据（例如，数据的所述类型的标识符）的信息，其在修改“a”下的数据的情况下需要被发送。因此，在“c”条目下引用的与某个“a”条目有关的数据能够在步骤1107的另外数据(D2)选择上被使用，以及用于确定是否发送步骤1109的通知消息的条件。

例如，在图1所示情形中，在“c”上确立的与如“a”确立的某些数据相关的“注册状态”（例如，是否“已注册”或“未注册”）以简单的方式提供了减少信令的优点，因为是否发送步骤1109的通知消息能够根据例如用户的注册状态进行。例如，如果在CS网络域30中用户的注册状态（也在DBS中存储的数据）是“已注册”，则优选只向对应服务服务器（即，HLR）通知对于所述用户的电路交换CS话音呼叫的呼叫转发激活状态的修改。因此，该表能够包括一个条目，其中，“a”识别数据类型，如用于CS话音呼叫的呼叫转发激活状态，其中，对应的“b”数据存储用于寻址HLR（31，32）的信息，以及其中，“c”指明涉及的用户的注册状态必须为“已注册”。此外，能够有一个条目，其中，“a”全局识别在适用于存储与例如网络域30有关的所有补充服务信息的DBS上的对象类型，以及其中，为用户进行的全部或部分修改（步骤1103）的通知（步骤1109）因此由“c”下与所述“a”有关的信息来调节。

回到图3所示的方法，步骤1107也能够包括选择未受步骤1101上请求的修改影响的一些另外数据(D2)。在此方面，数据选择单元45适用于选择与受修改（步骤1103）影响的用户相关存储的另外数据，这些数据未受所述修改影响。如上所述，这能够通过使数据选择单元45检查元素“a”、“b”和“c”的上述表上的对应条目（具体而言，修改的数据“a”的类型相对能够在“c”上确立的另外数据D2）而以简化的方式来实现。

备选的是，有关修改的数据的类型“a”的信息能够以其它方式在逻辑上被链接（例如，对另外表的引用），以便在步骤1107上，例如数据选择单元45检查要在步骤1109上发送的数据修改通知中发送可与用户的修改的数据类型（“a”）相关存储的哪些另外数据。

如前面所提及的，在步骤1109上向某个选定第一服务服务器发送的消息优选包括：

- [1]与其数据进行了步骤1103的修改的用户相关联存储的一个或多个标识符；

- [2]与进行了步骤1103的修改的数据有关的信息；以及

能够由DBS在如图1所示系统中与用户相关存储的标识符的类型（上述元素“1”）的示例有：MSISDN、IMSI、SIP-URI等。元素“2”优选包括涉及的修改的数据元素的类型信息和内容（如步骤1103上所修改的）。

优选并且如也在更早所提及的，在步骤1109向某个选定第一服务服务器发送的消息还包括以下的至少之一：

- [3]与进行修改步骤1103前第一数据有关的信息（如上所述，它能够包括类型和属性内容，但有关类型的信息如果它不是修改的主体则能够是多余的）；

- [4]有关在步骤1101的请求中接收的数据操作的类型的信息，请求造成在步骤1103中的数据修改（例如，请求的LDAP操作的类型）；以及 

- [5]与另外的（第二）数据(D2)有关的信息，所述另外的数据在DBS中与其（第一）数据在步骤1103上被修改的用户相关存储，并且未受所述修改步骤影响。

在元素“5”下的信息优选包括第二服务服务器的标识符，该标识符能够由第一服务服务器（即，在步骤1109上发送的消息的接收器）用于与它进行进一步通信。如更早所述，优选的是第二服务服务器是当前处理所述用户的数据以便向所述用户提供服务的服务器。使用图1所示示例，第二服务服务器例如能够是MSC/VLR 34（用于服务于在移动网络CS域上的话音服务）或S-CSCF 24（用于服务于在IMS域中的多媒体服务）。例如，在用户从终端注册到电信系统(100)中时，HLR或HSS存储（在DLA架构的情况中，在DBS中）有关提供通信控制服务到此用户的对应（第二）服务服务器的信息，此用户也由HLR或HSS提供了所述用户的必需数据的副本（主副本在DBS中存储）。下表列出在DBS 11上保存的包括有关第二服务服务器的信息（注为位置信息）的配置表的示例，该表能够用于确定在修改通知消息(1109)中在此方面要发送的信息。

应用	网络接口	位置信息	位置成分
				HLR	C	CS位置，VLR	目的地地址、区域漫游标志、CAMEL支持标志、GPRS支持标志、服务支持标志（ECT、LCS等）
HLR	D	PS位置，SGSN	目的地地址、CAMEL支持标志、GPRS支持标志、服务支持标志（ECT、LCS等）
				HSS	Cx	IMS核心网络位置，S-CSCF	目的地地址
HSS	Wx	WLAN位置，3GPP AAA服务器	目的地地址
				HSS	Sh	IMS应用服务器位置	目的地地址

在元素“5”下的可用于确定要在步骤1109的通知消息上发送的另外内容的信息也能够包括引用一些其它的另外数据(D2)，这些数据未受修改步骤1103影响，并且其（如上参照“第二服务服务器”所提及的）能够在步骤1109的消息上被发送，它能够有利地由消息的接收器（第一服务服务器，例如，HLR 31）用于适当处理数据修改，而无需向DBS 11进行进一步查询以获得根据第一服务服务于的特定应用逻辑而可能需要的附加信息。例如，如果在DBS中存储，与用户有关的数据已进行关于例如呼叫/会话转发信息、进入呼叫/会话的禁止等的修改；则除为服务对于所述用户的通信服务当前指派的（第二）服务器（例如，23、24、25、33、34、35的任何服务器）的标识符外，可能有用的是接收步骤1109的消息的第一服务服务器（例如，21、22、31、32的任何服务器）接收处理修改和/或进一步向第二服务服务器发送可能需要的另外数据。所述另外数据(D2)的示例能够是：在相同或不同网络域（20，30）中用户的某个标识符、关于服务禁止的共用信息、与所述用户有关的另外标识符（例如“通配公共用户或服务标识符”）、“移动增强逻辑的定制应用”CAMEL信息、有关和与修改的数据有关的网络域不同的网络域上另外的第二服务服务器的信息（例如，如果修改的数据属于域30，则在域20上的CSCF的标识符或反之亦然）、有关涉及的用户为已注册终端利用的接入网络的特定位置信息（例如，无线局域网WLAN标识符或其它种类的接入网络标识符）等。

根据本发明的实施例，这得以实现而无未增大DBS的复杂性和使用在大多数数据库系统中可用的一些基本数据链接特征，因为如更早所提及的，在一些数据之间根据任何适合的数据链接/映射解决方案设置，预存储在其中的简单链接解决了以简单的方式确定在通知有关某些第一数据的修改的消息中要包括哪些另外的第二有关数据的问题；这不要求DBS（比如说）根据数据有关的应用服务而知道数据的特定含意。另外，由于服务服务器的逻辑中的修改及这些服务器服务的新应用的添加造成的影响在后端存储系统(DBS 11)上被降到最低，因为这些修改和/或添加不要求（比如说）将特定服务逻辑导出到DBS，而只是更改和/或确立其中保存的数据之间的逻辑链接和/或简单地修改这些数据。

虽然前面未明确提及，但DBS 11（例如，通过进一步使发送器确定单元48或发送器单元43适用）能够适用于在相当的接收器之间分布修改通知消息（例如，步骤1109以及还有将在后面描述的步骤1115）。例如，DBS能够适合实现任何适合的负载分布机制（例如，基于循环逻辑、加权分布逻辑和/或目的地可用性逻辑）将消息分布到相当的第一服务服务器。因此，要在步骤1109（或1115）上发送的消息如果与HSS应用有关，则能够根据分布逻辑输送到可用HSS（例如，根据图1的21或22）。例如，服务器选择单元46能够检查具有用于每个应用（例如，HLR和HSS应用）的条目的表，其中，每个应用条目指派有分布组，所述分布组由诸如URL或IP地址等标识符的列表和配置到对应目的地的选择所需的附加信息组成，在有多于一个对应的相当服务服务器（例如，21、22、31、32）的情况下，所述附加信息例如能够包括优先级选择信息。

接着，作为本发明的一示范实施例，描述了用于在DBS 11与第一服务服务器（例如，21、22、31、32的任何服务器）之间传递数据修改的一些细节。提议的协议在本文中称为“网络通知指示协议”NNI，并且能够例如基于使用用于消息内容的扩展标记语言(XML)定义的SOAP。

提议的协议能够包括2个消息：从网络通知客户端（即，DBS 11）到服务器方向（即，诸如服务器21等第一服务服务器）的请求，如在步骤1109或1115所示；以及在服务器到客户端方向的确认消息（图中未示出）。它们在本文中分别称为网络通知指示请求(NNIR)和确认(NNIA)消息。

网络通知指示请求(NNIR)消息的可能格式在下面根据只考虑一些特定附加数据(D2)的一实施例，以伪形式语言（例如，符合XML）来描述：

上述元素的详细描述如下：

NNIR - 如图所示，它是表示需要由网络的服务服务器进一步处理和/或更新的用户有关信息（即，有关其一些数据进行了修改的用户）的结构。它由NNIComponent元素的序列合成。

每个NNIComponent（如图所示）又由Applicationlnformation元素、Locationlnformation元素、Userlnformation元素及Modificationlnformation元素的序列合成。这些元素将在下面描述。

Applicationlnformation元素 - 表示其修改触发了通知消息的数据的应用所有者的结构。在如图2所示的情形中，应用属性的可能值是HLR和HSS（例如，在相同的第一服务服务器 - 即此消息的接收器 - 服务于两种应用的情况下可用） 和/或特定第一服务服务器的标识符（即，NNIR消息的目的地 - 步骤1109/1115 - 本身）。

Locationlnformation元素 - 表示服务于与其修改触发了通知事件（即，NNRI消息，步骤1109）的订户有关的位置信息的结构。它包括位置元素的序列，位置元素又包括可选ServiceFlag元素的序列和两个属性。在下面的两个表中，描述元素“Locationlnformation”的子元素和合成属性。

位置属性	类型	描述
			typeOfLocation	Enumerated	CS、PS、IMS等。
destinationAddress	OctectString	它包括对应第二服务服务器的地址，例如，MSC/VLR、SGSN、CSCF、AS、3GPP AAA服务器等的地址。

 

ServiceFlag属性	类型	描述
			typeOfFlag	Enumerated	它能够采取值GPRSSupport、CAMELSupport、AreaRoamingSupport、ECTSupport、LCSSupport等。
flags	octectString	它包含标志值信息

Userlnformation元素 - 根据其修改触发了通知事件（即，NNRI消息，步骤1109）的受影响应用而表示用户标识符的结构。它包括Userldentifier元素的序列。在下面表中，描述了合成属性。

UserIdentifier属性	类型	描述
			typeOfldentifier	Enumerated	它能够采取例如MSISDN、IMSI、采用SIP-URI、NAI等形式的公共用户标识符的值。
identifier	octectString	它存储用户标识符。

Modificationlnformation元素 - 它是表示其修改触发了通知事件（即，NNRI消息，步骤1109）的数据对象的结构。根据此示例，它包括：可选“AffectedAttribute”元素（后面描述）的序列和两个属性。元素“Modificationlnformation”的一些属性在下面的表中示出。

AffectedAttribute元素又能够包括识别其修改触发了步骤1109的NNIR通知的属性（例如，如步骤1101的LDAP操作所识别的）。它由能够是可选的两个另外元素和两个属性合成。下面的表表示上述关于元素“AffectedAttribute”的属性。

AffectedAttribute属性	类型	描述
			name	String	它包括修改的数据属性的标识符
modification	Enumerated	它识别在属性上所做的修改的类型。它能够例如采取添加，修改或删除的值。

 

AffectedAttribute元素	类型	描述
			oldValue	String	它包括在修改发生前的数据属性值。它在执行例如LDAP修改或LDAP删除操作时应用。
newValue	String	它包括在修改发生后的属性值。

下面示意描述用于如从第一服务服务器发送到DBS 11的作为步骤1109（或1115）上发送的NNIR消息的回复的“网络通知指示确认”(NNIA)消息的可能格式：

NNIA - 如图所示，它是表示作为回复，从接收数据通知消息（NNIR消息，步骤1109）的服务服务器发送的网络通知指示请求消息的结果的结构。它包括两个元素ResultCode和Diagnostic，如下面的表中公开的。

NNIA元素	类型	要求	描述
				ResultCode	String	强制	它包括NNIR执行的成功或不成功结果。此信息例如在故障情况下能够由DBS 11进一步使用。
Diagnostic	String	可选	它是包括与数据修改通知(NNIR)的结果有关的信息的可选信息元素，能够由DBS 11进一步用于例如在故障情况下撤销一些动作，和/或由网络运营商用于另外的目的。

根据本发明的一些实施例的方法的详细描述现在将继续参照在第一服务服务器（例如，21、22、31或32的任何服务器）上在步骤1109上由DBS发送及在其中接收的消息的处理。所述处理在图3中由步骤2101到2105示出。

为了接收外部消息，第一服务服务器（如图5所示服务器21）包括适用于从诸如DBS 11等其它服务器接收通信的接收器单元51。具体而言，为在步骤1109（或步骤1115）上从DBS 11接收通信（在本文中也称为“第二消息”M2），接收器单元51能够适用于根据除其它之外在TCP/IP通信基础设施上经SOA协议接收消息，这要求在其中实现必需的（公知的）协议栈。

此外，在从DBS接收通知数据修改的通信（第二消息，1109）后，为发送另外消息（在本文中也称为“第三消息”M3，在后面解释的步骤2105），服务器21还包括发送单元52，该单元例如能够与接收器单元51共享一些硬件和/或软件通信资源，如一些协议栈和/或物理连接线路。具体而言，除与另外的（第二）服务服务器（例如，23、24、25）通信所要求的协议外，如DIAMETER（或MAP，如果第一服务服务器21是HLR），发送器单元52能够也适合在确认消息（如更早所述NNIA）实现时经SOAP例如与DBS进行通信，并且也经LDAP进行通信以便在DBS上在执行其自己的应用服务逻辑时由于其正常操作而修改（例如，更新，删除，设置）数据。

服务服务器21也能够包括用于确定是否发送另外消息（在本文中也称为“第三消息”，后面解释的步骤2105）的发送确定单元(54)和用于为所述另外消息选择适当的通信协议的协议选择器。为实现其相应功能，发送确定单元54及协议选择单元例如能够使用如更早参照DBS 11的实施例（图4）所述的本地链接的数据（例如，表），并基于它们协同工作。作为说明性示例，服务服务器21能够具有列出包括以下的条目的表：

-能够从DBS修改的数据的识别的类型；

-能够从DBS通知所述数据的操作的类型；

-有关在从DBS接收修改通知时是否要发送（例如，是/否）另外消息的信息（例如，在每数据类型和/或操作上）。这可包括除修改的数据的类型外，也将在来自DBS的通知中接收的另外数据考虑在内；以及 

-有关要用于发送所述另外消息的协议的类型（例如，向诸如33、34、35等服务器的MAP；或向服务器23、24、25的DIAMETER）的信息（例如，在每数据类型和/或操作上）。

例如，如果修改通知消息（步骤1109）指示与某个订户有关的对象数据已被新近创建（例如，带有用于新用户的必需数据属性的新订户条目 -SUBS-已在接收例如LDAP“添加操作”后在DBS中创建），则一般情况下不必从服务器21向任何其它服务服务器（例如，MSC/VLR、SGSN、CSCF等）发送任何另外消息，因为用户可能尚未通过也任何其它服务服务器注册，也未由任何其它服务服务器服务。另一方面，例如如果修改通知消息涉及与某个补充服务（例如，IMS-SRV#2）有关的某些数据属性，并且用户当前已注册，则随后的另外消息将从服务器21发送到任何其它服务服务器（如通知修改消息中所指示的）。不过，如果DBS已经配置了有关为发送步骤1109的消息而考虑或不考虑什么数据修改的信息，则上述“有关是否要发送另外消息的信息”（是/否）可能是不必要的。

如图3所示，通过在步骤2101上选择用于向对应第二服务服务器（例如，23、24、25、33、34或35的任何服务器）发送另外消息(M3)的协议，并且通过在步骤2103上确定是否发送此类消息，该方法在服务器21、22、31或32的任何服务器（如它对应的）中继续。要注意的是，步骤2101和2103能够与如图所示相反的顺序执行。接着，在步骤2105上，如果继续，则发送另外消息M3。在步骤2105上发送的消息M3包括修改另外的服务服务器（例如，23、24、25、33、34或35的任何服务器）上存储的至少相当数据（如在步骤2101上它们被通知为修改一样）的请求。

如果另外的消息(M3)要在步骤2105上被发送，则服务服务器（例如，21、22、31、32）能够包含用于使在消息M3中要发送的数据的格式适用于根据对应协议的适当格式的数据转换单元(53)。例如，如从DBS通知的例如呼叫转发状态的修改的内容可能需要适用于例如MAP协议指定的格式，以便向MSC/VLR发送操作“插入订户数据”（作为M3）。类似地，如果经DIAMETER协议向应用服务器25传送(M3)，则接收的修改通知消息(M2)上的一些数据可能需要适用于适合DIAMETER“推送简档请求”PPR格式的内容（即，所谓的“属性值对”AVP）。

如后面将提及的，数据转换单元53也能够适用于执行其它功能，如将已被通知为已修改（即在服务器21中在步骤1109发送的数据修改通知消息的处理），并且属于第一网络域（例如，20）的给定数据的类型格式和内容转换为适合在第二网络域（例如，30）中使用的类型格式和内容。在此情况下，数据发送器单元52也能够适用于从数据转换单元53接收数据转换结果（例如，由于接收步骤1109的数据修改通知消息），以便将另外消息发送到DBS 11，请求修改关于某个用户（即，与受步骤1101和1103影响的用户相同）的数据的数据操作和包括转换的数据（图3中未示出的步骤）。随后，DBS 11能够为涉及的用户执行随后的步骤1103。优选的是，在此情况下，第二服务服务器（例如，21）发送的请求包括向DBS指示在1103后的步骤无需由DBS执行的一种标志。

图3中也示出的根据本发明的附加实施例的方法能够进一步继续以提供附加的有利特征，这些特征也能够有助于减少包括中央数据库存储系统DBS的系统的信令并因此改进其性能，并且特别是减少了根据数据分层架构DLA所布置的系统的信令并利用其内在益处。

在DBS存储与第一和第二网络域（20，30）有关的用户的数据的情况下，图3所示从步骤1111到步骤3105的方法步骤包括：将第一域上与用户有关的修改的第一数据（例如，在步骤1103上修改）转换（步骤1111）为根据第二域（D1，D1C）的格式，在DBS中将转换的修改的第一数据(D1C)与所述用户的其它数据相关存储（图3中未明确示出的步骤），以及发送（步骤1115）另外的数据修改通知消息(M2C)到对应第二服务服务器。

各种优点由于此特征而得以提供。例如，需要一个单后端存储系统DBS，其中，与不同域有关的数据（即极可能具有关于格式和内容的不同类型）能够有利地在逻辑上分离存储，但其中，它们中的一些数据能够在修改时同步（根据数据内容转换的类型和格式）。另外，与系统100的服务器进行的用户交互能够得以简化并要求更少信令，所述用户交互是为了例如设置、删除或更改与诸如进入服务转发（例如，用于进入数据或话音呼叫，或者用于进入IMS多媒体会话），或者进入服务暂时禁止等某个服务有关的某些数据。在涉及配备时，能够获得类似的优点。例如，在配备服务器12修改（例如，根据最终用户请求，或者根据网络运营商策略）与用户有关的某些数据，例如，影响上述进入服务转发或禁止服务。

图3所示的步骤考虑特定的现实（步骤1111到1115），其中，转换功能由DBS 11执行，并且随后，这些数据修改（由于转换）在消息(M2C)中通知对应第一服务服务器（步骤1115）以便在其中的其进一步处理。这由步骤3101到3105示出，这些步骤在功能上相当于关于消息M2的前面所述步骤2101到2105。然而，也能够设想转换在另外的服务器中执行。例如，转换由例如服务器21执行为与数据修改通知消息M2的接收有关的一个更多的进程（图3中未示出）；这随后应是向DBS 11的修改数据的随后的请求（图3中同样未示出的步骤）。为此目的，诸如服务器21等服务服务器能够包括也适用于例如更改与IMS域(20)有关的某些数据的格式/内容为在CS或PS域(30)上相当数据的格式/内容或反之亦然的数据转换单元53。

在步骤1111，DBS 11执行将在步骤1103 (D1)上修改的属于第一网络域的数据转换为根据第二域(DIC)的格式的进程，并将转换的结果与相同涉及用户的(SUBS)的对应数据条目属性相关存储。例如，为了说明目的使用图2，如果在“CS-SRV#M”下的数据已在步骤1103上被修改，则除修改数据格式/内容外，步骤1111能够还包括在认为相当的例如“IMS-SRV#N”上存储修改结果数据。此相当不要求（比如说）在DBS 11中实现给定网络域上某些数据的服务逻辑，因此增大其复杂性。相反，确立简单的逻辑链接（如201所示）能够足以实现以下目的：确定是否需要数据转换，其中，在数据结构(SUBS)中是其对应物，以及某些数据的内容要如何从第一格式（例如，适合由在第一网络域上的服务服务器使用）转换为第二格式（例如，适合由在第一网络域上的服务服务器使用）。与用于链接数据（例如，带有如本文中所述的进一步处理的目的）的细节有关的技术是技术人员公知的；例如，使两个或更多数据元素指向存储器存储装置（例如，42）上单个点（例如，数据记录），使用别名，其中，给定别名被指派为涉及不同（链接的）数据（例如，涉及CS-SRV#M和IMS-SRV#N）、数据指针等。

为实现与步骤1111相关的上述过程，DBS 11能够包括用于将修改的第一数据转换为根据第二域的格式的数据转换单元(47)。此外，数据转换单元47能够与数据存储处理单元44协作，以便在数据存储装置42中将用于第一网络域(20)的某个用户的转换的修改数据(SUBS)和第二域(30)中相同用户的数据相关存储。

能够为数据实现从第一域（即，如在步骤1103上所修改的）到第二域的数据转换，而与它是由在DBS 11上的转换单元（单元47）、第一服务服务器（例如，21、22、31、32的任何服务器）还是以数据转换特征为专长的另一种服务器（图1中未示出）执行无关。转换步骤1111优选包括应用某种数据内容同步规则，规则能够预确立以便例如与根据在第2代移动网络（例如，GSM/GPRS）的CS或PS域上功能相当数据的格式，转换与IMS有关的某些数据的格式（例如，数据类型和内容），且反之亦然。功能相当数据的示例是例如通过将进入会话转向与最初请求的目的地不同的另一最终目的地而控制进入会话的转发、或控制进入会话（例如，CS域中的话音呼叫、PS域中的数据呼叫、IMS域中的SIP会话）的禁止的那些数据。

例如，转换规则能够在以下两个数据值之间为描述用于SUBS（图2）下定义的任何用户数据的数据确立对应关系：在属于CS域的数据上，例如由服务服务器用于确定对于CS域(30)中某个用户的进入话音呼叫是否将转向某个备选目的地（例如，向另一MSISDN）的某个数据值，和例如与相同用户有关的IFC的内容上要修改的对应(201)数据值（例如，IMS-SRV#M，部分或全部），以便在激活，修改或去活CS域中的转发特征的情况下，在IMS域上其有关服务数据相应地在IMS域进行进一步修改；且反之亦然。修改与“初始过滤器准则”IFC有关的数据在本文中只叙述为一示范实施例，为用户与IMS域(IMS-DAT)相关存储的能够由S-CSCF直接解释和执行的这些和/或其它数据(SUBS)也能够被使用。IFC的结构和内容例如由附录B或E上的上述3GPP规范29.228 V8.5.0公开。

采用上述使用情况作为示例，能够有由数据转换单元（例如，47或53）保存的转换规则，在例如用于CS域30上用户的话音呼叫转发信息（例如，CS-SRV#M内容）的修改借助于某个值（例如，由CS-SRV#M内容存储）指出所有进入话音呼叫将转向某个备选目的地（例如，如例如也由CS-SRV#M内容包括的另一用户的MSISDN）时，所述转换规则确立要如何修改与IMS域有关的相同用户的数据的内容（例如，IMS-SRV#N），以便在IMS上寻址到此用户的进入会话也将输送到相同备选目的地。在此情况下，如果例如在步骤1103上修改CS- SRV#M数据，以便其当前内容例如是{2, +34913391000}，其中，“2”将表示话音“无条件呼叫转发”，并且“34913391000”将表示进入话音呼叫转发（转移）到的MSISDN号码，则例如应根据修改规则使涉及的用户的一个或多个“初始过滤器准则”IFC的内容（例如，如IMS-SRV#N所存储的）适用，所述修改规则将确立例如“TriggerPoint”的内容和/或“ApplicationServer”下的内容（例如，如由IMS-SRV#N存储的IFC的内容）应被如何修改，以便对于相同用户(SUBS)的IMS域20上接收的另外的进入的IMS会话也被无条件转向MSISDN“34913391000”（例如通过使用包含所述数字的Tel-URL）。

另外示例情况能够参照进入会话禁止特征来提供。例如，能够假设CS-SRV#M表示包括进入话音呼叫阻止/禁止信息的数据条目，其中，在例示用于某个用户的所述数据的寄存器上的值“1”表示例如所有进入话音呼叫要被禁止。随后，能够将转换规则与CS-SRV#M表示的数据的类型相关存储，以便在CS- SRV#M上在用于某个用户的所述数据上到值“1”的修改触发转换进程（例如，步骤1111），影响例如与相同用户有关的（例如，如图2中IMS-SRV#N所表示的）IFC上存储的“TriggerPoint”和/或“ApplicationServer”的内容。所述转换的结果随后相应地将造成（例如，如在步骤3105中一样，在随后通知诸如服务服务器23等CSCF时）由IMS域20处理的对于所述用户的另外的进入SIP会话也被禁止。

鉴于本文中的教导，技术人员将只面对在现有技术中选择用于链接数据的机制和定义用于与第一域（例如，20）有关的数据和与第二域（例如，30）有关的数据之间数据内容的数据格式转换机制的日常工作任务，与第一域有关的数据和与第二域有关的数据可能涉及类似的功能性，例如：进入会话的禁止、进入会话的转发等。

随后的步骤1113和1115能够根据前面分别关于步骤1107和1109给出的细节/选择执行，特殊性在于：根据与修改的数据有关的域选择消息M2C的目的地（第一）服务服务器（例如，如果在步骤1108上选择HSS，则在步骤1113上要相应地选择HLR）；能够在消息M2C上发送的附加数据优选也要进行转换（例如，D2C表示适当转换的步骤1107的D2）；以及具体而言，也由DSB 11（例如，使用上述表）根据转换的修改的数据(D1C)来选择与处理与转换的数据有关的网络域中涉及的用户的数据的另外服务服务器（例如，MSC/VLR，SGSSN，CSCF）有关的信息。

在接收通知在转换的数据D1C（以前在步骤1103上修改和存储）和D2C（如果继续）上修改的消息M2C时，如更早相对于步骤2101到2105所述，由接收服务服务器（例如，21、22、31、32的任何服务器）处理步骤3101到3105。具体而言，接收服务服务器（例如，21、22、31、32的任何服务器）无需知道（且其处理因此是透明的）它是在接收来自原数据修改（即，步骤1103的结果）还是来自DBS执行的随后数据修改（即，步骤1111的结果）的消息。

作为上述进程的结果，与相同用户有关的可用于提供服务到第一网络域（例如，20）上和第二网络域（例如，30）中的所述用户的数据(SUBS)能够以自动方式保持一致；这能够产生更佳的用户感知，并且使网络运营商更容易且更可靠地处理用户数据。此外，适用于数据分层架构DLA的系统（如图1中的）提供的内在优点能够得以保持，同时最小化后端存储系统(DBS 11)收发的信令，并且也最小化对现有数据库系统产品的设计适用影响。

图6示出根据本发明的一个实施例，在图1的一些服务器之间的简化信令流程，它考虑修改的数据上的数据格式转换在DBS 11内进行。

流程601表示消息请求DBS进行修改与某个用户有关的数据的数据操作，这如更早参照步骤1101到1107所述处理。也如更早公开的，流程601的消息的接收能够促使DBS在步骤1109上发送消息，向第一服务服务器通知数据修改。这在图6中通过流程602示出，其作为示例情况考虑到由于流程601中接收的请求而修改的数据是与HSS应用有关的数据（例如，IMS-SRV#N），并且HSS服务服务器（例如，21）被选择为在流程602中所示消息的目的地。

接收流程602的数据修改通知消息的服务服务器（例如，HSS 21）随后如前面参照步骤2101到2105所述处理它，这能够涉及在流程603上向另外的（第二）服务服务器(S-CSCF)发送另外的消息 - 有关在流程602的消息中由DBS优选指示的内容的信息，包括用户的标识符并请求修改其中与所述用户相关保存的数据。流程603的消息优选包括用于要由目的地（第二）服务服务器(S-CSCF)在其自己存储的数据上修改的数据的类型/内容值、哪种格式能够例如由流程603的消息的发送器来适用（如果需要）。如更早所述，诸如流程603所示消息的消息包括与例如在流程601的数据修改请求消息的接收时修改并且也由另外服务服务器（例如，S-CSCF）存储的数据有关的数据修改请求。

例如，如果流程601的消息请求的数据修改对于某个用户暗示无条件转发IMS域(20)中所有进入多媒体会话，或者禁止IMS域中所有进入多媒体会话，则进程的结果是指派为服务于所述用户（例如，用于在IMS域中注册的用户的给定终端）的S-CSCF将由于接收和处理流程603的请求而使其本地保存的关于这些服务的数据相应地被更新。根据此示例，流程603的消息能够是DIAMETER消息“推送简档请求”PPR。

随后，根据前面详细介绍的一实施例，DBS能够执行（步骤1111）有关在DBS上由于流程601的消息而修改的数据(D1)的数据转换，并且执行在DBS存储装置上与受第一修改（步骤1103）影响的相同用户相关的修改的数据(D1C)的随后存储。DBS也能够在步骤1111转换与相同用户有关的一些另外数据(D2)。随后，如流程604所示，DBS发送（步骤1115）消息到另一服务服务器(HLR)，通知与转换的修改的数据有关的数据修改。

诸如HLR（如图所示）等服务服务器进行的流程604的消息的接收暗示与如前面参照HSS/S-CSCF和流程602-603所述，并且更具体地说如更早参照图3的步骤3101到3015（或相当的步骤2101到2105）所述类似的处理。因此，随后的消息（流程605）将从HLR发送，以请求按照转换的修改的数据(D1C)来修改另外的服务服务器（例如，MSC/VLR 34）中保存的用户的数据，这将在其中相应地得到处理。流程605的消息例如能够是MAP消息“插入订户数据”。在上述示例后，如果流程601的消息请求的数据修改对于某个用户暗示无条件转发IMS域(20)中的所有进入多媒体会话或禁止IMS域中的所有进入多媒体会话，则对于服务于受影响用户的CS域(30)中话音呼叫的MSC/VLR，流程605的数据修改请求消息能够输送所述MSC/VLR中所述用户的标识符和MSC/VLR中关于所述用户要修改的必需数据，以便所有其进入话音呼叫例如被转向或禁止。

本发明已在说明性和非限制性方式中相对于一些示范实施例进行了描述。本领域技术人员能够轻松明白变化。为此原因，本发明要鉴于权利要求来解释和限制。

Claims (27)

1. 一种用于处理与通信系统(100)的用户有关的数据的方法，所述通信系统包括：用于存储与所述系统的多个用户有关的数据的数据库服务器(11)、和用于提供服务到所述用户的多个服务服务器（21、23、32、35），所述方法包括：

-在所述数据库服务器中接收（1101，601）第一消息，所述第一消息请求修改与用户有关的数据的数据操作；以及 

-根据所接收的请求来修改(1103)所述数据库服务器中与所述用户有关的第一数据；

特征在于它还包括：

-从所述数据库服务器发送（1109，602）通知所述数据修改的第二消息到所述多个服务服务器中的第一服务服务器(21)，所述第二消息包括：所述用户的标识符、与所述修改步骤后所述第一数据有关的信息以及处理与所述用户有关的数据以便向所述用户提供服务的所述多个服务服务器中的第二服务服务器(23)的标识符，以及

-从所述第一服务服务器发送（2105，603）第三消息到所述第二服务服务器，所述第三消息包括所述用户的标识符并请求修改其中与所述用户相关保存的数据。

2. 如权利要求1所述的方法，其中所述第二消息还包括：

-与所述修改步骤前的所述第一数据有关的信息，和/或 

-与数据操作的类型有关的信息，和/或

-与第二数据有关的信息，所述第二数据与所述用户相关存储，未受所述修改步骤影响。

3. 如权利要求2所述的方法，其中所述第二消息还包括与第二数据有关的信息，还包括：

-由所述数据库服务器根据所述第一数据来选择(1107)所述第二数据。

4. 如权利要求1所述的方法，还包括：

-由所述数据库服务器根据所述第一数据来选择(1107)所述第一服务服务器。

5. 如任一前面权利要求所述的方法，还包括：

-由所述第一服务服务器根据第二服务服务器的类型、或者根据所述第二消息中接收的信息，选择(2101)用于发送所述第三消息的协议。

6. 如任一前面权利要求所述的方法，还包括从以下选择的至少一个步骤：

-由所述数据库服务器根据所述第一数据、或者根据所述第一消息的发送器和所述第一服务服务器是否相同或是否具有相同类型来确定(1105)是否发送所述第二消息，

-由所述第一服务服务器根据接收的与所述第一数据或所述第二数据有关的信息、或者根据接收的与所述数据操作的类型有关的信息来确定(2103)是否发送所述第三消息。

7. 如任一前面权利要求所述的方法，其中所述通信系统包括第一(20)和第二(30)网络域，以及其中所述第一数据属于所述第一域中所述用户的数据，还包括：

-将所修改的第一数据转换(1111)为根据所述第二域的格式，以及 

-在所述数据库服务器中将所转换的修改的第一数据与所述第二域中所述用户的数据相关存储。

8. 如权利要求7所述的方法，其中转换的步骤在所述数据库服务器中进行。

9. 如权利要求7所述的方法，其中转换的步骤在所述第一服务服务器中进行，还包括：

-从所述第一服务服务器向所述数据库服务器发送第四消息，所述第四消息请求修改与所述用户有关的数据的数据操作并包括所转换的修改的第一数据。

10. 如权利要求7所述的方法，其中所述数据库服务器分开存储与所述第一域中和所述第二域中用户有关的数据，还包括：

-确立与所述第一域有关的所述用户的数据和与所述第二域有关的所述用户的另一数据之间的链接(201)，

其中如果此类链接存在，则进行转换的步骤。

11. 如权利要求7所述的方法，其中所述第一和第二网络域分别包括以下的至少之一：

-移动网络电路交换域，

-移动网络分组交换域，

-因特网协议多媒体子系统域IMS。

12. 一种数据库服务器(11)，包括：

-数据存储单元(42)，用于存储与通信系统的多个用户有关的数据，

-接收器单元(41)，用于接收请求修改与用户有关的数据的数据操作的第一消息，

-数据存储处理单元(44)，用于根据所接收的请求在所述数据存储装置中修改与所述用户有关的第一数据，以及 

-发送单元(43)，用于发送通知所述数据修改的第二消息到所述系统的第一服务服务器(21)，所述第二消息包括：所述用户的标识符、与所述修改步骤后所述第一数据有关的信息以及处理与所述用户有关的数据的所述系统的第二服务服务器的标识符。

13. 如权利要求12所述的数据库服务器，其中所述第二消息还包括：

-与所述修改前所述第一数据有关的信息，和/或 

-与数据操作的类型有关的信息，和/或 

-与第二数据有关的信息，所述第二数据与所述用户相关存储，未受所述修改影响。

14. 如权利要求13所述的数据库服务器，当所述第二消息还包括与第二数据有关的信息时，还包括用于根据所述第一数据来选择所述第二数据的数据选择单元(45)。

15. 如权利要求12所述的数据库服务器，还包括用于根据所述第一数据来选择所述第一服务服务器的服务器选择单元(46)。

16. 如权利要求12到15的任一项所述的数据库服务器，还包括用于根据所述第一数据、或根据所述第一消息的发送器和所述第一服务服务器是否相同或是否具有相同类型来确定是否发送所述第二消息的消息发送确定单元(48)。

17. 如权利要求12到16的任一项所述的数据库服务器，其中所述通信系统包括第一(20)和第二(30)网络域，以及其中所述第一数据属于所述第一域中所述用户的数据，还包括：

-数据转换单元(47)，用于将所修改的第一数据转换为根据所述第二域的格式，

以及其中所述数据存储处理单元还适用于在所述数据存储装置中将所转换的修改的第一数据与所述第二域中所述用户的数据相关存储。

18. 如权利要求17所述的数据库服务器，其中所述数据存储装置适用于：

-分开存储与所述第一域中和所述第二域中的用户有关的数据，以及

-链接(201)与所述第一域有关的所述用户的数据和与所述第二域有关的所述用户的另一数据，

以及其中所述数据转换单元还适用于在转换前检查此类链接存在。

19. 如权利要求17所述的数据库服务器，其中所述第一和第二网络域分别包括以下的至少之一：

-移动网络电路交换域，

-移动网络分组交换域，

-因特网协议多媒体子系统域IMS。

20. 一种用于提供服务到通信系统的用户的服务服务器(21)，包括：

-接收器单元(51)，用于从存储与所述系统的多个用户有关的数据的数据库服务器(11)接收通知与用户有关的第一数据的数据修改的第一消息，所述消息包括：所述用户的标识符、与所述修改步骤后所述第一数据有关的信息、以及处理与所述用户有关的数据的所述系统的第二服务服务器的标识符，以及 

-发送单元(52)，用于在接收所述第一消息时，发送第二消息到所述第二服务服务器，所述第二消息包括所述用户的标识符并请求修改其中与所述用户相关保存的数据。

21. 如权利要求20所述的服务服务器，其中所述第一消息还包括：

-与所述修改前所述第一数据有关的信息，和/或

-与数据操作的类型有关的信息，和/或

-与第二数据有关的信息，所述第二数据与所述用户相关存储，未受所述修改影响。

22. 如权利要求20或21所述的服务服务器，还包括用于根据第二服务服务器的类型、或者根据所述第一消息中接收的信息来选择用于发送所述第二消息的协议的协议选择器(55)。

23. 如权利要求20到22的任一项所述的服务服务器，还包括用于根据与所述第一数据或所述第二数据有关的接收的信息、或者根据与所述数据操作的类型有关的接收的信息来确定是否发送所述第二消息的消息发送确定单元(54)。

24. 如权利要求20到23的任一项所述的服务服务器，其中所述通信系统包括第一和第二网络域，以及其中所述第一数据属于所述第一域中所述用户的数据，还包括：

-数据转换单元(53)，用于将所修改的第一数据转换为根据所述第二域的格式，

其中所述发送单元还适用于将第三消息发送到所述数据库服务器，所述第三消息请求修改与所述用户有关的数据的数据操作并包括所转换的修改的第一数据。

25. 如权利要求24所述的服务服务器，其中所述第一和第二网络域分别包括以下的至少之一：

-移动网络电路交换域，

-移动网络分组交换域，

-因特网协议多媒体子系统域IMS。

26. 一种包括计算机可读指令的计算机程序产品，所述指令在基于计算机的数据库服务器中被加载时用于执行如权利要求1到11的任一项所述的涉及所述数据库服务器(11)的步骤。

27. 一种包括计算机可读指令的计算机程序产品，所述指令在基于计算机的服务服务器中被加载时用于执行如权利要求1到11的任一项所述的涉及所述第一服务服务器的步骤。

Images