JP2006508597A - デジタル通信データに基づいてアクションをトリガーする方法及びコンピュータ・システム - Google Patents

Abstract

本発明は、意味フローを規定する1つ又は2つ以上のプロトコル属性における1つ又は2つ以上の条件に対応して3つの状態を持ち得る少なくとも1つのフィルタを供給されるデジタル処理装置(1,2)に関する。それぞれのプロトコル属性は意味フロー中に利用される一連のプロトコル・ネームと、一連のプロトコル・ネーム中にそのネームが示されるプロトコルが搬送するパラメータ・ネームとによって特定される。デジタル処理装置は、通信データがプロトコル属性値を提示し、このプロトコル属性値からフィルタが有効又は無効状態となるまで通信データにフィルタを供給するフィルタリング・エンジン(1)と、フィルタの状態が有効であればアクションをトリガーするアクション・エンジン(2)とから成る。

Description

本発明の分野はデジタル通信データの形で送信される情報ストリームの制御及び管理の分野である。
例えば、ルーティング、資源やサービス品質の管理、セキュリティ制御、特定コンテンツの観測、通信手段の使用料算定などを挙げることができる。

ルーティングは本質的には送信側から受信側への通信データを経路決定するためネットワーク・レベルにおいて適用される。回線交換の場合には、物理的な固定の端末相互間リンクを成立させる信号経路によって行われる。パケット交換の場合には、それぞれ異なる物理レイヤで構成されている複数のネットワークであっても、通信全体のために物理的回線を独占しなくても、例えば、IPアドレスのようなアドレスによって通過が可能になる。

ATMプロトコルによって提供されるようなセル交換の場合、仮想回路の形成によって、回路交換によって提供されるスピードと、パケット交換によって提供される物理資源の最適利用とを両立させることになる。典型的には、ルーティングは本質的に地理的な場所のコンセプトに基づく所定のネットワーク・アドレスに依存する。ネットワーク・サービスには、より抽象化したいという傾向がある。このような要望のいくつかに対して、その解決策となる技術が既に提供されている。

例えば、仮想ローカル・エリア・ネットワーク（略してVLAN）がそれである。しかし、データの経路を決定するルータによって実施されるアクションの多くは未だに所定の企業に仮想ローカル・エリア・ネットワークを割当てるための従来のアーキテクチャやアドレスの仕様のような、比較的固定的な基準によって条件設定されるのが現状である。仮想ネットワークが特定のアプリケーション、特定のデータのタイプ、又は特定のサービスにリンクされることが望ましい。残念ながら、このようなアプローチの採用は配備及び管理の複雑さという点で不利である。

資源及びサービス品質の管理は構文的なデータ・フローに対してスループット又は送信優先権レベルを割当てるなどのアクションを実行することにある。構文的フローとはネットワーク、トランスポート又はセッション・レベルの基準によって識別される1組のパケットに相当する。構文的フローの認識に基づく資源やサービス品質の管理は、提供されるサービス、例えば、音楽や映画の連続再生(オーディオ又はビデオのストリーミング)、仮想ネットワークのメンバーシップ、一連の交換、G721コーディングやサウンド圧縮標準によって規定されているような通信内容、特定通信における帯域幅を購入する使用者又はキーワードの識別などに関連して、アプリケーション・レベルで管理しようとしても満足に管理できない。同じ構文的フローでありながらタイプの異なるデータを伝送することがある。

例えば、クライアントの端末に表示されるhttpフローは、システムのキャパシティが次第に自由になるに従って表示される画像の表示を犠牲にして、先ずテキスト・データを呈示する。テキスト・データの伝送には狭い帯域幅で充分であり、可視又は可聴データの伝送には広い帯域幅が好適であるが、構文的フロー全体に単一の帯域幅を割当てるだけでは満足な成果は得られない。

セキュリティ制御は認可されたユーザーだけに、デジタル通信データ又は放送へのアクセスを制限するように、伝送されるデジタル通信データに対して実行されるアクションである。ファイヤーウォールは例えばIPのようなネットワーク・アドレスを認識することによって、TCP又はUDPのようなトランスポート・ポートへのデータ・パケットを禁止又は許可する。このような基準は動的にネゴシエートされるポートを使用するアプリケーションに困難を課することになる。

例えば、FTPプロトコルの場合、コマンド・コネクションが先ずTCP21ポートにおいて開かれる。このコネクションによって、クライアントはサーバにつないでリモート・ファイル・システム・ツリーを辿り、サーバに問合せ(GET)を行うことができる。クライアントが問合せを行うと、サーバはクライアントに所要のファイルを回収するために接続しなければならない特定のポートを通知し、データ・コネクションを開く。トランザクションはこの動的にネゴシエートされるポートにおいて行われるが、このコネクションは特定のヘッダを持たないから、このコネクションを分析することによってFTPプロトコルを認識することは不可能である。

交換されるファイルのバイナリデータだけが移動する。この場合、データ・コネクションすべてを確認するためには、コマンド・セッションの完全な内容を分析する必要がある。このことはマルチメディア・システムに関するH.323規格に含まれる多くのプロトコル及びリアルタイム・アプリケーション・コネクション(RTP)についても同様である。H.323セッションが開始されると、ユーザインタフェイス制御に関するH.245プロトコルによって動的ポートが割当てられ、音声及び/又は画像が伝送されるRTPが決定される。それぞれの音声パケットに使用される特定のヘッダがRTPコネクションの認識を可能にするから、ポートの予備知識を省くことができる。

デジタル通信データで行われるセキュリティ・アクションのうち、暗号手法の分野では、メッセージの暗号化、署名、又は認証アクションも公知である。通常、暗号手法アクションをトリガーするのはメッセージを管理するアプリケーションである。例えば、ローカル・エリア・ネットワークからワイド・エリア・ネットワークを介して送信されるデータを暗号化するため、ネットワーク・レベルで暗号手法アクションをトリガーする、例えば、IPSECのような手段も公知である。トリガーの基準となるのは依然として構文形式のフローである。例えば計算資源を節約するため、デジタル通信データのうち、最も慎重を要するコンテンツの部分に対して、アプリケーションとは独立に、暗号化又は認証アクションを事後的にトリガーすることは困難である。

コンテンツの観察（モニタリング）は交換される情報のエラー率、搬送量又は意味の統計を行うのに有用である。動作の制御はこの種の通信機能の一部を形成する。ここでも、観察すべきコンテンツの選択は本質的には構文的フローに基づいて行われる。時には、関連事項に拘らずに、通信データ全体に対して観察アクションがトリガーされる。利用し易いように分類する上では、ターゲットを絞って観察アクションをトリガーする方が有用である。

以上に指摘した問題点は他の通信機能、例えば、通信手段使用料金の算定やデータ圧縮にも見られる。一般に、データ圧縮及び圧縮解除アクションをトリガーするのはアプリケーション・レベルである。例えば、専用ポートを介して伝送される通信データすべてに対して、トランスポート・レベルで圧縮アクションをトリガーすることも可能である。しかし、このようなアプローチは依然として構文的な性格のものであり、より高い機能レベルには殆ど不適当である。

さらにまた、それぞれの通信機能は、トリガーすべきアクション及び考慮すべき構文的フローを予め定義することによって、開発の目的物と、しばしば具体的な配備の目的物とをもたらすのが普通である。これでは通信機能の幅を広げる融通性に欠ける。

要約すれば、デジタル通信データは一般に、構文的フローを定義するのに好適なプロトコル情報をコードする信号と、しばしば有用データ（又はペイロード）と呼称されるアプリケーション・パッケージ・レベル情報をコードする信号とを有するヘッダを含む。それぞれの通信機能に関連してこれらの通信データに対して、その出所又は到着点においてアプリケーション・パッケージ・レベルで、又は構文的フローを識別する既知の値をヘッダ部分中に認識することによって、送信の途中においてアクションがトリガーされる。

アプリケーションを目的に応じてパラメータ化できたとしても、企業や計算センターのような事業所において実施される膨大なアプリケーションへの対応は忽ち手詰まりとなる。
ポートを動的にネゴシエートする場合、又はサービスの必要上、より高い機能レベルの基準に沿って、構文的フローの一部にだけ、又は複数の構文的フローに対して共通にアクションを実行しなければならない場合、構文的フローを識別する既知の値を認識することによって引き起こされる厳密さは、必ずしも好適であるとはいえない。

本発明の目的は、ソースにおけるアプリケーションとは独立に、且つ構文的フローに制限された純粋にプロトコルに基づく分析に制限されることなく通信データに対してアクションをトリガーできるようにすることである。
本発明の他の目的はアクション・トリガーを一括する通信機能を、最大限の融通性を確保できるように、開発し、配備できるようにすることである。

解決策として、通信データを意味フローによって分類し、所与の意味フローにそれぞれのアクション・トリガーを割当てる。
構文的フローとは異なり、意味フローは所与のサービスを満足させるため、共通の機能基準を満たすすべての通信データを一括する。構文的フローは幾つかの異なる意味フローを搬送することがある。同一の意味フローは、それが搬送されるためには幾つかの構文的フローを必要とすることがある。

意味フローに基づく分類の利点はアクション・トリガー基準を無限に広げることができることであり、分散型ネットワークのフレームワーク内では特に有利である。
本発明の主題は、デジタル通信データが同一の意味フローに属するとき、この意味フローに対応する少なくとも1つのアクションを、デジタル処理装置（1,2）を介して前記デジタル通信データに対してトリガーする方法である。

この方法は、それぞれが意味フロー中に使用される順序付けされた一連のプロトコル・ネーム及び前記順序付けされた一連のプロトコル・ネーム中にそのネームが指示されるプロトコルに搬送されるパラメータによって特定される、前記意味フローに対応して指定される1つ又は2つ以上のプロトコル属性の1つ又は2つ以上の論理条件に起因する3つの状態、すなわち、前記1つ又は2つ以上の条件が満足されることを裏付けるプロトコル属性値に対応する有効状態と、前記1つ又は2つ以上の条件が満足されないことを裏付けるプロトコル属性値に対応する無効状態と、前記1つ又は2つ以上の条件が満足されるかされないかを裏付けるプロトコル属性値の不在に対応する不確定状態とを有する少なくとも1つのフィルタを前記装置に供給するステップと、フィルタが前記不確定状態を生じる値以外のプロトコル属性値を前記通信データが提供しなかった場合に限り、デジタル処理装置によって前記通信データに3-状態フィルタを適用するステップと、通信データが提供するプロトコル属性値からフィルタが前記有効状態を生ずるとき、デジタル処理装置によって前記アクションをトリガーするステップと、を含むことを特徴とする。

この方法において、フィルタは同一意味フローに属する通信データに対して反応する要素を構成する。この要素は意味フローによる通信データの分類という点において多大の融通性を付与する。利用者は複数の条件を満たすようにプロトコル属性を適応させることができる。例えば、新しいプロトコル・アーキテクチュアに対しては、使用するプロトコル・ネームの順序付けされたシークェンスを規定するだけでよい。利用者はプロトコル・ネーム配列を介して、アクションをトリガーしたい意味フローに適合するパラメータを自由決定することが可能である。利用者は必要に応じて、他のフィルタを形成するだけで、他の意味フローに、デジタル処理装置に供給すべき他のプロトコル属性を付加することができる。

尚、種々の意味フローを定義するためには、デジタル処理装置が実行する動作をフィルタの作成から切り離す。

前記通信データにフィルタを適用するため、フィルタの状態が有効又は無効と判明するまで、又はプロトコル属性がすべて送り出されるまで、デジタル処理装置によって、順序付けされた一連のプロトコル・ネーム中に示されるプロトコルに割当てられたプロトコル・インタフェイスに前記プロトコル属性を逐次送り出し、プロトコル・インタフェイスによって特定パラメータの値を通信データ中から検索して、発見したらこの値をデジタル処理装置へ送信し、デジタル処理装置によってプロトコル・インタフェイスによって送信された値又はこの値の不在に対応するフィルタ状態を評価することによってこの方法にさらに融通性を付与することができる。

これにより、パラメータが使用されるプロトコルによるプロトコル属性値の探索を特殊化し、デジタル処理装置の設計を単純化することができる。
この方法の有益な特徴は、前記デジタル処理装置に供給するそれぞれのフィルタが第1テーブル中のルールの組合せ論理によって決定され、それぞれのルールが、第2テーブルにおいて、プロトコル属性を引数とする少なくとも1つの比較演算子を含む検証式によって決定されることにある。

特に、プロトコル・インタフェイスによって送信される値又は値の不在に対応するフィルタ状態を評価するため、デジタル処理装置が値の送信に応じて組合せ論理中の少なくとも1つのルールの状態を評価し、次いで、評価されたルールの状態に適用された組合せ論理によって決定される状態を評価する。
意味フローへの通信データの所属は経時的に変化することがある。これに対応するため、本発明の方法は、デジタル通信データを走査してプロトコル属性値の変化を検出することによって、値の変化に対応するフィルタ状態変化の評価を可能にするステップを含む。

本発明の他の主題は、デジタル通信データが同一の意味フローに属するとき、この意味フローに対応する少なくとも1つのアクションを、前記デジタル通信データに対してトリガーするコンピュータ・システムである。

このコンピュータ・システムは、フィルタリング・エンジン及びアクション・エンジンを有するデジタル処理装置と、前記意味フローに対応して指定される1つ又は2つ以上のプロトコル属性の1つ又は2つ以上の条件に起因する3つの状態を有する少なくとも1つのフィルタをフィルタリング・エンジンに供給するためのデータベースと、それぞれが意味フロー中に使用される順序付けされた一連のプロトコル・ネーム及び前記順序付けされた一連のプロトコル・ネーム中にそのネームが指示されるプロトコルに搬送されるパラメータによって特定されるプロトコル属性値であって、前記1つ又は2つ以上の条件が満足されることを裏付けるプロトコル属性値に対応する有効状態と、前記1つ又は2つ以上の条件が満足されないことを裏付けるプロトコル属性値に対応する無効状態と、前記1つ又は2つ以上の条件が満足されるかされないかを裏付けるプロトコル属性値の不在に対応する不確定状態とのカタログを設ける少なくとも1つのデータ構造と、フィルタが前記不確定状態を生ずる値以外のプロトコル属性値を前記通信データが提供しなかった場合に限り、フィルタリング・エンジンが前記通信データにそれぞれ必要なフィルタを適用するのに利用できる通信データ受信手段と、データ構造中に前記有効状態が含まれるとき、前記アクションをトリガーするためにアクション・エンジンが利用できる通信データ送信手段と、を備えることを特徴とする。

フィルタリング・エンジンとアクション・エンジンがデジタル処理装置の2つの切り離された要素であるこのコンピュータ・システムが本発明の方法を実施することを可能にする。
意味フロー中の利用可能なそれぞれのプロトコルに割当てられ、フィルタリング・エンジンから、割当てたプロトコルに応じて定められたプロトコル属性を受信するプロトコル・インタフェイスを含み、プロトコル・インタフェイスが特定パラメータの値を通信データ中から検索して、発見したらこの値をフィルタリング・エンジンへ送信し、フィルタリング・エンジンが、プロトコル・インタフェイスによって送信された値又はこの値の不在に対応するフィルタ状態を評価する、ように構成すれば、通信技術の改良に伴って新しいプロトコルが現れても、コンピュータ・システムをこれに容易に適応させることができる。

システム全体を再構成しなくても、この新しいプロトコルのために特別に設計されたプロトコル・インタフェイスを付加するだけでよい。
このコンピュータ・システムの有益な特徴は、データベースが各フィルタに関するルールの組合せ論理を含む第1テーブルと、各ルールに関して、プロトコル属性を引数とする少なくとも1つの比較演算子を含む検証式を含む第2テーブルとを備えることにある。

特に、プロトコル・インタフェイスによって送信される値又は値の不在に対応するフィルタ状態を評価するため、デジタル処理装置が値の送信に応じて組合せ論理中の少なくとも1つのルールの状態を評価し、次いで、評価されたルールの状態に適用された組合せ論理によって決定される状態を評価する。

このコンピュータ・システムの有益な特徴は、データベースが、特定フィルタに連携するそれぞれの意味フローに対応する幾つかのアクション・ネームを含む少なくとも1つの第3テーブルを有することにある。
これにより、それぞれの意味フローに適合する1つ又は2つ以上のアクションをトリガーすることができる。
本発明のその他の利点及び特徴を、添付の図面に示す実施例に基づいて以下に説明する。

図1は本発明を実行するコンピュータ・システムのアーキテクチャ構成図である。
デジタル通信データはアクション・エンジン2へ伝送される前に、後述するように考案されたフィルタリング・エンジン1へ送られて分析される。

図1に示す実施例の場合、デジタル通信データの起点はデジタル通信データをパケット形式で入力カプラ4から受信するコネクション・エクストラクタ3である。コネクション・エクストラクタ3は受信される各パケットから、受信されたパケットが属するカレント・コネクションの識別を可能にする情報を抽出するように考案される。この情報は、典型的には、少なくとも1つ又は2つ以上の第1プロトコル・ネームを含む順序付けされた一連のプロトコル・ネームと、出所アドレスと宛先アドレスとを含む。順序付けされた一連のプロトコル・ネームはパケットが属するコネクションのプロトコル・スタックによって使用されるプロトコル・ネームを含む。各パケットは必ずしもコネクションを完全に識別する全情報を含む必要はなく、受信されるパケットが属するカレント・コネクションを他のパケットが属する他のコネクションから識別することを可能にする最少限の情報を含むだけでよい。パケットが受信されると、コネクション・エクストラクタ3は、受信パケットからコネクション識別情報を抽出して、この情報をカレント・コネクション・テーブル5の当該パケットが属するコネクションに対応する行に記憶させる。このようにしてコネクション・エクストラクタ3はテーブル5を逐次充実させることにより、できうる限り完全な形でそれぞれのカレント・コネクションをテーブル5の各行において識別する。受信されるパケットはそれぞれテーブル5の行を参照しながらフィルタリング・エンジン1へ転送される。テーブル5の行はこのパケットの識別情報と照らし合わせてカレント・コネクションを識別するための情報を含んでいる。

刊行物「IEEE/ACM Transactions On Networking, volume 6, Issue 2 (April 1998), Peter Newman et al., pp.117-129）に開示されている公知技術によれば、ここに詳しく述べるまでもなくコネクション・エクストラクタ3を実施することができる。また、例えば特許出願FR0209599は高性能コネクション・エクストラクタ3の運用に際してプロトコルを認識及び分析する方法を開示している。

本発明のコンピュータ・システムを、例えば、フィルタリング・エンジン1へ伝送すべきデジタル通信情報を含むカレント・コネクション・パケットを入力カプラ4へ転送するための通信ネットワーク・ノードに配置されたプロキシーサーバ装置に組み込む場合に、コネクション・エクストラクタ3は有用である。

さらにまた、それ自体がコネクションのデジタル通信データを形成し、他の手段を介して、それ自体が管理する通信プロトコル・スタックのコネクション識別情報にアクセスする装置に本発明のコンピュータ・システムを組み込む場合にも、必要不可欠ではないが、コネクション・エクストラクタ3は有用である。
入力カプラ4によって受信される限り、または本発明のシステムのホスト・マシンによって形成される限り、デジタル通信データをパケットごとに送信すれば、全部が送信されるまで待つ必要がなく、受信されたり、形成されたりするのを逐次記憶させる必要もなく、リアルタイムで通信データを処理することができる。但し、本発明のシステムは記録されているコネクションに関するデジタル通信データに基づく事後（バッチ）処理にも有用である。

フィルタリング・エンジン1は図2を参照して以下に述べるアクション・データベース6にアクセスする。
データベース6は1つ又は2つ以上のリンク・テーブル61,62,63、少なくとも1つのフィルタ・テーブル64及び少なくとも1つのルール・テーブル65から成る。

リンク・テーブルの各行はフィルタ・ネームをアクション・ネームと関連させる。アクション・ネームは優先順位の高い方から順に索引付けされ、優先順位が最も高いアクションはリンク・テーブルの第1行に、デフォルト・アクションのネームはリンク・テーブルの最終行にそれぞれ索引付けされる。デフォルト・アクションは、優先順位がより高いアクションが1つもトリガーされない場合にトリガーされるアクションである。デフォルト・アクションは空アクション、すなわち、全く作用を持たないアクションとしてもよい。

テーブル61はデジタル通信データの動作又はコンテンツの観察（モニター）を可能にする測定リンク・テーブルである。種々の測定基準がデジタル通信データ中の何を観察すべきかを決定する。例えば、バイト数又はバイトの倍数で表現される通信データ量の評価（又は計測値）を示して、後続の通信データ量、通信時間、毎秒のバイト数又は毎秒のバイト倍数で表される、以後必要とされるスループットを予測する。また、待ち時間、転送エラー又は閉止に対する動作制御を示唆し、モニタされる特定タイプの情報（例えば、文字列）の取出しを示す。

テーブル61のカラム66に索引付けされているそれぞれのネームには、1つ又は2つ以上の測定基準を満足させるアクションが対応する。例えば、「命令文1」は、パケット毎のバイト量を表わす数を合計し、到着する2つの連続パケットを分離する時間を記憶させることによって、量と待ち時間を評価するための測定基準を満足させるアクションに対応する。ネーム「命令文2」は、パケット毎のバイト数を合計して量評価測定基準を満足させるアクションに対応する。「命令文i」は何もしないアクションに対応する。テーブル61の最終行のカラム66に索引付けされているネームと連携するのは、テーブル61の末尾を示す特定ネーム「def」であり、このネームはデフォルトでトリガーされるアクションのネームである。

カラム67に示すフィルター・ネームはカラム66の各アクションと連携する。各フィルター・ネームは同一の意味フローに属する1組の通信データを認識する機能を有する。意味フローはシステム利用者によって特定の意味を与えられる通信データのストリームである。この意味は、例えば、利用者が通信データの受信場所、又は送信場所、日付、又は通信ルーティングを検索するなら、物理的レベルの意味である。この意味は、利用者が特定のアプリケーション、アプリケーションのタイプ又はアプリケーションの利用者を検索するなら、アプリケーション・パッケージ・レベルの意味である。この意味はまた、システム利用者によって意味を与えられる対象に応じて物理的レベル、アプリケーション・パッケージ・レベル及び/又は中間的レベルの複号的レベルの意味である場合もある。1つ又は2つ以上のコネクションが同一の意味フローに属することもある。同様に、1つのコネクションが複数の意味フローに属することもある。従って、各アクションはそれがトリガーされる動機となる意味フローと連携する。

テーブル62はいわゆる防火壁(ファイヤーウォール)リンクであり、同一意味フローのデジタル通信データの転送を許可したり、禁止したりすることを可能にする。
テーブル62のカラム66に索引付けされているそれぞれのネームに対応するのは、デジタル通信データの伝送を許可したり、禁止したりするようにこのデジタル通信データに作用するアクションである。例えば、「拒絶」は受信者へのデータ伝送を阻止し、送信者にこの阻止を通告するアクションに対応する。ネーム「廃棄」は送信者に通告することなく通信データを破壊するアクションに対応する。例えば、「受入」はデジタル通信データを最終受信者に変更を加えることなく伝送するアクションに対応する。

テーブル62のカラム67に示すフィルタ・ネームはカラム66の各アクション・ネームとも連携する。テーブル62のカラム67のフィルタ・ネームは、計測アクション及びファイヤーウォール・アクションが同一の意味フローに好適である場合には、テーブル61のカラム67のフィルタ・ネームと同一となることがある。観察に関して、また伝送の許可又は禁止に関してデジタル通信データが異なる意味フローに属する場合、テーブル62のカラム67のフィルタ・ネームはテーブル61のカラム67のフィルタ・ネームと異なることがある。1つのアクションが複数の異なる意味フローに適応できる場合、同一ネームのアクションをリンク・テーブルの複数の行に索引付けすることがある。これに対して、フィルタ・ネームはそれぞれのリンク・テーブルにおいてたかだか1回だけ連携する。同一の意味フローに関して、不適合なアクションをトリガーすることには矛盾があるからである。テーブル62の最終行のカラム66に索引付けされているネームと連携するのは、テーブル62の末尾を示す特定ネーム「def」であり、索引付けされているネームはデフォルトでトリガーされるルールのネームである。

テーブル63はデジタル通信データに種々の転送スループットを割り当てるサービス・リンク・テーブルである。

テーブル63のカラム66に索引付けされているそれぞれのネームと対応するのは、特定のデジタル通信データに、これらデータのための所定のサービス品質に応じて、伝送スループットを割り当てるアクションである。このアクションは待ち行列（キュー）によって通信データが受信される時、この待ち行列に規定されたスループットに従って再送信するように公知の態様で通信データを進路制御するアクションである。例えば、「キュー20Kb/ｓ」は待ち行列に20Kb/sの転送スループットでデータを伝送するアクションに相当する。ネーム「キュー50Kb/s」は待ち行列に50Kb/sの転送スループットでデータを伝送するアクションに相当する。また、「キュー10Kb/s」は待ち行列に10Kb/sの転送スループットでデータを伝送するアクションに相当する。
テーブル63において、カラム67のフィルタ・ネームはカラム66の各アクション・ネームとも連携する。

ほかにも、デジタル通信データが属する意味フローの機能に応じてシステムの利用者がこのデータに実施したい処理に従って示されるリンク・テーブルにならった、例えば、圧縮又は圧縮解除リンク・テーブル、暗号リンク・テーブル、ルーティング・リンク・テーブルなどの他のリンク・テーブルを作成することができる（図示せず）。この場合、圧縮リンク・テーブルのカラム66に、通信データに適用すべき種々の圧縮率に対応するアクションのネームを見出すことができる。暗号リンク・テーブルのカラム66に、通信データに適用すべき種々の暗号化又は認証キーに対応するアクションのネームを見出すことができる。暗号リンク・テーブルのカラム66に、あらためて通信データが伝送される種々の宛先アドレスに対応するアクションのネームを見出すことができる。

カラム68に索引付けされているフィルタ・ネームと連携されるフィルタ・テーブル64の各行は、カラム69の同一行に索引付けされているルールの組合せ論理である。リンク・テーブルのカラム67に索引付けされている各フィルタ・ネームはテーブル64のカラム68に一度だけ索引付けされるが、事実上同語反復に相当するネーム「def」は例外とされる場合がある。

カラム69の組合せ論理は、図3を参照して説明する真理値テーブル55,56,57,58に従って定義される3つの状態を有する論理演算子を使用する。論理演算子の引数は3つの状態、すなわち、値-1で示される無効状態、値1で示される有効状態及び値0で示される不確定状態を有する。

テーブル58は、「AND」論理演算子の真理値テーブルである。この演算子は、2つの引数が有効状態であるときに有効状態を与え、1つの引数が無効状態であるときに無効状態を与え、そしてその他の場合には不確定状態を与える。
テーブル57は、「OR」論理演算子の真理値テーブルである。この演算子は、1つの引数が有効状態であるときに有効状態を与え、2つの引数が無効状態であるときに無効状態を与え、そしてその他の場合には不確定状態を与える。

テーブル56は、「XOR」論理演算子(排他的論理和)の真理値テーブルである。この演算子は、引数の一方が有効状態に、他方が無効状態のアーギュメントであるときに有効状態を与え、2つの引数がともに無効状態又は有効状態にあるときに無効状態を与え、そしてその他の場合には不確定状態を与える。
テーブル55は、「NOT」単項論理演算子の真理値テーブルである。この演算子は、無効状態の引数に有効状態を与え、有効状態の引数に無効状態を与え、そして不確定状態の引数には不確定状態を与える。

図2に示されたテーブル64のカラム69では、組合せ論理が、1つ又は2つ以上の引数に適用可能な論理演算子で始まる。ルール・ネームで全て終わる枝を有する論路演算子ツリーを記述するように、それぞれの引数はそれ自体ルール・ネーム又は組合せ論理である。
テーブル64のカラム69において使用されたルール・ネームは、1つ毎に一度だけテーブル65のカラム59に索引付けされる。ルール・テーブル65の各ルール・ネームはプロトコル属性に関連する検証式と連携する。この式はカラム60において、カラム59内に含まれるルール・ネームの行と同一行に含まれる。ルール・テーブルは、それぞれのルール・ネームである自然的意味の又は非自然的意味の指示と連携することにより改善され、この自然的又は非自然的意味の指示はカラム39において、カラム59内に含まれるルール・ネームの行と同一行に含まれる。自然的意味は、ルールを作動するカレント・コネクションに属する通信データからプロトコル属性値を抽出可能であることを指示する。非自然的意味は、ルールを作動するカレントコネクションのピアコネクションに属する通信データからプロトコル属性値を抽出可能であることを指示する。

プロトコル属性は、プロトコル・スタック内の所与のプロトコルによって搬送されたパラメータである。好ましくはそれぞれのプロトコル属性は、3つの構文要素によって特定される。第1構文要素はプロトコル・ネームの列を含み、ここにおいて1つの又は2つ以上の*文字は任意のネーム又はネームの列の任意の部分が適合することを指示する。第2構文要素は、プロトコル・ネームのラベル付けのためのマークを含む。このマークは列内のパラメータを使用し、例えばこのパラメータをプロトコル・ネームを括弧間に配置するか、又はデフォルトの場合には列内の最後のネームの品質とする。第3構文要素は、使用されたパラメータ・ネームを含む。例えば、属性*.ip.ip:saddrはカプセル化されたIPパケットのソースアドレスを表し、属性*.[ip].ip:saddrは、最低レベルのIPパケットのソースアドレスを表す。パラメータ・ネームは、TCPプロトコル及びUDPプロトコルのソース又は宛先ポート・ナンバーを指定することができる。パラメータ・ネームはまた、httpプロトコルのホスト・サーバー・ネーム、要求された転送スループット、搬送された明示的プロトコル・ネーム、又は例えばSNETによって決定されるようなサブネット式を指定することもできる。

パラメータは、デジタル通信データの任意の部分に関連することもできる。パラメータは構文的フローを定義するのに適したプロトコル情報をコードする信号に必ずしも関連しなくてよい。パラメータはまた、前に挙げられた有用なデータに関連してもよい。
プロトコル属性は、システムが、サポートされたプロトコル・セット全体に対して包括的な、論理的、算術的且つ比較的な操作を実施するのを可能にするようなタイプとすることが有利である。下記のタイプ、すなわち、符号あり/符号なし/8, 16, 32, 64ビット整数、Mac アドレス、IPアドレス/サブネット・マスク、文字列、時間単位、バイナリー列が挙げられる。例えばBASE.*.UPP:SPORTによって特定されたUDPパケットのポートは、16ビット符号なし整数に対応するunit16タイプである。*.IMAP:SENDERによって特定された、IMAPプロトコルのemailアドレスが、文字列によって定義される。

ルールはプロトコル属性における条件である。ルールの状態は、同一コネクションのデジタル通信データセット全体に適している。検証式は比較演算子を含む。比較演算子は、関連するプロトコル属性値においてそのタイプの関数として演算を行う。例えば等価に対応する=、序列関係に対応する>, <, >=, <=、不等価に対応する!=、正規表現を有効にするための演算子〜である。

図2に示した例の場合、R1と称されるルールは、属性1と称されるプロトコル属性が値1と等しい値を有する場合には有効状態に、値が異なる場合には無効状態に、及びプロトコル属性の値が未知である場合には不確定状態となる。R2と称されるルールは、属性2と称されるプロトコル属性が厳密に値1未満の値を有する場合に有効状態となり、プロトコル属性値が厳密に値1未満ではない場合に無効状態となり、及びプロトコル属性の値が未知である場合に不確定状態となる。こうしてテーブル65は同様に、テーブル64で使用可能なルールセット全体を定義する。例えばRiと称されるルールは、属性iと称されるプロトコル属性が値Xの正規表現を満足させる値を有するとき、有効状態となる。既知の正規表現の中から例を挙げると、文字列の形態で表現されるものであって、文字列は文字又は任意の文字の列と置き換えられ得る特殊文字を含む。これらの特殊文字は、フォーマット(整数、日付け又は金銭価値の存在)を指示するか、又は、データタイプ(ナンバー、アドレス、文字列)を参照するものであって、値が正規表現を満たさない場合無効状態となり、及びプロトコル属性値が未知である場合に不確定状態となる。

なお、フィルターは論理ルール関数である。フィルターを有効にするために考えられる解決手段は、フィルターが呼び出されたときにはいつでもフィルタリング・エンジンによって解釈されるフィルターを有していることにある。フィルターは、より容易に実行可能な構文ツリーの形態で二進フォーマットで予めコンパイルされていることが有利である。例えばルール・ネームはそれぞれ、そのルール・ネームに対応するテーブル65の行上で直接的に、二進フォーマットでポインターによって置き換えられる。構文ツリーはそれ自体、メモリー・スペースを低減するように、そして実行速度を高めるように最適化される。
テーブル61〜65の内容はデータベース6内に予め存在することができる。データベース6は、マン/マシンインタフェイスにカップリングされることが有利である。このインタフェイスは、システムの利用者が予め存在する内容、又は最初は空の内容に基づいて、そしてこの内容を上回るように、これらのテーブルの内容を豊富にすることを可能にする。

利用者が、特定の意味フローに対して新しいアクションをトリガーさせることを定義するのを可能にするために、マン/マシンインタフェイスは、リンク・テーブルの既存ネームの第1の空又は空でないカタログをドロップダウン・メニューの形で提案し、そしてこのカタログに第1のオプションを取り付けることにより、新しいリンク・テーブル・ネームを形成するように構成されている。マン/マシンインタフェイスは、利用者が第1生成オプションを選択すると第1ウィンドウを開き、これにより、利用者がそのウィンドウに入力するリンク・テーブル・ネームを第1カタログに加え、そしてデータベース6内に、入力されたネームによって名付けられた新しい最初は空のリンクテーブルを生成するように構成されている。

マン/マシンインタフェイスは、第1カタログ内のリンク・テーブル・ネームの選択又は付加後に、選択又は付加されたリンク・テーブルにおけるアクションの既存ネームの第2の空又は空でないカタログを、ドロップダウン・メニューの形で提案するように構成されている。ドロップダウン・メニューにおける第2カタログには、新しいアクション・ネームを生成するための第2オプションが取り付けられる。マン/マシンインタフェイスは、利用者が第2生成オプションを選択すると第2ウィンドウを開き、これにより、利用者がウィンドウに入力するアクション・ネームを第2カタログに加え、そしてデータベース6内に、入力されたネームによって名付けられたアクションを定義するデータ構造を生成するように構成されている。マン/マシンインタフェイスは、利用者によって定義された優先順位に従って、カレントリンク・テーブルで選択又は生成されたアクション・ネームを挿入するように構成されている。

マン/マシンインタフェイスは、第2カタログ内へのアクション・ネームの選択又は挿入後に、フィルタ・テーブル64における既存フィルタ・ネームの第3の空又は空でないカタログを、ドロップダウン・メニューの形で提案するように構成されている。ドロップダウン・メニューにおける第3カタログには、新しいフィルタ・ネームを形成するための第3オプションが取り付けられる。マン/マシンインタフェイスは、利用者が第3生成オプションを選択すると第3ウィンドウを開き、これにより、利用者がウィンドウに入力するフィルタ・ネームを第3カタログに加え、そしてテーブル64のカラム69内に、入力されたネームによって名付けられたフィルタを定義する組合せ論理を生成するように構成されている。マン/マシンインタフェイスは、第3カタログで選択又は生成されたフィルタ・ネームを、リンク・テーブル内に挿入されたアクション・ネームと連携させるように構成されている。

組合せ論理を生成するために、マン/マシンインタフェイスは、テーブル65における既存フィルタ・ネームの第4の空又は空でないカタログを、ドロップダウン・メニューの形で提案するように構成されている。ドロップダウン・メニューにおける第4カタログには、新しいルール・ネームを組合せ論理の中に形成するための第4オプションが取り付けられる。マン/マシンインタフェイスは、利用者が第4生成オプションを選択すると第4ウィンドウを開き、これにより、利用者がウィンドウに入力するルール・ネームを第4カタログに加え、そしてテーブル65のカラム60内に、入力されたネームによって名付けられたルールを定義する検証式を生成するように構成されている。第4ウィンドウは、次いでテーブル65のカラム39に記憶されるルールの自然的又は非自然的の意味を特定する可能性を利用者に提供することにより改善される。マン/マシンインタフェイスは、組合せ論理における論理演算子の引数として、第4カタログで選択又は付加されたそれぞれのルール・ネームを導入するように構成されている。

検証式を生成するために、マン/マシンインタフェイスは、プロトコル属性の既存ネームの第5の空又は空でないカタログを、ドロップダウン・メニューの形で提案するように構成されている。このカタログには、検証式にもたらされるべき新しいプロトコル属性ネームを形成するための第5オプションが加えられる。マン/マシンインタフェイスは、利用者が第5生成オプションを選択すると第5ウィンドウを開き、これにより、利用者がウィンドウに入力するプロトコル属性ネームを第5カタログに加えるように構成されている。マン/マシンインタフェイスは、テーブル65のカラム60内で、後にタイピングされた値が続けられる比較演算子を、第5カタログ内で選択又は付加されたプロトコル属性ネームと連結するように構成されている。

マン/マシンインタフェイスが、第4カタログに加えられたルール・ネームに対応して生成された検証式が、テーブル65内に予め存在するルール・ネームに対応する検証式と同一であることを検出すると、マン/マシンインタフェイスは、第4カタログ内にルール・ネームを加えずに、予め存在するルール・ネーム上に位置を合わせ、そしてテーブル65のカラム60において新しい検証式を生成しない。これにより、それぞれのルールはテーブル65内に1つ毎に一度だけ記述される。

マン/マシンインタフェイスが、第3カタログに加えられたフィルタ・ネームに対応して生成された組合せ論理が、テーブル64内に予め存在するフィルタ・ネームに対応する組合せ論理と同一であることを検出すると、マン/マシンインタフェイスは、第3カタログ内にフィルタ・ネームを加えずに、予め存在するフィルタ・ネーム上に位置を合わせ、そしてテーブル64のカラム69において新しい組合せ論理を生成しない。これによりそれぞれのフィルタはテーブル64内に1つ毎に一度だけ記述される。

こうしてデータベース6とカップリングされたマン/マシンインタフェイスは、デジタル通信データ上でトリガーされるべきアクション、及びアクションをトリガーするデータが属する意味フローをフレキシブルに定義することを利用者に許すか、又はかかる定義を行うことを選択することを可能にする。下記に説明するように、これらのデータの供給を受けるのは、プロトコル属性がフィルターを有効にするようなコネクションである。

具体的には、図1に関して説明したシステムにおいて、テーブル5はそれぞれの行に、データ構造50, 51, 52を指し示すポインターを含む。これらデータ構造は、テーブル5の対応行内に索引付けされたカレントコネクションに割り当てられた状態を記憶するように構成されている。

各データ構造50, 51, 52は、コネクション・リンク・テーブル53、フィルタ状態テーブル54及びルール状態テーブル55を含む。テーブル53のそれぞれの行は、異なるリンク・テーブル61, 62, 63に割り当てられる。これらのリンク・テーブルのアクション・ネームのうち、まだトリガーされ得るアクションの中の最高優先順位を有するアクション・ネームが、カラム49に索引付けされる。カラム49に索引付けされたそれぞれのアクション・ネームと、有効であるか又は不確定であるかの状態とがカラム48において連携する。テーブル54の各行は、カラム47に索引付けされたネームを有する異なるフィルタに割り当て可能である。カラム47に索引付けされたそれぞれのフィルタ・ネームと、有効であるか、無効であるか又は不確定であるかの状態とがカラム46において連携する。テーブル55の各行は、カラム45に索引付けされたネームを有するルールに割り当て可能である。カラム45に索引付けされたそれぞれのフール・ネームと、有効であるか、無効であるか又は不確定であるかの状態とがカラム44において連携する。

デジタル通信データ内に検出された新しいコネクションに対応してテーブル5の行を形成すると、リンク・テーブル53は、リンク・テーブル61, 62, 63の行の全てを再現した像で初期化される。これにより各リンク・テーブル61, 62, 63の各アクション・ネームをカラム49内に含有し、それぞれの連携フィルタ・ネームをカラム48内に含有する。テーブル54及び55は最初は空である。

テーブル53, 54及び55の、図6に示された構造の場合、コネクションの処理中に、コネクションの進行が続いて記述されることになる。

図1に関して説明されたシステムは、各使用可能なプロトコルに対応して、プロトコル属性40, 41, 42, 43のインタフェイスを含む。各プロトコル属性インタフェイスは、特定プロトコルに割り当てられる。この特定プロトコルに関して、プロトコル属性インタフェイスは、通信データの中から、所定のプロトコル属性において特定されるようなパラメータ値を抽出するように構成される。このプロトコル属性は、このパラメータを使用するものとしてこの特定プロトコルを指示する。マン/マシンインタフェイスは、プロトコル属性ネームが第5カタログ内に加えられる場合、及びパラメータ値を復元するように構成されたプロトコル属性インタフェイスがない場合に、好適なプロトコル属性インタフェイスをロードすることを利用者に求めるように構成されていることが有利である。このシステムは、任意のプロトコル・アーキテクチャの改変を考慮に入れるようにフレキシブルに構成することができる。

なお、一方においてデータベース6を用いてアクション及び意味フローを定義し、他方においてプロトコル属性インタフェイスを用いて可能なプロトコル・アーキテクチャを定義することは、独立して達成可能である。
フィルタリング・エンジン1を、テーブル5及びデータベース6を読むように構成することにより、図4及び図5に関連して今説明した方法を実行するように、データ構造50, 51, 52を読み書きし、そしてプロトコル属性インタフェイス40, 41, 42, 43を作動させる。

この方法は、通信データがステップ100においてパケット毎に伝送される特定の事例に関してここでは記載される。有利なのは、通信データがこれらのパケットを記憶する必要なしにパケット毎に受信される限り、リアルタイムでその通信データを処理できることである。この方法は、例えば毎日の通信データの包括的な処理(バッチ処理)に適合することができ、これらのステップは、実質的に同じままである。むしろ、トリガーされるべきアクションに区別が生じる。ファイヤーウォール・リンク及びサービス・リンクのテーブルのアクションは、リアルタイム処理に関してより有益であり、測定リンク又は圧縮リンクのテーブルのアクションは、静的処理のフレームワーク内と同様に、リアルタイム処理のフレームワーク内において有益である。

パケットがステップ100においてフィルタリング・エンジン1に到達すると、これに伴って、そのパケットが属するカレント・コネクションに対応するテーブル5の行が参照される。
パケットを伴う参照は、フィルタリング・エンジン1がステップ101において、カレントコネクションと連携するデータ構造50, 51, 52の1つを指し示すポインターを検索するのを可能にする。図4で使用された参照50は、例えば、指し示されたデータ構造が構造50である場合に対応するが、しかし、下記説明は他のいかなるデータ構造にも依然として適している。

更新ステップ103において、フィルタリング・エンジンはテーブル54及びテーブル55から、それぞれカラム46及びカラム44内に含有された状態が不確実であるような行全てを削除する。状態が不確実であるのは、対応するルール及びフィルタがカレント通信データに対して再評価されるべきであるからである。
ステップ102において、フィルタリング・エンジン1はテーブル53を、第1行で始まる行毎に走査する。走査された行毎に、フィルタリング・エンジン1は、テーブル54のカラム47を介して、走査されたテーブル53の行のカラム48によって参照されたフィルター・ネームを検索する。

カラム47にフィルター・ネームを含むテーブル54の行がない場合、フィルタリング・エンジン1は、カラム47内にフィルター・ネームを有するテーブル54に、行を加える。次いで、カレント・コネクションは再び、カラム47内に加えられたネームを有するフィルタによって決定される意味ストリームに関連して分類されることになる。このとき、フィルタリング・エンジン1は、連続するステップ104〜110をトリガーして、フィルタを評価してから、ステップ102へ戻る。

テーブル54の行が、カラム46内に無効状態(-1)を有するフィルター・ネームを含有する場合、フィルタリング・エンジン1は、カラム48内にこのフィルター・ネームを含有するテーブル53から、行を削除する。次いで、フィルタリング・エンジン1は、テーブル53内に次の行が存在するかどうかを試験する。テーブル53内に次の行が存在しない場合、フィルタリング・エンジン1は、図4に関して説明したプロセスを出る。それというのも、意味フローに関してカレント・コネクションを分類する必要がもはやないからである。テーブル53内に次の行が存在する場合、この行を走査することにより、前述及び後述のようなステップ102を実行し続ける。

テーブル54の行が、カラム46内に不確定状態(0)を有するフィルター・ネームを含有する場合、フィルタリング・エンジン1は、テーブル53内に次の行が存在するかどうかを試験する。テーブル53内に次の行が存在しない場合、フィルタリング・エンジン1は、図4に関して説明したプロセスを出る。それというのも、意味フローに関してカレント・コネクションを分類する必要がもはやないからである。テーブル53内に次の行が存在する場合、この行を走査することにより、前述及び後述のようなステップ102を実行し続ける。

テーブル54の行が、カラム46内に有効状態(+1)を有するフィルター・ネームを含有する場合、フィルタリング・エンジン1は、現在走査された行よりも優先順位が低いアクション・ネームをカラム49内に含有するテーブル53の行を削除する。次いで、フィルタリング・エンジン1は、テーブル53内に次の行が存在するかどうかを試験する。テーブル53内に次の行が存在しない場合、フィルタリング・エンジン1は、図4に関して説明したプロセスを出る。それというのも、意味フローに関してカレント・コネクションを分類する必要がもはやないからである。テーブル53内に次の行が存在する場合、この行を走査することにより、前述のようなステップ102を実行し続ける。

ステップ104において、フィルタリング・エンジン1は、テーブル64の行を示す。このテーブル64は、テーブル54のカラム47内のフィルター・ネームと同じフィルター・ネームをカラム68に含み、これにより、フィルタを評価するのに必要となるルールの組合せ論理を、カラム69内に得る。次いで、フィルタリング・エンジン1は、組合せ論理における論理演算子の引数と見なされるルールに対応して、一連のステップ105〜109をトリガーする。これらのステップは、組合せ論理のルール全てが検討されるまで、或いは、有効又は無効の決定的な状態に関するフィルタの評価が得られるまで繰り返される。

ステップ105において、フィルタリング・エンジン1は、テーブル55を通して、カラム45内にルール・ネームを含有する行を検索する。この検索は、テーブル55の行内に含まれないルール・ネームに到達するまで行われる。
ルール・ネームがテーブル55の行内に含まれない場合には、フィルタリング・エンジン1は、カラム45内にルール・ネームを有するテーブル55に行を加える。ルールがいわゆる非自然的意味を有する場合、フィルタリング・エンジン1は、行のカラム44に不確定状態の値0を設ける。それというのも、このルールの評価に必要なデータがカレント・コネクションには存在せず、ピア・コネクションに存在するからである。ルールが自然的意味を有している場合には、フィルタリング・エンジン1は、ルールを評価するためのステップ106をトリガーする。

ステップ106において、フィルタリング・エンジン1はテーブル65の行にアクセスする。テーブル65は、テーブル55に加えられた行のカラム45と同じルール・ネームをカラム59内に含むことにより、カラム60内で連携する検証式をロードする。フィルタリング・エンジンは、プロトコル・インタフェイス40, 41, 42, 43のうちの、プロトコル属性の構文によって特定されたプロトコルに割り当てられるものに、プロトコル属性ネームを提供する。次いで、プロトコル・インタフェイスはカレント・通信データを通して、プロトコル属性の値を検索する。プロトコル・インタフェイスが、提供されたプロトコル属性値を見いだす場合、プロトコル・インタフェイスはフィルタリング・エンジンにこの値を送信し、そしてカレント・コネクション専用のレジスターにこの値を記憶する。プロトコル・インタフェイスが、提供されたプロトコル属性値を見いださない場合、プロトコル・インタフェイスは、この値が見いだされないことを指示する信号を、フィルタリング・エンジンに送信する。

プロトコル・インタフェイスが、値が見いだされないことを指示する信号を送信する場合、フィルタリング・エンジンは、不確定状態にあるものとしてこのルールを試験する。
プロトコル・インタフェイスがプロトコル属性の値を伝送するときに、送信された値が検証式の条件を満たす場合には、フィルタリング・エンジンは有効状態にあるものとしてルールを評価し、そして送信された値が検証式の条件を満たさない場合には、無効状態にあるものとしてルールを評価する。

ステップ107において、フィルタリング・エンジンは、テーブル55の対応カラム44において評価されたルールの状態を記憶する。
フィルタ評価ステップ108において、フィルタリング・エンジン1は、真理値テーブル55, 56, 57, 58に従って、カラム69内に含有される組合せ論理を、カラム60内に含まれるルール状態に適用する。

ステップ109において、フィルタリング・エンジン1は、評価されたフィルタの状態が不確実であるかどうか、また、ルールがフィルタの組合せ論理に関してまだ評価されていないかどうかを試験する。
評価されたフィルタの状態が不確実である場合、またルールがフィルタの組合せ論理に関してまだ評価されていない場合、フィルタリング・エンジン1はステップ104に戻り、組合せ論理において評価されるべき次のルール上に位置する。
逆の場合、フィルタリング・エンジンはステップ110をトリガーする。

ステップ110において、ステップ102に戻ってその実行を続ける前に、フィルタリング・エンジンは、テーブル54のカラム46内で評価されたフィルタの状態を記憶する。フィルタリング・エンジン1は、図4に関して説明したプロセスを出ると、より有利には、図5に関して説明したプロセスに入る。図5に関して説明したプロセスは、通信データにおける情報項目を考慮に入れることを可能にする。これらの情報項目は、カレント・コネクションのピア・コネクションを分類するための意味フローを決定するのに有用である。

ステップ111において、フィルタリング・エンジンは、テーブル5に索引付けされたピア・コネクションを検索する。テーブル5は、ピア・コネクションの行において、カレント・コネクションのデータ構造とは異なるデータ構造を指し示すポインターを含む。いまポインターがデータ構造52を指し示すと想定する。
データ構造52のテーブル55のカラム45に索引付けされたネームを有する、いわゆる非自然的意味の各ルールに対応して、一連のステップ114〜116がトリガーされる。

ステップ114において、フィルタリング・エンジン1は、評価されるべき又は再評価されるべき非自然的意味のルールを選択する。評価されるべき又は再評価されるべきルールを、その状態が不確実であると考えることは、評価されるべきルールの数を制限することにより、良好な処理速度を維持するのを可能にする。評価されるべき又は再評価されるべきルールをすべて非自然的意味のルールであると考えることは、ルールの状態を変化させ得るプロトコル属性の改変を考慮に入れるのを可能にする。

ルール評価ステップ115において、フィルタリング・エンジンは、プロトコル属性の構文によって特定されたプロトコルに割り当てられたプロトコル・インタフェイスに、検証式のプロトコル属性ネームを提供する。プロトコル・インタフェイスがプロトコル属性値を戻す場合、フィルタリング・エンジンは、戻された値に検証式を適用することにより、ルールの状態を計算する。プロトコル・インタフェイスがいずれのプロトコル属性値も戻さない場合、フィルタリング・エンジンは、ルールの状態を変化させないままにする。

ステップ116において、フィルタリング・エンジン1は、データ構造52のテーブル55のカラム45にルールの状態を記憶する。
1つ又は2つ以上の意味フローにおいてピア・コネクションの分類を完了するのに必要なルールだけに、非自然的意味のルールの評価を制限するために、ステップ112は、ピア・コネクションがなおも分類されるべきかどうかを決定するように構成される。
ステップ112において、フィルタリング・エンジンは、データ構造52のテーブル54を通して、カラム46内の不確実な状態を有するフィルター・ネームを検索する。不確実な状態のフィルター・ネーム毎に、フィルタリング・エンジンはステップ113をトリガーする。テーブル54を介した検索が終わると、フィルタリング・エンジンはステップ117をトリガーする。

テーブル54内で不確定状態と連携するネームを有するフィルターを選択するのに対応するステップ113において、フィルタリング・エンジンは、組合せ論理のルールのネームがテーブル64におけるこのフィルター・ネームと連携するとみなし、非自然的意味の各ルール・ネームに対応する一連のステップ114〜116を実行する。

意味フローへのコネクションの所属は所定の時間経過後に変化してよい。このことは例えば、同一の低レベル・コネクションにおいていくつかのエンド・ツー・エンド・コネクションを多重化する場合、又は画像に対応する意味とテキストに対応する意味とで異なる意味をコネクションが有するとき、画像の所与の瞬間と、続いて画像に関連するテキストの別の瞬間とで、コネクションが移る場合に、発生し得る。
本発明による方法の実施は、ステップ103を下記のように改善することにより増強される。

更新ステップ103において、パケット内に含まれる通信データは、各プロトコル・インタフェイス40, 41, 42, 43によって探索される。このプロトコル・インタフェイスは既に、パケットが属するカレント・コネクションに関して、フィルタリング・エンジン1によって問合わせられている。プロトコル・インタフェイスがプロトコル属性に対応する値の変化を検出し、この値をフィルタリング・エンジンに予め通信している場合には、プロトコル・インタフェイスは、値が変化するプロトコル属性のネームをフィルタリング・エンジンに通知する。

フィルタリング・エンジンは、このプロトコル属性をテーブル65内で使用するルールと、この又はこれらのルールをテーブル64内で使用するフィルタと、次いで、こうしてリンク・テーブル61, 62, 63内で決定されたフィルター・ネームと連携するネームを有するそれぞれのアクションとを決定する。
こうして決定された各アクション・ネームに関して、フィルタリング・エンジン1は、以下の基準との関連において、テーブル53に行を加えるか又は加えないかを決める。

リンク・テーブル(例えば61)のいくつかのアクションが同時にトリガーされてよい場合には、フィルタリング・エンジンは、リンク・テーブル61によって定義された順序に従う一方、テーブル53内に行のコピーを挿入する。この行は、テーブル61内で決定されたアクション・ネームに対応する。この行のコピーがテーブル53内に既に存在する場合には、フィルタリング・エンジンはテーブル54から、対応フィルタ行を削除することにより、必要な場合にフィルタの新しい評価を指示する。

リンク・テーブル(例えば62又は63)の単一のアクションがトリガー可能であるとき、つまり、有効状態を有する最優先順位アクション又はデフォルト・アクションであるときには、フィルタリング・エンジンは、リンク・テーブル62, 63によって定義された順序に従う一方、決定されたアクションが、トリガー可能なアクションよりも高い優先順位を有している場合、且つこれを有している場合にのみ、テーブル53内に、テーブル61内で決定されたアクション・ネームに対応する行のコピーを挿入する。この行のコピーがテーブル53内に既に存在する場合には、フィルタリング・エンジンはテーブル54の対応フィルタ行を削除することにより、必要な場合にフィルタの新しい評価を指示する。

ステップ117は、このステップを必要とする意味のルール全てが、自然的意味のルールに関して図4を参照しながら説明したプロセスで評価されており、また補足的に、非自然的意味のルールに関して図5を参照しながら説明したプロセスで評価されている場合に実行される。

ステップ117において、フィルタリング・エンジンは、受信されたパケットを、アクション・エンジン2に送信する。
アクション・エンジン2は、カレント・コネクションのデータ構造50のテーブル53を指し示す。アクション・ネームとテーブル53内で連携するフィルター・ネームとテーブル54内で連携する状態との関連において、アクション・エンジン2は、アクションがトリガーされるべきか、又はされるべきでないのかを決める。

リンク・テーブルのいくつかのアクション(例えば61)が同時にトリガー可能である場合には、アクション・エンジンは、テーブル54内の有効状態にあるフィルター・ネームとテーブル53で連携するネームを有するアクション全てをトリガーし、或いは、テーブル54内の有効状態にあるフィルター・ネームとテーブル53で連携するネームを有するアクションが存在しない場合には、テーブル54内の不確定状態にあるフィルター・ネームとテーブル53で連携するネームを有するアクション全て、又はデフォルト・アクションを、このリンクテーブルに対応する所定のトリガー規定に従ってトリガーする。

リンクテーブルの単一のアクション(例えば62又は63)がトリガー可能あるとき、つまり、有効状態を有する最優先順位アクション又はデフォルト・アクションであるときには、アクション・エンジン2は、テーブル54内の有効状態にあるフィルター・ネームとテーブル53で連携するネームを有するアクションをトリガーし、或いは、テーブル54内の有効状態にあるフィルター・ネームとテーブル53で連携するネームを有するアクションが存在しない場合には、デフォルト・アクションをトリガーする。

アクション・エンジンは、データベース6内に与えられた定義に従って、各アクションをトリガーする。前に見られたように、トリガーされた或る特定のアクションは、ヘッダの内容又はパケット本体の内容を変更する傾向がある。その後、アクション・エンジン2は出力7に移る。パケットは、トリガーされた種々のアクションを被る。

本発明のコンピュータ・システムの構成図である。 図1のコンピュータ・システムのデータベース構造を示すテーブルである。 本発明のための真理値テーブルである。 本発明の方法を構成するステップの論理フローチャートである。 本発明の方法を構成するステップの論理フローチャートである。 本発明の方法を実行中におけるコンピュータ・システムのデータ構造を示すテーブルである。

Claims (10)

1. デジタル通信データが同一の意味フローに属するとき、この意味フローに対応する少なくとも1つのアクションを、デジタル処理装置(1,2)を介して前記デジタル通信データに対してトリガーする方法であって、
   それぞれが意味フロー中に使用される順序付けされた一連のプロトコル・ネーム及び前記順序付けされた一連のプロトコル・ネーム中にそのネームが指示されるプロトコルに搬送されるパラメータによって特定される、前記意味フローに対応して指定される1つ又は2つ以上のプロトコル属性の1つ又は2つ以上の条件に起因する3つの状態、すなわち、前記1つ又は2つ以上の条件が満足されることを裏付けるプロトコル属性値に対応する有効状態と、前記1つ又は2つ以上の条件が満足されないことを裏付けるプロトコル属性値に対応する無効状態と、前記1つ又は2つ以上の条件が満足されるかされないかを裏付けるプロトコル属性値の不在に対応する不確定状態とを有する少なくとも1つのフィルタを前記装置(1,2)に供給するステップと、
   フィルタが前記不確定状態を生ずる値以外のプロトコル属性値を前記通信データが提供しなかった場合に限り、デジタル処理装置(1,2)によって前記通信データに3-状態フィルタを適用するステップ(108)と、
   通信データが提供するプロトコル属性値からフィルタが前記有効状態を生ずるとき、デジタル処理装置(2)によって前記アクションをトリガーするステップと、
   を含むことを特徴とする前記方法。
2. 前記通信データにフィルタを適用するため、
   フィルタの状態が有効又は無効と判明するまで、又はプロトコル属性がすべて送り出されるまで(109)、デジタル処理装置(1)によって、順序付けされた一連のプロトコル・ネーム中に示されるプロトコルに割当てられたプロトコル・インタフェイス(40,41,42,43)に前記プロトコル属性を逐次送り出し、
   プロトコル・インタフェイス(40,41,42,43)によって特定パラメータの値を通信データ中から検索して、発見したらこの値をデジタル処理装置へ送信し、
   デジタル処理装置（1）によって、プロトコル・インタフェイス(40,41,42,43)によって送信された値又はこの値の不在に対応するフィルタ状態を評価する
   、請求項1に記載の方法。
3. 前記デジタル処理装置に供給するそれぞれのフィルタを第1テーブル(64)中のルールの組合せ論理によって決定され、それぞれのルールが、第2テーブルにおいて、プロトコル属性を引数とする少なくとも1つの比較演算子を含む検証式によって決定される、請求項1又は2に記載の方法。
4. プロトコル・インタフェイスによって送信される値又は値の不在に対応するフィルタ状態を評価するため、デジタル処理装置によって値の送信に応じて組合せ論理中の少なくとも1つのルールの状態を評価し、次いで、評価されたルールの状態に適用された組合せ論理によって決定される状態を評価する、請求項2及び3に記載の方法。
5. デジタル通信データを走査してプロトコル属性値の変化を検出することによって、値の変化に対応するフィルタ状態変化の評価を可能にするステップ(103)を含む、請求項1から4までのいずれか1項に記載の方法。
6. デジタル通信データが同一の意味フローに属するとき、この意味フローに対応する少なくとも1つのアクションを、前記デジタル通信データに対してトリガーするコンピュータ・システムであって、
   フィルタリング・エンジン(1)及びアクション・エンジン(2)を有するデジタル処理装置と、
   前記意味フローに対応して指定される1つ又は2つ以上のプロトコル属性の1つ又は2つ以上の条件に起因する3つの状態を有する少なくとも1つのフィルタをフィルタリング・エンジン（1）に供給するためのデータベース(6)と；
   それぞれが意味フロー中に使用される順序付けされた一連のプロトコル・ネーム及び前記順序付けされた一連のプロトコル・ネーム中にそのネームが指示されるプロトコルに搬送されるパラメータによって特定されるプロトコル属性値であって、前記1つ又は2つ以上の条件が満足されることを裏付けるプロトコル属性値に対応する有効状態と、前記1つ又は2つ以上の条件が満足されないことを裏付けるプロトコル属性値に対応する無効状態と、前記1つ又は2つ以上の条件が満足されるかされないかを裏付けるプロトコル属性値の不在に対応する不確定状態とのカタログを設ける少なくとも1つのデータ構造(50,51,52)と、
   フィルタが前記不確定状態を生ずる値以外のプロトコル属性値を前記通信データが提供しなかった場合に限り、フィルタリング・エンジン(1)が前記通信データにそれぞれ必要なフィルタを適用するのに利用できる通信データ受信手段(100)と、
   データ構造(50,51,52)中に前記有効状態が含まれるとき、前記アクションをトリガーするためにアクション・エンジン(2)が利用できる通信データ送信手段(117)と、
   を備えることを特徴とする、前記コンピュータ・システム。
7. 意味フロー中の利用可能なそれぞれのプロトコルに割当てられ、フィルタリング・エンジン(1)から、割当てたプロトコルに応じて定められたプロトコル属性を受信するプロトコル・インタフェイス(40,41,42,43)を含み、
   プロトコル・インタフェイス(40,41,42,43)は特定パラメータの値を通信データ中から検索して、発見したらこの値をフィルタリング・エンジン(1)へ送信し、
   フィルタリング・エンジン(1)は、プロトコル・インタフェイス(40,41,42,43）によって送信された値又はこの値の不在に対応するフィルタ状態を評価する、
   請求項6に記載のコンピュータ・システム。
8. データベース(6)が各フィルタに関するルールの組合せ論理を含む第1テーブル(64)と、各ルールに関して、プロトコル属性を引数とする少なくとも1つの比較演算子を含む検証式を含む第2テーブル(65)とを備える、請求項6又は7に記載のコンピュータ・システム。
9. プロトコル・インタフェイスによって送信される値又は値の不在に対応するフィルタ状態を評価するため、デジタル処理装置が値の送信に応じて組合せ論理中の少なくとも1つのルールの状態を評価し、次いで、評価されたルールの状態に適用された組合せ論理によって決定される状態を評価する、請求項7又は8に記載のコンピュータ・システム。
10. データベース(6)が、特定フィルタに連携するそれぞれの意味フローに対応する幾つかのアクション・ネームを含む少なくとも1つの第3テーブル(61,62,63)を有する、請求項6から9までのいずれか1項に記載のコンピュータ・システム。

Images