JP5719453B2 - マルチユーザ装置のためのメッセージプッシュ通知クライアントの改良 - Google Patents

Description

本発明は、一般的に、データ処理システムに関する。より詳細には、本発明は、マルチユーザ装置のための通知メッセージに関する。

本出願人は、２０１１年１月５日に出願された同時係争中のプロビジョナル米国特許出願第６１／４３０，１２６号の優先権の利益を主張し、その全体が参考としてここに援用される。

マルチユーザ装置（例えば、ラップトップ、パルムトップ、移動電話、スマートホン、マルチメディアホン、ポータブルメディアプレーヤ、ＧＰＳユニット、移動ゲームシステム、等）のユーザは、通知サービスから通知メッセージを定期的に受信するアプリケーションをインストールしている。例えば、そのようなアプリケーションは、「プッシュ」ｅ−メールサービス（例えば、ＭｏｂｉｌｅＭｅ、ＭｉｃｒｏｓｏｆｔＥｘｃｈａｎｇｅＡｃｔｉｖｅＳｙｎｃ、ｐｕｓｈ−ＩＭＡＰ、Ｙａｈｏｏ！Ｐｕｓｈ、等）又は他のプッシュサービス（例えば、アップデート／アップグレードサービス、ニュースサービス、ウェブログサービス、ポッドキャストサービス、ソーシャルネットワーキングサービス、又は通知メッセージが送信される他の形式のサービス）を含む。通知メッセージは、典型的に、アプリケーションにより典型的に定義される当該イベント（例えば、新規なｅ−メールインジケータ、新規なニュースアイテムインジケータ、新規なポッドキャストインジケータ、ソーシャルネットワーキングフレンドのオンライン状態の変化、等）を表わす。

通常、通知メッセージは、それに対応する発信サーバー及び受信クライアント装置を識別することによりプッシュサービスを通してルーティングされる。通知メッセージを受信すると、クライアント装置は、特定のユーザのターゲットクライアントアプリケーションへメッセージを配送する。多くの場合に、クライアント装置の１人以上のユーザのための複数のクライアントアプリケーションは、同時に同じ発信サーバーからの通知メッセージを待機する。待機中の各クライアントアプリケーションは、通知メッセージが到着したときに呼び出される。クライアント装置の絶えず増加する数のクライアントアプリケーションをサポートするために発信サーバーに益々多くのサーバーアプリケーションがホストされるにつれて、クライアント装置の貴重な処理リソースが、メッセージ通知の管理のために浪費される。

従って、マルチユーザ装置のメッセージ通知を与える既存のメカニズムは、リソースに負担を掛け、所与のマルチユーザ装置の多数のユーザを考慮せず、及び／又は他の問題を引き起こすことがある。

本発明は、クライアントマルチユーザ装置に通知メッセージを効率的に配送してリソース使用を最小にするために個々のクライアントアプリケーション及び複数のユーザにアドレスすることのできる多レベルのネーミングハイアラーキーを提供することができる。サーバー識別子又はトピックにより識別される共通サーバーにホストされる複数のサーバーアプリケーションは、同じトピックを共有する通知メッセージをクライアント装置へプッシュすることができる。トピックに契約するターゲットクライアントアプリケーションを識別するためにクライアント装置のトピックに対して受信される通知メッセージにサブトピックを埋め込むことができる。

１つの実施形態において、クライアントアプリケーションは、トピックにより識別されるサーバーにおいて実行される対応するサーバーアプリケーションにクライアントアプリケーション識別子をサブトピックとして任意に登録することができる。サブトピックは、クライアントアプリケーションに対する付加的なレベルのネーミングハイアラーキーである。その結果、サーバーにホストされたサーバーアプリケーションからプッシュされる通知メッセージは、トークン及びクライアントアプリケーション識別子を保持し、共有トピックに契約する他のクライアントアプリケーション又は他のユーザを呼び出したりそれに通知したりせずに通知メッセージをクライアントアプリケーションへ直接的にルーティングできるようにする。通知サーバーは、トークンを使用して、メッセージを適当なユーザアカウントへルーティングすることができる。トピックの１つのサーバーによりホストされる個別のサーバーアプリケーションからの複数の通知メッセージは、クライアント装置において同じトピックを有効に且つ効率的に聴取する同じ又は異なるユーザに対して行先である個別のクライアントアプリケーションへマルチプレクスして、受信した通知メッセージを取り扱うのに必要なクライアント装置のリソース使用を最小にすることができる。

１つの実施形態では、マルチユーザクライアント装置内のクライアントアプリケーションを識別するサブトピック識別子を発生するための方法及び装置がここに説明される。クライアントアプリケーションは、１つ以上のアプリケーションサーバーにホストされたサーバーアプリケーションに関連している。クライアントアプリケーションは、クライアントアプリケーションに関連した識別子を転送するために通知サービスをアプリケーションサーバーに登録し、そしてサーバーアプリケーションがクライアントアプリケーションに対して選択的にそのユーザのためのクライアント装置に通知メッセージをプッシュできるようにする。アプリケーションサーバーから通知メッセージを受信するときに、通知メッセージは、その通知メッセージがクライアントアプリケーションのサブトピック識別子を保持する場合に、クライアント装置における他のアプリケーションを呼び出すことなく、クライアントアプリケーションへ直接転送すべきか調査又は検査される。

別の実施形態では、メッセージ通知の登録要求は、クライアント装置で実行されるクライアントアプリケーションから第１のネットワーク接続を経てサーバーアプリケーションにより受け取られる。第１のネットワーク接続は、サーバーアプリケーションをホストするためにサーバー識別子でクライアント装置からアプリケーションサーバーへ最初に確立される。要求は、ユーザ及びクライアント装置を識別するユーザトークンと、クライアントアプリケーションを識別するクライアントアプリケーション識別子とを含む識別子を保持する。サーバー識別子は、クライアント装置がアプリケーションサーバーからプッシュされたメッセージを聴取できるようにクライアント装置へ送信される。１つの実施形態では、要求で保持される識別子は、メッセージ通知についてユーザを登録するために記憶される。アプリケーションサーバーは、クライアントアプリケーションに通知するためにユーザトークンによりクライアント装置に結合されたプッシュネットワークへの第２のネットワーク接続を経てクライアント装置へ通知メッセージを送信又はプッシュする。通知メッセージは、サーバー識別子により識別される。任意であるが、通知メッセージは、クライアント装置が通知メッセージをクライアントアプリケーションへ直接配送できるようにするためにクライアントアプリケーション識別子を保持する。

本発明の他の特徴は、添付図面及び以下の詳細な説明から明らかとなろう。本発明は、同様の要素が同じ参照番号で示された添付図面に一例として示すが、これに限定されるものではない。

メッセージ通知のためのネットワークシステムの１つの実施形態を示すブロック図である。 マルチユーザ装置のユーザアカウントでユーザを識別するのに使用されるエイリアスを含むユーザトークンのブロック図である。 ここに述べる実施形態により通知メッセージを管理するためのマルチユーザ装置の規範的コンポーネントを示すブロック図である。 通知メッセージを与えるためのアプリケーションサーバーの規範的コンポーネントを示すブロック図である。 ここに述べる実施形態によるマルチユーザ装置とアプリケーションサーバーとの間の規範的なメッセージ交換を示すシーケンス図である。 マルチユーザ装置が通知メッセージを識別されたクライアントアプリケーションへルーティングできるようにするためのプロセスの一実施形態を示すフローチャートである。 通知メッセージをユーザトークンに関連したユーザの識別されたクライアントアプリケーションへルーティングするのに使用されるユーザトークンを発生するためのプロセスの一実施形態を示すフローチャートである。 アプリケーションサーバーからアプリケーションクライアントへ通知メッセージを与えるためのプロセスの一実施形態を示すフローチャートである。 ここに述べる実施形態に使用されるデータ処理システムの一例を示す。 ここに述べる実施形態に関連して使用される典型的なコンピュータシステムの一例を示す。

共通のアプリケーションサーバーを聴取するか又はそれに契約することによりマルチユーザ装置の複数のユーザに関連した複数のクライアントアプリケーションの中でターゲットクライアントアプリケーションを識別する通知メッセージのための方法及び装置をここに説明する。以下の記述において、本発明の実施形態を完全に説明するために多数の細部について述べる。しかしながら、当業者であれば、本発明の実施形態は、それらの特定の細部がなくても実施できることが明らかであろう。他の点については、本発明の実施形態を不明瞭にしないために、良く知られた構造及び装置は、詳細に示さず、ブロック図形態で示す。

本明細書において、「１つの実施形態」又は「一実施形態」を言及するときは、その実施形態に関連して述べる特定の特徴、構造又は特性が本発明の少なくとも１つの実施形態に含まれることを意味する。本明細書の種々の場所で「１つの実施形態において」という句が現れたときは、必ずしも、全てが同じ実施形態を指していない。

特に指示のない限り、この説明全体を通して、「処理」又は「コンピューティング」又は「計算」又は「決定」又は「表示」、等の用語を使用する説明は、コンピュータシステムのレジスタ及びメモリ内で物理的（電子的）量として表されたデータを操作し、そしてコンピュータシステムのメモリ又はレジスタ或いは他のそのような情報記憶、伝達又は表示装置内で物理的量として同様に表される他のデータへと変換するデータ処理システム又は同様の電子的コンピューティング装置のアクション及び処理を参照するものである。

ここに述べるアルゴリズム及びディスプレイは、特定のコンピュータ又は他の装置に固有に関係していない。種々の汎用システムを、ここに述べる技術に基づくプログラムと共に使用してもよいし、又は必要なマシン実施方法オペレーションを遂行するように更に特殊な装置を構成するのが便利であると分かっている。種々のこれらシステムに要求される構造は、以下の説明から明らかとなろう。更に、本発明の実施形態は、特定のプログラミング言語を参照して説明しない。ここに述べる本発明の実施形態の教示を具現化するのに種々のプログラミング言語を使用できることが明らかであろう。

本発明の実施形態は、方法として具現化されるか、又はデータ処理システムにより実行されたときにそのシステムが方法を遂行するようにさせる実行可能なインストラクションを記憶するマシン読み取り可能な非一時的記憶媒体として具現化される。データ処理システムのような装置も、本発明の実施形態である。本発明の他の特徴は、添付図面及び以下の詳細な説明から明らかとなろう。

本発明の少なくとも幾つかの実施形態は、ポータブル音楽及び／又はビデオメディアプレーヤのようなデジタルメディアプレーヤの一部分で、これは、メディアを提示するためのメディア処理システムや、メディアを記憶するための記憶装置を含むと共に、アンテナシステム及びメディア処理システムに結合された高周波（ＲＦ）トランシーバ（例えば、セルラー電話のためのＲＦトランシーバ）も含む。ある実施形態では、リモート記憶装置に記憶されたメディアは、ＲＦトランシーバを経てメディアプレーヤに送信される。メディアは、例えば、音楽又は他のオーディオ、静止画又は動画の１つ以上を含む。

ポータブルメディアプレーヤは、タッチスクリーン入力装置、プッシュボタン装置、可動ポインティング入力装置、又は他の入力装置のようなメディア選択装置を含む。メディア選択装置は、記憶装置及び／又はリモート記憶装置に記憶されたメディアを選択するのに使用される。ポータブルメディアプレーヤは、少なくとも幾つかの実施形態では、入力装置を通して選択されて、スピーカ又はイヤホンを通して、又はディスプレイ装置に、或いはディスプレイ装置及びスピーカ又はイヤホンの両方に提示されるメディアのタイトル又は他の指示子を表示するためにメディア処理システムに結合されたディスプレイ装置を含む。

ここに述べる本発明の実施形態は、例えば、娯楽システム又はパーソナルデジタルアシスタント（ＰＤＡ）、又は汎用コンピュータシステム、又は特殊目的コンピュータシステム、又は別の装置内に埋め込まれた装置、又はメディアプレーヤを含まないセルラー電話、又はそれら装置の観点又は機能を合成する装置（例えば、１つのポータブル装置においてＰＤＡ、娯楽システム及びセルラー電話と合成されたｉＰｏｄ（登録商標）のようなメディアプレーヤ）、或いはマルチタッチハンドヘルド装置のようなマルチタッチ入力装置又はマルチタッチ入力装置を伴うセルラーホン及びハンドヘルドコンピュータを含む装置又は消費差向け電子製品、のような他の形式のデータ処理システムの一部分である。

１つの実施形態では、メールサーバー、ＩＭＡＰ（インターネットアクセスメッセージプロトコル）サーバー、カレンダーサーバー、連絡先サーバー、装置管理サーバー、又は他の適用可能なサーバーアプリケーション、のようなサーバーアプリケーションをホストするサーバーは、クライアント装置へ通知を通信するためにサービス当局（例えば、アップル・インク）からプッシュプロバイダー証明書を要求することによりプッシュ能力を維持することができる。クライアント装置において複数のユーザの１人に対応して実行されるクライアントアプリケーションは、クライアント装置からアプリケーションサーバーへ確立された接続を経て対応サーバーアプリケーションをホストするアプリケーションサーバーの能力を問合せる。問合せの結果、アプリケーションサーバーがプッシュサービスを知っているか又はプッシュサービスを提供できることが示されると、クライアントアプリケーションは、サーバーアプリケーションにそれ自身を識別するためにプッシュサービスコマンドを送信することができる。

特に、クライアント装置で実行されるクライアントアプリケーションは、プッシュサービスコマンドにより、ユーザ及びクライアント装置のユーザトークンをサーバーアプリケーションへ提示して、サーバーアプリケーションをホストするサーバーがメッセージ又は通知をクライアント装置の適当なユーザアカウントにプッシュできるようにする。プッシュサービスコマンドに応答して、サーバーアプリケーションは、サーバーからプッシュされたメッセージを受け取るためにクライアント装置が聴いたり見たりできる通知トピック又はサーバーの識別子を識別することができる。

ある実施形態では、クライアントアプリケーションからサーバーアプリケーションへのプッシュサービスコマンドは、対応するアプリケーションのプッシュプロトコルに対するバージョン番号、アカウント識別子、サーバー（例えば、サーバーアプリケーションを実行する）がクライアントアプリケーションをホストする対応するユーザのためのクライアント装置に連絡できるようにするユーザトークン、及び／又はクライアントアプリケーションを識別するサブトピック識別子、のような名前付き値ペア(named value pairs)を含む。アカウント識別子及び／又はサブトピック識別子は、プッシュサービス（又はプッシュサーバー）へ通すべくサーバーに対して不透明のままである。クライアントアプリケーションのためのクライアント装置への通知メッセージは、アカウント識別子及びサブトピック識別子に沿って保持される。

１つの実施形態において、サービスアプリケーションからクライアントアプリケーションへのプッシュサービスコマンドに対する応答は、プッシュプロトコルのバージョン番号及びサーバーアプリケーションをホストするサーバーに関連したトピック識別子を含む名前付き値を含むことができる。トピック識別子は、クライアントアプリケーションを実行しているクライアント装置のユーザに対するユーザアカウントにサーバーが通知メッセージをプッシュできるようにするためにサーバーに対するプロバイダー証明書を登録するのに使用される。ある実施形態では、クライアント装置及びサーバーは、例えば、プッシュサービスコマンド／応答を経てハンドシェーク交換を遂行し、サーバーアプリケーションからクライアントアプリケーションへのメッセージ通知に対するプッシュプロトコルのバージョンをネゴシエーションする（例えば、サーバー及びクライアントの両アプリケーションに対する最高サポートバージョンを識別する）。

１つの実施形態によれば、クライアントアプリケーションのサブトピックは、アプリケーションサーバーに関連したトピックのトップに１つ以上の付加的な間接レベルを与える。例えば、サブトピックは、クライアントアプリケーションをターゲットとする通知メッセージを指令する。クライアントアプリケーションは、トピック及びサブトピック対について登録する。或いは又、クライアントアプリケーション及びアプリケーションサーバーは、サブトピックベースのメカニズムを経て緊密に結合されない。複数の（クライアント）アプリケーションは、トピックにおける共通のサブトピックに対して登録することができる。更に、クライアントアプリケーションは、１人以上のユーザについてサブトピックを登録することができる。

サブトピックは、登録のためにクライアントアプリケーションからサーバーアプリケーションへ転送される。ある実施形態では、名前付けハイアラーキーのサブトピック又は他のレベルが、クライアントアプリケーションによりサブトピックを転送する必要なく、サーバーアプリケーションに対するクライアントアプリケーションについて登録される。

説明上、１つの実施形態によれば、連絡先アプリケーション、カレンダーアプリケーション、及びワードアプリケーションは、アプリケーションのオフィススイートに属する。連絡先アプリケーションは、１人以上のユーザに対する一般的なトピック「オフィス」のもとでサブトピック「連絡先」を登録する。カレンダーアプリケーションは、連絡先アプリケーションに関しては、厳密に同じサブトピック（即ち「連絡先」）及びトピックペア（即ち「連絡先」及び「オフィス」）について登録するように選択を行い、良好な、より最新の使用経験を与え、例えば、誕生日を追加する。しかしながら、ワードアプリケーションは、サブトピック「連絡先」について登録を行わずに一般的なトピック「オフィス」のもとで登録を行う。従って、サブトピックでの登録は、特定のアプリケーションについて（又はそれをターゲットとして）必ずしも１対１のマッピングを実施しない。サーバーは、サブトピック情報を知るか又はクライアントと共有する必要がない。例えば、サーバーは、連絡先データの変更を特定のサブトピック、例えば、「連絡先」に関連付け、そしてプッシュプロトコルに対するサブトピックを固有のメカニズムとして使用する。

別の例として、連絡先アプリケーションは、マルチユーザ装置の各ユーザの個別のインスタンスに対する通知について登録を行う。この例では、連絡先アプリケーションは、マルチユーザ装置のユーザ１、ユーザ２、・・・ユーザＮについて個別の通知要求を登録する。このため、ユーザ１は、連絡先アプリケーションのユーザ１のユーザの通知を得ることを希望するが、ユーザ２、・・・ユーザＮに関連した連絡先アプリケーションに対する通知は希望しない。

図１Ａは、メッセージ通知のためのネットワークシステムの一実施形態を示すブロック図である。ネットワークシステム１００は、ネットワーク１０７を経てマルチユーザ装置１０９のような１つ以上の装置（例えば、パーソナルコンピュータ、ラップトップ、テーブル、スマートホン、ゲーム装置、等）に結合されたアプリケーションサーバー１０１のような１つ以上のサーバー（又はホスト）、ブリッジ１１９、通知サーバー１０５、例えば、ＡＰＮサーバーを備えている。１つの実施形態において、ネットワーク１０７は、オープンインターネット、イントラネット、ファイアウオール保護安全ネットワーク、ワイドエリアセルラーネットワーク（例えば、３Ｇネットワーク）、等を経て、通知サーバー１０５、マルチユーザ装置１０９、及び／又はアプリケーションサーバー１０１間をネットワーク接続できるようにする（例えば、プッシュ通知を送信するために）。ネットワーク１０７は、ワイヤード、ワイヤレス（Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、等）、又はその両方の組み合わせである。

１つの実施形態によれば、アプリケーションサーバー１０１は、１つの単一のサーバー装置を含むか、或いはローカル又はリモート分散サーバー装置のクラスターを含む。アプリケーションサーバー１０１は、マルチユーザ装置１０９のようなクライアント装置で実行される対応するクライアントアプリケーションにサービスするサーバーアプリケーション１１７のような１つ以上の個別のサーバーアプリケーションをホストする。サーバーアプリケーションは、メールサーバー、カレンダーサーバー、連絡先サーバー、装置管理サーバー又は他の適用可能なサーバーアプリケーションを含む。１つの実施形態では、アプリケーションサーバー１０１は、マルチユーザ装置１０９へ通知メッセージをプッシュ又は送信するために通知サーバー１０５からの証明書を登録する。登録は、トピック１０３を、アプリケーションサーバー１０１を識別する識別子（例えば、登録された証明書に含まれた）として指定する。マルチユーザ装置１０９は、マルチユーザ装置１０９にアカウントをもつ１人以上のユーザに対して通知サーバー１０５により与えられるアップル・インクからのＡＰＮサービスのようなプッシュサービスを経てアプリケーションサーバー１０１から発信するメッセージについてトピック１０３を聴取する。

１つの実施形態において、アプリケーションサーバー１０１は、ブリッジ１１９を通してプッシュ通知を送信する。１つの実施形態において、ブリッジ１１９は、プッシュ通知を１つのフォーマットから別のフォーマットに変換するのに使用される。この実施形態では、ブリッジ１１９は、通知サーバー１０５からプッシュ通知要求を受け取り、そしてそのプッシュ通知要求を、アプリケーションサーバー１０１が満足できるプロトコルへ変換することにより、マルチユーザクライアント１０９のプロキシーとして働く。更に、アプリケーションサーバー１０１は、アプリケーションサーバーにより使用されるネーティブプロトコルにおいてマルチユーザクライアント１０９に向けられるプッシュ通知を送信する。ブリッジ１１９は、このプッシュ通知を受け取り、そしてその通知を、マルチユーザクレイムに適したフォーマットへ変換する（例えば、アップルプッシュ通知（ＡＰＮ）サービス、等）。例えば、１つの実施形態では、アプリケーションサーバー１０１は、プッシュ通知要求を受け取り、そして拡張性メッセージング及び存在プロトコル（ＸＭＰＰ）を使用してプッシュ通知を送信し、又、マルチユーザクライアント１０９は、異なるプロトコル（例えば、ＡＰＮプロトコル、等）を使用してプッシュ通知（プッシュ通知要求）を受信（送信）する。

１つの実施形態において、ブリッジ１１９は、アプリケーションサーバー１０１からのプッシュ通知に契約するマルチユーザクライアント及び／又はシングルユーザクライアントからのユーザのリストを維持する。この実施形態では、アプリケーションサーバー１０１は、ブリッジ１１９が１人以上のユーザであるかのようにブリッジ１１９と相互作用する。次いで、ブリッジ１１９は、ユーザのためのプッシュ通知を満足するためにマルチユーザ装置１０９及び／又はシングルユーザクライアントの対応ユーザアカウントと相互作用する。

１つの実施形態では、マルチユーザ装置１０９は、１つ以上のユーザアカウント１１４Ａ−Ｂをホストする。１つの実施形態では、マルチユーザ装置１０９は、２つのユーザアカウントと共に示されているが、別の実施形態では、マルチユーザ装置１０９は、ユーザアカウントがそれより少なくても多くてもよい。１つの実施形態では、ユーザは、マルチユーザ装置１０９を使用する個人である。ユーザは、ユーザアカウントでマルチユーザ装置１０９を使用することができる。１つの実施形態では、ユーザアカウントは、そのユーザに対してマルチユーザ装置１０９をカスタマイズするのに使用される。例えば、１つの実施形態では、ユーザは、ユーザアカウントを使用して、ユーザのファイルシステム環境、デスクトップ、アプリケーション、等に対して特定の設定を生成する。この実施形態では、ユーザは、ユーザアカウントを使用して、そのユーザによる特定の使用についてアプリケーションを設定する。例えば、１つの実施形態において、ユーザ１は、ユーザ１がユーザ１のｅ−メールは見るが、他のユーザのものは見ないように、メールアプリケーションを設定する。

別の実施形態では、マルチユーザクライアント１０９が使用する同じプロトコルで通信するアプリケーションサーバー１０１について、アプリケーションサーバー１０１は、ブリッジ１１９を通らずに、プッシュ通知を通信する。

１つの実施形態において、マルチユーザ装置１０９は、アプリケーション１１１Ａ−Ｂを含む複数のクライアントアプリケーションをホストすることができる。１つの実施形態では、各ユーザ１１１４Ａ−Ｂは、通知サーバー１０５と共に使用できる１つ以上のアプリケーション１１１Ａ−Ｂに関連している。クライアントアプリケーションとは、それに対応するサーバーアプリケーションによりサービスされるメールアプリケーション、カレンダーアプリケーション、連絡先アプリケーション、装置管理アプリケーション、又は他の適用可能なクライアントアプリケーションである。マルチユーザ装置１０９は、例えば、通知サーバー１０５を経てプッシュサービスに登録し、マルチユーザ装置１０９がアプリケーションサーバー１０１のようなサーバーからプッシュサービスを経てプッシュされたメッセージを受信できるようにするための装置トークン１１５を得る。装置トークン１１５は、プッシュサービスを経て通知メッセージをルーティングするためにマルチユーザ装置１０９を識別し及び／又は承認する。更に、サブトピック１１３Ａ−Ｂは、マルチユーザ装置１０９のユーザアカウント１１４Ａ−Ｂインスタンスごとに発生され、装置における異なるクライアントアプリケーション及び／又はユーザの中でアプリケーション１１１Ａ−Ｂを独特に識別する。更に、マルチユーザ装置１０９は、各ユーザ１１６Ａ−Ｂに対してユーザトークン１１４Ａ−Ｂを各々要求する。１つの実施形態では、ユーザトークン１１４Ａ−Ｂは、プッシュ通知に対してユーザ１１６Ａ−Ｂを独特に識別するのに使用される。

１つの実施形態において、アプリケーション１１１Ａ−Ｂは、各ユーザトークン１１４Ａ−Ｂ及びサブトピック１１３Ａ−Ｂをアプリケーションサーバー１０１のための対応するサーバーアプリケーション１１７へ転送し、通知メッセージをマルチユーザ装置１０９へプッシュする。次いで、アプリケーションサーバー１０１は、アプリケーションサーバー１０１からプッシュされた通知メッセージを受信するためにマルチユーザ装置１０９が聴取すべきトピック１０３で応答する。通知メッセージは、他のクライアントアプリケーションを呼び出したり装置の他のユーザアカウントに通知したりせずにサブトピック１１３Ａ−Ｂ及び／又はユーザトークン１１４Ａ−Ｂによって識別されたユーザ１１６Ａ−Ｂ及びアプリケーション１１１Ａ−Ｂの組み合わせへマルチユーザ装置１０９がメッセージを直接配送できるようにするためにサブトークン１１３Ａ−Ｂ及び／又はユーザトークン１１４Ａ−Ｂを埋め込む。

図１Ｂは、マルチユーザ装置のユーザアカウントでユーザを識別するのに使用されるエイリアスを含むユーザトークン１１４Ａのブロック図である。図１Ｂにおいて、ユーザトークン１１４Ａは、装置識別子１３０と、ゾーン情報１３４と、エイリアス１３６と、パッディングデータ１３８とを含む。装置識別子１３０は、マルチユーザ装置１０９を識別するのに使用される、この技術で知られた識別子である。装置識別子１３０をユーザトークン１１４Ａに含ませることにより、ユーザ１１６Ａは、マルチユーザ装置１０９に関連付けられる。１つの実施形態において、装置識別子１３４は、装置トークン１１５に使用される同じ識別子である。装置識別子は、装置証明書、ハードウェア識別子、この技術で知られた他の装置識別データ、及び／又はその組み合わせ、等である。

１つの実施形態において、ゾーン情報１３４は、ユーザ１１６Ａを通知システムの特定のゾーンに関連付ける識別子である。１つの実施形態において、ゾーンは、通知システムの区分であり、通知システムは、１つ以上のゾーンで形成され、そして同じゾーン内の各通知クライアント（例えば、マルチユーザ装置１０９、他の通知クライアント、等）は、そのゾーンの１つ以上の通知サーバーにより取り扱われる。１つの実施形態において、通知サーバー１０５は、ゾーン情報を使用して、そのゾーンを取り扱う適当な通知サーバーにプッシュ通知を転送する。例えば、１つの実施形態において、通知サーバー１０５がゾーン１のプッシュ通知を処理し、そしてこの通知サーバーがアプリケーションサーバー１０９からゾーン２のプッシュ通知を受け取る場合に、通知サーバー１０５は、ゾーン２のプッシュ通知を取り扱う別の通知サーバー（図示せず）へこのプッシュ通知を転送する。

更に、ユーザトークン１１６Ａは、エイリアス１３６を含む。１つの実施形態において、エイリアス１３６は、マルチユーザ装置のユーザを識別するのに使用される。この実施形態では、ユーザごとに独特のエイリアスがあり、そしてそれに対応するユーザアカウントがマルチユーザマシン１０９に存在する。例えば、１つの実施形態において、マルチユーザ装置では、２つのユーザアカウントがある場合に、２人のユーザの各々に対して独特のエイリアスがある。エイリアス１３６は、ランダム数、ユーザ証明書から導出された列挙された数、等である。１つの実施形態では、エイリアス１３６は、ユーザトークン１１６Ａにおける４バイトフィールドである。１つの実施形態では、エイリアス１３６は、ユーザアカウントを表わすのに使用される装置のエイリアスであり、そしてプッシュ通知の装置識別子に代わるユーザである。

更に、ユーザトークン１１６Ａは、パッディングデータ１３８を含む。１つの実施形態では、パッディングデータ１３６は、トークン１１６Ａの使用にとって重要でないデータで、トークン１１６Ａ内のスペースを埋め、及び／又はトークン１１６Ａ内のスペースを将来の使用のために予約するのに使用される。

図２は、ここに述べる実施形態により通知メッセージを管理するためのマルチユーザ装置１０９の規範的コンポーネントを示すブロック図である。例えば、マルチユーザ装置１０９は、複数のユーザ１１６Ａ−Ｂに対して図１Ａのネットワークシステム１００を経てプッシュサービスについて登録する。１つの実施形態では、通知管理モジュール２０１は、マルチユーザ装置１０９内にプッシュサービスのためのフレームワークを与える。通知管理モジュール２０１は、サービス（例えば、プッシュサービス）接続プロセス中に装置トークン１１５を受け取り、プッシュサービスを経てプッシュされた通知メッセージを受け取ることが証明され又は信頼されたものとしてマルチユーザ装置１０９を識別する。更に、通知管理モジュール２０１は、サービス（例えば、プッシュサービス）接続プロセス中にユーザトークン１１４Ａ−Ｂを受け取り、プッシュサービスを経てプッシュされた通知メッセージを受け取ることが証明され又は信頼されたものとしてユーザ１１６Ａ−Ｂを各々識別する。１つの実施形態では、通知管理モジュール２０１は、プッシュサービスからプッシュされたメッセージがマルチユーザ装置１０９のユーザ１１６Ａ−Ｂに向けられるかどうかを、メッセージがユーザトークン１１４Ａ−Ｂに一致するか又はそれを含むかに基づいて決定する。

１つの実施形態によれば、通知管理モジュール２０１は、例えば、アプリケーション１１１Ａ−Ｂからの要求に応答して、１つ以上のサブトピック１１３Ａ−Ｂを、マルチユーザ装置１０９内のアプリケーション１１１Ａ−Ｂを識別するクライアントアプリケーション識別子として発生する。アプリケーション１１１Ａ−Ｂは、図１のサーバーアプリケーション１１７のような対応するサーバーアプリケーションからのメッセージ通知を受信するために、サブトピック１１３Ａ−Ｂ及びそれに対応するユーザトークン１１４Ａ−Ｂを登録のために転送する。１つの実施形態では、アプリケーション１１１Ａ−Ｂは、通知管理モジュール２０１を経て、図１のトピック１０３のようなトピックに契約し又はそれを聴取する。マルチユーザ装置１０９の２つ以上のアプリケーション１１１Ａ−Ｂは、共通のトピックを登録し又はそれに契約する。更に、マルチユーザ装置１０９の異なるユーザ１１４Ａ−Ｂにより使用されるアプリケーション１１１Ａ−Ｂは、共通のトピックを登録し又はそれに契約する。通知管理モジュール２０１は、どのトピックがどのアプリケーション及びどのユーザにより現在契約されているか指示するトピック契約データを契約プロフィール２０３に記憶する。１つの実施形態では、通知管理モジュール２０１は、各ユーザトークン１１６Ａ−Ｂに対して異なる契約プロフィール３０２を有する。この実施形態では、マルチユーザ装置１０９は、異なる契約プロフィールを、そのユーザトークン１１６Ａ−Ｂに対応するユーザ１１４Ａ−Ｂに各々関連付ける。

プッシュサービスを経てプッシュされた通知メッセージを受け取ると、通知管理モジュール２０１は、到着する通知メッセージからトークンを抽出して、その通知メッセージがマルチユーザ装置１０９に向けられたものであるかどうか、例えば、トークンとユーザトークン１１６Ａ又は１１６Ｂとの間の一致に基づいて、決定することができる。通知管理モジュール２０１は、受け取った通知メッセージからトピックを識別し、契約プロフィール２０３に基づいて、その受け取った通知メッセージでどのクライアントアプリケーション及びどのユーザアカウントを通知すべきか識別する。任意であるが、通知管理モジュール２０１は、これもその受け取った通知メッセージに含まれたトピックに契約している他のアプリケーションを呼び出したり又は通知したりすることなく、サブトピック１１３Ａ−Ｂにより識別されるアプリケーション１１１Ａ−Ｂのようなサブトピックストリングにより識別されたクライアントアプリケーションにその受け取った通知メッセージを直接配送するために、その受け取った通知メッセージがサブトピック（例えば、ストリング）を保持するかどうか決定する。

１つの実施形態において、通知管理モジュール２０１は、異なるユーザ１１４Ａ−Ｂの各々に対してホワイトリスト及び／又はブラックリストを維持する。この実施形態では、ホワイトリストとは、移動装置のユーザが通知メッセージの受信を希望するところのインストールされたアプリケーションに対応するアプリケーション識別子のリストである。更に、ブラックリストとは、移動装置のユーザが通知メッセージの受信を希望しないところのインストールされたアプリケーションに対応するアプリケーション識別子のリストである。ホワイトリスト／ブラックリストの維持及び使用は、参考としてここに援用する２００９年２月２４日に出願された“Managing Notification Messages”と題する米国特許出願第１２／３９２，６７９号に説明されている。

図３は、通知メッセージを与えるためのアプリケーションサーバーの規範的コンポーネントを示すブロック図である。例えば、アプリケーションサーバー１０１は、図１のネットワークシステム１００にわたり通知サーバー１０５を経てクライアント装置に通知メッセージをプッシュする。１つの実施形態において、通知モジュール３０１は、プッシュサービスの当局から受け取られた証明書の一部分としてアプリケーションサーバー１０１を識別するためトピック１０３を受け取る。サーバーアプリケーション１１７は、例えば、通知モジュール３０１から検索されたトピック１０３を、図１の移動クライアント１０９のようなクライアント装置へ送り、クライアント装置がアプリケーションサーバー１０１からプッシュされたメッセージを聴取できるようにする。

１つの実施形態において、通知サービスレジストリ３０３は、アプリケーションサーバー１０１にホストされるサーバーアプリケーション１１７又は他のサーバーアプリケーションからのメッセージ通知に対して登録されたクライアント装置から受け取られたユーザトークン及び関連データを記憶する。通知サービスレジストリ３０３は、アプリケーションサーバー１０１にローカル又はリモート結合されたメモリ又は大量記憶装置に基づく。１つの実施形態では、通知サービスレジストリ３０３のユーザトークンは、メッセージ通知について登録するためにクライアントアプリケーションから転送されたサブトピックのようなデータに関連している。関連データは、アプリケーションサーバー１０１及び／又は通知サーバー１０５に対して不透明のままである。例えば、関連データを記憶し、検索し、除去し及び／又は転送する以外、それらのデータについてアプリケーションサーバー１０１に処理リソースが割り当てられない。ユーザトークンにより識別されたクライアント装置へ通知メッセージをプッシュするときに、サーバーアプリケーション１１７は、ユーザトークンを、それに関連したデータ及びトピック１０３と一緒に、例えば、通知モジュール３０１を経て通知サーバー１０５へ転送する。

ユーザトークンと装置トークンとの間マッピングを維持するために、通知サーバー１０５は、どのエイリアスがどの装置に関連しているかのリストを維持する。１つの実施形態では、通知サーバー１０５は、複数のエイリアスを識別子リスト３００の装置に関連付ける。１つの実施形態では、識別子リスト３００のエイリアスは、図２において上述したエイリアス１３６である。例えば、１つの実施形態では、通知サーバー１０５は、エイリアス３０４Ａ−Ｎを装置トークン３０２Ａに、そしてエイリアス３０６Ａ−Ｎを装置トークン３０２Ｂに関連付ける。１つの実施形態では、通知サーバー１０５は、異なるユーザアカウントにより使用中のアプリケーションが、プッシュ通知に契約する要求を送信するときに、ユーザトークンを処理することによりこのリストを維持する。例えば、１つの実施形態では、通知サーバー１０５は、アプリケーションがプッシュ通知に契約することを要求するときに装置識別子を含むユーザトークンを受け取る。この実施形態では、通知サーバーは、ユーザトークンからエイリアス及び関連装置識別子を抽出し、そして必要に応じて、識別子リスト３００を更新する。

図４は、ここに述べる実施形態によるマルチユーザ装置とアプリケーションサーバーとの間の規範的なメッセージ交換を示すシーケンス図である。１つの実施形態では、マルチユーザ装置１０９、アプリケーションサーバー１０１及び通知サーバー１０５は、図１のネットワーク１０７を経て互いに結合される。マルチユーザ装置１０９は、メッセージ通知アプリケーションサーバー１０１について登録する前に、例えば、インスタンス４０１の前に、図１のユーザトークン１１４Ａ又は１１４Ｂのようなユーザトークンを、例えば、プッシュサーバーから通知サーバー１０５を経て受け取る。アプリケーションサーバー１０１は、通知サーバー１０５のようなプッシュサーバーへの接続を確立するためにアプリケーションサーバー１０１を許可する証明書をプッシュサービスの安全当局から受け取る。受け取った証明書は、アプリケーションサーバー１０１を識別するための図１のトピック１０３のようなトピックをストリングとして含む。

１つの実施形態では、マルチユーザ装置１０９のクライアントアプリケーション、例えば、メールは、サーバーアプリケーションからのメッセージ通知について登録するためにアプリケーションサーバー１０１においてホストされる対応するサーバーアプリケーション、例えば、ＩＭＡＰサーバーとのネットワーク接続を開始する。シーケンス４０１において、クライアントアプリケーションは、どの能力がサーバーアプリケーションによりサポートされるか問合せする問合せ要求を送信するためにマルチユーザ装置１０９とアプリケーションサーバー１０１との間のネットワーク接続を開始する。それに応答して、シーケンス４０３において、サーバーアプリケーションは、例えば、ＸＡＰＰＬＥＰＵＳＨＳＥＲＶＩＣＥ指示子を含むプロトコルに基づき、プッシュオプションの利用性を示す指示子で回答する。

次いで、シーケンス４０５において、クライアントアプリケーションは、メッセージプッシュ又は通知について登録するためにマルチユーザ装置１０９からアプリケーションサーバー１０１へコマンドを送信する。コマンドは、サーバーアプリケーションがマルチユーザ装置１０９、ユーザアカウント（例えば、ユーザトークン）及び／又はクライアントアプリケーションをアドレスできるようにするために名前又は識別子を伴うパラメータを含む。１つの実施形態において、パラメータは、マルチユーザ装置１０９のユーザトークンを含む名前付きの値に基づく。任意であるが、パラメータは、マルチユーザ装置１０９内のクライアントアプリケーションが独特に所有するサブトピック、例えば、“ｃｏｍ．ａｐｐｌｅ．ｍｏｂｉｌｅｍａｉｌ”を含んでもよい。シーケンス４０７において、アプリケーションサーバーは、アプリケーションサーバー１０１を識別するトピックで回答する。トピックとは、複数のサーバーにより共有されるプッシュサービスを経てアプリケーションサーバー１０１からプッシュされるメッセージを識別するのに使用できるストリング、例えば、“ｃｏｍ．ｇｏｏｇｌｅ．ｐｕｓｈ”である。マルチユーザ装置１０９とアプリケーションサーバー１０１との間のメッセージ通知を登録するために確立された同じネットワーク接続を経て付加的なアプリケーション特有のトランザクションが交換される。このネットワーク接続は、マルチユーザ装置１０９がアプリケーションサーバー１０１からの通知を待機する間に切断される。

その後、サーバーアプリケーションは、例えば、特定のユーザに対してＩＭＡＰサーバーに新たなメールが到着する等の、あるアプリケーション特有のイベントの発生に応答して、マルチユーザ装置１０９へプッシュされるべき通知メッセージを発生する。サーバーアプリケーションは、通知メッセージをユーザトークンでパッケージし、そして例えば、マルチユーザ装置１０９に対して登録された（又は記憶された）クライアントアプリケーションのサブトピックを含めて、ユーザトークンに関連したデータを通過させる。シーケンス４０９において、アプリケーションサーバー１０１は、アプリケーションサーバー１０１を識別するトピックを伴う通知メッセージを、通知サーバー１０５を経てマルチユーザ装置１０９へ送信する。次いで、シーケンス４１１において、通知サーバー１０５は、プッシュネットワークサービスを経てマルチユーザ装置１０９へ通知メッセージをプッシュする。

通知メッセージが到着すると、マルチユーザ装置１０９は、当該クライアントアプリケーション及びユーザアカウントへメッセージを転送する前にメッセージのトピック及び／又はユーザトークンを検証する。マルチユーザ装置１０９は、検証が失敗した（例えば、トピックが契約されず及び／又はユーザトークンがローカルユーザトークンに一致しない）場合にはメッセージを無視する。任意であるが、マルチユーザ装置１０９は、通知メッセージのペイロードからサブトピックを抽出して、通知メッセージを、トピックに契約している他のアプリケーションへ転送せずに、サブトピックにより名前付けされたクライアントアプリケーションのみに配送してもよい。マルチユーザ装置１０９は、クライアントアプリケーションがスリープ状態にあるか又は通知メッセージを受信するように現在実行されていない場合には、そのユーザアカウントに対してクライアントアプリケーションを呼び出す。次いで、シーケンス４１３において、クライアントアプリケーションは、アプリケーションサーバー１０１における対応するサーバーアプリケーションとの接続を開始し、アプリケーション特有のトランザクション（例えば、対応するユーザのためのメールメッセージを検索する）。

図５Ａは、マルチユーザ装置が通知メッセージを識別されたクライアントアプリケーションへルーティングできるようにするためのプロセス５００の一実施形態を示すフローチャートである。規範的なプロセス５００は、ハードウェア（回路、専用ロジック、等）、ソフトウェア（専用マシンで実行されるような）、又はその組み合わせを含む処理ロジックによって遂行される。例えば、プロセス５００は、図１のシステム１００の幾つかのコンポーネントにより遂行される。ブロック５０１において、プロセス５００の処理ロジックは、ユーザトークンにより識別されるクライアント装置に存在するクライアントアプリケーションのためのアプリケーション識別子（例えば、サブトピック）を発生することができ、クライアントアプリケーションは、サーバー識別子（例えば、トピック）によって識別された１つ以上のアプリケーションサーバーによりホストされるサーバーアプリケーションとのトランザクションを遂行する。

ブロック５０３において、１つの実施形態では、プロセス５００の処理ロジックは、クライアントアプリケーションに対するアプリケーションサーバーからのメッセージ通知サービスを登録する。プロセス５００の処理ロジックは、クライアントアプリケーションに関連した識別子（例えば、クライアントアプリケーション識別子のためのサブトピック、及びクライアント装置のユーザのためのユーザトークンを含む）を、アプリケーションサーバーにおいてホストされるサーバーアプリケーションへ転送して、サーバーアプリケーションが通知メッセージをクライアントアプリケーション及びそれに対応するユーザのためにクライアント装置にプッシュできるようにする。

ブロック５０５において、アプリケーションサーバーから通知メッセージを受け取るのに応答して、プロセス５００の処理ロジックは、通知メッセージがアプリケーション識別子を保持するかどうか決定する。１つの実施形態では、プロセス５００の処理ロジックは、通知メッセージからトークン及びトピックを抽出して（例えば、名前付きの値に基づいて）、通知メッセージがマルチユーザ装置により受信されることが意図されているかどうか検証する。１つの実施形態では、プロセス５００の処理ロジックは、通知メッセージのペイロードからのアプリケーション識別子、例えば、サブトピックを識別する。

アプリケーション識別子又はサブトピック及びユーザトークンのエイリアスが識別された場合には、ブロック５０７において、プロセス５００の処理ロジックは、トピックと契約する他のアプリケーション又は通知メッセージの他のユーザ（それらユーザがクライアントアプリケーションを使用するかどうかに関わらず）へ通知メッセージを転送することなく、エイリアスで識別されたユーザに対してサブトピックにより識別されるクライアントアプリケーションへ通知メッセージを転送する。プロセス５００の処理ロジックは、複数のクライアントアプリケーションの中でサブトピックにより識別されるクライアントアプリケーションを選択すると共に、クライアント装置においてトピックに契約する適当なユーザに対してクライアントアプリケーションを選択する。さもなければ、通知メッセージにサブトピックが見つからない場合には、プロセス５００の処理ロジックは、クライアントアプリケーションのトピック及び／又は各ユーザと契約する各クライアントアプリケーションへ通知メッセージを転送して、通知メッセージを処理すべきかどうか決定する（例えば、メッセージに保持されたコンテンツに基づいて）。

図５Ｂは、通知メッセージをユーザトークンに関連したユーザに対する識別クライアントアプリケーションへルーティングするのに使用されるユーザトークンを発生するためのプロセスの一実施形態を示すフローチャートである。規範的なプロセス５００は、ハードウェア（回路、専用ロジック、等）、ソフトウェア（専用マシンで実行されるような）、又は両方の組み合わせを含む処理ロジックによって遂行される。例えば、プロセス５００は、図１Ａのシステム１００の幾つかのコンポーネント（例えば、マルチユーザクライアント１０９）により遂行される。ブロック５５２において、プロセス５００の処理ロジックは、プッシュ通知要求を受け取る。１つの実施形態において、通知管理モジュール２０１は、図２において上述したように、クライアントアプリケーション１１１Ａ又は１１１Ｂからプッシュ通知要求を受け取る。この実施形態では、プッシュ通知要求は、ユーザからのクライアントアプリケーションからのものである。１つの実施形態において、プッシュ通知要求は、どのクライアントアプリケーション及びユーザがプッシュ通知を要求しているか識別する。

１つの実施形態において、プッシュ通知要求は、次のもの、即ち装置トークン、ユーザトークン、及び／又はユーザ証明書、の１つ以上を含む。例えば、１つの実施形態では、装置トークンは、プッシュ通知システムに対して装置を識別する装置トークン１１５であり、そしてユーザトークンは、プッシュ通知システムに対してユーザを識別するのに使用されるユーザトークン１１６Ａであり、図１Ａ−２について上述したようにそのユーザに対するエイリアスを含む。

ブロック５５４において、プロセス５００は、要求に証明書が含まれているかどうか決定する。１つの実施形態では、証明書は、要求を作成するユーザを識別するのに使用されるパブリックキー証明書である。又、証明書は、ユーザのアイデンティティ（ＡｐｐｌｅＩＤ、ＭｏｂｉｌｅＭｅ ＩＤ、この分野で知られている他の証明書、等）に基づくものである。要求に証明書が含まれない場合には、ブロック５５６において、プロセス５５０は、証明書を発行する。１つの実施形態では、プロセス５００は、第三者の証明書発行サービスから証明書を検索することにより証明書を発行する。１つの実施形態では、適当な証明書当局が証明書に署名する。１つの実施形態では、証明書を使用して、ユーザのエイリアスが発生される（例えば、図１について上述したユーザトークン１１６Ａの一部分であるエイリアス１３６）。

プッシュ通知要求に証明書が含まれる場合には、プロセス５５０は、ブロック５５８において、プッシュ通知システムに接続する。１つの実施形態では、プロセス５５０は、プッシュ通知接続コマンドを通知サーバー１０５へ送信する。プッシュ通知接続を送信することにより、プロセス５５０は、プロセス５５０がユーザのための通知及びユーザに関連したクライアントアプリケーションを受信する準備ができたことを通知システムに信号する。

ブロック５６０において、プロセス５６０は、プッシュ通知システムから装置トークンを検索しそして記憶する。１つの実施形態では、プロセス５００は、図２について上述したように、通知サーバー１０５から装置トークンを検索しそしてその装置トークンを契約プロフィール２０３に記憶する。１つの実施形態では、通知サーバー１０５に接続するマルチユーザ装置１０９の最初のインスタンスに装置トークンが生成される。

プロセス５５０は、ブロック５６２において、プッシュ通知要求にユーザトークンが含まれるかどうか決定する。１つの実施形態では、プッシュ通知要求に対してユーザトークンが利用できる場合には、要求側プロセスが、図１Ｂについて述べたユーザトークン１１６Ａのようなユーザトークンをプッシュ通知要求に挿入する。プッシュ通知要求にユーザトークンが含まれない場合には、プロセス５５０は、ブロック５６４において、ユーザトークンをフェッチする。１つの実施形態では、プロセス５５０は、ユーザトークンをフェッチするためにプッシュ通知接続存在コマンドを通知サーバーへ送信する。それに応答して、通知サーバーは、適当なユーザトークン（例えば、ユーザトークン１１６Ａ）を要求側プロセス（例えば、プロセス５５０）へ送信する。この実施形態では、接続存在コマンドは、装置及び装置に関連したユーザがオンラインでありそしてプッシュ通知を受け取る準備ができたことをプッシュ通知サーバーに信号する。１つの実施形態では、プロセス５５０は、ユーザがマルチユーザ装置にログインするか、又はマルチユーザ装置が１ユーザ装置又はデフォールトユーザを伴う多ユーザ装置に対してブートアップするときに、プッシュ通知接続存在コマンドを送信する。ユーザトークンが要求に含まれる場合には、プロセス５５０は、ブロック５６６において、ユーザトークンをイネーブルする。１つの実施形態では、プロセス５５０は、トークンが生成されるときにユーザトークンをイネーブルする。

図６は、アプリケーションサーバーからアプリケーションクライアントへ通知メッセージを与えるためのプロセスの一実施形態を示すフローチャートである。規範的なプロセス６００は、ハードウェア（回路、専用ロジック、等）、ソフトウェア（専用マシンで実行されるような）、又は両方の組み合わせを含む処理ロジックによって遂行される。例えば、プロセス６００は、図１のアプリケーションサーバー１０１のようなシステム１００の幾つかのコンポーネントにより遂行される。ブロック６０１において、プロセス６００の処理ロジックは、アプリケーションサーバーにおいてホストされるサーバーアプリケーションからのメッセージ通知に対してクライアント装置のクライアントアプリケーションから登録要求を受け取る。登録要求は、クライアント装置及び／又はユーザのための識別子（例えば、ユーザトークン）と、任意であるが、クライアントアプリケーションのための付加的な識別子（例えば、サブトピック）とを含む。

ブロック６０３において、プロセス６００の処理ロジックは、アプリケーションサーバーを識別するサーバー識別子（例えば、トピック）をクライアント装置へ送信して、クライアント装置が、アプリケーションサーバーから通知された（又はプッシュされた）メッセージを聴取できるようにする。１つの実施形態では、プロセス６００の処理ロジックは、ブロック６０５において、クライアント装置に対する通知メッセージをアドレスするために装置識別子及びプッシュサービスのエイリアスを含む識別子を記憶する。例えば、１つの実施形態では、サーバーは、図３について上述した識別子リスト３００のような識別子リストに装置識別子及びそれに対応するエイリアスを記憶する。記憶される識別子は、通知メッセージを受け取るためにクライアント装置のクライアントアプリケーションを識別するサブトピックを含む。

１つの実施形態では、ブロック６０７において、プロセス６００の処理ロジックは、クライアントアプリケーションをホストするクライアント装置のユーザのための記憶された識別子に基づいてメッセージを受信するために登録されたクライアントアプリケーションの通知メッセージを発生する。例えば、通知メッセージは、クライアントアプリケーションに関連したアカウントに関するサーバーアプリケーションにおけるイベントの発生、例えば、新たなメールメッセージの到着、チャット要求、スケジュール更新、又は他の適用可能なイベント、を指示する。通知メッセージは、通知メッセージを受信するクライアント装置及びユーザを識別するユーザトークンと、クライアントアプリケーションを識別するサブトピックを含むペイロードと共にパッケージされる。ブロック６０９において、プロセス６００の処理ロジックは、発信側アプリケーションサーバーを識別するトピックを含む通知メッセージを、プッシュサービスを経てクライアント装置へ送信する。通知メッセージは、クライアントアプリケーションを識別するためにメッセージのペイロードに埋め込まれたサブトピックを保持する。その後、ブロック６１１において、プロセス６００の処理ロジックは、サーバーアプリケーションと共にクライアントアプリケーションから確立されたネットワークセッションを経てアプリケーション特有のトランザクションを遂行する。

ブロック６１３において、プロセス６００の処理ロジックは、クライアントアプリケーション、ユーザ及び／又はクライアント装置への通知メッセージの送信をストップするための条件が満足されたかどうか決定する。サーバーアプリケーションから通知メッセージを受信するためのユーザのクライアントアプリケーションが登録される。１つの実施形態において、プロセス６００の処理ロジックは、クライアント装置へ最後の通知メッセージを送信して以来のユーザ及び／又はクライアント装置に対する期間又は経過時間を監視する。この期間がスレッシュホールド（例えば、１日、１２時間、等、これは予め構成されるか又は動的に構成される）を越えた場合には、ユーザ及び／又はクライアント装置への通知メッセージの送信をストップするための条件が満足される。ブロック６１５において、プロセス６００の処理ロジックは、その条件が満足された場合にサーバーアプリケーションのメッセージ通知（又はプッシュサービス）からユーザ及び／又はクライアント装置を登録解除する。１つの実施形態では、ユーザは、サーバーアプリケーションの通知受信者のリストから除去される。例えば、１つの実施形態では、プロセス６００の処理ロジックは、クライアント装置のクライアントアプリケーションを識別するサブトピックを保持するデータを含めて、ユーザを識別するエイリアスに関連したエントリを、メッセージ通知のためのレジストリから除去する。別の実施形態では、クライアント装置は、サーバーアプリケーションの通知受信者のリストから除去される。例えば、プロセス６００の処理ロジックは、クライアント装置のクライアントアプリケーションを識別するサブトピックを保持するデータを含めて、クライアント装置を識別する装置トークンに関連したエントリを、メッセージ通知のためのレジストリから除去する。この実施形態では、クライアント装置を登録解除することで、クライアント装置に関連したユーザも登録解除される。

図７は、ここに述べる実施形態に使用されるデータ処理システムの一例を示す。図７に示すデータ処理システム７００は、１つ以上のマイクロプロセッサであるか又はシステムオンチップ集積回路である処理システム７１１を備え、又、処理システムにより実行するためのデータ及びプログラムを記憶するメモリ７０１も備えている。又、システム７００は、オーディオ入力／出力サブシステム７０５も備え、これは、例えば、音楽を再生するためのマイクロホン及びスピーカを含むか、又はスピーカ及びマイクロホンを通して電話機能を与える。システム７００は、少なくとも幾つかの実施形態では、ここに述べる１つ以上のプロフィールを要求し、そしてそれらのプロフィールをダウンロードし、ネットワークを通して通信するよう装置を構成することができる。システム７００は、図７に示すシステムであるサーバーデータ処理システムからそれらのプロフィールをダウンロードすることができる。１つの実施形態では、システム７００は、図１に示す装置１１１Ａ−Ｂである。

ディスプレイコントローラ・ディスプレイ装置７０７は、ユーザのための視覚ユーザインターフェイスを与え、このデジタルインターフェイスは、ＯＳ Ｘオペレーティングシステムソフトウェアを実行するときにＭａｃｉｎｔｏｓｈコンピュータに示されるものと同様のグラフィックユーザインターフェイスを含む。又、システム７００は、別のデータ処理システムと通信するための１つ以上のワイヤレストランシーバ７０３も備えている。ワイヤレストランシーバは、ＷｉＦｉトランシーバ、赤外線トランシーバ、Ｂｌｕｅｔｏｏｔｈ（登録商標）トランシーバ、及び／又はワイヤレスセルラー電話トランシーバである。ある実施形態では、図示されていない付加的なコンポーネントも、システム７００の一部分であり、そしてある実施形態では、図７の示すものより少ないコンポーネントをデータ処理システムに使用してもよいことが明らかであろう。

又、データ処理システム７００は、ユーザがシステムに入力を与えることができるようにするために設けられた１つ以上の入力装置７１３も備えている。それらの入力装置は、キーパッド、又はキーボード、又はタッチパネル、又はマルチタッチパネルである。又、データ処理システム７００は、ドックのためのコネクタである任意の入力／出力装置７１５も備えている。当業者に明らかなように、種々のコンポーネントを相互接続するのに、図示されていない１つ以上のバスを使用できることが明らかであろう。図７に示すデータ処理システムは、ハンドヘルドコンピュータ、又はパーソナルデジタルアシスタント（ＰＤＡ）、又はＰＤＡのような機能をもつセルラー電話、又はセルラー電話を含むハンドヘルドコンピュータ、又はｉＰｏｄのようなメディアプレーヤ、或いはそれら装置の態様又は機能を結合する装置、例えば、ＰＤＡ及びセルラー電話と１つの装置に結合されたメディアプレーヤである。他の実施形態では、データ処理システム７００は、ネットワークコンピュータ、又は別の装置内の埋め込み型処理装置、或いは図７に示すものより少数のコンポーネント又はおそらくそれより多数のコンポーネントを有する他の形式のデータ処理システムである。

図８は、本発明の１つの実施形態に使用されるデータ処理システムの一例を示す。例えば、図８は、コンピュータシステムの種々のコンポーネントを示すが、コンポーネントを相互接続する特定のアーキテクチャー又は仕方を表わすことを意図していない。というのは、そのような詳細は、本発明と関係がないからである。より少数のコンポーネント又はおそらくより多数のコンポーネントを有するネットワークコンピュータ及び他のデータ処理システム又は他の消費者向け電子装置も、本発明に使用できることが明らかであろう。図８は、図１に示すサーバーシステムを表わす。

図８に示すように、一形式のデータ処理システムであるコンピュータシステム８００は、バス１９０３を備え、これは、マイクロプロセッサ８０５、ＲＯＭ（リードオンリメモリ）８０７、揮発性ＲＡＭ８０９、及び不揮発性メモリ８１１に結合される。マイクロプロセッサ８０５は、メモリ８０７、８０９、８１１からインストラクションを検索し、そしてそれらインストラクションを実行して、上述したオペレーションを遂行する。バス８０３は、これら種々のコンポーネントを一緒に相互接続すると共に、これらのコンポーネント８０５、８０７、８０９及び８１１を、ディスプレイコントローラ・ディスプレイ装置８１３、並びに入力／出力（Ｉ／Ｏ）装置のような周辺装置に相互接続し、そのＩ／Ｏ装置は、マウス、キーボード、モデム、ネットワークインターフェイス、プリンタ、及びこの分野で良く知られた他の装置である。典型的に、入力／出力装置８１５は、入力／出力コントローラ８１７を通してシステムに結合される。揮発性ＲＡＭ（ランダムアクセスメモリ）８０９は、典型的に、メモリ内のデータをリフレッシュ又は維持するために常時電力を必要とするダイナミックＲＡＭ（ＤＲＡＭ）として具現化される。

大量記憶装置８１１は、典型的に、システムから電力が取り去られた後もデータ（例えば、大量のデータ）を維持する磁気ハードディスク、磁気光学ドライブ、光学ドライブ又はＤＶＤ ＲＡＭ、又はフラッシュメモリ、或いは他の形式のメモリシステムである。典型的に、大量記憶装置８１１は、ランダムアクセスメモリでもあるが、これは、必要なことではない。図８は、大量記憶装置８１１がデータ処理システムの残りのコンポーネントに直結されたローカル装置であることを示しているが、本発明は、システムから遠隔にある不揮発性メモリ、例えば、モデムのようなネットワークインターフェイス、イーサネット（登録商標）インターフェイス、又はワイヤレスネットワークを通してデータ処理システムに結合されたネットワーク記憶装置を使用してもよいことが明らかである。バス８０３は、この分野で良く知られたように、種々のブリッジ、コントローラ、及び／又はアダプタを通して互いに接続される１つ以上のバスを含む。

ここで使用する「メモリ」という語は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）及びスタティックＲＡＭ（ＳＲＡＭ）のような全ての揮発性記憶媒体を包含することが意図される。コンピュータ実行可能なインストラクションは、磁気ハードディスク、光学ディスクのような不揮発性記憶装置に記憶され、そして典型的に、プロセッサによるソフトウェアの実行中に、直接メモリアクセスプロセスによりメモリに書き込まれる。当業者であれば、「マシン読み取り可能な記憶媒体」という語は、プロセッサによりアクセスできる任意の形式の揮発性又は不揮発性記憶装置を含むことが直ちに認識されよう。

以上の説明において、本発明は、特定の規範的な実施形態を参照して説明された。特許請求の範囲に規定された本発明の広い精神及び範囲から逸脱せずに種々の変更がなされ得ることが明らかであろう。従って、本明細書及び図面は、例示に過ぎず、それに限定されるものではない。

１００:ネットワークシステム
１０１：アプリケーションサーバー
１０３:トピック
１０５:通知サーバー
１０７：ネットワーク
１０９：マルチユーザ装置
１１１Ａ−Ｂ：アプリケーション
１１３Ａ−Ｂ：サブトピック
１１４Ａ−Ｂ：ユーザトークン
１１５：装置トークン
１１６Ａ−Ｂ：ユーザ
１１７：サーバーアプリケーション
１１９:ブリッジ
１３０:装置識別子
１３４：ゾーン情報
１３６：エイリアス
１３８：パッディングデータ

Claims (20)

1. マルチユーザメッセージ通知のためのマシン実施方法において、
   クライアント装置内の複数のユーザアカウントの１つである対応するユーザアカウントを識別するエイリアスを発生する段階であって、そのエイリアスは、１つ以上のアプリケーションサーバーにおいてホストされるサーバーアプリケーションに関連したクライアントアプリケーションに対応するサブトピック識別子と組み合わせて使用されるものである段階と、
   前記クライアントアプリケーションに関連した識別子を前記サーバーアプリケーションへ転送して、前記サーバーアプリケーションが、前記クライアントアプリケーションのためのクライアント装置の前記対応するユーザアカウントへ通知メッセージをプッシュできるようにするために、前記クライアントアプリケーション及びエイリアスに対して前記アプリケーションサーバーに通知サービスを登録する段階と、
   前記アプリケーションサーバーからの通知メッセージを受信するのに応答して、前記通知メッセージが前記エイリアス及び前記クライアントアプリケーションのサブトピック識別子を保持するかどうか決定する段階と、
   前記通知メッセージが前記クライアントアプリケーションの識別子を保持する場合には前記クライアント装置の他のアプリケーションへ前記通知メッセージを転送することなく前記対応するユーザアカウントに対して前記クライアントアプリケーションへ前記通知メッセージを転送する段階と、
   を含む方法。
2. 複数のクライアントアプリケーションが前記クライアント装置にホストされ、前記サブトピック識別子は、その複数のクライアントアプリケーションの中でクライアントアプリケーションを独特に識別する、請求項１に記載の方法。
3. 前記識別子は、サブトピック識別子を含む、請求項１に記載の方法。
4. 前記対応するユーザアカウントに関連した証明書からエイリアスを導出する、請求項１に記載の方法。
5. 前記エイリアスは、クライアント装置の装置識別子を更に含むユーザトークンに記憶される、請求項１に記載の方法。
6. 前記識別子は、前記対応するユーザアカウントを独特に識別するユーザトークンを含む、請求項３に記載の方法。
7. 前記アプリケーションサーバーは、トピック識別子により独特に識別され、そして前記登録段階は、更に、前記アプリケーションサーバーからの通知を聴取するために前記トピック識別子に対して前記クライアントアプリケーションを登録することを含み、前記トピック識別子に対して２つ以上のクライアントアプリケーションが登録される、請求項２に記載の方法。
8. 前記アプリケーションサーバーとのネットワーク接続を開始する段階と、
   前記ネットワーク接続を経て前記アプリケーションサーバーへ前記識別子を送信する段階と、
   を更に含む請求項５に記載の方法。
9. 前記決定段階は、更に、
   前記エイリアス及びトピック識別子を前記通知メッセージから抽出すること、及び
   前記通知メッセージが前記サブトピック識別子を保持しない場合にはトピックストリングについて登録された各クライアントアプリケーション及びそれに対応するユーザに前記通知メッセージを転送すること、
   を含む請求項５に記載の方法。
10. 前記転送段階は、前記クライアントアプリケーションが現在アクティブでない場合には前記クライアントアプリケーションを呼び出すことを含む、請求項１に記載の方法。
11. メッセージ通知を与えるためのマシン実施方法において、
    メッセージ通知のためのクライアント装置のユーザのクライアントアプリケーションからの登録要求を、アプリケーションサーバーにおいてホストされるサーバーアプリケーションで受信する段階であって、前記要求は、クライアント装置を識別するユーザトークンを含む識別子と、クライアントアプリケーションを識別するクライアントアプリケーション識別子とを有し、前記クライアント装置は、複数のユーザアカウントをホストすることができ、そしてユーザのための対応ユーザアカウントを含むものである段階と、
    前記クライアント装置が前記アプリケーションサーバーからプッシュされたメッセージを聴取できるようにするために、ユーザのためのサーバー識別子を送信する段階と、
    前記受信した識別子を記憶して、メッセージ通知についてユーザを登録する段階と、
    そのユーザについて前記クライアントアプリケーションに通知するために前記クライアント装置へ前記ユーザトークンを含む通知メッセージを送信する段階であって、前記通知メッセージは、前記サーバー識別子により識別され、且つ前記通知メッセージは、前記クライアントアプリケーション識別子を埋め込むものである段階と、
    を含む方法。
12. 前記ユーザトークンは、ユーザを識別するエイリアスと、クライアント装置を識別する装置識別子とを含む、請求項１１に記載の方法。
13. 前記登録要求は、前記クライアント装置により開始されるネットワーク接続を経て受け取られ、そして前記サーバー識別子は、そのネットワーク接続を経て送信される、請求項１１に記載の方法。
14. 前記ユーザトークンは、前記クライアントアプリケーション識別子を含む不透明データに関連して記憶される、請求項１１に記載の方法。
15. 前記通知メッセージは、クライアント装置のユーザを識別するためのユーザトークンを含み、そして前記不透明データは、前記通知メッセージのペイロードに保持される、請求項１４に記載の方法。
16. 前記通知メッセージを送信する段階は、
    プッシュサービスにおいてプッシュサーバーとのネットワーク接続を確立すること、
    前記ネットワーク接続を経て前記プッシュサーバーへ通知メッセージを送信すること、を含み、前記通知メッセージは、前記サーバー識別子と共にパッケージされる、請求項１２に記載の方法。
17. 前記サーバー識別子は、前記プッシュサービスの当局からの証明書において受け取られ、そして前記サーバー識別子は、前記プッシュサービスを共有するアプリケーションサーバーを独特に識別する、請求項１６に記載の方法。
18. マシンにより実行されたときに、そのマシンが、
    クライアント装置の複数のユーザアカウントの１つである対応するユーザアカウントを識別するエイリアスを発生し、そのエイリアスは、１つ以上のアプリケーションサーバーにおいてホストされるサーバーアプリケーションに関連したクライアントアプリケーションに対応するサブトピック識別子と組み合わせて使用され、
    前記クライアントアプリケーションに関連した識別子を前記サーバーアプリケーションへ転送して、前記サーバーアプリケーションが、前記クライアントアプリケーションのためのクライアント装置の前記対応するユーザアカウントへ通知メッセージをプッシュできるようにするために、前記クライアントアプリケーション及びエイリアスに対して前記アプリケーションサーバーに通知サービスを登録し、
    前記アプリケーションサーバーからの通知メッセージを受信するのに応答して、前記通知メッセージが前記エイリアス及び前記クライアントアプリケーションのサブトピック識別子を保持するかどうか決定し、
    前記通知メッセージが前記クライアントアプリケーションの識別子を保持する場合には前記クライアント装置の他のアプリケーションへ前記通知メッセージを転送することなく前記対応するユーザアカウントに対して前記クライアントアプリケーションへ前記通知メッセージを転送する、
    ことを含むメッセージ通知方法を遂行するようにさせるインストラクションを有するマシン読み取り可能な記憶媒体。
19. マシンにより実行されたときに、そのマシンが、
    メッセージ通知のためのクライアント装置のユーザのクライアントアプリケーションからの登録要求を、アプリケーションサーバーにおいてホストされるサーバーアプリケーションで受信し、前記要求は、ユーザ及びクライアント装置を識別するユーザトークンを含む識別子と、クライアントアプリケーションを識別するクライアントアプリケーション識別子とを有し、前記クライアント装置は、複数のユーザアカウントをホストすることができ、そしてユーザのための対応ユーザアカウントを含むものであり、
    ユーザのためのサーバー識別子を送信して、前記クライアント装置が前記アプリケーションサーバーからプッシュされたメッセージを聴取できるようにし、
    前記受信した識別子を記憶して、メッセージ通知についてユーザを登録し、
    前記クライアント装置へ前記ユーザトークンを含む通知メッセージを送信してそのユーザについて前記クライアントアプリケーションに通知し、前記通知メッセージは、前記サーバー識別子により識別され、且つ前記通知メッセージは、前記クライアントアプリケーション識別子を埋め込む、
    ことを含む、メッセージ通知を与える方法を遂行するようにさせるインストラクションを有するマシン読み取り可能な記憶媒体。
20. サーバーアプリケーションを含む実行可能なインストラクションを記憶するメモリと、
    プッシュネットワークに結合されたネットワークインターフェイスと、
    メッセージングサービスに対して前記メモリからの実行可能なインストラクションを実行するために前記ネットワークインターフェイス及び前記メモリに結合されたプロセッサであって、
    クライアント装置からの開始に応答して、前記ネットワークインターフェイスを経て前記クライアント装置との第１のネットワーク接続を確立し、
    前記第１のネットワーク接続を経てクライアント装置のクライアントアプリケーションからの登録要求を前記サーバーアプリケーションで受信し、前記要求は、クライアント装置のユーザを識別するユーザトークンを含む識別子と、クライアントアプリケーションを識別するクライアントアプリケーション識別子とを有し、
    前記クライアント装置のサーバー識別子を送信して、前記クライアント装置が前記サーバーアプリケーションからプッシュされたメッセージを聴取できるようにし、
    前記受信した識別子を記憶して、メッセージ通知についてユーザを登録し、
    前記ネットワークインターフェイスを経て前記プッシュネットワークへの第２のネットワーク接続にわたって前記クライアント装置へ通知メッセージを送信し、前記通知メッセージは、ユーザについてクライアントアプリケーションに通知するためのユーザトークンを有し、前記通知メッセージは、前記サーバー識別子により識別され、そして前記通知メッセージは、前記クライアントアプリケーション識別子を埋め込む、
    ように構成されたプロセッサと、
    を備えたサーバー。

Images