JP7498844B1 - ウェブフィルタリングシステム - Google Patents

Abstract

【課題】ウェブサイトに送信しようとするデータの内容を踏まえてアクセスを制御する技術の提供。【解決手段】ＤＢには予め、ユーザが登録した個々のキーワード及びこれをハッシュ化して得られるハッシュ化キーワードが格納されている。フィルタリングサーバでは、個々のキーワードがリクエストのボディデータに含まれるか否かを確認すべく、ボディデータを分割して生じる分割データを順にハッシュ化し（Ｓ６３，Ｓ７１）、これを対象としてハッシュ化キーワードとのマッチングを行い（Ｓ６４）、一致したら（Ｓ６４：Ｙｅｓ）規制判定を下す（Ｓ６５）。ハッシュ化することでマッチングを高速に行うことができる。また、２番目以降のハッシュ化分割データをマッチングの対象とする際には、その先頭に１つ前のハッシュ化分割データの末尾部を連結するため（Ｓ７２）、２つの分割データに跨って存在するキーワードを見逃すことなく規制判定を下すことができる。【選択図】図６

Description

本発明は、ウェブサイトに対するアクセスの制御、特に、ウェブサイトに対し送信しようとするデータの内容を踏まえてアクセスを制御するウェブフィルタリングシステムに関する。

従来、コンピュータとそのコンピュータがアクセスしようとするウェブサーバとの間の通信を所定の規則に沿って制御する技術が知られている。例えば、特許文献１には、管理者によりカテゴリ毎の閲覧可否の設定が予めなされており、ウェブサイトの閲覧要求を受け付けると、フィルタリングサーバにそのウェブサイトのカテゴリを問い合わせ、フィルタリングサーバから送信されたカテゴリ情報に基づいてウェブサイトの閲覧を禁止又は許可するフィルタリング方法が開示されている。また、特許文献２には、第１のコンピュータから第２のコンピュータへのアクセスを制限するか否かを決定するためのアクセス制限条件に、第２のコンピュータにより提供されるサービスに含まれる個々の機能（ログイン、メール、書き込み、アップロード等）単位での許可又は禁止の設定が含まれうることが記載されている。

特開２０２３－１３４９６９号公報 特開２０１５－１４１６０９号公報 特開２００７－２５７３４６号公報

前者の先行技術によれば、ＵＲＬにより特定されるウェブサイトのカテゴリに基づいてそのウェブサイトへのアクセスを制御することができ、後者の先行技術によれば、ウェブサイトにより提供される特定の機能のみ利用を許可しつつ他の機能は利用を禁止する等、１つのウェブサイトに対する制御を機能に応じて細分化することができると考えられる。しかしながら、いずれの先行技術においても、ウェブサイトに送信される情報の内容には関与していないため、不適切な情報が送信されないようにするには、閲覧には問題がなくても、ウェブサイト全体、又はウェブサイトにより提供される機能全体で利用を禁止せざるを得ない。

一方、電子掲示板システムにおいて、投稿された掲示文章に電子掲示板への掲示に不適切な掲示禁止用語が含まれる場合に、自動的に電子掲示板への掲示を拒否し、掲示禁止用語は含まれないものの個人を誹謗中傷した内容が記載された掲示文章や個人情報が記載された掲示文章については、管理者が確認した上で削除するようなシステムも存在するが（例えば、特許文献３を参照。）、このような機能を備えたウェブサイトはごく一部に過ぎない。また、不適切と捉えられる情報はユーザ（企業や学校等）により異なることから、仮に全てのウェブサイトがこのような機能を備えたとしても、ユーザにとって満足のいく運用がなされるとは限らない。これらの点を鑑みると、ユーザが不適切と捉える情報が送信されないようにするには、送信側において何らかの制御が求められる。

そこで、本発明は、ウェブサイトに送信しようとするデータの内容を踏まえてアクセスを制御する技術の提供を課題とする。

上記の課題を解決するため、本発明は以下のウェブフィルタリングシステムを採用する。なお、以下の括弧書中の文言はあくまで例示であり、本発明はこれに限定されるものではない。

すなわち、本発明のウェブフィルタリングシステムは、ユーザにより予め登録された１以上のキーワードが格納された記憶部と、ウェブサーバに対するブラウザからのリクエストの規制に関する問い合わせを受け付けると、リクエストのボディデータにキーワードが含まれるか否かに基づいて判定を行い、問い合わせの送信元に判定結果を返す判定部とを備えている。

ウェブフィルタリングシステムにおいて判定に用いられるキーワードは、ユーザにより予め登録されたものである。したがって、ウェブフィルタリングシステムによれば、規制するか否かの判定をユーザの意向に沿って行うことができ、ユーザが不適切と捉えるキーワードを含むデータの送信を確実に規制することが可能となる。

好ましくは、上述した態様のウェブフィルタリングシステムにおいて、判定部は、ボディデータをハッシュ化して得られるハッシュ化データとキーワードをハッシュ化して得られるハッシュ化キーワードとのマッチングを行うことにより、ボディデータにキーワードが含まれるか否かを確認する。

この態様のウェブフィルタリングシステムによれば、ハッシュ化データとハッシュ化キーワードとのマッチングを行うため、ハッシュ化せずにマッチングを行う場合と比較して、マッチングひいてはボディデータにキーワードが含まれるか否かの確認を高速に実行することができる。

より好ましくは、上述したいずれかの態様のウェブフィルタリングシステムにおいて、記憶部は、キーワード及びこれに対応するハッシュ化キーワードが予め格納されている。

この態様のウェブフィルタリングシステムによれば、マッチングの際に記憶部に格納されているハッシュ化キーワードをそのまま用いることができるため、個々のキーワードをその都度ハッシュ化する必要がなく、マッチングの効率を向上することができる。

さらに好ましくは、上述したいずれかの態様のウェブフィルタリングシステムにおいて、判定部は、ボディデータを所定のサイズ毎に分割し、分割データをハッシュ化して得られるハッシュ化分割データとハッシュ化キーワードとのマッチングを行い、２番目以降のハッシュ化分割データをマッチングの対象とする場合には、当該ハッシュ化分割データの先頭に、１つ前のハッシュ化分割データの末尾部をなす、ユーザにより登録された最長のキーワードの文字数分のハッシュデータを連結する。

この態様のウェブフィルタリングシステムによれば、２番目以降のハッシュ化分割データの先頭にその１つ前のハッシュ化分割データの末尾部を連結してなるハッシュ化データを対象としてハッシュ化キーワードとのマッチングを行うため、２つの分割データに跨って存在しているキーワードを見逃すことなく規制の判定を下すことができ、データの送信を確実に規制することが可能となる。

以上のように、本発明によれば、ウェブサイトに送信しようとするデータの内容を踏まえてアクセスを制御することができる。

一実施形態のウェブフィルタリングシステム１を示すブロック図である。 プロキシ型の通信制御を説明する図である。 ＩＣＡＰ型の通信制御を説明する図である。 リダイレクトサーバ型の通信制御を説明する図である。 フィルタリング判定処理の手順例を示すフローチャートである。 キーワード判定処理の手順例を示すフローチャートである。 ユーザにより登録されたキーワードリストの一例を示す図である。 キーワード判定処理の各段階でマッチングの対象となるハッシュ化データを説明する図である。 キーワードが分割データ１に含まれている場合の例を示す図である。 キーワードが分割データ１～２に跨っている場合の例を示す図である。

以下、本発明の実施の形態について、図面を参照しながら説明する。なお、以下の実施形態は好ましい例示であり、本発明はこの例示に限定されるものではない。

図１は、一実施形態のウェブフィルタリングシステム１を示すブロック図である。
ウェブフィルタリングシステム１は、インターネット上に存在する様々なウェブサーバＷＳへのユーザ環境下（例えば、学校や企業等の環境下）にある端末からのアクセスを、予め登録された情報に基づいて制御するシステムである。アクセスの許可又は規制を判定するためのプログラムは、クラウド上に配置されたフィルタリングサーバ１０に実装されており、フィルタリングサーバ１０のＣＰＵ１１がこのプログラムの実行主体となる。また、フィルタリングサーバ１０にはデータベース（ＤＢ）１２が設けられており、プログラムによる判定に用いられる様々な情報が格納されている。

クラウド上には、フィルタリングサーバ１０に加えて、プロキシサーバ２０及びリダイレクトサーバ３０が配置されている。また、ユーザ環境下の端末には、ブラウザ４０が搭載されており、必要に応じてさらにアプリケーション５０やブラウザ拡張機能６０がインストールされている。端末のブラウザ４０からウェブサーバＷＳにアクセスしようとすると、プロキシサーバ２０、リダイレクトサーバ３０、アプリケーション５０のいずれかを介して、フィルタリングサーバ１０に対し、ブラウザ４０からのリクエストを規制するか否かに関する問い合わせがなされ、その結果に基づいて通信が制御される。

言い換えると、ウェブフィルタリングシステム１においては、ブラウザ４０とウェブサーバＷＳとの間の通信を制御するための３つの形態が設けられており、端末に適した形態が選択される。具体的には、端末のプロキシ設定を用いてプロキシサーバ２０経由で通信を制御するプロキシ型、端末のプロキシ設定を用いずにアプリケーション５０経由で通信を制御するＩＣＡＰ型、リダイレクトサーバ３０を用いてブラウザ拡張機能６０経由で通信を制御するリダイレクトサーバ型、の３つの形態が利用可能である。

図２は、プロキシ型の通信制御を示している。図２中（Ａ）は、プロキシ型の制御の流れを示すフローチャートであり、図２中（Ｂ）は、プロキシ型の制御に関わる構成を示すブロック図である。なお、（Ｂ）のブロック図における矢印はデータの流れる主な方向を示しており、矢印に付したステップ番号は（Ａ）のフローチャートにおけるステップ番号に対応しており、黒矢印は規制を示している。また、（Ｂ）のブロック図においてインターネットの図示を省略しているが、端末とサーバとの間の通信はインターネットを介してなされる（図３及び図４においても同様）。以下、流れに沿って説明する。

ステップＳ１１，Ｓ１２：プロキシサーバ２０は、ブラウザ４０からウェブサーバＷＳに対するリクエストを受け取ると（ステップＳ１１）、このリクエストの規制有無をフィルタリングサーバ１０に問い合わせる（ステップＳ１２）。

ステップＳ１３：プロキシサーバ２０からの問い合わせに応じて、フィルタリングサーバ１０がフィルタリング判定処理を実行し、その結果をプロキシサーバ２０に返す。なお、フィルタリング判定処理の内容については、別の図面を用いてさらに後述する。

ステップＳ１４，Ｓ１５：プロキシサーバ２０は、フィルタリングサーバ１０から「規制」が返された場合には（ステップＳ１４：Ｙｅｓ）、ブラウザ４０に規制の応答を返す（ステップＳ１５）。その結果、ブラウザ４０にはアクセスを規制する旨を示す画面が表示される。これに対し、フィルタリングサーバ１０から「許可」が返された場合には（ステップＳ１４：Ｎｏ）、プロキシサーバ２０は、ステップＳ１６に進む。

ステップＳ１６～Ｓ１８：プロキシサーバ２０は、ウェブサーバＷＳにリクエストを送信し（ステップＳ１６）、これに対するウェブサーバＷＳからのレスポンスを受け取って（ステップＳ１７）、ブラウザ４０に送信する（ステップＳ１８）。その結果、ブラウザ４０にはリクエストしたページが表示される。

図３は、ＩＣＡＰ型の通信制御を示している。図３中（Ａ）は、ＩＣＡＰ型の制御の流れを示すフローチャートであり、図３中（Ｂ）は、ＩＣＡＰ型の制御に関わる構成を示すブロック図である。以下、流れに沿って説明する。

ステップＳ２１，Ｓ２２：アプリケーション５０は、ブラウザ４０からのウェブサーバＷＳに対するリクエストをフックし（ステップＳ２１）、フックしたリクエストの規制有無をフィルタリングサーバ１０に問い合わせる（ステップＳ２２）。

ステップＳ２３：アプリケーション５０からの問い合わせに応じて、フィルタリングサーバ１０がフィルタリング判定処理を実行し、その結果をアプリケーション５０に返す。

ステップＳ２４，Ｓ２５：アプリケーション５０は、フィルタリングサーバ１０から「規制」が返された場合には（ステップＳ２４：Ｙｅｓ）、ブラウザ４０に規制の応答を返す（ステップＳ２５）。その結果、ブラウザ４０にはアクセスを規制する旨を示す画面が表示される。これに対し、フィルタリングサーバ１０から「許可」が返された場合には（ステップＳ２４：Ｎｏ）、アプリケーション５０は、ステップＳ２６に進む。

ステップＳ２６～Ｓ２８：アプリケーション５０は、ウェブサーバＷＳにリクエストを送信し（ステップＳ２６）、これに対するウェブサーバＷＳからのレスポンスを受け取って（ステップＳ２７）、ブラウザ４０に送信する（ステップＳ２８）。その結果、ブラウザ４０にはリクエストしたページが表示される。

図４は、リダイレクトサーバ型の通信制御を示している。図４中（Ａ）は、リダイレクトサーバ型の制御の流れを示すフローチャートであり、図４中（Ｂ）は、リダイレクトサーバ型の制御に関わる構成を示すブロック図である。以下、流れに沿って説明する。

ステップＳ３１：ブラウザ拡張機能６０は、ブラウザ４０からのウェブサーバＷＳに対するリクエストをフックし、これをリダイレクトサーバ３０に転送する。

ステップＳ３２：リダイレクトサーバ３０は、ブラウザ拡張機能６０から転送されたリクエストの規制有無をフィルタリングサーバ１０に問い合わせる。

ステップＳ３３：リダイレクトサーバ３０からの問い合わせに応じて、フィルタリングサーバ１０がフィルタリング判定処理を実行し、その結果をリダイレクトサーバ３０に返す。

ステップＳ３４～Ｓ３６：リダイレクトサーバ３０は、フィルタリングサーバ１０から「規制」が返された場合には（ステップＳ３４：Ｙｅｓ）、ブラウザ拡張機能６０に対し規制画面へのリダイレクト応答を返す（ステップＳ３５）。その結果、ブラウザ４０がアクセスを規制する旨を示す画面にリダイレクトする。これに対し、フィルタリングサーバ１０から「許可」が返された場合には（ステップＳ３４：Ｎｏ）、リダイレクトサーバ３０は、ブラウザ拡張機能６０に対しウェブサーバＷＳへのリダイレクト応答を返す（ステップＳ３６）。

ステップＳ３７，Ｓ３８：ブラウザ拡張機能６０は、ウェブサーバＷＳにリクエストを送信し（ステップＳ３７）、これに対するウェブサーバＷＳからのレスポンスを受け取る（ステップＳ３８）。その結果、ブラウザ４０にはリクエストしたページが表示される。

図５は、フィルタリング判定処理の手順例を示すフローチャートである。
フィルタリング判定処理は、ブラウザ４０とウェブサーバＷＳとの間の通信を制御する過程（図２中のステップＳ１３、図３中のステップＳ２３、図４中のステップＳ３３）で、リクエストの規制有無に関する問い合わせを受け付けたフィルタリングサーバ１０のＣＰＵ１１により実行される。以下、フィルタリング判定処理において実行される主な処理を手順例に沿って説明する。

ステップＳ５１：ＣＰＵ１１は、ＵＲＬ判定処理を実行する。ＵＲＬ判定処理では、ＣＰＵ１１は、データベース１２に予め格納されたドメイン情報やカテゴリ情報に基づいて、問い合わせを受けたリクエストのＵＲＬにより特定されるウェブサイトへのアクセスを許可するか否かを判定し、「許可」又は「規制」の判定結果を返す。なお、具体的な判定方法は、例えば特許第６２５９１７５号公報に記載されているものと同様であるため、ここでは説明を省略する。

ステップＳ５２：ＣＰＵ１１は、ＵＲＬ判定処理の返り値が「許可」である場合には（ステップＳ５２：Ｙｅｓ）、ステップＳ５３に進む一方、返り値が「規制」である場合には（ステップＳ５２：Ｎｏ）、ステップＳ５６に進む。

ステップＳ５３：ＣＰＵ１１は、続いてキーワード判定処理を実行する。キーワード判定処理では、ＣＰＵ１１は、ブラウザ４０からウェブサーバＷＳに送信されようとしているデータ（リクエストのボディデータ）にユーザ（例えば、学校や企業等）が予め登録したキーワードが含まれているか否かに基づいて、アクセスを許可するか否かを判定し、「許可」又は「規制」の判定結果を返す。なお、キーワード判定処理の詳細な内容については、別の図面を参照しながら詳しく後述する。

ステップＳ５４：ＣＰＵ１１は、キーワード判定処理の返り値が「許可」である場合には（ステップＳ５４：Ｙｅｓ）、ステップＳ５５に進む一方、返り値が「規制」である場合には（ステップＳ５４：Ｎｏ）、ステップＳ５６に進む。

ステップＳ５５，Ｓ５６：ＣＰＵ１１は、ＵＲＬ判定処理及びキーワード判定処理の両方の返り値が「許可」である場合には、問い合わせの送信元に対して「許可」を返す（ステップＳ５５）。これに対し、ＵＲＬ判定処理又はキーワード判定処理の返り値が「規制」である場合には、問い合わせの送信元に対して「規制」を返す（ステップＳ５６）。
以上の手順を終えると、ＣＰＵ１１は、フィルタリング判定処理を終了する。

なお、上記の手順例はあくまで一例であり、適宜変更が可能である。例えば、上記の手順例においては、ＵＲＬ判定処理の返り値が「許可」である場合にキーワード判定処理を実行しているが、これに代えて、先にキーワード判定処理を実行し、その返り値が「許可」である場合にＵＲＬ判定処理を実行してもよい。また、ＵＲＬ判定処理及びキーワード判定処理の他に、さらなる判定処理を組み合わせて実行してもよい。

図６は、キーワード判定処理の手順例を示すフローチャートである。
キーワード判定処理は、フィルタリング判定処理の過程（図５中のステップＳ５３）でフィルタリングサーバ１０のＣＰＵ１１により実行される。以下、手順例に沿って説明する。

ステップＳ６１：ＣＰＵ１１は、リクエストのボディデータを所定のサイズ毎に分割して、Ｎ個の分割データを生成する。ここではＣＰＵ１１は、ブラウザ４０から分割して送られてくるデータを、処理し易い所定のサイズ毎にさらに分割する。結果として、リクエストのボディデータ全体がＮ個に分割される。なお、ボディデータのサイズが所定のサイズに満たない場合には、分割データは１つ（Ｎ＝１）となる。

ステップＳ６２，Ｓ６３：ＣＰＵ１１は、ボディデータ全体における現在の位置を示す位置カウンタｃに１をセットし（ステップＳ６２）、最初の分割データである分割データ１をハッシュ化して、これをハッシュ化分割データ１とする（ステップＳ６３）。

ハッシュ化分割データは、その元となった分割データを構成する文字数に応じた個数（文字数＋１）の要素を持つ配列Ｈである。配列Ｈの各要素には、分割データを構成する各文字をハッシュ化した０以上の整数値（ハッシュ値）に基づいて算出された値がセットされる。具体的には、Ｈ［０］には固定値「１」がセットされ、Ｈ［ｋ］には、分割データの先頭からｋ文字目までの各文字のハッシュ値に対し所定のビット数（例えば、８ビット）を確保して累積した値に基づく値、より具体的には、Ｈ［ｋ－１］に所定値（例えば、２５６（＝８ビットの最大値））を乗じた値と分割データのｋ番目の文字のハッシュ値との和を十分に大きい除数で割った剰余がセットされる。分割データをこのような態様で配列化しておくことにより、後述するマッチングに際して、分割データに含まれる任意の位置における任意の長さの部分文字列のハッシュ値を簡単な演算で容易に算出可能となる。なお、ハッシュ化は、独自に開発したアルゴリズム（ハッシュ関数）により行ってもよいし、一般的に知られたハッシュ関数を用いて行ってもよい。

続いて、ハッシュ化分割データ１を対象として、データ送信を規制するための個々のキーワードとのマッチングがなされる。図７は、キーワードリストの一例として、学校Ａというユーザにより登録されたキーワードリストの一部を抜粋して示している。

データベース１２には、ユーザにより予め登録された１以上のキーワードからなるキーワードリストが格納されている。学校Ａのキーワードリストには、生徒や教員によるＳＮＳや電子掲示板等への投稿を阻止すべきであると学校Ａが判断した様々なキーワード（例えば、薬物や犯罪に関する言葉、暴力的な言葉、他者を誹謗中傷又は差別する言葉等）が登録されている。

マッチングを効率よく行えるよう、データベース１２にはさらに、個々のキーワードをハッシュ化して得られた０以上の整数で表されるハッシュ化キーワードからなるハッシュ化キーワードリストが格納されている。なお、図７において、個々のハッシュ化キーワードの具体的な数値を示さず「‥‥‥」と略記しているが、キーワードが異なればハッシュ化キーワードは異なるものとなる。

また、図７に示されるように、日本語のキーワードに対しては、３種類の文字コード（Shift_JIS，EUC，UTF-8）でそれぞれハッシュ化したハッシュ化キーワードが格納されている。これにより、マッチングを行う際には、個々のキーワードをその都度ハッシュ化する必要がなく、リクエストのボディデータの文字コード（リクエストヘッダのcharset属性）に対応するハッシュ化キーワードをデータベース１２から取得してそのままマッチングに用いることができる。

〔図６を参照〕
ステップＳ６４：ＣＰＵ１１は、ユーザのハッシュ化キーワードリストからボディデータの文字コードに対応するキーワードを１つ選択し、このハッシュ化キーワードと直前のステップで得られたハッシュ化分割データとのマッチングを行う。マッチングにおいては、文字列が等しければそのハッシュ値も等しいということを前提に、直前のステップ（ステップＳ６３、又は、ステップＳ７２）で得られたハッシュ化データを対象として、ローリングハッシュの手法を用いて、選択されたハッシュ化キーワードと同一のハッシュ値をもつ文字列の検索がなされる。マッチングにおいてハッシュ化キーワードに一致する箇所が見つかれば、そのハッシュ化キーワードに対応するキーワードがハッシュ化される前のデータに含まれていることになる。なお、マッチングの具体例については、別の図面を用いてさらに後述する。

ステップＳ６５～Ｓ６７：ＣＰＵ１１は、選択したハッシュ化キーワードに一致した場合には（ステップＳ６５：Ｙｅｓ）、「規制」を返し（ステップＳ６６）、キーワード判定処理を終了して呼び出し元のフィルタリング判定処理に復帰する。

一方、選択したハッシュ化キーワードに一致しなかった場合には（ステップＳ６５：Ｎｏ）、ＣＰＵ１１は、ハッシュ化キーワードリストに含まれる全てのキーワード（日本語のキーワードの場合は、ボディデータの文字コードに対応するハッシュ化キーワード）とのマッチングを行ったか否かを確認する（ステップＳ６７）。未だマッチングを行っていないキーワードが残っている場合には（ステップＳ６７：Ｎｏ）、ＣＰＵ１１は、ステップＳ６４に戻り、未だマッチングを行っていないキーワードを選択してマッチングを行い、以降の手順を再度実行する。

これに対し、ハッシュ化キーワードリストに含まれる全てのキーワードとのマッチングを行った場合には（ステップＳ６７：Ｙｅｓ）、ＣＰＵ１１は、ステップＳ６８に進む。
ステップＳ６８，Ｓ６９：ＣＰＵ１１は、位置カウンタｃの値が分割データの個数Ｎより小さい（ｃ＜Ｎである）か否かを確認する。ｃ＜Ｎである場合、すなわち未だマッチングの対象となっていない分割データが残っている場合には（ステップＳ６８：Ｙｅｓ）、ＣＰＵ１１は、ステップＳ７０に進む。一方、ｃ＝Ｎである場合、すなわち全ての分割データに対するマッチングが完了した場合には（ステップＳ６８：Ｎｏ）、ＣＰＵ１１は、「許可」を返し（ステップＳ６９）、キーワード判定処理を終了して呼び出し元のフィルタリング判定処理に復帰する。

ステップＳ７０，Ｓ７１：ＣＰＵ１１は、位置カウンタｃに１を加算した上で（ステップＳ７０）、分割データ（ｃ）をハッシュ化し、これをハッシュ化分割データ（ｃ）とする（ステップＳ７１）。例えば、ステップＳ７０においてｃ＝２となった場合には、ステップＳ７１において２番目の分割データである分割データ２がハッシュ化されてハッシュ化分割データ２が生成される。

ステップＳ７２：ＣＰＵ１１は、ユーザのキーワードリストにおける最長のキーワードの文字数（以下、「最長文字数」と称する。）を確認し、ハッシュ化分割データ（ｃ－１）、すなわち１つ前のハッシュ化分割データの末尾から最長文字数分のハッシュデータを取得して、ハッシュ化分割データ（ｃ）の先頭に連結する。例えば、ｃ＝２の場合には、ハッシュ化分割データ１の末尾における最長文字数分のハッシュデータが、ハッシュ化分割データ２の先頭に連結される。その上で、ＣＰＵ１１は、このようにして得られたハッシュ化データを対象として、ステップＳ６４以降の手順を繰り返し実行する。

以上のように、キーワード判定処理においては、リクエストのボディデータ全体における処理の対象とする位置を前方から後方へと徐々に移動させて、ユーザにより予め登録された個々のキーワードに対応するハッシュ化キーワードとのマッチングを行っていき、ハッシュ化キーワードに一致したらその時点で「規制」を返し、最後の位置までマッチングを行っていずれのハッシュ化キーワードにも一致しなかった場合に限り「許可」を返す。

なお、ハッシュ関数のシード値はフィルタリングサーバ１０の起動毎に変更される。これに対応して、データベース１２に格納されているハッシュ化キーワードリストも、フィルタリングサーバ１０の起動毎に更新される。

図８は、キーワード判定処理の各段階でマッチングの対象となるハッシュ化データを説明する図である。

図８中（Ａ）は、ブラウザ４０からのリクエストのボディデータの一例を示している。図示の例においては、ボディデータが３つに分割されて分割データ１～３が生成されている。図中の「～～～」は、分割データを構成する文字の羅列を簡略的に示している。

図８中（Ｂ）は、図８中（Ａ）に示された分割データ１～３で構成されるボディデータに対するキーワード判定処理において、各段階でマッチングの対象となるハッシュ化データを示している。図中の「‥‥‥」は、ハッシュ化データを簡略的に示している。

先ず、位置カウンタｃ＝１のときには、ハッシュ化分割データ１がマッチングの対象となる。次に、ｃ＝２のときには、ハッシュ化分割データ１の末尾における最長文字数分のハッシュデータとハッシュ化分割データ２とを連結して得られるハッシュ化データがマッチングの対象となる。そして、ｃ＝３ときには、ハッシュ化分割データ２の末尾における最長文字数分の文字列とハッシュ化分割データ３とを連結して得られるハッシュ化データがマッチングの対象となる。

例えば、図７に示された学校Ａのキーワードリストにおける最長のキーワードが１０文字であると想定する。この場合、ｃ＝２のときには、ハッシュ化分割データ１の末尾部をなす１０文字分のハッシュデータをハッシュ化分割データ２の先頭に連結したハッシュ化データがマッチングの対象となり、ｃ＝３のときには、ハッシュ化分割データ２の末尾部をなす１０文字分のハッシュデータをハッシュ化分割データ３の先頭に連結したハッシュ化データがマッチングの対象となる。

図９は、キーワードが分割データ１に含まれている場合の例を示している。図９においては、ハッシュ化分割データにおけるキーワードに対応するデータ箇所に網掛けを施している（図１０においても同様）。

例えば、リクエストのボディデータの文字コードが「Shift_JIS」であり、図７に示された学校Ａのキーワードリストのうち、「パパ活」というキーワードが分割データ１に含まれている場合を想定する。キーワード判定処理（図６）の過程では、位置カウンタｃ＝１のときに、ハッシュ化分割データ１とキーワード「パパ活」に対応する「Shift_JIS」のハッシュ化キーワードとのマッチングがなされる（図６中のステップＳ６４）。

具体的には、ハッシュ化分割データ１の配列Ｈから、キーワード「パパ活」の文字数分だけ離れた位置にある２つの要素、すなわち３つ離れた２つの要素を用いて３文字分のハッシュ値が算出され、ハッシュ化キーワードと一致するか否かの確認がなされる。先ず、Ｈ［０］及びＨ［３］の値を用いて先頭から３文字分のハッシュ値が算出されてハッシュ化キーワードと一致するか否かの確認がなされ、一致しなければ、Ｈ［１］及びＨ［４］の値を用いて２文字目から３文字分のハッシュ値が算出されてハッシュ化キーワードと一致するか否かの確認がなされ、一致しなければ、Ｈ［２］及びＨ［５］の値を用いて３文字目から３文字分のハッシュ値が算出されてハッシュ化キーワードと一致するか否かの確認がなされ、‥‥という具合に、位置を１ずつ後方にずらして３文字分のマッチングが次々と行われていく。

そして、ハッシュ化分割データ１を対象としたマッチングの過程でハッシュ化キーワードに一致するため（図６中のステップＳ６５：Ｙｅｓ）、判定結果として「規制」が返される（図６中のステップＳ６６）。その結果、ブラウザ４０からのウェブサーバＷＳに対するアクセスが規制されることとなる。

図１０は、キーワードが分割データ１～２に跨っている場合の例を示す図である。
例えば、リクエストのボディデータの文字コードが「EUC」であり、図７に示された学校Ａのキーワードリストのうち、「コカイン」というキーワードが分割データ１～２に跨っている場合を想定する。キーワード判定処理の過程（図６）では、ハッシュ化分割データとキーワード「コカイン」に対応する「EUC」のハッシュ化キーワードとのマッチングがなされる（図６中のステップＳ６４）。

位置カウンタｃ＝１のときには、ハッシュ化分割データ１の配列Ｈから、キーワード「コカイン」の文字数分だけ離れた位置にある２つの要素、すなわち４つ離れた２つの要素を用いて４文字分のハッシュ値が算出され、ハッシュ化キーワードと一致するか否かの確認がなされる。先ず、Ｈ［０］及びＨ［４］の値を用いて先頭から４文字分のハッシュ値が算出されてハッシュ化キーワードと一致するか否かの確認がなされ、一致しなければ、Ｈ［１］及びＨ［５］の値を用いて２文字目から４文字分のハッシュ値が算出されてハッシュ化キーワードと一致するか否かの確認がなされ、一致しなければ、Ｈ［２］及びＨ［６］の値を用いて３文字目から４文字分のハッシュ値が算出されてハッシュ化キーワードと一致するか否かの確認がなされ、‥‥という具合に、位置を１ずつ後方にずらして４文字分のマッチングが次々と行われていく。図１０に示されるように、ハッシュ化分割データ１には、キーワード「コカイン」に対応する「EUC」のハッシュ化キーワードの一部（先頭の「コ」に対応するハッシュデータ）しか含まれていない。したがって、ｃ＝１のときには、ハッシュ化キーワードに一致しない。

ｃ＝２のときには、ハッシュ化分割データ１の末尾部とハッシュ化分割データ２とを連結したハッシュ化データを対象とし、その配列Ｈから、４つ離れた２つの要素を用いて４文字分のハッシュ値が算出され、上述したような態様により４文字分のマッチングが次々と行われていく。図１０に示されるように、ハッシュ化分割データ１の末尾部には、ハッシュ化キーワードの一部（先頭の「コ」に対応するハッシュデータ）が含まれており、これに続くハッシュ化分割データ２の先頭部には、残りの部分（「カイン」に対応するハッシュデータ）が含まれている。

したがって、ｃ＝２のときに行われるマッチングの過程でハッシュ化キーワードに一致するため（図６中のステップＳ６５：Ｙｅｓ）、判定結果として「規制」が返される（図６中のステップＳ６６）。その結果、ブラウザ４０からのウェブサーバＷＳに対するアクセスが規制されることとなる。

〔本発明の優位性〕
以上のように、上述した実施形態のウェブフィルタリングシステムによれば、以下のような効果が得られる。

（１）予め登録されたキーワードがリクエストのボディデータに含まれるか否かに基づいてアクセスを規制するか否かの判定がなされるため、ユーザ環境下の端末から不適切な情報が送信されるのを未然に防ぐことができる。

（２）判定に用いられるキーワードリストはユーザが自ら登録したものであるため、ユーザの意向に沿って「規制」又は「許可」の判定を下すことができ、個々のユーザが不適切と捉えるキーワード（ユーザ環境下から送信できないようにしたいキーワード）を含む情報の送信を確実に規制することができる。

（３）リクエストのボディデータを分割して生じる個々の分割データをハッシュ化したハッシュ化分割データと予め登録されたキーワードをハッシュ化したハッシュ化キーワードとのマッチングがローリングハッシュの手法を用いて行われるため、マッチングを高速に実行することができ、ハッシュ化しない文字列でマッチングを行う場合と比較して処理速度を上げることができる。

（４）ハッシュ化分割データ１～Ｎと個々のハッシュ化キーワードとのマッチングにおいて、２番目以降のハッシュ化分割データをマッチングの対象とする場合には、そのハッシュ化分割データ（例えば、ハッシュ化分割データ２）の先頭に、１つ前のハッシュ化分割データ（例えば、ハッシュ化分割データ１）の末尾から取得した最長キーワードの文字数分のハッシュデータが連結され、１つ前のハッシュ化分割データの末尾部もマッチングの対象に含まれるため、キーワードが２つの分割データに跨って存在している場合でも、その情報の送信を確実に規制することができる。

（５）キーワードリストに対応するハッシュ化キーワードリストがデータベース１２に予め格納されていることから、マッチングを行う度に個々のキーワードをハッシュ化する必要がないため、その都度キーワードをハッシュ化する場合と比較してマッチングの効率を向上することができる。

本発明は、上述した実施形態に制約されることなく、種々に変形して実施することが可能である。

上述した実施形態においては、データベース１２がフィルタリングサーバ１０に設けられているが、データベースの設置場所はフィルタリングサーバ１０上に限定されない。例えば、フィルタリングサーバ１０が接続可能な別のサーバ上に設けてもよいし、異なるサーバ上に設けられた複数のデータベースを用途に応じて使い分けてもよい。或いは、キーワードリストやハッシュ化キーワードリストを、データベース１２に代えてフィルタリングサーバ１０上の設定ファイル等に格納してもよい。

上述した実施形態においては、フィルタリングサーバ１０のユーザとして学校や企業等の団体を想定しているが、利用形態はこれに限定されない。例えば、個人をフィルタリングサーバ１０のユーザとし、その個人の家庭環境下にある端末からウェブサーバＷＳにアクセスする際に、その個人が自ら設定したキーワードリストに基づいて通信の制御を行ってもよい。これにより、その個人の家族が不適切な情報を送信するのを未然に防ぐことができる。

その他、実施形態のウェブフィルタリングシステム１を説明する過程で挙げた構成や数値等は、あくまで一例であり、本発明の実施に際して適宜に変形が可能であることは言うまでもない。

１ ウェブフィルタリングシステム
１０ フィルタリングサーバ
１１ ＣＰＵ （判定部）
１２ データベース （記憶部）
２０ プロキシサーバ
３０ リダイレクトサーバ
４０ ブラウザ
５０ アプリケーション
６０ ブラウザ拡張機能

Claims (2)

1. ユーザにより予め登録された１以上のキーワードが格納された記憶部と、
   ウェブサーバに対するブラウザからのリクエストの規制に関する問い合わせを受け付けると、前記リクエストのボディデータに前記キーワードが含まれるか否かに基づいて判定を行い、前記問い合わせの送信元に判定結果を返す判定部と
   を備え、
   前記判定部は、
   前記ボディデータを所定のサイズ毎に分割し、個々の分割データをハッシュ化して得られるハッシュ化分割データと前記キーワードをハッシュ化して得られるハッシュ化キーワードとのマッチングを行うことにより、前記ボディデータに前記キーワードが含まれるか否かを確認し、２番目以降のハッシュ化分割データをマッチングの対象とする場合には、当該ハッシュ化分割データの先頭に、１つ前のハッシュ化分割データの末尾部をなす、ユーザにより登録された最長のキーワードの文字数分のハッシュデータを連結することを特徴とするウェブフィルタリングシステム。
2. 請求項１に記載のウェブフィルタリングシステムにおいて、
   前記記憶部は、
   前記キーワード及びこれに対応する前記ハッシュ化キーワードが予め格納されていることを特徴とするウェブフィルタリングシステム。