(57)【要約】【課題】通信記録の分析装置において正常なデータや異常なデータの取り出しや検索ができるようにする。【解決手段】「表示装置１」と「打鍵装置２」と通信データの重要な情報が格納された「データベース（通信パケットテーブル）４」及び「通信サマリーデータ５」を検索する「データ検索機構３」を有し、特定検索規則として「種別メニュー定義６」、「特定検索ＳＱＬ定義７」、「ＳＱＬ検索除外定義８」、「サイトコード定義９」、「検索メニュー定義１０」、「プロシジャー１４」が定義でき、「作業域１３」を利用してお互い処理を行う「特定検索制御機構１１」、「検索機構１２」、上記「プロシジャー１４」、「コード変換機構１５」の連携により実現する。【選択図】  図１
2006186953.tif 000002
【特許請求の範囲】
【請求項１】
通信のパケット内の情報が登録されたデータベースを検索し該当した結果を表示すると共にこの結果の前後の流れを示す通信データの一覧を表示することにより通信の流れおよび内容からデータ取り出しの規則性が発見できる機構を持ち、これにより見いだされた規則を特定検索規則として、代表データを検索するＳＱＬ文の定義と検索から除外する文字列の定義とコード変換を規定した定義と、これら定義に対応したプロシジャーが組み込める点を特徴とし、代表データを検索するＳＱＬ文の定義と検索から除外する文字列の定義により検索用ＳＱＬ文を生成し上記データベースを検索、定義に対応したプロシジャーがこの検索結果を参照し、検索結果のデータ位置を起点としてプロシジャーが上記データベースから特定範囲のデータを取り込み、プロシジャーがこのデータを直接コード変換するか、定義によりコード変換を行うコード変換機構にデータをコード変換させることで、通信時のデータを表示装置で参照できる形に再生する方法とこれを実現する構造とこの構造を持つシステム。
【請求項２】
上記の方法により再生されたデータの文字列を検索する方法とこれを実現する構造とこの構造を持つシステム。
【発明の詳細な説明】
【技術分野】
【０００１】本発明は通信分野における通信記録の分析装置に関する発明である。
【背景技術】
【０００２】従来、パケットデータを傍受し、その中から特定のデータを取り出す方法は特許文献１に記載される方法及び装置が知られている。この方法はリアルタイムにパケットデータを傍受し、指定されたデータを選別し、特定のデータをデータベースに記録する方式が取られている。この方法とは別に特許文献２に示される方法のようにパケットデータを特殊な種類に分けるものの、すべての情報を記録し検索するシステムがある。【０００３】
【特許文献１】  特願２０００−３４１１８３号
【特許文献２】  特願２００４−６３１３２号
【発明の開示】
【発明が解決しようとする課題】
【０００４】特許文献１に記載された方法ではあらかじめ決められた手順のデータの取り出ししかできない。通信は通信の中断やデータ消失、データの変質の存在する世界である。また、新型の攻撃やコンピュータウィルスなど今までにないパターンの通信も存在する。特許文献１に記載された方法によれば、それらは決められた手順のデータでないと判断され処理対象外となる。これでは始めからデータが記録されず、利用者にそのデータが認識できない危険性がある。【０００５】この弱点を解決するには、特許文献２に示される方法のようにパケットデータをすべて記録し検索するシステムを利用し、通信の流れに正常や異常が発見できなければならない。逆にいうと、この調査過程があって、はじめて正常なデータや異常なデータの取り出しが可能になる。リアルタイムのデータの取り出しで取り出し不能になったデータは特許文献１の方法では失われることになる。この弱点を解決し確実にデータを取り出す方法が課題となった。
【課題を解決するための手段】
【０００６】図１は本発明の構成を示すブロック図である。
本発明は、「表示装置１」と「打鍵装置２」と「データ検索機構３」を利用し通信データの重要な情報が格納された「データベース（通信パケットテーブル）４」からデータを検索表示し、そこを起点に通信データの代表的な情報を取り出して作成された一覧データ「通信サマリーデータ５」を表示する。この部分は特許文献２と変わりない点である。この機能を利用し通信の流れおよび内容から特定のデータ取り出しを目的とする規則性を発見する。特許文献２ではこのような使い方を規定しているわけではなく本発明のみこの点を規定する。これは課題を解決するための基本要素となる。【０００７】発見された規則により、取り出すデータを区別するための定義「種別メニュー定義６」とデータベース検索のための定義「特定検索ＳＱＬ定義７」とその検索から除外する定義「ＳＱＬ検索除外定義８」とデータのコード変換を定義した「サイトコード定義９」と「プロシジャー１４」が作成される。【０００８】これを「特定検索制御機構１１」が、「特定検索ＳＱＬ定義７」と「ＳＱＬ検索除外定義８」を読んで「データベース（通信パケットテーブル）４」を検索する「検索機構１２」と、「プロシジャー１４」と連携し特定のデータの取り出しと検索を実現する。【０００９】「プロシジャー１４」は他に「サイトコード定義９」を読んでコード変換を行う「コード変換機構１５」と連携し最終的にデータのコード変換を行う。「作業域１３」は「プロシジャー１４」と「コード変換機構１５」に使用されるほか「特定検索制御機構１１」と「検索機構１２」及び「プロシジャー１４」から利用される。
「検索メニュー定義１０」は「特定検索制御機構１１」が「検索機構１２」と「プロシジャー１４」と連携し「データベース（通信パケットテーブル）４」から再生したデータの文字列検索に利用する定義である。
【発明の効果】
【００１０】本発明を利用すると、検索により発見した通信パターンにおいてデータの取り出し精度を上げることが可能となり、正常な手順で得られるデータだけでなく、異常なパターンのデータも取り出すことができるようになる。
【発明を実施するための最良の形態】
【００１１】特許文献２に示される方法のようにパケットデータをすべて記録し検索するシステムであることが前提である。その上で、様様な検索機能を持ち容易に正常なパターンの通信、異常なパターンの通信の規則性がわかるシステムである必要がある。以上のシステムに対し「種別メニュー定義６」、「特定検索ＳＱＬ定義７」、「ＳＱＬ検索除外定義８」、「サイトコード定義９」、「検索メニュー定義１０」、「特定検索制御機構１１」、「検索機構１２」、「作業域１３」、「プロシジャー１４」、「コード変換機構１５」を装備させることで本発明の効果が最大限発揮される。
【実施例】
【００１２】以下、本発明の実施形態を図１〜図３０に基づいて説明する。【００１３】図１は本発明の構成を示すブロック図である。
「表示装置１」と「打鍵装置２」と「データ検索機構３」と「データベース（通信パケットテーブル）４」と「通信サマリーデータ５」の構成は特許文献２と同等である。この特許は、通信の内容を用途により「ルーティング関連のデータ」、「通信確認関連のデータ」、「データ通信関連のデータ」に分けて蓄積する方法を特徴にしている。また「データ通信関連のデータ」は「サービス提供タイプ」と「サービス要求タイプ」の２つに分離される。この方法はデータの蓄積量の削減と異常発見の精度向上を目的としたことが特許文献２で記されている。以上のように分離されたデータそれぞれに専用の不正検知処理を行うと誤検知の発生率が飛躍的に低下することが確認されている。【００１４】「データ通信関連のデータ」とは具体的にプロトコルで言うとＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）とＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）に相当し、それらの通信において「サービス提供タイプ」とはサーバからクライアントへ送信するデータであり、「サービス要求タイプ」とはクライアントからサーバへ送信するデータである。
従って「データベース（通信パケットテーブル）４」は送受信のデータを持たず、どちらか一方向の通信から取り出したデータを持つ特長がある。【００１５】双方向の通信データを持つものは「ルーティング関連のデータ」、「通信確認関連のデータ」、「データ通信関連のデータ」の各データとなる。特に、今回は「データ通信関連のデータ」が重要であり、これが「通信サマリーデータ５」に相当するものである。図１８は「データベース（通信パケットテーブル）４」の構成要素図であり、図１９は「通信サマリーデータ５」の構成要素図である。【００１６】以上の特徴を持つデータのため、通信の流れは「データベース（通信パケットテーブル）４」と「通信サマリーデータ５」の両者を使用して確認することになる。【００１７】本発明の重要な利点はデータ取り出し処理が修正でき、データ取り出し精度が向上する点にある。データ取り出し精度向上のための作業の流れ図を図２に示す。【００１８】処理ステップ１で「データ検索機構３」を使いデータ取り出しの規則性を調査する。つまり、「データベース（通信パケットテーブル）４」と「通信サマリーデータ５」の両者を検索して調査する。ここで通信データの規則性の発見や確認を行う。【００１９】処理ステップ２で、特定検索の関連定義が存在するか判定する。
ＹＥＳの場合、処理ステップ４へ進む。
ＮＯの場合、処理ステップ３へ進む。【００２０】処理ステップ３は特定検索の関連定義が存在しない場合である。
新規に「種別メニュー定義６」を作成し、この定義に対応する「特定検索ＳＱＬ定義７」、「ＳＱＬ検索除外定義８」、「サイトコード定義９」、「検索メニュー定義１０」、「プロシジャー１４」を作成する。処理ステップ５へ進む。【００２１】処理ステップ４は特定検索の関連定義が存在する場合である。
作成済みの「種別メニュー定義６」、「特定検索ＳＱＬ定義７」、「ＳＱＬ検索除外定義８」、「サイトコード定義９」、「検索メニュー定義１０」、「プロシジャー１４」を修正する。処理ステップ５へ進む。【００２２】処理ステップ５で、「特定検索制御機構１１」を使いデータ取り出しを実行し、正しくデータが表示されるか確認する。【００２３】処理ステップ６で、データが正しく表示されるか判定する。
ＹＥＳの場合、処理ステップ７へ進む。
ＮＯの場合、再度、調査をする必要があるため処理ステップ１へ戻る。【００２４】処理ステップ７で、作成した定義とは別の観点により「データ検索機構３」を使いデータを検索し、データ取り出しの抜けがないか調査する。【００２５】処理ステップ８で、抜けが存在するか判定する。
ＹＥＳの場合、再度、調査をする必要があるため処理ステップ１へ戻る。
ＮＯの場合、以上の処理を終了する。【００２６】図２０は「種別メニュー定義６」の構成要素図である。項１の「種別コード」は区分を示す。項２の「表示タイトル」は「特定検索制御機構１１」が「表示装置１」に表示する選択メニュー内に表示される題名を示す。項３の「プロシジャーコード」は「特定検索制御機構１１」が「プロシジャー１４」を起動する時に参照するコードである。項４の「文字コード名の初期値」はデータのコード変換を行う場合の初期値である。項５の「ＵＲＬデコードフラグ」はデータのＵＲＬデコードを指示するものでＯＮの場合、データに対しＵＲＬデコードが行われる。【００２７】図２１は「特定検索ＳＱＬ定義７」の構成要素図である。項１の「種別コード」は区分を示す。「種別メニュー定義６」の関連データとして「種別メニュー定義６（図２０）」の項１と同じ値が設定される。項２の「検索条件（ＳＱＬ文）」は「検索機構１２」が「データベース（通信パケットテーブル）４」を検索する場合使用するＳＱＬ文の条件部分である。具体的な例を図２５と図２６に示す。【００２８】図２２は「ＳＱＬ検索除外定義８」の構成要素図である。項１の「種別コード」は区分を示す。「種別メニュー定義６」の関連データとして「種別メニュー定義６（図２０）」の項１と同じ値が設定される。項２の「検索文字列」は「検索機構１２」が「データベース（通信パケットテーブル）４」を検索する場合、除外対象にする文字列である。【００２９】図２３は「サイトコード定義９」の構成要素図である。項１の「種別コード」は区分を示す。「種別メニュー定義６」の関連データとして「種別メニュー定義６（図２０）」の項１と同じ値が設定される。項２の「サイトの名前」は「データベース（通信パケットテーブル）４（図１８）」の項１３の「送信元の法人名又は団体名」の一部もしくは全部を記載したもの。項３の「文字コード名」は「コード変換機構１５」がデータのコード変換を行う時に参照する文字コードの名称である。【００３０】図２４は「検索メニュー定義１０」の構成要素図である。項１の「種別コード」は区分を示す。「種別メニュー定義６」の関連データとして「種別メニュー定義６（図２０）」の項１と同じ値が設定される。項２の「選択タイトル」は再生されたデータをさらに検索する時の選択メニュー内に表示される題名である。項３の「検索文字列」は再生されたデータにおいて検索する文字列である。【００３１】特定検索結果一覧表示処理の手順を図３に示す。この処理は図４〜図１３の手順と連動して動作する。以下、図３〜図１３について説明する。【００３２】処理ステップ９で、「打鍵装置２」から種別メニューの種別が入力されると「特定検索制御機構１１」が処理を開始する。【００３３】処理ステップ１０で、「特定検索制御機構１１」が「種別メニュー定義６」を読む。【００３４】処理ステップ１１で、「特定検索制御機構１１」が「検索機構１２」を起動する。【００３５】処理ステップ１２で、特定検索処理が行われる。この処理を図４に示す。【００３６】処理ステップ１９で、「検索機構１２」が「特定検索ＳＱＬ定義７」と「ＳＱＬ検索除外定義８」を読み、検索用ＳＱＬ文を生成する。
「特定検索ＳＱＬ定義７（図２１）」の項２「検索条件（ＳＱＬ文）」の定義例を図２５と図２６に示す。
この条件は特定検索結果一覧で表示される題名のもととなるデータを検索する条件である。この条件文はＳＱＬ文のＷｈｅｒｅ句に記載される部分であり、これを「特定検索ＳＱＬ定義７（図２１）」の項２「検索条件（ＳＱＬ文）」に設定する。
図２５と図２６の各項は「種別コード」と一対一に対応する。
本例の場合、図２５の項１は「Ｅメールの題名」、図２５の項２は「Ｅメールの添付ファイル名」、図２５の項３はＨＴＴＰの「ＧＥＴリクエスト」、図２５の項４はＨＴＴＰの「ＰＯＳＴリクエスト」、図２６の項５はＨＴＴＰの「クッキーフィールド」、図２６の項６はＦＴＰの「ＧＥＴ，ＭＧＥＴ，ＲＥＴＲリクエスト」、図２６の項７はＦＴＰの「ＰＵＴ，ＭＰＵＴ，ＳＴＯＲリクエスト」、図２６の項８は「ＳＳＬセション確立」の特定検索に対応する。これらの名称は「種別メニュー定義６（図２０）」の項２「表示タイトル」に設定される。【００３７】特に、図２５の項３〜項４と図２６の項５のＨＴＴＰ関連のデータには一部ＯＳやウィルス対策ソフトの自動修正適用のリクエストが検索で見つかる場合が多く、この問題を「ＳＱＬ検索除外定義８」を使い検索から除外する条件を追加することで回避する。
「ＳＱＬ検索除外定義８（図２２）」の項２の「検索文字列」は以下のＳＱＬ文が定義の数ほど生成され、「特定検索ＳＱＬ定義７（図２１）」の項２の「検索条件（ＳＱＬ文）」に追加される。
「ａｎｄ  ｎｏｔ  ｄａｔａ＿ｔｘｔ  ｌｉｋｅ  ‘％「検索文字列（図２２の項２）」％’」
ｄａｔａ＿ｔｘｔとは「データベース（通信パケットテーブル）４（図１８）」の項１６「通信パケットのデータ内容（ＡＳＣＩＩ形式）」の名称である。
なお、ＨＴＴＰはＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌの略であり、ＦＴＰはＦｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌの略であり、ＳＳＬはＳｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒの略である。【００３８】処理ステップ２０で、「検索機構１２」が「データベース（通信パケットテーブル）４」に対し検索を実行する。【００３９】処理ステップ２１で、「検索機構１２」が検索結果をインターフェイス域（図２７の項１）に格納し、検索完了を「特定検索制御機構１１」へ通知する。
このインターフェイス域は「作業域１３」に作成される。図２７にインターフェイス域の構成図を示す。以降、「検索結果を参照する」という表現は、このインターフェイス域（図２７）の項１を参照することを意味する。
以上、特定検索処理を完了し、図３へ戻る。【００４０】処理ステップ１３で、「特定検索制御機構１１」が「プロシジャーコード（図２０の項３）」があるか判定する。
ＹＥＳの場合、処理ステップ１４へ進む。
ＮＯの場合、処理ステップ１８へ進む。
「特定検索制御機構１１」は「プロシジャーコード」をもとに「プロシジャー１４」を読み込むか決定する。「プロシジャーコード」が空の時はデータの再加工処理はおこなわない。
図２５と図２６の例の場合、図２５の項２の「Ｅメールの添付ファイル名」と図２６の項８の「ＳＳＬセション確立」に対応する「種別メニュー定義６」の「プロシジャーコード（図２０の項３）」は空であり、データの再加工処理の対象外になっている。【００４１】処理ステップ１４で、「特定検索制御機構１１」が対応する「プロシジャー１４」を読み込む。これにより「プロシジャー１４」はデータの再加工処理ができる状態になる。【００４２】処理ステップ１５で、「特定検索制御機構１１」が「特定検索処理（処理ステップ１２）」の検索結果を参照する。検索結果とはインターフェイス域（図２７）の項１のことである。この時「特定検索制御機構１１」はインターフェイス域（図２７）の項２〜項６の初期化も行う。【００４３】処理ステップ１６で、「特定検索制御機構１１」が検索結果が全くないか、最後まで読んだか判定する。
ＹＥＳの場合、終了したので処理ステップ１８へ進む。
ＮＯの場合、データを再加工する必要があるので、処理ステップ１７へ進む。【００４４】処理ステップ１７で、データ再加工処理が行われる。この処理を図５に示す。
データ再加工処理の目的は、特定検索結果一覧表示の題名を完全に表示する目的とＥメールの本文を再生し内容が表示できる状態にする目的がある。「プロシジャー１４」はこれを実現するために作成される手順である。【００４５】図５の処理ステップ２２で、「特定検索制御機構１１」が「プロシジャー１４」を呼び出す。処理ステップ２３以降は、用意された「プロシジャー１４」の実行になる。今回は「Ｅメールデータ再加工処理」と「ＨＴＴＰ・ＦＴＰデータ再加工処理」を例に説明する。
もちろん、「Ｔｅｌｎｅｔのコマンドデータ再加工処理」や「ＰＯＰ３のＥメールデータ再加工処理」など専用の「プロシジャー１４」及びこれに対応する「種別メニュー定義６」、「特定検索ＳＱＬ定義７」、「ＳＱＬ検索除外定義８」、「サイトコード定義９」を新規に作成すれば、同様にデータベースから通信時のデータが再生できる。【００４６】図２５と図２６の例では、図２５の項１の「Ｅメールの題名」の場合、処理ステップ２３の「Ｅメールデータ再加工処理」が実行される。
図２５の項３のＨＴＴＰの「ＧＥＴリクエスト」、図２５の項４のＨＴＴＰの「ＰＯＳＴリクエスト」、図２６の項５のＨＴＴＰの「クッキーフィールド」、図２６の項６のＦＴＰの「ＧＥＴ，ＭＧＥＴ，ＲＥＴＲリクエスト」、図２６の項７のＦＴＰの「ＰＵＴ，ＭＰＵＴ，ＳＴＯＲリクエスト」の場合、処理ステップ２４の「ＨＴＴＰ・ＦＴＰデータ再加工処理」が実行される。
「Ｅメールデータ再加工処理」は図６〜図９の手順で処理が行われ、「ＨＴＴＰ・ＦＴＰデータ再加工処理」は図１０〜図１２の手順で処理が行われる。
以下、「Ｅメールデータ再加工処理」、「ＨＴＴＰ・ＦＴＰデータ再加工処理」の順に処理を説明する。【００４７】図６へ進み。処理ステップ２５で、「プロシジャー１４」はデータ再加工処理時のデータの記録に使う領域を初期化する。【００４８】処理ステップ２６で、「組み立てデータ」に検索結果（図２７の項１）の「通信パケットのデータ内容（１６進数）（図８の項１７に相当）」を設定する。
「組み立てデータ」とは最終的に再生されるデータのことである。【００４９】処理ステップ２７で、検索結果（図２７の項１）の順次番号（図１８の項１に相当）を起点として、Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（図１８の項９に相当）の整合性を考慮し、検索結果（図２７の項１）の送信元ＩＰアドレス（図１８の項５に相当）と送信先ＩＰアドレス（図１８の項７に相当）と送信先ＰＯＲＴ番号（図１８の項８に相当）が同一である次のデータを「データベース（通信パケットテーブル）４」から検索する。ＳＱＬ文は以下となる。
「ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  ｔａｂｌｅ＿ｎａｍｅ  ｗｈｅｒｅ  ｐｒｏｔｏｃｏｌ＝‘ＴＣＰ’  ａｎｄ  ＄ｎｏｗｐｏｓ＜ｓｅｒｉａｌ  ａｎｄ  ｓｒｃ＿ｉｐ＝＄ｎｏｗ＿ｓｒｃ  ａｎｄ  ｄｓｔ＿ｉｐ＝＄ｎｏｗ＿ｄｓｔ  ａｎｄ  ｄｓｔ＿ｐｏｒｔ＝＄ｎｏｗ＿ｄｓｔ＿ｐｏｒｔ  ａｎｄ  ｎｏｗ＿ｓｅｑ＝＄ｎｅｘｔ＿ｓｅｑ  ｌｉｍｉｔ  ０，１  」
＄ｎｏｗｐｏｓは検索結果（図２７の項１）の順次番号（図１８の項１に相当）であり、データの位置を示す。＄ｎｏｗ＿ｓｒｃは検索結果（図２７の項１）の送信元ＩＰアドレス（図１８の項５に相当）を示し、＄ｎｏｗ＿ｄｓｔは検索結果（図２７の項１）の送信先ＩＰアドレス（図１８の項７に相当）を示し、＄ｎｏｗ＿ｄｓｔ＿ｐｏｒｔは検索結果（図２７の項１）の送信先ＰＯＲＴ番号（図１８の項８に相当）を示し、＄ｎｅｘｔ＿ｓｅｑは検索結果（図２７の項１）のＮｅｘｔ  Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（図１８の項１０に相当）を示す。
Ｎｅｘｔ  Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒとは現通信パケットのＳｅｑｕｅｎｃｅ  ｎｕｍｂｅｒにデータ長を加えた値のことを言う。正常な通信なら、次の通信パケットのｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒはこのＮｅｘｔ  Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒになっている。
ｔａｂｌｅ＿ｎａｍｅは「データベース（通信パケットテーブル）４」の名称であり、ｓｅｒｉａｌは「順次番号（図１８の項１）」の名称であり、ｐｒｏｔｏｃｏｌは「プロトコル名（図１８の項４）」の名称であり、ｓｒｃ＿ｉｐは「送信元ＩＰアドレス（図１８の項５）」の名称であり、ｄｓｔ＿ｉｐは「送信先ＩＰアドレス（図１８の項７）」の名称であり、ｄｓｔ＿ｐｏｒｔは「送信先ＰＯＲＴ番号（図１８の項８）」の名称であり、ｎｏｗ＿ｓｅｑは「Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（図１８の項９）」の名称である。
ｄｓｔ＿ｐｏｒｔは通信の方向が逆の場合、「送信元ＰＯＲＴ番号（図１８の項６）」の名称「ｓｒｃ＿ｐｏｒｔ」に置き換わる。この場合、＄ｎｏｗ＿ｄｓｔ＿ｐｏｒｔは検索結果（図２７の項１）の送信元ＰＯＲＴ番号（図１８の項６に相当）である＄ｎｏｗ＿ｓｒｃ＿ｐｏｒｔに置き換わる。【００５０】処理ステップ２８で、未発見か判定する。
ＹＥＳの場合、処理ステップ３２へ進む。
ＮＯの場合、処理ステップ２９へ進む。【００５１】処理ステップ２９で、発見したデータ（図１８）にＱＵＩＴコマンド又はＦＩＮフラグ又はＲＥＳＥＴフラグがあるか判定する。ＱＵＩＴコマンドの有無は図１８の項１６「通信パケットのデータ内容（ＡＳＣＩＩ形式）」を検査し、ＦＩＮフラグ又はＲＥＳＥＴフラグの有無は図１８の項１５「ＴＣＰフラグ、ＩＣＭＰのタイプとコードなど」を検査する。
ＹＥＳの場合、処理ステップ３２へ進む。
ＮＯの場合、処理ステップ３０へ進む。【００５２】処理ステップ３０で、データ再加工処理時のデータの再生処理を行う。
プロトコルがＴＣＰの場合、パケットのＳｅｑｕｅｎｃｅ  ｎｕｍｂｅｒを考慮しデータを組み立てる必要がある。ＴＣＰの場合、同じデータを持つパケットが出現する。これは送信再試行のデータであり、処理においてこのデータを無視する必要がある。この判断はパケットに与えられたＳｅｑｕｅｎｃｅ  ｎｕｍｂｅｒにより行う。図１３にデータ再加工処理時のデータの再生処理の手順を示す。以下、図１３について説明する。【００５３】処理ステップ６６で、データの「Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（図１８の項９）」が同じである記録２（図１４の項１）が存在するか判定する。
ＹＥＳの場合、処理を終了する。
ＮＯの場合、処理ステップ６７へ進む。
記録２とは、処理ステップ６７により記録されたデータのことで図１４の構成要素を持っている。【００５４】処理ステップ６７で、「データベース（通信パケットテーブル）４（図１８）」の項９、項１７を参照し、記録２（図１４）に項９「Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ」を追加する。「組み立てデータ」に項１７「通信パケットのデータ内容（１６進数）」を追加する。【００５５】以上、データ再加工処理時のデータの再生処理を終了し、図６へ戻る。
処理ステップ２８〜処理ステップ３１のループが終了すると「組み立てデータ」にデータが組み立てられたことになる。【００５６】処理ステップ３１で、現在のデータの順次番号（図１８の項１）を起点として、Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒの整合性を考慮し、検索結果（図２７の項１）の送信元ＩＰアドレス（図１８の項５に相当）と送信先ＩＰアドレス（図１８の項７に相当）と送信先ＰＯＲＴ番号（図１８の項８に相当）が同一である次のデータを「データベース（通信パケットテーブル）４」から検索する。ＳＱＬ文は以下となる。
「ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  ｔａｂｌｅ＿ｎａｍｅ  ｗｈｅｒｅ  ｐｒｏｔｏｃｏｌ＝‘ＴＣＰ’  ａｎｄ  ＄ｎｏｗｐｏｓ＜ｓｅｒｉａｌ  ａｎｄ  ｓｒｃ＿ｉｐ＝＄ｎｏｗ＿ｓｒｃ  ａｎｄ  ｄｓｔ＿ｉｐ＝＄ｎｏｗ＿ｄｓｔ  ａｎｄ  ｄｓｔ＿ｐｏｒｔ＝＄ｎｏｗ＿ｄｓｔ＿ｐｏｒｔ  ａｎｄ  ｎｏｗ＿ｓｅｑ＝＄ｎｅｘｔ＿ｓｅｑ  ｌｉｍｉｔ  ０，１  」
＄ｎｏｗ＿ｓｒｃは現在発見したデータの順次番号（図１８の項１）を示し、＄ｎｅｘｔ＿ｓｅｑは現在発見したデータのＮｅｘｔ  Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（図１８の項１０）を示す。
＄ｎｏｗ＿ｓｒｃは検索結果（図２７の項１）の送信元ＩＰアドレス（図１８の項５に相当）を示し、＄ｎｏｗ＿ｄｓｔは検索結果（図２７の項１）の送信先ＩＰアドレス（図１８の項７に相当）を示し、＄ｎｏｗ＿ｄｓｔ＿ｐｏｒｔは検索結果（図２７の項１）の送信先ＰＯＲＴ番号（図１８の項８に相当）を示す。
ｔａｂｌｅ＿ｎａｍｅは「データベース（通信パケットテーブル）４」の名称であり、ｓｅｒｉａｌは「順次番号（図１８の項１）」の名称であり、ｐｒｏｔｏｃｏｌは「プロトコル名（図１８の項４）」の名称であり、ｓｒｃ＿ｉｐは「送信元ＩＰアドレス（図１８の項５）」の名称であり、ｄｓｔ＿ｉｐは「送信先ＩＰアドレス（図１８の項７）」の名称であり、ｄｓｔ＿ｐｏｒｔは「送信先ＰＯＲＴ番号（図１８の項８）」の名称であり、ｎｏｗ＿ｓｅｑは「Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（図１８の項９）」の名称である。
ｄｓｔ＿ｐｏｒｔは通信の方向が逆の場合、「送信元ＰＯＲＴ番号（図１８の項６）」の名称「ｓｒｃ＿ｐｏｒｔ」に置き換わる。この場合、＄ｎｏｗ＿ｄｓｔ＿ｐｏｒｔは検索結果（図２７の項１）の送信元ＰＯＲＴ番号（図１８の項６に相当）である＄ｎｏｗ＿ｓｒｃ＿ｐｏｒｔに置き換わる。
以上、ループ処理が終了すると図７へ進む。【００５７】処理ステップ３２で、データがあるか判定する。
データとは処理ステップ２８〜処理ステップ３１のループで生成した「組み立てデータ」のことである。
ＹＥＳの場合、処理ステップ３３へ進む。
ＮＯの場合、処理を終了する。【００５８】処理ステップ３３で、ヘッダ格納域とＥメール内容域を初期化する。
「ヘッダ格納域」とはＥメールのヘッダ部分を格納する領域をいう。Ｅメールのヘッダ部分とはＥメールの先頭部分にあり、題名、差出人、あて先、写し送付先などのデータが記載された部分をいう。このデータの一部は一覧表の題名表示に使用される。「Ｅメール内容域」とはＥメール全体のデータを格納する領域のことである。例えば、Ｅメールの内容全体を画面に表示したい時に必要になるデータである。
なお、「組み立てデータ」はこの時点で１６進数からバイナリデータへ変換される。このデータは複数行のデータになっている。【００５９】処理ステップ３４で、データを１行読む。【００６０】処理ステップ３５で、最終行を超えたか判定する。
ＹＥＳの場合、処理ステップ４４へ進む。図９に手順を示す。
ＮＯの場合、処理ステップ３６へ進む。【００６１】処理ステップ３６で、データが「ｍａｉｌ  ｆｒｏｍ：コマンド行」か判定する。
ＹＥＳの場合、処理ステップ３７へ進む。
ＮＯの場合、処理ステップ３８へ進む。【００６２】処理ステップ３７で、「ｍａｉｌ  ｆｒｏｍ：コマンド行」から差出人のＥメールアドレスを取り出す。処理後、処理ステップ３４へ戻る。この情報は特定検索結果一覧表示の際、必要になる。【００６３】処理ステップ３８で、データが「ｒｃｐｔ  ｔｏ：コマンド行」か判定する。
ＹＥＳの場合、処理ステップ３９へ進む。
ＮＯの場合、処理ステップ４０へ進む。【００６４】処理ステップ３９で、「ｒｃｐｔ  ｔｏ：コマンド行」からあて先のＥメールアドレスを取り出す。処理後、処理ステップ３４へ戻る。この情報は特定検索結果一覧表示の際、必要になる。【００６５】処理ステップ４０で、データが「ＤＡＴＡコマンド行」を超えたか判定する。
ＹＥＳの場合、処理ステップ４１へ進む。
ＮＯの場合、処理ステップ３４へ戻る。【００６６】処理ステップ４１で、初回の連続改行を超えたか判定する。
ＹＥＳの場合、処理ステップ４３へ進む。
ＮＯの場合、処理ステップ４２へ進む。
これはＥメールのヘッダ部分がＥメールの先頭から最初の空行までのデータであるため、データがＥメールのヘッダ部分にあるのか判定している。【００６７】処理ステップ４２で、ヘッダ格納域へデータを追加する。【００６８】処理ステップ４３で、Ｅメール内容域へデータを追加する。
処理後、処理ステップ３４へ戻る。【００６９】図９の処理ステップ４４は上記処理により、必要なデータの採取が終わった状態にある。【００７０】処理ステップ４４で、ヘッダ格納域の「Ｓｕｂｊｅｃｔ：行」のデータ（Ｅメールの題名）を取り出す。データがＢＡＳＥ６４などで符号化されていた場合、そのデータを復号する。この情報は特定検索結果一覧表示の際、必要になる。
Ｅメールの題名には漢字コードが使用される場合が多い。Ｅメールの場合、そのまま送信することができないので符号化を行っている。現在、符号化の方式はＢＡＳＥ６４、Ｑｕｏｔｅｄ−Ｐｒｉｎｔａｂｌｅ、ｕｕｅｎｃｏｄｅなどがある。例えばＢＡＳＥ６４を使って符号化することを「Ｂエンコーディング」と呼び、「  ＝？文字コード名？Ｂ？ＢＡＳＥ６４で符号化されたデータ？＝改行」の形式になっている。このようにデータには「文字コード名」が入っている。
この場合、「ＢＡＳＥ６４で符号化されたデータ」を復号した後、このデータの文字コードを上記で指定された「文字コード名」とみなし、「表示系の文字コード」にコード変換する。「表示系の文字コード」とは処理を行う機械が使用する文字コードのことを言う。【００７１】処理ステップ４５で、Ｅメールの題名、あて先、差出入、Ｅメール内容域を特定検索結果の付随情報としてインターフェイス域（図２７）に書き出す。
Ｅメールの題名は図２７の項２に書き出され、あて先のＥメールアドレスは図２７の項３に書き出され、差出入のＥメールアドレスは図２７の項４に書き出され、Ｅメール内容域は図２７の項５に書き出される。ヘッダ格納域とＥメール内容域は「作業域１３」にあり、インターフェイス域（図２７）とは別に確保される。Ｅメールの内容については、内容表示や文字列検索の必要が出た時点で、上記処理によりデータを構築すればよい。Ｅメールの場合、以上のようにして「表示装置１」に表示する情報が構築される。【００７２】図１０〜図１２にＨＴＴＰ・ＦＴＰデータ再加工処理の手順を示す。これは、ＨＴＴＰのＧＥＴ・ＰＯＳＴリクエスト又はＦＴＰのＧＥＴ・ＭＧＥＴ・ＲＥＴＲリクエスト、ＰＵＴ・ＭＰＵＴ・ＳＴＯＲリクエストを元のデータに復元する手順である。【００７３】図１０の処理ステップ４６で、「プロシジャー１４」はデータ再加工処理時のデータの記録に使う領域を初期化する。この処理ステップは処理ステップ２５と同じである。【００７４】処理ステップ４７で、「組み立てデータ」に検索結果（図２７の項１）の「通信パケットのデータ内容（１６進数）（図８の項１７に相当）」を設定する。
この処理ステップは処理ステップ２６と同じである。【００７５】処理ステップ４８で、検索結果（図２７の項１）の順次番号（図１８の項１に相当）を起点として、Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒの整合性を考慮し、検索結果（図２７の項１）の送信元ＩＰアドレス（図１８の項５に相当）と送信先ＩＰアドレス（図１８の項７に相当）と送信先ＰＯＲＴ番号（図１８の項８に相当）が同一である次のデータを「データベース（通信パケットテーブル）４」から検索する。この処理ステップは処理ステップ２７と同じである。【００７６】処理ステップ４９で、未発見か判定する。この処理ステップは処理ステップ２８と同じである。
ＹＥＳの場合、処理ステップ５３へ進む。
ＮＯの場合、処理ステップ５０へ進む。【００７７】処理ステップ５０で、発見したデータ（図１８）がＡＣＫフラグを持つ０バイトのデータ又はＦＩＮフラグ又はＲＥＳＥＴフラグを持つか判定する。
０バイトのデータの有無は図１８の項１６「通信パケットのデータ内容（ＡＳＣＩＩ形式）」を検査し、ＡＣＫフラグ又はＦＩＮフラグ又はＲＥＳＥＴフラグの有無は図１８の項１５「ＴＣＰフラグ、ＩＣＭＰのタイプとコードなど」を検査する。
ＹＥＳの場合、処理ステップ５３へ進む。
ＮＯの場合、処理ステップ５１へ進む。【００７８】処理ステップ５１で、データ再加工処理時のデータの再生処理を行う。
この処理ステップは処理ステップ３０と同じである。【００７９】処理ステップ５２で、現在のデータの順次番号（図１８の項１）を起点として、Ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒの整合性を考慮し、検索結果（図２７の項１）の送信元ＩＰアドレス（図１８の項５に相当）と送信先ＩＰアドレス（図１８の項７に相当）と送信先ＰＯＲＴ番号（図１８の項８に相当）が同一である次のデータを「データベース（通信パケットテーブル）４」から検索する。
この処理ステップは処理ステップ３１と同じである。【００８０】図１１の処理ステップ５３で、データがあるか判定する。
データとはすでに説明した「組み立てデータ」のことである。
ＹＥＳの場合、処理ステップ５４へ進む。
ＮＯの場合、処理を終了する。【００８１】処理ステップ５４で、ＵＲＬデコード指示があるか判定する。
この指示は「種別メニュー定義６（図２０）」の項５のフラグで指定されている。
フラグがＯＮの場合、ＵＲＬデコード指示があることを意味する。
ＹＥＳの場合、処理ステップ５５へ進む。
ＮＯの場合、処理ステップ５６へ進む。【００８２】処理ステップ５５でデータをＵＲＬデコードする。
データとはすでに説明した「組み立てデータ」のことである。ＨＴＴＰのリクエストで日本語が含まれている場合、そのままデータとして送信できないのでＵＲＬエンコードという符号化が行われている。このため、データをＵＲＬデコードし、元のデータに戻す必要がある。
なお、「組み立てデータ」は１６進数になっているので、バイナリデータへ変換してからＵＲＬデコードする。【００８３】処理ステップ５６で、「プロシジャー１４」が「サイトコード定義９」を読む。なお、この時点で「組み立てデータ」が１６進数からバイナリデータへ変換されてなかった場合、「組み立てデータ」はバイナリデータへ変換される。【００８４】処理ステップ５７で「プロシジャー１４」が「サイトコード定義９」においてサイトの名前（図２３の項２）が検索結果（図２７の項１）の「送信先（送信元）の企業名又は団体名（図１８の項１３に相当）」のすべて又は一部と一致するものを探す。
通常、ＧＥＴリクエスト、ＰＯＳＴリクエストなどの文字コードは種類が明確になってないので、判定できない場合にそなえ「種別メニュー定義６」に「文字コード名の初期値（図２０の項４）」を定義し「サイトコード定義９」に「文字コード名（図２３の項３）」を定義しておく。文字コード名とは、文字のコード体系を示すものでＪＩＳ、シフトＪＩＳ、ＥＵＣ、ＵＴＦ−８、ＵＮＩＣＯＤＥなどを指す。図１２へ進む。【００８５】処理ステップ５８で、一致したものがあるか判定する。
ＹＥＳの場合、処理ステップ６２へ進む。
ＮＯの場合、処理ステップ５９へ進む。【００８６】処理ステップ５９で、「プロシジャー１４」が「コード変換機構１５」に「種別メニュー定義６」の文字コード名の初期値（図２０の項４）を渡す。【００８７】処理ステップ６０で、「コード変換機構１５」がデータから文字コードを判定する。
データとはすでに説明した「組み立てデータ」のことである。【００８８】処理ステップ６１で、文字コードが判定できたか判定する。
ＹＥＳの場合、処理ステップ６３へ進む。
ＮＯの場合、処理ステップ６４へ進む。【００８９】処理ステップ６２で、
「コード変換機構１５」が「サイトコード定義９」の文字コード名（図２３の項３）をデータの文字コードと見なし、表示系の文字コードにコード変換する。
データとはすでに説明した「組み立てデータ」のことである。【００９０】処理ステップ６３で、「コード変換機構１５」が判定した文字コードをデータの文字コードと見なし、表示系の文字コードにコード変換する。
データとはすでに説明した「組み立てデータ」のことである。【００９１】処理ステップ６４で、「コード変換機構１５」が文字コード名の初期値（図２０の項４）をデータの文字コードと見なし、表示系の文字コードにコード変換する。
データとはすでに説明した「組み立てデータ」のことである。
以上で「コード変換機構１５」の処理が終了する。【００９２】処理ステップ６５で、「プロシジャー１４」がコード変換されたデータを特定検索結果の付随情報としてインターフェイス域（図２７の項２）に書き出す。【００９３】以上の処理が終了すると、図５に戻り、データ加工処理を終了する。この処理は図３の処理ステップ１７と同じである。すべての処理が完了すると処理ステップ１８へ進む。【００９４】処理ステップ１８で、「特定検索制御機構１１」がインターフェイス域（図２７）の項１〜項５を参照し「表示装置１」へデータを一覧表示する。
以上の処理を通じて、通信情報を記録したデータベースから該当する通信データが再生され、「表示装置１」にそのデータが表示される。
図２８に「特定検索（Ｅメールの題名）結果一覧表示」の各行の構成要素図を示す。図２９に「特定検索（Ｅメールの題名とＳＳＬセション確立以外）結果一覧表示」の各行の構成要素図を示す。図３０に「特定検索（ＳＳＬセション確立）結果一覧表示」の各行の構成要素図を示す。【００９５】このようにして再生されたデータに対し文字列を検索する場合、以上の手順に従って再生したデータの内容を検索すればよい。この処理を図１５〜図１７に示す。これらの処理は図１に示す構成により処理が行われる。図１５は特定検索結果一覧表示からの検索処理の手順を示す。【００９６】処理ステップ６８で、「打鍵装置２」から検索文字列を入力又は検索メニューから選択項目を指定された。これにより、「特定検索制御機構１１」が起動する。【００９７】処理ステップ６９で、「特定検索制御機構１１」が「種別メニュー定義６」を読む。このステップは処理ステップ１０と同じである。【００９８】処理ステップ７０で、「特定検索制御機構１１」は「検索機構１２」を起動し、処理ステップ６８で入力された検索文字列もしくは指定された選択項目に該当する「検索メニュー定義１０」の検索文字列（図２４の項３）を渡す。【００９９】処理ステップ７１で、「特定検索処理１」が行われる。図１７に「特定検索処理１」の手順を示す。以下、図１７を説明する。【０１００】処理ステップ８２で、「検索機構１２」が「特定検索ＳＱＬ定義７」と「ＳＱＬ検索除外定義８」を読み、検索用ＳＱＬ文を生成する。このステップは処理ステップ１９と同じである。【０１０１】処理ステップ８３で、「検索機構１２」が「種別メニュー定義６」に「プロシジャーコード（図２０の項３）」があるか判定する。
ＹＥＳの場合、処理ステップ８６へ進む。
ＮＯの場合、処理ステップ８４へ進む。【０１０２】処理ステップ８４で、「検索機構１２」が「特定検索制御機構１１」から渡された検索文字列をサポートする文字コードのすべてにコード変換し、それらの１６進数を検索するＳＱＬ文を生成する。
例えば、ＪＩＳ、シフトＪＩＳ、ＥＵＣ、ＵＴＦ−８、ＵＮＩＣＯＤＥの文字コードをサポートしていた場合、以下のＳＱＬ文が生成される。
「  ａｎｄ  （  ｄａｔａ＿ｈｅｘ  ｌｉｋｅ  ‘％「ＪＩＳで符号化した検索列の１６進数」％’  ｏｒ  ｄａｔａ＿ｈｅｘ  ｌｉｋｅ  ‘％「シフトＪＩＳで符号化した検索列の１６進数」％’  ｏｒ  ｄａｔａ＿ｈｅｘ  ｌｉｋｅ  ‘％「ＥＵＣで符号化した検索列の１６進数」％’  ｏｒ  ｄａｔａ＿ｈｅｘ  ｌｉｋｅ  ‘％「ＵＴＦ−８で符号化した検索列の１６進数」％’  ｏｒ  ｄａｔａ＿ｈｅｘ  ｌｉｋｅ  ‘％「ＵＮＩＣＯＤＥで符号化した検索列の１６進数」％’  ）  」
ｄａｔａ＿ｈｅｘとは「データベース（通信パケットテーブル）４（図１８）」の項１７「通信パケットのデータ内容（１６進数）」の名称である。【０１０３】処理ステップ８５で、処理ステップ８２により生成された検索用ＳＱＬ文に処理ステップ８４で生成した検索用ＳＱＬ文を追加する。【０１０４】処理ステップ８６で、「検索機構１２」が「データベース（通信パケットテーブル）４」に対し検索を実行する。このステップは処理ステップ２０と同じである。【０１０５】処理ステップ８７で、「検索機構１２」が検索結果をインターフェイス域（図２７の項１）に格納し、検索完了を「特定検索制御機構１１」へ通知する。このステップは処理ステップ２１と同じである。
以上、特定検索処理を完了し、図１５へ戻る。【０１０６】処理ステップ７２で、「特定検索制御機構１１」が「プロシジャーコード（図２０の項３）」があるか判定する。
ＹＥＳの場合、処理ステップ７３へ進む。
ＮＯの場合、処理ステップ７４へ進む。【０１０７】処理ステップ７３で、「特定検索制御機構１１」が対応する「プロシジャー１４」を読み込む。これにより「プロシジャー１４」はデータの再加工処理ができる状態になる。このステップは処理ステップ１４と同じである。【０１０８】処理ステップ７４で、「特定検索制御機構１１」がインターフェイス域（図２７）の項６「データ該当フラグ」をＯＮにする。この時「特定検索制御機構１１」はインターフェイス域（図２７）の項２〜項５の初期化も行う。処理ステップ８１へ進む。【０１０９】図１６の処理ステップ７５で、「特定検索制御機構１１」が「特定検索処理（処理ステップ１２）」の検索結果（図２７の項１）を参照する。
この時「特定検索制御機構１１」はインターフェイス域（図２７）の項２〜項６の初期化も行う。このステップは処理ステップ１５と同じである。【０１１０】処理ステップ７６で、「特定検索制御機構１１」が検索結果が全くないか、最後まで読んだか判定する。
このステップは処理ステップ１６と同じである。
ＹＥＳの場合、終了したので処理ステップ８１へ進む。
ＮＯの場合、データを再加工する必要があるので、処理ステップ７７へ進む。【０１１１】処理ステップ７７で、データ再加工処理が行われる。このステップは処理ステップ１７と同じである。この処理により、通信時のデータが再生される。【０１１２】処理ステップ７８で、データに検索文字列があるか判定する。データとは処理ステップ７７で生成されたデータであり、インターフェイス域に格納されたデータ（図２７の２項〜５項）のことである。
ＹＥＳの場合、処理ステップ８０へ進む。
ＮＯの場合、処理ステップ７９へ戻る。【０１１３】処理ステップ７９で、「特定検索制御機構１１」がインターフェイス域（図２７）の項６「データ該当フラグ」をＯＦＦにする。【０１１４】処理ステップ８０で、「特定検索制御機構１１」がインターフェイス域（図２７）の項６「データ該当フラグ」をＯＮにする。【０１１５】処理ステップ８１で、「特定検索制御機構１１」は「データ該当フラグ（図２７の項６）」がＯＮであるインターフェイス域（図２７）の項１〜項５を使い表示装置に結果を表示する。
以上のようにして通信情報を記録したデータベースから通信データを再生し、そのデータから文字列を検索する。
【産業上の利用可能性】
【０１１６】本発明を利用することで、通信の正常・異常パターンに存在する特定データの取り出しが可能となり、取り出されたデータは符号化されたものを復号するのでそのデータ内の文字列検索が可能となる。また、図２に示すデータ取り出し精度向上のための作業を行うことにより、データの取り出し精度が向上する利点が生まれ、データの信頼性が向上する。
【図面の簡単な説明】
【０１１７】
【図１】本発明の構成を示すブロック図
【図２】データ取り出し精度向上のための作業の手順を示す図
【図３】特定検索結果一覧表示処理の手順を示す図
【図４】特定検索処理の手順を示す図
【図５】データ再加工処理の手順を示す図
【図６】Ｅメールデータ再加工処理の手順を示す図
【図７】Ｅメールデータ再加工処理の手順を示す図（続き）
【図８】Ｅメールデータ再加工処理の手順を示す図（続き）
【図９】Ｅメールデータ再加工処理の手順を示す図（続き）
【図１０】ＨＴＴＰ・ＦＴＰデータ再加工処理の手順を示す図
【図１１】ＨＴＴＰ・ＦＴＰデータ再加工処理の手順を示す図（続き）
【図１２】ＨＴＴＰ・ＦＴＰデータ再加工処理の手順を示す図（続き）
【図１３】データ再加工処理時のデータの再生処理の手順を示す図
【図１４】データ再加工処理時に記録されたデータの構成要素図
【図１５】特定検索結果一覧表示からの検索処理の手順を示す図
【図１６】特定検索結果一覧表示からの検索処理の手順を示す図（続き）
【図１７】特定検索処理１の手順を示す図
【図１８】データベース（通信パケットテーブル）の構成要素図
【図１９】通信サマリーデータの構成要素図
【図２０】種別メニュー定義の構成要素図
【図２１】特定検索ＳＱＬ定義の構成要素図
【図２２】ＳＱＬ検索除外定義の構成要素図
【図２３】サイトコード定義の構成要素図
【図２４】検索メニュー定義の構成要素図
【図２５】特定検索ＳＱＬ定義の定義例を示した図
【図２６】特定検索ＳＱＬ定義の定義例を示した図（続き）
【図２７】インターフェイス域の構成要素図
【図２８】特定検索（Ｅメールの題名）結果一覧表示の各行の構成要素図
【図２９】特定検索（Ｅメールの題名とＳＳＬセション確立以外）結果一覧表示の各行の構成要素図
【図３０】特定検索（ＳＳＬセション確立）結果一覧表示の各行の構成要素図
【図１】
2006186953.tif 000003
【図２】
2006186953.tif 000004
【図３】
2006186953.tif 000005
【図４】
2006186953.tif 000006
【図５】
2006186953.tif 000007
【図６】
2006186953.tif 000008
【図７】
2006186953.tif 000009
【図８】
2006186953.tif 000010
【図９】
2006186953.tif 000011
【図１０】
2006186953.tif 000012
【図１１】
2006186953.tif 000013
【図１２】
2006186953.tif 000014
【図１３】
2006186953.tif 000015
【図１４】
2006186953.tif 000016
【図１５】
2006186953.tif 000017
【図１６】
2006186953.tif 000018
【図１７】
2006186953.tif 000019
【図１８】
2006186953.tif 000020
【図１９】
2006186953.tif 000021
【図２０】
2006186953.tif 000022
【図２１】
2006186953.tif 000023
【図２２】
2006186953.tif 000024
【図２３】
2006186953.tif 000025
【図２４】
2006186953.tif 000026
【図２５】
2006186953.tif 000027
【図２６】
2006186953.tif 000028
【図２７】
2006186953.tif 000029
【図２８】
2006186953.tif 000030
【図２９】
2006186953.tif 000031
【図３０】
2006186953.tif 000032