通信事件的通知相關申請本申請在35USC119或365下要求2012年6月14日提交的英國申請No.1210598.7的優(yōu)先權，該文獻的公開內容全部合并于此。

背景技術：
存在各種不同的用于通過諸如因特網之類的基于分組的網絡建立現場的基于分組的話音或視頻呼叫的通信系統。例如，這樣的系統可以使用VoIP（話音互聯網協議）技術。一種普及類型的通信系統建立在對等（P2P）拓撲結構上。在傳統的P2P系統中，每個最終用戶在他或她各自的用戶終端（例如臺式或膝上型計算機、平板計算機或者手持式移動電話）上安裝通信客戶端應用程序。每個用戶然后向P2P提供商的服務器注冊以便獲得認證證書。一些用戶終端也將變成分布式數據庫的節(jié)點，其將P2P通信系統內的用戶的用戶名映射到該系統通過其實現的網絡內的各個不同的用戶終端的地址（典型地為IP地址）。于是，最終用戶之間的通信可以在呼叫設立或者認證過程中不涉及集中式服務器的情況下進行。相反地，呼叫者的終端上的客戶端查詢分布式數據庫的一個或多個節(jié)點（即呼叫中以任何其他方式涉及的其他最終用戶（不一定是他們自己）的一個或多個終端）以便確定預期的被呼叫者的終端的地址。呼叫者然后使用所確定的地址向被呼叫者發(fā)送呼叫邀請，并且被呼叫者以呼叫接受響應進行響應。呼叫者和被呼叫者交換他們的認證證書以便對彼此進行認證。每個用戶也維持聯系人列表，該聯系人列表可以存儲在P2P提供商的服務器上，使得它即使在用戶登錄到不同的終端上的情況下也可用。其他諸如每個用戶的簡檔信息（例如化身（avatar）圖像或者情緒消息）之類的輔助信息也可以存儲在服務器上。此外，客戶端應用程序也彼此交換存在性信息。該存在性信息指示用戶的可用性狀態(tài)，并且至少部分地由用戶他自己或她自己定義。例如，存在性可以指示用戶是否離線、在線但是選擇成不可用（“請勿打擾”）或者在線并且選擇成可用。例如，每個客戶端可以周期性地輪詢其聯系人列表中的每個聯系人以便確定他們各自的存在性，和/或每個客戶端可以周期性地向其列表中的每個聯系人發(fā)送出存在性更新。存在性典型地基于P2P技術在最終用戶之間直接地而不是經由服務器用信號發(fā)送。當進行呼叫時，呼叫者的客戶端基于最新的存在性信息確定被呼叫者是否可用來接受呼叫。

技術實現要素：
本發(fā)明的實施例提供了一種裝置，該裝置包括處理裝置和收發(fā)器裝置。處理裝置被配置成生成與來自始發(fā)端點的預期用于目的地端點的通信有關的推送通知，該通信要通過基于分組的網絡進行。收發(fā)器裝置被設置成將推送通知發(fā)送至目的地端點。此外，處理裝置被配置成利用有效載荷生成推送通知，該有效載荷包括要由目的地端點用來輸出就所述通信通知目的地用戶的用戶通知的語言的指示。依照本發(fā)明的另外的實施例，提供了一種相應的方法和計算機程序產品。本

技術實現要素：
被提供來以簡化的形式引入構思的選擇，這些構思在下面的具體實施方式中進一步加以描述。本

技術實現要素：
并不預期識別要求保護的主題的關鍵特征或基本特征，也不預期限制要求保護的主題。要求保護的主題也不限于解決現有系統的所提到的缺點中的任何一個或全部的實現方式。附圖說明圖1為通信系統的一個示意圖，圖2為通信系統的另一個示意圖，圖3為通信系統的另一個示意圖，圖4為兩個用戶終端的示意圖，以及圖5為網絡元件和兩個用戶終端的示意圖。具體實施方式隨著能夠運行諸如VoIP客戶端之類的通信客戶端應用程序的手持式移動電話的日益流行，存在越來越多數量的端點可用于參與通過因特網等等實現的VoIP通信系統或者其他這樣的基于分組的通信系統。然而，也可能出現的一個問題是，移動電話手持送受話器典型地具有比傳統臺式或膝上型計算機更有限的資源，例如每單位時間能夠執(zhí)行更少的處理周期，每處理周期具有更少的功能，具有更有限的存儲器資源（例如RAM和/或緩存）和/或具有更少的屏幕區(qū)域資源。因此，一些終端上的操作系統（OS）可以將特定應用程序置于背景狀態(tài)下。這可以包括通信客戶端。在背景狀態(tài)下，背景化應用程序可以完全暫停，或者以不能夠檢測到來的呼叫邀請和/或處理傳統的呼叫邀請的程度每單位時間被調度有限的處理周期。例如，這可能在另一個應用程序正在前景狀態(tài)下運行的情況下，尤其是在其他應用程序在處理、存儲器和/或屏幕資源方面密集，例如運行于全屏模式或者像主導應用程序那樣當前具有某種其他狀態(tài)的情況下發(fā)生。一個實例將是在移動電話上玩的計算機游戲。在這樣的情況下，如果客戶端不能夠發(fā)送出存在性更新或者對來自其他用戶的存在性輪詢進行響應，那么用戶根據他或她的存在性可能看起來是離線的。然而，用戶可能仍然希望可用于接受呼叫，例如將寧愿中斷視頻游戲而不是錯過呼叫。因此，傳統的存在性概念開始被打破。類似的問題可能潛在地發(fā)生在具有能夠將特定應用程序置于背景狀態(tài)下以利于一個或多個其他應用程序的特征的任何終端上。因此，可能希望的是遠離用于呼叫設立的P2P方法，或者至少遠離純粹的P2P方法。諸如在基于分組的網絡上實現的常規(guī)P2P系統之類的通信系統可能出現的另一個問題上呼叫信令的速度，尤其是在呼叫被應答之前要花費多長時間，或者要花費多長時間確定呼叫未被應答。這尤其是（但非排他性地）在被呼叫者的客戶端如上面所討論的處于背景狀態(tài)下時可能是個問題，其中呼叫者可能必須在他或她被通知被呼叫者不可用之前等待企圖的呼叫邀請超時。呼叫信令延遲也可能發(fā)生在其他情形中以及其他類型的通信系統中。因此，可能希望的是提供一種改進的或者可替換的向目的地用戶終端通知呼叫或者其他通信事件的方式。一些其他類型的通信系統使用推送通知來通知通信事件的目的地用戶終端。推送通知是在服務器或者另一個始發(fā)元件的指使下而不是在目的地終端本身的指使下（即與由目的地終端拉拽相反）從服務器發(fā)送的通知。因此，推送通知可以被認為與目的地終端異步。例如，常規(guī)上，這樣的推送通知可以用來指示來源于始發(fā)用戶終端的IM（即時消息傳遞）聊天消息或者文件傳輸在服務器處的可用性。然而，“原始”推送通知僅僅通知目的地終端在服務器處存在等待它的某種通信。目的地終端于是仍然必須輪詢服務器以便確定等待通信的性質，即確定它被通知的事件的性質，并且響應于接收到推送通知而從服務器拉拽涉及事件的性質的有關信息。這意味著一旦目的地終端接收到通知，那么它仍然必須向后參閱服務器以獲得允許目的地用戶就他或她是否希望獲得所述通信做出明智決定的信息（如果這樣的話，在此之前再次回去取回等待通信，例如取回等待IM聊天消息或者文件傳輸）。如果例如這樣的推送通知系統直接適于向用戶通知呼叫邀請，使得原始通知用來從背景狀態(tài)喚醒目的地客戶端應用程序，那么在喚醒時目的地客戶端于是將不得不輪詢服務器以便發(fā)現它為什么被喚醒（即確定提議了呼叫）并且發(fā)現使得它能夠對呼叫邀請進行響應的始發(fā)終端或者呼叫者的身份。這可能把不希望的延遲引入到呼叫信令中。此外，獲取的信息的性質可能仍然用途有限，并且不一定適合所述通信的特定預期接受者或者所述通信的特定發(fā)送者或者發(fā)送者和接受者的組合。依照本發(fā)明的實施例，提供了一種擴增推送通知機制，其中推送通知包括有效載荷，該有效載荷攜帶使得目的地用戶能夠就是否接受呼叫或通信做出明智決定的信息。特別地，有效載荷信息至少包括用來向目的地用戶通知有關通信事件（例如到來的呼叫）的語言的指示。該語言可以是始發(fā)用戶（在呼叫的情況下為呼叫者）、目的地用戶（在呼叫的情況下為被呼叫者）的語言，或者由始發(fā)用戶和目的地用戶二者共用的語言。在實施例中，推送通知的有效載荷信息包括語言模板，其包括要使用的語言的指示以及用于制定到目的地用戶的屏幕上或者可聽通知的語言句法的指示。有效載荷可選地可以包括其他的信息，例如所述通信的類型的指示（例如呼叫、IM、話音郵件、文件傳輸）；始發(fā)用戶的指示（例如用戶名和/或顯示名）；代表始發(fā)用戶的化身圖像（或者到化身圖像的鏈接）；始發(fā)終端的地址；始發(fā)終端的類型的指示；始發(fā)用戶的加密密鑰；時間戳；提議的通信會話的會話標識符（例如提議的呼叫的呼叫ID）；用于通信的交談標識符；和或用于通信的任何中繼器的指示。在實施例中，由于在推送通知本身中提供了附加用戶信息，因而在通知的時間，接收用戶能夠更好地確定他或她是否希望接受關聯的通信或通信會話（例如提議的呼叫），而不一定必須首先從通信提供商的網絡元件中取回附加信息以便確定到來的通信的性質和/或發(fā)送者的身份。這有利地減少了雙程的數量并且因而降低了信令延遲。如所提到的，諸如手持式移動電話之類的現代移動設備現在能夠運行通信客戶端應用程序以便通過諸如因特網之類的基于分組的網絡而不是僅僅經由移動電話的專用蜂窩話音通道執(zhí)行諸如VoIP或者其他基于分組的話音或視頻呼叫之類的基于分組的通信。利用該能力，迎來在線且可呼叫或者可聯系的用戶數量的急劇增加。然而，這樣的用戶的客戶端應用程序也可能潛在地被發(fā)現在呼叫時處于背景狀態(tài)下，其中客戶端被暫停，或者至多被移動設備的操作系統調度非常有限的資源——從而需要被喚醒以便接收到來的呼叫。在這樣的操作系統制度下——其中應用程序不再可以保證能夠在背景中處理諸如到來的呼叫、聊天等等之類的事件——VoIP或者其他通信提供商的架構將受益于擴展。例如，這在以下情況下將是有益的：提供商希望能夠將呼叫（和其他）通知輸送至它們的通信系統的用戶，即使這些用戶“背景化”了有關的通信客戶端應用程序（或者讓該應用程序由操作系統背景化），但是雖然如此其仍然在線并且因此潛在地可呼叫或者可聯系。也可以修改客戶端應用程序的呼叫部件以確保呼叫用戶的初始意圖可以可靠地輸送至其中用戶應當能夠——經由推送通知（如果需要的話）接收呼叫（或者其他通信）的所有端點。例如，考慮其中被呼叫者在等待他或她的朋友呼叫（也許來自國外，因此出于成本的原因偏好使用VoIP）的同時正在手持式電話或者平板計算機上使用web瀏覽器或者玩視頻游戲的使用情況。被呼叫者基于存在性狀態(tài)檢查朋友是否在線，但是當他或她不在線時，被呼叫者開始瀏覽或者玩以填補時間。接著，朋友（呼叫者）隨后登錄到例如臺式計算機上的他或她的客戶端應用程序，準備好呼叫被呼叫者。在實施例中，可以修改被呼叫者的客戶端以便將被呼叫者向呼叫者顯示為在線，即使被呼叫者的客戶端應用程序由于瀏覽器或游戲需要消耗的高系統資源的原因，例如由于在瀏覽器中運行的flash應用程序或者其他小應用程序的原因而由被呼叫者的操作系統暫?；蛘咭种?。在本發(fā)明的實施例中，呼叫者點擊呼叫按鈕以發(fā)起與被呼叫者的呼叫，并且被呼叫者的操作系統被配置成彈出向他或她通知到來的呼叫的提示。被呼叫者的客戶端應用程序被配置成使得如果被呼叫者響應于提示碰觸或者點擊接受按鈕，那么客戶端應用程序在被呼叫者的終端上被帶回到前景中，從而允許被呼叫者對呼叫（話音或視頻）進行應答并且開始與他的朋友或者呼叫者交談。在該示例性方案中存在一些要指出的元素。被呼叫者客戶端的狀態(tài)在最壞的情況下潛在地是完全暫停的（終止），并且因此不會由常規(guī)的P2P會話建立方法達成。在本發(fā)明的實施例中，被呼叫者可能不知道或者注意到他或她的客戶端應用程序被暫停，因為這可以不由被呼叫者用戶顯式地完成——事實上恰恰相反，這可能由操作系統自動地完成，并且被呼叫者可能假定他或她的客戶端應用程序仍然在運行，并且他們在線且可達到。此外，在此方案中，與用于這樣的系統的常規(guī)存在性機制不同的是，沒有使得存在性依賴于（或者不僅僅依賴于）客戶端的P2P可用性。為了支持上面的方案，提供商將實現新的呼叫部件和/或對現有的部件做出必要的改變。一個目標是讓被呼叫者客戶端喚醒并且能夠在適當的時間表和范圍內與呼叫者客戶端建立會話（例如P2P會話）。為了保持呼叫設立時間盡可能短，只要有可能，就應當將會話和呼叫建立中的雙程保持為最少。如上面的實例方案中所示范的，呼叫發(fā)起流可以支持需要經由非P2P消息輸送系統用信號發(fā)送呼叫的意圖的使用情況，這可以在需要的情況下回退到推送通知以便喚醒被呼叫者客戶端。例如，這可以借助于由所討論的操作系統的提供商提供的推送通知服務?？梢愿潞艚胁考员憷缭诤诵膸熘袑崿F必要的客戶端部件變化，以確保它們迎合所有需要的使用情況、互操作性和后向兼容性方案?？梢愿潞艚锌蛻舳瞬考员阍试S被呼叫者客戶端接受借助于推送通知輸送方法接收的到來的呼叫邀請。這可以包括允許客戶端UI（用戶接口）層將接收的有效載荷信息傳遞至呼叫部件、使得P2P會話建立和呼叫設立及信令能夠進行的一個或多個UIAPI（應用編程接口）的集合。為了將呼叫有關信息包括在經由消息輸送系統輸送至被呼叫者端點的消息的有效載荷中，呼叫功能可以支持基于云的服務，這些服務接收來自輸送基礎設施的消息并且填入該呼叫特定有效載荷信息。呼叫通知將包括足夠的信息以便允許被呼叫者就是否應答呼叫做出明智的決定。這可以包括例如呼叫者姓名（用戶名和/或顯示名）、呼叫者的化身和/或呼叫邀請的時間戳。呼叫通知也可以包括諸如握手消息之類的允許被呼叫者客戶端制定接受響應的信息，以及允許作為響應聯系呼叫者的信息（例如呼叫者用戶名和/或地址）。一旦輸送系統的呼叫通知器完成了以上所述，那么傳遞呼叫通知以便最終輸送至被呼叫者端點。這將在被邀請參加呼叫的用戶為接收推送通知進行了注冊的情況下或者在存在到客戶端的開放式連接的情況下發(fā)生。通知可以通過直接的持久連接（被呼叫者客戶端處于前景中和/或一些背景狀態(tài)），或者在需要的情況下經由推送通知到達基于有關操作系統的通知服務（被呼叫者客戶端被暫停和/或一些其他背景狀態(tài)）。參與呼叫的邀請在若干情況下可以由呼叫方發(fā)出，這些情況例如：在實際呼叫建立之前，作為發(fā)起的部分；或者在進行中的呼叫期間，將另一個參與者添加到呼叫。圖1為基于傳統P2P范式的通信系統的示意圖。該通信系統包括基于分組的網絡100，例如諸如因特網之類的廣域互聯網絡（互聯網）。該通信系統也包括多個最終用戶終端102，每個最終用戶終端包括可操作來耦合到因特網100的收發(fā)器裝置，并且每個最終用戶終端包括所討論的通信系統的對應通信客戶端應用程序。最終用戶終端102中的每一個可以例如采取臺式或膝上型計算機、平板計算機或者手持式移動電話（或者“手持送受話器”）的形式。用戶終端102中的每一個是通信系統內的VoIP呼叫或者其他基于分組的通信的潛在端點。圖1中圖示出的是呼叫者端點102a和被呼叫者端點102b。依照常規(guī)P2P原理，用戶終端102c中的一個或多個上的客戶端應用程序呈現分布式地址查找數據庫的節(jié)點的狀態(tài)。為了確定被呼叫者的用戶終端102b的地址（例如包括IP地址），在步驟S10處呼叫者的用戶終端102a上的客戶端經由因特網100與充當分布式數據庫的節(jié)點的用戶終端102c之一上的客戶端通信。呼叫者的終端102a上的客戶端通過向數據庫節(jié)點102c發(fā)送識別通信系統內的被呼叫者的被呼叫者的用戶名而查詢該數據庫節(jié)點102c，并且數據庫節(jié)點102c返回被呼叫者的用戶終端102b的所需地址。在步驟S12處，呼叫用戶終端102a上的客戶端然后使用該地址向預期的被呼叫者的終端102b上的客戶端用信號發(fā)送呼叫設立請求或者“邀請”（CI）。作為響應，如果被呼叫者選擇接受呼叫，那么被呼叫者終端102b上的客戶端向后用信號發(fā)送呼叫接受響應。呼叫者和被呼叫者的終端102a和102b上的客戶端也交換認證證書以便驗證彼此的身份。這些客戶端因此建立彼此之間的會話以便作為現場話音或視頻呼叫的一部分發(fā)送來自其各自終端102、102b上的麥克風和/或視頻照相機的實時話音和/或視頻內容形式的通信量。由于地址查找基于分布式數據庫，因而不必涉及用于這個目的的中央服務器。呼叫設立信令、認證和呼叫通信量也在無需涉及中央服務器的情況下進行。在實施例中，如果呼叫者的用戶終端102a由于NAT（網絡地址轉換）或者防火墻108的原因而不能直接與被呼叫者的用戶終端102b通信，那么這些客戶端可以被設置成經由也可以由在P2P通信系統的一個或多個其他用戶的最終用戶終端102d上運行的客戶端實現的一個或多個中繼器通信。中繼最終用戶終端102d的用戶不必是呼叫的參與者（不必消耗呼叫的話音或視頻內容，并且由于加密的原因而的確不能）。盡管如此，中繼最終用戶終端102d的用戶在他或她簽約到P2P通信系統時同意這樣的情形，并且他自己或者她自己在其他場合下可以受益于互惠的安排。通信系統可以進一步包括耦合到因特網100的后端服務器104，其中所述客戶端中的每一個可以存儲各自的聯系人列表，該列表是其各自用戶的聯系人的列表（通信系統被配置成使得用戶變成相互協議的聯系人）。后端服務器104也可以存儲用于每個用戶的簡檔信息，例如用于向通信系統內的其他用戶代表對應用戶的化身圖像。每個客戶端可以訪問和顯示聯系人的簡檔，使得呼叫者可以看見被呼叫者的簡檔信息，并且反之亦然。通信系統也可以包括耦合在因特網100與電路交換網絡（未示出）之間的網關106。這樣的網絡可以被稱為PSTN（公共交換電話網絡），例如陸線網絡，或者諸如3GPP網絡之類的移動蜂窩網絡。用戶終端102上的客戶端由此也能夠經由網關106與更傳統的電話建立呼叫。圖2圖示出依照本發(fā)明實施例的修改的混合P2P通信系統。圖1的一些或者全部部件也可以仍然與圖2的系統并行地存在，但是為了簡明起見一些部件從圖2中省略。此外，通信系統包括通信服務提供商（例如VoIP提供商）的、耦合到因特網100并且被設置成運行呼叫控制和通知軟件的一個或多個服務器單元的形式的網絡元件204。通信系統也包括耦合到因特網100的一個或多個基于操作系統的推送通知服務（OSPNS）202。所述一個或多個基于操作系統的推送通知服務202中的每一個與對應的操作系統關聯，并且由操作系統的制造商和/或發(fā)布商提供以便支持經由所討論的操作系統可用的專用推送通知機制?；诓僮飨到y的推送通知服務202采取被設置成運行推送通知軟件的一個或多個服務器單元的形式。在圖2的示例性系統中，圖示的元件102、202、204被配置成如下操作。在步驟S20處，呼叫者的用戶終端102a上的客戶端將呼叫邀請（CI）不直接發(fā)送到被呼叫者的用戶終端102b上的客戶端，而是發(fā)送到VoIP提供商的呼叫控制和通知元件204（消息CI不一定與關于圖1所描述的消息相同）。在步驟S22處，響應于接收到來自呼叫者的呼叫邀請，VoIP提供商的呼叫控制和通知元件204生成它發(fā)送至基于操作系統的推送通知服務202的推送通知請求（PNR）。在步驟S24處，響應于接收到來自VoIP提供商204的推送通知請求，操作系統的推送通知服務202將基于操作系統的推送通知（PN_OS）發(fā)送至被呼叫者的用戶終端102b上的操作系統?；诓僮飨到y的推送通知由被呼叫者的用戶終端102b上的操作系統接收和處理，使得它在被呼叫者的用戶終端102b的屏幕上顯示向被呼叫者用戶指示存在到來的事件的彈出消息。在本發(fā)明的實施例中，屏幕上消息可以提示被呼叫者是否接受到來的呼叫。如果被呼叫者的客戶端應用程序當前是背景化的，那么屏幕上消息可以提示用戶是否從背景狀態(tài)喚醒被呼叫者的客戶端應用程序。在實施例中，可以將這些動作組合到相同的提示中。如果作為響應，被呼叫者以肯定方式提供用戶輸入，那么操作系統通過重新調度至完全操作水平或者至少給被呼叫者的終端102上的被呼叫者客戶端應用程序調度處理呼叫的足夠資源而喚醒該被呼叫者客戶端應用程序。如下文中更詳細地討論的，在實施例中，推送通知PN_OS可以包括使得被呼叫者的用戶終端102b上的客戶端能夠直接通過因特網100而不是經由提供商或者服務元件202和204中的任何一個的服務器制定返回握手消息和信號的有效載荷，所述返回握手消息和信號通過因特網100向后通告呼叫者的用戶終端102a上的客戶端。如果被呼叫者接受來自操作系統的用戶提示，那么被呼叫者的用戶終端102b上的操作系統將推送通知的有效載荷的至少一部分向上傳遞至被呼叫者的客戶端應用程序以便它可以制定有關響應并且向后將該響應發(fā)送至呼叫者。圖3圖示出依照本發(fā)明實施例的另一個修改的混合P2P通信系統。圖1和/或圖2的一些或者全部部件也可能仍然與圖3的系統并行地存在，但是為了簡潔起見一些部件從圖3中省略了。在圖3的示例性系統中，圖示的元件102、204被配置成如下操作。在步驟S20處，呼叫者的用戶終端102a上的客戶端同樣地將呼叫邀請（CI）不直接發(fā)送到被呼叫者的用戶終端102b上的客戶端，而是發(fā)送到VoIP提供商的呼叫控制和通知元件204（消息CI不一定與關于圖1所描述的消息相同）。在實施例中，這可以是與關于圖2所描述的步驟相同的步驟，或者在其他實施例中，它可以是可替換的或者附加的單獨步驟。然而，在這種情況下，VoIP提供商元件204不發(fā)送（或者不僅僅發(fā)送）推送通知請求（PNR）至操作系統的推送通知服務202。相反地，它直接制定它自己的應用層推送通知（PN_AL），它直接通過因特網100將該應用層推送通知發(fā)送至被呼叫者的用戶終端102b上的客戶端。被呼叫者的用戶終端102b上的客戶端然后可以在應用層處理該通知以便自己借助于應用層機制，而不是上面描述的操作系統機制就到來的呼叫提示被呼叫者用戶。如下文中更詳細地討論的，在實施例中，推送通知PN_AL包括使得被呼叫者的用戶終端102b上的客戶端能夠直接通過因特網100而不是經由提供商或者服務元件202和204中的任何一個的服務器制定返回握手消息和信號的有效載荷，所述返回握手消息和信號通過因特網100向后通告呼叫者的用戶終端102a上的客戶端。在這種情況下，如果被呼叫者的終端102b上的客戶端處于前景狀態(tài)下（未受抑制以利于任何其他應用程序）或者處于其中它被調度有限的周期但是仍然足以處理到來的呼叫的特殊背景狀態(tài)下，那么被呼叫者的客戶端能夠通過在操作系統調度被呼叫者的客戶端的時間期間偵聽來自網絡100的到來的通信，例如在被呼叫者的終端102b的被分配用于供被呼叫者的客戶端使用的網絡套接字上偵聽而直接訪問推送通知的有效載荷。應當指出的是，圖1、圖2和圖3的機制中的兩個或更多可以并行地存在，并且這些機制中的任何一個或者全部可用于用信號發(fā)送呼叫邀請或通知。在本發(fā)明的一個實施例中，至少被呼叫者端點102b包括移動終端，該移動終端具有相對有限的資源（處理、存儲器和/或屏幕資源），并且具有易于背景化對應的客戶端應用程序以利于諸如某些情況下的視頻游戲之類的另一個應用程序的操作系統。在其中客戶端應用程序完全被暫停的情況下，這意味著它被終止，直到喚醒，并且可能需要冷啟動以便接收呼叫或者其他通信。圖4給出了形成呼叫的兩個端點（或者甚至在多方會議呼叫方案中的更大數量的端點中的兩個）的呼叫用戶（呼叫者）的始發(fā)最終用戶終端102a以及被呼叫用戶（被呼叫者）的目的地最終用戶終端102b的示意性框圖。始發(fā)用戶終端102a包括對應的操作系統400a、VoIP通信系統的通信客戶端402a（以及潛在地還有其他應用程序）和用戶接口408a。VoIP客戶端402a存儲在始發(fā)終端102a的（諸如電子或磁性存儲設備之類的計算機可讀存儲器或者介質形式的）存儲器上，并且被設置用于在始發(fā)終端102a的處理裝置上執(zhí)行。術語“計算機可讀存儲器”意在覆蓋存儲介質的所有法定形式，并且因此并非意在覆蓋諸如信號和載波之類的非法定介質形式。客戶端應用程序402a也被稱為在操作系統400a上運行，因為它被調度用于由操作系統400a執(zhí)行。如果存在多個存在且運行于終端102a上的應用程序，那么操作系統將調度它們以便例如以交錯的方式和/或在并行處理資源上執(zhí)行，使得每個應用程序在操作系統400a的控制下被分配至少一些處理資源。當被調度時，客戶端應用程序402a能夠經由用戶接口408a與用戶交互并且經由用戶終端102a的收發(fā)器裝置通過網絡100通信。如將關于目的地終端102b更詳細地討論的，操作系統也可以暫停諸如客戶端應用程序之類的應用程序的執(zhí)行。目的地用戶終端102b也包括對應的操作系統400b、VoIP通信系統的通信客戶端402b、諸如電子郵件客戶端404和視頻游戲406之類的其他應用程序以及用戶接口408b。通信客戶端402b存儲在目的地終端102b的（諸如電子或磁性存儲設備之類的計算機可讀存儲器或者介質形式的）存儲器上，并且被設置用于在目的地終端102b的處理裝置上執(zhí)行。VoIP客戶端應用程序402b和其他應用程序404、406被稱為在操作系統400b上運行，因為它們被調度用于由操作系統例如以交錯的方式和/或在并行處理資源上執(zhí)行，使得每個應用程序在操作系統400b的控制下被分配至少一些處理資源。當被調度時，VoIP客戶端402b能夠經由用戶接口408b與用戶交互并且經由目的地用戶終端102b的收發(fā)器裝置通過網絡100通信。當所述其他應用程序404和406被調度時，情況同樣如此。如所提到的，操作系統400b也可以具有暫停諸如VoIP客戶端402b之類的應用程序或者將其置于其中它每單位時間僅僅被分配非常有限數量的處理資源的某種其他背景狀態(tài)下的能力。在實施例中，操作系統400b的調度包括將每個應用程序402b、404、406置于前景狀態(tài)或者背景狀態(tài)下的能力。前景狀態(tài)可以包括其中前景應用程序為在當前時間運行的主要的、主導的應用程序的狀態(tài)。這點的一個特定實例是應用程序在全屏模式下運行，在該模式下，它以其他應用程序為代價被分配整個屏幕資源。例如，視頻游戲406在運行時可以被給予全屏或者其他主導前景狀態(tài)，因為用戶可能需要全屏來玩游戲和/或游戲可能消耗顯著的處理資源，從而可能使得有限的處理資源或者沒有處理資源可用于諸如VoIP應用程序402b和電子郵件客戶端404之類的其他應用程序。這種方案尤其可能發(fā)生在諸如手持式移動電話之類的移動終端上，在該移動終端處，資源與比如臺式計算機相比相對有限。前景狀態(tài)的另一個實例可以包括這樣的狀態(tài)，其中沒...