情報処理装置および情報処理方法、プログラム
【課題】 閲覧者によるＷＥＢサイトへのアクセスを管理する監査者が、効率よくアクセスログを管理することができる仕組みを提供すること
【解決手段】 端末装置からウェブサーバに対して送信されるデータ取得要求の中継制御を行い、当該中継結果を端末装置に送信する情報処理装置であって、データ取得要求に取得要求元ＵＲＬが含まれる場合には、当該データ取得要求が送信された時刻と当該取得要求元ＵＲＬに対してデータ取得要求が送信された時刻との時間差を算出し、算出された時間差が予め設定された時間以内である場合には、当該データ取得要求にかかるアクセスは送信しない。
【解決手段】 端末装置からウェブサーバに対して送信されるデータ取得要求の中継制御を行い、当該中継結果を端末装置に送信する情報処理装置であって、データ取得要求に取得要求元ＵＲＬが含まれる場合には、当該データ取得要求が送信された時刻と当該取得要求元ＵＲＬに対してデータ取得要求が送信された時刻との時間差を算出し、算出された時間差が予め設定された時間以内である場合には、当該データ取得要求にかかるアクセスは送信しない。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、内部ネットワークの端末装置と、インターネット等の外部ネットワーク上のサーバ装置との間の通信の中継制御にかかる記録の管理技術に関する。
【背景技術】
【０００２】
ネットワーク技術の発展によって、情報のやり取りが非常に簡便に、且つ効率よく行うことが可能となっている。例えば、会議に使用する資料を電子メールに添付して参加者に前もって送付したりすることが、手間も煩わしさもなく行うことが可能となっている。
【０００３】
ただ、このようにネットワーク技術が発達し、情報のやりとりが容易に行われるようになった反面、重要な機密情報が簡単に外部に流出してしまう危険性や外部からコンピュータウイルス等の有害情報が流入してしまう危険性が高まっている。
【０００４】
そこで、企業等では、業務とは直接関係のない情報を提供しているサーバへのアクセスを禁止する等の対策を講じている。
【０００５】
例えば、特定のＵＲＬに対するアクセスを禁止する通信制御であるＵＲＬフィルタリングを行う機器を導入し、アクセスが許可されないＵＲＬに対するリクエストを当該ＵＲＬが示す情報資源を提供する外部サーバに転送しないことで、当該ＵＲＬが示す情報資源にアクセスできないようにしている。
【０００６】
ＵＲＬフィルタリングを行う場合には、アクセスを許可するＵＲＬのリストであるホワイトリストや、アクセスを禁止するＵＲＬのリストであるブラックリストを作成し、それらに対する制御を行うことになる。つまり、ホワイトリストに登録されているＵＲＬに対するリクエストはその通信を中継し、ブラックリストに登録されているＵＲＬに対するリクエストはその通信を中継しないといった制御を行うことになる。
【０００７】
例えば、特許文献１には、閲覧制限が付されたＷＥＢサイトに対してユーザから閲覧要求があった場合、監査者に対して閲覧の記録が通知される仕組みが開示されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００８−２３４３３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、閲覧が制限されたＷＥＢサイトに対するアクセス記録についてすべてが通知されることとなると、非常に大量の記録が通知されることになってしまう。
【００１０】
特に、ユーザ指定のＵＲＬだけでなく、複数のＵＲＬアクセスからページ全体が構成されるサイトでは、画像や動画などのファイル取得先が別ＵＲＬで指定されている場合がある。このような場合において、「ユーザが指定したＵＲＬ自体は閲覧許可されているが、そこからリンクされている画像や動画などのファイル取得先であるＵＲＬについては閲覧制限の対象となっている」という場合には、大量の規制ログが通知されてしまう。
【００１１】
このような画像や動画に対するアクセスは、閲覧者が故意に（意図的に）アクセスをしている訳ではないため、このようなアクセス記録は適切な閲覧制限を行う上で有用な記録ではない。
【００１２】
そのため、監査者は、適切なアクセス制限をするために、大量のログの中から、ユーザが故意に（意図的に）アクセスしたログを抽出しなければならないといった手間が生じてしまう。
【００１３】
そこで、本発明は、閲覧者によるＷＥＢサイトへのアクセスを管理する監査者が、効率よくアクセスログを管理することができる仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明の情報処理装置は、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断手段と、前記参照元判断手段により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知手段と、を備えることを特徴とする。
を特徴とする。
【００１５】
また、本発明の情報処理方法は、情報処理装置の取得手段が、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得工程と、前記情報処理装置の参照元判断手段が、前記取得工程により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断工程と、前記情報処理装置の通知手段が、前記参照元判断工程により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知工程と、を備えることを特徴とする。
を特徴とする。
【００１６】
また、本発明のプログラムは、情報処理装置を、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断手段と、前記参照元判断手段により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知手段として機能させることを特徴とする。
【発明の効果】
【００１７】
本発明によれば、閲覧者によるＷＥＢサイトへのアクセスを管理する監査者が、効率よくアクセスログを管理することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】本発明の情報処理システムの構成の一例を示す図である
【図２】図１のプロキシサーバ１０１として適用可能な情報処理装置のハードウエア構成の一例を示す図である
【図３】第１および第２の実施形態における、プロキシサーバ１０１により実行されるアクセス制御処理を示すフローチャートである
【図４】アクセスルールテーブルの一例を示す図である
【図５】アクセスログテーブルの一例を示す図である
【図６】本発明におけるクライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれの処理の流れを示す図である
【図７】本発明におけるクライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれの処理の流れを示す図である
【図８】第１の実施形態においてプロキシサーバ１０１により実行される、アクセスログをクライアントＰＣに表示する処理を示すフローチャートである
【図９】第１の実施形態においてクライアントＰＣ１０２に表示される条件設定画面の一例を示す図である
【図１０】ステップＳ８０３、ステップＳ１３０３においてクライアントＰＣ１０２に表示されるアクセスログ表示画面の一例を示す図である
【図１１】第１の実施形態（ステップＳ８１１）、第４の実施形態においてクライアントＰＣ１０２に表示されるアクセスログ表示画面の一例を示す図である
【図１２】プロキシサーバ１０１の機能構成を示すブロック図である。
【図１３】第２の実施形態においてプロキシサーバ１０１により実行される、アクセスログをクライアントＰＣに表示する処理を示すフローチャートである
【図１４】第２の実施形態（ステップＳ１３０９）、第３の実施形態においてクライアントＰＣ１０２に表示されるアクセスログ表示画面の一例を示す図である
【図１５】第３の実施形態においてプロキシサーバ１０１により実行される、アクセス制御処理およびアクセスログの登録処理を示すフローチャートである
【図１６】第４の実施形態においてプロキシサーバ１０１により実行されるアクセス制御処理およびアクセスログの登録処理を示すフローチャートである
【図１７】ＨＴＴＰリクエストデータの構成を示す図である
【図１８】ステップＳ１５０８において登録されるアクセスログを示す図である
【図１９】ステップＳ１６０９において登録されるアクセスログを示す図である
【図２０】ステップＳ１６０８において判断基準として用いられる閾値が登録されたテーブルである
【図２１】図２０に示す閾値を設定する画面の一例を示す図である
【図２２】第３、第４の実施形態においてプロキシサーバ１０１がクライアントＰＣ１０２に対してアクセスログを送信する処理を示すフローチャートである
【図２３】第３、第４の実施形態における検索条件設定画面の一例を示す図である
【発明を実施するための形態】
【００１９】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００２０】
図１は、本発明に係る情報処理システムのシステム構成の一例を示す図である。
【００２１】
図１に示すように、本実施形態に係る情報処理システムは、プロキシサーバ１０１、クライアントＰＣ１０２−１乃至１０２−３（以後、まとめて「クライアントＰＣ１０２」とする）、ＬＡＮ１０３、広域ネットワーク１０４、ウェブサーバ１０５−１乃至１０５−３（以後、まとめて「ウェブサーバ１０５」とする）を備えている。
【００２２】
以下、本発明の情報処理システムを構成する各装置について説明する。
【００２３】
プロキシサーバ１０１は、本発明の情報処理装置として機能する装置であり、クライアントＰＣ１０２とウェブサーバ１０５との間のデータ通信を中継する。また、プロキシサーバ１０１は、クライアントＰＣ１０２とウェブサーバ１０５との間でやりとりされるデータに対して、当該データの中継を許可する（中継する）か、または拒否する（中継しない）かといった中継制御ルールに従い、データの通信制御を行う機能を有している。
【００２４】
また、データの通信制御に関するログを記憶する機能を有している。
【００２５】
クライアントＰＣ１０２は、ウェブサーバ１０５が提供する各種のサービス（ホームページの閲覧等）を利用するユーザが使用する端末装置である。また、プロキシサーバ１０１に記憶されたデータ通信制御に関するログを表示する機能を有する。
【００２６】
ＬＡＮ１０３は、プロキシサーバ１０１、クライアントＰＣ１０２を相互にデータ通信可能に接続するネットワークである。
【００２７】
ウェブサーバ１０５は、各種のウェブサービスを提供するサービス事業者により設置されるサーバ装置である。ここで提供されるサービスとしては、例えばホームページの閲覧サービスや、商品の販売サービス、航空券やホテル等の予約サービスなどがあるが、これに限定されない。
【００２８】
プロキシサーバ１０１とウェブサーバ１０５は、インターネット等の広域ネットワーク１０４を介して、相互にデータ通信可能に接続されている。
以上が本発明の情報処理システム構成の一例の説明である。
【００２９】
以下、図２を用いて、図１に示したプロキシサーバ１０１に適用可能な情報処理装置のハードウエア構成の一例について説明する。
【００３０】
図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な各種プログラム等が記憶されている。
【００３１】
２０２はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
【００３２】
また、２０５は入力コントローラで、入力装置２０９等からの入力を制御する。２０６はビデオコントローラで、液晶ディスプレイ等のディスプレイ装置２１０への表示を制御する。なお、ディスプレイ装置は、液晶ディスプレイに限られず、ＣＲＴディスプレイなどであっても良い。これらは必要に応じてクライアントが使用するものである。
【００３３】
２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶するハードディスク（ＨＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００３４】
２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したＬＡＮ１０４）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。
【００３５】
なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ装置２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ装置２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３６】
ハードウエア上で動作する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００３７】
次に図３を用いて、本発明の第１および第２の実施形態においてプロキシサーバ１０１が行うアクセス制御処理について説明する。
【００３８】
なお、図３のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００３９】
ステップＳ３０１では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータからアクセス先となるＵＲＬを取得する。
【００４０】
ステップＳ３０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ３０１で取得したアクセス先ＵＲＬがアクセスルールテーブル（図４）に存在するかを判定する。すなわち、当該アクセス先ＵＲＬについて、いずれかのアクセスルールが適用されるか否かを判定する。
【００４１】
アクセスルールテーブルに存在すると判定された場合（ステップＳ３０２：ＹＥＳ）は、処理をステップＳ３０３に移行する。
【００４２】
他方、アクセスルールテーブルに存在しないと判定された場合（ステップＳ３０２：ＮＯ）は、処理をステップＳ３０６に移行する。
【００４３】
ステップＳ３０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ３０２で適用されると判定されたアクセスルールについて、その動作がアクセスを禁止（データ中継を許可しない）であるか否かを判定する。
【００４４】
ステップＳ３０３においてアクセスを許可すると判定された場合（ステップＳ３０３：許可）は、処理をステップＳ３０６に移行する。
【００４５】
他方、ステップＳ３０３においてアクセスを禁止すると判定された場合（ステップＳ３０３：禁止）は、処理をステップＳ３０４に移行する。
【００４６】
ステップＳ３０４では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣから送信されたＵＲＬに対するアクセスが禁止された旨の結果をアクセスログテーブル（図５）に記録する。
【００４７】
この際、アクセスログテーブルには、アクセスが禁止された旨の結果（ルール結果）だけでなく、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣを識別する情報（ＩＰアドレス等）（クライアントＩＰアドレス）、アクセス先ＵＲＬ等についても記録される。
【００４８】
また、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに「ＲｅｆｅｒｅｒＵＲＬ（参照元ＵＲＬ）」が含まれる場合には、当該ＲｅｆｅｒｅｒＵＲＬもあわせて記録される。
【００４９】
ステップＳ３０５では、プロキシサーバ１０１のＣＰＵ２０１は、リクエスト元であるクライアントＰＣ１０２に対してアクセスが禁止された旨の結果を示すＨＴＴＰレスポンスデータを送信する。
そして本フローチャートに示す処理を終了する。
【００５０】
ステップＳ３０６以降は、ステップＳ３０２においてクライアントＰＣ１０２から送信されたアクセス先ＵＲＬがアクセスルールに該当しなかった場合、または、該当するアクセスルールに設定された動作が「禁止」以外であった場合の処理である。
【００５１】
ステップＳ３０６では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ３０１で取得したアクセス先ＵＲＬが示すウェブサーバ１０５にアクセスをする。
【００５２】
ステップＳ３０７では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣから送信されたＵＲＬに対するアクセスが許可された旨の結果をアクセスログテーブル（図５）に記録する。この際、ステップＳ３０４における処理と同様に、アクセスログテーブルに対して、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣのＩＰアドレス（クライアントＩＰアドレス）、アクセス先ＵＲＬについても記録される。
【００５３】
また、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに「ＲｅｆｅｒｅｒＵＲＬ」が含まれる場合には、当該ＲｅｆｅｒｅｒＵＲＬもあわせて記録される。
【００５４】
ステップＳ３０８では、プロキシサーバ１０１のＣＰＵ２０１は、ウェブサーバ１０５からレスポンスデータを取得し、当該レスポンスデータをリクエスト元であるクライアントＰＣ１０２に送信する。
そして、本フローチャートに示す処理を終了する。
【００５５】
なお、本実施形態では、アクセスルールテーブルに設定されていないＵＲＬへのアクセスについては、アクセスを許可するように構成しているが、デフォルト処理としてアクセス禁止として設定をしておき、その設定に従って処理を行うように構成しても良い。
【００５６】
以上の処理により、プロキシサーバ１０１において実行された、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに対する処理を記録することができる。
【００５７】
次に、図６を用いて、本発明の第１および第２の実施形態におけるクライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれの処理の流れを説明する。
【００５８】
なお、図６では、「複数のＵＲＬアクセスからページ全体が構成され、ユーザにより指定されたＵＲＬ自体はアクセスが許可されるが、そこからリンクされている画像のファイル取得先であるＵＲＬについてはアクセスが禁止される場合」の処理について説明する。
【００５９】
ステップＳ６０１では、クライアントＰＣ１０２からプロキシサーバ１０１に対してＨＴＴＰリクエストデータが送信される（図３におけるステップＳ３０１に相当）。図６に示す例では、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータ（アクセス先ＵＲＬ）は「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるとする。
【００６０】
そして、ステップＳ６０２では、プロキシサーバ１０１がステップＳ６０１で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。
【００６１】
図６に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるため、アクセスルールテーブルにおけるルールＩＤ：３（「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「許可」であるので、ステップＳ６０２では、クライアントＰＣ１０２から送信されたデータの中継は許可される（図３のステップＳ３０３：許可に相当）。
【００６２】
ステップＳ６０３では、プロキシサーバ１０１が「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」が示すウェブサーバ１０５へアクセスをする。そして、ステップＳ６０４でウェブサーバ１０５は、ステップＳ６０３のアクセスに対するレスポンスデータをプロキシサーバ１０１に送信し、プロキシサーバ１０１は当該レスポンスデータを取得する（図３のステップＳ３０６に相当）。
【００６３】
ステップＳ６０５では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」に対するアクセスが許可された旨をアクセスログテーブルに記録する（図３のステップＳ３０７に相当）。なお、ステップＳ６０５で記録されるアクセスログは、図５に示すアクセスログテーブルの「ログＩＤ：３」に示すログにあたる。
【００６４】
ステップＳ６０６では、プロキシサーバ１０１は、ウェブサーバ１０５から取得したレスポンスデータをクライアントＰＣ１０２に対して送信する（図３のステップＳ３０８に相当）。
【００６５】
そして、クライアントＰＣ１０２では、ステップＳ６０６でプロキシサーバ１０１から送信されたレスポンスデータを解析し、ウェブページ内に含まれる画像データの取得先であるＵＲＬを取得する。なお、図６に示す例では、レスポンスデータを解析して得られたＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ」であるとする。
【００６６】
ステップＳ６０７では、クライアントＰＣ１０２から、取得したＵＲＬ（ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ）をアクセス先とするＨＴＴＰリクエストデータがプロキシサーバ１０１に送信される（図３のステップＳ３０１に相当）。このとき、ＨＴＴＰリクエストデータは、ＲｅｆｅｒｅｒＵＲＬとしてリンク元のウェブページのＵＲＬである「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」を有する。
【００６７】
そして、ステップＳ６０８では、プロキシサーバ１０１がステップＳ６０７で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。
【００６８】
図６に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ」であるため、アクセスルールテーブルにおけるルールＩＤ：１（「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「禁止」であるので、ステップＳ６０８では、クライアントＰＣから送信されたデータの中継は行われない（図３のステップＳ３０３：禁止に相当）。
【００６９】
ステップＳ６０９では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ」に対するアクセスが禁止された旨をアクセスログテーブルに記録する（図３のステップＳ３０３０４に相当）。なお、この際、アクセスログテーブルには、ＲｅｆｅｒｅｒＵＲＬである「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」があわせて記録される。なお、ステップＳ６０９で記録されるログは、図５に示すアクセスログテーブルの「ログＩＤ：４」に示すログにあたる。
【００７０】
そして、ステップＳ６１０において、プロキシサーバ１０１からクライアントＰＣ１０２に対して、アクセスが禁止された旨の情報が送信される（図３のステップＳ３０５に相当）。
【００７１】
次に、図７を用いて、独立した２つのウェブページへのアクセスが共にアクセス禁止をされるケースについて、クライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれで実行される処理の流れを説明する。
【００７２】
ステップＳ７０１では、クライアントＰＣ１０２からプロキシサーバ１０１に対してＨＴＴＰリクエストデータが送信される（図３におけるステップＳ３０１に相当）。図７に示す例では、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータ（アクセス先ＵＲＬ）は「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるとする。
【００７３】
そして、ステップＳ７０２では、プロキシサーバ１０１がステップＳ７０１で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。
【００７４】
図７に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるため、アクセスルールテーブルにおけるルールＩＤ：１（「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「禁止」であるので、ステップＳ７０２では、クライアントＰＣ１０２から送信されたデータの中継は行われない（図３のステップＳ３０３：禁止に相当）。
【００７５】
ステップＳ７０３では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」に対するアクセスが禁止された旨をアクセスログテーブルに記録する（図３のステップＳ３０３０４に相当）。なお、ステップＳ７０３で記録されるログは、図５に示すアクセスログテーブルの「ログＩＤ：１」に示すログにあたる。
【００７６】
そして、ステップＳ７０４において、プロキシサーバ１０１からクライアントＰＣ１０２に対して、アクセスが禁止された旨の情報が送信される（図３のステップＳ３０５に相当）。
【００７７】
ステップＳ７０５では、クライアントＰＣ１０２からプロキシサーバ１０１に対してＨＴＴＰリクエストデータが送信される（図３におけるステップＳ３０１に相当）。図７に示す例では、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータ（アクセス先ＵＲＬ）は「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍａｉｎ．ｈｔｍｌ」であるとする。
【００７８】
そして、ステップＳ７０６では、プロキシサーバ１０１がステップＳ７０５で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。
【００７９】
図７に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍａｉｎ．ｈｔｍｌ」であるため、アクセスルールテーブルにおけるルールＩＤ：１（「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「禁止」であるので、ステップＳ７０６では、クライアントＰＣ１０２から送信されたデータの中継は行われない（図３のステップＳ３０３：禁止に相当）。
【００８０】
ステップＳ７０７では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍａｉｎ．ｈｔｍｌ」に対するアクセスが禁止された旨をアクセスログテーブルに記録する（図３のステップＳ３０３０４に相当）。なお、ステップＳ７０７で記録されるログは、図５に示すアクセスログテーブルの「ログＩＤ：２」に示すログにあたる。このとき、ステップＳ７０５で送信されたＨＴＴＰリクエストデータにはＲｅｆｅｒｅｒＵＲＬがないため、アクセスログテーブルにもＲｅｆｅｒｅｒＵＲＬは記録されない。
【００８１】
そして、ステップＳ７０８において、プロキシサーバ１０１からクライアントＰＣ１０２に対して、アクセスが禁止された旨の情報が送信される（図３のステップＳ３０５に相当）。
【００８２】
次に、図８を用いて、本発明の第１の実施形態におけるプロキシサーバ１０１がアクセスログテーブルに記録されたアクセスログのうち、アクセスが禁止されたログをクライアントＰＣ１０２に表示する処理について説明する。
【００８３】
なお、図８のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００８４】
ステップＳ８０１では、プロキシサーバ１０１のＣＰＵ２０１は、ユーザからアクセスログの検索条件の設定を受け付ける。
【００８５】
なお、検索条件の設定については、クライアントＰＣ１０２に表示される検索条件設定画面（図９）を介して受け付ける。
【００８６】
ここで、図９に一例を示す検索条件設定画面について説明する。
【００８７】
図９に示す画面では、アクセスログを検索する検索条件として、アクセス時刻の時刻条件（期間や時間範囲）や、「自動除外解析」のＯＮ／ＯＦＦおよび「自動除外解析時間」の設定が可能である。
【００８８】
「自動除外解析」がＯＦＦである場合には、時刻条件により検索されたアクセスログの全てが表示対象となる。
【００８９】
「自動除外解析」がＯＮである場合には、時刻条件により検索されたアクセスログのうち、ＲｅｆｅｒｅｒＵＲＬが記録されていないログ、および、ＲｅｆｅｒｅｒＵＲＬが記録されているログのうち当該ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻から「自動除外解析時間」で設定された時間を経過した後にアクセスされたログが表示対象となる。なお、自動除外解析時間については、ユーザにより任意に設定が可能である。
【００９０】
図９に示す例では、アクセスログテーブルに記録されたアクセス時刻が「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であり、「００時００分〜２４時００分」まで（終日）のログが検索されることを示している。
【００９１】
また、自動除外解析がＯＮである（チェックボックスにチェックがされている）ため、上述の通り、時刻条件により検索されたアクセスログのうち、ＲｅｆｅｒｅｒＵＲＬが記録されていないログ、および、ＲｅｆｅｒｅｒＵＲＬが記録されているログのうち当該ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻から１０秒以上経過した後にアクセスされたログが表示対象となる。
【００９２】
ステップＳ８０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０１で設定された条件のうち、自動除外解析がＯＮに設定されているか否か（チェックボックスにチェックが入れられているか否か）を判断する。
【００９３】
ＯＦＦに設定されている場合（ステップＳ８０２：ＯＦＦ）は、処理をステップＳ８０３に移行する。
【００９４】
ＯＮに設定されている場合（ステップＳ８０３：ＯＮ）は、処理をステップＳ８０４に移行する。
【００９５】
ステップＳ８０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０１で設定された時刻条件により検索される禁止アクセスログ（ルール結果が禁止として記録されているアクセスログ）の全てをクライアントＰＣ１０２に表示するべく、クライアントＰＣ１０２に送信する。
【００９６】
ステップＳ８０４では、プロキシサーバ１０１のＣＰＵ２０１は、アクセスログテーブルに記録されたアクセスログのうち最初のアクセスログを読み込む。
【００９７】
ステップＳ８０５では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログの「ルール結果」が禁止であるか否かを判断する。
【００９８】
禁止であると判断されると（ステップＳ８０５：ＹＥＳ）、処理をステップＳ８０６に移行する。
【００９９】
禁止ではないと判断されると（ステップＳ８０５：ＮＯ）、処理をステップＳ８１２に移行する。すなわち、当該アクセスログは表示対象から除外される。
【０１００】
ステップＳ８０６では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログのアクセス時刻が、ステップＳ８０１で設定された時刻条件を満たすか否かを判断する。すなわち、図９の例においては、当該アクセスログのアクセス時刻が「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であるか否かを判断する。
【０１０１】
時刻条件を満たすと判断された場合（ステップＳ８０６：ＹＥＳ）は、処理をステップＳ８０７に移行する。
【０１０２】
時刻条件を満たさないと判断された場合（ステップＳ８０６：ＮＯ）は、処理をステップＳ８１２に移行する。すなわち、当該アクセスログは表示対象から除外される。
【０１０３】
ステップＳ８０７では、ステップＳ８０４で読み込まれたアクセスログのＨＴＴＰメソッドがＧＥＴメソッドであるか否かを判断する。
【０１０４】
ＧＥＴメソッドであると判断されると（ステップＳ８０７：ＹＥＳ）、処理をステップＳ８０８に移行する。
【０１０５】
ＧＥＴメソッドではないと判断されると（ステップＳ８０７：ＮＯ）、処理をステップＳ８１１に移行する。すなわち、当該アクセスログを表示対象としてクライアントＰＣ１０２へ表示する。
【０１０６】
ステップＳ８０８では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。
【０１０７】
ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ８０８：ＹＥＳ）は、処理をステップＳ８０９に移行する。
【０１０８】
ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ８０８：ＮＯ）は、処理をステップＳ８１１に移行する。すなわち、当該アクセスログを表示対象としてクライアントＰＣ１０２へ表示する。
【０１０９】
ステップＳ８０９では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログに記録されたＲｅｆｅｒｅｒＵＲＬに対するアクセスにかかるアクセスログであり、かつ、ステップＳ８０４で読み込んだアクセスログの「クライアントＩＰアドレス」と同じクライアントＩＰアドレスが記録されたアクセスログを取得する。
【０１１０】
なお、本実施例では、同一性の判断にアクセス元のクライアントＰＣのＩＰアドレスを用いたが、これに限られるものではなく、他の基準により同一性を判断しても良い。
【０１１１】
ステップＳ８１０では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログのアクセス時刻が、ステップＳ８０９で取得したアクセスログのアクセス時刻（ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻）からステップＳ８０１で設定された自動除外解析時間を経過した時刻であるか否かを判断する。すなわち、ステップＳ８０４で読み込んだアクセスログにかかるアクセスが、ＲｅｆｅｒｅｒＵＲＬへのアクセスから自動除外解析時間が経過した後のアクセスであるか否かを判断する。
【０１１２】
ＲｅｆｅｒｅｒＵＲＬへのアクセスから自動除外解析時間を経過した後のアクセスであると判断された場合（ステップＳ８１０：ＹＥＳ）は、処理をステップＳ８１１に移行する。すなわち、当該アクセスログを表示対象としてクライアントＰＣ１０２へ表示する。
【０１１３】
ＲｅｆｅｒｅｒＵＲＬへのアクセスから自動除外解析時間を経過する前のアクセスであると判断された場合（ステップＳ８１０：ＮＯ）は、処理をステップＳ８１２に移行する。すなわち、当該アクセスログは表示対象から除外される。
【０１１４】
ステップＳ８１１では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログをクライアントＰＣ１０２に表示するべく、クライアントＰＣ１０２に送信する。
【０１１５】
ステップＳ８１２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログがアクセスログテーブルに記録されたアクセスログのうち最後のアクセスログであるか否かを判断する。
【０１１６】
最後のアクセスログであると判断されると（ステップＳ８１２：ＹＥＳ）、本フローチャートに示す処理を終了する。
【０１１７】
最後のアクセスログではないと判断されると（ステップＳ８１２：ＮＯ）、処理をステップＳ８０４に移行し、次のアクセスログを１行読み込む。
【０１１８】
以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを監査者へ通知することが可能なる。これにより、適切なログ管理が可能となる。
【０１１９】
具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、意図的なアクセスではない可能性が高い。ただ、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスのすべてが意図的ではないアクセスとは言えず、ＲｅｆｅｒｅｒＵＲＬが記録されていたとしても意図的なアクセスである可能性はある。そこで、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮し、ＲｅｆｅｒｅｒＵＲＬが記録されたアクセスであっても意図的なアクセスであるか否かを判断する。
【０１２０】
すなわち、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間が短い場合には、自動的にブラウザがリクエストをしたログである可能性が高い。他方、ＲｅｆｅｒｅｒＵＲＬへのアクセスから一定時間が経過した後のアクセスについては、ユーザによる意図的なアクセス（リンク先をクリックした等）である可能性が高いといえる。そのため、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮することで、意図的なアクセスであるか否かを適切に判断することが可能となる。
【０１２１】
このように、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては通知・表示をしないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。その結果、効率的なログ管理が可能となる。
【０１２２】
さらに、本実施形態においては、ステップＳ８０７においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、表示対象ログとしている。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）場合については、ＲｅｆｅｒｅｒＵＲＬの有無や、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間に関わらず、意図的なアクセスであることが多いためである。このステップＳ８０７における判断処理により、監査に有用なログを表示させることが可能となる。
【０１２３】
なお、本発明の目的は、監査に有用ではないアクセスログを表示させないことである。そのため、ステップＳ８０７における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。
【０１２４】
次に、図１０および図１１を用いて、図８のフローチャートに示す処理によりクライアントＰＣ１０２に表示されるアクセスログについて具体的に説明する。
【０１２５】
図１０に示す画面は、図８のステップＳ８０３においてクライアントＰＣ１０２に表示される画面である。すなわち、アクセスログテーブル（図５）に記録されたアクセスログのうち、ルール結果が禁止であり、かつ、ステップＳ８０１で図９に示す検索条件設定画面を介して設定された時刻条件を満たすアクセスログの全てが表示されている。
【０１２６】
図１０に示す画面では、アクセスログテーブルにおけるログＩＤ：１、２、４、５、６、８のアクセスログが表示されている。
【０１２７】
図１１に示す画面は、図８のステップＳ８１１においてクライアントＰＣ１０２に表示される画面である。
【０１２８】
以下、アクセスログテーブル（図５）および図８のフローチャートを用いて、図１１に表示されるアクセスログについて詳細に説明する。なお、時刻条件としては、図９に示す条件（「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であり、「００時００分〜２４時００分」まで）であるとする。
【０１２９】
アクセスログテーブルに示す「ログＩＤ：１」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：なし」である。そのため、図８におけるステップＳ８０８でＮＯと判断され、ステップＳ８１１にて表示対象とされる。
【０１３０】
「ログＩＤ：２」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：なし」であるため、ログＩＤ：１のアクセスログと同様に表示対象とされる。
【０１３１】
「ログＩＤ：３」のアクセスログについては、「ルール結果：許可」であるため、図８のステップＳ８０５においてＮＯと判断され、表示対象から除外される。
【０１３２】
「ログＩＤ：４」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：あり」、「ＲｅｆｅｒｅｒＵＲＬへのアクセスからの時間差：自動除外解析時間以内」であるため、図８のステップＳ８１０でＮＯと判断され、表示対象から除外される。
【０１３３】
なお、ＲｅｆｅｒｅｒＵＲＬへのアクセスにかかるアクセスログは、「ログＩＤ：３」のログであり、当該アクセスからの時間差は０秒である。そのため、自動除外解析時間（１０秒）以内のアクセスであると判断される。
【０１３４】
「ログＩＤ：５」のアクセスログについては、ログＩＤ：４のアクセスログと同様に表示対象から除外される。
【０１３５】
なお、ＲｅｆｅｒｅｒＵＲＬへのアクセスにかかるアクセスログは、「ログＩＤ：３」のログであり、当該アクセスからの時間差は２秒である。そのため、自動除外解析時間（１０秒）以内のアクセスであると判断される。
【０１３６】
「ログＩＤ：６」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：あり」、「ＲｅｆｅｒｅｒＵＲＬへのアクセスからの時間差：自動除外解析時間経過後」、であるため、ステップＳ８１０でＹＥＳと判断され、ステップＳ８１１にて表示対象とされる。
【０１３７】
なお、ＲｅｆｅｒｅｒＵＲＬへのアクセスにかかるアクセスログは、「ログＩＤ：３」のログであり、当該アクセスからの時間差は２０秒である。そのため、自動除外解析時間（１０秒）を経過した後のアクセスであると判断される。
【０１３８】
「ログＩＤ：７」のアクセスログについては、「ルール結果：許可」であるため、図８のステップＳ８０５でＮＯと判断され、表示対象から除外される。
【０１３９】
「ログＩＤ：８」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＰＯＳＴ」であるため、図８のステップＳ８０７でＮＯと判断されステップＳ８１１で表示対象とされる。
【０１４０】
図１２は、本発明におけるプロキシサーバ１０１の機能構成を示すブロック図である。
【０１４１】
取得部１２０１は、クライアントＰＣ１０２からウェブサーバに対して送信されるデータ取得要求（リクエストデータ）を取得する。
【０１４２】
参照元判断手段１２０２は、取得部１２０１が取得したリクエストデータに参照元ＵＲＬが含まれているか否かを判断する。
【０１４３】
通知部１２０３は、第１決定部１２０５、第２決定部１２０８により通知すると決定されたアクセスログを監査者に対して通知する。
【０１４４】
時間差算出部１２０４は、取得部１２０１が取得したリクエストデータがクライアントＰＣ１０２から送信された時刻と、当該リクエストデータに含まれる参照元ＵＲＬに対してリクエストデータが送信された時刻との時間差を算出する。
【０１４５】
第１決定部１２０５は、時間差算出部１２０４により算出された時間差に応じて、監査者に対してアクセスログを通知するか否かを決定する。
【０１４６】
時間差設定受付部１２０６は、第１決定部１２０５がアクセスログを通知するか否かを決定するための基準となる時間差の設定を受け付ける。
【０１４７】
中継制御部１２０７は、クライアントＰＣ１０２から送信されるリクエストデータの中継の可否を決定する。
【０１４８】
第２決定部１２０８は、中継制御部１２０７により決定された中継の可否により、当該リクエストデータにかかるアクセスログを監査者に通知するか否かを決定する。
【０１４９】
記憶部１２０９は、クライアントＰＣ１０２から送信されたリクエストデータをログとして記憶する。
【０１５０】
検索条件受付部１２１０は、記憶部１２０９に記憶されたログデータを検索するための条件の設定を監査者等から受け付ける。
【０１５１】
抽出部１２１１は、検索条件受付部１２１０で受け付けた検索条件に合致するログデータを、記憶部１２０９に記憶されたログデータから抽出する。
＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。
【０１５２】
第１の実施形態においては、自動除外解析がＯＮである場合には、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮して、アクセスログを表示するか否かを判断した。
【０１５３】
これに対して第２の実施形態は、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間については考慮せず、リクエストデータにＲｅｆｅｒｅＵＲＬが含まれるか否かによって、アクセスログを表示するか否かを判断する実施形態である。
【０１５４】
すなわち、第１の実施形態における条件設定画面（図９）では、自動除外解析時間の設定が可能であったが、第２の実施形態における条件設定画面（不図示）では、当該設定ができない画面となる（自動除外解析をするか否かの設定のみが可能な画面となる）。
【０１５５】
図１３は、本発明の第２の実施形態において、プロキシサーバ１０１がアクセスログテーブルに記録されたアクセスログのうち、アクセスが禁止されたログをクライアントＰＣ１０２に表示処理を示すフローチャートである。すなわち、第１の実施形態における図８に代わるフローチャートである。
【０１５６】
なお、図１３のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【０１５７】
ステップＳ１３０１〜ステップＳ１３０７に示す処理については、図８におけるステップＳ８０１〜Ｓ８０７に示す処理と同じ処理である。そのため、ここでの説明は省略する。
【０１５８】
ステップＳ１３０８では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１３０４で読み込んだアクセスログにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。
【０１５９】
ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ１３０８：ＹＥＳ）は、処理をステップＳ１３１０へ移行する。
【０１６０】
ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ１３０８：ＮＯ）は、処理をステップＳ１３０９へ移行する。
【０１６１】
ステップＳ１３０９では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１３０４で読み込んだアクセスログをクライアントＰＣ１０２に表示するべく、クライアントＰＣ１０２に送信する。
【０１６２】
ステップＳ１３１０では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１３０４で読み込んだアクセスログが、アクセスログテーブルに記録されたアクセスログのうち最後のアクセスログであるか否かを判断する。
【０１６３】
最後のアクセスログであると判断されると（ステップＳ１３１０：ＹＥＳ）、本フローチャートに示す処理を終了する。
【０１６４】
最後のアクセスログではないと判断されると（ステップＳ１３１０：ＮＯ）、処理をステップＳ１３０４に移行し、次のアクセスログを１行読み込む。
【０１６５】
以上のように、第２の実施形態における処理は、第１の実施形態におけるステップＳ８０９およびステップＳ８１０に示す処理を実行しないものである。これにより、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間にかかわらず、リクエストデータにＲｅｆｅｒｅｒＵＲＬが存在するアクセスログについては表示対象としないことが可能となる。
【０１６６】
図１４に示す画面は、第２の実施形態における図１３のステップＳ１３１１の処理によりクライアントＰＣ１０２に表示される画面である。
【０１６７】
アクセスログテーブル（図５）におけるログＩＤ：１、２、８のアクセスログが表示されている。
【０１６８】
すなわち、設定された時刻条件を満たすログのうち、「アクセスが禁止されたログであり、かつＲｅｆｅｒｅｒＵＲＬが記録されていないログ」および、「アクセスが禁止されたログであり、ＧＥＴメソッドではないログ」が表示される。
【０１６９】
以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを監査者へ通知することが可能なる。その結果、適切なログ管理が可能となる。
【０１７０】
具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、ユーザによる意図的なアクセス（リンク先をクリックする等）ではなく、ブラウザが自動的にデータを取得した可能性が高いといえる。
【０１７１】
このように、ＲｅｆｅｒｅｒＵＲＬの有無により、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては通知・表示をしないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。それにより、効率的なログ管理が可能となる。
【０１７２】
さらに、本実施形態においては、ステップＳ１３０７においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、表示対象ログとしている。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）場合については、ＲｅｆｅｒｅｒＵＲＬの有無に関わらず、意図的なアクセスであることが多いためである。このステップＳ１３０７における判断処理により、監査に有用なログを表示させることが可能となる。
【０１７３】
なお、本発明の目的は、監査に有用ではないアクセスログを表示させないことであるため、ステップＳ１３０７における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。
＜第３の実施形態＞
次に、本発明の第３の実施形態について説明する。
【０１７４】
第３の実施形態は、リクエストデータにＲｅｆｅｒｅｒＵＲＬが含まれるか否かにより、当該リクエストに関するアクセスログを残すか否かを判断するものである。
【０１７５】
第１および第２の実施形態においては、全てのリクエストに関するアクセスログを残し（図３参照）、当該ログを表示させる際にＲｅｆｅｒｅｒＵＲＬの有無や、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮して表示させるか否かを判断した（図８、図１３参照）。
【０１７６】
第３の実施形態では、ＲｅｆｅｒｅｒＵＲＬの有無によりアクセスログを残すか否かを決定する構成について説明する。
【０１７７】
図１５は、本発明の第３の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２から送信されたリクエストデータを受信し、当該リクエストにかかるアクセスログを記録する処理を示すフローチャートである。すなわち、第１および第２の実施形態における図３のフローチャートに代わる図である。
【０１７８】
なお、図１５のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【０１７９】
ステップＳ１５０１では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータを取得し、当該リクエストデータからアクセス先となるＵＲＬを取得する。
【０１８０】
ステップＳ１５０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したアクセス先ＵＲＬがアクセスルールテーブル（図４）に存在するか否かを判定する。すなわち、当該アクセス先ＵＲＬについて、いずれかのアクセスルールが適用されるか否かを判定する。
【０１８１】
アクセスルールテーブルに存在すると判定された場合（ステップＳ１５０２：ＹＥＳ）は、処理をステップＳ１５０４へ移行する。
【０１８２】
他方、アクセスルールテーブルに存在しないと判断された場合（ステップＳ１５０２：ＮＯ）は、処理をステップＳ１５０３に移行する。
【０１８３】
ステップＳ１５０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０２で適用されると判定されたアクセスルールについて、その動作がアクセスを禁止（データ中継を許可しない）であるか否かを判定する。
【０１８４】
ステップＳ１５０３においてアクセスを許可すると判定された場合（ステップＳ１５０３：許可）は、処理をステップＳ１５０４に移行する。
【０１８５】
他方、ステップＳ１５０３においてアクセスを禁止すると判定された場合（ステップＳ１５０３：禁止）は、処理をステップＳ１５０６に移行する。
【０１８６】
ステップＳ１５０４では、プロキシサーバ１０１のＣＰＵ２０１は、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したアクセス先ＵＲＬが示すウェブサーバ１０５にアクセスをする。
【０１８７】
ステップＳ１５０５では、プロキシサーバ１０１のＣＰＵ２０１は、ウェブサーバ１０５からレスポンスデータを取得し、当該レスポンスデータをリクエスト元であるクライアントＰＣ１０２に送信する。
そして、本フローチャートに示す処理を終了する。
【０１８８】
ステップＳ１５０６では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したＨＴＴＰリクエストデータのメソッドがＧＥＴメソッドであるか否かを判断する。
【０１８９】
ＧＥＴメソッドであると判断された場合（ステップＳ１５０６：ＹＥＳ）は、処理をステップＳ１５０７に移行する。
【０１９０】
ＧＥＴメソッドではないと判断された場合（ステップＳ１５０６：ＮＯ）は、処理をステップＳ１５０８に移行する。
【０１９１】
ステップＳ１５０７では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したリクエストデータにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。
【０１９２】
ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ１５０７：ＹＥＳ）は、処理をステップＳ１５０９に移行する。
【０１９３】
ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ１５０７：ＮＯ）は、処理をステップＳ１５０８に移行する。
【０１９４】
ステップＳ１５０８では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣからリクエストされたＵＲＬに対するアクセスが禁止された旨の結果をアクセスログテーブル（図１８）に記録する。
【０１９５】
この際、アクセスログテーブルには、アクセスが禁止された旨の結果（ルール結果）だけでなく、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣを識別する情報（ＩＰアドレス等）（クライアントＩＰアドレス）、アクセス先ＵＲＬ等についても記録される。
【０１９６】
ステップＳ１５０９では、プロキシサーバ１０１のＣＰＵ２０１は、リクエスト元であるクライアントＰＣ１０２に対してアクセスが禁止された旨の結果を示すＨＴＴＰレスポンスデータを送信する。
そして、本フローチャートに示す処理を終了する。
【０１９７】
なお、本実施形態では、アクセスルールテーブルに設定されていないＵＲＬへのアクセスについては、アクセスを許可するように構成しているが、デフォルト処理としてアクセス禁止として設定をしておき、その設定に従って処理を行うように構成しても良い。
【０１９８】
以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを記録することが可能なる。これにより、適切なログ管理が可能となる。
【０１９９】
具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、ユーザによる意図的なアクセス（リンク先をクリックする等）ではなく、ブラウザが自動的にデータを取得した可能性が高いといえる。
【０２００】
このように、ＲｅｆｅｒｅｒＵＲＬの有無により、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては記録として残さないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。これにより、効率的なログ管理が可能となる。
【０２０１】
さらに、本実施形態においては、ステップＳ１５０６においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、記録としてログを残している。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）については、ＲｅｆｅｒｅｒＵＲＬの有無に関わらず、意図的なアクセスであることが多いためである。このステップＳ１５０６における判断処理により、監査に有用なログを記録することが可能となる。
【０２０２】
なお、本発明の目的は、監査に有用ではないアクセスログについては登録しない（記録として残さない）ことであるため、ステップＳ１５０６における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。
【０２０３】
また、監査に必要なログと不要なログとをアクセスログを記録する際に判断する構成を採ることで、ログを表示させる際の判断が不要となる。このように、不要なログを記録しないことで、プロキシサーバ等の資源（記憶領域等）を有効に利用することが可能となる。
【０２０４】
図２２は、本発明の第３の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２にアクセスログを表示するべくクライアントＰＣ１０２にアクセスログを送信する処理を示すフローチャートである。
【０２０５】
なお、図２２のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【０２０６】
ステップＳ２２０１では、プロキシサーバ１０１のＣＰＵ２０１は、ユーザからアクセスログの検索条件の設定を受け付ける。なお、検索条件の設定については、クライアントＰＣ１０２に表示される検索条件設定画面（図２３）を介して受け付ける。
【０２０７】
ここで、図２３に一例を示す検索条件設定画面について説明する。
【０２０８】
図２３に示す画面では、アクセスログを検索する条件として、アクセス時刻の時刻条件（期間や時間範囲）の設定が可能である。
【０２０９】
図２３に示す例では、アクセスログテーブルに記録されたアクセス時刻が、「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であり、「００時００分〜２４時００分」まで（終日）のログが検索されることを示している。
【０２１０】
ステップＳ２２０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ２２０１で受け付けた検索条件に合致するアクセスログをアクセスログテーブルから抽出する。
【０２１１】
ステップＳ２２０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ２２０２で抽出されたアクセスログを、クライアントＰＣ１０２で表示すべくクライアントＰＣ１０２に送信する。
【０２１２】
以上の処理により送信されたアクセスログをクライアントＰＣ１０２が受信すると、クライアントＰＣ１０２には、図１４に一例を示す画面が表示される（表示される画面は第２の実施形態と同じである）。
＜第４の実施形態＞
次に、本発明の第４の実施形態について説明する。
【０２１３】
第４の実施形態は、リクエストデータにＲｅｆｅｒｅｒＵＲＬが含まれるか否か、およびＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間によって、当該リクエストに関するアクセスログを残すか否かを判断するものである。
【０２１４】
すなわち、第３の実施形態においては、ＲｅｆｅｒｅｒＵＲＬが含まれるリクエストデータにかかるアクセスログについては全て記録を残さなかった（ログを記憶しなかった）が、第４の実施形態においては、ＲｅｆｅｒｅｒＵＲＬが含まれるリクエストデータにかかるアクセスログについても、当該ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間によってログを記憶するか否かを決定する。
【０２１５】
図１６は、本発明の第４の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２から送信されたリクエストデータを受信し、当該リクエストにかかるアクセスログを記録する処理を示すフローチャートである。
【０２１６】
なお、図１６のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【０２１７】
なお、ステップＳ１６０１〜Ｓ１６０６の処理については、第３の実施形態における図１５のステップＳ１５０１〜Ｓ１５０６と同じ処理であるため、ここでの説明は省略する。
【０２１８】
ステップＳ１６０７では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１６０１で取得したリクエストデータにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。
【０２１９】
ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ１６０７：ＹＥＳ）は、処理をステップＳ１６０８に移行する。
【０２２０】
ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ１６０７：ＮＯ）は、処理をステップＳ１６０９に移行する。
【０２２１】
ステップＳ１６０８では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１６０１で取得したリクエストデータの送信時刻と、ステップＳ１６０７で判断されたＲｅｆｅｒｅｒＵＲＬへのアクセス時刻との差が、図２０に示す閾値を超えるか否かを判断する。すなわち、ＲｅｆｅｒｅｒＵＲＬへのアクセスから閾値を超える時間を経過した後のアクセスであるかを判断する。なお、図２０に示す閾値は、図２１に示す設定画面を介して監査者等により設定される。
【０２２２】
ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻から閾値を超える時間が経過していると判断された場合（ステップＳ１６０８：ＹＥＳ）は、処理をステップＳ１６０９に移行する。
【０２２３】
ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻からの経過時間が閾値を超えないと判断された場合（ステップＳ１６０８：ＮＯ）は、処理をステップＳ１６１０に移行する。
【０２２４】
ステップＳ１６０９では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣから送信されたＵＲＬに対するアクセスが禁止された旨の結果をアクセスログテーブル（図１９）に記録する。
【０２２５】
この際、アクセスログテーブルには、アクセスが禁止された旨の結果（ルール結果）だけでなく、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣを識別する情報（ＩＰアドレス等）（クライアントＩＰアドレス）、アクセス先ＵＲＬ等についても記録される。
【０２２６】
また、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに「ＲｅｆｅｒｅｒＵＲＬ（参照元ＵＲＬ）」が含まれる場合には、当該ＲｅｆｅｒｅｒＵＲＬもあわせて記録される。
【０２２７】
ステップＳ１６１０では、プロキシサーバ１０１のＣＰＵ２０１は、リクエスト元であるクライアントＰＣ１０２に対してアクセスが禁止された旨の結果を示すＨＴＴＰレスポンスデータを送信する。
そして、本フローチャートに示す処理を終了する。
【０２２８】
以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを記録することが可能なる。これにより、適切なログ管理が可能となる。
【０２２９】
具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、ユーザによる意図的なアクセスではなく、ブラウザが自動的にアクセスした可能性が高い。ただ、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスのすべてが意図的ではないアクセスとは言えず、ＲｅｆｅｒｅｒＵＲＬが記録されていたとしても意図的なアクセスである可能性はある。そこで、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮し、ＲｅｆｅｒｅｒＵＲＬが記録されたアクセスであっても意図的なアクセスであるか否かを判断する。
【０２３０】
すなわち、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間が短い場合には、自動的にブラウザがリクエストをしたログである可能性が高い。他方、ＲｅｆｅｒｅｒＵＲＬへのアクセスから一定時間が経過した後のアクセスについては、ユーザによる意図的なアクセス（リンク先をクリックした等）である可能性が高いといえる。そのため、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮することで、意図的なアクセスであるか否かを適切に判断することが可能となる。
【０２３１】
このように、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては記録として残さないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。その結果、効率的なログ管理が可能となる。
【０２３２】
さらに、本実施形態においては、ステップＳ１６０６においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、表示対象ログとしている。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）については、ＲｅｆｅｒｅｒＵＲＬの有無や、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間に関わらず、意図的なアクセスであることが多いためである。このステップＳ１６０６における判断処理により、監査に有用なログを表示させることが可能となる。
【０２３３】
なお、本発明の目的は、監査に有用ではないアクセスログを表示させないことであるため、ステップＳ１６０６における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。
【０２３４】
また、監査に必要なログと不要なログとをアクセスログを記録する際に判断する構成を採ることで、ログを表示させる際の判断が不要となる。このように、不要なログを記録しないことで、プロキシサーバ等の資源（記憶領域等）を有効に利用することが可能となる。
【０２３５】
第４の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２にアクセスログを表示するべく、クライアントＰＣ１０２にアクセスログを送信する処理については、図２２のフローチャートで示す（第３の実施形態と同じ処理である）。
【０２３６】
第４の実施形態において、図２２の処理により送信されたアクセスログをクライアントＰＣ１０２が受信した際にクライアントＰＣ１０２に表示される画面については、図１１に示す画面である（第１の実施形態と同じ画面である）。
【０２３７】
ここで、図１７を参照して、ＨＴＴＰリクエストデータの構成について説明する。図１７に示すようにＨＴＴＰデータのリクエスト行１７０１、１７０２には、メソッド（図１７の例ではＧＥＴメソッド）、宛先となるＵＲＬ情報（リクエストＵＲＬ）、ＨＴＴＰのバージョン情報が設定される。
【０２３８】
本発明の第１〜第４の実施形態では、このリクエスト行１７０１、１７０２に設定されているＵＲＬ情報をアクセス先ＵＲＬとして中継制御ルールと照合する。
【０２３９】
またＲｅｆｅｒｅｒ１７０３には、このＨＴＴＰデータの送信元となったＵＲＬ情報（ＲｅｆｅｒｅｒＵＲＬ（参照元ＵＲＬ））が設定される。本発明の第１〜第４の実施形態では、ＨＴＴＰデータに、このＲｅｆｅｒｅｒ１７０３が記録されているか否かを判断する。
【０２４０】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０２４１】
また、本発明におけるプログラムは、図３、図６〜図８の処理方法をコンピュータが実行可能なプログラムである。なお、本発明におけるプログラムは図３、図６〜図８の各装置の処理方法ごとのプログラムであってもよい。
【０２４２】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
【０２４３】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
【０２４４】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。
【０２４５】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２４６】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２４７】
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０２４８】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０２４９】
１０１ プロキシサーバ
１０２ クライアント端末
１０３ ＬＡＮ
１０４ 広域ネットワーク
１０５ ウェブサーバ
【技術分野】
【０００１】
本発明は、内部ネットワークの端末装置と、インターネット等の外部ネットワーク上のサーバ装置との間の通信の中継制御にかかる記録の管理技術に関する。
【背景技術】
【０００２】
ネットワーク技術の発展によって、情報のやり取りが非常に簡便に、且つ効率よく行うことが可能となっている。例えば、会議に使用する資料を電子メールに添付して参加者に前もって送付したりすることが、手間も煩わしさもなく行うことが可能となっている。
【０００３】
ただ、このようにネットワーク技術が発達し、情報のやりとりが容易に行われるようになった反面、重要な機密情報が簡単に外部に流出してしまう危険性や外部からコンピュータウイルス等の有害情報が流入してしまう危険性が高まっている。
【０００４】
そこで、企業等では、業務とは直接関係のない情報を提供しているサーバへのアクセスを禁止する等の対策を講じている。
【０００５】
例えば、特定のＵＲＬに対するアクセスを禁止する通信制御であるＵＲＬフィルタリングを行う機器を導入し、アクセスが許可されないＵＲＬに対するリクエストを当該ＵＲＬが示す情報資源を提供する外部サーバに転送しないことで、当該ＵＲＬが示す情報資源にアクセスできないようにしている。
【０００６】
ＵＲＬフィルタリングを行う場合には、アクセスを許可するＵＲＬのリストであるホワイトリストや、アクセスを禁止するＵＲＬのリストであるブラックリストを作成し、それらに対する制御を行うことになる。つまり、ホワイトリストに登録されているＵＲＬに対するリクエストはその通信を中継し、ブラックリストに登録されているＵＲＬに対するリクエストはその通信を中継しないといった制御を行うことになる。
【０００７】
例えば、特許文献１には、閲覧制限が付されたＷＥＢサイトに対してユーザから閲覧要求があった場合、監査者に対して閲覧の記録が通知される仕組みが開示されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００８−２３４３３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、閲覧が制限されたＷＥＢサイトに対するアクセス記録についてすべてが通知されることとなると、非常に大量の記録が通知されることになってしまう。
【００１０】
特に、ユーザ指定のＵＲＬだけでなく、複数のＵＲＬアクセスからページ全体が構成されるサイトでは、画像や動画などのファイル取得先が別ＵＲＬで指定されている場合がある。このような場合において、「ユーザが指定したＵＲＬ自体は閲覧許可されているが、そこからリンクされている画像や動画などのファイル取得先であるＵＲＬについては閲覧制限の対象となっている」という場合には、大量の規制ログが通知されてしまう。
【００１１】
このような画像や動画に対するアクセスは、閲覧者が故意に（意図的に）アクセスをしている訳ではないため、このようなアクセス記録は適切な閲覧制限を行う上で有用な記録ではない。
【００１２】
そのため、監査者は、適切なアクセス制限をするために、大量のログの中から、ユーザが故意に（意図的に）アクセスしたログを抽出しなければならないといった手間が生じてしまう。
【００１３】
そこで、本発明は、閲覧者によるＷＥＢサイトへのアクセスを管理する監査者が、効率よくアクセスログを管理することができる仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明の情報処理装置は、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断手段と、前記参照元判断手段により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知手段と、を備えることを特徴とする。
を特徴とする。
【００１５】
また、本発明の情報処理方法は、情報処理装置の取得手段が、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得工程と、前記情報処理装置の参照元判断手段が、前記取得工程により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断工程と、前記情報処理装置の通知手段が、前記参照元判断工程により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知工程と、を備えることを特徴とする。
を特徴とする。
【００１６】
また、本発明のプログラムは、情報処理装置を、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断手段と、前記参照元判断手段により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知手段として機能させることを特徴とする。
【発明の効果】
【００１７】
本発明によれば、閲覧者によるＷＥＢサイトへのアクセスを管理する監査者が、効率よくアクセスログを管理することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】本発明の情報処理システムの構成の一例を示す図である
【図２】図１のプロキシサーバ１０１として適用可能な情報処理装置のハードウエア構成の一例を示す図である
【図３】第１および第２の実施形態における、プロキシサーバ１０１により実行されるアクセス制御処理を示すフローチャートである
【図４】アクセスルールテーブルの一例を示す図である
【図５】アクセスログテーブルの一例を示す図である
【図６】本発明におけるクライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれの処理の流れを示す図である
【図７】本発明におけるクライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれの処理の流れを示す図である
【図８】第１の実施形態においてプロキシサーバ１０１により実行される、アクセスログをクライアントＰＣに表示する処理を示すフローチャートである
【図９】第１の実施形態においてクライアントＰＣ１０２に表示される条件設定画面の一例を示す図である
【図１０】ステップＳ８０３、ステップＳ１３０３においてクライアントＰＣ１０２に表示されるアクセスログ表示画面の一例を示す図である
【図１１】第１の実施形態（ステップＳ８１１）、第４の実施形態においてクライアントＰＣ１０２に表示されるアクセスログ表示画面の一例を示す図である
【図１２】プロキシサーバ１０１の機能構成を示すブロック図である。
【図１３】第２の実施形態においてプロキシサーバ１０１により実行される、アクセスログをクライアントＰＣに表示する処理を示すフローチャートである
【図１４】第２の実施形態（ステップＳ１３０９）、第３の実施形態においてクライアントＰＣ１０２に表示されるアクセスログ表示画面の一例を示す図である
【図１５】第３の実施形態においてプロキシサーバ１０１により実行される、アクセス制御処理およびアクセスログの登録処理を示すフローチャートである
【図１６】第４の実施形態においてプロキシサーバ１０１により実行されるアクセス制御処理およびアクセスログの登録処理を示すフローチャートである
【図１７】ＨＴＴＰリクエストデータの構成を示す図である
【図１８】ステップＳ１５０８において登録されるアクセスログを示す図である
【図１９】ステップＳ１６０９において登録されるアクセスログを示す図である
【図２０】ステップＳ１６０８において判断基準として用いられる閾値が登録されたテーブルである
【図２１】図２０に示す閾値を設定する画面の一例を示す図である
【図２２】第３、第４の実施形態においてプロキシサーバ１０１がクライアントＰＣ１０２に対してアクセスログを送信する処理を示すフローチャートである
【図２３】第３、第４の実施形態における検索条件設定画面の一例を示す図である
【発明を実施するための形態】
【００１９】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００２０】
図１は、本発明に係る情報処理システムのシステム構成の一例を示す図である。
【００２１】
図１に示すように、本実施形態に係る情報処理システムは、プロキシサーバ１０１、クライアントＰＣ１０２−１乃至１０２−３（以後、まとめて「クライアントＰＣ１０２」とする）、ＬＡＮ１０３、広域ネットワーク１０４、ウェブサーバ１０５−１乃至１０５−３（以後、まとめて「ウェブサーバ１０５」とする）を備えている。
【００２２】
以下、本発明の情報処理システムを構成する各装置について説明する。
【００２３】
プロキシサーバ１０１は、本発明の情報処理装置として機能する装置であり、クライアントＰＣ１０２とウェブサーバ１０５との間のデータ通信を中継する。また、プロキシサーバ１０１は、クライアントＰＣ１０２とウェブサーバ１０５との間でやりとりされるデータに対して、当該データの中継を許可する（中継する）か、または拒否する（中継しない）かといった中継制御ルールに従い、データの通信制御を行う機能を有している。
【００２４】
また、データの通信制御に関するログを記憶する機能を有している。
【００２５】
クライアントＰＣ１０２は、ウェブサーバ１０５が提供する各種のサービス（ホームページの閲覧等）を利用するユーザが使用する端末装置である。また、プロキシサーバ１０１に記憶されたデータ通信制御に関するログを表示する機能を有する。
【００２６】
ＬＡＮ１０３は、プロキシサーバ１０１、クライアントＰＣ１０２を相互にデータ通信可能に接続するネットワークである。
【００２７】
ウェブサーバ１０５は、各種のウェブサービスを提供するサービス事業者により設置されるサーバ装置である。ここで提供されるサービスとしては、例えばホームページの閲覧サービスや、商品の販売サービス、航空券やホテル等の予約サービスなどがあるが、これに限定されない。
【００２８】
プロキシサーバ１０１とウェブサーバ１０５は、インターネット等の広域ネットワーク１０４を介して、相互にデータ通信可能に接続されている。
以上が本発明の情報処理システム構成の一例の説明である。
【００２９】
以下、図２を用いて、図１に示したプロキシサーバ１０１に適用可能な情報処理装置のハードウエア構成の一例について説明する。
【００３０】
図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な各種プログラム等が記憶されている。
【００３１】
２０２はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
【００３２】
また、２０５は入力コントローラで、入力装置２０９等からの入力を制御する。２０６はビデオコントローラで、液晶ディスプレイ等のディスプレイ装置２１０への表示を制御する。なお、ディスプレイ装置は、液晶ディスプレイに限られず、ＣＲＴディスプレイなどであっても良い。これらは必要に応じてクライアントが使用するものである。
【００３３】
２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶するハードディスク（ＨＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００３４】
２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したＬＡＮ１０４）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。
【００３５】
なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ装置２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ装置２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３６】
ハードウエア上で動作する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００３７】
次に図３を用いて、本発明の第１および第２の実施形態においてプロキシサーバ１０１が行うアクセス制御処理について説明する。
【００３８】
なお、図３のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００３９】
ステップＳ３０１では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータからアクセス先となるＵＲＬを取得する。
【００４０】
ステップＳ３０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ３０１で取得したアクセス先ＵＲＬがアクセスルールテーブル（図４）に存在するかを判定する。すなわち、当該アクセス先ＵＲＬについて、いずれかのアクセスルールが適用されるか否かを判定する。
【００４１】
アクセスルールテーブルに存在すると判定された場合（ステップＳ３０２：ＹＥＳ）は、処理をステップＳ３０３に移行する。
【００４２】
他方、アクセスルールテーブルに存在しないと判定された場合（ステップＳ３０２：ＮＯ）は、処理をステップＳ３０６に移行する。
【００４３】
ステップＳ３０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ３０２で適用されると判定されたアクセスルールについて、その動作がアクセスを禁止（データ中継を許可しない）であるか否かを判定する。
【００４４】
ステップＳ３０３においてアクセスを許可すると判定された場合（ステップＳ３０３：許可）は、処理をステップＳ３０６に移行する。
【００４５】
他方、ステップＳ３０３においてアクセスを禁止すると判定された場合（ステップＳ３０３：禁止）は、処理をステップＳ３０４に移行する。
【００４６】
ステップＳ３０４では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣから送信されたＵＲＬに対するアクセスが禁止された旨の結果をアクセスログテーブル（図５）に記録する。
【００４７】
この際、アクセスログテーブルには、アクセスが禁止された旨の結果（ルール結果）だけでなく、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣを識別する情報（ＩＰアドレス等）（クライアントＩＰアドレス）、アクセス先ＵＲＬ等についても記録される。
【００４８】
また、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに「ＲｅｆｅｒｅｒＵＲＬ（参照元ＵＲＬ）」が含まれる場合には、当該ＲｅｆｅｒｅｒＵＲＬもあわせて記録される。
【００４９】
ステップＳ３０５では、プロキシサーバ１０１のＣＰＵ２０１は、リクエスト元であるクライアントＰＣ１０２に対してアクセスが禁止された旨の結果を示すＨＴＴＰレスポンスデータを送信する。
そして本フローチャートに示す処理を終了する。
【００５０】
ステップＳ３０６以降は、ステップＳ３０２においてクライアントＰＣ１０２から送信されたアクセス先ＵＲＬがアクセスルールに該当しなかった場合、または、該当するアクセスルールに設定された動作が「禁止」以外であった場合の処理である。
【００５１】
ステップＳ３０６では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ３０１で取得したアクセス先ＵＲＬが示すウェブサーバ１０５にアクセスをする。
【００５２】
ステップＳ３０７では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣから送信されたＵＲＬに対するアクセスが許可された旨の結果をアクセスログテーブル（図５）に記録する。この際、ステップＳ３０４における処理と同様に、アクセスログテーブルに対して、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣのＩＰアドレス（クライアントＩＰアドレス）、アクセス先ＵＲＬについても記録される。
【００５３】
また、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに「ＲｅｆｅｒｅｒＵＲＬ」が含まれる場合には、当該ＲｅｆｅｒｅｒＵＲＬもあわせて記録される。
【００５４】
ステップＳ３０８では、プロキシサーバ１０１のＣＰＵ２０１は、ウェブサーバ１０５からレスポンスデータを取得し、当該レスポンスデータをリクエスト元であるクライアントＰＣ１０２に送信する。
そして、本フローチャートに示す処理を終了する。
【００５５】
なお、本実施形態では、アクセスルールテーブルに設定されていないＵＲＬへのアクセスについては、アクセスを許可するように構成しているが、デフォルト処理としてアクセス禁止として設定をしておき、その設定に従って処理を行うように構成しても良い。
【００５６】
以上の処理により、プロキシサーバ１０１において実行された、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに対する処理を記録することができる。
【００５７】
次に、図６を用いて、本発明の第１および第２の実施形態におけるクライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれの処理の流れを説明する。
【００５８】
なお、図６では、「複数のＵＲＬアクセスからページ全体が構成され、ユーザにより指定されたＵＲＬ自体はアクセスが許可されるが、そこからリンクされている画像のファイル取得先であるＵＲＬについてはアクセスが禁止される場合」の処理について説明する。
【００５９】
ステップＳ６０１では、クライアントＰＣ１０２からプロキシサーバ１０１に対してＨＴＴＰリクエストデータが送信される（図３におけるステップＳ３０１に相当）。図６に示す例では、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータ（アクセス先ＵＲＬ）は「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるとする。
【００６０】
そして、ステップＳ６０２では、プロキシサーバ１０１がステップＳ６０１で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。
【００６１】
図６に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるため、アクセスルールテーブルにおけるルールＩＤ：３（「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「許可」であるので、ステップＳ６０２では、クライアントＰＣ１０２から送信されたデータの中継は許可される（図３のステップＳ３０３：許可に相当）。
【００６２】
ステップＳ６０３では、プロキシサーバ１０１が「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」が示すウェブサーバ１０５へアクセスをする。そして、ステップＳ６０４でウェブサーバ１０５は、ステップＳ６０３のアクセスに対するレスポンスデータをプロキシサーバ１０１に送信し、プロキシサーバ１０１は当該レスポンスデータを取得する（図３のステップＳ３０６に相当）。
【００６３】
ステップＳ６０５では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」に対するアクセスが許可された旨をアクセスログテーブルに記録する（図３のステップＳ３０７に相当）。なお、ステップＳ６０５で記録されるアクセスログは、図５に示すアクセスログテーブルの「ログＩＤ：３」に示すログにあたる。
【００６４】
ステップＳ６０６では、プロキシサーバ１０１は、ウェブサーバ１０５から取得したレスポンスデータをクライアントＰＣ１０２に対して送信する（図３のステップＳ３０８に相当）。
【００６５】
そして、クライアントＰＣ１０２では、ステップＳ６０６でプロキシサーバ１０１から送信されたレスポンスデータを解析し、ウェブページ内に含まれる画像データの取得先であるＵＲＬを取得する。なお、図６に示す例では、レスポンスデータを解析して得られたＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ」であるとする。
【００６６】
ステップＳ６０７では、クライアントＰＣ１０２から、取得したＵＲＬ（ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ）をアクセス先とするＨＴＴＰリクエストデータがプロキシサーバ１０１に送信される（図３のステップＳ３０１に相当）。このとき、ＨＴＴＰリクエストデータは、ＲｅｆｅｒｅｒＵＲＬとしてリンク元のウェブページのＵＲＬである「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」を有する。
【００６７】
そして、ステップＳ６０８では、プロキシサーバ１０１がステップＳ６０７で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。
【００６８】
図６に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ」であるため、アクセスルールテーブルにおけるルールＩＤ：１（「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「禁止」であるので、ステップＳ６０８では、クライアントＰＣから送信されたデータの中継は行われない（図３のステップＳ３０３：禁止に相当）。
【００６９】
ステップＳ６０９では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｍａｇｅ．ｐｎｇ」に対するアクセスが禁止された旨をアクセスログテーブルに記録する（図３のステップＳ３０３０４に相当）。なお、この際、アクセスログテーブルには、ＲｅｆｅｒｅｒＵＲＬである「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」があわせて記録される。なお、ステップＳ６０９で記録されるログは、図５に示すアクセスログテーブルの「ログＩＤ：４」に示すログにあたる。
【００７０】
そして、ステップＳ６１０において、プロキシサーバ１０１からクライアントＰＣ１０２に対して、アクセスが禁止された旨の情報が送信される（図３のステップＳ３０５に相当）。
【００７１】
次に、図７を用いて、独立した２つのウェブページへのアクセスが共にアクセス禁止をされるケースについて、クライアントＰＣ１０２、プロキシサーバ１０１、ウェブサーバ１０５それぞれで実行される処理の流れを説明する。
【００７２】
ステップＳ７０１では、クライアントＰＣ１０２からプロキシサーバ１０１に対してＨＴＴＰリクエストデータが送信される（図３におけるステップＳ３０１に相当）。図７に示す例では、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータ（アクセス先ＵＲＬ）は「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるとする。
【００７３】
そして、ステップＳ７０２では、プロキシサーバ１０１がステップＳ７０１で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。
【００７４】
図７に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であるため、アクセスルールテーブルにおけるルールＩＤ：１（「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「禁止」であるので、ステップＳ７０２では、クライアントＰＣ１０２から送信されたデータの中継は行われない（図３のステップＳ３０３：禁止に相当）。
【００７５】
ステップＳ７０３では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」に対するアクセスが禁止された旨をアクセスログテーブルに記録する（図３のステップＳ３０３０４に相当）。なお、ステップＳ７０３で記録されるログは、図５に示すアクセスログテーブルの「ログＩＤ：１」に示すログにあたる。
【００７６】
そして、ステップＳ７０４において、プロキシサーバ１０１からクライアントＰＣ１０２に対して、アクセスが禁止された旨の情報が送信される（図３のステップＳ３０５に相当）。
【００７７】
ステップＳ７０５では、クライアントＰＣ１０２からプロキシサーバ１０１に対してＨＴＴＰリクエストデータが送信される（図３におけるステップＳ３０１に相当）。図７に示す例では、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータ（アクセス先ＵＲＬ）は「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍａｉｎ．ｈｔｍｌ」であるとする。
【００７８】
そして、ステップＳ７０６では、プロキシサーバ１０１がステップＳ７０５で送信されたＨＴＴＰリクエストデータを取得し、当該データの中継の可否をアクセスルールテーブルをもとに判定する（図３のステップＳ３０２、Ｓ３０３に相当）。
【００７９】
図７に示す例では、クライアントＰＣ１０２から送信されたアクセス先ＵＲＬは「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍａｉｎ．ｈｔｍｌ」であるため、アクセスルールテーブルにおけるルールＩＤ：１（「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／＊」）に該当することになる。したがって、当該ルールの動作は「禁止」であるので、ステップＳ７０６では、クライアントＰＣ１０２から送信されたデータの中継は行われない（図３のステップＳ３０３：禁止に相当）。
【００８０】
ステップＳ７０７では、プロキシサーバ１０１は、「ｈｔｔｐ：／／ｂｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｍａｉｎ．ｈｔｍｌ」に対するアクセスが禁止された旨をアクセスログテーブルに記録する（図３のステップＳ３０３０４に相当）。なお、ステップＳ７０７で記録されるログは、図５に示すアクセスログテーブルの「ログＩＤ：２」に示すログにあたる。このとき、ステップＳ７０５で送信されたＨＴＴＰリクエストデータにはＲｅｆｅｒｅｒＵＲＬがないため、アクセスログテーブルにもＲｅｆｅｒｅｒＵＲＬは記録されない。
【００８１】
そして、ステップＳ７０８において、プロキシサーバ１０１からクライアントＰＣ１０２に対して、アクセスが禁止された旨の情報が送信される（図３のステップＳ３０５に相当）。
【００８２】
次に、図８を用いて、本発明の第１の実施形態におけるプロキシサーバ１０１がアクセスログテーブルに記録されたアクセスログのうち、アクセスが禁止されたログをクライアントＰＣ１０２に表示する処理について説明する。
【００８３】
なお、図８のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００８４】
ステップＳ８０１では、プロキシサーバ１０１のＣＰＵ２０１は、ユーザからアクセスログの検索条件の設定を受け付ける。
【００８５】
なお、検索条件の設定については、クライアントＰＣ１０２に表示される検索条件設定画面（図９）を介して受け付ける。
【００８６】
ここで、図９に一例を示す検索条件設定画面について説明する。
【００８７】
図９に示す画面では、アクセスログを検索する検索条件として、アクセス時刻の時刻条件（期間や時間範囲）や、「自動除外解析」のＯＮ／ＯＦＦおよび「自動除外解析時間」の設定が可能である。
【００８８】
「自動除外解析」がＯＦＦである場合には、時刻条件により検索されたアクセスログの全てが表示対象となる。
【００８９】
「自動除外解析」がＯＮである場合には、時刻条件により検索されたアクセスログのうち、ＲｅｆｅｒｅｒＵＲＬが記録されていないログ、および、ＲｅｆｅｒｅｒＵＲＬが記録されているログのうち当該ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻から「自動除外解析時間」で設定された時間を経過した後にアクセスされたログが表示対象となる。なお、自動除外解析時間については、ユーザにより任意に設定が可能である。
【００９０】
図９に示す例では、アクセスログテーブルに記録されたアクセス時刻が「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であり、「００時００分〜２４時００分」まで（終日）のログが検索されることを示している。
【００９１】
また、自動除外解析がＯＮである（チェックボックスにチェックがされている）ため、上述の通り、時刻条件により検索されたアクセスログのうち、ＲｅｆｅｒｅｒＵＲＬが記録されていないログ、および、ＲｅｆｅｒｅｒＵＲＬが記録されているログのうち当該ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻から１０秒以上経過した後にアクセスされたログが表示対象となる。
【００９２】
ステップＳ８０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０１で設定された条件のうち、自動除外解析がＯＮに設定されているか否か（チェックボックスにチェックが入れられているか否か）を判断する。
【００９３】
ＯＦＦに設定されている場合（ステップＳ８０２：ＯＦＦ）は、処理をステップＳ８０３に移行する。
【００９４】
ＯＮに設定されている場合（ステップＳ８０３：ＯＮ）は、処理をステップＳ８０４に移行する。
【００９５】
ステップＳ８０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０１で設定された時刻条件により検索される禁止アクセスログ（ルール結果が禁止として記録されているアクセスログ）の全てをクライアントＰＣ１０２に表示するべく、クライアントＰＣ１０２に送信する。
【００９６】
ステップＳ８０４では、プロキシサーバ１０１のＣＰＵ２０１は、アクセスログテーブルに記録されたアクセスログのうち最初のアクセスログを読み込む。
【００９７】
ステップＳ８０５では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログの「ルール結果」が禁止であるか否かを判断する。
【００９８】
禁止であると判断されると（ステップＳ８０５：ＹＥＳ）、処理をステップＳ８０６に移行する。
【００９９】
禁止ではないと判断されると（ステップＳ８０５：ＮＯ）、処理をステップＳ８１２に移行する。すなわち、当該アクセスログは表示対象から除外される。
【０１００】
ステップＳ８０６では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログのアクセス時刻が、ステップＳ８０１で設定された時刻条件を満たすか否かを判断する。すなわち、図９の例においては、当該アクセスログのアクセス時刻が「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であるか否かを判断する。
【０１０１】
時刻条件を満たすと判断された場合（ステップＳ８０６：ＹＥＳ）は、処理をステップＳ８０７に移行する。
【０１０２】
時刻条件を満たさないと判断された場合（ステップＳ８０６：ＮＯ）は、処理をステップＳ８１２に移行する。すなわち、当該アクセスログは表示対象から除外される。
【０１０３】
ステップＳ８０７では、ステップＳ８０４で読み込まれたアクセスログのＨＴＴＰメソッドがＧＥＴメソッドであるか否かを判断する。
【０１０４】
ＧＥＴメソッドであると判断されると（ステップＳ８０７：ＹＥＳ）、処理をステップＳ８０８に移行する。
【０１０５】
ＧＥＴメソッドではないと判断されると（ステップＳ８０７：ＮＯ）、処理をステップＳ８１１に移行する。すなわち、当該アクセスログを表示対象としてクライアントＰＣ１０２へ表示する。
【０１０６】
ステップＳ８０８では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。
【０１０７】
ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ８０８：ＹＥＳ）は、処理をステップＳ８０９に移行する。
【０１０８】
ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ８０８：ＮＯ）は、処理をステップＳ８１１に移行する。すなわち、当該アクセスログを表示対象としてクライアントＰＣ１０２へ表示する。
【０１０９】
ステップＳ８０９では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログに記録されたＲｅｆｅｒｅｒＵＲＬに対するアクセスにかかるアクセスログであり、かつ、ステップＳ８０４で読み込んだアクセスログの「クライアントＩＰアドレス」と同じクライアントＩＰアドレスが記録されたアクセスログを取得する。
【０１１０】
なお、本実施例では、同一性の判断にアクセス元のクライアントＰＣのＩＰアドレスを用いたが、これに限られるものではなく、他の基準により同一性を判断しても良い。
【０１１１】
ステップＳ８１０では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログのアクセス時刻が、ステップＳ８０９で取得したアクセスログのアクセス時刻（ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻）からステップＳ８０１で設定された自動除外解析時間を経過した時刻であるか否かを判断する。すなわち、ステップＳ８０４で読み込んだアクセスログにかかるアクセスが、ＲｅｆｅｒｅｒＵＲＬへのアクセスから自動除外解析時間が経過した後のアクセスであるか否かを判断する。
【０１１２】
ＲｅｆｅｒｅｒＵＲＬへのアクセスから自動除外解析時間を経過した後のアクセスであると判断された場合（ステップＳ８１０：ＹＥＳ）は、処理をステップＳ８１１に移行する。すなわち、当該アクセスログを表示対象としてクライアントＰＣ１０２へ表示する。
【０１１３】
ＲｅｆｅｒｅｒＵＲＬへのアクセスから自動除外解析時間を経過する前のアクセスであると判断された場合（ステップＳ８１０：ＮＯ）は、処理をステップＳ８１２に移行する。すなわち、当該アクセスログは表示対象から除外される。
【０１１４】
ステップＳ８１１では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログをクライアントＰＣ１０２に表示するべく、クライアントＰＣ１０２に送信する。
【０１１５】
ステップＳ８１２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ８０４で読み込んだアクセスログがアクセスログテーブルに記録されたアクセスログのうち最後のアクセスログであるか否かを判断する。
【０１１６】
最後のアクセスログであると判断されると（ステップＳ８１２：ＹＥＳ）、本フローチャートに示す処理を終了する。
【０１１７】
最後のアクセスログではないと判断されると（ステップＳ８１２：ＮＯ）、処理をステップＳ８０４に移行し、次のアクセスログを１行読み込む。
【０１１８】
以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを監査者へ通知することが可能なる。これにより、適切なログ管理が可能となる。
【０１１９】
具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、意図的なアクセスではない可能性が高い。ただ、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスのすべてが意図的ではないアクセスとは言えず、ＲｅｆｅｒｅｒＵＲＬが記録されていたとしても意図的なアクセスである可能性はある。そこで、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮し、ＲｅｆｅｒｅｒＵＲＬが記録されたアクセスであっても意図的なアクセスであるか否かを判断する。
【０１２０】
すなわち、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間が短い場合には、自動的にブラウザがリクエストをしたログである可能性が高い。他方、ＲｅｆｅｒｅｒＵＲＬへのアクセスから一定時間が経過した後のアクセスについては、ユーザによる意図的なアクセス（リンク先をクリックした等）である可能性が高いといえる。そのため、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮することで、意図的なアクセスであるか否かを適切に判断することが可能となる。
【０１２１】
このように、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては通知・表示をしないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。その結果、効率的なログ管理が可能となる。
【０１２２】
さらに、本実施形態においては、ステップＳ８０７においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、表示対象ログとしている。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）場合については、ＲｅｆｅｒｅｒＵＲＬの有無や、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間に関わらず、意図的なアクセスであることが多いためである。このステップＳ８０７における判断処理により、監査に有用なログを表示させることが可能となる。
【０１２３】
なお、本発明の目的は、監査に有用ではないアクセスログを表示させないことである。そのため、ステップＳ８０７における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。
【０１２４】
次に、図１０および図１１を用いて、図８のフローチャートに示す処理によりクライアントＰＣ１０２に表示されるアクセスログについて具体的に説明する。
【０１２５】
図１０に示す画面は、図８のステップＳ８０３においてクライアントＰＣ１０２に表示される画面である。すなわち、アクセスログテーブル（図５）に記録されたアクセスログのうち、ルール結果が禁止であり、かつ、ステップＳ８０１で図９に示す検索条件設定画面を介して設定された時刻条件を満たすアクセスログの全てが表示されている。
【０１２６】
図１０に示す画面では、アクセスログテーブルにおけるログＩＤ：１、２、４、５、６、８のアクセスログが表示されている。
【０１２７】
図１１に示す画面は、図８のステップＳ８１１においてクライアントＰＣ１０２に表示される画面である。
【０１２８】
以下、アクセスログテーブル（図５）および図８のフローチャートを用いて、図１１に表示されるアクセスログについて詳細に説明する。なお、時刻条件としては、図９に示す条件（「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であり、「００時００分〜２４時００分」まで）であるとする。
【０１２９】
アクセスログテーブルに示す「ログＩＤ：１」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：なし」である。そのため、図８におけるステップＳ８０８でＮＯと判断され、ステップＳ８１１にて表示対象とされる。
【０１３０】
「ログＩＤ：２」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：なし」であるため、ログＩＤ：１のアクセスログと同様に表示対象とされる。
【０１３１】
「ログＩＤ：３」のアクセスログについては、「ルール結果：許可」であるため、図８のステップＳ８０５においてＮＯと判断され、表示対象から除外される。
【０１３２】
「ログＩＤ：４」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：あり」、「ＲｅｆｅｒｅｒＵＲＬへのアクセスからの時間差：自動除外解析時間以内」であるため、図８のステップＳ８１０でＮＯと判断され、表示対象から除外される。
【０１３３】
なお、ＲｅｆｅｒｅｒＵＲＬへのアクセスにかかるアクセスログは、「ログＩＤ：３」のログであり、当該アクセスからの時間差は０秒である。そのため、自動除外解析時間（１０秒）以内のアクセスであると判断される。
【０１３４】
「ログＩＤ：５」のアクセスログについては、ログＩＤ：４のアクセスログと同様に表示対象から除外される。
【０１３５】
なお、ＲｅｆｅｒｅｒＵＲＬへのアクセスにかかるアクセスログは、「ログＩＤ：３」のログであり、当該アクセスからの時間差は２秒である。そのため、自動除外解析時間（１０秒）以内のアクセスであると判断される。
【０１３６】
「ログＩＤ：６」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＧＥＴ」、「ＲｅｆｅｒｅｒＵＲＬ：あり」、「ＲｅｆｅｒｅｒＵＲＬへのアクセスからの時間差：自動除外解析時間経過後」、であるため、ステップＳ８１０でＹＥＳと判断され、ステップＳ８１１にて表示対象とされる。
【０１３７】
なお、ＲｅｆｅｒｅｒＵＲＬへのアクセスにかかるアクセスログは、「ログＩＤ：３」のログであり、当該アクセスからの時間差は２０秒である。そのため、自動除外解析時間（１０秒）を経過した後のアクセスであると判断される。
【０１３８】
「ログＩＤ：７」のアクセスログについては、「ルール結果：許可」であるため、図８のステップＳ８０５でＮＯと判断され、表示対象から除外される。
【０１３９】
「ログＩＤ：８」のアクセスログについては、「ルール結果：禁止」、「時刻条件：満たす」、「ＨＴＴＰメソッド：ＰＯＳＴ」であるため、図８のステップＳ８０７でＮＯと判断されステップＳ８１１で表示対象とされる。
【０１４０】
図１２は、本発明におけるプロキシサーバ１０１の機能構成を示すブロック図である。
【０１４１】
取得部１２０１は、クライアントＰＣ１０２からウェブサーバに対して送信されるデータ取得要求（リクエストデータ）を取得する。
【０１４２】
参照元判断手段１２０２は、取得部１２０１が取得したリクエストデータに参照元ＵＲＬが含まれているか否かを判断する。
【０１４３】
通知部１２０３は、第１決定部１２０５、第２決定部１２０８により通知すると決定されたアクセスログを監査者に対して通知する。
【０１４４】
時間差算出部１２０４は、取得部１２０１が取得したリクエストデータがクライアントＰＣ１０２から送信された時刻と、当該リクエストデータに含まれる参照元ＵＲＬに対してリクエストデータが送信された時刻との時間差を算出する。
【０１４５】
第１決定部１２０５は、時間差算出部１２０４により算出された時間差に応じて、監査者に対してアクセスログを通知するか否かを決定する。
【０１４６】
時間差設定受付部１２０６は、第１決定部１２０５がアクセスログを通知するか否かを決定するための基準となる時間差の設定を受け付ける。
【０１４７】
中継制御部１２０７は、クライアントＰＣ１０２から送信されるリクエストデータの中継の可否を決定する。
【０１４８】
第２決定部１２０８は、中継制御部１２０７により決定された中継の可否により、当該リクエストデータにかかるアクセスログを監査者に通知するか否かを決定する。
【０１４９】
記憶部１２０９は、クライアントＰＣ１０２から送信されたリクエストデータをログとして記憶する。
【０１５０】
検索条件受付部１２１０は、記憶部１２０９に記憶されたログデータを検索するための条件の設定を監査者等から受け付ける。
【０１５１】
抽出部１２１１は、検索条件受付部１２１０で受け付けた検索条件に合致するログデータを、記憶部１２０９に記憶されたログデータから抽出する。
＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。
【０１５２】
第１の実施形態においては、自動除外解析がＯＮである場合には、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮して、アクセスログを表示するか否かを判断した。
【０１５３】
これに対して第２の実施形態は、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間については考慮せず、リクエストデータにＲｅｆｅｒｅＵＲＬが含まれるか否かによって、アクセスログを表示するか否かを判断する実施形態である。
【０１５４】
すなわち、第１の実施形態における条件設定画面（図９）では、自動除外解析時間の設定が可能であったが、第２の実施形態における条件設定画面（不図示）では、当該設定ができない画面となる（自動除外解析をするか否かの設定のみが可能な画面となる）。
【０１５５】
図１３は、本発明の第２の実施形態において、プロキシサーバ１０１がアクセスログテーブルに記録されたアクセスログのうち、アクセスが禁止されたログをクライアントＰＣ１０２に表示処理を示すフローチャートである。すなわち、第１の実施形態における図８に代わるフローチャートである。
【０１５６】
なお、図１３のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【０１５７】
ステップＳ１３０１〜ステップＳ１３０７に示す処理については、図８におけるステップＳ８０１〜Ｓ８０７に示す処理と同じ処理である。そのため、ここでの説明は省略する。
【０１５８】
ステップＳ１３０８では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１３０４で読み込んだアクセスログにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。
【０１５９】
ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ１３０８：ＹＥＳ）は、処理をステップＳ１３１０へ移行する。
【０１６０】
ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ１３０８：ＮＯ）は、処理をステップＳ１３０９へ移行する。
【０１６１】
ステップＳ１３０９では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１３０４で読み込んだアクセスログをクライアントＰＣ１０２に表示するべく、クライアントＰＣ１０２に送信する。
【０１６２】
ステップＳ１３１０では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１３０４で読み込んだアクセスログが、アクセスログテーブルに記録されたアクセスログのうち最後のアクセスログであるか否かを判断する。
【０１６３】
最後のアクセスログであると判断されると（ステップＳ１３１０：ＹＥＳ）、本フローチャートに示す処理を終了する。
【０１６４】
最後のアクセスログではないと判断されると（ステップＳ１３１０：ＮＯ）、処理をステップＳ１３０４に移行し、次のアクセスログを１行読み込む。
【０１６５】
以上のように、第２の実施形態における処理は、第１の実施形態におけるステップＳ８０９およびステップＳ８１０に示す処理を実行しないものである。これにより、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間にかかわらず、リクエストデータにＲｅｆｅｒｅｒＵＲＬが存在するアクセスログについては表示対象としないことが可能となる。
【０１６６】
図１４に示す画面は、第２の実施形態における図１３のステップＳ１３１１の処理によりクライアントＰＣ１０２に表示される画面である。
【０１６７】
アクセスログテーブル（図５）におけるログＩＤ：１、２、８のアクセスログが表示されている。
【０１６８】
すなわち、設定された時刻条件を満たすログのうち、「アクセスが禁止されたログであり、かつＲｅｆｅｒｅｒＵＲＬが記録されていないログ」および、「アクセスが禁止されたログであり、ＧＥＴメソッドではないログ」が表示される。
【０１６９】
以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを監査者へ通知することが可能なる。その結果、適切なログ管理が可能となる。
【０１７０】
具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、ユーザによる意図的なアクセス（リンク先をクリックする等）ではなく、ブラウザが自動的にデータを取得した可能性が高いといえる。
【０１７１】
このように、ＲｅｆｅｒｅｒＵＲＬの有無により、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては通知・表示をしないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。それにより、効率的なログ管理が可能となる。
【０１７２】
さらに、本実施形態においては、ステップＳ１３０７においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、表示対象ログとしている。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）場合については、ＲｅｆｅｒｅｒＵＲＬの有無に関わらず、意図的なアクセスであることが多いためである。このステップＳ１３０７における判断処理により、監査に有用なログを表示させることが可能となる。
【０１７３】
なお、本発明の目的は、監査に有用ではないアクセスログを表示させないことであるため、ステップＳ１３０７における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。
＜第３の実施形態＞
次に、本発明の第３の実施形態について説明する。
【０１７４】
第３の実施形態は、リクエストデータにＲｅｆｅｒｅｒＵＲＬが含まれるか否かにより、当該リクエストに関するアクセスログを残すか否かを判断するものである。
【０１７５】
第１および第２の実施形態においては、全てのリクエストに関するアクセスログを残し（図３参照）、当該ログを表示させる際にＲｅｆｅｒｅｒＵＲＬの有無や、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮して表示させるか否かを判断した（図８、図１３参照）。
【０１７６】
第３の実施形態では、ＲｅｆｅｒｅｒＵＲＬの有無によりアクセスログを残すか否かを決定する構成について説明する。
【０１７７】
図１５は、本発明の第３の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２から送信されたリクエストデータを受信し、当該リクエストにかかるアクセスログを記録する処理を示すフローチャートである。すなわち、第１および第２の実施形態における図３のフローチャートに代わる図である。
【０１７８】
なお、図１５のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【０１７９】
ステップＳ１５０１では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータを取得し、当該リクエストデータからアクセス先となるＵＲＬを取得する。
【０１８０】
ステップＳ１５０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したアクセス先ＵＲＬがアクセスルールテーブル（図４）に存在するか否かを判定する。すなわち、当該アクセス先ＵＲＬについて、いずれかのアクセスルールが適用されるか否かを判定する。
【０１８１】
アクセスルールテーブルに存在すると判定された場合（ステップＳ１５０２：ＹＥＳ）は、処理をステップＳ１５０４へ移行する。
【０１８２】
他方、アクセスルールテーブルに存在しないと判断された場合（ステップＳ１５０２：ＮＯ）は、処理をステップＳ１５０３に移行する。
【０１８３】
ステップＳ１５０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０２で適用されると判定されたアクセスルールについて、その動作がアクセスを禁止（データ中継を許可しない）であるか否かを判定する。
【０１８４】
ステップＳ１５０３においてアクセスを許可すると判定された場合（ステップＳ１５０３：許可）は、処理をステップＳ１５０４に移行する。
【０１８５】
他方、ステップＳ１５０３においてアクセスを禁止すると判定された場合（ステップＳ１５０３：禁止）は、処理をステップＳ１５０６に移行する。
【０１８６】
ステップＳ１５０４では、プロキシサーバ１０１のＣＰＵ２０１は、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したアクセス先ＵＲＬが示すウェブサーバ１０５にアクセスをする。
【０１８７】
ステップＳ１５０５では、プロキシサーバ１０１のＣＰＵ２０１は、ウェブサーバ１０５からレスポンスデータを取得し、当該レスポンスデータをリクエスト元であるクライアントＰＣ１０２に送信する。
そして、本フローチャートに示す処理を終了する。
【０１８８】
ステップＳ１５０６では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したＨＴＴＰリクエストデータのメソッドがＧＥＴメソッドであるか否かを判断する。
【０１８９】
ＧＥＴメソッドであると判断された場合（ステップＳ１５０６：ＹＥＳ）は、処理をステップＳ１５０７に移行する。
【０１９０】
ＧＥＴメソッドではないと判断された場合（ステップＳ１５０６：ＮＯ）は、処理をステップＳ１５０８に移行する。
【０１９１】
ステップＳ１５０７では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１５０１で取得したリクエストデータにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。
【０１９２】
ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ１５０７：ＹＥＳ）は、処理をステップＳ１５０９に移行する。
【０１９３】
ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ１５０７：ＮＯ）は、処理をステップＳ１５０８に移行する。
【０１９４】
ステップＳ１５０８では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣからリクエストされたＵＲＬに対するアクセスが禁止された旨の結果をアクセスログテーブル（図１８）に記録する。
【０１９５】
この際、アクセスログテーブルには、アクセスが禁止された旨の結果（ルール結果）だけでなく、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣを識別する情報（ＩＰアドレス等）（クライアントＩＰアドレス）、アクセス先ＵＲＬ等についても記録される。
【０１９６】
ステップＳ１５０９では、プロキシサーバ１０１のＣＰＵ２０１は、リクエスト元であるクライアントＰＣ１０２に対してアクセスが禁止された旨の結果を示すＨＴＴＰレスポンスデータを送信する。
そして、本フローチャートに示す処理を終了する。
【０１９７】
なお、本実施形態では、アクセスルールテーブルに設定されていないＵＲＬへのアクセスについては、アクセスを許可するように構成しているが、デフォルト処理としてアクセス禁止として設定をしておき、その設定に従って処理を行うように構成しても良い。
【０１９８】
以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを記録することが可能なる。これにより、適切なログ管理が可能となる。
【０１９９】
具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、ユーザによる意図的なアクセス（リンク先をクリックする等）ではなく、ブラウザが自動的にデータを取得した可能性が高いといえる。
【０２００】
このように、ＲｅｆｅｒｅｒＵＲＬの有無により、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては記録として残さないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。これにより、効率的なログ管理が可能となる。
【０２０１】
さらに、本実施形態においては、ステップＳ１５０６においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、記録としてログを残している。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）については、ＲｅｆｅｒｅｒＵＲＬの有無に関わらず、意図的なアクセスであることが多いためである。このステップＳ１５０６における判断処理により、監査に有用なログを記録することが可能となる。
【０２０２】
なお、本発明の目的は、監査に有用ではないアクセスログについては登録しない（記録として残さない）ことであるため、ステップＳ１５０６における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。
【０２０３】
また、監査に必要なログと不要なログとをアクセスログを記録する際に判断する構成を採ることで、ログを表示させる際の判断が不要となる。このように、不要なログを記録しないことで、プロキシサーバ等の資源（記憶領域等）を有効に利用することが可能となる。
【０２０４】
図２２は、本発明の第３の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２にアクセスログを表示するべくクライアントＰＣ１０２にアクセスログを送信する処理を示すフローチャートである。
【０２０５】
なお、図２２のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【０２０６】
ステップＳ２２０１では、プロキシサーバ１０１のＣＰＵ２０１は、ユーザからアクセスログの検索条件の設定を受け付ける。なお、検索条件の設定については、クライアントＰＣ１０２に表示される検索条件設定画面（図２３）を介して受け付ける。
【０２０７】
ここで、図２３に一例を示す検索条件設定画面について説明する。
【０２０８】
図２３に示す画面では、アクセスログを検索する条件として、アクセス時刻の時刻条件（期間や時間範囲）の設定が可能である。
【０２０９】
図２３に示す例では、アクセスログテーブルに記録されたアクセス時刻が、「２０１０年１０月１日（金）〜２０１０年１０月２８日（木）」までの期間であり、「００時００分〜２４時００分」まで（終日）のログが検索されることを示している。
【０２１０】
ステップＳ２２０２では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ２２０１で受け付けた検索条件に合致するアクセスログをアクセスログテーブルから抽出する。
【０２１１】
ステップＳ２２０３では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ２２０２で抽出されたアクセスログを、クライアントＰＣ１０２で表示すべくクライアントＰＣ１０２に送信する。
【０２１２】
以上の処理により送信されたアクセスログをクライアントＰＣ１０２が受信すると、クライアントＰＣ１０２には、図１４に一例を示す画面が表示される（表示される画面は第２の実施形態と同じである）。
＜第４の実施形態＞
次に、本発明の第４の実施形態について説明する。
【０２１３】
第４の実施形態は、リクエストデータにＲｅｆｅｒｅｒＵＲＬが含まれるか否か、およびＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間によって、当該リクエストに関するアクセスログを残すか否かを判断するものである。
【０２１４】
すなわち、第３の実施形態においては、ＲｅｆｅｒｅｒＵＲＬが含まれるリクエストデータにかかるアクセスログについては全て記録を残さなかった（ログを記憶しなかった）が、第４の実施形態においては、ＲｅｆｅｒｅｒＵＲＬが含まれるリクエストデータにかかるアクセスログについても、当該ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間によってログを記憶するか否かを決定する。
【０２１５】
図１６は、本発明の第４の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２から送信されたリクエストデータを受信し、当該リクエストにかかるアクセスログを記録する処理を示すフローチャートである。
【０２１６】
なお、図１６のフローチャートで示す処理については、プロキシサーバ１０１のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【０２１７】
なお、ステップＳ１６０１〜Ｓ１６０６の処理については、第３の実施形態における図１５のステップＳ１５０１〜Ｓ１５０６と同じ処理であるため、ここでの説明は省略する。
【０２１８】
ステップＳ１６０７では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１６０１で取得したリクエストデータにＲｅｆｅｒｅｒＵＲＬが記録されているか否かを判断する。
【０２１９】
ＲｅｆｅｒｅｒＵＲＬが記録されていると判断された場合（ステップＳ１６０７：ＹＥＳ）は、処理をステップＳ１６０８に移行する。
【０２２０】
ＲｅｆｅｒｅｒＵＲＬが記録されていないと判断された場合（ステップＳ１６０７：ＮＯ）は、処理をステップＳ１６０９に移行する。
【０２２１】
ステップＳ１６０８では、プロキシサーバ１０１のＣＰＵ２０１は、ステップＳ１６０１で取得したリクエストデータの送信時刻と、ステップＳ１６０７で判断されたＲｅｆｅｒｅｒＵＲＬへのアクセス時刻との差が、図２０に示す閾値を超えるか否かを判断する。すなわち、ＲｅｆｅｒｅｒＵＲＬへのアクセスから閾値を超える時間を経過した後のアクセスであるかを判断する。なお、図２０に示す閾値は、図２１に示す設定画面を介して監査者等により設定される。
【０２２２】
ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻から閾値を超える時間が経過していると判断された場合（ステップＳ１６０８：ＹＥＳ）は、処理をステップＳ１６０９に移行する。
【０２２３】
ＲｅｆｅｒｅｒＵＲＬへのアクセス時刻からの経過時間が閾値を超えないと判断された場合（ステップＳ１６０８：ＮＯ）は、処理をステップＳ１６１０に移行する。
【０２２４】
ステップＳ１６０９では、プロキシサーバ１０１のＣＰＵ２０１は、クライアントＰＣから送信されたＵＲＬに対するアクセスが禁止された旨の結果をアクセスログテーブル（図１９）に記録する。
【０２２５】
この際、アクセスログテーブルには、アクセスが禁止された旨の結果（ルール結果）だけでなく、クライアントＰＣ１０２からＨＴＴＰリクエストデータが送信された時刻（アクセス時刻）、ＨＴＴＰリクエストデータを送信したクライアントＰＣを識別する情報（ＩＰアドレス等）（クライアントＩＰアドレス）、アクセス先ＵＲＬ等についても記録される。
【０２２６】
また、クライアントＰＣ１０２から送信されたＨＴＴＰリクエストデータに「ＲｅｆｅｒｅｒＵＲＬ（参照元ＵＲＬ）」が含まれる場合には、当該ＲｅｆｅｒｅｒＵＲＬもあわせて記録される。
【０２２７】
ステップＳ１６１０では、プロキシサーバ１０１のＣＰＵ２０１は、リクエスト元であるクライアントＰＣ１０２に対してアクセスが禁止された旨の結果を示すＨＴＴＰレスポンスデータを送信する。
そして、本フローチャートに示す処理を終了する。
【０２２８】
以上の処理により、ユーザ（閲覧者）が意図的にアクセスしたログのみを記録することが可能なる。これにより、適切なログ管理が可能となる。
【０２２９】
具体的には、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスは、ユーザによる意図的なアクセスではなく、ブラウザが自動的にアクセスした可能性が高い。ただ、ＲｅｆｅｒｅｒＵＲＬが記録されたリクエストデータにかかるアクセスのすべてが意図的ではないアクセスとは言えず、ＲｅｆｅｒｅｒＵＲＬが記録されていたとしても意図的なアクセスである可能性はある。そこで、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮し、ＲｅｆｅｒｅｒＵＲＬが記録されたアクセスであっても意図的なアクセスであるか否かを判断する。
【０２３０】
すなわち、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間が短い場合には、自動的にブラウザがリクエストをしたログである可能性が高い。他方、ＲｅｆｅｒｅｒＵＲＬへのアクセスから一定時間が経過した後のアクセスについては、ユーザによる意図的なアクセス（リンク先をクリックした等）である可能性が高いといえる。そのため、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間を考慮することで、意図的なアクセスであるか否かを適切に判断することが可能となる。
【０２３１】
このように、意図的なアクセスであるか否かを判断し、意図的ではないアクセスのログについては記録として残さないようにすることで、監査者が大量のログに紛れてしまった有用なログを探し出す手間を低減することが可能となる。その結果、効率的なログ管理が可能となる。
【０２３２】
さらに、本実施形態においては、ステップＳ１６０６においてリクエストが「ＧＥＴメソッドであるか否か」の判断をして、ＧＥＴメソッドではない場合には、表示対象ログとしている。これは、ＧＥＴメソッドではない（例えばＰＯＳＴ等）については、ＲｅｆｅｒｅｒＵＲＬの有無や、ＲｅｆｅｒｅｒＵＲＬへのアクセスからの経過時間に関わらず、意図的なアクセスであることが多いためである。このステップＳ１６０６における判断処理により、監査に有用なログを表示させることが可能となる。
【０２３３】
なお、本発明の目的は、監査に有用ではないアクセスログを表示させないことであるため、ステップＳ１６０６における処理は、本発明の目的を達成するために必須の処理でなく、省略したとしても本発明の目的は達成される。
【０２３４】
また、監査に必要なログと不要なログとをアクセスログを記録する際に判断する構成を採ることで、ログを表示させる際の判断が不要となる。このように、不要なログを記録しないことで、プロキシサーバ等の資源（記憶領域等）を有効に利用することが可能となる。
【０２３５】
第４の実施形態において、プロキシサーバ１０１がクライアントＰＣ１０２にアクセスログを表示するべく、クライアントＰＣ１０２にアクセスログを送信する処理については、図２２のフローチャートで示す（第３の実施形態と同じ処理である）。
【０２３６】
第４の実施形態において、図２２の処理により送信されたアクセスログをクライアントＰＣ１０２が受信した際にクライアントＰＣ１０２に表示される画面については、図１１に示す画面である（第１の実施形態と同じ画面である）。
【０２３７】
ここで、図１７を参照して、ＨＴＴＰリクエストデータの構成について説明する。図１７に示すようにＨＴＴＰデータのリクエスト行１７０１、１７０２には、メソッド（図１７の例ではＧＥＴメソッド）、宛先となるＵＲＬ情報（リクエストＵＲＬ）、ＨＴＴＰのバージョン情報が設定される。
【０２３８】
本発明の第１〜第４の実施形態では、このリクエスト行１７０１、１７０２に設定されているＵＲＬ情報をアクセス先ＵＲＬとして中継制御ルールと照合する。
【０２３９】
またＲｅｆｅｒｅｒ１７０３には、このＨＴＴＰデータの送信元となったＵＲＬ情報（ＲｅｆｅｒｅｒＵＲＬ（参照元ＵＲＬ））が設定される。本発明の第１〜第４の実施形態では、ＨＴＴＰデータに、このＲｅｆｅｒｅｒ１７０３が記録されているか否かを判断する。
【０２４０】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０２４１】
また、本発明におけるプログラムは、図３、図６〜図８の処理方法をコンピュータが実行可能なプログラムである。なお、本発明におけるプログラムは図３、図６〜図８の各装置の処理方法ごとのプログラムであってもよい。
【０２４２】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
【０２４３】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
【０２４４】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。
【０２４５】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２４６】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２４７】
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０２４８】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０２４９】
１０１ プロキシサーバ
１０２ クライアント端末
１０３ ＬＡＮ
１０４ 広域ネットワーク
１０５ ウェブサーバ
【特許請求の範囲】
【請求項１】
端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、
前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断手段と、
前記参照元判断手段により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記参照元判断手段により、前記取得手段で取得されたデータ取得要求に当該データ取得要求の参照元を示す情報が含まれていると判断された場合、当該データ取得要求が送信された時刻と、当該データ取得要求の参照元に対してデータ取得要求が送信された時刻との時間差を算出する時間差算出手段と、
前記時間差算出手段により算出された時間差に応じて、前記取得手段が取得した前記データ取得要求について前記通知手段による通知を行うか否かを決定する第１の決定手段とをさらに備え、
前記通知手段は、前記第１の決定手段により通知を行うと決定された前記データ取得要求を、監査者に対して特定可能に通知することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第１の決定手段は、前記時間差算出手段により算出された時間差が、所定の時間差を超えた場合、前記取得手段が取得した前記データ取得要求について前記通知手段による通知を行うと決定することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記所定の時間差の設定を受け付ける時間差設定受付手段をさらに備え、
前記第１の決定手段は、前記時間差算出手段により算出された時間差が、前記時間設定受付手段により設定を受け付けた時間差を超えた場合、前記取得手段が取得した前記データ取得要求について前記通知手段による通知を行うと決定することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記端末装置から送信されたデータ取得要求の中継の可否を決定するための中継制御ルールに基づき、前記端末装置から送信されたデータ取得要求の中継の可否を決定する中継制御手段と、
前記中継制御手段により決定された中継の可否に応じて、前記取得手段が取得したデータ取得要求について前記通知手段による通知を行うか否かを決定する第２の決定手段とをさらに備え、
前記通知手段は、さらに、前記第２の決定手段が通知を行うと決定した前記データ取得要求を、監査者に対して特定可能に通知すること特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記端末装置からデータ取得要求が送信された時刻と、当該データ取得要求におけるデータ取得要求先を示す情報とを含む、前記データ取得要求のログデータを記憶する記憶手段をさらに備えることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
前記記憶手段は、前記通知手段による通知が行われない前記データ取得要求のログデータを記憶しないことを特徴とする請求項６に記載の情報処理装置。
【請求項８】
検索条件を受け付ける検索条件受付手段と、
前記検索条件受付手段で受け付けた検索条件に合致する前記ログデータを前記記憶手段から抽出する抽出手段とをさらに備え、
前記通知手段は、前記抽出手段で抽出されたログデータを監査者に対して通知することを特徴とする請求項６または７に記載の情報処理装置。
【請求項９】
前記検索条件受付手段により受け付ける検索条件は、時刻条件を含むことを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
情報処理装置の取得手段が、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得工程と、
前記情報処理装置の参照元判断手段が、前記取得工程により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断工程と、
前記情報処理装置の通知手段が、前記参照元判断工程により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知工程と、
を備えることを特徴とする情報処理方法。
【請求項１１】
情報処理装置を、
端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、
前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断手段と、
前記参照元判断手段により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知手段として機能させることを特徴とするプログラム。
【請求項１】
端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、
前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断手段と、
前記参照元判断手段により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記参照元判断手段により、前記取得手段で取得されたデータ取得要求に当該データ取得要求の参照元を示す情報が含まれていると判断された場合、当該データ取得要求が送信された時刻と、当該データ取得要求の参照元に対してデータ取得要求が送信された時刻との時間差を算出する時間差算出手段と、
前記時間差算出手段により算出された時間差に応じて、前記取得手段が取得した前記データ取得要求について前記通知手段による通知を行うか否かを決定する第１の決定手段とをさらに備え、
前記通知手段は、前記第１の決定手段により通知を行うと決定された前記データ取得要求を、監査者に対して特定可能に通知することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第１の決定手段は、前記時間差算出手段により算出された時間差が、所定の時間差を超えた場合、前記取得手段が取得した前記データ取得要求について前記通知手段による通知を行うと決定することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記所定の時間差の設定を受け付ける時間差設定受付手段をさらに備え、
前記第１の決定手段は、前記時間差算出手段により算出された時間差が、前記時間設定受付手段により設定を受け付けた時間差を超えた場合、前記取得手段が取得した前記データ取得要求について前記通知手段による通知を行うと決定することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記端末装置から送信されたデータ取得要求の中継の可否を決定するための中継制御ルールに基づき、前記端末装置から送信されたデータ取得要求の中継の可否を決定する中継制御手段と、
前記中継制御手段により決定された中継の可否に応じて、前記取得手段が取得したデータ取得要求について前記通知手段による通知を行うか否かを決定する第２の決定手段とをさらに備え、
前記通知手段は、さらに、前記第２の決定手段が通知を行うと決定した前記データ取得要求を、監査者に対して特定可能に通知すること特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記端末装置からデータ取得要求が送信された時刻と、当該データ取得要求におけるデータ取得要求先を示す情報とを含む、前記データ取得要求のログデータを記憶する記憶手段をさらに備えることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
前記記憶手段は、前記通知手段による通知が行われない前記データ取得要求のログデータを記憶しないことを特徴とする請求項６に記載の情報処理装置。
【請求項８】
検索条件を受け付ける検索条件受付手段と、
前記検索条件受付手段で受け付けた検索条件に合致する前記ログデータを前記記憶手段から抽出する抽出手段とをさらに備え、
前記通知手段は、前記抽出手段で抽出されたログデータを監査者に対して通知することを特徴とする請求項６または７に記載の情報処理装置。
【請求項９】
前記検索条件受付手段により受け付ける検索条件は、時刻条件を含むことを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
情報処理装置の取得手段が、端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得工程と、
前記情報処理装置の参照元判断手段が、前記取得工程により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断工程と、
前記情報処理装置の通知手段が、前記参照元判断工程により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知工程と、
を備えることを特徴とする情報処理方法。
【請求項１１】
情報処理装置を、
端末装置からウェブサーバに対して送信されるデータ取得要求を取得する取得手段と、
前記取得手段により取得されたデータ取得要求に、当該データ取得要求の参照元ＵＲＬが含まれるか否かを判断する参照元判断手段と、
前記参照元判断手段により参照元ＵＲＬが含まれないと判断される前記端末装置からのデータ取得要求を、監査者に対して特定可能に通知する通知手段として機能させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１２−１４６２８３（Ｐ２０１２−１４６２８３Ａ）
【公開日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願番号】特願２０１１−２１６７４２（Ｐ２０１１−２１６７４２）
【出願日】平成２３年９月３０日（２０１１．９．３０）
【出願人】（３９０００２７６１）キヤノンマーケティングジャパン株式会社 (656)
【出願人】（３１２０００２０６）キヤノンＭＪアイティグループホールディングス株式会社 (259)
【出願人】（５９２１３５２０３）キヤノンＩＴソリューションズ株式会社 (528)
【Ｆターム（参考）】
【公開日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願日】平成２３年９月３０日（２０１１．９．３０）
【出願人】（３９０００２７６１）キヤノンマーケティングジャパン株式会社 (656)
【出願人】（３１２０００２０６）キヤノンＭＪアイティグループホールディングス株式会社 (259)
【出願人】（５９２１３５２０３）キヤノンＩＴソリューションズ株式会社 (528)
【Ｆターム（参考）】
[ Back to top ]