JP4014211B2 - メールサーバ装置及び情報通信システム - Google Patents

Description

本発明は、情報通信端末装置の能力に応じた形式のデータファイルを提供し得るメールサーバ装置及び情報通信システムに関する。

インターネット等のＴＣＰ／ＩＰを用いたネットワーク上でメッセージの送受信を行うプロトコルとしてＳＭＴＰ、ＰＯＰ３、ＩＭＡＰ４が知られており（例えば非特許文献１及び非特許文献２参照及び非特許文献３。）、これらのプロトコルに従った電子メールサービスが広く普及している。

このような電子メールサービスでは、マルチパートＭＩＭＥ（Multipurpose Internet Mail Extension）形式でコード化したデータファイルを添付することができるようになっている（例えば非特許文献４〜８参照。）
Jonathan B. Postel、「ＲＦＣ−８２１」、[online]、１９８２年８月、［平成１４年１２月３１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc0821.txt＞、ｐ．２〜５ J. Myers、M. Rose、「ＲＦＣ−１９３９」、[online]、１９９６年５月、［平成１４年１２月３１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc1939.txt＞、ｐ．２〜４ M. Crispin、「ＲＦＣ−２０６０」、[online]、１９９６年１２月、［平成１５年１月１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc2060.txt＞、ｐ．４〜７９ N. Freed, N. Borenstein、「ＲＦＣ２０４５」、[online]、１９９６年１１月、［平成１５年６月１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc2045.txt＞、ｐ．３〜３１ N. Freed, N. Borenstein、ＲＦＣ２０４６」、[online]、１９９６年１１月、［平成１５年６月１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc2046.txt＞、ｐ．３〜４４ K. Moore、ＲＦＣ２０４７」、[online]、１９９６年１１月、［平成１５年６月１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc2047.txt＞、ｐ．１〜１３ N. Freed, J. Klensin, J. Postel、ＲＦＣ２０４８」、[online]、１９９６年１１月、［平成１５年６月１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc2048.txt＞、ｐ．１〜２１ N. Freed, N. Borenstein、ＲＦＣ２０４９」、[online]、１９９６年１１月、［平成１５年６月１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc2049.txt＞、ｐ．１〜２４

しかしながら、携帯電話端末装置等の情報通信端末装置の表示能力，記憶容量等の制約は機種毎に異なる場合がある。これらの制約条件の異なる情報通信端末装置に対して、一律に同じファイル形式(解像度等も含む)のデータを供給してしまうと、受信できなかったり、表示できなかったりする場合がある。

本発明は、上述のような課題に鑑みてなされたものであり、情報通信端末装置の能力に応じて適切な形式のデータを提供することができるメールサーバ装置及び情報通信システムを提供することを目的とする。

上述の問題を解決するために、本発明に係るメールサーバ装置は、情報通信端末装置の機種を示す機種ＩＤ毎に利用可能なデータファイルの形式を示す情報を保持する端末能力保持テーブルと、電子メールサービスの提供先の情報通信端末装置の宛先毎に機種ＩＤを保持するアドレステーブルと、受信したメッセージ（受信メッセージ）のＭＩＭＥ構造を検出する構造検出手段と、受信メッセージに添付されているデータファイルの形式を検出する形式検出手段と、メッセージを受信すると、アドレステーブルを参照して受信メッセージの宛先に対応する機種ＩＤを取得し、取得した機種ＩＤに応じて端末能力保持テーブルを参照して当該宛先の情報端末装置で利用可能なデータファイルの形式を示す情報を取得し、形式検出手段が検出したデータファイルの形式が当該データファイルが添付されている受信メッセージの宛先の情報通信端末装置において利用可能な形式か否かを判定する判定手段と、判定手段の判定結果に応じて、当該データファイルが当該情報通信端末装置において利用可能な形式でない場合に、データファイルの変換を行う変換手段に、データファイルを当該情報通信端末装置において利用可能な形式に変換させる変換制御手段と、変換手段によって変換されたデータファイルの形式を示す通知拡張子を選択する通知拡張子選択手段と、構造検出手段が検出したＭＩＭＥ構造と通知拡張子選択手段が選択した通知拡張子を含む受信通知をショートメッセージにより情報通信端末装置に送信する受信通知手段と、受信通知を受信した情報通信端末装置からのＭＩＭＥ構造のパートを示す情報を含む送信要求に応じて要求されたパートに対応するデータファイルを送信する送信手段とを備えることを特徴とする。

また、本発明に係る情報通信システムは、本発明に係るメールサーバ装置を備えることを特徴とする。

本発明では、形式検出手段が検出したデータファイルの形式が当該データファイルが添付されている受信メッセージの宛先に対応する情報通信端末装置において利用可能な形式でない場合に、変換制御手段が、変換手段に、データファイルを当該情報利用端末装置において利用可能な形式に変換させることにより、メッセージの宛先の情報通信端末装置の能力に応じて適切な形式のデータファイルを提供することができる。また、本発明では、構造検出手段が、受信したメッセージ（受信メッセージ）のＭＩＭＥ構造を検出し、通知拡張子選択手段が、変換手段によって変換されたデータファイルの形式を示す通知拡張子を選択し、受信通知手段が、構造検出手段が検出したＭＩＭＥ構造と通知拡張子選択手段が選択した通知拡張子を含む受信通知をショートメッセージにより情報通信端末装置に送信し、送信手段が、受信通知を受信した情報通信端末装置からのＭＩＭＥ構造のパートを示す情報を含む送信要求に応じて要求されたパートに対応するデータファイルを送信するため、ユーザが必要なデータファイルの受信のみを選択することができ、無駄なトラフィックの低減に寄与することができる。

本発明は、例えば携帯電話端末装置等の情報利用端末装置に、電子メールサービス、ＨＴＴＰ（Hyper Text Transfer Protocol）サービス等のサービスを提供する情報通信システム等に適用することができる。

（構成）
本発明の一実施例に係る情報通信システムは、例えば図１に示すように、メールサービスを提供するメールサーバ２０と、移動体通信網３０経由でメールサーバ２０が提供するメールサービスを利用する携帯電話端末装置４０とを備えている。

ｍｂｏｘ１０には、ユーザのアカウント毎に、ユーザ領域１１，１２，…が設けられており、これらのユーザ領域１１，１２，…にはユーザのメールアドレス毎にメッセージ１１ａ，１１ｂ，…が格納されるようになっている。

メールサーバ２０は、ＳＭＴＰ等のプロトコルに従って、インターネット等のネットワーク１経由で供給されるメッセージを受信してｍｂｏｘ１０に格納し、ＰＯＰ３、ＩＭＡＰ４等のプロトコルに従って、携帯電話端末装置４０のユーザのメールアドレス宛てのメッセージを提供する。このメールサーバ２０は、ネットワーク１を介して供給されるメッセージを受信してｍｂｏｘ１０に格納する受信部２１と、受信部２１が受信したメッセージの構造の解析等を行うメッセージ解析部２２と、携帯電話端末装置４０の表示能力等を示す情報を保持するユーザ端末能力保持部２３と、メッセージ解析部２２が解析したメッセージに添付されているデータファイルの形式を変換するファイル形式変換部２４と、新たなメッセージを受信した旨を示す受信通知を携帯電話端末装置４０宛てに送信する通知部２５と、携帯電話端末装置４０から要求に応じてｍｂｏｘ１０に格納されているメッセージを提供するメッセージ提供部２６とを備えている。

移動体通信網３０は、携帯電話端末装置４０との間の無線チャネルの割り当て等の処理を行う回線交換機３１と、データ通信用のパケットデータ等の交換処理を行うパケット交換機３２と、例えば１４０オクテット程度の短いメッセージ（ショートメッセージ）を携帯電話端末装置４０に提供するショートメッセージサービスセンタ（ＳＭＳＣ：Short Message Service Center）３３と、携帯電話端末装置４０と間で無線通信を行う基地局装置（ＢＳ：Base Station）３５ａ，３５ｂ，…，３５ｎと、ＢＳ３５ａ〜３５ｎの管理を行う基地局制御装置（ＢＳＣ：Base Station Controller）３４と、携帯電話端末装置４０の登録情報等の管理を行う加入者位置登録装置（ＨＬＲ：Home Location Register）３９とを備えている。

携帯電話端末装置４０は、移動体通信網３０を介して通話サービス，ＨＴＴＰサービス等を利用できる他、メールサーバ２０によって提供されるメールサービスを利用することができるようになっている。この携帯電話端末装置４０は、高周波信号の処理を行う高周波（ＲＦ：Radio Frequency）部４１と、ＭＰＵ４２と、メモリ４３と、ユーザからの指示等を入力する操作キー４４と、ユーザに対する表示を行う表示部４５と、音声信号の符号化／復号化を行う音声ＣＯＤＥＣ４６と、ＭＩＣ４７と、スピーカ４８とを備えている。

ＭＰＵ４２は、例えばメモリ４３に保持されている制御プログラムを実行することにより、移動体通信網３０を介した通信の制御を行う通信制御部５０，電子メールの送受信を行う電子メールクライアント６０及び電子メールのメッセージ等を表示するブラウザ７０として機能する。電子メールクライアント６０は、上述のメールサーバ２０が提供するメールサービスを利用する通常メール処理部６１と、上述のＳＭＳＣ３３が提供するショートメッセージサービスを利用するＳＭＳ処理部６２とを備えている。また、メモリ４３内には、設定情報を保持する設定保持部４３ａと、メッセージを保持するメッセージ保持部４３ｂとが設けられている。

（メッセージ例）
メールサーバ２０がネットワーク１側に対して送受信するメッセージは、例えば図２に示すように、メッセージの伝送経路，送信日時，差出人（Ｆｒｏｍフィールド），宛先（Ｔｏフィールド），件名（Ｓｕｂｊｅｃｔフィールド），メッセージＩＤ等の情報を含むヘッダ３０１と、ボディ３０２とから構成されている。ボディ３０２は、さらにＭＩＭＥマルチパートメッセージから構成されていることがあり、図２の例では、ボディ３０２が本文テキスト部３０２ａと添付ファイル（Ｔｅｓｔ．ｐｎｇ）３０２ｂとから構成されている場合を示している。

ところで、この情報通信システムでは、電子メールクライアント６０が受信する１通のメッセージの上限サイズは、例えばショートメッセージでは１４０オクテット，通常のメッセージではヘッダ込みで３０ｋバイトに制限されている。

一方、メールサーバ２０が受信するメッセージは、携帯電話端末装置４０以外にもネットワーク１側からも供給されるようになっており、電子メールクライアント６０におけるショートメッセージあるいはメッセージの上限サイズ以上のサイズである場合もある。

このため、この情報通信システムでは、メールサーバ２０が携帯電話端末装置４０宛てのメッセージを受信すると、まず、ショートメッセージによってヘッダの一部，本文テキスト（ショートメッセージにおけるサイズ制限を超える場合には本文テキストの一部），添付ファイルの有無及び種類等を含む上述の受信通知を携帯電話端末装置４０に送信するようになっている。

例えばメッセージに添付ファイルが無く、本文テキストのサイズがサイズ制限以内であれば、電子メールクライアント６０は、メールサーバ２０に当該メッセージのさらなる送信は要求しない。しかし、添付ファイルがある場合又は本文テキストのサイズがサイズ制限以上であった場合には、電子メールクライアント６０は、ユーザからの指示に従って、メールサーバ２０に添付ファイル又は本文テキスト（残りの指定したサイズ分のみ）の送信を要求するようになっている。

（添付ファイルの形式変換）
ところで、メールサーバ２０がネットワーク１側から受信したメッセージには、メッセージの宛先の携帯電話端末装置４０側で再生できない形式のデータファイルが添付されている場合がある。

携帯電話端末装置４０の表示部４５の表示能力は、パーソナルコンピュータ等の汎用の情報処理装置の表示部に比較すると表示画素数が制限されていたり、表示色数が制限されていたりする。このため、汎用の情報処理装置では表示できる画像のデータファイルであっても携帯電話端末装置４０では表示できない場合がある。また、音声のデータファイルあるいはアプリケーションに依存した形式のデータファイルに関しても携帯電話端末装置４０側で再生ないし表示が不可能な場合もある。

さらに、携帯電話端末装置４０の機種毎に表示能力が異なることもあり、ある携帯電話端末装置４０では表示できるデータファイルであっても他の携帯電話端末装置４０では表示できない場合もある。また、出荷時期，利用できるサービスの種類等に応じて携帯電話端末装置４０の仕様が異なり、表示能力等を個別に管理する必要が生じる場合も考えられる。

このため、この情報通信システムでは、メールサーバ２０側で、メッセージに添付されているデータファイルの形式を確認し、携帯電話端末装置４０で表示できない形式である場合には、携帯電話端末装置４０で表示できる形式に変換して携帯電話端末装置４０に提供するようにしている。

具体的には、例えば図３に示すように、ユーザ端末能力保持部２３に、メッセージの宛先となるアドレスと、当該アドレスに対応する携帯電話端末装置４０の機種を示す属性情報（機種ＩＤ）を保持するアドレステーブル２３ａと、機種ＩＤに対応する携帯電話端末装置４０の能力を保持する端末テーブル２３ｂとを設けている。ファイル形式変換部２４は、アドレスをキーにしてアドレステーブル２３ａから機種ＩＤを取得し、機種ＩＤをキーにして端末テーブル２３ｂからアドレスに対応する携帯電話端末装置４０の能力を取得することができるようになっている。

メッセージに添付されているデータファイルの形式は、ボディ３０２中のＭＩＭＥタイプ，各パート内のファイル名（ｎａｍｅフィールド、ｎａｍｅフィールドが存在しない場合はｆｉｌｅｎａｍｅフィールド）中の拡張子をキーとして、例えば図４に示す拡張子変換テーブルを参照することによって特定することができる。メッセージ解析部２２は、この拡張子変換テーブルを保持している。

また、ファイル形式変換部２４には、例えば図５に示すように、画像のデータファイルの形式を変換する画像形式変換部２４ａと、音声のデータファイルの形式を変換する音声形式変換部２４ｂと、アプリケーションに依存したデータファイル等の形式を変換する形式変換部２４ｃと、メッセージ解析部２２が検出したデータファイルの形式とユーザ端末能力保持部２３から取得した当該データファイルが添付されているメッセージの宛先の携帯電話端末装置４０の能力に応じて各形式変換部２４ａ〜２４ｃの動作を制御する制御部２２ｄとを備えている。

また、各形式変換部２４ａ〜２４ｃは、具体的なデータファイルの変換処理を実行する公知のプログラムを用いた変換部（変換部Ａ，変換部Ｂ，変換部Ｃ，…）を備えており、制御部２４ｄからの制御に従って、所定の変換部によってデータファイルの形式の変換を行う。変換部はモジュール化されており、変換部を追加することにより、将来ファイル形式が追加された場合でも対応できるようになっている。

（動作）
上述のように構成された情報通信システムでは、メールサーバ２０の受信部２１がメッセージを受信すると、例えば図６中のＳ０において、受信部２１がファイル形式変換部２４にメッセージを受信した旨を通知し、ファイル形式変換部２４がメッセージの宛先の携帯電話端末装置４０の能力をユーザ端末能力保持部２３に問合せる（Ｓ１）。

ユーザ端末能力保持部２３からの回答があると（Ｓ２）、ファイル形式変換部２４は、メッセージ解析部２２によるメッセージの解析結果によって得られたメッセージに添付されているデータファイルの形式と、携帯電話端末装置４０の能力とを比較し、携帯電話端末装置４０において表示等が可能でない場合にはデータファイルの形式の変換を行い、変換後のデータファイルをｍｂｏｘ１０の当該ユーザのユーザ領域１１に格納する（Ｓ３）。

データファイルの形式の変換が終了すると、ファイル形式変換部２４は、通知部２５に指示して携帯電話端末装置４０宛てに、新たなメッセージを受信した旨を通知する受信通知を送信させる（Ｓ４）。この受信通知は、ＳＭＳＣ３３等を介して携帯電話端末装置４０のＳＭＳ処理部６２に供給される（Ｓ５）。

この受信通知において通知する情報は、例えば図７に示すように、従来の同種の情報通信システムでは、送信元アドレス，件名，本文の一部及び本文等の続きの情報の有無を示す情報であったが、この情報通信システムでは、例えば返信先アドレス（Ｒｅｐｌｙ−ｔｏフィールド）と、本文等の続きの情報の有無を示す情報の代わりのメッセージの構造を示す情報と添付ファイルについての情報となっている。

上述のような受信通知を受信すると、ＳＭＳ処理部６２は、受信した受信通知に応じて、例えば図８（Ａ）に示すように、送信元アドレス，件名，メッセージの構造及び添付ファイルについての情報等を表示部４５に表示させる（Ｓ６）。ユーザがこれに応じて操作キー４４を操作して受信を希望するパート（ヘッダ，本文，添付ファイル）を指示すると、通常メール処理部６１は、指示されたパートの送信を要求するコマンド（メッセージ要求）をメールサーバ２０のメッセージ提供部２６宛てに送信する（Ｓ７）。このメッセージ要求に応じてメッセージ提供部２６は、指示されたパートをｍｂｏｘ１０から取得し、携帯電話端末装置４０宛に送信する。これにより、ユーザが希望する添付ファイル等が通常メール処理部６１に供給される。

（動作詳細）
上述のＳ３のメッセージ解析におけるデータファイルの形式の判定処理では、メッセージ解析部２２は、まず、メッセージのＭＩＭＥ構造を解析して、各パート毎に形式の判定処理を実行する。

この判断処理では、メッセージ解析部２２は、例えば図９-1及び図９-2に示すように、各パートのＣｏｎｔｅｎｔ−ｔｙｐｅフィールド（Ｓ１０１，Ｓ１０３，Ｓ１０９）と、ファイル名（Ｓ１１１〜Ｓ１２０）によってデータファイルの形式を判断している。

具体的には、まず、Ｃｏｎｔｅｎｔ−ｔｙｐｅが“ｍｅｓｓａｇｅ／ｒｆｃ８２２”であるかを判断し（Ｓ１０１）、該当する場合には、当該パートの通知拡張子（図４中のＡｔｙｐｅ）に当該パートが電子メールファイルであることを示す“８２２”を設定する（Ｓ１０２）。

次に、Ｃｏｎｔｅｎｔ−ｔｙｐｅが“ｔｅｘｔ／ｐｌａｉｎ”であるか否かを確認し（Ｓ１０３）、該当する場合には、Ｃｏｎｔｅｎｔ−ｔｙｐｅに“ｎａｍｅ”が存在するか否かまたはＣｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに“ｆｉｌｅｎａｍｅ”が存在するか否かを確認する（Ｓ１０４）。存在する場合には、条件に一番初めに合致したパートであるか否かを確認し（Ｓ１０５）、一番初めに合致したパートであればメッセージの本文とし、当該パートを添付ファイルとしては扱わない（Ｓ１０６）、それ以外であれば通知拡張子（Ａｔｙｐｅ）に“ＢＤＹ”を設定する（Ｓ１０８）。Ｃｏｎｔｅｎｔ−ｔｙｐｅに“ｎａｍｅ”が存在しないまたはＣｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに“ｆｉｌｅｎａｍｅ”が存在しない場合には、通知拡張子（Ａｔｙｐｅ）に“ＴＸＴ”を設定する（Ｓ１０７）。

Ｃｏｎｔｅｎｔ−ｔｙｐｅが“ｔｅｘｔ／ｐｌａｉｎ”でない場合には、Ｃｏｎｔｅｎｔ−ｔｙｐｅが“ｔｅｘｔ／ｈｔｍｌ”であるか否かを確認し（Ｓ１０９）、該当する場合には、通知拡張子（Ａｔｙｐｅ）に“ＨＴＭ”を設定する（Ｓ１１０）。

Ｃｏｎｔｅｎｔ−ｔｙｐｅが“ｔｅｘｔ／ｈｔｍｌ”でない場合には、Ｃｏｎｔｅｎｔ−ｔｙｐｅに“ｎａｍｅ”が存在するか否かまたはＣｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに“ｆｉｌｅｎａｍｅ”が存在するか否かを確認し（Ｓ１１１）、存在する場合には、ファイル名がエンコードされていれば（Ｓ１１２）、ファイル名をデコードした際に正常か否かを確認し（Ｓ１１３）、正常でなければ通知拡張子（Ａｔｙｐｅ）に“？？？”を設定する（Ｓ１１４）。

ファイル名がエンコードされていない、若しくはエンコードされているファイル名のデコード結果が正常である場合には、Ｃｏｎｔｅｎｔ−ｔｙｐｅが“ｉｍａｇｅ／ｍｔ＊（＊は任意の文字列）”であって、ｎａｍｅフィールドまたはｆｉｌｅｎａｍｅフィールドのファイル名の拡張子が、ＪＰＧ又はＰＮＧであるか否かを確認する（Ｓ１１５）。これらの拡張子のいずれかに該当する場合には、ファイル名の拡張子が“ｍｔ？”（？は文字“ｎ”若しくは１桁の数字“２”〜“９”）のいずれかに該当するか否かを判定し（Ｓ１１６）、該当する場合には、通知拡張子（Ａｔｙｐｅ）に“ｍｔ？”（？はＳ１１６で判定した値）を設定する（Ｓ１１７）。

Ｃｏｎｔｅｎｔ−ｔｙｐｅとファイル名の拡張子が上述の条件に一致しない場合には、ファイル名の拡張子が上述の図４に示す拡張子変換テーブルに存在するか否かを確認し（Ｓ１１８）、存在する場合には当該拡張子に対応する通知拡張子（Ａｔｙｐｅ）を拡張子変換テーブルから選択して設定する（Ｓ１１９）。ファイル名の拡張子が拡張子変換テーブルに存在しない場合には通知拡張子（Ａｔｙｐｅ）に“？？？”を設定する（Ｓ１２０）。

また、Ｃｏｎｔｅｎｔ−ｔｙｐｅに“ｎａｍｅ”が存在しない場合またはＣｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎに“ｆｉｌｅｎａｍｅ”が存在しない場合には、当該パートにファイル名がない状態と考えられ、携帯電話端末装置４０に供給しても表示等することができない。このような場合には、受信通知に添付ファイル情報を含めないように通知部２４に指示し、メッセージ提供部２６は、携帯電話端末装置４０からの要求Ｓ７に対する応答Ｓ８に添付ファイル情報を含めない（Ｓ１２１）。

メッセージ解析部２２は、上述のように設定した通知拡張子（Ａｔｙｐｅ）をファイルの形式を示す情報としてファイル形式変換部２４に通知する。

ところで、上述のように、メッセージ提供部２６は、パート毎にメッセージを携帯電話端末装置４０に提供することができるようになっている。このメッセージ提供部２６は、ｍｂｏｘ１０に対して、例えばＩＭＡＰ４に準じた手順でメッセージの読み出し等の処理を行うようになっている。

これに対し、ＭＰＵ４２の処理性能等の制限から、通常メール処理部６１にはＩＭＡＰ４そのものは実装しておらず、メッセージの送信要求では、メッセージの送信を要求するコマンド，個々のメッセージに割り当てられた識別情報（ＵＩＤ：Unique ID）及び送信要求の対象となるパートを示す情報［例えばMIME構造に準じた“2．1”等のパート番号］が指定されるようになっている。

メッセージ提供部２６は、このような送信要求に応じて内部的にＩＭＡＰコマンドを生成し、ｍｂｏｘ１０に対する操作を行うようになっている。具体的には、メッセージ提供部２６は、例えば図１０に示すように、携帯電話端末装置４０との間でコマンドの送受信を行う送受信部２６ａと、携帯電話端末装置４０からの要求を解析する要求解析部２６ｂと、ｍｂｏｘ１０からメッセージを取得するメッセージ取得部２６ｃと、携帯電話端末装置４０に対する応答メッセージを構成する応答構成部２６ｄとを備えている。

メッセージ提供部２６の要求解析部２６ｂは、通常メール処理部６１から供給された送信要求中のコマンド及びパラメータ（ＵＩＤ，パート番号等）を解析して送信要求に対応するＩＭＡＰコマンドを内部的に生成し、メッセージ取得部２６ｃに指示してｍｂｏｘ１０から指定されたメッセージの指定されたパートのデータを取得させる。メッセージ取得部２６ｃはｍｂｏｘ１０からのデータを取得すると、メッセージ解析部２２に指示して、取得したメッセージの解析および必要があればファイル形式変換部２４にファイル形式を変換させ、応答構成部２６ｄに指示してＩＭＡＰ４サーバ２１の応答に対応する応答メッセージを生成させ、送受信部２６ａを介して通常メール処理部６１に送信させる。このような動作により、この情報通信システムでは、携帯電話端末装置４０側にＩＭＡＰ４プロトコルを実装していなくても、メッセージのパート毎に受信，転送，削除等の処理を行うことができるようになっている。

（効果）
以上説明したように、この情報通信システムでは、ユーザ端末能力保持部２３に保持されている携帯電話端末装置４０の能力に応じて、メッセージに添付されているデータファイルの形式を、携帯電話端末装置４０の能力に応じて再生可能な形式に変換することができる。

このため、携帯電話端末装置４０側でデータファイルを再生することができる可能性を高め、携帯電話端末装置４０側で再生できない場合に他のアドレスに転送する等の操作の必要性を低減させることができる。従って、無駄なトラフィックの低減にも寄与することができる。無用なトラフィックを低減させることにより、ユーザ側の通信費用の負担の低減にも寄与することができる。

また、この情報通信システムでは、新たなデータファイルの形式及び拡張子が増加した場合でも、メッセージ解析部２２が保持している上述の拡張子変換テーブルを変更し、ファイル形式変換部２４における変換処理の選択を調整すれば、メッセージに添付されているデータファイルを適切な形式に変換することができる。従って、データファイルの形式の増加にも容易に対応することができる。

さらに、この情報通信システムでは、受信通知に添付ファイルを個別に指定可能な情報が含まれているため、ユーザが必要な添付ファイルの受信のみを選択することができ、無駄なトラフィックの低減に寄与することができる。また、携帯電話端末装置４０から要求し得る添付ファイルは、上述のように、当該携帯電話端末装置４０によって再生可能な形式に変換されているため、受信するまで再生できないことが解らないといった状況の発生を低減させることができる。

（変形例１）
また、例えばメールサーバ２０側でメッセージに添付されているデータファイルの内容が、拡張子あるいはファイル形式に従って正当であるか否かを確認するようにしてもよい。例えばファイルのヘッダ情報を元に、画像ファイルであれば正常に表示できるか否か、サウンドファイルであれば正常に再生できるか否か等を確認する。これにより、例えば拡張子あるいはファイル形式が適切でないデータファイルによって携帯電話端末装置４０が誤動作する可能性を低減させることができる。

（変形例２）
また、例えば上述の図３に示す端末テーブル２３ｂでは、機種ＩＤのみを管理するようになっていたが、機種のバージョン毎に仕様が若干異なる場合がある。このため、端末テーブル２３ｂにおいて、携帯電話端末装置４０のバージョン毎に能力を管理するようにしてもよい。これにより、同一機種の異なるバージョンにおける能力の管理を行うことができる。

（変形例３）
ところで、上述の実施例では、上述のように、機種ＩＤ毎に機種毎に一律にメッセージに添付されているデータファイルの形式の変換を行うようにしていたが、例えば携帯電話端末装置４０毎にユーザが希望する形式に変換するようにしてもよい。

このためには、ユーザ端末能力保持部２３に、例えば図１１に示すように、アドレス毎に希望する形式を保持するテーブルを設け、予めユーザが希望する形式を登録しておくようにする。ファイル形式変換部２４は、メッセージの宛先アドレス毎に添付されているデータファイルの形式の変換を行う。これにより、例えばユーザがデータファイルのサイズが小さくなるように形式を設定しておけば、受信するデータ量を低減させることができる。

静止画のデータファイルのサイズを低減させるには、例えば画面サイズを縮小する（図１２）、減色する（図１３）、画像フォーマットの圧縮率を上げる、すなわち、画質を劣化させる（図１４）等の方法がある。また、音声のデータファイルのサイズを低減させるには、ステレオからモノラルへ変換する（図１５）、サンプリングレートを落とす（図１６）、音声フォーマットの圧縮率を上げる、すなわち、音質を劣化させる等の方法がある。また、動画から複数の静止画と音声とに分けたり、異なる静止画像フォーマット間の変換・異なる動画フォーマット間の変換・異なる音声フォーマット間の変換を行ったりするようにしてもよい。

このような動作を実現するためには、例えばユーザ端末能力保持部２３で図１１の情報を保持し、ユーザ毎に図１１の情報を変更可能なウェブサーバを設ける。このウェブサーバはユーザ端末能力保持部２３と接続されており、携帯電話端末装置４０の中のブラウザ７０からアクセス可能とし、ユーザからの指示に応じて図１１の情報を変更する。

（変形例４）
上述の実施例の説明では、ＰＤＣ（パーソナルデジタルセルラ）方式のようなデジタル移動体通信網を想定していたが、例えば図１７に示すように、Ｗ−ＣＤＭＡ方式等の第３世代のデジタル移動体通信網においても本発明を適用することができる。

ＰＤＣ方式では、携帯電話端末装置４０とアドレスが１対１で対応していたため、上述の実施例のように、アドレスから携帯電話端末装置４０の能力（製造メーカ、装置種別、装置仕様等）を知ることができた。

しかしながら、第３世代のデジタル移動体通信網では、加入者識別子（ＵＳＩＭ）９９と携帯電話端末装置（ＵＥ）９０が分離可能に構成されており、ユーザが加入者識別子（ＵＳＩＭ）９９と携帯電話端末装置（ＵＥ）９０を自由に組み合わせることができるようになっている。

このため、第３世代のデジタル移動体通信網では、リアルタイム又は移動体通信網に接続される際に携帯電話端末装置（ＵＥ）９０の情報（ＩＭＥＩ）を取得する手段が必要となる。方式としてはいくつか考えられるが、メールデータおよびメッセージに添付された添付ファイル情報を情報通信端末装置（ＵＥ）９０に通知する前にＨＬＲ（加入者位置登録）８９を参照し、情報通信端末装置（ＵＥ）９０の能力（製造メーカ、装置種別、装置仕様）を特定する方式が考えられる。

例えば、加入者識別子（ＵＳＩＭ）９９の中のユーザＩＤ（ＩＭＳＩ、3GPP TS29.002(R99)，http://www.3gpp.org/ftp/Specs/1999-12/23_series/23003-330.zip参照）の他に端末電話端末装置（ＵＥ）９０の情報（ＩＭＥＩ、3GPP TS22.016(R99)，http://www.3gpp.org/ftp/Specs/1999-12/22_series/22016-310.zip参照）がＨＬＲ８９に通知されており、ユーザ端末能力保持部２３’は、これを共通線信号方式である移動体応用部（ＭＡＰ）プロトコル（3GPP TS29.002(R99)，http://www.3gpp.org/ftp/Specs/1999-12/29_series/29002-332.zip参照）で取得する。

また、ユーザ端末能力保持部２３’には、図１８に示すように、アドレスとユーザＩＤ（ＩＭＳＩ）の対応を示すテーブル２３ａ’と、携帯電話端末装置（ＵＥ）９０の情報（ＩＭＥＩ）と能力の対応を示すテーブル２３ｂ’が設けられている。

ファイル形式変換部２４は、テーブル２３ａ’を参照してメッセージの宛先に対応するユーザＩＤ（ＩＳＭＩ）を取得し、取得したＩＳＭＩに対応するＩＭＥＩをＨＬＲ８９から取得する。さらに、ファイル形式変換部２４は、テーブル２３ｂ’を参照してＨＬＲ８９から取得したＩＭＥＩに対応する携帯電話端末装置９０の能力を示す情報を取得する。

この取得した携帯電話端末装置９０の能力を示す情報を用いることにより、上述の実施例と同様に、メッセージに添付されたデータファイルを携帯電話端末装置４０の能力に応じた形式に変換して提供することができる。

本発明の一実施例に係る情報通信システムの構成例を示す図である。 前記情報通信システムで伝送されるメッセージの例を示す図である。 前記情報通信システムを構成するメールサーバのユーザ端末能力保持部に保持されるテーブルの一例を示す図である。 変換テーブルの一例を示す図である。 ファイル形式変換部の構成例を示す図である。 メッセージの受信通知及び携帯電話端末装置に対するメッセージの供給処理の一例を示すシーケンス図である。 受信通知によって通知される情報の一例を示す図である。 携帯電話端末装置の表示部に表示される画像の一例を示す図である。 ファイルの形式判定処理の一例を示すフローチャートである。 ファイルの形式判定処理の一例を示すフローチャートである。 メッセージ提供部の構成例を示す図である。 ユーザ端末能力保持部に保持されるテーブルに追加される情報の一例を示す図である。 画像のデータファイルのサイズの低減処理の一例を示す図である。 画像のデータファイルのサイズの低減処理の一例を示す図である。 画像のデータファイルのサイズの低減処理の一例を示す図である。 音声のデータファイルのサイズの低減処理の一例を示す図である。 音声のデータファイルのサイズの低減処理の一例を示す図である。 本発明に係る情報通信システムの他の構成例を示す図である。 ユーザ端末能力保持部に保持されるテーブルの一例を示す図である。

符号の説明

１０ ｍｂｏｘ１０
１１，１２ ユーザ領域
１１ａ，１１ｂ メッセージ
２０ メールサーバ
２２ メッセージ解析部
２３ ユーザ端末能力保持部
２４ ファイル形式変換部
２５ 通知部
３０ 移動体通信網
４０ 携帯電話端末装置
６１ 通常メール処理部
６２ ＳＭＳ処理部

Claims (3)

1. 情報通信端末装置の機種を示す機種ＩＤ毎に利用可能なデータファイルの形式を示す情報を保持する端末能力保持テーブルと、
   電子メールサービスの提供先の情報通信端末装置の宛先毎に前記機種ＩＤを保持するアドレステーブルと、
   受信したメッセージ（受信メッセージ）のＭＩＭＥ構造を検出する構造検出手段と、
   受信メッセージに添付されているデータファイルの形式を検出する形式検出手段と、
   メッセージを受信すると、前記アドレステーブルを参照して前記受信メッセージの宛先に対応する機種ＩＤを取得し、該取得した機種ＩＤに応じて前記端末能力保持テーブルを参照して当該宛先の情報端末装置で利用可能なデータファイルの形式を示す情報を取得し、前記形式検出手段が検出したデータファイルの形式が当該データファイルが添付されている受信メッセージの宛先の情報通信端末装置において利用可能な形式か否かを判定する判定手段と、
   該判定手段の判定結果に応じて、当該データファイルが当該情報通信端末装置において利用可能な形式でない場合に、データファイルの変換を行う変換手段に、前記データファイルを当該情報通信端末装置において利用可能な形式に変換させる変換制御手段と、
   前記変換手段によって変換された前記データファイルの形式を示す通知拡張子を選択する通知拡張子選択手段と、
   前記構造検出手段が検出したＭＩＭＥ構造と前記通知拡張子選択手段が選択した通知拡張子を含む受信通知をショートメッセージにより前記情報通信端末装置に送信する受信通知手段と、
   前記受信通知を受信した前記情報通信端末装置からの前記ＭＩＭＥ構造のパートを示す情報を含む送信要求に応じて要求されたパートに対応する前記データファイルを送信する送信手段と
   を備えることを特徴とするメールサーバ装置。
2. 第三世代デジタル情報通信網において情報通信端末装置毎に割り当てられた識別情報の範囲毎に利用可能なデータファイルの形式を示す情報を保持する端末能力保持テーブルと、
   電子メールの提供先の宛先毎にユーザのユーザＩＤを保持するアドレステーブルと、
   受信したメッセージ（受信メッセージ）のＭＩＭＥ構造を検出する構造検出手段と、
   受信メッセージに添付されているデータファイルの形式を検出する形式検出手段と、
   メッセージを受信すると、前記アドレステーブルを参照して前記受信メッセージの宛先に対応するユーザＩＤを取得し、該取得したユーザＩＤに対応する情報通信端末装置の前記識別情報を加入者位置登録を参照して取得し、該取得した識別情報に応じて前記端末能力保持テーブルを参照して当該宛先に対応する情報通信端末装置で利用可能なデータファイルの形式を示す情報を取得し、前記形式検出手段が検出したデータファイルの形式が当該データファイルが添付されている受信メッセージの宛先に対応する情報通信端末装置において利用可能な形式か否かを判定する判定手段と、
   該判定手段の判定結果に応じて、当該データファイルが当該情報通信端末装置において利用可能な形式でない場合に、データファイルの変換を行う変換手段に、前記データファイルを当該情報通信端末装置において利用可能な形式に変換させる変換制御手段と、
   前記変換手段によって変換された前記データファイルの形式を示す通知拡張子を選択する通知拡張子選択手段と、
   前記構造検出手段が検出したＭＩＭＥ構造と前記通知拡張子選択手段が選択した通知拡張子を含む受信通知をショートメッセージにより前記情報通信端末装置に送信する受信通知手段と、
   前記受信通知を受信した前記情報通信端末装置からの前記ＭＩＭＥ構造のパートを示す情報を含む送信要求に応じて要求されたパートに対応する前記データファイルを送信する送信手段と
   を備えることを特徴とするメールサーバ装置。
3. 情報通信端末装置の機種を示す機種ＩＤ毎に利用可能なデータファイルの形式を示す情報を保持する端末能力保持テーブルと、電子メールサービスの提供先の情報通信端末装置の宛先毎に前記機種ＩＤを保持するアドレステーブルと、受信したメッセージ（受信メッセージ）のＭＩＭＥ構造を検出する構造検出手段と、受信メッセージに添付されているデータファイルの形式を検出する形式検出手段と、メッセージを受信すると、前記アドレステーブルを参照して前記受信メッセージの宛先に対応する機種ＩＤを取得し、該取得した機種ＩＤに応じて前記端末能力保持テーブルを参照して当該宛先の情報端末装置で利用可能なデータファイルの形式を示す情報を取得し、前記形式検出手段が検出したデータファイルの形式が当該データファイルが添付されている受信メッセージの宛先の情報通信端末装置において利用可能な形式か否かを判定する判定手段と、該判定手段の判定結果に応じて、当該データファイルが当該情報通信端末装置において利用可能な形式でない場合に、データファイルの形式の変換を行う変換手段に、前記データファイルを当該情報通信端末装置において利用可能な形式に変換させる変換制御手段と、前記変換手段によって変換された前記データファイルの形式を示す通知拡張子を選択する通知拡張子選択手段と、前記構造検出手段が検出したＭＩＭＥ構造と前記通知拡張子選択手段が選択した通知拡張子を含む受信通知をショートメッセージにより前記情報通信端末装置に送信する受信通知手段と、前記受信通知を受信した前記情報通信端末装置からの前記ＭＩＭＥ構造のパートを示す情報を含む送信要求に応じて要求されたパートに対応する前記データファイルを送信する送信手段とを有するメールサーバ装置
   を備えることを特徴とする情報通信システム。

Images