专利名称：一种地址簿信息融合管理的方法及装置的制作方法
技术领域：
本发明涉及通信技术领域，尤其涉及一种地址簿信息融合管理技术。
背景技术：
为便于用户的通信需求，通常会采用地址簿管理用户的联系人信息。目前，由于用户在不同的通信应用场景下需要使用不同的地址簿获取相应的联系人信息，为此，用户需要设置不同形式并保存于不同位置的各种地址簿信息，例如终端设备中的地址簿、SIM(Subscriber Identity Model，客户识别模块卡)卡中的地址簿、业务应用中的地址簿以及ISP(Internet Service Provider，因特网业务供应者)提供的地址簿等等。因此，在通信网络中，将会存在大量的不同种类的位于不同位置的地址簿，不同的地址簿中通常保存着不同的地址簿信息，地址簿信息可以是联系人的各种信息，如联系人的联系电话、联系人的位置信息、联系人的个性化信息，等等。
在实现本发明的过程中，发明人发现现有技术中至少存在如下问题 针对上述位于不同位置的不同种类的地址簿无法统一进行集中有效的管理，使得用户无法统一管理更多的联系人信息，进而使得用户及其他实体无法方便、快捷地应用相应的地址簿信息。
发明内容
本发明的实施例提供了一种地址簿信息融合管理的方法及装置，以使得融合地址簿服务器可以获得更多的联系人信息，便于用户及其他实体应用相应的地址簿信息。
一种地址簿信息融合管理的方法，包括 检测到地址簿信息中的联系人信息发生变化； 根据设置的联系人信息更新方式从至少一个信息源获取所述联系人的更新信息； 根据获取的联系人的更新信息更新地址簿信息中的联系人信息。
一种融合地址簿服务器，包括 检测单元，用于检测地址簿信息中的联系人信息是否发生变化； 联系人信息获取单元，用于在所述检测单元检测到地址簿信息中的联系人信息发生变化后，根据设置的联系人信息更新方式获取至少一个信息源的联系人的更新信息； 信息更新单元，用于根据所述联系人信息获取单元获取的联系人信息更新本地址簿信息中的联系人的更新信息。
一种地址簿信息融合管理系统，包括 至少一个信息源，用于维护联系人信息，并发送维护的联系人信息； 融合地址簿服务器，用于集中管理用户的地址簿信息，该地址簿信息中记录着用户的联系人信息，以及用于检测到地址簿信息中的联系人信息发生变化后，根据设置的联系人信息更新方式从所述至少一个信息源获取联系人的更新信息，并根据获取的联系人的更新信息更新所述地址簿信息中的联系人信息。
一种共享活动xml文档管理服务器，包括 行为信息接收单元，用于接收应用服务器发送来用户使用业务应用的行为信息； 行为历史记录存储单元，用于根据所述行为信息接收单元接收到的行为信息存储联系人的行为历史记录信息，该行为历史记录信息包括行为历史记录的内容及对应的联系人信息。
由上述本发明的实施例提供的技术方案可以看出，本发明实施例中，由于通过融合地址簿服务器集中管理用户的联系人信息，且融合地址簿服务器可以方便地获取其他信息源的联系人信息，以获得更多的联系人信息，进而使得用户及其他实体能够非常方便地应用用户的联系人信息。
图1为本发明实施例提供的方法的处理过程示意图； 图2为本发明实施例提供的实施例一的处理过程示意图； 图3为本发明实施例提供的实施例二的处理过程示意图； 图4为本发明实施例提供的实施例三的处理过程示意图； 图5为本发明实施例提供的实施例四的处理过程示意图； 图6为本发明实施例提供的实施例五的处理过程示意图； 图7为本发明实施例提供的系统的结构示意图。
具体实施例方式 本发明实施例中，在对地址簿信息进行管理过程中包括在检测到地址簿信息中的联系人信息发生变化后，则根据设置的联系人信息更新方式从至少一个信息源获取所述联系人的更新信息；并根据获取的联系人的更新信息更新地址簿信息中的联系人信息。
进一步地，可以通过向信息源发送联系人信息订阅请求的广度，获取信息源回送的联系人的更新信息；或者，也可以通过向信息源发送联系人信息请求消息的方式，获取信息源回送所请求的联系人的更新信息。
本发明实施例中，还可以接收设置联系人信息更新方式的信息，以便于根据该更新方式的信息设置保存联系人信息更新方式，从而根据相应的联系人信息更新方式进行联系人的更新信息的获取。相应的设置联系人信息更新方式的信息具体可以承载于包含联系人信息的消息中发送，或者，也可以承载于单独用于设置更新方式的消息中发送。
具体地，本发明实施例中获取联系人的更新信息的方式可以为以下至少一种方式 方式一，在用户导入已有的地址簿，并发布联系人信息更新方式后，解析用户设置的联系人信息更新方式，并根据所述联系人信息更新方式从至少一个信息源请求获取联系人的更新信息或订阅联系人的更新信息； 方式二，在用户向地址簿添加新的联系人后，融合地址簿服务器解析用户对新添加联系人的联系人信息更新方式的设置，并根据用户设置的联系人信息更新方式从至少一个信息源请求获取联系人的更新信息或订阅联系人的更新信息。
具体地，本发明实施例可以建立相应的融合地址簿服务器，并设置相应的融合地址簿，该融合地址簿用于集中管理用户的地址簿信息，即记录着用户的联系人信息，其可以作为公共的标准的地址簿，以便于为用户提供一种可以为多种业务与多个设备使用的网络地址簿；可见，通过融合地址簿服务器中的融合地址簿可以为用户管理维护更多的联系人信息。
为便于应用，则需要该融合地址簿中能够保存更为丰富、全面的联系人信息，为此，本发明实施例中，融合地址簿服务器可以从一个或多个不同的信息源获取联系人信息，以使得融合地址簿中能够保存维护更多的联系人信息，从而便于各种业务及设备的应用，进而给用户带来较佳的业务应用体验。
对应的，相应信息源需要将自身维护的联系人信息作为联系人的更新信息发送给融合地址簿服务器，以便于更新融合地址簿服务器的地址簿信息中的联系人信息；其中，信息源具体可以根据融合地址簿服务器发来的订阅策略或发来的联系人信息请求消息，将自身维护的联系人信息作为联系人的更新信息发送给融合地址簿服务器。
进一步，融合地址簿服务器可以根据该联系人信息对应的用户的设置或要求更新本地保存的地址簿信息，例如，在用户向融合地址服务器中添加联系人信息时，融合地址簿服务器可以感知到该变化，并可以根据该联系人信息对应的用户的设置或要求，向其他维护有该添加的联系人的其他信息的信息源获取相应的更多的联系人信息。
在上述处理过程中，相应的融合地址簿服务器可以通过向信息源发送联系人信息订阅请求的方式，请求信息源按照订阅策略向该融合地址簿服务器发送联系人信息，以实现融合地址簿中的联系人信息的更新；或者，融合地址簿服务器也可以通过向信息源发送联系人信息请求消息的方式，请求信息源向该融合地址簿服务器发送请求的联系人信息，以实现融合地址簿中的联系人信息的更新，进一步地，相应的向信息源发送联系人信息请求消息可以为定时发送，也可以为非定时发送(如单次发送等)。
融合地址簿服务器还可以根据接收到的用于设置联系人信息更新方式的信息在本地设置保存相应的联系人信息更新方式的信息。具体地，用户可以将联系人信息更新方式的信息通过不同的方式发送给融合地址簿服务器，例如，可以承载于向融合地址簿服务器发送的包含联系人信息的消息中发给融合地址簿服务器，或者，还可以承载于向融合地址簿服务器发送独立的用于设置更新方式的消息中发给融合地址簿服务器，等等。
融合地址簿服务器收到相应的联系人信息更新方式后，则需要将相应的联系人信息更新方式保存于本地，以便于后续进行联系人信息更新操作过程中应用，相应的在本地保存所述联系人信息更新方式的过程可以采用但不限于以下任一种方式 方式一，在融合地址簿服务器的地址簿信息包含的联系人信息中定义一个元素，通过该元素表示用户是否希望通过获取或订阅的方式更新该联系人信息，以指示融合地址簿服务器是否需要进行该联系人信息的更新； 方式二，在融合地址簿服务器中，通过设置文件记录是否希望通过获取或订阅的方式更新地址簿信息中的各个联系人信息，以分别指示融合地址簿服务器是否需要进行对应的联系人信息的更新； 方式三，在融合地址簿服务器中，通过预定的存储空间统一记录是否希望通过获取或订阅的方式更新地址簿信息中的各个联系人信息，以指示融合地址簿服务器是否需要进行地址簿信息中维护的联系人信息的更新，该方式三下，相应的设置对地址簿信息中的所有联系人信息有效。
本发明实施例中，相应的信息源可以包括远端的融合地址簿服务器、共享档案xml文档管理服务器或共享活动xml文档管理服务器中的至少一项，当然，也可以为其他维护着联系人信息的服务器。
其中，在共享活动xml文档管理服务器中存储的联系人信息可以包括联系人的行为历史记录信息，该行为历史记录信息包括行为历史记录的内容及对应的联系人信息；进一步地，相应的联系人的行为历史记录信息还可以包括行为历史记录的发生时间、行为历史记录的来源、行为历史记录对应的行为的受关注程度或者对该行为历史记录的评论中的至少一项。
本发明实施例中，当融合地址簿服务器完成相应的地址簿信息中的联系人信息的更新操作后，还可以通知用户，以便于用户可以获知其在融合地址簿服务器中维护的联系人信息更新情况。
本发明实施例提供的融合地址簿服务器获取联系人信息的实现方案的具体应用过程可以参照图1所示，即融合地址簿服务器检测到变化，便可以根据用户的设置对变化进行响应。
相应的处理过程具体可以包括以下步骤 步骤101，融合地址簿服务器检测到地址簿信息(即融合地址簿中的信息)发生变化； 融合地址簿服务器检测到的变化可以但不限于为用户导入地址簿到融合地址簿中，或者，用户添加新的联系人到融合地址簿中，或者，用户删除、修改融合地址簿中的联系人信息，等等； 步骤102，融合地址簿服务器解析用户设置的联系人信息更新方式，判断是否需要对变化进行响应，若需要，则执行步骤103，否则，该融合地址簿服务器不对变化做响应； 相应的用户设置联系人信息更新方式可以为用户是否需要服务器在检测到变化以后进行响应，以及在进行响应的情况下如何响应，该联系人信息更新方式具体可以通过以下任一方式进行设置 (1)预先将联系人信息更新方式设置于融合地址簿服务器中，例如，预先设置针对新导入或添加到融合地址簿信息中的联系人对应的联系人信息更新方式，等等； 具体可以通过预先发送的消息向融合地址簿服务器进行相应的联系人信息更新方式的设置； (2)在更新融合地址簿服务器中的信息的过程中，对更新过程中涉及的联系人设置相应的联系人信息更新方式，例如，可以指定导入的多个联系人信息中的某一个或多个联系人需要再进行后续的联系人信息的更新操作； 具体可以将相应的联系人信息更新方式与更新融合地址簿服务器中的联系人的信息一并发送给融合地址簿服务器，例如，将用户设置的联系人信息更新方式写入携带新增联系人信息的消息中发送给融合地址簿服务器；或者，也可以将相应的联系人信息更新方式通过一条专用于设置联系人信息更新方式的消息发送给融合地址簿服务器。
对于用户设置的联系人信息更新方式，可以在融合地址簿服务器中维护相应的联系人信息更新方式，融合地址簿服务器维护该联系人信息更新方式过程中可以采用以下任一方式实现 (1)在融合地址簿服务器的融合地址簿的联系人信息存储格式中定义表示用户是否要获取或订阅此联系人的信息的元素； (2)在融合地址簿中创建一个存储用户获取或订阅联系人信息相关的设置文件，该设置文件与联系人信息存储文件对应，即两个文件中的联系人一一对应，设置文件仅存储用户是否想获取或订阅的联系人的信息，联系人信息存储文件存储该联系人自身的各种信息，如姓名住址等； (3)在融合地址簿服务器中开辟用户设置的存储空间，用户可以在该存储空间中发布用户设置的联系人信息更新方式的信息。
对于部分联系人信息更新方式信息也可以不在融合地址簿服务器中维护，如联系人信息更新方式仅对某一个或多个联系人有效，且融合地址簿服务器收到相应的联系人信息更新方式后便可以完成相应更新处理操作； 可选地，本发明实施例中还可以设置当融合地址簿服务器完成相应的更新操作后，是否需要将更新结果通知给用户。
步骤103，融合地址簿服务器根据用户设置的联系人信息更新方式，从相关的信息源获取或订阅联系人的信息。
相应的信息源可以但不限于包括远端融合地址簿服务器R-CAB Server(Remote ConvergedAddress Book Server)、共享档案xml文档管理服务器Shared Profile XDMS以及共享活动xml文档管理服务器Shared Activity XDMS，等等； 在该步骤中，融合地址簿服务器可以向各信息源发送信息获取指令来得到相应的联系人的信息，如HTTP GET(超文本传输协议获取)的方式；或者，融合地址簿服务器也可以通过向各信息源订阅相应的联系人的信息的方式获取联系人的信息，例如，向各信息源发送订阅命令，实现针对某联系人信息的订阅，例如，采用SIP的订阅通知机制实现。
上述处理过程，对于用户删除联系人及修改联系人信息等情况，融合地址簿服务器也可以根据用户设置的联系人信息更新方式进行响应，例如，若用户删除了某个联系人，且融合地址簿服务器已经订阅了该联系人的信息，则融合地址簿服务器可以取消相应的订阅关系，若用户修改了某个联系人的信息(如在该联系人的信息中添加了新的统一资源标识URI)，则融合地址簿服务器可以根据用户设置的联系人信息更新方式针对该新的URI进行信息的获取或订阅。
为便于对本发明实施例的理解，下面将结合附图对本发明实施例的具体应用进行详细说明。
实施例一 在该实施例一中，将以归属融合地址簿服务器H-CAB Server(home Converged Address BookServer)从R-CAB Server获取信息为例进行说明，即在该实施例一中将说明H-CAB Server在用户导入地址簿事件的触发下，向R-CAB Server订阅联系人信息的处理过程。
假设用户A为CAB(Converged Address Book)业务的签约用户，其会话初始协议的统一资源标识SIP URI为sip:a@example.com，目前，该用户A已经将相应的地址簿导入到H-CAB Server中，并希望向R-CAB Server订阅之前已经导入地址簿中的部分联系人(如联系人B、C、E等)的信息。
在上述场景下，相应的H-CAB Server获取联系人的信息的过程如图2所示，具体可以包括以下步骤 步骤201，H-CAB Server导入用户的某信息源的地址簿信息，如用户在终端上以及应用中的地址簿等； 步骤202，用户A向H-CAB Server发送消息，以设置相应的联系人信息更新方式为需要H-CAB Server订阅导入的地址簿中的联系人的信息； 相应的联系人信息更新方式具体可以通过HTTP PUT命令设置于H-CAB Server中，相应的设置方式可以包括以下任一方式 方式一在CAB的联系人信息存储格式中定义表示用户是否要获取或订阅该联系人的信息的元素，若CAB采用xml的格式存储联系人信息，则包含联系人信息更新方式的CAB中的联系人信息可以表示为以下形式 <contact id＝″a″> <fullname>Jim Smith</fullname> <displayname>fish</displayname> <address> <email>jimmy@huawei.com</email> <phone>0755-28786876</phone> <sipuri>sip:jimmy@example.com</sipuri> <homeadd>Shenzhen nanshan district</homeadd> </address> <hasic> <birthday>19480923</birthday> <description>cool man</description> </basic> <extended> <hobbies>sports</hobbies> </extended> <webresource> <homepage>http://www.mycooo.com/jimmy</homepage> <blog>http://www.blogcn.com/jimmy</blog> </webresource> <getmore-setting active＝“no”> </getmore-setting> <subscribe-setting active＝“yes”> </subscribe-setting> </contact> 其中，相应的带下划线的黑体字部分用于表示联系人信息更新方式，具体地，<getmore-setting>元素表示用户是否想获取该联系人的更多信息，如相应的active(激活)属性值为yes表示需要获取，为no表示不需要获取；另一个元素<subscribe-setting>表示用户是否想订阅该联系人的信息，如相应的active属性值为yes表示需要订阅，为no表示不需要订阅。
与该设置方式一对应的，在设置的联系人信息更新方式的过程中，用户A发送的用于进行设置操作的HTTP PUT消息可以如下所示 接收到该消息的H-CAB Server便可以根据消息中的内容，对在CAB的联系人信息存储格式中定义表示用户是否要获取或订阅该联系人的信息的元素进行设置，以表示H-CAB Server是否需要获取或订阅该联系人的信息； 方式二在CAB中创建一个存储用户获取或订阅联系人信息的设置文件，该设置文件与联系人信息存储文件对应，两个文件中的联系人一一对应，其中，设置文件仅存储联系人信息更新方式，即用户是否想获取或订阅这个联系人的信息，联系人信息存储文件则用于存储联系人自身的各种信息，如姓名、住址等； 若CAB采用xml格式存储该设置文件，则设置文件可以为 <contact id＝″sip:b@huawei.com″> <getmore-setting active＝“no”> </getmore-setting> <subscribe-setting active＝“yes”> </subscribe-setting> </contact> 其中，两个子元素的含义及作用与方式一中相应子元素的含义和作用相同，故在此不再赘述。
与该设置方式二对应的，在设置联系人信息更新方式的过程中，用户A发送的用于设置操作的HTTPPUT消息的格式可以如下所示 接收到该消息的H-CAB Server便可以根据消息中的内容，对设置文件的内容进行设置，表明H-CABServer是否需要获取或订阅某联系人的信息。
上述处理过程中，仅以用户A通过HTTP PUT消息对联系人B的联系人信息更新方式进行设置的处理过程为例进行了描述，同样地，对联系人C及联系人E的联系人信息更新方式的设置操作也可以通过上述处理过程实现，在此不再一一详述。
在该步骤中，用户A还可以设置是否需要H-CAB Server在完成相应的联系人信息更新后将更新的结果通知给用户A，具体地可以在上述方式一的联系人信息中添加另一个元素<update_notify>，以表示用户A是否需要H-CAB Server将联系人信息的更新结果通知给自己，例如，其active属性值为yes表示需要通知，为no表示不需要通知；或者，也可以在方式二的设置文件的每个联系人对应的设置中添加该元素<update_notify>。或者，若H-CAB Server具有用户设置的存储空间，则用户A可以在H-CAB Server的该存储空间中发布是否将联系人信息的更新结果通知用户A的用户设置，此时，相应的用户设置信息可以适用于所有联系人信息的更新，其可以采用xml格式将设置的信息写入到存储空间中，相应的xml格式的设置信息如下所示 <update_notify active＝”yes”> <update_notify>； 步骤203，H-CAB Server向用户A返回确认200OK消息，表示确认收到用户A发来的设置消息； 步骤204，H-CAB Server解析用户A设置的联系人信息更新方式，确定用户A希望订阅联系人B、C和E的信息，且希望H-CAB Server能够将更新的结果通知给自己。
步骤205，H-CAB Server在R-CAB Server上发布订阅联系人信息的设置，例如，可以通过HTTP PUT命令发布相应的设置； 若设置文件采用xml格式，且H-CAB Server在R-CAB Server上已经创建的设置文件如下 <？xml version＝″1.0″encoding＝″UTF-8″？> <cabsub_settings xmlns＝″urn:oma:params:xml:ns:cab:cabsub_settings″> <entity id＝“sip:a@example.com”> <subscription active＝”yes”></subscription> <sub_persons> <person id＝“f@examplel.com> <person id＝“g@examplel.com> </sub_persons> <sub_elements> <email>true</email> <sipuri>true</sipuri> <homepage>true</homepage> </sub_elements> </entity> ...... </cabsub_settings> 则H-CAB Server发送的HTTP PUT消息可以如下所示 在该步骤205中，H-CAB Server可以根据每个联系人SIP URI的宿主部分(如“huawei.com”等)，所述的宿主部分是指该联系人SIP URI所在的设备或服务器，将订阅请求发送到该宿主部分对应域的维护有该联系人信息的服务器，另外，SIP/IP Core(基于SIP的IP核心网)通过DNS(域名服务)等域名解析系统将H-CAB Server的订阅请求路由到各个R-CAB Server。
步骤206，R-CAB Server可以对收到的H-CAB Server发送来的订阅请求进行相应的授权检查，并根据联系人B设置的策略，确认用户A是否在联系人B设置的授权订阅列表中，即是否允许用户A通过H-CABServer订阅联系人B的信息，并在鉴权通过后向H-CAB Server返回订阅请求的处理结果； 若确定不允许本次订阅请求，则如图2的步骤206所示，相应的R-CAB Server将向H-CAB Server返回禁止订阅403Forbidden消息，以表示该订阅请求无法实现。
可选地，在步骤206中，R-CAB Server也可以按照信息安全处理过程中常用的信任机制对用户A进行鉴权，该信任机制是指H-CAB Server信任用户A，R-CAB Server信任H-CAB Server，则R-CAB Server信任用户A，采用该信任机制，则R-CAB Server仅需要对H-CAB Server进行鉴权即可，对于用户A的鉴权操作则由H-CAB Server完成。
步骤207，H-CAB Server收到R-CAB Server返回的消息后，将订阅的结果通知给用户A； 具体可以采用发送SIP消息(SIP MESSAGE)的方式向用户A发送通知，此时，若H-CAB Server收到的是R-CAB Server返回的禁止订阅403Forbidden消息，则相应的SIP MESSAGE的格式可以如下所示 MESSAGE sip:a@example.com SIP/2.0 ViaSIP/2.0/TCP client.example.com；branch＝z9hG4bK776sgdkse Max-Forwards70 Fromsip:h-cab.example.com；tag＝49583 Tosip:a@example.com Call-IDasd88asd77a@1.2.3.4 CSeq1MESSAGE Content-Typetext/plain Content-Length51 You can not subscribe B’s information from his cab/禁止从联系人B的CAB服务器订阅联系人B的信息。
通过上述SIP MESSAGE便可以通知用户A本次订阅处理结果。
步骤208，用户A收到相应的SIP MESSAGE后，获取相应的订阅处理结果，并向H-CAB Server返回确认200OK响应消息，完成本次处理过程。
实施例二 在该实施例二中，在导入地址簿操作的触发下，相应的H-CAB Server选择从共享档案文档管理服务器Shared Profile XDMS获取信息，并在用户导入地址簿方式的触发下进行联系人信息的更新操作。
如图3所示，在该实施例二中，相应的更新联系人信息的过程包括 步骤301，H-CAB Server导入用户的其他地址簿，包括用户在终端上以及应用中的地址簿； 步骤302，用户A(包含CAB客户端，CAB Client)向H-CAB Server发送消息，以设置相应的联系人信息更新方式，表明希望H-CAB Server获取导入的地址簿中某些联系人(如联系人B、C、E等)的更多的联系人信息； 具体可以通过HTTP PUT命令进行相应的联系人信息更新方式的设置，该HTTP PUT消息的具体格式可以为如下所示 通过该HTTP PUT命令便可以实现相应的联系人信息更新方式的设置，以便于用户A通过H-CABServer获取联系人B的更多的联系人信息，若用户A还想获得联系人C和E的更多的联系人信息，则也可以按照同样的方式也可对联系人C和E进行相应的联系人信息更新方式的设置，在此不再赘述； 或者，也可以通过一条HTTP PUT命令同时针对多个联系人进行联系人信息更新方式的设置，即通过一条HTTP PUT命令同时携带表示希望获取联系人B、C、E的更多的联系人信息的指示，从而可以通过一条消息完成相应的联系人信息更新方式的设置； 在该步骤中，用户A还可以设置要求H-CAB Server将更新的结果通知给自己的信息，以便于用户A可以获知相应的信息更新结果。
步骤303，H-CAB Server收到相应的HTTP PUT命令，向用户A返回确认200OK消息，表示收到用户A的针对联系人信息更新方式的设置消息。
步骤304，H-CAB Server解析用户A发来的设置消息的内容，确定用户A希望获取联系人B，C，E的更多的联系人信息。
步骤305，H-CAB Server向Shared Profile XDMS发送命令以请求获取联系人B、C、E的更多的联系人信息； 具体地，可以采用发送HTTP GET消息的方式进行联系人B、C、E的更多信息的获取，相应的HTTPGET消息的格式可以如下所示 通过上述HTTP GET消息，H-CAB Server便可以向Shared Profile XDMS请求获取联系人B的用户文档user profile；另外，对于联系人C和联系人E的用户文档user profile则同样可以通过包含不同内容的HTTP GET消息进行获取，在此将不再赘述。
步骤306，Shared Profile XDMS收到相应的HTTP GET消息后，便可以向H-CAB Server返回200OK消息，在该返回200OK消息中便包含了联系人B的信息(如联系人B的用户文档user profile等)； 相应的200OK消息的具体格式可以如下所示 在该步骤306中，Shared Profile XDMS可以按照信息安全处理过程中常用的信任机制对用户A进行鉴权，即H-CAB Server信任用户A，Shared Profile XDMS信任H-CAB Server，则Shared Profile XDMS信任用户A。
步骤307，H-CAB Server收到Shared Profile XDMS返回的200OK消息后，则根据预先的设置将更新结果通知到用户A； 相应的，可以通过SIP MESSAGE进行通知，此时，该SIP MESSAGE的具体格式可以如下所示 MESSAGE sip:a@example.com SIP/2.0 ViaSIP/2.0/TCP client.example.com；branch＝z9hG4bK776sgdkse Max-Forwards70 Fromsip:h-cab.example.com；tag＝49583 Tosip:a@example.com Call-IDasd88asd77a@1.2.3.4 CSeq1 MESSAGE Content-Typeapplication/updatelog+xml Content-Length...... <？xml version＝″1.0″encoding＝″UTF-8″？> <updatelog xmlns＝″urn:oma:params:xml:ns:updatelog″> <person id＝”sip:b@example.com”> <update><displayname>Bob</displayname>….. </update> <add><hobbies>Butterfly Collection</hobbies> ...... </add></person> </updatelog> 其中，<person>元素表示对相应联系人的信息更新记录，<update>子元素表示更新的信息，<add>子元素则表示增加的信息。
步骤308，用户A收到上述SIP MESSAGE后，向H-CAB Server返回200OK消息，完成相应的处理过程。
实施例三 该实施例三中，在导入地址簿操作的触发下，H-CAB Server从Shared Activity XDMS获取信息，该Shared Activity XDMS中记录的信息包括用户的行为历史记录，其为记录用户在应用上的行为历史记录的网络存储器，相应的应用可以包括web应用以及呈现、定位、游戏、GSSM(General ServiceSubscription Management，综合业务订阅管理)、BCAST(Mobile Broadcast Services，移动广播业务，)，等等。
在Shared Activity XDMS中存储的用户(也可以称为联系人)的行为历史记录可以采用xml格式保存，其具体可以包括如下信息 (1)<user-activity>元素，用于表示记录的为用户的行为历史记录； (2)<user>元素，用于表示某个用户的行为历史记录； 其中，该<user>元素还可以包括 (2-1)<uri>子元素，用于标识是用户的身份标识信息，即行为历史记录的内容对应的联系人信息； (2-2)<activity>子元素，用于表示用户的某个行为历史记录，用户的一个行为历史记录可以对应一个该<activity>子元素； 该<activity>子元素具体可以包括 <application>子元素，用于表示用户行为历史记录所在应用的标识信息，以区分用户的多个不同的行为历史记录； <time>子元素，用于表示用户行为历史记录发生的时间信息； <description>子元素，用于描述用户的具体行为历史记录； <link>子元素，用于表示该行为历史记录的来源，即提供原始行为历史记录的链接。
可选地，该<activity>子元素具体还可以包括 <popular>子元素，用于表示用户的该行为历史记录是否受到许多关注； <comments>子元素，用于列举应用中的其他用户对该用户的行为历史记录的评论。
以下给出一个具体的例子，即用户sip:b@example.com在Shared Activity XDMS中的行为历史记录可以如下所示 <user> <uri>sip:b@example.com</uri> <activity id＝”a”> <application>mycooo</application> <time>20080304pm14:00</time> <description>upload a beautiful photo”flower.gif”</description> <link>www.mycooo.com\b</link> <popular>very popular</popular> </activity> <activity id＝”b”> <application>xunlei</application> <time>20080310am10:25</time> <description>upload a movie”Yangse River No.7.rm”</description> <link>www.xunleikankan.com</link> <comments>It’s great！</comments> </activity> ...... </user> 基于上述Shared Activity XDMS中记录的信息，H-CAB Server获取相应的联系人信息的处理过程如图4所示，具体可以包括 步骤401，H-CAB Server导入用户的其他地址簿，相应的地址簿可以包括用户在终端上以及应用中的地址簿； 步骤402，H-CAB Server解析用户设置的联系人信息更新方式； 在该步骤402之前，用户已经进行了相关联系人信息更新方式的设置，即已经设置了需要在H-CABServer导入地址簿以后，从Shared Activity XDMS中订阅导入的地址簿中所有联系人的更多信息。
步骤403，H-CAB Server向Shared Activity XDMS订阅联系人的信息； 由于Shared Activity XDMS中记录了联系人B的信息，故H-CAB Server向联系人B的宿主服务器Shared Activity XDMS订阅联系人B的信息，具体可以通过SIP SUBSCRIBE(SIP订阅)消息进行订阅，此时，相应的SIP SUBSCRIBE消息的具体格式可以如下所示 Shared Activity XDMS收到相应的SIP SUBSCRIBE消息后，可以按照信息安全处理过程中常用的信任机制对用户A进行鉴权，即H-CAB Server信任用户A，Shared Activity XDMS信任H-CAB Server，则Shared Activity XDMS信任用户A； 这样，用户A便通过H-CAB Server实现了向Shared Activity XDMS订阅联系人B的信息的操作。
步骤404，当Shared Activity XDMS确定记录的联系人B的信息发生变化，则可以通过SIP NOTIFY(SIP通知)消息将发生变化后的联系人B的信息通知给H-CAB Server，SIP NOTIFY消息的具体格式可以如下所示 步骤405，H-CAB Server收到Shared Activity XDMS通过SIP NOTIFY消息发来的更新后的联系人B的信息后，则将相应的更新结果通知给用户A； 该步骤中，具体可以采用SIP MESSAGE向用户A发送通知，相应的SIP MESSAGE消息的格式可以如下所示 MESSAGE sip:a@example.com SIP/2.0 ViaSIP/2.0/TCP client.example.com；branch＝z9hG4bK776sgdkse Max-Forwards70 Fromsip:h-cab.example.com；tag＝49583 Tosip:a@example.com Call-IDasd88asd77a@1.2.3.4 CSeq1MESSAGE Content-Typetext/plain Content-Length79 Your contact B upload a picture”me.jpeg”at 20080308am1026on www.facebook.com. 步骤406，用户A收到H-CAB Server发来的SIP NOTIFY消息后，向H-CAB Server返回确认200OK消息。
实施例四 在该实施例四中，将对用户A向H-CAB Server中添加新联系人的的实现过程进行说明。其中，相应的其他信息源对用户的鉴权以及用户A对H-CAB Server的更新通知的设置已经完成。
如图5所示，相应的添加新联系人的处理过程可以包括 步骤501，用户A向H-CAB Server发送消息，以便在CAB中增加一个新的联系人B，并令H-CAB Server向其他信息源订阅联系人B的信息； 用户A可以通过HTTP PUT命令请求在H-CAB Server中添加新的联系人B，HTTP PUT命令的消息体中携带联系人B的已知信息； 相应的用户A还可以通过以下任意方式设置在添加了联系人B的信息以后的联系人B采用的联系人信息更新方式，该联系人信息更新方式表明是否需要H-CAB Server获取或订阅联系人B的信息 方式一 将联系人B的信息与用户A设置的联系人信息更新方式通过HTTP PUT命令传送至H-CAB Server，即将用户A设置的联系人信息更新方式写入携带联系人B信息的消息体内；假设用户A的SIP URI为sip:a@example.com，且用户A仅知道用户B的SIP URI为sip:b@huawei.com，则相应的HTTP PUT消息的格式可以如下所示 方式二 若需要在联系人信息的格式中定义表示用户是否获取或订阅此联系人的信息的元素，则对应的用于设置相应的联系人信息更新方式的HTTP PUT消息的格式可以如下所示 方式三 在H-CAB Server中开辟了保存用户设置的联系人信息更新方式的存储空间，则用户A可以在H-CABServer中的该存储空间内发布相应的用户设置的联系人信息更新方式；假设H-CAB Server采用xml格式的xml文件存储用户设置的联系人信息更新方式，则相应的包含联系人信息更新方式的内容xml文件具体可以如下所示 <？xml version＝″1.0″encoding＝″UTF-8″？><cabadd_settings xmlns＝″urn:oma:params:xml:ns:cab:cabadd_settings″><entity> <getmore-setting active＝“no”> </getmore-setting> <subscribe-setting active＝“yes”> </subscribe-setting></entity> </cabadd_settings> 与H-CAB Server的存储空间中存储的用户设置的联系人信息更新方式对应，可以采用的设置相应的联系人信息更新方式的HTTP PUT消息的格式具体可以如下所示 其中，通过上述方式一和方式二，用户A可以对不同的联系人进行不同联系人信息更新方式的设置，而通过方式三则可以对所有的联系人的联系人信息更新方式进行统一设置，即该设置后的联系人信息更新方式可以适用于用户添加的所有联系人。
步骤502，H-CAB Server收到H-CAB Server发送来的用于设置联系人信息更新方式的设置消息后，则返回200OK消息，以表示设置成功。
步骤503，H-CAB Server解析联系人B的信息以及用户A设置的联系人信息更新方式，存储联系人B的信息，并明确用户A希望向其他信息源订阅联系人B的信息。
步骤504，H-CAB Server向R-CAB Server发送订阅联系人B的信息的消息，以实现针对联系人B的订阅设置； 具体可以采用HTTP PUT消息进行订阅设置，该HTTP PUT消息的格式可以如下所示 步骤505，R-CAB Server收到H-CAB Server发送来的订阅设置的消息后，则返回200OK消息，以表示设置成功。
步骤506，当R-CAB Server中联系人B的信息变化时，R-CAB Server便可以通过SIP MESSAGE消息将联系人B的信息的变化情况通知给H-CAB Server； 相应的SIP MESSAGE消息的具体格式可以如下所示 MESSAGE sip:h-cab.example.com SIP/2.0 ViaSIP/2.0/TCP client.example.com；branch＝z9hG4bK776sgdkse Max-Forwards70 Fromsip:r-cab.huawei.com；tag＝49583 Tosip:h-cab.example.com Call-IDasd88asd77a@1.2.3.4 CSeq1MESSAGE Content-Typeapplication/info+xml Content-Length... <？xml version＝″1.0″encoding＝″UTF-8″？> <info xmlns＝″urn:oma:params:xml:ns:info″> <person id＝″sip:b@huawei.com”> <sipuri>bb@examplel.com</sipuri> <displayname>Amuda</displayname> </person> </info> 步骤507，H-CAB Server收到相应的更新后的联系人B的信息后，则返回200OK响应。
步骤508，H-CAB Server向Shared Profile XDMS发起订阅请求； 具体可以采用SIP SUBSCRIBE消息进行订阅，该SIP SUBSCRIBE消息的格式可以如下所示 步骤509，该Shared Profile XDMS收到H-CAB Server发来的订阅请求消息后，则当Shared ProfileXDMS中联系人B的信息发生变化时，便可以通过SIP NOTIFY消息将联系人B的信息的变化通知给H-CABServer； 该SIP NOTIFY消息的格式可以如下所示 步骤510，H-CAB Server向Shared Activity XDMS发起订阅请求； 该步骤中具体可以采用SIP SUBSCRIBE消息发起相应的订阅请求，相应的SIP SUBSCRIBE消息的格式可以如下所示 步骤511，Shared Activity XDMS收到H-CAB Server发来的订阅请求消息后，当Shared ActivityXDMS中联系人B的信息发生变化时，便可以通过SIP NOTIFY消息将联系人B的信息的变化情况通知给H-CAB Server； 相应的SIP NOTIFY消息的格式可以如下所示 需要说明的是，上述步骤504-507，步骤508、509，以及步骤510、511的执行时序并无限定，例如，也可以首先执行步骤508、509，之后再执行步骤504-507，或者，也可以首先执行步骤510、511，之后再执行其他步骤508、509或者步骤504-507。
实施例五 在该实施例五中，用户A设置H-CAB Server定时获取联系人信息，即H-CAB Server在定时装置的触发下到相应的信息源获取联系人信息。且其他信息源对用户的鉴权以及用户对H-CAB Server的更新通知的设置已经完成。
步骤601，H-CAB Server中的定时装置提示服务器到R-CAB Server以及Shared Activity XDMS中获取联系人的信息； 在步骤601之前，用户A已经设置相应的联系人信息更新方式为H-CAB Server定时获取联系人信息，进一步地，可以设置定时获取哪些联系人对应的联系人信息、用于获取相应联系人信息的至少一个信息源以及获取联系人信息的时间间隔，等等。
具体设置相应信息的实现方式可以包括可以在联系人信息中添加一个元素<time-get>，用于表示用户A是否需要通过H-CAB Server定时获取该联系人的信息，其active属性值为yes表示需要定时获取，为no则表示不需要定时获取；或者，也可以在联系人的设置文件中的每个联系人设置中添加该元素；再者，假设H-CAB Server中具有用户设置的联系人信息更新方式的存储空间，则用户A可以在H-CABServer中的相应存储空间发布相应的联系人信息更新方式，例如，在存储空间中可以采用如下的xml格式表示该联系人信息更新方式为 <update_notify active＝”yes”> <persons> <person id＝“sip:b@huawei.com”> <person id＝“sip:c@chinamobile.com”> <person id＝“sip:e@chinaunion.com”> </persons> <source> <cab>true</cab> <activity>true</activitv> </source> <interval> <day>10</day> </interval> <update_notify> 其中，<update_notify>，用于表示用户定时获取的设置，具体可以包括<persons>，用于表示需要定时获取更多信息的联系人，<source>，用于表示定时获取联系人的信息的信息源，<interval>，用于表示定时获取更多信息的时间间隔； 步骤602，H-CAB Server确定符合定时获取条件时，则向R-CAB Server请求获取联系人B、C、E的信息； 具体可以采用SIP SUBSCRIBE消息进行相应联系人的信息的获取，此时，该SIP SUBSCRIBE消息的格式可以如下所示 步骤603，R-CAB Server收到相应的SIP SUBSCRIBE消息后，则可以通过SIP NOTIFY消息将联系人B的信息反馈给H-CAB Server； 相应的SIP NOTIFY消息的格式具体可以如下所示 采用上述步骤602和步骤603的处理方式便可以继续进行联系人C和E的信息的获取操作，在此不再赘述。
步骤604，H-CAB Server向Shared Activity XDMS请求获取联系人B、C、E的信息； 具体可以通过HTTP GET消息进行获取，此时，相应的HTTP GET消息的格式具体可以如下所示 步骤605，Shared Activity XDMS收到相应的HTTP GET消息后，向H-CAB Server返回200OK响应，响应中包含其需要获取的联系人的信息； 该200OK响应消息的格式具体可以如下所示 需要说明的是，上述步骤602、603与步骤604、605之间并无时序限制，其可以以任意的执行顺序进行。
本领域普通技术人员可以理解，上述各个本发明实施例中包含的全部或部分步骤可以通过程序指令相关的硬件实现，其中，相应的程序可以存储于计算机可读取存储介质中，该存储介质可以但不限包括ROM、RAM、磁盘或光盘等等。
本发明实施例还提供了一种地址簿信息融合管理系统，其具体实现结构如图7所示，主要包括 至少一个信息源，用于维护联系人信息，并发送维护的联系人信息；相应的信息源可以包括远端的融合地址簿服务器、共享档案xml文档管理服务器或共享活动xml文档管理服务器中的至少一项。
融合地址簿服务器，用于集中管理用户的地址簿信息，该地址簿信息中记录着用户的联系人信息，以及用于检测到地址簿信息中的联系人信息发生变化后，根据设置的联系人信息更新方式从所述至少一个信息源获取联系人的更新信息，并根据获取的联系人的更新信息更新所述地址簿信息中的联系人信息。
下面将结合附图分别对相应的信息源及融合地址簿服务器的具体实现结构进行说明。
(一)地址服务器，其可以作为相应的信息源 该地址服务器用于为融合地址簿服务器提供相应的联系人信息，如图7所示，该地址服务器可以包括 联系人信息维护单元，用于维护联系人信息； 信息发送单元，用于将所述联系人信息维护单元维护的联系人信息发送给融合地址簿服务器，以更新融合地址簿服务器的地址簿信息中的联系人信息，所述融合地址簿服务器用于集中管理用户的地址簿信息，该地址簿信息中记录着用户的联系人信息。
可选地，该地址服务器还可以包括发送触发单元，用于在根据融合地址簿服务器发来的订阅策略或发来的联系人信息请求消息确定需要发送联系人信息时，通知所述信息发送单元。
(二)融合地址簿服务器 如图7所示，该融合地址簿服务器具体可以包括 (1)检测单元，用于检测维护的用户的地址簿信息中的联系人信息是否发生变化； (2)联系人信息获取单元，用于在所述检测单元检测到维护的用户的地址簿信息中的联系人信息发生变化后，根据用户设置的联系人信息更新方式从至少一个信息源获取联系人信息； 为便于从信息源获取相应的联系人信息，该联系人信息获取单元具体可以但不限于包括以下任一单元 第一信息请求单元，用于向信息源发送联系人信息订阅请求，请求按照订阅策略从所述信息源获取联系人信息； 第二信息请求单元，用于向信息源发送联系人信息请求消息，请求从所述信息源获取联系人信息。
(3)信息更新单元，用于根据所述联系人信息获取单元收到的联系人信息更新本地保存的地址簿信息中的联系人信息。
在该融合地址簿服务器中还可以包括更新方式存储单元，用于获取并保存用户设置的联系人信息更新方式的信息，其中，获取相应的联系人信息更新方式的过程可以为直接通过设置接口获取用户在融合地址簿服务器处设置的联系人信息更新方式，也可以通过接收用户设备发来的消息中承载的信息获取相应的联系人信息更新方式。
其中，根据保存联系人信息更新方式的实现方式的不同，该更新方式存储单元具体可以但不限于包括以下任一单元 第一存储单元，用于在地址簿信息包含的联系人信息中定义一个元素，通过该元素表示是否希望通过获取或订阅的方式更新该联系人信息； 第二存储单元，用于通过设置文件分别记录是否希望通过获取或订阅的方式更新地址簿信息中的各个联系人信息； 第三存储单元，用于通过预定的存储空间统一记录是否希望通过获取或订阅的方式更新地址簿信息中的各个联系人信息。
可选地，在该融合地址簿服务器中还可以包括通知单元，用于在完成地址簿信息中的联系人信息的更新操作后，根据设置的信息确定是否向用户发送完成更新操作的通知，并在确定需要发送通知时，向用户发送更新操作的结果，以便于用户可以获知相应的更新结果。
本发明实施例还提供了一种共享活动xml文档管理服务器，仍参照图7所示，其具体可以包括 行为信息接收单元，用于接收应用服务器发送来用户使用业务应用的行为信息； 行为历史记录存储单元，用于根据所述行为信息接收单元接收到的行为信息存储联系人的行为历史记录信息，该行为历史记录信息包括行为历史记录的内容及对应的联系人信息。
可选地，在该行为历史记录存储单元存储的信息还可以包括行为历史记录所在应用的标识信息，行为历史记录的发生时间，行为历史记录的来源，行为历史记录对应的行为的受关注程度或者对该行为历史记录的评论中的至少一项。
可选地，在该共享活动xml文档管理服务器中，相应的行为信息接收单元还可以用于向呈现服务器订阅用户呈现信息中的行为信息，若所述被订阅的行为信息发生变化，则所述行为信息接收单元将会接收到呈现服务器发送来的变化后的行为信息；呈现服务器可以将行为信息的具体内容及对应的用户标识、发生时间等信息发送给该共享活动xml文档管理服务器，以便于将更为丰富的行为信息保存于历史记录存储单元中。
综上所述，本发明实施例提供的获取联系人信息的实现方案中，融合地址簿服务器检测到变化，并根据用户的设置进行响应，主要包括在用户导入已有地址簿到融合地址簿以及添加新的联系人到融合地址簿时，融合地址簿服务器根据用户的设置从相关的信息源获取或订阅联系人的信息。通过本发明提供的获取联系人信息的方法，能够让服务器主动地获取或订阅用户的联系人信息，不仅能够为用户搜集联系人的更多信息，丰富地址簿的内容，而且能够根据用户的设置，进行实时地更新，让用户掌握联系人的最新信息，给用户带来方便，除此之外，其他信息源对用户的鉴权也为联系人信息的安全提供保障。
以上所述，仅为本发明较佳的
具体实施方式
，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。
权利要求
1、一种地址簿信息融合管理的方法，其特征在于，包括
检测到地址簿信息中的联系人信息发生变化；
根据设置的联系人信息更新方式从至少一个信息源获取所述联系人的更新信息；
根据获取的联系人的更新信息更新地址簿信息中的联系人信息。
2、根据权利要求1所述的方法，其特征在于，所述根据设置的联系人信息更新方式从至少一个信息源获取所述联系人的信息具体包括
向信息源发送联系人信息订阅请求，使得请求信息源回送所述联系人的更新信息；
或者，
向信息源发送联系人信息请求消息，使得请求信息源回送所请求的联系人的更新信息。
3、根据权利要求1或2所述的方法，其特征在于，该方法还包括
接收设置联系人信息更新方式的信息；
根据该更新方式的信息设置保存联系人信息更新方式。
4、根据权利要求3所述的方法，其特征在于，所述设置联系人信息更新方式的信息具体包括
承载于包含联系人信息的消息中发送；
或者，
承载于单独用于设置更新方式的消息中发送。
5、根据权利要求3所述的方法，其特征在于，所述设置保存联系人信息更新方式包括
在地址簿信息包含的联系人信息中定义一个元素，通过该元素表示是否希望通过获取或订阅的方式更新该联系人信息；
或者，
通过设置文件分别记录是否希望通过获取或订阅的方式更新地址簿信息中的联系人信息；
或者，
通过预定的存储空间统一记录是否希望通过获取或订阅的方式更新地址簿信息中的联系人信息。
6、根据权利要求1或2所述的方法，其特征在于，所述的信息源包括以下至少一项
融合地址簿服务器、共享档案xml文档管理服务器或共享活动xml文档管理服务器。
7、根据权利要求1或2所述的方法，其特征在于，该方法还包括
当完成相应的地址簿信息中的联系人信息的更新操作后，根据设置的信息确定是否将更新结果通知用户。
8、根据权利要求1或2所述的方法，其特征在于，所述检测到地址簿信息中的联系人信息发生变化，根据设置的联系人信息更新方式从至少一个信息源获取联系人信息的过程具体包括以下至少一项
在用户导入已有的地址簿，并发布联系人信息更新方式后，解析用户设置的联系人信息更新方式，并根据所述联系人信息更新方式从至少一个信息源请求获取联系人的更新信息或订阅联系人的更新信息；
在用户向地址簿添加新的联系人后，融合地址簿服务器解析用户对新添加联系人的联系人信息更新方式的设置，并根据用户设置的联系人信息更新方式从至少一个信息源请求获取联系人的更新信息或订阅联系人的更新信息。
9、一种融合地址簿服务器，其特征在于，包括
检测单元，用于检测地址簿信息中的联系人信息是否发生变化；
联系人信息获取单元，用于在所述检测单元检测到地址簿信息中的联系人信息发生变化后，根据设置的联系人信息更新方式获取至少一个信息源的联系人的更新信息；
信息更新单元，用于根据所述联系人信息获取单元获取的联系人信息更新地址簿信息中的联系人的更新信息。
10、根据权利要求9所述的服务器，其特征在于，所述联系人信息获取单元包括
第一信息请求单元，用于向信息源发送联系人信息订阅请求，以从所述信息源获取联系人的更新信息；
或者，
第二信息请求单元，用于向信息源发送联系人信息请求消息，以从所述信息源获取联系人的更新信息。
11、根据权利要求9或10所述的服务器，其特征在于，还包括
更新方式存储单元，用于接收联系人信息更新方式，并设置保存联系人信息更新方式，以提供给所述联系人信息获取单元。
12、根据权利要求11所述的服务器，其特征在于，所述更新方式存储单元具体包括
第一存储单元，用于在地址簿信息包含的联系人信息中定义一个元素，通过该元素表示是否希望通过获取或订阅的方式更新该联系人信息；
或者，
第二存储单元，用于通过设置文件分别记录是否希望通过获取或订阅的方式更新地址簿信息中的联系人信息；
或者，
第三存储单元，用于通过预定的存储空间统一记录是否希望通过获取或订阅的方式更新地址簿信息中的联系人信息。
13、根据权利要求9或10所述的服务器，其特征在于，还包括
通知单元，用于在所述信息更新单元完成地址簿信息中的联系人信息的更新操作后，将更新结果通知用户。
14、一种地址簿信息融合管理系统，其特征在于，包括
至少一个信息源，用于维护联系人信息，并发送维护的联系人信息；
融合地址簿服务器，用于集中管理用户的地址簿信息，该地址簿信息中记录着用户的联系人信息，以及用于检测到地址簿信息中的联系人信息发生变化后，根据设置的联系人信息更新方式从所述至少一个信息源获取联系人的更新信息，并根据获取的联系人的更新信息更新所述地址簿信息中的联系人信息。
15、一种共享活动xml文档管理服务器，其特征在于，包括
行为信息接收单元，用于接收应用服务器发送来用户使用业务应用的行为信息；
行为历史记录存储单元，用于根据所述行为信息接收单元接收到的行为信息存储联系人的行为历史记录信息，该行为历史记录信息包括行为历史记录的内容及对应的联系人信息。
16、根据权利要求15所述的服务器，其特征在于，所述行为历史记录存储单元存储的信息还包括以下至少一项
行为历史记录所在应用的标识信息，行为历史记录的发生时间，行为历史记录的来源，行为历史记录对应的行为的受关注程度或者对该行为历史记录的评论。
17、根据权利要求15或16所述的服务器，其特征在于，所述的行为信息接收单元还用于向呈现服务器订阅用户呈现信息中的行为信息，若所述被订阅的行为信息发生变化，则所述行为信息接收单元将会接收到呈现服务器发送来的变化后的行为信息。
全文摘要
一种地址簿信息融合管理的方法及装置，其主要包括在检测到维护的用户的地址簿信息中的联系人信息发生变化后，便可以根据设置的联系人信息更新方式从至少一个信息源获取联系人信息，并根据获取到的所述联系人信息更新本地保存的地址簿信息中的联系人信息。可见，本发明实施例中，可以使得用户及其他实体能够非常方便地应用用户的联系人信息。
文档编号H04L29/08GK101557409SQ200810091948
公开日2009年10月14日 申请日期2008年4月9日 优先权日2008年4月9日
发明者蓉 邓, 贾江涛, 浩 王, 谦 孙 申请人:华为技术有限公司