JP2022020737A - ストリームデータにおける空間変化検出器 - Google Patents

Abstract

【課題】イベントストリームに含まれるイベントを処理するためのイベント処理システム、方法及びコンピュータ読み取り可能な媒体を提供する。【解決手段】システムは、アプリケーションに関する連続データストリームを受信し２０５、連続データストリームに関連付けられた入力ジオメトリを特定し２１０、入力ジオメトリに空間クラスタアルゴリズムを実行してジオメトリクラスタを生成し２２０、各クラスタのジオメトリ数に基づいて生成した出力ジオメトリ２２５のパーティションを決定し２３５、該出力ジオメトリのパーティションサイズを動的に変更し２４０、該連続データストリームに関連付けられた出力ジオメトリを送信する２４５。【選択図】図２

Description

関連出願の相互参照
本願は、２０１６年９月１５日に出願され、「ＡＵＴＯＭＡＴＩＣ ＰＡＲＡＬＬＥＬＩＺＡＴＩＯＮ ＦＯＲ ＧＥＯＦＥＮＣＥ ＡＰＰＬＩＣＡＴＩＯＮＳ（ジオフェンスアプリケーションのための自動並列化）」と題された米国仮出願第６２／３９５，２０４号に基づく優先権および利益を主張するものであり、当該出願のすべての記載内容を、あらゆる目的のために引用により本明細書に援用する。

本願は、本願と同日に出願され、「ＡＵＴＯＭＡＴＩＣ ＰＡＲＡＬＬＥＬＩＺＡＴＩＯＮ ＦＯＲ ＧＥＯＦＥＮＣＥ ＡＰＰＬＩＣＡＴＩＯＮＳ（ジオフェンスアプリケーションのための自動並列化）」と題された出願ＰＣＴ／ＵＳ２０１７／０５１８６８号（代理人整理番号０８８３２５－１０５２４３０）の関連出願であり、当該出願のすべての記載内容を、すべてが本明細書に記載されているかのように、引用により本明細書に援用する。

背景
従来のデータベースシステムでは、データは、通常、１つ以上のデータベースにテーブルの形で格納される。その後、格納されたデータは、構造化問い合わせ（クエリ）言語（ＳＱＬ：Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）などのデータ管理言語を用いて問い合わせおよび処理される。たとえば、ＳＱＬクエリを定義、実行し、データベースに格納されたデータから関連性のあるデータを特定してもよい。よって、ＳＱＬクエリは、データベースに格納された有限な一連のデータに対して実行される。さらに、ＳＱＬクエリが実行されるとき、ＳＱＬクエリは、有限なデータセットに対して１回実行され、有限で静的な結果を作成する。よって、データベースは、有限な格納データセットに対してクエリを実行するのに最適である。

しかしながら、いくつかの最近のアプリケーションおよびシステムは、有限なデータセットではなく、連続データまたはイベントストリームの形でデータを生成する。このようなアプリケーションの例として、センサーデータアプリケーション、チッカー、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通量監視などが挙げられるが、これらに限定されない。このようなアプリケーションは、データストリームを処理できる新しい種類のアプリケーションの必要性のきっかけを作った。たとえば、温度センサは、温度測定値を送信ように構成されてもよい。

これらの種類のイベントストリームベースのアプリケーションのためにデータを管理および処理するには、強固な時間的焦点を有するデータ管理および問い合わせ機能を構築することが必要である。連続する無限の一連のデータに対して長時間クエリを実行することを含んだ、異なる種類の問い合わせメカニズムが必要である。現在、イベントストリーム処理を目的とする製品一式を提供するベンダーもいるが、これらの製品提供では、まだ、今日のイベント処理のニーズに対応するために必要な処理柔軟性が欠如している。

概要
イベントストリームのイベントを処理するための技術を提供する（たとえば、方法、シ
ステム、１つ以上のプロセッサによって実行可能なコードまたは命令を格納した非一時的なコンピュータ読み取り可能な媒体）。１つ以上のコンピュータを備えるシステムは、システムにアクションを実行させるソフトウェア、ファームウェア、ハードウェア、または、それらの組合せがシステム上にインストールされていることにより、特定の動作またはアクションを実行するように構成され得る。１つ以上のコンピュータプログラムは、データ処理装置によって実行されると装置にアクションを実行させる命令を含んでいることにより、特定の動作またはアクションを実行するように構成され得る。包括的な一態様は、連続データストリームを処理するための方法を含み、当該方法は、コンピューティングデバイスが、アプリケーションに関する連続データストリームを受信するステップを含む。また、方法は、コンピューティングデバイスが、連続データストリームのジオメトリをリレーションに変換するステップを含む。また、方法は、コンピューティングデバイスが、連続データストリームに含まれる複数の移動オブジェクトを追跡するステップを含む。また、方法は、コンピューティングデバイスが、リレーションおよび連続データストリームのジオメトリに少なくとも基づいて、複数の移動オブジェクトに含まれる、少なくとも第１の移動オブジェクトと第２の移動オブジェクトとの近接を判断するステップを含む。また、方法は、少なくとも第１の移動オブジェクトと第２の移動オブジェクトとの近接が予め定められた閾値を超えた場合、アラートを生成するステップを含む。

実装形態は、下記の特徴のうちの１つ以上を含んでもよい。リレーションは、連続データストリームのジオメトリの空間インデックスを含む、方法。方法は、コンピューティングデバイスが、範囲を用いて空間インデックスにフィルタを適用して連続データストリームのジオメトリについてのフィルタ処理された結果を取得するステップをさらに含み、近接を判断するステップは、フィルタ処理された結果を用いて第１の移動オブジェクトと第２の移動オブジェクトとの距離を算出するステップを含む。方法は、コンピューティングデバイスが、連続データストリームのジオメトリに変更があるかどうかを判断するステップと、コンピューティングデバイスが、連続データストリームのジオメトリに変更があった場合、更新イベントを発行するステップとをさらに含む。更新イベントは、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ上で発行される、方法。方法は、結合演算を用いてコンピューティングデバイスが、リレーションと連続データストリームのジオメトリとを結合するステップをさらに含む。追跡するステップは、少なくとも第１の移動オブジェクトの第２の移動オブジェクトに対する関係を追跡するための空間演算を用いて実行される、方法。記載の技術の実装形態は、ハードウェア、方法もしくはプロセス、または、コンピュータによってアクセス可能な媒体上のコンピュータソフトウェアを含んでもよい。

包括的な一態様は、コンピュータによって実行可能な命令を格納するように構成されたメモリと、メモリにアクセスしてコンピュータによって実行可能な命令を実行するように構成されたプロセッサとを備えるシステムを含む。また、システムは、アプリケーションに関する連続データストリームを受信することを含む。また、システムは、連続データストリームのジオメトリをリレーションに変換することを含む。また、システムは、連続データストリームに含まれる複数の移動オブジェクトを追跡することを含む。また、システムは、リレーションおよび連続データストリームのジオメトリに少なくとも基づいて、複数の移動オブジェクトに含まれる、少なくとも第１の移動オブジェクトと第２の移動オブジェクトとの近接を判断することを含む。また、システムは、少なくとも第１の移動オブジェクトと第２の移動オブジェクトとの近接が予め定められた閾値を超えた場合、アラートを生成することを含む。この態様の他の実施形態は、対応するコンピュータシステムと、装置と、方法のアクションを実行するように各々が構成される、１つ以上のコンピュータ記憶装置上に記録されたコンピュータプログラムとを備える。

実装形態は、下記の特徴のうちの１つ以上を含んでもよい。リレーションは、連続デー
タストリームのジオメトリの空間インデックスを含む、システム。システムは、コンピューティングデバイスが、範囲を用いて空間インデックスにフィルタを適用して連続データストリームのジオメトリについてのフィルタ処理された結果を取得することをさらに含み、近接を判断することは、フィルタ処理された結果を用いて第１の移動オブジェクトと第２の移動オブジェクトとの距離を算出することを含む。システムは、コンピューティングデバイスが、連続データストリームのジオメトリに変更があるかどうかを判断することと、コンピューティングデバイスが、連続データストリームのジオメトリに変更があった場合、更新イベントを発行することとをさらに含む。更新イベントは、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ上で発行される,システム。システ
ムは、結合演算を用いてコンピューティングデバイスが、連続データストリームのジオメトリとリレーションとを結合することをさらに含む。追跡することは、少なくとも第１の移動オブジェクトの第２の移動オブジェクトに対する関係を追跡するための空間演算を用いて実行される、システム。記載の技術の実装形態は、ハードウェア、方法もしくはプロセス、または、コンピュータによってアクセス可能な媒体上のコンピュータソフトウェアを含んでもよい。

包括的な一態様は、コンピュータによって実行可能なコードを格納したコンピュータ読み取り可能な媒体を含み、コンピュータによって実行可能なコードは、プロセッサによって実行されると、プロセッサに動作を行わせ、当該動作は、アプリケーションに関する第１の連続データストリームを受信することを含む。また、コンピュータ読み取り可能な媒体は、第１の連続データストリームのジオメトリをリレーションに変換することを含む。また、コンピュータ読み取り可能な媒体は、連続データストリームに含まれる複数の移動オブジェクトを追跡することを含む。また、コンピュータ読み取り可能な媒体は、アプリケーションに関する第２の連続データストリームを受信することを含む。また、コンピュータ読み取り可能な媒体は、リレーションおよび第２の連続データストリームのジオメトリに少なくとも基づいて、複数の移動オブジェクトに含まれる、少なくとも移動オブジェクトと第２の連続データストリームに含まれるオブジェクトとの関係をチェックすることを含む。また、コンピュータ読み取り可能な媒体は、関係が予め定められた基準を満たす場合、移動オブジェクトのプロパティを設定することを含む。この態様の他の実施形態は、対応するコンピュータシステムと、装置と、方法のアクションを実行するように各々が構成される、１つ以上のコンピュータ記憶装置上に記録されたコンピュータプログラムとを備える。

実装形態は、下記の特徴のうちの１つ以上を含んでもよい。リレーションは、連続データストリームのジオメトリの空間インデックスを含む、コンピュータ読み取り可能な媒体。関係をチェックすることは、リレーションおよび第２の連続データストリームのジオメトリに少なくとも基づいて、複数の移動オブジェクトに含まれる、少なくとも移動オブジェクトと第２の連続データストリームに含まれるオブジェクトとの近接を判断することを含む、コンピュータ読み取り可能な媒体。少なくとも複数の移動オブジェクトに含まれる移動オブジェクトと第２の連続データストリームに含まれるオブジェクトとの近接が予め定められた閾値を超えた場合、移動オブジェクトのプロパティが設定される、コンピュータ読み取り可能な媒体。動作は、範囲を用いて空間インデックスにフィルタを適用して第１の連続データストリームのジオメトリについてのフィルタ処理された結果を取得することをさらに含み、近接を判断することは、複数の移動オブジェクトに含まれる移動オブジェクトと第２の連続データストリームに含まれるオブジェクトとの距離を算出することを含む、コンピュータ読み取り可能な媒体。動作は、第１の連続データストリームのジオメトリに変更があるかどうかを判断することと、第１の連続データストリームのジオメトリに変更があった場合、更新イベントを発行することとをさらに含み、更新イベントは、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ上で発行される、コンピュータ読み取り可能な媒体。記載の技術の実装形態は、ハードウェア、方法もしく
はプロセス、または、コンピュータによってアクセス可能な媒体上のコンピュータソフトウェアを含んでもよい。

本開示の実施形態に係る、イベント処理アプリケーションがそれぞれ異なる実行環境のために処理され得る環境を提供する例示的なイベント処理システムアーキテクチャの態様を示す図である。 本開示の実施形態に係る、全体的なワークフローの例示的なフロー図である。 本開示の実施形態に係る、クラスタ変更検出処理の例示的なフロー図である。 本開示の実施形態に係る、クラスタ削除処理、パーティションの変更処理、およびパーティション識別子の割り当て処理の例示的なフロー図である。 本開示の実施形態に係る、入力ジオメトリ、インデックス、およびグリッドの説明図である。 本開示の実施形態に係る、ストリームに含まれる移動オブジェクトの近接検出およびチェックを行うための技術の説明図である。 本開示の実施形態に係る、ストリームに含まれる移動オブジェクトの近接検出およびチェックを行うための技術の説明図である。 近接検出およびストリームに含まれる移動オブジェクトのチェックを行うための技術、および、本開示の実施形態に従ってチェック・セット操作が実施され得る例示的なシステムまたはアーキテクチャの説明図である。 本開示の実施形態に係る、イベント処理システムの簡略化されたハイレベル図の説明図である。 本開示の実施形態に係る、イベント処理の例示的なフロー図である。 本開示の実施形態を実現するための分散システムの簡略図である。 本開示の実施形態に係る、実施形態のシステムの１つ以上構成要素が提供するサービスがクラウドサービスとして提供され得るシステム環境の１つ以上の構成要素の簡略ブロック図である。 本開示の実施形態を実現するために利用され得る例示的なコンピュータシステムを例示する図である。

詳細な説明
以下の説明において、様々な実施形態を説明する。説明の便宜上、実施形態の十分な理解のために具体的な構成および詳細を説明する。しかしながら、実施形態が具体的な詳細なしに実施され得ることは、当業者に明らかになるだろう。さらに、記載の実施形態を曖昧にしてしまわないように、周知の特徴は省略または簡略化される場合がある。

複合イベント処理（ＣＥＰ：Ｃｏｍｐｌｅｘ Ｅｖｅｎｔ Ｐｒｏｃｅｓｓｉｎ）の概要
複合イベント処理（ＣＥＰ）は、イベント駆動型アーキテクチャに基づいてアプリケーションを構築するためのモジュラープラットフォームを提供する。ＣＥＰプラットフォームの中心にあるのは、連続問い合わせ（クエリ）言語（ＣＱＬ：Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）である。ＣＱＬによって、アプリケーションは、ＳＱＬのような宣言型言語を用いてデータのストリームに対してフィルタ処理、問い合わせ、およびパターンマッチング動作を実行できるようになる。開発者は、軽量Ｊａｖａ（登録商標）プログラミングモデルと合わせてＣＱＬを使用してアプリケーションを書いてもよい。他のプラットフォームモジュールとして、一例を挙げると、機能が豊富なＩＤＥ、管理コンソール、クラスタリング、分散キャッシング、イベントリポジトリ、モニタリングな
どがある。

イベント駆動型アーキテクチャおよび複合イベント処理がエンタープライズコンピューティング分野の目立った特徴になるにつれて、より多くの企業がＣＥＰ技術を用いてミッションクリティカルなアプリケーションを構築し始めた。今日、ミッションクリティカルなＣＥＰアプリケーションは、多くの異なる産業で見つけることができる。たとえば、ＣＥＰ技術は、電力事業において、電気需要の変化に対して瞬時に公共事業を対応させることにより公共事業をより効率的なものにするために利用されている。ＣＥＰ技術は、クレジットカード業界において、詐欺の可能性があるトランザクションが発生したときにリアルタイムで検出するために利用されている。ミッションクリティカルなＣＥＰアプリケーションの数は、増え続けている。ミッションクリティカルなアプリケーションを構築するためにＣＥＰ技術が利用されることにより、ＣＥＰアプリケーションが高い可用性を有し、かつ、フォールトトレラントである必要があるようになった。

今日の情報技術（ＩＴ：Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）環境は、金融市場およびネットワーク性能の監視から、ビジネスプロセスの実行およびＲＦＩＤがタグ付けされたアセットの追跡まで、あらゆることについてのデータの連続ストリームを生成する。ＣＥＰは、イベント処理アプリケーションを開発するための豊富な宣言型環境を提供して、業務運営の有効性を改善する。ＣＥＰは、複数のイベントストリームを処理して、パターンおよび傾向をリアルタイムで検出し、かつ、新たに出現した商機に出資するまたはリスクが大きくなるのを軽減するために必要な可視性を企業に提供できる。

データの連続ストリーム（イベントストリームとも称する）は、本質的にはっきりとした終端がない、連続または無限のデータストリームまたはイベントストリームを含んでもよい。論理的には、イベントストリームまたはデータストリームは、データ要素（イベントとも称する）のシーケンスであってもよく、各データ要素は、関連するタイムスタンプを有する。連続イベントストリームは、要素（ｓ，Ｔ）のバッグまたはセットとして論理的に表されてもよく、「ｓ」は、データ部分を表し、「Ｔ」は、時間ドメインに含まれる。この「ｓ」部分は、一般に、タプルまたはイベントと呼ばれる。よって、イベントストリームは、タイムスタンプが記録されたタプルまたはイベントのシーケンスであってもよい。

いくつかの態様では、ストリームに含まれるイベントに関連付けられたタイムスタンプは、クロックタイムと一致してもよい。しかしながら、他の例では、イベントストリームに含まれるイベントに関連付けられた時間は、アプリケーションドメインによって定義されてもよく、クロックタイムに対応しなくてもよいが、代わりに、たとえばシーケンス番号によって表されてもよい。したがって、イベントストリームに含まれるイベントに関連付けられた時間情報は、番号、タイムスタンプ、または時間の観念を表すその他の情報によって表されてもよい。入力イベントストリームを受信するシステムについては、このイベントは、タイムスタンプの昇順に当該システムに到着する。同じタイムスタンプを有するイベントが２つ以上あるかもしれない。

いくつかの例では、イベントストリームに含まれるイベントは、なんらかの世俗的イベントの発生（たとえば、温度センサの値が新しい値に変わったとき、銘柄記号の価格が変更したとき）を表してもよく、当該イベントに関連付けられた時間情報は、データストリームイベントによって表される世俗的イベントがいつ発生したかを示してもよい。

イベントストリームを介して受信されたイベントについては、イベントに関連付けられた時間情報を用いて、イベントストリームに含まれる当該イベントが必ずタイムスタンプ値の昇順に到着するようにしてもよい。これによって、イベントストリームで受信された
イベントがそれらの関連する時間情報に基づいて順序付けされることを可能にしてもよい。この順序付けを可能にするために、後に生成されるイベントが、前に生成されたイベントよりも後のタイムスタンプを有するよう、イベントストリームに含まれるイベントにタイムスタンプが非降順で関連付けられてもよい。別の例として、時間情報としてシーケンス番号が利用されている場合、後に生成されるイベントに関連付けられるシーケンス番号は、それよりも前に生成されたイベントに関連付けられるシーケンス番号よりも大きくてもよい。いくつかの例では、たとえば、データストリームイベントが表す世俗的イベントが同じ時間に発生した場合、複数のイベントが同じタイムスタンプまたはシーケンス番号に関連付けられてもよい。同じイベントストリームに属するイベントは、一般に、関連する時間情報がイベントに設定した順序で処理されてもよく、前のイベントが後のイベントよりも前に処理される。

イベントストリームに含まれるイベントに関連付けられた時間情報（たとえば、タイムスタンプ）は、ストリームの送信元によって設定されてもよく、または、これに代えて、システムが当該ストリームを受信することによって設定されてもよい。たとえば、特定の実施形態では、ハートビートは、イベントストリームを受信するシステム上で維持されてもよく、イベントに関連付けられた時間は、ハートビートが計測するイベントのシステムへの到着時間に基づいてもよい。イベントストリームに含まれる２つのイベントが同じ時間情報を有している可能性がある。なお、タイムスタンプ順序要件は１つのイベントストリームに特有であるが、異なるストリームのイベントが任意にインターリーブされるかもしれない。

イベントストリームは、関連するスキーマ「Ｓ」を有し、このスキーマは、時間情報および１つ以上の名前付き属性のセットを含む。特定のイベントストリームに属するすべてのイベントは、その特定のイベントストリームに関連付けられたスキーマに準拠している。したがって、イベントストリーム（ｓ，Ｔ）について、このイベントストリームは、（＜ｔｉｍｅ＿ｓｔａｍｐ＞、＜ａｔｔｒｉｂｕｔｅ（ｓ）＞）というスキーマ「Ｓ」を有してもよい。＜ａｔｔｒｉｂｕｔｅｓ＞は、スキーマのデータ部分を表し、１つ以上の属性を含み得る。たとえば、チッカーイベントストリームのスキーマは、属性＜ｓｔｏｃｋ
ｓｙｍｂｏｌ＞（銘柄記号）と＜ｓｔｏｃｋ ｐｒｉｃｅ＞（株価）とを含んでもよい。このようなストリームを介して受信された各イベントは、１つのタイムスタンプと２つの属性とを有することになる。たとえば、チッカーイベントストリームは、以下のイベントおよび関連するタイムスタンプを受信してもよい。

…
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＞，＜ＮＶＤＡ，４＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋１＞，＜ＯＲＣＬ，６２＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋２＞，＜ＰＣＡＲ，３８＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋３＞，＜ＳＰＯＴ，５３＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋４＞，＜ＰＤＣＯ，４４＞）
（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋５＞，＜ＰＴＥＮ，５０＞）
…
上記のストリームでは、ストリーム要素（＜ｔｉｍｅｓｔａｍｐ＿Ｎ＋１＞，＜ＯＲＣＬ，６２＞）について、イベントは、＜ＯＲＣＬ，６２＞であり、属性「ｓｔｏｃｋ＿ｓｙｍｂｏｌ」および「ｓｔｏｃｋ＿ｖａｌｕｅ」を有する。ストリーム要素に関連付けられたタイムスタンプは、「ｔｉｍｅｓｔａｍｐ＿Ｎ＋１」である。よって、連続イベントストリームは、イベントのフローであり、各イベントは同じ一連の属性を有する。

上述したように、ストリームは、ＣＱＬ問い合わせが作用し得るデータの主要なソースであってもよい。ストリームＳは、要素（ｓ，Ｔ）のバッグ（「マルチセット」とも称す
）であってもよく、「ｓ」は、Ｓのスキーマに含まれ、「Ｔ」は、時間ドメインに含まれる。これに加えて、ストリーム要素は、タプルとタイムスタンプとのペアであってもよく、タイムスタンプが記録されたタプル挿入のシーケンスとして表され得る。つまり、ストリームは、タイムスタンプが記録されたタプルのシーケンスであってもよい。場合によっては、同じタイムスタンプを有する２つ以上のタプルがあってもよい。そして、入力ストリームのタプルは、タイムスタンプの昇順でシステムに到着する必要があってもよい。これに代えて、リレーション（「時間変化リレーション」とも称す。リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同しないこと。）は、時間ドメインからスキーマＲの無限のタプルバッグへのマッピングであり得る。いくつかの例では、リレーションは、順序付けされていない、時間で変化するタプルバッグ（すなわち、瞬間のリレーション）であってもよい。場合によっては、各時間において、リレーションは、有界集合であってもよい。リレーションは、リレーションが変化する状態を捉えるために挿入、削除、および／または更新を含み得る、タイムスタンプが記録されたタプルのシーケンスとして表すこともできる。ストリームと同様に、リレーションは、リレーションの各タプルが準拠し得る固定スキーマを有してもよい。さらに、本明細書で使用するとき、連続クエリは、一般に、ストリームおよび／またはリレーションのデータを処理することが可能であってもよい（すなわち、問い合わせされる）。これに加えて、リレーションは、ストリームのデータを参照してもよい。

いくつかの態様では、ＣＱＬエンジンは、本格的な問い合わせ言語を含んでもよい。このように、ユーザは、問い合わせによって計算内容を指定してもよい。これに加えて、ＣＱＬエンジンは、メモリの最適化、問い合わせ言語特性の利用、演算子の共有、リッチパターンマッチング、リッチ言語構成などのために設計されてもよい。これに加えて、いくつかの例では、ＣＱＬエンジンは、過去データおよびストリーミングデータの両方を処理してもよい。たとえば、ユーザは、カリフォルニア州での売上が特定の目標を上回った場合にアラートを送るためのクエリを設定できる。よって、いくつかの例では、アラートは、過去の売上データおよび受信中のライブの（すなわち、リアルタイムの）売上データ、の少なくとも一部に基づいてもよい。

いくつかの例では、ＣＱＬエンジンまたは後述する概念の他の特徴は、リアルタイムで過去のコンテキスト（すなわち、ウェアハウスデータ）を受信データと結合するように構成されてもよい。よって、場合によっては、本開示は、データベースに格納された情報とインフライト情報との境界を記述してもよい。データベースに格納された情報およびインフライト情報は、ＢＩデータを含んでもよい。このように、データベースは、いくつかの例では、ＢＩサーバであってもよく、または、任意の種類のデータベースであってもよい。さらに、いくつかの例では、本開示の特徴は、プラグラミングの仕方またはコードの書き方をユーザが知らなくても上記の特徴が実施されることを可能にしてもよい。つまり、この特徴は、多機能ユーザインタフェース（ＵＩ）で提供されてもよく、または、開発者でない者が過去データとリアルタイムデータとの結合を実現できるようなその他の方法で提供されてもよい。

いくつかの例では、上記の概念を利用して、複合イベント処理に関連付けられた豊富なリアルタイムの連続イベント処理能力を活用してもよい。これに限定されないが、アーカイブされたリレーションなどのいくつかの特徴がサポートされてもよい。このように、このような特徴（たとえば、豊富なリアルタイムの連続イベント処理）活用するために、システムは、リレーショナルデータのスタートアップ状態および実行時状態を透過的に取り扱うように構成されてもよい。つまり、システムは、空でないクエリを作成された時点から管理するように構成されてもよい（すなわち、アーカイブされたリレーション）。

いくつかの例では、アーカイブされたリレーションを利用してもよい。このように、ク
エリがアーカイブされたリレーションに基づいていることを示す当該クエリをＣＱＬエンジンが確認した場合、そのアーカイブされたリレーションは、たとえば、過去のコンテキストを問い合わせするためにリレーションが呼び出すことができる特定のエンティティがあることも示してもよい。いくつかの例では、データ定義言語（ＤＤＬ：Ｄａｔａ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）は、これらに限定されないが、問い合わせをどのように行うか、テーブルにおいて重要なカラムはどれであるか、および／または残りのデータの送リ先など、アーカイブされたリレーションについての注釈を示してもよい。いくつかの例では、ＣＱＬエンジンにおいてクエリが組み立てられると（たとえば、グラフとして）、システムは、質問グラフを分析してもよい。これに加えて、いくつかの態様では、「ｄｉｓｔｉｎｃｔ」、「ｇｒｏｕｐ ａｇｇｒ」、「ｐａｔｔｅｒｎ」、および／または「ｇｒｏｕｐ ｂｙ」のような、ステートフルな特定の演算子がある。しかしながら、ステートレスな演算子は、入力を取ってそれを親、たとえば、下流の演算子に送るだけであろう。ついては、１つの手法は、このテーブル全体をここに記憶することである。しかしながら、アーカイブされたリレーションを利用して、システムは、質問グラフを分析して、アーカイブを問い合わせするのに使用できる最下位のステートフル演算子がどれであるかを決めてもよい。いくつかの例では、システム（または、１つ以上のコンピュータにより実現される方法）は、グラフを横断しながら到達した最下位のステートフル演算子での状態を検索してもよい。たとえば、質問グラフは、ソースからトポロジー順に分析されてもよい。この最初のステートフル演算子の少なくとも一部に基づいて、ＣＱＬエンジンは、アーカイブされたリレーションに対して定義されたクエリの演算子の状態を初期化するために、フェッチするデータの最適な量を決定してもよい。

少なくとも１つの非限定例では、リレーションおよび／またはソースのようなソース演算子は、トポロジー横断において最初に出現してもよく、クエリが出力されるおよび／またはルートが最後に来る。たとえば、ＣＱＬクエリがｓｅｌｅｃｔ ｓｕｍ（ｃ１）ｆｒｏｍ Ｒ１ ｗｈｅｒｅ ｃ２＞ｃ２５、のような場合、このクエリのプランは、ＲｅｌａｔｉｏｎＳｏｕｒｃｅ→ＳＥＬＥＣＴ→ＧｒｏｕｐＡｇｇｒ、のようになるだろう。よって、トポロジー順に従って、ＲｅｌａｔｉｏｎＳｏｕｒｃｅおよびＳＥＬＥＣＴは両方ステートレスであるので、最下位のステートフル演算子は、ＧｒｏｕｐＡｇｇｒであろう。このように、クエリのステートフル演算子（この例において、ＧｒｏｕｐＡｇｇｒ）は、クエリエンジンがストリーミングデータを受信する前にデータストアからの過去データで当該クエリエンジンを満たすことを可能にしてもよい。これは、アーカイブされたリレーションをクエリが分析しており、アーカイブされたリレーションがそのように示されている、ということの少なくとも一部に基づいて可能になってもよい。

いくつかの例では、所与のアーカイブされたリレーションのウィンドウサイズは、ユーザによって指定されてもよい。いくつかの態様においてアーカイブされたリレーションと関連しているウィンドウは、ストリーム配信された受信コンテンツを分析または評価する質問グラフにおけるノードを含んでもよい。つまり、ウィンドウは、クエリエンジンによって分析および／もしくは処理されるストリーム配信されたコンテンツの量ならびに／またはアーカイブされたリレーションに含まれることになる過去データの量を規定してもよい。

ハイレベルでは、ウィンドウがＳｔｒｅａｍに適用されると、それはＲｅｌａｔｉｏｎになり、その後、リレーショナルデータベースと同様に通常の関係論理が適用されてもよい。タプルがウィンドウに到着してウィンドウを離れると、当該Ｒｅｌａｔｉｏｎは、それに対してクエリがコンパイルされると変化し、それと同時に結果を出力する。ＣＱＬは、ＲＡＮＧＥ（最大でナノ秒の粒度）、ＲＯＷＳ、ＰＡＲＴＩＴＩＯＮ ＢＹ、および拡張可能なウィンドウをサポートしてもよい。これらのウィンドウは、ストリームからリレーションへの演算子の例である。一方では、ＩＳＴＲＥＡＭ（すなわち、挿入ストリーム
）、ＤＳＴＲＥＡＭ（すなわち、削除ストリーム）、およびＲＳＴＲＥＡＭ（すなわち、リレーションストリーム）が、リレーションからストリームへの演算子である。いくつかの例では、ユーザ、開発者、および／または管理者は、クエリエンジンまたはクエリエンジンを操作もしくはホストしている１つ以上のコンピューティングシステムが提供するウィンドウサイズを（たとえば、ＵＩを介して）設定してもよい。いくつかの例では、ストリーム上のウィンドウは、時間ベースの範囲ウィンドウであってもよい。たとえば、アーカイブされたリレーション上の構成可能な値ウィンドウは、ウィンドウサイズ、およびウィンドウが算出される属性を用いて指定されてもよい。アーカイブされたリレーション上で指定された構成可能な値ウィンドウがある場合、スナップショットクエリが計算されてもよく、ウィンドウ制限内のスナップショットタプルが出力されてもよい。これに加えて、状態の初期化後、値ウィンドウは、受信アクティブデータに適用されてもよい。いくつかの例では、ウィンドウ属性の値がウィンドウサイズよりも小さい、現在のイベント時刻とは異なるウィンドウに、受信アクティブデータだけが挿入されることになる。

これに加えて、いくつかの例では、本開示の特徴は、ＣＱＬエンジンおよび／またはＣＥＰエンジンの連続クエリ処理機能を活用してデータのリアルタイム分析をサポートしてもよい。いくつかの態様では、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、従来、ストリーム指向分析エンジンであったと思われる。しかしながら、堅牢なストア（たとえば、上述したアーカイブされたリレーション）が支援するストリーム指向データをサポートするよう強化されてもよい。たとえば、本開示は、堅牢なストア（データベースおよび／またはテーブル）であるデータオブジェクト（ＤＯ：Ｄａｔａ Ｏｂｊｅｃｔ）の概念をサポートし得る特徴を記載する。ＤＯに対して行われた修正によって、データストリームを事実上作成している関心のあるリスナーに変更通知がブロードキャストされてもよい。このデータストリームは、実行中のクエリをサポートしているＣＱＬエンジンおよび／またはＣＥＰエンジンによって消費されてもよい。しかしながら、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、ＤＯ支援ストアに含まれる既存データを考慮するように設計されていないかもしれない。たとえば、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、ＣＱＬエンジンおよび／またはＣＥＰエンジンで実行中のクエリの初期状態がＤＯ支援ストアに現在あるすべてのデータを含むＤＯの現在の状態を反映するよう、要求してもよい。このクエリがこのように初期化されると、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、従来のストリーム指向スタイルで、その時点以降のＤＯ変更通知のストリームと関わるだけでよい。

いくつかの態様では、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、ストリームまたはアーカイブされていないリレーションを従来的に処理している可能性があり、それ故、初期状態が存在しない可能性がある。たとえば、クエリがロードされてもよく、実行および変更などについての待ち受けを開始してもよい。場合によっては、ユーザが州別の売上を棒グラフで求め、その後、誰かが新しい売上を出した場合、テーブルは更新されてもよく、ユーザは、売上の変更がグラフに反映されていることを期待するだろう。しかしながら、ダッシュボードを閉じて１週間後に再び売上を表示した場合、ユーザは、積算売上データのテーブルに従って売上の合計を得ると期待するだろう。つまり、クエリは、クエリをアーカイブ状態にしてからアクティブな変更を待ち受ける必要があってもよい。

いくつかの態様では、たとえば、ＣＱＬエンジンは、アーカイブされたデータを用いて予め初期化されてもよい。初期化されると、ＣＱＬエンジンは、ＪＭＳ（Ｊａｖａ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）または変更通知用の他のメッセンジャーを（たとえば、アーカイブからのデータの挿入、削除などのためのＡＰＩ呼び出しの少なくとも一部に基づいて）待ち受けてもよい。よって、サービスは、待ち受けることができ、待ち受けサービスが待ち受けている同じトピックをＪＭＳが発信した場合、サービスは、データを受信してもよい。サービスは、誰が発信しているか、または発信しているかどうかを把握し
ていなくてもよい。待ち受けサービスは、待ち受けることができるだけであり、何かが起こると、待ち受けサービスはそれが聞こえてもよい。いくつかの例では、これが、たとえば顧客から持続性が切り離される方法である。これに加えて、いくつかの例では、アラートエンジンは、アラートエンジンが聞いた内容、場合によっては、そしてさらにはリスナーに関連性のあるプロセスクエリを待ち受けている可能性のあるＳＱＬエンジンに基づいてアラートを挙げてもよい。

いくつかの例では、クエリは、ＣＱＬ、ＳＱＬ、および／またはＣＥＰエンジンで開始されてもよく、命令は、アーカイブデータを取得して（たとえば、エンジンを準備し）、その後、これらのＪＭＳメッセージの待ち受けを開始するように構成されてもよい。しかしながら、挿入、削除などが膨大であると、大量の情報を含んでいる可能性がある。これに加えて、メッセージがリスナーに聞かれる前にタイムラグがある可能性があり、待ち受けは、いくつかの例では、急いでクエリのアーカイブを問い合わせして戻ってきて待ち受けを開始する可能性がある。よって、イベントを喪失してしまう、および／または二重にカウントしてしまう可能性がある。

これに加えて、エンジンが単にクエリを実行するだけである場合、クエリを実行中に様々なものがＪＭＳに入ってしまってエンジンが待ち受けをしていないところでそれらが発信されてしまう可能性がある。そのため、エンジンは、リスナーを最初にセットアップしてからアーカイブクエリを実行し、その後、戻ってきて実際に待ち行列から取り出し始めるように構成されてもよく、これにより、何も見逃さなくなる。よって、ＪＭＳは、待ち行列に様々なものを入れてもよく、たとえ停滞したとしても、エンジンが問い合わせをしている間は大丈夫である。なぜならば、エンジンはその後キャッチアップでき、同期しているかどうかについて気にしなくてよいからである。エンジンがここで待ち受けをしていなくても、エンジンがリスナーを設定している限り、見逃すことはなく、エンジンが戻ってくるまでただ待ち行列に入れられる。

これに加えて、いくつかの例では、システムカラムがユーザのデータに追加されてもよい。このシステムカラムは、二重カウントおよび／または喪失操作問題の処理を図るためにトランザクションＩＤを示すためのものであってもよい。しかしながら、他の例では、システムは、トランザクションコンテキストテーブルを提供または生成してもよい。これに加えて、２つのさらなるカラムであるＴＲＡＮＳＡＣＴＩＯＮ＿ＣＩＤとＴＲＡＮＳＡＣＴＩＯＮ＿ＴＩＤとがあってもよい。コンテキストテーブルは、スレッド（コンテキスト）的に最後にコミットされたトランザクションＩＤが分かるよう、永続サービスによって常に維持されてもよい。トランザクションＩＤがスレッド（コンテキスト）の昇順でコミットされることを保証してもよい。たとえば、サーバは、立ち上がると、永続サービスを実行してもよい。各々は、予め初期化された情報のデータがＪＭＳを通したデータのすべてを含んでいるかどうかを判断するための、コンテキストＩＤとトランザクションＩＤとのセットを割り当ててもよい。これに加えて、場合によっては、（ＪＴＡに準拠して、および／または高可用性（ＨＡ）を実現するために）複数の出力サーバが利用されてもよく、各サーバは、その他のサーバが管理するその他のテーブルとは完全に異なる１つコンテキスト／トランザクションテーブルのセットを管理してもよい。

いくつかの実施形態では、連続（たとえば、ＣＱＬ）クエリが作成または登録された場合、このクエリは、構文解析および意味分析にかけられてもよく、最後に論理クエリプランが作成される。たとえば、「ａｌｔｅｒ ｑｕｅｒｙ ＜ｑｕｅｒｙｎａｍｅ＞ ｓｔａｒｔ」ＤＤＬを発行することによってＣＱＬクエリが開始されると、論理クエリプランは、物理クエリプランに変換されてもよい。一例において、物理クエリプランは、物理演算子のＤＡＧ（Ｄｉｒｅｃｔｅｄ Ａｃｙｃｌｉｃ Ｇｒａｐｈ）などと表されてもよい。次に、物理演算子は実行演算子に変換され、そのＣＱＬクエリの最終クエリプランに到
着してもよい。ＣＱＬエンジンに入ってくるイベントはソース演算子（複数可）に到達し、最終的に、これらのイベントに処理を実行して適切な出力イベントを生成する方法で、演算子とともに下流に移動する。

イベント処理アプリケーション
ＲＡＷインフラストラクチャおよびビジネスイベントの量および速度は、ＩＴ環境において急激に増加している。それが金融サービスの株式データをストリーミング配信していようと、軍用衛星データまたは運送／ロジスティクス業のリアルタイム車両位置データをストリーミング配信していようと、複数の業界の企業は、大容量の複合データをリアルタイムで処理しなければならない。これに加えて、モバイル機器の急激な増加および高速接続性の偏在性がモバイルデータの急激な増加を増大させる。同時に、ビジネスプロセスの俊敏性および実行の需要も増えている。これらの２つの傾向が、実装のイベント駆動型アーキテクチャパターンをサポートする能力を上げるよう、組織に圧力をかけている。リアルタイムイベント処理は、イベント処理要件を実行するためのインフラストラクチャおよびアプリケーション開発環境の両方を必要とする。これらの要件は、日々のユースケースから、潜在的に、数秒の応答時間ではなく、マイクロ秒で計測されるレイテンシを有する非常に高速のデータおよびイベントスループットまで拡大する必要性を含んでいる場合が多い。これに加えて、イベント処理アプリケーションは、これらのイベントのフローに含まれる複雑なパターンを検出しなければならないことが多い。

Ｏｒａｃｌｅ Ｓｔｒｅａｍ Ａｎａｌｙｔｉｃｓプラットフォームは、多くの業界および機能分野を対象としている。以下に、いくつかのユースケースを示す。

テレコミュニケーション：リアルタイムで呼詳細レコード（ＣＤＲ：Ｃａｌｌ Ｄｅｔａｉｌ Ｒｅｃｏｒｄ）の監視およびＤｏＳ（Ｄｅｎｉａｌ Ｏｆ Ｓｅｒｖｉｃｅ）攻撃の検出を行う能力。

金融サービス：ミリ秒またはマイクロ秒の期間に存在する裁定取引する商機に出資する能力。金融証券取引のリスク分析、監視および報告をリアルタイムで行い、外国為替価格を算出する能力。

運輸：地域または目的地の天候、地上整備員の作業、空港セキュリティなどによるフライトの不具合の場合に乗客向けアラートを作成し、手荷物の場所を検出する能力。

公共部門／軍事：地理的な分散した敵の情報を検出、抽出して、高確率の敵の攻撃を読み解く能力。最適なリソースをアラートして非常事態に対応する能力。

保険：詐欺の可能性がある請求を学習および検出する能力。
ＩＴシステム：障害が発生しているアプリケーションまたはサーバをリアルタイムで検出し、修正措置を作動させる能力。

サプライチェーンおよびロジスティクス：出荷をリアルタイムで追跡し、到着が遅れる可能性を検出および報告する能力。

リアルタイムストリーム配信およびイベント処理アナリティクス
互いに接続されるデバイスの数が増えるにつれてデータが急激に増加することにより、組織内を移動するデータだけでなく、ファイアウォール外を移動するデータについても動的に変化するデータが大量に増えている。高速データは、特に変動が激しいビジネスプロセスにとって大きな価値がある。しかしながら、このデータのうちのいくつかは、短時間でその運用価値が失われてしまう。ビッグデータを利用すれば、実用的な洞察を行うため
の処理を時間をかけて行うことができる。一方では、ファストデータ（Ｆａｓｔ Ｄａｔａ）の場合、非常に動的かつ戦略的なデータから最大限の価値を引き出す必要がある。ファストデータは、さらに高速な処理が必要とされ、生成されたデータにできるだけ近いタイムリーなアクションを取ることができるようになる。Ｏｒａｃｌｅ Ｓｔｒｅａｍ Ａｎａｌｙｔｉｃｓプラットフォームは、応答性が向上したファストデータを実現することができる。Ｏｒａｃｌｅ Ｅｄｇｅ Ａｎａｌｙｔｉｃｓでは、ネットワークエッジに処理がプッシュされ、データを相関分析、フィルタ処理、および分析して、実用的な洞察をリアルタイムで行うことができる。

Ｏｒａｃｌｅ Ｓｔｒｅａｍ Ａｎａｌｙｔｉｃｓプラットフォームは、永続データを有する受信ストリーミングイベントをつなぎ合わせる能力を提供することにより、前後関係を意識したフィルタ処理、相関分析、アグリゲーション、およびパターンマッチングを提供する。共通のイベントソース（Ｅｖｅｎｔ Ｓｏｕｒｃｅ）用に軽量かつそのまますぐに使える（ｏｕｔ ｏｆ ｔｈｅ ｂｏｘ）アダプタを提供する。また、カスタムアダプタの開発のための使いやすいアダプタフレームワークを提供する。このプラットフォームによって、組織は、商機、および無関係に思われるイベントが表す脅威を特定して予期することができるようになる。そのインクリメンタル処理規範は、最低限の量のリソースを用いてイベントを処理することができ、待機時間が極端に少ない。また、非常にタイムリーなアラートを作成し、次のような喪失または遅延したイベントをすぐに検出できるようにもなる。

関連するイベント：イベントＡが発生すると、イベントＢは、ほとんどの場合、その２秒以内に発生する。

喪失したイベントやシーケンス外のイベント：イベントＡ、Ｂ、Ｃは、この順で発生するはずであるが、ＣがＡの直後に発生し、Ｂが発生しない。

原因となるイベント：製品の重さが徐々に減少したり、読み取り値が許容基準の範囲外になったりする。潜在的な問題や今後のメンテナンスの必要性について、信号を出す。

Ｏｒａｃｌｅ Ｓｔｒｅａｍ Ａｎａｌｙｔｉｃｓプラットフォーム設計環境およびランタイム実行では、リアルタイムイベントソーシングに加えて、イベントストリームならびに、データベースおよび高性能のデータグリッドのような永続データストアの両方に対して、標準ベースの連続クエリ実行がサポートされる。これによって、プラットフォームは、マイクロ秒のまたは数秒で、（そうでなければ見過ごされる可能性のある）パターンおよび傾向を認識するために回答を得る必要のあるシステムのインテリジェンスの中核として機能することができる。イベント処理のユースケースでは、数学的な正確性と標準データベースＳＱＬの信頼性とを備えた、高速のメモリ内処理が必要とされる。このプラットフォームのクエリは、受信イベントストリームを待ち受けて、クエリを最適化する高度な自動アルゴリズムを利用して、メモリ内で各イベントに対して登録済みクエリを連続して実行する。しかしながら、メモリ内実行モデルに基づいているものの、このプラットフォームは、クエリ開発に標準ＡＮＳＩ ＳＱＬ構文を活用するので、クエリ構成の正確性および拡張性が確保される。このプラットフォームは、ＡＮＳＩ ＳＱＬ'９９規格と完
全に互換性があり、ＡＮＳＩ ＳＱＬの審査を受けたリアルタイムの連続クエリパターンマッチングのための標準ＳＱＬの拡張機能をサポートした業界初の製品であった。ＣＱＬエンジンによって、プロセッサ内のクエリの実行が最適化されるので、開発者は、最適化よりもビジネスロジックに集中することができる。

Ｏｒａｃｌｅ Ｓｔｒｅａｍ Ａｎａｌｙｔｉｃｓプラットフォームでは、ＳＱＬとＪａｖａコードとを組み合わせて堅牢なイベント処理アプリケーションを提供することがで
きる。標準の業界用語を利用してイベントソース、プロセッサ、およびイベント出力またはイベントシンクを記述することにより、このプラットフォームは、アプリケーション内のイベントを定義および操作するためのメタデータ駆動型の手法を提供する。その開発者は、アプリケーション設計のための視覚的な、方向付きのグラフ・キャンバスおよびパレットを使用して、イベント間およびデータソース間のイベントおよび処理のフローの概略を素早く作成することができる。開発者は、ドラッグ・アンド・ドロップモデルと構成ウィザードとによってこのフローを作成し、適切なメタデータ定義を入力して、設計を実装に結びつけることができる。開発者は、必要性や好みに応じて、ワンクリックで、カスタムＪａｖａコード開発に変更したり、Ｓｐｒｉｎｇ（登録商標）フレームワークを用いて最新の概念をアプリケーションに直接コーディングしたりすることができる。

イベント駆動型アプリケーションは、多くの場合、非常に高速なストリーミング入力データを処理するにもかかわらず、レイテンシが低くかつ決定的（ｄｅｔｅｒｍｉｎｉｓｔｉｃ）でなければならない、という特徴がある。Ｏｒａｃｌｅ Ｓｔｒｅａｍ Ａｎａｌｙｔｉｃｓプラットフォームの土台は、ＯＳＧｉ（登録商標）バックプレーンに基づく軽量Ｊａｖａコンテナである。軽量Ｊａｖａコンテナは、セキュリティ、ロギング、および作業管理アルゴリズムなど、ＷｅｂＬｏｇｉｃ ＪＥＥ アプリケーションサーバの成熟したコンポーネントを含んでいるが、これらのサービスをリアルタイムのイベント処理環境で活用している。統合されたリアルタイムカーネルにより、一意のサービスが提供され、ＪＭＸフレームワークがサポートするスレッドおよびメモリ管理が最適化され、パフォーマンスおよび構成に関してコンテナとやり取りができるようになる。Ｗｅｂ２．０リッチインターネットアプリケーションは、ＨＴＴＰパブリッシュ／サブスクライブサービスを用いてプラットフォームと通信できる。ＨＴＴＰパブリッシュ／サブスクライブサービスは、Ｗｅｂ２．０リッチインターネットアプリケーションがアプリケーションチャネルを利用してイベントをクライアントにプッシュさせることを可能にする。小さいフットプリントでは、このプラットフォームは、軽量のＪａｖａベースのコンテナであり、本番への導入時間を短縮し、所有権の総コストを低減することができる。

Ｏｒａｃｌｅ Ｓｔｒｅａｍ Ａｎａｌｙｔｉｃｓプラットフォームは、最適にはＯｒａｃｌｅ Ｅｘａｌｏｇｉｃおよび他のＥｎｇｉｎｅｅｒｅｄ Ｓｙｓｔｅｍのポートフォリオを用いて、標準的な汎用ハードウェアに対してマイクロ秒の処理レイテンシで１秒あたり何百万というイベントを処理する能力がある。これは、完全な「トップダウン」の階層的ソリューションによって実現され、高パフォーマンスのイベント処理のユースケースだけでなく、エンタープライズクラスのリアルタイム処理インフラストラクチャコンポーネントとの緊密な統合にも設計の重点を置いている。パフォーマンス優先のサーバクラスタのプラットフォームアーキテクチャは、Ｏｒａｃｌｅ Ｃｏｈｅｒｅｎｃｅ技術への緊密な統合による信頼性、フォールトトレランス、および非常に高い柔軟性に重点を置いているため、ミッションクリティカルなアプリケーションをデータグリッドの端から端まで企業が予想どおりにスケーリングし、連続データの可用性およびトランザクション上の完全性を確実にすることができる。

これに加えて、このプラットフォームにより、決定的処理が可能になり、これは、同じイベントを複数のサーバに、または同じサーバに異なる速度で送り込むことができ、毎回同じ結果を達成することを意味する。これにより、動作中のサーバのシステムクロックにしか頼っていないシステムと比べて素晴らしい利点を得ることができる。

上述および後述の技術は、いくつかの方法およびいくつかのコンテキストで実現されてもよい。いくつかの例示的な実装形態およびコンテキストを以下の図面を参照しながら提供するが、さらに詳細は後述する。しかしながら、以下の実装形態およびコンテキストは、たくさんあるうちの一部である。

ジオフェンス・ベースのアプリケーションのための自動並列処理
自動車交通量監視などのアプリケーションでは、データは、連続データストリームの形である。連続データストリームは、はっきりとした終端範囲なしでストリーム処理サーバに到着するデータのストリームである。連続データストリームを処理することによって、アプリケーションは、複雑なパターン、イベント間の相関関係、およびイベント間の関係を検出できる。たとえば、連続データストリームは、高速道路の特定の区画を通過する車についての情報を有していてもよい。自動車は、位置座標を継続的に送ることができる。このデータストリームに基づいて、車両台数と他の車両を利用している人の数との「ｍ」対「ｎ」関係をソリューションが処理する必要がある状況において自動車の位置の近くにいる人を検出するなどの問題、または、車両台数が百万台にわたるときの問題を解決してもよい。

従来のデータベースシステムおよびデータ処理アルゴリズムにおいてサポートされる空間データは、通常、有限の格納データセットとして格納された空間データを処理するように設計されている。従来のデータベースシステムは、ＳＱＬなどのデータ管理言語を用いてデータが問い合わせおよび操作されるデータベーステーブルにデータを格納する。しかしながら、データベース管理システムおよびアルゴリズムは、ジオメトリの連続データストリームを処理できない。なぜならば、データベース管理システムおよびアルゴリズムは、大量であるが有限のデータの集まりをシステムが格納するという想定に基づいて設計されているからである。

メモリ資源が制限されているため、限られた数の移動オブジェクトしか１つのアプリケーションによってサポートすることができない。スケーラビリティの問題を解決するために、クラスタリングが利用され得る。しかしながら、単純なクラスタリングでは、上述した人検出問題など、特定のユースケースの問題を解決することができない。なぜならば、通常、処理ノード間でサポートする領域がいくつか重複している必要があるからである。

以前の手法では、ジオ・パーティショナを用いて上記の問題を解決していた。ジオ・パーティショナは、通常、領域が予め定義された距離を有して分割されるグリッドベースの手法、または、ジオメトリが入力ジオメトリをパーティション分割する領域を指定する領域ベースの手法に基づいている。この手法は、パーティションが固定であり、パーティションでの移動オブジェクトの変更を反映することができない静的手法である。たとえば、この手法は、グリッドに含まれる移動オブジェクトの数が突然増える、たとえば、スタジアムでの野球の試合が終了したときにタクシーの台数が増加するシナリオに対応できないと思われる。

特定の実施形態では、動的グリッドは、Ｋ－ＭｅａｎｓまたはＤＢＳＰＡＮなどの空間クラスタリングアルゴリズムに基づいて生成される。図１は、空間クラスタリングアルゴリズムを用いてパーティションのサイズを動的に決定するための技術が実装される例示的な動的グリッドシステムまたはアーキテクチャ１００を示す図である。様々な実施形態では、動的グリッドシステムまたはアーキテクチャ１００は、次のコンポーネントを含む。空間クラスタジェネレータ（ＳＣＧ：Ｓｐａｔｉａｌ Ｃｌｕｓｔｅｒ Ｇｅｎｅｒａｔｏｒ）１０５、クラスタベース・パーティショナ（ＣＢＰ：Ｃｌｕｓｔｅｒ Ｂａｓｅｄ
Ｐａｒｔｉｔｉｏｎｅｒ）１１０、および空間クエリプロセッサ（ＳＱＰ：Ｓｐａｔｉａｌ Ｑｕｅｒｙ Ｐｒｏｃｅｓｓｏｒ）１１５。空間クラスタジェネレータ１０５コンポーネントは、継続的にＫ－ＭｅａｎｓまたはＤＢＳＣＡＮなどの空間クラスタアルゴリズムを漸進的に実行して、入力ジオメトリからジオメトリクラスタを作成するように構成されてもよい。出力（クラスタジオメトリおよびクラスタに含まれるジオメトリの数）は、クラスタベース・パーティショナ１１０に送られてもよい。クラスタベース・パーティ
ショナ１１０コンポーネントは、入力ジオメトリをパーティション分割して、どのジオメトリがどのパーティションに行くかを決定するように構成されてもよい。いくつかの実施形態では、クラスタベース・パーティショナ１１０は、パーティションサイズを動的に変更する役割がある。空間クエリプロセッサ１１５コンポーネントは、空間クエリを処理する。一例として、空間カートリッジ（Ｓｐａｔｉａｌ Ｃａｒｔｒｉｄｇｅ）を有するＣＱＬＥｎｇｉｎｅがある。各空間クエリプロセッサ１１５コンポーネントは、１つ以上のパーティションを処理するように構成されてもよい。図１に示すコンポーネントのうちの１つ以上は、ソフトウェアで、ハードウェアで、またはそれらの組合せで実現されてもよい。いくつかの実施形態では、ソフトウェアは、メモリ（たとえば、非一時的なコンピュータ読み取り可能な媒体）に、メモリ素子または他の物理メモリ上に格納されてもよく、１つ以上の処理装置（たとえば、１つ以上のプロセッサ、１つ以上のプロセッサコア、１つ以上のＧＰＵなど）によって実行されてもよい。

図２～図４は、いくつかの実施形態に係る空間クラスタリングアルゴリズムを用いてパーティションのサイズを動的に決定するための技術を説明する図である。個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明される場合もある。フローチャートは、逐次プロセスとして動作を示し得るが、これらの動作の多くのは、平行してまたは同時に実行してもよい。これに加えて、動作の順序は、並び替えられてもよい。プロセスは、その動作が完了したときに終了するが、図に含まれない追加ステップを有し得る。プロセスは、方法、関数、プロシージャ、サブルーチン、サブプログラムなどに相当してもよい。プロセスが関数に相当する場合、その終了は、呼び出し関数またはメイン関数へのこの関数の戻りに相当してもよい。

図２～図４に示す処理および／または動作は、１つ以上の処理装置（たとえば、プロセッサコア）によって実行されるソフトウェア（たとえば、コード、命令、プログラム）、ハードウェア、またはそれらの組合せで実現されてもよい。ソフトウェアは、（たとえば、メモリ素子上、非一時的なコンピュータ読み取り可能な記憶媒体上の）メモリに格納されてもよい。図２～図４の特定の一連の処理は、限定を意図したものではない。また、他のステップのシーケンスが別の実施形態に従って実行されてもよい。たとえば、別の実施形態では、概要を上述したステップを異なる順序で実行してもよい。また、図２～図４に示す個々のステップは、個々のステップに応じて様々なシーケンスで行なわれ得る複数のサブステップを含んでもよい。さらに、特定のアプリケーションに応じてさらなるステップが追加または削除されてもよい。当業者は、多くの変形例、変更例、および代替例が分かるだろう。

図２は、本開示の実施形態が実施する全体的なワークフローを説明するフローチャート２００を示す。いくつかの実施形態では、フローチャート２００に示す処理は、動的グリッドシステムまたは図１のアーキテクチャ１００によって実施されてもよい。ステップ２０５において、アプリケーションに関する連続データストリームを受信してもよい。ステップ２１０において、連続データストリームに関連付けられた入力ジオメトリを特定してもよい。入力ジオメトリは、連続データストリームにおけるパーティション分割される領域を指定してもよい。ステップ２１５において、入力ジオメトリをＳＣＧに送信してもよい。ステップ２２０において、ＳＣＧは、入力ジオメトリにインクリメンタル空間クラスタアルゴリズムを実行し、入力ジオメトリの少なくとも一部に基づいてジオメトリクラスタを生成してもよい。ステップ２２５において、ジオメトリクラスタおよびジオメトリクラスタに含まれる各クラスタにおけるジオメトリの数、の少なくとも一部に基づいて、ＳＣＧによって出力ジオメトリを生成してもよい。ステップ２３０において、ＳＣＧは、出力ジオメトリをＣＢＰに送信してもよい。ステップ２３５において、ＣＢＰは、ＳＣＧからのジオメトリクラスタおよびジオメトリの数を用いて出力ジオメトリの１つ以上のパー
ティションを決定してもよい。いくつかの実施形態では、ＣＢＰのパーティションアルゴリズムは、次の処理を含んでもよい。（ｉ）クラスタ変更検出、（ｉｉ）クラスタ削除、（ｉｉｉ）パーティションの変更、および（ｉｖ）入力ジオメトリへのパーティション識別子の割り当て。これらの処理はさらに詳細に後述する。ステップ２４０において、出力ジオメトリの１つ以上のパーティションのサイズを動的に変更してもよい。ステップ２４５において、連続データストリームに関連付けられた出力ジオメトリを、１つ以上のパーティションのサイズが動的に変更された状態で送信してもよい。

図３は、本開示の実施形態が実施するＣＢＰのクラスタ変更検出処理を説明するフローチャート３００を示す。いくつかの実施形態では、フローチャート３００に示す処理は、動的グリッドシステムまたは図１のアーキテクチャ１００によって実施されてもよい。特定の実施形態では、ＲＴｒｅｅインデックスなどのインデックスを用いてクラスタに変更があるかどうかの判断を行い、クラスタの変更を検出してもよい。ＲＴｒｅｅインデックスまたはＲ－ｔｒｅｅは、空間アクセス方法の、すなわち、地理的位置、四角形、または多角形などの多次元情報をインデックス付けするために使用されるツリーデータ構造である。ステップ３０５において、クラスタのバウンディングボックスをＲＴｒｅｅにロードしてもよい。ステップ３１０において、ＲＴｒｅｅインデックスに含まれる出力クラスタのルックアップを行い、それらのサイズを比較してもよい。たとえば、ジオメトリクラスタのバウンディングボックスをインデックスにロードしてもよく、ジオメトリクラスタを、ＲＴｒｅｅインデックス内の他のジオメトリクラスタと比較してもよい。クラスタのサイズを含む１つ以上のパラメータに基づいて比較が行われてもよい。ステップ３１５において、クラスタがインデックスから見つからなかった場合、クラスタが新しいクラスタであると判断がされてもよい。ステップ３２０において、クラスタが新しいクラスタである場合、古いクラスタサイズなしでパーティション変更処理を実行してもよい。ステップ３２５において、クラスタがインデックスから見つかった場合、クラスタが新しいクラスタではない（たとえば、既存クラスタ）との判断がされてもよい。ステップ３３０において、クラスタが新しいクラスタではない場合、サイズ閾値を特定してパーティションの変更を決定してもよい。たとえば、このサイズ変更がＸパーセントである場合、Ｘパーセントを用いてパーティション変更処理を実行してもよい。

図４は、本開示の実施形態が実施する、クラスタ削除処理、パーティションの変更処理、およびパーティション識別子の割り当て処理を説明するフローチャート４００を示す。いくつかの実施形態では、フローチャート４００に示す処理は、動的グリッドシステムまたは図１のアーキテクチャ１００によって実施されてもよい。ステップ４０５において、タイマを用いて所定時間ＳＣＧからクラスタが見つからなかった場合、ＲＴｒｅｅに含まれるクラスタを削除してもよい。ステップ４１０において、パーティションを変更してもよい。これには、グリッド範囲の決定、インデックステーブルをパーティション分割するためのグリッドインデックスの作成、および、パーティション識別子を割り当てる際にＲＴｒｅｅに格納されたクラスタオブジェクトが利用できるよう、インデックステーブルをパーティション分割するためのグリッドインデックスをクラスタオブジェクトに設定することが含まれてもよい。グリッド範囲の決定は、構成パラメータ、ＧｒｉｄＳｉｚｅ、ＳｉｚｅＥｆｆｅｃｔＦａｃｔｏｒ、およびＳＣＧから与えられたジオメトリの数によって実施されてもよい。例では、ＧｒｉｄＳｉｚｅは、式（ＧｒｉｄＳｉｚｅ／（ジオメトリ数×ＳｉｚｅＥｆｆｅｃｔＦａｃｔｏｒ）を適用することによって、ジオメトリの数を用いて調整されてもよい。クラスタのバウンディングボックスは、調整済みのＧｒｉｄＳｉｚｅによって分割されてもよく、これにより、新しいパーティションが作成されるまたはさらなるパーティションが追加される。例では、コンシステントハッシュ技術を用いてパーティション識別子を作成し、システムを負荷を分散させた状態に維持してもよい。グリッドインデックスは、パーティションＩＤに直接対応付けられないので、いくつかの実施形態では、ルックアップテーブルを用いてグリッドインデックスをパーティションＩＤに
対応付けてもよい。特定の実施形態では、クラスタ削除アルゴリズムは、パーティションＩＤの入力ジオメトリへの割り当てをさらに含んでもよい。パーティション識別子の割り当ては、ＲＴｒｅｅでクラスタを探索し、範囲比較によってグリッドを見つけ、インデックステーブルをパーティション分割するためのグリッドインデックスをルックアップすることによって行われてもよい。よって、本開示の実施形態は、空間クラスタリングとグリッドパーティション分割とを組合せた空間クラスタリングアルゴリズムを用いてパーティションのサイズを動的に決定するための技術を提供する。さらに、ジオメトリのストリームからパーティションおよびグリッドサイズを動的に変更するための技術を開示する。

図５は、本開示の実施形態に係る、入力ジオメトリ５０５、入力ジオメトリ５０５がロードされ得るＲＴｒｅｅなどのインデックス５１０、および、グリッド範囲とインデックステーブルをパーティション分割するためのグリッドインデックスとを含むグリッド５１５、のうちの少なくとも一部に基づいて生成されるジオメトリクラスタの例の説明図である。グリッドインデックスは、インデックス５１０に格納されたクラスタオブジェクトに設定される。

Ｓｐａｒｋストリーミングにおける空間変化検出器およびチェック・セット操作
本開示の実施形態は、ストリームに含まれる移動オブジェクトの近接検出およびチェックを実行する技術を提供する。様々な実施形態では、移動オブジェクトを追跡でき、２つの以上の移動オブジェクトが互いに近接している場合にアラートを作成できる空間変化検出器が開示されている。たとえば、空間変化検出器は、空港にある移動オブジェクトを追跡し、それらが所与の範囲内に接近しないようにすることができる。

いくつかの実施形態では、移動オブジェクトの追跡は、空間「ｗｉｔｈｉｎｄｉｓｔａｎｃｅ」演算を利用して実施されてもよい。しかしながら、移動オブジェクトがストリームの一部である場合、移動オブジェクトストリームの自己結合からのｎ！個の組合せの間の距離を算出しなければならない。ＧＰＳから２つの位置の間の距離を算出することは、比較的重い点演算であり得る。本開示の実施形態が実施する１つの解決法は、図６に示す空間変化検出器６００を利用することである。空間変化検出器６００は、ストリーム６０５のジオメトリ（たとえば、車両の位置についてのデータ）をリレーション６１０に変換し、ストリーム６０５とリレーション６１０との結合演算６１５を行う。ＦＲＯＭ句におけるＴａｂｌｅＥｘｐｒｅｓｓｉｏｎに含まれ得る結合演算は、２つのデータセットまたはテーブルセット間の結合を行う。これにより、リレーションからの空間インデックスを利用することができ、ｎ！個の組合せの距離の算出を回避する。空間インデックスは、空間カラムをインデックス付けさせる種類の拡張インデックスである。空間カラムは、ｇｅｏｍｅｔｒｙ型またはｇｅｏｇｒａｐｈｙ型など、空間データ型のデータを含んでいるテーブルカラムである。空間インデックスが活用される場合、範囲を用いてフィルタが適用され得、フィルタ処理された結果から距離が算出され得る。これにより、ｎ乗演算が得られる。ストリーム６０５をリレーション６１０に変換するために、同じキーのコンテンツの変更が検出されてもよい。実施形態では、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ６２０を使用して、コンテンツの変更があるかどうかを検出し、「更新」イベントを発行し、ストリーム６０５をリレーション６１０に変換してもよい。ＨａｓｈＭａｐなどのメモリ内キャッシュ６２０は、よく要求されるデータをメモリに保持することによってアプリケーションのパフォーマンスを向上させるように設計されてもよく、そのデータを取得するためのデータベースクエリの必要性を小さくする。その後、ストリーム６０５およびリレーション６１０を空間「ｗｉｔｈｉｎｄｉｓｔａｎｃｅ」演算６２５に用いて移動オブジェクト同士のリレーションを追跡し、近接検出を行うことができる。「ｗｉｔｈｉｎｄｉｓｔａｎｃｅ」などの空間演算は、ジオメトリ関数を用いて空間データを入力として取り、データを分析し、その後、入力データに対して行われた分析の派生物である出力データを生成する。

いくつかの実施形態では、チェック・セット操作（ｃｈｅｃｋ ａｎｄ ｓｅｔ ｏｐｅｒａｔｉｏｎ）を実施してもよい。たとえば、（たとえば、乗客からの要求でタクシーを派遣している間に）オブジェクトのストリームに対する要求・照会操作がある場合、当該照会からのアービトレーションが必要である。上記の例について、乗客要求ストリームから、特定の範囲内のタクシーを決定することができる。候補のタクシーが見つかると、それらのタクシーの中から１台が選ばれて、ほかの乗客が同じタクシーのダブルブッキングを回避できるように、「予約済み」とマークされる。ＣＱＬはクエリ言語であり、手続き型言語ではないので、チェック操作およびセット操作は、同じ時間に行うことができない。

このようなチェック・セット操作をサポートする１つの方法に、メモリ内キャッシュ（または、ＨａｓｈＭａｐ）を使用する方法がある。並列処理のためのアトミック操作として用いられるテスト・アンド・セットまたはコンペア・アンド・スワップと同様に、メモリ内キャッシュ７０５がサポートする図７に示すセット（ＣｈｅｃｋＡｎｄＳｅｔ）検出器７００は、第１ストリーム７１０のジオメトリ（たとえば、車両の位置についてのデータ）をリレーション７１５に変換し、リレーション７１５と第２ストリーム７２５（たとえば、要求の位置についてのデータ）との間でチェック・セット操作７２０を行うように構成されてもよい。これにより、リレーションからの空間インデックスを利用することができ、ｎ！個の組合せ間の距離の算出を回避する。空間インデックスを活用する場合、範囲を用いてフィルタが適用され得、フィルタ処理された結果から距離が算出され得る。これにより、ｎ乗演算が得られる。第１ストリーム７１０をリレーション７１５に変換するために、同じキーのコンテンツの変更が検出されてもよい。実施形態では、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ７０５を用いて、コンテンツの変更があるかどうかを検出し、「更新」イベントを発行し、第１ストリーム７１０をリレーション７１５に変換してもよい。その後、チェック・セット操作７２０においてリレーション７１５および第２ストリーム７２５を、第１ストリーム７１０からのデータを第２ストリーム７２５からのデータと照合して（たとえば、乗客が要求した場所に近いタクシーが選ばれてもよい）エントリ・オブジェクトのプロパティを設定する（たとえば、ほかの乗客がダブルブッキングを回避できるようにタクシーを「ｂｏｏｋｅｄ（予約済み）」と印を付ける）よう、用いることができる。特定の実施形態では、「ｓｅｌｅｃｔ ｐａｓｓｅｎｇｅｒＩｄ， ｔａｘｉＩｄ ｆｒｏｍ ｔａｘｉＲｅｌａｔｉｏｎ， ｒｅｑｕｅｓｔＳｔｒｅａｍ ｗｈｅｒｅ ｔａｘｉＣａｃｈｅ．ｃｈｅｃｋＡｎｄＳｅｔ（‘ｂｏｏｋｅｄ'，ｔｒｕｅ）」などのｓｅｌｅｃｔステートメントを用いて、エントリ
・オブジェクトの「ｂｏｏｋｅｄ」プロパティがｔａｘｉＣａｃｈｅにおいて「ｆａｌｓｅ」であるかどうかをチェックし、「ｂｏｏｋｅｄ」プロパティをｔｒｕｅに設定し、ｔｒｕｅを返し、エントリを変更することの副作用を作成しつつ、フィルタを結果に適用することができる。

様々な実施形態では、チェック・セット操作は、メモリ内キャッシュ（または、ＨａｓｈＭａｐ）を使用する必要があり、以下のように実施されてもよい。

ＣａｃｈｅＤＳｔｒｅａｍおよびＣａｃｈｅＲＤＤを追加する
ＣＱＬＥｎｇｉｎｅがシングルトンのＣａｃｈｅを作成する。

ＣＱＬＥｎｇｉｎｅがデリゲートによってＣａｃｈｅメソッドのＲＰＣ操作を追加する。

ＣａｃｈｅＲＤＤをＣＱＬＥｎｇｉｎｅと共通にパーティション分割（ｃｏ－ｐａｒｔｉｔｉｏｎｅｄ）すべきである。

ＣａｃｈｅＲＤＤは、キャッシュＲＰＣ操作によってキャッシュ操作をＣＱＬＥｎｇｉｎｅにデリゲートする
Ｃａｃｈｅ－変更を検知するための通常操作
if (get(key) == null) {
put
add(new TupleValue(PLUS, ...))
} else {
put
add(new TupleValue(UPDATE, ...)
}
if (expiredTupleQueue.size > 0) {
待ち行列からすべてのタプルを削除して削除
add(new TupleValue(MINUS, ...)
}
キャッシュは、タイマを開始してタプルを自己満了させ、満了したタプルを待ち行列ｅｘｐｉｒｅｄＴｕｐｌｅＱｕｅｕｅに追加する
キャッシュは、ＣｈｅｃｋＡｎｄＳｅｔ操作も有する
value = get(key)
if (value.getProperty(property) != newValue)
value.setProperty(property, newValue)
return true
else return false
このように、上記技術を用いて、開示の空間変化検出器は、ジオメトリデータストリームに対する空間「ｗｉｔｈｉｎｄｉｓｔａｎｃｅ」演算がより高速で実行されることを可能にし、開示のチェック・セット操作は、アービトレーションにＣＱＬを提供することを可能にする。上記技術を用いて、移動オブジェクトの近接チェックおよび要求・派遣システムなどのジオ・ストリーミングのユースケースを実施することができる。

図８は、ストリームに含まれる移動オブジェクトの近接検出およびチェックを行うための技術およびチェック・セット操作が実施され得る例示的なシステムまたはアーキテクチャを示す図である。いくつかの実施形態では、イベント処理サービス、または、イベントストリームを処理するための環境を提供するように構成されたシステム８００は、ＣＱＬプロセッサ８０５と、ＪＡＶＡカートリッジ８１０と、タイマ８１５と、メモリ内キャッシュ８２０と、ＣａｃｈｅＲＤＤ８２５とを備える。ＣＱＬプロセッサ８０５は、入力チャネルが提供するイベントに対して動作する１つ以上のＣＱＬクエリに関連付けられてもよい。ＣＱＬプロセッサは、クエリ結果が書き込まれる出力チャネルに接続される。タイマ８１５は、有効期限を過ぎたデータを編成またはメモリ内キャッシュ８２０から削除するために使用されてもよい。少なくとも図６および図７に関して本明細書において説明するように、ＣａｃｈｅＲＤＤ８２５は、データストリーム８３０を受信し、メモリ内キャッシュ８２０を利用してデータストリームをリレーション８３５に変換してもよい。

図９は、本開示の実施形態を組み込み得るイベント処理システム２００の簡略化されたハイレベル図を示す。いくつかの実施形態では、イベント処理システム９００は、１つ以上のイベントソース（９０４、９０６、９０８）と、イベントストリームを処理するための環境を提供するように構成されるイベント処理サービス（ＥＰＳ）９０２（ＣＱサービス９０２とも称する）と、１つ以上のイベントシンク（イベントシンク）（９１０、９１２）を含んでもよい。イベントソースは、ＥＰＳ９０２によって受信されるイベントストリームを生成する。ＥＰＳ９０２は、１つ以上のイベントソースから１つ以上のイベントストリームを受信してもよい。たとえば、図９に示すように、ＥＰＳ９０２は、イベント
ソース９０４から第１の入力イベントストリーム９１４を受信し、イベントソース９０６から第２の入力イベントストリーム９１６を受信し、イベントソース９０８から第３のイベントストリーム９１８を受信する。１つ以上のイベント処理アプリケーション（９２０、９２２、および９２４）がＥＰＳ９０２上でデプロイされてＥＰＳ９０２によって実行されてもよい。ＥＰＳ９０２が実行するイベント処理アプリケーションは、１つ以上の入力イベントストリームを待ち受けて、入力イベントストリームから１つ以上のイベントを注目イベントとして選択する処理ロジックに基づいて１つ以上のイベントストリームを介して受信したイベントを処理するように構成されてもよい。次に、注目イベントが１つ以上の出力イベントストリームの形で１つ以上のイベントシンク（９１０、９１２）に送られてもよい。たとえば、図９において、ＥＰＳ９０２は、第１の出力イベントストリーム９２６をイベントシンク９１０に出力し、第２の出力イベントストリーム９２８をイベントシンク９１２に出力する。特定の実施形態では、イベントソース、イベント処理アプリケーション、およびイベントシンクは、１つのコンポーネントがその他のコンポーネントに変更を生じさせずにこれらのコンポーネントのうちのいずれかを追加または削除できるよう、互いから切り離される。

一実施形態では、ＥＰＳ９０２は、共用サービスを有する、Ｅｑｕｉｎｏｘ ＯＳＧｉに基づいたものなどの軽量Ｊａｖａアプリケーションコンテナを含んだＪａｖａサーバとして実装されてもよい。いくつかの実施形態では、ＥＰＳ９０２は、たとえば、ＪＲｏｃｋｉｔ Ｒｅａｌ Ｔｉｍｅを用いることによって、イベントを処理するための超高スループットおよびマイクロ秒のレイテンシをサポートしてもよい。また、ＥＰＳ９０２は、イベント処理アプリケーションを開発するためのツール（たとえば、Ｏｒａｃｌｅ ＣＥＰ ＶｉｓｕａｌｉｚｅｒおよびＯｒａｃｌｅ ＣＥＰ ＩＤＥ）を含んだ開発プラットフォーム（たとえば、完全リアルタイムのエンドツーエンドＪａｖａイベント駆動型アーキテクチャ（ＥＤＡ：Ｊａｖａ Ｅｖｅｎｔ－Ｄｒｉｖｅｎ Ａｒｃｈｉｔｅｃｔｕｒｅ）開発プラットフォーム）を提供してもよい。

イベント処理アプリケーションは、１つ以上の入力イベントストリームを待ち受けて、１つ以上の入力イベントストリームから１つ以上の注目イベントを選択するためのロジック（たとえば、クエリ）を実行し、選択された注目イベントを１つ以上の出力イベントストリームを介して１つ以上のイベントソースに出力するように構成される。図９は、１つのこのようなイベント処理アプリケーション９２０のドリルダウンを示す図である。図９に示すように、イベント処理アプリケーション９２０は、入力イベントストリーム９１８を待ち受けて、入力イベントストリーム９１８から１つ以上の注目イベントを選択するためのロジックを含んだ連続クエリ９３０を実行し、選択された注目イベントを出力イベントストリーム９２８を介してイベントシンク９１２に出力するように構成される。イベントソースとして、アダプタ（たとえば、ＪＭＳ、ＨＴＴＰ、およびファイル）、チャネル、プロセッサ、テーブル、キャッシュなどが挙げられるが、これらに限定されない。イベントシンクとして、アダプタ（たとえば、ＪＭＳ、ＨＴＴＰ、およびファイル）、チャネル、プロセッサ、キャッシュなどが挙げられるが、これらに限定されない。

図９のイベント処理アプリケーション０２０は、１つの入力ストリームを待ち受けて、選択されたイベントを１つの出力ストリームを介して出力する、として示されているが、これは、限定を意図したものではない。別の実施形態では、イベント処理アプリケーションは、１つ以上のイベントソースから受信した複数の入力ストリームを待ち受けて、監視されているストリームからイベントを選択し、選択されたイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントシンクに出力するように構成されてもよい。同じクエリが２つ以上のイベントシンクに関連付けられ得、互いに異なる種類のイベントシンクと関連付けられ得る。

イベントストリームが本質的に無限であるため、イベントストリームを介して受信したデータの量は、一般に、大量である。したがって、一般に、クエリ目的のためにすべてのデータを格納またはアーカイブすることは実用的でなく、望ましくない。イベントストリームの処理は、ＥＰＳ９０２によってイベントが受信されると、すべての受信イベントデータを格納せずに当該イベントをリアルタイムで処理することが必要である。したがって、ＥＰＳ９０２は、イベントがＥＰＳ９０２によって受信されると受信したイベントのすべてを格納しなくても当該イベントの処理が実行されることを可能にする特殊な問い合わせメカニズムを提供する。

イベント駆動型アプリケーションは、ルール駆動型であり、ルールは、入力ストリームを処理するために使用される連続クエリの形で表現されてもよい。連続クエリは、受信したイベントについて実行する、どのイベントを注目イベントとして選択するか、およびどのイベントをクエリ処理の結果として出力するのかを含む処理を特定する命令（たとえば、ビジネスロジック）を含んでもよい。連続クエリは、データストアに永続化され、イベントの入力ストリームを処理およびイベントの出力ストリームを生成するために使用されてもよい。連続クエリは、通常、入力イベントストリームから注目イベントを発見および取り出すためのフィルタ処理機能およびアグリゲーション機能を実行する。その結果、出力イベントストリームに含まれるアウトバウンド・イベントの数は、一般に、イベントの選択元の入力イベントストリームに含まれるイベントの数よりも遙かに少ない。

有限なデータセットに対して１回実行されるＳＱＬクエリとは異なり、特定のイベントストリームのためにアプリケーションがＥＰＳ９０２に登録している連続クエリは、イベントがそのイベントストリームにおいて受信されるたびに実行されてもよい。連続クエリ実行の一部として、ＥＰＳ９０２は、受信したイベントを、連続クエリが指定した命令に基づいて評価し、１つ以上のイベントが注目イベントとして選択されるかどうかを判断し、連続クエリ実行の結果として出力する。

連続クエリは、互いに異なる言語を用いてプログラミングされてもよい。特定の実施形態では、連続クエリは。Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎが提供し、Ｏｒａｃｌｅの複合イベント処理（ＣＥＰ：Ｃｏｍｐｌｅｘ Ｅｖｅｎｔｓ Ｐｒｏｃｅｓｓｉｎｇ）製品の提供によって利用されるＣＱＬを利用して構成されてもよい。ＯｒａｃｌｅのＣＱＬは、イベントストリームに対して実行され得るクエリ（ＣＱＬクエリと称する）をプログラミングするために使用され得る宣言型言語である。特定の実施形態では、ＣＱＬは、イベントデータをストリーム配信する処理をサポートする構成が追加されたＳＱＬに基づいている。

一実施形態では、イベント処理アプリケーションは、次のコンポーネント型によって構成されてもよい。
（１）入出力ストリーム、ならびに、リレーションソースおよびリレーションシンクに直接インタフェース接続される１つ以上のアダプタ。アダプタは、入出力ストリームプロトコルを理解するように構成され、かつ、アプリケーションプロセッサが問い合わせし得る正規化された形式にイベントデータを変換する責任がある。アダプタは、正規化されたイベントデータをチャネルまたは出力ストリームおよびリレーションシンクに転送してもよい。イベントアダプタは、様々なデータソースおよびデータシンク用に規定されてもよい。
（２）イベント処理エンドポイントとして機能する１つ以上のチャネル。特に、チャネルは、イベント処理エージェントがイベントデータに対して作用できるようになるまで当該イベントデータを待ち行列に入れる責任がある。
（２）１つ以上のアプリケーションプロセッサ（または、イベント処理エージェント）は、チャネルからの正規化されたイベントデータを消費し、それをクエリを用いて処理して
注目イベントを選択し、選択された注目イベントを出力チャネルに転送する（または、コピーする）ように構成される。
（４）１つ以上のＢｅａｎは、出力チャネルを待ち受けるように構成され、新しいイベントが出力チャネルに挿入されることによりトリガされる。いくつかの実施形態では、このユーザコードは、ＰＯＪＯ（Ｐｌａｉｎ－Ｏｌｄ－Ｊａｖａ－Ｏｂｊｅｃｔ）である。ユーザアプリケーションは、ＪＭＳ、Ｗｅｂサービス、およびファイルライターなど、外部サービスのセットを利用して、生成されたイベントを外部のイベントシンクに転送することができる。
（５）イベントＢｅａｎは、出力チャネルを待ち受けるために登録されてもよく、新しいイベントが出力チャネルに挿入されることによりトリガされる。いくつかの実施形態では、このユーザコードは、ＢｅａｎをＯｒａｃｌｅ ＣＥＰで管理できるように、Ｏｒａｃｌｅ ＣＥＰイベントＢｅａｎ ＡＰＩを利用してもよい。

一実施形態では、イベントアダプタがイベントデータを入力チャネルに提供する。入力チャネルは、入力チャネルが提供するイベントに対して動作する１つ以上のＣＱＬクエリに関連付けられたＣＱＬプロセッサに接続される。ＣＱＬプロセッサは、クエリ結果が書き込まれる出力チャネルに接続される。

いくつかの実施形態では、イベント処理アプリケーションのためにアセンブリファイルが提供されてもよい。イベント処理アプリケーションには、イベント処理アプリケーションの様々なコンポーネント、コンポーネントがどのように互いに関連するか、アプリケーションが処理するイベント型が記述されている。イベントを選択するために連続クエリまたはビジネスロジックを指定するための別々のファイルが提供されてもよい。

図９に示すシステム９００が、図９に示すコンポーネント以外のコンポーネントを有し得ることを理解されたい。さらに、図９に示す実施形態は、本開示の実施形態を組み込み得るシステムの一例に過ぎない。他のいくつかの実施形態では、システム９００は、図９に示すコンポーネントよりも多いまたは少ないコンポーネントを有してもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの構成または配置が異なっていてもよい。システム９００は、サービスプロバイダコンピュータ、パーソナルコンピュータ、ポータブルデバイス（たとえば、携帯電話またはモバイルデバイス）、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、またはその他のデータ処理システムを含む、様々な種類のうちの１つであり得る。他のいくつかの実施形態では、システム９００は、システム９００の１つ以上のコンポーネントがクラウドにおける１つ以上のネットワーク間で分散している分散システムとして構成されてもよい。

図９に示すコンポーネントのうちの１つ以上は、ソフトウェアで、ハードウェアで、またはそれらの組合せで実現されてもよい。いくつかの実施形態では、ソフトウェアは、メモリ（たとえば、非一時的なコンピュータ読み取り可能な媒体）に、メモリ素子または他の物理メモリ上に格納されてもよく、１つ以上の処理装置（たとえば、１つ以上のプロセッサ、１つ以上のプロセッサコア、１つ以上のＧＰＵなど）によって実行されてもよい。

図１０は、いくつかの実施形態に係る、空間変化検出およびチェック・セット操作のための技術を説明する図である。個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明される場合もある。フローチャートは、逐次プロセスとして動作を示し得るが、動作の多くのは、平行して、または同時に実行してもよい。これに加えて、動作の順序は、並び替えられてもよい。プロセスは、その動作が完了したときに終了するが、図に含まれないステップをさらに有し得る。プロセスは、方法、関数、プロシージャ、サブルーチン、サブプログラムなどに
相当してもよい。プロセスが関数に相当する場合、その終了は、呼び出し関数またはメイン関数へのこの関数の戻りに相当してもよい。

図１０に示す処理および／または動作は、１つ以上の処理装置（たとえば、プロセッサコア）によって実行されるソフトウェア（たとえば、コード、命令、プログラム）、ハードウェア、またはそれらの組合せで実現されてもよい。ソフトウェアは、（たとえば、メモリ素子上、非一時的なコンピュータ読み取り可能な記憶媒体上の）メモリに格納されてもよい。図１０の特定の一連の処理は、限定を意図したものではない。また、他のステップシーケンスが別の実施形態に従って実行されてもよい。たとえば、別の実施形態では、概要を上述したステップを異なる順序で実行してもよい。また、図１０に示す個々のステップは、個々のステップに応じて様々なシーケンスで行なわれ得る複数のサブステップを含んでもよい。さらに、特定のアプリケーションに応じてさらなるステップが追加または削除されてもよい。当業者は、多くの変形例、変更例、および代替例が分かるだろう。

図１０は、本開示の実施形態が実施する空間変化検出および／またはチェック・セット操作を説明するフローチャート１０００を示す図である。いくつかの実施形態では、フローチャート１０００に示す処理は、図８および図９のイベント処理システムによって実施されてもよい。ステップ１００５において、アプリケーションに関する第１の連続データストリームを受信する。ステップ１０１０において、第１の連続データストリームのジオメトリをリレーションに変換する。リレーションは、第１の連続データストリームのジオメトリの空間インデックスを含んでもよい。特定の実施形態では、範囲を有するフィルタが空間インデックスに適用され、第１の連続データストリームのジオメトリについてのフィルタ処理された結果が得られる。いくつかの実施形態では、この変換は、第１の連続データストリームのジオメトリに変更があるかどうかを判断し、第１の連続データストリームのジオメトリに変更があった場合、更新イベントを発行することを含む。更新イベントは、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ上で発行される。

ステップ１０１５において、第１の連続データストリームにおいて、複数の移動オブジェクトを追跡する。この追跡は、少なくとも第１の移動オブジェクトの第２の移動オブジェクトとの関係を追跡するために空間演算を用いて実行されてもよい。ステップ１０２０において、複数の移動オブジェクトにおける少なくとも第１の移動オブジェクトと第２の移動オブジェクトとの関係を、第１の連続データストリームのジオメトリおよびリレーションのうちの少なくとも１つに基づいて判断またはチェックする。特定の実施形態では、第１の連続データストリームのジオメトリおよびリレーションは、追跡の前に結合演算を用いて結合されている。

必要に応じて、アプリケーションに関する第２の連続データストリームを受信し、複数の移動オブジェクトのうちの少なくとも１つの移動オブジェクトと第２の連続データストリームに含まれるオブジェクトとの関係を、リレーションおよび第２の連続データストリームのジオメトリに少なくとも基づいて判断またはチェックする。いくつかの実施形態では、当該関係の判断は、第１の連続データストリームのジオメトリおよびリレーションに少なくとも基づいて、少なくとも、複数の移動オブジェクトにおける第１の移動オブジェクトと第２の移動オブジェクトとの近接を判断することを含む。他の実施形態では、当該関係の判断は、リレーションおよび第２の連続データストリームのジオメトリに少なくとも基づいて、少なくとも、複数の移動オブジェクトのうちの当該移動オブジェクトと第２の連続データストリームに含まれるオブジェクトとの近接を判断することを含む。当該近接の判断は、フィルタ処理された結果を用いて第１の移動オブジェクトと第２の移動オブジェクトとの距離を算出すること、または、複数の移動オブジェクトのうちの当該移動オブジェクトと第２の連続データストリームに含まれるオブジェクトとの距離を算出するこ
とを含んでもよい。

ステップ１０２５において、判断された関係に基づいてアクションを取る。様々な実施形態では、このアクションは、リレーション、第１の連続データストリームのジオメトリ、および第２の連続データストリームのジオメトリ、のうちの１つ以上に適用される操作を介して実行される。いくつかの実施形態では、このアクションは、少なくとも第１の移動オブジェクトと第２の移動オブジェクトとの近接が予め定められた閾値を超える場合にアラートを生成することを含む。他の実施形態では、このアクションは、関係が予め定められた基準を満たす場合、たとえば、予め定められた閾値を超える場合、移動オブジェクトのプロパティを設定することを含む。

例示的なシステム
図１１～図１３は、様々な実施形態に係る本開示の態様を実現するための例示的な環境の態様を説明する図である。図１１は、本開示の実施形態を実現するための分散システム１１００の簡略図である。図示した実施形態では、分散システム１１００は、１つ以上のクライアントコンピューティングデバイス１１０２、１１０４、１１０６、および１１０８を備える。１つ以上のクライアントコンピューティングデバイス１１０２、１１０４、１１０６、および１１０８は、１つ以上のネットワーク（複数可）１１１０でウェブブラウザ、プロプライエタリ・クライアント（たとえば、Ｏｒａｃｌｅ Ｆｏｒｍｓ）などのクライアントアプリケーションを実行および操作するように構成される。サーバ１１１２は、ネットワーク１１１０を介して、リモートクライアントコンピューティングデバイス１１０２、１１０４、１１０６、および１１０８と通信可能に接続されてもよい。

様々な実施形態では、サーバ１１１２は、素性管理サービスを提供するサービスおよびアプリケーションなど、１つ以上のサービスまたはソフトウェア・アプリケーションを実行するようになされてもよい。また、特定の実施形態では、サーバ１１１２は、非仮想環境および仮想環境を含み得る他のサービスまたはソフトウェア・アプリケーションを提供してもよい。いくつかの実施形態では、これらのサービスは、クライアントコンピューティングデバイス１１０２、１１０４、１１０６、および／または１１０８のユーザに対して、ウェブベースのサービスもしくはクラウドサービスとして提供されてもよく、または、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）モデル下で提供されてもよい。そして、クライアントコンピューティングデバイス１１０２、１１０４、１１０６、および／または１１０８を操作するユーザは、１つ以上のクライアントアプリケーションを利用して、サーバ１１１２とやり取りして、これらのコンポーネントが提供するサービスを利用できる。

図１１に示す構成において、システム１１００のソフトウェアコンポーネント１１１８、１１２０、および１１２２が、サーバ１１１２上に実装されたものとして示される。また、他の実施形態では、システム１１００のコンポーネントのうちの１つ以上および／またはこれらのコンポーネントが提供するサービスのうちの１つ以上は、クライアントコンピューティングデバイス１１０２、１１０４、１１０６、および／または１１０８のうちの１つ以上によって実現されてもよい。次に、クライアントコンピューティングデバイスを操作しているユーザは、１つ以上のクライアントアプリケーションを利用して、これらのコンポーネントが提供するサービスを使用してもよい。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。様々な異なるシステム構成が可能であり、これらは、分散型システム１１００とは異なってもよいことを理解されたい。よって、図１１に示す実施形態は、実施形態のシステムを実現するための分散システムの一例であり、限定を意図したものではない。

クライアントコンピューティングデバイス１１０２、１１０４、１１０６、および／ま
たは１１０８は、様々な種類のコンピュータシステムを含んでもよい。たとえば、クライアントデバイスは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ（登録商標）などのソフトウェアおよび／またはｉＯＳ、Ｗｉｎｄｏｗｓ（登録商標）Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ、ＢｌａｃｋＢｅｒｒｙ １０、Ｐａｌｍ ＯＳなどのいろいろなモバイルオペレーティングシステムを実行する手のひらサイズのポータブルデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブルデバイス（たとえば、Ｇｏｏｇｌｅ
Ｇｌａｓｓ（登録商標）ヘッドマウントディスプレイ）を含んでもよい。デバイスは、様々なインターネット関連アプリ、電子メール、ショートメッセージサービス（ＳＭＳ）アプリケーションなど、様々なアプリケーションをサポートしてもよく、様々な他の通信プロトコルを使用してもよい。また、クライアントコンピューティングデバイスは、一例として、様々なバージョンのＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）、および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む、汎用パーソナルコンピュータを含んでもよい。クライアントコンピューティングデバイスは、これらに限定されないが、たとえば、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ
ＯＳなど、いろいろなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを含む、流通している各種のＵＮＩＸ（登録商標）またはＵＮＩＸ（登録商標）に似たオペレーティングシステムを実行するワークステーションコンピュータであり得る。また、クライアントコンピューティングデバイスは、シンクライアントコンピュータ、インターネット対応のゲーミングシステム（たとえば、Ｋｉｎｅｃｔ（登録商標）ジェスチャ入力装置付きまたは無しのＭｉｃｒｏｓｏｆｔ Ｘｂｏｘのゲーミングコンソール）、および／またはパーソナルメッセージングデバイスなど、ネットワーク（複数可）１１１０で通信可能な電子機器を含んでもよい。

図１１の分散システム１１００は、４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサ付きデバイスなど、他のデバイスがサーバ１１１２とやり取りを行ってもよい。

分散システム１１００におけるネットワーク（複数可）１１１０は、これらに限定されないが、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＳＮＡ（Ｓｙｓｔｅｍｓ Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＩＰＸ（Ｉｎｔｅｒｎｅｔ ｐａｃｋｅｔ ｅｘｃｈａｎｇｅ）、ＡｐｐｌｅＴａｌｋなどを含む、各種の利用可能なプロトコルを使用したデータ通信をサポートできる、当業者にとってなじみの任意の種類のネットワークであってもよい。単に一例として、ネットワーク（複数可）１１１０は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、Ｅｔｈｅｒｎｅｔ（登録商標）ベースのネットワーク、トークンリング、ワイドエリアネットワーク、インターネット、仮想ネットワーク、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、イントラネット、エクストラネット、ＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）、赤外線ネットワーク、ワイヤレスネットワーク（たとえば、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ Ｏｆ Ｅｌｅｃｔｒｉｃａｌ Ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ）１００２．１１スイートのプロトコル、Ｂｌｕｅｔｏｏｔｈ（登録商標）、および／またはその他のワイヤレスプロトコルのうちのいずれかの下で動作するネットワーク）、および／またはこれらの任意の組合せならびに／もしくは他のネットワークで有り得る。

サーバ１１１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（一例として、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジ・サーバ、メインフレーム・コンピュータ、ラックマウント式のサーバな
どを含む）、サーバファーム、サーバクラスタ、またはその他の適切な配置および／または組合せから構成されてもよい。サーバ１１１２は、仮想オペレーティングシステムを実行している１つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャを含み得る。論理記憶装置の１つ以上のフレキシブルプールを仮想化して、サーバ用の仮想記憶装置を維持することができる。仮想ネットワークは、ソフトウェア定義ネットワーキングを使用して、サーバ１１１２によって制御することができる。様々な実施形態において、サーバ１１１２は、上記の開示において説明した１つ以上のサービスまたはソフトウェア・アプリケーションを実行するようになされてもよい。たとえば、サーバ１１１２は、本開示の実施形態に係る上述した処理を実行するためのサーバに相当してもよい。

サーバ１１１２は、上述のオペレーティングシステムのいずれかおよび市販されているサーバオペレーティングシステムのうちのいずれかを含むオペレーティングシステムを実行してもよい。また、サーバ１１１２は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）サーバ、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サーバ、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む、各種の追加のサーバアプリケーションおよび／またはミッドティア・アプリケーションを実行してもよい。例示的なデータベースサーバとして、Ｏｒａｃｌｅ、Ｍｉｃｒｏｓｏｆｔ、Ｓｙｂａｓｅ、ＩＢＭ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ）などから市販されているデータベースサーバが挙げられるが、これらに限定されない。

いくつかの実装形態では、サーバ１１１２は、クライアントコンピューティングデバイス１１０２、１１０４、１１０６、および１１０８のユーザから受信したデータフィードおよび／またはイベント更新を分析および１つにまとめるための１つ以上のアプリケーションを含んでもよい。例として、データフィードおよび／またはイベント更新は、これらに限定されないが、１つ以上のサードパーティ情報ソースおよび連続したデータストリームから受信するＴｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新またはリアルタイム更新を含んでもよく、当該１つ以上のサードパーティ情報ソースおよび連続したデータストリームは、センサーデータアプリケーション、チッカー、ネットワークパフォーマンス測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通量監視などに関するリアルタイムイベントを含み得る。また、サーバ１１１２は、クライアントコンピューティングデバイス１１０２、１１０４、１１０６、および１１０８の１つ以上の表示装置を介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含んでもよい。

また、分散システム１１００は、１つ以上のデータベース１１１４および１１１６を含んでもよい。これらのデータベースは、ユーザ識別情報、および本開示の実施形態が用いるその他の情報などの情報を格納するためのメカニズムを提供してもよい。データベース１１１４および１１１６は、いろいろな場所に存在してもよい。一例として、データベース１１１４および１１１６のうちの１つ以上は、サーバ１１１２にローカルな（および／または存在する）非一時的な記憶媒体上に存在してもよい。これに代えて、データベース１１１４および１１１６は、サーバ１１１２から遠隔の場所に存在し、ネットワークベースまたは専用の接続を通してサーバ１１１２と通信していてもよい。一組の実施形態では、データベース１１１４および１１１６は、ＳＡＮ（Ｓｔｏｒａｇｅ－Ａｒｅａ Ｎｅｔｗｏｒｋ）に存在してもよい。同様に、サーバ１１１２に起因する機能を実行するための必要なファイルは、いずれも、サーバ１１１２上のローカルな場所および／またはサーバ１１１２から遠隔の場所に、適宜、格納されてもよい。一組の実施形態では、データベース１１１４および１１１６は、ＳＱＬフォーマットのコマンドに応答してデータ格納、更
新、および取り出すようになされたＯｒａｃｌｅが提供するデータベースなど、リレーショナルデータベースを含んでもよい。

図１２は、本開示の実施形態を実現するために使用され得る例示的なコンピュータシステム１２００を示す図である。いくつかの実施形態では、コンピュータシステム１２００を使用して、上述の様々なサーバおよびコンピュータシステムのうちのいずれかを実現してもよい。図１２に示すように、コンピュータシステム１２００は、バス・サブシステム１２０２を介していくつかの周辺サブシステムと通信する処理サブシステム１２０４を含む、様々なサブシステムを備える。これらの周辺サブシステムは、処理高速化装置１２０６と、Ｉ／Ｏサブシステム１２０８と、ストレージサブシステム１２１８と、通信サブシステム１２２４とを備えてもよい。ストレージサブシステム１２１８は、有形のコンピュータ読み取り可能な記憶媒体１２２２と、システムメモリ１２１０とを備えてもよい。

バス・サブシステム１２０２は、コンピュータシステム１２００の様々なコンポーネントおよびサブシステムを互いに意図した通りに通信させるための機構を提供する。バス・サブシステム１２０２は、１つのバスとして図示されているが、バス・サブシステムの別の実施形態は、複数のバスを利用してもよい。バス・サブシステム１２０２は、メモリコントローラのメモリバス、周辺バス、および各種のバスアーキテクチャを使用するローカルバスを含む、いくつかの種類のバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを含んでもよく、これらは、ＩＥＥＥ Ｐ１３８６．１標準規格に準拠して製造されるＭｅｚｚａｎｉｎｅバスなどとして実現され得る。

処理サブシステム１２０４は、コンピュータシステム１２００の動作を制御し、１つ以上の処理装置１２３２、１２３４などを備えてもよい。処理装置は、シングルコア・プロセッサまたはマルチコア・プロセッサを含む１つ以上のプロセッサ、プロセッサの１つ以上のコア、またはそれらの組合せを含んでもよい。いくつかの実施形態では、処理サブシステム１２０４は、グラフィックスプロセッサ、デジタル・シグナル・プロセッサ（ＤＳＰ）など、１つ以上の専用コプロセッサを含み得る。いくつかの実施形態では、処理サブシステム１２０４の処理装置の一部またはすべては、特定用途向け集積回路（ＡＳＩＣ）、またはフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など、カスタム回路を使用して実現され得る。

いくつかの実施形態では、処理サブシステム１２０４に含まれる処理装置は、システムメモリ１２１０に、または、コンピュータ読み取り可能な記憶媒体１２２２上に格納された命令を実行できる。様々な実施形態では、処理装置は、いろいろなプログラムまたはコード命令を実行し、複数の同時に実行しているプログラムまたはプロセスを維持できる。いつでも、実行されるプログラムコードの一部またはすべては、システムメモリ１２１０に、および／または、１つ以上の記憶装置上を潜在的に含む、コンピュータ読み取り可能な記憶媒体１２１０上に存在し得る。適したプログラミングを通して処理サブシステム１２０４は、使用パターンに応じてドキュメント（たとえば、ウェブページ）を動的に変更するための上述の様々な機能を提供できる。

特定の実施形態では、カスタマイズされた処理を実行するための、または、コンピュータシステム１２００によって実行される全体的な処理が高速化するように、処理サブシステム１２０４によって実行される処理のうちのいくつかの負荷を軽減させるための処理高
速化装置１２０６が提供されてもよい。

Ｉ／Ｏサブシステム１２０８は、コンピュータシステム１２００に情報を入力するためのデバイスおよびメカニズム、ならびに／またはコンピュータシステム１２００から、もしくはコンピュータシステム１２００を介して情報を出力するためのデバイスおよびメカニズムを含んでもよい。一般に、用語「入力装置」の使用は、コンピュータシステム１２００に情報を入力するためのあらゆる種類のデバイスおよび機構を含む意図がある。ユーザインタフェース入力装置は、たとえば、キーボード、マウスもしくはトラックボールなどのポインティングデバイス、タッチパッドもしくはディスプレイに組み込まれたタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、ボイスコマンド認識システムを有する音声入力装置、マイクロホン、および他の種類の入力装置を含んでもよい。また、ユーザインタフェース入力装置は、ユーザが入力装置を制御するおよび入力装置とやり取りすることを可能にするＭｉｃｒｏｓｏｆｔ Ｋｉｎｅｃｔ（登録商標）モーションセンサなどの動き検知デバイスおよび／またはジェスチャ認識デバイス、Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）３６０ゲームコントローラ、ジェスチャコマンドおよび音声コマンドを使用した入力を受信するためのインタフェースを提供するデバイスを含んでもよい。ユーザインタフェース入力装置は、ユーザからの目のアクティビティ（たとえば、写真を撮影しながらおよび／またはメニュー選択を行いながら「まばたきすること」）を検出し、アイ・ジェスチャを入力装置（たとえば、Ｇｏｏｇｌｅ Ｇｌａｓｓ（登録商標））への入力として変形させるＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）まばたき検出装置などのアイ・ジェスチャ認識デバイスを含んでもよい。これに加えて、ユーザインタフェース入力装置は、ユーザが、ボイスコマンドを通して、音声認識システム（たとえば、Ｓｉｒｉ（登録商標）ナビゲータ）とやり取りすることを可能にする音声認識検知デバイスを含んでもよい。

ユーザインタフェース入力装置の他の例に、３次元（３Ｄ）マウス、ジョイスティックもしくはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルカムコーダー、ポータブルメディアプレーヤ、ウェブカム、イメージスキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザー測距器、および視線追跡装置などのオーディオ／ビジュアル装置などが挙げられるが、これらに限定されない。これに加えて、ユーザインタフェース入力装置は、たとえば、コンピュータ断層撮影法、磁気共鳴画像、ポジトロン・エミッション・トモグラフィー、超音波検査デバイスなど、医用画像入力装置を含んでもよい。また、ユーザインタフェース入力装置は、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力装置を含んでもよい。

ユーザインタフェース出力装置は、表示サブシステム、インジケーターライト、または音声出力装置などの非ビジュアル装置を含んでもよい。表示サブシステムは、ブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使用するものなどのフラットパネル表示装置、投影装置、タッチスクリーンなどであってもよい。一般に、用語「出力装置」の使用は、コンピュータシステム１２００からユーザまたは他のコンピュータに情報を出力するためのあらゆる種類のデバイスおよび機構を含むよう意図される。たとえば、ユーザインタフェース出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、自動車ナビゲーションシステム、作図装置、音声出力装置、およびモデムなど、視覚的に文字、図形、および音声／映像情報を伝えるいろいろな表示装置を含み得るが、これらに限定されない。

ストレージサブシステム１２１８は、コンピュータシステム１２００が使用する情報を格納するためのリポジトリまたはデータストアを提供する。ストレージサブシステム１２１８は、いくつかの実施形態の機能を提供する基本プログラミング構造およびデータ構造
を格納するための有形の非一時的なコンピュータ読み取り可能な記憶媒体を提供する。処理サブシステム１２０４によって実行されると上述の機能を提供するソフトウェア（プログラム、コードモジュール、命令）がストレージサブシステム１２１８に格納されてもよい。ソフトウェアは、処理サブシステム１２０４の１つ以上の処理装置によって実行されてもよい。また、ストレージサブシステム１２１８は、本開示に応じて使用されるデータを格納するためのリポジトリを提供してもよい。

ストレージサブシステム１２１８は、揮発性および不揮発性メモリ素子を含む、１つ以上の非一時的なメモリ素子を含んでもよい。図１２に示すように、ストレージサブシステム１２１８は、システムメモリ１２１０と、コンピュータ読み取り可能な記憶媒体１２２２とを備える。システムメモリ１２１０は、プログラムを実行中に命令およびデータを格納するための揮発性のメインＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、および、固定の命令が格納される不揮発性ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）またはフラッシュメモリを含む、いくつかのメモリを含んでもよい。いくつかの実装形態では、起動中などで、コンピュータシステム１２００内の要素間で情報を転送することを助ける基本ルーチンを含むＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）は、通常、ＲＯＭに格納されてもよい。ＲＡＭは、通常、処理サブシステム１２０４が現在操作および実行していているデータおよび／またはプログラムモジュールを含む。いくつかの実装形態では、システムメモリ１２１０は、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）またはＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ
Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）など、複数の異なる種類のメモリを含んでもよい。

一例として、限定ではないが、図１２に示すように、システムメモリ１２１０は、クライアントアプリケーション、ウェブブラウザ、ミッドティア・アプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などのアプリケーションプログラム１２１２と、プログラムデータ１２１４と、オペレーティングシステム１２１６とを含んでもよい。一例として、オペレーティングシステム１２１６は、様々なバージョンのＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）、および／もしくはＬｉｎｕｘオペレーティングシステム、いろいろな流通しているＵＮＩＸ（登録商標）もしくはＵＮＩＸに似たオペレーティングシステム（いろいろなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）ＯＳなどを含むが、これらに限定されない）、ならびに／またはｉＯＳ、Ｗｉｎｄｏｗｓ（登録商標）Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標）ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標）１０ＯＳ、およびＰａｌｍ（登録商標）ＯＳオペレーティングシステムなど、モバイルオペレーティングシステムを含んでもよい。

コンピュータ読み取り可能な記憶媒体１２２２は、いくつかの実施形態の機能を提供するプログラミング構造およびデータ構造を格納してもよい。処理サブシステム１２０４によって実行されると、プロセッサに上述の機能を提供するソフトウェア（プログラム、コードモジュール、命令）がストレージサブシステム１２１８に格納されてもよい。一例として、コンピュータ読み取り可能な記憶媒体１２２２は、ハードディスクドライブなどの不揮発性メモリ、磁気ディスクドライブ、ＣＤ ＲＯＭ、ＤＶＤ、Ｂｌｕ－Ｒａｙ（登録商標）ディスクなどの光ディスクドライブまたは他の光学媒体を含んでもよい。コンピュータ読み取り可能な記憶媒体１２２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリーカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）フラッシュドライブ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでもよいが、これらに限定されない。コンピュータ読み取り可能な記憶媒体１２２２は、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなど、不揮発性メモリに基づくＳＳＤ（Ｓｏｌｉｄ－Ｓｔａｔｅ
Ｄｒｉｖｅｓ）、ソリッドステートＲＡＭ、動的ＲＡＭ、静的ＲＡＭなど、揮発性メモ
リに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭのＳＳＤとフラッシュメモリベースのＳＳＤとの組合せを使用するハイブリッドＳＳＤを含んでもよい。コンピュータ読み取り可能な媒体１２２２は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、およびコンピュータシステム１２００用の他のデータのストレージを提供してもよい。

特定の実施形態では、ストレージサブシステム１２００は、コンピュータ読み取り可能な記憶媒体１２２２にさらに接続され得るコンピュータ読み取り可能な記憶媒体リーダ１２２０を含んでもよい。システムメモリ１２１０と合わせて、必要に応じてシステムメモリ１２１０と組み合わせて、コンピュータ読み取り可能な記憶媒体１２２２は、遠隔の記憶装置、ローカル記憶装置、固定記憶装置、および／またはリム―バブル記憶装置、ならびにコンピュータ読み取り可能な情報を格納するための記憶媒体を包括的に表してもよい。

特定の実施形態では、コンピュータシステム１２００は、１つ以上の仮想マシンを実行するためのサポートを提供してもよい。コンピュータシステム１２００は、仮想マシンの構成および管理を容易にするためのハイパーバイザなどのプログラムを実行してもよい。各仮想マシンには、メモリ、コンピュータ（たとえば、プロセッサ、コア）、Ｉ／Ｏ、およびネットワーキング・リソースが割り当てられてもよい。各仮想マシンは、通常、それ自体のオペレーティングシステムを実行する。このオペレーティングシステムは、コンピュータシステム１２００が実行する他の仮想マシンによって実行されるオペレーティングシステムと同じまたは異なってもよい。したがって、複数のオペレーティングシステムは、コンピュータシステム１２００によって同時に実行される可能性があってもよい。各仮想マシンは、一般に、その他の仮想マシンとは別に実行される。

通信サブシステム１２２４は、他のコンピュータシステムおよびネットワークへのインタフェースを提供する。通信サブシステム１２２４は、コンピュータシステム１２００からデータを受信し、コンピュータシステム１２００から他のシステムにデータを送信するためのインタフェースとして機能する。たとえば、通信サブシステム１２２４は、１つ以上のクライアントコンピューティングデバイスと情報を送受信するためのクライアントコンピューティングデバイスへの通信チャネルを、インターネットを介してコンピュータシステム１２００が確立することを可能にしてもよい。これに加えて、通信サブシステム１２２４を用いて、ログインに成功したという通知、または特権アカウントの管理者から要求側ユーザに対してパスワードを再入力するよう求める通知を伝達してもよい。

通信サブシステム１２２４は、有線通信プロトコルおよび／またはワイヤレス通信プロトコルの両方をサポートしてもよい。たとえば、特定の実施形態では、通信サブシステム１２２４、ワイヤレス音声ネットワークもしくは／またはデータネットワークにアクセスするためのＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）送信コンポーネント（たとえば、携帯電話技術、３Ｇ、４Ｇ、もしくはＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅｓ
Ｆｏｒ Ｇｌｏｂａｌ Ｅｖｏｌｕｔｉｏｎ）などの次世代データネットワークテクノロジー、ＷｉＦｉ（ＩＥＥＥ ８０２．１１ファミリー標準規格）、他の移動オブジェクト通信技術、またはそれらの任意の組合せを使用する）、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信コンポーネント、および／または他のコンポーネントを含んでもよい。いくつかの実施形態では、通信サブシステム１２２４は、ワイヤレスインタフェースに加えて、またはワイヤレスインタフェースの代わりに、有線ネットワーク接続性（たとえば、Ｅｔｈｅｒｎｅｔ）を提供できる。

通信サブシステム１２２４は、様々な形でデータを受送信できる。たとえば、いくつかの実施形態では、通信サブシステム１２２４は、入力通信文を、構造化および／または非
構造化データフィード１２２６、イベントストリーム１２２８、イベント更新１２３０などの形で受信してもよい。たとえば、通信サブシステム１２２４は、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）の更新、ＲＳＳ（Ｒｉｃｈ Ｓｉｔｅ
Ｓｕｍｍａｒｙ）フィードなどのｗｅｂフィード、および／または１つ以上のサードパーティ情報ソースからのリアルタイム更新など、ソーシャルメディアネットワークおよび／または他のコミュニケーションサービスのユーザから、データフィード１２２６をリアルタイムで受信する（または送る）ように構成されてもよい。

特定の実施形態では、通信サブシステム１２２４は、連続したデータストリームの形でデータを受信するように構成されてもよく、連続したデータストリームは、本質的にはっきりとした終端がない、連続または無限の、リアルタイムイベントおよび／またはイベント更新１２３０のイベントストリーム１２２８を含んでもよい。連続データを生成するアプリケーションとして、たとえば、センサーデータアプリケーション、チッカー、ネットワークパフォーマンス測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通量監視などが挙げられてもよい。

また、通信サブシステム１２２４コンピュータシステム１２００に接続された１つ以上のストリーミングデータソースコンピュータと通信中であり得る１つ以上のデータベースに、構造化および／または非構造化データフィード１２２６、イベントストリーム１２２８、イベント更新１２３０などを出力するように構成されてもよい。

コンピュータシステム１２００は、手のひらサイズのポータブルデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえば、Ｇｏｏｇｌｅ Ｇｌａｓｓ（登録商標）ヘッドマウントディスプレイ）、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、様々な種類のうちの１つであり得る。

変わり続けるというコンピュータおよびネットワークの性質により、図１２に示すコンピュータシステム１２００の説明は、具体例にすぎない。図１２に示すシステムよりも多いまたは少ないコンポーネントを有する多くの他の構成が可能である。本明細書に記載の開示および教示に基づいて、当業者は、様々な実施形態を実現するための他のやり方および／または方法が分かるだろう。

図面のいくつかに示すシステムは、様々な構成で提供されてもよい。いくつかの実施形態では、これらのシステムは、システムの１つ以上の構成要素が１つ以上のクラウドインフラストラクチャシステムにおける１つ以上のネットワーク間で分散される分散システムとして構成されてもよい。

クラウドインフラストラクチャシステムは、１つ以上のサーバコンピューティングデバイス、ネットワーク機器、および／または記憶装置の集まりである。これらのリソースは、クラウドサービスプロバイダによって分けられて、その顧客に何らかの方法で割り当てられてもよい。たとえば、カリフォルニア州レッドウッドショアーズのオラクル社などのクラウドサービスプロバイダは、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）カテゴリ下で提供される１つ以上のサービス、ＰａａＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）カテゴリ下で提供されるサービス、ＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）カテゴリ下で提供されるサービス、または、混合サービスを含む他のカテゴリのサービスを様々な種類のクラウドサービスを提供してもよいが、これらに限定されない。ＳａａＳサービスとして、Ｏｒａｃｌｅ Ｆｕｓｉｏｎ
アプリケーションなどのオンデマンドアプリケーション一式を構築および届ける機能が挙げられるが、これらに限定されない。ＳａａＳサービスは、クラウドインフラストラクチャシステム上で実行中のアプリケーションを、顧客がアプリケーション用のソフトウェアを購入する必要なしに利用することを可能にする。ＰａａＳサービスとして、ＪＣＳ（Ｏｒａｃｌｅ Ｊａｖａ Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ）、ＤＢＣＳ（Ｏｒａｃｌｅ Ｄａｔａｂａｓｅ Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ）など、組織（Ｏｒａｃｌｅなど）が既存のアプリケーションを共有の共通アーキテクチャ上に１つにまとめることを可能にするサービス、およびプラットフォームが提供する共有サービスを活用する新しいアプリケーションを作る能力などが挙げられるが、これらに限定されない。ＩａａＳサービスは、通常、ＳａａＳプラットフォームおよびＰａａＳプラットフォームが提供するサービスを利用している顧客のための、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースなど、礎となるコンピューティングリソースの管理および制御を容易にする。

図１３は、本開示の実施形態に係る、実施形態のシステムの１つ以上の構成要素が提供するサービスがクラウドサービスとして提供され得るシステム環境１３００の１つ以上の構成要素の簡略ブロック図である。 図示した実施形態では、システム環境１３００は、
１つ以上のクライアントコンピューティングデバイス１３０４、１３０６、および１３０８を含む。１つ以上のクライアントコンピューティングデバイス１３０４、１３０６、および１３０８は、ユーザによって、クラウドサービスを提供するクラウドインフラストラクチャシステム１３０２と対話するために使用されもよい。クライアントコンピューティングデバイスは、ウェブブラウザ、プロプライエタリ・クライアントアプリケーション（たとえば、Ｏｒａｃｌｅ Ｆｏｒｍｓ）、または他のアプリケーションなど、クライアントアプリケーションを操作するように構成されてもよい。クライアントアプリケーションは、クライアントコンピューティングデバイスのユーザによって、クラウドインフラストラクチャシステム１３０２と対話を行ってクラウドインフラストラクチャシステム１３０２が提供するサービスを利用するために使用され得る。

図に示したクラウドインフラストラクチャシステム１３０２が、図示された構成要素以外の構成要素を有し得ることを理解されたい。さらに、図に示す実施形態は、本開示の実施形態を組み込み得るクラウドインフラストラクチャシステムの一例に過ぎない。他のいくつかの実施形態では、クラウドインフラストラクチャシステム１３０２は、図に示す構成要素よりも多いまたは少ない数の構成要素を有してもよく、２つ以上の構成要素を組み合わせてもよく、または構成要素の構成もしくは配置が異なっていてもよい。

クライアントコンピューティングデバイス１３０４、１３０６、および１３０８は、１１０２、１１０４、１１０６、および１１０８に関して上述したクライアントコンピューティングデバイスと同様のデバイスであってもよい。

例示的なシステム環境１３００は、３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサ付きデバイスなど、他のデバイスがクラウドインフラストラクチャシステム１３０２と対話を行ってもよい。

ネットワーク（複数可）１３１０は、クライアント１３０４、１３０６、および１３０８とクラウドインフラストラクチャシステム１３０２との間のデータの通信およびやり取りを容易にしてもよい。各ネットワークは、ネットワーク（複数可）１６１０に関して上述したプロトコルを含む各種市販のプロトコルのいずれかを用いたデータ通信をサポートできる、当業者にとってなじみのある任意の種類のネットワークであってもよい。

クラウドインフラストラクチャシステム１３０２は、サーバ１１１２に関して上述した
コンピュータおよびサーバを含み得る１台以上のコンピュータおよび／またはサーバから構成されてもよい。

特定の実施形態では、クラウドインフラストラクチャシステムが提供するサービスは、オンラインのデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされたオフィススイートドキュメント連携サービス、データベース処理、管理されたテクニカルサポートサービスなど、クラウドインフラストラクチャシステムのユーザが要求すれば利用可能になるサービスのホストを含んでもよい。クラウドインフラストラクチャシステムが提供するサービスは、動的にスケール変更してそのユーザのニーズを満たすことができる。クラウドインフラストラクチャシステムが提供するサービスを具体的にインスタンス化したものは、本明細書において、「サービスインスタンス」と称される。一般に、インターネットなどの通信ネットワークを介してユーザが利用できるようになる、クラウドサービスプロバイダのシステムからのいずれのサービスも、「クラウドサービス」と称される。通常、パブリッククラウド環境において、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客所有のオンプレミス・サーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介して、要求に基づいてアプリケーションを注文および使用すればよい。

いくつかの例において、コンピュータネットワークのクラウドインフラストラクチャにおけるサービスは、ストレージ、ホストされたデータベース、ホストされたウェブサーバ、ソフトウェア・アプリケーションへの保護されたコンピュータネットワークアクセス、もしくはクラウドベンダーがユーザに提供するその他のサービス、または、当技術分野で周知の上記以外のその他のサービスを含んでもよい。たとえば、サービスは、インターネットを通した、クラウド上のリモートストレージへのパスワード保護されたアクセスを含み得る。別の例として、サービスは、ネットワークで結ばれた開発者が私的使用するための、ウェブサービスベースのホストされたリレーショナルデータベースおよびスクリプト言語のミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダーのウェブサイト上にホストされた電子メールソフトウェア・アプリケーションへのアクセスを含み得る。

特定の実施形態では、クラウドインフラストラクチャシステム１３０２は、顧客にセルフサービスでサブスクリプション方式で伸縮自在にスケーラブルで信頼性があり、かつ高い可用性を有するセキュアな方法で届けられるアプリケーション一式、ミドルウェア、およびデータベースサービス提供物を含んでもよい。このようなクラウドインフラストラクチャシステムの例が、本願の譲受人が提供するオラクルパブリッククラウド（Ｏｒａｃｌｅ Ｐｕｂｌｉｃ Ｃｌｏｕｄ）である。

様々な実施形態では、クラウドインフラストラクチャシステム１３０２は、クラウドインフラストラクチャシステム１３０２が提供するサービスへの顧客のサブスクリプションを自動的にプロビジョニング、管理、および追跡するようになされてもよい。クラウドインフラストラクチャシステム１３０２は、それぞれ異なるデプロイメントモデルを介してクラウドサービスを提供してもよい。たとえば、サービスは、パブリッククラウドモデル下で提供されてもよい。パブリッククラウドモデルでは、クラウドインフラストラクチャシステム１３０２は、（たとえば、オラクル所有の）クラウドサービスを提供する組織が所有しており、一般大衆またはそれぞれ異なる産業企業でサービスが使用できるようになる。別の例として、サービスは、クラウドインフラストラクチャシステム１３０２が１つの組織のためだけに動かされるプライベートクラウドモデル下で提供されてもよく、組織内の１つ以上のエンティティのためのサービスを提供してもよい。また、クラウドサービスは、コミュニティクラウドモデル下で提供されてもよい。コミュニティクラウドモデル
では、クラウドインフラストラクチャシステム１３０２およびクラウドインフラストラクチャシステム１３０２が提供するサービスが、関連コミュニティ内のいくつかの組織によって共有される。クラウドサービスは、ハイブリッドクラウドモデル下で提供されてもよい。ハイブリッドクラウドモデルとは、２つ以上の異なるモデルの組合せである。

いくつかの実施形態では、クラウドインフラストラクチャシステム１３０２が提供するサービスは、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）カテゴリ、ＰａａＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）カテゴリ、ＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）カテゴリ、または混合サービスを含む、他のカテゴリ下で提供される１つ以上のサービスを含んでもよい。顧客は、サブスクリプションのオーダーによって、クラウドインフラストラクチャシステム１３０２が提供する１つ以上のサービスをオーダーしてもよい。次に、クラウドインフラストラクチャシステム１３０２は、処理を実行して、顧客のサブスクリプションのオーダーにあるサービスを提供する。

いくつかの実施形態ではクラウドインフラストラクチャシステム１３０２が提供するサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを含んでもよいが、これらに限定されない。いくつかの例において、アプリケーションサービスは、ＳａａＳサービスを介してクラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリに該当するクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、オンデマンドアプリケーション一式を構築し、統合開発／デプロイメントプラットフォームに届けるための機能を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理および制御してもよい。ＳａａＳプラットフォームが提供するサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、アプリケーションサービスを、別のライセンスおよびサポートを購入する必要なしに、入手できる。様々な異なるＳａａＳサービスが提供されてもよい。例として、大きな組織のための販売実績管理、エンタープライズ統合、およびビジネス上の柔軟性に対するソリューションを提供するサービスなどが挙げられるが、これに限定されない。

いくつかの実施形態では、プラットフォームサービスは、ＰａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリに該当するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスとして、組織（Ｏｒａｃｌｅなど）が既存のアプリケーションを共有の共通アーキテクチャ上に１つにまとめることを可能にするサービス、およびプラットフォームが提供する共有サービスを活用する新しいアプリケーションを作る能力などが挙げられるが、これらに限定されない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための、基礎となるソフトウェアおよびインフラストラクチャを管理および制御してもよい。顧客は、ＰａａＳ クラウドインフラストラクチャシステムが提供するサービスを、ライセンスおよびサポートを別に購入する必要なしに、取得できる。プラットフォームサービスとして、ＪＣＳ（Ｏｒａｃｌｅ Ｊａｖａ Ｃｌｏｕｄ
Ｓｅｒｖｉｃｅ）、ＤＢＣＳ（Ｏｒａｃｌｅ Ｄａｔａｂａｓｅ Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ）など、およびその他が挙げられるが、これらに限定されない。

ＰａａＳプラットフォームが提供するサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムがサポートするプログラミング言語およびツールを採用することができ、また、デブロイされたサービスを管理することができる。いくつかの実施形態において、クラウドインフラストラクチャシステムが提供するプラットフォーム
サービスは、データベース・クラウドサービス、ミドルウェアクラウドサービス（たとえば、Ｏｒａｃｌｅ Ｆｕｓｉｏｎ Ｍｉｄｄｌｅｗａｒｅサービス）、およびＪａｖａクラウドサービスを含んでもよい。一実施形態では、データベース・クラウドサービスは、共有サービスデプロイメントモデルをサポートしてもよい。共有サービスデプロイメントモデルは、組織が、データベースリソースをプールし、データベース・クラウドの形のサービスとしてデータベースを顧客に提供することを可能にする。ミドルウェアクラウドサービスは、顧客が様々な業務アプリケーションを開発およびデプロイするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてＪａｖａアプリケーションをデプロイするためのプラットフォームを提供してもよい。

クラウドインフラストラクチャシステムにおいて、ＩａａＳプラットフォームによって、様々な異なるインフラストラクチャサービスが提供されてもよい。インフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームが提供するサービスを利用している顧客のための、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースなど、基礎となるコンピューティングリソースの管理および制御を容易にする。

特定の実施形態では、クラウドインフラストラクチャシステム１３０２は、クラウドインフラストラクチャシステムの顧客に様々なサービスを提供するために使用されるリソースを提供するためのインフラストラクチャ・リソース１３３０を含んでもよい。一実施形態では、インフラストラクチャ・リソース１３３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームが提供するサービスを実行するための、サーバなどのハードウェアと、ストレージと、ネットワーキング・リソースとの予め統合された最適な組合せ、および他のリソースを含んでもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム１３０２におけるリソースは、複数のユーザによって共有され、要求に応じて動的に再割り当てされてもよい。これに加えて、リソースは、それぞれ異なるタイムゾーンのユーザに割り当てられてもよい。たとえば、クラウドインフラストラクチャシステム１３３０は、第１のタイムゾーンにいる第１セットのユーザが、指定された時間数、クラウドインフラストラクチャシステムのリソースを利用することを可能にした後、同じリソースを、異なるタイムゾーンに位置する別のセットのユーザへ再割り当てすることを可能にし、リソースの利用を最大限に活用することができる。

特定の実施形態では、クラウドインフラストラクチャシステム１３０２のそれぞれ異なるコンポーネントまたはモジュールによって、かつ、クラウドインフラストラクチャシステム１３０２が提供するサービスによって共有される、いくつかの内部共有サービス１３３２が提供されてもよい。これらの内部共有サービスは、セキュリティ／素性サービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャン／ホワイトリストサービス、可用性の高いバックアップ・リカバリサービス、クラウドサポート、Ｅメールサービス、通知サービス、ファイル転送サービスなどを可能にするためのサービスを含み得るが、これらに限定されない。

特定の実施形態では、クラウドインフラストラクチャシステム１３０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえば、ＳａａＳサービス、Ｐａａサービス、およびＩａａＳサービス）の包括的な管理を提供してもよい。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム１３０２などが受信した顧客のサブスクリプションをプロビジョニング、管理、および追跡するための機能を含んでもよい。

一実施形態では、図に示すように、クラウド管理機能は、オーダー管理モジュール１３２０、オーダーオーケストレーションモジュール１３２２、オーダープロビジョニングモジュール１３２４、オーダー管理／監視モジュール１３２６、および素性管理モジュール１３２８など、１つ以上のモジュールによって提供されてもよい。これらのモジュールは、１つ以上のコンピュータおよび／またはサーバを含んでもよく、または、これらを使用して提供されてもよい。１つ以上のコンピュータおよび／またはサーバは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な配置および／または組合せであり得る。

例示的な動作１３３４において、クライアントデバイス１３０４、１３０６ または１
３０８などのクライアントデバイスを使用している顧客は、クラウドインフラストラクチャシステム１３０２が提供する１つ以上のサービスを要求し、クラウドインフラストラクチャシステム１３０２が提供する１つ以上のサービスのサブスクリプションのオーダーをすることによってクラウドインフラストラクチャシステム１３０２とやり取りしてもよい。特定の実施形態では、顧客は、クラウドＵＩ１３１２、クラウドＵＩ１３１４ および
／またはクラウドＵＩ１３１６などのクラウドユーザインタフェース（ＵＩ：Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）にアクセスし、これらのＵＩを介してサブスクリプションのオーダーを行ってもよい。顧客がオーダーをすることに応答してクラウドインフラストラクチャシステム１３０２が受信したオーダー情報は、この顧客を特定する情報、および、顧客がサブスクリプションをする予定である、クラウドインフラストラクチャシステム１３０２が提供する１つ以上のサービスを含んでもよい。

顧客によって注文がされた後、クラウドＵＩ１３１２、１３１４、および／または１３１６を介してオーダー情報が受け付けられる。

動作１３３６において、この注文は、オーダーデータベース１３１８に格納される。オーダーデータベース１３１８は、クラウドインフラストラクチャシステム１３１８によって操作され、かつ、他のシステム要素と共に操作されるいくつかのデータベースのうちの１つであり得る。

動作１３３８において、オーダー情報がオーダー管理モジュール１３２０に転送される。場合によっては、オーダー管理モジュール１３２０は、注文の確認、確認後の注文の登録など、注文に関する課金機能および会計機能を実行するように構成されてもよい。

動作１３４０において、注文に関する情報がオーダーオーケストレーションモジュール１３２２に伝送される。オーダーオーケストレーションモジュール１３２２は、このオーダー情報を利用して、顧客が行った注文に関するサービスおよびリソースのプロビジョニングをオーケストレーションしてもよい。場合によっては、オーダーオーケストレーションモジュール１３２２は、リソースのプロビジョニングをオーケストレーションして、オーダープロビジョニングモジュール１３２４のサービスを使用してサブスクリプションされているサービスをサポートしてもよい。

特定の実施形態では、オーダーオーケストレーションモジュール１３２２は、各注文に関連する業務の流れの管理を可能にし、ビジネスロジックを適用して、注文がプロビジョニングに進むべきかどうかを判断する。動作１３４２において、新しいサブスクリプションの注文を受けると、オーダーオーケストレーションモジュール１３２２は、サブスクリプションの注文を満たすために必要なリソースを割り当ててこれらのリソースを構成する要求をオーダープロビジョニングモジュール１３２４に送信する。オーダープロビジョニングモジュール１３２４は、顧客が申し込んだサービスのためのリソースの割り当てを有
効にする。オーダープロビジョニングモジュール１３２４は、クラウドインフラストラクチャシステム１３００が提供するクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理実施層との間に抽象度を設ける。よって、サービスおよびリソースがオンザフライで実際にプロビジョニングされたかどうか、または予めプロビジョニングされて要求された場合にのみ割り当てられたかどうかなどの実装の詳細からオーダーオーケストレーションモジュール１３２２を切り離すことができる。

動作１３４４において、サービスおよびリソースがプロビジョニングされると、クラウドインフラストラクチャシステム１３０２のオーダープロビジョニングモジュール１３２４によって、クライアントデバイス１３０４、１３０６、および／または１３０８上の顧客に、提供されたサービスについての通知が送信されてもよい。動作１３４６において、オーダー管理／監視モジュール１３２６によって顧客のサブスクリプションの注文が管理および追跡されてもよい。場合によっては、オーダー管理／監視モジュール１３２６は、サブスクリプションの注文におけるサービスに関する使用統計データ、たとえば、使用されたストレージの量、転送されたデータの量、ユーザの数、ならびにシステムの稼働時間およびシステムの休止時間などを収集するように構成されてもよい。

特定の実施形態では、クラウドインフラストラクチャシステム１３００は、素性管理モジュール１３２８を含んでもよい。素性管理モジュール１３２８は、クラウドインフラストラクチャシステム１３００におけるアクセス管理および承認サービスなどの素性サービスを提供するように構成されてもよい。いくつかの実施形態では、素性管理モジュール１３２８は、クラウドインフラストラクチャシステム１３０２が提供するサービスを利用したい顧客についての情報を管理してもよい。このような情報は、このような顧客の素性を認証する情報、および、様々なシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらの顧客がどのような操作を行うことが承認されているのかを記述する情報を含み得る。また、素性管理モジュール１３２８は、各顧客についての記述情報、およびその記述情報が誰によってどのようにアクセスおよび変更され得るかについての記述情報の管理を含んでもよい。

具体的な本開示の実施形態を説明したが、様々な変更例、代替例、代替的な構成、および均等物も本開示の範囲内に包含される。本開示の実施形態は、ある特定のデータ処理環境内の動作に制限されず、複数のデータ処理環境内で自由に動作することができる。これに加えて、特定の一続きのトランザクションおよびステップを使用して本開示の実施形態を説明したが、本開示の範囲は、記載の一続きのトランザクションおよびステップに限られないことは、当業者に明らかであるはずである。上述の実施形態の様々な特徴および態様は、個々に、または共同で使用されてもよい。

さらに、ハードウェアとソフトウェアとの特定の組合せを使用して本開示の実施形態を説明したが、ハードウェアとソフトウェアとの他の組合せも、本開示の範囲内であることを認識されたい。本開示の実施形態は、ハードウェアのみ、もしくは、ソフトウェアのみで実現されてもよく、またはそれらの組合せを使用して実現されてもよい。本明細書に記載の様々なプロセスは、同じプロセッサまたは任意の組合せのそれぞれ異なるプロセッサ上で実現できる。よって、コンポーネントまたはモジュールが特定の動作を実行するように構成されると説明されている箇所では、このような構成は、たとえば、この動作を実行するように電子回路を設計することによって、この動作を実行するようにプログラム可能な電子回路（マイクロプロセッサなど）をプログラムすることによって、またはそれらの任意の組合せによって達成できる。プロセスは、プロセス間通信のための従来技術を含む、いろいろな技術を使用して通信できるが、これに限定されず、それぞれ異なるペアプロセスは、異なる技術を使用してもよく、プロセスの同じペアは、異なる技術を別々のタイミングで使用してもよい。

明細書および図面は、厳密ではなく一例にすぎないと適宜みなされるべきである。しかしながら、添付の特許請求の範囲に記載のより広義の趣旨および範囲から逸脱することなく、追加、減算、削除、および他の変更ならびに変形がそれらに対してなされてもよいということは明白であろう。したがって、具体的な本開示の実施形態を説明したが、これらは、限定を意図しない。様々な変更例および均等物は、添付の特許請求の範囲内である。

Claims (20)

1. 連続データストリームを処理するための方法であって、
   コンピューティングデバイスが、アプリケーションに関する前記連続データストリームを受信するステップと、
   前記コンピューティングデバイスが、前記連続データストリームのジオメトリをリレーションに変換するステップと、
   前記コンピューティングデバイスが、前記連続データストリームに含まれる複数の移動オブジェクトを追跡するステップと、
   前記コンピューティングデバイスが、前記リレーションおよび前記連続データストリームのジオメトリに少なくとも基づいて、前記複数の移動オブジェクトに含まれる、少なくとも第１の移動オブジェクトと第２の移動オブジェクトとの近接を判断するステップと、
   前記コンピューティングデバイスが、少なくとも前記第１の移動オブジェクトと前記第２の移動オブジェクトとの前記近接が予め定められた閾値を超えた場合、アラートを生成するステップとを含む、方法。
2. 前記リレーションは、前記連続データストリームのジオメトリの空間インデックスを含む、請求項１に記載の方法。
3. 前記コンピューティングデバイスが、範囲を用いて前記空間インデックスにフィルタを適用して前記連続データストリームのジオメトリについてのフィルタ処理された結果を取得するステップをさらに含み、前記近接を判断するステップは、前記フィルタ処理された結果を用いて前記第１の移動オブジェクトと前記第２の移動オブジェクトとの距離を算出するステップを含む、請求項２に記載の方法。
4. 前記コンピューティングデバイスが、前記連続データストリームのジオメトリに変更があるかどうかを判断するステップと、前記コンピューティングデバイスが、前記連続データストリームのジオメトリに変更があった場合、更新イベントを発行するステップとをさらに含む、請求項３に記載の方法。
5. 前記更新イベントは、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ上で発行される、請求項４に記載の方法。
6. 結合演算を用いて前記コンピューティングデバイスが、前記リレーションと前記連続データストリームのジオメトリとを結合するステップをさらに含む、請求項２に記載の方法。
7. 前記追跡するステップは、少なくとも前記第１の移動オブジェクトの前記第２の移動オブジェクトに対する関係を追跡するための空間演算を用いて実行される、請求項６に記載の方法。
8. コンピュータによって実行可能な命令を格納するように構成されたメモリと、
   前記メモリにアクセスして前記コンピュータによって実行可能な命令を実行するように構成されたプロセッサとを備え、前記コンピュータによって実行可能な命令は、
   アプリケーションに関する連続データストリームを受信するための命令と、
   前記連続データストリームのジオメトリをリレーションに変換するための命令と、
   前記連続データストリームに含まれる複数の移動オブジェクトを追跡するための命令と、
   前記リレーションおよび前記連続データストリームのジオメトリに少なくとも基づいて、前記複数の移動オブジェクトに含まれる、少なくとも第１の移動オブジェクトと第２の
   移動オブジェクトとの近接を判断するための命令と、
   少なくとも前記第１の移動オブジェクトと前記第２の移動オブジェクトとの前記近接が予め定められた閾値を超えた場合、アラートを生成するための命令とを含む、システム。
9. 前記リレーションは、前記連続データストリームのジオメトリの空間インデックスを含む、請求項８に記載のシステム。
10. 前記コンピューティングデバイスが、範囲を用いて前記空間インデックスにフィルタを適用して前記連続データストリームのジオメトリについてのフィルタ処理された結果を取得することをさらに含み、前記近接を判断することは、前記フィルタ処理された結果を用いて前記第１の移動オブジェクトと前記第２の移動オブジェクトとの距離を算出することを含む、請求項９に記載のシステム。
11. 前記コンピューティングデバイスが、前記連続データストリームのジオメトリに変更があるかどうかを判断することと、前記コンピューティングデバイスが、前記連続データストリームのジオメトリに変更があった場合、更新イベントを発行することとをさらに含む、請求項１０に記載のシステム。
12. 前記更新イベントは、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ上で発行される、請求項１１に記載のシステム。
13. 結合演算を用いて前記コンピューティングデバイスが、前記連続データストリームのジオメトリと前記リレーションとを結合することをさらに含む、請求項９に記載のシステム。
14. 前記追跡することは、少なくとも前記第１の移動オブジェクトの前記第２の移動オブジェクトに対する関係を追跡するための空間演算を用いて実行される、請求項１３に記載のシステム。
15. コンピュータによって実行可能なコードを格納したコンピュータ読み取り可能な媒体であって、前記コンピュータによって実行可能なコードは、プロセッサによって実行されると、前記プロセッサに動作を行わせ、前記動作は、
    アプリケーションに関する第１の連続データストリームを受信することと、
    前記第１の連続データストリームのジオメトリをリレーションに変換することと、
    前記連続データストリームに含まれる複数の移動オブジェクトを追跡することと、
    前記アプリケーションに関する第２の連続データストリームを受信することと、
    前記リレーションおよび前記第２の連続データストリームのジオメトリに少なくとも基づいて、少なくとも前記複数の移動オブジェクトに含まれる移動オブジェクトと前記第２の連続データストリームに含まれるオブジェクトとの関係をチェックすることと、
    前記関係が予め定められた基準を満たす場合、前記移動オブジェクトのプロパティを設定することとを含む、コンピュータ読み取り可能な媒体。
16. 前記リレーションは、前記連続データストリームのジオメトリの空間インデックスを含む、請求項１５に記載のコンピュータ読み取り可能な媒体。
17. 前記関係をチェックすることは、前記リレーションおよび前記第２の連続データストリームのジオメトリに少なくとも基づいて、少なくとも前記複数の移動オブジェクトに含まれる前記移動オブジェクトと前記第２の連続データストリームに含まれる前記オブジェクトとの近接を判断することを含む、請求項１６に記載のコンピュータ読み取り可能な媒体。
18. 少なくとも前記複数の移動オブジェクトに含まれる前記移動オブジェクトと前記第２の連続データストリームに含まれる前記オブジェクトとの前記近接が予め定められた閾値を超えた場合、前記移動オブジェクトのプロパティが設定される、請求項１７に記載のコンピュータ読み取り可能な媒体。
19. 前記動作は、範囲を用いて前記空間インデックスにフィルタを適用して前記第１の連続データストリームのジオメトリについてのフィルタ処理された結果を取得することをさらに含み、前記近接を判断することは、前記複数の移動オブジェクトに含まれる前記移動オブジェクトと前記第２の連続データストリームに含まれる前記オブジェクトとの距離を算出することを含む、請求項１８に記載のコンピュータ読み取り可能な媒体。
20. 前記動作は、前記第１の連続データストリームのジオメトリに変更があるかどうかを判断することと、前記第１の連続データストリームのジオメトリに変更があった場合、更新イベントを発行することとをさらに含み、前記更新イベントは、挿入操作、削除操作、および更新操作をサポートするメモリ内キャッシュ上で発行される、請求項１９に記載のコンピュータ読み取り可能な媒体。

Images