(57)【要約】  グデータ内の関連するイベントのシーケンスを取得するため、リクエスト式をパースし、検索されるイベント間の依存性と、各イベントを特徴付ける制約条件（例えば、キーワード）とを取得する。パースの結果に基づいて、個々のイベントの制約条件とイベント間の相互関係（例えば期間）を表すクエリ要素が形成される。結果として生成される、クエリ要素を備えたスパンクエリは、ストレージ内の関連するイベントの相互位置をコード化したイベントのインデックスに対して実行される。【選択図】図２
2010541102.tif 000002
【特許請求の範囲】
【請求項１】
ログデータ内の関連するイベントを検索する方法であって、
１以上のイベントをログメッセージとして格納するステップと、
第１クエリに対する応答内において１以上のイベントを取得できる形態で前記ログメッセージ内の語句のインデックスを生成するステップと、
前記第１クエリをパースするステップと、
前記第１クエリを実行するステップと、
前記第１クエリを実行した結果を取得するステップと、
前記結果に基づいて関連するイベントに対する第２クエリを形成するステップと、
前記インデックス上で前記第２クエリを実行して関連するイベントを判定するステップと、
を有する方法。
【請求項２】
前記判定された関連するイベントを属性によってグループ分けするステップを有する、
請求項１記載の方法。
【請求項３】
前記第２クエリは、イベントクエリのシーケンス、複数制約クエリ、および因果関係クエリを構成するクエリ種別のグループから選択される、
請求項１記載の方法。
【請求項４】
前記イベントクエリのシーケンスを形成するステップは、
個々のログメッセージについて１以上のクエリを構築するステップと、
個々のログメッセージについてのクエリを、複数ログメッセージにわたるスパンクエリとして統合するステップと、
を有する、請求項３記載の方法。
【請求項５】
前記イベントクエリのシーケンスを実行するステップは、
個々のログメッセージについてのクエリを実行するステップと、
個々のログメッセージについてのクエリ結果間の時間を判定するステップと、
前記ログメッセージが前記判定された時間内で発生することを検証するステップと、
を有する、請求項４記載の方法。
【請求項６】
前記複数制約クエリを形成するステップは、
中間イベントについての第１クエリを決定するステップと、
最終イベントについての第２クエリを決定するステップと、
を有する、請求項３記載の方法。
【請求項７】
ログデータ内の関連するイベントを検索する方法であって、
固定要素と可変要素を識別する第１クエリを処理するステップと、
前記固定および可変要素を統合することによって第２クエリを形成するステップと、
前記第２クエリを実行して明らかにすべき統合イベントを識別するステップと、
第１期間内の識別された統合イベントに先行するイベントを取得するステップと、
前記固定要素に基づき第３クエリを実行して明らかにすべき固定イベントを識別するステップと、
第２期間内の識別された固定イベントに先行するイベントを取得するステップと、
識別された統合イベントについての共通部分の第１セットを構築するステップと、
識別された固定イベントについての共通部分の第２セットを構築するステップと、
前記共通部分の第１および第２セット内の共通部分間の差異を判定するステップと、
を有する方法。
【請求項８】
前記第１クエリに対する見込み回答として差異のリストを出力するステップを有する、
請求項７記載の方法。
【請求項９】
前記第２クエリは、複数のクエリ種別と、少なくとも１つの中間クエリを含む少なくとも１つのクエリ種別とを有する、
請求項１記載の方法。
【請求項１０】
イベントデータ内のイベントシーケンスを識別するシステムであって、
イベントデータをインデックス付けして取得できるようにする動作が可能な記憶装置と、
前記記憶装置に連結され、イベントシーケンスについてのクエリを構築するためユーザによって指定された記述子を解釈し、前記クエリ内に含まれる条件を満たすイベントシーケンスを識別する動作が可能なプロセッサと、
を有するシステム。
【請求項１１】
前記イベントデータはログメッセージを含む、請求項１０記載のシステム。
【請求項１２】
１以上のイベントをログメッセージとして格納する動作が可能な記憶装置と、
前記記憶装置に連結され、第１クエリに対する応答内において１以上のイベントを取得することができる形態で前記ログメッセージ内の語句のインデックスを生成し；前記第１クエリをパースし；前記第１クエリを実行し；前記第１クエリを実行した結果を取得し；前記結果に基づいて関連するイベントについての第２クエリを形成し；前記インデックス上で前記第２クエリを実行して関連するイベントを判定する動作が可能なプロセッサと、
を有するシステム。
【請求項１３】
前記判定された関連するイベントを属性によってグループ分けする、
請求項１２記載のシステム。
【請求項１４】
前記第２クエリは、イベントクエリのシーケンス、複数制約クエリ、および因果関係クエリを構成するクエリ種別のグループから選択される、
請求項１２記載のシステム。
【請求項１５】
前記イベントクエリのシーケンスを形成する際に、
個々のログメッセージについて１以上のクエリを構築し、
個々のログメッセージについてのクエリを、複数ログメッセージにわたるスパンクエリとして統合する、
請求項１４記載のシステム。
【請求項１６】
前記イベントクエリのシーケンスを実行する際に、
個々のログメッセージについてのクエリを実行し、
個々のログメッセージについてのクエリ結果間の時間を判定し、
前記ログメッセージが前記判定された時間内で発生することを検証する、
請求項１５記載のシステム。
【請求項１７】
前記イベントクエリのシーケンスを実行する際に、
期間を制約として含む単一のクエリを実行する、
請求項１５記載のシステム。
【請求項１８】
前記複数制約クエリを形成する際に、
中間イベントについての第３クエリを決定し、
最終イベントについての第４クエリを決定する、
請求項１４記載のシステム。
【請求項１９】
１以上のイベントをログメッセージとして格納する動作が可能な記憶装置と、
前記記憶装置に連結され、固定要素および可変要素を識別する第１クエリを処理し；前記固定および可変要素を統合することによって第２クエリを形成し；前記第２クエリを実行して明らかにすべき統合イベントを識別し；第１期間内の識別された統合イベントに先行するイベントを取得し；前記固定要素に基づき第３クエリを実行して明らかにすべき固定イベントを識別し；第２期間内の識別された固定イベントに先行するイベントを取得し；識別された統合イベントについての共通部分の第１セットを構築し；識別された固定イベントについての共通部分の第２セットを構築し；前記共通部分の第１および第２セット内の共通部分間の差異を判定する動作が可能なプロセッサと、
を有するシステム。
【請求項２０】
前記第１クエリに対する見込み回答として差異のリストを出力する、
請求項１９記載のシステム。
【請求項２１】
プロセッサが実行することによって前記プロセッサに処理を実行させる命令を有する、コンピュータ読取可能な媒体であって、前記処理は、
１以上のイベントをログメッセージとして格納するステップと、
第１クエリに対する応答内において１以上のイベントを取得できる形態で前記ログメッセージ内の語句のインデックスを生成するステップと、
前記第１クエリをパースするステップと、
前記第１クエリを実行するステップと、
前記第１クエリを実行した結果を取得するステップと、
前記結果に基づいて関連するイベントに対する第２クエリを形成するステップと、
前記インデックス上で前記第２クエリを実行して関連するイベントを判定するステップと、
を有するコンピュータ読取可能媒体。
【請求項２２】
前記処理は、前記判定された関連するイベントを属性によってグループ分けするステップを有する、
請求項２１記載のコンピュータ読取可能媒体。
【請求項２３】
前記第２クエリは、イベントクエリのシーケンス、複数制約クエリ、および因果関係クエリを構成するクエリ種別のグループから選択される、
請求項２１記載のコンピュータ読取可能媒体。
【請求項２４】
１以上のイベントをログメッセージとして格納する手段と、
第１クエリに対する応答内において１以上のイベントを取得できる形態で前記ログメッセージ内の語句のインデックスを生成する手段と、
前記第１クエリをパースする手段と、
前記第１クエリを実行する手段と、
前記第１クエリを実行した結果を取得する手段と、
前記結果に基づいて関連するイベントに対する第２クエリを形成する手段と、
前記インデックス上で前記第２クエリを実行して関連するイベントを判定する手段と、
を有するシステム。
【請求項２５】
前記第２クエリは、イベントクエリのシーケンス、複数制約クエリ、および因果関係クエリを構成するクエリ種別のグループから選択される、請求項２４記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願の主題は、主にコンピュータログの管理に関する。
【背景技術】
【０００２】
ログ管理は、例えばサーバ、ルータ、スイッチ、ファイアウォール、などの様々なコンピュータネットワークデバイスから、データを収集し、統合し、解析し、警告を発し、アーカイブするプロセスである。ログ検索は、イベントに関連する個々のログメッセージを識別するプロセスである。ログ検索は、ログ管理の一部として、企業のコンプライアンス目標を達成する手助けをすることができ、また機密保護違反による法的漏洩のリスクを低減する。ログ検索はまた、ＩＴ（ｉｎｆｏｒｍａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ）部門がネットワーク内の特定の問題を識別し、それらの問題と潜在的に関連しているログメッセージを識別し分析することによってそれらの問題を解決する手助けをすることにより、ネットワークのダウンタイムを大幅に低減ことができる。
【０００３】
ログ解析の重要な側面は、関連するログメッセージ（例えば、関連する２または３のログメッセージ）を検索することができる能力である。従来の検索手法では、検索項目のシーケンスを取得することができるインデックスを用いる。例えば、ｗｅｂサーチとデスクトップサーチは、文書やデータベースレコードのような個々のエンティティにアクセスする手段を提供する。しかしこれらの検索手法は、関連するログメッセージのグループを取得することができないので、ログ管理における価値は限定的である。
【発明の概要】
【課題を解決するための手段】
【０００４】
ログデータ内の関連するイベントのシーケンスを取得するため、リクエスト式をパースし、検索されるイベント間の依存性と、イベントを特徴付ける制約条件（例えば、キーワード）とを取得する。パースの結果に基づいて、個々のイベントの制約条件とイベント間の相互関係（例えば期間）を表すクエリ要素が形成される。結果として生成される、クエリ要素を備えたスパンクエリは、検索可能なデータ構造（例えば、ログファイルストレージ）内の関連するイベントの相互位置をコード化したイベントのインデックスに対して実行される。
【０００５】
本開示の実装は、ログイベントに対するより速いアクセスを提供し、関連するメッセージを取得するよりよい手段を提供し、検索プロセスをよりインタラクティブにすることによってログデータの解析を自動化することができる。メッセージ（イベント）間の関係は、後に明らかになるように、サーバなどのエンティティに属し、ユーザなどのエージェントによって実行され、イベント間の推測原因関係となる。
【０００６】
その他、マルチメッセージ検索のイベント取得シナリオも開示される。例えば、「Ｗｈｉｃｈ」シナリオは、途中に生じる全ての中間クエリ件名を検索することを含む。この中間クエリ件名の後には、最終クエリ件名が続き、最終クエリ件名はユーザクエリ内で指定された語句の関連によって中間クエリ件名に関連付けられる。
【図面の簡単な説明】
【０００７】
【図１】ログ管理システムの例を示すブロック図である。
【図２】ログデータ内の関連するイベントに対するクエリを形成する方法例の概略図である。
【図３】ログデータ内の関連するイベントに対するクエリを実行する方法例の概念図である。
【図４】イベントクエリのシーケンス、複数制約クエリ、および因果関係クエリ内の要素例のブロック図である。
【図５】イベントクエリのシーケンスを用いてログデータ内の関連するイベントを検索するプロセス例のフローチャートである。
【図６】複数制約クエリを用いてログデータ内の関連するイベントを検索するプロセス例のフローチャートである。
【図７】因果関係クエリを用いてログデータ内の関連するイベントを検索するプロセス例のフローチャートである。
【図８】図５〜図７に記載されているプロセスに関連して用いることのできるコンピュータシステム例の概略図である。
【発明を実施するための形態】
【０００８】
＜ログ管理システムの概要＞
図１は、ログ管理システム１００の例を示すブロック図である。ある実装例において、ログ管理システム１００は、１以上のコレクタ１０２ａ〜１０２ｎ、プリパーサ１０４、永続記憶装置１０６、パーサ／マッパ１０８、データベース１１０、レポータ１１２、およびタグシステム１１４を備える。タグシステム１１４は、タグインデクサ１１６、タグレポータ１１８を備える。このような実装により、１以上のユーザは、レポータ１１２とタグレポータ１１８を用いて、コレクタ１０２ａ〜１０２ｎが収集したデータについての新しいレポートとカスタマイズされたレポートを生成することができる。このようなレポートについてのイベントデータ（例えばログメッセージ）は、ログ管理システム１００の残りの構成要素によって収集され、処理される。以後、「タグ」および「属性」という用語は、同義に用いられる。タグ／属性は、オブジェクトまたは要素の性質または特徴を定義するエンティティである。タグ／属性は通常、ただし常時ではないが、名称と値を有する。
【０００９】
ある実装例において、コレクタ１０２ａ〜１０２ｎは、動作上プリパーサ１０４に連結している。ある実装例において、ログ管理システム１００の様々な構成要素は、同一のハードウェアプラットフォーム上に配置されていてもよいし、１以上のネットワーク（例えばイーサネット、インターネット、イントラネット）によって接続された複数のハードウェアプラットフォーム上に配置されていてもよい。コレクタ１０２ａ〜１０２ｎはそれぞれ、１以上の他のコンピュータデバイスまたはアプリケーションからイベントデータを収集する任意のデバイスとすることができる。このような情報収集は、能動的なものでも受動的なものでもよく、エラーメッセージ、ユーザトランザクション、システムイベント、アプリケーションマイルストーン、データアクセス試行、などの情報を含んでいてもよい。例えばコレクタ１０２ａは、ＬｏｇＬｏｇｉｃ  ＬＸ  ５００のアプライアンス（カリフォルニア州サンホセのログロジック株式会社が製造している）であってもよい。このアプライアンスは、例えばメッセージ、エラー、トランザクションのような情報が１以上のデータサーバ上で発生すると、これらを受動的に収集し、解析するように構成することができる。同じサーバから能動的に収集される他のイベント情報には、可用性ステータス、現在のストレージ容量、リソース使用状況、などを含めることができる。他の例において、コレクタ１０２ｂは、ＬｏｇＬｏｇｉｃ  ＬＸ  ２０００のアプライアンスであってもよい。このアプライアンスは、例えばメッセージ／添付ファイル統計、失敗したログイン試行、パスワード変更などの、電子メールシステムからの情報を、能動的および受動的に収集し解析するように構成することができる。
【００１０】
コレクタ１０２ａ〜１０２ｎが収集した情報は、プリパーサ１０４に送信される。このような情報は、連続ログインイベントが発生したときに生成される「フラットファイル」を介して、またはフラットファイルの断片を表す周期的メッセージとして、送信することができる。ある実装例において、ログデータの送信は、データをバイトストリームとして送信するため、例えば伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ：ＴＣＰ）のような１以上の標準ネットワークプロトコルの後に続くことができる。コレクタはまた、各ログメッセージに、メッセージのコンテキスト（例えば、コレクタがログメッセージを受信した時刻、メッセージの送信元デバイス）を記述した情報を追加することができる。
【００１１】
プリパーサ１０４は、未加工のログ情報を、コレクタが生成したコンテキストヘッダとともに、１以上のコレクタ１０２ａ〜１０２ｎから受け取る。処理中、プリパーサ１０４は、ログソースのタイプとバージョンを、各ログソースについてあらかじめ定められた署名（例えば、Ｃｉｓｃｏ（登録商標）  Ｆｉｒｅｗａｌｌ  バージョン７、Ｏｒａｃｌｅ（登録商標）  データベース  バージョン１０）を用いて判定する。プリパーサ１０４は、この情報を、ログ管理システム１００が後に使用するため、永続記憶装置１０６に未変更ログ情報とともに格納する。
【００１２】
ログ管理システム１００は、プリパーサ１０４から受け取ったログ情報を格納するため、永続記憶装置１０６を用いる。ある実装例において、記憶方法として、個々のログメッセージを含む１以上の「フラットファイル」を採用することができる。例えば、電子メールシステムからのログメッセージを含むフラットファイルの「行」は、ユーザ名（例えば「Ｍａｔｔ」）、ＩＰアドレス、場所、失敗したログイン試行のような発生イベント、を含むようにすることができる。このようなエントリには、エントリが生成された時刻（例えば、分レベルまたは１秒の数分の１レベルの時刻）を識別するタイムスタンプを含めることができる。ある実装例において、ログ管理システム１００は、ユーザが指定した期間、永続記憶装置１０６内にログを保持するように構成することができる。例えば、医療保険の相互運用性と責任に関する法律（ＨＩＰＡＡ）の規制に関連するイベントデータを有するログファイルを、数年間にわたって保持することができる。
【００１３】
パーサ／マッパ１０８は、永続記憶装置１０６内に保持されているログ情報を用いて、データの内容を表すタグ、またはインデックスを生成する。そのプロセスには、関連するイベントデータを検索する間に、永続記憶装置１０６内に格納されたログ情報の行をパースする動作が含まれる。このようなパース処理は、あらかじめ定められたパース規則とキーワードインデックスを用いることができる。例えば、電子メールアプリケーションからログファイルをパースする処理は、ログ管理システム１００が「ＵＳＥＲ＿ＩＤ」と括弧に囲まれたユーザ名を有するユーザ関連イベントデータを検索するよう定めたルールをパースする処理を用いることができる。パースに加え、パーサ／マッパ１０８は、対応するログファイルに配置された情報とログファイル内の関連するイベントデータをマップする。このようにして、例えば「ＵＳＥＲ＿ＩＤ：［ＭＡＴＴ］」のようなログファイルのイベントデータをマップすることができる。他例において、パース規則とキーワードは、例えば「ＣＥＲＥＳ  ＥＮＤ  ＯＦ  ＤＡＹ」のような日々のアプリケーションマイルストーンが、タイムスタンプとともにシステムログから抽出されるようにすることができる。このような情報は、定常イベントの発生、例えば「ＥＮＤ  ＯＦ  ＤＡＹ」イベントを、「ＣＥＲＥＳ」という名前のアプリケーションと比較する（そしてレポートする）ために用いることができる。
【００１４】
ある実装例において、パーサ／マッパ１０８が実行する動作は、ログファイルエントリが永続記憶装置１０６内で入手できるようになるのにともなって、ほぼリアルタイムで発生する。他の実装例において、パーサ／マッパ１０８は、あらかじめ定められた間隔または閾値、例えば経過時間やログファイルサイズに基づく間隔または閾値で、処理を実行するようにスケジュールすることができる。
【００１５】
ログ管理システム１００は、１以上のデータベース内に、マップされたログ情報のインデックスを格納することができる。例えば、ログ管理システム１００は、データベース１１０を用いて、永続記憶装置１０６内のマップされたログ情報を表す逆インデックスを蓄積することができる。ある実装例において、データベース１１０内のエントリは、パーサ／マッパ１０８が生成することができる。レポータ１１２を用いるユーザは、データベース１１０にアクセスし、正規表現を用いて標準テキスト検索を実行するのに役立つことができる。
【００１６】
属性／値を生成する実装例として、正規表現規則を用いるものが考えられる。まず、プリパーサ規則を構成する正規表現規則のセットは、異なるメッセージタイプの「署名」を検出する。署名によってログメッセージタイプが識別されると、パーサ規則を構成するメッセージタイプ固有のルールセットが適用され、各メッセージから異なる属性／値が抽出される。属性／値を最初に抽出した後、メッセージに追加属性を追加する追加規則があってもよい。これら後者の規則セットは、原則として最初の属性／値のセットの空間（正規表現規則によって生成される）を領域分割し、個々の領域に新たな属性／値をラベル付けする。これら後者の規則セットを、マッピングまたは分類規則と呼ぶ。
【００１７】
上述のプロセスの例を以下に述べる。まず、メッセージの署名によって、「タイプＡ」ログとして識別する。次に、「タイプＡ」ログの規則が適用される。このステップでは、例えば「ｕｓｅｒ＝ｕｕｕ，ｄｅｖｉｃｅ＝ｄｄｄ，ａｃｔｉｏｎ＝ａａａ，ｒｅｓｕｌｔ＝ｒｒｒ」のような属性を生成することができる。ユーザがセット｛ａ，ｂ，ｃ｝の中にあり、アクションがセット｛ａ１，ａ２，ａ３｝の中にあれば、「ｃｒｉｔｉｃａｌｉｔｙ＝ｃｃｃ」となる。蓄積されるメッセージの全体的な属性／値のセットは、上記ステップ１、２、３の結合である。すなわち、メッセージは以下の属性／値ペアのセットに変換される。（メッセージ種別＝ｔｙｐｅＡ，ｕｓｅｒ＝ｕｕｕ，ｄｅｖｉｃｅ＝ｄｄｄ，ａｃｔｉｏｎ＝ａａａ，ｒｅｓｕｌｔ＝ｒｒｒ，ｃｒｉｔｉｃａｌｉｔｙ＝ｃｃｃ）
【００１８】
レポータ１１２を用いてレポートを生成するプロセスは、レポータ１１２から発信するクエリがデータベース１１０に送信されたときに開始することができる。例えば、クエリの目的が「ＭＡＴＴ」という名前のユーザに関連する電子メールイベントデータを検索することであったとする。クエリを受け取ると、データベース１１０は対応するインデックスをレポータ１１２に送信する。これらインデックスを用いて、レポータ１１２は永続記憶装置１０６へ対応するイベントデータを要求する。レポータ１１２は、対応するイベントデータを受け取り、処理を終了する。ある実装例において、データベース１１０とレポータ１１２は、オープンソースデータベースまたは検索技術、例えばＭｙＳＱＬ（登録商標）またはＬｕｃｅｎｅ（登録商標）を用いて実装することができる。このような技術を用いることによって、例えば「“ログイン試行失敗（ｆａｉｌｅｄ  ｌｏｇｉｎ  ａｔｔｅｍｐｔ）”というフレーズを有する全てのイベントデータエントリを見つけよ」のような、トークンベースの検索を促進することができる。このような検索は、ブール関数、ワイルドカード文字、その他特別なクエリツールを利用することができる。しかし、データベース１１０とレポータ１１２のみを用いて利用可能となる規定のスキーマと構造化されたレポートは、ログ管理システム１００上で実行されるクエリの複雑度と範囲を制限する可能性がある。特に、ユーザは未加工のログメッセージを、より洗練されたクエリ、特にログファイル内の関連するイベントデータの属性間の関係に基づいたクエリを用いて、検索したいかもしれない。このようなレポート能力は、以下に説明するタグシステム１１４によって提供される。
【００１９】
＜タグシステムの概要＞
タグシステム１１４は、タグインデクサ１１６とタグレポータ１１８を備える。タグインデクサ１１６は、パーサ／マッパ１０８が処理する永続記憶装置１０６内の未加工ログデータに基づいて、パーサ／マッパ１０８からタグまたはインデックスを受け取る。タグインデクサ１１６は、ログファイル内の情報の特定のインスタンスを、未ソートの属性／値ペアとして表す。ある実装例において、タグインデクサ１１６はこれら属性／値ペアを、その属性／値に対応する未加工ログメッセージへのポインタのリストを用いて、逆ログインデックスとして蓄積する。例えば、ある属性／値ペアが、ユーザ名（例えば、ｕｓｅｒ＝Ｍａｔｔ）または特定のサーバ（例えば、ｓｅｒｖｅｒ＝ｅｍａｉｌ）に対するアクション結果（例えば、ａｃｔｉｏｎ＝ｆａｉｌｅｄ  ｌｏｇｉｎ）を表すものとする。タグインデクサ１１６は、各期間における各属性／値ペアの数を保持する（例えば、ｕｓｅｒ＝Ｍａｔｔ：１０，１２，２４は、ｕｓｅｒ＝Ｍａｔｔが３つの連続する時間において、１０回、１２回、および２４回発生したことを意味する）。またタグインデクサ１１６は、同時に発生する属性／値ペアのセットの数を保持する。例えば、ｕｓｅｒ＝Ｍａｔｔ，ａｃｔｉｏｎ＝ｆａｉｌｅｄ  ｌｏｇｉｎ，ｓｅｒｖｅｒ＝ｅｍａｉｌという組があるものとする。この組は、Ｍａｔｔというユーザが異なる時間にｅｍａｉｌサーバに対してログインを試行して失敗した回数を表す。ユーザがログインを試みて失敗した回数を表すことに加えて、タグインデクサ１１６は、ログファイル内の対応する未加工エントリへのポインタ（以下に詳述する）を保持することができる。タグインデクサ１１６内に保持されている情報を用いて、タグレポータ１１８は属性と値に関連するレポートを生成することができる。タグレポータ１１８は、下記に詳述するように、２以上の関連する属性／値ペア間の関係を利用することができるので、このようなレポートは、レポータ１１２が提供する標準的なトークンベースのレポートよりも、洗練されている。
【００２０】
例えば、レポータ１１２は電子メールシステムイベントの標準的なリストを生成するために用いることができる一方で、レポータ１１８は昨日中の電子メールメッセージの数を描画してそれらをＳＰＡＭにグループ分けするために用いることができる。他例において、タグレポータ１１８は、上位ｎの送信者によってグループ分けされた機密性の高い電子メールメッセージのレポートを生成するために用いることができる。
【００２１】
ある実装例において、ログ管理システム１００のユーザインタフェース（図示せず）は、レポータ１１２用とタグレポータ１１８用の個別のタブを備えていてもよい。ユーザは、その時点のユーザのレポート要求に対応する個々のタブの下で、機能を選択する。例えば、タグレポータ１１８タブ配下の画面部品によって、ユーザは関係を共有する属性ペア（以下に説明する）のような情報を閲覧することができ、またそのような関係を利用したレポートを生成することができる。タグレポータ１１８配下の他の画面部品によって、タグインデクサ１１６内のイベントデータを用いたレポートを形成し、開始することを促進することができる。
【００２２】
＜クエリ形成および処理の概要＞
図２は、ログデータ内の関連するイベントに対するクエリを形成する方法例２００の概略図である。方法２００は、入力としてクエリ文字列２０２を受け取る。クエリ文字列２０２は、例えばキーワードのシーケンスのような検索語句を含む。クエリ文字列２０２は、英語または他言語の自然言語クエリを形成する。クエリ文字列２０２は、検索語句を満たすソートされたイベントセット（例えばログメッセージ）またはイベントの集合として、検索結果を生成する。以後、「イベント」「メッセージ」という用語は同義に用いられ、「語句」「キーワード」という用語はメッセージの内容を記述するために用いられる。
【００２３】
ある実装例では、ログデータ内のイベントをインデックス付けしてもよい。イベントのインデックスは、検索用に最適化されたイベントを格納するシステムであり、また例えば、全てのログメッセージについてログメッセージ内の全ての語句を格納する逆インデックスであってもよい。取得を効率的にするため、ログメッセージは、例えば特定の時間が経過した後（例えば毎時）またはインデックスが特定サイズに達した後に、複数のインデックスシステムに分割してもよい。インデックス内のログメッセージの出現は、整数のペアで識別することができる。ペアの１番目はインデックス文書ＩＤであり、ペアの２番目はインデックス文書内のメッセージＩＤである。ある実装例において、インデックス内の個々のログメッセージは、開始語句と終了語句を含む語句シーケンス（例えばキーワード）として各ログメッセージを表すことにより、検索可能となる。インデックスクエリには、開始語句と終了語句の中に埋め込まれた入力検索クエリ２０２からの語句を含めることができる。
【００２４】
他の入力には、イベントが発生するデバイス２０４のリストと、検索結果のソート順２０６を含めることができる。入力は、例えばユーザによって提供され、または記憶装置から取得することができる。
【００２５】
方法２００は、ステップ２０８でクエリ文字列２０２をパースし、変換する。パースおよび変換ステップ２０８は、クエリ文字列２０２を事前整形するステップを含むことができる。例えば、クエリ文字列２０２は、小文字に変更され、複数の文言に分割される。クエリ文字列２０２をパースして、節、反転語、属性、値を識別することができる。パースおよび変換ステップ２０８はさらに、例えばワイルドカードや語幹のような特殊な存在を処理するステップを含むことができる。クエリ文字列２０２は、正規形で書き直すことができる。クエリを構文解析し、検索結果に影響しない節を識別して除去することができる。クエリ内のワイルドカードは、選言肢（例えば、論理“ｏｒ”句）に拡張することができる。例えば「ｐｌａｙ＊」のような語幹ワイルドカードの場合は、選言肢は「ｐｌａｙまたはｐｌａｙｅｒまたはｐｌａｙｉｎｇまたはｐｌａｙｅｄ」を含む。
【００２６】
方法２００は、ステップ２１０でスパンクエリを構築する。ブール演算子、フレーズ、語句を組み合わせて、スパンクエリを形成することができる。方法２００は、ステップ２１２でネストされたクエリを処理する。例えば、クエリは１以上の節が他の節に従属する複数節を含むことができる。方法２００は、ステップ２１４でスパンクエリをグループ分けする。スパンクエリは、要求値、禁止値、選言値によってグループ分けすることができる。方法２００は、ステップ２１６でクエリにデバイスについての節を追加することができる。
【００２７】
方法２００は、出力として、クエリ２１８、２２０、２２２を、クエリ文字列２０２に基づいて生成する。方法２００は、ポジティブおよびネガティブクエリ節についてスパンクエリ２１８のペアを出力することができる。方法２００は、ＳｐａｎＮｏｔ（例えば、包含する属性値を有する１以上の語句と、除外する属性値を有する１以上の語句とを有するクエリ）を含むスパンクエリ２２０を出力することができる。方法２００は、例えばクエリ文字列２０２をパースした結果のような、未加工ブールクエリ２２２を出力することができる。
【００２８】
図３は、ログデータ内の関連するイベントに対するクエリを実行する方法例３００の概略図である。ある実装例において、方法３００は、検索結果の数を推定するステップ３０２およびブールクエリ３０４を実行するステップから開始する。方法３００は、スパンクエリの結果を受け取るＨｉｔｓＣｏｌｌｅｃｔｏｒをステップ３０６で構築する。方法３００は、ステップ３０８でスパンクエリを実行する。ブールクエリとスパンクエリからの結果があり、かつ一致する結果がある場合は、方法３００はステップ３１０でＳｐａｎＮｏｔクエリを実行する。あるいはブールクエリとスパンクエリ双方からの結果があり、かつ一致する結果がなく、かつ否定要素が存在する場合は、方法３００は否定要素についてステップ３１２でスパンクエリを実行する。方法３００は、ステップ３１４ａ〜ｃで、否定要素についてのスパンクエリ、およびＳｐａｎＮｏｔクエリの結果からファイル名とファイル位置のペアを取得する。否定要素についてのスパンクエリまたはＳｐａｎＮｏｔクエリの結果がある場合は、方法３００はファイル名とファイル位置の否定ペアをステップ３１４ｃで引き去る。方法３００はステップ３１６で残りのファイル名とファイル位置のペアと関連するログメッセージを取得する。方法３００は、ステップ３１８ａ〜ｃで、例えばログメッセージ、ログメッセージの数、検索結果の状態に関するユーザフィードバックを出力する。
【００２９】
＜クエリテンプレートの概要＞
図４は、イベントクエリ４０２および４０４、複数制約クエリ４０６、因果関係クエリ４０８のシーケンス内の要素例を示すブロック図である。イベントクエリ４０２および４０４は、「ユーザ  ｊｏｈｎ１２３」４０２ａおよび４０４ａのような各イベントの制約、「後に」４０２ｂ、「その後」４０４ｂおよび４０４ｄのような時間的関係、その後に続く後続のイベントについての「アクセス拒否」４０２ｃおよび４０４ｃのような制約を含む。２つのイベントについてのクエリ４０２は、ユーザによって例えば「ユーザ“ｊｏｈｎ１２３”は、“５．６．７．８”に対してアクセス拒否された後に“１．２．３．４”に対してログイン成功したか」（Ｄｉｄ  ｕｓｅｒ“ｊｏｈｎ１２３”  ｓｕｃｃｅｓｓｆｕｌｌｙ  ｌｏｇｇｅｄ  ｉｎ  ｔｏ  “１．２．３．４”  ａｆｔｅｒ  ｈｅ  ｗａｓ  ｄｅｎｉｅｄ  ａｃｃｅｓｓ  ｔｏ  “５．６．７．８”）のように入力される。「ユーザ  ｊｏｈｎ１２３」「ログイン」「１．２．３．４」「拒否」「アクセス」「５．６．７．８」のようなキーワードが識別される。冠詞、代名詞、その他特定の一般語句のようなストップワードは、クエリから除去される。テンプレートは、各イベントの制約についての要素とそれらの間の時間的関係についての要素を含む。
【００３０】
ある実装例において、イベントシーケンス内の２以上のイベントが検索され得る。例えば、ユーザが入力したクエリ４０４が、「ユーザ“ｊｏｈｎ１２３”は４０秒以内に、“１．２．３．４”にログイン成功し、その後“５．６．７．８”へのアクセスを拒否され、その後“１５．１６．１７．１８”にアクセスを試みたか」（Ｄｉｄ  ｕｓｅｒ“ｊｏｈｎ１２３”  ｓｕｃｃｅｓｓｆｕｌｌｙ  ｌｏｇｇｅｄ  ｉｎ  ｔｏ  “１．２．３．４”  ｔｈｅｎ  ｈｅ  ｗａｓ  ｄｅｎｉｅｄ  ａｃｃｅｓｓ  ｔｏ  “５．６．７．８”  ｔｈｅｎ  ｈｅ  ａｔｔｅｍｐｔｅｄ  ｌｏｇｉｎ  ｔｏ  “１５．１６．１７．１８”  ｗｉｔｈｉｎ  ４０  ｓｅｃｏｎｄｓ）のようになっている場合、クエリ４０４は、時間的関係４０４ｂおよび４０４ｄについての要素と置き換えられる、個々のイベント４０４ａおよび４０４ｃの制約についての要素、および全体時間要素４０４ｆを含む。
【００３１】
システムは、２ステップの検索を用いて、クエリ４０６のような複数制約クエリを処理する。クエリ４０６は、検索キーワードが明確に示されている（例えば、「ログイン」および「１．２．３．４」）中間要素４０６ｃ、最初に指定されたキーワード（例えば、「デバイス」、「アクセス」、「ユーザ」）を含む最終要素４０６ａ、中間クエリ４０６ｃの実行結果として得られる語句を含む。また、「どの（ｗｈｉｃｈ）」または「誰（ｗｈｏ）」キーワードのような予約語を含むセパレータ要素４０６ｂが存在する。
【００３２】
システムは、検索イベントの原因である、ログメッセージ内の一般キーワードを識別する複数ステップ検索を用いる、クエリ４０８のような因果関係クエリを処理する。クエリ４０８は、考慮中のイベントセットを減じる固定要素４０８ａを含む。クエリ４０８は、先行するイベントとの相互関係が検索されるキーワードを指定する可変要素４０８ｃを含む。クエリ４０８は、「なぜ」キーワードのような予約語を含むセパレータ要素４０８ｂを含む。
【００３３】
＜ある期間内のイベントシーケンスを検索するステップの概要＞
図５は、イベントクエリのシーケンスを用いてログデータ内の関連するイベントを検索するプロセス５００の例を示すフローチャートである。プロセス５００は、個々のイベントに対するクエリを形成するステップ５０２から開始する。例えば、ログ管理システム１００は、クエリ要素４０２ａおよび４０２ｃ、クエリ要素４０４ａ、４０４ｃ、および４０４ｅを形成する。
【００３４】
プロセス５００は、個々のイベントに対するクエリに基づくイベントシーケンスに対するクエリを、ステップ５０４で形成する。個々のクエリは、イベントシーケンス内の最初のイベント（例えば４０２ｃ）と最後のイベント（例えば４０２ａ）の間の時間を暗黙に含む。これに代えてまたはこれに加えて、イベントクエリのシーケンスは、例えば４０４ｆのような明示的な時間制約を含むこともできる。
【００３５】
プロセス５００は、イベントシーケンスに対するクエリをステップ５０６で実行する。複数のインデックスファイル内に結果が存在する場合は（ステップ５０８）、プロセス５００はイベントシーケンス内の結果をフィルタリングして（ステップ５１０）時間制約を維持する。例えば、ログ管理システム１００はインデックスファイル間の時間を計算し、全体的な時間制約を維持する。プロセス５００は、ある時間内の関連するイベントシーケンスとして、結果セットを形成する（ステップ５１２）。
【００３６】
＜複数制約クエリを実行するステップの概要＞
図６は、複数制約クエリを用いてログデータ内の関連するイベントを検索するプロセス例６００を示すフローチャートである。プロセス６００は、クエリをパースして１以上の中間要素と最終要素を識別するステップ（６０２）から開始する。例えば、ログ管理システム１００は、「どのデバイスが、“１．２．３．４”にログイン成功したユーザによってアクセスされたか」（Ｗｈｉｃｈ  ｄｅｖｉｃｅｓ  ｗｅｒｅ  ａｃｃｅｓｓｅｄ  ｂｙ  ｕｓｅｒｓ  ｗｈｏ  ｓｕｃｃｅｓｓｆｕｌｌｙ  ｌｏｇｇｅｄ  ｉｎｔｏ  “１．２．３．４”）というクエリ文字列を受け取る。ログ管理システム１００は、クエリをパースして、例えば「どの（ｗｈｉｃｈ）」「誰（ｗｈｏ）」のような予約語の位置を特定する。ログ管理システム１００は、予約語４０６ｂに先行する節を最終要素４０６ａとして識別し、予約語４０６ｂの後の節を中間要素４０６ｃとして識別する。
【００３７】
プロセス６００は、識別した中間要素についてのクエリを形成する（ステップ６０４）。例えば、ログ管理システム１００は、「ＳＥＬＥＣＴ  ｕｓｅｒ  ｆｒｏｍ  ｔｈｉｓ  ｔａｂｌｅ  ＷＨＥＲＥ  ｄｅｖｉｃｅ＝“１．２．３．４”」のようなクエリを形成することができる。
【００３８】
プロセス６００は、中間要素についてのクエリを実行し（ステップ６０６）、最終要素についてのクエリに含まれるべきキーワードを識別する。例えば、ログ管理システム１００は、中間要素についてのクエリを実行し、デバイス「１．２．３．４」に関連するユーザを判定する。
【００３９】
プロセス６００は、中間要素についてのクエリの結果を用いて、最終要素についてのクエリを形成する（ステップ６０８）。例えば、ログ管理システム１００は、「ＳＥＬＥＣＴ  ｄｅｖｉｃｅ  ｆｒｏｍ  ｔｈｉｓ  ｔａｂｌｅ  ＷＨＥＲＥ  ｕｓｅｒ＝［中間クエリの結果］」のようなクエリを形成することができる。
【００４０】
プロセス６００は、最終要素についてのクエリを実行する（ステップ６１０）。例えば、ログ管理システム１００は、「ＳＥＬＥＣＴ  ｄｅｖｉｃｅ  ｆｒｏｍ  ｔｈｉｓ  ｔａｂｌｅ  ＷＨＥＲＥ  ｕｓｅｒ＝」クエリを、中間クエリから判定された各結果について実行する。
【００４１】
プロセス６００は、中間クエリと最終クエリの結果を統合する（ステップ６１２）。例えば、ログ管理システム１００は、個々のイベントに関連する最終クエリからのイベントセットとともに中間クエリからの個々のイベントを提示する、ユーザインタフェースビューを構築することができる。中間クエリからの値「ｕｓｅｒ」は、最終クエリについてのＳｐａｎＯｒ要素を形成する。
【００４２】
各クエリ部は、追加制約を有することもできる。例えば、ログ管理システム１００が、「どのデバイス“ｄｓｔ：２５５．＊；ｓｅｒｖｉｃｅｓ：６７；ｓ＿ｐｏｒｔ：６８；ｒｕｌｅ：０”が、“１．２．３．４”の製品“ｐｒｏｄｕｃｔ：ＶＰＮ−１＆ＦｉｒｅＷａｌｌ−１”にログイン成功したユーザによってアクセスされたか」（Ｗｈｉｃｈ  ｄｅｖｉｃｅｓ  “ｄｓｔ：２５５．＊；ｓｅｒｖｉｃｅｓ：６７；ｓ＿ｐｏｒｔ：６８；ｒｕｌｅ：０”  ｗｅｒｅ  ａｃｃｅｓｓｅｄ  ｂｙ  ｕｓｅｒｓ  ｗｈｏ  ｓｕｃｃｅｓｓｆｕｌｌｙ  ｌｏｇｇｅｄ  ｉｎ  ｔｏ  “１．２．３．４”  ｐｒｏｄｕｃｔ  “ｐｒｏｄｕｃｔ：ＶＰＮ−１＆ＦｉｒｅＷａｌｌ−１”）のようなクエリ文字列を受け取ったものとする。ログ管理システム１００は、中間クエリ「ＳＥＬＥＣＴ  ｕｓｅｒ  ｆｒｏｍ  ｔｈｉｓ  ｔａｂｌｅ  ＷＨＥＲＥ  ｄｅｖｉｃｅ＝“１．２．３．４”  ＡＮＤ  ｐｒｏｄｕｃｔ＝“ＶＰＮ−１＆ＦｉｒｅＷａｌｌ−１”」を形成し、実行する。ログ管理システム１００は、最終クエリ「ＳＥＬＥＣＴ  ｄｅｖｉｃｅ  ｆｒｏｍ  ｔｈｉｓ  ｔａｂｌｅ  ＷＨＥＲＥ  ｄｅｖｉｃｅ＝“ｄｓｔ：２５５．＊；ｓｅｒｖｉｃｅｓ：６７；ｓ＿ｐｏｒｔ：６８；ｒｕｌｅ：０”  ＡＮＤ  ｕｓｅｒ＝［中間クエリの結果］」を形成し、実行する。
【００４３】
＜因果関係クエリを実行するステップの概要＞
図７は、因果関係クエリを用いてログデータ内の関連するイベントを検索するプロセス例７００を示すフローチャートである。プロセス７００は、クエリをパースし、固定要素および可変要素を識別する（ステップ７０２）。例えば、ログ管理システム１００は、「なぜ（ｗｈｙ）」のような予約語の位置を特定し、予約語に先行する固定要素４０８ａと予約語の後に続く可変要素４０８ｃを識別する。これに代えて、他の予約語、例えば「いつ（ｗｈｅｎ）」も、固定要素および可変要素の位置を特定する他規則と同様に用いることができる。
【００４４】
プロセス７００は、固定要素と可変要素を統合することによって、クエリを形成する（ステップ７０４）。例えば、ログ管理システム１００は、「ＳＥＬＥＣＴ  ＊  ｆｒｏｍ  ｔｈｉｓ  ｔａｂｌｅ  ｗｈｅｒｅ  ｕｓｅｒ＝“ｊｏｈｎ２３４”  ａｎｄ  ｄｅｖｉｃｅ＝“１．２．３．４”」のようなクエリを形成する。
【００４５】
プロセス７００は、統合されたクエリを実行し、明らかにすべきイベントを識別する（ステップ７０６）。少なくとも１つの統合されたイベントについて、プロセス７００は、特定の期間内の識別された統合イベントに先行するイベントを取得する（ステップ７０８）。例えばログ管理システム１００は、「ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  ｔｈｉｓ  ｔａｂｌｅ  ＷＨＥＲＥ  ｔｉｍｅ＝［統合クエリの時間についての結果］−１０ｍｉｎｕｔｅｓ」のような、統合クエリからの各結果についてのクエリを実行することができる。時間は、ユーザから受け取り、または記憶装置から取得される。
【００４６】
プロセス７００は、固定要素に基づくクエリを実行する（ステップ７１０）。例えば、ログ管理システム１００は、「ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  ｔｈｉｓ  ｔａｂｌｅ  ｗｈｅｒｅ  ｄｅｖｉｃｅ＝“１．２．３．４”」のような固定クエリを実行することができる。少なくとも１つの識別された固定イベントについて、プロセス７００は、特定の期間内の識別された固定イベントに先行するイベントを取得する（ステップ７１２）。
【００４７】
プロセス７００は、識別された統合イベントについて、束を構築する（ステップ７１４）。プロセス７００は、識別された固定イベントについて束を構築する（ステップ７１６）。束は、２以上のイベントセット間のイベント共通部分のセットである。共通部分について順序を定義することができる。プロセス７００は、セット減算を実行し、統合イベント共通部分束と固定イベント共通部分束の間の差異を判定する（ステップ７１８）。プロセス７００は、差異のリストを、ユーザが提起した因果関係問い合わせに対する見込み回答として、ユーザに出力する。
【００４８】
例えば、デバイス「１．２．３．４」にアクセスしたユーザについてのクエリが、ユーザ「ｊｏｈｎ２３４」とともに他の７ユーザ（ユーザ１、ユーザ２、ユーザ３、ユーザ４、ユーザ５、ユーザ６、ユーザ７）を含むものとする。ユーザ１、２、３、４は、デバイス「１．２．３．４」へのアクセスを許可されたイベントシーケンスを有する。ユーザ５、６、７、「ｊｏｈｎ２３４」は、アクセスが拒否されたイベントシーケンスを有する。イベントは、中断イベント、交換イベント、接続イベント、リセットイベント、開始イベントを含み、以後それぞれ「ｉ」「ｅ」「ｃ」「ｒ」「ｓ」として表される。各ユーザのイベントは、下記テーブルに示される。
【表１】
2010541102.tif 000003
【００４９】
デバイス「１．２．３．４」へのアクセスを許可されたユーザのイベントセットの共通部分は、「ｉｅｃ」「ｉ」「ｉｅ」「ｉｅｓ」を含む。デバイス「１．２．３．４」へのアクセスを拒否されたユーザのイベントセットの共通部分は、「ｉｃｒ」「ｃｒ」を含む。この例において、アクセス許可についての共通部分とアクセス拒否についての共通部分の間には、共通するイベントセットはない。１以上のイベントセットが共通部分の結果間で共通する場合は、その共通するイベントセットは除去される。アクセス拒否についての共通部分の残りのイベントセットは、ユーザ「ｊｏｈｎ２３４」についてのイベントと比較され、イベント「ｃｒ」は、ユーザ「ｊｏｈｎ２３４」がデバイス「１．２．３．４」に対するアクセスを拒否された原因である可能性があると判定される。
【００５０】
ある実装例において、上記例は、イベントセットの結果を予測するために用いることができる。例えば、ユーザ「ｊｏｈｎ２３４」がデバイス「１．２．３．４」へのアクセスを拒否されたか否かをイベントセット「ｃｒｓ」に基づき判定するため、イベントセット「ｃｒｓ」を、アクセス許可についての共通部分およびアクセス拒否についての共通部分の残りのイベントセットと比較することができる。イベントセット「ｃｒｓ」がアクセス許可についての共通部分のイベントセットを含む場合は、イベント「ｃｒｓ」の結果としてアクセス許可があり得ることになる。あるいは、イベントセット「ｃｒｓ」がアクセス拒否についての共通部分のイベントセットを含む場合は、イベント「ｃｒｓ」の結果としてアクセス拒否があり得ることになる。
【００５１】
図８は、一般的なコンピュータシステム８００の概略図である。コンピュータシステム８００は、いずれか１の実装に基づく先述のコンピュータで実装した方法に関して記述した動作のために用いることができる。コンピュータシステム８００は、プロセッサ８１０、メモリ８２０、記憶装置８３０、入出力装置８４０を備える。各要素８１０、８２０、８３０、８４０は、システムバス８５０を用いて相互接続されている。プロセッサ８１０は、コンピュータシステム８００内で実行する命令を処理することができる。ある実装例では、プロセッサ８１０はシングルスレッドプロセッサである。別の実装例では、プロセッサ８１０はマルチスレッドプロセッサである。プロセッサ８１０は、メモリ８２０または記憶装置８３０内に格納されている命令を実行し、入出力装置８４０上にユーザインタフェースの画像情報を表示することができる。
【００５２】
メモリ８２０は、コンピュータシステム８００内に情報を格納する。ある実装では、メモリ８２０はコンピュータ読取可能な媒体である。ある実装例では、メモリ８２０は揮発性メモリユニットである。別の実装例では、メモリ８２０は不揮発性メモリユニットである。
【００５３】
記憶装置８３０は、コンピュータシステム８００のための大容量記憶を提供することができる。ある実装例では、記憶装置８３０はコンピュータ読取可能な媒体である。他の異なる種々の実装例では、記憶装置８３０はフロッピーディスク、ハードディスク装置、光ディスク装置、またはテープ装置であってもよい。
【００５４】
入出力装置８４０は、コンピュータシステム８００の入出力動作を提供する。ある実装例では、入出力装置８４０はキーボードおよび／またはポインタデバイスを含む。他の実装例では、入出力装置８４０はグラフィカルユーザインタフェースを表示するためのディスプレイユニットを含む。
【００５５】
上述の特徴は、デジタル電子回路、またはコンピュータハードウェア、ファームウェア、ソフトウェア、またはこれらの組合せによって実装することができる。上述の特徴は、例えば機械読取可能な記憶装置または伝達信号のような情報伝送体に有形具体化したコンピュータプログラム製品内に実装し、プログラム可能プロセッサによって実行することができる。方法のステップは、入力データを処理し出力を生成することによって上述の実装の機能を実行する命令プログラムを実行するプログラム可能プロセッサによって実行することができる。上述の特徴は、データと命令をデータ記憶装置から受け取り、またはデータと命令をデータ記憶装置に送信するように連結された少なくとも１つのプログラム可能プロセッサ、少なくとも１つの入力装置、少なくとも１つの出力装置を備えたプログラム可能システム上で実行する１以上のコンピュータプログラム内で、効果的に実装することができる。コンピュータプログラムは、コンピュータ内で直接または間接に、特定の活動を実行し、または特定の結果をもたらす、命令セットである。コンピュータプログラムは、コンパイル言語またはインタープリタ言語を含む任意のプログラム言語の形態で記述することができる。コンピュータプログラムは、スタンドアロンプログラム、またはモジュール、コンポーネント、サブルーチン、またはコンピュータ環境内の使用に適した他のユニットを含む、任意の形態で配信することができる。
【００５６】
命令プログラムの実行に適したプロセッサには、例えば、一般および特定用途マイクロプロセッサ、単一のプロセッサ、または任意種類のコンピュータのマルチプロセッサの１つが含まれる。一般にプロセッサは、読取専用メモリまたはランダムアクセスメモリまたはこれら双方から、命令とデータを受け取る。コンピュータの必須要素は、命令を実行するプロセッサと、命令とデータを格納する１以上のメモリである。一般にコンピュータは、データファイルを格納する１以上の大容量記憶装置を備え、または通信できるように接続される。このようなデバイスには、内部ハードディスクおよびリムーバブルディスクのような磁気ディスク、光磁気ディスク、光ディスクが含まれる。コンピュータプログラム命令およびデータを有形具体化するのに適した記憶装置には、例えばＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ装置のような半導体メモリ装置、内部ハードディスクおよびリムーバブルディスクのような磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスクを含む、任意形態の不揮発性メモリが含まれる。プロセッサとメモリは、ＡＳＩＣｓ（特定用途向け集積回路）によって補い、またはＡＳＩＣｓ内に内蔵することができる。
【００５７】
ユーザとの相互動作を提供するため、上述の特徴は、ユーザに情報を表示するＣＲＴ（Ｃａｔｈｏｄｅ  ｒａｙ  ｔｕｂｅ）またはＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）モニタのようなディスプレイ装置、キーボード、ユーザがコンピュータに対して入力することができるマウスまたはトラックボールのようなポインタデバイスを備えるコンピュータ上で実装することができる。
【００５８】
上述の特徴は、データサーバのようなバックエンド要素を有するコンピュータシステム内、またはアプリケーションサーバやインターネットサーバのようなミドルウェア要素を有するコンピュータシステム内、またはグラフィカルユーザインタフェースやインターネットブラウザを有するクライアントコンピュータのようなフロントエンド要素を有するコンピュータシステム内、またはこれらの任意の組合せによって実装することができる。システムの要素は、通信ネットワークのようなデジタルデータ通信の任意形態の媒体によって接続することができる。通信ネットワークの例には、例えばＬＡＮ、ＷＡＮ、インターネットを形成するコンピュータとネットワークが含まれる。
【００５９】
コンピュータシステムは、クライアントとサーバを備えることができる。クライアントとサーバは、一般に互いに離れており、典型的には上述のようなネットワークを介して通信する。クライアントとサーバの関係は、各コンピュータ上で動作し、クライアント−サーバ同士の関係を有するコンピュータプログラムによって成り立つ。
【００６０】
上記ではいくつかの実装例を詳細に説明したが、他の変形例も可能である。また、図面に表した論理フローは、望ましい結果を達成するために、図示した特定順序または逐次順序を要するものではない。また、上述のフローに他ステップを追加し、またはステップを削除し、上述のシステムに他の要素を追加し、または削除することもできる。特許請求の範囲およびその要旨を逸脱することなく様々な変形が可能であることが理解されよう。したがって、他の実装例も特許請求の範囲に含まれる。
【図１】
2010541102.tif 000004
【図２】
2010541102.tif 000005
【図３】
2010541102.tif 000006
【図４】
2010541102.tif 000007
【図５】
2010541102.tif 000008
【図６】
2010541102.tif 000009
【図７】
2010541102.tif 000010
【図８】
2010541102.tif 000011
【国際調査報告】
2010541102.tif 000012
2010541102.tif 000013