JP4376830B2 - 電子メール配信システム - Google Patents

Description

本発明は、送信側端末装置から送信された電子メールをメールボックスに格納し、該メールボックスに格納された電子メールを受信側端末装置に配信するようにした電子メール配信システムに関する。

近年、電子メール機能を備えた携帯電話機、ＰＨＳ、ＰＤＡなどの移動通信端末（送信側端末装置または受信側端末装置）が実用化され、コミュニケーション手段としての地位が確立されるようになった。このような移動通信端末での電子メールの送受信は以下のようにして行われる。まず、電子メールの送信者が送信側端末装置から受信側端末装置宛に電子メールを送信すると、その電子メールは携帯電話網に設置されたメール配信サーバのメールボックスに格納される。受信側端末装置の利用者は、新規の電子メールがメールボックスに格納されているか、適宜、メール受信サーバに問い合わせを行って、新規の電子メールがメールボックスに格納されていれば、当該電子メールを受信側端末装置にダウンロードして、電子メールを受信するようにしている。また、携帯電話機のインターネット接続サービスであれば、ショートメッセージサービスセンタ（ＳＭＳＣ）が当該電子メールを受信した旨を当該電子メールの受信側端末装置宛に通知するので、当該電子メールの受信者は当該メール受信サーバを通じてメールボックスに格納された電子メールを受信側端末装置にダウンロードして、電子メールを受信するようにしている。

ところで、移動通信端末には様々の機種があって、その機種に応じて利用できるサービスが異なったり、対応するマルチメディア・データ（画像・動画・音声・楽曲・オフィスドキュメント等）のフォーマット（コンテンツ）やサイズも異なっている。このため、送信者が受信側端末装置の機種や、対応するフォーマット（コンテンツ）やサイズなどを知らないで、添付ファイルを有する電子メールの送信を行うと、受信側端末装置は当該電子メールに添付された添付ファイルを受信できないという問題を生じた。また、添付ファイルの受信を行っても、受信側端末装置がフォーマット（コンテンツ）に対応していないため、当該受信側端末装置に表示できなかったり、あるいは利用できないという問題も生じた。

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

このような電子メールの受信システムの一例を図２０に例示する。図２０において、この電子メールの受信システムは、インターネット、移動体通信ネットワークあるいはこれらのネットワークが相互に接続されたネットワークなどからなるネットワーク７０と、メール配信サーバ（この場合は、送信側メール配信サーバ７１ａと受信側メール配信サーバ７１ｂとからなる）と、メールボックス７２と、メール受信サーバ７３と、ディレクトリサーバ７４と、ウエッブスペース７５と、ウエッブサーバ７６と、変換機能部７７と、受信端末プロファイル７８と、ショートメッセージサービスセンタ（ＳＭＳＣ）７９とを備えている。なお、ディレクトリサーバ７４にはユーザディレクトリ７４ａが接続されており、変換機能部７７には変換エンジン７７ａが接続されている。

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

その結果、受信側端末装置（ＭＳ−２）が管理するアカウントであれば、受信側メール配信サーバ７１ｂは受信した電子メールをメールボックス７２に格納するとともに、ショートメッセージサービスセンタ（ＳＭＳＣ）７９に通知する。すると、ショートメッセージサービスセンタ（ＳＭＳＣ）７９は当該電子メールを受信した旨の通知を当該電子メールの受信側端末装置（ＭＳ−２）に送信する。これにより、受信側端末装置（ＭＳ−２）はメール受信サーバ７３にアクセス（配信要求）して、メールボックス７２に格納された電子メールを受信することができるようになる。

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

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

この変換要求に応じて変換機能部７７は、受信端末プロファイル７８と受信したユーザエージェント情報から、受信側端末装置（ＭＳ−２）が受信可能なフォーマット（コンテンツ）やサイズを決定し、変換エンジン７７ａにより受信可能なフォーマット（コンテンツ）やサイズになるような変換処理を行なわせる。変換処理後、ウエッブサーバ７６は変換された電子メールの配信を受信側端末装置（ＭＳ−２）に行う。これにより、受信側端末装置（ＭＳ−２）は電子メールを受信できるようになるとともに、その添付ファイル（コンテンツ）が見られるようになる。

ところで、通常、電子メールの受信は１回の受信操作で済むようになされているが、上述した図２０に示すようなシステムにおいては、ホスティングされたＵＲＬを受信した後に、ウエッブサーバ７６にアクセスする必要がある。このため、電子メールの受信動作が不便であるという問題を生じた。また、電子メールを受信した旨の通知を受信する度に、ウエッブサーバ７６にアクセスする必要がある。このため、電子メールを受信するための動作が面倒であるという問題を生じた。また、ウエッブサーバ７６へのアクセスは、受信側端末装置（ＭＳ−２）上のウエッブブラウザソフトを用いるため、受信した電子メールを管理するソフトウェアの保存フォルダで添付ファイルを保存することができなく、送信者が意図して作成された電子メールの本文と添付ファイルがそれぞれのソフトウェアでバラバラに保存されるという制限もあった。

また、受信側端末装置（ＭＳ−２）宛の電子メールは必ずしも受信者が必要とするメッセージではないこともあるため、ウエッブサーバ７６へのアクセスが行われない場合もある。この場合、ウエッブスペース７５に格納された当該受信側端末装置（ＭＳ−２）宛の添付ファイル（コンテンツ）が削除されないことになるので、ウエッブスペース７５の容量が圧迫されるという事態も予想されることとなる。このため、必要以上に大容量のウエッブスペース７５を確保しなければならないといった問題も発生し、ウエッブスペース７５を大容量にするためのコストが増大するという問題も生じた。

そこで、本出願人は先の出願（特願２００４−２５２１８４号）において、利用可能形式(フォーマット)、通信速度、メモリ容量、データ転送量などに制限がある受信側端末装置であっても、これらの制限に係わらず、画像ファイル、動画ファイル、ｍｉｄｉ（登録商標）ファイル等のマルチメディア・データなどの添付ファイルを受信できるようにした電子メールの格納システムを提案した。
大和哲,「ケータイ用語の基礎知識」,第９５回：ｉショットとは,［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〉 OMA（Open Mobile Alliance）Release Program and Specifications［online］［平成１７年６月１７日検索］、インターネット〈URL:http://www.openmobilealliance.org/release_program/〉 W3C (The World Wide Web Consortium) Content Adaptation and Generation Principles for Heterogeneous Clients ［online］［平成１７年６月１７日検索］、インターネット〈URL:http://www.w3.org/2002/07/DIAT/posn/inria/DIAT-PositionPaper.html〉

ところで、携帯電話(この場合は受信側端末装置となる) の機種を変更する場合、２Ｇ(Second Generation)端末やＰＤＣ端末、あるいは２．５Ｇ（2.5Generation）端末やＰＤＣパケット端末においては、通常、機種変更時にショップにおいて、自動的に変更した機種の情報がアカウント情報を格納するユーザディレクトリに反映されるように機種変更のシステム処理がなされている。このため、アカウント情報から受信側端末装置の機種情報を得ることができる。ところが、ＵＳＩＭ（Universal Subscriber Identity Module：汎用加入者識別モジュール）対応の３Ｇ(Third Generation)端末やＷ−ＣＤＭＡ端末（ＩＭＴ２０００で取り決められた方式）であれば、ＵＳＩＭを差し替えるだけで機種変更が可能となる。このため、機種情報を格納しているディレクトリサーバは、当該ユーザディレクトリが現在どの機種を利用しているかを判別できないこととなる。この結果、ＵＳＩＭ対応の移動通信端末（３Ｇ端末，Ｗ−ＣＤＭＡ端末）においては、アカウント情報から受信側端末装置の機種情報を得ることが困難となる。

このため、上述した特願２００４−２５２１８４号にて提案されたシステムにおいては、当該受信側端末装置が受信可能なフォーマット（コンテンツ）やサイズなどの情報は不明となって、メールボックスへの格納時に電子メールの変換処理を行うことができないこととなる。この結果、当該受信側端末装置に対応した画像ファイル、動画ファイル、ｍｉｄｉファイル（ｍｉｄｉは登録商標）等のマルチメディア・データなどの添付ファイル（コンテンツ）を受信できないという問題を生じた。

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

この場合、図２１に示すよう、メールボックス８２から電子メールを取り出すときに、変換プロキシー８５が受信側端末装置（ＭＳ−２）に合わせて変換を行うという配信システムが、ＯＭＡ(Open Mobile Alliance：非特許文献３参照)やＷ３Ｃ(The World Wide Web Consortium：非特許文献４参照)にて提唱されている。ところが、これらの配信システムにおいては、受信側端末装置（ＭＳ−２）の利用者が予め変換シナリオを選択して登録しておき、この登録された変換シナリオに基づいて電子メールの変換を行なわせるということ、即ち、利用者の好みに応じて変換を行なわせるということは不可能であった。

そこで、本発明は上記問題点を解決するためになされたものであって、受信側端末装置がＵＳＩＭ対応の移動通信端末（３Ｇ端末，Ｗ−ＣＤＭＡ端末）、あるいはＰＤＡ(Personal Digital Assistant)やＰＣ(Personal Computer)などであっても、利用可能形式(フォーマット)、通信速度、メモリ容量、データ転送量などの制限に係わらず、画像ファイル、動画ファイル、ｍｉｄｉ（登録商標）ファイル等のマルチメディア・データなどの添付ファイル（コンテンツ）を受信側端末装置の利用者の好みに応じて受信できるようにすることを目的とする。

上記目的を達成するため、本発明の電子メールの配信システムにおいては、送信側端末装置から送信された電子メールを受信して当該電子メールをメールボックスに格納させるメール配信サーバと、受信側端末装置からの配信要求に基づいてメールボックスに格納された電子メールを当該受信側端末装置に配信するとともに、受信側端末装置からの配信要求時に当該受信側端末装置のユーザ識別情報とユーザエージェント情報を取得するメール受信サーバと、メールボックスの所在やユーザ識別情報や受信側端末装置に対して予め登録された変換方法もしくは変換条件を定義する変換シナリオを含むユーザアカウント情報とユーザ識別情報に対応した受信可能なフォーマットリストと変換可能なコンテンツカテゴリリストとを含む第１プロファイル情報とを格納するユーザディレクトリと、受信側端末装置の受信可能サイズや受信可能フォーマットや変換要素の少なくとも１つを含む情報をデータベース化した当該受信側端末装置に関する第２プロファイル情報を格納する受信端末プロファイルと、マルチメディア・データのフォーマットやコーデックを変換する少なくとも１つ以上の変換エンジンとを備えるようにしている。

そして、メール受信サーバは受信側端末装置からの配信要求時に取得したユーザ識別情報に基づいてユーザディレクトリからユーザアカウント情報と第１プロファイル情報とを取得するとともに、配信要求時に同時に取得したユーザエージェント情報に基づいて受信端末プロファイルから当該受信側端末装置に関する第２プロファイル情報を取得して、取得した第２プロファイル情報に基づいて、メールボックスに格納された電子メールに変換処理を施す必要であるか否かを判定する判定手段を備え、判定手段により判定された結果、変換処理を必要と判定したときは、ユーザアカウント情報の変換方法もしくは変換条件を定義する変換シナリオに基づいて当該電子メールを前記変換エンジンにより受信側端末装置が受信可能なフォーマットやサイズや変換要素に変換させて、変換された電子メールを受信側端末へ配信するようにすればよい。

ついで、本発明の一実施の形態を図１〜図１９に基づいて説明するが、本発明はこの実施の形態に何ら限定されるものでなく、本発明の目的を変更しない範囲で適宜変更して実施することが可能である。なお、図１は、本発明の電子メール配信システムの概略構成を模式的に示すブロック図である。図２は、図１に示されたメール受信サーバでの処理動作の例を示すフローチャートである。図３〜図６は、図１に示された変換機能部での処理動作の例を示すフローチャートである。図７は送信メールの一例を示す図である。図８はユーザディレクトリの一例を示す図である。

また、図９はコンテンツリストの一例を示す図である。図１０は変換可能なコンテンツカテゴリリストを示している。図１１は受信端末プロファイルの一例を示す図であり、図１１（ａ）は受信したユーザエージェント情報に基づく機種の種別および受信可能サイズを示すプロファイルの一例であり、図１１（ｂ）は静止画に対応する変換要素を示すプロファイルの一例であり、図１１（ｃ）は動画に対応する変換要素を示すプロファイルの一例である。図１２〜図１９は、コンテンツの変換例を模式的に示す図である。

図１に示すように、本発明の電子メール配信システムは、ネットワーク１０と、送信側端末装置（ＭＳ−１）から電子メールを受信するメール配信サーバ（この場合は、送信側メール配信サーバ１１ａと受信側メール配信サーバ１１ｂとからなる）と、受信側メール配信サーバ１１ｂが受信した電子メールを格納するメールボックス１２と、受信側端末装置（ＭＳ−２）からの配信要求に応じてメールボックス１２に格納された電子メールを受信側端末装置（ＭＳ−２）に配信するメール受信サーバ１３と、メールボックスの所在やユーザ識別情報（この場合は、電話番号、メールアドレスなど）やメールの送受信に必要な情報（この場合は、変換シナリオ：図８参照）などのユーザアカウント情報を管理するディレクトリサーバ１４と、電子メールに添付された添付ファイル（コンテンツ）に所定の変換処理を施す変換機能部１５と、受信側端末装置（ＭＳ−２）に対応したコンテンツリストや受信可能サイズや変換要素（表示サイズや表示色など）などの第２プロファイル情報を格納する受信端末プロファイル１７と、ショートメッセージサービスセンタ（ＳＭＳＣ）１８とを備えている。
この場合、ネットワーク１０は、インターネット、移動体通信ネットワークあるいはこれらのネットワークが相互に接続されたネットワークなどからなる。また、送信側端末装置（ＭＳ−１）および受信側端末装置（ＭＳ−２）はインターネット接続機能を有する端末装置または移動体通信事業者が提供するインターネットゲートウェイに接続して電子メールを送受信できる端末装置とする。

ここで、送信側メール配信サーバ１１ａおよび受信側メール配信サーバ１１ｂは、図示しないＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスクドライブ（ＨＤＤ）や光ディスクドライブ等からなる記憶装置、あるいはシステムバスなどからなるハードウェア上で所定のプログラムを実行することにより、受信側端末装置（ＭＳ−２）のユーザに付与されているメールアドレス宛の電子メールを受信したり、この電子メールを転送したりする機能を実現している。このようなプログラムとしては、ＭＴＡ（Message Transfer Agent）等のソフトウェアが用いられる。そして、これらの送信側メール配信サーバ１１ａおよび受信側メール配信サーバ１１ｂを所定の手順に従って動作させるためのプログラムはＲＯＭや記憶装置に記憶されており、必要に応じてＣＰＵやＲＡＭ上の作業エリアに呼び出されて実行される。なお、送信側メール配信サーバ１１ａおよび受信側メール配信サーバ１１ｂは１台のコンピュータシステムで構成してもいいし、複数のサーバ機能をそれぞれ受け持つ複数台のコンピュータをネットワークで結んで構成するようにしてもよい。

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

メール受信サーバ１３は上述した送信側メール配信サーバ１１ａおよび受信側メール配信サーバ１１ｂと同様に、図示しないＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスクドライブ（ＨＤＤ）や光ディスクドライブ等からなる記憶装置、あるいはシステムバスなどからなるハードウェア上で所定のプログラムを実行することにより、受信側端末装置（ＭＳ−２）からの配信要求に基づいて、メールボックス１２に格納された電子メールを受信側端末装置（ＭＳ−２）に配信する機能を実現している。このようなプログラムとしては、ＭＲＡ（Mail Retrieval Agent）等のソフトウェアが用いられる。そして、このメール受信サーバ１３を所定の手順に従って動作させるためのプログラムはＲＯＭや記憶装置に記憶されており、必要に応じてＣＰＵやＲＡＭ上の作業エリアに呼び出されて実行される。なお、メール受信サーバ１３も、送信側メール配信サーバ１１ａおよび受信側メール配信サーバ１１ｂと同様に１台のコンピュータシステムで構成してもいいし、複数のサーバ機能をそれぞれ受け持つ複数台のコンピュータをネットワークで結んで構成するようにしてもよい。

ディレクトリサーバ１４は、上述した送信側メール配信サーバ１１ａおよび受信側メール配信サーバ１１ｂやメール受信サーバ１３とほぼ同様なハードウェアで構成されており、メールボックスの所在やユーザ識別情報（この場合は、電話番号、メールアドレスなど）やメールの送受信に必要な情報（この場合は、変換シナリオ：図８参照）などのユーザアカウント情報を格納したユーザディレクトリ１４ａが接続されている。そして、メール受信サーバ１３からの要求に応じて、ユーザディレクトリ１４ａに予め格納された、ユーザ識別情報などのユーザアカウント情報をメール受信サーバ１３に送信する機能を備えている。

この場合、ユーザディレクトリ１４ａには、予め受信側端末装置（ＭＳ−２）の所有者からの登録要求により、例えば、図８に例示するように、受信側端末装置（ＭＳ−２）のアカウント（電話番号やメールアドレス）に対応した変換シナリオなどをデータベース化したユーザアカウント情報が格納されている。また、ユーザディレクトリ１４ａには、図９に示す受信可能フォーマット（コンテンツ）リスト、即ち、コンテンツリスト（この場合は、Ａ〜Ｉまでのコンテンツリストが有るものとする）に対応する受信側端末装置（ＭＳ−２）が受信できるフォーマット（コンテンツ：静止画に対応するコンテンツの種別、動画に対応するコンテンツの種別、着信メロディー（ｍｉｄｉファイル）に対応するコンテンツの種別、マークアップランゲージに対応するコンテンツの種別等）をデータベース化した第１プロファイル情報も格納されている。また、図１０に示す変換可能なコンテンツカテゴリリスト、即ち、変換可能なフォーマット（コンテンツ：静止画、動画、着信メロディー（ｍｉｄｉファイル）、マークアップランゲージなど）のカテゴリをデータベース化した第１プロファイル情報も格納されている。

変換機能部１５は、上述した送信側メール配信サーバ１１ａおよび受信側メール配信サーバ１１ｂやメール受信サーバ１３とほぼ同様なハードウェアで構成されているとともに変換エンジン部１６が接続されており、添付ファイル(コンテンツ)毎に最適な変換エンジンを選択するようになされている。そして、メール受信サーバ１３からの要求に応じて、ユーザディレクトリ１４ａや後述する受信端末プロファイル１７に予め格納された第１，第２プロファイル情報に基づいて、受信した電子メールを変換エンジン部１６に用意された変換エンジンを用いて所定のフォーマットや所定のコーデックおよび所定のサイズになるような変換処理を行い、変換された電子メールをメール受信サーバ１３に送信する機能を備えている。

この場合、変換エンジン部１６には複数の変換エンジンが用意されおり、マルチメディア・データのフォーマット(コンテンツ)を変換したり、同じデータフォーマットでも、異なるコーデック（圧縮伸張方式）が存在する為、当該コーデックに変換することができるようになされている。例えば、画像（静止画）の変換を行う画像変換エンジン、映像（動画）の変換を行う映像変換エンジン、ｍｉｄｉ（登録商標）の変換を行うｍｉｄｉ変換エンジン、ドキュメントの変換を行うドキュメント変換エンジン、ＨＴＭＬやＳＭＩＬなどのマークアップランゲージの変換を行うマークアップランゲージ変換エンジン等の複数のマルチメディア・データのフォーマット(コンテンツ)に対応する多数の変換エンジンが用意されている。

受信端末プロファイル１７は、ユーザエージェント(User Agent)情報（なお、この情報は受信側端末装置（ＭＳ−２）がメール受信サーバ１３にアクセスした際に取得される）に対応した受信側端末装置（ＭＳ−２）の機種名や、受信側端末装置（ＭＳ−２）の受信可能サイズや表示色などからなる複数の表示能力情報や、再生時間やサンプリングレートなどからなる複数の再生能力情報をデータベース化した第２プロファイル情報が格納されている。

例えば、図１１（ａ）に示すように、ユーザエージェント(User Agent)に対応した移動機の機種名やコンテンツリストや受信可能サイズをデータベース化したプロファイル情報が格納されている。また、図１１（ｂ）に示すように、静止画に関しては、変換要素１，２，３からなる表示サイズ（縦、横のサイズ）や表示色などの表示能力情報をデータベース化した第２プロファイル情報が格納されている。さらに、図１１（ｃ）に示すように、動画に関しては、変換要素１，２，３からなる表示サイズ（縦×横のサイズ）やフレーム数（ｆｐｓ）やビットレート（ｋｂｐｓ）などの表示能力情報をデータベース化したプロファイル情報が格納されている。

なお、受信側端末装置（ＭＳ−２）が移動機以外のＰＤＡ(Personal Digital Assistant)やＰＣ(Personal Computer)の場合、ユーザエージェント(User Agent)情報は、ＰＤＡやＰＣの機種名ではなく、使用しているメールソフト毎に定義されるようになされている。

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

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

ついで、上述のように構成される電子メール配信システムにおいて、図２〜図６のフローチャートを参照しながら、送信側端末装置（ＭＳ−１）が添付ファイル（コンテンツ）を有する電子メールを受信側端末装置（ＭＳ−２）宛に送信した場合のメール受信サーバ１３の電子メールの配信の手順、および変換機能部１５が添付ファイル（コンテンツ）を変換する手順を以下に説明する。この場合、受信側端末装置（ＭＳ−２）のアカウント（電話番号やメールアドレス）に対応する変換シナリオ（図８参照）が受信側端末装置（ＭＳ−２）を所有するユーザの申し出により予めユーザディレクトリ１４ａに登録されているものとする。また、受信可能フォーマット（コンテンツ）リスト（図９参照）や変換可能なコンテンツカテゴリリスト（図１０参照）などの第１プロファイル情報がユーザディレクトリ１４ａに格納されているものとする。さらに、ユーザエージェント(User Agent)に対応した移動機の機種名やコンテンツリストや受信可能サイズ、静止画に対する変換要素１、２、３および動画に対する変換要素１、２、３などの要素情報および受信可能サイズ情報などのデータベースからなる第２プロファイル情報（図１１参照）が受信端末プロファイル１７に予め格納されているものとする。

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

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

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

１．通常の処理
ここで、送信側端末装置（ＭＳ−１）が、図７に示すような電子メールを送信したする。なお、図７に示す送信メールにおいて、ヘッダ部（点線で囲まれたＡ部）と、ボディ部（点線で囲まれたＢ部からなる電子メール本文と、Ｃ部およびＤ部からなる添付ファイル（コンテンツ）とからなり、Ｃ部は画像ファイル（ｇｉｆ）であり、Ｄ部は動画ファイル（ｍｐｇ）である）からなることを示している。ここで、送信側メール配信サーバ１１ａが送信側端末装置（ＭＳ−１）からの電子メールを受信すると、送信側メール配信サーバ１１ａネットワーク１０を介して受信した電子メールを受信側メール配信サーバ１１ｂに送信する。

すると、これを受信した受信側メール配信サーバ１１ｂは受信側端末装置（ＭＳ−２）のアカウントがユーザディレクトリ１４ａに存在するか否かをディレクトリサーバ１４に問い合わせる。その結果、受信側端末装置（ＭＳ−２）が管理するアカウントであれば、受信側メール配信サーバ１１ｂは受信した電子メールをメールボックス１２に格納する。これと同時に、受信側メール配信サーバ１１ｂはショートメッセージサービスセンタ（ＳＭＳＣ）１８に受信側端末装置（ＭＳ−２）宛に電子メールを受信した旨の通知を行うので、ショートメッセージサービスセンタ（ＳＭＳＣ）１８は当該電子メールを受信した旨の通知を受信側端末装置（ＭＳ−２）に送信する。

これにより、受信側端末装置（ＭＳ−２）は所定のプロトコル（この場合は、ＩＭＡＰ(Internet Message Access Protocol)／ＰＯＰ(Post Office Protocol)／ＯＭＡ ＭＭＳ(OMA Multimedia Messaging Service)などとする）によりメール受信サーバ１３にアクセスする（配信要求する）こととなる。これにより、図２に示すステップＳ２１にて、メール受信サーバ１３は所定のプロトコル（ＩＭＡＰ／ＰＯＰ／ＯＭＡ ＭＭＳなど）により、受信側端末装置（ＭＳ−２）からのアクセス（配信要求）を受け付ける。すると、メール受信サーバ１３は、受信側端末装置（ＭＳ−２）からのアクセス（配信要求）に基づき、当該受信側端末装置（ＭＳ−２）のアカウント（電話番号とメールアドレス）とユーザエージェントを取得する。

そして、ステップＳ２２にて、取得したユーザエージェントに基づいて受信側端末装置（ＭＳ−２）の現在使用中の移動機の機種名を取得（図１１（ａ）参照）する。そして、取得した機種名から、コンテンツリストや受信可能サイズや受信可能フォーマットや変換要素などの第２プロファイル情報を受信端末プロファイル１７に格納されたデータベース（図１１（ａ）（ｂ）（ｃ）参照）から変換機能部１５を介して取得するとともに、取得した受信可能サイズや受信可能フォーマットや変換要素などの第２プロファイル情報を変換機能部１５に転送する。

ついで、ステップＳ２３にて、取得したアカウント（電話番号）やメールアドレスからなるユーザ識別情報に対応する変換シナリオなどのユーザアカウント情報をユーザディレクトリ１４ａに格納されたデータベース（例えば、図８参照）からディレクトリサーバ１４を介して取得するとともに、受信可能フォーマット（コンテンツ）リスト（図９参照）や変換可能なコンテンツカテゴリリスト（図１０参照）などの第１プロファイル情報をユーザディレクトリ１４ａに格納されたデータベースからディレクトリサーバ１４を介して取得する。そして、取得したユーザアカウント情報や第１プロファイル情報を変換機能部１５に転送する。

ついで、ステップＳ２４に進め、当該受信側端末装置（ＭＳ−２）のアカウント（電話番号とメールアドレス）宛ての電子メールをメールボックス１２から読み出して、ＲＦＣ（Request For Comment）の仕様に基づいたインターネットメールに関する規約に従った電子メールの解析を実施する。例えば、図７に示す電子メールの場合には、複数のＭＩＭＥ（Multipurpose Internet Mail Extensions）の各パート毎、即ち、Ｂ部の電子メール本文、Ｃ部の添付ファイル（ｇｉｆファイル）およびＤ部の添付ファイル（ｍｐｇファイル）毎に電子メールを分解する。そして、分解された各ＭＩＭＥのヘッダから添付ファイル（コンテンツ）のサイズや添付ファイル（コンテンツ）の種類を判別する。この後、ステップＳ２５にて、前のステップＳ２４で電子メールの解析を行った結果に基づいて、即ち、取得した受信可能サイズや受信可能フォーマットや変換要素などの第２プロファイル情報に基づいて、受信した電子メールは変換が必要か否かの判定を行う。

この場合、受信側端末装置（ＭＳ−２）で対応していない（受信可能でない）フォーマット（コンテンツ）の添付ファイル（コンテンツ）が添付されておらず、かつ受信した電子メールのサイズ合計が受信可能サイズ以下であれば、ステップＳ２５にて「Ｎｏ」と判定する。そして、次のステップＳ２８にてメールボックス１２に格納されている電子メールをそのまま受信側端末装置（ＭＳ−２）に配信する。一方、受信側端末装置（ＭＳ−２）で対応していない（受信可能でない）フォーマット（コンテンツ）の添付ファイル（コンテンツ）が添付されていたり、受信した電子メールのサイズ合計が受信可能サイズを超えていれば、ステップＳ２５にて「Ｙｅｓ」と判定する。

そして、次のステップＳ２６にて、メールボックス１２から読み出した電子メールを変換機能部１５に転送するとともに、ステップＳ２２にて転送されて変換機能部１５が取得した変換シナリオに基づいて、変換機能部１５に変換シナリオに基づく電子メールの変換処理を行なわせる。この後、メール受信サーバ１３は、ステップＳ２７にて、変換機能部１５にて変換された変換後の電子メールを変換機能部１５から受信し、次のステップＳ２８にて変換後の電子メールを受信側端末装置（ＭＳ−２）に配信する。

なお、取得した変換シナリオが変換シナリオ１であると、変換機能部１５は図３のフローチャートに基づいて、変換シナリオ１の処理を実行する。同様に、取得した変換シナリオが変換シナリオ２であると、変換機能部１５は図４のフローチャートに基づいて変換シナリオ２の処理を実行し、変換シナリオ３であると図５のフローチャートに基づいて変換シナリオ３の処理を実行し、変換シナリオ４であると図６のフローチャートに基づいて変換シナリオ４の処理を実行する。

２．変換シナリオ１の処理
ここで、ステップＳ２３にて転送されて変換機能部１５が受信した変換シナリオが変換シナリオ１であると、図３のステップＳ３０にて、変換機能部１５は変換シナリオ１の変換処理を開始する。すると、ステップＳ３１において、受信した電子メールに添付されたファイルはフォーマット（コンテンツ）の変換が必要か否かの判定を行う。ここで、受信した電子メールに添付されたファイルが、上述のステップＳ２３にてユーザディレクトリ１４ａから取得したコンテンツリストに対応した受信可能フォーマット（コンテンツ）リスト（図９参照）にリストアップされていれば、フォーマット（コンテンツ）の変換を行う必要がないので、ステップＳ３１にて「Ｎｏ」と判定して、ステップＳ３１ｂに進める。

一方、受信した電子メールに添付されたファイルが、受信可能フォーマット（コンテンツ）リスト（図９参照）に存在しない場合は、ステップＳ３１にて「Ｙｅｓ」と判定して、ステップＳ３１ａに進め、上述のステップＳ２３にてユーザディレクトリ１４ａから取得した変換可能なコンテンツカテゴリリスト（図１０参照）にリストアップされていれば、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に変換できるような適切な変換エンジンを変換エンジン部１６に選択させ、変換エンジン部１６が選択した変換エンジンにより受信した電子メールの添付ファイルのフォーマット（コンテンツ）の変換を依頼する。

この場合、変換エンジン部１６は、用意された画像変換エンジン、映像変換エンジン、ｍｉｄｉ変換エンジン、ドキュメント変換エンジン、マークアップランゲージ変換エンジンなどから受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応する変換エンジンを選択し、選択した変換エンジンを用いてフォーマット（コンテンツ）の変換処理を実行することとなる。この後、変換機能部１５は、変換エンジン部１６で変換がなされたフォーマット（コンテンツ）を取得し、当該フォーマット（コンテンツ）のファイルを電子メールに添付して電子メールの形に再変換を行う。

例えば、電話番号が「０９０−００００−０００１」（このアカウントの場合、図１１に示すように、ユーザエージェント(Vodafone/1.0/V802SH)から使用中の移動機の機種名がＶ８０２ＳＨに特定され、そのコンテンツリストはＧとなる。そして、図８に示すように、変換シナリオは変換シナリオ１となる）宛にフォーマット（コンテンツ）がｂｍｐである添付ファイルを有する電子メールを受信した場合、静止画に対応するフォーマット（コンテンツ）は受信可能フォーマット（コンテンツ）リスト（図９参照）からｊｐｇ、ｐｎｇとなる。この場合、ｂｍｐは変換可能なコンテンツカテゴリリスト（図１０参照）の静止画のカテゴリにリストアップされているので、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応するｊｐｇに変換される必要がある。このため、変換機能部１５は、フォーマット（コンテンツ）がｂｍｐである添付ファイルを、変換エンジン部１６に用意された画像変換エンジンを用いて、ｂｍｐのフォーマット（コンテンツ）をｊｐｇのフォーマット（コンテンツ）に変換させる。これにより、変換機能部１５は変換後の電子メールをメール受信サーバ１３に送信し、メール受信サーバ１３は、変換後の電子メールを受信側端末装置（ＭＳ−２）に配信する。

ここで、添付ファイルのフォーマット（コンテンツ）変換を行った場合、フォーマット（コンテンツ）の特性により、サイズが縮小されることがある。例えば、ｊｐｇの場合は、ｂｍｐと比較して、通常品質を落とさない範囲で画像のサンプリングレートやクオリティ値といったパラメターが定められており、フォーマット（コンテンツ）変換により画像が圧縮される。この場合、次のステップＳ３１ｂにてメールサイズの合計が受信側端末装置（ＭＳ−２）の受信可能サイズ以下であるか否かの判断を行う。

そして、受信可能サイズ以下であれば、変換機能部１５はステップＳ３１ｂにて「Ｙｅｓ」と判定して、ステップＳ３７にて、変換後のフォーマット（コンテンツ）からなる電子メールをメール受信サーバ１３に送信する。すると、メール受信サーバ１３は、上述したステップＳ２７（図２参照）にて変換後のフォーマット（コンテンツ）からなる電子メールを受信し、次のステップＳ２８に進めて、変換後の電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

一方、受信可能サイズより大きいと、変換機能部１５はステップＳ３１ｂにて「Ｎｏ」と判定して、次のステップＳ３２に進める。ついで、ステップＳ３２において取得した第２プロファイル情報から変換要素１を指定する。この後、ステップＳ３３にて、添付されている全ての添付ファイルのフォーマット（コンテンツ）を変換要素１に基づいて変換する。ついで、ステップＳ３４に進め、変換後の全サイズの合計が受信側端末装置（ＭＳ−２）の受信可能サイズ（図１１参照）以下か否かの判定を行う。ここで、受信可能サイズ以下であれば、ステップＳ３４にて「Ｙｅｓ」と判定して、変換後のフォーマット（コンテンツ）からなる電子メールをメール受信サーバ１３に送信する。

一方、受信可能サイズより大きいと、ステップＳ３４にて「Ｎｏ」と判定して、次のステップＳ３５にて、最後の変換要素であるか否か、即ち、次の変換要素があるか否かの判定を行う。ここで、次の変換要素がない場合は、ステップＳ３５にて「Ｙｅｓ」と判定して、変換後のフォーマット（コンテンツ）からなる電子メールをメール受信サーバ１３に送信する。これにより、メール受信サーバ１３は、上述したステップＳ２８（図２参照）に進めて、変換後のフォーマット（コンテンツ）からなる電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

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

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

（１）第１変換例
まず、変換シナリオ１に基づく第１変換例を図１２（なお、図１２は第１変換例を模式的に示す図である）に基づいて説明する。この場合は、本文＋ヘッダのサイズは１Ｋで、表示サイズは６４０×４８０で、画像サイズは３０Ｋで、表示色は２４万色の画像１と、表示サイズは６４０×４８０で、画像サイズは３０Ｋで、表示色は２４万色の画像２からなる添付ファイルを有する電子メールを受信したものとする。図１２において、添付ファイル（画像１、２）のフォーマット（コンテンツ）はｊｐｇであり、このアカウント（０９０−００００−０００１）の場合、図１１に示すように、ユーザエージェント(Vodafone/1.0/V802SH)から使用中の移動機の機種名がＶ８０２ＳＨに特定され、そのコンテンツリストはＧとなり、図８に示すように、変換シナリオは変換シナリオ１となる。

そして、図９に示すコンテンツリストＧに対応する受信可能フォーマット（コンテンツ）リストより、使用中の移動機の機種は受信可能なフォーマット（コンテンツ）（ｊｐｇ）であることが分かるので、フォーマット（コンテンツ）の変換は行われないこととなる。この場合、受信した電子メールサイズは本文＋ヘッダが１Ｋで、画像１のサイズは３０Ｋで、画像２のサイズは３０Ｋであるので、電子メールの合計のサイズは６１Ｋとなる。そこで、変換要素１に基づいて１回目の変換を行うこととなる。

この機種（Ｖ８０２ＳＨ）に対応する変換要素１（図１１（ｂ）のＶ８０２ＳＨの静止画の変換要素１）により、変換機能部１５は、変換エンジン部１６に用意された画像変換エンジンを用いて、画像１および画像２はともに表示サイズが３２０×２４０で、画像サイズが１５Ｋで、表示色が２４万色にサイズ変換される。これにより、電子メールの合計のサイズは３１Ｋとなるので、この機種の受信可能サイズである３０Ｋを超えるので、静止画の変換要素２に基づいて２回目のサイズ変換が行なわれることとなる。この２回目のサイズ変換により、電子メールの合計のサイズは２１Ｋとなるので、変換機能部１５はこれを採用して変換後の電子メールをメール受信サーバ１３に送信する。これにより、メール受信サーバ１３は変換されたフォーマット（コンテンツ）が添付された電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

（２）第２変換例
ついで、変換シナリオ１に基づく第２変換例を図１３（なお、図１３は第２変換例を模式的に示す図である）に基づいて説明する。この場合は、本文＋ヘッダのサイズは１Ｋで、フォーマット（コンテンツ）はｂｍｐで、表示サイズが６４０×４８０で、画像サイズが６０Ｋで、表示色が２４万色の画像１と、フォーマット（コンテンツ）はｂｍｐで、表示サイズが６４０×４８０で、画像サイズが６０Ｋで、表示色が２４万色の画像２からなる添付ファイルを有する電子メールを受信したものとする。このアカウント（０９０−００００−０００１）の場合、図１１に示すように、ユーザエージェント(Vodafone/1.0/V802SH)から使用中の移動機の機種名がＶ８０２ＳＨに特定され、そのコンテンツリストはＧとなり、図８に示すように、変換シナリオは変換シナリオ１となる。

そして、図９に示すコンテンツリストＧに対応する受信可能フォーマット（コンテンツ）リストより、ｂｍｐは、使用中の移動機の機種は受信可能なフォーマット（コンテンツ）であるｊｐｇやｐｎｇでないことが分かる。この場合、ｂｍｐは、図１０に示す変換可能なコンテンツカテゴリの静止画のカテゴリにリストアップされているので、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応するｊｐｇへの変換が行われることとなる。そして、画像１は表示サイズが６４０×４８０で、画像サイズが３０Ｋで、表示色が２４万色のｊｐｇのフォーマット（コンテンツ）に変換され、画像２は表示サイズが６４０×４８０で、画像サイズが３０Ｋで、表示色が２４万色のｊｐｇのフォーマット（コンテンツ）に変換される。

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

これにより、電子メールの合計のサイズは３１Ｋとなるので、この機種（Ｖ８０２ＳＨ）の受信可能サイズである３０Ｋを超えることとなる。このため、静止画の変換要素２に基づいて２回目のサイズ変換が行なわれる。この２回目のサイズ変換により、電子メールの合計のサイズは２１Ｋとなるので、変換機能部１５はこれを採用して変換後の電子メールをメール受信サーバ１３に送信する。これにより、メール受信サーバ１３は変換されたフォーマット（コンテンツ）が添付された電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

（３）第３変換例
ついで、変換シナリオ１に基づく第３変換例を図１４（なお、図１４は第３変換例を模式的に示す図である）に基づいて説明する。この場合は、本文＋ヘッダのサイズは１Ｋで、フォーマット（コンテンツ）はｂｍｐで、表示サイズが６４０×４８０で、画像サイズが６０Ｋで、表示色が２４万色の画像１と、フォーマット（コンテンツ）は３ｇｐで、表示サイズが１７６×１４４で、フレーム数が３０ｆｐｓで、ビットレートが６４ｋｂｐｓで、サイズが６０Ｋの動画１からなる添付ファイルを有する電子メールを受信したものとする。このアカウント（０９０−００００−０００１）の場合、図１１に示すように、ユーザエージェント(Vodafone/1.0/V802SH)から使用中の移動機の機種名がＶ８０２ＳＨに特定され、そのコンテンツリストはＧとなり、図８に示すように、変換シナリオは変換シナリオ１となる。

そして、図９に示すコンテンツリストＧに対応する受信可能フォーマット（コンテンツ）リストより、ｂｍｐは、使用中の移動機の機種は受信可能なフォーマット（コンテンツ）であるｊｐｇやｐｎｇでないことが分かる。この場合、ｂｍｐは、図１０に示す変換可能なコンテンツカテゴリの静止画のカテゴリにリストアップされているので、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応するｊｐｇへの変換が行われることとなる。一方、３ＧＰは使用中の移動機の機種は受信可能なフォーマット（コンテンツ）にリストアップされているので、フォーマット（コンテンツ）の変換は行われないこととなる。そして、画像１は表示サイズが６４０×４８０で、画像サイズが３０Ｋで、表示色が２４万色のｊｐｇのフォーマット（コンテンツ）に変換される。

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

これにより、電子メールの合計のサイズは４６Ｋとなるので、この機種（Ｖ８０２ＳＨ）の受信可能サイズである３０Ｋを超えることとなる。このため、静止画および動画の変換要素２に基づいて、図１４に示すように２回目のサイズ変換が行なわれることとなる。この２回目のサイズ変換によっても、電子メールの合計のサイズは３５Ｋで３０Ｋ以下にならないため、静止画および動画の変換要素３に基づいて、３回目のサイズ変換が行なわれることとなる。これにより、図１４により電子メールの合計のサイズは２１Ｋとなるので、変換機能部１５はこれを採用して変換後の電子メールをメール受信サーバ１３に送信する。これにより、メール受信サーバ１３は変換されたフォーマット（コンテンツ）からなる添付ファイルを有する電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

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

このアカウント（０９０−００００−０００１）の場合、図１１に示すように、ユーザエージェント(Vodafone/1.0/V802SH)から使用中の移動機の機種名がＶ８０２ＳＨに特定され、そのコンテンツリストはＧとなり、図８に示すように、変換シナリオは変換シナリオ１となる。そして、図９に示すコンテンツリストＧに対応する受信可能フォーマット（コンテンツ）リストより、ｂｍｐは、使用中の移動機の機種は受信可能なフォーマット（コンテンツ）であるｊｐｇやｐｎｇでないことが分かる。この場合、ｂｍｐは、図１０に示す変換可能なコンテンツカテゴリの静止画のカテゴリにリストアップされているので、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応するｊｐｇへの変換が行われることとなる。また、ｍｉｄは使用中の移動機の機種は受信可能なフォーマット（コンテンツ）であるｍｍｆやｓｍｄでないことが分かる。この場合、ｍｉｄは、図１０に示す変換可能なコンテンツカテゴリの着信メロディー（ｍｉｄｉ）のカテゴリにリストアップされているので、受信可能フォーマット（コンテンツ）リスト（図９参照）の着信メロディー（ｍｉｄｉ）のコンテンツ１に対応するｍｍｆへの変換が行われることとなる。

一方、ファイルサイズは本文＋ヘッダのサイズが１Ｋで、ｊｐｇに変換された画像１のサイズは３０Ｋで、ｍｍｆに変換された着信メロディーのサイズは５Ｋで、動画１のサイズは６０Ｋであるので、合計のサイズは９６Ｋとなる。そこで、上述と同様に、ステップ３１ｂにて受信可能なサイズか否かの判定をした後、図１５に示すように、この機種（Ｖ８０２ＳＨ）の受信可能サイズである３０Ｋ以下になるように、変換要素１に基づいて１回目のサイズ変換を行い、変換要素２に基づいて２回目のサイズ変換を行い、変換要素３に基づいて３回目のサイズ変換が行なわれることとなる。これにより、図１５に示すように、３回目のサイズ変換により電子メールの合計のサイズは２６Ｋとなり、変換機能部１５はこれを採用して変換後の電子メールをメール受信サーバ１３に送信する。これにより、メール受信サーバ１３は変換後のフォーマット（コンテンツ）からなる添付ファイルを有する電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

（５）第５変換例
ついで、変換シナリオ１に基づく第５変換例を図１６（なお、図１６は第５変換例を模式的に示す図である）に基づいて説明する。この場合は、本文＋ヘッダのサイズは１Ｋで、フォーマット（コンテンツ）はｂｍｐで、表示サイズが６４０×４８０で、画像サイズが６０Ｋ、表示色が２４万色の画像１と、フォーマット（コンテンツ）はｚｉｐで、サイズ画３０Ｋのその他の添付ファイルを有する電子メールを受信したものとする。このアカウント（０９０−００００−０００１）の場合、図１１に示すように、ユーザエージェント(Vodafone/1.0/V802SH)から使用中の移動機の機種名がＶ８０２ＳＨに特定され、そのコンテンツリストはＧとなり、図８に示すように、変換シナリオは変換シナリオ１となる。

そして、図９に示すコンテンツリストＧに対応する受信可能フォーマット（コンテンツ）リストより、ｂｍｐは、使用中の移動機の機種は受信可能なフォーマット（コンテンツ）であるｊｐｇやｐｎｇでないことが分かる。この場合、ｂｍｐは、図１０に示す変換可能なコンテンツカテゴリの静止画のカテゴリにリストアップされているので、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応するｊｐｇへの変換が行われることとなる。また、ｚｉｐは使用中の移動機の機種は受信可能なフォーマット（コンテンツ）でないことが分かる。この場合、ｚｉｐは、図１０に示す変換可能なコンテンツカテゴリのその他にリストアップされているが、受信可能フォーマット（コンテンツ）リスト（図９参照）のその他の項には存在しないため、無変換のままとなる。

一方、ファイルサイズは本文＋ヘッダのサイズが１Ｋで、ｊｐｇに変換された画像１のサイズは３０Ｋで、無変換のｚｉｐのサイズは３０Ｋであるので、合計のサイズは６１Ｋとなる。そこで、ステップＳ３１ｂにて、受信可能なサイズか否かの判定をした後、図１６に示すように、変換要素１に基づいて１回目のサイズ変換を行い、変換要素２に基づいて２回目のサイズ変換を行い、変換要素３に基づいて３回目のサイズ変換を行うこととなる。この場合、３回目のサイズ変換により合計のサイズは３９Ｋとなって、この機種（Ｖ８０２ＳＨ）の受信可能サイズである３０Ｋ以下とはならない。このため、ｊｐｇに変換された画像１は、表示サイズが１６０×１２０で、表示色が２４万色で、画像サイズが８Ｋに変換され、ｚｉｐファイルは無変換（３０Ｋのまま）で、メール受信サーバ１３に送信する。これにより、メール受信サーバ１３は変換された画像１および無変換のｚｉｐファイルが添付された電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

３．変換シナリオ２の処理
ここで、ステップＳ２３にて転送されて変換機能部１５が受信した変換シナリオが変換シナリオ２であると、変換機能部１５は、図４のステップＳ４０にて変換シナリオ２の変換処理を開始する。すると、ステップＳ４１において、受信した電子メールに添付されたファイルはフォーマット（コンテンツ）の変換が必要か否かの判定を行う。ここで、受信した電子メールに添付されたファイルが、上述のステップＳ２３にてユーザディレクトリ１４ａから取得したコンテンツリストに対応した受信可能フォーマット（コンテンツ）リスト（図９参照）にリストアップされていれば、フォーマット（コンテンツ）の変換を行う必要がないので、ステップＳ４１にて「Ｎｏ」と判定して、ステップＳ４１ｂに進める。

一方、受信した電子メールに添付されたファイルが、受信可能フォーマット（コンテンツ）リスト（図９参照）に存在しない場合は、ステップＳ４１にて「Ｙｅｓ」と判定して、ステップＳ４１ａに進め、上述のステップＳ２３にてユーザディレクトリ１４ａから取得した変換可能なコンテンツカテゴリリスト（図１０参照）にリストアップされていれば、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に変換できるような適切な変換エンジンを変換エンジン部１６に選択させ、変換エンジン部１６が選択した変換エンジンにより受信した電子メールの添付ファイルのフォーマット（コンテンツ）の変換を依頼する。

この場合、変換エンジン部１６は、用意された画像変換エンジン、映像変換エンジン、ｍｉｄｉ変換エンジン、ドキュメント変換エンジン、マークアップランゲージ変換エンジンなどから受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応する変換エンジンを選択し、選択した変換エンジンを用いてフォーマット（コンテンツ）の変換処理を実行することとなる。この後、変換機能部１５は、変換エンジン部１６で変換がなされたフォーマット（コンテンツ）を取得し、当該フォーマット（コンテンツ）のファイルを電子メールに添付して電子メールの形に再変換を行う。

ついで、ステップＳ４１ｂにおいて、電子メールの全サイズの合計が受信側端末装置（ＭＳ−２）の受信可能サイズ（図１１参照）以下か否かの判定を行う。ここで、受信可能サイズ以下であれば、変換機能部１５はステップＳ４１ｂにて「Ｙｅｓ」と判定して、ステップＳ４９ａにて、電子メールをメール受信サーバ１３に送信する。すると、メール受信サーバ１３は、上述したステップＳ２７（図２参照）にて、メール受信サーバ１３は変換機能部１５から変換後の電子メールを受信し、次のステップＳ２８に進めて、変換後の電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

一方、受信可能サイズを超えていると、ステップＳ４１ｂにて「Ｎｏ」と判定して、次のステップＳ４２に進める。ついで、ステップＳ４２において、取得した第２プロファイル情報（図１１参照）から変換要素１を指定する。この後、ステップＳ４３にて、添付されている全ての添付ファイルを変換要素１に基づいて変換する。ついで、ステップＳ４４に進め、変換後の全電子メールサイズの合計が受信側端末装置（ＭＳ−２）の受信可能サイズ（図１１参照）以下か否かの判定を行う。

ここで、受信可能サイズ以下であれば、ステップＳ４４にて「Ｙｅｓ」と判定して、ステップＳ４９ａにて、変換後の電子メールをメール受信サーバ１３に送信する。一方、受信可能サイズを超えていると、ステップＳ４４にて「Ｎｏ」と判定して、次のステップＳ４５にて、最後の変換要素であるか否か、即ち、次の変換要素があるか否かの判定を行う。ここで、次の変換要素がある場合は、ステップＳ４５にて「Ｎｏ」と判定して、次のステップＳ４６において、取得した第２プロファイル情報から次の変換要素（この場合は変換要素２となる）を指定する、ついで、ステップＳ４３に戻り、次の変換要素がなくなるまで上述のステップＳ４３〜ステップＳ４６までの変換処理を繰り返して実行する。
なお、この変換シナリオ２の処理においても、変換シナリオ１の場合と同様に、フォーマット（コンテンツ）を指定の変換要素で変換する場合に、受信可能サイズをできる限り大きくするために受信側端末装置（ＭＳ−２）に不要な情報（例えば、ｊｐｇのＥｘｉｆ情報やサムネイルなどの付加情報）は削除するようにするのが望ましい。

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

前回あるいは前々回の変換要素による変換後の全電子メールサイズが受信可能サイズ以下にならない場合は、ステップＳ４８において「Ｎｏ」と判定して、ステップＳ４９ａにて、最後に変換した変換後のフォーマット（コンテンツ）からなるファイルを添付した電子メールをメール受信サーバ１３に送信する。また、前回あるいは前々回の変換要素による変換後の全電子メールサイズが受信可能サイズ以下であった場合は、ステップＳ４８において「Ｙｅｓ」と判定して、次のステップＳ４９において、変換機能部１５は変換後のフォーマット（コンテンツ）からなるファイルとして前回あるいは前々回の変換要素による変換ファイルを採用してメール受信サーバ１３に送信する。

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

ここで、変換シナリオ２に基づく電子メールの変換例を図１７（なお、図１７は変換例を模式的に示す図である）に基づいて説明する。この場合、変換シナリオ２を採用するアカウント（電話番号は０９０−００００−０００２で、機種の種別がＶ８０２ＳＥのもの）の受信側端末装置（ＭＳ−２）宛の添付ファイルを有する電子メールを受信した例について以下に説明する。この場合は、本文＋ヘッダのサイズは１Ｋで、フォーマット（コンテンツ）がｂｍｐで、表示サイズは６４０×４８０で、画像サイズは６０Ｋで、表示色は２４万色の画像１と、フォーマット（コンテンツ）がｚｉｐで、サイズが３０Ｋのファイルを有する電子メールを受信したものとする。このアカウント（０９０−００００−０００２）の場合、図１１に示すように、ユーザエージェント(Vodafone/1.0/V802SE)から使用中の移動機の機種名がＶ８０２ＳＥに特定され、そのコンテンツリストはＨとなり、図８に示すように、変換シナリオは変換シナリオ２となる。

そして、図９に示すコンテンツリストＨに対応する受信可能フォーマット（コンテンツ）リストより、ｂｍｐは、使用中の移動機の機種は受信可能なフォーマット（コンテンツ）であるｊｐｇやｐｎｇであることが分かる。この場合、ｂｍｐは、図１０に示す変換可能なコンテンツカテゴリの静止画のカテゴリにリストアップされているので、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応するｊｐｇへの変換が行われることとなる。一方、その他のｚｉｐは無変換のままとなる。そして、受信した電子メールサイズは本文＋ヘッダのサイズが１Ｋで、ｊｐｇに変換された画像１のサイズは３０Ｋで、その他のｚｉｐのサイズは３０Ｋであるので、電子メールの合計のサイズは６１Ｋとなる。そこで、ステップＳ４１ｂでサイズの判定が行われるが、この移動機の機種（Ｖ８０２ＳＥ）の受信可能サイズは３０Ｋ（図１１参照）であるので、変換要素１に基づいて１回目のサイズ変換を行うこととなる。

この機種（Ｖ８０２ＳＥ）に対応する変換要素１（図１１（ｂ）のＶ８０２ＳＥの静止画の変換要素１）により、画像１は表示サイズが３２０×２４０で、画像サイズが１５Ｋで、表示色が２４万色になるように変換される。これにより、電子メールの合計のサイズは４６Ｋとなるので、この機種の受信可能サイズである３０Ｋを超えるので、静止画の変換要素２に基づいて２回目のサイズ変換が行なわれることとなる。この２回目のサイズ変換により、電子メールの合計のサイズは４１Ｋとなるので、静止画の変換要素３に基づいて３回目のサイズ変換が行なわれる。これにより、電子メールの合計のサイズは３９Ｋとなるため、受信可能サイズの３０Ｋを超えるその他のフォーマット（コンテンツ）からなるファイル（ｚｉｐ）は削除される。
この場合、変換要素１に基づいて変換されたサイズが１５Ｋの前々回の変換後のフォーマット（コンテンツ）からなるファイルが採用（ステップＳ４８参照）され、合計で１６Ｋとなるフォーマット（コンテンツ）からなるファイルが添付された電子メールが受信側端末装置（ＭＳ−２）に配信される。

４．変換シナリオ３の処理
ここで、ステップＳ２２にて転送されて変換機能部１５が受信した変換シナリオが変換シナリオ３であると、変換機能部１５は、図５のステップＳ５０にて、変換シナリオ３の変換処理を開始する。すると、ステップＳ５１において、受信した電子メールに添付されたファイルはフォーマット（コンテンツ）の変換が必要か否かの判定を行う。ここで、受信した電子メールに添付されたファイルが、上述のステップＳ２３にてユーザディレクトリ１４ａから取得したコンテンツリストに対応した受信可能フォーマット（コンテンツ）リスト（図９参照）にリストアップされていれば、フォーマット（コンテンツ）の変換を行う必要がないので、ステップＳ５１にて「Ｎｏ」と判定して、ステップＳ５１ｂに進める。

一方、受信した電子メールに添付されたファイルが、受信可能フォーマット（コンテンツ）リスト（図９参照）に存在しない場合は、ステップＳ５１にて「Ｙｅｓ」と判定して、ステップＳ５１ａに進め、上述のステップＳ２３にてユーザディレクトリ１４ａから取得した変換可能なコンテンツカテゴリリスト（図１０参照）にリストアップされていれば、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に変換できるような適切な変換エンジンを変換エンジン部１６に選択させ、変換エンジン部１６が選択した変換エンジンにより受信した電子メールの添付ファイルのフォーマット（コンテンツ）の変換を依頼する。

この場合、変換エンジン部１６は、用意された画像変換エンジン、映像変換エンジン、ｍｉｄｉ変換エンジン、ドキュメント変換エンジン、マークアップランゲージ変換エンジンなどから受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応する変換エンジンを選択し、選択した変換エンジンを用いてフォーマット（コンテンツ）の変換処理を実行することとなる。この後、変換機能部１５は、変換エンジン部１６で変換がなされたフォーマット（コンテンツ）を取得し、当該フォーマット（コンテンツ）のファイルを電子メールに添付して電子メールの形に再変換を行う。

ついで、ステップＳ５１ｂにおいて、電子メールの全サイズの合計が受信側端末装置（ＭＳ−２）の受信可能サイズ（図１１参照）以下か否かの判定を行う。ここで、受信可能サイズ以下であれば、ステップＳ５１ｂにて「Ｙｅｓ」と判定して、ステップＳ５９にて、電子メールをメール受信サーバ１３に送信する。すると、メール受信サーバ１３は、上述したステップＳ２７（図２参照）にて変換機能部１５から変換後のフォーマット（コンテンツ）からなるファイルが添付された電子メールを受信し、次のステップＳ２８に進めて、電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

一方、受信可能サイズを超えていると、ステップＳ５１ｂにて「Ｎｏ」と判定して、次のステップＳ５２に進める。ついで、ステップＳ５２において取得した第２プロファイル情報（図１１参照）から変換要素１を指定するとともに、受信した電子メールに添付されたファイルの内、最後の添付番号（ｎ）のファイルを指定する。この後、ステップＳ５３にて、最後の添付番号（ｎ）の添付ファイルを変換要素１に基づいて変換する。ついで、ステップＳ５４に進め、添付番号（ｎ）の添付ファイルでの変換後の電子メールサイズの合計が受信可能サイズ（図１１参照）以下か否かの判定を行う。

ここで、受信可能サイズ以下であれば、ステップＳ５４にて「Ｙｅｓ」と判定して、ステップＳ５９にて、変換後のフォーマット（コンテンツ）からなるファイルが添付された電子メールをメール受信サーバ１３に送信する。一方、変換後の電子メールのサイズ合計が受信可能サイズを超えていると、ステップＳ５４にて「Ｎｏ」と判定して、次のステップＳ５５にて、最後の変換要素であるか否か、即ち、次の変換要素があるか否かの判定を行う。次の変換要素がある場合は、ステップＳ５５にて「Ｎｏ」と判定して、次のステップＳ５６において取得した第２プロファイル情報（図１１参照）から次の変換要素（この場合は変換要素２となる）を指定した後、ステップＳ５３に戻り、次の変換要素がなくなるまでステップＳ５３〜ステップＳ５６の処理を繰り返して実行する。

上述したステップＳ５３〜ステップＳ５６の処理を繰り返して実行している内に次の変換要素がなくと、ステップＳ５５にて「Ｙｅｓ」と判定して、次のステップＳ５７に進み、前の添付番号（ｎ−１）の添付ファイルが有るか否かの判定を行う。前の添付番号（ｎ−１）の添付ファイルがない場合は、ステップＳ５７にて「Ｎｏ」と判定して、ステップＳ５９にて、変換後のフォーマット（コンテンツ）が添付された電子メールをメール受信サーバ１３に送信する。

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

上述したステップＳ５３、ステップＳ５４、ステップＳ５５、ステップＳ５７、ステップＳ５８の処理を繰り返して実行している内に、前の添付番号（ｎ−１）の添付ファイルがなくなると、ステップＳ５７にて「Ｎｏ」と判定して、ステップＳ５９にて、変換後のフォーマット（コンテンツ）が添付された電子メールをメール受信サーバ１３に送信する。すると、メール受信サーバ１３は、上述したステップＳ２７（図２参照）にて変換後のフォーマット（コンテンツ）が添付された電子メールを受信し、次のステップＳ２８に進めて、変換後のフォーマット（コンテンツ）が添付された電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

なお、この変換シナリオ３の処理においても、受信可能サイズをできる限り大きくするために受信側端末装置（ＭＳ−２）に不要な情報（例えば、ｊｐｇのＥｘｉｆ情報やサムネイルなどの付加情報）は削除するようにするのが望ましい。
上述したように、本変換シナリオ３に基づく変換においては、添付されたファイルのフォーマット（コンテンツ）毎に変換を行うようにしている。このため、例えば、変換された添付ファイルのフォーマット（コンテンツ）が画像である場合は、さらに高解像度で高画質な画像が得られることとなる。

ここで、変換シナリオ３に基づく電子メールの変換例を図１８（なお、図１８は変換例を模式的に示す図である）に基づいて説明する。この場合、変換シナリオ３を採用するアカウント（電話番号は０９０−００００−０００３で、機種の種別がＶ８０２ＳＥのもの）の受信側端末装置（ＭＳ−２）宛の添付ファイルを有する電子メールを受信した例について以下に説明する。この場合は、本文＋ヘッダのサイズは１Ｋで、フォーマット（コンテンツ）がｊｐｇで、表示サイズは３２０×２４０で、画像サイズは１５Ｋで、表示色は２４万色の画像１、２、３からなる添付ファイルを有する電子メールを受信したものとする。
このアカウント（０９０−００００−０００３）の場合、図１１に示すように、ユーザエージェント(Vodafone/1.0/V802SE)から使用中の移動機の機種名がＶ８０２ＳＥに特定され、そのコンテンツリストはＨとなり、図８に示すように、変換シナリオは変換シナリオ３となる。

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

このため、前の添付ファイルとなる画像２について、変換要素１に基づいて４回目のサイズ変換を行い、変換要素２に基づいて５回目のサイズ変換を行い、変換要素３に基づいて６回目のサイズ変換を行うこととなる。この６回目のサイズ変換により、図１８に示すように、電子メールの合計のサイズは３２Ｋとなって、受信可能サイズの３０Ｋを超えるサイズとなる。このため、さらに前の添付ファイルとなる画像１について、変換要素１に基づいて７回目のサイズ変換を行い、変換要素２に基づいて８回目のサイズ変換を行うこととなる。この８回目のサイズ変換により、図１８に示すように、電子メールの合計のサイズは２７Ｋとなって、受信可能サイズの３０Ｋ以下となる。これにより、画像３については３回目のサイズ変換によるファイルが、画像２については６回目のサイズ変換によるファイルが、画像１については８回目のサイズ変換によるファイルが採用され、これらのファイルが添付された電子メールが受信側端末装置（ＭＳ−２）に配信されることとなる。

５．変換シナリオ４の処理
ここで、ステップＳ２２にて転送されて変換機能部１５が受信した変換シナリオが変換シナリオ４であると、変換機能部１５は、図６のステップＳ６０にて、変換シナリオ４の変換処理を開始する。すると、ステップＳ６１において、受信した電子メールに添付されたファイルはフォーマット（コンテンツ）の変換が必要か否かの判定を行う。ここで、受信した電子メールに添付されたファイルが、上述のステップＳ２３にてユーザディレクトリ１４ａから取得したコンテンツリストに対応した受信可能フォーマット（コンテンツ）リスト（図９参照）にリストアップされていれば、フォーマット（コンテンツ）の変換を行う必要がないので、ステップＳ６１にて「Ｎｏ」と判定して、ステップＳ６１ｂに進める。

一方、受信した電子メールに添付されたファイルが、受信可能フォーマット（コンテンツ）リスト（図９参照）に存在しない場合は、ステップＳ６１にて「Ｙｅｓ」と判定して、ステップＳ６１ａに進め、上述のステップＳ２３にてユーザディレクトリ１４ａから取得した変換可能なコンテンツカテゴリリスト（図１０参照）にリストアップされていれば、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に変換できるような適切な変換エンジンを変換エンジン部１６に選択させ、変換エンジン部１６が選択した変換エンジンにより受信した電子メールの添付ファイルのフォーマット（コンテンツ）の変換を依頼する。

この場合、変換エンジン部１６は、用意された画像変換エンジン、映像変換エンジン、ｍｉｄｉ変換エンジン、ドキュメント変換エンジン、マークアップランゲージ変換エンジンなどから受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応する変換エンジンを選択し、選択した変換エンジンを用いてフォーマット（コンテンツ）の変換処理を実行することとなる。この後、変換機能部１５は、変換エンジン部１６で変換がなされたフォーマット（コンテンツ）を取得し、当該フォーマット（コンテンツ）のファイルを電子メールに添付して電子メールの形に再変換を行う。

ついで、ステップＳ６１ｂにおいて、電子メールの全サイズの合計が受信側端末装置（ＭＳ−２）の受信可能サイズ（図１１参照）以下か否かの判定を行う。ここで、受信可能サイズ以下であれば、ステップＳ６１ｂにて「Ｙｅｓ」と判定して、ステップＳ６９ｂにて、変換後のフォーマット（コンテンツ）からなるファイルが添付された電子メールをメール受信サーバ１３に送信する。すると、メール受信サーバ１３は、上述したステップＳ２７（図２参照）にて変換後のフォーマット（コンテンツ）からなるファイルが添付された電子メールを受信し、次のステップＳ２８に進めて、変換後のフォーマット（コンテンツ）からなるファイルが添付された電子メールを受信側端末装置（ＭＳ−２）に配信することとなる。

一方、受信可能サイズを超えていると、ステップＳ６１ｂにて「Ｎｏ」と判定して、次のステップＳ６２に進める。ついで、ステップＳ６２において、受信側端末装置（ＭＳ−２）に対応している添付ファイルの順番を先頭に移動させる。ついで、ステップＳ６３において取得した第２プロファイル情報（図１１参照）から変換要素１を指定する。この後、ステップＳ６４にて、添付されている全ての添付ファイルを変換要素１に基づいて変換して、次のステップＳ６５へ進める。

ステップＳ６５に進むと、変換後の全電子メールサイズの合計が受信可能サイズ（図１１参照）以下か否かの判定を行う。ここで、受信可能サイズ以下であれば、ステップＳ６５にて「Ｙｅｓ」と判定して、ステップＳ６９ｂにて、変換後のフォーマット（コンテンツ）からなるファイルをメール受信サーバ１３に送信する。一方、受信可能サイズを超えていると、ステップＳ６５にて「Ｎｏ」と判定して、次のステップＳ６６にて、最後の変換要素であるか否か、即ち、次の変換要素があるか否かの判定を行う。

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

一方、次の変換要素がない場合は、ステップＳ６６にて「Ｙｅｓ」と判定して、ステップＳ６８に進み、受信可能サイズより大きいファイルを削除する。ついで、ステップＳ６９にて、前回あるいは前々回の変換要素による、変換後の合計のサイズが受信可能サイズ以下であるか否かの判定を行う。ここで、変換後の合計のサイズが受信可能サイズを超えている場合は、ステップＳ６９にて「Ｎｏ」と判定して、ステップＳ６９ｂにて受信可能サイズを超えたままのファイルをメール受信サーバ１３に送信する。

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

ここで、変換シナリオ４に基づく電子メールの変換例を図１９（なお、図１９は変換例を模式的に示す図である）に基づいて説明する。この場合、変換シナリオ４を採用するアカウント（電話番号は０９０−００００−０００４で、機種の種別がＶ７０２ＭＯ）の受信側端末装置（ＭＳ−２）宛の添付ファイルを有する電子メールを受信した例について以下に説明する。この場合は、本文＋ヘッダのサイズは１Ｋで、フォーマット（コンテンツ）がｄｏｃで、サイズが２０Ｋのその他のファイルと、フォーマット（コンテンツ）がｇｉｆで、表示サイズは６４０×４８０で、画像サイズは４０Ｋで、表示色は２４万色の画像１と、フォーマット（コンテンツ）がｊｐｇで、表示サイズは３２０×２４０で、画像サイズは１５Ｋで、表示色は２４万色の画像２からなる添付ファイルを有する電子メールを受信したものとする。このアカウント（０９０−００００−０００４）の場合、図１１に示すように、ユーザエージェント(Vodafone/V702MO/1.0)から使用中の移動機の機種名がＶ７０２ＭＯに特定され、そのコンテンツリストはＤとなり、図８に示すように、変換シナリオは変換シナリオ４となる。

そして、図９に示すコンテンツリストＤに対応する受信可能フォーマット（コンテンツ）リストより、その他のファイルとなるフォーマットがｄｏｃのファイルは変換対象外のフォーマット（コンテンツ）であるので、無変換にする。一方、ｇｉｆは、使用中の移動機の機種（Ｖ７０２ＭＯ）は受信可能なフォーマット（コンテンツ）であるｊｐｇやｐｎｇでないことが分かる。この場合、ｇｉｆは、図１０に示す変換可能なコンテンツカテゴリの静止画のカテゴリにリストアップされているので、受信可能フォーマット（コンテンツ）リスト（図９参照）のコンテンツ１に対応するｊｐｇへの変換が行われることとなる。さらに、ｊｐｇは、使用中の移動機の機種（Ｖ７０２ＭＯ）は受信可能なフォーマット（コンテンツ）であるので、フォーマット（コンテンツ）の変換は無変換となる。

図１９において、その他のファイルとなるフォーマットがｄｏｃのファイルは変換対象外のフォーマット（コンテンツ）であるので、無変換にする。一方、画像２のｊｐｇは対応するフォーマット（コンテンツ）（図９参照）であるので、フォーマット（コンテンツ）の変換は無変換となる。一方、画像１のフォーマット（コンテンツ）はｇｉｆであるので、対応しないフォーマット（コンテンツ）（図９参照）であるので、フォーマット（コンテンツ）をｊｐｇに変換する。そして、受信した電子メールサイズは本文＋ヘッダが１Ｋで、その他のサイズは２０Ｋで、ｊｐｇに変換後の画像１のサイズは３０Ｋで、画像２のサイズは１５Ｋであるので、合計サイズは６６Ｋとなり、ステップＳ６１ｂにてサイズの判定を行うが、この機種（Ｖ７０２ＭＯ）の受信可能サイズの３０Ｋであることから、変換要素１に基づいて第１回目の変換を行うこととなる。

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

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

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

これらのことは、前述した、変換シナリオ２（図１７）、変換シナリオ４（図１９）における超過ファイルの削除についても同様に行なうことができる。この場合、超過したファイルを削除することなく、メール受信サーバ１３により、後続ファイルの存在を受信側端末装置（ＭＳ−２）に通知するようにすればよい。なお、メール転送手続きを行なって、パソコンなどのメールアドレスへ転送してファイル取得できることは勿論のことである。

本発明の電子メール格納システムの概略構成を模式的に示すブロック図である。 図１に示されたメール受信サーバの処理動作の例を示すフローチャートである。 図２の処理動作における変換機能部での変換シナリオ１の処理動作の例を示すフローチャートである。 図２の処理動作における変換機能部での変換シナリオ２の処理動作の例を示すフローチャートである。 図２の処理動作における変換機能部での変換シナリオ３の処理動作の例を示すフローチャートである。 図２の処理動作における変換機能部での変換シナリオ４の処理動作の例を示すフローチャートである。 受信メールの一例を示す図である。 ユーザディレクトリの一例を示す図である。 コンテンツリストの一例を示す図であり、図９（ａ）は静止画に対応するコンテンツリストを示し、図９（ｂ）は動画に対応するコンテンツリストを示し、図９（ｃ）は着信メロディー（ｍｉｄｉファイル）に対応するコンテンツリストを示している。 変換可能なコンテンツカテゴリリストを示す図である。 受信端末プロファイルの一例を示す図であり、図１１（ａ）は受信したユーザエージェント情報に基づく機種の種別および受信可能サイズを示すプロファイルの一例であり、図１１（ｂ）は静止画に対応する変換要素を示すプロファイルの一例であり、図１１（ｃ）は動画に対応する変換要素を示すプロファイルの一例である。 変換シナリオ１による第１変換例を模式的に示す図である。 変換シナリオ１による第２変換例を模式的に示す図である。 変換シナリオ１による第３変換例を模式的に示す図である。 変換シナリオ１による第４変換例を模式的に示す図である。 変換シナリオ１による第５変換例を模式的に示す図である。 変換シナリオ２による変換例を模式的に示す図である。 変換シナリオ３による変換例を模式的に示す図である。 変換シナリオ４による変換例を模式的に示す図である。 従来の電子メールの受信システムの概略構成を模式的に示すブロック図である。 ＯＭＡやＷ３Ｃで提唱されている電子メールの受信システムの概略構成を模式的に示すブロック図である。

符号の説明

１０…ネットワーク、１１ａ…送信側メール配信サーバ、１１ｂ…受信側メール配信サーバ、１２…メールボックス、１３…メール受信サーバ、１４…ディレクトリサーバ、１４ａ…ユーザディレクトリ、１５…変換機能部、１６…変換エンジン部、１７…受信端末プロファイル、１８…ショートメッセージサービスセンタ（ＳＭＳＣ）

Claims (2)

1. 送信側端末装置から送信された電子メールをメールボックスに格納し、該メールボックスに格納された電子メールを受信側端末装置に配信するようにした電子メール配信システムであって、
   前記送信側端末装置から送信された電子メールを受信して当該電子メールをメールボックスに格納させるメール配信サーバと、
   前記受信側端末装置からの配信要求に基づいて前記メールボックスに格納された電子メールを当該受信側端末装置に配信するとともに、前記受信側端末装置からの配信要求時に当該受信側端末装置のユーザ識別情報とユーザエージェント情報を取得するメール受信サーバと、
   前記メールボックスの所在やユーザ識別情報や前記受信側端末装置に対して予め登録された変換方法もしくは変換条件を定義する変換シナリオを含むユーザアカウント情報とユーザ識別情報に対応した受信可能なフォーマットリストと変換可能なコンテンツカテゴリリストとを含む第１プロファイル情報とを格納するユーザディレクトリと、
   前記受信側端末装置の受信可能サイズや受信可能フォーマットや変換要素の少なくとも１つを含む情報をデータベース化した当該受信側端末装置に関する第２プロファイル情報を格納する受信端末プロファイルと、
   前記マルチメディア・データのフォーマットやコーデックを変換する少なくとも１つ以上の変換エンジンとを備え、
   前記メール受信サーバは前記受信側端末装置からの配信要求時に取得したユーザ識別情報に基づいて前記ユーザディレクトリから前記ユーザアカウント情報と前記第１プロファイル情報とを取得するとともに、前記配信要求時に同時に取得したユーザエージェント情報に基づいて前記受信端末プロファイルから当該受信側端末装置に関する第２プロファイル情報を取得して、取得した前記第２プロファイル情報に基づいて、前記メールボックスに格納された電子メールに変換処理を施す必要であるか否かを判定する判定手段を備え、
   前記判定手段により判定された結果、変換処理を必要と判定したときは、前記ユーザアカウント情報の変換方法もしくは変換条件を定義する変換シナリオに基づいて当該電子メールを前記変換エンジンにより前記受信側端末装置が受信可能なフォーマットやサイズや変換要素に変換させて、変換された電子メールを前記受信側端末へ配信するようにしたことを特徴とする電子メール配信システム。
2. 前記受信側端末装置はインターネット接続機能を有する端末装置または移動体通信事業者が提供するインターネットゲートウェイに接続して電子メールを送受信できる端末装置であることを特徴とする請求項１に記載の電子メール配信システム。

Images