JP2012198714A - イベント処理方法、イベント処理装置及びイベント処理プログラム - Google Patents

Abstract

【課題】複数のイベント送信側機器から受信したイベント群を発生時刻順に並び替えて提供する際に、イベントの受信時刻から提供時刻までの時間差が長くなる（イベントの鮮度が低下する）ことを抑制する。
【解決手段】イベント処理装置１０は、複数の機器から受信した各受信イベントをバッファに格納する。そして、イベント処理装置１０は、受信イベントの送信元機器以外の相手方機器ごとに待ち時間を設定する。そして、イベント処理装置１０は、相手方機器ごとの待ち時間内に相方手機器からイベントを受信したか、または待ち時間が超過したかによって、受信イベントの送信元機器と相手方機器との２機器間の発生順序判定を確定する。そして、イベント処理装置１０は、バッファに格納された受信イベントのうち、受信イベントの送信元機器と、他の全ての相手方機器との間で発生順序が確定されたイベントを発生時刻順に送信する。
【選択図】図２

Description

本発明は、イベント処理方法、イベント処理装置及びイベント処理プログラムに関する。

ネットワークに接続された複数の情報源（例えば、コンピュータ、各種の機器、各種のセンサ等）から出力されたイベントをサーバで処理するイベント処理技術がある。近年、ネットワーク技術の発展と、情報源の多様化に伴い、様々な情報源が送信するイベントに基づき、サーバで逐次に判断処理を行うイベント処理技術が利用され始めている。

イベント処理技術は、例えば、市場動向をもとに株式売買を行うアルゴリズムトレーディングシステムで利用される。また、ゲームの操作情報をもとにゲームの進行管理を行うオンラインゲームシステム、車両の位置情報をもとに渋滞マップを作成する渋滞マップ作成サーバ、圃場環境の観測情報や作業者の入力情報をもとに圃場作業を支援する圃場支援システム等で利用される。

これらのシステムでは、複数の情報源から送信されたイベントがサーバに受信された時に、イベントの発生順序と受信順序が一致しない場合、イベントに基づいた適切な判断処理が行えないという不都合がある。そこで、複数の情報源から送信されたイベントがサーバに受信されたときに、イベントを発生順序で並び替える従来技術がある。

この従来技術では、イベントを送信する各イベント送信側計算機と、イベントを受信するイベント受信側計算機の間で計測された通信遅延時間の最大値と最小値の差を最大通信遅延時間差とする。そして、イベント受信側計算機は、常に最大通信遅延時間差だけイベントの受信を待ち合わせた後に、受信したイベントを発生順序で並び替えた上で、判断処理を行う処理ルーチンへ提供する。

特開２００６−１１６８３号公報

しかしながら、上記の従来技術では、最大通信遅延時間差だけイベントの受信を待つ間に、既に受信したイベントが時間的に古い情報となってしまうという問題があった。すなわち、上記の従来技術では、イベント受信側計算機は、最大通信遅延時間差だけ時間が経過する以前に全てのイベント送信側計算機からのイベントが揃った場合でもなお、最大通信遅延時間差だけ時間が経過するまで待機する。よって、待機時間を経たイベントは、時間的に古い、鮮度が低下したイベントとなってしまう。処理ルーチンは、提供されたイベントが、鮮度が低下したイベントであると、このイベントに基づいて適切な判断処理を行うことができない。

開示の技術は、上記に鑑みてなされたものであって、複数のイベント送信側機器から受信したイベント群を発生時刻順に並び替えて提供する際に、イベントの受信時刻から提供時刻までの時間差が長くなる（イベントの鮮度が低下する）ことの抑制を目的とする。

開示の技術に係るイベント処理方法では、先ず、複数の機器から受信した各受信イベントをバッファに格納する。そして、受信イベントの送信元機器以外の相手方機器ごとに待ち時間を設定する。そして、相手方機器ごとの待ち時間内に相方手機器からイベントを受信したか、または待ち時間が超過したかによって、受信イベントの送信元機器と相手方機器との２機器間の発生順序判定を確定する。そして、バッファに格納された受信イベントのうち、受信イベントの送信元機器と、他の全ての相手方機器との間で発生順序が確定されたイベントを、発生時刻順に送信する。

開示の技術によれば、イベントの受信時刻から提供時刻までの時間差が長くなる（イベントの鮮度が低下する）ことを抑制できる。

図１は、イベント処理システムの構成を示す図である。 図２は、イベント処理装置の構成を示す機能ブロック図である。 図３は、待ち時間管理テーブルの一例を示す図である。 図４は、順序整列用管理テーブルの一例を示す図である。 図５は、イベント受信時の処理例を説明する図である。 図６は、イベント発生順序判定処理（イベント受信時）の処理例を説明する図である。 図７は、イベント発生順序判定処理（タイムアウト時）の処理例を説明する図である。 図８は、イベント処理装置における処理を示すタイムチャートの一例を示す図である。 図９は、イベント発生順序判定処理（イベント受信時）を示すフローチャートである。 図１０は、イベント発生順序判定処理（タイムアウト時）を示すフローチャートである。 図１１Ａは、イベント送信側機器の追加時の処理（待ち時間管理テーブル関連）を説明する図である。 図１１Ｂは、イベント送信側機器の追加時の処理（順序整列用管理テーブル関連）を説明する図である。 図１２は、イベント処理プログラムを実行するコンピュータの一例を示す図である。 図１３は、実施例１を説明する図である。 図１４は、実施例２を説明する図である。 図１５は、実施例３を説明する図である。

以下に、開示の技術に係るイベント処理方法、イベント処理装置及びイベント処理プログラムの実施の形態を図面に基づいて説明する。なお、以下の実施の形態は、開示の技術を限定するものではない。

［システム構成］
図１は、イベント処理システムの構成を示す図である。イベント処理システム１では、イベント処理装置１０と、イベント送信側機器３０Ａ〜３０Ｃが、ネットワーク３を介して通信可能に接続される。ネットワーク３は、有線もしくは無線の、公衆網又は閉域網の任意の通信網である。また、イベント処理システム１では、イベント処理装置１０と、イベント処理アプリケーションサーバ２０とが通信可能に接続される。

イベント送信側機器３０Ａ〜３０Ｃは、各々で発生したイベントをイベント処理装置１０へ送信する情報源であり、例えばコンピュータ、各種の機器、各種のセンサ等である。イベント送信側機器３０Ａ〜３０Ｃは、イベント処理装置１０において互いのイベントの受信を待ち合せるグループをなす。なお、イベント送信側機器３０Ａ〜３０Ｃを総称する場合、イベント送信側機器３０と呼ぶこととする。

実施の形態において、イベント処理装置１０が受信したイベントの発生順序を判定して確定させるために着目するイベントを自イベントと呼ぶこととする。また、イベント処理装置１０へ自イベントを送信した送信側機器３０を送信元機器と呼ぶこととする。また、イベントを待ち合せるグループ内の送信元機器以外のイベント送信側機器３０を相手方機器と呼ぶこととする。また、相手方機器がイベント処理装置１０へ送信するイベントを相手イベントと呼ぶこととする。相手イベントは、イベント処理装置１０が自イベントとの発生順序の判定対象とするイベントである。

具体的には、イベント送信側機器３０Ａ〜３０Ｃのグループにおいて、イベント送信側機器３０Ａを送信元機器と呼ぶこととする場合、イベント送信側機器３０Ｂ、３０Ｃが相手方機器である。また、イベント送信側機器３０Ａがイベント処理装置１０へ送信するイベントを自イベントと呼ぶこととする場合、イベント送信側機器３０Ｂ、３０Ｃがイベント処理装置１０へ送信するイベントが相手イベントである。イベント送信側機器３０Ｂ、イベント送信側機器３０Ｃについても同様である。

イベント処理装置１０は、イベント送信側機器３０Ａ〜３０Ｃから受信したイベントを発生順序で並び替えて、イベント処理アプリケーションサーバ２０へ出力するコンピュータ等である。なお、実施の形態で「イベントの受信」という場合、イベント送信側機器３０Ａ〜３０Ｃから送信されたイベントが、イベント処理装置１０により受信されることをいう。イベント処理アプリケーションサーバ２０は、イベント処理装置１０から出力されたイベントをもとに各種の判断処理を行うコンピュータ等である。

なお、図１では、３台のイベント送信側機器３０Ａ〜３０Ｃ、１台のイベント処理装置１０、１台のイベント処理アプリケーションサーバ２０を図示するが、開示のイベント処理システム１は、図１の構成に限定されない。すなわち、イベント処理システム１は、２台以上のイベント送信側機器、任意の数のイベント処理装置及び任意の数のイベント処理アプリケーションサーバを含んでもよい。

以下の説明では、イベント処理システム１は、次の（１）〜（３）を満たすことを前提とする。
（１）イベント送信側機器３０と、イベント処理装置１０の間でシステム時刻が同期している。
（２）イベント送信側機器３０は、発生時刻の順序で、イベントをイベント処理装置１０へ送信する。イベント送信側機器３０が、イベントを一旦蓄積し、蓄積した複数のイベントを一括してイベント処理装置１０へ送信する場合も同様である。
（３）イベント送信側機器３０から送信されたイベントは、同一のイベント送信側機器３０から先行して送信された他のイベントよりも先にイベント処理装置１０に受信されることはない。すなわち、同一のイベント送信側機器３０からのイベントは、発生時刻の順序でイベント処理装置１０に受信される。

次に、各イベント送信側機器３０から送信されるイベントがイベント処理装置１０に受信されるまでに生じるイベントの発生時刻と、受信時刻との時間差であるタイムラグについて説明する。各イベント送信側機器３０からイベント処理装置１０へ送信されたイベントは、タイムラグにより、イベントの発生順序でイベント処理装置１０に受信されるとは限らない。

上記のタイムラグは、様々な要因で発生する。要因は、イベント送信側機器３０とイベント処理装置１０間の伝送遅延、イベント送信側機器３０又はイベント処理装置１０とネットワーク３の接続断、ネットワーク３内の通信断、イベント送信側機器３０におけるイベント発生から送信までの遅延等である。各イベント送信側機器３０におけるイベント発生からイベント送信までの遅延は、イベント送信側機器３０内で、イベントを検出後、一定期間保持してから送信する場合等に発生する。

これら様々な要因から、各イベント送信側機器３０においてイベントが発生してから、イベントがイベント処理装置１０に受信されるまでに、長短様々なタイムラグが発生する。このため、イベント処理装置１０が、受信順序でイベントをイベント処理アプリケーションサーバ２０へ出力した場合、複数のイベント間で発生時刻と受信時刻との順序の逆転が生じる場合がある。複数のイベント間で発生時刻と受信時刻との順序に逆転が生じた場合、イベント処理アプリケーションサーバ２０は、イベントに基づいた適切な判断処理ができない。

そこで、イベント処理装置１０は、バッファに自イベントとして格納したイベントごとに、相手方機器から送信される相手イベントの受信を待ち合せるイベント待ち時間を相手方機器ごとに設定する。そして、イベント処理装置１０は、自イベントごと、かつ相手方機器ごとに設定されたイベント待ち時間だけ、相手方機器からの相手イベントの受信を待つ。

そして、イベント処理装置１０は、イベント待ち時間以内に相手方機器から相手イベントを受信するか、相手イベントのイベント待ち時間を超過した場合、バッファに格納した自イベントについて、送信元機器と相手方機器との間で順序を判定して確定させる。イベント処理装置１０は、バッファに格納した各イベントについて、送信元機器と相手方機器との間の順序の判定を繰り返し、送信元機器と全ての相手方機器と間の順序を確定させる。

そして、イベント処理装置１０は、バッファに格納したイベントのうち、送信元機器と全ての相手方機器との間の順序を確定させたイベントを、イベントの発生順序でイベント処理アプリケーションサーバ２０へ出力する。これにより、イベント処理装置１０は、タイムラグが最も長い相手方機器からの相手イベントの受信を待ち合わせずとも、自イベントと相手イベントとの順序の逆転を是正するので、相手イベントの受信の待機時間を低減でき、イベントの鮮度の低下を抑制できる。

［イベント処理装置の構成］
図２は、イベント処理装置の構成を示す機能ブロック図である。イベント処理装置１０は、受信部１１、待ち時間設定部１２、バッファリング部１３、イベント発生順序判定部１４、記憶部１５を有する。記憶部１５は、待ち時間管理テーブル１５ａ、順序整列用管理テーブル１５ｂをさらに有する。以降では、図２と図８を用いて、処理の流れの概要を説明する。

受信部１１は、イベント送信側機器３０からイベントを受信する（ステップＳ１０１（図８参照、以下同様））。受信部１１は、イベント送信側機器３０からイベントを受信すると、待ち時間設定部１２にイベントの送信元機器、イベントの発生時刻、イベントの受信時刻を通知（ステップＳ１０２）後、受信イベントをバッファリング部１３へ送信する（ステップＳ１０３）。なお、受信部１１は、受信イベントに一意のイベント識別情報を付与してバッファリング部１３へ送信する。

ステップＳ２０１では、待ち時間設定部１２は、受信部１１から受信を通知されたイベントの発生時刻とイベントの受信時刻との時間差をタイムラグとして算出する。そして、待ち時間設定部１２は、受信を通知されたイベントの送信元機器であるイベント送信側機器３０ごとにタイムラグを管理し、タイムラグの最大値を、該当するイベント送信側機器３０からのイベント受信を待つイベント待ち時間と決定する。そして、待ち時間設定部１２は、該当するイベント送信側機器３０を一意に識別する識別情報に決定したイベント待ち時間を対応付けて待ち時間管理テーブル１５ａに登録する（以上、ステップＳ２０１）。

なお、待ち時間設定部１２が、ステップＳ２０１において、イベント待ち時間を決定する方法は、次の様にしてもよい。ここで、イベント処理装置１０の電源投入直後等は、各イベント送信側機器３０に対応するイベント待ち時間として、初期値が待ち時間管理テーブル１５ａに登録されるとする。なお、初期値は、所定値、もしくは既に設定されている他のイベント送信側機器３０のイベント待ち時間に基づく統計値（最小値、最大値、中央値、最頻値、平均等）としてもよい。

すなわち、待ち時間設定部１２は、受信部１１から受信を通知されたイベントの発生時刻とイベントの受信時刻に基づくタイムラグを算出する。そして、待ち時間設定部１２は、待ち時間管理テーブル１５ａを参照し、タイムラグと、受信部１１から受信を通知されたイベントの送信元機器であるイベント送信側機器３０に対応するイベント待ち時間とを比較する。そして、待ち時間設定部１２は、タイムラグが、待ち時間管理テーブル１５ａに登録されている受信時間を上回る場合、タイムラグで、該当するイベント送信側機器３０に対応するイベント待ち時間を更新する。

なお、待ち時間設定部１２は、イベント送信側機器３０ごとに、過去の全てのタイムラグを履歴として蓄積しておき、最新のタイムラグが、履歴に基づく統計的な外れ値である場合、最新のタイムラグでイベント待ち時間を更新しないとしてもよい。そして、最新のタイムラグが統計的な外れ値である場合、待ち時間設定部１２は、最新のタイムラグを蓄積しないとしてもよい。

例えば、待ち時間設定部１２は、イベント送信側機器３０ごとに、過去の一定期間のタイムラグを時系列に並べた場合のタイムラグの変化量もしくは変化率をヒストグラムとして蓄積する。そして、待ち時間設定部１２は、最新のタイムラグと同一値もしくは一定範囲内で近似する値の出現度数が一定数未満の場合、最新のタイムラグを外れ値としてもよい。

または、待ち時間設定部１２は、最新のタイムラグが、イベント送信側機器３０ごとの所定の閾値を超えるか否かを判定し、所定の閾値を超える場合に、最新のタイムラグを外れ値としてもよい。または、待ち時間設定部１２は、イベント送信側機器３０ごとに、タイムラグの履歴の平均と、最新のタイムラグとの差である偏差の絶対値を、タイムラグの履歴の標準偏差で割った統計値が所定値を超える場合、最新のタイムラグを外れ値としてもよい。例えば、所定値が“３”の場合は、いわゆる“３σの法則”に従って外れ値を除外することになる。

この様に、最新のタイムラグが統計的な外れ値である場合、最新のタイムラグで待ち時間管理テーブル１５ａに登録されているイベント送信側機器３０に対応するイベント待ち時間を更新しないことにより、イベント待ち時間の精度が低下することを防止できる。

バッファリング部１３は、受信部１１から受信したイベントを蓄積（バッファリング）する（ステップＳ３０１）。また、バッファリング部１３は、受信部１１からイベントを受信したことをイベント発生順序判定部１４へ通知する（ステップＳ３０２）。また、バッファリング部１３は、イベント発生順序判定部１４からの通知に応じて、発生順序が確定されたイベントをイベント処理アプリケーションサーバ２０へ出力する（ステップＳ３０３）。

イベント発生順序判定部１４は、イベント送信側機器３０からのイベントの受信（ステップＳ４０１）もしくは後述のタイマのタイムアウト（ステップＳ４０８Ｙｅｓ）を契機として、各イベントについて、送信元機器と相手方機器の順序の判定を繰り返す。そして、イベント発生順序判定部１４は、送信元機器と全ての相手方機器の順序を確定させる（ステップＳ４０５、ステップＳ４０９）。そして、イベント発生順序判定部１４は、送信元機器と全ての相手方機器との間の順序が確定されたイベントをイベント処理アプリケーションサーバ２０へ出力する様にバッファリング部１３に対して通知する（ステップＳ４１１）。

具体的には、イベント発生順序判定部１４は、バッファリング部１３からイベントの受信を通知されると、通知されたイベントに対応する新規レコードを順序整列用管理テーブル１５ｂに挿入する（ステップＳ４０４）。なお、イベント発生順序判定部１４は、イベントの発生時刻の昇順で整列しながら新規レコードを順序整列用管理テーブル１５ｂに挿入する。

イベント発生順序判定部１４は、受信イベントに対応する新規レコードを順序整列用管理テーブル１５ｂに挿入する際、待ち時間管理テーブル１５ａから各相手方機器の待ち時間を取得する（ステップＳ４０２）。そして、イベント発生順序判定部１４は、受信イベントの発生時刻に各相手方機器の待ち時間をそれぞれ加算した時刻を、各相手方機器からの相手イベントの受信待ち上限時刻とする（ステップＳ４０３）。そして、イベント発生順序判定部１４は、受信イベントの受信時刻及び各相手方機器からの相手イベントの受信待ち上限時刻を、受信イベントに対応する新規レコードに登録する（ステップＳ４０４）。

イベント発生順序判定部１４は、受信イベントに対応する新規レコードを挿入する際、受信イベントと、相手イベントについて、受信イベントの送信元機器と相手方機器との間の順序を判定する（ステップＳ４０５）。そして、イベント発生順序判定部１４は、受信イベントは、相手イベントとの間の順序が確定したか否かを判定する（ステップＳ４０６）。

また、イベント発生順序判定部１４は、受信イベントに対応する新規レコードを挿入する際、受信イベントについて、相手方機器に対応する相手イベントの受信待ち上限時刻に基づくタイマの計時を開始する（ステップＳ４０７）。そして、イベント発生順序判定部１４は、タイマの計時がタイムアウトすると（ステップＳ４０８Ｙｅｓ）、受信イベントと、タイムアウトした相手方機器であるイベント送信側機器３０に対応する相手イベントとの間の順序を判定する（ステップＳ４０９）。

上記の様にして、イベント発生順序判定部１４は、全ての相手方機器に対応する相手イベントの受信待ち上限時刻が“順序判定済”となったイベント（ステップＳ４１０Ｙｅｓ）を順序確定済のイベントとしてバッファリング部１３に通知する（ステップＳ４１１）。

なお、受信部１１及びバッファリング部１３は、複数の機器からイベントを受信した各受信イベントをバッファに格納する受信部の一例である。待ち時間設定部１２は、受信イベントの送信元機器以外の相手方機器ごとに待ち時間を設定する待ち時間設定部の一例である。バッファリング部１３及びイベント発生順序判定部１４は、バッファに格納された受信イベントのうち、受信イベントの送信元機器と、他の全ての相手方機器との間で発生順序が確定されたイベントを、発生時刻順に送信する送信部の一例である。

なお、受信部１１、待ち時間設定部１２、バッファリング部１３、イベント発生順序判定部１４は、一例として、ＡＳＩＣ、ＣＰＵ、ＭＰＵ等の集積回路で実現できる。ＡＳＩＣは“Application Specific Integrated Circuit”、ＣＰＵは“Central Processing Unit”、ＭＰＵは“Micro Processing Unit”の略である。また、記憶部１５は、一例として、ＲＡＭ（Random Access Memory）、フラッシュメモリ（flash memory）、磁気ディスク、光ディスク、光磁気ディスク等を記憶媒体とする記憶装置で実現できる。

［待ち時間管理テーブル］
図３は、待ち時間管理テーブルの一例を示す図である。図３に示す様に、待ち時間管理テーブル１５ａでは、「イベント送信側機器」と、「イベント待ち時間」のカラムを有する。待ち時間管理テーブル１５ａでは、「イベント送信側機器」の値と、「イベント待ち時間」の値が対応付けられて管理される。

「イベント送信側機器」は、イベント送信側機器を一意に識別する識別情報を示す。「イベント待ち時間」は、対応するイベント送信側機器３０が相手方機器である場合に、自イベントがイベント処理装置１０により受信されたとき、自イベントの発生時刻を開始時点として、イベント処理装置１０による相手イベントの受信を待つ時間を示す。

図３に示す例では、イベント送信側機器３０Ａに、イベント待ち時間として時間“ｗ１”が対応付けられている。これは、イベント送信側機器３０Ａが相手方機器である場合、イベント処理装置１０は、自イベントがイベント処理装置１０により受信されたときを開始時点として、時間“ｗ１”だけイベント送信側機器３０Ａからのイベント受信を待つことを意味する。イベント送信側機器３０Ｂ、３００Ｃについても同様である。

なお、待ち時間管理テーブル１５ａは、互いにイベントを待ち合せるイベント送信側機器３０のグループごとにテーブルを分けて作成されてもよい。または、待ち時間管理テーブル１５ａは、互いにイベントを待ち合せるイベント送信側機器３０のグループの別なく一つのテーブルで作成されてもよい。または、待ち時間管理テーブル１５ａは、互いにイベントを待ち合せるイベント送信側機器３０のグループを一意の識別情報で識別可能にして、異なるグループのイベント送信側機器３０に対応する「イベント待ち時間」を一つのテーブルで管理するとしてもよい。

［順序整列用管理テーブル］
図４は、順序整列用管理テーブルの一例を示す図である。図４に示す様に、順序整列用管理テーブル１５ｂは、受信イベントごとに、「発生時刻」、「受信時刻」、「送信元機器」、「イベント識別情報」、「イベント待ち上限時刻（受信時刻）」のカラムを有する。順序整列用管理テーブル１５ｂでは、「発生時刻」の値、「受信時刻」の値、「送信元機器」の値、「イベント識別情報」の値、「イベント待ち上限時刻（受信時刻）」の値が対応付けられて管理される。

さらに、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」のカラムは、イベント送信側機器ごとにカラムを有し、イベント送信側機器ごとに「イベント待ち上限時刻（受信時刻）」の値が管理される。

「イベント発生時刻」は、順序整列用管理テーブル１５ｂにおいて、該当するイベントが発生した時刻を示す。「受信時刻」は、順序整列用管理テーブル１５ｂにおいて、該当するイベントがイベント処理装置１０により受信された時刻を示す。「送信元機器」は、順序整列用管理テーブル１５ｂにおいて、該当するイベントを送信したイベント送信側機器３０を示す。「イベント識別情報」は、順序整列用管理テーブル１５ｂにおいて、該当するイベントを一意に識別する識別情報を示す。

「イベント待ち上限時刻（受信時刻）」は、イベント送信側機器が、該当するイベントを送信した送信元機器の場合には、イベントの受信時刻を示す。また、「イベント待ち上限時刻（受信時刻）」は、イベント送信側機器が相手方機器である場合には、イベント処理装置１０が相手方機器からの相手イベントの受信を待つ上限時刻を示す。

図４に示す例では、「イベント識別情報」“ｅ２”のイベントを自イベントと呼ぶこととする場合、「イベント識別情報」“ｅ１”のイベントが、発生順序の判定対象である相手イベントである。この場合、自イベントの「発生時刻」は“ｔ０”、「受信時刻」は“ｔ４”、「送信元機器」は“イベント送信側機器３０Ｂ”である。また、自イベントは、「イベント待ち上限時刻」“ｔ０＋ｗ１”まで、相手方機器であるイベント送信側機器３０Ａからの相手イベントの受信を待つことを示す。同様に、自イベントは、「イベント待ち上限時刻」“ｔ０＋ｗ３”まで、相手方機器であるイベント送信側機器３０Ｃからの相手イベントの受信を待つことを示す。

また、「イベント識別情報」“ｅ２”のイベントは、“イベント送信側機器３０Ｂ”を送信元機器とするイベントであるので、「イベント待ち上限時刻（受信時刻）」のイベント送信側機器３０Ｂに対応させて、自イベントの「受信時刻」“（ｔ４）”が登録される。

同様に、図４に示す例では、「イベント識別情報」“ｅ１”のイベントを自イベントと呼ぶこととする場合、「イベント識別情報」“ｅ２”のイベントが、発生順序の判定対象である相手イベントである。この場合、自イベントの「発生時刻」は“ｔ１”、「受信時刻」は“ｔ３”、「送信元機器は」“イベント送信側機器３０Ａ”である。

また、図４に示す例では、自イベントは、「イベント待ち上限時刻」“ｔ１＋ｗ２”まで、相手方機器であるイベント送信側機器３０Ｂからの相手イベントの受信を待つことを示す。同様に、自イベントは、「イベント待ち上限時刻」“ｔ１＋ｗ３”まで、相手方機器であるイベント送信側機器３０Ｃからの相手イベントの受信を待つことを示す。

また、「イベント識別情報」“ｅ１”のイベントは、“イベント送信側機器３０Ａ”を送信元機器とするイベントであるので、「イベント待ち上限時刻（受信時刻）」のイベント送信側機器３０Ａに対応させて、自イベントの「受信時刻」“（ｔ３）”が登録される。

なお、図４に示すイベント送信側機器ごとの「イベント待ち上限時刻（受信時刻）」において、時刻を括弧書きで表記することで、イベント待ち上限時刻と、受信時刻とを区別している。

なお、順序整列用管理テーブル１５ｂは、互いにイベントを待ち合せるイベント送信側機器３０のグループごとにテーブルを分けて作成されてもよい。また、順序整列用管理テーブル１５ｂは、互いにイベントを待ち合せるイベント送信側機器３０のグループを一意の識別情報で識別可能にして、異なるグループのイベント送信側機器３０に対応する「イベント待ち上限時刻」を一つのテーブルで管理してもよい。

［イベント受信時の処理］
図５は、イベント受信時の処理例を説明する図である。図５で説明する処理は、イベント処理装置１０によりイベントが受信されるごとに行われる。図５では、イベント処理装置１０が受信したイベント送信側機器３０Ａからのイベントｅ１が自イベントである。この場合、イベント送信側機器３０Ｂ、３０Ｃがイベント処理装置１０へ送信するイベントは、相手イベントである。つまり、図５では、イベント送信側機器３０Ａが送信元機器であり、イベント送信側機器３０Ｂ、３０Ｃが、相手方機器である場合を示す。なお、イベント送信側機器３０Ｂ、３０Ｃが自イベントの送信元機器となる場合も同様である。

図５では、イベントｅ１を受信した時刻“ｔ３”が現在時刻である。また、図５では、イベント送信側機器３０Ａが時刻“ｔ１”に発生した自イベントをイベント処理装置１０へ送信し、時刻“ｔ３”にイベント処理装置１０により自イベントが受信された場合を示す。イベント処理装置１０の受信部１１は、時刻“ｔ３”にイベント送信側機器３０Ａから自イベントを受信すると、待ち時間設定部１２に自イベントの送信元機器、発生時刻、受信時刻を通知する。また、受信部１１は、自イベントにイベント識別情報“ｅ１”（以下、イベントｅ１と呼ぶこととする）を付与してバファリング部１３へ送信する。

待ち時間設定部１２は、イベントｅ１の受信が受信部１１から通知されたことを契機として、イベントｅ１の受信時刻“ｔ３”及び発生時刻“ｔ１”の時間差“ｗ１”を算出する（ステップＳ１１）。そして、待ち時間設定部１２は、時間差“ｗ１”で、必要に応じて、待ち時間管理テーブル１５ａの“イベント送信側機器３０Ａ”に対応するイベントのイベント待ち時間を更新する（ステップＳ１２）。

そして、イベント発生順序判定部１４は、他に受信済みイベントが無いことから、相手方機器ごとにイベント待ち時間を設定する。具体的には、イベント発生順序判定部１４は、イベントｅ１の相手イベントを送信する相手方機器であるイベント送信側機器３０Ｂ、３０Ｃに各々対応するイベント待ち時間“ｗ２”、“ｗ３”をそれぞれ読み出す（ステップＳ１３、ステップＳ１４）。

そして、イベント発生順序判定部１４は、イベントｅ１の発生時刻“ｔ１”に、イベント送信側機器３０Ｂからのイベント受信の待ち時間“ｗ２”を加算し、“ｔ１＋ｗ２”を得る（ステップＳ１５）。“ｔ１＋ｗ２”は、イベント送信側機器３０Ｂからのイベント受信の待ち時刻の上限を示すイベント待ち上限時刻である。

同様に、イベント発生順序判定部１４は、イベントｅ１の発生時刻“ｔ１”に、イベント送信側機器３０Ｃからのイベント受信の待ち時間“ｗ３”を加算し、“ｔ１＋ｗ３”を得る（ステップＳ１６）。“ｔ１＋ｗ３”は、イベント送信側機器３０Ｃからのイベント受信の待ち時刻の上限を示すイベント待ち上限時刻である。

そして、イベント発生順序判定部１４は、イベントｅ１の発生時刻“ｔ１”、受信時刻“ｔ３”、送信元機器“３０Ａ”、イベント識別情報“ｅ１”を含む新規レコードを順序整列用管理テーブル１５ｂに挿入する。さらに、新規レコードには、イベント送信側機器ごとの「イベント待ち上限時刻（受信時刻）」が登録される。

すなわち、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」において、自イベントを送信した送信元機器であるイベント送信側機器３０Ａに受信時刻“（ｔ３）”を対応付けて登録する。

また、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」において、相手方機器であるイベント送信側機器３０Ｂに「イベント待ち上限時刻」“ｔ１＋ｗ２”を対応付けて登録する。同様に、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」において、相手方機器であるイベント送信側機器３０Ｃに「イベント待ち上限時刻」“ｔ１＋ｗ３”を対応付けて登録する。

そして、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂに登録した「イベント待ち上限時刻」“ｔ１＋ｗ２”まで計時するタイマを作動させる。同様に、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂに登録した「イベント待ち上限時刻」“ｔ１＋ｗ３”まで計時するタイマを作動させる。

［イベント発生順序判定処理（イベント受信時）］
図６は、イベント発生順序判定処理（イベント受信時）の処理例を説明する図である。図６で説明する処理は、イベント処理装置１０によりイベントが受信されるごとに行われる。図６では、イベントｅ２を受信した時刻“ｔ４”が現在時刻である。また、受信したイベントｅ２が自イベント、自イベントの送信元機器（イベント送信側機器３０Ｂ）以外のイベント送信側機器３０（イベント送信側機器３０Ａ、３０Ｃ）が相手方機器である。なお、イベント送信側機器３０Ａ、３０Ｃが送信元機器となる場合も同様である。

なお、図６では、イベントｅ１と、イベント送信側機器３０Ｂにおいてイベントｅ１よりも早く発生したが、イベントｅ１よりも遅くイベント処理装置１０により受信されたイベントｅ２の二つのイベントについて発生順序を判定する場合を説明する。しかし、イベントｅ１と発生順序を比較するイベントの発生時刻、受信時刻、送信元機器は、イベントｅ２の様に限られるものではない。

図６では、現在時刻が時刻“ｔ３”から時刻“ｔ４”まで経過したことにより、図５から状況が変化している。図６において、時刻“ｔ４”で「イベント識別情報」“ｅ２”のイベントがイベント処理装置１０により受信され、対応する新規レコードが順序整列用管理テーブル１５ｂに挿入される処理の説明は、図５と同様であるので省略する。なお、以下、イベント識別情報“ｅ２”のイベントをイベントｅ２と呼ぶこととする。

イベント発生順序判定部１４は、イベントｅ２に対応する新規レコードを順序整列用管理テーブル１５ｂに発生時刻順に並ぶように挿入すると、イベントｅ１及びイベントｅ２を送信したイベント送信側機器３０Ａ、３０Ｂ間でイベントの発生順序の判定を行う。

図６では、イベントｅ１が、相手方機器からのイベント受信待ちの間に、イベント処理装置１０により相手イベントであるイベントｅ２が受信されたことを示す。この場合、イベント発生順序判定部１４は、イベントｅ２に対応する新規レコードを順序整列用管理テーブル１５ｂに挿入する。

そして、イベント発生順序判定部１４は、受信イベントｅ２の送信元機器（イベント送信側機器３０Ｂ）からのイベントを相手イベントとして待っていたものがあるかを確認する。このため、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」のカラムにおいて、イベントｅ２の送信元機器であるイベント送信側機器３０Ｂの列を上から下へ読み進める。そして、イベント発生順序判定部１４は、「受信時刻」を示す“（ｔ４）”と、「イベント待ち上限時刻」を示す“ｔ１＋ｗ２”を検出する。イベント発生順序判定部１４は、「受信時刻」“（ｔ４）”と、「イベント待ち上限時刻」“ｔ１＋ｗ２”の組合せから、イベントｅ２がイベント処理装置１０による受信を待っていたイベントｅ１が存在することを検出する（以上、ステップＳ２１）。

そして、イベント発生順序判定部１４は、イベントｅ１、ｅ２の発生順序を、発生時刻をもとに判定する。そして、イベント発生順序判定部１４は、イベントｅ１の「イベント待ち上限時刻（受信時刻）」の、イベント送信機器３０Ｂに対応する「イベント待ち上限時刻」“ｔ１＋ｗ２”を“順序判定済”に更新する（以上、ステップＳ２２）。なお、イベンｅ１、ｅ２は、順序整列用管理テーブルへのイベント挿入時点で発生時刻順にソートされているため、発生順序の判定を省略することも可能である。

なお、イベント発生順序判定部１４は、イベントｅ２を待っていたイベントが複数ある場合、該当する全てのイベントについて、ステップＳ２１及びステップＳ２２と同様処理する。すなわち、イベント発生順序判定部１４は、「イベント待ち上限時刻（受信時刻）」の、イベントｅ２の受信を待っていた全てのイベント送信側機器に該当する列を、ステップＳ２１及びステップＳ２２と同様に処理する。

また、イベント発生順序判定部１４は、イベントｅ２がイベントの受信を待ち合せようとするイベントのうち、すでに受信済みのものがあるかを調べる。具体的には、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」において、イベントｅ２がイベントの受信を待ち合せようとするイベント送信側機器３０Ａの列を上から下へ読み進める。そして、イベント発生順序判定部１４は、「イベント待ち上限時刻」“ｔ０＋ｗ１”と「受信時刻」“（ｔ３）”を検出する。イベント発生順序判定部１４は、「イベント待ち上限時刻」“ｔ０＋ｗ１”と、「受信時刻」“（ｔ３）”の組合せから、イベントｅ２がイベント処理装置１０による受信を待とうとするイベントｅ１が既に受信済であることを検出する（ステップＳ２３）。

そして、イベント発生順序判定部１４は、イベントｅ２の「イベント待ち上限時刻（受信時刻）」のイベント送信機器３０Ａに対応する「イベント待ち上限時刻」“ｔ０＋ｗ１”を“順序判定済”に更新する（以上、ステップＳ２４）。

なお、イベント発生順序判定部１４は、イベントｅ２が待とうとするイベントが複数ある場合、該当する全てのイベントについて、ステップＳ２３及びステップＳ２４と同様に処理する。すなわち、イベント発生順序判定部１４は、「イベント待ち上限時刻（受信時刻）」のイベントｅ２が待ち合せようとする全てのイベント送信側機器に該当する列を、ステップＳ２３及びステップＳ２４と同様に処理する。

［イベント発生順序判定処理（タイムアウト時）］
図７は、イベント発生順序判定処理（タイムアウト時）の処理例を説明する図である。図７で説明する処理は、イベント発生順序判定部１４が計時するタイマがタイムアウトするごとに行われる。図７では、図６同様に、現在時刻が“ｔ４”である。また、図７では、図６同様に、イベント送信側機器３０Ｂがイベント処理装置１０へ自イベントを送信する送信元機器であり、イベント送信側機器３０Ａ、３０Ｃがイベント処理装置１０へ相手イベントを送信する相手方機器である。なお、イベント送信側機器３０Ａ、３０Ｃが自イベントの送信元機器となる場合も同様である。

イベント発生順序判定部１４は、イベント送信側機器３０からイベントを受信したときに、受信したイベントが待ち合せようとする相手方機器からの相手イベント受信の待ち時間をイベント待ち上限時刻まで計時するタイマを作動させる。図７では、図６の処理に引き続き、イベント発生順序判定部１４は、自イベントであるイベントｅ２が待とうとする、相手方機器であるイベント送信側機器３０Ｃからの相手イベントの受信の待ち時間を計時するタイマがタイムアウトとしたことを検出する。具体的には、イベント発生順序判定部１４は、イベント送信側機器３０Ｃからの相手イベントの受信の待ち時間を計時するタイマがタイムアウトしたことを検出する（ステップＳ３１）。そして、イベント発生順序判定部１４は、自イベントｅ２の発生時刻“ｔ０”より前に発生したイベントが相手方機器（イベント送信側機器３０Ｃ）から通知されることは無いと判断する。そして、イベント発生順序判定部１４は、イベント送信側機器３０Ｃに対応する「イベント待ち上限時刻（受信時刻）」“ｔ０＋ｗ３”を“順序判定済”へ更新する（ステップＳ３２）。

以上の様に、イベント発生順序判定部１４は、全ての相手方機器に対応する「イベント受信待ち上限時刻（受信時刻）」が“順序判定済”に更新されたイベントｅ２を順序確定済として、バッファリング部１３にイベントｅ２を出力するように指示する。バッファリング部１３は、イベント発生順序判定部１４からの指示に応じて、イベント処理アプリケーションサーバ２０へイベントｅ２を出力する。

［イベント処理装置における処理］
図８は、イベント処理装置における処理を示すタイムチャートの一例を示す図である。図８に示すタイムチャートは、イベント処理装置１０において、受信部１１がイベントを受信したことを契機として処理が開始される。先ず、イベント処理装置１０において、受信部１１は、イベント送信側機器３０からイベントを受信する（ステップＳ１０１）。そして、受信部１１は、イベントを受信したことを、イベントの発生時刻、受信時刻等とともに待ち時間設定部１２に通知する（ステップＳ１０２）。また、受信部１１は、ステップＳ１０１で受信した受信イベントにイベント識別子を付与してバッファリング部１３へ送信する（ステップＳ１０３）。

待ち時間設定部１２は、ステップＳ１０２で受信部１１から受信イベントの通知に基づき、イベントの発生時刻と受信時刻の時間差で受信イベントを送信したイベント送信側機器からイベント受信の待ち上限時間を決定する（ステップＳ２０１）。

バッファリング部１３は、受信部１１から受信した受信イベントをバッファリングする（ステップＳ３０１）。そして、バッファリング部１３は、イベント発生順序判定部１４に、受信部１１から受信した受信イベントをバッファリングしたことを通知する（ステップＳ３０２）。

イベント発生順序判定部１４は、バッファリング部１３から受信イベントのバッファリングの通知を受信する（ステップＳ４０１）。そして、イベント発生順序判定部１４は、待ち時間設定部１２に、イベント送信側機器ごとの「イベント待ち時間」を問い合わせて取得する（ステップＳ４０２）。なお、待ち時間設定部１２は、イベント発生順序判定部１４からの問い合わせに応じて、待ち時間管理テーブル１５ａを参照して、イベント送信側機器ごとの「イベント待ち時間」を取得し、イベント発生順序判定部１４に応答する。

そして、イベント発生順序判定部１４は、ステップＳ４０２で取得した「イベント待ち時間」に基づき、受信イベントが自イベントである場合の相手方機器となるイベント送信側機器からの相手イベントの待ち上限時刻を算出する（ステップＳ４０３）。

そして、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂに、発生時刻の順序で受信イベントを挿入する（ステップＳ４０４）。ステップＳ４０４の処理の際、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」の受信イベントの送信元機器に対しては、受信イベントの受信時刻を登録する。また、ステップＳ４０４の処理の際、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」の受信イベントの相手方機器に対しては、相手イベントのイベント待ち上限時刻を登録する。そして、イベント発生順序判定部１４は、後述するイベント発生順序判定処理（イベント受信時）を行う（ステップＳ４０５）。

そして、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂにおいて、受信イベントは、相手方機器からの相手イベントが順序確定済であるか否かを判定する（ステップＳ４０６）。イベント発生順序判定部１４は、相手方機器からの相手イベントが順序確定済であると判定した場合（ステップＳ４０６Ｙｅｓ）、ステップＳ４１０へ処理を移す。一方、イベント発生順序判定部１４は、全ての相手方機器からの相手イベントが順序確定済であると判定しなかった場合（ステップＳ４０６Ｎｏ）、ステップＳ４０７へ処理を移す。

ステップＳ４０７では、イベント発生順序判定部１４は、受信イベントが受信を待つ相手イベントについて、相手イベントに相手方機器を対応付けて、相手イベントの受信を待つイベント待ち上限時刻まで計時するタイマの作動を開始させる。そして、イベント発生順序判定部１４は、ステップＳ４０８で作動を開始させたタイマがタイムアウトしたか否かを判定する（ステップＳ４０８）。具体的には、ステップＳ４０８では、イベント発生順序判定部１４は、相手イベントのイベント待ち上限時刻から現在時刻を差し引いた結果が負又は０になった場合に、タイムアウトと判定する。

イベント発生順序判定部１４は、ステップＳ４０８でタイマがタイムアウトしたと判定した場合（ステップＳ４０８Ｙｅｓ）、ステップＳ４０９へ処理を移す。一方、イベント発生順序判定部１４は、ステップＳ４０８で作動を開始させたタイマがタイムアウトしたと判定しなかった場合（ステップＳ４０８Ｎｏ）、ステップＳ４０８処理を繰り返す。

ステップＳ４０９では、イベント発生順序判定部１４は、後述するイベント発生順序判定処理（タイムアウト時）を行う（ステップＳ４０９）。イベント発生順序判定部１４は、ステップＳ４０９の処理が終了すると、ステップＳ４１０へ処理を移す。

ステップＳ４１０では、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂにおいて、全ての相手方機器からの相手イベントが順序確定済である順序確定済イベントが存在するか否かを判定する。イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂにおいて、順序確定済イベントが存在すると判定した場合（ステップＳ４１０Ｙｅｓ）、ステップＳ４１１へ処理を移す。一方、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂにおいて、順序確定済イベントが存在すると判定しなかった場合（ステップＳ４１０Ｎｏ）、処理を終了する。

ステップＳ４１１では、イベント発生順序判定部１４は、ステップＳ４１０の処理で判定された順序確定済イベントをイベントの発生順序でイベント処理アプリケーションサーバ２０へ送信する指示を、イベント識別子を指定してバッファリング部１３に通知する。

そして、バッファリング部１３は、イベント発生順序判定部１４から順序確定済イベントの送信指示を通知されると、送信が指示されたイベントを、イベントの発生順序でイベント処理アプリケーションサーバ２０へ送信する（ステップＳ３０３）。

［イベント発生順序判定処理（イベント受信時）］
図９は、イベント発生順序判定処理（イベント受信時）を示すフローチャートである。図９は、図８のステップＳ４０５で示したイベント発生順序判定処理（イベント受信時）の詳細を示すフローチャートである。

先ず、ステップＳ４０５ａでは、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂにおいて、到着（受信）イベントＥａの送信元機器Ｓａからのイベントを待っていた相手イベントＥｋが存在するか否かを判定する。ステップＳ４０５ａは、既に到着済で今回のイベント到着を待っていたイベントの順序判定処理である。以下、相手イベントＥｋの送信元機器Ｓｋを相手方機器Ｓｋと呼ぶこととする。具体的には、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」の到着イベントＥａの送信元機器Ｓａに該当する欄を、発生順序（上から）に、待っていたイベントＥｋがあるかを調べる。ステップＳ４０５ａは、図６で、イベント発生順序判定部１４が、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」の受信イベント（イベントｅ２）の送信元機器（イベント送信側機器３０Ｂ）に該当する欄を上から走査することに対応する。

イベント発生順序判定部１４は、到着イベントＥａの送信元機器Ｓａからのイベントを待っていた相手イベントＥｋが存在すると判定した場合（ステップＳ４０５ａＹｅｓ）、ステップＳ４０５ｂへ処理を移す。ステップＳ４０５ａＹｅｓは、図６で、イベント発生順序判定部１４が、「イベント待ち上限時刻（受信時刻）」のイベント送信側機器３０Ｂに該当する欄にイベント待ち上限時刻“ｔ１＋ｗ２”が設定されているイベントｅ１のレコードを検出することに対応する。一方、イベント発生順序判定部１４は、到着イベントＥａの送信元機器Ｓａからのイベントを待っていた相手イベントＥｋが存在すると判定しなかった場合（ステップＳ４０５ａＮｏ）、ステップＳ４０５ｃへ処理を移す。

ステップＳ４０５ｂでは、イベント発生順序判定部１４は、ＥｋとＥａの発生時刻を比較し、順序判定し、該当する２項関係を“順序判定済”とする。具体的には、イベント発生順序判定部１４は、到着して相手イベントを待っているイベントＥｋを自イベント、到着イベントＥａを相手イベントとして、順序整理用管理テーブル１５ｂで、自イベントＥｋと相手方機器Ｓａの交点を“順序判定済”とする。なお、イベント発生順序判定部１４は、到着イベントＥａの到着を待っていたイベントＥｋが複数存在する場合は、ステップＳ４０５ｂの処理を繰り返し行う。ステップＳ４０５ｂは、図６で、イベント発生順序判定部１４が、順序整理用管理テーブル１５ｂのイベントｅ１のレコードと「イベント待ち上限時刻（受信時刻）」のイベント送信側機器３０Ｂの欄との交点を“順序判定済”とすることに対応する。イベント発生順序判定部１４は、ステップＳ４０５ｂの処理が終了すると、ステップＳ４０５ｃへ処理を移す。

ステップＳ４０５ｃでは、イベント発生順序判定部１４は、到着イベントＥａが相手方機器Ｓｋからの相手イベントＥｋの到着を待とうとしていた期間に、既に到着済の相手イベントＥｋが存在するか否かを判定する。ステップＳ４０５ｃは、到着イベントの順序判定処理である。具体的には、イベント発生順序判定部１４は、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」の相手イベントＥｋの送信元機器Ｓｋに該当する欄を、発生時刻順に、到着済イベントがあるかを調べる。ステップＳ４０５ｃは、図６で、イベント発生順序判定部１４が、順序整列用管理テーブル１５ｂの「イベント待ち上限時刻（受信時刻）」のイベントｅ２の相手方機器（イベント送信側機器３０Ａ）に該当する欄をイベントの発生順序で走査することに対応する。

イベント発生順序判定部１４は、既に到着済の相手イベントＥｋが存在すると判定した場合（ステップＳ４０５ｃＹｅｓ）、ステップＳ４０５ｄへ処理を移す。ステップＳ４０５ｃＹｅｓは、図６で、イベント発生順序判定部１４が、「イベント待ち上限時刻（受信時刻）」のイベント送信側機器３０Ａに該当する欄にイベントの受信時刻“（ｔ３）”が設定されているイベントｅ１のレコードを検出することに対応する。一方、イベント発生順序判定部１４は、既に受信済の相手イベントＥｋが存在すると判定しなかった場合（ステップＳ４０５ｃＮｏ）、ステップＳ４０５ｅへ処理を移す。

ステップＳ４０５ｄでは、イベント発生順序判定部１４は、ＥａとＥｋの発生時刻を比較し、順序判定し、該当する２項関係を“順序判定済”とする。具体的には、イベント発生順序判定部１４は、到着してイベントを待っているイベントＥａを自イベント、到着イベントＥｋを相手イベントとして、自イベントＥａと相手方機器Ｓｋとの交点を“順序判定済”とする。なお、イベント発生順序判定部１４は、到着イベントＥａが相手方機器Ｓｋからのイベント到着を待とうとしていた期間に、相手方機器Ｓｋから到着済の全ての相手イベントＥｋに対してステップＳ４０５ｄの処理を行う。ステップＳ４０５ｄは、図６で、イベント発生順序判定部１４が、イベントｅ２を自イベントとし、順序整理用管理テーブル１５ｂのイベントｅ２と「イベント待ち上限時刻（受信時刻）」の相手方機器３０Ａの列との交点を“順序判定済”とすることに対応する。イベント発生順序判定部１４は、ステップＳ４０５ｄの処理が終了すると、ステップＳ４０５ｅへ処理を移す。

ステップＳ４０５ｅでは、イベント発生順序判定部１４は、順序整理用管理テーブル１５ｂにおいて、他の全ての相手方機器との“順序判定済”のイベントが存在するか否かを判定する。イベント発生順序判定部１４は、他の全ての相手方機器との“順序判定済”のイベントが存在すると判定した場合（ステップＳ４０５ｅＹｅｓ）、ステップＳ４０５ｆへ処理を移す。ステップＳ４０５ｅＹｅｓとなるのは、各イベントの相手方機器との交点が全て“順序判定済”の場合である。一方、イベント発生順序判定部１４は、他の全ての相手方機器との“順序判定済”のイベントが存在すると判定しなかった場合（ステップＳ４０５ｅＮｏ）、図８のステップＳ４０６へ処理を移す。ステップＳ４０５ｆでは、イベント発生順序判定部１４は、ステップＳ４０５ｅでＹｅｓとされた該当イベントを順序確定済とし、図８のステップＳ４０６へ処理を移す。

［イベント発生順序判定処理（タイムアウト時）］
図１０は、イベント発生順序判定処理（タイムアウト時）を示すフローチャートである。図１０は、図８のステップＳ４０９で示したイベント発生順序判定処理（タイムアウト時）の詳細を示すフローチャートである。

先ず、ステップＳ４０９ａでは、イベント発生順序判定部１４は、タイムアウトしたイベントＥｋと、その相手方機器Ｓａを特定する。ステップＳ４０９ａは、図７で、イベント発生順序判定部１４が、イベントｅ２において、相手方機器であるイベント送信側機器３０Ｃからのイベント待ち上限時刻がタイムアウトしたことを検出することに対応する。なお、イベント発生順序判定部１４は、図８のステップＳ４０７のタイマ設定時に、タイマ、イベントＥｋ、相手方機器Ｓｋを対応付けておく。これにより、イベント発生順序判定部１４は、タイムアウトしたイベントＥｋと、イベントＥｋを相手イベントＥａとして待っていた相手方機器Ｓａを特定できる。

そして、ステップＳ４０９ｂでは、イベント発生順序判定部１４は、イベントＥｋが、相手方機器Ｓａの相手イベントＥａより先に発生したと判定する。そして、イベント発生順序判定部１４は、ＥｋとＥａの該当する２項関係を“順序判定済”とする（以上、ステップＳ４０９ｂ）。具体的には、イベント発生順序判定部１４は、イベントＥｋと相手方機器Ｓａの交点を“順序判定済”とする。ステップＳ４０９ｂは、図７で、イベント発生順序判定部１４が、イベントｅ２のレコードと「イベント待ち上限時刻（受信時刻）」のイベント送信側機器３０Ｃとの交点を“順序判定済”とすることに対応する。

ステップＳ４０９ｃでは、イベント発生順序判定部１４は、順序整理用管理テーブル１５ｂにおいて、他の全ての相手方機器との“順序判定済”のイベントが存在するか否かを判定する。イベント発生順序判定部１４は、他の全ての相手方機器との“順序判定済”のイベントが存在すると判定した場合（ステップＳ４０９ｃＹｅｓ）、ステップＳ４０９ｄへ処理を移す。ステップＳ４０９ｄＹｅｓとなるのは、各イベントの相手方機器との交点が全て“順序判定済”の場合である。一方、イベント発生順序判定部１４は、他の全ての相手方機器との“順序判定済”のイベントが存在すると判定しなかった場合（ステップＳ４０９ｃＮｏ）、図８のステップＳ４１０へ処理を移す。ステップＳ４０９ｄでは、イベント発生順序判定部１４は、ステップＳ４０９ｃでＹｅｓとされた該当イベントを順序確定済とし、図８のステップＳ４１０へ処理を移す。

［イベント送信側機器の追加時の処理］
図１１Ａは、イベント送信側機器の追加時の処理（待ち時間管理テーブル関連）を説明する図である。図１１Ｂは、イベント送信側機器の追加時の処理（順序整列用管理テーブル関連）を説明する図である。例えば、イベント処理装置１０は、イベント処理アプリケーションサーバ２０やその他の図示しない装置からの要求に従って、イベント処理装置１０がイベントを整列する対象のイベント送信側機器３０を追加又は削除してもよい。以下、一例として、イベント送信側機器３０Ａ〜３０Ｃのグループに、イベント送信側機器３０Ｄ〜３０Ｆが追加される場合に、待ち時間管理テーブル１５ａ及び順序整列用管理テーブル１５ｂに関連して行われる処理を説明する。

なお、図１１Ａ及び図１１Ｂの例では、イベント送信側機器３０Ｄ〜３０Ｆの追加の要求を受け付ける前に、イベント識別情報“ｅ２”のイベント及びイベント識別情報“ｅ１”のイベントがイベント送信側機器３０Ｂ、３０Ａからそれぞれ受信されていたとする。以下では、イベント識別情報“ｅ１”のイベントをイベントｅ１と呼び、イベント識別情報“ｅ２”のイベントをイベントｅ２と呼ぶこととする。

また、図１１Ａ及び図１１Ｂの例では、イベント送信側機器３０Ｄ〜３０Ｆの追加の要求を受け付けた後に、イベント送信側機器３０Ｅから、「発生時刻」“ｔ５”、「受信時刻」“ｔ６”、「イベント識別情報」“ｅ５”のイベントが受信されたとする。以下、「イベント識別情報」“ｅ５”のイベントをイベントｅ５と呼ぶこととする。

なお、イベント送信側機器３０の追加要求及び削除要求は、イベント送信側機器３０で動作するアプリケーションから受け付けることもできるし、イベント処理装置１０の図示しない入力装置から受け付けることもできる。

イベント処理装置１０は、イベント送信側機器３０Ａ〜３０Ｃのグループに、イベント送信側機器３０Ｄ〜３０Ｆを追加する追加要求を受け付けた場合、次のような処理を行う。すなわち、イベント処理装置１０は、追加要求を受け付けたイベント送信側機器３０Ｄ〜３０Ｆごとに「イベント待ち時間」を設定するレコードを待ち時間管理テーブル１５ａに追加する。なお、イベント送信側機器３０Ｄ〜３０Ｆごとの「イベント待ち時間」には、イベント送信側機器３０Ｄ〜３０Ｆからイベントを未受信の場合、所定の初期値を設定してもよい。本実施の形態では、イベント送信側機器３０Ｄ〜３０Ｆに対して、それぞれ“ｗ４”、“ｗ５”、“ｗ６”が登録されている。そして、図１１Ｂに示す様に、イベント発生順序判定部１４は、「イベント待ち上限時刻（受信時刻）」に、イベント送信側機器３０Ｄ〜３０Ｆの各欄を追加する。その上で、イベント発生順序判定部１４は、受信済みのイベントｅ２とｅ１に関して、それぞれのイベント待ち時間である、“ｔ０＋ｗ４”、“ｔ０＋ｗ５”、“ｔ０＋ｗ６”と“ｔ１＋ｗ４”、“ｔ１＋ｗ５”、“ｔ１＋ｗ６”を設定する。

そして、図１１Ａに示す様に、待ち時間設定部１２は、イベントｅ５を受信する。すると、待ち時間設定部１２は、前述したように必要に応じて、イベントｅ５の発生時刻“ｔ５”と受信時刻“ｔ６”の時間差“ｔ６−ｔ５”をイベント送信側機器３０Ｅからのイベント待ち時間として待ち時間管理テーブル１５ａに設定する。

また、イベント発生順序判定部１４は、イベントｅ５に関して、前述したように、イベント送信側機器３０Ａ〜３０Ｄ、３０Ｆからの「イベント待ち上限時刻（受信時刻）」に、次の時間をそれぞれ設定する。すなわち、イベント発生順序判定部１４は、発生時刻に相手方機器からのイベント待ち時間を加算した時間である“ｔ５＋ｗ１”、“ｔ５＋ｗ２”、“ｔ５＋ｗ３”、“ｔ５＋ｗ４”、“ｔ５＋ｗ６”をそれぞれ設定する。また、イベント発生順序判定部１４は、イベントｅ５はイベント送信側機器３０Ｅの自イベントであるので、イベント送信側機器３０Ｅからの「イベント待ち上限時刻（受信時刻）」に受信時刻“（ｔ５）”を設定する。

そして、イベント発生順序判定部１４は、イベントごと、イベント送信側機器ごとに設定した「イベント待ち上限時刻」までそれぞれ計時するタイマを作動させる。そして、イベント発生順序判定部１４は、イベント送信側機器ごとの「イベント待ち上限時刻」までに相手方機器から相手イベントを受信したイベントについて、このイベントの送信元機器と、相手方機器との順序を判定済とする。また、イベント発生順序判定部１４は、「イベント待ち上限時刻」を超過してタイマがタイムアウトした相手方機器があるイベントについて、このイベントの送信元機器と、相手方機器との順序を判定済とする。

この様に、イベント処理装置１０は、各イベントについて、イベントの送信元機器と相手方機器の間の二つの機器間の関係ごとに順序を判定する。よって、イベント処理装置１０は、既に判定済のイベント送信側機器間の順序に影響を与えず、イベントを整列する対象とするイベント送信側機器３０の追加及び削除に柔軟に対応できる。

以上の実施の形態で開示した各部、各装置の分散及び統合の具体的形態は、図２に示したものに限られず、その全部又は一部を、負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散及び統合して構成することができる。例えば、受信部１１、待ち時間設定部１２、バッファリング部１３、イベント発生順序判定部１４のうちの少なくとも二つが、機能に応じて統合されてもよい。また、受信部１１、待ち時間設定部１２、バッファリング部１３、イベント発生順序判定部１４の少なくとも一つが別装置とされ、通信可能に接続され、イベント処理装置１０として協働するようにしてもよい。

また、以上の実施の形態で開示した各処理の分散及び統合の具体的形態は、図８〜図１０に示したものに限られず、負荷や使用状況等に応じて、任意の単位で分散及び統合して構成することができる。例えば、図９のステップＳ４０５ａ及びステップＳ４０５ｂは、ステップＳ４０５ｃ及びステップＳ４０５ｄと処理順序を入れ替えてもよい。

［イベント処理プログラム］
以上の実施の形態で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行されてもよい。図１２は、イベント処理プログラムを実行するコンピュータの一例を示す図である。

図１２に示すように、コンピュータ１００は、バス１４０を介して接続される操作部１１０、表示部１２０、通信部１３０、ＣＰＵ１５０、ＲＯＭ１６０、ＨＤＤ１７０、ＲＡＭ１８０を有する。

ＨＤＤ１７０には、図２に示した受信部１１、待ち時間設定部１２、バッファリング部１３、イベント発生順序判定部１４と同様の機能を発揮するイベント処理プログラム１７０ａ及びイベント処理プログラム１７０ａの実行に要する各種データが予め格納される。イベント処理プログラム１７０ａは、図２に示した各部と同様、適宜統合又は分離してもよい。

図１２に示す様に、ＣＰＵ１５０が、イベント処理プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、イベント処理プログラム１７０ａは、イベント処理プロセス１８０ａとして機能する。なお、イベント処理プロセス１８０ａは、図２に示した各部にて実行される処理、例えば図８〜図１０に示す処理を含む。また、ＣＰＵ１５０、ＨＤＤ１７０及びＲＡＭ１８０上で仮想的に実現される各部は、処理の実行時に適宜に実現されればよい。

なお、イベント処理プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０に格納せずともよい。例えば、コンピュータ１００が読み取り可能なフレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の「可搬用の物理媒体」にプログラムを記憶させておく。そして、コンピュータ１００が、媒体読み取り装置を介して「可搬用の物理媒体」からプログラムを読み出して実行するようにしてもよい。また、公衆網又は閉域網を介してコンピュータ１００に接続される他のコンピュータからプログラムを取得して実行するようにしてもよい。

［実施例１］
図１３は、実施例１を説明する図である。実施例１は、開示の技術をオンラインゲームの進行管理に利用する例である。図１３に示す例では、オンラインゲームにおいて、各種の通信回線で接続された操作端末３０Ａ−１〜３０Ｂ−１等の複数の操作端末からユーザのゲームの進行に係る操作がイベントとして入力される。操作端末３０Ａ−１〜３０Ｂ−１が実施の形態のイベント送信側機器３０の例である。

そして、イベントが、操作端末３０Ａ−１〜３０Ｂ−１等の複数の操作端末からオンラインゲームサーバ２０−１へ送信される。オンラインゲームサーバ２０−１は、受信したイベントに基づいてゲームの進行を管理する。オンラインゲームサーバ２０−１が実施の形態のイベント送信側機器３０の例である。

オンラインゲームでは、ゲームの進行管理上、操作端末３０Ａ−１〜３０Ｂ−１等の複数の操作端末から入力されたイベントが、オンラインゲームサーバ２０−１で、イベントの入力時刻すなわち発生時刻の順序でリアルタイムに処理されることが望ましい。しかし、各ユーザの操作端末３０Ａ−１〜３０Ｂ−１等の複数の操作端末が接続されるネットワーク環境は様々である。また、各ユーザの操作端末３０Ａ−１〜３０Ｂ−１等の複数の操作端末の通信性能も様々である。このため、ネットワーク環境によっては通信遅延が発生し、各ユーザが操作端末３０Ａ−１〜３０Ｂ−１等の複数の操作端末から入力されたイベントが、発生時刻の順序でオンラインゲームサーバ２０−１に受信されるとは限らない。

例えば、図１３において、操作端末３０Ａ−１〜３０Ｂ−１等の複数の操作端末が接続される個別のネットワーク環境によっては、通信遅延が発生する場合がある。個別のネットワーク環境で通信遅延が発生した場合、各ユーザが操作端末３０Ａ−１〜３０Ｂ−１から入力したイベントが、発生時刻の順序でオンラインゲームサーバ２０−１に受信されず、リアルタイム性が求められるオンラインゲームの進行管理に支障を来す。

そこで、開示の技術に係るイベント処理装置１０は、操作端末３０Ａ−１〜３０Ｂ−１等の複数の操作端末から送信されたイベントに対して、通信遅延を考慮して発生時刻順で並び替えるイベント発生順序整列処理を行う。そして、イベント処理装置１０は、イベント発生順序整列処理を行ったイベントをオンラインゲームサーバ２０−１へ出力する。この様に、オンラインゲームサーバ２０−１は、発生順序で並び替えられたイベントに基づいてオンラインゲームの進行管理を行うことで、適切にオンラインゲームを進行させることができる。

［実施例２］
図１４は、実施例２を説明する図である。実施例２は、開示の技術をオン渋滞マップ作成に利用する例である。図１４に示す例では、渋滞マップ作成において、各種の通信回線で接続された携帯端末３０Ａ−２〜３０Ｄ−２等の、車両に持ち込まれる複数の携帯端末から車両の運行に係る情報がイベントとして入力される。携帯端末３０Ａ−２〜３０Ｄ−２が実施の形態のイベント送信側機器３０の例である。

車両の運行に係る情報は、ＧＰＳ（Global Positioning System）による車両の位置情報、車両の速度、車両の進行方向等である。そして、イベントが、携帯端末３０Ａ−２〜３０Ｄ−２等の複数の携帯端末から渋滞マップ作成サーバ２０−２へ送信される。渋滞マップ作成サーバ２０−２は、受信したイベントに基づいて渋滞マップを作成する。渋滞マップ作成サーバ２０−２が実施の形態のイベント送信側機器３０の例である。

渋滞マップ作成では、渋滞マップのリアルタイム性を確保するため、携帯端末３０Ａ−１〜３０Ｂ−１等の複数の携帯端末から送信されたイベントが、渋滞マップ作成サーバ２０−２で、リアルタイムに処理されることが望ましい。しかし、各携帯端末３０Ａ−２〜３０Ｄ−２等の複数の携帯端末が接続されるネットワーク環境は様々である。また、各携帯端末３０Ａ−２〜３０Ｄ−２等の複数の携帯端末の通信性能も様々である。

さらには、各携帯端末３０Ａ−２〜３０Ｄ−２等の複数の携帯端末が持ち込まれる車両の位置が変化することにより、ネットワーク環境の状態が時々刻々と変化する。よって、携帯端末３０Ａ−２〜３０Ｄ−２等の携帯端末は、無線通信のエリア圏内であればリアルタイムでイベントを送信し、エリア圏外ではイベントを蓄積しておき、エリア圏内になったときに蓄積したイベントを一括送信する。この様な、イベントのリアルタイム送信もしくは一括送信の区別をイベント送信パターンと呼ぶこととする。

この様に、各携帯端末３０Ａ−２〜３０Ｄ−２等の複数の携帯端末から送信されたイベントが、イベント送信パターンを含む様々な要因から生じる通信遅延により、渋滞マップ作成サーバ２０−２に受信されたときには、時間的に古い情報になっている場合がある。渋滞マップ作成サーバ２０−２が作成した渋滞マップが時間的に古い情報を含んでいる場合、リアルタイム性が要求される渋滞マップとして、信頼度が低下してしまう。

そこで、開示の技術に係るイベント処理装置１０は、携帯端末３０Ａ−２〜３０Ｄ−２等の複数の携帯端末から送信されたイベントを、通信遅延やイベント送信パターンの変化を考慮してイベントを発生時刻順で並び替える。そして、イベント処理装置１０は、イベントを発生時刻順で並び替えるイベント発生順序整列処理を行ったイベントを渋滞マップ作成サーバ２０−２へ出力する。この様にして、渋滞マップ作成サーバ２０−２は、発生順序で並び替えられたイベントに基づいて、リアルタイムな渋滞マップの作成を行うことができる。

［実施例３］
図１５は、実施例３を説明する図である。実施例３は、開示の技術を圃場管理・圃場作業支援に利用する例である。図１５に示す例では、圃場管理・圃場作業支援において、各種の通信回線で接続されたセンサ３０Ａ−３〜３０Ｃ−３や入力端末３０Ｄ−３からイベントが入力される。すなわち、センサ３０Ａ−３〜３０Ｃ−３や入力端末３０Ｄが実施の形態のイベント送信側機器３０の例である。

図１５の例では、センサ３０Ａ−３は、土壌や農業用水のｐＨ（potential Hydrogen）値を観測するｐＨセンサである。また、センサ３０Ｂ−３は、圃場環境の湿度を観測する湿度計である。また、センサ３０Ｃ−３は、圃場環境の気温や水温を観測する温度計である。また、入力端末３０Ｄ−３は、圃場作業者が、例えば作業中に発見した観測情報（農作物の生育状況等）や圃場作業の進捗情報等を入力するコンピュータである。

センサ３０Ａ−３〜３０Ｃ−３や入力端末３０Ｄ−３は、観測情報もしくは入力情報をイベントとして圃場管理及び作業支援サーバ２０−３へ送信する。そして、圃場管理及び作業支援サーバ２０−３は、受信したイベントに基づいて圃場環境を総合的に判断し、圃場作業の指示を出力する。圃場管理及び作業支援サーバ２０−３が、実施の形態のイベント処理アプリケーションサーバ２０の例である。

なお、センサ３０Ａ−３〜３０Ｃ−３は、イベントをリアルタイムに送信するもの、周期的に送信するもの、一括して送信するものがある。また、入力端末３０Ｄ−３がイベントを送信するタイミングも、入力情報に応じて異なる場合がある。この様なイベントの送信タイミングの違いをイベント送信パターンと呼ぶこととする。

圃場管理・圃場作業支援では、農作物の的確な生育管理を行うため、センサ３０Ａ−３〜３０Ｃ−３や入力端末３０Ｄから送信されたイベントが、圃場管理及び作業支援サーバ２０−３に適切に処理されることが望ましい。しかし、センサ３０Ａ−３〜３０Ｃ−３や入力端末３０Ｄ−３から圃場管理及び作業支援サーバ２０−３へイベントを送信する際のイベント送信パターンは様々である。

この様に、センサ３０Ａ−３〜３０Ｃ−３や入力端末３０Ｄ−３から送信されるイベント送信パターンの違いにより、圃場管理及び作業支援サーバ２０−３が、受信したイベントに基づいて的確な判断を行えない場合がある。

そこで、開示の技術に係るイベント処理装置１０は、センサ３０Ａ−３〜３０Ｃ−３や入力端末３０Ｄ−３から送信されたイベントを、イベント送信パターンを考慮してイベントを発生時刻順で並び替えた上で圃場管理及び作業支援サーバ２０−３へ出力する。この様にして、圃場管理及び作業支援サーバ２０−３は、発生順序で並び替えられたイベントに基づいて、農作物の生育状況と圃場環境の総合的な判断に基づいた灌水、農薬や養分の散布の制御及び作業指示をより的確に行うことができる。

１ イベント処理システム
３ ネットワーク
１０ イベント処理装置
１１ 受信部
１２ 待ち時間設定部
１３ バッファリング部
１４ イベント発生順序判定部
１５ 記憶部
１５ａ 待ち時間管理テーブル
１５ｂ 順序整列用管理テーブル
２０イベント処理アプリケーションサーバ
３０、３０Ａ〜３０Ｆ イベント送信側機器

Claims (6)

1. 複数の機器から受信した各受信イベントをバッファに格納し、
   前記受信イベントの送信元機器以外の相手方機器ごとに待ち時間を設定し、
   前記相手方機器ごとの待ち時間内に前記相方手機器からイベントを受信したか、または前記待ち時間が超過したかによって、前記受信イベントの送信元機器と前記相手方機器との２機器間の発生順序判定を確定し、
   前記バッファに格納された受信イベントのうち、受信イベントの送信元機器と、他の全ての相手方機器との間で発生順序が確定されたイベントを、発生時刻順に送信する
   処理をイベント処理装置によって実行することを特徴とするイベント処理方法。
2. 前記相手方機器ごとに前記待ち時間を設定する際に、
   前記受信イベントが発生した時刻及び前記受信イベントを前記機器から受信した時刻の時間差のうち最長の時間差に基づいて前記待ち時間を設定する
   処理をイベント処理装置によって実行することを特徴とする請求項１に記載のイベント処理方法。
3. 前記相手方機器ごとに前記待ち時間を設定する際に、
   前記時間差を統計処理して得られる変化量が所定の閾値未満である最長の時間差を前記待ち時間として設定する
   処理をイベント処理装置によって実行することを特徴とする請求項２に記載のイベント処理方法。
4. 前記相手方機器ごとに前記待ち時間を設定する際に、
   各々のイベントを発生時刻順に送信する対象とする機器を追加する要求を受け付けた場合に、当該追加の要求を受け付けた機器から受信したイベントを対象にして前記追加の要求を受け付ける前にイベントを発生時刻順に送信する対象とされていた機器ごとに前記待ち時間の設定を追加するとともに、当該追加の要求を受け付ける前にイベントを発生時刻順に送信する対象とされていた機器を対象にして前記追加の要求を受け付けた機器ごとに前記待ち時間の設定を追加する処理を行い、
   前記イベントの受信を確定する際に、
   前記待ち時間の設定が追加された相手方機器からイベントを受信済みであるか、もしくは受信したかを確定する
   処理をイベント処理装置によって実行することを特徴とする請求項１、２又は３に記載のイベント処理方法。
5. 複数の機器からイベントを受信した各受信イベントをバッファに格納する受信部と、
   前記受信イベントの送信元機器以外の相手方機器ごとに待ち時間を設定する待ち時間設定部と、
   前記相手方機器ごとの待ち時間内に前記相手方機器からイベントを受信したか、または前記待ち時間が超過したかによって、前記受信イベントの送信元機器と前記相手方機器との２機器間の発生順序判定を確定する確定部と、
   前記バッファに格納された受信イベントのうち、受信イベントの送信元機器と、他の全ての相手方機器との間で発生順序が確定されたイベントを、発生時刻順に送信する送信部と
   を備えたことを特徴とするイベント処理装置。
6. 複数の機器から受信した各受信イベントをバッファに格納し、
   前記受信イベントの送信元機器以外の相手方機器ごとに待ち時間を設定し、
   前記相手方機器ごとの待ち時間内に前記相方手機器からイベントを受信したか、または前記待ち時間が超過したかによって、前記受信イベントの送信元機器と前記相手方機器との２機器間の発生順序判定を確定し、
   前記バッファに格納された受信イベントのうち、受信イベントの送信元機器と、他の全ての相手方機器との間で発生順序が確定されたイベントを、発生時刻順に送信する
   処理をイベント処理装置に実行させることを特徴とするイベント処理プログラム。

Images