專利名稱：提供聯系人信息的方法、系統及網絡設備的制作方法
技術領域：
本發(fā)明涉及通信技術領域，具體涉及提供聯系人信息的方法、系統及網 絡設備。
背景技術：
在很多情況下，用戶需要獲取其聯系人的一些相關信息，如聯系人的呈 現信息、聯系人的使用偏好信息等，從而使用戶在獲取了聯系人的相關信息后可以進行相應的操作；但是聯系人的相關信息是會改變的，因而用戶希望 在聯系人的相關信息發(fā)生改變時，能夠盡快獲得聯系人改變后的相關信息。 訂閱通知機制就是這樣一種解決異步通知問題的有效方法，其基本思想是這 樣的用戶可以向網絡上的一個服務器訂閱聯系人的相關信息，當聯系人的 相關信息發(fā)生改變時，服務器可以向用戶發(fā)送相應的通知消息。目前，訂閱通知機制在會話初始協議(SIP: Session Initiation Protocol) 服務中有著廣泛的應用，例如，在呈現業(yè)務中，；(見察者可以通過訂閱通知機 制獲得呈現體的呈現信息；為了支持訂閱通知機制，SIP進行了相應的擴展， 定義了會話初始協i義訂閱(SIP SUBSCRIBE )方法和會話初始協議通知(SIP NOTIFY)方法，在SIP中，訂閱通知機制的過程是這樣的訂閱者向通知者發(fā)送一個訂閱請求消息；訂閱請求消息中包括訂閱者的 相關信息，以及訂閱者想訂閱的聯系人的信息和訂閱者想訂閱的具體的信息 類型；通知者在收到訂閱請求消息后，向訂閱者返回一個確認訂閱請求的確認 消息；通知者在得知訂閱者想訂閱的聯系人的信息發(fā)生改變時，向訂閱者發(fā)送 一個通知消息，該通知消息包括相應的改變后的聯系人信息；訂閱者在收到改變后的信息后，向通知者返回一個確認信息；在實際應用中，訂閱者通過某個用戶設備(UE: User Equipment)上的用 戶代理(UA: User Agent)訂閱了通知者的呈現信息后，通知就會發(fā)送到該 UE的UA上。即使當多個UE使用了用戶的同 一個統一資源標識符(URI: Unified Resource Identify )向網絡注冊時，如果用戶只使用了其中的一個UE 訂閱了信息，那么通知消息只會發(fā)送到該UE上，而不會發(fā)送到其他的UE, 如果用戶想在其他的UE上也能夠收到通知消息，則需要在其他的UE上也訂 閱通知者的呈現信息。在實現本發(fā)明的過程中，發(fā)明人發(fā)現現有的技術方案至少存在如下缺陷 如果用戶需要在每個UE上都收到通知消息，則需要在每個UE上都訂閱通知 者的呈現信息，增加了用戶的處理負擔，給用戶帶來了不必要的麻煩，并且， 在UE上發(fā)送訂閱請求后，UE會定期的發(fā)送刷新訂閱請求，因而如果每個UE 都發(fā)送了訂閱請求，刷新訂閱請求的數量將會非常多，從而造成有限網絡資 源的極大浪費。發(fā)明內容本發(fā)明實施例的目的是提供一種提供聯系人信息的方法、系統及網絡設 備，使用本發(fā)明實施例提供的技術方案，可以使用戶只需要在一個UE上發(fā)送 訂閱請求，就可以在多個UE上收到通知消息。本發(fā)明實施例的目的是通過以下技術方案實現的 本發(fā)明實施例提供了 一種提供聯系人信息的方法，包括接收訂閱聯系人信息的訂閱請求消息一 ，所述訂閱請求消息一 包括用戶 的公共用戶標識；生成與所述訂閱請求消息一對應的訂閱請求消息二，將所述訂閱請求消 息二發(fā)送至與所述聯系人信息對應的聯系人信息服務器；若收到來自所述聯系人信息服務器的所述聯系人信息變化的消息，向用 戶設備信息文件中記錄的用戶設備發(fā)送所述變化后的聯系人信息，所述用戶 設備信息文件與所述公共用戶標識對應，所述用戶設備信息文件記錄有歸屬 于所述用戶的所有通過注冊的用戶設備信息。本發(fā)明實施例還提供了一種網絡設備，包括訂閱請求消息接收單元，用于接收訂閱聯系人信息的訂閱請求消息一，所述訂閱請求消息 一 包括用戶的公共用戶標識；訂閱請求消息生成單元，用于生成與所述訂閱請求消息一對應的訂閱請 求消息二；訂閱請求消息發(fā)送單元，用于將所述訂閱請求消息二發(fā)送至與所述聯系 人信息對應的聯系人信息服務器；聯系人信息接收單元，用于接收來自所述聯系人信息服務器的所述聯系 人信息變化的消息；聯系人信息發(fā)送單元，用于向用戶設備信息文件中記錄的用戶設備發(fā)送 所述變化后的聯系人信息，所述用戶設備信息文件與所述公共用戶標識對應， 所述用戶設備信息文件記錄有歸屬于所述用戶的所有通過注冊的用戶設備信 息。相應的，本發(fā)明實施例提供了一種提供聯系人信息的系統，包括網絡設備，接收訂閱聯系人信息的訂閱請求消息一，所述訂閱請求消息 一包括用戶的公共用戶標識；生成與所述訂閱請求消息一對應的訂閱請求消 息二，并發(fā)送所述訂閱請求消息二；與所述聯系人信息對應的聯系人信息服務器，用于接收所述訂閱請求消 息二；若所述聯系人信息發(fā)生變化，發(fā)送變化后的所述聯系人信息；所述網絡設備，還用于接收所述變化后的聯系人信息；查找所述公共用 戶標識對應的用戶設備，向所述用戶設備發(fā)送所述變化后的聯系人信息。從本發(fā)明實施例提供的以上技術方案可以看出，由于用戶或業(yè)務服務器 只需要發(fā)送一次訂閱請求消息一 ，在網絡實體發(fā)送變化后的聯系人信息時， 才艮據用戶的URI,向經過注冊的歸屬于該URI的UE返回變化后的聯系人信 息，從而使用戶只需要發(fā)送一次訂閱請求消息一就可以從多個UE上收取變化 后的聯系人信息，從而不會給用戶帶來較大的處理負擔；并且，由于只有一個UE或一個業(yè)務服務器發(fā)送了訂閱請求消息，因而刷新訂閱請求也只有一個UE或一個業(yè)務服務器需要發(fā)送，所以刷新訂閱請求的數量也是有限的，從而不會過多的占用網絡資源。


圖1為本發(fā)明實施例中UE注冊過程的流程圖； 圖2為本發(fā)明實施例提供的用戶設備信息文件的結構圖； 圖3為本發(fā)明實施例中提供聯系人信息的方法實施例一的流程圖； 圖4為本發(fā)明實施例中提供聯系人信息的方法實施例二的流程圖； 圖5為本發(fā)明實施例中提供聯系人信息的方法實施例三的流程圖； 圖6為本發(fā)明實施例中提供聯系人信息的方法實施例四的流程圖； 圖7為本發(fā)明實施例中提供聯系人信息的方法實施例五的信令流程圖； 圖8為本發(fā)明實施例中提供聯系人信息的方法實施例六的信令流程圖； 圖9為本發(fā)明實施例中網絡設備實施例一的結構圖； 圖10為本發(fā)明實施例中網絡設備實施例二的結構圖； 圖11為本發(fā)明實施例中網絡設備實施例三的結構圖； 圖12為本發(fā)明實施例中網絡設備實施例四的結構圖； 圖13為本發(fā)明實施例中網絡設備實施例五的結構圖； 圖14為本發(fā)明實施例中提供聯系人信息的系統實施例 一的結構圖。
具體實施方式
為使本發(fā)明的目的、技術方案、及優(yōu)點更加清楚明白，以下參照附圖并 舉實施例，對本發(fā)明進一步詳細說明。先介紹本發(fā)明實施例提供的UE注冊的過程，如圖l所示，包括步驟101 、接收UE的注冊通知消息；該注冊通知消息包括UE歸屬的用 戶公共用戶標識；用戶一般會有多個UE，當用戶需要通過一個UE去接收網絡狀態(tài)時，則 需要先將該UE在網絡注冊；網絡一般都會給用戶分配一個公共用戶標識，在 實際應用中，該〃^共用戶標識可以是URI，在網絡中，URI就可以唯一的標 識該用戶，因而在將該用戶的UE進行注冊時，要附帶該用戶的URI,以此標 識該UE是歸屬于該URI的用戶；步驟102、判斷注冊通知消息的類型；如果是初始注冊通知消息，進入步 驟103;如果是去注冊通知消息，進入步驟106;當沒有經過注冊的UE需要注冊時，就發(fā)送初始注冊通知消息，觸發(fā)網絡 側對其注冊；而當需要將經過注冊的UE解除注冊時，則發(fā)送去注冊通知消息， 觸發(fā)網絡側解除對該UE的注冊；在實際應用中，經過注冊的UE還要定期的 發(fā)送刷新注冊通知消息，刷新注冊通知消息并不會觸發(fā)網絡側做任何實際操 作，刷新注冊通知消息的作用是通知網絡側該UE的注冊仍然有效，相應的， 如果長時間沒有收到一個UE的刷新注冊消息，則可以對該UE做解除注冊處 理。步驟103、判斷與URI對應的用戶設備信息文件是否存在；如果是，進 入步驟104;如果否，進入步驟105;如果對應于步驟101所述的URI的UE是第一次注冊，則與該URI對應 的設備信息文件是不會存在的，因而在添加UE的信息之前要對是否存在對應 的用戶設備信息文件進行判斷；步驟104、在已經存在的用戶設備信息文件中添加UE的信息；結束；步驟105、創(chuàng)建包括該UE的信息的用戶設備信息文件；結束；步驟106、從用戶設備信息文件中刪除UE的信息；在實際應用中，如果用戶設備信息文件中沒有任何UE的信息，可以將該 用戶設備信息文件刪除，從而降低系統負荷，進而提高系統效率。圖2描述了本發(fā)明實施例提供的用戶設備信息文件的結構，如圖2所示， 用戶設備信息文件201包括用戶的URI以及UE信息，其中UE信息還包括用來標識與URI綁定的網絡地址的唯一標識，業(yè)務服務器可以根據這個唯一標識查找并修改相應的信息；與URI綁定的網絡地址信息；與URI綁定的網 絡地址的狀態(tài)信息，其值可以為激活或終止，在向多個UE發(fā)送聯系人信息時， 可以根據所述網絡地址的狀態(tài)信息只向狀態(tài)為激活的UE發(fā)送聯系人信息，該 項為可選項。在介紹本發(fā)明實施例提供的提供聯系人信息的方法前，先介紹一下融合 地址簿融合地址簿是網絡設備所提供的 一項功能，包括用戶設備信息文件以及 聯系人地址簿，其作用就相當于用戶在網絡側的聯系人列表，包括用戶聯系 人的一些靜態(tài)和動態(tài)的信息，其中靜態(tài)信息包括聯系人的聯系方式、聯系人 顯示名、聯系人的個人信息、聯系人的愛好等，動態(tài)信息包括聯系人的呈現 信息、聯系人的偏好設置、聯系人的通信能力等。以下開始介紹本發(fā)明實施例提供的提供聯系人信息的方法，如圖3所示， 提供聯系人信息的方法實施例 一 包括步驟301、接收訂閱聯系人信息的訂閱請求消息一，訂閱請求消息一包括 用戶的URI;訂閱請求消息一可以來自用戶設備即UE,也可以來自業(yè)務服務器；當來自UE時，是由用戶通過UE主動發(fā)送的；當來自業(yè)務服務器時，業(yè)務服務器是根據用戶的用戶服務設置信息觸發(fā)的，用戶預先設置一個觸發(fā)信息，當滿足觸發(fā)信息的條件時就會觸發(fā)業(yè)務服務器發(fā)送訂閱請求消息一；其中，前述的用戶服務設置信息一般情況下保存在業(yè)務服務器中，包含一些設置信息， 如與融合地址簿相關的設置信息等；訂閱請求消息一 包括URI,訂閱的聯系人的信息可以發(fā)送到該URI對應 的UE, URI在訂閱請求消息一的消息體中傳輸；其中，聯系人的信息可以包 括聯系人的呈現信息、聯系人的用戶偏好信息中的 一種或幾種的組合；與刷新注冊請求相應的，也有刷新訂閱請求，刷新訂閱請求也可以起到 告知服務器訂閱請求有效的作用；步驟302、生成與訂閱請求消息一對應的訂閱請求消息二；訂閱請求消息二的接收方標識采用訂閱請求消息一 中所述的URI，因而 可以在收到訂閱通知后，根據接收方標識中的所述URI查找到對應的UE;訂閱請求消息二是與訂閱請求消息一對應的，若訂閱請求消息一為一次 訂閱請求消息，則訂閱請求消息二也為 一次訂閱請求消息；若訂閱請求消息 一為長期訂閱請求消息，相應的訂閱請求消息二也為長期訂閱請求消息；進一步，還可以在訂閱請求消息二中設置過濾器，因為用戶可能只需要 訂閱某一大類消息中的一種消息，此時在訂閱請求消息二中設置過濾器可以 確保只返回該種消息，從而可以減少網絡流量；步驟303、將訂閱請求消息二發(fā)送至與聯系人信息對應的聯系人信息服務器；根據訂閱的聯系人信息的不同，訂閱請求消息二發(fā)送至的聯系人信息服 務器也不一樣，其中，用戶信息服務器可以是呈現業(yè)務服務器和用戶設置偏 好服務器等；若訂閱的是聯系人的呈現信息，則訂閱請求消息二發(fā)送至呈現 業(yè)務服務器；若訂閱的是聯系人的偏好設置信息，則訂閱請求消息二發(fā)送至 用戶偏好設置服務器；相應的，如果訂閱的是其他的聯系人信息，則將訂閱 請求消息二發(fā)送至相應的聯系人信息服務器；步驟304、若從聯系人信息服務器收到聯系人信息變化的消息，則向用戶 設備信息文件中記錄的UE發(fā)送變化后的聯系人信息；其中，用戶設備信息文 件與URI對應，用戶設備信息文件記錄有歸屬于該URI的所有已經注冊的用 戶的設備信息；當聯系人信息服務器收到了訂閱請求消息二后，若訂閱請求消息二訂閱 的聯系人信息發(fā)生變化，則所述聯系人信息服務器會發(fā)送聯系人信息發(fā)生變 化的通知消息， 一般情況下，該通知消息會附帶變化后的聯系人信息及URI 信息，該通知消息直接發(fā)送給發(fā)送訂閱請求消息二的網絡實體；該網絡實體 收到通知消息后，就會查找與該URI對應的用戶設備信息文件，根據該用戶 設備信息文件中記錄的UE信息向相應的UE發(fā)送該變化后的聯系人信息；從上可知，本實施例中，用戶或業(yè)務服務器只需要發(fā)送一次訂閱請求消 息一，在網絡實體發(fā)送變化后的聯系人信息時，根據用戶的URI,向經過注冊的歸屬于該URI的UE返回變化后的聯系人信息，從而使用戶只需要發(fā)送 一次訂閱請求消息一就可以從多個UE上收取變化后的聯系人信息，從而不會 給用戶帶來較大的處理負擔；并且，由于只有一個UE或業(yè)務服務器發(fā)送了訂 閱請求消息，因而刷新訂閱請求也只有一個UE或業(yè)務服務器需要發(fā)送，所以 刷新訂閱請求的數量也是有限的，從而不會過多的占用網絡資源。如圖4所示，本發(fā)明實施例中提供聯系人信息的方法實施例二包括步驟401、接收訂閱聯系人信息的訂閱請求消息一，訂閱請求消息一包括 用戶的URI;步驟402、生成與訂閱請求消息一對應的訂閱請求消息二；步驟403、將訂閱請求消息二發(fā)送至與聯系人信息對應的聯系人信息服務器；步驟404、收到來自聯系人信息服務器的聯系人信息變化的消息；步驟405、判斷用戶設備信息文件中記錄的UE的狀態(tài)是否為激活；若是， 進入步驟406;若否，結束流程；在UE向網絡側注冊后，即用戶設備信息文件中記錄了 UE的信息后，如 果一段時間內沒有收到該UE的刷新注冊請求，除了直接解除對該UE的注冊 外，還可以先將該UE的狀態(tài)改為未激活狀態(tài)，只有當該UE在未激活狀態(tài)一 段時間后網絡側仍然沒有收到刷新注冊請求才對該UE解除注冊；從而可以避 免直接對該UE解除注冊，使用戶需要重新注冊，不會給用戶帶來過多的麻煩；步驟406、向狀態(tài)為激活的UE發(fā)送變化后的聯系人信息；從上可知，本方法實施例二與方法實施例一相比進一步包括了對UE的狀 態(tài)是否激活進行判斷的過程，并只向狀態(tài)為激活的UE發(fā)送變化后的聯系人信 息，從而可以減少需要發(fā)送的信息量，不僅可以減少對有限網絡資源的占用， 還降低了對該網絡實體的系統資源的占用；同時，因為狀態(tài)為未激活的UE并 不會接收變化后的聯系人信息，因而不會對用戶造成影響。如圖5所示，本發(fā)明實施例中提供聯系人信息的方法實施例三包括步驟501、接收訂閱聯系人信息的訂閱請求消息一，訂閱請求消息一包括 用戶的URI;步驟502、生成與訂閱請求消息一對應的訂閱請求消息二；步驟503、將訂閱請求消息二發(fā)送至與聯系人信息對應的聯系人信息服務器；步驟504、收到來自聯系人信息服務器的聯系人信息變化的消息；步驟505、判斷設備信息文件中記錄的UE是否設置為接收變化后的聯系 人信息；若是，進入步驟506;若否，結束流程；雖然用戶向網絡側注冊了多個UE,但是用戶可能并不需要在每個UE上 都接收變化后的聯系人信息，因而可以設置某些UE不接收變化后的聯系人信 息，因而不僅可以滿足用戶的需要，還可以減少發(fā)送聯系人信息時對有限網 絡資源的占用；此設置的默認值為接收，用戶可以對該設置進行修改；具體 的修改方法根據具體的實現方式不同可以采取不同的方法，例如，以融合地 址簿為例，當融合地址簿采用可擴展標記語言(XML: Extensible Markup Language )文檔管理服務器(XDMS: XML Document Management Server) 的方式實現時，可以使用XML配置訪問協議(XCAP: XML Configuration Access Protocol)的PUT方法進4亍1多改。步驟506、判斷設置為接收變化后的聯系人信息的UE的狀態(tài)是否為激活； 若是，進入步驟507;若否，結束流程；步驟507、向狀態(tài)為激活的UE發(fā)送變化后的聯系人信息；從上可知，本方法實施例三與方法實施例二相比進一步包括了判斷UE是 否接收變化后的聯系人信息的步驟，并只向設置為接收變化后的聯系人信息 的UE發(fā)送變化后的聯系人信息，從而可以減少需要發(fā)送的信息量，不僅可以 減少對有限網絡資源的占用，還降低了對該網絡實體的系統資源的占用；同 時，因為用戶并不需要在設置為不接收聯系人信息的UE接收變化后的聯系人信息，因而不會對用戶造成影響。假設一個用戶的URI下注冊了兩個UE,即用戶設備信息文件中記錄了兩 個UE，分別是UE1和UE2，方法流程如圖6所示，本發(fā)明實施例中提供聯 系人信息的方法實施例四包括如下步驟，其中聯系人信息保存在聯系人信息 文檔中步驟601、接收來自UE1的訂閱聯系人信息的訂閱請求消息一，訂閱請 求消息一 包括用戶的URI;步驟602、觸發(fā)歸屬于該URI的UE2訂閱聯系人信息文檔的更新，該聯 系人信息文檔包括UE1訂閱的聯系人信息；UE2的信息在用戶設備信息文件中有記錄，在實際應用中，根據具體的 實現方式不同，具體的觸發(fā)方法也不同，例如，當采用SIP協議時，可以使 用REFER參考方法觸發(fā)用戶設備信息文件上的其他設備訂閱融合地址簿上 聯系人信息文檔的變化；步驟603、生成與訂閱請求消息一對應的訂閱請求消息二；步驟604、將訂閱請求消息二發(fā)送至與聯系人信息對應的聯系人信息服務器；步驟605、收到來自聯系人信息服務器的聯系人信息變化的消息，更新聯 系人信息文檔；在實際應用中，因為網絡側會保存每個聯系人的信息，例如前述的融合 地址簿，當然也可能是其他的實現相似功能的功能實體，其中，聯系人信息 保存在聯系人信息文檔中，因而需要更新聯系人信息文檔，前述的實施例一、 實施例二和實施例三在實際應用中也會有更新聯系人信息文檔這個步驟；步驟606 、向UE1發(fā)送變化后的聯系人信息；因為是UE1主動向網絡側訂閱聯系人信息，所以采用與UE1所采用的訂 閱方式相對應的方式向UE1發(fā)送變化后的聯系人信息；步驟607、向UE2發(fā)送聯系人信息文檔更新的通知；UE2是被動的向網絡側訂閱聯系人信息文檔的更新，而這個訂閱方式可能與UE1所采用的訂閱方式不同，因而網絡側根據UE2而所采用的訂閱方式， 采用相應的通知方式通知UE2聯系人信息文檔的更新；在實際應用中，UE2的數量可能會有多個，因為UE1主動訂閱了聯系人 信息，網絡側會單獨的向UE1發(fā)送變化后的聯系人信息，因而在向UE2發(fā)送 聯系人信息文檔更新的通知時，不用向UE1發(fā)送；在本實施例中，UE可以接收網絡側的觸發(fā)信息，被動的訂閱聯系人信息 文檔的更新，從而使UE可以做好接收聯系人信息更新的通知的準備，從而可 以提高UE的處理效率，因而可以滿足用戶的需要。圖7是本發(fā)明實施例中提供聯系人信息的方法實施例五的信令流程圖， 在該實施例中用戶有兩個UE分別為UE1和UE2，并使用用戶的同 一個SIP URI向融合網際協議(IP: Internet Protocol)消息(CPM: Converged IP Messaging)業(yè)務引擎注冊，CPM業(yè)務引擎收到注冊請求完成注冊過程后將 UEl和UE2的設備信息更新到融合地址簿(CAB: Converged Address Book) 的設備列表中，當用戶使用UEl通過CAB訂閱了某個聯系人的服務能力或用 戶偏好后，CAB根據設備列表將來自呈現服務器或用戶偏好設置服務器的信 息更新到用戶的UE2中，具體過程如下步驟701、用戶使用UEl向CPM業(yè)務引擎注冊；具體過程為(1 )用戶使用UEl通過SIP REGISTER請求向IP多媒體子 系統(IMS: IP Multimedia Subsystem)網絡的服務呼叫會話控制功能(S-CSCF: Serving Call Session Control Function)注冊；(2 )注冊成功，S-CSCF向UEl 返回200 ok的成功響應；(3) S-CSCF根據初始過濾規(guī)則(IFC)向CPM業(yè) 務引擎發(fā)起注冊；(4)注冊成功，CPM業(yè)務引擎向S-CSCF返回200 ok的成 功響應；(5) S-CSCF根據CPM業(yè)務引擎訂閱的注冊事件，向CPM業(yè)務引擎 發(fā)送通知消息；(6 ) CPM業(yè)務引擎收到通知后返回200 ok的成功響應；進一步，以XML實現方式為例，第(5)步中通知消息體包括如下信息 〈contact id="99a9020" state="active" event="registered" ><uri>sip: 1.8.27.2.161 @8.27.2.56:5060</uri〉</contact>步驟702、 CPM業(yè)務引擎向CAB寫UE1的信息；具體過程為CPM業(yè)務引擎根據通知消息體中〈contact〉元素的"state" 屬性值和"event"屬性值判斷用戶是初次注冊，獲得與用戶的^^共SIP URI 綁定的contact地址(例如sip:1.8.27.2.161@8.27.2.56:5060 ),并通過XCAP協議的PUT方法將此信息添加到保存在CAB中用戶的設備列表中；使用 XCAP協議的PUT方法在CAB中創(chuàng)建用戶的設備信息文件的消息實例可以包 括〈deviceinfo〉元素，具體如下<deviceinfo xmlns="urn:ietf:params:xml:ns:device-lists"xmlns:xsi="http:〃www.w3.org/2001/XMLSchema-instance"><devicelist aor=" sip:userl@example.com "/〉 〈contact id="99a9020" state="active"> <uri> sip:1.8.27.2.161@8.27.2.56:5060</uri> </contact> </deviceinfo>〈deviceinfo〉元素是設備信息文件的根元素，表示這個文件描述的是設備 信息，〈deviceinfo〉才艮元素包含一個〈devicelist〉和一個或多個〈contac^元素， 其中〈devicelist〉元素有一個必選的aor屬性，其值為用戶的公共SIP URI，用 來表示此設備列表屬于哪一個用戶，化ontact〉元素用來表示用戶所使用設備 當前的contact地址，他包含兩個屬性，分別為id屬性和state屬性，其中id 屬性用來唯一的標識這個contact地址其值與CPM業(yè)務引擎收到的注冊事件 通知消息體中〈contact〉元素的id屬性值一致，state屬性用來表示這個contact 地址的注冊狀態(tài)，其虧直可以是active、 terminated,此夕卜，〈contact〉元素還包 含一個〈uri〉子元素，其值為 一個SIP URI,即用戶UE1的當前contact地址； 優(yōu)選的，還可以包含指示某個設備是否接收聯系人信息變化的設置信息；進一步，CPM業(yè)務引擎根據通知消息的消息體中的內容判斷如何處理的過程如下如果收到的通知消息中〈contact〉元素的"state"屬性值為"active",并且 "event"屬性的值為"register"或"created",則用戶的此次注冊為初始注冊， CPM業(yè)務引擎通過XCAP協議的PUT方法向CAB中的用戶設備信息文件中 添加與用戶的公共SIP URI綁定的contact地址信息和id屬性，如果在CAB 中，用戶的設備信息文件不存在，則創(chuàng)建包含與用戶的公共SIP URI綁定的 contact地址信息和id屬性的設備信息文件；如果收到的通知消息中〈contac1^元素的"state"屬性值為"active",并 且"event"屬性的值為"refreshed"或"shortened",則用戶的注冊為刷新注 冊，不需要更改CAB中用戶設備信息文件的內容；如果收到的通知消息中〈contact〉元素的"state"屬性值為"terminated", 則用戶的此次注冊為去注冊請求，CPM業(yè)務引擎通過XCAP協議的DELETE 方法刪除用戶設備信息文件中〈contact〉元素的id屬性值與此通知消息中的 〈contact〉元素的id屬性值相同的〈contact〉元素及其子元素，或將此〈contact〉 元素的"state"屬性值 文為"terminated";步驟703、創(chuàng)建成功，CAB向CPM業(yè)務引擎返回成功響應，該成功響應 可以為201 Created消息；步驟704、用戶使用UE2向CPM業(yè)務引擎注冊；用戶使用與前述步驟701相同的公共SIP URI ( sip:userl@example.com) 通過UE2向CPM業(yè)務服務引擎注冊，具體的過程如步驟701所描述；步驟705、 CPM業(yè)務引擎向CAB寫UE2的信息；CPM業(yè)務引擎根據通知中的信息，獲得UE2的contact地址 sip:1.8.27.2.172②8.27.2.56:5060(CPM業(yè)務引擎從通知消息中獲取與用戶的公 共SIP URI綁定的UE2的contact地址的方法與步驟2所述的方法相同)，并 通過XCAP協議的PUT方法將此信息添加到保存在CAB中用戶的設備列表 中，進一步，還可以包含指示某個設備是否接收聯系人信息變化的設置信息；步驟706、創(chuàng)建成功，CAB向CPM業(yè)務引擎返回成功響應；步驟707、用戶通過UE1發(fā)起訂閱聯系人呈現信息和用戶偏好信息的請 求，該請求作為訂閱請求消息一；一種使用SIP協議訂閱(SUBSCRIBE)方法描述訂閱請求消息一的具體 實例如下SUBSCRIBE sipxab@example.com SIP/2.0Via: SIP/2.0/TCPuel.example.com;branch=z9hG4bKwYb6QREiCLMax-Forwards: 70丁o: cab <sip:cab@example.com>From: <sip:userl@example.com>;tag=ie4hbb8tCall-ID: cdB34qLToC@terminal.example.comCSeq: 1 SUBSCRIBEContact: <sip:uel .example.com>Content-Type: application/res-lists+xmlEvent: contactinfoExpires: 7200< xml version="1.0" encoding="UTF-8" > 〈resource-lists xmlns="um:ietf:params:xml:ns:cab-lists"xmlns:xsi="http:〃www. w3.org/2001/XMLSchema-instance"〉 <list><entry uri="sip:bill@example.com" /> </list> </resource-lists>上述訂閱請求消息一的消息體為 一個聯系人列表，指明用戶要訂閱哪些 聯系人的聯系信息，Request-URI的值為融合地址簿的SIP URI其Content-Type 頭字段值為application/res-lists+xml。步驟708、訂閱成功CAB向UE1返回200 ok的成功響應；步驟709、 CAB根據收到的訂閱請求消息向呈現業(yè)務服務器訂閱所述聯 系人(sip:bill@example.com )的呈現信息，具體的通過發(fā)送訂閱請求消息二 向呈現業(yè)務服務器訂閱；在實際應用中，可以在訂閱請求消息二中添加僅訂閱聯系人部分信息的 過濾器， 一種包含在訂閱請求消息中，使用XML描述的過濾器的具體實例如 下SUBSCRIBE sip:cab@example.com SIP/2.0Via: SIP/2.0/TCPuel.example.com;branch=z9hG4bKwYb6QREiCLMax-Forwards: 70To: cab <sip:cab@example.com>From: <sip:userl@example.com>;tag=ie4hbb8tCall-ID: cdB34qLToC@terminal.example.comCS叫1 SUBSCRIBEContact: <sip:uel.example.com>Content-Type: multipart/mixed;boundary=unique-boundary-1Event: contactinfoExpires: 7200 —unique-boundary-1 Content-Type: application/cab-lists+xml< xml version="1.0" encoding="UTF-8" > <resource-lists xmlns="urn:ietf:params:xml:ns:cab-lists" xmlns:xsi="http:〃www.w3.org/2001/XMLSchema-instance"> <list〉<entry uri="sip:bill@example.com" /> </list> </resource-lists> —unique-boundary-1Content-Type: application/simple-filter+xmlEvent: presence< xml version="1.0" encoding="UTF-8" > <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <m-bindings〉〈ns-binding prefix="pidf' urn="urn:ietf:params:xml:ns:pidr/> <ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/> </ns-bindings><filter id="123" uri=" sip:bill@example.com "> <what>〈include type="xpath"〉/pidf:presence/pidf:tuple[rpid:class="CPM"]/pidf:servcaps </include> </what> </filter> </filter-set> —unique-boundary-1上述SIP消息的Content-Type頭字段值指示此SIP消息中包含兩個消息 體， 一部分指明此SIP SUBSCRIBE請求要訂閱哪些聯系人的呈現信息， 一部 分指明訂閱這些聯系人的哪一部分呈現信息；其中，該過濾器可以是用戶自 己設置通過訂閱請求消息一傳送的，因為訂閱請求消息一中有過濾器，所以 需要在訂閱請求消息二中設置同樣的過濾器；該過濾器還可以是預先設置在 CAB上的，當收到訂閱請求消息一后，判斷訂閱請求消息一所訂閱的聯系人 信息，如果符合預先設定的條件，則將該過濾器加到訂閱請求消息二中；通過在訂閱請求消息二中增加該過濾器，可以使聯系人信息服務器僅返回該過濾器允許返回的聯系人信息；步驟710、訂閱成功返回200 ok的成功響應；步驟711、呈現業(yè)務服務器向CAB發(fā)送聯系人呈現信息的通知；呈現業(yè)務服務器可以通過SIP協議的NOTIFY方法向CAB發(fā)送SIP URI 為sip:bill@example.com的聯系人的呈S2/[言息；步驟712、 CAB收到聯系人呈現信息的通知消息后向呈現業(yè)務服務器返 回200 ok的成功響應，并根據收到的通知消息更新用戶的聯系人列表中標識 為sip:bill@example.com的聯系人信息；步驟713、 CAB向用戶偏好服務器訂閱聯系人的用戶偏好信息，也是通 過發(fā)送訂閱請求消息二向用戶偏好服務器訂閱；步驟714、訂閱成功返回200 ok的成功響應；步驟715、用戶偏好服務器向CAB發(fā)送聯系人的用戶偏好通知，用戶偏 好服務器可以通過SIP協議NOTIFY通知方法向CAB發(fā)送此聯系人的用戶偏 好信息；步驟716、 CAB向用戶偏好服務器返回200 ok的成功響應，并根據收到 的通知消息更新用戶的聯系人列表中標識為sip:bill@example.com的聯系人信 息；步驟717、 CAB通過SIP協議的NOTIFY方法將步驟711和步驟715中 消息發(fā)送給UEl;步驟718、 UE1收到消息后返回200 ok的成功響應；步驟719、 CAB解析用戶設備信息文件，查找其他UE;本實施例中能夠 查到UE2;步驟720、 CAB將聯系人信息的變化發(fā)送給UE2,具體的可以使用同步 才示"i己i吾言(SyncML: Synchronization Markup Language ) #支術,或4吏用SIP消 息(MESSAGE)方法；步驟721、 UE2返回成功響應；從上可知，本實施例中用戶通過UE1向CAB發(fā)送訂閱聯系人信息的訂閱 請求，CAB在獲知聯系人信息更新后，除了向UE1發(fā)送聯系人信息更新的通知，還向與UE1具有相同URI的UE2發(fā)送聯系人信息更新的信息，從而使用 戶只需要發(fā)送一次訂閱請求消息就可以從UE1和UE2上收取變化后的聯系人 信息，從而不會給用戶帶來較大的處理負擔；并且，由于只有UE1發(fā)送了訂 閱請求消息，因而也只有UE1發(fā)送刷新訂閱請求，所以刷新訂閱請求的數量 也是可以有限的，不會過多的占用有限的網絡資源。圖8是本發(fā)明實施例中提供聯系人信息的方法實施例六的信令流程圖， 在該實施例中CPM業(yè)務引擎收到注冊請求完成注冊過程后將UE1和UE2 的設備信息更新到CAB的設備列表中，當用戶使用UE1通過CAB訂閱了某 個聯系人的服務能力或用戶偏好后，CAB根據用戶設備信息文件觸發(fā)UE2訂 閱融合地址簿上聯系人信息文檔的變化，融合地址簿收到所述聯系人呈現信 息或用戶偏好信息變化的通知消息后更新此聯系人的信息，然后向UE2發(fā)送 融合地址簿上聯系人信息文檔變化的通知；具體過程如下步驟801、用戶通過UEl根據本地聯系人列表使用SIP協i義的 SUBSCRIBE方法向CAB發(fā)起訂閱聯系人信息的訂閱請求，請求訂閱聯系人 的服務能力信息和用戶偏好信息，該訂閱請求可以為訂閱請求消息一；步驟802、訂閱成功CAB向UEl返回200 ok的成功響應；步驟803、 CAB根據收到的訂閱請求消息向呈現業(yè)務服務器訂閱聯系人的服務能力；服務能力是呈現信息的一部分，所以向呈現業(yè)務服務器發(fā)訂閱請求，該訂閱請求為訂閱請求消息二；步驟804、訂閱成功返回200 ok的成功響應；步驟805、呈現業(yè)務服務器向CAB發(fā)送聯系人服務能力信息的通知；步驟806、 CAB收到聯系人呈現信息的通知消息后向呈現業(yè)務服務器返 回200 ok的成功響應；步驟807、 CAB向用戶偏好服務器訂閱聯系人的用戶偏好信息，具體的 通過向用戶偏好服務器發(fā)送訂閱請求消息二訂閱聯系人的用戶偏好信息；步驟808、訂閱成功返回200 ok的成功響應；步驟809、用戶偏好服務器向CAB發(fā)送聯系人的用戶偏好信息通知，用戶偏好服務器可以通過SIP協議NOTIFY方法向CAB發(fā)送聯系人的用戶偏好 信息；步驟810、 CAB向用戶偏好服務器返回200ok的成功響應；步驟811、 CAB使用REFER方法觸發(fā)UE2訂閱CAB上用戶聯系人信息 文檔的變化，RERFER消息的To頭域值為與UE2綁定的IP地址，From頭域 值為CAB的SIP URI, Refer-to頭域指明用戶的聯系人信息文檔，其method 參數為SUBSCRIBE,以指明UE2產生的動作，此RERFER消息采用XML 實現的實例如下所示REFER sip: 1.8.27.2.172@8.27.2.56:5060 SIP/2.0Via: SIP/2.0/UDP cab.example.com;branch=z9hG4bK2293940223To: <sip:1.8.27.2.172@8.27.2.56:5060>From: <sip:cab@example.com>;tag=l93402342Call-ID: 898234234@example.comCSeq: 93809823 REFERMax-Forwards: 70Refer-To: sip: cab@example.com method=SUBSCRIBE Contact: sip:cab@example.com Content-Length: 0其中在上述SIP消息的實例中可以在Refer-To頭字段中指明UE2的訂閱 請求發(fā)送是發(fā)送到CAB的，在method參數值中指明UE2應發(fā)起SIP SUBSCRIBE消息；步驟812、 UE2返回202 Accepted響應；步驟813、 UE2向CAB發(fā)送NOTIFY消息；步驟814、 CAB向UE2返回200ok的成功響應；步驟815 、 UE2產生SUBSCRIBE請求消息訂閱CAB上用戶聯系人信息文檔的變化；步驟816、訂閱成功CAB向UE2返回200 ok的成功響應； 步驟817、 CAB向UE2發(fā)送NOTIFY消息； 步驟818、 UE2向CAB返回200ok的成功響應； 步驟819 、 UE2向CAB發(fā)送訂閱狀態(tài)終止的通知消息； 步驟820、 CAB向UE2返回200 ok的成功響應；步驟821、 CAB通過SIP協議的NOTIFY方法將步驟805和步驟809中 的消息發(fā)送給UE1;步驟822、 UE1收到消息后返回200 ok的成功響應；從上可知，本實施例中UE2接收CAB的觸發(fā)信息，被動的訂閱聯系人信 息文檔的更新，從而使UE2在接收來自CAB的聯系人信息更新的通知時，已 經做好了接收該通知的準備，提高了UE2的處理速度，可以進一步滿足用戶 的需要。是可以通過程序來指令相關的硬件完成，所述的程序可以存儲于一種計算機 可讀存儲介質中，該程序在執(zhí)行時，包括如下步驟接收訂閱聯系人信息的訂閱請求消息一，訂閱請求消息一包括用戶的腦；生成與訂閱請求消息一對應的訂閱請求消息二，將訂閱請求消息二發(fā)送 至與聯系人信息對應的聯系人信息服務器；若收到來自聯系人信息服務器的所述聯系人信息變化的消息，向用戶設 備信息文件中記錄的UE發(fā)送變化后的聯系人信息，用戶設備信息文件與URI 對應，用戶設備信息文件記錄有歸屬于用戶的所有通過注冊的UE信息；上述提到的存儲介質可以是只讀存儲器，磁盤或光盤等。本發(fā)明實施例還提供了 一種網絡設備，該網絡設備可以實現前述的融合 地址簿的功能，如圖9所示，網絡設備的實施例一包括訂閱請求消息接收單元901,用于接收訂閱聯系人信息的訂閱請求消息一，其中訂閱請求消息一 包括用戶的URI;訂閱請求消息生成單元902,用于生成與訂閱請求消息一對應的訂閱誚-求消息二；訂閱請求消息發(fā)送單元903,用于將訂閱請求消息二發(fā)送至與聯系人信 息對應的聯系人信息服務器；聯系人信息接收單元904,用于接收來自聯系人信息服務器的所述聯系 人信息變化的消息；聯系人信息發(fā)送單元905，用于向用戶設備信息文件中記錄的UE發(fā)送變 化后的聯系人信息，用戶設備信息文件與URI對應，用戶設備信息文件記錄 有歸屬于該用戶的所有通過注冊的UE信息；從上可知，本實施例中，用戶或業(yè)務服務器只需要發(fā)送一次訂閱請求消 息一，在網絡實體發(fā)送變化后的聯系人信息時，根據用戶的URI,向經過注 冊的歸屬于該URI的UE返回變化后的聯系人信息，從而使用戶只需要發(fā)送 一次訂閱請求消息一就可以從多個UE上收取變化后的聯系人信息，從而不會 給用戶帶來較大的處理負擔；并且，由于只有一個UE或業(yè)務服務器發(fā)送了訂 閱請求消息，因而刷新訂閱請求也只有一個UE或業(yè)務服務器需要發(fā)送，所以 刷新訂閱請求的數量也是可以有限的，從而不會過多的占用有限的網絡資源。進一步，提供了網絡設備的實施例二，如圖10所示，包括訂閱請求消息接收單元1001,用于接收訂閱聯系人信息的訂閱請求消息 一 ，訂閱請求消息一 包括用戶的URI;訂閱請求消息生成單元1002,用于生成與訂閱請求消息一對應的訂閱請 求消息二；訂閱請求消息發(fā)送單元1003,用于將訂閱請求消息二發(fā)送至與聯系人信 息對應的聯系人信息服務器；聯系人信息接收單元1004,用于接收來自聯系人信息服務器的聯系人信 息變化的消息；激活狀態(tài)判斷單元1005,用于在聯系人信息接收單元接收聯系人信息變化的消息后，判斷用戶設備信息文件中記錄的UE的狀態(tài)是否為激活；其中， 用戶設備信息文件與URI對應，用戶設備信息文件記錄有歸屬于用戶的所有 通過注冊的UE信息；聯系人信息發(fā)送單元1006,用于向激活狀態(tài)判斷單元判斷為激活的UE 發(fā)送變化后的聯系人信息；從上可知，本實施例與網絡設備實施例一相比進一步包括了對UE是否激 活進行判斷的激活狀態(tài)判斷單元，并只向狀態(tài)為激活的UE發(fā)送變化后的聯系 人信息，從而可以減少需要發(fā)送的信息量，不僅可以減少對有限網絡資源的 占用，還降低了對向UE發(fā)送變化后的聯系人信息的網絡實體的系統資源占 用；同時，因為狀態(tài)為未激活的UE并不會接收變化后的聯系人信息，因而不 會對用戶造成影響。進一步，提供了網絡設備的實施例三，如圖ll所示，包括訂閱請求消息接收單元1101,用于接收訂閱聯系人信息的訂閱請求消息 一，訂閱請求消息一 包括用戶的URI;訂閱請求消息生成單元1102,用于生成與訂閱請求消息一對應的訂閱請 求消息二；訂閱請求消息發(fā)送單元1103,用于將訂閱請求消息二發(fā)送至與聯系人信 息對應的聯系人信息服務器；聯系人信息接收單元1104,用于接收來自聯系人信息服務器的聯系人信 息變化的消息；接收設置判斷單元1105,用于在聯系人信息接收單元接收聯系人信息變 化的消息后，判斷用戶設備信息文件中記錄的UE是否設置為接收變化后的聯 系人信息；其中，用戶設備信息文件與URI對應，用戶設備信息文件記錄有 歸屬于用戶的所有通過注冊的UE信息；激活狀態(tài)判斷單元1106，用于在接收設置判斷單元判斷UE設置為接收 變化后的聯系人信息時，判斷UE的狀態(tài)是否為激活；聯系人信息發(fā)送單元1107,用于向激活狀態(tài)判斷單元判斷為激活，且設置為接收變化后的聯系人信息的UE發(fā)送變化后的聯系人信息；從上可知，本實施例與網絡設備實施例二相比進一步包括了判斷UE是否 接收變化后的聯系人信息的接收設置判斷單元，并只向設置為接收變化后的 聯系人信息的UE發(fā)送變化后的聯系人信息，從而可以減少需要發(fā)送的信息 量，不僅可以減少對有限網絡資源的占用，還降低了對向UE發(fā)送變化后的聯 系人信息的網絡實體的系統資源占用；同時，因為用戶并不需要在設置為不 接收聯系人信息的UE接收變化后的聯系人信息，因而不會對用戶造成影響。進一步，提供了網絡設備的實施例四，如圖12所示，包括訂閱請求消息接收單元1201,用于接收訂閱聯系人信息的訂閱請求消息 一，訂閱:清求消息一 包括用戶的URI;訂閱請求消息生成單元1202，用于生成與訂閱請求消息一對應的訂閱請 求消息二；訂閱請求消息發(fā)送單元1203,用于將訂閱請求消息二發(fā)送至與聯系人信 息對應的聯系人信息服務器；聯系人信息接收單元1204,用于接收來自聯系人信息服務器的聯系人信 息變化的消息；聯系人信息發(fā)送單元1205,用于向用戶設備信息文件中記錄的UE發(fā)送 變化后的聯系人信息，用戶設備信息文件與URI對應，用戶設備信息文件記 錄有歸屬于用戶的所有通過注冊的UE信息；聯系人信息文檔更新單元1206,用于在聯系人信息接收單元接收聯系人 信息變化的消息后，更新包括聯系人信息的聯系人信息文檔；從上可知，本實施例與網絡設備實施例一相比還包括更新聯系人信息文 檔的聯系人信息文檔更新單元，通過對聯系人信息文檔的更新，可以保證網 絡側保存的聯系人信息與聯系人的真實信息保持一致。在實際應用中，網絡設備在收到訂閱請求后，可以觸發(fā)發(fā)送訂閱請求外 的UE訂閱聯系人信息文檔的更新，假設由UE1發(fā)送訂閱請求，相應的提供了網絡設備的實施例五，如圖13所示，包括訂閱請求消息接收單元1301,用于接收訂閱聯系人信息的訂閱請求消息 一，訂閱請求消息一包括用戶的URI;訂閱請求消息生成單元1302,用于生成與訂閱請求消息一對應的訂閱請 求消息二；訂閱請求發(fā)送單元1303,用于將訂閱請求消息二發(fā)送至與聯系人信息對 應的聯系人信息服務器；聯系人信息接收單元1304,用于接收來自聯系人信息服務器的聯系人信 息變化的消息；聯系人信息文檔更新單元1305,用于在聯系人信息接收單元接收聯系人 信息變化的消息后，更新包括聯系人信息的聯系人信息文檔；觸發(fā)單元1306,用于在訂閱請求接收單元接收訂閱請求消息一后，觸發(fā) 用戶設備信息文件記錄的UE中除UE1外的UE ，訂閱聯系人信息文檔的更新；聯系人信息發(fā)送單元1307,用于在訂閱請求消息接收單元接收了訂閱請 求消息一后，向訂閱了聯系人信息文檔更新的UE和發(fā)送訂閱請求消息一的 UE1,發(fā)送變化后的聯系人信息；在本實施例中，UE可以接收網絡側的觸發(fā)信息，被動的訂閱聯系人信息 文檔的更新，從而使UE可以做好準備以接收聯系人信息更新的通知，從而可 以提高UE的處理效率，因而可以滿足用戶的需要。本發(fā)明實施例進一步提供了提供聯系人信息的系統，如圖14所示，本發(fā) 明實施例中提供聯系人信息的系統實施例一包括網絡設備1401,接收訂閱聯系人信息的訂閱請求消息一，訂閱請求消息 一包括用戶的URI;生成與訂閱請求消息一對應的訂閱請求消息二，并發(fā)送 訂閱請求消息二；該網絡設備可以使用本發(fā)明實施例中網絡設備的實施例，具有融合地址 簿的功能；與聯系人信息對應的聯系人信息服務器1402，用于接收訂閱請求消息 二；若聯系人信息發(fā)生變化，發(fā)送變化后的聯系人信息；其中，聯系人信息服務器是提供聯系人信息的服務器，根據用戶所訂閱 的聯系人信息的不同，對應的聯系人信息服務器也不同，因為不同的聯系人 信息服務器提供不同的聯系人信息，例如呈現業(yè)務服務器為用戶提供聯系人 的呈現信息，用戶偏好設置服務器為用戶提供聯系人的偏好設置服務，通用 服務訂閱服務器為用戶提供聯系人訂閱何種增值服務的信息等；網絡設備1401,還用于接收變化后的聯系人信息；查找與URI對應的 UE,向UE發(fā)送變化后的聯系人信息；從上可知，本實施例中，網絡設備只4妄收一次訂閱請求消息一，在網絡 實體發(fā)送變化后的聯系人信息時，根據用戶的URI,向經過注冊的歸屬于該 URI的UE返回變化后的聯系人信息，從而只需要發(fā)送一次訂閱請求消息一就 可以讓用戶從多個UE上收取變化后的聯系人信息，從而不會給用戶帶來較大 的處理負擔；并且，由于只有一個UE或業(yè)務服務器發(fā)送了訂閱請求消息，因 而刷新訂閱請求也只有一個UE或業(yè)務服務器需要發(fā)送，所以刷新訂閱請求的 數量也是可以有限的，從而不會過多的占用有限的網絡資源。本發(fā)明實施例進一 步提供了提供聯系人信息的系統實施例二 ，本實施例 二與系統實施例一相比進一步包括至少一個UE,用于接收變化后的聯系人信息；在實際應用中，若網絡設備具有融合地址簿的功能，為了保證用戶能夠 通過UE對融合地址簿上的信息進行操作，因而UE與現有的UE相比會增加 融合地址簿操作單元，通過融合地址簿操作單元，用戶可以對融合地址簿上 文件記錄的聯系人信息進行添加、刪除、修改等操作；具體如何操作根據融 合地址簿的實現方式不同而不同，例如，當融合地址簿釆用XDMS方式現實 時，融合地址簿客戶端可以是XCAP客戶端，當融合地址簿采用數據同'步服 務器實現時，融合地址簿客戶端可以采用數據同步客戶端實現。其中，在本發(fā)明實施例的系統實施例一和二中，訂閱請求消息一可以由用戶通過UE發(fā)送，也可以由業(yè)務服務器發(fā)送；若訂閱請求消息一由業(yè)務服務器發(fā)送，本發(fā)明提供的系統實施例可以進 一步包括發(fā)送訂閱請求消息一的業(yè)務服務器。從上可知，使用本發(fā)明實施例提供的技術方案，用戶或業(yè)務服務器只需 要發(fā)送一次訂閱請求消息一，在網絡實體發(fā)送變化后的聯系人信息時，根據用戶的URI,向經過注冊的歸屬于該URI的UE返回變化后的聯系人信息， 從而使用戶只需要發(fā)送一次訂閱請求消息一就可以從多個UE上收取變化后 的聯系人信息，從而不會給用戶帶來較大的處理負擔；并且，由于只有一個 UE或業(yè)務服務器發(fā)送了訂閱請求消息，因而刷新訂閱請求也只有一個UE或 業(yè)務服務器需要發(fā)送，所以刷新訂閱請求的數量也是可以有限的，從而不會 過多的占用有限的網絡資源；進一步，可以對UE是否激活進行判斷，并只向 狀態(tài)為激活的UE發(fā)送變化后的聯系人信息，從而可以減少需要發(fā)送的信息 量，不僅可以減少對有限網絡資源的占用，還降低了對向UE發(fā)送變化后的聯 系人信息的網絡實體的系統資源占用；同時，因為狀態(tài)為未激活的UE并不會 接收變化后的聯系人信息，因而不會對用戶造成影響；進一步，還可以判斷 UE是否接收變化后的聯系人信息，并只向設置為接收變化后的聯系人信息的 UE發(fā)送變化后的聯系人信息，從而可以減少需要發(fā)送的信息量，不僅可以減 少對有限網絡資源的占用，還降低了對向UE發(fā)送變化后的聯系人信息的網絡 實體的系統資源占用；同時，因為用戶并不需要在設置為不接收聯系人信息 的UE接收變化后的聯系人信息，因而不會對用戶造成影響；在本發(fā)明實施例 中，UE可以接收網絡側的出發(fā)信息，被動的訂閱聯系人信息文檔的更新，從 而使UE可以做好接收聯系人信息更新的通知的準備，從而可以提高UE的處 理效率，因而可以滿足用戶的需要。以上對本發(fā)明實施例所提供的一種提供聯系人信息的方法、系統及網絡 設備進行了詳細介紹，以上實施例的說明只是用于幫助理解本發(fā)明的方法及 其思想；同時，對于本領域的一般技術人員，依據本發(fā)明的思想，在具體實 施例及應用范圍上均會有改變之處，綜上所述，本說明書內容不應理解為對 本發(fā)明的限制。
權利要求
1、一種提供聯系人信息的方法，其特征在于，包括接收訂閱聯系人信息的訂閱請求消息一，所述訂閱請求消息一包括用戶的公共用戶標識；生成與所述訂閱請求消息一對應的訂閱請求消息二，將所述訂閱請求消息二發(fā)送至與所述聯系人信息對應的聯系人信息服務器；若收到來自所述聯系人信息服務器的所述聯系人信息變化的消息，向用戶設備信息文件中記錄的用戶設備發(fā)送所述變化后的聯系人信息，所述用戶設備信息文件與所述公共用戶標識對應，所述用戶設備信息文件記錄有歸屬于所述用戶的所有通過注冊的用戶設備信息。
2、 如權利要求1所述的提供聯系人信息的方法，其特征在于，向用戶設 備信息文件中記錄的用戶設備發(fā)送變化后的所述聯系人信息前進一步包括判斷所述用戶設備的狀態(tài)是否為激活；若是，進入向用戶設備信息文件中記錄的用戶設備發(fā)送變化后的所述聯 系人信息的步驟。
3、 如權利要求1所述的提供聯系人信息的方法，其特征在于，向用戶設 備信息文件中記錄的用戶設備發(fā)送變化后的所述聯系人信息前進一步包括判斷所述用戶設備是否設置為接收變化后的聯系人信息；若是，進入向用戶設備信息文件中記錄的用戶設備發(fā)送變化后的所述聯 系人信息的步驟。
4、 如權利要求1至3任一所述的提供聯系人信息的方法，其特征在于， 進一步在所述訂閱請求消息二中設置僅訂閱聯系人部分信息的過濾器；來自所述聯系人信息服務器的所述聯系人信息變化的消息為所述聯系人 部分信息變化的消息。
5、 如權利要求1至3任一所述的提供聯系人信息的方法，其特征在于， 所述聯系人信息保存在聯系人信息文檔中，收到來自所述聯系人信息服務器的所述聯系人信息變化的消息后進一步包括更新包括所述聯系人信息的所述聯系人信息文檔。
6、 如權利要求1所述的提供聯系人信息的方法，其特征在于，接收訂閱 聯系人信息的訂閱請求消息 一后進一 步包括觸發(fā)所述用戶設備信息文件記錄的用戶設備訂閱所述聯系人信息文檔的 更新；所述向用戶設備信息文件中記錄的用戶設備發(fā)送變化后的所述聯系人信 息具體為向所述訂閱了所述聯系人信息文檔的更新的用戶設備發(fā)送所述聯系人信 息文檔更新的通知。
7、 如權利要求6所述的提供聯系人信息的方法，其特征在于，若所述訂 閱請求消息一由用戶設備一發(fā)送，所述訂閱了所述聯系人信息文檔的變化的 用戶設備不包括所述用戶設備一。
8、 如權利要求1所述的提供聯系人信息的方法，其特征在于，所述用戶 設備在所述用戶設備信息文件中注冊具體為接收用戶設備的注冊通知消息，所述注冊通知消息包括所述用戶設備歸 屬的用戶的公共用戶標識；若所述注冊通知消息為初始注冊通知消息，判斷與所述公共用戶標識對 應的用戶設備信息文件是否存在，若是，在所述存在的用戶設備信息文件中 添加所述用戶設備的信息；若否，創(chuàng)建包括所述用戶設備信息文件的用戶設 備信息文件；若所述注冊通知消息為去注冊通知消息，從所述用戶設備信息文件中刪 除所述用戶設備的信息。
9、 如權利要求8所述的提供聯系人信息的方法，其特征在于，若刪除了 所述用戶設備的信息的用戶設備信息文件沒有任何用戶設備的信息，刪除所 述用戶設備信息文件。
10、 如權利要求1所述的提供聯系人信息的方法，其特征在于，所述訂 閱請求消息一由用戶設備發(fā)送、或由業(yè)務服務器根據用戶的服務設置發(fā)送。
11、 一種網絡設備，其特征在于，包括訂閱請求消息接收單元，用于接收訂閱聯系人信息的訂閱請求消息一 ，所述訂閱請求消息一 包括用戶的公共用戶標識；訂閱請求消息生成單元，用于生成與所述訂閱請求消息一對應的訂閱請 求消息二；訂閱請求消息發(fā)送單元，用于將所述訂閱請求消息二發(fā)送至與所述聯系 人信息對應的聯系人信息服務器；聯系人信息接收單元，用于接收來自所述聯系人信息服務器的所述聯系 人信息變化的消息；聯系人信息發(fā)送單元，用于向用戶設備信息文件中記錄的用戶設備發(fā)送 所述變化后的聯系人信息，所述用戶設備信息文件與所述公共用戶標識對應， 所述用戶設備信息文件記錄有歸屬于所述用戶的所有通過注冊的用戶設備信 息。
12、 如權利要求11所述的網絡設備，其特征在于，還包括激活狀態(tài)判斷單元，用于判斷所述用戶設備信息文件中記錄的用戶設備 的狀態(tài)是否為激活；所述聯系人信息發(fā)送單元，用于向所述激活狀態(tài)判斷單元判斷為激活的 用戶設備發(fā)送變化后的聯系人信息。
13、 如權利要求11所述的網絡設備，其特征在于，還包括接收設置判斷單元，用于判斷所述用戶設備信息文件中記錄的用戶設備 是否設置為接收變化后的聯系人信息；所述聯系人信息發(fā)送單元，用于向所述接收設置判斷單元判斷為設置為 接收變化后的聯系人信息的用戶設備，發(fā)送變化后的聯系人信息。
14、 如權利要求11至13任一所述的網絡設備，其特征在于，所述聯系 人信息保存在聯系人信息文檔中，該網絡設備還包括聯系人信息文檔更新單元，用于在所述聯系人信息接收單元接收所述聯 系人信息變化的消息后，更新包括所述聯系人信息的聯系人信息文檔。
15、 如權利要求14所述的網絡設備，其特征在于，所述訂閱請求消息一 由用戶設備一發(fā)送，所述網絡設備還包括觸發(fā)單元，用于觸發(fā)所述用戶設備信息文件記錄的用戶設備中除用戶設 備一外的用戶設備，訂閱所述聯系人信息文檔的更新；所述聯系人信息發(fā)送單元，用于向所述訂閱了所述聯系人信息文檔更新 的用戶設備和所述用戶設備一，發(fā)送變化后的聯系人信息。
16、 一種提供聯系人信息的系統，其特征在于，包括網絡設備，接收訂閱聯系人信息的訂閱請求消息一，所述訂閱請求消息 一包括用戶的公共用戶標識；生成與所述訂閱請求消息一對應的訂閱請求消 息二，并發(fā)送所述訂閱請求消息二；與所述聯系人信息對應的聯系人信息服務器，用于接收所述訂閱請求消 息二；若所述聯系人信息發(fā)生變化，發(fā)送變化后的所述聯系人信息；所述網絡設備，還用于接收所述變化后的聯系人信息；查找所述公共用 戶標識對應的用戶設備，向所述用戶設備發(fā)送所述變化后的聯系人信息。
17、 如權利要求16所述的提供聯系人信息的系統，其特征在于，還包括 至少一個用戶設備，所述用戶設備用于接收所述變化后的聯系人信息。
18、 如權利要求17所述的提供聯系人信息的系統，其特征在于，所述訂 閱請求消息 一 由所述用戶設備中的用戶設備一發(fā)送。
19、 如權利要求16或17所述的提供聯系人信息的系統，其特征在于， 還包括業(yè)務服務器，用于發(fā)送所述訂閱請求消息一。
全文摘要
本發(fā)明涉及通信技術領域，公開了提供聯系人信息的方法、系統及網絡設備，其中方法包括接收訂閱聯系人信息的訂閱請求消息一，訂閱請求消息一包括用戶的URI；生成與訂閱請求消息一對應的訂閱請求消息二，將訂閱請求消息二發(fā)送至與聯系人信息對應的聯系人信息服務器；若收到來自所聯系人信息服務器的所述聯系人信息變化的消息，向用戶設備信息文件中記錄的UE發(fā)送所述變化后的聯系人信息，用戶設備信息文件與公共用戶標識對應，用戶設備信息文件記錄有歸屬于用戶的所有通過注冊的用戶設備信息；本發(fā)明還提供了對應的系統即網絡設備，使用本發(fā)明可以使用戶只需要在一個UE上發(fā)送訂閱請求，就可以在多個UE上收到通知消息。
文檔編號H04L12/16GK101335634SQ200710129549
公開日2008年12月31日 申請日期2007年6月29日 優(yōu)先權日2007年6月29日
發(fā)明者謙 孫, 宋雪飛, 彭程暉 申請人:華為技術有限公司