JP6521973B2 - 多重入力データストリームにわたるパターンマッチング - Google Patents

Description

関連出願の相互参照
本願は、２０１４年１２月３日に提出され、「多重入力データストリームにわたるパターンマッチング（PATTERN MATCHING ACROSS MULTIPLE INPUT DATA STREAMS）」と題された米国特許出願第１４／５５９，５５０号と、２０１３年１２月５日に提出され、「多重入力データストリームにわたるパターンマッチング（PATTERN MATCHING ACROSS MULTIPLE INPUT DATA STREAMS）」と題された米国仮特許出願第６１／９１２，３４４号とに対する優先権を主張するものであって、各々の内容全体があらゆる目的のために引用により援用されている。

背景
従来のデータベースシステムにおいては、データが通常は表の形式である１つ以上のデータベースに格納される。格納されたデータは、次いで、構造化クエリ言語（structured query language：ＳＱＬ）などのデータ管理言語を用いて照会および処理される。たとえば、ＳＱＬクエリは、データベースに格納されたデータから関連データを識別するように規定および実行されてもよい。このため、ＳＱＬクエリは、データベースに格納された有限集合データ上で実行される。さらに、ＳＱＬクエリが実行される場合、このＳＱＬクエリは、有限データ集合に対して１回だけ実行され、有限の静的な結果を生成する。このため、データベースは、有限の格納データ集合に対してクエリを実行するために最適に実装される。

しかしながら、いくつかの現在のアプリケーションおよびシステムは、有限のデータ集合ではなく、連続的なデータまたはイベントストリームの形式でデータを生成する。このようなアプリケーションの例は、センサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通モニタリングなどを含むがこれらに限定されない。このようなアプリケーションのために、データストリームを処理することのできる新しい種類のアプリケーションが必要となってきた。たとえば、温度センサは、温度測定値を連続的に発信するように構成されてもよい。

これらのタイプのイベントストリームベースのアプリケーションのためのデータを管理および処理するには、一時的に極集中的にデータの管理および照会能力を構築する必要がある。連続的な無限のセットのデータに対する長期間の照会を含む、さまざまな種類の照会メカニズムが必要とされる。ベンダーの中には、現在、イベントストリーム処理用に意図された製品１式を提供しているものもあるが、これらの提供される製品には、依然として、現代のイベント処理のニーズに対処するのに必要な処理融通性が欠けている。

概要
いくつかの実施形態においては、１つ以上のアプリケーションに関する多重入力データストリームにわたるパターンを検出するための技術（たとえば、１つ以上のプロセッサによって実行可能なコードまたは命令を格納する方法、システム、非一時的なコンピュータ読取可能媒体）が提供される。

一実施形態に従うと、１つ以上のアプリケーションに関する多重入力データストリームにわたってパターンを検出するための方法が開示される。当該方法は、第１の入力データストリームおよび第２の入力データストリームを含む複数の入力データストリームを受取るステップを含む。当該方法はさらに、第１の入力データストリームについての第１のダイナミックデータタイプを生成するステップと、第２の入力データストリームについての第２のダイナミックデータタイプを生成するステップとを含む。いくつかの実施形態においては、第１のダイナミックデータタイプは、第１の入力データストリームの第１の属性を、第２のデータストリームには存在しないものとして識別することによって生成されてもよい。次いで、第１のダイナミックデータタイプが、第１の属性のために生成される。第２のダイナミックデータタイプは、第２の入力データストリームの第２の属性を、第１のデータストリームには存在しないものとして識別することによって生成されてもよい。次いで、第２のダイナミックデータタイプが第２の属性のために生成される。一実施形態においては、第１のダイナミックデータタイプは、第１の入力データストリームの第１の属性に対応する第１のデータ値を格納するように構成されてもよく、第２のダイナミックデータタイプは、第２の入力データストリームの第２の属性に対応する第２のデータ値を格納するように構成されてもよい。

いくつかの実施形態においては、当該方法は、第１の入力データストリームと第２の入力データストリームとを結合して、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプに基づく結合データストリーム（combined data stream）を生成するステップを含み得る。一実施形態においては、当該方法はさらに、結合データストリームに対する連続クエリを処理してパターンを検出するステップを含み得る。いくつかの実施形態においては、「パターン」は、第１のデータストリームにおける第１のイベントの発生と、これに後続する第２のデータストリームにおける別のイベントの発生とを構成し得る。

別の実施形態に従うと、１つ以上のアプリケーションに関する多重入力データストリームにわたってパターンを検出するためのシステムが開示される。当該システムは、複数の命令を格納するためのメモリと、メモリにアクセスするように構成されたプロセッサとを含む。一実施形態においては、プロセッサは、第１の入力データストリームおよび第２の入力データストリームを識別する連続クエリを受取るようにとの命令を実行するように構成される。プロセッサは、第１の入力データストリームの第１の属性についての第１のダイナミックデータタイプと、第２の入力データストリームの第２の属性についての第２のダイナミックデータタイプとを識別するようにとの命令を実行するようにさらに構成される。いくつかの実施形態においては、プロセッサは、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプに基づいて結合データストリームを生成し、結合データストリームに対して連続クエリを実行してパターンを検出するように構成される。

いくつかの実施形態に従うと、１つ以上のプロセッサによって実行可能なコンピュータ実行可能命令を格納する非一時的なコンピュータ読取可能媒体が開示される。コンピュータ実行可能命令は、１つ以上のプロセッサに、第１の入力データストリームおよび第２の入力データストリームを少なくとも含む複数の入力データストリームを受取らせるための命令を含む。コンピュータ実行可能命令はさらに、１つ以上のプロセッサに、第１の入力データストリームについての第１のダイナミックデータタイプおよび第２の入力データストリームについての第２のダイナミックデータタイプを生成させるための命令を含む。いくつかの実施形態においては、コンピュータ実行可能命令は、第１の入力データストリームと第２の入力データストリームとを結合して、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプに基づいて結合データストリームを生成し、結合データストリームに対する連続クエリを処理して、パターンを検出するための命令を含む。

いくつかの実施形態に従うと、第１の入力データストリームおよび第２の入力データストリームを少なくとも含む複数の入力データストリームを受取るステップと、第１の入力データストリームについての第１のダイナミックデータタイプを生成するステップと、第２の入力データストリームについての第２のダイナミックデータタイプを生成するステップと、第１の入力データストリームと第２の入力データストリームとを結合して、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプに少なくとも部分的に基づく結合データストリームを生成するステップと、結合データストリームに対する連続クエリを処理してパターンを検出するステップとを含む。

いくつかの実施形態においては、第１のダイナミックデータタイプを生成するステップはさらに、第１の入力データストリームの第１の属性を、第２のデータストリームには存在しないものとして識別するステップと、第１の属性についての第１のダイナミックデータタイプを生成するステップとを含む。第１のダイナミックデータタイプは、第１の入力データストリームの第１の属性に対応する第１のデータ値を格納するように構成される。

いくつかの実施形態においては、第２のダイナミックデータタイプを生成するステップはさらに、第２の入力データストリームの第２の属性を、第１のデータストリームには存在しないものとして識別するステップと、第２の属性についての第２のダイナミックデータタイプを生成するステップとを含む。第２のダイナミックデータタイプは、第２の入力データストリームの第２の属性に対応する第２のデータ値を格納するように構成される。

いくつかの実施形態においては、当該方法はさらに、共通属性を識別するステップを含む。共通属性は、第１の入力データストリームに存在し、かつ第２の入力データストリームに存在するものとして識別される。当該方法はさらに、同種スキーマを生成するステップを含む。同種スキーマは、第１の入力データストリームおよび第２の入力データストリームの１つ以上の属性の表現を含み、当該表現は、少なくとも、共通属性、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプを含む。当該方法はさらに、同種スキーマに少なくとも部分的に基づく結合データストリームを生成するステップを含む。

いくつかの実施形態においては、当該方法はさらに、結合データストリームの分析に少なくとも部分的に基づくパターンを検出するステップを含む。パターンは、第１の入力データストリームにおける第１のイベントと、後続する第２の入力データストリームにおける第２のイベントとを識別する。

いくつかの実施形態に従うと、サービスプロバイダデバイスが提供される。サービスプロバイダデバイスは、第１の入力データストリームおよび第２の入力データストリームを少なくとも含む複数の入力データストリームを受取るように構成された入力データストリーム受取ユニットと、第１の入力データストリームについての第１のダイナミックデータタイプを生成するように構成された第１のダイナミックデータタイプ生成ユニットと、第２の入力データストリームについての第２のダイナミックデータタイプを生成するように構成された第２のダイナミックデータタイプ生成ユニットと、第１の入力データストリームと第２の入力データストリームとを結合して、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプに少なくとも部分的に基づく結合データストリームを生成するように構成された結合データストリーム生成ユニットと、結合データストリームに対する連続クエリを処理してパターンを検出するように構成されたパターン検出ユニットとを備える。

いくつかの実施形態においては、第１のダイナミックデータタイプ生成ユニットはさらに、第１の入力データストリームの第１の属性を第２のデータストリームに存在しないものとして識別し、第１の属性についての第１のダイナミックデータタイプを生成するように構成される。

いくつかの実施形態においては、第１のダイナミックデータタイプは、第１の入力データストリームの第１の属性に対応する第１のデータ値を格納するように構成される。

いくつかの実施形態においては、第２のダイナミックデータタイプ生成ユニットはさらに、第２の入力データストリームの第２の属性を第１のデータストリームには存在しないものとして識別し、第２の属性についての第２のダイナミックデータタイプを生成するように構成される。第２のダイナミックデータタイプは、第２の入力データストリームの第２の属性に対応する第２のデータ値を格納するように構成される。

いくつかの実施形態においては、サービスプロバイダデバイスはさらに、共通属性識別ユニットを含み得る。共通属性識別ユニットは、共通属性を識別するように構成される。共通属性は、第１の入力データストリームに存在し、かつ第２の入力データストリームに存在するものとして識別される。サービスプロバイダデバイスはさらに、同種スキーマを生成するように構成された同種スキーマ生成ユニットを含む。同種スキーマは、第１の入力データストリームおよび第２の入力データストリームの１つ以上の属性の表現を含む。当該表現は、少なくとも共通属性、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプを含む。

いくつかの実施形態においては、同種スキーマは、ストリーム名識別子属性、第１の入力データストリームに関連付けられた第１のタイムスタンプ属性、または第２の入力データストリームに関連付けられた第２のタイムスタンプ属性のうち少なくとも１つを含む。

いくつかの実施形態においては、結合データストリーム生成ユニットはさらに、同種スキーマによって識別される第１の入力データストリームからタプルの第１のセットを選択し、同種スキーマによって識別される第２の入力データストリームからタプルの第２のセットを選択し、タプルの第１のセットおよびタプルの第２のセットに対するサブクエリを処理して結合データストリームを生成するように構成されてもよい。

いくつかの実施形態においては、パターンは、結合データストリームの分析に少なくとも部分的に基づいて検出されてもよい。パターンは、第１の入力データストリームにおける第１のイベントと、後続する第２の入力データストリームにおける第２のイベントとを識別する。

図面の簡単な説明
添付の図面に関連付けて詳細な説明を行う。図においては、参照番号の左端の数字は、その参照番号が最初に現われる図番号を示している。さまざまな図において同じ参照番号を用いる場合、類似または同一のアイテムを示している。

多重入力データストリームにわたってパターンを識別するための技術が実現され得る簡略化された例示的なシステムまたはアーキテクチャを示す図である。 多重入力データストリームにわたるパターンの検出についての特徴が記載され得る簡略化されたブロック図を示す。 本開示の一実施形態に従って、多重入力データストリームを識別するＣＱＬクエリを用いてパターン認識を実行する具体例を示す図である。 本開示の別の実施形態に従って、多重入力データストリームを識別するＣＱＬクエリを用いてパターン認識を実行する具体例を示す図である。 本開示の一実施形態に従って、多重入力データストリームにわたってパターンを検出するためのプロセスを示す高レベルフローチャートである。 本開示の一実施形態に従って、同種スキーマを生成するためのプロセスを示す高レベルフローチャートである。 本開示の実施形態を援用し得るイベント処理システムを示す簡略化された高レベル図である。 実施形態のうちの１つを実現するための分散型システムを示す簡略図である。 本開示の実施形態に従って、具体例としてのシステムの１つ以上の構成要素によって提供されるサービスがクラウドサービスとして提供され得るシステム環境の１つ以上の構成要素を示す簡略化されたブロック図である。 本発明のさまざまな実施形態が実現され得る例示的なコンピュータシステムを示す図である。 本発明のさまざまな実施形態が実現され得る例示的なサービスプロバイダデバイスを示す簡略化されたブロック図である。

詳細な説明
以下の説明においては、さまざまな実施形態が記載される。それら実施形態を充分に理解できるようにするために具体的な構成および詳細が説明のために記載される。しかしながら、これらの実施形態が具体的な詳細なしで実施され得ることも当業者には明らかになるだろう。さらに、周知の特徴は、記載されている実施形態が不明瞭にならないようにするために省略または簡素化される可能性がある。

いくつかのアプリケーションにおいては、データは、有限の格納されたデータ集合ではなく、連続的な無限のデータストリームの形を採る可能性がある。このようなデータストリームの例には、金融分野における株価表示機、ネットワーク監視およびトラフィック管理における性能測定、ウェブトラッキングおよびパーソナル化におけるログレコードまたはクリックストリーム、センサアプリケーションからのデータ供給、ファイアウォールベースのセキュリティにおけるネットワークパケットおよびメッセージ、電気通信における通話記録、などが含まれ得る。これらの連続的な性質があるために、これらのデータストリームは、典型的には、従来の１回限りのＳＱＬクエリではなく、連続クエリを用いて照会され得る。

概して、連続データストリーム（イベントストリームとも称される）は、本質的に明確な終わりがない連続的または無限であり得るデータまたはイベントのストリームを含み得る。論理的には、イベントまたはデータストリームは、一連のデータエレメント（またイベントとも称される）であってもよく、各々のデータエレメントは関連付けられたタイムスタンプを有し得る。連続的なイベントストリームは、論理的には、１塊または１セットのエレメント（ｓ，Ｔ）として表わされてもよい。この場合、「ｓ」はデータ部分を表わし、「Ｔ」は時間ドメインにある。「ｓ」部分は概してタプルまたはイベントと称される。このため、イベントストリームは、一連のタイムスタンプ付きタプルまたはイベントであり得る。

いくつかの局面においては、ストリームにおけるイベントに関連付けられたタイムスタンプはクロックタイムと等しい可能性がある。しかしながら、他の例においては、イベントストリームにおけるイベントに関連付けられた時間は、アプリケーションドメインによって規定される可能性があり、クロックタイムに対応しない可能性があるが、たとえば、代わりに一連の数字によって表わされる可能性もある。したがって、イベントストリームにおけるイベントに関連付けられた時間情報は、数、タイムスタンプ、または時間の概念を表わす他の情報によって表わされる可能性がある。入力イベントストリームを受取るシステムの場合、イベントは、タイムスタンプが増加する順序でシステムに到達する。同じタイムスタンプを備えた２つ以上のイベントが存在する可能性もある。

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

イベントストリームを介してイベントが受取られた場合、イベントに関連付けられた時間情報を用いて、タイムスタンプ値が増大する順序で、イベントストリームにおけるイベントが到達することを確実にしてもよい。これにより、イベントストリームにおいて受取られたイベントを、それらの関連付けられた時間情報に基づいて順序付けることが可能になり得る。この順序付けを可能にするために、タイムスタンプは、後に生成されるイベントが、以前に生成されたイベントよりも後のタイムスタンプを有するように非減少の態様で、イベントストリームにおけるイベントに関連付けられてもよい。別の例として、順序番号が時間情報として用いられている場合、後に生成されたイベントに関連付けられた順序番号が、以前に生成されたイベントに関連付けられた順序番号より大きくなる可能性がある。いくつかの例においては、たとえば、データストリームイベントによって表わされる世界的なイベントが同時に発生したときに、複数のイベントが同じタイムスタンプまたは順序番号に関連付けられてもよい。同じイベントストリームに属するイベントは、概して、関連付けられた時間情報によってイベントに課された順序で処理される可能性があり、先行のイベントが後のイベントよりも前に処理される。

イベントストリームにおけるイベントに関連付けられた時間情報（たとえばタイムスタンプ）は、ストリームのソースによって設定されてもよく、または、代替的には、ストリームを受取るシステムによって設定されてもよい。たとえば、いくつかの実施形態においては、イベントストリームを受取るシステム上で心臓の鼓動が維持されてもよく、イベントに関連付けられた時間は、心臓の鼓動によって測定されるようなシステムへのイベントの到着時間に基づいてもよい。イベントストリームにおける２つのイベントは同じ時間情報を有することができる。なお、タイムスタンプの順序付けが１つのイベントストリームにとって特有であるが、さまざまなストリームのイベントが任意にインターリーブされ得ることにも留意されたい。

イベントストリームは、関連付けられたスキーマ「Ｓ」を有してもよい。スキーマは、時間情報と１つ以上の名前付き属性のセットとを含み得る。特定のイベントストリームに属するすべてのイベントは、その特定のイベントストリームに関連付けられたスキーマに合致する。したがって、イベントストリーム（ｓ，Ｔ）の場合、当該イベントストリームは、（<time_stamp>, <attribute(s)>）としてスキーマ「Ｓ」を有し得る。この場合、＜attributes＞はスキーマのデータ部分を表わし、１つ以上の属性を含み得る。たとえば、株価表示機のイベントストリームについてのスキーマは、属性＜stock symbol＞および＜stock price＞を含み得る。このようなストリームを介して受取られたイベントは各々、タイムスタンプおよび２つの属性を有することとなる。たとえば、株価表示機イベントストリームは以下のイベントおよび関連付けられたタイムスタンプを受取ってもよい：
…
(<timestamp_N>, <NVDA,4>)
(<timestamp_N+1>, <ORCL,62>)
(<timestamp_N+2>, <PCAR,38>)
(<timestamp_N+3>, <SPOT,53>)
(<timestamp_N+4>, <PDCO,44>)
(<timestamp_N+5>, <PTEN,50>)
…
上述のストリームにおいては、ストリームエレメント（＜timestamp_N+1＞，＜ORCL,62＞）の場合、イベントは、属性「stock_symbol」および「stock_value」を備えた＜ORCL,62＞である。ストリームエレメントに関連付けられたタイムスタンプは「timestamp_N+1」である。このため、連続的なイベントストリームはイベントのフローとなり、各々のイベントは同じ系列の属性を有する。

上述のように、ストリームは、ＣＱＬクエリが作用し得る主要なデータソースであってもよい。ストリームＳは、（「マルチセット」とも称される）一塊のエレメント（ｓ，Ｔ）であってもよい。この場合、「ｓ」はＳのスキーマにあり、「Ｔ」は時間ドメインにある。付加的には、ストリームエレメントはタプルのタイムスタンプ対であってもよく、これは、一連のタイムスタンプ付きタプル挿入として表わすことができる。言いかえれば、ストリームは、一連のタイムスタンプ付きタプルであってもよい。場合によっては、同じタイムスタンプを備えた２つ以上のタプルがあってもよい。さらに、入力データストリームのタプルは、タイムスタンプが増大する順序でシステムに到達するように要求されてもよい。代替的には、（「時間可変関係」とも称され、リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同されるべきではない）関係は、時間ドメインから、スキーマＲのタプルからなる無制限の塊までのマッピングであってもよい。いくつかの例においては、関係は、無秩序な時間依存型タプルの塊（すなわち瞬間的な関係）であってもよい。場合によっては、時間の各々のインスタンスにおいては、関係は有限のセットであってもよい。これはまた、関係の変更状態を把握するために、挿入、削除および／または更新を含み得る一連のタイムスタンプ付きタプルとして表わすことができる。ストリームと同様に、関係は、関係の各タプルが準拠し得る一定のスキーマを有し得る。さらに、連続クエリは、この明細書中において用いられる場合、概して、ストリームおよび／または関係の（すなわち、ストリームおよび／または関係について照会された）データを処理することができる可能性がある。付加的には、関係は、ストリームのデータを参照してもよい。

いくつかの例においては、ビジネスインテリジェンス（business intelligence：ＢＩ）は、特定の間隔で（たとえば、場合によって毎日）ビジネス活動を促進および最適化するのに役立ち得る。このタイプのＢＩは、通常、オペレーショナルビジネスインテリジェンス、リアルタイムビジネスインテリジェンスまたはオペレーショナルインテリジェンス（operational intelligence：ＯＩ）と称される。オペレーショナルインテリジェンスは、いくつかの例においては、ＢＩとビジネス活動監視（business activity monitoring：ＢＡＭ）との間の境界を曖昧にする。たとえば、ＢＩは履歴データの周期的な問合せに焦点が合わされる可能性があり、そのため、後方重視の焦点を有する可能性がある。しかしながら、ＢＩはまた、オペレーショナルアプリケーションに分類されてもよく、したがって、単なる戦略上の分析ツールからビジネスオペレーションにおける最前線にまで拡大する可能性がある。そのため、ＢＩシステムはまた、イベントストリームを分析して、総計をリアルタイムで計算するように構成されてもよい。

いくつかの例においては、連続的なクエリ言語サービス（ＣＱ（continuous query）サービス）は、連続クエリを処理してリアルタイムアラートを使用可能にするためにＢＩ解析サーバを拡張するように構成されてもよい。ＣＱサービスによって、いくつかの局面においては、ＢＩ解析サーバおよびＣＱＬエンジンとが統合される可能性がある。単なる一例として、ＢＩ解析サーバは、ＣＱサービスに連続クエリを委ねてもよく、ＣＱサービスはまた、ＣＱＬエンジンのための論理データベース（database：ＤＢ）ゲートウェイとして機能してもよい。このようにして、ＣＱＬエンジンは、その解析能力およびセマンティックモデリングのためにＢＩ解析サーバを活用可能であり得る。

いくつかの例においては、ＣＱサービスは、特に以下の機能を提供し得る：
−ＣＱＬエンジンゲートウェイとしての、ＢＩ解析サーバのための遠隔操作サービス；
−イベントソース／シンクアダプタ；
−ＣＱＬ拡張に加えて論理ＳＱＬからデータ定義言語（data definition language：ＤＤＬ）を生成；
−すべてのタイプの連続クエリおよびインプリメンテーション選択のために一体化モデルを提供；
−メタデータの維持、再開可能性のサポート；ならびに、
−高可用性およびスケーラビリティのサポート。

付加的には、いくつかの例においては、ＯＩは、可視性および洞察力をビジネスオペレーションに与えることができるリアルタイムのダイナミックなビジネス解析の一形式である。ＯＩは、しばしば、ＢＩもしくはリアルタイムＢＩにリンクされるか、またはＢＩもしくはリアルタイムＢＩと比較される。というのも、これらＢＩおよびリアルタイムＢＩがともに両方が大量の情報を把握するのに役立つからである。但し、いくつかの基本的な違いがある。すなわち、ＯＩは主としてアクティビティ中心であり得るのに対して、ＢＩは主としてデータ中心であり得る。加えて、従来から、パターンを識別するために事後ベースかつレポートベースのアプローチとして用いられる可能性のあるＢＩとは異なり、ＯＩは、開発状況（たとえば、トレンドおよびパターン）を検出してこれに対応するのにより適切であり得る。

いくつかの例においては、ビジネスイベント分析および監視（business event analysis and monitoring：ＢＥＡＭ）システムが、機内データの処理および／または受取りのためにＣＱＬエンジンを含んでもよい。たとえば、ＣＱＬエンジンは、受信したリアルタイム情報（たとえばＢＩまたはＯＩ）を照会または処理するように構成されたインメモリ・リアルタイムイベント処理エンジンであってもよい。ＣＱＬエンジンは、時間的なセマンティックを利用または理解し、データのウィンドウの定義を処理することを可能にするように構成されてもよい。ＣＱＬエンジンを利用する場合、場合によっては、受信データ上でクエリを常に実行することが必要になるかもしれない。

いくつかの局面においては、ＣＱＬエンジンは十分に発達したクエリ言語を含んでもよい。そのため、ユーザは照会の観点から演算を指定してもよい。加えて、ＣＱＬエンジンは、クエリ言語特徴、オペレータ共有、豊富なパターンマッチング、豊富な言語構築などを利用して、メモリを最適化するように設計されてもよい。加えて、いくつかの例においては、ＣＱＬエンジンは履歴データおよびストリーミングデータの両方を処理してもよい。たとえば、カリフォルニアでの売上高が一定の目標を超えた場合、ユーザはアラートを送信するようにクエリを設定することができる。このため、いくつかの例においては、アラートは、履歴上の売上データならびに受信した実際の（すなわち、リアルタイムの）売上データに少なくとも部分的に基づいている可能性がある。

いくつかの例においては、ＣＱＬエンジンまたは以下に記載される概念の他の特徴が、履歴コンテキスト（すなわち倉庫データ）を受信データとリアルタイムで結合するように構成されてもよい。これにより、場合によっては、本開示では、データベースに格納された情報および機内情報の範囲が説明され得る。データベースに格納された情報および機内情報はともにＢＩデータを含み得る。このため、データベースは、いくつかの例においては、ＢＩサーバであってもよく、または、如何なるタイプのデータベースであってもよい。さらに、いくつかの例においては、本開示の特徴は、ユーザがコードをプログラムするかまたは書込む方法を知らなくても、上述の特徴の実施を可能にし得る。言いかえれば、これらの特徴は、特徴を豊富に含むユーザインターフェイス（user interface：ＵＩ）において提供されてもよく、または、非デベロッパがリアルタイムデータと履歴データとの結合を実現することを可能にする他の態様で提供されてもよい。

いくつかの実施形態においては、連続データストリームにおいて受取られたイベントは、データストリームにおける特定のパターンの発生を検出するために、実行時間中に処理されてもよい。「パターン」は、連続データストリームにおいて、各々がいくつかの条件を満たす一連の連続したイベントまたはタプルを構成してもよい。一例として、株の取引き高の変化などのイベントが発生すると、結果として、株式の価格の変化などの別のイベントが発生し、金融分野に関する「株のティック」イベントを受取る連続データストリームにおいて或る「パターン」を構成し得る。

多重連続データストリームの文脈においては、「パターン」は、第１のデータストリームにおける第１のイベントの発生、後続する第２のデータストリームにおける別のイベントの発生などを構成し得る。一例として、第１の一連のイベントによって促進される第１のビジネスプロセスについて検討する。この場合、これらイベントはレンタカーの予約アプリケーションに関するものである。同様に、第２の一連のイベントによって促進される第２のビジネスプロセスを検討する。この場合、イベントは飛行機の予約アプリケーションに関するものである。加えて、第１の一連のイベントが第１の連続入力データストリームを介して受取られ、第２の一連のイベントが第２の連続入力データストリームを介して受取られると想定する。このような状況においては、第１の連続入力データストリームにおけるイベント（たとえばユーザによる自動車の予約）が到着し、その後、第２の連続入力データストリームにおける別のイベント（たとえば、ユーザへの飛行チケットの発行）が到着したときに、パターンマッチを出力することが所望され得る。

一実施形態においては、多重連続入力データストリームにわたるパターンマッチングは、受信した入力データストリームに連続クエリ（たとえばＣＱＬクエリ）を適用することによって実行されてもよい。ある１つのアプローチにおいては、中間ストリームに対応するビューを規定する結果とのパターンマッチングが実行されるべき関連入力データストリームのうち、すべてのＵＮＩＯＮまたはすべてのサブセットを最初に実行することによって、多重連続入力データストリームにわたるパターンマッチングが実行されてもよい。次いで、マッチングされるべきパターンはこの単一の中間ストリームにわたって特定することができる。一実施形態においては、ＣＱＬ言語構築ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ文節は、多重入力データストリームを識別するＣＱＬクエリにおいてパターン認識を実行するために用いられてもよい。次いで、パターンを、ビューに含まれるすべてのストリームにマッチングさせてもよい。

一例として、以下のＣＱＬクエリ「Ｑ１」を検討する。Ｑ１は、第１の入力データストリームＳ１および第２の入力データストリームＳ２にわたってマッチングされるべきパターンを指定する連続クエリである。

Q1:
SELECT *
FROM
(SELECT cleintId, p1, -1L as p2 from S1 UNION ALL SELECT clientId, -1L as p1, p2 from S1) AS S MATCH_RECOGNIZE
(
PARTITION BY clientId
MEASURES
A.p1 as p1,
B.P2 AS P2
PATTERN (A b)
DEFINE
A as (P1 !=-Il)
b as (P2 !=-1l)
)
加えて、ストリームＳ１が第１のスキーマによって規定されると想定する：Ｓ１（ｉｎｔ ｐ１， ｉｎｔ ｃｌｉｅｎｔＩｄ)。さらに、ストリームＳ２が第２のスキーマによって規定されると想定する：Ｓ２（ｉｎｔ ｐ２， ｉｎｔ ｃｌｉｅｎｔＩｄ）。この場合、ｐ１、ｐ２およびｃｌｉｅｎｔＩｄは、ストリームＳ１およびストリームＳ２の１つ以上の属性に対応する。

クエリＱ１は、ストリームＳ１およびストリームＳ２のＵＮＩＯＮを指定するＦＲＯＭ分節を含む。ＵＮＩＯＮ ＡＬＬクエリにより、ストリームＳ１およびストリームＳ２の結果セットを結合するために、ＣＱＬ ＵＮＩＯＮ ＡＬＬクエリ内のＣＱＬ ＳＥＬＥＣＴステートメントは各々、典型的には、類似のデータタイプをもつ結果セットにおいて同数のフィールドを有することが必要とされる。上述のクエリＱ１の例においては、ストリームＳ１のスキーマはストリームＳ２のスキーマとは異なる。１つのアプローチにおいては、ストリームＳ１およびストリームＳ２は、ストリームＳ１およびストリームＳ２のスキーマ同士を正規化することによって結合され得る。

一例においては、スキーマの正規化は、ストリームＳ１およびストリームＳ２のスキーマの各々に付加的なカラムを追加することによって実行されてもよい。上述のクエリＱ１の例においては、カラムは、ストリームＳ１およびストリームＳ２のスキーマの各々に追加され、「−１Ｌ」などのハードコード化された値でポピュレートされてスキーマを正規化する。しかしながら、各々のストリームにハードコード化されたデータ値を導入することは、エラーが起こり易い手動プロセスである。なぜなら、異なるスキーマで多重入力データストリームを識別するＣＱＬクエリが処理されるたびに、ハードコード化された値を入力しなければならないからである。

本開示の一実施形態においては、１つ以上の関与する入力データストリームを表わす同種スキーマが生成される。いくつかの実施形態においては、同種スキーマは、関与する入力データストリームの１つ以上の属性についての１つ以上のダイナミックデータタイプを作成することによって生成されてもよい。ダイナミックデータタイプおよび同種スキーマを生成することにより、ＵＮＩＯＮ ＡＬＬサブクエリ内の各々のＳＥＬＥＣＴステートメントが、同数のフィールドおよび類似するデータタイプを含むことが可能となり、結果として、ストリームＳ１およびストリームＳ２の結果セットがＳＥＬＥＣＴステートメントを用いて結合され得る。加えて、関与する入力データストリームの属性についてのダイナミックデータタイプの生成はリアルタイムで実行され、ＣＱＬクエリが処理されるたびに、ハードコード化された値を関与する入力データストリームに導入する必要がなくなる。一例においては、以下に詳細に説明されるように、ダイナミックデータタイプは、入力データストリームの１つ以上の属性について識別された複合データタイプを参照する可能性もある。

いくつかの実施形態においては、次いで、入力データストリームが結合されて、同種スキーマに基づいて結合データストリームが生成されてもよい。次いで、入力データストリームにわたるパターンを検出するために、連続クエリが結合データストリームにわたって処理されてもよい。一実施形態においては、多重入力データストリームを識別するＣＱＬクエリでパターン認識を実行するために、ＣＱＬ言語構築ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節が用いられてもよい。多重入力データストリームを識別するＣＱＬクエリにおけるパターン認識を実行するために同種スキーマおよびダイナミックデータタイプが生成および利用され得る態様の付加的な詳細が、以下の図１〜図４において詳細に説明される。

ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節を用いると、ユーザは、相関変数と称される識別子を用いることによって、受信したイベントの属性に関する条件を規定し、パターンマッチングについての条件を特定することができる。上述のとおり、入力データストリームにおける一連の連続イベントまたはタプルは、各々がいくつかの条件を満たすものであって、パターンを構成している。パターン認識機能は、ユーザが、受信したイベントまたはタプルの属性についての条件を規定することと、相関変数と称される文字列名を用いることによってこれらの条件を識別することとを可能にする。

上述のクエリＱ１においては、「Ａ」および「Ｂ」は相関変数である。マッチングさせるべきパターンは、これらの相関変数に対する正規表現として指定され、有効な一致として認識されるべきさまざまな受信イベントによって条件が満たされるべき順番または順序を決定する。これらの条件を満たす入力データストリームにおける一連の連続イベントがパターンを構成する。一実施形態においては、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥクエリの出力はストリームである。上述のクエリＱ１においては、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節はまた、いくつかのサブ文節を含む。

ＤＥＦＩＮＥサブ文節は、各々の相関変数についてのブール条件を指定する。これは、如何なる論理式または演算式として指定されてもよく、条件と一致するイベントの属性に対して如何なる単一行関数または集約関数を適用してもよい。入力データストリームを介して新しいイベントを受取ると、その時点で関連している相関変数の条件が評価される。イベントは、それがその規定条件を満たしている場合には相関変数と一致したものとみなされる。特定の入力は０、１またはそれ以上の相関変数と一致し得る。入力イベントを受取った際に評価されるべき関連条件は、ＰＡＴＴＥＲＮ分節正規表現によって管理される処理ロジックと、それより前の入力を処理した後に達するパターン認識プロセスにおける状態とによって決定される。条件は、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節が適用されているストリームを評価するストリームまたはビューのスキーマの属性のうちのいずれを指してもよい。ＰＡＴＴＥＲＮ分節における相関変数は、ＤＥＦＩＮＥ分節において指定される必要はない。このような相関変数についてのデフォルトは常に真である叙述部となる。このような相関変数はすべてのイベントと一致する。

ＰＡＲＴＩＴＩＯＮ ＢＹサブ文節はストリーム属性を指定するが、このストリーム属性に基づいて、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節がその結果を分割するはずである。ＰＡＲＴＩＴＩＯＮ ＢＹ分節がない場合、すべてのストリーム属性は同じ区画に属する。ＰＡＲＴＩＴＩＯＮ ＢＹ分節がパターンマッチングと共に存在する場合、入力データストリームは、論理的には、区画リストにおいて記載される属性に基づいて分割され、パターンマッチングが区画内においてなされる。上述のクエリＱ１においては、（ストリームＳ１およびストリームＳ２に共通の属性である）「ｃｌｉｅｎｔＩｄ」属性が、ＰＡＲＴＩＴＩＯＮ ＢＹ分節において指定され、これにより、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節がその結果を分割し得る。

ＭＥＡＳＵＲＥＳサブ文節は、指定されたパターンとうまく一致するイベントの１つ以上の属性値をエクスポートし（たとえば、ＳＥＬＥＣＴ分節に含めることを可能にし）、さらに、それらの属性値について表現を指定することを可能にする。この分節を用いることにより、ＤＥＦＩＮＥ分節における条件（相関変数）と一致するイベントストリームにおけるイベントの属性についての表現を規定し、これらの表現を別名で記載し、これにより、このＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ条件が一部をなす主クエリのＳＥＬＥＣＴ分節においてこれらの表現を好適に用いることができるようにし得る。イベントストリームの属性は、直接的または相関変数を介して参照され得る。

ＰＡＴＴＥＲＮサブ文節は、１つ以上の相関変数に関する正規表現として一致させるべきパターンを指定する。受信イベントは与えられた順序で（左から右へと）これらの条件と一致するはずである。正規表現は、以下のような相関変数およびパターン修飾子から構成され得る：
^＊：０回以上
＋：１回以上
？：０回または１回など。

いくつかの実施形態においては、上述の１文字パターン修飾子は最大または「グリーディ（greedy）」であり、これらは、それらが適用される正規表現のうち可能な限り多くのインスタンスと一致するよう企図されるだろう。パターン修飾子はまた２文字であって、最小または「リラクタント（reluctant）」であり、それらが適用される正規表現のうち可能な限り少数のインスタンスと一致するよう企図されるだろう。２文字の修飾子の例は、以下を含むが、それらに限定されない。

^＊？：０回以上
＋？：１回以上
？？：０回または１回。

パターンマッチングの例として、以下のパターンを検討する：
パターン（ＡＢ^＊Ｃ）
このパターン分節は、以下の条件が連続的な受信入力イベントによって満たされたときにパターンマッチが認識されるだろうことを意味する：
状態１：１つのイベントタプルが、相関変数Ａを規定する条件と一致し、その後、
状態２：ゼロ以上のタプルが相関変数Ｂと一致し、その後、
状態３：１つのタプルが相関可変Ｃと一致する。

状態１、状態２および状態３を含む状態は、パターン（ＡＢ^＊Ｃ）についてのさまざまな状態を表わし得る。状態３はパターンについての最終状態である。パターンマッチが特定の状態であり、同じ特定の状態のままであり得るか、または、次のイベントのために特定の状態から次の状態まで移行し得る場合、これは、バインディングが大きくなる可能性があることを示唆している可能性がある。パターンは、バインディングが最終状態である場合に一致したとみなされてもよい。状態２である間、相関変数ＢおよびＣの両方と一致するタプルまたはイベントが到達する場合（これによって、これら相関変数ＢおよびＣの両方の規定条件が満たされるので）、Ｂについての修飾子^＊がグリーディであれば、そのタプルはＣではなくＢと一致したとみなされる可能性がある。したがって、グリーディの特性があるために、ＢはＣよりも優先され、より多くのＢが一致する可能性がある。パターン表現がＡＢ^＊Ｃ？である場合、Ｂに対してレイジーまたはリラクタントな修飾子が用いられ、さらに、ＢおよびＣの両方と一致するタプルはＣとしか一致しないものとして処理される可能性がある。このため、この例においては、ＣはＢよりも優先される可能性があり、一致させるＢの数がより少なくなる可能性がある。

上述のクエリＱ１においては、パターン（ＡＢ）は以下の場合に一致する：
状態１：１つのイベントタプルが相関変数Ａを規定する条件と一致し、その後、
状態２（最終状態）：１つのタプルが相関変数Ｂと一致する。

状態１および状態２などの状態は、パターン（ＡＢ）についてのさまざまな実現可能な状態を表わし、状態２はパターンについての最終状態である。

上述および以下の技術は、いくつかの方法で、いくつかの文脈において実現され得る。いくつかの実現例および文脈が、添付の図面に関連付けて以下においてより詳細に提供される。しかしながら、以下の実現例および文脈は多数あるうちの数例に過ぎない。

図１は、多重入力データストリームにわたってパターンマッチングを実行するための技術が実現され得る簡略化された例示的なシステムまたはアーキテクチャ１００を示す。アーキテクチャ１００においては、１つ以上のユーザ１０２（たとえば口座名義人）はユーザコンピューティング装置１０４（１）〜１４０（Ｎ）（集合的に「ユーザ装置１０４」）を利用して、１つ以上のネットワーク１０８を介して１つ以上のサービスプロバイダコンピュータ１０６にアクセスし得る。いくつかの局面においては、サービスプロバイダコンピュータ１０６はまた、ネットワーク１０８を介して１つ以上のストリーミングデータソースコンピュータ１１０および／または１つ以上のデータベース１１２と通信し得る。たとえば、ユーザ１０２はサービスプロバイダコンピュータ１０６を利用して、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２のデータにアクセスするかまたは当該データを管理し得る（たとえば、クエリは１１０および１１２のいずれかまたは両方に対して実行され得る）。データベース１１２はリレーショナルデータベース、ＳＱＬサーバなどであってもよく、いくつかの例においては、ユーザ１０２の代わりに履歴データ、イベントデータ、リレーション、アーカイブされたリレーションなどを管理してもよい。加えて、データベース１１２は、ストリーミングデータソースコンピュータ１１０によって提供されるデータを受取るかまたは格納し得る。いくつかの例においては、ユーザ１０２はユーザ装置１０４を利用して、クエリ（「クエリステートメント」とも称される）またはデータについての他の要求（たとえば履歴イベントデータ、ストリーミングイベントデータなど）を提供することによってサービスプロバイダコンピュータ１０６と対話し得る。次いで、このようなクエリまたは要求がサービスプロバイダコンピュータ１０６によって実行されて、データベース１１２のデータおよび／またはストリーミングデータソースコンピュータ１１０からの受信データが処理され得る。さらに、いくつかの例においては、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２は、サービスプロバイダコンピュータ１０６に関連付けられた一体型の分散環境の一部であってもよい。

いくつかの例においては、ネットワーク１０８は、ケーブルネットワーク、インターネット、ワイヤレスネットワーク、セルラーネットワーク、イントラネットシステム、ならびに／または、他のプライベートネットワークおよび／もしくはパブリックネットワークなどの複数のさまざまなタイプのネットワークのうちのいずれかまたはそれらの組合せを含み得る。図示される例は、ネットワーク１０８を介してサービスプロバイダコンピュータ１０６にアクセスするユーザ１０２を表わしており、記載された技術は、ユーザ１０２が、地上通信電話によって１つ以上のユーザ装置１０４を介して、キオスク経由で、または他の方法で、１つ以上のサービスプロバイダコンピュータ１０６と対話する場合にも同様に適用され得る。なお、記載された技術が、他のクライアント／サーバ構成（たとえばセットトップボックスなど）において、ならびに非クライアント／サーバ構成（たとえば局所的に格納されたアプリケーションなど）においても同様に適用され得ることに留意されたい。

ユーザ装置１０４は、携帯電話、スマートフォン、携帯情報端末（personal digital assistant：ＰＤＡ）、ラップトップコンピュータ、デスクトップコンピュータ、シンクライアントデバイス、タブレットＰＣなどの如何なるタイプのコンピューティング装置であってもよいが、これらに限定されない。いくつかの例においては、ユーザ装置１０４は、ネットワーク１０８を介して、または他のネットワーク接続を介して、サービスプロバイダコンピュータ１０６と通信してもよい。さらに、ユーザ装置１０４はまた、データベース１１２（または他のデータストア）のデータの処理を要求するための１つ以上のクエリまたはクエリステートメントを供給するように構成されてもよい。

いくつかの局面においては、サービスプロバイダコンピュータ１０６はまた、サーバなどのモバイル、デスクトップ、シンクライアントおよび／もしくはクラウドコンピューティング装置などの如何なるタイプのコンピューティング装置などであってもよいが、これらに限定されない。いくつかの例においては、サービスプロバイダコンピュータ１０６は、ネットワーク１０８を介して、または他のネットワーク接続を介してユーザ装置１０４と通信してもよい。サービスプロバイダコンピュータ１０６は、サーバファームとして、または互いに関連付けられない個々のサーバとして、場合によってはクラスタに配置される１つ以上のサーバを含み得る。これらのサーバは、この明細書中に記載されるような、ＣＱＬリレーションの管理、入力リレーションの生成、入力リレーションに関連付けられた構成可能なウィンドウオペレータ、および出力リレーションの生成を含むがこれらに限定されない、この明細書中に記載される特徴を実行またはホストするように構成されてもよい。加えて、いくつかの局面においては、サービスプロバイダコンピュータ１０６は、ストリーミングデータソースコンピュータ１１０および／もしくはデータベース１１２を含む一体型分散コンピューティング環境の一部として構成されてもよい。

具体的な一構成においては、サービスプロバイダコンピュータ１０６は、少なくとも１つのメモリ１１４および１つ以上の処理ユニット（またはプロセッサ）１３４を含み得る。プロセッサ１３４は、ハードウェア、コンピュータ実行可能命令、ファームウェアまたはこれらの組合せで、適宜実現され得る。プロセッサ１３４のコンピュータ実行可能命令またはファームウェア実現例は、記載されたさまざまな機能を実行するために好適なプログラミング言語で書込まれたコンピュータ実行可能命令またはマシン実行可能命令を含み得る。

メモリ１１４は、これらのプログラムの実行中に生成されるデータに加えて、プロセッサ１３４上でロード可能かつ実行可能なプログラム命令を格納してもよい。サービスプロバイダコンピュータ１０６の構成およびタイプに応じて、メモリ１１４は、揮発性（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）であってもよく、および／もしくは不揮発性（読取専用メモリ（read-only memory：ＲＯＭ）、フラッシュメモリなど）であってもよい。サービスプロバイダコンピュータ１０６またはサーバはまた、リムーバブルストレージおよび／もしくは非リムーバブルストレージを含み得る追加の記憶装置１３６を含んでもよい。追加の記憶装置１３６は、磁気記憶装置、光ディスクおよび／もしくはテープ記憶装置を含み得るが、これらに限定されない。ディスクドライブおよびそれらの関連するコンピュータ読取可能媒体は、コンピューティング装置のためにコンピュータ読取可能命令、データ構造、プログラムモジュールおよび他のデータを不揮発的に格納し得る。いくつかの実現例においては、メモリ１１４は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）またはＲＯＭなどの複数のさまざまなタイプのメモリを含み得る。

メモリ１１４および追加の記憶装置１３６はともに、取外し可能かつ取外し不可能であって、コンピュータ読取可能記憶媒体のあらゆる例となる。たとえば、コンピュータ読取可能記憶媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュールまたは他のデータなどの情報を格納するためのいずれかの方法または技術において実現される揮発性または不揮発性の、取外し可能であるかまたは取外し不可能である媒体を含み得る。メモリ１１４および追加の記憶装置１３６はコンピュータ記憶媒体のあらゆる例となる。

サービスプロバイダコンピュータ１０６はまた、サービスプロバイダコンピュータ１０６が、ネットワーク１０８上で、格納されたデータベース、別のコンピューティング装置もしくはサーバ、ユーザ端末および／または他の装置と通信することを可能にする通信接続部１３８を含んでもよい。サービスプロバイダコンピュータ１０６はまた、キーボード、マウス、ペン、音声入力装置、タッチ入力装置、ディスプレイ、１つ以上のスピーカ、プリンタなどの入出力（input/output：Ｉ／Ｏ）装置１４０を含んでもよい。

メモリ１１４のコンテンツをより詳細に参照すると、メモリ１１４は、オペレーティングシステム１２４と、少なくとも入力データストリームモジュール１１６、ダイナミックデータタイプ生成モジュール１１８、結合データストリーム生成モジュール１２０およびパターン検知モジュール１２２を含む、この明細書中に開示される特徴を実現するための１つ以上のアプリケーションプログラムまたはサービスとを含み得る。この明細書中において用いられるように、モジュールは、サービスの一部でありサーバまたはサーバのクラスタによって実行されるプログラミングモジュールを指し得る。この特定のコンテキストにおいては、モジュールは、サービスプロバイダコンピュータ１０６の一部であるサーバまたはサーバのクラスタによって実行されてもよい。他の実施形態においては、モジュールは、サービスプロバイダコンピュータ１０６の一部であり得るＣＱＬエンジンおよび／もしくは（図２に示される）ＣＱサービス２００によって実行されてもよい。さまざまな実施形態においては、以下に詳細に説明されるように、モジュール１１６、１１８、１２０および１２２は、複数の入力データストリームにわたるパターンの検出を可能にする機能を実行するように構成されてもよい。これらのモジュールは、ハードウェアで、ソフトウェアで、またはそれらの組合せで実現され得る。図１に示されるさまざまなモジュールは、説明を目的としたものであり、本発明の実施形態の範囲を限定するように意図されたものではない。代替的な実施形態に含まれ得るモジュールは、図１に示されるよりも多くてもまたは少なくてもよい。

一実施形態においては、入力データストリームモジュール１１６は、１つ以上の入力データストリーム１２６を受取るか、識別するか、生成するかまたは提供するように構成され得る。一例においては、入力データストリーム１２６は、１つ以上のアプリケーションに関するデータまたはイベントからなる受信連続データストリームを含み得る。いくつかの実施形態においては、入力データストリーム１２６は、データソースコンピュータ１１０および／もしくはデータベース１１２から受取られてもよい。

いくつかの例においては、入力データストリーム１２６は、１つ以上のアプリケーションに関する一連のタイムスタンプ付きタプルまたはデータ記録を含み得る。たとえば、入力データストリーム１２６におけるデータ記録は各々、以下のスキーマ（＜time_stamp＞，＜attribute(s)＞）によって表わされ得るイベントストリームエントリを含んでもよい。＜attributes＞はスキーマのデータ部分を表わし、１つ以上の属性を含み得る。

一例として、入力データストリーム１２６が第１のデータストリームおよび第２のデータストリームを含むものとする。この例のために、さらに、第１の入力データストリームが第１のアプリケーションに関するイベントの第１のセット（たとえばレンタカー予約アプリケーション）を含むものとし、第２の入力データストリームが第２のアプリケーションに関するイベントの第２のセット（たとえば飛行機予約アプリケーション）を含むものとする。加えて、第１の入力データストリームが第１のスキーマＳ１：（ｃ１，整数，ｃ２，整数）によって規定されるものとし、第２の入力データストリームが第２のスキーマＳ２：（ｃ１，整数，ｃ３，整数）によって規定されるものとする。

一実施形態においては、第１の入力データストリームおよび第２の入力データストリームを分析してパターンを検出してもよい。この場合、「パターン」は、第１のデータストリームにおけるイベントの発生と、後続する第２のデータストリームにおける別のイベントの発生とを構成し得る。一例においては、パターンマッチングは、受信した連続データストリームに連続クエリ（たとえばＣＱＬクエリ）を適用することによって実行されてもよい。図２は、多重入力データストリームに対してＣＱＬクエリを適用することによってパターンマッチングを実行するためのＣＱＬエンジンおよび／もしくはＣＱサービス２００のうち少なくとも１つの実現例を記載する。上述の説明は第１のデータストリームおよび第２のデータストリームにわたってパターンを検出することに関連しているが、開示された技術が、少なくともいくつかの実施形態においては、多重連続入力データストリームにわたるパターンの検出に適用され得ることが認識されるはずである。

いくつかの実施形態においては、入力データストリームの分析は、最初に、ダイナミックデータタイプ生成モジュール１１８によって実行されてもよい。一実施形態においては、ダイナミックデータタイプ生成モジュール１１８は、入力データストリームモジュール１１６から第１の入力データストリームおよび第２の入力データストリームを受取り、入力データストリームにおける１つ以上の属性を識別するように構成されてもよい。いくつかの例においては、ダイナミックデータタイプ生成モジュール１１８は、第１のデータストリームの第１の属性および第２のデータストリームの第２の属性を識別するように構成されてもよい。一例においては、第１の属性は、第２のデータストリームには存在しない属性として識別されてもよく、第２の属性は、第１のデータストリームには存在しない属性として識別されてもよい。

上に説明されたデータストリームＳ１およびデータストリームＳ２の例に従って、一実施形態においては、ダイナミックデータタイプ生成モジュール１１８は、第１の属性「ｃ２」を、第２のデータストリームＳ２には存在しない第１のデータストリームＳ１における属性として識別してもよい。同様に、ダイナミックデータタイプ生成モジュール１１８は、第２の属性「ｃ３」を、第１のデータストリームＳ１には存在しない第２のデータストリームＳ２における属性として識別してもよい。上述の説明は、ストリームＳ１およびストリームＳ２において識別された第１の属性および第２の属性に関するものであるが、他の実施形態においては、ダイナミックデータタイプ生成モジュール１１８が、ストリームＳ１およびストリームＳ２からの付加的な属性を識別するように構成され得ることが認識されるはずである。

いくつかの実施形態においては、ダイナミックデータタイプ生成モジュール１１８はさらに、第１の属性についての第１のダイナミックデータタイプおよび第２の属性についての第２のダイナミックデータタイプを生成するように構成されてもよい。一例においては、第１のダイナミックデータタイプは第１のデータストリームの第１の属性に対応する第１のデータ値を格納するように構成され、第２のダイナミックデータタイプは第２のデータストリームの第２の属性に対応する第２のデータ値を格納するように構成される。

いくつかの実施形態においては、ダイナミックデータタイプは、この明細書中において「フィールド」と称される１つ以上のメンバタイプを含む複合データタイプとして実現されてもよい。一例においては、メンバフィールドは名前および関連付けられたタイプを含んでもよい。フィールドタイプは、たとえばＣＱＬ拡張可能タイプなどの如何なるＣＱＬ固有のタイプであってもよい。いくつかの例においては、サービス（たとえば、図２に示されるＣＱＬエンジンおよび／もしくはＣＱサービス２００）は、ダイナミックデータタイプがそのパブリックフィールド（たとえばフィールド名、フィールドのデータタイプ）を指定することによって作成および規定され得る１つ以上のアプリケーションプログラミングインターフェイス（ＡＰＩ：application programming interface）を提供することによって、ダイナミックデータタイプについてのＣＱＬ拡張可能タイプを実現するように構成されてもよい。

いくつかの実施形態においては、ダイナミックデータタイプ生成モジュール１１８は、第１のデータストリームおよび第２のデータストリームの両方に存在する属性として識別され得る共通属性を識別するように構成されてもよい。一実施形態においては、ダイナミックデータタイプ生成モジュール１１８はさらに、第１の入力データストリームおよび第２の入力データストリームを表わすために同種スキーマ１２８を生成するように構成されてもよい。一例においては、同種スキーマ１２８は、共通属性ならびに第１のダイナミックデータタイプおよび第２のダイナミックデータタイプを含む第１の入力データストリームおよび第２の入力データストリームの１つ以上の属性の表現を含み得る。

上述の第１の入力データストリームＳ１および第２の入力データストリームＳ２の例に従って、一実施形態においては、ストリームＳ１およびストリームＳ２についての同種スキーマＳが以下のように生成され得る：
同種スキーマＳ：($streamName char, c1 int, S1 Typ1@DynamicTypeCartridge, S2 Typ2@DynamicTypeCartridge)
ここで、「$streamName」は、同種スキーマにおけるデータタイプチャーを有する属性を指す。「$streamName」属性は、入力データストリームから受信された入力タプル（イベント）の入力データストリームソースを識別する。イベント「ｅ」について、「$streamName」属性は、「ｅ」がイベントであるストリームエイリアスの名前を格納してもよい。これにより、「$streamName」属性は、現在の入力イベント（タプル）が属する特定の入力データストリームの識別を可能にする。「ｃ１」は、同種スキーマにおける共通属性を指す。この場合、共通属性は、関与する入力データストリームすべてにおいて同じデータタイプおよび同じ名前を有する属性として識別される。たとえば、共通属性「ｃ１」は、入力データストリームＳ１および入力データストリームＳ２に関する第１のアプリケーションおよび第２のアプリケーションにアクセスするユーザを識別するユーザ属性を指してもよい。いくつかの例においては、共通属性を含む同種スキーマは、ＰＡＲＴＩＴＩＯＮ ｂｙ分節の規格で、それ自体がさまざまな入力データストリームからのイベントを含み得るサブストリームを作成することを可能にし得る。

加えて、「Typ1@DynamicTypeCartridge」は、第１のデータストリームの第１の属性に対応する第１のデータ値を格納するように構成された第１のダイナミックデータタイプを指す。一例においては、「Typ1@DynamicTypeCartridge」は、第１の入力データストリームＳ１における第１の属性「ｃ２」に対応するデータ値を格納するために用いられてもよい。一例として、第１の入力データストリームＳ１における第１の属性「ｃ２」は、第１のアプリケーション（たとえばレンタカー予約アプリケーション）にアクセスするユーザから得られる自動車予約識別番号を格納する自動車予約属性を指し得る。

同様に、「Typ2@DynamicTypeCartridge」は、第２のデータストリームの第２の属性に対応する第２のデータ値を格納するように構成された第２のダイナミックデータタイプを指す。一例においては、「Typ2@DynamicTypeCartridge」は、第２の入力データストリームＳ２における第２の属性「ｃ３」に対応するデータ値を格納するために用いられてもよい。一例として、第２の入力データストリームＳ２における第２の属性「ｃ３」は、第２のアプリケーション（たとえば飛行機予約アプリケーション）にアクセスするユーザのために飛行機予約識別番号を格納する飛行予約属性を指し得る。

上述の例の場合、タイプ「Typ1@DynamicTypeCartridge」のＳ１についての１つの属性（たとえば「ｃ２」）、およびタイプ「Typ2@DynamicTypeCartridge」のＳ２についての１つの属性（たとえば「ｃ３」）が存在することが確認され得る。「Typ1@DynamicTypeCartridge」は、同じデータタイプのストリームＳ１の各属性ごとに１つのパブリックフィールドを含み得る。同様に、「Typ2@DynamicTypeCartridge」は、ストリームＳ２の各属性ごとに１つのパブリックフィールドを含み得る。Ｔｙｐ１およびＴｙｐ２が内部タイプであって、エンドユーザにとって可視可能ではないかもしれないことに留意されたい。検討された例に関して、Ｔｙｐ１はパブリックフィールド「ｃ１」および「ｃ２」を含んでもよく、Ｔｙｐ２はパブリックフィールド「ｃ１」および「ｃ３」を含んでもよい。

一実施形態においては、このように生成された同種スキーマに基づいて、結合データストリーム生成モジュール１２０は結合データストリームを生成するように構成され得る。一例においては、結合データストリームは、第１の入力データストリームおよび第２の入力データストリームのＵＮＩＯＮを実行することによって生成されてもよい。この場合、第１の入力データストリームおよび第２の入力データストリームは、同種スキーマＳによって表現される。一例においては、ＣＱＬ ＵＮＩＯＮ ＡＬＬサブクエリは、同種スキーマに基づいてストリームＳ１およびストリームＳ２の結果セットを結合するために第１のデータストリームＳ１および第２のデータストリームＳ２に適用されてもよい。同種スキーマを生成することにより、ＵＮＩＯＮ ＡＬＬサブクエリ内の各々のＣＱＬ ＳＥＬＥＣＴステートメントが、結果セットにおける同数のフィールドおよび類似のデータタイプを有することが可能となる。したがって、ストリームＳ１およびストリームＳ２の結果セットは、同種スキーマに基づいてＵＮＩＯＮ ＡＬＬサブクエリにおけるＳＥＬＥＣＴステートメントを用いて結合されてもよい。ＵＮＩＯＮ ＡＬＬサブクエリを用いて第１のデータストリームと第２のデータストリームとを結合して結合データストリームを生成し得る態様を、図４において説明する。

いくつかの実施形態においては、パターン検出モジュール１２２は、さらに、結合データストリームに基づいてパターン１３２を検出するように構成されてもよい。一実施形態においては、パターン検出モジュールは、結合データストリームにＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節を適用することによってパターンマッチを出力するように構成されてもよい。一例として、検出されたパターンは、第１の入力データストリームＳ１における第１のイベント（たとえばユーザによる自動車予約）の到着と、後続する第２の入力データストリームＳ２における第２のイベント（たとえばユーザへの飛行機チケット発行）の到着とを含み得る。多重入力データストリームを識別するパターン認識をＣＱＬクエリで実行するようにパターン検出モジュールが構成され得る態様を、図３において説明する。

図２は、多重入力データストリームにわたってパターンを検出するための特徴が記載され得る簡略化されたブロック図を示す。図示のとおり、図２は、多重入力データストリームを管理するためのＣＱＬエンジンおよび／またはＣＱサービス２００の少なくとも１つの実現例を示す。いくつかの実施形態においては、図１に示されるモジュール１１６、１１８、１２０および１２２は、ＣＱＬエンジンおよび／もしくはＣＱサービス２００によって実行され得る。ＣＱＬエンジンおよび／もしくはＣＱサービス２００は、最初に、入力ソース２０４から情報を受取ってもよい。一例においては、入力ソース２０４は、１つ以上のアプリケーションに関するデータまたはイベントのストリームを含む連続入力データストリームを受取るデータソースコンピュータ１１０を含み得る。いくつかの実施形態においては、第１の入力データストリームＳ１ ２０６および第２の入力データストリームＳ２ ２０８を含むクエリ（たとえばＣＱＬクエリ）が識別されるかまたは受取られると、ＣＱＬエンジン２００は、ストリームＳ１およびストリームＳ２にわたってパターンを検出するためにクエリをパーズし得る。一実施形態においては、ＣＱＬエンジンおよび／またはＣＱサービス２００は、第１の入力データストリームおよび第２の入力データストリームのＵＮＩＯＮを最初に実行することによってＣＱＬクエリを実行してもよい。この場合、第１の入力データストリームおよび第２の入力データストリームは同種スキーマＳによって表現される。一実施形態においては、同種スキーマＳは、図１において説明されるようなダイナミックデータタイプ生成モジュール１１８によって生成されてもよい。

次いで、入力データストリームＳ１および入力データストリームＳ２が結合されて、同種スキーマに基づく結合データストリームが生成され得る。一実施形態においては、結合データストリームは結合データストリームモジュール１２０によって生成されてもよい。次いで、パターン検出モジュール１２２が、結合データストリームに対する連続クエリ（たとえばＣＱＬクエリ）を処理して、入力データストリームにわたってパターンを検出し得る。一実施形態においては、パターン検出モジュールは、結合データストリームに対してＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節を適用することによって、パターンマッチを出力するように構成されてもよい。いくつかの例においては、ＣＱＬエンジンおよび／またはＣＱサービス２００は、次いで、たとえば図１に示されるデータベース１１２におけるような出力宛先２１２において検出されたパターンを格納し得る。

図３は、本開示の一実施形態に従った、多重入力データストリームを識別するＣＱＬクエリを用いてパターン認識を実行する具体例である。一例においては、クエリ３００は、第１の入力データストリームＳ１および第２の入力データストリームＳ２にわたって一致させるべきパターンを指定する連続的な（たとえばＣＱＬ）クエリである。図３に示される例においては、ストリームＳ１およびストリームＳ２は括弧に囲まれてカンマで分離されたリストにおいて指定され、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節への入力として与えられる。結果として、クエリ３００のＦＲＯＭ分節は以下の式（Ｓ１，Ｓ２）ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥを用いて、好都合に表現され得る。いくつかの例においては、リストにおける各々のストリームは、ベースストリームとして、ストリームに対するビューの評価として、またはストリームに対するサブクエリの評価として識別されてもよい。

上述のようなカンマで分離されたリストを用いてストリームＳ１およびストリームＳ２が指定される場合、関与するストリームの各々は別個のエイリアスで識別される必要があるかもしれない。そのため、たとえば、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節が｛Ｓ，Ｓ｝に対して適用される場合、ＦＲＯＭ分節は（Ｓ，Ｓ ＡＳ Ｓ１）ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ）として指定される必要があるかもしれない。すなわち、任意のＡＳ分節は、第２のストリームＳを別名で記載して別個のエイリアス名を確実にするために導入される必要があるかもしれない。なお、明確なＡＳ分節が指定されない場合、他の例においてストリーム名がエイリアス名とみなされる可能性があることに留意されたい。

いくつかの実施形態においては、カンマで分離されたリストとしてのストリームＳ１およびストリームＳ２の表現は、入力データストリームＳ１および入力データストリームＳ２のＵＮＩＯＮと評価され得る。この場合、ストリームＳ１およびストリームＳ２は同種スキーマによって規定される。一実施形態においては、図４において詳細に説明されるように、結合データストリームは、ＵＮＩＯＮ ＡＬＬサブクエリの実行に基づいて生成されてもよく、結合データストリームはＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節への入力として供給されてもよい。次いで、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥが結合データストリームにおけるパターンを検出するために利用されてもよい。

上述のように、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節を用いると、ユーザは、受信したイベントの属性に関する条件を規定し、相関変数と称される識別子を用いることによってパターンマッチングについての条件を識別することができる。パターン認識機能は、ユーザが、受信したイベントまたはタプルの属性に関する条件を規定し、相関変数と称される文字列名を用いることによってこれらの条件を識別することを可能にする。

クエリ３００においては、「Ａ」は相関変数である。一致させるべきパターンは、この相関変数に関する正規表現として指定されており、条件が有効な一致と認識されるべきさまざまな受信イベントによって満たされるべきである順番または順序を決定する。一例においては、これらの条件を満たす入力データストリームＳ１および入力データストリームＳ２における連続イベントの順番がパターンを構成する。一実施形態においては、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥクエリの出力はストリームである。

図４は、本開示の別の実施形態に従った、多重入力データストリームを識別するＣＱＬクエリを用いてパターン認識を実行する具体例である。一実施形態においては、図４に示されるクエリ４００は、クエリ３００のＦＲＯＭ分節の内部表現を示す。一例においては、ＦＲＯＭ分節は、ストリームＳ１およびストリームＳ２のＵＮＩＯＮ ＡＬＬサブクエリとして表現されてもよく、この場合、ストリームＳ１およびストリームＳ２は同種スキーマによって表現される。

図４に示される例に関して、ストリームＳ１およびストリームＳ２を表わす同種スキーマは以下のように生成されてもよい：
同種スキーマＳ：($streamName char, c1 int, ELEMENT_TIME int, S1 Typ1@DynamicTypeCartridge, S2 Typ2@DynamicTypeCartridgeCartridge)
ここで、「Typ1@DynamicTypeCartridge」は、ストリームＳ２中に存在しないストリームＳ１の属性のために生成された第１のダイナミックデータタイプを表わす。同様に、「Typ2@DynamicTypeCartridge」は、ストリームＳ１中に存在しないストリームＳ２の属性のために生成された第２のダイナミックデータタイプを表わす。図４に示される例に関して、「Typ1@DynamicTypeCartridge」は、ストリームＳ２中に存在しないストリームＳ１における第１の属性「ｃ２」についての第１のダイナミックデータタイプを表わし、「Typ2@DynamicTypeCartridge」は、ストリームＳ１中に存在しないストリームＳ２における第２の属性「ｃ３」についての第２のダイナミックデータタイプを表わす。

一実施形態においては、上述のダイナミックデータタイプおよび同種スキーマを生成することによって、ストリームＳ１およびストリームＳ２の個別ストリーム特有の属性に以下のようにアクセスすることが可能となり得る。実行時には、ストリームＳ１から受取られたイベントに関して、「Typ1@DynamicTypeCartridge」ダイナミックデータタイプは、表現「Typ1@DynamicTypeCartridge(c1, c2)AS S1」を用いて、Ｓ２に存在しないストリームＳ１からの第１の属性「ｃ２」を表わすように構成されてもよく、「Typ2@DynamicTypeCartridge」ダイナミックデータタイプは、式「Typ2@DynamicTypeCartridge( ) AS S2」を用いて、Ｓ１に存在しないストリームＳ２からの第２の属性「ｃ３」を表わすように構成されてもよい。一例においては、「Typ2@DynamicTypeCartridge」は、受取られたイベントについてのストリームＳ２の第２の属性「ｃ３」のＮＵＬＬ値を格納してもよい。

同様に、ストリームＳ２から受取られたイベントに関して、「Typ1@DynamicTypeCartridge」ダイナミックデータタイプは、Ｓ２に存在しないストリームＳ１からの第１の属性（「ｃ２」）を「Typ1@DynamicTypeCartridge()AS S1」として表わし、属性「ｃ２」についてのＮＵＬＬ値を格納するように構成されてもよい。加えて、「Typ2@DynamicTypeCartridge」は、表現「Typ2@DynamicTypeCartridge(c1, c3) AS S2」を用いて、Ｓ１に存在しないストリームＳ２からの第２の属性「ｃ３」を表わすように構成されてもよい。一実施形態においては、上述のダイナミックデータタイプ表現を用いて、属性「ｃ２」がＣＱＬクエリにおいてＳ１．ｃ２としてアクセスされてもよく、属性「ｃ３」はＣＱＬクエリにおいてＳ２．ｃ３としてアクセスされてもよい。

加えて、図４に示される例においては、属性「ｃ１」および「ＥＬＥＭＥＮＴ＿ＴＩＭＥ」（タイムスタンプ値）は共通属性として識別されてもよい。いくつかの例においては、共通属性「ｃ１」はＡ．ｃ１またはＡ．Ｓ１．ｃ１として同種スキーマを用いてアクセスされてもよい。いくつかの例においては、ＰＡＲＴＩＴＩＯＮ ＢＹ分節も共通属性にアクセスするために用いられてもよい。

上述の同種スキーマおよびダイナミックデータタイプの生成により、ＵＮＩＯＮ ＡＬＬクエリ内の各々のＣＱＬ ＳＥＬＥＣＴステートメントが結果セットにおける同数のフィールドおよび類似のデータタイプを有することが可能になることが認識され得る。加えて、ダイナミックデータタイプは、特定のストリームに属さない属性に「ＮＵＬＬ」値を割当てることを可能にする。一実施形態においては、次いで、ストリームＳ１およびストリームＳ２の結果セットは、ＣＱＬ ＵＮＩＯＮ ＡＬＬサブクエリを適用してストリームＳ１およびストリームＳ２の結果セットを結合することによって、同種スキーマに基づいて結合データストリームを生成するように結合されてもよい。結合データストリームが生成され得る態様が、以下の非限定的な例を用いて説明され得る。

一例として、第１の入力データストリームＳ１が以下のイベントおよび関連するタイムスタンプを受取るものとする。

…
(<timestamp 1000>, <C1 1, C2 5>)
(<timestamp 2000>, <C1 1,C2 10>)
(<timestamp 3000>, <C1 1 C2 15>)
…
同様に、第２の入力データストリームＳ２が以下のイベントおよび関連するタイムスタンプを受取るものとする。

…
(<timestamp 1000>, <C1 1, C3 5>)
(<timestamp 2000>, <C1 1,C3 10>)
(<timestamp 3000>, <C1 1 C3 15>)
…
上述のストリームＳ１およびストリームＳ２の結果セットを結合して、以下に示されるような結合データストリームを生成してもよい。一例においては、結合データストリームは、上述のような同種スキーマに基づいて、ＵＮＩＯＮ ＡＬＬサブクエリにおけるＳＥＬＥＣＴステートメントを用いて結合され得るストリームＳ１およびストリームＳ２の結果セットを含む。一例においては、結合データストリームは、以下の同種スキーマ（＄ｓｔｒｅａｍＮａｍｅ，ｃ１，Ｓ１．ｃ２，Ｓ２，ｃ３）によって識別され、以下のイベントおよび関連するタイムスタンプを含んでもよい。

…
(<timestamp 1000>, <S1, C1 1, C2 5, NULL>)
(<timestamp 1000>, <S2, C1 1, C2 NULL, C3 5>)
(<timestamp 2000>, <S1, C1 1, C2 10, C3 NULL>)
(<timestamp 2000>, <S2, C1 1, C2 NULL, C3 10>)
(<timestamp 3000>, <S1, C1 1, C2 1, C3 NULL>)
(<timestamp 3000>, <S2, C1 1, C2 NULL, C3 15>)
…
図５および図６は、この明細書中に記載される、多重入力データストリームにわたるパターンの検出を実現するためのそれぞれのプロセス５００および６００を示す例示的なフロー図である。これらのプロセス５００および６００は論理的なフロー図として示され、それらの各々の動作は、ハードウェア、コンピュータ命令またはそれらの組合せで実現することができる一連の動作を表わしている。コンピュータ命令のコンテキストにおいては、動作は、１つ以上のコンピュータ読取可能記憶媒体上に格納されたコンピュータ実行可能命令を表わす。これらコンピュータ実行可能命令は、１つ以上のプロセッサによって実行されたときに列挙された動作を実行する。一般に、コンピュータ実行可能命令は、特定の機能を実行するかまたは特定のデータタイプを実現するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。動作が記載されている順序は、限定するものとして解釈されるよう意図されるものではなく、記載される動作の番号はいずれも如何なる順序で組合せされてもよく、および／または並行してプロセスを実現してもよい。

加えて、プロセスのうちいくつか、いずれかまたはすべてが、実行可能命令を用いて構成された１つ以上のコンピュータシステムの制御下で実行されてもよく、１つ以上のプロセッサ上で、ハードウェアによって、またはそれらの組合せによって、集合的に実行されるコード（たとえば、実行可能命令、１つ以上のコンピュータプログラムまたは１つ以上のアプリケーション）として実現されてもよい。上述のように、コードは、たとえば、１つ以上のプロセッサによって実行可能な複数の命令を含むコンピュータプログラムの形式で、コンピュータ読取可能記憶媒体に格納されてもよい。コンピュータ読取可能記憶媒体は非一時的であってもよい。

図５は、本開示の一実施形態に従って、多重入力データストリームにわたってパターンを検出するためのプロセスを示す高レベルフローチャートである。いくつかの例においては、少なくとも図１（など）に示される（たとえば、少なくとも入力データストリームモジュール１１６、ダイナミックデータタイプ生成モジュール１１８、結合データストリーム生成モジュール１２０、またはパターン検出モジュール１２２を利用する）１つ以上のサービスプロバイダコンピュータ１０６は、図５のプロセス５００を実行し得る。プロセス５００は、第１の入力データストリームおよび第２の入力データストリームを識別するステップおよび／または受取るステップを含め、ステップ５０２から開始されてもよい。

５０４において、プロセス５００は、第１の入力データストリームおよび第２の入力データストリームを表現するために同種スキーマを生成するステップを含み得る。同種スキーマが生成され得るプロセスが図６において詳細に説明される。

５０６において、プロセス５００は、第１の入力データストリームと第２の入力データストリームとを結合して、同種スキーマに基づく結合データストリームを生成するステップを含み得る。一実施形態においては、結合データストリームを生成するステップは、第１の入力データストリームから（第１のＣＱＬ ＳＥＬＥＣＴステートメントを介して）タプルの第１のセットを選択するステップと、第２の入力ストリームから（第１のＣＱＬ ＳＥＬＥＣＴステートメントを介して）タプルの第２のセットを選択するステップと、タプルの第１のセットおよびタプルの第２のセットにわたってサブクエリ（たとえば、ＵＮＩＯＮ ａｌｌサブクエリ）を処理して、結合データストリームを生成するステップとを含み得る。上述のとおり、同種スキーマを生成することにより、ＵＮＩＯＮ ＡＬＬサブクエリ内の各々のＣＱＬ ＳＥＬＥＣＴステートメントが、結果セットにおける同数のフィールドおよび類似のデータタイプを有することが可能になる。したがって、ストリームＳ１およびストリームＳ２の結果セットは、結合データストリームを生成するために、同種スキーマに基づいてＵＮＩＯＮ ＡＬＬサブクエリにおけるＳＥＬＥＣＴステートメントを用いて結合されてもよい。

５０８において、プロセス５００は、結合データストリームにわたって連続クエリ（たとえばＣＱＬクエリ）を処理してパターンを識別するステップを含み得る。一実施形態においては、ＵＮＩＯＮ ＡＬＬサブクエリの実行に基づいて生成された結合データストリームは、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節への入力として供給されてもよい。図３において説明されたように、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ分節を用いて、結合データストリームにわたってＣＱＬクエリを処理して、結合データストリームにおけるパターンを検出してもよい。

図６は、本開示の一実施形態に従って、同種スキーマを生成するためのプロセスを示す高レベルのフローチャートである。一実施形態においては、プロセス６００は、図５において説明されたプロセス５０４の実行をより詳細に説明する。

６０２において、プロセス６００は、第１の入力データストリームの第１の属性を識別するステップを含み得る。

６０４において、プロセスは、第２の入力データストリームの第２の属性を識別するステップを含み得る。一実施形態においては、第１の属性は、第２の入力データストリーム中に存在しない属性として識別されてもよく、第２の属性は、第１の入力データストリーム中に存在しない属性として識別されてもよい。

６０６において、プロセス６００は、第１の入力データストリームの第１の属性を表現するために第１のダイナミックデータタイプを生成するステップを含み得る。６０８において、プロセス６００は、第２の入力データストリームの第２の属性を表現するために第２のダイナミックデータタイプを生成するステップを含み得る。

６１０において、プロセス６００は共通属性を識別するステップを含み得る。一実施形態においては、共通属性は、第１の入力データストリームおよび第２の入力データストリーム中に存在する属性として識別されてもよい。

６１２において、プロセス６００は、同種スキーマを生成するステップを含み得る。一実施形態においては、図２に詳細に示されるように、同種スキーマは、第１の入力データストリームおよび第２の入力データストリームの１つ以上の属性の表現を含み得る。この表現は、少なくとも、共通属性、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプを含む。

図７は、本開示の実施形態を援用し得るイベント処理システム７００を示す簡略化された高レベル図である。イベント処理方式７００は、１つ以上のイベントソース（７０４、７０６、７０８）、イベントストリームを処理するための環境を提供するように構成されるイベント処理サーバ（event processing server：ＥＰＳ）７０２、ならびに１つ以上のイベントシンク（７１０および７１２）を含み得る。イベントソースは、ＥＰＳ７０２によって受取られるイベントストリームを生成する。ＥＰＳ７０２は、１つ以上のイベントソースから１つ以上のイベントストリームを受取ってもよい。たとえば、図７に示されるように、ＥＰＳ７０２は、イベントソース７０４から入力イベントストリーム７１４を受取り、イベントソース７０６から第２の入力イベントストリーム７１６を受取り、イベントソース７０８から第３のイベント７１８を受取る。１つ以上のイベント処理アプリケーション（７２０、７２２および７２４）は、ＥＰＳ７０２上でデプロイされ、ＥＰＳ７０２によって実行されてもよい。ＥＰＳ７０２によって実行されるイベント処理アプリケーションは、１つ以上の入力イベントストリームに従い、１つ以上のイベントを注目すべきイベントとして入力イベントストリームから選択する処理ロジックに基づいて１つ以上のイベントストリームを介して受取られたイベントを処理するように構成され得る。次いで、注目すべきイベントは、１つ以上の出力イベントストリームの形式で１つ以上のイベントシンク（７１０，７１２）に送信されてもよい。たとえば、図７においては、ＥＰＳ７０２は、イベントストリーム７２６をイベントシンク７１０に出力し、第２の出力イベントストリーム７２８をイベントシンク７１２に出力する。いくつかの実施形態においては、イベントソース、イベント処理アプリケーションおよびイベントシンクは、互いの構成要素に変化をもたらすことなく、これらの構成要素のうちのいずれかを追加するかまたは削除することができるように分離される。

一実施形態において、ＥＰＳ７０２を、サービスを共有するEquinox OSGiをベースとするもののような軽量Ｊａｖａ（登録商標）アプリケーションコンテナを含むＪａｖａサーバとして実現してもよい。いくつかの実施形態において、ＥＰＳ７０２は、たとえばJRockit Real Timeを用いてイベント処理の超高スループットおよびマイクロ秒レイテンシをサポートし得る。ＥＰＳ７０２はまた、イベント処理アプリケーションを開発するためのツール（たとえばOracle CEP VisualizerおよびOracle CEP IDE）を含む開発プラットフォーム（たとえば完全なリアルタイムエンドツーエンドＪａｖａイベントドリブンアーキテクチャ（Event-Driven Architecture）（ＥＤＡ）開発プラットフォーム）を提供し得る。

イベント処理アプリケーションは、１つ以上の入力イベントストリームに従い、この１つ以上の入力イベントストリームから注目すべき１つ以上のイベントを選択するためにロジック（たとえばクエリ）を実行し、選択した注目すべきイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントソースに出力するように構成される。図７は、このようなイベント処理アプリケーション７２０のためのドリルダウンを提供する。図７に示されるように、イベント処理アプリケーション７２０は、入力イベントストリーム７１８に従い、入力イベントストリーム７１８から１つ以上の注目すべきイベントを選択するためのロジックを含むクエリを、ＣＱＬエンジン／ＣＱサービス２００を介して実行し、選択された注目すべきイベントを出力イベントストリーム７２８を介してイベントシンク７１２に出力するように構成される。イベントソースの例は、アダプタ（たとえばJMS、HTTP、およびファイル)、チャネル、プロセッサ、テーブル、キャッシュ等を含むがこれらに限定されない。イベントシンクの例は、アダプタ（たとえばJMS、HTTP、およびファイル）、チャネル、プロセッサ、キャッシュなどを含むがこれらに限定されない。

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

その性質上無制限なので、１つのイベントストリームを介して受信されるデータの量は通常非常に多い。結果として、クエリを目的としてすべてのデータを格納またはアーカイブすることは、通常実用的でなく望ましくない。イベントストリームを処理するには、イベントをＥＰＳ７０２が受信したときに、受信したイベントデータをすべて格納することなく、イベントをリアルタイムで処理することが必要である。したがって、ＥＰＳ７０２は、ＥＰＳ７０２がイベントを受信したときに、受信したイベントをすべて格納することなく、イベントを処理できるようにする、特別なクエリ機構を提供する。

イベントドリブンのアプリケーションはルールドリブンであり、これらルールは、入力ストリームを処理するのに使用される連続クエリの形態で表わしてもよい。連続クエリは、クエリ処理の結果として注目すべきイベントおよび出力としてどんなイベントが選択されるべきであるかを含め、受信したイベントに対して実行すべき処理を特定する命令（たとえばビジネスロジック）を含み得る。連続クエリは、データ記憶装置まで持続させて、イベントの入力ストリームの処理およびイベントの出力ストリームの生成のために使用してもよい。連続クエリは、典型的には、発見すべきフィルタリングおよび集約関数を実行し入力イベントストリームから注目すべきイベントを抽出してもよい。結果として、出力イベントストリームにおけるアウトバウンドのイベントの数は通常、イベントを選択する元になる入力イベントストリームにおけるイベントの数よりも遥かに少ない。

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

連続クエリは異なる言語を用いてプログラムしてもよい。ある実施形態において、連続クエリは、Oracle社が提供するＣＱＬを用いて構成されOracle社の複合イベント処理（Complex Events Processing）（ＣＥＰ）という製品によって使用されてもよい。Oracle社のＣＱＬは、イベントストリームに対して実行することができるクエリ（ＣＱＬクエリと呼ばれる）をプログラムするのに使用できる宣言型言語である。ある実施形態において、ＣＱＬは、ストリーミングイベントデータの処理をサポートする構成が追加されたＳＱＬに基づく。

一実施形態において、イベント処理アプリケーションは、以下の種類の構成要素で構成されてもよい。

（１）入力および出力ストリームならびにリレーションソースおよびシンクに直接インターフェイスする１つ以上のアダプタ。アダプタは、入力および出力ストリームプロトコルを解釈するように構成され、イベントデータを、アプリケーションプロセッサがクエリできる標準化された形態に変換する役割を担う。アダプタは、標準化されたイベントデータを、チャネルまたは出力ストリームおよびリレーションシンクに転送してもよい。イベントアダプタを、さまざまなデータソースおよびシンクに対して定めてもよい。

（２）イベント処理のエンドポイントとして作用する１つ以上のチャネル。特に、チャネルは、イベント処理エージェントがイベントデータに対して機能を発揮できるようになるまでイベントデータをキューに保管する役割を担う。

（３）１つ以上のアプリケーションプロセッサ（またはイベント処理エージェント）は、チャネルからの標準化されたイベントデータを消費（consume）し、これをクエリを用いて処理することにより、注目すべきイベントを選択し、選択した注目すべきイベントを出力チャネルに転送（またはコピー）するように構成される。

（４）１つ以上のビーン（bean）は、出力チャネルをリッスンするように構成され、新たなイベントが出力チャネルに挿入されたことによってトリガされる。いくつかの実施形態において、このユーザコードは、昔からある単なるＪａｖａオブジェクト（plain-old-Java-object）（ＰＯＪＯ）である。ユーザアプリケーションは、ＪＭＳ、ウェブサービス、ファイルライター等の一組の外部サービスを利用して、生成されたイベントを外部イベントシンクに転送することができる。

（５）イベントビーンは、出力チャネルをリッスンするように登録されてもよく、出力チャネルに新しいイベントを挿入することによってトリガされる。いくつかの実施形態においては、このユーザコードはオラクルＣＥＰイベントビーンＡＰＩを用いて、このビーンをオラクルＣＥＰによって管理することができるようにしてもよい。

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

いくつかの実施形態において、イベント処理アプリケーションに対し、イベント処理アプリケーションのさまざまな構成要素を説明しどのようにして構成要素同士が接続されるかを説明しアプリケーションによって処理されるイベントタイプを説明するアセンブリファイルを与えてもよい。イベントを選択するための連続クエリまたはビジネスロジックを指定するために別々のファイルを与えてもよい。

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

図７に示される構成要素のうちの１つ以上は、ソフトウェア、ハードウェア、またはその組合せにおいて実現し得る。いくつかの実施形態において、ソフトウェアは、メモリ（たとえば非一時的なコンピュータ読取可能な媒体）に、メモリ素子に、または何等かのその他の物理メモリに格納されてもよく、１つ以上の処理部（たとえば１つ以上のプロセッサ、１つ以上のプロセッサコア、２つ以上のＧＰＵなど）によって実行されてもよい。

図のいくつかに示されるシステムは、さまざまな構成で設けられてもよい。いくつかの実施形態においては、システムは、当該システムの１つ以上の構成要素がクラウドコンピューティングシステムにおける１つ以上のネットワークを介して分散されている分散型システムとして構成されてもよい。

図８は、いくつかの実施形態のうちの１つの実施形態を実現するための分散型システム８００の簡略図を示す。図示される実施形態においては、分散型システム８００は、１つ以上のネットワーク８１０を介して、ウェブブラウザ、プロプライエタリクライアント（たとえばオラクルフォーム）などのクライアントアプリケーションを実行して動作させるように構成される１つ以上のクライアントコンピューティング装置８０２、８０４、８０６および８０８を含む。サーバ８１２は、ネットワーク８１０を介してリモートクライアントコンピューティング装置８０２、８０４、８０６および８０８と通信可能に結合されてもよい。

さまざまな実施形態においては、サーバ８１２は、システムの構成要素のうち１つ以上によって提供される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。サービスまたはソフトウェアアプリケーションは非仮想環境および仮想環境を含み得る。仮想環境は、２次元または三次元（３Ｄ）表現、ページベースの論理的環境などであろうとなかろうと、仮想イベント、トレードショー、シミュレータ、クラスルーム、購買商品取引および企業活動のために用いられるものを含み得る。いくつかの実施形態においては、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、またはソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）モデルのもとで、クライアントコンピューティング装置８０２，８０４，８０６および／または８０８のユーザに供給されてもよい。そして、クライアントコンピューティング装置８０２，８０４，８０６および／または８０８を動作させるユーザは、１つ以上のクライアントアプリケーションを利用して、サーバ８１２と相互作用して、これらの構成要素によって提供されるサービスを利用し得る。

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

クライアントコンピューティング装置８０２，８０４，８０６および／または８０８は、手持ち式携帯機器（たとえばｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、計算タブレット、パーソナルデジタルアシスタント（personal digital assistant：ＰＤＡ））またはウェアラブル装置（たとえばグーグルグラス（登録商標）ヘッドマウントディスプレイ）であってもよく、当該装置は、マイクロソフト・ウィンドウズ・モバイル（登録商標）などのソフトウェアを実行し、および／または、ｉＯＳ、ウィンドウズ・フォン、アンドロイド、ブラックベリー１０、パームＯＳなどのさまざまなモバイルオペレーティングシステムを実行し、インターネット、ｅメール、ショート・メッセージ・サービス（short message service：ＳＭＳ）、ブラックベリー（登録商標）、または使用可能な他の通信プロトコルである。クライアントコンピューティング装置は、汎用パーソナルコンピュータであってもよく、当該汎用パーソナルコンピュータは、一例として、マイクロソフトウィンドウズ（登録商標）、アップルマッキントッシュ（登録商標）および／またはリナックス（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む。クライアントコンピューティング装置は、ワークステーションコンピュータであってもよく、当該ワークステーションコンピュータは、たとえばＧｏｏｇｌｅ Ｃｈｒｏｍｅ ＯＳなどのさまざまなＧＮＵ／リナックスオペレーティングシステムを含むがこれらに限定されるものではないさまざまな市販のＵＮＩＸ（登録商標）またはＵＮＩＸライクオペレーティングシステムのうちのいずれかを実行する。代替的に、またはさらに、クライアントコンピューティング装置８０２，８０４，８０６および８０８は、シン・クライアントコンピュータ、インターネットにより可能なゲームシステム（たとえばキネクト（登録商標）ジェスチャ入力装置を備えるかまたは備えないマイクロソフトＸボックスゲーム機）、および／または、ネットワーク８１０を介して通信が可能なパーソナルメッセージング装置などのその他の電子装置であってもよい。

例示的な分散システム８００は、４個のクライアントコンピューティング装置を有するように示されているが、任意の数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置が、サーバ８１２と相互作用してもよい。

分散システム８００におけるネットワーク８１０は、さまざまな市販のプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者になじみのある任意のタイプのネットワークであってもよく、当該プロトコルは、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、アップルトークなどを含むが、これらに限定されるものではない。単に一例として、ネットワーク８１０は、イーサネット（登録商標）、トークンリングなどに基づくものなどのローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク８１０は、広域ネットワークおよびインターネットであってもよい。ネットワーク８１０は、仮想ネットワークを含んでいてもよく、当該仮想ネットワークは、仮想プライベートネットワーク（virtual private network：ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば米国電気電子学会（Institute of Electrical and Electronics：ＩＥＥＥ）８０２．１１の一連のプロトコル、ブルートゥース（登録商標）および／またはその他の無線プロトコルのうちのいずれかのもとで動作するネットワーク）、および／またはこれらの任意の組合せ、および／または他のネットワークを含むが、これらに限定されるものではない。

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

サーバ８１２は、上記のもののうちのいずれか、および、任意の市販のサーバオペレーティングシステムを含むオペレーティングシステムを実行し得る。また、サーバ８１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（共通ゲートウェイインターフェース）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含むさまざまなさらなるサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行し得る。例示的なデータベースサーバは、オラクル社、マイクロソフト社、サイベース社、ＩＢＭ社（International Business Machines）などから市販されているものを含むが、これらに限定されるものではない。

いくつかの実現例では、サーバ８１２は、クライアントコンピューティング装置８０２，８０４，８０６および８０８のユーザから受信されたデータフィードおよび／またはイベント更新を分析および統合するための１つ以上のアプリケーションを含み得る。一例として、データフィードおよび／またはイベント更新は、１つ以上の第三者情報源および連続的なデータストリームから受信されるツイッター（登録商標）フィード、フェースブック（登録商標）更新またはリアルタイム更新を含み得るが、これらに限定されるものではなく、センサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリングなどに関連するリアルタイムイベントを含み得る。また、サーバ８１２は、クライアントコンピューティング装置８０２，８０４，８０６および８０８の１つ以上の表示装置を介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含み得る。

また、分散システム８００は、１つ以上のデータベース８１４および８１６を含み得る。データベース８１４および８１６は、さまざまな場所に存在し得る。一例として、データベース８１４および８１６の１つ以上は、サーバ８１２にローカルな（および／または存在する）非一時的な記憶媒体に存在していてもよい。代替的に、データベース８１４および８１６は、サーバ８１２から遠く離れていて、ネットワークベースまたは専用の接続を介してサーバ８１２と通信してもよい。一組の実施形態においては、データベース８１４および８１６は、記憶領域ネットワーク（storage-area network：ＳＡＮ）に存在していてもよい。同様に、サーバ８１２に起因する機能を実行するための任意の必要なファイルが、サーバ８１２上にローカルに、および／または、リモートで適宜格納されていてもよい。一組の実施形態においては、データベース８１４および８１６は、ＳＱＬフォーマットコマンドに応答してデータを格納、更新および検索するように適合された、オラクル社によって提供されるデータベースなどのリレーショナルデータベースを含み得る。

図９は、本開示の実施形態に係る、実施形態のシステムの１つ以上の構成要素によって提供されるサービスをクラウドサービスとして供給することができるシステム環境９００の１つ以上の構成要素の簡略化されたブロック図である。示されている実施形態においては、システム環境９００は、クラウドサービスを提供するクラウドインフラストラクチャシステム９０２と相互作用するようにユーザによって使用され得る１つ以上のクライアントコンピューティング装置９０４，９０６および９０８を含む。クライアントコンピューティング装置は、クラウドインフラストラクチャシステム９０２によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム９０２と相互作用するようにクライアントコンピューティング装置のユーザによって使用され得る、ウェブブラウザ、専有のクライアントアプリケーション（たとえばオラクルフォームズ）または他のアプリケーションなどのクライアントアプリケーションを動作させるように構成され得る。

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

クライアントコンピューティング装置９０４，９０６および９０８は、８０２，８０４，８０６および８０８について上記したものと類似の装置であってもよい。

例示的なシステム環境９００は３個のクライアントコンピューティング装置を有するように示されているが、任意の数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置が、クラウドインフラストラクチャシステム９０２と相互作用してもよい。

ネットワーク９１０は、クライアント９０４，９０６および９０８とクラウドインフラストラクチャシステム９０２との間のデータの通信およびやりとりを容易にし得る。各々のネットワークは、ネットワーク８１０について上記したものを含むさまざまな市販のプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者になじみのある任意のタイプのネットワークであってもよい。

クラウドインフラストラクチャシステム９０２は、サーバ８１２について上記したものを含み得る１つ以上のコンピュータおよび／またはサーバを備え得る。

特定の実施形態においては、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータ記憶およびバックアップソリューション、ウェブベースのｅメールサービス、ホスト型オフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理技術サポートサービスなどの、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用可能な多数のサービスを含み得る。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリング可能である。クラウドインフラストラクチャシステムによって提供されるサービスの具体的なインスタンス化は、本明細書では「サービスインスタンス」と称される。一般に、インターネットなどの通信ネットワークを介してクラウドサービスプロバイダのシステムからユーザが利用可能な任意のサービスは、「クラウドサービス」と称される。通常、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムがアプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドで当該アプリケーションを注文および使用してもよい。

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

特定の実施形態においては、クラウドインフラストラクチャシステム９０２は、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルな、信頼性のある、高可用性の、安全な態様で顧客に配信される一連のアプリケーション、ミドルウェアおよびデータベースサービス提供品を含み得る。このようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクルパブリッククラウドである。

「ビッグデータ（Big data）」は、多くのレベルで、かつさまざまなスケールでインフラストラクチャシステムによってホストおよび／または処理されてもよい。大量のデータを視覚化し、トレンドを検出し、および／または、データと相互作用させるために、分析者および研究者は極めて大きいデータ集合を格納し処理することができる。平行にリンクされた何十、何百または何千ものプロセッサがこのようなデータに対して作用可能であり、これにより、このようなデータを表示し得るか、または、データに対する外力をシミュレートし得るかもしくはそれが表しているものをシミュレートし得る。これらのデータ集合は、データベースにおいて編制されたデータ、もしくは構造化モデルに従ったデータ、および／または、非体系的なデータ（たとえば電子メール、画像、データブロブ（バイナリ大型オブジェクト）、ウェブページ、複雑なイベント処理）などの構造化されたデータを必要とする可能性がある。目標物に対してより多くの（またはより少数の）コンピューティングリソースを比較的迅速に集中させるために実施形態の能力を強化することにより、ビジネス、政府関係機関、研究組織、私人、同じ目的をもった個々人もしくは組織のグループ、または他のエンティティから、要求に基づいて大量のデータ集合上でタスクを実行するために、クラウドインフラストラクチャシステムより良好に利用可能となる。

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

いくつかの実施形態においては、クラウドインフラストラクチャシステム９０２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）カテゴリ、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）カテゴリ、インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリのもとで提供される１つ以上のサービスを含み得る。顧客は、サブスクリプションオーダーによって、クラウドインフラストラクチャシステム９０２によって提供される１つ以上のサービスを注文し得る。次いで、クラウドインフラストラクチャシステム９０２は、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を実行する。

いくつかの実施形態においては、クラウドインフラストラクチャシステム９０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含み得るが、これらに限定されるものではない。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリに分類されるクラウドサービスを提供するように構成され得る。たとえば、ＳａａＳプラットフォームは、一体化された開発およびデプロイメントプラットフォーム上で一連のオンデマンドアプリケーションを構築および配信するための機能を提供し得る。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。ＳａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムで実行されるアプリケーションを利用することができる。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。さまざまな異なるＳａａＳサービスが提供されてもよい。例としては、大規模組織のための販売実績管理、企業統合およびビジネスの柔軟性のためのソリューションを提供するサービスが挙げられるが、これらに限定されるものではない。

いくつかの実施形態においては、プラットフォームサービスは、ＰａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリに分類されるクラウドサービスを提供するように構成され得る。プラットフォームサービスの例としては、組織（オラクル社など）が既存のアプリケーションを共有の共通アーキテクチャ上で統合することを可能にするサービス、および、プラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する機能を挙げることができるが、これらに限定されるものではない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを取得することができる。プラットフォームサービスの例としては、オラクルＪａｖａクラウドサービス（Java Cloud Service：ＪＣＳ）、オラクルデータベースクラウドサービス（Database Cloud Service：ＤＢＣＳ）などが挙げられるが、これらに限定されるものではない。

ＰａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを利用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態においては、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービル（たとえばオラクルフージョンミドルウェアサービス）およびＪａｖａクラウドサービスを含み得る。一実施形態においては、データベースクラウドサービスは、組織がデータベースリソースをプールしてデータベースクラウドの形態でデータベース・アズ・ア・サービスを顧客に供給することを可能にする共有のサービスデプロイメントモデルをサポートし得る。ミドルウェアクラウドサービスは、クラウドインフラストラクチャシステムにおいてさまざまなビジネスアプリケーションを開発およびデプロイするために顧客にプラットフォームを提供し得て、Ｊａｖａクラウドサービスは、クラウドインフラストラクチャシステムにおいてＪａｖａアプリケーションをデプロイするために顧客にプラットフォームを提供し得る。

さまざまな異なるインフラストラクチャサービスは、クラウドインフラストラクチャシステムにおけるＩａａＳプラットフォームによって提供されてもよい。インフラストラクチャサービスは、記憶装置、ネットワークなどの基本的な計算リソース、ならびに、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のための他の基礎的な計算リソースの管理および制御を容易にする。

また、特定の実施形態においては、クラウドインフラストラクチャシステム９０２は、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース９３０を含み得る。一実施形態においては、インフラストラクチャリソース９３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するための、サーバ、記憶装置およびネットワーキングリソースなどのハードウェアの事前に一体化された最適な組合せを含み得る。

いくつかの実施形態においては、クラウドインフラストラクチャシステム９０２におけるリソースは、複数のユーザによって共有され、デマンドごとに動的に再割り振りされ得る。また、リソースは、異なる時間帯にユーザに割り振られ得る。たとえば、クラウドインフラストラクチャシステム９３０は、第１の時間帯におけるユーザの第１の組が規定の時間にわたってクラウドインフラストラクチャシステムのリソースを利用することを可能にし、次いで、異なる時間帯に位置するユーザの別の組への同一のリソースの再割り振りを可能にし、それによってリソースの利用を最大化することができる。

特定の実施形態においては、クラウドインフラストラクチャシステム９０２の異なる構成要素またはモジュール、および、クラウドインフラストラクチャシステム９０２によって提供されるサービス、によって共有されるいくつかの内部共有サービス９３２が提供され得る。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、インテグレーションサービス、企業リポジトリサービス、企業マネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性・バックアップおよび回復サービス、クラウドサポートを可能にするためのサービス、ｅメールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されるものではない。

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

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

例示的な動作９３４において、顧客は、クラウドインフラストラクチャシステム９０２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム９０２によって供給される１つ以上のサービスのサブスクリプションについてオーダーを行うことによって、クライアント装置９０４，９０６または９０８などのクライアント装置を用いてクラウドインフラストラクチャシステム９０２と相互作用し得る。特定の実施形態においては、顧客は、クラウドユーザインターフェース（User Interface：ＵＩ）、すなわちクラウドＵＩ９１２、クラウドＵＩ９１４および／またはクラウドＵＩ９１６にアクセスして、これらのＵＩを介してサブスクリプションオーダーを行い得る。顧客がオーダーを行ったことに応答してクラウドインフラストラクチャシステム９０２によって受信されたオーダー情報は、顧客および顧客がサブスクライブする予定のクラウドインフラストラクチャシステム９０２によって供給される１つ以上のサービスを特定する情報を含み得る。

オーダーが顧客によって行われた後、オーダー情報は、クラウドＵＩ９１２，９１４および／または９１６を介して受信される。

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

動作９３８において、オーダー情報は、オーダー管理モジュール９２０に転送される。いくつかの例では、オーダー管理モジュール９２０は、オーダーの確認および確認時のオーダーの予約などのオーダーに関連するビリングおよびアカウンティング機能を実行するように構成され得る。

動作９４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール９２２に通信される。オーダーオーケストレーションモジュール９２２は、顧客によって行われたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレートするためにオーダー情報を利用し得る。いくつかの例では、オーダーオーケストレーションモジュール９２２は、オーダープロビジョニングモジュール９２４のサービスを用いてサブスクライブされたサービスをサポートするためにリソースのプロビジョニングをオーケストレートし得る。

特定の実施形態においては、オーダーオーケストレーションモジュール９２２は、各々のオーダーに関連付けられるビジネスプロセスの管理を可能にし、ビジネス論理を適用してオーダーがプロビジョニングに進むべきか否かを判断する。動作９４２において、新たなサブスクリプションについてのオーダーを受信すると、オーダーオーケストレーションモジュール９２２は、リソースを割り振って当該サブスクリプションオーダーを満たすのに必要とされるそれらのリソースを構成するための要求をオーダープロビジョニングモジュール９２４に送る。オーダープロビジョニングモジュール９２４は、顧客によってオーダーされたサービスのためのリソースの割り振りを可能にする。オーダープロビジョニングモジュール９２４は、クラウドインフラストラクチャシステム９００によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間にあるレベルの抽象化を提供する。したがって、オーダーオーケストレーションモジュール９２２は、サービスおよびリソースが実際に実行中にプロビジョニングされるか、事前にプロビジョニングされて要求があったときに割振られる／割当てられるのみであるかなどの実装の詳細から分離させることができる。

動作９４４において、サービスおよびリソースがプロビジョニングされると、提供されたサービスの通知が、クラウドインフラストラクチャシステム９０２のオーダープロビジョニングモジュール９２４によってクライアント装置９０４，９０６および／または９０８上の顧客に送られ得る。

動作９４６において、顧客のサブスクリプションオーダーが、オーダー管理および監視モジュール９２６によって管理および追跡され得る。いくつかの例では、オーダー管理および監視モジュール９２６は、使用される記憶量、転送されるデータ量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間などのサブスクリプションオーダーにおけるサービスについての使用統計を収集するように構成され得る。

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

図１０は、本発明のさまざまな実施形態を実現することができる例示的なコンピュータシステム１０００を示す。システム１０００は、上記のコンピュータシステムのうちのいずれかを実現するために使用され得る。図に示されているように、コンピュータシステム１０００は、バスサブシステム１００２を介していくつかの周辺サブシステムと通信する処理ユニット１００４を含む。これらの周辺サブシステムは、処理加速ユニット１００６と、Ｉ／Ｏサブシステム１００８と、記憶サブシステム１０１８と、通信サブシステム１０２４とを含み得る。記憶サブシステム１０１８は、有形のコンピュータ読取可能な記憶媒体１０２２と、システムメモリ１０１０とを含む。

バスサブシステム１００２は、コンピュータシステム１０００のさまざまな構成要素およびサブシステムに、意図されたように互いに通信させるための機構を提供する。バスサブシステム１００２は、単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施形態は、複数のバスを利用してもよい。バスサブシステム１００２は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのうちのいずれかを使用するローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、ＩＥＥＥ Ｐ１３８６．１標準に合わせて製造されたメザニンバスとして実現可能な、業界標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、拡張ＩＳＡ（Enhanced ISA：ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（Video Electronics Standards Association：ＶＥＳＡ）ローカルバスおよび周辺機器相互接続（Peripheral Component Interconnect：ＰＣＩ）バスを含み得る。

１つ以上の集積回路（たとえば従来のマイクロプロセッサまたはマイクロコントローラ）として実現可能な処理ユニット１００４は、コンピュータシステム１０００の動作を制御する。処理ユニット１００４には、１つ以上のプロセッサが含まれ得る。これらのプロセッサは、単一コアまたはマルチコアプロセッサを含み得る。特定の実施形態においては、処理ユニット１００４は、各々の処理ユニットに含まれる単一またはマルチコアプロセッサを有する１つ以上の独立した処理ユニット１０３２および／または１０３４として実現されてもよい。また、他の実施形態においては、処理ユニット１００４は、２つのデュアルコアプロセッサを単一のチップに組み入れることによって形成されるクアッドコア処理ユニットとして実現されてもよい。

さまざまな実施形態においては、処理ユニット１００４は、プログラムコードに応答してさまざまなプログラムを実行し得て、同時に実行される複数のプログラムまたはプロセスを維持し得る。任意の所与の時点において、実行されるべきプログラムコードのうちのいくつかまたは全ては、プロセッサ１００４および／または記憶サブシステム１０１８に存在し得る。好適なプログラミングを通じて、プロセッサ１００４は、上記のさまざまな機能を提供し得る。また、コンピュータシステム１０００は、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、特殊用途プロセッサなどを含み得る処理加速ユニット１００６を含み得る。

Ｉ／Ｏサブシステム１００８は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含み得る。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティング装置、タッチパッドまたはタッチスクリーンを含み得て、これらは、音声コマンド認識システム、マイクロホンおよび他のタイプの入力装置とともに、ディスプレイ、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、オーディオ入力装置に組込まれている。ユーザインターフェイス入力装置は、たとえば、ジェスチャおよび話されたコマンドを用いてナチュラルユーザインターフェースを介してユーザがマイクロソフトＸｂｏｘ（登録商標）３６０ゲームコントローラなどの入力装置を制御して入力装置と相互作用することを可能にするマイクロソフトキネクト（登録商標）モーションセンサなどのモーション検知および／またはジェスチャ認識装置を含み得る。また、ユーザインターフェイス入力装置は、ユーザから眼球運動（たとえば撮影および／またはメニュー選択を行っている間の「まばたき」）を検出して、当該眼球ジェスチャを入力装置への入力として変換するグーグルグラス（登録商標）まばたき検出器などの眼球ジェスチャ認識装置を含み得る。また、ユーザインターフェイス入力装置は、ユーザが音声コマンドを介して音声認識システム（たとえばＳｉｒｉ（登録商標）ナビゲータ）と相互作用することを可能にする音声認識検知装置を含み得る。

また、ユーザインターフェイス入力装置は、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、およびスピーカなどのオーディオ／ビジュアル装置、デジタルカメラ、デジタルカムコーダ、携帯型メディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダ、および視線検出装置を含み得るが、これらに限定されるものではない。また、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影、磁気共鳴画像化、位置発光断層撮影、医療用超音波検査装置などの医療用画像化入力装置を含み得る。また、ユーザインターフェイス入力装置は、たとえばＭＩＤＩキーボード、デジタル楽器などのオーディオ入力装置を含み得る。

ユーザインターフェイス出力装置は、ディスプレイサブシステム、表示灯、またはオーディオ出力装置などの非視覚的ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）またはプラズマディスプレイを使用するものなどのフラットパネルディスプレイ、投影装置、タッチスクリーンなどであってもよい。一般に、「出力装置」という用語の使用は、コンピュータシステム１０００からの情報をユーザまたは他のコンピュータに出力するための全ての可能なタイプの装置および機構を含むよう意図されている。たとえば、ユーザインターフェイス出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、自動車のナビゲーションシステム、プロッタ、音声出力装置およびモデムなどの、テキスト、グラフィックスおよびオーディオ／ビデオ情報を視覚的に伝えるさまざまな表示装置を含み得るが、これらに限定されるものではない。

コンピュータシステム１０００は、現在のところシステムメモリ１０１０内に位置しているように示されているソフトウェア要素を備える記憶サブシステム１０１８を備え得る。システムメモリ１０１０は、処理ユニット１００４上でロード可能および実行可能なプログラム命令と、これらのプログラムの実行中に生成されるデータとを格納し得る。

コンピュータシステム１０００の構成およびタイプに応じて、システムメモリ１０１０は、揮発性（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）であってもよく、および／または、不揮発性（リードオンリメモリ（read-only memory：ＲＯＭ）、フラッシュメモリなど）であってもよい。一般に、ＲＡＭは、処理ユニット１００４がすぐにアクセス可能なデータおよび／またはプログラムモジュール、および／または、処理ユニット１００４によって現在動作および実行されているデータおよび／またはプログラムモジュールを収容する。いくつかの実現例では、システムメモリ１０１０は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）などの複数の異なるタイプのメモリを含み得る。いくつかの実現例では、始動中などにコンピュータシステム１０００内の要素間で情報を転送することを助ける基本ルーチンを含む基本入力／出力システム（basic input/output system：ＢＩＯＳ）が、一般にＲＯＭに格納され得る。一例としておよび非限定的に、システムメモリ１０１０は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）などを含み得るアプリケーションプログラム１０１２、プログラムデータ１０１４およびオペレーティングシステム１０１６も示す。一例として、オペレーティングシステム１０１６は、マイクロソフトウィンドウズ（登録商標）、アップルマッキントッシュ（登録商標）および／もしくはリナックスオペレーティングシステムのさまざまなバージョン、さまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸライクオペレーティングシステム（さまざまなＧＮＵ／リナックスオペレーティングシステム、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）ＯＳなどを含むが、これらに限定されるものではない）、ならびに／または、ｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド（登録商標）ＯＳ、ブラックベリー（登録商標）１０ＯＳおよびパーム（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含み得る。

また、記憶サブシステム１０１８は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能な記憶媒体を提供し得る。プロセッサによって実行されたときに上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）が記憶サブシステム１０１８に格納され得る。これらのソフトウェアモジュールまたは命令は、処理ユニット１００４によって実行され得る。また、記憶サブシステム１０１８は、本発明に従って使用されるデータを格納するためのリポジトリを提供し得る。

また、記憶サブシステム１０００は、コンピュータ読取可能な記憶媒体１０２２にさらに接続可能なコンピュータ読取可能な記憶媒体リーダ１０２０を含み得る。ともにおよび任意には、システムメモリ１０１０と組合せて、コンピュータ読取可能な記憶媒体１０２２は、コンピュータ読取可能な情報を一時的および／または永久に収容、格納、送信および検索するための記憶媒体に加えて、リモートの、ローカルの、固定されたおよび／または取外し可能な記憶装置を包括的に表わし得る。

また、コードまたはコードの一部を含むコンピュータ読取可能な記憶媒体１０２２は、当該技術分野において公知のまたは使用される任意の適切な媒体を含み得て、当該媒体は、情報の格納および／または送信のための任意の方法または技術において実現される揮発性および不揮発性の、取外し可能および取外し不可能な媒体などであるが、これらに限定されるものではない記憶媒体および通信媒体を含む。これは、ＲＡＭ、ＲＯＭ、電子的消去・プログラム可能ＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）、または他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または他の有形のコンピュータ読取可能な媒体などの有形の一時的なコンピュータ読取可能な記憶媒体を含み得る。また、これは、データ信号、データ送信などの無形の一時的なコンピュータ読取可能な媒体、または、所望の情報を送信するために使用可能でありかつ計算システム１１００によってアクセス可能なその他の媒体を含み得る。

一例として、コンピュータ読取可能な記憶媒体１０２２は、取外し不可能な不揮発性磁気媒体から読取るまたは当該媒体に書込むハードディスクドライブ、取外し可能な不揮発性磁気ディスクから読取るまたは当該ディスクに書込む磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤおよびブルーレイ（登録商標）ディスクまたは他の光学式媒体などの取外し可能な不揮発性光学ディスクから読取るまたは当該ディスクに書込む光学式ディスクドライブを含み得る。コンピュータ読取可能な記憶媒体１０２２は、ジップ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digital：ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得るが、これらに限定されるものではない。また、コンピュータ読取可能な記憶媒体１０２２は、フラッシュメモリベースのＳＳＤ、企業向けフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（solid-state drive：ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（magnetoresistive RAM：ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組合せを使用するハイブリッドＳＳＤを含み得る。ディスクドライブおよびそれらの関連のコンピュータ読取可能な媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールおよび他のデータをコンピュータシステム１０００に提供し得る。

通信サブシステム１０２４は、他のコンピュータシステムおよびネットワークとのインターフェイスを提供する。通信サブシステム１０２４は、他のシステムからデータを受信したり、コンピュータシステム１０００から他のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム１０２４は、コンピュータシステム１０００がインターネットを介して１つ以上の装置に接続することを可能にし得る。いくつかの実施形態においては、通信サブシステム１０２４は、（たとえば３Ｇ、４ＧまたはＥＤＧＥ（enhanced data rates for global evolution）などの携帯電話技術、高度データネットワーク技術を用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）トランシーバコンポーネント、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリ標準または他のモバイル通信技術またはそれらの任意の組合せ）、全地球測位システム（global positioning system：ＧＰＳ）レシーバコンポーネント、および／または、他のコンポーネントを含み得る。いくつかの実施形態においては、通信サブシステム１０２４は、無線インターフェイスに加えて、または無線インターフェイスの代わりに、有線ネットワーク接続（例えばイーサネット）を提供し得る。

また、いくつかの実施形態においては、通信サブシステム１０２４は、コンピュータシステム１０００を使用し得る１人以上のユーザを代表して、構造化されたおよび／または構造化されていないデータフィード１０２６、イベントストリーム１０２８、イベント更新１０３０などの形態で入力通信を受信し得る。

一例として、通信サブシステム１０２４は、ツイッター（登録商標）フィード、フェースブック（登録商標）更新、リッチ・サイト・サマリ（Rich Site Summary：ＲＳＳ）フィードなどのウェブフィードなどのデータフィード１０２６をリアルタイムでソーシャルメディアネットワークおよび／または他の通信サービスのユーザから受信し、および／または、１つ以上の第三者情報源からリアルタイム更新を受信するように構成され得る。

また、通信サブシステム１０２４は、連続的なデータストリームの形態でデータを受信するように構成され得て、当該データは、連続的である場合もあれば本質的に明確な端部をもたない状態で境界がない場合もあるリアルタイムイベントのイベントストリーム１０２８および／またはイベント更新１０３０を含み得る。連続的なデータを生成するアプリケーションの例としては、たとえばセンサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリングなどを含み得る。

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

コンピュータシステム１０００は、手持ち式携帯機器（たとえばｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）計算タブレット、ＰＤＡ）、ウェアラブル装置（たとえばグーグルグラス（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラックまたはその他のデータ処理システムを含むさまざまなタイプのうちの１つであってもよい。

コンピュータおよびネットワークの絶え間なく変化し続ける性質のために、図に示されているコンピュータシステム１０００の説明は、特定の例として意図されているに過ぎない。図に示されているシステムよりも多くのまたは少ない数の構成要素を有する多くの他の構成が可能である。たとえば、ハードウェア、ファームウェア、（アプレットを含む）ソフトウェア、または組合せにおいて、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素が実装されてもよい。さらに、ネットワーク入力／出力装置などの他の計算装置への接続が利用されてもよい。本明細書で提供される開示および教示に基づいて、当業者は、さまざまな実施形態を実現するための他の手段および／または方法を理解するであろう。言いかえれば、いくつかの実施形態においては、コンピュータシステム１０００の構成は、全体として、第１の入力データストリームおよび第２の入力データストリームを少なくとも含む複数の入力データストリームを受取るための手段と；第１の入力データストリームについての第１のダイナミックデータタイプを生成するための手段と；第２の入力データストリームについての第２のダイナミックデータタイプを生成するための手段と；第１の入力データストリームと第２の入力データストリームとを結合して、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプに少なくとも部分的に基づく結合データストリームを生成するための手段と；結合データストリームに関する連続クエリをコンピュータシステムによって処理してパターンを検出するための手段とを含み得る。

図１１は、本発明のさまざまな実施形態が実現され得る例示的なサービスプロバイダデバイスの簡略化されたブロック図を示す。サービスプロバイダデバイス１１００のブロックは、本発明の原理を実行するために、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアとの組合せで実現されてもよい。図１１に記載されるブロックが、上述のとおり本発明の原理を実現するために、サブブロックに組合わされ得るかまたは分割され得ることが当業者によって理解される。したがって、この明細書中における記載は、この明細書中に記載される機能ブロックのいずれかの実現可能な組合せまたは分割またはさらなる定義をサポートし得る。

図１１に示されるように、サービスプロバイダデバイス１１００は、入力データストリーム受取ユニット１１０１、第１のダイナミックデータタイプ生成ユニット１１０３、第２のダイナミックデータタイプ生成ユニット１１０５、結合データストリーム生成ユニット１１０７、およびパターン検出ユニット１１０９を含み得る。入力データストリーム受取ユニット１１０１は、第１の入力データストリームおよび第２の入力データストリームを少なくとも含む複数の入力データストリームを受取るように構成されてもよい。第１のダイナミックデータタイプ生成ユニット１１０３は、第１の入力データストリームについての第１のダイナミックデータタイプを生成するように構成されてもよい。第２のダイナミックデータタイプ生成ユニット１１０５は、第２の入力データストリームについての第２のダイナミックデータタイプを生成するように構成されてもよい。結合データストリーム生成ユニット１１０７は、第１の入力データストリームと第２の入力データストリームとを結合して、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプに少なくとも部分的に基づく結合データストリームを生成するように構成されてもよい。パターン検出ユニット１１０９は、結合データストリームに関する連続クエリを処理して、パターンを検出するように構成されてもよい。一実施形態においては、各々のユニットは、コンピュータプログラム命令を読出すことによって、対応するプロセスを実行するプロセッサとして実現されてもよい。

一実施形態においては、第１のダイナミックデータタイプ生成ユニット１１０３はさらに、第１の入力データストリームの第１の属性を、第２のデータストリーム中に存在しないものとして識別し、第１の属性についての第１のダイナミックデータタイプを生成するように構成されてもよい。

一実施形態においては、第１のダイナミックデータタイプは、第１の入力データストリームの第１の属性に対応する第１のデータ値を格納するように構成されてもよい。

一実施形態においては、第２のダイナミックデータタイプ生成ユニット１１０５はさらに、第２の入力データストリームの第２の属性を、第１のデータストリーム中に存在しないものとして識別し、第２の属性についての第２のダイナミックデータタイプを生成するように構成されてもよい。第２のダイナミックデータタイプは、第２の入力データストリームの第２の属性に対応する第２のデータ値を格納するように構成され得る。

一実施形態においては、サービスプロバイダデバイス１１００はさらに、共通属性識別ユニット１１１１および同種スキーマ生成ユニット１１１３を含み得る。共通属性識別ユニット１１１１は、共通属性を識別するように構成されてもよい。共通属性は、第１の入力データストリーム中に存在するものとして、かつ、第２の入力データストリーム中に存在するものとして識別され得る。同種スキーマ生成ユニット１１１３は、同種スキーマを生成するように構成されてもよい。同種スキーマは、第１の入力データストリームおよび第２の入力データストリームの１つ以上の属性の表現を含む。当該表現は、少なくとも共通属性、第１のダイナミックデータタイプおよび第２のダイナミックデータタイプを含む。

一実施形態においては、同種スキーマは、ストリーム名識別子属性、第１の入力データストリームに関連付けられた第１のタイムスタンプ属性、または第２の入力データストリームに関連付けられた第２のタイムスタンプ属性のうち少なくとも１つを含み得る。

一実施形態においては、結合データストリーム生成ユニット１１０７はさらに、同種スキーマによって識別される第１の入力データストリームからタプルの第１のセットを選択し、同種スキーマによって識別される第２の入力データストリームからタプルの第２のセットを選択し、結合データストリームを生成するためにタプルの第１のセットおよびタプルの第２のセットに関してサブクエリを処理するように構成されてもよい。

一実施形態においては、パターンは、結合データストリームの分析に少なくとも部分的に基づいて検出されてもよい。パターンは、第１の入力データストリームにおける第１のイベントと、後続する第２の入力データストリームにおける第２のイベントとを識別する。

図１１に記載されるブロックは、上述のとおり本発明の原理を実現するためにサブブロックに組合せされ得るかまたは分割され得る。たとえば、第１のダイナミックデータタイプ生成ユニット１１０３および第２のダイナミックデータタイプ生成ユニット１１０５は、ダイナミックデータタイプ生成ユニットとして一体化されてもよい。一体型ダイナミックデータタイプ生成ユニットはまた、共通属性識別ユニット１１１１および同種スキーマ生成ユニット１１１３を組込むことができる。

当業者であれば、サービスプロバイダデバイス１１００が、先の例示的な実施形態において記載されたサービスプロバイダコンピュータ１０６の例示的な実現例であり得ることを理解することができる。当業者であれば、また、サービスプロバイダデバイス１１００が、本発明の原則に従った動作またはその組合せのいずれをも実行するように必要に応じて変更され得ることを理解することができる。

上記の明細書では、本発明の局面は、その具体的な実施形態を参照して記載されているが、本発明はこれに限定されるものではないことを当業者は認識するであろう。上記の発明のさまざまな特徴および局面は、個々にまたは一緒に使用されてもよい。さらに、実施形態は、明細書のより広い精神および範囲から逸脱することなく、本明細書に記載されているものを越えたどのような環境およびアプリケーションでも利用可能である。したがって、明細書および図面は、限定的ではなく例示的であるものとみなされるべきである。

Claims (10)

1. コンピュータによって実行される方法であって、
   コンピュータ実行可能命令を用いて構成されるコンピュータシステムが、第１の入力データストリームおよび第２の入力データストリームを少なくとも含む複数の入力データストリームを受取るステップと、
   前記コンピュータシステムが、前記第１の入力データストリームの第１の属性を前記第２の入力データストリーム中に存在しないものとして識別するステップと、
   前記コンピュータシステムが、前記第１の入力データストリームの前記第１の属性についての第１のダイナミックデータタイプを生成するステップとを含み、
   前記第１のダイナミックデータタイプは、前記第１の入力データストリームの前記第１の属性に対応する第１のデータ値を格納するように構成され、
   前記方法は、さらに、
   前記コンピュータシステムが、前記第２の入力データストリームの第２の属性を前記第１の入力データストリーム中に存在しないものとして識別するステップと、
   前記コンピュータシステムが、前記第２の入力データストリームの前記第２の属性についての第２のダイナミックデータタイプを生成するステップとを含み、
   前記第２のダイナミックデータタイプは、前記第２の入力データストリームの前記第２の属性に対応する第２のデータ値を格納するように構成され、
   前記第１および第２のダイナミックデータタイプは、それぞれ前記第１および第２の入力データストリームの１つ以上の属性についての複合データタイプとして構成され、
   前記方法は、さらに、
   前記コンピュータシステムが、前記第１および第２の入力データストリームの共通属性を識別するステップと、
   前記コンピュータシステムが、前記共通属性と、前記第１および第２のダイナミックデータタイプとを含む同種スキーマを生成するステップと、
   前記コンピュータシステムが、前記同種スキーマに基づいて、前記第１の入力データストリームと前記第２の入力データストリームとを結合した結合データストリームを生成するステップと、
   前記コンピュータシステムが、前記結合データストリームに関する連続クエリを処理して、パターンを検出するステップとを含む、コンピュータによって実行される方法。
2. 前記同種スキーマは、ストリーム名識別子属性、前記第１の入力データストリームに関連付けられた第１のタイムスタンプ属性、または前記第２の入力データストリームに関連付けられた第２のタイムスタンプ属性のうち少なくとも１つを含む、請求項１に記載のコンピュータによって実行される方法。
3. 前記結合データストリームを生成するステップは、
   前記同種スキーマによって識別される前記第１の入力データストリームからタプルの第１のセットを選択するステップと、
   前記同種スキーマによって識別される前記第２の入力データストリームからタプルの第２のセットを選択するステップと、
   前記タプルの第１のセットと前記タプルの第２のセットとに関するサブクエリを処理して、前記結合データストリームを生成するステップとを含む、請求項１または２に記載のコンピュータによって実行される方法。
4. 前記パターンは、前記結合データストリームの分析に少なくとも部分的に基づいて検出され、前記パターンは、前記第１の入力データストリームにおける第１のイベントと、後続する前記第２の入力データストリームにおける第２のイベントとを識別する、請求項１〜３のいずれか１項に記載のコンピュータによって実行される方法。
5. システムであって、
   複数の命令を格納するメモリと、
   前記メモリにアクセスするように構成された少なくとも１つのプロセッサとを含み、前記少なくとも１つのプロセッサは、
   第１の入力データストリームおよび第２の入力データストリームを識別する連続クエリを受取り、
   前記第１の入力データストリームの第１の属性を、前記第２の入力データストリーム中に存在しないものとして識別し、
   前記第１の入力データストリームの前記第１の属性についての第１のダイナミックデータタイプを識別し、
   前記第１のダイナミックデータタイプは、前記第１の入力データストリームの前記第１の属性に対応する第１のデータ値を格納するように構成され、
   前記少なくとも１つのプロセッサは、さらに、
   前記第２の入力データストリームの第２の属性を、前記第１の入力データストリーム中に存在しないものとして識別し、
   前記第２の入力データストリームの前記第２の属性についての第２のダイナミックデータタイプを識別し、
   前記第２のダイナミックデータタイプは、前記第２の入力データストリームの前記第２の属性に対応する第２のデータ値を格納するように構成され、
   前記第１および第２のダイナミックデータタイプは、それぞれ前記第１および第２の入力データストリームの１つ以上の属性についての複合データタイプとして構成され、
   前記少なくとも１つのプロセッサは、さらに、
   前記第１および第２の入力データストリームの共通属性を識別し、
   前記共通属性と、前記第１および第２のダイナミックデータタイプとを含む同種スキーマを生成し、
   前記同種スキーマに基づいて、前記第１の入力データストリームと前記第２の入力データストリームとを結合した結合データストリームを生成し、
   前記結合データストリームに関する前記連続クエリを実行してパターンを検出する、システム。
6. 前記同種スキーマは、ストリーム名識別子属性、前記第１の入力データストリームに関連付けられた第１のタイムスタンプ属性、または前記第２の入力データストリームに関連付けられた第２のタイムスタンプ属性のうち少なくとも１つを含む、請求項５に記載のシステム。
7. 前記少なくとも１つのプロセッサは、さらに、
   前記同種スキーマによって識別される前記第１の入力データストリームからタプルの第１のセットを選択し、
   前記同種スキーマによって識別される前記第２の入力データストリームからタプルの第２のセットを選択し、
   前記タプルの第１のセットおよび前記タプルの第２のセットに関するサブクエリを処理することによって、前記結合データストリームを生成する、請求項５または６に記載のシステム。
8. 前記パターンは、前記結合データストリームの分析に少なくとも部分的に基づいて検出され、前記パターンは、前記第１の入力データストリームにおける第１のイベントと、後続する前記第２の入力データストリームにおける第２のイベントとを識別する、請求項５〜７のいずれか１項に記載のシステム。
9. １つ以上のプロセッサによって実行可能なコンピュータ実行可能命令を含むコンピュータ読取可能プログラムであって、前記コンピュータ実行可能命令は、
   前記１つ以上のプロセッサに、第１の入力データストリームおよび第２の入力データストリームを少なくとも含む複数の入力データストリームを受取らせる命令と、
   前記１つ以上のプロセッサに、前記第１の入力データストリームの第１の属性を前記第２の入力データストリーム中に存在しないものとして識別させる命令と、
   前記１つ以上のプロセッサに、前記第１の入力データストリームの前記第１の属性についての第１のダイナミックデータタイプを生成させる命令とを含み、
   前記第１のダイナミックデータタイプは、前記第１の入力データストリームの前記第１の属性に対応する第１のデータ値を格納するように構成され、
   前記コンピュータ実行可能命令は、さらに、
   前記１つ以上のプロセッサに、前記第２の入力データストリームの第２の属性を前記第１の入力データストリーム中に存在しないものとして識別させる命令と、
   前記１つ以上のプロセッサに、前記第２の入力データストリームの前記第２の属性についての第２のダイナミックデータタイプを生成させる命令とを含み、
   前記第２のダイナミックデータタイプは、前記第２の入力データストリームの前記第２の属性に対応する第２のデータ値を格納するように構成され、
   前記第１および第２のダイナミックデータタイプは、それぞれ前記第１および第２の入力データストリームの１つ以上の属性についての複合データタイプとして構成され、
   前記コンピュータ実行可能命令は、さらに、
   前記１つ以上のプロセッサに、前記第１および第２の入力データストリームの共通属性を識別させる命令と、
   前記１つ以上のプロセッサに、前記共通属性と、前記第１および第２のダイナミックデータタイプとを含む同種スキーマを生成させる命令と、
   前記１つ以上のプロセッサに、前記同種スキーマに基づいて、前記第１の入力データストリームと前記第２の入力データストリームとを結合した結合データストリームを生成させる命令と、
   前記１つ以上のプロセッサに、前記結合データストリームに関する連続クエリを処理させてパターンを検出させる命令とを含む、コンピュータ読取可能プログラム。
10. １つ以上のプロセッサによって実行可能なコンピュータ実行可能命令を含むコンピュータ読取可能プログラムであって、前記コンピュータ実行可能命令は、前記１つ以上のプロセッサに、請求項１〜４のいずれか１項に記載の方法を実行させる、コンピュータ読取可能プログラム。

Images