JP2004046411A - 通信システム、データ処理装置およびその制御方法 - Google Patents
通信システム、データ処理装置およびその制御方法 Download PDFInfo
- Publication number
- JP2004046411A JP2004046411A JP2002201146A JP2002201146A JP2004046411A JP 2004046411 A JP2004046411 A JP 2004046411A JP 2002201146 A JP2002201146 A JP 2002201146A JP 2002201146 A JP2002201146 A JP 2002201146A JP 2004046411 A JP2004046411 A JP 2004046411A
- Authority
- JP
- Japan
- Prior art keywords
- data
- communication terminal
- decoding
- decoded
- communication
- 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.)
- Withdrawn
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】通信端末自身がデコードできないデータを受信した場合でも、別の装置の支援を受けてそのデータをデコードし、通信端末においてメッセージの内容を確認することのできる通信システム、通信端末およびその制御方法を提供すること。
【解決手段】データ処理装置は、通信端末からの指示に応じて、その通信端末でデコードできない属性のデータを取得し、通信端末に代わってデコードを行う。データ処理装置はデコード後のデータに対して所定の処理を行う（Ｃ−６）他、デコード後のデータを通信端末に転送する（Ｃ−８）。
【選択図】 図６
【解決手段】データ処理装置は、通信端末からの指示に応じて、その通信端末でデコードできない属性のデータを取得し、通信端末に代わってデコードを行う。データ処理装置はデコード後のデータに対して所定の処理を行う（Ｃ−６）他、デコード後のデータを通信端末に転送する（Ｃ−８）。
【選択図】 図６
Description
【０００１】
【発明の属する技術分野】
本発明は、通信システム、通信端末およびその制御方法に関するものである。
【０００２】
【従来の技術】
無線携帯端末等の通信端末は、ネットワークを経由してサーバから各種データを取得することが可能である。最近では、電子メール機能により電子メールデータを自動受信することができるようになっている。電子メールは各種アプリケーションで作成されたファイルを添付ファイルとして送信することも可能になっている。
【０００３】
【発明が解決しようとする課題】
ところが、添付ファイルとして送られてきたもののすべてが無線携帯端末でデコード可能であるとは限らない。デコードできないデータを端末が記憶していることは無駄であるから、そのようなデータを自動的に破棄させることも考えられるが、他の装置の補助を受けてでもデコードできないメッセージの内容を見たいというニーズもある。
【０００４】
そこで、本発明は、通信端末自身がデコードできないデータを受信した場合でも、別の装置の支援を受けてそのデータをデコードし、通信端末においてメッセージの内容を確認することのできる通信システム、通信端末およびその制御方法を提供することを目的としている。
【０００５】
【課題を解決するための手段】
本発明の一側面は、ネットワークを介してデータを送受可能な通信端末と、その通信端末と接続可能なデータ処理装置とを含む通信システムに係る。この通信システムにおいて、前記通信端末は、受信したデータに当該通信端末でデコードできない属性のファイルが含まれているか否かを判断し、前記受信したデータに当該通信端末でデコードできない属性のファイルが含まれているときは、そのファイルを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのファイルをデコードするよう指示する。そして、前記データ処理装置は、前記指示手段の指示に応じて、前記ファイルを取得し、取得した前記ファイルをデコードし、デコード後のデータを前記通信端末に送信する。
【０００６】
本発明の別の側面は、ネットワークを介してメッセージを送受可能な通信端末に接続されたデータ処理装置およびその制御方法に係る。このデータ処理装置は、前記通信端末が受信したメッセージに当該通信端末でデコードできない属性のデータが含まれていること示す指示信号を検出し、前記指示信号を検出したときに前記データを取得し、取得した前記データをデコードし、デコードしたデータを前記通信端末に送信する。かかる制御方法はプログラムによっても実現されうる。
【０００７】
【発明の実施の形態】
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。
【０００８】
図１は、実施形態におけるデータ処理装置としてのマルチファンクション端末装置の構成を示すブロック図である。このマルチファンクション端末装置は、後述するように通信端末としての無線携帯端末と接続し、無線携帯端末からのデータを表示、印刷、記憶等することができるように構成されている。
【０００９】
マルチファンクション端末装置１０は、図示のように、ＣＰＵ１−１、ＲＯＭ１−２、ＲＡＭ１−３、不揮発性ＲＡＭ１−４、操作部１−５、表示部１−６、符号・復号部１−７、読取り部１−８、記録部１−９、駆動部１−１０、ＭＯＤＥＭ部１−１１、プリンタ部１−１２、Ａ／Ｄ変換部１−１３、スピーカ部１−１４、Ｉ／Ｆ部１−１５を有する。
【００１０】
ＣＰＵ１−１は、ＲＯＭ１−２に記憶されているプログラムに従って装置全体の制御を行う。プログラムを格納するＲＯＭ部１−２は、フラッシュメモリのような書き換え可能なメモリでも構わない。ＲＡＭ１−３は、無線携帯端末からＩ／Ｆ部１−１５経由で受け取ったデータや、符号・復号部１−７、Ａ／Ｄ部１−１３、記録部１−９、読取り部１−８、プリンタ部１−１２で処理するデータの格納を行うのに用いる。
【００１１】
不揮発性ＲＡＭ１−４は、無線携帯端末の認証に関する各種情報や、端末固有の情報をはじめ、各種デコード処理に必要なプログラムの全部または一部、ダウンロードされた最新のアプリケーションソフト等を格納するのに用いられる。
【００１２】
操作部１−５は、無線携帯端末からのデータをメニュー表示させる「メニューボタン」、メニューからどのデータを処理させるかを決める「選択操作」、選択したデータをどのように処理するかを決める「選択操作」などを有する。表示部１−６と一体化させタッチパネルなどを使うようにしても構わない。
【００１３】
表示部１−６は、各種操作を補助するためのメニュー表示、受信データのうち表示選択されたデータの表示等に使用される。
【００１４】
符号・復号部１−７は、受信したデータのタイプによって決定される符号・復号プログラムにより演算処理する。高速演算が必要なため符号・復号部内部に専用のＲＯＭ、ＲＡＭ、演算回路を有する構成が好ましい。また、演算回路（例えばＤＳＰ）でのデコードに必要なプログラムを、ネットワーク経由で更新できるようにしてもよい。なお、ＣＰＵの充分に処理能力が高い場合は、この符号・復号部１−７の機能をＣＰＵ１−１に担わせるようにしても構わない。
【００１５】
読取り部１−８は原稿をスキャンする光学系部品で構成され、原稿の内容を電子データとして変換する。ここでスキャンされたアナログ信号をＡ／Ｄ変換し、以後の処理に必要なデータ形式に符号・複号部１−７で変換する。
【００１６】
記録部１−９は、ハードディスク、半導体メモリまたはテープなどで構成され、無線携帯端末経由で受信したデータを保存するために用いられる。ＲＡＭ部１−３との容量・価格・アクセスタイムのバランスを考慮した記録媒体を用いることが望ましい。
【００１７】
駆動部１−１０は読み取り部１−８、プリンタ部１−１２の各種モータを駆動する。
【００１８】
モデム部１−１１は、無線携帯端末経由でアナログ変調された変調波を送受信する（いわゆる見なし音声通信）場合の変調／復調を行う。
【００１９】
プリンタ部１−１２は、受信したデータ、読取ったデータをプリントアウトするのに用い、ＬＢＰ、インクジェット、熱転などいずれの方式を用いてもよい。
【００２０】
Ａ／Ｄ変換部１−１３は受信した音データをアナログ信号に変換や、各種操作音を生成するために用いる。モデム部１−１１のＡ／Ｄ変換回路と共有するようにしても良い。
【００２１】
スピーカ部１−１４はＡ／Ｄ変換部１−１３で変換されたアナログ信号をスピーカにより可聴音として再生する。
【００２２】
Ｉ／Ｆ部１−１５は、無線携帯端末との通信および充電を行うインターフェイス部分であり、複数の無線携帯端末を接続できるようにしても構わない。インターフェイスの通信仕様は有線でも無線でも構わないが、本実施形態ではシリアル通信でデータ送受を行う。
【００２３】
また、ＲＯＭ１−２には、例えば、このマルチファンクション端末装置１０でデコード可能な画像データの形式（ＧＩＦ、ＪＰＥＧ、ＢＭＰなど）を記述したサポートフォーマット一覧テーブルが記憶されている。
【００２４】
次に、電子メールに添付された画像データを、マルチファンクション端末装置で出力・再生する際の動作について説明する。
【００２５】
図２は、実施形態に係る上記マルチファンクション端末装置１０を含む通信システムを示す図である。
【００２６】
同図において、２−２がマルチファンクション端末装置１０と接続可能な無線携帯端末であり、２−３は、画像入力装置（例えばデジタルカメラ）２−４と接続可能な別の無線携帯端末である。２−５および２−１１は無線携帯端末と無線通信を行う基地局、２−６、２−１０はＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワーク制御装置）であり、図示の如く、この基地局２−１１とＲＮＣ２−１０、基地局２−５とＲＮＣ２−６でそれぞれＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：無線アクセス網）２−９ａ、２−９ｂを構成する。
【００２７】
また、ＣＮ（ｃｏｒｅ ｎｅｔｗｏｒｋ：コアネットワーク）２−７にはＲＡＮ２−９ａ、２−９ｂをはじめ、次に掲げるノードが接続されている。
【００２８】
加入者の情報や認証を行うマネージメントサーバ２−８、
ＣＮ２−７のメールを管理するメールサーバ２−１５、
各種ドライバプログラムを格納したドライバサーバおよびパケット処理のアドレス解決（ＤＮＳ）サーバとして機能するサービスデータベース２−２０、そして、
ＩＰ網２−１６、ＰＤＣ網２−２１、ＰＨＳ網２−２２、ＰＳＴＮ網２−２３、ＩＳＤＮ網２−２４といった各種通信ネットワーク。
【００２９】
デジタルカメラ２−１２を接続可能なパーソナルコンピュータ（ＰＣ）２−１３は、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）２−１４を経由してＩＰ網２−１６に接続される。ＩＰ網２−１６にはこの他、各種サービスのコンテンツを格納したコンテンツサーバ２−１７、各種アプリケーションの最新ドライバを格納したドライバサーバ２−１８、そしてＷＷＷサーバ２−１９が接続されている。
【００３０】
図８は、無線携帯端末２−２のハードウェア構成を示すブロック図である。２０１は端末全体の動作を制御するＣＰＵ、２０２はデータおよびプログラムを記憶するメモリ、２０４は操作パネル、２０５は液晶表示器などの表示器、２０９は変調信号−無線電波の変換を行うＲＦユニット、２０８はＱＰＳＫ（Ｑｕａｄｕｒａｔｕｒｅ Ｐｈａｓｅ Ｓｈｉｆｔ Ｋｅｙｉｎｇ）などによりチャネルデータを変復調するモデム、２０７はデジタル音声−無線チャネルＩ／Ｆデータの変換を行うチャネルコーデック、２０６はＡＤＰＣＭ（Ａｄａｐｔｉｖｅ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｐｕｌｓｅ Ｃｏｄｅｄ Ｍｏｄｕｌａｔｉｏｎ）などによりアナログ音声−デジタル音声の変換を行うコーデック、２１２はスピーカ、２１３はマイクロホン、そして、２１４は例えばシリアルＩ／Ｆなどのマルチファンクション端末装置１０とのＩ／Ｆ回路である。
【００３１】
無線携帯端末２−２は典型的には例えばＰＨＳで実現され、かかる端末では諸種の動作設定をユーザからの指示により行うこと（ユーザ設定）ができるように構成されていることは周知のとおりである。本実施形態における無線携帯端末２−２のユーザ設定項目には、受信したメールの内容をこの無線携帯端末２−２においてデコードするかどうかの選択が含まれる。また、メモリ２０２には、例えば、この無線携帯端末２−２でデコード可能な画像データの形式（ＧＩＦ、ＪＰＥＧ、ＢＭＰなど）を記述したサポートフォーマット一覧テーブルが記憶されている。
【００３２】
上記した構成の通信システムにおける動作の一例として、ユーザＢの無線携帯端末２−３が、デジタルカメラ２−４からの画像データを、ユーザＡの無線携帯端末２−２に送信する場合の動作について説明する。
【００３３】
無線携帯端末２−３において無線携帯端末２−２の宛先を指定して発呼すると、公知の手段で基地局２−５と通信を行う。ＲＮＣ２−６およびＣＮ２−７を管理するマネージメントサーバ２−８により、無線携帯端末２−２を収容するＲＡＮ（すなわちＲＡＮ２−９）の選択を行い、そこにデータを送信することになる。
【００３４】
ＲＮＣ２−１０および基地局２−１１経由でデータを受信した無線携帯端末２−２は、受信したデータ中のヘッダ情報に基づいて画像データを抽出し、あらかじめプログラムされてあるデコードプログラムによりファイルを画像データに展開し、無線携帯端末２−２に内蔵の表示用ドライバプログラムによってその表示部に表示する。各無線携帯端末は相手先の無線携帯端末を想定した最適な画像フォーマットでデータ転送すればよい。ＰＣで一般的に使用されている画像フォーマットとしては、ＪＰＥＧやデジタルカメラの標準ファイル形式ＤＣＦ（Ｄｅｓｉｇｎｒｕｌｅ ｆｏｒ Ｃａｍｅｒａ Ｆｉｌｅ ｓｙｓｔｅｍ）などがある。
【００３５】
次に、ユーザＣのＰＣ２−１３が、デジタルカメラ２−１２で撮影した画像を、ユーザＡの無線携帯端末２−２に送信する場合について説明する。
【００３６】
デジタルカメラ２−１２で撮影された画像ファイルは、ＰＣ２−１３で所定の加工がなされた後、電子メールプログラム（メールアプリケーション）により、ユーザＣのｔａｒｏ＠ｇａｎｏｎ．ｃｏ．ｊｐを送信元アドレス、ユーザＡのｈａｎａｋｏ＠ｘｘｘｘ．ｎｅ．ｊｐを送信先アドレスとする電子メールの添付ファイルとして送信される。
【００３７】
具体的には次のとおりである。ここで、画像ファイルの形式は例えばビットマップ（ＢＭＰ）形式のファイルであるとする。まず、ビットマップの画像ファイルはＰＣ２−１３のメールアプリケーションにおいてＴＩＦＦヘッダが付加され、さらにＭＩＭＥ（Ｍｕｌｔｉｐｌｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｔｉｏｎｓ：多目的インターネット・メール拡張機能（ＲＦＣ１５２１で定義されている。））に従うエンコードを行ってＡＳＣＩＩの文字列としてメールに埋め込まれることになる。
【００３８】
元来、電子メールは７ｂｉｔ文字のキャラクタコードを送受信するのが前提になっていたため、８ｂｉｔ文字や１行の文字数の制限やメール全体のサイズの制限もあった。そこで、Ｂａｓｅ６４やＱｕｏｔｅｄ−ｐｒｉｎｔａｂｌｅを用いることにより、７ｂｉｔから８ｂｉｔコード化を行い、また、ＭＩＭＥによりメール本文に構造化機能を与えることができるようになった。これにより、添付ファイルデータはＭＩＭＥエンコードされ、ＡＳＣＩＩ の文字列となることにより電子メールのプロトコルによって配送できる形式となる。
【００３９】
ＭＩＭＥはメールヘッダ部に新たなヘッダを追加することで実現される。ここで、ＭＩＭＥ用に新規追加されたヘッダの一部を示す。
【００４０】
Ｍｉｍｅ−Ｖｅｒｓｉｏｎ ＭＩＭＥ のバージョン
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ データの種類
タイプ／サブタイプ；サブオプション
デフォルトは、
ｔｅｘｔ／ｐｌａｉｎ；ｃｈａｒｓｅｔ＝ＵＳ−ＡＳＣＩＩ
【００４１】
その後、送信先アドレスバッファの内容が宛先情報に設定され、電子メールがＳＭＴＰ（ＩＥＴＦにより勧告されたＳｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によりＩＳＰ２−１４内にあるＳＭＴＰサーバに送信される。ＩＰ網２−１６にある複数のメールサーバは、ＳＭＴＰサーバから転送されたメールをＳＭＴＰにより転送を続け、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ）からＣＮ２−７のゲートウエイのＩＰアドレスを取得し、ルーティングしながらＣＮ２−７に到達させる。ＣＮ２−７を管理するマネージメントサーバ２−８は、転送されてきたメールデータをまずＣＮ２−７内のメールサーバ２−１５に格納する。
【００４２】
マネージメントサーバ２−８は、無線携帯端末２−２がどのＲＡＷに属しているか検索し、ＲＮＣ２−１０および基地局２−１１を経由して無線携帯端末２−２に対してメールサーバ２−１５に届いたメールをＳＭＴＰにより送信する。
【００４３】
あるいは、マネージメントサーバ２−８が無線携帯端末２−２がどのＲＡＷに属しているか検索してＲＮＣ２−１０にメールの到着を通知し、基地局２−１１が無線携帯端末２−２に対してメールサーバ２−１５に届いたメールの情報を通知する。そして、通知を受けた無線携帯端末２−２がメールサーバ２−１５にアクセスして、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）により、スプールされたデータをダウンロードするようにしてもよい。
【００４４】
メールサーバ２−１５より受信した電子メールデータは、図３のようなメッセージ形式となる。同図中、
Ｍｅｓｓａｇｅ−Ｉｄ： はメッセージ固有のＩＤ（識別番号）、
Ｘ−Ｓｅｎｄｅｒ： は送信者のメールアドレス
Ｆｒｏｍ：ｔａｒｏ＠ｇａｎｏｎ．ｃｏ．ｊｐは送信者アドレス、
Ｔｏ：ｈａｎａｋｏ＠ｘｘｘｘ．ｎｅ．ｊｐは宛先アドレス、
Ｓｕｂｊｅｃｔはユーザが定義したメールのタイトル、
Ｍｉｍｅ−Ｖｅｒｓｉｏｎ： １．０はＭＩＭＥのバージョンが１．０であることを宣言したものである。また、Ｘ−Ｍａｉｌｅｒ： はメールアプリケーション名とそのバージョンを示すものである。
【００４５】
続くＣｏｎｔｅｎｔ−Ｔｙｐｅはデータの属性を示すものであり、例えばＣｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｐｌａｉｎはテキストデータを示し、このあとのデータ属性がテキストであることを示している。このＣｏｎｔｅｎｔ−Ｔｙｐｅにはこの他、例えば以下の種類がある。
【００４６】
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｒｉｃｈｔｅｘｔはリッチテキストで書かれたテキストデータ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｕｄｉｏ／ｂａｓｉｃは８ｂｉｔ μ法則でコード化された音声データ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｖｉｄｅｏ／ｍｐｅｇはＭＰＥＧ１形式の動画データ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｉｍａｇｅ／ｔｉｆｆはＴＩＦＦ形式のイメージデータであることを示す。
【００４７】
次に、電子メールを受信した無線携帯端末２−２およびこの無線携帯端末２−２に接続されうるマルチファンクション端末装置１０の動作について、図４〜７のフローチャートを用いて説明する。
【００４８】
図４は、電子メールを受信した無線携帯端末２−２の動作を示すフローチャートである。
【００４９】
ステップＡ−１でメール（メッセージ）を受信した後、ユーザ設定の状態に基づき、メールの内容を無線携帯端末２−２においてデコードするか否かを判断する（ステップＡ−２）。メールの内容を無線携帯端末２−２においてデコードしない場合には、後述するステップＡ−１１に進む。一方、メールの内容を無線携帯端末２−２においてデコードする場合、受信したメールメッセージからＣｏｎｔｅｎｔ−Ｔｙｐｅを取得する（ステップＡ−３）。そして、取得したそのＣｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式であるか否かを判断する（ステップＡ−４）。Ｃｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式でない場合にはステップＡ−６に進むが、Ｃｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式である場合には、ＴＩＦＦヘッダからどのようなエンコードにより生成されたデータかが判断できるので、ステップＡ−５に進み、ＴＩＦＦヘッダを解析する。
【００５０】
ＴＩＦＦヘッダにあるタグにはデータの並び方をはじめ、主走査（Ｘ軸方向）、副走査（Ｙ軸方向）それぞれの画素数による画像サイズ情報、圧縮情報、解像度、ビットマップの形式、ＲＧＢのデータ並びの順序、スキャナのメーカー名・型名コード、画像あたりのサンプル数（カラー）などの情報が含まれている。ステップＡ−６では、このタグから取得した情報と無線携帯端末２−２のサポートフォーマット一覧テーブルと比較し、無線携帯端末２−２においてサポート可能か否か（すなわち、デコードが可能か否か）を判断する。また、Ｃｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式でない場合には、画像データのヘッダから確認されるフォーマット情報とサポートフォーマット一覧テーブルと比較し、無線携帯端末２−２においてサポート可能か否かを判断する。
【００５１】
無線携帯端末２−２でサポート不可と判断された場合にはそのままステップＡ−１１に進む。一方、無線携帯端末２−２でサポートできると判断された場合にはステップＡ−７に進み、Ｃｏｎｔｅｎｔ−Ｔｙｐｅならびにタグ情報に基づいてデコード後のデータが有効かどうかを判断する。判断の条件としては例えば次のようなものがある。
【００５２】
・無線携帯端末２−２のメモリで処理可能なデータサイズであるか。
・表示部で表示するのに適当な画素数および色空間であるか。
・無線携帯端末２−２での処理を期待していないデータ、たとえばプリントアウトを前提としたＤＰＯＦ（Ｄｉｇｉｔａｌ Ｐｒｉｎｔ Ｏｒｄｅｒ Ｆｏｒｍａｔ）と呼ばれる印刷フォーマットデータやｐｒｎファイルであるか、等。
【００５３】
以上のような判断条件をいずれも満たさない場合にはステップＡ−１１に進む。他方、以上のような判断条件のいずれかを満たす場合にはステップＡ−８に進み、無線携帯端末２−２でデコードを実行し、表示などの所定の処理を行う（ステップＡ−９）。
【００５４】
続いてステップＡ−１１で、マルチファンクション端末（ＤＯＣＫ）２−１で処理を行うかどうかを次のように判断する。
【００５５】
まず、ステップＡ−６において無線携帯端末２−２でサポート不可と判断された場合で、なおかつ、マルチファンクション端末装置１０で処理をしない設定になっている場合は、ステップＡ−１２に進み、データを破棄し、ステップＡ−１３で、処理できないデータを受信し破棄した旨を通知し、処理を終了する。
【００５６】
一方、ステップＡ−６において無線携帯端末２−２でサポート不可と判断されたがマルチファンクション端末装置１０において処理をする設定になっている場合、あるいは、ステップＡ−７において無線携帯端末２−２でのデコード後のデータが有効でないと判断された場合は、ステップＡ−１４に進み、無線携帯端末２−２のＩ／Ｆレジスタにデータ有りのビット（ＤＬＲＱ ｂｉｔ）を立て、その後、ステップＡ−１５で、Ｉ／Ｆ部にマルチファンクション端末装置１０が接続されているか否かを判断する。
【００５７】
Ｉ／Ｆ部にマルチファンクション端末装置１０が接続されている場合には、ステップＡ−１８に進み、リクエスト信号をイネーブルにする。
【００５８】
Ｉ／Ｆ部にマルチファンクション端末装置１０が接続されていない場合には、無線携帯端末２−２で解析した結果の情報を記憶する。具体的には、ステップＡ−１６で、メールメッセージのうちＭＩＭＥ形式ヘッダ部分のみを抽出してステップＡ−１７でメモリ部に保存する一方、その他の部分についてはステップＡ−１２と同様に消去する。この消去により携帯端末の記憶領域を確保でき、その後の通信で記憶領域を最適に使用できる。
【００５９】
図５は、無線携帯端末２−２が接続されたときのマルチファンクション端末装置１０の動作を示すフローチャートである。
【００６０】
ステップＢ−１では、Ｉ／Ｆ部１−１５（図１を参照）に無線携帯端末２−２が接続されたことを確認する。Ｉ／Ｆ部１−１５が充電機能を備えている場合には、充電回路の電圧監視回路を用いて無線携帯端末２−２が接続されたことを判定し、ＰＣＭＣＩＡ経由で無線携帯端末２−２との交信を開始することができる。
【００６１】
まず、無線携帯端末２−２の電話番号、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｙ ｍｏｄｕｌｅ）のＰＩＮ（Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｙ Ｎｕｍｂｅｒ）情報などから以後のフローの処理を実行してよいかの相互認証を行う（ステップＢ−２）。次に、無線携帯端末２−２のステータスレジスタを確認し（ステップＢ−３）、図４のステップＡ−１４において設定されるＤＬＲＱ ｂｉｔが立っているか否かを調べることでステップＢ−５以下の処理を行うかどうかを判断する（ステップＢ−４）。なお、無線携帯端末２−２が接続されたままの状態の場合には、上記のステップＡ−１８で無線携帯端末２−２より出されるリクエスト信号をトリガとして無線携帯端末２−２のステータスレジスタを確認するようにする。
【００６２】
ステップＢ−５では、無線携帯端末２−２の解析結果を利用するかどうかを判断する。
【００６３】
利用しない場合にはステップＢ−６に進み、無線携帯端末２−２を起動し、メールサーバ２−１５から該当するメールデータを受信する。この場合、無線端末２−２でいったんデータを受信した後にマルチファンクション端末で受信してもよいし、無線端末を通じて直接マルチファンクション端末で受信してもよい。
【００６４】
ダウンロードしたデータは図３と同じ形式であり、Ｍｉｍｅ−Ｖｅｒｓｉｏｎフィールドにおいて、ＭＩＭＥのバージョンを確認できる。Ｍｅｓｓａｇｅ−Ｉｄ、Ｘ−Ｍａｉｌｅｒ、Ｄａｔｅ、Ｔｏ、Ｆｒｏｍ、Ｓｕｂｊｅｃｔなどの各情報を取得した後、Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドからファイル属性を調べる（ステップＢ−７）。図示の例では、
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｍｕｌｔｉｐａｒｔ／ｍｉｘｅｄ；ｂｏｕｎｄａｒｙ＝”ｂｏｕｎｄａｒｙ＿ｔａｒｏ”
と記述され、メッセージボディが複数のブロックから構成され（ｍｕｌｔｉｐａｒｔ）、”ｂｏｕｎｄａｒｙ＿ｔａｒｏ”という文字列の境界で区切られた複数のブロックを有し、各ブロックはそれぞれ独立していることがわかる。そして、図示のとおり、第１のブロックは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｔｅｘｔ／ｐｌａｉｎとして、その内容はプレーンなテキストであることが示されている。また、第２のブロックは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｉｍａｇｅ／ｔｉｆｆとして、その内容はＴＩＦＦ形式の画像データであることがわかる。さらに、第３のブロックは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｕｄｉｏ／ｂａｓｉｃとして、その内容は８ｂｉｔμ法則でコード化された音声データであることがわかる。
【００６５】
ここでは、第２のブロックに格納されているＴＩＦＦフォーマットされたＢＭＰファイルを例に説明する。ＴＩＦＦはひとつのタグ（ＴＡＧ）と複数のディレクトリから構成されている。ヘッダは先頭のディレクトリをポインタで示し、各ディレクトリは次のディレクトリをポインタで指し示し最終ポインタとして０が格納されている。
【００６６】
以下にＴＩＦＦに含まれる情報の一例をあげる。
【００６７】
ｉｍａｇｅ ｗｉｄｔｈＴＡＧ（ＩＤ：０ＦＦ）とｉｍａｇｅ ｌｅｎｇｔｈＴＡＧ（ＩＤ：１０１）の大きさ（ピクセル数）から、画像データの大きさを判断できる。ｓａｍｐｌｅ ｐｅｒ ｂｉｔＴＡＧ（ＩＤ：１１５）とｂｉｔ ｐｅｒｓａｍｐｌｅＴＡＧ（ＩＤ：１０２）より、モノクロデータであるか、何ビット幅のカラーデータであるかを判断できる。また、データが圧縮されているかどうかはｃｏｍｐｒｅｓｓｉｏｎＴＡＧ（ＩＤ：１０３）を調べることにより判断でき、データ圧縮の方式はｃｏｍｐｒｅｓｓｉｏｎＴＡＧ（ＩＤ：２５９）を調べることにより判断できる。画像データの場所はｓｔｒｉｐ ｏｆｆｓｅｔＴＡＧ（ＩＤ：１１１）に格納されているファイル内のオフセットを参照する。
【００６８】
以上のように解析した情報をマルチファンクション端末装置１０のサポートフォーマット一覧テーブルと比較し、デコード可能かどうかを判断する（ステップＢ−８）。
【００６９】
デコード可能な場合、この解析情報をもとにｂｏｕｎｄａｒｙ＿ｔａｒｏで区切られたブロック毎にデコードを行う（ステップＢ−９）。ｍｕｌｔｉｐａｒｔ／ｍｉｘｅｄの場合には、それぞれのＣｏｎｔｅｎｔ−Ｔｙｐｅがデコード可能か否かを個別に判断する。そして、マルチファンクション端末装置１０で処理可能なものはｂｏｕｎｄａｒｙ＝”ｂｏｕｎｄａｒｙ＿ｔａｒｏ”で区切られたブロックを切り出す。
【００７０】
上記のステップＢ−５で、無線携帯端末２−２の解析結果を利用する場合には、ステップＢ−１０に進み、無線携帯端末２−２の解析結果にＣｏｎｔｅｎｔ−Ｔｙｐｅの情報が含まれているかどうかを判断する。解析結果にＣｏｎｔｅｎｔ−Ｔｙｐｅの情報が含まれていない場合にはステップＢ−６に進む。一方、解析結果にＣｏｎｔｅｎｔ−Ｔｙｐｅの情報が含まれていた場合にはステップＢ−１１に進み、ステップＢ−７と同様にＣｏｎｔｅｎｔ−Ｔｙｐｅからファイル属性を解析する。さらに、ステップＢ−１２で、ステップＢ８と同様に、解析した情報をマルチファンクション端末装置１０のサポートフォーマット一覧テーブルと比較し、デコード可能かどうかを判断する。そして、ステップＢ−１３で、無線携帯端末２−２を起動し、メールサーバ２−１５から、該当するメールデータのうちデコード可能と判断されたブロックをダウンロードした後、ステップＢ−９に進む。
【００７１】
ステップＢ−８またはステップＢ−１２において、デコード不可と判断された場合は、マルチファンクション端末装置１０に受信データに対応するデコード用のドライバプログラムがないと判断して、図７に示すフローＤへ進む。
【００７２】
まず、ステップＤ−１で、デコード用のドライバプログラムをドライバサーバ２−１８からダウンロードして更新するかどうかを判断する。更新するかどうかは、例えば、現在インストールされているドライバプログラムの作成日時から所定期間を経過しているか否かで判断する。更新しない場合にはステップＤ−５に進む。
【００７３】
ドライバプログラムをダウンロードするためには無線携帯端末２−２を用いて発呼する必要があるため、ステップＢ−２で行った相互認証の結果を用いるようにしてもよい。
【００７４】
ドライバプログラムをダウンロードする場合、まずサービスデータベース２−２０に問い合わせを行い、必要なドライバプログラムが保管してあるドライバサーバ２−１８のＩＰアドレスを取得し、ＩＰ網２−１６経由でドライバサーバ２−１８にアクセスする（ステップＤ−２）。
【００７５】
ステップＤ−３で、デコードに必要なドライバプログラムがあるか否かを判断し、ある場合にはそのプログラムをダウンロードする（ステップＤ−４）。デコードに必要なドライバソフトがなかった場合は、デコードできなかった旨を表示部１−６に表示し、ユーザに告知する（ステップＤ−５）。
【００７６】
この処理はあらかじめ決められた時間毎にドライバプログラムがアップグレードされていないか確認し、必要に応じてダウンロードするようにしてもよい。
【００７７】
図６は、図５のステップＢ−９においてデコードされたデータのマルチファンクション端末の処理を示すフローチャートである。
【００７８】
まず、ステップＣ−１で、マルチファンクション端末装置１０にダウンロードされたデータがプリント用のファイルであるか否かを、例えば画像の解像度に基づいて判断する。例えば、画像の解像度が所定値よりも大きい場合には、表示部１−６で表示するにはサイズが大きすぎて不適当であるため表示部に表示させるのではなくプリントしたほうがよいので、この画像はプリント用のファイルであると判断する。ここで、ダウンロードされたデータがプリント用のファイルでなかった場合には、ステップＣ−２に進み、デコードしたデータの内容をユーザに知らせたり次の処理を選択させる目的で、デコードしたデータを表示用ドライバプログラムを用いて表示部１−６に表示する。その後、ステップＣ−３に進む。一方、ダウンロードされたデータがプリント用のファイルであった場合には、そのままステップＣ−３に進む。
【００７９】
ステップＣ−３はプリンタ部１−１２へデータを転送し印字（ｐｒｉｎｔ ｏｕｔ）するか否かを判断するブロックであり、ステップＣ−１でプリントファイルと判断された場合、および、ステップＣ−２で選択的に印字を選択された場合、にステップＣ−４に進み、そうでなければステップＣ−７に進むことになる。
【００８０】
ステップＣ−４では、操作部１−５よりプリントアウトする画像を選択、編集し、プリントアウトの設定を行う。そして、ステップＣ−５で内蔵のプリンタドライバを用いプリントデータが作成され、ステップＣ−６で、プリンタ部１−１２にプリントデータが転送されてプリントアウトされる。
【００８１】
次に、図５に示したフローに従いマルチファンクション端末装置１０でデコードしたデータを無線携帯端末２−２に送信すべきかどうかを、例えばユーザ設定の内容（デコード後のデータを無線携帯端末２−２に送信する／しない）に基づいて判断する（ステップＣ−７）。無線携帯端末２−２に送信すべきと判断された場合にはステップＣ−８に進み、ステップＣ−８デコード後のデータを無線携帯端末２−２に転送した後、ステップＣ−９に進む。ステップＣ−７で無線携帯端末２−２に送信しないと判断された場合にはそのままステップＣ−９に進む。このため、無線携帯端末２−２は転送されてきたデコード後のデータの内容を表示し、および／または、記憶することが可能になる。
【００８２】
ステップＣ−９では、マルチファンクション端末装置１０にダウンロードされたデータを記録部１−９に保存するかどうか判断する。ここで、保存の必要がない場合にはステップＣ−１０に進み、データを消去する。保存の必要がある場合にはステップＣ−１１に進み、データを所定の記録媒体に保存する。なお、ここではダウンロードしたデータをデコードできたか否かにかかわりなく保存するようにしてもよい。
【００８３】
また、デコードしたデータで保存するとデータサイズが大きくなり、格納に不利な場合はデコード前のデータで保存し、必要に応じてデコードするようにするとよいであろう。
【００８４】
また、受信したメール固有のＭｅｓｓａｇｅ−ＩＤを保存データまたは保存データのインデックスに付加することにより、無線携帯端末２−２からデータを消去した場合もメールの受信順にデータをソートすることが可能になる。
【００８５】
また、カラー画像ファイルを無線携帯端末２−２が受信したとき、無線携帯端末２−２で表示可能なモノクロデータにデコード・表示し、受信したデータを保存するようにしてもよい。この場合、マルチファンクション端末装置１０に接続されたときには、受信データをデコードしカラーで表示する。
【００８６】
以上の実施形態によれば、無線携帯端末２−２が自身ではデコードできないデータを受信した場合、マルチファンクション端末装置１０が代わってそのデータをデコードする。さらに、デコードされたデータは無線携帯端末２−２に転送される。これにより、無線情報端末２−２は、自身でデコードできなかったデータの内容を表示し保持することが可能になる。
【００８７】
以上、本発明の実施形態を詳述したが、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタ等）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機、ファクシミリ装置等）に適用してもよい。
【００８８】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（図４および／または図５〜７に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムを読み出して実行することによっても達成される場合を含む。
【００８９】
したがって、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【００９０】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【００９１】
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ等）、光磁気ディスク、磁気テープ、メモリカード等がある。
【００９２】
その他、プログラムの供給方法としては、インターネットを介して本発明のプログラムをファイル転送によって取得する態様も含まれる。
【００９３】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介して暗号化を解く鍵情報を取得させ、その鍵情報を使用することで暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００９４】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現され得る。
【００９５】
さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【００９６】
【発明の効果】
本発明によれば、通信端末自身がデコードできないデータを受信した場合でも、別の装置の支援を受けてそのデータをデコードし、通信端末においてメッセージの内容を確認することのできる通信システム、通信端末およびその制御方法を提供することができる。
【図面の簡単な説明】
【図１】実施形態におけるマルチファンクション端末装置の構成を示すブロック図である。
【図２】実施形態に係る通信システムを示す図である。
【図３】実施形態における電子メールデータの内容の一例を示す図である。
【図４】電子メールを受信した無線携帯端末の動作を示すフローチャートである。
【図５】無線携帯端末が接続されたときのマルチファンクション端末の動作を示すフローチャートである。
【図６】実施形態におけるデータのデコード後のマルチファンクション端末の処理を示すフローチャートである。
【図７】対象データのデコードが不可と判断されたときのマルチファンクション端末の処理を示すフローチャートである。
【図８】実施形態に係る無線携帯端末のハードウェア構成を示すブロック図である。
【発明の属する技術分野】
本発明は、通信システム、通信端末およびその制御方法に関するものである。
【０００２】
【従来の技術】
無線携帯端末等の通信端末は、ネットワークを経由してサーバから各種データを取得することが可能である。最近では、電子メール機能により電子メールデータを自動受信することができるようになっている。電子メールは各種アプリケーションで作成されたファイルを添付ファイルとして送信することも可能になっている。
【０００３】
【発明が解決しようとする課題】
ところが、添付ファイルとして送られてきたもののすべてが無線携帯端末でデコード可能であるとは限らない。デコードできないデータを端末が記憶していることは無駄であるから、そのようなデータを自動的に破棄させることも考えられるが、他の装置の補助を受けてでもデコードできないメッセージの内容を見たいというニーズもある。
【０００４】
そこで、本発明は、通信端末自身がデコードできないデータを受信した場合でも、別の装置の支援を受けてそのデータをデコードし、通信端末においてメッセージの内容を確認することのできる通信システム、通信端末およびその制御方法を提供することを目的としている。
【０００５】
【課題を解決するための手段】
本発明の一側面は、ネットワークを介してデータを送受可能な通信端末と、その通信端末と接続可能なデータ処理装置とを含む通信システムに係る。この通信システムにおいて、前記通信端末は、受信したデータに当該通信端末でデコードできない属性のファイルが含まれているか否かを判断し、前記受信したデータに当該通信端末でデコードできない属性のファイルが含まれているときは、そのファイルを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのファイルをデコードするよう指示する。そして、前記データ処理装置は、前記指示手段の指示に応じて、前記ファイルを取得し、取得した前記ファイルをデコードし、デコード後のデータを前記通信端末に送信する。
【０００６】
本発明の別の側面は、ネットワークを介してメッセージを送受可能な通信端末に接続されたデータ処理装置およびその制御方法に係る。このデータ処理装置は、前記通信端末が受信したメッセージに当該通信端末でデコードできない属性のデータが含まれていること示す指示信号を検出し、前記指示信号を検出したときに前記データを取得し、取得した前記データをデコードし、デコードしたデータを前記通信端末に送信する。かかる制御方法はプログラムによっても実現されうる。
【０００７】
【発明の実施の形態】
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。
【０００８】
図１は、実施形態におけるデータ処理装置としてのマルチファンクション端末装置の構成を示すブロック図である。このマルチファンクション端末装置は、後述するように通信端末としての無線携帯端末と接続し、無線携帯端末からのデータを表示、印刷、記憶等することができるように構成されている。
【０００９】
マルチファンクション端末装置１０は、図示のように、ＣＰＵ１−１、ＲＯＭ１−２、ＲＡＭ１−３、不揮発性ＲＡＭ１−４、操作部１−５、表示部１−６、符号・復号部１−７、読取り部１−８、記録部１−９、駆動部１−１０、ＭＯＤＥＭ部１−１１、プリンタ部１−１２、Ａ／Ｄ変換部１−１３、スピーカ部１−１４、Ｉ／Ｆ部１−１５を有する。
【００１０】
ＣＰＵ１−１は、ＲＯＭ１−２に記憶されているプログラムに従って装置全体の制御を行う。プログラムを格納するＲＯＭ部１−２は、フラッシュメモリのような書き換え可能なメモリでも構わない。ＲＡＭ１−３は、無線携帯端末からＩ／Ｆ部１−１５経由で受け取ったデータや、符号・復号部１−７、Ａ／Ｄ部１−１３、記録部１−９、読取り部１−８、プリンタ部１−１２で処理するデータの格納を行うのに用いる。
【００１１】
不揮発性ＲＡＭ１−４は、無線携帯端末の認証に関する各種情報や、端末固有の情報をはじめ、各種デコード処理に必要なプログラムの全部または一部、ダウンロードされた最新のアプリケーションソフト等を格納するのに用いられる。
【００１２】
操作部１−５は、無線携帯端末からのデータをメニュー表示させる「メニューボタン」、メニューからどのデータを処理させるかを決める「選択操作」、選択したデータをどのように処理するかを決める「選択操作」などを有する。表示部１−６と一体化させタッチパネルなどを使うようにしても構わない。
【００１３】
表示部１−６は、各種操作を補助するためのメニュー表示、受信データのうち表示選択されたデータの表示等に使用される。
【００１４】
符号・復号部１−７は、受信したデータのタイプによって決定される符号・復号プログラムにより演算処理する。高速演算が必要なため符号・復号部内部に専用のＲＯＭ、ＲＡＭ、演算回路を有する構成が好ましい。また、演算回路（例えばＤＳＰ）でのデコードに必要なプログラムを、ネットワーク経由で更新できるようにしてもよい。なお、ＣＰＵの充分に処理能力が高い場合は、この符号・復号部１−７の機能をＣＰＵ１−１に担わせるようにしても構わない。
【００１５】
読取り部１−８は原稿をスキャンする光学系部品で構成され、原稿の内容を電子データとして変換する。ここでスキャンされたアナログ信号をＡ／Ｄ変換し、以後の処理に必要なデータ形式に符号・複号部１−７で変換する。
【００１６】
記録部１−９は、ハードディスク、半導体メモリまたはテープなどで構成され、無線携帯端末経由で受信したデータを保存するために用いられる。ＲＡＭ部１−３との容量・価格・アクセスタイムのバランスを考慮した記録媒体を用いることが望ましい。
【００１７】
駆動部１−１０は読み取り部１−８、プリンタ部１−１２の各種モータを駆動する。
【００１８】
モデム部１−１１は、無線携帯端末経由でアナログ変調された変調波を送受信する（いわゆる見なし音声通信）場合の変調／復調を行う。
【００１９】
プリンタ部１−１２は、受信したデータ、読取ったデータをプリントアウトするのに用い、ＬＢＰ、インクジェット、熱転などいずれの方式を用いてもよい。
【００２０】
Ａ／Ｄ変換部１−１３は受信した音データをアナログ信号に変換や、各種操作音を生成するために用いる。モデム部１−１１のＡ／Ｄ変換回路と共有するようにしても良い。
【００２１】
スピーカ部１−１４はＡ／Ｄ変換部１−１３で変換されたアナログ信号をスピーカにより可聴音として再生する。
【００２２】
Ｉ／Ｆ部１−１５は、無線携帯端末との通信および充電を行うインターフェイス部分であり、複数の無線携帯端末を接続できるようにしても構わない。インターフェイスの通信仕様は有線でも無線でも構わないが、本実施形態ではシリアル通信でデータ送受を行う。
【００２３】
また、ＲＯＭ１−２には、例えば、このマルチファンクション端末装置１０でデコード可能な画像データの形式（ＧＩＦ、ＪＰＥＧ、ＢＭＰなど）を記述したサポートフォーマット一覧テーブルが記憶されている。
【００２４】
次に、電子メールに添付された画像データを、マルチファンクション端末装置で出力・再生する際の動作について説明する。
【００２５】
図２は、実施形態に係る上記マルチファンクション端末装置１０を含む通信システムを示す図である。
【００２６】
同図において、２−２がマルチファンクション端末装置１０と接続可能な無線携帯端末であり、２−３は、画像入力装置（例えばデジタルカメラ）２−４と接続可能な別の無線携帯端末である。２−５および２−１１は無線携帯端末と無線通信を行う基地局、２−６、２−１０はＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワーク制御装置）であり、図示の如く、この基地局２−１１とＲＮＣ２−１０、基地局２−５とＲＮＣ２−６でそれぞれＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：無線アクセス網）２−９ａ、２−９ｂを構成する。
【００２７】
また、ＣＮ（ｃｏｒｅ ｎｅｔｗｏｒｋ：コアネットワーク）２−７にはＲＡＮ２−９ａ、２−９ｂをはじめ、次に掲げるノードが接続されている。
【００２８】
加入者の情報や認証を行うマネージメントサーバ２−８、
ＣＮ２−７のメールを管理するメールサーバ２−１５、
各種ドライバプログラムを格納したドライバサーバおよびパケット処理のアドレス解決（ＤＮＳ）サーバとして機能するサービスデータベース２−２０、そして、
ＩＰ網２−１６、ＰＤＣ網２−２１、ＰＨＳ網２−２２、ＰＳＴＮ網２−２３、ＩＳＤＮ網２−２４といった各種通信ネットワーク。
【００２９】
デジタルカメラ２−１２を接続可能なパーソナルコンピュータ（ＰＣ）２−１３は、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）２−１４を経由してＩＰ網２−１６に接続される。ＩＰ網２−１６にはこの他、各種サービスのコンテンツを格納したコンテンツサーバ２−１７、各種アプリケーションの最新ドライバを格納したドライバサーバ２−１８、そしてＷＷＷサーバ２−１９が接続されている。
【００３０】
図８は、無線携帯端末２−２のハードウェア構成を示すブロック図である。２０１は端末全体の動作を制御するＣＰＵ、２０２はデータおよびプログラムを記憶するメモリ、２０４は操作パネル、２０５は液晶表示器などの表示器、２０９は変調信号−無線電波の変換を行うＲＦユニット、２０８はＱＰＳＫ（Ｑｕａｄｕｒａｔｕｒｅ Ｐｈａｓｅ Ｓｈｉｆｔ Ｋｅｙｉｎｇ）などによりチャネルデータを変復調するモデム、２０７はデジタル音声−無線チャネルＩ／Ｆデータの変換を行うチャネルコーデック、２０６はＡＤＰＣＭ（Ａｄａｐｔｉｖｅ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｐｕｌｓｅ Ｃｏｄｅｄ Ｍｏｄｕｌａｔｉｏｎ）などによりアナログ音声−デジタル音声の変換を行うコーデック、２１２はスピーカ、２１３はマイクロホン、そして、２１４は例えばシリアルＩ／Ｆなどのマルチファンクション端末装置１０とのＩ／Ｆ回路である。
【００３１】
無線携帯端末２−２は典型的には例えばＰＨＳで実現され、かかる端末では諸種の動作設定をユーザからの指示により行うこと（ユーザ設定）ができるように構成されていることは周知のとおりである。本実施形態における無線携帯端末２−２のユーザ設定項目には、受信したメールの内容をこの無線携帯端末２−２においてデコードするかどうかの選択が含まれる。また、メモリ２０２には、例えば、この無線携帯端末２−２でデコード可能な画像データの形式（ＧＩＦ、ＪＰＥＧ、ＢＭＰなど）を記述したサポートフォーマット一覧テーブルが記憶されている。
【００３２】
上記した構成の通信システムにおける動作の一例として、ユーザＢの無線携帯端末２−３が、デジタルカメラ２−４からの画像データを、ユーザＡの無線携帯端末２−２に送信する場合の動作について説明する。
【００３３】
無線携帯端末２−３において無線携帯端末２−２の宛先を指定して発呼すると、公知の手段で基地局２−５と通信を行う。ＲＮＣ２−６およびＣＮ２−７を管理するマネージメントサーバ２−８により、無線携帯端末２−２を収容するＲＡＮ（すなわちＲＡＮ２−９）の選択を行い、そこにデータを送信することになる。
【００３４】
ＲＮＣ２−１０および基地局２−１１経由でデータを受信した無線携帯端末２−２は、受信したデータ中のヘッダ情報に基づいて画像データを抽出し、あらかじめプログラムされてあるデコードプログラムによりファイルを画像データに展開し、無線携帯端末２−２に内蔵の表示用ドライバプログラムによってその表示部に表示する。各無線携帯端末は相手先の無線携帯端末を想定した最適な画像フォーマットでデータ転送すればよい。ＰＣで一般的に使用されている画像フォーマットとしては、ＪＰＥＧやデジタルカメラの標準ファイル形式ＤＣＦ（Ｄｅｓｉｇｎｒｕｌｅ ｆｏｒ Ｃａｍｅｒａ Ｆｉｌｅ ｓｙｓｔｅｍ）などがある。
【００３５】
次に、ユーザＣのＰＣ２−１３が、デジタルカメラ２−１２で撮影した画像を、ユーザＡの無線携帯端末２−２に送信する場合について説明する。
【００３６】
デジタルカメラ２−１２で撮影された画像ファイルは、ＰＣ２−１３で所定の加工がなされた後、電子メールプログラム（メールアプリケーション）により、ユーザＣのｔａｒｏ＠ｇａｎｏｎ．ｃｏ．ｊｐを送信元アドレス、ユーザＡのｈａｎａｋｏ＠ｘｘｘｘ．ｎｅ．ｊｐを送信先アドレスとする電子メールの添付ファイルとして送信される。
【００３７】
具体的には次のとおりである。ここで、画像ファイルの形式は例えばビットマップ（ＢＭＰ）形式のファイルであるとする。まず、ビットマップの画像ファイルはＰＣ２−１３のメールアプリケーションにおいてＴＩＦＦヘッダが付加され、さらにＭＩＭＥ（Ｍｕｌｔｉｐｌｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｔｉｏｎｓ：多目的インターネット・メール拡張機能（ＲＦＣ１５２１で定義されている。））に従うエンコードを行ってＡＳＣＩＩの文字列としてメールに埋め込まれることになる。
【００３８】
元来、電子メールは７ｂｉｔ文字のキャラクタコードを送受信するのが前提になっていたため、８ｂｉｔ文字や１行の文字数の制限やメール全体のサイズの制限もあった。そこで、Ｂａｓｅ６４やＱｕｏｔｅｄ−ｐｒｉｎｔａｂｌｅを用いることにより、７ｂｉｔから８ｂｉｔコード化を行い、また、ＭＩＭＥによりメール本文に構造化機能を与えることができるようになった。これにより、添付ファイルデータはＭＩＭＥエンコードされ、ＡＳＣＩＩ の文字列となることにより電子メールのプロトコルによって配送できる形式となる。
【００３９】
ＭＩＭＥはメールヘッダ部に新たなヘッダを追加することで実現される。ここで、ＭＩＭＥ用に新規追加されたヘッダの一部を示す。
【００４０】
Ｍｉｍｅ−Ｖｅｒｓｉｏｎ ＭＩＭＥ のバージョン
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ データの種類
タイプ／サブタイプ；サブオプション
デフォルトは、
ｔｅｘｔ／ｐｌａｉｎ；ｃｈａｒｓｅｔ＝ＵＳ−ＡＳＣＩＩ
【００４１】
その後、送信先アドレスバッファの内容が宛先情報に設定され、電子メールがＳＭＴＰ（ＩＥＴＦにより勧告されたＳｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によりＩＳＰ２−１４内にあるＳＭＴＰサーバに送信される。ＩＰ網２−１６にある複数のメールサーバは、ＳＭＴＰサーバから転送されたメールをＳＭＴＰにより転送を続け、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ）からＣＮ２−７のゲートウエイのＩＰアドレスを取得し、ルーティングしながらＣＮ２−７に到達させる。ＣＮ２−７を管理するマネージメントサーバ２−８は、転送されてきたメールデータをまずＣＮ２−７内のメールサーバ２−１５に格納する。
【００４２】
マネージメントサーバ２−８は、無線携帯端末２−２がどのＲＡＷに属しているか検索し、ＲＮＣ２−１０および基地局２−１１を経由して無線携帯端末２−２に対してメールサーバ２−１５に届いたメールをＳＭＴＰにより送信する。
【００４３】
あるいは、マネージメントサーバ２−８が無線携帯端末２−２がどのＲＡＷに属しているか検索してＲＮＣ２−１０にメールの到着を通知し、基地局２−１１が無線携帯端末２−２に対してメールサーバ２−１５に届いたメールの情報を通知する。そして、通知を受けた無線携帯端末２−２がメールサーバ２−１５にアクセスして、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）により、スプールされたデータをダウンロードするようにしてもよい。
【００４４】
メールサーバ２−１５より受信した電子メールデータは、図３のようなメッセージ形式となる。同図中、
Ｍｅｓｓａｇｅ−Ｉｄ： はメッセージ固有のＩＤ（識別番号）、
Ｘ−Ｓｅｎｄｅｒ： は送信者のメールアドレス
Ｆｒｏｍ：ｔａｒｏ＠ｇａｎｏｎ．ｃｏ．ｊｐは送信者アドレス、
Ｔｏ：ｈａｎａｋｏ＠ｘｘｘｘ．ｎｅ．ｊｐは宛先アドレス、
Ｓｕｂｊｅｃｔはユーザが定義したメールのタイトル、
Ｍｉｍｅ−Ｖｅｒｓｉｏｎ： １．０はＭＩＭＥのバージョンが１．０であることを宣言したものである。また、Ｘ−Ｍａｉｌｅｒ： はメールアプリケーション名とそのバージョンを示すものである。
【００４５】
続くＣｏｎｔｅｎｔ−Ｔｙｐｅはデータの属性を示すものであり、例えばＣｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｐｌａｉｎはテキストデータを示し、このあとのデータ属性がテキストであることを示している。このＣｏｎｔｅｎｔ−Ｔｙｐｅにはこの他、例えば以下の種類がある。
【００４６】
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｔｅｘｔ／ｒｉｃｈｔｅｘｔはリッチテキストで書かれたテキストデータ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｕｄｉｏ／ｂａｓｉｃは８ｂｉｔ μ法則でコード化された音声データ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｖｉｄｅｏ／ｍｐｅｇはＭＰＥＧ１形式の動画データ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｉｍａｇｅ／ｔｉｆｆはＴＩＦＦ形式のイメージデータであることを示す。
【００４７】
次に、電子メールを受信した無線携帯端末２−２およびこの無線携帯端末２−２に接続されうるマルチファンクション端末装置１０の動作について、図４〜７のフローチャートを用いて説明する。
【００４８】
図４は、電子メールを受信した無線携帯端末２−２の動作を示すフローチャートである。
【００４９】
ステップＡ−１でメール（メッセージ）を受信した後、ユーザ設定の状態に基づき、メールの内容を無線携帯端末２−２においてデコードするか否かを判断する（ステップＡ−２）。メールの内容を無線携帯端末２−２においてデコードしない場合には、後述するステップＡ−１１に進む。一方、メールの内容を無線携帯端末２−２においてデコードする場合、受信したメールメッセージからＣｏｎｔｅｎｔ−Ｔｙｐｅを取得する（ステップＡ−３）。そして、取得したそのＣｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式であるか否かを判断する（ステップＡ−４）。Ｃｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式でない場合にはステップＡ−６に進むが、Ｃｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式である場合には、ＴＩＦＦヘッダからどのようなエンコードにより生成されたデータかが判断できるので、ステップＡ−５に進み、ＴＩＦＦヘッダを解析する。
【００５０】
ＴＩＦＦヘッダにあるタグにはデータの並び方をはじめ、主走査（Ｘ軸方向）、副走査（Ｙ軸方向）それぞれの画素数による画像サイズ情報、圧縮情報、解像度、ビットマップの形式、ＲＧＢのデータ並びの順序、スキャナのメーカー名・型名コード、画像あたりのサンプル数（カラー）などの情報が含まれている。ステップＡ−６では、このタグから取得した情報と無線携帯端末２−２のサポートフォーマット一覧テーブルと比較し、無線携帯端末２−２においてサポート可能か否か（すなわち、デコードが可能か否か）を判断する。また、Ｃｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式でない場合には、画像データのヘッダから確認されるフォーマット情報とサポートフォーマット一覧テーブルと比較し、無線携帯端末２−２においてサポート可能か否かを判断する。
【００５１】
無線携帯端末２−２でサポート不可と判断された場合にはそのままステップＡ−１１に進む。一方、無線携帯端末２−２でサポートできると判断された場合にはステップＡ−７に進み、Ｃｏｎｔｅｎｔ−Ｔｙｐｅならびにタグ情報に基づいてデコード後のデータが有効かどうかを判断する。判断の条件としては例えば次のようなものがある。
【００５２】
・無線携帯端末２−２のメモリで処理可能なデータサイズであるか。
・表示部で表示するのに適当な画素数および色空間であるか。
・無線携帯端末２−２での処理を期待していないデータ、たとえばプリントアウトを前提としたＤＰＯＦ（Ｄｉｇｉｔａｌ Ｐｒｉｎｔ Ｏｒｄｅｒ Ｆｏｒｍａｔ）と呼ばれる印刷フォーマットデータやｐｒｎファイルであるか、等。
【００５３】
以上のような判断条件をいずれも満たさない場合にはステップＡ−１１に進む。他方、以上のような判断条件のいずれかを満たす場合にはステップＡ−８に進み、無線携帯端末２−２でデコードを実行し、表示などの所定の処理を行う（ステップＡ−９）。
【００５４】
続いてステップＡ−１１で、マルチファンクション端末（ＤＯＣＫ）２−１で処理を行うかどうかを次のように判断する。
【００５５】
まず、ステップＡ−６において無線携帯端末２−２でサポート不可と判断された場合で、なおかつ、マルチファンクション端末装置１０で処理をしない設定になっている場合は、ステップＡ−１２に進み、データを破棄し、ステップＡ−１３で、処理できないデータを受信し破棄した旨を通知し、処理を終了する。
【００５６】
一方、ステップＡ−６において無線携帯端末２−２でサポート不可と判断されたがマルチファンクション端末装置１０において処理をする設定になっている場合、あるいは、ステップＡ−７において無線携帯端末２−２でのデコード後のデータが有効でないと判断された場合は、ステップＡ−１４に進み、無線携帯端末２−２のＩ／Ｆレジスタにデータ有りのビット（ＤＬＲＱ ｂｉｔ）を立て、その後、ステップＡ−１５で、Ｉ／Ｆ部にマルチファンクション端末装置１０が接続されているか否かを判断する。
【００５７】
Ｉ／Ｆ部にマルチファンクション端末装置１０が接続されている場合には、ステップＡ−１８に進み、リクエスト信号をイネーブルにする。
【００５８】
Ｉ／Ｆ部にマルチファンクション端末装置１０が接続されていない場合には、無線携帯端末２−２で解析した結果の情報を記憶する。具体的には、ステップＡ−１６で、メールメッセージのうちＭＩＭＥ形式ヘッダ部分のみを抽出してステップＡ−１７でメモリ部に保存する一方、その他の部分についてはステップＡ−１２と同様に消去する。この消去により携帯端末の記憶領域を確保でき、その後の通信で記憶領域を最適に使用できる。
【００５９】
図５は、無線携帯端末２−２が接続されたときのマルチファンクション端末装置１０の動作を示すフローチャートである。
【００６０】
ステップＢ−１では、Ｉ／Ｆ部１−１５（図１を参照）に無線携帯端末２−２が接続されたことを確認する。Ｉ／Ｆ部１−１５が充電機能を備えている場合には、充電回路の電圧監視回路を用いて無線携帯端末２−２が接続されたことを判定し、ＰＣＭＣＩＡ経由で無線携帯端末２−２との交信を開始することができる。
【００６１】
まず、無線携帯端末２−２の電話番号、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｙ ｍｏｄｕｌｅ）のＰＩＮ（Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｙ Ｎｕｍｂｅｒ）情報などから以後のフローの処理を実行してよいかの相互認証を行う（ステップＢ−２）。次に、無線携帯端末２−２のステータスレジスタを確認し（ステップＢ−３）、図４のステップＡ−１４において設定されるＤＬＲＱ ｂｉｔが立っているか否かを調べることでステップＢ−５以下の処理を行うかどうかを判断する（ステップＢ−４）。なお、無線携帯端末２−２が接続されたままの状態の場合には、上記のステップＡ−１８で無線携帯端末２−２より出されるリクエスト信号をトリガとして無線携帯端末２−２のステータスレジスタを確認するようにする。
【００６２】
ステップＢ−５では、無線携帯端末２−２の解析結果を利用するかどうかを判断する。
【００６３】
利用しない場合にはステップＢ−６に進み、無線携帯端末２−２を起動し、メールサーバ２−１５から該当するメールデータを受信する。この場合、無線端末２−２でいったんデータを受信した後にマルチファンクション端末で受信してもよいし、無線端末を通じて直接マルチファンクション端末で受信してもよい。
【００６４】
ダウンロードしたデータは図３と同じ形式であり、Ｍｉｍｅ−Ｖｅｒｓｉｏｎフィールドにおいて、ＭＩＭＥのバージョンを確認できる。Ｍｅｓｓａｇｅ−Ｉｄ、Ｘ−Ｍａｉｌｅｒ、Ｄａｔｅ、Ｔｏ、Ｆｒｏｍ、Ｓｕｂｊｅｃｔなどの各情報を取得した後、Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドからファイル属性を調べる（ステップＢ−７）。図示の例では、
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ｍｕｌｔｉｐａｒｔ／ｍｉｘｅｄ；ｂｏｕｎｄａｒｙ＝”ｂｏｕｎｄａｒｙ＿ｔａｒｏ”
と記述され、メッセージボディが複数のブロックから構成され（ｍｕｌｔｉｐａｒｔ）、”ｂｏｕｎｄａｒｙ＿ｔａｒｏ”という文字列の境界で区切られた複数のブロックを有し、各ブロックはそれぞれ独立していることがわかる。そして、図示のとおり、第１のブロックは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｔｅｘｔ／ｐｌａｉｎとして、その内容はプレーンなテキストであることが示されている。また、第２のブロックは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｉｍａｇｅ／ｔｉｆｆとして、その内容はＴＩＦＦ形式の画像データであることがわかる。さらに、第３のブロックは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｕｄｉｏ／ｂａｓｉｃとして、その内容は８ｂｉｔμ法則でコード化された音声データであることがわかる。
【００６５】
ここでは、第２のブロックに格納されているＴＩＦＦフォーマットされたＢＭＰファイルを例に説明する。ＴＩＦＦはひとつのタグ（ＴＡＧ）と複数のディレクトリから構成されている。ヘッダは先頭のディレクトリをポインタで示し、各ディレクトリは次のディレクトリをポインタで指し示し最終ポインタとして０が格納されている。
【００６６】
以下にＴＩＦＦに含まれる情報の一例をあげる。
【００６７】
ｉｍａｇｅ ｗｉｄｔｈＴＡＧ（ＩＤ：０ＦＦ）とｉｍａｇｅ ｌｅｎｇｔｈＴＡＧ（ＩＤ：１０１）の大きさ（ピクセル数）から、画像データの大きさを判断できる。ｓａｍｐｌｅ ｐｅｒ ｂｉｔＴＡＧ（ＩＤ：１１５）とｂｉｔ ｐｅｒｓａｍｐｌｅＴＡＧ（ＩＤ：１０２）より、モノクロデータであるか、何ビット幅のカラーデータであるかを判断できる。また、データが圧縮されているかどうかはｃｏｍｐｒｅｓｓｉｏｎＴＡＧ（ＩＤ：１０３）を調べることにより判断でき、データ圧縮の方式はｃｏｍｐｒｅｓｓｉｏｎＴＡＧ（ＩＤ：２５９）を調べることにより判断できる。画像データの場所はｓｔｒｉｐ ｏｆｆｓｅｔＴＡＧ（ＩＤ：１１１）に格納されているファイル内のオフセットを参照する。
【００６８】
以上のように解析した情報をマルチファンクション端末装置１０のサポートフォーマット一覧テーブルと比較し、デコード可能かどうかを判断する（ステップＢ−８）。
【００６９】
デコード可能な場合、この解析情報をもとにｂｏｕｎｄａｒｙ＿ｔａｒｏで区切られたブロック毎にデコードを行う（ステップＢ−９）。ｍｕｌｔｉｐａｒｔ／ｍｉｘｅｄの場合には、それぞれのＣｏｎｔｅｎｔ−Ｔｙｐｅがデコード可能か否かを個別に判断する。そして、マルチファンクション端末装置１０で処理可能なものはｂｏｕｎｄａｒｙ＝”ｂｏｕｎｄａｒｙ＿ｔａｒｏ”で区切られたブロックを切り出す。
【００７０】
上記のステップＢ−５で、無線携帯端末２−２の解析結果を利用する場合には、ステップＢ−１０に進み、無線携帯端末２−２の解析結果にＣｏｎｔｅｎｔ−Ｔｙｐｅの情報が含まれているかどうかを判断する。解析結果にＣｏｎｔｅｎｔ−Ｔｙｐｅの情報が含まれていない場合にはステップＢ−６に進む。一方、解析結果にＣｏｎｔｅｎｔ−Ｔｙｐｅの情報が含まれていた場合にはステップＢ−１１に進み、ステップＢ−７と同様にＣｏｎｔｅｎｔ−Ｔｙｐｅからファイル属性を解析する。さらに、ステップＢ−１２で、ステップＢ８と同様に、解析した情報をマルチファンクション端末装置１０のサポートフォーマット一覧テーブルと比較し、デコード可能かどうかを判断する。そして、ステップＢ−１３で、無線携帯端末２−２を起動し、メールサーバ２−１５から、該当するメールデータのうちデコード可能と判断されたブロックをダウンロードした後、ステップＢ−９に進む。
【００７１】
ステップＢ−８またはステップＢ−１２において、デコード不可と判断された場合は、マルチファンクション端末装置１０に受信データに対応するデコード用のドライバプログラムがないと判断して、図７に示すフローＤへ進む。
【００７２】
まず、ステップＤ−１で、デコード用のドライバプログラムをドライバサーバ２−１８からダウンロードして更新するかどうかを判断する。更新するかどうかは、例えば、現在インストールされているドライバプログラムの作成日時から所定期間を経過しているか否かで判断する。更新しない場合にはステップＤ−５に進む。
【００７３】
ドライバプログラムをダウンロードするためには無線携帯端末２−２を用いて発呼する必要があるため、ステップＢ−２で行った相互認証の結果を用いるようにしてもよい。
【００７４】
ドライバプログラムをダウンロードする場合、まずサービスデータベース２−２０に問い合わせを行い、必要なドライバプログラムが保管してあるドライバサーバ２−１８のＩＰアドレスを取得し、ＩＰ網２−１６経由でドライバサーバ２−１８にアクセスする（ステップＤ−２）。
【００７５】
ステップＤ−３で、デコードに必要なドライバプログラムがあるか否かを判断し、ある場合にはそのプログラムをダウンロードする（ステップＤ−４）。デコードに必要なドライバソフトがなかった場合は、デコードできなかった旨を表示部１−６に表示し、ユーザに告知する（ステップＤ−５）。
【００７６】
この処理はあらかじめ決められた時間毎にドライバプログラムがアップグレードされていないか確認し、必要に応じてダウンロードするようにしてもよい。
【００７７】
図６は、図５のステップＢ−９においてデコードされたデータのマルチファンクション端末の処理を示すフローチャートである。
【００７８】
まず、ステップＣ−１で、マルチファンクション端末装置１０にダウンロードされたデータがプリント用のファイルであるか否かを、例えば画像の解像度に基づいて判断する。例えば、画像の解像度が所定値よりも大きい場合には、表示部１−６で表示するにはサイズが大きすぎて不適当であるため表示部に表示させるのではなくプリントしたほうがよいので、この画像はプリント用のファイルであると判断する。ここで、ダウンロードされたデータがプリント用のファイルでなかった場合には、ステップＣ−２に進み、デコードしたデータの内容をユーザに知らせたり次の処理を選択させる目的で、デコードしたデータを表示用ドライバプログラムを用いて表示部１−６に表示する。その後、ステップＣ−３に進む。一方、ダウンロードされたデータがプリント用のファイルであった場合には、そのままステップＣ−３に進む。
【００７９】
ステップＣ−３はプリンタ部１−１２へデータを転送し印字（ｐｒｉｎｔ ｏｕｔ）するか否かを判断するブロックであり、ステップＣ−１でプリントファイルと判断された場合、および、ステップＣ−２で選択的に印字を選択された場合、にステップＣ−４に進み、そうでなければステップＣ−７に進むことになる。
【００８０】
ステップＣ−４では、操作部１−５よりプリントアウトする画像を選択、編集し、プリントアウトの設定を行う。そして、ステップＣ−５で内蔵のプリンタドライバを用いプリントデータが作成され、ステップＣ−６で、プリンタ部１−１２にプリントデータが転送されてプリントアウトされる。
【００８１】
次に、図５に示したフローに従いマルチファンクション端末装置１０でデコードしたデータを無線携帯端末２−２に送信すべきかどうかを、例えばユーザ設定の内容（デコード後のデータを無線携帯端末２−２に送信する／しない）に基づいて判断する（ステップＣ−７）。無線携帯端末２−２に送信すべきと判断された場合にはステップＣ−８に進み、ステップＣ−８デコード後のデータを無線携帯端末２−２に転送した後、ステップＣ−９に進む。ステップＣ−７で無線携帯端末２−２に送信しないと判断された場合にはそのままステップＣ−９に進む。このため、無線携帯端末２−２は転送されてきたデコード後のデータの内容を表示し、および／または、記憶することが可能になる。
【００８２】
ステップＣ−９では、マルチファンクション端末装置１０にダウンロードされたデータを記録部１−９に保存するかどうか判断する。ここで、保存の必要がない場合にはステップＣ−１０に進み、データを消去する。保存の必要がある場合にはステップＣ−１１に進み、データを所定の記録媒体に保存する。なお、ここではダウンロードしたデータをデコードできたか否かにかかわりなく保存するようにしてもよい。
【００８３】
また、デコードしたデータで保存するとデータサイズが大きくなり、格納に不利な場合はデコード前のデータで保存し、必要に応じてデコードするようにするとよいであろう。
【００８４】
また、受信したメール固有のＭｅｓｓａｇｅ−ＩＤを保存データまたは保存データのインデックスに付加することにより、無線携帯端末２−２からデータを消去した場合もメールの受信順にデータをソートすることが可能になる。
【００８５】
また、カラー画像ファイルを無線携帯端末２−２が受信したとき、無線携帯端末２−２で表示可能なモノクロデータにデコード・表示し、受信したデータを保存するようにしてもよい。この場合、マルチファンクション端末装置１０に接続されたときには、受信データをデコードしカラーで表示する。
【００８６】
以上の実施形態によれば、無線携帯端末２−２が自身ではデコードできないデータを受信した場合、マルチファンクション端末装置１０が代わってそのデータをデコードする。さらに、デコードされたデータは無線携帯端末２−２に転送される。これにより、無線情報端末２−２は、自身でデコードできなかったデータの内容を表示し保持することが可能になる。
【００８７】
以上、本発明の実施形態を詳述したが、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタ等）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機、ファクシミリ装置等）に適用してもよい。
【００８８】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（図４および／または図５〜７に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムを読み出して実行することによっても達成される場合を含む。
【００８９】
したがって、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【００９０】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【００９１】
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ等）、光磁気ディスク、磁気テープ、メモリカード等がある。
【００９２】
その他、プログラムの供給方法としては、インターネットを介して本発明のプログラムをファイル転送によって取得する態様も含まれる。
【００９３】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介して暗号化を解く鍵情報を取得させ、その鍵情報を使用することで暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００９４】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現され得る。
【００９５】
さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【００９６】
【発明の効果】
本発明によれば、通信端末自身がデコードできないデータを受信した場合でも、別の装置の支援を受けてそのデータをデコードし、通信端末においてメッセージの内容を確認することのできる通信システム、通信端末およびその制御方法を提供することができる。
【図面の簡単な説明】
【図１】実施形態におけるマルチファンクション端末装置の構成を示すブロック図である。
【図２】実施形態に係る通信システムを示す図である。
【図３】実施形態における電子メールデータの内容の一例を示す図である。
【図４】電子メールを受信した無線携帯端末の動作を示すフローチャートである。
【図５】無線携帯端末が接続されたときのマルチファンクション端末の動作を示すフローチャートである。
【図６】実施形態におけるデータのデコード後のマルチファンクション端末の処理を示すフローチャートである。
【図７】対象データのデコードが不可と判断されたときのマルチファンクション端末の処理を示すフローチャートである。
【図８】実施形態に係る無線携帯端末のハードウェア構成を示すブロック図である。
Claims (7)
- ネットワークを介してメッセージを送受可能な通信端末と、その通信端末と接続可能なデータ処理装置とを含む通信システムであって、
前記通信端末は、
受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているか否かを判断する判断手段と、
前記受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているときは、そのデータを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのデータをデコードするよう指示する指示手段と、
を備え、
前記データ処理装置が、
前記指示手段の指示に応じて、前記データを取得する取得手段と、
取得した前記データをデコードするデコード手段と、
前記デコード手段によりデコードしたデータを前記通信端末に送信する送信手段と、
を備えることを特徴とする通信システム。 - 前記通信端末は、更に、
前記メッセージの受信時に前記データ処理装置との通信が確立していなかったときは、前記受信したメッセージの所定のフィールド情報のみを前記メモリに記憶するよう制御する制御手段を備えることを特徴とする請求項１に記載の通信システム。 - 前記取得手段は、前記通信端末との通信が確立したときに、前記制御手段によって前記メモリに記憶された前記フィールド情報に基づいて前記データを取得することを特徴とする請求項２に記載の通信システム。
- ネットワークを介してメッセージを送受可能な通信端末に接続されたデータ処理装置であって、
前記通信端末が受信したメッセージに当該通信端末でデコードできない属性のデータが含まれていること示す指示信号を検出する検出手段と、
前記検出手段により前記指示信号を検出したときに、前記データを取得する取得手段と、
取得した前記データをデコードするデコード手段と、
前記デコード手段によりデコードしたデータを前記通信端末に送信する送信手段と、
を備えることを特徴とするデータ処理装置。 - 前記取得手段は、前記通信端末との通信が確立したときに、前記通信端末に記憶されている受信データの前記フィールド情報に基づいて前記データを取得することを特徴とする請求項４に記載のデータ処理装置。
- ネットワークを介してメッセージを送受可能な通信端末に接続されたデータ処理装置の制御方法であって、
前記通信端末が受信したメッセージに当該通信端末でデコードできない属性のデータが含まれていること示す指示信号を検出する検出ステップと、
前記検出ステップで前記指示信号を検出したときに、前記データを取得する取得ステップと、
取得した前記データをデコードするデコードステップと、
前記デコードステップでデコードしたデータを前記通信端末に送信する送信ステップと、
を有することを特徴とするデータ処理装置の制御方法。 - ネットワークを介してメッセージを送受可能な通信端末に接続されたデータ処理装置を制御するためのプログラムあって、
前記通信端末が受信したメッセージに当該通信端末でデコードできない属性のデータが含まれていること示す指示信号を検出する検出ステップ、
前記検出ステップで前記指示信号を検出したときに、前記データを取得する取得ステップ、
取得した前記データをデコードするデコードステップ、
前記デコードステップでデコードしたデータを前記通信端末に送信する送信ステップ
を実行させるプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002201146A JP2004046411A (ja) | 2002-07-10 | 2002-07-10 | 通信システム、データ処理装置およびその制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002201146A JP2004046411A (ja) | 2002-07-10 | 2002-07-10 | 通信システム、データ処理装置およびその制御方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004046411A true JP2004046411A (ja) | 2004-02-12 |
Family
ID=31707766
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002201146A Withdrawn JP2004046411A (ja) | 2002-07-10 | 2002-07-10 | 通信システム、データ処理装置およびその制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004046411A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006039639A (ja) * | 2004-07-22 | 2006-02-09 | Ricoh Co Ltd | 情報処理端末利用装置、アプリケーション搭載方法、アプリケーション搭載プログラム及びアプリケーション搭載プログラムが記憶された記憶媒体 |
| JP2011525061A (ja) * | 2008-05-05 | 2011-09-08 | クゥアルコム・インコーポレイテッド | 保存済みまたは新着メッセージの検証 |
-
2002
- 2002-07-10 JP JP2002201146A patent/JP2004046411A/ja not_active Withdrawn
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006039639A (ja) * | 2004-07-22 | 2006-02-09 | Ricoh Co Ltd | 情報処理端末利用装置、アプリケーション搭載方法、アプリケーション搭載プログラム及びアプリケーション搭載プログラムが記憶された記憶媒体 |
| JP2011525061A (ja) * | 2008-05-05 | 2011-09-08 | クゥアルコム・インコーポレイテッド | 保存済みまたは新着メッセージの検証 |
| US8498416B2 (en) | 2008-05-05 | 2013-07-30 | Qualcomm Incorporated | Validation of stored or incoming messages |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7616336B2 (en) | Network facsimile system with relaying server | |
| US6658456B1 (en) | Electric mail transferring apparatus and electric mail transferring method | |
| US8489771B2 (en) | Address book transmission program, address book transmission method, and address server | |
| JP2002171291A (ja) | サーバ装置及び電子メールの送信制御方法 | |
| JP2002135505A (ja) | ネットワークファクシミリ装置 | |
| JP2004046411A (ja) | 通信システム、データ処理装置およびその制御方法 | |
| JP2004046410A (ja) | 通信システム、通信端末およびデータ処理装置、ならびに制御方法 | |
| JP3653606B2 (ja) | ネットワークファクシミリ装置の制御方法 | |
| JP4067461B2 (ja) | ファクシミリ通信システム、通信端末装置および通信システム | |
| JP2003032169A (ja) | マルチファンクション端末およびデータ処理システム | |
| JP2001236274A (ja) | ネットワークファクシミリ装置およびその制御方法およびネットワークファクシミリ送信装置およびネットワークファクシミリ受信装置 | |
| JP2001265698A (ja) | ネットワークファクシミリ装置 | |
| JP2003008766A (ja) | マルチファンクション装置、無線携帯端末装置およびデータ処理システム | |
| JP4167110B2 (ja) | 画像形成装置の制御方法および画像形成装置 | |
| JP3944602B2 (ja) | ファクシミリ装置 | |
| JP2004362057A (ja) | 通信端末装置、コンピュータプログラム及び記録媒体 | |
| JPH11338807A (ja) | 情報処理装置 | |
| JP2003023488A (ja) | マルチファンクション端末装置 | |
| JP2005159698A (ja) | 画像通信装置、画像通信装置の制御方法、および画像通信装置の制御プログラム | |
| JP2000181820A (ja) | ファクシミリ装置 | |
| JP2004038532A (ja) | 携帯通信端末 | |
| JP2003091486A (ja) | 通信端末装置 | |
| JP2004187026A (ja) | メール受信装置 | |
| JP2008109675A (ja) | 通信端末装置 | |
| JP2003023477A (ja) | マルチファンクション端末装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20051004 |