融合用户信息的系统及用户信息的感知、融合和决策方法

具体实施方式

本发明的基本思想是：引入融合用户信息感知实体，通过融合用户信息感知实体获取来自多用户信息源的用户信息，对获取的用户信息进行融合，将融合用户信息提供给CPM使能者实体；CPM使能者实体根据融合用户信息，进行CPM业务控制和决策。

下面结合附图对技术方案的实施作进一步的详细描述。

一种融合用户信息的系统，该系统包括：融合用户信息感知实体和CPM使能者实体。其中，融合用户信息感知实体，用于获取来自多用户信息源的用户信息，对获取的用户信息进行融合，将融合用户信息提供给CPM使能者实体。CPM使能者实体，用于根据融合用户信息进行CPM业务控制和决策。

这里，融合用户信息感知实体，进一步用于通过对用户信息统一的存储和处理，实现所述融合。其中，存储包括：根据来自多用户信息源的用户信息之间的关联关系，将用户信息组织后存储。处理包括：以CPM用户为单位，采用数据仓库的形式对来自多用户信息源的用户信息进行处理。

这里，CPM使能者实体，进一步用于通过融合用户信息感知实体提供的单点访问接口，从融合用户信息感知实体获取融合用户信息。其中，CPM使能者实体具体包括：CPM参与功能、和/或互通选择功能、和/或应用控制功能。

这里，融合用户信息感知实体，进一步用于作为CPM参与功能的内部实体，并通过内部接口，将融合用户信息提供给所述CPM参与功能。CPM参与功能，进一步用于通过与融合用户信息感知实体之间的内部接口获取融合用户信息，并根据融合用户信息实时地进行CPM业务控制和决策。

一种用户信息的感知、融合和决策的方法，该方法包括以下步骤：

步骤11：融合用户信息感知实体获取来自多用户信息源的用户信息，对获取的用户信息进行融合。

步骤12：CPM使能者实体根据融合用户信息，进行CPM业务控制和决策。

这里，针对由以上步骤11～12所构成的技术方案而言，步骤11中，实现上述融合进一步包括：融合用户信息感知实体对用户信息进行统一的存储和处理。

其中，存储包括：根据来自多用户信息源的用户信息之间的关联关系，将用户信息组织后存储。处理包括：以CPM用户为单位，采用数据仓库的形式对来自多用户信息源的用户信息进行处理。

这里，所述处理具体包括：去除冗余的用户信息；来自多用户信息源的用户信息出现冲突时，基于融合用户信息感知实体的本地策略，对用户信息进行判断并决策选择最佳用户信息。这里，所谓最佳用户信息指：能够较真实表征用户信息当前内容并保持用户信息的一致性的用户信息。

这里，该方法进一步包括：CPM使能者实体通过融合用户信息感知实体提供的单点访问接口，获取融合用户信息。

这里，CPM使能者实体具体为CPM参与功能，融合用户信息感知实体作为CPM参与功能的内部实体时，该方法进一步包括：CPM参与功能通过与融合用户信息感知实体之间的内部接口获取融合用户信息。

这里，步骤11中，针对获取而言，CPM使能者实体具体为CPM参与功能时，所述获取的触发条件包括：由第三方注册请求所触发、或由CPM融合信息查询请求所触发。

CPM参与功能基于触发条件触发获取过程后，该方法进一步包括：通过CPM参与功能内部的融合用户信息感知实体发起获取过程。

这里，步骤11中，针对融合而言，融合用户信息由从多用户信息源获取的用户信息构成。

所述融合的触发条件包括：由获取到CPM用户信息或信息变化的动作触发。

基于融合的触发条件触发融合过程后，该方法进一步包括：融合用户信息感知实体针对目标用户加载本地存储的各个用户信息源对应的用户信息文档，完成最终的文档内容的融合计算过程。其中，融合计算过程包括：针对融合用户的通信地址信息、融合用户注册状态信息、融合注册设备的属性信息、融合用户访问策略信息、融合呈现状态信息、融合会话状态信息的融合计算。

这里，步骤12中，针对业务控制和决策而言，根据融合用户信息进行CPM业务控制和决策，具体包括：CPM参与功能根据融合用户信息进行的业务控制和决策过程，和/或互通选择功能根据融合用户信息进行的业务控制和决策过程，和/或应用控制功能根据融合用户信息进行的业务控制和决策过程。以下对上述三个过程分别阐述。

针对CPM参与功能根据融合用户信息进行的业务控制和决策过程而言，该过程包括：

步骤121a、发起端/终止端的CPM参与功能接收到CPM请求消息。其中，CPM请求消息包括：CPM会话、CPM消息或CPM文件传输等。

步骤122a、发起端/终止端的CPM参与功能通过内部接口查询发起方/终止方的CPM用户的融合用户信息感知状态。

步骤123a、判断针对发起方/终止端的CPM用户是否触发了融合用户信息感知操作，如果没有触发，则进行步骤124a；如果触发了，则进行步骤125a。

步骤124a、触发融合用户信息感知实体发起的融合用户信息感知操作，然后进行步骤125a。

步骤125a、发起方/终止端的CPM参与功能通过内部接口获取到了发起方/终止方的CPM用户的融合用户信息。

步骤126a、发起方/终止端的CPM参与功能根据自身业务逻辑的需求，解析对应的融合用户信息并进行逻辑执行控制，例如：发起方的CPM参与功能参考发起方用户的访问策略信息和偏好信息；终止方CPM的参与功能参考终止方用户的注册状态、访问策略、用户偏好、会话状态等信息。

针对互通选择功能根据融合用户信息进行的业务控制和决策过程而言，该过程包括：

步骤121b、互通选择功能接收到互通请求消息。

步骤122b、互通选择功能通过内部或外部接口，向融合用户信息感知实体发起目标CPM用户的融合用户信息查询请求。

步骤123b、判断融合用户信息感知实体判断针对目标CPM用户是否触发了融合用户信息感知操作，如果没有触发，则进行步骤124b；如果触发了，则进行步骤125b。

步骤124b、触发融合用户信息感知实体发起的融合用户信息感知操作，然后进行步骤125b。

步骤125b、融合用户信息感知实体将目标CPM用户的融合用户信息返回给互通选择功能。

步骤126b、互通选择功能根据互通方案的计算逻辑，解析相关的融合用户用户信息，如非CPM用户联系地址、互通相关的用户偏好等，计算互通选择方案。

步骤127b、互通选择功能结合计算出来的互通选择方案，选择非CPM业务对应的互通功能进行业务互通尝试。

针对应用控制功能根据融合用户信息进行的业务控制和决策过程而言，该过程包括：

步骤121c、VAS应用针对目标CPM用户提供增值业务。

步骤122c、应用控制功能向融合用户信息感知实体订阅了特定事件，如CPM用户的当前注册状态、会话状态等。

步骤123c、融合用户信息感知实体判断针对目标CPM用户是否触发了融合用户信息感知操作，如果没有触发，则进行步骤124c；如果触发了，则进行步骤125c。

步骤124c、触发融合用户信息感知实体发起的融合用户信息感知操作，然后进行步骤125c。

步骤125c、融合用户信息感知实体在相关CPM用户状态发生变化时，向应用控制功能反馈相应的事件通知消息。

步骤126c、应用控制功能将特定事件反馈给VAS应用。

步骤127c、VAS应用根据通知事件类型，对向CPM用户提供的增值业务进行调整。

综上所述，针对本发明所要解决的技术问题而言，现有的用户信息使用方式为：CPM使能者基于业务逻辑执行的需要，从分散的用户信息源分别获取用户信息，并进行业务逻辑控制和处理。这种现有的方式存在很多弊端，包括：多信息源信息获取过程繁琐而不易管理；与多信息源的信息交互时延不稳定；用户信息源之间的用户信息独立且不完备，信息源之间可能存在信息冗余和信息不一致的情况，无法体现信息关联关系等等。

基于现有这种用户信息的获取方案，会对CPM业务的用户体验造成一定的影响，并且不利于提供基于完备用户信息感知能力的智能型的融合业务，束缚了基于CPM使能者框架的融合业务的发展。因此建立合理的信息获取模型、访问模型、存储模型和管理模型，对CPM业务的提供将起到关键的作用。

而本发明的方案是一种集中式的融合用户信息的系统，以及基于该融合用户信息的系统的使用方法流程，这里，该使用方法流程主要包括用户信息的感知、融合及根据融合的信息进行决策几方面内容。采用本发明，对分散于多信息源的用户多方面信息，能进行动态采集、融合和统一管理，并为CPM决策过程相关实体提供充分的用户信息支持。

本发明主要包括以下内容：

1.1方案概述

本发明基于集中式的融合用户信息的系统逻辑架构如图3所示，图3为本发明系统中各实体的逻辑关系图。需要指出的是，各实体的具体物理布局不限定于图3的范围，如以下的图5所示为一个具体的系统物理布局实例。具体描述请详见有关图5的描述。

图3中，在该系统架构中，首先定义了一个融合用户信息感知实体，它负责对本域内的CPM用户各方面的信息进行统一的感知和融合能力，为CPM参与功能和互通选择功能等业务控制和决策实体提供融合的用户信息；其次，定义了以用户为中心的融合用户信息模型的生成和使用方案，保证了用户信息的融合和一致，提高了业务的准确性和用户体验。其中，所示本域内的CPM用户各方面的信息包括：分布式地存储在CPM客户端处的信息、SIP/IP核心网络处的信息、以及各个CPM支撑使能者等处的信息。

在集中式的融合用户信息感知模型中，采用了将融合用户信息感知实体作为CPM参与功能内部实体的实现方式，基于以下原因：

a：CPM参与功能是用户信息最重要的消费者。

CPM参与功能面向CPM用户执行功能。不论是CPM用户发起或接收CPM消息/CPM会话的过程，都要由CPM参与功能完成相关决策，因此需要用户信息的支撑。融合用户信息感知实体作为参与功能的内部组件，则信息查询接口变为内部接口，提高访问效率。

b：CPM参与功能可以分布部署。

CPM参与功能是面向用户的功能实体，在一个CPM域内可以部署多个CPM参与功能为不同用户进行服务，这种分布式的结构类似于IMS核心中的S-CSCF的分布方式。因此可以实现CPM参与功能的负载均衡，不会使得负责集中式采集的融合用户信息感知实体出现明显的瓶颈效应。

CPM参与功能在决策过程之前，就提前完成了对用户信息的感知、融合、存储和管理过程，可以相对实时地从融合用户信息感知实体获取最新、最准确的用户信息；同时所有关注融合用户信息的CPM使能者实体在需要用户信息进行决策时，只需要通过融合用户信息感知实体提供的单点访问接口就可以获取来自多信息源的融合用户信息。该方案不需要关注某种用户信息到底最终来自于哪些信息源，避免了决策实体分别向多个信息源进行信息获取的繁琐过程，以及按需进行信息鉴别和组织可能带来的复杂性和不准确性。

图4为CPM参与功能基于集中式的融合用户信息的系统执行用户信息感知、融合和决策的流程图，该流程包括以下步骤：

步骤201、CPM参与功能收到条件触发(如CPM用户的参与功能收到第三方注册请求、CPM用户的参与功能收到CPM请求)，通过内部的融合用户信息感知实体发起用户信息感知过程。

步骤202、融合用户信息感知实体向SIP/IP核心网发起获取用户注册状态的请求。

步骤203、SIP/IP核心网将用户注册状态返回给融合用户信息感知实体。

步骤204、融合用户信息感知实体向用户偏好XDMS(属于XDM使能者)发起获取用户偏好信息的请求。

步骤205、用户偏好XDMS(属于XDM使能者)将用户偏好信息返回给融合用户信息感知实体。

步骤206、融合用户信息感知实体向呈现使能者发起获取用户呈现信息的请求。

步骤207、呈现使能者将用户呈现信息返回给融合用户信息感知实体。

步骤208、融合用户信息感知实体对收集到的用户信息进行分类与组织。

步骤209、CPM参与功能收到远端CPM系统发送过来的CPM消息。

步骤210、CPM参与功能通过内部接口获取目标用户的各方面用户信息，并基于这些参考信息进行业务决策，即：对CPM消息采取的下一步动作，如：立即向用户发送、延迟发送、丢弃或互通等。

注：上述流程中的202、204、206步骤可以并发地进行，并且实际的用户信息源不局限于图中给出的信息源实体。

1.1.1方案的体系架构

以下对系统架构进行举例说明，图5为基于CPM使能者框架提出的融合用户信息的系统图。图5中的核心部件是：本发明所引入的对用户信息进行集中式采集和管理的逻辑实体——融合用户信息感知实体。

融合用户信息感知实体的功能包括以下内容：

1)负责本地域内用户相关信息的感知(获取和动态维护)，包括与信息源的通信交互以及信息发生变化时的动态更新，并将各个信息源获取的信息基于用户信息之间的关联关系进行组织与保存。

2)负责向信息请求者提供特定格式的访问接口，接收对用户信息的获取请求，并以特定的信息组织格式(如XML文档)提供给请求方。

3)负责以CPM用户为单位，采用数据仓库的形式对从多信息源获取的用户进行组织管理，包括去除冗余的用户信息，并且在多信息来源获取的用户信息数据出现冲突时，基于本地策略对用户信息进行判断并决策选择最佳用户数据，保持数据一致性。

图5中，还以点划线标识了融合用户信息感知实体从本域内信息源获取用户信息的信息感知接口；粗实线标识了用户信息请求方向融合用户信息感知实体请求用户信息的信息访问接口。

1)信息感知接口

该接口的功能是为本域内的融合用户信息感知实体提供从信息源获取信息并进行动态更新维护的能力。结合具体信息源的接口能力，应采用不同的接口协议，如XML配置访问协议(XCAP，XML Configuration Access Protocol)协议、SIP协议的订阅通知机制(SUBSCRIBE/NOTIFY)等。

该接口由各个信息源提供的接口能力来实现。对应于CPM体系架构，是由CPM参与功能和支撑使能者之间的接口以及CPM参与功能和SIP/IP核心网之间的接口提供，不需要对CPM体系架构内的现有接口进行修改。

2)信息访问接口

该接口的功能是请求并获取用户的融合信息，如果信息是以XML文档的形式进行组织，可以采用XCAP协议来获取；也可以采用SIP协议的订阅通知机制。

另外，该接口还应该提供对部分用户信息的访问能力(如只获取设备信息、只获取偏好信息等等)，供决策实体仅仅对其感兴趣的信息内容进行查询。

针对互通选择功能访问用户信息的情况，需要CPM参与功能为其提供专用的接口，可以通过将互通选择功能和CPM参与功能部署在一起，将该接口转变成为互通选择功能和CPM参与功能之间的内部接口，从而避免了对CPM体系架构的修改，此外该部署方式可以实现基于融合用户信息感知实体提供的信息直接进行互通决策和互通选择过程，简化了CPM业务向非CPM业务互通的互通流程。

1.1.2用户信息源和信息感知接口

融合用户信息感知实体负责维护与用户信息源之间的订阅关系。相关的用户信息源和信息感知接口如下图6所示，图6为融合用户信息感知实体与用户信息源的示意图。

下表1对CPM业务环境下的用户信息源和信息源对应的信息获取方式进行了说明。表1为信息源、用户信息内容和获取方式的说明表。

表1

1.1.3用户信息分类与信息组织存储模型

在融合用户信息感知实体中，以用户为单位对用户信息进行组织和管理，保存在用户数据仓库中。在该过程中对各个信息源中的用户信息进行处理，去除了无关的冗余用户信息，同时基于本地策略(信息源优先级)解决信息冲突问题，保证了用户信息的一致性。

本发明中将CPM业务环境下的用户信息进一步细化分类。从提供融合用户信息的角度，以用户为单位对CPM中需要的信息如下分类：

a、用户状态：用户活动、用户心情、用户位置、用户角色、用户可达性意愿等等。

b、用户偏好：用户针对不同场景下的通信意愿描述。

c、用户访问策略：用户为应用方服务器指定了对请求、消息、媒体相关的处理偏好。

d、用户可用业务：用户订购的业务，如CPM业务、非CPM业务(SMS、VoIP等)。

e、用户联系地址：用户可用的地址信息(CPM地址、非CPM通信地址)。f、用户可用设备：用户可用设备的标识、属性、能力等相关信息。

g、用户可用网络：用户设备可用使用的网络相关信息，如网络标识、漫游属性等等。

结合CPM相关需求，图7为用户信息类型间的关联关系图，显示了对CPM用户各类型信息之间的包含和关联关系。其中的实线表示数据之间的包含关系，虚线表示数据之间的引用关联关系(通过相关的标识在文档内进行引用)。

信息组织模型说明如下：

图7中的实线描述了各类用户信息的上下级组织结构：用户偏好配置、用户访问策略、联系地址、设备信息、用户状态作为用户信息的下一级数据信息；而用户可用业务作为联系地址中包含的下一级信息，用来表示业务与联系地址的订购关系，网络作为设备信息中包含的下一级信息，用来表示设备与网络的连接关系。图7中虚线描述了不同类别用户信息之间的关联关系，箭头标明了引用关系的方向。

其中，实线部分的关系包括：用户可以有多个偏好配置，针对不同的场景组织成为不同的偏好配置文档；用户可以使用不同设备，因此用户设备信息包含这些不同设备的信息，其中包括了相应设备的通信能力、设备软硬件属性等相关数据；用户可以使用多个联系地址，因此包含不同的联系地址信息；用户具有一份用户状态的描述；一个联系地址可以订购多个业务；一个设备可以连接到多个网络。

其中，虚线部分描述的是各类信息之间的相互关联关系，包括：联系地址VS.用户偏好：可以为一个联系地址激活一个用户偏好场景；联系地址VS.访问策略：可以为一个联系地址指定一份访问策略；设备VS.用户偏好：可以为一个设备激活一个用户偏好场景；联系地址VS.设备：一个联系地址可以由多个设备进行注册；业务VS.设备：一个业务可以使用多个设备；设备VS.业务：一个设备可以用于多个业务。

每一类用户信息的实例中应该包含一个唯一的标识ID，不同类型信息的关联关系通过在相应部分的信息中包含关联项的标识ID进行描述，通过这些标识ID可以关联并定位到相关的信息。

1.2用户信息的感知过程

用户信息感知过程由CPM参与功能在特定条件下触发，触发信息感知过程的情况包括：CPM参与功能接收到特定CPM用户的第三方注册请求；CPM参与功能接收到查询特定CPM用户融合信息的请求，比如XCAP请求或SIP订阅请求。

其中，第三方注册请求触发的信息感知过程，可以保证所有以及已经完成注册过程的CPM用户信息能够被自动的感知和融合，具体操作流程如图8所示，图8为第三方注册请求触发的信息感知流程图，包括以下步骤：

步骤301、CPM参与功能接收到SIP/IP核心网络发送的第三方注册请求，解析注册用户URI和注册时间Expires头域，进行步骤302的操作。

步骤302、CPM参与功能通过注册时间Expires头域判断第三方注册请求的类型，如果是发起用户注册过程，则进行步骤303处理；如果是解除用户注册操作，则进行步骤305处理。

步骤303、CPM参与功能通过内部接口查询注册用户对应的信息感知状态，进行步骤304处理。

步骤304、根据查询结果判断是否发起了针对注册用户的信息感知操作，如果没有发起过则进行步骤307处理；如果发起过信息感知操作则进行步骤308处理。

步骤305、获取注册用户的当前注册状态信息，进行步骤306处理。

步骤306、根据获得的注册状态信息，判断该用户当前是否还存在有效的注册设备，如果存在则进行步骤308的处理；如果不存在则进行步骤309的处理。

步骤307、向相关信息源发起初始订阅请求。其中，相关信息源包括：XDM使能者、SIP/IP核心网、呈现使能者、融合地址簿，不做赘述。

步骤308、向相关信息源发起刷新订阅请求。

步骤309、向相关信息源发起终止订阅请求。

当CPM参与功能接收到其他实体查询CPM融合用户信息的请求时，如果该用户尚未注册，即：未发起对该用户的信息感知过程，则触发融合用户信息感知实体对目标用户的信息感知过程，来满足相关的信息查询请求，具体操作流程如图9所示，图9为融合信息查询请求触发的信息感知流程图，该流程包括以下步骤：

步骤401、融合用户信息感知实体接收到针对特定CPM用户的融合信息查询请求，进行步骤402的操作。其中，针对特定CPM用户的融合信息查询请求包括：XCAP GET请求或SIP SUBSCRIBE请求。

步骤402、查询目标CPM用户的当前信息感知状态，进行步骤403处理。

步骤403、根据查询结果判断是否已经针对该用户发起过信息感知操作，如果没有发起过信息感知过程则进行步骤404处理；如果发起过信息感知过程则进行步骤405处理。

步骤404、触发融合用户信息感知实体发起针对目标用户的信息感知操作，进行步骤406处理。

步骤405、向查询实体返回目标用户的融合用户信息。

当融合用户信息感知实体完成了针对目标用户的信息感知过程后，它将可以接收来自各个信息源的CPM用户信息。根据与信息源之间的具体接口方式，可以划分为以下四种类型：

1)CPM参与功能通过内部接口主动提供的用户信息。

通过内部接口定义的相关数据结构将用户信息提供给融合用户信息感知实体，如图10所示，图10为CPM参与功能通过内部接口提供信息的流程图。

2)SIP/IP核心网络通过ISC接口主动提供的SIP消息。

通过ISC接口的能力，CPM参与功能将接收到的第三方注册请求消息提供给融合用户信息感知实体，如图11所示，图11为第三方注册请求消息提供用户信息的流程图。

3)融合用户信息感知实体通过XCAP协议向XDMS获取XML文档内的用户信息。

通过CPM-XDM接口的能力，融合用户信息感知实体主动通过XCAP GET请求操作获取HTTP URI描述的XML文档内容，如图12所示，图12为通过XCAP请求获取用户信息的流程图。

4)融合用户信息感知实体通过SIP订阅通知机制向相关信息源订阅用户信息或信息变化通知。

通过CPM-XDM/PRS-2/ISC接口的能力，融合用户信息感知实体向信息源发起信息订阅请求，并被动接收NOTIFY通知消息来获取实时的用户信息，如图13所示，图13为通过SIP订阅通知机制获取用户信息的流程图。

1.2.2用户信息的融合过程

1)融合用户信息计算过程的触发

用户信息的融合存储过程由获取到CPM用户信息或信息变化的动作触发。即在接收到了相关信息源提供的某种用户信息或用户信息的变化时，融合用户信息感知实体自动开始并完成最新的融合用户信息的计算过程。这种获取用户信息的情况包括：

a、CPM参与功能通过与融合用户信息感知实体之间的内部接口提供用户会话信息。

b、通过SIP协议的第三方注册消息携带的注册设备和接入网络的属性信息。

c、通过SIP协议的NOTIFY通知消息携带最新的用户信息或用户信息的变化描述。其中，用户信息的变化描述包括：XDM使能者支持的xcap-diff格式或呈现使能者支持的部分通知格式，例如访问策略、用户偏好、呈现状态等信息。

d、通过XCAP GET请求获取XML文档描述的用户信息内容，如访问策略文档、用户偏好文档、融合地址簿信息等。

接收到特定的用户信息后，自动触发用户信息融合的过程如图14所示，图14为融合用户信息计算过程的触发流程图，该流程包括以下步骤：

步骤501、融合用户信息感知实体通过内部或外部接口获取到实时的用户信息后，进行步骤502的操作。

步骤502、查询目标CPM用户的当前信息感知状态，判断是否已经发起过信息感知操作，是则进行步骤503处理；否则不作处理并终止流程。

步骤503、融合用户信息感知实体根据对应的信息来源对本地缓存的用户信息进行更新，然后进行步骤504处理。

步骤504、自动开始用户信息的融合。

步骤505、将融合后的用户信息进行本地存储。

2)融合用户信息的整体计算步骤

当触发了用户信息的融合过程后，融合用户信息感知实体将会针对目标用户加载本地存储的各个信息源对应的用户信息文档，并完成最终的文档内容的融合计算过程，具体的融合算法执行过程如图15所示，图15为融合用户信息文档内容的融合计算实现流程图，图15对应的用户信息的融合算法流程可以划分为以下步骤：

起始步骤：算法执行的初始准备工作，明确本地存储的用户信息对应的存储位置。

步骤601：融合用户的通信地址信息，具体算法执行过程如下：

解析本地缓存的来自于融合地址簿(CAB)的用户信息文档；

在融合地址信息中保持CPM用户地址和非CPM用户地址信息。

步骤602：融合用户注册状态信息，具体算法执行过程如下：

解析本地缓存的来自于SIP/IP核心网络的用户注册状态信息文档；

查找文档中对应的用户地址记录(registration元素)，在融合用户信息中设置该地址对应的注册状态；

获取用户地址下的注册设备信息(contact元素)，在融合用户信息中保存注册设备信息(如设备唯一标识符、设备UA能力集描述信息等)；

在融合用户信息中的用户地址信息中关联对应注册设备的唯一标识符。

步骤603：融合注册设备的属性信息，具体算法执行过程如下：

解析本地缓存的来自于第三方注册请求消息内的设备属性信息文档；

根据文档中的设备唯一标识符定位融合用户信息中的设备记录；

在融合用户信息中的对应设备记录中保存设备的属性描述信息和设备接入网络信息。

步骤604：融合用户访问策略信息，具体算法执行过程如下：

解析本地缓存的来自于XDM使能者的用户访问策略信息文档；

在融合用户信息中保存获取的用户访问策略信息；

将用户访问策略信息关联到对应的用户地址记录。

步骤605：融合呈现状态信息，具体算法执行过程如下：

解析本地缓存的来自于呈现使能者的用户呈现状态信息文档；

解析用户联系信息，在融合用户信息中添加未包含的用户通信地址记录；

解析用户在线状态，在融合用户信息中的对应用户地址记录中保存在线状态；

解析设备描述信息，在融合用户信息中的对应设备记录中基于优先级对设备描述信息进行处理和保存；

解析用户状态信息(如用户心情、用户活动、用户位置、环境等)，在融合用户信息中保存以上的用户状态信息。

步骤606：融合用户偏好信息，具体算法执行过程如下：

解析本地缓存的来自于XDM使能者的用户偏好配置信息文档；

在融合用户信息中保存用户偏好配置文档中的用户偏好信息内容；

查询针对CPM用户激活的用户偏好配置，在融合用户信息中对应的用户地址记录中关联该用户偏好配置的唯一标识符；

查询针对特定设备激活的用户偏好配置，在融合用户信息中对应的注册设备记录中关联用户偏好配置的唯一标识符。

步骤607：融合会话状态信息，具体算法执行过程如下：

解析本地缓存的来自于CPM参与功能的用户会话状态信息；

在融合用户信息中保存CPM用户的当前会话状态信息；

在融合用户信息中定位对应的用户地址记录，将正在进行的会话的标识符关联到该地址；

在融合用户信息中根据会话使用的设备唯一标识符，定位对应的设备记录信息，将正在进行的会话的标识符关联到该设备。

终止步骤：将算法执行结束后获得的融合用户文档的内容进行本地存储，供融合用户信息的信息消费实体查询应用。

注：当处理的用户信息内容同时存在于多个信息源文档内容中时，在基于上述算法对该信息进行融合处理的过程中，基于本地策略的信息源优先级进行一致性处理，即当出现信息冲突时以高优先级信息源的信息为准，来保证数据的一致性。

如果某个用户信息的信息源没有反馈有效的用户信息，如访问控制权限不够，无法获得用户信息，则跳过对该信息源文档内容的融合处理步骤，进行下一步骤的融合计算处理。当然该信息源代表的用户信息和用户信息之间的关联关系在融合用户信息文档内容中将无法体现。

3)融合用户信息的内容更新过程

融合用户信息发生中某类用户信息发生变化时，对融合用户信息的更新过程有两种具体的实现方案，以下分别阐述。

方案1的实现思想是：将用户信息变化对应的本地缓存信息进行更新，然后重新进行融合用户信息的完整计算过程。该算法的优点是：算法思想简单，实现过程较容易，不需要对不同类型的用户信息变化进行复杂的逻辑处理过程；缺点是：对没有变化的用户信息进行了重复运算，更新过程的效率较低。

方案2的思想是：将用户信息变化对应的本地缓存信息进行更新，然后重新执行该用户信息源对应的计算步骤；然后查找后续计算步骤中哪些步骤涉及了对变化信息的查询关联处理，并重新执行查找到的计算步骤。该算法的优点是：不需要对所有的用户信息进行重新融合计算，提高了融合用户信息的更新效率；缺点是需要额外记录用户信息计算步骤之间的信息关联关系，算法实现难度比方案1大。此外需要额外记录存在信息冲突情况的用户信息当前优先级水平，具体操作包括：

在融合用户信息的整体融合计算过程中，在对用户信息的一致性进行处理时，记录冲突信息的最终优先级(多信息源的最高优先级)；

在方案2的信息更新过程中，如果针对特定用户信息，反馈信息变化的信息源优先级高于或等于当前冲突信息的优先级记录，则进行该用户信息的更新，同时将冲突信息的优先级记录设置为当前信息源对应的优先级；否则，如果信息源的优先级低于当前冲突信息优先级记录，则不进行信息更新。

1.2.3融合用户信息模型的使用

融合用户信息模型的使用涉及到CPM体系架构中需要CPM用户信息作为决策支撑的相关信息消费实体，包括：CPM参与功能、互通选择功能、应用控制功能等实体。

按照相关功能实体与融合用户信息感知实体是否部署在一个物理实体内，融合用户信息的查询操作接口分为两大类：内部接口和外部接口。其中融合用户信息感知实体位于CPM参与功能内部，因此CPM参与功能通过内部接口获取融合用户信息内容；其他实体，比如互通选择功能、应用控制功能，如果部署在CPM参与功能内部，则也通过内部实体获取融合用户信息，否则通过外部接口进行融合用户信息的查询。外部接口实现的备选协议包括：XCAP协议和SIP协议的订阅通知机制。

1)CPM参与功能对融合用户信息的使用

CPM参与功能作为CPM业务中面向用户的业务执行核心实体，代表用户进行CPM业务的业务流程控制，实现包括CPM会谈控制和互通决策的相关逻辑控制功能。CPM会谈控制可以基于融合用户信息提供的用户访问策略、偏好信息、设备注册状态、会话状态、用户状态、设备通信能力和使用情况等方面的用户信息完成具体的业务控制操作；CPM互通决策过程可以基于融合用户信息提供的如用户互通偏好、访问策略、注册状态(注册/未注册)等方面的信息进行互通决策的逻辑执行过程。

因此，在CPM会谈控制和互通决策过程中需要准确、实时的相关CPM用户信息作为决策支撑，为用户提供人性化、智能型的融合用户体验。通过融合用户信息感知实体的能力，可以实时获取最新、最准确的融合用户信息内容和信息之间的关联关系，如当前设备正在进行哪些会话过程，设备使用了激活了哪些偏好配置等，进而完成CPM会谈控制和互通决策的业务逻辑执行。

发起方CPM参与功能对应的执行流程，与终止方CPM参与功能的执行流程类似，具体流程说明如下，包括：

步骤701、发起端/终止端CPM参与功能接收到CPM会话、CPM消息或CPM文件传输等请求消息，进行步骤702的操作。

步骤702、发起端/终止端CPM参与功能通过内部接口查询发起方/终止方CPM用户的融合用户信息感知状态，进行步骤703的操作。

步骤703、判断针对发起方/终止端CPM用户是否发起了信息感知操作的过程，如果没有触发则进行步骤704操作；如果触发了信息感知操作则进行步骤705的操作。

步骤704、触发融合用户信息感知实体发起信息感知操作，然后进行步骤705处理操作。

步骤705、发起方/终止端CPM参与功能通过内部接口获取到了发起方/终止方CPM用户的融合用户信息，进行步骤706处理操作。

步骤706、发起方/终止端CPM参与功能根据自身业务逻辑的需求，解析对应的用户信息内容进行逻辑执行控制，例如：发起方CPM参与功能参考发起方用户的访问策略信息和偏好信息；终止方CPM参与功能参考终止方用户的注册状态、访问策略、用户偏好、会话状态等信息。

2)互通选择功能对融合用户信息的使用

CPM业务体系架构中的互通选择功能对融合用户信息的使用根据其部署方式分为不同的情况，如果互通选择功能部署为CPM参与功能的内部功能实体，则信息查询操作通过内部接口来实现；否则如果互通选择功能部署为外部功能实体中，则信息查询操作通过外部接口，如XCAP GET操作/SIP订阅通知机制来实现。

互通选择功能对融合用户信息的使用，其具体流程包括：

步骤801、互通选择功能接收到互通请求消息，进行步骤2的操作。

步骤802、互通选择功能实体通过内部或外部接口向融合用户信息感知实体发起目标用户的融合用户信息查询请求，进行步骤803的操作。

步骤803、融合用户信息感知实体判断针对目标CPM用户是否发起了信息感知操作的过程，如果没有触发则进行步骤804操作；如果触发了信息感知操作则进行步骤805的操作。

步骤804、触发融合用户信息感知实体发起信息感知操作，然后进行步骤805处理操作。

步骤805、融合用户信息感知实体将目标用户的融合用户信息返回给互通选择功能实体，进行步骤806处理操作。

步骤806、互通选择功能根据互通方案的计算逻辑，解析相关的用户信息内容，如非CPM用户联系地址、互通相关的用户偏好等，计算互通选择方案。

步骤807、互通选择功能结合计算出来的互通选择方案选择非CPM业务对应的互通功能进行业务互通尝试。

3)应用控制功能对融合用户信息的使用

应用控制功能在提供VAS应用能力的同时，CPM用户的相关状态变化对VAS增值业务的业务逻辑执行存在影响。在CPM VAS相关需求中体现为应用控制功能对特定事件的支持，使VAS应用通过获取CPM用户状态变化的通知事件来调整业务逻辑。根据应用控制功能的部署方式，分为不同情况：如果应用控制功能部署在CPM参与功能中，则通过内部接口向融合用户信息感知实体订阅特定事件；如果应用控制功能部署在其他外部实体中，则通过外部接口，如SUBSCRIBE订阅通知机制向融合用户信息感知实体订阅特定事件。当接收到事件通知后，应用控制功能将相关通知提供给VAS应用完成业务逻辑执行控制过程。

应用控制功能对融合用户信息的使用，其具体流程包括：

步骤901、VAS应用针对特定CPM用户提供了增值业务，进行步骤902的操作。

步骤902、应用控制功能向融合用户信息感知实体订阅了特定事件，如CPM用户的当前注册状态、会话状态等，进行步骤903的操作。

步骤903、融合用户信息感知实体判断针对目标CPM用户是否发起了信息感知操作的过程，如果没有触发则进行步骤904操作；如果触发了信息感知操作则进行步骤905的操作。

步骤904、触发融合用户信息感知实体发起信息感知操作，然后进行步骤905处理操作。

步骤905、融合用户信息感知实体在相关CPM用户状态发生变化时向应用控制功能反馈相应的事件通知消息，进行步骤906处理操作。

步骤906、应用控制功能将特定事件反馈给VAS应用，进行步骤7处理操作。

步骤907、VAS应用根据通知事件类型调整向CPM用户提供的增值业务。

以下对本发明进行举例阐述。

实施例一：

CPM用户注册过程的第三方注册请求发送给CPM参与功能，触发融合用户信息感知实体针对该用户进行信息感知和信息融合的过程。

当CPM用户客户端向SIP/IP核心网络注册后，CPM用户就可以通过CPM客户端接入到CPM业务，在后续的CPM业务的交互过程中，CPM核心功能实体会不可避免地使用用户信息进行决策和业务控制。因此有必要在CPM用户注册完成后，触发对该CPM用户的融合用户信息感知过程。该触发过程重用了当前SIP/IP核心网络支持的第三方注册机制和订阅注册事件包的相关机制，并结合了向其他信息源订阅获取相关用户信息(如用户呈现状态、用户偏好信息等)的过程，以完成融合用户信息的感知过程。

首先由CPM用户发起向SIP/IP核心网的客户端注册过程，SIP/IP核心网络完成注册过程后向为CPM用户服务的CPM参与功能发送第三方注册请求。CPM参与功能向内部的融合用户信息参与功能查询是否触发过信息感知过程。如果没有发起对应用户的融合信息感知过程，则发起信息感知操作，向各个用户信息源进行信息的订阅和获取过程。

该第三方注册请求触发用户信息感知过程的整体处理逻辑包括：

步骤1001、CPM参与功能接收到SIP/IP核心网络发送的用户A的第三方注册请求。

这里，步骤1001的具体处理过程包括：如果内部的融合用户信息感知实体触发过用户A的信息感知过程，则转到步骤1004；如果内部的融合用户信息感知实体未触发过用户A的信息感知过程，则转到步骤1002。

步骤1002、融合用户信息感知实体发起针对用户A的信息感知过程。

这里，步骤1002的具体处理过程包括：融合用户信息感知实体通过订阅通知机制(SUBSCRIBE/NOTIFY)，构造SUBSCRIBE请求向SIP/IP核心网订阅reg事件包，获取用户A的注册状态信息；融合用户信息感知实体通过订阅通知机制(SUBSCRIBE/NOTIFY)，构造SUBSCRIBE请求向呈现使能者订阅presence事件包，获取用户A的呈现状态信息；融合用户信息感知实体通过订阅通知机制(SUBSCRIBE/NOTIFY)，构造SUBSCRIBE请求向XDM使能者订阅xcap-diff事件包，并在Request-URI中添加AUID参数来指示被订阅的XDMS类型，获取对应XDMS的XML文档中的用户信息。

步骤1003、融合用户信息感知实体将接收到的用户A的信息进行组织和存储。

这里，步骤1003的具体处理过程包括：融合用户信息感知实体动态接收到用户A的注册状态通知消息；融合用户信息感知实体动态接收到用户A的呈现状态通知消息；融合用户信息感知实体动态接收到用户A的XDMS的通知消息；融合用户信息感知实体将接收到的用户A的各种信息进行分类组织与存储。其中，用户A的XDMS的通知消息包括：融合地址簿中的联系地址、用户偏好信息、用户访问策略信息等。

步骤1004、结束本处理流程。

实施例二：

未注册的CPM用户作为CPM消息/CPM会话请求的目标用户，CPM参与功能触发融合用户信息感知实体针对目标用户进行用户信息感知和信息融合的过程。

当目标用户的CPM网络的CPM参与功能接收到一个CPM消息/CPM会话请求时，如果目标CPM用户当前未注册，则CPM参与功能需要根据CPM用户的相关信息，如用户偏好信息)，来决策进一步的动作，如CPM消息/CPM会话的互通、CPM消息的延迟发送、对CPM会话请求的拒绝操作等。因此，这种情况下有必要针对CPM消息/CPM会话请求的目标用户触发融合用户信息的感知过程。

当终止方网络的CPM参与功能收到CPM消息/CPM会话请求消息时，CPM参与功能首先向融合用户信息感知实体查询是否触发过针对目标用户的信息感知过程，如果触发过则直接获取相关信息进行决策；如果未触发过融合用户信息的感知过程，则触发信息感知过程，向目标用户的各个信息源订阅并获取相关信息，按照本技术方案提出的信息组织模型进行信息的组织和存储。待用户信息感知过程完成后，再基于所需用户信息进行下一步决策。

该目标用户为未注册CPM用户情况下触发用户信息感知过程的整体处理逻辑包括：

步骤1011、CPM参与功能代表未注册CPM用户A接收到CPM消息/CPM会话请求消息。

这里，步骤1011的具体处理过程包括：如果内部的融合用户信息感知实体触发过用户A的信息感知过程，则转到步骤1012；如果内部的融合用户信息感知实体未触发过用户A的信息感知过程，则转到步骤1013。

步骤1012、CPM参与功能通过内部接口获取到用户A的信息，并基于这些信息进行决策，然后转到步骤1016。

步骤1013、融合用户信息感知实体针对用户A发起信息感知过程。

这里，步骤1013的具体处理过程包括：融合用户信息感知实体通过订阅通知机制(SUBSCRIBE/NOTIFY)，构造SUBSCRIBE请求向SIP/IP核心网订阅reg事件包，获取用户A的注册状态信息；融合用户信息感知实体通过订阅通知机制(SUBSCRIBE/NOTIFY)，构造SUBSCRIBE请求向呈现使能者订阅presence事件包，获取用户A的呈现状态信息；融合用户信息感知实体通过订阅通知机制(SUBSCRIBE/NOTIFY)，构造SUBSCRIBE请求向XDM使能者订阅xcap-diff事件包，并在Request-URI中添加AUID参数来指示被订阅的XDMS类型，获取对应XDMS的XML文档中的用户信息。

步骤1014、融合用户信息感知实体将接收到的用户A的信息进行组织和存储。

这里，步骤1014的具体处理过程包括：融合用户信息感知实体动态接收到用户A的注册状态通知消息；融合用户信息感知实体动态接收到用户A的呈现状态通知消息；融合用户信息感知实体动态接收到用户A的XDMS的通知消息；融合用户信息感知实体将接收到的用户A的各种信息进行分类组织与存储。其中，用户A的XDMS的通知消息包括：融合地址簿中的联系地址、用户偏好信息、用户访问策略信息等。

步骤1015、CPM参与功能通过内部接口获取到用户A的信息，并基于这些信息完成决策过程。

步骤1016、结束本次处理流程。

实施例三：用户信息请求方向融合用户信息感知实体查询目标用户信息的请求，触发针对该目标用户的信息感知和信息融合过程。

当CPM参与功能中的融合用户信息感知实体接收到针对特定CPM用户的用户信息查询请求时，融合用户信息感知实体将本地用户信息仓库中该用户的信息发送给信息的请求方，信息请求方(如互通选择功能、应用控制功能等CPM使能者实体)将基于收到的用户信息完成决策过程。因此，这种情况下有必要针对被查询CPM用户触发融合用户信息的感知过程。其中，信息请求方包括：如互通选择功能、应用控制功能等CPM使能者实体。

当CPM参与功能内部的融合用户信息感知实体收到用户信息请求方查询特定CPM用户的信息请求消息时，CPM参与功能首先向融合用户信息感知实体查询是否触发过待查询用户的信息感知过程，如果触发过则直接将被查询的用户信息提供给信息请求方；如果未触发过融合用户信息的感知过程，则触发信息感知过程，向各个用户信息源订阅并获取相关信息，进行信息的组织和存储。待信息感知和融合过程完成后，再将被查询的用户信息提供给信息请求方。

该用户信息请求方触发用户信息感知过程的整体逻辑，其具体处理流程包括：

步骤1021、融合用户信息感知实体接收到其他实体查询用户A的用户信息的请求。

这里，步骤1021的具体处理过程包括：如果融合用户信息感知实体触发过用户A的信息感知过程，则进行步骤1022；如果融合用户信息感知实体未触发过用户A的信息感知过程，则进行步骤1023。

步骤1022、融合用户信息感知实体通过信息查询接口向信息请求方提供用户A的信息，然后转到步骤1026。

步骤1023、融合用户信息感知实体针对用户A发起信息感知过程，然后转到步骤1024。

这里，步骤1023的具体处理过程包括：融合用户信息感知实体通过订阅通知机制(SUBSCRIBE/NOTIFY)，构造SUBSCRIBE请求向SIP/IP核心网订阅reg事件包，获取用户A的注册状态信息；融合用户信息感知实体通过订阅通知机制(SUBSCRIBE/NOTIFY)，构造SUBSCRIBE请求向呈现使能者订阅presence事件包，获取用户A的呈现状态信息；融合用户信息感知实体通过订阅通知机制(SUBSCRIBE/NOTIFY)，构造SUBSCRIBE请求向XDM使能者订阅xcap-diff事件包，并在Request-URI中添加AUID参数来指示被订阅的XDMS类型，获取对应XDMS的XML文档中的用户信息。

步骤1024、融合用户信息感知实体将接收到的用户A的信息进行组织和存储。

这里，步骤1024的具体处理过程包括：融合用户信息感知实体动态接收到用户A的注册状态通知消息；融合用户信息感知实体动态接收到用户A的呈现状态通知消息；融合用户信息感知实体动态接收到用户A的XDMS的通知消息；融合用户信息感知实体将接收到的用户A的各种信息进行分类组织与存储过程。其中，用户A的XDMS的通知消息包括：融合地址簿中的联系地址、用户偏好信息、用户访问策略信息等。

步骤1025、融合用户信息感知实体通过信息查询接口向信息请求方提供用户A的信息。

步骤1026、结束本次处理流程。

实施例四：

用户信息感知过程中的信息融合过程

在上述实施例一～三描述的三种情况下，一旦触发融合用户信息感知实体发起针对目标用户的信息感知操作，则融合用户信息感知实体将针对所有的用户信息源发送信息获取的请求。该过程请分别参考实施例一、实施例二和实施例三中的感知操作流程的描述，针对不同类型的信息源按照对应说明的操作进行处理。

当来自于分布式用户信息源的用户信息到达融合用户信息感知实体后，该实体将针对目标用户进行信息的融合和存储过程。对用户信息的融合和存储过程的目的是去除分布式的独立信息源中的冗余用户信息，建立不同类别用户信息之间的关联关系，在出现信息冲突的情况下保持用户信息的一致性。

假设融合用户信息感知实体在针对用户Alice(sip：alice@cpm.com)发起信息感知过程后，收到了各个信息源返回的用户信息数据，信息内容如下所示：(1)SIP核心网发送的用户信息：包括用户地址、用户设备、可用业务、设备可用网络四方面的信息。以下是相关的文档实例：

①SIP/IP网络返回的注册状态通知消息，对应的文档实例内容如下表2所示：

表2

该文档实例表明：

用户Alice的地址为sip:alice@cpm.com

注册请求关联的联系地址为sip:alice@pc.cpm.com

注册设备1的UUID为f81d4fae-7dec-11d0-a765-00a0c91e6bf6

设备1的公有GRUU地址为sip:alice@cpm.com；gr＝hha9s8d-99a

设备1的私有GRUU地址为sip:8ffkas08af7fasklzi9@cpm.com；gr

②第三方注册请求的Contact头域包含的用户代理特性参数：

Contact:<sip:alice@pc.cpm.com>；audio；video；text

表明该设备1的用户代理能力为：支持视频、音频和文本。

③第三方注册请求消息体中包含的RDF文档，描述了设备和可用网络的属性，如以下表3所示：

表3

该文档实例表明：

Alice的注册设备1的屏幕大小为300X200；

设备1具有彩色显示能力；

设备1支持图像显示能力；

设备1支持的文本字符集为US-ASCII和URF-8。

(2)CPM参与功能内部维护的信息：当前CPM用户的CPM业务的会话状态：如当前无会话/会话进行中，假设当前Alice正在进行CPM会话，如以下表4所示。

表4

该文档实例显示的是Alice的当前会话状态，可以包括但不局限于以下会话内容：

会话标识号为：session1

会话类型为：1对1会话

会话参与者为：sip:marry@cpm.net

会话包含的媒体流信息为：音频

媒体流关联的设备为：urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

媒体流对应的设备端口号为：3822

使用的传输协议为：RTP

编码格式为：PCM

(3)用户偏好配置XDMS返回的用户偏好信息：通过sip:alice@cpm.com作为目标地址进行偏好查询，返回Alice对应的用户偏好配置文档组成的偏好集合。

当前对于偏好配置文档的具体格式还没有定义，以下文档实例仅作为一种参考文档格式。自定义的文档实例如下表5所示：

表5

该文档实例显示的是Alice的默认场景的偏好配置文档，可以包括但不局限于以下偏好内容：

通信能力：允许进行音频通信；

存储偏好：允许向消息存储器自动保存CPM会谈内容；

CPM消息处理偏好：对于到来的CPM消息进行延迟发送；

CPM会话邀请的处理偏好：允许接收CPM会话邀请消息；

互通处理偏好：允许进行与非CPM业务的互通。

表6

如以上表6所示，该文档实例显示的是Alice的“Home”场景下的偏好配置文档，可以包括但不局限于以下偏好内容：

通信能力：允许进行音频通信；

存储偏好：允许向消息存储器自动保存CPM会谈内容；

CPM消息处理偏好：允许接收CPM消息；

CPM会话邀请的处理偏好：允许接收CPM会话邀请消息；

互通处理偏好：不允许进行与非CPM业务的互通。

该场景对于UUID为f81d4fae-7dec-11d0-a765-00a0c91e6bf6的用户设备是激活场景。

(4)共享策略XDMS中返回的用户访问策略信息：通过sip:alice@cpm.com作为目标地址进行用户访问策略的查询，由多条用户访问规则组成用户访问策略，文档实例如下表7所示：

表7

该文档实例显示的是Alice的用户访问策略文档，由多个<rule>元素对应的用户访问规则构成，图中给出的规则表明：针对CPM业务，当请求发起方地址为tel:+43012349999或sip:percy.underwood@example.com时，应该自动拒绝相关CPM请求。

(5)共享配置XDMS中返回的用户地址信息，通过sip:alice@cpm.com作为目标地址进行用户配置信息查询，文档实例如下表8所示：

表8

该文档实例显示的是Alice的用户配置文档，Alice的可用地址除了sip:alice@cpm.com以外，还拥有+18586230743的通信地址。

(6)呈现使能者返回的呈现数据：通过sip:alice@cpm.com地址查询其呈现信息，包括用户地址、用户状态、可用业务、用户设备、设备可用网络等类型的用户信息。文档实例如下表9所示：

表9

该文档实例显示的是Alice的呈现信息文档，第一个tuple元素描述的是sip:alice@cpm.com地址对应的CPM业务，其中描述了CPM业务的会话状态、关联的设备UUID标识符，注册状态和是否被禁止使用等属性；第二个tuple元素描述的是+18586230743地址对应的短信业务。Person元素描述了Alice的当前用户状态，而device元素描述了设备标识符信息以及该设备对应的网络信息。

(7)融合地址簿返回的用户地址信息，通过sip:alice@cpm.com查询获得对应的地址簿信息。当前CPM-CAB的工作进展刚刚进行到体系架构的制定阶段，地址信息的描述格式尚未进行定义，以下给出一种自定义的参考格式，CAB文档实例如下表10所示：

表10

该文档实例显示的是Alice的CAB个人联系信息文档，Alice的可用地址除了sip:alice@cpm.com以外，还拥有Email：alice@yahoo.com的邮箱通信地址。

在获取上面的7个用户信息源的用户信息后，可以结合CPM环境下用户信息的分类方式对这些信息进行重新组织，同时还要体现出不同类别的用户信息之间的关联关系。将融合用户信息保存在融合用户信息感知实体的用户数据仓库中。用户数据仓库中的用户信息可以使用XML文档或数据库表等具体的数据存储和表示方式来实现，具体的信息融合计算过程请参看本发明1.2中“用户信息的融合过程”部分的内容说明。本发明在定义了用户信息组织模型的同时，并没有指定具体的信息存储方式，保留了信息存储实现过程的灵活性。

实施例五：

融合用户信息的查询和使用

融合用户信息感知模型的信息感知过程实现了在CPM业务环境中，对特定用户的用户信息感知、统一组织与存储过程，其目的是为相关的CPM使能者实体提供决策过程中的融合用户信息支撑能力。

融合用户信息的消费者是需要在决策过程中使用用户信息作为参考的CPM使能者实体。相关CPM使能者实体通过向融合用户信息感知实体进行查询来获取相关用户信息，一方面避免了向多用户信息源的信息交互过程，提高了信息使用的效率；另一方面获取的用户信息是经过信息组织和冗余信息处理的用户数据，提高了用户信息使用过程的信息关联和准确性。

本发明中将融合用户信息感知实体作为CPM参与功能中的内部实体，这样可以保证对用户信息使用最为频繁的CPM参与功能可以通过内部接口相对实时的获取用户信息来完成决策过程，提高了业务决策和执行过程的效率和决策准确性。

本实施例描述了如下场景：

假设CPM用户Alice对应的CPM地址为sip:alice@cpm.com，她使用移动终端设备1完成了注册过程。CPM用户Tom向Alice发起一个CPM会话邀请。为目标用户Alice提供服务的CPM参与功能在接收到CPM用户Tom发起的CPM会话邀请后，需要结合各种类型的用户信息，Alice的用户偏好、用户访问策略、用户注册状态、用户设备信息、用户呈现状态等信息来完成对CPM会话请求的决策处理过程。

CPM参与功能使用融合用户信息进行业务决策和控制的信息查询和使用过程，即针对CPM用户Alice的融合用户信息查询和使用的流程包括：

步骤1031、CPM参与功能在CPM用户Alice注册后，当接收到相应的第三方注册请求时，触发内部的融合用户信息感知实体发起针对CPM用户Alice的信息感知过程。具体过程参见实施例一中的描述。

步骤1032、融合用户信息感知实体向各个用户信息源发起具体的信息感知操作。具体过程参见实施例一中步骤1002的操作流程描述。

步骤1033、融合用户信息感知实体对各个信息源返回的用户信息进行统一的分类、组织和存储。具体过程参见实施例四中的描述。

步骤1034、CPM用户Tom向Alice发起一个CPM会话邀请，该请求消息到达CPM用户Alice本地CPM网络中的CPM参与功能。

步骤1035、CPM参与功能通过内部接口查询用户Alice，对应用户地址为sip:alice@cpm.com，的融合用户信息。

步骤1036、由于融合用户信息感知实体已经动态感知并维护了用户Alice的融合用户信息，因此在接收到信息请求的同时，融合用户信息感知实体可以通过内部接口立即向CPM参与功能提供用户Alice的实时融合用户信息。

步骤1037、CPM参与功能基于查询到的CPM用户Alice各方面的用户信息进行业务决策，该过程对应用不同的场景具有不同的决策流程，针对本场景的参考决策流程如下：

通过用户Alice的融合用户信息中的地址信息，CPM参与功能获知Alice已经注册；

通过用户Alice的融合用户信息中的业务信息，CPM参与功能获知Alice当前并没有进行CPM会话；

通过用户Alice的融合用户信息中的用户访问策略，CPM参与功能获知Alice允许Tom对自己发起CPM会话；

通过用户Alice的融合用户信息中的用户状态(心情、环境信息)，结合Alice的用户偏好信息，CPM参与功能获知用户Alice当前场景下允许进行CPM会话；

通过用户Alice的注册设备信息，CPM参与功能获取Alice的设备具备了进行CPM会话的能力；

综合上述信息决策过程后，CPM参与功能将向CPM用户Alice的设备发送CPM会话建立的请求消息。

注：如果发起融合用户信息查询请求的实体不是CPM参与功能或其内部实体，则上述流程中的5、6步骤对应于融合用户信息感知实体外部查询接口的查询操作；此外融合用户信息感知实体应该能够支持对部分类型用户信息的查询能力，允许CPM使能者实体仅仅获取其关注的用户信息。

综上所述，采用本发明具有以下优点：

(1)通过在CPM体系架构基础上，扩展定义融合用户信息感知模型框架，在实现对用户信息的全面而准确的感知能力的同时，能够去除多信息源之上的冗余信息，保证了信息的一致性。

(2)通过集中式的融合用户信息感知实体提供的单点信息查询能力，避免了用户信息请求方分别向多个信息源发起信息查询过程的复杂性，同时降低了部分网络负载，并保证了获取用户信息的相对实时性和高效性。

(3)通过定义统一的融合用户信息组织与存储模型，将分散在不同信息源之上的独立用户信息进行分类，并体现不同类型用户信息之间的关联关系，以基于完备的用户信息和关联关系保证决策过程的准确性，并能够提供具有用户信息上下文感知能力的智能业务体验。

(4)通过现有的CPM体系架构中的现有接口，完成用户信息的实时感知过程，并动态完成实时信息的融合计算操作。

(5)通过定义具体的融合用户信息计算流程和算法说明，实现对多信息源中用户信息的融合计算过程。

(6)通过融合用户信息感知实体向信息源的部分订阅和部分通知方式，能够动态维护本地用户信息的副本，在保证用户信息实时性和准确性的同时，有效的降低了网络负载。

(7)通过将融合用户信息感知实体作为CPM参与功能的内部实体，以保证CPM参与功能能够实时基于用户信息进行决策，同时利用CPM参与功能分布式部署的特点，避免成为网络瓶颈。

在此简单地对上述优点进行概括如下：

本发明的技术方案通过重用现有CPM体系架构中用户信息源，如支撑使能者、SIP/IP核心网的信息获取接口，在CPM使能者框架基础上扩展定义了集中式的融合用户信息模型架构和信息组织模型，在提高用户信息的相对实时性、完备性、准确性和信息关联性的同时，有效降低了多信息源信息收集过程的网络负载和复杂性，为扩展实现具备用户上下文信息感知能力的智能型CPM业务提供了信息支撑。

这里，以上涉及到的用户偏好配置以User Preference Profile表示，缩写为UPP；统一资源定位符以Unfiorm Resource Locator表示，缩写为URL。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。