以下、本発明の通信装置の実施例を図を参照しながら説明する。
本実施例の通信装置は、図1に示すように、各部を制御する制御手段としての制御部4を有しており、制御部4にはバスライン20を介してテキストで静止画、動画などを表示する画像表示手段としての表示部1と、音楽や音声を出力する音声出力手段としての音声出力部2と、公衆回線、LAN、赤外線通信などを通じて他の装置と通信を行う通信手段としての通信部3と、指示等を入力する選択手段としての入力部21とが接続されている。更に、バスライン20には、装置がどのようなフォーマットのデータを扱うことができるかを記憶するリソース情報記憶手段としてのリソース情報記憶部5と、通信を行うデータを記憶する記憶部6と、通信相手が解釈できるようにデータの変換を行うデータ変換手段としてのデータ変換部7とが接続されており、かつ現在保持するデータが通信相手が解釈できる形に変換できるかどうかを記憶する変換テーブル手段としての変換テーブル8と、実際の変換手段を記憶する変換手段格納手段としての変換手段格納部9と、相手の装置のリソース情報がどのようなどのようなものかしるためのネゴシエーション手段としてのネゴシエーション部10とが接続されている。
なお、上述構成では受信したデータは人が見るあるいは聞くことを想定したものであるが、特に人に対して出力する必要はなく、出力部の代わりに処理部であっても構わない。また、受信されるデータは音声、音楽、画像、文字に限らず、形式が決まつているデジタルの数値列であれば表計算ソフトのデータやCAD(Computer Aided Design)やLSI配線のデータであっても構わない。このようにする場合には、図1のブロック図において音声出力部のところをデータ処理部と置き換える。
次に、本実施例の動作を図2のフローチャートに沿って説明する。
ステップS1でにおいて、送信するデータが設定され、ステップS2において、送信先が設定される。ステップS3において、ステップS2で設定された送信相手に送信要求が出され、ステップS4において、接続が成功したかどうかが判定される。接続が失敗した場合、通信が終了される。接続が成功した場合、ステップS5において、送信相手の端末の持つリソース情報が受信され、ステップS6において、ユーザは変換テーブル8を参照して入力部21により任意の変換手法を選択する。ステップS7において、選択された変換手法があったかどうかが判定される。もちろん変換せずに済む場合も変換可能として判断される。ステップS8において、変換する手段がなかった場合、その旨が表示部1に表示されて通信が終了される。この場合は通信を終了しているが、一つのデータの中で異なるフォーマットが使用されている場合、例えば文字と静止画が混在する場合などには、一部を通信する(文字だけ通信する)ことも考えられる。この場合には、通信を終了せず、通信できるものだけを送ることも考えられる。選択された変換手法があった場合、ステップS9において、受信側で解釈可能なようにデータが変換される。変換が不要な場合にはなにもしない。ステップS10において、変換したデータが送信され、ステップS11において、通信が終了される。
受信側では、ステップS12において、送信要求が待機され、ステップS13において、送信要求が受理され、接続が確立したか判断される。接続が確立しない場合には再び受信待ちになる。ステップS14において、受信側端末の持つリソース情報が送信され、ステップS15において、受信側で解釈できる形のデータが受信され、ステップS16において、通信が終了される。
上述したフローでは送信側でデータ変換を行ったが、受信側で変換を行う場合も考えられる。またここでのフローでは呼びを発生する側がデータを送るように記述されているが、当然呼びを発生させる側がデータ受信を行ってもよい。これは以下の実施例でも同様である。なお通信相手のリソース情報を通信終了後も記憶しておくと、次回からネゴシエーションを行わずに済む。この場合に何らかの理由で相手のリソースが変更されたときには、それを通知することが必要である。また、他機種の出力の形態を模擬する機能があり、相手側のリソース情報を記憶していると、送信する前もしくは送信後に相手側でどのような形態で出力されるかを確認することが可能になる。
図3に送信データの例を示す。この例では、文章(TEXT1,TEXT2)、静止画(IMAGE1)、音楽(SOUND1)が含まれている。この場合には、例えば表1のような形式で送信される。この例では##というキーに続いてフォーマットが指定されている。この例の最初のデータはEUC TEXTと記述されていてEUCコードで書かれた文章が存在する。次にはJPEGの静止画データが、その次にはMIDI形式の音楽データが、最後に再びEUC形式の文章が格納されている。
上述した変換方法により変換された後の例は、表2に示すように、文章はEUCコードからSJIS(シフトJIS)コードに変換され、JPEGデータはビットマップデータに変換されている。MIDIはそのままであり、変換されていない。
表3に装置が持つリソース情報ファイルの例を示す。この例では、EUCの文章、BITMAP、MIDIなどを解釈可能であることを示している。すなわち、解釈可能なものしか通信できない。この例で上げられているように、アドレスデータやスケジュールデータなどもリソース情報として登録することが望ましい。変換プログラムを作成することで、機種により異なる住所やスケジュールフォーマットなどが、ユーザに意識させることなく変換が可能になる。
表4に変換テーブルの例を示す。この例では、変換前フォーマット:変換可能フォーマット1、変換可能フォーマット2、・・・・という形で記述されている。
尚、フォーマット名の前に「*」がついているのは非可逆変換を示している。非可逆変換とは、AをBに変換し、再びBをAに変換しようとしたとき、元のAが完全には復元できない変換を示している。言い換えると、変換を行ったときに元の情報の一部が失われる変換のことを指す。なお、請求項1の発明では、この非可逆変換かどうかは関係しない。ここで変換という言葉は元のデータもしくはそれに付険する情報、例えばファイル名、作成日時、作成装置アドレスなどを用いて別のデータを作り出す作業をいう。もとのデータはイメージであるものを、そのオリジナルデータがあるマシンのアドレスとそのイメージのファイル名とそのイメージの縦横の大きさだけに置き換えてしまうような操作も変換と呼んでいる。同様に動画データから1枚ないしは数枚の静止画を抜き出したデータを作る操作も変換である。
次に、本発明の通信装置の他の実施例を図を参照しながら説明する。なお、図1と同一構成部分には同一符号を付して説明を省略する。
本実施例の通信装置は、図4に示すように、当該機種の変換の性能を示す性能評価値記憶手段としての性能評価記憶部11と、当該機種と通信相手の機種から送られてきた性能評価を比較する性能比較手段としての性能比較部12とを具備している。
次に、本実施例の動作を図5のフローチャートに沿って説明する。
ステップS21において、送信するデータが設定され、ステップS22において、送信先が設定される。ステップS23において、ステップS22で設定された送信相手に送信要求が出され、ステップS24において、接続が成功したかどうかが判定される。接続が失敗したならば、ステップS34において通信が終了される。接続が成功した場合、ステップS25において、送信相手の端末の持つリソース情報が受信され、ステップS26において、通信相手の性能評価値が受信される。ステップS27において、変換テーブルを参照して入力部21により変換手法が選択され、ステップS28において、選択された変換手法があったかどうかが判定される。もちろん、変換せずに済む場合も変換可能として判断される。ステップS29において、変換する手段がなかった場合、その旨がユーザに伝えられて通信が終了される。この場合は通信を終了しているが、一つのデータの中で異なるフォーマットが使用されている場合、例えば文字と静止画が混在する場合などには、一部が通信できる(文字だけ通信できる)ことも考えられる。この場合には通信を終了せず、通信できるものだけを送ることも考えられる。ステップS30において、当該機種の性能評価値と通信相手の性能評価値が比較され、ステップS31において、当該機種の性能が通信相手よりもよいかどうかが判定される。ステップS32において、当該機種の性能が高いので当該機種にて受信側で解釈可能なようにデータが変換される。変換が不要な場合にはなにもしない。ステップS33において、変換したデータが送信され、ステップS34において、通信が終了される。
一方、受信側では、ステップS35において、送信要求が待機され、ステップS36において、送信要求が受理され、接続が確立したか否かが判断される。接続が確立しない場合には再び受信待ちになる。ステップS37において、受信側端末の持つリソース情報が送信され、ステップS38において、性能評価値が送信される。ステップS39において、データが受信され、ステップS40において、リソース情報と現在のデータのフォーマットとが比較されて変換が必要かどうかが判定される。ステップS41において、変換が行われ、ステップS42において、通信が終了される。
上述したフローでは変換手法を選択する前に性能評価値を受信しているが、当然、変換可能と判断された後に性能評価値を受信することも考えられる。また、性能評価値はただ一つの値ではなく、変換手法毎に記憶しておくことがより望ましい。機種の性能により、ある変換は他の機種に比較して相対的に高速に行えるが、別の変換は相対的に遅いということがありえる。変換手法毎に性能を記憶しておくと、現在必要な変換に対しての変換速度の比較が可能になり、より効率的に処理できる。また、この例では性能評価値は事前に速度測定プログラムなどにより測定されて、設定されているものとしているが、装置の現在の負荷、例えば複数のプログラムが走っていてCPUの負担が大きいとうによって性能評価値を動的に変更することも可能である。この場合には負荷の大きい機種ではなるべく変換作業を行わなくなる。CPUの性能で負荷の大きさに依らずユーザがどちらで変換するかを指定することも可能である。この場合には、2台の装置とも変換できる場合に必ずユーザに問い合わせることも可能であるし、「相手の装置がXであつたならば相手側で変換」などといったようなことをあらかじめ記憶しておくことも可能である。
次に、本発明の通信装置の他の実施例を図を参照しながら説明する。なお、図1と同一構成部分には同一符号を付して説明を省略する。
本実施例の通信装置は、図6に示すように、過去に受信したデータに対してオリジナルのデータがどこにあるかを記憶するオリジナルアドレス記憶手段としてのアドレス/識別子記憶部22と、現在送信しようとするデータに送信側装置のアドレスと、データを特定するための識別子を付加するオリジナルアドレス付加手段としてのアドレス/識別子付加部23とを具備しており、アドレス/識別子記憶部22は、現在記憶しているデータがオリジナルとまったく同じか、なんらかの変換によってオリジナルのデータが復元できる場合には、アドレス/識別子にはなにも記憶されないように構成されている。
次に、本実施例の動作を図7のフローチャートに沿って説明する。
ステップS51において、送信するデータが設定され、ステップS52において、送信先が設定される。ステップS53において、ステップS52で設定された送信相手に送信要求が出され、ステップS54において、接続が成功したかどうかが判定される。接続が失敗したならば、ステップS63において通信が終了される。接続が成功した場合、ステップS55において、送信相手の端末の持つリソース情報が受信され、ステップS56において、変換テーブルを参照して入力部21により変換手法が選択され、ステップS57において、選択された変換手法があったかどうかが判定される。もちろん、変換せずに済む場合も変換可能として判断される。ステップS58において、変換する手段がなかった場合、その旨がユーザに伝えられ通信が終了される。この場合は通信を終了しているが、一つのデータの中で異なるフォーマットが便用されている場合、例えば文字と静止画が混在する場合などには、一部が通信できる(文字だけ通信できる)ことも考えられる。この場合には通信を終了せず、通信できるものだけを送ることも考えられる。ステップS59において変換が行われ、ステップS60において、ステップS59で行われた変換が可逆変換か不可逆変換かが判断される。ステップS61において、ステップS59で行われた変換が不可逆変換であつた場合に、そのデータのオリジナルのアドレスとデータ識別子が送信データに付加される。なお、可逆変換か不可逆変換かの判断は、表4の変換テーブルにあらかじめ記述しておくことで実現できる。アドレスとは、変換前のオリジナルデータを持つ装置にアクセスするための通信アドレスのことである。識別子とはオリジナルデータを保有する装置の中のどのデータを指しているかを特定するためのコードである。通常のファイルシステムであればディレクトリのパスとファイルネームでもよい。しかしパスとファイルネームではファイルの名前を変えただけで見つけられなくなるので、データと必ず一致するようなコードを採用することが望ましい。また、オリジナルデータのフォーマット情報もこのとき同時に付加することが望ましい。ステップS62において、変換したデータが送信され、ステップS63において、通信が終了される。
一方、受信側では、ステップS64において、送信要求が待機され、ステップS65において、送信要求が受理され、接続が確立したか否かが判断される。接続が確立しない場合には再び受信待ちになる。ステップS66において、受信側端末の持つリソース情報が送信され、ステップS67において、データが受信され、ステップS68において、通信が終了される。
本発明は例えば、以下のようにして適用される。A,B,Cの3種類の装置を仮定する。装置AとCは同等の能力をもつ装置、例えばパソコンであり、装置Bは装置A,Cに比較して劣った性能をもつもの、例えば携帯端末と仮定する。装置AにはデータXが存在する。これを装置Bに送る場合に、装置BがデータXを解釈する能力がないため、装置Aもしくは装置BでデータXは、これと異なるフォーマットに変換される。変換されたデータをX’とする。ここで行われた変換が不可逆変換であるとすると、本発明によつてデータX’にはオリジナルのデータを保持する装置Aのアドレスと、Xを装置A内で特定するための識別子が付加される。装置BではX’が解釈され、出力(表示)が行われる。更に、装置Bではそのデータを装置Cに送信することを考える。装置CではデータX’を解釈するが、データXのフォーマットも解釈する能力がある場合には、情報量の落ちたデータX’よりもデータXをユーザは望む可能性がある。この場合に、本発明によりデータX’にはデータXの存在する装置Aのアドレスとデータを特定する識別子を含んでいるので、装置Cから装置Aに対してデータXの送信を要求することが可能になる。例えば、データXはカラ−画像をJPEGによって圧縮したものであり、データX’は白黒のビットマップデータであるような場合である。装置CではデータX’を出力する場合に、同時に別のオリジナルデータが存在する旨の表示が行われ、かつ、ワンタッチで装置Aと通信し、オリジナルデータを出力できることが望ましい。また、この例ではオリジナルのアドレスを一つだけ付加するように記載しているが、送信された履歴として通過してきたすべての装置のアドレスを付加してもよい。インターネットの電子メールには通過してきたコンピュータのアドレスがすべて付加されている。
上述した説明では、不可逆変換を行いデータを送信した装置においてデータ消去されるとオリジナルのデータを得ることはできなくなるが、送信履歴をすべて付加しておくとデータが消去された場合でも他の装置へデータを要求することが可能になる。また、不可逆変換を行った場合にも、変換後のデータと併せて変換前のオリジナルデータを送信することも考えられる。この場合にはデータ量が増えるが、オリジナルデータは必ず保存されているので、オリジナルデータを必要とする場合に、新たに通信をする必要がない。
次に、本発明の通信装置の他の実施例を図を参照しながら説明する。
本実施例の通信装置の特徴は図1の変換テーブル8および変換手段格納部9を書換可能な媒体で構成することにある。このようにすることで新たなフォーマットが生まれても、そのフォーマットを既存の解釈できるフォーマットに変換する手段を後から追加することが可能となり、新しいフォーマットに対応することが可能になる。
次に、本発明の通信装置の他の実施例を図を参照しながら説明する。なお、図1と同一構成部分には同一符号を付して説明を省略する。
本実施例の通信装置は、図8に示すように、現在の通信相手ではない第3の装置に対してフォーマット変換を依頼する変換依頼手段としての変換依頼部24と、変換依頼を受け付ける変換受け付け手段としての変換依頼受付部25とを具備している。
次に、本実施例の動作を図9のフローチャートに沿って説明する。
ステップS71において、送信するデータが設定され、ステップS72において、送信先が設定される。ステップS73において、ステップS72で設定された送信相手に送信要求が出され、ステップS74において、接続が成功したかどうかが判定される。接続が失敗したならば通信は終了される。接続が成功した場合、ステップS75において、送信相手の端末の持つリソース情報が受信され、ステップS76において、変換テーブルが参照されて入力部21により変換手法が選択される。ステップS77において、変換手法があったかどうかが判定される。もちろん変換せずに済む場合も変換可能として判断される。ステップS78において、送受信側に変換する手段がなかった場合、第3の装置へ変換が依頼される。この依頼については後述する。ステップS79において、変換を依頼した結果が成功であったかどうかが判断され、ステップS80において、変換が失敗に終わった場合、変換不能の表示が出され、通信が終了される(ステップS83)。ステップS81において、当該機種の性能が高いので当該機種にて受信側で解釈可能なようにデータが変換される。変換が不要な場合にはなにもしない。ステップS82において、変換したデータが送信され、ステップS83において、通信が終了される。
一方、受信側では、ステップS84において、送信要求が待機され、ステップS85において、送信要求が受理され、接続が確立したか否かが判断される。接続が確立しない場合には再び受信待ちになる。ステップS86において、受信側端末の持つリソース情報が送信され、ステップS87において、受信側で解釈できる形のデータが受信される。ステップS88において、通信を終了される。
ここで、ステップS78の変換依頼について図10のフローチャートに沿って説明する。
ステップS91において、送信データが設定され、ステップS92において、変換依頼先が設定される。ステップS93において、変換依頼先の装置を呼び出される。ステップS94において、接続が確立したかどうかを判定される。ステップS95において、変換依頼が送信される。なお、変換依頼とは変換前のフォーマットと変換後のフォーマットを記述したものである。ステップS96において、依頼先の装置が要求した変換を行えるかどうかの結果が受信される。ステップS97において、変換可能であるかどうかを判断され、ステップS98において、変換要求の結果として変換不能が設定される。ステップS99において、変換不能の表示が行われ、通信が終了される(ステップS103)。また、上述ステップS97において変換可能であると判断された場合、ステップS100において、変換のためのデータが送信され、ステップS101において、変換されたデータが受信される。ステップS102において、変換の要求結果として変換成功が設定される。ステップS103において、通信を終了される。
一方、受信側では、ステップS104において、他の装置からの送信要求が待機され、ステップS105において、通信が確立したかどうかが判断される。ステップS106において、送信者の要求を受信される。ステップS107において、受信要求が変換要求であるかどうかが判断される。ステップS108において、変換要求以外であった場合、所定の他の処理が行われる。ステップS109において、送られてきた変換要求が可能かどうかが判定される。ステップS110において、変換できないと判定された場合、変換不能が送信される。ステップS111において、変換可能が送信される。ステップS112において、変換のためのデータが受信される。ステップS113において、実際に変換処理が行われる。ステップS114において、変換データが送信される。
なお、上述したフローでは送信の処理の途中で別の装置に対して変換要求を出しているが、もちろん、最初の通信を一度中断してから別の装置に変換要求を出し、変換が終わってから再度最初の送信相手を呼び出すことが望ましい。本発明は例えば機種の巣なる2台の携帯端末がデータのやり取りを行う場合において、携帯端末自身には変換の手段がないときに、第3の装置、例えばパソコンに対して変換要求を出して変換を行うといったように使用される。フローでは送信側の装置が変換要求を出した後に変換結果をもらい、その変換結果を受信装置に送るように記載されている。しかし、当然、変換を行う装置が変換結果を送信側に返さずに、直接受信側に送ることも考えられる。この場合には変換依頼送信もしくはデータ送信のときに送信先のアドレスを同時に変換側装置へ送ることが必要である。また、一回の変換要求において複数のデータの変換を行えることや、1台でなく複数台の装置に変換要求を出せるようにしておくことが望ましい。
次に、本発明の通信装置の他の実施例を図を参照しながら説明する。なお、図1と同一構成部分には同一符号を付して説明を省略する。
本実施例の通信装置は、図11に示すように、データ変換時間を含めた通信時間を推定する通信時間推定手段としての通信時間推定部26を具備する。
次に、本実施例の動作を図12のフローチャートに沿って説明する。
ステップS121において、送信するデータが設定される。ステップS122において、送信先が設定される。ステップS123において、ステップS122で設定された送信相手に送信要求が出される。ステップS124において、接続が成功したかどうかが判定される。接続が失敗したならば、通信が終了される(ステップS137)。接続が成功した場合、ステップS125において、通信速度が求められる。これは回線状態によって通信速度が変わる場合があることによる。モデムでは通常トレーニングによって通信速度が決定される。よってトレーニングの後では通信速度の概算が算定できる。ただし、誤り率などは完全には分からないので概算の数値となる。ステップS126において、送信相手の端末の持つリソース情報が受信される。ステップS127において、変換テーブルが参照されて入力部21により変換手法が選択される。ステップS128において、変換手法があったかどうかが判定される。もちろん変換せずに済む場合も変換可能として判断される。ステップS129において、変換不能の表示を出して、通信を終了される(ステップS137)。変換可能であると判断された場合、ステップS130において、変換に要する時間が推定される。この場合も変換手法やデータの種類によって完全な推定は困難である。よって標準のデータサイズの場合において要する時間を変換手法ごとに予め記憶した数値などと現在のデータ量から推定する手法が考えられる。ステップS131において、変換後のデータ容量が推定される。ステップS130と同じく完全には困難であるが、大ざっぱな値は標準的な数字から概算で求めることが可能である。ステップS132において、「変換後データ容量/通信速度+変換時間」などの式によって現在のデータ通信に必要な時間の概算が求められる。また、課金のための情報を記憶しておくことで、通信に要する通信料の概算をユーザに提示することも可能である。
ステップS133において、ステップS132で得られた所要時間が示され、ユーザにそのデータを送信してよいかどうかが確認される。ステップS134において、ユーザが送信を許可したかどうかが判定される。許可したと判断した場合、ステップS135において、データ変換が行われる。ステップS136において、データが送信される。ステップS137において、通信が終了される。
一方、受信側では、ステップS138において、送信要求が待機され、ステップS139において、送信要求を受理し、接続が確立したか判断される。接続が確立しない場合には再び受信待ちになる。接続が確立した場合、ステップS140において、受信側端末の持つリソース情報が送信される。ステップS141において、受信側で解釈できる形のデータが受信される。ステップS142において、通信が終了される。
なお、複数の変換手法がある場合にはそのすべてもしくは一部を表示してユーザに選択させることが望ましい。送信データに文字とイメージなど異なる種類のデータを含む場合には、オリジナルデータを得るための情報のみを送ることも考えられる。例えば、文字と動画を含むデータを電話回線をつかって送ろうとして、電話回絡で動画を送信するには時間がかかり過ぎるとユーザが判断した場合に、文字はすべての情報を送信し、動画はオリジナルのデータを得るためのアドレス情報でデータ識別子などのみを送るということが可能になる。なお、この場合には文字と画像の位置関係(座標情報)も併せて送ると、文字を表示したときに画像がどの位置に表示されるかを受信側のユーザに示すことが可能である。また、上述請求項3の実施例によって、動画データがほしい場合には送信要求を出すことでそのデータが得られる。ユーザに判断を求める場合には、あらかじめ条件を記述しておくことも考えられる。この場合にはユーザが事前に「10分以上通信を行うことはしない」とか「100円以上の通信を行うことはしない」とかの設定を入力し、その条件に合致する変換を選択して通信を行うことが可能である。また、文字、イメージ、及び音楽などの複数の情報が含まれたデータを送信する場合には、データ量が少ないものから送信を行うことが望ましい。
経験的に文字データはイメージデータに比較してデータ量が少なく、かつ1単位(バイト)あたりの情報量は多いので、データ量の少ないものから送信することで、通信が中断した場合に、多くの情報が届いている可能性が高い。また、使用法によってイメージデータが重要であるなどの要望がユーザによつて異なると考えられるので、ユーザがどのデータを先に通信したいかの設定を行えるようにすることが望ましい。
次に、本発明の通信装置の他の実施例を図を参照しながら説明する。なお、図1と同一構成部分には同一符号を付して説明を省略する。
本実施例の通信装置は、図13に示すように、データを出力もしくは処理するための情報(例えば出力用ソフトウエア)を記憶する出力用情報記憶手段としての出力用情報記憶部27と、出力用情報記憶部27で記憶されている情報を別の装置に送ったり、別の装置から出力用情報を得る出力用情報通信手段としての出力用情報通信部28とを具備している。なお、出力用情報記憶部27は上述実施例においては表示部や音声処理部の一部として存在しているものとする。
次に、本実施例の動作を図14のフローチャートに沿って説明する。
ステップS151において、送信するデータが設定される。ステップS152において、送信先が設定される。ステップS153において、ステップS152で設定された送信相手に送信要求が出される。ステップS154において、接続が成功したかどうかが判定される。接続が失敗したならば通信が終了される(ステップS164)。接続が成功した場合、ステップS155において、送信相手の端末の持つリソース情報が受信される。この場合のリソース情報には、受信装置の機種も記録されているとする。ステップS156において、受信側の装置で出力もしくは処理が可能かどうかがリソース情報を用いて判定される。出力可能でない場合、ステップS157において、受信側で出力が不能であるので、送信側で受信装置用の出力用情報を記憶しているかどうかが判定される。この判定にはリソース情報の中の機種情報が利用される。送信側で受信装置用の出力用情報を記憶していると判断された場合、ステップS158において、受信装置に対して出力用情報の送信要求が出される。ステップS159において、送信可能かどうかが受信される。ステップS160において、送信可能かどうかが判定される。送信可能であると判断された場合、ステップS161において、出力用情報が送信される。ステップS162において、データ送信が要求される。ステップS163において、データが送信される。ステップS164において、通信を終了される。
一方、受信側では、ステップS165において、送信要求が待機されている。ステップS166において、送信要求が受理され、接続が確立したか否かが判断される。接続が確立しない場合には再び受信待ちになる。接続が確立した場合、ステップS167において、受信側装置の持つリソース情報が送信される。ステップS168において、送信要求が受信される。ステップS169において、送信要求がデータのためのものか出力情報のためのものかが判定される。出力用情報であると判断された場合、ステップS170において、出力用情報を受信するかどうかが判断される。これは受信側のメモリ容量などにより判定しても構わないし、ユーザに受信するかどうかを問い合わせても実現できる。受信不可であると判断された場合、ステップS171において、受信不能が送信される。受信可であると判断された場合、ステップS172において、受信可能が送信される。ステップS173において、出力用情報が受信される。
上述ステップS169において、送信要求がデータのためのものであると判断された場合、ステップS174において、データが受信され、ステップS175において、通信が終了される。
今、送信側がデータXを送信したい場合であって、受信側でデータXを出力もしくは処理する情報がないと仮定される。この場合に本発明を用いれば、自動的に送信側装置からデータXを出力するための情報を受信側に送ることができ、あらかじめ出力用の情報を受信側装置に用意しておかなくても、データを出力することが可能になる。例えば、1台のパソコンに携帯端末で出力するための情報をすべて蓄えておくことで、携帯端末は、個々に出力用ソフトをインストールすることなく、パソコンからのデータ受信時に自動的にソフトがインストールされることになる。当然、ここでは著作権の問題が生じるため、出力用情報にはコピー可能、不能のフラグを立てておき、可能フラグが立っているものだけが対象となるようにしておく。また、一度コピーしたソフトに対しては再度複製をとらないようにコピー不能フラグを持つようなことも可能である。
請求項1のデータ通信装置によれば、変換手法選択手段により送信データに含まれるデータのフォーマット変換手法が選択され、選択された変換手法により、送信データに含まれる2つ以上のフォーマットのデータのうち1つ以上のデータについてデータ変換手段がデータ変換を行い、アドレス・識別子付加手段が、前記データ変換を行う前のデータを特定するためのアドレスおよび識別子を送信データに付加し、送信手段が、前記データ変換後のデータを含む送信データを送信する。
これにより、変換によってオリジナルの情報が失われる場合には、オリジナルデータがどこにあるかの情報をつけて送ることにより、容易にオリジナルデータを得ることができる。
本発明を用いると、WAVEフォーマットとともに元のMIDIフォーマットを保持するかもしくは、元のMIDIフォーマットがどこにあったかの情報を保持することで、元のMIDIフォーマットが欲しい場合であっても、簡単な操作で呼び出すことができる。
請求項2のデータ通信装置によれば、アドレス・識別子付加手段は、行われた前記データ変換が不可逆変換である場合のみ付加される。これにより、データ変換が不可逆変換であり受信側でデータ変換を行う前のデータの復元が不可能である場合にのみ、受信側ユーザによるデータ取得を可能とし、データ変換が可逆変換であり付加されたアドレスにアクセスしなくとも受信側でデータ変換を行う前のデータを復元可能である場合には、アドレスおよび識別子を送信しないことにより送信データ量を削減する。
請求項3のデータ通信装置によれば、データ変換手段は、変換前のデータを削除する。これにより、送信データ量をさらに削減する。
請求項4のデータ通信装置によれば、変換方法選択手段は、受信側の他の通信装置の機器情報に基づいて変換手法を選択する。これにより、より適切なフォーマットで受信側の他の通信装置にデータを送信することが可能となる。
請求項5のデータ通信装置によれば、ネゴシエーション手段が、データの送信に先立って、受信側の他の通信装置が送信するデータの処理に必要なリソースを有するか否かを判定するように前記受信側の他の通信装置と通信する。これにより、一層適切なフォーマットで受信側の他の通信装置にデータを送信することが可能となる。
請求項6のデータ通信装置は、受信したデータを変換、送信する。
請求項7のデータ通信方法によれば、変換手法選択ステップにおいて送信データに含まれるデータのフォーマット変換手法が選択され、データ変換ステップにおいて送信データに含まれる2つ以上のフォーマットのデータのうち1つ以上のデータについて前記選択手段により選択された変換手法によりデータ変換が行われ、アドレス・識別子付加ステップにおいて前記データ変換を行う前のデータを特定するためのアドレスおよび識別子が送信データに付加され、送信ステップにおいて前記データ変換後のデータを含む送信データが送信される。
請求項8のプログラムによれば、請求項7記載のデータ通信方法が実行される。