(57)【要約】      （修正有）【課題】データのストリームを処理するための、改善された技術を提供する。【解決手段】イベント処理システム１００において、１つのイベントが時間ベースのウィンドウ内に留まる資格がある継続時間は、同一のイベントストリームを介して受信した異なるイベントごとに異なる。１つの入力イベントが時間ベースのウィンドウ内にある継続時間は、このイベントの１つ以上の属性の１つ以上の値の関数である。異なるイベントは異なる１つ以上の属性値を有することがあるので、異なるイベントがそのイベントストリームのための時間ベースのウィンドウ内にある時間の量は異なることがある。１つのイベントが時間ベースのウィンドウ内にある時間の量は、このイベントの１つ以上の属性によって制御することができる。【選択図】図１
2019061712.tif 000002
【特許請求の範囲】
【請求項１】
方法であって、
イベントストリームを介して受信した第１のイベントの第１の継続時間を計算装置によって決定することを含み、前記第１の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第１のイベントが留まる資格がある継続時間を示し、
前記イベントストリームを介して受信した第２のイベントの第２の継続時間を前記計算装置によって決定することを含み、前記第２の継続時間は、前記時間ベースのウィンドウ内に前記第２のイベントが留まる資格がある継続時間を示し、前記第２の継続時間は前記第１の継続時間と異なる、方法。
【請求項２】
前記第１の時間イベントが前記時間ベースのウィンドウ内に前記第１の継続時間留まった後に、前記第１のイベントを前記時間ベースのウィンドウから前記計算装置によって除去することと、
前記第２の時間イベントが前記時間ベースのウィンドウ内に前記第２の継続時間留まった後に、前記第２のイベントを前記時間ベースのウィンドウから前記計算装置によって除去することとをさらに含む、請求項１に記載の方法。
【請求項３】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と同一である、請求項１または２に記載の方法。
【請求項４】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と異なる、請求項１または２に記載の方法。
【請求項５】
前記第１の継続時間を決定することは、前記第１のイベントの１つ以上の属性の１つ以上の値に基づいて前記第１の継続時間を計算することを含み、
前記第２の継続時間を決定することは、前記第２のイベントの１つ以上の属性の１つ以上の値に基づいて前記第２の継続時間を計算することを含む、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
前記第１のイベントの第１の属性の値に基づいて前記第１のイベントのための第１の区画を決定することと、
前記第２のイベントの第１の属性の値に基づいて前記第２のイベントが前記第１の区画に属すると決定することとをさらに含み、
前記時間ベースのウィンドウは前記第１の区画のためのものである、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記第１のイベントに関連付けられた第１の時間と前記第１の継続時間とに基づいて前記第１のイベントの第１の満了時間を前記計算装置によって決定することと、
前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のイベントの第２の満了時間を前記計算装置によって決定することと、
前記第１の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第１のイベントを除去することと、
前記第２の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第２のイベントを除去することとをさらに含む、請求項１〜６のいずれか一項に記載の方法。
【請求項８】
計算装置であって、
メモリと、
一組の処理部とを備え、前記一組の処理部のうちの１つ以上の処理部は、
イベントストリームを介して受信した第１のイベントの第１の継続時間を決定するように適合され、前記第１の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第１のイベントが留まる資格がある継続時間を示し、
前記イベントストリームを介して受信した第２のイベントの第２の継続時間を決定するように適合され、前記第２の継続時間は、前記時間ベースのウィンドウ内に前記第２のイベントが留まる資格がある継続時間を示し、前記第２の継続時間は前記第１の継続時間と異なる、計算装置。
【請求項９】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１の時間イベントが前記時間ベースのウィンドウ内に前記第１の継続時間留まった後に、前記第１のイベントを前記時間ベースのウィンドウから除去するように適合され、
前記第２の時間イベントが前記時間ベースのウィンドウ内に前記第２の継続時間留まった後に、前記第２のイベントを前記時間ベースのウィンドウから除去するように適合される、請求項８に記載の計算装置。
【請求項１０】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と同一である、請求項８または９に記載の計算装置。
【請求項１１】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と異なる、請求項８または９に記載の計算装置。
【請求項１２】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１のイベントの１つ以上の属性の１つ以上の値に基づいて前記第１の継続時間を決定するように適合され、
前記第２のイベントの１つ以上の属性の１つ以上の値に基づいて前記第２の継続時間を決定するように適合される、請求項８〜１１のいずれか一項に記載の計算装置。
【請求項１３】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１のイベントの第１の属性の値に基づいて前記第１のイベントのための第１の区画を決定するように適合され、
前記第２のイベントの第１の属性の値に基づいて前記第２のイベントが前記第１の区画に属すると決定するように適合され、
前記時間ベースのウィンドウは前記第１の区画のためのものである、請求項８〜１２のいずれか一項に記載の計算装置。
【請求項１４】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１のイベントに関連付けられた第１の時間と前記第１の継続時間とに基づいて前記第１のイベントの第１の満了時間を決定するように適合され、
前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のイベントの第２の満了時間を決定するように適合され、
前記第１の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第１のイベントを除去するように適合され、
前記第２の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第２のイベントを除去するように適合される、請求項８〜１３のいずれか一項に記載の計算装置。
【請求項１５】
１つ以上の処理部によって実行可能な複数の命令を格納するコンピュータ読取可能なメモリであって、前記複数の命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、イベントストリームを介して受信した第１のイベントの第１の継続時間を決定させる命令を含み、前記第１の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第１のイベントが留まる資格がある継続時間を示し、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記イベントストリームを介して受信した第２のイベントの第２の継続時間を決定させる命令を含み、前記第２の継続時間は、前記時間ベースのウィンドウ内に前記第２のイベントが留まる資格がある継続時間を示し、前記第２の継続時間は前記第１の継続時間と異なる、コンピュータ読取可能なメモリ。
【請求項１６】
前記複数の命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１の時間イベントが前記時間ベースのウィンドウ内に前記第１の継続時間留まった後に、前記第１のイベントを前記時間ベースのウィンドウから除去させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２の時間イベントが前記時間ベースのウィンドウ内に前記第２の継続時間留まった後に、前記第２のイベントを前記時間ベースのウィンドウから除去させる命令とを含む、請求項１５に記載のコンピュータ読取可能なメモリ。
【請求項１７】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と同一である、請求項１５または１６に記載のコンピュータ読取可能なメモリ。
【請求項１８】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と異なる、請求項１５または１６に記載のコンピュータ読取可能なメモリ。
【請求項１９】
前記複数の命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のイベントの１つ以上の属性の１つ以上の値に基づいて前記第１の継続時間を決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２のイベントの１つ以上の属性の１つ以上の値に基づいて前記第２の継続時間を決定させる命令とを含む、請求項１５〜１８のいずれか一項に記載のコンピュータ読取可能なメモリ。
【請求項２０】
前記複数の命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のイベントの第１の属性の値に基づいて前記第１のイベントのための第１の区画を決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２のイベントの第１の属性の値に基づいて前記第２のイベントが前記第１の区画に属すると決定させる命令とを含み、
前記時間ベースのウィンドウは前記第１の区画のためのものである、請求項１５〜１９のいずれか一項に記載のコンピュータ読取可能なメモリ。
【請求項２１】
前記複数の命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のイベントに関連
付けられた第１の時間と前記第１の継続時間とに基づいて前記第１のイベントの第１の満了時間を決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のイベントの第２の満了時間を決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第１のイベントを除去させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第２のイベントを除去させる命令とを含む、請求項１５〜２０のいずれか一項に記載のコンピュータ読取可能なメモリ。
【請求項２２】
システムであって、
イベントストリームを介して受信した第１のイベントの第１の継続時間を決定するための手段を備え、前記第１の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第１のイベントが留まる資格がある継続時間を示し、
前記イベントストリームを介して受信した第２のイベントの第２の継続時間を決定するための手段を備え、前記第２の継続時間は、前記時間ベースのウィンドウ内に前記第２のイベントが留まる資格がある継続時間を示し、前記第２の継続時間は前記第１の継続時間と異なる、システム。
【請求項２３】
前記第１の時間イベントが前記時間ベースのウィンドウ内に前記第１の継続時間留まった後に、前記第１のイベントを前記時間ベースのウィンドウから除去するための手段と、
前記第２の時間イベントが前記時間ベースのウィンドウ内に前記第２の継続時間留まった後に、前記第２のイベントを前記時間ベースのウィンドウから除去するための手段とをさらに備える、請求項２２に記載のシステム。
【請求項２４】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と同一である、請求項２２または２３に記載のシステム。
【請求項２５】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と異なる、請求項２２または２３に記載のシステム。
【請求項２６】
前記第１の継続時間を決定するための手段は、前記第１のイベントの１つ以上の属性の１つ以上の値に基づいて前記第１の継続時間を計算するための手段を含み、
前記第２の継続時間を決定するための手段は、前記第２のイベントの１つ以上の属性の１つ以上の値に基づいて前記第２の継続時間を計算するための手段を含む、請求項２２〜２５のいずれか一項に記載のシステム。
【請求項２７】
前記第１のイベントの第１の属性の値に基づいて前記第１のイベントのための第１の区画を決定するための手段と、
前記第２のイベントの第１の属性の値に基づいて前記第２のイベントが前記第１の区画に属すると決定するための手段とをさらに備え、
前記時間ベースのウィンドウは前記第１の区画のためのものである、請求項２２〜２６のいずれか一項に記載のシステム。
【請求項２８】
前記第１のイベントに関連付けられた第１の時間と前記第１の継続時間とに基づいて前
記第１のイベントの第１の満了時間を決定するための手段と、
前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のイベントの第２の満了時間を決定するための手段と、
前記第１の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第１のイベントを除去するための手段と、
前記第２の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第２のイベントを除去するための手段とをさらに備える、請求項２２〜２７のいずれか一項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本願は、２０１３年１月１５日に出願され「VARIABLE DURATION WINDOWS ON CONTINUOUS DATA STREAMS（連続データストリームに対する継続時間可変ウィンドウ）」と題された米国仮出願第６１／７５２，８５０号に基づく利益および優先権を主張する。本願はまた、米国仮出願第６１／７５２，８５０号に基づく優先権を主張する２０１３年３月１５日に出願され「VARIABLE DURATION WINDOWS ON CONTINUOUS DATA STREAMS」と題された米国非仮出願第１３／８３８，２５９号に基づく利益および優先権を主張する。出願第６１／７５２，８５０号および第１３／８３８，２５９号の内容全体をすべての目的のために本明細書に引用により援用する。
【背景技術】
【０００２】
背景
開示されている実施形態は、概してデータ処理システムに関し、より具体的には継続時間可変ウィンドウを用いて連続イベントストリームを処理するための技術に関する。
【０００３】
従来のデータベースシステムにおいて、データは、通常はテーブルの形態で１つ以上のデータベースに格納される。格納されたデータはその後、ＳＱＬ等のデータ管理言語を用いてクエリされ操作される。たとえば、ＳＱＬクエリは、データベースに格納されているデータのうちの関連データを識別するために定義し実行することができる。したがって、ＳＱＬクエリは、データベースに格納されている有限集合のデータに対して実行される。さらに、ＳＱＬクエリが実行されるとき、ＳＱＬは有限のデータ集合に対して一度実行されて有限の静的結果をもたらす。このように、データベースは、格納されている有限のデータ集合に対してクエリが実行されるよう最適に作成されている。
【０００４】
しかしながら、数多くの現代のアプリケーションおよびシステムは、データを、有限のデータ集合ではなく連続データまたはイベントストリームの形態で生成する。このようなアプリケーションの例は、センサデータアプリケーション、財務表示機、ネットワークパフォーマンス測定ツール（たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリング等を含むが、これらに限定されない。たとえば、温度センサを、温度測定値を発信するように構成することができる。このようなアプリケーションから、データストリームを処理することが可能な新たな種類のアプリケーションの必要性が生じた。
【０００５】
イベントストリームに基づくこれらの種類のアプリケーションの場合のデータの管理および処理は、時間を強く重視してデータ管理およびクエリ機能を構築することを含む。連続する無限のデータ集合に対する長時間のクエリ実行を含む、異なる種類のクエリ機構が必要である。現在イベントストリーム処理に適した製品一式を提供している販売業者はあるが、これら製品が提供するものは依然として、現代のイベント処理のニーズに対処するのに必要な処理の柔軟性に欠けている。
【発明の概要】
【課題を解決するための手段】
【０００６】
簡単な概要
本発明のある実施形態は、一般的にはデータ処理システムに関し、より具体的には継続時間可変ウィンドウを用いて連続イベントストリームを処理するための技術に関する。この技術は、たとえば、イベントデータストリームに対して機能する、コンピュータによっ
て実施される方法、イベントデータストリームを処理する計算機、システム、または装置、１つ以上の処理部によって実行可能な複数の命令を格納するコンピュータ読取可能なメモリなどを用いて実施される技術を含み得る。
【０００７】
ある実施形態において、１つのイベントが時間ベースのウィンドウ内に留まる資格がある継続時間は、同一のイベントストリームを介して受信した異なるイベントごとに異なり得る。たとえば、このイベントストリームを介して受信した第１の入力イベントの場合にこの第１のイベントが時間ベースの範囲ウィンドウ内に留まる資格がある継続時間が「Ｘ」で、同一のイベントストリームを介して受信した第２のイベントの場合にこの第２のイベントが時間ベースのウィンドウ内に留まる資格がある継続時間が「Ｙ」で、「Ｘ」が「Ｙ」と同じでないことがある。第１および第２のイベントは、関連付けられたタイムスタンプが同一または異なる場合がある。本発明の実施形態はしたがって、１つのイベントが時間ベースのウィンドウ内にある時間の量を制御できるようにする。
【０００８】
ある実施形態において、入力イベントが時間ベースのウィンドウ内にある継続時間は、このイベントの１つ以上の属性の１つ以上の値の関数である。イベントの種類が異なれば１つ以上の属性の値は異なり得るので、異なるイベントが時間ベースのウィンドウ内にある時間の量は異なり得る。したがって、１つのイベントが時間ベースのウィンドウ内にある時間の量は、このイベントの１つ以上の属性を介して制御することができる。
【０００９】
一実施形態において、複数のイベントがイベントストリームを介して計算装置によって受信されてもよい。たとえば、第１のイベントおよび第２のイベントがイベントストリームを介して受信されてもよい。第１のイベントに対して第１の継続時間を決定してもよく、第１の継続時間は、このイベントストリームに対して指定された時間ベースのウィンドウ内に第１のイベントが留まる資格がある継続時間を示す。第２のイベントに対して第２の継続時間を決定してもよく、第２の継続時間は、時間ベースのウィンドウ内に第２のイベントが留まる資格がある継続時間を示し、第２の継続時間は第１の継続時間と異なる。
【００１０】
ある実施形態において、第１および第２のイベントを、そのイベントストリームに対して指定された時間ベースのウィンドウに追加してもよい。第１のイベントは、時間ベースのウィンドウ内に第１の継続時間留まった後に、時間ベースのウィンドウから除去または削除される。第２のイベントは、時間ベースのウィンドウ内に第２の継続時間留まった後に、時間ベースのウィンドウから除去または削除される。このように、第１のイベントが時間ベースのウィンドウ内にある継続時間は、第２のイベントがこの時間ベースのウィンドウ内にある継続時間と異なり得る。
【００１１】
上記第１および第２のイベントの例の実施形態において、第１のイベントは関連付けられた第１の時間を有していてもよく、第２のイベントは関連付けられた第２の時間を有していてもよい。一例において、第１の時間と第２の時間は同一であってもよい。第２の例において、第１の時間は第２の時間と異なっていてもよい。
【００１２】
ある実施形態において、１つのイベントが時間ベースのウィンドウ内にある資格がある継続時間は、このイベントの１つ以上の属性の値に基づいていてもよい。
【００１３】
ある実施形態において、行‐時間範囲ウィンドウは、異なる区画であってもよい。１つのイベントが属する区画は、第１のイベントの属性の値に基づいていてもよい。１つのイベントが、１つの区画のための行‐時間範囲ウィンドウ内にある資格がある時間の量は、このイベントの１つ以上の属性の１つ以上の値に基づいていてもよい。したがって、特定の区画に属するイベントについては、異なるイベントは、この特定の区画のための行‐時間範囲ウィンドウ内に異なる継続時間留まる資格を有し得る。
【００１４】
ある実施形態において、第１のイベントに関連付けられた第１の時間と第１の継続時間とに基づいて、第１のイベントの第１の満了時間を計算してもよい。第２のイベントに関連付けられた第２の時間と第２の継続時間とに基づいて、第２のイベントの第２の満了時間を計算してもよい。第１のイベントは、第１の満了時間の到来時または到来後に、時間ベースのウィンドウから除去または削除される。同様に、第２のイベントは、第２の満了時間の到来時または到来後に、時間ベースのウィンドウから除去または削除されてもよい。
【００１５】
本開示の一局面に従い、計算装置が提供される。この計算装置は、計算装置がイベントストリームを介して受信した第１のイベントの第１の継続時間を決定するように構成された第１の決定部を含み、第１の継続時間は、イベントストリームに対して指定された時間ベースのウィンドウ内に第１のイベントが留まる資格がある継続時間を示す。計算装置は、計算装置がイベントストリームを介して受信した第２のイベントの第２の継続時間を決定するように構成された第２の決定部を含んでいてもよく、第２の継続時間は、時間ベースのウィンドウ内に第２のイベントが留まる資格がある継続時間を示す。第２の継続時間は第１の継続時間と異なっていてもよい。
【００１６】
ある実施形態において、計算装置はさらに、第１の時間イベントが時間ベースのウィンドウ内に第１の継続時間留まった後に第１のイベントを時間ベースのウィンドウから除去するように構成された第１の除去部と、第２の時間イベントが時間ベースのウィンドウ内に第２の継続時間留まった後に第２のイベントを時間ベースのウィンドウから除去するように構成された第２の除去部とを含む。
【００１７】
ある実施形態において、第１のイベントは関連付けられた第１の時間を有し、第２のイベントは関連付けられた第２の時間を有し、第１の時間は第２の時間と同一である。
【００１８】
ある実施形態において、第１のイベントは関連付けられた第１の時間を有し、第２のイベントは関連付けられた第２の時間を有し、第１の時間は第２の時間と異なる。
【００１９】
ある実施形態において、第１の継続時間を決定することは、第１のイベントの１つ以上の属性の１つ以上の値に基づいて第１の継続時間を計算することを含む。さらに、第２の継続時間を決定することは、第２のイベントの１つ以上の属性の１つ以上の値に基づいて第２の継続時間を計算することを含む。
【００２０】
ある実施形態において、第１の決定部は、第１のイベントの第１の属性の値に基づいて、第１のイベントのための第１の区画を決定するように構成される。第２の決定部は、第２のイベントの第１の属性の値に基づいて、第２のイベントは第１の区画に属すると決定するように構成される。時間ベースのウィンドウは第１の区画のためのものである。
【００２１】
ある実施形態において、第１の決定部は、第１のイベントに関連付けられた第１の時間と第１の継続時間とに基づいて第１のイベントの第１の満了時間を決定するように構成される。第２の決定部は第２のイベントに関連付けられた第２の時間と第２の継続時間とに基づいて第２のイベントの第２の満了時間を決定するように構成される。第１の除去部は、第１の満了時間の到来時または到来後に時間ベースのウィンドウから第１のイベントを除去するように構成される。第２の除去部は、第２の満了時間の到来時または到来後に時間ベースのウィンドウから第２のイベントを除去するように構成される。
【００２２】
以下の詳細な説明は、添付の図面とともに、本発明の実施形態の性質の一層の理解をもたらすであろう。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施形態を組込み得るイベント処理システムの簡略化された高レベルの図を示す。
【図２】本発明の実施形態に従い、継続時間可変ウィンドウを管理するための方法を示す簡略化されたフローチャートを示す。
【図３】本発明の実施形態に従い、継続時間可変の時間ベースウィンドウ処理を実現するために使用し得るモジュールおよびデータ構造を示す。
【図４】上記のように優先度キューを用いて継続時間可変の時間ベースウィンドウを実現する実施形態において時間ベースウィンドウオペレータが実行し得る処理を示す簡略化されたフローチャートを示す。
【図５】本発明の実施形態に従い、区画のための継続時間可変ウィンドウを管理するための方法を示す簡略化されたフローチャートを示す。
【図６】本発明の実施形態に従い、優先度キューを用いて区画のための継続時間可変ウィンドウを扱うために時間ベースウィンドウオペレータが実行し得る処理を示す簡略化されたフローチャートを示す。
【図７】本発明の実施形態に従い使用し得るシステム環境の構成要素を示す簡略化されたブロック図である。
【図８】本発明のある実施形態に従い使用し得るコンピュータシステムの簡略化されたブロック図である。
【図９】本発明のある実施形態に従い使用し得る計算装置の簡略化されたブロック図である。
【発明を実施するための形態】
【００２４】
詳細な説明
以下の記載では、説明を目的として具体的な詳細事項が本発明の実施形態の十分な理解をもたらすべく述べられている。しかしながら、さまざまな実施形態がこういった具体的な詳細事項なしで実施し得ることは明らかであろう。図面および説明は限定を意図したものではない。
【００２５】
データのストリームを処理するための改善された技術を提供する、ある実施形態について説明する。１つのイベントが時間ベースのウィンドウ内に留まる資格がある継続時間は、同一イベントストリームを介して受信した異なるイベントごとに異なり得る。ある実施形態において、入力イベントが時間ベースのウィンドウ内にある継続時間は、このイベントの１つ以上の属性の１つ以上の値の関数である。イベントが異なれば１つ以上の属性値は異なり得るので、異なるイベントがそのイベントストリーム用の時間ベースのウィンドウ内にある時間の量は異なり得る。１つのイベントが時間ベースのウィンドウ内にある時間の量は、このイベントの１つ以上の属性を介して制御することができる。
【００２６】
連続データストリーム（イベントストリームまたはイベントデータストリームとも呼ばれる）は、明確な終わりがない、本質的に連続するまたは無限であるデータまたはイベントのストリームである。論理的に、イベントまたはデータストリームは、一連のデータ要素（イベントとも呼ばれる）であり、各データ要素は関連付けられたタイムスタンプを有する。連続イベントストリームは、論理的には要素（ｓ，Ｔ）のバッグ（bag）またはセ
ットで表わすことができ、「ｓ」はデータ部分を表わし「Ｔ」は時間ドメインを表わす。「ｓ」部分は一般的にタプルまたはイベントと呼ばれる。イベントストリームはしたがってタイムスタンプされた一連のタプルまたはイベントである。
【００２７】
いくつかの実施形態において、あるストリーム内のイベントに関連付けられるタイムスタンプは、クロック時間に匹敵し得る。しかしながら、他の実施形態において、あるイベ
ントストリーム内のイベントに関連付けられる時間は、アプリケーションドメインによって定義してもよく、クロック時間に対応しなくてもよいが、たとえばその代わりに連続番号によって表わしてもよい。したがって、あるイベントストリーム内のイベントに関連付けられる時間情報は、数字、タイムスタンプ、または時間の連続の概念を表わす他の情報によって表わすことができる。入力イベントストリームを受信するシステムでは、イベントは、タイムスタンプが増す順序でシステムに到着する。同一のタイムスタンプを有する２つ以上のイベントがある場合がある。
【００２８】
いくつかの実施形態において、あるイベントストリーム内のイベントは、世の中の何らかのイベントの発生（たとえば、温度センサの値が新たな値に変化したとき、株式銘柄の価格が変化したとき）を表わしてもよく、このイベントに関連付けられた時間情報が、データストリームイベントによって表わされる上記世の中のイベントが発生した時間を示してもよい。
【００２９】
イベントストリームを介して受信するイベントについては、イベントに関連付けられた時間情報を用いて、イベントストリーム内のイベントがタイムスタンプの値が増す順序で到着することを保証する。これにより、受信するイベントストリーム内のイベントを、それぞれのイベントに関連付けられた時間情報に基づいて並べることができる。このように並べることを可能にするためには、後で生成されたイベントが、先に生成されたイベントよりも後のタイムスタンプを有するように、タイムスタンプを、イベントストリーム内のイベントと、タイムスタンプが減少しないやり方で関連付ければよい。別の例として、連続番号を時間情報として用いるのであれば、後に生成されたイベントに関連付けられる連続番号は、先に生成されたイベントに関連付けられる連続番号よりも大きい。同一のイベントストリームに属するイベントは通常、関連付けられた時間情報によってこれらイベントに課された順序で処理され、先のイベントは後のイベントよりも前に処理される。いくつかの実施形態において、たとえば、データストリームイベントで表わされる世の中のイベントが同時に発生するときには、複数のイベントが同一のタイムスタンプまたは連続番号に関連付けられることがある。これらの状況において、イベントは受信された順序で処理される。
【００３０】
イベントストリーム内のイベントに関連付けられる時間情報（たとえばタイムスタンプ）は、ストリームのソースによって設定されてもよく、または、その代わりに、このストリームを受信するシステムによって設定されてもよい。たとえば、ある実施形態において、イベントストリームを受信するシステム上でハートビート（heartbeat）を管理しても
よく、イベントに関連付けられる時間は、ハートビートによって測定される、システムへのイベントの到着時間に基づいていてもよい。あるイベントストリーム内の２つのイベントが同一の時間情報を有することが起こり得る。タイムスタンプの順序条件は、１つのイベントストリームに特有のものであるが、異なるストリームのイベントを、任意で交互配置してもよいことに注意しなければならない。
【００３１】
イベントストリームには、関連付けられたスキーマ「Ｓ」があり、スキーマは、時間情報と、名前付きの１つ以上の属性からなる一組の属性とを含む。特定のイベントストリームに属するすべてのイベントは、この特定のイベントストリームに関連付けられたスキーマに従う。したがって、イベントストリーム（ｓ，Ｔ）の場合、このイベントストリームは、スキーマ「Ｓ」を、（＜time_stamp＞，＜attribute(s)＞）として有し得る。＜attributes＞は、スキーマのデータ部分を表わし１つ以上の属性を含み得る。たとえば、株式相場表示機のイベントストリームについてのスキーマは、＜株式銘柄＞および＜株価＞という属性を含み得る。このようなストリームを介して受ける各イベントは、１つのタイムスタンプと上記２つの属性とを有する。たとえば、株式相場表示機のイベントストリームは、以下のイベントおよび関連付けられたタイムスタンプを受けることができる。
【００３２】
...
(<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」（株価）という属性に対するイベン
ト値はそれぞれＯＲＣＬおよび６２である。このストリーム要素に関連付けられたタイムスタンプは「timestamp_N+1」である。このように、連続イベントストリームは、イベン
トのフローであり、各イベントは同じ一連の属性を有する。
【００３３】
図１は、本発明の実施形態を組込み得るイベント処理システム１００の簡略化された高レベルの図を示す。イベント処理システム１００は、１つ以上のイベントソース（１０４，１０６，１０８）と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サーバ（event processing server）（ＥＰＳ）１０２と、１つ以上
のイベントシンク（１１０，１１２）とを含み得る。イベントソースは、ＥＰＳ１０２が受信するイベントストリームを生成する。ＥＰＳ１０２は、１つ以上のイベントストリームを１つ以上のイベントソースから受信し得る。たとえば、図１に示されるように、ＥＰＳ１０２は、入力イベントストリーム１１４をイベントソース１０４から受信し、第２の入力イベントストリーム１１６をイベントソース１０６から受信し、第３のイベントストリーム１１８をイベントソース１０８から受信する。１つ以上のイベント処理アプリケーション（１２０，１２２，および１２４）をＥＰＳ１０２に導入しＥＰＳ１０２によって実行してもよい。ＥＰＳ１０２によって実行されるイベント処理アプリケーションは、１つ以上の入力イベントストリームをリッスンし、１つ以上のイベントストリームを介して受信したイベントを、入力イベントストリームから１つ以上のイベントを注目すべきイベントとして選択する処理ロジックに基づいて処理するように構成されてもよい。注目すべきイベントは次に、１つ以上の出力イベントストリームの形態で１つ以上のイベントシンク（１１０，１１２）に送信してもよい。たとえば、図１において、ＥＰＳ１０２は、出力イベントストリーム１２６をイベントシンク１１０に出力し、第２の出力イベントストリーム１２８をイベントシンク１１２に出力する。ある実施形態において、イベントソース、イベント処理アプリケーション、およびイベントシンクは、これら構成要素のうちのいずれも、他の構成要素の変更を生じさせることなく追加または除去できるよう、互いに分離されている。
【００３４】
一実施形態において、ＥＰＳ１０２を、サービスを共有するEquinox OSGiをベースとするもののような軽量Ｊａｖａ（登録商標）アプリケーションコンテナを含むＪａｖａサーバとして実現してもよい。いくつかの実施形態において、ＥＰＳ１０２は、たとえばJRockit Real Timeを用いてイベント処理の超高スループットおよびマイクロ秒レイテンシを
サポートし得る。ＥＰＳ１０２はまた、イベント処理アプリケーションを開発するためのツール（たとえばOracle CEP VisualizerおよびOracle CEP IDE）を含む開発プラットフ
ォーム（たとえば完全なリアルタイムエンドツーエンドＪａｖａイベント駆動型アーキテクチャ（Event-Driven Architecture）（ＥＤＡ）開発プラットフォーム）を提供し得る
。
【００３５】
イベント処理アプリケーションは、１つ以上の入力イベントストリームをリッスンし、この１つ以上の入力イベントストリームから注目すべき１つ以上のイベントを選択するた
めにロジック（たとえばクエリ）を実行し、選択した注目すべきイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントソースに出力するように構成される。図１は、１つのこのようなイベント処理アプリケーション１２０についてのドリルダウンを提供する。図１に示されるように、イベント処理アプリケーション１２０は、入力イベントストリーム１１８をリッスンし、入力イベントストリーム１１８から注目すべき１つ以上のイベントを選択するためにロジックを含むクエリ１３０を実行し、選択した注目すべきイベントを出力イベントストリーム１２８を介してイベントシンク１１２に出力するように構成される。イベントソースの例は、アダプタ（たとえばJMS、HTTP、およびファ
イル)、チャネル、プロセッサ、テーブル、キャッシュ等を含むがこれらに限定されない
。イベントシンクの例は、アダプタ（たとえばJMS、HTTP、およびファイル）、チャネル
、プロセッサ、キャッシュなどを含むがこれらに限定されない。
【００３６】
図１のイベント処理アプリケーション１２０は、１つの入力ストリームをリッスンし選択したイベントを１つの出力ストリームを介して出力するものとして示されているが、これは限定を意図したものでない。これに代わる実施形態では、イベント処理アプリケーションは、１つ以上のイベントソースから受信した複数の入力ストリームをリッスンし、モニタリングされたストリームからイベントを選択し、選択したイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントシンクに出力するように構成されてもよい。同一のクエリを２つ以上のイベントシンクに関連付け異なる種類のイベントシンクに関連付けてもよい。
【００３７】
その性質上無制限なので、１つのイベントストリームを介して受信されるデータの量は通常非常に多い。結果として、クエリを目的としてすべてのデータを格納またはアーカイブすることは、通常実用的でなく望ましくない。イベントストリームを処理するには、イベントをＥＰＳ１０２が受信したときに、受信したイベントデータをすべて格納することなく、イベントをリアルタイムで処理することが必要である。したがって、ＥＰＳ１０２は、ＥＰＳ１０２がイベントを受信したときに、受信したイベントをすべて格納することなく、イベントを処理できるようにする、特別なクエリ機構を提供する。
【００３８】
イベント駆動型のアプリケーションはルール駆動型であり、これらルールは、入力ストリームを処理するのに使用される連続クエリの形態で表わしてもよい。連続クエリは、クエリ処理の結果としてどのイベントを注目すべきイベントとして選択し出力すべきかということを含む、受信したイベントに対して実行すべき処理を特定する命令（たとえばビジネスロジック）を含み得る。連続クエリは、データ記憶装置まで持続させて、イベントの入力ストリームの処理およびイベントの出力ストリームの生成のために使用してもよい。連続クエリは、発見すべきフィルタリングおよび集約関数を指定し入力イベントストリームから注目すべきイベントを抽出してもよい。結果として、出力イベントストリームにおけるアウトバウンドのイベントの数は通常、イベントを選択する元になる入力イベントストリームにおけるイベントの数よりも遥かに少ない。
【００３９】
有限データ集合に対して一度実行されるＳＱＬクエリと異なり、特定のイベントストリームに対してアプリケーションによりＥＰＳ１０２に登録された連続クエリは、このイベントストリーム内のイベントが受信される度に実行されてもよい。連続クエリ実行の一部として、ＥＰＳ１０２は、受信したイベントを、連続クエリが指定する命令に基づいて評価することにより、１つ以上のイベントを注目すべきイベントとして選択すべきか否か決定し、連続クエリ実行の結果として出力する。
【００４０】
連続クエリは異なる言語を用いてプログラムしてもよい。ある実施形態において、連続クエリは、Oracle社が提供する連続クエリ言語（Continuous Query Language）（ＣＱＬ
）を用いて構成されOracle社の複合イベント処理（Complex Events Processing）（ＣＥ
Ｐ）という製品によって使用されてもよい。Oracle社のＣＱＬは、イベントストリームに対して実行することができるクエリ（ＣＱＬクエリと呼ばれる）をプログラムするのに使用できる宣言型言語である。ある実施形態において、ＣＱＬは、ストリーミングイベントデータの処理をサポートする構成が追加されたＳＱＬに基づく。
【００４１】
一実施形態において、イベント処理アプリケーションは、以下の種類の構成要素で構成されてもよい。
【００４２】
（１）入力および出力ストリームならびにリレーションソースおよびシンクに直接インターフェイスする１つ以上のアダプタ。アダプタは、入力および出力ストリームプロトコルを解釈するように構成され、イベントデータを、アプリケーションプロセッサがクエリできる標準化された形態に変換する役割を担う。アダプタは、標準化されたイベントデータを、チャネルまたは出力ストリームおよびリレーションシンクに転送してもよい。イベントアダプタを、さまざまなデータソースおよびシンクに対して定めてもよい。
【００４３】
（２）イベント処理のエンドポイントとして作用する１つ以上のチャネル。特に、チャネルは、イベント処理エージェントがイベントデータに対して機能を発揮できるようになるまでイベントデータをキューに保管する役割を担う。
【００４４】
（３）１つ以上のアプリケーションプロセッサ（またはイベント処理エージェント）は、チャネルからの標準化されたイベントデータを消費（consume）し、これをクエリを用
いて処理することにより注目すべきイベントを選択し、選択した注目すべきイベントを出力チャネルに転送（またはコピー）するように構成される。
【００４５】
（４）１つ以上のビーン（bean）は、出力チャネルをリッスンするように構成または登録されてもよく、新たなイベントが出力チャネルに挿入されたことによってトリガされてもよい。いくつかの実施形態において、このユーザコードは、昔からある単なるＪａｖａオブジェクト（plain-old-Java-object）（ＰＯＪＯ）であってもよく、または、ユーザ
コードがＯｒａｃｌｅ  ＣＥＰのイベントビーンＡＰＩを使用してビーンをＯｒａｃｌｅ
ＣＥＰによって管理できるようにしてもよい。ユーザアプリケーションは、ＪＭＳ、ウェブサービス、ファイルライター等の一組の外部サービスを利用して、生成されたイベントを外部イベントシンクに転送することができる。
【００４６】
一実施形態において、イベントアダプタは、イベントデータを入力チャネルに与える。入力チャネルは、入力チャネルが与えるイベントに対して機能する１つ以上のＣＱＬクエリに関連付けられたＣＱＬプロセッサに接続される。ＣＱＬプロセッサは、クエリ結果が書込まれる出力チャネルに接続される。
【００４７】
いくつかの実施形態において、イベント処理アプリケーションに対し、イベント処理アプリケーションのさまざまな構成要素を説明しどのようにして構成要素同士が接続されるかを説明しアプリケーションによって処理されるイベントタイプを説明するアセンブリファイルを与えてもよい。イベントを選択するための連続クエリまたはビジネスロジックを指定するために別々のファイルを与えてもよい。
【００４８】
図１に示されるシステム１００が図１に示される構成要素以外の構成要素を有し得ることが理解されるはずである。さらに、図１に示される実施形態は、本発明の実施形態を組込み得るシステムの一例に過ぎない。他のいくつかの実施形態では、システム１００が有する構成要素の数は図１に示されるものよりも多くても少なくてもよく、２つ以上の構成要素を組合わせてもよく、または、構成要素の構成または配置が異なっていてもよい。システム１００は、パーソナルコンピュータ、ポータブルデバイス（たとえば携帯電話また
は装置）、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、またはその他何等かのデータ処理システムを含むさまざまな種類のものであってもよい。他のいくつかの実施形態において、システム１００を、システム１００の１つ以上の構成要素がクラウド内の１つ以上のネットワークに分散している分散システムとして構成してもよい。
【００４９】
図１に示される構成要素のうちの１つ以上は、ソフトウェア、ハードウェア、またはその組合わせにおいて実現し得る。いくつかの実施形態において、ソフトウェアは、メモリ（たとえば非一時的なコンピュータ読取可能な媒体）に、メモリ素子に、または何等かのその他の物理メモリに格納されてもよく、１つ以上の処理部（たとえば１つ以上のプロセッサ、１つ以上のプロセッサコア、２つ以上のＧＰＵなど）によって実行されてもよい。
【００５０】
イベントおよびアプリケーションの例
（１）市場変動に基づいた株式取引を自動化するための金融アルゴリズム取引アプリケーション。クエリの例：いずれかの２０秒ウィンドウ内で株式Ｂの上昇が２％を上回り株式Ａはそうではない場合、自動的に株式Ａを購入する。
【００５１】
（２）運輸。イベント間のパターンを検出することによって不正行為を発見するための安全および不正検出アプリケーション。クエリの例：都市地下鉄システムにアクセスするために１枚のＩＤカードが５秒未満の間に２度使用された場合、ピギーバックについてセキュリティ警告を発する。
【００５２】
（３）偽陽性（false positive）警告を減じるためのエネルギおよび電気通信警告相関アプリケーション。クエリの例：いずれかの５秒ウィンドウ内で１５の警告を受けたが３０秒以内に検出された同様の警告が５未満の場合、何もしない。
【００５３】
（４）患者のバイタルサインをモニタリングし特定のイベントが発生した場合に何らかのタスクを実行するためのヘルスケア患者モニタリングアプリケーション。クエリの例：薬の変更に続いて患者の血圧がいずれかの１０秒ウィンドウ内でこの患者の最大許容血圧の２０％以内上昇した場合、最も近い看護師に通知する。
【００５４】
ウィンドウベースの処理
別の例として、イベント処理アプリケーションは、ある時間範囲のデータまたはイベントを照合し処理するように構成されてもよい。たとえば、ＥＰＳ１０２は、「温度（ｔｅｍｐ）」属性および関連付けられた時間を含むイベントからなる温度イベントストリームを受信してもよい。「温度」データは、関連付けられた時間における温度を示してもよい。前の１０秒の平均温度を得るために、ＣＱＬクエリをこのようなイベントストリーム用に構築してもよい。クエリは次のように指定してもよい。
【００５５】
Select avg (temp) from temp [range 10]
上記クエリは、「１０」という範囲（ｒａｎｇｅ）における「温度（ｔｅｍｐ）」の平均（ａｖｇ）を発見する。この例における範囲「１０」は１０秒を表わす。他の実施形態において、この範囲を、分、日、またはそれ以外の指定された時間単位等、他の時間単位を用いて指定してもよい。このＣＱＬクエリは、ＥＰＳ１０２によって実行されると、前の１０秒で受信したタプルを評価し平均温度を見出す。「満了」タプル、すなわち示されている範囲よりも前に（すなわち１０秒ウィンドウ外で）受信したタプルは、クエリによって無視される。したがって、ＣＱＬクエリは、受信したイベントすべてを捕えて格納する必要はなく、最新の１０秒ウィンドウ内のイベントを処理するだけでよい。
【００５６】
イベントストリームは無限の可能性があるタプルストリームを表わすので、タプルを受
信したときに処理するために、ＣＱＬクエリ（または一般的には連続クエリ）は、ＣＱＬクエリの各実行時に処理するのに使用される受信イベントのサブセットを特定する。ＣＱＬクエリはこれをウィンドウを指定することによって行なう。この場合のウィンドウは、ＣＱＬクエリを実行するときに処理目的で使用する受信イベントのサブセット（すなわち一部）を定める。ウィンドウは、イベントストリームからのゼロ以上のイベントからなる有限のサブセットである。
【００５７】
オラクルイベント処理のＣＱＬのセマンティクスでは、ウィンドウは、ストリーム−リレーションオペレータとして定義され、すべての瞬間において、リレーションは、順序付けられていない、時間によって変化する、イベントの有限の集合（またはバッグ）である。一実施形態において、ストリーム−リレーションオペレータは、ストリームに対してスライディングウィンドウを提供し、ウィンドウ仕様を用いて定められる。いくつかの実施形態において、ウィンドウは、
（１）時間ベース‐特定の継続時間に基づくもの、
（２）タプルベースまたはイベントベース‐イベントの数に基づくもの、または、
（３）区画ベース‐各区画で時間ベースまたはタプルベースのものであってもよい。
【００５８】
時間ベースのウィンドウ
イベントストリームを処理するために、時間ベースのウィンドウは、このウィンドウに含まれるイベントを制御する時間パラメータを用いて定められる。いくつかの実施形態において、時間パラメータは、このウィンドウの時間範囲を指定してもよい。たとえば、ＣＱＬクエリは、入力ストリームＳに対する時間範囲ベースのウィンドウを次のように指定してもよい。
【００５９】
S [range T]
上記ＣＱＬコードは、継続時間「Ｔ」をパラメータとして取る、ストリームに対する時間ベースの範囲ウィンドウを作成し、出力リレーションを生成する。継続時間Ｔは、分、秒、日等の何等かの時間単位で指定されればよく、一実施形態では、単位が指定されなければデフォルトを秒にする。このように、「範囲」というキーワードを用いて指定された時間ベースのウィンドウは、ストリームＳに対し、時間間隔「Ｔ」をパラメータとして取り出力リレーション「Ｒ（ｔ）」を生成する時間ベースのスライディングウィンドウを作成する。時間「ｔ」において、出力リレーションＲ（ｔ）は、入力イベントストリームＳからの、「ｔ−Ｔ」と「ｔ」の間の関連するタイムスタンプを有するすべてのイベントを含み、「Ｔ」はこのウィンドウのサイズすなわち継続時間である。
【００６０】
時間ベースの範囲ウィンドウの過去の実装例では、ＣＱＬにおいて時間ウィンドウの継続時間を指定するために使用される時間パラメータ「Ｔ」は、一定または固定されていた。したがって、以前の実装例では、各イベントが時間ベースのウィンドウ内にある時間の量は、イベント自体に応じて異なるものではない。すべてのイベントは等しく扱われ、すべてのイベントは時間ベースのウィンドウ内に同じ継続時間存在する。たとえば、先に説明した温度平均のＣＱＬクエリの例では、範囲は「［ｒａｎｇｅ  １０］」として指定され、「Ｔ」の値は１０秒を表わす固定値「１０」に設定される。この範囲ウィンドウは固定されており変動しないという性質のものであるので、時間「ｔ」において、ウィンドウは最新の１０秒（すなわち「ｔ」と「ｔ−１０」の間）で受信したイベントのリレーションセットを評価する。ウィンドウ自体は「ｔ」でスライドするが、ウィンドウの継続時間は常に１０秒に固定されることに注意しなければならない。継続時間が固定されているので、以前は、時間ベースのウィンドウ内のイベントは常に、この時間ウィンドウ内の同じ継続時間後に満了した。
【００６１】
固定されたまたは一定の時間ベースの範囲ウィンドウに加えて、本発明のある実施形態
は、時間ベースのウィンドウの継続時間を、同一のイベントストリームを介して受信した異なるイベントごとに変えることができる。このような実施形態では、スライドする時間ベースの範囲ウィンドウの継続時間を定めるために用いられる継続時間パラメータ「Ｔ」の値を、異なるイベントごとに異なるようにする、したがって変えることができる。このため、特定のイベントストリームに対してＥＰＳ１０２に登録されたクエリにとって、このイベントストリームを介して受信したイベントの継続時間は、異なるイベントごとに異なり得る。たとえば、図１に示されるように、イベントアプリケーション１２０は、可変の時間ベースのウィンドウを指定するＣＱＬコードを有する連続クエリ１３０を含み得る。
【００６２】
たとえば、イベントストリームを介して受信した第１の入力イベントについて、第１のイベントが時間ベースの範囲ウィンドウ内に留まる資格がある継続時間は「Ｘ」で、同じイベントストリームを介して受信した第２のイベントについて、第２のイベントが時間ベースのウィンドウ内に留まる資格がある継続時間は「Ｙ」で、「Ｘ」が「Ｙ」と同一でないという場合がある。第１および第２のイベントは、同じ関連タイムスタンプを有し得る、または、異なるタイムスタンプを有し得る。本発明の実施形態はしたがって、イベントが時間ベースのウィンドウ内にある時間の量を制御できるようにする。
【００６３】
イベントに対して継続時間可変範囲パラメータＴの値を設定できる方法としてはさまざまな方法がある。いくつかの実施形態において、継続時間パラメータＴは、ユーザによって構成可能なものであってもよい。ある実施形態において、Ｔの値（すなわち時間ベースの範囲ウィンドウの継続時間）は、イベント自体の関数である。たとえば、受信したイベントに対するＴの値は、受信したイベントの１つ以上の属性の値に基づいて設定してもよい。たとえば、関連するスキーマが２つの属性＜ａｔｔｒ＿１，ａｔｔｒ＿２＞を有するイベントストリームを想定する。一実施形態において、このイベントストリームを対象とするＣＱＬクエリにおいて、イベントが時間ベースの範囲ウィンドウ内にあることが可能な時間を、属性「ａｔｔｒ＿２」の値に設定されるようにプログラムしてもよい。たとえば、イベントストリームが下記イベントを受信するとする。
【００６４】
...
(<timestamp_N>,<attr_1=100,attr_2=5>)
(<timestamp_N+1>,<attr_1=100,attr_2=2>)
(<timestamp_N+2>,<attr_1=200,attr_2=2>)
(<timestamp_N+3>,<attr_1=600,attr_2=4>)
...
ｔｉｍｅｓｔａｍｐ＿Ｎを有するイベントを受信したとき、このイベントが時間ベースの範囲ウィンドウ内に留まることができる継続時間は、５時間単位と計算される。なぜなら、タプルのａｔｔｒ＿２の値が５であるからである。ｔｉｍｅｓｔａｍｐ＿Ｎ＋１を有するイベントの場合、このイベントが時間ベースの範囲ウィンドウ内に留まることができる継続時間は、２時間単位と計算され、ｔｉｍｅｓｔａｍｐ＿Ｎ＋２を有するイベントの場合、このイベントが時間ベースの範囲ウィンドウ内に留まることができる継続時間は、２時間単位と計算され、ｔｉｍｅｓｔａｍｐ＿Ｎ＋３を有するイベントの場合、このイベントが時間ベースの範囲ウィンドウ内に留まることができる継続時間は、４時間単位と計算され、以降同様に続く。このようにして、１つのイベントがそのイベントストリームに対する時間ベースのウィンドウ内に留まる資格がある継続時間は、イベントごとに異なり得る。上記例において、継続時間は受信したイベントの属性「ａｔｔｒ＿２」に基づいて変化する。
【００６５】
他のいくつかの実施形態において、時間パラメータＴは、数式（mathematical expression）として次のように表わしてもよい。
【００６６】
S [RANGE <mathematical_expression>]
ある実施形態において、この数式は、イベントストリームスキーマの１つ以上の属性に基づくものであってもよい。たとえば、スキーマ属性が＜ａｔｔｒ＿１，ａｔｔｒ＿２＞であるイベントストリームについて、＜ｍａｔｈｅｍａｔｉｃａｌ＿ｅｓｐｒｅｓｓｉｏｎ＞は、＜ａｔｔｒ＿２＋４＞，＜ａｔｔｒ＿１＋ａｔｔｒ＿２＞等として定めてもよい。これに代わる実施形態において、イベントベースであってもなくてもよい他の関数または条件を用いて、連続クエリの時間ベースの範囲ウィンドウの継続時間を設定し変化させてもよい。
【００６７】
別の例として、ストリームを次のように定義するとする。
CREATE STREAM S (DATA INTEGER, RANGE_COLUMN BIGINT)
この定義によると、各ストリームイベントは、２つの属性（カラムとも呼ばれる）、すなわち、整数データ値を取る第１の属性「ＤＡＴＡ」と、ｂｉｇｉｎｔ（長い）値を取る第２の属性「ＲＡＮＧＥ＿ＣＯＬＵＭＮ」とを含む。次に、この「ＲＡＮＧＥ＿ＣＯＬＵＭＮ」属性を用いて、時間ベースの範囲ウィンドウの継続時間を指定してもよい。
【００６８】
継続時間可変の時間ベース範囲ウィンドウを指定するＣＱＬクエリは、ストリームＳに対し、次のように指定してもよい。
【００６９】
CREATE QUERY Q1 AS SELECT * FROM S [RANGE <range_expression>]
これにより、時間ベースの範囲ウィンドウに対して連続クエリＱ１が作成され、この場合、時間ベースのウィンドウの継続時間が「ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ」という式として指定される。
【００７０】
一実施形態において、ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎは、ストリームＳからの１つ以上の属性に基づいていてもよい。たとえば次の通りである。
【００７１】
CREATE QUERY Q1 AS SELECT * FROM S [RANGE RANGE_COLUMN]
ここで、受信したイベントの属性ＲＡＮＧＥ＿ＣＯＬＵＭＮの値は、時間ベースの範囲ウィンドウの継続時間を指定する。この場合、＜ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＞の値は、Ｓというイベントストリームを介して受信した各入力イベントに対し、受信した入力イベントの属性ＲＡＮＧＥ＿ＣＯＬＵＭＮの値を用いて計算される。時間「ｔ」で受信した入力タプルは、時間ベースのウィンドウに挿入され、この時間ベースのウィンドウ内に、＜ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＞の値に従う継続時間留まった後、満了するかまたはウィンドウから除去される。受信イベントに対して計算される満了時間はしたがって、（ｔ＋ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＿ｖａｌｕｅ）であり、「ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＿ｖａｌｕｅ」は、イベントを受信したときに、受信したイベントのＲＡＮＧＥ＿ＣＯＬＵＭＮ属性の値を用いて＜ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＞の値を求めることによって計算される値である。属性ＲＡＮＧＥ＿ＣＯＬＵＭＮの値はイベントごとに異なり得るので、時間ベースのウィンドウの継続時間もイベントごとに異なり得る。
【００７２】
以下の例は、イベント受信時の継続時間可変の時間ベース範囲ウィンドウの効果を示す。この例について、入力イベントストリームＳは、３つの属性ｃ１、ｃ２、およびｃ３として（ｃ１  ｉｎｔｅｇｅｒ，ｃ２  ｂｉｇｉｎｔ，ｃ３  ｄｏｕｂｌｅ）を有するスキーマ（＜ｔｉｍｅｓｔａｍｐ＞，＜ａｔｔｒｉｂｕｔｅｓ＞）を有すると想定する。連続ＣＱＬクエリをストリームＳに対して以下のように指定してもよい。
【００７３】
SELECT * FROM S [range c2]
このクエリによると、受信した各入力について、時間ベースのウィンドウの継続時間は属性ｃ２の値に基づく。
【００７４】
以下の表Ａは、タプルの入力ストリームと、入力イベントストリームＳを介してイベントを受信するときのさまざまな時点における時間ベースの範囲ウィンドウの内容とを示す。
【００７５】
【表１】
2019061712.tif 000003
【００７６】
上記表Ａにおいて、左の列はスキーマ（タイムスタンプ，ｃ１，ｃ２，ｃ３）を有するストリームＳを介して受信されたイベントのストリームを示す。タイムスタンプはミリ秒（ｍｓｅｃｓ）で示され、１秒＝１０００ｍｓｅｃｓである。タイムスタンプは、たとえば、イベントの受信時の時間またはイベントの発生時の時間であってもよい。表Ａの右の列は、さまざまな時点（ミリ秒（ｍｓｅｃｓ）で示され、１秒＝１０００ｍｓｅｃｓであ
る）における、時間ベースの範囲ウィンドウの内容（すなわちイベント）を示す。イベントの前の「＋」表記は、このイベントが時間ベースのウィンドウに追加されたことを示すために使用される。イベントの前の「−」表記は、このイベントが、このイベントが満了したために、時間ベースのウィンドウから削除されたことを示すために使用される。
【００７７】
一実施形態において、イベントが受信されると、このイベントの満了時間が計算される。イベントに対して計算される満了時間は、このイベントが満了し時間ベースのウィンドウから削除されることになる時間を示す。その後このイベントは時間ベースのウィンドウに追加される。また、時間ベースのウィンドウが検査されて、このウィンドウ内のいずれかのイベントが満了しておりウィンドウから取除かれる必要があるか否か判断される。
【００７８】
時間「ｔ」に到着し時間範囲または継続時間が「Ｔ」であるイベントについて、このイベントの満了時間は（ｔ＋Ｔ）である。以下のクエリの場合、範囲の値は、受信したイベントの属性ｃ２の値に基づく。
【００７９】
SELECT * FROM S [range c2]
したがって、関連付けられたタイムスタンプが「ｔ」である受信イベントについて、このイベントの満了時間は（ｔ＋ｃ２の値）である。上記表Ａにおいて、各受信イベントの満了時間（expiration time）は、このイベントの添え字として示されている。
【００８０】
【数１】
2019061712.tif 000004
【００８１】
ある実施形態において、範囲句によって具体的に指定されない限り、範囲の時間単位のデフォルトは秒であり、したがって、Ｓ［ｒａｎｇｅ  １］は、Ｓ［ｒａｎｇｅ  １秒］に等しい。
【００８２】
時間ベースのウィンドウ（すなわち時間ベースのウィンドウによって出力されるリレーションセット）は、１０００ミリ秒の時点でイベントが到着する前、すなわち関連付けられたタイムスタンプが１０００ミリ秒であるイベントが到着する前は、空である。表Ａに示されるように、イベント（１０００，１０，１，１０．０）が最初に受信される。このイベントの満了時間は２秒（イベントのタイムスタンプ＋ｃ２の値、すなわち１＋１＝２秒）と計算される。次に、このイベントは時間ベースのウィンドウに追加される（「＋」で示される）。イベント（１０００，１０，１，１０．０）は、時間ベースのウィンドウに１秒間留まり２秒の標識の時点でウィンドウから削除されることになる。この時点で、時間ベースの範囲ウィンドウは、１つのイベント（１０００，１０，１，１０．０）を含む。
【００８３】
次にイベント（２０００，２０，２，２０．０）が受信される。一実施形態において、２０００ミリ秒というタイムスタンプは、このイベントが受信された時間を表わしてもよい。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断される。イベント（１０００，１０，１，１０．０）は満了しており時間ベースのウィンドウから削除される（「−」で示される）と判断される。イベント（２０００，２０，２，２０．０）の満了時間は４秒（イベントのタイムスタンプ＋ｃ２の値、すなわち、２＋２＝４秒）と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に２秒間留まり４秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、１つのイベント（２０００，２０，２，２０．０）を含む。
【００８４】
次にイベント（３０００，３０，３，３０．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント（３０００，３０，３，３０．０）の満了時間は６秒（イベントのタイムスタンプ＋ｃ２の値、すなわち、３＋３＝６秒）と計算される。このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に３秒間留まり６秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、２つのイベント（２０００，２０，２，２０．０）および新たに追加されたイベント（３０００，３０，３，３０．０）を含む。
【００８５】
次にイベント（４０００，４０，４，４０．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断される。イベント（２０００，２０，２，２０．０）は満了しており時間ベースのウィンドウから削除される（「−」で示される）と判断される。イベント（４０００，４０，４，４０．０）の満了時間は８秒（イベントのタイムスタンプ＋ｃ２の値、すなわち、４＋４＝８秒）と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に４秒間留まり８秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、２つのイベント（３０００，３０，３，３０．０）および新たに追加されたイベント（４０００，４０，４，４０．０）を含む。
【００８６】
次にイベント（５０００，５０，５，５０．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント（５０００，５０，５，５０．０）の満了時間は１０秒（イベントのタイムスタンプ＋ｃ２の値、すなわち、５＋５＝１０秒）と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に５秒間留まり１０秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、３つのイベント（３０００，３０，３，３０．０）、（４０００，４０，４，４０．０）、および新たに追加されたイベント（５０００，５０，５，５０．０）を含む。
【００８７】
次にイベント（６０００，６０，６，６０．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、イベント（３０００，３０，３，３０．０）は満了しており時間ベースのウィンドウから削除される（「−」で示される）と判断される。イベント（６０００，６０，６，６０．０）の満了時間は１２秒（イベントのタイムスタンプ＋ｃ２の値、すなわち、６＋６＝１２秒）と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に６秒間留まり１２秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、３つのイベント（４０００，４０，４，４０．０）、（５０００，５０，５，５０．０）および新たに追加されたイベント（６０００，６０，６，６０．０）を含む。
【００８８】
次にイベント（７０００，７０，７，７０．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント（７０００，７０，７，７０．０）の満了時間は１４秒（イベントの到着時間＋ｃ２の値、すなわち、７＋７＝１４秒）と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に７秒間留まり１４秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、４つのイベント（４０
００，４０，４，４０．０）、（５０００，５０，５，５０．０）、（６０００，６０，６，６０．０）、および新たに追加されたイベント（７０００，７０，７，７０．０）を含む。
【００８９】
次にイベント（８０００，８０，８，８０．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、イベント（４０００，４０，４，４０．０）は満了しており時間ベースのウィンドウから削除される（「−」で示される）と判断される。イベント（８０００，８０，８，８０．０）の満了時間は１６秒（イベントのタイムスタンプ＋ｃ２の値、すなわち、８＋８＝１６秒）と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に８秒間留まり１６秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、４つのイベント（５０００，５０，５，５０．０）、（６０００，６０，６，６０．０）、（７０００，７０，７，７０．０）、および新たに追加されたイベント（８０００，８０，８，８０．０）を含む。
【００９０】
次にイベント（９０００，９０，９，９０．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント（９０００，９０，９，９０．０）の満了時間は１８秒（イベントの到着時間＋ｃ２の値、すなわち、９＋９＝１８秒）と計算される。このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に９秒間留まり１８秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、５つのイベント（５０００，５０，５，５０．０）、（６０００，６０，６，６０．０）、（７０００，７０，７，７０．０）、（８０００，８０，８，８０．０）、および新たに追加されたイベント（９０００，９０，９，９０．０）を含む。
【００９１】
次にイベント（１００００，１００，１０，１００．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、イベント（５０００，５０，５，５０．０）は満了しており時間ベースのウィンドウから削除される（「−」で示される）と判断される。イベント（１００００，１００，１０，１００．０）の満了時間は２０秒（イベントのタイムスタンプ＋ｃ２の値、すなわち、１０＋１０＝２０秒）と計算される。このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に１０秒間留まり２０秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、５つのイベント（６０００，６０，６，６０．０）、（７０００，７０，７，７０．０）、（８０００，８０，８，８０．０）、（９０００，９０，９，９０．０）、および新たに追加されたイベント（１００００，１００，１０，１００．０）を含む。
【００９２】
次にイベント（１１０００，１１０，１１，１１０．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント（１１０００，１１０，１１，１１０．０）の満了時間は２２秒（イベントのタイムスタンプ＋ｃ２の値、すなわち、１１＋１１＝２２秒）と計算される。このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に１１秒間留まり２２秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、６つのイベント（６０００，６０，６，６０．０）、（７０００，７０，７，７０．０）、（８０００，８０，８，８０．０）、（９０００，９０，９，９０．０）、（１００００，１００，１０，１００．０）、および新たに追加されたイベント（１１０００，１１０，１１，１１０．０）を含む。
【００９３】
次にイベント（１２０００，１２０，１２，１２．０）が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、イベント（６０００，６０，６，６０．０）は満了しており時間ベースのウィンドウから削除される（「−」で示される）と判断される。イベント（１２０００，１２０，１２，１２０．０）の満了時間は２４秒（イベントの到着時間＋ｃ２の値、すなわち、１２＋１２＝２４秒）と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に１２秒間留まり２４秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、６つのイベント（７０００，７０，７，７０．０）、（８０００，８０，８，８０．０）、（９０００，９０，９，９０．０）、（１００００，１００，１０，１００．０）、（１１０００，１１０，１１，１１０．０）、および新たに追加されたイベント（１２０００，１２０，１２，１２０．０）を含む。
【００９４】
表Ａに関して先に述べたように、入力イベントの受信時に実行される処理は、入力イベントの満了時間を決定することと、入力イベントを時間ベースのウィンドウに追加することと、ウィンドウを検査することにより、満了したイベントを同定し削除することとを含む。イベントが時間ベースのウィンドウ内にある継続時間は、入力イベントの属性の関数であってもよい。この属性の値は、イベントが異なれば異なり得るので、イベントが時間ベースのウィンドウ内にある継続時間は、イベントごとに異なり得る。したがって、イベントが時間ベースのウィンドウ内に留まる資格がある継続時間は、イベントが異なれば異なり得る。
【００９５】
図２は、本発明の実施形態に従い、継続時間可変ウィンドウを管理するための方法を示す簡略化されたフローチャート２００を示す。図２に示される処理は、１つ以上のプロセッサによって実行されるソフトウェア（たとえばコード、命令、プログラム）で実施されてもよく、ハードウェアで実施されてもよく、またはその組合わせにおいて実施されてもよい。ソフトウェアは、メモリに（たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に）格納されていてもよい。図２に示される特定の一連の処理ステップは、限定を意図したものではない。
【００９６】
ある実施形態において、図２に示される処理は、イベントストリームを介して入力イベントが受信される度に、連続クエリ実行の一部として実行されてもよい。２０２で、イベントストリーム内の入力イベント（タプル）が受信されてもよい。このイベントは、関連付けられた時間情報（たとえばタイムスタンプ）を有していてもよい。いくつかの例において、あるイベントに関連付けられた時間は、このイベントの受信時の時間を示すものであってもよい。
【００９７】
２０４で、受信されたイベントについて、このイベントが時間ベースのウィンドウ内で保持されることになる継続時間が計算される。２０４の一部として、ＣＱＬコードによって時間ベースのウィンドウに対して指定された範囲パラメータが決定され継続時間を決定するのに使用される。先に説明したように、いくつかの実施形態において、連続クエリは、時間ベースのウィンドウの継続時間を、受信された入力イベントの１つ以上の属性の値の関数として定めてもよい。このようなシナリオにおいて、２０４で継続時間を決定することは、２０２で受信されたイベントの１つ以上の属性の値を決定することと、これら値の関数として継続時間を計算することとを含み得る。継続時間を計算するために使用される上記１つ以上の属性の値は、異なるイベントごとに異なり得るので、この継続時間は個々のイベントごとに異なる可能性がある。
【００９８】
たとえば、ある実施形態において、この継続時間は、イベントの特定の属性の値に設定
されてもよい。この特定の属性の値は、２０４で決定されてもよく、入力イベントに対するウィンドウ継続時間は、決定された値に設定される。他のいくつかの実施形態において、連続クエリは、ウィンドウの継続時間を、１つ以上の属性値に基づいて、算術式として定めてもよい。このようなシナリオにおいて、２０４で、受信されたイベントの１つ以上の属性値が決定されてもよく、その後、決定された値を用いて算術式の値が求められ、それにより、受信イベントの継続時間が計算されてもよい。
【００９９】
２０６で、受信されたイベントについて、２０４で決定された継続時間に基づいて満了時間が計算される。一実施形態において、
イベントの満了時間＝ｔ＋Ｔ
であり、「ｔ」は２０２で受信されたイベントに関連付けられた時間（たとえばイベントの到着時間）であり、「Ｔ」は２０４で決定された継続時間である。
【０１００】
２０８で、２０６で計算された満了時間は、２０２で受信されたイベントに関連付けられてもよい。たとえば、満了時間情報を格納しておいて、ＥＰＳ１０２がイベントが与えられたときにこのイベントに対して計算される満了時間を容易に求めることができるようにしてもよい。
【０１０１】
２１０で、時間ベースのウィンドウが検査されて、満了したイベント（すなわち以前に受信したイベント）を含むか否か判断される。満了していると識別されたイベントについては、このイベントは２１０で時間ベースのウィンドウから削除または除去される。一実施形態において、時間ベースのウィンドウ内のイベントは、このイベントについて計算された満了時間が現在の時間と等しいかまたはそれよりも前であれば、満了しているとみなされる。上記のように、あるイベントの満了時間は（ｔ＋Ｔ）と計算される。したがって、現在の時間（ｔｐ）が（ｔ＋Ｔ）と同一かまたはそれよりも後であれば、イベントは満了しているとみなされる。満了したと判断されたイベントは次に、時間ベースのウィンドウから削除または除去される。
【０１０２】
２１２で、２０２で受信されたイベントが、時間ベースのウィンドウに挿入または追加される。２１４で、この処理はその後、イベントストリーム内の次のイベントを待つ。次のイベントが受信されると、処理は２０２から２１４まで繰り返される。
【０１０３】
図２に関して先に説明したように、受信された各イベントについて継続時間と満了時間が計算され、イベントはその後時間ベースのウィンドウに挿入される。さらに、時間ベースのウィンドウ内にあるイベントが検査されて、満了したイベントが識別され、満了したイベントはその後時間ベースのウィンドウから削除または除去される。このようにして、あるイベントが時間ベースのウィンドウ内に留まることになる継続時間を、イベントごとに計算し、この継続時間は、イベントの１つ以上の属性値に基づいていてもよい。イベントについて、継続時間に基づいて計算される満了時間は、イベントが満了し時間ベースのウィンドウから削除または除去されることになる時間を表わす。
【０１０４】
図３は、本発明の実施形態に従い、継続時間可変の時間ベースウィンドウ処理を実現するために使用し得るモジュールおよびデータ構造を示す。図３に示されるモジュールは、ソフトウェア、またはハードウェア、またはその組合わせにおいて実現し得る。さらに、図３に示されるモジュールおよびデータ構造は限定を意図したものではない。これに代わる実施形態は、さまざまな配置および組み合わせの、図３に示されるものよりも多いかまたは少ないモジュールを有していてもよい。
【０１０５】
図３に示される実施形態において、モジュールは、継続時間および満了時間評価器モジュール３０２と、時間ベースウィンドウオペレータモジュール３０４とを含む。継続時間
および満了時間評価器モジュール３０２は、新たに受信した各イベントに対し、この受信イベントの継続時間および満了時間を決定するように構成されてもよい。受信イベントはその後、このイベントに対して計算された満了時間とともに、さらなる処理のために時間ベースウィンドウオペレータ３０４に渡されもよい。一実施形態において、継続時間および満了時間評価器３０２は、図２の２０４、２０６、および２０８に示され先に説明された処理を実行するように構成されてもよい。
【０１０６】
時間ベースウィンドウオペレータ３０４は、時間ベースのウィンドウを管理するように構成されてもよい。これは、新たに受信したイベントを時間ベースのウィンドウに挿入することと、時間ベースのウィンドウ内のイベントがいつ満了したか判断することと、満了したイベントを時間ベースのウィンドウから削除または除去することとを含み得る。一実施形態において、時間ベースウィンドウオペレータ３０４は、２１０および２１２に示され先に説明された処理を実行するように構成されてもよい。
【０１０７】
さまざまなデータ構造を用いて継続時間可変の時間ベースウィンドウを実現してもよい。一実施形態において、優先度キューが使用され、優先度はウィンドウ内のイベントに対して計算された満了時間によって指示される。新たに受信されたイベントはキューに追加され、満了したイベントはキューから削除される。キューの中にあるイベントは、それぞれに関連付けられた満了時間に基づいてソートされてもよい。一実施形態において、イベントは、満了時間がより早いイベントがキューの先頭により近く満了時間がより遅いイベントがキューの末尾により近くなるように、ソートされる。どの時点でも、優先度キューは、その時点で時間ベースのウィンドウ内にあるゼロ以上のイベントを表わすゼロ以上のイベントを含み得る。
【０１０８】
図４は、上記のように優先度キューを用いて継続時間可変の時間ベースウィンドウを実現する実施形態において時間ベースウィンドウオペレータが実行し得る処理を示す簡略化されたフローチャート４００を示す。図４に示される処理は、１つ以上のプロセッサによって実行されるソフトウェア（たとえばコード、命令、プログラム）で実施されてもよく、ハードウェアで実施されてもよく、またはその組合わせにおいて実施されてもよい。ソフトウェアは、メモリに（たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に）格納されていてもよい。図４に示される特定の一連の処理ステップは、限定を意図したものではない。
【０１０９】
４０２で、新たに受信されたイベントは、関連付けられた満了時間とともに受信されてもよい。このイベントの満了時間は、継続時間および満了時間評価器３０２によって既に計算されていてもよい。
【０１１０】
４０４で、キューは空か否か判断される。空のキューは、現在ウィンドウ内にイベントがないことを示す。４０４でキューが空であると判断された場合、処理は４１２に続き、そうでなければ処理は４０６に続く。
【０１１１】
４０６で、優先度キューの先頭にあるイベントがアクセスされる。優先度キューの中にあるイベント要素は常に、これらイベントに関連付けられた満了時間に基づいてソートされ、満了時間がより早いイベントはキューの先頭により近く、満了時間がより遅いイベントはキューの末尾により近いので、キューの先頭にあるイベントは、ウィンドウ内で満了時間が最も早いイベントを表わす。
【０１１２】
４０８で、４０６でアクセスされたイベントが満了しているか否か判断される。一実施形態において、アクセスされたイベントに関連付けられた満了時間が現在の時間に等しいかまたはそれよりも早い場合、このイベントは満了しているとみなされる。たとえば、現
在の時間が１０秒の標識にあるとすると、アクセスされたイベントに関連付けられた満了時間が１０秒または１０秒未満であれば、このアクセスされたイベントは満了しているとみなされる。４０８で、アクセスされたイベントが満了していると判断された場合、４１０で、アクセスされたイベントは優先度キューから除去または削除され、処理は４０４に続く。４０８で、アクセスされたイベントが満了していないと判断された場合、処理は４１２に続く。このようにして、４０４、４０６、４０８、および４１０の処理は、キューの中の満了したイベントすべてがキューから除去されるまで、または、キューが空になるまで、繰り返される。
【０１１３】
４０４でキューは空であると判断されるかまたは４０６でアクセスされたイベントが満了していないと判断された場合、処理は４１２に続く。４１２では、４０２で受信されたイベントが、このイベントに対して計算された満了時間に基づいてキューに追加される。イベントは、キューのソートされた（すなわち満了時間に基づいてソートされた）状態が維持されるように挿入される。次に、処理は４１４に続き、４１４でＥＰＳ１０２はイベントストリーム内の次のイベントを待つ。イベントが来ると、処理は４０２に続く。
【０１１４】
時間ベースの区画ウィンドウ
ある実施形態において、「ＰＡＲＴＩＴＩＯＮ  ＢＹ」というＣＱＬ句によって、１つのイベントストリームを、このストリームの属性に基づいて、論理的に複数のサブストリームに分割することができる。次に、範囲（ｒａｎｇｅ）Ｔのスライディングウィンドウが、各サブストリームに対して独立して計算される。
【０１１５】
たとえば、ストリームＳに対し、時間ベースの区画ウィンドウは次のように定義されてもよい。
【０１１６】
S [partition by A1,..., Ak rows N range T]
ストリームＳに対する上記分割スライディングウィンドウは、イベントの正の整数Ｎと、ストリームの属性のサブセット｛Ａ１，...Ａｋ｝とをパラメータとして取り、（１）属
性Ａ１，...Ａｋが同等であることに基づいて、論理的にＳを異なるサブストリームに分
割し、（２）各サブストリームに対し独立してサイズがＮで範囲／継続時間がＴのイベントベースのスライディングウィンドウを計算する。イベントベースのスライディングウィンドウは独立して各区画に適用される。このようなウィンドウを「行‐時間範囲ウィンドウ」と呼んでもよい。なぜなら、ある区画に対するウィンドウについて、イベントは、「ｒａｎｇｅ（範囲）Ｔ」によって制御されるそれぞれのイベントに関連付けられた満了時間に基づいて、または、「ｒｏｗｓ（行）Ｎ」によって制御されるウィンドウ内のイベントの数に基づいて、ウィンドウから満了するからである。上記Ｎは行‐時間範囲ウィンドウ内のイベントの最大数を定める。
【０１１７】
過去の実装例では、範囲／継続時間パラメータ「Ｔ」は、一定または固定されており可変ではなかった。本発明のある実施形態では、ＰＡＲＴＩＴＩＯＮ  ＢＹ句によって作成された１つの区画のための行‐時間範囲ウィンドウ内に１つのイベントが留まる資格がある継続時間を指定する範囲／継続時間パラメータＴを、異なるイベントごとに異なるようにすることができる。結果として、特定の入力イベントストリームに対しＥＰＳ１０２に登録されたクエリについて、１つの区画のためのウィンドウ内にイベントが留まる継続時間を、異なるイベントごとに異なるようにすることができる。
【０１１８】
たとえば、継続時間可変区画ウィンドウを有する以下のＣＱＬクエリについて考える。
CREATE QUERY Q1 AS 
SELECT * 
FROM S [PARTITION BY DATA ROWS M RANGE <range_expression>]
上記ＣＱＬコードは、ストリームＳを、「ＤＡＴＡ」の値に基づいて区画すなわちサブストリームに分割する。各区画について、ＣＱＬコードは行‐時間範囲ウィンドウを指定し、この行‐時間範囲ウィンドウ内のイベントの最大数は「Ｍ」であり、１つのイベントがこの行‐時間範囲ウィンドウ内に留まる資格がある継続時間は＜ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＞で表わされる。この例において、「ｒａｎｇｅ」についてのパラメータは、式「＜ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＞」として指定され、ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎは、変数または算術式であってもよい。ある実施形態において、＜ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＞は、イベント属性に基づくものであってもよい。他の実施形態において、＜ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＞は、イベントストリームスキーマの１つ以上の属性に基づき得る算術式であってもよい。
【０１１９】
例として以下のものについて考える。
FROM S [PARTITION BY DATA ROWS 2 RANGE RANGE_COLUMN]
この場合も、イベントストリームＳは、属性「ＤＡＴＡ」の値に基づいて区画に分割される。ＣＱＬコードは、各区画に対し、行‐時間範囲ウィンドウを指定する。１つの区画のためのウィンドウ内のイベントの最大数は２であり、１つのイベントがこのウィンドウ内に留まる資格がある継続時間は、イベント属性であるＲＡＮＧＥ＿ＣＯＬＵＭＮで表わされる。特定の区画に属する１つのイベントについて、このイベントがこの区画のための行‐時間範囲ウィンドウ内に留まる資格がある継続時間は、このイベントの属性ＲＡＮＧＥ＿ＣＯＬＵＭＮの値と、この区画ウィンドウ内のイベントの数（最大で２）とによって制御される。したがって、属性ＲＡＮＧＥ＿ＣＯＬＵＭＮの値が互いに異なるイベントは、互いに異なる継続時間ウィンドウ内に留まる資格があることになる。
【０１２０】
以下の例において、区画時間ベースの継続時間パラメータは、以下の算術式で表わされる。
【０１２１】
CREATE QUERY Q1 AS 
SELECT * FROM S [PARTITION BY DATA ROWS 2 RANGE <range_expression>]
この場合、イベントストリームＳは、属性「ＤＡＴＡ」の値に基づいて区画に分割される。ＣＱＬコードは、各区画に対して行‐時間範囲ウィンドウを指定し、１つのウィンドウ内のイベントの最大数は２であり、１つのイベントがこのウィンドウ内に留まる資格がある継続時間は、式＜ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＞で表わされる。この行‐時間範囲ウィンドウは、独立して各区画に適用される。ある区画の受信イベントに対して計算される満了時間はしたがって（ｔ＋ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＿ｖａｌｕｅ）であり、「ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＿ｖａｌｕｅ」は、イベントの受信時に＜ｒａｎｇｅ＿ｅｘｐｒｅｓｓｉｏｎ＞の値を求めることによって計算される値である。
【０１２２】
以下の例は、イベントの受信時に、異なる区画に適用される継続時間可変の時間ベース範囲ウィンドウの効果を示す。この例について、入力イベントストリームＳは２つの属性ｃ１およびｃ２を有するスキーマを有すると想定する。
【０１２３】
S (c1 character(2), c2 bigint）
ストリームＳに対する連続ＣＱＬクエリは次のように指定してもよい。
【０１２４】
SELECT * from S [PARTITION BY c1 ROWS 2 RANGE c2]
上記ＣＱＬコードによると、入力ストリームＳは、属性ｃ１の値に基づいて区画に分割される。ＣＱＬコードは、各区画に対し行‐時間範囲ウィンドウを指定し、１つの区画のためのウィンドウ内のイベントの最大数は、（「ＲＯＷＳ  ２」なので）２であり、イベントがこの区画のためのウィンドウ内に留まる資格がある継続時間は、（「ＲＡＮＧＥ  ｃ２」なので）このイベントの属性ｃ２の値によって決定される。
【０１２５】
以下の表Ｂは、タプルの入力ストリーム、ならびに、タプルの内容および入力イベントストリームＳを介してイベントを受信するときのさまざまな時点において複数の区画に適用される行‐時間範囲ウィンドウの内容を示す。
【０１２６】
【表２】
2019061712.tif 000005
【０１２７】
上記表Ｂにおいて、左の列はスキーマ（タイムスタンプ，ｃ１，ｃ２）を有するストリームＳを介して受信されたイベントのストリームを示す。タイムスタンプはミリ秒（ｍｓｅｃｓ）で示され、１秒＝１０００ｍｓｅｃｓである。一実施形態において、あるイベントに関連付けられたタイムスタンプは、このイベントの受信時の時間またはこのイベントの発生時の時間を表わし得る。表Ｂの右の列は、各区画について、さまざまな時点における、この区画のための行‐時間範囲ウィンドウの内容（すなわちイベント）を示す。イベントの前の「＋」表記は、そのイベントが区画のための行‐時間範囲ウィンドウに追加されたことを示すために使用される。イベントの前の「−」表記は、このイベントが、このイベントが満了したために、区画のための行‐時間範囲ウィンドウから削除されたことを示すために使用される。
【０１２８】
一実施形態において、イベントが受信されると、このイベントのための区画が決定される。このイベントの満了時間が計算される。イベントに対して計算される満了時間は、このイベントが満了しその区画のための行‐範囲ウィンドウから削除されることになる時間を示す。その後このイベントは、適切な区画のための行‐時間範囲ウィンドウに追加される。また、各区画のための行‐時間範囲ウィンドウが検査されて、この行‐時間範囲ウィンドウ内のいずれかのイベントを、このイベントが満了したためまたはＲＯＷＳ条件のために、ウィンドウから削除する必要があるか否か判断される。
【０１２９】
関連付けられたタイムスタンプが「ｔ」であり時間範囲または継続時間が「Ｔ」であるイベントの場合、このイベントの満了時間は（ｔ＋Ｔ）である。以下のクエリの場合、範囲の値は、受信したイベントの属性ｃ２の値に基づく。
【０１３０】
SELECT * from S [PARTITION BY c1 ROWS 2 RANGE c2]
したがって、受信したイベントについて、このイベントの満了時間は（ｔ＋ｃ２の値）である。上記表Ｂにおいて、各受信イベントの満了時間（expiration time）は、このイベ
ントの添え字として示されている。
【０１３１】
【数２】
2019061712.tif 000006
【０１３２】
表Ｂに示されるように、イベント（１０００，ａ，２）が受信される。さまざまな区画のための行‐時間範囲ウィンドウ（すなわち各区画のためのウィンドウが出力するリレーションセット）が検査されて、いずれかのイベントをそのイベントが満了しているので行‐時間範囲ウィンドウから削除する必要があるか否か判断される。表Ｂに示される例のために、さまざまな区画のための行‐時間範囲ウィンドウは、イベント（１０００，ａ，２）の到着前は空であると想定する。このイベントのｃ２属性の値に基づいて、このイベントは、属性値「ａ」に対応する区画（「Ｐａ」）のための行‐時間範囲ウィンドウ内に、２秒間留まることになっていると判断される。イベント（１０００，ａ，２）の満了時間は３秒標識（このイベントのタイムスタンプ＋ｃ２の値、すなわち１＋２＝３秒）であると計算される。次に、このイベント（１０００，ａ，２）は、Ｐａのための行‐時間範囲ウィンドウに追加される（「＋」で示される）。イベント（１０００，ａ，２）は、区画Ｐａのための行‐時間範囲ウィンドウ内に２秒間留まる資格がある。このイベントは、３秒標識の時点で（またはこの区画ウィンドウの「ＲＯＷＳ  ２」条件のためにそれよりも早く）行‐時間範囲ウィンドウから削除されることになっている。Ｐａのための行‐時間範囲ウィンドウはその後検査されて、いずれかのイベントを「ＲＯＷＳ  ２」条件のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。
【０１３３】
関連付けられたタイムスタンプ情報が同一であるイベント（１０００，ａ，９）が受信される。このイベントのｃ２属性の値に基づいて、このイベントはＰａのための行‐時間範囲ウィンドウ内に９秒間留まることになっていると判断される。このイベントの満了時間は１０秒標識（このイベントのタイムスタンプ＋ｃ２の値、すなわち１＋９＝１０秒）であると計算される。次に、このイベント（１０００，ａ，９）は、区画Ｐａのための行‐時間範囲ウィンドウに追加される（「＋」で示される）。イベント（１０００，ａ，９）は、区画Ｐａのための行‐時間範囲ウィンドウ内に９秒間留まる資格がある。このイベントは、１０秒標識の時点で（またはこの区画ウィンドウの「ＲＯＷＳ  ２」条件のためにそれよりも早く）行‐時間範囲ウィンドウから削除されることになっている。Ｐａのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント（１０００，ａ，９）を挿入して「ＲＯＷＳ  ２」条件を満たすようにしたために、行‐時間範囲ウ
ィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画Ｐａのための行‐時間範囲ウィンドウは、２つのイベント（１０００，ａ，２）および（１０００，ａ，９）を含む。
【０１３４】
次にイベント（２０００，ａ，１）が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。満了したイベントはないと判断される。上記イベントのｃ２属性の値に基づいて、このイベントはＰａのための行‐時間範囲ウィンドウ内に１秒間留まることになっていると判断される。イベント（ａ，１）の満了時間は３秒標識（このイベントのタイムスタンプ＋ｃ２の値、すなわち２＋１＝３）であると計算される。次に、このイベント（２０００，ａ，１）は、区画Ｐａのための行‐時間範囲ウィンドウに追加される（「＋」で示される）。イベント（２０００，ａ，１）は区画Ｐａのための行‐時間範囲ウィンドウ内に１秒間留まる資格がある。このイベントは、３秒標識の時点で（またはこの区画ウィンドウの「ＲＯＷＳ  ２」条件のためにそれよりも早く）行‐時間範囲ウィンドウから削除されることになっている。次に、Ｐａのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント（２０００，ａ，１）を挿入して「ＲＯＷＳ  ２」条件を満たすようにしたために、Ｐａのための行‐時間範囲ウィンドウから削除する必要があるか否か判断される。Ｐａのための行‐時間範囲ウィンドウの「ＲＯＷＳ  ２」条件のために、イベント（２０００，ａ，１）を追加したことによってイベント（１０００，ａ，２）は区画Ｐａのための行‐時間範囲ウィンドウから削除されることになり、区画Ｐａのための行‐時間範囲ウィンドウ内には、２つのイベント（１０００，ａ，９）および（２０００，ａ，１）が残される。
【０１３５】
次にイベント（３０００，ｂ，１）が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Ｐａのための行‐時間範囲ウィンドウ内のイベント（２０００，ａ，１）は満了しておりこのウィンドウから削除される（「−」で示される）と判断される。ｃ２属性の値に基づいて、イベント（３０００，ｂ，１）は、属性値「ｂ」に対応する区画（「Ｐｂ」）のための行‐時間範囲ウィンドウ内に、１秒間留まることになっていると判断される。イベント（３０００，ｂ，１）の満了時間は４秒標識（このイベントのタイムスタンプ＋ｃ２の値、すなわち３＋１＝４秒）であると計算される。次に、このイベント（３０００，ｂ，１）は、Ｐｂのための行‐時間範囲ウィンドウに追加される（「＋」で示される）。イベント（３０００，ｂ，１）は、区画Ｐｂのための行‐時間範囲ウィンドウ内に１秒間留まる資格がある。このイベントは、４秒標識の時点で（またはこの区画ウィンドウの「ＲＯＷＳ  ２」条件のためにそれよりも早く）行‐時間範囲ウィンドウから削除されることになっている。Ｐｂのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント（３０００，ｂ，１）を挿入して「ＲＯＷＳ  ２」条件を満たすようにしたために、行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画Ｐａのための行‐時間範囲ウィンドウはイベント（１０００，ａ，９）を含み、区画Ｐｂのための行‐時間範囲ウィンドウはイベント（３０００，ｂ，１）を含む。
【０１３６】
次に、関連付けられたタイムスタンプが同一である３つのイベント（４０００，ａ，２）、（４０００，ａ，３）および（４０００，ｂ，３）が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Ｐｂのための行‐時間範囲ウィンドウ内のイベント（３０００，ｂ，１）は満了しておりこのウィンドウから削除される（「−」で示される）と判断される。ｃ２属性の値に基づいて、イベント（４０００，ａ，２）は、Ｐａのための行‐時間範囲ウィンドウ内に２秒間留ま
ることになっていると判断される。イベント（４０００，ａ，２）の満了時間は６秒標識（このイベントのタイムスタンプ＋ｃ２の値、すなわち４＋２＝６秒）であると計算される。次に、このイベント（４０００，ａ，２）は、区画Ｐａのための行‐時間範囲ウィンドウに追加される（「＋」で示される）。イベント（ａ，２）は、区画Ｐａのための行‐時間範囲ウィンドウ内に２秒間留まる資格があり、６秒標識の時点で（またはこの区画ウィンドウの「ＲＯＷＳ  ２」条件のためにそれよりも早く）このウィンドウから削除されることになっている。Ｐａのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント（４０００，ａ，２）を挿入して「ＲＯＷＳ  ２」条件を満たすようにしたために、行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。
【０１３７】
イベント（４０００，ａ，３）について、ｃ２属性の値に基づいて、イベント（４０００，ａ，３）は、Ｐａのための行‐時間範囲ウィンドウ内に３秒間留まることになっていると判断される。イベント（４０００，ａ，３）の満了時間は７秒標識（このイベントのタイムスタンプ＋ｃ２の値、すなわち４＋３＝７秒）であると計算される。次に、このイベント（４０００，ａ，３）は、区画Ｐａのための行‐時間範囲ウィンドウに追加される（「＋」で示される）。イベント（４０００，ａ，３）は、区画Ｐａのための行‐時間範囲ウィンドウ内に３秒間留まる資格があり、７秒標識の時点で（またはこの区画ウィンドウの「ＲＯＷＳ  ２」条件のためにそれよりも早く）このウィンドウから削除されることになっている。次に、Ｐａのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント（４０００，ａ，３）を挿入して「ＲＯＷＳ  ２」条件を満たすようにしたために、Ｐａのための行‐時間範囲ウィンドウから削除する必要があるか否か判断される。イベント（４０００，ａ，３）を追加したことによってイベント（１０００，ａ，９）は区画Ｐａのための行‐時間範囲ウィンドウから削除されることになる（「−」で示される）。
【０１３８】
イベント（４０００，ｂ，３）について、ｃ２属性の値に基づいて、イベント（４０００，ｂ，３）は、区画Ｐｂのための行‐時間範囲ウィンドウ内に３秒間留まることになっていると判断される。イベント（４０００，ｂ，３）の満了時間は７秒標識（このイベントのタイムスタンプ＋ｃ２の値、すなわち４＋３＝７秒）であると計算される。次に、このイベント（４０００，ｂ，３）は、区画Ｐｂのための行‐時間範囲ウィンドウに追加される（「＋」で示される）。イベント（ｂ，３）は、区画Ｐｂのための行‐時間範囲ウィンドウ内に３秒間留まる資格があり、７秒標識の時点で（またはこの区画ウィンドウの「ＲＯＷＳ  ２」条件のためにそれよりも早く）このウィンドウから削除されることになっている。Ｐｂのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント（４０００，ｂ，３）を挿入して「ＲＯＷＳ  ２」条件を満たすようにしたために、この行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画Ｐａのための行‐時間範囲ウィンドウはイベント（４０００，ａ，２）および（４０００，ａ，３）を含み、区画Ｐｂのためのウィンドウはイベント（４０００，ｂ，３）を含む。
【０１３９】
次にイベント（５０００，ｂ，２）が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。満了したイベントはないと判断される。ｃ２属性の値に基づいて、このイベント（５０００，ｂ，２）は区画Ｐｂのための行‐時間範囲ウィンドウ内に２秒間留まることになっていると判断される。イベント（５０００，ｂ，２）の満了時間は７秒標識（このイベントのタイムスタンプ＋ｃ２の値、すなわち５＋２＝７）であると計算される。次に、イベント（５０００，ｂ，２）は、区画Ｐｂのための行‐時間範囲ウィンドウに追加される（「＋」で示される）。イベント（５０００，ｂ，２）は区画Ｐｂのための行‐時間範囲ウィンドウ内に２秒間留まる資格
があり、７秒標識の時点で（またはこの区画ウィンドウの「ＲＯＷＳ  ２」条件のためにそれよりも早く）このウィンドウから削除されることになっている。区画Ｐｂのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント（５００００，ｂ，２）を挿入して「ＲＯＷＳ  ２」条件を満たすようにしたために、行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画Ｐａのための行‐時間範囲ウィンドウはイベント（４０００，ａ，２）および（４０００，ａ，３）を含み、区画Ｐｂのための行‐時間範囲ウィンドウはイベント（４０００，ｂ，３）および（５０００，ｂ，２）を含む。
【０１４０】
次に、関連付けられたタイムスタンプが６０００ミリ秒であるハートビートイベントが受信される。一実施形態において、ハートビートイベントは、単に時間の経過情報を伝えるために使用される特殊な入力イベントである。ハートビートイベントには、他の属性の値はない。イベント処理システムを、システムのユーザによって構成できる周期的な間隔でハートビートを自動的に送信するように構成してもよい。そうすれば、ハートビートイベントは、その継続時間内に他の実際のイベントが受信されなければ（すなわちイベントストリームはその継続時間サイレント状態である）、自動的に生成され周期的な間隔で送信される。このハートビートイベントが受信されると、ウィンドウに関連する処理が実行される。したがって、ハートビートイベント（６０００，＜ｈｅａｒｔｂｅａｔ＿ｅｖｅｎｔ＞）が受信されたとき、さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントが満了しているので行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Ｐａのための行‐時間範囲ウィンドウ内のイベント（４０００，ａ，２）は満了しておりこのウィンドウから削除される（「−」で示される）と判断される。この時点で、区画Ｐａのための行‐時間範囲ウィンドウはイベント（４０００，ａ，３）を含み、区画Ｐｂのための行‐時間範囲ウィンドウはイベント（４０００，ｂ，３）および（５０００，ｂ，２）を含む。
【０１４１】
次にイベント（７０００，ｃ，１）が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Ｐａのための行‐時間範囲ウィンドウ内のイベント（４０００，ａ，３）ならびに区画Ｐｂのための行‐時間範囲ウィンドウ内のイベント（４０００，ｂ，３）および（５０００，ｂ，２）は満了しておりウィンドウから削除される（「−」で示される）と判断される。ｃ２属性の値に基づいて、イベント（７０００，ｃ，１）は、属性値「ｃ」に対応する区画（「Ｐｃ」）のための行‐時間範囲ウィンドウ内に、１秒間留まることになっていると判断される。イベント（７０００，ｃ，１）の満了時間は８秒標識（このイベントのタイムスタンプ＋ｃ２の値、すなわち７＋１＝８秒）であると計算される。次に、このイベント（７０００，ｃ，１）は、属性値「ｃ」に対応する区画Ｐｃのための行‐時間範囲ウィンドウに追加される（「＋」で示される）。イベント（７０００，ｃ，１）は、区画Ｐｃのための行‐時間範囲ウィンドウ内に１秒間留まる資格があり、８秒標識の時点で（またはこの区画ウィンドウの「ＲＯＷＳ  ２」条件のためにそれよりも早く）ウィンドウから削除されることになっている。区画Ｐｃのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント（７０００，ｃ，１）を挿入して「ＲＯＷＳ  ２」条件を満たすようにしたために、行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画ＰａおよびＰｂのための行‐時間範囲ウィンドウは空であり区画Ｐｃのための行‐時間範囲ウィンドウはイベント（７０００，ｃ，１）を含む。
【０１４２】
すべてのシステムがハートビートイベント送信機構を有する必要はないことに注意しなければならない。ハートビートイベントを送信しないシステムにおいて、ウィンドウに関連する処理は、イベントストリームを介して通常の入力イベントが受信されると実行され
る。たとえば、表Ｂに示されるイベントストリームの場合、ハートビートイベント送信機能がないシステムでは、６０００ミリ秒標識および７０００ミリ秒標識の時点で実行される処理は、新たなイベント（７０００，ｃ，１）が受信されたときに７０００ミリ秒標識の時点で実行されてもよい。
【０１４３】
次に、ハートビートイベント（８０００，＜ｈｅａｒｔｂｅａｔ＿ｅｖｅｎｔ＞）が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Ｐｃのための行‐時間範囲ウィンドウ内のイベント（７０００，ｃ，１）は満了しておりウィンドウから削除される（「−」で示される）と判断される。この時点で、区画Ｐａ、Ｐｂ、およびＰｃのための行‐時間範囲ウィンドウは空である。
【０１４４】
表Ｂに関して先に説明したように、入力イベントの受信時に実行される処理は、この入力イベントの満了時間を決定することと、このイベントが属する区画を決定することと、この入力イベントをこの区画のための行‐時間範囲ウィンドウに追加することと、さまざまな区画のための行‐時間範囲ウィンドウを検査して、満了したイベント、または、ＲＯＷＳ条件の結果として区画ウィンドウから除去する必要があるイベントを識別し削除する。ある区画のための行‐時間範囲ウィンドウ内に１つのイベントが留まる継続時間は、入力イベントの属性の関数であってもよく、これは異なる入力イベントごとに異なり得る。したがって、イベントがある区画のための行‐時間範囲ウィンドウ内に留まる資格がある継続時間は、異なるイベントごとに異なり得る。
【０１４５】
図５は、本発明の実施形態に従い、区画のための継続時間可変ウィンドウを管理するための方法を示す簡略化されたフローチャート５００を示す。図５に示される処理は、１つ以上のプロセッサによって実行されるソフトウェア（たとえばコード、命令、プログラム）で実施されてもよく、ハードウェアで実施されてもよく、またはその組合わせにおいて実施されてもよい。ソフトウェアは、メモリに（たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に）格納されていてもよい。図５に示される特定の一連の処理ステップは、限定を意図したものではない。
【０１４６】
ある実施形態において、図５に示される処理は、イベントストリームを介して入力イベント（実際のイベントまたはハートビートイベントであり得る）が受信される度に、連続クエリ実行の一部として実行されてもよい。５０２で、イベントストリーム内の入力イベント（タプル）が受信されてもよい。このイベントは、関連付けられた時間情報（たとえばタイムスタンプ）を有していてもよい。いくつかの例において、あるイベントに関連付けられた時間は、このイベントの受信時の時間を示すものであってもよい。
【０１４７】
５０４で、受信されたイベントについて、このイベントが区画のための行‐時間範囲ウィンドウ内に留まる資格がある継続時間が計算される。５０４の一部として、ＣＱＬコードによって行‐時間範囲ウィンドウに対して指定された範囲パラメータが決定され継続時間を決定するのに使用される。先に説明したように、いくつかの実施形態において、連続クエリは、この継続時間を、受信された入力イベントの１つ以上の属性の値の関数として定めてもよい。このようなシナリオにおいて、５０４で継続時間を決定することは、５０２で受信されたイベントの１つ以上の属性の値を決定することと、このイベントについての継続時間をこれら値の関数として計算することとを含み得る。継続時間の計算に使用される１つ以上の属性の値は、異なるイベントごとに異なり得るので、この継続時間は個々のイベントごとに異なる可能性がある。
【０１４８】
たとえば、ある実施形態において、この継続時間は、イベントの特定の属性の値に設定されてもよい。この特定の属性の値は、５０４で決定されてもよく、入力イベントに対す
る行‐時間範囲ウィンドウは、決定された値に設定される。他のいくつかの実施形態において、連続クエリは、行‐時間範囲ウィンドウの継続時間を、１つ以上の属性値に基づいて算術式として定めてもよい。このようなシナリオにおいて、５０４で、受信されたイベントの１つ以上の属性値が決定されてもよく、その後、決定された値を用いて算術式の値が求められ、それにより、受信されたイベントの継続時間が計算されてもよい。
【０１４９】
５０６で、受信されたイベントについて、５０４で決定された継続時間に基づいて満了時間が計算される。一実施形態において、
イベントの満了時間＝ｔ＋Ｔ
であり、「ｔ」は５０２で受信されたイベントに関連付けられた時間（たとえばイベントの到着時間）であり、「Ｔ」は５０４で決定された継続時間である。
【０１５０】
５０８で、５０６で計算された満了時間は、５０２で受信されたイベントに関連付けられてもよい。たとえば、満了時間情報を格納しておいて、ＥＰＳ１０２がイベントを与えられたときにこのイベントについて計算される満了時間を容易に求めることができるようにしてもよい。
【０１５１】
５１０で、既存の各区画について、この区画のための行‐時間範囲ウィンドウが検査されて、満了したイベントが識別され削除される。満了していると識別されたイベントについては、このイベントはその区画の行‐時間範囲ウィンドウから削除または除去される。一実施形態において、行‐時間範囲ウィンドウ内のイベントは、このイベントについて計算された満了時間が現在の時間と等しいかまたはそれよりも前であれば、満了しているとみなされる。上記のように、あるイベントの満了時間は（ｔ＋Ｔ）と計算される。したがって、現在の時間（ｔｐ）が（ｔ＋Ｔ）と同一かまたはそれよりも後であれば、イベントは、満了しているとみなされる。
【０１５２】
５１２で、５０２で受信された入力イベントについて区画が決定される。このイベントが属する区画は、このイベントの属性の値に応じて決まるものであってもよい。したがって、５１２で、受信された入力イベントについて、入力イベントストリームを区画に分割するために使用された属性の値が検査され、この値に基づいて、イベントが属する区画が求められる。
【０１５３】
５１４で、５０２で受信されたイベントが、５１２で決定された区画の行‐時間範囲ウィンドウに挿入または追加される。
【０１５４】
上記のように、以下の句
S [partition by A1,..., Ak rows N range T]
の場合、区画からのイベントの除去は、このイベントの満了時間に基づいて、または、行‐時間範囲ウィンドウ内のイベントの総数に基づいて制御される。たとえば、「...ｒｏ
ｗｓ  Ｎ...」は、最大「Ｎ」個のイベントを１つの区画のための行‐時間範囲ウィンド
ウ内に入れることが可能であることを意味し、新たなイベントが受信されてこのウィンドウに追加されたときに、「ｒｏｗｓ  Ｎ」という条件を満たすためにこの区画内の最も早いイベントが行‐時間範囲ウィンドウから削除される。したがって、５１６では、５１２で決定された区画のための行‐時間範囲ウィンドウが検査されて、「ｒｏｗｓ  Ｎ」条件を満たすためにイベントが識別され削除される。いくつかの実施形態において、５１６の処理は、５１４の処理よりも前に実行されてもよく、または、これに代えて、５１４および５１６で実行される処理は一緒に実行されてもよい。
【０１５５】
５１８で、処理はその後イベントストリーム内の次のイベントを待つ。次のイベントが受信されると、処理は５０２から繰り返される。
【０１５６】
図３に示され先に説明されたさまざまなモジュールは、本発明の実施形態に従う区画ベースで継続時間可変の時間ベースウィンドウ処理においても使用し得る。一実施形態において、継続時間および満了時間評価器モジュール３０２を、図５の５０２、５０４、５０６、および５０８の処理を実行するように適応させてもよい。時間ベースウィンドウオペレータモジュール３０４は、上記さまざまな機能に加えて、場合によっては複数の区画行‐時間範囲ウィンドウを管理するように適応させてもよい。たとえば、時間ベースウィンドウオペレータ３０４は、図５の５１０、５１２、５１４、および５１６に従う処理を実行するように構成されてもよい。
【０１５７】
さまざまなデータ構造を用いてさまざまな区画のための行‐時間範囲ウィンドウを実現してもよい。一実施形態において、一組の優先度キューが使用されてもよく、各優先度キューは、特定の区画のための行‐時間範囲ウィンドウに対応する。ある区画のための行‐時間範囲ウィンドウを表わす優先度キューにおいて、優先度は行‐時間範囲ウィンドウ内のイベントに対して計算された満了時間によって指示されてもよい。ある区画に属する、新たに受信されたイベントは、この区画のための優先度キューに追加される。ある区画について、満了したイベントおよび／または「ｒｏｗ  Ｎ」条件のために区画の行‐時間範囲ウィンドウから除去されるイベントは、対応する優先度キューから削除される。
【０１５８】
ある区画のためのキューの中において、このキューの中にあるイベントは、それぞれに関連付けられた満了時間に基づいてソートされてもよい。一実施形態において、イベントは、満了時間がより早いイベントがキューの先頭により近く満了時間がより遅いイベントがキューの末尾により近くなるように、ソートされる。どの時点でも、ある区画のための優先度キューは、その時点でその区画のためのウィンドウ内にあるゼロ以上のイベントを表わすゼロ以上のイベントを含み得る。
【０１５９】
図６は、本発明の実施形態に従い、優先度キューを用いて区画のための継続時間可変ウィンドウを扱うために時間ベースウィンドウオペレータ３０４が実行し得る処理を示す簡略化されたフローチャート６００を示す。図６に示される処理は、１つ以上のプロセッサによって実行されるソフトウェア（たとえばコード、命令、プログラム）で実施されてもよく、ハードウェアで実施されてもよく、またはその組合わせにおいて実施されてもよい。ソフトウェアは、メモリに（たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に）格納されていてもよい。図６に示される特定の一連の処理ステップは、限定を意図したものではない。
【０１６０】
６０２で、新たに受信された入力イベントは、関連付けられた満了時間とともに受信されてもよい。このイベントの満了時間は、継続時間および満了時間評価器３０２によって既に計算されていてもよい。
【０１６１】
６０４、６０６、６０８、６１０、６１４、および６１２による処理は、既存の各区画に対して実行される。６０４で、未処理の区画のための行‐時間範囲ウィンドウに対応する優先度キューがアクセスされる。６０６で、このキューが空か否か判断される。空のキューは、この区画の行‐時間範囲ウィンドウ内に現在イベントがないことを示す。６０６でキューが空であると判断された場合、処理は６１４に続き、６１４で、次の未処理の区画に対する処理が６０４から再び開始される。６０６でキューが空でないと判断された場合、処理は６０８に続く。
【０１６２】
６０８で、処理されている区画のための優先度キューの先頭にあるイベントがアクセスされる。この区画のための優先度キューの中にあるイベント要素は常に、これらイベントに関連付けられた満了時間に基づいてソートされ、満了時間がより早いイベントはキュー
の先頭により近く、満了時間がより遅いイベントはキューの末尾により近いので、キューの先頭にあるイベントは、その区画のウィンドウ内で満了時間が最も早いイベントを表わす。
【０１６３】
６１０で、６０８でアクセスされたイベントが満了しているか否か判断される。一実施形態において、アクセスされたイベントに関連付けられた満了時間が現在の時間に等しいかまたはそれよりも早い場合、このイベントは満了しているとみなされる。たとえば、現在の時間が１０秒の標識にあるとすると、アクセスされたイベントに関連付けられた満了時間が１０秒または１０秒未満であれば、このアクセスされたイベントは満了しているとみなされる。６１０で、アクセスされたイベントが満了していると判断された場合、６１２で、アクセスされたイベントはこの区画のための優先度キューから除去または削除され、処理は６０６に続く。６１０で、アクセスされたイベントが満了していないと判断された場合、処理は６１４に続く。このようにして、６０４、６０６、６０８、６１０、６１２、および６１４の処理は、さまざまな区画のための行‐時間範囲ウィンドウから、満了したイベントすべてが削除されるまで、繰り返される。その後処理は６１６に続く。
【０１６４】
６１６で、６０２で受信されたイベントに対し区画が決定される。このイベントのための区画は、入力されたイベントの属性の値に基づいて決定されてもよい。
【０１６５】
６１８で、６１６で決定された区画のための行‐時間範囲ウィンドウに対応する優先度キューがアクセスされる。６２０で、６１８でアクセスされた優先度キューにイベントが挿入または追加される。一実施形態において、キューの要素がこのキューの中のイベントに対して計算された満了時間に基づいてソートされた状態を保つように、イベントはこのイベントのために計算された満了時間に基づいて挿入されてもよい。
【０１６６】
ある実施形態において、ハッシュ関数を用いて、６１６で決定された特定の区画に対応するキューがアクセスされてもよい。入力イベントストリームを区画に分割するために使用された属性の値が入力としてハッシュ関数に与えられてもよく、そうすると、ハッシュ関数はその区画のための行‐時間範囲に対応するキューに対するリファレンス（たとえばポインタ）を返す。
【０１６７】
６２２で、６１８でアクセスされたキューが処理されて、「ｒｏｗｓ  Ｎ」条件を満たすためにキューのイベントが識別されキューから削除される。６２４で、処理は、イベントストリーム内の次のイベントを待つ。次のイベントが受信されると、処理は６０２から繰り返される。
【０１６８】
上記のやり方で、１つのイベントが時間ベースのウィンドウ内に留まる資格がある継続時間がイベントごとに異なるようにすることができる。さらにある実施形態において、あるイベントの継続時間は、このイベント自体の１つ以上の属性に基づくものでありかつこの１つ以上の属性の関数であってもよい。あるイベントが時間ベースのウィンドウ（通常の時間ベースのウィンドウまたは区画のための行‐時間範囲ウィンドウのいずれか）内に留まる資格がある継続時間は、イベントごとに異なるようにすることができ、したがってイベント固有のものである。
【０１６９】
イベントがそれぞれ異なる継続時間ベースのウィンドウ内に留まるという状況は、数通りある。１つの状況は、２つのイベントが同時に受信された場合（たとえば関連付けられたタイムスタンプが同一）、これらのイベントが時間ベースのウィンドウ内にある継続時間は互いに異なることがある。その結果、これら２つのイベントの満了時間も互いに異なることがある。たとえば、あるイベントストリームに対して、時間ベースのウィンドウの継続時間がこのストリームのためのスキーマ内の属性「ａｔｔｒ」の値の関数である、連
続クエリが定められる場合がある。２つのイベントのうち第１のイベント（ｅ１）が時間ｔ１で受信され第２のイベント（ｅ２）も時間ｔ１で受信される場合について考える。さらに、ｅ１の属性「ａｔｔｒ」の値がａ１でありｅ２の属性「ａｔｔｒ」の値がａ２でありａ２はａ１と同一でないと仮定する。そうすると次のようになる。
【０１７０】
ｅ１のための時間ベースのウィンドウの継続時間＝ａ１
ｅ１の満了時間＝ｔ１＋ａ１
ｅ２のための時間ベースのウィンドウの継続時間＝ａ２
ｅ２の満了時間＝ｔ１＋ａ２
ａ１とａ２は同一でないので、ｅ１の満了時間（すなわちｔ１＋ａ１）は、ｅ２の満了時間（すなわちｔ１＋ａ２）と同一ではない。このため、これら２つのイベントは同時に受信されているが（すなわち関連付けられた時間情報が同一）、２つのイベントは異なる２つの時間に満了し、したがってウィンドウ内に留まる継続時間が互いに異なる。これは、同時に受信した２つのイベントは常に同時にウィンドウから満了する、以前の時間ベースウィンドウの実装例では不可能であった。
【０１７１】
継続時間可変の時間ベースウィンドウのもう１つの状況として、先に受信されたイベントに関連付けられた満了時間が後に受信されたイベントに関連付けられた満了時間よりも遅い、すなわち言い換えると、後に受信されたイベントが先に受信されたイベントよりも早くウィンドウから満了する可能性がある。たとえば、上記例において、第１のイベント（ｅ１）が時間ｔ１に受信され第２のイベント（ｅ２）がｔ１よりも後のｔ２で受信されたとする。さらに、ｅ１の属性「ａｔｔｒ」の値がａ１でありｅ２の属性「ａｔｔｒ」の値がａ２であると仮定する。そうすると次のようになる。
【０１７２】
ｅ１のための時間ベースのウィンドウの継続時間＝ａ１
ｅ１の満了時間＝ｔ１＋ａ１
ｅ２のための時間ベースのウィンドウの継続時間＝ａ２
ｅ２の満了時間＝ｔ２＋ａ２
ｅ２の満了時間（すなわちｔ２＋ａ２）がｅ１の満了時間（すなわちｔ１＋ａ１）よりも前、すなわち（ｔ２＋ａ２）が（ｔ１＋ａ１）よりも前である可能性がある。したがって、イベントｅ２は後で到着したのにｅ１よりも前に満了する。これは、以前の時間ベースウィンドウの実装例では不可能であった。以前の実装例では、先に受信されたイベントは、常に後に受信されたイベントよりも前に満了し、その理由はこれら２つのイベントのウィンドウ継続時間が同一であるからである。
【０１７３】
継続時間可変の時間ベースウィンドウによって、ユーザは、あるイベントがウィンドウ内にある継続時間を制御することができ、この継続時間はイベントごとに異なるようにすることができる。これは、異なるさまざまな応用例において有益である。たとえば、製品関連情報に関するイベントのストリームを処理するように構成された応用例を考える。各製品の有効期間がそれぞれ異なるということが起こり得る（たとえば生鮮食品の有効期間は非生鮮食品の有効期間よりも短い）。製品の有効期間に基づいて時間ベースのウィンドウの継続時間を変える必要があるアプリケーションでは、ストリームのためのスキーマは、有効期間が属性としてスキーマに加えられるように指定されてもよい。そうすると、あるイベントのための時間ベースのウィンドウは、有効期間という属性によって特定される値に基づくことになるであろう。継続時間可変の時間ベースウィンドウを利用することができる他の応用例は、例として、関連付けられているアラームタイマがそれぞれ異なるタスクのためのイベントに関連する応用例、完了日がそれぞれ異なるタスクのためのイベントに関連する応用例などであるが、これらに限定されない。
【０１７４】
上記のように、あるイベントについてのウィンドウ継続時間は、このイベント自体の１
つ以上の属性に基づくものであってもよい。ある実施形態において、継続時間の基になる属性は、入力イベントストリームスキーマ自体の一部であってもよい。しかしながら、いくつかの実施形態において、このような属性は受信された入力ストリームの一部でなくてもよい。このような一実施形態において、ウィンドウの継続時間を決定するために使用される１つ以上の属性は、元のストリームから新たなストリームを導き出すことによってイベントストリームに追加されてもよく、継続時間計算の基になる１つ以上の属性は、導き出されたイベントストリームのスキーマの一部である。
【０１７５】
図７は、本発明の実施形態に従い使用し得るシステム環境７００の構成要素を示す簡略化されたブロック図である。図に示されているように、システム環境７００は、１つ以上のクライアント計算装置７０２、７０４、７０６、７０８を含み、これら装置は、ウェブブラウザ、専用のクライアント（たとえばOracle Forms）等のクライアントアプリケーションを操作するように構成されている。さまざまな実施形態において、クライアント計算装置７０２、７０４、７０６、および７０８は、イベント処理システム７１２と情報をやり取りし得る。
【０１７６】
クライアント計算装置７０２、７０４、７０６、７０８は、汎用のパーソナルコンピュータ（例として、さまざまなバージョンのMicrosoft Windows（登録商標）および／また
はApple Macintosh（登録商標）オペレーティングシステムを実行するパーソナルコンピ
ュータおよび／またはラップトップコンピュータを含む）、携帯電話もしくはＰＤＡ（Microsoft Windows Mobile等のソフトウェアを実行し、インターネット、電子メール、ＳＭＳ、ブラックベリー（Blackberry）（登録商標）、またはその他の通信プロトコルを使用可能）、および／またはさまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを含むがこれに限定されない）のいずれかを実行するワークステーションコンピュータであってもよい。これに代えて、クライアント計算装置７０２、７０４、７０６、および７０８は、ネットワーク（たとえば以下で説明するネットワーク７１０）を通して通信可能なシンクライアントコンピュータ、インターネットを使用可能なゲーム機、および／またはパーソナルメッセージングデバイス等のその他の電子デバイスであってもよい。典型的なシステム環境７００が４つのクライアント計算装置とともに示されているが、クライアント計算装置の数はいくつであってもそれらをサポートし得る。センサ等を有する装置のような他の装置が、システム７１２と情報をやり取りしてもよい。
【０１７７】
ネットワーク７１０は、クライアント７０２、７０４、７０６、および７０８とイベント処理システム７１２との間でのデータの通信および交換を容易にし得る。ネットワーク７１０は、ＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、ＡｐｐｌｅＴａｌｋ等を含むがこれらに限定されないさまざまな市販のプロトコルのいずれかを用いたデータ通信をサポートできる、当業者によく知られているネットワークであれば、どのような種類のネットワークであってもよい。単なる例として、ネットワーク７１０は、イーサネット（登録商標）ネットワーク、トークンリングネットワーク等のローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク、バーチャルプライベートネットワーク（ＶＰＮ）を含むがこれに限定されないバーチャルネットワーク、インターネット、イントラネット、エクストラネット、公衆電話交換回線網（ＰＳＴＮ）、赤外線ネットワーク、ワイヤレスネットワーク（たとえば、IEEE 802.1Xプロトコル群のいずれかの下で動作するネットワーク、当該技術
分野において公知のブルートゥース（登録商標）プロトコル、および／またはその他のワイヤレスプロトコル）、および／または、これらおよび／または他のネットワークの任意の組合わせであってもよい。
【０１７８】
イベント処理システム７１２は１つ以上のコンピュータおよび／またはサーバを含み得る。これは、汎用コンピュータ、専用のサーバコンピュータ（例として、ＰＣサーバ、Ｕ
ＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式（rack-mounted）のサーバ等を含む）、サーバファーム、サーバクラスタ、またはその他の適切な配置および／または組み合わせであってもよい。さまざまな実施形態において、システム７１２は、本願のこれまでの開示において説明された１つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされていてもよい。
【０１７９】
システム７１２は、上述したオペレーティングシステムのうちのいずれかおよび任意の市販のサーバオペレーティングシステムを含むオペレーティングシステムを実行してもよい。また、システム７１２は、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、Ｊａｖａサーバ、およびデータベースサーバ等を含むさまざまなその他のサーバアプリケーション、および／またはミッドティア（mid-tier）アプリケーションのうちのいずれかを実行してもよい。典型的なデータベースサーバは、Ｏｒａｃｌｅ、Ｍｉｃｒｏｓｏｆｔ、Ｓｙｂａｓｅ、ＩＢＭ等から市販されているものを含むが、これらに限定されない。
【０１８０】
また、システム環境７００は１つ以上のデータベース７１４および７１６を含み得る。データベース７１４および７１６はさまざまな場所に存在し得る。例として、データベース７１４および７１６のうちの１つ以上は、システム７１２に対してローカルな（および／またはシステム７１２内に常駐している）記録媒体に存在していてもよい。これに代えて、データベース７１４および７１６は、システム７１２から離れていてネットワークベースまたは専用回線を介してシステム７１２と通信してもよい。一組の実施形態において、データベース７１４および７１６は、当業者によく知られているストレージエリアネットワーク（ＳＡＮ）に存在していてもよい。同様に、システム７１２による機能を実行するために必要なファイルは、必要に応じて、システム７１２に対してローカルにおよび／または遠隔で格納されてもよい。一組の実施形態において、データベース７１４および７１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、更新し、取出すようにされている、Ｏｒａｃｌｅ  １１ｇ等のリレーショナルデータベースを含み得る。
【０１８１】
図８は、本発明のある実施形態に従い使用し得るコンピュータシステム８００の簡略化されたブロック図である。たとえば、システム８００を用いて図１に示されるイベント処理システム１００を実現してもよい。バス８２４を介して電気的に接続し得るさまざまな構成要素を含むコンピュータシステム８００が示されている。この構成要素は、１つ以上の処理部８０２と、入力サブシステム８０４と、出力サブシステム８０６と、記憶装置８０８と、コンピュータ読取可能な記録媒体８１０に接続されたコンピュータ読取可能記録媒体リーダ８１２と、通信サブシステム８１４と、処理加速サブシステム８１６と、ワーキングメモリ８１８とを含み得る。
【０１８２】
バスサブシステム８２４は、コンピュータシステム８００のさまざまな構成要素およびサブシステムを意図された通りに相互通信させるためのメカニズムを提供する。バスサブシステム８２４は概略的に１本のバスとして示されているが、これに代わるバスサブシステムの実施形態は複数のバスを利用してもよい。
【０１８３】
入力サブシステム８０４は、マウス、キーボード、ポインティングデバイス、タッチパッド等といった１つ以上の入力装置を含み得る。一般的に、入力サブシステム８０４は、コンピュータシステム８００に情報を入力するための装置またはメカニズムを含み得る。
【０１８４】
出力サブシステム８０６は、コンピュータシステム８００から情報を出力するための１つ以上の出力装置を含み得る。出力装置の例は、表示装置、プリンタ、投影装置等を含むがこれらに限定されない。一般的に、出力サブシステム８０６は、コンピュータシステム８００から情報を出力するための装置またはメカニズムを含み得る。
【０１８５】
処理部８０２は、１つ以上のプロセッサ、プロセッサの１つ以上のコア、およびその組み合わせ等を含み得る。いくつかの実施形態において、処理部８０２は、汎用一次プロセッサと、グラフィックプロセッサ、デジタル信号プロセッサ等といった１つ以上の専用コプロセッサとを含み得る。いくつかの実施形態において、処理部８０２のうちのいくつかまたはすべてを、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）のようなカスタマイズされた回路を用いて実現することができる。いくつかの実施形態において、このような集積回路は、回路そのものに格納された命令を実行する。他の実施形態において、処理部８０２は、ワーキングメモリ８１８にまたは記憶装置８０８に格納された命令を実行してもよい。さまざまな実施形態において、処理部８０２は、多様なプログラムまたはコード命令を実行することができ、現在実行している複数のプログラムまたはプロセスを管理することができる。どの時点でも、これから実行するプログラムコードのうちのいくつかまたはすべては、システムワーキングメモリ８１８、記憶装置８０８、および／またはコンピュータ読取可能な記録媒体８１０に常駐していてもよい。適切なプログラミングによって、処理部８０２は、イベントストリームに関連する処理を実行するための上記さまざまな機能を提供することができる。いくつかの実施形態において、コンピュータシステム８００はまた、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサ、および／またはそれと同様のものを含み得る処理加速部８１６を含んでいてもよい。
【０１８６】
記憶装置８０８は、ディスクドライブ、光学式記憶装置等のメモリデバイス、ならびに、プログラム可能で、一瞬で更新可能で（flash-updatable）、および／またはそれと同
じようなことが可能なランダムアクセスメモリ（ＲＡＭ）および／または読出専用メモリ（ＲＯＭ）等のソリッドステート記憶装置を含み得る。処理部８０２によって実行されると上記機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、記憶装置８０８に格納されてもよい。記憶装置８０８も、本発明の実施形態に従い使用されるデータを格納するためのリポジトリを提供し得る。
【０１８７】
コンピュータ読取可能記録媒体リーダ８１２はさらに、コンピュータ読取可能な記録媒体８１０に接続されてもよい。コンピュータ読取可能な記録媒体８１０はともに、（かつ任意に記憶装置８０８と組合わせて）リモート式、ローカル式、固定式および／または着脱交換式の記憶装置、および、一時的および／またはより永続的にコンピュータ読取可能な情報を収容するための記録媒体を総合的に意味している。
【０１８８】
通信サブシステム８１４によって、ネットワーク７１０および／またはシステム環境７００に関連する上述のその他のコンピュータと、データをやり取りすることが可能であってもよい。通信サブシステム８１４は、コンピュータシステム８００からの他のシステムからデータを受信しこのシステムにデータを送信するためのインターフェイスの役割を果たす。通信は、有線または無線プロトコルを用いて提供し得る。たとえば、通信サブシステム８１４によって、コンピュータ８００がインターネットを介してクライアント装置と接続できるようにしてもよい。通信サブシステム８１４は、モデム、ネットワークカード（無線または有線）、赤外線通信装置、ＧＰＳ受信機等を含み得る。
【０１８９】
ワーキングメモリサブシステム８１８は、プログラム実行中の命令およびデータの格納のためのメインランダムアクセスメモリ（ＲＡＭ）と、固定命令が格納される読出専用メモリ（ＲＯＭ）とを含み得る。オペレーティングシステム８２０および／またはアプリケーションプログラム（クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、ＲＤＢＭＳ等であってもよい）等のその他のコード８２２は、ワーキングメモリ８１８に格納されていてもよい。典型的な実施形態において、ワーキングメモリ８１８は、上記のようにイベントを処理し継続時間可変のウィンドウ処理を可能にするために使用される、実行可能なコードおよび関連するデータ構造（キャッシュ等）を含み得
る。
【０１９０】
コンピュータシステム８００の代替実施形態は、数多くの変形を伴う、上記構成要素よりも多いまたは少ない構成要素を有し得ることが、理解されるはずである。たとえば、カスタマイズされたハードウェアを使用してもよく、および／または特定の要素を、ハードウェア、ソフトウェア（アプレット等のポータブルソフトウェアを含む）、またはこれら双方で実現してもよい。さらに、ネットワーク入出力装置等の他の計算装置との接続を用いてもよい。
【０１９１】
図９は、本発明のある実施形態に従い使用し得る計算装置９００の簡略化されたブロック図である。計算装置９００のブロックを、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせにおいて実現することによって本発明の原理を実行してもよい。図９に示されるブロックを組合わせるまたはサブブロックに分離することによって上記本発明の原理を実行してもよいことが、当業者には理解される。したがって、本明細書での説明は、本明細書に記載の機能ブロックの可能な組み合わせまたは分離またはさらに他の定義を裏付け得るものである。
【０１９２】
図９に示されるように、示されている計算装置９００は、第１の決定部９０２および第２の決定部９０３を含む。任意で、計算装置９００は、受信部９０１、第１の除去部９０４、および第２の除去部９０５も含むことができる。
【０１９３】
一実施形態において、受信部９０１は、イベントストリームを介して第１のイベントおよび第２のイベントを受信するように構成し得る。第１の決定部９０２は、イベントストリームを介して受信した第１のイベントの第１の継続時間を決定するように構成し得る。第１の継続時間は、イベントストリームに対して指定された時間ベースのウィンドウ内に第１のイベントが留まる資格がある継続時間を示す。第２の決定部９０３は、イベントストリームを介して受信した第２のイベントの第２の継続時間を決定するように構成し得る。第２の継続時間は、時間ベースのウィンドウ内に第２のイベントが留まる資格がある継続時間を示す。第２の継続時間は第１の継続時間と異なっていてもよい。
【０１９４】
一実施形態において、第１の除去部９０４は、第１の時間イベントが時間ベースのウィンドウ内に第１の継続時間あった後に時間ベースのウィンドウから第１のイベントを除去するように構成し得る。第２の除去部９０５は、第２の時間イベントが時間ベースのウィンドウ内に第２の継続時間あった後に時間ベースのウィンドウから第２のイベントを除去するように構成し得る。
【０１９５】
一実施形態において、第１のイベントは関連付けられた第１の時間を有し、第２のイベントは関連付けられた第２の時間を有し、第１の時間は第２の時間と同一である。
【０１９６】
一実施形態において、第１のイベントは関連付けられた第１の時間を有し、第２のイベントは関連付けられた第２の時間を有し、第１の時間は第２の時間と異なる。
【０１９７】
一実施形態において、第１の決定部９０２は、第１の継続時間を決定するときに第１のイベントの１つ以上の属性の１つ以上の値に基づいて第１の継続時間を計算するように構成し得る。第２の決定部９０３は、第２の継続時間を決定するときに第２のイベントの１つ以上の属性の１つ以上の値に基づいて第２の継続時間を計算するように構成し得る。
【０１９８】
一実施形態において、第１の決定部９０２は、第１のイベントの第１の属性の値に基づいて、第１のイベントのための第１の区画を決定するように構成し得る。第２の決定部９０３は、第２のイベントの第１の属性の値に基づいて、第２のイベントが第１の区画に属
すると決定するように構成し得る。この時間ベースのウィンドウは第１の区画のためのものである。
【０１９９】
一実施形態において、第１の決定部９０２は、第１のイベントに関連付けられた第１の時間と第１の継続時間とに基づいて、第１のイベントの第１の満了時間を決定するように構成し得る。第２の決定部９０３は、第２のイベントに関連付けられ第２の時間と第２の継続時間とに基づいて、第２のイベントの第２の満了時間を決定するように構成し得る。第１の除去部９０４は、第１の満了時間の到来時または到来後に時間ベースのウィンドウから第１のイベントを除去するように構成し得る。第２の除去部９０５は、第２の満了時間の到来時または到来後に時間ベースのウィンドウから第２のイベントを除去するように構成し得る。
【０２００】
本発明の特定の実施形態について説明してきたが、さまざまな修正、変更、代替構成、および均等物も、本発明の範囲に包含される。本発明の実施形態は、ある特定のデータ処理環境内での動作に限定されるものではなく、複数のデータ処理環境内で自在に機能する。加えて、本発明の実施形態について、特定の一連のトランザクションおよびステップを用いて説明してきたが、本発明の範囲が、記載されている一連のトランザクションおよびステップに限定されないことは、当業者には明らかなはずである。
【０２０１】
さらに、本発明の実施形態について、ハードウェアとソフトウェアの特定の組み合わせを用いて説明してきたが、ハードウェアとソフトウェアの他の組合わせも本発明の範囲内であることが認識されるはずである。本発明の実施形態は、ハードウェアのみで実現されてもよく、ソフトウェアのみで実現されてもよく、これらの組合わせを用いて実現されてもよい。本明細書に記載のさまざまなプロセスは、同一のプロセッサ上で実現されてもよく、または任意に組合わされた異なるプロセッサ上で実現されてもよい。したがって、構成要素またはモジュールが、特定の動作を実行するように構成されているという記載があった場合、このような構成は、たとえば、電子回路をこの動作を実行するように設計することによって、または、プログラム可能な電子回路（マイクロプロセッサ等）をこの動作を実行するようにプログラムすることによって、または、これらを任意に組合わせて実現することができる。プロセスは従来のプロセス間通信の技術を含むがこれに限定されないさまざまな技術を用いて通信することができ、異なるプロセス対は異なる技術を使用してもよく、または、同一のプロセス対が異なる技術を異なる時間に使用してもよい。
【０２０２】
明細書および図面はしたがって、限定的な意味ではなく例示的な意味で考慮されねばならない。しかしながら、これに対し、追加、控除、削除、およびその他の修正および変更を、請求項に記載のより広い精神および範囲から逸脱することなく行ない得ることは明らかであろう。このように、具体的な発明の実施形態について説明してきたが、これは限定を意図したものではない。さまざまな変形および均等物は以下の請求項の範囲に含まれる。
【図１】
2019061712.tif 000007
【図２】
2019061712.tif 000008
【図３】
2019061712.tif 000009
【図４】
2019061712.tif 000010
【図５】
2019061712.tif 000011
【図６】
2019061712.tif 000012
【図７】
2019061712.tif 000013
【図８】
2019061712.tif 000014
【図９】
2019061712.tif 000015
【手続補正書】
【提出日】平成30年12月18日(2018.12.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
受信するイベントをリアルタイムで処理する方法であって、
イベントストリームを介して受信した第１のイベントの第１の継続時間を計算装置によって決定することを含み、前記第１の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第１のイベントが留まる資格がある第１の時間量を示し、前記時間ベースのウィンドウは前記イベントストリームに対して指定されたクエリであって、受信するイベントをリアルタイムで処理できる形態を有するクエリによってクエリされる資格がある前記イベントストリームの一組のイベントを特定し、
前記イベントストリームを介して受信した第２のイベントの第２の継続時間を前記計算装置によって決定することを含み、前記第２の継続時間は、前記時間ベースのウィンドウ内に前記第２のイベントが留まる資格がある第２の時間量を示し、前記第２の時間量は前記第１の時間量と異なっており、
前記クエリが実行されるときに前記時間ベースのウィンドウ内にある前記イベントストリームを介して受信した一組のイベントに対する前記クエリを前記計算装置によって繰返し実行することを含む、方法。
【請求項２】
前記第１のイベントが前記時間ベースのウィンドウ内に前記第１の時間量の間留まった後に、前記第１のイベントを前記時間ベースのウィンドウから前記計算装置によって除去することと、
前記第２のイベントが前記時間ベースのウィンドウ内に前記第２の時間量の間留まった後に、前記第２のイベントを前記時間ベースのウィンドウから前記計算装置によって除去することとをさらに含む、請求項１に記載の方法。
【請求項３】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と同一である、請求項１または２に記載の方法。
【請求項４】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と異なる、請求項１または２に記載の方法。
【請求項５】
前記第１の継続時間を決定することは、前記第１のイベントの１つ以上の属性の１つ以上の値に基づいており、
前記第２の継続時間を決定することは、前記第２のイベントの１つ以上の属性の１つ以上の値に基づいている、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
前記第１のイベントの第１の属性の値に基づいて前記第１のイベントのための第１の区画を決定することと、
前記第２のイベントの第１の属性の値に基づいて前記第２のイベントが前記第１の区画に属すると決定することとをさらに含み、
前記時間ベースのウィンドウは前記第１の区画のためのものである、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記第１のイベントに関連付けられた第１の時間と前記第１の継続時間とに基づいて前記第１のイベントの第１の満了時間を前記計算装置によって決定することと、
前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のイベントの第２の満了時間を前記計算装置によって決定することと、
前記第１の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第１のイベントを除去することと、
前記第２の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第２のイベントを除去することとをさらに含む、請求項１〜６のいずれか一項に記載の方法。
【請求項８】
前記第１の継続時間を決定することは、前記イベントストリームに対して指定されたクエリに基づいており、前記第２の継続時間を決定することは、前記イベントストリームに対して指定されたクエリに基づいている、請求項１〜７のいずれか一項に記載の方法。
【請求項９】
前記クエリは、前記イベントストリームを介して受信した各イベントについて継続時間をどのように計算すべきか示す式を指定し、前記第１の継続時間を決定することは前記式の値を求めることを含み、前記第２の継続時間を決定することは前記式の値を求めることを含む、請求項８に記載の方法。
【請求項１０】
前記式は、前記イベントストリームを介して受信した各イベントの１つ以上の属性の１つ以上の値に基づいている、請求項９に記載の方法。
【請求項１１】
計算装置であって、
メモリと、
一組の処理部とを備え、前記一組の処理部のうちの１つ以上の処理部であって、受信するイベントをリアルタイムで処理する処理部は、
イベントストリームを介して受信した第１のイベントの第１の継続時間を決定するように適合され、前記第１の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第１のイベントが留まる資格がある第１の時間量を示し、前記時間ベースのウィンドウは前記イベントストリームに対して指定されたクエリであって、受信するイベントをリアルタイムで処理できる形態を有するクエリによってクエリされる資格がある前記イベントストリームの一組のイベントを特定し、
前記イベントストリームを介して受信した第２のイベントの第２の継続時間を決定するように適合され、前記第２の継続時間は、前記時間ベースのウィンドウ内に前記第２のイベントが留まる資格がある第２の時間量を示し、前記第２の時間量は前記第１の時間量と異なっており、
前記クエリが実行されるときに前記時間ベースのウィンドウ内にある前記イベントストリームを介して受信した一組のイベントに対する前記クエリを繰返し実行するように適合される、計算装置。
【請求項１２】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１のイベントが前記時間ベースのウィンドウ内に前記第１の時間量の間留まった後に、前記第１のイベントを前記時間ベースのウィンドウから除去するように適合され、
前記第２のイベントが前記時間ベースのウィンドウ内に前記第２の時間量の間留まった後に、前記第２のイベントを前記時間ベースのウィンドウから除去するように適合される、請求項１１に記載の計算装置。
【請求項１３】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と同一である、請求項１１または１２に記載の計算装置。
【請求項１４】
前記第１のイベントは関連付けられた第１の時間を有し、
前記第２のイベントは関連付けられた第２の時間を有し、
前記第１の時間は前記第２の時間と異なる、請求項１１または１２に記載の計算装置。
【請求項１５】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１のイベントの１つ以上の属性の１つ以上の値に基づいて前記第１の継続時間を決定するように適合され、
前記第２のイベントの１つ以上の属性の１つ以上の値に基づいて前記第２の継続時間を決定するように適合される、請求項１１〜１４のいずれか一項に記載の計算装置。
【請求項１６】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１のイベントの第１の属性の値に基づいて前記第１のイベントのための第１の区画を決定するように適合され、
前記第２のイベントの第１の属性の値に基づいて前記第２のイベントが前記第１の区画に属すると決定するように適合され、
前記時間ベースのウィンドウは前記第１の区画のためのものである、請求項１１〜１５のいずれか一項に記載の計算装置。
【請求項１７】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１のイベントに関連付けられた第１の時間と前記第１の継続時間とに基づいて前記第１のイベントの第１の満了時間を決定するように適合され、
前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のイベントの第２の満了時間を決定するように適合され、
前記第１の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第１のイベントを除去するように適合され、
前記第２の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第２のイベントを除去するように適合される、請求項１１〜１６のいずれか一項に記載の計算装置。
【請求項１８】
１つ以上の処理部によって実行可能な複数の命令を格納するコンピュータ読取可能なプログラムであって、前記複数の命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、受信するイベントをリアルタイムで処理させる命令であって、
イベントストリームを介して受信した第１のイベントの第１の継続時間を決定させる命令を含み、前記第１の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第１のイベントが留まる資格がある第１の時間量を示し、前記時間ベースのウィンドウは前記イベントストリームに対して指定されたクエリであって、受信するイベントをリアルタイムで処理できる形態を有するクエリによってクエリされる資格がある前記イベントストリームの一組のイベントを特定し、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記イベントストリームを介して受信した第２のイベントの第２の継続時間を決定させる命令を含み、前記第２の継続時間は、前記時間ベースのウィンドウ内に前記第２のイベントが留まる資格がある第２の時間量を示し、前記第２の時間量は前記第１の時間量と異なっており、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記クエリが実行されるときに前記時間ベースのウィンドウ内にある前記イベントストリームを介して受信した一組のイベントに対する前記クエリを繰返し実行させる命令を含む、コンピュータ読取可能なプログラム。
【請求項１９】
受信するイベントをリアルタイムで処理するシステムであって、
イベントストリームを介して受信した第１のイベントの第１の継続時間を決定するための手段を備え、前記第１の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第１のイベントが留まる資格がある第１の時間量を示し、前記時間ベースのウィンドウは前記イベントストリームに対して指定されたクエリであって、受信するイベントをリアルタイムで処理できる形態を有するクエリによってクエリされる資格がある前記イベントストリームの一組のイベントを特定し、
前記イベントストリームを介して受信した第２のイベントの第２の継続時間を決定するための手段を備え、前記第２の継続時間は、前記時間ベースのウィンドウ内に前記第２のイベントが留まる資格がある第２の時間量を示し、前記第２の時間量は前記第１の時間量と異なっており、
前記クエリが実行されるときに前記時間ベースのウィンドウ内にある前記イベントストリームを介して受信した一組のイベントに対する前記クエリを繰返し実行するための手段を備える、システム。
【外国語明細書】
2019061712000001.pdf