(57)【要約】コンピュータアプリケーションへのアプリケーション層リクエストをスクリーニングするためのルールの作成を容易にするために、アプリケーション層リクエストのサンプルスペースを、１つ以上のグルーピング基準に従いグルーピングする。各グルーピング基準は、各グルーピングが共通の特徴を持つアプリケーション層リクエストを含むような、アプリケーション層リクエストの特徴でありうる。例えば、アプリケーション層リクエストがハイパーテキスト転送プロトコル（ＨＴＴＰ）に従う場合、いくつかのグルーピングに共通の特徴は、共通ＵＲＩパス名拡張子でありうる。アプリケーション用のルールセットは、アプリケーション中のエラーを顕在化するのに使用されうる。ルールのうち少なくとも１つに違反するテストリクエストが構築される。アプリケーションが予想される例外を投げかけるかどうかを検査するために、テストリクエストはアプリケーションに受け渡される。
2006501551.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション層リクエストをスクリーニングするためのルールの作成を容易にする方法であって、
アプリケーション層リクエストのサンプルスペース由来のアプリケーション層リクエストを、該リクエストの特徴によってグルーピングすることを含む、方法。
【請求項２】
前記特徴が、宛先アドレス識別子の部分である、請求項１に記載の方法。
【請求項３】
前記アプリケーション層リクエストが、ハイパーテキストプロトコル（ＨＴＴＰ）リクエストであり、前記宛先アドレス識別子が、普遍資源識別子（ＵＲＩ）である、請求項２に記載の方法。
【請求項４】
前記ＵＲＩの前記部分が、ＵＲＩパス名拡張子である、請求項３に記載の方法。
【請求項５】
前記グルーピングに使用されるＵＲＩパス名拡張子が、予め決められている、請求項４に記載の方法。
【請求項６】
前記グルーピングに使用されるいくつかのＵＲＩパス名拡張子が予め決められており、その他の各々が前記リクエストの閾値のＵＲＩで使用されているＵＲＩパス名拡張子として決められている、請求項４に記載の方法。
【請求項７】
前記グルーピングによってグルーピングされていないＨＴＴＰリクエストの残りについて、該残りのＵＲＩパス名のディレクトリ名プレフィックス部分によって該残りのリクエストをグルーピングすることをさらに含む、請求項４に記載の方法。
【請求項８】
前記グルーピングに使用されている前記ディレクトリ名プレフィックス部分が予め決められている、請求項７に記載の方法。
【請求項９】
前記グルーピングに使用されている前記ディレクトリ名プレフィックス部分のいくつかが予め決められており、その他の各々が、前記リクエストの閾値のＵＲＩで使用されているディレクトリ名プレフィックス部分として決められている、請求項７に記載の方法。
【請求項１０】
まだグルーピングされていないＨＴＴＰリクエストの第２の残りについて、該第２の残りのＵＲＩパス名内のストリングパターンによって、該第２の残りのリクエストをグルーピングすることをさらに含む、請求項７に記載の方法。
【請求項１１】
まだグルーピングされていないＨＴＴＰリクエストの第３の残りについて、該第３の残りのリクエストのサブセットをグルーピングすることをさらに含み、該サブセットの各リクエストが共通のプロパティを有する、請求項１０に記載の方法。
【請求項１２】
前記共通のプロパティが予め決められたコンテンツタイプである、請求項１１に記載の方法。
【請求項１３】
前記共通のプロパティが予め決められたコンテンツタイプ及びリクエストの前記サブセットの閾値で使用されているコンテンツタイプのうちの１つである、請求項１１に記載の方法。
【請求項１４】
前記リクエストの各構成要素タイプに適用可能なデータテンプレートのセットを得ることをさらに含み、
該リクエストの構成要素の各タイプについて、該各リクエストのグルーピングのリクエスト中に見出される名及び関連付けられたデータ要素を同定し、
各名について、
各データ要素が該各名のインスタンスと関連付けられているデータ要素のサンプルグループを得、
データ要素の該サンプルグループをデータ要素テンプレートと適合させ、そして
該適合するデータテンプレートに基づいて、ルールを該各名に結び付けることによって、
各リクエストのグルーピングについてのルールセットを得ることをさらに含む、
請求項１に記載の方法。
【請求項１５】
各名について、データ要素の前記セット中の最も長いデータ要素の長さを決定すること、及び、該長さとしてデータ要素の最大許容長さを規定するさらなるルールを該各名に結び付けることをさらに含む、請求項１４に記載の方法。
【請求項１６】
データ要素の前記セット中の前記データ要素が数字である場合、データ要素の前記セット中の最も長い値のデータ要素の値及びデータ要素の該セット中の最も小さい値のデータ要素の値を決定し、そして、該最も長い値のデータ要素の該値に基づくデータ要素の最大許容値及び該最も小さい値のデータ要素の該値に基づく最小許容値を規定するさらなるルールを該各名に結び付ける、請求項１４に記載の方法。
【請求項１７】
各リクエストのグルーピングについて、該各リクエストのグルーピングの各リクエストに存在する要素を検索すること、及び、該各リクエストのグルーピングの各リクエストに存在する所定の要素を見出したときに、該所定の要素の存在を必要とする該各リクエストのグルーピングについての存在に関するルールを確立することをさらに含む、請求項１４に記載の方法。
【請求項１８】
少なくとも１つの所定の数のインスタンス化において前記各リクエストのグルーピングの各リクエストに、前記所定の要素が存在することが見出された場合、該各リクエストのグルーピング用の前記存在に関するルールが、前記最小数のインスタンス化における該所定の要素の存在を必要とするように設定される、請求項１７に記載の方法。
【請求項１９】
各リクエストのグルーピングについて、該リクエストのグルーピング中のリクエストのプロパティの統計的尺度を決定すること、及び、該統計的尺度に基づいて、該各リクエストのグルーピングについての統計的ルールを設定することをさらに含む、請求項１４に記載の方法。
【請求項２０】
各リクエストのグルーピングについて、前記ルールセットについてのトリガーを設定することをさらに含み、該トリガーが、該各リクエストのグルーピングをそれによって形成した特徴を含む、請求項１４に記載の方法。
【請求項２１】
アプリケーション層リクエストをスクリーニングするためのルールセットを作成する方法であって、
該リクエストの各構成要素タイプに適用可能なデータテンプレートのセットを得ること、
１つ以上のグルーピング基準を利用して、アプリケーション層リクエストをグルーピングすることを含み、
該リクエストの構成要素の各タイプについて、該各リクエストのグルーピングのリクエストに見出される名及び関連付けられたデータ要素を同定し、
各名について、
各データ要素が該各名のインスタンスと関連付けられたデータ要素のサンプルグループを得、
データ要素の該サンプルグループをデータ要素テンプレートと適合させ、そして
該適合するデータテンプレートに基づいて、ルールを該各名に結び付けることによって、各リクエストのグルーピング用のルールセットを得ることを含む、
方法。
【請求項２２】
ハイパーテキストプロトコル（ＨＴＴＰ）リクエストをスクリーニングするためのルールセットの作成を容易にする方法であって、
該リクエストの普遍資源識別子（ＵＲＩ）パス名拡張子によって、ＨＴＴＰリクエストのサンプルスペース由来のＨＴＴＰリクエストをグルーピングすることを含む、方法。
【請求項２３】
アプリケーション層リクエストをスクリーニングするためのルールの作成を容易にするシステムであって、
アプリケーション層リクエストのサンプルスペースを記憶するためのデータベースと、
アプリケーション層リクエストの該サンプルスペース由来のアプリケーション層リクエストを該リクエストの特徴によってグルーピングするためのルールジェネレータと
を備える、システム。
【請求項２４】
プロセッサにロードされたときに、アプリケーション層リクエストのサンプルスペース由来のアプリケーション層リクエストを、該リクエストの特徴によってグルーピングするよう該プロセッサを適応させるコンピュータ実行可能命令を含む、コンピュータ読取可能媒体。
【請求項２５】
アプリケーション層リクエストをスクリーニングするためのルールセットを作成するためのシステムであって、
該リクエストの各構成要素タイプに適用可能なデータテンプレートのセットを得るための手段と、
１つ以上のグルーピング基準を利用して、アプリケーション層リクエストをグルーピングするための手段とを備え、
該リクエストの構成要素の各タイプについて、該各リクエストのグルーピングのリクエストに見出される名及び関連付けられたデータ要素を同定し、
各名について、
各データ要素が該各名のインスタンスと関連付けられたデータ要素のサンプルグループを得、
データ要素の該サンプルグループをデータ要素テンプレートと適合させ、そして
該適合するデータテンプレートに基づいて該各名にルールを結び付けることによって、
各リクエストのグルーピング用のルールセットを得るための手段とを備える、
システム。
【請求項２６】
プロセッサにロードされたときに、
該リクエストの各構成要素タイプに適用可能なデータテンプレートのセットを得、
１つ以上のグルーピング基準を利用してアプリケーション層リクエストをグルーピングし、
該リクエストの構成要素の各タイプについて、該各リクエストのグルーピングのリクエストに見出される名及び関連付けられたデータ要素を同定し、
各名について、
各データ要素が該各名のインスタンスと関連付けられたデータ要素のサンプルグループを得、
データ要素の該サンプルグループをデータ要素テンプレートと適合させ、そして、
該適合するデータテンプレートに基づいて該各名にルールを結び付けることによって、
各リクエストのグルーピングのためのルールセットを得るように、該プロセッサを適応させるコンピュータ実行可能命令を含む、コンピュータ読取可能媒体。
【請求項２７】
コンピュータアプリケーション中のエラーをテストする方法であって、
アプリケーションに対する不正な入力をスクリーニングするためのルールセットを得ること、
各テスト入力が該ルールセットのうちの少なくとも１つのルールに違反するテスト入力を構築すること、
該テストリクエストを該アプリケーションに受け渡すこと、
該テスト入力に対する該アプリケーションからの応答に基づいて、該アプリケーション中のエラーの存在を決定すること
を含む、方法。
【請求項２８】
各テスト入力がテストリクエストであり、各テストリクエストが、前記ルールセットによって、リクエスト内のオブジェクトに固有の少なくとも１つのプロパティに違反する、請求項２７に記載の方法。
【請求項２９】
テストリクエストが、普遍ルール、単純な存在に関するルール、複合の存在に関するルール、複合の普遍ルール、及び統計的ルールのうちの少なくとも１つに違反する、請求項２８に記載の方法。
【請求項３０】
プロセッサにロードされたときに、
アプリケーションに対する不正な入力をスクリーニングするためのルールセットを得、
各テスト入力が該ルールセットのうちの少なくとも１つのルールに違反するテスト入力を構築し、
該テストリクエストを該アプリケーションへと受け渡し、
該テスト入力に対する該アプリケーションからの応答に基づいて、該アプリケーション中のエラーの存在を決定する
ように該プロセッサを適応させるコンピュータ実行可能命令を含む、コンピュータ読取可能媒体。
【請求項３１】
アプリケーションに対する不正な入力をスクリーニングするためのルールセットを得るための手段と、
各テスト入力が該ルールセットのうちの少なくとも１つのルールに違反するテスト入力を構築するための手段と、
該テストリクエストを該アプリケーションへ受け渡すための手段と、
該テスト入力に対する該アプリケーションからの応答に基づいて、該アプリケーション中のエラーの存在を決定するための手段と
を備える、アプリケーションテスタ。
【発明の詳細な説明】
【背景技術】
【０００１】
発明の背景
【０００２】
本発明は、コンピュータアプリケーションへのリクエストをスクリーニングするためのルール作成の容易化に関する。
【０００３】
コンピュータネットワークでは、情報はパケット形式で通常伝送される。情報の流れは、通常、コンピュータアプリケーションに対して為されるリクエストとアプリケーションによる該リクエストへの応答の形式である。パケットが信頼されていないソース（例えば、公衆インターネット）から来た場合、それらがコンピュータアプリケーションへの不正なリクエストを含んでいる（ｃｏｍｐｒｉｓｅ又はｃｏｎｔａｉｎ）危険性がある。そのような不正なリクエストは、所有者の情報へアクセスしようとする未許可の試み、情報を改竄しようとする未許可の試み、又はアプリケーションの通常の動作に干渉しようとする試み（所謂、「ＤｏＳ攻撃」）を構成しうる。
【０００４】
コンピュータ上のアプリケーションは、アプリケーションに向けられたパケットをフィルタリングするコンピュータファイアウォールによって、不正なリクエストから保護されうる。より詳細には、ファイアウォールはパケットを検証し、予め定義されたアクセスルールのセットにそれらが一致するかどうかによって、それらをアプリケーションへと受け渡すかまたはそれらを破棄する。公知のパケットフィルタリングファイアウォールは、使用されているプロトコルを検証するために、１つ以上のリンク層、ネットワーク層及びトランスポート層のパケットヘッダにルールを適用しうる。
【０００５】
不正なリクエストからアプリケーションを保護するための別のアプローチには、プロキシファイアウォールの採用がある。プロキシファイアウォールは、公衆ネットワークを介して到達するパケットの宛先として機能し、各パケットから公衆ネットワークを介するパケットの方向付けに使用されたオーバーヘッドを取り除く。このアプローチにより、パケットのネットワークオーバーヘッドを使用するいずれの攻撃も回避される。公知のプロキシファイアウォールはまた、アプリケーションプロトコルを検証するために、ルールを適用しうる。
【０００６】
パケットフィルタリングファイアウォール及びプロキシファイアウォールは、多くの不正なリクエストをスクリーニング除去するのに効果的であるが、そのようなファイアウォールを破るうまい「攻撃」が未だ発生している。従って、コンピュータアプリケーションへのリクエストのより効果的なスクリーニングを可能とするアクセスルールの必要性が存在する。
【発明の開示】
【課題を解決するための手段】
【０００７】
発明の要旨
【０００８】
コンピュータアプリケーションへのアプリケーション層リクエストをスクリーニングするためのルールの作成を容易にするため、アプリケーション層リクエストのサンプルスペースを、１つ以上のグルーピング基準に従い、グルーピングする。各グルーピング基準は、各グルーピングが共通の特徴を持つアプリケーション層リクエストを含むようなアプリケーション層リクエストの特徴でありうる。例えば、アプリケーション層リクエストがハイパーテキスト転送プロトコル（ＨＴＴＰ）に従う場合、いくつかのグルーピングの共通の特徴は、共通のＵＲＩパス名拡張子でありうる。
【０００９】
アプリケーション用のルールセットは、アプリケーション又はアプリケーションが処理するデータのセキュリティを損ないうるアプリケーション中のエラーを顕在化させるのに使用されうる。テストリクエストが構築され、それらの各々はルールのうちの少なくとも１つに違反する。テストリクエストは、アプリケーションが予期される例外を投げかけるかどうかを確認するためにアプリケーションへと受け渡される。
【００１０】
本発明によれば、アプリケーション層リクエストをスクリーニングするためのルールの作成を容易にする方法が提供され、該方法は、アプリケーション層リクエストのサンプルスペース由来のアプリケーション層リクエストを、該リクエストの特徴によって、グルーピングすることを含む。
【００１１】
本発明の別の態様によれば、アプリケーション層リクエストをスクリーニングするためのルールセットを作成する方法が提供され、該方法は、該リクエストの各構成要素タイプに適用可能なデータテンプレートセットを得ること、１つ以上のグルーピング基準を用いてアプリケーション層リクエストをグルーピングすること、以下によって各リクエストのグルーピングのためのルールセットを得ること（該リクエストの構成要素の各タイプについて、該各リクエストグルーピングのリクエスト中に見出される名及び関連付けられたデータ要素を同定すること、各名について、データ要素（各データ要素は該各名のインスタンスと関連付けられている）を得ること、データ要素の該サンプルグループをデータ要素テンプレートと適合させること、及び該適合するデータテンプレートに基づき、該各名にルールを結びつけること）を含む。
【００１２】
本発明のさらなる態様によれば、ハイパーテキストプロトコル（ＨＴＴＰ）リクエストをスクリーニングするためのルールセットの作成を容易にする方法が提供され、該方法は、ＨＴＴＰリクエストのサンプルスペース由来のＨＴＴＰリクエストを、該リクエストの普遍資源識別子（ＵＲＩ）パス名拡張子によって、グルーピングすることを含む。
【００１３】
本発明の別の態様によれば、コンピュータアプリケーション中のエラーをテストする方法が提供され、該方法は、アプリケーションへの不正な入力をスクリーニングするためのルールセットを得ること、テスト入力を構築すること（各テスト入力は該ルールセットのうち少なくとも１つのルールに違反する）、該テストリクエストを該アプリケーションへと受け渡すこと、該テスト入力に対する該アプリケーションからの応答に基づき、該アプリケーション中のエラーの存在を決定することを含む。
【００１４】
関連するシステム及びコンピュータ読取可能媒体も提供される。
【００１５】
他の特徴及び利点は、図面とともに、以下の説明を検討した後、明らかになるだろう。
【００１６】
詳細な説明
【００１７】
インターネットを介して伝送されるパケットは、上位のリンク層、中位のネットワーク層、より下位のトランスポート層、下位のアプリケーション層を含む。より上位の層のそれぞれが、本質的には、パケットである。従って、リンク層は、ヘッダとネットワーク層パケットを含むデータとを有するパケットであり、ネットワーク層パケットは、ヘッダとトランスポート層パケットを含むデータとを有する。リンク層のヘッダは、ほぼ必ず、パケットが従うプロトコルがインターネットプロトコル（ＩＰ）（より旧式のプロトコルは、現在はほとんど廃れているかつ／又はインターネットでは使用されていない）であることを示している。パケットがＩＰパケットである場合、ネットワーク層は、ＩＰデータグラムとして知られている。トランスポート層のヘッダは伝送プロトコルを示す。ＩＰの伝送制御プロトコル（ＴＣＰ）は、それがウェブブラウジング、電子メール、およびウェブサービスに使用されているので、とりわけ最も一般的な伝送プロトコルである。（当業者に理解されるように、ウェブサービスは、あるアプリケーションが別のアプリケーションのリクエストをそれにより作成しうるマシン間の対話である）。
【００１８】
トランスポート層パケットのデータは、アプリケーション層を含む（これは通常、多数のトランスポート層パケットにわたって分散されている）。トランスポート層におけるポート番号、及び／又はコンテキストは、アプリケーション層プロトコルを示している。伝送プロトコルがＴＣＰである場合、アプリケーション層プロトコルは様々なアプリケーション層プロトコルのいずれであってもよいが、最も重要なのは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュアＨＴＴＰ（ＨＴＴＰＳ）、ファイル転送プロトコル（ＦＴＰ）、及び簡易メール転送プロトコル（ＳＭＴＰ）である。
【００１９】
公知のパケットフィルタリングファイアウォールは、使用されているプロトコルを検証するために、リンク層、ネットワーク層、及びトランスポート層のうちの１つ以上のパケットヘッダにルールを適用しうる。公知のプロキシファイアウォールは、アプリケーションプロトコルを検証しうる。公知のパケットフィルタリングファイアウォール及びプロキシファイアウォールにより適用される各ルールは、「汎用（ｓｉｍｐｌｅ  ｕｎｉｖｅｒｓａｌ）」と呼ばれうる形式である。説明として、ルールは、それが適用される要素のタイプを特定する。ルールにより特定されるタイプの全ての要素にそれが適用される場合、該ルールは汎用ルールである。一例として、ルール「全てのパケットは、送信先ポート番号８０宛でなくてはならない」において、このルールが適用される要素はパケットである。そして、このルールが全てのパケットに適用されるので、それは汎用ルールである。
【００２０】
現在、ＨＴＴＰ（又はＨＴＴＰＳ）は、ウェブブラウジング及びウェブサービスに使用されている。ＨＴＴＰリクエストは、以下の一般的な形式を有する。
＜メソッド＞  ＜ＵＲＩ＞  ＜ＨＴＴＰバージョン＞
＜埋め込みクッキーを持つＨＴＴＰヘッダ＞
＜リクエスト本体＞
ここで、「ＵＲＩ」は、普遍資源識別子を示す。ＵＲＩは、ウェブ上のエンティティへのリンクであり、一般には統一資源位置指定子（ＵＲＬ）である。ＵＲＩはまた、任意のＵＲＩパラメータ（これもＧＥＴフィールドとして知られている）を含む。ＨＴＴＰリクエスト中には、０以上のヘッダと０以上のクッキーが存在しうる。本体はオプションであり、もしある場合には、ＵＲＩエンコードフォーマット、フォームマルチパートエンコードフォーマット、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）フォーマットを有していてもよいし、本体が体系化されていない内容を有していてもよい。ＵＲＩエンコードフォーマット又はフォームマルチパートエンコードフォーマットを有する本体は、ハイパーテキストマークアップ言語（ＨＴＭＬ）又は拡張可能ＨＴＭＬ（ＸＨＴＭＬ）で記述される。ＳＯＡＰフォーマットを有する本体は、拡張可能マークアップ言語（ＸＭＬ）で記述される。
【００２１】
例として、図１Ａを参照して、ＨＴＴＰリクエスト１０は、以下の構成要素（ＧＥＴメソッド１２、ＵＲＩ１４、ＨＴＴＰバージョンインジケータ１６、及び埋め込みクッキー２０を持つヘッダ１８）を有する。この特殊なＨＴＴＰリクエストは本体を持たない。ＵＲＩは、ＵＲＬ２４とＵＲＩパラメータ２６から構成される。
【００２２】
図１Ａから明らかなように、ＵＲＩパラメータ２６は、フォーマット“名”＝“値”を持つ（実施例ＨＴＴＰリクエスト１０は２つのＵＲＩパラメータを持つ）。典型的であるように、ＵＲＩパラメータは、ユーザのカレントセッションを識別する。ヘッダ１８は、フォーマット“名”：“値”を持つ。各クッキーは埋め込まれた名と値とのペアを持ち、各ペアはコロンにより分けられている。従って、クッキー２０はフォーマット（“クッキー”：”名１＝“値１”；“名２”＝“値２”；“名３”＝“値３”・・・）を持つ。
【００２３】
図１Ｂは、ＰＯＳＴメソッド１２’、ＵＲＩパラメータを持たないＵＲＩ１４’、ＨＴＴＰバージョンインジケータ１６、埋め込みクッキー２０’を持つヘッダ１８’を有する第２の実施例ＨＴＴＰリクエスト１０’を示している。ＨＴＴＰリクエスト１０’は、本体２２’も有している。本体は、フィールド２５’（各々が、名２４’と値２６’とのペアを持つ）から構成される。リクエスト１０’のヘッダ１８ａ’は、本体２２’が、ＵＲＬエンコードフォーマットを有し、結果として、名−値ペアが形式“名”＝“値”（各ペアは＆によって分けられている）を有することを示している。
【００２４】
図１Ｃの実施例ＨＴＴＰリクエスト１０”は、以下の構成要素（メソッド１２”、ＵＲＩ１４”、ＨＴＴＰバージョンインジケータ１６”、ヘッダ１８”、及び本体２２”のフィールド２５”）を有している。ヘッダに埋め込まれたクッキーはないことが分かる。ヘッダ１８ａ”は、本体２２”がマルチパートフォームエンコードフォーマットを有することを示している。マルチパートフォームフォーマットの場合、本体のフィールドはパートとして知られている。ヘッダ１８ａ”は、各パートを線引きするパートバウンダリ２８”を指定する。パートバウンダリの後には、データフィールドの名２４”、それに続くフィールド値２６”を含む１つ以上のヘッダ３０”が続く。
【００２５】
図１Ｄの実施例ＨＴＴＰリクエスト１０’’’は、本体の構成要素２５’’’がＸＭＬ要素、それらの属性、及びＳＯＡＰメッセージフォーマットの仕様に従うデータオブジェクトを含むように、本体２２’’’がＳＯＡＰフォーマットを有することを示すヘッダ１８ａ’’’を持つ。
【００２６】
アプリケーションへの攻撃を始める際にパケットの実際のペイロードデータ（アプリケーション層）の構成要素を用いる不正なリクエストジェネレータ（これは人のハッカーであるかもしれないし機械であるかもしれない）の可能性が存在する。従って、攻撃は、ＨＴＴＰリクエストの構成要素を使用しうる。そのような攻撃を失敗させるためには、各ＨＴＴＰリクエストの構成要素に対するスクリーニングルールを作成することが考えられる。
【００２７】
ＨＴＴＰスクリーニングルールの作成のアプローチは、スクリーニングルールによって保護されるべきコンピュータアプリケーションの本質（すなわち、アプリケーション）を最初に考えることである。ルール開発者は、よくあるタイプのアプリケーションの一般的な知識しか持っていないかもしれない。あるいは、開発者は、スクリーニングされるアプリケーション（単数又は複数）の基本領域の知識を持っているかもしれない。あるいは、開発者は、アプリケーション（単数又は複数）の具体的な知識を持っているかもしれない。アプリケーションにおける（又はあるタイプのアプリケーションにおける）データ要素の本質の知識は、これらのアプリケーション（又はこれらのアプリケーションのサンプルのアプリケーション）についての機能仕様書から得られるかもしれない。この本質に基づき、ルールテンプレートが記述されうる。従って、ルール開発者がよくあるタイプのアプリケーションの一般的な知識から作業をしている場合、彼／彼女は、よく見られるデータ要素についてのルールテンプレートを記述しうる。ルール開発者が、スクリーニングされるべきアプリケーション（単数又は複数）の基本領域の知識を持って作業をしている場合、彼／彼女は、領域固有のデータ要素についてのルールテンプレートを記述しうる。そして、ルール開発者が、スクリーニングされるべき具体的アプリケーション（単数又は複数）の知識を持って作業をしている場合、彼／彼女は、アプリケーション固有のデータ要素についてのルールテンプレートを記述しうる。
【００２８】
例えば、オンラインショッピング又はあるポイントで必須の登録プロセスを含むウェブアプリケーションは、ユーザが記入し提出するためのフォームを出す。記入済みのフォームは、ＵＲＬエンコードフォーマット又はマルチパートフォームエンコードフォーマットで、アプリケーションへのリクエスト中に埋め込まれる。本体のフィールドは、名データ、住所データ、郵便番号（ｚｉｐ  ｃｏｄｅ又はｐｏｓｔａｌ  ｃｏｄｅ）データ、及び通常は電話番号を持つ。これらのフィールドのデータ要素は、よく見られるデータ要素と考えられうる。
【００２９】
電話番号を例にとると、ルール開発者は、そのような番号を含むフィールド用のルールテンプレートを記述しうる。人が読取可能な形式で記述されたそのようなルールテンプレートのサンプルを、図２に示す。（実際には、ルールテンプレートは、正規表現として知られるパターン言語を例えば使用することによって、より記号的に記述される。図２を見ると、ルールテンプレート５０は、一連のデータ要素テンプレート（北米フォーマットの電話番号についてのデータ要素テンプレート５４ａ、国際フォーマットの電話番号についてのデータ要素テンプレート５４ｂ、及び通話料無料の電話番号についてのデータ要素テンプレート５４ｃ）が続く、そのアプリケーションの説明文５２を持っている。
【００３０】
スクリーニングされるべきアプリケーション（単数又は複数）の領域が、製品カタログのものであることが知られている場合、製品カタログに固有のデータ要素（例えば、均一価格コード（Ｕｎｉｖｅｒｓａｌ  Ｐｒｉｃｉｎｇ  Ｃｏｄｅ）（ＵＰＣ））について記述されたルールテンプレートが存在するだろう。同様に、旅行予約型アプリケーションの場合には、旅行予約に固有のデータ要素（例えば、国際空港コード）について記述されたルールテンプレートが存在するだろう。スクリーニングされるべき具体的なアプリケーションの本質が知られている場合、そのアプリケーションに固有なルールテンプレート（例えば、ユーザＩＤの必須フォーマット）が存在するだろう。
【００３１】
記述されうる上述のルールテンプレートのいずれにも加えて、ルール開発者は、上述のより具体的なテンプレートのいずれにも適合（ｍａｔｃｈ）しないデータ要素用の抽象的ルールテンプレートを記述する。（従って、抽象的ルールテンプレートのアプリケーションの説明文は、それらがそれ以外には適合しないデータ要素用であることである）。このルールテンプレート用のデータ要素テンプレートは以下のものを含みうる。
・数字データテンプレート
・英字データテンプレート
・英数字データテンプレート
・印刷可能なＡＳＣＩＩ文字列テンプレート
・一般的なＡＳＣＩＩ文字列テンプレート
・ＵＴＦ−８文字列テンプレート
・ＵＣＳ−１６文字列テンプレート
【００３２】
これらのデータテンプレートは、より具体的なものから、最も具体的でないものへと順序付けられていた。その理由は、以下から明らかになるだろう。実際には、より一般的には、任意のルールテンプレートについて、ルールテンプレートのデータテンプレートのいくつかのフォーマットが他のものよりも具体的である場合、データテンプレートは、最も具体的なものから最も具体的でないものへと順序付けられる。
【００３３】
図３を参照して、領域用またはよく見られるデータ要素用のルールテンプレートは、予め記述されえ、いくつかの適切な様式で索引を付けられデータベース７０に記憶されうる。データベースは、ルールジェネレータ７２に接続されうる。ルールジェネレータ７２は、コンピュータ読取可能媒体７６（例えば、コンピュータディスケット、読み出し専用メモリ（ＲＯＭ）チップ、又はリモートソースからダウンロードされたファイル）に収録されたルール生成ソフトウェアを用いてプログラムされた汎用コンピュータでありうる。ルールジェネレータも、開発者インターフェース７８及びスクリーナ８２との通信のために接続される。ルールジェネレータは通信線８０を介してデータを受信しうる。データベース７０は、スクリーニングされるべき１つ以上のコンピュータアプリケーションを対象とするＨＴＴＰリクエストのサンプルスペースを記憶する。サンプルスペースのリクエストは、スクリーニングルールを必要とするアプリケーション（単数又は複数）宛のコンピュータパケットの部分であるか、そのようなコンピュータパケットから取り出されたかのいずれかである。サンプルスペースのリクエストは、通信線８０において受信されえ、データベースによってサンプルスペース中に蓄積されうる。リクエストのサンプルスペースは、１つ以上のアプリケーションの正当な用途を表すと仮定される。従って、サンプルスペースは、信頼できないソースからリクエストを受信する前に、通常は作成される。
【００３４】
図４（これは、ルールジェネレータ７２の動作を示す）を参照して、スクリーニングを必要とするアプリケーション（単数又は複数）のルールを作成するために、インターフェース７８を介して、ルール開発者が、ルールジェネレータ７２に、データベース中の適切なルールテンプレートを示しうる（Ｓ１１０）。さらに、開発者は、スクリーニングされるべきアプリケーション（単数又は複数）に固有のさらなるルールテンプレートを構築し、これらをインターフェース７８を介してルールジェネレータに受け渡しうる（Ｓ１１２）。
【００３５】
次いで、ルールジェネレータ７２は、ＨＴＴＰリクエストをグルーピングする（Ｓ１１４）。グルーピングは、階層様式で達成される。すなわち、最初に、第１の基準を満たすＨＴＴＰリクエストがグルーピングされる。次いで、第１の基準を満たさないＨＴＴＰリクエストの残りは、第２の基準に従いグルーピングされ、そのグルーピングの残りは、第３の基準によってグルーピングされる、等々。グルーピング基準は、リクエストのグループ中のデータ要素とルールテンプレート中のデータテンプレートとの適合を促進するようにして、ＨＴＴＰリクエストをグルーピングするそれらの能力の順で、適用される。ＨＴＴＰリクエストにおいて、各データ要素は、通常は、名（図１Ａ〜１Ｄとともに上述したような）と関連付けられる。そして、いずれか１つのアプリケーションにおいて、アプリケーションの異なるパートは異なるＵＲＩを用いて方向付けされるが、アプリケーション中のいずれの固有の名も、１セットフォーマットを有するデータ要素と関連付けられる。従って、グルーピングが、固有の名の複数のインスタンスが存在するようなものでありうる場合、同一フォーマットを有するデータ要素の同様の複数のインスタンスが存在し、そうして、データテンプレートとの適合が促進される。従って、階層グルーピングプロセスは、適合を生成するより高い見込みを有するものから、適合を生成するより低い見込みを有するものへと、順序付けられたグルーピングを生じる。
【００３６】
サンプルスペース内のリクエストは、まず、各コレクションが、所定の固有ＵＲＬについてのリクエストの全てを含むように、コレクションへと形成される。これらのコレクションは、次いで、ルール作成における正確性を促進するために、グルーピングされる。すべてのさらなるグルーピング作業は、これらのコレクションに作用する。
【００３７】
迅速な処理を促進するために、リクエストのグルーピングは、まず、各コレクションに対応する固有リクエストＵＲＩの審査を介してのみ観察されるリクエストのプロパティに基づき、すなわち、コレクション内のリクエストのヘッダ、クッキー、本体、メソッド又はＨＴＴＰバージョンの審査はなしで、行われる。
【００３８】
リクエストをグルーピングするための第１の基準は、タイプインジケータ（例えば、ＵＲＩパス名内のファイル名拡張子）でありうる。従って、例えば、以下の（最も高次の）グルーピングが形成されうる。
・公知の“イメージ”ファイルタイプ（これらは、“．ｇｉｆ”、“．ｊｐｇ”、“．ｊｐｅｇ”、“．ｐｎｇ”を含む拡張子を含むファイル名拡張子に代表される）を有するＵＲＩを持つＨＴＴＰリクエストのグルーピング
・公知の“ＨＴＭＬ／ＣＳＳ”ファイルタイプ（これらは、“．ｈｔｍ”、“．ｈｔｍｌ”、“．ｃｓｓ”を含むファイル名拡張子に代表される）を有するＵＲＩを持つＨＴＴＰリクエストのグルーピング
・公知の“クライアントサイドスクリプト”ファイルタイプ（これらは、“．ｊｓ”を含むファイル名拡張子に代表される）を有するＵＲＩを持つＨＴＴＰリクエストのグルーピング
・公知の“ダイナミックコンテンツ”ファイルタイプ（これらは、“．ｊｓｐ”、“．ａｓｐ”、“．ｐｌ”、“．ｐｈｐ”を含むファイル名拡張子に代表される）を有するＵＲＩを持つＨＴＴＰリクエストのグルーピング、及び
・サンプルスペース内のＨＴＴＰリクエストの閾値よりも多いＵＲＩについて生じる他の正式に認められていないファイル名拡張子に代表される任意のファイルタイプを有するＵＲＩを持つＨＴＴＰリクエストのグルーピング。
【００３９】
第１の基準の適用によってグルーピングされなかったリクエストの残りについては、第２の次元のグルーピング基準が適用される。この第２の基準は、固有ＵＲＩパス名のディレクトリ名プレフィックス部分である。従って、例えば、以下のグルーピングが形成されうる。
・プレフィックスＵＲＩパス名“／ｉｍａｇｅｓ／”を有するＵＲＩを持つＨＴＴＰリクエストのグルーピング
・プレフィックスＵＲＩパス名“／ｓｃｒｉｐｔｓ”を有するＵＲＩを持つＨＴＴＰリクエストのグルーピング、及び
・残りのＨＴＴＰリクエストの閾値よりも多くで遭遇する任意のパス名プレフィックスを有するＵＲＩを持つＨＴＴＰリクエストのグルーピング。
【００４０】
必要に応じ、第１又は第２の基準のいずれによってもグルーピングされなかったリクエストの残りは、リクエストのＵＲＩ内に見られるパターンに従ってグルーピングされうる。例えば、部分列“ｏｎｌｉｎｅ／ｂａｎｋｉｎｇ／ａｐｐｌｉｃａｔｉｏｎ”を有する全てのＵＲＩが一緒にグルーピングされうる。残存するＨＴＴＰリクエスト中のＵＲＩの長さに従って、いずれの残りもグルーピングされうる。例えば、１０００文字長を超える全てのＵＲＩが一緒にグルーピングされうる。
【００４１】
任意の残存する残りのために、次いで、各固有ＵＲＩについてのリクエストのコレクションが検査され、不変条件（すなわち、いずれか１つのコレクション中のリクエスト全てに亘り不変であるプロパティ）が求められる。次いで、コレクションのさらなるグルーピングが、これら不変条件に基づき行われうる。これら不変条件は、リクエスト本体のコンテンツタイプに最初求められ、次いで、リクエストのサイズに求められ、次いで、リクエストのメソッドに求められ、そしてリクエストの任意の他のプロパティに最後に求められる。例えば、以下のグルーピングがコンテンツタイプに基づき形成されうる。
・コレクションそれぞれのリクエストが不変のコンテンツタイプ“ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ”を有する、リクエストのコレクションのグルーピング
・コレクションそれぞれのリクエストが“ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ”及び“ｍｕｌｔｉｐａｒｔ／ｆｏｒｍ−ｄａｔａ”を含むＨＴＭＬフォーム提出を代表する不変の公知のコンテンツタイプを有する、リクエストのコレクションのグルーピング
・コレクション中に代表されるリクエスト数が、サンプルスペース内のリクエストの閾値を超える、コレクションそれぞれのリクエストが不変の未知のコンテンツタイプを有する、リクエストのコレクションのグルーピング。
【００４２】
いずれの残りについても、次いで、さらなるグルーピングが、リクエストヘッダに基づいて行われうる。例えば、以下のグルーピングがリクエストヘッダに基づき形成されうる。
・コレクションそれぞれのリクエストがＴｒａｎｓｆｅｒ  Ｅｎｃｏｄｉｎｇ（“ＴＥ”）ヘッダを有し、ＴＥヘッダの値がグルーピング中の全てのリクエストについて不変（すなわち、同じ）である、リクエストのコレクションのグルーピング
・コレクションそれぞれのリクエストが“Ｕｓｅｒ−Ａｇｅｎｔ”ヘッダを有し、Ｕｓｅｒ−Ａｇｅｎｔヘッダの値がグルーピング中の全てのリクエストについて不変である、リクエストのコレクションのグルーピング
・コレクションそれぞれのリクエストが“Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ”ヘッダを有し、Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅヘッダの値がグルーピング中の全てのリクエストについて不変である、リクエストのコレクションのグルーピング
・コレクションそれぞれのリクエストが、コレクション中で示されるリクエスト数がサンプルスペース内のリクエストの閾値を超える任意の所定のヘッダについて不変のヘッダ値を有する、リクエストのコレクションのグルーピング。
【００４３】
いずれの残りについても、以下のグループがリクエストサイズに基づき形成されうる。
・コレクションそれぞれのリクエストが、１０００ｂｙｔｅｓを超える不変の本体サイズを有する、リクエストのコレクションのグルーピング
・コレクションそれぞれのリクエストが５００ｂｙｔｅｓを超えるヘッダを有する、リクエストのコレクションのグルーピング。
【００４４】
いずれの残りについても、以下のグルーピングがリクエストメソッドに基づき形成されうる。
・コレクションそれぞれのリクエストがＰＵＴメソッドを有する、リクエストのコレクションのグルーピング
・コレクションそれぞれのリクエストがＨＥＡＤ又はＧＥＴメソッドを有する、リクエストのコレクションのグルーピング。
【００４５】
最後に、いずれの残存する残りも、各コレクション内のリクエストの任意の他の不変のプロパティに基づき、グルーピングされうる。これが、最も低次のグルーピング基準である。
【００４６】
次いで、ルーラジェネレータ７２は、ルール開発者が、２つ以上のグルーピングを形成するかまたは任意の２つ以上のグルーピングを１つのグルーピングに合体するために、任意のグルーピングをばらばらにすることを可能にするために、開発者インターフェース７８にグルーピングを提示しうる（Ｓ１１６）。
【００４７】
次いで、各グルーピング内のリクエストは、それらの構成要素に分解される（Ｓ１１８）。ＨＴＴＰリクエストの場合、これらの構成要素は、メソッド、ＵＲＩ、ＧＥＴフィールド（ＵＲＩパラメータ）、ＨＴＴＰバージョン、ヘッダ、クッキー、ｕｒｌエンコードＰＯＳＴフィールド、フォームマルチパートエンコードＰＯＳＴフィールド、及びＳＯＡＰ要素を含む。
【００４８】
次に、各グルーピング（Ｓ１２０、Ｓ１４４）について、構成要素の各タイプ（すなわち、ＧＥＴフィールド、ヘッダ、クッキーなど）について、ルールジェネレータ７２が、全ての構成要素名のセット（すなわち、グルーピング内の１つ以上のリクエストに見られる全ての構成要素名のセット）を形成する（Ｓ１２２）。セット中の各名について（Ｓ１２６、Ｓ１３６）、関連付けられたデータ要素のサンプルグループが形成される（ここで、各データ要素は名のインスタンスと関連付けられている）（Ｓ１２８）。
【００４９】
次いで、選択されたルールテンプレートのうちの適用可能なルールテンプレートのデータテンプレートが、適合するデータテンプレートを見つけるために、データ要素の各サンプルグループに適用される（Ｓ１３０）。例えば、図２電話番号用のルールテンプレートは、リクエスト本体中（すなわち、ＵＲＩエンコードＰＯＳＴフィールド、マルチアート（ｍｕｌｔｉ−ａｒｔ）エンコードＰＯＳＴフィールド、又はＳＯＡＰ要素中）の本体中の、あるいはＧＥＴフィールド（ＵＲＩパラメータ）中の、データ要素に、潜在的に適用可能であるだけである。従って、このルールテンプレートは、ＨＴＴＰ構成要素タイプが、本体又はＵＲＩパラメータ中の、ＵＲＬエンコードフィールド、マルチパートエンコードフィールド、又はＳＯＡＰ要素である場合のみに適用可能である。
【００５０】
ルールテンプレートがより大きな〜より小さな特異性のデータ要素テンプレートを有する状況では、より小さな特異性のデータ要素テンプレートに適合するデータ要素はまた、より大きな特異性のデータ要素テンプレートにも適合しうる。先述したように、そのようなルールテンプレートのデータ要素テンプレートは、ルールテンプレート中のより大きな特異性からより小さな特異性へと編成される。そのような編成の場合、ルールジェネレータ７２は、より大きな特異性のテンプレートから始めて、適合するデータ要素テンプレートを検索しえ、データ要素のサンプルグループのフォーマットに適合する最初のデータ要素テンプレートを見つけた時に検索を終えうる。
【００５１】
任意の１つのコンピュータアプリケーションにおいて、アプリケーション中の任意の固有の名が、同じフォーマットを有するデータ要素と関連付けられることが想起される。従って、リクエストのグループ中の名のセットにおける名は、通常、同一フォーマットを有するデータ要素と関連付けられる。また、同じ名が、異なるフォーマットのデータ要素と関連付けられたリクエストの１つのグループで使用されている可能性もある（通常、異なるコンピュータアプリケーションで使用されている同一名に起因する）。そのような状況において、データ要素のサンプルグループは、先述した抽象的ルールテンプレート中のデータ要素テンプレートの１つに適合するよう宣言されうるのみかもしれない。そのような適合は、（インターフェース７８を介して）ルール開発者に伝達され、適合を改良するためのリクエストグループの改変を可能としうる。
【００５２】
データ要素のサンプルグループがデータ要素テンプレートに適合する場合、適合するデータ要素テンプレートに従い関連付けられたデータ要素をその構成要素タイプ名の各インスタンスが有することを必要とするルールに、対応する構成要素タイプ名が結び付けられる（Ｓ１３２）。そのようなルールは、それがその構成要素タイプの全ての要素に適用される点で、汎用ルールであることが理解されるだろう。
【００５３】
例として、リクエスト本体中の名“ｔｅｌｎｏ”に関連付けられたデータ要素のサンプルグループが、（ｘｘｘ）ｘｘｘ−ｘｘｘｘの北米電話番号フォーマットに適合したかもしれない。そのような場合、全てのリクエスト（ここで、本体名は“ｔｅｌｎｏ”）について、関連付けられたデータ要素は、フォーマット（ｘｘｘ）ｘｘｘ−ｘｘｘｘを有さなくてはならないと述べるルールが作成されるだろう。
【００５４】
結び付けられた汎用ルールは、以下のようにして制限されうる。
・ルールは、それが作成されたデータ要素のサンプルグループ中の極値に基づき、最小データ値長（文字又はｂｙｔｅｓで）及び最大データ値長（文字又はｂｙｔｅｓで）を割り当てられうる。
・データ要素の値が数字型の場合、ルールは、それが作成されたデータ要素のサンプルグループ中の極値に基づき、最小数字データ値及び最大数字データ値が割り当てられうる（Ｓ１３４）。
【００５５】
次いで、ルールジェネレータ７２は、存在に関する不変条件について、ＨＴＴＰリクエストの各グルーピングを検査しうる。例えば、ルールジェネレータは、必ず存在する任意のタイプの名付けられた要素（すなわち、単純な存在に関する不変条件）、及び／又は特定数で常に存在する要素タイプ（すなわち、複合の存在に関する不変条件）を探しうる。各存在に関する不変条件について、そのエンティティ（又はエンティティのその数）の存在の必要性を条件とするルールが、グルーピングに結び付けられ、結び付けられた存在に関するルールを作成する（Ｓ１３８）。例えば、ルールジェネレータは、ＨＴＴＰリクエストのグルーピング中の全てのリクエストが、“ＳｅｓｓｉｏｎＩＤ”と呼ばれるクッキーを有することに注目しうる。そのような例では、ルールジェネレータは、そのグルーピングに当てはまるいずれのＨＴＴＰリクエスト（すなわち、ＵＲＩ、ヘッダ、又はグルーピングの基準を形成する他の特徴を有する任意のＨＴＴＰリクエスト）についても、“ＳｅｓｓｉｏｎＩＤ”と呼ばれるクッキーを必要とする単純な存在に関するルールを設定しうる。あるいは、ルールジェネレータは、グルーピング中のそれぞれのリクエストが、数値を有する３〜５のＰＯＳＴフィールドを有することに注目しうる。そのような例では、ルールジェネレータは、そのグルーピングに当てはまるいずれのＨＴＴＰリクエストについても、数値を有する３〜５のＰＯＳＴフィールドを必要とする複雑な存在に関するルールを設定しうる。
【００５６】
次に、ＨＴＴＰリクエストの各グルーピングが、統計的特性について検査されうる。各統計的不変条件について、その統計的特性の必要性を条件とするルールが、ＵＲＩグルーピングに結び付けられ、結び付けられた統計的ルールを作成する（Ｓ１４０）。例えば、統計的ルールは、「ＰＯＳＴフィールドの５％以下が、ブランク（空の）値を有しうる」であるかもしれない。
【００５７】
最後に、各グループ用の得られた結び付けられたルール（全てのタイプの、すなわち、汎用の結び付けられたルール、存在に関する結び付けられたルール、統計的な結び付けられたルール）が、完全なルールセットへと構成される。グルーピングについてのルールセットが、グループの基準を形成した特徴と同一の特徴を有する任意の次のＨＴＴＰリクエストに適用可能なルールを有する。例えば、ルールセットは、ファイル名拡張子“．ｇｉｆ”を有するＵＲＩを持つＨＴＴＰリクエストから形成されたグループから生じうる。そのような場合には、このルールセットは、ファイル名拡張子“．ｇｉｆ”を有するＵＲＩを持つ任意の次のＨＴＴＰリクエストに適用可能である。従って、この特徴は、ルールセットの“トリガー”である。それゆえに、各グルーピングの基準を形成した共通の特徴が、ルールセットのトリガー条件へと形成され、グルーピングに結び付けられた（各タイプの）各ルールが、ルールセットに付け加えられる条件になる（Ｓ１４２）。
【００５８】
グルーピングが形成される方法の上述の説明から、ＨＴＴＰリクエストが、１より多いルールセットのトリガー条件を満たしうることは明らかである。しかしながら、上述したように、グルーピングは、適合を生成するより高い見込みを有するグルーピングから、適合を生成するより低い見込みを有するグルーピングへと一般的に進むように、階層的に順序付けられる。能率性を処理するために、任意の１つのリクエストが、１つのルールセットだけによってスクリーニングされることが一般的に好適である。従って、ルールセットは、グルーピングが順序付けられたのと同じ順序で順序付けられる。結果的に、リクエストを受信したとき、スクリーナ８２は、高次のルールセット（これは、適合を生成するより高い見込みを有する）で始め、リクエストが満たすトリガー条件を検索しうる。リクエストが満たすトリガー条件を有することが見出されたルールセットの順序付けられたリスト中の第１のルールセットが、リクエストに適用されるルールセットである。
【００５９】
図５は、人が読取可能な形式で表現された実施例ルールセットの一部を示す。（実際には、リクエスト用のルールは、通常、表に記憶され、人が読取可能な形式で都合よく表現されうるよりも細かい識別を可能とする様式で、記号的に表現されうる。）  図５を見ると、トリガー９０は、それと関連付けられた多数の条件９２を有する。各条件は、トリガー９０を含むＵＲＩ特徴に基づき設定されたＨＴＴＰリクエスト群に結び付けられたルールのうちの１つである。
【００６０】
次いで、順序付けられたルールセットは、アプリケーション（単数又は複数）への次のリクエストをスクリーニングするために、スクリーナ８２へと受け渡されうる（Ｓ１４６）。必要に応じ、これらの次のＨＴＴＰリクエストは、データベース７０中のリクエストのサンプルスペースを増やすために、記憶されうる。そのような場合、ルールジェネレータ７２は、改良されたルールセットを作成しようとして、リクエストのこのより大きなサンプルスペースを後で処理しうる。
【００６１】
アプリケーションへの不正なリクエスト（入力）を排除する目的で開発されたコンピュータアプリケーションについての任意のルールセットが、アプリケーション中のエラーを顕在化するために使用されうる。より詳細には、アプリケーション中のエラーは、アプリケーションに特別な“テスト”リクエストを受け渡すことによって、顕在化されうる。各テストリクエストは、アプリケーション用のルールセット中の１つ以上のルールに故意に違反する。次いで、結果が、アプリケーション（単数又は複数）がテストリクエストに直面して予期される例外を投げかけることであることを確実にするように、テストリクエストに対するアプリケーション（単数又は複数）の反応が観察される。アプリケーションが予期される例外を投げかけない場合、これは、アプリケーション用のソフトウェアコード中のエラーを示す。
【００６２】
ルールセットは、アプリケーションの説明書を考慮することから開発されうる。例えば、ルールセットは、アプリケーションの機能仕様書を参照して、ルール開発者によって開発されるルールテンプレートから生じうるか、又は、ルールセットは、アプリケーションのより前のバージョンの機能仕様書を参照して開発されうる。当業者により理解されるように、コンピュータアプリケーションの機能仕様書は、アプリケーションの技術仕様書の開発の基礎を提供する。次いで、アプリケーションのソフトウェアコードが、技術仕様書に基づき記述される。ソフトウェア開発者は、機能仕様書から技術仕様書への動きにおいて、又は、技術仕様書からソフトウェアコードへの動きにおいて、エラーを作成しうる。アプリケーションの機能仕様書に基づくルールは、機能仕様書において予想されたようにアプリケーションが記述されていると見なす。結果として、コーディングにエラーが存在した場合、このエラーは、テストリクエストを処理する際に予期されるようには動かないアプリケーションによって、顕在化されうる。
【００６３】
上述したように、ルールセットはまた、アプリケーションへのリクエストのサンプルスペースから開発されうる。そのようなルールセットは、アプリケーションへの有効なリクエストを特徴付けると考えられ、そして、そのようにして、エラーを顕在化するのに使用されうる。
【００６４】
各テストリクエストが、リクエスト内のオブジェクトに割り当てられた少なくとも１つのプロパティの違反を含む。そのようなプロパティは、オブジェクトの値の数値範囲に関する規定、オブジェクトの名又は値の長さ（文字若しくはｂｙｔｅｓで）に関する規定、或いは、オブジェクトの名若しくは値のフォーマット又はパターンに関する規定の形式をとりうる。従って、テストリクエストは、ルールによって規定される範囲外の数値を有するオブジェクトを含むリクエストを構築することによって、ルールによって規定される範囲外の長さ（文字又はｂｙｔｅｓで）を有する名又は値を有するオブジェクトを含むリクエストを構築することによって、或いは、ルールによって規定されるパターンに適合しない名又は値を有するオブジェクトを含むリクエストを構築することによって、構築されうる。
【００６５】
テストリクエストは、普遍形式のルールに基づきうる。そのようなテストリクエストは、アプリケーションへの許可されたアクセスを記述する普遍ルールから作成される。普遍ルールのトリガー条件を満たすが、普遍ルールによって特定タイプのオブジェクトに普遍的に存在するとして規定されるプロパティが、そのタイプの１つ以上のオブジェクトに存在しないように、リクエストは構築される。
【００６６】
テストリクエストはまた、単純な存在に関する形式のルールに基づきうる。そのようなテストリクエストは、アプリケーションへのリクエストを構築することによって、アプリケーションへの許可されたアクセスを記述する単純な存在に関するルールから作成されうる。該アプリケーションへのリクエストは、単純な存在に関するルールのトリガー条件を満たすが、そこには、単純な存在に関するルールにより必ず存在すると規定される特定のタイプの要素は存在しない。
【００６７】
テストリクエストはまた、複合の存在に関する形式のルールに基づきうる。そのようなテストリクエストが、複合の存在に関するルールのトリガー条件を満たすが、そこには、複合の存在に関するルールによって特定数又は特定量必ず存在するとして規定される特定タイプの要素（単数又は複数）が異なる数又は量で存在する、アプリケーションへのリクエストを構築することによって、アプリケーションへの許可されたアクセスを記述する複合の存在に関するルールから作成されうる。
【００６８】
テストリクエストは、複合の普遍形式のルールに基づきうる。そのようなテストリクエストは、アプリケーションへの許可されたアクセスを記述する複合の普遍ルールから作成されうる。アプリケーションへのテストリクエストは、複合の普遍ルールのトリガー条件を満たすように構築されるが、特定タイプのオブジェクト中の準普遍プロパティについてのルールの要件を満たさない。（準普遍プロパティは、例えば、特定タイプのオブジェクトのＮ以外の全てに存在するか、そのようなオブジェクトのｍ％に存在するように、規定されるものでありうる。）
【００６９】
テストリクエストは、統計的形式のルールに基づきうる。そのようなテストリクエストは、統計的ルールのトリガー条件を満たすが、そこでは、リクエスト内の特定タイプのオブジェクトへの統計的ルールによって規定される統計的プロパティが、テストリクエスト内のそのタイプのオブジェクトに関して得ることができない、アプリケーションへのリクエストを構築することによってアプリケーションへの許可されたアクセスを記述する統計的ルールから作成されうる。
【００７０】
テストリクエストは、開発者インターフェース７８を介するか、又はルールジェネレータ７２（アプリケーションテスタとして動作する）によって、ルール開発者により構築され、アプリケーションに直接受け渡されうる。アプリケーションの応答は、ルール開発者又はルールジェネレータによって、受信され分析されうる。
【００７１】
エラーが顕在化したらすぐに、それは修正されうる。
【００７２】
ＨＴＴＰプロトコルに従うリクエストに関連して本発明を記述してきたが、本発明の教示が、任意の他の適切なプロトコルに従うリクエストへの適用を有することは明らかである。
【００７３】
他の改変は当業者に明らかであり、従って、本発明は特許請求の範囲に規定される。
【図面の簡単な説明】
【００７４】
【図１Ａ】本発明の実施例態様を記載する図において、図１Ａ、１Ｂ、１Ｃ、及び１Ｄは、実施例ＨＴＴＰリクエストの内容を示している。
【図１Ｂ】本発明の実施例態様を記載する図において、図１Ａ、１Ｂ、１Ｃ、及び１Ｄは、実施例ＨＴＴＰリクエストの内容を示している。
【図１Ｃ】本発明の実施例態様を記載する図において、図１Ａ、１Ｂ、１Ｃ、及び１Ｄは、実施例ＨＴＴＰリクエストの内容を示している。
【図１Ｄ】本発明の実施例態様を記載する図において、図１Ａ、１Ｂ、１Ｃ、及び１Ｄは、実施例ＨＴＴＰリクエストの内容を示している。
【図２】図２は、人が読取可能な形式での本発明に従うルールテンプレートの一部の例である。
【図３】図３は、本発明の態様を用いるシステムの概略図である。
【図４】図４は、図３の一部システムの動作を示す流れ図である。そして、
【図５】図５は、人が読取可能な形式での本発明に従うルールセットの一部の例である。
【図１Ａ】
2006501551.tif 000003
【図１Ｂ】
2006501551.tif 000004
【図１Ｃ】
2006501551.tif 000005
【図１Ｄ】
2006501551.tif 000006
【図２】
2006501551.tif 000007
【図３】
2006501551.tif 000008
【図４】
2006501551.tif 000009
【図５】
2006501551.tif 000010
【国際調査報告】
2006501551.tif 000011
2006501551.tif 000012
2006501551.tif 000013
2006501551.tif 000014
2006501551.tif 000015