JP2014531072A - 多数のデバイスへのイベントの配信 - Google Patents

Abstract

メッセージコピーおよびメッセージ待ち時間を最小限にすることができる方式で、多数のイベントコンシューマにイベントを配信する。方法は、イベントが特定のコンシューマの集合に送信されるべきかを決定することを含む。この方法はさらに、イベントをコピーし、個々のコピーを複数の配信区分に提供することを含む。この方法はさらに、それぞれの配信区分においてイベントのコピーを複数のルーティングスリップとまとめて複数の送信バンドルを作成することを含む。このルーティングスリップは、イベントの受信が意図される複数の個々のコンシューマを表す。方法はさらに、ルーティングスリップで指定された個々のコンシューマにイベントを配信する送信バンドルを用いることを含む。

Description

本願発明の一実施例は、例えば、多数のデバイスへのイベントの配信に関する。

[0001]コンピュータおよびコンピューティングシステムは、現代生活のほとんどすべての側面に影響を与えている。コンピュータは、仕事、レクリエーション、健康管理、運輸、エンターテイメント、家庭管理などに広く関わる。

[0002]さらに、コンピューティングシステムがネットワーク接続によって他のコンピューティングシステムと相互接続可能であることによって、コンピューティングシステムの機能性は拡大されることができる。ネットワーク接続は、限定はされないが、有線もしくは無線のイーサネットによる接続、セルラー式接続、またはシリアル、パラレル、ＵＳＢもしくは他の接続によるコンピュータ間接続をも含んでよい。これらの接続は、コンピューティングシステムが他のコンピューティングシステムでのサービスにアクセスできるようにし、また、他のコンピューティングシステムから迅速かつ効率的にアプリケーションデータを受信できるようにする。

[0003]多くのコンピュータは、コンピュータとの直接のユーザ対話による使用が意図される。そのため、コンピュータは入力ハードウェアおよびソフトウェアユーザインターフェースを有して、ユーザ対話を容易にする。たとえば、ユーザがコンピュータにデータを入力できるようにするために、現代の汎用のコンピュータは、キーボード、マウス、タッチパッド、カメラなどを含んでよい。その上、さまざまなソフトウェアユーザインターフェースが利用可能である。

[0004]ソフトウェアユーザインターフェースの例としては、グラフィカルユーザインターフェース、テキストコマンドラインベースのユーザインターフェース、ファンクションキーまたはホットキーのユーザインターフェースなどを含む。

[0005]ｉＯＳ、アンドロイド（Ａｎｄｒｏｉｄ）、ウィンドウズフォン（Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ）、ウィンドウズ（Ｗｉｎｄｏｗｓ）などでモバイルアプリを構築する開発者を仮定すると、一般大衆が興味を持つニュース、世界の出来事に関する情報および事実、またはサッカー、フットボール、ホッケー、もしくは野球のリーグもしくはチームのスポーツファンのための情報および事実を配信して、これらのニュースや情報、事実を最新のものにすることに焦点を合わせる。これらのアプリケーション（および幅広い種類の他のアプリ）にとって、ファンのひいきのチームのスコアまたは世界で発生するある種のニュースイベントとして注意喚起または祝いの表示をする通知は、大きな差別化技法（ｄｉｆｆｅｒｅｎｔｉａｔｏｒ）である。その差別化技法は通常、サーバインフラストラクチャの構築および管理を実行して供給者が提供する通知チャネルにそれらのイベントをプッシュ配信するが、これは最適化されたユーザ経験に焦点を合わせる多くのモバイルアプリケーション（「アプリ」）の開発者の技能範囲を超える。そして、彼らのアプリが非常に成功した場合、イベントを何万、さらには何十万ものデバイスにタイムリーな方式で配信することは非常に困難であるので、単純なサーバベースのソリューションはすぐに拡張性の上限に達する。

[0006]タイムリーであることは、この種の多くのアプリケーションにとって重要な価値のある問題であろう。たとえば、スポーツファンは、最新であることに関して言えば忍耐力をあまり持っていない。同様に、閾値に達する金融ポートフォリオの状況を見ている個人および機関、大きなオークションに参加している人々、または、自分達のフェイスブック上の仮想の農業領域が通過するハリケーンにまさに襲われようとしているプレイヤー達は、最新であることに関して言えば忍耐力をあまり持っていないことが多い。

[0007]ＡｐｐｌｅのｉＯＳ用Ｐｕｓｈ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅｓ、Ｇｏｏｇｌｅのアンドロイド用Ｃ２ＤＭサービス、Ｍｉｃｒｏｓｏｆｔのウィンドウズフォン用ＭＰＮＳサービス、および他の多くのモバイルプラットフォームは、最大エネルギーを供給するデバイス（したがってバッテリ）の効率に何らかの形の最適化された共有の接続を提供し、アプリケーションがそれぞれのプラットフォームのプッシュ通知ＡＰＩを介してその共有のチャネルを利用できるようにする。しかしながら、上述のとおり、これらのプラットフォームを用いて単一のイベントに基づく多数の通知を配信することは困難であり、かつ／または、大量のコンピューティングリソースを必要とする場合がある。

[0008]本明細書で主張する内容は、前述のような環境においてのみにおけるあらゆる不利を解決し、または前述のような環境においてのみ動作する実施形態に限定されるものではない。むしろこの背景は、本明細書において述べられるいくつかの実施形態が実施されることができる例示的な技術分野を説明するために提供されるにすぎない。

[0009]本明細書における一実施形態は、コンピューティング環境において実施されうる方法を対象とする。この方法は、メッセージコピーおよびメッセージ待ち時間を最小限にすることができる方式で多数のイベントコンシューマにイベントを配信するための動作を含む。この方法は、イベントが特定のコンシューマの集合に送信されるべきか決定することを含む。この方法はさらに、イベントをコピーし、個々のコピーを複数の配信区分に提供することを含む。この方法はさらに、それぞれの配信区分においてイベントのコピーを複数のルーティングスリップとまとめて複数の送信バンドルを作成することを含む。このルーティングスリップは、イベントの受信が意図される複数の個々のコンシューマを表す。方法はさらに、ルーティングスリップで指定された個々のコンシューマにイベントを配信する送信バンドルを用いることを含む。

[0010]本概要は、詳細な説明においてさらに後述される概念の選択を、単純化された形で紹介するために提供される。本概要は、主張される内容の重要な特徴または本質的な特徴を特定するよう意図されるものではなく、主張される内容の範囲を決定する助けとなるものとして使用されるよう意図されるものでもない。

[0011]さらなる特徴および利点は以下に続く説明に記述され、一部は説明から明白であり、または本明細書における教示の実施によって知ることができる。本発明の特徴および利点は、添付の特許請求の範囲において具体的に指摘される機器および組合せによって実現され、取得されうる。本発明の特徴は、後述する詳細および添付の特許請求の範囲からより充分に明らかになり、また、以下に記載の本発明の実施によって知ることができる。

[0012]上述その他の利点および特徴を得られる方法を説明するために、上記に簡潔に述べられた内容のさらに具体的な説明が、添付の図面に示される具体的な実施形態を参照することによりなされる。これらの図面は典型的な実施形態のみを表し、したがって、範囲が限定されるものと考えられるべきではないことが理解され、実施形態は、添付の図面を使用して、さらに具体的かつ詳細に記述され、説明される。

[0013]イベントデータ配信システムの例を示す図である。 [0014]イベントデータの取得および配信システムを示す図である。 [0015]イベントを配信する方法を示す図である。

[0016]本明細書で説明されるいくつかの実施形態はプッシュ通知機構を利用し、さらに通知管理および配信層をまず提供し、モバイルおよびデスクトップの開発者が、所定の規模で非常にタイムリーな配信特性を伴うこれらのプッシュ通知チャネルを利用できるようにする。

[0017]いくつかの実施形態は、カスケーディングおよび区分された配信による通知の同報通信、ならびに、個々の対象ごとの入口から出口までの通知の平均フロー時間を最小限にしつつメッセージコピーの数を最小限にし、かつ非常に多数の送信対象に拡大することができる送信システムを実行する方法を含んでよい。

[0018]いくつかの実施形態は、クライアントおよび第三者の序列を監視するシステムの目的で送信統計を収集し、データウェアハウスソリューションに流す方法を含んでよい。
[0019]いくつかの実施形態は、一時的または永続的な送信エラー状態のために一時的または永続的に対象をブラックリストに載せる方法を含んでよい。

[0020]基礎として、一実施形態のシステムは、ワシントン州レッドモンド（Ｒｅｄｍｏｎｄ Ｗａｓｈｉｎｇｔｏｎ）のＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＷｉｎｄｏｗｓ Ａｚｕｒｅ Ｓｅｒｖｉｃｅ Ｂｕｓにより提供されるパブリッシュ／サブスクライブのインフラストラクチャを使用するが、これはまた、さまざまな他のメッセージングシステムにおいて似たような形で存在する。このインフラストラクチャは、提示される方法の説明される実施を容易にする２つの機能を提供する。すなわち、トピックとキューである。

[0021]キューはメッセージの格納構造であり、メッセージが起こった順番に追加され（エンキューされ）、また、メッセージが追加されたのと同じ順番で取り出される（デキューされる）ようにする。メッセージは、任意の数の同時に存在するクライアントによって追加され、取り出されることができ、エンキュー側の負荷を平滑化することと、デキュー側のレシーバにかかる処理負荷のバランスをとることとを可能にする。キューはまた、メッセージがデキューされるときにエンティティがメッセージ上でロックを取得することを可能にし、いつメッセージが実際にキューから削除されるか、または取り出されたメッセージの処理が失敗した場合にメッセージをキューに戻すことができるかどうかに対する消費クライアントの明示制御を可能にする。

[0022]トピックは、キューのすべての特性を有する格納構造であるが、複数の同時に存在する「サブスクリプション」を可能にし、サブスクリプションはそれぞれ、一連のエンキューされたメッセージに対し、切り離された、選別された表示を可能にする。トピックのそれぞれのサブスクリプションは、サブスクリプションの関連したフィルタ条件（複数可）がメッセージに明確に一致するという条件で、エンキューされた各メッセージのコピーを得る。その結果、各サブスクリプションがすべてのメッセージに合致する単純な「パススルー」状況を有する１０のサブスクリプションを備えるトピックにエンキューされたメッセージは、サブスクリプションごとに１つの、計１０個のメッセージを得る。キューのようなサブスクリプションは、レシーバにかかる処理負荷のバランスをとる複数の同時に存在するコンシューマを有することができる。

[0023]別の基礎的な概念は「イベント」の概念であるが、基本的なパブリッシュ／サブスクライブのインフラストラクチャの観点から、これは単にメッセージである。一実施形態に照らして、イベントは、メッセージ本体およびメッセージプロパティの使用に影響する単純な制約の集合の影響を受ける。イベントのメッセージ本体は通常曖昧なデータブロックとして流れ、一実施形態によって考えられるあらゆるイベントデータは通常メッセージプロパティに流れるが、これはイベントを表すメッセージの一部であるキーと値のペアの集合である。

[0024]実施形態は、所与の入力イベントから、ある範囲に関連付けられた多数の「対象１０２」のそれぞれに情報のコピーを配信するように、また、対象１０２ごとに最短時間で配信するように構成されてよい。対象１０２は、ある第三者通知システム、またはあるネットワークアクセス可能な外部インフラストラクチャ、およびその通知システムまたはそのインフラストラクチャにアクセスするための補助データへのアダプタの識別子に結合されたデバイスまたはアプリケーションのアドレスを含んでよい。

[0025]いくつかの実施形態は、３つの異なる処理役割に分割されるアーキテクチャを含んでよく、以下で詳細に説明され、図１を参照することによって理解されることができる。図１において「１」とエリプシスと「ｎ」とによって記されるように、処理役割はそれぞれ１つまたは複数の処理役割の段階を有することができる。それぞれの場合での「ｎ」の使用は、処理役割に適用される他の場合とはそれぞれ異なると考えられるべきであることに留意すべきであり、つまり、処理役割はそれぞれ同じ数の段階を有する必要はない。「配信エンジン」１１２の役割は、イベントを受け取り、それらを対象１０２の群を含むルーティングスリップとバンドルする（たとえば図２のルーティングスリップ１２８−１を参照のこと）。「送信エンジン」１０８はこれらのバンドルを受け取り、対象１０２によって表されるネットワークロケーションへの送信のためのルーティングスリップを処理する。管理サービス１４２によって示される「管理役割」は外部ＡＰＩを提供して対象１０２を管理し、また、送信エンジン１０８からの統計およびエラーデータを受け取り、かつそのデータを処理、記憶する役割を担う。

[0026]データフローは、イベントが配信用に提出される「配信トピック１４４」に固定される。提出されたイベントは、メッセージプロパティを用いて関連付けられる範囲を示すラベルを付けられる。これは、イベントと未加工のメッセージとを区別する前述の制約のひとつとなりうる。

[0027]図示された例における配信トピック１４４は、「配信区分１２０」ごとに１つのパススルー（フィルタ処理されていない）サブスクリプションを有する。「配信区分」は、所与の範囲の対象１０２の一部分に通知を配信、送信する役割を担う切り離されたリソースの集合である。配信トピックに送信される各イベントのコピーは、関連するサブスクリプションによって、同時に存在するように構成されたすべての配信区分が効率的に同時に利用することができ、配信ワークの並列化を可能にする。

[0028]区分化することによる並列化はタイムリーな配信を達成するのに役立つ。このことを理解するために、１０００万の対象１０２を有する範囲を考察する。対象のデータが区分化されていない記憶装置に保持された場合、システムは単一の大きなデータベースの結果の集合を順々に横断しなければならず、または、結果の集合が同じ記憶装置の区分化クエリを用いて取得された場合、対象データを取得するためのスループットは少なくとも所与の記憶装置が面するネットワークゲートウェイのインフラストラクチャのスループット上限によって抑えられ、その結果、所与の結果の集合において説明記録が生じるのが非常に遅い対象１０２への通知の送信の送信待ち時間が不満足なものとなる可能性が高い。

[0029]そうではなく、１０００万の対象１０２が、それぞれが１万の対象の記録を保持する１０００の記憶装置にわたって配信され、それらの記憶装置が、ここで説明されるような区分の形でクエリを実行し結果を処理する専用の計算インフラストラクチャ（本明細書で説明される「配信エンジン１２２」および「送信エンジン１０８」）と組み合わされた場合、対象の説明の取得は、計算およびネットワークリソースの広範な集合にわたって並列化されることができ、配信される最初のイベントから最後のイベントまで計測された、すべてのイベントの配信についての時間差を著しく短縮させる。

[0030]配信区分の実際の数は技術的には限定されない。単一の区分から２つ以上の任意の数の区分まで及ぶことができる。
[0031]図示された例において、配信区分１２０用の「配信エンジン１２２」がイベント１０４を取得すると、まずイベントデータの大きさを計算し、次にルーティングスリップ１２８の大きさを計算するが、これはイベントの大きさと、基本的なメッセージングシステムの許容される最大のメッセージの大きさと大きさの絶対上限とのうちの小さい方との差分に基づいて算出することができる。イベントは、「ルーティングスリップ」のデータのための最小限の余裕があるように大きさが限定される。

[0032]ルーティングスリップ１２８は、対象１０２の説明を含むリストである。ルーティングスリップは、区分の記憶装置１２４に保持された対象１０２に対するイベントの範囲に一致する検索クエリを実行することによって配信エンジン１２２により作成され、イベントの範囲に一致するすべての対象１０２と、イベントデータのフィルタリング条件に基づく選択を狭めるさらなる条件の集合とを返す。実施形態は、それらのフィルタリング条件の中に、結果を現時点で有効とみなされるそれらの対象１０２に限定する時間窓条件を含んでよく、つまり、現在のＵＴＣ時間が対象の説明記録に含まれる開始／終了有効性時間窓内にあることを意味する。この機能はブラックリストに載せるために用いられ、本書で後述される。検索結果が横断されると、エンジンはイベント１０４のコピーを作成し、記憶装置１２４から取り出された対象の説明でルーティングスリップ１２８を最大限の大きさまで満たし、結果として生じたイベントとルーティングスリップとのバンドルを区分の「送信キュー１３０」にエンキューする。

[0033]ルーティングスリップの技術は、配信エンジン１２２から送信エンジン１０８（複数可）へのイベントのイベントフロー速度が、基本的なインフラストラクチャ上の実際のメッセージフロー速度より速くなることを確実にし、つまり、たとえば３０の対象の説明がイベントデータと共にルーティングスリップ１２８にまとめられることができる場合、イベントと対象の組合せのフロー速度は、イベントと対象の組合せが直ちにメッセージにグループ化される場合より３０倍速いことを意味する。

[0034]送信エンジン１０８は、送信キュー１３０からのイベントとルーティングスリップのバンドル１２６のコンシューマである。送信エンジン１０８の役割はこれらのバンドルをデキューすることであり、また、イベント１０４をルーティングスリップ１２８に列挙されたすべての宛先に送信することである。送信は通常、イベントメッセージを各対象インフラストラクチャによって理解される通知メッセージのフォーマットにするアダプタを介して生じる。たとえば、通知メッセージは、ウィンドウズ（登録商標）７フォン用のＭＰＮＳフォーマット、ｉＯＳデバイス用のＡＰＮ（Ａｐｐｌｅ Ｐｕｓｈ Ｎｏｔｉｆｉｃａｔｉｏｎ）フォーマット、アンドロイドデバイス用のＣ２ＤＭ（Ｃｌｏｕｄ Ｔｏ Ｄｅｖｉｃｅ Ｍｅｓｓａｇｉｎｇ）フォーマット、デバイス上のブラウザ用のＪＳＯＮ（Ｊａｖａ Ｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）フォーマット、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などで送信されることができる。

[0035]送信エンジン１０８は通常、独立した対象１０２にわたる送信を並列化し、対象インフラストラクチャによって強制される範囲を共有する対象１０２への送信を直列化する。後者の例として、送信エンジンの特定のアダプタは、特定の通知プラットフォーム上の特定の対象アプリケーションにおいて対象とされたすべてのイベントを単一のネットワーク接続によって送信するよう選択することができる。

[0036]配信エンジン１２２と送信エンジン１０８とは送信キュー１３０を用いて分離されて、送信エンジン１０８の独立したスケーリングを可能にし、また、送信の後退が配信クエリ／パッキング段階に逆流したり配信クエリ／パッキング段階を遮断したりすることがないようにする。

[0037]配信区分１２０はそれぞれ、送信キュー１３０を同時に監視する任意の数の送信エンジン段階を有してよい。送信キュー１３０の長さは、いくつの送信エンジンが同時に活動するかを決定するために用いることができる。キューの長さがある一定の閾値を超える場合、新しい送信エンジンの段階が区分１２０に追加されて、送信スループットを増大させることができる。

[0038]配信区分１２０および関連する配信エンジンと送信エンジンの段階は、大きな規模で最適な並列化を達成するために、実質的には限定のない方式で拡大されることができる。対象インフラストラクチャが１００万のイベント要求を受信し並行した方式でデバイスに転送することができる場合、対象インフラストラクチャが負荷および所与の任意の送信割当の下で許可するのと同じくらいタイムリーに、すべての所望の対象１０２への送信のためのイベントサブミッションで対象インフラストラクチャを満たすことができる方法で、可能性としてはデータセンターにわたるネットワークインフラストラクチャおよびバンド幅を利用して、説明されたシステムはその送信インフラストラクチャにわたりイベントを配信することができる。

[0039]いくつかの実施形態においては、メッセージはそれぞれのインフラストラクチャのアダプタを介して対象１０２に送信されるので、システムはさまざまな統計情報項目に注目する。それらの中には、送信バンドルおよび任意の個々のメッセージの送信を受信することと実際の送信オペレーションの継続との間の継続の計測された期間がある。さらに、統計情報の一部は、送信が成功したか失敗したかに関する指標でもある。この情報は送信エンジン１０８の内部で収集され、範囲ごとおよび対象アプリケーションごとの平均値にロールアップされる。この「対象アプリケーション」は、統計ロールアップの特定の目的のために採用されるグループ化識別子である。計算された平均値は、確定された間隔で送信統計キュー１４６に送信される。このキューは、管理サービス１４２内でワーカー（またはワーカーの集合）によって排出され、管理サービス１４２はさまざまな目的のためにイベントデータをデータウェアハウスに提出する。これらの目的は、操作上の監視に加えて、イベントが送信されるテナントの序列および／または第三者自身の序列に関するテナントへの統計の開示を含んでよい。

[0040]送信エラーが検出されると、これらのエラーは一時的エラー状態と永続的エラー状態とに分類される。一時的エラー状態は、たとえば、システムが対象インフラストラクチャの送信点に到達することを許可しない、または対象インフラストラクチャが送信割当が一時的に到達したことを報告することを許可しない、というネットワークの障害を含んでよい。永続的エラー状態は、たとえば、対象インフラストラクチャに関する認証／承認エラー、または手動の介入がなければ修復することができない他のエラー、および対象インフラストラクチャが対象がもはや利用できないこと、または永続的な基礎でメッセージを受け取ることを望んでいないということを報告するエラー状態を含んでよい。分類されると、エラー報告は送信失敗キュー１４８に提出される。一時的エラー状態については、エラーは、エラー状態が解決されると予想されるまで絶対ＵＴＣタイムスタンプを含んでもよい。同時に、対象は、この送信エンジン段階による任意のさらなる局所的送信のための対象アダプタによって局所的にブラックリストに載せられる。ブラックリストは、タイムスタンプを含んでもよい。

[0041]送信失敗キュー１４８は、管理役割においてワーカー（またはワーカーの集合）によって排出される。永続的エラーは、管理役割がアクセスするそれぞれの配信区分の記憶装置１２４から各対象を即座に削除させることができる。「削除」は、記録が確かに取り除かれたこと、または代替的に、有効期間の「終了」タイムスタンプをエラーのタイムスタンプに設定することによって記録が単に検索クエリから見えないところに移動されることを意味することができる。一時的エラー状態は、エラーによって示される期間、対象を非活動化させることができる。非活動化は、対象の有効期間の開始を、エラー状態が修復されると予想されるエラーにおいて示されるタイムスタンプまで移動させることによって行うことができる。

[0042]次に図２を参照すると、代替の図が示される。既に示したとおり、実施形態は単一のイベントが複数の（多数の可能性がある）エンドユーザーに広がるメッセージファンアウトのシステムにおいて特に有用でありうる。図２には、そのような例が示される。図２は、多数の異なるソースからの情報が多数の異なる対象に送信される例を示す。いくつかの例において、単一のソースからの情報、または複数のソースから集約された情報が用いられて多数の対象に送信される単一のイベントを作成することができる。これは、いくつかの実施形態において、図２に示すファンアウトトポロジーを用いて達成されうる。

[0043]図２は、ソース１１６を示す。本明細書で後述されるように、実施形態は取得区分１４０を利用してよい。取得区分１４０はそれぞれ、多くのソース１１６を含んでよい。多数かつ多様なソース１１６である可能性もある。ソース１１６は情報を提供する。その情報は、たとえば、電子メール、テキストメッセージ、リアルタイムの株式相場、リアルタイムのスポーツスコア、ニュースの更新などを含んでよいが、これらに限定されない。

[0044]図２は、各区分が例示の取得エンジン１１８のような取得エンジンを含むことを示す。取得エンジン１１８はソース１１６から情報を収集し、その情報に基づいて、イベントを生成する。図２に示される例において、さまざまなソースを用いて取得エンジンによって生成されたものとして、多くのイベントが示される。例証のためにイベント１０４−１が用いられる。いくつかの実施形態では、本明細書でさらに解説されるように、イベント１０４−１は標準化されてもよい。取得エンジン１１８は、インターネットのようなネットワーク上のサービスであってよく、ネットワーク上でソース１１６から情報を収集する。

[0045]図２は、イベント１０４−１が配信トピック１４４に送信されることを示す。この配信トピック１４４は、多くの配信区分にイベントを広げる。配信区分１２０−１は、すべての配信区分のためのアナログとして用いられる。配信区分はそれぞれ、サブスクリプションによって表される多くのエンドユーザーまたはデバイスにサービスを提供する。配信区分によってサービスを提供されるサブスクリプションの数は、他の配信区分の場合の数と異なっていてよい。いくつかの実施形態では、区分によりサービスを提供されるサブスクリプションの数は、配信区分の容量によることができる。代替的または追加的に、配信区分は、エンドユーザーに論理的または地理的に近いことに基づいてユーザにサービスを提供するよう選択されてもよい。このことは、よりタイムリーな方式でエンドユーザーにアラートが送信されることを可能にする。

[0046]図示された例において、配信区分１２０−１は配信エンジン１２２−１を含む。配信エンジン１２２−１はデータベース１２４−１を参考にする。データベース１２４−１は、関連する送信対象１０２についての詳細を有するサブスクリプションについての情報を含む。特にデータベースは、対象１０２、対象１０２に使用されるアプリケーション、対象１０２のネットワークアドレス、対象１０２を用いるエンドユーザーのユーザ嗜好などのためのプラットフォームを説明する情報のような情報を含んでよい。データベース１２４−１の情報を用いて、配信エンジン１２２−１はバンドル１２６−１を構成し、ここでバンドル１２６−１はイベント１０４（または、少なくともイベント１０４からの情報）、および、イベント１０４−１からの情報が通知として送信される対象１０２の中から複数の対象１０２を識別するルーティングスリップ１２８−１を含む。次に、バンドル１２６−１はキュー１３０−１に配置される。

[0047]配信区分１２０−１は、多くの送信エンジンを含んでよい。送信エンジンは、キュー１０３−１からバンドルをデキューし、対象１０２に通知を送信する。たとえば、送信エンジン１０８−１は、キュー１３−１からバンドル１２６−１を取り出し、ルーティングスリップ１２８−１内で識別された対象１０２にイベント１０４の情報を送信することができる。したがって、イベント１０４−１の情報を含む通知１３４は、さまざまな配信区分から対象１０２に、異なる対象１０２に適し、また個々の対象１０２に特有の、多くの異なるフォーマットで送信されることができる。このことは、送信システムによって多数の個別化された通知を運搬するのではなく、個々の対象１０２に合わせて個別化された個別化通知１３４が送信システムの周辺部で共通のイベント１０４−１から作成されることを可能にする。

[0048]ここで以下の議論は、実行されうる多くの方法および方法の動作について言及する。方法の動作はある順序で説明され、または特定の順序で生じるとおりにフローチャートで図示されることができるが、動作は実行されている動作より前に完了された他の動作によって決まるため、特に述べられない限り、または要求されない限り、特定の順序付けを要するものではない。

[0049]次に図３を参照すると、方法３００が図示される。この方法は、コンピューティング環境で実施されてよい。方法は、メッセージコピーおよびメッセージ待ち時間を最小限にしうる方式で多数のイベントコンシューマにイベントを配信する動作を含む。方法は、イベントが特定のコンシューマの集合に送信されるべきであることを決定すること（動作３０２）を含む。たとえば、図２に示されるように、イベント１０４は１つまたは複数の対象１０２に送信される必要がありうる。

[0050]方法はさらに、イベントをコピーし、個々のコピーを複数の配信区分に提供すること（動作３０４）を含む。たとえば、図２に示されるように、イベントは、配信トピックで配信区分１２０−１および図示された他の配信区分のような多くの配信区分にコピーされる。

[0051]方法はさらに、各配信区分において、イベントのコピーを複数のルーティングスリップとまとめて複数の送信バンドルを作成すること（動作３０６）を含む。このルーティングスリップは、イベントの受信が意図される複数の個々のコンシューマを表すことができる。そのような送信バンドルの例は、図２の１２６−１で示される。

[0052]方法はさらに、ルーティングスリップで指定された個々のコンシューマにイベントを配信する送信バンドルを用いること（動作３０８）を含む。たとえば、図２に示されるように、送信エンジン１０８−１は、ルーティングスリップ１２８−１を用いてさまざまな対象１０２にイベント１０４を送信することができる。

[0053]方法３００のいくつかの実施形態は、区分が区分の容量に基づいて決定される場合に実施されてよい。たとえば、送信区分によってイベントが配信される対象の数は、システムハードウェア、ネットワーク接続、電流負荷などの要因によって定められる容量によって決定されてよい。

[0054]方法３００のいくつかの実施形態は、区分が場所によって決定される場合に実施されてよい。たとえば、区分１２０−１のような区分は、区分に地理的または論理的にごく接近した対象が割り当てられてよい。

[0055]方法３００のいくつかの実施形態は、ルーティングスリップが個々のコンシューマにイベントを送信する方法について規則および制約を定める場合に実施されてよい。たとえば、ルーティングスリップは、コンシューマの特定のフィルタを含んでよい。一例において、コンシューマ（すなわち対象ユーザ）は、どのようなタイプのイベントを受け取り、または受け取らないかについての嗜好を定めてよい。この情報は、イベントを送信するか否かの決定を送信エンジンによって送信システムの周辺で行えるように、ルーティングスリップに含まれることができる。

[0056]代替または追加の実施形態では、ルーティングスリップは、ネットワーク位置の規則を定めることができる。たとえば、ルーティングスリップは特定の対象に達するネットワークパスを含んでよい。

[0057]代替または追加の実施形態では、ルーティングスリップは、セキュリティ資格情報を含んでよい。たとえば、セキュリティ資格は送信されるイベントに必要であるとしてよい。特に、イベントデータを提供するサーバと通信するときに、デバイス上のアプリケーションはセキュリティプロトコル情報を要求することができる。このセキュリティプロトコル情報は送信エンジン１０８−１によって含まれて、イベントが適切に送信されることを確実にすることができる。

[0058]代替または追加の実施形態では、ルーティングスリップは、未加工のイベントデータをコンシューマによって要求されるフォーマットにマッピングする規則を含んでよい。たとえば、イベントは一般形式であってよいが、ルーティングスリップは対象のためのプラットフォームを定めることができる。このことは、対象にイベントを送信する前に、送信エンジン１０８−１が、イベント１０４を定められたプラットフォームに適した特定のフォーマットにフォーマットすることができるようにする。

[0059]方法は、１つまたは複数のプロセッサおよびコンピュータメモリのようなコンピュータ読取可能媒体を含むコンピュータシステムによって実施されてよい。特に、コンピュータメモリは、１つまたは複数のプロセッサによって実行されるとき、実施形態に列挙される動作のようなさまざまな機能を実行させるコンピュータ実行可能命令を記憶することができる。

[0060]本発明の実施形態は、以下でより詳細に議論されるように、コンピュータハードウェアを含む特殊目的または汎用のコンピュータを備え、または利用してよい。本発明の範囲内の実施形態はまた、コンピュータ実行可能命令および／もしくはデータ構造を運搬し、または記憶する物理的および他のコンピュータ読取可能媒体を含む。このようなコンピュータ読取可能媒体は、汎用または特殊目的のコンピュータシステムによりアクセス可能な任意の利用可能な媒体でありうる。コンピュータ実行可能命令を記憶するコンピュータ読取可能媒体は、物理的ストレージ媒体である。コンピュータ実行可能命令を運搬するコンピュータ読取可能媒体は、伝送媒体である。したがって、限定ではなく例として、本発明の実施形態は、少なくとも２つの明らかに異なる種類のコンピュータ読取可能媒体、すなわち物理的コンピュータ読取可能ストレージ媒体と伝送コンピュータ読取可能媒体とを備えることができる。

[0061]物理的コンピュータ読取可能ストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスクストレージ（ＣＤ、ＤＶＤなど）、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または、コンピュータ実行可能命令もしくはデータ構造の形で所望のプログラムコード手段を記憶するために用いることができ、汎用または特殊目的のコンピュータによってアクセス可能な任意の他の媒体を含む。

[0062]「ネットワーク」は、コンピュータシステムおよび／またはモジュールおよび／または他の電子デバイスの間で電子データの移送を可能にする１つまたは複数のデータリンクと定義される。ネットワークまたは他の通信接続（有線、無線、または有線もしくは無線の組合せのいずれか）によって情報がコンピュータに転送または提供されるとき、コンピュータは接続を伝送媒体として適切にみなす。伝送媒体は、コンピュータ実行可能命令またはデータ構造の形で所望のプログラムコード手段を運搬するために用いることができ、汎用または特殊目的のコンピュータによってアクセスされうるネットワークおよび／またはデータリンクを含むことができる。上記の組合せもまた、コンピュータ読取可能媒体の範囲に含まれる。

[0063]さらに、さまざまなコンピュータシステムの構成要素に到達すると、コンピュータ実行可能命令またはデータ構造の形のプログラムコード手段は、伝送コンピュータ読取可能媒体から物理的コンピュータ読取可能ストレージ媒体に（または逆に）自動的に転送されうる。たとえば、ネットワークまたはデータリンクによって受信されたコンピュータ実行可能命令またはデータ構造は、ネットワークインターフェースモジュール（たとえば「ＮＩＣ」）内のＲＡＭにバッファリングされることができ、最終的にコンピュータシステムのＲＡＭおよび／またはコンピュータシステムのより揮発性の低いコンピュータ読取可能の物理的ストレージ媒体に転送される。したがって、コンピュータ読取可能の物理的ストレージ媒体は、伝送媒体を同様に（または主として）利用するコンピュータシステムの構成要素に含まれうる。

[0064]コンピュータ実行可能命令は、たとえば、汎用のコンピュータ、特殊目的のコンピュータまたは特殊目的の処理デバイスに、ある機能または機能群を実行させる命令およびデータを含む。このコンピュータ実行可能命令は、たとえば、バイナリ、アセンブリ言語などの中間フォーマットの命令、さらにはソースコードであってもよい。内容は構造的特徴および／または方法論的動作に特有の言語で説明されるが、添付の特許請求の範囲で明確にされる内容は必ずしも上述の特徴または上記の動作に限定されるものではないことを理解されたい。むしろ、述べられた特徴および動作は特許請求の範囲を実施する例示の形態として開示される。

[0065]本発明は、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、メッセージプロセッサ、携帯デバイス、マルチプロセッサシステム、マイクロプロセッサ型またはプログラム可能な家庭用電化製品、ネットワークＰＣ、小型コンピュータ、メインフレームコンピュータ、携帯電話、ＰＤＡ、ポケットベル、ルータ、スウィッチなどを含む多種のコンピュータシステム構成を備えるネットワークコンピューティング環境において実施できることが、当業者には十分に理解されるであろう。本発明はまた、ネットワークによってリンクされている（有線データリンク、無線データリンク、または有線データリンクと無線データリンクとの組合せのいずれかによる）ローカルコンピュータシステムとリモートコンピュータシステムとがいずれもタスクを実行する分散型のシステム環境において実施されてもよい。分散型のシステム環境においては、プログラムモジュールは、ローカルメモリストレージデバイスおよびリモートメモリストレージデバイスのいずれにも配置することができる。

[0066]本発明は、その精神または特性から逸脱することなく他の特定の形態で実施されてよい。述べられた実施形態は、あらゆる点で単に例示的なものであって限定的なものではないとみなされるべきである。したがって、本発明の範囲は、上述の説明によるのではなく添付の特許請求の範囲によって示される。特許請求の範囲と同等の意味および範囲内で生じる変更はすべて、その範囲内に包含されるべきものである。

Claims (7)

1. コンピューティング環境において、メッセージコピーおよびメッセージ待ち時間を最小限にすることができる方式(fashion)で多数のイベントコンシューマ(event consumers)にイベントを配信する方法であって、
   イベントが特定のコンシューマの集合(set)に送信されるべきかを決定するステップと、
   前記イベントをコピーし、個々のコピーを複数の配信区分(distribution partitions)に提供するステップと、
   前記配信区分のそれぞれにおいて前記イベントのコピーを複数のルーティングスリップ(routing slips)とまとめて複数の送信バンドル(delivery bundles)を作成するステップであって、前記ルーティングスリップは前記イベントの受信が意図される複数の個々の(individual)コンシューマを表す、ステップと、
   前記ルーティングスリップで指定された個々のコンシューマに前記イベントを配信する(distributing)前記送信バンドルを用いるステップと、
   を備える方法。
2. 前記配信区分は配信区分の容量に基づいて決定される、請求項１に記載の方法。
3. 前記区分(partitions)は場所(locale)によって決定される、請求項１に記載の方法。
4. 前記ルーティングスリップは個々のコンシューマに前記イベントを送信する方法について規則(rules)および制約(constraints)を定める、請求項１に記載の方法。
5. 前記制約はユーザ嗜好(preferences)を定め、前記ルーティングスリップで指定された個々のコンシューマに前記イベントを配信する前記送信バンドルを用いるステップは、前記ルーティングスリップの前記ユーザ嗜好に基づいてイベントを送信するか否かを決定するステップを備える、請求項４に記載の方法。
6. 前記制約は、未加工のイベントデータ(raw event data)を個々の(individual)コンシューマデバイス用のプラットフォーム特定(platform specific)フォーマットにマッピングする(map)規則を定める、請求項４に記載の方法。
7. 前記ルーティングスリップはセキュリティ資格(credential)情報を備える、請求項１に記載の方法。

Images