(57)【要約】      （修正有）【課題】可変の継続時間を用いて連続イベントストリームに対しイベントなしパターンマッチングを実行する。【解決手段】イベントなしパターンマッチングで使用される継続時間の値は、変化させることができる。したがって、イベントストリームを介して受信したイベントから発生するマッチに対して、第１のパターンマッチ候補に関連付けられる継続時間を、第２のパターンマッチ候補に関連付けられる継続時間とは異なるようにすることができる。候補パターンマッチについての継続時間は、この候補パターンマッチを開始させたイベントの１つ以上の属性に基づいていてもよく、または、イベントの１つ以上の属性を含む式（たとえば算術式）に基づいていてもよい。【選択図】図１
2019125383.tif 000002
【特許請求の範囲】
【請求項１】
方法であって、
計算装置によって、イベントストリームを介して前記計算装置が受信した第１のイベントがパターンに対する第１のパターンマッチ候補を開始させると決定することと、
前記計算装置によって、前記第１のパターンマッチ候補についての第１の継続時間を計算することと、
前記計算装置によって、前記イベントストリームを介して受信した第２のイベントが前記パターンに対する第２のパターンマッチ候補を開始させると決定することと、
前記計算装置によって、前記第２のパターンマッチ候補についての第２の継続時間を計算することとを含み、前記第２の継続時間は前記第１の継続時間とは異なる、方法。
【請求項２】
前記第１のイベントおよび前記第２のイベントは属性を含み、
前記第１の継続時間を計算することは、
前記第１のイベントの属性の第１の値を決定することと、
前記第１の値を用いて前記第１の継続時間を計算することとを含み、
前記第２の継続時間を計算することは、
前記第２のイベントの属性の第２の値を決定することを含み、前記第２の値は前記第１の値とは異なり、
前記第２の値を用いて前記第２の継続時間を計算することを含む、請求項１に記載の方法。
【請求項３】
前記第１のイベントおよび前記第２のイベントは属性を含み、
前記第１の継続時間を計算することは、
前記第１のイベントの属性の第１の値を決定することと、
前記第１の値を用いて式を評価することにより前記第１の継続時間を計算することとを含み、
前記第２の継続時間を計算することは、
前記第２のイベントの属性の第２の値を決定することを含み、前記第２の値は前記第１の値とは異なり、
前記第２の値を用いて式を評価することにより前記第２の継続時間を計算することを含む、請求項１に記載の方法。
【請求項４】
前記第１のイベントについての前記第１の継続時間の経過後に、前記第１のパターンマッチ候補が前記パターンとマッチしているか否か決定することと、
前記第１のパターンマッチ候補が前記パターンとマッチしていると決定したときに、前記第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力することとをさらに含む、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記第１のイベントに関連付けられた第１の時間と前記第１の継続時間とに基づいて前記第１のパターンマッチ候補についての第１の終了時間を決定することと、
前記第１の終了時間を前記第１のパターンマッチ候補に関連付けることと、
前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のパターンマッチ候補についての第２の終了時間を決定することと、
前記第２の終了時間を前記第２のパターンマッチ候補に関連付けることとをさらに含む、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
前記第１の終了時間を、前記第１のイベントに関連付けられた第１の時間に前記第１の継続時間を加算することによって決定することと、
前記第２の終了時間を、前記第２のイベントに関連付けられた第２の時間に前記第２の
継続時間を加算することによって決定することとをさらに含む、請求項５に記載の方法。
【請求項７】
前記第１のパターンマッチ候補に関連付けられた前記第１の終了時間以降に、前記第１のパターンマッチ候補が前記パターンとマッチしているか否か決定することと、
前記第１のパターンマッチ候補が前記パターンとマッチしていると決定したときに、前記第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力することとをさらに含む、請求項５に記載の方法。
【請求項８】
計算装置であって、
メモリと、
一組の処理部とを備え、前記一組の処理部のうちの１つ以上の処理部は、
イベントストリームを介して前記計算装置が受信した第１のイベントがパターンに対する第１のパターンマッチ候補を開始させると決定するように適合され、
前記第１のパターンマッチ候補についての第１の継続時間を計算するように適合され、
前記イベントストリームを介して受信した第２のイベントが前記パターンに対する第２のパターンマッチ候補を開始させると決定するように適合され、
前記第２のパターンマッチ候補についての第２の継続時間を計算するように適合され、前記第２の継続時間は前記第１の継続時間とは異なる、計算装置。
【請求項９】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１のイベントの属性の第１の値を決定するように適合され、
前記第１の値を用いて前記第１の継続時間を計算するように適合され、
前記第２のイベントの属性の第２の値を決定するように適合され、前記第２の値は前記第１の値とは異なり、
前記第２の値を用いて前記第２の継続時間を計算するように適合される、請求項８に記載の計算装置。
【請求項１０】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１のイベントの属性の第１の値を決定するように適合され、
前記第１の値を用いて式を評価することにより前記第１の継続時間を計算するように適合され、
前記第２のイベントの属性の第２の値を決定するように適合され、前記第２の値は前記第１の値とは異なり、
前記第２の値を用いて式を評価することにより前記第２の継続時間を計算するように適合される、請求項８に記載の計算装置。
【請求項１１】
前記一組の処理部のうちの１つ以上の処理部はさらに、
前記第１のイベントについての前記第１の継続時間の経過後に、前記第１のパターンマッチ候補が前記パターンとマッチしているか否か決定するように適合され、
前記第１のパターンマッチ候補が前記パターンとマッチしていると決定したときに、前記第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するように適合される、請求項８〜１０のいずれか一項に記載の計算装置。
【請求項１２】
前記一組の処理部のうちの１つ以上の処理部はさらに、
前記第１のイベントに関連付けられた第１の時間と前記第１の継続時間とに基づいて前記第１のパターンマッチ候補についての第１の終了時間を決定するように適合され、
前記第１の終了時間を前記第１のパターンマッチ候補に関連付けるように適合され、
前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のパターンマッチ候補についての第２の終了時間を決定するように適合され、
前記第２の終了時間を前記第２のパターンマッチ候補に関連付けるように適合される、請求項８〜１１のいずれか一項に記載の計算装置。
【請求項１３】
前記一組の処理部のうちの１つ以上の処理部は、
前記第１の終了時間を、前記第１のイベントに関連付けられた第１の時間に前記第１の継続時間を加算することによって決定するように適合され、
前記第２の終了時間を、前記第２のイベントに関連付けられた第２の時間に前記第２の継続時間を加算することによって決定するように適合される、請求項１２に記載の計算装置。
【請求項１４】
前記一組の処理部のうちの１つ以上の処理部はさらに、
前記第１のパターンマッチ候補に関連付けられた前記第１の終了時間以降に、前記第１のパターンマッチ候補が前記パターンとマッチしているか否か決定するように適合され、
前記第１のパターンマッチ候補が前記パターンとマッチしていると決定したときに、前記第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するように適合される、請求項１２に記載の計算装置。
【請求項１５】
１つ以上の処理部によって実行可能な複数の命令を格納するコンピュータ読取可能なメモリであって、前記複数の命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、イベントストリームを介して受信した第１のイベントがパターンに対する第１のパターンマッチ候補を開始させると決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のパターンマッチ候補についての第１の継続時間を計算させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記イベントストリームを介して受信した第２のイベントが前記パターンに対する第２のパターンマッチ候補を開始させると決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２のパターンマッチ候補についての第２の継続時間を計算させる命令とを含み、前記第２の継続時間は前記第１の継続時間とは異なる、コンピュータ読取可能なメモリ。
【請求項１６】
前記１つ以上の処理部のうちの少なくとも１つの処理部に前記第１の継続時間を計算させる命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のイベントの属性の第１の値を決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１の値を用いて前記第１の継続時間を計算させる命令とを含み、
前記１つ以上の処理部のうちの少なくとも１つの処理部に前記第２の継続時間を計算させる命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２のイベントの属性の第２の値を決定させる命令を含み、前記第２の値は前記第１の値とは異なり、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２の値を用いて前記第２の継続時間を計算させる命令を含む、請求項１５に記載のコンピュータ読取可能なメモリ。
【請求項１７】
前記１つ以上の処理部のうちの少なくとも１つの処理部に前記第１の継続時間を計算させる命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のイベントの属性の第１の値を決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１の値を用いて式を評価することにより前記第１の継続時間を計算させる命令とを含み、
前記１つ以上の処理部のうちの少なくとも１つの処理部に前記第２の継続時間を計算させる命令は、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２のイベントの属性の第２の値を決定させる命令を含み、前記第２の値は前記第１の値とは異なり、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２の値を用いて式を評価することにより前記第２の継続時間を計算させる命令を含む、請求項１５に記載のコンピュータ読取可能なメモリ。
【請求項１８】
前記複数の命令はさらに、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のイベントについての前記第１の継続時間の経過後に、前記第１のパターンマッチ候補が前記パターンとマッチしているか否か決定させる命令と、
前記第１のパターンマッチ候補が前記パターンとマッチしていると決定したときに、前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力させる命令とを含む、請求項１５〜１７のいずれか一項に記載のコンピュータ読取可能なメモリ。
【請求項１９】
前記複数の命令はさらに、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のイベントに関連付けられた第１の時間と前記第１の継続時間とに基づいて前記第１のパターンマッチ候補についての第１の終了時間を決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１の終了時間を前記第１のパターンマッチ候補に関連付けさせる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のパターンマッチ候補についての第２の終了時間を決定させる命令と、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２の終了時間を前記第２のパターンマッチ候補に関連付けさせる命令とを含む、請求項１５〜１８のいずれか一項に記載のコンピュータ読取可能なメモリ。
【請求項２０】
前記１つ以上の処理部のうちの少なくとも１つの処理部に前記第１の終了時間を決定させる命令は、前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１の終了時間を、前記第１のイベントに関連付けられた第１の時間に前記第１の継続時間を加算することによって決定させる命令を含み、
前記１つ以上の処理部のうちの少なくとも１つの処理部に前記第２の終了時間を決定させる命令は、前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第２の終了時間を、前記第２のイベントに関連付けられた第２の時間に前記第２の継続時間を加算することによって決定させる命令を含む、請求項１９に記載のコンピュータ読取可能なメモリ。
【請求項２１】
前記複数の命令はさらに、
前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のパターンマッチ候補に関連付けられた前記第１の終了時間以降に、前記第１のパターンマッチ候補が前記パターンとマッチしているか否か決定させる命令と、
前記第１のパターンマッチ候補が前記パターンとマッチしていると決定したときに、前記１つ以上の処理部のうちの少なくとも１つの処理部に、前記第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力させる命令とを含む、請求項１９に記載のコンピュータ読取可能なメモリ。
【請求項２２】
装置であって、
イベントストリームを介して計算装置が受信した第１のイベントがパターンに対する第１のパターンマッチ候補を開始させると決定するための手段と、
前記第１のパターンマッチ候補についての第１の継続時間を計算するための手段と、
前記イベントストリームを介して受信した第２のイベントが前記パターンに対する第２のパターンマッチ候補を開始させると決定するための手段と、
前記第２のパターンマッチ候補についての第２の継続時間を計算するための手段とを備え、前記第２の継続時間は前記第１の継続時間とは異なる、装置。
【請求項２３】
前記第１のイベントおよび前記第２のイベントは属性を含み、
前記第１の継続時間を計算するための手段は、
前記第１のイベントの属性の第１の値を決定するための手段と、
前記第１の値を用いて前記第１の継続時間を計算するための手段とを備え、
前記第２の継続時間を計算するための手段は、
前記第２のイベントの属性の第２の値を決定するための手段を備え、前記第２の値は前記第１の値とは異なり、
前記第２の値を用いて前記第２の継続時間を計算するための手段を備える、請求項２２に記載の装置。
【請求項２４】
前記第１のイベントおよび前記第２のイベントは属性を含み、
前記第１の継続時間を計算するための手段は、
前記第１のイベントの属性の第１の値を決定するための手段と、
前記第１の値を用いて式を評価することにより前記第１の継続時間を計算するための手段とを備え、
前記第２の継続時間を計算するための手段は、
前記第２のイベントの属性の第２の値を決定するための手段を備え、前記第２の値は前記第１の値とは異なり、
前記第２の値を用いて式を評価することにより前記第２の継続時間を計算するための手段を備える、請求項２２に記載の装置。
【請求項２５】
前記第１のイベントについての前記第１の継続時間の経過後に、前記第１のパターンマッチ候補が前記パターンとマッチしているか否か決定するための手段と、
前記第１のパターンマッチ候補が前記パターンとマッチしていると決定したときに、前記第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するための手段とをさらに備える、請求項２２〜２４のいずれか一項に記載の装置。
【請求項２６】
前記第１のイベントに関連付けられた第１の時間と前記第１の継続時間とに基づいて前記第１のパターンマッチ候補についての第１の終了時間を決定するための手段と、
前記第１の終了時間を前記第１のパターンマッチ候補に関連付けるための手段と、
前記第２のイベントに関連付けられた第２の時間と前記第２の継続時間とに基づいて前記第２のパターンマッチ候補についての第２の終了時間を決定するための手段と、
前記第２の終了時間を前記第２のパターンマッチ候補に関連付けるための手段とをさらに備える、請求項２２〜２５のいずれか一項に記載の装置。
【請求項２７】
前記第１の終了時間を、前記第１のイベントに関連付けられた第１の時間に前記第１の継続時間を加算することによって決定するための手段と、
前記第２の終了時間を、前記第２のイベントに関連付けられた第２の時間に前記第２の継続時間を加算することによって決定するための手段とをさらに備える、請求項２６に記載の装置。
【請求項２８】
前記第１のパターンマッチ候補に関連付けられた前記第１の終了時間以降に、前記第１のパターンマッチ候補が前記パターンとマッチしているか否か決定するための手段と、
前記第１のパターンマッチ候補が前記パターンとマッチしていると決定したときに、前記第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するための手段とをさらに備える、請求項２６に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本願は、２０１３年１月１５日に出願され「VARIABLE DURATION NON EVENT PATTERN MATCHING（継続時間可変イベントなしパターンマッチング）」と題された米国仮出願第６１／７５２，８５５号に基づく利益および優先権を主張する。本願はまた、米国仮出願第６１／７５２，８５５号に基づく優先権を主張する２０１３年３月１５日に出願され「VARIABLE DURATION NON-EVENT PATTERN MATCHING」と題された米国本出願第１３／８３９，２８８号に基づく利益および優先権を主張する。出願第６１／７５２，８５５号および第１３／８３９，２８８号の内容全体をすべての目的のために本明細書に引用により援用する。
【背景技術】
【０００２】
背景
開示されている実施形態は、概してデータ処理システムに関し、より具体的には継続時間可変機能を用いて連続イベントストリームに対しイベントなしパターンマッチングを実行するための技術に関する。
【０００３】
従来のデータベースシステムにおいて、データは、通常はテーブルの形態で１つ以上のデータベースに格納される。格納されたデータはその後、ＳＱＬ等のデータ管理言語を用いてクエリされ操作される。たとえば、ＳＱＬクエリは、データベースに格納されているデータのうちの関連データを識別するために定義し実行することができる。したがって、ＳＱＬクエリは、データベースに格納されている有限集合のデータに対して実行される。さらに、ＳＱＬクエリが実行されるとき、ＳＱＬは有限のデータ集合に対して一度実行されて有限の静的結果をもたらす。このように、データベースは、格納されている有限のデータ集合に対してクエリが実行されるよう最適に作成されている。
【０００４】
しかしながら、数多くの現代のアプリケーションおよびシステムは、データを、有限のデータ集合ではなく連続データまたはイベントストリームの形態で生成する。このようなアプリケーションの例は、センサデータアプリケーション、財務表示機、ネットワークパフォーマンス測定ツール（たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリング等を含むが、これらに限定されない。たとえば、温度センサを、温度測定値を発信するように構成することができる。このようなアプリケーションから、データストリームを処理することが可能な新たな種類のアプリケーションの必要性が生じた。
【０００５】
イベントストリームに基づくこれらの種類のアプリケーションの場合のデータの管理および処理は、時間を強く重視してデータ管理およびクエリ機能を構築することを含む。連続する無限のデータ集合に対する長時間のクエリ実行を含む、異なる種類のクエリ機構が必要である。現在イベントストリーム処理に適した製品一式を提供している販売業者はあるが、これら製品が提供するものは依然として、現代のイベント処理のニーズに対処するのに必要な処理の柔軟性に欠けている。
【発明の概要】
【課題を解決するための手段】
【０００６】
簡単な概要
可変の継続時間を用いて連続イベントストリームに対しイベントなしパターンマッチングを実行するためのある実施形態が開示される。この実施形態は、さまざまな技術、たと
えば、イベントデータストリームに対して機能する、コンピュータによって実施される方法、イベントデータストリームを処理する計算機、システム、または装置、１つ以上の処理部によって実行可能な複数の命令を格納するコンピュータ読取可能なメモリなどを用いて実施される技術を含み得る。
【０００７】
イベント処理エンジンのパターンマッチング機能に関して、イベントなし検出とは、特定の時間枠内で生じるはずである何らかのイベントがこの時間枠内で生じないときの状況を検出することを意味する。たとえば、イベントが特定の順序で生じるというシナリオでは、イベントなし検出を用いて、特定の時間枠内においてこの順序で次に生じることになっている特定のイベントがこの時間枠内で起こらないという状況を、検出することができる。
【０００８】
イベントなしをベースにしたパターンマッチングでは、イベントの到来によってパターンマッチ候補（バインディングと呼ばれることもある）が開始されてもよい。継続時間が計算されてこの新たに作成されたバインディングに関連付けられる。この場合の継続時間は、バインディングの終了前の期間を特定する。イベントなしパターンマッチングの場合、この継続時間は、たとえば、予測される次のイベントが生じることになっている時間枠を特定してもよい。本発明のある実施形態では、この継続時間は異なるバインディングに対して可変であってもよい。
【０００９】
たとえば、イベントストリームを介して受信した第１のイベントが、第１のパターンマッチ候補（すなわち第１のバインディング）を開始させてもよい。これと同じイベントストリームを介して受信した第２のイベントが、第２のパターンマッチ候補（すなわち第２のバインディング）を開始させてもよい。本発明の一実施形態に従うと、第１のバインディングについての継続時間を、第２のバインディングについての継続時間と異ならせることができる。このようにして、イベントなしパターンマッチングの場合に使用される異なるバインディングに、異なるまたは可変の継続時間を関連付けてもよい。
【００１０】
ある実施形態において、バインディングについての継続時間は、このバインディングを開始させたイベントの属性の値に基づいていてもよい。たとえば、継続時間は、数式で表わしてもよく、この式は、バインディングを開始させたイベントの１つ以上のイベント属性値に基づく。イベントが異なれば属性の値も異なり得るので、異なるイベントが開始させたバインディングについて計算される継続時間は異なり得る。これにより、イベントなしパターンマッチングの実行における柔軟性がより高くなり、この処理をいくつかの実際のシナリオに応用することができる。これは、過去ではすべてのバインディングの継続時間が固定または一定であったので不可能であった。
【００１１】
ある実施形態において、第１のイベントおよび第２のイベントは、イベントストリームを介して受信されてもよい。第１のイベントは、あるパターンに対する第１のパターンマッチ候補を開始させてもよい。第２のイベントは、このパターンに対する第２のパターンマッチ候補を開始させてもよい。第１の継続時間が第１のパターンマッチ候補について計算されてもよく、第２の継続時間が第２のパターンマッチ候補に対して計算されてもよい。この場合の第２の継続時間は第１の継続時間とは異なる。このように、異なるイベントに関連付けられる継続時間は異なっていてもよい。
【００１２】
ある実施形態において、第１および第２のイベントで開始するパターンマッチについての継続時間は、これらイベントの属性の値に基づいて計算されてもよい。たとえば、第１のイベントの第１の属性の第１の値が決定されてもよく、第２のイベントの第１の属性の第２の値が決定されてもよい。この場合の第２の値は第１の値とは異なる。そこで、第１の値を用いて、第１のイベントによって開始したパターンマッチについての継続時間を計
算してもよく、第２の値を用いて、第２のイベントから開始したパターンマッチについての継続時間が計算されてもよい。
【００１３】
ある実施形態において、第１および第２のイベントで開始するパターンマッチについての継続時間は、式（たとえば算術式）の評価に基づいて計算されてもよい。たとえば、第１のイベントの第１の属性の第１の値が決定されてもよく、第２のイベントの第１の属性の第２の値が決定されてもよい。この場合の第２の値は第１の値とは異なる。次に、第１の値を用いて算術式を評価することにより、第１のイベントの結果生じたパターンマッチについての継続時間を計算してもよく、第２の値を用いてこの算術式を評価することにより、第２のイベントの結果生じたパターンマッチについての第２の継続時間を計算してもよい。
【００１４】
ある実施形態において、第１のパターンマッチ候補についての第１の継続時間の経過後に、第１のパターンマッチ候補がパターンとマッチしているか否か決定されてもよい。第１のパターンマッチ候補がパターンとマッチしていると決定したときに、第１のパターンマッチ候補に対応するイベントなしの発生を示す情報が出力されてもよい。
【００１５】
ある実施形態において、第１のイベントに関連付けられたイベントタイムスタンプと、計算された第１の継続時間とに基づいて、第１のパターンマッチ候補について終了時間を決定してもよい。次にこの終了時間を第１のパターンマッチ候補に関連付けてもよい。第２のイベントに関連付けられたイベントタイムスタンプと、計算された第２の継続時間とに基づいて、第２のパターンマッチ候補について終了時間を決定してもよい。次にこの終了時間を第２のパターンマッチ候補に関連付けてもよい。一実施形態において、あるパターンマッチ候補についての終了時間は、このパターンマッチ候補について計算された継続時間を、このパターンマッチ候補を開始させたイベントに関連付けられたタイムスタンプに加算することによって決定してもよい。
【００１６】
ある実施形態において、終了時間を決定してパターンマッチ候補に関連付けた後、このパターンマッチ候補に関連付けられた終了時間以降に、このパターンマッチ候補がパターンとマッチしているか否か決定してもよい。パターンマッチ候補がパターンとマッチしていると決定されたときに、このパターンマッチ候補に対応するイベントなしの発生を示す情報が出力されてもよい。
【００１７】
本開示の一局面に従い、計算装置が提供される。この計算装置は、イベントストリームを介して計算装置が受信した第１のイベントがあるパターンに対する第１のパターンマッチ候補を開始させると決定するように構成された第１の決定部と、第１のパターンマッチ候補についての第１の継続時間を計算するように構成された第１の計算部と、イベントストリームを介して受信した第２のイベントが上記パターンに対する第２のパターンマッチ候補を開始させると決定するように構成された第２の決定部と、第２のパターンマッチ候補についての第２の継続時間を計算するように構成された第２の計算部とを含む。第２の継続時間は第１の継続時間とは異なる。
【００１８】
ある実施形態において、第１の決定部は、第１のイベントの属性の第１の値を決定するように構成される。第１の計算部は、第１の値を用いて第１の継続時間を計算するように構成される。第２の決定部は、第２のイベントの属性の第２の値を決定するように構成される。第２の値は第１の値とは異なる。第２の計算部は、第２の値を用いて第２の継続時間を計算するように構成される。
【００１９】
ある実施形態において、計算装置は、第１の評価部と第２の評価部とをさらに含む。第１の決定部は、第１のイベントの属性の第１の値を決定するように構成される。第１の評
価部は、第１の値を用いて式を評価することにより第１の継続時間を計算するように構成される。第２の決定部は、第２のイベントの属性の第２の値を決定するように構成される。第２の値は第１の値とは異なる。第２の評価部は、第２の値を用いて式を評価することにより第２の継続時間を計算するように構成される。
【００２０】
ある実施形態において、計算装置は出力部をさらに含む。第１の決定部は、第１のイベントについての第１の継続時間の経過後に、第１のパターンマッチ候補がパターンとマッチしているか否か決定するように構成される。出力部は、第１のパターンマッチ候補がパターンとマッチしていると決定されると、第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するように、構成される。
【００２１】
ある実施形態において、計算装置は、第１の関連付け部と第２の関連付け部とをさらに含む。第１の決定部は、第１のイベントに関連付けられた第１の時間と第１の継続時間とに基づいて第１のパターンマッチ候補についての第１の終了時間を決定するように構成される。第１の関連付け部は、第１の終了時間を第１のパターンマッチ候補に関連付けるように構成される。第２の決定部は、第２のイベントに関連付けられた第２の時間と第２の継続時間とに基づいて第２のパターンマッチ候補についての第２の終了時間を決定するように構成される。第２の関連付け部は、第２の終了時間を第２のパターンマッチ候補に関連付けるように構成される。
【００２２】
ある実施形態において、第１の決定部は、第１のイベントに関連付けられた第１の時間に第１の継続時間を加算することによって第１の終了時間を決定するように構成される。第２の決定部は、第２のイベントに関連付けられた第２の時間に第２の継続時間を加算することによって第２の終了時間を決定するように構成される。
【００２３】
ある実施形態において、計算装置は出力部をさらに含む。第１の決定部は、第１のパターンマッチ候補に関連付けられた第１の終了時間以降に、第１のパターンマッチ候補がパターンとマッチしているか否か決定するように構成される。出力部は、第１のパターンマッチ候補がパターンとマッチしていると決定されると、第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するように、構成される。
【００２４】
本開示の一局面に従い、システムまたは装置が提供されてもよい。このシステムまたは装置は、イベントストリームを介して計算装置が受信した第１のイベントがあるパターンに対する第１のパターンマッチ候補を開始させると決定するための手段と、第１のパターンマッチ候補についての第１の継続時間を計算するための手段と、イベントストリームを介して受信した第２のイベントが上記パターンに対する第２のパターンマッチ候補を開始させると決定するための手段と、第２のパターンマッチ候補についての第２の継続時間を計算するための手段とを含み、第２の継続時間は第１の継続時間とは異なる。
【００２５】
ある実施形態において、第１のイベントおよび第２のイベントは属性を含む。第１の継続時間を計算するための手段は、第１のイベントの属性の第１の値を決定するための手段と、第１の値を用いて第１の継続時間を計算するための手段とを含む。第２の継続時間を計算するための手段は、第２のイベントの属性の第２の値を決定するための手段を含み、第２の値は第１の値とは異なり、第２の値を用いて第２の継続時間を計算するための手段を含む。
【００２６】
ある実施形態において、第１のイベントおよび第２のイベントは属性を含む。第１の継続時間を計算するための手段は、第１のイベントの属性の第１の値を決定するための手段と、第１の値を用いて式を評価することにより第１の継続時間を計算するための手段とを含む。第２の継続時間を計算するための手段は、第２のイベントの属性の第２の値を決定
するための手段を含み、第２の値は第１の値とは異なり、第２の値を用いて式を評価することにより第２の継続時間を計算するための手段を含む。
【００２７】
ある実施形態において、このシステムまたは装置はさらに、第１のイベントについての第１の継続時間の経過後に、第１のパターンマッチ候補がパターンとマッチしているか否か決定するための手段と、第１のパターンマッチ候補がパターンとマッチしていると決定されると、第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するための手段とを含む。
【００２８】
ある実施形態において、このシステムまたは装置はさらに、第１のイベントに関連付けられた第１の時間と第１の継続時間とに基づいて、第１のパターンマッチ候補についての第１の終了時間を決定するための手段と、第１の終了時間を第１のパターンマッチ候補に関連付けるための手段と、第２のイベントに関連付けられた第２の時間と第２の継続時間とに基づいて、第２のパターンマッチ候補についての第２の終了時間を決定するための手段と、第２の終了時間を第２のパターンマッチ候補に関連付けるための手段とを含む。
【００２９】
ある実施形態において、このシステムまたは装置はさらに、第１のパターンマッチ候補に関連付けられた第１の終了時間以降に、第１のパターンマッチ候補がパターンとマッチしているか否か決定するための手段と、第１のパターンマッチ候補がパターンとマッチしていると決定されると、第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するための手段とを含む。
【図面の簡単な説明】
【００３０】
【図１】本発明の実施形態を組込み得るイベント処理システムの簡略化された高レベルの図を示す。
【図２】本発明の実施形態に従い、イベントの受信時に実行される処理を示す簡略化されたフローチャートを示す。
【図３】本発明の実施形態に従い、既に存在するバインディングに対し、イベントの受信時に実行される処理を示す簡略化されたフローチャートを示す。
【図４】本発明の実施形態に従い、継続時間可変のウィンドウを用いてイベントなし検出を実現するために使用し得るモジュールおよびデータ構造を示す。
【図５】本発明の実施形態に従い、ＡＬＬ  ＭＡＴＣＨＥＳ句が指定されたときに生じる可能性があるシナリオを示す。
【図６】本発明の実施形態に従い、ＳＫＩＰ  ＰＡＳＴ  ＬＡＳＴ  ＲＯＷ句が指定されたときに生じる可能性があるシナリオを示す。
【図７】本発明の実施形態に従い使用し得るシステム環境の構成要素を示す簡略化されたブロック図である。
【図８】本発明のある実施形態に従い使用し得るコンピュータシステムの簡略化されたブロック図である。
【図９】本発明のある実施形態に従い使用し得る計算装置の簡略化されたブロック図である。
【発明を実施するための形態】
【００３１】
詳細な説明
以下の記載では、説明を目的として具体的な詳細事項が本発明の実施形態の十分な理解をもたらすべく述べられている。しかしながら、さまざまな実施形態がこういった具体的な詳細事項なしで実施し得ることは明らかであろう。図面および説明は限定を意図したものではない。
【００３２】
可変の継続時間を用いて連続イベントストリームに対しイベントなしパターンマッチン
グを実行するための、ある実施形態が開示される。
【００３３】
イベント処理エンジンのパターンマッチング機能に関して、イベントなし検出とは、特定の時間枠内で生じるはずである何らかのイベントがこの時間枠内で生じないときの状況を検出することを意味する。たとえば、イベントが特定の順序で生じるというシナリオでは、イベントなし検出を用いて、特定の時間枠内においてこの順序で次に生じることになっている特定のイベントがこの時間枠内で起こらないという状況を、検出することができる。
【００３４】
イベントをベースにしたパターンマッチングでは、イベントの到来によってパターンマッチ候補（バインディングと呼ばれることもある）が開始されてもよい。継続時間が計算されてこの新たに作成されたバインディングに関連付けられる。この場合の継続時間は、バインディングの終了前の期間を特定する。イベントなしパターンマッチングの場合、この継続時間は、たとえば、予測される次のイベントが生じることになっている時間枠を特定してもよい。
【００３５】
過去において、パターンマッチによって開始される各バインディングに関連付けられる継続時間は、常に一定であったまたは固定されていた。たとえば、バインディングについての継続時間を指定するために使用されるＤＵＲＡＴＩＯＮ（継続時間）句は、パラメータとして、たとえば「ＤＵＲＡＴＩＯＮ  １０」という一定のまたは固定された値しか取ることができなかった。このような句では、新たなパターンマッチバインディングが開始される度に、バインディングについての継続時間は、常に１０時間単位（１０秒）に設定され、すべてのバインディングに対して同一であった。このため、イベントなしパターンマッチングを用いて実際の状況をモデル化する機能は著しく限定されていた。
【００３６】
本発明のある実施形態は、あるバインディングに関連付けられた継続時間をさまざまなバインディングに対して可変にすることができるという望ましい柔軟性を提供する。たとえば、イベントストリームを介して受信した第１のイベントが第１のパターンマッチ候補（すなわち第１のバインディング）を開始させてもよく、これと同一のイベントストリームを介して受信した第２のイベントが第２のパターンマッチ候補（すなわち第２のバインディング）を開始させてもよい。本発明のある実施形態に従うと、第１のバインディングについての継続時間を、第２のバインディングについての継続時間と異ならせることができる。このようにして、あるバインディングについての継続時間を、別のバインディングについての継続時間と異ならせることができる。イベントなしパターンマッチングの場合に使用される異なるバインディングにはしたがって、異なるまたは可変の継続時間がそれぞれ関連付けられてもよい。
【００３７】
ある実施形態において、バインディングについての継続時間は、このバインディングを開始させたイベントの属性の値に基づいていてもよい。たとえば、継続時間は、数式で表わしてもよく、この式は、バインディングを開始させたイベントの１つ以上のイベント属性値に基づく。イベントが異なれば属性の値も異なり得るので、異なるイベントが開始させたバインディングについて計算される継続時間は異なり得る。これにより、イベントなしパターンマッチングの実行における柔軟性がより高くなり、この処理をいくつかの実際のシナリオに応用することができる。これは、過去ではすべてのバインディングの継続時間が固定または一定であったので不可能であった。
【００３８】
上記のように、本発明の実施形態は、イベントストリーム（連続データストリームとも呼ばれる）の処理に応用し得る。連続データストリームまたはイベントストリーム（またはイベントデータストリーム）は、明確な終わりがない、本質的に連続するまたは無限であるデータまたはイベントのストリームである。論理的に、イベントまたはデータストリ
ームは、一連のデータ要素（イベントとも呼ばれる）であり、各データ要素は関連付けられたタイムスタンプを有する。連続イベントストリームは、論理的には要素（ｓ，Ｔ）のバッグ（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）（ＰＯＪＯ）であってもよく、または、ユーザ
コードがＯｒａｃｌｅ  ＣＥＰのイベントビーンＡＰＩを使用してビーンをＯｒａｃｌｅ
ＣＥＰによって管理できるようにしてもよい。ユーザアプリケーションは、ＪＭＳ、ウェブサービス、ファイルライター等の一組の外部サービスを利用して、生成されたイベントを外部イベントシンクに転送することができる。
【００５９】
一実施形態において、イベントアダプタは、イベントデータを入力チャネルに与える。入力チャネルは、入力チャネルが与えるイベントに対して機能する１つ以上のＣＱＬクエリに関連付けられたＣＱＬプロセッサに接続される。ＣＱＬプロセッサは、クエリ結果が書込まれる出力チャネルに接続される。
【００６０】
いくつかの実施形態において、イベント処理アプリケーションに対し、イベント処理アプリケーションのさまざまな構成要素を説明しどのようにして構成要素同士が接続されるかを説明しアプリケーションによって処理されるイベントタイプを説明するアセンブリファイルを与えてもよい。イベントを選択するための連続クエリまたはビジネスロジックを指定するために別々のファイルを与えてもよい。
【００６１】
図１に示されるシステム１００が図１に示される構成要素以外の構成要素を有し得ることが理解されるはずである。さらに、図１に示される実施形態は、本発明の実施形態を組込み得るシステムの一例に過ぎない。他のいくつかの実施形態では、システム１００が有する構成要素の数は図１に示されるものよりも多くても少なくてもよく、２つ以上の構成要素を組み合わせてもよく、または、構成要素の構成または配置が異なっていてもよい。システム１００は、パーソナルコンピュータ、ポータブルデバイス（たとえば携帯電話または装置）、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、またはその他何等かのデータ処理システムを含むさまざまな種類のものであってもよい。他のいくつかの実施形態において、システム１００を、システム１００の１つ以上の構成要素がクラウド内の１つ以上のネットワークに分散している分散システムとして構成してもよい。
【００６２】
図１に示される構成要素のうちの１つ以上は、ソフトウェア、ハードウェア、またはその組み合わせにおいて実現し得る。いくつかの実施形態において、ソフトウェアは、メモリ（たとえば非一時的なコンピュータ読取可能な媒体）に、メモリ素子に、または何等かのその他の物理メモリに格納されてもよく、１つ以上の処理部（たとえば１つ以上のプロセッサ、１つ以上のプロセッサコア、２つ以上のＧＰＵなど）によって実行されてもよい。
【００６３】
イベントなしパターンマッチング
上記のように、イベントなし検出とは、特定の時間枠内で生じるはずである何らかのイベントがこの時間枠内で生じないときの状況を検出することを意味する。たとえば、イベ
ントが特定の順序で生じるというシナリオでは、イベントなし検出を用いて、特定の時間枠内においてこの順序で次に生じることになっている特定のイベントがこの時間枠内で起こらないという状況を、検出することができる。
【００６４】
あるイベント処理システムでは、イベントなし検出を、イベントなしパターンマッチングを用いて実現することができる。以下は、イベントなし検出を応用することが可能な、限定ではないいくつかの例である。
【００６５】
例＃１：購入注文追跡アプリケーション：購入注文追跡システムは、注文された商品がこの注文品の推定納品時間が経過したにもかかわらず出荷されていない場合に、注文を追跡することが可能でなければならない。たとえば、購入注文システムのワークフローは、発注され、注文が処理され、注文された商品が出荷され、場合によってはこの注文についての推定納品時間が提供される、というワークフローであってもよい。アプリケーションは、発注され注文が処理されたが推定納品時間が経過したにもかかわらずまだ出荷されていないときに、イベントなしを報告するように構成される。ここでは、発注と、商品の出荷とを、別々のイベントとしてモデル化してもよい。推定納品時間は本質的に、注文され出荷される商品に左右され得ることがわかる。なぜなら、異なる購入注文についての推定納品時間は、この注文に関係する商品に応じて異なり得るからである。出荷される商品に基づくこの変動性は、従来の継続時間固定のイベントなしパターンマッチングを用いてモデル化することはできないが、本発明のある実施形態を用いるとモデル化することができる。上記３つのワークフロー状態がイベントとしてモデル化されてもよく、＜orderId, orderDesc, eventType, estimatedTimeOfDelivery＞というスキーマを有するイベントストリームが定められ受信されてもよい。このうちのeventTypeは、「placed（発注）」、「inProcess（処理中）」、および「shipped（出荷）」という３つの値を有し得る。このイ
ベント処理アプリケーションは、「placed（発注）」後注文は「inProcess（処理中）」
であるが、「placed（発注）」後「estimatedTimeOfDelivery（推定納品時間）」が経過
したにもかかわらずまだ「shipped（出荷）」がなされていないときに、イベントなしを
報告する。本発明のある実施形態により、種類が異なる注文に対し「estimatedTimeOfDelivery（推定納品時間）」が異なるようにすることができる。この検出なしを実行するた
めのＣＱＬクエリについては以下で示す。
【００６６】
例＃２：空港乗客追跡アプリケーション：航空会社は、乗客が上陸する時間および乗客が手荷物受取所に到着する時間の追跡を所望する場合がある。航空会社は、乗客は上陸するとその後特定の時間枠たとえば３０分以内に手荷物受取所に現われると予測する場合がある。この時間枠の予測は、航空会社によって異なり得る。このシナリオにおいて、乗客が上陸することと、乗客が手荷物受取所に到着することとは、別々のイベントとしてモデル化してもよい。すなわち、イベントＡを上陸とし、イベントＢを手荷物受取所に到着することとしてもよい。上陸は、正規表現を（Ａ）として用いてモデル化してもよい。このパターンについての継続時間は（Ｔ＋遅延）として表現してもよく、Ｔは乗客の上陸時間（すなわちイベントＡのタイムスタンプ）であり、「遅延」は乗客が手荷物受取所にいる（すなわちイベントＢが発生する）と航空会社が予測する時間である。この「遅延」はある航空会社では３０分かもしれず、航空会社特有である場合がある。イベントＡが発生した（すなわちパターンがマッチした）がイベントＡ発生後の継続時間以内にイベントＢが発生しないときは、イベントなしと報告されるであろう。
【００６７】
例＃１（購入注文追跡の例）に戻ると、＜orderId, orderDesc, eventType, estimatedTimeOfDelivery＞というスキーマを有するイベントのストリーム＜PurchaseOrderTracking＞が受信されてもよい。上記のように、eventTypeは、可能な値として「placed」、「inProcess」、および「shipped」という３つの値を有し得る。「placed（発注）」後注文は「inProcess（処理中）」であるが、「placed（発注）」後「estimatedTimeOfDelivery（
推定納品時間）」が経過したにもかかわらずまだ「shipped（出荷）」がなされていない
ときに、マッチを報告するために、ＣＱＬクエリが定められてもよい。ここで、「estimatedTimeOfDelivery」は、種類が異なる注文に対してそれぞれ異なるようにすることがで
きる。「PurchaseOrderTracking」ストリームの属性「estimatedTimeOfDelivery」は、ＤＵＲＡＴＩＯＮサブ句で表現することができる。一実施形態において、これは、以下の継続時間可変句を有するＣＱＬクエリ（qDelayedShipments）を用いて捕捉することができ
る。
【００６８】
【数１】
2019125383.tif 000003
【００６９】
ここで、estimatedTimeOfDeliveryは、入力イベントストリームのスキーマの属性である
。したがって、パターン（ＡＢ）に対するパターンマッチ候補を開始させる受信入力イベントについては、このパターンマッチ候補の継続時間は、このパターンを開始させる入力イベントのestimatedTimeOfDelivery属性の値に基づいて決定される。
【００７０】
qDelayedShipmentsクエリは、以下で説明するいくつかのＣＱＬ句を含む。一実施形態
において、ＣＱＬ言語構造ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ句が、ＣＱＬクエリにおけるパターン認識を実行するために使用される。ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ句を用いて、ユーザは、入来するイベントの属性に対する条件を定め、相関変数と呼ばれる識別子を用いることによってパターンマッチングの条件を識別することができる。各々が何らかの条件を満たす、入力されたストリーム内の一連の連続イベントまたはタプルが、１つのパターンを構成する。パターン認識機能によって、ユーザは、入来するイベントまたはタプルの属性に対する条件を定め、相関変数と呼ばれる文字列名を用いることによってこれらの条件を識別することができる。qDelayedShipmentsクエリにおいて、「Ａ」および「Ｂ
」は相関変数である。マッチングすべきパターンは、これら相関変数に対する正規表現として指定され、これは、有効なマッチとして認識されるべき異なる入来イベントが条件を満たすべきシーケンスすなわち順序を決定する。これら条件を満たす、入力ストリーム内の一連の連続イベントが、１つのパターンを構成する。一実施形態において、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥクエリの出力はストリームである。
【００７１】
上記クエリqDelayedShipmentsにおいて、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ句はいくつ
かのサブ句を有する。ＤＥＦＩＮＥサブ句は、相関変数ごとにブール条件を指定する。これは、何らかの論理または算術式として指定されてもよく、何らかの一行または集約関数
を、条件とマッチするイベントの属性に適用してもよい。入力ストリームを介して新たなイベントが受信されると、この時点で関連がある相関変数の条件が評価される。あるイベントは、その規定条件を満たす場合に相関変数とマッチしていると言える。特定の入力は、ゼロ、１つ、または２つ以上の相関変数とマッチし得る。入力イベントの受信時に評価すべき関連条件は、ＰＡＴＴＥＲＮ句の正規表現によって支配される処理ロジックと、パターン認識プロセスにおいて前の入力の処理後に達した状態とによって、決定される。この条件は、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ句が適用されているストリームに対して評価するストリームまたはビューのスキーマの属性のうちのいずれかを参照することができる。ＰＡＴＴＥＲＮ句における相関変数は、ＤＥＦＩＮＥ句において指定される必要はなく、このような相関変数のデフォルトは、常に真である述語である。このような相関変数はすべてのイベントとマッチする。
【００７２】
ＰＡＲＴＩＴＩＯＮ  ＢＹサブ句は、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ句がその結果を区画に分割するときに使用すべきストリーム属性を指定する。ＰＡＲＴＩＴＩＯＮ  ＢＹ句がなければ、すべてのストリーム属性が同一の区画に属することになる。パターンマッチングに加えてＰＡＲＴＩＴＩＯＮ  ＢＹ句があるとき、入力ストリームは、区画リスト内で示される属性に基づいて論理的に分割され、パターンマッチングは１つの区画内で行なわれる。
【００７３】
ＭＥＡＳＵＲＥＳサブ句は、指定されたパターンとのマッチに成功したイベントの１つ以上の属性値をエクスポートし（たとえばＳＥＬＥＣＴ句に含めることができるようにし）、かつ、これら属性値に対して式を指定できるようにする。この句を用いて、ＤＥＦＩＮＥ句内の条件（相関変数）とマッチするイベントストリーム内のイベントの属性に対して式を定めてもよく、これらの式をエイリアシングして、ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ条件がその一部であるメインクエリのＳＥＬＥＣＴ句で適切にこれらの式を使用できるようにしてもよい。あるイベントストリームの属性は、直接参照されてもよく、または、相関変数を介して参照されてもよい。
【００７４】
ＡＬＬ  ＭＡＴＣＨＥＳサブ句は、オプションであり、オーバラップするパターンをどのように扱うべきか指定するために使用される。ＡＬＬ  ＭＡＴＣＨＥＳ句が存在することによって、特定の入力の受信時にマッチするすべてのパターンインスタンスが報告される。ＡＬＬ  ＭＡＴＣＨＥＳ句を省略すると、１つのパターン（最も長いマッチ）のみが出力される。たとえば、マッチさせる対象であるパターンが（ＡＢ＊）の場合、ＡＬＬ  ＭＡＴＣＨＥＳによって、マッチしオーバラップするすべてのパターン、たとえばＡ、ＡＢ、ＡＢＢ、ＡＢＢＢが、出力されることになる。この句を省略すると、マッチする最も長いパターン、すなわちＡＢＢＢのみが出力されることになる。
【００７５】
ＩＮＣＬＵＤＥ  ＴＩＭＥＲ  ＥＶＥＮＴＳサブ句は、イベントなし検出クエリのＤＵＲＡＴＩＯＮ句（以下で説明する）とともに使用される。典型的に、ほとんどのパターンマッチクエリにおいて、パターンマッチ出力は常に、パターンをマッチさせている対象である入力ストリームの入力イベントによってトリガされる。例外は、（入力ストリームの明確な入力イベントとは対照的に）タイマ終了というイベントによって出力がトリガされる、イベントなし検出クエリである。
【００７６】
ＰＡＴＴＥＲＮサブ句は、マッチさせるべきパターンを、１つ以上の相関変数に対する正規表現として指定する。入来するイベントは、所与の順序（左から右）でこれら条件にマッチしなければならない。正規表現は、相関変数および以下のようなパターン修飾子で構成されてもよい。
【００７７】
＊：０以上の回数
＋：１以上の回数
？：０または１回等
ある実施形態において、上記１文字のパターン修飾子は、最大または「greedy（欲張り）」である、すなわち、これら修飾子が適用される正規表現のうちできる限り多くのインスタンスをマッチさせようとする。このパターン修飾子は２文字であってもよく、これは、最小または「reluctant（不承不承）」である、すなわち、これら修飾子が適用される正
規表現のうちできる限り少ないインスタンスをマッチさせようとする。２文字の修飾子の例は以下のものを含むがこれらに限定されない。
【００７８】
＊？：０以上の回数
＋？：１以上の回数
？？：０または１回
パターンマッチングの一例として以下のパターンについて考える。
【００７９】
ＰＡＴＴＥＲＮ（ＡＢ＊Ｃ）
このパターン句は、入来する連続入力イベントによって以下の条件が満たされるときにパターンマッチが認識されるということを意味する。
状態１：丁度１つのイベントタプルが、相関変数Ａを定める条件とマッチし、続いて
状態２：相関変数Ｂとマッチするゼロ以上のタプル、続いて
状態３：相関変数Ｃとマッチする丁度１つのタプル。
【００８０】
状態１、状態２、および状態３という状態は、パターン（ＡＢ＊Ｃ）のさまざまな状態を表わし、状態３はこのパターンの最終状態である。パターンマッチが特定の状態にありこの特定の状態に留まることができるかまたは次のイベントによってこの特定の状態から次の状態に移ることができる場合、これは、バインディングが発展可能であることを示唆する。バインディングが最終状態にあればパターンはマッチしているとみなされる。状態２のときに、相関変数ＢおよびＣいずれにもマッチするタプルまたはイベントが到来した場合（なぜならこれは双方の規定条件を満たすからである）、Ｂの修飾子＊がgreedyであるため、このタプルはＣではなくＢとマッチしているとみなされることになる。したがって、greedyなプロパティＢはＣよりも優先されるので、Ｂとマッチするものの方が多い。パターン式がＡＢ＊？Ｃであれば、これはＢに対してlazy（怠惰な）またはreluctant修
飾子を使用しているので、ＢおよびＣ双方とマッチするタプルは、Ｃのみとマッチするものとして扱われることになる。このように、ＣはＢよりも優先され、Ｂとマッチするものの方が少ない。
【００８１】
上記qDelayedShipmentsクエリにおいて、パターン（ＡＢ）は、
状態１：丁度１つのイベントタプルが、相関変数Ａを定める条件とマッチし、すなわちeventTypeが「placed」であるイベントであり、続いて
状態２（最終状態）：相関変数Ｂとマッチする丁度１つのタプル、すなわちeventTypeが
「inProcess」であるイベント。
状態１および状態２という状態は、パターン（ＡＢ）にとって可能なさまざまな状態を表わし、状態２はこのパターンの最終状態である。
【００８２】
ＤＵＲＡＴＩＯＮサブ句は、イベントなし検出に関するクエリを書くときに使用される。この句を用いると、マッチが報告されるのは、ＰＡＴＴＥＲＮ句内の正規表現が完全にマッチしＤＵＲＡＴＩＯＮ句で指定された継続時間が終了するまで他のイベントまたは入力が到来しない場合のみである。ＤＵＲＡＴＩＯＮ句には関連付けられた時間パラメータがあり、この時間パラメータはＤＵＲＡＴＩＯＮ句に対してたとえば以下の継続時間を指定する。
【００８３】
ＤＵＲＡＴＩＯＮ＜time_parameter＞
このtime_parameterを用いて、入力イベントが原因で開始された、特定のパターンに対するバインディングまたはパターンマッチ候補（すなわちバインディング）について継続時間を計算する。この継続時間は、このパターンマッチまたはバインディングの開始を生じさせるイベントの到着時間を起点とする、バインディングが発展可能な時間の長さを示す。
【００８４】
過去において、time_parameterは常に一定または固定値であった。本発明のある実施形態により、イベントなし検出のためのパターンクエリのＤＵＲＡＴＩＯＮ句において指定されるtime_parameterを可変にすることができる。上記のように、以前の実装例では、ユーザはＤＵＲＡＴＩＯＮ句において一定または固定値しか持つことができなかった。本発明のある実施形態により、可変ＤＵＲＡＴＩＯＮ句を、変動するものに基づくようにすることができる。
【００８５】
たとえば、ＤＵＲＡＴＩＯＮ句のtime_parameterは、入力イベントの１つ以上の属性の関数であってもよい。たとえば、qDelayedShipmentsというクエリのパターン（ＡＢ）の
場合、ＤＵＲＡＴＩＯＮ句のtime_parameterは、「estimatedTimeOfDelivery」であり、
継続時間の期間は、マッチを開始させた受信イベントのestimatedTimeOfDelivery属性の
値に設定される。この属性の値は、マッチを開始させたイベントが異なれば異なり得るので、ＤＵＲＡＴＩＯＮ句によって指定される継続時間の値は、異なるイベントごとに異なるようにすることができる。したがって、１つ以上の属性を含むスキーマを有する、基礎となる入力ストリームの場合、ＤＵＲＡＴＩＯＮ句のtime_parameterは、これらイベント属性のうちの１つ以上に基づき得る。たとえば、イベント「Ｅ」が属性「ａｔｔｒ」を有する場合、ＤＵＲＡＴＩＯＮ句の一例は、「ＤＵＲＡＴＩＯＮ  Ｅ．ａｔｔｒ」であってもよい。ここで、time_parameterはＥ．ａｔｔｒの値に設定され、これにより、イベント「Ｅ」を受信したことによって生じたバインディングに関連付けられる継続時間は、属性Ｅ．ａｔｔｒの値に設定されることになる。
【００８６】
別の例として、ＤＵＲＡＴＩＯＮ句に関連付けられるtime_parameterは、評価される式（たとえば算術式）を指定してもよく、この評価の結果は、ＤＵＲＡＴＩＯＮ句について得られる継続時間に与えられる値である。いくつかの実施形態において、この式は、イベントの１つ以上の属性を含み得る。たとえば、イベント「Ｅ」が属性「ａｔｔｒ＿１」、「ａｔｔｒ＿２」を有する場合、time_parameterについての算術式の例は、以下のものを含み得るがこれらに限定されない。
【００８７】
ＤＵＲＡＴＩＯＮ  Ｅ．ａｔｔｒ＿１
ＤＵＲＡＴＩＯＮ  Ｅ．ａｔｔｒ＿１＋Ｃ
（Ｃはある定数（たとえばＥ．ａｔｔｒ＿１＋４）
ＤＵＲＡＴＩＯＮ  Ｅ．ａｔｔｒ＿１＋Ｅ．ａｔｔｒ＿２
ＤＵＲＡＴＩＯＮ  ２＊Ｅ．ａｔｔｒ＿２
受信されたイベントの属性の値はイベントごとに異なり得るので、算術式を評価すると、結果として、異なるイベントによるマッチから生じたバインディングに、異なる継続時間値が関連付けられることになる。したがって、本発明の実施形態により、ＤＵＲＡＴＩＯＮについて、固定／一定値および可変値のいずれもが可能になる。
【００８８】
パターンマッチングの場合、ＤＵＲＡＴＩＯＮ句は、実行時に、あるイベントが入力イベントストリームに到来し１つのパターンマッチ（または複数のパターンマッチ）を開始させた（すなわち新たなバインディングを作成した）ときに評価される。このようなバインディングが開始されるときに式がＤＵＲＡＴＩＯＮ句に関連付けられ、この式の評価から得られた値がこのバインディングについての継続時間として特定される。したがって、
この式の値は、このイベントで開始されたパターンマッチ（もしあれば）に対するＤＵＲＡＴＩＯＮ値として扱われる。
【００８９】
したがって、ユーザは、イベントなし検出に対してＣＱＬクエリを設計し、ユーザの必要に合わせてＤＵＲＡＴＩＯＮの式（たとえば算術式）を指定することができる。ユーザは、イベントなし検出の継続時間を、場合によってはパターンクエリが定められているベースストリームの１つ以上の属性を含む算術式として、指定することができる。継続時間に可変値を使用することは、イベントごとに考える場合、すなわち入力イベントごとに継続時間が異なり得る場合、有用である。
【００９０】
図２は、本発明の実施形態に従い、イベントの受信時に実行される処理を示す簡略化されたフローチャート２００を示す。図２に示される処理は、１つ以上の処理部（たとえばプロセッサコア）によって実行されるソフトウェア（たとえばコード、命令、プログラム）で実施されてもよく、ハードウェアで実施されてもよく、またはその組み合わせにおいて実施されてもよい。ソフトウェアは、メモリに（たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に）格納されていてもよい。図２に示される特定の一連の処理ステップは、限定を意図したものではない。ある実施形態において、図２に示される処理は、イベントストリームを介して入力イベントが受信される度に、連続クエリ実行の一部として実行されてもよい。
【００９１】
２０２で、入力イベントがイベントストリームを介して受信される。このイベントには、時間情報（たとえばタイムスタンプ）が関連付けられていてもよい。場合によっては、イベントに関連付けられる時間は、このイベントが受信された時間を表わすものであってもよい。
【００９２】
２０４で、２０２で受信されたイベントがパターンマッチ候補（バインディングとも呼ばれる）を開始させるか否か判断される。イベントによってＰＡＴＴＥＲＮ内の第１の相関変数がマッチした場合、このイベントはバインディングを開始させる。このようなマッチは、新たなパターンマッチをこのイベントで開始させることができることを示唆する。このイベントが新たなバインディングを開始させる場合、処理は２０６に続き、そうでなければ処理は２１４に続く。一例として上記qDelayedShipmentsクエリを用いると、パタ
ーンは（ＡＢ）であり、ＡはそのeventTypeが「placed」であるイベントであり、Ｂはそ
のeventTypeが「inProcess」であるイベントである。したがって、そのeventTypeが「placed」であるイベントが２０２で受信された場合、このイベントはパターンマッチを開始
させる。なぜなら、このイベントは（ＡＢ）パターンの「Ａ」部分とマッチする（すなわち状態１が満たされる）からである。このパターンマッチをバインディングと呼んでもよい。パターンマッチまたはバインディングはさらに発展する可能性がある。このような、さらに発展する可能性があるバインディングのことをアクティブなバインディングと呼ぶ。
【００９３】
２０６で、この新たに開始されたバインディングについて継続時間が計算される。バインディングについての継続時間は、クエリ内のＤＵＲＡＴＩＯＮ句において指定されるtime_parameterに基づく。この継続時間は、バインディングが終了する前の期間を特定する。パターンマッチを含むすべてのイベントは、この継続時間によって指定される時間枠の中で生じ、（ＰＡＴＴＥＲＮ句に従い）マッチに寄与する最後のイベントが発生した後であってかつこの継続時間が終了／完了する前は、他のイベントは生じない。したがって、２０６で、ＤＵＲＡＴＩＯＮ句のtime_parameterが評価され、この評価の結果が継続期間の値である。
【００９４】
場合によっては、以前の実装例のように、time_parameterが固定値であることがある。
このような場合、継続時間はこの固定値に設定される。
【００９５】
ある実施形態において、time_parameterは可変値を指定し得る。たとえば、ＤＵＲＡＴＩＯＮ句のtime_parameterは、イベントの属性に基づいていてもよい。他のシナリオでは、time_parameterは、イベントの１つ以上の属性を含む式（たとえば算術式）で表わされてもよい。２０６の一部として、２０２で受信されたイベントのこれら１つ以上の属性の値が求められて継続時間の計算に使用される。イベントの１つ以上の属性を含む式（たとえば算術式）が指定された場合は、２０６で、この１つ以上の属性の値が求められて算術式の評価に使用される。継続時間は、この算術式の評価の結果である。たとえば、ＤＵＲＡＴＩＯＮ句について、
ＤＵＲＡＴＩＯＮ  ｃ１＋５（ｃ１はイベントの属性）
の場合、２０２で受信されたイベントの属性ｃ１の値が求められ、「ｃ１＋５」という算術式が、求められた値を用いて評価される。この評価の結果が、新たなバインディングについての継続時間である。
【００９６】
属性の値は、新たなバインディングを開始させるイベントが異なれば異なり得るので、算術式の評価の結果も、バインディングが異なれば異なる継続時間になる可能性がある。このように、同一のイベントストリームを介して受信されたイベントそれぞれによって開始される異なるバインディングであってかつ同一の指定パターンに対するバインディングに関連付けられる継続時間は、異なり得る。
【００９７】
２０８で、２０６で求められた継続時間に基づいて、新たに開始されたバインディングについて終了時間（またはターゲット時間）が求められる。バインディングについてのターゲット時間は、２０６で求められた継続時間を、このバインディングを開始させた、２０２で受信されたイベントのタイムスタンプに加算することによって得られる。したがって、
ターゲット時間（ＴＴ）＝イベントの時間（ＴＥ）＋継続時間（ＴＤ）となる。
たとえば、２０２で受信されたイベントに関連付けられたタイムスタンプが５秒であり２０６で求められた継続時間が１０秒の場合、このイベントによって開始されるバインディングについてのターゲット時間は、５＋１０＝１５秒マークである。１５秒マークは、このバインディングに関連付けられる終了時間にマークを付ける。
【００９８】
２１０で、２０８で求められたターゲット時間が、新たに開始されたアクティブなバインディングに関連付けられる。処理は次に２１４に続く。
【００９９】
２１４で、２０２で受信されたイベントによってトリガされる他のイベント関連処理が実行されてもよい。たとえば、一実施形態において、図３に示される処理は２１４の一部として実行されてもよい。２１４での処理が実行された後、２１２で、イベント処理システムは次のイベントが到来するのを待つ。図２に示される処理はその後、次のイベントのために繰返されてもよい。
【０１００】
一旦新たなバインディングが生成されると、その後のイベントが到来したときに、イベント処理システムによって処理が実行されて、このバインディングが、発展するのかまたはこのバインディングが発展できない状態に達するのかが、判断される。さらに、イベント処理システムは、バインディングおよびバインディングそれぞれに関連付けられたターゲットまたは終了時間を追跡し、バインディングに関連付けられた終了時間が経過したときまたは終了したときに（すなわちバインディングが終了したときに）適切な処理を実行する。
【０１０１】
図３は、本発明の実施形態に従い、既に存在するバインディングに対し、イベントの受
信時に実行される処理を示す簡略化されたフローチャート３００を示す。図３に示される処理は、１つ以上の処理部（たとえばプロセッサコア）によって実行されるソフトウェア（たとえばコード、命令、プログラム）で実施されてもよく、ハードウェアで実施されてもよく、またはその組み合わせにおいて実施されてもよい。ソフトウェアは、メモリに（たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に）格納されていてもよい。図３に示される特定の一連の処理ステップは、限定を意図したものではない。ある実施形態において、図３に示される処理は、イベントストリームを介して入力イベントが受信される度に、連続クエリ実行の一部として実行されてもよい。
【０１０２】
図３は、既に存在する１つのバインディングに対する処理を示す。しかしながら、前に受信されたイベントに基づくパターンマッチの開始によって各々が作成された２つ以上のバインディングが存在する可能性があることは明白なはずである。これら複数のバインディングは各々、図３に示され以下で説明される処理によって処理されてもよい。
【０１０３】
３０２で、イベントがイベントストリームを介して受信される。各イベントには時間情報（たとえばタイムスタンプ）が関連付けられている。この時間情報を用いて、既存のバインディングに関連付けられたターゲット時間（すなわち終了時間）が経過しているまたは完了しているか否か、すなわちこのバインディングが終了しているか否か判断される。
【０１０４】
したがって、３０４では、既存のバンディングに関連付けられたターゲットまたは終了時間が、３０２で受信されたイベントに関連付けられたタイムスタンプと同一またはそれよりも小さいか否か検査される。３０４で、既存のバインディングに関連付けられたターゲットまたは終了時間が３０２で受信されたイベントに関連付けられたタイムスタンプと同一またはそれよりも小さいと判断された場合、これはバインディングが終了していること示し、処理は３１４に続く。そうでなければ、バインディングは終了していないことが示されたことになり、処理は３０６に続く。
【０１０５】
３０６で、３０２で受信されたイベントに基づいて、このアクティブなバインディングを発展させることができるか否か判断される。上述のように、バインディングが、マッチングされているパターンについて可能なさまざまな状態のうちの特定の状態にあり、この特定の状態に留まることができるかまたは次のイベントの結果としてこの特定の状態から次の状態に移ることができる場合、これは、バインディングが発展可能であることを示唆する。たとえば、３０２で受信された入力イベントがＰＡＴＴＥＲＮの正規表現に従うと次に可能な変数とマッチする場合、バインディングはさらに発展させることができる。上記次に可能な変数は、パターンマッチにおいて現在のアクティブなバインディングが表わすポイントに依存する。したがって、３０６では、既存のバインディングを、３０２で受信されたイベントの結果として発展させることができるか否か判断される。３０６でバインディングを発展させることができると判断された場合、３０８でバインディングを発展させ、そうでなければ、３１０でバインディングはこの処理から打切られる。次に、処理は３１２に続き、３１２でイベント処理システムは次のイベントの到来を待つ。
【０１０６】
一例としてqDelayedShipmentsクエリを用いると、処理されている既存のバインディン
グは、前のイベントがＡとマッチしているのでパターン（ＡＢ）の状態１である場合がある。３０２で受信されたイベントがこのパターンのＢとマッチする（すなわち３０２で受信されたイベントのeventTypeが「inProcess」である)場合、バインディングは発展可能
であり、３０８でＡからＡＢに発展する（バインディングの状態が状態１から状態２に移る）。しかしながら、３０２で受信されたイベントがＢとマッチしない（すなわち３０２で受信されたイベントのeventTYpeが「inProcess」でない）場合、バインディングは発展できず３１０で処理から打切られる。
【０１０７】
３０４に戻って、３０４で、既存のバインディングに関連付けられたターゲットまたは終了時間が３０２で受信されたイベントに関連付けられたタイムスタンプと同一またはそれよりも小さければ、これはバインディングが終了していることを示し、処理は３１４に続く。３１４では、バインディングがパターンマッチングの状態のうちの最終状態か否か検査される。バインディングが最終状態でない場合、このことは、指定されたパターンが、バインディングに関連付けられた継続時間以内にマッチしていないことを示唆し、バインディングは３１０で処理から打切られる。バインディングが最終状態である場合、このことは、指定されたパターンが、バインディングに関連付けられた継続時間以内にマッチしていることを示唆し、３１６で、イベントなしが報告される。一実施形態において、ＭＥＡＳＵＲＥ句は、出力すべき情報を特定する。よって、ＭＥＡＳＵＲＥ句の式が評価され、その後情報が出力される。処理は次に３１２に続き、３１２でシステムは次のイベントの到来を待つ。
【０１０８】
たとえば、qDelayedShipmentsの（ＡＢ）パターンの場合、３１４で、バインディング
が状態２（すなわちＡＢが既にマッチしている）か否か判断するための検査が行なわれる。状態２でなければ、このことは、ＡＢパターンが、バインディングに関連付けられた継続時間以内にマッチしていないことを示唆し、このバインディングは３１０で処理から打切られる。３１４でバインディングが最終状態である（すなわちＡＢが既にマッチしている）と判断された場合、このことが示すのは、発注（Ａとマッチ）を示すイベントが受信され、それに続いてこの注文が処理中であること（ＡＢとマッチ）を示すイベントが受信されたものの、その後出荷されたことを示すイベントがこのバインディングに関連付けられた継続時間（すなわちestimatedTimeOfDelivery）以内に受信されなかった、というこ
とである。したがって、この場合はイベントなしが報告される。
【０１０９】
図２および図３に示され先に説明された処理は、３０２で受信されるイベントが実際のデータイベントであると想定している。いくつかの実施形態において、３０２で受信されるイベントは、時間の経過の情報のみを伝えるために使用される特殊な入力イベントであるハートビートイベントであってもよい。ハートビートイベントには、通常のデータイベントに関連付けられる他の属性の値はない。イベント処理システムを、システムのユーザが設定できる定期的な間隔で自動的にハートビートイベントを送信するように構成してもよい。この場合、ハートビートイベントは、自動的に生成され、定期的な間隔で、その期間内に他の実際のイベントが受信されなければ（すなわちこの期間の間イベントストリームがサイレントであれば）、送信される。たとえば、タイムスタンプされるシステムソース（イベント処理アプリケーションではよく使用される）の場合、ある期間ストリーム／リレーションがサイレントであるときに、ハートビートイベントが自動送信された後の期間を、指定してもよい。入力チャネルが、設定可能な間隔でハートビートタプルを送信するように構成されてもよい。すべてのシステムがハートビートイベント送信機構を有する必要がある訳ではないことに注意しなければならない。
【０１１０】
ハートビートイベントはデータ属性を含まないので、図２では、ハートビートイベントが受信されると処理は２１４に続くであろう。ハートビートイベントは時間の経過の情報を伝えるので、図３では、ハートビートイベントが受信されると、３０４の処理が実行されてバインディングが終了したか否か判断されるであろう。終了したと判断された場合、処理は３１４に続くであろう。終了していなければ、処理は３１２に続くであろう。
【０１１１】
イベントなしパターンマッチング処理の結果は、さまざまなやり方で報告することができる。たとえば、ＡＬＬ  ＭＡＴＣＨＥＳサブ句が指定されるときは、マッチしたパターンインスタンスがすべて報告される。ＡＬＬ  ＭＡＴＣＨＥＳ句を省略すると、パターンが１つ（最も長いマッチ）のみ出力される。したがって、イベントなしが報告される場合は３１６で適切な処理が行なわれればよい。たとえば、ＡＬＬ  ＭＡＴＣＨＥＳ句がない
ときは、複数のオーバラップするバインディングから最も長いマッチのみが識別されてもよく、最も長いマッチが報告され、他のマッチは報告されなくてもよい。イベントなしを報告する他のカスタマイズされた方法が以下で説明される。
【０１１２】
図３に示され先に説明された処理を用いて、（以前の実装例の）期間一定または固定のＤＵＲＡＴＩＯＮ句、または、本発明のある実施形態に従う継続時間可変のＤＵＲＡＢＬＥ句を処理することができる。したがって、イベントなし検出を処理するために、一般的な汎用化された方法が提供される。
【０１１３】
図４は、本発明の実施形態に従い、可変継続時間を用いてイベントなし検出を実現するために使用し得るモジュールおよびデータ構造を示す。図４に示されるモジュールは、ソフトウェア、またはハードウェア、またはその組み合わせにおいて実現し得る。さらに、図４に示されるモジュールおよびデータ構造は限定を意図したものではない。これに代わる実施形態は、さまざまな配置および組み合わせの、図４に示されるものよりも多いかまたは少ないモジュールを有していてもよい。
【０１１４】
図４に示される実施形態において、モジュールは、新バインディングジェネレータ４０２と、バインディングマネージャ４０４と、継続時間および終了時間評価器４０６と、出力モジュール４１０とを含む。イベント処理システムによって受信されたイベント４００は、新バインディングジェネレータ４０２およびバインディングマネージャ４０４に転送されてもよい。ある実施形態において、新バインディングマネージャ４０２は、受信されたイベントが新たなバインディングまたはパターンマッチを開始させるか否か判断するように構成される。新たなバインディングが生成される場合、新バインディングジェネレータ４０２は、継続時間および終了時間評価器４０６を用いて、このバインディングの継続時間とこのバインディングの終了時間（ターゲット時間）を求めてもよい。継続時間および終了時間評価器４０６は、ＤＵＲＡＴＩＯＮ句に関連付けられたtime_parameterを評価することによりこのバインディングの継続時間を求めてもよい。計算された継続時間に基づき、かつイベント４００に関連付けられた時間に基づき、評価器４０６は、この新たに生成されたバインディングについてターゲットまたは終了時間を求めてもよい。この場合、新バインディングジェネレータ４０２は、評価器４０６から受けたターゲット時間を、新たに生成されたバインディングに関連付ければよい。この新たに生成されたバインディングおよびそれに関連付けられたターゲット時間は次にバインディングマネージャ４０４に転送されてもよい。一実施形態において、新バインディングジェネレータ４０２と、継続時間および終了時間評価器４０６とが組み合わされて、図２に示され先に説明された処理を実行するように構成される。
【０１１５】
ある実施形態において、バインディングマネージャ４０４は、イベント処理システムによってイベントが受信されるときにバインディングを管理するための処理を実行するように構成されてもよい。たとえば、一実施形態において、バインディングマネージャ４０４は、図３に示され先に説明された処理を実行するように構成されてもよい。イベントなしが検出されると、バインディングマネージャ４０４は、出力モジュール４１０のサービスを用いてイベントなしを報告してもよい。
【０１１６】
図４に示されるモジュールは、さまざまなデータ構造４０８を使用することにより、イベントの処理およびイベントなしの検出を容易にしてもよい。たとえば、本発明の一実施形態に従い、新バインディングジェネレータ４０２およびバインディングマネージャ４０４は、さまざまなデータ構造を、新たなバインディングの生成、および、イベントなしの検出を含むバインディング関連処理の実行の、一部として、使用してもよい。
【０１１７】
以下のクエリ（query tkpattern_q1）は、イベントなしを検出するための、もう１つの
ＣＱＬクエリを表わす。
【０１１８】
継続時間可変のイベントなしパターンマッチングの使用および結果について、以下の限定ではない単純な例を用いて説明する。ＣＱＬクエリが次のように指定されると仮定する。
【０１１９】
【数２】
2019125383.tif 000004
【０１２０】
この例において、ＤＵＲＡＴＩＯＮ（継続時間）は「ｃ１＋４」として指定されており、「ｃ１」は入力イベントストリームの属性である。入力ストリームは、入力イベントの属性ｃ２の値に基づいて区画に分割される。マッチさせる対象であるパターンは（ＡＢ＊）であり、パターンマッチングは、各区画ベースで実行されることになる。このパターンは、１区画内の連続する２つのイベントが属性ｃ１について同一の値を有さない限り、マッチする。
【０１２１】
以下に示す表Ａは、イベントのストリームと、本発明の一実施形態に従い可変の継続時間を用いてイベントなしパターンマッチングを実行した結果得られた出力とを示す。この例は限定を意図したものではない。
【０１２２】
【表１】
2019125383.tif 000005
【０１２３】
表Ａに示される出力は次のように説明することができる。
（１）イベント（１，１０，ＯＲＣＬ）は、Ａとマッチするので、「ＯＲＣＬ」というｃ２の値に対応する区画内における候補パターンマッチの開始（すなわち新たなバインディングが生成される）をマークする。このとき、継続時間の式ｃ１＋４が評価され、継続時間は１４秒であると計算される（（パターンマッチ候補を開始させたイベントのｃ１の値）＋４＝１０＋４＝１４）。この新たに生成されたアクティブなバインディングの終了時間は１５秒マークであると計算される（アクティブなバインディングを開始させたイベ
ントのタイムスタンプ＋継続時間の式の評価＝１＋１４＝１５）。このため、イベント（１，１０，ＯＲＣＬ）で開始されたバインディングが発展し続ける場合、これはそのターゲット時間である１５秒マークで出力されることになる。表Ａのイベントのフローからわかるように、「ＯＲＣＬ」区画内の後続のイベントは、Ｂ（すなわちＢ．ｃ１！＝Ａ．ｃ１）とマッチし続けそのためパターンマッチＡＢ＊はターゲット時間（１５秒マーク）に達するまで発展する。タイムスタンプ１６のイベント（１６，１３，ＯＲＣＬ）が受信されたとき、（図３の３０４に従い）入力イベントの時間は、「ＯＲＣＬ」区画内のバインディングと関連付けられているターゲット時間である１５秒よりも大きいと判断される。次に、バインディングが最終状態か否か判断するために検査が行なわれ、バインディングは実際最終状態である（すなわちＡＢ＊パターンはマッチしている）と判断される。したがって、イベントなしの検出が報告される。クエリ指定出力（タイムスタンプ，Ｔ．ｃ２，Ｔ．ｐ１，Ｔ．ｐ２）に従い、出力は（１５，ＯＲＣＬ，１０，１５）である。
【０１２４】
（２）イベント（１，１０，ＧＯＯＧ）は、Ａとマッチするので、「ＧＯＯＧ」というｃ２の値に対応する区画内における候補パターンマッチの開始（すなわち新たなバインディングが生成される）をマークする。このとき、継続時間の式ｃ１＋４が評価され、継続時間は１４秒であると計算される（（パターンマッチ候補を開始させたイベントのｃ１の値）＋４＝１０＋４＝１４）。この新たに生成されたアクティブなバインディングの終了時間は１５秒マークであると計算される（アクティブなバインディングを開始させたイベントのタイムスタンプ＋継続時間の式の評価＝１＋１４＝１５）。このため、イベント（１，１０，ＧＯＯＧ）で開始されたバインディングが発展し続ける場合、これはそのターゲット時間である１５秒マークで出力されることになる。表Ａのイベントのフローからわかるように、「ＧＯＯＧ」区画内の後続のイベントは、Ｂ（すなわちＢ．ｃ１！＝Ａ．ｃ１）とマッチし続けそのためパターンマッチＡＢ＊はターゲット時間（１５秒マーク）に達するまで発展する。タイムスタンプ１６のイベント（１６，１３，ＯＲＣＬ）が受信されたとき、（図３の３０４に従い）入力イベントの時間は、「ＧＯＯＧ」区画内のバインディングに関連付けられているターゲット時間である１５秒よりも大きいと判断される。次に、バインディングが最終状態か否か判断するために検査が行なわれ、バインディングは実際最終状態である（すなわちＡＢ＊パターンはマッチしている）と判断される。したがって、イベントなしの検出が報告される。クエリ指定出力（タイムスタンプ，Ｔ．ｃ２，Ｔ．ｐ１，Ｔ．ｐ２）に従い、出力は（１５，ＧＯＯＧ，１０，１００）である。
【０１２５】
（３）イベント（１，４，ＭＳＦＴ）は、Ａとマッチするので、「ＭＳＦＴ」というｃ２の値に対応する区画内における候補パターンマッチの開始（すなわち新たなバインディングが生成される）をマークする。このとき、継続時間の式ｃ１＋４が評価され、継続時間は８秒であると計算される（（パターンマッチ候補を開始させたイベントのｃ１の値）＋４＝４＋４＝８）。この新たに生成されたアクティブなバインディングの終了時間は９秒マークであると計算される（アクティブなバインディングを開始させたイベントのタイムスタンプ＋継続時間の式の評価＝１＋８＝９）。このため、イベント（１，４，ＭＳＦＴ）で開始されたバインディングが発展し続ける場合、これはそのターゲット時間である９秒マークで出力されることになる。表Ａのイベントのフローからわかるように、「ＭＳＦＴ」区画内の後続のイベントは、Ｂ（すなわちＢ．ｃ１！＝Ａ．ｃ１）とマッチし続けそのためパターンマッチＡＢ＊はターゲット時間（９秒マーク）に達するまで発展する。タイムスタンプ９のイベント（９，８８，ＯＲＣＬ）が受信されたとき、（図３の３０４に従い）入力イベントの時間は、「ＭＳＦＴ」区画内のバインディングに関連付けられているターゲット時間である９秒に等しいと判断される。次に、バインディングが最終状態か否か判断するために検査が行なわれ、バインディングは実際最終状態である（すなわちＡＢ＊パターンはマッチしている）と判断される。したがって、イベントなしの検出が報告される。クエリ指定出力（タイムスタンプ，Ｔ．ｃ２，Ｔ．ｐ１，Ｔ．ｐ２）に従い、出力は（９，ＭＳＦＴ，４，２）である。
【０１２６】
一実施形態において、パターン句（ＭＡＴＣＨ＿ＲＥＣＯＧＮＩＺＥ）構造のＤＤＬは変更する必要がない。構文解析（parser）レベルでは、ＤＵＲＡＴＩＯＮサブ句は以下のうちのいずれかにマップすることができる。
【０１２７】
【数３】
2019125383.tif 000006
【０１２８】
この規則の中で最後の２つのものは継続時間可変のサポートに相当する。一実施形態において、デフォルトの時間単位は秒である。
【０１２９】
イベントなしパターンマッチング処理の結果は、さまざまなやり方で報告することができる。ある実施形態において、特別な処理を実行して、マッチ出力が間違った順序で出力されないことを保証してもよい。たとえば、以下の２つのシナリオは、継続時間可変のイベントなし検出によって、マッチ出力が間違った順序で報告されるかもしれない例である。
【０１３０】
１．区画なし、ＡＬＬ  ＭＡＴＣＨＥＳ
２．区画、ＳＫＩＰ  ＰＡＳＴ  ＬＡＳＴ  ＲＯＷ
上記シナリオ各々に対して出力関連の処理を実行することにより、結果が正しい順序で出力されることを保証してもよい。正しい順序のマッチングは一部のイベント処理アプリケーションによって使用されてもよく、それ以外によって使用されなくてもよい。以下で説明される正しい順序に関連する処理は、請求項に記載される本発明の実施形態にとって必要なものまたは本質的なものではないことが理解されるはずである。
【０１３１】
（１）区画なし、ＡＬＬ  ＭＡＴＣＨＥＳ
上記のように、クエリにおいてＡＬＬ  ＭＡＴＣＨＥＳ句が指定されるとき、マッチしたすべてのパターンインスタンスが、最も長いマッチだけでなく、オーバラップしているパターンも含めて、報告される。個々のバインディングに関連付けられる継続時間は可変という性質があるため、図５において図で説明されている状況が起こり得る。図５に示されるように、それぞれの継続時間が終了している現在アクティブなバインディングが２つある。図５に示されるシナリオでは、アクティブバインディング２（第２のアクティブバインディング）はアクティブバインディング１（第１のアクティブバインディング）よりも後で開始されている（すなわち第２のアクティブバインディングを生じさせたイベントに関連付けられているタイムスタンプは、第１のアクティブバインディングを生じさせたイベントに関連付けられているタイムスタンプよりも後である）が、第２のバインディングの継続時間は、先に開始された第１のバインディングよりも前に終了している。その理由は、第２のバインディングに対して決定された継続時間が第１のバインディングに関連付けられた継続時間よりも小さかったからである。これは、可変の継続時間値を使用する実施形態でしか起こらない。
【０１３２】
したがって、図５の状況では、後で開始されたバインディングの継続時間は先に開始されたバインディングよりも前に終了している。このような状況の場合、ある実施形態では、望ましい出力は、バインディングにそれぞれ関連付けられているターゲットまたは終了時間の順序である。しかしながら、ここでの問題は、バインディングが通常の順序、すな
わちバインディングが開始された順序で処理された場合、第２の出力バインディングに関連付けられているターゲット時間の方が小さいにもかかわらず、第１のマッチ（すなわち第１のアクティブバインディング）が第２のマッチ（すなわち第２の出力バインディング）よりも先に出力されることである。
【０１３３】
一実施形態において、ＡＬＬ  ＭＡＴＣＨＥＳケースのバインディングが正しい順序で出力されることを保証するために、データ構造（たとえばtreeset）を用いて、すべての
アクティブバインディングがターゲット時間の昇順でソートされた状態を保つようにする。このようなデータ構造が繰返されるとき、ターゲット時間がより早いすなわち小さいバインディング（たとえば図５の第２のバインディング）は、ターゲット時間がより遅いすなわち大きいバインディング（たとえば図５の第１のバインディング）よりも前に処理されるであろう。これにより、バインディングを、ターゲット時間の正しい順序に従って出力することができる。
【０１３４】
ある実施形態において、マッチを正しい順序で報告するために、「不確かな（unsure）」バインディングという概念を導入する。不確かなバインディングとは、それ以上発展できず、最終状態に達しており、関連付けられたターゲット時間が過ぎているバインディングである。これに「不確か」という名称を与えることによって、マッチは完了しているにもかかわらずバインディングを出力するか否かが不確かであることを示す。不確かなバインディングに関連付けられるターゲット時間を、matchedT時間と呼ぶ（matchedTは不確かなバインディングに関連付けられるのに対し、ターゲット時間はアクティブなバインディングに対するものであるが、値は同じである）。アクティブなバインディングのターゲット時間が終了しバインディングがパターンの最終状態に達する（すなわちＰＡＴＴＥＲＮによって指定された正規表現がマッチしている）と、このバインディングは不確かなバインディングのリストに移される。その継続時間がまだ終了していない（すなわちそのターゲット時間がまだ経過していない）すべてのアクティブバインディングのリストも維持してもよい。
【０１３５】
一実施形態において、「区画なし  ＡＬＬ  ＭＡＴＣＨＥＳ」ケースの処理は、以下のデータ構造を用いて実現してもよい。
【０１３６】
（１）アクティブバインディングTreeSet：TreeSetは、区画ごとに、アクティブなバインディングをターゲット時間の昇順で格納し続ける。「partition by」句が指定されない場合、入力全体が１つの区画として扱われる。これは、間違った順序のマッチという問題を回避する（昇順のターゲット時間順序を保証する）TreeSetである。
【０１３７】
（２）アクティブアイテム：１つのアクティブアイテムは１つのアクティブバインディングを参照し、このアクティブバインディングは逆にアクティブアイテムを参照する。これは、partition byが指定される場合にのみ必要である。
【０１３８】
（３）ActiveItems：アクティブアイテムのTreeSetは、partition byが指定される場合にのみ維持される。このTreeSetは、アクティブアイテムを昇順のターゲット時間の順に
従って維持し、区画から独立している。これにより、新たな入力が到来したときにそれぞれのターゲット時間が完了しているすべての区画におけるアクティブバインディングが速やかに識別される。
【０１３９】
（４）commonUnsureList：アクティブバインディングは、そのターゲット時間が終了すると、不確かなバインディングのリストに移される。これらは後で出力される。
【０１４０】
一実施形態において、「区画なし、ＡＬＬ  ＭＡＴＣＨＥＳ」というシナリオを扱うた
めにＥＰＳが実行することにより正しい順序での出力を保証するための処理は、以下の６つのステップを含み得る（以下に示される処理は本発明の実施形態の範囲を限定することを意図したものではない）。
【０１４１】
１．入力タプルを受信。
２．Ｉｆ（「partition by」句が指定されている）ｔｈｅｎ、ターゲット時間＜＝現在の入力のタイムスタンプであるActiveItemsの中のすべてのアクティブアイテムについて
（現在の入力の区画に属するか否かに関係なく）、以下を行なう。
【０１４２】
（ａ）アクティブアイテムをActiveItemsデータ構造から削除し参照されたアクティ
ブバインディングもこの区画のアクティブバインディングTreeSetから削除する。
【０１４３】
（ｂ）参照されたアクティブバインディングはＰＡＴＴＥＲＮ句マッチを終了しており、指定された継続時間も終了している（ターゲット時間＜＝入力イベントの現在の時間（ｔｓ）であるため）。そこで、これをcommonUnsureListに移す。
【０１４４】
（ｃ）区画が空である（すなわちアクティブバインディングが残っていない）場合、これを削除する。
【０１４５】
３．Ｉｆ（partition by句は指定されていない）ＯＲ（指定されておりかつ現在のタプルはハートビートタプルでない）ｔｈｅｎ
現在のタプルの区画内のすべてのアクティブバインディングに対し、以下を行なう。
【０１４６】
（ａ）現在のタプルがハートビートタプルでありアクティブバインディングのターゲット時間がハートビート時間よりも大きい場合、ステップ６に進む。
【０１４７】
（ｂ）アクティブバインディングをTreeSetおよびActiveItemsから削除する（「partition by」が指定されている場合）。
【０１４８】
（ｃ）アクティブバインディングをさらに発展可能か否か判断するために処理する。
上記のように、ＰＡＴＴＥＲＮの正規表現に従い現在の入力タプルが次に可能な変数とマッチする場合、バインディングはさらに発展可能である。次に可能な変数は、パターンマッチにおいて現在のアクティブなバインディングが表わすポイントに依存する。たとえば、ＰＡＴＴＥＲＮ（ＡＢＣ）が仕様でありＡおよびＢが既にマッチしている（すなわちバインディングが部分マッチＡＢを表わす）場合、次に可能な変数はＣである。このため、マッチは、現在の入力タプルがＣのＤＥＦＩＮＥ句条件とマッチする場合にのみ、発展可能である。
【０１４９】
バインディングがさらに発展可能である場合、
新たな（発展したバインディング）をデータ構造（（維持されているのであれば）ActiveItemsおよびこの区画のアクティブバインディングツリーセット）に挿入する。
【０１５０】
Else
バインディングは、これ以上発展させることができないのであれば、データ構造から既に削除されているので、打切られる。
【０１５１】
４．現在の入力がハートビートタプルではなければ、
（ａ）現在の入力タプルがＰＡＴＴＥＲＮ内の第１の変数とマッチするか否か、すなわちマッチをこのタプルで開始できるか否か判断しようと試みる。
【０１５２】
（ｂ）そうであれば、
ａ．現在のタプルの属性値を用いて継続時間句の式を評価し継続時間の値をを計算する。
【０１５３】
ｂ．これを現在のタプルのタイムスタンプに加算しその結果をこの新アクティブバインディングについてのターゲット時間として設定する。
【０１５４】
ｃ．このバインディングをこの区画のアクティブバインディングTreeSetに挿入
。また、対応するActiveItemを構成しこれをActiveItemsデータ構造（維持されている場
合）に挿入。
【０１５５】
５．partition byが指定されている場合、現在の区画を、もし空であれば削除する。
６．ＭＥＡＳＵＲＥ句の式を評価した後にcommonUnsureListに集められた完了したマッチを出力する。繰返しの間に、バインディングはcommonUnsureListから削除されるので、このステップの終了時においてcommonUnsureListは空であろう。
【０１５６】
（２）区画、ＳＫＩＰ  ＰＡＳＴ  ＬＡＳＴ  ＲＯＷ
ＡＬＬ  ＭＡＴＣＨＥＳ句が指定されないとき、パターンマッチングは、最長のオーバラップパターンマッチバインディングを出力する。２種類のオーバラップパターンマッチが起こり得る。
【０１５７】
（ａ）完全オーバラップ
ある指定パターンに対する、２０００秒で開始されターゲット時間が８０００秒である第１のバインディングと、同じ指定パターンに対する、３０００秒で開始されターゲット時間が８０００秒である第２のバインディングを考える。終了時に、どちらのバインディングも指定パターンとマッチしていれば（すなわち最終状態であれば）、長い方の第１のバインディングが優先され短い方の第２のオーバラップバインディングの代わりに出力される。
【０１５８】
（ｂ）部分オーバラップ
ある指定パターンに対する、２０００秒で開始されターゲット時間が８０００秒である第１のバインディングと、同じ指定パターンに対する、５０００秒で開始されターゲット時間が９０００秒である第２のバインディングを考える。終了時に、どちらのバインディングも指定パターンとマッチしていれば（すなわち最終状態であれば）、開始時間が早い方の第１のバインディングが優先され第２のバインディングの代わりに出力される。
【０１５９】
異なるバインディングについて計算される継続時間は可変であるため、図６において図で説明されている状況が起こり得る。ここでは、２つの区画Ｐ１およびＰ２にバインディングがある。示されているように、区画１には不確かなバインディング（Ｂ２）とアクティブなバインディング（Ｂ１）がある。区画１のバインディングＢ２が不確かな理由は、Ｂ２は、アクティブバインディングＢ１よりも後に開始され、継続時間の値が他方のアクティブバインディングＢ１よりも小さいので継続時間がアクティブバインディングＢ１よりも前に終了するからである。この不確かなバインディングは出力されない。なぜなら、Ｐ１において現在アクティブなバインディングＢ１は、不確かになる可能性がありその後最長のマッチを表わすことになるからである。
【０１６０】
さらに、図６に示されるように、第２の区画Ｐ２には、現時点で不確かになったバインディングＢ３がある。しかしながら、このバインディングは出力できない。なぜなら、後に区画１のアクティブバインディングＢ１が（何らかの理由で）完了せず打切られる場合に、区画Ｐ１の不確かなバインディングＢ２を先ず出力する必要があるからである。その
matchedTsは区画２の不確かなバインディングＢ３のmatchedTsよりも小さいので、これは結果としてマッチが間違った順序で報告されることに繋がる。
【０１６１】
一実施形態において、unsureItem（不確かなアイテム）は、unsureList（不確かなリスト）内のすべてのバインディングに対して維持され、このようなunsureItemのTreesetを
用いることにより、その中で最小のmatchedTsを直ちに得ることができる。次にこれを用
いてバインディングを報告すべきか否か判断する。
【０１６２】
一実施形態において、ＡＬＬ  ＭＡＴＣＨＥＳケースを処理するための上記データ構造は、いくつかの変更を加えて使用される。不確かなバインディングに対し、commonUnsureListは維持されないが、その代わりに区画固有の不確かなバインディングのリストが維持される。さらに、「partition by」句が指定されると、以下の追加のデータ構造が維持される。
【０１６３】
（１）「readyToOutputBindings」と呼ばれる優先度キューが維持される。これは、「matchedTs」の昇順でソートされた、出力（output）の「準備ができている（ready）」不
確かなバインディング（bindings）を保持する。
【０１６４】
（２）不確かなバインディングにマップするunsureItemが維持される（activeItemと同様）。（区画から独立している）これら不確かなアイテムはすべて、unsureItemsと呼ば
れるTreeSetにおいて保持され、matchedTsによってソートされる。このデータ構造は、すべての区画にわたるすべての不確かなバインディングの中から最小の「matchedTs」を素
早く識別するのに役立つ。
【０１６５】
一実施形態において、区画を扱うためにＥＰＳによって実行されて正しい順序での出力を保証するための処理である、ＳＫＩＰ  ＰＡＳＴ  ＬＡＳＴ  ＲＯＷＳシナリオは、次のようなものであってもよい（以下に示される処理は本発明の実施解体の範囲を限定することを意図したものではない）。
【０１６６】
１．入力タプルを受信しこのタプルが属する区画を「現在の区画」としてマークする。partition byが指定されていないのであれば、入力全体が１つの（および「現在の」）区画である。
【０１６７】
２．入力タプルがハートビートでありかつpartition byが指定されている場合、ステップ４に進む。
【０１６８】
３．doCommonProcessing()を実行する。
４．partition byが指定されれば、doNonEventProcessing()を実行する。
【０１６９】
５．完了したマッチを出力する。
partition byが指定されなければ、不確かなバインディングのリストを全体を通して繰返し、ＭＥＡＳＵＲＥ句の式の評価後に出力する。
Ｅｌｓｅ
readyToOutputBindings優先度キュー（matchedTsによってソート）を通して繰返し、そのmatchedTsが、doCommonProcessing()のステップ５（ｂ）で計算したminTs（区画を通して現在不確かなすべてのバインディングの中で最小のmatchedTs、これは、正しくない順
序でマッチが報告されるという問題を回避するのに必要）未満のマッチすべてを出力する。出力前にＭＥＡＳＵＲＥ句の式を評価する。
【０１７０】
ある実施形態において、上記ステップ３でコールされるdoCommonProcessing()関数で実
行される処理は次の通りである。
【０１７１】
doCommonProcessing()
注：「現在の区画」は、doNonEventProcessingを介してコールされる場合は最近の入力の区画とは異なる。
【０１７２】
１．「現在の区画」のすべてのアクティブバインディング（ターゲット時間の順で維持される）に対し、以下を実行する。
【０１７３】
（ａ）Ｉｆ（アクティブバインディングのターゲット時間＞現在の入力時間）ＡＮＤ
（現在の入力タプルはハートビートであるＯＲ最近の入力の区画以外の区画を処理している）であれば、ステップ２に進む。
【０１７４】
この理由は、もし現在のタプルの区画以外の区画が処理されているのであればまたは入力がハートビートであれば、ターゲット時間を終了したアクティブバインディングのみが対象になるからである。
【０１７５】
（ｂ）アクティブバインディングおよび（もし維持されていれば）対応するアクティブアイテムをデータ構造から削除する。
【０１７６】
（ｃ）Ｉｆ
１．不確かなバインディングはまだ発見されていない  ＯＲ
２．これまでのところ、不確かなバインディングは発見されたが現在のアクティブバインディングは不確かなバインディング（unsureBind）よりも先に開始されている。
【０１７７】
「unsureBind」は、ある入力で不確かになる可能性があるおそらく多数のバインディングの中でstartIndexが最も小さい不確かなバインディングへの参照を含む。開始時間が異なり継続時間が可変のバインディングは同時に終了する可能性があり（同一のターゲット時間を持つ可能性があり）これらの中で最長のもの（最も早く開始されたもの）が対象となる。
Ｔｈｅｎ
バインディングを処理する。処理するとは、ＡＬＬ  ＭＡＴＣＨＥＳケースにおけるように、現在の入力に対してバインディングがさらに発展できるか否か判断しようとすることを意味する。発展できるのであれば、新たに発展したアクティブバインディングを維持されているデータ構造に入れる。バインディングが不確かになれば、ブールの「foundMatch」を真に設定する。
Ｅｌｓｅ
バインディングは打切られる。
【０１７８】
２．  ステップ１（ｃ）でマッチが発見された場合、
（ａ）「unsureBind」(最長のマッチ）をunsureListに追加し、また、このデータ構
造が維持されているのであればunsureItemを追加する。
【０１７９】
（ｂ）最近の入力の区画が処理されており入力がハートビートでない場合は、後で、最近の入力がパターンの開始変数とマッチするか否か試す必要がある。これは、ブールの「applyS0trans」を真に設定することによって追跡される。
【０１８０】
（ｃ）ステップ１（ａ）で中止したのであれば、「現在の区画」の残りのアクティブバインディングを通して繰返しunsureBindよりも後に開始されたものすべてを削除する。（オーバラップするマッチはここでは認められないのでunsureBindよりも後に開始された
ものは削除しなければならない。）
（ｄ）また、「unsureBind」よりも後に開始されしたがって「unsureBind」よりも小さい、「現在の区画」の不確かなバインディングすべてを削除する。
【０１８１】
３．この時点で「現在の区画」内に残されたすべてのアクティブバインディングは、「unsureBind」よりも前に開始されている。第１のバインディングのstartIndexを取得しこれを「minActiveIndex」として設定する。残されているバインディングがなければ、「minActiveIndex」をLong.MAX_VALUEに設定する。この「minActiveIndex」は、「unsureBind」を出力できるか否か判定する際に使用される。
【０１８２】
４．Ｉｆ（applyS0Transがステップ２（ｂ）で設定される）  ＯＲ
（現在の区画が最近の入力の区画であり  ＡＮＤ  現在の入力がハートビートではなく
ＡＮＤ  ステップ１（ｃ）でマッチを発見していない）、then
現在の入力タプルをＰＡＴＴＥＲＮ句における第１の変数とマッチさせようとすることによりマッチをこのタプルで開始可能か否か判断する。
【０１８３】
Ｉｆ  ｙｅｓ，ｔｈｅｎ
継続時間句の式を現在のタプルの属性値を用いて評価し継続時間の値を計算する。
【０１８４】
これを現在のタプルのタイムスタンプに加算しその結果をこの新たなアクティブバインディングがについてのターゲット時間として設定する。
【０１８５】
このバインディングをこの区画のアクティブバインディングTreeSetに挿入する。ま
た、対応するActiveItemを構成しこれを(維持されていれば）ActiveItemsデータ構造に挿入する。
【０１８６】
５．Ｉｆ（partition byが指定されている）ｔｈｅｎ  InitReportBindings：
このステップを用いて、区画全体で順序が不正確なマッチを報告しないことを保証する。
【０１８７】
（ａ）「現在の区画」内のすべての不確かなバインディングについて、
バインディングがステップ（３）で計算された「minActiveIndex」よりも先に開始されているのであれば、これを不確かなもののリストから削除して「readyToOutputBINdings」キューに移動させる。このことは、この不確かなバインディングよりも先に開始され
たアクティブなバインディングはこの区画にはなくしたがってこのバインディングはreadyToOutputであることを意味する。
【０１８８】
Ｅｌｓｅ
この不確かなバインディングよりも先に開始されておりしたがって最長のマッチである可能性があるアクティブなバインディングがあり、これが将来完了すればこの不確かなバインディングはまだ出力の準備が整っていないことになる。
【０１８９】
（ｂ）すべての区画にわたってすべての不確かなバインディングの中で最小のmatchedTsにminTsを設定する。そうすると、バインディングが出力の準備ができているもののmatchedTs＜このバインディングのmatchedTsである不確かなバインディングがあれば、これは出力できない。これは、「minTs」によって処理されunsureItemを用いてminTsを直ちに計算する。
【０１９０】
６．現在の区画が空になっていれば（アクティブなバインディングは残されていない）、これを削除。
【０１９１】
ある実施形態において、上記ステップ４でコールされるdoNonEventProcessing()関数において実行される処理（区画、ＳＫＩＰ  ＰＡＳＴ  ＬＡＳＴ  ＲＯＷケース）は次のようなものであってもよい。
【０１９２】
doNonEventProcessing()
ターゲット時間＜＝現在の入力時間であるすべてのアクティブなアイテムについて、
（ターゲット時間を過ぎしたがって不確かになる、区画全体の本質的にすべてのアクティブなバインディング）以下の処理を行なう。
【０１９３】
（ａ）アクティブアイテムの（バインディングの）区画を「現在の区画」に設定。
（ｂ）doCommonProcessing()
上記のように、イベントなしマッチング処理におけるバインディングについてのＤＵＲＡＴＩＯＮ（継続時間）は、このバインディングを開始させたイベントの１つ以上の属性に基づいていてもよい。ある実施形態において、ＤＵＲＡＴＩＯＮの値の基になる属性は、入力イベントストリームのスキーマ自体の一部であってもよい。しかしながら、いくつかの実施形態において、このような属性は受信入力ストリームの一部でなくてもよい。このような一実施形態において、ＤＵＲＡＴＩＯＮ値を設定するために使用すべき１つ以上の属性は、イベントストリームに、元のストリームから新たなストリームを引出すことによって、加えられてもよい。継続時間の計算の基になるこの１つ以上の属性は、引出されたイベントストリームスキーマの一部である。
【０１９４】
図７は、本発明の実施形態に従い使用し得るシステム環境７００の構成要素を示す簡略化されたブロック図である。図に示されているように、システム環境７００は、１つ以上のクライアント計算装置７０２、７０４、７０６、７０８を含み、これら装置は、ウェブブラウザ、専用のクライアント（たとえばOracle Forms）等のクライアントアプリケーションを操作するように構成されている。さまざまな実施形態において、クライアント計算装置７０２、７０４、７０６、および７０８は、イベント処理システム７１２と情報をやり取りし得る。
【０１９５】
クライアント計算装置７０２、７０４、７０６、７０８は、汎用のパーソナルコンピュータ（例として、さまざまなバージョンのMicrosoft Windows（登録商標）および／また
はApple Macintosh（登録商標）オペレーティングシステムを実行するパーソナルコンピ
ュータおよび／またはラップトップコンピュータを含む）、携帯電話もしくはＰＤＡ（Microsoft Windows Mobile等のソフトウェアを実行し、インターネット、電子メール、ＳＭＳ、ブラックベリー（Blackberry）（登録商標）、またはその他の通信プロトコルを使用可能）、および／またはさまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを含むがこれに限定されない）のいずれかを実行するワークステーションコンピュータであってもよい。これに代えて、クライアント計算装置７０２、７０４、７０６、および７０８は、ネットワーク（たとえば以下で説明するネットワーク７１０）を通して通信可能なシンクライアントコンピュータ、インターネットを使用可能なゲーム機、および／またはパーソナルメッセージングデバイス等のその他の電子デバイスであってもよい。典型的なシステム環境７００が４つのクライアント計算装置とともに示されているが、クライアント計算装置の数はいくつであってもそれらをサポートし得る。センサ等を有する装置のような他の装置が、システム７１２と情報をやり取りしてもよい。
【０１９６】
ネットワーク７１０は、クライアント７０２、７０４、７０６、および７０８とイベント処理システム７１２との間でのデータの通信および交換を容易にし得る。ネットワーク７１０は、ＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、ＡｐｐｌｅＴａｌｋ等を含むがこれらに限定
されないさまざまな市販のプロトコルのいずれかを用いたデータ通信をサポートできる、当業者によく知られているネットワークであれば、どのような種類のネットワークであってもよい。単なる例として、ネットワーク７１０は、イーサネット（登録商標）ネットワーク、トークンリングネットワーク等のローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク、バーチャルプライベートネットワーク（ＶＰＮ）を含むがこれに限定されないバーチャルネットワーク、インターネット、イントラネット、エクストラネット、公衆電話交換回線網（ＰＳＴＮ）、赤外線ネットワーク、ワイヤレスネットワーク（たとえば、IEEE 802.1Xプロトコル群のいずれかの下で動作するネットワーク、当該技術
分野において公知のブルートゥース（登録商標）プロトコル、および／またはその他のワイヤレスプロトコル）、および／または、これらおよび／または他のネットワークの任意の組み合わせであってもよい。
【０１９７】
イベント処理システム７１２は１つ以上のコンピュータおよび／またはサーバを含み得る。これは、汎用コンピュータ、専用のサーバコンピュータ（例として、ＰＣサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式（rack-mounted）のサーバ等を含む）、サーバファーム、サーバクラスタ、またはその他の適切な配置および／または組み合わせであってもよい。さまざまな実施形態において、システム７１２は、本願のこれまでの開示において説明された１つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされていてもよい。
【０１９８】
システム７１２は、上述したオペレーティングシステムのうちのいずれかおよび任意の市販のサーバオペレーティングシステムを含むオペレーティングシステムを実行してもよい。また、システム７１２は、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、Ｊａｖａサーバ、およびデータベースサーバ等を含むさまざまなその他のサーバアプリケーション、および／またはミッドティア（mid-tier）アプリケーションのうちのいずれかを実行してもよい。典型的なデータベースサーバは、Ｏｒａｃｌｅ、Ｍｉｃｒｏｓｏｆｔ、Ｓｙｂａｓｅ、ＩＢＭ等から市販されているものを含むが、これらに限定されない。
【０１９９】
また、システム環境７００は１つ以上のデータベース７１４および７１６を含み得る。データベース７１４および７１６はさまざまな場所に存在し得る。例として、データベース７１４および７１６のうちの１つ以上は、システム７１２に対してローカルな（および／またはシステム７１２内に常駐している）記録媒体に存在していてもよい。これに代えて、データベース７１４および７１６は、システム７１２から離れていてネットワークベースまたは専用回線を介してシステム７１２と通信してもよい。一組の実施形態において、データベース７１４および７１６は、当業者によく知られているストレージエリアネットワーク（ＳＡＮ）に存在していてもよい。同様に、システム７１２による機能を実行するために必要なファイルは、必要に応じて、システム７１２に対してローカルにおよび／または遠隔で格納されてもよい。一組の実施形態において、データベース７１４および７１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、更新し、取出すようにされている、Ｏｒａｃｌｅ  １１ｇ等のリレーショナルデータベースを含み得る。
【０２００】
図８は、本発明のある実施形態に従い使用し得るコンピュータシステム８００の簡略化されたブロック図である。たとえば、システム８００を用いて図１に示されるイベント処理システム１００を実現してもよい。バス８２４を介して電気的に接続し得るさまざまな構成要素を含むコンピュータシステム８００が示されている。この構成要素は、１つ以上の処理部８０２と、入力サブシステム８０４と、出力サブシステム８０６と、記憶装置８０８と、コンピュータ読取可能な記録媒体８１０に接続されたコンピュータ読取可能記録媒体リーダ８１２と、通信サブシステム８１４と、処理加速サブシステム８１６と、ワーキングメモリ８１８とを含み得る。
【０２０１】
バスサブシステム８２４は、コンピュータシステム８００のさまざまな構成要素およびサブシステムを意図された通りに相互通信させるためのメカニズムを提供する。バスサブシステム８２４は概略的に１本のバスとして示されているが、これに代わるバスサブシステムの実施形態は複数のバスを利用してもよい。
【０２０２】
入力サブシステム８０４は、マウス、キーボード、ポインティングデバイス、タッチパッド等といった１つ以上の入力装置を含み得る。一般的に、入力サブシステム８０４は、コンピュータシステム８００に情報を入力するための装置またはメカニズムを含み得る。
【０２０３】
出力サブシステム８０６は、コンピュータシステム８００から情報を出力するための１つ以上の出力装置を含み得る。出力装置の例は、表示装置、プリンタ、投影装置等を含むがこれらに限定されない。一般的に、出力サブシステム８０６は、コンピュータシステム８００から情報を出力するための装置またはメカニズムを含み得る。
【０２０４】
処理部８０２は、１つ以上のプロセッサ、プロセッサの１つ以上のコア、およびその組み合わせ等を含み得る。いくつかの実施形態において、処理部８０２は、汎用一次プロセッサと、グラフィックプロセッサ、デジタル信号プロセッサ等といった１つ以上の専用コプロセッサとを含み得る。いくつかの実施形態において、処理部８０２のうちのいくつかまたはすべてを、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）のようなカスタマイズされた回路を用いて実現することができる。いくつかの実施形態において、このような集積回路は、回路そのものに格納された命令を実行する。他の実施形態において、処理部８０２は、ワーキングメモリ８１８にまたは記憶装置８０８に格納された命令を実行してもよい。さまざまな実施形態において、処理部８０２は、多様なプログラムまたはコード命令を実行することができ、現在実行している複数のプログラムまたはプロセスを管理することができる。どの時点でも、これから実行するプログラムコードのうちのいくつかまたはすべては、システムワーキングメモリ８１８、記憶装置８０８、および／またはコンピュータ読取可能な記録媒体８１０に常駐していてもよい。適切なプログラミングによって、処理部８０２は、イベントストリームに関連する処理を実行するための上記さまざまな機能を提供することができる。いくつかの実施形態において、コンピュータシステム８００はまた、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサ、および／またはそれと同様のものを含み得る処理加速部８１６を含んでいてもよい。
【０２０５】
記憶装置８０８は、ディスクドライブ、光学式記憶装置等のメモリデバイス、ならびに、プログラム可能で、一瞬で更新可能で（flash-updatable）、および／またはそれと同
じようなことが可能なランダムアクセスメモリ（ＲＡＭ）および／または読出専用メモリ（ＲＯＭ）等のソリッドステート記憶装置を含み得る。処理部８０２によって実行されると上記機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、記憶装置８０８に格納されてもよい。記憶装置８０８も、本発明の実施形態に従い使用されるデータを格納するためのリポジトリを提供し得る。
【０２０６】
コンピュータ読取可能記録媒体リーダ８１２はさらに、コンピュータ読取可能な記録媒体８１０に接続されてもよい。コンピュータ読取可能な記録媒体８１０はともに、（かつ任意に記憶装置８０８と組み合わせて）リモート式、ローカル式、固定式および／または着脱交換式の記憶装置、および、一時的および／またはより永続的にコンピュータ読取可能な情報を収容するための記録媒体を総合的に意味している。
【０２０７】
通信サブシステム８１４によって、ネットワーク７１０および／またはシステム環境７００に関連する上述のその他のコンピュータと、データをやり取りすることが可能であってもよい。通信サブシステム８１４は、コンピュータシステム８００からの他のシステム
からデータを受信しこのシステムにデータを送信するためのインターフェイスの役割を果たす。通信は、有線または無線プロトコルを用いて提供し得る。たとえば、通信サブシステム８１４によって、コンピュータ８００がインターネットを介してクライアント装置と接続できるようにしてもよい。通信サブシステム８１４は、モデム、ネットワークカード（無線または有線）、赤外線通信装置、ＧＰＳ受信機等を含み得る。
【０２０８】
ワーキングメモリサブシステム８１８は、プログラム実行中の命令およびデータの格納のためのメインランダムアクセスメモリ（ＲＡＭ）と、固定命令が格納される読出専用メモリ（ＲＯＭ）とを含み得る。オペレーティングシステム８２０および／またはアプリケーションプログラム（クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、ＲＤＢＭＳ等であってもよい）等のその他のコード８２２は、ワーキングメモリ８１８に格納されていてもよい。典型的な実施形態において、ワーキングメモリ８１８は、上記のようにイベントを処理し継続時間可変のウィンドウ処理を可能にするために使用される、実行可能なコードおよび関連するデータ構造（キャッシュ等）を含み得る。
【０２０９】
コンピュータシステム８００の代替実施形態は、数多くの変形を伴う、上記構成要素よりも多いまたは少ない構成要素を有し得ることが、理解されるはずである。たとえば、カスタマイズされたハードウェアを使用してもよく、および／または特定の要素を、ハードウェア、ソフトウェア（アプレット等のポータブルソフトウェアを含む）、またはこれら双方で実現してもよい。さらに、ネットワーク入出力装置等の他の計算装置との接続を用いてもよい。
【０２１０】
図９は、本発明のある実施形態に従い使用し得る計算装置９００の簡略化されたブロック図である。計算装置９００のブロックを、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせにおいて実現することによって本発明の原理を実行してもよい。図９に示されるブロックを組み合わせるまたはサブブロックに分離することによって上記本発明の原理を実行してもよいことが、当業者には理解される。したがって、本明細書での説明は、本明細書に記載の機能ブロックの可能な組み合わせまたは分離またはさらに他の定義を裏付け得るものである。
【０２１１】
図９に示されるように、示されている計算装置９００は、第１の決定部９０１と、第２の決定部９０２と、第１の計算部９０３と、第２の計算部９０４とを含む。任意で、計算装置９００はまた、第１の評価部９０５と、第２の評価部９０６と、出力部９０７と、第１の関連付け部９０８と、第２の関連付け部９０９とを含み得る。
【０２１２】
一実施形態において、第１の決定部は、イベントストリームを介して計算装置が受信した第１のイベントがあるパターンに対する第１のパターンマッチ候補を開始させるか否か決定するように構成されてもよい。第１の計算部９０３は、第１のパターンマッチ候補について第１の継続時間を計算するように構成されてもよい。第２の決定部９０２は、イベントストリームを介して受信した第２のイベントがパターンに対する第２のパターンマッチ候補を開始させるか否か決定するように構成されてもよい。第２の計算部９０４は、第２のパターンマッチ候補について第２の継続時間を計算するように構成されてもよい。第２の継続時間は第１の継続時間とは異なる。
【０２１３】
一実施形態において、第１の決定部９０１は、第１のイベントの属性の第１の値を決定するように構成されてもよい。第１の計算部９０３は、第１の値を用いて第１の継続時間を計算するように構成されてもよい。第２の決定部９０２は、第２のイベントの属性の第２の値を決定するように構成されてもよい。第２の値は第１の値とは異なっていてもよい。第２の計算部９０４は、第２の値を用いて第２の継続時間を計算するように構成されて
もよい。
【０２１４】
一実施形態において、第１の決定部９０１は、第１のイベントの属性の第１の値を決定するように構成されてもよい。第１の評価部９０５は、第１の値を用いて式を評価することにより第１の継続時間を計算するように構成されてもよい。第２の決定部９０２は、第２のイベントの属性の第２の値を決定するように構成されてもよい。第２の値は第１の値とは異なっていてもよい。第２の評価部９０６は、第２の値を用いて式を評価することにより第２の継続時間を計算するように構成されてもよい。
【０２１５】
一実施形態において、第１の決定部９０１は、第１のイベントについての第１の継続時間の経過後に、第１のパターンマッチ候補がパターンとマッチしているか否か決定するように構成されてもよい。出力部９０７は、第１のパターンマッチ候補がパターンとマッチしていると決定されると、第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するように構成されてもよい。
【０２１６】
一実施形態において、第１の決定部９０１は、第１のイベントに関連付けられた第１の時間と第１の継続時間とに基づいて第１のパターンマッチ候補についての第１の終了時間を決定するように構成されてもよい。第１の関連付け部９０８は、第１の終了時間を、第１のパターンマッチ候補に関連付けるように構成されてもよい。第２の決定部９０２は、第２のイベントに関連付けられた第２の時間と第２の継続時間とに基づいて第２のパターンマッチ候補についての第２の終了時間を決定するように構成されてもよい。第２の関連付け部９０９は、第２の終了時間を第２のパターンマッチ候補に関連付けるように構成されてもよい。
【０２１７】
一実施形態において、第１の決定部９０１は、第１のイベントに関連付けられた第１の時間に第１の継続時間を加算することによって第１の終了時間を決定するように構成されてもよい。第２の決定部９０２は、第２のイベントに関連付けられた第２の時間に第２の継続時間を加算することによって第２の終了時間を決定するように構成されてもよい。
【０２１８】
一実施形態において、第１の決定部９０１は、第１のパターンマッチ候補に関連付けられた第１の終了時間にまたはその後に、第１のパターンマッチ候補がパターンとマッチしているか否か決定するように構成されてもよい。出力部９０７は、第１のパターンマッチ候補がパターンとマッチしていると判断されると、第１のパターンマッチ候補に対応するイベントなしの発生を示す情報を出力するように構成されてもよい。
【０２１９】
本発明の特定の実施形態について説明してきたが、さまざまな修正、変更、代替構成、および均等物も、本発明の範囲に包含される。本発明の実施形態は、ある特定のデータ処理環境内での動作に限定されるものではなく、複数のデータ処理環境内で自在に機能する。加えて、本発明の実施形態について、特定の一連のトランザクションおよびステップを用いて説明してきたが、本発明の範囲が、記載されている一連のトランザクションおよびステップに限定されないことは、当業者には明らかなはずである。
【０２２０】
さらに、本発明の実施形態について、ハードウェアとソフトウェアの特定の組み合わせを用いて説明してきたが、ハードウェアとソフトウェアの他の組み合わせも本発明の範囲内であることが認識されるはずである。本発明の実施形態は、ハードウェアのみで実現されてもよく、ソフトウェアのみで実現されてもよく、これらの組み合わせを用いて実現されてもよい。本明細書に記載のさまざまなプロセスは、同一のプロセッサ上で実現されてもよく、または任意に組み合わされた異なるプロセッサ上で実現されてもよい。したがって、構成要素またはモジュールが、特定の動作を実行するように構成されているという記載があった場合、このような構成は、たとえば、電子回路をこの動作を実行するように設
計することによって、または、プログラム可能な電子回路（マイクロプロセッサ等）をこの動作を実行するようにプログラムすることによって、または、これらを任意に組み合わせて実現することができる。プロセスは従来のプロセス間通信の技術を含むがこれに限定されないさまざまな技術を用いて通信することができ、異なるプロセス対は異なる技術を使用してもよく、または、同一のプロセス対が異なる技術を異なる時間に使用してもよい。
【０２２１】
明細書および図面はしたがって、限定的な意味ではなく例示的な意味で考慮されねばならない。しかしながら、これに対し、追加、控除、削除、およびその他の修正および変更を、請求項に記載のより広い精神および範囲から逸脱することなく行ない得ることは明らかであろう。このように、具体的な発明の実施形態について説明してきたが、これは限定を意図したものではない。さまざまな変形および均等物は以下の請求項の範囲に含まれる。
【図１】
2019125383.tif 000007
【図２】
2019125383.tif 000008
【図３】
2019125383.tif 000009
【図４】
2019125383.tif 000010
【図５】
2019125383.tif 000011
【図６】
2019125383.tif 000012
【図７】
2019125383.tif 000013
【図８】
2019125383.tif 000014
【図９】
2019125383.tif 000015
【手続補正書】
【提出日】平成31年4月4日(2019.4.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
方法であって、
計算装置によって、イベントストリームを介して前記計算装置が受信した第１のイベントがパターンに対する第１のパターンマッチ候補を開始させると決定することと、
前記計算装置によって、前記第１のパターンマッチ候補についての第１の継続時間を計算することと、
前記計算装置によって、前記イベントストリームを介して受信した第２のイベントが前記パターンに対する第２のパターンマッチ候補を開始させると決定することと、
前記計算装置によって、前記第２のパターンマッチ候補についての第２の継続時間を計算することとを含み、前記第２の継続時間は前記第１の継続時間とは異なる、方法。
【外国語明細書】
2019125383000001.pdf