JP5756884B2 - 二方向プッシュ通知のためのシステム及び方法 - Google Patents

Description

（優先権の主張）本願は、２０１１年６月３日出願の米国仮特許出願第６１／４９２，８８２号の３５Ｕ．Ｓ．Ｃ．第１１９条（ｅ）に基づく出願日の恩典を主張する。

本発明は、概括的には移動体デバイスの処理の分野に、より厳密には移動体デバイスとアプリケーションプロバイダの間で伝送される通知メッセージの管理に、関する。

移動体デバイス（ラップトップ、パームトップ、携帯電話、スマートフォン、マルチメディアフォン、ポータブルメディアプレーヤー、ＧＰＳユニット、携帯ゲームシステム、など）のユーザーは、通知サービスからの通知メッセージを周期的に受信するアプリケーションをインストールしていることであろう。例えば、その様なアプリケーションには、「プッシュ」ｅ−メールサービス（例えば、ＭｏｂｉｌｅＭｅ（Ｒ）、Ｍｉｃｒｏｓｏｆｔ（Ｒ） Ｅｘｃｈａｎｇｅ、ＡｃｔｉｖｅＳｙｎｃ（Ｒ）、Ｐｕｓｈ−ＩＭＡＰ（Ｒ）、Ｙａｈｏｏ！（Ｒ）Ｐｕｓｈ、など）及び他のプッシュサービス（例えば、更新／アップグレードサービス、ニュースサービス、ウェブブログサービス、ポッドキャストサービス、ソーシャルネットワーキングサービス、又は通知メッセージが送信されることになっている他の型式のサービス）が含まれる。通知メッセージは、典型的には、関心事象を表しており、その様な関心事象はアプリケーションによって定義されているのが典型的である（例えば、新ｅ−メールインジケータ、新ニュース項目インジケータ、新ポッドキャストインジケータ、ソーシャルネットワーキングの友人のオンライン状態の変更、など）。

移動体デバイスの使用の増加は、通知メッセージをそれらのデバイスへ経路指定することの複雑さを拡大させる。１つの問題は、移動体デバイスが元来アドレス可能にはなっていないことであり、例えば、現在のところ、ＩＰｖ６の移動体版は無い。換言すると、移動体デバイスは、デスクトップコンピュータまた更にはラップトップコンピュータがＩＰアドレスを有しているのと同じやり方で自身のＩＰアドレスを持っていない。また、移動体デバイスは、恐らくネットワークアドレストランスレーション（ＮＡＴ）を採用しているであろうサービスプロバイダのファイアウォールに論理的に遅れをとっていることも時にある。その様なファイアウォールは、セルラー関連内においても、またｗｉ−ｆｉ関連内においても、適用可能である。移動体デバイスが元来アドレス可能でないことを考えると、移動体電話へメッセージを経路指定することは、特にそれを大規模に行うことは、困難である。

ネットワークへ接続される移動体電話の数が増えるにつれ、移動体電話へ送信される通知メッセージとの関連内でスケーラビリティは特別な問題となる。例えば、移動体デバイスへ接続しているネットワークデバイスは、典型的に、同時に何千もの移動体デバイスについてのデバイス接続を管理している。したがって、何億もの移動体デバイスに対応するとなると、それら何億ものデバイスへの接続及びメッセージの経路指定を管理するのに何十万ものネットワークサーバデバイスが必要になろう。当然ながら、何十万ものネットワークサーバデバイスは、法外な費用がかかり、実装するのは非常に手間が掛かる。加えて、ネットワークサーバデバイスを使用するメッセージの静的経路指定は、フェイルセーフでもなくフォールトトレラントでもない場合が多く、翻せば、ネットワークデバイスが故障したら、通知メッセージが特定の移動体デバイスに到達できなくなる可能性があるということである。

米国仮特許出願第６１／４９２，８８２号 米国特許出願第２０１０／０２２７６３２号

プロバイダと移動体デバイスの間の二方向プッシュ通信を確立するためのシステム及び方法が記載されている。プロバイダは（移動体デバイスの様に）、指定されたユーザーセットからのプッシュ通知に備えて傾聴するよう登録する。その後、プロバイダの存在が継続的に監視されて、プロバイダが事前に指定されているポートを介して現在傾聴しているかどうかが判定される。そうである場合、１人又はそれ以上のユーザーのセットからの第１のプロバイダ宛てのプッシュ通知を受信したことに応えて、当該プロバイダがプッシュ通知に備えて傾聴している現在のネットワーク場所が識別され、プッシュ通知は第１のプロバイダへ転送される。

本発明のより深い理解は、添付図面に関連付けられた次に続く詳細な説明から得られることであろう。

様々な実施形態によるシステムを示しているブロック線図である。 様々な実施形態によるブロック線図である。 様々な実施形態による動作の流れ図である。 様々な実施形態による動作の流れ図である。 プロバイダとデバイスの間のゲートウェイを介する最適経路を選択するためのシステムアーキテクチャの１つの実施形態を示している。 プロバイダとデバイスの間のゲートウェイを介する最適経路を選択するための方法の１つの実施形態を示している。 二方向プッシュ通知を提供するためのシステムアーキテクチャの１つの実施形態を示している。 二方向プッシュ通知を提供するための方法の１つの実施形態を示している。

本発明の実施形態は、プッシュ通知サービスとの関連内で実施され得る。本願の譲受人によって設計されている１つのその様なサービスが、２００９年６月５日にプッシュ通知サービスという名称で出願されている同時係属米国特許出願第２０１０／０２２７６３２号に記載されている。プッシュ通知サービスの概観が以下に提供されており、それに続けて、二方向プッシュ通知を実施するためのシステム及び方法並びに動的経路指定のためのシステム及び方法の詳細な説明が提供されている。

図１は、様々な実施形態によるブロック線図である。プロバイダ１０２から移動体デバイス１３０への通知メッセージの転送は、少なくとも、１つのゲートウェイ１１０と１つのクーリエ１２０を要する。ゲートウェイ１１０は、プロバイダ１０２からの通知メッセージ（例えば、プッシュメッセージ）を受信する。様々な実施形態では、プロバイダ１０２は、ゲートウェイ１１０との初期接続に際し、認証セキュアソケットレイヤー（ＳＳＬ）証明書を送信する。このＳＳＬ証明書は、追加のユーザー定義データ付きで構成されてもよい。他の実施形態では、他のセキュア通信プロトコル（例えば、トランスポートレイヤーセキュリティ（ＴＬＳ）の様な暗号化プロトコルなど）が使用されることもあろう。認証部１１４は、何らかの追加のユーザー定義データを使用して、信頼できる様式でプロバイダ１０２を識別する。

或る特定のアプリケーション（例えば、ツイッター）と関連付けられるプロバイダが追加の識別用の（ユーザー定義）データをＳＳＬ証明書内に含んでいる場合、ゲートウェイ１１０は、プロバイダを認証するに留まらず、更に、当該プロバイダ及びアプリケーション（例えば、ツイッター）についてプッシュサービスを自動的に供給することになる。換言すると、ゲートウェイ１１０は、認証証明書から何らかの追加の識別用データを自動的に抽出し、当該追加の識別用データ（又はデータの一部分）をメッセージ（例えば、プッシュ通知メッセージ）へ添付する。一部の実施形態では、追加の識別用データは、ユーザーが加入しているプロバイダ（又はプロバイダのアプリケーション）と関連付けられるトピック又はフィードを識別するものであってもよい。したがって、認証証明書中の追加情報を活用して、当該トピック／フィードに加入している又はトピック／フィードに関する情報を要求している移動体デバイスへメッセージを方向決めさせることができる。この様にして、プロバイダについてプッシュサービスが自動的に供給される。

ゲートウェイ１１０は、認証されたプロバイダ１０２からの通知メッセージを受信すると、通知メッセージの宛先ゾーンを確定する。宛先ゾーンは、通知メッセージと共に送信されるトークン内に含まれている。一部の実施形態では、ゾーン情報をトークンの一部として送信することは必須ではない。ゾーンをトークンから抽出するか又はそれ以外のやり方でゾーン情報を取得することにより、ゲートウェイ１１０は、宛先ゾーンがゲートウェイ１１０によって保守／管理されているゾーンに一致するかどうかを判定する。よって、例えばゲートウェイ１１０がゾーン５に責任のある場合、プロバイダから受信されたメッセージで宛先ゾーン５を有する全てのメッセージは、ゲートウェイ１１０によってクーリエへ転送されることになる。但し、ゾーン５に責任のあるゲートウェイ１１０が、宛先ゾーンがゾーン８になっているメッセージを受信した場合、ゲートウェイ１１０は通知メッセージを、ゾーン５に責任のあるゲートウェイへ経路指定しなくてはならない。

経路指定表１１２が、メッセージを１つのゲートウェイから別のゲートウェイへ経路指定するのに使用される。様々な実施形態では、メッセージをゲートウェイ間で経路指定するのにＤＮＳ（ドメインネームサービス）が使用されている。とはいえ、他の実施形態では、他の経路指定プロトコルが使用されることもあろう。したがって、メッセージがゲートウェイ１１０で受信されたとき、ゲートウェイ１１０は、自身がメッセージを転送するのに適切なゲートウェイであるかどうかを判定する。そうでなかった場合、ゲートウェイ１１０は、経路指定表１１２の経路指定表ルックアップを遂行して、メッセージを転送するのに適切なゲートウェイを確定する。一部の実施形態では、ゲートウェイが通知メッセージを転送するのに適切なゲートウェイであるかどうかを判定するのにＤＮＳルックアップそのものが使用されている。

ゲートウェイ１１０が、ゲートウェイ１１０によって管理されているゾーンに一致する特定の宛先ゾーンを有するメッセージを受信した場合、ゲートウェイ１１０は、デバイス／クーリエマッピング１１６を使用して、当該メッセージを直接に適切なクーリエデバイスへ転送することができる。ゲートウェイ１１０は、このマッピング情報を様々なクーリエから受信しており、それについては以下に更に詳細に解説されている。ゾーンは、ゲートウェイへ動的に割り当てられている。換言すると、ゲートウェイ１１０は、或る期間は１つのゾーンについて通知メッセージを管理するものであり、その後、切り替えられるか又は構成し直されて、後の期間は異なったゾーンについてメッセージの転送を管理することになるかもしれない。

クーリエ１２０は、ゲートウェイ１１０と同様に、ネットワークデバイスである。クーリエ１２０は、接続モジュール１２４と逆伝播モジュール１２２を含み、デバイス情報１２６を保守している。クーリエ１２０は、一部の実施形態では、１６０万台以上のデバイスについて接続を管理している。クーリエは、特定のゾーンのデバイスと接続することに限定されていない。換言すると、クーリエ１２０は、様々な接続される側のデバイスが異なったゾーンに属しているデバイス接続を管理するものである。

デバイスが最初にクーリエ１２０と接続するとき、クーリエ１２０はデバイスについてゾーンを供給する。様々な実施形態では、デバイスについて供給されるゾーンは永久的である。それぞれのデバイスについての特定のゾーン割当にかかわらず、デバイスは自身のクーリエ１２０との接続を様々な理由で失うことがある。例えば、接続は、セルラー信号又はｗｉ−ｆｉ信号の喪失、パワーの喪失、又は移動体デバイスが地理的場所を変えたため、など、のせいで失われてしまうかもしれない。移動体デバイスが、システムへ再接続しクーリエと接続しようと試みたとき、デバイスはネットワーク上の何れのクーリエとも接続する可能性がある。このやり方では、クーリエ１２０は、異なったゾーンへ割り当てられているデバイスへ接続されないとも限らない。

上述の様に、クーリエ１２０は、接続相手のそれぞれのデバイスについてのデバイス情報１２６を保守している。デバイス情報は、デバイスについてのゾーン識別子、デバイスについての固有デバイス識別子（ＵＩＤ）、及び他のデバイス情報を含んでいよう。クーリエ１２０と様々なデバイスの間に接続を確立するのに接続モジュール１２４が使用される。

クーリエ１２０は、更に、逆伝播モジュール１２２を含んでいる。逆伝播モジュール１２２は、デバイス情報１２６を各ゲートウェイへ逆伝播させるのに使用される。デバイス情報は、ゾーン情報に基づいてゲートウェイへ逆伝播される。例えば、クーリエ１２０がゾーン１１のデバイスへ接続されているなら、クーリエ１２０は、接続モジュール１２４を介し、ゾーン１１の管理に責任のあるゲートウェイとの接続を供給することになる。クーリエ１２０は、次いで、ゾーン１１のデバイスについてのデバイス情報を、ゾーン１１の管理に責任のあるゲートウェイへ逆伝播させる。同様の様式で、クーリエ１２０は、異なった各々のゾーンと関連付けられているデバイスについての特定のデバイス情報を逆伝播させるべくそれら異なったゾーンのゲートウェイとの接続を成すことになる。

移動体デバイス１３０は、プロセッサ１４０、メモリ１３２、送信器１３４、受信器１３６、及び１つ又はそれ以上のアプリケーション１３８を含んでいる。プロセッサ１４０は、移動体デバイス１３０への接続用のクーリエを確定する接続モジュール１４２を含んでいる。接続モジュール１４２は、接続相手のクーリエを確定するのにラウンドロビンＤＮＳ（ドメインネームサービス）スキームを使用していてもよい。他の実施形態では、クーリエは、地理的場所などの様な他の情報に基づいて確定されることもあろう。受信器１３６は、最初にクーリエと接続すると、クーリエからゾーン識別子を受信する。暗号化モジュール１４４は、デバイスについてのゾーン識別子と固有デバイス識別子（ＵＩＤ）を組み合わせてデバイストークンを生成する。様々な実施形態では、暗号化モジュール１４４は、ハッシングアルゴリズム（例えば、ＳＨＡ−０、ＳＨＡ−１、ＳＨＡ−２、ＭＤ５、Ｗｈｉｒｐｏｏｌ、又は他のハッシングアルゴリズム）を適用することによって、トークンを暗号化する。メモリ１３２はトークンを格納する。デバイス１３０によって生成され暗号化されたトークンは、様々な実施形態では、移動体デバイス１３０について不変に維持される。換言すると、ＵＩＤは変化しないし、デバイスについてのゾーン識別子もまた変化しない。

ひとたびトークンが生成され暗号化されたら、送信器１３４がトークンを様々なプロバイダアプリケーション（例えば、プロバイダ１０２）へ伝送又は送信する。トークンは、デバイス１３０がプロバイダ１０２を最初に呼び出したときに伝送されてもよい。プロバイダ１０２は、トークンを適切にデバイス１３０へ折り返し転送できるように、トークンを何らかの通知メッセージと一体に使用するか又は含むことができる。

図２は、様々な実施形態によるブロック線図である。具体的には、図２は、プロバイダと移動体デバイスの間での通知メッセージの転送の諸例を示している。１つの例では、デバイス１はプロバイダ１によって管理されている或る特定のアプリケーションへ加入しており、当該アプリケーションについての通知メッセージを受信することを所望している。したがって、デバイス１は、プロバイダ１を呼び出し、自身のデバイストークンをプロバイダ１へ伝送する。以上に論じられている様に、当該トークンは、デバイスのＵＩＤとデバイスのゾーン識別子の暗号化された組合せを含んでいる。図２に示されている様に、デバイス１はゾーン識別子であるゾーン１５を有している。したがって、プロバイダ１が通知メッセージをデバイス１へ送信するとき、それはシステム内のゲートウェイの１つと接続する。様々な実施形態では、プロバイダ１は、ラウンドロビンＤＮＳを介してゲートウェイへ接続するが、他の実施形態では、他の接続スキームを使用することができる。但し、プロバイダ１は何ら特定のゲートウェイへ接続しなくても通知メッセージをデバイス１へ成功裏にプッシュできる、ということに着目するのが肝要である。例えば、プロバイダ１が通常はゲートウェイ１と接続していて、デバイス１宛てのメッセージを送信している場合、ゲートウェイ１がメッセージに附随するトークンを目にし、メッセージがゾーン１５のデバイス向けであることを理解する。ゲートウェイ１がゾーン９と関連付けられていることを考えると、ゲートウェイ１は経路指定表ルックアップ（例えば、ＤＮＳルックアップ）を遂行し、ゾーン１５に責任のあるゲートウェイ２へメッセージを経路指定する。

ゲートウェイ２は、それのデバイス／クーリエマッピングに基づき、クーリエ２へメッセージを送信／転送する。クーリエ２がデバイス１へ接続されていることを考えて、デバイス１がゾーン１５に属しておりゲートウェイ２がゾーン１５の管理に責任のあることから、クーリエ２はデバイス１についてのデバイス情報をゲートウェイ２へ既に逆伝播させているはずである。したがって、ゲートウェイ２は、それのデバイスクーリエマッピングに基づき、メッセージをクーリエ２へ転送することが可能であり、するとクーリエ２がそれの接続をルックアップし、メッセージをデバイス１へ送信することができる。

図２では、クーリエ２はデバイス１とデバイス２の両方へ接続されており、それぞれのデバイスは異なったゾーンに属していることに留意されたい。したがって、クーリエ２は、それらデバイスのそれぞれについてのデバイス情報を各々のデバイスに該当するゾーンへ逆伝播させる。換言すると、ゲートウェイ２はゾーン１５を管理していることを考えると、クーリエ２はデバイス１についてのデバイス情報をゲートウェイ２へ逆伝播させる。ゲートウェイ１はゾーン９の管理に責任のあることを考えると、クーリエ２はゾーン２についてのデバイス情報をゲートウェイ１へ逆伝播させる。上述の様に、逆伝播には、クーリエがゲートウェイデバイスとの接続を確立し、それの様々な移動体デバイスとの接続についての情報（例えば、デバイスについてのＵＩＤ）を送信することが伴う。

別の例では、プロバイダ２が、通知メッセージをデバイス３へ送信することを望んでいる。プロバイダ２はゲートウェイ１との接続を確立すると仮定して、プロバイダ２がメッセージをゲートウェイ１へ送信したとき、メッセージがゾーン９のデバイス向けである（ゲートウェイ１はゾーン９に責任のある）ことを考えると、ゲートウェイ１は自身がメッセージを転送するのに適切なゲートウェイであると判断する。図２から分かる様に、クーリエ１とクーリエ２がどちらもそれぞれがゾーン９のデバイスへ接続されていることを考えると、ゲートウェイ１はクーリエ１とクーリエ２の両方と接続を有している。但し、クーリエ１及びクーリエ２によってそれぞれ逆伝播されるデバイス／クーリエマッピングに基づき、ゲートウェイ１はマッピング情報のルックアップを遂行し、メッセージを、その宛先であるデバイス３へ到達させるために、クーリエ１へ転送させるべきであると判断する。クーリエ１がメッセージを受信したら、クーリエ１はメッセージをデバイス３へ転送する。

図３は、様々な実施形態による動作の流れ図である。１つ又はそれ以上の移動体デバイスについての存在情報が、移動体デバイスへ接続されている各々のクーリエから動的に受信される３１０。それぞれの移動体デバイスについての存在情報は、ＵＩＤ及びゾーン識別子から成るトークンを含んでいる。ここでの使用に際し、「動的に受信する」という用語は、存在情報が静的ではないとする概念をいう。換言すると、デバイスは常に同じクーリエへ接続されているとは限らず、従って、ゲートウェイは、デバイス宛てのメッセージを正しいクーリエへ適切に転送するために動的に更新される必要がある。

通知メッセージが、第１ゲートウェイデバイスで、プロバイダアプリケーションから受信される３２０。通知メッセージは、移動体デバイストークンを含んでいる。トークンは、メッセージと関連付けられているゾーン識別子を判定するべく（例えば、ハッシングアルゴリズムを使用して）復号化される３３０。次いで、メッセージ中のゾーン識別子がゲートウェイによって現在管理されているゾーンに一致しているかどうかが判定される３４０。メッセージ中のゾーン識別子がゲートウェイによって管理されているゾーンに一致しない場合、ゲートウェイは、経路指定表ルックアップを遂行し、メッセージを、当該メッセージと関連付けられるゾーンを管理している適切なゲートウェイへ経路指定する３６０。メッセージ中のゾーン識別子がゲートウェイによって管理されているゾーンに正に一致する場合、ゲートウェイはそれのデバイス／クーリエマッピングを参照し、メッセージを適切なクーリエへ転送する３５０。

図４は、様々な実施形態による、動作の流れ図である。移動体デバイスは、クーリエデバイスへの接続を確立する４１０。接続は、クーリエ接続を確立するラウンドロビンＤＮＳサーチ又は他のスキームを遂行することによって確立することができる。クーリエデバイスと接続すると、クーリエデバイスからゾーン識別子が受信される４２０。様々な実施形態では、ゾーン識別子は、クーリエとの初期接続時に限って受信される。換言すると、ゾーン識別子は、デバイスが新しいクーリエと接続する度毎に受信されるわけではない。そうではなく、ゾーン識別子は、デバイスがクーリエとの何らかの種類の接続を成した初回に限って受信される。

デバイスについてのトークンが生成され、暗号化アルゴリズムを介して暗号化される４３０。トークンは、デバイスの固有識別子（ＵＩＤ）とゾーン識別子の両方を含んでいる。暗号化は、既に説明されているハッシングアルゴリズムの様なハッシングアルゴリズムを使用して達成されてもよい。ひとたびトークンが生成され暗号化されたら、トークンはプロバイダアプリケーションへ伝送される４４０。例えば、移動体デバイスのユーザーは、或る特定のアプリケーション（例えば、ツイッター）をダウンロードする、インストールする、及び／又はそこへ加入するかもしれない。一部の実施形態では、移動体デバイスは、次に当該プロバイダアプリケーションを呼び出したとき、トークンをプロバイダへ伝送する４４０。トークンの伝送は、同様に、例えばユーザーがアプリケーション又はサービスを購買する及び／又はそれにサインアップする時点で起こってもよい。

続いて、メッセージが、プロバイダアプリケーションから、少なくとも１つのゲートウェイとクーリエを含んでいる通路を介して受信される４５０。換言すると、通路は、１つのゲートウェイを含んでいるかもしれないし、又は１つより多いゲートウェイを含んでいるかもしれない。但し、様々な実施形態では、通路はクーリエを１つしか含んでいないことになっている。（単数又は複数の）ゲートウェイとクーリエの間の転送用通路は、少なくとも一部は、当初にデバイスからプロバイダアプリケーションへ伝送されたトークンに基づいて確定される。

［二方向プッシュ通知のためのシステム及び方法の実施形態］
以上に論じられている様に、１つの実施形態では、プロバイダは、移動体デバイスへの通知をゲートウェイ及びクーリエを通してプッシュする。図５に示されている様に、アーキテクチャの一方の側では、移動体デバイスＤ₁とＤ₂が、特定のクーリエ５３１、５３２へのセキュア接続（例えば、ＳＳＬ接続又はＴＬＳ接続）を確立することによってプッシュ通知を受信するよう登録する。上述の様に、クーリエ５３１、５３２は、それぞれのデバイスについて例えばデバイス毎のゾーン識別子及び固有デバイス識別子（ＵＩＤ）を含むネットワーク情報を保守している。ゾーン識別子は、デバイスが割り当てられている特定のゾーンを識別し、ひいては当該ゾーンに責任のあるゲートウェイを識別する。

図５に示されている特定の例では、ゲートウェイ５２１及び５２３は、ゾーン１−５００宛てのプッシュ通知の経路指定に責任があり、ゲートウェイ５２２−５２４はゾーン５０１−１０００宛てのプッシュ通知に責任がある。同じゾーン範囲宛てのトラフィックを扱うのに、冗長性、負荷均衡化、及び動的データトラフィック経路指定（本書に記載）を提供するべく、複数のゲートウェイが割り当てられている。例えば、ゲートウェイ５２３が動作不能になった場合、それのデータトラフィック（ゾーン１−５００宛て）は、一時的にゲートウェイ５２１によってサービス供与されることになろう。但し、本発明の根底の原理は、何れの特定のゲートウェイ数にも、また何れの特定のゾーン割当のセットにも限定されないことに留意されたい。

１つの実施形態では、異なったデータセンターには異なったゲートウェイが置かれている。例えば、ゲートウェイ５２１及び５２２は第１のデータセンターに置かれ、ゲートウェイ５２３及び５２４は第２のデータセンターに置かれていてもよい。更に、同じデータセンター内に複数の冗長ゲートウェイが置かれていてもよい。本発明の根底の原理は、単一のデータセンター内で実施されてもよいし、又はデータセンターを跨いで実施されてもよい。

図５に示されている様に、プロバイダ５０１は、クーリエが移動体電話のために遂行するのと類似の機能を遂行している特定のインターフェース５１１を通して、ゲートウェイへ接続している。それぞれのインターフェース５１１は、プロバイダ５０１がプッシュ通知をＳＳＬ又はＴＬＳ接続（即ち、移動体デバイス上で実行されるアプリケーションを介しユーザーによって認定されている）を通して安全に伝送できるようにするプロセスである。例えば、ユーザーは、特定のニューストピック又はチームを求めて、又は何らかの他のアプリケーション固有の理由から、プッシュ通知を受信するように登録することであろう。プロバイダ５０１は、これらのプッシュ通知を、ユーザーの嗜好に基づいて、適切な時期に（例えば、周期的に、一部の特定の事象に応えて、など）生成する。

デバイスの存在情報は、ゲートウェイ側で、デバイスのプッシュトークンを使用して保守される。従って、プッシュ通知が或る特定のプッシュトークンへ向けられているゲートウェイで受信されたとき、ゲートウェイは、当該プッシュトークンと関連付けられているＴＣＰソケット記述子があることを判定するべくルックアップを遂行する。ソケット記述子は、ＴＣＰソケット情報、並びにプッシュ通知を適切なクーリエ５３１（即ち、デバイスが現在接続されるのに経由しているクーリエ）へ伝送するのに必要な他のネットワーキング情報を提供する。

プロバイダは、デバイスを、当該デバイスのプッシュトークン（例えば、例中のデバイスＤ₁を識別しているトークンＴ₁）を使用して識別する。プッシュトークンは、当該ゾーンに責任のあるゲートウェイを間接的に識別するゾーン識別子を保有している（即ち、それぞれのゲートウェイは、特定されたゾーン範囲についての経路指定トラフィックに責任があるため）。図５に示されている例では、デバイスＤ₁と関連付けられているトークンＴ₁は、２つの冗長ゲートウェイであるゲートウェイ５２２及び５２４によって管理されているゾーン５０６を識別する。

したがって、図５に示されている例では、プッシュ通知は、ゲートウェイ５２２又は５２４のどちらかを通してデバイスＤ₁へ伝送されることであろう。本発明の１つの実施形態では、ゲートウェイのそれぞれの間の負荷の均衡を図るためにラウンドロビンスキームが採用されている。代わりに、又は追加して、それぞれのゲートウェイとそれぞれのデバイスの間の通信チャネルの品質を監視し、相対的に高い品質の接続を提供しているゲートウェイが選択されるようにしてもよい。それぞれのゲートウェイ／デバイスチャネルの「品質」を確定するのに様々な異なった測定値が使用できるであろうが、本発明の１つの実施形態では、品質は、それぞれのゲートウェイとそれぞれのデバイスの間の伝送されるパケットについての測定往復時間に基づいている。したがって、図５に指し示されている様に、それぞれのデバイスと関連付けられる現在の往復時間（ＲＴＴ）値が格納されていて、その後、特定のゲートウェイを通る特定の経路を選択するのに使用されている。冗長ゲートウェイ（５２１／５２３及び５２２／５２４）のそれぞれが異なったデータセンターに置かれていることを考えると、選択されるゲートウェイは、デバイスが現在付属しているクーリエと同じデータセンターに所在する傾向がある（とはいうものの、本発明の根底の原理はこの特定の実施形に限定されない）。

１つの実施形態では、プロバイダ５０１のインターフェース５１１は、特定のプッシュ通知を経路指定するのに必要なゲートウェイのそれぞれのネットワークアドレス（例えば、ＩＰアドレス）を識別するために、初めに、ドメインネームサービス（ＤＮＳ）呼び出しを行ってもよい。既に説明されている様に、我々の例でのＴ₁の様なプッシュトークンはゾーンを識別しており、ゾーンは特定のゲートウェイセットを識別している（即ち、我々の例では、ゾーン５０６は冗長ゲートウェイ５２２及び５２４を識別している）。したがって、インターフェース５１１は、初めに、6.gateway.push.apple.com（即ち、アドレスの最初の部分の６はゾーン６を識別している）という形式のＤＮＳ問い合わせを生成する。すると、ＤＮＳサーバが、インターフェース問い合わせに、ゾーン６に責任のあるゲートウェイ５２２及び５２３のそれぞれのＩＰアドレスを返答する。インターフェース５１１は、次いで、プッシュ通知を伝送するためのゲートウェイの１つを選択する。

１つの実施形態では、インターフェース５１１は、特定のゲートウェイを、プッシュが向けられている特定のデバイスについて当該ゲートウェイと関連付けられる現在の往復時間（ＲＴＴ）に基づいて選択する。例えば、ゲートウェイ５２２がゲートウェイ５２４より相対的に短いＲＴＴを有しているなら、インターフェース５１１はゲートウェイ５２２を選択することになる。代わりに、インターフェースが相対的に低いＲＴＴを有するゲートウェイを選択するのではなしに、最も低いＲＴＴを有するゲートウェイのネットワークアドレスが、ＤＮＳ問い合わせに応えてインターフェースへ提供されるようになっていてもよいし、又はネットワークアドレスのセットが優先順位の付けられた順に（最も低いＲＴＴを有するゲートウェイのネットワークアドレスを優先順位の付けられたリストの最上位に配して）インターフェースへ送信されるようになっていてもよい。この実施形態では、様々なＲＴＴ値を引き出して処理するために、ＤＮＳはゲートウェイのそれぞれと一体化されているか又は通信していてもよい。但し、本発明の根底の原理は、経路がゲートウェイを通して選択される特定の方式に限定されないことに留意されたい。本発明の範囲内で、様々な異なった構成が実施可能であり、考えられる。

ＲＴＴ値に基づく経路指定に加え、１つの実施形態では、ラウンドロビンスキームも実施されている（例えば、負荷均衡化のため）。例えば、ゲートウェイのそれぞれと関連付けられるＲＴＴ値が指定された閾値内にある限り、どちらのゲートウェイも実行可能な経路指定選択肢となり得る。その様な事例では、ラウンドロビンスキームの連続の中の次のゲートウェイが選択されることになる。１つの実施形態では、ラウンドロビンスキームは、指定された閾値内のＲＴＴ値を有するそれらのゲートウェイに限定して遂行されている。例えば、８つの異なった実施可能なゲートウェイがあって、但し、ＲＴＴ値が閾値内にあるのは２つだけである場合、ラウンドロビンスキームは当該２つのゲートウェイの間でのみ実施されるということになる。この実施形態は、同じデータセンター内に、同じゾーン又は同じゾーン範囲に責任のあるゲートウェイが複数存在している場合に好都合である。その様な事例では、２つのゲートウェイは比較的似通ったＲＴＴ値を有しているかもしれず、但しこれらのＲＴＴ値は残り６つのゲートウェイ（異なったデータセンターに所在）よりも有意に低いということがある。当然ながら、本発明の根底の原理は、ゲートウェイのデータセンター間での何らかの特定の分配に限定されないことに留意されたい。

１つの実施形態では、ＲＴＴは静的閾値とは比較されない。むしろ、様々なＲＴＴ値間の差が比較され、幾つかが他より特定の閾値差を超えて有意に低い場合には、より低いＲＴＴ値を有するゲートウェイが選択されることになろう。

プッシュ通知を経路指定するための方法の１つの実施形態が図６に示されている。方法は、図５に示されているアーキテクチャとの関連内で実施することができるが、但し、何れかの特定のシステムアーキテクチャに限定されない。

６０１で、プッシュ通知サービスに対してデバイスを識別する（例えば、デバイスが接続されるのに経由している特定のクーリエを識別する）存在情報が特定の移動体デバイスから受信される。上述の様に、１つの実施形態では、デバイスのトークンは、それぞれのゲートウェイをそれぞれのクーリエへ接続しているＴＣＰソケットを識別するソケット記述子と関連付けられており、クーリエ自体はデバイスとの接続を保守している。

６０２で、デバイスのそれぞれとゲートウェイのそれぞれの間の往復時間（ＲＴＴ）が監視される。１つの実施形態では、それぞれのＧＷ／デバイス組合せについてのＲＴＴ値は、ゲートウェイによって管理されている表内で継続的に更新されるが、その様な構成は、本発明の根底の原理に準拠する上で必須ではない。

６０３で、ユーザーが加入している特定のプロバイダによって、プッシュ通知が生成される。例えば、特定の事象がユーザーの好みのチームの１つに関連付けて起こったり、ユーザーのデバイスにインストールされているソフトウェアのニューバージョンが利用可能になったりすることであろう。

６０４で、プッシュ通知を特定のゲートウェイを通して経路指定するべく経路が選定される。前述の様に、経路は、プロバイダが接続されるのに経由しているインターフェースによるＤＮＳ問い合わせに応えて指し示されてもよいし、或いは代わりにインターフェース自身によって作成されてもよい。加えて、（以上に論じられている様に）限定ラウンドロビンスキームがＲＴＴ値と組み合わせて実装されていてもよい。特定の実装とは関係なく、ゲートウェイは、プッシュ通知をデバイスへ効率良く経路指定するように選択されればよい。

［二方向プッシュのためのシステム及び方法］
以上の論考は、プロバイダによって生成されるプッシュ通知が移動体デバイスへ経路指定される一方向の実施形に焦点が当てられた。追加して、本発明の１つの実施形態は、デバイスからプロバイダへのプッシュチャネルを開き、それにより、プロバイダとデバイスの間の双方向プッシュ通信を可能にする。双方向の実施形は、例えば、プロバイダへのフィードバック通知を生成するのに使用することができる（例えば、開封確認メッセージを使用して、ユーザーが読んだとき、確認応答したとき、又はそれ以外にプッシュ通知を実行したときを検知する）。

図７を参照して、１つの実施形態では、プロバイダは、プロバイダが通知に備えて傾聴していることを指し示すために、事前に指定されているＴＣＰポートへのソケット接続をインターフェース７１１を介して開く。図７に示されている例では、このポートは、総称的に「ポートＸ」と呼称されているが、何れの事前指定のポートが使用されてもよい。認証目的で、それぞれのプロバイダには、プロバイダ用のゾーン番号を生成するのに使用することのできる固有証明書が割り当てられている。１つの実施形態では、プロバイダは、自身の証明書をインターフェースへ提供し、するとインターフェースは証明書に対しハッシュ（例えば、ＳＨＡ−１ハッシュ）を遂行して、ゾーン番号、即ち図７に示されている例ではゾーン５１８、を含んでいるプロバイダトークン（デバイストークンに類似）を生成する。このトークン／ゾーン番号は、次いで、移動体デバイス上のアプリケーション（又は他のサービス）によって、プッシュ通知を各プロバイダそれぞれへ伝送するために指定される。

その結果、クーリエがデバイスの存在をゲートウェイと一体に（以上に論じられている様に）登録するのと丁度同じ様に、それぞれのプロバイダは自身の存在をそれのゾーンに責任のあるゲートウェイ内に登録することになる。図７に指し示されている様に、プロバイダの存在データは、プロバイダの割当先ゾーンに責任のあるそれぞれのゲートウェイ上の表に格納される。指し示されている様に、存在情報は、ゲートウェイと各プロバイダそれぞれの間で伝送されるパケットの往復時間（ＲＴＴ）を含んでいてもよい。プロバイダと関連付けられるＲＴＴ値は、上述の様にクーリエについてのＲＴＴ値がゲートウェイを選択するのに使用されているのと丁度同じ様に、今度はゾーンについて冗長ゲートウェイのそれぞれの間で選択するのに使用されることになる。図７に示されてはいないが、ゲートウェイ５２４について示されているのと同じプロバイダ存在及びデバイス存在がゲートウェイ５２２内に格納されていることに留意されたい。

プッシュ通知を特定のプロバイダへ伝送するデバイスは、プロバイダをプロバイダトークンを使って識別しており、プロバイダトークンは当該トークンと関連付けられるゾーンを使用するゲートウェイを識別している。１つの実施形態では、デバイスが初めに接続されているクーリエは、プロバイダのトークンからプロバイダのゾーン番号を抽出し、ゾーン番号を使用して、当該ゾーンに責任のあるゲートウェイのＩＰアドレスを識別するためのＤＮＳ問い合わせ（例えば、518.gateway.push.apple.com、ここに５１８はゾーンを識別している）を生成する。ＤＮＳ機能性は、ゲートウェイと同じハードウェアプラットフォーム内に実装されていてもよいし、別体の専用ハードウェアを使用していてもよい。次いで、複数の冗長ゲートウェイについてのＤＮＳ問い合わせに応えて、複数のＩＰアドレスが返されるであろう。１つの実施形態では、これらのＩＰアドレスは、（以上に論じられている様に）ラウンドロビンスキーム、ＲＴＴ値、又はそれら２つの組合せを使用して優先順位が付けられていてもよい。例えば、ゲートウェイの或るセットが、この特定のプロバイダ用の他のゲートウェイより有意に低い（例えば、指定されている閾値量だけ低い）ＲＴＴ値を有しているなら、このゲートウェイセットに対しラウンドロビンスキームが実施されることになろう。

ゲートウェイがどの様に優先順位を付けられているかに関係なく、選択されたゲートウェイは、プロバイダが接続されているインターフェースについてのソケット記述子データを使用して、プッシュ通知をプロバイダへ伝送する。プロバイダは、次いで、プッシュ通知の内容を読み出し、何らかのアプリケーション特有の方式で応答する。例えば、プッシュ通知が開封確認メッセージであるなら、プロバイダは、開封確認メッセージ中に保有されている情報をユーザーデータベース内に格納してもよい。当然ながら、本発明の根底の原理は、ここに説明されている逆プッシュ機能の何らかの特定の使用に限定されない。また、本発明の根底の原理になお準拠しながらも、同じプロバイダが幾つかの異なったゲートウェイを経由して幾つかの異なったインターフェースへ接続されていることもあろう。

図８は、本発明の１つの実施形態による方法を示している。方法は、図７に示されているアーキテクチャとの関連内で実行することができるが、何らかの特定のアーキテクチャに限定されない。

８０１で、プロバイダは、プッシュ通知サービスへ規定されたポート（例えば、図７に示されている例ではポートＸ）を介して接続し、自身の証明書を提供する。８０２で、証明書のハッシュが遂行されて、プロバイダについてゾーンが識別される。８０３で、プロバイダの存在データ（例えば、ＴＣＰソケットデータ及び現在の状態）が、この特定のゾーンに責任のあるゲートウェイ内に格納される。８０４で、プッシュ通知がデバイスの１つから受信され、ゲートウェイのそれぞれを経由するソケット接続の現在の品質（例えば、１つの実施形態では往復時間によって識別されている）に基づいて特定のゲートウェイを通る経路が選択される。最終的に、８０５で、逆プッシュ通知はプロバイダによって受信され、プロバイダは逆プッシュ通知の受信に対して幾つもの数の事前に指定されているやり方で振る舞う。

本発明の実施形態は、以上に述べられている様々な段階を含んでいる。それら段階は、汎用又は特殊目的のプロセッサに特定の段階を遂行させる機械実行可能命令に具現化されていてもよい。代わりに、これらの段階は、段階を遂行するためのハードウェ論理を保有している特定のハードウェア構成要素によって遂行されてもよいし、又はプログラムされたコンピュータ構成要素及びカスタムハードウェア構成要素の何らかの組合せによって遂行されてもよい。

本発明の要素は、更に、機械実行可能プログラムコードを格納するための機械可読媒体として提供されてもよい。機械可読媒体には、限定するわけではないが、フロッピーディスケット、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、又は電子プログラムコードを格納するのに適した他の型式の媒体／機械可読媒体、が含まれよう。

以上の記述全体を通し、本発明が十分理解されるように、解説を目的に、数多くの特定の詳細事項を述べてきた。とはいえ、本発明はこれらの特定の詳細事項の一部無しに実践され得ることが当業者には自明であろう。例えば、ここに記載されている機能モジュール及び方法は、ソフトウェアとして、又はハードウェアとして、又はそれらの何らかの組合せとして、実装されることが、当業者には容易に理解できよう。また、本発明の実施形態はここでは移動体コンピューティング環境（即ち、移動体デバイス１２０−１２３；６０１−６０３を使用）との関連内で説明されているが、本発明の根底の原理は、移動体コンピューティング実装に限定されない。実際に、一部の実施形態では、例えばデスクトップコンピュータ又はワークステーションコンピュータを含め、何れの型式のクライアント又はピアデータプロセッシングデバイスが使用されてもよい。従って、本発明の範囲及び精神は、以下に続く特許請求の範囲に鑑みて判断されるべきである。

１０２ プロバイダ
１１０ ゲートウェイ
１１２ 経路指定表
１１４ 認証部
１１６ デバイス／クーリエマッピング
１２０ クーリエ
１２２ 逆伝播モジュール
１２４ 接続モジュール
１２６ デバイス情報
１３０ 移動体デバイス
１３２ メモリ
１３４ 送信器
１３６ 受信器
１３８ アプリケーション
１４０ プロセッサ
１４２ 接続モジュール
１４４ 暗号化モジュール
５０１ プロバイダ
５１１ インターフェース
５２１、５２２、５２３、５２４ ゲートウェイ
５３１、５３２ クーリエ
Ｄ₁、Ｄ₂ 移動体デバイス
Ｔ₁、Ｔ₂ トークン

Claims (16)

1. プロバイダと移動体デバイスの間の二方向プッシュ通信を確立するための方法であって、
   第１のプロバイダが１人又はそれ以上のユーザーのセットからのプッシュ通知を受信することを選択したとの指示を受信する処理と、
   第１のユーザーが１つ又はそれ以上のプロバイダのセットからのプッシュ通知を受信することを選択したとの指示を受信する処理と、
   前記第１のユーザー及び前記第１のプロバイダと関連付けられる存在情報であって、当該第１のユーザー及び当該第１のプロバイダが、それぞれ、現在ネットワークに接続されていてプッシュ通知に備えて傾聴しているかどうかを指し示す存在情報を、監視する処理と、
   前記第１のユーザー宛てのプッシュ通知を受信したことに応えて、前記第１のユーザーの現在のネットワーク場所を識別し、前記プッシュ通知を前記第１のユーザーへ転送する処理と、
   前記１人又はそれ以上のユーザーのセットからの前記第１のプロバイダ宛てのプッシュ通知を受信したことに応えて、前記プロバイダがプッシュ通知に備えて傾聴している現在のネットワーク場所を識別し、前記プッシュ通知を前記第１のプロバイダへ転送する処理と、が実行され、
   前記プッシュ通知を前記第１のプロバイダへ転送する処理は、第１のゲートウェイと第２のゲートウェイの間で前記プッシュ通知を伝送するのにどちらを経由するかを選択することを含み、当該選択は、前記第１のプロバイダと第１のゲートウェイの間及び前記第１のプロバイダと第２のゲートウェイの間の伝送されるパケットについてチャネル品質を測定し、及び前記第１のゲートウェイと前記第２のゲートウェイの間で、前記測定されたチャネル品質に基づいて選択することを更に含む、方法。
2. 前記第１のプロバイダが１人又はそれ以上のユーザーのセットからのプッシュ通知を受信することを選択したとの指示を受信する処理は、前記第１のプロバイダが接続されていてプッシュ通知に備えて傾聴している現在のネットワークポートの指示を受信する処理を含む、請求項１に記載の方法。
3. 前記第１のプロバイダ宛ての前記プッシュ通知は、当該プッシュ通知と関連付けられるユーザーが、以前に前記プロバイダによって前記ユーザーへ伝送されているプッシュ通知を読んだことを指し示す開封確認メッセージを含む、請求項１に記載の方法。
4. チャネル品質を測定する処理は、前記第１のプロバイダと第１のゲートウェイの間及び前記第１のプロバイダと第２のゲートウェイの間の伝送されるパケットについて往復時間を監視する処理を含む、請求項１に記載の方法。
5. 前記ゲートウェイで関連付けられる往復時間が相対的に低い方を選択する処理を更に含む、請求項４に記載の方法。
6. 前記第１のプロバイダと前記第１のゲートウェイの間の測定された前記チャネル品質が、前記第１のプロバイダと第２のゲートウェイの間の測定された前記チャネル品質の指定されている閾値量内にあれば、ラウンドロビンスキームを採用して、前記第１のプロバイダへの前記プッシュ通知の伝送について前記第１のゲートウェイと前記第２のゲートウェイの間で選択する、請求項１に記載の方法。
7. それぞれのゲートウェイ上のプロバイダ存在表であって、当該ゲートウェイと各プロバイダそれぞれの間の前記接続と関連付けられる更新されたチャネル品質値を保有しているプロバイダ存在表を、保守する処理を更に含む、請求項１に記載の方法。
8. 前記チャネル品質値は、前記ゲートウェイと前記プロバイダの間の伝送されるパケットの往復時間を含む、請求項７に記載の方法。
9. プログラムコードを格納するためのメモリと、動作を遂行するべく前記プログラムコードを処理するためのプロセッサとを備えたシステムであって、
   第１のプロバイダが１人又はそれ以上のユーザーのセットからのプッシュ通知を受信することを選択したとの指示を受信する動作と、
   第１のユーザーが１つ又はそれ以上のプロバイダのセットからのプッシュ通知を受信することを選択したとの指示を受信する動作と、
   前記第１のユーザー及び前記第１のプロバイダと関連付けられる存在情報であって、当該第１のユーザー及び当該第１のプロバイダが、それぞれ、現在ネットワークに接続されていてプッシュ通知に備えて傾聴しているかどうかを指し示す存在情報を、監視する動作と、
   前記第１のユーザー宛てのプッシュ通知を受信したことに応えて、前記第１のユーザーの現在のネットワーク場所を識別し、前記プッシュ通知を前記第１のユーザーへ転送する動作と、
   前記１人又はそれ以上のユーザーのセットからの前記第１のプロバイダ宛てのプッシュ通知を受信したことに応えて、前記プロバイダがプッシュ通知に備えて傾聴している現在のネットワーク場所を識別し、前記プッシュ通知を前記第１のプロバイダへ転送する動作と、
   を遂行するべくプログラムコードであって、
   前記プッシュ通知を前記第１のプロバイダへ転送する動作は、第１のゲートウェイと第２のゲートウェイの間で前記プッシュ通知を伝送するのにどちらを経由するかを選択することを含み、当該選択は、前記第１のプロバイダと第１のゲートウェイの間及び前記第１のプロバイダと第２のゲートウェイの間の伝送されるパケットについてチャネル品質を測定し、及び前記第１のゲートウェイと前記第２のゲートウェイの間で、前記測定されたチャネル品質に基づいて選択することを更に含む前記プログラムコードを処理するためのプロセッサを有しているシステム。
10. 前記第１のプロバイダが１人又はそれ以上のユーザーのセットからのプッシュ通知を受信することを選択したとの指示を受信する動作は、前記第１のプロバイダが接続されていてプッシュ通知に備えて傾聴している現在のネットワークポートの指示を受信する動作を含む、請求項９に記載のシステム。
11. 前記第１のプロバイダ宛ての前記プッシュ通知は、当該プッシュ通知と関連付けられるユーザーが、以前に前記プロバイダによって前記ユーザーへ伝送されているプッシュ通知を読んだことを指し示す開封確認メッセージを含む、請求項１０に記載のシステム。
12. チャネル品質を測定する動作は、前記第１のプロバイダと第１のゲートウェイの間及び前記第１のプロバイダと第２のゲートウェイの間の伝送されるパケットについて往復時間を監視する動作を含む、請求項９に記載のシステム。
13. 前記プロセッサに、追加の動作、即ち、
    前記ゲートウェイで関連付けられる往復時間が相対的に低い方を選択する動作を遂行させる追加のプログラムコードを含む、請求項１２に記載のシステム。
14. 前記第１のプロバイダと前記第１のゲートウェイの間の測定された前記チャネル品質が、前記第１のプロバイダと第２のゲートウェイの間の測定された前記チャネル品質の指定されている閾値量内にあれば、ラウンドロビンスキームを採用して、前記第１のプロバイダへの前記プッシュ通知の伝送について前記第１のゲートウェイと前記第２のゲートウェイの間で選択する、請求項９に記載のシステム。
15. 前記プロセッサに、追加の動作、即ち、
    それぞれのゲートウェイ上のプロバイダ存在表であって、当該ゲートウェイと各プロバイダそれぞれの間の前記接続と関連付けられる更新されたチャネル品質値を保有しているプロバイダ存在表の保守動作を遂行させる追加のプログラムコードを含む、請求項１１に記載のシステム。
16. 前記チャネル品質値は、前記ゲートウェイと前記プロバイダの間の伝送されるパケットの往復時間を含む、請求項１５に記載のシステム。

Images