JP2006072467A - 電子メールの格納方法，格納システム，電子メールサーバおよび変換処理部 - Google Patents

Abstract

【課題】 利用可能形式(フォーマット)，通信速度，メモリ容量，データ転送量などに制限がある端末であっても，画像ファイル，動画ファイル，ＭＩＤＩファイルなどの添付ファイルを受信できるようにする。
【解決手段】 本発明の電子メールの格納方法は，ユーザーアカウント毎に予め登録されたユーザーディレクトリ情報に基づいて，受信端末プロファイルに予め登録されたプロファイル情報を取得し，取得したプロファイル情報に基づいて受信した電子メールに変換処理を施す必要であるか否かを判定する。そして，変換処理が必要でない電子メールの場合はそのままメールボックスに格納する。また，変換処理が必要である電子メールの場合は取得したプロファイル情報に基づいて受信端末に対応するフォーマットおよびサイズになるように変換し，変換された電子メールをメールボックスに格納する。
【選択図】 図１

Description

本発明は，送信端末から送信された添付ファイルを有する電子メールをメールボックスに格納し，当該メールボックスに格納された添付ファイルを有する電子メールを受信端末が受信できるようにした電子メールの格納方法および格納システムに関する。

近年，電子メール機能を備えた携帯電話機，ＰＨＳ，ＰＤＡなどの携帯通信端末（ＭＳ：Mobile Station）が実用化され，コミュニケーション手段としての地位が確立されるようになった。このような携帯通信端末（ＭＳ）での電子メールの送受信は以下のようにして行われる。まず，電子メールの送信者が受信者宛に電子メールを送信すると，その電子メールは携帯電話網に設置されたメールサーバーのメールボックスに格納される。すると，ショートメッセージサービスセンタ（ＳＭＳＣ）が当該メールを受信した旨の通知を当該メールの受信者宛に送信するので，当該メールの受信者は当該メールサーバーのメールボックスに格納された電子メールを携帯通信端末にダウンロードして，電子メールを受信するようにしている。

ところで，携帯通信端末には様々の機種があって，その機種に応じて利用できるサービスが異なったり，対応するフォーマット（コンテンツ）やサイズも異なっている。このため，送信者が受信側の携帯通信端末の機種や，対応するフォーマット（コンテンツ）やサイズなどを知らないで，添付ファイルを有する電子メールの送信を行うと，受信側の携帯通信端末は当該電子メールに添付された添付ファイルを受信できないという問題を生じた。また，添付ファイルの受信を行っても，受信側の携帯通信端末がファイル(コンテンツ)に対応していないため，表示など利用できないという問題もあった。

そこで，メール送信の過程でウエッブホスティング（ウエッブスペースへのアップロード）を事前に行い，この電子メールに添付された添付ファイルを当該メールの受信端末に対応するような変換を行って，どのような携帯通信端末（ＭＳ）でも受信できるようにした電子メールの格納システムが非特許文献１，２あるいは特許文献１にて提案されるようになった。これらの非特許文献１，２あるいは特許文献１にて提案された電子メールの格納システムにおいては，ウエッブへのアクセス時に受信側の携帯通信端末（ＭＳ）の端末情報（ユーザーエージェント）に基づいて，この電子メールに添付された添付ファイルを当該端末で受信できるように変換処理を行うというというものである。

このような電子メールの格納システムの一例を図示すると，図１９に示すようになる。図１９において，この電子メールの格納システム７０は，メールサーバー７１と，メールボックス７２と，ＩＭＡＰ（Internet Message Access Protocol）／ＰＯＰ（Post Office Protocol）サーバー７３と，ディレクトリーサーバー７４と，ウエッブスペース７５と，ウエッブサーバー７６と，変換機能部７７と，受信端末プロファイル７８とを備えている。なお，ディレクトリーサーバー７４にはユーザーディレクトリー７４ａが接続されており，変換機能部７７には変換エンジン７７ａが接続されている。

このような電子メールの格納システム７０の動作を説明すると以下のようになる。まず，送信端末（ＭＳ−１）が所定の文字数のテキストデータのみの電子メールを送信すると，この携帯電話網に設置されたメールサーバー７１が当該電子メールを受信する。すると，このメールサーバー７１は受信端末（ＭＳ−２）のアカウントがユーザーディレクトリ７４ａに存在するか否かをディレクトリサーバー７４に問い合わせる。

その結果，受信端末（ＭＳ−２）が管理するアカウントであれば，受信した電子メールをメールボックス７２に格納する。すると，図示しないショートメッセージサービスセンタ（ＳＭＳＣ）が当該メールを受信した旨の通知を当該メールの受信端末（ＭＳ−２）に送信する。これにより，受信端末（ＭＳ−２）はＩＭＡＰ／ＰＯＰサーバー７３にアクセスして，メールボックス７２に格納された電子メールを受信することができるようになる。

一方，送信端末（ＭＳ−１）が写真などの添付ファイル（コンテンツ）を有する電子メールを送信し，当該電子メールの受信端末（ＭＳ−２）が管理するアカウントであれば，メールサーバー７１は当該電子メールを受信する。すると，メールサーバー７１は受信した添付ファイル（コンテンツ）を有する電子メールをウエッブスペース７５に格納するとともに，メールボックス７２にウエッブサーバー７６へアクセスするためのＵＲＬを保存する。そして，ショートメッセージサービスセンタ（ＳＭＳＣ）が当該メールを受信した旨の通知を当該メールの宛先となる受信端末（ＭＳ−２）に送信する。これにより，受信端末（ＭＳ−２）はＩＭＡＰ／ＰＯＰサーバー７３にアクセスして，メールボックス７２に格納されたＵＲＬを取得する。

そして，受信端末（ＭＳ−２）が，取得したＵＲＬに基づいてウエッブサーバー７６にアクセスすると，ウエッブサーバー７６はウエッブスペース７５に格納された当該受信端末（ＭＳ−２）宛の添付ファイル（コンテンツ）を有する電子メールを受信端末（ＭＳ−２）に送信する。これにより，当該メールを受信端末（ＭＳ−２）は受信できるようになる。この場合，受信端末（ＭＳ−２）がウエッブサーバー７６にアクセスすると，受信端末（ＭＳ−２）はこの端末を識別するためのユーザーエージェントをウエッブサーバー７６に通知する。これにより，ウエッブサーバー７６はウエッブスペース７５からメールを取得し，これを変換機能部７７に送信して変換要求を行う。

この変換要求に応じて変換機能部７７は，受信端末プロファイル７８と受信したユーザーエージェントから，受信端末（ＭＳ−２）が受信可能なフォーマット（コンテンツ）やサイズを決定し，変換エンジン７７ａにより受信可能なフォーマット（コンテンツ）やサイズになるような変換処理を行う。変換処理後，ウエッブサーバー７６は変換された電子メールのダウンロードを受信端末（ＭＳ−２）に行う。これにより，受信端末（ＭＳ−２）は電子メールを受信できるようになるとともに，その添付ファイルが見られるようになる。
大和哲,「ケータイ用語の基礎知識」,第９５回：ｉショットとは,［online］,2002/06/11,［平成１６年７月２３日検索］，インターネット〈URL:http://k-tai.impress.co.jp/cda/article/keyword/9754.html〉 荒田淳子,「写真付きメール送受信攻略法」,Ｊ−フォン写メール編,［online］,2002/09/12,［平成１６年７月２３日検索］，インターネット〈URL:http://k-tai.impress.co.jp/cda/article/review/10949.html〉 特開２００４−５６６６２号公報

ところで，通常，電子メールの受信は１回の受信操作で済むようになされているが，上述した図１９に示すようなシステムにおいては，ホスティングされたＵＲＬを受信した後に，ウエッブサーバー７６にアクセスする必要がある。このため，メールの受信動作が不便であるという問題を生じた。また，メールを受信した旨の通知を受信する度に，ウエッブサーバー７６にアクセスする必要がある。このため，メールを受信するための動作が面倒であるという問題を生じた。

さらに，メールボックスへの格納時に電子メールの変換を行うためには，この時点で受信端末が受信可能なフォーマット（コンテンツ）やサイズ情報が必要となる。ところが，受信端末がアクセスするまでは，当該受信端末が受信可能なフォーマット（コンテンツ）やサイズなどの情報は不明である。このため，メールボックスへの格納時に電子メールの変換処理を行うことができないという問題を生じた。

そこで，本発明は上記問題点を解決するためになされたものであって，利用可能形式(フォーマット)，通信速度，メモリ容量，データ転送量などに制限がある通信端末であっても，これらの制限に係わらず，画像ファイル，動画ファイル，ＭＩＤＩファイル（ＭＩＤＩは登録商標）等のデジタルコンテンツなどの添付ファイルを受信できるようにすることを目的とする。

上記目的を達成するため，本発明の電子メールの格納方法は，ユーザーアカウント毎に予め登録されたユーザーディレクトリ情報に基づいて，受信端末プロファイルに予め登録されたプロファイル情報を取得し，取得したプロファイル情報に基づいて受信した電子メールに変換処理を施す必要があるか否かを判定する。そして，変換処理が必要でない電子メールの場合はそのままメールボックスに格納する。一方，変換処理が必要である電子メールの場合は取得したプロファイル情報に基づいて受信端末が受信可能なフォーマット（コンテンツ）およびサイズになるように変換し，変換された電子メールをメールボックスに格納するようにしたことを特徴とする。

このように，取得したプロファイル情報に基づいて受信端末が受信可能なフォーマット（コンテンツ）およびサイズになるように変換し，変換された電子メールをメールボックスに格納するようにすると，利用可能形式(フォーマット)，通信速度，メモリ容量，データ転送量などに制限がある通信端末であっても，これらの制限に係わらず添付ファイルを受信できるようになる。

この場合，ユーザーディレクトリ情報は受信端末の機種情報，コンテンツリスト，変換シナリオのいずれか１つを含む情報であるのが望ましい。また，複数の変換シナリオが用意されており，受信端末のユーザーが予め選択して登録された変換シナリオに基づいて受信した電子メールを変換処理するのが望ましい。また，プロファイル情報は変換要素，受信可能サイズ，受信可能フォーマットのいずれか１つを含む情報であるのが望ましい。さらに，電子メールの変換時に当該受信端末の制約により不必要な情報（例えば，画像であれば，Ｅｘｉｆ情報やサムネイル画像など）は削除するようするのが望ましい。

このような電子メールの格納方法を実現するためには，添付ファイルを有する電子メールを受信するメールサーバーと，受信端末のユーザーディレクトリ情報を格納するユーザーディレクトリと，受信端末のプロファイル情報を格納する受信端末プロファイルとを備えるようにする。そして，メールサーバーはユーザーディレクトリに格納されたユーザーアカウントに対応するユーザーディレクトリ情報と，受信端末プロファイルに格納されたプロファイル情報とを取得して，受信した電子メールに変換処理を施す必要があるか否かを判定する判定手段を備えるようにする。
これにより，判定手段により判定された結果，変換処理が必要でない電子メールの場合はそのままメールボックスに格納し，変換処理が必要である電子メールの場合は取得したプロファイル情報に基づいて受信端末が受信可能なフォーマットおよびサイズになるように変換し，変換された電子メールをメールボックスに格納できるようになる。

ついで，本発明の一実施の形態を図１〜図１８に基づいて説明するが，本発明はこの実施の形態に何ら限定されるものでなく，本発明の目的を変更しない範囲で適宜変更して実施することが可能である。なお，図１は，本発明の電子メール格納システムの概略構成を模式的に示すブロック図である。図２〜図６は，図１に示されたメールサーバーの処理動作の例を示すフローチャートである。図７はユーザーディレクトリの一例を示す図である。図８はコンテンツリストの一例を示す図であり，図８（ａ）は静止画に対応するコンテンツリストを示し，図８（ｂ）は動画に対応するコンテンツリストを示し，図８（ｃ）は着信メロディー（ＭＩＤＩファイル）に対応するコンテンツリストを示している。図９はコンテンツカテゴリリストを示している。図１０は受信端末プロファイルの一例を示す図である。図１１〜図１８は，変換例を模式的に示す図である。

図１に示すように，本発明の電子メール格納システム１０は，送信端末（ＭＳ−１）あるいは外部のメールサーバーから電子メールを受信するメールサーバー１１と，メールサーバー１１が受信した電子メールを格納するメールボックス１２と，メールボックス１２に格納された電子メールを受信端末（ＭＳ−２）に送信するＩＭＡＰ（Internet Message Access Protocol）／ＰＯＰ（Post Office Protocol）サーバー１３と，アカウントを管理するディレクトリーサーバー１４とを備えている。

また，本発明の電子メール格納システム１０は，受信した電子メールを所定のフォーマットおよび所定のサイズになるような変換処理を行う変換機能部１５と，受信端末（ＭＳ−２）の機種毎に予め登録されたプロファイルを格納する受信端末プロファイル１７とを備えている。なお，ディレクトリーサーバー１４には受信者のアカウント（例えば，電話番号など）に対応した受信端末（ＭＳ−２）の機種情報やコンテンツリストや変換シナリオなどの情報を保存したユーザーディレクトリ１４ａが接続されており，変換機能部１５には変換エンジン１６が接続されている。

ここで，メールサーバー１１は，図示しないＣＰＵ，ＲＡＭ，ＲＯＭ，ハードディスクドライブ（ＨＤＤ）や光ディスクドライブ等からなる記憶装置，あるいはシステムバスなどからなるハードウェア上で所定のプログラムを実行することにより，受信端末（ＭＳ−２）のユーザーに付与されているメールアドレス宛の電子メールを受信したり，この電子メールを転送したり，電子メールを送信したりする各種の機能を実現している。このようなプログラムとしては，ＭＴＡ（Message Transfer Agent）やＭＲＡ（Mail Retrieval Agent）等のソフトウェアが用いられる。

そして，このメールサーバー１１を所定の手順に従って動作させるためのプログラムはＲＯＭや記憶装置に記憶されており，必要に応じてＣＰＵやＲＡＭ上の作業エリアに呼び出されて実行される。なお，メールサーバー１１は１台のコンピュータシステムで構成してもいいし，複数のサーバ機能をそれぞれ受け持つ複数台のコンピュータをネットワークで結んで構成するようにしてもよい。

メールボックス１２はメールサーバー１１が受信した電子メールを一定期間（例えば，３０日間）だけ格納するデータベースである。この場合，受信端末（ＭＳ−２）からの配信要求に基づくＩＭＡＰ／ＰＯＰサーバー１３からの配信のリクエストを受け取ると，格納された電子メールをＩＭＡＰ／ＰＯＰサーバー１３に送信するようになされている。なお，ユーザーによるメールボックス操作による削除指示がなければ，一定期間（例えば，３０日間）経過後は，格納した電子メールデータを自動消去するようになされている。

ＩＭＡＰ／ＰＯＰサーバー１３は，上述したメールサーバー１１とほぼ同様なハードウェアで構成されており，受信端末（ＭＳ−２）からの電子メールの配信要求に基づいてメールボックス１２に格納された電子メールをメールボックス１２から受信して，これを受信端末（ＭＳ−２）に転送する機能を備えている。

ディレクトリーサーバー１４は，上述したメールサーバー１１とほぼ同様なハードウェアで構成されており，メールサーバー１１からの要求に応じて，ユーザーディレクトリ１４ａに予め格納された，受信端末（ＭＳ−２）のアカウント（例えば，電話番号など）に対応した機種情報やコンテンツリストや変換シナリオなどの情報をメールサーバー１１に送信する機能を備えている。この場合，ユーザーディレクトリ１４ａには，例えば，図７に例示するように，受信端末（ＭＳ−２）のアカウント（この場合は電話番号）に対応した機種情報や，コンテンツリストや，変換シナリオなどの情報が格納されている。また，ユーザーディレクトリ１４ａには，図８に示すように，コンテンツリストに対応した，静止画に対応するコンテンツの種別（ａ），動画に対応するコンテンツの種別（ｂ），着信メロディー（ＭＩＤＩファイル）に対応するコンテンツの種別（ｃ）などの情報が格納されている。また，ユーザーディレクトリ１４ａには，図９に示すように，コンテンツカテゴリリストも格納されている。

変換機能部１５は，上述したメールサーバー１１とほぼ同様なハードウェアで構成されており，メールサーバー１１からの要求に応じて，受信端末プロファイル１７に予め格納された各種の情報に基づいて，受信した電子メールを変換エンジン１６を用いて所定のフォーマットおよび所定のサイズになるような変換処理を行い，変換したファイルをメールサーバー１１に送信する機能を備えている。この場合，受信端末プロファイル１７には，例えば，図１０に例示するように，受信端末（ＭＳ−２）の機種毎に予め登録されたプロファイル（静止画に対する変換要素１，２，３および動画に対する変換要素１，２，３などの要素情報，受信可能サイズ情報など）が格納されている。

なお，受信可能サイズについては，次のような理由により予め決められている。携帯電話のネットワークを例にした場合，ＰＤＣ(Personal Digital Cellular)，または，２Ｇ(Second Generation)と呼ばれる世代の通信ネットワークにおいては，エア・インタフェースのデータ通信速度が９，６００ｂｐｓであるから，秒単位における転送バイト数は１，２００バイト／秒となる。このとき，一般的に呼接続の品質維持から導かれる許容継続通信時間は，およそ６秒であることから，６秒間で保障し得る総バイト量は１２００バイト×６秒で導かれる，７．２Ｋバイトとなる。データ転送時は，実データと共にヘッダ情報が付加され，一般的に総情報量の２０％程度を有することから，結果的に転送可能な情報総量（すなわち，受信端末が受信可能なサイズ）は，６Ｋバイトとされている。

また，ＰＤＣパケット方式，または，２．５Ｇ（2.5Generation）と呼ばれる世代の通信ネットワークでは，データ通信速度が２８．８Ｋｂｐｓとされているが，本方式はベスト・エフォート型の通信方式であるため実質的には２０Ｋｂｐｓ程度で保障する。ゆえに，前述の算出手順で導き出される実データの総バイト量を１２Ｋバイトとしている。さらに，今日の２．５Ｇのネットワークにおいては，ベスト・エフォート方式のエラーレート許容を改善し，受信可能サイズを３０Ｋバイトまで保障するようにしている。また，Ｗ−ＣＤＭＡ方式，または，３Ｇ(Third Generation)と呼ばれる世代の通信ネットワークでは，データ通信速度が３８４Ｋｂｐｓとされているが，２．５Ｇのネットワークと同様の算出手順で導き出される実データの総バイト量を２００Ｋバイトとしている。また，レガシーなＰＤＡだと，メモリー容量が数Ｍバイトと非常に小さなものがあり，1通あたりのメール容量が小さく規定されている。

ついで，上述のように構成される電子メール格納システムにおいて，図２〜図６のフローチャートを参照しながら，送信端末（ＭＳ−１）が添付ファイルを有する電子メールを受信端末（ＭＳ−２）宛に送信した場合のメールサーバー１１の電子メールの格納処理手順を以下に説明する。この場合，オペレータによる設定により，受信端末（ＭＳ−２）のアカウント（電話番号）に対応する機種の種別，コンテンツリストが，また，この受信端末（ＭＳ−２）を所有するユーザーの申し出により，採用する変換シナリオがユーザーディレクトリ１４ａにそれぞれ登録されているものとする。

なお，本実施形態においては，上述の変換シナリオは変換シナリオ１，変換シナリオ２，変換シナリオ３，変換シナリオ４の各シナリオが用意されており，ユーザーが選択した変換シナリオに基づいて電子メールの格納のための変換処理が行われるようになされている。この場合，変換シナリオ１においては，本文，添付ファイル（コンテンツ）の添付順序は変更しないで，全ての添付ファイルをできるだけ見られるような変換処理を行う。このため，後述する図３のフローチャートに示す変換シナリオ１の処理を行うこととなる。

また，変換シナリオ２においては，本文，添付ファイル（コンテンツ）の添付順序は変更しないで，全ての添付ファイルをできるだけ見られるような変換処理を行う。ただし，受信可能サイズを超えたものは削除し，空いた受信可能サイズ内で，できる限りきれいに（高解像度で）見られるような変換処理を行う。このため，後述する図４のフローチャートに示す変換シナリオ２の処理を行うこととなる。また，変換シナリオ３においては，本文，添付ファイル（コンテンツ）の添付順序は変更しないで，１番目の添付ファイル（コンテンツ）をできる限りきれいに（高解像度で）見られるような変換処理を行う。このため，後述する図５のフローチャートに示す変換シナリオ３の処理を行うこととなる。

さらに，変換シナリオ４においては，受信端末が受信可能なフォーマット（コンテンツ）を先頭へ移動させ，受信不能（サポートしていない）のフォーマット（コンテンツ）は後方へ移動させるように添付ファイル（コンテンツ）の添付順序を変更し，かつ，全ての添付ファイルをできる限り見られるような変換処理を行う。このため，後述する図６のフローチャートに示す変換シナリオ４の処理を行うこととなる。以下に，通常処理， 変換シナリオ１による処理，変換シナリオ２による処理，変換シナリオ３による処理，変換シナリオ４による処理の順で詳細に説明する。

１．通常の処理
まず，ステップＳ２１にて，メールサーバー１１が所定のプロトコル（この場合はＳＭＴＰ（Simple Mail Transfer Protocol）とする）により，送信端末（ＭＳ−１）あるいは外部のメールサーバーから電子メール（Ｆｒｏｍ，Ｔｏ，メール本文，添付ファイル（コンテンツ）からなる）を受信したとする。すると，ステップＳ２２にて，メールサーバー１１は，このメールの宛先（Ｔｏ）に応じたアカウント（電話番号）に対応した受信端末（ＭＳ−２）の各種情報（機種情報やコンテンツリストや変換シナリオなど：図７参照）をユーザーディレクトリ１４ａに格納されたデータベースからディレクトリサーバー１４を介して取得する。

また，ステップＳ２３にて，メールサーバー１１は，ステップＳ２２にて取得した受信端末（ＭＳ−２）の機種に対応するプロファイル（静止画に対する変換要素１，２，３，動画に対する変換要素１，２，３，受信可能サイズなど：図１０参照）を受信端末プロファイル１７に格納されたデータベースから変換機能部１５を介して取得する。ついで，ステップＳ２４に進め，ＲＦＣ（Request For Comment）の仕様に基づいたインターネットメールに関する規約に従った解析を実施する。この結果，電子メールのサイズ，添付されているファイルフォーマットとそのサイズなどの情報を取得する。

この後，ステップＳ２５にて，前のステップで電子メールの解析を行った結果に基づいて，受信した電子メールは変換が必要か否かの判定を行う。この場合，受信端末（ＭＳ−２）で対応していない（受信可能でない）フォーマット（コンテンツ）の添付ファイルが添付されておらず，かつ受信した電子メールのサイズ合計が受信可能サイズ以下であれば，ステップＳ２５にて「Ｎｏ」と判定して，次のステップＳ２７にて受信した電子メールをそのままメールボックス１２に格納する。

一方，受信端末（ＭＳ−２）で対応していない（受信可能でない）フォーマット（コンテンツ）の添付ファイルが添付されていたり，受信した電子メールのサイズ合計が受信可能サイズを超えていれば，ステップＳ２５にて「Ｙｅｓ」と判定して，次のステップＳ２６にて，ステップＳ２２にて取得した変換シナリオに基づいて，メールの変換処理を行った後，次のステップＳ２７にて変換後のメールをメールボックス１２に格納する。この場合，ステップＳ２２にて取得した変換シナリオが変換シナリオ１であると，図３のフローチャートに基づいて，変換シナリオ１の処理を行う。同様に，取得した変換シナリオが変換シナリオ２であると，図４のフローチャートに基づいて変換シナリオ２の処理を行い，変換シナリオ３であると図５のフローチャートに基づいて変換シナリオ３の処理を行い，変換シナリオ４であると図６のフローチャートに基づいて変換シナリオ４の処理を行う。

なお，受信した電子メールをメールボックス１２に格納すると，メールサーバー１１はショートメッセージサービスセンタ（ＳＭＳＣ）を介して当該メールを受信した旨の通知を受信端末（ＭＳ−２）に送信する。これにより，受信端末（ＭＳ−２）は所定のプロトコル（この場合は，ＩＭＡＰ／ＰＯＰとする）によりＩＭＡＰ／ＰＯＰサーバー１３にアクセスする。すると，ＩＭＡＰ／ＰＯＰサーバー１３は，メールボックス１２に格納されているメールからアクセスした受信端末（ＭＳ−２）のアカウント（電話番号）に対応するメールを受信する。これにより，受信端末（ＭＳ−２）は当該受信端末（ＭＳ−２）宛の変換処理済み，あるいは無変換の添付ファイル（コンテンツ）を有する電子メールを受信できるようになる。

２．変換シナリオ１の処理
図２のステップＳ２５にて「Ｙｅｓ」と判定し，かつステップＳ２２にて取得した変換シナリオが変換シナリオ１であると，図３のステップＳ３０にて，変換シナリオ１の変換処理を開始する。すると，ステップＳ３１において，受信した電子メールの添付ファイルのフォーマット（コンテンツ）がユーザーディレクトリ１４ａから取得したコンテンツリスト（図７，図８，図９参照）に対応していない場合は，対応するフォーマットに変換する。例えば，図７において，アカウントが「０９０−００００−０００１」の受信端末（ＭＳ−２）の静止画に対応するフォーマットは「ＪＰＧ」，「ＰＮＧ」（図８（ａ）参照）である。このため，この受信端末（ＭＳ−２）が，フォーマットが「ＢＭＰ」である添付ファイル（コンテンツ）を受信した場合は，変換機能部１５でＢＭＰ→ＪＰＧのファイルに変換される。

ここで，ファイル(コンテンツ)のフォーマットの変換を行った場合，フォーマットの特性により，サイズが縮小されることがある。例えば，ＪＰＧの場合は，ＢＭＰと比較して，通常品質を落とさない範囲で画像のサンプリングレートやクオリティ値といったパラメターが定められており，フォーマット変換により画像が圧縮される。この場合，次のステップＳ３１ａにてメールサイズの合計が受信端末（ＭＳ−２）の受信可能サイズ以下であるか否かの判断を行う。ここで，受信可能サイズ以下であれば，ステップＳ３１ａにて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進めて，変換後のメールをメールボックス１２に格納する。一方，受信可能サイズより大きいと，ステップＳ３１ａにて「Ｎｏ」と判定して，次のステップＳ３２に進める。

ついで，ステップＳ３２において受信端末プロファイル１７から取得（ステップＳ２３）した変換要素１を指定する。この後，ステップＳ３３にて，添付されている全ての添付ファイル（コンテンツ）を変換要素１に基づいて変換する。ついで，ステップＳ３４に進め，変換後の全サイズの合計が受信端末（ＭＳ−２）の受信可能サイズ（図１０参照）以下か否かの判定を行う。ここで，受信可能サイズ以下であれば，ステップＳ３４にて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進めて，変換後のメールをメールボックス１２に格納する。一方，受信可能サイズより大きいと，ステップＳ３４にて「Ｎｏ」と判定して，次のステップＳ３５にて，最後の変換要素であるか否か，即ち，次の変換要素があるか否かの判定を行う。ここで，次の変換要素がない場合は，ステップＳ３５にて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進めて，変換後のメールをメールボックス１２に格納する。

一方，次の変換要素がある場合は，ステップＳ３５にて「Ｎｏ」と判定して，次のステップＳ３６において受信端末プロファイル１７から取得（Ｓ２３）した次の変換要素（この場合は変換要素２となる）を指定した後，ステップＳ３３に戻る。そして，次の変換要素がなくなるまで上述のステップＳ３３〜ステップＳ３６までの処理を繰り返して実行する。なお，この変換シナリオ１の処理において，添付ファイルを指定の変換要素で変換する場合に，受信可能サイズをできる限り大きくするために受信端末（ＭＳ−２）に不要な情報（例えば，ＪＰＧのＥｘｉｆ情報やサムネイルなどの付加情報）は削除するようにするのが望ましい。

ここで，変換シナリオ１に基づくメールの変換例を図１１〜図１５に基づいて説明する。この場合，変換シナリオ１を採用するアカウント（電話番号は０９０−００００−０００１で，機種の種別がＳＨＡＪ０１のもの）の受信端末（ＭＳ−２）宛の添付ファイルを有する電子メールを受信した例について以下に説明する。

（１）第１変換例
まず，変換シナリオ１に基づく第１変換例を図１１（なお，図１１は第１変換例を模式的に示す図である）に基づいて説明する。この場合は，本文＋ヘッダは１Ｋで，６４０×４８０，３０Ｋ，２４万色の画像１と，６４０×４８０，３０Ｋ，２４万色の画像２からなる添付ファイルを有する電子メールを受信したものとする。図１１において，添付ファイル（画像１，２）のフォーマット（コンテンツ）はＪＰＧであり，このアカウント（０９０−００００−０００１）のコンテンツリストはＧ（図７参照）であるので，図８より対応するコンテンツ（ＪＰＧ）であることが分かる。従って，ステップＳ３１でのフォーマット（コンテンツ）の変換は行われないこととなる。一方，受信したメールサイズは本文＋ヘッダが１Ｋで，画像１のサイズは３０Ｋで，画像２のサイズは３０Ｋであるので，メールの合計のサイズは６１Ｋとなる。そこで，変換要素１に基づいて１回目の変換を行うこととなる。

この機種に対応する変換要素１（図１０（ａ）のＳＨＡＪ０１の静止画の変換要素１）により，画像１および画像２はともに３２０×２４０，１５Ｋ，２４万色に変換する。これにより，メールの合計のサイズは３１Ｋとなるので，この機種の受信可能サイズである３０Ｋを超えるので，静止画の変換要素２に基づいて２回目の変換を行うこととなる。この２回目の変換により，メールの合計のサイズは２１Ｋとなるので，これを採用して，変換されたファイル（コンテンツ）がメールボックス１２に格納されることとなる。

（２）第２変換例
ついで，変換シナリオ１に基づく第２変換例を図１２（なお，図１２は第２変換例を模式的に示す図である）に基づいて説明する。この場合は，本文＋ヘッダは１Ｋで，フォーマット（コンテンツ）はＢＭＰで，６４０×４８０，６０Ｋ，２４万色の画像１と，フォーマット（コンテンツ）はＢＭＰで，６４０×４８０，６０Ｋ，２４万色の画像２からなる添付ファイルを有する電子メールを受信したものとする。このアカウント（０９０−００００−０００１）のコンテンツリストはＧ（図７参照）であるので，図８より対応するコンテンツ（ＪＰＧ，ＰＮＧ）でないことが分かる。従って，ステップＳ３１でのフォーマット（コンテンツ）の変換が行われることとなり，画像１は６４０×４８０，３０Ｋ，２４万色のＪＰＧのフォーマット（コンテンツ）に変換され，画像２は６４０×４８０，３０Ｋ，２４万色のＪＰＧのフォーマット（コンテンツ）に変換される。

一方，ＪＰＧのフォーマット（コンテンツ）に変換されたファイルサイズは本文＋ヘッダが１Ｋで，画像１のサイズは３０Ｋで，画像２のサイズは３０Ｋであるので，変換後のファイルサイズの合計のサイズは６１Ｋとなる。このため，ステップＳ３１ａでサイズの判定が行われるが，この端末の受信可能サイズは３０Ｋ（図１０参照）であるので，変換要素１に基づいて１回目の変換を行うこととなる。この機種に対応する変換要素１（図１０（ａ）のＳＨＡＪ０１の静止画の変換要素１）により，画像１および画像２はともに３２０×２４０，１５Ｋ，２４万色に変換する。これにより，メールの合計のサイズは３１Ｋとなるので，この機種の受信可能サイズである３０Ｋを超えることとなる。このため，静止画の変換要素２に基づいて２回目の変換を行う。この２回目の変換により，メールの合計のサイズは２１Ｋとなるので，これを採用して，変換されたファイル（コンテンツ）がメールボックス１２に格納されることとなる。

（３）第３変換例
ついで，変換シナリオ１に基づく第３変換例を図１３（なお，図１３は第３変換例を模式的に示す図である）に基づいて説明する。この場合は，本文＋ヘッダは１Ｋで，フォーマット（コンテンツ）はＢＭＰで，６４０×４８０，６０Ｋ，２４万色の画像１と，フォーマット（コンテンツ）は３ｇｐで，１７６×１４４，３０ｆｐｓ，６４ｋｂｐｓ，６０Ｋの動画１からなる添付ファイルを有する電子メールを受信したものとする。このアカウント（０９０−００００−０００１）のコンテンツリストはＧ（図７参照）であるので，図８より，静止画においては対応するコンテンツ（ＪＰＧ，ＰＮＧ）でないことが分かり，動画においては対応するコンテンツ（３ｇｐ，ｎｏａ）であることが分かる。従って，ステップＳ３１で，画像１についてはフォーマット（コンテンツ）の変換が行われ，動画１についてはフォーマット（コンテンツ）の変換が行われない。そして，画像１は６４０×４８０，３０Ｋ，２４万色のＪＰＧのフォーマット（コンテンツ）に変換される。

一方，ファイルサイズは本文＋ヘッダが１Ｋで，ＪＰＧのフォーマット（コンテンツ）に変換された画像１のサイズは３０Ｋで，動画１のサイズは６０Ｋであるので，ファイルサイズの合計のサイズは９１Ｋとなる。このため，ステップＳ３１ａでサイズの判定が行われるが，この端末の受信可能サイズは３０Ｋ（図１０参照）であるので，変換要素１に基づいて１回目の変換を行うこととなる。この機種に対応する変換要素１（図１０（ａ）のＳＨＡＪ０１の静止画の変換要素１および図１０（ｂ）のＳＨＡＪ０１の動画の変換要素１）により，画像１は３２０×２４０，１５Ｋ，２４万色に変換し，動画１は１７６×１４４，１５ｆｐｓ，６４ｋｂｐｓ，３０Ｋに変換する。

これにより，メールの合計のサイズは４６Ｋとなるので，この機種の受信可能サイズである３０Ｋを超えることとなる。このため，静止画および動画の変換要素２に基づいて，図１３に示すように２回目の変換を行うこととなる。この２回目の変換によっても，メールの合計のサイズは３５Ｋで３０Ｋ以下にならないため，静止画および動画の変換要素３に基づいて，３回目の変換を行うこととなる。これにより，図１３によりメールの合計のサイズは２１Ｋとなるので，これを採用して，変換されたファイル（コンテンツ）がメールボックス１２に格納されることとなる。

（４）第４変換例
ついで，変換シナリオ１に基づく第４変換例を図１４（なお，図１４は第４変換例を模式的に示す図である）に基づいて説明する。この場合は，本文＋ヘッダは１Ｋで，フォーマット（コンテンツ）はＢＭＰで，６４０×４８０，６０Ｋ，２４万色の画像１と，フォーマット（コンテンツ）はｍｉｄで，５Ｋの着信メロディーと，フォーマット（コンテンツ）は３ｇｐで，１７６×１４４，３０ｆｐｓ，６４ｋｂｐｓ，６０Ｋの動画１からなる添付ファイルを有する電子メールを受信したものとする。

このアカウント（０９０−００００−０００１）のコンテンツリストはＧ（図７参照）であるので，図８（ａ）より，静止画においては対応するコンテンツ（ＪＰＧ，ＰＮＧ）でないことが分かる。また，図８（ｂ）より，動画においては対応するコンテンツ（３ｇｐ，ｎｏａ）であることが分かる。また，図８（ｃ）より，着信メロディーにおいては対応するコンテンツ（ｍｍｆ，ｓｍｄ）でないことが分かる。したがって，画像１および着信メロディー（ＭＩＤＩファイル）についてはフォーマット（コンテンツ）の変換（ステップＳ３１）が行われ，動画１についてはフォーマット（コンテンツ）の変換が行われない。そして，画像１はフォーマット（コンテンツ）がＪＰＧで，６４０×４８０，３０Ｋ，２４万色に変換され，着信メロディー（ＭＩＤＩファイル）はフォーマット（コンテンツ）がｍｍｆに変換される。

一方，ファイルサイズは本文＋ヘッダが１Ｋで，ＪＰＧに変換された画像１のサイズは３０Ｋで，ｍｍｆに変換された着信メロディーのサイズは５Ｋで，動画１のサイズは６０Ｋであるので，合計のサイズは９６Ｋとなる。そこで，上述と同様に，受信可能なサイズか否かの判定をした後，図１４に示すように，この機種の受信可能サイズである３０Ｋ以下になるように，変換要素１に基づいて１回目の変換を行い，変換要素２に基づいて２回目の変換を行い，変換要素３に基づいて３回目の変換を行うこととなる。これにより，図１４に示すように，３回目の変換によりメールの合計のサイズは２６Ｋとなり，これが採用されて，変換されたファイル（コンテンツ）がメールボックス１２に格納されることとなる。

（５）第５変換例
ついで，変換シナリオ１に基づく第５変換例を図１５（なお，図１５は第５変換例を模式的に示す図である）に基づいて説明する。この場合は，本文＋ヘッダは１Ｋで，フォーマット（コンテンツ）はＢＭＰで，６４０×４８０，６０Ｋ，２４万色の画像１と，フォーマット（コンテンツ）はｚｉｐで，３０Ｋのその他の添付ファイルを有する電子メールを受信したものとする。このアカウント（０９０−００００−０００１）のコンテンツリストはＧ（図７参照）であるので，図８（ａ）より，静止画においては対応するコンテンツ（ＪＰＧ，ＰＮＧ）でないことが分かる。また，その他のｚｉｐは図８に示されないコンテンツであることが分かる。したがって，画像１については，６４０×４８０，３０Ｋ，２４万色のＪＰＧに変換され，ｚｉｐについては無変換のままとなる。

一方，ファイルサイズは本文＋ヘッダが１Ｋで，ＪＰＧに変換された画像１のサイズは３０Ｋで，無変換のｚｉｐのサイズは３０Ｋであるので，合計のサイズは６１Ｋとなる。そこで，受信可能なサイズか否かの判定をした後，図１５に示すように，変換要素１に基づいて１回目の変換を行い，変換要素２に基づいて２回目の変換を行い，変換要素３に基づいて３回目の変換を行うこととなる。この場合，３回目の変換により合計のサイズは３９Ｋとなって，この機種の受信可能サイズである３０Ｋ以下とはならない。このため，ＪＰＧに変換された画像１は，１６０×１２０，２４万色で，サイズが８Ｋに変換されて，ｚｉｐファイルは無変換（３０Ｋのまま）でメールボックス１２に格納されることとなる。この場合，本文＋ヘッダと画像１の合計サイズは，９Ｋとなるので，ＩＭＡＰ／ＰＯＰサーバー１３にて，この部分のみを選択受信が可能になる。また，ＩＭＡＰ／ＰＯＰサーバー１３のサーバーメール転送機能で，別のメールへ転送する事も可能になる。

３．変換シナリオ２の処理
図２のステップＳ２５にて「Ｙｅｓ」と判定し，かつステップＳ２２にて取得した変換シナリオが変換シナリオ２であると，図４のステップＳ４０にて，変換シナリオ２の変換処理を開始する。すると，ステップＳ４１において，受信した電子メールの添付ファイル（コンテンツ）がユーザーディレクトリ１４ａから取得したコンテンツリスト（図７，図８，図９参照）に対応していない場合は，対応するフォーマットに変換する。

ついで，ステップＳ４１ａにおいて，フォーマット変換後の全サイズの合計が受信端末（ＭＳ−２）の受信可能サイズ（図１０参照）以下か否かの判定を行う。ここで，受信可能サイズ以下であれば，ステップＳ４１ａにて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進めて，変換後のメールをメールボックス１２に格納する。一方，受信可能サイズを超えていると，ステップＳ４１ａにて「Ｎｏ」と判定して，次のステップＳ４２に進める。ついで，ステップＳ４２において受信端末プロファイル１７から取得（Ｓ２３）した変換要素１を指定する。この後，ステップＳ４３にて，添付されている全ての添付ファイル（コンテンツ）を変換要素１に基づいて変換する。

ついで，ステップＳ４４に進め，変換後の全メールサイズの合計が受信端末（ＭＳ−２）の受信可能サイズ（図１０参照）以下か否かの判定を行う。ここで，受信可能サイズ以下であれば，ステップＳ４４にて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進めて，変換後のメールをメールボックス１２に格納する。一方，受信可能サイズを超えていると，ステップＳ４４にて「Ｎｏ」と判定して，次のステップＳ４５にて，最後の変換要素であるか否か，即ち，次の変換要素があるか否かの判定を行う。

ここで，次の変換要素がある場合は，ステップＳ４５にて「Ｎｏ」と判定して，次のステップＳ４６において受信端末プロファイル１７から取得（Ｓ２３）した次の変換要素（この場合は変換要素２となる）を指定する，ついで，ステップＳ４３に戻り，次の変換要素がなくなるまで上述のステップＳ４３〜ステップＳ４６までの変換処理を繰り返して実行する。なお，この変換シナリオ２の処理においても，変換シナリオ１の場合と同様に，添付ファイルを指定の変換要素で変換する場合に，受信可能サイズをできる限り大きくするために受信端末（ＭＳ−２）に不要な情報（例えば，ＪＰＧのＥｘｉｆ情報やサムネイルなどの付加情報）は削除するようにするのが望ましい。

一方，上述のステップＳ４３〜ステップＳ４６までの変換処理を繰り返して実行している内に，次に変換するため変換要素がなくなった場合は，ステップＳ４５にて「Ｙｅｓ」と判定して，次のステップＳ４７に進める。このステップＳ４７においては，最後の変換要素によって変換を行っても受信可能サイズ以下にならないファイル（単独ファイル）については削除を行う。変換を行っても受信可能サイズ以下にならなかったファイルを削除したことにより，受信可能サイズに空きが生じることとなる。そこで，ステップＳ４８において，前回あるいは前々回の変換要素による変換後の全メールサイズが受信可能サイズ以下であるか否かの判定を行う。

前回あるいは前々回の変換要素による変換後の全メールサイズが受信可能サイズ以下にならない場合は，ステップＳ４８において「Ｎｏ」と判定して，上述したステップＳ２７（図２参照）に進めて，最後に変換した変換後のメールをメールボックス１２に格納する。また，前回あるいは前々回の変換要素による変換後の全メールサイズが受信可能サイズ以下であった場合は，ステップＳ４８において「Ｙｅｓ」と判定して，次のステップＳ４９において，変換後のファイルとして前回あるいは前々回の変換要素による変換ファイルを採用し，この変換後のメールをメールボックス１２に格納することとする。

上述したように，本変換シナリオ２に基づく変換においては，最低レベルの変換要素で変換しても受信可能サイズ以下にならないファイル（単独ファイル）は削除して，受信可能サイズに空きを生じさせ，残ったファイルについては，レベルが上の変換要素で変換されたファイルを採用するため，例えば，画像ファイルについては高解像度の画像ファイルが得られることとなる。

ここで，変換シナリオ２に基づくメールの変換例を図１６（なお，図１６は変換例を模式的に示す図である）に基づいて説明する。この場合，変換シナリオ２を採用するアカウント（電話番号は０９０−００００−０００２で，機種の種別がＳＨＡＳ０１のもの）の受信端末（ＭＳ−２）宛の添付ファイルを有する電子メールを受信した例について以下に説明する。この場合は，本文＋ヘッダは１Ｋで，フォーマット（コンテンツ）がＢＭＰで，６４０×４８０，６０Ｋ，２４万色の画像１と，フォーマット（コンテンツ）がｚｉｐで，３０Ｋのその他からなる添付ファイルを有する電子メールを受信したものとする。

図１６において，画像１のフォーマット（コンテンツ）はＢＭＰであるので，図８より対応するコンテンツでないので，フォーマット（コンテンツ）がＪＰＧに変換される。一方，その他のｚｉｐは無変換のままとなる。そして，受信したメールサイズは本文＋ヘッダが１Ｋで，ＪＰＧに変換された画像１のサイズは３０Ｋで，その他のｚｉｐのサイズは３０Ｋであるので，メールの合計のサイズは６１Ｋとなる。そこで，ステップＳ４１ａでサイズの判定が行われるが，この端末の受信可能サイズは３０Ｋ（図１０参照）であるので，変換要素１に基づいて１回目の変換を行うこととなる。

この機種に対応する変換要素１（図１０（ａ）のＳＨＡＳ０１の静止画の変換要素１）により，画像１は３２０×２４０，１５Ｋ，２４万色に変換する。これにより，メールの合計のサイズは４６Ｋとなるので，この機種の受信可能サイズである３０Ｋを超えるので，静止画の変換要素２に基づいて２回目の変換を行うこととなる。この２回目の変換により，メールの合計のサイズは４１Ｋとなるので，静止画の変換要素３に基づいて３回目の変換を行う。これにより，メールの合計のサイズは３９Ｋとなるため，受信可能サイズの３０Ｋを超えるその他のファイル（ｚｉｐ）は削除される。
この場合，変換要素１に基づいて変換されたサイズが１５Ｋの前々回の変換後のファイルが採用（ステップＳ４８参照）され，合計で１６Ｋとなるファイル（コンテンツ）がメールボックス１２に格納されることとなる。

４．変換シナリオ３の処理
図２のステップＳ２５にて「Ｙｅｓ」と判定し，かつステップＳ２２にて取得した変換シナリオが変換シナリオ３であると，図５のステップＳ５０にて，変換シナリオ３の変換処理を開始する。すると，ステップＳ５１において，受信した電子メールの添付ファイル（コンテンツ）がユーザーディレクトリ１４ａから取得したコンテンツリスト（図７，図８，図９参照）に対応していない場合は，対応するフォーマットに変換する。

ついで，ステップＳ５１ａにおいて，フォーマット変換後の全サイズの合計が受信端末（ＭＳ−２）の受信可能サイズ（図１０参照）以下か否かの判定を行う。ここで，受信可能サイズ以下であれば，ステップＳ５１ａにて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進めて，変換後のメールをメールボックス１２に格納する。一方，受信可能サイズを超えていると，ステップＳ５１ａにて「Ｎｏ」と判定して，次のステップＳ５２に進める。ついで，ステップＳ５２において受信端末プロファイル１７から取得（Ｓ２３）した変換要素１を指定するとともに，受信した電子メールに添付されたファイルの内，最後の添付番号（ｎ）のファイルを指定する。この後，ステップＳ５３にて，最後の添付番号（ｎ）の添付ファイル（コンテンツ）を変換要素１に基づいて変換する。

ついで，ステップＳ５４に進め，添付番号（ｎ）の添付ファイル（コンテンツ）での変換後のメールサイズの合計が受信可能サイズ（図１０参照）以下か否かの判定を行う。ここで，受信可能サイズ以下であれば，ステップＳ５４にて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進め，変換後のメールをメールボックス１２に格納する。変換後のメールサイズの合計が受信可能サイズを超えていると，ステップＳ５４にて「Ｎｏ」と判定して，次のステップＳ５５にて，最後の変換要素であるか否か，即ち，次の変換要素があるか否かの判定を行う。

次の変換要素がある場合は，ステップＳ５５にて「Ｎｏ」と判定して，次のステップＳ５６において受信端末プロファイル１７から取得（Ｓ２３）した次の変換要素（この場合は変換要素２となる）を指定した後，ステップＳ５３に戻り，次の変換要素がなくなるまでステップＳ５３〜ステップＳ５６の処理を繰り返して実行する。上述したステップＳ５３〜ステップＳ５６の処理を繰り返して実行している内に次の変換要素がなくと，ステップＳ５５にて「Ｙｅｓ」と判定して，次のステップＳ５７に進み，前の添付番号（ｎ−１）の添付ファイル（コンテンツ）が有るか否かの判定を行う。前の添付番号（ｎ−１）の添付ファイル（コンテンツ）がない場合は，ステップＳ５７にて「Ｎｏ」と判定して上述したステップＳ２７（図２参照）に進め，変換後のメールをメールボックス１２に格納する。

一方，前の添付番号（ｎ−１）の添付ファイル（コンテンツ）がある場合は，ステップＳ５７にて「Ｙｅｓ」と判定してステップＳ５８に進み，前の添付番号（ｎ−１）の添付ファイル（コンテンツ）を変換対称ファイルに指定した後，上述したステップＳ５３に戻り，前の添付番号（ｎ−１）の添付ファイル（コンテンツ）がなくなるまで上述したステップＳ５３，ステップＳ５４，ステップＳ５５，ステップＳ５７，ステップＳ５８の処理を繰り返し実行する。

上述したステップＳ５３，ステップＳ５４，ステップＳ５５，ステップＳ５７，ステップＳ５８の処理を繰り返して実行している内に，前の添付番号（ｎ−１）の添付ファイル（コンテンツ）がなくなると，ステップＳ５７にて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進め，変換後のメールをメールボックス１２に格納する。なお，この変換シナリオ３の処理においても，受信可能サイズをできる限り大きくするために受信端末（ＭＳ−２）に不要な情報（例えば，ＪＰＧのＥｘｉｆ情報やサムネイルなどの付加情報）は削除するようにするのが望ましい。

上述したように，本変換シナリオ３に基づく変換においては，添付されたファイル（コンテンツ）毎に変換を行うようにしている。このため，例えば，変換された添付ファイルが画像ファイルである場合は，さらに高解像度で高画質な画像ファイルが得られることとなる。

ここで，変換シナリオ３に基づくメールの変換例を図１７（なお，図１７は変換例を模式的に示す図である）に基づいて説明する。この場合，変換シナリオ３を採用するアカウント（電話番号は０９０−００００−０００３で，機種の種別がＳＨＡＵ０１のもの）の受信端末（ＭＳ−２）宛の添付ファイルを有する電子メールを受信した例について以下に説明する。この場合は，本文＋ヘッダは１Ｋで，フォーマット（コンテンツ）がＪＰＧで，３２０×２４０，１５Ｋ，２４万色の画像１，２，３からなる添付ファイルを有する電子メールを受信したものとする。

図１７において，画像１，２，３のフォーマット（コンテンツ）はＪＰＧであるので，対応するコンテンツ（図８参照）であるので，フォーマット（コンテンツ）の変換は無変換となる。そして，受信したメールサイズは本文＋ヘッダが１Ｋで，画像１，２，３のサイズはそれぞれ１５Ｋであるので，合計サイズは４６Ｋとなる。そこで，まず，ステップＳ５１ａでサイズの判定を行うが，この機種の受信可能サイズ（図１０参照）は３０Ｋであることから，変換要素１に基づいて最後の添付ファイルとなる画像３について１回目の変換を行う。ついで，変換要素２に基づいて２回目の変換を行い，変換要素３に基づいて３回目の変換を行うこととなる。この３回目の変換により，図１７に示すように，メールの合計のサイズは３８Ｋとなって，受信可能サイズの３０Ｋを超えるサイズとなる。

このため，前の添付ファイルとなる画像２について，変換要素１に基づいて４回目の変換を行い，変換要素２に基づいて５回目の変換を行い，変換要素３に基づいて６回目の変換を行うこととなる。この６回目の変換により，図１７に示すように，メールの合計のサイズは３２Ｋとなって，受信可能サイズの３０Ｋを超えるサイズとなる。このため，さらに前の添付ファイルとなる画像１について，変換要素１に基づいて７回目の変換を行い，変換要素２に基づいて８回目の変換を行うこととなる。この８回目の変換により，図１７に示すように，メールの合計のサイズは２７Ｋとなって，受信可能サイズの３０Ｋ以下となる。これにより，画像３については３回目の変換によるファイルが，画像２については６回目の変換によるファイルが，画像１については８回目の変換によるファイルがそれぞれメールボックス１２に格納されることとなる。

５．変換シナリオ４の処理
図２のステップＳ２５にて「Ｙｅｓ」と判定し，かつステップＳ２２にて取得した変換シナリオが変換シナリオ４であると，図６のステップＳ６０にて，変換シナリオ４の変換処理を開始する。すると，ステップＳ６１において，受信した電子メールの添付ファイル（コンテンツ）がユーザーディレクトリ１４ａから取得したコンテンツリスト（図７，図８，図９参照）に対応していない場合は，対応するフォーマットに変換する。

ついで，ステップＳ６１ａにおいて，フォーマット変換後の全サイズの合計が受信端末（ＭＳ−２）の受信可能サイズ（図１０参照）以下か否かの判定を行う。ここで，受信可能サイズ以下であれば，ステップＳ６１ａにて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進めて，変換後のメールをメールボックス１２に格納する。一方，受信可能サイズを超えていると，ステップＳ６１ａにて「Ｎｏ」と判定して，次のステップＳ６２に進める。ついで，ステップＳ６２において，受信端末（ＭＳ−２）に対応している添付ファイル（コンテンツ）の順番を先頭に移動させる。ついで，ステップＳ６３において受信端末プロファイル１７から取得（Ｓ２３）した変換要素１を指定する。この後，ステップＳ６４にて，添付されている全ての添付ファイル（コンテンツ）を変換要素１に基づいて変換する。

ついで，ステップＳ６５に進むと，変換後の全メールサイズの合計が受信可能サイズ（図１０参照）以下か否かの判定を行う。ここで，受信可能サイズ以下であれば，ステップＳ６５にて「Ｙｅｓ」と判定して，上述したステップＳ２７（図２参照）に進めて，変換後のメールをメールボックス１２に格納する。一方，受信可能サイズを超えていると，ステップＳ６５にて「Ｎｏ」と判定して，次のステップＳ６６にて，最後の変換要素であるか否か，即ち，次の変換要素があるか否かの判定を行う。

ここで，次の変換要素がある場合は，ステップＳ６６にて「Ｎｏ」と判定して，次のステップＳ６７において受信端末プロファイル１７から取得（Ｓ２３）した次の変換要素（この場合は変換要素２となる）を指定する。この後，ステップＳ６４に戻り，最後の変換要素がなくなるまでステップＳ６４〜ステップＳ６７の処理を繰り返して実行する。なお，この変換シナリオ４の変換処理においても，添付ファイルを指定の変換要素で変換する場合に，受信可能サイズをできる限り大きくするために受信端末（ＭＳ−２）に不要な情報（例えば，ＪＰＧのＥｘｉｆ情報やサムネイルなどの付加情報）は削除するようにするのが望ましい。

一方，次の変換要素がない場合は，ステップＳ６６にて「Ｙｅｓ」と判定して，ステップＳ６８に進み，受信可能サイズより大きいファイルを削除する。ついで，ステップＳ６９にて，前回あるいは前々回の変換要素による，変換後の合計のサイズが受信可能サイズ以下であるか否かの判定を行う。ここで，変換後の合計のサイズが受信可能サイズを超えている場合は，ステップＳ６９にて「Ｎｏ」と判定して，上述したステップＳ２７（図２参照）に進めて，受信可能サイズを超えたままのファイルをメールボックス１２に格納する。

また，変換後の合計のサイズが受信可能サイズ以下である場合は，ステップＳ６９にて「Ｙｅｓ」と判定して，ステップＳ６９ａにて，前回あるいは前々回の変換要素による変換後のファイルを採用して，上述したステップＳ２７（図２参照）に進めて，変換後のメールをメールボックス１２に格納する。上述したように，本変換シナリオ４に基づく変換においては，受信端末（ＭＳ−２）がサポートしている添付ファイル（コンテンツ）を先頭に移動させ，サポートしていない添付ファイル（コンテンツ）を後方に移動させた後，変換処理を行うようにしているので，可能な限り多くの添付ファイル（コンテンツ）を見られるようになる。

ここで，変換シナリオ４に基づくメールの変換例を図１８（なお，図１８は変換例を模式的に示す図である）に基づいて説明する。この場合，変換シナリオ４を採用するアカウント（電話番号は０９０−００００−０００４で，機種の種別がＴＳＡＱ０１のもの）の受信端末（ＭＳ−２）宛の添付ファイルを有する電子メールを受信した例について以下に説明する。この場合は，本文＋ヘッダは１Ｋで，フォーマット（コンテンツ）がｄｏｃで２０Ｋのその他のファイル，フォーマット（コンテンツ）がＧＩＦで，６４０×４８０，４０Ｋ，２４万色の画像１，フォーマット（コンテンツ）がＪＰＧで，３２０×２４０，１５Ｋ，２４万色の画像２からなる添付ファイルを有する電子メールを受信したものとする。

図１８において，その他のファイルとなるフォーマットがｄｏｃのファイルは変換対象外のファイル（コンテンツ）であるので，無変換にする。一方，画像２のＪＰＧは対応するコンテンツ（図８参照）であるので，フォーマット（コンテンツ）の変換は無変換となる。一方，画像１のフォーマット（コンテンツ）はＧＩＦであるので，対応しないコンテンツ（図８参照）であるので，フォーマットをＪＰＧに変換する。そして，受信したメールサイズは本文＋ヘッダが１Ｋで，その他のサイズは２０Ｋで，ＪＰＧに変換後の画像１のサイズは３０Ｋで，画像２のサイズは１５Ｋであるので，合計サイズは６６Ｋとなり，ステップＳ６１ａにてサイズの判定を行うが，この端末の受信可能サイズの３０Ｋであることから，変換要素１に基づいて第１回目の変換を行うこととなる。

そこで，まず，この受信端末（ＭＳ−２：ＴＳＡＱ０１）に対応するフォーマット（ＪＰＧ）となる画像１が１番で，画像２が２番で，その他のファイル（ｄｏｃ）が最後になるように順番を入れ替える。そして，変換要素１に基づいて１回目の変換を行うことにより，図１８に示すように，変換後のサイズの合計は５１Ｋとなる。これは受信可能サイズの３０Ｋを超えるサイズとなるため，変換要素２に基づいて２回目の変換を行うことにより変換後の合計サイズは４１Ｋとなり，さらに，変換要素３に基づいて３回目の変換を行うことにより変換後の合計サイズは３７Ｋとなる。これも受信可能サイズの３０Ｋを超えるサイズとなるため，サイズが大きいその他のファイル（ｄｏｃ）を削除する。これにより，変換後のサイズの合計は１６Ｋとなるため，変換後のサイズの合計が２１Ｋで３０Ｋ以下となる前回の変換要素２による変換後のファイルを採用する。

なお，上述の変換シナリオ１の第５変換例において，その他のファイル（ｚｉｐ）は変換することなくメールボックス１２に格納する例について説明した。ところが，該ファイルを受信端末（ＭＳ−２）で取得する場合は，ＩＭＡＰ方式により，図１５の第５変換例では，本文とヘッダおよび画像１を最初に取得し，残りのファイルを後の受信要求で取得するようにしてもよい。この場合，最初の電子メール取得時に，ＩＭＡＰ／ＰＯＰサーバーが後続するファイルがあることを添付データとして，最初の電子メールとともに受信端末（ＭＳ−２）に通知するようにする。そして，受信端末（ＭＳ−２）側では，この添付データを参照して，ＩＭＡＰ／ＰＯＰサーバーに対して後続の受信要求を行なうことにより，前述のその他のファイルを取得することができる。

また，その他のファイルが，受信端末（ＭＳ−２）の受信可能なサイズをこえている場合（図１５の例においては，その他のファイル（ｚｉｐ）が３０Ｋ以上の場合）は，前述のＩＭＡＰ／ＰＯＰサーバーが添付するデータを参照することにより，受信端末（ＭＳ−２）のユーザーが後続のファイルの存在を知ることができる。ところが，受信端末（ＭＳ−２）での受信が不可であることから，サーバーメール転送手続き（例えば，受信端末（ＭＳ−２）のユーザーが別に保有する，パソコンなどのメールアドレスへの転送手続き）をすることにより，後続のファイルを取得することが可能となる。

これらのことは，前述した，変換シナリオ２（図１６），変換シナリオ４（図１８）における超過ファイルの削除についても同様に行なうことができる。この場合，超過したファイルを削除することなく，変換後の電子メールとともにメールボックス１２に保存するようにし，ＩＭＡＰサーバーにより，後続ファイルの存在を受信端末（ＭＣ−２）に通知するようにすればよい。なお，メールボックス１２から他の電子メールサーバへ，メール転送手続きを行なって，パソコンなどのメールアドレスへ転送してファイル取得できることは勿論のことである。

本発明の電子メール格納システムの概略構成を模式的に示すブロック図である。 図１に示されたメールサーバーの処理動作の例を示すフローチャートである。 図２の処理動作における変換シナリオ１の処理動作の例を示すフローチャートである。 図２の処理動作における変換シナリオ２の処理動作の例を示すフローチャートである。 図２の処理動作における変換シナリオ３の処理動作の例を示すフローチャートである。 図２の処理動作における変換シナリオ４の処理動作の例を示すフローチャートである。 ユーザーディレクトリの一例を示す図である。 コンテンツリストの一例を示す図であり，図８（ａ）は静止画に対応するコンテンツリストを示し，図８（ｂ）は動画に対応するコンテンツリストを示し，図８（ｃ）は着信メロディー（ＭＩＤＩファイル）に対応するコンテンツリストを示している。 コンテンツカテゴリリストを示す図である。 受信端末プロファイルの一例を示す図である。 変換シナリオ１による第１変換例を模式的に示す図である。 変換シナリオ１による第２変換例を模式的に示す図である。 変換シナリオ１による第３変換例を模式的に示す図である。 変換シナリオ１による第４変換例を模式的に示す図である。 変換シナリオ１による第５変換例を模式的に示す図である。 変換シナリオ２による変換例を模式的に示す図である。 変換シナリオ３による変換例を模式的に示す図である。 変換シナリオ４による変換例を模式的に示す図である。 従来の電子メール格納システムの概略構成を模式的に示すブロック図である。

符号の説明

１０…電子メール格納システム，１１…メールサーバー，１２…メールボックス，１３…ＩＭＡＰ／ＰＯＰサーバー，１４…ディレクトリサーバー，１４ａ…ユーザーディレクトリ，１５…変換機能部，１６…変換エンジン，１７…受信端末プロファイル

Claims (6)

1. 添付ファイルを有する電子メールを受信してメールボックスに格納し，該メールボックスに格納された前記電子メールを受信側端末が受信できるようにした電子メールの格納方法であって，
   ユーザーアカウント毎に予め登録されたユーザーディレクトリ情報に基づいて，受信側端末プロファイルに予め登録されたプロファイル情報を取得し，
   前記取得したプロファイル情報に基づいて前記受信した電子メールに変換処理を施す必要であるか否かを判定し，
   変換処理が必要でない電子メールの場合はそのまま前記メールボックスに格納し，変換処理が必要である電子メールの場合は前記取得したプロファイル情報に基づいて受信側端末が受信可能なフォーマットおよびサイズになるように変換し，変換された電子メールを前記メールボックスに格納するようにしたことを特徴とする電子メールの格納方法。
2. 前記ユーザーディレクトリ情報は受信側端末の機種情報，コンテンツリスト，変換シナリオのいずれか１つを含む情報であることを特徴とする請求項１に記載の電子メールの格納方法。
3. 複数の変換シナリオが用意されており，受信側端末のユーザーが予め選択して登録された変換シナリオに基づいて前記受信した電子メールを変換するようにしたことを特徴とする請求項２に記載の電子メールの格納方法。
4. 前記プロファイル情報は変換要素，受信可能サイズ，受信可能フォーマットのいずれか１つを含む情報であることを特徴とする請求項１から請求項３のいずれかに記載の電子メールの格納方法。
5. 前記電子メールの変換処理時に当該受信側端末の制約により不必要な情報は削除するようにしたことを特徴とする請求項１から請求項４のいずれかに記載の電子メールの格納方法。
6. 送信側端末から送信された添付ファイルを有する電子メールをメールボックスに格納し，当該メールボックスに格納された前記電子メールを受信側端末が受信できるようにした電子メールの格納システムであって，
   前記添付ファイルを有する電子メールを受信するメールサーバーと，
   前記受信側端末のユーザーディレクトリ情報を格納するユーザーディレクトリと，
   前記受信側端末のプロファイル情報を格納する受信端末プロファイルとを備え，
   前記メールサーバーは前記ユーザーディレクトリに格納されたユーザーアカウントに対応するユーザーディレクトリ情報と，前記受信側端末プロファイルに格納されたプロファイル情報とを取得して，前記受信した電子メールに変換処理を施す必要であるか否かを判定する判定手段を備え，
   前記判定手段により判定された結果，変換処理が必要でない電子メールの場合はそのまま前記メールボックスに格納し，変換処理が必要である電子メールの場合は前記取得したプロファイル情報に基づいて受信側端末が受信可能なフォーマットおよびサイズになるように変換し，変換された電子メールを前記メールボックスに格納する電子メールの格納システム。
   

Images