(57)【要約】【課題】  ウェブメールサービスに関した送信制御システムの運用を容易にし、さらには新規サービスの自動検出と設定対応を行う仕組みを提供すること。【解決手段】  設定情報ウェブメールを送信するために設定すべき複数の設定情報をクライアント端末装置１００に送信する。クライアント端末装置１００は、中継サーバ１１０を介してウェブメールサーバ１５０にアクセスした後、上記複数の設定情報を設定してからウェブメールサーバ１５０に対してウェブメールのソース情報としてのＨＴＴＰリクエストを送信する。中継サーバ１１０は、このＨＴＴＰリクエストを受信してからこのＨＴＴＰリクエストを解析し、上記複数の設定情報のそれぞれについて、その属性名としてＨＴＴＰリクエストに記されている属性名情報を取得する。そして中継サーバ１１０は、取得したそれぞれの属性名情報をメモリに登録する。【選択図】  図１
2010128929.tif 000002
【特許請求の範囲】
【請求項１】
端末装置と、ウェブメールサービスを提供する為のホームページを閲覧可能に提示するウェブメールサーバと、の間のデータ通信を中継する情報処理装置であって、
ウェブメールを送信するために設定すべき複数の設定情報を前記端末装置に送信する送信手段と、
前記ホームページを閲覧すべく前記端末装置が前記情報処理装置を介して前記ウェブメールサーバにアクセスした後、前記端末装置がわで前記複数の設定情報を設定してから前記ウェブメールサーバに対して送信されたウェブメールのソース情報を前記端末装置から受信する受信手段と、
前記ソース情報を分析し、前記複数の設定情報のそれぞれについて、その属性名として前記ソース情報に記されている属性名情報を取得する分析手段と、
前記属性名情報をメモリに登録する登録手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記設定情報には、ウェブメールの件名、送信元、送信先、本文、添付ファイル、が含まれていることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記分析手段は、設定情報と対になって前記ソース情報に記されている文字列を属性名情報として取得する処理を、それぞれの設定情報について行うことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
更に、
設定情報ごとに、前記分析手段が前記属性名情報を取得することができたか否かを示す表示を行う手段を備えることを特徴とする請求項２または３に記載の情報処理装置。
【請求項５】
更に、
設定情報ごとに、対応する属性名情報を表示する手段を備えることを特徴とする請求項２乃至４の何れか１項に記載の情報処理装置。
【請求項６】
前記受信手段が複数のソース情報を受信した場合、
前記分析手段はそれぞれのソース情報について分析処理を行い、それぞれのソース情報が１つのメールを構成するのか、別個のメールを構成するのかを示すセッション識別子を取得し、
前記登録手段は、前記セッション識別子を更に前記メモリに登録する
ことを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
【請求項７】
更に、
前記送信手段、前記受信手段、前記分析手段、前記登録手段は、外部からウェブメールの分析を行うためのモードが設定された場合に動作することを特徴とする請求項１乃至６の何れか１項に記載の情報処理装置。
【請求項８】
更に、
外部からウェブメールの分析を行うためのモードが設定されていない場合に、前記端末装置からソース情報が送信される毎に、このソース情報をログとして登録する手段と、
前記ログとして登録されたソース情報のうち、ウェブメールに係る構成要素を含むソース情報について、ウェブメールの送信に係るソース情報の確からしさを示す評価値を求める手段と、
前記ログとして残すことができないソース情報を特定し、特定したソース情報の評価値が閾値を越えている場合には、この特定したソース情報について前記分析手段が分析した結果を表示する手段と
を備えることを特徴とする請求項１乃至７の何れか１項に記載の情報処理装置。
【請求項９】
前記ソース情報は、ＨＴＴＰリクエストのデータであることを特徴とする請求項１乃至８の何れか１項に記載の情報処理装置。
【請求項１０】
端末装置と、ウェブメールサービスを提供する為のホームページを閲覧可能に提示するウェブメールサーバと、の間のデータ通信を中継する情報処理装置が行う情報処理方法であって、
ウェブメールを送信するために設定すべき複数の設定情報を前記端末装置に送信する送信工程と、
前記ホームページを閲覧すべく前記端末装置が前記情報処理装置を介して前記ウェブメールサーバにアクセスした後、前記端末装置がわで前記複数の設定情報を設定してから前記ウェブメールサーバに対して送信されたウェブメールのソース情報を前記端末装置から受信する受信工程と、
前記ソース情報を分析し、前記複数の設定情報のそれぞれについて、その属性名として前記ソース情報に記されている属性名情報を取得する分析工程と、
前記属性名情報をメモリに登録する登録工程と
を備えることを特徴とする情報処理方法。
【請求項１１】
コンピュータを、請求項１乃至９の何れか１項に記載の情報処理装置が有する各手段として機能させるためのコンピュータプログラム。
【請求項１２】
請求項１１に記載のコンピュータプログラムを格納した、コンピュータが読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＨＴＴＰプロトコルで送信される電子メール（ウェブメール）の送信の許可／拒否を行う送信制御技術に関するものである。
【背景技術】
【０００２】
近年のネットワーク技術の発達により、情報のやりとりにかかるコストが格段に低下する中、個人や各企業では電子メールやウェブサービスといったインターネットを利用した各種サービスを利用することにより、効率的な情報伝達ができるようになった。
【０００３】
しかしながら、特に企業を始めとした組織では、個人情報保護法などの施行により、情報の管理について明確な対応を求められることになっている。例えば、企業における情報漏洩対策として、社内から社外に外部送信する電子メールの内容をチェックし、組織が予め定めた基準に合致した場合のみ、その電子メールの外部への送信を許可するといった送信制御システムを導入することが一般的になっている。
【０００４】
さらには、ＳＭＴＰプロトコルを利用した従来の電子メールに対する送信制御システムだけではなく、情報漏洩の経路としてＨＴＴＰプロトコルを利用したウェブサービスを対象にしたものもある。例えば、インターネット上への電子掲示板システムへの投稿や、ウェブメールサービスを対象にした送信制御システムである。
【０００５】
例えば、特許文献１には、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）でインターネット上のサービスを指定し、そのサービスに対して情報送信を制御することが開示されている。
【０００６】
また、特許文献２には、従来の電子メールの送信制御システムと同等の機能を中継サーバに設置することで、ＳＭＴＰと異なるプロトコルに対しても、ネットワークの利便性を損なうことなく、情報漏洩対策を講じることが開示されている。
【０００７】
しかしながら、ＨＴＴＰを利用したウェブメールサービスを送信制御対象とする場合には、次のような問題がある。例えば、新規サービスサイトの開始、あるいは既存サービスサイトのリニューアルなどが行われると、特許文献１で開示されているようなＵＲＬでサービスを指定するような送信制御システムでは、専門知識を有した者でないとＵＲＬを特定することは困難である。また、組織の管理者が新規サービスサイトに対して直ちに送信制御を実施したいと思っても、現状の送信制御システムには、既存ウェブサービスに特化した設定を予め組み込んでいることが一般的である。そのため、例えば、送信制御システムを開発したメーカーによる設定データベースの更新を待つこととなり、送信制御システムの運用を容易且つ迅速に実施することができないものが多い。
【０００８】
さらに、ＳＭＴＰプロトコルを使用した従来の電子メールとは異なり、ＨＴＴＰプロトコルを使用したウェブメールサービスについては画一的な設計規約等が存在しないため、ウェブメールサービス毎に様々な設計および運用がなされている。
【０００９】
例えば、添付ファイルを送信する事例にしても、メール本文と同時に転送するメールサービスもあれば、事前に添付ファイルだけをメール本文と切り離して転送するメールサービスもある。
【００１０】
また、ＳＭＴＰプロトコルを利用した従来の電子メール送信制御システムと同様に、送信元アドレスや送信先アドレス、Ｃｃ、件名といった意味情報を基準に送信制御を実施しようとした場合、それぞれのウェブメールサービスごとに異なる設定が必要となる。
【特許文献１】特開２００４−３４８２０２号公報
【特許文献２】特開２００７−１８１０３１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
このように、ＳＭＴＰプロトコルを利用した従来の電子メール送信制御システムを、ＨＴＴＰプロトコルを利用したウェブメールサービスに適用しようとした場合、画一的ではない複数のウェブメールサービスに対して画一的に対応させることは容易ではない。また、運用の複雑化や高度化といった問題もある。
【００１２】
また、組織の管理者が未対応のウェブサービスに対して直ちに送信制御を実施したいと思っても、専門知識がない限り容易に設定変更ができる状態でもない。
【００１３】
本発明は、以上の問題に鑑みてなされたものであり、ウェブメールサービスに関した送信制御システムの運用を容易にし、さらには新規サービスの自動検出と設定対応を行う仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明の目的を達成するために、例えば、本発明の情報処理装置は以下の構成を備える。
【００１５】
即ち、端末装置と、ウェブメールサービスを提供する為のホームページを閲覧可能に提示するウェブメールサーバと、の間のデータ通信を中継する情報処理装置であって、
ウェブメールを送信するために設定すべき複数の設定情報を前記端末装置に送信する送信手段と、
前記ホームページを閲覧すべく前記端末装置が前記情報処理装置を介して前記ウェブメールサーバにアクセスした後、前記端末装置がわで前記複数の設定情報を設定してから前記ウェブメールサーバに対して送信されたウェブメールのソース情報を前記端末装置から受信する受信手段と、
前記ソース情報を分析し、前記複数の設定情報のそれぞれについて、その属性名として前記ソース情報に記されている属性名情報を取得する分析手段と、
前記属性名情報をメモリに登録する登録手段と
を備えることを特徴とする。
【００１６】
本発明の目的を達成するために、例えば、本発明の情報処理方法は以下の構成を備える。
【００１７】
即ち、端末装置と、ウェブメールサービスを提供する為のホームページを閲覧可能に提示するウェブメールサーバと、の間のデータ通信を中継する情報処理装置が行う情報処理方法であって、
ウェブメールを送信するために設定すべき複数の設定情報を前記端末装置に送信する送信工程と、
前記ホームページを閲覧すべく前記端末装置が前記情報処理装置を介して前記ウェブメールサーバにアクセスした後、前記端末装置がわで前記複数の設定情報を設定してから前記ウェブメールサーバに対して送信されたウェブメールのソース情報を前記端末装置から受信する受信工程と、
前記ソース情報を分析し、前記複数の設定情報のそれぞれについて、その属性名として前記ソース情報に記されている属性名情報を取得する分析工程と、
前記属性名情報をメモリに登録する登録工程と
を備えることを特徴とする。
【発明の効果】
【００１８】
本発明によれば、ＨＴＴＰプロトコルを利用したウェブメールサービスに対して、従来のＳＭＴＰプロトコルを利用した電子メールの送信制御システムと同等の設定を行うことが容易となる。また、新規サービスをログから自動的に検出し、効率的な送信制御を実施できる等の効果を奏する。
【発明を実施するための最良の形態】
【００１９】
以下、添付図面を参照し、本発明の好適な実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載の構成の具体的な実施例の１つである。
【００２０】
図１は、本実施形態に係る情報処理装置を適用可能なシステムの構成例を示すブロック図である。図１に示す如く、本実施形態に係るシステムは、クライアント端末装置１００、中継サーバ１１０、管理者用端末装置１２０、ＤＢ（データベース）１１１、広域ネットワーク網１４０、ウェブメールサーバ１５０、により構成されている。クライアント端末装置１００、管理者用端末装置１２０、中継サーバ１１０、ＤＢ１１１は何れも、イントラネット１３０に接続されている。そして、イントラネット１３０上に接続されているこれらの装置（ＤＢ１１１を除く）は何れも、中継サーバ１１０を介して広域ネットワーク網１４０に対するデータの送受信を行う。
【００２１】
なお、図１には、以下の説明に必要な構成の一例を示しているので、クライアント端末装置１００や管理者用端末装置１２０の数、広域ネットワーク網１４０の構成、ウェブメールサーバ１５０の数などについては、図１に示したものに限定するものではない。
【００２２】
クライアント端末装置１００は、イントラネット１３０、中継サーバ１１０、広域ネットワーク網１４０を介してウェブメールサーバ１５０に対してアクセスすることができ、ウェブメールサーバ１５０が提供するウェブメールサービスを享受することができる。
【００２３】
中継サーバ１１０は、イントラネット１３０上の装置（ＤＢ１１１を除く）と、ウェブメールサーバ１５０と、の間のデータ通信を中継するためのものである。例えば、クライアント端末装置１００が中継サーバ１１０を介してウェブメールサーバ１５０が閲覧可能に提供するホームページにアクセスし、このホームページ上で情報の閲覧や登録、ウェブメールの作成や受信、送信などの操作指示を入力したとする。この場合、中継サーバ１１０は、このような操作指示をクライアント端末装置１００から受け、受けた操作指示をＨＴＴＰリクエスト（ソース情報）としてウェブメールサーバ１５０へ中継送信する処理を実行する。
【００２４】
また、中継サーバ１１０は、ウェブメールサーバ１５０を識別するためのウェブメールサービス情報や、ウェブメールのデータ通信を許可／拒否するといった送信制御に使用するルールであるウェブメール規制ルールが登録されているＤＢ１１１を備えている。
【００２５】
また、中継サーバ１１０は、ＤＢ１１１に登録されている情報の編集を、外部の装置に行わせるためのホームページを提供する、所謂ウェブサーバ機能も有している。なお、図１では、ＤＢ１１１は中継サーバ１１０に接続されているが、ＤＢ１１１の所在については特に限定するものではなく、中継サーバ１１０がアクセス可能なように構成されていればよい。
【００２６】
管理者用端末装置１２０は、中継サーバ１１０にアクセスし、上記ウェブサーバ機能を利用することで、中継サーバ１１０を制御することができる。また、管理者用端末装置１２０は、ウェブメールを送信したりするためにクライアント端末装置１００から中継サーバ１１０を介して送信されるＨＴＴＰリクエストを、管理者が閲覧できるように、設定および閲覧したりするために用いられるものである。
【００２７】
ウェブメールサーバ１５０は、一般のプロバイダに設けられているウェブサーバと同様の動作を行うものである。即ち、ウェブメールサーバ１５０は、中継サーバ１１０、広域ネットワーク網１４０を経由してアクセスしてきたクライアント端末装置１００に対して、要求に応じたウェブページを提供する。本実施形態では特に、ウェブメールサーバ１５０は、ＨＴＴＰプロトコルを利用した電子メールの送受信を行うウェブメールサービスを提供する。
【００２８】
広域ネットワーク網１４０は、インターネットに代表されるネットワークである。イントラネット１３０は、ＬＡＮなどのネットワークにより構成されるものである。
【００２９】
図２は、中継サーバ１１０のハードウェア構成例を示すブロック図である。
【００３０】
ＣＰＵ２０１は、ＲＡＭ２０２やＲＯＭ２０３に格納されているコンピュータプログラムやデータを用いて、中継サーバ１１０全体の制御を行うと共に、中継サーバ１１０が行うものとして後述する各処理を実行する。
【００３１】
ＲＡＭ２０２は、ＨＤＤ（ハードディスクドライブ）２０４や記憶媒体ドライブ２０６からロードされたコンピュータプログラムやデータ、Ｉ／Ｆ（インターフェース）２０５、２１０を介して外部から受信したデータ等を一時的に記憶する為のエリアを有する。更に、ＲＡＭ２０２は、ＣＰＵ２０１が各種の処理を実行する際に用いるワークエリアも有する。即ち、ＲＡＭ２０２は、各種のエリアを適宜提供することができる。
【００３２】
ＲＯＭ２０３には、中継サーバ１１０の設定データや、ブートプログラムなどが格納されている。
【００３３】
ＨＤＤ２０４には、ＯＳ（オペレーティングシステム）や、中継サーバ１１０が行うものとして後述する各処理をＣＰＵ２０１に実行させるためのコンピュータプログラム、中継サーバ１１０が保持するものとして後述する様々なデータ等が保存されている。なお、ＤＢ１１１をこのＨＤＤ２０４内に設けても良い。ＨＤＤ２０４内に保存されているコンピュータプログラムやデータは、ＣＰＵ２０１による制御に従って適宜ＲＡＭ２０２にロードされ、ＣＰＵ２０１による処理対象となる。
【００３４】
Ｉ／Ｆ２０５は、中継サーバ１１０をイントラネット１３０、広域ネットワーク網１４０に接続するためのインターフェースである。従って、中継サーバ１１０はこのＩ／Ｆ２０５を介して、イントラネット１３０、広域ネットワーク網１４０に接続されている各装置とのデータ通信を行うことができる。
【００３５】
記憶媒体ドライブ２０６は、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＡＭ等の記憶媒体に記録されているコンピュータプログラムやデータを読み出し、その読み出し結果をＲＡＭ２０２やＨＤＤ２０４に出力する。なお、ＲＡＭ２０２やＨＤＤ２０４が保持している情報のうち一部をこの記憶媒体に記録させておいてもよい。
【００３６】
キーボード２０７、ポインティングデバイス２０８は、中継サーバ１１０の操作者が操作することで、各種の指示をＣＰＵ２０１に対して入力する為のものである。ポインティングデバイス２０８は、マウスやジョイスティック等により構成されている。
【００３７】
表示部２０９は、ＣＲＴや液晶画面等により構成されており、ＣＰＵ２０１による処理結果を画像や文字等でもって表示することができる。
【００３８】
Ｉ／Ｆ２１０は、周辺機器を中継サーバ１１０に接続するためのインターフェースである。中継サーバ１１０は、このＩ／Ｆ２１０を介して、この周辺機器とのデータ送受信を行う。Ｉ／Ｆ２１０は、ＵＳＢやＩＥＥＥ１３９４等により構成されており、通常複数のＩ／Ｆを有する。周辺機器との接続形態は有線／無線を問わない。
【００３９】
バス２１１は上述の各部をつなぐものである。
【００４０】
なお、本実施形態では、中継サーバ１１０は、図２に示した構成を有するものとして説明するが、以下に説明する中継サーバ１１０の動作を実現するものであれば、図２に示した構成に限定するものではない。
【００４１】
また、本実施形態では、クライアント端末装置１００、管理者用端末装置１２０、ウェブメールサーバ１５０についても図２に示した構成を有するものとして説明する。即ち、クライアント端末装置１００、管理者用端末装置１２０、中継サーバ１１０、ウェブメールサーバ１５０の何れも図２に示した構成を有するものとして説明する。しかし、それぞれの装置の構成は図２に示した構成に限定するものではなく、それぞれの装置の動作として以下に説明する動作を実現するものであれば、如何なる構成であっても良い。
【００４２】
次に、ＤＢ１１１に保存されているデータ群について説明する。
【００４３】
ＤＢ１１１には、図３に示すテーブル情報３００、図４に示すテーブル情報４００、図５に示すテーブル情報５００、が保存されている。
【００４４】
先ず、図３に示したテーブル情報３００について説明する。図３は、テーブル情報３００の構成例を示す図である。テーブル情報３００は、図３に示す如く、サービスＩＤ３０１とサービス名３０２とがセットになって登録されているテーブル形式の情報である。
【００４５】
サービスＩＤ３０１は、ウェブメールサービスを一意に示す識別番号である。このサービスＩＤ３０１は、自動的に付与しても、ユーザの入力指示に基づいて設定しても構わないが、重複することは認めない。即ち、テーブル情報３００には、互いに異なるサービスＩＤ３０１が登録されている。
【００４６】
サービス名３０２は、ウェブメールサービスのサービス名を示すものである。サービス名３０２は、管理者用端末装置１２０からＤＢ１１１へアクセスしたときの表示等で使用されるものである。
【００４７】
次に、図４に示したテーブル情報４００について説明する。図４は、テーブル情報４００の構成例を示す図である。テーブル情報４００は、図４に示す如く、サービスＩＤ４０１、詳細設定ＩＤ４０２、種別４０３、ＵＲＬ４０４、送信データ情報４１２、がセットになって登録されているテーブル形式の情報である。
【００４８】
サービスＩＤ４０１は、ウェブメールサービスを一意に示す識別番号であり、テーブル情報３００中に登録されているサービスＩＤ３０１と同じものである。即ち、テーブル情報３００に登録されているセットと、テーブル情報４００に登録されているセットと、で、同じサービスＩＤを有するセットは、それぞれ関連付けられることになる。
【００４９】
詳細設定ＩＤ４０２は、ウェブメールサービスの詳細設定を一意に示す識別番号である。この詳細設定ＩＤ４０２は、自動的に付与しても、ユーザの入力指示に基づいて設定しても構わない。ただし、同一ウェブメールサービス内での重複は認めない。
【００５０】
種別４０３は、「本文」、「添付」、「本文＆添付」のうち何れか１つを示す項目であり、後述のＵＲＬ４０４に登録されているＵＲＬに対して行われる通信が、電子メールの本文のみ送信する通信、添付ファイルのみ送信する通信、本文と添付ファイルとを一緒に送信する通信の何れであるのかを示す。ウェブメールでは、ＳＭＴＰの電子メール送信とは異なり、クライアント端末装置１００から本文と添付ファイルとが同一のトランザクション（同一のリクエスト）で送信されないものもあるため、このような項目を設ける必要がある。
【００５１】
ＵＲＬ４０４は、ウェブメールサービスを提供するホームページ（このホームページを提供するサーバ）の所在を示すものである。
【００５２】
送信データ情報４１２は、ウェブメールを送信する為に設定すべき設定情報の属性名を示す情報（属性名情報）から成り、ＦＲＯＭ４０５、ＴＯ４０６、ＣＣ４０７、ＢＣＣ４０８、件名４０９、本文４１０、添付４１１、から構成されている。
【００５３】
ＦＲＯＭ４０５は、ＨＴＴＰリクエスト内に記されている設定情報「送信者（Ｆｒｏｍ）」の属性名としてＨＴＴＰリクエストに記されている属性名情報である。
【００５４】
ＴＯ４０６は、ＨＴＴＰリクエスト内に記されている設定情報「送信先アドレス（Ｔｏ）」の属性名としてＨＴＴＰリクエストに記されている属性名情報である。
【００５５】
ＣＣ４０７は、ＨＴＴＰリクエスト内に記されている設定情報「同報先アドレス（Ｃｃ）」の属性名としてＨＴＴＰリクエストに記されている属性名情報である。
【００５６】
ＢＣＣ（Ｂｌｉｎｄ  Ｃａｒｂｏｎ  Ｃｏｐｙ）４０８は、ＨＴＴＰリクエスト内に記されている設定情報「同報者（Ｂｃｃ）」の属性名としてＨＴＴＰリクエストに記されている属性名情報である。
【００５７】
件名４０９は、ＨＴＴＰリクエスト内に記されている設定情報「メールの件名」の属性名としてＨＴＴＰリクエストに記されている属性名情報である。
【００５８】
本文４１０は、ＨＴＴＰリクエスト内に記されている設定情報「本文」の属性名としてＨＴＴＰリクエストに記されている属性名情報である。
【００５９】
添付４１１は、ＨＴＴＰリクエスト内に記されている設定情報「添付ファイル」の属性名としてＨＴＴＰリクエストに記されている属性名情報である。
【００６０】
これらの属性名情報は、ウェブメールサービス毎に異なるので、ウェブメールサービス毎に取得しておく必要がある。なお、ウェブメールサービスによってはこれらの設定情報の一部を必要としないものもある。従って、必要としない設定情報については、その属性名情報は設定する必要はない。
【００６１】
次に、図５に示したテーブル情報５００について説明する。図５は、テーブル情報５００の構成例を示す図である。テーブル情報５００は、図５に示す如く、サービスＩＤ５０１とセッション識別子５０２とがセットになって登録されているテーブル形式の情報である。
【００６２】
サービスＩＤ５０１は、ウェブメールサービスを一意に示す識別番号であり、テーブル情報３００中に登録されているサービスＩＤ３０１と同じものである。即ち、テーブル情報３００に登録されているセットと、テーブル情報５００に登録されているセットと、で、同じサービスＩＤを有するセットは、それぞれ関連付けられることになる。
【００６３】
セッション識別子５０２は、ウェブメールサービスにおいて同一のメールメッセージを構成するデータに対する属性値を示す。即ち、複数のメールメッセージ（ＨＴＴＰリクエスト）がある場合に、セッション識別子は、それぞれのＨＴＴＰリクエストが１つのメールを構成するのか、別個のメールを構成するのかを示すことになる。
【００６４】
ここで上述の通り、各種のウェブメールサービスに対して送信制御を実施する場合には、図３〜５に示したテーブル情報をＤＢ１１１に予め設定しておく必要がある。例えば、送信先を制限したい場合には、ＴＯ４０６やＣＣ４０７及びＢＣＣ４０８を参照し、ＵＲＬ４０４が示す送信先への情報送信の前で送信制御を実施すれば良い。本実施形態では、図３〜５に示したテーブル情報を半自動的に作成すること（半自動抽出登録）、及び未知のウェブメールサービスに対して自動的に図３〜５に示したテーブル情報を作成すること（自動提示登録）にある。
【００６５】
次に、図３〜５に示したテーブル情報の半自動抽出登録、自動提示登録について、図６、７Ａ、７Ｂを参照して説明する。
【００６６】
図６は、半自動抽出登録の処理と、自動提示登録の処理と、を示す登録処理に関するフローチャートである。図７Ａは、中継サーバ１１０に通常モードが設定された場合におけるシステムの構成を示す図である。図７Ｂは、テーブル情報を作成するためのモード（検出モード）が中継サーバ１１０に設定された場合におけるシステムの構成を示す図である。
【００６７】
先ず、半自動抽出登録の処理について、図６、７Ａ、７Ｂ、８〜２４を用いて説明する。
【００６８】
中継サーバ１１０の動作モードは上述の通り、通常モードと検出モードとがある。中継サーバ１１０の動作モード変更は、後述する半自動抽出登録で自動的に実施されるが、管理者用端末装置１２０から任意に行うこともできる。例えば、管理者用端末装置１２０が中継サーバ１１０にアクセスすることで、中継サーバ１１０は、中継サーバ１１０の動作モードを設定するための画面情報を管理者用端末装置１２０に送信する。管理者用端末装置１２０側では、係る画面情報に基づく設定画面を表示し、管理者用端末装置１２０の操作者が係る設定画面上で動作モードを切り替える操作を行うと、係る操作内容を示す情報は、中継サーバ１１０に送信される。中継サーバ１１０は、この操作内容を示す情報を受信すると、自身の動作モードを、この受信した情報が示す動作モードに切り替える処理を行う。これにより、管理者用端末装置１２０により、中継サーバ１１０の動作モードを設定することができる。もちろん、中継サーバ１１０の動作モードを設定するための構成についてはこれに限定するものではない。
【００６９】
中継サーバ１１０に通常モードが設定された場合、システムは、図７Ａに示す構成となる。管理者用端末装置１２０側では、中継サーバ１１０の動作モードを表示したり、クライアント端末装置１００から中継サーバ１１０を介して広域ネットワーク網１４０に対して送信される情報を表示するための管理用ブラウザ７０１が表示される。係る表示は、管理者用端末装置１２０が有する表示部２０９が行う。
【００７０】
一方、クライアント端末装置１００側では、ウェブメールサーバ１５０が提供する「ウェブメールサービスを提供するためのホームページ」にアクセスして表示すると共に、ウェブメールに係る様々な操作を行うために、閲覧用ブラウザ７０２が表示される。係る表示は、クライアント端末装置１００が有する表示部２０９が行う。
【００７１】
そのほかの構成については図１に示したとおりである。
【００７２】
次に、中継サーバ１１０に検出モードが設定された場合、システムは、図７Ｂに示した構成となる。図７Ｂに示した構成を有するシステムの動作について詳しくは後述するが、係る構成により、管理者用端末装置１２０は、管理者用端末装置１２０から広域ネットワーク網１４０に対して送信される情報からＤＢ１１１に登録するための各種情報の検出を行う指示を、中継サーバ１１０に対して行うことができる。加えて、クライアント端末装置１００から中継サーバ１１０を介して広域ネットワーク網１４０へのアクセスが遮断されたりすることはない。
【００７３】
先ず、管理者用端末装置１２０側では、管理用ブラウザ７０１を起動し（ステップＳ６０１）、中継サーバ１１０との接続を開始する（ステップＳ６０２）。管理用ブラウザ７０１の起動及び中継サーバ１１０への接続、の一連の処理は、管理者用端末装置１２０の操作者のキーボード２０７やポインティングデバイス２０８を用いた操作指示を受け付けることでこの一連の処理の開始を指示しても良い。
【００７４】
次に、管理者用端末装置１２０の操作者は、キーボード２０７やポインティングデバイス２０８を用いて、この管理用ブラウザ７０１が有する管理用メニューから、サービス追加の項目を指示する。この指示を受けると、管理者用端末装置１２０は、図３に示したテーブル情報３００を中継サーバ１１０に要求するので、中継サーバ１１０はこのテーブル情報３００をＤＢ１１１から取得し、管理者用端末装置１２０に送信する。管理者用端末装置１２０は、中継サーバ１１０から受信したテーブル情報３００を用いて、図９に例示する画面９００（サービス追加画面）を表示部２０９に表示する（ステップＳ６０３）。
【００７５】
図９は、画面９００の表示例を示す図である。
【００７６】
サービス追加画面９００には、図３に示したテーブル情報３００の内容が一覧表示されており、表示欄９０１にはサービスＩＤ３０１が表示されており、表示欄９０２にはサービス名３０２が表示されている。
【００７７】
ここで、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてチェックボックス９０４をチェックし、削除ボタン９０５を指示したとする。この場合、管理者用端末装置１２０は、チェックしたチェックボックスに対応するウェブメールサービス（図９の場合にはサービス名が「ｆｒｅｅｍａｉｌ」のウェブメールサービス）をＤＢ１１１から削除する。具体的には、チェックしたチェックボックスに対応するウェブメールサービスのサービスＩＤに関連付けられている情報群を、テーブル情報３００、テーブル情報４００、テーブル情報５００から削除する。
【００７８】
また、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いて行９０６や行９０７を指示することで、図２０に例示する画面２０００が表示部２０９に表示される。図２０に例示する画面については後述する。
【００７９】
また、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてサービス追加ボタン９０３を指示すると、その指示に応じて管理者用端末装置１２０は、表示部２０９に、図１０に例示する画面１０００を表示する。
【００８０】
図１０は、新たにウェブメールサービスについての情報をテーブル情報３００、４００、５００に追加するために用いる画面の表示例を示す図である。
【００８１】
サービス追加ボタン９０３が指示されると、管理者用端末装置１２０は、ＤＢ１１１に登録済みのサービスＩＤと重複しない識別番号を発行する。そして管理者用端末装置１２０は、この発行した識別番号を、これから登録するウェブメールサービスのサービスＩＤとして表示領域１００１に表示する。なお、管理者用端末装置１２０の操作者は、キーボード２０７やポインティングデバイス２０８を用いて、この表示領域１００１に表示されているサービスＩＤを他のサービスＩＤに変更することもできる。しかし、上述の通り、ＤＢ１１１に登録済みの他のサービスＩＤと重複することは認められないので、この場合には、エラー表示を行うなど、重複したサービスＩＤの登録は拒否する。
【００８２】
なお、この表示領域１００１に記入されているサービスＩＤは、後にテーブル情報３００におけるサービスＩＤ３０１、テーブル情報４００におけるサービスＩＤ４０１、テーブル情報５００におけるサービスＩＤ５０１、として登録されることになる。
【００８３】
表示領域１００２は、画面１０００が表示された時点では空白領域となっており、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いて所望のサービス名を入力することができる。この表示領域１００２に記入されたサービス名は、後にテーブル情報３００におけるサービス名３０２として登録されることになる。
【００８４】
表示領域１００６には、管理者用端末装置１２０側で予め保持しておいた規定の（ウェブメールの）送信先（Ｔｏ、Ｃｃ、Ｂｃｃ）が表示されている。なお、この規定の送信先を以降の処理で使用する場合は、管理者用端末装置１２０の操作者はキーボード２０７やポインティングデバイス２０８を用いてチェックボックス１００３をチェックする必要がある。なお、このチェックボックス１００３をチェックしない場合、管理者用端末装置１２０の操作者は、キーボード２０７やポインティングデバイス２０８を用いて、この規定の送信先に代わる別の送信先（Ｔｏ、Ｃｃ、Ｂｃｃ）を入力する必要がある。
【００８５】
ここで、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてキャンセルボタン１００４を指示すると、管理者用端末装置１２０は、表示部２０９の表示を、図９に例示した画面９００に切り替える。
【００８６】
一方、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いて「次へ」のボタン１００５を指示すると、管理者用端末装置１２０は表示部２０９の表示を図１１に例示する画面１１００に切り替える（ステップＳ６０４）。
【００８７】
図１１は、新たにウェブメールサービスについての情報をテーブル情報３００、４００、５００に追加するために用いる画面の表示例を示す図である。
【００８８】
画面１１００において表示領域１１０１には、管理者用端末装置１２０のＩＰアドレスが表示される。
【００８９】
表示領域１１０２には、管理者用端末装置１２０側で予め保持しておいた規定の差出人アドレスが表示される。なお、管理者用端末装置１２０の操作者は、キーボード２０７やポインティングデバイス２０８を用いて、この表示領域１１０２内に表示されている差出人アドレスを任意に編集することができる。
【００９０】
表示領域１１０３、１１０４、１１０５には、図１０に例示した画面１０００における表示領域１００６内に表示された送信先（若しくは管理者用端末装置１２０の操作者が別途入力した送信先）が表示される。
【００９１】
表示領域１１０６には、中継サーバ１１０が生成したランダムな文字列が表示される。管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いて、画面１０００におけるボタン１００５を指示すると、管理者用端末装置１２０は中継サーバ１１０に対して、表示領域１１０６内に表示する為の文字列を要求する。中継サーバ１１０はこの要求を受けると、予め作成しておいたランダムな文字列（この時点で作成しても良い）を管理者用端末装置１２０に送信する。管理者用端末装置１２０はこの文字列を中継サーバ１１０から受信すると、この受信した文字列を表示領域１１０６内に表示する。
【００９２】
ここで、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いて、表示領域１１０６内に表示されているコピーリンク１１０７を指示したとする。この場合、管理者用端末装置１２０は、表示領域１１０６内に表示されているランダムな文字列を、稼動中のオペレーティングシステムのクリップボードにコピーする。コピーの目的などについては後述する。
【００９３】
表示領域１１０８には、中継サーバ１１０が生成したランダムな文字列が表示される。管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いて、画面１０００におけるボタン１００５を指示すると、管理者用端末装置１２０は中継サーバ１１０に対して、表示領域１１０８内に表示する為の文字列を要求する。中継サーバ１１０はこの要求を受けると、予め作成しておいたランダムな文字列（この時点で作成しても良い）を管理者用端末装置１２０に送信する。管理者用端末装置１２０はこの文字列を中継サーバ１１０から受信すると、この受信した文字列を表示領域１１０８内に表示する。
【００９４】
ここで、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いて、コピーリンク１１０９を指示したとする。この場合、管理者用端末装置１２０は、表示領域１１０８内に表示されているランダムな文字列を、稼動中のオペレーティングシステムのクリップボードにコピーする。コピーの目的などについては後述する。
【００９５】
ダウンロードボタン１１１０は、添付ファイルとして用いるサンプルファイルを中継サーバ１１０に要求するために指示するボタンである。管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてこのダウンロードボタン１１１０を指示すると、管理者用端末装置１２０は中継サーバ１１０に対して、添付ファイルとして用いるサンプルファイルを要求する。中継サーバ１１０はこの要求を受けると、予め作成しておいたサンプルファイル（この時点で作成しても良い）を管理者用端末装置１２０に送信する。管理者用端末装置１２０は、この送信されたサンプルファイルを受信すると、これをＲＡＭ２０２やＨＤＤ２０４等に一時的に格納する。
【００９６】
チェックボタン１１１１ａ、１１１１ｂは、表示領域１１１１内に設けられ、これから送信するウェブメールを、編集後直ちに送信するか、編集後に一端保存してから送信するのかを選択するためのものである。チェックボタン１１１１ａが指示された場合には前者の送信形態を採用し、チェックボタン１１１１ｂが指示された場合には後者の送信形態を採用する。
【００９７】
ウェブメールを送信する際のウェブメールサービスのアクションには、主に２種類のアクションが存在する。メールを編集後直ちに送信するものと、一度編集内容を下書き保存してから別のセッションで送信するものがある。このアクションに対応するために、チェックボタン１１１１ａ、１１１１ｂを設けた。
【００９８】
表示領域１１１２には、中継サーバ１１０からの指示が表示される。
【００９９】
ここで、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてキャンセルボタン１１１３を指示すると、管理者用端末装置１２０は、表示部２０９の表示を、図１０に例示した画面１０００に切り替える。完了ボタン１１１４を指示した場合における管理者用端末装置１２０の動作については後述する。
【０１００】
図６に戻って、ステップＳ６０４の処理の後、管理者用端末装置１２０の操作者は、キーボード２０７やポインティングデバイス２０８を用いて、閲覧用ブラウザ７１１の起動を指示する。これにより管理者用端末装置１２０は、この閲覧用ブラウザ７１１を起動する（ステップＳ６０６）。この閲覧用ブラウザ７１１は、中継サーバ１１０が有する後述の検出プロキシー７１２にアクセスするためのものである。
【０１０１】
そして、管理者用端末装置１２０は、閲覧用ブラウザ７１１で検出プロキシー７１２（中継サーバ１１０）を介してウェブメールサーバ１５０にアクセスし、ウェブメールサービスを提供するためのホームページにアクセスする（ステップＳ６０７）。この時点から検出プロキシー７１２は、閲覧用ブラウザ７１１からのアクセスを記録し始める。もちろん、この時点で、検出プロキシー７１２の起動は完了しているものとする。検出プロキシー７１２の起動のタイミングについては後述する。即ち、この時点で、管理者用端末装置１２０は、閲覧用ブラウザ７１１を介して、このホームページ上で送信先や件名などを入力することで、いつでもウェブメールサービスを利用することができる環境下にある。
【０１０２】
従って、管理者用端末装置１２０は、閲覧用ブラウザ７１１を介してウェブメールサービスを提供するためのホームページにアクセスしているので、このホームページ上で、送信元、送信先、件名等を入力し、ウェブメールを作成する（ステップＳ６０８）。
【０１０３】
ウェブメールの作成の際、送信元（差出人）については、図１１に例示する画面１１００における表示領域１１０２内に表示されているアドレスをコピーして用いればよい。
【０１０４】
また、送信先（Ｔｏ、Ｃｃ、Ｂｃｃ）についてはそれぞれ、図１１に例示する画面１１００における表示領域１１０３、１１０４、１１０５に表示されている送信先アドレスをコピーして用いればよい。
【０１０５】
また、件名については、上記コピーリンク１１０７を指示することでコピーされた、表示領域１１０６内に表示されている文字列を用いればよい。
【０１０６】
また、本文については、上記コピーリンク１１０９を指示することでコピーされた、表示領域１１０８内に表示されている文字列を用いればよい。
【０１０７】
また、添付ファイルをメールに添付する場合には、図１１に例示する画面１１００におけるダウンロードボタン１１１０を指示することでＲＡＭ２０２やＨＤＤ２０４にダウンロードしたファイルを添付するように、上記ホームページ上で操作指示すればよい。
【０１０８】
このように、管理者用端末装置１２０側では、閲覧用ブラウザ７１１上で、これから送信するウェブメールを、図１１に例示した画面１１００に表示された各設定項目を用いて作成する。
【０１０９】
そしてウェブメールの作成が完了すると、管理者用端末装置１２０の操作者はキーボード２０７やポインティングデバイス２０８を用いて送信指示を入力する。この送信指示を受けると、管理者用端末装置１２０は、このウェブメールの送信を行う為のＨＴＴＰリクエストを作成し、作成したＨＴＴＰリクエストをウェブメールサーバ１５０に対して送信する（ステップＳ６０９）。検出プロキシー７１２（中継サーバ１１０）は、管理者用端末装置１２０から送信されたＨＴＴＰリクエスト取得することになる。
【０１１０】
なお、ウェブメールの送信後は、閲覧用ブラウザ７１１は閉じても構わないし、そのままにしておいても良い。
【０１１１】
図６では、管理者用端末装置１２０の操作者はキーボード２０７やポインティングデバイス２０８を用いて閲覧用ブラウザ７１１を閉じる操作指示を入力したものとしている。従って、ステップＳ６１０では、管理者用端末装置１２０は、閲覧用ブラウザ７１１を閉じる処理を行う。
【０１１２】
図１２は、閲覧用ブラウザ７１１の起動（ステップＳ６０６）から終了（ステップＳ６１０）までの処理と並行して中継サーバ１１０及び検出プロキシー７１２で実施される半自動抽出登録の詳細フローチャートである。即ち、図１２に示したフローチャートに従った処理は、ステップＳ６０４における処理が開始されたことをトリガーにして開始するものである。
【０１１３】
先ず、管理者用端末装置１２０からの画面１１００の画面情報要求（ステップＳ６０４）とともに、管理者用端末装置１２０から中継サーバ１１０に対して検出モードへの移行指示が送信される。その移行指示に応じて、中継サーバ１１０は、自身の動作モードを検出モードに移行する為の処理を行う（ステップＳ１２０２）。中継サーバ１１０の検出モードへの移行処理が終了した際には、管理者用端末装置１２０の表示部２０９には画面１１００が表示されることになる。
【０１１４】
図１３は、ステップＳ１２０２における処理の詳細を示すフローチャートである。
【０１１５】
先ず、管理者用端末装置１２０からの移行指示に応じて、中継サーバ１１０は、検出プロキシー７１２を起動する（ステップＳ１３０１）。
【０１１６】
次に、中継サーバ１１０は、検出プロキシー７１２の起動が成功したか否かを判断する（ステップＳ１３０２）。係る判断の結果、成功したと判断した場合には、処理をステップＳ１３０３に進める。一方、失敗したと判断した場合には、検出モードへの移行が失敗したと判断し、図１３に示したフローチャートに従った処理を終了させる。
【０１１７】
中継サーバ１１０は、ＣＰＵ２０１内に設けられているタイマにより計時を開始する（タイマ起動）（ステップＳ１３０３）。このタイマは、検出プロキシー７１２を起動後、一定時間内に閲覧用ブラウザ７１１から何らリクエストがなかった場合、検出プロキシー７１２を自動的に終了させるためのものである。
【０１１８】
次に、中継サーバ１１０は、タイマの起動が成功したか否かを判断する（ステップＳ１３０４）。係る判断の結果、成功したと判断した場合には、検出モードへの移行が成功したと判断し、本処理を終了する。一方、失敗したと判断した場合には、検出モードへの移行が失敗したと判断し、本処理を終了する。
【０１１９】
なお、検出モードへの移行が成功したか失敗したかの判断結果は、中継サーバ１１０から管理者用端末装置１２０に通知される。
【０１２０】
図１２に戻って、次に、図１３のフローチャートに従った処理の結果、検出モードへの移行が成功したと判断された場合には、ステップＳ１２０３を介してステップＳ１２０４に処理を進める。一方、検出モードへの移行が失敗したと判断された場合には、ステップＳ１２０３を介してステップＳ１２２１に処理を進める。
【０１２１】
ステップＳ１２２１では、管理者用端末装置１２０は、図１１に例示した画面１１００における表示領域１１１２に、検出モードへの移行が失敗した旨のメッセージを表示し、その後、半自動抽出登録を終了させる。
【０１２２】
一方、ステップＳ１２０４では、管理者用端末装置１２０は、図１１に例示した画面１１００における完了ボタン１１１４が指示されたか否かを判断する。この完了ボタン１１１４は、ウェブメールの送信後に指示するものである。即ち、ステップＳ１２０４は図６のステップＳ６０５と同等である。係る判断の結果、指示されていない場合には処理をステップＳ１２０５に進める。なお、完了ボタン１１１４が指示された場合には、管理者用端末装置１２０はその旨を中継サーバ１１０に通知する。
【０１２３】
ステップＳ１２０５では、中継サーバ１１０は、上記ステップＳ６０９において管理者用端末装置１２０上の閲覧用ブラウザ７１１から送信されたＨＴＴＰリクエストを検出プロキシー７１２で検出及び記録した後、ウェブメールサーバ１５０に転送するための処理を行う。
【０１２４】
図１４は、検出プロキシー７１２におけるステップＳ１２０５の処理の詳細を示すフローチャートである。
【０１２５】
先ず、検出プロキシー７１２は、上記ステップＳ１３０３において起動したタイマによる計時時間が、予め設定された有効時間内であるか否かを判断する（ステップＳ１４０１）。係る判断の結果、有効時間外である場合には、ステップＳ１２０５における処理を終了させる。
【０１２６】
一方、有効時間内である場合には、処理をステップＳ１４０２に進める。
【０１２７】
次に、検出プロキシー７１２は、受信したＨＴＴＰリクエストが、予め許可されたＩＰアドレス（特定ＩＰアドレス）からのリクエストであるか否かを判断する（ステップＳ１４０２）。本実施形態では、この特定アドレスとして、管理者用端末装置１２０のＩＰアドレスを用いる。従って、管理者用端末装置１２０からのＨＴＴＰリクエストを受信した場合、検出プロキシー７１２は、このＨＴＴＰリクエストは、予め許可されたＩＰアドレスからのリクエストであると判断する。
【０１２８】
ステップＳ１４０２における判断の結果、特定アドレスからのリクエストであると判断した場合には、処理をステップＳ１４０３に進め、特定アドレスからのリクエストではないと判断した場合には、処理をステップＳ１４０５に進める。
【０１２９】
ステップＳ１４０５では、検出プロキシー７１２は、受信したＨＴＴＰリクエストを破棄する（このＨＴＴＰリクエストの送信元のＩＰアドレスからの接続を拒否する）。
【０１３０】
一方、ステップＳ１４０３では、検出プロキシー７１２は、上記ステップＳ６０９において管理者用端末装置１２０から閲覧用ブラウザ７１１を介して送信されたＨＴＴＰリクエストを、検出データとしてＲＡＭ２０２やＨＤＤ２０４に記録する。このとき、管理者は、閲覧用ブラウザ７１１上からウェブメールサーバ１５０へ実際にアクセスを実施することになる。ＨＴＴＰリクエストは、例えば、図２３、図２４に示す構成を有するデータである。ＨＴＴＰリクエストについて詳しくは後述する。
【０１３１】
次に、ステップＳ１４０４では、検出プロキシー７１２は、上記ステップＳ６０９において管理者用端末装置１２０から送信されたＨＴＴＰリクエストを、広域ネットワーク網１４０を介してウェブメールサーバ１５０に送信する処理を行う。
【０１３２】
図１２に戻って、一方、完了ボタン１１１４が指示されている場合には処理はステップＳ１２０４からステップＳ１２０６に進める（図６のステップＳ６０５ではループを抜ける）。
【０１３３】
ここで、上記ステップＳ１２０５で検出データを取得していた場合には、ステップＳ１２０６を介してステップＳ１２０７に処理を進め、取得していない場合には、ステップＳ１２０６を介してステップＳ１２１５に処理を進める。
【０１３４】
ステップＳ１２１５では、中継サーバ１１０は、管理者用端末装置１２０に対して、ＨＴＴＰリクエストを受けていない旨を通知するので、管理者用端末装置１２０は、画面１１００における表示領域１１１２に、その旨のメッセージを表示する。例えば、Ｍ１２１６に示すような表示を、表示領域１１１２に表示する。
【０１３５】
次に、管理者用端末装置１２０は、管理者用端末装置１２０の操作者が、ＨＴＴＰリクエストを再送信する旨の操作指示を、キーボード２０７やポインティングデバイス２０８を用いて入力しているか否かを判断する（ステップＳ１２１７）。例えば、表示Ｍ１２１６中の「はい」のボタンを指示した場合には、再送信指示が入力されたものと判断する。一方、「いいえ」のボタンを指示した場合には、再送信指示が入力されなかったものと判断する。
【０１３６】
このような判断処理の結果、再送信指示が入力されたものと判断した場合には、処理をステップＳ１２０４に戻し、検出プロキシー７１２は閲覧用ブラウザ７１１からのＨＴＴＰリクエストの再送信を待つ。一方、再送信指示が入力されなかったものと判断した場合には、処理をステップＳ１２１８に進める。
【０１３７】
ステップＳ１２１８では、管理者用端末装置１２０は、再送信指示が入力されなかったことを中継サーバ１１０に通知するので、中継サーバ１１０は、検出プロキシー７１２を終了し、自身動作モードを通常モードに移行する。
【０１３８】
次に、ステップＳ１２１９では、管理者用端末装置１２０は、画面１１００における表示領域１１１２に、１２２０Ｍに示す表示を行う。
【０１３９】
一方、ステップＳ１２０７では、中継サーバ１１０は、自身の動作モードを通常モードに移行する。
【０１４０】
次に、ステップＳ１２０８では、中継サーバ１１０は、上記ステップＳ１４０３において検出データとしてＲＡＭ２０２やＨＤＤ２０４に格納したＨＴＴＰリクエストを解析する。そして、ＨＴＴＰリクエスト内に記されているそれぞれの設定情報の属性名を検出（抽出、取得）する。
【０１４１】
図１５は、ステップＳ１２０８における処理の詳細を示すフローチャートである。
【０１４２】
図１５に示したフローチャートでは、それぞれの設定情報について、ステップＳ１５０２〜Ｓ１５０４の処理を行う。
【０１４３】
先ず、ステップＳ１５０２では、中継サーバ１１０は、ＨＴＴＰリクエスト中のＨＴＴＰヘッダ情報やボディ情報から、送信先ＵＲＬ、Ｃｏｏｋｉｅ、マルチパートに分割された本文や添付ファイル等の情報をすべて分解・分析する（ＨＴＴＰリクエスト分析）。
【０１４４】
係る処理について、図２３、２４を用いて説明する。
【０１４５】
図２３は、ＨＴＴＰリクエストの構成例を示す図である。図２３に示す如く、ＨＴＴＰリクエストは、ＨＴＴＰヘッダ部２３０１と、ＨＴＴＰボディ部２３０２と、から構成されている。
【０１４６】
ＨＴＴＰヘッダ部２３０１は、１行目を除いて行毎に、属性名：属性値という書式で構成されており、例えば、属性名Ｃｏｏｋｉｅの属性値は２３０３に示す如く「７９８２３４７９２８３４９５２９３２３４２３４２３４２５１２４」である。１行目のみ、ＨＴＴＰメソッド、ＨＴＴＰパス、ＨＴＴＰプロトコルバージョンとＨＴＴＰ規約に定義されている。
【０１４７】
また、ＨＴＴＰボディ部２３０２は、テキスト文字列から構成されており、ＨＴＴＰの規約では、複数の構成要素を持つ場合、「＆」を区切り文字として構成できることが規定されている。従って、ＨＴＴＰボディ部２３０２の第２の構成要素は、「Ｓｕｂｊ＝ＷＤＷＬＤＡｗＩＦｆｆｆ２ｑＡｄｉＩＦ％２ＢＱＷＷＲＦＨＥｒ２ｑｒｑｉ３ｏＡ」であることがわかる。さらに各構成要素は「＝」を区切り文字として、属性名＝属性値という書式で構成されている。例えば、第２の構成要素は、属性名２３０４（Ｓｕｂｊ）、属性値２３０５（ＷＤＷＬＤＡｗＩＦｆｆｆ２ｑＡｄｉＩＦ％２ＢＱＷＷＲＦＨＥｒ２ｑｒｑｉ３ｏＡ）からなる。
【０１４８】
なお、ＨＴＴＰヘッダ部２３０１では、「Ｃｏｎｔｅｎｔ−ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ」と定義されている。そのため、属性値２３０５内の「％２Ｂ」は、ＨＴＴＰの規定により、「＋」と同値であるとされる。
【０１４９】
このようにＨＴＴＰヘッダ部２３０１、及びＨＴＴＰボディ部２３０２を構成要素単位で分解して、それぞれの構成要素を属性名と属性値の対として見なし、それぞれの属性値のうち、画面１１００において提示した設定情報の値と合致する属性値を特定する。そして特定した属性値と対になっている属性名を、属性名情報として取得する。
【０１５０】
なお、リクエスト先ＵＲＬについては、ＨＴＴＰヘッダ部２３０１の先頭の２行から生成することとなる。この場合、２行目にある属性名「Ｈｏｓｔ」の属性値が「ｗｗｗ．ｘｍａｉｌ．ｊｐ」であり、１行目のＨＴＴＰパスが「／ｗｅｂｍａｉｌ／ｓｅｎｄ」である。従って、リクエスト先ＵＲＬは「ｈｔｔｐ：／／ｗｗｗ．ｘｍａｉｌ．ｊｐ／ｗｅｂｍａｉｌ／ｓｅｎｄ」となる。
【０１５１】
次に、ウェブメールに添付ファイルを添付した場合のＨＴＴＰリクエスト分析について、図２４を用いて説明する。図２４は、ウェブメールに添付ファイルを添付した場合のＨＴＴＰリクエストの構成例を示す図である。
【０１５２】
図２４に示すＨＴＴＰリクエストも、図２３に示したＨＴＴＰリクエストと同じように、ＨＴＴＰヘッダ部２４０１とＨＴＴＰボディ部２４０２とから構成されており、ＨＴＴＰヘッダ部２４０１の分析方法については、前述した分析方法と同じである。
【０１５３】
一方、ＨＴＴＰボディ部２４０２を走査すると、ＨＴＴＰ規約で定められた書式で、領域２４０５に添付ファイルの実態があることがわかる。ここで、属性値２４０７が「ｍｕｌｔｉｐａｒｔ／ｆｏｒｍ−ｄａｔａ」形式であるため、領域がマルチパートと呼ばれる領域に含まれていることがわかる。マルチパート領域では、境界文字列（ｂｏｕｎｄａｒｙ）で区切られた領域毎に、マルチパートヘッダ部２４０８とマルチパートボディ部２４０９を持ち、添付ファイルはマルチパートボディ部２４０９内にある。従って、その対になるマルチパートヘッダ部２４０８を検査する。
【０１５４】
マルチパートヘッダ部２４０８には、ＨＴＴＰ規約で定められた書式で属性名２４０３、及びファイル名２４０４が記述されており、ＨＴＴＰリクエスト分析では、属性名２４０３を添付ファイルの属性名として取得する。
【０１５５】
このように、本実施形態に係るＨＴＴＰリクエスト分析では、図１１に例示した画面１１００において提示された設定情報の値（属性値）と対になってＨＴＴＰリクエスト中に記されている属性名を、属性名情報として取得する。もちろん、上述の通り、設定情報は送信先や件名など複数個あるので、それぞれの設定情報について属性名情報を取得することになる。
【０１５６】
従ってステップＳ１５０２では、ＨＴＴＰリクエストを上述のように属性名と属性値の対ごとに分解し、ＲＡＭ２０２やＨＤＤ２０４に保存する。
【０１５７】
次に、ステップＳ１５０３では、ステップＳ１５０２で取得した複数の属性値の中に、画面１１００で表示しているもの（すなわち、検出対象のウェブメールに設定されるはずの送信先条件や件名、本文等の属性値情報として設定した情報）があるか否かを判断する。係る判断の結果、表示しているものを検出した場合には処理をステップＳ１５０４に進める。一方、検出できなかった場合には、次のＨＴＴＰリクエストを分析すべく、処理をステップＳ１５０２に戻し、以降の処理を行う。
【０１５８】
ステップＳ１５０４では、検出した属性値情報と対に記録されているステップＳ１５０２で取得した属性名情報を、ＲＡＭ２０２やＨＤＤ２０４に保存する。例えば、図２３に示したＨＴＴＰリクエストを例に取ると、属性値２３０５は、画面１１００において表示領域１１０６に件名として表示された設定情報の値（属性値）と一致する(ステップＳ１５０３)。従って、この属性値２３０５と対になってＨＴＴＰリクエストに記されている属性名２３０４（Ｓｕｂｊ）が件名を意味しているものであるとわかるので、この属性名２３０４を、この設定情報に対応する属性名情報として取得する（ステップＳ１５０４）。即ち、詳細は後述するが、送信データ情報４１２において、件名４０９に記録されるべき値が属性名２３０４（Ｓｕｂｊ）となる。
【０１５９】
以上が、図１２のステップＳ１２０８で行うＨＴＴＰリクエスト分析処理の詳細である。
【０１６０】
図１２に戻って、次に、ステップＳ１２０９では、中継サーバ１１０は、ステップＳ１２０８において、検出データから属性名情報を抽出することができたか否かを判断する。係る判断の結果、抽出できている場合には処理をステップＳ１２１０に進め、抽出できていない場合には処理をステップＳ１２１９に進める。
【０１６１】
ステップＳ１２１９では、中継サーバ１１０は、１２２０Ｍに示す表示のデータを管理者用端末装置１２０に送信するので、管理者用端末装置１２０は、Ｍ１２２０に示す表示を、図１１に例示した画面１１００における表示領域１１１２に表示する。
【０１６２】
一方、ステップＳ１２１０では、中継サーバ１１０は、セッション情報の特定を行う。ＨＴＴＰを利用したウェブメールサービスでは、利用者のログイン状態等をサービス側で管理するために、セッション管理機能が必須となっており、各ＨＴＴＰリクエストにはセッション情報が組み込まれている。図１６は、ステップＳ１２１０における処理の詳細を示すフローチャートである。
【０１６３】
先ず、ステップＳ１６０１では、上記ＨＴＴＰリクエスト分析処理により解析されたＨＴＴＰリクエスト中にＣｏｏｋｉｅがあるか否かを判断する。係る判断の結果、Ｃｏｏｋｉｅがあると判断された場合には処理をステップＳ１６０２に進める。一方、Ｃｏｏｋｉｅがないと判断された場合には、処理をステップＳ１６０４に進める。
【０１６４】
ステップＳ１６０２では、分析した全てのＨＴＴＰリクエストが、Ｃｏｏｋｉｅについて同じ属性値を有しているか否かを判断する。係る判断の結果、有していると判断した場合には処理をステップＳ１６０３に進める。一方、有していないと判断した場合には、セッションの特定を失敗したと判断し、図１６のフローチャートに従った処理を終了する。
【０１６５】
一方、ステップＳ１６０３では、Ｃｏｏｋｉｅをセッション識別子と判断する。そして、セッションの特定は成功したと判断し、図１６のフローチャートに従った処理を終了する。係る処理ついて、図２３に示した構成を有するＨＴＴＰリクエストと図２４に示した構成を有するＨＴＴＰリクエストとを例に取って説明する。図２３に示したＨＴＴＰリクエストに記述されているＣｏｏｋｉｅの属性値２３０３と、図２４に示したＨＴＴＰリクエストに記述されているＣｏｏｋｉｅの属性値２４０６と、は同じ値である。即ち、それぞれのＨＴＴＰリクエストはＣｏｏｋｉｅの属性値として同じ値を有しているので、それぞれのＨＴＴＰリクエストは、Ｃｏｏｋｉｅをセッション識別子として同一セッションであるということがわかる。
【０１６６】
一方、ステップＳ１６０４では、Ｃｏｏｋｉｅが定義されていないと判断し、Ｃｏｏｋｉｅ以外のＨＴＴＰリクエストから共通の属性値を探索する。解析したそれぞれのＨＴＴＰリクエストから、属性名情報を取得することができた「属性名と属性値との対」のうち、送信データ情報４１２の候補となる以外の対を処理対象とする。
【０１６７】
そしてステップＳ１６０５では、ステップＳ１６０４において処理対象とした対の中で、共通の「属性名＝属性値の対」を有しているかを判断する。係る判断の結果、有していると判断した場合には、処理をステップＳ１６０６に進める。一方、有していないと判断した場合には、セッションの特定は失敗したものと判断し、図１６のフローチャートに従った処理を終了する。
【０１６８】
ステップＳ１６０６では、ステップＳ１６０５で取得できた全てのＨＴＴＰリクエストが共通に有している「属性名＝属性値」の対を構成する属性名を、セッション識別子として判断する。
【０１６９】
なお、図１６のフローチャートに従った処理によって取得したセッション識別子は、図５に示したセッション識別子５０２として、テーブル情報５００に登録される。
【０１７０】
図１２に戻って、次に、ステップＳ１２１１では、中継サーバ１１０は、上記ステップＳ１２０８で分析し、取得した属性名情報の集合が、既にＤＢ１１１に登録されているか否かを判断する。係る判断の結果、登録されていると判断した場合には、処理をステップＳ１２１３に進める。一方、登録されていないと判断した場合には、処理をステップＳ１２１２に進める。ステップＳ１２１１における判断結果は、中継サーバ１１０から管理者用端末装置１２０に通知される。
【０１７１】
ステップＳ１２１３では、管理者用端末装置１２０は、Ｍ１２１４に示すような表示を、図１１に例示した画面１１００における表示領域１１１２に表示する。
【０１７２】
一方、ステップＳ１２１２では、管理者用端末装置１２０は、表示部２０９の表示を、図１７に例示する画面１７００に切り替える。図１７は、ＨＴＴＰリクエスト分析結果を一覧表示する画面１７００の表示例を示す図である。
【０１７３】
画面１７００において、表示領域１７０１には、管理者用端末装置１２０のＩＰアドレスが表示されている。
【０１７４】
表示領域１７０２には、表示領域１７０３に表示したＵＲＬへのアクセス時刻が表示されている。
【０１７５】
表示領域１７０３には、ＨＴＴＰリクエストの送信先のＵＲＬが表示されている。本実施形態の場合、このＵＲＬは、ウェブメールサーバ１５０が提供するウェブメールサービスの為のホームページのアドレスとなる。
【０１７６】
表示領域１７０４には、「本文」、「添付」、「本文＆添付」、のいずれかが表示される。上記のＨＴＴＰリクエスト分析処理により、本文は検出したものの添付ファイルは検出されなかった場合には「本文」、添付ファイルは検出したものの本文は検出されなかった場合には「添付」、その両方を検出した場合には「本文＆添付」、と表示される。
【０１７７】
表示領域１７０５には、表示領域１１１１において、チェックボタン１１１１ａ、１１１１ｂの何れが指示されたのかが表示される。チェックボタン１１１１ａが指示された場合には「メール送信」が表示され、チェックボタン１１１１ｂが指示された場合には「下書き保存」が表示される。
【０１７８】
表示領域１７０６には、送信元についての属性名が検出されたか否かを示すシンボルが表示される。図１７の場合「○」が表示されているので、送信元についてはその属性名が検出されたことを示している。送信元についてその属性名が検出されなかった場合には「×」が表示される。
【０１７９】
なお、これは以降についても同様であるが、属性名が検出されたか否かを示したシンボルの表示形態については特に限定するものではない。
【０１８０】
表示領域１７０７には、上記のＨＴＴＰリクエスト分析処理により、取得した属性値が表示されている。属性名が正しく検出できていれば、画面１１００における表示領域１１０２に表示されている差出人アドレスと一致する。
【０１８１】
表示領域１７０８、１７０９、１７１０にはそれぞれ、上記のＨＴＴＰリクエスト分析処理により、取得した属性値が表示されている。属性名が正しく検出できていれば、画面１１００における表示領域１１０３、１１０４、１１０５に表示されていたメールアドレスと一致する。
【０１８２】
表示領域１７１１には、上記のＨＴＴＰリクエスト分析処理により、取得した属性値が表示されている。属性名が正しく検出できていれば、画面１１００における表示領域１１０６に表示されている文字列と一致する。
【０１８３】
表示領域１７１２には、上記のＨＴＴＰリクエスト分析処理により、取得した属性値が表示されている。属性名が正しく検出できていれば、画面１１００における表示領域１１０８に表示されている文字列と一致する。
【０１８４】
表示領域１７１３には、画面１１００におけるダウンロードボタン１１１０を指示したことでダウンロードしたファイルの内容と、ＨＴＴＰリクエスト分析処理により得られた添付ファイルの内容とが一致すれば、「○」が表示される。一方、一致していない場合や、そもそも添付ファイルが送信されなかった場合には、「×」が表示される。
【０１８５】
表示領域１７１４には、上記ステップＳ１２１０で取得したセッション識別子が表示される。例えば、セッション識別子がＣｏｏｋｉｅの場合は、「Ｃｏｏｋｉｅ」と表示される。また、セッション識別子が属性名と判断した場合は、その属性名が表示される。
【０１８６】
なお、画面１７００のような画面は、１回のアクセスでメール送信がなされた場合におけるものであって、複数回のアクセスによってメール送信がなされる場合には、それぞれのアクセスでのＨＴＴＰリクエストについての画面が表示されることになる。例えば、添付ファイルのみのＨＴＴＰリクエストが検出された場合は、図１７に示した画面の代わりに、図１８に示した画面１８００が表示されることになる。
【０１８７】
図１８は、添付ファイルのみ送信した場合のＨＴＴＰリクエスト分析結果を一覧表示した画面１８００の表示例を示す図である。このとき、添付ファイルについての表示領域１８０１、セッション識別子についての表示領域１８０２には「○」が表示されており、その他の項目についてはこのＨＴＴＰリクエストからは検出されていないので、「×」が表示されている。
【０１８８】
図１７に戻って、次に、画面１７００に表示した各属性名情報をＤＢ１１１に登録する場合、管理者用端末装置１２０の操作者は、キーボード２０７やポインティングデバイス２０８を用いてボタン１７１６を指示する。一方、登録しない場合には、ボタン１７１５を指示する。
【０１８９】
管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてボタン１７１６を指示すると、その指示に応じて、管理者用端末装置１２０は、表示部２０９の表示を、図１９に示す画面１９００に切り替える。
【０１９０】
図１９は、登録情報を確認するための画面１９００の表示例を示す図である。
【０１９１】
画面１９００において表示領域１９０１には、上記画面１０００における表示領域１００２に表示したサービス名が表示されている。
【０１９２】
表示領域１９０２には、上記画面１７００における表示領域１７０４に表示されている種別が表示されている。
【０１９３】
表示領域１９０３には、他の設定ＩＤと重ならないように管理者用端末装置１２０が発行した詳細設定ＩＤが表示されている。
【０１９４】
表示領域１９０４には、上記画面１７００における表示領域１７０３に表示されていたＵＲＬが表示されている。
【０１９５】
表示領域１９０５には、上記画面１７００における表示領域１７０７に表示されている「差出人」の属性値と対となる属性名情報が表示されている。
【０１９６】
表示領域１９０６には、上記画面１７００における表示領域１７０８に表示されている「Ｔｏ」の属性値と対となる属性名情報が表示されている。
【０１９７】
表示領域１９０７には、上記画面１７００における表示領域１７０９に表示されている「Ｃｃ」の属性値と対となる属性名情報が表示されている。
【０１９８】
表示領域１９０８には、上記画面１７００における表示領域１７１０に表示されている「Ｂｃｃ」の属性値と対となる属性名情報が表示されている。
【０１９９】
表示領域１９０９には、上記画面１７００における表示領域１７１１に表示されている「件名」の属性値と対となる属性名情報が表示されている。
【０２００】
表示領域１９１０には、上記画面１７００における表示領域１７１２に表示されている「本文」の属性値と対となる属性名情報が表示されている。
【０２０１】
表示領域１９１１には、設定情報「添付ファイル」について上記ＨＴＴＰリクエスト分析処理によって取得した属性名情報が表示されている。なお、ウェブメールに添付ファイルを添付しなかった場合には当然ながら表示領域１９１１には何も表示されない。即ち、表示領域１９０２に「本文＆添付」あるいは「添付ファイル」が表示されている場合にのみ、添付ファイルの属性名情報が表示領域１９１１に表示される。
【０２０２】
この画面１９００は、上記画面１７００に対応した画面であるので、図１９では表示領域１９１１は空欄となっている。従って、画面１８００の場合、表示領域１９１１には「ｆｉｌｅｎａｍｅ」と表示され、表示領域１９０５〜１９１０は空欄となる。そして、表示領域１９０３には重複しない詳細設定ＩＤ（例えば、３２）が表示され、表示領域１９０４には、画面１８００で表示されたＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｘｍａｉｌ．ｊｐ／ｗｅｂｍａｉｌ／ａｔｔａｃｈ」が表示され、表示領域１９０２には「添付ファイル」と表示される。
【０２０３】
画面１９００が表示されている状態で、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてキャンセルボタン１９１２を指示すると、管理者用端末装置１２０は画面１９００を閉じ、画面１７００あるいは画面１８００に戻る。
【０２０４】
一方、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてボタン１９１３を指示すると、中継サーバ１１０に登録指示を送信する。中継サーバ１１０は、この登録指示を管理者用端末装置１２０から受信すると、ＨＴＴＰリクエスト分析処理によって取得したそれぞれの属性名情報を、テーブル情報３００、４００、５００において該当する箇所に登録する。
【０２０５】
図８は、本実施形態に係るシステムを構成する装置間の半自動抽出登録の動作を示す図である。図８において、図６、１２、１３で説明した処理と同じ処理については同じ参照番号を付けており、その説明は省略する。
【０２０６】
ここで、上述の通り、図９において管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いて、画面９００における行９０６や行９０７を指示することで、図２０に例示する画面２０００が表示部２０９に表示される。
【０２０７】
図２０は、ウェブメールサービス毎の情報を一覧表示した画面２０００の表示例を示す図である。以下では一例として、行９０６が指示された場合について説明する。
【０２０８】
画面２０００では、ウェブメールサービス名「ｆｒｅｅｍａｉｌ」についてＤＢ１１１に登録した送信データ情報の概要が表示されている。図２０では、本文を検出するための送信データ情報と、添付ファイルを検出するための送信データ情報とが登録されていることが表示されている。
【０２０９】
詳細設定ＩＤ２００１は、図４における詳細設定ＩＤ４０２と同一となる。即ち、重複する詳細設定ＩＤは認められない。
【０２１０】
ＵＲＬ２００２は、その設定（このＵＲＬについてＨＴＴＰリクエスト分析した結果としての属性名情報を用いた送信制御）が作用するＵＲＬを示しており、例えば、図４におけるＵＲＬ４０４と同一となる。
【０２１１】
種別２００３は、その設定で取得できるデータの種類を示しており、例えば、図４における種別４０３と同一となる。
【０２１２】
また、チェックボックス２００４をチェックし、「削除」ボタン２００５を指示することで、対応する設定をＤＢ１１１から削除することもできる。
【０２１３】
ここで、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてサービス名が表示されている行２００７や、行２００８を指示すると、管理者用端末装置１２０は、表示部２０９の表示を画面１９００に切り替える。なお、この画面遷移で画面１９００を表示したとき、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてキャンセルボタン１９１２を指示すると、管理者用端末装置１２０は画面１９００を閉じ、画面２０００に戻る。
【０２１４】
また、管理者用端末装置１２０の操作者が、キーボード２０７やポインティングデバイス２０８を用いてボタン２００６を指示すると、管理者用端末装置１２０は、表示部２０９の表示を画面１９００（但し各表示領域は空白）に切り替える。管理者用端末装置１２０の操作者は、この画面１９００を用いて新たな属性名情報を設定することができる。なお、この画面遷移で画面１９００を表示したとき、管理者用端末装置１２０の操作者がキーボード２０７やポインティングデバイス２０８を用いてキャンセルボタン１９１２を指示すると、管理者用端末装置１２０は画面１９００を閉じ、画面２０００に戻る。
【０２１５】
図２１は、上述した様々な画面の遷移図を示す図である。なお、図２１において、画面２０００から画面９００へ遷移する際の「戻る」ボタンとは、管理用ブラウザ７０１に設けられているものである。
【０２１６】
次に、自動提示登録処理、即ち、図６のステップＳ６１２、Ｓ６１３における処理について説明する。自動提示登録処理は、半自動抽出登録処理を行っていない時間帯に、定期的、若しくは不定的に実行されるものである。
【０２１７】
半自動抽出登録処理を行っていない間、クライアント端末装置１００や管理者用端末装置１２０はウェブメールを送信することができるので、当然ながらそれぞれの端末装置から中継サーバ１１０へは、この送信に係るＨＴＴＰリクエストが送信されている。しかし、クライアント端末装置１００や管理者用端末装置１２０からは、掲示板への書き込みを行う等、ウェブメールの送信以外の目的で中継サーバ１１０に対してＨＴＴＰリクエストを送信することもある。
【０２１８】
従って中継サーバ１１０は、ＨＴＴＰリクエストがどのような操作を示したものであるのかに関係なく、管理者用端末装置１２０やクライアント端末装置１００から送信されたＨＴＴＰリクエストはログとしてＨＤＤ２０４に記録する。従ってステップＳ６１２では、中継サーバ１１０は、ＨＤＤ２０４に記録されているＨＴＴＰリクエストのログを分析する処理を行う。もちろん、中継サーバ１１０が記録するＨＴＴＰリクエストのログの記録先は、ＨＤＤ２０４に限られるものではない。
【０２１９】
図２２は、ステップＳ６１２における処理の詳細を示すフローチャートである。
【０２２０】
先ず、ステップＳ２２０１では、上記ステップＳ１５０２におけるＨＴＴＰリクエスト分析処理と同様の処理を、ＨＤＤ２０４等にログとして記録されているＨＴＴＰリクエストについて行う。
【０２２１】
次に、ステップＳ２２０２では、ステップＳ２２０１で行われたＨＴＴＰリクエスト分析処理の結果を参照して、送信先ＵＲＬを取り出し、この送信先ＵＲＬが既にＤＢ１１１に登録されているか否かを判断する。係る判断の結果、登録されている場合には、「検出なし」と判断し、図２２に示したフローチャートに従った処理を終了する。
【０２２２】
一方、登録されていないと判断した場合には、処理をステップＳ２２０３に進める。
【０２２３】
ステップＳ２２０３では、ステップＳ２２０１で行われたＨＴＴＰリクエスト分析処理の結果を参照して、セッション識別子を特定する。本ステップにおけるセッション識別子の特定処理は、図１６に示したフローチャートに従った処理となる。上述の半自動抽出登録処理では、検出プロキシー７１２を利用することで、閲覧用ブラウザ７１１からのリクエストを限定して中継するため、明確に単一のセッション識別子を特定することができる（送信元である閲覧用ブラウザ７１１も送信先であるウェブメールサーバ１５０も限定されている）。しかし、自動提示登録処理では、複数のクライアント端末装置１００から様々なウェブサーバへの接続が記録されているログが解析対象となるため、検出されるセッション識別子も単一ではなく複数存在する可能性がある。従って、セッション識別子の管理にセッションリストを使用する。セッションリストとは、セッション識別子をキーとして複数のセッション情報を管理できるものである。ここで、セッション情報とは、セッション識別子、評価値、ステップＳ２２０１で行われたリクエスト分析結果が複数、付加情報、からなる構造を持つ。評価値については、後述する。なお、セッションリストはＲＡＭ２０２やＨＤＤ２０４等に保存されている。また、自動提示登録処理が終了しても、その内容が放棄されることはなく、ＨＤＤ２０４等に保存されている。従って、自動提示登録処理の始めには、ＨＤＤ２０４等からＲＡＭ２０２へ読み込む等の処理が必要である。
【０２２４】
ステップＳ２２０３における処理の結果、取得したセッション識別子が既にセッションリストに登録されている場合には処理をステップＳ２２０４に進める。一方、取得したセッション識別子がセッションリストには未だ登録されていない場合には、処理をステップＳ２２０５に進める。
【０２２５】
ステップＳ２２０５では、ステップＳ２２０１で取得したセッション識別子を、新規キーとしてセッションリストに追加登録する。このとき、追加登録する構造はセッション情報であり、キーであるセッション識別子、ステップＳ２２０１で取得したリクエスト分析結果が設定されている。なお、後述するが、このとき評価値は０である。
【０２２６】
一方、ステップＳ２２０４では、ステップＳ２２０１で取得したセッション識別子はセッションリストに登録されているので、ステップＳ２２０１で取得したリクエスト分析の結果を、既に登録されているセッション情報に追加して登録する。この処理の結果、このセッション情報には、複数のリクエスト分析結果が登録されていることとなる。
【０２２７】
なお、セッション情報にリクエスト分析結果を追加する際には、同じ構成を持つリクエスト分析結果（同一ＵＲＬに対して、属性名集合が一致する）が既に登録されているか否かを先に判断する。これは、同一ＨＴＴＰセッション内で複数のウェブメールを送信した場合を想定している。従って、このような場合は、このような追加登録処理を行うだけでなく、１以上のウェブメールが送信されている旨を示す情報をセッション情報に付与する。
【０２２８】
次に、ステップＳ２２０６では、中継サーバ１１０は、ステップＳ２２０１で行われたＨＴＴＰリクエスト分析処理の結果を参照し、このＨＴＴＰリクエスト中にウェブメールで使用する構成要素が含まれているか否かを判断する。即ち、ウェブメールの送信に係るＨＴＴＰリクエストがログに含まれているのか否かを判断する。例えば、メールアドレスや、添付ファイルの有無、日本語文字列等が、ウェブメールで使用する構成要素に該当する。例えば、ある属性値が「ｆｏｏ＠ｅｘａｍｐｌｅ．ｃｏｍ」であれば、この属性名がメールアドレスを持つ項目であることがわかる（文字＠を挟んで、後方にドメインと思われる文字列．ｃｏｍが存在する）。このような構成要素がＨＴＴＰリクエストに含まれていれば、このＨＴＴＰリクエストはウェブメールの送信に係るものであると判断する。
【０２２９】
係る判断の結果、ウェブメールで使用する構成要素が含まれているＨＴＴＰリクエストが存在する場合には、処理をステップＳ２２０７に進める。一方、ウェブメールで使用する構成要素が含まれているＨＴＴＰリクエストが存在しなかった場合には、処理をステップＳ２２０８に進める。
【０２３０】
ステップＳ２２０７では、ウェブメールで使用する構成要素が含まれているリクエスト分析結果に対する評価値を算出する。例えば、リクエスト分析結果中にメールアドレスを属性値として含む場合には３点、日本語文字列を属性値として含む場合には１点、日本語文字列が長文（所定長以上）である場合には３点、添付ファイルが含まれている場合には５点、を現得点に加算する。このようにして、リクエスト分析結果からこのような条件を検出する毎に、現得点（最初は０点）に加算することで、リクエスト分析結果に対する累積得点を評価値として求めることができる。即ち、この評価値とは、「ウェブメールの送信に係るＨＴＴＰリクエストの確からしさ」を示すものであり、その値が高ければ高いほど、ウェブメールの送信に係るＨＴＴＰリクエストの確からしさが高くなる。
【０２３１】
なお、このようにして求めた評価値は、セッション情報に記録される。即ち、同じセッション識別子を持つ複数のリクエスト分析結果が存在する場合には、それぞれのリクエスト分析結果の評価値を、このセッション情報に記録された評価値の現得点に加算する。これは、同一のＨＴＴＰセッションで評価される属性名が、複数のＨＴＴＰリクエストに分割されていても（例えば、本文と添付ファイル）、また、単一のＨＴＴＰリクエストで送信されても（例えば、本文＆添付ファイル）、評価値が同値になるようにするためである。
【０２３２】
次に、ステップＳ２２０８では、予め定められた期間範囲を超えたセッション識別子がセッションリスト中に存在するか否かを判断する。ここで、「予め定められた期間範囲」について説明する。
【０２３３】
中継サーバ１１０側では予め期間ｔとリクエスト数ｎとが設定されており、セッション情報は、セッションリストに登録されてから期間ｔの期間だけしかセッションリストに保存されない（残さない）。これは、長時間に渡ってセッション情報を保持するべきではなくため、大量に保持しておく必要がないことに起因している。即ち、この期間ｔを超えると、中継サーバ１１０は、このセッション情報をセッションリストから削除する。なお、時間ｔとは実時間における期間を表すものではなく、分析対象となっているログの記録時間における期間を示すものである。例えば、期間ｔが１時間の場合、実処理時間で１時間保存するのではなく、新規登録したセッション情報が持つリクエスト分析結果の時間情報を基点として、１時間後の時間情報までのリクエスト分析結果を保存することを意味する。
【０２３４】
また、セッションリストには、セッション情報あたり、リクエスト分析結果数ｎまでしか登録しない（残さない）。これは、ウェブメールサービスへのリクエストは短時間に大量に発生する性質を持たないため、大量に保持しておく必要がないことに起因している。従って、期間ｔとリクエスト数ｎについては、どちらか一方の範囲外となったときにセッションリストの期間範囲を超えたと判断する。
【０２３５】
セッションリストの期間範囲を超えていない限りは、自動提示登録処理では、未知のウェブメールサービスの提示は行わない。
【０２３６】
従って、期間ｔを超えたセッション情報が存在するか、若しくはこの時点でセッション情報が保持するリクエスト分析結果の数がｎよりも多い、という条件が満たされた場合には、処理をステップＳ２２０９に進める。一方、この条件が満たされなかった場合には、「検出なし」と判断し、図２２に示したフローチャートに従った処理を終了する。なお、セッションリストは放棄されず、ＲＡＭ２０２やＨＤＤ２０４等に保存される。
【０２３７】
ステップＳ２２０９では、上述の条件を満たしたセッション情報を、セッションリストから削除する。なお、係る処理では、セッションリストからは削除するものの、セッション情報そのものについてはＲＡＭ２０２などのメモリから削除するわけではない。
【０２３８】
次に、ステップＳ２２１０では、セッションリストから削除したセッション情報の評価値が、予め定められた閾値を越えているか否かを判断する。係る判断の結果、閾値を越えている場合には、「検出あり」と判断し、図２２に示したフローチャートに従った処理を終了する。なお、セッションリストは放棄されず、ＲＡＭ２０２やＨＤＤ２０４等に保存される。
【０２３９】
一方、閾値を越えていない場合には、「検出なし」と判断し、図２２に示したフローチャートに従った処理を終了する。なお、セッションリストは放棄されず、ＲＡＭ２０２やＨＤＤ２０４等に保存される。
【０２４０】
図６に戻って、次に、ステップＳ６１２において「検出なし」と判断された場合には、ステップＳ６１３を介してステップＳ６１２に処理を戻す。一方、ステップＳ６１２において「検出あり」と判断された場合には、ステップＳ６１３を介してステップＳ６１１に処理を進める。なお、中継サーバ１１０は、ステップＳ６１２における判断結果を、管理者用端末装置１２０に通知する。
【０２４１】
ステップＳ６１１では、管理者用端末装置１２０は、半自動抽出登録と同様、例えば、図１７に例示した画面１７００を管理用ブラウザ７０１を介して表示する。この画面１７００では、セッションリストから削除されたセッション情報が有するリクエスト分析結果について表示する。
【０２４２】
以上で自動提示登録の説明を終了するが、自動提示登録の結果が不明確な場合、管理者用端末装置１２０の操作者は、ステップＳ６１１で表示された情報をもとにして、更に半自動抽出登録処理を指示することができる。これにより、より正確にウェブメールサービスに係る情報（属性名情報）をＤＢ１１１に登録することができる。
【０２４３】
以上の説明により、本実施形態によれば、ＨＴＴＰプロトコルを利用したウェブメールサービスに対して、従来のＳＭＴＰプロトコルを利用した電子メールの送信制御システムと同等の設定を行うことが容易となる。また、新規のウェブメールサービスをログから自動的に検出し、効率的な送信制御を実施することができる。
【０２４４】
なお、以上の説明で用いたデータやテーブル情報の構成、装置やシステムの構成については一例であって、当業者であれば、上記の処理と同等の処理を実現できるのであれば、それらは適宜変形しても良い。
【０２４５】
ここで、上記処理により作成されたテーブル情報３００、テーブル情報４００、テーブル情報５００を使用して中継サーバ１１０によって行われる、ウェブメールの送信制御処理について簡単に触れておく。
【０２４６】
ＤＢ１１１には前述したとおり、ウェブメール規制ルールが登録されている。ウェブメール規制ルールには、例えば、特定のアドレスがＴＯに設定されている、特定のアドレスがＣＣに設定されている、特定のキーワードがメール件名や本文に存在する等の条件と、その条件に合致した場合に行われる、ウェブメールの送信を許可する（中継する）／拒否する（中断する）、当該ウェブメールの送信者の管理者の判断に従う（保留する）等の処理とが登録されている。特定のアドレスに対して添付ファイル付きのウェブメールが送信されようとした場合、複数のドメインを持つアドレスに対して送信されようとしているメールが送信されようとした場合、閾値以上の送信先がＴＯやＣＣに設定されている場合を条件とするウェブメール規制ルールを設定することも勿論可能である。
【０２４７】
そして、中継サーバ１１０は、クライアント端末装置１００から広域ネットワーク網１４０に対して送信されたＨＴＴＰリクエストを取得すると、その送信先となっているＵＲＬが図４のテーブル情報４００のＵＲＬ４０４に設定されているかを判断する。テーブル情報４００のＵＲＬ４０４に設定されているＵＲＬに対するＨＴＴＰリクエストであった場合には、そのＨＴＴＰリクエストをテーブル情報４００中の当該ＵＲＬのレコードの送信データ情報４１２に定義している各種の属性名情報（ＦＲＯＭ４０５、ＴＯ４０６等）を用いてＨＴＴＰリクエストを分析し、ウェブメールのＦＲＯＭ、ＴＯなどとして設定されている各種の情報（属性値情報）を取得する。
【０２４８】
そして、取得した各種の情報（属性値情報）をウェブメール規制ルールに適用することで、ウェブメールの送信制御を行うことになる。取得したＨＴＴＰリクエストの送信先となっているＵＲＬがテーブル情報４００のＵＲＬ４０４に設定されていなかった場合には、ウェブメール規制ルールを適用することはない。しかし、他の送信制御ルールがある場合には、その送信制御ルールを適用した送信制御処理を行うことになる。
【０２４９】
＜その他の実施形態＞
以上、実施形態について示したが、同様のことは、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様を取ることが可能である。具体的には、中継サーバ及びクライアント端末装置については、それぞれ複数の機器から構成されるシステムに適用しても、ひとつの機器からなるシステムに適用してもよい。
【０２５０】
また、本実施形態と同様のことは、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本実施形態と同様の目的を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を、このシステムあるいは装置に読み出すことによって、そのシステムあるいは装置が、同様の効果を享受することが可能となる。
【０２５１】
さらに、本実施形態と同様の目的を達成するためのソフトウェアをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、同様の効果を享受することが可能となる。
【０２５２】
なお、上述した実施形態及びその変形例を組み合わせた構成もまた、特許請求の範囲に記した発明に含まれるものである。
【図面の簡単な説明】
【０２５３】
【図１】本発明の実施形態に係る情報処理装置を適用可能なシステムの構成例を示すブロック図である。
【図２】中継サーバ１１０のハードウェア構成例を示すブロック図である。
【図３】テーブル情報３００の構成例を示す図である。
【図４】テーブル情報４００の構成例を示す図である。
【図５】テーブル情報５００の構成例を示す図である。
【図６】半自動抽出登録の処理と、自動提示登録の処理と、を示す登録処理に関するフローチャートである。
【図７Ａ】中継サーバ１１０に通常モードが設定された場合におけるシステムの構成を示す図である。
【図７Ｂ】テーブル情報を作成するためのモード（検出モード）が中継サーバ１１０に設定された場合におけるシステムの構成を示す図である。
【図８】本発明の実施形態に係るシステムを構成する装置間の半自動抽出登録の動作を示す図である。
【図９】サービス追加画面９００の表示例を示す図である。
【図１０】新たにウェブメールサービスについての情報をテーブル情報３００、４００、５００に追加するために用いる画面の表示例を示す図である。
【図１１】新たにウェブメールサービスについての情報をテーブル情報３００、４００、５００に追加するために用いる画面の表示例を示す図である。
【図１２】前記閲覧用ブラウザ７１１の起動（ステップＳ６０６）から終了（ステップＳ６１０）までの処理と並行して中継サーバ１１０及び検出プロキシー７１２で実施される半自動抽出登録の詳細フローチャートである。
【図１３】ステップＳ１２０２における処理の詳細を示すフローチャートである。
【図１４】検出プロキシー７１２におけるステップＳ１２０５の処理の詳細を示すフローチャートである。
【図１５】ステップＳ１２０８における処理の詳細を示すフローチャートである。
【図１６】ステップＳ１２１０における処理の詳細を示すフローチャートである。
【図１７】ＨＴＴＰリクエスト分析結果を一覧表示する画面１７００の表示例を示す図である。
【図１８】添付ファイルのみ送信した場合のＨＴＴＰリクエスト分析結果を一覧表示した画面１８００の表示例を示す図である。
【図１９】登録情報を確認するための画面１９００の表示例を示す図である。
【図２０】ウェブメールサービス毎の情報を一覧表示した画面２０００の表示例を示す図である。
【図２１】様々な画面の遷移図を示す図である。
【図２２】ステップＳ６１２における処理の詳細を示すフローチャートである。
【図２３】ＨＴＴＰリクエストの構成例を示す図である。
【図２４】ウェブメールに添付ファイルを添付した場合のＨＴＴＰリクエストの構成例を示す図である。
【図１】
2010128929.tif 000003
【図２】
2010128929.tif 000004
【図３】
2010128929.tif 000005
【図４】
2010128929.tif 000006
【図５】
2010128929.tif 000007
【図６】
2010128929.tif 000008
【図７Ａ】
2010128929.tif 000009
【図７Ｂ】
2010128929.tif 000010
【図８】
2010128929.tif 000011
【図９】
2010128929.tif 000012
【図１０】
2010128929.tif 000013
【図１１】
2010128929.tif 000014
【図１２】
2010128929.tif 000015
【図１３】
2010128929.tif 000016
【図１４】
2010128929.tif 000017
【図１５】
2010128929.tif 000018
【図１６】
2010128929.tif 000019
【図１７】
2010128929.tif 000020
【図１８】
2010128929.tif 000021
【図１９】
2010128929.tif 000022
【図２０】
2010128929.tif 000023
【図２１】
2010128929.tif 000024
【図２２】
2010128929.tif 000025
【図２３】
2010128929.tif 000026
【図２４】
2010128929.tif 000027
【手続補正書】
【提出日】平成21年10月30日(2009.10.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
端末装置からウェブメールサービスを提供するウェブメールサーバに送信されるウェブメールデータのＨＴＴＰリクエスト、に対して設定される複数の設定情報の属性値を受け付ける受付手段と、
前記端末装置から前記ウェブメールサーバに対して送信されたウェブメールデータのＨＴＴＰリクエストデータであって、前記受付手段で受け付けた前記属性値を前記設定情報として設定したウェブメールデータのＨＴＴＰリクエストを受信する受信手段と、
前記受信手段で受信した前記ウェブメールデータのＨＴＴＰリクエストを解析することで、当該ＨＴＴＰリクエストに含まれる送信先ＵＲＬ、及び、前記受付手段で受け付けた属性値の設定パターンを検出する検出手段と、
前記検出手段で検出した、送信先ＵＲＬと、前記ウェブメールサーバに対するウェブメールデータのＨＴＴＰリクエストの通信制御に用いられる前記設定パターンであって、前記ウェブメールデータの設定情報の属性値を取得するための前記設定パターンと、を対応付けて記憶する第１の記憶手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記受信手段が、前記端末装置から前記ウェブメールサーバに対して送信された前記ウェブメールデータのＨＴＴＰリクエストを複数受信した場合に、前記複数のウェブメールデータのＨＴＴＰリクエスト全てで共通する属性値を持つ設定情報をセッション識別情報として特定する特定手段を更に備え、
前記第１の記憶手段は、前記特定手段で特定されたセッション識別情報を更に記憶すること
を特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記検出手段は、前記ＨＴＴＰリクエストのＨＴＴＰヘッダ及びＨＴＴＰボディを構成要素単位で分解してそれぞれの構成要素の属性名と属性値の対を検出し、検出した属性名のうち、前記受付手段で受け付けた属性値と対となる属性名を、前記設定パターンとして検出すること
を特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記ＨＴＴＰリクエストを解析することで前記検出手段が検出した属性値に対応する設定情報を識別可能に画面表示するための画面情報を生成する生成手段
を更に備えることを特徴とする請求項３に記載の情報処理装置。
【請求項５】
ウェブメールの設定情報に設定されている属性値を条件とした、前記ウェブメールデータの通信の送信制御に用いるウェブメール規制ルールを記憶する第２の記憶手段と、
端末装置より受信したＨＴＴＰリクエストに含まれる送信先ＵＲＬが、前記第１の記憶手段に前記されているかを判定する判定手段と、
前記判定手段で当該送信先ＵＲＬが前記第１の記憶手段に記憶されていると判定した場合に、当該送信先ＵＲＬに対応付けられている前記設定パターンを用いて属性値を取得する取得手段と、
前記取得手段で取得した属性値と前記ウェブメール規制ルールとを照合することで、ウェブメールデータの送信の可否を制御する送信制御手段と、
を更に備えることを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
【請求項６】
前記設定情報には、ウェブメールの件名、送信元、送信先、本文、及び添付ファイルのうちの少なくともいずれか１つが含まれることを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
【請求項７】
情報処理装置によって行われる情報処理方法であって、
端末装置からウェブメールサービスを提供するウェブメールサーバに送信されるウェブメールデータのＨＴＴＰリクエスト、に対して設定される複数の設定情報の属性値を受け付ける受付工程と、
前記端末装置から前記ウェブメールサーバに対して送信されたウェブメールデータのＨＴＴＰリクエストデータであって、前記受付工程で受け付けた前記属性値を前記設定情報として設定したウェブメールデータのＨＴＴＰリクエストを受信する受信工程と、
前記受信工程で受信した前記ウェブメールデータのＨＴＴＰリクエストを解析することで、当該ＨＴＴＰリクエストに含まれる送信先ＵＲＬ、及び、前記受付工程で受け付けた属性値の設定パターンを検出する検出工程と、
前記検出工程で検出した、送信先ＵＲＬと、前記ウェブメールサーバに対するウェブメールデータのＨＴＴＰリクエストの通信制御に用いられる前記設定パターンであって、前記ウェブメールデータの設定情報の属性値を取得するための前記設定パターンと、を対応付けて記憶する第１の記憶工程と
を備えることを特徴とする情報処理方法。
【請求項８】
コンピュータを、
端末装置からウェブメールサービスを提供するウェブメールサーバに送信されるウェブメールデータのＨＴＴＰリクエスト、に対して設定される複数の設定情報の属性値を受け付ける受付手段と、
前記端末装置から前記ウェブメールサーバに対して送信されたウェブメールデータのＨＴＴＰリクエストデータであって、前記受付手段で受け付けた前記属性値を前記設定情報として設定したウェブメールデータのＨＴＴＰリクエストを受信する受信手段と、
前記受信手段で受信した前記ウェブメールデータのＨＴＴＰリクエストを解析することで、当該ＨＴＴＰリクエストに含まれる送信先ＵＲＬ、及び、前記受付手段で受け付けた属性値の設定パターンを検出する検出手段と、
前記検出手段で検出した、送信先ＵＲＬと、前記ウェブメールサーバに対するウェブメールデータのＨＴＴＰリクエストの通信制御に用いられる前記設定パターンであって、前記ウェブメールデータの設定情報の属性値を取得するための前記設定パターンと、を対応付けて記憶する第１の記憶手段
として機能させるためのコンピュータプログラム。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】変更
【補正の内容】
【００１３】
本発明は、以上の問題に鑑みてなされたものであり、ウェブメールサービスに関した送信制御システムの運用に用いる設定を容易に行うための仕組みを提供することを目的とする。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】変更
【補正の内容】
【００１５】
即ち、端末装置からウェブメールサービスを提供するウェブメールサーバに送信されるウェブメールデータのＨＴＴＰリクエスト、に対して設定される複数の設定情報の属性値を受け付ける受付手段と、
前記端末装置から前記ウェブメールサーバに対して送信されたウェブメールデータのＨＴＴＰリクエストデータであって、前記受付手段で受け付けた前記属性値を前記設定情報として設定したウェブメールデータのＨＴＴＰリクエストを受信する受信手段と、
前記受信手段で受信した前記ウェブメールデータのＨＴＴＰリクエストを解析することで、当該ＨＴＴＰリクエストに含まれる送信先ＵＲＬ、及び、前記受付手段で受け付けた属性値の設定パターンを検出する検出手段と、
前記検出手段で検出した、送信先ＵＲＬと、前記ウェブメールサーバに対するウェブメールデータのＨＴＴＰリクエストの通信制御に用いられる前記設定パターンであって、前記ウェブメールデータの設定情報の属性値を取得するための前記設定パターンと、を対応付けて記憶する第１の記憶手段と
を備えることを特徴とする。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
即ち、情報処理装置によって行われる情報処理方法であって、
端末装置からウェブメールサービスを提供するウェブメールサーバに送信されるウェブメールデータのＨＴＴＰリクエスト、に対して設定される複数の設定情報の属性値を受け付ける受付工程と、
前記端末装置から前記ウェブメールサーバに対して送信されたウェブメールデータのＨＴＴＰリクエストデータであって、前記受付工程で受け付けた前記属性値を前記設定情報として設定したウェブメールデータのＨＴＴＰリクエストを受信する受信工程と、
前記受信工程で受信した前記ウェブメールデータのＨＴＴＰリクエストを解析することで、当該ＨＴＴＰリクエストに含まれる送信先ＵＲＬ、及び、前記受付工程で受け付けた属性値の設定パターンを検出する検出工程と、
前記検出工程で検出した、送信先ＵＲＬと、前記ウェブメールサーバに対するウェブメールデータのＨＴＴＰリクエストの通信制御に用いられる前記設定パターンであって、前記ウェブメールデータの設定情報の属性値を取得するための前記設定パターンと、を対応付けて記憶する第１の記憶工程と
を備えることを特徴とする。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００１８
【補正方法】変更
【補正の内容】
【００１８】
本発明によれば、ＨＴＴＰプロトコルを利用したウェブメールサービスに対して、従来のＳＭＴＰプロトコルを利用した電子メールの送信制御システムと同等の設定を行うことが容易となり、効率的な送信制御を実施できる等の効果を奏する。