(57)【要約】【課題】従来よりもメールサーバの使用効率化の向上およびネットワークの通信トラフィックの抑制を図ることができるメール通信システムを提供すること。【解決手段】メールサーバは、電子メールを利用者Ａ宛に送信する場合に、過去に受信したメールのうち、利用者Ａが送信元になっているメールの添付ファイルを検索し（Ｓ１４）、添付ファイルが検索されると、これから送信しようとする電子メールの添付ファイルの中に、検索されたファイルと同一のものがあるか否かを判断する（Ｓ１６）。同一のものがあると判断すると、送信しようとする電子メールから、同一と判断された添付ファイルを削除した後（Ｓ１７）、利用者Ａ宛てに送信する（Ｓ１９）。【選択図】図５
2007213338.tif 000002
【特許請求の範囲】
【請求項１】
添付ファイル付きの電子メールを送受信する機能を有するメールサーバであって、
送信しようとする第１の電子メールと、過去の電子メールのうち送信元が第１の電子メールの宛先と一致する第２の電子メールについて、第１の電子メールの添付ファイルの中に第２の電子メールの添付ファイルと同一のものがあるか否かを判断する判断手段と、
同一と判断された添付ファイルがある場合には、第１の電子メールから当該同一と判断された添付ファイルを削除して送信するメール送信手段と、
を備えることを特徴とするメールサーバ。
【請求項２】
過去の電子メールの送信元を含む履歴情報を記憶している履歴情報記憶手段を有し、
前記判断手段は、前記履歴情報から過去の電子メールの送信元を取得することを特徴とする請求項１に記載のメールサーバ。
【請求項３】
受信した電子メールには、当該電子メールのオリジナルとなる過去の電子メールの送信元を含む履歴情報が書き込まれており、
前記判断手段は、前記履歴情報から、過去の電子メールの送信元を取得することを特徴とする請求項１に記載のメールサーバ。
【請求項４】
前記判断手段は、
添付ファイルの内容に関する情報として、添付ファイルのファイル名、拡張子、実データ、ファイル属性、ハッシュ値のいずれか１つ、または２以上を組み合わせた情報から前記判断を行うことを特徴とする請求項１乃至３のいずれか１項に記載のメールサーバ。
【請求項５】
過去の電子メールについて、前記添付ファイルの内容に関する情報を記憶しているファイル情報記憶手段を備え、
前記判断手段は、
過去の電子メールについては前記添付ファイルの内容に関する情報を前記ファイル情報記憶手段から取得し、第１の電子メールについては当該電子メールから取得し、取得した双方の情報を比較することにより前記判断を行うことを特徴とする請求項４に記載のメールサーバ。
【請求項６】
前記メール送信手段は、
第１の電子メールの宛先に、過去の電子メールの送信元と一致しない別の宛先が含まれている場合には、当該別の宛先に送信する電子メールについて添付ファイルの削除を行わないことを特徴とする請求項１乃至５のいずれか１項に記載のメールサーバ。
【請求項７】
前記メール送信手段は、
前記削除に代えて添付ファイルを圧縮した後に前記電子メールを送信することを特徴とする請求項１乃至６のいずれか１項に記載のメールサーバ。
【請求項８】
前記メール送信手段は、添付ファイルの圧縮に際し、その圧縮方法を当該添付ファイルの種類に応じて変えることを特徴とする請求項７に記載のメールサーバ。
【請求項９】
前記メール送信手段は、
添付ファイルの圧縮に際し、その圧縮率を当該添付ファイルの前記宛先への送信済み回数に応じて変えることを特徴とする請求項７または８に記載のメールサーバ。
【請求項１０】
添付ファイル付きの電子メールを送受信する機能を有するメールサーバを介して端末装置間で電子メールを通信する電子メール通信システムであって、
前記メールサーバは、
送信しようとする第１の電子メールと、過去の電子メールのうち送信元が第１の電子メールの宛先と一致する第２の電子メールについて、第１の電子メールの添付ファイルの中に第２の電子メールの添付ファイルと同一のものがあるか否かを判断する判断手段と、
同一と判断された添付ファイルがある場合には、第１の電子メールから当該同一と判断された添付ファイルを削除して送信するメール送信手段と、
を備えることを特徴とする電子メール通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メールサーバを介して第１と第２の端末装置間で電子メールを送受信する電子メール通信システムおよびメールサーバに関する。
【背景技術】
【０００２】
電子メール通信システムでは、メールサーバは、受信した電子メール（以下、「メール」という。）を記憶部に一旦格納しておき、ユーザが利用する端末装置から当該ユーザ宛てのメールの受信要求があると、要求されたメールを読み出して当該端末装置に送る構成になっている。このような構成をとる場合、メールの通信量が増加すると、メールサーバに格納しておくメールの量も増えるため、メールサーバの記憶容量を予め大きくしておくことが必要である。
【０００３】
ところが、メールサーバの記憶容量を無限に大きくすることは不可能であり、実際には限られた容量の中で効率良く使用することが求められる。
メールサーバを効率良く使用する技術として、特許文献１には、格納されている２つのメールについて、送信元、宛先および件名を比較し、これらが一致した場合に、通信日時が古い方のメールを削除する技術が開示されている。これによれば、例えばユーザＡがユーザＢに対し、誤った内容のメールを送信し、その直後に内容を訂正したメールを送信した場合に、メールサーバには２つのメールが一時的に格納されるが、古い内容のメールについては不要なものとして削除されることになる。従って、メールサーバに不要なメールが長時間格納されることを防止でき、また通信トラフィックの抑制を図ることができる。
【特許文献１】特開２００３−８５１０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献１の技術では、同一宛先のメールについて古いものを削除できるだけであり、次のような場合には通信トラフィックの抑制等を図ることはできない。すなわち、例えばユーザＢがユーザＡからのメールに添付されていたファイルを、いわゆる転送機能を利用して、ユーザＡを含む複数のユーザを宛先に指定して１回のメールで転送するという操作を行うような場合である。当該ファイルは、Ａ以外のユーザにとっては初めて受け取るものかも知れないが、ユーザＡにとっては、自己がもともと所有していたものであるから受け取っても見る必要がなく、結果的に無用なファイルがメールサーバを介して送信されることになる。
【０００５】
添付ファイルは、文書作成用アプリケーションにより作成された文書データや画像データなどからなるものが多く、メッセージ本体よりも一般的にデータサイズが大きい。
このようなデータサイズが大きい無用な添付ファイルが通信されることは、メールサーバにとって使用効率化の低下につながり、ネットワークにとって通信トラフィックの増大につながることになる。
【０００６】
本発明は、上記の問題点に鑑みてなされたものであって、従来よりもメールサーバの使用効率化の向上およびネットワークの通信トラフィックの抑制を図ることができる電子メール通信システムおよびメールサーバを提供することを目的としている。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明に係るメールサーバは、添付ファイル付きの電子メールを送受信する機能を有するメールサーバであって、送信しようとする第１の電子メールと、過去の電子メールのうち送信元が第１の電子メールの宛先と一致する第２の電子メールについて、第１の電子メールの添付ファイルの中に第２の電子メールの添付ファイルと同一のものがあるか否かを判断する判断手段と、同一と判断された添付ファイルがある場合には、第１の電子メールから当該同一と判断された添付ファイルを削除して送信するメール送信手段と、を備えることを特徴とする。
【発明の効果】
【０００８】
このように、宛先によっては不要と思われる添付ファイルを削除してから送信するので、添付ファイルを一律に送信する従来の構成に比べて、メールサーバの使用効率化の向上とネットワークの通信トラフィックの抑制を図ることができる。
また、過去の電子メールの送信元を含む履歴情報を記憶している履歴情報記憶手段を有し、前記判断手段は、前記履歴情報から過去の電子メールの送信元を取得することを特徴とする。
【０００９】
このようにすれば、容易に過去の電子メールの送信元を取得することが可能になる。
また、受信した電子メールには、当該電子メールのオリジナルとなる過去の電子メールの送信元を含む履歴情報が書き込まれており、前記判断手段は、前記履歴情報から、過去の電子メールの送信元を取得することを特徴とする。
このようにすれば、過去の電子メールの送信元を記憶しておく記憶手段を装置に備えない構成をとることが可能になる。
【００１０】
さらに、前記判断手段は、添付ファイルの内容に関する情報として、添付ファイルのファイル名、拡張子、実データ、ファイル属性、ハッシュ値のいずれか１つ、または２以上を組み合わせた情報から前記判断を行うとすることができる。
ここで、過去の電子メールについて、前記添付ファイルの内容に関する情報を記憶しているファイル情報記憶手段を備え、前記判断手段は、過去の電子メールについては前記添付ファイルの内容に関する情報を前記ファイル情報記憶手段から取得し、第１の電子メールについては当該電子メールから取得し、取得した双方の情報を比較することにより前記判断を行うことを特徴とする。
【００１１】
このようにすれば、過去の電子メールについて添付ファイルの内容に関する情報を容易に取得することができる。
また、前記メール送信手段は、第１の電子メールの宛先に、過去の電子メールの送信元と一致しない別の宛先が含まれている場合には、当該別の宛先に送信する電子メールについて添付ファイルの削除を行わないことを特徴とする。
【００１２】
当該別の宛先には当該添付ファイルが過去に送信されていない蓋然性が高く、当該別の宛先のユーザにとって便利である。
さらに、前記メール送信手段は、前記削除に代えて添付ファイルを圧縮した後に前記電子メールを送信することを特徴とする。
このようにすれば、第１の電子メールの宛先となるユーザは解凍により添付ファイルを見ることができるので、通信トラフィックの抑制を図りつつ、当該ユーザにとって便利になる。
【００１３】
また、前記メール送信手段は、添付ファイルの圧縮に際し、その圧縮方法を当該添付ファイルの種類に応じて変えることを特徴とする。
ここで、圧縮方法を当該添付ファイルの種類に応じて変えるとは、当該種類毎に別の圧縮方法を用いる場合と、ある種類については圧縮自体を行わない場合の両方を含む概念で用いられる。
【００１４】
このようにすれば、ファイル毎に適正な圧縮を行うことが可能になる。
さらに、前記メール送信手段は、添付ファイルの圧縮に際し、その圧縮率を当該添付ファイルの前記宛先への送信済み回数に応じて変えることを特徴とする。
通常、ユーザは同じファイルであれば１回受信すれば十分なので、例えば送信済み回数が多くなると圧縮率を大きくするとすることにより、当該ユーザに不便をかけることなくより通信トラフィックの抑制を図ることが可能になる。
【００１５】
本発明に係る電子メール通信システムは、添付ファイル付きの電子メールを送受信する機能を有するメールサーバを介して端末装置間で電子メールを通信する電子メール通信システムであって、前記メールサーバは、送信しようとする第１の電子メールと、過去の電子メールのうち送信元が第１の電子メールの宛先と一致する第２の電子メールについて、第１の電子メールの添付ファイルの中に第２の電子メールの添付ファイルと同一のものがあるか否かを判断する判断手段と、同一と判断された添付ファイルがある場合には、第１の電子メールから当該同一と判断された添付ファイルを削除して送信するメール送信手段と、を備えることを特徴とする。
【発明を実施するための最良の形態】
【００１６】
以下、本発明に係る電子メール通信システムおよびメールサーバの実施の形態を、図面を参照しながら説明する。
（第１の実施の形態）
図１は、電子メール通信システム１０の構成を示す図である。
同図に示すように、電子メール通信システム１０は、ネットワークシステム１，２，３が通信網、ここではインターネット４００を介して接続されてなる。
【００１７】
ネットワークシステム１は、端末装置１０１，１０２，１０３、メールサーバ１１０、ハブ１１１、ルーター１１２がＬＡＮ（Local Area Network）１２０を介して接続されてなる。また、ネットワークシステム２は、端末装置２０１，２０２，２０３、メールサーバ２１０、ハブ２１１、ルーター２１２がＬＡＮ２２０を介して接続されてなり、ネットワークシステム３は、端末装置３０１，３０２、メールサーバ３１０がＬＡＮ３２０を介して接続されてなる。
【００１８】
端末装置１０１、２０１等は、パーソナルコンピュータ（ＰＣ）であり、文書や図形等の作成のためのアプリケーションソフトウエア（以下、「アプリケーション」という。）がインストールされており、ユーザは当該アプリケーションにより文書や図形等のファイルを作成することができる。また、メール送受信のための通信ソフトウェア、いわゆるメーラーがインストールされており、ユーザは当該メーラーによりメールの作成や送信、受信、転送、返信等を行うことができる。さらに、アプリケーションにより作成した文書等のファイルを添付ファイルとしてメールに添付して送信する機能も有している。ここでは、利用者Ｘが端末装置１０１を、利用者Ｙが端末装置２０１を、利用者Ｚが端末装置３０１を、利用者αが端末装置３０２をそれぞれ使用するものとする。
【００１９】
メールサーバ１１０，２１０等は、端末装置間でメールを送受信するための中継装置として機能する。ここでは、メール送受信に公知のSMTP(Simple Mail Transfer Protocol)およびPOP3(Post Office Protocol 3)が用いられる。なお、ハブ１１１，２１１とルーター１１２，２１２については、公知の中継装置であるので、ここでの説明を省略する。
以下、メールサーバの処理を詳しく説明するが、各メールサーバは基本的に同じ構成なので、ここではメールサーバ２１０について説明し、他のサーバについてはその説明を省略するものとする。
【００２０】
図２は、メールサーバ２１０の構成を示すブロック図である。
同図に示すように、メールサーバ２１０は、主な構成要素として、送受信部２５１、全体制御部２５２、記憶部２５３、メール検索部２５４、添付ファイル同一性判断部２５５、添付ファイル削除部２５６および送信メール格納部２５７を備え、バス２５８を介して各部間で通信が行えるようになっている。
【００２１】
送受信部２５１は、ＬＡＮカード、ＬＡＮボードといったＬＡＮ２２０に接続するためのインターフェースである。
記憶部２５３は、ＨＤＤ（ハードディスクドライブ）などの不揮発性の記憶手段からなり、各利用者宛てに届いたメール（以下、「受信メール」という。）を格納しておくためのアドレス単位で割り当てられたメールボックス（ＢＯＸ）２６１、２６２等が設けられている。
【００２２】
全体制御部２５２は、各部を制御し、メールサーバとしてのメール送受信等の機能を円滑に実行させる。具体的には、メール受信の場合、受信メールを、送受信部２５１を介して受信して、利用者用のメールボックス、例えば宛先が利用者Ｙの場合にはメールボックス２６１に格納させる。利用者Ｙが使用する端末装置、ここでは２０１からＹ宛てのメールの受信要求があると、メールボックス２６１から当該受信メールを読み出して端末装置２０１に送る。
【００２３】
また、メール送信の場合、端末装置２０１等から送信されたメール（以下、「送信メール」という。）を、送受信部２５１を介して受け付けて、送信メール格納部２５７に一旦格納させる。そして、当該送信メールを送信メール格納部２５７から読み出し、指定された宛先に送受信部２５１を介して送信する。
メール検索部２５４は、これから送信しようとする送信メールの宛先と同じアドレスが送信元になっている過去の受信メールを検索する。
【００２４】
添付ファイル同一性判断部２５５は、これから送信しようとする送信メールの添付ファイルと、メール検索部２５４の検索により得られた過去の受信メールの添付ファイルについて、その同一性を判断する。この判断方法およびメール検索部２５４の検索方法の詳細については、後述する。
添付ファイル削除部２５６は、添付ファイル同一性判断部２５５により同一と判断された添付ファイルを送信メールから削除する処理を行う。
【００２５】
次に、メールサーバ２１０が送信メールを受け付けたときに実行する処理内容を説明するが、ここでは利用者ＸからＹ宛に添付ファイル付きのメールＡが送信された後、Ｙがメーラーのいわゆる転送機能を利用して添付ファイル付きのメールＢを送信メールとして利用者Ｘ、Ｚ宛に送信する場合に、メールサーバ２１０が実行する処理の内容例を具体的に説明する。
【００２６】
図３は、メールＡの構成例１３０を示す図である。また、図４（ａ）は、メールＢが端末装置２０１からメールサーバ２１０に送られるときの構成例２３０を示す図であり、図４（ｂ）は、メールＢがメールサーバ２１０から利用者Ｘ宛に送信されるときの構成例２４０を示す図である。
図３に示すように、メールＡには、Ｔｏ欄１３１、ＣＣ欄１３２、Ｆｒｏｍ欄１３３、Ｓｕｂｊｅｃｔ欄１３４、Ｄａｔｅ欄１３５、添付ファイル情報欄１３６、Ｏｒｉｇｉｎａｌ  Ｍａｉｌ（オリジナルメール）情報欄１３７およびメッセージ欄１３８が設けられている。なお、メールＡには、添付ファイル１３９が添付されており、ここではメッセージ欄１３８の下に書き込まれている。
【００２７】
Ｔｏ欄１３１には、メールＡの宛先、ＣＣ欄１３２には、メールＡと同じ内容のメール（コピー）を送信する場合の宛先、Ｆｒｏｍ欄１３３には、送信元のアドレスがそれぞれ書き込まれる。同図は、Ｔｏ欄１３１に利用者Ｙ、Ｆｒｏｍ欄１３３に利用者Ｘのアドレスが書き込まれている場合の例を示している。
Ｓｕｂｊｅｃｔ欄１３４には、メールＡの件名を示す情報が、Ｄａｔｅ欄１３５には、作成日時を示す情報が、添付ファイル情報欄１３６には、添付ファイルのファイル名とその拡張子を示す添付ファイル情報が書き込まれている。ここでは、添付ファイルとして、拡張子「ｂｍｐ」のファイル名「サンプル画像１」というファイルがメールＡに添付されていることが解る。
【００２８】
オリジナルメール情報欄１３７には、いわゆる転送や返信機能を利用する際のオリジナルとなるオリジナルメールについてその宛先や送信元、添付ファイルのファイル名、拡張子などの情報（図４（ａ）の欄２３７参照）がオリジナルメール情報として書き込まれる。メールＡには、オリジナルメールとされるメールがないので空白になっている。
メッセージ欄１３８には、利用者Ｘにより入力されたメッセージが書き込まれる。
【００２９】
一方、図４（ａ）に示すように、端末装置２０１からメールサーバ２１０に送られるメールＢには、Ｔｏ欄２３１〜メッセージ欄２３８が設けられている。Ｓｕｂｊｅｃｔ欄２３４、Ｄａｔｅ欄２３５を含めて各欄の内容は、基本的にメールＡのものと同じであるが、Ｔｏ欄２３１には、利用者Ｘ、ＣＣ欄２３２には、利用者Ｚ、Ｆｒｏｍ欄２３３には、利用者Ｙのアドレスが書き込まれている。なお、メールＢにも添付ファイルが添付されており、メッセージ欄２３８の下に、その添付ファイル２３９が書き込まれている。
【００３０】
添付ファイル情報欄２３６には、メールＢの添付ファイルについて、その添付ファイル情報が書き込まれている。同図は、メールＡの添付ファイルと同じ情報になっている例を示している。オリジナルメール情報欄２３７には、メールＡについてその送信元等のオリジナルメール情報が書き込まれている。メールＡは、端末装置１０１のメーラーにより、メールＢは、端末装置２０１のメーラーによりそれぞれ作成され、各装置から送信される。なお、図４（ｂ）のメール構成例２４０については後述する。
【００３１】
図５は、端末装置２０１からメールＢを受け付けたときにメールサーバ２１０が実行する処理内容の例を示すフローチャートである。
同図に示すように、送信メールとしてメールＢを受け付けると（ステップＳ１１）、変数ｉの値を「１」に設定する（ステップＳ１２）。そして、メールＢの全宛先のうち、ｉ番目の宛先を確認する（ステップＳ１３）。ここで、ｉ番目とは、メールＢのＴｏ欄とＣＣ欄に書き込まれている各宛先を上から１番目、２番目というように順番付けしたときの番号のことをいう。ｉ＝１の場合には、ｉ番目の宛先は利用者Ｘということになる。
【００３２】
次に、記憶部２５３のメールボックスに格納されている過去の全受信メールのうち、送信元がｉ番目の宛先（利用者Ｘ）と一致する受信メールの添付ファイルを検索する（ステップＳ１４）。送信元については、過去の受信メールのＦｒｏｍ欄に書き込まれている情報が履歴情報として参照される。ここでは図３に示すようにメールＡの送信元が利用者Ｘになっており、従ってメールＡの添付ファイル（ファイル名「サンプル画像１．ｂｍｐ」）が検索されるものとする。この検索は、主にメール検索部２５４により実行される。
【００３３】
ファイル検索の有無を判断する（ステップＳ１５）。添付ファイルが検索されたことを判断すると（ステップＳ１５で「ＹＥＳ」）、メールＢの添付ファイルの中に、検索された添付ファイルと同一のものがあるか否かを判断する（ステップＳ１６）。
具体的には、メールＢの添付ファイル（ファイル名「サンプル画像１．ｂｍｐ」）と、検索された添付ファイル（ファイル名「サンプル画像１．ｂｍｐ」）双方について、その本文内容を読み出し、両者の内容を比較して、内容が一致していれば同一、異なっていれば同一でないと判断される。ここでは、メールＢの添付ファイルが１つの場合を例にしたが、複数ある場合には、個々のファイル毎に同一性が判断される。
【００３４】
なお、同一性の判断方法は、これに限られない。例えば、添付ファイルの内容に関する情報として、ファイル名、属性情報、作成日時等のいずれか、または２以上を組み合わせて、ファイル名等の比較結果から判断するとしても良い。当該情報がメールに含まれていれば実現できる。この判断は、主に添付ファイル同一性判断部２５５により実行される。
また、過去の受信メールを記憶しておく構成になっていない場合には、例えばメールを受信する毎に、当該受信メールから当該情報を読み出し、その情報を記憶部のテーブル等に登録しておき、同一性の判断の際に当該テーブルを参照する構成をとるとしても良い。さらに、添付ファイルの内容に関する情報としては，例えば添付ファイルのデータのハッシュ値とすることもできる。この場合も、例えばメールの受信毎にその添付ファイルについてハッシュ値を計算し、得られたハッシュ値を登録する方法をとるとしても良い。
【００３５】
添付ファイルが同じであることを判断すると（ステップＳ１６で「ＹＥＳ」）、宛先をｉ番目とする（利用者Ｘ宛の）メールＢから、同じと判断された添付ファイル、ここでは「サンプル画像１．ｂｍｐ」の添付ファイルを削除する処理を行う（ステップＳ１７）。具体的には、送信メール格納部２５７に格納されているメールＢを読み出すと共に添付ファイル２３９に相当する部分のデータを削除して、これを利用者Ｘ宛のメールＢとするものである。
【００３６】
そして、添付ファイルが削除された旨の情報（削除情報）を当該メールＢに書き込む（ステップＳ１８）。図４（ｂ）は、添付ファイルが削除され、削除情報が書き込まれたメールＢの構成例２４０を示す図である。なお、同図では、図４（ａ）の構成例２３０と同じ部分について省略してある。
図４（ｂ）に示すように、当該メールＢの添付ファイル欄２３６には、ファイル名「サンプル画像１」のファイルが削除されたこと、および削除されたファイルがどのメールに添付されているのかを知らせるメッセージが削除情報として書き込まれるようになっている。この削除情報は、ファイル名や日時、宛先に相当する部分を除いたメッセージに、当該削除されるファイルに対応するファイル名等を示す情報が追記されることにより生成される。また、同図に示すように、上記の削除により、メッセージ欄２３８の下部には、添付ファイルに相当する部分が存在していないことが解る。
【００３７】
利用者Ｘは、当該メールＢを受信し、添付ファイル欄２３６を見れば、どの添付ファイルが削除され、削除されたファイルがどのメールに添付されていたものと同じであるかを知ることができる。なお、削除情報は、同図のものに限られず、削除された旨が示されるものであれば良い。この削除等は、主に添付ファイル削除部２５６において実行される。
図５に戻り、ステップＳ１９では、ｉ番目の宛先（利用者Ｘ宛）のメールＢを送信して、ステップＳ２０に移る。
【００３８】
ステップＳ２０では、全ての宛先への送信が終了したか否かを判断する。ここでは、まだ終了していないと判断し、現在の変数ｉの値に「１」をインクリメントして（ステップＳ２１）、ステップＳ１３に戻る。ここではｉ＝２となる。
ステップＳ１３〜Ｓ１５では、２番目の宛先（利用者Ｚ）について、上記同様の方法により検索等を実行する。ここでは、過去の受信メールが検索されなかったとする。過去の受信メールがないことを判断すると（ステップＳ１５で「ＮＯ」）、ステップＳ１９に移り、添付ファイル付きのメールＢを送信メール格納部２５７から読み出して利用者Ｚ宛に送信する。過去の受信メールがないということは、利用者ＺがメールＢの添付ファイルを所有していない可能性があるので、削除せずに送信するものである。これより、利用者Ｚは、受信したメールＢから添付ファイルを確認することができる。
【００３９】
ステップＳ１９で全宛先について送信が終了したことを判断すると当該処理を終了する。なお、ステップＳ１６で添付ファイルが同じでないことを判断した場合には、ステップＳ１９に移り、添付ファイルを削除することなく指定の宛先にメールＢを送信する。
このようにメールサーバ２１０は、送信メールの添付ファイルを必要に応じて削除してから送信するので、添付ファイルを一律に送信する従来の構成に比べて、通信トラフィックを抑制でき、もってネットワークにかかる負荷の低減を図ることができると共に、ネットワークに配されるメールサーバ（本例では１１０等）の使用効率化の向上を図ることが可能になる。
【００４０】
なお、上記では、ステップＳ１３〜Ｓ２１において、宛先毎に、添付ファイルの削除の要否判断とメール送信を行うとしたが、送信メールから添付ファイルを必要に応じて削除して送信できる方法であれば良く、これに限定されない。
例えば、まず添付ファイル削除の要否を全宛先について判断し、その判断後に各宛先に順次メール送信を行う（もちろん添付ファイルの削除が必要とされた宛先についてはファイル削除が行われる）とすることもできる。
【００４１】
また、ステップＳ１４では、過去の受信メールのうち、「送信元」が送信メールのｉ番目の宛先と一致する受信メールの添付ファイルを検索するとしたが、「送信元」に加えて「宛先」が一致する過去の受信メールをも検索するとしても良い。具体的には、例えばメールＡのＣＣ欄に利用者αのアドレスが記載されており、メールＢの宛先に利用者αが含まれている場合を考える。この場合、利用者αは、メールＡにて当該添付ファイルを所有済みということになる。従って、過去の受信メールのうち、利用者αを「宛先」に含む受信メール（ここではＡ）が存在すれば、利用者α宛のメールＢについて添付ファイルを削除することで、利用者αに不便をかけることなく、上記同様にネットワークの通信トラフィック抑制等の効果を得ることができる。
【００４２】
（第２の実施の形態）
上記実施の形態では、添付ファイル同一性の判断対象の添付ファイルを、過去の受信メールの中から検索するとしたが、本実施の形態では、送信メールのオリジナル情報に記載の添付ファイルとしており、この点が第１の実施の形態と異なっている。以下、第１の実施の形態と異なる部分を中心に説明し、同じ部分についてはその説明を省略すると共に同符号を付すこととする。
【００４３】
図６は、本実施の形態のメールサーバ２１０が端末装置２０１からの送信メールを受け付けたときに実行する処理内容を示すフローチャートである。
同図に示すように、送信メールとしてメールＢを受け付けると（ステップＳ１１）、メールＢの添付ファイルのファイル名、拡張子を添付ファイル情報欄２３６から読み出すと共に、オリジナルとなるメールの添付ファイルのファイル名、拡張子をオリジナルメール情報欄２３７から読み出す（ステップＳ３１）。図４（ａ）の構成例２３０の場合、共にファイル名が「サンプル画像１」、拡張子が「ｂｍｐ」になる。
【００４４】
双方のファイル名、拡張子が同じか否かを判断する（ステップＳ３２）。同じと判断すると（ステップＳ３２で「ＹＥＳ」）、変数ｉの値を「１」に設定し、メールＢのｉ番目の宛先を確認し（ステップＳ１２、Ｓ１３）、ステップＳ３３に移る。ここでは宛先を利用者Ｘとする。
ステップＳ３３では、ｉ番目の宛先（利用者Ｘ）と同アドレスが、オリジナルメール情報欄２３７のＦｒｏｍまたはＴｏ欄に書き込まれているか否かを確認する。図４（ａ）の構成例２３０の場合、Ｆｒｏｍ欄に書き込まれているとされる。利用者ＸのアドレスがＦｒｏｍ欄に書き込まれている場合、当該添付ファイルの元々の所有者が利用者Ｘであり、Ｔｏ欄の場合、当該添付ファイルが利用者Ｘに送付済みであることが判る。この意味で、Ｆｒｏｍ欄の情報は、当該メールＢのオリジナルとなる過去のメールの送信元を示す履歴情報ということができる。
【００４５】
ＦｒｏｍまたはＴｏ欄に書き込まれていることを判断すると（ステップＳ３４で「ＹＥＳ」）、ステップＳ１７〜Ｓ１９の処理を実行する。すなわち、利用者Ｘ宛のメールＢから添付ファイルを削除し、そのメールＢを利用者Ｘ宛てに送信する。一方、書き込まれていないことを判断すると（ステップＳ３４で「ＮＯ」）、ステップＳ１９に移る。この場合、当該添付ファイルを所有していない可能性が高いので、添付ファイルが添付された状態でメールＢが送信される。
【００４６】
ステップＳ２０で全宛先への送信終了が判断されるまで、ステップＳ１３〜Ｓ２１の処理が繰り返し実行される。例えば、ｉ＝２、すなわち宛先を利用者Ｚとすると、利用者Ｚのアドレスは、オリジナルメール情報欄２３７のＦｒｏｍとＴｏ欄のいずれにも書き込まれていないので、ステップＳ３４で「ＮＯ」と判断される。これより、利用者Ｚ宛のメールＢは添付ファイルが添付された状態で送信されることになる。
【００４７】
なお、ステップＳ３２で双方のファイル名、拡張子が同じでないことを判断すると、指定された各宛先にそのままメールＢを送信して（ステップＳ３５）、当該処理を終了する。ファイル名等が同じでない場合、各宛先の利用者が当該添付ファイルを所有していないとしてファイル削除を行わないものである。
このように本実施の形態では、送信メールのオリジナルメール情報だけを参照して添付ファイルの同一性を判断するとしたので、判断等の処理を簡易化することができる。
【００４８】
なお、ステップＳ３３では、送信メールのｉ番目の宛先と同アドレスがオリジナルメール情報のＦｒｏｍ、Ｔｏ欄に書き込まれているかを確認するとしたが、これに限られない。例えば、オリジナルメール情報のＣＣ欄に宛先が書き込まれていれば、当該ＣＣ欄をも確認するとしても良い。ＣＣ欄の宛先には、当該オリジナルメールにて添付ファイルが送信済みであるから、送信メールのｉ番目の宛先と同アドレスがＣＣ欄に書き込まれている場合にも、その宛先へのメールＢについて添付ファイルを削除することで、上記同様に通信トラフィックの抑制等の効果を得ることができる。
【００４９】
（第３の実施の形態）
上記実施の形態では、添付ファイルを削除するとしたが、本実施の形態では、圧縮するとしており、この点が上記実施の形態と異なっている。
具体的には、メールサーバ２１０は、上記ステップＳ１７でファイル削除に代えてファイル圧縮、ここではＪＰＥＧ（Joint Photographic Experts Group）により非可逆圧縮を施し、ステップＳ１８で、削除情報の書き込みに代えて、圧縮を施したことを示す情報（圧縮情報）を書き込む処理を行うものである。
【００５０】
図７は、メールＢの本実施の形態に係る構成例２５０を示す図である。同図の添付ファイル欄２５１には、圧縮情報が書き込まれた例が示されている。圧縮された添付ファイル２５３は、メッセージ欄２５２の下に書き込まれている。
なお、圧縮方法がＪＰＥＧに限られないことはいうまでもなく、他の非可逆または可逆圧縮の方法、例えばＪＢＩＧ（Joint Bi-level Image experts Group）、ＭＨ（Modified Huffman）、ＭＭＲ（Modified Modified Read）などを用いるとしても良い。その際、どの圧縮方法が用いられたのかを示す情報が記述される。同図の例では、添付ファイル欄２５１に、ファイルの拡張子として表わされている。利用者Ｘは、受信したメールＢから拡張子等を確認することで圧縮方法を理解でき、必要があれば伸長（解凍）を行うことでファイルの内容を参照することができる。一方で、利用者Ｚは、圧縮されていない添付ファイルを受信できるので、解凍の手間をかけずにファイルの内容を確認することができる。
【００５１】
このように添付ファイルの削除に代えて圧縮することでも、圧縮せず一律に添付ファイルを送信する構成に比べて、ネットワークの通信トラフィックの抑制とメールサーバの使用効率化の向上を図ることができる。
なお、利用者Ｘにとってはファイルがどのような内容だったかを知ることができれば十分ということもでき、従って圧縮をいわゆるサムネールとすることもできる。
【００５２】
（第４の実施の形態）
本実施の形態では、第３の実施の形態で利用者Ｙから利用者ＸとＺ宛に送信されたメールＢを受け取った利用者Ｘが、端末装置１０１から転送機能によりメールＣを利用者Ｙ、α、Ｚ宛に送信する場合に、メールサーバ１１０が実行する処理について説明する。
図８は、メールＣの構成例１４０を示す図である。
【００５３】
同図に示すようにメールＣは、Ｔｏ欄とＣＣ欄に宛先として利用者Ｙ、α、Ｚのアドレスが書き込まれている。また、オリジナルメール欄１４２には、２つのオリジナルメールがあることが書き込まれている。オリジナルメール１の情報は、端末装置２０１がメールＢを送信する際にそのメーラーにより書き込まれ、オリジナルメール２の情報は、端末装置１０１がメールＣを送信する際にそのメーラーにより書き込まれる。オリジナルメール欄１４２を見れば、メールＣが、メールＡ、Ｂを元に作成されたもの（履歴）であることが解る。また、添付ファイル１４３が含まれている。メールＣは、メールサーバ１１０の送信メール格納部（図２の２５７に相当）に格納される。
【００５４】
図９は、メールサーバ１１０が実行する処理内容を示すフローチャートである。
同図に示すように、本処理は、第２の実施の形態におけるメールサーバ２１０の処理（図６）と基本的に同じであるが、ステップＳ３３では「ＣＣ」欄をも確認することが追加され、ステップＳ１７、１８に代えてステップＳ５０の圧縮処理を実行する点が異なっている。ステップＳ１３でｉ＝１とすると、宛先が利用者Ｙになり、ステップＳ３３、Ｓ３４では、利用者ＹのアドレスがメールＣのオリジナルメール情報欄１４２のＦｒｏｍ、ＴｏまたはＣＣ欄に存在するか否かが判断される。図８の例では、存在すると判断されて（ステップＳ３４で「ＹＥＳ」）、ステップＳ５０の圧縮処理が実行される。
【００５５】
図１０は、圧縮処理のサブルーチンの内容を示すフローチャートである。
同図に示すように、まず添付ファイルが画像または音声ファイルか否かを判断する（ステップＳ５１）。ここでは、添付ファイルのファイル名の拡張子を参照して判断される。例えば、拡張子が「ｊｐｇ」の場合に画像、「ｗａｖ」の場合に音声などと予め決めておくことで判断できる。また、図示していないが、メールＣのヘッダ部の「Ｃｏｎｔｅｎｔ−Ｔｐｙｅ」欄を参照するとしても良い。具体的には、当該欄の記載が例えば「ｉｍａｇｅ／ｊｐｅｇ」であれば画像、「ａｕｄｉｏ／ｂａｓｉｃ」とあれば音声、「ｖｉｄｅｏ／ｍｐｅｇ」とあれば動画等のファイルであると判断するものである。
【００５６】
画像、音声ファイルのいずれかと判断すると（ステップＳ５１で「ＹＥＳ」）、１番目の宛先（利用者Ｙ）について、今回のメールＣの送信により、同一と判断された添付ファイルとファイル名が同じファイルの送信が２回目になるか、それとも３回目以上になるかを判断する（ステップＳ５２）。ここでは、利用者Ｙが、各オリジナルメールの宛先になっている回数が計数される。具体的には、利用者Ｙは、オリジナルメール１の宛先になっているがオリジナルメール２の宛先にはなっていないので、利用者Ｙには当該添付ファイルが過去１回送信済みと判断され、従って今回の送信で２回目と判定される。
【００５７】
同様に、例えば利用者Ｚの場合には、オリジナルメール１、２共に宛先になっているので、今回の送信で３回目とされる。この回数とは、宛先ごとに、その宛先がファイル名の同じ添付ファイルを何回受信することになるのかを示すものといえる。
回数を２回目と判断すると（ステップＳ５２で「ＹＥＳ」）、利用者Ｙ宛のメールＣについて、その添付ファイル１４３に、第３の実施の形態と同じ圧縮率Ａの圧縮処理を施し（ステップＳ５３）、圧縮した旨を示す圧縮情報を添付ファイル欄１４１（図８）に書きこんで（ステップＳ５４）、メインルーチンにリターンする。この場合、２回目の圧縮ということになる（１回目は、メールＢの添付の際にメールサーバ２１０で圧縮されたため）ので、その旨と圧縮率Ａであることを示すメッセージが圧縮情報として追記される。当該メールＣの送信は、図９のステップＳ１９において実行される。
【００５８】
ルーチンが一巡してステップＳ１３に移り、ｉ＝２（宛先が利用者α）の場合には、ステップＳ３３では、利用者αのアドレスがオリジナルメール情報のＦｒｏｍ、ＴｏまたはＣＣ欄に書き込まれているかが確認される。ここでは書き込まれていないとし、ステップＳ３４で「ＮＯ」と判断され、ステップＳ１９に移る。この場合、ステップＳ５０の圧縮処理が実行されない。従って、利用者α宛のメールＣについては添付ファイル１４３の圧縮が施されず、添付ファイル欄１４１には、ファイル名（図８の例では「サンプル画像１．ｊｐｇ」）だけが書き込まれ、圧縮情報としてのメッセージは書き込まれない。
【００５９】
さらに、ルーチンが一巡してステップＳ１３に移り、ｉ＝３（宛先が利用者Ｚ）になった場合には、ステップＳ３３で利用者Ｚのアドレスがオリジナルメール情報のＦｒｏｍ、ＴｏまたはＣＣ欄に書き込まれているかが確認される。ここでは、書き込まれていると判断され、ステップＳ５０の圧縮処理に移る。
この場合、図１０の圧縮処理では、画像ファイルと判断され（ステップＳ５１で「ＹＥＳ」）、ステップＳ５２では、利用者Ｚについて回数が判定される。利用者Ｚについては上記のように３回目と判断され（ステップＳ５２で「ＮＯ」）、利用者Ｚ宛のメールＣについては、その添付ファイル１４３に圧縮率がＡよりも大きいＢの圧縮を施し（ステップＳ５５）、ステップＳ５４に移る。このように回数が３回目以上の場合に圧縮率を大きくしているのは、利用者Ｚは過去に２回同じ名称の添付ファイルを受信しており、従って伸長したときにある程度の歪が残ってもその内容を参考にできれば十分と考えられ、高圧縮を行うことで通信トラフィックの抑制をより図ることができるからである。なお、回数が３回目以上の場合に同じ圧縮率Ｂとしているが、回数が増えるに従って圧縮率を大きくしていくとしても良いし、サムネールとしても良い。ステップＳ５４では圧縮情報が書き込まれるが、ここでは圧縮率Ｂであることが追記される。
【００６０】
ステップＳ５１で、画像、音声以外のファイルであることを判断すると、圧縮等の処理を施すことなく、そのままメインルーチンにリターンする。画像、音声以外のファイルの場合、画像、音声に比べて圧縮、伸長による品質の劣化が目立つことが多いと考えられるからである。なお、ファイルの種類毎に別の方法を用いて圧縮する構成をとるとしても良い。また、どの種類のファイルをどの方法を用いて圧縮するかについて予め決めておいても良いし、管理者等からの設定入力を受け付ける構成をとるとしても良い。
【００６１】
このように本実施の形態では、添付ファイルの種類または送信済み回数に応じて圧縮方法を変える、ここでは圧縮の要否を決め、また圧縮率を変えるとしているので、受信側のユーザに不便をかけることなく、より通信トラフィックの抑制とメールサーバの使用効率化の向上を図ることができる。本実施の形態の処理はメールサーバ１１０に限られず、他のメールサーバ２１０等が実行するとしても良い。
【００６２】
なお、本発明は、メールサーバに限られず、メールサーバにおける上記のメール送受信方法であるとしてもよい。さらに、その方法をコンピュータが実行するプログラムであるとしてもよい。また、本発明に係るプログラムは、例えば磁気テープ、フレキシブルディスク等の磁気ディスク、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＭＯ、ＰＤなどの光記録媒体、フラッシュメモリ系記録媒体等、コンピュータ読み取り可能な各種記録媒体に記録することが可能であり、当該記録媒体の形態で生産、譲渡等がなされる場合もあるし、プログラムの形態でインターネットを含む有線、無線の各種ネットワーク、放送、電気通信回線、衛星通信等を介して伝送、供給される場合もある。
【００６３】
また、本発明に係るプログラムは、上記に説明した処理をコンピュータに実行させるための全てのモジュールを含んでいる必要はなく、例えば通信プログラムやオペレーティングシステム（ＯＳ）に含まれるプログラムなど、別途情報処理装置にインストールすることができる各種汎用的なプログラムを利用して、本発明の各処理をコンピュータに実行させるようにしても良い。従って、上記した本発明の記録媒体に必ずしも上記全てのモジュールを記録している必要はないし、また必ずしも全てのモジュールを伝送する必要もない。さらに所定の処理を専用ハードウェアを利用して実行させるようにすることができる場合もある。
【００６４】
（変形例）
以上、本発明を実施の形態に基づいて説明してきたが、本発明は、上述の実施の形態に限定されないのは勿論であり、以下のような変形例が考えられる。
すなわち、上記実施の形態では、メールサーバが送信メールを送信する際に必要に応じて添付ファイルを削除する構成例を説明したが、例えば添付ファイル付きの受信メールを受信して指定された宛先用のメールボックスに格納する際に、当該添付ファイルを必要に応じて削除する構成をとるとすることもできる。
【００６５】
第１の実施の形態を例にとると、メールサーバ１１０は、メールＡを含む全ての送信メールについて、その送信元を含む履歴情報と添付ファイルの内容に関する情報を記憶手段に記憶しておく。メールサーバ２１０は、メールＢをメールサーバ１１０に送信する際に、添付ファイルを削除せずにメールサーバ１１０宛に送信する（このメールサーバ２１０の処理は従来に同じ）。
【００６６】
メールサーバ１１０は、メールＢを受信すると、メールＢから宛先と添付ファイルの内容に関する情報を取得する。そして、記憶されている履歴情報と添付ファイルの内容に関する情報を読み出して、過去の送信メールのうち、その送信元が、メールＢの宛先（利用者Ｘ）と一致するメールの添付ファイルを検索する。ここでは、メールＡの添付ファイルが検索されることになる。メールＡとメールＢの添付ファイルの同一性を判断し、同一と判断すると、メールＢから添付ファイルを削除し、利用者Ｘ用のメールボックスに格納させる。利用者Ｘから受信要求があると、メールサーバ１１０は、添付ファイルが削除されたメールＢを利用者Ｘ宛てに送信するというものである。
【００６７】
このようにしても、メールサーバ１１０の無用なファイルの長期保存の防止による使用効率化の向上と、メールサーバ１１０と端末装置１０１間におけるネットワークの通信トラフィックの抑制を図ることができる。
また、上記実施の形態及び上記変形例をそれぞれ組み合わせるとしても良い。
【産業上の利用可能性】
【００６８】
本発明は、電子メールを送受信するメールサーバを含む電子メール通信システムにおいて、通信トラフィックの抑制を図る技術として有用である。
【図面の簡単な説明】
【００６９】
【図１】第１の実施の形態に係る電子メール通信システム１０の構成を示す図である。
【図２】電子メール通信システム１０に含まれるメールサーバ２１０の構成を示すブロック図である。
【図３】電子メール通信システム１０に含まれる端末装置１０１からメールサーバ１１０を介してメールサーバ２１０宛に送信されるメールＡの構成例１３０を示す図である。
【図４】（ａ）は、電子メール通信システム１０に含まれる端末装置２０１からメールサーバ２１０宛に送信されるメールＢの構成例２３０を示す図であり、（ｂ）は、メールサーバ２１０からメールサーバ１１０宛に送信される構成例２４０を示す図である。
【図５】端末装置２０１からメールＢを受け付けたときにメールサーバ２１０が実行する処理内容の例を示すフローチャートである。
【図６】第２の実施の形態に係るメールサーバ２１０の処理内容を示すフローチャートである。
【図７】第３の実施の形態に係るメールＢの構成例２５０を示す図である。
【図８】第４の実施の形態に係るメールサーバ１１０がメールサーバ２１０等宛に送信するメールＣの構成例１４０を示す図である。
【図９】第４の実施の形態に係るメールサーバ１１０が実行する処理内容を示すフローチャートである。
【図１０】第４の実施の形態に係るメールサーバ１１０が実行する処理に含まれる圧縮処理のサブルーチンの内容を示すフローチャートである。
【符号の説明】
【００７０】
１０      電子メール通信システム
１０１、１０２、１０３、２０１、２０２、２０３、３０１、３０２      端末装置
１１０、２１０、３１０      メールサーバ
１３９、１４３、２３９、２５３      添付ファイル
２５１      送受信部
２５２      全体制御部
２５３      記憶部
２５４      メール検索部
２５５      添付ファイル同一性判断部
２５６      添付ファイル削除部
【図１】
2007213338.tif 000003
【図２】
2007213338.tif 000004
【図３】
2007213338.tif 000005
【図４】
2007213338.tif 000006
【図５】
2007213338.tif 000007
【図６】
2007213338.tif 000008
【図７】
2007213338.tif 000009
【図８】
2007213338.tif 000010
【図９】
2007213338.tif 000011
【図１０】
2007213338.tif 000012