JP2004147338A - 通信装置 - Google Patents

Abstract

【課題】データフォーマットが異なっても通信が行える通信装置を提供する。
【解決手段】公衆回線、ＬＡＮ、赤外線通信などを通じて他の装置と通信を行う通信部３と、装置がどのようなフォーマットのデータを扱うことができるかを記憶するリソース情報記憶部５と、通信を行うデータを記憶する記憶部６と、通信相手が解釈できるようにデータの変換を行うデータ変換部７と、現在保持するデータが通信相手が解釈できる形に変換できるかどうかを記憶する変換テーブル８と、実際の変換手段を記憶する変換手段格納部９と、相手の装置のリソース情報がどのようなどのようなものか知るネゴシエーション部１０とが配設されている。
【選択図】　　　図１

Description

　本発明は、通信装置に関し、特に文字、画像、音声などのデータを公衆回線網、ＬＡＮ、赤外線通信などのネットワークを通じて送受信する通信装置に関する。

　従来、ネットワークを用いたデータ通信においては、送信側があらかじめ受信側のデータ処理能力および機能を知っていて、それに合わせたデータを送っている。例えば、テレビ放送では放送局側は端末（テレビ）の能力に合わせた形式の信号を送信している。この方式では単一のデータフォーマットを仮定できる場合には問題ないが、多種類のフォーマットが存在し、かつ装置がそのうちの一部のフォーマットしか解釈できない場合には、受信できないという問題がある。送信側の装置が所定のフォーマットを仮定してデータを送信しても、受信側がそのフォーマットを理解できない事があるからである。

　また、テレビより進んだ形式としてファクシミリがある。これはネゴシエーションの部分でどのような通信速度で通信が可能であるかなどの情報をやり取りを行い、その上で両者が扱うことのできる通信速度及びプロトコルで送受信を行う。この手法は、通信プロトコルの選択を行うが、データフォーマットの変更を行うわけではない。よってデータフォーマットの異なりについての問題は解決されない。

　そこで、この問題点を解消するものとして、扱うデータをカラー静止画像に限った場合には、特開平５−２６０２４２号公報で示される方式が存在する。これは、データ通信に先駆けてネゴシエーションを行い、受信装置が処理できる形式に送信側で変換してからデータを送る。

　しかしながら、特開平５−２６０２４２号公報で示される方式では扱うデータがカラー静止画像画像のみを対象としている。静止画像以外のデータの通信に対しては方法が存在しない。またカラー画像であってもそのカラーの扱い方のみを述べているのであって、画像サイズの違いなどについては触れられていない。

　例えば文字データの例を考えると、通常ワードプロセッサは文章や図形の格納のための機種固有のフォーマットをもっており、フォーマットの異なる機種で通信を行おうとすると何らかの変換が必要である。同様に個人用の携帯端末ではアドレスやスケジュールを格納するために固有のフォーマットを有している。理想的にはこれらは唯一の共通フォーマットに統一されることが望ましいが、それが事実上困難である場合には、なんらかの変換の手段が必要となる。また、他のデータでも同様であり、動画の場合にはＭＰＥＧ１、ＭＰＥＧ２などの標準フォーマットの他にマイクロソフト社のＡＶＩフォーマットやアップル社のＱｕｉｃｋＴｉｍｅフォーマットなどがある。音楽では波形そのものを送る場合であってもサンプリング周波数や１サンプルのビット精度などの選択の余地があり、またＭＩＤＩなどの記号情報で送る場合もある。通信を行う機器が相互に同じフォーマットを解釈できる能力があることが望ましいが、他種類の機種の間で通信を行おうとすると、この仮定は必ずしも成り立たない。このため、データ通信に先立ち送信側と受信側でネゴシエーションを行い、送信装置において受信側で扱える形式に変換して送信することが望ましい。もし、フォーマットとしては送信が可能な場合であっても受信側の記憶容量などが問題になることも考えられる。

　本発明は、上記のような課題を解消するためになされたもので、データフォーマットが異なっても通信が行える通信装置を提供することを目的とする。

　本発明によれば、前述の目的は、文字、画像、図形、音声及び音楽データを含む情報を送受信する通信装置であって、データを処理するためのハードウエア及びソフトウエアからなるリソースに関する情報を記憶するリソース情報記憶手段と、データの送信に先立って、受信側の他の通信装置が同じリソースを有するか否かを判定すべく前記受信側の他の通信装置と通信するネゴシエーション手段と、前記受信側の他の通信装置が同じリソースを有さない場合に、送信すべきデータを前記受信側の他の通信装置のリソースで処理可能なデータに変換するための変換手段を記述した変換テーブルに基づいてデータ変換を行うデータ変換手段とを具備する請求項１の通信装置によって達成される。

　本発明によれば、前述の目的は、前記通信装置の計算性能を示す性能評価値を記憶する性能評価値記憶手段と、前記通信装置の性能評価値と前記受信側の他の通信装置の性能評価値を比較する性能比較手段とを具備し、前記通信装置の性能評価値と前記受信側の他の通信装置の性能評価値を比較し、性能評価値が優位な通信装置で前記データ変換を行う請求項２の通信装置によって達成される。

　本発明によれば、前述の目的は、各データに対してオリジナルデータがどこに存在するのかを記憶しておくオリジナルアドレス記憶手段と、通信のときにオリジナルデータがどこに存在するかの情報を付加するオリジナルアドレス付加手段とを具備し、前記受信側の他の通信装置においてオリジナルデータを得たい場合には、ユーザからの指示に基づきオリジナルデータを持つ他の通信装置からオリジナルデータを得る請求項３の通信装置によって達成される。

　本発明によれば、前述の目的は、前記変換テーブルと、前記リソース情報記憶手段とが書換可能な媒体である請求項４の通信装置によって達成される。

　本発明によれば、前述の目的は、前記通信装置または前記受信側の他の通信装置と異なる第３の通信装置に対してデータ変換を依頼する変換依頼手段と、他の通信装置からの変換を受け付ける変換受け付け手段とを具備し、前記通信装置で前記受信側の他の通信装置が処理できるデータに変換できない場合には、前記第３の通信装置に対してデータを変換するよう依頼し、前記変換されたデータを前記受信側の他の通信装置へ送る請求項５の通信装置によって達成される。

　本発明によれば、前述の目的は、各種データ変換を行った場合のデータ転送に必要な時間の推定を行う通信時間推定手段と、データの送受信の際の通信時間の推定値を前記データ変換毎に表示する画像表示手段と、画像表示手段に表示されるデータ変換の種類及び通信時間の情報に基づき任意の手法を選択する選択手段とを具備する請求項６の通信装置によって達成される。

　本発明によれば、前述の目的は、現在送信しようとしているデータを処理するためのソフトウエアを含めた情報を記憶する出力用情報記憶手段を具備し、前記受信側の他の通信装置にデータを処理するためのソフトウエアを含めた情報がなく、かつ送信側の通信装置に前記情報がある場合に、前記データとともに前記情報を送信する請求項７の通信装置によって達成される。

　請求項１の通信装置によれば、リソース情報記憶手段により装置のハードウエア及びソフトウエア情報が記憶され、ネゴシエーション手段によりデータの送信に先立って、受信側が同じリソースを有するか否かを判定すべく受信側と通信し、変換テーブルにより送信すべきデータを処理するためのリソースが受信側にない場合に受信側のリソースで処理できるようにするための変換手段が記述され、この変換テーブルに基づいてデータ変換手段によりデータ変換が行われる。これにより、装置間でハードウエアやソフトウエア、データフォーマットの違いを吸収するため、ユーザはそれらの異なりを気にすることなく、常に最良のデータを受信または送信することが可能になる。

　請求項２の通信装置によれば、性能評価値記憶手段により装置の計算性能を示す性能評価値が記憶され、性能比較手段により送信側の性能評価値と受信側の性能評価値が比較され、通信に際してデータフォーマットの変換が必要な場合かつ送信側と受信側の両方ともその変換を行うことが可能な場合に、計算性能が比較され、性能が優位な装置で変換が行われる。これによりフォーマット変換を含めた通信時間を短縮し得る。

　請求項３の通信装置によれば、オリジナルアドレス記憶手段により各データに対するオリジナルデータがどこに存在するのかが記憶され、オリジナルアドレス付加手段により通信のときにオリジナルデータがどこに存在するかの情報が付加され、受信側装置においてデータのオリジナルデータを得たい場合には、指示に基づきオリジナルデータを持つ装置からオリジナルデータが得られる。

　請求項４の通信装置によれば、前記変換テーブルと、リソース情報記憶部とは書換可能である。これにより、新しいリソースを容易に追加できる。

　請求項５の通信装置によれば、変換依頼手段により送信または受信装置と異なる第３の装置に対して変換が依頼され、変換受け付け手段により他の装置からの変換が受け付けられ、送信側で受信装置が解釈できる形式に変換できない場合には、第３の装置に対して変換を行うよう依頼され、その変換結果が受信装置へ送られる。これにより、送信側及び受信側でできないフォーマット変換を行うことが出来る。

　請求項６の通信装置によれば、通信時間推定手段により各種変換を行った場合のデータ転送に必要な時間の推定が行われ、画像表示手段によりデータの送受信の際に通信時間の推定値がデータ変換毎に表示され、選択手段により画像表示手段に表示される変換の種類及び通信時間の情報に基づき任意の手法が選択される。従って、ユーザが適切な変換手法を選択することが可能となる。

　請求項７の通信装置によれば、出力用情報記憶手段により現在送信しようとしているデータを処理するためのソフトウエアを含めた情報が記憶され、出力用情報通信手段によりその出力用情報が送受信され、受信側でデータ出力もしくは処理のためのソフトウエアを含めた情報がなく、かつ送信側にその情報がある場合に、データとともに該情報が送受信される。従って、変換を行うことなくデータを処理することが出来る。

　以下、請求項１の通信装置の実施例を図を参照しながら説明する。

　本実施例の通信装置は、図１に示すように、各部を制御する制御手段としての制御部４を有しており、制御部４にはバスライン２０を介してテキストで静止画、動画などを表示する画像表示手段としての表示部１と、音楽や音声を出力する音声出力手段としての音声出力部２と、公衆回線、ＬＡＮ、赤外線通信などを通じて他の装置と通信を行う通信手段としての通信部３と、指示等を入力する選択手段としての入力部２１とが接続されている。更に、バスライン２０には、装置がどのようなフォーマットのデータを扱うことができるかを記憶するリソース情報記憶手段としてのリソース情報記憶部５と、通信を行うデータを記憶する記憶部６と、通信相手が解釈できるようにデータの変換を行うデータ変換手段としてのデータ変換部７とが接続されており、かつ現在保持するデータが通信相手が解釈できる形に変換できるかどうかを記憶する変換テーブル手段としての変換テーブル８と、実際の変換手段を記憶する変換手段格納手段としての変換手段格納部９と、相手の装置のリソース情報がどのようなどのようなものかしるためのネゴシエーション手段としてのネゴシエーション部１０とが接続されている。

　なお、上述構成では受信したデータは人が見るあるいは聞くことを想定したものであるが、特に人に対して出力する必要はなく、出力部の代わりに処理部であっても構わない。また、受信されるデータは音声、音楽、画像、文字に限らず、形式が決まつているデジタルの数値列であれば表計算ソフトのデータやＣＡＤ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄｅｓｉｇｎ）やＬＳＩ配線のデータであっても構わない。このようにする場合には、図１のブロック図において音声出力部のところをデータ処理部と置き換える。

　次に、本実施例の動作を図２のフローチャートに沿って説明する。

　ステップＳ１でにおいて、送信するデータが設定され、ステップＳ２において、送信先が設定される。ステップＳ３において、ステップＳ２で設定された送信相手に送信要求が出され、ステップＳ４において、接続が成功したかどうかが判定される。接続が失敗した場合、通信が終了される。接続が成功した場合、ステップＳ５において、送信相手の端末の持つリソース情報が受信され、ステップＳ６において、ユーザは変換テーブル８を参照して入力部２１により任意の変換手法を選択する。ステップＳ７において、選択された変換手法があったかどうかが判定される。もちろん変換せずに済む場合も変換可能として判断される。ステップＳ８において、変換する手段がなかった場合、その旨が表示部１に表示されて通信が終了される。この場合は通信を終了しているが、一つのデータの中で異なるフォーマットが使用されている場合、例えば文字と静止画が混在する場合などには、一部を通信する（文字だけ通信する）ことも考えられる。この場合には、通信を終了せず、通信できるものだけを送ることも考えられる。選択された変換手法があった場合、ステップＳ９において、受信側で解釈可能なようにデータが変換される。変換が不要な場合にはなにもしない。ステップＳ１０において、変換したデータが送信され、ステップＳ１１において、通信が終了される。

　受信側では、ステップＳ１２において、送信要求が待機され、ステップＳ１３において、送信要求が受理され、接続が確立したか判断される。接続が確立しない場合には再び受信待ちになる。ステップＳ１４において、受信側端末の持つリソース情報が送信され、ステップＳ１５において、受信側で解釈できる形のデータが受信され、ステップＳ１６において、通信が終了される。

　上述したフローでは送信側でデータ変換を行ったが、受信側で変換を行う場合も考えられる。またここでのフローでは呼びを発生する側がデータを送るように記述されているが、当然呼びを発生させる側がデータ受信を行ってもよい。これは以下の実施例でも同様である。なお通信相手のリソース情報を通信終了後も記憶しておくと、次回からネゴシエーションを行わずに済む。この場合に何らかの理由で相手のリソースが変更されたときには、それを通知することが必要である。また、他機種の出力の形態を模擬する機能があり、相手側のリソース情報を記憶していると、送信する前もしくは送信後に相手側でどのような形態で出力されるかを確認することが可能になる。

　図３に送信データの例を示す。この例では、文章（ＴＥＸＴ１，ＴＥＸＴ２）、静止画（ＩＭＡＧＥ１）、音楽（ＳＯＵＮＤ１）が含まれている。この場合には、例えば表１のような形式で送信される。この例では＃＃というキーに続いてフォーマットが指定されている。この例の最初のデータはＥＵＣ ＴＥＸＴと記述されていてＥＵＣコードで書かれた文章が存在する。次にはＪＰＥＧの静止画データが、その次にはＭＩＤＩ形式の音楽データが、最後に再びＥＵＣ形式の文章が格納されている。

　上述した変換方法により変換された後の例は、表２に示すように、文章はＥＵＣコードからＳＪＩＳ（シフトＪＩＳ）コードに変換され、ＪＰＥＧデータはビットマップデータに変換されている。ＭＩＤＩはそのままであり、変換されていない。

　表３に装置が持つリソース情報ファイルの例を示す。この例では、ＥＵＣの文章、ＢＩＴＭＡＰ、ＭＩＤＩなどを解釈可能であることを示している。すなわち、解釈可能なものしか通信できない。この例で上げられているように、アドレスデータやスケジュールデータなどもリソース情報として登録することが望ましい。変換プログラムを作成することで、機種により異なる住所やスケジュールフォーマットなどが、ユーザに意識させることなく変換が可能になる。

　表４に変換テーブルの例を示す。この例では、変換前フォーマット：変換可能フォーマット１、変換可能フォーマット２、・・・・という形で記述されている。

　尚、フォーマット名の前に「＊」がついているのは非可逆変換を示している。非可逆変換とは、ＡをＢに変換し、再びＢをＡに変換しようとしたとき、元のＡが完全には復元できない変換を示している。言い換えると、変換を行ったときに元の情報の一部が失われる変換のことを指す。なお、請求項１の発明では、この非可逆変換かどうかは関係しない。ここで変換という言葉は元のデータもしくはそれに付険する情報、例えばファイル名、作成日時、作成装置アドレスなどを用いて別のデータを作り出す作業をいう。もとのデータはイメージであるものを、そのオリジナルデータがあるマシンのアドレスとそのイメージのファイル名とそのイメージの縦横の大きさだけに置き換えてしまうような操作も変換と呼んでいる。同様に動画データから１枚ないしは数枚の静止画を抜き出したデータを作る操作も変換である。

　次に、請求項２の通信装置の実施例を図を参照しながら説明する。なお、図１と同一構成部分には同一符号を付して説明を省略する。

　本実施例の通信装置は、図４に示すように、当該機種の変換の性能を示す性能評価値記憶手段としての性能評価記憶部１１と、当該機種と通信相手の機種から送られてきた性能評価を比較する性能比較手段としての性能比較部１２とを具備している。

　次に、本実施例の動作を図５のフローチャートに沿って説明する。

　ステップＳ２１において、送信するデータが設定され、ステップＳ２２において、送信先が設定される。ステップＳ２３において、ステップＳ２２で設定された送信相手に送信要求が出され、ステップＳ２４において、接続が成功したかどうかが判定される。接続が失敗したならば、ステップＳ３４において通信が終了される。接続が成功した場合、ステップＳ２５において、送信相手の端末の持つリソース情報が受信され、ステップＳ２６において、通信相手の性能評価値が受信される。ステップＳ２７において、変換テーブルを参照して入力部２１により変換手法が選択され、ステップＳ２８において、選択された変換手法があったかどうかが判定される。もちろん、変換せずに済む場合も変換可能として判断される。ステップＳ２９において、変換する手段がなかった場合、その旨がユーザに伝えられて通信が終了される。この場合は通信を終了しているが、一つのデータの中で異なるフォーマットが使用されている場合、例えば文字と静止画が混在する場合などには、一部が通信できる（文字だけ通信できる）ことも考えられる。この場合には通信を終了せず、通信できるものだけを送ることも考えられる。ステップＳ３０において、当該機種の性能評価値と通信相手の性能評価値が比較され、ステップＳ３１において、当該機種の性能が通信相手よりもよいかどうかが判定される。ステップＳ３２において、当該機種の性能が高いので当該機種にて受信側で解釈可能なようにデータが変換される。変換が不要な場合にはなにもしない。ステップＳ３３において、変換したデータが送信され、ステップＳ３４において、通信が終了される。

　一方、受信側では、ステップＳ３５において、送信要求が待機され、ステップＳ３６において、送信要求が受理され、接続が確立したか否かが判断される。接続が確立しない場合には再び受信待ちになる。ステップＳ３７において、受信側端末の持つリソース情報が送信され、ステップＳ３８において、性能評価値が送信される。ステップＳ３９において、データが受信され、ステップＳ４０において、リソース情報と現在のデータのフォーマットとが比較されて変換が必要かどうかが判定される。ステップＳ４１において、変換が行われ、ステップＳ４２において、通信が終了される。

　上述したフローでは変換手法を選択する前に性能評価値を受信しているが、当然、変換可能と判断された後に性能評価値を受信することも考えられる。また、性能評価値はただ一つの値ではなく、変換手法毎に記憶しておくことがより望ましい。機種の性能により、ある変換は他の機種に比較して相対的に高速に行えるが、別の変換は相対的に遅いということがありえる。変換手法毎に性能を記憶しておくと、現在必要な変換に対しての変換速度の比較が可能になり、より効率的に処理できる。また、この例では性能評価値は事前に速度測定プログラムなどにより測定されて、設定されているものとしているが、装置の現在の負荷、例えば複数のプログラムが走っていてＣＰＵの負担が大きいとうによって性能評価値を動的に変更することも可能である。この場合には負荷の大きい機種ではなるべく変換作業を行わなくなる。ＣＰＵの性能で負荷の大きさに依らずユーザがどちらで変換するかを指定することも可能である。この場合には、２台の装置とも変換できる場合に必ずユーザに問い合わせることも可能であるし、「相手の装置がＸであつたならば相手側で変換」などといったようなことをあらかじめ記憶しておくことも可能である。

　次に、請求項３の通信装置の実施例を図を参照しながら説明する。なお、図１と同一構成部分には同一符号を付して説明を省略する。

　本実施例の通信装置は、図６に示すように、過去に受信したデータに対してオリジナルのデータがどこにあるかを記憶するオリジナルアドレス記憶手段としてのアドレス／識別子記憶部２２と、現在送信しようとするデータに送信側装置のアドレスと、データを特定するための識別子を付加するオリジナルアドレス付加手段としてのアドレス／識別子付加部２３とを具備しており、アドレス／識別子記憶部２２は、現在記憶しているデータがオリジナルとまったく同じか、なんらかの変換によってオリジナルのデータが復元できる場合には、アドレス／識別子にはなにも記憶されないように構成されている。

　次に、本実施例の動作を図７のフローチャートに沿って説明する。

　ステップＳ５１において、送信するデータが設定され、ステップＳ５２において、送信先が設定される。ステップＳ５３において、ステップＳ５２で設定された送信相手に送信要求が出され、ステップＳ５４において、接続が成功したかどうかが判定される。接続が失敗したならば、ステップＳ６３において通信が終了される。接続が成功した場合、ステップＳ５５において、送信相手の端末の持つリソース情報が受信され、ステップＳ５６において、変換テーブルを参照して入力部２１により変換手法が選択され、ステップＳ５７において、選択された変換手法があったかどうかが判定される。もちろん、変換せずに済む場合も変換可能として判断される。ステップＳ５８において、変換する手段がなかった場合、その旨がユーザに伝えられ通信が終了される。この場合は通信を終了しているが、一つのデータの中で異なるフォーマットが便用されている場合、例えば文字と静止画が混在する場合などには、一部が通信できる（文字だけ通信できる）ことも考えられる。この場合には通信を終了せず、通信できるものだけを送ることも考えられる。ステップＳ５９において変換が行われ、ステップＳ６０において、ステップＳ５９で行われた変換が可逆変換か不可逆変換かが判断される。ステップＳ６１において、ステップＳ５９で行われた変換が不可逆変換であつた場合に、そのデータのオリジナルのアドレスとデータ識別子が送信データに付加される。なお、可逆変換か不可逆変換かの判断は、表４の変換テーブルにあらかじめ記述しておくことで実現できる。アドレスとは、変換前のオリジナルデータを持つ装置にアクセスするための通信アドレスのことである。識別子とはオリジナルデータを保有する装置の中のどのデータを指しているかを特定するためのコードである。通常のファイルシステムであればディレクトリのパスとファイルネームでもよい。しかしパスとファイルネームではファイルの名前を変えただけで見つけられなくなるので、データと必ず一致するようなコードを採用することが望ましい。また、オリジナルデータのフォーマット情報もこのとき同時に付加することが望ましい。ステップＳ６２において、変換したデータが送信され、ステップＳ６３において、通信が終了される。

　一方、受信側では、ステップＳ６４において、送信要求が待機され、ステップＳ６５において、送信要求が受理され、接続が確立したか否かが判断される。接続が確立しない場合には再び受信待ちになる。ステップＳ６６において、受信側端末の持つリソース情報が送信され、ステップＳ６７において、データが受信され、ステップＳ６８において、通信が終了される。

　本発明は例えば、以下のようにして適用される。Ａ，Ｂ，Ｃの３種類の装置を仮定する。装置ＡとＣは同等の能力をもつ装置、例えばパソコンであり、装置Ｂは装置Ａ，Ｃに比較して劣った性能をもつもの、例えば携帯端末と仮定する。装置ＡにはデータＸが存在する。これを装置Ｂに送る場合に、装置ＢがデータＸを解釈する能力がないため、装置Ａもしくは装置ＢでデータＸは、これと異なるフォーマットに変換される。変換されたデータをＸ’とする。ここで行われた変換が不可逆変換であるとすると、本発明によつてデータＸ’にはオリジナルのデータを保持する装置Ａのアドレスと、Ｘを装置Ａ内で特定するための識別子が付加される。装置ＢではＸ’が解釈され、出力（表示）が行われる。更に、装置Ｂではそのデータを装置Ｃに送信することを考える。装置ＣではデータＸ’を解釈するが、データＸのフォーマットも解釈する能力がある場合には、情報量の落ちたデータＸ’よりもデータＸをユーザは望む可能性がある。この場合に、本発明によりデータＸ’にはデータＸの存在する装置Ａのアドレスとデータを特定する識別子を含んでいるので、装置Ｃから装置Ａに対してデータＸの送信を要求することが可能になる。例えば、データＸはカラ−画像をＪＰＥＧによって圧縮したものであり、データＸ’は白黒のビットマップデータであるような場合である。装置ＣではデータＸ’を出力する場合に、同時に別のオリジナルデータが存在する旨の表示が行われ、かつ、ワンタッチで装置Ａと通信し、オリジナルデータを出力できることが望ましい。また、この例ではオリジナルのアドレスを一つだけ付加するように記載しているが、送信された履歴として通過してきたすべての装置のアドレスを付加してもよい。インターネットの電子メールには通過してきたコンピュータのアドレスがすべて付加されている。

　上述した説明では、不可逆変換を行いデータを送信した装置においてデータ消去されるとオリジナルのデータを得ることはできなくなるが、送信履歴をすべて付加しておくとデータが消去された場合でも他の装置へデータを要求することが可能になる。また、不可逆変換を行った場合にも、変換後のデータと併せて変換前のオリジナルデータを送信することも考えられる。この場合にはデータ量が増えるが、オリジナルデータは必ず保存されているので、オリジナルデータを必要とする場合に、新たに通信をする必要がない。

　次に、請求項４の通信装置の実施例を図を参照しながら説明する。

　本実施例の通信装置の特徴は図１の変換テーブル８および変換手段格納部９を書換可能な媒体で構成することにある。このようにすることで新たなフォーマットが生まれても、そのフォーマットを既存の解釈できるフォーマットに変換する手段を後から追加することが可能となり、新しいフォーマットに対応することが可能になる。

　次に、請求項５の通信装置の実施例を図を参照しながら説明する。なお、図１と同一構成部分には同一符号を付して説明を省略する。

　本実施例の通信装置は、図８に示すように、現在の通信相手ではない第３の装置に対してフォーマット変換を依頼する変換依頼手段としての変換依頼部２４と、変換依頼を受け付ける変換受け付け手段としての変換依頼受付部２５とを具備している。

　次に、本実施例の動作を図９のフローチャートに沿って説明する。

　ステップＳ７１において、送信するデータが設定され、ステップＳ７２において、送信先が設定される。ステップＳ７３において、ステップＳ７２で設定された送信相手に送信要求が出され、ステップＳ７４において、接続が成功したかどうかが判定される。接続が失敗したならば通信は終了される。接続が成功した場合、ステップＳ７５において、送信相手の端末の持つリソース情報が受信され、ステップＳ７６において、変換テーブルが参照されて入力部２１により変換手法が選択される。ステップＳ７７において、変換手法があったかどうかが判定される。もちろん変換せずに済む場合も変換可能として判断される。ステップＳ７８において、送受信側に変換する手段がなかった場合、第３の装置へ変換が依頼される。この依頼については後述する。ステップＳ７９において、変換を依頼した結果が成功であったかどうかが判断され、ステップＳ８０において、変換が失敗に終わった場合、変換不能の表示が出され、通信が終了される（ステップＳ８３）。ステップＳ８１において、当該機種の性能が高いので当該機種にて受信側で解釈可能なようにデータが変換される。変換が不要な場合にはなにもしない。ステップＳ８２において、変換したデータが送信され、ステップＳ８３において、通信が終了される。

　一方、受信側では、ステップＳ８４において、送信要求が待機され、ステップＳ８５において、送信要求が受理され、接続が確立したか否かが判断される。接続が確立しない場合には再び受信待ちになる。ステップＳ８６において、受信側端末の持つリソース情報が送信され、ステップＳ８７において、受信側で解釈できる形のデータが受信される。ステップＳ８８において、通信を終了される。

　ここで、ステップＳ７８の変換依頼について図１０のフローチャートに沿って説明する。

　ステップＳ９１において、送信データが設定され、ステップＳ９２において、変換依頼先が設定される。ステップＳ９３において、変換依頼先の装置を呼び出される。ステップＳ９４において、接続が確立したかどうかを判定される。ステップＳ９５において、変換依頼が送信される。なお、変換依頼とは変換前のフォーマットと変換後のフォーマットを記述したものである。ステップＳ９６において、依頼先の装置が要求した変換を行えるかどうかの結果が受信される。ステップＳ９７において、変換可能であるかどうかを判断され、ステップＳ９８において、変換要求の結果として変換不能が設定される。ステップＳ９９において、変換不能の表示が行われ、通信が終了される（ステップＳ１０３）。また、上述ステップＳ９７において変換可能であると判断された場合、ステップＳ１００において、変換のためのデータが送信され、ステップＳ１０１において、変換されたデータが受信される。ステップＳ１０２において、変換の要求結果として変換成功が設定される。ステップＳ１０３において、通信を終了される。

　一方、受信側では、ステップＳ１０４において、他の装置からの送信要求が待機され、ステップＳ１０５において、通信が確立したかどうかが判断される。ステップＳ１０６において、送信者の要求を受信される。ステップＳ１０７において、受信要求が変換要求であるかどうかが判断される。ステップＳ１０８において、変換要求以外であった場合、所定の他の処理が行われる。ステップＳ１０９において、送られてきた変換要求が可能かどうかが判定される。ステップＳ１１０において、変換できないと判定された場合、変換不能が送信される。ステップＳ１１１において、変換可能が送信される。ステップＳ１１２において、変換のためのデータが受信される。ステップＳ１１３において、実際に変換処理が行われる。ステップＳ１１４において、変換データが送信される。

　なお、上述したフローでは送信の処理の途中で別の装置に対して変換要求を出しているが、もちろん、最初の通信を一度中断してから別の装置に変換要求を出し、変換が終わってから再度最初の送信相手を呼び出すことが望ましい。本発明は例えば機種の巣なる２台の携帯端末がデータのやり取りを行う場合において、携帯端末自身には変換の手段がないときに、第３の装置、例えばパソコンに対して変換要求を出して変換を行うといったように使用される。フローでは送信側の装置が変換要求を出した後に変換結果をもらい、その変換結果を受信装置に送るように記載されている。しかし、当然、変換を行う装置が変換結果を送信側に返さずに、直接受信側に送ることも考えられる。この場合には変換依頼送信もしくはデータ送信のときに送信先のアドレスを同時に変換側装置へ送ることが必要である。また、一回の変換要求において複数のデータの変換を行えることや、１台でなく複数台の装置に変換要求を出せるようにしておくことが望ましい。

　次に、請求項６の通信装置の実施例を図を参照しながら説明する。なお、図１と同一構成部分には同一符号を付して説明を省略する。

　本実施例の通信装置は、図１１に示すように、データ変換時間を含めた通信時間を推定する通信時間推定手段としての通信時間推定部２６を具備する。

　次に、本実施例の動作を図１２のフローチャートに沿って説明する。

　ステップＳ１２１において、送信するデータが設定される。ステップＳ１２２において、送信先が設定される。ステップＳ１２３において、ステップＳ１２２で設定された送信相手に送信要求が出される。ステップＳ１２４において、接続が成功したかどうかが判定される。接続が失敗したならば、通信が終了される（ステップＳ１３７）。接続が成功した場合、ステップＳ１２５において、通信速度が求められる。これは回線状態によって通信速度が変わる場合があることによる。モデムでは通常トレーニングによって通信速度が決定される。よってトレーニングの後では通信速度の概算が算定できる。ただし、誤り率などは完全には分からないので概算の数値となる。ステップＳ１２６において、送信相手の端末の持つリソース情報が受信される。ステップＳ１２７において、変換テーブルが参照されて入力部２１により変換手法が選択される。ステップＳ１２８において、変換手法があったかどうかが判定される。もちろん変換せずに済む場合も変換可能として判断される。ステップＳ１２９において、変換不能の表示を出して、通信を終了される（ステップＳ１３７）。変換可能であると判断された場合、ステップＳ１３０において、変換に要する時間が推定される。この場合も変換手法やデータの種類によって完全な推定は困難である。よって標準のデータサイズの場合において要する時間を変換手法ごとに予め記憶した数値などと現在のデータ量から推定する手法が考えられる。ステップＳ１３１において、変換後のデータ容量が推定される。ステップＳ１３０と同じく完全には困難であるが、大ざっぱな値は標準的な数字から概算で求めることが可能である。ステップＳ１３２において、「変換後データ容量／通信速度＋変換時間」などの式によって現在のデータ通信に必要な時間の概算が求められる。また、課金のための情報を記憶しておくことで、通信に要する通信料の概算をユーザに提示することも可能である。

　ステップＳ１３３において、ステップＳ１３２で得られた所要時間が示され、ユーザにそのデータを送信してよいかどうかが確認される。ステップＳ１３４において、ユーザが送信を許可したかどうかが判定される。許可したと判断した場合、ステップＳ１３５において、データ変換が行われる。ステップＳ１３６において、データが送信される。ステップＳ１３７において、通信が終了される。

　一方、受信側では、ステップＳ１３８において、送信要求が待機され、ステップＳ１３９において、送信要求を受理し、接続が確立したか判断される。接続が確立しない場合には再び受信待ちになる。接続が確立した場合、ステップＳ１４０において、受信側端末の持つリソース情報が送信される。ステップＳ１４１において、受信側で解釈できる形のデータが受信される。ステップＳ１４２において、通信が終了される。

　なお、複数の変換手法がある場合にはそのすべてもしくは一部を表示してユーザに選択させることが望ましい。送信データに文字とイメージなど異なる種類のデータを含む場合には、オリジナルデータを得るための情報のみを送ることも考えられる。例えば、文字と動画を含むデータを電話回線をつかって送ろうとして、電話回絡で動画を送信するには時間がかかり過ぎるとユーザが判断した場合に、文字はすべての情報を送信し、動画はオリジナルのデータを得るためのアドレス情報でデータ識別子などのみを送るということが可能になる。なお、この場合には文字と画像の位置関係（座標情報）も併せて送ると、文字を表示したときに画像がどの位置に表示されるかを受信側のユーザに示すことが可能である。また、上述請求項３の実施例によって、動画データがほしい場合には送信要求を出すことでそのデータが得られる。ユーザに判断を求める場合には、あらかじめ条件を記述しておくことも考えられる。この場合にはユーザが事前に「１０分以上通信を行うことはしない」とか「１００円以上の通信を行うことはしない」とかの設定を入力し、その条件に合致する変換を選択して通信を行うことが可能である。また、文字、イメージ、及び音楽などの複数の情報が含まれたデータを送信する場合には、データ量が少ないものから送信を行うことが望ましい。

　経験的に文字データはイメージデータに比較してデータ量が少なく、かつ１単位（バイト）あたりの情報量は多いので、データ量の少ないものから送信することで、通信が中断した場合に、多くの情報が届いている可能性が高い。また、使用法によってイメージデータが重要であるなどの要望がユーザによつて異なると考えられるので、ユーザがどのデータを先に通信したいかの設定を行えるようにすることが望ましい。

　次に、請求項７の通信装置の実施例を図を参照しながら説明する。なお、図１と同一構成部分には同一符号を付して説明を省略する。

　本実施例の通信装置は、図１３に示すように、データを出力もしくは処理するための情報（例えば出力用ソフトウエア）を記憶する出力用情報記憶手段としての出力用情報記憶部２７と、出力用情報記憶部２７で記憶されている情報を別の装置に送ったり、別の装置から出力用情報を得る出力用情報通信手段としての出力用情報通信部２８とを具備している。なお、出力用情報記憶部２７は上述実施例においては表示部や音声処理部の一部として存在しているものとする。

　次に、本実施例の動作を図１４のフローチャートに沿って説明する。

　ステップＳ１５１において、送信するデータが設定される。ステップＳ１５２において、送信先が設定される。ステップＳ１５３において、ステップＳ１５２で設定された送信相手に送信要求が出される。ステップＳ１５４において、接続が成功したかどうかが判定される。接続が失敗したならば通信が終了される（ステップＳ１６４）。接続が成功した場合、ステップＳ１５５において、送信相手の端末の持つリソース情報が受信される。この場合のリソース情報には、受信装置の機種も記録されているとする。ステップＳ１５６において、受信側の装置で出力もしくは処理が可能かどうかがリソース情報を用いて判定される。出力可能でない場合、ステップＳ１５７において、受信側で出力が不能であるので、送信側で受信装置用の出力用情報を記憶しているかどうかが判定される。この判定にはリソース情報の中の機種情報が利用される。送信側で受信装置用の出力用情報を記憶していると判断された場合、ステップＳ１５８において、受信装置に対して出力用情報の送信要求が出される。ステップＳ１５９において、送信可能かどうかが受信される。ステップＳ１６０において、送信可能かどうかが判定される。送信可能であると判断された場合、ステップＳ１６１において、出力用情報が送信される。ステップＳ１６２において、データ送信が要求される。ステップＳ１６３において、データが送信される。ステップＳ１６４において、通信を終了される。

　一方、受信側では、ステップＳ１６５において、送信要求が待機されている。ステップＳ１６６において、送信要求が受理され、接続が確立したか否かが判断される。接続が確立しない場合には再び受信待ちになる。接続が確立した場合、ステップＳ１６７において、受信側装置の持つリソース情報が送信される。ステップＳ１６８において、送信要求が受信される。ステップＳ１６９において、送信要求がデータのためのものか出力情報のためのものかが判定される。出力用情報であると判断された場合、ステップＳ１７０において、出力用情報を受信するかどうかが判断される。これは受信側のメモリ容量などにより判定しても構わないし、ユーザに受信するかどうかを問い合わせても実現できる。受信不可であると判断された場合、ステップＳ１７１において、受信不能が送信される。受信可であると判断された場合、ステップＳ１７２において、受信可能が送信される。ステップＳ１７３において、出力用情報が受信される。

　上述ステップＳ１６９において、送信要求がデータのためのものであると判断された場合、ステップＳ１７４において、データが受信され、ステップＳ１７５において、通信が終了される。

　今、送信側がデータＸを送信したい場合であって、受信側でデータＸを出力もしくは処理する情報がないと仮定される。この場合に本発明を用いれば、自動的に送信側装置からデータＸを出力するための情報を受信側に送ることができ、あらかじめ出力用の情報を受信側装置に用意しておかなくても、データを出力することが可能になる。例えば、１台のパソコンに携帯端末で出力するための情報をすべて蓄えておくことで、携帯端末は、個々に出力用ソフトをインストールすることなく、パソコンからのデータ受信時に自動的にソフトがインストールされることになる。当然、ここでは著作権の問題が生じるため、出力用情報にはコピー可能、不能のフラグを立てておき、可能フラグが立っているものだけが対象となるようにしておく。また、一度コピーしたソフトに対しては再度複製をとらないようにコピー不能フラグを持つようなことも可能である。

　請求項１の通信装置によれば、装置の持つハードウエア、ソフトウエア情報（リソース情報）を通信に先立ち送ることで、現在通信を行いたいデータフォーマットと受信側でのリソース情報を比較し、変換が必要であるならばデータ変換を施してから送信するので、データフォーマットが異なっても通信を行うことができる。

　例えば、携帯端末とパーソナルコンピュータ（ＰＣ）を公衆電話回線を通じて結ぶことを考える。ＰＣ側で保持する音楽がMIDIフォーマットであるが、携帯端末側ではMIDIのデータフォーマットを解釈できず、WAVEフォーマットしか出力できないとする。本発明によると、この場合にもそれぞれのリソースを判定することで、ＰＣ側（もしくは携帯端末側）でMIDIフォーマットをフォーマットに変換して送ることが可能になる。

　同様に、ＰＣ側で保持するスケジュールデータのフォーマットが携帯端末のスケジュールフォーマットと合わない場合であっても、変換プログラムを用意するだけで、自動的にそれぞれの機械がどのフォーマットを扱えるかを自動判別して変換し、ユーザはその変換を意識することなく、データを送受信することができる。

　請求項２の通信装置によれば、変換する場合においては、送信側、受信側双方で変換できる能力がある場合には、装置の性能を比較して、性能のよい装置にて変換するので、変換を含めた通信時間を短縮できる。前述の請求項１の例では、ＰＣ側で変換するか携帯端末側で変換するかは実装の方法による。もし、携帯端末で変換する時間がＰＣで変換する場合に比較して極端に遅い場合には、携帯端末で変換するのは効率が悪い。本発明では、この場合にＰＣでの変換性能と携帯端末での変換性能を比較することで、性能の良い方で変換を行うことになる。

　請求項３の通信装置によれば、変換によってオリジナルの情報が失われる場合には、オリジナルデータがどこにあるかの情報をつけて送ることにより、容易にオリジナルデータを得ることができる。前述の請求項２の例では、MIDIフォーマットからWAVEフォーマットに変換された場合に、MIDIフォーマットを復元することは不可能になる。これは、携帯端末でWAVEフォーマットを保持した場合に、さらにその画像を別のＰＣに送ったとしても、そのＰＣはMIDIフォーマットを得ることはできない。

　本発明を用いると、WAVEフォーマットとともに元のMIDIフォーマットを保持するかもしくは、元のMIDIフォーマットがどこにあったかの情報を保持することで、元のMIDIフォーマットが欲しい場合であっても、簡単な操作で呼び出すことができる。

　請求項４の通信装置によれば、リソース情報は書換可能な記憶媒体に収納することで、新たな周辺機器の購入や新たなソフトウエアの追加などにより容易にリソースを追加することができる。

　請求項５の通信装置によれば、送信側および受信側と異なる第３の装置にデータ変換を依頼する機能を持つので、送信、受信装置ではできないフォーマット変換を行うことが可能となる。前述の請求項１の例において、送信側のＰＣでも受信側の携帯端末でもMIDIからWAVEへの変換ができなかった場合に、第３の機械（例えばワークステーションやＰＣ）を用いてデータ変換することができる。第３の機械に自動的にフォーマット変換を依頼することによって、ユーザが意識することなくデータの送受信が行える。

　請求項６の通信装置によれば、変換の種類が複数ある場合には、変換に先立ち、変換を行つた場合の通信時間の推定値をユーザに提示して、ユーザが適切な方法を選択することができる。

　請求項７の通信装置によれば、受信側でデータを処理するソフトウエアなどの情報を保持しない場合には、その情報を送信側から得るので、変換を行うことなくデータを処理することができる。

請求項１の通信装置の実施例の構成を示すブロック図である。 請求項１の通信装置の実施例の動作を示すフローチャートである。 送信データの例を示す図である。 請求項２の通信装置の実施例の構成を示すブロック図である。 請求項２の通信装置の実施例の動作を示すフローチャートである。 請求項３の通信装置の実施例の構成を示すブロック図である。 請求項３の通信装置の実施例の動作を示すフローチャートである。 請求項５の通信装置の実施例の構成を示すブロック図である。 請求項５の通信装置の実施例の動作を示すフローチャートである。 請求項５の通信装置の実施例の動作を示すフローチャートである。 請求項６の通信装置の実施例の構成を示すブロック図である。 請求項６の通信装置の実施例の動作を示すフローチャートである。 請求項７の通信装置の実施例の構成を示すブロック図である。 請求項７の通信装置の実施例の動作を示すフローチャートである。

符号の説明

　１　表示部
　２　音声出力部
　３　通信部
　４　制御部
　５　リソース情報記憶部
　６　データ記憶部
　７　データ変換部
　８　変換テーブル
　９　変換手段格納部
　１０　ネゴシエーション部
　１１　性能評価記憶部
　１２　性能比較部
　２１　入力部
　２２　アドレス／識別子記憶部
　２３　アドレス／識別子付加部
　２４　変換依頼部
　２５　変換依頼受付部
　２６　通信時間推定部
　２７　出力用情報記憶部
　２８　出力用情報通信部

Claims (7)

1. 　文字、画像、図形、音声、音楽データ、及びデジタル化されたデータの全種類もしくはそのー部を含む情報を送受信する通信装置であって、データを処理するためのハードウエア及びソフトウエアからなるリソースに関する情報を記憶するリソース情報記憶手段と、データの送信に先立って、受信側の他の通信装置が同じリソースを有するか否かを判定すべく前記受信側の他の通信装置と通信するネゴシエーション手段と、前記受信側の他の通信装置が同じリソースを有さない場合に、送信すべきデータを前記受信側の他の通信装置のリソースで処理可能なデータに変換するための変換手段を記述した変換テーブルに基づいてデータ変換を行うデータ変換手段とを具備することを特徴とする通信装置。
2. 　前記通信装置の計算性能を示す性能評価値を記憶する性能評価値記憶手段と、前記通信装置の性能評価値と前記受信側の他の通信装置の性能評価値を比較する性能比較手段とを具備し、前記通信装置の性能評価値と前記受信側の他の通信装置の性能評価値を比較し、性能評価値が優位な通信装置で前記データ変換を行う請求項１に記載の通信装置。
3. 　各データに対してオリジナルデータがどこに存在するのかを記憶しておくオリジナルアドレス記憶手段と、通信のときにオリジナルデータがどこに存在するかの情報を付加するオリジナルアドレス付加手段とを具備し、前記受信側の他の通信装置においてオリジナルデータを得たい場合には、ユーザからの指示に基づきオリジナルデータを持つ他の通信装置からオリジナルデータを得る請求項１または２に記載の通信装置。
4. 　前記変換テーブルと、前記リソース情報記憶手段とが書換可能な媒体である請求項１から３のいずれか一項に記載の通信装置。
5. 　前記通信装置または前記受信側の他の通信装置と異なる第３の通信装置に対してデータ変換を依頼する変換依頼手段と、他の通信装置からの変換を受け付ける変換受け付け手段とを具備し、前記通信装置で前記受信側の他の通信装置が処理できるデータに変換できない場合には、前記第３の通信装置に対してデータを変換するよう依頼し、前記変換されたデータを前記受信側の他の通信装置へ送る請求項１から４のいずれか一項に記載の通信装置。
6. 　各種データ変換を行った場合のデータ転送に必要な時間の推定を行う通信時間推定手段と、データの送受信の際の通信時間の推定値を前記データ変換毎に表示する表示手段と、該表示手段に表示されるデータ変換の種類及び通信時間の情報に基づき任意の手法を選択する選択手段とを具備する請求項１から５のいずれか一項に記載の通信装置。
7. 　現在送信しようとしているデータを処理するためのソフトウエアを含めた情報を記憶する出力用情報記憶手段を具備し、前記受信側の他の通信装置にデータを処理するためのソフトウエアを含めた情報がなく、かつ送信側の通信装置に前記情報がある場合に、前記データとともに前記情報を送信する請求項１から６のいずれか一項に記載の通信装置。

Images