JP2007181031A - 情報処理装置、その制御方法、プログラム、及び記憶媒体 - Google Patents

Abstract

【課題】 ＨＴＴＰを利用した電子メール（Ｗｅｂメール）であってもＳＭＴＰを用いた電子メールと同様に、宛先、ＣＣや件名等、特定の意味を持った情報（セマンテック情報）に基づき、データの中継制御を行う為の技術を提供すること。
【解決手段】 中継サーバ１０１は先ず、ＨＴＴＰプロトコルを用いて電子メールの送受信を行うサービスを提供する為のホームページを提供するＨＴＴＰサーバ１０５にアクセスし、このホームページ上における操作が可能なクライアント端末装置１０２側でホームページを介して、送信対象の電子メールに関する操作入力が行われた場合に、クライアント端末装置１０２から送信された電子メールに関する情報を受信する。そしてこの情報に基づいて電子メールについて行われた操作のタイプを特定し、特定したタイプに応じて処理を行う。即ち、特定したタイプが電子メールの送信や保存を含む場合、この情報に基づいて、電子メールデータの送信を制御する。
【選択図】 図１

Description

本発明は、ＨＴＴＰプロトコルを用いて電子メールの送受信を行うための技術に関するものである。

ネットワーク技術の発展によって、情報のやりとりが非常に簡便に、且つ効率良く行うことが可能になっている。例えば会議に使用する資料を電子メールに添付して参加者に前もって送付したりすることが、手間も煩わしさもなく行うことが可能になっている。ただ、このようにネットワーク技術が発達し、情報のやりとりが容易に行われるようになった反面、重要な機密情報が簡単に外部に流れてしまうという危険性の度合いも増してきている。

情報漏洩の防止といった観点に立った場合、１つは外部からの不正アクセスに対しての対策を講じること、もう１つは内部からの不用意な重要データの送信について対策を行うことが重要になっている。情報の漏洩の発生原因としては、不正アクセスにより情報が盗まれてしまうことよりもむしろ、内部の人間の不注意、もしくは不正な行動によって情報が流出してしまうことのほうが多いのが現状である。

このような背景とあわせ、個人情報保護法などの施行により、企業には情報のきちんとした取り扱いが求められるようになったため、例えば、企業において情報の漏洩対策として、社内から外部へ送信される電子メールの内容（例えば、宛先や本文のテキスト情報、添付ファイルの内容）をチェックし、所定の条件に合致した場合にはその電子メールを社外に送信することを禁止するようなシステムを導入している。このことにより、社内から重要な機密情報が漏洩してしまう、あるいは企業として不利益な情報が流出してしまう危険性を低くしている。

一方、ネットワーク経由の情報漏洩や不利益な情報の流出の危険性は電子メール送信によるものだけではない。例えばインターネット上への掲示板への投稿などによる機密情報漏洩や不利益な情報の流出も考えられる。インターネットを用いたサービスが多様化してきており、そのサービス毎に情報漏洩に対しての企業としての対応が求められるようになっている。

上記掲示板への投稿による機密情報の漏洩や企業として不都合な情報の流出を防止するための技術としては、例えば、特許文献１が開示されている。係る技術によれば、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）でインターネット上の特定のサービスを指定し、そのサービスにのみ情報の送信を制御することで、従来の電子メール（ＳＭＴＰ）とは異なるプロトコル（ＨＴＴＰ）のデータに対してもインターネットの利便性を損なうことなく情報の漏洩の対策を講じることが可能になっている。
特開２００４−３４８２０２号公報

最近、従来の電子メール（ＳＭＴＰによりデータの送信が行われる）とは異なり、ＨＴＴＰを利用した電子メールを行うサービスが広く行われるようになってきている。このサービスでは、電子メール用のアプリケーションを使用することなく、汎用的なブラウザソフトウェアを使用して電子メールの送受信が可能になっている。

このような形式でのメール送信の制御については、従来の電子メール（ＳＭＴＰによるもの）とは通信の規約が異なるために、従来の電子メールに対しての中継制御の手法を用いることが出来ない。また、上記特許文献１に開示されている技術を用いることで、特定キーワードを用いての通信制御は可能であるが、従来の電子メールの通信制御システムのような、宛先、ＣＣ、件名といった情報に基づいた細かい通信制御を行うことは出来ない。

また、そのような通信の制御を行おうとした場合にも、ＳＭＴＰを使用した電子メールとは異なり、統一的な規約がないために、プロトコルの違いを考慮しただけでは、従来の電子メールの中継制御の手法を適用することが不可能であるという問題がある。

本発明は以上の問題に鑑みてなされたものであり、ＨＴＴＰを利用した電子メール（Ｗｅｂメール）であってもＳＭＴＰを用いた電子メールと同様に、宛先、ＣＣや件名等、特定の意味を持った情報（セマンテック情報）に基づき、データの中継制御を行う為の技術を提供することを目的とする。

本発明の目的を達成する為に、例えば、本発明の情報処理装置は以下の構成を備える。

即ち、ＨＴＴＰプロトコルを用いて電子メールの送受信を行うサービスを提供する為のホームページを提供するＨＴＴＰサーバと、当該ＨＴＴＰサーバにアクセスし、当該ホームページ上における操作が可能なクライアント端末装置との間のデータ通信を中継する情報処理装置であって、
前記クライアント端末装置側で前記ホームページを介して、送信対象の電子メールに関する操作入力が行われた場合に、前記クライアント端末装置から送信された当該電子メールに関する情報を受信する第１の受信手段と、
前記情報に基づいて前記電子メールについて行われた操作のタイプを特定し、当該特定したタイプに応じて処理を行う第１の処理手段とを備え、
前記第１の処理手段は、前記情報に基づいて、前記電子メールのデータの送信を制御することを特徴とする。

本発明の目的を達成する為に、例えば、本発明の情報処理装置の制御方法は以下の構成を備える。

即ち、ＨＴＴＰプロトコルを用いて電子メールの送受信を行うサービスを提供する為のホームページを提供するＨＴＴＰサーバと、当該ＨＴＴＰサーバにアクセスし、当該ホームページ上における操作が可能なクライアント端末装置と、の間のデータ通信を中継する情報処理装置の制御方法であって、
前記クライアント端末装置側で前記ホームページを介して、送信対象の電子メールに関する操作入力が行われた場合に、前記クライアント端末装置から送信された当該電子メールに関する情報を受信する受信工程と、
前記情報に基づいて前記電子メールについて行われた操作のタイプを特定し、当該特定したタイプに応じて処理を行う処理工程とを備え、
前記処理工程では、前記情報に基づいて、前記電子メールのデータの送信を制御することを特徴とする。

本発明の構成により、ＨＴＴＰを利用した電子メール（Ｗｅｂメール）であってもＳＭＴＰを用いた電子メールと同様に、宛先、ＣＣや件名等、特定の意味を持った情報（セマンテック情報）に基づき、データの中継制御を行うことができる。

以下添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。

［第１の実施形態］
図１は、本実施形態に係るシステムの構成例を示す図である。同図に示す如く、本実施形態に係るシステムは、メールサーバ１０４、ＨＴＴＰサーバ１０５、クライアント端末装置１０２ａ、１０２ｂ、そして本実施形態に係る情報処理装置として機能する中継サーバ１０１により構成されている。以下、本実施形態に係るシステムを構成するこれらについて説明する。

クライアント端末装置１０２ａ、１０２ｂは、中継サーバ１０１、広域ネットワーク網１０６を介してＨＴＴＰサーバ１０５にアクセスし、ＨＴＴＰサーバ１０５が提供する各種のホームページのうち所望のホームページを閲覧するために用いられるものである。また、クライアント端末装置１０２ａ、１０２ｂは、ＳＭＴＰプロトコルを用いた一般の電子メールの送受信も行うことができ、その場合には、送信した電子メールは中継サーバ１０１、広域ネットワーク網１０６を介してメールサーバ１０４に対して送信される。また、クライアント端末装置１０２ａ、１０２ｂが電子メールを受信する際には、中継サーバ１０１、広域ネットワーク網１０６を介してメールサーバ１０４にアクセスし、電子メールのダウンロードを指示すれば良い。

ＨＴＴＰサーバ１０５は、一般のプロバイダに設けられているＨＴＴＰサーバと同様の動作を行うものであり、中継サーバ１０１、広域ネットワーク網１０６を介してアクセスしてきたクライアント端末装置１０２ａ、１０２ｂに対して要求に応じたホームページを提供するものである。本実施形態では、このようなホームページの１つとして、ＨＴＴＰプロトコルを用いて電子メールの送受信を行うサービスを提供するホームページ（以下「Ｗｅｂメールページ」とする）がある。以下ではこのＨＴＴＰプロトコルを用いて送受信される電子メールを「Ｗｅｂメール」と呼称する。Ｗｅｂメールページについては周知の如く、一般のプロバイダで提供されているものであるので、これに関する詳細な説明は省略する。

中継サーバ１０１は、クライアント端末装置１０２ａ、１０２ｂと、ＨＴＴＰサーバ１０５との間のデータ通信を中継するためのものである。クライアント端末装置１０２ａ、１０２ｂがＨＴＴＰサーバ１０５が提供するＷｅｂメールページに対してアクセスし、このＷｅｂメールページ上で電子メールの作成や保存、送信などの操作指示を入力した場合、中継サーバ１０１は、この操作指示を受け、受けた操作指示に従った各種の処理を実行する。中継サーバ１０１が行う処理について詳しくは後述する。

広域ネットワーク網１０６は、インターネットに代表されるネットワークである。１０３は、ＬＡＮやインターネットなどのネットワークにより構成されるものである。

図２は、中継サーバ１０１のハードウェア構成を示すブロック図である。

２０１はＣＰＵで、ＲＡＭ２０２やＲＯＭ２０３に格納されているプログラムやデータを用いて中継サーバ１０１全体の制御を行うと共に、中継サーバ１０１が行う後述の各処理を実行する。

２０２はＲＡＭで、ＨＤＤ（ハードディスクドライブ）２０４や記憶媒体ドライブ２０６からロードされたプログラムやデータ、ネットワークＩ／Ｆ（インターフェース）２０５を介して外部から受信したプログラムやデータ等を一時的に記憶するためのエリアや、ＣＰＵ２０１が各種の処理を実行する際に用いるワークエリア等、各種のエリアを適宜提供することができる。

２０３はＲＯＭで、中継サーバ１０１の設定データや、ブートプログラム等を格納する。

２０４はＨＤＤで、ＯＳ（オペレーティングシステム）や、中継サーバ１０１が行う後述の各処理をＣＰＵ２０１に実行させるためのプログラムやデータなどを保存するものであり、これらはＣＰＵ２０１による制御に従って適宜ＲＡＭ２０２にロードされ、ＣＰＵ２０１による処理対象となる。

２０５はネットワークＩ／Ｆで、中継サーバ１０１を上記ネットワーク１０３、広域ネットワーク網１０６に接続するためのものであり、中継サーバ１０１はこのネットワークＩ／Ｆ２０５を介して、ネットワーク１０３、広域ネットワーク網１０６に接続されている各装置とのデータ通信を行うことができる。

２０６は記憶媒体ドライブで、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／ＲＷ、ＤＶＤ―ＲＯＭ、ＤＶＤ−Ｒ／ＲＷ、ＤＶＤ−ＲＡＭ等の記憶媒体に記録されているプログラムやデータを読み出し、ＲＡＭ２０２やＨＤＤ２０４に出力する。なお、ＨＤＤ２０４が保持している情報のうちの一部をこの記憶媒体に記憶させておいても良い。

２０７はキーボード、２０８はマウスやジョイスティックなどにより構成されているポインティングデバイスであり、中継サーバ１０１の操作者が操作することで、各種の指示をＣＰＵ２０１に対して入力することができる。

２０９は表示部で、ＣＲＴや液晶画面などにより構成されており、ＣＰＵ２０１による処理結果を画像や文字などでもって表示することができる。

２１０は外部機器接続Ｉ／Ｆで、周辺機器を中継サーバ１０１に接続させるためのポートである。中継サーバ１０１は、この外部機器接続Ｉ／Ｆ２１０を介して、この周辺機器とのデータの送受信を行う。外部機器接続Ｉ／Ｆ２１０は、ＵＳＢやＩＥＥＥ１３９４等により構成されており、通常複数の外部機器Ｉ／Ｆを有する。周辺機器との接続形態は有線／無線を問わない。

２１１は上述の各部を繋ぐバスである。

なお、中継サーバ１０１のハードウェア構成は図２に示した構成を有するとして説明するが、必ずしも同図の構成を有することに限定するものではなく、中継サーバ１０１が行う処理として説明する以下の処理が実行可能な構成であれば、中継サーバ１０１の構成は適宜変形しても良い。

また、クライアント端末装置１０２ａ、１０２ｂ、ＨＴＴＰサーバ１０５、メールサーバ１０４のハードウェア構成についてであるが、これらには一般のコンピュータを適用するので、周知の如く、概ね図２に示した構成を有する。

次に、クライアント端末装置１０２ａ、１０２ｂが中継サーバ１０１、広域ネットワーク網１０６を介してＨＴＴＰサーバ１０５が提供するＷｅｂメールページにアクセスし、Ｗｅｂメールページ上にてＷｅｂメールの作成や保存、送信等を指示した場合に、中継サーバ１０１が行う処理について、同処理のフローチャートを示す図３を用いて以下説明する。

なお、同図のフローチャートに従った処理をＣＰＵ２０１に実行させる為のプログラムやデータはＨＤＤ２０４に保存されており、これをＣＰＵ２０１による制御に従ってＲＡＭ２０２にロードし、ロードしたプログラムやデータを用いてＣＰＵ２０１が処理を行うことで、中継サーバ１０１は以下説明する各処理を実行することになる。なお、以下の説明では、クライアント端末装置１０２ａ、１０２ｂをまとめてクライアント端末装置１０２と呼称する。

上述の通り、同図のフローチャートに従った処理を開始する時点では、クライアント端末装置１０２はＷｅｂメールページにアクセスしており、電子メールの作成や保存、送信などを指示可能な状態にある。例えば、クライアント端末装置１０２が有する表示装置の表示画面上にはＷｅｂメールページの画面が表示されており、このＷｅｂメールページには、電子メールの送信先（ＴＯ，ＣＣ，ＢＣＣ）を指定する領域、電子メール本文を記述するための領域や、作成した電子メールをＨＴＴＰサーバ１０５に保存したり、送信したり、あるいは、当該電子メールに添付するファイルを指定するためのボタン画像などが設けられている。

中継サーバ１０１は、クライアント端末装置１０２から何れの指示が送信されても良いように、待機状態にある。そして、クライアント端末装置１０２側で、電子メールの作成や保存、送信などの指示を入力した場合、例えば、作成や保存を指示するためのボタン画像がクライアント端末装置１０２側で指示された場合には、クライアント端末装置１０２からは、指示した内容を含むＨＴＴＰ中継パケット（ＨＴＴＰデータ）が中継サーバ１０１に送信される。中継サーバ１０１は、ネットワークＩ／Ｆ２０５を介してＨＴＴＰデータの受信を検知すると、これをＲＡＭ２０２、若しくはＨＤＤ２０４に格納する処理を行う（ステップＳ５０１）。この格納する処理は、送信された全てのＨＴＴＰデータの受信が完了するまで行う。

全てのＨＴＴＰデータ（クライアント端末装置１０２側で電子メールに関する１つの指示を入力した場合に、クライアント端末装置１０２から送信される全てのＨＴＴＰデータ）を受信した場合には処理をステップＳ５０２を介してステップＳ５０３に進め、受信したＨＴＴＰデータを解析し、リクエストメソッド、リクエストURL、プロトコルバージョン、リクエストヘッダ、リクエストボディ等、ＨＴＴＰデータを構成する各要素（以下の処理で参照する各要素）を抽出し、抽出したこれらの要素を含む１つのファイル（解析ファイル）を所定のフォーマットに従って作成する（ステップＳ５０３）。

尚、リクエストボディがある場合は、Content-TypeヘッダやContent-LengthまたはTransfer-Encodingヘッダの内容に基づき、リクエストボディの内容も解析(パース)し、テキスト情報を抽出する。もし、Content-Typeがマルチパート形式の場合は各パートを再帰的にパースしていく。

また、リクエストボディのデータ、もしくはパートのデータとしてPDFやワープロ文書などのテキスト情報を内部にもつ構造化データフォーマットのデータが含まれている場合は、各フォーマットデータからテキスト情報を抽出する。

次に、ＨＤＤ２０４から図５に示す中継制御ルールテーブルのデータをＲＡＭ２０２にロードし、ロードしたテーブルから１つルールＩＤを選択する（ステップＳ５０４）。図５は、中継サーバ１０１が行う処理を解析ファイルに基づいて決定するために参照する中継制御ルールテーブルの構成例を示す図である。

同図に示す如く、中継制御ルールテーブルには、それぞれのルールＩＤに対応する、捕捉パターン表現式、Ｗｅｂメール定義属性、アクション式のセットが登録されている。例えば、ルールＩＤ＝３には、＜パターン表現式−０３＞、（サービスＩＤ＝１，操作タイプ＝作成、コンテキスト操作手続き＝＜操作手続き−３＞）、＜アクション式−０３＞のセットが関連付けられている。

従って、上記ステップＳ５０４では、中継制御ルールテーブルに登録されているルールＩＤを１つ選択し、選択したルールＩＤに対応する捕捉パターン表現式、Ｗｅｂメール定義属性、アクション式を特定する処理を行う。なお、全てのルールＩＤについて既に選択している場合には処理をステップＳ５０７に進める。一方、全てのルールＩＤについて既に選択していない場合（即ち、選択したルールＩＤが未だ選択されていない場合）には処理をステップＳ５０５に進め、図４のフローチャートに従った処理を行う（ステップＳ５０５）。図４は、ステップＳ５０５における処理の詳細を示すフローチャートである。

先ず、解析ファイルを参照し、ステップＳ５０４で選択したルールＩＤに対応する捕捉パターン表現式と合致しているか否かをチェックする（ステップＳ６０１）。捕捉パターン表現式は、送信ＨＴＴＰデータの特定のインスタンス集合を表現するための式であり、図９に示す如く記述されており、解析ファイルがどのようなものであるかを特定するためのフィルタとして機能する。従って、解析ファイルと捕捉パターン表現式とが合致した場合には、この解析ファイルの内容は、捕捉パターン表現式で判断した内容に合致したものとして判断することができる。図９は、捕捉パターン表現式の一例を示す図である。図９の捕捉パターン表現式を送信ＨＴＴＰデータに対して評価すると、リクエストＵＲＬ文字列が”http:／／[a-z]+\.abc-mail\.co\.jp／mail／send.cgi“で表される正規表現パタンに合致し、キーが”FLAG0”で値が”ON”のＵＲＬのパラメーターが含まれており、さらにキーが”SEND”というＵＲＬパラメーターもしくはCOOKIEパラメーターを含み、かつリクエストメソッドが”GET”であり、かつユーザーエージェント名文字列が”Mozilla／5”という文字列で開始されるときに合致すると判定し、それ以外のときは合致しないと判定する。

ステップＳ６０１におけるチェック処理の結果、ステップＳ５０４で選択したルールＩＤに対応する捕捉パターン表現式と解析ファイルとが合致していない場合には処理を図３のステップＳ５０６を介してステップＳ５０４に戻し、未だ選択されていない次のルールＩＤ選択するのであるが、合致している場合には、処理をステップＳ６０２に進め、ステップＳ５０４で選択したルールＩＤに対応するＷｅｂメール定義属性が存在するか否かをチェックする（ステップＳ６０２）。図５に示した例では、ルールＩＤ＝３に対応するＷｅｂメール定義属性は存在するが、ルールＩＤ＝１に対応するＷｅｂメール定義属性は存在していない。

ここで、Ｗｅｂメール定義属性について説明する。Ｗｅｂメール定義属性は図５に示す如く、サービスＩＤ、操作タイプ、コンテキスト操作手続きにより構成されている。「サービスＩＤ」は、Ｗｅｂメールページの種別を示すものである。周知の如く、Ｗｅｂメールページを提供するプロバイダは複数種存在する。そこで、クライアント端末装置１０２が現在使用しているＷｅｂメールページがどのプロバイダによるＷｅｂメールページであるのかを特定する為に、Ｗｅｂメールページの種別毎にＩＤが割り当てられている。図６は、各サービスＩＤに対応するＷｅｂメールページの種別を登録したテーブルの構成例を示す図で、例えば、サービスＩＤ＝２は、「Ｃｏｏメール」なる種別のＷｅｂメールページ（Ｃｏｏメールサービスを提供しているＷｅｂメールページ）を示す。

「操作タイプ」は、クライアント端末装置１０２からの指示が何であるのかを示すものであり、同図では「（電子メールの）作成」、「（電子メールの）取り消し」、「（電子メールの）送信」、「（電子メールの）作成・送信」の何れかである。

「コンテキスト操作手続き」は、「操作タイプ」に応じて、中継サーバ１０１が行うべき処理内容を記述したものである。「コンテキスト操作手続き」について詳しくは後述する。

アクション式は、「操作タイプ」に応じて、中継サーバ１０１が最終的に行うべき処理内容を記述したものである。「アクション式」について詳しくは後述する。

従って、解析ファイルが例えば＜パターン表現式−０３＞に合致した場合には、クライアント端末装置１０２が使用しているＷｅｂメールページの種別はサービスＩＤ＝１のＷｅｂメールページ（ＡＢＣメールサービスを提供しているＷｅｂメールページ）であり、クライアント端末装置１０２から指示された内容は「（電子メールの）作成」であり、この指示に応じて中継サーバ１０１が行う処理は＜操作手続き−０３＞、＜アクション式−０３＞であると判断することができる。

図４に戻って、ステップＳ６０２における処理の結果、ステップＳ５０４で選択したルールＩＤに対応するＷｅｂメール定義属性が存在しない場合には処理をステップＳ６０４に進めるのであるが、存在する場合には処理をステップＳ６０３に進め、ステップＳ５０４で選択したルールＩＤに対応するコンテキスト操作手続きを実行する（ステップＳ６０３）。

図１０〜１３は、様々な操作タイプに対応するコンテキスト操作手続きの内容を示す図である。コンテキスト操作手続きは、１つの電子メールメッセージの送信処理が複数のHTTPトランザクションから構成される場合に、各HTTPトランザクションの送信内容をある特定のメール送信に関する部分的な情報としてＲＡＭ２０２内の送信メール情報テーブルの中へ記録するための手続きである。通常は１つの電子メールメッセージの送信処理が、複数のHTTPトランザクションから構成されるために単純なチェックだけでは制御できないという問題があるためにこのような処理を行うことになる。

図１０、１１に示したコンテキスト操作手続きは、操作タイプ＝作成の場合の例である。例えば図１０に示したコンテキスト操作手続きを実行すれば、先ず、作成しようとする電子メールに固有のサービスＩＤ、セッションキーを取得し、取得したサービスＩＤ、セッションキーを電子メールメッセージを特定するためにキー情報として、解析ファイル内に記述されている電子メールの宛先（Ｔｏ、Ｃｃ）を図７に示す送信メール情報テーブルに登録する。図１０のコンテキスト操作手続きの中で、「VAR SEVICE_ID; VAR SESSION-KEY; VAR SLOT_TO; VAR SLOT_CC;」は、それぞれ”Ｗｅｂメールサービスの識別子“、”セッションキー“、”ＴＯアドレス“、”ＣＣアドレス“の値を手続き実行中に保管するための変数宣言であり、「SERVICE_ID=GET_SERVICE_ID();」を実行すると現在評価中の中継制御ルールテーブルの現在行にあるサービスＩＤ行の値をSERVICE_ID変数へ代入し、「SESSION-KEY=URL_PARAM(“SESSID”)」を実行すると送信ＨＴＴＰデータの中のSESSIDという名前のパラメーターの値をSESSION-KEY変数へ代入し、「SLOT_TO=BODY_GET_ELEMENT_BY_ID(“text／xml”, “to_addr”);」を実行すると送信ＨＴＴＰデータの中のリクエストボディデータを”text／xml”形式として解析してその中から”to_addr”という識別子をもつＸＭＬエンティティの値をSLOT_TO変数に代入し、同様に「 SLOT_CC=BODY_GET_ELEMENT_BY_ID(“text／xml”, “to_addr”);」は”cc_addr”という識別子をもつＸＭＬエンティティの値をSLOT_CC変数に代入し、「STORE_MAIL_CONTEXT(SERVICE_ID, SESSION-KEY, TO, SLOT_TO);STORE_MAIL_CONTEXT(SERVICE_ID, SESSION-KEY, CC, SLOT_CC);」を実行するとSERVICE_ID変数とSESSION-KEY変数の値をキーとして、送信情報テーブルにＴＯ欄にSLOT_TO変数の値をＣＣ欄にSLOT_CC変数の値を格納する。

同様に図１１の内容は送信ＨＴＴＰデータのリクエストボディデータから添付ファイルを取り出して送信メール情報テーブルに格納する手続きを表している。このようにコンテキスト操作手続きは解析ファイルから要素データにアクセスする関数と送信メール情報テーブルを更新する関数が組み込まれている。また送信ＨＴＴＰデータからのセッションキーの取り出し方法、ＴＯやＣＣ、または本文、添付ファイル等のメール属性情報の取り出し方法は、Ｗｅｂメールサービスやまたそのバージョンなどによって異なるため、取り出し仕様そのものもコンテキスト操作手続きデータの中でプログラム形式で表現するものとする。

図７は、送信メール情報テーブルの構成例を示す図である。横１行が１つの送信メールに関する送信情報を表しており、同図では、送信メールに固有のサービスＩＤ、セッションキー、宛先（Ｔｏ、Ｃｃ）、Ｓｕｂｊｅｃｔ、本文、添付ファイル、開始時刻、送信者属性（認証識別子、クライアント端末装置１０２固有の識別情報としてのＩＰアドレス）のセットが１つの送信メールに関する送信情報として送信メール情報テーブルに登録されている。従って、１つの電子メールメッセージの送信処理が複数のHTTPトランザクションから構成される場合には、それら複数のHTTPトランザクションに対するコンテキスト操作手続きが実施されることによって、送信メール情報テーブルの横１行の情報が作成されることになる。図１０に示したコンテキスト操作手続きを実行すると、作成しようとする電子メールに関する送信情報（解析ファイル内に記述されている情報）がこの送信メール情報テーブルに登録されることになる。

もちろん、電子メールによっては添付ファイルが存在しないなど、必ずしも全ての送信情報が１つの電子メールについて存在するとは限らないので、存在しない送信情報に関しては、例えば、ｎｕｌｌなどを登録すればよい。

図１２に示したコンテキスト操作手続きは、操作タイプ＝取り消しの場合の例である。この場合、作成中のメールメッセージは送信を取り消されるとして、送信メール情報テーブルの対応する情報は削除してもよいと判断する。同図に示したコンテキスト操作手続きを実行すれば、取り消し対象としてクライアント端末装置１０２側から指示された電子メールに固有のサービスＩＤ、セッションキーを取得し、図７に例示した送信メール情報テーブルから、取得したサービスＩＤ、セッションキーで特定される送信情報を削除する処理を行う。図１２では、図１０と同様にＷｅｂメールサービスＩＤとセッションキーを取り出した後、「REMOVE_MAIL_CONTEXT(SERVICE_ID,SESSION-KEY,CC)；」命令でＷｅｂメールサービスＩＤとセッションキーをキーにして送信メール情報テーブルの対象エントリを削除している。

図１３に示したコンテキスト操作手続きは、操作タイプ＝送信の場合の例である。同図に示したコンテキスト操作手続きを実行すれば、送信対象としてクライアント端末装置１０２側から指示された電子メールに固有のサービスＩＤ、セッションキーを取得し、図７に例示した送信メール情報テーブルに登録されている送信情報のうち、取得したサービスＩＤ、セッションキーに対応する送信情報を取得する。そして、取得した送信情報中の「本文」の部分に、送信対象として指示された電子メールの本文（解析ファイルから取得）を登録する。図１３では、図１０の説明と同様に変数宣言とＷｅｂメールサービス識別子とセッションキーの取り出しのあと、「SLOT_BODY=BODY_GET_ELEMENT_BY_ID(”appliacation／x-www-form-urlencoded”,”mail_body”, “euc-jp”);」文で送信ＨＴＴＰデータのリクエストボディを”appliacation／x-www-form-urlencoded”形式として”mail_body”文字列がキーとなる値を取り出してEUC-JPへの文字コード変換した結果をSLOT_BODY変数へ代入し、「STORE_MAIL_CONTEXT(SERVICE_ID,SESSION-KEY,BODY,SLOT_BODY);」文で送信メール情報テーブルの本文フィールドの値をSLOT_BODY変数の内容で更新し、最後に「COMMIT_MAIL_MESSAGE(SERVICE_ID,SESSION-KEY);」文で送信メール情報テーブルのＷｅｂメールサービスＩＤとセッションキーで識別されるメールセッション情報セットが完了したとする。

このように、解析ファイルが、ステップＳ５０４で取得したルールＩＤに対応する捕捉パターン表現式に合致した場合には、合致した捕捉パターン表現式に対応するコンテキスト操作手続きを実行する。これにより、クライアント端末装置１０２側から指示されたサービスIDとセッションキーによって特定される電子メールに関する操作を中継サーバ１０１が行うことになる。

また、中継サーバ１０１が電子メールに関する処理を行う毎に、図７に例示した送信メール情報テーブルに登録された送信情報のうち、クライアント端末装置１０２側から指示された電子メールに関する送信情報を、操作タイプに応じて更新することになる。

図４に戻って、次に、ステップＳ５０４で選択したルールＩＤに対応するアクション式を実行する（ステップＳ６０４）。図１４〜１７は、様々な操作タイプに対応するアクション式の内容を示す図である。図１４、１５に示したアクション式は、クライアント端末装置１０２側から送信されたＨＴＴＰデータが、Ｗｅｂメールに関するものではない場合（Ｗｅｂメールページ以外のホームページ閲覧のための要求である場合）に、中継サーバ１０１が実行する処理を示すものであり、図１４に示したアクション式を実行すれば、ＲＥＪＥＣＴを返す。図１５に示したアクション式を実行すれば、ＲＥＪＥＣＴを返すと共に、システム管理者が使用する端末装置にメールを送信する。アクション式は捕捉パターン表現式に該当したリクエストに対するアクセス判定の結果を決定するための評価式である。また評価結果を返すとともにその結果に基づいて駆動することができる処理を定義することができる。アクション式の値としてＯＫ、ＲＥＪＥＣＴ、ＣＯＮＴＩＮＵＥのいずれかを返すものとする。

図１６に示したアクション式は、操作タイプ＝作成の場合の例である。同図のアクション式を実行すると、そのまま処理を継続するよう、ＣＯＮＴＩＮＵＥを返す。即座に許可してよい場合はＯＫを返せばよい。

図１７に示したアクション式は、操作タイプ＝送信の場合の例である。同図のアクション式を実行すると、ＧＥＴ＿ＫＥＹＷＯＲＤ（ｘ）なる関数により、キーワードセットＩＤ＝ｘに対応する定義式を読み出す。図８は、各キーワードセットＩＤに対応する定義式が登録されているキーワード定義テーブルの構成例を示す図である。ここで定義式とは、送信しようとしている電子メールの本文中に含まれている各文字（列）などが所定の条件を満たしているのか否かをチェックするための条件式を示すものである。従って、電子メールの本文中に含まれていてはいけない様々な文字（列）の組み合わせに対応するために、キーワードセットＩＤ毎に異なる定義式が対応付けられている。

次に、送信対象の電子メールについて、発信者、及び送信先をチェックし、所定の発信者で、且つ所定の送信先である場合には、送信対象の電子メールの送信を禁止すべく、ＨＴＴＰサーバ１０５に対して、この送信対象の電子メールを送信しないので、キャンセルするよう、指示すると共に、ＲＥＪＥＣＴを返す。

次に、送信対処の電子メールの送信先の数をチェックし、チェックした数が所定数以上である場合には、システム管理者が使用する端末装置に対して電子メールを送信する。次に、ＧＥＴ＿ＫＥＹＷＯＲＤ（ｘ）で取得される定義式を用いて、送信対象の電子メールの本文をチェックし、本文中に定義式を満たす箇所が発見された場合には、この電子メールについての情報をログとしてＨＤＤ２０４に記録する処理を行う。そして、ＲＥＪＥＣＴを返していない限りはＯＫを返す。

なお、ここでは電子メールの送信先や送信先の数又は本文をチェックし、条件と一致するものについてアクションの実行を行ったが、これらに限定したものでなく、それぞれは発信者、SUBJECTや添付ファイルの有無、または、それらを組合せた条件と一致する場合に所定のアクションの実行を行うものとしてもよい。

また、条件と一致したものについてアクションの実行を行ったが、条件と一致したもののみ取消処理などを行うものとしたが、これに限らず、条件と一致しなかったもの全てについて取消処理などを行うものとしてもよい。

「操作タイプ」はこのほかに、「（電子メールをサーバに）保存」なども考えられる。「保存」が選択された場合にも送信と同様電子メールのデータがサーバに送信されることになるので「操作タイプ」が送信の場合と同様のアクション式を用意しておくことが好ましい。そうすることにより、保存処理が指示された場合にもクライアント装置１０２からＨＴＴＰサーバ１０５に送信される電子メールデータのチェックを行うことが可能になる。

以上説明したように、アクション式を実行することで、例えば、電子メールを送信する前に、送信対象の電子メールの送信先やその数といった項目をチェックし、チェックした項目が電子メールの送信条件を満たしているのかをチェックすることができる。そしてチェックの結果に応じて、送信を許可する／禁止する為の各種の手続き処理を行うことができる。

また、中継制御を行ったＷｅｂメールは送信の許可した／禁止したに関わらず、宛先、ＣＣ、ＢＣＣ、件名、本文、添付ファイル等の情報を検索キーとして、データの検索が可能になるようにデータベースに登録することが好ましい。その際には中継制御結果もあわせて登録しておいても勿論良い。

なお、このようなアクション式には様々なものがあり、それぞれの捕捉パターン表現式に応じて異なるアクション式を複数用意しておくことと、単一のアクション式の中でも複数の条件と起動される処理を設定することによって、送信される電子メールに対する中継可否と同時に副作用として起動される処理の組み合わせを複数種用意することができる。

以上、ステップＳ６０４における処理が完了すると、図３のステップＳ５０６に処理を戻し、上記ステップＳ６０４においてアクション式を実行した結果、返されたものがＲＥＪＥＣＴ、ＯＫ、ＣＯＮＴＩＮＵＥの何れであるのかをチェックする（ステップＳ５０６）。このチェックの結果、返されたものがＣＯＮＴＩＮＵＥである場合には処理をステップＳ５０４に戻し、未だ選択していないルールＩＤを選択し、以降の処理を繰り返す。

一方、返されたものがＯＫ又はＲＥＪＥＣＴである場合には処理をステップＳ５０７に進める。そして、返されたものがＯＫの場合、若しくはステップＳ５０４からステップＳ５０７に処理を移行した場合には、以降のＨＴＴＰの中継処理を実施する（ステップＳ５０７）。一方、返されたものがＲＥＪＥＣＴの場合には、クライアント端末装置１０２に対してアクセス拒否の旨をＨＴＴＰレスポンスとして通知する（ステップＳ５０７）。

なお、セッションキーが、１つのパラメータでなくて、複数のパラメータの合成となるようなケースでは、テーブルモデルでは対応できない。従って、アプリケーション制御を模倣して、
SESSION_KEY = URL_PARAM(”SESSIN_1”) + COOKIE_PARAM(”SESSIN_2”); （”+”は文字列連結）などと記述できるようにしておけばよい。

［第２の実施形態］
中継サーバ１０１は、Ｗｅｂメールだけでなく、通常の電子メール（ＳＭＴＰ）についてもＷｅｂメールと同様に、データ中継を行う前に送信データに対して所定の中継制御ルールを適用し、データ送信の許可／拒否を判定し、中継処理の継続、停止、禁止メッセージを応答などの動作を行い、さらには送信データを記録している。

通信の方法の違いはあるものの、Ｗｅｂメールと通常の電子メールとはデータの性質的には同様の性質を有するものであるので、それぞれを別個に管理するのではなく、統一的に管理できるほうが好ましい。

そこで中継サーバ１０１がＷｅｂメールおよび通常の電子メール（ＳＭＴＰによる電子メール）の双方の中継制御を行っている場合には、それらの送信データを統一的に管理することが好ましい。中継サーバは通常の電子メールを受信した場合には、宛先、ＣＣ、ＢＣＣ等のセマンテック情報や、宛先数や特定キーワードに基づいて、当該通常の電子メールの送信を許可する／拒否するといった通信制御を行うことになる。この際にもＷｅｂメールの場合と同様その捕捉パターンを定義しておき、ＳＭＴＰによる電子メールが捕捉パターンに合致した場合にどのような処理を行うかを定義したアクション式を用意しておくことになる。Ｗｅｂメールと通常の電子メールの双方の中継制御を中継サーバが行っている場合には、宛先、ＣＣ、ＢＣＣ、件名、本文、添付ファイル等の情報を検索キーとして、データの検索が可能になるようにＷｅｂメールと通常の電子メールの双方のデータを統一的にデータベースに登録することが好ましい。

［第３の実施形態］
図５、６のテーブルデータ、図１４〜図１７に示したアクション式については、中継サーバ１０１の操作者が任意のタイミングでもって編集するようにしても良い。

即ち、例えば、あるプロバイダが新たにＷｅｂメールページを提供する場合には、このＷｅｂメールページに対応するために、図６に示したテーブルに、このＷｅｂメールページに関する情報と、この情報に対して新たに発行したサービスＩＤを関連付けて登録する必要がある。

また、図１４〜図１７に示したコンテキスト操作手続きについても同様で、例えば図１７に示すアクション式において、ＧＥＴ＿ＫＥＹＷＯＲＤ（ｘ）の関数で引数として用いるｘの値や、電子メールの発信者、送信先について判定する基準、送信先の数が所定数以上である場合に送信するメールの送信先などについても適宜編集する必要がある。

また、以上のような情報を追加作成した場合には、これを図５に示すテーブルに登録する必要がある。

このように、これらのようなテーブルデータや条件などについては適宜編集可能なようにしても良い。なお、編集方法については、例えば、中継サーバ１０１が有する表示部２０９上に編集用のＧＵＩを表示し、このＧＵＩを介して編集するようにしても良い。

［その他の実施形態］
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

本発明の第１の実施形態に係るシステムの構成例を示す図である。 中継サーバ１０１のハードウェア構成を示すブロック図である。 クライアント端末装置１０２ａ、１０２ｂが中継サーバ１０１、広域ネットワーク網１０６を介してＨＴＴＰサーバ１０５が提供するＷｅｂメールページにアクセスし、Ｗｅｂメールページ上にてＷｅｂメールの作成や保存、送信等を指示した場合に、中継サーバ１０１が行う処理のフローチャートである。 ステップＳ５０５における処理の詳細を示すフローチャートである。 中継サーバ１０１が行う処理を解析ファイルに基づいて決定するために参照する中継制御ルールテーブルの構成例を示す図である。 各サービスＩＤに対応するＷｅｂメールページの種別を登録したテーブルの構成例を示す図である。 送信メール情報テーブルの構成例を示す図である。 各キーワードセットＩＤに対応する定義式が登録されているキーワード定義テーブルの構成例を示す図である。 捕捉パターン表現式の一例を示す図である。 様々な操作タイプに対応するコンテキスト操作手続きの内容を示す図である。 様々な操作タイプに対応するコンテキスト操作手続きの内容を示す図である。 様々な操作タイプに対応するコンテキスト操作手続きの内容を示す図である。 様々な操作タイプに対応するコンテキスト操作手続きの内容を示す図である。 様々な操作タイプに対応するアクション式の内容を示す図である。 様々な操作タイプに対応するアクション式の内容を示す図である。 様々な操作タイプに対応するアクション式の内容を示す図である。 様々な操作タイプに対応するアクション式の内容を示す図である。

Claims (8)

1. ＨＴＴＰプロトコルを用いて電子メールの送受信を行うサービスを提供する為のホームページを提供するＨＴＴＰサーバと、当該ＨＴＴＰサーバにアクセスし、当該ホームページ上における操作が可能なクライアント端末装置との間のデータ通信を中継する情報処理装置であって、
   前記クライアント端末装置側で前記ホームページを介して、送信対象の電子メールに関する操作入力が行われた場合に、前記クライアント端末装置から送信された当該電子メールに関する情報を受信する第１の受信手段と、
   前記情報に基づいて前記電子メールについて行われた操作のタイプを特定し、当該特定したタイプに応じて処理を行う第１の処理手段とを備え、
   前記第１の処理手段は、前記情報に基づいて、前記電子メールのデータの送信を制御することを特徴とする情報処理装置。
2. 前記情報の捕捉パターンを記憶する第１の捕捉パターン記憶手段と、
   前記捕捉パターンに対応した処理内容を記憶する第１の処理内容記憶手段とを備え、
   前記情報が前記捕捉パターンに合致する場合には、前記第１の処理手段は、前記第１の処理内容記憶手段に記憶された前記捕捉パターンに対応する処理を行うことを特徴とする請求項１に記載の情報処理装置。
3. 前記情報には送信先情報、送信元情報が含まれ、
   前記送信先情報及び／または送信元情報をキーにして検索可能に前記情報を記憶する電子メール情報記憶手段を更に備えることを特徴とする請求項１または２に記載の情報処理装置。
4. 前記情報処理装置は、更にクライアント端末装置と電子メールサーバの間のＳＭＴＰによる電子メールのデータ通信を中継し、
   前記クライアント端末装置から送信された当該ＳＭＴＰによる電子メールに関する情報を受信する第２の受信手段と、
   前記第２の受信手段で受信した前記情報の捕捉パターンを記憶する第２の捕捉パターン記憶手段と、
   前記第２の捕捉パターン記憶手段に記憶された捕捉パターンに対応した処理内容を記憶する第２の処理内容記憶手段と、
   前記情報が前記捕捉パターンに合致する場合に前記処理内容のうち、前記捕捉パターンに合致した処理を実行する第２の処理手段を更に備え、
   前記電子メール情報記憶手段は、前記ＳＭＴＰによる電子メールに関する情報を更に記憶することを特徴とする請求項３に記載の情報処理装置。
5. 更に、
   前記第１の捕捉パターン記憶手段に記載された捕捉パターンを編集する編集手段を備えることを特徴とする請求項２乃至４のいずれか１項に記載の情報処理装置。
6. ＨＴＴＰプロトコルを用いて電子メールの送受信を行うサービスを提供する為のホームページを提供するＨＴＴＰサーバと、当該ＨＴＴＰサーバにアクセスし、当該ホームページ上における操作が可能なクライアント端末装置と、の間のデータ通信を中継する情報処理装置の制御方法であって、
   前記クライアント端末装置側で前記ホームページを介して、送信対象の電子メールに関する操作入力が行われた場合に、前記クライアント端末装置から送信された当該電子メールに関する情報を受信する受信工程と、
   前記情報に基づいて前記電子メールについて行われた操作のタイプを特定し、当該特定したタイプに応じて処理を行う処理工程とを備え、
   前記処理工程では、前記情報に基づいて、前記電子メールのデータの送信を制御することを特徴とする情報処理装置の制御方法。
7. コンピュータに請求項６に記載の情報処理方法を実行させるためのプログラム。
8. 請求項７に記載のプログラムを格納したことを特徴とするコンピュータ読み取り可能な記憶媒体。

Images