JP2014528126A

JP2014528126A - 複数のターゲットへのマルチソースプッシュ通知の分配

Info

Publication number: JP2014528126A
Application number: JP2014529930A
Authority: JP
Inventors: ヴァスターズ，クレメンス・フリードリッチ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2011-09-12
Filing date: 2012-09-10
Publication date: 2014-10-23
Also published as: WO2013039798A2; EP2756475A2; EP2756475A4; US20130067024A1; CN103051667A; CN103051667B; WO2013039798A3; KR20140072044A

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]ＯＤａｔａなどの複雑構造化データを運ぶ拡張子は、基礎的イベントモデルを複雑化することなく、複合タイプ構造およびデータを保存するマッピングモデルを実施することができる。いくつかの実施形態は、ＪＳＯＮなどの正準およびコンパクト複合データ表示に正規化し、例えば、複合データタイプ「人」のＯＤａｔａプロパティ「テナント」をキー／値対にマッピングし、キーはプロパティ名「テナント」であり、値はＪＳＯＮ直列化された形で示された名前、経歴情報、および住所情報を有する人を説明する複合データである。データソースがＸＭＬドキュメントである場合、ＲＳＳまたはＡｔｏｍの場合と同様に、値は、ＸＭＬデータをＸＭＬによって提供された構造を保存するＪＳＯＮに転写するが、属性および要素などのＸＭＬ特殊性を平坦化することによって作り出すことができ、同じＸＭＬ要素ノードのＸＭＬ属性および要素の下位概念であるＸＭＬ属性および要素は両方とも、別の区別がない「きょうだい（siblings）」としてＪＳＯＮプロパティにマッピングされる。

[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]ルーティングスリップ１２８は、ターゲット１０２の記述を含むリストである。ルーティングスリップは、イベントの範囲をパーティションのストア１２４内に保持されたターゲット１０２に対して一致させる検索クエリーを行ない、イベントの範囲、およびイベントデータに関するフィルタリング条件に基づく選択を狭める別の条件の集合に一致する全てのターゲット１０２を返すことによって、分配エンジン１２２により作り出される。実施形態は、これらのフィルタ条件の中で、現在の瞬間に有効であると考えられるこれらのターゲット１０２に結果を制限する時間ウィンドウ条件を含むことができる、これは、現在のＵＴＣ時間はターゲット記述記録に含まれた開始／終了有効性時間ウィンドウ内にあるということを意味する。この能力は、本文書でのちに記載するブラックリスト化に使用される。検索結果が詳しく検討されると、エンジンはイベント１０４のコピーを作り出し、ルーティングスリップ１２８を最大のサイズまで、ストア１２４から取り出したターゲット記述で満たし、その後、イベントおよびルーティングスリップの得られたバンドルをパーティションの「配信キュー１３０」に加える。

[0067]ルーティングスリップ技術は、分配エンジン１２２から（１つまたは複数の）配信エンジン１０８までのイベントのイベント流速が、根本的なインフラ上の実際のメッセージ流量より高いことを保証し、これは例えば、３０個のターゲット記述をイベントデータのそばでルーティングスリップ１２８内に詰めることができる場合に、イベント／ターゲット対の流速は、イベント／ターゲット対が直ぐにメッセージにグループ化された場合よりも３０倍高いということを意味する。

[0068]配信エンジン１０８は、配信キュー１３０からのイベント／ルーティングスリップバンドル１２６の消費者である。配信エンジン１０８の役割は、これらのバンドルをキューから取り除き、イベント１０４をルーティングスリップ１２８内に挙げられた全ての宛先に配信することである。配信は普通、イベントメッセージをそれぞれのターゲットインフラによって理解される通知メッセージに形式化するアダプタを通して起こる。例えば、通知メッセージは、ウィンドウズ（登録商標）７フォン用のＭＰＮＳフォーマット、ｉＯＳデバイス用のＡＰＮ（アップルプッシュ通知）フォーマット、アンドロイドデバイス用のＣ２ＤＭ（クラウドツーデバイスメッセージング）フォーマット、デバイス上のブラウザ用のＪＳＯＮ（ジャバスクリプトオブジェクトノーテーション）フォーマット、ＨＴＴＰ（ハイパーテキスト転送プロトコル）などで配信することができる。

[0069]配信エンジン１０８は普通、独立したターゲット１０２にわたる配信を並列化し、ターゲットインフラによって実施される範囲を共有するターゲット１０２への配信を直列化する。後者の例は、配信エンジン内の特定のアダプタが、単一のネットワーク接続を通して特定の通知プラットフォーム上の特定のターゲットアプリケーションでターゲット化された全てのイベントを送信することを選択することができるということである。

[0070]分配および配信エンジン１２２および１０８は、配信キュー１３０を使用して切り離されて、配信エンジン１０８の独自のスケーリングが可能になり、配信が減速されるのを防ぎ、分配クエリー／パッキングステージをブロックする。

[0071]各分配パーティション１２０は、配信キュー１３０を同時に観察するあらゆる数の配信エンジン例を有することができる。配信キュー１３０の長さを使用して、いくつの配信エンジンが同時にアクティブであるかを判断することができる。キューの長さが特定の閾値と交差する場合、新しい配信エンジン例がパーティション１２０に加えられて、送信スループットを大きくすることができる。

[0072]分配パーティション１２０、および関連する分配および配信エンジン例を、高いスケールでの最適な並列化を達成するために、実質的に無制限の方法でスケールアップさせることができる。ターゲットインフラが、並列の方法でデバイスに１００万のイベント要求を受信および転送することが可能である場合、記載されたシステムは、その配信インフラにわたってイベントを分配することが可能である、潜在的には、ターゲットインフラに負荷がかけられ、あらゆる許可された配信割当が与えられるのを可能にするのと同じだけタイムリーに、全ての所望のターゲット１０２への配信のためのイベント提示でターゲットインフラを飽和させることができる方法で、データセンタにわたってネットワークインフラおよび帯域幅を利用することが可能である。

[0073]メッセージがそれぞれのインフラアダプタを介してターゲット１０２に配信されると、いくつかの実施形態では、システムは統計情報アイテムの範囲に注意する。これらの中で、配信バンドルの受け取りと、あらゆる個別のメッセージの配信の間の継続時間、および実際の送信動作の継続時間に対する期間が測定される。また、統計情報の一部は、配信が成功したか失敗したかに関する指標である。この情報は、配信エンジン１０８内で収集され、範囲毎およびターゲットアプリケーション毎に、平均値に丸められる。「ターゲットアプリケーション」は、統計ロールアップの特定の目的で導入されたグループ化識別子である。計算された平均値は、規定のインターバルで配信統計キュー１４６に送信される。このキューは、ある範囲の目的でデータ倉庫にイベントデータを提示する、管理サービス１４２内の労働者（の集合）によって流出される。これらの目的は、操作監視に加えて、イベントが配信されるテナントの請求、および／または第三者の独自の請求に対するテナントへの統計の開示を含むことができる。

[0074]配信エラーが検出されると、これらのエラーは一時的および永久的エラー状態に分類される。一時的エラー状態としては、例えば、システムがターゲットインフラの配信ポイントに到達することができないネットワーク故障、または配信割当に一時的に到達したことを報告するターゲットインフラを挙げることができる。永久的エラー状態としては、例えば、ターゲットインフラ上の認証／許可エラー、またはターゲットがもはや利用可能ではないまたは永久的にメッセージを受けたくないということをターゲットインフラが報告する人的介入およびエラー状態なしで直すことができない他のエラーを挙げることができる。いったん分類されると、エラーレポートが配信失敗キュー１４８に提示される。一時的エラー状態では、エラーはまた、エラー状態が解決されることが予測されるまで、絶対ＵＴＣタイムスタンプを含むことができる。同時に、ターゲットは、この配信エンジン例によってあらゆるさらなるローカル配信に対するターゲットアダプタにより局所的にブラックリスト化される。ブラックリストはまた、タイムスタンプを含むことができる。

[0075]配信失敗キュー１４８は、管理役割で労働者（の集合）によって流出される。永久的エラーは、それぞれのターゲットを、管理役割がアクセスを有するそれぞれの分配パーティションストア１２４から直ぐに削除させる可能性がある。「削除」とは、記録が実際に取り除かれる、または別の方法では、規則がその有効期間の「終了」タイムスタンプをエラーのタイムスタンプに設定することによって、検索クエリーから見えないように単に移動されることを意味することがある。一時的エラー状態は、エラーによって示された期間だけターゲットを停止させる可能性がある。停止は、エラー状態が直ると予測される、エラーに示されたタイムスタンプまでターゲットの有効性期間を移動させることによって行なうことができる。

[0076]図５は、取得パーティション１４０が分配トピック１４４を通して分配パーティション１２０に結合されるシステムの概略図を示す。
[0077]前に記したように、いくつかの実施形態では、全体的なイベント１０４をソース１１６からの情報から作り出すことができる。全体的なイベントは、後に、データを識別し、プラットフォーム特定フォーマットに置くことができるような、全体的なフォーマットである可能性がある。次に、特定のプラットフォーム通知へ、一実施形態で実施された全体的なイベントプロパティをマッピングすることができる、式の多くの例を以下に示す。

[0078]＄（ｎａｍｅ）ｏｒ．（ｎａｍｅ）ｏｒ＞（ｎａｍｅ）所与の名前を有するイベントプロパティへの参照。プロパティ名は大文字と小文字を区別しない。プロパティ名は、参照されたプロパティの値がＪＳＯＮストリング文字列式の形で複合タイプデータを含む場合に、「ドット」式（例えば、プロパティアイテム）である可能性がある。この式は、プロパティのテキスト値、またはプロパティが存在しない場合には空の文字列に分解する。値は、ターゲットフィールドに対するターゲットのサイズ制約によってクリッピングされる可能性がある。

[0079]＄（ｎａｍｅ，ｎ）、上記のとおりであるが、テキストはｎ文字で明確にクリッピングされる。例えば、＄（ｔｉｔｌｅ，２０）は、２０文字でタイトルプロパティの内容をクリッピングする。

[0080]．（ｎａｍｅ，ｎ）、上記のとおりであるが、テキストはクリッピングされているので３ドットで接尾辞が付けられる。クリッピングされた文字列および接尾辞の合計サイズは、ｎ文字を超えない。「これはタイトル行です」の入力プロパティを有する．（ｔｉｔｌｅ，２０）は、「これは、・・・タイトルである」という結果になる。

[0081]％（ｎａｍｅ）、＄（ｎａｍｅ）と同様であるが、出力が符号化されたＵＲＩであることを除く。
[0082]＄ｂｏｄｙは、イベントのエンティティ本体のことを言う。エンティティ本体は、バイナリデータを含む任意のデータを含むことができ、現状のままでシステムを通過させることができるので、クリッピング可能ではない。＄ｂｏｄｙがターゲット上のテキストプロパティにマッピングされると、いくつかの実施形態では、本体がテキストの内容を含んでいる場合に、マッピングが成功するだけである。エンティティ本体が空である場合、式は空の文字列に分解される。

[0083]＄ｃｏｕｎｔは、所与のソースから配信されたイベントのターゲット毎のカウントのことを言う。この式は、このカウンタのリセットを最後に要求してから、このソース１１６からいくつのメッセージをそれぞれのターゲットが受信したかを示すシステムによって計算された数に分解する。いくつかの例示的な実施形態では、この数は０から９９の範囲を有する。カウンタが９９に到達すると、さらには値が増えない。この値は普通、バッジおよびタイルカウンタに使用される。

[0084]‘［．．ｔｅｘｔ．．．］’または“［．．ｔｅｘｔ．．．］”は、リテラルである。リテラルは、一重または二重引用符内に囲まれた任意のテキストを含む。テキストは、ＪａｖａＳｃｒｉｐｔエスケープ規則にしたがってエスケープの形で特殊な文字を含むことができる（EＣＭＡ−２６２、７．８．４を参照のこと）。ｅｘｐｒ１＋ｅｘｐｒ２は、単一文字列へ２つの式を結合させる連結演算子である。式は、上記のいずれかである可能性がある。

[0085]ｅｘｐｒ１？？ｅｘｐｒ２は、ゼロまたはゼロ長さ文字列でない場合に、ｅｘｐｒ１の値を求め、それ以外の場合にｅｘｐｒ２の値を求める条件演算子である。？？演算子は、＋演算子より高い優先順位を有する、すなわち、式‘ｐ’＋＄（ａ）？？＄（ｂ）は、リテラル‘ｐ’の接頭辞を付けたａまたはｂの値を生じる。

[0086]実施形態は、イベント１０４からプロパティを取るためにマッピング言語を使用し、これらをターゲット１０２上での通知のために正しい位置にマッピングすることができる。

[0087]ウィンドウズフォン用のタイル通知はまた、カウントを自動的に記録する＄ｃｏｕｎｔプロパティを利用することができる。

[0088]ｉＰａｄアプリでは、実施形態は以下に示すようにこれを警告にマッピングすることができる。

[0089]または、単にアプリアイコン上のバッジ（カウンタ）だけである。

[0090]いくつかの実施形態では、これらのマッピングに対するデフォルトは、各ターゲットプロパティが同じ名前を有する入力プロパティにマッピングされるということである。実施形態はしたがって、これと同じだけ簡潔にウィンドウズ（登録商標）フォンに対するターゲットを特定することができる。

また、Ｔｅｘｔ１、Ｔｅｘｔ２およびＰａｒａｍは、入力イベント上で同じ名前を有するメッセージプロパティから自動的にマッピングされ、このようなプロパティがない場合には空になる（送信されない）。これにより、ウィンドウズアジュール（商標）サービスバスキューおよびトピック加入が普通そうであるのと同様に、ソース１１６が開発制御下にある場合のプロパティの完全なソースサイド制御が可能になる。

[0091]グーグルアンドロイドでは、Ｃ２ＤＭサービスは通知用の固定フォーマットを定義せず、アンドロイドユーザインターフェイスシェル内への直近の関係がないので、マッピングはいくらか異なり、それによってマッピングは、ターゲットプロパティをキーとして、式を値として有する自由形式のプロパティバッグの形をとる。プロパティマップが省略された場合、全ての入力プロパティは、Ｃ２ＤＭエンドポイントに真っ直ぐにマッピングされる。

[0092]
選択通知分配
本明細書に記載された実施形態は、放送システム内の通知ターゲット１０２が、地理的、人口統計的、または他の基準に基づいて、ターゲットへのイベントストリームからのイベントの選択分配を可能にする基準を提供するイベントストリームに加入することを可能にする機能を実施することができる。

[0093]特に、イベントデータは、様々なカテゴリー化データを有することができる。例えば、イベントにジオタグを付けることができる。別の方法では、イベントは、イベント用のカテゴリー文字列を含めることなどによって、ソースによりカテゴリー化することができる。

[0094]再び図１を参照すると、様々な図を参照して上に記載したように、イベント１０４は、様々なタイプのカテゴリー化データを含むことができる。例えば、イベントは、地理的座標が警告内に含まれたジオタグを含むことができる。分配エンジン１２２−１は、ジオタグ付けされたデータを見つけるためにイベントを調べることができる。分配エンジン１２２−１はまた、ジオタグを有するデータに興味があるターゲット１０２を判断するために、データベース１２４−１を調べることができる。例えば、ユーザは、その位置、または全体的な位置を特定することができる。ユーザは、その位置に関連する、またはその位置から８．０４５キロ（５マイル）以内のあらゆる警告をユーザに運ぶべきであることを特定することができる。分配エンジン１２２−１は、データ内のジオタグがこの仕様内に含まれるかどうかを判断することができる。そうである場合には、その後、分配エンジン１２２−１は、イベント１０４に対してルーティングスリップ１２８−１内のその特定のユーザを含むことができる。そうでなければ、ユーザをルーティングスリップから除外することができ、警告１０４を有する通知を受信しない。

[0095]ジオタグ付けされたイベントでは、ユーザ（または、ユーザへの他のエンティティ制御通知およびイベント配信）は、多くの異なる境界のいずれかを特定することができる。例えば、所与の位置の８．０４５キロ（５マイル）以内のあらゆる位置を特定することにより、基本的に、ポイント、およびそのポイントの周りの円を特定する。しかし、他の実施形態は、市、州、国、または大陸などの地政学的境界の仕様、建物または複合施設の形などを含むことができる。ワシントン州レッドモンドのマイクロソフトコーポレーションからのＳＱＬサーバ（登録商標）は、イベントを配信するためにターゲット１０２を判断するように、分配パーティション１２０−１の一部として使用することができる地理空間的機能を有する。

[0096]一般的に、イベントデータは、カテゴリー化情報を含むことができる。例えば、イベントに含まれる文字列は、イベントデータをカテゴリー化することができる。ルーティングスリップ１２８−１内にターゲットを含むことは、カテゴリー内を選ぶ、またはカテゴリーから選ばないユーザに基づくことがある。例えば、ターゲット１０２−１は、カテゴリーを選択することができ、カテゴリー化文字列をイベント１０４−１上で比較することができる。イベント１０４−１が選択されたカテゴリーを示す文字列を含む場合、その後、ターゲット１０２−１は、イベント１０４−１からのデータを有する通知がターゲット１０２−１に運ばれるように、バンドル１２６−１のルーティングスリップ１２８−１内に含められる。

[0097]
バッジカウンタ
記載したいくつかの実施形態により、個別のカウンタを、各エンドユーザに対するカウンタの個別の追跡を必要とすることなく、イベント放送システム内で追跡することが可能になる。これは、一連のイベントを受信するサーバによって達成することができ、一連の中の各イベントはタイムスタンプのリストに関連している。各イベント用のタイムスタンプのリストは、イベント用のタイムスタンプ、および一連の中の全ての前のイベント用のタイムスタンプを含む。

[0098]ユーザは、タイムスタンプをサーバに送信する。タイムスタンプは、ユーザがユーザデバイスでいくつかのユーザ相互作用をいつ行ったかの指標である。例えば、タイムスタンプは、ユーザがユーザデバイス上のアプリケーションをいつ開いたかの指標である可能性もある。サーバは、ユーザによって送信されるタイムスタンプを、ユーザに送信されようとしているイベント用のタイムスタンプのリストと比較する。サーバは、ユーザがタイムスタンプを送信した後に起こるユーザに送信されようとしているイベント用のタイムスタンプのリスト内のタイムスタンプの数をカウントし、このカウントをバッジカウンタとして送信する。

[0099]一例が、ここに添付された図６に示される。図６は、ターゲット１０２−１を示す。ターゲット１０２−１は、配信エンジン１０８−１からイベント１０４およびバッジカウンタ１０６を受信する。ターゲット１０２−１は、タイムスタンプ１１０を配信エンジン１０８−１に送信する。ターゲット１０２−１によって配信エンジン１０８−１に送信されたタイムスタンプ１１０は、ターゲット１０２−１でのいくつかのアクションに基づくことができる。例えば、ユーザは、配信エンジン１０８−１によってターゲット１０２−１に送信されるイベント１０４およびバッジカウンタ１０６に関連するアプリケーションを開くことができる。アプリケーションを開くことにより、タイムスタンプ１１０を、アプリケーションが開かれたときを示す配信エンジン１０８−１に対してターゲット１０２−１から放出させることができる。

[00100]配信エンジン１０８−１は、一連のイベント１１２（１０４−１、１０４−２、１０４−３、および１０４−ｎとして示される）を受信する。一連のイベント１１２内の各イベントは、タイムスタンプのリスト１１４−１、１１４−２、１１４−３、または１１４−ｎそれぞれに関連している。タイムスタンプの各リストは、現在のイベント用のタイムスタンプ、および現在のイベントの前の一連の中の各イベント用のタイムスタンプを含む。示した例では、イベント１０４−１は、ターゲット１０２への配信のための配信エンジン１０８−１に送信される第１のイベントである。したがって、イベント１０４−１に関連するリスト１１４−１は、イベント１０４−１が配信エンジン１０８−１に送信された時間に対応する単一エントリＴ１を含む。イベント１０４−２は、イベント１０４−１の後に配信エンジン１０８−１に送信され、したがって、イベント１０４−１および１０４−２がそれぞれ配信エンジン１０８−１に送信されたときに対応する時間スタンプＴ１およびＴ２を含むリスト１１４−２に関連している。イベント１０４−３は、イベント１０４−２の後に配信エンジン１０８−１に送信され、したがって、イベント１０４−１、１０４−２および１０４−３がそれぞれ配信エンジン１０８−１に送信されるときに対応するタイムスタンプＴ１、Ｔ２およびＴ３を含むリスト１１４−３に関連している。イベント１０４−ｎは、イベント１０４−３（および、推定上リスト１１４−ｎ内の楕円によって示されるような多くの他のイベント）の後に配信エンジン１０８−１に送信され、したがって、イベント１０４−１、１０４−２、１０４−３から１０４−ｎまでがそれぞれ配信エンジン１０８−１に送信されたときに対応する時間スタンプＴ１、Ｔ２、Ｔ３からＴｎまでを含むリスト１１４−ｎに関連している。

[00101]ターゲット１０２−１が、配信エンジン１０８−１にいかなるタイムスタンプ１１０も送信していないと仮定する。配信エンジンがイベント１０４−１を送信する場合、また、Ｔ１に対応する、１の値を有するバッジカウンタを送信する。配信エンジンがイベント１０４−２を送信する場合、また、タイムスタンプＴ１およびＴ２のカウントに対応する、２の値を有するバッジカウンタを送信する。配信エンジンがイベント１０４−３を送信する場合、また、タイムスタンプＴ１、Ｔ２およびＴ３に対応する、３の値を有するバッジカウンタを送信する。配信エンジンがイベント１０４−ｎを送信する場合、また、ｎのタイムスタンプＴ１からＴｎまでに対応する、ｎの値を有するバッジカウンタを送信する。

[00102]次に、ターゲットがタイムＴ２とＴ３の間に起こる絶対的時間を有するタイムスタンプ１１０を送信すると仮定する。推定上このポイントでは、イベント１０４−１および１０４−２は既に、ターゲット１０２−１に運ばれている。イベント１０４−３がターゲットに送信されると、配信エンジン１０８−１は、バッジカウンタの値を判断する場合に、タイムスタンプ１１０の後に起こるタイムスタンプをカウントするだけである。したがって、このシナリオでは、配信エンジン１０８−１は、イベント１０４−３と共に、（タイムスタンプ１１０の前にイベントＴ１およびＴ２が起こったときに）Ｔ３に対応する、１のバッジカウンタを送信する。このプロセスは、バッジカウンタ値を判断するために使用されているターゲット１０２−１から受信された最新のタイムスタンプ１１０で繰り返すことができる。

[00103]以下の議論は次に、行なうことができるいくつかの方法および方法活動のことに言及する。方法活動を、特定の順序で議論する、または特定の順序で起こるようなフローチャートで図示することができるが、特に記されていない限り特定の順序は必要ない、または活動は行なわれている活動の前に完了している別の活動に左右されるので必要ない。

[00104]次に図７を参照すると、方法７００が図示されている。この方法は、イベントを消費者に配信する活動を含む。方法７００は、所有権データにアクセスするステップ（活動７０２）を含む。例えば、各ソース１１６は、異なるソース１１６に特定である所有権フォーマットでデータを提供することができる。

[00105]方法７００はさらに、所有権データを正規化して正規化イベントを作り出すステップ（活動７０４）を含む。例えば、上に例示したように、イベント１０４は、異なるソース１１６からの所有権データを正規化することによって正規化させることができる。

[00106]方法７００はさらに、加入に基づいて、イベントを受信するべきである複数の末端消費者を判断するステップ（活動７０６）を含む。例えば、図２に示すように、分配エンジン１２２−１は、ターゲット１０２でのどのようユーザが加入したのかを判断するためにデータベース１２４−１を調べることができる。

[00107]方法７００はさらに、判断された末端消費者全てに適当な複数の異なるフォーマットに正規化イベントからのデータを形式化するステップ（活動７０８）を含む。例えば、図１に示すように、正規化イベントを、様々なターゲット１０２に適当なフォーマットに特に形式化させることができる。

[00108]方法７００はさらに、末端消費者に適当なフォーマットで、複数の末端消費者それぞれに正規化イベントからのデータを配信するステップ（活動７１０）を含む。
[00109]さらに、方法は、１つまたは複数のプロセッサ、およびコンピュータメモリなどのコンピュータ読取可能媒体を含むコンピュータシステムによって実施させることができる。特に、コンピュータメモリは、実施形態で言及した活動などの、１つまたは複数のプロセッサによって実行される場合に様々な機能を行なわせるコンピュータ実行可能指示を記憶することができる。

[00110]本発明の実施形態は、以下により詳細に論じるように、コンピュータハードウェアを含む専用または汎用コンピュータを備える、または利用することができる。本発明の範囲内の実施形態はまた、コンピュータ実行可能指示および／またはデータ構造を担持または記憶するための物理的または他のコンピュータ読取可能媒体を含む。このようなコンピュータ読取可能媒体は、汎用または専用コンピュータシステムによってアクセスすることができるあらゆる市販の媒体であってもよい。コンピュータ実行可能指示を記憶するコンピュータ読取可能媒体は、物理的記憶媒体である。コンピュータ実行可能指示を担持するコンピュータ読取可能媒体は、伝達媒体である。したがって、限定ではなく例として、本発明の実施形態は、少なくとも２つの個別の異なる種類のコンピュータ読取可能媒体、物理的コンピュータ読取可能記憶媒体および伝達コンピュータ読取可能媒体を備えることができる。

[00111]物理的コンピュータ読取可能記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光学ディスク記憶装置（ＣＤ、ＤＶＤなど）、磁気ディスク記憶装置または他の磁気記憶デバイス、またはコンピュータ実行可能指示またはデータ構造の形の所望のプログラムコード手段を記憶するのに使用することができ、汎用または専用コンピュータによってアクセスすることが可能なあらゆる他の媒体が挙げられる。

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

[00113]さらに、様々なコンピュータシステム構成部品に到達する際に、コンピュータ実行可能指示またはデータ構造の形のプログラムコード手段は、伝達コンピュータ読取可能媒体から物理的コンピュータ読取可能記憶媒体に伝達させることができる（または、逆も同様である）。例えば、ネットワークまたはデータリンク上で受信されたコンピュータ実行可能指示またはデータ構造は、ネットワークインターフェイスモジュール（例えば、「ＮＩＣ」）内でＲＡＭにバッファリングさせ、その後、コンピュータシステムでコンピュータシステムＲＡＭおよび／または揮発性が低いコンピュータ読取可能物理的記憶媒体に次第に伝達させることができる。したがって、コンピュータ読取可能物理的記憶媒体は、また（または、一次的にでさえも）伝達媒体を利用するコンピュータシステム構成部品内に含めることができる。

[00114]コンピュータ実行可能指示は、例えば、汎用コンピュータ、専用コンピュータ、または専用処理デバイスに特定の機能または機能のグループを行なわせる指示およびデータを含む。コンピュータ実行可能指示は例えば、アセンブリ言語、またはさらにはソースコードなどのバイナリ、中間フォーマット指示であってもよい。主体を構造的特性および／または方法的活動に特有の言語で記載したが、添付の特許請求の範囲で定義された主題は、上に記載した特性または活動に必ずしも限定されるものではないことを理解されたい。むしろ、記載した特性および活動は、特許請求の範囲を実施する例示的形として開示されている。

[00115]当業者は、本発明を、パソコン、デスクトップコンピュータ、ノートパソコン、メッセージプロセッサ、手持ち式デバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、携帯電話、ＰＤＡ、ページャ、ルータ、スイッチなどを含む、多くのタイプのコンピュータシステム構成でのネットワーク演算環境で実施することができることが分かるだろう。本発明はまた、ネットワークを通して（有線データリンク、無線データリンク、または有線および無線データリンクの組合せのいずれかによって）リンクされた、ローカルおよび遠隔コンピュータシステムが両方ともタスクを行なう分配されたシステム環境で実施することができる。分配されたシステム環境では、プログラムモジュールは、ローカルおよび遠隔メモリ記憶デバイスの両方に配置させることができる。

[00116]本発明は、その精神および特徴から逸脱することなく、他の特定の形で具体化させることができる。記載した実施形態は、全ての態様において、単に例示的なものであり、限定するものではないと考えられるものとする。本発明の範囲はしたがって、前述の説明よりむしろ、添付の特許請求の範囲によって示される。特許請求の範囲の均等の意味および範囲内にある全ての変更は、その範囲内に含まれるものである。

Claims

イベントを消費者に配信する方法であって、
所有権データにアクセスするステップと、
前記所有権データを正規化(normalizing)して正規化(normalized)イベントを作り出すステップと、
加入(subscription)に基づいて、前記イベントを受信するべきである複数の末端消費者(end consumers)を判断する(determining)ステップと、
前記判断された末端消費者全てに適当な(appropriate)、複数の異なるフォーマットに、前記正規化イベントからのデータを形式化する(formatting)ステップと、
前記末端消費者に適当なフォーマットで、前記複数の末端消費者それぞれに前記正規化イベントからの前記データを配信するステップと、
を含む方法。
所有権データにアクセスするステップは、複数のソースからのデータにアクセスするステップを含む、請求項１に記載の方法。
前記末端消費者に適当なフォーマットで、前記複数の末端消費者それぞれに前記正規化イベントからの前記データを配信するステップは、最初に前記正規化フォーマットで前記イベントからの前記データをファンアウトする(fanning out)ステップを含む、請求項１に記載の方法。
前記末端消費者に適当なフォーマットで、前記複数の末端消費者それぞれに前記正規化イベントからの前記データを配信するステップは、前記イベントを複数のバンドル(bundles)にパッケージングする(packaging)ステップを含み、前記バンドルはそれぞれ前記正規化フォーマットの前記イベントおよびルーティングスリップ(routing slip)を含み、前記ルーティングスリップは、複数の末端消費者を識別し(identifying)、前記識別は、前記ルーティングスリップ内で識別された前記末端消費者用のフォーマットを識別することを含む、請求項１に記載の方法。
前記イベントを複数のバンドルにパッケージングするステップは、データベース内の末端消費者の好み(preferences)を参照することによって、どの末端消費者が前記ルーティングスリップに含まれるのかを判断するためにデータベースを調べるステップを含む、請求項４に記載の方法。
前記所有権(proprietary)データを正規化して正規化イベントを作り出すステップは、イベント正規化システムによってさらに解釈されない、単一の(single)不透明な(opaque)バイナリ量(binary chunk)のデータに伴うキー値対(key value pairs)として前記データを示すステップを含む、請求項１に記載の方法。
前記判断された末端消費者全てに適当な複数の異なるフォーマットに前記正規化イベントからのデータを形式化するステップは、同じ名前を有するメッセージプロパティをマッピングすることによって、前記正規化イベントからの１つまたは複数のプロパティをフォーマットにマッピングするステップを含む、請求項１に記載の方法。