JP2001216214A - 情報送信方法、情報通信方法、情報通信装置および情報通信端末 - Google Patents

Abstract

(57)【要約】 【課題】 画像ファイル付き分割電子メールを、メール
サーバを通過して中継サーバへ転送するための情報送信
方式、および情報送信装置において、中継サーバへの転
送処理で必要になるユーザーおよびメールサーバの負荷
の軽減を図るとともに、受信時において下位機種互換、
多機種互換を図る。 【解決手段】 分割された画像ファイル付き電子メール
に対して、ユーザーの操作とは切り離して自動的に識別
コードをヘッダ情報に挿入させることで中継サーバへの
転送を実現するとともに、中継サーバにて分割電子メー
ルの統合、および通知メールに添付ファイルを記憶した
ＵＲＬを付加して送るよう構成することにより下位機種
互換、多機種互換を図ることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、携帯電話等の携
帯無線装置(以下、携帯電話と記す。ＰＨＳ（Ｐｅｒｓ
ｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）を含
む。）間で電子メールを送受信する方式において、中継
サーバを介した送受信を行う際の情報送信方法に関す
る。

【０００２】

【従来の技術】携帯電話は４７００万人という膨大なユ
ーザーを取り込み、電子メールサービスを始めとしてイ
ンターネットのホームページ閲覧、情報提供サービス、
オンラインバンキングなどが実現され、情報携帯端末と
しての地位を固めつつある。特に、１９９９年２月から
ＮＴＴ移動通信網株式会社（以下、ＮＴＴドコモと称
す）が開始した”ｉモード”サービス（以下、ｉモード
と記す。）は携帯電話を用いて利用できるサービスの種
類の多さからユーザ数の拡大が目覚しい。

【０００３】一方、２００１年より商用化が予定されて
いるＷ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉ
ｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）通信
方式ではデータ通信速度が飛躍的に改善され、携帯電話
での動画像コンテンツの送受信が可能になる。それに伴
い、イメージセンサー（カメラ）と携帯電話を組み合わ
せ、動画像を送受信できる製品の市場投入が予想され
る。Ｗ−ＣＤＭＡ通信方式を採用した携帯電話の市場投
入に先駈け、オプションとしてディジタルカメラと接続
し静止画像を送受信することのできる携帯電話は１９９
９年４月より株式会社ツーカセルラー東京や株式会社ツ
ーカーセルラー東海等より構成されるツーカグループで
製品化されている。

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

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

【０００６】またｉモードの電子メールでは、ｉモード
携帯電話同士はもちろんのこと、現在、一般的になりつ
つあるインターネットを介したメール（以下、インター
ネットメールと称す）にも対応しており、携帯電話を用
いてインターネットメールの送受信を行うことができ
る。さらに、ｉモード携帯電話は、インターネットにあ
るホームページ上に公開された情報コンテンツを閲覧す
るためにＣｏｍｐａｃｔＨＴＭＬをサポートした携帯電
話用のインターネットブラウザーを搭載しており、Ｃｏ
ｍｐａｃｔＨＴＭＬで記述されたインターネットのホー
ムページ等を閲覧することができる。

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

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

【０００９】図９を用いてｉモードシステムを簡単に説
明する。図９に示すように、発信側ｉモード携帯電話
１、および２間の通常の音声通話ではＰＤＣ（Ｐｅｒｓ
ｏｎａｌ Ｄｉｇｉｔａｌ Ｃｅｌｌｕｌａｒ）の音声
通信網４を使用する。具体的には、発信側ｉモード携帯
電話１より受信側ｉモード携帯電話２に電話をかけた場
合、回線は音声通信網４を介して接続される。

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

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

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

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

【００１４】上記の手法については、画像データを添
付し送信することは可能であるが、ｉモード携帯電話で
送ることのできる１電子メールあたりのデータ量が２５
０文字（５００バイト）と非常に小さく１通の電子メー
ルでは画像データを送信することはできない。

【００１５】上記ツーカグループより発売された画像送
受信携帯電話でも同様の制約があり、こちらは画像デー
タを複数の電子メールに分割し送信する方法を採用して
いる。例えば、画像ファイルを８つに分割し８通のｉモ
ード電子メールとして送信した場合は４０００バイト
（４ＫＢ）の画像データを送受信できることになる。

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

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

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

【００１９】さらに、ｉモード携帯電話本体では、以下
の作業が引き続き行われ送信のための画像添付メールが
作成される。

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

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

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

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

【００２４】上記、複数に分割され送信された画像添付
メールは先述したパケット通信網５を介し相手先である
受信側ｉモード携帯電話２に送信される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００４７】

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

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

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

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

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

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

【００５３】

【課題を解決するための手段】本発明に係る情報送信方
法は、送信情報を所定形式のコード列に変換して得られ
る変換コードを生成する変換コード生成段階と、該変換
コード生成段階において生成される前記変換コードを分
割し、該分割された前記変換コードの一部に前記送信情
報の種類を示す識別コードを付加して複数の分割情報を
生成する分割情報生成段階と、該分割情報生成段階にお
いて生成される前記複数の分割情報を送信する送信段階
とを含む。

【００５４】また、送信段階の前に、中継先を意味する
ことと等価な情報を分割情報に挿入する中継先挿入段階
を含む。

【００５５】また、複数の分割情報を中継先に送信する
ことを特徴とする。

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

【００５７】また、複数の受信情報に中継先が含まれる
ことを特徴とする。

【００５８】また、各段階が中継先において実施される
ことを特徴とする。

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

【００６０】また、複数の受信情報に中継先が含まれる
ように構成されることを特徴とする。

【００６１】また、各手段が中継先に含まれることを特
徴とする。

【００６２】本発明に係る情報通信端末は、送信情報を
所定形式のコード列に変換して得られる変換コードを生
成する変換コード生成手段と、該変換コード生成手段に
おいて生成される前記変換コードを分割し、該分割され
た前記変換コードの一部に前記送信情報の種類を示す識
別コードを付加して複数の分割情報を生成する分割情報
生成手段と、該分割情報生成手段において生成される前
記複数の分割情報を送信する送信手段とを含む。

【００６３】また、送信手段における複数の分割情報の
送信の前に、中継先を意味することと等価な情報を分割
情報に挿入するように構成される。

【００６４】また、複数の分割情報を中継先に送信する
ように構成される。

【００６５】

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

【００６６】実施の形態１．図１は、この発明の実施形
態１である携帯電話より送信された電子メールを、メー
ルサーバを通過して中継サーバへ転送するための画像添
付メール送信時のフローである。

【００６７】図において、ステップ１は送信するための
相手先アドレスおよび用件（サブジェクト）を設定する
ステップ、ステップ２は送信する文章をテキストデータ
で作成するステップ、ステップ３はこれから添付データ
として送信する画像を選択するステップ、ステップ４は
画像のバイナリーデータをテキストデータに変換するス
テップ、ステップ１０は送信するテキスト情報を分割す
るステップである。

【００６８】ステップ１１は中継サーバ８へメールを送
信するためのヘッダ情報を生成するステップ、ステップ
１２は該ヘッダ情報をステップ１０で生成した分割テキ
スト情報にリンクして中継サーバ８へメールを送信する
ためのメールを生成するステップ、ステップ１３は中継
サーバから分割メールを送信するステップ、ステップ１
４は複数の分割メールを全て送信したか判定を行うステ
ップである。

【００６９】図２は、この発明の実施の形態１である携
帯電話より送信された電子メールを、メールサーバを通
過して中継サーバへ転送するための情報送信装置のシス
テム構成図である。図において、図９と同一符号を記し
たものは構成、および動作が同一である詳細な説明は省
略する。図において８は中継サーバである。

【００７０】図３は複数の分割メールを生成する際の対
象となるテキスト情報の構成を示す。図において１０は
ユーザーが入力したボディ情報（文章情報）、１１はユ
ーザーが選択した添付データ（例えば、画像データであ
り擬似ＡＳＣＩＩ化済のデータ）である。また、図４は
複数に分割する例として８通の分割を行った場合のデー
タ構成の概念の一例を示す。

【００７１】図５は発信側ｉモード携帯電話１から送信
される際の分割メールのヘッダ情報の一例を示す。図に
おいて１２は送信者（図中、ｆｒｏｍ：Ｂ＠ｍａｉｌｓ
ｅｒｖｅｒのＢ＠ｍａｉｌｓｅｒｖｅｒ）および受信者
（図中、ｔｏ：Ａ＠ｍａｉｌｓｅｒｖｅｒのＡ＠ｍａｉ
ｌｓｅｒｖｅｒ、ｃｃ：Ｃ＠ｍａｉｌｓｅｒｖｅｒのＣ
＠ｍａｉｌｓｅｒｖｅｒ）のアドレス情報、１３は中継
サーバ８へ転送するための識別コード（図中、ｍａｉｌ
−ｔｙｐｅ：ｐｉｃ ｍａｉｌのｐｉｃ ｍａｉｌ）、
１４はアドレス情報１２および識別コード１３の他、分
割情報、添付データ情報を含むヘッダ情報、１５は複数
に分割されたボディ情報および添付データのうちの１つ
の分割テキスト情報である。

【００７２】なお、ここで識別コードとは、基本的に、
添付ファイルの種別（ここにいう種別とは、例えば、画
像ファイル、音声ファイル、ワードプロセッサのファイ
ル等の種別を意味する）を示すものであり、例えば、上
述のような「ｐｉｃ ｍａｉｌ」であれば、画像ファイ
ルであることを意味する。

【００７３】図６は、中継サーバ８が分割メールを受信
した際の処理アルゴリズムを示す。図において、ステッ
プ２０は分割メールからヘッダ情報を分離するステッ
プ、ステップ２１は分割情報をもとにもとの１つのテキ
スト情報（ボディ情報１０及び添付データ１１）に復元
するステップ、ステップ２２は添付データファイルを分
離するステップ、ステップ２３は分離した添付データ１
１をテキストデータからバイナリデータ（画像データ）
に変換するステップ、ステップ２４は上記バイナリデー
タ（画像データ）を所定の記憶領域に記憶し、その記憶
領域を指し示すＵＲＬを生成するステップ、ステップ２
５はボディ情報１０と生成されたＵＲＬを記載した通知
メールを作成するステップである。

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

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

【００７６】その際、発信側ｉモード携帯電話１では分
割された８通の電子メールに対して上記中継サーバ８へ
転送するような後述の仕組みを施すものとして以下説明
を続ける。発信側ｉモード携帯電話１により８通に分割
され送信された画像添付メールは上記識別コードをもと
に中継基地３、パケット通信網５、ゲートウェイサーバ
６およびインターネット網７を経由して中継サーバ８へ
送信される。

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

【００７８】そして、上記復元した１通の画像添付メー
ルより本文および添付画像ファイルを分離し、該画像添
付ファイルを上記中継サーバ８内に記憶する。なお、中
継サーバ８では上記添付画像ファイルを記憶する際、該
記憶アドレス（ＵＲＬ）を生成する。

【００７９】中継サーバ８内に添付画像ファイルを記憶
すると、本実施の形態1では上記画像添付メールの本文
（文字情報部）および上記ＵＲＬを用いて通知メールを
作成し、受信者（本実施の形態１では、受信側ｉモード
携帯電話２）に該通知メールを送信する。

【００８０】このときの宛先アドレスは、中継サーバ８
への転送時に保持されているアドレス情報１２から抽出
する。そして、受信側ｉモード携帯電話２では、上記通
知メールを受信すると、メールを開きＵＲＬを選択し添
付画像ファイルを中継サーバ８よりダウンロードする。

【００８１】以下、図１、図３乃至図６を用いて本実施
の形態１の画像添付メールの送信方式について説明す
る。図１において、発信側ｉモード携帯電話１における
画像添付メール作成の際は、まずはじめ、従来例と同様
に、ステップ１において宛先（上述のように、中継サー
バ８内の受信側ｉモード携帯電話２のアドレス）、およ
びサブジェクトを設定する。

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

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

【００８４】上記擬似ＡＳＣＩＩ変換された画像ファイ
ルは、ステップ４において該電子メールのボディ情報１
０（本文となる文字情報）の後に添付データ１１（添付
情報）として直結され、図３に示すようなテキスト情報
が完成する。

【００８５】次にステップ４において作成されたテキス
ト情報は、ステップ１０において５００バイト単位に分
割され、例えば図４に示すような８つの分割テキスト情
報として生成される。

【００８６】続いて、ステップ１１においては、各分割
テキスト情報に対してヘッダ情報を生成するが、このと
き生成されるヘッダ情報内には識別コードとして、例え
ば図５に示すような識別コード１３を付加し、アドレス
情報１２およびその他の分割情報、添付ファイル情報等
も合わせて中継サーバ向けヘッダ１４に付加される。

【００８７】ステップ１２では分割テキスト１５に前記
ヘッダ情報１４をリンクすることにより、送信可能な分
割画像添付メールが生成される。そして、ステップ１３
では分割画像添付メールを送信する。ステップ１４では
複数の分割画像添付メール全てを送信したかどうか判定
を行い、全て正常に送信できた場合には送信終了状態と
なる。

【００８８】送信された上記分割画像添付メールは上記
パケット通信網５、ゲートウェイサーバ６に向けて送信
される。ゲートウェイサーバ６に到着した分割画像添付
メールはこのサーバにおいてヘッダ情報の解析を行い、
識別コード１３によってそのメールが分割画像添付メー
ルであることを判別する。

【００８９】判別結果から、ゲートウェイサーバ６は中
継サーバ８に向けて、この分割画像添付メールをインタ
ーネット網７を介し転送する。このときアドレス情報１
２はそのままヘッダ内に収められたまま中継サーバ８へ
転送される。

【００９０】次に、画像添付メール受信時の中継サーバ
８側でのフローについて図６を用いて説明する。中継サ
ーバ８では、上記８通に分割され送信された画像添付メ
ールを受信すると、まずはじめ、各電子メールのヘッダ
部分に付加されている分割情報を分離する（ステップ２
０）。

【００９１】そして、上記分離したヘッダ情報をもと
に、分割された８通の画像添付メールがすべて中継サー
バ８に到着すると、中継サーバ８では該分離した分割情
報もとにボディ情報１０および添付データ１１からなる
テキスト情報を復元する（ステップ２１）。

【００９２】ステップ２１においてテキスト情報を復元
すると、上記ステップ１１において付加した各電子メー
ルのヘッダ部分に付加されている添付ファイル情報をも
とに、添付データ１１を分離する。その際、分離した添
付データの種別を確認する（ステップ２２）。

【００９３】ステップ２３では、分離した添付データ種
別情報をもとに、添付データが画像データの場合、ＢＡ
ＳＥ６４デコードを行い、もとのバイナリーデータのフ
ァイルに変換する。そして、元のバイナリーデータの画
像ファイル復元後、該画像ファイルを中継サーバ８内の
所定の記憶領域（ディスク領域）に記録するとともに、
記録した画像データの記録アドレス（ＵＲＬ）を作成す
る（ステップ２４）。

【００９４】ＵＲＬの作成を終了すると、ステップ２１
において復元したボディ情報１０に該ＵＲＬを付加し、
画像添付メールが到着したことを伝える通知メールを作
成する（ステップ２５）。

【００９５】このときのアドレス設定については上記ア
ドレス情報１２をもとに行う。そして、受信側ｉモード
携帯電話２に該通知メールを送信し、画像添付メールが
到着したことを伝える。

【００９６】本実施の形態１は以上のように構成されて
いるので、８通に分割され送信された画像添付メールも
ユーザーが意識することなく中継サーバに送信すること
ができ、その結果、従来例で述べたような分割された電
子メールの統合機能のサポートされていない下位機種、
あるいは画像添付メールをサポートしていない他機種に
送信した場合でも、分割されたメールの統合、擬似ＡＳ
ＣＩＩ化された画像ファイルのバイナリー変換（ＢＡＳ
Ｅ６４デコード）等を中継サーバ８によって行うことに
より画像ファイルの閲覧を行うことができる。

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

【００９８】なお、上記実施の形態１では識別コードを
別途用意していたが、これを省略し分割情報の有無によ
って中継サーバ８への転送を判定させてもよい。

【００９９】実施の形態２．次にこの発明の実施の形態
２を説明する。実施の形態２における画像添付メールの
送信方法は、中継サーバへの転送を行うための本文の構
成およびヘッダ情報の取り扱い方が異なる。以下、本実
施の形態における本文の構成およびヘッダ情報の取り扱
い方について詳細に説明する。

【０１００】図７は、携帯電話より送信された電子メー
ルを、ゲートウェイサーバ６を通過して中継サーバ８へ
転送するための分割された画像添付メールの構成を示
す。

【０１０１】図において、１６は中継サーバ８へ転送す
るためのアドレス情報（この場合は、一旦、中継サーバ
８にメール送信が行われるため、図中、発信者はｆｒｏ
ｍ：Ｂ＠ｍａｉｌｓｅｒｖｅｒ、受信者はｔｏ：Ｂ＠ｓ
ｅｒｖｉｃｅｓｅｒｖｅｒと表現されている）、１７は
アドレス情報１６の他の分割情報等を含む中継サーバ向
けヘッダ、１８は分割して送信するテキスト情報であ
る。

【０１０２】また、図８は画像添付メールの送信方法に
おける分割対象となるテキスト情報の構成を示す。図に
おいて１９はユーザ（発信者）が設定するアドレス情
報、２０はユーザ（発信者）が入力したテキスト情報お
よび選択した画像情報をもとに生成される、受信者宛て
の実メール（発信者によって実際に作成された送信情
報）である。

【０１０３】以下、図７および図８を用いてこの実施の
形態２における送信方法の詳細な動作について説明す
る。

【０１０４】発信側ｉモード携帯電話１においては、画
像添付メール作成の際、まずはじめ、図１のステップ１
において宛先およびサブジェクトを設定する。続いてス
テップ２において画像ファイルに添付する文書を作成
し、ステップ３において添付する画像ファイルを選択す
る。

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

【０１０６】擬似ＡＳＣＩＩ変換された画像ファイルは
ステップ４において該電子メールの本文の最後部に添付
される。この結果、図８に示すような受信者宛て実メー
ル２０が完成する。受信者宛て実メール２０では、メー
ルを受け付けるサーバすなわちゲートウェイサーバ６に
存在するアカウントに届くようなアドレス情報１９が付
加されている。

【０１０７】次に、ステップ４において作成された画像
添付が行われた実メール２０は、ステップ１０にて５０
０バイト単位に分割され、実施の形態１と同様に、図４
に示すような８つの分割テキスト情報として生成され
る。

【０１０８】ここで、ステップ１１では各テキスト情報
に対して中継サーバ８向けのヘッダ１７を付加するが、
このとき中継サーバ８向けのヘッダ１７内の宛先（ｔ
ｏ：Ｂ＠ｓｅｒｖｉｃｅｓｅｒｖｅｒ）には、図７に示
すように中継サーバ８における送信者のアドレスに置き
換わったアドレス情報１６が挿入され、その他分割情報
等も合わせて付加される（この場合、発信者Ｂは中継サ
ーバ８にそのアカウントＢ＠ｓｅｒｖｉｃｅｓｅｒｖｅ
ｒを有していることを前提としている）。

【０１０９】上記、複数に分割され送信された画像添付
メールは、パケット通信網５、ゲートウェイサーバ６、
およびインターネット網７を介し中継サーバ８に送信さ
れる（ただし、ここでは、中継サーバ８において発信側
ｉモード携帯電話１のアカウントがすでに存在するもの
として述べている）。

【０１１０】上述した、複数に分割され送信された画像
添付メールは、パケット通信網５、ゲートウェイサーバ
６に向けて送信される。ゲートウェイサーバ６に到着し
た分割メールはこのサーバにおいてアドレスが中継サー
バ８に向けてのものであるかどうかを識別し、中継サー
バ８に向けてのものであると識別された場合には、中継
サーバ８に向けて本分割メールをインターネット７を介
し中継サーバ８に転送する。

【０１１１】次に、画像添付メール受信時の中継サーバ
８側におけるフローについて図６を用いて説明する。中
継サーバ８において上記８通に分割され送信された画像
添付メールを受信すると、まずはじめ、各分割され送信
された画像添付メールの中継サーバ向けヘッダ１７に付
加されている分割情報を分離する（ステップ２０）。

【０１１２】そして、分離したヘッダ情報をもとに、分
割された８通の画像添付メールがすべて中継サーバ８に
到着すると、中継サーバ８では該分離した分割情報をも
とに図８に示すようなもとの１通の受信者宛て実メール
２０を復元する（ステップ２１）。

【０１１３】そして、ステップ２１において受信者宛て
実メール２０を復元すると、図８に示すメール内のヘッ
ダ部分に付加した添付データ情報をもとに添付画像デー
タを分離する。その際、分離した添付データの種別を確
認する（ステップ２２）。

【０１１４】ステップ２３では、分離した添付ファイル
種別情報をもとに、添付データが画像データの場合、Ｂ
ＡＳＥ６４デコードを行ってもとのバイナリーデータ
（画像データ）のファイルに変換する。

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

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

【０１１７】この通知メールにおける宛先アドレスは、
実メール２０内のアドレス情報１９から抽出する（図８
における、ｔｏ：Ａ＠ｍａｉｌｓｅｒｖｅｒ）。そし
て、受信側ｉモード携帯電話２にステップ２５において
作成した通知メールを送信して画像添付メールが到着し
たことを伝える。

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

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

【０１２０】また、本実施の形態２では、受信者宛ての
実メールを分割したがこれに限るものではなく、中継サ
ーバ８において認識可能なボディ情報、添付情報、宛先
アドレス情報からなる任意のテキスト形式のフォーマッ
トデータを生成し、これを分割送信しても同様の効果を
奏する。

【０１２１】また、本実施の形態２では、送信側ｉモー
ド携帯電話１において中継サーバ８への送信アドレスの
付替えを行うため、ゲートウェイサーバ６に判別処理な
どの負荷をもたせることなく中継サーバ８に転送するこ
とができる。

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

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

【０１２４】さらに、実施の形態１および２では、ＧＩ
Ｆ圧縮形式の画像データを想定していたが、送信した画
像データをもとにＧＩＦ、ＪＰＥＧ、ＰＮＧ（Ｐｏｒｔ
ａｂｌｅ Ｎｅｔｗｏｒｋ Ｇｒａｐｈｉｃｓ。ピン
グ。）、ＢＭＰ（Ｂｉｔ Ｍａｐ。ビットマップ。）な
ど複数の圧縮形式の画像データを中継サーバ８において
生成し、アクセスした携帯電話の機種によってファイル
形式を選択することを可能としダウンロードできるよう
に構成すれば、個々の携帯電話に搭載されたデコーダ機
能にマッチする画像ファイルをダウンロードできるの
で、下位機種互換、あるいは他機種互換を図ることがで
きる。

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

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

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

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

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

【０１３０】また、実施の形態１および２では、上述の
ように中継サーバ８に転送してもアドレス情報は保持さ
れるので、画像添付メールの通知メールに記載されてい
る本文の内容、あるいは差出人アドレスにより電子メー
ルに添付された画像ファイルの閲覧をユーザーが選択す
ることができる。従って、実施の形態１に示す静止画像
を送信するシステムでは、送信された画像ファイルを受
信者の選択によりダウンロード（受信、および閲覧）で
きるので、受信者が不必要と考える画像ファイルがダウ
ンロードされることがなく、画像添付メール受信時に必
要以上の課金がなされない効果がある。

【０１３１】また、実施の形態１および２では、擬似Ａ
ＳＣＩＩ化された画像ファイルを、分割メールとして中
継サーバ８へ送信し、中継サーバ８で統合した後に、こ
の統合された擬似ＡＳＣＩＩ化された画像ファイルをバ
イナリーデータのファイルに変換（実施の形態１におい
てはＢＡＳＥ６４デコードに対応）してからダウンロー
ドするので、従来例の擬似ＡＳＣＩＩ化された画像ファ
イルの受信処理と比較し、データ量が約１／１．４倍に
なりパケット数が減らすことができ、画像ファイル収得
時に発生する課金を少なくすることができる効果があ
る。

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

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

【０１３４】

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

【０１３５】本発明に係る情報送信方法は、送信情報を
所定形式のコード列に変換して得られる変換コードを生
成する変換コード生成段階と、該変換コード生成段階に
おいて生成される前記変換コードを分割し、該分割され
た前記変換コードの一部に前記送信情報の種類を示す識
別コードを付加して複数の分割情報を生成する分割情報
生成段階と、該分割情報生成段階において生成される前
記複数の分割情報を送信する送信段階とを含むので、画
像情報等の送信情報を下位機種、あるは他機種において
閲覧することが可能なデータの構成が容易に可能とな
る。

【０１３６】また、送信段階の前に、中継先を意味する
ことと等価な情報を分割情報に挿入する中継先挿入段階
を含むので、送信者が特に意識すること無く送信情報を
中継先に送信するように構成することができる。

【０１３７】また、複数の分割情報を中継先に送信する
ことを特徴とするので、中継先において送信情報の受信
者側における適当な閲覧形態を実現することができる。

【０１３８】本発明に係る情報通信方法は、送信情報を
所定形式のコード列に変換して得られた変換コードの一
部、前記送信情報の種類を示す識別コードおよび受信者
宛先より構成された複数の受信情報を受信する受信段階
と、該受信段階において受信される前記複数の受信情報
を統合して前記送信情報に対応する前記変換コードの全
部を復元する復元段階と、該復元段階において復元され
る前記変換コードの全部および前記識別コードに基づい
て前記送信情報または前記送信情報と実質的に等価な情
報を生成して、指定される記憶先に記憶する記憶段階
と、前記受信者宛先に前記記憶段階において指定された
前記記憶先を送信する送信段階とを含むので、画像情報
等の送信情報を下位機種、あるは他機種において閲覧す
ることが可能なデータの構成が容易に可能となる。

【０１３９】また、複数の受信情報に中継先が含まれる
ことを特徴とするので、送信者が特に意識すること無く
送信情報を中継先に送信するように構成することができ
る。

【０１４０】また、各段階が中継先において実施される
ことを特徴とするので、中継先において送信情報の受信
者側における適当な閲覧形態を実現することができる。

【０１４１】本発明に係る情報通信装置は、送信情報を
所定形式のコード列に変換して得られた変換コードの一
部、前記送信情報の種類を示す識別コードおよび受信者
宛先より構成された複数の受信情報を受信する受信手段
と、該受信手段において受信される前記複数の受信情報
を統合して前記送信情報に対応する前記変換コードの全
部を復元する復元手段と、該復元手段において復元され
る前記変換コードの全部および前記識別コードに基づい
て前記送信情報または前記送信情報と実質的に等価な情
報を生成して、指定される記憶先に記憶する記憶手段
と、前記受信者宛先に前記記憶手段において指定された
前記記憶先を送信する送信手段とを含むので、画像情報
等の送信情報を下位機種、あるは他機種において閲覧す
ることが可能なデータの構成が容易に可能となる。

【０１４２】また、複数の受信情報に中継先が含まれる
ように構成されることを特徴とするので、送信者が特に
意識すること無く送信情報を中継先に送信するように構
成することができる。

【０１４３】また、各手段が中継先に含まれることを特
徴とするので、中継先において送信情報の受信者側にお
ける適当な閲覧形態を実現することができる。

【０１４４】本発明に係る情報通信端末は、送信情報を
所定形式のコード列に変換して得られる変換コードを生
成する変換コード生成手段と、該変換コード生成手段に
おいて生成される前記変換コードを分割し、該分割され
た前記変換コードの一部に前記送信情報の種類を示す識
別コードを付加して複数の分割情報を生成する分割情報
生成手段と、該分割情報生成手段において生成される前
記複数の分割情報を送信する送信手段とを含むので、画
像情報等の送信情報を下位機種、あるは他機種において
閲覧することが可能なデータの構成が容易に可能とな
る。

【０１４５】また、送信手段における複数の分割情報の
送信の前に、中継先を意味することと等価な情報を分割
情報に挿入するように構成されるので、送信者が特に意
識すること無く送信情報を中継先に送信するように構成
することができる。

【０１４６】また、複数の分割情報を中継先に送信する
ように構成されるので、中継先において送信情報の受信
者側における適当な閲覧形態を実現することができる。

【図面の簡単な説明】

【図１】 実施の形態１における送信処理アルゴリズム
を示すフローチャートである。

【図２】 実施の形態１における情報通信システムを示
すシステム構成図である。

【図３】 実施の形態１におけるテキスト情報の構成を
示す説明図である。

【図４】 実施の形態１における分割された送信情報
（送信メール）を示す説明図である。

【図５】 実施の形態１における、中継サーバに向けた
送信メール内に付加されるヘッダ情報を示す説明図であ
る。

【図６】 実施の形態１における、中継サーバの受信処
理アルゴリズムを示すフローチャートである。

【図７】 実施の形態２における、中継サーバに向けた
分割メールの構成を示す説明図である。

【図８】 実施の形態２における、分割対象となるテキ
スト情報を示す説明図である。

【図９】 従来の情報通信システムを示すシステム構成
図である。

【図１０】 従来の送信処理アルゴリズムを示すフロー
チャートである。

【図１１】 従来の受信処理アルゴリズムを示すフロー
チャートである。

【符号の説明】

１ 発信側ｉモード携帯電話、２ 受信側ｉモード携帯
電話、３ 中継局、４音声通信網、５ パケット通信
網、６ ゲートウェイサーバ、７ インターネット、８
中継サーバ、１０ ボディ情報、１１ 添付データ、
１２，１６，１９ アドレス情報、１３ 識別コード、
１４，１７ 中継サーバ向けヘッダ、１５，１８ 分割
テキスト、２０ 実メール。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 小野 良樹 東京都千代田区丸の内二丁目２番３号 三 菱電機株式会社内 Ｆターム(参考） 5B089 GA11 GA25 JA31 JB14 KA08 KB07 KH11 LA01 LA18 5K030 HA06 HB11 HB16 HD03 KA02 LB05 9A001 CC05 CC07 EE02 JJ21 JJ24 KK62

Claims (12)

【特許請求の範囲】
1. 【請求項１】 送信情報を所定形式のコード列に変換し
   て得られる変換コードを生成する変換コード生成段階
   と、 該変換コード生成段階において生成される前記変換コー
   ドを分割し、該分割された前記変換コードの一部に前記
   送信情報の種類を示す識別コードを付加して複数の分割
   情報を生成する分割情報生成段階と、 該分割情報生成段階において生成される前記複数の分割
   情報を送信する送信段階とを含む情報送信方法。
2. 【請求項２】 送信段階の前に、中継先を意味すること
   と等価な情報を分割情報に挿入する中継先挿入段階を含
   む請求項１記載の情報送信方法。
3. 【請求項３】 複数の分割情報を中継先に送信すること
   を特徴とする請求項１記載の情報送信方法。
4. 【請求項４】 送信情報を所定形式のコード列に変換し
   て得られた変換コードの一部、前記送信情報の種類を示
   す識別コードおよび受信者宛先より構成された複数の受
   信情報を受信する受信段階と、 該受信段階において受信される前記複数の受信情報を統
   合して前記送信情報に対応する前記変換コードの全部を
   復元する復元段階と、 該復元段階において復元される前記変換コードの全部お
   よび前記識別コードに基づいて前記送信情報または前記
   送信情報と実質的に等価な情報を生成して、指定される
   記憶先に記憶する記憶段階と、 前記受信者宛先に前記記憶段階において指定された前記
   記憶先を送信する送信段階とを含む情報通信方法。
5. 【請求項５】 複数の受信情報に中継先が含まれること
   を特徴とする請求項４記載の情報通信方法。
6. 【請求項６】 各段階が中継先において実施されること
   を特徴とする請求項４記載の情報通信方法。
7. 【請求項７】 送信情報を所定形式のコード列に変換し
   て得られた変換コードの一部、前記送信情報の種類を示
   す識別コードおよび受信者宛先より構成された複数の受
   信情報を受信する受信手段と、 該受信手段において受信される前記複数の受信情報を統
   合して前記送信情報に対応する前記変換コードの全部を
   復元する復元手段と、 該復元手段において復元される前記変換コードの全部お
   よび前記識別コードに基づいて前記送信情報または前記
   送信情報と実質的に等価な情報を生成して、指定される
   記憶先に記憶する記憶手段と、 前記受信者宛先に前記記憶手段において指定された前記
   記憶先を送信する送信手段とを含む情報通信装置。
8. 【請求項８】 複数の受信情報に中継先が含まれるよう
   に構成されることを特徴とする請求項７記載の情報通信
   装置。
9. 【請求項９】 各手段が中継先に含まれることを特徴と
   する請求項７記載の情報通信装置。
10. 【請求項１０】 送信情報を所定形式のコード列に変換
    して得られる変換コードを生成する変換コード生成手段
    と、 該変換コード生成手段において生成される前記変換コー
    ドを分割し、該分割された前記変換コードの一部に前記
    送信情報の種類を示す識別コードを付加して複数の分割
    情報を生成する分割情報生成手段と、 該分割情報生成手段において生成される前記複数の分割
    情報を送信する送信手段とを含む情報通信端末。
11. 【請求項１１】 送信手段における複数の分割情報の送
    信の前に、中継先を意味することと等価な情報を分割情
    報に挿入するように構成される請求項１０記載の情報通
    信端末。
12. 【請求項１２】 複数の分割情報を中継先に送信するよ
    うに構成されることを特徴とする請求項１０記載の情報
    通信端末。