JP2001217876A - 情報通信方法および情報通信装置 - Google Patents
情報通信方法および情報通信装置Info
- Publication number
- JP2001217876A JP2001217876A JP2000021391A JP2000021391A JP2001217876A JP 2001217876 A JP2001217876 A JP 2001217876A JP 2000021391 A JP2000021391 A JP 2000021391A JP 2000021391 A JP2000021391 A JP 2000021391A JP 2001217876 A JP2001217876 A JP 2001217876A
- Authority
- JP
- Japan
- Prior art keywords
- information
- image
- attached
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
(57)【要約】
【課題】 中継サーバを利用した情報通信方式、および
情報通信装置において添付ファイル付き電子メールの特
に受信時において下位機種互換、他機種互換を図る。 【解決手段】 中継サーバにて分割され送信された電子
メールの統合などの処理を行い、通知メールに添付ファ
イルを記憶したURLを付けて送るよう構成することに
より下位機種互換、他機種互換を図ることができる。
情報通信装置において添付ファイル付き電子メールの特
に受信時において下位機種互換、他機種互換を図る。 【解決手段】 中継サーバにて分割され送信された電子
メールの統合などの処理を行い、通知メールに添付ファ
イルを記憶したURLを付けて送るよう構成することに
より下位機種互換、他機種互換を図ることができる。
Description
【0001】
【発明の属する技術分野】この発明は、携帯電話等の携
帯無線装置(以下、携帯電話と記す。PHS(Pers
onal Handyphone System)端末
を含む。)より発信された電子メールを、中継サーバ装
置(以下、単に中継サーバと記す。)を仲介し送受信を
行う際の情報通信方法及び情報通信システムに関する。
帯無線装置(以下、携帯電話と記す。PHS(Pers
onal Handyphone System)端末
を含む。)より発信された電子メールを、中継サーバ装
置(以下、単に中継サーバと記す。)を仲介し送受信を
行う際の情報通信方法及び情報通信システムに関する。
【0002】
【従来の技術】携帯電話は4700万人という膨大なユ
ーザーを取り込み、電子メールサービスを手始めに、イ
ンターネット接続、情報提供サービス、オンラインバン
キングなど情報携帯端末としての地位を固めつつある。
特に、1999年2月からNTT移動通信網株式会社
(以下、NTTドコモと称す)が開始した”iモード”
サービス(以下、iモードと記す。)はこれまでの携帯
電話とは異なり、音声通話以外に電子メールをはじめ、
オンラインバンキング(銀行の残高照会・振り込み)、
レストランガイド、タウンページ検索など生活に密接し
たサービスが携帯電話を用いて利用することができる。
ーザーを取り込み、電子メールサービスを手始めに、イ
ンターネット接続、情報提供サービス、オンラインバン
キングなど情報携帯端末としての地位を固めつつある。
特に、1999年2月からNTT移動通信網株式会社
(以下、NTTドコモと称す)が開始した”iモード”
サービス(以下、iモードと記す。)はこれまでの携帯
電話とは異なり、音声通話以外に電子メールをはじめ、
オンラインバンキング(銀行の残高照会・振り込み)、
レストランガイド、タウンページ検索など生活に密接し
たサービスが携帯電話を用いて利用することができる。
【0003】一方、2001年より商用化が予定されて
いるW−CDMA(Wideband Code Di
vision Multiple Access)通信
方式では、データ通信速度が飛躍的に改善され携帯電話
での動画像コンテンツの送受信が可能となる。
いるW−CDMA(Wideband Code Di
vision Multiple Access)通信
方式では、データ通信速度が飛躍的に改善され携帯電話
での動画像コンテンツの送受信が可能となる。
【0004】それに伴い、イメージセンサー(カメラ)
と携帯電話を組み合わせ、動画像を送受信できる製品の
市場投入が予想される。また、W−CDMA通信方式を
採用した携帯電話の市場投入に先駈け、オプションとし
てディジタルカメラと接続し静止画像を送受信すること
のできる携帯電話が1999年4月より株式会社ツーカ
セルラー東京、株式会社ツーカセルラー東海等により構
成されるツーカグループによって製品化された。
と携帯電話を組み合わせ、動画像を送受信できる製品の
市場投入が予想される。また、W−CDMA通信方式を
採用した携帯電話の市場投入に先駈け、オプションとし
てディジタルカメラと接続し静止画像を送受信すること
のできる携帯電話が1999年4月より株式会社ツーカ
セルラー東京、株式会社ツーカセルラー東海等により構
成されるツーカグループによって製品化された。
【0005】今後、携帯電話を用いて画像データの送受
信を行う製品が各社より市場投入されると予想される。
以下、上記NTTドコモのiモードを例に携帯電話を用
いて静止画像の送受信を行う場合のシステム(画像送受
信携帯電話システム)について説明する。
信を行う製品が各社より市場投入されると予想される。
以下、上記NTTドコモのiモードを例に携帯電話を用
いて静止画像の送受信を行う場合のシステム(画像送受
信携帯電話システム)について説明する。
【0006】まずはじめ、従来の静止画像を送受信する
システムの説明を行う前に、上記iモードに関して簡単
に説明する。iモードはNTTドコモが開始した新しい
データ通信サービスでパケット通信方式を採用してい
る。iモードで採用されている上記パケット通信方式で
は、従来の接続時間による課金ではなく送受信したデー
タ量(パケット数)に応じて課金される。
システムの説明を行う前に、上記iモードに関して簡単
に説明する。iモードはNTTドコモが開始した新しい
データ通信サービスでパケット通信方式を採用してい
る。iモードで採用されている上記パケット通信方式で
は、従来の接続時間による課金ではなく送受信したデー
タ量(パケット数)に応じて課金される。
【0007】また、iモードでの電子メールはiモード
携帯電話同士はもちろん、現在一般的になりつつあるイ
ンターネットを介したメール(以下、インターネットメ
ールと称す)にも対応しており、携帯電話を用いてイン
ターネットメールの送受信を行うことができる。
携帯電話同士はもちろん、現在一般的になりつつあるイ
ンターネットを介したメール(以下、インターネットメ
ールと称す)にも対応しており、携帯電話を用いてイン
ターネットメールの送受信を行うことができる。
【0008】さらに、iモード携帯電話は、インターネ
ットのホームページ上に公開された情報コンテンツを閲
覧するためにCompactHTMLをサポートしたi
モード携帯電話用のインターネットブラウザーを搭載し
ており、iモード対応で作成されたインターネットのホ
ームページ等を閲覧することができる。
ットのホームページ上に公開された情報コンテンツを閲
覧するためにCompactHTMLをサポートしたi
モード携帯電話用のインターネットブラウザーを搭載し
ており、iモード対応で作成されたインターネットのホ
ームページ等を閲覧することができる。
【0009】また、iモード携帯電話ではGIF(Gr
aphic Interchange Format)
ファイル形式の画像データのデコーダを標準搭載してお
り、該画像データファイルをインターネット上よりダウ
ンロードし携帯電話の液晶上に表示することができる。
aphic Interchange Format)
ファイル形式の画像データのデコーダを標準搭載してお
り、該画像データファイルをインターネット上よりダウ
ンロードし携帯電話の液晶上に表示することができる。
【0010】図6にiモードの基本システム構成図を示
す。図において1は発信側iモード携帯電話、2は受信
側iモード携帯電話、3は中継基地、4は例えばドコモ
通信網のような音声通信網、5は例えばドコモのデータ
通信網DoPa(ドゥーパ)のようなパケット通信網、
6は例えばドコモゲートウェイサーバのようなゲートウ
ェイサーバ、7はインターネット網である。
す。図において1は発信側iモード携帯電話、2は受信
側iモード携帯電話、3は中継基地、4は例えばドコモ
通信網のような音声通信網、5は例えばドコモのデータ
通信網DoPa(ドゥーパ)のようなパケット通信網、
6は例えばドコモゲートウェイサーバのようなゲートウ
ェイサーバ、7はインターネット網である。
【0011】図6を用いてiモードシステムを簡単に説
明する。図6に示すように、発信側iモード携帯電話1
および受信側iモード携帯電話2間の通常の音声通話で
は音声通信網(PDC。Personal Digit
al Cellular)4を使用する。
明する。図6に示すように、発信側iモード携帯電話1
および受信側iモード携帯電話2間の通常の音声通話で
は音声通信網(PDC。Personal Digit
al Cellular)4を使用する。
【0012】具体的には、発信側iモード携帯電話1よ
り受信側iモード携帯電話2に電話をかけた場合、回線
は音声通信網4を介して接続される。一方、iモードで
は上述のようにパケットを用いたデータ通信であるので
パケット通信網5を使用する。
り受信側iモード携帯電話2に電話をかけた場合、回線
は音声通信網4を介して接続される。一方、iモードで
は上述のようにパケットを用いたデータ通信であるので
パケット通信網5を使用する。
【0013】パケット通信網5は携帯電話からインター
ネットにアクセスする際に用いられるが、iモードサー
ビス前の利用にあたってはパソコン、あるいはPDA
(Personal Digital Assista
nts。個人用携帯情報端末。)といったものを必要と
する。
ネットにアクセスする際に用いられるが、iモードサー
ビス前の利用にあたってはパソコン、あるいはPDA
(Personal Digital Assista
nts。個人用携帯情報端末。)といったものを必要と
する。
【0014】発信側iモード携帯電話1からのインター
ネット網7へのアクセスは図に示すようにパケット通信
網5を使用しゲートウェイサーバ6を介して行われる。
また、電子メールのやり取りに関しても上記パケット通
信網5が使用され、iモード携帯電話では最大250文
字のインターネットメールの送受信を行うことができ
る。
ネット網7へのアクセスは図に示すようにパケット通信
網5を使用しゲートウェイサーバ6を介して行われる。
また、電子メールのやり取りに関しても上記パケット通
信網5が使用され、iモード携帯電話では最大250文
字のインターネットメールの送受信を行うことができ
る。
【0015】次に、上記iモード携帯電話での画像デー
タの送受信方法について説明する。画像データを送受信
する場合、大きく分けて2つの方法がある。
タの送受信方法について説明する。画像データを送受信
する場合、大きく分けて2つの方法がある。
【0016】1つは、iモード携帯電話からインター
ネット上のサーバに画像ファイルを転送(以下、アップ
ロードと称す。)し、該転送した画像ファイルの記録さ
れているURL(Uniform Resource
Locater)を受信者に通知する方法である。な
お、画像ファイルの収得は、上記URLをもとに受信者
がインターネット上のサーバからiモード携帯電話内に
上記画像ファイルを転送(以下、ダウンロードと記
す。)する。 もう一つは、電子メールに画像ファイルを添付し送信
する方法である。
ネット上のサーバに画像ファイルを転送(以下、アップ
ロードと称す。)し、該転送した画像ファイルの記録さ
れているURL(Uniform Resource
Locater)を受信者に通知する方法である。な
お、画像ファイルの収得は、上記URLをもとに受信者
がインターネット上のサーバからiモード携帯電話内に
上記画像ファイルを転送(以下、ダウンロードと記
す。)する。 もう一つは、電子メールに画像ファイルを添付し送信
する方法である。
【0017】上記の手法はiモード携帯電話ではデー
タ(ファイル)をインターネット上のサーバに直接携帯
電話よりアップロードする方法がサポートされていな
い。従って、iモード携帯電話本体からは画像データ
(画像ファイル)を直接インターネット上のサーバにア
ップロードすることができない。
タ(ファイル)をインターネット上のサーバに直接携帯
電話よりアップロードする方法がサポートされていな
い。従って、iモード携帯電話本体からは画像データ
(画像ファイル)を直接インターネット上のサーバにア
ップロードすることができない。
【0018】また上記の手法は、画像データを添付し
送信することは可能であるが、iモード携帯電話で送る
ことのできる1電子メールあたりのデータ量が250文
字(500バイト)と非常に小さく1通の電子メールで
は画像データを送信することはできない。そこで、上記
ツーカグループより発売された画像の送受信を行うこと
ができる携帯電話では画像データを複数の電子メールに
分割し送信する方法を採用している。例えば、画像ファ
イルを8つに分割し8通のiモードメールとして送信し
た場合は4000バイト(4KB)の画像データを送受
信することができる。
送信することは可能であるが、iモード携帯電話で送る
ことのできる1電子メールあたりのデータ量が250文
字(500バイト)と非常に小さく1通の電子メールで
は画像データを送信することはできない。そこで、上記
ツーカグループより発売された画像の送受信を行うこと
ができる携帯電話では画像データを複数の電子メールに
分割し送信する方法を採用している。例えば、画像ファ
イルを8つに分割し8通のiモードメールとして送信し
た場合は4000バイト(4KB)の画像データを送受
信することができる。
【0019】以下、画像データを8通の電子メールに分
割して伝送する場合の従来の携帯電話システムの動作を
説明する。
割して伝送する場合の従来の携帯電話システムの動作を
説明する。
【0020】図7に電子メール送信時のフローを示す。
iモード携帯電話で画像ファイル(静止画像)を添付し
た電子メール(以下、画像添付メールと称す。)を送る
際は、まずはじめ、電子メール作成モードにて宛先(以
下、単にアドレスと称す。)、および用件(以下、サブ
ジェクトと称す。)等を設定する(ステップ1)。
iモード携帯電話で画像ファイル(静止画像)を添付し
た電子メール(以下、画像添付メールと称す。)を送る
際は、まずはじめ、電子メール作成モードにて宛先(以
下、単にアドレスと称す。)、および用件(以下、サブ
ジェクトと称す。)等を設定する(ステップ1)。
【0021】そして、電子メールの本文(文書)を作成
し(ステップ2)、添付する画像ファイルを選択する
(ステップ3)。以上が、ユーザーによる画像添付メー
ルの作成手順である。
し(ステップ2)、添付する画像ファイルを選択する
(ステップ3)。以上が、ユーザーによる画像添付メー
ルの作成手順である。
【0022】さらに、画像を送信する場合には、携帯電
話本体で以下の作業が引き続き行われ送信のための画像
添付メールが作成される。上記ステップ3において添付
する画像ファイルの選択が行われると、発信側iモード
携帯電話1の本体では該選択された画像ファイルをGI
Fファイル形式に圧縮するとともに、圧縮後の画像デー
タ(バイナリーデータ)をBASE64エンコードなど
の手法を用いて擬似ASCII(ASCII:Amer
ican Standard Code for In
formation Intercharge。なお、
ここでは本来のASCIIコードに変換できないような
バイナリーコードの変換も含める上で疑似ASCIIと
表現している)データに変換する(バイナリーファイル
から疑似ASCIIデータよりなるファイルに変換され
る)。
話本体で以下の作業が引き続き行われ送信のための画像
添付メールが作成される。上記ステップ3において添付
する画像ファイルの選択が行われると、発信側iモード
携帯電話1の本体では該選択された画像ファイルをGI
Fファイル形式に圧縮するとともに、圧縮後の画像デー
タ(バイナリーデータ)をBASE64エンコードなど
の手法を用いて擬似ASCII(ASCII:Amer
ican Standard Code for In
formation Intercharge。なお、
ここでは本来のASCIIコードに変換できないような
バイナリーコードの変換も含める上で疑似ASCIIと
表現している)データに変換する(バイナリーファイル
から疑似ASCIIデータよりなるファイルに変換され
る)。
【0023】そして、上記疑似ASCII変換された画
像ファイルは上記ステップ2において作成された文書の
後ろに添付され画像添付メールが構成される(ステップ
4)。
像ファイルは上記ステップ2において作成された文書の
後ろに添付され画像添付メールが構成される(ステップ
4)。
【0024】通常、インターネットメール(iモードメ
ール)はバイナリーデータを送信することができない。
よって、画像データなどのバイナリーデータを送信する
際はBASE64などを用いバイナリーデータを疑似A
SCII化してメールに添付する必要がある(なお、イ
ンターネットメールの詳細に関しては、現在一般的に用
いられているMIME(Multipurpose I
nternet Mail Extensions)に
規定されている。例えば、OPEN DESIGN N
o.8 電子メール・システム完全マスタ CQ出版社
1995年5月10日 初版発行参照)。
ール)はバイナリーデータを送信することができない。
よって、画像データなどのバイナリーデータを送信する
際はBASE64などを用いバイナリーデータを疑似A
SCII化してメールに添付する必要がある(なお、イ
ンターネットメールの詳細に関しては、現在一般的に用
いられているMIME(Multipurpose I
nternet Mail Extensions)に
規定されている。例えば、OPEN DESIGN N
o.8 電子メール・システム完全マスタ CQ出版社
1995年5月10日 初版発行参照)。
【0025】そして、ステップ4において作成された画
像添付メールは500バイト単位に分割され、複数の電
子メールとして携帯電話より送信される。その際、各電
子メールのヘッダ部分には、分割情報、および添付ファ
イル情報等が付加される(ステップ5)。上述のよう
に、複数に分割され送信された画像添付メールはパケッ
ト通信網5を介し受信側iモード携帯電話2に送信され
る。
像添付メールは500バイト単位に分割され、複数の電
子メールとして携帯電話より送信される。その際、各電
子メールのヘッダ部分には、分割情報、および添付ファ
イル情報等が付加される(ステップ5)。上述のよう
に、複数に分割され送信された画像添付メールはパケッ
ト通信網5を介し受信側iモード携帯電話2に送信され
る。
【0026】次に、画像添付メールの受信側のフローを
図8を用いて説明する。受信側iモード携帯電話2で
は、上記8通に分割され送信された画像添付メールを受
信すると、まずはじめに各電子メールのヘッダ部分に付
加されている分割情報に基づいてもとの1通の画像添付
メールを復元する(ステップ6)。
図8を用いて説明する。受信側iモード携帯電話2で
は、上記8通に分割され送信された画像添付メールを受
信すると、まずはじめに各電子メールのヘッダ部分に付
加されている分割情報に基づいてもとの1通の画像添付
メールを復元する(ステップ6)。
【0027】そして、画像添付メールを復元すると上記
ステップ5において付加した各電子メールのヘッダ部分
に付加されている添付ファイル情報をもとに添付画像フ
ァイルを分離する。その際、分離した添付ファイルの種
別(ここにいう種別とは、例えば、画像ファイル、音声
ファイル、ワードプロセッサのファイル等の種別を意味
する)を確認する。
ステップ5において付加した各電子メールのヘッダ部分
に付加されている添付ファイル情報をもとに添付画像フ
ァイルを分離する。その際、分離した添付ファイルの種
別(ここにいう種別とは、例えば、画像ファイル、音声
ファイル、ワードプロセッサのファイル等の種別を意味
する)を確認する。
【0028】そして、添付ファイルが画像ファイルの場
合、BASE64デコードを行い、もとのバイナリーデ
ータのファイルに変換する(ステップ7)。
合、BASE64デコードを行い、もとのバイナリーデ
ータのファイルに変換する(ステップ7)。
【0029】ステップ7の終了後、画像ファイルを所定
のメモリ領域に記録するとともに、受信側iモード携帯
電話2では画像添付メールが着信したことをユーザーに
通知する(メール着信情報)。その際、添付画像ありの
情報を付加する。これは、例えば、画像データとリンク
したアイコン情報をメールの最後に付加することによっ
て行われる(ステップ8)。
のメモリ領域に記録するとともに、受信側iモード携帯
電話2では画像添付メールが着信したことをユーザーに
通知する(メール着信情報)。その際、添付画像ありの
情報を付加する。これは、例えば、画像データとリンク
したアイコン情報をメールの最後に付加することによっ
て行われる(ステップ8)。
【0030】ユーザーは上記メール着信情報に基づき受
信メールを開き、本文確認後上記アイコンを選択する
(ステップ9)。上記アイコンが選択されると受信側i
モード携帯電話2では上記インターネットブラウザーを
起動し(ステップ10)、上記画像ファイルをデコード
(GIFファイル形式をデコードしもとの画像ファイル
を復元する)し表示する(ステップ11)。
信メールを開き、本文確認後上記アイコンを選択する
(ステップ9)。上記アイコンが選択されると受信側i
モード携帯電話2では上記インターネットブラウザーを
起動し(ステップ10)、上記画像ファイルをデコード
(GIFファイル形式をデコードしもとの画像ファイル
を復元する)し表示する(ステップ11)。
【0031】従来の携帯電話による画像添付メールの送
受信は、上述したように行われているため、画像添付メ
ールは複数のiモードメールに分割され送信される。図
8に示したように上記分割された電子メールを受信した
受信側iモード携帯電話2では、上記分割された各々の
電子メールを合成してもとの1通の画像添付メールを復
元する。
受信は、上述したように行われているため、画像添付メ
ールは複数のiモードメールに分割され送信される。図
8に示したように上記分割された電子メールを受信した
受信側iモード携帯電話2では、上記分割された各々の
電子メールを合成してもとの1通の画像添付メールを復
元する。
【0032】しかし、現在発売されているiモード携帯
電話(以下、下位機種と記す。)では上記分割された電
子メールの統合機能はサポートされていない。従って、
下位機種で上記画像添付メールを受信した場合は、8通
の単独メールとしてしか認識されない。よって、下位機
種で画像添付メールを受信した場合、先頭のメールに記
載されている文字情報しか読むことができず、添付ファ
イルに関しては上述のように疑似ASCII化された文
字列が表示される。
電話(以下、下位機種と記す。)では上記分割された電
子メールの統合機能はサポートされていない。従って、
下位機種で上記画像添付メールを受信した場合は、8通
の単独メールとしてしか認識されない。よって、下位機
種で画像添付メールを受信した場合、先頭のメールに記
載されている文字情報しか読むことができず、添付ファ
イルに関しては上述のように疑似ASCII化された文
字列が表示される。
【0033】特に、iモードを使用する場合、メール受
信に際しても情報量に応じて課金される。しかし、画像
添付メールをサポートしていない下位機種において上記
分割され送信された画像添付メールを受信しても画像を
閲覧することができない。
信に際しても情報量に応じて課金される。しかし、画像
添付メールをサポートしていない下位機種において上記
分割され送信された画像添付メールを受信しても画像を
閲覧することができない。
【0034】さらに、上記疑似ASCII化された添付
ファイル情報に関しても、電子メール受信者に課金され
る。
ファイル情報に関しても、電子メール受信者に課金され
る。
【0035】また、上記分割メールの統合機能がサポー
トされている場合においても、添付ファイルを画像ファ
イルとして認識できない場合は、疑似ASCII化され
た添付ファイルをバイナリーデータに変更することがで
きず、(BASE64デコード機能がサポートされてい
ない場合)上記場合と同様に画像添付メールを受信して
も携帯電話本体で画像を閲覧することができないだけで
はなく、上記疑似ASCII化された添付ファイル情報
に関しても課金される。
トされている場合においても、添付ファイルを画像ファ
イルとして認識できない場合は、疑似ASCII化され
た添付ファイルをバイナリーデータに変更することがで
きず、(BASE64デコード機能がサポートされてい
ない場合)上記場合と同様に画像添付メールを受信して
も携帯電話本体で画像を閲覧することができないだけで
はなく、上記疑似ASCII化された添付ファイル情報
に関しても課金される。
【0036】なお、上述では下位機種について述べた
が、上記画像添付メールをサポートしていない携帯電話
に画像添付メールを送信した場合にも同様の事態とな
る。
が、上記画像添付メールをサポートしていない携帯電話
に画像添付メールを送信した場合にも同様の事態とな
る。
【0037】さらに、上記画像添付メールをサポートし
ている場合においても、画像添付メール着信時に8通の
電子メールとして受信されるため、例えば、分割された
1通の電子メールに着信遅延が生じた場合、携帯電話で
該着信遅延メールが受信できないと該画像添付メールを
復元することができず、受信時間(最初の分割されたメ
ールを受信してから上記着信遅延メールを受信するまで
の時間)が非常に長くなる。
ている場合においても、画像添付メール着信時に8通の
電子メールとして受信されるため、例えば、分割された
1通の電子メールに着信遅延が生じた場合、携帯電話で
該着信遅延メールが受信できないと該画像添付メールを
復元することができず、受信時間(最初の分割されたメ
ールを受信してから上記着信遅延メールを受信するまで
の時間)が非常に長くなる。
【0038】また、他の分割された電子メールと着信遅
延メールの間に時間があるため1通の画像添付メールを
受信する際、携帯電話から電子メール着信音が2度鳴
る。さらに、上記遅延メールが複数メールに及んだ場合
は1通の画像添付メールの着信に対して複数回の該電子
メール着信音が鳴る。
延メールの間に時間があるため1通の画像添付メールを
受信する際、携帯電話から電子メール着信音が2度鳴
る。さらに、上記遅延メールが複数メールに及んだ場合
は1通の画像添付メールの着信に対して複数回の該電子
メール着信音が鳴る。
【0039】また、上述のように8通の電子メールに画
像データを分割して送信する場合、4000バイトのデ
ータを送信することができるが、画像データは上述のよ
うにBASE64エンコードなどの手法により疑似AS
CII化されるため、実際に送ることのできるデータ量
は約1/1.4倍になる。
像データを分割して送信する場合、4000バイトのデ
ータを送信することができるが、画像データは上述のよ
うにBASE64エンコードなどの手法により疑似AS
CII化されるため、実際に送ることのできるデータ量
は約1/1.4倍になる。
【0040】例えば、250文字をメッセージに割り当
てた場合、8通の電子メールで送ることのできる画像デ
ータファイルの大きさは3500バイト/1.4=25
00バイト程度になる。例えば、96画素×72ライン
の画像データを、iモード携帯電話でサポートされてい
るGIFファイル形式で最適化パレットを用いて圧縮し
た場合、表示色数は16色程度となり、原画像に対し画
質が非常に劣化する。
てた場合、8通の電子メールで送ることのできる画像デ
ータファイルの大きさは3500バイト/1.4=25
00バイト程度になる。例えば、96画素×72ライン
の画像データを、iモード携帯電話でサポートされてい
るGIFファイル形式で最適化パレットを用いて圧縮し
た場合、表示色数は16色程度となり、原画像に対し画
質が非常に劣化する。
【0041】しかし、GIFファイル形式に比べて画像
の圧縮効率が高いJPEG(Joint Photog
raphic Experts Group)等の圧縮
処理を用いた場合、同一の伝送データ量で画質の劣化が
少ない。
の圧縮効率が高いJPEG(Joint Photog
raphic Experts Group)等の圧縮
処理を用いた場合、同一の伝送データ量で画質の劣化が
少ない。
【0042】しかし、iモード携帯電話では上述のよう
にGIFファイル形式の画像データのデコーダは標準搭
載されているが、現状では上記JPEGなどの他の形式
の画像ファイル形式はサポートされていない。
にGIFファイル形式の画像データのデコーダは標準搭
載されているが、現状では上記JPEGなどの他の形式
の画像ファイル形式はサポートされていない。
【0043】従って、画像の圧縮方式としてJPEGを
使用した場合、分割された電子メールの受信をサポート
した携帯電話で上記画像添付メールを受信した際も、J
PEGデコーダをサポートしていない場合、携帯電話本
体で受信画像を閲覧することができない。
使用した場合、分割された電子メールの受信をサポート
した携帯電話で上記画像添付メールを受信した際も、J
PEGデコーダをサポートしていない場合、携帯電話本
体で受信画像を閲覧することができない。
【0044】すなわち、画像ファイルとして添付ファイ
ルを認識しJPEGファイルを構成できた場合であって
も画像をデコードできないため、JPEGファイルをパ
ソコンなどに一旦転送しないと受信画像を見ることがで
きない。
ルを認識しJPEGファイルを構成できた場合であって
も画像をデコードできないため、JPEGファイルをパ
ソコンなどに一旦転送しないと受信画像を見ることがで
きない。
【0045】特に、上記多機能型携帯電話(画像データ
(静止画像)の送受信を行うことができる携帯電話)の
市場の拡大のためには、上述した下位機種、あるいは他
機種(分割メールをサポートした携帯電話等)との互換
性が必要となる。
(静止画像)の送受信を行うことができる携帯電話)の
市場の拡大のためには、上述した下位機種、あるいは他
機種(分割メールをサポートした携帯電話等)との互換
性が必要となる。
【0046】また、画像ファイルは上述のように疑似A
SCII変換されているため、実際のデータと比べ約
1.4倍のデータ量になっている。したがって、パケッ
ト量に応じて課金されるiモードでは受信時の料金が必
要以上に高くなってしまう。
SCII変換されているため、実際のデータと比べ約
1.4倍のデータ量になっている。したがって、パケッ
ト量に応じて課金されるiモードでは受信時の料金が必
要以上に高くなってしまう。
【0047】また、画像添付メールを受信した際、ユー
ザーが画像データを見たくなくても添付画像データを受
信してしまうため、(送られてきた画像はすべて受信し
てしまうため)見たくない画像データに対しても課金が
なされてしまう。
ザーが画像データを見たくなくても添付画像データを受
信してしまうため、(送られてきた画像はすべて受信し
てしまうため)見たくない画像データに対しても課金が
なされてしまう。
【0048】
【発明が解決しようとする課題】従来の画像送受信携帯
電話システムは上記のように構成されているので、画像
データ(静止画像)を携帯電話同士で送受信を行う場
合、上述のように下位機種、あるいは他機種において送
信されてきた画像添付メールに添付された画像を閲覧す
ることができないといった問題点があった。
電話システムは上記のように構成されているので、画像
データ(静止画像)を携帯電話同士で送受信を行う場
合、上述のように下位機種、あるいは他機種において送
信されてきた画像添付メールに添付された画像を閲覧す
ることができないといった問題点があった。
【0049】また、画像を閲覧できないにもかかわらず
受信データ量に応じて課金が施されるといった問題点が
あった。
受信データ量に応じて課金が施されるといった問題点が
あった。
【0050】また、画像添付メールをサポートしている
携帯電話同士の画像データのやり取りであっても着信遅
延メールが発生した場合、画像添付メールの受信に非常
に時間がかかるとともに、複数通に別れてメールが送信
されるため、着信遅延メールが発生した場合、該着信遅
延メールが受信されるたびに携帯電話よりメール着信音
が鳴ってしまうという問題点があった。
携帯電話同士の画像データのやり取りであっても着信遅
延メールが発生した場合、画像添付メールの受信に非常
に時間がかかるとともに、複数通に別れてメールが送信
されるため、着信遅延メールが発生した場合、該着信遅
延メールが受信されるたびに携帯電話よりメール着信音
が鳴ってしまうという問題点があった。
【0051】また、画像ファイルは上述のように疑似A
SCII変換されているため実際のデータと比べ約1.
4倍のデータ量になっている。したがって、パケット量
に応じて課金されるiモードでは受信時の料金が必要以
上に高くなってしまうといった問題点があった。
SCII変換されているため実際のデータと比べ約1.
4倍のデータ量になっている。したがって、パケット量
に応じて課金されるiモードでは受信時の料金が必要以
上に高くなってしまうといった問題点があった。
【0052】また、画像添付メールを受信した際、ユー
ザーが画像データを見たくなくても添付画像データを受
信してしまうため、見たくない画像データに対しても課
金がなされてしまうといった問題点があった。
ザーが画像データを見たくなくても添付画像データを受
信してしまうため、見たくない画像データに対しても課
金がなされてしまうといった問題点があった。
【0053】この発明は、上述のような課題を解決する
ためになされたもので、下位機種、あるいは他機種に対
して画像添付メールを送信した場合、不必要な添付画像
データの受信、および課金(画像の閲覧ができないにも
かかわらず課金される)がなされない中継サーバを利用
した情報通信方法および情報通信システムを得ることを
目的とする。
ためになされたもので、下位機種、あるいは他機種に対
して画像添付メールを送信した場合、不必要な添付画像
データの受信、および課金(画像の閲覧ができないにも
かかわらず課金される)がなされない中継サーバを利用
した情報通信方法および情報通信システムを得ることを
目的とする。
【0054】さらに、下位機種、あるいは他機種に対し
て画像添付メールを送信した場合においても、受信側で
添付された画像ファイルを閲覧することができる中継サ
ーバを利用した情報通信方法および情報通信システムを
得ることを目的とする。
て画像添付メールを送信した場合においても、受信側で
添付された画像ファイルを閲覧することができる中継サ
ーバを利用した情報通信方法および情報通信システムを
得ることを目的とする。
【0055】また、画像添付メール受信にあたって不必
要な受信遅延、あるいは複数回にわたるメールの着信音
が鳴らない中継サーバを利用した情報通信方法および情
報通信システムを得ることを目的とする。
要な受信遅延、あるいは複数回にわたるメールの着信音
が鳴らない中継サーバを利用した情報通信方法および情
報通信システムを得ることを目的とする。
【0056】また、画像添付メール受信にあたって受信
データ量を最小限に抑え、必要以上の課金が行われない
中継サーバを利用した情報通信方法および情報通信シス
テムを得ることを目的とする。
データ量を最小限に抑え、必要以上の課金が行われない
中継サーバを利用した情報通信方法および情報通信シス
テムを得ることを目的とする。
【0057】また、ユーザーが添付データを必要としな
いときには添付データを受け取らない中継サーバを利用
した情報通信方法および情報通信システムを得ることを
目的とする。
いときには添付データを受け取らない中継サーバを利用
した情報通信方法および情報通信システムを得ることを
目的とする。
【0058】
【課題を解決するための手段】本発明に係る情報通信方
法は、送信情報を所定形式のコード列に変換して得られ
た変換コードの一部および受信者宛先より構成された複
数の受信情報を受信する受信段階と、該受信段階におい
て受信される前記複数の受信情報を統合して前記送信情
報に対応する前記変換コードの全部を復元する復元段階
と、該復元段階において復元される前記変換コードの全
部に基づいて前記送信情報または前記送信情報と実質的
に等価な情報を生成して、指定される記憶先に記憶する
記憶段階と、前記受信者宛先に前記記憶段階において指
定された前記記憶先を送信する送信段階とを含む。
法は、送信情報を所定形式のコード列に変換して得られ
た変換コードの一部および受信者宛先より構成された複
数の受信情報を受信する受信段階と、該受信段階におい
て受信される前記複数の受信情報を統合して前記送信情
報に対応する前記変換コードの全部を復元する復元段階
と、該復元段階において復元される前記変換コードの全
部に基づいて前記送信情報または前記送信情報と実質的
に等価な情報を生成して、指定される記憶先に記憶する
記憶段階と、前記受信者宛先に前記記憶段階において指
定された前記記憶先を送信する送信段階とを含む。
【0059】また、送信情報に所定の変換処理を施して
当該送信情報と実質的に同等の情報を得る変換処理段階
を含む。
当該送信情報と実質的に同等の情報を得る変換処理段階
を含む。
【0060】また、変換処理は、疑似ASCII化され
た送信情報をバイナリー情報に変換する。
た送信情報をバイナリー情報に変換する。
【0061】また、送信情報と共に当該送信情報と実質
的に同等の情報を指定される記憶先に記憶する。
的に同等の情報を指定される記憶先に記憶する。
【0062】本発明に係る情報通信装置は、送信情報を
所定形式のコード列に変換して得られた変換コードの一
部および受信者宛先より構成された複数の受信情報を受
信し、該受信した複数の受信情報を統合して前記送信情
報に対応する前記変換コードの全部を復元する復元手段
と、該復元手段において復元される前記変換コードの全
部に基づいて前記送信情報または前記送信情報と実質的
に等価な情報を生成して、指定される記憶先に記憶する
記憶手段と、前記受信者宛先に前記記憶手段において指
定された前記記憶先を送信する送信手段とを有する。
所定形式のコード列に変換して得られた変換コードの一
部および受信者宛先より構成された複数の受信情報を受
信し、該受信した複数の受信情報を統合して前記送信情
報に対応する前記変換コードの全部を復元する復元手段
と、該復元手段において復元される前記変換コードの全
部に基づいて前記送信情報または前記送信情報と実質的
に等価な情報を生成して、指定される記憶先に記憶する
記憶手段と、前記受信者宛先に前記記憶手段において指
定された前記記憶先を送信する送信手段とを有する。
【0063】また、送信情報に所定の変換処理を施して
当該送信情報と実質的に同等の情報を得る変換処理手段
を備える。
当該送信情報と実質的に同等の情報を得る変換処理手段
を備える。
【0064】また、変換処理手段における変換処理は、
疑似ASCII化された送信情報をバイナリー情報に変
換する。
疑似ASCII化された送信情報をバイナリー情報に変
換する。
【0065】また、記憶手段は、送信情報と共に当該送
信情報と実質的に同等の情報を記憶するように構成され
る。
信情報と実質的に同等の情報を記憶するように構成され
る。
【0066】
【発明の実施の形態】以下、この発明をその実施の形態
を示す図面に基づいて具体的に説明する。なお、以下の
説明においては、添付ファイルが送信情報、例えばBA
SE64形式に変換されたコード(列)が所定形式のコ
ード列、受信者アドレスが受信者宛先、例えばGIFデ
ータから変換されたJPEG等のデータが送信情報と実
質的に等価な情報、送信情報または送信情報と実質的に
等価な情報が記憶されたURLが記憶先にそれぞれ相当
する。
を示す図面に基づいて具体的に説明する。なお、以下の
説明においては、添付ファイルが送信情報、例えばBA
SE64形式に変換されたコード(列)が所定形式のコ
ード列、受信者アドレスが受信者宛先、例えばGIFデ
ータから変換されたJPEG等のデータが送信情報と実
質的に等価な情報、送信情報または送信情報と実質的に
等価な情報が記憶されたURLが記憶先にそれぞれ相当
する。
【0067】実施の形態1.図1は、この発明の実施の
形態1である中継サーバを利用した情報通信装置のシス
テム構成図である。図において、図6と同一符号を記し
たものは構成および動作が従来のものと同様であるので
詳細な説明を省略する。図において8は中継サーバであ
る。
形態1である中継サーバを利用した情報通信装置のシス
テム構成図である。図において、図6と同一符号を記し
たものは構成および動作が従来のものと同様であるので
詳細な説明を省略する。図において8は中継サーバであ
る。
【0068】図2に、上記中継サーバ8の画像添付メー
ル受信時のフローを示す。
ル受信時のフローを示す。
【0069】以下、図1を用いて本発明の実施の形態1
の概要を説明する。本実施の形態1では発信側iモード
携帯電話1から受信側iモード携帯電話2へ画像添付メ
ールを送信する際の中継サーバ8の動作を中心に説明す
ることとし、従来例と同様にiモード携帯電話を使用
し、画像添付メール送信の際は、該画像添付メールを8
通に分割し送信するものとする。
の概要を説明する。本実施の形態1では発信側iモード
携帯電話1から受信側iモード携帯電話2へ画像添付メ
ールを送信する際の中継サーバ8の動作を中心に説明す
ることとし、従来例と同様にiモード携帯電話を使用
し、画像添付メール送信の際は、該画像添付メールを8
通に分割し送信するものとする。
【0070】以下、本実施の形態1による画像添付メー
ル送受信システムの概要を説明する。発信側iモード携
帯電話1において作成された画像添付メールは、従来例
と同様に発信側iモード携帯電話1の本体において8通
の電子メールに分割される。
ル送受信システムの概要を説明する。発信側iモード携
帯電話1において作成された画像添付メールは、従来例
と同様に発信側iモード携帯電話1の本体において8通
の電子メールに分割される。
【0071】その際、発信側iモード携帯電話1におい
ては、分割された各電子メールの宛先(アドレス)を上
記中継サーバ8内に設けられたあらかじめ定められたア
ドレスに送信するものとして以下説明を続ける。発信側
iモード携帯電話1により8通に分割され送信された画
像添付メールは上記アドレスをもとに中継基地3、パケ
ット通信網5、ゲートウェイサーバ6およびインターネ
ット網7を経由して中継サーバ8へ送信される。
ては、分割された各電子メールの宛先(アドレス)を上
記中継サーバ8内に設けられたあらかじめ定められたア
ドレスに送信するものとして以下説明を続ける。発信側
iモード携帯電話1により8通に分割され送信された画
像添付メールは上記アドレスをもとに中継基地3、パケ
ット通信網5、ゲートウェイサーバ6およびインターネ
ット網7を経由して中継サーバ8へ送信される。
【0072】上記、8通に分割された画像添付メールを
受信すると中継サーバ8では、まずはじめ、分割された
各々のメールのヘッダ情報を基に、8通に分割された画
像添付メールの統合を行って1通の画像添付メールを中
継サーバ8内で構成する。
受信すると中継サーバ8では、まずはじめ、分割された
各々のメールのヘッダ情報を基に、8通に分割された画
像添付メールの統合を行って1通の画像添付メールを中
継サーバ8内で構成する。
【0073】そして、この復元された画像添付メールよ
り本文および画像添付ファイルを分離し、該画像添付フ
ァイルを上記中継サーバ8内に記憶する。
り本文および画像添付ファイルを分離し、該画像添付フ
ァイルを上記中継サーバ8内に記憶する。
【0074】なお、中継サーバ8内に上記添付画像ファ
イルを記憶する際、該中継サーバ8に関する記憶アドレ
ス(URL)を生成する。この後、上記画像添付メール
の本文(文字情報部)、および上記URLを含む通知メ
ールを作成し、受信側iモード携帯電話2に該通知メー
ルを送信する。
イルを記憶する際、該中継サーバ8に関する記憶アドレ
ス(URL)を生成する。この後、上記画像添付メール
の本文(文字情報部)、および上記URLを含む通知メ
ールを作成し、受信側iモード携帯電話2に該通知メー
ルを送信する。
【0075】そして、受信側iモード携帯電話2におい
ては、上記通知メールを受信すると、メールを開いて受
信したURLを選択し、添付画像ファイルを中継サーバ
8よりダウンロードする。
ては、上記通知メールを受信すると、メールを開いて受
信したURLを選択し、添付画像ファイルを中継サーバ
8よりダウンロードする。
【0076】以下、図2、図3および図7を用いて本実
施の形態1の画像添付メールの送受信方法および中継サ
ーバ8の詳細な動作について説明する。なお、画像メー
ルの作成手順に関しては図7を参照して説明した従来例
と同様であるので詳細な説明は省略する。
施の形態1の画像添付メールの送受信方法および中継サ
ーバ8の詳細な動作について説明する。なお、画像メー
ルの作成手順に関しては図7を参照して説明した従来例
と同様であるので詳細な説明は省略する。
【0077】また、ここでは、受信側iモード携帯電話
2が上記中継サーバ8上に画像添付メールを受信するた
めのアドレスを有する場合について説明する。
2が上記中継サーバ8上に画像添付メールを受信するた
めのアドレスを有する場合について説明する。
【0078】図7において、発信側iモード携帯電話1
では画像添付メール作成の際は、まずはじめ、従来例と
同様に、ステップ1において宛先(上述のように、中継
サーバ8内の受信側iモード携帯電話2のアドレス)、
およびサブジェクトを設定する。
では画像添付メール作成の際は、まずはじめ、従来例と
同様に、ステップ1において宛先(上述のように、中継
サーバ8内の受信側iモード携帯電話2のアドレス)、
およびサブジェクトを設定する。
【0079】そして、ステップ2において画像ファイル
に添付する文書を作成し、ステップ3において添付する
画像ファイルを選択する。なお、本実施の形態1では、
画像ファイルの圧縮形式としてGIFファイル形式を使
用する場合について説明する。従来例でも述べたがiモ
ード携帯電話のインターネットブラウザーではGIFフ
ァイル形式に圧縮された画像を復元(デコード)閲覧す
ることができる。
に添付する文書を作成し、ステップ3において添付する
画像ファイルを選択する。なお、本実施の形態1では、
画像ファイルの圧縮形式としてGIFファイル形式を使
用する場合について説明する。従来例でも述べたがiモ
ード携帯電話のインターネットブラウザーではGIFフ
ァイル形式に圧縮された画像を復元(デコード)閲覧す
ることができる。
【0080】そして、上記ステップ3において、添付す
る画像ファイルの選択が行われると発信側iモード携帯
電話1本体では、選択された画像ファイルにGIFファ
イル形式の圧縮を施した後、BASE64エンコードを
施し疑似ASCIIデータに変換する。
る画像ファイルの選択が行われると発信側iモード携帯
電話1本体では、選択された画像ファイルにGIFファ
イル形式の圧縮を施した後、BASE64エンコードを
施し疑似ASCIIデータに変換する。
【0081】この疑似ASCII変換された画像ファイ
ルはステップ4において該電子メールの本文の後ろに添
付される。そして、ステップ4において作成された画像
添付メールは500バイト単位に分割され(ステップ
5)、複数の電子メールとして発信側iモード携帯電話
1より送信される。なお、ステップ5において各電子メ
ールのヘッダ部分には、分割情報、および添付ファイル
情報等が付加される。
ルはステップ4において該電子メールの本文の後ろに添
付される。そして、ステップ4において作成された画像
添付メールは500バイト単位に分割され(ステップ
5)、複数の電子メールとして発信側iモード携帯電話
1より送信される。なお、ステップ5において各電子メ
ールのヘッダ部分には、分割情報、および添付ファイル
情報等が付加される。
【0082】上記、複数に分割され送信された画像添付
メールはパケット通信網5、ゲートウェイサーバ6およ
びインターネット網7を介し中継サーバ8に送信され
る。
メールはパケット通信網5、ゲートウェイサーバ6およ
びインターネット網7を介し中継サーバ8に送信され
る。
【0083】次に、画像添付メール受信時の中継サーバ
8における処理フローを図2を用いて説明する。
8における処理フローを図2を用いて説明する。
【0084】中継サーバ8では、上記8通に分割され送
信された画像添付メールを受信すると、まずはじめ、各
電子メールのヘッダ部分に付加されている分割情報を分
離する(ステップ10)。
信された画像添付メールを受信すると、まずはじめ、各
電子メールのヘッダ部分に付加されている分割情報を分
離する(ステップ10)。
【0085】分割された8通の画像添付メールがすべて
中継サーバ8に到着すると、中継サーバ8では分離した
分割情報に基づいてもとの1通の画像添付メールを復元
する(ステップ11)。
中継サーバ8に到着すると、中継サーバ8では分離した
分割情報に基づいてもとの1通の画像添付メールを復元
する(ステップ11)。
【0086】そして、各電子メールのヘッダ部分に付加
されている添付ファイル情報をもとに添付画像ファイル
を分離する。その際、分離した添付ファイルの種別を確
認する(ステップ12)。
されている添付ファイル情報をもとに添付画像ファイル
を分離する。その際、分離した添付ファイルの種別を確
認する(ステップ12)。
【0087】ステップ13においては、確認した添付フ
ァイルの種別をもとに、添付ファイルが画像ファイルの
場合、BASE64デコードを行って、もとのバイナリ
ーデータのファイルに変換する。
ァイルの種別をもとに、添付ファイルが画像ファイルの
場合、BASE64デコードを行って、もとのバイナリ
ーデータのファイルに変換する。
【0088】そして、元のバイナリーデータの画像ファ
イルに復元後、該画像ファイルを中継サーバ8内の所定
の記憶領域(ディスク領域)に記録するとともに、記録
した画像データの記録アドレス(URL)を作成する
(ステップ14)。
イルに復元後、該画像ファイルを中継サーバ8内の所定
の記憶領域(ディスク領域)に記録するとともに、記録
した画像データの記録アドレス(URL)を作成する
(ステップ14)。
【0089】その後、ステップ11において復元した画
像添付メールの本文に作成したURLを付加し、画像添
付メールが到着したことを伝える通知メールを作成する
(ステップ15)。
像添付メールの本文に作成したURLを付加し、画像添
付メールが到着したことを伝える通知メールを作成する
(ステップ15)。
【0090】そして、受信側iモード携帯電話2に該通
知メールを送信し画像添付メールが到着したことを伝え
る。
知メールを送信し画像添付メールが到着したことを伝え
る。
【0091】なお、本実施の形態1では上記画像添付メ
ールの送信先は受信側iモード携帯電話2が中継サーバ
8内に予め登録されたアカウントであるので、予め中継
サーバ8からの転送先が設定されているものとして説明
を続ける(すなわち、転送先があらかじめ受信側iモー
ド携帯電話2のアドレスに設定されるよう該中継サーバ
8を構成した場合に相当する)。
ールの送信先は受信側iモード携帯電話2が中継サーバ
8内に予め登録されたアカウントであるので、予め中継
サーバ8からの転送先が設定されているものとして説明
を続ける(すなわち、転送先があらかじめ受信側iモー
ド携帯電話2のアドレスに設定されるよう該中継サーバ
8を構成した場合に相当する)。
【0092】次に、該通知メール受信時の受信側iモー
ド携帯電話2における動作を図3を用いて説明する。通
知メールを受信すると受信側iモード携帯電話2におい
てはメール着信を通知するため着信音がなる(ステップ
16)。
ド携帯電話2における動作を図3を用いて説明する。通
知メールを受信すると受信側iモード携帯電話2におい
てはメール着信を通知するため着信音がなる(ステップ
16)。
【0093】ユーザーは電子メールの着信音が鳴ると着
信メールを閲覧するために電子メールブラウザーを起動
し、着信した電子メール(着信メールの選択、および閲
覧)を開き内容を確認する(ステップ17)。
信メールを閲覧するために電子メールブラウザーを起動
し、着信した電子メール(着信メールの選択、および閲
覧)を開き内容を確認する(ステップ17)。
【0094】ステップ18において受信メールが通常の
電子メールか、画像添付メールの通知メールか判断す
る。通常の電子メールの場合は本文閲覧後、電子メール
ブラウザーを終了する(ステップ19)。
電子メールか、画像添付メールの通知メールか判断す
る。通常の電子メールの場合は本文閲覧後、電子メール
ブラウザーを終了する(ステップ19)。
【0095】着信した電子メールが画像添付メールの通
知メールであった場合、ユーザは発信者アドレス情報お
よび本文を読み画像データを閲覧する(ダウンロードす
る)かどうか判断する(ステップ20)。
知メールであった場合、ユーザは発信者アドレス情報お
よび本文を読み画像データを閲覧する(ダウンロードす
る)かどうか判断する(ステップ20)。
【0096】なお、ここでは着信メールが画像添付メー
ルの通知メールであるかは通知メールの送信アドレス、
あるいは通知メールに付加されている上記URLによっ
て判断するものとする。
ルの通知メールであるかは通知メールの送信アドレス、
あるいは通知メールに付加されている上記URLによっ
て判断するものとする。
【0097】ステップ20において画像データを閲覧し
ない場合は、通知メールの本文閲覧後、ステップ19に
おいて電子メールブラウザーを終了し、電子メールの閲
覧を終了する。
ない場合は、通知メールの本文閲覧後、ステップ19に
おいて電子メールブラウザーを終了し、電子メールの閲
覧を終了する。
【0098】従って、上述のように、画像添付メールの
通知メールに記載されている本文の内容、あるいは差出
人アドレスにより電子メールに添付された画像ファイル
の閲覧をユーザーが選択することができるので、発信側
iモード携帯電話1から送信された画像データを受信側
iモード携帯電話2を持つ受信者の選択により画像デー
タの受信の要否の選択ができる。
通知メールに記載されている本文の内容、あるいは差出
人アドレスにより電子メールに添付された画像ファイル
の閲覧をユーザーが選択することができるので、発信側
iモード携帯電話1から送信された画像データを受信側
iモード携帯電話2を持つ受信者の選択により画像デー
タの受信の要否の選択ができる。
【0099】また、ステップ20において画像データを
閲覧する場合は、ユーザーは通知メールに添付されてい
る上記URLを選択する(ステップ21)。受信側iモ
ード携帯電話2は、上記URLが選択されると従来例と
同様にインターネットブラウザーを起動する(ステップ
22)。
閲覧する場合は、ユーザーは通知メールに添付されてい
る上記URLを選択する(ステップ21)。受信側iモ
ード携帯電話2は、上記URLが選択されると従来例と
同様にインターネットブラウザーを起動する(ステップ
22)。
【0100】そして、URL情報をもとに中継サーバ8
より画像ファイルをダウンロードするよう要求コマンド
を中継サーバ8に送信する(ステップ23)。
より画像ファイルをダウンロードするよう要求コマンド
を中継サーバ8に送信する(ステップ23)。
【0101】画像ファイルのダウンロードが完了すると
インターネットブラウザーはダウンロードした画像ファ
イルのデコード(GIFファイルのデコード)を行う
(ステップ24)。
インターネットブラウザーはダウンロードした画像ファ
イルのデコード(GIFファイルのデコード)を行う
(ステップ24)。
【0102】上述したが、iモード携帯電話のインター
ネットブラウザーはGIFファイルのデコーダを標準サ
ポートしており、GIFファイル形式に圧縮された画像
をすべての機種で閲覧することができる。
ネットブラウザーはGIFファイルのデコーダを標準サ
ポートしており、GIFファイル形式に圧縮された画像
をすべての機種で閲覧することができる。
【0103】画像データ閲覧後、ダウンロードしてきた
画像ファイルを記録するか確認する(ステップ25)。
現実の携帯電話本体はその大きさ、および許容しうる消
費電力などの制限から、画像ファイルのような大きなフ
ァイルを何十枚も記憶するようなメモリを搭載していな
い。
画像ファイルを記録するか確認する(ステップ25)。
現実の携帯電話本体はその大きさ、および許容しうる消
費電力などの制限から、画像ファイルのような大きなフ
ァイルを何十枚も記憶するようなメモリを搭載していな
い。
【0104】よって、本実施の形態1では画像ファイル
の内容確認後ユーザーに画像データを記憶するかを確認
する構成とした。ステップ25において画像ファイルを
記録しない場合は、画像閲覧後インターネットブラウザ
ーを終了し、電子メールの閲覧画面に戻る(ステップ2
7)。
の内容確認後ユーザーに画像データを記憶するかを確認
する構成とした。ステップ25において画像ファイルを
記録しない場合は、画像閲覧後インターネットブラウザ
ーを終了し、電子メールの閲覧画面に戻る(ステップ2
7)。
【0105】一方、画像ファイルを記憶する場合は、メ
モリの空きスペースを確認後、画像ファイルをメモリに
記録し(ステップ26)、インターネットブラウザーを
終了する(ステップ27)。
モリの空きスペースを確認後、画像ファイルをメモリに
記録し(ステップ26)、インターネットブラウザーを
終了する(ステップ27)。
【0106】最後に、ステップ19において電子メール
ブラウザーを終了し、電子メールの閲覧を終了する。
ブラウザーを終了し、電子メールの閲覧を終了する。
【0107】本実施の形態1の中継サーバを利用した情
報通信方法および情報通信システムは以上のように構成
されているので、8通に分割され送信された画像添付メ
ールも、従来例で述べたような分割された電子メールの
統合機能のサポートされていない下位機種、あるいは画
像添付メールをサポートしていない他機種に送信した場
合でも、分割されたメールの統合、疑似ASCII化さ
れた画像ファイルのバイナリー変換(BASE64デコ
ード)等を中継サーバ8で行うので画像ファイルの閲覧
することができる。
報通信方法および情報通信システムは以上のように構成
されているので、8通に分割され送信された画像添付メ
ールも、従来例で述べたような分割された電子メールの
統合機能のサポートされていない下位機種、あるいは画
像添付メールをサポートしていない他機種に送信した場
合でも、分割されたメールの統合、疑似ASCII化さ
れた画像ファイルのバイナリー変換(BASE64デコ
ード)等を中継サーバ8で行うので画像ファイルの閲覧
することができる。
【0108】また、本実施の形態1では、上述のように
下位機種、あるいは他機種で画像添付メールの送受信機
能のサポートされていない携帯電話での画像添付メール
(画像ファイル)の閲覧が可能となり、従来例で示した
ような画像ファイルの閲覧ができないにもかかわらず課
金されるといった問題点も発生しなくなる効果がある。
下位機種、あるいは他機種で画像添付メールの送受信機
能のサポートされていない携帯電話での画像添付メール
(画像ファイル)の閲覧が可能となり、従来例で示した
ような画像ファイルの閲覧ができないにもかかわらず課
金されるといった問題点も発生しなくなる効果がある。
【0109】さらに、本実施の形態1では分割され送信
された画像添付メールの統合機能を中継サーバ8で行
い、iモード携帯電話本体には画像添付メールの本文と
URLを通知メールとして送信するので、分割された各
電子メール送信中に一部の電子メールに着信遅延が生じ
ても、サーバ側で分割されたすべての電子メールがそろ
うまで通知メールを送信しないので、従来例で示したよ
うな画像添付メール1通の受信に非常に時間がかかる、
あるいは、同一電子メールの着信にもかかわらず着信音
が2度以上鳴るといった問題点が発生しなくなるという
効果がある。
された画像添付メールの統合機能を中継サーバ8で行
い、iモード携帯電話本体には画像添付メールの本文と
URLを通知メールとして送信するので、分割された各
電子メール送信中に一部の電子メールに着信遅延が生じ
ても、サーバ側で分割されたすべての電子メールがそろ
うまで通知メールを送信しないので、従来例で示したよ
うな画像添付メール1通の受信に非常に時間がかかる、
あるいは、同一電子メールの着信にもかかわらず着信音
が2度以上鳴るといった問題点が発生しなくなるという
効果がある。
【0110】また、本実施の形態1では、上述のよう
に、画像添付メールの通知メールに記載されている本文
の内容、あるいは差出人アドレスにより電子メールに添
付された画像ファイルの閲覧をユーザーが選択すること
ができる。
に、画像添付メールの通知メールに記載されている本文
の内容、あるいは差出人アドレスにより電子メールに添
付された画像ファイルの閲覧をユーザーが選択すること
ができる。
【0111】従って、本実施の形態1に示す静止画像を
送受信するシステムでは、送信された画像ファイルを受
信者の選択によりダウンロード(受信、および閲覧)で
きるので、受信者が不必要と思われる画像ファイルをむ
やみにダウンロードしなくてすみ、画像添付メール受信
時に必要以上の課金がなされない効果がある。
送受信するシステムでは、送信された画像ファイルを受
信者の選択によりダウンロード(受信、および閲覧)で
きるので、受信者が不必要と思われる画像ファイルをむ
やみにダウンロードしなくてすみ、画像添付メール受信
時に必要以上の課金がなされない効果がある。
【0112】また、本実施の形態1では、中継サーバ8
で擬似ASCII化された画像ファイルをバイナリーデ
ータのファイル(本実施の形態1ではBASE64デコ
ードに対応する。)に変換しダウンロードするので、従
来の擬似ASCII化された画像ファイルのやり取りと
比較しデータ量が約1/1.4倍になり、画像ファイル
収得時に発生する課金を少なくすることができる効果が
ある。
で擬似ASCII化された画像ファイルをバイナリーデ
ータのファイル(本実施の形態1ではBASE64デコ
ードに対応する。)に変換しダウンロードするので、従
来の擬似ASCII化された画像ファイルのやり取りと
比較しデータ量が約1/1.4倍になり、画像ファイル
収得時に発生する課金を少なくすることができる効果が
ある。
【0113】特に、iモードメールの場合、1通の電子
メール(250文字)の受信に当たっては、250文字
の文字データ(画像データ)以外のオーバーヘッドが多
く、画像添付メール受信時は必要以上にデータ量が多く
なってしまうが、本実施の形態1では上記画像データ以
外のオーバーヘッドを最小限に押さえることができる効
果がある。(パケット量の節約がはかれる。)
メール(250文字)の受信に当たっては、250文字
の文字データ(画像データ)以外のオーバーヘッドが多
く、画像添付メール受信時は必要以上にデータ量が多く
なってしまうが、本実施の形態1では上記画像データ以
外のオーバーヘッドを最小限に押さえることができる効
果がある。(パケット量の節約がはかれる。)
【0114】実施の形態2.図4はこの発明の実施の形
態2である中継サーバを利用した情報通信方式、および
情報通信装置における上記中継サーバ8の画像メール受
信時のフローを示す。本実施の形態2では、添付画像フ
ァイルの圧縮方式としてJPEGを用いた場合の動作を
説明する。
態2である中継サーバを利用した情報通信方式、および
情報通信装置における上記中継サーバ8の画像メール受
信時のフローを示す。本実施の形態2では、添付画像フ
ァイルの圧縮方式としてJPEGを用いた場合の動作を
説明する。
【0115】なお、中継サーバ8を利用した情報通信装
置のシステム構成図は図1を参照して説明した実施の形
態1と同様であり、また、発信側iモード携帯電話1で
の画像添付メール作成時の動作(手順)も実施の形態1
と同様なので詳細な動作の説明は省略する。
置のシステム構成図は図1を参照して説明した実施の形
態1と同様であり、また、発信側iモード携帯電話1で
の画像添付メール作成時の動作(手順)も実施の形態1
と同様なので詳細な動作の説明は省略する。
【0116】また、受信側iモード携帯電話2での画像
添付メール受信時の動作(手順)も実施の形態1と同様
なので詳細な動作の説明は省略する。
添付メール受信時の動作(手順)も実施の形態1と同様
なので詳細な動作の説明は省略する。
【0117】また、本実施の形態2においても実施の形
態1と同様に、発信側iモード携帯電話1から受信側i
モード携帯電話2へ画像添付メールを送信する際の中継
サーバ8の動作を中心に説明する。
態1と同様に、発信側iモード携帯電話1から受信側i
モード携帯電話2へ画像添付メールを送信する際の中継
サーバ8の動作を中心に説明する。
【0118】また、本実施の形態2でも実施の形態1と
同様にiモード携帯電話を使用し、画像添付メール送信
の際は、該画像添付メールを8通に分割し送信するもの
とする。その際、実施の形態1と同様に、発信側iモー
ド携帯電話1では分割された各電子メールの宛先(アド
レス)を上記中継サーバ8に設けられたあらかじめ定め
られたアドレスに送信するものとして以下説明を続け
る。
同様にiモード携帯電話を使用し、画像添付メール送信
の際は、該画像添付メールを8通に分割し送信するもの
とする。その際、実施の形態1と同様に、発信側iモー
ド携帯電話1では分割された各電子メールの宛先(アド
レス)を上記中継サーバ8に設けられたあらかじめ定め
られたアドレスに送信するものとして以下説明を続け
る。
【0119】以下、本実施の形態2で画像圧縮方式とし
てJPEGを使用する理由を簡単に説明する。従来例で
も述べたが、iモードメール8通で送ることのできるデ
ータ量は、1通を文字情報を送ると仮定すると2500
バイト程度となる。
てJPEGを使用する理由を簡単に説明する。従来例で
も述べたが、iモードメール8通で送ることのできるデ
ータ量は、1通を文字情報を送ると仮定すると2500
バイト程度となる。
【0120】例えば、96画素×72ラインのカラー画
像データを2500バイト以下にGIFファイル形式で
圧縮した場合、コンピュータシミュレーションの結果、
最適化したカラーパレットを用いて圧縮すると、16
色、あるいは8色程度の色数でしか圧縮することができ
ず、送信画像の画質劣化はいなめない。
像データを2500バイト以下にGIFファイル形式で
圧縮した場合、コンピュータシミュレーションの結果、
最適化したカラーパレットを用いて圧縮すると、16
色、あるいは8色程度の色数でしか圧縮することができ
ず、送信画像の画質劣化はいなめない。
【0121】GIFファイル形式を用いた場合、画質を
確保しようとした場合は画像添付メールの分割数を増や
す必要があるが、送受信のためのデータ量が増加し、画
像添付メール1通あたりのコストが上がる。
確保しようとした場合は画像添付メールの分割数を増や
す必要があるが、送受信のためのデータ量が増加し、画
像添付メール1通あたりのコストが上がる。
【0122】一方、GIFファイル形式に比べて画像の
圧縮効率が高いJPEG等の圧縮手法を用いた場合は同
一の伝送データ量で画質の劣化が少ないため、以下はこ
のような、画像圧縮方式としてJPEGを用いた場合の
中継サーバを利用した情報通信方式、および情報通信装
置について説明する。
圧縮効率が高いJPEG等の圧縮手法を用いた場合は同
一の伝送データ量で画質の劣化が少ないため、以下はこ
のような、画像圧縮方式としてJPEGを用いた場合の
中継サーバを利用した情報通信方式、および情報通信装
置について説明する。
【0123】以下、本実施の形態2による画像添付メー
ル送受信システムの概要を説明する。図1において、発
信側iモード携帯電話1により8通に分割され送信され
た画像添付メールは、実施の形態1と同様に上記アドレ
スをもとに中継基地3、パケット網5、ゲートウェイサ
ーバ6、およびインターネット網7を経由して中継サー
バ8へ送信される。
ル送受信システムの概要を説明する。図1において、発
信側iモード携帯電話1により8通に分割され送信され
た画像添付メールは、実施の形態1と同様に上記アドレ
スをもとに中継基地3、パケット網5、ゲートウェイサ
ーバ6、およびインターネット網7を経由して中継サー
バ8へ送信される。
【0124】8通に分割された画像添付を受信すると中
継サーバ8では実施の形態1と同様に8通に分割された
画像添付メールの統合を行う。そして、上記復元した画
像添付メールより本文、およびJPEG形式で送信され
た添付画像ファイルを分離する。該分離されたJPEG
ファイルは実施の形態1と同様にBASE64デコード
が施されもとのバイナリーデータのJPEGファイルに
復元される。
継サーバ8では実施の形態1と同様に8通に分割された
画像添付メールの統合を行う。そして、上記復元した画
像添付メールより本文、およびJPEG形式で送信され
た添付画像ファイルを分離する。該分離されたJPEG
ファイルは実施の形態1と同様にBASE64デコード
が施されもとのバイナリーデータのJPEGファイルに
復元される。
【0125】該復元されたバイナリーデータのJPEG
ファイルは、中継サーバ8内でデコードされ元の画像に
復元される。次に、該復元された画像を中継サーバ8は
GIFファイル形式に再圧縮する。
ファイルは、中継サーバ8内でデコードされ元の画像に
復元される。次に、該復元された画像を中継サーバ8は
GIFファイル形式に再圧縮する。
【0126】該バイナリーデータに変換されたJPEG
ファイルと、該GIFファイル形式に圧縮された画像フ
ァイルの両方の画像ファイルを上記中継サーバ8内に記
憶する。
ファイルと、該GIFファイル形式に圧縮された画像フ
ァイルの両方の画像ファイルを上記中継サーバ8内に記
憶する。
【0127】なお、実施の形態1と同様、中継サーバ8
では上記添付画像ファイルを記憶する際、URLを生成
する。中継サーバ8内に添付画像ファイルを記憶する
と、本実施の形態1と同様に上記画像添付メールの本
文、および上記URLを用いて通知メールを作成し、受
信者に該通知メールを送信する。
では上記添付画像ファイルを記憶する際、URLを生成
する。中継サーバ8内に添付画像ファイルを記憶する
と、本実施の形態1と同様に上記画像添付メールの本
文、および上記URLを用いて通知メールを作成し、受
信者に該通知メールを送信する。
【0128】受信側iモード携帯電話2では、上記通知
メールを受信すると、実施の形態1と同様にメールを開
きURLを選択し添付画像ファイルを中継サーバ8より
ダウンロードする。
メールを受信すると、実施の形態1と同様にメールを開
きURLを選択し添付画像ファイルを中継サーバ8より
ダウンロードする。
【0129】以下、図4を用いて本実施の形態2の画像
添付メールの送受信方式、および中継サーバ8の詳細な
動作について説明する。なお、画像メールの作成手順に
関しては実施の形態1と同様であるので詳細な説明は省
略する。
添付メールの送受信方式、および中継サーバ8の詳細な
動作について説明する。なお、画像メールの作成手順に
関しては実施の形態1と同様であるので詳細な説明は省
略する。
【0130】また、本実施の形態2では、本実施の形態
1同様、受信側iモード携帯電話2が上記中継サーバ8
上に画像添付メールを受信するためのアドレスを有して
いるものとして説明を続ける。なお、通知メールの宛先
に関しても実施の形態1と同一であるので詳細な説明は
省略する。上記、複数に分割され送信された画像添付メ
ールはパケット通信網5等を介し中継サーバ8に入力さ
れる。以降の中継サーバ8の動作を図4を用いて説明す
る。
1同様、受信側iモード携帯電話2が上記中継サーバ8
上に画像添付メールを受信するためのアドレスを有して
いるものとして説明を続ける。なお、通知メールの宛先
に関しても実施の形態1と同一であるので詳細な説明は
省略する。上記、複数に分割され送信された画像添付メ
ールはパケット通信網5等を介し中継サーバ8に入力さ
れる。以降の中継サーバ8の動作を図4を用いて説明す
る。
【0131】中継サーバ8では、上記8通に分割され送
信された画像添付メールを受信すると、ステップ10に
おいて各電子メールのヘッダ部分に付加されている分割
情報を分離する。そして、ステップ11では該分割され
た8通の画像添付メールがすべて中継サーバ8に到着す
ると、中継サーバ8では該分離した分割情報もとにもと
の1通の画像添付メールを復元する。そして、ステップ
12にて各電子メールのヘッダ情報に付加されている添
付ファイル情報をもとに添付画像ファイルを分離する。
その際、実施の形態1と同様に分離した添付ファイルの
種別を確認する。
信された画像添付メールを受信すると、ステップ10に
おいて各電子メールのヘッダ部分に付加されている分割
情報を分離する。そして、ステップ11では該分割され
た8通の画像添付メールがすべて中継サーバ8に到着す
ると、中継サーバ8では該分離した分割情報もとにもと
の1通の画像添付メールを復元する。そして、ステップ
12にて各電子メールのヘッダ情報に付加されている添
付ファイル情報をもとに添付画像ファイルを分離する。
その際、実施の形態1と同様に分離した添付ファイルの
種別を確認する。
【0132】ステップ13では、上記分離した添付ファ
イル種別情報をもとに、添付ファイルが画像ファイルの
場合、BASE64デコードを行いもとのバイナリーデ
ータのファイルに変換する。中継サーバ8は該バイナリ
ーデータに変換されたJPEGファイルをデコードし画
像データを復元する。
イル種別情報をもとに、添付ファイルが画像ファイルの
場合、BASE64デコードを行いもとのバイナリーデ
ータのファイルに変換する。中継サーバ8は該バイナリ
ーデータに変換されたJPEGファイルをデコードし画
像データを復元する。
【0133】画像データ復元後、中継サーバ8は該画像
データをGIFファイル形式に再圧縮しする(ステップ
30)。ここで、バイナリーデータに変換されたJPE
GファイルとGIFファイル形式に圧縮された画像ファ
イルの両方の画像ファイルを上記中継サーバ8内の所定
の記憶領域(ディスク領域)に記録するとともに、記録
した画像データの記録アドレス(URL)を作成する
(ステップ14)。
データをGIFファイル形式に再圧縮しする(ステップ
30)。ここで、バイナリーデータに変換されたJPE
GファイルとGIFファイル形式に圧縮された画像ファ
イルの両方の画像ファイルを上記中継サーバ8内の所定
の記憶領域(ディスク領域)に記録するとともに、記録
した画像データの記録アドレス(URL)を作成する
(ステップ14)。
【0134】URLの作成を終了すると、ステップ15
において該画像添付メールの本文にURLを付加し、画
像添付メールが到着したことを伝える通知メールを送信
し、受信側iモード携帯電話2に該通知メールを送信し
画像添付メールが到着したことを伝える。
において該画像添付メールの本文にURLを付加し、画
像添付メールが到着したことを伝える通知メールを送信
し、受信側iモード携帯電話2に該通知メールを送信し
画像添付メールが到着したことを伝える。
【0135】次に、該通知メール受信後の動作を図3お
よび図5を用いて説明する。通知メールを受信すると受
信側iモード携帯電話2でメール着信を通知するため着
信音がなる(ステップ16)。なお、本実施の形態2で
は実施の形態1と同様にメール着信時に着信音を鳴らし
メール到着をユーザに通知する場合について説明する。
よび図5を用いて説明する。通知メールを受信すると受
信側iモード携帯電話2でメール着信を通知するため着
信音がなる(ステップ16)。なお、本実施の形態2で
は実施の形態1と同様にメール着信時に着信音を鳴らし
メール到着をユーザに通知する場合について説明する。
【0136】図5に画像ファイルをダウンロードする際
の受信側iモード携帯電話2と中継サーバ8間の動作フ
ローを示す。ユーザーは電子メールの着信音が鳴るとス
テップ17において着信メールを閲覧するために電子メ
ールブラウザーを起動し、着信した電子メールを選択し
内容を確認する。
の受信側iモード携帯電話2と中継サーバ8間の動作フ
ローを示す。ユーザーは電子メールの着信音が鳴るとス
テップ17において着信メールを閲覧するために電子メ
ールブラウザーを起動し、着信した電子メールを選択し
内容を確認する。
【0137】そして、ステップ18において受信メール
が通常の電子メールか、画像添付メールの通知メールか
判断する。通常の電子メールの場合は本文閲覧後、電子
メールブラウザーを終了する(ステップ19)。ステッ
プ20において画像データを閲覧しない場合は、通知メ
ールの本文閲覧後、ステップ19において電子メールブ
ラウザーを終了し、電子メールの閲覧を終了する。
が通常の電子メールか、画像添付メールの通知メールか
判断する。通常の電子メールの場合は本文閲覧後、電子
メールブラウザーを終了する(ステップ19)。ステッ
プ20において画像データを閲覧しない場合は、通知メ
ールの本文閲覧後、ステップ19において電子メールブ
ラウザーを終了し、電子メールの閲覧を終了する。
【0138】また、ステップ20において画像データを
閲覧する場合は、ステップ21においてユーザーは通知
メールに添付されているURLを選択する。受信側iモ
ード携帯電話2は、上記URLが選択されると実施の形
態1と同様にステップ22でインターネットブラウザー
を起動する。そして、該URL情報をもとに中継サーバ
8より画像ファイルをダウンロードするようコマンドを
中継サーバ8に送信する。
閲覧する場合は、ステップ21においてユーザーは通知
メールに添付されているURLを選択する。受信側iモ
ード携帯電話2は、上記URLが選択されると実施の形
態1と同様にステップ22でインターネットブラウザー
を起動する。そして、該URL情報をもとに中継サーバ
8より画像ファイルをダウンロードするようコマンドを
中継サーバ8に送信する。
【0139】以下、本実施の形態2の画像データのダウ
ンロードについて図5を用いて説明する。受信側iモー
ド携帯電話2より中継サーバ8に画像ファイルのダウン
ロード要求が送信される(ステップ31)と、中継サー
バ8では画像ファイル形式を選択するよう受信側iモー
ド携帯電話2にファイル選択要求を出力する(ステップ
32)。
ンロードについて図5を用いて説明する。受信側iモー
ド携帯電話2より中継サーバ8に画像ファイルのダウン
ロード要求が送信される(ステップ31)と、中継サー
バ8では画像ファイル形式を選択するよう受信側iモー
ド携帯電話2にファイル選択要求を出力する(ステップ
32)。
【0140】受信側iモード携帯電話2では画像ファイ
ル形式を選択し中継サーバ8に伝える。(ステップ3
3)中継サーバ8では、該ファイル形式選択結果に応じ
て中継サーバ8内に記録した該画像ファイルを送信する
(ステップ34)。受信側iモード携帯電話2では、中
継サーバ8よりダウンロードされてきた画像ファイルを
受信する(ステップ35)。
ル形式を選択し中継サーバ8に伝える。(ステップ3
3)中継サーバ8では、該ファイル形式選択結果に応じ
て中継サーバ8内に記録した該画像ファイルを送信する
(ステップ34)。受信側iモード携帯電話2では、中
継サーバ8よりダウンロードされてきた画像ファイルを
受信する(ステップ35)。
【0141】まずはじめに、上記受信側iモード携帯電
話2でJPEGファイルのデコードをサポートしている
場合について説明する。よって、ステップ32ではJP
EGファイルを選択しダウンロードする場合について説
明する。受信側iモード携帯電話2では、画像ファイル
のダウンロードが完了すると該インターネットブラウザ
ーはダウンロードした画像ファイルのデコード(JPE
Gファイルのデコード)を行う(ステップ24)。
話2でJPEGファイルのデコードをサポートしている
場合について説明する。よって、ステップ32ではJP
EGファイルを選択しダウンロードする場合について説
明する。受信側iモード携帯電話2では、画像ファイル
のダウンロードが完了すると該インターネットブラウザ
ーはダウンロードした画像ファイルのデコード(JPE
Gファイルのデコード)を行う(ステップ24)。
【0142】画像データ閲覧後、本実施の形態2では実
施の形態1と同様、上記ダウンロードしてきた画像ファ
イルを記録するか確認する。ステップ25にて画像ファ
イルを記録しない場合は、画像閲覧後インターネットブ
ラウザーを終了し、電子メールの閲覧画面に戻る(ステ
ップ27)。
施の形態1と同様、上記ダウンロードしてきた画像ファ
イルを記録するか確認する。ステップ25にて画像ファ
イルを記録しない場合は、画像閲覧後インターネットブ
ラウザーを終了し、電子メールの閲覧画面に戻る(ステ
ップ27)。
【0143】一方、画像ファイルを記憶する場合は、メ
モリの空きスペースを確認後、画像ファイルをメモリに
記録し(ステップ26)、インターネットブラウザーを
終了する(ステップ27)。その後、画像添付メールの
閲覧後、ステップ19にて電子メールブラウザーを終了
し、電子メールの閲覧を終了する。
モリの空きスペースを確認後、画像ファイルをメモリに
記録し(ステップ26)、インターネットブラウザーを
終了する(ステップ27)。その後、画像添付メールの
閲覧後、ステップ19にて電子メールブラウザーを終了
し、電子メールの閲覧を終了する。
【0144】次に、上記受信側iモード携帯電話2でJ
PEGファイルのデコードをサポートしていない場合に
ついて説明する。上述したが、iモード携帯電話のイン
ターネットブラウザーはGIFファイルのデコーダを標
準サポートしており、GIFファイル形式に圧縮された
画像をすべての機種で閲覧することができる。
PEGファイルのデコードをサポートしていない場合に
ついて説明する。上述したが、iモード携帯電話のイン
ターネットブラウザーはGIFファイルのデコーダを標
準サポートしており、GIFファイル形式に圧縮された
画像をすべての機種で閲覧することができる。
【0145】しかし、下位機種、あるいは他機種ではJ
PEGデコーダまで標準サポートしていない。その場
合、ステップ32ではGIFファイルを選択し画像ファ
イルをダウンロードする。受信側iモード携帯電話2で
は、上記GIFファイル形式の画像ファイルのダウンロ
ードが完了すると該インターネットブラウザーはダウン
ロードした画像ファイルのデコード(GIFファイルの
デコード)を行い、携帯電話の液晶上に画像データを表
示する(ステップ24)。
PEGデコーダまで標準サポートしていない。その場
合、ステップ32ではGIFファイルを選択し画像ファ
イルをダウンロードする。受信側iモード携帯電話2で
は、上記GIFファイル形式の画像ファイルのダウンロ
ードが完了すると該インターネットブラウザーはダウン
ロードした画像ファイルのデコード(GIFファイルの
デコード)を行い、携帯電話の液晶上に画像データを表
示する(ステップ24)。
【0146】本実施の形態2の中継サーバを利用した情
報通信方式、および情報通信装置は以上のように構成さ
れているので、8通に分割され送信された画像添付メー
ルも、実施の形態1と同様に、分割された電子メールの
統合機能のサポートされていない下位機種、あるいは画
像添付メールをサポートしていない他機種に送信した場
合でも画像ファイルの閲覧することができる効果があ
る。
報通信方式、および情報通信装置は以上のように構成さ
れているので、8通に分割され送信された画像添付メー
ルも、実施の形態1と同様に、分割された電子メールの
統合機能のサポートされていない下位機種、あるいは画
像添付メールをサポートしていない他機種に送信した場
合でも画像ファイルの閲覧することができる効果があ
る。
【0147】また、本実施の形態2では、実施の形態1
と同様に上述のように画像添付メールに関して下位機種
互換、あるいは他機種互換があるので画像ファイルの閲
覧ができないにもかかわらず課金されるといった問題点
も発生しなくなる効果がある。
と同様に上述のように画像添付メールに関して下位機種
互換、あるいは他機種互換があるので画像ファイルの閲
覧ができないにもかかわらず課金されるといった問題点
も発生しなくなる効果がある。
【0148】さらに、本実施の形態2では実施の形態1
と同様に、分割された各電子メール送信中に一部のメー
ルに着信遅延が生じても、サーバ側で分割されたすべて
の電子メールがそろうまで通知メールを送信しないので
画像添付メール1通の受信に非常に時間がかかる、ある
いは、同一電子メールの着信にもかかわらず着信音が2
度鳴るといった問題点が発生しなくなるという効果があ
る。
と同様に、分割された各電子メール送信中に一部のメー
ルに着信遅延が生じても、サーバ側で分割されたすべて
の電子メールがそろうまで通知メールを送信しないので
画像添付メール1通の受信に非常に時間がかかる、ある
いは、同一電子メールの着信にもかかわらず着信音が2
度鳴るといった問題点が発生しなくなるという効果があ
る。
【0149】また、本実施の形態2では、実施の形態1
と同様、上述のように送信された画像ファイルを受信者
の選択によりダウンロードの(受信、および閲覧)でき
るので、受信者が不必要と思われる画像ファイルをむや
みにダウンロードしなくてすみ、また、画像添付メール
受信時に必要以上の課金がなされない効果がある。ま
た、本実施の形態2では、実施の形態1と同様に、上記
画像データ以外のオーバーヘッドを最小限に押さえるこ
とができる効果がある。
と同様、上述のように送信された画像ファイルを受信者
の選択によりダウンロードの(受信、および閲覧)でき
るので、受信者が不必要と思われる画像ファイルをむや
みにダウンロードしなくてすみ、また、画像添付メール
受信時に必要以上の課金がなされない効果がある。ま
た、本実施の形態2では、実施の形態1と同様に、上記
画像データ以外のオーバーヘッドを最小限に押さえるこ
とができる効果がある。
【0150】さらに、本実施の形態2では、画像データ
をJPEG圧縮し中継サーバ8にアップロードする。該
アップロードされた画像データをJPEG伸長し画像デ
ータを復元する。そして、該復元した画像データをGI
Fファイル形式に圧縮し、受信したJPEGファイル形
式の画像とGIFファイル形式の画像を記憶し、アクセ
スした携帯電話の種別によってファイル形式を選択しダ
ウンロードできるように構成するので、JPEGデコー
ダを機能を有しない携帯電話からでもGIFファイル形
式で添付された画像ファイルをダウンロードできるの
で、下位機種互換、あるいは他機種互換を図ることがで
きる効果がある。
をJPEG圧縮し中継サーバ8にアップロードする。該
アップロードされた画像データをJPEG伸長し画像デ
ータを復元する。そして、該復元した画像データをGI
Fファイル形式に圧縮し、受信したJPEGファイル形
式の画像とGIFファイル形式の画像を記憶し、アクセ
スした携帯電話の種別によってファイル形式を選択しダ
ウンロードできるように構成するので、JPEGデコー
ダを機能を有しない携帯電話からでもGIFファイル形
式で添付された画像ファイルをダウンロードできるの
で、下位機種互換、あるいは他機種互換を図ることがで
きる効果がある。
【0151】また、JPEGデコード機能を有する携帯
電話へはJPEGファイル形式にてダウンロードするの
で、GIFファイル変換時の発生する画質の劣化がなく
画像データをダウンロードすることができるとともに、
GIFファイル形式に再圧縮する際、画像データ量が増
えるが、(シミュレーションの結果、圧縮する際の色数
にもよるが2倍程度のデータ量になる。)その影響を受
けること無く画像データをダウンロードすることができ
る。
電話へはJPEGファイル形式にてダウンロードするの
で、GIFファイル変換時の発生する画質の劣化がなく
画像データをダウンロードすることができるとともに、
GIFファイル形式に再圧縮する際、画像データ量が増
えるが、(シミュレーションの結果、圧縮する際の色数
にもよるが2倍程度のデータ量になる。)その影響を受
けること無く画像データをダウンロードすることができ
る。
【0152】なお、本実施の形態2では、画像圧縮方式
としてJPEGを用い、また、JPEGデコード後再圧
縮する際の圧縮方式にGIFを採用したがこれに限るも
のではなく、例えば、ビットマップ形式、あるいはPN
Gファイル形式に変換した画像を記憶しても、携帯電話
が上記圧縮方式のデコードをサポートしていれば同様の
効果を奏する。
としてJPEGを用い、また、JPEGデコード後再圧
縮する際の圧縮方式にGIFを採用したがこれに限るも
のではなく、例えば、ビットマップ形式、あるいはPN
Gファイル形式に変換した画像を記憶しても、携帯電話
が上記圧縮方式のデコードをサポートしていれば同様の
効果を奏する。
【0153】また、本実施の形態2では、JPEGファ
イル、およびGIFファイルの2種類のファイルを中継
サーバ8上に記録する場合について説明したがこれに限
るものではなく、例えば上述した、JPEG,GIF,
PNG(PortableNetwork Graph
ics。ピング)、およびBMP(Bit Map。ビ
ットマップ)の4種類のファイルをサポートするように
構成しても同様の効果がある。
イル、およびGIFファイルの2種類のファイルを中継
サーバ8上に記録する場合について説明したがこれに限
るものではなく、例えば上述した、JPEG,GIF,
PNG(PortableNetwork Graph
ics。ピング)、およびBMP(Bit Map。ビ
ットマップ)の4種類のファイルをサポートするように
構成しても同様の効果がある。
【0154】さらに、同一のGIFファイル形式であっ
ても表示色数を変え複数のファイル形式を準備しても同
様の効果があることは言うまでもない。例えば、携帯電
話本体でインターネット上からダウンロードできるファ
イルサイズの最大値が決まっている場合があり、その
際、ダウンロードできるファイルサイズを選択すること
ができ、送られてきた画像ファイルをダウンロードでき
るファイルサイズが小さい携帯電話でも画像ファイルを
ダウンロードし閲覧することができる効果がある。
ても表示色数を変え複数のファイル形式を準備しても同
様の効果があることは言うまでもない。例えば、携帯電
話本体でインターネット上からダウンロードできるファ
イルサイズの最大値が決まっている場合があり、その
際、ダウンロードできるファイルサイズを選択すること
ができ、送られてきた画像ファイルをダウンロードでき
るファイルサイズが小さい携帯電話でも画像ファイルを
ダウンロードし閲覧することができる効果がある。
【0155】さらに、例えば白黒2階調の携帯電話を有
している場合は、カラー画像をダウンロードしてもカラ
ー画像を見ることができない。従って、例えば2値に圧
縮したGIFファイルをダウンロードすればデータ量が
少なくてすみ、ダウンロードの際のコストを削減するこ
とができる効果がある。
している場合は、カラー画像をダウンロードしてもカラ
ー画像を見ることができない。従って、例えば2値に圧
縮したGIFファイルをダウンロードすればデータ量が
少なくてすみ、ダウンロードの際のコストを削減するこ
とができる効果がある。
【0156】なお、上記実施の形態1および2では、画
像添付メールをiモードメール8通に分割し伝送した場
合について説明したがこれに限るものではなく、たとえ
ば、添付画像の画素数が多い場合、あるいはさらに画質
のよいデータを送信したい場合などは、10通、15通
に分割し送信しても、中継サーバ8にて分割された画像
添付メールの統合などを行えば同様の効果を奏する。
像添付メールをiモードメール8通に分割し伝送した場
合について説明したがこれに限るものではなく、たとえ
ば、添付画像の画素数が多い場合、あるいはさらに画質
のよいデータを送信したい場合などは、10通、15通
に分割し送信しても、中継サーバ8にて分割された画像
添付メールの統合などを行えば同様の効果を奏する。
【0157】また、通知メールの転送先アドレスに関し
ては、例えばメール本文のあらかじめ定められた場所に
記述するように構成し、該中継サーバ8で該転送先を画
像添付メール本体より分離し送信しても同様の効果を奏
することは言うまでもない。また、格納位置に関して
も、該分割され送信された各分割メールのヘッダ部分に
記憶しても良いことは言うまでもない。
ては、例えばメール本文のあらかじめ定められた場所に
記述するように構成し、該中継サーバ8で該転送先を画
像添付メール本体より分離し送信しても同様の効果を奏
することは言うまでもない。また、格納位置に関して
も、該分割され送信された各分割メールのヘッダ部分に
記憶しても良いことは言うまでもない。
【0158】また、本実施の形態1および2では、バイ
ナリデータを疑似ASCIIデータに変換する際、BA
SE64を用いたが変換方式はこれに限るものではな
く、例えば、UNIXマシーンで使用されているような
UUエンコードなどの手法を用いても同様の効果を奏す
る。
ナリデータを疑似ASCIIデータに変換する際、BA
SE64を用いたが変換方式はこれに限るものではな
く、例えば、UNIXマシーンで使用されているような
UUエンコードなどの手法を用いても同様の効果を奏す
る。
【0159】また、上記実施の形態1および2では、通
知メールとして画像添付メールの本文とURLを送信し
たがこれに限るものではなく、例えば、本文の一部とU
RL、あるいはURLのみを通知メールとして送信して
も同様の効果がある。その際、本文の一部、あるいはU
RLのみ送信する場合は、携帯電話からのダウンロード
要求時には少なくとも送信しなかったメールの本文をダ
ウンロードできる構成とすれば同様の効果があることは
言うまでもない。
知メールとして画像添付メールの本文とURLを送信し
たがこれに限るものではなく、例えば、本文の一部とU
RL、あるいはURLのみを通知メールとして送信して
も同様の効果がある。その際、本文の一部、あるいはU
RLのみ送信する場合は、携帯電話からのダウンロード
要求時には少なくとも送信しなかったメールの本文をダ
ウンロードできる構成とすれば同様の効果があることは
言うまでもない。
【0160】また、本実施の形態1および2では、ドコ
モのiモード携帯電話を用いた場合について説明したが
これに限るものではなくツーカーグループの行っている
スカイメッセージサービス、あるいはWAP(Wire
less Access Protocol)(日本移
動通信株式会社IDO、あるいは第二電電株式会社DD
Iなどにおいて採用)を用いた電子メールの送受信シス
テムにおいても上述のように中継サーバを用い分割され
送信されたメールの統合、所定のファイル変換、所定の
ファイル形式への画像の変換等を行うよう構成すれば同
様の効果があることは言うまでもない。
モのiモード携帯電話を用いた場合について説明したが
これに限るものではなくツーカーグループの行っている
スカイメッセージサービス、あるいはWAP(Wire
less Access Protocol)(日本移
動通信株式会社IDO、あるいは第二電電株式会社DD
Iなどにおいて採用)を用いた電子メールの送受信シス
テムにおいても上述のように中継サーバを用い分割され
送信されたメールの統合、所定のファイル変換、所定の
ファイル形式への画像の変換等を行うよう構成すれば同
様の効果があることは言うまでもない。
【0161】また、画像ファイルの圧縮方式として実施
の形態1および2ではGIF、およびJPEGを例に説
明したがこれに限るものではなくPNG、あるいはBM
P形式の画像ファイルでも同様の効果を有することはい
うまでもない。
の形態1および2ではGIF、およびJPEGを例に説
明したがこれに限るものではなくPNG、あるいはBM
P形式の画像ファイルでも同様の効果を有することはい
うまでもない。
【0162】また、画像サイズに関しても96画素×7
2ラインに限るものではない。また、実施の形態1およ
び2では、メール着信時に着信音を鳴らしメール到着を
ユーザに通知したがマナーモードなどのバイブレーショ
ン機能を用いた携帯電話への通知の場合でも同様の効果
を奏することはいうまでもない。
2ラインに限るものではない。また、実施の形態1およ
び2では、メール着信時に着信音を鳴らしメール到着を
ユーザに通知したがマナーモードなどのバイブレーショ
ン機能を用いた携帯電話への通知の場合でも同様の効果
を奏することはいうまでもない。
【0163】さらに、本実施の形態1および2では、電
子メールに静止画像を添付する場合について述べたがこ
れに限るものではなく、MPEG(Moving Pi
cture Experts Gruop)などをベー
スに圧縮された動画像、および音声を添付した電子メー
ルを送受信する場合も中継サーバ8側で上述のような機
能を持たせれば同様の効果を奏することはいうまでもな
い。
子メールに静止画像を添付する場合について述べたがこ
れに限るものではなく、MPEG(Moving Pi
cture Experts Gruop)などをベー
スに圧縮された動画像、および音声を添付した電子メー
ルを送受信する場合も中継サーバ8側で上述のような機
能を持たせれば同様の効果を奏することはいうまでもな
い。
【0164】また、上記実施の形態1および2では、電
子メールに画像ファイルを添付する場合について述べた
がワープロ文章の添付、音声ファイルの添付、あるいは
着信メロディなどの音楽ファイルの添付に関しても同様
に中継サーバ8側で上述のような機能をもたせれば同様
の効果を奏することは言うまでもない。
子メールに画像ファイルを添付する場合について述べた
がワープロ文章の添付、音声ファイルの添付、あるいは
着信メロディなどの音楽ファイルの添付に関しても同様
に中継サーバ8側で上述のような機能をもたせれば同様
の効果を奏することは言うまでもない。
【0165】なお、以上の各実施の形態において、音声
の通信網の一例としてドコモ通信網のような音声通信
網、データ通信網の一例としてDopaのようなパケッ
ト通信網を例に説明したが、必ずしもこれらにのみ限定
される訳ではなく、他の音声通信網、パケット通信網で
あっても同様に適用することができる。
の通信網の一例としてドコモ通信網のような音声通信
網、データ通信網の一例としてDopaのようなパケッ
ト通信網を例に説明したが、必ずしもこれらにのみ限定
される訳ではなく、他の音声通信網、パケット通信網で
あっても同様に適用することができる。
【0166】
【発明の効果】この発明は、以上説明したように構成さ
れているので、以下に示すような効果を奏する。
れているので、以下に示すような効果を奏する。
【0167】本発明に係る情報通信方法は、送信情報を
所定形式のコード列に変換して得られた変換コードの一
部および受信者宛先より構成された複数の受信情報を受
信する受信段階と、該受信段階において受信される前記
複数の受信情報を統合して前記送信情報に対応する前記
変換コードの全部を復元する復元段階と、該復元段階に
おいて復元される前記変換コードの全部に基づいて前記
送信情報または前記送信情報と実質的に等価な情報を生
成して、指定される記憶先に記憶する記憶段階と、前記
受信者宛先に前記記憶段階において指定された前記記憶
先を送信する送信段階とを含むので、添付情報を機種に
よらずに閲覧することができ、閲覧できないにも関わら
ず課金される、あるいは受信者の意図しない受信を防止
することができるので受信に大きな時間がかかってしま
うという問題点を解消することができる。
所定形式のコード列に変換して得られた変換コードの一
部および受信者宛先より構成された複数の受信情報を受
信する受信段階と、該受信段階において受信される前記
複数の受信情報を統合して前記送信情報に対応する前記
変換コードの全部を復元する復元段階と、該復元段階に
おいて復元される前記変換コードの全部に基づいて前記
送信情報または前記送信情報と実質的に等価な情報を生
成して、指定される記憶先に記憶する記憶段階と、前記
受信者宛先に前記記憶段階において指定された前記記憶
先を送信する送信段階とを含むので、添付情報を機種に
よらずに閲覧することができ、閲覧できないにも関わら
ず課金される、あるいは受信者の意図しない受信を防止
することができるので受信に大きな時間がかかってしま
うという問題点を解消することができる。
【0168】また、送信情報に所定の変換処理を施して
当該送信情報と実質的に同等の情報を得る変換処理段階
を含むので、添付情報を機種によらずに閲覧することが
可能となる。
当該送信情報と実質的に同等の情報を得る変換処理段階
を含むので、添付情報を機種によらずに閲覧することが
可能となる。
【0169】また、変換処理は、疑似ASCII化され
た送信情報をバイナリー情報に変換するので、そのよう
な機能を有しない場合においても添付情報を機種によら
ずに閲覧することが可能となる。
た送信情報をバイナリー情報に変換するので、そのよう
な機能を有しない場合においても添付情報を機種によら
ずに閲覧することが可能となる。
【0170】また、送信情報と共に当該送信情報と実質
的に同等の情報を指定される記憶先に記憶するので、受
信者側の機能に応じて添付情報を閲覧することができ
る。
的に同等の情報を指定される記憶先に記憶するので、受
信者側の機能に応じて添付情報を閲覧することができ
る。
【0171】本発明に係る情報通信装置は、送信情報を
所定形式のコード列に変換して得られた変換コードの一
部および受信者宛先より構成された複数の受信情報を受
信し、該受信した複数の受信情報を統合して前記送信情
報に対応する前記変換コードの全部を復元する復元手段
と、該復元手段において復元される前記変換コードの全
部に基づいて前記送信情報または前記送信情報と実質的
に等価な情報を生成して、指定される記憶先に記憶する
記憶手段と、前記受信者宛先に前記記憶手段において指
定された前記記憶先を送信する送信手段とを有するの
で、添付情報を機種によらずに閲覧することができ、閲
覧できないにも関わらず課金される、あるいは受信者の
意図しない受信を防止することができるので受信に大き
な時間がかかってしまうという問題点を解消することが
できる。
所定形式のコード列に変換して得られた変換コードの一
部および受信者宛先より構成された複数の受信情報を受
信し、該受信した複数の受信情報を統合して前記送信情
報に対応する前記変換コードの全部を復元する復元手段
と、該復元手段において復元される前記変換コードの全
部に基づいて前記送信情報または前記送信情報と実質的
に等価な情報を生成して、指定される記憶先に記憶する
記憶手段と、前記受信者宛先に前記記憶手段において指
定された前記記憶先を送信する送信手段とを有するの
で、添付情報を機種によらずに閲覧することができ、閲
覧できないにも関わらず課金される、あるいは受信者の
意図しない受信を防止することができるので受信に大き
な時間がかかってしまうという問題点を解消することが
できる。
【0172】また、送信情報に所定の変換処理を施して
当該送信情報と実質的に同等の情報を得る変換処理手段
を備えるので、添付情報を機種によらずに閲覧すること
が可能となる。
当該送信情報と実質的に同等の情報を得る変換処理手段
を備えるので、添付情報を機種によらずに閲覧すること
が可能となる。
【0173】また、変換処理手段における変換処理は、
疑似ASCII化された送信情報をバイナリー情報に変
換するものであるので、そのような機能を有しない場合
においても添付情報を機種によらずに閲覧することが可
能となる。
疑似ASCII化された送信情報をバイナリー情報に変
換するものであるので、そのような機能を有しない場合
においても添付情報を機種によらずに閲覧することが可
能となる。
【0174】また、記憶手段は、送信情報と共に当該送
信情報と実質的に同等の情報を記憶するように構成され
るので、受信者側の機能に応じて添付情報を閲覧するこ
とができる。
信情報と実質的に同等の情報を記憶するように構成され
るので、受信者側の機能に応じて添付情報を閲覧するこ
とができる。
【図1】 実施の形態1に説明する情報通信システムの
構成図である。
構成図である。
【図2】 実施の形態1に説明する情報通信方法によ
る、中継サーバでの画像添付メールの処理アルゴリズム
である。
る、中継サーバでの画像添付メールの処理アルゴリズム
である。
【図3】 実施の形態1に説明する情報通信方法によ
る、携帯電話で通知メールを受信した際の処理アルゴリ
ズムである。
る、携帯電話で通知メールを受信した際の処理アルゴリ
ズムである。
【図4】 実施の形態2に説明する情報通信方法によ
る、中継サーバでの画像添付メールの処理アルゴリズム
である。
る、中継サーバでの画像添付メールの処理アルゴリズム
である。
【図5】 実施の形態2に説明する情報通信方法によ
る、画像ファイルをダウンロードする際の携帯電話と中
継サーバ間の動作フローを示す図である。
る、画像ファイルをダウンロードする際の携帯電話と中
継サーバ間の動作フローを示す図である。
【図6】 従来の携帯電話の電子メール送受信のための
システム構成図である。
システム構成図である。
【図7】 従来の画像添付メールを送信する際の携帯電
話本体の処理アルゴリズムである。
話本体の処理アルゴリズムである。
【図8】 従来の画像添付メールを受信する際の携帯電
話本体の処理アルゴリズムである。
話本体の処理アルゴリズムである。
1 発信側iモード携帯電話、2 受信側iモード携帯
電話、3 中継局、5パケット通信網、6 ゲートウェ
イサーバ、7 インターネット、8 中継サーバ。
電話、3 中継局、5パケット通信網、6 ゲートウェ
イサーバ、7 インターネット、8 中継サーバ。
───────────────────────────────────────────────────── フロントページの続き Fターム(参考) 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】 送信情報に所定の変換処理を施して当該
送信情報と実質的に同等の情報を得る変換処理段階を含
む請求項1に記載の情報通信方法。 - 【請求項3】 変換処理は、疑似ASCII化された送
信情報をバイナリー情報に変換するものである請求項2
に記載の情報通信方法。 - 【請求項4】 送信情報と共に当該送信情報と実質的に
同等の情報を指定される記憶先に記憶する請求項1に記
載の情報通信方法。 - 【請求項5】 送信情報を所定形式のコード列に変換し
て得られた変換コードの一部および受信者宛先より構成
された複数の受信情報を受信し、該受信した複数の受信
情報を統合して前記送信情報に対応する前記変換コード
の全部を復元する復元手段と、 該復元手段において復元される前記変換コードの全部に
基づいて前記送信情報または前記送信情報と実質的に等
価な情報を生成して、指定される記憶先に記憶する記憶
手段と、 前記受信者宛先に前記記憶手段において指定された前記
記憶先を送信する送信手段とを有する情報通信装置。 - 【請求項6】 送信情報に所定の変換処理を施して当該
送信情報と実質的に同等の情報を得る変換処理手段を備
える請求項5に記載の情報通信装置。 - 【請求項7】 変換処理手段における変換処理は、疑似
ASCII化された送信情報をバイナリー情報に変換す
るものである請求項6に記載の情報通信装置。 - 【請求項8】 記憶手段は、送信情報と共に当該送信情
報と実質的に同等の情報を記憶するように構成される請
求項5に記載の情報通信装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000021391A JP2001217876A (ja) | 2000-01-31 | 2000-01-31 | 情報通信方法および情報通信装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000021391A JP2001217876A (ja) | 2000-01-31 | 2000-01-31 | 情報通信方法および情報通信装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2001217876A true JP2001217876A (ja) | 2001-08-10 |
Family
ID=18547805
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000021391A Pending JP2001217876A (ja) | 2000-01-31 | 2000-01-31 | 情報通信方法および情報通信装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2001217876A (ja) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003091485A (ja) * | 2001-09-17 | 2003-03-28 | Denso Corp | メールの送信端末 |
WO2003042818A1 (fr) * | 2001-11-12 | 2003-05-22 | Fujitsu Limited | Appareil terminal, serveur, procede de traitement d'informations execute par ordinateur, programme et support |
JP2006048168A (ja) * | 2004-07-30 | 2006-02-16 | Canon Inc | 通信装置、情報処理方法、ならびにプログラム、記憶媒体 |
US7031008B2 (en) | 2001-12-26 | 2006-04-18 | Kabushiki Kaisha Toshiba | Image forming apparatus and method of controlling the apparatus |
JP2007004496A (ja) * | 2005-06-23 | 2007-01-11 | Trusted Solutions Kk | メール送付システムおよびメール送付方法 |
JP2007260262A (ja) * | 2006-03-29 | 2007-10-11 | Koshida Tec:Kk | 遊技機安全運送システムおよびその方法 |
US7535477B2 (en) | 2003-12-12 | 2009-05-19 | Sharp Kabushiki Kaisha | Data converter, data conversion method, program for making computer function as data converter and recording medium for storing this program |
-
2000
- 2000-01-31 JP JP2000021391A patent/JP2001217876A/ja active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003091485A (ja) * | 2001-09-17 | 2003-03-28 | Denso Corp | メールの送信端末 |
WO2003042818A1 (fr) * | 2001-11-12 | 2003-05-22 | Fujitsu Limited | Appareil terminal, serveur, procede de traitement d'informations execute par ordinateur, programme et support |
US7031008B2 (en) | 2001-12-26 | 2006-04-18 | Kabushiki Kaisha Toshiba | Image forming apparatus and method of controlling the apparatus |
US7535477B2 (en) | 2003-12-12 | 2009-05-19 | Sharp Kabushiki Kaisha | Data converter, data conversion method, program for making computer function as data converter and recording medium for storing this program |
JP2006048168A (ja) * | 2004-07-30 | 2006-02-16 | Canon Inc | 通信装置、情報処理方法、ならびにプログラム、記憶媒体 |
US8612521B2 (en) | 2004-07-30 | 2013-12-17 | Canon Kabushiki Kaisha | Communication apparatus, information processing method, program, and storage medium |
US10305836B2 (en) | 2004-07-30 | 2019-05-28 | Canon Kabushiki Kaisha | Communication apparatus, information processing method, program, and storage medium |
JP2007004496A (ja) * | 2005-06-23 | 2007-01-11 | Trusted Solutions Kk | メール送付システムおよびメール送付方法 |
JP2007260262A (ja) * | 2006-03-29 | 2007-10-11 | Koshida Tec:Kk | 遊技機安全運送システムおよびその方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2001217860A (ja) | 情報受信方法、情報通信方法、情報通信装置および情報通信端末 | |
US6795711B1 (en) | Multimedia message content adaptation | |
JP4255140B2 (ja) | 情報の無線検索方法 | |
US20050149618A1 (en) | System and method of transmitting electronic files over to a mobile phone | |
CN100505758C (zh) | 移动邮件终端适配方法和系统 | |
CN102318295A (zh) | 用于处理消息的设备和方法 | |
JP2001045047A (ja) | 簡易応答システム | |
CN101568193A (zh) | 一种即时通信终端主叫信息的显示方法及系统 | |
JP2002041404A (ja) | 情報提供システム及び装置とその方法 | |
JP2006514513A (ja) | マルチメディアメッセージングサービス方法 | |
CN101232629A (zh) | 利用手机直接接收传真的方法 | |
JP2001217876A (ja) | 情報通信方法および情報通信装置 | |
CN100384279C (zh) | 一种短信发送方法、和应用该方法的手机及系统 | |
KR20030061155A (ko) | 인터넷 메일장치의 선택된 전자메일 수신방법 | |
WO2009146442A1 (en) | Systems, methods and software applications for mobile device menu modification | |
JP2001265674A (ja) | 電子メール転送装置及び電子メール転送システム | |
JP2001216214A (ja) | 情報送信方法、情報通信方法、情報通信装置および情報通信端末 | |
JP3674666B2 (ja) | 電子メール装置及びその制御方法 | |
CN100525520C (zh) | 为一号通用户提供消息的实现方法 | |
KR100595657B1 (ko) | Mms메시지 전송방법 | |
JP2003018660A (ja) | 携帯電話メッセージ処理システム、方法及びこれに用いる装置 | |
JP4880387B2 (ja) | 通信装置、管理装置、及び、プログラム | |
JP4416624B2 (ja) | 移動体通信端末 | |
JP2005012627A (ja) | 携帯通信端末、移動体通信システム及びメール通信制御方法 | |
JP2004080818A (ja) | デジタル無線電話によるメッセージ通信システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20040630 |