JP2007310902A - 受信側通信装置 - Google Patents
受信側通信装置 Download PDFInfo
- Publication number
- JP2007310902A JP2007310902A JP2007184041A JP2007184041A JP2007310902A JP 2007310902 A JP2007310902 A JP 2007310902A JP 2007184041 A JP2007184041 A JP 2007184041A JP 2007184041 A JP2007184041 A JP 2007184041A JP 2007310902 A JP2007310902 A JP 2007310902A
- Authority
- JP
- Japan
- Prior art keywords
- data
- conversion
- communication
- communication device
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
- Information Transfer Between Computers (AREA)
Abstract
【課題】データフォーマットが異なっても通信が行える通信装置を提供する。
【解決手段】公衆回線、LAN、赤外線通信などを通じて他の装置と通信を行う通信部3と、装置がどのようなフォーマットのデータを扱うことができるかを記憶するリソース情報記憶部5と、通信を行うデータを記憶する記憶部6と、通信相手が解釈できるようにデータの変換を行うデータ変換部7と、現在保持するデータが通信相手が解釈できる形に変換できるかどうかを記憶する変換テーブル8と、実際の変換手段を記憶する変換手段格納部9と、相手の装置のリソース情報がどのようなどのようなものか知るネゴシエーション部10とが配設されている。
【選択図】図1
【解決手段】公衆回線、LAN、赤外線通信などを通じて他の装置と通信を行う通信部3と、装置がどのようなフォーマットのデータを扱うことができるかを記憶するリソース情報記憶部5と、通信を行うデータを記憶する記憶部6と、通信相手が解釈できるようにデータの変換を行うデータ変換部7と、現在保持するデータが通信相手が解釈できる形に変換できるかどうかを記憶する変換テーブル8と、実際の変換手段を記憶する変換手段格納部9と、相手の装置のリソース情報がどのようなどのようなものか知るネゴシエーション部10とが配設されている。
【選択図】図1
Description
本発明は、通信装置に関し、特に文字、画像、音声などのデータを公衆回線網、LAN、赤外線通信などのネットワークを通じて送受信する通信装置に関する。
従来、ネットワークを用いたデータ通信においては、送信側があらかじめ受信側のデータ処理能力および機能を知っていて、それに合わせたデータを送っている。例えば、テレビ放送では放送局側は端末(テレビ)の能力に合わせた形式の信号を送信している。この方式では単一のデータフォーマットを仮定できる場合には問題ないが、多種類のフォーマットが存在し、かつ装置がそのうちの一部のフォーマットしか解釈できない場合には、受信できないという問題がある。送信側の装置が所定のフォーマットを仮定してデータを送信しても、受信側がそのフォーマットを理解できない事があるからである。
また、テレビより進んだ形式としてファクシミリがある。これはネゴシエーションの部分でどのような通信速度で通信が可能であるかなどの情報をやり取りを行い、その上で両者が扱うことのできる通信速度及びプロトコルで送受信を行う。この手法は、通信プロトコルの選択を行うが、データフォーマットの変更を行うわけではない。よってデータフォーマットの異なりについての問題は解決されない。
そこで、この問題点を解消するものとして、扱うデータをカラー静止画像に限った場合には、特開平5−260242号公報で示される方式が存在する。これは、データ通信に先駆けてネゴシエーションを行い、受信装置が処理できる形式に送信側で変換してからデータを送る。
しかしながら、特開平5−260242号公報で示される方式では扱うデータがカラー静止画像画像のみを対象としている。静止画像以外のデータの通信に対しては方法が存在しない。またカラー画像であってもそのカラーの扱い方のみを述べているのであって、画像サイズの違いなどについては触れられていない。
例えば文字データの例を考えると、通常ワードプロセッサは文章や図形の格納のための機種固有のフォーマットをもっており、フォーマットの異なる機種で通信を行おうとすると何らかの変換が必要である。同様に個人用の携帯端末ではアドレスやスケジュールを格納するために固有のフォーマットを有している。理想的にはこれらは唯一の共通フォーマットに統一されることが望ましいが、それが事実上困難である場合には、なんらかの変換の手段が必要となる。また、他のデータでも同様であり、動画の場合にはMPEG1、MPEG2などの標準フォーマットの他にマイクロソフト社のAVIフォーマットやアップル社のQuickTimeフォーマットなどがある。音楽では波形そのものを送る場合であってもサンプリング周波数や1サンプルのビット精度などの選択の余地があり、またMIDIなどの記号情報で送る場合もある。通信を行う機器が相互に同じフォーマットを解釈できる能力があることが望ましいが、他種類の機種の間で通信を行おうとすると、この仮定は必ずしも成り立たない。このため、データ通信に先立ち送信側と受信側でネゴシエーションを行い、送信装置において受信側で扱える形式に変換して送信することが望ましい。もし、フォーマットとしては送信が可能な場合であっても受信側の記憶容量などが問題になることも考えられる。
本発明は、上記のような課題を解消するためになされたもので、データフォーマットが異なっても通信が行える通信装置を提供することを目的とする。
本発明によれば、前述の目的は、文字、画像、図形、音声及び音楽データを含む情報を送受信する通信装置であって、データを処理するためのハードウエア及びソフトウエアからなるリソースに関する情報を記憶するリソース情報記憶手段と、データの送信に先立って、受信側の他の通信装置が同じリソースを有するか否かを判定すべく前記受信側の他の通信装置と通信するネゴシエーション手段と、前記受信側の他の通信装置が同じリソースを有さない場合に、送信すべきデータを前記受信側の他の通信装置のリソースで処理可能なデータに変換するための変換手段を記述した変換テーブルに基づいてデータ変換を行うデータ変換手段とを具備する請求項1の通信装置によって達成される。
本発明によれば、前述の目的は、前記通信装置の計算性能を示す性能評価値を記憶する性能評価値記憶手段と、前記通信装置の性能評価値と前記受信側の他の通信装置の性能評価値を比較する性能比較手段とを具備し、前記通信装置の性能評価値と前記受信側の他の通信装置の性能評価値を比較し、性能評価値が優位な通信装置で前記データ変換を行う請求項2の通信装置によって達成される。
本発明によれば、前述の目的は、各データに対してオリジナルデータがどこに存在するのかを記憶しておくオリジナルアドレス記憶手段と、通信のときにオリジナルデータがどこに存在するかの情報を付加するオリジナルアドレス付加手段とを具備し、前記受信側の他の通信装置においてオリジナルデータを得たい場合には、ユーザからの指示に基づきオリジナルデータを持つ他の通信装置からオリジナルデータを得る請求項3の通信装置によって達成される。
本発明によれば、前述の目的は、前記変換テーブルと、前記リソース情報記憶手段とが書換可能な媒体である請求項4の通信装置によって達成される。
本発明によれば、前述の目的は、前記通信装置または前記受信側の他の通信装置と異なる第3の通信装置に対してデータ変換を依頼する変換依頼手段と、他の通信装置からの変換を受け付ける変換受け付け手段とを具備し、前記通信装置で前記受信側の他の通信装置が処理できるデータに変換できない場合には、前記第3の通信装置に対してデータを変換するよう依頼し、前記変換されたデータを前記受信側の他の通信装置へ送る請求項5の通信装置によって達成される。
本発明によれば、前述の目的は、各種データ変換を行った場合のデータ転送に必要な時間の推定を行う通信時間推定手段と、データの送受信の際の通信時間の推定値を前記データ変換毎に表示する画像表示手段と、画像表示手段に表示されるデータ変換の種類及び通信時間の情報に基づき任意の手法を選択する選択手段とを具備する請求項6の通信装置によって達成される。
本発明によれば、前述の目的は、現在送信しようとしているデータを処理するためのソフトウエアを含めた情報を記憶する出力用情報記憶手段を具備し、前記受信側の他の通信装置にデータを処理するためのソフトウエアを含めた情報がなく、かつ送信側の通信装置に前記情報がある場合に、前記データとともに前記情報を送信する請求項7の通信装置によって達成される。
請求項1の通信装置によれば、リソース情報記憶手段により装置のハードウエア及びソフトウエア情報が記憶され、ネゴシエーション手段によりデータの送信に先立って、受信側が同じリソースを有するか否かを判定すべく受信側と通信し、変換テーブルにより送信すべきデータを処理するためのリソースが受信側にない場合に受信側のリソースで処理できるようにするための変換手段が記述され、この変換テーブルに基づいてデータ変換手段によりデータ変換が行われる。これにより、装置間でハードウエアやソフトウエア、データフォーマットの違いを吸収するため、ユーザはそれらの異なりを気にすることなく、常に最良のデータを受信または送信することが可能になる。
請求項2の通信装置によれば、性能評価値記憶手段により装置の計算性能を示す性能評価値が記憶され、性能比較手段により送信側の性能評価値と受信側の性能評価値が比較され、通信に際してデータフォーマットの変換が必要な場合かつ送信側と受信側の両方ともその変換を行うことが可能な場合に、計算性能が比較され、性能が優位な装置で変換が行われる。これによりフォーマット変換を含めた通信時間を短縮し得る。
請求項3の通信装置によれば、オリジナルアドレス記憶手段により各データに対するオリジナルデータがどこに存在するのかが記憶され、オリジナルアドレス付加手段により通信のときにオリジナルデータがどこに存在するかの情報が付加され、受信側装置においてデータのオリジナルデータを得たい場合には、指示に基づきオリジナルデータを持つ装置からオリジナルデータが得られる。
請求項4の通信装置によれば、前記変換テーブルと、リソース情報記憶部とは書換可能である。これにより、新しいリソースを容易に追加できる。
請求項5の通信装置によれば、変換依頼手段により送信または受信装置と異なる第3の装置に対して変換が依頼され、変換受け付け手段により他の装置からの変換が受け付けられ、送信側で受信装置が解釈できる形式に変換できない場合には、第3の装置に対して変換を行うよう依頼され、その変換結果が受信装置へ送られる。これにより、送信側及び受信側でできないフォーマット変換を行うことが出来る。
請求項6の通信装置によれば、通信時間推定手段により各種変換を行った場合のデータ転送に必要な時間の推定が行われ、画像表示手段によりデータの送受信の際に通信時間の推定値がデータ変換毎に表示され、選択手段により画像表示手段に表示される変換の種類及び通信時間の情報に基づき任意の手法が選択される。従って、ユーザが適切な変換手法を選択することが可能となる。
請求項7の通信装置によれば、出力用情報記憶手段により現在送信しようとしているデータを処理するためのソフトウエアを含めた情報が記憶され、出力用情報通信手段によりその出力用情報が送受信され、受信側でデータ出力もしくは処理のためのソフトウエアを含めた情報がなく、かつ送信側にその情報がある場合に、データとともに該情報が送受信される。従って、変換を行うことなくデータを処理することが出来る。
以下、請求項1の通信装置の実施例を図を参照しながら説明する。
本実施例の通信装置は、図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などを解釈可能であることを示している。すなわち、解釈可能なものしか通信できない。この例で上げられているように、アドレスデータやスケジュールデータなどもリソース情報として登録することが望ましい。変換プログラムを作成することで、機種により異なる住所やスケジュールフォーマットなどが、ユーザに意識させることなく変換が可能になる。
尚、フォーマット名の前に「*」がついているのは非可逆変換を示している。非可逆変換とは、AをBに変換し、再びBをAに変換しようとしたとき、元のAが完全には復元できない変換を示している。言い換えると、変換を行ったときに元の情報の一部が失われる変換のことを指す。なお、請求項1の発明では、この非可逆変換かどうかは関係しない。ここで変換という言葉は元のデータもしくはそれに付険する情報、例えばファイル名、作成日時、作成装置アドレスなどを用いて別のデータを作り出す作業をいう。もとのデータはイメージであるものを、そのオリジナルデータがあるマシンのアドレスとそのイメージのファイル名とそのイメージの縦横の大きさだけに置き換えてしまうような操作も変換と呼んでいる。同様に動画データから1枚ないしは数枚の静止画を抜き出したデータを作る操作も変換である。
次に、請求項2の通信装置の実施例を図を参照しながら説明する。なお、図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であつたならば相手側で変換」などといったようなことをあらかじめ記憶しておくことも可能である。
次に、請求項3の通信装置の実施例を図を参照しながら説明する。なお、図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と通信し、オリジナルデータを出力できることが望ましい。また、この例ではオリジナルのアドレスを一つだけ付加するように記載しているが、送信された履歴として通過してきたすべての装置のアドレスを付加してもよい。インターネットの電子メールには通過してきたコンピュータのアドレスがすべて付加されている。
上述した説明では、不可逆変換を行いデータを送信した装置においてデータ消去されるとオリジナルのデータを得ることはできなくなるが、送信履歴をすべて付加しておくとデータが消去された場合でも他の装置へデータを要求することが可能になる。また、不可逆変換を行った場合にも、変換後のデータと併せて変換前のオリジナルデータを送信することも考えられる。この場合にはデータ量が増えるが、オリジナルデータは必ず保存されているので、オリジナルデータを必要とする場合に、新たに通信をする必要がない。
次に、請求項4の通信装置の実施例を図を参照しながら説明する。
本実施例の通信装置の特徴は図1の変換テーブル8および変換手段格納部9を書換可能な媒体で構成することにある。このようにすることで新たなフォーマットが生まれても、そのフォーマットを既存の解釈できるフォーマットに変換する手段を後から追加することが可能となり、新しいフォーマットに対応することが可能になる。
次に、請求項5の通信装置の実施例を図を参照しながら説明する。なお、図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台でなく複数台の装置に変換要求を出せるようにしておくことが望ましい。
次に、請求項6の通信装置の実施例を図を参照しながら説明する。なお、図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単位(バイト)あたりの情報量は多いので、データ量の少ないものから送信することで、通信が中断した場合に、多くの情報が届いている可能性が高い。また、使用法によってイメージデータが重要であるなどの要望がユーザによつて異なると考えられるので、ユーザがどのデータを先に通信したいかの設定を行えるようにすることが望ましい。
次に、請求項7の通信装置の実施例を図を参照しながら説明する。なお、図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の通信装置によれば、装置の持つハードウエア、ソフトウエア情報(リソース情報)を通信に先立ち送ることで、現在通信を行いたいデータフォーマットと受信側でのリソース情報を比較し、変換が必要であるならばデータ変換を施してから送信するので、データフォーマットが異なっても通信を行うことができる。
例えば、携帯端末とパーソナルコンピュータ(PC)を公衆電話回線を通じて結ぶことを考える。PC側で保持する音楽がMIDIフォーマットであるが、携帯端末側ではMIDIのデータフォーマットを解釈できず、WAVEフォーマットしか出力できないとする。本発明によると、この場合にもそれぞれのリソースを判定することで、PC側(もしくは携帯端末側)でMIDIフォーマットをフォーマットに変換して送ることが可能になる。
同様に、PC側で保持するスケジュールデータのフォーマットが携帯端末のスケジュールフォーマットと合わない場合であっても、変換プログラムを用意するだけで、自動的にそれぞれの機械がどのフォーマットを扱えるかを自動判別して変換し、ユーザはその変換を意識することなく、データを送受信することができる。
請求項2の通信装置によれば、変換する場合においては、送信側、受信側双方で変換できる能力がある場合には、装置の性能を比較して、性能のよい装置にて変換するので、変換を含めた通信時間を短縮できる。前述の請求項1の例では、PC側で変換するか携帯端末側で変換するかは実装の方法による。もし、携帯端末で変換する時間がPCで変換する場合に比較して極端に遅い場合には、携帯端末で変換するのは効率が悪い。本発明では、この場合にPCでの変換性能と携帯端末での変換性能を比較することで、性能の良い方で変換を行うことになる。
請求項3の通信装置によれば、変換によってオリジナルの情報が失われる場合には、オリジナルデータがどこにあるかの情報をつけて送ることにより、容易にオリジナルデータを得ることができる。前述の請求項2の例では、MIDIフォーマットからWAVEフォーマットに変換された場合に、MIDIフォーマットを復元することは不可能になる。これは、携帯端末でWAVEフォーマットを保持した場合に、さらにその画像を別のPCに送ったとしても、そのPCはMIDIフォーマットを得ることはできない。
本発明を用いると、WAVEフォーマットとともに元のMIDIフォーマットを保持するかもしくは、元のMIDIフォーマットがどこにあったかの情報を保持することで、元のMIDIフォーマットが欲しい場合であっても、簡単な操作で呼び出すことができる。
請求項4の通信装置によれば、リソース情報は書換可能な記憶媒体に収納することで、新たな周辺機器の購入や新たなソフトウエアの追加などにより容易にリソースを追加することができる。
請求項5の通信装置によれば、送信側および受信側と異なる第3の装置にデータ変換を依頼する機能を持つので、送信、受信装置ではできないフォーマット変換を行うことが可能となる。前述の請求項1の例において、送信側のPCでも受信側の携帯端末でもMIDIからWAVEへの変換ができなかった場合に、第3の機械(例えばワークステーションやPC)を用いてデータ変換することができる。第3の機械に自動的にフォーマット変換を依頼することによって、ユーザが意識することなくデータの送受信が行える。
請求項6の通信装置によれば、変換の種類が複数ある場合には、変換に先立ち、変換を行つた場合の通信時間の推定値をユーザに提示して、ユーザが適切な方法を選択することができる。
請求項7の通信装置によれば、受信側でデータを処理するソフトウエアなどの情報を保持しない場合には、その情報を送信側から得るので、変換を行うことなくデータを処理することができる。
1 表示部
2 音声出力部
3 通信部
4 制御部
5 リソース情報記憶部
6 データ記憶部
7 データ変換部
8 変換テーブル
9 変換手段格納部
10 ネゴシエーション部
11 性能評価記憶部
12 性能比較部
21 入力部
22 アドレス/識別子記憶部
23 アドレス/識別子付加部
24 変換依頼部
25 変換依頼受付部
26 通信時間推定部
27 出力用情報記憶部
28 出力用情報通信部
2 音声出力部
3 通信部
4 制御部
5 リソース情報記憶部
6 データ記憶部
7 データ変換部
8 変換テーブル
9 変換手段格納部
10 ネゴシエーション部
11 性能評価記憶部
12 性能比較部
21 入力部
22 アドレス/識別子記憶部
23 アドレス/識別子付加部
24 変換依頼部
25 変換依頼受付部
26 通信時間推定部
27 出力用情報記憶部
28 出力用情報通信部
Claims (7)
- 文字、画像、図形、音声、音楽データ、及びデジタル化されたデータの全種類もしくはそのー部を含む情報を送受信する通信装置であって、データを処理するためのハードウエア及びソフトウエアからなるリソースに関する情報を記憶するリソース情報記憶手段と、データの送信に先立って、受信側の他の通信装置が同じリソースを有するか否かを判定すべく前記受信側の他の通信装置と通信するネゴシエーション手段と、前記受信側の他の通信装置が同じリソースを有さない場合に、送信すべきデータを前記受信側の他の通信装置のリソースで処理可能なデータに変換するための変換手段を記述した変換テーブルに基づいてデータ変換を行うデータ変換手段とを具備することを特徴とする通信装置。
- 前記通信装置の計算性能を示す性能評価値を記憶する性能評価値記憶手段と、前記通信装置の性能評価値と前記受信側の他の通信装置の性能評価値を比較する性能比較手段とを具備し、前記通信装置の性能評価値と前記受信側の他の通信装置の性能評価値を比較し、性能評価値が優位な通信装置で前記データ変換を行う請求項1に記載の通信装置。
- 各データに対してオリジナルデータがどこに存在するのかを記憶しておくオリジナルアドレス記憶手段と、通信のときにオリジナルデータがどこに存在するかの情報を付加するオリジナルアドレス付加手段とを具備し、前記受信側の他の通信装置においてオリジナルデータを得たい場合には、ユーザからの指示に基づきオリジナルデータを持つ他の通信装置からオリジナルデータを得る請求項1または2に記載の通信装置。
- 前記変換テーブルと、前記リソース情報記憶手段とが書換可能な媒体である請求項1から3のいずれか一項に記載の通信装置。
- 前記通信装置または前記受信側の他の通信装置と異なる第3の通信装置に対してデータ変換を依頼する変換依頼手段と、他の通信装置からの変換を受け付ける変換受け付け手段とを具備し、前記通信装置で前記受信側の他の通信装置が処理できるデータに変換できない場合には、前記第3の通信装置に対してデータを変換するよう依頼し、前記変換されたデータを前記受信側の他の通信装置へ送る請求項1から4のいずれか一項に記載の通信装置。
- 各種データ変換を行った場合のデータ転送に必要な時間の推定を行う通信時間推定手段と、データの送受信の際の通信時間の推定値を前記データ変換毎に表示する表示手段と、該表示手段に表示されるデータ変換の種類及び通信時間の情報に基づき任意の手法を選択する選択手段とを具備する請求項1から5のいずれか一項に記載の通信装置。
- 現在送信しようとしているデータを処理するためのソフトウエアを含めた情報を記憶する出力用情報記憶手段を具備し、前記受信側の他の通信装置にデータを処理するためのソフトウエアを含めた情報がなく、かつ送信側の通信装置に前記情報がある場合に、前記データとともに前記情報を送信する請求項1から6のいずれか一項に記載の通信装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007184041A JP2007310902A (ja) | 2007-07-13 | 2007-07-13 | 受信側通信装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007184041A JP2007310902A (ja) | 2007-07-13 | 2007-07-13 | 受信側通信装置 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005152706A Division JP2005332409A (ja) | 2005-05-25 | 2005-05-25 | 通信装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007310902A true JP2007310902A (ja) | 2007-11-29 |
Family
ID=38843640
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007184041A Pending JP2007310902A (ja) | 2007-07-13 | 2007-07-13 | 受信側通信装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007310902A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012503374A (ja) * | 2008-09-27 | 2012-02-02 | 中▲興▼通▲訊▼股▲ふぇん▼有限公司 | メディア資源システム及びメディア資源の提供方法 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH05197643A (ja) * | 1992-01-22 | 1993-08-06 | Fuji Xerox Co Ltd | ファイル送受信装置 |
JPH05252384A (ja) * | 1992-03-02 | 1993-09-28 | Nippon Telegr & Teleph Corp <Ntt> | カラー静止画伝送方法 |
JPH0644122A (ja) * | 1992-07-24 | 1994-02-18 | Oki Electric Ind Co Ltd | マルチメディア情報管理システム |
JPH06205042A (ja) * | 1992-12-29 | 1994-07-22 | Fuji Xerox Co Ltd | 電子メール通信システム |
-
2007
- 2007-07-13 JP JP2007184041A patent/JP2007310902A/ja active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH05197643A (ja) * | 1992-01-22 | 1993-08-06 | Fuji Xerox Co Ltd | ファイル送受信装置 |
JPH05252384A (ja) * | 1992-03-02 | 1993-09-28 | Nippon Telegr & Teleph Corp <Ntt> | カラー静止画伝送方法 |
JPH0644122A (ja) * | 1992-07-24 | 1994-02-18 | Oki Electric Ind Co Ltd | マルチメディア情報管理システム |
JPH06205042A (ja) * | 1992-12-29 | 1994-07-22 | Fuji Xerox Co Ltd | 電子メール通信システム |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012503374A (ja) * | 2008-09-27 | 2012-02-02 | 中▲興▼通▲訊▼股▲ふぇん▼有限公司 | メディア資源システム及びメディア資源の提供方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0719016B1 (en) | Communication equipment | |
KR101003295B1 (ko) | 범용직렬버스 연결 | |
JP3547191B2 (ja) | 通信装置 | |
JP2009524975A (ja) | 通信網でのマルチメディアコンテンツ伝送方法及びシステム | |
EP3068070B1 (en) | Method and device for initiating network conference | |
WO2018103405A1 (zh) | 识别接入点和热点的方法及相关产品 | |
US20090296906A1 (en) | Image sharing system | |
KR20150032152A (ko) | 전자 장치 간의 편집 동작을 실행하는 방법 및 장치 | |
US20220261527A1 (en) | Information processing apparatus and non-transitory computer readable medium | |
CN110875850A (zh) | 一种固件升级方法、系统、可读存储介质及终端设备 | |
JP2015001784A (ja) | 情報処理システム、情報処理装置、及び情報処理プログラム | |
CN112346751A (zh) | 应用程序的安装方法、装置、电子设备和存储介质 | |
JP2008004103A (ja) | 通信装置 | |
JP6287501B2 (ja) | 情報処理装置及び情報処理プログラム | |
CN112788090B (zh) | 一种网络资源传输方法、装置及系统 | |
KR100361490B1 (ko) | 인터넷 tv를 이용한 인터넷 접속 방법 | |
JP2003150523A (ja) | 通信装置、その制御方法及び電子メールシステム | |
US8819147B2 (en) | Electronic mail receiving apparatus | |
TW200941282A (en) | Content management that addresses levels of functionality | |
JP2007310902A (ja) | 受信側通信装置 | |
JP3711129B2 (ja) | 通信装置 | |
JP2007317215A (ja) | 受信側通信装置 | |
CN101917476B (zh) | 超文本传输协议消息处理方法及其客户端系统 | |
JP2005332409A (ja) | 通信装置 | |
JP2007334903A (ja) | 通信装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091117 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100115 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100413 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20100810 |