JP2013164719A

JP2013164719A - Ｕｒｌフィルタリングシステム

Info

Publication number: JP2013164719A
Application number: JP2012027153A
Authority: JP
Inventors: Takanobu Kawabe; 隆伸川邉
Original assignee: Nippon Telegraph and Telephone Corp; Nippon Telegraph and Telephone West Corp
Current assignee: Nippon Telegraph and Telephone Corp; Nippon Telegraph and Telephone West Corp
Priority date: 2012-02-10
Filing date: 2012-02-10
Publication date: 2013-08-22
Anticipated expiration: 2032-02-10
Also published as: JP5801218B2

Abstract

【課題】フィルタリング部として働くプロキシサーバにかかる負荷を抑えつつ、通信オーバーヘッドを抑えたＵＲＬフィルタリングシステムを実現する。
【解決手段】ＵＲＬフィルタリング装置２０と、埋込ＵＲＬサーバ４０及び規制対象ＤＢサーバ３０とからなるフィルタリングシステムとする。埋込ＵＲＬサーバ４０が、通常時にＵＲＬフィルタリング装置２０から受け付けるリクエストの処理と、その処理を高速に行うための準備である定期的なバッチ処理とを別個に行う。普段はリクエスト数をカウントし、バッチ処理でそのカウントが多いＵＲＬのドキュメントを解析し、埋め込まれたＵＲＬを予め埋込ＵＲＬデータベース４３に記録して読み出し可能としておく。埋込ＵＲＬサーバ４０はリクエストに対して埋込ＵＲＬを返答し、ＵＲＬフィルタリング装置２０はそれらＵＲＬへの接続の可否を一括して規制対象ＤＢサーバ３０に問い合わせる。
【選択図】図１

Description

この発明は、ＵＲＬフィルタリングによる脅威の遮断によって、利用者により安全なネットワーク利用を提供するシステム、及びシステム制御方法に関する。

主にインターネットに代表されるネットワーク上には、利用者にとって好ましくない情報やプログラムが一部に存在している。例えば、利用者の端末にコンピュータウイルスを仕掛けたり、利用者を誤認させてパスワードやクレジットカード番号などの個人情報を入力させるフィッシングを行うといった、悪意を持って作られたページである。これらのページへは、検証目的でも無い限り不用意に接続しないことが推奨される。また、未成年の利用者に対しては、成人向けのコンテンツへ接続しないことが求められるし、業務用の端末からゲームなどの娯楽関連サイトへの接続を行わないように使用者が規制したいと考える場合もある。こういった様々な理由から、規制されたＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）へのアクセスを遮断するＵＲＬフィルタリングが一般に行われている。

フィルタリングの方法としては、ブラウザもしくはＨＴＴＰ−Ｐｒｏｘｙ機能を持つ端末の内部に規制対象となるＵＲＬのリストであるデータベースを保持し、ＨＴＴＰの問い合わせを実施する前にそのデータベースと接続先ＵＲＬとの対照を行い、接続可否を判断する方法がある。しかし、端末内部にそのデータベースを保持しようとすると、近年の規制対象となるサイトの増加に伴うデータベースの肥大化により、端末に要求されるリソースが大きくなる。

一方、常時接続回線の普及により家庭用ルータが広く利用されており、これが接続を中継するＨＴＴＰ−ｐｒｏｘｙ機能を持つプロキシサーバとして、フィルタリングを担う実施形態もある。ただし、このような家庭用ルータなどは比較的処理能力やメモリ容量が小さいものが多く、規制対象となるＵＲＬのリストであるデータベースを自前で保持、検索しようとするのは難しい。

また、接続を規制すべきＵＲＬの一覧はサイトの生成や消滅により刻々と変化するため、その一覧を記録する規制対象ＵＲＬデータベースも随時更新していかなければならない。従って、この規制対象ＵＲＬデータベースは、端末やフィルタリング装置内に保持するよりも、インターネット上に設けたセキュリティサーバで保持し、端末から接続の可否を問い合わせる方が脅威の発生に対する即応性の点から望ましい。このようにすれば、端末やフィルタリング装置が必要とするリソースは大きく抑制できる。

ただし、現在のインターネットで使われているＨＴＭＬドキュメントやＸＭＬドキュメントの大半には、多数の画像ファイルや動画、アニメーションファイル等が埋め込まれており、一つのページを表示するために必要な規制対象か否かの問い合わせは、その個々のファイルへのＨＴＴＰ接続ごとに発生するため、ここで生じる通信オーバーヘッドは増大する傾向にあり、利用者にとってはその分インターネットアクセスのレスポンスが下がって見えることになる。また、規制対象ＵＲＬデータベースは多数の端末から問い合わせを受けることになるため、データベースサーバを運営するセキュリティプラットフォーム側に要求されるサーバ性能も極めて高いものが要求される。

これに対して、特許文献１で、その負荷を軽減する方法が提案されている。これはまず、プロキシサーバでもあるフィルタリング装置が、端末の接続要求を中継してダウンロードしたＨＴＭＬファイルについて、フィルタリング装置内でＨＴＭＬ構造を解析する。その結果、リンクや画像の指定、インラインフレームなどの形でＨＴＭＬファイルに埋め込まれたコンテンツのアドレスである埋込ＵＲＬについて、規制対象ＵＲＬデータベース内のＵＲＬに該当するかをまとめてチェックする。該当すればそのＵＲＬはまとめて、規制対象へのリンクであることを示す安全な画像ファイルを指定するＵＲＬに変換する。これにより、ＨＴＭＬファイルを表示するにあたり個々の埋込ＵＲＬについて個別に問い合わせをする必要がなくなり、通信オーバーヘッドを抑制できる。

特開２０１１−２２１６１６号公報

しかしながら、特許文献１に記載のシステムでは、プロキシサーバでＨＴＭＬの構造解析を行わなければならず、プロキシサーバにブラウザと同様のＨＴＭＬ解析機能を持たせなければならない。しかもそのＨＴＭＬ解析はユーザの端末がドキュメントへアクセスするたびに、利用者にタイムラグを与えないように速やかに行わなければならない。このため、プロキシサーバに要求される処理能力が高く、家庭用インターネットルータなどの比較的低価格低スペックであるプロキシサーバをフィルタリング装置とする場合に利用することが難しかった。

そこでこの発明は、端末やフィルタリング装置に要求される処理性能や消費リソースを低く抑え、なおかつ、インターネット閲覧時の通信オーバーヘッドをも抑えたＵＲＬフィルタリングシステムを実現することを目的する。

この発明は、利用者の端末に内蔵又は併設したＵＲＬフィルタリング部と、上記ＵＲＬフィルタリング部と相互に通信する埋込ＵＲＬサーバ及び規制対象ＤＢサーバとからなるフィルタリングシステムであり、上記埋込ＵＲＬサーバが、通常時に上記ＵＲＬフィルタリング部から受け付けるリクエストの処理と、その処理を高速に行うための準備である定期的なバッチ処理とを別個に行うようにしたものである。その内容は次の通りである。
通常時には、利用者のコンテンツ表示用端末が発した接続要求の指定先である接続先ＵＲＬを含むリクエストを上記ＵＲＬフィルタリング部から受け取って、その接続先ＵＲＬを問い合わせの回数カウントとともに問合頻度データベースに記録する頻度更新機能を実行する。一方で、上記問合頻度データベースに記録された直近の問い合わせ頻度が高い一部のＵＲＬ群について、それらＵＲＬ群に対応する一連のドキュメントをダウンロードして解析し、当該ドキュメントに埋め込まれた埋込ＵＲＬを、接続先ＵＲＬとともに埋込ＵＲＬデータベースに記録する定期的なバッチ処理を行うバッチ処理実行機能を実行させておく。そのバッチ処理が一回以上された後の通常時のリクエスト処理では、上記バッチ処理により上記埋込ＵＲＬデータベースに記録された上記接続先ＵＲＬを含む上記ＵＲＬフィルタリング部からの上記リクエストに対しては、対応する上記埋込ＵＲＬを上記埋込ＵＲＬデータベースから呼び出して、該当ＵＲＬと上記埋込ＵＲＬを上記ＵＲＬフィルタリング部へ返答する埋込ＵＲＬ返答機能を、上記頻度更新機能とともに実行する。上記ＵＲＬフィルタリング部は、上記埋込ＵＲＬサーバから返答された接続先ＵＲＬとそれに対応した上記埋込ＵＲＬとについて、規制対象ページのアドレスの一覧である規制ＵＲＬ一覧を記録した上記規制対象ＤＢサーバに対して、一括して接続の可否を問い合わせ、その応答可否結果に従って接続先ＵＲＬと上記埋込ＵＲＬとに対応したファイルへの接続要求を遮断する。

すなわち、多くのＵＲＬフィルタリング部からアクセスのあるＵＲＬのドキュメントについて、埋込ＵＲＬサーバがリクエストのカウントとは別個に定期的なバッチ処理を行い、予めそのドキュメントの埋込ＵＲＬを解析しておきそのリストを上記埋込ＵＲＬデータベースに記録しておく。以後に同一ＵＲＬについてのリクエストがフィルタリング部からあれば、解析するまでもなく上記埋込ＵＲＬデータベースから接続先ＵＲＬのドキュメントに埋め込まれた埋込ＵＲＬのリストを呼び出し、速やかにＵＲＬフィルタリング部に返答することができる。

より具体的な構成は次のような形態での実施が可能である。
まず、上記ＵＲＬフィルタリング部は、ＵＲＬ接続可否キャッシュと、中継代理サーバ部と、ＵＲＬ評価部とを有する。
上記ＵＲＬ接続可否キャッシュは、上記接続先ＵＲＬに埋め込まれた上記埋込ＵＲＬについての接続の可否を、少なくともそれら一連のＵＲＬへの接続要求が完了し得る制限時間付きで一時記憶する一時記憶機能を有する。
上記中継代理サーバ部は、上記接続要求を受信して、上記ＵＲＬ評価部へ問い合わせを送信する要求問合機能と、上記接続の可否の結果を受信してその結果に従い上記接続要求に対する遮断を行う遮断機能とを有する。
上記ＵＲＬ評価部は、上記問い合わせを受けて上記埋込ＵＲＬサーバへ上記リクエストを送信するリクエスト機能と、上記埋込ＵＲＬサーバから上記埋込ＵＲＬの無い返答を受信した場合には接続先ＵＲＬのみへの接続の可否を上記規制対象ＤＢサーバへ問い合わせる単独可否問合機能と、上記埋込ＵＲＬサーバから上記埋込ＵＲＬを受信した場合には上記規制対象ＤＢサーバへ上記接続の可否を問い合わせる一括可否問合機能と、前記一括可否問合機能の返答である上記埋込ＵＲＬの接続の可否を上記ＵＲＬ接続可否キャッシュへ書き込む第一キャッシュ機能と、接続先ＵＲＬへの接続の可否の結果を上記中継代理サーバ部へ返答する通常返答機能と、上記接続要求からの問い合わせに対し接続先ＵＲＬについて上記ＵＲＬ接続可否キャッシュを検索して予め記録された上記埋込ＵＲＬに該当すれば上記リクエストを送信することなくその可否を上記中継代理サーバ部へ返答する高速返答機能とを有する。

すなわち、ＵＲＬフィルタリング部が埋込ＵＲＬについての接続の可否をまとめて規制対象ＤＢサーバに問い合わせ、接続先ＵＲＬのドキュメントに埋め込まれた一連の画像等のコンテンツを指定する埋込ＵＲＬへのアクセスが終わるまで上記ＵＲＬ接続可否キャッシュにその接続の可否の情報を記録しておくことで、個々の埋込ＵＲＬへの接続のたびに規制対象ＤＢサーバへの問い合わせをせずに済むことになる。

このＵＲＬフィルタリング部は、端末の外部にあってＬＡＮで繋がった独立した装置であってもよいし、端末がブラウザの機能やパーソナルファイアウォールの機能として有するソフトウェアであってもよい。この発明ではＵＲＬフィルタリング部がＨＴＭＬ解析などの負荷が大きい処理を行わずに済むため、その機能を端末にソフトウェアとして組み込んでも大きな負担とならずに済むためである。

また、そのようなリクエストに対応する上記埋込ＵＲＬサーバについての具体的構成としては、通常時のリクエストを処理する埋込ＵＲＬデータベース管理部と、定期的な上記バッチ処理を実行するデータベース更新部と、上記バッチ処理の際に解析を行うコンテンツ解析部と、上記埋込ＵＲＬデータベースと、上記問合頻度データベースとを有する。
上記データベース更新部は、上記ＵＲＬ群を上記問合頻度データベースから読み出して上記コンテンツ解析部に送る頻度読出機能と、上記埋込ＵＲＬデータベースに上記ＵＲＬ群とともにそれらそれぞれに対応する上記埋込ＵＲＬを記録する埋込ＵＲＬ記録機能を有するものとする。
上記コンテンツ解析部は、上記ＵＲＬ群を構成するＵＲＬのそれぞれに対応するドキュメントを、接続先ＵＲＬが示すコンテンツサーバからダウンロードして解析し、そのドキュメントに埋め込まれた埋込ＵＲＬを求める事前解析機能を有するものとする。
上記埋込ＵＲＬデータベース管理部は、上記ＵＲＬフィルタリング部からの上記リクエストを受け取り接続先ＵＲＬを問い合わせの回数とともに上記問合頻度データベースに記録する上記頻度更新機能と、上記リクエストに含まれる接続先ＵＲＬについて上記埋込ＵＲＬデータベースを検索し、該当すれば接続先ＵＲＬに対応する上記埋込ＵＲＬを呼び出す埋込ＵＲＬ検索機能と、上記埋込ＵＲＬ及び前記検索で該当があれば上記埋込ＵＲＬを上記ＵＲＬ評価部へ返答する上記埋込ＵＲＬ返答機能とを有するものとする。

すなわち、頻度更新機能により問い合わせ頻度データベースにＵＲＬごとにリクエストのあった回数をカウントしておき、その回数が特に多いＵＲＬのみを頻度読出機能で読み出して、通常のリクエスト処理とは別に、定期的なバッチ処理としてドキュメントの解析を行う事前解析機能を実行することで、サーバの負荷を抑制しつつ、効率の良い応答が実現できる。このバッチ処理は例えば未明などのリクエストが比較的少ない時間帯に行えばよい。

またこの発明の別の形態として、上記の形態を次の様に変更しても好適なシステムとなる。通常時のリクエストの処理にあたり、上記埋込ＵＲＬデータベース管理部が、上記埋込ＵＲＬのリストを上記埋込ＵＲＬデータベースから読み出した後、そのリストを上記ＵＲＬフィルタリング部のＵＲＬ評価部に返答する前に、直接に規制対象ＤＢサーバへまとめて接続の可否を問い合わせて、返って来た接続の可否の結果とともに上記フィルタリング部に返答するようにする。この形態では、上記ＵＲＬフィルタリング部にかかる負荷は上記の形態よりも少なくなり、上記ＵＲＬフィルタリング部である家庭用ルータなどから外部へのリクエストを減らすこともできる。さらにこの実施形態において、埋込ＵＲＬサーバと規制対象ＤＢサーバとのネットワーク上の位置が近いと、ネットワーク全体の負荷をさらに下げることが出来る。

この発明により、家庭用ルータなどの比較的低スペックであるプロキシサーバでも機能拡張を最小限にして、効率の良いフィルタリングが可能となる。また、ドキュメントの解析を受け持つ埋込ＵＲＬサーバも、接続要求のたびに解析するのではなく、要求頻度の高いものに絞って解析を行うだけで済むため、サーバにかかる負荷も抑えながら速やかな応答が可能となる。これによりネットワーク全体での通信量も削減できる。

この発明の第一の実施形態にかかる構成図第一の実施形態における通常時リクエストの処理を示す前半のフロー図第一の実施形態における通常時リクエストの処理を示す後半のフロー図この発明にかかる埋込ＵＲＬサーバのバッチ処理を示すフロー図（ａ）ＵＲＬ接続可否キャッシュの例を示すテーブル、（ｂ）問合頻度データベースの例を示すテーブル、（ｃ）埋込ＵＲＬデータベースの例を示すテーブル、（ｄ）規制対象ＵＲＬデータベースの例を示すテーブルこの発明の第二の実施形態にかかる構成図第二の実施形態における通常時リクエストの処理を示す前半のフロー図第二の実施形態における通常時リクエストの処理を示す後半のフロー図この発明の第三の実施形態にかかる構成図

以下、この発明の具体的な実施形態について説明する。この発明にかかるフィルタリングシステムの第一の実施形態は、図１に記載の構成からなる。すなわち、利用者が利用するコンテンツ表示用端末１０と、それに併設されるＵＲＬフィルタリング装置２０と、規制対象となるアドレスの情報を有する規制対象ＤＢサーバ３０と、リクエストを処理する埋込ＵＲＬサーバ４０と、コンテンツ自体を有するコンテンツサーバ５０である。また、以下に記載の「部」とはハードウェア又はソフトウェアによって実行される処理回路、処理機構又は処理装置であり、「機能」とは「部」又はデータベースで実行されるプログラムである。

上記のコンテンツ表示用端末１０は、有線ＬＡＮ又は無線によるネットワーク接続機能と、インターネットブラウザ機能を発揮するブラウザ処理部１１を有するものであれば特に限定されない。具体的にはパソコン、スマートフォン、フィーチャーフォン、ネットワーク対応ゲーム機、ネットワーク対応レコーダなどが挙げられる。上記のＵＲＬフィルタリング装置２０を介して外部ネットワークに接続する。

上記のＵＲＬフィルタリング装置２０は、上記コンテンツ表示用端末１０がコンテンツサーバ５０にアクセスする際の接続要求を中継するプロキシサーバであるとともに、その接続要求が規制対象となるアドレスへのものである場合にはそれを遮断するＵＲＬフィルタリング部としての機能を有する装置である。具体的には、家庭用ルータや、比較的小規模なネットワーク向けのルータが挙げられ、上記コンテンツ表示用端末１０と同一ネットワーク内にあって併設されている。大規模なネットワーク用の高性能ルータでも本発明を実施できるが、特に処理能力が比較的低いルータで本発明の実施によるメリットが大きくなる。上記のコンテンツ表示用端末１０とは、有線ＬＡＮ又は無線ＬＡＮにより相互に通信する。

上記規制対象ＤＢサーバ３０は、各々のコンテンツ表示用端末１０からの接続要求を遮断すべき規制対象ページとなるアドレスを記録した規制ＵＲＬ一覧を、規制対象ＵＲＬデータベース３２として保有するサーバである。多数のＵＲＬフィルタリング装置２０と通信しうるものであり、複数の端末が一つの規制対象ＤＢサーバ３０を共有する。具体的には、セキュリティベンダーが運用する公開サーバや、プロバイダが利用者に対して提供するサーバ、企業内で共有するサーバなど、運用形態は特に限定されない。ただし、上記埋込ＵＲＬサーバ４０と同じネットワーク内にあり互いに高速に通信できる環境にあると、後述する第二の実施形態での運用がしやすくなる。なお、この規制対象ＵＲＬは、リクエストがされた上記コンテンツ表示用端末１０及び上記ＵＲＬフィルタリング装置２０ごとに切り替えられるものでもよい。

上記埋込ＵＲＬサーバ４０は、上記ＵＲＬフィルタリング装置２０からのリクエスト頻度をカウントする問合頻度データベース４２を有する。また、リクエスト頻度の高いＵＲＬについて、リクエストの処理とは別にバッチ処理にて当該ＵＲＬのコンテンツサーバ５０からダウンロードされるドキュメントを解析して埋め込まれた画像等の埋込ＵＲＬを解析しておき保有する埋込ＵＲＬデータベース４３を有する。すなわち、通常のリクエスト処理と、定期的なバッチ処理とを行う機能を有する。

上記コンテンツサーバ５０は、主にインターネットなどの外部ネットワーク上にあり、ＨＴＴＰアクセスを受け付けてＨＴＭＬ文書などのファイルをダウンロードさせることが可能なサーバである。図では一つのみ記載しているが、実際には多数のサーバがネットワークで繋がったものであり、個々のサーバ及びドキュメントはＵＲＬによって指定される。このうちの一部のアドレスによってダウンロードされるファイルが上記の規制対象に該当し、そのアドレスが上記規制ＵＲＬ一覧に登録されている。

上記のフィルタリングシステムが実行するフィルタリング方法を、図２〜４のフローチャートに従って説明する。図２及び図３は利用者のコンテンツ表示用端末１０のブラウザ処理部１１から通常のリクエストがされた際の処理を示すフローであり、図４は定期的に上記埋込ＵＲＬサーバ４０が実行するバッチ処理を示すフローである。

まず、図２のフローを説明する（Ｓ１００）。利用者が操作するコンテンツ表示用端末１０において、ブラウザ処理部１１に対して所定の接続先ＵＲＬを指定してコンテンツを要求するブラウザ操作を行い（Ｓ１０１）、接続要求を送信する（Ｓ１０２）。この接続要求は、直接に接続先ＵＲＬが示すコンテンツサーバ５０へ到達するのではなく、プロキシサーバであるＵＲＬフィルタリング装置２０の中継代理サーバ部２１へ送られる（Ｓ１０２）。中継代理サーバ部２１は、この接続要求を受信すると、そのままコンテンツサーバ５０へ中継するのではなく、同じくＵＲＬフィルタリング装置２０が有するＵＲＬ評価部２２へ送って接続の可否を問い合わせる要求問合機能６０を実行する（Ｓ１０３）。なお、中継代理サーバ部２１及びＵＲＬ評価部２２は、ＵＲＬフィルタリング装置２０内にハードウェアとして実装されていてもよいし、ソフトウェアとして実装されていてもよい。それぞれが別の半導体回路である場合は、上記の要求問合機能６０の実行は半導体間の送信指示となる。ソフトウェアで実装されている場合は、ＵＲＬフィルタリング装置２０が有する記憶メモリ（図示せず。）内で、ＵＲＬ評価部２２として動作するソフトウェアに上記の接続要求のＵＲＬを受け渡すこととなる。

上記の問い合わせを受けたＵＲＬ評価部２２は、まず、ＵＲＬ接続可否キャッシュ２３に当該接続要求の接続先ＵＲＬについて、その接続先ＵＲＬへの接続の可否が記録されているか否かを検索する高速返答機能６８を実行する（Ｓ１０４）。このＵＲＬ接続可否キャッシュ２３のレコードの例を図５（ａ）に示す。ＵＲＬと、そのＵＲＬへの接続が規制されているか否かを記録したレコードからなる。この記録は後述する処理（Ｓ１３８）による。記録があれば、ＵＲＬフィルタリング装置２０は他にリクエスト等を送るまでもなく対処を決定する。すなわち、その接続先ＵＲＬへの接続が「可」であるとの記録があれば（Ｓ１０５→Ｓ１０６）、中継代理サーバ部２１はプロキシサーバとして、接続先ＵＲＬから指定されたドキュメントのダウンロードを要求する中継機能６１を実行し（Ｓ１５３）、ダウンロードされたドキュメントをコンテンツ表示用端末１０に中継送信する（Ｓ１５４）。一方、その接続先ＵＲＬへの接続が「否」であるとの記録があれば（Ｓ１０５→Ｓ１０７）、その接続要求を遮断する遮断機能６２を実行する。遮断するには単純に送信要求を破棄することでも可能だが、ここではその接続先ＵＲＬへの接続が規制されていることが外見上判別可能なドキュメント又は画像ファイルである接続規制ファイルを、本来指定されたドキュメント等の代わりにコンテンツ表示用端末１０に送信する（Ｓ１５２）。この高速返答機能６８は、後述するリクエスト頻度の高い一部のドキュメントに引き続いて読み込まれる画像ファイルなどの埋込ＵＲＬに対して実行される。

一方、高速返答機能６８の実行の結果（Ｓ１０４）、その接続先ＵＲＬへの接続の可否がＵＲＬ接続可否キャッシュ２３に記録されていなければ、ＵＲＬ評価部２２は、埋込ＵＲＬサーバ４０が有する埋込ＵＲＬデータベース管理部４１にその接続先ＵＲＬを含むリクエストを送信するリクエスト機能６３を実行する（Ｓ１１１）。

上記のリクエストを受信する埋込ＵＲＬサーバ４０の埋込ＵＲＬデータベース管理部４１は、埋込ＵＲＬサーバ４０の通常時において受信するリクエストを処理するハードウェア又はソフトウェアである。この埋込ＵＲＬデータベース管理部４１はまず、受信したリクエストに含まれる接続先ＵＲＬについて、問合頻度データベース４２に記録する頻度更新機能８１を実行する（Ｓ１１２）。問合頻度データベース４２の例を図５（ｂ）に示す。上記接続先ＵＲＬと、区切られた時期、及びその時期ごとのリクエスト回数とからなる。このとき、既に接続先ＵＲＬのレコードがあれば、現在実行中の時期に該当するレコードにそのリクエスト回数に＋１する。すなわち、問合頻度データベース４２は、接続先ＵＲＬとともに、その接続先ＵＲＬがリクエストされた回数をカウントするものである。なお、ここの頻度更新を行うＵＲＬは、その後に埋込ＵＲＬを解析するためのものであるため、ＨＴＭＬファイル、ＸＭＬファイルなどをダウンロードさせるアドレス以外は無意味となる。従って、アドレス末尾の拡張子がｊｐｇ、ｐｎｇ，ｇｉｆ、ｓｗｆ、ｍｐｇ、ｍｐ４などである画像、動画、音声ファイルについては問合頻度データベース４２への記録から除外しておくことが好ましい。

それと前後して、埋込ＵＲＬデータベース管理部４１は、埋込ＵＲＬサーバ４０内に設けたもう一つのデータベースである埋込ＵＲＬデータベース４３内を、その接続先ＵＲＬをキーとして検索する埋込ＵＲＬ検索機能８２を実行する（Ｓ１１３）。この埋込ＵＲＬデータベースの例を図５（ｃ）に示す。接続先ＵＲＬと、そのＵＲＬが示すドキュメントに埋め込まれた画像ファイルなどの複数の埋込ＵＲＬとを関連づけて記録している。なお、この埋込ＵＲＬデータベース４３への記録は後述するバッチ処理で行われる（Ｓ２１６）。埋込ＵＲＬデータベース４３内に、上記接続先ＵＲＬ及びその接続先ＵＲＬで指定されるドキュメントに埋め込まれた埋込ＵＲＬのレコードが存在したら（Ｓ１１４→Ｓ１１５）、その接続先ＵＲＬと上記埋込ＵＲＬとをまとめて、上記ＵＲＬフィルタリング装置２０のＵＲＬ評価部２２へ返答する埋込ＵＲＬ返答機能８３を実行する。すなわち、上記リクエストに対して、その場でドキュメントの解析作業を行うことなく、接続先ＵＲＬのドキュメントに含まれる画像等の埋込ＵＲＬを速やかに返答できる。この返答を受けたＵＲＬ評価部２２は、その接続先ＵＲＬと上記埋込ＵＲＬとのＵＲＬ集合を、規制対象ＤＢサーバ３０へ送り、それら全てへの接続の可否をまとめて問い合わせる一括可否問合機能６５を実行する（Ｓ１１６）。

上記の規制対象ＤＢサーバ３０は、規制対象ページとして接続を制限、禁止するアドレスの規制ＵＲＬ一覧を記録した規制対象ＵＲＬデータベース３２と、問い合わされたＵＲＬについて、規制対象ＵＲＬデータベース３２を検索し、そのＵＲＬへの接続の可否を調べる可否判断機能７１を実行する接続可否判断部３１とを有する。この規制対象ＵＲＬデータベース３２の例を図５（ｄ）に示す。規制対象となるＵＲＬが記録されてあり、ドメイン名やファイル名などで検索可能であると望ましい。この内容は、ユーザからの報告などによりサーバが自動的に更新するものであったり、サーバの運営者が独自に登録するものであったりしてよい。

この規制対象ＤＢサーバ３０への可否判断機能７１の実行手順は次の通りである（Ｓ１３１〜Ｓ１３７）。上記のＵＲＬ集合に含まれるＵＲＬのそれぞれについて、規制対象ＵＲＬデータベース３２を検索し（Ｓ１３２）、当該ＵＲＬが存在していれば接続可否一覧に当該ＵＲＬを接続「否」として登録する（Ｓ１３３→Ｓ１３４）。存在していなければ、接続可否一覧に接続「可」として登録する（Ｓ１３３→Ｓ１３５）。これを、一括して送られてきた全てのＵＲＬについて行う（Ｓ１３６→Ｓ１３１）。なお、この接続可否一覧とは、上記ＵＲＬ集合への一括処理にあたり、一時的にサーバのメモリ上に展開するテーブルで、それぞれのＵＲＬについて可否の項目を記録するものであり、ＵＲＬ評価部２２への返答後は消去するとよい。一括して問い合わせがあったＵＲＬの全てについて上記接続可否一覧の可否が確認できたら、接続可否判断部３１は可否判断返答機能７２を実行してその結果をまとめて返答する。

上記接続可否一覧を受信したＵＲＬ評価部２２は、その内容をＵＲＬ接続可否キャッシュ２３に書き込む第一キャッシュ機能６６を実行する（Ｓ１３８）。このＵＲＬ接続可否キャッシュの内容は、数秒から数分程度の時間が経過すると自動的に消去される一時記憶機能６９が実行されるように設定しておく。これは、一つの接続先ＵＲＬへの接続要求に引き続いて、それに引き続く埋め込まれた画像ファイルや動画ファイル、インラインフレームのＨＴＭＬファイルなどの上記埋込ＵＲＬについての接続要求がされるが、それらの接続要求に対して上記の高速返答機能６８が実行される間（Ｓ１０４，Ｓ１０５〜）だけ保持していれば、十分にネットワークへの問い合わせと通信量を削減できるからである。また、キャッシュが肥大化すると応答速度が低下してしまうため、サイズは最小限に留めておくことが望ましい。なお、保持している間に再度同じＵＲＬについて書き込みがあれば、その保持時間は延長するとよい。

続いてＵＲＬ評価部２２は、接続先ＵＲＬについての接続の可否を中継代理サーバ部２１に返答する通常返答機能６７を実行する。このとき、埋込ＵＲＬについての接続の可否は返答しない。これを受けた中継代理サーバ部２１は、接続先ＵＲＬへの接続が「否」であれば（Ｓ１５１→Ｓ１５２）、その接続要求を遮断する遮断機能６２を実行する。この遮断機能６２の内容は上記の通りである。一方、接続先ＵＲＬへの接続が「可」であれば、その接続要求をコンテンツサーバ５０へ中継して当該ドキュメントのダウンロードを要求する中継機能６１を実行する（Ｓ１５３，Ｓ１５４）。

一方、埋込ＵＲＬデータベース４３を検索しても（Ｓ１１３）、接続先ＵＲＬが記録されていなければ（Ｓ１１４）、埋込ＵＲＬデータベース管理部４１は、ＵＲＬ評価部２２に、ｎｕｌｌ又は接続先ＵＲＬのみを返答するゼロ返答機能８４を実行する（Ｓ１１８）。この返答を受けたＵＲＬ評価部２２は、接続先ＵＲＬのみについての接続の可否を、規制対象ＤＢサーバに問い合わせる単独可否問合機能６４を実行する（Ｓ１１９）。規制対象ＤＢサーバ３０の接続可否判断部３１は、上記の場合に問い合わせのあった接続先ＵＲＬについて、規制対象ＵＲＬデータベース３２を検索する可否判断機能７１を実行して（Ｓ１４１）、その結果をＵＲＬ評価部２２へ返答する可否判断返答機能７２を実行し（Ｓ１４２）、その接続先ＵＲＬについての接続の可否をＵＲＬ接続可否キャッシュ２３に書き込む第一キャッシュ機能６６を実行する（Ｓ１３８）。ここで接続先ＵＲＬをキャッシュに保存しておくことにより、接続直後にブラウザ処理部１１で「戻る」や「再読込」といった作業を行った際にも速やかに返答が可能となる。また、再読込を繰り返す所謂「Ｆ５アタック」がされても、問合頻度データベース４２へ無駄なカウントが送られるという事態を防止できる。ＵＲＬ評価部２２は、その返答結果に応じて（Ｓ１５１），中継機能６１を実行するか（Ｓ１５３、Ｓ１５４），遮断機能６２を実行するか（Ｓ１５２）のいずれかを行う。

以上が第一の実施形態において通常時に端末からのリクエストに対してフィルタリングシステムが行う処理手順である。そして、埋込ＵＲＬサーバ４０は、上記の手順で実行された頻度更新機能８１による問合頻度データベース４２のデータを元に次のバッチ処理を定期的に行うことで、上記の処理手順を円滑に行える環境を用意する。このバッチ処理は大量のＨＴＭＬファイルの解析を行うためサーバの処理能力を大いに必要とすることから、上記の通常のリクエストが少ない時間帯に自動的に行うように設定しておくとよく、例えば毎日未明などに行うと好ましい。この定期的に実行するよう設定したバッチ処理実行機能８６の手順を図４に沿って説明する。

まず（Ｓ２１１）、このバッチ処理を統括するデータベース更新部４５が、問合頻度データベース４２を検索し、直近のリクエスト頻度の高かったＵＲＬ群を抽出する頻度読出機能８７を実行する。例えば、頻度のカウント数の上位何万件分かのＵＲＬ群を抽出するということである。このカウント数はバッチ処理の度にリセットするか、または図５（ｂ）のように、バッチ処理後にあらたな時期としてカウントし直すことが好ましく、できるだけ直近の一時期、又は限定された数の時期に亘っての問い合わせが多いＵＲＬ群を抽出することが好ましい。過去にカウント数が多くても現在問い合わせが少ないＵＲＬについて処理していたのでは、効率が悪いからである。ただし、リクエスト回数が曜日ごとの周期やさらに長い周期を持って変動していたりする場合もあるため、過去の一定期間の時期のログを残しておき、次に予想される頻度に最適化してＵＲＬ群を読み出してもよい。

この抽出したＵＲＬ群をコンテンツ解析部４４に送り、それらのＵＲＬが示すドキュメントに埋め込まれた埋込ＵＲＬを全て解析して埋込ＵＲＬデータベース４３に記録し直す事前解析機能８５を実行する（Ｓ２１３〜Ｓ２１７）。なお、埋め込まれた埋込ＵＲＬとは例えば、ＨＴＭＬのｉｍｇタグやＥｍｂｅｄタグ、ｉｆｒａｍｅタグなど、ドキュメントの読み込み時に同時に表示されるタグのＵＲＬである。なお、多くの場合はａタグによるリンク先を含めると、問合頻度データベースへのカウントが正しくされないので、除外する方が望ましい。リンク先への接続要求はどれが指定されるかわからず、先読みを行おうとすると数が多くなりすぎる場合があるためである。また、接続先ＵＲＬからダウンロード可能となるアーカイブを含めてもよい。具体的には次の手順を前記のＵＲＬ群を構成する全てのＵＲＬについて行う。

まず、コンテンツ解析部４４は、当該ＵＲＬがアドレスとして示すコンテンツサーバ５０へドキュメントのダウンロードを要求して受信する（Ｓ２１４）。受信したＨＴＭＬファイルやＸＭＬファイルの中身を解析して、ブラウザでそのドキュメントを表示させた際に読み込まれることになる埋込ＵＲＬを抽出する（Ｓ２１５）。ここで、単にＨＴＭＬファイルやＸＭＬファイルに直接記載されているアドレスだけではなく、それらファイルがブラウザの表示時に読み込むＣＳＳ（ＣａｓｃａｄｉｎｇＳｔｙｌｅＳｈｅｅｔｓ）ファイルやＪＳ（ＪａｖａＳｃｒｉｐｔ）ファイルなどがさらに読み込むことになるファイルの埋込ＵＲＬまで解析するように設定しておくことが望ましい。

次いで、当該接続先ＵＲＬと、それから抽出した埋込ＵＲＬとを、埋込ＵＲＬデータベース４３へ登録する埋込ＵＲＬ記録機能８８を実行する（Ｓ２１６）。以上のダウンロード、解析抽出、登録を、抽出したＵＲＬ群全てに対して行う（Ｓ２１７→Ｓ２１３）。このバッチ処理によって、一部の問い合わせ頻度の高い接続先ＵＲＬについての埋込ＵＲＬのリストが用意され、上記の通常時におけるリクエストに対して埋込ＵＲＬ返答機能８３、一括可否問合機能６５、高速返答機能６８が実行できるようになり、高速なフィルタリング処理が可能となる。

もし、上記のバッチ処理で解析された後に、当該接続先ＵＲＬの内容が変更されて、埋め込まれているコンテンツの埋込ＵＲＬが変更された場合は、その新たに追加された埋込ＵＲＬについては高速返答機能６８によるフィルタリングはできない。しかし、その埋込ＵＲＬが規制対象に該当するか否かは規制対象ＵＲＬデータベース３２のデータと照らし合わされるので（Ｓ１０４→Ｓ１１１〜Ｓ１１４→Ｓ１１８）、解析とのタイムラグによって安全性が悪化することはない。

次に、この発明の第二の実施形態について説明する。その構成図を図６に、通常時のリクエストの処理フローを図７及び図８に示す。バッチ処理については第一の実施形態と同様である。また、通常時のリクエストについても基本的なフローは第一の実施形態と同じ部分が多いため、第一の実施形態からの変更点を中心に説明する。

具体的には、規制対象ＤＢサーバ３０へのアクセス経路を変更している。第一の実施形態ではＵＲＬ評価部２２との間で応答したが、第二の実施形態では埋込ＵＲＬサーバ４０の埋込ＵＲＬデータベース管理部４１との間で応答する。すなわち、フローの上では、Ｓ１１５及びＳ１１６、Ｓ１１８及びＳ１１９で一旦ＵＲＬ評価部２２が受信してから接続可否判断部３１へ問い合わせしていた部分を、Ｓ１２１，Ｓ１２２のように、埋込ＵＲＬデータベース管理部４１が接続可否判断部３１へ直接に問い合わせるように変更する。これにより、接続先ＵＲＬ及び埋込ＵＲＬやｎｕｌｌの結果とともに、それぞれへの接続の可否の判断結果もまとめてＵＲＬ評価部２２に戻ってくるため（Ｓ１３７ｂ，Ｓ１４２ａ）、ＵＲＬ評価部２２が行う処理が減り、ＵＲＬフィルタリング装置２０のＵＲＬ評価部２２にかかる負荷が軽減される。さらに、サーバ側だけで一連の処理をまとめて行えるため、埋込ＵＲＬサーバ４０と規制対象ＤＢサーバ３０との通信回線さえ高速であれば、より迅速な応答が可能になる。

上記のフローを実施するために必要な埋込ＵＲＬデータベース管理部４１の機能は次の通りとなる。上記接続先ＵＲＬについて上記埋込ＵＲＬデータベース４３への埋込ＵＲＬ検索機能８２を実行して（Ｓ１１３、Ｓ１１４）、見つかれば、埋込ＵＲＬを読み出し、接続先ＵＲＬと埋込ＵＲＬとのＵＲＬ集合について接続可否判断部３１へ問い合わせる直送一括可否問合機能９２を実行する（Ｓ１２１）。それらＵＲＬ集合についての接続の可否を接続可否判断部３１から受信したら（Ｓ１３７ａ）、それらをまとめてＵＲＬ評価部２２へ返答する一括返答機能９４を実行する（Ｓ１３７ｂ）。埋込ＵＲＬ検索機能８２を実行して見つからなければ、接続先ＵＲＬのみについて接続可否判断部３１へ問い合わせる直送単独可否問合機能９１を実行する（Ｓ１２２）。その接続先ＵＲＬについての接続の可否を接続可否判断部３１から受信したら（Ｓ１４１ａ）、その接続の可否をＵＲＬ評価部２２へ返答する単独返答機能９３を実行し（Ｓ１４２ａ）、その接続先ＵＲＬについての接続の可否をＵＲＬ接続可否キャッシュ２３に書き込む第二キャッシュ機能９５を実行する（Ｓ１３８）。

一方、規制対象ＤＢサーバ３０は、可否判断返答機能７２の返答先が埋込ＵＲＬデータベース管理部４１に変更となる。また、ＵＲＬ評価部２２は、第一の実施形態では有していた単独可否問合機能６４及び一括可否問合機能６５を実行しない。また、埋込ＵＲＬデータベース管理部４１から上記埋込ＵＲＬ及びそれへの接続の可否を受信した段階で、ＵＲＬ接続可否キャッシュ２３へ一時的な記録を書き込む第二キャッシュ機能９５を実行する（Ｓ１３８）。

さらに、この発明の第３の実施形態について説明する。その構成図を図９に示す。これは上記の第２の実施形態においてコンテンツ表示用端末１０に併設されていたＵＲＬフィルタリング装置２０の機能を、ＵＲＬフィルタリング部２０ａとして、コンテンツ表示用端末１０ａに内蔵させたものである。このＵＲＬフィルタリング部２０ａは、具体的には、ブラウザがＨＴＭＬレンダリング機能とは別に有する通信部に含まれるソフトウェアや、ブラウザとは別にパーソナルファイアウォールとしてコンテンツ表示用端末１０ａにインストールされるソフトウェアとなる。

この第３の実施形態のフローは、図７及び８と、図４とに示されるフローにおいて、ＵＲＬフィルタリング装置２０をＵＲＬフィルタリング部２０ａに置き換えたものとなる。ただし、ブラウザ処理部１１とＵＲＬフィルタリング部２０ａとのデータのやり取りは、ＬＡＮなどを経由せず、同一端末内でのデータの受け渡しとなる。

なお、第一の実施形態における図１に示すＵＲＬフィルタリング装置２０の機能を、ＵＲＬフィルタリング部２０ａとしてコンテンツ表示用端末１０ａに内蔵させる形態でも本発明は実施可能である。ただし、第一の実施形態（図１）のようにＵＲＬ評価部２２が一旦受信してから問い合わせるよりも、第三の実施形態（図５）のようにＵＲＬ評価部２２を経由することなく埋込ＵＲＬサーバ４０から規制対象ＤＢサーバ３０に問い合わせる方が、ＵＲＬフィルタリング部２０ａにかかる処理負荷は小さくなるため、コンテンツ表示用端末１０ａに内蔵させる際に必要なスペックもより小さくできる。

１０，１０ａコンテンツ表示用端末
１１ブラウザ処理部
２０ＵＲＬフィルタリング装置
２０ａＵＲＬフィルタリング部
２１中継代理サーバ部
２２ＵＲＬ評価部
２３ＵＲＬ接続可否キャッシュ
３０規制対象ＤＢサーバ
３１接続可否判断部
３２規制対象ＵＲＬデータベース
４０埋込ＵＲＬサーバ
４１埋込ＵＲＬデータベース管理部
４２問合頻度データベース
４３埋込ＵＲＬデータベース
４４コンテンツ解析部
４５データベース更新部
５０コンテンツサーバ
６０要求問合機能
６１中継機能
６２遮断機能
６３リクエスト機能
６４単独可否問合機能
６５一括可否問合機能
６６第一キャッシュ機能
６７通常返答機能
６８高速返答機能
６９一時記憶機能
７１可否判断機能
７２可否判断返答機能
８１頻度更新機能
８２埋込ＵＲＬ検索機能
８３埋込ＵＲＬ返答機能
８４ゼロ返答機能
８５事前解析機能
８６バッチ処理実行機能
８７頻度読出機能
８８埋込ＵＲＬ記録機能
９１直送単独可否問合機能
９２直送一括可否問合機能
９３単独返答機能
９４一括返答機能
９５第二キャッシュ機能

Claims

利用者が利用するコンテンツ表示用端末のブラウザ処理部から、コンテンツサーバに向けて接続要求が送信された際に、その接続要求先のアドレスが規制対象ページとして予め記録された規制ＵＲＬ一覧に該当する場合には、上記コンテンツ表示用端末に併設又は内蔵したＵＲＬフィルタリング部で遮断させる機能を有するＵＲＬフィルタリングシステムであって、
上記ＵＲＬフィルタリング部と、上記ＵＲＬフィルタリング部と相互に通信する、埋込ＵＲＬサーバ及び規制対象ＤＢサーバとからなり、
上記埋込ＵＲＬサーバは、通常時に受け付けるリクエストの処理と、定期的なバッチ処理とを別個に行うものであり、
通常時には、上記ＵＲＬフィルタリング部から上記接続要求の指定先である接続先ＵＲＬを含む上記リクエストを受け取って、上記接続先ＵＲＬを上記リクエストの回数とともに問合頻度データベースに記録する頻度更新機能を有し、
一方で、上記問合頻度データベースに記録された上記接続先ＵＲＬのうち直近のリクエスト頻度が高い一部のＵＲＬ群について、接続先ＵＲＬに対応するドキュメントをダウンロードして解析し、当該ドキュメントに埋め込まれた埋込ＵＲＬを、接続先ＵＲＬとともに埋込ＵＲＬデータベースに記録する定期的なバッチ処理を行うバッチ処理実行機能を有し、
上記バッチ処理後の通常時には、上記バッチ処理により上記埋込ＵＲＬデータベースに上記埋込ＵＲＬが記録された上記接続先ＵＲＬを含む上記ＵＲＬフィルタリング部からの上記リクエストに対しては、対応する上記埋込ＵＲＬを上記埋込ＵＲＬデータベースから呼び出して、該当ＵＲＬと上記埋込ＵＲＬを上記ＵＲＬフィルタリング部へ返答する埋込ＵＲＬ返答機能を有して、上記頻度更新機能とともに実行するものであり、
上記ＵＲＬフィルタリング部は、上記埋込ＵＲＬサーバから返答された接続先ＵＲＬとそれに対応した上記埋込ＵＲＬとについて、上記規制ＵＲＬ一覧を記録した上記規制対象ＤＢサーバに対して、一括して接続の可否を問い合わせ、その応答可否結果に従って接続先ＵＲＬと、それに引き続く上記埋込ＵＲＬへの接続要求を遮断するＵＲＬフィルタリングシステム。
上記ＵＲＬフィルタリング部は、ＵＲＬ接続可否キャッシュと、中継代理サーバ部と、ＵＲＬ評価部とを有し、
上記ＵＲＬ接続可否キャッシュは、上記接続先ＵＲＬに埋め込まれた上記埋込ＵＲＬについての接続の可否を、（少なくともそれら一連のＵＲＬへの接続要求が完了し得る）制限時間付きで一時記憶する一時記憶機能を有し、
上記中継代理サーバ部は、上記接続要求を受信して、上記ＵＲＬ評価部へ問い合わせを送信する要求問合機能と、上記接続の可否の結果を受信してその結果に従い上記接続要求に対する遮断を行う遮断機能とを有し、
上記ＵＲＬ評価部は、上記問い合わせを受けて上記埋込ＵＲＬサーバへ上記リクエストを送信するリクエスト機能と、上記埋込ＵＲＬサーバから上記埋込ＵＲＬの無い返答を受信した場合には接続先ＵＲＬのみへの接続の可否を上記規制対象ＤＢサーバへ問い合わせる単独可否問合機能と、上記埋込ＵＲＬサーバから上記埋込ＵＲＬを受信した場合には上記規制対象ＤＢサーバへ上記接続の可否を問い合わせる一括可否問合機能と、前記一括可否問合機能の返答である上記埋込ＵＲＬの接続の可否を上記ＵＲＬ接続可否キャッシュへ書き込む第一キャッシュ機能と、接続先ＵＲＬへの接続の可否の結果を上記中継代理サーバ部へ返答する通常返答機能と、上記接続要求からの問い合わせに対し接続先ＵＲＬについて上記ＵＲＬ接続可否キャッシュを検索して予め記録された上記埋込ＵＲＬに該当すれば上記リクエストを送信することなくその可否を上記中継代理サーバ部へ返答する高速返答機能とを有する、
請求項１に記載のＵＲＬフィルタリングシステム。
上記埋込ＵＲＬサーバは、通常時のリクエストを処理する埋込ＵＲＬデータベース管理部と、定期的な上記バッチ処理を実行するデータベース更新部と、上記バッチ処理の際に解析を行うコンテンツ解析部と、上記埋込ＵＲＬデータベースと、上記問合頻度データベースとを有し、
上記データベース更新部は、上記ＵＲＬ群を上記問合頻度データベースから読み出して上記コンテンツ解析部に送る頻度読出機能と、上記埋込ＵＲＬデータベースに上記ＵＲＬ群とともにそれらそれぞれに対応する上記埋込ＵＲＬを記録する埋込ＵＲＬ記録機能を有し、
上記コンテンツ解析部は、上記ＵＲＬ群を構成するＵＲＬのそれぞれに対応するドキュメントを、接続先ＵＲＬが示すコンテンツサーバからダウンロードして解析し、そのドキュメントに埋め込まれた埋込ＵＲＬを求める事前解析機能を有し、
上記埋込ＵＲＬデータベース管理部は、上記ＵＲＬフィルタリング部からの上記リクエストを受け取り接続先ＵＲＬを問い合わせの回数とともに上記問合頻度データベースに記録する上記頻度更新機能と、上記リクエストに含まれる接続先ＵＲＬについて上記埋込ＵＲＬデータベースを検索し、該当すれば接続先ＵＲＬに対応する上記埋込ＵＲＬを呼び出す埋込ＵＲＬ検索機能と、上記埋込ＵＲＬ及び前記検索で該当があれば上記埋込ＵＲＬを上記ＵＲＬ評価部へ返答する上記埋込ＵＲＬ返答機能とを有する、
請求項１又は２に記載のＵＲＬフィルタリングシステム。
利用者が利用するコンテンツ表示用端末のブラウザ処理部から、コンテンツサーバに向けて接続要求が送信された際に、その接続要求先のアドレスが規制対象ページとして予め記録された規制ＵＲＬ一覧に該当する場合には、上記コンテンツ表示用端末に併設又は内蔵されたＵＲＬフィルタリング部で遮断させる機能を有するＵＲＬフィルタリングシステムであって、
上記ＵＲＬフィルタリング部と、上記ＵＲＬフィルタリング部と相互に通信する埋込ＵＲＬサーバと、埋込ＵＲＬサーバと通信する規制対象ＤＢサーバとからなり、
上記埋込ＵＲＬサーバは、通常時に受け付けるリクエストの処理と、定期的なバッチ処理とを別個に行うものであり、
通常時には、上記ＵＲＬフィルタリング部から上記接続要求の指定先である接続先ＵＲＬを含むリクエストを受け取って、上記接続先ＵＲＬを上記リクエストの回数とともに問合頻度データベースに記録する頻度更新機能を有し、
一方で、上記問合頻度データベースに記録された直近のリクエスト頻度が高い一部のＵＲＬ群について、接続先ＵＲＬに対応するドキュメントをダウンロードして解析し、当該ドキュメントに埋め込まれた埋込ＵＲＬを、接続先ＵＲＬとともに埋込ＵＲＬデータベースに記録する定期的なバッチ処理を行うバッチ処理実行機能を有し、
上記バッチ処理後の通常時には、上記バッチ処理により上記埋込ＵＲＬデータベースに上記埋込ＵＲＬが記録された上記接続先ＵＲＬを含む上記ＵＲＬフィルタリング部からの上記リクエストに対しては、対応する上記埋込ＵＲＬを上記埋込ＵＲＬデータベースから呼び出し、接続先ＵＲＬとそれに対応した上記埋込ＵＲＬとについて、上記規制ＵＲＬ一覧を記録した上記規制対象ＤＢサーバに対し、一括して接続の可否を問い合わせた上で、その結果を上記ＵＲＬフィルタリング部へ返答する一括返答機能を有し、上記頻度更新機能とともに実行するものであり、
上記ＵＲＬフィルタリング部は、その返答結果に従って接続先ＵＲＬとそれに引き続く上記埋込ＵＲＬへの接続要求を遮断するＵＲＬフィルタリングシステム。
上記ＵＲＬフィルタリング部は、ＵＲＬ接続可否キャッシュと、中継代理サーバ部と、ＵＲＬ評価部とを有し、
上記ＵＲＬ接続可否キャッシュは、上記接続先ＵＲＬに埋め込まれた上記埋込ＵＲＬについての接続の可否を制限時間付きで一時記憶する一時記憶機能を有し、
上記中継代理サーバ部は、上記接続要求を受信して、上記ＵＲＬ評価部へ問い合わせを送信する要求問合機能と、上記接続の可否の結果を受信してその結果に従い上記接続要求に対する遮断を行う遮断機能とを有し、
上記ＵＲＬ評価部は、上記問い合わせを受けて上記埋込ＵＲＬサーバへ上記リクエストを送信するリクエスト機能と、上記埋込ＵＲＬサーバから上記埋込ＵＲＬとその接続の可否とを含む返答を受信した場合には上記埋込ＵＲＬの接続の可否を上記ＵＲＬ接続可否キャッシュへ書き込む第二キャッシュ機能と、上記埋込ＵＲＬデータベース管理部から受信した接続先ＵＲＬへの接続の可否の結果を上記中継代理サーバ部へ返答する通常返答機能と、上記接続要求からの問い合わせに対し接続先ＵＲＬについて上記ＵＲＬ接続可否キャッシュを検索して予め記録された上記埋込ＵＲＬに該当すれば上記リクエストを送信することなくその可否を上記中継代理サーバ部へ返答する高速返答機能とを有し、
上記埋込ＵＲＬサーバは、通常時のリクエストを処理する埋込ＵＲＬデータベース管理部と、定期的な上記バッチ処理を実行するデータベース更新部と、上記バッチ処理の際に解析を行うコンテンツ解析部と、上記埋込ＵＲＬデータベースと、上記問合頻度データベースとを有し、
上記データベース更新部は、上記ＵＲＬ群を上記問合頻度データベースから読み出して上記コンテンツ解析部に送る頻度読出機能と、上記埋込ＵＲＬデータベースに上記ＵＲＬ群とともにそれらそれぞれに対応する上記埋込ＵＲＬを記録する埋込ＵＲＬ記録機能を有し、
上記コンテンツ解析部は、上記ＵＲＬ群を構成するＵＲＬのそれぞれに対応するドキュメントを、接続先ＵＲＬが示すコンテンツサーバからダウンロードして解析し、そのドキュメントに埋め込まれた埋込ＵＲＬを求める事前解析機能を有し、
上記埋込ＵＲＬデータベース管理部は、上記ＵＲＬフィルタリング部からの上記リクエストを受け取り接続先ＵＲＬを問い合わせの回数とともに上記問合頻度データベースに記録する上記頻度更新機能と、上記リクエストに含まれる接続先ＵＲＬについて上記埋込ＵＲＬデータベースを検索し、該当すれば接続先ＵＲＬに対応する上記埋込ＵＲＬを呼び出す埋込ＵＲＬ検索機能と、上記埋込ＵＲＬ及び前記検索で該当があれば上記埋込ＵＲＬを上記規制対象ＤＢサーバの接続可否判断部へ送信してそれらの接続の可否を受信する直送一括可否問合機能と、前記接続の可否を一括して上記フィルタリング部の上記ＵＲＬ評価部へ返答する一括返答機能を実行する、
請求項４に記載のＵＲＬフィルタリングシステム。
利用者が利用するコンテンツ表示用端末のブラウザ処理部から、コンテンツサーバに向けて接続要求が送信された際に、その接続要求先のアドレスが規制対象ページとして予め記録された規制ＵＲＬ一覧に該当する場合には、上記コンテンツ表示用端末に併設又は内蔵されたＵＲＬフィルタリング部で遮断させるＵＲＬフィルタリング方法であって、
ＵＲＬフィルタリング部とネットワークで繋がった埋込ＵＲＬサーバ及び規制対象ＤＢサーバを用い、
通常時には、上記ＵＲＬフィルタリング部からの接続要求の指定先である接続先ＵＲＬを含むリクエストを埋込ＵＲＬサーバで受信し、上記埋込ＵＲＬサーバに、上記接続先ＵＲＬをリクエストの回数とともに上記埋込ＵＲＬサーバが有する問合頻度データベースに予め記録させる頻度更新機能を実行させ、
一方で、上記埋込ＵＲＬサーバに、上記問合頻度データベースに記録された直近のリクエスト頻度が高い一部のＵＲＬ群について、接続先ＵＲＬに対応するドキュメントをダウンロードして解析し、当該ドキュメントに埋め込まれた埋込ＵＲＬを、接続先ＵＲＬとともに埋込ＵＲＬデータベースに記録する定期的なバッチ処理を行うバッチ処理実行機能を実行させ、
上記バッチ処理後の通常時には、上記埋込ＵＲＬサーバに、上記バッチ処理により上記埋込ＵＲＬデータベースに上記埋込ＵＲＬが記録された上記接続先ＵＲＬを含む上記ＵＲＬフィルタリング部からの上記リクエストに対して、対応する上記埋込ＵＲＬを上記埋込ＵＲＬデータベースから呼び出して、該当ＵＲＬと上記埋込ＵＲＬを上記ＵＲＬフィルタリング部へ返答する埋込ＵＲＬ返答機能を、上記頻度更新機能とともに実行させ、
上記ＵＲＬフィルタリング部に、上記埋込ＵＲＬサーバから返答された接続先ＵＲＬとそれに対応した上記埋込ＵＲＬとについて、上記規制ＵＲＬ一覧を記録した上記規制対象ＤＢサーバに対して、一括して接続の可否を問い合わさせ、その応答可否結果に従って接続先ＵＲＬと、それに引き続く上記埋込ＵＲＬへの接続要求を遮断させるＵＲＬフィルタリング方法。