(57)【特許請求の範囲】
【請求項１】
ウェブサイトのＵＲＬ及びそのＵＲＬに対するカテゴリを格納する第１格納手段と、
指定されたＵＲＬに対するカテゴリの判定要求をサーバ判定の要求として受け付けると、前記第１格納手段を用いて判定を行った結果を前記サーバ判定の要求元に対して応答するサーバ判定手段と、
前記第１格納手段が格納する全体のレコードの一部に当たる定期的に配信されるレコードを格納する第２格納手段と、
指定されたＵＲＬに対するカテゴリの判定要求をローカル判定の要求として受け付けると、前記第２格納手段を用いて判定を試み、カテゴリを判定することができた場合は判定されたカテゴリを前記ローカル判定の要求元に対して応答する一方、カテゴリを判定することができなかった場合は前記ＵＲＬを指定して前記サーバ判定手段に前記サーバ判定を要求し、前記サーバ判定手段により判定されたカテゴリを前記ローカル判定の要求元に対して応答するローカル判定手段と、
ユーザ端末によりウェブサイトへのアクセス要求がなされると、そのウェブサイトのＵＲＬを指定して前記ローカル判定手段に前記ローカル判定を要求し、前記ローカル判定手段により応答されたカテゴリに応じて前記アクセス要求を許可するか否かを制御するアクセス制御手段と、
を備えたウェブフィルタリングシステム。
【請求項２】
請求項１に記載のウェブフィルタリングシステムにおいて、
前記第１格納手段及び前記第２格納手段は、
いずれも前記ウェブサイトのＵＲＬに対し付与されたフラグを格納しており、前記フラグには、前記ウェブサイトのＵＲＬに関連するＵＲＬを持つ他のレコードの存在に関わる値が格納されていることを特徴とするウェブフィルタリングシステム。
【請求項３】
請求項２に記載のウェブフィルタリングシステムにおいて、
前記サーバ判定手段は、
前記ローカル判定手段が要求した前記サーバ判定に対する応答として、前記指定されたＵＲＬに少なくとも前方一致したＵＲＬであるマッチＵＲＬ及び前記マッチＵＲＬに対するカテゴリを含む結果データを送信し、前記指定されたＵＲＬに対するカテゴリの判定基準としたＵＲＬに対しフラグが付与されており所定条件が満たされる場合は、前記フラグを前記マッチＵＲＬに対するフラグとして前記結果データに含めることを特徴とするウェブフィルタリングシステム。
【請求項４】
請求項１から３のいずれかに記載のウェブフィルタリングシステムにおいて、
前記ローカル判定手段が要求した前記サーバ判定に対する応答として前記サーバ判定手段から送信された結果データを一時的に蓄える一時格納手段をさらに備え、
前記ローカル判定手段は、
前記ローカル判定の要求を受け付けると、先ず前記一時格納手段を用いて判定を試み、カテゴリを判定することができた場合は判定されたカテゴリを前記ローカル判定の要求元に対して応答し、カテゴリを判定することができなかった場合は、前記第２格納手段を用いて判定を試みることを特徴とするウェブフィルタリングシステム。
【請求項５】
請求項１から４のいずれかに記載のウェブフィルタリングシステムにおいて、
前記第１格納手段に格納されるデータを配信する第１配信手段と、
前記第２格納手段に格納されるデータを配信する第２配信手段と
をさらに備えたウェブフィルタリングシステム。
【請求項６】
請求項１から５のいずれかに記載のウェブフィルタリングシステムにおいて、
前記第１格納手段に格納されるデータ及び前記第２格納手段に格納されるデータを作成する作成手段
をさらに備えたウェブフィルタリングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブサイトに対するアクセスの許可又は不許可を制御するウェブフィルタリングシステムに関する。
【背景技術】
【０００２】
ユーザ端末によるインターネットのアクセスにおいて、ギャンブル、薬物や成人向けのコンテンツが公開されているサイトや出会い系サイトのように利用環境によっては閲覧を禁止すべきサイトや、フィッシングサイトやマルウェアが仕掛けられたサイトのような有害なサイト等へのアクセスを禁止し、規制対象とするサイトへの接続を制限するために、従来ウェブフィルタリング技術が利用されている。【０００３】
例えば、ユーザ（管理者または使用者）の意図によりなされた特定のＵＲＬに関するアクセスの禁止又は許可の設定をユーザ端末内に記憶し、記憶されている設定に基づいてリクエストされた入力ＵＲＬに対するアクセス制御をユーザ端末側で行う装置が知られている（例えば、特許文献１を参照）。また、ユーザ端末とウェブサイトとをネットワークを介して中継するサーバに、ウェブサイトのフィルタリング機能を装備させた装置が開示されている（例えば、特許文献２を参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１１−２０５３８０号公報
【特許文献２】特開２００７−２４９７２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
前者の先行技術によれば、ユーザ端末の利用が特定目的に限定されている環境であれば、特定のＵＲＬに対するアクセスのみを許可又は禁止する制御を行うことができると考えられる。しかしながら、インターネット上に存在するウェブサイトの数はあまりにも膨大である上に、危険性の高いウェブサイトはフィルタリングによる規制を回避するためにＵＲＬが変更されるケースも少なくないため、規制対象とするＵＲＬの管理負荷は非常に高く、これをユーザに任せるのは現実的ではない。【０００６】
また、後者の先行技術によれば、ウェブサイトのＵＲＬやそのコンテンツに含まれる文字列情報等、ウェブサイトに関する情報はサーバ上に蓄積されており、この情報に各ユーザによるフィルタリング情報（ウェブサイトへの許可／不許可を判断する基準となる情報）を掛け合わせて、アクセス要求を受けたウェブサイトへのアクセス許可／不許可が判断されるため、ユーザは許可／不許可の対象とするＵＲＬを管理する必要はなく、簡便にフィルタリングを実現することができると考えられる。しかしながら、頻繁に利用され安全であることが判っているウェブサイトにアクセスする場合であっても必ず外部のフィルタリングサーバへの問い合わせが発生するため、処理効率の面で問題がある。【０００７】
そこで、本発明は、ユーザ端末によるウェブサイトへのアクセスの許可／不許可の制御を効率よく実行することができる技術の提供を課題とする。
【課題を解決するための手段】
【０００８】
上記の課題を解決するため、本発明は以下のウェブフィルタリングシステムを提供する。なお、以下の括弧書中の文言はあくまで例示であり、本発明はこれに限定されるものではない。【０００９】
ウェブフィルタリングシステムは、インターネットを通じてアクセスが可能な多数のウェブサイトについて、そのＵＲＬやこれに対応するカテゴリを第１格納手段と第２格納手段に分散して格納する。このうち、第１格納手段はインターネット上のウェブサイト全体のＵＲＬ及びカテゴリを網羅的に格納するが、第２格納手段は第１格納手段が格納する全体のレコードの一部を格納する。レコードの分散は、指定されたＵＲＬに対するカテゴリの判定要求をローカル判定手段とサーバ判定手段とで分担して行うことを可能とする。すなわち、指定されたＵＲＬに対するカテゴリの判定要求を先にローカル判定の要求として受け付け、そこで第２格納手段を用いて判定を試みた結果、カテゴリを判定できた場合はカテゴリの判定結果を要求元に対して応答する。一方、第２格納手段のレコード内容を用いて判定できなかった場合はサーバ判定手段に対してサーバ判定を要求し、返ってきた結果をローカル判定の要求元に対して応答する。アクセス制御手段は、ユーザ端末によりウェブサイトへのアクセス要求が生じた際は、そのウェブサイトのＵＲＬを指定してローカル判定を要求し、（ローカル判定手段又はサーバ判定手段のどちらで判定されたかに関係なく）返ってきた結果（ＵＲＬに対応するカテゴリ）に応じてアクセス要求を許可するか否かを制御する。【００１０】
インターネット上のウェブサイトに対するアクセスの許可／不許可を制御する際には、ウェブサイトに関するＵＲＬやカテゴリ等のデータを蓄積したデータベースが必要とされる。ウェブサイトの数は日々増え続けているため、これに伴いアクセス制御に用いられるデータベースのサイズも肥大化の一途を辿っている。【００１１】
このようなデータベース、すなわちウェブサイトに関するデータの全レコードをクライアント側（ユーザ環境）に配置してアクセス制御を行った場合、クライアント側のコンピュータの記憶領域及びメモリを大量に消費することとなる。クライアント側のコンピュータのスペックによっては、全レコードを処理し切れず、アクセス制御を正常に行うことができない場合もありうる。また、このように肥大化したデータベースを更新するに際しても、やはりクライアント側のリソースに対する過負荷は避けられない。そうかと言って、このデータベースをサーバ側（ユーザ環境の外側）に配置してアクセス制御を行った場合、クライアント側はウェブサイトへのアクセス要求が発生する度に毎回サーバ側に問い合わせを行わなければならず、その結果、サーバ側とクライアント側との間で通信量が増え、アクセス制御に要する応答時間の長期化につながる。【００１２】
これに対し、ウェブフィルタリングシステムにおいては、ウェブサイトへのアクセス要求が発生すると、そのウェブサイトのＵＲＬに対するカテゴリの判定が先ずクライアント側（ローカル）で第２格納手段を用いて試みられる。そして、ここでカテゴリを判定することができなかった場合は、カテゴリの判定がサーバ側で第１格納手段を用いて実行される。したがって、ウェブフィルタリングシステムによれば、サーバ側とクライアント側との間の通信量を最小限に抑制することができ、結果として、ウェブサイトへのアクセス要求に対する制御に要する応答時間を短縮することが可能となる。【００１３】
また、ウェブフィルタリングシステムにおいては、サーバ側で実行されるカテゴリ判定においては第１格納手段が用いられ、クライアント側で実行されるカテゴリ判定においては第２格納手段が用いられる。第２格納手段は、第１格納手段が格納する全レコードの一部のみを格納している。したがって、ウェブフィルタリングシステムによれば、クライアント側のリソースに対して過負荷を与えることなくウェブサイトに対するアクセスを制御することができる。このように、この態様のウェブフィルタリングシステムによれば、ウェブサイトに対するアクセスの許可／不許可の制御を効率よく実行することができる。【００１４】
好ましくは、ウェブフィルタリングシステムでは、第１格納手段と第２格納手段とが、いずれもウェブサイトのＵＲＬに対し付与された各種のフラグを格納している。これらのフラグには、ウェブサイトのＵＲＬに関連するＵＲＬを持つ他のレコードの存在に関わる値がセットされている。【００１５】
ウェブサイトのＵＲＬは、それぞれ階層構造を有したドメイン部とパス部を含んでいる。ここで、ドメイン部の階層構造とは、最上位ドメイン（親ドメイン）を起点とした子ドメイン、孫ドメイン‥と連なる構造のことである。また、パス部の階層構造とは、最上位パス（ルート、親ディレクトリ）を起点とした子ディレクトリ、孫ディレクトリ‥と連なる構造のことである。ウェブサイトの構成はサイトによって様々であり、同じサイト内に配置されたコンテンツであっても、必ずしも同じカテゴリに属するとは限らない。例えば、上位階層のパスと下位階層のパスとが異なるカテゴリに属する場合も少なくない。このような場合において、データベースに格納されているＵＲＬのうち、アクセス要求がなされたウェブサイトのＵＲＬに部分一致するＵＲＬを網羅的にマッチングさせるとした場合、対象となるレコード件数が多いため処理の効率が悪く、アクセス要求に対する応答時間が長期化しやすい。【００１６】
これに対しこの態様のウェブフィルタリングシステムにおいては、第１格納手段及び第２格納手段は、ＵＲＬ及びカテゴリに加えて、関連するＵＲＬを持つ他のレコードの存在に関する値がセットされた各種のフラグを格納しており、サーバ側、クライアント側でのカテゴリ判定は、これらのフラグを用いて実行される。したがって、この態様のウェブフィルタリングシステムによれば、フラグを格納していないデータベースを用いてカテゴリ判定を実行する場合と比較して、マッチング処理の効率を向上させることができ、ウェブサイトに対するアクセスの許可／不許可の制御をさらに効率よく実行することができる。【００１７】
好ましくは、ウェブフィルタリングシステムでは、サーバ判定手段は、ローカル判定手段が要求したサーバ判定に対する応答として、マッチＵＲＬとマッチＵＲＬに対するカテゴリとを含む結果データを送信する。マッチＵＲＬとは、サーバ判定で指定されたＵＲＬに完全一致又は前方一致したＵＲＬのことである。サーバ判定手段は、指定されたＵＲＬに対するカテゴリの判定基準としたＵＲＬに対しフラグが付与されていて、かつ、所定条件が満たされる場合（すなわち、判定基準としたＵＲＬに対し付与されていたフラグをマッチＵＲＬにも継承させる必要があると判断された場合）、そのフラグをマッチＵＲＬに対するフラグとして含めた結果データを送信する。【００１８】
この態様のウェブフィルタリングシステムによれば、カテゴリの判定基準としたＵＲＬに対しフラグが付与されていても、マッチＵＲＬに継承させる必要がないと判断された場合には、このフラグは結果データには含まれない（結果データから削除される）。したがって、この態様のウェブフィルタリングシステムによれば、不要なフラグを結果データから除外して送信することができ、結果データを利用したマッチング処理におけるヒット率を向上させることが可能となる。したがって、ウェブサイトに対するアクセスの許可／不許可の制御をより効率よく実行することができる。【００１９】
より好ましくは、ウェブフィルタリングシステムは、ローカル判定手段が要求したサーバ判定に対する応答としてサーバ判定手段から送信された結果データを一時的に蓄える一時格納手段をさらに備えている。ローカル判定手段は、ローカル判定の要求を受け付けると、先ず一時格納手段を用いて判定を試みる。これによりカテゴリを判定することができた場合、ローカル判定手段はここで判定されたカテゴリを要求元に対して応答する。一方、これによりカテゴリを判定することができなかった場合、ローカル判定手段は、次に第２格納手段を用いて判定を試みる。【００２０】
上述したように、ウェブフィルタリングシステムにおいては、ウェブサイトへのアクセス要求が発生すると、そのウェブサイトのＵＲＬに対するカテゴリの判定を先ずクライアント側（ローカル）で第２格納手段を用いて試み、ここでカテゴリを判定できなかった場合はサーバ側で第１格納手段を用いて判定が実行される。【００２１】
第２格納手段を用いて試みられたカテゴリ判定においてＵＲＬに対するカテゴリを判定することができなかったということは、第２格納手段がカテゴリ判定を行うための十分なデータを有していなかったことを意味する。そのため、再び同じウェブサイトへのアクセス要求がなされると、クライアント側で実行するカテゴリ判定に用いるデータが前回の判定時と同一、すなわち第２格納手段のみである場合には、今回も前回と同様にローカル判定ではカテゴリを判定することができず、サーバ判定を要求しなければならない。【００２２】
これに対し、この態様のウェブフィルタリングシステムは、サーバ判定の要求に対する応答として送信された結果データを一時的に蓄える一時格納手段を備えており、クライアント側で実行されるカテゴリ判定には、第２格納手段に加えて一時格納手段が用いられる。そして、ウェブサイトへのアクセス要求が発生すると、クライアント側では、そのウェブサイトのＵＲＬに対するカテゴリの判定を、先ず一時格納手段を用いて試み、ここでカテゴリを判定することができなかった場合は、次に第２格納手段を用いて試み、それでもカテゴリを判定することができなかった場合は、サーバ側で第１格納手段を用いて判定が実行される。【００２３】
したがって、この態様のウェブフィルタリングシステムによれば、サーバ判定が実行されたＵＲＬに対する結果データを一時格納手段が格納している間に同じＵＲＬに対して再びアクセス要求がなされた場合、サーバ判定を要求することなくローカル判定のみでカテゴリを判定することができる。よって、サーバ側とクライアント側との間の通信量をさらに減らすことができ、ウェブサイトに対するアクセスの許可／不許可の制御を一層効率よく実行することができる。【００２４】
さらに好ましくは、ウェブフィルタリングシステムでは、一時格納手段は、サーバ判定手段から結果データとして送信されたマッチＵＲＬ、マッチＵＲＬに対するカテゴリ及びフラグを格納している。【００２５】
この態様のウェブフィルタリングシステムによれば、一時格納手段を用いたカテゴリ判定がフラグを用いて実行されるため、フラグを格納していない一時格納手段を用いてカテゴリ判定を実行する場合と比較して、マッチング処理の効率を向上させることができる。したがって、ウェブサイトに対するアクセスの許可／不許可の制御をより一層効率よく実行することができる。【００２６】
好ましくは、ウェブフィルタリングシステムは、第１格納手段に格納されるデータを配信する第１配信手段と、第２格納手段に格納されるデータを配信する第２配信手段と、第１格納手段に格納されるデータ及び第２格納手段に格納されるデータを作成する作成手段とをさらに備えている。【００２７】
この態様のウェブフィルタリングシステムによれば、第１格納手段に格納されるデータ及び第２格納手段に格納されるデータがネットワークを介して配信されるため、サーバ判定及びローカル判定において用いられるデータベースのデータ更新を容易に行うことができる。このことは、ウェブサイトに対するアクセスの許可／不許可の制御の効率化に貢献する。
【発明の効果】
【００２８】
本発明によれば、ユーザ端末によるウェブサイトへのアクセスの許可／不許可の制御を効率よく実行することができる。
【図面の簡単な説明】
【００２９】
【図１】ウェブフィルタリングシステムが動作する環境の構成図である。
【図２】ウェブフィルタリングシステムにおけるデータの流れを表す模式図である。
【図３】ウェブフィルタリングシステムに関わる各データベースの相対的な規模を表す模式図である。
【図４】ウェブフィルタリングシステムの機能ブロック図（１／２）である。
【図５】ウェブフィルタリングシステムの機能ブロック図（２／２）である。
【図６】フルＤＢ作成処理の手順例を示すフローチャートである。
【図７】部分ＤＢ作成処理の手順例を示すフローチャートである。
【図８】クライアント側で実行されるカテゴリ判定処理の手順例を示すフローチャートである。
【図９】サーバ側で実行されるカテゴリ判定処理の手順例を示すフローチャートである。
【図１０】各データベースに格納されるレコードの一例を示す表である。
【図１１】各入力ＵＲＬが指定された場合にサーバ側でのカテゴリ判定処理が必要であるか否かをまとめた表である。
【図１２】番号１，２の入力ＵＲＬが指定された場合のウェブフィルタリングシステムの動作例を示すシーケンス図である。
【図１３】番号３の入力ＵＲＬが指定された場合のウェブフィルタリングシステムの動作例を示すシーケンス図である。
【図１４】フラグ「ＨＡＳ＿ＬＥＦＴ」を用いたカテゴリ判定処理を説明する図である。
【図１５】フラグ「ＨＡＳ＿ＲＩＧＨＴ」を用いたカテゴリ判定処理を説明する図である。
【図１６】第２実施形態のウェブフィルタリングシステムが動作する環境の構成図である。
【図１７】第２実施形態のウェブフィルタリングシステムにおけるデータの流れを表す模式図である。
【発明を実施するための形態】
【００３０】
以下、本発明の実施形態について、図面を参照しながら説明する。なお、以下の実施形態は好ましい例示であり、本発明はこの例示に限定されるものではない。
【００３１】
〔第１実施形態〕
図１は、一実施形態におけるウェブフィルタリングシステム１００が動作する環境の構成図である。ウェブフィルタリングシステム１００は、例えばインターネット等のネットワークに接続されたコンピュータ環境に適用することができる。
【００３２】
この図に示されるように、ウェブフィルタリングシステム１００は、サーバ側（バックエンド、フロントエンド）及びクライアント側（ユーザ環境）に配置された各機能により構成される。バックエンドには、ウェブフィルタリングシステム１００で使用されるルックアップデータの作成及び配信を担うサーバコンピュータ、すなわちＤＢ（データベース）サーバ１０、作成サーバ２０、第１配信サーバ３０及び第２配信サーバ４０が配置される。ＤＢサーバ１０は、インターネット上のウェブサイトに関する情報を蓄積したデータベースを管理／提供する。作成サーバ２０は、ＤＢサーバ１０に蓄積されている情報に基づいて配信用に２種類のデータベースを作成する。第１配信サーバ３０は、作成サーバ２０が作成したデータベースのうち一方をルックアップサーバ５０に配信する。第２配信サーバ４０は、他方のデータベースをルックアップクライアント７０に配信する。
【００３３】
ところで、配信用のデータベースは、ウェブサイトに関するＵＲＬやカテゴリ等の情報で構成されている。「カテゴリ」とは、各ＵＲＬに対して付与される分類であり、ウェブサイトの内容に応じて付与される。本実施形態では、約数百個のカテゴリが定義されており、例えば、娯楽、スポーツ、アダルトやマルウェア等のカテゴリが存在する。
【００３４】
フロントエンド（クラウド）には、ルックアップサーバ５０が配置されている。ルックアップサーバ５０は、サーバ側で動作するルックアップ（以下、「サーバルックアップ」と称する。）の機能を有したサーバコンピュータである。ここで「ルックアップ」とは、マッチング処理により特定のＵＲＬに対する情報をデータベースから取得する処理のことをいう。ルックアップサーバ５０は、例えば、ウェブフィルタリングシステム１００のユーザである企業や学校等が使用するクラウドサーバや、ウェブフィルタリングシステム１００の提供者がユーザである企業や学校等を対象として提供するクラウドサーバが該当する。ルックアップサーバ５０は、ルックアップクライアント７０からの要求に基づいてサーバルックアップを実行し、その結果をルックアップクライアント７０に応答する。
【００３５】
ユーザ環境には、ルックアップクライアント７０が配置されている。ルックアップクライアント７０には、ネットワークを介してユーザ端末９０が接続されている。ルックアップクライアント７０は、クライアント側で動作するルックアップ（以下、「ローカルルックアップ」と称する。）の機能を有したサーバコンピュータであり、ユーザ端末９０によるウェブサイトへのアクセスを許可するか否かを制御する。ルックアップクライアント７０は、例えば、ウェブフィルタリングシステム１００のユーザである企業や学校等においてファイアウォールの内側に配置されユーザ端末９０とインターネット上のウェブサイトとの間の通信を中継するルータやプロキシサーバ等が該当する。
【００３６】
ユーザ端末９０は、ユーザがウェブサイトにアクセスする際に使用するコンピュータであり、一般的なブラウジング機能を有している。ユーザ端末９０には、例えば、コンピュータ、スマートフォンやタブレットＰＣ等のモバイルデバイスが該当する。
【００３７】
ユーザ端末９０がウェブブラウザ等を介してウェブサイトにアクセスしようとすると、ルックアップクライアント７０は、このアクセス要求を検出して、先ずローカルルックアップを実行し、必要に応じてルックアップサーバ５０に対してサーバルックアップを要求する。ルックアップクライアント７０は、ルックアップの実行結果に基づいて、ユーザ端末９０によるウェブサイトへのアクセスを許可するか否かを制御する。以下の説明においては、アクセス要求がなされたウェブサイトのＵＲＬを「入力ＵＲＬ」と称する。
【００３８】
なお、各サーバコンピュータ１０，２０，３０，４０，５０，７０が有する機能や、入力ＵＲＬに対するカテゴリの判定に関する処理の具体的な流れについては、別の図を参照しながら詳しく後述する。
【００３９】
図２は、一実施形態のウェブフィルタリングシステム１００におけるデータの流れを表す模式図である。なお、図中の白抜き矢印は、データベースの流れを示しており、黒矢印は、データベース以外のデータの流れを示している。
【００４０】
ＤＢサーバ１０は、インターネット上のウェブサイトに関する情報を蓄積したマスタＤＢ１２を管理／提供している。作成サーバ２０は、ネットワーク等を介してＤＢサーバ１０と相互に接続可能であり、マスタＤＢ１２に格納されたデータを読み出し、これらのデータに基づいて、２種類のデータベース、すなわち第１配信ＤＢ２４及び第２配信ＤＢ２６を作成する。第１配信ＤＢ２４は、ルックアップサーバ５０で実行されるサーバルックアップにおいて用いられ、第２配信ＤＢ２６は、ルックアップクライアント７０で実行されるローカルルックアップにおいて用いられる。
【００４１】
作成サーバ２０はまた、ネットワーク等を介して第１配信サーバ３０及び第２配信サーバ４０とも相互に接続可能である。作成サーバ２０は、第１配信ＤＢ２４を複製した第１配信ＤＢ２４ｃを第１配信サーバ３０に転送し、第２配信ＤＢ２６を複製した第２配信ＤＢ２６ｃを第２配信サーバ４０に転送する。
【００４２】
第１配信サーバ３０は、ネットワーク等を介してルックアップサーバ５０と相互に接続可能であり、ルックアップサーバ５０からの要求に基づいて、第１配信ＤＢ２４ｃをルックアップサーバ５０に配信する。
【００４３】
第２配信サーバ４０は、インターネット６０を介してルックアップクライアント７０と相互に接続可能であり、ルックアップクライアント７０からの要求に基づいて、第２配信ＤＢ２６ｃをルックアップクライアント７０に配信する。
【００４４】
ルックアップサーバ５０は、インターネット６０を介してルックアップクライアント７０と相互に接続可能である。ルックアップサーバ５０は、ルックアップクライアント７０からの要求を受け付けると、この要求と共に送信された入力ＵＲＬに基づいて第１配信ＤＢ２４ｃを用いてサーバルックアップを実行し、その結果として得られたカテゴリ及びその他の付随情報をルックアップクライアント７０に送信する。
【００４５】
ルックアップクライアント７０は、インターネット６０に接続可能である。ユーザ端末９０によるウェブサイトへのアクセス要求が発生すると、ルックアップクライアント７０は、先ず第２配信ＤＢ２６ｃ及びキャッシュＤＢ８０を用いてローカルルックアップを実行し、入力ＵＲＬに対するカテゴリの確定を試みる。キャッシュＤＢ８０は、ルックアップサーバ５０から送信された結果データを一時的に格納するデータベースである。ローカルルックアップによりカテゴリが確定された場合は、ルックアップクライアント７０は確定されたカテゴリに基づいてウェブサイトへのアクセスを許可するか否かを制御する。これに対し、ローカルルックアップによりカテゴリが確定されなかった場合は、ルックアップクライアント７０はルックアップサーバ５０に対してサーバルックアップを要求し、この要求に対するルックアップサーバ５０からの応答結果に基づいて、ウェブサイトへのアクセスを許可するか否かを制御する。
【００４６】
図３は、ウェブフィルタリングシステム１００に関わる各データベースの相対的な規模を表す模式図である。図３中には、ウェブフィルタリングシステム１００に関わる４つのデータベースがそれぞれ大きさの異なる円柱で描かれている。これらの大きさの違いは、各データベースの規模の違いを視覚的に表現したものである。円柱の直径は、各データベースに登録されているＵＲＬ（以下、「登録ＵＲＬ」と称する。）に関連付けられたデータの項目数、すなわちデータベース内のフィールド数に相当する。また、円柱の高さは、登録ＵＲＬをキーとしたデータ件数、すなわちデータベース内のレコード数に相当する。
【００４７】
図３中（Ａ）：マスタＤＢ１２は、インターネット上のウェブサイトに関する詳細な情報を蓄積したデータベースである。マスタＤＢ１２には、例えば、登録ＵＲＬ、プロトコル、ポート、ドメイン階層、パス階層、サイト内でヒットしたキーワード、カテゴリ、データ登録日、データ更新日、アクセスログ等をはじめとする多くのデータ項目が格納されている。
【００４８】
図３中（Ｂ）：第１配信ＤＢ２４，２４ｃは、マスタＤＢ１２に格納されているデータ項目のうち、サーバルックアップに必要となるデータ項目のみを抜き出し、かつ入力ＵＲＬに対するカテゴリを確定する過程で用いられる各種のフラグを付与して作成される。また、第１配信ＤＢ２４，２４ｃは、マスタＤＢ１２に格納されている一部のレコード（例えば、配信対象外のカテゴリに該当するレコードやノイズレコード）を除外して作成される。つまり、第１配信ＤＢ２４，２４ｃは、格納される登録ＵＲＬのデータ件数においてはマスタＤＢ１２のデータ件数よりやや少なく、格納されるデータ項目数においてはマスタＤＢ１２のデータ項目数よりも少ない。第１配信ＤＢ２４，２４ｃには、例えば、登録ＵＲＬ，カテゴリ、フラグ等のデータ項目が格納されている。第１配信ＤＢ２４，２４ｃは、例えば４〜５ＧＢを超えるデータサイズに達する。
【００４９】
図３中（Ｃ）：第２配信ＤＢ２６，２６ｃは、ローカルルックアップに必要となるデータ項目で構成されており、第１配信ＤＢ２４，２４ｃと同一の構造を有している。第２配信ＤＢ２６，２６ｃは、ルックアップクライアント７０でのルックアップに用いられるため、データ件数は、必要十分な量に抑制されている。つまり、第２配信ＤＢ２６，２６ｃは、格納されるデータ項目数においては第１配信ＤＢ２４，２４ｃのデータ項目数と同一であるが、格納されるデータ件数においては第１配信ＤＢ２４，２４ｃのデータ件数よりも少ない。第２配信ＤＢ２６，２６ｃには、第１配信ＤＢ２４，２４ｃに格納される全データのうち、所定の基準に従って抽出された一部（例えば全体の約１割）のデータが格納される。
【００５０】
このように、第２配信ＤＢ２６，２６ｃに格納されるデータは、第１配信ＤＢ２４，２４ｃに格納される全データ（フルデータ）の一部をなす部分データである。そこで、以下の説明においては、第１配信ＤＢ２４，２４ｃをフルＤＢ２４，２４ｃと称するとともに、第２配信ＤＢ２６，２６ｃを部分ＤＢ２６，２６ｃと称することとする。
【００５１】
図３中（Ｄ）：キャッシュＤＢ８０は、ルックアップサーバ５０から送信されたサーバルックアップの結果データを一時的に格納するデータベースであり、例えば、ルックアップクライアント７０の内部記憶領域に記憶される。ルックアップサーバ５０から送信される結果データは、マッチＵＲＬ、カテゴリ及びフラグの３つのデータ項目で構成される。ルックアップクライアント７０は、入力ＵＲＬに対するカテゴリがローカルルックアップにより確定されなかった場合に、ルックアップサーバ５０に対してサーバルックアップを要求するが、この要求に対する応答として送信された結果データに基づいてキャッシュＤＢ８０を更新する。キャッシュＤＢ８０が格納するデータ項目は、マッチＵＲＬ、カテゴリ及びフラグの３項目の他に、キャッシュＤＢ８０の更新制御に用いられる項目を含んでいる。そのため、キャッシュＤＢ８０に格納されるデータ項目数は、フルＤＢ２４，２４ｃ及び部分ＤＢ２６，２６ｃのデータ項目数よりやや多い。
【００５２】
ところで、「マッチＵＲＬ」とは、登録ＵＲＬと入力ＵＲＬとを比較してマッチした部分までのＵＲＬのことである。例えば、入力ＵＲＬが「ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔ．ｃｏｍ／ａ／」であり、サーバルックアップで参照されるフルＤＢ２４ｃに登録ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔ．ｃｏｍ／ａ／ｂｃｄ」が格納されている場合、マッチＵＲＬとして「ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔ．ｃｏｍ／ａ／」が返される。ルックアップサーバ５０は、マッチＵＲＬを登録ＵＲＬとして、マッチＵＲＬとともに返されたカテゴリ及び各種のフラグとともに、キャッシュＤＢ８０に格納する。これらのデータがキャッシュＤＢ８０に格納されている間に同じウェブサイトに対するアクセス要求が再び発生した場合、ルックアップクライアント７０は、キャッシュＤＢ８０を用いてローカルルックアップのみで入力ＵＲＬに対するカテゴリを確定させることができ、ルックアップサーバ５０に対するサーバルックアップの要求は不要となる。したがって、ルックアップクライアント７０は、ルックアップに伴うルックアップサーバ５０との間の通信量を最小限に抑制し、効率よくアクセス制御を行うことが可能となる。
【００５３】
キャッシュＤＢ８０は、ルックアップクライアント７０の起動時には全ての格納データがクリアされて空の状態となるが、サーバルックアップの結果データが蓄積されることによりデータ量が増えていく。また、キャッシュＤＢ８０のデータサイズはユーザ環境（企業や学校等）毎の要件に応じて上限（例えば１００ＭＢ）が設けられている。キャッシュＤＢ８０のデータサイズが上限を超えると、所定のルールに基づいてキャッシュＤＢ８０に格納されているデータがクリアされ、空き領域が確保される。
【００５４】
なお、図３中に表された４つのデータベース（Ａ）〜（Ｄ）の大きさは、規模の違いを直感的に把握できるようにすることのみを目的として表現されており、各データベースの実際の規模の正確な相対比を表してはいない。例えば、図３中（Ｃ）の部分ＤＢ２６，２６ｃは、図３中（Ｂ）のフルＤＢ２４，２４ｃの３割程度の高さで表現されているが、部分ＤＢ２６，２６ｃに格納されるデータ件数は、フルＤＢ２４，２４ｃに格納されるデータ件数の１割程度である。
【００５５】
図４及び図５は、ウェブフィルタリングシステム１００の機能ブロック図である。ウェブフィルタリングシステム１００は、サーバ側（サーバコンピュータ２０，３０，４０，５０）とクライアント側（サーバコンピュータ７０）とに跨って構成されている。
【００５６】
図４は、ウェブフィルタリングシステム１００がサーバ側に有する機能を示すブロック図である。この図に示されるように、ウェブフィルタリングシステム１００は、配信ＤＢ作成部２２、配信ＤＢ転送部２８、フルＤＢ配信部３２、部分ＤＢ配信部４２、配信要求部５２、フルデータ格納部５４、カテゴリ判定部５６及び要求応答部５８をサーバ側に有する。
【００５７】
作成サーバ２０、第１配信サーバ３０及び第２配信サーバ４０には、サーバルックアップ及びローカルルックアップで使用されるデータベースの作成及び配信に係る機能部２２，２８，３２，４２が実装される。
【００５８】
配信ＤＢ作成部２２は、ＤＢサーバ１０に実装されるマスタデータ格納部１２（マスタＤＢ１２）に格納されているデータに基づいて、配信用の２つのデータベース（フルＤＢ２４、部分ＤＢ２６）を作成する。
【００５９】
配信ＤＢ転送部２８は、配信ＤＢ作成部２２により作成されたデータベースの複製を配信サーバに転送する。具体的には、配信ＤＢ転送部２８は、フルＤＢ２４ｃを第１配信サーバ３０に転送し、部分ＤＢ２６ｃを第２配信サーバ４０に転送する。
【００６０】
フルＤＢ配信部３２は、ルックアップサーバ５０からの要求に応じてフルＤＢ２４ｃを配信する。
【００６１】
部分ＤＢ配信部４２は、ルックアップクライアント７０からの要求に応じて部分ＤＢ２６ｃを配信する。
【００６２】
ルックアップサーバ５０には、サーバルックアップを実行する上で必要とされる機能部５２，５４，５６，５８が実装される。
【００６３】
配信要求部５２は、第１配信サーバ３０に対しフルＤＢ２４ｃの配信を要求する。
【００６４】
フルデータ格納部５４は、第１配信サーバ３０から配信されたフルＤＢ２４ｃに相当する記憶領域であり、フルＤＢ２４ｃの全レコードを格納する。
【００６５】
カテゴリ判定部５６は、フルデータ格納部５４に格納されたデータを用いてサーバルックアップを実行することにより、入力ＵＲＬに対するカテゴリを判定する。
【００６６】
要求応答部５８は、ルックアップクライアント７０からの要求を受け付け、カテゴリ判定部５６による入力ＵＲＬに対するカテゴリ判定の結果をルックアップクライアント７０に対し応答する。
【００６７】
図５は、ウェブフィルタリングシステム１００がクライアント側に有する機能を示すブロック図である。この図に示されるように、ウェブフィルタリングシステム１００は、配信要求部７２、部分データ格納部７４、入力ＵＲＬ処理部７６、ローカル判定部７８、キャッシュデータ格納部８０、キャッシュデータ更新部８２、サーバ判定要求部８４及びアクセス制御設定部８６をクライアント側（ルックアップクライアント７０）に有する。
【００６８】
ルックアップクライアント７０には、ユーザ端末９０によるウェブサイトへのアクセスを許可するか否かを制御する上で必要とされる機能部７２，７４，７６，７８，８０，８２，８４，８６が実装される。
【００６９】
配信要求部７２は、第２配信サーバ４０に対し部分ＤＢ２６ｃの配信を要求する。
【００７０】
部分データ格納部７４は、第２配信サーバ４０から配信された部分ＤＢ２６ｃに相当する記憶領域であり、部分ＤＢ２６ｃの全レコードを格納する。
【００７１】
入力ＵＲＬ処理部７６は、ユーザ端末９０のウェブブラウザ９２によりウェブサイトへのアクセス要求がなされると、そのウェブサイトのＵＲＬ（入力ＵＲＬ）をローカル判定部７８に渡して入力ＵＲＬに対するカテゴリを取得し、さらにそのカテゴリのウェブサイトに対するアクセスの許可／不許可の設定をアクセス制御設定部８６から取得して、取得した設定に応じてウェブサイトへのアクセスを制御する。
【００７２】
ローカル判定部７８は、部分データ格納部７４及びキャッシュデータ８０に格納されたデータを用いてローカルルックアップを実行することにより、入力ＵＲＬに対するカテゴリの確定を試みる。ローカルルックアップによりカテゴリが確定されなかった場合は、ローカル判定部７８は、サーバ判定要求部８４を介してルックアップサーバ５０に対し、サーバルックアップによるカテゴリ判定を要求する。ローカル判定部７８は、最終的に確定された入力ＵＲＬに対するカテゴリを入力ＵＲＬ処理部７６に返す。
【００７３】
サーバ判定要求部８４は、ルックアップサーバ５０に対し、入力ＵＲＬを受け渡してこの入力ＵＲＬに対するカテゴリ判定を要求する。また、サーバ判定要求部８４は、ルックアップサーバ５０からカテゴリ判定の結果データを受け取り、結果データをキャッシュデータ更新部８２に渡すとともに、ルックアップサーバ５０でのカテゴリ判定により確定されたカテゴリをローカル判定部７８に返す。
【００７４】
キャッシュデータ格納部８０は、キャッシュＤＢ８０に相当する記憶領域であり、サーバルックアップによるカテゴリ判定の結果データを格納する。
【００７５】
キャッシュデータ更新部８２は、サーバ判定要求部８４から渡された結果データに基づいてキャッシュデータ格納部８０に格納されているデータを更新する。
【００７６】
アクセス制御設定部８６は、ウェブフィルタリングシステム１００で定義されている各カテゴリに対するユーザ設定、すなわちユーザ環境において各カテゴリに該当するウェブサイトへのアクセスを許可するか否かの設定を行うための画面を提供し、この設定画面を介してユーザ環境の管理者によりなされたアクセス制御設定を保存する。
【００７７】
ユーザ端末９０がウェブブラウザ９２を介してウェブサイトへのアクセス要求を行うと、ルックアップクライアント７０に実装されたこれらの機能部７２，７４，７６，７８，８０，８２，８４，８６が連係して、入力ＵＲＬに対するカテゴリを確定し、そのカテゴリに応じてアクセスを制御する。要求されたウェブサイトがアクセス許可のカテゴリに該当する場合は、ユーザ端末９０はウェブサイトへのアクセスが許可される。一方、要求されたウェブサイトがアクセス不許可のカテゴリに該当する場合は、ユーザ端末９０はウェブサイトへのアクセスが許可されない。このとき、ユーザ端末９０は入力ＵＲＬ処理部７６からアクセスが許可されない旨を示すメッセージを受け取り、メッセージをウェブブラウザ９２のブラウジング領域に表示する。この表示により、ユーザはウェブサイトへのアクセスが許可されなかった（ブロックされた）ことを認識することができる。
【００７８】
図６は、作成サーバ２０で実行されるフルＤＢ作成処理の手順例を示すフローチャートである。このフローチャートに示される各ステップは、ウェブフィルタリングシステム１００が作成サーバ２０上に有する機能部により実行されるが、各機能部を動作させる主体は作成サーバ２０のＣＰＵ２１である。以下、手順例に沿って説明する。
【００７９】
ステップＳ１００：ＣＰＵ２１は、配信ＤＢ作成部２２にマスタＤＢ読込処理を実行させる。この処理では、配信ＤＢ作成部２２は、マスタＤＢ１２に格納されている一部のレコード（例えば、配信対象外のカテゴリに該当するレコードやノイズレコード）を除いた全てのレコードに対する所定のデータフィールドを読み込み、ＲＡＭ２３上にロードする。
【００８０】
ステップＳ１１０：ＣＰＵ２１は、配信ＤＢ作成部２２にドメインパスツリー作成処理を実行させる。この処理では、配信ＤＢ作成部２２は、前ステップＳ１００でＲＡＭ２３上にロードしたデータを用いて各登録ＵＲＬを構成するドメイン部とパス部の階層をツリー構造化したデータを構築する。
【００８１】
ステップＳ１２０：ＣＰＵ２１は、配信ＤＢ作成部２２にフラグ付与処理を実行させる。この処理では、配信ＤＢ作成部２２は、前ステップＳ１１０で構築したツリー構造のデータを用いてドメイン単位で様々な判定（例えば、サブドメインの他の登録ＵＲＬの有無や、配下のパスにおける他の登録ＵＲＬの有無の判定）を行い、これらの判定結果に基づいて、各登録ＵＲＬに対し各種のフラグを付与する。
【００８２】
ステップＳ１４０：ＣＰＵ２１は、配信ＤＢ作成部２２にフルＤＢ出力処理を実行させる。この処理では、配信ＤＢ作成部２２は、前ステップＳ１２０でフラグを付与したツリー構造のデータを配信用のデータ形式に変換し、フルＤＢ２４として出力する。フルＤＢ２４は、例えばＨＤＤ２５上に出力される。
【００８３】
ステップＳ１５０：ＣＰＵ２１は、配信ＤＢ転送部２８にフルＤＢ転送処理を実行させる。この処理では、配信ＤＢ転送部２８は、前ステップＳ１４０で出力されたフルＤＢ２４の複製２４ｃを第１配信サーバ３０に転送する。
以上の手順を終えると、フルＤＢ作成処理が終了する。
【００８４】
図７は、作成サーバ２０で実行される部分ＤＢ作成処理の手順例を示すフローチャートである。このフローチャートに示される各ステップの動作主体は、図６のフルＤＢ作成処理と同様である。以下、手順例に沿って説明する。
【００８５】
ステップＳ２００：ＣＰＵ２１は、配信ＤＢ作成部２２にマスタＤＢ読込処理を実行させる。この処理では、配信ＤＢ作成部２２は、マスタＤＢ１２に格納されている一部のレコード（例えば、配信対象外のカテゴリに該当するレコードやノイズレコード）を除いた全てのレコードに対する所定のデータフィールドを読み込み、ＲＡＭ２３上にロードする。
【００８６】
ステップＳ２１０：ＣＰＵ２１は、配信ＤＢ作成部２２にドメインパスツリー作成処理を実行させる。この処理では、配信ＤＢ作成部２２は、前ステップＳ２００でＲＡＭ２３上にロードしたデータを用いて各登録ＵＲＬを構成するドメインとパスの階層をツリー構造化したデータを構築する。
【００８７】
ステップＳ２２０：ＣＰＵ２１は、配信ＤＢ作成部２２にフラグ付与処理を実行させる。この処理では、配信ＤＢ作成部２２は、前ステップＳ２１０で構築したツリー構造のデータを用いてドメイン単位で様々な判定（例えば、サブドメインの他の登録ＵＲＬの有無や、配下のパスにおける他の登録ＵＲＬの有無の判定）を行い、これらの判定結果に基づいて、各登録ＵＲＬに対し各種のフラグを付与する。
【００８８】
ステップＳ２３０：ＣＰＵ２１は、配信ＤＢ作成部２２に配信対象データ抽出処理を実行させる。この処理では、配信ＤＢ作成部２２は、前ステップＳ２２０でフラグを付与したツリー構造のデータから、配信対象とする一部のデータを所定の基準に従って抽出する。例えば、登録ＵＲＬのアクセス数の多い方から順に、かつ、フラグが付与されていないデータが優先的に扱われて、全体の一部をなす部分データが抽出される。
【００８９】
ステップＳ２４０：ＣＰＵ２１は、配信ＤＢ作成部２２に部分ＤＢ出力処理を実行させる。この処理では、配信ＤＢ作成部２２は、前ステップＳ２３０で抽出された部分データを配信用のデータ形式に変換し、部分ＤＢ２６として出力する。部分ＤＢ２６は、例えばＨＤＤ２５上に出力される。
【００９０】
ステップＳ２５０：ＣＰＵ２１は、配信ＤＢ転送部２８に部分ＤＢ転送処理を実行させる。この処理では、配信ＤＢ転送部２８は、前ステップＳ２４０で出力された部分ＤＢ２６の複製２６ｃを第２配信サーバ４０に転送する。
以上の手順を終えると、部分ＤＢ作成処理が終了する。
【００９１】
図８は、ルックアップクライアント７０で実行されるカテゴリ判定処理の手順例を示すフローチャートである。このフローチャートに示される各ステップは、ウェブフィルタリングシステム１００がルックアップクライアント７０上に有する機能部により実行されるが、各機能部を動作させる主体はルックアップクライアント７０のＣＰＵ７１である。以下、手順例に沿って説明する。
【００９２】
ステップＳ４００：ＣＰＵ７１は、入力ＵＲＬ処理部７６に入力ＵＲＬ取得処理を実行させる。この処理では、入力ＵＲＬ処理部７６は、ユーザ端末９０によりウェブブラウザ９２を介してなされたウェブサイトへのアクセス要求を伴う入力ＵＲＬを取得する。
【００９３】
ステップＳ４１０：ＣＰＵ７１は、ローカル判定部７８にキャッシュＤＢ検索処理を実行させる。この処理では、ローカル判定部７８は、前ステップＳ４００で取得された入力ＵＲＬを検索キーとしてキャッシュＤＢ８０を検索する（ローカルルックアップ）。
【００９４】
ステップＳ４２０：ＣＰＵ７１は、前ステップＳ４１０で実行した検索で登録ＵＲＬが入力ＵＲＬに一致するレコードがヒットしたか否かをローカル判定部７８に確認させる。レコードがヒットした場合（ステップＳ４２０：Ｙｅｓ）、ＣＰＵ７１は次にステップＳ４５０を実行する。一方、レコードがヒットしなかった場合（ステップＳ４２０：Ｎｏ）、ＣＰＵ７１は次にステップＳ４３０を実行する。
【００９５】
ステップＳ４３０：ＣＰＵ７１は、ローカル判定部７８に部分ＤＢ検索処理を実行させる。この処理では、ローカル判定部７８は、ステップＳ４００で取得された入力ＵＲＬを検索キーとして部分ＤＢ２６ｃを検索する（ローカルルックアップ）。
【００９６】
ステップＳ４４０：ＣＰＵ７１は、前ステップＳ４３０で実行した検索で登録ＵＲＬが入力ＵＲＬに一致するレコードがヒットしたか否かをローカル判定部７８に確認させる。レコードがヒットした場合（ステップＳ４４０：Ｙｅｓ）、ＣＰＵ７１は次にステップＳ４５０を実行する。一方、レコードがヒットしなかった場合（ステップＳ４４０：Ｎｏ）、ＣＰＵ７１は次にステップＳ４７０を実行する。
【００９７】
ステップＳ４５０：ＣＰＵ７１は、ローカル判定部７８にカテゴリ取得処理を実行させる。この処理では、ローカル判定部７８は、ステップＳ４１０又はステップＳ４３０で実行した検索でヒットしたレコードに対する登録ＵＲＬ、フラグ、カテゴリ等のデータに基づいて、入力ＵＲＬに対するカテゴリの確定を試みる。
【００９８】
ステップＳ４６０：ＣＰＵ７１は、前ステップＳ４５０の実行により入力ＵＲＬに対するカテゴリが確定したか否かをローカル判定部７８に確認させる。カテゴリが確定した場合（ステップＳ４６０：Ｙｅｓ）、ＣＰＵ７１は次にステップＳ５１０を実行する。一方、カテゴリが確定しなかった場合（ステップＳ４６０：Ｎｏ）、ＣＰＵ７１は次にステップＳ４７０を実行する。
【００９９】
ステップＳ４７０：ＣＰＵ７１は、サーバ判定要求部８４にサーバ判定要求処理を実行させる。この処理では、サーバ判定要求部８４は、ルックアップサーバ５０に入力ＵＲＬに対するカテゴリ判定の要求を送信する。
【０１００】
ステップＳ４８０：ＣＰＵ７１は、サーバ判定要求部８４にサーバ判定結果受信処理を実行させる。この処理では、サーバ判定要求部８４は、前ステップＳ４７０での要求に対する応答としてルックアップサーバ５０から送信されるカテゴリ判定の結果データを受信する。
【０１０１】
ステップＳ４９０：ＣＰＵ７１は、前ステップＳ４８０で受信した結果データにＵＲＬが含まれているか否かをローカル判定部７８に確認させる。結果データにＵＲＬが含まれている場合（ステップＳ４９０：Ｙｅｓ）、ＣＰＵ７１は次にステップＳ５００を実行する。一方、結果データにＵＲＬが含まれていない場合（ステップＳ４９０：Ｎｏ）、ＣＰＵ７１は次にステップＳ５１０を実行する。
【０１０２】
ステップＳ５００：ＣＰＵ７１は、キャッシュデータ更新部８２にキャッシュＤＢ更新処理を実行させる。この処理では、キャッシュデータ更新部８２は、ステップＳ４８０でサーバ判定要求部８４が受信した結果データに基づいて、キャッシュＤＢ８０のデータを更新する。
【０１０３】
ステップＳ５１０：ＣＰＵ７１は、ローカル判定部７８にカテゴリ出力処理を実行させる。この処理では、ローカル判定部７８は、入力ＵＲＬに対する確定したカテゴリを出力する。
以上の手順を終えると、クライアント側で実行されるカテゴリ判定処理が終了する。
【０１０４】
図９は、ルックアップサーバ５０で実行されるカテゴリ判定処理の手順例を示すフローチャートである。このフローチャートに示される各ステップは、ウェブフィルタリングシステム１００がルックアップサーバ５０上に有する機能部により実行されるが、各機能部を動作させる主体はルックアップサーバ５０のＣＰＵ５１である。以下、手順例に沿って説明する。
【０１０５】
ステップＳ３００：ＣＰＵ５１は、要求応答部５８に要求受信処理を実行させる。この処理では、要求応答部５８は、ルックアップクライアント７０から送信されたカテゴリ判定の要求を受信し、この要求と共に送信された入力ＵＲＬを取得する。
【０１０６】
ステップＳ３１０：ＣＰＵ５１は、カテゴリ判定部５６にフルＤＢ検索処理を実行させる。この処理では、カテゴリ判定部５６は、前ステップＳ３００で取得された入力ＵＲＬを検索キーとして、フルＤＢ２４ｃを検索する（サーバルックアップ）。
【０１０７】
ステップＳ３２０：ＣＰＵ５１は、前ステップＳ３１０で実行した検索で登録ＵＲＬが入力ＵＲＬに一致するレコードがヒットしたか否かをカテゴリ判定部５６に確認させる。レコードがヒットした場合（ステップＳ３２０：Ｙｅｓ）、ＣＰＵ５１は次にステップＳ３４０を実行する。一方、レコードがヒットしなかった場合（ステップＳ３２０：Ｎｏ）、ＣＰＵ５１は次にステップＳ３３０を実行する。
【０１０８】
ステップＳ３３０：ＣＰＵ５１は、カテゴリ判定部５６に不一致ＵＲＬを取得させる。ここで、「不一致ＵＲＬ」とは、登録ＵＲＬと入力ＵＲＬとを比較して得られるマッチＵＲＬに対し付与されたカテゴリ及び各種のフラグによって入力ＵＲＬに対するカテゴリが確定されなかった場合のマッチＵＲＬのことである。別の言い方をすると、不一致ＵＲＬとは、入力ＵＲＬが未分類カテゴリに該当すると判定された場合のマッチＵＲＬのことである。但し、カテゴリ判定部５６は、入力ＵＲＬのドメイン部が未登録である場合のマッチＵＲＬについては不一致ＵＲＬから除外する。
【０１０９】
ステップＳ３４０：ＣＰＵ５１は、カテゴリ判定部５６にマッチＵＲＬ、カテゴリ、フラグを取得させる。この処理では、カテゴリ判定部５６は、入力ＵＲＬがいずれかのカテゴリに該当すると判定された場合のマッチＵＲＬに加え、このマッチＵＲＬに対し付与されたカテゴリ及び各種のフラグを取得する。
【０１１０】
ステップＳ３５０：ＣＰＵ５１は、要求応答部５８に結果送信処理を実行させる。この処理では、要求応答部５８は、ステップＳ３３０又はステップＳ３４０で取得されたカテゴリ判定の結果データをルックアップクライアント７０に送信する。
以上の手順を終えると、サーバ側で実行されるカテゴリ判定処理が終了する。
【０１１１】
図１０は、ウェブフィルタリングシステム１００で使用される各データベース（フルＤＢ２４ｃ、部分ＤＢ２６ｃ、キャッシュＤＢ８０）に格納されているレコードの一例を示す表である。各表中の左のカラムには説明の便宜のために付した番号が示されており、左から２番目のカラムには登録ＵＲＬが示されており、右から２番目のカラムにはカテゴリＩＤが示されており、右のカラムにはフラグが示されている。
【０１１２】
ここでは、各データベースに格納されたレコードのうち、ドメイン「ｗｗｗ．ｔｅｓｔ．ｃｏｍ」に属するウェブサイトの登録ＵＲＬを有するレコードが例示されている。より具体的には、各表は、登録ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔ．ｃｏｍ／」と、「ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔ．ｃｏｍ／ａｄ」で始まる登録ＵＲＬと、「ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔ．ｃｏｍ／ｄｒ」で始まる登録ＵＲＬと有するレコードを含んでいる。
【０１１３】
図１０中（Ａ）：サーバルックアップで使用されるフルＤＢ２４ｃに格納されているレコードの一例として、番号１１〜１７の７件のレコードが示されている。番号１１は登録ＵＲＬのパス部がルート「／」であるレコードであり、番号１２，１３は登録ＵＲＬのパス部が「／ａｄ」で始まるレコードであり、番号１４〜１７は登録ＵＲＬのパス部が「／ｄｒ」で始まるレコードである。また、番号１１のレコードにはフラグ「ＨＡＳ＿ＲＩＧＨＴ」が付与されている。
【０１１４】
フラグ「ＨＡＳ＿ＲＩＧＨＴ」は、このフラグが付与されたレコードの登録ＵＲＬのパス部に前方一致しつつ、より長いパス部を登録ＵＲＬに有する他のレコードが格納されていることを示している。具体例についてはさらに後述する。また、フラグ「ＨＡＳ＿ＬＥＦＴ」は、このフラグが付与されたレコードの登録ＵＲＬのドメイン部を親ドメインとした登録ＵＲＬを有する他のレコードが格納されていることを示している。例えば、登録ＵＲＬ「ｈｔｔｐ：／／ｔｅｓｔ．ｃｏｍ／」を有するレコードがフルＤＢ２６ｃに格納されているとした場合、この登録ＵＲＬのドメイン部「ｔｅｓｔ．ｃｏｍ」は番号１１の登録ＵＲＬのドメイン部「ｗｗｗ．ｔｅｓｔ．ｃｏｍ」の親ドメインに当たるため、このレコードにはフラグ「ＨＡＳ＿ＬＥＦＴ」が付与されることとなる。ウェブフィルタリングシステム１００においては、これらの他にも様々な種類のフラグが用意されているが、ここでは説明を省略する。なお、フラグを用いたカテゴリ判定処理の具体例については、別の図を参照しながら詳しく後述する。
【０１１５】
このように、フルＤＢ２４ｃ及び部分ＤＢ２６ｃは、各種のフラグを用いたカテゴリ判定を行うことができるデータ構造で作成されている。したがって、ルックアップサーバ５０及びルックアップクライアント７０は、ルックアップの過程で登録ＵＲＬが入力ＵＲＬに部分一致する全てのレコードを網羅的にマッチングする必要がなく、効率よくマッチングを行うことができる。
【０１１６】
図１０中（Ｂ）：ローカルルックアップで使用される部分ＤＢ２６ｃに格納されているレコードの一例として、番号２１〜２４の４件のレコードが示されている。番号２１，２２，２３，２４の各レコードは、それぞれフルＤＢ２４ｃに含まれる番号１１，１２，１３，１７のレコードに一致し、部分ＤＢ２６ｃの登録レコードは全てフルＤＢ２４ｃに含まれている。これは、部分ＤＢ２６ｃがフルＤＢ２４ｃのサブセットであることを示している。
【０１１７】
図１０中（Ｃ）：ローカルルックアップで使用されるキャッシュＤＢ８０に格納されているレコードの一例として、２件のレコードが示されている。番号３１，３２の各レコードは、それぞれフルＤＢ２４ｃに含まれる番号１４，１５のレコードに一致する。キャッシュＤＢ８０に格納されているレコードは、いずれも部分ＤＢ２６ｃには含まれていない。これは、部分ＤＢ２６ｃでは入力ＵＲＬに対するカテゴリを確定できなかったためにサーバルックアップが行われ、その結果として返されたデータ、すなわち部分ＤＢ２６ｃには含まれないデータがキャッシュＤＢ８０に格納されていることを示している。
【０１１８】
図１１は、各入力ＵＲＬが指定された場合にサーバ側でのカテゴリ判定処理が必要とされるか否かをまとめた表である。表中の左のカラムには説明の便宜のために付した番号が示されており、左から２番目のカラムには入力ＵＲＬが示されている。左から３番目のカラムには、入力ＵＲＬに対するカテゴリの確定場所、すなわちいずれのデータベースのレコードに基づいてカテゴリが確定されたかが示されている。また、右から２番目のカラムには、カテゴリ判定処理の結果として図８中のステップＳ５１０で出力されるカテゴリＩＤが示されている。右のカラムにはサーバ側でのカテゴリ判定処理が必要であるか不要であるかが示されている。
【０１１９】
以下、各入力ＵＲＬに対するカテゴリが図１０に示された各データベースを用いてどのように確定されるのかを、１つずつ追って説明する。
【０１２０】
番号１の入力ＵＲＬは、パス部が「／ｄｒｉｖｅ／」である。登録ＵＲＬのパス部が「／ｄｒｉｖｅ／」であるレコードは、キャッシュＤＢ８０に格納されている（図１０中（Ｃ）の番号３２）。したがって、番号１の入力ＵＲＬに対するカテゴリはキャッシュＤＢ８０のレコードに基づいて確定され、カテゴリ判定処理の結果としてカテゴリＩＤ「１１２」が出力される。このように、番号１の入力ＵＲＬに対するカテゴリはローカルルックアップにより確定されるため、サーバ側でのカテゴリ判定処理は不要である。
【０１２１】
番号２の入力ＵＲＬは、パス部が「／ａｄｍｉｎ／」である。登録ＵＲＬのパス部が「／ａｄｍｉｎ／」であるレコードは、部分ＤＢ２６ｃに格納されている（図１０中（Ｂ）の番号２２）。したがって、番号２の入力ＵＲＬに対するカテゴリは部分ＤＢ２６ｃのレコードに基づいて確定され、カテゴリ判定処理の結果としてカテゴリＩＤ「１０１」が出力される。このように、番号２の入力ＵＲＬに対するカテゴリはローカルルックアップにより確定されるため、サーバ側でのカテゴリ判定処理は不要である。
【０１２２】
番号３の入力ＵＲＬは、パス部が「／ｄｒｏｎｅ／」である。登録ＵＲＬのパス部が「／ｄｒｏｎｅ／」であるレコードは、キャッシュＤＢ８０及び部分ＤＢ２６ｃには格納されていない。部分ＤＢ２６ｃには、パス部「／ｄｒｏｎｅ／」の親パスに当たるルート「／」を登録ＵＲＬのパス部に持つレコードが格納されているが（図１０中（Ｂ）の番号２１）、このレコードにはフラグ「ＨＡＳ＿ＲＩＧＨＴ」が付与されており、部分ＤＢ２６ｃに格納されたレコードだけでは入力ＵＲＬに対するカテゴリを確定することができない。これに対し、フルＤＢ２４ｃには登録ＵＲＬのパス部が「／ｄｒｏｎｅ／」であるレコードが格納されている（図１０中（Ａ）の番号１６）。したがって、番号３の入力ＵＲＬに対するカテゴリはフルＤＢ２４ｃのレコードに基づいて確定され、カテゴリ判定処理の結果としてカテゴリＩＤ「１１２」が出力される。このように、番号３の入力ＵＲＬに対するカテゴリはサーバルックアップにより確定されるため、サーバ側でのカテゴリ判定処理が必要である。
【０１２３】
番号４の入力ＵＲＬは、パス部が「／ｄｒｉｎｋ／」である。登録ＵＲＬのパス部が「／ｄｒｉｎｋ／」であるレコードは、キャッシュＤＢ８０及び部分ＤＢ２６ｃには格納されていない。部分ＤＢ２６ｃには、パス部「／ｄｒｉｎｋ／」の親パスに当たるルート「／」を登録ＵＲＬのパス部に持つレコードが格納されているが（図１０中（Ｂ）の番号２１）、このレコードにはフラグ「ＨＡＳ＿ＲＩＧＨＴ」が付与されており、部分ＤＢ２６ｃに格納されたレコードだけでは入力ＵＲＬに対するカテゴリを確定することができない。登録ＵＲＬのパス部が「／ｄｒｉｎｋ／」であるレコードは、フルＤＢ２４ｃにも格納されていないが、フルＤＢ２４ｃには全ての登録ＵＲＬが格納されているため、パス部「／ｄｒｉｎｋ／」の親パスに当たるルート「／」を登録ＵＲＬのパス部に持つレコード（図１０中（Ａ）の番号１１）と、このレコードに付与されているフラグ「ＨＡＳ＿ＲＩＧＨＴ」に基づく他の関連レコードを参照してカテゴリを判定することができる。これにより登録ＵＲＬに対するカテゴリが確定され、カテゴリ判定処理の結果としてこのレコードと同じカテゴリＩＤ「１００」が出力される。このように、番号４の入力ＵＲＬに対するカテゴリはサーバルックアップにより確定されるため、サーバ側でのカテゴリ判定処理が必要である。
【０１２４】
図１２は、図１１中の番号１，２の入力ＵＲＬが指定された場合のウェブフィルタリングシステム１００の動作例を示すシーケンス図である。コンピュータ間でパケットを送受信する際に事前に行われるプロトコルのネゴシエーションやセッション確立に相当するステップについては、一般的事項であるため記載を省略する。以下、動作例に沿って説明する。
【０１２５】
ステップＳ１０，Ｓ１２：ルックアップサーバ５０が第１配信サーバ３０にフルＤＢ２４ｃの配信を要求すると（Ｓ１０）、第１配信サーバ３０はフルＤＢ２４ｃをルックアップサーバ５０に配信する（Ｓ１２）。
ステップＳ２０，Ｓ２２：ルックアップクライアント７０が第２配信サーバ４０に部分ＤＢ２６ｃの配信を要求すると（Ｓ２０）、第２配信サーバ４０は部分ＤＢ２６ｃをルックアップクライアント７０に配信する（Ｓ２２）。
【０１２６】
このようにして、ルックアップサーバ５０はフルＤＢ２４ｃを第１配信サーバ３０から、またルックアップクライアント７０は部分ＤＢ２６ｃを第２配信サーバ４０から、それぞれ定期的にダウンロードする（例えば１日に３回）。ダウンロードのタイミングや周期は、ルックアップサーバ５０とルックアップクライアント７０とで異なる。
【０１２７】
ステップＳ３０：ユーザ端末９０がウェブブラウザ９２を介して図１１中の番号１の入力ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔ．ｃｏｍ／ｄｒｉｖｅ／」にアクセスしようとすると、ルックアップクライアント７０はこの入力ＵＲＬを取得する。
【０１２８】
ステップＳ３２〜Ｓ３６：ルックアップクライアント７０がキャッシュＤＢ８０を検索すると、登録ＵＲＬが入力ＵＲＬに一致するレコードがヒットし（Ｓ３２）、入力ＵＲＬに対するカテゴリ「１１２」が確定する（Ｓ３４）。ルックアップクライアント７０は、このカテゴリを出力し（Ｓ３６）、このカテゴリに対するユーザ設定に応じてユーザ端末９０によるウェブサイトへのアクセスを制御する。
【０１２９】
ステップＳ４０：しばらくして、ユーザ端末９０がウェブブラウザ９２を介して図１１中の番号２の入力ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔ．ｃｏｍ／ａｄｍｉｎ／」にアクセスしようとすると、ルックアップクライアント７０はこの入力ＵＲＬを取得する。
【０１３０】
ステップＳ４２〜Ｓ４８：ルックアップクライアント７０は、先ずキャッシュＤＢ８０を検索するが、登録ＵＲＬが入力ＵＲＬに一致するレコードがヒットしない（Ｓ４２）。そこでルックアップクライアント７０は、部分ＤＢ２６ｃを検索すると登録ＵＲＬが入力ＵＲＬに一致するレコードがヒットし（Ｓ４４）、入力ＵＲＬに対するカテゴリ「１０１」が確定する（Ｓ４６）。ルックアップクライアント７０は、このカテゴリを出力し（Ｓ４８）、このカテゴリに対するユーザ設定に応じてユーザ端末９０によるウェブサイトへのアクセスを制御する。
【０１３１】
このように、キャッシュＤＢ８０又は部分ＤＢ２６ｃに登録ＵＲＬが入力ＵＲＬに一致するレコードが含まれ、ローカルルックアップによりカテゴリが確定される場合、ルックアップクライアント７０とルックアップサーバ５０との間での通信は一切発生しない。
【０１３２】
図１３は、図１１中の番号３の入力ＵＲＬが指定された場合のウェブフィルタリングシステム１００の動作例を示すシーケンス図である。なお、事前に行われるデータベースのダウンロードに関する動作（ステップＳ１０，Ｓ１２，Ｓ２０，Ｓ２２）については、図１２中と同様であるため、説明を省略する。以下、動作例に沿って説明する。
【０１３３】
ステップＳ６０：ユーザ端末９０がウェブブラウザ９２を介して図１１中の番号３の入力ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｔｅｓｔ．ｃｏｍ／ｄｒｏｎｅ／」にアクセスしようとすると、ルックアップクライアント７０はこの入力ＵＲＬを取得する。
【０１３４】
ステップＳ６２〜Ｓ６６：ルックアップクライアント７０は、先ずキャッシュＤＢ８０を検索するが、登録ＵＲＬが入力ＵＲＬに一致するレコードがヒットしない（Ｓ６２）。ルックアップクライアント７０は、次に部分ＤＢ２６ｃを検索するが、入力ＵＲＬに対するカテゴリを確定することができない（Ｓ６４）。そこで、ルックアップクライアント７０は、ルックアップサーバ５０にサーバ側でのカテゴリ判定を要求する（Ｓ６６）。
【０１３５】
ステップＳ６８〜Ｓ７４：ルックアップサーバ５０は、ルックアップクライアント７０からの要求を受信する（Ｓ６８）。そこで、要求とともに送られた入力ＵＲＬを取得してフルＤＢ２４ｃを検索すると、登録ＵＲＬが入力ＵＲＬに一致するレコードがヒットし（Ｓ７０）、入力ＵＲＬに対するカテゴリ「１１２」が確定する（Ｓ７２）。ルックアップサーバ５０は、カテゴリ判定の結果データをルックアップクライアント７０に送信する（Ｓ７４）。
【０１３６】
ステップＳ７６，Ｓ７８：ルックアップクライアント７０は、ルックアップサーバ５０から送られた結果データに基づいてキャッシュＤＢを更新する（Ｓ７６）。また、ルックアップクライアント７０は、確定したカテゴリを出力し（Ｓ７８）、このカテゴリに対するユーザ設定に応じてユーザ端末９０によるウェブサイトへのアクセスを制御する。
【０１３７】
このように、ローカルルックアップによりカテゴリが確定されなかった場合、ルックアップクライアント７０はルックアップサーバ５０に対しサーバ側でのカテゴリ判定を要求し、ルックアップサーバ５０はこの要求に応じて実行したカテゴリ判定の結果をルックアップクライアント７０に対して応答する。つまり、ルックアップクライアント７０とルックアップサーバ５０との間での通信は、ローカルルックアップによりカテゴリが確定されなかった場合に限り発生する。
【０１３８】
図１４は、フラグ「ＨＡＳ＿ＬＥＦＴ」を用いてサーバ側で実行されるカテゴリ判定処理を説明する図である。フラグ「ＨＡＳ＿ＬＥＦＴ」については既に説明したが、フラグ「ＨＡＳ＿ＬＥＦＴ」が付与されているレコードに対しては、併せてフラグ「ＨＡＳ＿ＬＥＦＴ＿ＮＯＣＬＥＡＲ」が付与されている場合がある。フラグ「ＨＡＳ＿ＬＥＦＴ＿ＮＯＣＬＥＡＲ」は、このフラグが付与されたレコードの登録ＵＲＬのドメイン部を複数のドメイン階層を跨いで親ドメインとした登録ＵＲＬを有する他のレコードが格納されていることを示している。フラグ「ＨＡＳ＿ＬＥＦＴ＿ＮＯＣＬＥＡＲ」が付与されているレコードに基づいてカテゴリが確定された場合、その結果データからフラグ「ＨＡＳ＿ＬＥＦＴ」は削除されない。
【０１３９】
以下、データベースの登録レコード例に沿ってフラグ「ＨＡＳ＿ＬＥＦＴ」及び「ＨＡＳ＿ＬＥＦＴ＿ＮＯＣＬＥＡＲ」を用いたカテゴリ判定処理の具体例を説明する。なお、図１４中の表にリストアップされた例はいずれも、これまでの説明に登場した例とは関連性を有しないものとする。
【０１４０】
図１４中（Ａ）：サーバルックアップで使用されるフルＤＢ２４ｃに格納されているレコードの一例を示す表である。各表中の左のカラムには説明の便宜のために付した番号が示されており、左から２番目のカラムには登録ＵＲＬが示されており、右から２番目のカラムにはカテゴリＩＤが示されており、右のカラムにはフラグが示されている。この表には、番号４１〜４４の４件のレコードが例示されている。
【０１４１】
番号４１のレコードには、フラグ「ＨＡＳ＿ＬＥＦＴ」とともにフラグ「ＨＡＳ＿ＬＥＦＴ＿ＮＯＣＬＥＡＲ」が付与されている。番号４２のレコードには、フラグ「ＨＡＳ＿ＬＥＦＴ」のみが付与されている。番号４３及び４４のレコードには、フラグが付与されていない。
【０１４２】
番号４２の登録ＵＲＬのドメイン部「ａａａ．ｘｙｚ．ｃｏｍ」は、番号４１の登録ＵＲＬのドメイン部「ｘｙｚ．ｃｏｍ」を親ドメインとしている。したがって、番号４１のレコードにはフラグ「ＨＡＳ＿ＬＥＦＴ」が付与されている。また、番号４３の登録ＵＲＬのドメイン部「ａ１．ａａａ．ｘｙｚ．ｃｏｍ」は、番号４２の登録ＵＲＬのドメイン部「ａａａ．ｘｙｚ．ｃｏｍ」を親ドメインとしている。したがって、番号４２のレコードにはフラグ「ＨＡＳ＿ＬＥＦＴ」が付与されている。これらの例では、いずれも対比する２つのドメイン部は親ドメインとサブドメインの関係にあり（１階層）、複数のドメイン階層を跨いでいない。
【０１４３】
番号４４の登録ＵＲＬのドメイン部「ｂ１．ｂｂｂ．ｘｙｚ．ｃｏｍ」の親ドメインは「ｂｂｂ．ｘｙｚ．ｃｏｍ」である。ドメイン「ｂｂｂ．ｘｙｚ．ｃｏｍ」を登録ＵＲＬのドメイン部とするレコードは格納されていないが、番号４１のレコードは、このドメインの親ドメイン「ｘｙｚ．ｃｏｍ」を登録ＵＲＬのドメイン部に有している。つまり、番号４４の登録ＵＲＬのドメイン部「ｂ１．ｂｂｂ．ｘｙｚ．ｃｏｍ」は、番号４１の登録ＵＲＬのドメイン部「ｘｙｚ．ｃｏｍ」を複数のドメイン階層（２階層）を跨いで親ドメインとしている。したがって、番号４１のレコードには更にフラグ「ＨＡＳ＿ＬＥＦＴ＿ＮＯＣＬＥＡＲ」が付与されている。
【０１４４】
図１４中（Ｂ）：各入力ＵＲＬが指定されサーバ側でカテゴリ判定処理が実行された場合にサーバから返される結果データを示す表である。表中の左のカラムには説明の便宜のために付した番号が示されており、左から２番目のカラムには入力ＵＲＬが示されている。右から３つのカラムには、サーバ側で実行されたカテゴリ判定処理の結果として図９中のステップＳ３４０で取得されて返される結果データ（マッチＵＲＬ、カテゴリＩＤ及びフラグ）が示されている。
【０１４５】
番号１の入力ＵＲＬは、ドメイン部が「ｗｗｗ．ａａａ．ｘｙｚ．ｃｏｍ」であり、番号４２の登録ＵＲＬのドメイン部「ａａａ．ｘｙｚ．ｃｏｍ」を親ドメインとしている。一般的に、サブドメイン「ｗｗｗ．ａａａ．ｘｙｚ．ｃｏｍ」は、親ドメイン「ａａａ．ｘｙｚ．ｃｏｍ」と同じパス構造を有していることが多く、両ドメインは同一であるとみなすことができる。したがって、番号１の入力ＵＲＬに対するカテゴリは番号４２のレコードに基づいて確定され、カテゴリＩＤ「２００」が返される。このとき、親ドメインに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」は結果データには継承されない。このように、特定文字列を最下位の階層に持つサブドメインが入力ＵＲＬとして指定された場合、親ドメインと同一視してカテゴリ判定がなされるとともに、結果データには親ドメインに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」は返されない。なお、このようなカテゴリ判定がなされる特定文字列には、上述した「ｗｗｗ」の他に、「ｍ」、「ｍｏｂｉｌｅ」又は「ｉ」等がある。
【０１４６】
番号２の入力ＵＲＬは、ドメイン部が「ａ２．ａａａ．ｘｙｚ．ｃｏｍ」であり、番号４２の登録ＵＲＬのドメイン部「ａａａ．ｘｙｚ．ｃｏｍ」を親ドメインとしている。したがって、番号２の入力ＵＲＬに対するカテゴリは番号４２のレコードに基づいて確定され、カテゴリＩＤ「２００」が返される。番号４２のレコードに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」は、このドメインが直下の階層のサブドメインを有していることを示すものであり、番号２の入力ＵＲＬのドメイン部が更なるサブドメインを有していることは意味していない。したがって、結果データには親ドメインに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」は返されない。つまり、フラグ「ＨＡＳ＿ＬＥＦＴ」は結果データから削除される。
【０１４７】
番号３の入力ＵＲＬは、ドメイン部が「ｂｂｂ．ｘｙｚ．ｃｏｍ」であり、番号４１の登録ＵＲＬのドメイン部を親ドメインとしている。したがって、番号３の入力ＵＲＬに対するカテゴリは番号４１のレコードに基づいて確定され、カテゴリＩＤ「１００」が返される。番号４１のレコードに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」は、このドメインが直下の階層のサブドメインを有していることを示すものであり、番号３の入力ＵＲＬのドメイン部が更なるサブドメインを有していることは意味していない。しかしながら、番号４１のレコードには併せてフラグ「ＨＡＳ＿ＬＥＦＴ＿ＮＯＣＬＥＡＲ」が付与されており、カテゴリ判定処理においてはこのドメインを複数の階層を跨いで親ドメインとするサブドメインが存在することを考慮しなければならない。したがって、結果データにはこのドメインに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」が返される。つまり、フラグ「ＨＡＳ＿ＬＥＦＴ」は結果データから削除されない。
【０１４８】
図１５は、フラグ「ＨＡＳ＿ＲＩＧＨＴ」を用いてサーバ側で実行されるカテゴリ判定処理を説明する図である。フラグ「ＨＡＳ＿ＲＩＧＨＴ」については既に説明したが、フラグ「ＨＡＳ＿ＲＩＧＨＴ」が付与されているレコードに対しては、併せてフラグ「ＨＡＳ＿ＲＩＧＨＴ＿ＮＯＣＬＥＡＲ」が付与されている場合がある。フラグ「ＨＡＳ＿ＲＩＧＨＴ＿ＮＯＣＬＥＡＲ」は、フラグ「ＨＡＳ＿ＲＩＧＨＴ」が付与される要因となったレコードの登録ＵＲＬのパス部が、不特定な他のサブドメインにも継承されていることを示している。フラグ「ＨＡＳ＿ＲＩＧＨＴ＿ＮＯＣＬＥＡＲ」が付与されているレコードに基づいてカテゴリが確定された場合、その結果データからフラグ「ＨＡＳ＿ＲＩＧＨＴ」は削除されない。
【０１４９】
以下、データベースの登録レコード例に沿ってフラグ「ＨＡＳ＿ＲＩＧＨＴ」及び「ＨＡＳ＿ＲＩＧＨＴ＿ＮＯＣＬＥＡＲ」を用いたカテゴリ判定処理の具体例を説明する。なお、図１５中の表にリストアップされた例はいずれも、これまでの説明に登場した例とは関連性を有しないものとする。
【０１５０】
図１５中（Ａ）：サーバルックアップで使用されるフルＤＢ２４ｃに格納されているレコードの一例を示す表である。各表中の左のカラムには説明の便宜のために付した番号が示されており、左から２番目のカラムには登録ＵＲＬが示されており、右から２番目のカラムにはカテゴリＩＤが示されており、右のカラムにはフラグが示されている。この表には、番号５１〜５３及び番号６１，６２の５件のレコードが例示されている。
【０１５１】
番号５１のレコードには、フラグ「ＨＡＳ＿ＬＥＦＴ」及び「ＨＡＳ＿ＲＩＧＨＴ」が付与されている。番号５２のレコードには、フラグ「ＨＡＳ＿ＲＩＧＨＴ」のみが付与されている。番号５３のレコードには、フラグが付与されていない。
【０１５２】
番号５２，５３の登録ＵＲＬのドメイン部は、いずれも番号５１の登録ＵＲＬのドメイン部「ｘｙｚ．ｃｏｍ」を親ドメインとしている。したがって、番号５１のレコードにはフラグ「ＨＡＳ＿ＬＥＦＴ」が付与されている。また、番号５３の登録ＵＲＬは、番号５２の登録ＵＲＬに前方一致しつつ、番号５２の登録ＵＲＬのパス部「／」より長いパス部「／ｍｕｓｅｕｍ／」を有している。したがって、番号５２のレコードにはフラグ「ＨＡＳ＿ＲＩＧＨＴ」が付与されている。
【０１５３】
また、番号６１のレコードには、フラグ「ＨＡＳ＿ＬＥＦＴ」及び「ＨＡＳ＿ＲＩＧＨＴ」とともにフラグ「ＨＡＳ＿ＲＩＧＨＴ＿ＮＯＣＬＥＡＲ」が付与されている。番号６２のレコードには、フラグが付与されていない。
【０１５４】
番号６１のレコードに付与されたフラグ「ＨＡＳ＿ＲＩＧＨＴ＿ＮＯＣＬＥＡＲ」は、このドメイン「ａｂｃ．ｃｏｍ」に地名や自動生成された定型文字列のような規則的な名称で構成されるサブドメイン（例えば「ｔｏｋｙｏ．ａｂｃ．ｃｏｍ」や「ｏｓａｋａ．ａｂｃ．ｃｏｍ」）が複数存在し、それらのサブドメインの間で同一のパス構造を有していることを示している。フラグ「ＨＡＳ＿ＲＩＧＨＴ＿ＮＯＣＬＥＡＲ」が付与されているレコードのドメイン部を親ドメインとする全てのサブドメインに対しては、このフラグに基づき親ドメインと同一のパス構造を有しているものとみなしてカテゴリ判定が行われる。
【０１５５】
図１５中（Ｂ）：各入力ＵＲＬが指定されサーバ側でカテゴリ判定処理が実行された場合にサーバから返される結果データを示す表である。表中の左のカラムには説明の便宜のために付した番号が示されており、左から２番目のカラムには入力ＵＲＬが示されている。右から３つのカラムには、サーバ側で実行されたカテゴリ判定処理の結果として図９中のステップＳ３４０で取得されて返される結果データ（マッチＵＲＬ、カテゴリＩＤ及びフラグ）が示されている。
【０１５６】
番号１の入力ＵＲＬ「ｈｔｔｐ：／／ｃａｔ．ｘｙｚ．ｃｏｍ／」は、番号５２の登録ＵＲＬに完全一致している。したがって、番号１の入力ＵＲＬに対するカテゴリは番号５２のレコードに基づいて確定され、結果データとしてこのレコードと同一のカテゴリＩＤ「６００」及びフラグ「ＨＡＳ＿ＲＩＧＨＴ」が返される。
【０１５７】
番号２の入力ＵＲＬ「ｈｔｔｐ：／／ｃａｔ．ｘｙｚ．ｃｏｍ／ｍｕｓｉｃ／」は、番号５２の登録ＵＲＬとドメイン部が同一であり、番号５２の登録ＵＲＬのパス部「／」より長いパス部「／ｍｕｓｉｃ／」を有している。番号２の入力ＵＲＬは、番号５３の登録ＵＲＬともドメイン部が同一であり、パス部は前方一致しているが「／ｍｕｓｉ」以降は一致していない。したがって、番号２の入力ＵＲＬに対するカテゴリは番号５２のレコードに基づいて確定され、カテゴリＩＤ「６００」とともにマッチＵＲＬ「ｈｔｔｐ：／／ｃａｔ．ｘｙｚ．ｃｏｍ／ｍｕｓｉ」が返される。番号５２のレコードに付与されているフラグ「ＨＡＳ＿ＲＩＧＨＴ」は、親パス「／」に対して付与されたフラグであり、番号２の入力ＵＲＬに対して返されたマッチＵＲＬのパス部「／ｍｕｓｉ」より長いパス部を有する登録ＵＲＬが存在することは意味していない。したがって、結果データには親パスに付与されているフラグ「ＨＡＳ＿ＲＩＧＨＴ」は返されない。つまり、フラグ「ＨＡＳ＿ＲＩＧＨＴ」は結果データから削除される。
【０１５８】
番号３の入力ＵＲＬは、ドメイン部が「ｄｏｇ．ｘｙｚ．ｃｏｍ」であり、番号５１の登録ＵＲＬのドメイン部「ｘｙｚ．ｃｏｍ」を親ドメインとしている。したがって、番号３の入力ＵＲＬに対するカテゴリは番号５１のレコードに基づいて確定され、カテゴリＩＤ「５００」が返される。番号５１のレコードに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」は、親ドメインが直下の階層のサブドメインを有していることを示すものであり、番号３の入力ＵＲＬのドメイン部が更なるサブドメインを有していることは意味していない。したがって、結果データには親ドメインに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」は返されない。また、番号５１のレコードに付与されているフラグ「ＨＡＳ＿ＲＩＧＨＴ」は、親ドメイン「ｘｙｚ．ｃｏｍ」のルートパス「／」に対して付与されたフラグであり、番号３の入力ＵＲＬのパス部より長いパス部を有する登録ＵＲＬが存在することは意味していない。したがって、結果データには親ドメインに付与されているフラグ「ＨＡＳ＿ＲＩＧＨＴ」は返されない。つまり、フラグ「ＨＡＳ＿ＬＥＦＴ」及び「ＨＡＳ＿ＲＩＧＨＴ」はいずれも結果データから削除される。
【０１５９】
番号４の入力ＵＲＬは、ドメイン部が「ｔｏｋｙｏ．ａｂｃ．ｃｏｍ」であり、番号６１の登録ＵＲＬのドメイン部「ａｂｃ．ｃｏｍ」を親ドメインとしている。したがって、番号４の入力ＵＲＬに対するカテゴリは番号６１のレコードに基づいて確定され、カテゴリＩＤ「８００」が返される。番号６１のレコードに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」は、親ドメインが直下の階層のサブドメインを有していることを示すものであり、番号４の入力ＵＲＬのドメイン部が更なるサブドメインを有していることは意味していない。したがって、結果データには親ドメインに付与されているフラグ「ＨＡＳ＿ＬＥＦＴ」は返されない。また、番号６１のレコードに付与されているフラグ「ＨＡＳ＿ＲＩＧＨＴ」は、親ドメイン「ａｂｃ．ｃｏｍ」のルートパス「／」に対して付与されたフラグであり、番号４の入力ＵＲＬのパス部より長いパス部を有する登録ＵＲＬが存在することは意味していない。しかしながら、番号６１のレコードには併せてフラグ「ＨＡＳ＿ＲＩＧＨＴ＿ＮＯＣＬＥＡＲ」が付与されており、カテゴリ判定処理においては親パスより長いパス部を有する登録ＵＲＬが存在することを考慮しなければならない。したがって、結果データには親ドメインに付与されているフラグ「ＨＡＳ＿ＲＩＧＨＴ」が返される。つまり、フラグ「ＨＡＳ＿ＬＥＦＴ」は結果データから削除されるが、フラグ「ＨＡＳ＿ＲＩＧＨＴ」は結果データから削除されない。
【０１６０】
番号５の入力ＵＲＬ「ｈｔｔｐ：／／ｏｓａｋａ．ａｂｃ．ｃｏｍ／ｄｒｕｇ／」は、番号６２の登録ＵＲＬのドメイン部「ａｂｃ．ｃｏｍ」を親ドメインとしており、パス部は番号６２の登録ＵＲＬのパス部「／ｄｒｕｇ／」と一致している。したがって、番号５の入力ＵＲＬに対するカテゴリは番号６２のレコードに基づいて確定され、カテゴリＩＤ「９００」が返される。番号６２のレコードにはフラグが付与されていないため、結果データにはフラグは返されない。
【０１６１】
このように、カテゴリ判定において基準としたレコードに付与されているフラグは、状況に応じて結果データから削除される（結果データとして返されない）が、フラグ「ＨＡＳ＿＊＊＊＿ＮＯＣＬＥＡＲ」が付与されている場合はフラグ「ＨＡＳ＿＊＊＊」は結果データに残される（結果データとして返される）。
【０１６２】
ウェブフィルタリングシステム１００においては、指定された入力ＵＲＬに対するカテゴリがキャッシュＤＢ８０及び部分ＤＢ２６ｃを用いて実行されるローカルルックアップにより確定されなかった場合、フルＤＢ２４ｃを用いて実行されるサーバルックアップによりカテゴリが確定される。この処理に伴いサーバ側から返される結果データは、クライアント側でキャッシュＤＢ８０に一時的に格納され、それ以降に実行されるローカルルックアップにおいて用いられる。したがって、結果データとしてマッチＵＲＬ及びカテゴリＩＤとともに適切なフラグをクライアント側に返すことにより、ローカルルックアップにおけるデータのヒット率を高めることができる。
【０１６３】
〔第２実施形態〕
次に、異なる実施形態のウェブフィルタリングシステムについて説明する。図１６は、第２実施形態のウェブフィルタリングシステム２００が動作する環境の構成図である。
【０１６４】
第２実施形態のウェブフィルタリングシステム２００は、上述した第１実施形態のウェブフィルタリングシステム１００におけるルックアップクライアント７０及びユーザ端末９０の機能をユーザ端末９５が兼ね備えている点で、第１実施形態のウェブフィルタリングシステム１００とは異なっている。言い換えると、第２実施形態のウェブフィルタリングシステム２００においては、ローカルルックアップの機能がユーザ端末９５に搭載されており、ウェブブラウザ等を介したウェブサイトへのアクセス要求と、アクセス要求がなされたＵＲＬ（入力ＵＲＬ）に対するローカルルックアップとを、いずれもユーザ端末９５が実行する。ユーザ端末９５は、例えば、コンピュータ、スマートフォンやタブレットＰＣ等のモバイルデバイスが該当する。
【０１６５】
図１７は、第２実施形態のウェブフィルタリングシステム２００におけるデータの流れを表す模式図である。なお、図中の白抜き矢印は、データベースの流れを示しており、黒矢印は、データベース以外のデータの流れを示している。
【０１６６】
ユーザ端末９５は、インターネット６０に接続可能である。上述したように、第２実施形態のウェブフィルタリングシステム２００においては、ローカルルックアップの機能がユーザ端末９５に搭載されている。したがって、ローカルルックアップに用いられる部分ＤＢ２６ｃは、インターネット６０を介して第２配信サーバ４０からユーザ端末９５に配信される。
【０１６７】
ユーザ端末９５でウェブサイトへのアクセス要求が発生すると、ユーザ端末９５は、先ず部分ＤＢ２６ｃ及びキャッシュＤＢ８０を用いてローカルルックアップを実行し、入力ＵＲＬに対するカテゴリの確定を試みる。ローカルルックアップによりカテゴリが確定された場合には、ユーザ端末９５は確定されたカテゴリに基づいてウェブサイトへのアクセス可否を制御する。これに対し、ローカルルックアップによりカテゴリが確定されなかった場合には、ユーザ端末９５はルックアップサーバ５０に対してサーバルックアップを要求し、この要求に対するルックアップサーバ５０からの応答結果に基づいて、ウェブサイトへのアクセス可否を制御する。
【０１６８】
なお、第２実施形態のウェブフィルタリングシステム２００においては、キャッシュＤＢ８０が記憶容量がさほど大きくないユーザ端末９５のリソースに記憶される点を考慮し、キャッシュＤＢ８０のデータサイズには、第１実施形態のウェブフィルタリングシステム１００における場合よりも小さい上限（例えば１〜１０ＭＢ）が設けられている。また、図１７において、ユーザ端末９５に配信された部分ＤＢ２６ｃは、その大きさが第２配信サーバ４０が配信する部分ＤＢ２６ｃより小さく描かれているが、これは図面のスペースの都合によるものである。図１７中に示される部分ＤＢ２６ｃはいずれも、作成サーバ２０が作成した部分ＤＢ２６の複製であり、データベースのサイズは同一である。
【０１６９】
〔実施形態の優位性〕
以上に述べたように、上述したウェブフィルタリングシステム１００（ウェブフィルタリングシステム２００）においては、カテゴリ判定処理の過程でルックアップされるデータのうち、全データを格納するフルＤＢ２４ｃがルックアップサーバ５０に配信される一方、全データのうち所定の基準に従って抽出された部分データを格納する部分ＤＢ２６ｃがルックアップクライアント７０（ユーザ端末９５）に配信される。また、入力ＵＲＬに対するカテゴリがローカルルックアップで確定されなかった場合に実行されたサーバルックアップの結果データが、キャッシュＤＢ８０に一時的に格納される。フルＤＢ２４ｃ、部分ＤＢ２６ｃ及びキャッシュＤＢ８０は、いずれもフラグを用いたカテゴリ判定を行うことができるデータ構造を有している。
【０１７０】
ユーザ端末９０（ユーザ端末９５）によるウェブサイトへのアクセス要求が発生すると、ルックアップクライアント７０（ユーザ端末９５）は、先ずキャッシュ８０を用い、次に部分ＤＢ２６ｃを用いて、ローカルルックアップにより入力ＵＲＬに対するカテゴリの確定を試みる。そして、ローカルルックアップによりカテゴリが確定されなかった場合に限り、ルックアップサーバ５０に対してサーバ側でのカテゴリ判定を要求し、カテゴリを確定させる。
【０１７１】
したがって、ウェブフィルタリングシステム１００（ウェブフィルタリングシステム２００）によれば、ルックアップの過程で入力ＵＲＬに部分一致する登録ＵＲＬを効率よくマッチングさせることができる。また、このようなデータ構造は、ドメイン部やパス部の階層が深い登録ＵＲＬを有するレコードの冗長的な格納をなくすことができる。これにより、フルＤＢ２４ｃ及び部分ＤＢ２６ｃのデータ効率を向上させ、ローカルルックアップにおけるデータのヒット率を高めることができる。
【０１７２】
また、ローカルルックアップにおけるヒット率の上昇により、ローカルルックアップに伴う使用メモリ量を抑制するとともに、サーバ側でのカテゴリ判定を必要とする頻度を低下させることができる。したがって、ウェブフィルタリングシステム１００（ウェブフィルタリングシステム２００）によれば、仮にルックアップサーバ５０に毎回問い合わせを行うとした場合と比較して、ルックアップクライアント７０（ユーザ端末９５）からルックアップサーバ５０に対する問い合わせの回数を減らし、ルックアップクライアント７０（ユーザ端末９５）とルックアップサーバ５０との間の通信量を最小限に抑制することができる。結果として、ウェブサイトへのアクセス要求に対する制御に要する応答時間を短縮することが可能となる。
【０１７３】
また、部分ＤＢ２６ｃはフルＤＢ２４ｃに格納される全データから必要十分な部分データが抽出されて作成されており、キャッシュＤＢ８０にはデータ量の上限が設けられているため、ルックアップクライアント７０（ユーザ端末９５）のローカルリソースが過度に消費されることがない。このこともまた、ローカルルックアップに伴う使用メモリ量の抑制に貢献する。使用メモリ量を抑制することにより、ローカルルックアップにおいて優れた処理速度を得ることが可能となる。
【０１７４】
また、部分ＤＢ２６ｃを、例えばフルＤＢ２４ｃに格納される全データのうちアクセス頻度の高い方から順にフラグが付与されていないデータを優先的に抽出して作成することにより、ローカルルックアップにおけるデータのヒット率をさらに高めることができる。ローカルルックアップにおけるデータのヒット率の向上は、サーバルックアップが必要とされる頻度を低下させ、結果としてルックアップクライアント７０（ユーザ端末９５）とルックアップサーバ５０との通信量の抑制に一層貢献することが可能となる。
【０１７５】
このように、ウェブフィルタリングシステム１００（ウェブフィルタリングシステム２００）によれば、ルックアップクライアント７０（ユーザ端末９５）は、ユーザ端末９０（ユーザ端末９５）によるウェブサイトへのアクセス要求に対するアクセス許可／不許可の制御を効率よく実行することができる。通信量、使用メモリ、処理速度のいずれの側面においても、実施形態の顕著な優位性が明らかである。
【０１７６】
本発明は、上述した実施形態に制約されることなく、種々に変更して実施することが可能である。また、実施形態で挙げた各種数値はあくまで例示であり、上述した内容に限定されるものではない。
【０１７７】
上述した実施形態では、２種類の配信用データベース（フルＤＢ２４ｃ、部分ＤＢ２６ｃ）をそれぞれ異なる配信サーバが配信しているが、同一の配信サーバが配信してもよい。
【０１７８】
上述した実施形態では、マスタＤＢ１２がＤＢサーバ１０上で管理／提供されているが、マスタＤＢ１２は作成サーバ２０の内部記憶領域に実装されてもよいし、ＵＳＢやＳＣＳＩ等の各種ポートを介して作成サーバ２０に接続される外付けのハードディスクドライブ（ＨＤＤ）等の外部記憶媒体に実装されてもよい。
【０１７９】
上述した実施形態では、カテゴリ判定において基準としたレコードに付与されているフラグが状況に応じて結果データから削除され、フラグ「ＨＡＳ＿＊＊＊＿ＮＯＣＬＥＡＲ」が付与されている場合のみフラグ「ＨＡＳ＿＊＊＊」が結果データに残されるが、これに限定されない。例えば、カテゴリ判定において基準としたレコードに付与されているフラグを削除しない構成としてもよい。また、カテゴリ判定において基準としたレコードに付与されているフラグを削除するか否か（結果データとして返すか否か）を、設定により変更できる構成としてもよい。
【０１８０】
上述した第１実施形態では、ウェブフィルタリングシステム１００のユーザとして企業や学校を例に挙げたが、これに限定されず、例えば通信キャリアがウェブフィルタリングシステム１００を利用することも可能である。このケースでは、通信キャリアの顧客が利用する接続デバイスがユーザ端末９０に相当し、これらの接続デバイスの接続先となるサーバがルックアップクライアント７０に相当する。
【符号の説明】
【０１８１】
１０          ＤＢサーバ
１２          マスタＤＢ
２０          作成サーバ
２４，２４ｃ  フルＤＢ（第１配信ＤＢ）
２６，２６ｃ  部分ＤＢ（第２配信ＤＢ）
３０          第１配信サーバ
４０          第２配信サーバ
５０          ルックアップサーバ
６０          インターネット
７０          ルックアップクライアント
８０          キャッシュＤＢ
１００        ウェブフィルタリングシステム
【要約】
ウェブサイトへのアクセス許可／不許可の制御を効率よく実行することができる技術を提供する。
クライアント（７０）は、ウェブサイトへのアクセス要求に伴う入力ＵＲＬを取得し（Ｓ４００）、入力ＵＲＬを検索キーとして先ずキャッシュＤＢ（８０）を検索し（Ｓ４１０）、ヒットしなければ次に部分ＤＢ（２６ｃ）を検索する（Ｓ４３０）。いずれかのＤＢでヒットした場合（Ｓ４２０：Ｙｅｓ，Ｓ４４０：Ｙｅｓ）、ヒットしたレコードに基づき入力ＵＲＬに対するカテゴリの確定を試みる（Ｓ４５０）。いずれのＤＢでもヒットしなかった場合（Ｓ４４０：Ｎｏ）、又は、ヒットはしたがカテゴリを確定できなかった場合（Ｓ４６０：Ｎｏ）に限り、クライアント（７０）は、サーバ（５０）にカテゴリ判定を要求して（Ｓ４７０）、その結果を受信し（Ｓ４８０）、キャッシュＤＢ（８０）を更新する（Ｓ５００）。最後に、確定したカテゴリを返す（Ｓ５１０）。
（選択図：図８）【図１】
0006259175.tif 000002
【図２】
0006259175.tif 000003
【図３】
0006259175.tif 000004
【図４】
0006259175.tif 000005
【図５】
0006259175.tif 000006
【図６】
0006259175.tif 000007
【図７】
0006259175.tif 000008
【図８】
0006259175.tif 000009
【図９】
0006259175.tif 000010
【図１０】
0006259175.tif 000011
【図１１】
0006259175.tif 000012
【図１２】
0006259175.tif 000013
【図１３】
0006259175.tif 000014
【図１４】
0006259175.tif 000015
【図１５】
0006259175.tif 000016
【図１６】
0006259175.tif 000017
【図１７】
0006259175.tif 000018