(57)【要約】【課題】ＵＲＬリストによるＷｅｂフィルタリングを実装しているＰＣが、Ａｊａｘ等を利用したページにアクセスすると、膨大なＵＲＬアクセス許可リクエストが発生し、ページの表示が非常に遅れる問題が発生する。【解決手段】既にアクセスが許可されているひとつのＷｅｂページから大量のＵＲＬアクセス許可リクエストが出ているとき、次の類似性判定を行ないアクセスリクエストの件数を削減することにより、ページ表示処理の迅速化を実現する。ＵＲＬリクエスト送信状況を監視し、大量にリクエストが送信されていることが検出された場合に、同じアクセス元ページから過去にリクエストされたＵＲＬに対する現在ページとの類似性を判定する。類似ＵＲＬと判定されたＵＲＬに対して、アクセス許可の判定ロジックをバイパスする。【選択図】図２
2008204425.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ端末から送信されるＷｅｂページヘのＵＲＬアクセス要求に応じて該ＵＲＬの類似性の判定を処理するコンピュータ・プログラムであって、
コンピュータに、
複数のＵＲＬアクセス要求が送信されているかを判断するステップと、
前記複数のＵＲＬアクセス要求が送信されていると判断された場合に、該複数のＵＲＬ間の類似性を判定するステップと、
前記判定するステップによって類似すると判定された場合、該類似するＵＲＬを以後のプログラムの処理対象から省略するステップと、
を実行させるコンピュータ・プログラム。
【請求項２】
前記判断するステップにおいて、送信待機状態のソケット数が所定数以上存在する場合に、前記複数のＵＲＬアクセス要求が送信されていると判断する、請求項１に記載のコンピュータ・プログラム。
【請求項３】
前記判断するステップにおいて、ＨＴＴＰリクエスト数とＨＴＴＰレスポンス数のそれぞれが、一定時間に所定数以上検出された場合に、前記複数のＵＲＬアクセス要求が送信されていると判断する、請求項１又は２に記載のコンピュータ・プログラム。
【請求項４】
前記類似性を判定するステップは、
該複数のＵＲＬ間のＨＴＴＰリクエスト・ヘッダデータからクエリ文字列をそれぞれ抽出し、各クエリ文字列のパターンが一致する場合に、該複数のＵＲＬが類似すると判定する、ことを特徴とする請求項１乃至請求項３に記載のコンピュータ・プログラム。
【請求項５】
前記類似性を判定するステップは、
前記クエリ文字列に含まれたパラメータの識別子、該識別子の順番、及び該識別子のデータのタイプが一部又は全部が一致した場合に、該複数のＵＲＬが類似すると判定するステップを含む、請求項４に記載のコンピュータ・プログラム。
【請求項６】
前記類似性を判定するステップは、前記ＨＴＴＰリクエスト・ヘッダ内のページリンク元参照情報を参照して、要求元のページが表示許可されているページであることを照合確認するステップを更に含む、請求項１乃至請求項５いずれかに記載のコンピュータ・プログラム。
【請求項７】
前記ＵＲＬアクセス要求に対するＵＲＬにアクセスするステップを更に有し、
前記省略するステップは、
前記類似すると判定したＵＲＬに対する前記アクセスを省略させることを特徴とする請求項１乃至請求項６に記載のコンピュータ・プログラム。
【請求項８】
ＵＲＬアクセス要求に応じてアクセスしたインターネットへのアクセス履歴を保存するステップを更に有し、
前記省略するステップは、
前記類似すると判定したＵＲＬに対するアクセス履歴の保存を省略することを特徴とする請求項１乃至請求項７に記載のコンピュータ・プログラム。
【請求項９】
ユーザ端末から送信されるＷｅｂページヘのＵＲＬアクセス要求に応じて該ＵＲＬの類似性の判定を処理する類似性判定装置であって、
複数のＵＲＬアクセス要求が送信されているかを判断する手段と、
前記複数のＵＲＬアクセス要求が送信されていると判断された場合に、該複数のＵＲＬ間の類似性を判定する手段と、
前記判定する手段によって類似すると判定された場合、該類似するＵＲＬを以後のプログラムの処理対象から省略する手段と、
を備える類似性判定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＲＬの類似性分析による処理省略判定プログラム、及び装置に関する。
【背景技術】
【０００２】
インターネット上のＷｅｂページにおいて、１つのページが、他の多くのＵＲＬに自動的にアクセスをして読み込むことにより、ページ全体を構成するものがある。特に、最近では、Ａｊａｘ（Ａｓｙｃｈｒｏｎｏｕｓ  ＪａｖａＳｃｒｉｐｔ（登録商標）＋  ＸＭＬ）（例えば、非特許文献１参照）と呼ばれる技術を積極的に利用したＷｅｂアプリケーションが流行しつつあり、送信側と受信側の同期を求めず、一度に大量のＵＲＬアクセス要求を送信するＷｅｂページが増加する傾向にある。
【非特許文献１】“Ａ  Ｎｅｗ  Ａｐｐｒｏａｃｈ  ｔｏ  Ｗｅｂ  Ａｐｐｌｉｃａｔｉｏｎｓ”，［ｏｎｌｉｎｅ］，Ｊｅｓｓｅ  Ｊａｍｅｓ  Ｇａｒｒｅｔｔ，Ｆｅｂｒｕａｒｙ  １８，２００５，［２００７年１月２５日検索］、インターネット＜ＵＲＬ  ｈｔｔｐ：／／ｗｗｗ．ａｄａｐｔｉｖｅｐａｔｈ．ｃｏｍ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｅｓｓａｙｓ／ａｒｃｈｉｖｅｓ／０００３８５．ｐｈｐ＞
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上記のような場合に、ＵＲＬリストによるインターネット・フィルタリングを行ったとき、個々のＵＲＬに対してアクセス許可リクエストをフィルタリング判定サーバに送信してその判定結果を受信していると、ブラウザ上では、ページ全体から一部のデータが抜けた表示状態が長く続いたり、フィルタリング判定サーバ側及びクライアントＰＣ側では、処理負荷が増大してパフォーマンスが低下する等の要因となる。
【０００４】
また、情報セキュリティ及びその他の目的のため、インターネットのアクセス履歴を保存する場合において、多くの不必要なＵＲＬがログに出力されることにより、ログファイル保存スペースが増大したり、ログの解析効率が低下する等の要因になる。
【課題を解決するための手段】
【０００５】
本発明では、上記課題に鑑み以下のような解決手段を提供する。
【０００６】
（１）  ユーザ端末から送信されるＷｅｂページヘのＵＲＬアクセス要求に応じて該ＵＲＬの類似性の判定を処理するコンピュータ・プログラムであって、
コンピュータに、
複数のＵＲＬアクセス要求が送信されているかを判断するステップと、前記複数のＵＲＬアクセス要求が送信されていると判断された場合に、該複数のＵＲＬ間の類似性を判定するステップと、
前記判定するステップによって類似すると判定された場合、該類似するＵＲＬを以後のプログラムの処理対象から省略するステップと、
を実行させるコンピュータ・プログラム。
【０００７】
（２）  前記判断するステップにおいて、送信待機状態のソケット数が所定数以上存在する場合に、前記複数のＵＲＬアクセス要求が送信されていると判断する、（１）に記載のコンピュータ・プログラム。
【０００８】
（３）  前記判断するステップにおいて、ＨＴＴＰリクエスト数とＨＴＴＰレスポンス数のそれぞれが、一定時間に所定数以上検出された場合に、前記複数のＵＲＬアクセス要求が送信されていると判断する、（１）又は（２）に記載のコンピュータ・プログラム。
【０００９】
（４）  前記類似性を判定するステップは、
該複数のＵＲＬ間のＨＴＴＰリクエスト・ヘッダデータからクエリ文字列をそれぞれ抽出し、各クエリ文字列のパターンが一致する場合に、該複数のＵＲＬが類似すると判定する、ことを特徴とする（１）乃至（３）に記載のコンピュータ・プログラム。
【００１０】
（５）  前記類似性を判定するステップは、
前記クエリ文字列に含まれたパラメータの識別子、該識別子の順番、及び該識別子のデータのタイプが一部又は全部が一致した場合に、該複数のＵＲＬが類似すると判定するステップを含む、（４）に記載のコンピュータ・プログラム。
【００１１】
（６）  前記類似性を判定するステップは、前記ＨＴＴＰリクエスト・ヘッダ内のページリンク元参照情報を参照して、要求元のページが表示許可されているページであることを照合確認するステップを更に含む、（１）乃至（５）いずれかに記載のコンピュータ・プログラム。
【００１２】
（７）  前記ＵＲＬアクセス要求に対するＵＲＬにアクセスするステップを更に有し、
前記省略するステップは、
前記類似すると判定したＵＲＬに対する前記アクセスを省略させることを特徴とする（１）乃至（６）に記載のコンピュータ・プログラム。
【００１３】
（８）  ＵＲＬアクセス要求に応じてアクセスしたインターネットへのアクセス履歴を保存するステップを更に有し、
前記省略するステップは、
前記類似すると判定したＵＲＬに対するアクセス履歴の保存を省略することを特徴とする（１）乃至（７）に記載のコンピュータ・プログラム。
【００１４】
（９）  ユーザ端末から送信されるＷｅｂページヘのＵＲＬアクセス要求に応じて該ＵＲＬの類似性の判定を処理する類似性判定装置であって、
複数のＵＲＬアクセス要求が送信されているかを判断する手段と、
前記複数のＵＲＬアクセス要求が送信されていると判断された場合に、該複数のＵＲＬ間の類似性を判定する手段と、
前記判定する手段によって類似すると判定された場合、該類似するＵＲＬを以後のプログラムの処理対象から省略する手段と、
を備える類似性判定装置。
【００１５】
すなわち、上記の解決手段によれば、既にアクセスが許可されている１つのＷｅｂページから複数のＵＲＬアクセス許可のリクエストが出ているとき、次のａ）及びｂ）の判定を行うことによりサーバへのアクセス・リクエストの件数を削減することにより、ページ表示処理の迅速化を実現することができる。
ａ）ＵＲＬリクエストの送信状況を監視し、大量にリクエストが送信されていることが検出された場合に、リクエストされたアクセス先のＵＲＬに対する過去にリクエストされたＵＲＬとの類似性を判定する。
ｂ）類似ＵＲＬと判定されたＵＲＬに対して、アクセス許可の判定ロジックをバイパスする。
【００１６】
ここで、ＵＲＬリクエスト送信状況の監視においては、ソケットの監視モジュールによって次のｃ）及びｄ）のいずれかの条件を監視し、短時間に「複数のＵＲＬアクセス要求が送信されている」ことを判断する。
ｃ）送信待機状態のソケット数が所定数以上であること
ｄ）リクエストとレスポンスのカウント数が所定数以上であること
【００１７】
複数のアクセス要求が送信されていると判断された場合、接続先ＵＲＬの文字列を、同じアクセス元ページから過去にリクエストされたＵＲＬに対する現在ページの類似性判定処理を行うモジュールに送り、類似性の判定を行う。更に、複数のアクセス要求があるときのＵＲＬのクエリストリング（クエリ文字列）内の文字列をパターン化し、パターンの一致による類似判定を行う。そして、ＨＴＴＰリクエストのヘッダ内のデータ項目であるページリンク参照情報（例えば、識別子「Ｒｅｆｅｒｅｒ」で記述される参照情報）をチェックして要求元のページが表示許可されているページであることを照合確認する。最後に、類似ＵＲＬと判定された場合、このプログラムを組み込んだアプリケーション・ソフトウェアの処理対象から省略する。
【発明の効果】
【００１８】
本発明によれば、以下の作用効果を奏する。
【００１９】
（１）Ａｊａｘ等の技術が使用されているＷｅｂページの場合、ＵＲＬリクエストが多発する傾向がある。このようなページにおいてＵＲＬフィルタリングを行う場合、１件１件のＵＲＬに対してサーバに問い合わせを行うため、ページのロードに遅延が発生し、パフォーマンスが低下してしまう。そこで、ＵＲＬの類似性を分析するロジックを適用し、過去に問合わせたＵＲＬと類似関係にあるかどうかを類似性判定モジュールで分析する。分析結果により類似性があると判定したＵＲＬについては、類似関係にあったＵＲＬの有害判定を適用することで問い合わせ回数、及びページのロードに要する時間を大幅に削減させることが可能になる。また、問い合わせ回数が減少することで、処理能力も向上させることができる。
【００２０】
（２）Ｗｅｂページのアクセスログを集計する装置において、不必要なＵＲＬが多量に保存されてしまう場合がある。このような状況にＵＲＬの類似性判定モジュールを適用することで、ログファイルの保存容量の大幅な削減を可能にし、ログ解析効率を向上させることができる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明を実施するための最良の形態について図を参照しながら説明する。なお、以下の実施形態では、上述の類似性判定装置をサーバ上で実現した「有害判定サーバ」として説明する。
【００２２】
［システムの全体構成図］
図１は、本発明の好適な実施形態の一例に係るシステム１の全体構成を示す図である。
【００２３】
本発明を構成するシステム１は、ＵＲＬの類似性分析によるＵＲＬを処理対象から省略するかどうかを判定するシステムである。本システムでは、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）サーバ１０並びに有害判定サーバ４０が、通信回線３０を介して、ユーザ端末２０と接続される。サーバ１０並びに有害判定サーバ４０は、図１では別のサーバであるかのように記載しているが、同一のサーバで構成してもよい。また、サーバのハードウェアの数に制限はなく、必要に応じて、１又は複数で構成してよい。
【００２４】
ＷＷＷサーバ１０は、文書や画像等の情報（Ｗｅｂページともいう）を蓄積しておき、ユーザ端末２０のＷｅｂブラウザ等のソフトウェアの要求に応じて、通信回線３０、例えば、インターネット等のネットワークを通じて、これらの情報を送信する機能を備える。なお、個人や会社のホームページ等のＷｅｂページ群、又はＷｅｂページ群が置いてあるインターネット上の場所を、Ｗｅｂサイトという。ＷｅｂサイトはＷＷＷサーバ１０に１又は複数あってもよい。
【００２５】
有害判定サーバ４０は、インターネットの情報を監視する管理者が、それぞれのＷＷＷサーバ１０が持つ情報を取得して、有害であると判定したＷｅｂサイトのＵＲＬをリスト（以下、ブラックリスト４１という）に記憶する。ユーザ端末２０からＷｅｂページのＵＲＬについて有害であるかどうかの判定依頼を受信したときに、ブラックリスト４１を参照し、判定結果（例えば、リストにある場合は判定依頼を受けたＵＲＬのサイトが有害Ｗｅｂサイトであるという判定結果）をユーザ端末２０に送信する機能を備える。有害であると判断する基準は、例えば、子供に見せたくない、アダルト、暴力、出会い系、反社会行為等に関するＷｅｂページであるか否かである。なお、有害ではないと判定したＷｅｂサイトのＵＲＬを別のリスト（以下、ホワイトリスト４２という）に記憶し、ブラックリスト４１と共に参照してもよい。ホワイトリスト４２にあるＷｅｂサイトに対しては、アクセスの許可をユーザ端末２０に送信する。
【００２６】
通信回線３０は、一般的にはインターネットであり、有線により実現するものだけではなく、アクセスポイントを介して無線ＬＡＮにより実現するもの等、本発明の技術的思想に合致するものであれば様々な通信技術により実現される。
【００２７】
ユーザ端末２０は、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）の他、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄａｔａ  Ａｓｓｉｓｔａｎｔ）等のいわゆるコンピュータ以外の通信端末であってもよい。
【００２８】
［端末及びサーバの機能ブロック］
図２は、本発明の好適な実施形態の一例に係るユーザ端末２０、並びに有害判定サーバ４０の機能ブロック図である。
【００２９】
ユーザ端末２０は、通信Ｉ／Ｆ（通信インターフェイス）を持ち、ＷＷＷサーバ１０からＷｅｂページ等を受信する、及びＷｅｂブラウザによるリクエスト等を送信する、送受信部２２を備える。また、ユーザ端末２０は、ＣＲＴや液晶ディスプレイ等の表示装置を持ち、Ｗｅｂページ等を表示する表示部２４を備える。更に、ユーザ端末２０は、キーボード及びマウス等の入力手段を持ち、ＷｅｂブラウザにおけるＵＲＬの入力、及びＷｅｂページに表示されたリンクをクリックする等の入力部２１を備える。
【００３０】
更に、ユーザ端末２０は、制御部２３を持ち、ＵＲＬアクセス要求が送信されていることを検出するソケット監視モジュール２０１、ＷｅｂサイトやＷｅｂページの不適切な情報を閲覧できなくしたり、有益な情報だけを閲覧できるようにしたりするフィルタリングモジュール２０２、ＵＲＬの類似性を分析して判断するＵＲＬ類似性判定モジュール２０３、並びに有害判定結果を保存するキャッシュモジュール２０４を備える。なお、有害判定結果は、有害であるＷｅｂサイト並びにアクセスが許可されたＷｅｂサイトのＵＲＬがリストになっているものである。典型的には、これら制御部２３のモジュールはＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）によって実行されるコンピュータ・プログラムで実現される。
【００３１】
有害判定サーバ４０は、制御部４５を持ち、ＵＲＬについての判定依頼を受けて、当該ＵＲＬを持つＷｅｂサイトが有害であるかと、アクセスを許可であるかと、を判定する判定部４０１を備える。判定部４０１は、ブラックリスト４１及びホワイトリスト４２を備える。なお、ブラックリスト４１にあるＷｅｂサイト以外はアクセス許可するとして、ブラックリスト４１だけを備えてもよい。その他、有害判定サーバ４０には、送受信部を備え、更に、入力部、表示部を備えてもよいがここでは図示を省略している。
【００３２】
［ＵＲＬフィルタリング処理のフロー］
図３は、本発明の好適な実施形態の一例に係るＵＲＬフィルタリング処理のフローチャートである。
【００３３】
まず、ステップＳ１０１では、ユーザ端末２０の制御部２３が、入力部２１により、Ｗｅｂブラウザ上において、ユーザからのＵＲＬの入力、及びＷｅｂページに表示されたリンク（接続先ＵＲＬ）をクリックする等の入力を受け付ける。移動先の新しいＷｅｂページがＡｊａｘ等の技術を用いている場合、複数のＵＲＬに自動的にアクセスをするＵＲＬアクセス要求を含むＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）リクエストを、ソケット監視モジュール２０１が受信する。ここでＨＴＴＰリクエストとは、端末（クライアント）からサーバに送信するデータである。
【００３４】
なお、複数のＵＲＬに自動的にアクセスをするＵＲＬアクセス要求とは、ＷＷＷサーバ１０から送信された複数のＵＲＬにアクセスしてＷｅｂページの送信を要求することであり、例えば、ユーザ端末２０が、地図を提供するＷｅｂサイトから、地図を受信して表示した場合に、Ａｊａｘ等の技術を用いて複数のＵＲＬを送信し、表示された地図に隣接する複数の地図を、予めＷｅｂサイトからダウンロードすることである。こうすることで、ユーザが、地図を表示されている以外の場所に動かしたときに、予めダウンロードしていない場合は、ダウンロードの時間分だけ表示が遅れるが、予めダウンロードしておくことで、隣接する地図を表示してスムーズに地図を遷移させることができる。
【００３５】
次に、ステップＳ１０２では、ソケット監視モジュール２０１が、所定の時間内に大量のＵＲＬアクセス要求が送信されているかどうかを監視する。監視方法には、送信待機状態のソケット数を監視する方法、リクエストとレスポンスのカウントを監視する方法がある。それぞれの方法について具体的には、図７において後述する。なお、ソケットは、ＩＰアドレスと、複数のコンピュータと同時に通信するためのサブアドレスとしての複数のポート番号を組み合わせたネットワーク・アドレスのことである。
【００３６】
次に、ステップＳ１０３では、ソケット監視モジュール２０１が、大量のＵＲＬアクセス要求が送信されていることを検出した場合（Ｓ１０３：ＹＥＳの場合）は、ＵＲＬ類似性判定モジュール２０３による処理を行う。また、大量のＵＲＬアクセス要求の送信を検出しない場合（Ｓ１０３：ＮＯの場合）は、ＨＴＴＰリクエスト先のＵＲＬ（以降リクエスト先ＵＲＬという）の有害性の判定依頼を、有害判定サーバ４０に送信する。
【００３７】
次に、ステップＳ１０４では、ＵＲＬ類似性判定モジュール２０３が、リクエスト先ＵＲＬ間の類似性を分析する。類似性の分析は、ＵＲＬのクエリストリング内の文字列をパターン化し、パターンの一致による分析を行う。具体的には、図８において後述する。
【００３８】
次に、ステップＳ１０５では、キャッシュモジュール２０４に、リクエスト先ＵＲＬと類似関係にあるＵＲＬのアクセスログがない場合（Ｓ１０５：ＮＯの場合）は、フィルタリングモジュール２０２が、リクエスト先ＵＲＬについての判定依頼を、ユーザ端末２０の送受信部２２を介して有害判定サーバ４０に送信する。また、リクエスト先ＵＲＬと類似関係にあるＵＲＬのアクセスログがある場合（Ｓ１０５：ＹＥＳの場合）は、有害性の判定のステップに進む。
【００３９】
次に、ステップＳ１０６では、フィルタリングモジュール２０２が、キャッシュモジュール２０４の類似関係にあるＵＲＬの有害判定の結果を参照して、リクエスト先ＵＲＬのアクセスの許可をするか、しないかを判定する。なお、有害判定結果は、ユーザによるユーザ端末２０のアクセス設定も反映される。すなわち、有害判定サーバ４０が有害ではないと判断したＷｅｂサイトに、例えば、子供に利用させたくないショッピングサイト等のユーザによるアクセスの不許可を設定・追加してもよい。
【００４０】
次に、ステップＳ１０７では、有害判定サーバ４０が、ユーザ端末２０からの有害判定依頼を受信して、リクエスト先ＵＲＬを含むＷｅｂサイトが有害であるかをブラックリスト４１を用いて判定する。更に、判定結果（有害である、又は、有害ではない）をユーザ端末２０に送信する。そして、ユーザ端末２０のフィルタリングモジュール２０２が、送受信部２２を介して判定結果を受信する。
【００４１】
次に、ステップＳ１０８では、リクエスト先ＵＲＬを含むＷｅｂサイトが有害と判断された場合、並びに、有害ではないがユーザによってアクセスを不許可と設定された場合は、リクエスト先ＵＲＬに対するＷｅｂページの表示をブロックする。
【００４２】
又は、リクエスト先ＵＲＬを含むＷｅｂサイトが有害ではない場合、並びに、有害ではなくアクセス許可であった場合は、フィルタリングモジュール２０２が、ＨＴＴＰリクエストを、ユーザ端末２０の送受信部２２により、ＷＷＷサーバ１０に送信する。ＷＷＷサーバ１０はＨＴＴＰリクエストを受信し、ＨＴＴＰリクエストに対するＨＴＴＰレスポンス（Ｗｅｂページのコンテンツデータを含む）をユーザ端末２０に送信する。キャッシュモジュール２０４が、送受信部２２を介してＨＴＴＰレスポンス（Ｗｅｂページのコンテンツデータを含む）を受信し、ユーザ端末２０の表示部２４により、Ｗｅｂページを表示する。なお、ＨＴＴＰレスポンスとは、ＨＴＴＰリクエストに対する、サーバから端末（クライアント）に返信するデータである。そして更に、キャッシュモジュール２０４にキャッシュ（アクセスログ）を保存する。ここでのキャッシュは、過去にＵＲＬ判定した情報のキャッシュなので、ＷＷＷサーバ１０のＨＴＴＰレスポンスがキャッシュされるのではなく、ＷＷＷサーバ１０のＵＲＬの有害性の判定結果がキャッシュとして残る。
【００４３】
［ＵＲＬフィルタリング処理のシステム概要］
図４は、従来のＵＲＬフィルタリング処理のシステム概要を示す図である。
【００４４】
従来のシステムでは、ＷｅｂブラウザからのＨＴＴＰリクエストについて、ユーザ端末２０の制御部２３が備えるフィルタリングモジュール２０２により、ＵＲＬフィルタリング処理が行われる。フィルタリングモジュール２０２がＨＴＴＰリクエストに含まれるＵＲＬと同一ＵＲＬについてキャッシュモジュール２０４の判定結果のキャッシュ（アクセスログ）を参照する。また、キャッシュがない場合は、ＵＲＬの判定依頼を有害判定サーバ４０に送信する。そして、有害判定サーバ４０がＵＲＬの有害性を判定して、そのＵＲＬの判定結果をユーザ端末２０のフィルタリングモジュール２０２に送信する。
【００４５】
ここで、大量のＵＲＬアクセス要求を含むＨＴＴＰリクエストがありＵＲＬフィルタリング処理を行う場合は、個々のＵＲＬについてキャッシュモジュール２０４を参照し、更に、ＨＴＴＰリクエストに含まれるＵＲＬと同一のＵＲＬが、キャッシュモジュール２０４にない場合は、個々のＵＲＬについて有害性の判定依頼を有害判定サーバ４０に送信する。
【００４６】
しかし、このように従来のシステムにおいて、個々のＵＲＬについての有害性の判定依頼を行うことは、有害判定サーバ４０及びユーザ端末２０の処理負荷が増大してパフォーマンスが低下する等の要因となる。また、Ｗｅｂブラウザ上では、Ｗｅｂページ全体から一部のデータが抜けた表示状態が続いたりする。また、キャッシュモジュール２０４によるキャッシュ（アクセスログ）の保存において、多くの不必要なＵＲＬがログに出力されることにより、ログファイル保存スペースが増大し、更に、ログの参照効率が低下する等の要因になる。
【００４７】
図５は、図４の従来システムに、本発明の好適な実施形態の一例に係るＵＲＬ類似性判定モジュール２０３を備えたＵＲＬフィルタリング処理のシステム概要を示す図である。
【００４８】
このシステムでは、複数のＵＲＬアクセス要求を含むＨＴＴＰリクエストがＵＲＬ類似性判定モジュール２０３により分析され、類似関係にあるＵＲＬについて、キャッシュモジュール２０４を参照する。こうすることで、個々のＵＲＬについてキャッシュモジュール２０４のキャッシュを参照して有害性の判定を行うので、有害判定サーバ４０への問合わせが省かれる。また、類似関係にあるＵＲＬが、キャッシュモジュール２０４にない場合は、類似関係にあるＵＲＬの有害性の判定依頼を有害判定サーバ４０に送信する。次に、有害判定サーバ４０は、判定依頼されたＵＲＬの有害性を判定して、その判定結果をユーザ端末２０に送信する。
【００４９】
こうすることで、判定依頼に伴う処理を、個々のＵＲＬ毎に行うという従来システムよりも効率的に行うことができる。また、キャッシュモジュール２０４によるキャッシュ（アクセスログ）の保存において、類似関係にあるＵＲＬだけがログに出力されることにより、ログファイル保存スペースを減らし、更に、ログの参照効率を高めること等ができる。なお、アクセスログについては、図１３で後述する。
【００５０】
図６は、本発明の好適な実施形態の別の例に係るＵＲＬ類似性判定モジュール２０３を別のサーバに備えたＵＲＬフィルタリング処理のシステム概要を示す図である。
【００５１】
例えば会社のネットワークに接続されたユーザ端末２０は、直接インターネット等のネットワークに接続が出来ないので、必ず、社内ネットワークのサーバ（イントラネットにおけるサーバ）を経由する。そこで、ＵＲＬフィルタリング処理を社内ネットワークのサーバで行うようにすることができる。このことにより、ユーザ端末２０毎のＵＲＬフィルタリング処理が不要となる。なお、社内ネットワークではなく、学校や家庭等であっても、サーバを経由した外部アクセスのネットワークであれば、同様に行うことができる。
【００５２】
［ソケット監視モジュールによる大量のＵＲＬアクセス要求監視］
次に、ソケット監視モジュール２０１による「大量のＵＲＬアクセス要求」の監視方法について説明する。ソケット監視モジュール２０１は、一度に大量のＵＲＬアクセス要求が送信されていることを検出する。検出方法には、（１）ＷＳＰＳｅｌｅｃｔ（後述）を利用して送信待機の状態のソケット数を監視する方法、（２）リクエストとレスポンスのカウントを監視する方法がある。一度に大量のＵＲＬアクセス要求が送信される具体例としては、Ａｊａｘ等の技術が使用されているＷｅｂページがある。このため、大量のＵＲＬアクセス要求が送信される場合を、Ａｊａｘ対応フィルタリングモードとも呼ぶことにする。
【００５３】
Ａｊａｘは、例えばＷｅｂ検索に応用することで、従来は入力確定後に行っていた検索を、ユーザがキー入力をする間にバックグラウンドで行うことでリアルタイムに検索結果を表示していくといったことを可能にする。このように、送信側と受信側の同期を求めず、一度に大量のＵＲＬアクセス要求を送信するＡｊａｘ仕様のＷｅｂページが増加する傾向にある。
【００５４】
（１）のＷＳＰＳｅｌｅｃｔを利用して送信待機状態のソケット数を監視する方法について説明する。図７は、本発明の好適な実施形態の一例に係るソケット監視モジュール２０１のＷＳＰＳｅｌｅｃｔを利用した送信待機状態のソケット数の監視のフローチャートである。ＷＳＰＳｅｌｅｃｔは、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）  ＯＳにおけるＷｉｎＳｏｃｋ  ＡＰＩのｆｕｎｃｔｉｏｎの１つで、ソケットを調査するモジュールである。詳細は、“ＷＳＰＳｅｌｅｃｔ”，［ｏｎｌｉｎｅ］，［２００７年２月２日検索］、インターネット＜ＵＲＬ  ｈｔｔｐ：／／ｍｓｄｎ２．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ−ｕｓ／ｌｉｂｒａｒｙ／ｍｓ７４２２８９．ａｓｐｘ＞を参照。ソケットは、前述したように、ＩＰアドレスと、複数のコンピュータと同時に通信するためのサブアドレスとしての複数のポート番号を組み合わせたネットワーク・アドレスのことである。
【００５５】
まず、ステップＳ２０１では、ソケット監視モジュール２０１が、ＷＳＰＳｅｌｅｃｔを利用し、送信待機状態のソケットの個数を得る。
【００５６】
次に、ステップＳ２０２において、ソケット監視モジュール２０１は、得られた送信待機状態のソケット数が所定数（例えば、２）未満の場合に、通常のＵＲＬアクセス要求であると判定し、ＵＲＬフィルタリング処理を行う。
【００５７】
次に、ステップＳ２０３では、上述ステップＳ２０２において、送信待機状態のソケット数が所定数（例えば、２）以上の場合に、Ａｊａｘ等の技術が使用されているＷｅｂページによるＨＴＴＰリクエスト、すなわち、大量のＵＲＬアクセス要求が送信されている（Ａｊａｘ対応フィルタリングモード）と判定する。そして、ソケット単位で、ＵＲＬ類似性判定モジュール２０３を備えたＵＲＬフィルタリング処理を行う。
【００５８】
（２）のリクエストとレスポンスのカウントを監視する方法について説明する。同一ＩＰアドレスを使用しているソケットに対し、リクエストとレスポンスの数、順番をカウントし、リクエストがレスポンスを受信せずに一定時間内に所定の数以上連続して行われた場合に、大量のＵＲＬアクセス要求が送信されている（Ａｊａｘ対応フィルタリングモード）とみなし、ＵＲＬ類似性判定モジュール２０３が備えたＵＲＬフィルタリング処理を行う。こうすることで、上述のＷＳＰＳｅｌｅｃｔを利用した送信待機状態のソケット数を監視する方法に対して補助的な方法を提供することができる。この方法が適用される主なサービスとしては、ユーザが検索文字列を入力する際に文字列の候補を推定して表示するユーザ入力を補う入力補助機能がある。
【００５９】
［ＵＲＬの類似性分析例］
図８は、本発明の好適な実施形態に係るＵＲＬの類似性分析の一例を示す図である。
【００６０】
まず、ステップＳ３０１では、ＨＴＴＰリクエストからＵＲＬアクセス要求部分の「ＧＥＴ  ／ｍｔ？ｎ＝４０４＆ｖ＝ｗ２．１２＆ｘ＝５８２０２＆ｙ＝２５８１２＆ｚｏｏｍ＝１  ＨＴＴＰ／１．１」から、クエリ文字列の「？ｎ＝４０４＆ｖ＝ｗ２．１２＆ｘ＝５８２０２＆ｙ＝２５８１２＆ｚｏｏｍ＝１」を抽出する。
【００６１】
次に、ステップＳ３０２では、クエリ文字列の各パラメータを「？ｎ＝」、「＆ｖ＝」等で分割する。ここで、「？ｎ＝」、「＆ｖ＝」等はパラメータの識別子（ｉｄ）である。
【００６２】
次に、ステップＳ３０３では、各識別子に続く文字列のタイプを決定する。ここで、タイプ（Ｔｙｐｅ）は、ｆ：数値、ｃ：文字列、ｅ：「その他」と定義する。例えば、「？ｎ＝４０４」では４０４が数値であるので「？ｎ＝」は「Ｔｙｐｅ＝ｆ」と定義される。また、「＆ｖ＝ｗ２．１２」ではｗ２．１２が文字列及び数値であるので「その他」になり、「＆ｖ＝」は「Ｔｙｐｅ＝ｅ」と定義される。
【００６３】
次に、ステップＳ３０４では、パラメータ（ｉｄ）となる識別子及び文字列のタイプ（Ｔｙｐｅ）、並びにそれらの出現順番等の、クエリ文字列分析結果が、ＵＲＬの類似性判定基準としてキャッシュモジュール２０４にキャッシュされ、以降の類似性判定に使用される。
【００６４】
なお、類似性があると判定する場合は、複数のＵＲＬ間において以下の条件の両方を満たす場合に限られる。
（１）“？”以降の文字列を含まないＵＲＬが完全に一致
（２）類似性の判定基準（ｉｄ，Ｔｙｐｅ，出現順番）が完全に一致
【００６５】
図９は、本発明の好適な実施形態の一例に係るＨＴＴＰリクエストを示す図である。上述したＵＲＬの類似性分析を行うと、（ａ）、（ｂ）、（ｃ）については類似関係にあると判定できる。具体的に、（ａ）のリクエストが発生したときにソケットが所定数（例えば、２）以上存在した場合は、ＵＲＬ類似性判定モジュール２０３により、クエリ文字列を解析してできた類似性判定基準が生成される。
【００６６】
次に、（ｂ）のリクエストの時、既に大量のＵＲＬアクセス要求であると判定されているため、クエリ文字列を解析し、（ａ）で先に生成された類似性判定基準と比較する。ここで、（ａ）と（ｂ）のクエリ文字列のタイプが同じであるため、（ａ）のリクエストと類似関係にあると判定される。（ｃ）も同様である。具体的には、（ａ）、（ｂ）、（ｃ）において、「＆ｘ＝」に続く数値が異なるが、いずれも数値であり、Ｔｙｐｅが同一と判定できて、類似関係があると判定される。
【００６７】
次に、（ｄ）のリクエストが発生した時、（ａ）、（ｂ）、（ｃ）と同じＩＰアドレスであれば類似関係のないＵＲＬと判断する。異なるＩＰアドレスであった場合は、大量のＵＲＬアクセス要求と判定されている場合に限りクエリ文字列を解析し、新たな類似性判定基準を生成する。
【００６８】
図１０並びに図１１は、類似関係にあるＵＲＬアクセス要求を含むＨＴＴＰリクエストの例を示す図である。図１０は、１から３行目までのＵＲＬが類似関係にある。また、８行目と９行目とが類似関係にある。図１１においては、１行目と、５行目と、６行目とが類似関係にある。
【００６９】
［Ｒｅｆｅｒｅｒのチェック］
図１２は、本発明の好適な実施形態の一例に係るＵＲＬ類似性判定モジュール２０３を備えたＵＲＬフィルタリング処理にＲｅｆｅｒｅｒのチェックを含むフローチャートである。Ｒｅｆｅｒｅｒとは、ＨＴＴＰリクエストのヘッダに含まれる項目であり、Ｗｅｂページのリンクを選択して別のＷｅｂページに移動するときの、リンク元のＷｅｂページのＵＲＬを含むデータである。
【００７０】
まず、ステップＳ４０１乃至ステップＳ４０５は、ソケット監視モジュール２０１による大量のＵＲＬアクセスの要求監視、並びにＵＲＬ類似性判定モジュール２０３のＵＲＬフィルタリング処理と同様である。そして、ステップＳ４０６では、ＨＴＴＰリクエストのヘッダ中にＲｅｆｅｒｅｒがあるかを参照する。
【００７１】
次に、ステップＳ４０７では、ＨＴＴＰリクエストのヘッダ中にＲｅｆｅｒｅｒがある場合（Ｓ４０６：ＹＥＳの場合）に、Ｒｅｆｅｒｅｒに含まれたＵＲＬの有害判定を行う。こうすることで、ＨＴＴＰリクエストでＡｊａｘ等の技術を用いバックグラウンドで取得するデータ（ＵＲＬ）が、有害であるＷｅｂサイトにリンクしているかどうかを発見することができる。
【００７２】
次に、ステップＳ４０８では、ＨＴＴＰリクエストのヘッダ中にＲｅｆｅｒｅｒがない場合（Ｓ４０６：ＮＯの場合）は、クエリ文字列を分析した結果（類似性判定基準）の有害判定を行う。
【００７３】
［アクセスログのログファイル集計方法］
図１３は、本発明の好適な実施形態の一例に係るアクセスログを集計する装置にＵＲＬ類似性判定モジュール２０３を適用する場合のフローチャートである。アクセスログの集計装置の設置には多種多様な方法が考えられるため、ここではその集計方法のみに着目し、ＵＲＬ類似性判定モジュール２０３の適用例を説明する。
【００７４】
まず、ステップＳ５０１では、ユーザ端末２０の制御部２３が、Ｗｅｂページのアクセスログ（ＵＲＬ）を取得する。Ｗｅｂブラウザでは、新たなＷｅｂページに移動していて、Ａｊａｘ等の技術を用いバックグラウンドで取得している複数のデータのアクセスログ（ＵＲＬ）が、１つ１つ取得される。
【００７５】
次に、ステップＳ５０２では、ＵＲＬ類似性判定モジュール２０３が、キャッシュモジュール２０４を参照し、取得したアクセスログのＵＲＬの類似性分析を実施する。ここでは、複数取得したアクセスログ同士でのＵＲＬの類似性分析を行ってもよい。
【００７６】
次に、ステップＳ５０３では、ＵＲＬ類似性判定モジュール２０３が、取得したアクセスログのＵＲＬと類似関係のあるＵＲＬが、キャッシュモジュール２０４にあるかどうかを参照する。
【００７７】
次に、ステップＳ５０４では、取得したアクセスログのＵＲＬと類似関係のあるＵＲＬが、キャッシュモジュール２０４にある場合（Ｓ５０３：ＹＥＳの場合）は、取得したアクセスログを保存しない。
【００７８】
次に、ステップＳ５０５では、取得したアクセスログのＵＲＬと類似関係のあるＵＲＬが、キャッシュモジュール２０４にない場合（Ｓ５０３：ＮＯの場合）、取得したアクセスログのＵＲＬを類似性分析したＵＲＬを保存する。このように、既に保存済みであるＵＲＬと類似性があると判断された場合は、新規にアクセスログとして保存せず、類似性が認められなかった場合に保存するようにする。具体的なアクセスログ保存の一例として、図１４を参照しながら説明する。
【００７９】
図１４の例において、上部は新たに取得したＷｅｂページのアクセスログ（ＵＲＬ）である。ここでは、キャッシュモジュール２０４にアクセスログがない状態である。取得したアクセスログ（ＵＲＬ）にＵＲＬ類似性判定モジュール２０３を適用すると、図１４の下部のように、類似しないＵＲＬだけをログに保存することが可能となる。こうすることで、ログファイルの容量が大幅な削減と、ログファイルの簡略化が期待できる。例えば、図１４の新たに取得した上から２行目と、３行目と、４行目とのＷｅｂページのＵＲＬは、類似関係にあるので、ログには２行目のＵＲＬを保存するだけでよい。
【００８０】
［サーバ及び端末のハードウェア構成］
図１５は、本発明の好適な実施形態の一例に係るＷＷＷサーバ１０及び有害判定サーバ４０（以下、サーバという）、及びユーザ端末２０のハードウェア構成を示す図である。以下、サーバを例にして説明するが、クライアントであるユーザ端末２０についても基本的には同様である。
【００８１】
サーバは、制御部１０１を構成するＣＰＵ１１０（マルチプロセッサ構成ではＣＰＵ１２０等複数のＣＰＵが追加されてもよい）、バスライン１０５、通信Ｉ／Ｆ１４０、メインメモリ１５０、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）１６０、ＵＳＢポート１９０、Ｉ／Ｏコントローラ１７０、並びにキーボード及びマウス１８０等の入力手段や表示装置１２２を備える。
【００８２】
Ｉ／Ｏコントローラ１７０には、テープドライブ１７２、ハードディスク１７４、光ディスクドライブ１７６、半導体メモリ１７８、等の記憶部１０２を接続することができる。
【００８３】
ＢＩＯＳ１６０は、サーバの起動時にＣＰＵ１１０が実行するブートプログラムや、サーバのハードウェアに依存するプログラム等を格納する。
【００８４】
ハードディスク１７４は、サーバとして機能するための各種プログラム及び本発明の機能を実行するプログラムを記憶する。
【００８５】
光ディスクドライブ１７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この場合は各ドライブに対応した光ディスク１７７を使用する。光ディスク１７７から光ディスクドライブ１７６によりプログラム又はデータを読み取り、Ｉ／Ｏコントローラ１７０を介してメインメモリ１５０又はハードディスク１７４に提供することもできる。また、同様にテープドライブ１７２に対応したテープメディア１７１を主としてバックアップのために使用することもできる。
【００８６】
サーバに提供されるプログラムは、ハードディスク１７４、光ディスク１７７、又はメモリーカード等の記録媒体に格納されて提供される。このプログラムは、Ｉ／Ｏコントローラ１７０を介して、記録媒体から読み出され、又は通信Ｉ／Ｆ１４０を介してダウンロードされることによって、サーバにインストールされ実行されてもよい。
【００８７】
上述のプログラムは、内部又は外部の記憶媒体に格納されてもよい。ここで、記憶媒体としては、ハードディスク１７４、光ディスク１７７、又はメモリーカードの他に、ＭＤ等の光磁気記録媒体、テープメディア１７１を用いることができる。また、専用通信回線やインターネット等の通信回線に接続されたサーバシステムに設けたハードディスク１７４又は光ディスクライブラリ等の記憶装置を記録媒体として使用し、通信回線３０を介してプログラムをサーバに提供してもよい。
【００８８】
ここで、表示装置１２２は、ユーザによるデータの入力を受け付ける画面を表示したり、ＷＷＷサーバ１０及び有害判定サーバ４０による演算処理結果の画面を表示したりするものであり、ブラウン管表示装置（ＣＲＴ）、液晶表示装置（ＬＣＤ）等のディスプレイ装置を含む。
【００８９】
ここで、入力手段は、ユーザによる入力の受け付けを行うものであり、キーボード及びマウス１８０等により構成してよい。
【００９０】
また、通信Ｉ／Ｆ１４０は、サーバを専用ネットワーク又は公共ネットワークを介して端末と接続できるようにするためのネットワーク・アダプタである。通信Ｉ／Ｆ１４０は、モデム、ケーブル・モデム及びイーサネット（登録商標）・アダプタを含んでよい。なお、ユーザ端末２０は、サーバと同様の構成を備えてよいが、端末として必要最小限のハードウェア構成としてよいのは言うまでもない。
【００９１】
以上の例は、サーバのハードウェア構成について主に説明したが、コンピュータに、プログラムをインストールして、そのコンピュータをサーバとして動作させることにより上記で説明した機能を実現することもできる。従って、本発明において一実施形態として説明したサーバにより実現される機能は、上述の方法を当該コンピュータにより実行することにより、あるいは、上述のプログラムを当該コンピュータに導入して実行することによっても実現可能である。
【００９２】
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施例に記載されたものに限定されるものではない。
【図面の簡単な説明】
【００９３】
【図１】本発明の好適な実施形態の一例に係るシステム１の全体構成を示す図である。
【図２】本発明の好適な実施形態の一例に係るユーザ端末２０、並びに有害判定サーバ４０の機能ブロック図である。
【図３】本発明の好適な実施形態の一例に係るＵＲＬフィルタリング処理のフローチャートである。
【図４】従来のＵＲＬフィルタリング処理のシステム概要を示す図である。
【図５】本発明の好適な実施形態の一例に係るＵＲＬ類似性判定モジュール２０３を備えたＵＲＬフィルタリング処理のシステム概要を示す図である。
【図６】本発明の好適な実施形態の別の例に係るＵＲＬ類似性判定モジュール２０３を備えたＵＲＬフィルタリング処理のシステム概要を示す図である。
【図７】本発明の好適な実施形態の一例に係るソケット監視モジュール２０１のＷＳＰＳｅｌｅｃｔを利用する大量のＵＲＬアクセス要求監視のフローチャートである。
【図８】本発明の好適な実施形態に係るＵＲＬの類似性分析の一例を示す図である。
【図９】本発明の好適な実施形態の一例に係るＨＴＴＰリクエストを示す図である。
【図１０】本発明の好適な実施形態の一例に係る類似関係にあるＵＲＬアクセス要求を含むＨＴＴＰリクエストを示す図である。
【図１１】本発明の好適な実施形態の別の一例に係る類似関係にあるＵＲＬアクセス要求を含むＨＴＴＰリクエストを示す図である。
【図１２】本発明の好適な実施形態の一例に係るＵＲＬ類似性判定モジュール２０３を備えたＵＲＬフィルタリング処理にＲｅｆｅｒｅｒのチェックを含むフローチャートである。
【図１３】本発明の好適な実施形態の一例に係るアクセスログを集計する装置にＵＲＬ類似性判定モジュール２０３を適用する場合のフローチャートである。
【図１４】本発明の好適な実施形態の一例に係る具体的なアクセスログ保存を示す図である。
【図１５】本発明の好適な実施形態の一例に係るＷＷＷサーバ１０、有害判定サーバ４０、及びユーザ端末２０のハードウェア構成を示す図である。
【符号の説明】
【００９４】
１  システム
１０  ＷＷＷサーバ
２０  ユーザ端末
３０  通信回線
４０  有害判定サーバ
２０１  ソケット監視モジュール
２０２  フィルタリングモジュール
２０３  ＵＲＬ類似性判定モジュール
２０４  キャッシュモジュール
【図１】
2008204425.tif 000003
【図２】
2008204425.tif 000004
【図３】
2008204425.tif 000005
【図４】
2008204425.tif 000006
【図５】
2008204425.tif 000007
【図６】
2008204425.tif 000008
【図７】
2008204425.tif 000009
【図８】
2008204425.tif 000010
【図９】
2008204425.tif 000011
【図１０】
2008204425.tif 000012
【図１１】
2008204425.tif 000013
【図１２】
2008204425.tif 000014
【図１３】
2008204425.tif 000015
【図１４】
2008204425.tif 000016
【図１５】
2008204425.tif 000017