一種調用隱私的方法

2023-05-12 10:29:26

專利名稱：一種調用隱私的方法
技術領域：
本發明涉及通信系統，更具體而言，涉及支持隱私調用的機制。本發明還涉及在諸如US FTC(美國聯邦貿易委員會)所擬定的指導原則之內使用用戶數據。
背景技術：
全球資訊網WWW的交互模型是以圖1所示的簡單客戶-伺服器交互為基礎的。客戶-伺服器關係可以使用功能實體(例如，受管理的對象或者網絡層)之間的關係來加以定義，其中，一個實體使用另一個實體所提供的業務。該業務的用戶可以稱為「客戶」，該業務的提供者可稱為「伺服器」。術語交互可以描述為發生在一種業務影響其它業務的操作時的情形。
WWW交互的基礎是客戶根據統一資源標識符(URI)例如統一資源定位器(URL)從該伺服器請求資源。這種標識符使網際網路中的文件或者目錄和使用它們所需要的協議各不相同。根據這種交互模型，伺服器能夠向客戶提供某種服務。
在這一交互過程中，伺服器將常常要求來自客戶的數據。這種數據可以包括客戶的PKI(公鑰基礎設施)數字證書、或者可能是關於該客戶代表其作出請求的用戶的某些細節(例如，用戶名、密碼、用戶地址)。
由於在無線世界中有各種約束，所以該交互模型不同於上述的模型。在無線模型中，附加伺服器被引入來在該網絡上分布負載。這一交互模型如圖2所示。取代直接經由鏈路A作出客戶的請求，始發伺服器能夠經由鏈路B到支持伺服器來請求關於客戶的信息。
這些支持伺服器具有許多用途。一些例子是-收集關於用戶的位置數據(位置伺服器)；-代表用戶存儲和分發身份證書(證書伺服器)；-描述用戶終端的屬性(用戶代理簡檔伺服器)；以及-充當數據資源庫。
由於各種原因(包括法律規定的)而認為個人數據應該在嚴格的指導原則之內加以分發。近些年來，人們愈加關注用戶在網際網路上的隱私。這已經導致產生來自各組織，像OECD(經濟協作和發展組織Organization for Economic Co-operation and development)和EU(歐盟European Union)的各種指導原則和指示。這些來自各種來源、儘管相當類似的指導原則由US FTC(美國聯邦貿易委員會United StatesFederal Trade Commission)的、在電子市場中的交易信息慣例(FairInformation Practices(FIP))很好地概括。FIP建議用戶的隱私應該遵循如下的4項指導原則(http//www.ftc.gov/privacy/index.html)·通知-用戶應該得到什麼個人數據被使用、誰正在使用它、以及如何使用它的通知；·選擇-用戶應該具有對是否允許那樣使用的選擇權；·訪問-用戶應該具有對那個數據的訪問權，無論那個數據在何處被使用；以及·安全-用戶數據應該總是被使用合理的安全預防措施來進行保護。
全球資訊網協會(W3C)已經定義了一種機制，使終端確定個人信息可被傳送到各應用的條件。這種機制稱為P3P(隱私優先選擇平臺)。它實際上是用於如下操作的架構·在應用伺服器上定義隱私策略(即，從形式上規定什麼信息被收集且如何使用它)；·定義客戶可以怎樣定義他們自己的隱私優先選擇；以及·可以怎樣比較隱私策略。
P3P沒有規定具體的實現(除了依靠XML(可擴展標記語言)來定義策略之外)，但是幾個原型系統提供如下的功能·每次訪問其策略與用戶優先選擇不同的WWW站點時警告該用戶；以及·請求該用戶授權將個人信息傳送到WWW站點。
對用戶數據的訪問控制，存在兩種現有技術水平的方法。很通常的訪問控制方法是使用黑/白列表來控制對資源的訪問。黑列表是那些不被允許訪問該資源的實體的列表。如果黑列表存在，則除了在黑列表之上的那些實體外，所有的實體都被允許去訪問該列表。白列表是那些被允許訪問該資源的實體的列表。如果白列表存在，則除了在白列表上的那些實體外，任何實體都不被允許去訪問該列表。
儘管這是一種提供隱私級保護的相當簡單的方法，但是存在一些缺點，因此該方法不可應用來支持在指導原則內的隱私調用。它是一種靜態方法，且它沒有辦法來動態地處理數據請求。假定該用戶希望訪問該始發伺服器。他們必須通過的步驟如下1)首先，他們將必須確定該始發伺服器可能要求什麼數據；2)接著，他們將必須定位到合適的支持伺服器(或者可能涉及到的幾個伺服器)；3)然後，他們可進行到該始發伺服器以便得到服務。
此外，僅僅存在黑列表或者白列表的可能性。不存在具有「灰」列表的能力，在該灰列表中該用戶可被詢問以便查看他們是否希望允許該始發伺服器具有所述數據。
訪問控制的另一種可能是一種方法，其中該始發伺服器組裝它所要求的一組數據，並將它呈現為一個列表以便讓該客戶來進行數字籤名。然後，當請求個人用戶數據時，該始發伺服器將此數字籤名的列表呈現給該支持伺服器。不過，這種方法將會涉及額外的往返行程以及在客戶端的加密處理。確切地講正是這些問題要求使用支持伺服器。換句話說，這種方案將否定支持伺服器的優點。
這種方案依賴於PKI，後者進而又要求數字證書。因為數字證書本身能夠包含個人用戶數據，所以使用數字證書這個簡單的事實本身可能會損害用戶隱私。
部分地由於這樣的「隱私」是一種新領域的事實，所以一直沒有在涉及支持伺服器的標準上作努力來解決該隱私問題。從上述使用的例子中可以清楚地看出，在支持伺服器上所包含的數據是個人用戶數據，以及所述數據應該根據合適的隱私指導原則來加以使用。
與上面提及的當前情形相關聯的問題之一是，隱私還沒有在無線網際網路標準中被解決。因此，對於支持伺服器保護用戶的隱私願望，即沒有定義也沒有實現的方法。目前，使用支持伺服器的情形是，當支持伺服器接收對信息的請求時，並沒有代表用戶的幹預。這就意味著，對於用戶而言，沒有任何方法來接收通知或者作出關於她/他自己的個人數據的選擇。

發明內容
因此，本發明的一個目的是提供一種新的機制來在通信系統中支持隱私調用。本發明的目的通過具有在獨立權利要求中所記載的特徵的方法和方案實現。本發明的優選實施例在從屬權利要求中公開。
本發明所依據的思想是使用從支持伺服器到客戶的窄帶推送信道，以便通知客戶關於對所述支持伺服器擁有的個人數據的請求。用戶然後對此請求作出應答，說明她/他是否希望允許這一請求。
本發明的方法和方案的優點在於它們允許用戶具有對是否讓他們的個人數據被使用的選擇權。
本發明的方法和方案的另一個優點在於它不要求該始發伺服器和支持伺服器之間的以前的關係。


在下面參考附圖，通過優選實施例，將更加詳細地描述本發明。在所述附圖中圖1展示現有技術的WWW交互模型；圖2展示現有技術的無線網際網路交互模型；以及圖3示出在根據本發明的支持伺服器中的隱私保護。
具體實施例方式
能夠應用本發明的通信系統的通用系統圖可以包括配備有短消息服務的常規移動站的用戶設備。儘管在下面本發明將通過短消息、短消息服務、WAP(無線應用協議)消息以及WAP消息服務加以描述，但是一個消息可以包括例如至少如下消息之一短消息、即時消息、電子郵件消息、多媒體消息、統一傳遞的消息、WAP消息或者SIP(會話啟動協議)消息。移動站還可以是配有例如即時消息、電子郵件消息、多媒體消息、統一傳遞的消息或者SIP(會話啟動協議)消息服務的移動站。
本發明的基本原理可被用來使能在任何移動通信系統諸如GSM、GPRS、TETRA和UMTS之間和/或之內的隱私調用。
本發明可以影響無線應用的端到端系統的某些單元。在隱私調用系統中，客戶單元(以下在這一申請中稱為客戶)可以被描述為具有接收和處理推送消息的能力的任何單元。一個客戶單元可以是配有這種能力的典型的移動WAP終端。
支持資源庫伺服器單元(以下在這一申請中稱為支持伺服器)可以被描述為具有能力以便在受到將個人信息遞交到其它伺服器的請求的觸發之後把推送消息發送到客戶的任何單元。一個這樣的支持伺服器可以是配有這種能力的典型伺服器。
換句話說，為了實現本發明及其實施例，終端將需要能夠接受推送消息，以及所述支持伺服器將需要能力以便能夠充當一個推送啟動者。此外，在所述終端和支持伺服器中可能需要一些程序性邏輯。
這種窄帶推送信道可以被定義為這樣的信道，即通過該信道，伺服器可以例如在沒有從客戶接收到在前請求的情況下發送數據或信令。這種信道的例子是SMS(短消息系統)信道。當前，SMS可被視為在無線世界中的一個獨有特徵，不過它的普及卻正導致它在更廣闊的網際網路中的複製。還有其它類型的、構建在數據的異步傳輸(即非請求/應答式)之上的信道，它們可被視為推送信道。
本發明提出使用從支持伺服器到客戶的窄帶推送信道以便通知客戶關於對所述支持伺服器擁有的個人數據的請求。用戶然後可對此請求作出應答，說明她/他是否希望允許這一請求。因此，本發明提出拓展這種推送信道來保護用戶的隱私並且提供對合適的隱私指令的更好履行。
在圖3，在支持伺服器和客戶之間畫有一條額外的鏈路。該鏈路(鏈路C)被稱為推送信道鏈路。當使用該推送信道鏈路時，數據序列可能按照如下流動1)客戶1通過第一信道(A)向始發伺服器2請求該資源；2)始發伺服器2向支持伺服器3作出請求，請求一些個人用戶數據；3)支持伺服器3通過窄帶信道(C)發送推送消息，指示始發伺服器2已經作出對所述數據的請求；(這一步驟涉及到FTC關於通知和個人數據的指導原則。)4)客戶1對所述推送作出應答，允許或禁止對數據的所述請求。(這一步驟涉及到FTC關於選擇和個人數據的指導原則。)所述應答可以是簡單的是/否。或者，客戶1和支持伺服器3可以就給出什麼數據以及為什麼目的而進行協商；以及5)根據客戶1的應答，支持伺服器3或者將所述數據遞交到始發伺服器2或者拒絕將所述數據遞交到始發伺服器2。
始發伺服器所需要的數據要求在客戶上客戶所不具有的處理能力。在這一情況下，支持伺服器供應所要求的處理能力。
有許多種方式來實現上面提及的機制。兩種候選方案可以包括將本發明的實現作為SMS實現或者作為WAP推送實現。
在SMS實現中，支持伺服器將需要支持一個到SMSC(短消息服務中心)的接口。當對個人數據的請求從始發伺服器到達時，支持伺服器會將SMS發送到客戶，向她/他通知該始發伺服器的請求。客戶然後能夠作出應答，指示她/他的優先選擇以便使支持伺服器來接受或拒絕該始發伺服器的請求。SMS消息的確切內容可以是例如上面所描述的小的實現細節；1)支持伺服器→客戶″在www.mybank.com處的我的銀行請求你的位置。你希望將位置給它們嗎？是/否″。
2)客戶→支持伺服器″是″在WAP系統中，定義了推送架構[推]。所述架構定義了3個部件推送客戶、推送啟動者P1和推送代理網關PPG。在這一實現中，該無線客戶也是能夠接收WAP推送消息的推送客戶。在這一情況下，支持伺服器充當推送啟動者，建立推送消息以便遞交給客戶。在這兩個實體之間，存在稱為PPG的實體。PPG的作用是處理尋址以及將推送消息從P1遞交到推送客戶。
此外，在這一實現中，要傳遞的消息的確切格式可被確定，但是可以使用通用的過程來使支持伺服器P1編輯詳細描述該始發伺服器對個人數據的請求的推送消息。客戶然後對所述消息作出應答，指示他們相對於該始發伺服器請求的隱私優先選擇。
如上所述，本發明的核心思想是使用推送窄帶信道來警告用戶對他們的個人數據的使用和/或試圖使用他們的個人數據。來自用戶的應答可以僅僅是簡單的是/否應答，指示用戶接受始發伺服器對個人數據的請求。這種應答還可以是某個其它類型的應答，假如它能夠在支持伺服器中被讀取的話。
然而，還有可能的是推送消息能夠啟動拉取會話(pull session)，允許用戶協商他們可能希望要顯露的那個信息。在拉取會話中，客戶可以請求數據，數據可以在拉取信道上被返回。例如，如果始發伺服器請求用戶名和信用卡細節，則用戶可以作出應答，指示她/他僅僅希望顯露她/他的名字。
如上所述，本發明可以應用在WAP系統之中。一個原因在於這樣的事實，即支持伺服器在一般位於無線網際網路的標準化的前端的WAP體系結構之中定義得很好。然而，本發明的範圍超出了WAP系統和體系結構的範圍，並且支持伺服器的原理擴展到WAP體系結構之外。例如，位置伺服器將會在3G(第3代)環境中見到，而不管該環境是否是WAP環境。證書URI的使用也正在被擴展到傳統的web模型。用戶代理簡檔的傳輸是以W3C關於CC/PP(組合能力/優先選擇簡檔)的工作為基礎的。實際上，支持伺服器的部署在希望有效利用帶寬的任何網絡中都是有意義的。
在WAP中的一些支持伺服器描述如下證書伺服器[WPKI，無線公鑰基礎設施]。
作為在網際網路安全協議SSL/TLS(安全套接字層/傳輸層安全)中安全握手的一部分，該客戶和伺服器可以交換PKI數字身份證書以便彼此互相鑑權。這些證書的交換在無線網絡中會要求相當大量的帶寬。針對這一原因，SSL/TLS的無線等價物WTLS(無線傳輸層安全)允許發送證書URI來代替發送證書。這樣就允許始發伺服器從網絡的另一位置(即證書的支持伺服器)來檢索該客戶的身份證書。
UAProf伺服器[UAProf].
無線客戶的特徵之一在於他們的特徵和形式因素有相當大的不同。而對於WWW則不是這種情況，在那種情況下客戶是相對同構的。WAP已經定義了稱為UAProf(用戶代理簡檔)的規範，它允許客戶將其特徵傳送到始發伺服器。由於考慮到帶寬，客戶還可以傳送這樣的URI，它指向包括該客戶特徵的細節的支持伺服器。
位置伺服器[位置].
移動網際網路的一個獨特的方面在於物理位置是相關的數據值。確定客戶的物理位置的一種方法依賴於伺服器在支持網絡中所採用的措施。為了提供共同的抽象，定義了位置伺服器，它是能夠提供關於該客戶位置信息的伺服器。位置伺服器的一個獨特的特徵在於它甚至基本上不需要客戶的交互就可使用。始發伺服器可以簡單地向位置伺服器請求用戶的位置。這種類型的交互對於用戶隱私問題特別敏感。
儘管每個支持伺服器提供不同的功能性，但是在它們之間存在一些共性。在每一種情況下-始發伺服器從客戶要求一些數據(例如，他們是誰，他們在那裡，他們正使用的是什麼終端)；-客戶發送標識符，允許始發伺服器向支持伺服器查詢所述數據；-支持伺服器提供在傳統的web模型中可能會由客戶來提供的數據；以及-所請求和所提供的數據具有對該客戶的用戶的一些特定引用(例如，在證書中的用戶身份，用戶的客戶特徵，用戶的物理位置)。
本發明假設存在一種方式來將MSISDN(綜合業務數字網)或者終端的固定IP(網際協議)地址與由應用轉發到資源庫的用戶標識相關聯起來(不管是名字和地址，小甜餅(cookie)等等)。這種情況的一種可能性是與無線網關定位在一起的或者包含用戶資料庫(白頁)的資源庫。
如果用戶可以在不同的瀏覽器視窗中具有幾個活動的進行中的瀏覽會話，則推送消息有可能必須提供指示哪個站點正在請求私有數據的公開。在不需由最終用戶事先啟動而請求私有信息的背景應用的情形中，情況基本上是相似的。用戶應該得到關於正在(自治地)試圖收集關於她或他的信息的應用的通知。
每當應用伺服器(即始發伺服器)從資源庫(即從支持伺服器)中請求個人信息時，所述資源庫可以將推送消息發送到最終用戶，即發送到客戶，請求確認以便將個人信息遞交到該應用。
在現有技術水平的支持伺服器中，如前面已經描述過的，這一信息沒有來自客戶的幹預而被發布。這意味著過去沒有任何方式來使用戶接收通知或者作出關於他們自己的個人數據的選擇。儘管在一些情況中，支持伺服器的實現可能已經允許一種簡單的黑/白列表形式，它確保了數據僅僅被給與選定方，但是這一方法過去且現在是相當靜態的以及受限於預先規定的選定的始發伺服器組。
本發明的一個優點在於它相對於較早前的技術方案的改進在於它是動態的且具有靈活性。並不要求用戶在訪問始發伺服器之前來通過支持伺服器設置優先選擇。而是這一過程能夠在用戶與始發伺服器的會話期間發生。然而，應該指出，作為一種優化，該支持伺服器可以將以前用戶選擇的列表保留作為動態的黑/白列表。
本發明允許灰列表。代替僅僅是簡單的黑和白列表，現在有可能具有灰列表，灰列表中的條目被從該用戶詢問。這可以被視為一種對簡單的黑/白列表解決方案的改進。
此外，用戶也在控制之中。在其它方法中，用戶必須向每個和所有可能包含其個人數據的支持伺服器通知關於他們的隱私優先選擇。使用這種方法，該支持伺服器就在他們需要知道用戶的優先選擇是什麼時去向用戶詢問它們是什麼。
按照本發明的這種機制節省了帶寬。試圖允許代表用戶進行交互的其它方案(諸如數字籤名的請求)則消耗額外的往返行程和帶寬。在此所提供的機制使用最小的額外行程和帶寬。這是非常明顯的優點，因為在客戶和始發伺服器之間的網絡鏈路(圖3所述的鏈路A)的帶寬可以非常低，或者鏈路的延遲時間可以很差。在本發明的輔助之下，在始發伺服器和支持伺服器之間的網絡鏈路(示為鏈路B)可以高很多。
本發明不要求始發伺服器和支持伺服器之間，或者始發伺服器和用戶、客戶之間以前的關係。它還利用了獨特的無線特徵，諸如推送技術。本發明允許使用任何推送信道來直接與用戶進行通信，而不只是使用通信網絡的信令信道。
本發明以及優選實施例並不假定存在隱私優先選擇協商架構(諸如P3P)，儘管它可以用在那樣的環境中。本發明並不要求為了執行該協商而將完整的程序下載到該終端。
本發明在以下方面與P3P不同·它不假定該應用伺服器將它的隱私策略的描述發送到該終端；·它不假定該終端存儲隱私優先選擇；以及·它不假定由個人數據資源庫代表客戶來執行通知。
它以如下方式而不同於現有技術水平的原型和研究·它依賴於無線基礎設施來請求和傳送來自該最終用戶的公開授權。而所公布的提議只考慮有線網際網路/WWW基礎設施；以及·它不假定將信息呈現為必須由最終用戶(或者自動表單填寫程序)來填寫的表單，而是僅僅假定被各應用從包含用戶信息的資源庫進行請求。
它更加接近地反映隱私標準。儘管是一個新的領域，但是W3C確實具有稱為P3P的隱私標準[P3P]。P3P規範組的一部分是用戶隱私優先選擇語言APPEL[APPEL]。APPEL列出在確定是否應該接受P3P策略時的4種可能的結果。這些結果是″接受″，″拒絕″，″通知″，″警告″。當翻譯到支持伺服器時，這種方法允許支持伺服器來實現″通知″和″警告″結果。對於例如黑/白列表這是不可能的。
本發明依賴無線應用基礎設施的能力，尤其是推送，來請求和檢索來自最終用戶的公開授權。這構成了在非交互式應用情況下的主要優勢用戶可能還沒有啟動該應用(例如自動的WWW爬蟲(crawler)正嘗試編輯來自分散在網際網路上的資源庫中的信息)且甚至可能都不在線，但是她/他卻仍然在他的行動電話上經由推送消息而得到對個人數據的公開請求的通知。
用於無線應用的業務平臺有可能良好地調諧對該公開請求的處理，例如通過在確定出最終用戶不可達的情況下自動地拒絕所述請求。
本發明的另一優點在於並非特定地僅涉及到對位置信息的請求，而是本發明還覆蓋了幾乎所有的個人數據，例如用戶名、密碼、信用卡細節、地址、生日，即基本上在網際網路表單上可能要填寫的任何一項。
使用窄帶推送信道來處理4項隱私指導原則中的2項，即通知和選擇。通過接收該推送消息，用戶得到對使用他們的私有數據的通知。他們還能夠對所述請求作出應答，說明他們是否希望允許所述請求。這樣就允許用戶具有對是否採用那樣的方式來使用他們的個人數據的選擇權。
對本領域技術人員而言，顯而易見的是，隨著技術的推進，本發明的概念能夠採用各種方式來加以實現。本發明及其實施例並不限制於上述的例子，而是在權利要求的範圍內可以改變。
權利要求
1.一種在通信系統中調用涉及到能夠接受推送消息的用戶設備(1)的隱私的方法，所述推送消息是這樣一個消息，即不需所述用戶設備(1)的用戶對該消息進行請求，伺服器便可將其發送到用戶設備(1)，且所述伺服器具有能夠充當推送消息始發者的能力，其特徵在於如下步驟(i)通過第一信道(A)從用戶設備(1)將對個人用戶數據的第一請求發送到始發伺服器(2)；(ii)始發伺服器(2)將對個人用戶數據的請求發送到支持伺服器(3)；(iii)支持伺服器(3)通過窄帶信道(C)將推送消息發送到用戶設備(1)，指示由該始發伺服器(2)對該用戶數據作出的所述請求；(iv)用戶設備(1)經由所述窄帶信道至少通過對該數據的請求的允許消息或者禁止消息而對所述推送消息作出應答；以及(v)支持伺服器(3)至少部分地對所述允許消息作出應答而將所述數據提供到始發伺服器(2)，否則就拒絕所述數據的提供。
2.根據權利要求1的方法，其特徵在於，在步驟(v)之前，如果用戶設備(1)已經將允許消息發送到該支持伺服器，則該用戶設備(1)和支持伺服器(3)就關於將什麼數據提供到始發伺服器進行協商。
3.根據權利要求1或2的方法，其特徵在於，用戶設備(1)是通信網絡中的WAP設備，且所述推送消息和允許消息或者禁止消息在用戶設備(1)和支持伺服器(3)之間通過該通信網絡的網關(PPG)和服務節點被路由。
4.根據權利要求1或2的方法，其特徵在於，用戶設備(1)是在通信網絡中配有短消息裝置的設備，所述推送消息和所述允許消息或禁止消息在用戶設備(1)和支持伺服器(3)之間通過該通信網絡的中心(SMSC)和服務節點而被路由。
5.根據權利要求1-4的方法，其特徵在於，支持伺服器(3)向該通信網絡的其它支持伺服器和/或始發伺服器通知用戶已經同意顯露涉及到她/他的信息，從而使該始發伺服器不必將推送消息發送到該用戶設備。
6.根據權利要求1-5中任一項的方法，其特徵在於，在用戶設備(1)和支持伺服器(3)之間的推送消息和允許或者禁止消息的交換被授權和/或被保護，優選地通過諸如IP sec、數字籤名或者相當好的保密(PGP)的方法。
7.根據權利要求6的方法，其特徵在於，所述授權和/或保護是通過如下的方法之一來進行的IP sec，數字籤名或者相當好的保密(PGP)。
8.一種在通信網絡中的支持伺服器，其特徵在於，它適合於進行如下的操作(i)從始發伺服器(2)接收請求個人用戶數據的請求；(ii)經由窄帶信道(C)將推送消息發送到用戶設備(1)，指示始發伺服器(2)對所述數據的請求；(iii)經由所述窄帶信道(C)從用戶設備(1)接收對所述推送消息的應答，所述應答至少包括對於所述數據請求的允許消息或禁止消息；以及(iv)至少部分地對所述允許消息作出應答，將所述數據提供到始發伺服器(2)，而否則就拒絕所述數據的提供。
9.一種用戶設備，其特徵在於，它適合於進行如下操作(i)經由第一信道(A)將對個人用戶數據的請求發送到始發伺服器(2)；(ii)經由窄帶信道(C)接收來自支持伺服器(3)的推送消息，所述消息指示始發伺服器(2)對數據作出的請求；以及(iii)經由所述窄帶信道、至少通過對該數據請求的允許消息或者禁止消息而對所述推送消息作出應答。
10.一種通信系統，其特徵在於，它包括至少一個根據權利要求9的用戶設備和/或至少一個根據權利要求8的支持伺服器。
全文摘要
本發明涉及一種在通信網絡中調用關於用戶設備(1)的隱私的方法，所述用戶設備(1)能夠接受推送消息，所述推送消息是這樣一種消息，即在用戶設備(1)的用戶沒有請求它的情況下，伺服器可以將該消息發送到該用戶設備(1)，以及所述伺服器具有能夠充當推送消息始發者的能力。所述方法包括如下步驟(i)通過第一信道(A)將對個人用戶數據的第一請求從用戶設備(1)發送到始發伺服器(2)；(ii)該始發伺服器(2)將對個人用戶數據的請求發送到支持伺服器(3)；(iii)該支持伺服器(3)通過窄帶信道(C)將推送消息發送到用戶設備(1)，指示由該始發伺服器(2)作出的所述對該用戶數據的請求；(iv)用戶設備(1)經由所述窄帶信道、至少通過對該數據的請求的允許消息或者禁止消息而對所述推送消息作出應答；以及(v)該支持伺服器(3)至少部分地對所述允許消息作出應答以將該數據提供到該始發伺服器(2)，而否則就拒絕該數據的提供。
文檔編號H04Q7/20GK1484926SQ01821773
公開日2004年3月24日 申請日期2001年4月9日 優先權日2001年1月4日
發明者J·卡爾, A·穆霍寧, M·穆利甘, J 卡爾, 裟 申請人:諾基亞有限公司