專利名稱：一種存在信息的訂閱、發(fā)布和更新方法
技術(shù)領(lǐng)域：
本發(fā)明涉及即時通信(IM，Instant Messaging)領(lǐng)域，特別涉及即時通信服務(wù)中存在消息的訂閱、發(fā)布和更新方法。
背景技術(shù)：
存在(Presence)是一種將用戶的狀態(tài)信息提供給觀察者的技術(shù)。Presence是NGN(下一代互聯(lián)網(wǎng)絡(luò))的優(yōu)勢業(yè)務(wù)，Presence業(yè)務(wù)能夠讓即時信息服務(wù)用戶設(shè)置在線狀態(tài)，可實時獲得好友的狀態(tài)信息，如是否在線、是否忙、目前希望以什么方式交互等。
目前即時通信系統(tǒng)最大的問題就是如何實現(xiàn)不同廠商IM服務(wù)的互通。這個問題的解決需要標準協(xié)議的支持。當(dāng)前，在Presence領(lǐng)域有三個主要協(xié)議在競爭，SIMPLE(SIP for Instant Messaging and Presence Leveraging)和XMPP(ExtensibleMessaging and Presence Protocol)，以及IMPS(Instant Messaging and PresenceService)。
SIMPLE的一個主要優(yōu)勢在于它是基于SIP的協(xié)議。因此，具有SIP帶來的諸如可擴展性、靈活性、高效性等優(yōu)勢。SIP協(xié)議被廣泛用于IP多媒體實時交互領(lǐng)域，SIMPLE的另一個優(yōu)勢是它將使IM能夠與現(xiàn)存的大量SIP終端兼容，并且得到了微軟和IBM等大廠商的支持。
專利200510059237.8“存在信息共享方法和系統(tǒng)”公開了在多個應(yīng)用之間共享存在信息，從而掌握不同類型的應(yīng)用的存在信息的改變。IM(X)服務(wù)器從客戶機接收存在信息的改變的通知，并且將用于通知存在信息的改變的改變通知消息發(fā)送到在場服務(wù)器。然后，在場服務(wù)器將從IM(X)服務(wù)器接收到的改變通知消息發(fā)送到IM(Y)服務(wù)器。IM(Y)服務(wù)器將從在場服務(wù)器接收到的改變通知消息發(fā)送到客戶機B2。
專利200510085286.9“存在信息的提供方法”公開了一種存在信息的提供方法，應(yīng)用在包括存在體、存在服務(wù)器和至少一個觀察體的存在系統(tǒng)中，包括步驟在存在服務(wù)器中針對存在體提供的同一存在信息分別設(shè)置對應(yīng)不同觀察體屬性的值；存在服務(wù)器根據(jù)觀察體屬性提供存在信息的對應(yīng)值。本發(fā)明可以實現(xiàn)根據(jù)不同的觀察體提供對應(yīng)的存在信息值的目的。
專利200510076893.9“一種訂閱存在信息的方法”公開了一種訂閱存在信息的方法。應(yīng)用于無線通信領(lǐng)域。用以解決現(xiàn)有技術(shù)存在當(dāng)訂閱失敗時，IMPS Server不向訂閱方用戶發(fā)送任何消息，使得該用戶無法確定訂閱是否成功的問題。本發(fā)明方法包括下列步驟A.訂閱方用戶向即時消息和存在業(yè)務(wù)服務(wù)器(IMPS Server)發(fā)送訂閱請求消息；B.IMPS Server根據(jù)所述訂閱請求消息向被訂閱方用戶發(fā)送授權(quán)請求消息；C.被訂閱方用戶確認后，向IMPS Server發(fā)送授權(quán)確認消息；D.若IMPS Server收到所述授權(quán)確認消息，并表明接受訂閱，則IMPS Server向訂閱方用戶發(fā)送訂閱成功消息；否則，IMPS Server向訂閱方用戶發(fā)送訂閱失敗消息。
本發(fā)明關(guān)注用戶之間存在信息的長期訂閱關(guān)系和上線后存在信息的自動發(fā)布與更新方法，并且本發(fā)明在以上專利的基礎(chǔ)上擴展了存在信息的范圍，采用了新的方法來攜帶存在信息，與上述各專利都不同。

發(fā)明內(nèi)容
本發(fā)明的目的是在SIMPLE協(xié)議下提供一種關(guān)于存在信息的訂閱、發(fā)布和更新方法。
為了實現(xiàn)上述目的，本發(fā)明提供了一種存在信息的訂閱方法，包括以下步驟步驟11)、第一用戶訂閱第二用戶的存在信息，第一用戶向第二用戶發(fā)送添加好友請求；步驟12)、第二用戶決定是否接受第一用戶所發(fā)出的添加好友請求，若接受，則向第一用戶返回接受請求的消息，并執(zhí)行下一步，若不接受，則向第一用戶發(fā)送不接受請求的消息后，終止操作，若第二用戶暫時無法決定是否接受，則發(fā)送表示未決的消息；步驟13)、第二用戶所屬的存在服務(wù)器接收到接受請求的消息后，在第二用戶的表示已訂閱第二用戶存在信息的好友列表中添加第一用戶；步驟14)、第一用戶所屬的存在服務(wù)器接收到接受請求的消息后，添加第二用戶為第一用戶的好友并記錄在存在數(shù)據(jù)庫中；步驟15)、第一用戶上線后從該用戶所屬的存在服務(wù)器得到本用戶的基本信息，并獲取好友列表，向好友名單中的好友發(fā)出存在信息訂閱請求；步驟16)、表示好友的用戶所屬的存在服務(wù)器接收到存在信息訂閱請求后，響應(yīng)該請求并發(fā)送本用戶的存在信息到第一用戶。
上述技術(shù)方案中，若第二用戶接受被訂閱，則第二用戶所在終端詢問用戶是否需要訂閱第一用戶的存在信息，若需要，則重新發(fā)起一個添加好友的流程。
上述技術(shù)方案中，在所述的步驟11)中，所述的添加好友請求為SIMPLESUBSCRIBE消息，該消息的Event頭域值為presence/initial，Expires頭域值為非0，在該消息中還包含了所要添加好友的統(tǒng)一資源標識信息。
上述技術(shù)方案中，在所述的步驟12)中，所述接受請求的消息為NOTIFY消息，該消息的Event頭域值為“presence/initial”，Subscription-State頭域值為“active”；所述不接受請求的消息為NOTIFY消息，該消息的Event頭域值為“presence/initial”，Subscription-State頭域值為“terminated”，消息體為空；所述表示未決的消息為NOTIFY消息，該消息的Event頭域值為“presence/initial”，Subscription-State頭域值為“pending”，消息體為空。
上述技術(shù)方案中，在所述的步驟15)中，所述的第一用戶通過SUBSCRIBE消息請求本用戶的基本信息，該消息的Event頭域值為“personalinfo”。
上述技術(shù)方案中，在所述的步驟15)中，所述的第一用戶通過NOTIFY消息得到本用戶的基本信息，該消息的Event頭域值為“personalinfo”，Content-Type頭域值為“application/xpidf+xml”，該消息的消息體中包含用戶昵稱、頭像等基本信息。
上述技術(shù)方案中，在所述的步驟15)中，所述的第一用戶通過SUBSCRIBE消息向所屬的存在服務(wù)器請求好友列表，該消息的Event頭域值為“buddylist”。
上述技術(shù)方案中，在所述的步驟15)中，所述的第一用戶通過NOTIFY消息從存在服務(wù)器得到好友列表，該消息的Event頭域值為“buddylist”，Subscription-State字段為active，該消息的消息體中包含了用戶的好友列表。
上述技術(shù)方案中，在所述的步驟15)中，所述的第一用戶通過SUBSCRIBE消息發(fā)出存在信息訂閱請求，該消息的Event頭域值為“presence/refresh”。
上述技術(shù)方案中，在所述的步驟16)中，通過類型為presence/refresh/active的NOTIFY消息將用戶的存在信息發(fā)送到第一用戶。
本發(fā)明還提供了一種存在消息的發(fā)布和更新方法，包括以下步驟步驟21)、一個用戶改變存在信息的設(shè)置，向本用戶所屬的存在服務(wù)器發(fā)送存在信息更新消息；步驟22)、改變存在信息的用戶所屬的存在服務(wù)器收到所述的發(fā)布消息后，更新存在數(shù)據(jù)庫中的該用戶的存在信息，并向該用戶發(fā)送響應(yīng)消息；步驟23)、改變存在信息的用戶所屬的存在服務(wù)器向所有好友發(fā)送用戶的存在信息更新消息，將用戶新的存在消息通知好友。
上述技術(shù)方案中，在所述的步驟21)中，所述的存在信息更新消息為PUBLISH(modify)類型的消息，該消息的SIP-If-Match頭域值為前一個PUBLISH消息應(yīng)答中的Entity-Tag的值，Expires頭域值為180，該消息的消息體包含用戶更新后的存在信息。
上述技術(shù)方案中，在所述的步驟23)中，通過NOTIFY消息發(fā)送用戶的存在信息更新消息，在所述NOTIFY消息中，Event的頭域值為“presence/refresh”，Subscription-State頭域值為“active”，Content-Type頭域值為“application/xpidft+xml”，該消息的消息體中包含了用戶更新后的存在信息。
本發(fā)明的優(yōu)點在于1、本發(fā)明中存在信息的訂閱、發(fā)布和更新流程簡明清晰，基于本發(fā)明能實現(xiàn)一個結(jié)構(gòu)簡明的，能支持大規(guī)模用戶的存在信息訂閱/發(fā)布系統(tǒng)；2、本發(fā)明擴展了存在消息的范圍，使用XML定義個性化的存在信息，如個人信息、通信方式、通信優(yōu)先級別等，具備良好的實用性和擴展性。


圖1為本發(fā)明的存在信息訂閱方法中的添加好友流程；圖2為添加好友流程中所采用的SUBSCRIBE(添加好友)消息格式的示意圖；圖3為添加好友流程中所采用的NOTIFY(未決)消息格式；圖4為添加好友流程中所采用的NOTIFY(接受被訂閱)消息格式；圖5為添加好友流程中所采用的NOTIFY消息體格式；圖6為添加好友流程中所采用的NOTIFY(拒絕被訂閱)消息格式；圖7為本發(fā)明的存在信息訂閱方法中用戶上線獲取存在信息的流程；圖8為獲取存在信息的流程中所采用的SUBSCRIBE(訂閱本用戶存在信息)消息格式；圖9為獲取存在信息的流程中所采用的NOTIFY(本用戶存在信息)消息格式；圖10為獲取存在信息的流程中所采用的SUBSCRIBE(用戶好友列表)消息格式；圖11為獲取存在信息的流程中所采用的NOTIFY(用戶好友列表)消息格式；圖12為獲取存在信息的流程中所采用的NOTIFY(用戶好友列表)消息體格式；圖13為獲取存在信息的流程中所采用的SUBSCRIBE(好友存在信息)消息格式；圖14為獲取存在信息的流程中所采用的NOTIFY(用戶存在信息)消息格式；圖15為本發(fā)明的存在消息的發(fā)布和更新方法的流程圖16為本發(fā)明的存在消息的發(fā)布和更新方法中所采用的PUBLISH(modify)消息格式；圖17為本發(fā)明的存在消息的發(fā)布和更新方法中所采用的PUBLISH(modify)消息體格式；具體實施方式
下面結(jié)合附圖和具體實施方式
對本發(fā)明作進一步詳細描述在本實施例中，假設(shè)用戶A(其用戶ID為860106255533，SIP URI為sip860106255533@domain1，此后用“a”代替用戶ID“860106255533”)欲添加用戶B為好友(其用戶ID為8601082681111，SIP URI為sip8601082681111@domain1，此后用“b”代替用戶ID“8601082681111”)，且用戶A和用戶B分屬于不同的域，兩者有不同的存在服務(wù)器。下面參考圖1，對用戶A和B添加好友的流程進行說明。
步驟1-1、用戶A的終端向A所屬域的存在服務(wù)器發(fā)送SUBSCRIBE消息，請求添加用戶B為好友；圖2是SUBSCRIBE消息的消息格式，SUBSCRIBE消息的Expires頭域值為非0，Event頭域值為“presence/initial”。
步驟1-2、用戶A所屬域的存在服務(wù)器將該SUBSCRIBE消息轉(zhuǎn)發(fā)到被添加好友(用戶B)所屬域的存在服務(wù)器；步驟1-3、用戶B所屬域的存在服務(wù)器將SUBSCRIBE消息轉(zhuǎn)發(fā)到用戶B的終端；步驟1-4、用戶B的終端向其所屬域的存在服務(wù)器回復(fù)200OK消息；步驟1-5、用戶B所屬域的存在服務(wù)器向用戶A所屬域的存在服務(wù)器回復(fù)200OK消息；步驟1-6、用戶A所屬域的存在服務(wù)器向用戶A的終端回復(fù)200OK消息；步驟1-7、用戶B所屬域的存在服務(wù)器向用戶B轉(zhuǎn)發(fā)SUBSCRIBE消息后，在收到用戶B返回的拒絕或接收訂閱的NOTIFY消息前，通過用戶A所屬域的存在服務(wù)器向用戶A終端發(fā)送未決的NOTIFY消息，表示訂閱正被處理中。
未決的NOTIFY消息的消息格式如圖3所示，其中，NOTIFY消息的Event頭域值為“presence/initial”，Subscription-State頭域值為“pending”，消息體為空。
步驟1-8、未決NOTIFY消息的接收者向發(fā)送者回復(fù)200OK消息；步驟1-9、用戶B的終端原路返回接受或拒絕訂閱的NOTIFY消息，若用戶B接受訂閱，則執(zhí)行下一步，若用戶B拒絕訂閱，則在發(fā)送拒絕訂閱的NOTIFY消息后終止操作；用戶B接受訂閱與拒絕訂閱所發(fā)送的NOTIFY消息具有不同的消息格式，當(dāng)用戶B接受訂閱時，如圖4所示，NOTIFY消息的Event頭域值為“presence/initial”，Subscription-State頭域值為“active”。當(dāng)用戶拒絕訂閱時，如圖6所示，NOTIFY消息的Event頭域值為“presence/initial”，Subscription-State頭域值為“terminated”，消息體為空。
步驟1-10、NOTIFY消息的接收者向發(fā)送者回復(fù)200OK消息；步驟1-11、用戶B若接受被訂閱，其終端將詢問用戶是否將訂閱者用戶A添加為好友，若要添加，則用戶B的終端開始向用戶A發(fā)起一個添加好友流程；步驟1-12、用戶B若接受被訂閱，其所屬域的存在服務(wù)器接收到接受的NOTIFY消息后，將在用戶B的通知表(訂閱用戶B的好友列表)中添加用戶A；用戶A所屬域的存在服務(wù)器接收到接受的NOTIFY消息后，將在用戶A的訂閱表(用戶A訂閱的好友列表)中添加用戶B。
用戶A添加用戶B為好友后，在每次登錄時，獲取用戶B的存在信息，如圖7所示，其具體實現(xiàn)流程如下步驟2-1、A向A所屬域的存在服務(wù)器發(fā)送請求本用戶基本信息的SUBSCRIBE消息；圖8為請求本用戶基本信息的SUBSCRIBE消息的消息格式，在該消息中，Event頭域值為“personalinfo”。
步驟2-2、A所屬域的存在服務(wù)器返回200OK消息；步驟2-3、A所屬域的存在服務(wù)器向用戶A發(fā)送通知用戶基本信息的NOTIFY消息；圖9是該NOTIFY消息的消息格式，在該消息中，Event頭域值為“personalinfo”，Content-Type頭域值為“application/xpidf+xml”，圖5是NOTIFY消息的消息體格式，在消息體中包含用戶昵稱、頭像等基本信息。
步驟2-4、A向所屬域的存在服務(wù)器回復(fù)200OK消息；步驟2-5、A向所屬域的存在服務(wù)器發(fā)送請求用戶好友列表的SUBSCRIBE消息，該消息的消息格式如圖10所示，其Event頭域值為“buddylist”。
步驟2-6、A所屬域的存在服務(wù)器回復(fù)200OK消息；步驟2-7、A所屬域的存在服務(wù)器向A發(fā)送通知用戶好友列表的NOTIFY消息，圖11表示了NOTIFY消息的消息格式，其中，Event頭域值為“buddylist”，Subscription-State字段為active。圖12表示了NOTIFY消息的消息體，在消息體中包含了用戶的好友列表。由本步驟的操作，用戶A得到了好友列表的相關(guān)信息。
步驟2-8、A向所屬域存在服務(wù)器回復(fù)200OK消息；步驟2-9、A向好友列表中的用戶B所屬域的存在服務(wù)器發(fā)送SUBSCRIBE消息，訂閱用戶B的存在信息，SUBSCRIBE消息的消息格式如圖13所示，其中，Event頭域值為“presence/refresh”；步驟2-10、B所屬域的存在服務(wù)器回復(fù)200OK消息；步驟2-11、B所屬域的存在服務(wù)器往A發(fā)送NOTIFY消息，在該消息中攜帶B的存在信息。圖14是攜帶存在信息的NOTIFY消息的消息格式，其中，Event頭域值為“presence/refresh”，Subscription-State頭域值為“active”。圖5是NOTIFY消息的消息體格式，步驟2-12、用戶A往B所屬存在服務(wù)器回復(fù)200OK消息。
用戶在通訊過程中，用戶的存在消息可能會發(fā)生改變，因此，本發(fā)明還提供了一種用戶存在信息的發(fā)布和更新方法，下面假設(shè)用戶A的存在信息發(fā)生了變化，對其存在信息進行發(fā)布和更新的實現(xiàn)流程如下步驟3-1、用戶A的存在消息發(fā)生變化，A向其所屬存在服務(wù)器發(fā)送PUBLISH(modify)消息，圖16是PUBLISH(modify)消息的消息格式，其中，SIP-If-Match頭域值為前一個PUBLISH消息的應(yīng)答中的Entity-Tag的值，Expires頭域值為180，圖17是PUBLISH(modify)消息的消息體格式，消息體包含用戶更新后的存在信息。
步驟3-2、A所屬域的存在服務(wù)器收到PUBLISH消息后，更新數(shù)據(jù)庫中所保存的該用戶存在信息，并向用戶A的終端返回200OK消息；步驟3-3、A所屬域的存在服務(wù)器向用戶訂閱者列表中的所有好友發(fā)送NOTIFY消息，通知用戶A更新后的存在信息，在所發(fā)送的NOTIFY消息中，如圖14所示，Event的頭域值為“presence/refresh”，Subscription-State頭域值為“active”，Content-Type頭域值為“application/xpidft+xml”，NOTIFY消息的消息體如圖5所示，它包含了用戶更新后的存在信息。
步驟3-4、NOTIFY消息的接收者向其直接發(fā)送者回復(fù)200OK消息。
最后所應(yīng)說明的是，以上實施例僅用以說明本發(fā)明的技術(shù)方案而非限制。盡管參照實施例對本發(fā)明進行了詳細說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解，對本發(fā)明的技術(shù)方案進行修改或者等同替換，都不脫離本發(fā)明技術(shù)方案的精神和范圍，其均應(yīng)涵蓋在本發(fā)明的權(quán)利要求范圍當(dāng)中。
權(quán)利要求
1.一種存在信息的訂閱方法，包括以下步驟步驟11)、第一用戶訂閱第二用戶的存在信息，第一用戶向第二用戶發(fā)送添加好友請求；步驟12)、第二用戶決定是否接受第一用戶所發(fā)出的添加好友請求，若接受，則向第一用戶返回接受請求的消息，并執(zhí)行下一步，若不接受，則向第一用戶發(fā)送不接受請求的消息后，終止操作，若第二用戶暫時無法決定是否接受，則發(fā)送表示未決的消息；步驟13)、第二用戶所屬的存在服務(wù)器接收到接受請求的消息后，在第二用戶的表示已訂閱第二用戶存在信息的好友列表中添加第一用戶；步驟14)、第一用戶所屬的存在服務(wù)器接收到接受請求的消息后，添加第二用戶為第一用戶的好友并記錄在存在數(shù)據(jù)庫中；步驟15)、第一用戶上線后從該用戶所屬的存在服務(wù)器得到本用戶的基本信息，并獲取好友列表，向好友名單中的好友發(fā)出存在信息訂閱請求；步驟16)、表示好友的用戶所屬的存在服務(wù)器接收到存在信息訂閱請求后，響應(yīng)該請求并發(fā)送本用戶的存在信息到第一用戶。
2.根據(jù)權(quán)利要求1所述的存在信息的訂閱方法，其特征在于，若第二用戶接受被訂閱，第二用戶所在終端詢問用戶是否需要訂閱第一用戶的存在信息，若需要，則重新發(fā)起一個添加好友的流程。
3.根據(jù)權(quán)利要求1所述的存在信息的訂閱方法，其特征在于，在所述的步驟11)中，所述的添加好友請求為SIMPLE SUBSCRIBE消息，該消息的Event頭域值為presence/initial，Expires頭域值為非0，在該消息中還包含了所要添加好友的統(tǒng)一資源標識信息。
4.根據(jù)權(quán)利要求1所述的存在信息的訂閱方法，其特征在于，在所述的步驟12)中，所述接受請求的消息為NOTIFY消息，該消息的Event頭域值為“presence/initial”，Subscription-State頭域值為“active”；所述不接受請求的消息為NOTIFY消息，該消息的Event頭域值為“presence/initial”，Subscription-State頭域值為“terminated”，消息體為空；所述表示未決的消息為NOTIFY消息，該消息的Event頭域值為“presence/initial”，Subscription-State頭域值為“pending”，消息體為空。
5.根據(jù)權(quán)利要求1所述的存在信息的發(fā)布方法，其特征在于，在所述的步驟15)中，所述的第一用戶通過SUBSCRIBE消息請求本用戶的基本信息，該消息的Event頭域值為“personalinfo”。
6.根據(jù)權(quán)利要求1所述的存在信息的發(fā)布方法，其特征在于，在所述的步驟15)中，所述的第一用戶通過NOTIFY消息得到本用戶的基本信息，該消息的Event頭域值為“personalinfo”，Content-Type頭域值為“application/xpidf+xml”，該消息的消息體中包含用戶昵稱、頭像等基本信息。
7.根據(jù)權(quán)利要求1所述的存在信息的發(fā)布方法，其特征在于，在所述的步驟15)中，所述的第一用戶通過SUBSCRIBE消息向所屬的存在服務(wù)器請求好友列表，該消息的Event頭域值為“buddylist”。
8.根據(jù)權(quán)利要求1所述的存在信息的發(fā)布方法，其特征在于，在所述的步驟15)中，所述的第一用戶通過NOTIFY消息從存在服務(wù)器得到好友列表，該消息的Event頭域值為“buddylist”，Subscription-State字段為active，該消息的消息體中包含了用戶的好友列表。
9.根據(jù)權(quán)利要求1所述的存在信息的發(fā)布方法，其特征在于，在所述的步驟15)中，所述的第一用戶通過SUBSCRIBE消息發(fā)出存在信息訂閱請求，該消息的Event頭域值為“presence/refresh”。
10.根據(jù)權(quán)利要求1所述的存在信息的發(fā)布方法，其特征在于，在所述的步驟16)中，通過類型為presence/refresh/active的NOTIFY消息將用戶的存在信息發(fā)送到第一用戶。
11.一種存在消息的發(fā)布和更新方法，包括以下步驟步驟21)、一個用戶改變存在信息的設(shè)置，向本用戶所屬的存在服務(wù)器發(fā)送存在信息更新消息；步驟22)、改變存在信息的用戶所屬的存在服務(wù)器收到所述的發(fā)布消息后，更新存在數(shù)據(jù)庫中的該用戶的存在信息，并向該用戶發(fā)送響應(yīng)消息；步驟23)、改變存在信息的用戶所屬的存在服務(wù)器向所有好友發(fā)送用戶的存在信息更新消息，將用戶新的存在消息通知好友。
12.根據(jù)權(quán)利要求11所述的存在消息的發(fā)布和更新方法，其特征在于，在所述的步驟21)中，所述的存在信息更新消息為PUBLISH(modify)類型的消息，該消息的SIP-If-Match頭域值為前一個PUBLISH消息應(yīng)答中的Entity-Tag的值，Expires頭域值為180，該消息的消息體包含用戶更新后的存在信息。
13.根據(jù)權(quán)利要求11所述的存在消息的發(fā)布和更新方法，其特征在于，在所述的步驟23)中，通過NOTIFY消息發(fā)送用戶的存在信息更新消息，在所述NOTIFY消息中，Event的頭域值為“presence/refresh”，Subscription-State頭域值為“active”，Content-Type頭域值為“application/xpidft+xml”，該消息的消息體中包含了用戶更新后的存在信息。
全文摘要
本發(fā)明公開了一種存在信息的訂閱、發(fā)布和更新方法，應(yīng)用于采用SIMPLE協(xié)議的即時通信系統(tǒng)中，該方法包括用戶長期訂閱另一用戶存在信息；用戶上線后從存在服務(wù)器獲取自身及好友的存在信息；用戶更改自身存在信息后，往存在服務(wù)器發(fā)布新的存在信息流程和存在服務(wù)器向其好友更新其存在信息?；诒景l(fā)明，可實現(xiàn)互聯(lián)網(wǎng)絡(luò)中即時通信系統(tǒng)用戶間的個人信息、通信方式、通信優(yōu)先級別等存在信息的共享，具備良好的實用性和擴展性。
文檔編號G06F17/30GK101051922SQ200710065239
公開日2007年10月10日 申請日期2007年4月6日 優(yōu)先權(quán)日2007年4月6日
發(fā)明者周安福, 宋翊麟, 舒童, 徐剛, 劉敏, 王明會 申請人:中國科學(xué)院計算技術(shù)研究所