JP2001217876A - 情報通信方法および情報通信装置 - Google Patents

Abstract

(57)【要約】 【課題】 中継サーバを利用した情報通信方式、および
情報通信装置において添付ファイル付き電子メールの特
に受信時において下位機種互換、他機種互換を図る。 【解決手段】 中継サーバにて分割され送信された電子
メールの統合などの処理を行い、通知メールに添付ファ
イルを記憶したＵＲＬを付けて送るよう構成することに
より下位機種互換、他機種互換を図ることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、携帯電話等の携
帯無線装置(以下、携帯電話と記す。ＰＨＳ（Ｐｅｒｓ
ｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）端末
を含む。）より発信された電子メールを、中継サーバ装
置（以下、単に中継サーバと記す。）を仲介し送受信を
行う際の情報通信方法及び情報通信システムに関する。

【０００２】

【従来の技術】携帯電話は４７００万人という膨大なユ
ーザーを取り込み、電子メールサービスを手始めに、イ
ンターネット接続、情報提供サービス、オンラインバン
キングなど情報携帯端末としての地位を固めつつある。
特に、１９９９年２月からＮＴＴ移動通信網株式会社
（以下、ＮＴＴドコモと称す）が開始した”ｉモード”
サービス（以下、ｉモードと記す。）はこれまでの携帯
電話とは異なり、音声通話以外に電子メールをはじめ、
オンラインバンキング（銀行の残高照会・振り込み）、
レストランガイド、タウンページ検索など生活に密接し
たサービスが携帯電話を用いて利用することができる。

【０００３】一方、２００１年より商用化が予定されて
いるＷ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉ
ｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）通信
方式では、データ通信速度が飛躍的に改善され携帯電話
での動画像コンテンツの送受信が可能となる。

【０００４】それに伴い、イメージセンサー（カメラ）
と携帯電話を組み合わせ、動画像を送受信できる製品の
市場投入が予想される。また、Ｗ−ＣＤＭＡ通信方式を
採用した携帯電話の市場投入に先駈け、オプションとし
てディジタルカメラと接続し静止画像を送受信すること
のできる携帯電話が１９９９年４月より株式会社ツーカ
セルラー東京、株式会社ツーカセルラー東海等により構
成されるツーカグループによって製品化された。

【０００５】今後、携帯電話を用いて画像データの送受
信を行う製品が各社より市場投入されると予想される。
以下、上記ＮＴＴドコモのｉモードを例に携帯電話を用
いて静止画像の送受信を行う場合のシステム（画像送受
信携帯電話システム）について説明する。

【０００６】まずはじめ、従来の静止画像を送受信する
システムの説明を行う前に、上記ｉモードに関して簡単
に説明する。ｉモードはＮＴＴドコモが開始した新しい
データ通信サービスでパケット通信方式を採用してい
る。ｉモードで採用されている上記パケット通信方式で
は、従来の接続時間による課金ではなく送受信したデー
タ量（パケット数）に応じて課金される。

【０００７】また、ｉモードでの電子メールはｉモード
携帯電話同士はもちろん、現在一般的になりつつあるイ
ンターネットを介したメール（以下、インターネットメ
ールと称す）にも対応しており、携帯電話を用いてイン
ターネットメールの送受信を行うことができる。

【０００８】さらに、ｉモード携帯電話は、インターネ
ットのホームページ上に公開された情報コンテンツを閲
覧するためにＣｏｍｐａｃｔＨＴＭＬをサポートしたｉ
モード携帯電話用のインターネットブラウザーを搭載し
ており、ｉモード対応で作成されたインターネットのホ
ームページ等を閲覧することができる。

【０００９】また、ｉモード携帯電話ではＧＩＦ（Ｇｒ
ａｐｈｉｃ Ｉｎｔｅｒｃｈａｎｇｅ Ｆｏｒｍａｔ）
ファイル形式の画像データのデコーダを標準搭載してお
り、該画像データファイルをインターネット上よりダウ
ンロードし携帯電話の液晶上に表示することができる。

【００１０】図６にｉモードの基本システム構成図を示
す。図において１は発信側ｉモード携帯電話、２は受信
側ｉモード携帯電話、３は中継基地、４は例えばドコモ
通信網のような音声通信網、５は例えばドコモのデータ
通信網ＤｏＰａ（ドゥーパ）のようなパケット通信網、
６は例えばドコモゲートウェイサーバのようなゲートウ
ェイサーバ、７はインターネット網である。

【００１１】図６を用いてｉモードシステムを簡単に説
明する。図６に示すように、発信側ｉモード携帯電話１
および受信側ｉモード携帯電話２間の通常の音声通話で
は音声通信網（ＰＤＣ。Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔ
ａｌ Ｃｅｌｌｕｌａｒ）４を使用する。

【００１２】具体的には、発信側ｉモード携帯電話１よ
り受信側ｉモード携帯電話２に電話をかけた場合、回線
は音声通信網４を介して接続される。一方、ｉモードで
は上述のようにパケットを用いたデータ通信であるので
パケット通信網５を使用する。

【００１３】パケット通信網５は携帯電話からインター
ネットにアクセスする際に用いられるが、ｉモードサー
ビス前の利用にあたってはパソコン、あるいはＰＤＡ
（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａ
ｎｔｓ。個人用携帯情報端末。）といったものを必要と
する。

【００１４】発信側ｉモード携帯電話１からのインター
ネット網７へのアクセスは図に示すようにパケット通信
網５を使用しゲートウェイサーバ６を介して行われる。
また、電子メールのやり取りに関しても上記パケット通
信網５が使用され、ｉモード携帯電話では最大２５０文
字のインターネットメールの送受信を行うことができ
る。

【００１５】次に、上記ｉモード携帯電話での画像デー
タの送受信方法について説明する。画像データを送受信
する場合、大きく分けて２つの方法がある。

【００１６】１つは、ｉモード携帯電話からインター
ネット上のサーバに画像ファイルを転送（以下、アップ
ロードと称す。）し、該転送した画像ファイルの記録さ
れているＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ
Ｌｏｃａｔｅｒ）を受信者に通知する方法である。な
お、画像ファイルの収得は、上記ＵＲＬをもとに受信者
がインターネット上のサーバからｉモード携帯電話内に
上記画像ファイルを転送（以下、ダウンロードと記
す。）する。 もう一つは、電子メールに画像ファイルを添付し送信
する方法である。

【００１７】上記の手法はｉモード携帯電話ではデー
タ（ファイル）をインターネット上のサーバに直接携帯
電話よりアップロードする方法がサポートされていな
い。従って、ｉモード携帯電話本体からは画像データ
（画像ファイル）を直接インターネット上のサーバにア
ップロードすることができない。

【００１８】また上記の手法は、画像データを添付し
送信することは可能であるが、ｉモード携帯電話で送る
ことのできる１電子メールあたりのデータ量が２５０文
字（５００バイト）と非常に小さく１通の電子メールで
は画像データを送信することはできない。そこで、上記
ツーカグループより発売された画像の送受信を行うこと
ができる携帯電話では画像データを複数の電子メールに
分割し送信する方法を採用している。例えば、画像ファ
イルを８つに分割し８通のｉモードメールとして送信し
た場合は４０００バイト（４ＫＢ）の画像データを送受
信することができる。

【００１９】以下、画像データを８通の電子メールに分
割して伝送する場合の従来の携帯電話システムの動作を
説明する。

【００２０】図７に電子メール送信時のフローを示す。
ｉモード携帯電話で画像ファイル（静止画像）を添付し
た電子メール（以下、画像添付メールと称す。）を送る
際は、まずはじめ、電子メール作成モードにて宛先（以
下、単にアドレスと称す。）、および用件（以下、サブ
ジェクトと称す。）等を設定する（ステップ１）。

【００２１】そして、電子メールの本文（文書）を作成
し（ステップ２）、添付する画像ファイルを選択する
（ステップ３）。以上が、ユーザーによる画像添付メー
ルの作成手順である。

【００２２】さらに、画像を送信する場合には、携帯電
話本体で以下の作業が引き続き行われ送信のための画像
添付メールが作成される。上記ステップ３において添付
する画像ファイルの選択が行われると、発信側ｉモード
携帯電話１の本体では該選択された画像ファイルをＧＩ
Ｆファイル形式に圧縮するとともに、圧縮後の画像デー
タ（バイナリーデータ）をＢＡＳＥ６４エンコードなど
の手法を用いて擬似ＡＳＣＩＩ（ＡＳＣＩＩ：Ａｍｅｒ
ｉｃａｎ Ｓｔａｎｄａｒｄ Ｃｏｄｅ ｆｏｒ Ｉｎ
ｆｏｒｍａｔｉｏｎ Ｉｎｔｅｒｃｈａｒｇｅ。なお、
ここでは本来のＡＳＣＩＩコードに変換できないような
バイナリーコードの変換も含める上で疑似ＡＳＣＩＩと
表現している）データに変換する（バイナリーファイル
から疑似ＡＳＣＩＩデータよりなるファイルに変換され
る）。

【００２３】そして、上記疑似ＡＳＣＩＩ変換された画
像ファイルは上記ステップ２において作成された文書の
後ろに添付され画像添付メールが構成される（ステップ
４）。

【００２４】通常、インターネットメール（ｉモードメ
ール）はバイナリーデータを送信することができない。
よって、画像データなどのバイナリーデータを送信する
際はＢＡＳＥ６４などを用いバイナリーデータを疑似Ａ
ＳＣＩＩ化してメールに添付する必要がある（なお、イ
ンターネットメールの詳細に関しては、現在一般的に用
いられているＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉ
ｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ）に
規定されている。例えば、ＯＰＥＮ ＤＥＳＩＧＮ Ｎ
ｏ．８ 電子メール・システム完全マスタ ＣＱ出版社
１９９５年５月１０日 初版発行参照）。

【００２５】そして、ステップ４において作成された画
像添付メールは５００バイト単位に分割され、複数の電
子メールとして携帯電話より送信される。その際、各電
子メールのヘッダ部分には、分割情報、および添付ファ
イル情報等が付加される（ステップ５）。上述のよう
に、複数に分割され送信された画像添付メールはパケッ
ト通信網５を介し受信側ｉモード携帯電話２に送信され
る。

【００２６】次に、画像添付メールの受信側のフローを
図８を用いて説明する。受信側ｉモード携帯電話２で
は、上記８通に分割され送信された画像添付メールを受
信すると、まずはじめに各電子メールのヘッダ部分に付
加されている分割情報に基づいてもとの１通の画像添付
メールを復元する（ステップ６）。

【００２７】そして、画像添付メールを復元すると上記
ステップ５において付加した各電子メールのヘッダ部分
に付加されている添付ファイル情報をもとに添付画像フ
ァイルを分離する。その際、分離した添付ファイルの種
別（ここにいう種別とは、例えば、画像ファイル、音声
ファイル、ワードプロセッサのファイル等の種別を意味
する）を確認する。

【００２８】そして、添付ファイルが画像ファイルの場
合、ＢＡＳＥ６４デコードを行い、もとのバイナリーデ
ータのファイルに変換する（ステップ７）。

【００２９】ステップ７の終了後、画像ファイルを所定
のメモリ領域に記録するとともに、受信側ｉモード携帯
電話２では画像添付メールが着信したことをユーザーに
通知する（メール着信情報）。その際、添付画像ありの
情報を付加する。これは、例えば、画像データとリンク
したアイコン情報をメールの最後に付加することによっ
て行われる（ステップ８）。

【００３０】ユーザーは上記メール着信情報に基づき受
信メールを開き、本文確認後上記アイコンを選択する
（ステップ９）。上記アイコンが選択されると受信側ｉ
モード携帯電話２では上記インターネットブラウザーを
起動し（ステップ１０）、上記画像ファイルをデコード
（ＧＩＦファイル形式をデコードしもとの画像ファイル
を復元する）し表示する（ステップ１１）。

【００３１】従来の携帯電話による画像添付メールの送
受信は、上述したように行われているため、画像添付メ
ールは複数のｉモードメールに分割され送信される。図
８に示したように上記分割された電子メールを受信した
受信側ｉモード携帯電話２では、上記分割された各々の
電子メールを合成してもとの１通の画像添付メールを復
元する。

【００３２】しかし、現在発売されているｉモード携帯
電話（以下、下位機種と記す。）では上記分割された電
子メールの統合機能はサポートされていない。従って、
下位機種で上記画像添付メールを受信した場合は、８通
の単独メールとしてしか認識されない。よって、下位機
種で画像添付メールを受信した場合、先頭のメールに記
載されている文字情報しか読むことができず、添付ファ
イルに関しては上述のように疑似ＡＳＣＩＩ化された文
字列が表示される。

【００３３】特に、ｉモードを使用する場合、メール受
信に際しても情報量に応じて課金される。しかし、画像
添付メールをサポートしていない下位機種において上記
分割され送信された画像添付メールを受信しても画像を
閲覧することができない。

【００３４】さらに、上記疑似ＡＳＣＩＩ化された添付
ファイル情報に関しても、電子メール受信者に課金され
る。

【００３５】また、上記分割メールの統合機能がサポー
トされている場合においても、添付ファイルを画像ファ
イルとして認識できない場合は、疑似ＡＳＣＩＩ化され
た添付ファイルをバイナリーデータに変更することがで
きず、（ＢＡＳＥ６４デコード機能がサポートされてい
ない場合）上記場合と同様に画像添付メールを受信して
も携帯電話本体で画像を閲覧することができないだけで
はなく、上記疑似ＡＳＣＩＩ化された添付ファイル情報
に関しても課金される。

【００３６】なお、上述では下位機種について述べた
が、上記画像添付メールをサポートしていない携帯電話
に画像添付メールを送信した場合にも同様の事態とな
る。

【００３７】さらに、上記画像添付メールをサポートし
ている場合においても、画像添付メール着信時に８通の
電子メールとして受信されるため、例えば、分割された
１通の電子メールに着信遅延が生じた場合、携帯電話で
該着信遅延メールが受信できないと該画像添付メールを
復元することができず、受信時間（最初の分割されたメ
ールを受信してから上記着信遅延メールを受信するまで
の時間）が非常に長くなる。

【００３８】また、他の分割された電子メールと着信遅
延メールの間に時間があるため１通の画像添付メールを
受信する際、携帯電話から電子メール着信音が２度鳴
る。さらに、上記遅延メールが複数メールに及んだ場合
は１通の画像添付メールの着信に対して複数回の該電子
メール着信音が鳴る。

【００３９】また、上述のように８通の電子メールに画
像データを分割して送信する場合、４０００バイトのデ
ータを送信することができるが、画像データは上述のよ
うにＢＡＳＥ６４エンコードなどの手法により疑似ＡＳ
ＣＩＩ化されるため、実際に送ることのできるデータ量
は約１／１．４倍になる。

【００４０】例えば、２５０文字をメッセージに割り当
てた場合、８通の電子メールで送ることのできる画像デ
ータファイルの大きさは３５００バイト／１．４＝２５
００バイト程度になる。例えば、９６画素×７２ライン
の画像データを、ｉモード携帯電話でサポートされてい
るＧＩＦファイル形式で最適化パレットを用いて圧縮し
た場合、表示色数は１６色程度となり、原画像に対し画
質が非常に劣化する。

【００４１】しかし、ＧＩＦファイル形式に比べて画像
の圧縮効率が高いＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇ
ｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）等の圧縮
処理を用いた場合、同一の伝送データ量で画質の劣化が
少ない。

【００４２】しかし、ｉモード携帯電話では上述のよう
にＧＩＦファイル形式の画像データのデコーダは標準搭
載されているが、現状では上記ＪＰＥＧなどの他の形式
の画像ファイル形式はサポートされていない。

【００４３】従って、画像の圧縮方式としてＪＰＥＧを
使用した場合、分割された電子メールの受信をサポート
した携帯電話で上記画像添付メールを受信した際も、Ｊ
ＰＥＧデコーダをサポートしていない場合、携帯電話本
体で受信画像を閲覧することができない。

【００４４】すなわち、画像ファイルとして添付ファイ
ルを認識しＪＰＥＧファイルを構成できた場合であって
も画像をデコードできないため、ＪＰＥＧファイルをパ
ソコンなどに一旦転送しないと受信画像を見ることがで
きない。

【００４５】特に、上記多機能型携帯電話（画像データ
（静止画像）の送受信を行うことができる携帯電話）の
市場の拡大のためには、上述した下位機種、あるいは他
機種（分割メールをサポートした携帯電話等）との互換
性が必要となる。

【００４６】また、画像ファイルは上述のように疑似Ａ
ＳＣＩＩ変換されているため、実際のデータと比べ約
１．４倍のデータ量になっている。したがって、パケッ
ト量に応じて課金されるｉモードでは受信時の料金が必
要以上に高くなってしまう。

【００４７】また、画像添付メールを受信した際、ユー
ザーが画像データを見たくなくても添付画像データを受
信してしまうため、（送られてきた画像はすべて受信し
てしまうため）見たくない画像データに対しても課金が
なされてしまう。

【００４８】

【発明が解決しようとする課題】従来の画像送受信携帯
電話システムは上記のように構成されているので、画像
データ（静止画像）を携帯電話同士で送受信を行う場
合、上述のように下位機種、あるいは他機種において送
信されてきた画像添付メールに添付された画像を閲覧す
ることができないといった問題点があった。

【００４９】また、画像を閲覧できないにもかかわらず
受信データ量に応じて課金が施されるといった問題点が
あった。

【００５０】また、画像添付メールをサポートしている
携帯電話同士の画像データのやり取りであっても着信遅
延メールが発生した場合、画像添付メールの受信に非常
に時間がかかるとともに、複数通に別れてメールが送信
されるため、着信遅延メールが発生した場合、該着信遅
延メールが受信されるたびに携帯電話よりメール着信音
が鳴ってしまうという問題点があった。

【００５１】また、画像ファイルは上述のように疑似Ａ
ＳＣＩＩ変換されているため実際のデータと比べ約１．
４倍のデータ量になっている。したがって、パケット量
に応じて課金されるｉモードでは受信時の料金が必要以
上に高くなってしまうといった問題点があった。

【００５２】また、画像添付メールを受信した際、ユー
ザーが画像データを見たくなくても添付画像データを受
信してしまうため、見たくない画像データに対しても課
金がなされてしまうといった問題点があった。

【００５３】この発明は、上述のような課題を解決する
ためになされたもので、下位機種、あるいは他機種に対
して画像添付メールを送信した場合、不必要な添付画像
データの受信、および課金（画像の閲覧ができないにも
かかわらず課金される）がなされない中継サーバを利用
した情報通信方法および情報通信システムを得ることを
目的とする。

【００５４】さらに、下位機種、あるいは他機種に対し
て画像添付メールを送信した場合においても、受信側で
添付された画像ファイルを閲覧することができる中継サ
ーバを利用した情報通信方法および情報通信システムを
得ることを目的とする。

【００５５】また、画像添付メール受信にあたって不必
要な受信遅延、あるいは複数回にわたるメールの着信音
が鳴らない中継サーバを利用した情報通信方法および情
報通信システムを得ることを目的とする。

【００５６】また、画像添付メール受信にあたって受信
データ量を最小限に抑え、必要以上の課金が行われない
中継サーバを利用した情報通信方法および情報通信シス
テムを得ることを目的とする。

【００５７】また、ユーザーが添付データを必要としな
いときには添付データを受け取らない中継サーバを利用
した情報通信方法および情報通信システムを得ることを
目的とする。

【００５８】

【課題を解決するための手段】本発明に係る情報通信方
法は、送信情報を所定形式のコード列に変換して得られ
た変換コードの一部および受信者宛先より構成された複
数の受信情報を受信する受信段階と、該受信段階におい
て受信される前記複数の受信情報を統合して前記送信情
報に対応する前記変換コードの全部を復元する復元段階
と、該復元段階において復元される前記変換コードの全
部に基づいて前記送信情報または前記送信情報と実質的
に等価な情報を生成して、指定される記憶先に記憶する
記憶段階と、前記受信者宛先に前記記憶段階において指
定された前記記憶先を送信する送信段階とを含む。

【００５９】また、送信情報に所定の変換処理を施して
当該送信情報と実質的に同等の情報を得る変換処理段階
を含む。

【００６０】また、変換処理は、疑似ＡＳＣＩＩ化され
た送信情報をバイナリー情報に変換する。

【００６１】また、送信情報と共に当該送信情報と実質
的に同等の情報を指定される記憶先に記憶する。

【００６２】本発明に係る情報通信装置は、送信情報を
所定形式のコード列に変換して得られた変換コードの一
部および受信者宛先より構成された複数の受信情報を受
信し、該受信した複数の受信情報を統合して前記送信情
報に対応する前記変換コードの全部を復元する復元手段
と、該復元手段において復元される前記変換コードの全
部に基づいて前記送信情報または前記送信情報と実質的
に等価な情報を生成して、指定される記憶先に記憶する
記憶手段と、前記受信者宛先に前記記憶手段において指
定された前記記憶先を送信する送信手段とを有する。

【００６３】また、送信情報に所定の変換処理を施して
当該送信情報と実質的に同等の情報を得る変換処理手段
を備える。

【００６４】また、変換処理手段における変換処理は、
疑似ＡＳＣＩＩ化された送信情報をバイナリー情報に変
換する。

【００６５】また、記憶手段は、送信情報と共に当該送
信情報と実質的に同等の情報を記憶するように構成され
る。

【００６６】

【発明の実施の形態】以下、この発明をその実施の形態
を示す図面に基づいて具体的に説明する。なお、以下の
説明においては、添付ファイルが送信情報、例えばＢＡ
ＳＥ６４形式に変換されたコード（列）が所定形式のコ
ード列、受信者アドレスが受信者宛先、例えばＧＩＦデ
ータから変換されたＪＰＥＧ等のデータが送信情報と実
質的に等価な情報、送信情報または送信情報と実質的に
等価な情報が記憶されたＵＲＬが記憶先にそれぞれ相当
する。

【００６７】実施の形態１．図１は、この発明の実施の
形態１である中継サーバを利用した情報通信装置のシス
テム構成図である。図において、図６と同一符号を記し
たものは構成および動作が従来のものと同様であるので
詳細な説明を省略する。図において８は中継サーバであ
る。

【００６８】図２に、上記中継サーバ８の画像添付メー
ル受信時のフローを示す。

【００６９】以下、図１を用いて本発明の実施の形態１
の概要を説明する。本実施の形態１では発信側ｉモード
携帯電話１から受信側ｉモード携帯電話２へ画像添付メ
ールを送信する際の中継サーバ８の動作を中心に説明す
ることとし、従来例と同様にｉモード携帯電話を使用
し、画像添付メール送信の際は、該画像添付メールを８
通に分割し送信するものとする。

【００７０】以下、本実施の形態１による画像添付メー
ル送受信システムの概要を説明する。発信側ｉモード携
帯電話１において作成された画像添付メールは、従来例
と同様に発信側ｉモード携帯電話１の本体において８通
の電子メールに分割される。

【００７１】その際、発信側ｉモード携帯電話１におい
ては、分割された各電子メールの宛先（アドレス）を上
記中継サーバ８内に設けられたあらかじめ定められたア
ドレスに送信するものとして以下説明を続ける。発信側
ｉモード携帯電話１により８通に分割され送信された画
像添付メールは上記アドレスをもとに中継基地３、パケ
ット通信網５、ゲートウェイサーバ６およびインターネ
ット網７を経由して中継サーバ８へ送信される。

【００７２】上記、８通に分割された画像添付メールを
受信すると中継サーバ８では、まずはじめ、分割された
各々のメールのヘッダ情報を基に、８通に分割された画
像添付メールの統合を行って１通の画像添付メールを中
継サーバ８内で構成する。

【００７３】そして、この復元された画像添付メールよ
り本文および画像添付ファイルを分離し、該画像添付フ
ァイルを上記中継サーバ８内に記憶する。

【００７４】なお、中継サーバ８内に上記添付画像ファ
イルを記憶する際、該中継サーバ８に関する記憶アドレ
ス（ＵＲＬ）を生成する。この後、上記画像添付メール
の本文（文字情報部）、および上記ＵＲＬを含む通知メ
ールを作成し、受信側ｉモード携帯電話２に該通知メー
ルを送信する。

【００７５】そして、受信側ｉモード携帯電話２におい
ては、上記通知メールを受信すると、メールを開いて受
信したＵＲＬを選択し、添付画像ファイルを中継サーバ
８よりダウンロードする。

【００７６】以下、図２、図３および図７を用いて本実
施の形態１の画像添付メールの送受信方法および中継サ
ーバ８の詳細な動作について説明する。なお、画像メー
ルの作成手順に関しては図７を参照して説明した従来例
と同様であるので詳細な説明は省略する。

【００７７】また、ここでは、受信側ｉモード携帯電話
２が上記中継サーバ８上に画像添付メールを受信するた
めのアドレスを有する場合について説明する。

【００７８】図７において、発信側ｉモード携帯電話１
では画像添付メール作成の際は、まずはじめ、従来例と
同様に、ステップ１において宛先（上述のように、中継
サーバ８内の受信側ｉモード携帯電話２のアドレス）、
およびサブジェクトを設定する。

【００７９】そして、ステップ２において画像ファイル
に添付する文書を作成し、ステップ３において添付する
画像ファイルを選択する。なお、本実施の形態１では、
画像ファイルの圧縮形式としてＧＩＦファイル形式を使
用する場合について説明する。従来例でも述べたがｉモ
ード携帯電話のインターネットブラウザーではＧＩＦフ
ァイル形式に圧縮された画像を復元（デコード）閲覧す
ることができる。

【００８０】そして、上記ステップ３において、添付す
る画像ファイルの選択が行われると発信側ｉモード携帯
電話１本体では、選択された画像ファイルにＧＩＦファ
イル形式の圧縮を施した後、ＢＡＳＥ６４エンコードを
施し疑似ＡＳＣＩＩデータに変換する。

【００８１】この疑似ＡＳＣＩＩ変換された画像ファイ
ルはステップ４において該電子メールの本文の後ろに添
付される。そして、ステップ４において作成された画像
添付メールは５００バイト単位に分割され（ステップ
５）、複数の電子メールとして発信側ｉモード携帯電話
１より送信される。なお、ステップ５において各電子メ
ールのヘッダ部分には、分割情報、および添付ファイル
情報等が付加される。

【００８２】上記、複数に分割され送信された画像添付
メールはパケット通信網５、ゲートウェイサーバ６およ
びインターネット網７を介し中継サーバ８に送信され
る。

【００８３】次に、画像添付メール受信時の中継サーバ
８における処理フローを図２を用いて説明する。

【００８４】中継サーバ８では、上記８通に分割され送
信された画像添付メールを受信すると、まずはじめ、各
電子メールのヘッダ部分に付加されている分割情報を分
離する（ステップ１０）。

【００８５】分割された８通の画像添付メールがすべて
中継サーバ８に到着すると、中継サーバ８では分離した
分割情報に基づいてもとの１通の画像添付メールを復元
する（ステップ１１）。

【００８６】そして、各電子メールのヘッダ部分に付加
されている添付ファイル情報をもとに添付画像ファイル
を分離する。その際、分離した添付ファイルの種別を確
認する（ステップ１２）。

【００８７】ステップ１３においては、確認した添付フ
ァイルの種別をもとに、添付ファイルが画像ファイルの
場合、ＢＡＳＥ６４デコードを行って、もとのバイナリ
ーデータのファイルに変換する。

【００８８】そして、元のバイナリーデータの画像ファ
イルに復元後、該画像ファイルを中継サーバ８内の所定
の記憶領域（ディスク領域）に記録するとともに、記録
した画像データの記録アドレス（ＵＲＬ）を作成する
（ステップ１４）。

【００８９】その後、ステップ１１において復元した画
像添付メールの本文に作成したＵＲＬを付加し、画像添
付メールが到着したことを伝える通知メールを作成する
（ステップ１５）。

【００９０】そして、受信側ｉモード携帯電話２に該通
知メールを送信し画像添付メールが到着したことを伝え
る。

【００９１】なお、本実施の形態１では上記画像添付メ
ールの送信先は受信側ｉモード携帯電話２が中継サーバ
８内に予め登録されたアカウントであるので、予め中継
サーバ８からの転送先が設定されているものとして説明
を続ける（すなわち、転送先があらかじめ受信側ｉモー
ド携帯電話２のアドレスに設定されるよう該中継サーバ
８を構成した場合に相当する）。

【００９２】次に、該通知メール受信時の受信側ｉモー
ド携帯電話２における動作を図３を用いて説明する。通
知メールを受信すると受信側ｉモード携帯電話２におい
てはメール着信を通知するため着信音がなる（ステップ
１６）。

【００９３】ユーザーは電子メールの着信音が鳴ると着
信メールを閲覧するために電子メールブラウザーを起動
し、着信した電子メール（着信メールの選択、および閲
覧）を開き内容を確認する（ステップ１７）。

【００９４】ステップ１８において受信メールが通常の
電子メールか、画像添付メールの通知メールか判断す
る。通常の電子メールの場合は本文閲覧後、電子メール
ブラウザーを終了する（ステップ１９）。

【００９５】着信した電子メールが画像添付メールの通
知メールであった場合、ユーザは発信者アドレス情報お
よび本文を読み画像データを閲覧する（ダウンロードす
る）かどうか判断する（ステップ２０）。

【００９６】なお、ここでは着信メールが画像添付メー
ルの通知メールであるかは通知メールの送信アドレス、
あるいは通知メールに付加されている上記ＵＲＬによっ
て判断するものとする。

【００９７】ステップ２０において画像データを閲覧し
ない場合は、通知メールの本文閲覧後、ステップ１９に
おいて電子メールブラウザーを終了し、電子メールの閲
覧を終了する。

【００９８】従って、上述のように、画像添付メールの
通知メールに記載されている本文の内容、あるいは差出
人アドレスにより電子メールに添付された画像ファイル
の閲覧をユーザーが選択することができるので、発信側
ｉモード携帯電話１から送信された画像データを受信側
ｉモード携帯電話２を持つ受信者の選択により画像デー
タの受信の要否の選択ができる。

【００９９】また、ステップ２０において画像データを
閲覧する場合は、ユーザーは通知メールに添付されてい
る上記ＵＲＬを選択する（ステップ２１）。受信側ｉモ
ード携帯電話２は、上記ＵＲＬが選択されると従来例と
同様にインターネットブラウザーを起動する（ステップ
２２）。

【０１００】そして、ＵＲＬ情報をもとに中継サーバ８
より画像ファイルをダウンロードするよう要求コマンド
を中継サーバ８に送信する（ステップ２３）。

【０１０１】画像ファイルのダウンロードが完了すると
インターネットブラウザーはダウンロードした画像ファ
イルのデコード（ＧＩＦファイルのデコード）を行う
（ステップ２４）。

【０１０２】上述したが、ｉモード携帯電話のインター
ネットブラウザーはＧＩＦファイルのデコーダを標準サ
ポートしており、ＧＩＦファイル形式に圧縮された画像
をすべての機種で閲覧することができる。

【０１０３】画像データ閲覧後、ダウンロードしてきた
画像ファイルを記録するか確認する（ステップ２５）。
現実の携帯電話本体はその大きさ、および許容しうる消
費電力などの制限から、画像ファイルのような大きなフ
ァイルを何十枚も記憶するようなメモリを搭載していな
い。

【０１０４】よって、本実施の形態１では画像ファイル
の内容確認後ユーザーに画像データを記憶するかを確認
する構成とした。ステップ２５において画像ファイルを
記録しない場合は、画像閲覧後インターネットブラウザ
ーを終了し、電子メールの閲覧画面に戻る（ステップ２
７）。

【０１０５】一方、画像ファイルを記憶する場合は、メ
モリの空きスペースを確認後、画像ファイルをメモリに
記録し（ステップ２６）、インターネットブラウザーを
終了する（ステップ２７）。

【０１０６】最後に、ステップ１９において電子メール
ブラウザーを終了し、電子メールの閲覧を終了する。

【０１０７】本実施の形態１の中継サーバを利用した情
報通信方法および情報通信システムは以上のように構成
されているので、８通に分割され送信された画像添付メ
ールも、従来例で述べたような分割された電子メールの
統合機能のサポートされていない下位機種、あるいは画
像添付メールをサポートしていない他機種に送信した場
合でも、分割されたメールの統合、疑似ＡＳＣＩＩ化さ
れた画像ファイルのバイナリー変換（ＢＡＳＥ６４デコ
ード）等を中継サーバ８で行うので画像ファイルの閲覧
することができる。

【０１０８】また、本実施の形態１では、上述のように
下位機種、あるいは他機種で画像添付メールの送受信機
能のサポートされていない携帯電話での画像添付メール
（画像ファイル）の閲覧が可能となり、従来例で示した
ような画像ファイルの閲覧ができないにもかかわらず課
金されるといった問題点も発生しなくなる効果がある。

【０１０９】さらに、本実施の形態１では分割され送信
された画像添付メールの統合機能を中継サーバ８で行
い、ｉモード携帯電話本体には画像添付メールの本文と
ＵＲＬを通知メールとして送信するので、分割された各
電子メール送信中に一部の電子メールに着信遅延が生じ
ても、サーバ側で分割されたすべての電子メールがそろ
うまで通知メールを送信しないので、従来例で示したよ
うな画像添付メール１通の受信に非常に時間がかかる、
あるいは、同一電子メールの着信にもかかわらず着信音
が２度以上鳴るといった問題点が発生しなくなるという
効果がある。

【０１１０】また、本実施の形態１では、上述のよう
に、画像添付メールの通知メールに記載されている本文
の内容、あるいは差出人アドレスにより電子メールに添
付された画像ファイルの閲覧をユーザーが選択すること
ができる。

【０１１１】従って、本実施の形態１に示す静止画像を
送受信するシステムでは、送信された画像ファイルを受
信者の選択によりダウンロード（受信、および閲覧）で
きるので、受信者が不必要と思われる画像ファイルをむ
やみにダウンロードしなくてすみ、画像添付メール受信
時に必要以上の課金がなされない効果がある。

【０１１２】また、本実施の形態１では、中継サーバ８
で擬似ＡＳＣＩＩ化された画像ファイルをバイナリーデ
ータのファイル（本実施の形態１ではＢＡＳＥ６４デコ
ードに対応する。）に変換しダウンロードするので、従
来の擬似ＡＳＣＩＩ化された画像ファイルのやり取りと
比較しデータ量が約１／１．４倍になり、画像ファイル
収得時に発生する課金を少なくすることができる効果が
ある。

【０１１３】特に、ｉモードメールの場合、１通の電子
メール（２５０文字）の受信に当たっては、２５０文字
の文字データ（画像データ）以外のオーバーヘッドが多
く、画像添付メール受信時は必要以上にデータ量が多く
なってしまうが、本実施の形態１では上記画像データ以
外のオーバーヘッドを最小限に押さえることができる効
果がある。（パケット量の節約がはかれる。）

【０１１４】実施の形態２．図４はこの発明の実施の形
態２である中継サーバを利用した情報通信方式、および
情報通信装置における上記中継サーバ８の画像メール受
信時のフローを示す。本実施の形態２では、添付画像フ
ァイルの圧縮方式としてＪＰＥＧを用いた場合の動作を
説明する。

【０１１５】なお、中継サーバ８を利用した情報通信装
置のシステム構成図は図１を参照して説明した実施の形
態１と同様であり、また、発信側ｉモード携帯電話１で
の画像添付メール作成時の動作（手順）も実施の形態１
と同様なので詳細な動作の説明は省略する。

【０１１６】また、受信側ｉモード携帯電話２での画像
添付メール受信時の動作（手順）も実施の形態１と同様
なので詳細な動作の説明は省略する。

【０１１７】また、本実施の形態２においても実施の形
態１と同様に、発信側ｉモード携帯電話１から受信側ｉ
モード携帯電話２へ画像添付メールを送信する際の中継
サーバ８の動作を中心に説明する。

【０１１８】また、本実施の形態２でも実施の形態１と
同様にｉモード携帯電話を使用し、画像添付メール送信
の際は、該画像添付メールを８通に分割し送信するもの
とする。その際、実施の形態１と同様に、発信側ｉモー
ド携帯電話１では分割された各電子メールの宛先（アド
レス）を上記中継サーバ８に設けられたあらかじめ定め
られたアドレスに送信するものとして以下説明を続け
る。

【０１１９】以下、本実施の形態２で画像圧縮方式とし
てＪＰＥＧを使用する理由を簡単に説明する。従来例で
も述べたが、ｉモードメール８通で送ることのできるデ
ータ量は、１通を文字情報を送ると仮定すると２５００
バイト程度となる。

【０１２０】例えば、９６画素×７２ラインのカラー画
像データを２５００バイト以下にＧＩＦファイル形式で
圧縮した場合、コンピュータシミュレーションの結果、
最適化したカラーパレットを用いて圧縮すると、１６
色、あるいは８色程度の色数でしか圧縮することができ
ず、送信画像の画質劣化はいなめない。

【０１２１】ＧＩＦファイル形式を用いた場合、画質を
確保しようとした場合は画像添付メールの分割数を増や
す必要があるが、送受信のためのデータ量が増加し、画
像添付メール１通あたりのコストが上がる。

【０１２２】一方、ＧＩＦファイル形式に比べて画像の
圧縮効率が高いＪＰＥＧ等の圧縮手法を用いた場合は同
一の伝送データ量で画質の劣化が少ないため、以下はこ
のような、画像圧縮方式としてＪＰＥＧを用いた場合の
中継サーバを利用した情報通信方式、および情報通信装
置について説明する。

【０１２３】以下、本実施の形態２による画像添付メー
ル送受信システムの概要を説明する。図１において、発
信側ｉモード携帯電話１により８通に分割され送信され
た画像添付メールは、実施の形態１と同様に上記アドレ
スをもとに中継基地３、パケット網５、ゲートウェイサ
ーバ６、およびインターネット網７を経由して中継サー
バ８へ送信される。

【０１２４】８通に分割された画像添付を受信すると中
継サーバ８では実施の形態１と同様に８通に分割された
画像添付メールの統合を行う。そして、上記復元した画
像添付メールより本文、およびＪＰＥＧ形式で送信され
た添付画像ファイルを分離する。該分離されたＪＰＥＧ
ファイルは実施の形態１と同様にＢＡＳＥ６４デコード
が施されもとのバイナリーデータのＪＰＥＧファイルに
復元される。

【０１２５】該復元されたバイナリーデータのＪＰＥＧ
ファイルは、中継サーバ８内でデコードされ元の画像に
復元される。次に、該復元された画像を中継サーバ８は
ＧＩＦファイル形式に再圧縮する。

【０１２６】該バイナリーデータに変換されたＪＰＥＧ
ファイルと、該ＧＩＦファイル形式に圧縮された画像フ
ァイルの両方の画像ファイルを上記中継サーバ８内に記
憶する。

【０１２７】なお、実施の形態１と同様、中継サーバ８
では上記添付画像ファイルを記憶する際、ＵＲＬを生成
する。中継サーバ８内に添付画像ファイルを記憶する
と、本実施の形態１と同様に上記画像添付メールの本
文、および上記ＵＲＬを用いて通知メールを作成し、受
信者に該通知メールを送信する。

【０１２８】受信側ｉモード携帯電話２では、上記通知
メールを受信すると、実施の形態１と同様にメールを開
きＵＲＬを選択し添付画像ファイルを中継サーバ８より
ダウンロードする。

【０１２９】以下、図４を用いて本実施の形態２の画像
添付メールの送受信方式、および中継サーバ８の詳細な
動作について説明する。なお、画像メールの作成手順に
関しては実施の形態１と同様であるので詳細な説明は省
略する。

【０１３０】また、本実施の形態２では、本実施の形態
１同様、受信側ｉモード携帯電話２が上記中継サーバ８
上に画像添付メールを受信するためのアドレスを有して
いるものとして説明を続ける。なお、通知メールの宛先
に関しても実施の形態１と同一であるので詳細な説明は
省略する。上記、複数に分割され送信された画像添付メ
ールはパケット通信網５等を介し中継サーバ８に入力さ
れる。以降の中継サーバ８の動作を図４を用いて説明す
る。

【０１３１】中継サーバ８では、上記８通に分割され送
信された画像添付メールを受信すると、ステップ１０に
おいて各電子メールのヘッダ部分に付加されている分割
情報を分離する。そして、ステップ１１では該分割され
た８通の画像添付メールがすべて中継サーバ８に到着す
ると、中継サーバ８では該分離した分割情報もとにもと
の１通の画像添付メールを復元する。そして、ステップ
１２にて各電子メールのヘッダ情報に付加されている添
付ファイル情報をもとに添付画像ファイルを分離する。
その際、実施の形態１と同様に分離した添付ファイルの
種別を確認する。

【０１３２】ステップ１３では、上記分離した添付ファ
イル種別情報をもとに、添付ファイルが画像ファイルの
場合、ＢＡＳＥ６４デコードを行いもとのバイナリーデ
ータのファイルに変換する。中継サーバ８は該バイナリ
ーデータに変換されたＪＰＥＧファイルをデコードし画
像データを復元する。

【０１３３】画像データ復元後、中継サーバ８は該画像
データをＧＩＦファイル形式に再圧縮しする（ステップ
３０）。ここで、バイナリーデータに変換されたＪＰＥ
ＧファイルとＧＩＦファイル形式に圧縮された画像ファ
イルの両方の画像ファイルを上記中継サーバ８内の所定
の記憶領域（ディスク領域）に記録するとともに、記録
した画像データの記録アドレス（ＵＲＬ）を作成する
（ステップ１４）。

【０１３４】ＵＲＬの作成を終了すると、ステップ１５
において該画像添付メールの本文にＵＲＬを付加し、画
像添付メールが到着したことを伝える通知メールを送信
し、受信側ｉモード携帯電話２に該通知メールを送信し
画像添付メールが到着したことを伝える。

【０１３５】次に、該通知メール受信後の動作を図３お
よび図５を用いて説明する。通知メールを受信すると受
信側ｉモード携帯電話２でメール着信を通知するため着
信音がなる（ステップ１６）。なお、本実施の形態２で
は実施の形態１と同様にメール着信時に着信音を鳴らし
メール到着をユーザに通知する場合について説明する。

【０１３６】図５に画像ファイルをダウンロードする際
の受信側ｉモード携帯電話２と中継サーバ８間の動作フ
ローを示す。ユーザーは電子メールの着信音が鳴るとス
テップ１７において着信メールを閲覧するために電子メ
ールブラウザーを起動し、着信した電子メールを選択し
内容を確認する。

【０１３７】そして、ステップ１８において受信メール
が通常の電子メールか、画像添付メールの通知メールか
判断する。通常の電子メールの場合は本文閲覧後、電子
メールブラウザーを終了する（ステップ１９）。ステッ
プ２０において画像データを閲覧しない場合は、通知メ
ールの本文閲覧後、ステップ１９において電子メールブ
ラウザーを終了し、電子メールの閲覧を終了する。

【０１３８】また、ステップ２０において画像データを
閲覧する場合は、ステップ２１においてユーザーは通知
メールに添付されているＵＲＬを選択する。受信側ｉモ
ード携帯電話２は、上記ＵＲＬが選択されると実施の形
態１と同様にステップ２２でインターネットブラウザー
を起動する。そして、該ＵＲＬ情報をもとに中継サーバ
８より画像ファイルをダウンロードするようコマンドを
中継サーバ８に送信する。

【０１３９】以下、本実施の形態２の画像データのダウ
ンロードについて図５を用いて説明する。受信側ｉモー
ド携帯電話２より中継サーバ８に画像ファイルのダウン
ロード要求が送信される（ステップ３１）と、中継サー
バ８では画像ファイル形式を選択するよう受信側ｉモー
ド携帯電話２にファイル選択要求を出力する（ステップ
３２）。

【０１４０】受信側ｉモード携帯電話２では画像ファイ
ル形式を選択し中継サーバ８に伝える。（ステップ３
３）中継サーバ８では、該ファイル形式選択結果に応じ
て中継サーバ８内に記録した該画像ファイルを送信する
（ステップ３４）。受信側ｉモード携帯電話２では、中
継サーバ８よりダウンロードされてきた画像ファイルを
受信する（ステップ３５）。

【０１４１】まずはじめに、上記受信側ｉモード携帯電
話２でＪＰＥＧファイルのデコードをサポートしている
場合について説明する。よって、ステップ３２ではＪＰ
ＥＧファイルを選択しダウンロードする場合について説
明する。受信側ｉモード携帯電話２では、画像ファイル
のダウンロードが完了すると該インターネットブラウザ
ーはダウンロードした画像ファイルのデコード（ＪＰＥ
Ｇファイルのデコード）を行う（ステップ２４）。

【０１４２】画像データ閲覧後、本実施の形態２では実
施の形態１と同様、上記ダウンロードしてきた画像ファ
イルを記録するか確認する。ステップ２５にて画像ファ
イルを記録しない場合は、画像閲覧後インターネットブ
ラウザーを終了し、電子メールの閲覧画面に戻る（ステ
ップ２７）。

【０１４３】一方、画像ファイルを記憶する場合は、メ
モリの空きスペースを確認後、画像ファイルをメモリに
記録し（ステップ２６）、インターネットブラウザーを
終了する（ステップ２７）。その後、画像添付メールの
閲覧後、ステップ１９にて電子メールブラウザーを終了
し、電子メールの閲覧を終了する。

【０１４４】次に、上記受信側ｉモード携帯電話２でＪ
ＰＥＧファイルのデコードをサポートしていない場合に
ついて説明する。上述したが、ｉモード携帯電話のイン
ターネットブラウザーはＧＩＦファイルのデコーダを標
準サポートしており、ＧＩＦファイル形式に圧縮された
画像をすべての機種で閲覧することができる。

【０１４５】しかし、下位機種、あるいは他機種ではＪ
ＰＥＧデコーダまで標準サポートしていない。その場
合、ステップ３２ではＧＩＦファイルを選択し画像ファ
イルをダウンロードする。受信側ｉモード携帯電話２で
は、上記ＧＩＦファイル形式の画像ファイルのダウンロ
ードが完了すると該インターネットブラウザーはダウン
ロードした画像ファイルのデコード（ＧＩＦファイルの
デコード）を行い、携帯電話の液晶上に画像データを表
示する（ステップ２４）。

【０１４６】本実施の形態２の中継サーバを利用した情
報通信方式、および情報通信装置は以上のように構成さ
れているので、８通に分割され送信された画像添付メー
ルも、実施の形態１と同様に、分割された電子メールの
統合機能のサポートされていない下位機種、あるいは画
像添付メールをサポートしていない他機種に送信した場
合でも画像ファイルの閲覧することができる効果があ
る。

【０１４７】また、本実施の形態２では、実施の形態１
と同様に上述のように画像添付メールに関して下位機種
互換、あるいは他機種互換があるので画像ファイルの閲
覧ができないにもかかわらず課金されるといった問題点
も発生しなくなる効果がある。

【０１４８】さらに、本実施の形態２では実施の形態１
と同様に、分割された各電子メール送信中に一部のメー
ルに着信遅延が生じても、サーバ側で分割されたすべて
の電子メールがそろうまで通知メールを送信しないので
画像添付メール１通の受信に非常に時間がかかる、ある
いは、同一電子メールの着信にもかかわらず着信音が２
度鳴るといった問題点が発生しなくなるという効果があ
る。

【０１４９】また、本実施の形態２では、実施の形態１
と同様、上述のように送信された画像ファイルを受信者
の選択によりダウンロードの（受信、および閲覧）でき
るので、受信者が不必要と思われる画像ファイルをむや
みにダウンロードしなくてすみ、また、画像添付メール
受信時に必要以上の課金がなされない効果がある。ま
た、本実施の形態２では、実施の形態１と同様に、上記
画像データ以外のオーバーヘッドを最小限に押さえるこ
とができる効果がある。

【０１５０】さらに、本実施の形態２では、画像データ
をＪＰＥＧ圧縮し中継サーバ８にアップロードする。該
アップロードされた画像データをＪＰＥＧ伸長し画像デ
ータを復元する。そして、該復元した画像データをＧＩ
Ｆファイル形式に圧縮し、受信したＪＰＥＧファイル形
式の画像とＧＩＦファイル形式の画像を記憶し、アクセ
スした携帯電話の種別によってファイル形式を選択しダ
ウンロードできるように構成するので、ＪＰＥＧデコー
ダを機能を有しない携帯電話からでもＧＩＦファイル形
式で添付された画像ファイルをダウンロードできるの
で、下位機種互換、あるいは他機種互換を図ることがで
きる効果がある。

【０１５１】また、ＪＰＥＧデコード機能を有する携帯
電話へはＪＰＥＧファイル形式にてダウンロードするの
で、ＧＩＦファイル変換時の発生する画質の劣化がなく
画像データをダウンロードすることができるとともに、
ＧＩＦファイル形式に再圧縮する際、画像データ量が増
えるが、（シミュレーションの結果、圧縮する際の色数
にもよるが２倍程度のデータ量になる。）その影響を受
けること無く画像データをダウンロードすることができ
る。

【０１５２】なお、本実施の形態２では、画像圧縮方式
としてＪＰＥＧを用い、また、ＪＰＥＧデコード後再圧
縮する際の圧縮方式にＧＩＦを採用したがこれに限るも
のではなく、例えば、ビットマップ形式、あるいはＰＮ
Ｇファイル形式に変換した画像を記憶しても、携帯電話
が上記圧縮方式のデコードをサポートしていれば同様の
効果を奏する。

【０１５３】また、本実施の形態２では、ＪＰＥＧファ
イル、およびＧＩＦファイルの２種類のファイルを中継
サーバ８上に記録する場合について説明したがこれに限
るものではなく、例えば上述した、ＪＰＥＧ，ＧＩＦ，
ＰＮＧ（ＰｏｒｔａｂｌｅＮｅｔｗｏｒｋ Ｇｒａｐｈ
ｉｃｓ。ピング）、およびＢＭＰ（Ｂｉｔ Ｍａｐ。ビ
ットマップ）の４種類のファイルをサポートするように
構成しても同様の効果がある。

【０１５４】さらに、同一のＧＩＦファイル形式であっ
ても表示色数を変え複数のファイル形式を準備しても同
様の効果があることは言うまでもない。例えば、携帯電
話本体でインターネット上からダウンロードできるファ
イルサイズの最大値が決まっている場合があり、その
際、ダウンロードできるファイルサイズを選択すること
ができ、送られてきた画像ファイルをダウンロードでき
るファイルサイズが小さい携帯電話でも画像ファイルを
ダウンロードし閲覧することができる効果がある。

【０１５５】さらに、例えば白黒２階調の携帯電話を有
している場合は、カラー画像をダウンロードしてもカラ
ー画像を見ることができない。従って、例えば２値に圧
縮したＧＩＦファイルをダウンロードすればデータ量が
少なくてすみ、ダウンロードの際のコストを削減するこ
とができる効果がある。

【０１５６】なお、上記実施の形態１および２では、画
像添付メールをｉモードメール８通に分割し伝送した場
合について説明したがこれに限るものではなく、たとえ
ば、添付画像の画素数が多い場合、あるいはさらに画質
のよいデータを送信したい場合などは、１０通、１５通
に分割し送信しても、中継サーバ８にて分割された画像
添付メールの統合などを行えば同様の効果を奏する。

【０１５７】また、通知メールの転送先アドレスに関し
ては、例えばメール本文のあらかじめ定められた場所に
記述するように構成し、該中継サーバ８で該転送先を画
像添付メール本体より分離し送信しても同様の効果を奏
することは言うまでもない。また、格納位置に関して
も、該分割され送信された各分割メールのヘッダ部分に
記憶しても良いことは言うまでもない。

【０１５８】また、本実施の形態１および２では、バイ
ナリデータを疑似ＡＳＣＩＩデータに変換する際、ＢＡ
ＳＥ６４を用いたが変換方式はこれに限るものではな
く、例えば、ＵＮＩＸマシーンで使用されているような
ＵＵエンコードなどの手法を用いても同様の効果を奏す
る。

【０１５９】また、上記実施の形態１および２では、通
知メールとして画像添付メールの本文とＵＲＬを送信し
たがこれに限るものではなく、例えば、本文の一部とＵ
ＲＬ、あるいはＵＲＬのみを通知メールとして送信して
も同様の効果がある。その際、本文の一部、あるいはＵ
ＲＬのみ送信する場合は、携帯電話からのダウンロード
要求時には少なくとも送信しなかったメールの本文をダ
ウンロードできる構成とすれば同様の効果があることは
言うまでもない。

【０１６０】また、本実施の形態１および２では、ドコ
モのｉモード携帯電話を用いた場合について説明したが
これに限るものではなくツーカーグループの行っている
スカイメッセージサービス、あるいはＷＡＰ（Ｗｉｒｅ
ｌｅｓｓ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）（日本移
動通信株式会社ＩＤＯ、あるいは第二電電株式会社ＤＤ
Ｉなどにおいて採用）を用いた電子メールの送受信シス
テムにおいても上述のように中継サーバを用い分割され
送信されたメールの統合、所定のファイル変換、所定の
ファイル形式への画像の変換等を行うよう構成すれば同
様の効果があることは言うまでもない。

【０１６１】また、画像ファイルの圧縮方式として実施
の形態１および２ではＧＩＦ、およびＪＰＥＧを例に説
明したがこれに限るものではなくＰＮＧ、あるいはＢＭ
Ｐ形式の画像ファイルでも同様の効果を有することはい
うまでもない。

【０１６２】また、画像サイズに関しても９６画素×７
２ラインに限るものではない。また、実施の形態１およ
び２では、メール着信時に着信音を鳴らしメール到着を
ユーザに通知したがマナーモードなどのバイブレーショ
ン機能を用いた携帯電話への通知の場合でも同様の効果
を奏することはいうまでもない。

【０１６３】さらに、本実施の形態１および２では、電
子メールに静止画像を添付する場合について述べたがこ
れに限るものではなく、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉ
ｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｕｏｐ）などをベー
スに圧縮された動画像、および音声を添付した電子メー
ルを送受信する場合も中継サーバ８側で上述のような機
能を持たせれば同様の効果を奏することはいうまでもな
い。

【０１６４】また、上記実施の形態１および２では、電
子メールに画像ファイルを添付する場合について述べた
がワープロ文章の添付、音声ファイルの添付、あるいは
着信メロディなどの音楽ファイルの添付に関しても同様
に中継サーバ８側で上述のような機能をもたせれば同様
の効果を奏することは言うまでもない。

【０１６５】なお、以上の各実施の形態において、音声
の通信網の一例としてドコモ通信網のような音声通信
網、データ通信網の一例としてＤｏｐａのようなパケッ
ト通信網を例に説明したが、必ずしもこれらにのみ限定
される訳ではなく、他の音声通信網、パケット通信網で
あっても同様に適用することができる。

【０１６６】

【発明の効果】この発明は、以上説明したように構成さ
れているので、以下に示すような効果を奏する。

【０１６７】本発明に係る情報通信方法は、送信情報を
所定形式のコード列に変換して得られた変換コードの一
部および受信者宛先より構成された複数の受信情報を受
信する受信段階と、該受信段階において受信される前記
複数の受信情報を統合して前記送信情報に対応する前記
変換コードの全部を復元する復元段階と、該復元段階に
おいて復元される前記変換コードの全部に基づいて前記
送信情報または前記送信情報と実質的に等価な情報を生
成して、指定される記憶先に記憶する記憶段階と、前記
受信者宛先に前記記憶段階において指定された前記記憶
先を送信する送信段階とを含むので、添付情報を機種に
よらずに閲覧することができ、閲覧できないにも関わら
ず課金される、あるいは受信者の意図しない受信を防止
することができるので受信に大きな時間がかかってしま
うという問題点を解消することができる。

【０１６８】また、送信情報に所定の変換処理を施して
当該送信情報と実質的に同等の情報を得る変換処理段階
を含むので、添付情報を機種によらずに閲覧することが
可能となる。

【０１６９】また、変換処理は、疑似ＡＳＣＩＩ化され
た送信情報をバイナリー情報に変換するので、そのよう
な機能を有しない場合においても添付情報を機種によら
ずに閲覧することが可能となる。

【０１７０】また、送信情報と共に当該送信情報と実質
的に同等の情報を指定される記憶先に記憶するので、受
信者側の機能に応じて添付情報を閲覧することができ
る。

【０１７１】本発明に係る情報通信装置は、送信情報を
所定形式のコード列に変換して得られた変換コードの一
部および受信者宛先より構成された複数の受信情報を受
信し、該受信した複数の受信情報を統合して前記送信情
報に対応する前記変換コードの全部を復元する復元手段
と、該復元手段において復元される前記変換コードの全
部に基づいて前記送信情報または前記送信情報と実質的
に等価な情報を生成して、指定される記憶先に記憶する
記憶手段と、前記受信者宛先に前記記憶手段において指
定された前記記憶先を送信する送信手段とを有するの
で、添付情報を機種によらずに閲覧することができ、閲
覧できないにも関わらず課金される、あるいは受信者の
意図しない受信を防止することができるので受信に大き
な時間がかかってしまうという問題点を解消することが
できる。

【０１７２】また、送信情報に所定の変換処理を施して
当該送信情報と実質的に同等の情報を得る変換処理手段
を備えるので、添付情報を機種によらずに閲覧すること
が可能となる。

【０１７３】また、変換処理手段における変換処理は、
疑似ＡＳＣＩＩ化された送信情報をバイナリー情報に変
換するものであるので、そのような機能を有しない場合
においても添付情報を機種によらずに閲覧することが可
能となる。

【０１７４】また、記憶手段は、送信情報と共に当該送
信情報と実質的に同等の情報を記憶するように構成され
るので、受信者側の機能に応じて添付情報を閲覧するこ
とができる。

【図面の簡単な説明】

【図１】 実施の形態１に説明する情報通信システムの
構成図である。

【図２】 実施の形態１に説明する情報通信方法によ
る、中継サーバでの画像添付メールの処理アルゴリズム
である。

【図３】 実施の形態１に説明する情報通信方法によ
る、携帯電話で通知メールを受信した際の処理アルゴリ
ズムである。

【図４】 実施の形態２に説明する情報通信方法によ
る、中継サーバでの画像添付メールの処理アルゴリズム
である。

【図５】 実施の形態２に説明する情報通信方法によ
る、画像ファイルをダウンロードする際の携帯電話と中
継サーバ間の動作フローを示す図である。

【図６】 従来の携帯電話の電子メール送受信のための
システム構成図である。

【図７】 従来の画像添付メールを送信する際の携帯電
話本体の処理アルゴリズムである。

【図８】 従来の画像添付メールを受信する際の携帯電
話本体の処理アルゴリズムである。

【符号の説明】

１ 発信側ｉモード携帯電話、２ 受信側ｉモード携帯
電話、３ 中継局、５パケット通信網、６ ゲートウェ
イサーバ、７ インターネット、８ 中継サーバ。

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B089 GA11 GA25 HA13 JA31 JB03 JB23 KA08 KA09 KA16 KB04 KF05 KH02 KH04 KH13 KH28 LA01 LA11 LA18 5K030 HA06 JT09 KA02 9A001 HH27 JJ14 JJ25 JJ27 JJ65 KK58 KK60

Claims (8)

【特許請求の範囲】
1. 【請求項１】 送信情報を所定形式のコード列に変換し
   て得られた変換コードの一部および受信者宛先より構成
   された複数の受信情報を受信する受信段階と、 該受信段階において受信される前記複数の受信情報を統
   合して前記送信情報に対応する前記変換コードの全部を
   復元する復元段階と、 該復元段階において復元される前記変換コードの全部に
   基づいて前記送信情報または前記送信情報と実質的に等
   価な情報を生成して、指定される記憶先に記憶する記憶
   段階と、 前記受信者宛先に前記記憶段階において指定された前記
   記憶先を送信する送信段階とを含む情報通信方法。
2. 【請求項２】 送信情報に所定の変換処理を施して当該
   送信情報と実質的に同等の情報を得る変換処理段階を含
   む請求項１に記載の情報通信方法。
3. 【請求項３】 変換処理は、疑似ＡＳＣＩＩ化された送
   信情報をバイナリー情報に変換するものである請求項２
   に記載の情報通信方法。
4. 【請求項４】 送信情報と共に当該送信情報と実質的に
   同等の情報を指定される記憶先に記憶する請求項１に記
   載の情報通信方法。
5. 【請求項５】 送信情報を所定形式のコード列に変換し
   て得られた変換コードの一部および受信者宛先より構成
   された複数の受信情報を受信し、該受信した複数の受信
   情報を統合して前記送信情報に対応する前記変換コード
   の全部を復元する復元手段と、 該復元手段において復元される前記変換コードの全部に
   基づいて前記送信情報または前記送信情報と実質的に等
   価な情報を生成して、指定される記憶先に記憶する記憶
   手段と、 前記受信者宛先に前記記憶手段において指定された前記
   記憶先を送信する送信手段とを有する情報通信装置。
6. 【請求項６】 送信情報に所定の変換処理を施して当該
   送信情報と実質的に同等の情報を得る変換処理手段を備
   える請求項５に記載の情報通信装置。
7. 【請求項７】 変換処理手段における変換処理は、疑似
   ＡＳＣＩＩ化された送信情報をバイナリー情報に変換す
   るものである請求項６に記載の情報通信装置。
8. 【請求項８】 記憶手段は、送信情報と共に当該送信情
   報と実質的に同等の情報を記憶するように構成される請
   求項５に記載の情報通信装置。