知財求人 - 知財ポータルサイト「IP Force」
▶ コモンウェルス サイエンティフィック アンド インダストリアル リサーチ オーガナイゼーションの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-07-13
(54)【発明の名称】ログデータのコンプライアンス
(51)【国際特許分類】
G06F 11/34 20060101AFI20230706BHJP
【ＦＩ】
G06F11/34 166
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022576510
(86)(22)【出願日】2021-06-10
(85)【翻訳文提出日】2023-02-13
(86)【国際出願番号】 AU2021050596
(87)【国際公開番号】W WO2021248201
(87)【国際公開日】2021-12-16
(31)【優先権主張番号】2020901929
(32)【優先日】2020-06-11
(33)【優先権主張国・地域又は機関】AU
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
(71)【出願人】
【識別番号】590003283
【氏名又は名称】コモンウェルス サイエンティフィック アンド インダストリアル リサーチ オーガナイゼーション
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】グイド・ゴヴェルナトリ
(72)【発明者】
【氏名】ニック・ヴァン・ビースト
(72)【発明者】
【氏名】エイドリアン・クライヤー
(72)【発明者】
【氏名】ヘールコ・フルーフセマ
【テーマコード（参考）】
5B042
【Ｆターム（参考）】
5B042HH30
5B042MA08
5B042MA12
5B042MA14
5B042MC40
(57)【要約】
本開示は、ログデータを分析するコンピュータに関する。コンピュータは、それぞれのプロセス遂行からのログイベントを有するトレースを備えるログデータを受信する。コンピュータは、ログイベントのストリームを作成し、ストリームは、イベント時間でソートされる。コンピュータは、ログイベントのストリームを反復し、ログイベントごとに、ログイベントに基づいて変数のセットの更新を定義する更新関数を遂行する。変数のセットは、変数のセットの更新された値を計算するための少なくとも1つのクロストレース変数を備える。更新関数は、トレースのログイベントに応答してクロストレース変数の更新を定義する。コンピュータは、更新された値に基づいてログデータに関するコンプライアンスを決定するために、変数のセットに対して評価関数をさらに遂行する。評価関数は、クロストレース変数を含む変数のセットに基づいてコンプライアンスルールを表す。
【特許請求の範囲】
【請求項1】
ログデータを分析するための方法であって、複数の異なるそれぞれのプロセス遂行からの複数のログイベントを有するトレースを備えるログデータを受信するステップであって、前記複数のログイベントの各々が、イベント時間に関連付けられている、ステップと、
前記複数のそれぞれ異なるプロセス遂行からの前記複数のログイベントを備えるログイベントの単一のストリームを作成するステップであって、ログイベントの前記単一のストリームが、前記関連付けられるイベント時間によってソートされる、ステップと、
ログイベントの前記単一のストリームを反復し、ログイベントごとに、前記ログイベントに基づいて変数のセットの更新を定義する1つまたは複数の更新関数を遂行するステップであって、変数の前記セットが、変数の前記セットのうちの1つまたは複数の更新された値を計算するために少なくとも1つのクロストレース変数を備え、前記1つまたは複数の更新関数が、前記トレースのうちの複数の前記ログイベントに応答して、前記少なくとも1つのクロストレース変数の更新を定義する、ステップと、
前記更新された値に基づいて前記ログデータに関連するコンプライアンスを決定するために、変数の前記セットに対して1つまたは複数の評価関数を遂行するステップであって、前記1つまたは複数の評価関数が、前記クロストレース変数を含む変数の前記セットに基づいてコンプライアンスルールを表す、ステップと
を備える、方法。
【請求項2】
前記方法が、ログイベントごとに前記1つまたは複数の評価関数を遂行するステップを備える、請求項1に記載の方法。
【請求項3】
前記方法が、さらなるログデータを受信しながらコンプライアンスを決定するために、リアルタイムで作成、反復、および遂行する前記ステップを実行するステップを備える、請求項1または2に記載の方法。
【請求項4】
前記コンプライアンスルールが条件付きの義務を備える、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記コンプライアンスルールが複数のプロセスにわたって定義される、請求項1から4のいずれか一項に記載の方法。
【請求項6】
前記更新関数が、複数のプロセスまたは複数のプロセスインスタンスからのログデータに応答して、変数の前記セットのうちの1つの更新を定義する、請求項1から5のいずれか一項に記載の方法。
【請求項7】
前記ログデータが、オペレーティングシステムを遂行するコンピュータシステムによって生成されたログデータを備える、請求項1から6のいずれか一項に記載の方法。
【請求項8】
前記ログデータが、前記オペレーティングシステムによって遂行される様々なプロセスによって生成される、請求項7に記載の方法。
【請求項9】
前記複数のログイベントが、タスクの開始を示す開始ログイベントと、タスクの終了を示す停止イベントとを備える、請求項1から8のいずれか一項に記載の方法。
【請求項10】
前記1つまたは複数の評価関数が、評価述語によって表される、請求項1から9のいずれか一項に記載の方法。
【請求項11】
前記評価述語が、ログイベントのあらかじめ定められた発生を示す論理値に関連付けられる、請求項10に記載の方法。
【請求項12】
前記評価述語が、グラフ構造で定義される、請求項10または11に記載の方法。
【請求項13】
前記グラフ構造が、前記評価述語間の優先順位を定義する、請求項12に記載の方法。
【請求項14】
前記方法が、前記グラフ構造に基づく遂行を必要とする評価関数または更新関数のセットを決定し、その反復において評価関数または更新関数の前記セットのみを遂行するステップをさらに備える、請求項12または13に記載の方法。
【請求項15】
前記方法が、各ステップにおいて、前記セットに評価関数と更新関数を追加するステップと、
前記セット内の前記評価関数と前記更新関数を遂行するステップと、
前記グラフ構造によって定義された前記セットから評価関数と更新関数を削除するステップと
によって、コンプライアンスを評価するために前記グラフ構造をトラバースするステップをさらに備える、請求項14に記載の方法。
【請求項16】
前記セットが揮発性コンピュータメモリに記憶される、請求項14または15に記載の方法。
【請求項17】
前記グラフ構造が、チェックされた状態と、遂行が必要な前記評価関数または前記更新関数との組合せを表す、請求項13から16のいずれか一項に記載の方法。
【請求項18】
ルールを表すための更新関数または評価関数、あるいはその両方のインスタンスを生成するステップと、前記生成されたインスタンスを揮発性コンピュータメモリに記憶するステップと、
前記生成されたインスタンスを前記揮発性コンピュータメモリにおいて遂行するステップと、
コンプライアンスをさらに決定しながら、前記揮発性コンピュータメモリ内の前記生成されたインスタンスを破棄または上書きするステップと
をさらに備える、請求項1から17のいずれか一項に記載の方法。
【請求項19】
複数のルールに対して並行して複数のトレースのコンプライアンスを決定するステップをさらに備える、請求項18に記載の方法。
【請求項20】
前記1つまたは複数の評価関数が、ルールによって定義された有効な時間間隔で遂行される、請求項1から19のいずれか一項に記載の方法。
【請求項21】
コンピュータにインストールされると、前記コンピュータに、請求項1から20のいずれか一項に記載の方法を実行させる、ソフトウェア。
【請求項22】
ログデータを分析することによって別のシステムのコンプライアンスを監視するためのコンピュータシステムであって、複数のそれぞれの異なるプロセス遂行からの複数のログイベントを有するトレースを備える前記ログデータを受信することであって、前記複数のログイベントの各々が、イベント時間に関連付けられている、ことと、
前記複数のそれぞれ異なるプロセス遂行からの前記複数のログイベントを備えるログイベントの単一のストリームを作成することであって、ログイベントの前記単一のストリームが、前記関連付けられるイベント時間によってソートされる、ことと、
ログイベントの前記単一のストリームを反復し、ログイベントごとに、前記ログイベントに基づいて変数のセットの更新を定義する1つまたは複数の更新関数を遂行することであって、変数の前記セットが、変数の前記セットのうちの1つまたは複数の更新された値を計算するために少なくとも1つのクロストレース変数を備え、前記1つまたは複数の更新関数が、前記トレースのうちの複数の前記ログイベントに応答して、前記少なくとも1つのクロストレース変数の更新を定義する、ことと、
前記更新された値に基づいて前記ログデータに関連するコンプライアンスを決定するために、変数の前記セットに対して1つまたは複数の評価関数を遂行することであって、前記1つまたは複数の評価関数が、前記クロストレース変数を含む変数の前記セットに基づいてコンプライアンスルールを表す、ことと
を行うように構成されたプロセッサを備える、コンピュータシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ログデータを分析することに関し、より具体的には、ログデータを分析するための方法およびシステムに関する。
【背景技術】
【0002】
技術システムは、実行する動作の数だけでなく、含まれる対話モジュールの数もますます複雑になっている。各モジュールの挙動を定義することは可能であるが、すべてのモジュールが期待どおりに一緒に動作することを実行時にチェックすることは困難である。たとえば、いくつかのモジュールは、データベースサーバまたは暗号公開鍵などの共有リソースにアクセスする場合がある。その結果、システム全体のコンプライアンスは、各モジュールの挙動の一時的な態様に依存する。
【0003】
いくつかの手法は、主にコンプライアンスチェックではなく適合チェックに重点を置いており、イベントログに記録された挙動は、プロセスモデルにおいて指定された意図された挙動に対して評価される。一方、コンプライアンスチェックでは、規制に由来するルールのセットによって要求される挙動で挙動がチェックされる。その結果、プロセスの遂行は、準拠しているが適合していない(すなわち、挙動はモデルに含まれていないが、どのルールにも違反していない)か、適合しているが準拠していない(観察された挙動はモデルによって許可されているが、1つまたは複数のルールに違反している)可能性がある。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】Guido GovernatoriおよびAntonino Rotoloによって導入されたプロセスコンプライアンスロジック「Norm compliance in business process modeling」、International Workshop on Rules and Rule Markup Languages for the Semantic Web. Springer、ベルリン、ハイデルベルク、2010年
【発明の概要】
【発明が解決しようとする課題】
【0005】
たとえば、モジュールAがモジュールBの前に公開鍵ストレージにアクセスする場合、システムは準拠している可能性があるが、モジュールBがモジュールAの前に公開鍵ストレージにアクセスする場合は準拠してない。ルールがそのようなシナリオに対して直接エンコードされると、潜在的なシナリオの数が組合せ的に増加する可能性があるため、潜在的な組合せの数は実際の制約をすぐに超え、これは「組合せ爆発(combinatorial explosion)」とも呼ばれる。この爆発により、コンプライアンスチェッカを設計することは、不可能ではないにしても困難である。したがって、潜在的に多くの異なるプロセスからのログデータを効率的に分析できる方法およびシステムが必要である。コンプライアンスチェッカが次のイベントが発生する前にコンプライアンスをチェックできるレベルまで複雑さが軽減され、リアルタイムの監視が可能になる場合、これは特に役立つ可能性がある。
【0006】
本明細書における「ルール(rules)」および「規制(regulations)」という用語は、必ずしも法的または法定ルールに関連するものではなく、物理システムの機能の制限などの技術的要件に関連する場合があることに留意されたい。すなわち、コンプライアンスチェックは、リソースが限られている物理システムが、システムに過負荷をかけたり、誤動作の危険を冒したりすることなく、様々なソースから所望の機能を安全に実行できることを保証する。
【0007】
本明細書全体を通して、「備える(comprise)」という言葉、または「備える(comprises)」または「備えている(comprising)」などの変形は、述べられた要素、整数またはステップ、あるいは要素、整数またはステップのグループを含むが、任意の他の要素、整数またはステップ、あるいは要素、整数またはステップのグループを除外しないことを含意すると理解される。
【0008】
本明細書に含まれる文書、行為、材料、デバイス、物品などの議論は、これらの事項のいずれかまたはすべてが先行技術ベースの一部を形成すること、または添付の請求項の各々の優先日より前に存在していたので、本開示に関連する分野における共通の一般知識であったことを認めるものと見なされるべきではない。
【課題を解決するための手段】
【0009】
ログデータを分析するための方法は、
複数の異なるそれぞれのプロセス遂行からの複数のログイベントを有するトレースを備えるログデータを受信するステップであって、複数のログイベントの各々が、イベント時間に関連付けられている、ステップと、
複数のそれぞれ異なるプロセス遂行からの複数のログイベントを備えるログイベントの単一のストリームを作成するステップであって、ログイベントの単一のストリームが、関連付けられるイベント時間によってソートされる、ステップと、
ログイベントの単一のストリームを反復し、ログイベントごとに、ログイベントに基づいて変数のセットの更新を定義する1つまたは複数の更新関数を遂行するステップであって、変数のセットが、変数のセットのうちの1つまたは複数の更新された値を計算するために少なくとも1つのクロストレース変数を備え、1つまたは複数の更新関数が、トレースのうちの複数のログイベントに応答して、少なくとも1つのクロストレース変数の更新を定義する、ステップと、
更新された値に基づいてログデータに関連するコンプライアンスを決定するために、変数のセットに対して1つまたは複数の評価関数を遂行するステップであって、1つまたは複数の評価関数が、クロストレース変数を含む変数のセットに基づいてコンプライアンスルールを表す、ステップとを備える。
複数の異なるそれぞれのプロセス遂行からの複数のログイベントを有するトレースを備えるログデータを受信するステップであって、複数のログイベントの各々が、イベント時間に関連付けられている、ステップと、
複数のそれぞれ異なるプロセス遂行からの複数のログイベントを備えるログイベントの単一のストリームを作成するステップであって、ログイベントの単一のストリームが、関連付けられるイベント時間によってソートされる、ステップと、
ログイベントの単一のストリームを反復し、ログイベントごとに、ログイベントに基づいて変数のセットの更新を定義する1つまたは複数の更新関数を遂行するステップであって、変数のセットが、変数のセットのうちの1つまたは複数の更新された値を計算するために少なくとも1つのクロストレース変数を備え、1つまたは複数の更新関数が、トレースのうちの複数のログイベントに応答して、少なくとも1つのクロストレース変数の更新を定義する、ステップと、
更新された値に基づいてログデータに関連するコンプライアンスを決定するために、変数のセットに対して1つまたは複数の評価関数を遂行するステップであって、1つまたは複数の評価関数が、クロストレース変数を含む変数のセットに基づいてコンプライアンスルールを表す、ステップとを備える。
【0010】
更新関数によって更新される変数のセットが存在し、評価関数がこれらの変数をテストすることは利点である。これにより、プロセス間のコンプライアンスの効率的なチェックが可能になり、そうしないと、一時的な依存関係により、完全に接続されている可能性のある評価グラフの直接処理が計算上困難になり、組合せが複雑になる可能性がある。
【0011】
本方法は、ログイベントごとに1つまたは複数の評価関数を遂行するステップを備え得る。本方法は、さらなるログデータを受信しながらコンプライアンスを決定するために、リアルタイムで作成、反復、および遂行するステップを実行するステップを備え得る。
【0012】
コンプライアンスルールは、条件付きの義務を備え得る。コンプライアンスルールは、複数のプロセスにわたって定義され得る。更新関数は、複数のプロセスまたは複数のプロセスインスタンスからのログデータに応答して、変数のセットのうちの1つの更新を定義し得る。
【0013】
ログデータは、オペレーティングシステムを遂行するコンピュータシステムによって生成されたログデータを備え得る。ログデータは、オペレーティングシステムによって遂行される様々なプロセスによって生成され得る。複数のログイベントは、タスクの開始を示す開始ログイベントと、タスクの終了を示す停止イベントとを備え得る。
【0014】
変数のセットは、現在アクティブなタスクの数を示している場合がある。1つまたは複数の更新関数は、複数のログイベントのうちの1つがログ開始イベントであることに応答して、変数のセットのうちの1つを増分し得、1つまたは複数の更新関数は、複数のログイベントのうちの1つがログ停止イベントであることに応答して、変数のセットのうちの1つを減分することができる。
【0015】
1つまたは複数の評価関数は、変数のセットのうちの1つの上限しきい値に基づき得る。1つまたは複数の評価関数は、評価述語によって表され得る。評価述語は、ログイベントのあらかじめ定められた発生を示す論理値に関連付けられ得る。評価述語は、グラフ状の構造で定義され得る。グラフ状の構造は、評価述語間の優先順位を定義し得る。
【0016】
本方法は、グラフ構造に基づく遂行を必要とする評価関数のセットを決定し、その反復において評価関数のセットのみを遂行するステップをさらに備え得る。
【0017】
グラフ構造は、チェックされた状態と、遂行が必要な評価関数との組合せを表し得る。
【0018】
本方法は、
ルールを表すための更新関数または評価関数、あるいはその両方のインスタンスを生成するステップと、
生成されたインスタンスを揮発性コンピュータメモリに記憶するステップと、
生成されたインスタンスを揮発性コンピュータメモリにおいて遂行するステップと、
コンプライアンスをさらに決定しながら、揮発性コンピュータメモリ内の生成されたインスタンスを破棄または上書きするステップとをさらに備え得る。
ルールを表すための更新関数または評価関数、あるいはその両方のインスタンスを生成するステップと、
生成されたインスタンスを揮発性コンピュータメモリに記憶するステップと、
生成されたインスタンスを揮発性コンピュータメモリにおいて遂行するステップと、
コンプライアンスをさらに決定しながら、揮発性コンピュータメモリ内の生成されたインスタンスを破棄または上書きするステップとをさらに備え得る。
【0019】
本方法は、複数のルールに対して並行して複数のトレースのコンプライアンスを決定するステップをさらに備え得る。
【0020】
評価関数は、ルールによって定義された有効な時間間隔を表し得る。
【0021】
ソフトウェアは、コンピュータにインストールされると、コンピュータに、上記の方法を実行させる。
【0022】
ログデータを分析することによって別のシステムのコンプライアンスを監視するためのコンピュータシステムは、
複数のそれぞれの異なるプロセス遂行からの複数のログイベントを有するトレースを備えるログデータを受信することであって、複数のログイベントの各々が、イベント時間に関連付けられている、ことと、
複数のそれぞれ異なるプロセス遂行からの複数のログイベントを備えるログイベントの単一のストリームを作成することであって、ログイベントの単一のストリームが、関連付けられるイベント時間によってソートされる、ことと、
ログイベントの単一のストリームを反復し、ログイベントごとに、ログイベントに基づいて変数のセットの更新を定義する1つまたは複数の更新関数を遂行することであって、変数のセットが、変数のセットのうちの1つまたは複数の更新された値を計算するために少なくとも1つのクロストレース変数を備え、1つまたは複数の更新関数が、トレースのうちの複数のログイベントに応答して、少なくとも1つのクロストレース変数の更新を定義する、ことと、
更新された値に基づいてログデータに関連するコンプライアンスを決定するために、変数のセットに対して1つまたは複数の評価関数を遂行することであって、1つまたは複数の評価関数が、クロストレース変数を含む変数のセットに基づいてコンプライアンスルールを表す、こととを行うように構成されたプロセッサを備える。
複数のそれぞれの異なるプロセス遂行からの複数のログイベントを有するトレースを備えるログデータを受信することであって、複数のログイベントの各々が、イベント時間に関連付けられている、ことと、
複数のそれぞれ異なるプロセス遂行からの複数のログイベントを備えるログイベントの単一のストリームを作成することであって、ログイベントの単一のストリームが、関連付けられるイベント時間によってソートされる、ことと、
ログイベントの単一のストリームを反復し、ログイベントごとに、ログイベントに基づいて変数のセットの更新を定義する1つまたは複数の更新関数を遂行することであって、変数のセットが、変数のセットのうちの1つまたは複数の更新された値を計算するために少なくとも1つのクロストレース変数を備え、1つまたは複数の更新関数が、トレースのうちの複数のログイベントに応答して、少なくとも1つのクロストレース変数の更新を定義する、ことと、
更新された値に基づいてログデータに関連するコンプライアンスを決定するために、変数のセットに対して1つまたは複数の評価関数を遂行することであって、1つまたは複数の評価関数が、クロストレース変数を含む変数のセットに基づいてコンプライアンスルールを表す、こととを行うように構成されたプロセッサを備える。
【0023】
次に、以下の図面を参照して例を説明する。
【図面の簡単な説明】
【0024】
【図1】ログイベント生成コンピュータおよびログ処理サーバを備えるコンピュータネットワークを示す図である。
【図3】トリガと期限との間のビジネスプロセスモデルのトレースに対する条件付きの義務の有効な間隔をグラフィカルに示す図である。
【図4】本明細書で開示される方法の例のグラフィカルな概要を示す図である。
【図7】各イベントが再生された後の変数の進化の例示的な抜粋を示す図である。
【図8】ログデータを分析するための方法を示す図である。
【図9】別のシステムのコンプライアンスを監視するためのコンピュータシステムを示す図である。
【図10】仮想ルールInvoicePayの例示的なグラフである。
【図11】本明細書で与えられたルールの例示的なグラフである。
【図12】請求書idのドメインにわたる仮想ルールInvoicePayスケーリングの例示的なグラフである。
【発明を実施するための形態】
【0025】
アプリケーションドメイン
本明細書で開示される方法は、異なるアプリケーションドメインの範囲に適用することができる。特に、開示された方法は、トレースを備えるログデータを分析する。各トレースは、複数の異なるそれぞれのプロセス遂行からの複数のログイベントを有する。すなわち、各トレースは、1つのプロセス遂行によって生成されたログイベントを有する。プロセス遂行は、プロセスインスタンスと見なすこともできる。たとえば、オペレーティングシステムにおいては、コンパイルされたソフトウェアプログラムをバイナリファイルとしてプログラムメモリに記憶することができ、プロセッサが遂行するステップはプロセスと見なされる。プロセッサがバイナリファイルを遂行すると、プロセッサはその遂行にプロセス識別子を割り当てる。すなわち、プロセッサはプロセスのインスタンスを作成する。その意味で、同じプロセスの複数のインスタンスが存在する可能性がある。たとえば、同じプロセッサによって遂行されているApacheウェブサーバの2つのインスタンスがあり、それぞれがそれぞれのプロセス識別子を有する可能性がある。
本明細書で開示される方法は、異なるアプリケーションドメインの範囲に適用することができる。特に、開示された方法は、トレースを備えるログデータを分析する。各トレースは、複数の異なるそれぞれのプロセス遂行からの複数のログイベントを有する。すなわち、各トレースは、1つのプロセス遂行によって生成されたログイベントを有する。プロセス遂行は、プロセスインスタンスと見なすこともできる。たとえば、オペレーティングシステムにおいては、コンパイルされたソフトウェアプログラムをバイナリファイルとしてプログラムメモリに記憶することができ、プロセッサが遂行するステップはプロセスと見なされる。プロセッサがバイナリファイルを遂行すると、プロセッサはその遂行にプロセス識別子を割り当てる。すなわち、プロセッサはプロセスのインスタンスを作成する。その意味で、同じプロセスの複数のインスタンスが存在する可能性がある。たとえば、同じプロセッサによって遂行されているApacheウェブサーバの2つのインスタンスがあり、それぞれがそれぞれのプロセス識別子を有する可能性がある。
【0026】
これらのプロセス遂行は、Microsoft Windows（登録商標）ベースのシステムにおけるタスクマネージャのUNIX（登録商標）ベースのシステムにおけるpsなどの管理ツールの出力として個別にリストされる。これらの遂行の各々は、独自の個別のログファイルに書き込むか、各ログイベントにプロセス識別子が追加された同じ共通ログファイルに書き込む。複数のプロセス遂行からのログイベントの数が重要になる可能性があることを理解することができる。
【0027】
さらに、異常を検知するためのプロセス遂行のコンプライアンスをチェックすることも重要である。これらのコンプライアンスチェックは、プロセス遂行ごとに個別にチェックするのではなく、複数のプロセス遂行にわたってコンプライアンスをチェックする場合、より関連性が高く、より堅牢である。たとえば、上記の複数のウェブサーバの各々が個別に準拠している可能性があるが、両方のサーバで同時に無視される監視ルールに違反している。しかしながら、異なるプロセス遂行間、すなわちトレース間でコンプライアンスをチェックすると、既存のコンピュータハードウェアでは処理が困難な組合せの複雑さが生じる。さらに、既存のよく知られているコンピュータ機能を使用してクロストレースコンプライアンスチェックを直接実装すると、現在のコンピュータアーキテクチャにおいて通常使用できるより多くのランダムアクセスメモリ(RAM)を必要とするプログラムコードが生成される。したがって、開示された方法は、計算の複雑さを軽減し、クロストレースコンプライアンスチェックに必要なRAMの量を削減する可能性がある。
【0028】
他の例では、プロセス遂行は、製造プロセスなどの物理的な性質のものである。これは、データ駆動型産業に関連する「Industry 4.0」というラベルの下で、ますます差し迫った問題になりつつある。製造プロセスに関する膨大な量のデータが収集されている一方で、クロストレースコンプライアンスチェックの計算が複雑であるため、このデータのコンプライアンスをチェックすることは困難である。たとえば、自動車の製造において、ドアパネルをプレスするプロセスとボンネットパネルをプレスするプロセスがあり得る。これらの両方の遂行は、個別にチェックすることができる。しかしながら、両方のプロセスが同じプレスを共有することもあり、同じ搬送ロボットを共有することもある。したがって、クロストレースコンプライアンスチェックが必要である。しかしながら、クロストレースコンプライアンスチェックは、開示された方法によって対処される困難な組合せ問題を提示する。
【0029】
コンピュータネットワーク
図1は、それぞれが独自のプロセスを遂行する3つのコンピュータ101、102、および103を含むコンピュータネットワーク100を示している。コンピュータネットワーク100は、ログ処理サーバ104をさらに備える。この例では、各コンピュータ101、102、103は、それぞれ識別子(ID)1、2、3を有する1つのプロセスを遂行し、生成されたイベントログをログ処理サーバ104に送信する。これらのプロセスの各々がログイベントを生成し、それらは個々のログ111、112、113にそれぞれ示されている。したがって、「イベントログ(event log)」という用語は、「ログイベント(log events)」の集合を指す。
図1は、それぞれが独自のプロセスを遂行する3つのコンピュータ101、102、および103を含むコンピュータネットワーク100を示している。コンピュータネットワーク100は、ログ処理サーバ104をさらに備える。この例では、各コンピュータ101、102、103は、それぞれ識別子(ID)1、2、3を有する1つのプロセスを遂行し、生成されたイベントログをログ処理サーバ104に送信する。これらのプロセスの各々がログイベントを生成し、それらは個々のログ111、112、113にそれぞれ示されている。したがって、「イベントログ(event log)」という用語は、「ログイベント(log events)」の集合を指す。
【0030】
各コンピュータ101、102、103は、図1に示されるように、イベントログ111、112、113をローカルに記憶し、次いで、それらをログ処理サーバ104に送信し得る。他の例では、コンピュータ101、102、103は、すべての新しいログイベントがローカル集合なしでログ処理サーバ104に直接送信されるという意味でログイベントを「ストリーム(stream)」する。他の例では、コンピュータ101、102、103は、バイナリを遂行するプロセッサ、または共有リソース上で動作する仮想マシンなど、ログ生成プロセスを遂行する他のエージェントに置き換えられ得る。サーバ104はまた、コンピュータ101、102、および103とともに単一のコンピュータシステムまたはプロセッサ上で、あるいはクラウドコンピューティング環境上でプロセスとして実装され得る。ログ処理サーバ104がイベントログ111、112、113内のログイベントを受信すると、サーバ104はそれらを1つのテーブルまたはイベントログの集合に結合し得る。
【0031】
ログイベント
例示的なログイベント121などの各ログイベントは、プロセスID122、イベントID123、イベントラベル124、タイムスタンプ125、およびライフサイクル126を備える。他の例では、イベントログ111、112、113は、異なる列または異なる構造を有し得る。
例示的なログイベント121などの各ログイベントは、プロセスID122、イベントID123、イベントラベル124、タイムスタンプ125、およびライフサイクル126を備える。他の例では、イベントログ111、112、113は、異なる列または異なる構造を有し得る。
【0032】
ここで、ログイベントはそれぞれのコンピュータによって遂行される同じプロセスによって生成されるため、プロセスIDは変更されないままであることに留意されたい。しかしながら、他の例では、コンピュータが複数のプロセスを遂行する場合、各コンピュータは異なるプロセスIDでイベントを生成する場合がある。ここでは、イベントIDは順次インデックスでラベル付けされているが、コンピュータ102はコンピュータ101が最後に使用したインデックスを認識していないため、図1に示されているイベントIDは、単に説明を目的としたものである。それらは、乱数などの一意のラベルとして選択されてもよく、コンピュータ101、102、103ごとに「0」から始まり、コンピュータまたはプロセッサIDによってプレフィックスが付けられた自動増分整数であってもよい。イベントラベル124は、イベントまたは「タスク」を一意に識別するラベルである。この点で、ログイベントはタスクの遂行インスタンスに関連し、イベントラベルはそのタスクの定義を参照する。したがって、コンピュータ101は、タスク「A」、「B」、「C」の各々に対応する2つのログイベントを有し、これらのタスクの各々の開始と終了をマークする。コンピュータ102と103が同じタスクのインスタンスを生成することは注目に値するため、それらのイベントログに「A」、「B」、「C」も有している。
【0033】
図1において使用されているタイムスタンプは、tのインデックスがある時点を表すようなものであり、秒またはミリ秒であり得る。たとえば、ログ111における第1のイベントは0ミリ秒(t0のインデックス「0」)で発生し、ログ112における第1のイベントは2ミリ秒(t2のインデックス「2」)で発生した。他の例では、タイムスタンプはUNIXタイムスタンプまたはその他のタイムスタンプである。ライフサイクルは、ラベル124のイベントが開始または完了したかどうかを示している。ライフサイクル列126は、3つ以上の状態(たとえば、「開始(start)」、「完了(complete')」、「終了(terminated')」、「中止(aborted')」、「一時停止(suspended')」、「再開(resumed')」など)のうちの1つを保持してもよく、またはまったく使用されなくてもよい。
【0034】
より具体的には、イベントは情報システムの遂行における重要なマイルストーンの記録である。たとえば、ビジネスプロセスにおけるタスクに関する情報の記録、そのビジネスプロセスのアーティファクトの作成と変更、タスクまたはアーティファクトID、イベントがトリガされた時刻、およびイベントのトリガに関与するリソースを含み得る。トレース内のイベント発生は、そのイベントに関連するデータ変数のセットで構成される。トレースを所与とすると、同じデータ変数が表示され、複数のイベント発生で変化する可能性がある。さらに、トレース/インスタンスレベルで保持される変数がある。ログイベント(または、単に「イベント」)は、次のように正式に定義され得る(ただし、異なる定義が使用される場合がある)。
【0035】
定義1(イベント) イベントe∈Eは、タプルe=<D,ν>であり、したがって、Dは{id,timestamp,state,resource}⊆Dとなるようなデータ変数のセットであり、νは変数x∈Dの値を取得する関数ν:D→d(x)であり、この式で、d(x)はxのドメインを表す。
【0036】
イベントログ
イベントのセットが与えられると、イベントログはトレースのセットで構成され、各トレースはプロセスの1回の遂行によって生成されたイベントのシーケンスを含む。イベントログ内のイベントは、それらのタイムスタンプによって誘導される合計順序によって関連付けられる。言い換えれば、サーバ104は、イベントログをタイムスタンプでソートする。ソートは、イベントをJava言語のリンクされたツリーデータ構造に入力することによって実現され得るが、他のプログラミング言語における他の多くの実装形態が可能であること留意されたい。このコンテキストでは、「順序付け(ordering)」と「ソート(sorting)」という用語は同義語として使用されている。イベントログは、次のように正式に定義され得る(ただし、異なる定義が使用される場合がある)。
イベントのセットが与えられると、イベントログはトレースのセットで構成され、各トレースはプロセスの1回の遂行によって生成されたイベントのシーケンスを含む。イベントログ内のイベントは、それらのタイムスタンプによって誘導される合計順序によって関連付けられる。言い換えれば、サーバ104は、イベントログをタイムスタンプでソートする。ソートは、イベントをJava言語のリンクされたツリーデータ構造に入力することによって実現され得るが、他のプログラミング言語における他の多くの実装形態が可能であること留意されたい。このコンテキストでは、「順序付け(ordering)」と「ソート(sorting)」という用語は同義語として使用されている。イベントログは、次のように正式に定義され得る(ただし、異なる定義が使用される場合がある)。
【0037】
定義2(イベントログ、トレース) Lをイベントログとし、Eをイベント発生のセットとする。イベントトレースはσ∈Lは、σ=e0e1…en-1が∀i∈Oσ:e1∈Eσを有するイベントのシーケンスであるような順序Oσ=[0,n-1]および|Eσ|=nを有するイベントのセットEσ⊆Eの観点から定義され、
【0038】
【数1】
【0039】
である。
【0040】
イベントログLの例が図1に示されている。すべてのトレースはシーケンスであり、すべてのイベントは一意の識別子(ei)、イベントラベル(たとえば、A)、タイムスタンプ(tk)、およびライフサイクルイベント(start、complete)を有する。実際のイベントログにおいては、通常、各イベントとともに記録されるイベントプロパティ(すなわち、変数)がはるかに多くあるが、図1では、読みやすくするためにこれらが省略されている。
【0041】
ここでのイベントプロパティは、顧客ID、注文金額、承認などであり得る。これらの変数の各々の値は、後続のイベントによって変更され得る。一部の変数はトレース固有であるが、他の変数はトレース全体で有効である(たとえば、マネージャが承認する必要がある注文の合計額、特定のリソースについて調査中のケースの合計など)。
【0042】
図2は、図1からのイベントログのグラフィカルな例を示している。イベントログ111、112、113は、まとめてイベントログLと呼ばれる。図2において、トレースがイベントのシーケンスとして視覚化されている。
【0043】
コンプライアンスルール
サーバ104は、111、112、113から結合されたイベントログのコンプライアンスをチェックして、ビジネスプロセスモデルが準拠していると見なされるために従わなければならない要件をチェックするために、規制フレームワークを使用し得る。一例では、サーバ104は、Guido GovernatoriおよびAntonino Rotoloによって導入されたプロセスコンプライアンスロジック「Norm compliance in business process modeling」、International Workshop on Rules and Rule Markup Languages for the Semantic Web. Springer、ベルリン、ハイデルベルク、2010年を使用し、これは、参照により本明細書に組み込まれる。規制の枠組みにおいて定式化することができるルールの種類についての直感を提供するために、条件付きの義務について以下に説明する。
サーバ104は、111、112、113から結合されたイベントログのコンプライアンスをチェックして、ビジネスプロセスモデルが準拠していると見なされるために従わなければならない要件をチェックするために、規制フレームワークを使用し得る。一例では、サーバ104は、Guido GovernatoriおよびAntonino Rotoloによって導入されたプロセスコンプライアンスロジック「Norm compliance in business process modeling」、International Workshop on Rules and Rule Markup Languages for the Semantic Web. Springer、ベルリン、ハイデルベルク、2010年を使用し、これは、参照により本明細書に組み込まれる。規制の枠組みにおいて定式化することができるルールの種類についての直感を提供するために、条件付きの義務について以下に説明する。
【0044】
定義3(条件付きの義務) ローカル義務eはタプル<o,r,t,d>であり、O∈{a,m}であり、義務のタイプを表す。要素c、tおよびdは、Lにおける命題リテラルである。rは義務の要件であり、tは義務のトリガであり、dは義務の期限である。
【0045】
表記法e=Oo<r,t,d>は、条件付きの義務を表すためにここで使用されている。
【0046】
条件付きの義務の要件、トリガ、および期限は、トレースの状態に対して評価される。ビジネスプロセスモデルのトレースと条件付きの義務が与えられた場合、トレースの状態が義務のトリガ要素を満たしている場合、義務は有効に設定される。さらに、義務がトレースに対して有効であり、期限要素がトレースの状態によって満たされている場合、条件付きの義務は有効ではなくなる。
【0047】
図3は、トリガ301と期限302との間のビジネスプロセスモデルのトレースに対する条件付きの義務の有効な間隔300をグラフィカルに示している。条件付きの義務は、1つまたは複数の評価関数においてエンコードされることに留意されたい。したがって、評価関数は、トリガ301と期限302との間の有効な間隔に対して遂行されると言われる。
【0048】
条件付きの義務が有効である場合、義務の要件要素、すなわち評価関数が、その特定の有効間隔において義務が満たされるか違反されるかを決定するために、有効間隔300内で評価されることに留意されたい。要件要素がどのように評価されるかは、義務の種類によって異なる。義務には、達成と維持の2種類があると考えられる。
【0049】
達成:この種の義務が有効である場合、有効間隔内、言い換えれば期限に達する前に、少なくとも1つの状態によって、規制によって指定された要件が満たされなければならない。この場合、有効な義務は満たされたと見なされ、そうでない場合は違反されたと見なされる。
【0050】
維持:この種の義務が有効である場合、期限に達するまで、有効間隔のすべての状態において要件が継続的に満たされなければならない。この場合も、有効な義務は満たされているが、そうでない場合は違反している。
【0051】
潜在的に複数の義務の有効間隔が同時に共存する可能性がある。しかしながら、トレースにおいて発生する1つのイベントによって、複数の有効間隔が満たされる場合がある。
【0052】
論理式
義務に関する無効にできる論理(Deontic defeasible logic)は、単なる制御フローよりも表現力があり、孤立したトレース内の変数だけでなく、トレース間でもより複雑な制約を課す可能性がある。そのため、イベントログ内の様々なトレースにわたるルールの評価が考慮される。
義務に関する無効にできる論理(Deontic defeasible logic)は、単なる制御フローよりも表現力があり、孤立したトレース内の変数だけでなく、トレース間でもより複雑な制約を課す可能性がある。そのため、イベントログ内の様々なトレースにわたるルールの評価が考慮される。
【0053】
それらのルールを検証するためにトレースのすべての可能な順列を単純に組み合わせることは扱いにくいため、複数のトレースにわたってルールセットRをより効率的に評価するために異なるセットアップが必要であり、各トレースは異なるプロセス定義に由来する場合もある。
【0054】
イベントログの解析方法
【0055】
図4は、本明細書で開示される方法の例のグラフィカルな概要を示している。本方法は、次のステップで構成されている。
1.イベントログ内のすべてのトレースからのイベントを、タイムスタンプ順に並べた連続ストリームとして順序付ける/ソートする。
2.ルールセットR内の各ルールriを次のように変換する:
- (セットの)変数V
- イベントの遂行後にそれぞれの変数v∈Vを更新する更新関数Uのセット
- ∀fj∈F,fj→trueである場合、ri→trueであり、そうではない場合、ri→falseであるように、入力変数のセットを所与として評価することができる、対応する評価関数Fのセット。
3.更新関数uj∈Uを使用して、イベントが再生されるごとに、その後各vj∈Vを更新しながら、新しく作成されたストリームを再生する。
4.変数の変更後に関連する評価関数を評価する。
1.イベントログ内のすべてのトレースからのイベントを、タイムスタンプ順に並べた連続ストリームとして順序付ける/ソートする。
2.ルールセットR内の各ルールriを次のように変換する:
- (セットの)変数V
- イベントの遂行後にそれぞれの変数v∈Vを更新する更新関数Uのセット
- ∀fj∈F,fj→trueである場合、ri→trueであり、そうではない場合、ri→falseであるように、入力変数のセットを所与として評価することができる、対応する評価関数Fのセット。
3.更新関数uj∈Uを使用して、イベントが再生されるごとに、その後各vj∈Vを更新しながら、新しく作成されたストリームを再生する。
4.変数の変更後に関連する評価関数を評価する。
【0056】
変数Vのセットは、コンピュータメモリ(揮発性または不揮発性)に記憶されたデータオブジェクトを参照することに留意されたい。それらは、整数、浮動小数点数、文字列、ブールまたは他のデータオブジェクトとして宣言され得る。
【0057】
関数は、1つまたは複数の入力変数と1つまたは複数の出力変数とを有する論理ユニットにグループ化された1つまたは複数のコンピュータ命令を備えるコンピュータプログラムコードを指す。これらの変数は、参照または値によって提供され得る。更新関数Uの出力変数は、変数のVのセットを備える。変数のVのセットは、評価関数の入力変数である。
【0058】
図5は、図1に示されるイベントログの連続したイベントのグラフィカルな概要を示しており、図6において単一のトレースとして表されている。サーバ104は、イベントが属する元のトレース(「pid:」)を依然として追跡していることに留意されたい。
【0059】
例
元のルール
1.マネージャは、同時にイベントBの2つのインスタンスしか処理できない。
2.Bの開始が許可される前に、Aを完了する必要がある。
元のルール
1.マネージャは、同時にイベントBの2つのインスタンスしか処理できない。
2.Bの開始が許可される前に、Aを完了する必要がある。
【0060】
変数:X0(配列)、X1(ビット文字列)、X2(ビット文字列)
変数X0はルール1の計算に使用され、変数X1およびX2はルール2の計算に使用される。
変数X0はルール1の計算に使用され、変数X1およびX2はルール2の計算に使用される。
【0061】
更新関数
・e.name=B,e.lifecycle=start,e.resource=manager⇒X0[e.mid]=X0[e.mid]+1
・e.name=B,e.lifecycle=complete,e.resource=manage⇒X0[e.mid]=X0[e.mid]-1
・
・e.name=B,e.lifecycle=start,e.resource=manager⇒X0[e.mid]=X0[e.mid]+1
・e.name=B,e.lifecycle=complete,e.resource=manage⇒X0[e.mid]=X0[e.mid]-1
・
【0062】
【数2】
【0063】
【数3】
【0064】
上式で、
【0065】
【数4】
【0066】
はプロセスインスタンス識別子の2乗であり、1から昇順である。言い換えれば、
【0067】
【数5】
【0068】
は、プロセスインスタンスのワンホットエンコーディングによるビット文字列である。そのため、「OR」演算(∨)により、イベントログ全体のビット文字列が作成され、各ビットは、トレースの特定のイベントの発生を表す。たとえば、X1は、それぞれのPidについてAが完了したかどうかをビットごとに示すビットのセットを含む。例として、イベントログは0から4の間の5つのプロセスインスタンスPidを有する。次いで、サーバ104は、次のビット文字列X1:00000を作成する。Pid=1についてAが完了すると、X1のビット文字列は00010になる。次いで、Pid=2についてもAが完了すると、X1のビット文字列は00110になる。Pid=4についてBが開始されると、X2のビット文字列は10000になる。ここで、サーバ104が評価関数X1∨X2=X1を遂行すると、ビット文字列X1∨X2:10110が得られ、これはX1=00110と等しくないため、準拠していない(Pid=4についてAが完了する前にBが開始された)。言い換えれば、以下の評価関数では、AがBの前にあるという要件が満たされているかどうかを評価するために必要なのは、論理OR演算だけである。そうでない場合は、ビット文字列間の差は違反トレースを示す。
【0069】
評価関数
・(∀mid)(X0[mid]≦2)
・X1∨X2=X1
・(∀mid)(X0[mid]≦2)
・X1∨X2=X1
【0070】
各イベントが再生された後の変数の進化の抜粋が図7に示されている。
【0071】
開示された手法は、より複雑な論理の使用をチェックすることを可能にし、非常に効率的なクロストレースおよびクロスプロセス分析を提供する。したがって、この手法の利点は次のように要約することができる。
・様々なプロセスインスタンスにわたるログコンプライアンスチェック
・様々なプロセスにわたるログコンプライアンスチェック
・自動ルール変換:
- 変数の自動導出
- 更新関数への自動変換
- 評価関数への自動変換
・結合されたトレースを使用した自動再生とコンプライアンス評価
・様々なプロセスインスタンスにわたるログコンプライアンスチェック
・様々なプロセスにわたるログコンプライアンスチェック
・自動ルール変換:
- 変数の自動導出
- 更新関数への自動変換
- 評価関数への自動変換
・結合されたトレースを使用した自動再生とコンプライアンス評価
【0072】
更新および評価関数
上述のように、サーバ104は、各ログイベントに対して更新関数を遂行する。これらの更新関数は、新しい数値またはブール値をこれらの変数に割り当てることなどによって、変数を更新する。更新関数は、以下を含むがこれらに限定されない算術関数であり得る。
・変数値を増分または減分する、
・変数値に加算する、または変数値から減算する、あるいは
・変数値に対して反復関数を実行する。
上述のように、サーバ104は、各ログイベントに対して更新関数を遂行する。これらの更新関数は、新しい数値またはブール値をこれらの変数に割り当てることなどによって、変数を更新する。更新関数は、以下を含むがこれらに限定されない算術関数であり得る。
・変数値を増分または減分する、
・変数値に加算する、または変数値から減算する、あるいは
・変数値に対して反復関数を実行する。
【0073】
通常、更新される複数の変数が存在することに留意されたい。しかし、各変数は様々なイベントタイプによって更新されるため、すべての変数がすべてのイベントにおいて更新されるわけではない。たとえば、1秒あたり1,000個のイベントによって継続的に更新される変数が100個ある場合がある。一例では、変数は、各ログイベントが受信された後、および次のログイベントが受信される前に更新される。
【0074】
次いで、サーバ104は、変数値がルールに対応するかどうかをテストするために、評価関数を遂行することができる。たとえば、次の評価をテストすることができる。
・正確な値に等しい
・所与の下限しきい値より大きい
・所与の上限しきい値未満
・正確な値に等しい
・所与の下限しきい値より大きい
・所与の上限しきい値未満
【0075】
ここでも、サーバ104は、各ログイベントを受信した後に評価関数を評価することができ、これによりリアルタイムのコンプライアンスチェックが可能になる。
【0076】
一例では、変数ごとに正確に1つの評価関数がある。しかしながら、変数ごとに複数の評価関数が存在する場合がある。さらなる例では、たとえば、2つの変数の合計が所与のしきい値未満であることをテストするなどのために、2つ以上の変数を組み合わせる関数が存在し得る。
【0077】
図1に示されるように、サーバ104は、アクティブなタスクを暗黙的に追跡する。たとえば、t0において、イベントラベルが「A」でライフサイクルが「開始」のイベントがあるとする。これは、タスク「A」が今開始されたことを示している。サーバ104は、タスク「A」の並列インスタンスの数を示す変数を維持することによって、この実行中のタスクを追跡する。そのため、時間t2において、タスク「A」の別のインスタンスが開始される。しかしながら、時間t1において、第1のインスタンスはすでに完了しているため、一度に実行されるインスタンスは1つだけである。変数と更新関数を使用することを通じて、サーバ104は、タスクが異なるコンピュータ101と102でそれぞれ実行されているにもかかわらず、タスクの数を追跡することができ、遂行において重複する可能性がある。
【0078】
したがって、サーバ104が持続時間のタスクを表す方法は、開始イベントおよび停止イベントを通じ、次いで各開始イベントおよび停止イベントにおいて変数を更新することである。
【0079】
いくつかの例では、サーバ104は、マネージャを契約開始イベントに接続するなど、開始イベントをリソースと接続する。この例では、2人のマネージャが両方とも5つの契約で作業できる場合があるが、第1のマネージャが6つの契約を有し、第2のマネージャが2つの契約を有している場合、システムは準拠していない。
【0080】
すべての変数がイベントおよび評価イベントに接続されるため、評価グラフの作成と比較するなどして、この手法は複雑さを大幅に軽減することに留意されたい。さらに、開示された方法は、リソース集約型でもあるバックトレースを防止する。
【0081】
サーバ104は、変数が規制の顕著な特徴を表し、更新関数および評価関数が規制を表すために変数上で定式化できるように、規制と変数との間のマッピングにおいて動作することにさらに留意されたい。言い換えれば、規制は変数のセットに変換され、これらの変数が一緒に、その特定のイベントログのコンプライアンスを示す証明値を提供するために十分である。
【0082】
さらなる例では、各変数はイベントログ内の特定のイベントに接続されており、これは、イベントログ内のイベントと対応する規制との間にブリッジがあることを意味する。更新関数は、イベントログを処理しながら、ブリッジを最新の状態に保つ。評価関数は、複雑な手順のセットであり、規制に対するイベントログのコンプライアンスをリアルタイムで更新するために、値に対する真の値を抽出する。
【0083】
一例では、規制は、義務に関する無効にできる論理などの論理形式で定式化される。規制はビジネスルールを表すことができるが、論理形式に変換される。これらの規制は、契約、ビジネスルール、または他のソースから発生する可能性がある。
【0084】
さらなる例では、ルールは、更新関数によって更新される変数と同じアトミックリテラルを備え得る。しかしながら、他の例では、ルール内のアトミックリテラルは更新された変数と同じではない。
【0085】
一例では、変換は、ルールから変数を取得すること、イベントログが変数を提示する標準化された方法を持たない更新された関数を決定するために手動マッピングすることを備える。言い換えれば、変数の使用が標準化されている場合、ルールから更新関数および評価関数への変換を自動化することができる。
【0086】
さらなる例示的な実装形態では、すべての変数がすべてのプロセスにわたってグローバルであるため、第1のプロセスからのログイベントの結果として更新される任意の変数を、第2のプロセスからの後続のログイベントの結果としてさらに更新することができる。
【0087】
評価関数/述語
一例では、評価関数は評価述語によってモデル化される。評価述語は、条件が満たされた場合に真(true)を返し、それ以外の場合に偽(false)を返すブール関数を使用して、条件の発生をキャプチャする。このように、評価関数は、特定の時点において発生し、その時点とともに記録することができる評価述語によって表される。
一例では、評価関数は評価述語によってモデル化される。評価述語は、条件が満たされた場合に真(true)を返し、それ以外の場合に偽(false)を返すブール関数を使用して、条件の発生をキャプチャする。このように、評価関数は、特定の時点において発生し、その時点とともに記録することができる評価述語によって表される。
【0088】
評価述語は、単一の反復において複雑な接続詞を評価するために、論理接続詞を使用してグラフ状の構造において定義され得る。これは、サーバ104がグラフ状の構造を記憶し、評価述語に関連付けられる値を計算するために、イベント発生ごとにグラフ状の構造を評価することを意味する。
【0089】
グラフ構造を使用した結果、評価述語が相互に優先される場合がある。すなわち、特定の評価述語が別の評価述語の後に発生する必要がある場合がある。さらに、評価述語にも制限がある場合がある。たとえば、特定の評価述語は、別の評価述語が真である場合にのみ考慮することが許可される場合がある。
【0090】
最後に、評価述語により、遅延変数の概念が可能になる。これは、変数の必要な値が設計時には不明であり、評価中に遂行から取得されることを意味する。
【0091】
方法
図8は、ログデータを分析するための方法800を示している。方法800は、サーバ104によって実行され得る。その例では、サーバ104は、複数の異なるプロセスからの複数のログイベントを備えるログデータを受信する(801)。ログデータは、テキストファイル、データベース、あるいはデータパイプまたはストリームの形式であり得る。複数のログイベントの各々は、そのログイベントの生成を引き起こしたイベントがいつ発生したかを示すイベント時間に関連付けられている。
図8は、ログデータを分析するための方法800を示している。方法800は、サーバ104によって実行され得る。その例では、サーバ104は、複数の異なるプロセスからの複数のログイベントを備えるログデータを受信する(801)。ログデータは、テキストファイル、データベース、あるいはデータパイプまたはストリームの形式であり得る。複数のログイベントの各々は、そのログイベントの生成を引き起こしたイベントがいつ発生したかを示すイベント時間に関連付けられている。
【0092】
サーバ104は、複数の異なるプロセスからの複数のログイベントを備えるログイベントの単一のストリームを作成する(802)。ログイベントの単一のストリームは、関連付けられるイベント時間によってソートされる。この単一のストリーム(または、「トレース」)は、新しいテキストファイルとして記憶されてもよく、元のログファイルを上書きしてもよく、RAMなどの揮発性ストレージに保存されてもよく、SQLデータベースの記録などのデータベースエントリとして保存されてもよい。さらなる例では、元のログデータは、SQLデータベースに任意の順序で記憶されてよく、サーバ104は、「タイムスタンプによって順序付ける(ORDER BY timestamp)」指示を含む「SELECT * FROM logdata」コマンドを発行することによって、ログイベントをソートする。
【0093】
サーバ104は、収集データオブジェクトの「次の(next)」ルーチンを呼び出すなどして、ログイベントの単一のストリームに対してを繰り返す(803)。ログイベントごとに、サーバ104は、ログイベントに基づいて変数セットの更新を定義する1つまたは複数の更新関数を遂行する。それによって、サーバ104は、変数のセットのうちの1つまたは複数の更新された値を計算する。たとえば、サーバ104は、特定のプロセスの実行中のインスタンスの数を維持する変数を増分または減分する。方法800のこの時点で、サーバ104は、ログデータのコンプライアンスを決定するために、次のログイベントを取得するためにループバックして、更新関数を遂行するステップ804のみを反復し得、次いで、変数のセットに対して1つまたは複数の評価関数を遂行する(805)。
【0094】
しかしながら、ほとんどの例では、サーバ104は、各更新ステップ804の後に1つまたは複数の評価関数を遂行する(805)。すなわち、評価関数の遂行後から次のログイベント803の取得まで戻って反復する、点線として示される反復ループ807がある。これは、サーバ104が各ログイベントを処理した後、すなわち更新関数の各遂行後に評価関数を遂行することを意味する。これは、各ログイベントの後に最新のコンプライアンス値が利用可能であることも意味する。
【0095】
1つまたは複数の評価関数は、変数のセットに基づいてコンプライアンスルールを表す。たとえば、評価関数は、特定のプロセスの実行中のインスタンスの数が上限しきい値を下回るなど、条件が満たされた場合に真と評価される。複数の評価関数がある場合、すべての評価関数が真と評価される場合、全体の動作は準拠している(806)。言い換えれば、最終的な真/偽または0/1準拠値を作成するために、すべての評価関数の評価値が「AND」接続される。
【0096】
一部のログイベントでは更新ステップ804の後に反復がループバックし、他のログイベントでは評価関数805の後に反復がループバックするハイブリッドバージョンも可能であることに留意されたい。これは、評価の数を減らすことができるという意味で、処理負荷を調整するために使用され得る。たとえば、ログイベント生成の速度が、1秒あたり1,000個のログイベントの生成など、人間がコンプライアンス値の変化を認識できる速度よりも早い場合、サーバ104は、毎秒1回、または1,000個のログイベントに対して更新関数を遂行した後に、805において評価関数を遂行し得る。
【0097】
アプリケーション
開示された方法は、様々な異なるアプリケーションにおいて使用され得る。たとえば、iOS（登録商標）、Windows（登録商標）、またはLinux（登録商標）などのオペレーティングシステムを遂行しているコンピュータシステムのログを分析するために、開示された方法が使用され得る。このシナリオでは、共通のログファイルが存在し、不揮発性ストレージに永続的に記憶され、新しいイベントがログファイルに追加され得る。より具体的には、コンピュータシステム上で複数のプロセスが実行され(ソフトウェアプログラムの様々なバイナリを遂行することなどによって)、各プロセスがログイベントを共通のログファイルに追加する。各プロセスは、開始および停止イベントを追加し得、サーバ104はこれらを上述のように処理する。
開示された方法は、様々な異なるアプリケーションにおいて使用され得る。たとえば、iOS（登録商標）、Windows（登録商標）、またはLinux（登録商標）などのオペレーティングシステムを遂行しているコンピュータシステムのログを分析するために、開示された方法が使用され得る。このシナリオでは、共通のログファイルが存在し、不揮発性ストレージに永続的に記憶され、新しいイベントがログファイルに追加され得る。より具体的には、コンピュータシステム上で複数のプロセスが実行され(ソフトウェアプログラムの様々なバイナリを遂行することなどによって)、各プロセスがログイベントを共通のログファイルに追加する。各プロセスは、開始および停止イベントを追加し得、サーバ104はこれらを上述のように処理する。
【0098】
さらなるアプリケーションシナリオでは、航空機または原子力発電所などの、複雑で信頼性の高いシステムが存在する可能性がある。やはり、これらのシナリオでは、それぞれがログイベントを生成する多数の相互接続されたモジュールがある。本明細書に開示された方法およびシステムを用いて、これらの動作をリアルタイムで監視し、適切な機能の詳細な評価を保証することができる。たとえば、航空機の場合など、様々なカテゴリのイベントに対する評価関数が存在し得、たとえば、エンジンの動作範囲に関するエンジンのコンプライアンスを車内システムとは別に評価できるように、エンジンのみの評価関数のセットが存在する場合がある。上記の条件付きの義務の概念を使用して、複雑なコンプライアンス条件を策定することも可能である。
【0099】
コンピュータシステム
図9は、別のシステム101のコンプライアンスを監視するためのコンピュータシステム900を示している。その意味で、コンピュータシステム900は、図1の処理サーバ104の例示的な実装形態である。コンピュータシステム900は、ログデータを分析することによってシステム101のコンプライアンスを監視する。コンピュータシステム900は、プロセッサ901、プログラムメモリ902、データメモリ903、および通信ポート904を備える。プロセッサ901は、図8における方法800を実行するように構成される。
図9は、別のシステム101のコンプライアンスを監視するためのコンピュータシステム900を示している。その意味で、コンピュータシステム900は、図1の処理サーバ104の例示的な実装形態である。コンピュータシステム900は、ログデータを分析することによってシステム101のコンプライアンスを監視する。コンピュータシステム900は、プロセッサ901、プログラムメモリ902、データメモリ903、および通信ポート904を備える。プロセッサ901は、図8における方法800を実行するように構成される。
【0100】
より具体的には、プログラムメモリ902は、プログラムコードが記憶された非一時的メモリである。プログラムコードは、方法800のソフトウェア実装形態であり、バイナリとしてコンパイルされた形式で、または別の解釈可能な形式で記憶され得る。プロセッサ901は、プロセッサ901が方法800を実行するための命令を含むプログラムコードを読み取る。ログデータ、ログイベント、更新関数および評価関数、ならびに変数は、プログラムメモリ902(関数用)またはデータメモリ903(変数用)に記憶されるデータ構造であることに留意されたい。
【0101】
プロセッサ901は、複数の異なるプロセスから複数のログイベントを備えるログデータを受信し、複数のログイベントの各々は、イベント時間に関連付けられている。次いで、プロセッサ901は、複数の異なるプロセスからの複数のログイベントを備えるログイベントの単一ストリームを作成し、そのストリームをデータメモリ903に記憶する。ログイベントの単一のストリームは、関連付けられるイベント時間によってソートされる。次いで、プロセッサ901は、ログイベントの単一のストリームを反復する。ログイベントごとに、プロセッサ901は、変数のセットのうちの1つまたは複数の更新された値を計算するために、ログイベントに基づいて変数のセットの更新を定義する1つまたは複数の更新関数を遂行する。最後に、プロセッサ901は、ログデータのコンプライアンスを決定するために、変数のセットに対して1つまたは複数の評価関数を遂行する。1つまたは複数の評価関数は、変数のセットに基づいてコンプライアンスルールを表す。
【0102】
プロセッサ901はまた、決定されたコンプライアンスに応答してアクションを実行し得る。たとえば、プロセッサ901は、ノンコンプライアンス(non-compliance)が検出されると、アラームを発するか警告メッセージを送信することなどによって軽減アクションを開始してもよく、他のシステム101の動作を一括して停止してもよい。
【0103】
グラフ構造
以下の開示は、1)グラフ状の構造がどのように定義されるか、および2)モデル化されたルールがいつでも準拠しているかどうかを決定するために構造を解釈する方法を提供する。
以下の開示は、1)グラフ状の構造がどのように定義されるか、および2)モデル化されたルールがいつでも準拠しているかどうかを決定するために構造を解釈する方法を提供する。
【0104】
グラフ構造は次のように与えられる。
・集合のセットであり、各集合は更新関数、評価関数、および変数のセットを備え、各集合は単一の変数タイプによってグループ化される。たとえば、集合は、変数Xを更新するすべての更新関数と評価関数を含み得る。
・論理演算子のセット。主にAND/ORであるが、これはXORなどのこれらの変形も含み得る。
・集合と論理演算子に対して定義された優先関係(すなわち、論理ノードと集合ノードとの間のエッジ)。
・別の集合が「発生した(occurred)」場合に(その時点で)集合を考慮する必要があるかどうかを説明する、集合に対して定義される制限関係。
・どのノードを最初に考慮する必要があるかを説明するエントリポイント。
・集合のセットであり、各集合は更新関数、評価関数、および変数のセットを備え、各集合は単一の変数タイプによってグループ化される。たとえば、集合は、変数Xを更新するすべての更新関数と評価関数を含み得る。
・論理演算子のセット。主にAND/ORであるが、これはXORなどのこれらの変形も含み得る。
・集合と論理演算子に対して定義された優先関係(すなわち、論理ノードと集合ノードとの間のエッジ)。
・別の集合が「発生した(occurred)」場合に(その時点で)集合を考慮する必要があるかどうかを説明する、集合に対して定義される制限関係。
・どのノードを最初に考慮する必要があるかを説明するエントリポイント。
【0105】
優先関係は再帰的ではなく、各集合は論理演算子にのみ関連している。便宜上、2つの集合の間にエッジを直接配置することは許容される。これは純粋に構文上のものであり、仲介者としてAND演算子があると暗黙的に解釈することができる。
【0106】
ここで、集合の「発生(occurrence)」は、変数が評価述語を満たし、もはや有効ではない値に更新される時点として定義される(すなわち、イベントBを探し、次いでイベントBを観察する)。留意すべき微妙な点は、メンテナンスルールを別の方法で解釈しなければならないことである。たとえば、銀行口座の残高がプラスのときに準拠する集合の「発生」は、口座が常にプラスの場合は意味がない。この場合、集合は評価の時点まで有効である。
【0107】
集合の発生の否定を考慮することが望ましい場合があり、たとえば、ルールが何らかの補償イベントの発生を必要とする場合、変数のデータを2回記録したくない。
【0108】
グラフ構造における各ノードは、論理演算子または集合の2つのタイプのうちの1つを表し得る。両方のタイプは、優先関係を通じて交換可能に接続され得る。集合は、複数のノード内で定義することができる。集合ベースの各ノードは、集合の否定を表し得る。すなわち、代表的な集合が発生した場合、評価述語の否定を結果として取得する。グラフのエントリポイントから、集合ベースのノードの深さによって相互に優先順位が確立される。すなわち、特定の集合が別の集合の後に発生する必要がある場合がある。
【0109】
グラフ状の構造は、所与のエントリポイントから左から右に評価され、グラフ状の構造が「非準拠(incompliant)」または「準拠(compliant)」と表明されるまで続く。そのような結果は、各集合内の変数がそれぞれのすべての評価述語を満たしているかどうか、有効ではなくなっているかどうか、およびグラフの論理構造を満たしているかどうかの結果である。
【0110】
グラフ例1
図10は、グラフ構造の例を提供しており、ここで、「開始(Start)」ノードはエントリポイントを表し、ノード「請求書(Invoice)」および「支払い(Pay)」は集合であり、ノード「または(or)」ならびに「および(and)」は論理接続子であり、それぞれの黒い実線は優先関係を表し、各点線は制約関係を表す。
図10は、グラフ構造の例を提供しており、ここで、「開始(Start)」ノードはエントリポイントを表し、ノード「請求書(Invoice)」および「支払い(Pay)」は集合であり、ノード「または(or)」ならびに「および(and)」は論理接続子であり、それぞれの黒い実線は優先関係を表し、各点線は制約関係を表す。
【0111】
【0112】
仮説的には、次の集合を有している可能性がある。
【0113】
請求書
・変数:X0(ブール)
・更新関数:e.name=invoice,e.lifecycle=complete⇒X0=true
・評価関数:X0=true
・変数:X0(ブール)
・更新関数:e.name=invoice,e.lifecycle=complete⇒X0=true
・評価関数:X0=true
【0114】
支払い
・変数:X1(浮動小数点数)
・更新関数:e.name=payment,e.lifecycle=complete⇒X1=X1+e.amount
・評価関数:X1=100
・変数:X1(浮動小数点数)
・更新関数:e.name=payment,e.lifecycle=complete⇒X1=X1+e.amount
・評価関数:X1=100
【0115】
この例は小さく、評価関数φ=￢X0∨(X1=100)に類似している。しかしながら、留意すべき違いは、X1(pay)へのすべての単一の更新においてφがチェックされるため、X1が変更するたびに￢X0が真かどうかの冗長なチェックが行われることである。これは、たとえば、ほとんどまたはすべてのイベントに対して複数の冗長なチェックが行われている場合、非効率的である。この場合、グラフ構造は、1)集合が発生したときにリッスンし、2)関連する集合をチェックすることによってルールのコンプライアンスをチェックするために、この発生時点でグラフをトラバースすることによってこの問題を回避することができる。
【0116】
さらに、集合が発生すると、集合に含まれる更新関数のセットを破棄することができるため、各イベントのチェック回数がさらに削減される。同様に、各集合に関連する現在使用されている変数もオプションで破棄できる場合がある。
【0117】
もう1つの利点は、ルールを修正または拡張するために、そのようなグラフ構造を簡単に操作することができることである。
【0118】
グラフ例2
図11は、より複雑な更新関数(すなわち、複数の変数に依存する更新関数)を使用しないと、グラフを単一の評価関数に縮小できない例を示している。この例には、「A」、「AtMostTwoB」、および「AtMostTwoC」の3つの集合を含んでおり、本明細書で与えられた例と似ている。赤い点線は、集合「A」と「AtMostTwoB」/「AtMostTwoB」との間の制限関係を表し、集合「A」が発生した場合にのみこれらの集合を更新する必要があることを指定する。グラフ構造は、次のルールをエンコードする。
図11は、より複雑な更新関数(すなわち、複数の変数に依存する更新関数)を使用しないと、グラフを単一の評価関数に縮小できない例を示している。この例には、「A」、「AtMostTwoB」、および「AtMostTwoC」の3つの集合を含んでおり、本明細書で与えられた例と似ている。赤い点線は、集合「A」と「AtMostTwoB」/「AtMostTwoB」との間の制限関係を表し、集合「A」が発生した場合にのみこれらの集合を更新する必要があることを指定する。グラフ構造は、次のルールをエンコードする。
【0119】
ルール
・イベントAが発生した場合、マネージャはイベントBの最大2つのインスタンスを同時に処理することができる。イベントAの後に発生するイベントBのみをカウントする。
・イベントAが発生した場合、マネージャはイベントCの最大2つのインスタンスを同時に処理することができる。イベントAの後に発生するイベントBのみをカウントする。
・イベントAが発生した場合、マネージャはイベントBの最大2つのインスタンスを同時に処理することができる。イベントAの後に発生するイベントBのみをカウントする。
・イベントAが発生した場合、マネージャはイベントCの最大2つのインスタンスを同時に処理することができる。イベントAの後に発生するイベントBのみをカウントする。
【0120】
この場合、集合「A」が発生していなければ、集合「AtMostTwoB」と「AtMostTwoB」の両方を無視して、必要な更新回数を減らすことができる。したがって、どの集合が関連しており、考慮する必要があるかをメモリ内に維持する手段として、グラフを繰返しトラバースすることができる。
【0121】
そのような構造を使用しない場合、次のように更新関数を定式化し得る。
・変数:X0(ブール値)、X1(整数)、X2(整数)
・更新関数:
- e.name=A,e.lifesysle=complete⇒X0=true
- e.name=B,e.lifesysle=start,X0=true⇒X1=X1+1
- e.name=B,e.lifesysle=complete,X0=true⇒X1=X1-1
- e.name=C,e.lifesysle=start,X0=true⇒X2=X2+1
- e.name=C,e.lifesysle=complete,X0=true⇒X2=X2-1
・評価関数:￢X0∨(X1≦2∧X2≦2)
・変数:X0(ブール値)、X1(整数)、X2(整数)
・更新関数:
- e.name=A,e.lifesysle=complete⇒X0=true
- e.name=B,e.lifesysle=start,X0=true⇒X1=X1+1
- e.name=B,e.lifesysle=complete,X0=true⇒X1=X1-1
- e.name=C,e.lifesysle=start,X0=true⇒X2=X2+1
- e.name=C,e.lifesysle=complete,X0=true⇒X2=X2-1
・評価関数:￢X0∨(X1≦2∧X2≦2)
【0122】
しかしながら、X0が偽である場合、最後の4つの更新関数(すなわち、X1、X2を更新する関数)をチェックする必要がないことがわかる。これらの関数はすべてのイベントにおいてチェックされるため、多くの冗長なチェックが発生する。
【0123】
ドメイン上でのグラフのスケーリング
グラフ構造により、インスタンスのドメイン全体のスケーリングが可能になる。例として、すべてのプロセスをスケールオーバするドメインと見なす場合がある。本明細書における例を考えると、各マネージャは固有のプロセス遂行に対応する。しかしながら、本方法はすべてのイベントを連続ストリームとしてソートするため、本方法は他のドメインも考慮することができる。たとえば、ルールでは、毎日、職場の最大スタッフ数が20人未満でなければならないことを検証したい場合がある。この場合、毎日のルールを検証したいので、ドメインは関連するすべての日のセットである。
グラフ構造により、インスタンスのドメイン全体のスケーリングが可能になる。例として、すべてのプロセスをスケールオーバするドメインと見なす場合がある。本明細書における例を考えると、各マネージャは固有のプロセス遂行に対応する。しかしながら、本方法はすべてのイベントを連続ストリームとしてソートするため、本方法は他のドメインも考慮することができる。たとえば、ルールでは、毎日、職場の最大スタッフ数が20人未満でなければならないことを検証したい場合がある。この場合、毎日のルールを検証したいので、ドメインは関連するすべての日のセットである。
【0124】
この概念をサポートするために、凝縮表記法が開発された。グラフの例1の続きで、作成されたすべての請求書インスタンスのルールを検証したい場合がある。これのグラフ表現が図12に示されている。この表記法は純粋に構文上のものであり、idごとに1つ、図10のコピーの「無限(infinite)」接続を表すことに注意することが重要である。
【0125】
実装形態に関しては、これは請求書idごとに新しいインスタンスを作成するものと見なされる。この問題の複雑さは、プロセッサ901がより複雑なドメインを考慮し、このドメインの一部に対して発生する集合を有するときに増加する。たとえば、単一のブランチを更新するドメイン(branch_id,manager_id)と集合を考える。これは、ブランチ内のすべてのマネージャとの1対多の関係である。特にいくつかのプリエンプティブな計算が必要な場合は、どの「コピー」ペアを作成する必要があるかを推測するのは困難である。
【0126】
しかしながら、この表記法は純粋に構文上のものであるため、これらの追加の複雑さは、グラフ構造定義によってすでにキャプチャされているはずである。
【0127】
グラフ構造をトラバースする方法
トラバースの方法は、本明細書で提示された方法を適応させたものである。集合は、更新関数、評価関数、および変数のセットであり、各集合は単一の変数タイプ(上記で定義)によってグループ化される。ルールセットをモデル化するグラフ構造が与えられると、本方法は次のように簡単に説明することができる。
1.イベントログの評価中に考慮される集合Cのセットを維持する。グラフのエントリポイントから、エントリポイントに関連する各集合を制約関係によって追加する。
2.イベントのストリームを再生し、それぞれの更新関数を使用してCにおける各集合を更新する。
3.変数の変更後に関連する評価関数を評価する。グラフ内のノードが「発生」した場合、すなわち、そのノードが基になる集合に基づいて真と表明された場合は、次の手順を実行する。
i.チェックが必要な次の集合のセットでセットCを更新する。
ii.コンプライアンスを評価するために、グラフ構造をトラバースし、グラフの論理構造を検証する。グラフ構造が証明可能な準拠または非準拠であると表明された場合は、終了する。
iii.それ以外の場合は、検索に不要になった集合をCから削除する。
4.イベントログの繰返しが完了した後、まだ決定されておらず、有効間隔が評価のポイントとして指定されているCにおける集合に対して、ステップ3を繰り返す。
トラバースの方法は、本明細書で提示された方法を適応させたものである。集合は、更新関数、評価関数、および変数のセットであり、各集合は単一の変数タイプ(上記で定義)によってグループ化される。ルールセットをモデル化するグラフ構造が与えられると、本方法は次のように簡単に説明することができる。
1.イベントログの評価中に考慮される集合Cのセットを維持する。グラフのエントリポイントから、エントリポイントに関連する各集合を制約関係によって追加する。
2.イベントのストリームを再生し、それぞれの更新関数を使用してCにおける各集合を更新する。
3.変数の変更後に関連する評価関数を評価する。グラフ内のノードが「発生」した場合、すなわち、そのノードが基になる集合に基づいて真と表明された場合は、次の手順を実行する。
i.チェックが必要な次の集合のセットでセットCを更新する。
ii.コンプライアンスを評価するために、グラフ構造をトラバースし、グラフの論理構造を検証する。グラフ構造が証明可能な準拠または非準拠であると表明された場合は、終了する。
iii.それ以外の場合は、検索に不要になった集合をCから削除する。
4.イベントログの繰返しが完了した後、まだ決定されておらず、有効間隔が評価のポイントとして指定されているCにおける集合に対して、ステップ3を繰り返す。
【0128】
集合Cのセットは、永続的なブロックストレージに頼ることなくCにおける集合にすばやくアクセスできるように、揮発性ランダムアクセスメモリ(RAM)内のスペースを占有するクラスまたは変数インスタンスなどのコンピュータプログラムのオブジェクトであり得、これは、小さいデータの読取りおよび書込みアクセスには低速で非効率的である。しかしながら、セットCが大きくなると、一般的なコンピュータシステム上で使用できるRAMの量をすぐに超えてしまう可能性がある。Cに対して集合を動的に追加および削除することによって、一度に使用されるRAMの量を、使用可能な物理RAMの制限内に抑えることができる。
【0129】
マージ
ルールごとに(またはルールのグループにおいて)ルールRのセットを評価する代わりに、Rを単一のグラフ構造にマージすることができる。グラフ構造により、状態または集合を共有できるため、計算とメモリを複製する必要がなくなる。さらに、状態または集合をより効率的に共有するために、更新関数を修正/分離できる場合もある。
ルールごとに(またはルールのグループにおいて)ルールRのセットを評価する代わりに、Rを単一のグラフ構造にマージすることができる。グラフ構造により、状態または集合を共有できるため、計算とメモリを複製する必要がなくなる。さらに、状態または集合をより効率的に共有するために、更新関数を修正/分離できる場合もある。
【0130】
当業者は、本開示の広い一般的範囲から逸脱することなく、上述の実施形態に対して多数の変形および/または修正を行うことができることを理解するであろう。したがって、本実施形態は、すべての点において例示的であり、限定的ではないと見なされるべきである。
【符号の説明】
【0131】
100 コンピュータネットワーク
101 コンピュータ
101 システム
102 コンピュータ
103 コンピュータ
104 ログ処理サーバ
111 イベントログ
112 イベントログ
113 イベントログ
122 プロセスID
123 イベントID
124 イベントラベル
125 タイムスタンプ
126 ライフサイクル
300 有効な間隔
301 トリガ
302 期限
800 方法
900 コンピュータシステム
901 プロセッサ
902 プログラムメモリ
903 データメモリ
904 通信ポート
101 コンピュータ
101 システム
102 コンピュータ
103 コンピュータ
104 ログ処理サーバ
111 イベントログ
112 イベントログ
113 イベントログ
122 プロセスID
123 イベントID
124 イベントラベル
125 タイムスタンプ
126 ライフサイクル
300 有効な間隔
301 トリガ
302 期限
800 方法
900 コンピュータシステム
901 プロセッサ
902 プログラムメモリ
903 データメモリ
904 通信ポート
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【国際調査報告】