(57)【要約】【課題】通信システムにおいて通信端末自身がデコードできないデータを受信した場合でも、別の装置の支援を受けてそのデータをデコードし所定の処理を行うことが容易にできるようにすること。【解決手段】通信端末はデータ処理装置と接続可能に構成される。この通信端末は、受信したデータに当該通信端末でデコードできない属性のファイルが含まれているか否かを判断し（Ａ−６）、受信したデータに当該通信端末でデコードできない属性のファイルが含まれているときは、そのファイルを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのファイルをデコードするよう指示する（Ａ−１８）。【選択図】　図４
2004046410.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してメッセージを送受可能な通信端末と、その通信端末と接続可能なデータ処理装置とを含む通信システムであって、
前記通信端末は、
受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているか否かを判断する判断手段と、
前記受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているときは、そのデータを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのデータをデコードするよう指示する指示手段と、
を備え、
前記データ処理装置が、
前記指示手段の指示に応じて、前記データを取得する取得手段と、
取得した前記データをデコードするデコード手段と、
を備えることを特徴とする通信システム。
【請求項２】
前記通信端末は、更に、
前記メッセージの受信時に前記データ処理装置との通信が確立していなかったときは、前記受信したメッセージの所定のフィールド情報のみを前記メモリに記憶するよう制御する制御手段を備えることを特徴とする請求項１に記載の通信システム。
【請求項３】
前記取得手段は、前記通信端末との通信が確立したときに、前記制御手段によって前記メモリに記憶された前記フィールド情報に基づいて前記データを取得することを特徴とする請求項２に記載の通信システム。
【請求項４】
ネットワークを介してメッセージを送受可能に構成されるとともにデータ処理装置と接続可能に構成された通信端末であって、
受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているか否かを判断する判断手段と、
前記受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているときは、そのデータを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのデータをデコードするよう指示する指示手段と、
を備えることを特徴とする通信端末。
【請求項５】
更に、
前記メッセージの受信時に前記データ処理装置との通信が確立していなかったときは、前記受信したメッセージの所定のフィールド情報のみを前記メモリ記憶するよう制御する制御手段を備えることを特徴とする請求項４に記載の通信端末。
【請求項６】
ネットワークを介してメッセージを送受可能に構成されるとともにデータ処理装置と接続可能に構成された通信端末の制御方法であって、
受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているか否かを判断する判断ステップと、
前記受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているときは、そのデータを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのデータをデコードするよう指示する指示ステップと、
を有することを特徴とする通信端末の制御方法。
【請求項７】
更に、
前記メッセージの受信時に前記データ処理装置との通信が確立していなかったときは、前記受信したメッセージの所定のフィールド情報のみを前記メモリに記憶するよう制御する制御ステップを有することを特徴とする請求項６に記載の通信端末の制御方法。
【請求項８】
ネットワークを介してメッセージを送受可能に構成されるとともにデータ処理装置と接続可能に構成された通信端末を制御するためのプログラムであって、
受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているか否かを判断する判断ステップ、
前記受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているときは、そのデータを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのデータをデコードするよう指示する指示ステップ、
を実行させるプログラム。
【請求項９】
ネットワークを介してメッセージを送受可能な通信端末に接続されたデータ処理装置であって、
前記通信端末が受信したメッセージに前記通信端末でデコードできない属性のデータが含まれていること示す指示信号を検出する検出手段と、
前記検出手段により前記指示信号を検出したときに、前記データを取得する取得手段と、
取得した前記データをデコードするデコード手段と、
を備えることを特徴とするデータ処理装置。
【請求項１０】
ネットワークを介してメッセージを送受可能な通信端末に接続されたデータ処理装置の制御方法であって、
前記通信端末が受信したメッセージに当該通信端末でデコードできない属性のデータが含まれていること示す指示信号を検出する検出ステップと、
前記検出ステップで前記指示信号を検出したときに、前記データを取得する取得ステップと、
取得した前記データをデコードするデコードステップと、
を有することを特徴とするデータ処理装置の制御方法。
【請求項１１】
ネットワークを介してメッセージを送受可能な通信端末に接続されたデータ処理装置を制御するためのプログラムあって、
前記通信端末が受信したメッセージに当該通信端末でデコードできない属性のデータが含まれていること示す指示信号を検出する検出ステップ、
前記検出ステップで前記指示信号を検出したときに、前記データを取得する取得ステップ、
取得した前記データをデコードするデコードステップ、
を実行させるプログラム。
【請求項１２】
メッセージを送受信可能な通信端末であって、
データ処理装置を接続する接続手段と、
受信したメッセージに当該通信端末でデコードできないデータが含まれているか否かを判別する判別手段と、
当該通信端末でデコードできないデータが前記メッセージに含まれている場合は、前記データ処理装置に前記データをデコードさせるように制御する制御手段と、
を備えることを特徴とする通信端末。
【請求項１３】
前記制御手段は、前記データ処理装置が接続されていない場合は、前記データ処理装置が接続された際に、前記データが前記データ処理装置に送信されるようにして前記データを記憶することを特徴とする請求項１２に記載の通信端末。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信システム、通信端末およびデータ処理装置、ならびに制御方法に関するものである。
【０００２】
【従来の技術】
無線携帯端末等の通信端末は、ネットワークを経由してサーバから各種データを取得することが可能である。最近では、電子メール機能により電子メールデータを自動受信することができるようになっている。電子メールは各種アプリケーションで作成されたファイルを添付ファイルとして送信することも可能になっている。
【０００３】
【発明が解決しようとする課題】
ところが、添付ファイルとして送られてきたもののすべてが無線携帯端末でデコード可能であるとは限らない。デコードできないデータを端末が記憶していることは無駄であるから、そのようなデータを自動的に破棄させることも考えられるが、他の装置の補助を受けてでもデコードできないメッセージの内容を見たいというニーズもある。
【０００４】
そこで、本発明は、通信システムにおいて通信端末自身がデコードできないデータを受信した場合でも、別の装置の支援を受けてそのデータをデコードし所定の処理を行うことが容易にできるようにすることを目的としている。
【０００５】
【課題を解決するための手段】
本発明の一側面は、ネットワークを介してメッセージを送受可能な通信端末と、その通信端末と接続可能なデータ処理装置とを含む通信システムに係る。この通信システムにおいて、前記通信端末は、受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているか否かを判断し、前記受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているときは、そのデータを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのデータをデコードするよう指示する。そして、前記データ処理装置は、前記指示手段の指示に応じて、前記データを取得し、取得した前記データをデコードする。
【０００６】
本発明の別の側面は、ネットワークを介してメッセージを送受可能に構成されるとともにデータ処理装置と接続可能に構成された通信端末およびその制御方法に係る。この通信端末は、受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているか否かを判断し、受信したメッセージに当該通信端末でデコードできない属性のデータが含まれているときは、そのデータを当該通信端末内のメモリに記憶する代わりに、前記データ処理装置にそのデータをデコードするよう指示する。かかる制御方法はプログラムによっても実現されうる。
【０００７】
本発明のさらに別の側面は、ネットワークを介してメッセージを送受可能な通信端末に接続されたデータ処理装置およびその制御方法に係る。このデータ処理装置は、前記通信端末が受信したメッセージに当該通信端末でデコードできない属性のデータが含まれていること示す指示信号を検出し、前記指示信号を検出したときに、前記データを取得し、取得した前記データをデコードする。かかる制御方法はプログラムによっても実現されうる。
【０００８】
本発明の別の側面は、メッセージを送受信可能な通信端末に係る。この通信端末は、受信したメッセージに当該通信端末でデコードできないデータが含まれているか否かを判別し、当該通信端末でデコードできないデータが前記メッセージに含まれている場合は、前記データ処理装置に前記データをデコードさせるように制御する。
【０００９】
【発明の実施の形態】
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。
【００１０】
図１は、実施形態におけるデータ処理装置としてのマルチファンクション端末装置の構成を示すブロック図である。このマルチファンクション端末装置は、後述するように通信端末としての無線携帯端末と接続し、無線携帯端末からのデータを表示、印刷、記憶等することができるように構成されている。
【００１１】
マルチファンクション端末装置１０は、図示のように、ＣＰＵ１−１、ＲＯＭ１−２、ＲＡＭ１−３、不揮発性ＲＡＭ１−４、操作部１−５、表示部１−６、符号・復号部１−７、読取り部１−８、記録部１−９、駆動部１−１０、ＭＯＤＥＭ部１−１１、プリンタ部１−１２、Ａ／Ｄ変換部１−１３、スピーカ部１−１４、Ｉ／Ｆ部１−１５を有する。
【００１２】
ＣＰＵ１−１は、ＲＯＭ１−２に記憶されているプログラムに従って装置全体の制御を行う。プログラムを格納するＲＯＭ部１−２は、フラッシュメモリのような書き換え可能なメモリでも構わない。ＲＡＭ１−３は、無線携帯端末からＩ／Ｆ部１−１５経由で受け取ったデータや、符号・復号部１−７、Ａ／Ｄ部１−１３、記録部１−９、読取り部１−８、プリンタ部１−１２で処理するデータの格納を行うのに用いる。
【００１３】
不揮発性ＲＡＭ１−４は、無線携帯端末の認証に関する各種情報や、端末固有の情報をはじめ、各種デコード処理に必要なプログラムの全部または一部、ダウンロードされた最新のアプリケーションソフト等を格納するのに用いられる。
【００１４】
操作部１−５は、無線携帯端末からのデータをメニュー表示させる「メニューボタン」、メニューからどのデータを処理させるかを決める「選択操作」、選択したデータをどのように処理するかを決める「選択操作」などを有する。表示部１−６と一体化させタッチパネルなどを使うようにしても構わない。
【００１５】
表示部１−６は、各種操作を補助するためのメニュー表示、受信データのうち表示選択されたデータの表示等に使用される。
【００１６】
符号・復号部１−７は、受信したデータのタイプによって決定される符号・復号プログラムにより演算処理する。高速演算が必要なため符号・復号部内部に専用のＲＯＭ、ＲＡＭ、演算回路を有する構成が好ましい。また、演算回路（例えばＤＳＰ）でのデコードに必要なプログラムを、ネットワーク経由で更新できるようにしてもよい。なお、ＣＰＵの充分に処理能力が高い場合は、この符号・復号部１−７の機能をＣＰＵ１−１に担わせるようにしても構わない。
【００１７】
読取り部１−８は原稿をスキャンする光学系部品で構成され、原稿の内容を電子データとして変換する。ここでスキャンされたアナログ信号をＡ／Ｄ変換し、以後の処理に必要なデータ形式に符号・複号部１−７で変換する。
【００１８】
記録部１−９は、ハードディスク、半導体メモリまたはテープなどで構成され、無線携帯端末経由で受信したデータを保存するために用いられる。ＲＡＭ部１−３との容量・価格・アクセスタイムのバランスを考慮した記録媒体を用いることが望ましい。
【００１９】
駆動部１−１０は読み取り部１−８、プリンタ部１−１２の各種モータを駆動する。
【００２０】
モデム部１−１１は、無線携帯端末経由でアナログ変調された変調波を送受信する（いわゆる見なし音声通信）場合の変調／復調を行う。
【００２１】
プリンタ部１−１２は、受信したデータ、読取ったデータをプリントアウトするのに用い、ＬＢＰ、インクジェット、熱転写などいずれの方式を用いてもよい。
【００２２】
Ａ／Ｄ変換部１−１３は受信した音データをアナログ信号に変換や、各種操作音を生成するために用いる。モデム部１−１１のＡ／Ｄ変換回路と共有するようにしても良い。
【００２３】
スピーカ部１−１４はＡ／Ｄ変換部１−１３で変換されたアナログ信号をスピーカにより可聴音として再生する。
【００２４】
Ｉ／Ｆ部１−１５は、無線携帯端末との通信および充電を行うインターフェイス部分であり、複数の無線携帯端末を接続できるようにしても構わない。インターフェイスの通信仕様は有線でも無線でも構わないが、本実施形態ではシリアル通信でデータ送受を行う。
【００２５】
また、ＲＯＭ１−２には、例えば、このマルチファンクション端末装置１０でデコード可能な画像データの形式（ＧＩＦ、ＪＰＥＧ、ＢＭＰなど）を記述したサポートフォーマット一覧テーブルが記憶されている。
【００２６】
次に、電子メールに添付された画像データを、マルチファンクション端末装置で出力・再生する際の動作について説明する。
【００２７】
図２は、実施形態に係る上記マルチファンクション端末装置１０を含む通信システムを示す図である。
【００２８】
同図において、２−２がマルチファンクション端末装置１０と接続可能な無線携帯端末であり、２−３は、画像入力装置（例えばデジタルカメラ）２−４と接続可能な別の無線携帯端末である。２−５および２−１１は無線携帯端末と無線通信を行う基地局、２−６、２−１０はＲＮＣ（Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワーク制御装置）であり、図示の如く、この基地局２−１１とＲＮＣ２−１０、基地局２−５とＲＮＣ２−６でそれぞれＲＡＮ（Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ：無線アクセス網）２−９ａ、２−９ｂを構成する。
【００２９】
また、ＣＮ（ｃｏｒｅ　ｎｅｔｗｏｒｋ：コアネットワーク）２−７にはＲＡＮ２−９ａ、２−９ｂをはじめ、次に掲げるノードが接続されている。
【００３０】
加入者の情報や認証を行うマネージメントサーバ２−８、
ＣＮ２−７のメールを管理するメールサーバ２−１５、
各種ドライバプログラムを格納したドライバサーバおよびパケット処理のアドレス解決（ＤＮＳ）サーバとして機能するサービスデータベース２−２０、そして、
ＩＰ網２−１６、ＰＤＣ網２−２１、ＰＨＳ網２−２２、ＰＳＴＮ網２−２３、ＩＳＤＮ網２−２４といった各種通信ネットワーク。
【００３１】
デジタルカメラ２−１２を接続可能なパーソナルコンピュータ（ＰＣ）２−１３は、ＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）２−１４を経由してＩＰ網２−１６に接続される。ＩＰ網２−１６にはこの他、各種サービスのコンテンツを格納したコンテンツサーバ２−１７、各種アプリケーションの最新ドライバを格納したドライバサーバ２−１８、そしてＷＷＷサーバ２−１９が接続されている。
【００３２】
図１１は、無線携帯端末２−２のハードウェア構成を示すブロック図である。２０１は端末全体の動作を制御するＣＰＵ、２０２はデータおよびプログラムを記憶するメモリ、２０４は操作パネル、２０５は液晶表示器などの表示器、２０９は変調信号−無線電波の変換を行うＲＦユニット、２０８はＱＰＳＫ（Ｑｕａｄｕｒａｔｕｒｅ　Ｐｈａｓｅ　Ｓｈｉｆｔ　Ｋｅｙｉｎｇ）などによりチャネルデータを変復調するモデム、２０７はデジタル音声−無線チャネルＩ／Ｆデータの変換を行うチャネルコーデック、２０６はＡＤＰＣＭ（Ａｄａｐｔｉｖｅ　Ｄｉｆｆｅｒｅｎｔｉａｌ　Ｐｕｌｓｅ　Ｃｏｄｅｄ　Ｍｏｄｕｌａｔｉｏｎ）などによりアナログ音声−デジタル音声の変換を行うコーデック、２１２はスピーカ、２１３はマイクロホン、そして、２１４は例えばシリアルＩ／Ｆなどのマルチファンクション端末装置１０とのＩ／Ｆ回路である。
【００３３】
無線携帯端末２−２は典型的には例えばＰＨＳで実現され、かかる端末では諸種の動作設定をユーザからの指示により行うこと（ユーザ設定）ができるように構成されていることは周知のとおりである。本実施形態における無線携帯端末２−２のユーザ設定項目には、受信したメールの内容をこの無線携帯端末２−２においてデコードするかどうかの選択が含まれる。また、メモリ２０２には、例えば、この無線携帯端末２−２でデコード可能な画像データの形式（ＧＩＦ、ＪＰＥＧ、ＢＭＰなど）を記述したサポートフォーマット一覧テーブルが記憶されている。
【００３４】
上記した構成の通信システムにおける動作の一例として、ユーザＢの無線携帯端末２−３が、デジタルカメラ２−４からの画像データを、ユーザＡの無線携帯端末２−２に送信する場合の動作について説明する。
【００３５】
無線携帯端末２−３において無線携帯端末２−２の宛先を指定して発呼すると、公知の手段で基地局２−５と通信を行う。ＲＮＣ２−６およびＣＮ２−７を管理するマネージメントサーバ２−８により、無線携帯端末２−２を収容するＲＡＮ（すなわちＲＡＮ２−９）の選択を行い、そこにデータを送信することになる。
【００３６】
ＲＮＣ２−１０および基地局２−１１経由でデータを受信した無線携帯端末２−２は、受信したデータ中のヘッダ情報に基づいて画像データを抽出し、あらかじめプログラムされてあるデコードプログラムによりファイルを画像データに展開し、無線携帯端末２−２に内蔵の表示用ドライバプログラムによってその表示部に表示する。各無線携帯端末は相手先の無線携帯端末を想定した最適な画像フォーマットでデータ転送すればよい。ＰＣで一般的に使用されている画像フォーマットとしては、ＪＰＥＧやデジタルカメラの標準ファイル形式ＤＣＦ（Ｄｅｓｉｇｎ
ｒｕｌｅ　ｆｏｒ　Ｃａｍｅｒａ　Ｆｉｌｅ　ｓｙｓｔｅｍ）などがある。
【００３７】
次に、ユーザＣのＰＣ２−１３が、デジタルカメラ２−１２で撮影した画像を、ユーザＡの無線携帯端末２−２に送信する場合について説明する。
【００３８】
デジタルカメラ２−１２で撮影された画像ファイルは、ＰＣ２−１３で所定の加工がなされた後、電子メールプログラム（メールアプリケーション）により、ユーザＣのｔａｒｏ＠ｇａｎｏｎ．ｃｏ．ｊｐを送信元アドレス、ユーザＡのｈａｎａｋｏ＠ｘｘｘｘ．ｎｅ．ｊｐを送信先アドレスとする電子メールの添付ファイルとして送信される。
【００３９】
具体的には次のとおりである。ここで、画像ファイルの形式は例えばビットマップ（ＢＭＰ）形式のファイルであるとする。まず、ビットマップの画像ファイルはＰＣ２−１３のメールアプリケーションにおいてＴＩＦＦヘッダが付加され、さらにＭＩＭＥ（Ｍｕｌｔｉｐｌｅ　Ｉｎｔｅｒｎｅｔ　Ｍａｉｌ　Ｅｘｔｅｎｔｉｏｎｓ：多目的インターネット・メール拡張機能（ＲＦＣ１５２１で定義されている。））に従うエンコードを行ってＡＳＣＩＩの文字列としてメールに埋め込まれることになる。
【００４０】
元来、電子メールは７ｂｉｔ文字のキャラクタコードを送受信するのが前提になっていたため、８ｂｉｔ文字や１行の文字数の制限やメール全体のサイズの制限もあった。そこで、Ｂａｓｅ６４やＱｕｏｔｅｄ−ｐｒｉｎｔａｂｌｅを用いることにより、７ｂｉｔから８ｂｉｔコード化を行い、また、ＭＩＭＥによりメール本文に構造化機能を与えることができるようになった。これにより、添付ファイルデータはＭＩＭＥエンコードされ、ＡＳＣＩＩ　の文字列となることにより電子メールのプロトコルによって配送できる形式となる。
【００４１】
ＭＩＭＥはメールヘッダ部に新たなヘッダを追加することで実現される。ここで、ＭＩＭＥ用に新規追加されたヘッダの一部を示す。
【００４２】
Ｍｉｍｅ−Ｖｅｒｓｉｏｎ　　ＭＩＭＥ　のバージョン
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ　　データの種類
タイプ／サブタイプ；サブオプション
デフォルトは、
ｔｅｘｔ／ｐｌａｉｎ；ｃｈａｒｓｅｔ＝ＵＳ−ＡＳＣＩＩ
【００４３】
その後、送信先アドレスバッファの内容が宛先情報に設定され、電子メールがＳＭＴＰ（ＩＥＴＦにより勧告されたＳｉｍｐｌｅ　Ｍａｉｌ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）によりＩＳＰ２−１４内にあるＳＭＴＰサーバに送信される。ＩＰ網２−１６にある複数のメールサーバは、ＳＭＴＰサーバから転送されたメールをＳＭＴＰにより転送を続け、ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｅｒｖｅｒ）からＣＮ２−７のゲートウエイのＩＰアドレスを取得し、ルーティングしながらＣＮ２−７に到達させる。ＣＮ２−７を管理するマネージメントサーバ２−８は、転送されてきたメールデータをまずＣＮ２−７内のメールサーバ２−１５に格納する。
【００４４】
マネージメントサーバ２−８は、無線携帯端末２−２がどのＲＡＷに属しているか検索し、ＲＮＣ２−１０および基地局２−１１を経由して無線携帯端末２−２に対してメールサーバ２−１５に届いたメールをＳＭＴＰにより送信する。
【００４５】
あるいは、マネージメントサーバ２−８が無線携帯端末２−２がどのＲＡＷに属しているか検索してＲＮＣ２−１０にメールの到着を通知し、基地局２−１１が無線携帯端末２−２に対してメールサーバ２−１５に届いたメールの情報を通知する。そして、通知を受けた無線携帯端末２−２がメールサーバ２−１５にアクセスして、ＰＯＰ（Ｐｏｓｔ　Ｏｆｆｉｃｅ　Ｐｒｏｔｏｃｏｌ）により、スプールされたデータをダウンロードするようにしてもよい。
【００４６】
メールサーバ２−１５より受信した電子メールデータは、図３のようなメッセージ形式となる。同図中、
Ｍｅｓｓａｇｅ−Ｉｄ：　はメッセージ固有のＩＤ（識別番号）、
Ｘ−Ｓｅｎｄｅｒ：　は送信者のメールアドレス
Ｆｒｏｍ：ｔａｒｏ＠ｇａｎｏｎ．ｃｏ．ｊｐは送信者アドレス、
Ｔｏ：ｈａｎａｋｏ＠ｘｘｘｘ．ｎｅ．ｊｐは宛先アドレス、
Ｓｕｂｊｅｃｔはユーザが定義したメールのタイトル、
Ｍｉｍｅ−Ｖｅｒｓｉｏｎ：　１．０はＭＩＭＥのバージョンが１．０であることを宣言したものである。また、Ｘ−Ｍａｉｌｅｒ：　はメールアプリケーション名とそのバージョンを示すものである。
【００４７】
続くＣｏｎｔｅｎｔ−Ｔｙｐｅはデータの属性を示すものであり、例えばＣｏｎｔｅｎｔ−Ｔｙｐｅ：　ｔｅｘｔ／ｐｌａｉｎはテキストデータを示し、このあとのデータ属性がテキストであることを示している。このＣｏｎｔｅｎｔ−Ｔｙｐｅにはこの他、例えば以下の種類がある。
【００４８】
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：　ｔｅｘｔ／ｒｉｃｈｔｅｘｔはリッチテキストで書かれたテキストデータ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：　ａｕｄｉｏ／ｂａｓｉｃは８ｂｉｔ　μ法則でコード化された音声データ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：　ｖｉｄｅｏ／ｍｐｅｇはＭＰＥＧ１形式の動画データ、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：　ｉｍａｇｅ／ｔｉｆｆはＴＩＦＦ形式のイメージデータであることを示す。
【００４９】
次に、電子メールを受信した無線携帯端末２−２およびこの無線携帯端末２−２に接続されうるマルチファンクション端末装置１０の動作について、図４〜７のフローチャートを用いて説明する。
【００５０】
図４は、電子メールを受信した無線携帯端末２−２の動作を示すフローチャートである。
【００５１】
ステップＡ−１でメール（メッセージ）を受信した後、ユーザ設定の状態に基づき、メールの内容を無線携帯端末２−２においてデコードするか否かを判断する（ステップＡ−２）。メールの内容を無線携帯端末２−２においてデコードしない場合には、後述するステップＡ−１１に進む。一方、メールの内容を無線携帯端末２−２においてデコードする場合、受信したメールメッセージからＣｏｎｔｅｎｔ−Ｔｙｐｅを取得する（ステップＡ−３）。そして、取得したそのＣｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式であるか否かを判断する（ステップＡ−４）。Ｃｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式でない場合にはステップＡ−６に進むが、Ｃｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式である場合には、ＴＩＦＦヘッダからどのようなエンコードにより生成されたデータかが判断できるので、ステップＡ−５に進み、ＴＩＦＦヘッダを解析する。
【００５２】
ＴＩＦＦヘッダにあるタグにはデータの並び方をはじめ、主走査（Ｘ軸方向）、副走査（Ｙ軸方向）それぞれの画素数による画像サイズ情報、圧縮情報、解像度、ビットマップの形式、ＲＧＢのデータ並びの順序、スキャナのメーカー名・型名コード、画像あたりのサンプル数（カラー）などの情報が含まれている。ステップＡ−６では、このタグから取得した情報と無線携帯端末２−２のサポートフォーマット一覧テーブルと比較し、無線携帯端末２−２においてサポート可能か否か（すなわち、デコードが可能か否か）を判断する。また、Ｃｏｎｔｅｎｔ−ＴｙｐｅがＴＩＦＦ形式でない場合には、画像データのヘッダから確認されるフォーマット情報とサポートフォーマット一覧テーブルと比較し、無線携帯端末２−２においてサポート可能か否かを判断する。
【００５３】
無線携帯端末２−２でサポート不可と判断された場合にはそのままステップＡ−１１に進む。一方、無線携帯端末２−２でサポートできると判断された場合にはステップＡ−７に進み、Ｃｏｎｔｅｎｔ−Ｔｙｐｅならびにタグ情報に基づいてデコード後のデータが有効かどうかを判断する。判断の条件としては例えば次のようなものがある。
【００５４】
・無線携帯端末２−２のメモリで処理可能なデータサイズであるか。
・表示部で表示するのに適当な画素数および色空間であるか。
・無線携帯端末２−２での処理を期待していないデータ、たとえばプリントアウトを前提としたＤＰＯＦ（Ｄｉｇｉｔａｌ　Ｐｒｉｎｔ　Ｏｒｄｅｒ　Ｆｏｒｍａｔ）と呼ばれる印刷フォーマットデータやｐｒｎファイルであるか、等。
【００５５】
以上のような判断条件をいずれも満たさない場合にはステップＡ−１１に進む。他方、以上のような判断条件のいずれかを満たす場合にはステップＡ−８に進み、無線携帯端末２−２でデコードを実行し、表示などの所定の処理を行う（ステップＡ−９）。
【００５６】
続いてステップＡ−１１で、マルチファンクション端末（ＤＯＣＫ）２−１で処理を行うかどうかを次のように判断する。
【００５７】
まず、ステップＡ−６において無線携帯端末２−２でサポート不可と判断された場合で、なおかつ、マルチファンクション端末装置１０で処理をしない設定になっている場合は、ステップＡ−１２に進み、データを破棄し、ステップＡ−１３で、処理できないデータを受信し破棄した旨を通知し、処理を終了する。
【００５８】
一方、ステップＡ−６において無線携帯端末２−２でサポート不可と判断されたがマルチファンクション端末装置１０において処理をする設定になっている場合、あるいは、ステップＡ−７において無線携帯端末２−２でのデコード後のデータが有効でないと判断された場合は、ステップＡ−１４に進み、無線携帯端末２−２のＩ／Ｆレジスタにデータ有りのビット（ＤＬＲＱ　ｂｉｔ）を立て、その後、ステップＡ−１５で、Ｉ／Ｆ部にマルチファンクション端末装置１０が接続されているか否かを判断する。
【００５９】
Ｉ／Ｆ部にマルチファンクション端末装置１０が接続されている場合には、ステップＡ−１８に進み、リクエスト信号をイネーブルにする。
【００６０】
Ｉ／Ｆ部にマルチファンクション端末装置１０が接続されていない場合には、無線携帯端末２−２で解析した結果の情報を記憶する。具体的には、ステップＡ−１６で、メールメッセージのうちＭＩＭＥ形式ヘッダ部分のみを抽出してステップＡ−１７でメモリ部に保存する一方、その他の部分についてはステップＡ−１２と同様に消去する。この消去により携帯端末の記憶領域を確保でき、その後の通信で記憶領域を最適に使用できる。
【００６１】
図５は、無線携帯端末２−２が接続されたときのマルチファンクション端末装置１０の動作を示すフローチャートである。
【００６２】
ステップＢ−１では、Ｉ／Ｆ部１−１５（図１を参照）に無線携帯端末２−２が接続されたことを確認する。Ｉ／Ｆ部１−１５が充電機能を備えている場合には、充電回路の電圧監視回路を用いて無線携帯端末２−２が接続されたことを判定し、ＰＣＭＣＩＡ経由で無線携帯端末２−２との交信を開始することができる。
【００６３】
まず、無線携帯端末２−２の電話番号、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ　Ｉｄｅｎｔｉｆｙ　ｍｏｄｕｌｅ）のＰＩＮ（Ｐｅｒｓｏｎａｌ　Ｉｄｅｎｔｙ　Ｎｕｍｂｅｒ）情報などから以後のフローの処理を実行してよいかの相互認証を行う（ステップＢ−２）。次に、無線携帯端末２−２のステータスレジスタを確認し（ステップＢ−３）、図４のステップＡ−１４において設定されるＤＬＲＱ　ｂｉｔが立っているか否かを調べることでステップＢ−５以下の処理を行うかどうかを判断する（ステップＢ−４）。なお、無線携帯端末２−２が接続されたままの状態の場合には、上記のステップＡ−１８で無線携帯端末２−２より出されるリクエスト信号をトリガとして無線携帯端末２−２のステータスレジスタを確認するようにする。
【００６４】
ステップＢ−５では、無線携帯端末２−２の解析結果（例えば図４のステップＡ−６、Ａ−７）を利用するかどうかを判断する。
【００６５】
利用しない場合にはステップＢ−６に進み、無線携帯端末２−２を起動し、メールサーバ２−１５から該当するメールデータを受信する。この場合、無線端末２−２でいったんデータを受信した後にマルチファンクション端末で受信してもよいし、無線端末を通じて直接マルチファンクション端末で受信してもよい。
【００６６】
ダウンロードしたデータは図３と同じ形式であり、Ｍｉｍｅ−Ｖｅｒｓｉｏｎフィールドにおいて、ＭＩＭＥのバージョンを確認できる。Ｍｅｓｓａｇｅ−Ｉｄ、Ｘ−Ｍａｉｌｅｒ、Ｄａｔｅ、Ｔｏ、Ｆｒｏｍ、Ｓｕｂｊｅｃｔなどの各情報を取得した後、Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドからファイル属性を調べる（ステップＢ−７）。図示の例では、
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：　ｍｕｌｔｉｐａｒｔ／ｍｉｘｅｄ；ｂｏｕｎｄａｒｙ＝”ｂｏｕｎｄａｒｙ＿ｔａｒｏ”
と記述され、メッセージボディが複数のブロックから構成され（ｍｕｌｔｉｐａｒｔ）、”ｂｏｕｎｄａｒｙ＿ｔａｒｏ”という文字列の境界で区切られた複数のブロックを有し、各ブロックはそれぞれ独立していることがわかる。そして、図示のとおり、第１のブロックは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｔｅｘｔ／ｐｌａｉｎとして、その内容はプレーンなテキストであることが示されている。また、第２のブロックは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｉｍａｇｅ／ｔｉｆｆとして、その内容はＴＩＦＦ形式の画像データであることがわかる。さらに、第３のブロックは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｕｄｉｏ／ｂａｓｉｃとして、その内容は８ｂｉｔμ法則でコード化された音声データであることがわかる。
【００６７】
ここでは、第２のブロックに格納されているＴＩＦＦフォーマットされたＢＭＰファイルを例に説明する。ＴＩＦＦはひとつのタグ（ＴＡＧ）と複数のディレクトリから構成されている。ヘッダは先頭のディレクトリをポインタで示し、各ディレクトリは次のディレクトリをポインタで指し示し最終ポインタとして０が格納されている。
【００６８】
以下にＴＩＦＦに含まれる情報の一例をあげる。
【００６９】
ｉｍａｇｅ　ｗｉｄｔｈＴＡＧ（ＩＤ：０ＦＦ）とｉｍａｇｅ　ｌｅｎｇｔｈＴＡＧ（ＩＤ：１０１）の大きさ（ピクセル数）から、画像データの大きさを判断できる。ｓａｍｐｌｅ　ｐｅｒ　ｂｉｔＴＡＧ（ＩＤ：１１５）とｂｉｔ　ｐｅｒｓａｍｐｌｅＴＡＧ（ＩＤ：１０２）より、モノクロデータであるか、何ビット幅のカラーデータであるかを判断できる。また、データが圧縮されているかどうかはｃｏｍｐｒｅｓｓｉｏｎＴＡＧ（ＩＤ：１０３）を調べることにより判断でき、データ圧縮の方式はｃｏｍｐｒｅｓｓｉｏｎＴＡＧ（ＩＤ：２５９）を調べることにより判断できる。画像データの場所はｓｔｒｉｐ　ｏｆｆｓｅｔＴＡＧ（ＩＤ：１１１）に格納されているファイル内のオフセットを参照する。
【００７０】
以上のように解析した情報をマルチファンクション端末装置１０のサポートフォーマット一覧テーブルと比較し、デコード可能かどうかを判断する（ステップＢ−８）。
【００７１】
デコード可能な場合、この解析情報をもとにｂｏｕｎｄａｒｙ＿ｔａｒｏで区切られたブロック毎にデコードを行う（ステップＢ−９）。ｍｕｌｔｉｐａｒｔ／ｍｉｘｅｄの場合には、それぞれのＣｏｎｔｅｎｔ−Ｔｙｐｅがデコード可能か否かを個別に判断する。そして、マルチファンクション端末装置１０で処理可能なものはｂｏｕｎｄａｒｙ＝”ｂｏｕｎｄａｒｙ＿ｔａｒｏ”で区切られたブロックを切り出す。
【００７２】
上記のステップＢ−５で、無線携帯端末２−２の解析結果を利用する場合には、ステップＢ−１０に進み、無線携帯端末２−２の解析結果にＣｏｎｔｅｎｔ−Ｔｙｐｅの情報が含まれているかどうかを判断する。解析結果にＣｏｎｔｅｎｔ−Ｔｙｐｅの情報が含まれていない場合にはステップＢ−６に進む。一方、解析結果にＣｏｎｔｅｎｔ−Ｔｙｐｅの情報が含まれていた場合にはステップＢ−１１に進み、ステップＢ−７と同様にＣｏｎｔｅｎｔ−Ｔｙｐｅからファイル属性を解析する。さらに、ステップＢ−１２で、ステップＢ８と同様に、解析した情報をマルチファンクション端末装置１０のサポートフォーマット一覧テーブルと比較し、デコード可能かどうかを判断する。そして、ステップＢ−１３で、無線携帯端末２−２を起動し、メールサーバ２−１５から、該当するメールデータのうちデコード可能と判断されたブロックをダウンロードした後、ステップＢ−９に進む。
【００７３】
ステップＢ−８またはステップＢ−１２において、デコード不可と判断された場合は、マルチファンクション端末装置１０に受信データに対応するデコード用のドライバプログラムがないと判断して、図７に示すフローＤへ進む。
【００７４】
まず、ステップＤ−１で、デコード用のドライバプログラムをドライバサーバ２−１８からダウンロードして更新するかどうかを判断する。更新するかどうかは、例えば、現在インストールされているドライバプログラムの作成日時から所定期間を経過しているか否かで判断する。更新しない場合にはステップＤ−５に進む。
【００７５】
ドライバプログラムをダウンロードするためには無線携帯端末２−２を用いて発呼する必要があるため、ステップＢ−２で行った相互認証の結果を用いるようにしてもよい。
【００７６】
ドライバプログラムをダウンロードする場合、まずサービスデータベース２−２０に問い合わせを行い、必要なドライバプログラムが保管してあるドライバサーバ２−１８のＩＰアドレスを取得し、ＩＰ網２−１６経由でドライバサーバ２−１８にアクセスする（ステップＤ−２）。
【００７７】
ステップＤ−３で、デコードに必要なドライバプログラムがあるか否かを判断し、ある場合にはそのプログラムをダウンロードする（ステップＤ−４）。デコードに必要なドライバソフトがなかった場合は、デコードできなかった旨を表示部１−６に表示し、ユーザに告知する（ステップＤ−５）。
【００７８】
この処理はあらかじめ決められた時間毎にドライバプログラムがアップグレードされていないか確認し、必要に応じてダウンロードするようにしてもよい。
【００７９】
図６は、図５のステップＢ−９においてデコードされたデータのマルチファンクション端末の処理を示すフローチャートである。
【００８０】
まず、ステップＣ−１で、マルチファンクション端末装置１０にダウンロードされたデータがプリント用のファイルであるか否かを、例えば画像の解像度に基づいて判断する。例えば、画像の解像度が所定値よりも大きい場合には、表示部１−６で表示するにはサイズが大きすぎて不適当であるため表示部に表示させるのではなくプリントしたほうがよいので、この画像はプリント用のファイルであると判断する。ここで、ダウンロードされたデータがプリント用のファイルでなかった場合には、ステップＣ−２に進み、デコードしたデータの内容をユーザに知らせたり次の処理を選択させる目的で、デコードしたデータを表示用ドライバプログラムを用いて表示部１−６に表示する。その後、ステップＣ−３に進む。一方、ダウンロードされたデータがプリント用のファイルであった場合には、そのままステップＣ−３に進む。
【００８１】
ステップＣ−３はプリンタ部１−１２へデータを転送し印字（ｐｒｉｎｔ　ｏｕｔ）するか否かを判断するブロックであり、ステップＣ−１でプリントファイルと判断された場合、および、ステップＣ−２で選択的に印字を選択された場合、にステップＣ−４に進み、そうでなければステップＣ−７に進むことになる。
【００８２】
ステップＣ−４では、操作部１−５よりプリントアウトする画像を選択、編集し、プリントアウトの設定を行う。そして、ステップＣ−５で内蔵のプリンタドライバを用いプリントデータが作成され、ステップＣ−６で、プリンタ部１−１２にプリントデータが転送されてプリントアウトされる。
【００８３】
ステップＣ−７では、マルチファンクション端末装置１０にダウンロードされたデータを記録部１−９に保存するかどうかを、ユーザ設定の内容に基づいて判断する。ここで、保存の必要がない場合にはステップＣ−９に進み、データを消去する。保存の必要がある場合にはステップＣ−１０に進み、データを所定の記録媒体に保存する。なお、ここではダウンロードしたデータをデコードできたか否かにかかわりなく保存するようにしてもよい。
【００８４】
また、デコードしたデータで保存するとデータサイズが大きくなり、格納に不利な場合はデコード前のデータで保存し、必要に応じてデコードするようにするとよいであろう。
【００８５】
また、受信したメール固有のＭｅｓｓａｇｅ−ＩＤを保存データまたは保存データのインデックスに付加することにより、無線携帯端末２−２からデータを消去した場合もメールの受信順にデータをソートすることが可能になる。
【００８６】
また、カラー画像ファイルを無線携帯端末２−２が受信したとき、無線携帯端末２−２で表示可能なモノクロデータにデコード・表示し、受信したデータを保存するようにしてもよい。この場合、マルチファンクション端末装置１０に接続されたときには、受信データをデコードしカラーで表示する。
【００８７】
次に、図８〜図１０を用いて、無線携帯端末２−２で実現されるＰＯＰ（Ｐｏｓｔ　Ｏｆｆｉｃｅ　Ｐｒｏｔｃｏｌ）について説明する。
【００８８】
図８は、無線携帯端末のみで２件のメールを受信する場合のシグナリング図である。具体的には、図４のステップＡ−１に相当する処理であり、その後無線携帯端末のみでデコードするステップＡ−８を想定したものである。
【００８９】
図８において左側が無線携帯端末２−２、右側がメールサーバ２−１５である。ここでは、メール読み出しプロトコルであるＰＯＰのみについて述べ、他の処理については省略している。
【００９０】
まず、無線携帯端末２−２はＳＴＡＴ命令を発行し、これに対してメールサーバ２−１５はこの無線携帯端末２−２向けのメール数とメールの総容量を返す。具体的には、ＳＴＡＴ命令に対しＯＫレスポンスとこれにスペースをおいてメール数（図８では２件）、さらにスペースをおいて総容量（図８では３２０バイト）を知らせる。これにより無線携帯端末２−２はメールサーバ２−１５上の受信メール数とメールの容量を把握できる。
【００９１】
さらに、無線携帯端末２−２はＵＩＤＬ（Ｕｎｉｑｕｅ　ＩＤ　Ｌｉｓｔ）命令で、各メールのＩＤを聞き出す。メールサーバ２−１５からは、このレスポンスとして、ＯＫレスポンスのあとに、メール番号（同図中の１、２）とそれぞれのＩＤ（ｘｘｘｘｘｘｘｘとｙｙｙｙｙｙｙ）が返る。
【００９２】
さらに無線携帯端末２−２は、ＬＩＳＴ命令で、各メールの容量を把握する。メールサーバ２−１５からのレスポンスはＯＫレスポンス、および各メール番号とその容量となる。図の例では、１件目が１２０バイト、２件目が２００バイトであることがわかる。なお、メールサーバ２−１５から発行される“・”は、メールサーバ２−１５からのターミネイト信号であり、メールサーバ２−１５が送信を完了したことを示すものである。
【００９３】
ここまでの手順で、無線携帯端末２−２は、メールサーバ２−１５上のメール個数とその各容量を知ることができる。
【００９４】
さらに無線携帯端末２−２は、１件目のメールの送信をＲＥＴＲコマンドとそれに続くメール番号で要求し、メールサーバ２−１５はメールサイズを附随したＯＫレスポンスを返答したあとに、メール本体を送信し、最後にターミネイト信号を送信する。これにより、１件目のメールが無線携帯端末２−２に取り込まれ、ここで上述のステップＡ−６、Ａ−７の処理によって無線携帯端末２−２でデコード可能と判断されれば、必要に応じてデコードされ表示部１−６などで表示される。ここで、１件目のメールの処理が終了したため、図８の例では、ＤＥＬ命令とメール番号で、メールサーバ２−１５へメールの削除を求め、メールサーバ２−１５で削除されたことをＯＫレスポンスで判断する。さらに図８の例では２件目も受信し、これも無線携帯端末２−２でデコード可能と判断し、２件目の取り込み後に、１件目と同様の手段でメールサーバ２−１５から削除している。
【００９５】
このように、図８においては、メールサーバ２−１５に記憶された全てのメールが無線携帯端末２−２でデコード可能な場合を示した。
【００９６】
次に、図９を用いて、無線携帯端末２−２でデコードできない場合の処理を説明する。
【００９７】
図９において、１件目のメールは無線携帯端末２−２でデコード可能であり、１件目を読み出し、メールサーバ２−１５から削除する処理は、図８と同様である。２件目を読み出した後に、２件目のデータを前述した方法で解析し、この結果が、端末でデコード不可能であった場合には、読み出した２件目のデータ削除をメールサーバ２−１５へ依頼せず（すなわち、ＤＥＬ　２コマンドを発行せず）、２件目を読み出した時点で、ＱＵＩＴ命令でいったんメールサーバ２−１５との接続を切断する。このとき、無線携帯端末２−２は、最初に読み出したメールのＩＤ　（ｙｙｙｙｙｙｙｙ）を記憶しておく。この状態で、メールサーバ２−１５には２件目のメールデータが保持されたままとなる。
【００９８】
次に、無線携帯端末２−２がマルチファンクション端末装置１０に接続された場合に、無線携帯端末２−２がメールサーバ２−１５に残っているメールデータを読み出す手順を図１０に示す。
【００９９】
無線携帯端末２−２は、マルチファンクション端末に接続されると、記憶しているメールのＩＤおよびその個数から、メールサーバ２−１５に残したメールの有無を判断し、残っているメールがある場合に、回線を接続し、図１０のＰＯＰ手順で、メールサーバ２−１５に残したメールを読み出し、その情報を接続されたマルチファンクション端末装置１０に送信する。この場合、無線携帯端末２−２で全てのデータを記憶した上でマルチファンクション端末装置１０にデータを送信してもよいし、メールデータを無線携帯端末２−２で記憶せず直接マルチファンクション端末装置１０に送信してもかまわない。
【０１００】
無線携帯端末２−２はＳＴＡＴ命令およびＵＩＤＬ命令でメールサーバ２−１５上のメールデータ情報を読み込み、読み込んだＩＤと先に記憶したＩＤが一致すれば、このメールの送信をメールサーバ２−１５へ指示し、メール本文を読み出して、メールサーバ２−１５上で不要となったこのメールの削除を指示して回線を切断する。このようにして、無線携帯端末２−２から渡されたデータは、前述した方法でマルチファクション端末においてデコードされ、所望の手段で出力される。
【０１０１】
以上の実施形態によれば、無線携帯端末２−２が自身ではデコードできないデータを受信した場合、マルチファンクション端末装置１０が代わってそのデータをデコードする。これにより、無線携帯端末２−２が受信、デコードできないデータを無効にすることなく処理できるようになる。
【０１０２】
以上、本発明の実施形態を詳述したが、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタ等）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機、ファクシミリ装置等）に適用してもよい。
【０１０３】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（図４および／または図５〜７に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムを読み出して実行することによっても達成される場合を含む。
【０１０４】
したがって、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１０５】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１０６】
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ等）、光磁気ディスク、磁気テープ、メモリカード等がある。
【０１０７】
その他、プログラムの供給方法としては、インターネットを介して本発明のプログラムをファイル転送によって取得する態様も含まれる。
【０１０８】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介して暗号化を解く鍵情報を取得させ、その鍵情報を使用することで暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１０９】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現され得る。
【０１１０】
さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０１１１】
【発明の効果】
本発明によれば、通信システムにおいて通信端末自身がデコードできないデータを受信した場合でも、別の装置の支援を受けてそのデータをデコードし所定の処理を行うことが容易にできるようすることができる。
【図面の簡単な説明】
【図１】実施形態におけるマルチファンクション端末装置の構成を示すブロック図である。
【図２】実施形態に係る通信システムを示す図である。
【図３】実施形態における電子メールデータの内容の一例を示す図である。
【図４】電子メールを受信した無線携帯端末の動作を示すフローチャートである。
【図５】無線携帯端末が接続されたときのマルチファンクション端末の動作を示すフローチャートである。
【図６】実施形態におけるデータのデコード後のマルチファンクション端末の処理を示すフローチャートである。
【図７】対象データのデコードが不可と判断されたときのマルチファンクション端末の処理を示すフローチャートである。
【図８】実施形態における無線携帯端末のみで２件のメールを受信する場合のシグナリング図である。
【図９】実施形態における無線携帯端末でデコードができない場合のシグナリング図である。
【図１０】実施形態における無線携帯端末がマルチファンクション端末に接続された場合に、無線携帯端末がメールサーバに残っているメールデータを読み出す場合の手順を示すシグナリング図である。
【図１１】実施形態に係る無線携帯端末のハードウェア構成を示すブロック図である。
【図１】
2004046410.tif 000003
【図２】
2004046410.tif 000004
【図３】
2004046410.tif 000005
【図４】
2004046410.tif 000006
【図５】
2004046410.tif 000007
【図６】
2004046410.tif 000008
【図７】
2004046410.tif 000009
【図８】
2004046410.tif 000010
【図９】
2004046410.tif 000011
【図１０】
2004046410.tif 000012
【図１１】
2004046410.tif 000013