(57)【要約】      （修正有）【課題】アクセスしようとするリンク先が悪性のリソースであることを自動的に判別する。【解決手段】情報処理装置は、ユーザ宛のメールデータを取得する取得部８０１と、メールデータに含まれるリンクデータを抽出する第１抽出部８０３と、抽出されたリンクデータが指すリソースの悪性を照会する照会部８０７と、悪性に係るリンクデータをリストに記録する記録処理部８０９と、転送すべきアクセス要求を、ユーザの端末から受け付ける受付部と、リストを参照し、アクセス要求のアクセス先が悪性に係るリンクデータに該当するか否かを判定する判定部とを有する。【選択図】図８
2016148967.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ宛のメールデータを取得する取得部と、
前記メールデータに含まれるリンクデータを抽出する抽出部と、
抽出された前記リンクデータが指すリソースの悪性を照会する照会部と、
前記悪性に係るリンクデータをリストに記録する記録部と、
転送すべきアクセス要求を、前記ユーザの端末から受け付ける受付部と、
前記リストを参照し、前記アクセス要求のアクセス先が前記悪性に係る前記リンクデータに該当するか否かを判定する判定部と
を有する情報処理装置。
【請求項２】
更に、
前記アクセス先が、前記悪性に係る前記リンクデータに該当すると判定した場合に、前記アクセス要求の転送を拒否する旨を、前記端末へ通知する通知部
を有する請求項１記載の情報処理装置。
【請求項３】
更に、
前記リソースの前記悪性を点検する点検部
を有し、
前記照会部は、前記点検部に前記リソースの前記悪性を照会する
請求項１又は２記載の情報処理装置。
【請求項４】
更に、
前記点検部が前記リソースに対するアクセスによって得たアクセス結果を、記憶部に格納する格納処理部と、
新規のアクセス先へのアクセス要求を受け付け、且つ当該アクセス先が前記悪性に係る前記リンクデータに該当しないと判定した場合に、前記記憶部に格納された前記アクセス結果を前記端末へ送信する送信部と
を有する請求項３記載の情報処理装置。
【請求項５】
前記アクセス結果を前記端末へ送信した後に、前記アクセス結果を前記記憶部から消去する消去部
を有する請求項４記載の情報処理装置。
【請求項６】
更に、
２回目以降のアクセス先へのアクセス要求を受け付け、且つ当該アクセス先が前記悪性に係る前記リンクデータに該当しないと判定した場合に、当該アクセス要求を転送する転送部
を有し、
前記送信部は、転送した前記アクセス要求に対するアクセス結果を前記端末へ送信する
請求項４又は５記載の情報処理装置。
【請求項７】
ユーザ宛のメールデータを取得し、
前記メールデータに含まれるリンクデータを抽出し、
抽出された前記リンクデータが指すリソースの悪性を照会し、
前記悪性に係るリンクデータをリストに記録し、
転送すべきアクセス要求を、前記ユーザの端末から受け付け、
前記リストを参照し、前記アクセス要求のアクセス先が、前記悪性に係る前記リンクデータに該当するか否かを判定する
処理を含み、コンピュータにより実行される情報処理方法。
【請求項８】
ユーザ宛のメールデータを取得し、
前記メールデータに含まれるリンクデータを抽出し、
抽出された前記リンクデータが指すリソースの悪性を照会し、
前記悪性に係るリンクデータをリストに記録し、
転送すべきアクセス要求を、前記ユーザの端末から受け付け、
前記リストを参照し、前記アクセス要求のアクセス先が、前記悪性に係る前記リンクデータに該当するか否かを判定する
処理をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リンクによるアクセス誘導を抑制する技術に関する。
【背景技術】
【０００２】
例えばマルウエアを送り込むような危険なＷｅｂサイトのＵＲＬ（Uniform Resource Locator）が貼られたメールが、ユーザ端末に送られて来ることがある。そして、ユーザ端末からそのＵＲＬにアクセスすれば、ユーザ端末はマルウエアに感染することになる。
【０００３】
マルウエアの感染を予防する策として、ＵＲＬを点検するサービスを提供するサイトを利用することが考えられる。この場合、ＵＲＬを指定して当該サイトへ照会すれば、ユーザは当該ＵＲＬが危険であるか否かの回答を得ることができる。
【０００４】
しかし、安全性への意識が低いユーザは、ＵＲＬの点検を怠るかもしれない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平１１−１４９４０５号公報
【特許文献２】特開２０１３−１９１１３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、一側面では、アクセスしようとするリンク先が悪性のリソースであることを自動的に判別することである。
【課題を解決するための手段】
【０００７】
一態様に係る情報処理装置は、ユーザ宛のメールデータを取得する取得部と、メールデータに含まれるリンクデータを抽出する抽出部と、抽出されたリンクデータが指すリソースの悪性を照会する照会部と、悪性に係るリンクデータをリストに記録する記録部と、転送すべきアクセス要求を、上記ユーザの端末から受け付ける受付部と、リストを参照し、アクセス要求のアクセス先が悪性に係るリンクデータに該当するか否かを判定する判定部とを有する。
【発明の効果】
【０００８】
一側面としては、アクセスしようとするリンク先が悪性のリソースであることを自動的に判別することができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、ネットワーク構成の第１例を示す図である。
【図２】図２は、ネットワーク構成の第２例を示す図である。
【図３】図３は、確認フェーズにおけるシーケンス例を示す図である。
【図４】図４は、中継フェーズにおけるシーケンス例を示す図である。
【図５】図５は、確認フェーズにおけるシーケンス例を示す図である。
【図６】図６は、中継フェーズにおけるシーケンス例を示す図である。
【図７】図７は、プロキシサーバのモジュール構成例を示す図である。
【図８】図８は、確認部のモジュール構成例を示す図である。
【図９】図９は、確認処理フローの例を示す図である。
【図１０】図１０は、中継部のモジュール構成例を示す図である。
【図１１】図１１は、中継処理フローの例を示す図である。
【図１２】図１２は、メールサーバのモジュール構成例を示す図である。
【図１３】図１３は、開示処理フローの例を示す図である。
【図１４】図１４は、配送処理フローの例を示す図である。
【図１５】図１５は、ネットワーク構成の第３例を示す図である。
【図１６】図１６は、実施の形態２の確認フェーズにおけるシーケンス例を示す図である。
【図１７】図１７は、実施の形態２の確認フェーズにおけるシーケンス例を示す図である。
【図１８】図１８は、実施の形態２における確認部のモジュール構成例を示す図である。
【図１９】図１９は、実施の形態２における確認処理フローの例を示す図である。
【図２０】図２０は、実施の形態３の確認フェーズにおけるシーケンス例を示す図である。
【図２１】図２１は、実施の形態３の中継フェーズにおけるシーケンス例を示す図である。
【図２２】図２２は、実施の形態３の中継フェーズにおけるシーケンス例を示す図である。
【図２３】図２３は、実施の形態３におけるプロキシサーバのモジュール構成例を示す図である。
【図２４】図２４は、実施の形態３における確認部のモジュール構成例を示す図である。
【図２５】図２５は、キャッシュデータの例を示す図である。
【図２６】図２６は、実施の形態３における確認処理フローの例を示す図である。
【図２７】図２７は、実施の形態３における中継部のモジュール構成例を示す図である。
【図２８】図２８は、実施の形態３における中継処理フローの例を示す図である。
【図２９】図２９は、実施の形態４の確認フェーズにおけるシーケンス例を示す図である。
【図３０】図３０は、実施の形態４の中継フェーズにおけるシーケンス例を示す図である。
【図３１】図３１は、実施の形態４の中継フェーズにおけるシーケンス例を示す図である。
【図３２】図３２は、実施の形態４の中継フェーズにおけるシーケンス例を示す図である。
【図３３】図３３は、実施の形態４における確認部のモジュール構成例を示す図である。
【図３４】図３４は、実施の形態４におけるキャッシュデータの例を示す図である。
【図３５】図３５は、実施の形態４における確認処理フローの例を示す図である。
【図３６】図３６は、実施の形態４における中継部のモジュール構成例を示す図である。
【図３７】図３７は、実施の形態４における中継処理フローの例を示す図である。
【図３８】図３８は、実施の形態４における中継処理フローの例を示す図である。
【図３９】図３９は、コンピュータの機能ブロック図である。
【発明を実施するための形態】
【００１０】
［実施の形態１］
図１に、ネットワーク構成の第１例を示す。ＬＡＮ（Local Area Network）は、例えば社内ネットワークに相当する。ＬＡＮは、プロキシサーバ１０１を介してインターネットに接続されている。プロキシサーバ１０１は、ＬＡＮ内のユーザ端末１０３からインターネットへのアクセスを代行する。つまり、プロキシサーバ１０１は、ユーザ端末１０３からインターネット上のＷｅｂサーバ１０５へ送られるアクセス要求を中継するとともに、当該Ｗｅｂサーバ１０５からユーザ端末１０３へ返されるアクセス結果を中継する。アクセス要求は、例えばＨＴＴＰ（Hypertext Transfer Protocol）リクエストである。アクセス結果は、例えばＨＴＴＰレスポンスである。
【００１１】
インターネット上のＷｅｂサーバ１０５の中には、ユーザにとって危険なものがある。危険なＷｅｂサーバ１０５は、例えばアクセス要求を発信した装置にマルウエアを送り込む。図１において、Ｗｅｂサーバ１０５ａは危険であると想定する。同じく、Ｗｅｂサーバ１０５ｂは危険でない、つまり安全であると想定する。
【００１２】
インターネットに接続している点検サーバ１０７は、Ｗｅｂサーバ１０５を指すＵＲＬに基づいて、Ｗｅｂサーバ１０５が危険であるか、あるいは安全であるかを点検する。点検サーバ１０７は、例えばＷｅｂサーバ１０５にアクセスした際の当該Ｗｅｂサーバ１０５の挙動に基づいて、当該Ｗｅｂサーバ１０５の危険性を判定する。あるいは、点検サーバ１０７は、予め危険なＷｅｂサーバ１０５を指すＵＲＬを記憶しておき、そのＵＲＬと一致する場合に、危険なＵＲＬであると判定してもよい。
【００１３】
また、危険なＷｅｂサーバ１０５ａへ誘導しようとする者が、ユーザ宛にメールを送ることがある。本実施の形態では、ユーザ端末１０３を使用するユーザ宛てのメールが、ＬＡＮ上に設けられているメールサーバ１０９に一旦蓄積されるものとする。ユーザがユーザ端末１０３のメーラーを操作して、メーラーがメールサーバ１０９からメールを受け取る。この例におけるユーザ端末１０３は、オペレーティングシステム、メーラー及びブラウザを有するものとする。
【００１４】
例えば、ユーザ端末１０３において受け取ったメールデータの本文に、危険なＷｅｂサーバ１０５ａを指すＵＲＬが記述されている場合に、当該ＵＲＬによって危険なＷｅｂサーバ１０５ａにアクセスすると、ユーザ端末１０３はマルウエアに感染してしまう。このように、例えばメールの本文にＵＲＬを記述することを、ＵＲＬを貼るということもある。メールの本文におけるＵＲＬをクリックすることによって、オペレーティングシステムを介してブラウザを呼び出して、ブラウザにアクセス先から得たコンテンツを表示させる動作は、従来のハイパーリンクの技術による。
【００１５】
本実施の形態では、ユーザ端末１０３においてメールデータを受け取る前に、プロキシサーバ１０１が、メールサーバ１０９に蓄積されているメールをチェックする。そして、プロキシサーバ１０１は、危険なＵＲＬをブラックリストに記録する。その後、ユーザ端末１０３から発せられたアクセス要求を中継する際に、プロキシサーバ１０１は、危険なＵＲＬへのアクセス要求を判別し、アクセス要求の転送を拒否する。
【００１６】
図１に示したネットワーク構成の場合には、プロキシサーバ１０１は、インターネット上に設けられた点検サーバ１０７を用いて、ＵＲＬの危険性に関する点検結果を得る。
【００１７】
図２に、別のネットワーク構成例を示す。この例では、点検サーバ１０７がＬＡＮ上に設けられている。このようなネットワーク構成の場合には、プロキシサーバ１０１は、ＬＡＮ上に設けられた点検サーバ１０７を用いて、ＵＲＬの危険性に関する点検結果を得る。
【００１８】
ユーザ端末１０３に感染したマルウエアは、例えばユーザ端末１０３に保存されているデータを盗み、あるいは改ざんすることがある。但し、ユーザにとって好ましくないＷｅｂサーバ１０５は、このようにマルウエアを送り込むタイプに限らない。例えば、詐欺や不正な勧誘を目的とするコンテンツや、その他の有害情報を含むコンテンツを提供するＷｅｂサーバ１０５も、ユーザにとって好ましくない。プロキシサーバ１０１は、このような悪性を点検する点検サーバ１０７を用いるようにしてもよい。例えば、点検サーバ１０７は、アクセス結果に所定のキーワードが含まれる場合に、そのアクセス結果の発信元に相当するＵＲＬは悪性を有すると判定する。この例におけるＵＲＬの危険性に関する点検は、ＵＲＬの悪性に関する点検の一態様である。従って、プロキシサーバ１０１は、以下の例で述べる「危険」を「悪性」と置き換え、更に「安全」を「良性」と置き換えて動作するようにしてもよい。
【００１９】
続いて、本実施の形態におけるシーケンスについて説明する。まず、メールに危険なＷｅｂサーバ１０５ａのＵＲＬ（危険なＵＲＬの例）が記述されていた場合の確認フェーズと中継フェーズについて説明する。以下で説明する確認フェーズでは、新着のメールが事前に確認される。中継フェーズでは、ユーザ端末１０３から送られる危険なアクセス要求が拒否される。但し、アクセス要求が安全であれば、正常に中継される。
【００２０】
図３に、メールに危険なＵＲＬが記述されていた場合の確認フェーズにおけるシーケンス例を示す。プロキシサーバ１０１は、メールサーバ１０９へメールデータの開示を要求する（Ｓ３０１）。このときプロキシサーバ１０１からメールサーバ１０９へ送られる要求を、第１要求という。例えば、第１要求には、プロキシサーバ１０１を認証するためのデータが含まれる。プロキシサーバ１０１は、更に、第１要求にユーザを特定するデータ（例えば、メールアドレスあるいはユーザＩＤ）を含めるようにしてもよい。
【００２１】
メールサーバ１０９は、プロキシサーバ１０１から第１要求を受けると（Ｓ３０３）、プロキシサーバ１０１を認証する。プロキシサーバ１０１の認証が成功すると、メールサーバ１０９は、新着のメールデータを抽出して、プロキシサーバ１０１へ送る。新着のメールデータとは、未だプロキシサーバ１０１へ送信されていないメールデータのことである。第１要求に、ユーザを特定するデータが含まれている場合には、メールサーバ１０９は、新着のメールデータのうち、当該ユーザ宛のメールデータを抽出して、送信するようにしてもよい。
【００２２】
プロキシサーバ１０１は、メールサーバ１０９からメールデータを受信する（Ｓ３０５）。プロキシサーバ１０１は、メールデータからＵＲＬを抽出する（Ｓ３０７）。プロキシサーバ１０１は、例えばメールの本文に含まれる「ｈｔｔｐ：」の文字列を検索し、ＵＲＬを抽出する。
【００２３】
プロキシサーバ１０１は、点検サーバ１０７へＵＲＬに関する安全性を照会する（Ｓ３０９）。このとき、プロキシサーバ１０１から点検サーバ１０７へ点検対象のＵＲＬが送られる（Ｓ３１１）。
【００２４】
点検サーバ１０７は、ＵＲＬに関する安全性を点検する（Ｓ３１３）。具体的には、点検サーバ１０７は、ＵＲＬが指すＷｅｂサーバ１０５ａへアクセス要求を送り（Ｓ３１５）、Ｗｅｂサーバ１０５ａからアクセス結果を受ける（Ｓ３１７）。点検サーバ１０７は、このときのＷｅｂサーバ１０５ａの挙動に基づいて、Ｗｅｂサーバ１０５ａがマルウエアを送り込む疑いがあるか否かを判定する。Ｗｅｂサーバ１０５ａがマルウエアを送り込む疑いがある場合には、点検サーバ１０７は、ＵＲＬが指すリソースへのアクセスは危険であると判定する。
【００２５】
この例では、Ｗｅｂサーバ１０５ａへのアクセスであるので、点検サーバ１０７は、点検対象のＵＲＬが危険であると判定する（Ｓ３１９）。点検対象のＵＲＬが危険であると判定した場合には、点検サーバ１０７からプロキシサーバ１０１へ「危険」を示す点検結果が送られる（Ｓ３２１）。
【００２６】
「危険」を示す点検結果を受けると、プロキシサーバ１０１は、危険であると判定されたＵＲＬをブラックリストに記録する（Ｓ３２３）。
【００２７】
次に、図４に、危険なＵＲＬをアクセス先とするアクセス要求が送られる場合の中継フェーズにおけるシーケンス例を示す。ユーザ端末１０３は、メールサーバ１０９からユーザ宛のメールを受け取る（Ｓ４０１）。このときユーザ端末１０３からメールサーバ１０９へ送られる要求を、第２要求という。第２要求には、例えばユーザを識別するためのアカウントデータが含まれる。
【００２８】
メールサーバ１０９は、第２要求を受信すると（Ｓ４０３）、第２要求に含まれるアカウントデータに基づいて、ユーザ宛のメールデータを抽出する（Ｓ４０５）。そして、メールサーバ１０９は、抽出したメールデータをユーザ端末１０３へ送信する（Ｓ４０７）。
【００２９】
メールサーバ１０９は、メールデータを受信すると、例えばメールのタイトルを並べたメールリストを表示する（Ｓ４０９）。そして、ユーザがいずれかのタイトルを選択する操作を行うと、ユーザ端末１０３は、メールの本文を表示する（Ｓ４１１）。このとき、表示されたメールの本文に含まれるＵＲＬをユーザがクリックすると（Ｓ４１３）、ユーザ端末１０３からプロキシサーバ１０１へ、アクセス要求が送られる（Ｓ４１５）。アクセス要求には、アクセス先に相当するＵＲＬが含まれる。
【００３０】
プロキシサーバ１０１は、アクセス要求を受けて、アクセス先に相当するＵＲＬがブラックリストにあるか否かを判定する。アクセス先に相当するＵＲＬがブラックリストにあると判定した場合には（Ｓ４１７）、プロキシサーバ１０１は、アクセス要求の転送を拒否する（Ｓ４１９）。従って、アクセス要求は中継されない。そして、プロキシサーバ１０１は、ユーザ端末１０３へ拒否通知を送る（Ｓ４２１）。
【００３１】
ユーザ端末１０３は、拒否通知を受けると、指示されたＵＲＬへのアクセスが拒否された旨のエラー表示を行う（Ｓ４２３）。
【００３２】
続いて、メールに安全なＷｅｂサーバ１０５ｂのＵＲＬ（安全なＵＲＬの例）が記述されていた場合の確認フェーズと中継フェーズについて説明する。図５に、メールに安全なＵＲＬが記述されていた場合の確認フェーズにおけるシーケンス例を示す。Ｓ３０１乃至Ｓ３１１の処理は、図３の場合と同様である。
【００３３】
点検サーバ１０７は、ＵＲＬに関する安全性を点検する（Ｓ５０１）。点検サーバ１０７は、例えばＵＲＬが指すＷｅｂサーバ１０５ｂへアクセス要求を送り（Ｓ５０３）、Ｗｅｂサーバ１０５ｂからアクセス結果を受ける（Ｓ５０５）。
【００３４】
Ｗｅｂサーバ１０５ｂがマルウエアを送り込む疑いがない場合には、点検サーバ１０７は、ＵＲＬが指すリソースへのアクセスは安全であると判定する。ＵＲＬが安全であると判定した場合には（Ｓ５０７）。点検サーバ１０７からプロキシサーバ１０１へ「安全」を示す点検結果が送られる（Ｓ５０９）。
【００３５】
「安全」を示す点検結果を受けた場合には、プロキシサーバ１０１は、安全であると判定されたＵＲＬをブラックリストに記録しない。
【００３６】
次に、図６に、安全なＵＲＬをアクセス先とするアクセス要求が送られる場合の中継フェーズにおけるシーケンス例を示す。Ｓ４０１乃至Ｓ４１５のシーケンスは、図４の場合と同様である。図６において、Ｓ４０５乃至Ｓ４１１のシーケンスは省略する。
【００３７】
アクセス先に相当するＵＲＬがブラックリストにないと判定した場合には（Ｓ６０１）、プロキシサーバ１０１は、アクセス要求の転送を拒否しない。従って、プロキシサーバ１０１は、Ｓ４１５において受けたアクセス要求をＷｅｂサーバ１０５ｂへ転送する（Ｓ６０３）。
【００３８】
Ｗｅｂサーバ１０５ｂは、アクセス要求を受けると（Ｓ６０５）、アクセス要求に対する応答に相当するアクセス結果を送る（Ｓ６０７）。
【００３９】
プロキシサーバ１０１は、アクセス結果を受けると、受けたアクセス結果をユーザ端末１０３へ送信する（Ｓ６０９）。
【００４０】
ユーザ端末１０３は、アクセス結果を受けると（Ｓ６１１）、アクセス結果に基づいてコンテンツを出力する（Ｓ６１３）。ユーザ端末１０３は、例えばＨＴＭＬ（HyperText Markup Language）文書を表示する。以上で、シーケンスについての説明を終える。
【００４１】
次に、プロキシサーバ１０１について説明する。図７に、プロキシサーバ１０１のモジュール構成例を示す。プロキシサーバ１０１は、ユーザ記憶部７０１、確認部７０３、リスト記憶部７０５及び中継部７０７を有する。ユーザ記憶部７０１は、ＬＡＮに接続しているユーザ端末１０３を使用しているユーザ、つまりメールサーバ１０９を用いてメールの発信及び着信を行っているユーザに関するリスト（以下、ユーザリストという。）を記憶している。ユーザリストには、メールサーバ１０９を利用しているユーザを識別するデータ（例えば、メールアドレスあるいはユーザＩＤ）が設定されている。
【００４２】
但し、メールサーバ１０９を利用しているユーザを区別せずに、メールデータを一括して処理する場合には、ユーザ記憶部７０１を設けないようにしてもよい。
【００４３】
確認部７０３は、メールサーバ１０９によって開示される着信メールの危険性を確認する。リスト記憶部７０５は、危険なＵＲＬを記録したブラックリストを記憶する。中継部７０７は、ユーザ端末１０３からインターネットへ送られるアクセス要求を中継するとともに、インターネットからユーザ端末１０３へ送られるアクセス結果を中継する。また、中継部７０７は、受け付けたアクセス要求のアクセス先に危険なＵＲＬが設定されているか否かを判定し、アクセス先に危険なＵＲＬが設定されているアクセス要求の転送を拒否する。
【００４４】
以下、確認部７０３について詳述する。図８に、確認部７０３のモジュール構成例を示す。確認部７０３は、取得部８０１、第１抽出部８０３、制御部８０５、照会部８０７及び記録処理部８０９を有する。取得部８０１は、メールサーバ１０９によって開示されたメールデータを取得する。第１抽出部８０３は、メールデータからＵＲＬを抽出する。制御部８０５は、確認部７０３による確認処理を制御する。照会部８０７は、ＵＲＬに関する安全性を照会する。記録処理部８０９は、危険なＵＲＬをブラックリストに記録する。
【００４５】
上述した確認部７０３、中継部７０７、取得部８０１、第１抽出部８０３、制御部８０５、照会部８０７及び記録処理部８０９は、ハードウエア資源（例えば、図３９）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【００４６】
上述したユーザ記憶部７０１及びリスト記憶部７０５は、ハードウエア資源（例えば、図３９）を用いて実現される。
【００４７】
次に、確認部７０３による確認処理について説明する。図９に、確認処理フローの例を示す。取得部８０１は、メールデータの開示を要求するために、第１要求をメールサーバ１０９へ送る（Ｓ９０１）。第１要求には、プロキシサーバ１０１を認証するためのデータ（例えば、機器ＩＤ）が含まれる。取得部８０１は、ユーザ記憶部７０１に記憶されているユーザリストで管理されているユーザを識別するデータ（例えば、メールアドレスあるいはユーザＩＤ）を第１要求に含めるようにしてもよい。
【００４８】
取得部８０１は、新着のメールデータを受信する（Ｓ９０３）。受信したメールデータは、１つ又は複数のメールに相当する。第１抽出部８０３は、受信したメールデータからＵＲＬを抽出する（Ｓ９０５）。第１抽出部８０３は、例えばメールデータの本文に含まれるスキーム名「ｈｔｔｐ：」の文字列を検索し、ＵＲＬのデータ形式に基づいてＵＲＬを抽出する。但し、他のスキーム名を検索するようにしてもよい。抽出されるＵＲＬは、１つあるいは複数である。
【００４９】
制御部８０５は、抽出されたＵＲＬのうち、処理対象となるＵＲＬを１つ特定する（Ｓ９０７）。照会部８０７は、点検サーバ１０７へＵＲＬに関する安全性を照会する（Ｓ９０９）。このとき、プロキシサーバ１０１から点検サーバ１０７へ、点検対象のＵＲＬが送られる。
【００５０】
そして、照会部８０７は、点検サーバ１０７から点検結果を受信する（Ｓ９１１）。記録処理部８０９は、受信した点検結果が「危険」を示しているか否かを判定する（Ｓ９１３）。受信した点検結果が「危険」を示していると判定した場合には、記録処理部８０９は、点検対象のＵＲＬをブラックリストに記録する（Ｓ９１５）。そして、Ｓ９１７の処理に移る。
【００５１】
一方、受信した点検結果が「危険」を示していないと判定した場合、つまり点検結果が「安全」を示している場合には、点検対象のＵＲＬは、ブラックリストに記録されない。そして、Ｓ９１７の処理に移る。
【００５２】
制御部８０５は、Ｓ９０５において抽出されたＵＲＬのうち未処理のＵＲＬがあるか否かを判定する（Ｓ９１７）。未処理のＵＲＬがあると判定した場合には、Ｓ９０７に示した処理に戻って、上述した処理を繰り返す。
【００５３】
一方、未処理のＵＲＬがないと判定した場合には、Ｓ９０１に示した処理に戻って、上述した処理を繰り返す。
【００５４】
続いて、中継部７０７について詳述する。図１０に、中継部７０７のモジュール構成例を示す。中継部７０７は、受付部１００１、判定部１００３、通知部１００５、転送部１００７、第１受信部１００９及び第１送信部１０１１を有する。
【００５５】
受付部１００１は、ユーザ端末１０３から中継すべきアクセス要求を受け付ける。判定部１００３は、各種の判定を行なう。通知部１００５は、アクセス要求の発信元の装置へ、アクセス要求の拒否を通知する。転送部１００７は、アクセス先の装置へアクセス要求を転送する。第１受信部１００９は、アクセス先の装置からアクセス結果を受信する。第１送信部１０１１は、アクセス要求の発信元の装置へアクセス結果を送信する。
【００５６】
上述した受付部１００１、判定部１００３、通知部１００５、転送部１００７、第１受信部１００９及び第１送信部１０１１は、ハードウエア資源（例えば、図３９）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【００５７】
続いて、中継部７０７による中継処理について説明する。尚、中継処理は、上述した確認処理と並行して実行される。図１１に、中継部７０７による中継処理フローの例を示す。受付部１００１は、待機して、ユーザ端末１０３から中継すべきアクセス要求を受信する（Ｓ１１０１）。判定部１００３は、受信したアクセス要求のアクセス先に相当するＵＲＬを特定する（Ｓ１１０３）。判定部１００３は、特定したＵＲＬをキーとしてブラックリストを検索する（Ｓ１１０５）。そして、判定部１００３は、特定したＵＲＬがブラックリストに記録されていたか否かを判定する（Ｓ１１０７）。特定したＵＲＬがブラックリストに記録されていたと判定した場合には、転送部１００７は、アクセス要求を転送しない。その代わりに、通知部１００５は、拒否通知をユーザ端末１０３へ送信する（Ｓ１１０９）。そして、Ｓ１１０１に示した処理に戻って、上述した処理を繰り返す。
【００５８】
一方、特定したＵＲＬがブラックリストに記録されていないと判定した場合には、転送部１００７は、Ｓ１１０１において受信したアクセス要求を転送する（Ｓ１１１１）。第１受信部１００９は、アクセス先のＷｅｂサーバ１０５からアクセス結果を受信する（Ｓ１１１３）。第１送信部１０１１は、受信したアクセス結果を、アクセス要求の発信元であるユーザ端末１０３へ送信する（Ｓ１１１５）。そして、Ｓ１１０１に示した処理に戻って、上述した処理を繰り返す。以上で、プロキシサーバ１０１についての説明を終える。
【００５９】
次に、メールサーバ１０９について説明する。図１２に、メールサーバ１０９のモジュール構成例を示す。メールサーバ１０９は、第２受信部１２０１、着信処理部１２０３、メール記憶部１２０５、開示部１２０７、第２送信部１２１３及び配送部１２１５を有する。
【００６０】
第２受信部１２０１は、プロキシサーバ１０１から第１要求を受信するとともに、ユーザ端末１０３から第２要求を受信する。着信処理部１２０３は、着信したメールデータをメール記憶部１２０５に書く。メール記憶部１２０５は、メールデータを記憶する。
【００６１】
開示部１２０７は、プロキシサーバ１０１にメールデータを開示するための処理を行う。開示部１２０７は、第１認証部１２０９及び第２抽出部１２１１を有する。第１認証部１２０９は、プロキシサーバ１０１を認証する。第２抽出部１２１１は、開示されるメールデータを抽出する。
【００６２】
第２送信部１２１３は、開示されるメールデータをプロキシサーバ１０１へ送信するとともに、ユーザ宛のメールデータをユーザ端末１０３へ送信する。
【００６３】
配送部１２１５は、ユーザ端末１０３にメールデータを配送するための処理を行う。配送部１２１５は、第２認証部１２１７、第３抽出部１２１９及び第１消去部１２２１を有する。第２認証部１２１７は、ユーザを認証する。第３抽出部１２１９は、ユーザ宛のメールデータを抽出する。第１消去部１２２１は、ユーザに送信したメールデータを消去する。
【００６４】
上述した第２受信部１２０１、着信処理部１２０３、開示部１２０７、第１認証部１２０９、第２抽出部１２１１、第２送信部１２１３、配送部１２１５、第２認証部１２１７、第３抽出部１２１９及び第１消去部１２２１は、ハードウエア資源（例えば、図３９）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【００６５】
また、上述したメール記憶部１２０５は、ハードウエア資源（例えば、図３９）を用いて実現される。
【００６６】
以下、メールサーバ１０９の処理について説明する。尚、着信処理部１２０３により新着のメールデータをメール記憶部１２０５に記憶する処理は、従来技術と同様であるので、説明を省略する。
【００６７】
開示部１２０７の処理について説明する。図１３に、開示処理フローの例を示す。第２受信部１２０１は、待機して、プロキシサーバ１０１から第１要求を受信する（Ｓ１３０１）。第１認証部１２０９は、受信した第１要求に含まれる認証データ（例えば、機器ＩＤ）に基づいて、プロキシサーバ１０１を認証する（Ｓ１３０３）。認証が失敗すると、開示部１２０７は、Ｓ１３０５乃至Ｓ１３０７の処理を行わずに、Ｓ１３０１の処理に戻る。
【００６８】
認証が成功すると、第２抽出部１２１１は、開示されるメールデータを抽出する（Ｓ１３０５）。具体的には、第２抽出部１２１１は、未だプロキシサーバ１０１に開示していないメールデータを抽出する。Ｓ１３０１において受信した第１要求にユーザを識別するデータ（例えば、メールアドレスあるいはユーザＩＤ）が含まれる場合には、当該ユーザ宛のメールデータを抽出するようにしてもよい。
【００６９】
第２送信部１２１３は、抽出したメールデータをプロキシサーバ１０１へ送信する（Ｓ１３０７）。
【００７０】
次に、配送部１２１５の処理について説明する。尚、配送部１２１５の処理は、上述した開示部１２０７の処理と並行する。図１４に、配送処理フローの例を示す。第２受信部１２０１は、待機して、ユーザ端末１０３から第２要求を受信する（Ｓ１４０１）。第２認証部１２１７は、第２要求に含まれるアカウントデータに基づいて、ユーザを認証する（Ｓ１４０３）。認証が失敗すると、配送部１２１５は、Ｓ１４０５乃至Ｓ１４０９の処理を行わずに、Ｓ１４０１の処理に戻る。
【００７１】
認証が成功すると、第３抽出部１２１９は、認証したユーザ宛のメールデータを抽出する（Ｓ１４０５）。具体的には、第３抽出部１２１９は、未だ当該ユーザに送信していないメールデータを抽出する。第２送信部１２１３は、抽出したメールデータを送信する（Ｓ１４０７）。そして、この例では、第１消去部１２２１が、送信したメールデータを消去する（Ｓ１４０９）。但し、配送部１２１５は、送信したメールデータを消去しないようにしてもよい。また、メールデータを消去するタイミングは、限定されない。
【００７２】
本実施の形態によれば、ユーザが着信メールに貼られたリンク先にアクセスしようとする場合に、当該リンク先が悪性のリソースであることを自動的に判別できる。プロキシサーバ１０１がＬＡＮを利用するユーザ宛のメールを一括してチェックすれば、ＬＡＮ全体の安全性を担保できるという面もある。
【００７３】
更に、悪性のリソースへのアクセスを未然に防ぐことができる。
【００７４】
［実施の形態２］
上述した実施の形態では、プロキシサーバ１０１が点検サーバ１０７を用いてＵＲＬを点検する例について説明したが、本実施の形態では、点検サーバ１０７を用いずに、プロキシサーバ１０１が点検サーバ１０７を兼ねる例について説明する。
【００７５】
本実施の形態では、図１５に示したネットワーク構成の第３例を前提とする。この例では、プロキシサーバ１０１が図１及び図２に示した点検サーバ１０７に相当する機能を有する。つまり、プロキシサーバ１０１は、ＵＲＬが指すリソースの危険性を点検する点検部を有する。そして、プロキシサーバ１０１は、ＵＲＬが指すリソースの危険性を自ら点検する。
【００７６】
続いて、実施の形態２におけるシーケンスについて説明する。図１６に、メールに危険なＵＲＬが記述されていた場合の確認フェーズにおけるシーケンス例を示す。Ｓ３０１乃至Ｓ３０７の処理は、図３の場合と同様である。
【００７７】
プロキシサーバ１０１は、プロキシサーバ１０１自身に含まれる点検部に安全性を照会する（Ｓ１６０１）。プロキシサーバ１０１は、自らＵＲＬに関する安全性を点検する（Ｓ１６０３）。このとき、プロキシサーバ１０１は、例えばＵＲＬが指すＷｅｂサーバ１０５ａへアクセス要求を送り（Ｓ１６０５）、Ｗｅｂサーバ１０５ａからアクセス結果を受ける（Ｓ１６０７）。点検の手順は、点検サーバ１０７の場合と同様である。
【００７８】
点検対象のＵＲＬが危険であると判定した場合には（Ｓ１６０９）。プロキシサーバ１０１は、危険であると判定されたＵＲＬをブラックリストに記録する（Ｓ１６１１）。
【００７９】
尚、危険なＵＲＬをアクセス先とするアクセス要求が送られる場合の中継フェーズにおけるシーケンスは、実施の形態１の場合（図４）と同様である。
【００８０】
次に、図１７を用いて、メールに安全なＵＲＬが記述されていた場合の確認フェーズにおけるシーケンス例について説明する。Ｓ３０１乃至Ｓ３０７の処理は、図３の場合と同様である。プロキシサーバ１０１は、プロキシサーバ１０１自身に含まれる点検部に安全性を照会する（Ｓ１７０１）。プロキシサーバ１０１は、自らＵＲＬに関する安全性を点検する（Ｓ１７０３）。このとき、プロキシサーバ１０１は、例えばＵＲＬが指すＷｅｂサーバ１０５ｂへアクセス要求を送り（Ｓ１７０５）、Ｗｅｂサーバ１０５ｂからアクセス結果を受ける（Ｓ１７０７）。
【００８１】
ＵＲＬが安全であると判定した場合には（Ｓ１７０９）、プロキシサーバ１０１は、安全であると判定されたＵＲＬをブラックリストに記録しない。
【００８２】
尚、安全なＵＲＬをアクセス先とするアクセス要求が送られる場合の中継フェーズにおけるシーケンスは、実施の形態１の場合（図６）と同様である。
【００８３】
また、プロキシサーバ１０１のモジュール構成は、実施の形態１の場合（図７）と同様である。但し、確認部７０３の構成が、実施の形態１の場合（図８）と異なる。
【００８４】
図１８に、実施の形態２における確認部７０３のモジュール構成例を示す。本実施の形態に係る確認部７０３は、点検部１８０１を有する。点検部１８０１は、ＵＲＬに関する安全性を点検する。
【００８５】
上述した点検部１８０１は、ハードウエア資源（例えば、図３９）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【００８６】
続いて、確認部７０３による確認処理について説明する。図１９に、実施の形態２における確認処理フローの例を示す。Ｓ９０１乃至Ｓ９０７の処理は、図９の場合と同様である。
【００８７】
照会部８０７は、点検部１８０１へＵＲＬに関する安全性を照会する（Ｓ１９０１）。このとき、照会部８０７から点検部１８０１へ、点検対象のＵＲＬが渡される。
【００８８】
点検部１８０１は、点検処理を実行する（Ｓ１９０３）。点検部１８０１における点検処理は、点検サーバ１０７における点検処理と同様である。点検部１８０１は、例えば点検対象のＵＲＬが指すＷｅｂサーバ１０５へアクセス要求を送り、Ｗｅｂサーバ１０５からアクセス結果を受ける。点検部１８０１は、このときのＷｅｂサーバ１０５の挙動に基づいて、Ｗｅｂサーバ１０５がマルウエアを送り込む疑いがあるか否かを判定する。Ｗｅｂサーバ１０５がマルウエアを送り込む疑いがある場合には、点検部１８０１は、ＵＲＬが指すリソースへのアクセスが危険であると判定する。Ｗｅｂサーバ１０５がマルウエアを送り込む疑いがない場合には、点検部１８０１は、ＵＲＬが指すリソースへのアクセスが安全であると判定する。
【００８９】
記録処理部８０９は、点検結果が「危険」を示しているか否かを判定する（Ｓ１９０５）。点検結果が「危険」を示していると判定した場合には、記録処理部８０９は、点検対象のＵＲＬをブラックリストに記録する（Ｓ１９０７）。そして、Ｓ９１７の処理に移る。
【００９０】
一方、点検結果が「危険」を示していないと判定した場合、つまり点検結果が「安全」を示している場合には、点検対象のＵＲＬは、ブラックリストに記録されない。そして、Ｓ９１７の処理に移る。
【００９１】
Ｓ９１７の処理は、図９の場合と同様である。
【００９２】
尚、中継部７０７のモジュール構成は、実施の形態１の場合（図１０）と同様である。
【００９３】
中継処理も、実施の形態１の場合（図１１）と同様である。
【００９４】
また、メールサーバ１０９のモジュール構成は、実施の形態１の場合（図１２）と同様である。開示処理も、実施の形態１の場合（図１３）と同様である。また、配送処理も、実施の形態１の場合（図１４）と同様である。
【００９５】
本実施の形態によれば、リンク先の点検に要する通信コストを削減できる。更に、独自の点検基準を設けることができるという面もある。
【００９６】
［実施の形態３］
Ｗｅｂサーバ１０５の中には、１回目のアクセス要求に限って、当該アクセス要求に応えるものがある。このように、１回限り有効なアクセスに用いられるＵＲＬを、ワンタイムＵＲＬという。
【００９７】
しかし、確認フェーズにおいて、プロキシサーバ１０１の点検部１８０１がワンタイムＵＲＬを用いてＷｅｂサーバ１０５にアクセスすれば、それ以降このワンタイムＵＲＬは無効となる。つまり、中継フェーズにおいて、ユーザがワンタイムＵＲＬを用いてアクセスしようとしても失敗することになる。あるいは、期待したアクセス結果が得られない。例えば、初回のアクセスに限ってパスワードを提供するサービスの場合には、２回目のアクセスにおいてパスワードは提供されない。
【００９８】
本実施の形態では、このような不具合を解消する。つまり、ワンタイムＵＲＬがメールデータに含まれる場合に、ワンタイムＵＲＬの点検後でもユーザがアクセス結果を得られるようにする。
【００９９】
その為、プロキシサーバ１０１は、確認フェーズにおける最初のアクセスで取得したアクセス結果を、プロキシサーバ１０１に設けられたキャッシュ記憶部に記憶する。そして、ユーザ端末１０３からの最初のアクセス要求に限って、キャッシュ記憶部に蓄えられているアクセス結果を返す。このようにすれば、ユーザ端末１０３からワンタイムＵＲＬに最初にアクセスする場合に、正常にアクセス結果が得られる。
【０１００】
但し、アクセス結果を返した後に、キャッシュ記憶部に蓄えられているアクセス結果は消去される。従って、ユーザ端末１０３から再び同じアクセス要求が送られても、当初のアクセス結果は得られない。
【０１０１】
本実施の形態は、図１５に示したネットワーク構成の第３例を前提とする。尚、プロキシサーバ１０１は、上述したようにキャッシュ記憶部を有する。キャッシュ記憶部については、後述する。
【０１０２】
以下、本実施の形態におけるシーケンスについて説明する。尚、メールに危険なＵＲＬが記述されていた場合の確認フェーズにおけるシーケンスは、実施の形態２の場合（図１６）と同様である。
【０１０３】
また、危険なＵＲＬをアクセス先とするアクセス要求が送られる場合の中継フェーズにおけるシーケンスは、実施の形態１の場合（図４）と同様である。
【０１０４】
図２０に、メールに安全なＵＲＬが記述されていた場合の確認フェーズにおけるシーケンス例を示す。Ｓ３０１乃至Ｓ３０７の処理は、図３の場合と同様である。また、Ｓ１７０１乃至Ｓ１７０９の処理は、図１７の場合と同様である。
【０１０５】
Ｓ１７０３に示したＵＲＬの安全性に関する点検において、点検対象のＵＲＬが安全であると判定した場合には（Ｓ１７０９）、プロキシサーバ１０１は、Ｓ１７０７において受けたアクセス結果を、安全であると判定されたＵＲＬに対応付けてキャッシュ記憶部に格納する（Ｓ２００１）。
【０１０６】
次に、図２１を用いて、安全なＵＲＬをアクセス先とするアクセス要求が初めて送られる場合の中継フェーズにおけるシーケンス例について説明する。Ｓ４０１乃至Ｓ４１５のシーケンスは、図４の場合と同様である。図２１において、Ｓ４０５乃至Ｓ４１１のシーケンスは省略する。
【０１０７】
アクセス先に相当するＵＲＬがブラックリストにないと判定した場合には（Ｓ２１０１）、プロキシサーバ１０１は、アクセス要求を拒否しない。但し、本実施の形態では、アクセス要求を転送する代わりに、キャッシュ記憶部に格納されているアクセス結果を用いる。
【０１０８】
この例では、最初のアクセス要求が送られているので、アクセス結果がキャッシュ記憶部に格納されている。アクセス結果がキャッシュ記憶部に格納されている場合には（Ｓ２１０３）、プロキシサーバ１０１は、キャッシュ記憶部からアクセス結果を読み取る（Ｓ２１０５）。そして、プロキシサーバ１０１は、読み取ったアクセス結果をユーザ端末１０３へ送信する（Ｓ２１０７）。尚、上述した最初のアクセス要求は、プロキシサーバ１０１にとって新規のアクセス要求に相当する。
【０１０９】
ユーザ端末１０３は、アクセス結果を受けると（Ｓ２１０９）、アクセス結果に基づいてコンテンツを出力する（Ｓ２１１１）。ユーザ端末１０３は、例えばＨＴＭＬ文書を表示する。
【０１１０】
アクセス結果をユーザ端末１０３へ送信した後、プロキシサーバ１０１は、当該アクセス結果をキャッシュ記憶部から消去する（Ｓ２１１３）。
【０１１１】
次に、図２２を用いて、安全なＵＲＬをアクセス先とするアクセス要求が再び送られる場合の中継フェーズにおけるシーケンス例について説明する。Ｓ４０１乃至Ｓ４１５のシーケンスは、図４の場合と同様である。図２２において、Ｓ４０５乃至Ｓ４１１のシーケンスは省略する。
【０１１２】
アクセス先に相当するＵＲＬがブラックリストにないと判定した場合には（Ｓ２２０１）、プロキシサーバ１０１は、キャッシュ記憶部にアクセス結果が格納されているか否かを判定する。この例では、最初のアクセス要求に対するアクセス結果が既に送られ、キャッシュ記憶部にアクセス結果が格納されていないものと想定する。キャッシュ記憶部にアクセス結果が格納されていないと判定した場合には（Ｓ２２０３）、プロキシサーバ１０１は、Ｓ４１５で受けたアクセス要求をＷｅｂサーバ１０５ｂへ転送する（Ｓ２２０５）。
【０１１３】
Ｗｅｂサーバ１０５ｂは、アクセス要求を受けると（Ｓ２２０７）、アクセス要求に対する応答に相当するアクセス結果を送る（Ｓ２２０９）。
【０１１４】
プロキシサーバ１０１は、アクセス結果を受けると、受けたアクセス結果をユーザ端末１０３へ送信する（Ｓ２２１１）。
【０１１５】
ユーザ端末１０３は、アクセス結果を受けると（Ｓ２２１３）、アクセス結果に基づいてコンテンツを出力する（Ｓ２２１５）。ユーザ端末１０３は、例えばＨＴＭＬ文書を表示する。以上で、シーケンスについての説明を終える。
【０１１６】
図２３に、実施の形態３におけるプロキシサーバ１０１のモジュール構成例を示す。本実施の形態に係るプロキシサーバ１０１は、上述した通りキャッシュ記憶部２３０１を有する。キャッシュ記憶部２３０１は、アクセス結果をキャッシュデータとして記憶する。キャッシュ記憶部２３０１は、ハードウエア資源（例えば、図３９）を用いて実現される。
【０１１７】
続いて、実施の形態３における確認部７０３について説明する。図２４に、実施の形態３における確認部７０３のモジュール構成例を示す。本実施の形態に係る確認部７０３は、第１格納処理部２４０１を有する。第１格納処理部２４０１は、ＵＲＬの点検結果が安全である場合に、アクセス結果をＵＲＬに対応付けてキャッシュ記憶部２３０１に格納する。第１格納処理部２４０１は、ハードウエア資源（例えば、図３９）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【０１１８】
図２５に、キャッシュデータの例を示す。キャッシュデータは、安全なＵＲＬと、当該ＵＲＬに対応付けられているアクセス結果を含んでいる。
【０１１９】
図２６に、実施の形態３における確認処理フローの例を示す。Ｓ９０１乃至Ｓ９０７の処理は、図９の場合と同様である。また、Ｓ１９０１乃至Ｓ１９０７の処理は、図１９の場合と同様である。
【０１２０】
Ｓ１９０５において点検結果が「危険」を示していないと判定した場合、つまり点検結果が「安全」を示している場合には、第１格納処理部２４０１は、Ｓ１９０３の点検処理において取得したアクセス結果を、安全であると判定されたＵＲＬに対応付けてキャッシュ記憶部２３０１に格納する（Ｓ２６０１）。そして、Ｓ９１７に示した処理に移る。
【０１２１】
Ｓ９１７の処理は、図９の場合と同様である。
【０１２２】
次に、実施の形態３における中継部７０７について説明する。図２７に、実施の形態３における中継部７０７のモジュール構成例を示す。本実施の形態に係る中継部７０７は、読取部２７０１及び第２消去部２７０３を有する。読取部２７０１は、キャッシュ記憶部２３０１からアクセス結果を読み取る。第２消去部２７０３は、キャッシュ記憶部２３０１からアクセス結果を消去する。読取部２７０１及び第２消去部２７０３は、ハードウエア資源（例えば、図３９）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【０１２３】
図２８に、実施の形態３における中継処理フローの例を示す。Ｓ１１０１乃至Ｓ１１０９の処理は、図１１の場合と同様である。
【０１２４】
Ｓ１１０７において、Ｓ１１０３で特定したＵＲＬがブラックリストに記録されていないと判定した場合には、判定部１００３は、Ｓ１１０３において特定したＵＲＬに対応するアクセス結果がキャッシュ記憶部２３０１に格納されているか否かを判定する（Ｓ２８０１）。具体的には、判定部１００３は、Ｓ１１０３において特定したＵＲＬがキャッシュ記憶部２３０１に記憶されている場合に、当該アクセス結果がキャッシュ記憶部２３０１に格納されていると判定する。
【０１２５】
Ｓ１１０３において特定したＵＲＬに対応するアクセス結果がキャッシュ記憶部２３０１に格納されていると判定した場合には、読取部２７０１は、キャッシュ記憶部２３０１からアクセス結果を読み取る（Ｓ２８０３）。第１送信部１０１１は、読み取ったアクセス結果を、アクセス要求の発信元であるユーザ端末１０３へ送信する（Ｓ２８０５）。第２消去部２７０３は、Ｓ２８０３において読み取ったアクセス結果をキャッシュ記憶部２３０１から消去する（Ｓ２８０７）。そして、Ｓ１１０１に示した処理に戻って、上述した処理を繰り返す。
【０１２６】
一方、Ｓ１１０３において特定したＵＲＬに対応するアクセス結果がキャッシュ記憶部２３０１に格納されていないと判定した場合に、転送部１００７は、Ｓ１１０１において受信したアクセス要求を転送する（Ｓ２８０９）。第１受信部１００９は、アクセス先のＷｅｂサーバ１０５からアクセス結果を受信する（Ｓ２８１１）。第１送信部１０１１は、受信したアクセス結果を、アクセス要求の発信元であるユーザ端末１０３へ送信する（Ｓ２８１３）。そして、Ｓ１１０１に示した処理に戻って、上述した処理を繰り返す。
【０１２７】
尚、メールサーバ１０９のモジュール構成は、実施の形態１の場合（図１２）と同様である。開示処理も、実施の形態１の場合（図１３）と同様である。また、配送処理も、実施の形態１の場合（図１４）と同様である。
【０１２８】
本実施の形態によれば、リンク先の点検時に取得した１回目のアクセス結果をユーザの端末へ返すことができる。例えば、ワンタイムＵＲＬへのアクセスの失敗を防げる。
【０１２９】
また、１回目のアクセス結果を再利用することを防げる。例えば、ワンタイムＵＲＬの趣旨が守られる。
【０１３０】
更に、２回目以降のアクセスにおいて、適正なアクセス結果を得ることができる。
【０１３１】
［実施の形態４］
上述した実施の形態では、ユーザ端末１０３によるアクセス要求が初回であるか否かをキャッシュデータの有無で区別する例について説明したが、本実施の形態では、ユーザ端末１０３によるアクセス要求が初回であるか否かを、キャッシュされたアクセス結果及びＵＲＬに対応付けられているフラグで区別する例について説明する。
【０１３２】
この例では、フラグにＯＦＦが設定されていれば、アクセス結果が未だユーザ端末１０３へ送信されていないことを意味する。一方、フラグにＯＮが設定されていれば、アクセス結果が既にユーザ端末１０３へ送信されたことを意味する。
【０１３３】
本実施の形態は、図１５に示したネットワーク構成の第３例を前提とする。例えば、従来技術によってアクセス結果をキャッシュデータとして蓄積するプロキシサーバ１０１を改変することによって、本実施の形態に係るプロキシサーバ１０１を実現するようにしてもよい。
【０１３４】
以下、本実施の形態におけるシーケンスについて説明する。メールに危険なＵＲＬが記述されていた場合の確認フェーズにおけるシーケンスは、実施の形態２の場合（図１６）と同様である。
【０１３５】
また、危険なＵＲＬをアクセス先とするアクセス要求が送られる場合の中継フェーズにおけるシーケンスは、実施の形態１の場合（図４）と同様である。
【０１３６】
図２９に、メールに安全なＵＲＬが記述されていた場合の確認フェーズにおけるシーケンス例を示す。Ｓ３０１乃至Ｓ３０７の処理は、図３の場合と同様である。Ｓ１７０１乃至Ｓ１７０９の処理は、図１７の場合と同様である。
【０１３７】
ＵＲＬが安全であると判定した場合には（Ｓ１７０９）、プロキシサーバ１０１は、Ｓ１７０７において受けたアクセス結果を、安全であると判定されたＵＲＬに対応付けてキャッシュ記憶部２３０１に格納する（Ｓ２９０１）。更に、プロキシサーバ１０１は、格納したアクセス結果に対応するフラグにＯＦＦを設定する（Ｓ２９０３）。
【０１３８】
次に、図３０を用いて、安全なＵＲＬをアクセス先とするアクセス要求が初めて送られる場合の中継フェーズにおけるシーケンス例について説明する。Ｓ４０１乃至Ｓ４１５のシーケンスは、図４の場合と同様である。図３０において、Ｓ４０５乃至Ｓ４１１のシーケンスは省略する。
【０１３９】
アクセス先に相当するＵＲＬがブラックリストにないと判定した場合には（Ｓ３００１）、プロキシサーバ１０１は、キャッシュ記憶部２３０１にアクセス結果が格納されているか否かを判定する。キャッシュ記憶部２３０１にアクセス結果が格納されていると判定した場合には（Ｓ３００３）、プロキシサーバ１０１は、更に、アクセス先に相当するＵＲＬに対応するフラグがＯＮであるかあるいはＯＦＦであるかを判定する。
【０１４０】
ユーザ端末１０３からの最初のアクセス要求を処理する場合には、未だアクセス結果がユーザ端末１０３に送信されていない。従って、アクセス先に相当するＵＲＬに対応するフラグにはＯＦＦが設定されている。アクセス先に相当するＵＲＬに対応するフラグがＯＦＦであると判定した場合には（Ｓ３００５）、プロキシサーバ１０１は、キャッシュ記憶部２３０１からアクセス結果を読み取って（Ｓ３００７）、読み取ったアクセス結果をユーザ端末１０３へ送信する（Ｓ３００９）。
【０１４１】
ユーザ端末１０３は、アクセス結果を受けると（Ｓ３０１１）、アクセス結果に基づいてコンテンツを出力する（Ｓ３０１３）。ユーザ端末１０３は、例えばＨＴＭＬ文書を表示する。
【０１４２】
アクセス結果をユーザ端末１０３へ送信した後に、プロキシサーバ１０１は、Ｓ４１５で受けたアクセス要求に含まれるアクセス先に相当するＵＲＬに対応するフラグにＯＮを設定する（Ｓ３０１５）。
【０１４３】
次に、図３１を用いて、安全なＵＲＬをアクセス先とするアクセス要求が再び送られる場合の中継フェーズにおけるシーケンス例について説明する。この例では、アクセス先のＷｅｂサーバ１０５ｂのリソースが、前回のアクセス以降に更新されているものと想定する。尚、以下では、Ｗｅｂサーバ１０５ｂのリソースが更新されていることを、Ｗｅｂサーバ１０５ｂが更新されているという。Ｓ４０１乃至Ｓ４１５のシーケンスは、図４の場合と同様である。図３１において、Ｓ４０５乃至Ｓ４１１のシーケンスは省略する。
【０１４４】
図３０に示したＳ３００１及びＳ３００３の場合と同様に、アクセス先に相当するＵＲＬがブラックリストにないと判定し（Ｓ３１０１）、更に、アクセス結果がキャッシュ記憶部２３０１に格納されていると判定した場合には（Ｓ３１０３）、プロキシサーバ１０１は、更に、アクセス先に相当するＵＲＬに対応するフラグがＯＮであるかあるいはＯＦＦであるかを判定する。
【０１４５】
例えば、ユーザ端末１０３からの２回目のアクセス要求を処理する場合には、アクセス結果がユーザ端末１０３に既に送信されている。従って、アクセス先に相当するＵＲＬに対応するフラグにはＯＮが設定されている。アクセス先に相当するＵＲＬに対応するフラグがＯＮであると判定した場合には（Ｓ３１０５）、プロキシサーバ１０１は、通常のキャッシュ処理を行う。
【０１４６】
具体的には、プロキシサーバ１０１は、Ｗｅｂサーバ１０５ｂに更新日時を問い合わせ、アクセス先のＷｅｂサーバ１０５ｂが更新されているか否かを判定する。プロキシサーバ１０１は、アクセス先のＷｅｂサーバ１０５ｂにおける更新日時が、前回のアクセス日時より新しければ、アクセス先のＷｅｂサーバ１０５ｂが更新されていると判定する。
【０１４７】
アクセス先のＷｅｂサーバ１０５ｂが更新されていると判定した場合には（Ｓ３１０７）、プロキシサーバ１０１は、Ｓ４１５で受けたアクセス要求をＷｅｂサーバ１０５ｂへ転送する（Ｓ３１０９）。
【０１４８】
Ｗｅｂサーバ１０５ｂは、アクセス要求を受けると（Ｓ３１１１）、アクセス要求に対する応答に相当するアクセス結果を送る（Ｓ３１１３）。
【０１４９】
プロキシサーバ１０１は、アクセス結果を受けると、受けたアクセス結果をユーザ端末１０３へ送信する（Ｓ３１１５）。
【０１５０】
ユーザ端末１０３は、アクセス結果を受けると（Ｓ３１１７）、アクセス結果に基づいてコンテンツを出力する（Ｓ３１１９）。ユーザ端末１０３は、例えばＨＴＭＬ文書を表示する。
【０１５１】
アクセス結果をユーザ端末１０３へ送信した後に、プロキシサーバ１０１は、Ｓ３１１３において受けたアクセス結果を、Ｓ４１５で受けたアクセス要求に含まれるアクセス先に相当するＵＲＬに対応付けてキャッシュ記憶部２３０１に格納する（Ｓ３１２１）。つまり、プロキシサーバ１０１は、アクセス結果を更新する。
【０１５２】
図３２に、安全なＵＲＬをアクセス先とするアクセス要求が再び送られる場合の中継フェーズにおける別のシーケンス例を示す。この例では、アクセス先のＷｅｂサーバ１０５ｂのリソースが、前回のアクセス以降に更新されていないものと想定する。尚、以下では、Ｗｅｂサーバ１０５ｂのリソースが更新されていないことを、Ｗｅｂサーバ１０５ｂが更新されていないという。Ｓ４０１乃至Ｓ４１５のシーケンスは、図４の場合と同様である。図３２において、Ｓ４０５乃至Ｓ４１１のシーケンスは省略する。
【０１５３】
また、Ｓ３２０１乃至Ｓ３２０５のシーケンスは、図３１に示したＳ３１０１乃至Ｓ３１０５の場合と同様である。
【０１５４】
例えば、連続的にアクセスする場合には、アクセス先のＷｅｂサーバ１０５ｂは更新されていないことが多い。アクセス先のＷｅｂサーバ１０５ｂが更新されていないと判定した場合（Ｓ３２０７）、つまりアクセス先のＷｅｂサーバ１０５ｂにおける更新日時が、前回のアクセス日時より古い場合には、プロキシサーバ１０１は、キャッシュ記憶部２３０１からアクセス結果を読み取る（Ｓ３２０９）。そして、プロキシサーバ１０１は、読み取ったアクセス結果をユーザ端末１０３へ送信する（Ｓ３２１１）。
【０１５５】
ユーザ端末１０３は、アクセス結果を受けると（Ｓ３２１３）、アクセス結果に基づいてコンテンツを出力する（Ｓ３２１５）。ユーザ端末１０３は、例えばＨＴＭＬ文書を表示する。以上で、シーケンスについての説明を終える。
【０１５６】
プロキシサーバ１０１のモジュール構成は、実施の形態３の場合（図２３）と同様である。但し、確認部７０３及び中継部７０７の構成が、上述した実施の形態の場合と異なる。
【０１５７】
実施の形態４における確認部７０３について説明する。図３３に、実施の形態４における確認部７０３のモジュール構成例を示す。本実施の形態に係る確認部７０３は、第１設定部３３０１を有する。第１設定部３３０１は、アクセス結果及びＵＲＬに対応するフラグへの設定を行う。第１設定部３３０１は、ハードウエア資源（例えば、図３９）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【０１５８】
また、キャッシュデータの構成も、上述した実施の形態の場合と異なる。図３４に、実施の形態４におけるキャッシュデータの例を示す。実施の形態４におけるキャッシュデータは、安全なＵＲＬと、当該ＵＲＬに対応付けられているアクセス結果の他に、アクセス結果及びＵＲＬに対応するアクセス日時とフラグとを含んでいる。アクセス日時は、当該ＵＲＬにアクセスする度に更新される。つまり、アクセス日時は、前回のアクセスが行われた日時を示す。以下、アクセス日時を更新する処理は省略する。
【０１５９】
図３５に、実施の形態４における確認処理フローの例を示す。Ｓ９０１乃至Ｓ９０７の処理は、図９の場合と同様である。Ｓ１９０１乃至Ｓ１９０７の処理は、図１９の場合と同様である。
【０１６０】
Ｓ１９０５において点検結果が「危険」を示していないと判定した場合、つまり点検結果が「安全」を示している場合には、第１格納処理部２４０１は、Ｓ１９０３の点検処理において取得したアクセス結果を、安全であるＵＲＬに対応付けてキャッシュ記憶部２３０１に格納する（Ｓ３５０１）。更に、第１設定部３３０１は、格納したアクセス結果に対応するフラグにＯＦＦを設定する（Ｓ３５０３）。そして、Ｓ９１７に示した処理に移る。
【０１６１】
Ｓ９１７の処理は、図９の場合と同様である。
【０１６２】
次に、実施の形態４における中継部７０７について説明する。図３６に、実施の形態４における中継部７０７のモジュール構成例を示す。本実施の形態に係る中継部７０７は、第２設定部３６０１及び第２格納処理部３６０３を有する。第２設定部３６０１は、上述したフラグにＯＮあるいはＯＦＦを設定する。第２格納処理部３６０３は、アクセス結果をキャッシュ記憶部２３０１に格納する。第２設定部３６０１及び第２格納処理部３６０３は、ハードウエア資源（例えば、図３９）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。
【０１６３】
図３７に、実施の形態４における中継処理フローの例を示す。Ｓ１１０１乃至Ｓ１１０９の処理は、図１１の場合と同様である。
【０１６４】
Ｓ１１０７において、Ｓ１１０３で特定したＵＲＬがブラックリストに記録されていないと判定した場合には、判定部１００３は、Ｓ１１０３において特定したＵＲＬに対応するアクセス結果がキャッシュ記憶部２３０１に格納されているか否かを判定する（Ｓ３７０１）。具体的には、判定部１００３は、Ｓ１１０３において特定したＵＲＬがキャッシュ記憶部２３０１に記憶されている場合に、当該アクセス結果がキャッシュ記憶部２３０１に格納されていると判定する。
【０１６５】
Ｓ１１０３において特定したＵＲＬに対応するアクセス結果がキャッシュ記憶部２３０１に格納されていると判定した場合には、判定部１００３は、Ｓ１１０３において特定したＵＲＬに対応するフラグがＯＮであるかあるいはＯＦＦであるかを判定する（Ｓ３７０３）。
【０１６６】
Ｓ１１０３において特定したＵＲＬに対応するフラグがＯＦＦであると判定した場合には、読取部２７０１は、Ｓ１１０３において特定したＵＲＬに対応するアクセス結果をキャッシュ記憶部２３０１から読み取る（Ｓ３７０５）。第１送信部１０１１は、読み取ったアクセス結果を、アクセス要求の発信元であるユーザ端末１０３へ送信する（Ｓ３７０７）。第２設定部３６０１は、Ｓ１１０３において特定したＵＲＬに対応するフラグにＯＮを設定する（Ｓ３７０９）。尚、Ｓ３７０５乃至Ｓ３７０９に示した処理は、図３０に示したシーケンスに対応する。そして、Ｓ１１０１に示した処理に戻って、上述した処理を繰り返す。
【０１６７】
Ｓ３７０３において、Ｓ１１０３で特定したＵＲＬに対応するフラグがＯＮであると判定した場合には、端子Ａを介して図３８に示したＳ３８０１の処理に移る。
【０１６８】
判定部１００３は、アクセス先におけるリソースが更新されているか否かを判定する（Ｓ３８０１）。プロキシサーバ１０１は、例えばアクセス先のＷｅｂサーバ１０５におけるリソースの更新日時を取得し、取得した更新日時と前回のアクセス日時とを比較する。プロキシサーバ１０１は、取得した更新日時が、前回のアクセス日時より新しければ、アクセス先のＷｅｂサーバ１０５が更新されていると判定する。一方、プロキシサーバ１０１は、取得した更新日時が前回のアクセス日時より古ければ、アクセス先のＷｅｂサーバ１０５が更新されていないと判定する。
【０１６９】
アクセス先におけるリソースが更新されていると判定した場合には、転送部１００７は、Ｓ１１０１において受信したアクセス要求を転送する（Ｓ３８０３）。第１受信部１００９は、アクセス先のＷｅｂサーバ１０５からアクセス結果を受信する（Ｓ３８０５）。第１送信部１０１１は、受信したアクセス結果を、アクセス要求の発信元であるユーザ端末１０３へ送信する（Ｓ３８０７）。第２格納処理部３６０３は、Ｓ３８０５において受信したアクセス結果を、Ｓ１１０３において特定したＵＲＬに対応付けてキャッシュ記憶部２３０１に格納する（Ｓ３８０９）。フラグは、ＯＮのままである。尚、Ｓ３８０３乃至Ｓ３８０９に示した処理は、図３１に示したシーケンスに対応する。そして、端子Ｂを介して図３７のＳ１１０１に示した処理に戻る。
【０１７０】
一方、アクセス先におけるリソースが更新されていないと判定した場合には、読取部２７０１は、Ｓ１１０３において特定したＵＲＬに対応するアクセス結果をキャッシュ記憶部２３０１から読み取る（Ｓ３８１１）。第１送信部１０１１は、読み取ったアクセス結果を、アクセス要求の発信元であるユーザ端末１０３へ送信する（Ｓ３８１３）。尚、Ｓ３８１１及びＳ３８１３に示した処理は、図３２に示したシーケンスに対応する。そして、端子Ｂを介して図３７のＳ１１０１に示した処理に戻る。
【０１７１】
図３７の説明に戻る。Ｓ３７０１において、Ｓ１１０３で特定したＵＲＬに対応するアクセス結果がキャッシュ記憶部２３０１に格納されていないと判定した場合には、転送部１００７は、Ｓ１１０１において受信したアクセス要求を転送する（Ｓ３７１１）。第１受信部１００９は、アクセス先のＷｅｂサーバ１０５からアクセス結果を受信する（Ｓ３７１３）。第１送信部１０１１は、受信したアクセス結果を、アクセス要求の発信元であるユーザ端末１０３へ送信する（Ｓ３７１５）。第２格納処理部３６０３は、Ｓ３７１３において受信したアクセス結果を、Ｓ１１０３において特定したＵＲＬに対応付けてキャッシュ記憶部２３０１に格納する（Ｓ３７１７）。第２設定部３６０１は、Ｓ１１０３において特定したＵＲＬに対応するフラグにＯＮを設定する（Ｓ３７１９）。尚、Ｓ３７１１乃至Ｓ３７１９に示した処理に対応するシーケンスは省略した。そして、Ｓ１１０１に示した処理に戻る。
【０１７２】
メールサーバ１０９のモジュール構成は、実施の形態１の場合（図１２）と同様である。開示処理も、実施の形態１の場合（図１３）と同様である。また、配送処理も、実施の形態１の場合（図１４）と同様である。
【０１７３】
本実施の形態によれば、リンク先の点検時に取得した１回目のアクセス結果をユーザの端末へ返すことができる。例えば、ワンタイムＵＲＬへのアクセスの失敗を防げる。
【０１７４】
また、１回目のアクセス結果を再利用することを防げる。例えば、ワンタイムＵＲＬの趣旨が守られる。
【０１７５】
更に、２回目以降のアクセスにおいて、適正なアクセス結果を得ることができる。
【０１７６】
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上述の機能ブロック構成はプログラムモジュール構成に一致しない場合もある。
【０１７７】
また、上で説明した各記憶領域の構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ、処理の順番を入れ替えることや複数の処理を並列に実行させるようにしても良い。
【０１７８】
なお、上で述べたプロキシサーバ１０１及びメールサーバ１０９は、コンピュータ装置であって、図３９に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【０１７９】
プロキシサーバ１０１の場合には、コンピュータ装置は、異なるネットワークに接続する２つの通信制御部２５１７を有するようにしてもよい。
【０１８０】
以上述べた本発明の実施の形態をまとめると、以下のようになる。
【０１８１】
本実施の形態に係る情報処理装置は、ユーザ宛のメールデータを取得する取得部と、メールデータに含まれるリンクデータを抽出する抽出部と、抽出されたリンクデータが指すリソースの悪性を照会する照会部と、悪性に係るリンクデータをリストに記録する記録部と、転送すべきアクセス要求を、上記ユーザの端末から受け付ける受付部と、リストを参照し、アクセス要求のアクセス先が悪性に係るリンクデータに該当するか否かを判定する判定部とを有する。
【０１８２】
このようにすれば、ユーザが着信メールに貼られたリンク先にアクセスしようとする場合に、当該リンク先が悪性のリソースであることを自動的に判別できる。
【０１８３】
更に、上記情報処理装置は、アクセス先が、悪性に係るリンクデータに該当すると判定した場合に、アクセス要求の転送を拒否する旨を、上記端末へ通知する通知部を有するようにしてもよい。
【０１８４】
このようにすれば、悪性のリソースへのアクセスを未然に防ぐことができる。
【０１８５】
更に、上記情報処理装置は、リソースの悪性を点検する点検部を有するようにしてもよい。そして、上記照会部は、点検部にリソースの悪性を照会するようにしてもよい。
【０１８６】
このようにすれば、リンク先の点検に要する通信コストを削減できる。更に、独自の点検基準を設けることができるという面もある。
【０１８７】
更に、上記情報処理装置は、点検部がリソースに対するアクセスによって得たアクセス結果を、記憶部に格納する格納処理部を有するようにしてもよい。また、上記情報処理装置は、新規のアクセス先へのアクセス要求を受け付け、且つ当該アクセス先が悪性に係るリンクデータに該当しないと判定した場合に、上記記憶部に格納されたアクセス結果を上記端末へ送信する送信部を有するようにしてもよい。
【０１８８】
このようにすれば、リンク先の点検時に取得した１回目のアクセス結果をユーザの端末へ返すことができる。例えば、ワンタイムＵＲＬへのアクセスの失敗を防げる。
【０１８９】
更に、上記情報処理装置は、アクセス結果を上記端末へ送信した後に、当該アクセス結果を上記記憶部から消去する消去部を有するようにしてもよい。
【０１９０】
このようにすれば、１回目のアクセス結果を再利用することを防げる。例えば、ワンタイムＵＲＬの趣旨が守られる。
【０１９１】
更に、上記情報処理装置は、２回目以降のアクセス先へのアクセス要求を受け付け、且つ当該アクセス先が悪性に係るリンクデータに該当しないと判定した場合に、当該アクセス要求を転送する転送部を有するようにしてもよい。そして、上記送信部は、転送したアクセス要求に対するアクセス結果を上記端末へ送信するようにしてもよい。
【０１９２】
このようにすれば、２回目以降のアクセスにおいて、適正なアクセス結果を得ることができる。
【０１９３】
なお、上で述べた情報処理装置における処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納されるようにしてもよい。尚、中間的な処理結果は、一般的にメインメモリ等の記憶装置に一時保管される。
【０１９４】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１９５】
（付記１）
ユーザ宛のメールデータを取得する取得部と、
前記メールデータに含まれるリンクデータを抽出する抽出部と、
抽出された前記リンクデータが指すリソースの悪性を照会する照会部と、
前記悪性に係るリンクデータをリストに記録する記録処理部と、
転送すべきアクセス要求を、前記ユーザの端末から受け付ける受付部と、
前記リストを参照し、前記アクセス要求のアクセス先が前記悪性に係る前記リンクデータに該当するか否かを判定する判定部と
を有する情報処理装置。
【０１９６】
（付記２）
更に、
前記アクセス先が、前記悪性に係る前記リンクデータに該当すると判定した場合に、前記アクセス要求の転送を拒否する旨を、前記端末へ通知する通知部
を有する付記１記載の情報処理装置。
【０１９７】
（付記３）
更に、
前記リソースの前記悪性を点検する点検部
を有し、
前記照会部は、前記点検部に前記リソースの前記悪性を照会する
付記１又は２記載の情報処理装置。
【０１９８】
（付記４）
更に、
前記点検部が前記リソースに対するアクセスによって得たアクセス結果を、記憶部に格納する格納処理部と、
新規のアクセス先へのアクセス要求を受け付け、且つ当該アクセス先が前記悪性に係る前記リンクデータに該当しないと判定した場合に、前記記憶部に格納された前記アクセス結果を前記端末へ送信する送信部と
を有する付記３記載の情報処理装置。
【０１９９】
（付記５）
前記アクセス結果を前記端末へ送信した後に、前記アクセス結果を前記記憶部から消去する消去部
を有する付記４記載の情報処理装置。
【０２００】
（付記６）
更に、
２回目以降のアクセス先へのアクセス要求を受け付け、且つ当該アクセス先が前記悪性に係る前記リンクデータに該当しないと判定した場合に、当該アクセス要求を転送する転送部
を有し、
前記送信部は、転送した前記アクセス要求に対するアクセス結果を前記端末へ送信する
付記４又は５記載の情報処理装置。
【０２０１】
（付記７）
ユーザ宛のメールデータを取得し、
前記メールデータに含まれるリンクデータを抽出し、
抽出された前記リンクデータが指すリソースの悪性を照会し、
前記悪性に係るリンクデータをリストに記録し、
転送すべきアクセス要求を、前記ユーザの端末から受け付け、
前記リストを参照し、前記アクセス要求のアクセス先が、前記悪性に係る前記リンクデータに該当するか否かを判定する
処理を含み、コンピュータにより実行される情報処理方法。
【０２０２】
（付記８）
ユーザ宛のメールデータを取得し、
前記メールデータに含まれるリンクデータを抽出し、
抽出された前記リンクデータが指すリソースの悪性を照会し、
前記悪性に係るリンクデータをリストに記録し、
転送すべきアクセス要求を、前記ユーザの端末から受け付け、
前記リストを参照し、前記アクセス要求のアクセス先が、前記悪性に係る前記リンクデータに該当するか否かを判定する
処理をコンピュータに実行させるためのプログラム。
【符号の説明】
【０２０３】
１０１  プロキシサーバ    １０３  ユーザ端末
１０５  Ｗｅｂサーバ    １０７  点検サーバ
１０９  メールサーバ    ７０１  ユーザ記憶部
７０３  確認部    ７０５  リスト記憶部
７０７  中継部    ８０１  取得部
８０３  第１抽出部    ８０５  制御部
８０７  照会部    ８０９  記録処理部
１００１  受付部    １００３  判定部
１００５  通知部    １００７  転送部
１００９  第１受信部    １０１１  第１送信部
１２０１  第２受信部    １２０３  着信処理部
１２０５  メール記憶部    １２０７  開示部
１２０９  第１認証部    １２１１  第２抽出部
１２１３  第２送信部    １２１５  配送部
１２１７  第２認証部    １２１９  第３抽出部
１２２１  第１消去部    １８０１  点検部
２３０１  キャッシュ記憶部    ２４０１  第１格納処理部
２７０１  読取部    ２７０３  第２消去部
３３０１  第１設定部    ３６０１  第２設定部
３６０３  第２格納処理部
【図１】
2016148967.tif 000003
【図２】
2016148967.tif 000004
【図３】
2016148967.tif 000005
【図４】
2016148967.tif 000006
【図５】
2016148967.tif 000007
【図６】
2016148967.tif 000008
【図７】
2016148967.tif 000009
【図８】
2016148967.tif 000010
【図９】
2016148967.tif 000011
【図１０】
2016148967.tif 000012
【図１１】
2016148967.tif 000013
【図１２】
2016148967.tif 000014
【図１３】
2016148967.tif 000015
【図１４】
2016148967.tif 000016
【図１５】
2016148967.tif 000017
【図１６】
2016148967.tif 000018
【図１７】
2016148967.tif 000019
【図１８】
2016148967.tif 000020
【図１９】
2016148967.tif 000021
【図２０】
2016148967.tif 000022
【図２１】
2016148967.tif 000023
【図２２】
2016148967.tif 000024
【図２３】
2016148967.tif 000025
【図２４】
2016148967.tif 000026
【図２５】
2016148967.tif 000027
【図２６】
2016148967.tif 000028
【図２７】
2016148967.tif 000029
【図２８】
2016148967.tif 000030
【図２９】
2016148967.tif 000031
【図３０】
2016148967.tif 000032
【図３１】
2016148967.tif 000033
【図３２】
2016148967.tif 000034
【図３３】
2016148967.tif 000035
【図３４】
2016148967.tif 000036
【図３５】
2016148967.tif 000037
【図３６】
2016148967.tif 000038
【図３７】
2016148967.tif 000039
【図３８】
2016148967.tif 000040
【図３９】
2016148967.tif 000041