(57)【要約】  データパケットの境界で分割されたパターンを検索するためにコンピュータネットワーク上でデータパケットストリームを検査するための方法及びシステムを開示する。２つ以上のデータパケットがデータパケットストリームにおいて連続するか否かを判断し、連続するデータパケットからのペイロードを結合し、連続するデータパケットからの結合したペイロードを解析し、文字の組み合わせからなる複数のパターンを検索する。結合したデータペイロードの最大の長さは、文字の組み合わせからなる複数のパターンの中の最も長いパターンの文字数よりも１だけ少ない値に設定する。本発明は、コンテンツサーチエンジン及びまたは正規表現エンジンが含んでも良い。また、本発明の別の態様では、データパケットが所定時間以上システム中にあるときは、所定の判断基準に基づきデータパケットを出力データストリームに戻す。
2009510815.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータネットワークにおいて、データパケットの境界に分割されたパターンについて、データパケットストリームを検査する方法であって、
２つ以上のデータパケットがデータパケットストリーム中で連続するか否かを判断するステップと、
連続するデータパケットからのデータペイロードを結合するステップと、
文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを解析するステップとを含み、
前記結合したデータペイロードの最大長は、前記文字の組み合わせの複数のパターンにおいて最大の長さを持つパターンの文字数より１だけ少ない値である
ことを特徴とする方法。
【請求項２】
前記２つ以上のデータパケットがデータパケットストリーム中で連続するか否かを判断するステップは、２つ以上のデータパケットに対する通信プロトコル接続を調査するステップを含む、ことを特徴とする請求項１記載の方法。
【請求項３】
前記通信プロトコル接続は、送信先アドレス、送信先ポート番号、送信元アドレス、送信元ポート番号、及び通信プロトコルのタイプを含む、ことを特徴とする請求項２記載の方法。
【請求項４】
前記通信プロトコルのタイプは、ＴＣＰ、ＵＤＰ、ＡＥＰ、ＡＭＴＰ、ＡＴＰ、ＣＵＤＰ、ＩＬ、ＮＢＰ、ＮｅｔＢＥＵＩ、ＲＴＭＰ、ＳＭＢ、ＳＰＸ、ＳＣＴＰ及びＲＴＰからなるグループから選択される、ことを特徴とする請求項３記載の方法。
【請求項５】
前記文字の組み合わせの複数のパターンはルールテーブルに格納される、ことを特徴とする請求項１記載の方法。
【請求項６】
前記文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを解析するステップは、コンテンツサーチエンジンを利用することを含む、ことを特徴とする請求項１記載の方法。
【請求項７】
前記文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを解析するステップは、正規表現エンジンを利用することを含む、ことを特徴とする請求項１記載の方法。
【請求項８】
前記文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを解析するステップは、コンテンツサーチエンジン及び正規表現エンジンを利用することを含む、ことを特徴とする請求項１記載の方法。
【請求項９】
前記データパケットストリームからの各データパケットからのヘッダを解析し、解析されたデータパケットストリームを生成するステップを含む、ことを特徴とする請求項１記載の方法。
【請求項１０】
前記データパケットストリーム内のデータパケットからの解析されたヘッダ情報が、各データパケットが、少なくとも１つの他のデータパケットと結合されてパターンが解析されるべきか、または、出力データパケットストリームに戻されるべきかのいずれを示しているのかを、排除フィルタにより使用される判断基準に基づき、判断するステップをさらに含む、ことを特徴とする請求項９記載の方法。
【請求項１１】
前記判断基準は、送信先通信プロトコルアドレス、フラグ、及び送信先通信プロトコルポート番号からなるグループから選択される、ことを特徴とする請求項１０記載の方法。
【請求項１２】
前記連続するデータパケットからデータペイロードを結合するステップは、マルチパケット・シグネチャ・スキャナを利用することを含む、ことを特徴とする請求項１記載の方法。
【請求項１３】
マルチパケット・シグネチャ・スキャナは、先入れ先出しメモリバッファを利用する、ことを特徴とする請求項１２記載の方法。
【請求項１４】
前記連続するデータパケットからデータペイロードを結合するステップは、マルチパケット・シグネチャ・スキャナを利用することを含み、前記文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを解析するステップは、コンテンツサーチエンジン及び正規表現エンジンを利用する、ことを特徴とする請求項１記載の方法。
【請求項１５】
前記マルチパケット・シグネチャ・スキャナ、前記コンテンツサーチエンジン及び前記正規表現エンジンは電気的にインタフェースに接続する、ことを特徴とする請求項１４記載の方法。
【請求項１６】
データパケットが前記マルチパケット・シグネチャ・スキャナ内に所定時間の間滞在しているか否かを判断し、これらのデータパケットを前記マルチパケット・シグネチャ・スキャナから移動させるステップをさらに含む、ことを特徴とする請求項１２記載の方法。
【請求項１７】
前記２つ以上のデータパケットがデータパケットストリーム中で連続するか否かを判断するステップは、次の通信プロトコル接続を指し示す情報を検査するステップを含む、ことを特徴とする請求項２記載の方法。
【請求項１８】
前記２つ以上のデータパケットがデータパケットストリーム中で連続するか否かを判断するステップは、送信元アドレス、送信元ポート番号、送信先アドレス、送信先ポート番号、通信プロトコルのタイプ、接続状態及びタイムアウトからなるグループから選択される通信プロトコル接続情報を調査するステップを含む、ことを特徴とする請求項２記載の方法。
【請求項１９】
前記２つ以上のデータパケットがデータパケットストリーム中で連続するか否かを判断するステップは、少なくとも１つのプロトコル接続参照テーブルを利用して、通信プロトコル接続情報を調査するステップを含む、ことを特徴とする請求項２記載の方法。
【請求項２０】
前記少なくとも１つのプロトコル接続参照テーブルは、相互に関連した階層構造を有する複数のプロトコル接続参照テーブルを含む、ことを特徴とする請求項１９記載の方法。
【請求項２１】
前記文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを解析するステップは、少なくとも１つのメモリに格納された第１のデータパケットと入力した第２のデータパケットを含む、連続したデータパケットの組み合わせが、結合されたデータペイロードの最大の長さを超え、かつ前記少なくとも１つのメモリに格納された第１のデータパケットの長さが、前記結合されたデータペイロードの最大の長さよりも小さいと判断したときに、入力した第２のデータパケットと少なくとも１つのメモリに格納された第１のデータパケットの組み合わせが、結合されたデータペイロードの最大長と等しくなるように、前記少なくとも１つのメモリに格納された第１のデータパケットの長さを切り詰めるステップを含み、
前記結合されたデータペイロードの最大長は、前記文字の組み合わせの複数のパターンの最大の長さよりも１だけ小さい値である、
ことを特徴とする請求項１記載の方法。
【請求項２２】
前記文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを解析するステップは、少なくとも１つのメモリに格納された第１のデータパケットと入力した第２のデータパケットを含む、連続したデータパケットの組み合わせが、結合されたデータペイロードの最大の長さを超え、かつ前記少なくとも１つのメモリに格納された第１のデータパケットの長さが、前記結合されたデータペイロードの最大の長さよりも大きいと判断したときに、入力した第２のデータパケットが、前記結合されたデータペイロードの最大長と等しくなるように、前記入力した第２のデータパケットの長さを切り詰めるステップを含み、
前記結合されたデータペイロードの最大長は、前記文字の組み合わせの複数のパターンの最大の長さよりも１だけ小さい値である、
を含む、ことを特徴とする請求項１記載の方法。
【請求項２３】
コンピュータネットワークにおいて、データパケットの境界に分割されたパターンについて、データパケットストリームを検査する方法であって、
２つ以上のデータパケットに対する通信プロトコル接続を調査することにより、２つ以上のデータパケットがデータパケットストリーム中で連続するか否かを判断するステップと、
連続するデータパケットからのデータペイロードを結合するステップと、
コンテンツサーチエンジン及び正規表現エンジンにより、文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを解析するステップとを含み、
前記結合したデータペイロードの最大長は、前記文字の組み合わせの複数のパターンにおいて最大の長さを持つパターンの文字数より１だけ少ない値である
前記通信プロトコル接続は、送信先アドレス、送信先ポート番号、送信元アドレス、送信元ポート番号、及び通信プロトコルのタイプを含む、
ことを特徴とする方法。
【請求項２４】
データパケットの境界に分割されたパターンについて、データパケットを検査するシステムであって、
データパケットの入力ストリームを受信し、２つ以上のデータパケットが連続するか否かを判別する、データパケット解析手段と、
連続するデータパケットからデータペイロードを結合する、マルチパケットシグナチャスキャン手段と、
文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを調査する、データパターン解析手段と、
を備え、
前記結合したデータペイロードの最大長は、前記文字の組み合わせの複数のパターンにおいて最大の長さを持つパターンの文字数より１だけ少ない値である
ことを特徴とするシステム。
【請求項２５】
前記データパケット解析手段はコントローラを含む、ことを特徴とする請求項２４記載のシステム。
【請求項２６】
前記データパケット解析手段はヘッダ解析手段を含む、ことを特徴とする請求項２４記載のシステム。
【請求項２７】
前記データパケット解析手段は２つ以上のデータパケットに対する通信プロトコル接続を調査する、ことを特徴とする請求項２４記載のシステム。
【請求項２８】
前記データパケット解析手段は少なくとも１つのプロトコル接続参照テーブルを用いて２つ以上のデータパケットに対する通信プロトコル接続を調査する、ことを特徴とする請求項２４記載のシステム。
【請求項２９】
前記少なくとも１つのプロトコル接続参照テーブルは、相互に関連した階層構造を有する複数のプロトコル接続参照テーブルを含む、ことを特徴とする請求項２８記載のシステム。
【請求項３０】
前記通信プロトコル接続は、送信先アドレス、送信先ポート番号、送信元アドレス、送信元ポート番号、及び通信プロトコルのタイプを含む、ことを特徴とする請求項２７記載のシステム。
【請求項３１】
前記データパケット解析手段は所定の基準に基づきデータパケットを出力データストリームに戻すことが可能な排除フィルタを含む、ことを特徴とする請求項２４記載のシステム。
【請求項３２】
前記所定の判断基準は、送信先通信プロトコルアドレス、フラグ、送信先通信プロトコルポート番号、及び次の通信プロトコル接続からなるグループから選択される、ことを特徴とする請求項３１記載のシステム。
【請求項３３】
データパケットの入力ストリームはコントローラにより受信され、ヘッダ解析手段により各データパケットからのヘッダ情報が解析され、その後、データパケットの入力ストリームは排除フィルタにより所定の判断基準に基づき解析されて経路づけられる、ことを特徴とする請求項２４記載のシステム。
【請求項３４】
前記マルチパケットシグナチャスキャン手段は先入れ先出しメモリバッファに動作可能に接続されている、ことを特徴とする請求項２４記載のシステム。
【請求項３５】
前記マルチパケットシグナチャスキャン手段は外部メモリに動作可能に接続されている、ことを特徴とする請求項２４記載のシステム。
【請求項３６】
前記マルチパケットシグナチャスキャン手段は先入れ先出しメモリバッファに動作可能に接続され、さらに、前記マルチパケットシグナチャスキャン手段は外部メモリに動作可能に接続されている、ことを特徴とする請求項２４記載のシステム。
【請求項３７】
前記データパターン解析手段はコンテンツサーチエンジンを含む、ことを特徴とする請求項２４記載のシステム。
【請求項３８】
前記データパターン解析手段は正規表現エンジンを含む、ことを特徴とする請求項２４記載のシステム。
【請求項３９】
前記データパターン解析手段は、前記文字の組み合わせの複数のパターンを格納可能なルールテーブルを含む、ことを特徴とする請求項２４記載のシステム。
【請求項４０】
前記データパターン解析手段は、コンテンツサーチエンジン、正規表現エンジン、及び前記文字の組み合わせの複数のパターンを格納可能なルールテーブルを含む、ことを特徴とする請求項２４記載のシステム。
【請求項４１】
前記マルチパケットシグナチャスキャン手段と、コンテンツサーチエンジンと、正規表現エンジンとに動作可能に接続されたインタフェースをさらに含む、ことを特徴とする請求項２４記載のシステム。
【請求項４２】
前記データパケット解析手段と前記データパターン解析手段に動作可能に接続された、出力データストリームを出力する出力バッファをさらに含む、ことを特徴とする請求項２４記載のシステム。
【請求項４３】
データパケットが前記マルチパケットシグナチャスキャン手段内に所定時間の間滞在したか否かを判断し、それらのデータパケットを前記マルチパケットシグナチャスキャン手段から移動させるタイマをさらに含む、ことを特徴とする請求項２４記載のシステム。
【請求項４４】
データパケットの境界に分割されたパターンについて、データパケットを検査するシステムであって、
データパケットの入力ストリームを受信し、通信プロトコル接続を調査することにより２つ以上のデータパケットが連続するか否かを判別する、データパケット解析手段と、
バッファ内の連続するデータパケットからデータペイロードを結合する、マルチパケットシグナチャスキャン手段と、
文字の組み合わせの複数のパターンについて、連続するデータパケットから結合したデータペイロードを調査する、データパターン解析手段と、
を備え、
前記結合したデータペイロードの最大長は、前記文字の組み合わせの複数のパターンにおいて最大の長さを持つパターンの文字数より１だけ少ない値であり、
前記データパターン解析手段はコンテンツサーチエンジン及び正規表現エンジンを含む、ことを特徴とするシステム。
【請求項４５】
ＦＰＧＡ（Field Programmable Gate Array）に電気的に接続されたコントローラをさらに含み、前記ＦＰＧＡはプロトコル接続参照テーブル及びコンテンツサーチエンジンに電気的に接続されたことを特徴とする請求項４４記載のシステム。
【請求項４６】
ＦＰＧＡ（Field Programmable Gate Array）に電気的に接続されたコントローラをさらに含み、前記コントローラはプロトコル接続参照テーブルに電気的に接続され、前記ＦＰＧＡはコンテンツサーチエンジンに電気的に接続されたことを特徴とする請求項４４記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを利用する通信プロトコルに適用するコンテンツサーチエンジンに関し、特に、コンテンツサーチエンジンに１つのデータパケット中に含まれるパターンの検索のみならず、複数のデータパケットに分割されて搬送されたパターンのマッチングをも可能とするアドレス方法に関する。好ましい通信プロトコルは伝送制御プロトコル（ＴＣＰ）であるが、本発明はユーザデータグラムプロトコル（ＵＤＰ）や他の種類のプロトコルに対しても利用できる。
【背景技術】
【０００２】
コンピュータネットワークが通信プロトコルを通じてデータを送信するためにデータパケットを利用することは周知である。通信プロトコルを利用して送信されるデータや情報は分割され、パケット化されて、１つずつネットワークを介して送信される。そしてデータパケットは、目的とする受信装置により受信されてリアセンブル（デパケット化）される。データパケットの間のメッセージの境界は、ソフトウェアアプリケーションにより自動的に設定されるか、または指定される。近年、２つの最も一般的な種類のデータ通信プロトコルに、明示的なメッセージ境界を定義し、識別するユーザデータグラムプロトコル（ＵＤＰ）と、メッセージ境界を利用しない、ストリーム指向プロトコルとも呼ばれる伝送制御プロトコル（ＴＣＰ）とがある。
【０００３】
例えば、ＴＣＰを利用する場合、給与アプリケーションは、雇用者レコード間の境界をマークしないか、または、給与データであるデータストリームのコンテンツを識別しない。ＴＣＰは、データストリームを、少なくとも１つのコンピュータを含んだＴＣＰコンピュータシステム間で伝送されるためにデータパケットに分割される、オクテットまたはバイト列として認識する。ＴＣＰデータパケット（セグメント）は、２つのコンピュータまたはコンピュータシステム間での転送単位である。ＴＣＰシステムは、データを、一度に種々のサイズで１つのパケット（セグメント）にパケット化して送信する。結果として、ソフトウェアアプリケーションが、不可能でない場合でも、１つの通信プロトコル接続に属するいくつかの連続したデータパケットまたは全てのデータパケットをリアセンブルする必要なしに、データを処理することを困難にするような方法で、データストリームが分割され、コンピュータネットワーク上で送信される。データパケットは消失し、抜け落ち、また、順序がバラバラで到着することがあり得るため、データパケットが分割され、独立して送信される場合、さらなる問題が生じる。
【０００４】
各データパケットを同時に監視することによりデータストリーム中で特定のパターンやシグネチャを検索する、コンテンツサーチエンジン、コンテンツフィルタ、ウィルス検出装置、及びウォーム検出装置がある。これらの検索方法の利用において、パターンまたはシグネチャは、それらが複数に分割され、２以上のデータパケットにおいて送信された場合、検出できない。このようなことは、偶然に、または、検出されないことを望む者による悪意により発生する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
データパケットをフィルタするために近年使用されているファイアウォールは、特定のソフトウェアアプリケーションがデータを送受信できるようにするための周知のポート番号及び／またはアドレスに基づいて静的に構成された、ヘッダの特定のエントリに基づき、検出する。しかしながら、同じソフトウェアアプリケーションが、静的に構成されるのではなく、むしろ動的に、さらに他のポート番号及び／または通信プロトコルアドレスを使用するようネゴシエートした場合、ファイアウォールは、各データパケットを深く調査する必要がある。それにより、ネゴシエートされたポート番号やアドレスが適切に認識される。このような深いパケットの調査を行うために、システムは、通信プロトコル接続を評価する深い調査におけるデータペイロードとともに、複数のレベル例えばＬ３−Ｌ７にある特定のヘッダのエントリを認識することにより、最初に論理的に接続状態を確認する必要がある。次に、その適格が通信プロトコル接続状態によって決定される、データまたはパターンを選択的に検索する必要がある。結果として、深いパケットの調査はパケットのリアセンブルとリアセンブルプロセスの全体制御とを必要とする。データまたはパターンのストリームが検索されているにもかかわらず、送信するデータパケットに依存するコンピュータシステムは、対応するデータパケットを、トラヒックの論理的な性質や構造を完全に把握した順番でリアセンブル必要がある。
【０００６】
よって、パケットリアセンブルプロセスはリソースにより駆動されるが、必ずしも複雑ではない。にもかかわらず、そのプロセスは時間を消費し、コンピュータの能力を必要とし、潜在的にＤｏＳ（Denial of Service）攻撃に脆弱である。故に、データパケットを効率的かつ安全にリアセンブルする方法を見出すことが重要である。本発明は、上記の少なくとも１つの問題を解決すべくなされたものである。
【課題を解決するための手段】
【０００７】
本発明は、例えばギガビットでの高速通信での１つの通信プロトコル接続に属し、連続しかつ隣接するデータパケットを系統的にリアセンブルし、パターンマッチング能力が要求されるソフトウェアアプリケーションにより処理可能なデータストリームを生成可能な、革新的かつ効率的なシステム及びプロセスを提供する。具体的に示した、それに限定されない、データパケットを送信する通信プロトコルの例として、ホストをグローバルコンピュータネットワーク（例えばインターネット）に接続するために使用される現実の一連の通信プロトコルである、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）がある。伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）は、データを種々のサイズのデータパケットに分割するナーゲルアルゴリズム（Nagel's Algorithm）を使用してデータを転送するストリームベースプロトコルである。一例として示し、それには限定されない、この種のパターンマッチングソフトウェアの例として、コンテンツサーチエンジン、インターネットのようなグローバルコンピュータネットワークにおけるサーバ上のファイルへの経路を定義するＵＲＬ（Uniform Resource Locator）のようなアドレスのためのフィルタ、ウィルス検出器、ウォーム検出器、侵入検知システム等がある。本発明は、通信プロトコル情報を利用して隣接するデータパケットを解析し、関連するペイロードデータを選択的に調査することを可能とする。
【０００８】
一例として示し、それには限定されない、通信プロトコル情報の例として、配信先アドレス、配信先ポート番号、配信元アドレス、配信元ポート番号、及びプロトコルの種類がある。通信プロトコル情報に基づきデータパケットが隣接すると判断された場合、入力されたパケットペイロードデータと格納されたパケットペイロードデータが結合され、場合によっては、バッファに格納されたペイロード情報の全長がシグネチャの特徴づけに利用される最大の文字数よりも１だけ少ない長さとなるように切り落とされる。１文字だけ減算することにより、２つ以上のパケットに分割された全てのシグネチャを検出できることが保証される。これにより、データパケットの境界を跨って存在するシグネチャの検索を可能とする、隣接するデータパケットのペイロードのデータストリームを提供する。
【０００９】
本発明の一つの態様において、ユニークな通信プロトコル情報を正確に特定し、隣接するデータペイロードを検索のために結合する。本発明の別の態様は、データパケットがフラグや他の条件により与えられる所定の基準に基づいてリアセンブル処理を迂回するようにデータパケットをルーティングすることにより、ＤｏＳ（Denial of Service）攻撃や複雑なアルゴリズムによる攻撃（algorithm complexity attack）に対するさらなる防御を提供する除外フィルタリングを含む。
【００１０】
本発明のさらに別の態様では、システム中で所定時間経過したデータパケットをシステムから消去し、それによりＤｏＳ（Denial of Service）攻撃や複雑なアルゴリズムによる攻撃（algorithm complexity attack）を阻止するように、時間が利用される。
【００１１】
上記の態様は、本発明の無数にある態様のうちのほんの一部であり、本発明の無数にある態様の全てを含んで列挙したものであると考えるべきではない。当業者にとって上記の態様及び他の態様は、後述する開示及び添付の図面を考慮して明らかになるであろう。
【発明を実施するための最良の形態】
【００１２】
以下の詳細な説明では、本発明を十分に理解するための多くの特定の詳細について述べている。しかし、そのような特定の詳細を用いずに本発明が実施できることは当業者であれば理解できる。また、本発明を不明確にすることから、周知の方法、手順及び構成要素については詳述していない。例えば、本発明は、データパケットを送信する任意の種類の通信プロトコルに仮想的に適用でき、伝送制御プロトコル（ＴＣＰ）に限定されない。
【００１３】
添付の図面において、同じ参照番号は同じ要素を示す。最初に参照される図１は、本発明で利用され、符号「１０」で示す、データパケット指向コンピュータネットワークを示した図である（例示であって、その内容に限定されない）。インターネットのようなグローバルコンピュータネットワーク１３にイーサネットケーブルのような電気的接続部１４を介して接続された、符号「１２」で示す複数のイントラネットシステムがある。イントラネットシステムのそれぞれは、組織に属する通信プロトコルに基づいたネットワークであり、かつ、その組織のメンバ、雇用者、その他、承認されていなアクセスを排除するためのインターネットを取り囲むファイアウォールにおいて承認された者のみがアクセスできるものである。それに限定するものではない一例としての各イントラネットシステム１２の構成要素は、通信プロトコルネットワークノード１６、例えばＴＣＰ／ＩＰを含むことができる。
【００１４】
通信プロトコルネットワークノード１６は、電気的接続部すなわちケーブル１４に接続されたイーサネット（ＥＮＥＴ）２６を含んでもよい。イーサネット（ＥＮＥＴ）２６は最も広く利用される、途中でハブやスイッチを用いたスター構成を有するローカルエリアネットワーク（ＬＡＮ）のアクセス方法である。このため、イーサネット（ＥＮＥＴ）２６は好ましいものであるが、他の多くの種類のコンピュータネットワークでもよい。イーサネット（ＥＮＥＴ）２６は、ノードの物理アドレスを取得するために利用される、ＴＣＰ／ＩＰのようなアドレス解決プロトコル（ＡＲＰ）機能２４と電気通信を行う。クライアントステーションは、通信対象のターゲットノードのＩＰアドレスを用いてＡＲＰリクエストをネットワークに要求し、そのアドレスを有するノードは物理アドレスを返信することで応答し、それにより、データパケットが送信可能となる。イーサネット（ＥＮＥＴ）２６はまた、ユーザデータグラムプロトコル（ＵＤＰ）２０や伝送制御プロトコル（ＴＣＰ）１８（例示であり、これに限定されない）のようなパケット伝送プロトコルと電気通信するネットワーク層のプロトコルであるインターネットプロトコル（ＩＰ）２２とも電気通信を行う。
【００１５】
図２は、本発明に係るマルチパケット・シグネチャ・スキャンシステムの好ましい実施形態を説明した図（例示であり、これに限定されない）である。マルチパケット・シグネチャ・スキャンシステムは符号「２８」で示される。ユーザデータグラムプロトコル（ＵＤＰ）のような多くの種類のデータパケット伝送プロトコルが使用できるが、伝送制御プロトコル（ＴＣＰ）を利用することが好ましい。他のデータ通信プロトコルには、ＡＥＰ、ＡＭＴＰ、ＡＴＰ、ＣＵＤＰ、ＩＬ、ＮＢＰ、ＮｅｔＢＥＵＩ、ＲＴＭＰ、ＳＭＢ、ＳＰＸ、ＳＣＴＰ、ＲＴＰがある。但し、これらに限定されるものではない。
【００１６】
入力データストリーム３２は、符号「３４」で示されるハードウェアモジュールすなわちコアにより受信される。ハードウェアモジュール３４は、コントローラ５６と、ヘッダ解析部４６と、排除フィルタ４８と、正規表現エンジン４２と、コンテンツサーチエンジン４４と、出力バッファ３８とを含む。
【００１７】
入力データストリーム３２は、ハードウェアモジュール３４に入力するとコントローラ５６により受信される。コントローラ５６は、例えばギガビットイーサネットメディアアクセスコントローラ（Gigabit Ethernet Media Access Controller）である。但し、これに限定されるものではない。データストリームがコントローラにより受信されると、データストリームはヘッダ解析部４６に送信される。ヘッダ解析部４６は、データパケットストリーム中の各データパケットからヘッダ情報を取り出し、解析する。解析されたデータは、その後排除フィルタ４８に送られる。排除フィルタ４８は、ルールテーブル４０に格納された種々の所定の判断基準に基づき、解析されたデータをフィルタリングする。この判断基準は、送信先通信プロトコルアドレス、フラグ、及び／または送信先通信プロトコルポート番号を含むことができる（例示であって、これに限定されるものではない）。その判断基準を満たすフィルタリングされたデータストリームはマルチパケット・シグネチャ・スキャナ３０により転送されて処理され、その判断基準を満たさないフィルタリングされたデータストリームは出力バッファ３８に直接送られる。出力バッファ３８は、出力データストリーム３６をコンピュータネットワークインタフェースへ定期的に送信する。
【００１８】
２つのデータメッセージが異なる処理速度を持つ２つの領域で交差する場合、読み出しと書き込みフェーズで同期をとる必要がある。これを「読み出し及び書き込み問題」と称する。読み出しと書き込みを同期させることで、１つの領域において、上書きして次の領域へオーバーフローしないようにデータが早く書き込まれないようにすることを保証し、かつ、読み出し処理が速すぎてデータが利用できない（書き込まれていない）ようにならないことを保証する。よって、先入れ先出し（ＦＩＦＯ）キューバッファ５２が有効で効率的な解決策として利用できる。入力データストリーム３２に含まれる論理情報に基づき、マルチパケット・シグネチャ・スキャナ３０は、入力したデータパケットを前に受信したデータパケットと合わせて分類して順番に再配置する。マルチパケット・シグネチャ・スキャナ３０は外部メモリ５４に接続されるのが好ましい。
【００１９】
マルチパケット・シグネチャ・スキャナ３０により再配置されたデータパケットは正しく並び替えられ、正規表現エンジン４２及び／またはコンテンツサーチエンジン４４により処理されるのに適したものとなる。基本的に、正規表現エンジン４２は特定のパターンに該当するテキストを検索する。コンテンツサーチエンジンの一例は、これに限定されるものではないが、２００３年１１月６日に公開された米国特許出願公開第２００３−０２０８４８７号に開示されており、その内容は引用することで本明細書中に組み入れられる。
【００２０】
マルチパケット・シグネチャ・スキャナ３０、正規表現エンジン４２及びコンテンツサーチエンジン４４は、マルチパケット・シグネチャ・スキャナ３０が順序がバラバラの送信されたデータパケットを処理する必要が有るか否かを判断するために、例えばコンピュータ処理ユニットのような、インタフェース５０を用いたホストから動的に構成される。マルチパケット・シグネチャ・スキャナ３０はまた、インタフェース５０または、Ｄｏｓ（Denial of Service）攻撃を引き起こす、メモリ、バッファ、及びその他のデータ記憶手段を消尽させるような例外的なセキュリティの問題が発生した場合に、他の装置を介してホストへ通知信号を送信するよう構成される。
【００２１】
図３は、符号「７４」で示す、データパケットのビットレベルでの論理構造を示す。データパケットにより利用され得る通信プロトコルの例（一例であって、それに限定されるものではない）はＴＣＰ／ＩＰである。入力データパケット３２の一部分である入力データパケットのそれぞれは、適切なＴＣＰ／ＩＰ接続の図２に示すように、マルチパケット・シグネチャ・スキャナ３０に入力し、有効なインターネットプロトコル（ＩＰ）ヘッダ６０を含み、さらに有効なＴＣＰヘッダ６２を含むことがある。
【００２２】
他の情報に加えて、ＩＰヘッダ６０は、一般に３２ビット長のインターネット（ＩＰ）送信元アドレス６４（「ＳＲＣＩＰ」と略す）と、一般に３２ビット長のインターネット（ＩＰ）送信先アドレス６６（「ＤＥＳＴＩＰ」と略す）とを含む。
【００２３】
ＴＣＰヘッダ６２は、通常、一般に１６ビット長のＴＣＰ送信元ポート番号６８（「ＳＰＯＲＴ」と略す）と、一般に１６ビット長のＴＣＰ送信先ポート番号７０（「ＤＰＯＲＴ」と略す）と、一般に１６ビット長のＴＣＰシーケンス番号７２（「ＴＳＥＱＮ」と略す）とを含む。伝送制御プロトコル（ＴＣＰ）はクライアント−サーバ間の信頼性の高い接続を提供する。ＴＣＰ接続はクライアントと所定のサーバの間で確立される。クライアントは、ＴＣＰ接続によりサーバとデータ交換ができ、その後、ＴＣＰ接続を終了できる。ＴＣＰは、所定のコンピュータまたはコンピュータシステム上で複数のアプリケーションプログラムが、同時に通信を行うことを可能とするとともに、入力したデータパケットを１つのコンピュータ内の複数のソフトウェアプログラムにデマルチプレクスすることを可能とする。このため、ＴＣＰは、ＴＣＰ送信先ポート番号（ＤＰＯＲＴ）７０をインターネットプロトコル（ＩＰ）送信先アドレス（ＤＥＳＴＩＰ）６６とともに利用し、コンピュータにおける最終的な送信先を一意に特定する。ＴＣＰ送信先ポート番号（ＤＰＯＲＴ）７０とインターネットプロトコル（ＩＰ）送信先アドレス（ＤＥＳＴＩＰ）６６の組み合わせを「送信先エンドポイント」と称す。このことは「送信元エンドポイント」についても同様であり、それは、ＴＣＰ送信元ポート番号（ＳＰＯＲＴ）６８とインターネットプロトコル（ＩＰ）送信元アドレス（ＳＲＣＩＰ）６４の組み合わせである。ＴＣＰ接続は１対のエンドポイント、すなわち、（ＴＣＰ送信元ポート番号（ＳＰＯＲＴ）６８とインターネットプロトコル（ＩＰ）送信元アドレス（ＳＲＣＩＰ）６４）と（ＴＣＰ送信先ポート番号（ＤＰＯＲＴ）７０とインターネットプロトコル（ＩＰ）送信先アドレス（ＤＥＳＴＩＰ）６６）により特定される。
【００２４】
データパケットの伝送中、ＴＣＰは、データストリームを、伝送用にパケットすなわちセグメントに分割されたバイトシーケンスとして監視する。ＴＣＰは、ＴＣＰシーケンス番号（ＴＳＥＱＮ）７２を送信される各バイトに関連付けることにより、データを順に並べる。例えば、アプリケーションが４０９６バイトをＴＣＰ接続に書き込むと、ＴＣＰは４つのセグメントを送信する。セグメントは１つのデータパケット中で送信または受信されるデータの単位として定義される。一例として（これに限定されるものではないが）、第１のセグメントはシーケンス番号１−１０２４を持つデータを含み、第２のセグメントはシーケンス番号１０２４−２０４８を持つデータを含み、第３のセグメントはシーケンス番号２０４８−３０７２を持つデータを含み、第４のセグメントはシーケンス番号３０７２−４０９６を持つデータを含むことができる。ＴＣＰシーケンス番号（ＴＳＥＱＮ）７２は、セグメント中の送信側のバイトストリームのデータにおける位置を特定する。シグネチャの全部または一部を格納できるデータは、符号「７６」により特定されるペイロードデータ内に位置する。また、ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、及びＦＩＮのような通信プロトコルの接続状態７８や、ＴＣＰ、Window８０のような通信プロトコルの接続を示す一連のフラグがある。
【００２５】
マルチパケット・シグネチャ・スキャンシステム２８の非常に重要な特徴は、ウィルスやウォームを示す悪意のあるパターンやシグネチャを、それらが１つのデータパケット中に含まれていても複数のパケットに分割されて送信されていても再構築できるように、セグメントを効率的にリアセンブルすることである。さらに、パターンの検出は、コンテンツサーチエンジン４４及び正規表現エンジン４２内でなされる。パターンの再構築は慎重なセグメントのリアセンブルを要する。
【００２６】
図４は、符号９０で示す、マルチパケット・シグネチャ・スキャンシステム２８に入力する代表的な３つのパケットの概念図である。入力データストリーム３２は図１にも示されており、例えば、イーサネットフレームのようなデータパケットの形式でマルチパケット・シグネチャ・スキャンシステム２８に入力する。例えば、イーサネットフレーム１０４、１０６、１０８はマルチパケット・シグネチャ・スキャンシステム２８に入力し、それぞれ、イーサネットフレームに関連するＬ２ヘッダ１１０と、インターネットプロトコル（ＩＰ）ヘッダ６０に関連するＬ３ヘッダ１１２と、ＴＣＰヘッダ６２に関連するＬ４ヘッダ１１４とを含む。連続して伝送されるビットストリームであるファーストフレームチェックシーケンス（ＦＣＳ）１０７が設けられている。ファーストフレームチェックシーケンス（ＦＣＳ）は伝送されるシリアルデータに対して計算される。ファーストフレームチェックシーケンス（ＦＣＳ）１０７の結果の補数がシリアルストリームに付加され、その後にフラグシーケンスが続く。この動作がファーストフレームチェックシーケンス（ＦＣＳ）１０７の補数に対してなされることで、良好なデータパケット、例えば、イーサフレームを示すパターンが生じる。これはエラー検出に使用される。
【００２７】
最初に入力するイーサネットフレーム１０４はペイロードデータ７６において文字列”Ｓｉｇｎ”１００を含む。さらに、イーサネットフレーム１０４が解析され、その結果、ペイロードデータ７６が抽出されてコンテンツサーチエンジン４４に送られる。ルールテーブル４０はコンテンツサーチエンジン４４に動作可能に接続されており、”Ｓｉｇｎａｔｕｒｅ  １”、”Ｓｉｇｎａｔｕｒｅ  ２”、”Ｓｉｇｎａｔｕｒｅ  １００”のような検索されるべき文字パターンを含んでいる。最初に入力するイーサネットフレーム１０４のペイロードデータ７６は図２に示すようにマルチパケット・シグネチャ・スキャンシステム２８を通過するが、一致するパターンがなく、ルールテーブル４０内にある完全なパターンがコンテンツサーチエンジン４４の検出機構４３によりペイロードデータ７６中に検出されないため、検出されない。
【００２８】
２番目に入力するイーサネットフレーム１０６はペイロードデータ７６において文字パターンのいずれの部分も含まないが、同様の方法で処理される。さらに、イーサネットフレーム１０６が解析され、その結果、ペイロードデータ７６が抽出されてコンテンツサーチエンジン４４に送られる。ルールテーブル４０はコンテンツサーチエンジン４４に動作可能に接続されており、”Ｓｉｇｎａｔｕｒｅ  １”、”Ｓｉｇｎａｔｕｒｅ  ２”、”Ｓｉｇｎａｔｕｒｅ  １００”のような検索されるべき文字パターンを含んでいる。よって、２番目に入力するイーサネットフレーム１０６も、同様に、図２に示すようにマルチパケット・シグネチャ・スキャンシステム２８を通過するが、ルールテーブル４０内にあるパターンがコンテンツサーチエンジン４４の検出機構４３によりペイロードデータ７６中に検出されないため、検出されない。
【００２９】
３番目に入力するイーサネットフレーム１０８も同様の方法で処理される。３番目のイーサネットフレーム１０８もまた解析され、その結果、ペイロードデータ７６が抽出されてコンテンツサーチエンジン４４に送られる。３番目のイーサネットフレーム１０８はペイロードデータ７６中に文字列”ａｔｕｒｅ  １００”を含んでいる。前述のように、ルールテーブル４０はコンテンツサーチエンジン４４に動作可能に接続されており、”Ｓｉｇｎａｔｕｒｅ  １”、”Ｓｉｇｎａｔｕｒｅ  ２”、”Ｓｉｇｎａｔｕｒｅ  １００”のような検索されるべき、事前に定義木された文字パターンの検索を可能とする。よって、３番目に入力するイーサネットフレーム１０８も、同様に、図２に示すようにマルチパケット・シグネチャ・スキャンシステム２８を通過するが、ルールテーブル４０内にある完全なパターンがコンテンツサーチエンジン４４の検出機構４３によりペイロードデータ７６中に検出されないため、検出されない。
【００３０】
図５は、図４と同様の仮想的な概念図であり、符号「９１」で示される。図５は、マルチパケット・シグネチャ・スキャンシステム２８に入力する代表的な３つのパケットの高いレベルの概念図であり、図２に示され、コンテンツサーチエンジン４４に送信される前に、入力するイーサフレーム１０４、１０６、１０８を受信するよう配置されたマルチパケット・シグネチャ・スキャナ３０を含む。
【００３１】
しかしながら、入力するイーサフレーム１０４、１０６、１０８のそれぞれは、マルチパケット・シグネチャ・スキャナ３０により、例えば伝送制御プロトコル（ＴＣＰ）のようなプロトコル接続により識別される。例えば、最初に入力するイーサフレーム１０４と３番目に入力するイーサフレーム１０８は双方とも同じプロトコル接続１１７によりセッションＩＤ１として識別され、２番目に入力するイーサフレーム１０６はプロトコル接続１１８によりセッションＩＤ２として識別される。よって、同じプロトコル接続１１７からのペイロードデータ７６が最初に入力するイーサフレーム１０４と３番目に入力するイーサフレーム１０８の間で合成されると、その結果にパターン”Ｓｉｇｎａｔｕｒｅ  １００”が含まれる。それは、ルールテーブル４０内のエントリ１１６と照合されて、コンテンツサーチエンジン４４により肯定的に識別される。
【００３２】
プロトコル接続１１８により識別される、２番目に入力するイーサフレーム１０６からの他のペイロードは、符号「１１２」で示され、コンテンツサーチエンジン４４に入力されることができるが、その検索結果は否定的となる。
【００３３】
図６に示すように、プロトコル接続、例えば、符号「１２０」で示すセッションＩＤが、それに関連する入力データパケット、例えば、イーサネットフレームを示すために利用されている。ＴＣＰ接続（一例であり、これに限定するものではない）に使用された場合、セッションＩＤ１２０は、送信先ＩＰアドレス１２４、送信先ポート番号１２６、送信元ＩＰアドレス１２８、送信元ポート番号１３０、例えばＴＣＰのようなプロトコルタイプ１３２の組みあわせからなるユニークな識別子である。この例（一例であり、これに限定するものではない）では、ＩＰアドレス１３６、及び３つの送信先ポート１３８、１４０、１４２を有するサーバホスト１３４が示されている。また、ＩＰアドレス１４６と、第１の送信元ポート１４８及び第２の送信元ポート１５０を有する第１のクライアントホスト１４４が示されている。また、ＩＰアドレス１５４と、第２の送信元ポート１５６を有する第２のクライアントホスト１５２が示されている。
【００３４】
送信先ＩＰアドレス１２４、送信先ポート番号１２６、送信元ＩＰアドレス１２８、送信元ポート番号１３０、例えばＴＣＰのようなプロトコルタイプ１３２の任意の組みあわせにより、データパケットが隣接するか否かを確認するために使用できるユニークな識別子が得られる。
【００３５】
第１の通信プロトコル接続の例が符号「１６０」で示されている。符号「１６２」は「セッション１」としてのセッションＩＤを示し、符号「１６４」は「ＴＣＰ」としてのプロトコルタイプを示す。送信先ＩＰアドレス１６６がサーバホスト１３４のＩＰアドレス１３６から得られる。送信先ポート番号１６８もまたサーバホスト１３４から得られ、符号「１３８」で示される。送信元ＩＰアドレス１７０は第１のホストクライアント１４４に対するＩＰアドレス１４６から得られ、送信元ポート番号１７２は第１のホストクライアント１４４からの送信元ポート番号１４８から得られる。
【００３６】
第２の通信プロトコル接続の例が符号「１７４」で示されている。符号「１７２」は「セッション２」としてのセッションＩＤを示し、符号「１７８」は「ＴＣＰ」としてのプロトコルタイプを示す。送信先ＩＰアドレス１８０がサーバホスト１３４のＩＰアドレス１３６から得られる。送信先ポート番号１８２もまたサーバホスト１３４から得られ、符号「１４０」で示される。送信元ＩＰアドレス１８４は第１のホストクライアント１４４に対するＩＰアドレス１４６から得られ、送信元ポート番号１８６は第１のホストクライアント１４４からの送信元ポート番号１５０から得られる。
【００３７】
第３の通信プロトコル接続の例が符号「１８８」で示されている。符号「１９０」は「セッション３」としてのセッションＩＤを示し、符号「１９２」は「ＴＣＰ」としてのプロトコルタイプを示す。送信先ＩＰアドレス１９４がサーバホスト１３４のＩＰアドレス１３６から得られる。送信先ポート番号１９６もまたサーバホスト１３４から得られ、符号「１４２」で示される。送信元ＩＰアドレス１９８は第２のホストクライアント１５４に対するＩＰアドレス１５２から得られ、送信元ポート番号１９９は第２のホストクライアント１５２からの送信元ポート番号１５６から得られる。
【００３８】
結果として、コンテンツサーチエンジン４４が文字列中のパターンを認識するためには、少なくとも２つのデータパケットに対する通信プロトコル接続が連続するか否かを判定するための機構が必要となる。図３に示すように、パケットヘッダ情報７４が、２つ以上のデータパケットが連続するか否かを判断する。よって、マルチパケット・シグネチャ・スキャナ３０が、２つ以上のデータパケットに分割されて配信されている可能性のあるパターンすなわちシグネチャを発見するために、複数のデータパケットからの情報を再構築する機構として動作する。
【００３９】
前述のように、プロトコル伝送接続、例えばＴＣＰは、送信先ＩＰアドレス１２４、送信先ポート番号１２６、送信元ＩＰアドレス１２８、送信元ポート番号１３０、例えばＴＣＰのようなプロトコルタイプ１３２の組みあわせによって、一意に識別される。図７に示すように、伝送制御プロトコル（ＴＣＰ）に対する、標準的でかつ周知の接続状態を示す図が符号「２００」で示されている。コンピュータ、例えば、クライアント（ホスト）は、ＳＹＮ２０２のようなフラグとともにパケットを送信することにより、ＴＣＰのようなプロトコル伝送接続を確立できる。別のコンピュータ、例えば、サーバ（ホスト）は、クライアントホスト２０４から送信された、フラグＳＹＮと、対応するパケットとを受信したときに、ＡＣＫのようなフラグを送信することによって、プロトコル伝送接続を確認できる。このＴＣＰパケットの交換の最終的な結果は、送信先ＩＰアドレス（例えば、サーバに対する128.192.6.2）と、送信先ポート番号（例えば、サーバの機構２３において割当られた番号）と、送信元ＩＰアドレス（例えば、元のクライアントのＩＰアドレス、例えば、128.192.6.7）と、送信元ポート番号（例えば、サーバの機構５０８２において割当られた番号）とによって一意に識別されるＴＣＰ接続である。この特定の組み合わせは、図６において符号「１６２」で示され、「セッション１」と名付けられる。同じ組み合わせを持つ将来のデータパケットは同じ接続に属すると見なされる。データパケットをリアセンブルするために、マルチパケット・シグネチャ・スキャナ３０は図５に示すようにメモリ内に少なくとも２つの連続するデータパケットを格納する。
【００４０】
図８において、マルチパケット・シグネチャ・スキャナ３０に対する接続テーブルにおけるエントリが例示され、それは符号「２１０」により示されている。最初の構成要素は、送信先アドレス１２４、送信先ポート番号１２６、送信元アドレス１２８、送信元ポート番号１３０を含む、前述の組みあわせ２１２である。特定のプロトコル接続（例えば、セッション）がいつ登録され、生成されたかを示すためのタイムエントリを与えるタイムスタンプ２１４が示されている。タイムスタンプ２１４の目的は、マルチパケット・シグネチャ・スキャナ３０が、通信プロトコル接続（例えば、セッション（マルチパケット・シグネチャ・システム２８中に長い期間滞在する））を処理できるようにすることである。結果として、リソースを消尽させるための偽の通信プロトコル接続を生成することによるＤｏｓ攻撃を実行する企てを阻止できる。
【００４１】
その後に、次のプロトコル接続（例えば、セッション番号２１６）を指し示すデータが続く。それは、前のプロトコル接続（例えば、セッション番号）と同じかまたはそれに連続する番号であるべきである。それは、次の入力するパケットが正しく、図２に示すようなマルチパケット・シグネチャ・スキャナ３０用のＦＩＦＯキューバッファ５２に格納されるべき次のプロトコル接続（例えばセッション番号）であるべきか否かを判断するためのものである。
【００４２】
次に、接続追跡情報２１８が続く。接続追跡情報２１８は、送信元及び送信先インターネットプロトコル（ＩＰ）アドレス、ポート番号、プロトコルタイプ、接続状態及びタイムアウトのような、メモリテーブル内の接続に関するステート情報を維持するための機能である。
【００４３】
図２に示すように、外部メモリ５４内に、通信プロトコル接続ペイロードデータが格納されるバッファがある。これは、符号「２２０」で示され、”ＳｉｇＢｕｆ”と名付けられている（例示であって、これに限定されるものではない）。このバッファ”ＳｉｇＢｕｆ”２２０のサイズは、ルールテーブル４０からのシグネチャの特徴づけにおいてコンテンツサーチエンジン４４により利用される最大の文字数に応じて変化する。ルールテーブル４０からのシグネチャの特徴づけにおいてコンテンツサーチエンジン４４により利用される最大の文字数をＬsigと表す（例示であって、これに限定されるものではない）。バッファ２２０（例えば、Ｓｉｇｂｕｆ）のサイズは、ルールテーブル４０からのシグネチャの特徴づけにおいてコンテンツサーチエンジン４４により利用される文字の最大数、例えばＬsigから１文字分だけ減じた値とする。１文字分減じることで、２つ以上のデータパケットに分割された全てのシグネチャを検出することが保証される。
【００４４】
図９において、マルチパケット・シグネチャ・スキャナ用の接続テーブルにおいて、通信プロトコル接続情報を格納する階層的なメモリ構造が符号２４０で示されている。これは、図８に示す通信プロトコル接続追跡情報とデータをバッファ２２０（例えば、Ｓｉｇｂｕｆ）内に保持する。階層的なメモリ構造に関連して、符号「２４２」、「２４４」、「２４６」でそれぞれ示される３レベルのアドレッシング方法がある。
【００４５】
第１のレベルのアドレッシング方法（例示であって、これに限定されるものではない）は、第２の所定の長さ（例えば、１６ビット）を持つ送信先ポート番号７０（ＤＰＯＲＴ）と、第１の所定の長さ（例えば、３２ビット）を持つインターネットプロトコル（ＩＰ）送信先アドレス６６（ＤＥＳＴＩＰ）と、インターネットプロトコル（ＩＰ）送信先アドレス６６と送信先ポート番号７０のビットの組み合わせとに関する情報を含み、送信先ポート番号７０はハッシュ関数と組み合わされてユニークな第１の数２４８（例えば３２ビット）を生成する。ハッシュ関数は、大きな領域から小さな領域へ写像する数学的な関数であって、潜在的に長いメッセージを、”メッセージダイジェスト”や”ハッシュ値”や後段のアルゴリズムへ入力するのに十分に小さい値に変換する。
【００４６】
得られたハッシュ値２４８は、第２レベルのテーブル２４４の先頭を差し示すアドレスである。第２レベルのテーブル２４４の内部において、送信元番号５６（ＳＰＯＲＴ）及びインターネットプロトコル（ＩＰ）送信元アドレス５４のハッシュ値を計算し、前述のように、ユニークな第２の数２５０（例えば、３２ビット長）を生成する。このユニークな第２の数２５０第３レベルのテーブル２４６のアドレスとなる。バッファ２２０（例えば、Ｓｉｇｂｕｆ）及び他の情報の最終的な位置を求めるために、マルチパケット・シグネチャ・スキャナ３０用のＦＩＦＯキューバッファ５２に格納された、次の又は予想されるプロトコル接続（例えば、セッション番号）のハッシュ値が計算され、バッファ２２０（例えば、Ｓｉｇｂｕｆ）及び他の情報が格納された場所、すなわち、第３レベルのテーブルの物理アドレスを示すユニークな第３の数２５２が生成される。
【００４７】
図１０において、バッファ２２０（例えば、Ｓｉｇｂｕｆ）における、マルチパケット・シグネチャ・スキャナ３０による解析に必要な情報の最大量について検討している。複数のデータパケットに対するスキャン時では、マルチパケット・シグネチャ・スキャナ３０は、図２に示すルールテーブル４０に格納される最長のパターン（「ルールテーブルからのシグネチャ」と称す）における文字数の最大値（例えば、Ｌsig）から、１文字だけ少ない長さのデータを格納する必要がある。
【００４８】
入力データパケットのペイロードデータの長さに依存して、マルチパケット・シグネチャ・スキャナ３０に格納されるべきバイト／文字の数の計算方法の決定に関して３つのシナリオがある。
【００４９】
第１のシナリオは式２６０で指定される式により示され、それは、入力ペイロードデータ２６２の長さとバッファ２６４（例えば、Ｓｉｇｂｕｆ）に格納されるペイロード情報の長さの合計が、図２に示すルールテーブル４０に格納される最長のパターン（例えば「シグネチャ」と称す）２６６の文字数の最大値（例えば、Ｌsig）から１文字分だけ減じた値よりも小さい場合である。結果として、格納されているペイロードデータ２６４の長さが入力ペイロードデータ２６２の長さに合算され、入力ペイロードデータ２６２の長さが、既にバッファ２６４に格納されているペイロードデータ情報に加算（連結）され、バッファ２７０（例えば、Ｎｅｗ Ｓｉｇｂｕｆ）に新しい長さのペイロード情報が格納される。
【００５０】
第２のシナリオは式２７２で指定される式により示され、それは、入力ペイロードデータ２６２の長さとバッファ２６４（例えば、Ｓｉｇｂｕｆ）に格納されるペイロード情報の長さの合計が、図２に示すルールテーブル４０に格納される最長のパターン（「シグネチャ」と称す）２６６の文字数の最大値（例えば、Ｌsig）から１文字分だけ減じた値以上で、かつ、バッファ２６４（例えば、Ｓｉｇｂｕｆ）に格納されるペイロード情報の長さが、ルールテーブル４０に格納される最長のパターン（「シグネチャ」と称す）２６６の文字数の最大値（例えば、Ｌsig）から１文字分だけ減じた値よりも小さい場合である。結果として、格納されているペイロードデータ２６４の長さは、入力ペイロードデータ２６２の長さとバッファ２６４（例えば、Ｓｉｇｂｕｆ）に格納されるペイロード情報の長さの合計から、ルールテーブル４０に格納される最長のパターン（例えば「シグネチャ」と称す）２６６の文字数の最大値（例えば、Ｌsig）から１文字分だけ少ない値を減じて得られる値と同じ長さ分だけ、データの先頭から切り詰められる。これにより、新たな長さの格納されたペイロードデータ２７６が形成される。そして、入力ペイロードデータ２６２が、切り詰められ、バッファ２６４に格納されているペイロードデータ２７４に加算（連結）され、バッファ２７６（例えば、Ｎｅｗ Ｓｉｇｂｕｆ）に新しい長さのペイロード情報が格納される。
【００５１】
第３のシナリオは式２８０で指定される式により示され、それは、入力ペイロードデータ２６２の長さとバッファ２６４（例えば、Ｓｉｇｂｕｆ）に格納されるペイロード情報の長さの合計が、図２に示すルールテーブル４０に格納される最長のパターン（「シグネチャ」と称す）２６６の文字数の最大値（例えば、Ｌsig）から１文字分だけ減じた値以上で、かつ、入力ペイロードデータ２６２の長さが、ルールテーブル４０に格納される最長のパターン（「シグネチャ」と称す）２６６の文字数の最大値（例えば、Ｌsig）から１文字分だけ減じた値よりも大きい場合である。結果として、入力ペイロードデータ２６２の長さは、入力ペイロードデータ２６２の長さから、ルールテーブル４０に格納される最長のパターン（例えば「シグネチャ」と称す）２６６の文字数の最大値（例えば、Ｌsig）から１文字分だけ少ない値を減じて得られる値と同じ長さ分だけ、データの先頭から切り詰められる。これにより、バッファ２８４（例えば、Ｎｅｗ Ｓｉｇｂｕｆ）に新しい長さのペイロード情報が格納される。
【００５２】
図１１において、図１に示すデータパケット指向コンピュータネットワーク１０と適合し、符号「８００」で示されるデータパケット指向コンピュータネットワークにおいて送受信される入力ＴＣＰデータパケットが示されている（一例として示したものであり、これに限定するものではない）。符号「１２」で示される、グローバルコンピュータネットワーク１３（例えばインターネット）に電気接続部１４（イーサケーブル）を介して接続する複数のイントラネットシステムが存在する。各イントラネットシステム１２の構成要素は、ＴＣＰ／ＩＰのような通信プロトコルネットワークノード１６を含むことができる（例示であり、これに限定するものではない）。
【００５３】
符号「８０２」により示され、第１のクライアントアプリケーション通信プロトコルネットワークノード８０４を含む第１のイントラネットシステムがある。ＩＰアドレスは符号「８０６」で示され、例えば、209.144.58.10である。第１のクライアントアプリケーション通信プロトコルネットワークノード８０４は例として示すポート番号８０８（例えば２０９２）を含む。第１のイントラネットシステム８０２が第１のデータパケット８４０と第２のデータパケット８４２を送信している点が示されている。
【００５４】
符号「８１０」により示され、第２のクライアントアプリケーション通信プロトコルネットワークノード８１２及び第３のクライアントアプリケーション通信プロトコルネットワークノード８１４を含む第２のイントラネットシステムがある。ＩＰアドレスは符号「８１６」で示され、例えば、209.144.58.20である。第２のクライアントアプリケーション通信プロトコルネットワークノード８１２は、例として示す第１のポート番号８１８（例えば２０９０）と例として示す第２のポート番号８２０（例えば２０９１）を含む。第３のクライアントアプリケーション通信プロトコルネットワークノード８１４は、例として示す第１のポート番号８２２（例えば２０９２）を含む。第２のイントラネットシステム８１０が、第３のデータパケット８４４、第４のデータパケット８４６、第５のデータパケット８４８、第６のデータパケット８５０及び第７のデータパケット８５２を送信している点が示されている。
【００５５】
符号「８２４」により示され、サーバアプリケーション通信プロトコルネットワークノード８２６を含む第３のイントラネットシステムがある。ＩＰアドレスは符号「８２８」で示され、例えば、64.233.161.147である。サーバアプリケーション通信プロトコルネットワークノード８２４は、例として示すポート番号８３０（例えば８０）を含む。入力データパケットは、第１のデータパケット８４０、第３のデータパケット８４４、第６のデータパケット８５０、第２のデータパケット８４２、第５のデータパケット８４８、第４のデータパケット８４６、第７のデータパケット８５２の順に受信される。
【００５６】
送信先ＩＰアドレス、送信先ポート番号、送信元ＩＰアドレス、送信元ポート番号の任意に組み合わせることで、データパケットが隣接するか否かを確認する際に利用されるユニークな識別子（例えば符号「８６０」で示されるセッション）を与えることができる。
【００５７】
第１の組み合わせの例は符号「８６２」で示される。セッションＩＤ「Ｓ１」が符号「８６４」で示される。送信先ＩＰアドレス８６６及び送信先ポート番号８６８はサーバアプリケーション通信プロトコルネットワークノード８２６のＩＰアドレス８２８とポート８３０から得られる。送信元ＩＰアドレス８７０及び送信元ポート番号８７２は第１のクライアントアプリケーション通信プロトコルネットワークノード８０４のＩＰアドレス８０６とポート番号８０８から得られる。第１のセッション「Ｓ１」は、入力データパケットとして最初に受信される第１のデータパケット８４０と、入力データパケットとして４番目に受信される第２のデータパケット８４２とを含む。
【００５８】
第２の組み合わせの例は符号「８７４」で示される。セッションＩＤ「Ｓ２」が符号「８７６」で示される。送信先ＩＰアドレス８７８及び送信先ポート番号８８０はサーバアプリケーション通信プロトコルネットワークノード８２６のＩＰアドレス８２８とポート８３０から得られる。送信元ＩＰアドレス８８２及び送信元ポート番号８８４は第２のクライアントアプリケーション通信プロトコルネットワークノード８１２のＩＰアドレス８１６とポート番号８２０から得られる。第２のセッション「Ｓ２」は、入力データパケットとして２番目に受信される第３のデータパケット８４４と、入力データパケットとして３番目に受信される第６のデータパケット８５０とを含む。
【００５９】
第３の組み合わせの例は符号「８８６」で示される。セッションＩＤ「Ｓ３」が符号「８８８」で示される。送信先ＩＰアドレス８９０及び送信先ポート番号８９２はサーバアプリケーション通信プロトコルネットワークノード８２６のＩＰアドレス８２８とポート８３０から得られる。送信元ＩＰアドレス８９４及び送信元ポート番号８９６は第２のクライアントアプリケーション通信プロトコルネットワークノード８１２のＩＰアドレス８１６とポート番号８１８から得られる。第３のセッション「Ｓ３」は、入力データパケットとして５番目に受信される第５のデータパケット８４８と、入力データパケットとして７番目に受信される第７のデータパケット８５２とを含む。
【００６０】
第４の組み合わせの例は符号「９００」で示される。セッションＩＤ「Ｓ４」が符号「９０２」で示される。送信先ＩＰアドレス９０４及び送信先ポート番号９０６はサーバアプリケーション通信プロトコルネットワークノード８２６のＩＰアドレス８２８とポート８３０から得られる。送信元ＩＰアドレス９０８及び送信元ポート番号９１０は第３のクライアントアプリケーション通信プロトコルネットワークノード８１４のＩＰアドレス８１６とポート番号８２２から得られる。第４のセッション「Ｓ４」は、入力データパケットとして６番目に受信される第４のデータパケット８４６を含む。
【００６１】
図１２は、符号「９２０」で示すパケットリアセンブル処理を示す。この例では、入力データパケットは、図１１を参照し既に述べたように、最初に受信され、セッション「Ｓ１」８６４の一部として定義される第１のデータパケット８４０、２番目に受信され、セッション「Ｓ１」８６４の一部として定義される第３のデータパケット８４４、３番目に受信され、セッション「Ｓ２」８７６の一部として定義される第６のデータパケット８５０、４番目に受信され、セッション「Ｓ１」８６４の一部として定義される第２のデータパケット８４２、５番目に受信され、セッション「Ｓ３」８８８の一部として定義される第５のデータパケット８４８、６番目に受信され、セッション「Ｓ４」９０２の一部として定義される第４のデータパケット８４６、７番目に受信され、セッション「Ｓ３」８８８の一部として定義される第７のデータパケット８５２の順に受信される。
【００６２】
最初に入力するイーサネットフレーム９２２はセッション「Ｓ１」８６４の一部分としての第１のデータパケット８４０であり、ペイロードデータ９２６における文字列”Ｒｅｄ  Ｓｉｇｎ”９２８と、イーサネットフレームに関連するＬ２ヘッダ９２３と、インターネットプロトコル（ＩＰ）ヘッダに関連するＬ３ヘッダ９２５と、ＴＣＰヘッダに関連するＬ４ヘッダ９２４とを含む。さらに、第１のイーサネットフレーム９２２は解析され、その結果、ペイロードデータ９２６がヘッダ９２３、９２５、９２４から抽出される。その後、ペイロードデータ９２６が第１のバッファ９３０（例えば、Ｓｉｇｂｕｆ）に格納される。
【００６３】
２番目に入力するイーサネットフレーム９３２はセッション「Ｓ２」８７６の一部分としての第３のデータパケット８４４であり、ペイロードデータ９３６における文字列”Ｇｒｅｅｎ  Ｓｉｇｎ”９３８と、イーサネットフレームに関連するＬ２ヘッダ９３３と、インターネットプロトコル（ＩＰ）ヘッダに関連するＬ３ヘッダ９３５と、ＴＣＰヘッダに関連するＬ４ヘッダ９３４とを含む。さらに、第２のイーサネットフレーム９３２は解析され、その結果、ペイロードデータ９３６がヘッダ９３３、９３５、９３４から抽出される。この第２のイーサネットフレーム９３２が同じプロトコル接続（セッション「Ｓ１」８６４とセッション「Ｓ２」８７６）であるか否かが判断される。同じプロトコル接続ではないので、ペイロードデータ９３６は、第２のバッファ９４０（例えば、Ｓｉｇｂｕｆ  Ｂ２）に格納される。
【００６４】
３番目に入力するイーサネットフレーム９４２はセッション「Ｓ２」８７６の一部分としての第６のデータパケット８５０であり、ペイロードデータ９４６における文字列”ａｕｒｅ  Ｓ２”９４８と、イーサネットフレームに関連するＬ２ヘッダ９４３と、インターネットプロトコル（ＩＰ）ヘッダに関連するＬ３ヘッダ９４５と、ＴＣＰヘッダに関連するＬ４ヘッダ９４４とを含む。さらに、第３のイーサネットフレーム９４２は解析され、その結果、ペイロードデータ９４６がヘッダ９４３、９４５、９４４から抽出される。このイーサネットフレーム９４２が、第２のイーサネットフレーム９３２のような以前に入力したイーサネットフレームと同じプロトコル接続（セッション「Ｓ２」８７６とセッション「Ｓ２」８７６）であるか否かが判断される。同じプロトコル接続であるので、ペイロードデータ９４６は、第２のバッファ９４０（例えば、Ｓｉｇｂｕｆ  Ｂ２）に格納されているペイロードデータ９３６と連結される。この組み合わせ９５０が図５に示すようにコンテンツサーチエンジン４４に入力される。図５に示されるルールテーブル４０は、コンテンツサーチエンジン４４と動作可能に接続され、”Ｂｒｏｗｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”、”Ｒｅｄ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”、”Ｇｒｅｅｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ２”、”Ｂｌｕｅ  Ｓｉｇｎａｔｕｒｅ  Ｓ４”等の検索されるべき文字のパターンを含む。”Ｇｒｅｅｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ２”のパターンが、２つのデータパケット９３２と９４２の組み合わせ中に存在することから、検索される。
【００６５】
４番目に入力するイーサネットフレーム９５２はセッション「Ｓ１」８６４の一部分としての第２のデータパケット８４２であり、ペイロードデータ９５６における文字列”ａｕｒｅ  Ｓ１”９５８と、イーサネットフレームに関連するＬ２ヘッダ９５３と、インターネットプロトコル（ＩＰ）ヘッダに関連するＬ３ヘッダ９５５と、ＴＣＰヘッダに関連するＬ４ヘッダ９５４とを含む。さらに、第４のイーサネットフレーム９５２は解析され、その結果、ペイロードデータ９５６がヘッダ９５３、９５５、９５４から抽出される。この第４のイーサネットフレーム９５２が、第１のイーサネットフレーム９２２のような以前に入力したイーサネットフレームと同じプロトコル接続（セッション「Ｓ１」８６４とセッション「Ｓ１」８６４）であるか否かが判断される。同じプロトコル接続であるので、ペイロードデータ９５６は、第１のバッファ９３０（例えば、Ｓｉｇｂｕｆ  Ｓ１）に格納されているペイロードデータ９２６と連結される。この組み合わせ９６０が図５に示すようにコンテンツサーチエンジン４４に入力される。図５に示されるルールテーブル４０は、コンテンツサーチエンジン４４と動作可能に接続され、”Ｂｒｏｗｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”、”Ｒｅｄ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”、”Ｇｒｅｅｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ２”、”Ｂｌｕｅ  Ｓｉｇｎａｔｕｒｅ  Ｓ４”等の検索されるべき文字のパターンを含む。”Ｒｅｄ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”のパターンが、２つのデータパケット９２２と９５２の組み合わせ中に存在することから、検索される。
【００６６】
５番目に入力するイーサネットフレーム９６２はセッション「Ｓ３」８８８の一部分としての第５のデータパケット８４８であり、ペイロードデータ９６６における文字列”Ｂｒｏｗｎ  Ｓｉｇｎ”９６８と、イーサネットフレームに関連するＬ２ヘッダ９６３と、インターネットプロトコル（ＩＰ）ヘッダに関連するＬ３ヘッダ９６５と、ＴＣＰヘッダに関連するＬ４ヘッダ９６４とを含む。さらに、第５のイーサネットフレーム９６２は解析され、その結果、ペイロードデータ９６６がヘッダ９６３、９６５、９６４から抽出される。この第５のイーサネットフレーム９６２が以前に入力したイーサネットフレームと同じプロトコル接続であるか否かが判断される。その判断結果は否定的であり、よって、ペイロードデータ９６６は第３のバッファ９７０（例えば、Ｓｉｇｂｕｆ  Ｂ３）に格納される。
【００６７】
６番目に入力するイーサネットフレーム９７２はセッション「Ｓ４」９０２の一部分としての第４のデータパケット８４６であり、ペイロードデータ９７６における文字列”Ｂｌｕｅ  Ｓｉｇｎａｔｕｒｅ”９７８と、イーサネットフレームに関連するＬ２ヘッダ９７３と、インターネットプロトコル（ＩＰ）ヘッダに関連するＬ３ヘッダ９７５と、ＴＣＰヘッダに関連するＬ４ヘッダ９７４とを含む。さらに、第６のイーサネットフレーム９７２は解析され、その結果、ペイロードデータ９７６がヘッダ９７３、９７５、９７４から抽出される。この第６のイーサネットフレーム９７２が以前に入力したイーサネットフレームと同じプロトコル接続であるか否かが判断される。その判断結果は否定的となる。そのパターン全体が１つのデータパケットに対する同じペイロードデータ９７６中に含まれているため、シグネチャからのデータは第４のバッファ９８０（例えば、Ｓｉｇｂｕｆ  Ｂ４）には格納されない。ペイロードデータ９７２が図５に示すようにコンテンツサーチエンジン４４に入力される。図５に示されるルールテーブル４０は、コンテンツサーチエンジン４４と動作可能に接続され、”Ｂｒｏｗｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”、”Ｒｅｄ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”、”Ｇｒｅｅｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ２”、”Ｂｌｕｅ  Ｓｉｇｎａｔｕｒｅ  Ｓ４”等の検索されるべき文字のパターンを含む。”Ｂｌｕｅ  Ｓｉｇｎａｔｕｒｅ  Ｓ４”のパターンがデータパケット９７２中に存在することから、検索される。
【００６８】
７番目に入力するイーサネットフレーム９８２はセッション「Ｓ３」８８８の一部分としての第７のデータパケット８５２であり、ペイロードデータ９８６における文字列”ａｔｕｒｅ  Ｓ３”９８８と、イーサネットフレームに関連するＬ２ヘッダ９８３と、インターネットプロトコル（ＩＰ）ヘッダに関連するＬ３ヘッダ９８５と、ＴＣＰヘッダに関連するＬ４ヘッダ９８４とを含む。さらに、第７のイーサネットフレーム９８２は解析され、その結果、ペイロードデータ９８６がヘッダ９８３、９８５、９８４から抽出される。この第７のイーサネットフレーム９８２が第５のイーサネットフレーム９６２のような以前に入力したイーサネットフレームと同じプロトコル接続（セッション「Ｓ３」８８８対セッション「Ｓ３」８８８）であるか否かが判断される。同じプロトコル接続であるので、ペイロードデータ９８６は、第４のバッファ９７０（例えば、Ｓｉｇｂｕｆ  Ｓ３）に格納されているペイロードデータ９６６と連結される。この組み合わせ１０００が図５に示すようにコンテンツサーチエンジン４４に入力される。図５に示されるルールテーブル４０は、コンテンツサーチエンジン４４と動作可能に接続され、”Ｂｒｏｗｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”、”Ｒｅｄ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”、”Ｇｒｅｅｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ２”、”Ｂｌｕｅ  Ｓｉｇｎａｔｕｒｅ  Ｓ４”等の検索されるべき文字のパターンを含む。”Ｂｒｏｗｎ  Ｓｉｇｎａｔｕｒｅ  Ｓ１”のパターンが、２つのデータパケット９６２、９８２中に存在することから、検索される。
【００６９】
図１３において、符号「３００」で示される、マルチパケット・シグネチャ・スキャナ３０に対して利用可能な電気的ハードウェア構成の例を示す（例示であって、これに限定されるものではない）。多くの電子機器がこの条件を満たす。それは、ＦＰＧＡ（Field Programmable Array）３０２を含んでもよい。ＦＰＧＡ３０２は製造後にデバイスにプログラムできる論理ネットワークであり、ゲートのような論理素子、参照テーブル、フリップフロップ及び／または他のプログラム可能な内部接続配線を含む。ＦＰＧＡ３０２は、Ｘｉｌｉｎｘ社（９５１２４−３４００カリフォリニア州、サンホセ、ロジックドライブ２１００）のＶＩＲＴＥＸ ＩＩ ＰＲＯ（登録商標）を含んでも良い（例示であり、これに限定されるものではない）。ＦＰＧＡ３０２は、好ましくはプロセッサを含むコントローラ３０４に電気的に接続される。コントローラ３０４は、ＩＢＭ社（１０６０４、ニューヨーク州、ホワイトプレインズ、ウエストチェスタ１１３３）のＰｏｗｅｒＰＣ Ｐｒｏｃｅｓｓｏｒ４０５（登録商標）を含んでも良い（例示であり、これに限定されるものではない）。ＦＰＧＡ３０２は、マルチパケット・シグネチャ・スキャナ３０が迅速に入力データストリームに対するプロトコル接続を確認できるように、図２に示すＦＩＦＯキューバッファ５２に格納されるプロトコル接続（例えば、セッション番号）に関する参照テーブル３０６とコンテンツサーチエンジン４４を実現するためのグルーロジック及び排斥ロジックを提供する。「グルーロジック」は、変換、翻訳、またはあるシステムを他のシステムと協働させるためのその他の処理を実現するソフトウェアである。
【００７０】
コントローラ３０４は、マルチパケット・シグネチャ・スキャナ３０とマルチパケット・シグネチャ・スキャナ３０が存在するホスト間のモニタ通信を行いつつ、マルチパケット・シグネチャ・スキャナ３０を監視し、管理するとともに他の通信プロトコル制御アプリケーション３０１（例えば、ＴＣＰ／ＩＰアプリケーション）をも実現する。ＦＰＧＡ３０２とコントローラ３０４の双方に接続するランダムアクセスメモリ（ＲＡＭ）のような複数のメモリ３０８が存在する。
【００７１】
別の例として、プロトコル接続（例えば、セッション番号）に関する参照テーブル３０６がＦＰＧＡ３０２ではなくコントローラ３０４に電気的に接続されてもよい。
【００７２】
図１４〜図１７において、いくつかの基本的な機能に関連したコンピュータプログラムステップがフローチャートで示されている。フローチャートの説明において、機能的な説明には”＜＞”を付しており、＜ｎｎｎ＞はその番号のフローチャートのブロックを示している。
【００７３】
図１４に、マルチパケット・シグネチャ・スキャン処理の全体フローチャートが符号４００で示されている。基本的なマルチパケット・シグネチャ・スキャン機能は符号＜４０２＞で示されている。図２に示すように、最初に、排除フィルタ４８を利用し、入力データストリーム３２を、出力データストリーム３６の一部とするために出力バッファ３８に戻すべきか、マルチパケット・シグネチャ・スキャナ３０に送信すべきかを判断するチェック機能がある。よって、排除に関する判断＜４０６＞が「否定的」であれば、次の入力データパケットが抽出され＜４２６＞、データパケットは出力バッファ３８に戻されて出力データストリーム３６の一部となる。
【００７４】
しかしながら、排除に関する判断＜４０６＞が「肯定的」であれば、例えば、図６に示すような、送信先アドレス１２４、送信元アドレス１２８、送信元ポート番号１３０及びプロトコルタイプ１３２の組み合わせにより、一意に特定されるＴＣＰのような、プロトコル伝送接続が同一か否かについて検索を行う。処理ステップ＜４０８＞においてこの検索結果が「否定的」であれば、図８において符号「２１８」で示され、送信元及び送信先アドレスやポート番号、プロトコルタイプ、接続状態及びタイムアウトのようなメモリテーブル内の接続に関するステート情報である接続追跡情報を、次の入力データパケットを抽出する＜４２６＞前にチェックする＜４１０＞。ステップ＜４０８＞においてその検索に対する応答が「肯定的」であれば、第１の格納データパケットの通信プロトコル接続を第２の入力データパケットと比較する＜４１２＞。
【００７５】
第１の格納データパケットの通信プロトコル接続が第２の入力データパケットと同じであるか否かが判断される＜４１４＞。その判断結果が「否定的」であれば、次の入力データパケットが抽出され＜４２６＞、当該データパケットは出力バッファ３８に戻されて出力データストリーム３６の一部となる。その判断結果が「肯定的」であれば、連結されたデータが、図２に示すように、コンテンツサーチエンジン４４及び／または正規表現エンジン４２により解析される＜４２０＞。
【００７６】
連結されたデータにおいてパターンが検出されたか否か判断する＜４２２＞。この判断の結果が「否定的」であれば、次の入力データパケットが抽出され＜４２６＞、当該データパケットは出力バッファ３８に戻されて出力データストリーム３６の一部となる。その判断結果が「肯定的」であれば、図２に示すように、連結されたデータは、切り詰められ、図８に示すバッファ２２０のようなバッファに格納される＜４２４＞。その長さは、ルールテーブル４０からのシグネチャを特徴づけるパターンに使用される文字列の最大文字数Ｌsigから１文字分だけ減じた値となる。
【００７７】
図１５に、図１１に示す参照テーブル３０６を利用して、通信プロトコル接続の一致があるか否かを判断する＜５０２＞マッチングアルゴリズムを示す第２のフローチャートを示す。最初のステップで、通信プロトコル伝送接続の入力を受信する＜５０４＞。プロトコル伝送接続の１つの例は、例えば図６に示すＴＣＰのように、送信先アドレス１２４、送信先ポート１２６、送信元アドレス１２８、送信元ポート番号１３０及びプロトコルタイプ１３２の組み合わせにより一意に特定される。
【００７８】
プロトコル伝送接続値が既存の通信プロトコル伝送接続値と等しいか否かを判断する＜５０６＞。この判断の結果が「否定的」であれば、現在のプロトコル伝送接続は、次の入力データパケットを抽出する＜４２６＞前に、図８に示す、送信元及び送信先アドレスやポート番号、プロトコルタイプ、接続状態及びタイムアウトのようなメモリテーブル内の接続に関するステート情報である通信プロトコル接続追跡情報２１８と、特定のプロトコル接続（例えばセッション）が登録または生成されたときを示すタイムエントリを与えるタイムスタンプ２１４とによってマークされる。この機能は符号＜５１０＞により示される。その後、ｎｕｌｌが返される＜５１２＞。
【００７９】
ステップ＜５０６＞における判断が「肯定的」であり、入力されたプロトコル伝送接続値が既存のプロトコル伝送接続値と等しければ、参照テーブル３０６において空きスロットを検索する機能＜５１４＞が実行される。接続テーブル内の空きスロットのプロトコル接続値が、既存のプロトコル伝送接続値と等しいか否かが判断される＜５１６＞。この判断が「否定的」であれば、例えば参照テーブル３０６のような通信プロトコル伝送接続テーブルにおいて空きスロットが作成される＜５２０＞。そして、現在のプロトコル伝送接続が、次の入力データパケットを抽出する＜４２６＞前に、図８に示す、送信元及び送信先インターネットプロトコル（ＩＰ）アドレスやポート番号、プロトコルタイプ、接続状態及びタイムアウトのようなメモリテーブル内の接続に関するステート情報である通信プロトコル接続追跡情報２１８と、特定のプロトコル接続（例えばセッション）が登録または生成されたときを示すタイムエントリを与えるタイムスタンプ２１４とによってマークされる。この機能は符号＜５２２＞により示される。その後、ｎｕｌｌが返される＜５２４＞。
【００８０】
ステップ＜５１６＞における、空きスロットのプロトコル接続値が既存のプロトコル接続値に等しいか否かの判断に対する結果が「肯定的」であれば、接続テーブル内のそのスロットに最新のタイムスタンプが上書きされる＜５１８＞。その後、現在のプロトコル伝送接続は、次の入力データパケットを抽出する＜４２６＞前に、図８に示す、送信元及び送信先アドレスやポート番号、プロトコルタイプ、接続状態及びタイムアウトのようなメモリテーブル内の接続に関するステート情報である通信プロトコル接続追跡情報２１８と、特定の通信プロトコル接続が登録または生成されたときを示すタイムエントリを与えるタイムスタンプとによってマークされる。この機能は符号＜５２２＞により示される。その後、ｎｕｌｌが返される＜５２４＞。
【００８１】
図１６に、符号「６００」で示す、隣接するパケットからのペイロードデータを付加するアルゴリズムである第３のフローチャートを示す。この全体的な機能は、隣接するパケットからのペイロードデータを連結する機能として示されている。最初に、メモリに格納されている第１のデータパケットと入力した第２のデータパケットの間で通信プロトコル接続が一致するか否かが判断される＜６０４＞。この判断が「肯定的」であるとき、メモリに格納されている第１のデータパケットと入力した第２のデータパケットが連結され＜６０６＞、連結されたペイロードデータは、パターンが検索されるデータとして返送される＜６０８＞。
【００８２】
この判断が「否定的」であるとき、入力した第２のデータパケットに対するプロトコル接続が、プロトコル接続テーブル内の関連するエントリと比較される＜６１０＞。この比較の結果が「否定的」であれば、ｎｕｌｌの値が返される＜６１２＞。この比較の結果が「肯定的」であれば、入力したペイロードデータの長さ（例えば、Len(data)）が、最大のシグネチャ長（Ｌsig）より１文字分少ない長さよりも小さいか否かが判断される。この判断の結果が「肯定的」であれば、バッファ内の格納ペイロードデータは、入力したペイロードデータと切り詰められた格納ペイロードデータにより置き換えられる＜６１６＞。その後、ｎｕｌｌの値が返される＜６１８＞。その判断の結果が「否定的」であれば、バッファ内の格納ペイロードデータは切り詰められた入力ペイロードデータにより置き換えられる＜６２０＞。その後、ｎｕｌｌの値が返される＜６１８＞。このプロセスはコンテンツサーチエンジン４４により利用されるデータを追加するための処理である。
【００８３】
図１７に、符号「７００」で示す、データをバッファに格納するアルゴリズムである第４のフローチャートを示す。この処理は、ペイロードデータをバッファに格納する第１の機能＜７０２＞を含む。入力ペイロードデータの長さ（Len(data)）と格納ペイロードデータの長さ（Len(BufSig)）が、最も長いシグネチャの長さ（Ｌsig）から１だけ少ない長さよりも小さいか否かを判断する＜７０４＞。判断＜７０４＞での結果が「肯定的」である場合、入力ペイロードデータと格納ペイロードデータの組み合わせが修正され、修正されたペイロードデータとして格納される＜７０６＞。判断＜７０４＞での結果が「否定的」である場合、格納されたペイロードデータの長さ（例えば、Len(data)）が、最大のシグネチャ長（Ｌsig）から１文字分減じた長さよりも小さいか否かが判断される＜７０８＞。
【００８４】
判断＜７０８＞の結果が「肯定的」である場合、入力ペイロードデータと格納ペイロードデータの組み合わせからなるデータがバッファに割り当てられる＜７１０＞。この場合、格納ペイロードデータは、その長さが入力ペイロードデータと格納ペイロードデータの組み合わせの長さが最大のシグネチャ長（Ｌsig）から１文字分減じた長さを超えないように切り詰められる。判断＜７０８＞の結果が「否定的」である場合、ステップ＜７１２＞で示すように、最大のシグネチャ長（Ｌsig）から１文字分減じた長さを超えないように切り詰められた入力ペイロードデータがバッファに割り当てられる。
【００８５】
以上のように、新規な本発明のいくつかの具体例を示し、説明した。前述の記述から明らかなように、本発明の態様はここで示したいくつかの例の特定の詳細により限定されるものではなく、よって、当業者は他の修正、適用、または均等なものに想到できる。上述の記述に含まれる「有する」、「含む」、その他の同様の用語は「選択的なものであり」または「含んでも良い」という意味で使用されており、「必要である」という意味では使用されていない。しかしながら、明細書及び図面を検討した後では、当業者にとって、本発明に対する種々の変更、修正、変形例、他の利用及び応用が明らかになるであろう。本発明の精神及び範囲から逸脱しない変更、修正、変形例、他の利用及び応用は、添付の特許請求の範囲によってのみ限定される発明によりカバーされるとみなされる。
【図面の簡単な説明】
【００８６】
【図１】本発明で利用されるデータパケット指向コンピュータネットワークの一例を示す概念図
【図２】本発明に係るマルチパケット・シグネチャ・スキャンシステムの好ましい具体例を示す図
【図３】ＴＣＰパケットのビットレベルでの説明図
【図４】高いレベルから見た、コンテンツサーチエンジンに入力する（３つの）代表的なデータパケットを説明した図
【図５】高いレベルから見た、本発明に係るマルチパケット・シグネチャ・スキャンシステムに入力する、図４に示すような（３つの）代表的なデータパケットを説明した図
【図６】関連の入力イーサネットフレームを示すために使用されるプロトコル接続情報を示した図
【図７】伝送制御プロトコル（ＴＣＰ）に対する典型的な接続状態を示した図
【図８】プロトコル接続情報、タイムスタンプ、次のプロトコル接続番号、接続追跡情報、及びメモリバッファに格納されたペイロード情報を含む接続テーブルにおける典型的なエントリを示す図
【図９】本発明に係る３つのレベルを持つ、分割された関連する接続テーブルを示す図
【図１０】入力ペイロードデータのサイズ、バッファに事前に格納されたペイロードデータのサイズ及び最長のシグネチャのサイズから１文字だけ少ない文字数に基づき変化する本発明に係るバッファに格納されたペイロードデータを示す図
【図１１】本発明で使用されるマルチセッション通信プロトコル接続データパケットトラヒックを有するデータパケット指向コンピュータネットワークを示す図
【図１２】図１１に示すような、データパケットのリアセンブルとともに、本発明に係るマルチパケット・シグネチャ・スキャンシステムに入力するデータパケットフローを示す図
【図１３】典型的なコンピュータハードウェアと、本発明に係るマルチパケット・シグネチャ・スキャンシステムに対する接続を示す図（一例であり、これに限定されない）
【図１４】本発明に係るマルチパケット・シグネチャ・スキャンシステムの典型的なフローチャート
【図１５】本発明に係る接続テーブルにおける通信プロトコルに対するマッチングアルゴリズムの典型的なフローチャート
【図１６】本発明に係るコンテンツサーチエンジン用に設けられたバッファへデータを追加するためのアルゴリズムの典型的なフローチャート
【図１７】本発明に係るコンテンツサーチエンジン用に設けられたメモリバッファへデータを格納するためのアルゴリズムの典型的なフローチャート
【図１】
2009510815.tif 000003
【図２】
2009510815.tif 000004
【図３】
2009510815.tif 000005
【図４】
2009510815.tif 000006
【図５】
2009510815.tif 000007
【図６】
2009510815.tif 000008
【図７】
2009510815.tif 000009
【図８】
2009510815.tif 000010
【図９】
2009510815.tif 000011
【図１０】
2009510815.tif 000012
【図１１】
2009510815.tif 000013
【図１２】
2009510815.tif 000014
【図１３】
2009510815.tif 000015
【図１４】
2009510815.tif 000016
【図１５】
2009510815.tif 000017
【図１６】
2009510815.tif 000018
【図１７】
2009510815.tif 000019