用于邀請訂閱聯(lián)系人信息的裝置和方法
【專利摘要】公開了一種高效地邀請訂閱聯(lián)系人信息的方法，該方法包括：從第一客戶端接收第一客戶端的特定聯(lián)系人信息的訂閱邀請請求；以及確定用于允許訂閱特定聯(lián)系人信息的條件是否被包含在訂閱邀請請求中，并且當條件被包括時向第二客戶端傳送包含地址信息的訂閱請求，其中通過地址信息能夠接收條件和特定聯(lián)系人信息。因此，有可能在支持各種類型的通信服務的通信系統(tǒng)中以高速提供通信服務而不浪費資源、電力、或存儲器。并且，有可能提供能夠容易地和迅速地根據(jù)用戶意圖的選擇來提供CAB服務的數(shù)據(jù)傳輸/接收方法。
【專利說明】用于邀請訂閱聯(lián)系人信息的裝置和方法
【技術領域】
[0001]本發(fā)明一般涉及融合地址簿(Converged Address Book, CAB)服務,更具體地,涉及用于基于融合地址簿服務來邀請訂閱聯(lián)系人信息(contact information)的裝置和方法。
【背景技術】
[0002]融合地址簿(CAB)服務是指基于這樣的單一網(wǎng)絡的地址簿服務:所述單一網(wǎng)絡存儲可以被用戶的各種終端使用的地址信息，允許該信息能夠在任何時間和任何地點被任何設備訪問，以及同步地址信息。這樣的融合地址簿服務對應于用于改善地址簿的用戶體驗和地址簿的功能的目的、通過將單一的網(wǎng)絡地址簿存儲在網(wǎng)絡中來提供的服務。融合地址簿服務的主要功能可以包括地址簿同步、聯(lián)系人訂閱、聯(lián)系人共享、聯(lián)系人搜索、從非CAB系統(tǒng)的外部地址簿導入、等等。
[0003]在以上列出的功能中，聯(lián)系人訂閱功能是通過這樣的方法來執(zhí)行的:發(fā)起方(originating side)邀請接收方(receiving side)訂閱發(fā)起方的聯(lián)系人信息。為此,在現(xiàn)有技術中，該方法是以這樣的類型來實施的:直接向接收方傳送關于訂閱請求主題的信息并且存儲該信息，然后傳送聯(lián)系人狀態(tài)信息，如圖1中所示。
[0004]參考圖1，當CAB客戶端AlO在步驟I中將訂閱邀請請求存儲在CAB服務器20中時，CAB服務器20執(zhí)行一系列操作以便邀請CAB客戶端B60的用戶B訂閱CAB客戶端AlO的聯(lián)系人信息。然而，在現(xiàn)有技術中，CAB客戶端AlO的全部聯(lián)系人信息在步驟4中被傳遞到包括CAB客戶端B60的CAB服務器50中，而不管CAB客戶端B60是否接受訂閱。當訂閱在步驟5中被接受時，關于訂閱請求主題的信息，S卩，整個所接收的聯(lián)系人信息和訂閱邀請在步驟6中被存儲，并且在步驟7中，CAB客戶端B60的用戶B認識到用戶A邀請用戶B訂閱用戶A的聯(lián)系人信息。此外，當在步驟5中訂閱沒有被接受時，全部所接收的聯(lián)系人信息沒有被存儲。

【發(fā)明內容】

[0005]技術問題
[0006]如上所述，雖然CAB客戶端AlO邀請CAB客戶端B60訂閱用戶A的聯(lián)系人信息，但是在步驟4中用戶A的整個聯(lián)系人信息被傳送。因此，即使用戶A期望與用戶B共享用戶A的僅僅一部分聯(lián)系人信息，但是不存在能夠支持它的方法。此外，因為實際的聯(lián)系人信息被從用戶A的CAB服務器20傳送到用戶B的CAB服務器50而不管CAB客戶端B60是否已經(jīng)接受還是拒絕了訂閱邀請，因此效率受到損害，這是由于處理能力沒有被高效地使用并且CAB服務器和CAB XDMS內的不必要的存儲空間被使用。
[0007]此外，當在步驟5中CAB客戶端B60的用戶B拒絕訂閱時，來自其它客戶端的全部請求和對于訂閱CAB客戶端AlO的聯(lián)系人信息的請求一樣通通被拒絕。也就是說，不能針對每個客戶端分別地設定接受或拒絕。因此，需要一種高效地邀請訂閱聯(lián)系人信息的方法。[0008]技術方案
[0009]因此，本發(fā)明提供用于高效地邀請訂閱聯(lián)系人信息的裝置和方法。
[0010]另外，本發(fā)明提供用于邀請選擇性地訂閱聯(lián)系人信息的僅僅一部分的裝置和方法。
[0011]根據(jù)本發(fā)明的一個方面，提供了一種融合地址簿服務器中的邀請訂閱聯(lián)系人信息的方法。該方法包括:從第一客戶端接收第一客戶端的特定聯(lián)系人信息的訂閱邀請請求；和確定用于允許訂閱所述特定聯(lián)系人信息的條件是否被包括在所述訂閱邀請請求中，并且當所述條件被包括時向第二客戶端傳送包括地址信息的訂閱請求，其中通過所述地址信息能夠接收所述條件和所述特定聯(lián)系人信息。
[0012]根據(jù)本發(fā)明的另一個方面，提供了一種用于邀請訂閱聯(lián)系人信息的融合地址簿XML文檔管理服務器(XDMS)。所述融合地址簿XML文檔管理服務器(XDMS)包括:融合地址簿特征處理器應用用法，用于當從第一客戶端接收到第一客戶端的特定聯(lián)系人信息的訂閱邀請請求時，向融合地址簿服務器通知包含允許訂閱所述特定聯(lián)系人信息的條件的聯(lián)系人共享請求；和個人聯(lián)系卡應用用法，用于存儲由所述融合地址簿服務器按所述條件篩選后的特定聯(lián)系人信息，以及向第二客戶端轉發(fā)包含地址信息的訂閱請求，其中通過所述地址信息能夠接收所述特定聯(lián)系人信息。
[0013]發(fā)明的有益效果
[0014]根據(jù)本發(fā)明，有可能通過本發(fā)明提出的系統(tǒng)和方法來提供更高效的聯(lián)系人信息管理方法給用戶。另外，根據(jù)本發(fā)明，發(fā)起方能夠對訂閱全部聯(lián)系人信息中的僅僅期望的一部分做出請求，而接收方能夠選擇性地只接收期望的客戶端的聯(lián)系人信息。此外，通過傳送關于聯(lián)系人信息的地址信息而不是實際的聯(lián)系人信息，有可能提高傳輸效率并且還提高CAB服務器和CAB XDMS的存儲效率。
【專利附圖】

【附圖說明】
[0015]圖1是用于描述傳統(tǒng)的聯(lián)系人信息訂閱邀請方法的視圖；
[0016]圖2是根據(jù)本發(fā)明實施例的用于聯(lián)系人信息訂閱邀請的系統(tǒng)的配置圖；
[0017]圖3示出根據(jù)本發(fā)明實施例的聯(lián)系人信息訂閱邀請過程；
[0018]圖4詳細示出圖3的過程；
[0019]圖5示出圖3的聯(lián)系人共享請求消息的示例；
[0020]圖6示出用于允許圖3中的接收者的訂閱的訪問許可文檔的示例；
[0021]圖7示出圖4的XDCP轉發(fā)請求消息的示例；
[0022]圖8示出圖4的XDCP轉發(fā)遠程請求消息的示例；
[0023]圖9示出根據(jù)本發(fā)明實施例的處于接受狀態(tài)的聯(lián)系人信息訂閱邀請過程；
[0024]圖10示出圖9的聯(lián)系人狀態(tài)的示例；以及
[0025]圖11示出圖9的請求通知列表的示例。
【具體實施方式】
[0026]以下，將參考附圖描述本發(fā)明的各種實施例。相同的元素將被相同的參考標號指定，即使它們被示出在不同的附圖中。此外，當結合于此的熟知功能和配置使得本發(fā)明的主題非常不清楚時，將省略其詳細描述。
[0027]在將要在下面描述的詳細描述中，用于解決上述技術問題的本發(fā)明的代表性實施例將被建議。此外，為了方便描述本發(fā)明，開放移動聯(lián)盟(OMA)的融合地址簿(CAB)中定義的實體的名稱將被使用，其中開放移動聯(lián)盟(OMA)是移動終端的應用的標準組織，但是所述標準和名稱并不限制本發(fā)明的范圍，并且可以被應用到具有與本發(fā)明的技術背景類似的技術背景的系統(tǒng)中。
[0028]本發(fā)明提出一種高效地執(zhí)行聯(lián)系人信息訂閱邀請的方法。因此，本發(fā)明包括這樣一個過程:當?shù)谝豢蛻舳俗龀鰧Φ谝豢蛻舳说奶囟?lián)系人信息的訂閱邀請請求時，CAB服務器確定允許訂閱所述特定聯(lián)系人信息的條件是否被包括，并且將包含所述條件以及所述特定聯(lián)系人信息的地址信息的訂閱請求傳送到第二客戶端。通過所述過程，有可能在支持各種類型的通信服務的通信系統(tǒng)中以高速提供通信服務而不浪費資源、電力、或存儲器。此夕卜，有可能提供能夠容易地迅速地根據(jù)用戶意圖的選擇來提供CAB服務的數(shù)據(jù)傳輸/接收方法。
[0029]通過圖2參考OMA CAB的概念結構，CAB服務系統(tǒng)包括融合地址簿(以下稱為“CAB”)客戶端100、CAB服務器110、CAB XML文檔管理服務器(以下稱為“CAB XDMS”) 120、和非CAB系統(tǒng)130。
[0030]首先，CAB客戶端100在終端上與CAB服務器110通信，并且用來(serveto)認證CAB用戶，同步個人聯(lián)系卡(以下稱為“PCC”)信息和存儲在網(wǎng)絡存儲空間中的融合地址簿，以及向CAB服務器110傳送CAB用戶的需求，例如，地址訂閱、地址搜索、地址共享、與傳統(tǒng)地址簿的交互、或者用戶偏好的管理。
[0031]特別地，根據(jù)本發(fā)明實施例的CAB客戶端100是指用戶A的終端，并且用來傳送用于推薦用戶B根據(jù)用戶A的請求訂閱用戶A的聯(lián)系人信息的聯(lián)系人共享請求。聯(lián)系人共享請求包含作為個人信息(PCC)中的一部分聯(lián)系人視圖的條件的篩選值(filter value)。聯(lián)系人共享請求是指對于由用戶B訂閱用戶A的一部分聯(lián)系人信息的請求，并且具體地，可以包含用于告知請求被訂閱的一部分聯(lián)系人信息是什么的篩選值。
[0032]這里，根據(jù)本發(fā)明實施例的聯(lián)系人信息包含地址簿、名片信息、和個人信息(PCC)中的至少一個，并且聯(lián)系人視圖是指，例如，根據(jù)用戶的需要將諸如包括名稱、電話號碼、和電子郵件地址的個人信息的一些信息做成一個組。也就是說，聯(lián)系人視圖意味著選擇性地提取將要被共享的全部聯(lián)系人信息的一部分，然后將所提取的信息形成為子集。
[0033]CAB服務器110是CAB結構所述網(wǎng)絡的主要組件，并且用來從CAB客戶端100接收CAB用戶的請求和處理所述請求。作為主要功能，CAB服務器110用來互相認證CAB客戶端、存儲CAB地址、同步地址信息、從地址訂閱功能接收地址信息更新、以及將所述地址信息更新反映在地址簿中。
[0034]CAB服務器110執(zhí)行用于反映地址訂閱/共享/轉換、用戶偏好/策略、等等的網(wǎng)絡管理的操作。此外，CAB服務器110具有與傳統(tǒng)的地址簿系統(tǒng)互操作或者將接口暴露給外部啟用器(external enabler)的互操作功能(IWF)。
[0035]CAB服務器110從CAB客戶端100接收包含用于允許選擇性訂閱聯(lián)系人信息的篩選值的聯(lián)系人信息共享請求。然后，CAB服務器110生成地址信息，通過該地址信息，根據(jù)篩選值選擇的CAB客戶端100的特定聯(lián)系人信息被接收。包含最新生成的地址信息的請求通過包括用戶A的CAB服務器(例如，XDMS130)被傳遞到包括用戶B的CAB服務器(例如，XDMS140)。如上所述，CAB服務器110用來最新生成通過其可以接收聯(lián)系人信息的地址信息，S卩，URL信息而不是實際的聯(lián)系人信息，以便減少傳輸負載以及提供URL信息。
[0036]用于管理用戶的數(shù)據(jù)的CAB XDMS120包括:CAB地址簿應用(CAB AB App)用法(usage)，用于存儲融合地址簿和聯(lián)系人狀態(tài)，所述聯(lián)系人狀態(tài)用于區(qū)分傳統(tǒng)的用戶和CAB用戶；CAB用戶偏好應用(CAB UP App)用法，用于存儲用戶偏好；CAB個人聯(lián)系卡應用(CABPCC App)用法，用于存儲個人聯(lián)系卡信息；以及CAB特征處理器應用(CAB FH App)用法，用于管理CAB服務請求和響應。此外，CAB XDMS120包括用于訪問各種應用用法功能的XDMC、用于與外部域的實體的消息路由的SIP/IP核心網(wǎng)絡、用于傳遞非SIP終端的通知消息的推送啟用器、等等。
[0037]在本發(fā)明的實施例中，當用戶期望邀請另一個用戶訂閱個人簡檔信息，例如，圖2的融合地址簿系統(tǒng)內的PCC信息時，用于做出包含標準化邀請消息(例如，“聯(lián)系人訂閱邀請”)的聯(lián)系人共享請求的新的方案被定義在CAB特征處理器應用用法內。另一方面，CAB服務器110賦予接收者訂閱用于相應的聯(lián)系人共享請求的個人簡檔信息的權利，將相應的聯(lián)系人共享請求傳送到接收方，以及根據(jù)由接收者設定的針對他人的訂閱請求的用戶偏好來處理包含相應的個人簡檔信息訂閱邀請的聯(lián)系人共享請求，所述用戶偏好也就是接受、拒絕、和確認，其最終以聯(lián)系人狀態(tài)信息的形式來提出邀請接收者訂閱聯(lián)系人信息的方法。這里，用戶偏好確認是指用于向接收者告知他人的訂閱請求以及詢問是否接受所述訂閱請求的設定。
[0038]為了詳細地描述用戶偏好確認，將參考圖3描述根據(jù)本發(fā)明實施例的聯(lián)系人信息訂閱邀請過程。圖3示出通過XML文檔遞送的聯(lián)系人信息訂閱邀請方法的示例。
[0039]參考圖3，在步驟300中，CAB客戶端AlOO向CAB XDMS130內的CAB特征處理器應用用法傳送聯(lián)系人共享請求。在這時，XML配置訪問協(xié)議(XCAP)請求被用于聯(lián)系人共享請求。聯(lián)系人共享請求包含:標準化邀請消息，用于邀請接收者(例如，XU1:sip:bobi_example, com)訂閱用于個人信息(PCC)當中的特定聯(lián)系人視圖的聯(lián)系人信息；和可選的篩選值，用于允許訂閱僅僅一部分聯(lián)系人視圖。此外，很清楚的是，標準化邀請消息能夠被已經(jīng)接收了接收者的聯(lián)系人信息訂閱邀請消息的服務器自動地生成。
[0040]響應于所述請求，CAB XDMS130在步驟305中通知所述聯(lián)系人共享請求。為此，CABXDMS130內的CAB特征處理器應用用法響應于聯(lián)系人共享請求，向CAB服務器110內的聯(lián)系人共享功能105告知CAB特征處理器的文檔變化，即，文檔更新信息。
[0041]在步驟310中，CAB服務器110更新接收者的訪問許可文檔。具體地說，訪問許可文檔是響應于在步驟305中獲取的聯(lián)系人共享請求、基于文檔更新信息而在CAB XDMS120內的PCC應用用法里被更新，以便允許接收者根據(jù)發(fā)起者的聯(lián)系人信息訂閱邀請進行訂閱。在這時，為了限制對聯(lián)系人信息的訂閱而被包含的篩選信息也被反映在訪問許可文檔中。這對應于事先認證訂閱發(fā)起者(例如，用戶A)的聯(lián)系人信息的接收者(例如，用戶B)的過程。CAB服務器110可以從用戶A的多個接收者的聯(lián)系人信息中接收多個不同的訂閱許可請求，并且可以用來為用戶A的所述多個訂閱許可請求管理訂閱許可請求，S卩，創(chuàng)建、更新、刪除、等等。
[0042]隨后，在步驟315中，CAB服務器110轉發(fā)請求。為了轉發(fā)請求，CAB服務器110生成和使用XDCP轉發(fā)請求。XDCP轉發(fā)請求包含用于聯(lián)系人信息訂閱邀請的標準化消息以及用于允許訂閱僅僅一部分聯(lián)系人視圖的篩選值。特別地，CAB服務器110生成通過其能夠實際接收特定聯(lián)系人信息的URL信息，將所生成的URL信息插入轉發(fā)請求中，并且傳送所述轉發(fā)請求。如上所述，因為本發(fā)明使用“HTTP POST”而不是傳統(tǒng)的“SIP MESSAGE”，所以只有通過其接收聯(lián)系人信息的信息才能夠被傳送，而不是實際的聯(lián)系人信息被傳送，并且部分的聯(lián)系人信息可以通過篩選值來提供。
[0043]XDCP轉發(fā)請求被傳送到CAB XDMS120內的PCC應用用法。CABXDMS120通過應用用于允許訂閱由發(fā)起者(即用戶A)為訂閱邀請指定的僅僅一部分特定聯(lián)系人視圖的篩選而生成新的聯(lián)系人視圖，然后將所生成的新的聯(lián)系人視圖存儲在PCC應用用法內的臨時存儲空間或者分離的文檔存儲空間中。隨后，在步驟320中，CAB XDMS120轉發(fā)包含用于所述文檔的URI值和用于聯(lián)系人信息訂閱邀請的標準化消息的遠程請求。此外，CAB XDMS120可以通過應用來自全部聯(lián)系人信息的篩選，來生成使得僅僅特定聯(lián)系人視圖能夠被顯示給特定接收者的URI值。XDCP轉發(fā)遠程請求被用于所述遠程請求。
[0044]XDCP轉發(fā)遠程請求被傳送到包括接收方(即用戶B)的CAB XDMS130。然后，在步驟325中，CAB XDMS130的PCC應用用法基于所接收的XDCP轉發(fā)遠程請求來處理所述遠程請求。也就是說，CAB XDMS130執(zhí)行對于用戶B的地址簿文檔遞送的偏好確認。對地址簿文檔遞送的偏好可以包括諸如接受、拒絕、確認等等的設定。接受意味著當用戶B接收到來自他人的訂閱請求時直接存儲所接收的文檔而不詢問用戶B，拒絕意味著不接受他人的訂閱請求，而確認意味著向用戶B告知他人的訂閱請求、從用戶B接收對訂閱請求的響應(例如，接受或拒絕)、并且處理該響應。因此，當偏好對應于接受時，CAB XDMS(130)通過使用從用戶A接收的、將被用于聯(lián)系人信息訂閱邀請的文檔的URI值，從存儲該文檔的服務器中取出該文檔，并且將該文檔存儲為臨時文檔，例如，ContactInvitationPCC.xml類型的臨時文檔。
[0045]在步驟330，接收方的CAB服務器140被CAB XDMS130的PCC應用用法告知所述臨時文檔。具體地說，CAB服務器被告知包含對應于所述臨時文檔的“ContactSharePCC.xml”和作為文檔變化的“note”的聯(lián)系人邀請文檔，或者被通知包含“ContactlnvitationPCC.xml”和作為文檔變化的“note”的聯(lián)系人邀請文檔。
[0046]在步驟335中，CAB服務器140存儲聯(lián)系人條目。聯(lián)系人條目的示例包括地址，并且地址共享數(shù)據(jù)根據(jù)地址簿格式而被轉換，然后被添加到XDMS130的AB應用用法內的地址簿文檔(AB文檔)中。此外，通過參考步驟330中的聯(lián)系人邀請文檔，地址類型被顯示為聯(lián)系人狀態(tài)，更新類型(〈updated〉)被顯示為條目狀態(tài)，并且與從發(fā)起者傳送的用于聯(lián)系人信息訂閱邀請的標準化消息(或者表達)相對應的〈note〉元素被顯示。
[0047]之后，在步驟340中，CAB服務器140傳送包含AB應用用法中所生成的文檔變化的服務器通知消息，以便同步CAB客戶端B150的地址簿。因此，通過地址簿的同步，CAB客戶端B150的用戶B能夠查看被用戶A允許訂閱的聯(lián)系人信息。
[0048]以下，將參考圖4更加詳細地描述圖3。圖4詳細地示出發(fā)起方中的聯(lián)系人信息分享。
[0049]參考圖4，步驟400與圖3的步驟300相同。更詳細地說，聯(lián)系人共享請求包含所述共享請求的結果報告，并且用于聯(lián)系人信息訂閱邀請的標準化消息(“聯(lián)系人訂閱邀請”)被包含在所述共享請求內的“note”元素中。用于聯(lián)系人共享請求的消息在圖5中被示出。
[0050]參考圖5，稍后，“note”元素中的標準化消息(“聯(lián)系人訂閱邀請”)在發(fā)起方和接收方中充當指示，其指示聯(lián)系人共享請求是對于共享發(fā)起者的聯(lián)系人信息訂閱邀請中的聯(lián)系人的請求。此外，在圖5中，在接收者(XU1: sip:bob@_example.com)最終接受僅僅針對名稱、通訊(comm-addr (通信-地址))、和職業(yè)(career-history (職業(yè)-歷史))的聯(lián)系人信息訂閱邀請之后，當對發(fā)起者的聯(lián)系人信息的訂閱被嘗試時，用于允許相應的文檔的僅僅一部分值的篩選值被設定，以便訂閱或者讀取聯(lián)系人信息。
[0051]在步驟405中，CAB XDMS120的CAB特征處理器應用用法存儲XCAP請求，并且向CAB客戶端A100傳送響應消息(2000K)。
[0052]在步驟410中，CAB特征處理器應用用法向CAB服務器110內的聯(lián)系人共享功能105告知CAB特征處理器的文檔變化，即，用于相應的共享請求的文檔更新信息。這里，除了由CAB特征處理器應用用法告知所述變化信息之外，聯(lián)系人共享功能105還可以通過主動地識別聯(lián)系人共享請求消息是否被存儲來獲取CAB特征處理器內的變化信息。
[0053]響應于步驟410，在步驟415中，聯(lián)系人共享功能105向CAB特征處理器應用用法傳送響應消息(2000K)。隨后，步驟420與圖3的步驟310相同。更詳細地說，聯(lián)系人共享功能105通過使用XDM代理、基于用于在步驟410中獲取的聯(lián)系人共享請求的文檔更新信息內所包括的篩選信息，來更新訪問許可文檔，以便限制對接收者信息和聯(lián)系人信息的訂閱，從而允許接收者根據(jù)相應的PCC應用用法內的發(fā)起者的聯(lián)系人信息訂閱邀請來進行訂閱。
[0054]圖6示出用 于允許接收者根據(jù)PCC應用用法內的聯(lián)系人信息訂閱邀請進行訂閱的訪問許可文檔的示例。
[0055]參考圖6,作為發(fā)起者(XU1: sip:alice@_examplel.com)的聯(lián)系人信息中的個人信息(PCC)的文檔規(guī)則的“allow-retrieve (允許-檢索)”意味著接收者能夠訂閱或者讀取發(fā)起者的整個聯(lián)系人信息。此外，通過基于用于在步驟410中獲取的聯(lián)系人共享請求的文檔更新信息中所包括的篩選信息(invite-1nclude (邀請-包括))來更新訪問許可文檔以便限制對接收者(XU1:sip:bob@_example.com)信息和聯(lián)系人信息的訂閱，當接收者最終接受僅僅針對發(fā)起者的個人信息當中的名稱、聯(lián)系、和職業(yè)(career-hi story)的聯(lián)系人信息訂閱邀請并且嘗試訂閱發(fā)起者的聯(lián)系人信息時，訂閱或者讀取被允許。
[0056]聯(lián)系人共享功能105在步驟425中從PCC應用用法接收響應消息(2000K)，然后在步驟430中通過使用XDM代理來生成并傳送XDCP轉發(fā)請求，以便與相應的PCC應用用法共享聯(lián)系人信息。在這時，用于允許訂閱步驟410中獲取的聯(lián)系人視圖的僅僅一部分值的篩選信息被包括。此外，用于聯(lián)系人信息訂閱邀請的標準化消息(或者表達)，即，“聯(lián)系人訂閱邀請”，被包括在XDCP轉發(fā)請求內的“note”元素中。由聯(lián)系人共享功能105生成的XDCP轉發(fā)請求被示出在圖7中。
[0057]隨后，在步驟435中，PCC應用用法首先識別是否做出了用于發(fā)起者的聯(lián)系人共享的聯(lián)系人共享遞送報告。隨后，為了將遞送結果通知給發(fā)起者，通過將“note”元素插入列表XDMS的轉發(fā)通知列表(以下稱為“FNL”)應用用法內的轉發(fā)通知列表(<forward-notification-1 ist>)兀素的遞送通知列表 ?delivery-notification-1 ist>)元素中、并且將相應的接收者的遞送狀態(tài)值設定為“未決”，來更新有關的信息。響應于所述更新，在步驟440中，PCC應用用法從列表XDMS125接收響應消息(2000K)。
[0058]然后，PCC應用用法基于XDCP轉發(fā)請求來識別出接收者是另一領域(domain)的用戶，應用用于允許訂閱由發(fā)起者為訂閱邀請指定的特定聯(lián)系人視圖的僅僅一部分值的篩選，然后將所述聯(lián)系人視圖存儲在PCC應用用法內的臨時存儲空間或者分離的文檔存儲空間中。
[0059]然后，在步驟445中，XDCP將包含用于所述文檔的URI值和用于個人信息訂閱邀請的標準化消息的遠程請求轉發(fā)到接收方。由發(fā)起方的PCC應用用法生成的XDCP轉發(fā)遠程請求被示出在圖8中。此后，在步驟450中，PCC應用用法從接收方的網(wǎng)絡127&129接收用于遞送結果的響應消息(2000K)。然后，在步驟455中，PCC應用用法從用于遞送結果的響應消息(2000K)中生成用于XDCP轉發(fā)請求的響應消息(2000K)。
[0060]此后，在步驟460中，聯(lián)系人共享功能105存儲轉發(fā)結果。也就是說，聯(lián)系人共享功能105將遞送結果存儲在CAB特征處理器應用用法中，并且CAB特征處理器應用用法在步驟465中向聯(lián)系人共享功能105傳送響應消息(2000K)。
[0061]在步驟470中，PCC應用用法從接收方的網(wǎng)絡127&129接收聯(lián)系人共享遞送報告。響應于步驟470，PCC應用用法在步驟475中向接收方的網(wǎng)絡127&129傳送響應消息(2000K)。
[0062]然后，在步驟480中，PCC應用用法更新轉發(fā)通知列表。具體地說，為了向接收者通知遞送結果，通過在列表XDMS的轉發(fā)通知列表(以下稱為“FNL”)內的轉發(fā)通知列表(<f orward-not if icat ion-1 ist>)兀素的遞送通知列表 ?del ivery-not if icat ion-1 ist>)元素中將相應的接收者的遞送狀態(tài)值設定為“已遞送”，來更新有關的信息。當更新完成時，在步驟485中，PCC應用用法從列表XDMS125中接收響應消息(2000K)。
[0063]此后，在步驟490中，CAB服務器105內的XDM代理被告知遞送報告的結果，并且在步驟490中在CAB FH應用用法內更新相應的聯(lián)系人共享請求的遞送狀態(tài)。
[0064]同時，圖9詳細地示出當接收者對于XML文檔遞送的用戶偏好被設定為‘接受’時邀請訂閱個人息的方法。
[0065]參考圖9，在步驟900中，包括CAB客戶端B150的PCC應用用法從發(fā)起方的網(wǎng)絡127&129接收XDCP轉發(fā)遠程請求。然后，PCC應用用法識別XDCP轉發(fā)遠程請求內的接收者是否處于相應的領域中，并且然后在步驟905中向包括CAB客戶端AlOO的PCC應用用法傳送響應消息(2000K)。
[0066]隨后，在步驟910中，CAB XDMS130的PCC應用用法從AB應用用法內的AB轉發(fā)偏好中識別CAB客戶端B150對于XDCP轉發(fā)遠程請求的偏好。AB轉發(fā)偏好包括下列情況，并且CAB客戶端B150接收(接受)從CAB客戶端AlOO接收的XDM資源的情況在這里被描述。
[0067]在步驟915中，當所述偏好對應于接受時，從發(fā)起方傳送的XDM資源被自動地存儲在相應的XDM服務器中。另一方面，當所述偏好對應于確認時，從發(fā)起方傳送的XDM資源被告知給接收者，然后其結果被等待。然而，當所述偏好對應于拒絕時，從發(fā)起方傳送的XDM資源不被存儲在相應的XDM服務器中并且被拒絕。此外，當所述偏好對應于拒絕時，步驟920之后的步驟不被執(zhí)行。
[0068] 具體地說，因為XDCP轉發(fā)遠程請求中所包括的所述文檔的URI，即，由發(fā)起者設定的用于允許訂閱由發(fā)起者為訂閱邀請指定的特定聯(lián)系人視圖的僅僅一部分值的篩選值被應用，所以接收方的PCC應用用法通過使用存儲在發(fā)起方的PCC應用用法內的臨時存儲空間或者分離的存儲空間中的所述文檔的URI，來從發(fā)起方的PCC應用用法中取出XDM資源。然后，如傳統(tǒng)的地址共享請求方法中所示，在XDCP轉發(fā)遠程請求中所包括的“note”元素中的用于個人信息訂購邀請的標準化消息(或者表達)，即，“聯(lián)系人訂閱邀請”之后，XDM資源可以以 “ContactSharePCC.xml” 的文件形式存儲，或者以 “ContactlnvitationPCC.xml”的新的文件形式存儲。
[0069]隨后，在步驟920中，CAB服務器140被接收方的PCC應用用法告知臨時文檔。具體地說，CAB服務器140被告知“ContactSharePCC.xml ”和包含作為文檔變化的“note”元素的聯(lián)系人邀請文檔，或者被告知“ContactlnvitationPCC.xml”和包含作為文檔變化的“note”元素的聯(lián)系人邀請文檔。此外，根據(jù)系統(tǒng)實施方式，可以通過分開地生成包含“note”元素的聯(lián)系人邀請文檔而不包括聯(lián)系人邀請文檔，但是可以以新的標頭形式將聯(lián)系人邀請文檔包括在通知請求消息(SIP NOTIFY)內。例如，CAB服務器140以“ContactSharePCC.xml”和聯(lián)系人邀請文檔的形式被告知文檔變化。CAB服務器140可以主動地在接收方中的PCC應用用法內獲取對應于文檔變化信息的信息，除了被接收方中的PCC應用用法告知該信息之外。
[0070]響應于所述接收，在步驟925中，CAB服務器140將響應消息(2000K)傳送到PCC應用用法，然后在步驟930中更新地址簿。具體地說，CAB服務器140將聯(lián)系人信息共享數(shù)據(jù)轉換為AB格式，然后將轉換后的聯(lián)系人信息共享數(shù)據(jù)添加到AB應用用法內的AB文檔中。然后，通過參考聯(lián)系人邀請文檔或者包括在通知請求消息中的與“note”有關的標頭，CAB服務器140將下面的地址類型顯示為聯(lián)系人狀態(tài)，將更新類型(〈updated〉)顯示為條目狀態(tài)，并且顯示與從發(fā)起者傳送的用于個人信息訂閱邀請的標準化消息(或者表達)相對應的〈note〉元素。
[0071]這樣的聯(lián)系人狀態(tài)被示出在圖10中。圖10示出了除了 AB文檔內的聯(lián)系人共享數(shù)據(jù)之外、為了聯(lián)系人信息訂閱邀請而添加的聯(lián)系人狀態(tài)。
[0072]此后，在步驟935，AB應用用法向CAB服務器140傳送響應消息(2000K)。
[0073]在步驟940中，PCC應用用法將<request-notification-list>元素添加到列表XDMS132的轉發(fā)通知列表中，以便向接收者通知所接收的XDCP轉發(fā)遠程請求的詳細事項。在這時，作為用于聯(lián)系人信息訂閱邀請的標準化消息(或者表達)的“note”元素也被存儲在聯(lián)系人信息共享請求中。列表XDMS132的轉發(fā)通知列表內的包括“note”元素的〈request-notification_list> 兀素被不出在圖 11 中。
[0074]如圖11的請求通知列表的示例中所示,接收者可以通過相應的請求通知列表識別關于發(fā)起者(XU1: sip:alice@_examplel.com)的信息和用于聯(lián)系人信息訂閱邀請的標準化消息(或者表達)。這里，列表XDMS132的相應的請求通知列表的變化信息能夠被通知給接收者，或者接收者能夠主動地識別列表XDMS132的相應的請求通知列表，以便獲取列表XDMS132的相應的請求通知列表的變化信息。
[0075]在步驟945中，列表XDMS132向PCC應用用法傳送響應消息(2000K)。隨后，在步驟950中，CAB XDMS130生成聯(lián)系人共享遞送報告，并且將所述聯(lián)系人共享遞送報告?zhèn)魉偷桨l(fā)起方的網(wǎng)絡127&129。響應于步驟950，在步驟955中，CAB XDMS130從發(fā)起方的網(wǎng)絡127&129接收響應消息(2000K)。[0076]此后，在步驟960中，CAB服務器140向CAB客戶端B150傳送包括AB應用用法中所生成的文檔變化的服務器通知消息，以便同步CAB客戶端B150的地址簿。
[0077]此外，當接收方識別出發(fā)起方的訂閱邀請、然后接受所述訂閱邀請并且訂閱信息時，在后面的時間里聯(lián)系人信息訂閱過程將根據(jù)一般程序被執(zhí)行。然而，在這種情況下，當接收者(XU1:sip:bob@_example.com)接受聯(lián)系人信息訂閱邀請并且最終通過發(fā)起者的PCC應用用法內的預設的訪問許可(即對應于圖4的步驟420中的“invite-1nclude”的篩選ID)僅僅針對名稱、聯(lián)系(comm-addr)、和職業(yè)(career_history)嘗試訂閱發(fā)起者的聯(lián)系人信息時，聯(lián)系人信息訂閱結果根據(jù)允許訂閱或者讀取的設定而被告知，并且聯(lián)系人信息根據(jù)用戶偏好而被更新。
[0078]此外，當確認了接收方對于XML文檔遞送的用戶偏好不是接受時，則通過將所接收的AB文檔添加到AB應用用法中、將聯(lián)系人狀態(tài)設定為“臨時”、同步CAB客戶端B150的地址、直接表達接收者的確認意圖、以及移除“臨時”狀態(tài)來完成聯(lián)系人共享。
[0079]此外，本發(fā)明實施一種通過CAB FH應用用法向CAB服務器傳送聯(lián)系人共享請求的個人信息訂閱邀請方法。然而，在其它情況下，也就是，根據(jù)系統(tǒng)實施方式，可以在融合地址簿系統(tǒng)中的一般XDM文檔管理功能實施方式的容許范圍內修改以上實施例，在所述一般XDM文檔管理功能實施方式中，聯(lián)系人共享請求通過CAB客戶端和CAB XDMS之間的用于XDM文檔遞送請求/響應的直接接口、以XDM文檔遞送的形式被傳送到CAB XDMS,但是總體操作和方法與本發(fā)明范圍內的相同。
[0080]最后，雖然本發(fā)明實施一種邀請不同領域用戶之間的聯(lián)系人信息訂閱的方法，但是，通過在CAB服務器和CAB XMDS中的一般XDM文檔管理功能實施方式的容許范圍內對相同領域用戶之間的聯(lián)系人信息訂閱邀請進行一些修改，就可以實施邀請不同領域用戶之間的聯(lián)系人信息訂閱的方法，但是總體操作和方法與本發(fā)明范圍內的相同。
[0081]根據(jù)本發(fā)明，有可能通過本發(fā)明提出的系統(tǒng)和方法來提供更高效的聯(lián)系人信息管理方法給用戶。另外，根據(jù)本發(fā)明，發(fā)起方能夠對訂閱全部聯(lián)系人信息中的僅僅期望的一部分做出請求，而接收方能夠選擇性地只接收期望的客戶端的聯(lián)系人信息。此外，通過傳送關于聯(lián)系人信息的地址信息而不是實際的聯(lián)系人信息，有可能提高傳輸效率并且還提高CAB服務器和CAB XDMS的存儲效率。
【權利要求】
1.一種融合地址簿服務器中的邀請訂閱聯(lián)系人信息的方法，該方法包括: 從第一客戶端接收第一客戶端的特定聯(lián)系人信息的訂閱邀請請求；和 確定用于允許訂閱所述特定聯(lián)系人信息的條件是否被包括在所述訂閱邀請請求中，并且當所述條件被包括時向第二客戶端傳送包括地址信息的訂閱請求，其中通過所述地址信息能夠接收所述條件和所述特定聯(lián)系人信息。
2.如權利要求1所述的方法，其中，通過傳送方的融合地址簿XML文檔管理服務器(XDMS)來接收所述訂閱邀請請求。
3.如權利要求1所述的方法，還包括通過將所述條件應用在第一客戶端的全體聯(lián)系人信息來生成篩選后的特定聯(lián)系人信息。
4.如權利要求1所述的方法，還包括生成通過其能夠接收所述特定聯(lián)系人信息的地址信息。
5.如權利要求1所述的方法，其中，所述訂閱請求通過使用HTTPPOST，從傳送方的融合地址簿XML文檔管理服務器(XDMS)被轉發(fā)到識別第二客戶端對于聯(lián)系人傳輸?shù)钠玫慕邮辗降娜诤系刂凡綳ML文檔管理服務器(XDMS)。
6.如權利要求5所述的方法，其中，第二客戶端的偏好是對于聯(lián)系人傳輸?shù)慕邮?、拒絕、和確認中的一個。
7.如權利要求6所述的方法，其中，當?shù)诙蛻舳说钠檬墙邮軙r，由所述接收方的融合地址簿XML文檔管理服務器(XDMS)使用所述地址信息從所述傳送方的融合地址簿XML文檔管理服務器(XDMS)取出的聯(lián)系人被存儲，而無需向第二客戶端詢問。
8.如權利要求1所述的方法，還包括，當所述訂閱邀請請求被接收時，基于第二客戶端的信息和包含在所述訂閱邀請請求中的條件來更新用于第二客戶端的訪問許可文檔。
9.一種用于邀請訂閱聯(lián)系人信息的融合地址簿XML文檔管理服務器(XDMS)，包括: 融合地址簿特征處理器應用用法，用于當從第一客戶端接收到第一客戶端的特定聯(lián)系人信息的訂閱邀請請求時，向融合地址簿服務器通知包含允許訂閱所述特定聯(lián)系人信息的條件的聯(lián)系人共享請求；和 個人聯(lián)系卡應用用法，用于存儲由所述融合地址簿服務器按所述條件篩選后的特定聯(lián)系人信息，以及向第二客戶端轉發(fā)包含地址信息的訂閱請求，其中通過所述地址信息能夠接收所述特定聯(lián)系人信息。
10.如權利要求9所述的融合地址簿XDMS，其中，所述個人聯(lián)系卡應用用法通過將所述條件應用在第一客戶端的全體聯(lián)系人信息來生成篩選后的特定聯(lián)系人信息。
11.如權利要求9所述的融合地址簿XDMS，其中，所述個人聯(lián)系卡應用用法生成通過其能夠接收所述特定聯(lián)系人信息的地址信息。
12.如權利要求9所述的融合地址簿XDMS，其中，所述訂閱請求通過使用HTTPPOST被轉發(fā)到識別第二客戶端對于聯(lián)系人傳輸?shù)钠玫慕邮辗降娜诤系刂凡綳ML文檔管理服務器(XDMS)。
13.如權利要求12所述的融合地址簿XDMS，其中，第二客戶端的偏好是對于聯(lián)系人傳輸?shù)慕邮?、拒絕、和確認中的一個。
14.如權利要求13所述的融合地址簿XDMS，其中，當?shù)诙蛻舳说钠檬墙邮軙r，由所述接收方的融合地址簿XML文檔管理服務器(XDMS)使用所述地址信息從所述個人聯(lián)系卡應用用法取出的聯(lián)系人被存儲，而無需向第二客戶端詢問。
15.如權利要求9所述的融合地址簿XDMS，其中，所述個人聯(lián)系卡應用用法更新和存儲用于允許第二客戶端根據(jù)所述融合地址簿服務器的訂閱邀請請求進行聯(lián)系人訂閱的訪問許可文檔。
【文檔編號】H04L29/06GK103988468SQ201280060404
【公開日】2014年8月13日 申請日期:2012年12月7日 優(yōu)先權日:2011年12月8日
【發(fā)明者】吳奎奉, 金旭, 李炅卓 申請人:三星電子株式會社