201251398 六、發明說明： 【發明所屬之技術領域】 本發明大體而言係關於行動裝置處理之領域；且更具體 言之’係關於對在行動裝置與應用程式提供者之間傳輸之 通知訊息的管理。 本申請案根據35 U.S.C. § 119(e)主張2011年6月3曰申請 之美國臨時申請案第61/492,893號之申請日期的權利。 【先前技術】 行動裝置（膝上型電腦、掌上型電腦、行動電話、智慧 型電話、多媒體電話、攜帶型媒體播放器、GPS單元、行 動遊戲系統等）之使用者可能已安裝有應用程式，該等應 用程式週期性地自通知服務接收通知訊息。舉例而言，此 等應用程式包括「推播」電子郵件服務（例如，MobileMe、
Microsoft Exchange、ActiveSync、Push-IMAP、Yahoo! Push 等）或其他推播服務（例如，更新/升級服務、新聞服務、 web網妹（bl〇g)服務、播客（p〇dcast)服務、社交網路服務， 或可發送通知訊息的其他類型之服務）。通知訊息通常表 不感興趣事件’該等事件通常由應用程式來定義（例如， 新電子郵件指示符、新的新聞項目指示符、新播客指示 符、社交網路好友之線上狀態的改變等）。 對行動裝置之增加使用擴大了將通知訊息投送至彼等裝 置之複雜性。一個問題係行動裝置並非為固有可定址的； 例如，當前不存在IPv6之行動版本。換言之，行動裝置不 與桌上型電腦或甚至膝上型電腦具有IP位址同樣地具有其 164767.doc 201251398 自己的ip位址。此外，有時在邏輯上而言，行動裝置位於 有可能使用網路位址轉譯（NAT)之服務提供者防火牆的後 面。此等防火牆可應用於蜂巢式情境及wi-fi情境兩者内。 假定行動裝置並非為固有可定址的，則難以將訊息投送至 行動裝置（尤其係大規模地投送）。 隨著連接至網路之行動裝置的數目增加，按比例調整性 在將通知訊息發送至行動裝置之情境内變成特定問題。舉 例而言，連接至行動裝置之網路裝置可通常一次管理數千 個行動裝置之裝置連接。因此，為容納數億個行動裝置， 將需要數十萬個網路伺服器裝置來管理至彼等數億個裝置 的連接及訊息投送。當然，數十萬個網路伺服器裝置將既 為成本高得令人不敢問津且亦為實施起來非常複雜的。另 外，使用網路词服器裝置之訊息的靜態路由常常不為故障 安全的或容錯的，丨意謂：若網路裝置停機，則有可能通 知訊息將不能夠到達某些行動裝置。 【發明内容】 不贽明描述 m呀吩1王月守很稱 動態地投送至使用者的系統及方法。舉例而言，在— 例中，監測與—使用者之-裝置相關聯的存在資訊。 在資訊指示第一裝置當前是否連接 β逆拱至一無線網路且指 裝置之一當前網路位置。亦監、丨 观測在該第一裝置與一第 道器之間及在該第一裝置與一第- 乐一閘道1§之間傳輸之 的通道品質且在傳輸推播通知時 丁。茨通道品質用以在該 閘道器與該第二閘道器之間進行選擇。 I64767.doc 201251398 【實施方式】 可自結合以下圖式之以下詳細描述來獲得本發明之較好 推播通知服務之實施例 本發明之實施例可實施於推播通知服務之情境内。已由 本申請案之受讓人設計的一種此服務描述於2〇〇9年6月5曰 申請之題為「Push Notification Service」的同在申請中之 美國專利申請案第2010/0227632號中。下文提供推播通知 服務之概述’其後接著為用於實施雙向推播通知之系統及 方法與用於動態路由之系統及方法的詳細描述。 圖1為根據各種實施例之方塊圖。將通知訊息自提供者 1〇2轉遞至行動裝置13〇需要至少一閘道器11〇及一信使 (c〇urier)i2〇。閘道器110自提供者1〇2接收通知訊息（例 如，推播訊息在各種實施例中，提供者1〇2在與閘道器 no建立初始連接後即發送鑑認安全通訊端層（SSL)憑證。 此SSL憑證可組態有額外的使用者定義資料。可在其他實 施例中使用其他安全通信協定(例如，諸如傳送層安全性 (T L S )之密碼協定等）。鑑認器丨丨4使用任何額外的使用者 定義資料來以可信賴方式識別提供者1〇2。 在與特定應m⑼如，Twitt叫目關敎提供者將額 外識別（例如，使用者；t義）資料包括於ssl憑證内的情兄 下，閘道器m不僅能夠鑑認提供者，而且能夠為^者 及應用程式（Twitter)自動地佈建推播服務。換言之，， 器11。可自動地自鑑認憑證提取任何額外識別；料：= 164767.doc 201251398 該額外識別資料（或該資料之部分）附接至訊息（例如，推播 通知訊息）°在—些實施例中，該額外識別資料可識別使 用者可訂用之與提供者（或提供者之應用程式）相關聯的主 題或摘要(feed)。因此，可充分利用鑑認憑證中之額外資 訊來將訊息導引至已訂用主題，摘要或關於該主題/摘要之 請求資訊的行動裝置β α此方&，為提供者自冑地佈建推 播服務。 在自經鑑認之提供者1〇2接收到通知訊息後，閘道器ιι〇 判定通知訊息之目的地區，該目的地區包括於與通知訊息 起發送之符記内。在一些實施例中，未必發送區資訊作 為符記之部分。藉由自符記提取區或以其他方式獲得區資 訊，閘道器110判定目的地區是否匹配由閘道器110維持/ 管理之區。因此，例如，若閘道器110負責區5，則可藉由 閘道器110將自提供者接收之具有目的地區5的所有訊息轉 遞至信使。然而，若負貴區5之閘道器110接收到目的地區 為區8的訊息’則閘道器110必須將通知訊息投送至負責區 5之閘道器。 路由表112用以將來自一閘道器之訊息投送至另一閘道 器。在各種實施例中，DNS(網域名稱服務）用以在閘道器 之間投送訊息。然而’可在其他實施例中使用其他路由協 定。因此，當在閘道器110處接收到訊息時，閘道器11〇判 定其是否為用以轉遞訊息之適當閘道器。若不為用以轉遞 訊息之適當閘道器’則閘道器110執行對路由表U2之路由 表查找以判定用以轉遞訊息之適當閘道器。在一些實施例 I64767.doc · S- 201251398 中’ DNS查找自身用以判定閘道器是否為用於轉遞通知訊 息之適當閘道器。 在閘道器110接收到具有匹配由閘道器110管理之區之特 定目的地區的訊息的狀況下，則閘道器u〇可使用裝置/信 使映射116將彼訊息直接轉遞至適當信使裝置^閘道器j j 〇 自各個信使接收此映射資訊，將在下文更詳細地解釋信 使。將區動態地指派給閘道器。換言之，閘道器u〇可管 理一區之通知訊息持續一時間段，且接著經切換或重新組 態以在稍後的時間管理一不同區之訊息的轉遞。 信使120(類似於閘道器no)為網路裝置。信使12〇包括連 接模组124、反向傳播模组122，且維持裝置資訊126。在 一些實施例中，信使120可管理超過16〇萬個裝置之連接。 信使並不限於與特定區之裝置連接。換言之，信使22〇可 在各種連接裝置屬於不同區的情況下管理裝置連接。 當裝置最初與信使120連接時，信使12〇為該裝置佈建一 區。在各種實施例中，為該裝置所佈建之區係永久性的。 不管針對每一裝置之特定區指派，裝置皆可能出於各種原 因而中斷其與信使12〇之連接。舉例而言，可能歸因於蜂 巢式L號或w卜的號之損失、電力中斷或由於行動裝置已 改變地理位置等等而使連接中斷。當行動裝置嘗試重新連 接至系統且與信使連接時，裝置可與網路上之任何信使連 接以此方 信使12〇可連接至被指派給不同區之裝置。 如上文所提及，信使12()維持與其連接之每一裝置的裝 置資訊126。裝置資訊可包括裝置之區識別符、裝置之唯 164767.doc 201251398 一裝置識別符（UID)及其他裝置資訊。連接模組124用以在 信使120與各種裝置之間建立連接。 信使120亦包括反向傳播模組122。反向傳播模組122用 以將裝置資訊126反向傳播至各別閘道器。基於區資訊而 將裝置資訊反向傳播至閘道器。舉例而言，若信使丨2〇連 接至區11裝置，則信使120將經由連接模組124來佈建與負 責官理區11之閘道器的連接β信使12〇將接著將區裝置 之裝置資訊反向傳播至負責管理區u之閘道器。以類似方 式，信使220將建立與不同區之閘道器的連接以反向傳播 與彼等各別區相關聯之裝置的特定裝置資訊。 行動裝置130包括處理器140、記憶體132'傳輸器134、 接收器136及一或多個應用程式138。處理器14〇包括判定 用於連接至行動裝置230之信使的連接模組142。連接模組 142可使用循環DNS(網域名稱服務）方案以判定待連接之信 使。在其他實施例中，可基於其他資訊（諸如，地理位置 等）來判定k使。接收器13 6在最初與信使連接後即自該信 使接收區識別符。加密模組144將區識別符與裝置之唯— 裝置識別符（UID)組合以產生裝置符記。在各種實施例 中，加密模組144藉由應用雜湊演算法（例如，SHA_〇、 SHA-1、SHA-2、MD5、Whirlpool或其他雜湊演算法）來對 符記進行加密。記憶體132儲存符記。在各種實施例中， 對於行動裝置130而言，由裝置13〇產生及加密之符記維持 恆疋。換§之，UID不改變且裝置之區識別符亦不改變。 一旦已產生符記且對其進行加密，傳輸器234便將符記 164767.doc 201251398 傳輸或發送至各種提供者應用程式（例如，提供者1〇2)。當 裝置130第一次呼叫提供者1〇2時，可傳輸符記。提供者 102可隨任何通知訊息使用符記或將符記包括於任何通知 訊息中，使得可將該符記適當地轉遞回至裝置丨3〇。 圖2為根據各種實施例之方塊圖。詳言之，圖2說明在提 供者與行動裝置之間轉遞通知訊息的各種實例。在一實例 中，裝置1訂用由提供者丨管理之特定應用程式且想要接收 彼應用程式之通知訊息。因此，裝置〗呼叫提供者〗且將其 裝置符記傳輸至提供者丨。如上文所論述，彼符記包括裝 置之UID及其區識別符的加密組合。如圖2中所展示，褒置 1具有區識別符··區15。因此，當提供者w通知訊息發送 至裝置1時，其與系統中之閘道器中的一者連接。在各種 實施例中，提供者1經由循環DNS*連接至閘道器，但在 其他實施例中，可使用其他連接方案。然@，重要的是， 應注意提供者1無需連接至任何特定閘道器以將通知訊息 成功地推播至裝置1。舉例而t，若提供h通常與問道器 1連接且發送意欲用於裝置i之訊息，則閘道器旧查看該 訊息所伴有之符記，且瞭解到該訊息意欲用於區Η中之裝 置。假定間道器1與區9相關聯’則間道器i執行路由表查 找（例如，麵查找）且將訊息投送至負責㈣之閘道器^ 間道器2基於其裝置/信使映射而將訊息發送/轉遞至信使 2。假定信使2連接至裝以，|lH言使2將在先前已將裝们 之裝置資訊反向傳播至閘道器2，此係因為1置丨屬於區Μ 且閘道器2負責管理區15。因此’閘道器2能夠基於其裝置 164767.doc 201251398 信使映射而將訊息轉遞至信使2;信使2接著能夠查找其連 接且將訊息發送至裝置1。 化使2連接至裝置1與裝置2兩者且每一 因此，信使2將該等裝置中之每一者的 在圖2中應注意 裝置屬於不同區 裝置資訊反向傳播至該等各別裝置之適#區。換言之，假 定閘道器2管理區15，則信使2將裝置i之裝置資訊反向傳 播至閘道器2。假定閘道器i負責管理區9，貝,！信使㈣區2 如上文所提及，反向傳 之裝置資訊反向傳播至閘道器1 播涉及信使與閘道器裝置建立連接且發送關於其與各種行 動裝置之連接的資訊（例如，裝置之UID)。 在另實例中，提供者2希望將通知訊息發送至裝置3。 假定提供者2與閘道^建立連接；因此，假定訊息意欲用 於區9裝置（閘道器【負責區9)，則當提供者2將訊息發送至 道器1時’閘道器i判定其為用以轉遞訊息之適當閘道 器。可自圖2瞭解，假定信使i與信使2兩者各自連接至區9 裝置’則閘道器1與信使i及信使2兩者具有連接。然而， 基於分別由信们及信使2反向傳播之裝置/信使映射，閑 道器i可執行映射資訊之查找且判定應將訊息轉遞至信… 以便到達其在裝置3處之目的地…旦信使i接收到訊息， 信使1便將訊息轉遞至裝置3。 圖3為根據各種實施例之操作之流程圖。自連接至一或 多個行動裝置之各別信使動態地接收(310)該等行動裝置之 存在資訊每-行動裝置之存在資訊包括由UID及區識別 符組成之符§己。如本文中所使用之術語「動態地接收」指 164767.doc 201251398 代存在資訊並非靜態的概念。換言之，裝置並非總是連接 至相同信使，且因此需要動態地更新閘道器以將裝置之訊 息適當地轉遞至正確信使。 在第一閘道器裝置處自提供者應用程式接收（320)通知 訊息。該通知訊息包括行動裝置符記。對該符記進行解密 (330)(例如，使用雜湊演算法）以判定與訊息相關聯之區識 別符。捿著判定（340)訊息中之區識別符是否匹配當前由閘 道器管理之區。若訊息中之區識別符不匹配由閘道器管理 之區’則閘道器執行路由表查找且將訊息投送（360)至管理 與該訊息相關聯之區的適當閘道器。若訊息中之區識別符 確實匹配由閘道器管理之區，則閘道器參考其裝置/信使 映射且將訊息轉遞（350)至適當信使。 圖4為根據各種實施例之操作之流程圖。行動裝置建立 (410)至k使裝置之連接。可藉由執行用以建立信使連接之 循環DNS搜尋或其他方案來建立該連接。在與信使裝置連 接後即自信使裝置接收（420)區識別符。在各種實施例中， 僅在與信使之初始連接期間才接收區識別符。換言之，並 不在每次裝置與新信使連接時皆接收區識別符。實情為， 僅在裝置第一次與信使建立任何種類之連接時才接收區識 別符。 產生裝置之符記且經由加密演算法對該符記進行加密 (430)。㈣記包括裝置之唯一識別符(um跑識別符兩 者《可使用雜凑演算法（諸如’先前所描述之雜凑演算法） 來實現加密。-旦已產生符記且對其進行加密便將符記 164767.doc 201251398 傳輸（440)至提供者應用程式。舉例而言，行動裝置之使用 者可下載、安裝及/或訂用特定應用程式（例如，。 在一些實施例中，當行動裝置緊接著呼叫彼提供者廡 式時’行動裝置將符記傳輸至提供者（44()卜符記之傳輸亦 可（例如）在使用者訂用及/或註冊（sign up)應用程式或服務 時發生。 隨後，經由包括至少一閘道器及一信使之路徑而自提供 者應用程式接收（45G)m言之，該畴可包括一個閑 道器或-個以上閘道器。然而，在各種實施例中該路徑 將僅包括-個信使十或多個）閘道器與信使之間的轉遞 路徑係至少部分基於最初自裝置傳輸至提供者應用程式之 符記而判定。 用於雙向推冑通知之系統及方法的實施例 如上文所論述，在-實施例中’提供者經由閘道器及信 使而將通知推播至行動裝置。如圖5,所說明，在架構之 一侧，行動裝置〇|及〇2登錄以藉由建立至特定信使531、 532之安全連接（例如，SSL或TLS連接）來接收推播通知。 如上文所提及，信使531、532維持每—裝置之網路資訊， 包括（例如）每-裝置之區識別符及唯-裝置識別符卿）。 區識別符制裝置被指派至的特定區，該特定區又識別負 貴彼區之閘道器。 在圖5中所展示之特定實例中，閉道器521及⑵負貴投 送區1-500之推播通知，且閘道器切⑽負責投送區5〇ι_ 1000之推播通知。多個閘道器經指派以處置同一範圍之區 164767.doc •12· 201251398 的訊務以提供冗餘、負載平衡及動態資料訊務路由（如本 文中所描述）。舉例而言，若閘道器323變得不起作用，則 其資料訊務（用於區1-500)可臨時由閘道器521服務。然而 應注意，本發明之基本原理並不限於任何特定數目個間道 器或區指派之任何特定集合。 在一實施例中’不同閘道器可位於不同資料中心中。舉 例而言，閘道器521及522可位於第一資料中心中，且閘道 器523及524可位於第二資料中心中。多個冗餘閘道器亦可 位於同一資料中心内。本發明之基本原理可實施於單一資 料中心内或跨越多個資料中心而實施。 如圖5中所說明’提供者501可經由特定介面511連接至 閘道器，該介面511執行與信使針對行動裝置所執行之功 旎類似的功能。每一介面511為特定處理程序，提供者5〇t 可經由該處理程序而經881^或11^連接（亦即，如由使用者 ，、座由執行於行動裝置上之應用程式而鑑認）來安全地傳輸 推播通知。舉例而言，使用者可登錄以接收特定新聞主題 或小組的推播通知，或出於任何其他特殊應用原因來接收 推播通知。提供者5〇 1基於使用者偏好而在適當時間（例 如，週期性地、回應於某些事件等等）產生此㈣播通知。 使用裝置之推播符記而在閘道器上維持裝置之存在資 Λ。因此，當在閘道器處接收到針對特定推播符記之推播 通知時’該閘道器執行查找以判定存在與彼推播符記相關 ，之TCP通汛端描述符。該通訊端描述符提供將推播通知 傳輸至適當信使531(亦即，裝置當前藉以連接的信使）所需 164767.doc 201251398 的TCP通訊端資訊及其他網路連接資訊。 k供者使用裝置之推播符記（例如，該實例中之符記 ，其識料置Dl)來識別|置。肖推播冑記含有間接地 識別負貴彼區（亦即，因為每一閘道器負貴投送指定範圍 之區的訊務）之區識別符。在圖5中所展示之實例中，與裝 置D〗相關聯之符記Τι識別區5〇6，該區5〇6由以下兩個冗餘 閘道器來管理：閘道器522及524。 因此，在圖5中所展示之實例中，可經由閘道器522或 524中之任一者將推播通知傳輸至裝置D"在本發明之一 實施例中，使用循環方案來平衡該等閘道器中之每一者之 間的負載β或者或另外，可監測每一閘道器與每一裝置之 間的通信頻道之品質，且可選擇提供相對較高品質連接的 閘道器。雖然可使用各種不同量測來判定每一閘道器/裝 置頻道之「品質」，但在本發明之一實施例令，品質係基 於在每一閘道器與每一裝置之間傳輸之封包的所量測之往 返時間。因此，如圖5中所指示，可儲存與每一裝置相關 聯之當前往返時間（RTT)值，且隨後將其用以選擇經由特 定閘道器之特定路線。假定冗餘閘道器（521/523及 522/524)中之每一者可位於不同資料中心中，則選定閘道 器可趨向於位於與裝置當前附接至的信使相同的資料中心 中（但本發明之基本原理並不限於此特定實施）。 在一實施例中，提供者501之介面5 11可最初進行網域名 稱服務（DNS)呼叫以識別投送特定推播通知所需之閘道器 中之每一者的網路位址（例如’ IP位址）。如先前所描述， 164767.doc
S 14 201251398 推播符記（諸如，吾人之實例中之T!)識別區，且彼區識別 閘道器之特定集合（亦即，在吾人之實例中，區5〇6識別冗 餘閘道器522及524)。因此，介面511可最初產生形式為 少./jws/i.app/e.com(亦即，其中在位址之第一部分中 的6識別區6)之DNS查詢》DNS伺服器接著用負責區6之閘 道器522及523中之每一者的IP位址來對介面查詢作出回 應。介面511可接著選擇該等閘道器中之一者來傳輸推播 通知。 在一實施例中，介面511基於與用於特定裝置之特定間 道器相關聯的當前往返時間（RTT)來選擇彼閘道器，該推 播係針對該特定裝置。舉例而言，若閘道器522具有比閘 道器524相對短的RTT，則介面5 11可選擇閘道器522。哎 者’代替介面選擇具有相對較低RTT之閘道器的做法為， 可回應於DNS查詢而將具有最低RTT之閘道器的網路位址 提供至介面，或可按照優先次序（其中具有最低RTT之閘道 器的網路位址位於優先順序清單之頂部）將網路位址之集 合發送至介面。在此實施例中，DNS可與閘道器中之每一 者整合或可與該閘道器通信以擷取及處理各種尺丁丁值。然 而應注f，本發明之基本原理並不限於選擇經由閑道器之 路線的特定方式。各種不同組態係可能的且涵蓋於本發明 之範疇内。 除基於RTT值來進行投送外，在一實施例中，亦可實施 循環方案(例如’用於負載平衡舉例而言，只要與閘道 器中之每-者相關聯的RTT值在指定臨限值内，則任一開 164767.doc 15 201251398 道器便可表示可行的路由選項。在此狀況下，可賴㈣ 方案中接連的下-閘道器。在一實施例中，可僅藉由且有 在指定臨限值内之RTT值的彼等閘道器來執行_方案。 舉例而言，若存在八個不同的可能閉道器，但僅有兩個閘 道器具有在該臨限值内之RTT值，則可僅在該兩個閉道器 之間實施循環方案。當在同一資料中心内存在負貴同一區 或區範圍的多個閘道器時，此實施例可尤為有利。在此狀 況下，該兩個閘道器可具有相對類似之RTT值，但此等 RTT值可顯著低於剩餘6個閘道器（其可位於不同資料中心 中）之RTT值。當然應注意，本發明之基本原理並不限於資 料中心之間的閘道器的任何特定分佈。 在一實施例中，不將RTT與靜態臨限值相比較。更確切 而。，比較各個RTT值之間的差異，且若一些RTT值顯著 低於其他RTT值而使差異超出指定臨限值，則將選擇具有 較低RTT值之閘道器。 圖6中說明用於投送推播通知之方法之一實施例。該方 法可實施於圖5中所展示之架構的情境内，但其並不限於 任何特定系統架構。 在601處’自特定行動裝置接收存在資訊，該存在資訊 向推播通知服務識別裝置（例如，識別特定信使，裝置經 由該特定信使而連接）。如上文所提及，在一實施例中， 裝置之符記與通訊端描述符相關聯，該通訊端描述符識別 將每一閘道器連接至每一信使的TCP通訊端，該信使又維 持與裝置之連接。 164767.doc
S • 16 - 201251398 在602處’監測裝置中之每—者與閘道器中之每一者之 間的往返時間(RTT)。在一實施例中，在由閉道器管理之 表内持續地更新每-GW/裝置組合之町值，但此組態對 於遵照本發明之基本原理而言並無必要。 在603處，藉由使用者已訂用之特定提供者來產生推播 通知。舉例而言，可發生關於使用者之最愛小組中之一者 的特定事件’或可使安裝於使用者之裝置上的軟體之新版 本變得可用。 在604處，選擇路線以經由特定閘道器來投送推播通 知。如先前所提及，可藉由介面（提供者經由其而連接）回 應於DNS查詢而指示該路線，或替代地，該路線可由介面 自身產生。另外，可結合RTT值來實施有限循環方案（如上 文所論述）。選擇閘道器以將推播通知有效地投送至裝置 而不管特定實施。 用於雙向推播之系統及方法 以上論述集中於將由提供者產生之推播通知投送至行動 裝置的單向實施。另外，本發明之一實施例開啟自裝置至 提供者之推播通道，藉此實現提供者與裝置之間的雙向推 播通仏。可使用雙向實施（例如）以產生至提供者之反饋通 知（例如，使用讀取回條來偵測使用者何時已讀取、應答 或以其他方式取用（consume)推播通知）。 參看圖7，在一實施例中，提供者經由介面71丨而開啟至 預先指定之TCP埠的通訊端連接，以便指示提供者正傾聽 通知。在圖7中所展示之實例十，此埠一般被稱作「埠 I64767.doc 201251398 X」’但可使用任何預先指定之埠。出於鑑認目的，每一提 供者指派有唯-憑證’該憑證可用以為提供者產生區號 媽。在-實施例中，提供者將其憑證提供至介面該介面 接著對憑證執行料⑽如，SHA]^[杨##定教^ 避彦翁以料。，）以產生提供者符記⑽似於裝置 符記）’該提供者符記包括區號碼（在圖7中所展示之實例中 為區5⑻。可接著由行動裝置上之應用程式(或由其他服 務）來指定此符記/區號碼，以將推播通知傳輸至每一各別 提供者。 因此’正如信使向閘道器登錄裝置之存在（如上文所論 述）’每一提供者可登錄其在負貴其區之閘道器内的存 在。如圖7中所㈣，提供者之存在資料儲存於在負貴提 供者之所指派區之每一閘道器上的表上。如所指示，存在 資訊可包括在閘道器與每一各別提供者之間傳輸之封包的 往返時間（RTT)。正如信使之灯丁值用以選#閉道器（如上 文所描述），與提供者相關聯之RTT值可接著用以在用於區 之冗餘閘道器中之每—者之間進行選擇。應注意，雖然圖 7中未說明，但與針對閘道器524所展示之提供者存在及裝置 存在相同的提供者存在及裝置存在可儲存於閘道器522内。 將推播通知傳輸至特定提供者的裝置藉由提供者之符記 來識別彼提供者，該符記制與彼符記相關聯之區來識別 閘道器。在一實施例中，裝置連接至的信使最初自提供 者之符記提取提供者之區號碼，且使用該區號碼來產生 DNS查詢以識別負貴彼區之閘道器的ip位址（例如， 164767.doc . 18·
S 201251398 518·容aiewa少.卿Λ卿化c〇w，其中5i8識別該區）。d則功 貪b〖生可實施於與閘道器相同之硬體平台内，或可使用單獨 之專用硬體。可接著回應於針對多個冗餘閘道器之DNs查 «旬而傳回多個IP位址。在一實施例中，可使用循環方案、 RTT值或該兩者之組合來排定此等”位址之優先順序（如上 文所論述卜舉例而言’若一組閘道器具有顯著低於用於 此特定提供者之其他閘道器的RTT值（例如，低了指定臨限 里），則可對此組閘道器實施循環方案。 不管如何排定閘道器之優先順序，選定閘道器皆使用提 供者連接至的介面之通訊端描述符資料將推播$知傳輸至 提供者。提供者可接著讀取推播通知之内容且以任何特殊 應用方式作出回應°舉例而言，若推播通知為讀取回條， 則提供者可將該讀取回條中所含有之資訊儲存於使用者資 料庫内。當然’本發明之基本原理並不限於本文中所描述 反内推播功育b的任何特定使用。此外，同一提供者可經 由若干不同閘道器連接至若干不同介面’同時仍遵照本發 明之基本原理。 圖8說明根據本發明之一實施例之方法。該方法可在圖7 中所展示之架構的情境内執行，但其並不限於任何特定架 構。 在801處，提供者經由指定埠（例如，在圖7中所展示之 實例中的埠X)而連接至推播通知服務且提供其憑證。在 =2處，執打憑證之雜湊以識別提供者之區。在8〇3處，將 提供者之存在資料（例如，TCP通訊端資料及當前狀態）儲 164767.doc 19 201251398 存於負責此特；^之閘道器内。在_處，自裝置中之一 者接收推播通知’且基於經由閉道器中之每一者的通訊端 連接之當前品請如，在—實施例中，如由往返時間來 識別）而選擇經由特定閘道器之路線。最後在祕處由 提供者接收反向推播通知，其 丹j以任何數目種預先指定之 方式對反向推播通知之接收起作用。 本發明之實施例可包括如上 扣π工又所陳述之各個步驟。該等 步驟可以使通用或專用虛进哭袖— 處里1§執仃某些步驟的機器可執行 指令體現。或者，可藉由姓中 稭由特疋硬體組件（其含有用於執行 該專步驟之固線式邏輯）成藉 、科）名稭由經程式化之電腦組件及定 製硬體組件的任何組合來執行此等步驟。 亦可將本發明之凡件提供為用於儲存機器可執行程式碼 之機器可讀媒體。機器可讀媒體可包括(但不限於)軟碟、 光碟、CD-ROM 及磁光碟、R〇M、ram、EpR〇M、 EEPR〇M、磁卡或光卡，或適合於㈣電子程式碼之其他 類型的媒體/機器可讀媒體。 貫穿以上描述，出於解釋之㈣，陳述了眾多特定細節 以便提供對本發明之透徹理解mm項技術者將 顯而易見’可在無此等特定細節中之—些特定細節的情況 下實踐本發明。舉例而言1習此項技術者將易於顯而易 見，可將本文令所描述之功能模組及方法實施為軟體、硬 體或其任何組合。此外，雖然本文中在行動計算環境（亦 即’使用行動裝置12(Μ23 ; 6〇ΐ·6()3)之情境内描述本發明 之實施例，但本發明之基本原理並不限於行動計算實施。 164767.doc
•20· 201251398 實際上，可在一些實施例中使用任何類型之 厂响取同級 貢料處理裝置包括（例如）桌上型電腦或工作站電 此’應依據下文之申請專利範圍來判斷本發明之範嘴及精 神0 【圖式簡單說明】 圖1為說明根據各種實施例之系統之方塊圖。 圖2為根據各種實施例之方塊圖。 圖3為根據各種實施例之操作之流程圖。 圖4為根據各種實施例之操作之流程圖。 圖5說明系統架構之一實施例，該系統架構用於選擇提 供者與裝置之間的經由閘道器之最佳路線。 圖6說明用於選擇提供者與裝置之間的經由閘道器之最 佳路線的方法之一實施例。 圖7說明用於提供雙向推播通知之系統之一實施例。 圖8說明用於提供雙向推播通知之方法之一實施例。 【主要元件符號說明】 102 提供者 110 閘道器 112 路由表 114 鑑認器 116 裝置/信使映射 120 信使/裝置 122 反向傳播模組 124 連接模組 164767.doc •21 · 裝置資訊 應用程式 記憶體 傳輸器 接收器 應用程式 處理器 連接模組 加密模組 提供者 區 介面 區 閘道器 閘道器 閘道器 閘道器 信使 信使’ 介面 行動裝置 行動裝置 符記 符記 -22-