| 【発明の名称】 |
電子メール送受信装置 |
| 【発明者】 |
【氏名】太田 薫 【住所又は居所】宮城県仙台市青葉区一番町3丁目3番5号 富士通東日本コミュニケーション・システムズ株式会社内
|
| 【要約】 |
【課題】本発明は電子メール送受信装置に関し、メール送受信機能を持つ任意のアプリケーションを改造することなく、任意のヘッダ規約でメール送受信機能を持つアプリケーションとメールの送受信を行なうことができる電子メール送受信装置を提供することを目的としている。
【解決手段】メール送受信機能を持つ任意のアプリケーションが発信するメールのヘッダ部を解析する送信メール解析部11と、その送信メールを相手のメール送受信装置のヘッダ規約に合わせて修正する送信メール作成部12と、受信したメールのヘッダ部を解析する受信メール解析部15と、その受信メールを当該アプリケーションが認識できるメールに修正する受信メール作成部16と、メールの送受信を制御するメール送受信部14と、を具備して構成される。 |
【特許請求の範囲】
【請求項1】 メール送受信機能を持つ任意のアプリケーションが発信するメールのヘッダ部を解析する送信メール解析部と、その送信メールを相手のメール送受信装置のヘッダ規約に合わせて修正する送信メール作成部と、受信したメールのヘッダ部を解析する受信メール解析部と、その受信メールを当該アプリケーションが認識できるメールに修正する受信メール作成部と、メールの送受信を制御するメール送受信部と、を具備して構成される電子メール送受信装置。 【請求項2】 受信したメールから相手アプリケーションのヘッダ規約を抽出し、相手アプリケーション情報を蓄積する相手アプリケーション情報設定部を具備することを特徴とする請求項1記載の電子メール送受信装置。 【請求項3】 前記送信メール作成部は、相手アプリケーション情報設定部を参照して、相手のメール規約が最新のものに対応していない場合、送信メールを旧規約のものに変換することを特徴とする請求項2記載の電子メール送受信装置。
|
【発明の詳細な説明】【0001】 【発明の属する技術分野】本発明は電子メール送受信装置に関する。近年、電子メールは人が情報を送る手段としてだけでなく、アプリケーションソフトウェアが情報を共有するための手段としても使用されるようになってきている。例えば、microsoftのOutlookにおいて、スケジュールをグループで共有するために電子メールの仕組みを利用している。本発明は、電子メールを利用した装置全般に関するものである。 【0002】 【従来の技術】電子メールの送受信のヘッダには、電子メールの規約で定められている標準部分と、アプリケーション側が自由に設定できる拡張部分がある。この拡張部分を大いに利用しているのが添付ファイルである。例えば、暗号化情報ファイル等は、利用者が明に添付する添付ファイルとは異なる扱いにしたいため、拡張部分に個別のヘッダを付与して送っている。 【0003】この規約を適用している電子メールソフトは、暗号化ファイルを受信してもそれを添付ファイルとして利用者に表示することはしない。この規約を適用していない電子メールソフトは、認識できない情報が付与されたとして受信を拒否したり、一般の添付ファイルとして利用者に表示したりしている。 【0004】この拡張部分は、自由といってもある程度規約化される仕組みとなっており、ベンダが考案した新しいサービスの普及具合や、ウイルス対策等の世の中の動きに応じて、それに対応した規約が追加、更新されている。 【0005】 【発明が解決しようとする課題】例えば、Aさんが暗号化ファイルに対応した規約に基づく電子メールソフトを用いてメールを発信し、Bさんはそれを暗号化ファイルに対応していない規約に基づく電子メールソフトで受信しようとしたものとする。先に述べたように、現在の技術では、Bさんはそのメールを受信できないか、添付ファイルの一つとしてその暗号化ファイルを受信してしまう。これを解決するためには、以下のように方法が考えられる。 ■Aさんが発信時に、暗号化ファイルに対応していない規約に基づく電子メールソフトを使用している人(ここではBさん)へは暗号化ファイルが添付されないようにする(つまり、発信者が相手のメールソフトの規約を意識する)。 ■Bさんが、暗号化ファイルに対応したバージョンにバージョンアップする。 ■Bさんが、暗号化ファイルに対応した電子メールソフトに乗り換える。 【0006】それぞれの対処方法には以下のような問題点がある。先ず、■に示す方法は、送る相手の電子メールソフトが何であるかを知っている必要があり、また、知っていても、その電子メールソフトがどういう規約に基づいているのかは、技術者レベルでなければ判断できない。■に示す方法は、対象の電子メールソフトが当該規約に対応したバージョンアップを行っていない場合には選択できない。■に示す方法は、使い慣れたGUI(画面)が変わってしまうのはもちろんのこと、旧電子メール環境を移行しなければならず、作業の手間がかかる他、ソフトの移行に伴い、アドレス帳や保存しているメールの消去等、誤操作の危険が伴う。 【0007】昨今、インターネットの急激な普及に伴い、市場では安全性を含め新サービスのために新たな規約が増えている。本発明はこのような課題に鑑みてなされたものであって、メール送受信機能を持つ任意のアプリケーションを改造することなく、任意のヘッダ規約でメール送受信機能を持つアプリケーションとメールの送受信を行なうことができる電子メール送受信装置を提供することを目的としている。 【0008】 【課題を解決するための手段】(1)図1は本発明の原理ブロック図である。図において、1は利用者、2は利用者1からの指令を受けて電子メールを動作させる電子メールアプリケーション、3はメールを送受信するメール送受信部で、電子メールアプリケーション2内に含まれている。10は本発明に係る電子メール送受信装置である。該電子メール送受信装置10において、11はメール送信機能を持つ任意のアプリケーション2が発信するメールのヘッダを解析する送信メール解析部、12は該送信メール解析部11の出力を受けて、その送信メールを相手のメール送受信装置のヘッダ規約に合わせて修正する送信メール作成部である。 【0009】13は送信相手先のアプリケーション情報が記憶される相手アプリケーション(以下単にアプリと略す)情報記憶部、14はメールの送受信を制御するメール送受信部である。前記送信メール作成部12の出力は、メール送受信部14に入力される。15はメール送受信部14からの信号を受けて受信したメールのヘッダ部を解析する受信メール解析部、16は該受信メール解析部15の出力を受けて、その受信メールを当該アプリケーション2が認識できるメールに修正する受信メール作成部である。該受信メール作成部16の出力は、メール送受信部3に入力される。また、電子メールアプリケーション2のメール送受信部3からは電子メール送受信装置10のメール送受信部14にコマンド等が送出される。 【0010】相手アプリ情報記憶部13の情報は送信メール解析部11により参照され、また受信メール解析部15は、受信メールの解析結果を相手アプリ情報記憶部13に与えると共に、相手アプリケーション情報を相手アプリ情報記憶部13より受ける。17はメール送信環境設定情報が記憶されるメール送信環境設定情報記憶部である。20は、電子メール送受信装置10と接続されるメールサーバである。 【0011】このように構成された装置において、電子メールアプリケーション2は、電子メール送受信装置10の存在を意識することなく、メールサーバ20との間でやりとりをしているように振る舞うことができる。 【0012】先ず、送信メール解析部11で電子メールアプリケーション2からメール送受信部3を利用して送信されたメールを解析する。ここで、主として解析するのは、メールのヘッダ部分である。送信メール解析部11は、送信メールのヘッダ部に記述されているメールの宛先を抽出し、相手アプリ情報記憶部13からメールの宛先に対応する送信メールの編集ルールを取得する。相手アプリ情報記憶部13には、メールを解析する時に利用する相手識別情報と編集ルールが関連付けされて格納されている。 【0013】相手アプリ情報の例を図2に示す。図2は、相手識別情報IDi(iは任意の整数で1〜nまで)とそれに対応した編集ルールiが記憶されていることを示す。 【0014】ここでいう編集ルールの例としては、例えば送信するメールにアプリケーション固有のデータが付加されていた場合、送信相手が利用するアプリケーションが該当のファイルを利用することができるかどうかの情報を相手アプリ情報記憶部13から取得し、利用できなければ送信メール作成部12で添付ファイル部分を削除したメールを作成する。 【0015】送信メール解析部11で解析した結果を送信メール作成部12に渡すと、送信メール作成部12は送信メール解析部11で解析した結果により、送信メールを作成する。作成したメールは、メール送受信部14からメールサーバ20へ送信される。この時、メールの送信環境は、メール送信環境設定情報記憶部17に設定された送信先メールサーバや、ポート番号を取得して利用する。 【0016】次に、利用者1が電子メールアプリケーション2を利用して電子メールを受信する場合、電子メールアプリケーション2を操作してメール送受信部3より発行されるメール受信コマンドが、電子メール送受信装置10のメール送受信部14に転送される。そして、コマンドを転送されたメール送受信部14は、メール送信環境設定情報記憶部17よりメールサーバ20のアドレスや、ポート番号等の接続環境を取得後、接続し、メールを受信する。受信したメールは、受信メール解析部15に渡されてヘッダの内容を解析する。受信メール解析部15は、メールのヘッダ部を解析する。 【0017】受信メール作成部16では、受信メール解析部15で解析した結果と、メール送受信部14で受信したメールが渡され、受信メール解析部15で解析した通りにメールを編集し、電子メールアプリケーション2へのメールとして作成する。作成したメールは、電子メールアプリケーション2のメール送受信部3を経由して電子メールアプリケーション2へ取り込まれる。 【0018】このように、この発明の構成によれば、メール送受信機能を持つ任意のアプリケーションを改造することなく、任意のヘッダ規約でメール送受信機能を持つ電子メールアプリケーション2とメールの送受信を行なうことができる。また、利用者が利用する電子メールアプリシーションに具備されていない機能があった場合で、その電子メールアプリシーションの改造や、該当機能が具備されている電子メールアプリシーションに置き換えることなく、拡張機能を利用することができる。 (2)請求項2記載の発明は、受信したメールから相手アプリケーションのヘッダ規約を抽出し、相手アプリケーション情報を蓄積する相手アプリケーション情報設定部を具備することを特徴とする。 【0019】このように構成すれば、相手アプリ情報記憶部13に、自動的に送受信相手のヘッダ規約を蓄積することが可能となり、記憶された編集ルールは、次回の送受信処理から利用することができる。また、相手アプリ情報を、受信したメールを解析し編集ルールを取得し、蓄積することで、編集ルールの設定の手間を省くことができる。 (3)請求項3記載の発明は、前記送信メール作成部は、相手アプリケーション情報設定部を参照して、相手のメール規約が最新のものに対応していない場合、送信メールを旧規約のものに変換することを特徴とする。 【0020】このように構成すれば、メール送信者とメール受信者との間で、メール受信者のもつ旧いバージョンのメールソフトで電子メールのやりとりを行なうことができる。 【0021】 【発明の実施の形態】以下、図面を参照して本発明の実施の形態例を詳細に説明する。図3は本発明の第1の実施の形態例を示すブロック図である。図1と同一のものは、同一の符号を付して示す。この実施の形態例は、図1に示す構成に比較して、受信メール解析部15と相手アプリ情報記憶部13との間に相手アプリ情報設定部18が設けられた点が異なっている。 【0022】利用者1が電子メールアプリケーション2を利用してメールを受信する場合について考える。上記した通り、メール送受信部14がメール送信環境設定情報記憶部17よりメール受信環境を取得してメールサーバ20と接続し、メールを受信する。受信したメールは、受信メール解析部15に渡されて、メールヘッダ部を解析する。 【0023】この解析の結果、編集ルールが相手アプリ情報記憶部13に格納されていない時、相手/識別情報と、編集ルールを相手アプリ情報設定部18を経由して相手アプリ情報記憶部13に記憶する。記憶された編集ルールは、次回のメールの送受信処理から利用することができる。 【0024】このように、本発明によれば、相手アプリ情報記憶部13に、自動的に送受信相手のヘッダ規約を蓄積することが可能となり、記憶された編集ルールは、次回の送受信処理から利用することができる。 【0025】図4は本発明の第2の実施の形態例を示すブロック図である。図1と同一のものは、同一の符号を付して示す。図において、2は電子メールアプリケーション、10は該電子メールアプリケーション2と接続される電子メール送受信装置、20はネットワーク25を介して電子メール送受信装置10と接続されるメールサーバである。 【0026】この実施の形態例では、同一コンピュータ30内に利用者が利用する電子メールアプリケーション2と、本発明である電子メール送受信装置10が存在している。ここでは、電子メール送受信装置10をコンピュータ30内に設けた例を示しているが、代わりにメールサーバ20内に設けることもできる。 【0027】コンピュータ30はネットワーク25上に存在し、ネットワーク25上には利用者がメール送受信の際利用するメールサーバ20が存在している。電子メール送受信装置10のメール送受信部14とメールサーバ20は、ネットワーク25を介して相互接続されている。ここでは、利用者が利用する電子メールアプリケーション2では、同じ本文のメールで、宛先毎に添付ファイルを付加/付加しないで送信する機能を有していないものとする。 【0028】そこで、本発明では、添付ファイルを宛先毎に付加/或いは付加しないで送信する場合を説明する。図5は本発明による送信処理動作を示すフローチャートである。先ず、電子メールアプリケーション2よりメールを送信する(S1)。次に、電子メール送受信装置10は、ユーザ利用アプリケーション2からメールを受信する(S2)。 【0029】次に、電子メール送受信装置10内の送信メール解析部11は、相手アプリ情報記憶部13を参照して、送信先アドレスより、送信ルールを取得し、メールヘッダを解析する(S3)。次に、送信メール作成部12は、送信メール解析部11の出力を受けて送信メールを編集する(S4)。この場合において、相手アプリ情報から取得した編集ルールにより送信メールを編集する。 【0030】次に、ルールにより編集の必要があるか否かをチェックする(S5)。編集の必要がない場合には、電子メール送受信装置10からオリジナルのメールを送信する(S8)。ステップS5において、編集が必要な場合、送信メール作成部12は送信メールを編集する(S6)。そして、編集したメールをメールをメールサーバ20に送信する(S7)。その後、オリジナルのメールを送信する(S8)。 【0031】利用者が、電子メールアプリケーション2を利用して任意のファイルを添付して電子メールを送信する時、普段利用している電子メールアプリケーション2よりメール本文を編集した後、添付したいファイルを指定してメールを送信する。通常では、宛先に指定した全てのアドレスに対してファイルが添付されて送信されるが、本発明を利用して任意の宛先にのみファイルを添付して送信する場合、電子メールアプリケーション2で宛先を指定する時に拡張ヘッダを利用する。 【0032】添付ファイルを付加せずに、メール本文のみ送信したい宛先については、拡張ヘッダとして“X−Attach−To”を付加してメールを送信する。この“X−Attach−To”というヘッダが付された場合には、添付ファイルは付加されない。 【0033】図6は拡張ヘッダ利用の送信先指定の説明図である。図において、40は標準ヘッダ、41は“X−Attach−To”がついた拡張ヘッダ、42はマルチパートヘッダである。マルチパートヘッダ42は、あるパートがどのようなものであるかを示すために用いられる。マルチパートヘッダ42の後に本文(図示せず)がくる。 【0034】電子メールアプリケーション2は、メールサーバ20ではなく、電子メール送受信装置10に対して接続を行ない、作成した電子メールを送信する。その電子メールを受信した電子メール送受信装置10は、送信メール解析部11で図6に示すようなメールのヘッダ部を解析し、拡張ヘッダである“X−Attach−To”を取得する。 【0035】送信メール解析部11では、相手アプリ情報記憶部13より“X−Attach−To”をキーに編集ルールを取得する。図7は相手アプリケーション情報記憶部13の実装例の説明図である。相手アプリ情報は、相手/識別情報とルールより構成されている。相手/識別情報はヘッダと値より構成されている。例えば、“X−Attach−To”のヘッダがある場合、その値は任意の値をとることができ(図中*で示す)、その場合のルールは、添付ファイル部を削除して宛先をToにするというものである。 【0036】この場合において、送信処理の場合には、送信メールのヘッダに記述されているヘッダと、その値よりルールを取得する。そして、取得したルールにより、送信メールを編集し、メールサーバに送信する。 【0037】一方、受信処理の場合には、受信したメールのヘッダに記述されているヘッダとその値よりルールを取得する。そして、取得したルールにより受信メールを編集し、ユーザが利用するアプリケーションにレスポンスとして返す。 【0038】この結果、メール解析部11では“X−Attach−To”の編集ルールである“添付ファイル部を削除し宛先をtoにする”というルールを取得する。取得したルールは送信メール作成部12に渡される。 【0039】送信メール作成部12では、送信メール解析部11より渡された編集ルール通りに送信メールを編集する。この実施の形態例の場合、添付ファイルを付加したメールの他に、添付ファイルを削除したメールを作成する。添付ファイルを削除したメールは、拡張ヘッダ“X−Attach−To”に指定された宛先(図6に示す例の場合ではsomeone@domain.com)に送信するためのものである。 【0040】編集ルールでは、“X−Attach−To”で示したアドレスに対しては添付ファイルを削除した後、宛先をToに変換することになっているので、図6で示されたメールのヘッダは図8に示すように変換される。図8は拡張ヘッダを標準ヘッダに変換する場合の説明図である。図において、43が標準ヘッダ、42がマルチパートヘッダである。図6において示されている“X−Attach−To”:someone<someone@domain.com>が、通常の標準ヘッダであるTo:<someone@domain.com>に変換されていることが分かる。 【0041】このように、本発明によれば、メール送受信機能を持つ任意のアプリケーションを改造することなく、任意のヘッダ規約でメール送受信機能を持つ電子メールアプリケーション2とメールの送受信を行なうことができる。 【0042】図9は本発明による受信処理動作を示すフローチャートである。先ず、ユーザ利用アプリケーション2を電子メール送受信装置10に接続する(S1)。次に、メールサーバ20からメールを1通受信する(S2)。受信されたメールは、メール送受信部14を介して受信メール解析部15に渡される。該受信メール解析部15は、相手アプリ情報記憶部13を参照して受信メールの編集ルールを取得し、受信メール1通分を解析する(S3)。次に、電子メール送受信装置10は、相手のアプリ情報記憶部13の情報を更新する必要があるか否かをチェックする(S4)。 【0043】相手アプリ情報を更新する必要がある場合、受信メール解析部15は相手アプリ情報記憶部13にアクセスして相手識別情報とルールを更新する(S5)。この結果、相手アプリ情報記憶部13の内容は更新される。ステップS4において、相手アプリ情報記憶部13の内容を記憶する必要がなかった場合、受信メール解析部15は、ルールにより編集が必要であるか否かをチェックする(S6)。 【0044】編集が必要である場合、受信メール作成部16は受信メールを編集する(S7)。編集が必要でない場合、電子メール送受信装置10は解析が完了したかどうかチェックする(S8)。解析が終了していない場合には、ステップS3に戻る。解析が完了している場合、及びステップS7で受信メール編集が終了した場合には、電子メール送受信装置10は、ユーザ利用アプリケーション2へメールを送信する(S9)。 【0045】上述した受信処理の場合では、受信したメールに添付されていた添付ファイルは、利用者が利用する電子メールアプリケーション2では、扱うことのできないアプリケーション固有のファイルであったものとする。 【0046】利用者が電子メールアプリケーション2を利用してメールの受信操作を行った時、メール受信コマンドは、本発明の受信メール作成部16、受信メール解析部15を経由してメール送受信部14に渡される。メール送受信部14は、ネットワーク25上に存在するメールサーバ20に対してメール受信コマンドを投入すると、メールを受信することができる。 【0047】なお、メール送受信部14は、接続先メールサーバのアドレスやポート番号等の接続環境を予め用意されているメール送信環境設定情報記憶部17から取得する。受信したメールは、受信メール解析部15に渡され、メールの内容を解析する。受信したメールの例を図10に示す。この図は、特定のアプリケーション同士でないと利用できないファイルが添付されているメールの例を示している。 【0048】このメールは、ヘッダのContent−Typeの値がapplication/x−approgfileとなっている。受信メール解析部15は、この値をキーに相手アプリ情報記憶部13より編集条件を取得する。この場合、添付ファイルを削除するルールを取得することができる。編集ルールを取得した後、受信メール作成部16に編集ルールを渡すと、受信メール作成部16は、そのルールの通り受信したメールを編集する。 【0049】図10に示すファイルを編集した結果は、図11に示すようになる。アプリケーション固有の添付ファイルが削除され、メールのヘッダ部も修正が行なわれ、電子メールアプリケーション2で受信しても通常表示できるようになっている。編集ルールによる電子メールの編集後は、ユーザが利用する電子メールアプリケーション2にメール受信コマンドのレスポンスとして返される。 【0050】上記受信処理の中で、相手アプリ情報記憶部13より編集条件を取得する処理がある。受信したメールを解析した結果、編集条件として相手アプリ情報記憶部13に追加する必要があった場合、その条件を相手アプリ情報記憶部13に追加することができる。例として、受信したメールの差出人が利用する電子メールアプリケーション2が最新規約での添付ファイルを付加してきた場合を想定する。最新規約の電子メールにおける添付ファイル付加は、図12に示すようになっている。図12は、最新規約での添付ファイル付加を示す図である。図12は、添付ファイル部分があることを示している。図のライン50は添付ファイル名である。 【0051】このようなメールに対して、受信メール作成処理では、図13に示すように、新規約に対応していない電子メールアプリケーションでも添付ファイル名を解釈できるような形式に変換する(図12の添付ファイル名50は、図13では添付ファイル名51に変わっている)が、相手アプリケーション情報(図7参照)にメールの差出人に対しては新規約に変換して送信しなければならないというルールを追加する。新ルールが追加された相手アプリ情報の構成を図14に示す。以後、新規約に対応したメールを利用する相手にファイルを添付してメールを送信する場合、新規約でのメール送信を行なうようになる。 【0052】以上、説明したように、この実施の形態例によれば、相手アプリ情報記憶部13に、自動的に送受信相手のヘッダ規約を蓄積することが可能となり、記憶された編集ルールは、次回の送受信処理から利用することができる。 【0053】なお、本発明によれば、前記送信メール作成部11は、相手アプリケーション情報設定部を参照して、相手のメール規約が最新のものに対応していない場合、送信メールを旧規約のものに変換することができる。 【0054】このように構成すれば、メール送信者とメール受信者との間で、メール受信者のもつ旧いバージョンのメールソフトで電子メールのやりとりを行なうことができる。 【0055】 【発明の効果】以上説明したように、本発明によれば以下の効果が得られる。 (1)請求項1記載の発明によれば、メール送受信機能を持つ任意のアプリケーションを改造することなく、任意のヘッダ規約でメール送受信機能を持つ電子メールアプリケーション2とメールの送受信を行なうことができる。 (2)請求項2記載の発明によれば、相手アプリ情報記憶部13に、自動的に送受信相手のヘッダ規約を蓄積することが可能となり、記憶された編集ルールは、次回の送受信処理から利用することができる。 (3)請求項3記載の発明によれば、メール送信者とメール受信者との間で、メール受信者のもつ旧いバージョンのメールソフトで電子メールのやりとりを行なうことができる。 【0056】このように、本発明によれば、メール送受信機能を持つ任意のアプリケーションを改造することなく、任意のヘッダ規約でメール送受信機能を持つアプリケーションとメールの送受信を行なうことができる電子メール送受信装置を提供することができる。
|
| 【出願人】 |
【識別番号】000005223 【氏名又は名称】富士通株式会社 【住所又は居所】神奈川県川崎市中原区上小田中4丁目1番1号
|
| 【出願日】 |
平成14年3月14日(2002.3.14) |
| 【代理人】 |
【識別番号】100085187 【弁理士】 【氏名又は名称】井島 藤治 (外1名)
|
| 【公開番号】 |
特開2003−271523(P2003−271523A) |
| 【公開日】 |
平成15年9月26日(2003.9.26) |
| 【出願番号】 |
特願2002−69499(P2002−69499) |
|