專利名稱：減少網絡內呈現狀態(tài)事件數目的方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及用于減少網絡內呈現狀態(tài)事件數目的方法和裝置。通過將個人頻繁通信的聯系人(親密好友/最近最常使用聯系人)與個人不頻繁通信的聯系人(非親密好友 /最近較少使用聯系人)進行隔離以更好地管理網絡中呈現狀態(tài)信息流來實現此目的。
背景技術：
盡管本發(fā)明專門涉及網絡上呈現狀態(tài)信息管理領域，并且因此參考此領域進行描述，但是應該理解，本發(fā)明在其他領域和應用中也很有用。在背景方面，存在被稱為觀察者(watcher)的基于標準的機制，用于便利通知用戶有關被稱為呈現實體(presentities)的其他用戶的呈現狀態(tài)信息。所述呈現狀態(tài)信息， 如公知的那樣，可以采取各種形式，但是一般指示用戶狀態(tài)。此類信息將允許其他用戶確定該用戶的在線、忙碌等狀態(tài)。一般而言，當在移動網絡中使用觀察者時，該已知的基于標準的機制使用過多的無線網絡資源量并且縮短了移動設備上的電池壽命。當然，過多使用網絡資源不是移動提供商所希望的，而且移動用戶也不希望電池壽命縮短。進一步地，在非移動使用中，當每個用戶觀察多個呈現實體時，產生和發(fā)送呈現狀態(tài)更改通知會導致對資源(例如，服務器容量)的過分需求，這不是呈現狀態(tài)網絡運營商所希望的。在一種情況下，當其他用戶(一種形式是，用戶位于移動用戶通訊簿中)的狀態(tài)發(fā)生更改時，將呈現狀態(tài)信息自動“推入(push)”移動用戶。即使僅跟蹤數百個呈現實體，此方法也會給網絡帶來巨大的負擔，因為每次將信息推入用戶都需要網絡資源。此外，存在多個其他現有機制來解決網絡中呈現狀態(tài)信息的難題。例如，可以使用 “拉動(pull)”呈現狀態(tài)信息(而非推入)。但是此方法削弱了用戶體驗。許多用戶無法接受呈現狀態(tài)信息請求(例如，拉動)和傳送之間的時差?？梢詼p少狀態(tài)數，但是此方法會導致呈現狀態(tài)服務的功能性降低。可以抑制呈現狀態(tài)通知。此方法的缺點包括延遲發(fā)送以及丟失短時間事件的信肩、ο還可以實現觸發(fā)器過濾器。但是此方法需要用戶高度參與才能設置過濾器。缺少其他方法，網絡提供商只能減少接收呈現狀態(tài)功能的用戶數。這樣會導致使用服務的用戶減少，可能減少收入。

發(fā)明內容
提供了用于減少網絡內呈現狀態(tài)事件數目的方法和裝置。在目前描述的實施例的一個方面，所述方法包括檢測第二用戶(例如，一個呈現實體)的呈現狀態(tài)的更改(通過，例如，諸如第一用戶之類的觀察者)，以及確定所述第二用戶(例如，一個呈現實體)位于第一列表還是第二列表上，如果所述第二用戶(例如，一個呈現實體)位于所述第一列表上，則立即通知所述第一用戶(例如，觀察者)呈現狀態(tài)的更
3改，以及如果所述第二用戶位于所述第二列表上，則在檢測到預定事件時通知所述第一移動用戶呈現狀態(tài)的更改。在目前描述的實施例的另一方面，所述第一列表為親密好友列表 /最近最常使用聯系人。在目前描述的實施例的另一方面，所述第二列表包含非親密好友列表/最近較少使用聯系人的標識符。在目前描述的實施例的另一方面，所述預定事件為打開地址簿或聯系人列表。在目前描述的實施例的另一方面，所述方法進一步包括修改所述第一和第二列表。在目前描述的實施例的另一方面，所述第一用戶為觀察者。在目前描述的實施例的另一方面，所述第二用戶為一個呈現實體。在目前描述的實施例的另一方面，所述系統(tǒng)包括與所述第一用戶(例如，觀察者) 對應的第一客戶端、存儲第一列表和第二列表的XDMS服務器以及可操作來檢測第二用戶 (例如，一個呈現實體)的呈現狀態(tài)更改，確定所述第二用戶(例如，一個呈現實體)位于所述第一列表上還是所述第二列表上，如果所述第二用戶(例如，一個呈現實體)位于所述第一列表上，則立即通知所述第一移動客戶端(例如，觀察者)呈現狀態(tài)的更改以及如果所述第二用戶(例如，一個呈現實體)位于所述第二列表上，則在檢測到預定事件時通知所述第一客戶端呈現狀態(tài)的更改的呈現狀態(tài)服務器。在目前描述的實施例的另一方面，所述第一列表為親密好友列表。在目前描述的實施例的另一方面，所述第二列表包含非親密好友列表上的用戶/ 最近較少使用聯系人的標識符。在目前描述的實施例的另一方面，所述預定事件為打開地址簿或聯系人列表。在目前描述的實施例的另一方面，所述呈現狀態(tài)服務器和第一客戶端(例如，觀察者)中的至少一項進一步可通過運行修改所述第一和第二列表。在目前描述的實施例的另一方面，所述第一用戶為觀察者。在目前描述的實施例的另一方面，所述第二用戶為一個呈現實體。通過下面提供的詳細描述，本發(fā)明進一步的應用范圍將變得顯而易見。但是應該理解，所述詳細的描述和特定實例盡管指示本發(fā)明的優(yōu)選實施例，但是僅出于說明的目的給出，因為對于本領域的技術人員來說，處于本發(fā)明的精神和范圍內的各種變化和修改將是顯而易見的。


本發(fā)明包括各種設備組件的結構、安排和組合以及方法步驟，并以此實現所構想的目標，如下文中更詳細地描述的那樣，所述目標在權利要求中具體地指出，并在附圖中示出，在所述附圖中圖1是其中可以實現目前描述的實施例的網絡的方塊圖；圖2是根據目前描述的實施例的方法的流程圖；以及圖3是其中可以實現目前描述的實施例的網絡的方塊圖。
具體實施方式
目前描述的實施例的基本理念是提供有利的PUSH和PULL (推拉)模型的混合體以在最大程度上減少無線網絡資源使用的情況下實現良好的用戶體驗。在此方面，一種形式是針對移動客戶端上顯示的通信模式通過呼叫記錄/最常呼叫或通信列表確定的一小組好友或最常呼叫方使用呈現狀態(tài)推入方法。根據目前描述的實施例的至少一種形式，該組用戶的呈現狀態(tài)始終保持最新。針對地址簿上的其他項使用呈現狀態(tài)拉動方法。根據目前描述的實施例的至少一種形式，該組用戶可能僅在被使用時(例如，在檢測到諸如打開地址簿之類的預定事件時) 更新其呈現狀態(tài)。當通信模式更改時，該小組好友的構成可能發(fā)生更改，以便于這小組與用戶通信的實體不斷地更新。由不經常通信的實體構成的較大組僅在打開通訊簿或出現其他此類可能使用它們的事件時才會進行更新。由于僅將最新呈現狀態(tài)發(fā)送給用戶通訊簿上的一部分實體，因此這種組合減少了所需的網絡資源(例如，大量減少使用需要分頁、打開流量通道等的通知消息)。根據所提出的解決方案的至少一種形式，使用IETF、3GPP和OMA制定的標準SIP/ SIMPLE(會話發(fā)起協(xié)議/針對即時消息和呈現狀態(tài)業(yè)務的利用擴展的會話發(fā)起協(xié)議)呈現狀態(tài)信號。根據至少一種形式，諸如移動客戶端之類的客戶端分析其通信記錄以確定其親密好友列表。它在例如XDMS內設置該列表并在例如呈現狀態(tài)服務器/資源列表服務器(RLS) 中訂閱該列表。通過這種形式，呈現狀態(tài)服務器/RLS在該列表上的任何用戶出現狀態(tài)更改時，通知移動客戶端。進一步地，根據至少一種形式，當打開地址簿時，客戶端(例如，移動客戶端)請求更新非親密好友列表的狀態(tài)(使用expires = 0，PULL請求)。根據至少一種形式，當親密好友列表更改時，由于(例如)用戶通信模式的更改， 將更改兩個列表(例如，親密好友列表和非親密好友列表)以反映此更改?，F在參考附圖，其中的圖示僅為了說明示例性實施例，并非限制所述的主題，圖1 提供其中可以集成目前描述的實施例的系統(tǒng)的視圖。如一般所示，圖1示出網絡部分100。 該網絡部分實現此處聯系目前描述的實施例描述的技術，其中提供了推拉模型的混合體以在最大程度上減少網絡資源使用的情況下使用呈現狀態(tài)檢測技術增強用戶體驗。應該理解，僅示出網絡的一部分以便于說明。本領域的技術人員將理解如何將此部分與其他網絡元素進行集成。在此方面，網絡100包括例如與呈現狀態(tài)服務器/資源列表服務器104通信的客戶端102 (例如，移動客戶端)。客戶端102例如示出為移動客戶端并且可以采取任何形式， 例如移動電話、個人計算機等。進一步地，客戶端102可以是移動電話，也可以不是移動電話-它可以是例如工作站或其他計算設備。此外，客戶端102為觀察者。服務器104也與XML文檔管理服務器(XDMQ 106進行通信。XDMS服務器106上面存儲有各種信息片段，其中包括至少第一和第二列表。除這些之外，還會存儲親密好友列表 18和非親密好友列表110。根據至少一種形式，親密好友列表上的用戶不會出現在非親密好友列表上。這些列表可以包括例如客戶端102的用戶的地址簿并且可以包含與其他用戶相關的標識符或其他數據。在適當的情況下，列表上的這些其他用戶可以被稱為呈現實體。同樣，所述其他用戶可以采取各種形式(例如，移動電話、計算機等)和/或使用各種設備， 并且可以是移動電話，也可以不是移動電話。在操作中，呈現狀態(tài)數據在狀態(tài)更改時被推入一小組好友的客戶端。如親密好友列表108所示，該小組親密好友通過客戶端102上通信的呼叫記錄或最近最常使用號碼進行確定。這組親密好友使用推入機制使其在移動客戶端102上的呈現狀態(tài)不斷保持最新。 應該理解，多數移動用戶一般都希望只有一小組好友的狀態(tài)不斷更新。在此方面，例如，移動電話用戶通常只與數量非常少的人進行通信。因此，僅讓一小組親密好友不斷更新對于多數人便已足夠。在至少一個實現中，使用諸如XDMS數據庫的XCAP之類的標準機制自動更新客戶端102(例如，移動客戶端10 的親密好友列表。通過這種方式，當親密好友列表上的任何項發(fā)生更改，都會通知移動客戶端實例102或呈現狀態(tài)服務器104的用戶。應該理解，此功能可以通過各種方式實現。例如，客戶端(例如，移動客戶端)可以通過備選實現分別請求或訂閱每個親密好友。通過進一步參考圖1進行的說明，針對一小組好友推入信息的的過程可以采取各種形式。根據一個實例形式，客戶端102訂閱其親密好友列表的呈現狀態(tài)信息(參考線1)。 然后，呈現狀態(tài)服務器104從XDMS服務器106請求親密好友列表的成員(參考線幻。接著，XDMS服務器通過好友A、B、C和D的標識對呈現狀態(tài)服務器104做出響應(參考線3)。 呈現狀態(tài)服務器104將好友A、B、C和D的狀態(tài)返回到客戶端102 (參考線4)。此時，如果任何親密好友(或呈現實體)的狀態(tài)發(fā)生更改，呈現狀態(tài)服務器都會檢測到此更改并且呈現狀態(tài)服務器會自動通知客戶端。例如，如果親密好友A(例如，呈現實體)的狀態(tài)發(fā)生更改，便會通知呈現狀態(tài)服務器(參考線幻。同樣，呈現狀態(tài)服務器接著將狀態(tài)更改通知發(fā)送到客戶端102(參考線6)。如上所述，目前描述的實施例提供推拉模型的混合體以提供增強的用戶體驗并限制對網絡資源的使用。因此，針對地址簿上在圖1中被識別為非親密好友110的較多的項使用拉動技術。在此方面，僅在需要時使用拉動機制更新地址簿中不包括在親密好友列表中的項。根據一種形式，使用諸如XDMS數據庫的XCAP(XML配置訪問協(xié)議)之類的標準機制更新非親密好友列表。該列表上每項的呈現狀態(tài)信息使用用于列表的呈現狀態(tài)拉動機制進行更新。當然，可能存在備選實現。例如，在一個備選實現中，定義多個列表，其中首先拉動地址簿中最先示出的項，接著拉動后面示出的項。另外，此實現的優(yōu)點在于提供更佳的用戶體驗。在另一備選實現中，針對地址簿中每項執(zhí)行呈現狀態(tài)拉動請求。就像使用推入技術一樣，拉動技術可以通過各種方式實現。但是，在一個實現中， 參考圖1，好友E (例如，一個呈現實體)(可以是移動電話)的狀態(tài)發(fā)生更改，因此通過狀態(tài)更改更新呈現狀態(tài)服務器104。在這種情況下，由于需要將信息拉動到移動客戶端，因此不會將通知發(fā)送到所述移動客戶端。然后，當用戶打開地址簿時，例如，便將拉動請求發(fā)送到指定非親密好友列表的呈現狀態(tài)服務器(參考線8)。呈現狀態(tài)服務器然后從XDMS服務器106請求非親密好友列表的成員(參考線9)。XDMS服務器106通過包括好友E的移動電話狀態(tài)的所有非親密好友的當前標識做出響應(參考線10)。呈現狀態(tài)服務器然后將這些非親密好友的狀態(tài)返回到客戶端102(參考線11)。因此，如果第二列表上的用戶(呈現實體)狀態(tài)發(fā)生更改，觀察者(例如，第一用戶或客戶端10 不會收到有關呈現狀態(tài)更改的通知，而是僅當發(fā)生預定事件時，所述觀察者才會看到該呈現實體的狀態(tài)的更改。目前描述的實施例的一個功能是不斷更新客戶端功能內的親密好友列表。在此方面，系統(tǒng)可以通過不斷更新親密好友列表提供增強的用戶體驗。現在參考圖2，其中示出方法200。在此方法中，用戶與另一實體進行通信(在 202)。在該實例中，更改通信記錄(在204)。根據通信記錄的更改，計算或再次計算親密好友列表(在206)。然后將親密好友列表的新狀態(tài)與舊狀態(tài)進行比較以確定一個列表與另一列表相比是否發(fā)生更改(在208)。如果發(fā)生更改，便會更新XDMS服務器106上存儲的親密好友列表和非親密好友列表(在210)。系統(tǒng)然后等待下一通信事件(在21 。當然，如果在208確定好友列表未發(fā)生更改，則系統(tǒng)僅等待下一通信事件(在212)?？梢酝ㄟ^各種方式實現步驟210中對親密好友列表和非親密好友列表的更新。根據一個示例性形式，現在參考圖3，其中示出系統(tǒng)100。在該實例中，用戶或移動客戶端102 將文本消息發(fā)送到好友E。在該實例中，E取代D成為最親密的四個好友之一(參考線1)。 客戶端將XCAP Put with E發(fā)送到親密好友XDMS列表(參考線幻。移動客戶端102然后將 XCAP Put with D發(fā)送到非親密好友列表(參考線3)。所述移動客戶端接著將XCAP Delete with D發(fā)送到親密好友列表108(參考線4)。最后，所述移動客戶端將XCAP Delete with E發(fā)送到非親密好友列表110 (參考線5)。一旦執(zhí)行完所有這些操作，親密好友列表108和非親密好友列表110的初始狀態(tài)分別更改為轉換狀態(tài)，如親密好友列表108’和非親密好友列表110’所示。應該理解，此處描述的方法和技術可以使用各種軟件例程、硬件配置和/或這兩者的組合來實現。例如，聯系圖1、2和3描述的技術可以使用客戶端或移動客戶端、呈現狀態(tài)服務器、XDMS服務器上運行的軟件例程或它們的各種組合來實現。進一步地，應該理解， 這些元件可以采取各種形式，例如，它們可以集成在其他元件內，也可以作為獨立的實體。上面的描述僅提供本發(fā)明的特定實施例的披露，并非旨在對本發(fā)明進行限制。因此，本發(fā)明并非僅限于上述實施例。而是應該理解，本領域的技術人員可以構想處于本發(fā)明的范圍之內的備選實施例。
權利要求
1.一種通知第一用戶其他用戶的呈現狀態(tài)更改的方法，所述方法包括 檢測第二用戶的呈現狀態(tài)的更改；確定所述第二用戶位于第一列表還是第二列表上；如果所述第二用戶位于所述第一列表上，則立即通知所述第一用戶呈現狀態(tài)的更改；以及如果所述第二用戶位于所述第二列表上，則在檢測到預定事件時通知所述第一用戶呈現狀態(tài)的更改。
2.如權利要求1中所述的方法，其中所述第一列表為親密好友列表。
3.如權利要求2中所述的方法，其中所述第二列表包含不在所述親密好友列表上的移動用戶的標識符。
4.如權利要求1中所述的方法，其中所述預定事件為打開地址簿或聯系人列表。
5.如權利要求1中所述的方法，進一步包括修改所述第一和第二列表。
6.一種通知第一用戶其他用戶的呈現狀態(tài)更改的系統(tǒng)，所述系統(tǒng)包括 與所述第一用戶對應的第一客戶端；存儲第一列表和第二列表的XDMS服務器；以及呈現狀態(tài)服務器，可操作來檢測第二用戶的呈現狀態(tài)更改，確定所述第二用戶位于所述第一列表上還是所述第二列表上，如果所述第二用戶位于所述第一列表上，則立即通知所述第一客戶端呈現狀態(tài)的更改以及如果所述第二用戶位于所述第二列表上，則在檢測到預定事件時通知所述第一客戶端呈現狀態(tài)的更改。
7.如權利要求6中所述的系統(tǒng)，其中所述第一列表為親密好友列表。
8.如權利要求7中所述的系統(tǒng)，其中所述第二列表包含不在所述親密好友列表上的移動用戶的標識符。
9.如權利要求6中所述的系統(tǒng)，其中所述預定事件為打開地址簿或聯系人列表。
10.如權利要求6中所述的系統(tǒng)，其中所述呈現狀態(tài)服務器和第一客戶端中的至少一個還可操作來修改所述第一和第二列表。
全文摘要
本發(fā)明提供了用于減少網絡內呈現狀態(tài)事件數目的方法和裝置。通過將親密好友(位于好友列表或聯系人列表上)與非親密好友(位于列表上)進行隔離以更好地管理網絡中呈現狀態(tài)信息流來實現此目的。
文檔編號H04L29/08GK102484617SQ201080029512
公開日2012年5月30日 申請日期2010年6月15日 優(yōu)先權日2009年6月30日
發(fā)明者D·W·瓦爾尼 申請人:阿爾卡特朗訊公司