JP3774542B2 - データ処理方法、データ処理装置、プリンタ及び記憶媒体 - Google Patents
データ処理方法、データ処理装置、プリンタ及び記憶媒体 Download PDFInfo
- Publication number
- JP3774542B2 JP3774542B2 JP11280997A JP11280997A JP3774542B2 JP 3774542 B2 JP3774542 B2 JP 3774542B2 JP 11280997 A JP11280997 A JP 11280997A JP 11280997 A JP11280997 A JP 11280997A JP 3774542 B2 JP3774542 B2 JP 3774542B2
- Authority
- JP
- Japan
- Prior art keywords
- protocol
- printer
- data processing
- node
- data
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、共通シリアスバスを介して、複数種類のプリンタのプロトコルを切り換えるためのデータ処理方法、データ処理装置、プリンタ及び記憶媒体に関するものである。
【０００２】
【従来の技術】
従来より、シリアスバスを介してプリンタにデータを送出するシステムとして、様々な種類のシステムが知られている。
【０００３】
例えば、ＳＣＳＩ（Small Computer System Interface ）、セントロニクス等、一般に広く用いられるようになったデファクトスタンダードのインターフェースを用いて、コンピュータからプリンタにデータを出力する技術が知られている。
【０００４】
【発明が解決しようとする課題】
しかしながら、シリアスバスを用いてプリンタデータを送出する従来のプリンタプロトコルは、プリンタメーカ固有の１つに限られていた。
したがって、拡張性に欠ける、という問題が生じていた。
特に、様々な種類の機器を接続するインターフェース、例えば、ＩＥＥＥ１３９４のようなインターフェースを用いて、プリントデータを出力する際には、かかる拡張性に欠けるという問題点は解決すべき大きな課題であった。
【０００５】
そこで、本発明は、上記の欠点を除去するために成されたもので、システムバスを介してプリントデータを送出する際に、拡張性の高いデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
また、本発明は、ＩＥＥＥ１３９４規格に好適なデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
また、本発明は、コンピュータを介することなく、画像データ出力デバイスから直接プリンタを接続するのに好適なデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
また、本発明は、最適なプリンタ出力を得ることができるデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
また、本発明は、プロトコルの切り替えによる負荷を下げることができるデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
【０００６】
【課題を解決するための手段】
本発明のデータ処理方法は、共通シリアスバスを介して複数デバイスのプロトコルを切り換えるためのデータ処理方法であって、前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行し、前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定し、前記初期プロトコルに続いて、決定されたプロトコルを実行することを特徴とする。
本発明のデータ処理装置は、共通シリアスバスを介して複数デバイスのプロトコルを切り換えるためのデータ処理装置であって、前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行する第１の実行手段と、前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定手段と、前記初期プロトコルに続いて、決定されたプロトコルを実行する第２の実行手段とを備えることを特徴とする。
本発明のプリンタは、共通シリアスバスを介して複数デバイスのプロトコルをホストに対応して切り換えるプリンタであって、前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行する第１の実行手段と、前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定手段と、前記初期プロトコルに続いて、決定されたプロトコルを実行する第２の実行手段とを備えることを特徴とする。
本発明の記憶媒体は、共通シリアスバスを介して複数デバイスのプロトコルを切り換えるためのデータ処理方法を実行するためのデータ処理ステップをコンピュータに実行させるためのコンピュータプログラムをコンピュータが読み取り可能に記憶した記憶媒体であって、前記データ処理方法は、前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行するステップと、前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定するステップと、前記初期プロトコルに続いて、決定されたプロトコルを実行するステップとを有することを特徴とする。
【０００７】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【０００８】
ここで、まず、以下に説明する第１及び第２の実施の形態では、各機器間を接続するディジタルＩ／Ｆとして、ＩＥＥＥ１３９４シリアルバスを用いているため、ＩＥＥＥ１３９４シリアルバスについて、予め説明する。
【０００９】
民生用デジタルＶＣＲやＤＶＤプレーヤの登場に伴なって、ビデオデータやオーディオデータなどのリアルタイムで、かつ高情報量のデータ転送のサポートが必要になっている。こういったビデオデータやオーディオデータをリアルタイムで転送し、パソコン（ＰＣ）に取り込んだり、またはその他のデジタル機器に転送を行なうには、必要な転送機能を備えた高速データ転送可能なインタフェースが必要になってくるものであり、そういった観点から開発されたインタフェースが、ＩＥＥＥ１３９４−１９９５（High Performance Serial Bus ）（以下、単に１３９４シリアルバスとも言う）である。
【００１０】
図１に１３９４シリアルバスを用いて構成されるネットワーク・システムの例を示す。
【００１１】
このシステムは、機器Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｈを備えており、Ａ−Ｂ間、Ａ−Ｃ間、Ｂ−Ｄ間、Ｄ−Ｅ間、Ｃ−Ｆ間、Ｃ−Ｇ間、及びＣ−Ｈ間をそれぞれ１３９４シリアルバスのツイスト・ペア・ケーブルで接続されている。この機器A 〜H は、例えばパソコン、デジタルＶＴＲ、ＤＶＤ、デジタルカメラ、ハードディスク、モニタ、チューナー、モニター等である。
【００１２】
各機器間の接続方式は、ディジーチェーン方式とノード分岐方式とを混在可
能としたものであり、自由度の高い接続が可能である。
【００１３】
また、各機器は各自固有のＩＤを有し、それぞれが認識し合うことによって１３９４シリアルバスで接続された範囲において、１つのネットワークを構成している。各デジタル機器間をそれぞれ１本の１３９４シリアルバスケーブルで順次接続するだけで、それぞれの機器が中継の役割を行い、全体として１つのネットワークを構成するものである。また、１３９４シリアルバス、Ｐｌｕｇ＆Ｐｌａｙ機能でケーブルを機器に接続した時点で自動で機器の認識や接続状況などを認識する機能を有している。
【００１４】
また、図１に示したようなシステムにおいて、ネットワークからある機器が削除されたり、または新たに追加されたときなど、自動的にバスリセットを行い、それまでのネットワーク構成をリセットしてから、新たなネットワークの再構築を行なう。この機能によって、その時々のネットワークの構成を常時設定、認識することができる。
【００１５】
またデータ転送速度は、１００／２００／４００Ｍｂｐｓと備えており、上位の転送速度を持つ機器が下位の転送速度をサポートし、互換をとるようになっている。
【００１６】
データ転送モードとしては、コントロール信号などの非同期データ（Asynchronousデータ：以下、Ａｓｙｎｃデータと言う）を転送するＡｓｙｎｃｈｒｏｎｏｕｓ転送モードとリアルタイムなビデオデータやオーディオデータ等の同期データ（Isochronous データ：以下、Ｉｓｏデータと言う）を転送するＩｓｏｃｈｒｏｎｏｕｓ転送モードがある。このＡｓｙｎｃデータとＩｓｏデータは各サイクル（通常１サイクル１２５μS ）の中において、サイクル開始を示すサイクル・スタート・パケット（ＣＳＰ）を転送した後、Ｉｓｏデータの転送をＡｓｙｎｃデータより優先しつつサイクル内で混在して転送される。
【００１７】
つぎに、図２に１３９４シリアルバスの構成要素を示す。
【００１８】
１３９４シリアルバスは全体としてレイヤ（階層）構造で構成されている。図２に示したように、１３９４シリアルバスのケーブルとコネクタが接続されるコネクタポートがあり、その上にハードウェアとしてフィジカル・レイヤとリンク・レイヤを位置づけしている。
【００１９】
ハードウェア部は実質的なインターフェイスチップの部分であり、そのうちフィジカル・レイヤは符号化やコネクタ関連の制御等を行い、リンク・レイヤはパケット転送やサイクルタイムの制御等を行なう。
【００２０】
ファームウェア部のトランザクション・レイヤは、転送（トランザクション）すべきデータの管理を行ない、Ｒｅａｄ、Ｗｒｉｔｅ、Ｌｏｃｋの命令を出す。マネージメント・レイヤは、接続されている各機器の接続状況やＩＤの管理を行ない、ネットワークの構成を管理する部分である。
【００２１】
このハードウェアとファームウェアまでが実質上の１３９４シリアルバスの構成である。
【００２２】
またソフトウェア部のアプリケーション・レイヤは使うソフトによって異なり、インタフェース上にどのようにデータをのせるか規定する部分であり、プリンタやＡＶＣプロトコルなどが規定されている。
【００２３】
以上が１３９４シリアルバスの構成である。
【００２４】
つぎに、図３に１３９４シリアルバスにおけるアドレス空間の図を示す。
【００２５】
１３９４シリアルバスに接続された各機器（ノード）には必ず各ノード固有の、６４ビットアドレスを持たせておく。そしてこのアドレスをＲＯＭに格納しておくことで、自分や相手のノードアドレスを常時認識でき、相手を指定した通信も行なえる。
【００２６】
１３９４シリアルバスのアドレッシングは、ＩＥＥＥ１２１２規格に準じた方式であり、アドレス設定は、最初の１０ｂｉｔがバスの番号の指定用に、次の６ｂｉｔがノードＩＤ番号の指定用に使われる。残りの４８ｂｉｔが機器に与えられたアドレス幅になり、それぞれ固有のアドレス空間として使用できる。最後の２８ｂｉｔは固有データの領域として、各機器の識別や使用条件の指定の情報などを格納する。
【００２７】
以上が１３９４シリアルバスの技術の概要である。
【００２８】
つぎに、１３９４シリアルバスの特徴といえる技術の部分を、より詳細に説明する。
【００２９】
１３９４シリアルバスの電気的仕様について説明する。
【００３０】
図４に１３９４シリアルバス・ケーブルの断面図を示す。
【００３１】
１３９４シリアルバスでは接続ケーブル内に６ピン、即ち２組のツイストペア信号線の他に、電源ラインを設けている。これによって、電源を持たない機器や、故障により電圧低下した機器等にも電力の供給が可能になっている。
【００３２】
電源線内を流れる電源の電圧は８〜４０Ｖ、電流は最大電流DC１．５Ａと規定されている。
【００３３】
なお、ＤＶケーブルと呼ばれる規格では電源を省いた４ピンで構成されている。
【００３４】
ＤＳ−Ｌｉｎｋ符号化について説明する。
【００３５】
１３９４シリアルバスで採用されている、データ転送フォーマットのＤＳ−Ｌｉｎｋ符号化方式を説明するための図を図５に示す。
【００３６】
１３９４シリアルバスでは、ＤＳ−Ｌｉｎｋ（Data／Strobe Link ）符号化方式が採用されている。このＤＳ−Ｌｉｎｋ符号化方式は、高速なシリアルデータ通信に適しており、その構成は、２本の信号線を必要とする。より対線のうち１本に主となるデータを送り、他方のより対線にはストローブ信号を送る構成になっている。受信側では、この通信されるデータと、ストローブとの排他的論理和をとることによってクロックを再現する。
【００３７】
このＤＳ−Ｌｉｎｋ符号化方式を用いるメリットとして、８／１０Ｂ変換に比べて転送効率が高いこと、ＰＬＬ回路が不要となるのでコントローラＬＳＩの回路規模を小さくできること、更には、転送すべきデータが無いときにアイドル状態であることを示す情報を送る必要が無いので、各機器のトランシーバ回路をスリープ状態にすることができることによって、消費電力の低減が図れる、などが挙げられる。
【００３８】
バスリセットのシーケンスについて説明する。
【００３９】
１３９４シリアルバスでは、接続されている各機器（ノード）にはノードＩＤが与えられ、ネットワーク構成として認識されている。
【００４０】
このネットワーク構成に変化があったとき、例えばノードの挿抜や電源のＯＮ／ＯＦＦなどによるノード数の増減などによって変化が生じて、新たなネットワーク構成を認識する必要があるとき、変化を検知した各ノードはバス上にバスリセット信号を送信して、新たなネットワーク構成を認識するモードに入る。
【００４１】
このときの変化の検知方法は、１３９４ポート基盤上でのバイアス電圧の変化を検知することによって行われる。
【００４２】
あるノードからバスリセット信号が伝達されて、各ノードのフィジカルレイヤはこのバスリセット信号を受けると同時にリンクレイヤにバスリセットの発生を伝達し、かつ他のノードにバスリセット信号を伝達する。最終的にすべてのノードがバスリセット信号を検知した後、バスリセットが起動となる。
【００４３】
バスリセットは、先に述べたようなケーブル抜挿や、ネットワーク異常等によるハード検出による起動と、プロトコルからのホスト制御などによってフィジカルレイヤに直接命令を出すことによっても起動する。
また、バスリセットが起動するとデータ転送は一時中断され、この間のデータ転送は待たされ、終了後、新しいネットワーク構成のもとで再開される。
【００４４】
以上がバスリセットのシーケンスである。
【００４５】
ノードＩＤ決定のシーケンスについて説明する。
【００４６】
バスリセットの後、各ノードは新しいネットワーク構成を構築するために、各ノードにＩＤを与える動作に入る。このときの、バスリセットからノードＩＤ決定までの一般的なシーケンスを図６、７、８のフローチャートを用いて説明する。
【００４７】
図６のフローチャートは、バスリセットの発生からノードＩＤが決定し、データ転送が行えるようになるまでの、一連のバスの作業を示してある。
【００４８】
まず、ステップＳ１０１として、ネットワーク内にバスリセットが発生することを常時監視していて、ここでノードの電源ＯＮ／ＯＦＦなどでバスリセットが発生するとステップＳ１０２に移る。
【００４９】
ステップＳ１０２では、ネットワークがリセットされた状態から、新たなネットワークの接続状況を知るために、直接接続されている各ノード間において親子関係の宣言がなされる。ステップＳ１０３として、すべてのノード間で親子関係が決定すると、ステップＳ１０４として一つのルートが決定する。すべてのノード間で親子関係が決定するまで、ステップＳ１０２の親子関係の宣言をおこない、またルートも決定されない。
【００５０】
ステップＳ１０４でルートが決定されると、次はステップＳ１０５として、各ノードにＩＤを与えるノードＩＤの設定作業が行われる。所定のノード順序で、ノードＩＤの設定が行われ、すべてのノードにＩＤが与えられるまで繰り返し設定作業が行われ、最終的にステップＳ１０６としてすべてのノードにＩＤを設定し終えたら、新しいネットワーク構成がすべてのノードにおいて認識されたので、ステップＳ１０７としてノード間のデータ転送が行える状態となり、データ転送が開始される。
【００５１】
このステップＳ１０７の状態になると、再びバスリセットが発生するのを監視するモードに入り、バスリセットが発生したらステップＳ１０１からステップＳ１０６までの設定作業が繰り返し行われる。
【００５２】
以上が、図６のフローチャートの説明であるが、図６のフローチャートのバスリセットからルート決定までの部分と、ルート決定後からＩＤ設定終了までの手順をより詳しくフローチャート図に表したものをそれぞれ、図７、図８に示す。
【００５３】
まず、図７のフローチャートの説明を行う。
【００５４】
ステップＳ２０１としてバスリセットが発生すると、ネットワーク構成は一旦リセットされる。なお、ステップＳ２０１としてバスリセットが発生するのを常に監視している。
【００５５】
次に、ステップＳ２０２として、リセットされたネットワークの接続状況を再認識する作業の第一段階として、各機器にリーフ（ノード）であることを示すフラグを立てておく。さらに、ステップＳ２０３として各機器が自分の持つポートがいくつ他ノードと接続されているのかを調べる。
【００５６】
ステップＳ２０４のポート数の結果に応じて、これから親子関係の宣言を始めていくために、未定義（親子関係が決定されてない）ポートの数を調べる。バスリセットの直後はポート数＝未定義ポート数であるが、親子関係が決定されていくにしたがって、ステップＳ２０４で検知する未定義ポートの数は変化していくものである。
【００５７】
まず、バスリセットの直後、はじめに親子関係の宣言を行えるのはリーフに限られている。リーフであるというのはステップＳ２０３のポート数の確認で知ることができる。リーフは、ステップＳ２０５として、自分に接続されているノードに対して、「自分は子、相手は親」と宣言し動作を終了する。
【００５８】
ステップＳ２０３でポート数が複数ありブランチと認識したノードは、バスリセットの直後はステップＳ２０４で未定義ポート数＞１ということなので、ステップＳ２０６へと移り、まずブランチというフラグが立てられ、ステップＳ２０７でリーフからの親子関係宣言で「親」の受付をするために待つ。
【００５９】
リーフが親子関係の宣言を行い、ステップＳ２０７でそれを受けたブランチは適宜ステップＳ２０４の未定義ポート数の確認を行い、未定義ポート数が１になっていれば残っているポートに接続されているノードに対して、ステップＳ２０５の「自分が子」の宣言をすることが可能になる。２度目以降、ステップＳ２０４で未定義ポート数を確認しても２以上あるブランチに対しては、再度ステップＳ２０７でリーフ又は他のブランチからの「親」の受付をするために待つ。
【００６０】
最終的に、いずれか１つのブランチ、又は例外的にリーフ（子宣言を行えるのにすばやく動作しなかった為）がステップＳ２０４の未定義ポート数の結果としてゼロになったら、これにてネットワーク全体の親子関係の宣言が終了したものであり、未定義ポート数がゼロ（すべて親のポートとして決定）になった唯一のノードはステップＳ２０８としてルートのフラグが立てられ、ステップＳ２０９としてルートとしての認識がなされる。
【００６１】
このようにして、図７に示したバスリセットから、ネットワーク内すべてのノード間における親子関係の宣言までが終了する。
【００６２】
つぎに、図８のフローチャートについて説明する。
【００６３】
まず、図８までのシーケンスでリーフ、ブランチ、ルートという各ノードのフラグの情報が設定されているので、これを元にして、ステップＳ３０１でそれぞれ分類する。
【００６４】
各ノードにＩＤを与える作業として、最初にＩＤの設定を行うことができるのはリーフからである。リーフ→ブランチ→ルートの順で若い番号（ノード番号＝０〜）からＩＤの設定がなされていく。
【００６５】
ステップＳ３０２としてネットワーク内に存在するリーフの数Ｎ（Ｎは自然数）を設定する。
【００６６】
この後、ステップＳ３０３として各自リーフがルートに対して、ＩＤを与えるように要求する。この要求が複数ある場合には、ルートはステップＳ３０４としてアービトレーションを行い、ステップＳ３０５として勝ったノード１つにＩＤ番号を与え、負けたノードには失敗の結果通知を行う。
【００６７】
ステップＳ３０６としてＩＤ取得が失敗に終わったリーフは、再度ＩＤ要求を出し、同様の作業を繰り返す。ＩＤを取得できたリーフからステップＳ３０７として、そのノードのＩＤ情報をブロードキャストで全ノードに転送する。１ノードＩＤ情報のブロードキャストが終わると、ステップＳ３０８として残りのリーフの数が１つ減らされる。
【００６８】
ここで、ステップＳ３０９として、この残りのリーフの数が１以上ある時はステップＳ３０３のＩＤ要求の作業からを繰り返し行い、最終的にすべてのリーフがＩＤ情報をブロードキャストすると、ステップＳ３０９がＮ＝０となり、次はブランチのＩＤ設定に移る。ブランチのＩＤ設定もリーフの時と同様に行われる。
【００６９】
まず、ステップＳ３１０としてネットワーク内に存在するブランチの数Ｍ（Ｍは自然数）を設定する。
【００７０】
この後、ステップＳ３１１として各自ブランチがルートに対して、ＩＤを与えるように要求する。これに対してルートは、ステップＳ３１２としてアービトレーションを行い、勝ったブランチから順にリーフに与え終った次の若い番号から与えていく。
【００７１】
ステップＳ３１３として、ルートは要求を出したブランチにＩＤ情報又は失敗結果を通知し、ステップＳ３１４としてＩＤ取得が失敗に終わったブランチは、再度ＩＤ要求を出し、同様の作業を繰り返す。
【００７２】
ＩＤを取得できたブランチからステップＳ３１５として、そのノードのＩＤ情報をブロードキャストで全ノードに転送する。
【００７３】
１ノードＩＤ情報のブロードキャストが終わると、ステップＳ３１６として残りのブランチの数が１つ減らされる。
【００７４】
ここで、ステップＳ３１７として、この残りのブランチの数が１以上ある時はステップＳ３１１のＩＤ要求の作業からを繰り返し、最終的にすべてのブランチがＩＤ情報をブロードキャストするまで行われる。すべてのブランチがノードＩＤを取得すると、ステップＳ３１７はＭ＝０となり、ブランチのＩＤ取得モードも終了する。
【００７５】
ここまで終了すると、最終的にＩＤ情報を取得していないノードはルートのみなので、ステップＳ３１８として与えていない番号で最も若い番号を自分のＩＤ番号と設定し、ステップＳ３１９としてルートのＩＤ情報をブロードキャストする。
【００７６】
以上で、図８に示したように、親子関係が決定した後から、すべてのノードのＩＤが設定されるまでの手順が終了する。
【００７７】
次に、一例として図９に示した実際のネットワークにおける動作を図９を参照しながら説明する。
【００７８】
図９の説明として、（ルート）ノードＢの下位にはノードＡとノードＣが直接接続されており、更にノードＣの下位にはノードＤが直接接続されており、更にノードＤの下位にはノードＥとノードＦが直接接続された階層構造になっている。この、階層構造やルートノード、ノードＩＤを決定する手順を以下で説明する。
【００７９】
バスリセットがされた後、まず各ノードの接続状況を認識するために、各ノードの直接接続されているポート間において、親子関係の宣言がなされる。この親子とは親側が階層構造で上位となり、子側が下位となると言うことができる。
【００８０】
図９ではバスリセットの後、最初に親子関係の宣言を行なったのはノードＡである。基本的にノードの１つのポートにのみ接続があるノード（リーフと呼ぶ）から親子関係の宣言を行なうことができる。これは自分には１ポートの接続のみということをまず知ることができるので、これによってネットワークの端であることを認識し、その中で早く動作を行なったノードから親子関係が決定されていく。こうして親子関係の宣言を行なった側（Ａ−Ｂ間ではノードＡ）のポートが子と設定され、相手側（ノードＢ）のポートが親と設定される。こうして、ノードＡ−Ｂ間では子−親、ノードＥ−Ｄ間で子−親、ノードＦ−Ｄ間で子−親と決定される。
【００８１】
さらに１階層あがって、今度は複数個接続ポートを持つノード（ブランチと呼ぶ）のうち、他ノードからの親子関係の宣言を受けたものから順次、更に上位に親子関係の宣言を行なっていく。図９ではまずノードＤがＤ−Ｅ間、Ｄ−Ｆ間と親子関係が決定した後、ノードＣに対する親子関係の宣言を行っており、その結果ノードＤ−Ｃ間で子−親と決定している。
【００８２】
ノードＤからの親子関係の宣言を受けたノードＣは、もう一つのポートに接続されているノードＢに対して親子関係の宣言を行なっている。これによってノードＣ−Ｂ間で子−親と決定している。
【００８３】
このようにして、図９のような階層構造が構成され、最終的に接続されているすべてのポートにおいて親となったノードＢが、ルートノードと決定された。
ルートは１つのネットワーク構成中に一つしか存在しないものである。
【００８４】
なお、この図９においてノードＢがルートノードと決定されたが、これはノードＡから親子関係宣言を受けたノードＢが、他のノードに対して親子関係宣言を早いタイミングで行なっていれば、ルートノードは他ノードに移っていたこともあり得る。すなわち、伝達されるタイミングによってはどのノードもルートノードとなる可能性があり、同じネットワーク構成でもルートノードは一定とは限らない。
【００８５】
ルートノードが決定すると、次は各ノードＩＤを決定するモードに入る。ここではすべてのノードが、決定した自分のノードＩＤを他のすべてのノードに通知する（ブロードキャスト機能）。
【００８６】
自己ＩＤ情報は、自分のノード番号、接続されている位置の情報、持っているポートの数、接続のあるポートの数、各ポートの親子関係の情報等を含んでいる。
【００８７】
ノードＩＤ番号の割り振りの手順としては、まず１つのポートにのみ接続があるノード（リーフ）から起動することができ、この中から順にノード番号＝０、１、２、・・・と割り当てられる。
【００８８】
ノードＩＤを手にしたノードは、ノード番号を含む情報をブロードキャストで各ノードに送信する。これによって、そのＩＤ番号は「割り当て済み」であることが認識される。
【００８９】
すべてのリーフが自己ノードＩＤを取得し終ると、次はブランチへ移りリーフに引き続いたノードＩＤ番号が各ノードに割り当てられる。リーフと同様に、ノードＩＤ番号が割り当てられたブランチから順次ノードＩＤ情報をブロードキャストし、最後にルートノードが自己ＩＤ情報をブロードキャストする。すなわち、常にルートは最大のノードＩＤ番号を所有するものである。
【００９０】
以上のようにして、階層構造全体のノードＩＤの割り当てが終わり、ネットワーク構成が再構築され、バスの初期化作業が完了する。
【００９１】
アービトレーションについて説明する。
【００９２】
１３９４シリアルバスでは、データ転送に先立って必ずバス使用権のアービトレーション（調停）を行なう。１３９４シリアルバスは個別に接続された各機器が、転送された信号をそれぞれ中継することによって、ネットワーク内すべての機器に同信号を伝えるように、論理的なバス型ネットワークであるので、パケットの衝突を防ぐ意味でアービトレーションは必要である。これによってある時間には、たった一つのノードのみ転送を行なうことができる。
【００９３】
アービトレーションを説明するための図として図１０（ａ）にバス使用要求の図（ｂ）にバス使用許可の図を示し、以下これを用いて説明する。
【００９４】
アービトレーションが始まると、１つもしくは複数のノードが親ノードに向かって、それぞれバス使用権の要求を発する。図１０（ａ）のノードＣとノードＦがバス使用権の要求を発しているノードである。これを受けた親ノード（図１０ではノードＡ）は更に親ノードに向かって、バス使用権の要求を発する（中継する）。この要求は最終的に調停を行なうルートに届けられる。
【００９５】
バス使用要求を受けたルートノードは、どのノードにバスを使用させるかを決める。この調停作業はルートノードのみが行なえるものであり、調停によって勝ったノードにはバスの使用許可を与える。図１０（ｂ）ではノードＣに使用許可が与えられ、ノードＦの使用は拒否された図である。
【００９６】
アービトレーションに負けたノードに対してはＤＰ（data prefix ）パケットを送り、拒否されたことを知らせる。拒否されたノードのバス使用要求は次回のアービトレーションまで待たされる。
【００９７】
以上のようにして、アービトレーションに勝ってバスの使用許可を得たノードは、以降データの転送を開始できる。
【００９８】
ここで、アービトレーションの一連の流れをフローチャート図１１に示して、説明する。
【００９９】
ノードがデータ転送を開始できる為には、バスがアイドル状態であることが必要である。先に行われていたデータ転送が終了して、現在バスが空き状態であることを認識するためには、各転送モードで個別に設定されている所定のアイドル時間ギャップ長（例えば、サブアクション・ギャップ）を経過する事によって、各ノードは自分の転送が開始できると判断する。
【０１００】
ステップＳ４０１として、Ａｓｙｎｃデータ、Ｉｓｏデータ等それぞれ転送するデータに応じた所定のギャップ長が得られたか判断する。所定のギャップ長が得られない限り、転送を開始するために必要なバス使用権の要求はできないので、所定のギャップ長が得られるまで待つ。
【０１０１】
ステップＳ４０１で所定のギャップ長が得られたら、ステップＳ４０２として転送すべきデータがあるか判断し、ある場合はステップＳ４０３として転送するためにバスを確保するよう、バス使用権の要求をルートに対して発する。このときの、バス使用権の要求を表す信号の伝達は、図１０に示したように、ネットワーク内各機器を中継しながら、最終的にルートに届けられる。ステップＳ４０２で転送するデータがない場合は、そのまま待機する。
【０１０２】
次に、ステップＳ４０４として、ステップＳ４０３のバス使用要求を１つ以上ルートが受信したら、ルートはステップＳ４０５として使用要求を出したノードの数を調べる。
【０１０３】
ステップＳ４０５での選択値がノード数＝１（使用権要求を出したノードは１つ）だったら、そのノードに直後のバス使用許可が与えられることとなる。ステップＳ４０５での選択値がノード数＞１（使用要求を出したノードは複数）だったら、ルートはステップＳ４０６として使用許可を与えるノードを１つに決定する調停作業を行う。この調停作業は公平なものであり、毎回同じノードばかりが許可を得る様なことはなく、平等に権利を与えていくような構成となっている（フェア・アービトレーション）。
【０１０４】
ステップＳ４０７として、ステップＳ４０６で使用要求を出した複数ノードの中からルートが調停して使用許可を得た１つのノードと、敗れたその他のノードに分ける選択を行う。ここで、調停されて使用許可を得た１つのノード、またはステップＳ４０５の選択値から使用要求ノード数＝１で調停無しに使用許可を得たノードには、ステップＳ４０８として、ルートはそのノードに対して許可信号を送る。
【０１０５】
許可信号を得たノードは、受け取った直後に転送すべきデータ（パケット）を転送開始する。また、ステップＳ４０６の調停で敗れて、バス使用が許可されなかったノードにはステップＳ４０９としてルートから、アービトレーション失敗を示すＤＰ（data prefix ）パケットを送られ、これを受け取ったノードは再度転送を行うためのバス使用要求を出すため、ステップＳ４０１まで戻り、所定ギャップ長が得られるまで待機する。
【０１０６】
以上がアービトレーションの流れを説明した、フローチャート図１１の説明である。
【０１０７】
Ａｓｙｎｃｈｒｏｎｏｕｓ（非同期）転送について説明する。
【０１０８】
アシンクロナス転送は、非同期転送である。図１２にアシンクロナス転送における時間的な遷移状態を示す。
【０１０９】
図１２の最初のサブアクション・ギャップは、バスのアイドル状態を示すものである。このアイドル時間が一定値になった時点で、転送を希望するノードはバスが使用できると判断して、バス獲得のためのアービトレーションを実行する。
【０１１０】
アービトレーションでバスの使用許可を得ると、次にデータの転送がパケット形式で実行される。データ転送後、受信したノードは転送されたデータに対しての受信結果のａｓｋ（受信確認用返送コード）をａｓｋ ｇａｐという短いギャップの後、返送して応答するか、応答パケットを送ることによって転送が完了する。ａｓｋは４ビットの情報と４ビットのチェックサムからなり、成功か、ビジー状態か、ペンディング状態であるかといった情報を含み、すぐに送信元ノードに返送される。
【０１１１】
つぎに、図１３にアシンクロナス転送のパケットフォーマットの例を示す。
【０１１２】
パケットには、データ部及び誤り訂正用のデータＣＲＣの他にはヘッダ部があり、そのヘッダ部には図１３に示すような、目的ノードＩＤ、ソースノードＩＤ、転送データ長さや各種コードなどが書き込まれ、転送が行なわれる。
【０１１３】
また、アシンクロナス転送は自己ノードから相手ノードへの１対１の通信である。転送元ノードから転送されたパケットは、ネットワーク中の各ノードに行き渡るが、自分宛てのアドレス以外のものは無視されるので、宛先の１つのノードのみが読込むことになる。
【０１１４】
以上がアシンクロナス転送の説明である。
【０１１５】
Ｉｓｏｃｈｒｏｎｏｕｓ（同期）転送について説明する。
【０１１６】
アイソクロナス転送は同期転送である。１３９４シリアルバスの最大の特徴であるともいえるこのアイソクロナス転送は、特に映像データや音声データといったマルチメディアデータなど、リアルタイムな転送を必要とするデータの転送に適した転送モードである。
【０１１７】
また、アシンクロナス転送（非同期）が１対１の転送であったのに対し、このアイソクロナス転送はブロードキャスト機能によって、転送元の１つのノードから他のすべてのノードへ一様に転送される。
【０１１８】
図１４はアイソクロナス転送における、時間的な遷移状態を示す図である。
【０１１９】
アイソクロナス転送は、バス上一定時間毎に実行される。この時間間隔をアイソクロナスサイクルと呼ぶ。アイソクロナスサイクル時間は、１２５μS である。この各サイクルの開始時間を示し、各ノードの時間調整を行なう役割を担っているのがサイクル・スタート・パケットである。サイクル・スタート・パケットを送信するのは、サイクル・マスタと呼ばれるノードであり、１つ前のサイクル内の転送終了後、所定のアイドル期間（サブアクションギャップ）を経た後、本サイクルの開始を告げるサイクル・スタート・パケットを送信する。
【０１２０】
このサイクル・スタート・パケットの送信される時間間隔が１２５μS となる。
【０１２１】
また、図１４にチャネルＡ、チャネルＢ、チャネルＣと示したように、１サイクル内において複数種のパケットがチャネルＩＤをそれぞれ与えられることによって、区別して転送できる。これによって同時に複数ノード間でのリアルタイムな転送が可能であり、また受信するノードでは自分が欲しいチャネルＩＤのデータのみを取り込む。このチャネルＩＤは送信先のアドレスを表すものではなく、データに対する論理的な番号を与えているに過ぎない。よって、あるパケットの送信は１つの送信元ノードから他のすべてのノードに行き渡る、ブロードキャストで転送されることになる。
【０１２２】
アイソクロナス転送のパケット送信に先立って、アシンクロナス転送同様アービトレーションが行われる。しかし、アシンクロナス転送のように１対１の通信ではないので、アイソクロナス転送にはａｓｋ（受信確認用返信コード）は存在しない。
【０１２３】
また、図１４に示したｉｓｏ ｇａｐ（アイソクロナスギャップ）とは、アイソクロナス転送を行なう前にバスが空き状態であると認識するために必要なアイドル期間を表している。この所定のアイドル期間を経過すると、アイソクロナス転送を行ないたいノードはバスが空いていると判断し、転送前のアービトレーションを行なうことができる。
【０１２４】
つぎに、図１５にアイソクロナス転送のパケットフォーマットの例を示し、説明する。
【０１２５】
各チャネルに分かれた、各種のパケットにはそれぞれデータ部及び誤り訂正用のデータＣＲＣの他にヘッダ部があり、そのヘッダ部には図１５に示すような、転送データ長やチャネルＮＯ、その他各種コード及び誤り訂正用のヘッダＣＲＣなどが書き込まれ、転送が行なわれる。
【０１２６】
以上がアイソクロナス転送の説明である。
【０１２７】
つぎに、バス・サイクルについて説明する。
【０１２８】
実際の１３９４シリアルバス上の転送では、アイソクロナス転送と、アシンクロナス転送は混在できる。その時の、アイソクロナス転送とアシンクロナス転送が混在した、バス上の転送状態の時間的な遷移の様子を表した図を図１６に示す。
【０１２９】
アイソクロナス転送はアシンクロナス転送より優先して実行される。その理由は、サイクル・スタート・パケットの後、アシンクロナス転送を起動するために必要なアイドル期間のギャップ長（サブアクションギャップ）よりも短いギャップ長（アイソクロナスギャップ）で、アイソクロナス転送を起動できるからである。したがって、アシンクロナス転送より、アイソクロナス転送は優先して実行されることとなる。
【０１３０】
図１６に示した、一般的なバスサイクルにおいて、サイクル＃ｍのスタート時にサイクル・スタート・パケットがサイクル・マスタから各ノードに転送される。これによって、各ノードで時刻調整を行ない、所定のアイドル期間（アイソクロナスギャップ）を待ってからアイソクロナス転送を行なうべきノードはアービトレーションを行い、パケット転送に入る。図１６ではチャネルｅとチャネルｓとチャネルｋが順にアイソクロナス転送されている。
【０１３１】
このアービトレーションからパケット転送までの動作を、与えられているチャネル分繰り返し行なった後、サイクル＃ｍにおけるアイソクロナス転送がすべて終了したら、アシンクロナス転送を行うことができるようになる。
【０１３２】
アイドル時間がアシンクロナス転送が可能なサブアクションギャップに達する事によって、アシンクロナス転送を行いたいノードはアービトレーションの実行に移れると判断する。
【０１３３】
ただし、アシンクロナス転送が行える期間は、アイソクロナス転送終了後から、次のサイクル・スタート・パケットを転送すべき時間（cycle synch ）までの間にアシンクロナス転送を起動するためのサブアクションギャップが得られた場合に限っている。
【０１３４】
図１６のサイクル＃ｍでは３つのチャネル分のアイソクロナス転送と、その後アシンクロナス転送（含むack ）が２パケット（パケット１、パケット２）転送されている。このアシンクロナスパケット２の後は、サイクルｍ＋１をスタートすべき時間（cycle synch ）にいたるので、サイクル＃ｍでの転送はここまでで終わる。
【０１３５】
ただし、非同期または同期転送動作中に次のサイクル・スタート・パケットを送信すべき時間（cycle synch ）に至ったとしたら、無理に中断せず、その転送が終了した後のアイドル期間を待ってから次サイクルのサイクル・スタート・パケットを送信する。すなわち、１つのサイクルが１２５μS 以上続いたときは、その分次サイクルは基準の１２５μS より短縮されたとする。このようにアイソクロナス・サイクルは１２５μS を基準に超過、短縮し得るものである。
【０１３６】
しかし、アイソクロナス転送はリアルタイム転送を維持するために毎サイクル必要であれば必ず実行され、アシンクロナス転送はサイクル時間が短縮されたことによって次以降のサイクルにまわされることもある。
こういった遅延情報も含めて、サイクル・マスタによって管理される。
【０１３７】
そこで、まず、第１の実施の形態について説明する。
【０１３８】
図１７は、本発明の特徴を最もよく表す図であり、同図において１３９４のインターフェイスをＬＡＮで用いられるＯＳＩモデルの各層と対比させてみると、ＯＳＩモデルの物理層１とデータリンク層２が、１３９４インターフェイスの下位層４であるフィジカル・リンク層に該当し、それら下位層４の上に存在する上位層３が１３９４インターフェイスではトランスポートプロトコル層５とプレゼンテーション層６に該当する。また、本発明の特徴となるＬＯＧＩＮプロトコル７は、１３９４インターフェイスの下位層４とトランスポートプロトコル５との間で動作するものである。
【０１３９】
この実施の形態では、シリアルバスプロトコル（ＳＢＰ−２）８に準拠したデバイスにＬＯＧＩＮプロトコルを挿入することによって、相手のデバイスに対して自分がＳＢＰ−２に準拠したプロトコルを使ってやり取りを行いたいことを通知することができる。また、後述する第３の実施の形態では、１３９４インターフェイス上で特化されたデバイスプロトコル９についてもＬＯＧＩＮプロトコルを挿入することで、お互いのデバイスがそのプロトコルがサポートされているかを判別してデータのやり取りを行うことができる。
【０１４０】
図１８は、ＬＯＧＩＮプロトコルの基本動作を示した図であり、プリンタは印字タスク１０を実行する際にまず初めにＬＯＧＩＮプロトコルを使ってプリンタで用意しているプリンタプロトコルＡ・Ｂ・Ｃのうち、どれを選択して印字するかを決定し、その後は決定されたプロトコルに沿って印字動作を行う。
すなわち、プリンタ側でいくつかのプリンタプロトコルをサポートしているデバイスにおいて、ターゲットとの接続の際にまず初めに相手のデバイスのプロトコルをＬＯＧＩＮプロトコルを使って判別し、プリンタは相手のプロトコルに合わせたプリンタプロトコルを複数の中からひとつ選択し、この選ばれたプロトコルに沿って印字データやコマンドのやり取りを行って印字処理を行う。
【０１４１】
図１９は、この実施の形態におけるＬＯＧＩＮプロトコルを実装した１３９４インターフェイスにおける各デバイスの接続形態を示した図で、複数のプリンタプロトコルに対応したプリンタ１１に対してＬＯＧＩＮプロトコルを実装したデバイス（ＰＣ１２、スキャナ１３、ＶＣＲ１４等）が接続された場合に、ＬＯＧＩＮプロトコルを使用して相手のトランスポートプロトコルに応じてプリンタ側でプリンタプロトコルを切り替えることにより、各デバイスからの印字タスクを問題なく処理することが可能となる。
【０１４２】
図２０はログイン動作の流れを示したものである。
【０１４３】
第一ステップ：
・デバイス（この場合マルチプロトコルプリンタ）をロック
・プリンタのケーパビリティ（受け付けるプロトコル等）を取得
かかるケーパビリティは、後述するレジスタ５０３に格納される。
・ホストのケーパビリティをプリンタにセット
第二ステップ：
・第一ステップで決定したプロトコルで、プリントデータの通信
第三ステップ：
・プリンタとホストは、コネクションを切断
【０１４４】
図２１は、この実施の形態においてＬＯＧＩＮプロトコルのためにプリンタが備える１３９４シリアルバスのＣＳＲを示し、図中、５０１はロックレジスタ（ｌｏｃｋ）、５０２はプロトコルレジスタ（ｐｒｏｔｏｃｏｌ）、５０３はケーパビリティレジスタ（ｃａｐａｂｉｌｉｔｙ）を示す。これらのレジスタは１３９４シリアルバスのアドレス空間における初期ユニット空間の定められたアドレスに配置される。ロックレジスタ５０１はリソースのロック状態を示し、値０はログイン可能な状態をあらわし、０以外はロック状態ですでにログインされていることをあらわす。ケーパビリティレジスタ５０３は設定可能なプロトコルを示し、ビット毎にプロトコルに対応し、ビットの値１はそのプロトコルが設定可能であることをあらわし、０は設定不可能であることをあらわす。プロトコルレジスタ５０２は現在設定されたプロトコルを示し、設定されたプロトコルに対応するケーパビリティレジスタ５０３のビットに相当するビットの値が１になる。
【０１４５】
図２２は、１３９４シリアルバスにより構成されたネットワーク（１３９４ネットワーク）におけるプリンタマップのフォーマットを示した図である。
【０１４６】
このプリンタマップには、応答を返してきたプリンタノードのユニークＩＤ（Unique ID ）、ノードＩＤ（Node ID ）、ステータス（Status）、ケーパビリティ（Capability）が保存される。
ここでいうステータス（Status）は、例えば、図２１のプロトコルレジスタ５０２の内容等を示し、ケーパビリティ（Capability）は、例えば、図２１のケーパビリティレジスタ５０３の内容等を示す。
【０１４７】
図２３は、ＣＲＣアーキテクチャにおけるノードユニークＩＤのフォーマットを示した図である。
【０１４８】
図２４は、プリンタマップ（図２２）の作成コマンドのフィーマットを示した図であり、このコマンドは、非同期パケットのライトトランザクションにより、ターゲットに通知される。
【０１４９】
図２４に示すようなコマンドは、このプロトコルにおいて、１３９４アドレス空間におけるターゲットのユニット空間の定められたアドレスに配置される。
【０１５０】
図２５は、複数のマルチプロトコルプリンタが１３９４ネットワークに接続されている場合のホスト側プリンティングプロトコル（ホスト側プリンタマップ作成処理）を示したフローチャートである。
【０１５１】
ここで、ネットワークにノードには、通常様々なデバイスが接続されている。このような状況下で、イニシエータ（ホスト）がプリンタの出力を試みる時、どのノードにプリンタが接続されているかを知る必要がある。また、プリンタの適切な出力を得るためには、プリンタの物理的な場所、その能力、その余力等を予め知っておくと非常に都合がよい。
【０１５２】
そこで、この実施の形態では、同一ネットワークに接続されているプリンタを調査する。
例えば、プリンタの出力時に、イニシエータ（ホスト）がネットワーク上のプリンタについて上述したような物理的な場所、能力及び余力等の情報（以下、トポロジー／能力情報とも言う）を得てプリンタマップを予め作成し、そのプリンタマップに基づいて目的のプリンタを選択する。
【０１５３】
以下、図２５を用いて、ホスト側のプリンタマップ作成処理について説明する。
【０１５４】
先ず、ホスト側は、プリンタマップ（図２２）を作成するために、その作成コマンド（図２４）をブロードキャストし（ステップＳ３００１）、ターゲットであるプリンタからの応答コマンドの受信待ち状態になる（ステップＳ３００２）。
【０１５５】
ホスト側は、ターゲットからの応答コマンドを受信すると、次に、その応答コマンドを返してきたターゲットのプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３００３）。これにより、ホスト側は、そのターゲットの能力や状態等を認識する。
【０１５６】
そして、ホスト側は、ステップＳ３００３で得た情報を基に、現在の１３９４ネットワーク上のプリンタについてのプリンタマップを作成する（ステップＳ３００４）。
【０１５７】
図２６は、上述したホスト側でのプリンタマップ作成処理時のターゲット側、すなわちプリンタ側の処理を示すフローチャートである。
【０１５８】
先ず、プリンタは、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３１０１）。
具体的には、例えば、現在の自プリンタの能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、プリンタ内部でのステータス及びケーパビリティの変化は、このステップでのステータス及びケーパビリティを提示にも反映する。
【０１５９】
次に、プリンタは、ホスト側からのプリンタマップ作成コマンドの受信待ち状態となる（ステップＳ３１０２）。
【０１６０】
そして、プリンタは、ホスト側からのプリンタマップ作成コマンドを受信すると、そのコマンドに対する応答コマンドをホスト側へ返す（ステップＳ３１０３）。
【０１６１】
図２７は、ログイン処理のホスト側のフローチャートである。
【０１６２】
ログインを開始するためには、図２５に示したプリンタマップ作成処理（ステップＳ６００）の後、ログインしようとするプリンタのロックレジスタ５０１、プロトコルレジスタ５０２、ケーパビリティレジスタ５０３をリードトランザクションにより確認する。ここで、ケーパビリティレジスタ５０３の内容から、ホストが通信に用いるプロトコルをプリンタがサポートしているかどうか確認する（ステップ６０１）。もしホストのプロトコルがプリンタのサポート外ならば、次のステップでログインを中止する。
【０１６３】
ロックレジスタ５０１が０以外であれば、他のデバイスがログイン中であるとみなし、ログインを中止する。ログインレジスタ５０１が０であれば、現在ログイン可能とみなす（ステップ６０２）。
【０１６４】
ログイン可能の場合リソースロック処理に移り、プリンタのロックレジスタ５０１にロックトランザクションを用いて１を書き込み、ホスト側のログイン設定とする（ステップ６０３）。この状態でプリンタはロックされたことになり、他のデバイスからの出力は不可能。またレジスタの変更も不可能とする。
【０１６５】
上記のようにプリンタのリソースがロックされた状態で、次にプロトコルの設定を行なう。本実施の形態におけるプリンタは、複数プリントプロトコルをサポートするため、プリントデータを受け取る前に、ホスト側のプロトコルを知らねばならない。ここでは、ホスト側がプリンタのプロトコルレジスタ５０２に対して、ライトトランザクションにより、これから使用するプロトコルに相当するビットを立て通知する（ステップ６０４）、という手段を用いる。
【０１６６】
この時点で、ホストが通信に用いるプロトコルがプリンタに通知され、かつプリンタがロック状態なので、現在ログインしているホストが通常のプロトコルでプリントデータの送信を行なう（ステップ６０５）。
【０１６７】
プリントデータの送信が終了したら、ホストはプリンタのロックレジスタ５０１、プロトコルレジスタ５０２、ケーパビリティレジスタ５０３をクリアすることにより、プリンタからログアウトする（ステップ６０６）。
【０１６８】
図２８は、ログイン処理のプリンタ側のフローチャートである。
【０１６９】
プリンタ側は、図２６に示したプリンタマップ作成処理（ステップＳ７００）の後、通常ホストからのログイン待ちの状態にいる。ホストからのプリントリクエストは、プリンタのロックレジスタ５０１、プロトコルレジスタ５０２、ケーパビリティレジスタ５０３の読み取りにより開始されるので、前記レジスタは、常に他のデバイスから読み出し可能の状態にしておく。今、プリントアウトを実行しようとするホストがプリンタをロックしたとする（ステップ７０１）。
【０１７０】
ロックレジスタ５０１への書き込みによりプリンタがロックされたら、次にホストからの、使用プロトコルの通知を待つ（ステップ７０２）。ロック状態になってからプロトコルの通知を待つのは、ログインの途中で、さらに他のデバイスからのリクエストにより、プロトコルレジスタ５０２を書き換えられないようにするためである。
【０１７１】
プロトコルの通知があったら、プリンタは自分の受け付けるプロトコルをスイッチし、ホスト側に合わせ、通信を行なう（ステップ７０３〜７１０）。
【０１７２】
通信が終了したら、プリンタはロックレジスタ５０１、プロトコルレジスタ５０２、ケーパビリティレジスタ５０３がクリアされたのを確認し（ステップ７１１）、ログイン待ち状態（ステップ７０１）に戻る。
【０１７３】
つぎに、第２の実施の形態について説明する。
【０１７４】
上述した第１の実施の形態では、図２５及び図２６を用いて説明したように、１３９４ネットワークに複数のプリンタが接続された場合において、ホストがネットワーク上のプリンタについてプリンタマップを作成し、そのプリンタマップに基づいて目的のプリンタを選択するようにしたが、この第２の実施の形態では、１３９４ネットワーク上でホスト及びプリンタが共に複数プロトコルをサポートしており、さらにそのようなプリンタが複数接続されている場合において、ホストが各プリンタの使用可能なプロトコルを調べて多数決を取り、最も多くサポートされているプロトコルを決定する。
【０１７５】
尚、この第２の実施の形態は、図２５及び図２６に示した処理以外については第１の実施の形態と同様であるため、その詳細な説明は省略し、ここでは、第１の実施の形態と異なる点についてのみ具体的に説明する。
【０１７６】
まず、図２９は、この実施の形態におけるホスト側のプリンタマップ作成処理を示すフローチャートであり、図３０は、この処理時のプリンタ側の処理を示すフローチャートである。
図２９の処理は、図２７に示したホスト側のログイン処理のステップＳ６００で行われる処理であり、図３０の処理は、図２９に示したプリンタ側のログイン処理のステップＳ７００で行われる処理である。
【０１７７】
ここで、この実施の形態では上述したように、１３９４ネットワーク上において、イニシエータ（ホスト）及びターゲット（プリンタ）共に複数プロトコルをサポートしており、さらにそのようなプリンタが同一ネットワークに複数台接続されている場合、当然イニシエータとターゲットが同一プロトコルを用いる必要があるが、今どのプロトコルを用いるかを決定するために、イニシエータが各プリンタの使用可能なプロトコルを調べ、その中で多数決を取り、最も多くサポートされているプロトコルを用いる。
【０１７８】
このように、多くのプロトコルが使用可能な状況下で多数決を取るように構成することで、実際に使用するプロトコルの種類を削減することができ、その結果、イニシエータのプロトコルスイッチによる負荷を下げることができる。
【０１７９】
以下、図２９及び図３０を用いて、イニシエータ側（ホスト側）及びターゲット側（プリンタ側）のプリンタマップ作成処理（相対多数プロトコル決定プリンタマップ処理）について説明する。
【０１８０】
先ず、ホスト側は、図２２に示したようなプリンタマップを作成するために、その作成コマンドをブロードキャストし（ステップＳ３２０１）、ターゲットであるプリンタからの応答コマンドの受信待ち状態になる（ステップＳ３２０２）。
【０１８１】
ホスト側は、ターゲットからの応答コマンドを受信すると、次に、その応答コマンドを返してきたターゲットのプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３２０３）。これにより、ホスト側は、そのターゲットの能力や状態等を認識する。
【０１８２】
次に、ホスト側は、ステップＳ３２０３で得た情報を基に、現在の１３９４ネットワーク上のプリンタについてのプリンタマップを作成する（ステップＳ３２０４）。
【０１８３】
次に、ホスト側は、ステップＳ３２０４で作成したプリンタマップより、現在ネットワークに接続されているマルチプロトコルプリンタの使用可能なプロトコルを調べ、それらのプロトコルの中から、最も多くサポートされているプロトコルを選択する（ステップＳ３２０５）。
【０１８４】
そして、ホスト側は、ステップＳ３２０５で選択したプロトコルを、プロトコル通知コマンドとして各プリンタに通知する（ステップＳ３２０６）。
【０１８５】
一方、プリンタは、先ず、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３３０１）。
具体的には、例えば、現在の自プリンタの能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、プリンタ内部でのステータス及びケーパビリティの変化は、このステップでのステータス及びケーパビリティを提示にも反映する。
【０１８６】
次に、プリンタは、ホスト側からのプリンタマップ作成コマンドの受信待ち状態となる（ステップＳ３３０２）。
【０１８７】
次に、プリンタは、ホスト側からのプリンタマップ作成コマンドを受信すると、そのコマンドに対する応答コマンドをホスト側へ返す（ステップＳ３３０３）。
【０１８８】
次に、プリンタは、ホスト側からのプロトコル通知コマンドの受信待ち状態となる（ステップＳ３４０２）。
【０１８９】
そして、プリンタは、ホスト側からのプロトコル通知コマンドを受信すると、そのコマンドに対する応答コマンドをホスト側へ返す（ステップＳ３５０３）。
【０１９０】
つぎに、第３の実施の形態について説明する。
【０１９１】
図３１は、この実施の形態における動作を示した図であり、図２に示した第１の実施の形態と比較してみるとＬＯＧＩＮプロトコルを実装していないプロトコルＤについても対応している点が特徴といえる。
すなわち、ＬＯＧＩＮプロトコルを持ったターゲットに対してだけでなく、既存のプロトコルＤ（例えばＡＶ／Ｃプロトコル）にのみ対応しているデバイスに対しても印字動作の保証を行う為に、プリンタ側で対応するプリンタプロトコルをＬＯＧＩＮプロトコルの持っていないデバイス用に追加を行ったものである。
【０１９２】
この動作について説明すると、接続の初めに行われるＬＯＧＩＮプロトコルによる会話によってターゲット側がＬＯＧＩＮプロトコルに対応していないことをプリンタ側が認識した際、プリンタ側はその他のプロトコルＤを使ってターゲットに会話を行い、そこで会話が成立した場合はそのプロトコルＤに沿った印字タスクを実行することができる。
【０１９３】
図３２は、この実施の形態におけるＯＳＩモデルとの対比を示した図であり、この実施の形態ではＬＯＧＩＮプロトコルの実装されていない現行のＡＶ／Ｃプロトコルに準拠したプリンタをモデルとしている。例４は、現行のプロトコルではまだ定義されていない、スキャナ用に作られたＬＯＧＩＮプロトコルの機能を持っていないプロトコルが実装されていた場合を表している。
すなわち、ＬＯＧＩＮプロトコルを実装していないプロトコルついてもプリンタ側で対応することができれば、繋がるターゲットデバイスの種類に幅ができるわけである。
【０１９４】
尚、上述した実施の形態では、主にネットワーク上のデバイスとしてプリンタを説明したが、これに限らず、モニタやコンピュータ、ディジタルカメラ等でもよく、特定の機種のデバイスに限定されるものではない。
【０１９５】
また、図２７のステップＳ６００、図２８のステップＳ７００、及び図２９のステップＳ３２０１で実行されるプリンタマップの作成においては、トポロジ接続状態が例えば図９のように調査され表示用マップが作成される、かかるトポロジ接続状態が判定されることによって、単なる多数決ではなく、トポロジ接続状態を加味して実際に使用するプロトコルを決定することができる。
【０１９６】
また、本発明は、図１９に示すような、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置内のデータ処理方法に適用してもよい。
【０１９７】
また、本発明の目的は、上述した各実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、達成されることは言うまでもない。
【０１９８】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した各実施の形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することとなる。
【０１９９】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０２００】
また、コンピュータが読みだしたプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２０１】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２０２】
【発明の効果】
以上説明したように本発明によれば、拡張性の高いデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することができる。特に、複数種類のプリンタのプロトコルに対応可能であるので、拡張性が極めて高い。
また、同一ネットワークに接続されたプリンタを調査することで、目的とするプリンタを選択することができるため、最適なプリンタ出力を得ることができる。さらに、多くのプロトコルが使用可能な状況下であっても、それらのプロトコルのうちプリンタから最も多くサポートされているプロトコルを決定することで、実際に使用するプロトコルの種類を削減することができるため、ホスト側のプロトコルに切り替えによる負荷を下げることができる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４ケーブルを用いた通信システムの一例を示す図である。
【図２】ＩＥＥＥ１３９４の階層構造を示す図である。
【図３】ＩＥＥＥ１３９４のアドレスを示す図である。
【図４】ＩＥＥＥ１３９４のケーブル断面図である。
【図５】ＤＳ−Ｌｉｎｋ符号化方式を説明するための図である。
【図６】バスリセットからＩＤの設定までを説明するフローチャートである。
【図７】ルートの決定方法を説明するフローチャートである。
【図８】親子関係決定からすべてのノードＩＤの設定までの手順を説明するフローチャートである。
【図９】ノード間の親子関係を示す図である。
【図１０】アービトレーションの過程を説明するための図である。
【図１１】アービトレーションの過程を示すフローチャートである。
【図１２】Ａｓｙｎｃｈｒｏｎｏｕｓ転送におけるサブアクションを説明するための図である。
【図１３】Ａｓｙｎｃｈｒｏｎｏｕｓ転送におけるパケット構造を説明するための図である。
【図１４】Ｉｓｏｃｈｒｏｎｏｕｓ転送におけるサブアクションを説明するための図である。
【図１５】Ｉｓｏｃｈｒｏｎｏｕｓ転送におけるパケット構造を示す図である。
【図１６】ＩＥＥＥ１３９４の通信サイクルの一例を説明するための図である。
【図１７】第１の実施の形態において、本発明を適用したシステムを説明するための図である。
【図１８】ＬＯＧＩＮプロトコルの基本動作を説明するための図である。
【図１９】ＬＯＧＩＮプロトコルを実装した１３９４インターフェイスにおける各デバイスの接続形態を説明するための図である。
【図２０】ログイン動作の流れを説明するための図である。
【図２１】ＬＯＧＩＮプロトコルのためにプリンタが備える１３９４シリアルバスのＣＳＲを説明するための図である。
【図２２】１３９４ネットワークにおけるプリンタマップを説明するための図である。
【図２３】ＣＲＣアーキテクチャにおけるノードＩＤを説明するための図である。
【図２４】プリンタマップ作成のコマンドを説明するための図である。
【図２５】ホスト側のプリンタマップ作成処理を説明するためのフローチャートである。
【図２６】プリンタ側のプリンタマップ作成処理を説明するためのフローチャートである。
【図２７】ログイン処理のホスト側の処理を説明するためのフローチャートである。
【図２８】ログイン処理のプリンタ側の処理を説明するためのフローチャートである。
【図２９】第２の実施の形態におけるホスト側のプリンタマップ作成処理を説明するためのフローチャートである。
【図３０】上記第２の実施の形態におけるプリンタ側のプリンタマップ作成処理を説明するためのフローチャートである。
【図３１】第３の実施の形態におけるシステム動作を説明するための図である。
【図３２】上記第３の実施の形態におけるＯＳＩモデルとの対比を説明するための図である。
【符号の説明】
１ ＯＳＩモデルの物理層
２ データリンク層
３ 上位層
４ 上位層
５ トランスポートプロトコル層
６ プレゼンテーション層
７ ＬＯＧＩＮプロトコル
８ シリアルバスプロトコル（ＳＢＰ−２）
９ デバイスプロトコル
【発明の属する技術分野】
本発明は、共通シリアスバスを介して、複数種類のプリンタのプロトコルを切り換えるためのデータ処理方法、データ処理装置、プリンタ及び記憶媒体に関するものである。
【０００２】
【従来の技術】
従来より、シリアスバスを介してプリンタにデータを送出するシステムとして、様々な種類のシステムが知られている。
【０００３】
例えば、ＳＣＳＩ（Small Computer System Interface ）、セントロニクス等、一般に広く用いられるようになったデファクトスタンダードのインターフェースを用いて、コンピュータからプリンタにデータを出力する技術が知られている。
【０００４】
【発明が解決しようとする課題】
しかしながら、シリアスバスを用いてプリンタデータを送出する従来のプリンタプロトコルは、プリンタメーカ固有の１つに限られていた。
したがって、拡張性に欠ける、という問題が生じていた。
特に、様々な種類の機器を接続するインターフェース、例えば、ＩＥＥＥ１３９４のようなインターフェースを用いて、プリントデータを出力する際には、かかる拡張性に欠けるという問題点は解決すべき大きな課題であった。
【０００５】
そこで、本発明は、上記の欠点を除去するために成されたもので、システムバスを介してプリントデータを送出する際に、拡張性の高いデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
また、本発明は、ＩＥＥＥ１３９４規格に好適なデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
また、本発明は、コンピュータを介することなく、画像データ出力デバイスから直接プリンタを接続するのに好適なデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
また、本発明は、最適なプリンタ出力を得ることができるデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
また、本発明は、プロトコルの切り替えによる負荷を下げることができるデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することを目的とする。
【０００６】
【課題を解決するための手段】
本発明のデータ処理方法は、共通シリアスバスを介して複数デバイスのプロトコルを切り換えるためのデータ処理方法であって、前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行し、前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定し、前記初期プロトコルに続いて、決定されたプロトコルを実行することを特徴とする。
本発明のデータ処理装置は、共通シリアスバスを介して複数デバイスのプロトコルを切り換えるためのデータ処理装置であって、前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行する第１の実行手段と、前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定手段と、前記初期プロトコルに続いて、決定されたプロトコルを実行する第２の実行手段とを備えることを特徴とする。
本発明のプリンタは、共通シリアスバスを介して複数デバイスのプロトコルをホストに対応して切り換えるプリンタであって、前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行する第１の実行手段と、前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定手段と、前記初期プロトコルに続いて、決定されたプロトコルを実行する第２の実行手段とを備えることを特徴とする。
本発明の記憶媒体は、共通シリアスバスを介して複数デバイスのプロトコルを切り換えるためのデータ処理方法を実行するためのデータ処理ステップをコンピュータに実行させるためのコンピュータプログラムをコンピュータが読み取り可能に記憶した記憶媒体であって、前記データ処理方法は、前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行するステップと、前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定するステップと、前記初期プロトコルに続いて、決定されたプロトコルを実行するステップとを有することを特徴とする。
【０００７】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【０００８】
ここで、まず、以下に説明する第１及び第２の実施の形態では、各機器間を接続するディジタルＩ／Ｆとして、ＩＥＥＥ１３９４シリアルバスを用いているため、ＩＥＥＥ１３９４シリアルバスについて、予め説明する。
【０００９】
民生用デジタルＶＣＲやＤＶＤプレーヤの登場に伴なって、ビデオデータやオーディオデータなどのリアルタイムで、かつ高情報量のデータ転送のサポートが必要になっている。こういったビデオデータやオーディオデータをリアルタイムで転送し、パソコン（ＰＣ）に取り込んだり、またはその他のデジタル機器に転送を行なうには、必要な転送機能を備えた高速データ転送可能なインタフェースが必要になってくるものであり、そういった観点から開発されたインタフェースが、ＩＥＥＥ１３９４−１９９５（High Performance Serial Bus ）（以下、単に１３９４シリアルバスとも言う）である。
【００１０】
図１に１３９４シリアルバスを用いて構成されるネットワーク・システムの例を示す。
【００１１】
このシステムは、機器Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ，Ｈを備えており、Ａ−Ｂ間、Ａ−Ｃ間、Ｂ−Ｄ間、Ｄ−Ｅ間、Ｃ−Ｆ間、Ｃ−Ｇ間、及びＣ−Ｈ間をそれぞれ１３９４シリアルバスのツイスト・ペア・ケーブルで接続されている。この機器A 〜H は、例えばパソコン、デジタルＶＴＲ、ＤＶＤ、デジタルカメラ、ハードディスク、モニタ、チューナー、モニター等である。
【００１２】
各機器間の接続方式は、ディジーチェーン方式とノード分岐方式とを混在可
能としたものであり、自由度の高い接続が可能である。
【００１３】
また、各機器は各自固有のＩＤを有し、それぞれが認識し合うことによって１３９４シリアルバスで接続された範囲において、１つのネットワークを構成している。各デジタル機器間をそれぞれ１本の１３９４シリアルバスケーブルで順次接続するだけで、それぞれの機器が中継の役割を行い、全体として１つのネットワークを構成するものである。また、１３９４シリアルバス、Ｐｌｕｇ＆Ｐｌａｙ機能でケーブルを機器に接続した時点で自動で機器の認識や接続状況などを認識する機能を有している。
【００１４】
また、図１に示したようなシステムにおいて、ネットワークからある機器が削除されたり、または新たに追加されたときなど、自動的にバスリセットを行い、それまでのネットワーク構成をリセットしてから、新たなネットワークの再構築を行なう。この機能によって、その時々のネットワークの構成を常時設定、認識することができる。
【００１５】
またデータ転送速度は、１００／２００／４００Ｍｂｐｓと備えており、上位の転送速度を持つ機器が下位の転送速度をサポートし、互換をとるようになっている。
【００１６】
データ転送モードとしては、コントロール信号などの非同期データ（Asynchronousデータ：以下、Ａｓｙｎｃデータと言う）を転送するＡｓｙｎｃｈｒｏｎｏｕｓ転送モードとリアルタイムなビデオデータやオーディオデータ等の同期データ（Isochronous データ：以下、Ｉｓｏデータと言う）を転送するＩｓｏｃｈｒｏｎｏｕｓ転送モードがある。このＡｓｙｎｃデータとＩｓｏデータは各サイクル（通常１サイクル１２５μS ）の中において、サイクル開始を示すサイクル・スタート・パケット（ＣＳＰ）を転送した後、Ｉｓｏデータの転送をＡｓｙｎｃデータより優先しつつサイクル内で混在して転送される。
【００１７】
つぎに、図２に１３９４シリアルバスの構成要素を示す。
【００１８】
１３９４シリアルバスは全体としてレイヤ（階層）構造で構成されている。図２に示したように、１３９４シリアルバスのケーブルとコネクタが接続されるコネクタポートがあり、その上にハードウェアとしてフィジカル・レイヤとリンク・レイヤを位置づけしている。
【００１９】
ハードウェア部は実質的なインターフェイスチップの部分であり、そのうちフィジカル・レイヤは符号化やコネクタ関連の制御等を行い、リンク・レイヤはパケット転送やサイクルタイムの制御等を行なう。
【００２０】
ファームウェア部のトランザクション・レイヤは、転送（トランザクション）すべきデータの管理を行ない、Ｒｅａｄ、Ｗｒｉｔｅ、Ｌｏｃｋの命令を出す。マネージメント・レイヤは、接続されている各機器の接続状況やＩＤの管理を行ない、ネットワークの構成を管理する部分である。
【００２１】
このハードウェアとファームウェアまでが実質上の１３９４シリアルバスの構成である。
【００２２】
またソフトウェア部のアプリケーション・レイヤは使うソフトによって異なり、インタフェース上にどのようにデータをのせるか規定する部分であり、プリンタやＡＶＣプロトコルなどが規定されている。
【００２３】
以上が１３９４シリアルバスの構成である。
【００２４】
つぎに、図３に１３９４シリアルバスにおけるアドレス空間の図を示す。
【００２５】
１３９４シリアルバスに接続された各機器（ノード）には必ず各ノード固有の、６４ビットアドレスを持たせておく。そしてこのアドレスをＲＯＭに格納しておくことで、自分や相手のノードアドレスを常時認識でき、相手を指定した通信も行なえる。
【００２６】
１３９４シリアルバスのアドレッシングは、ＩＥＥＥ１２１２規格に準じた方式であり、アドレス設定は、最初の１０ｂｉｔがバスの番号の指定用に、次の６ｂｉｔがノードＩＤ番号の指定用に使われる。残りの４８ｂｉｔが機器に与えられたアドレス幅になり、それぞれ固有のアドレス空間として使用できる。最後の２８ｂｉｔは固有データの領域として、各機器の識別や使用条件の指定の情報などを格納する。
【００２７】
以上が１３９４シリアルバスの技術の概要である。
【００２８】
つぎに、１３９４シリアルバスの特徴といえる技術の部分を、より詳細に説明する。
【００２９】
１３９４シリアルバスの電気的仕様について説明する。
【００３０】
図４に１３９４シリアルバス・ケーブルの断面図を示す。
【００３１】
１３９４シリアルバスでは接続ケーブル内に６ピン、即ち２組のツイストペア信号線の他に、電源ラインを設けている。これによって、電源を持たない機器や、故障により電圧低下した機器等にも電力の供給が可能になっている。
【００３２】
電源線内を流れる電源の電圧は８〜４０Ｖ、電流は最大電流DC１．５Ａと規定されている。
【００３３】
なお、ＤＶケーブルと呼ばれる規格では電源を省いた４ピンで構成されている。
【００３４】
ＤＳ−Ｌｉｎｋ符号化について説明する。
【００３５】
１３９４シリアルバスで採用されている、データ転送フォーマットのＤＳ−Ｌｉｎｋ符号化方式を説明するための図を図５に示す。
【００３６】
１３９４シリアルバスでは、ＤＳ−Ｌｉｎｋ（Data／Strobe Link ）符号化方式が採用されている。このＤＳ−Ｌｉｎｋ符号化方式は、高速なシリアルデータ通信に適しており、その構成は、２本の信号線を必要とする。より対線のうち１本に主となるデータを送り、他方のより対線にはストローブ信号を送る構成になっている。受信側では、この通信されるデータと、ストローブとの排他的論理和をとることによってクロックを再現する。
【００３７】
このＤＳ−Ｌｉｎｋ符号化方式を用いるメリットとして、８／１０Ｂ変換に比べて転送効率が高いこと、ＰＬＬ回路が不要となるのでコントローラＬＳＩの回路規模を小さくできること、更には、転送すべきデータが無いときにアイドル状態であることを示す情報を送る必要が無いので、各機器のトランシーバ回路をスリープ状態にすることができることによって、消費電力の低減が図れる、などが挙げられる。
【００３８】
バスリセットのシーケンスについて説明する。
【００３９】
１３９４シリアルバスでは、接続されている各機器（ノード）にはノードＩＤが与えられ、ネットワーク構成として認識されている。
【００４０】
このネットワーク構成に変化があったとき、例えばノードの挿抜や電源のＯＮ／ＯＦＦなどによるノード数の増減などによって変化が生じて、新たなネットワーク構成を認識する必要があるとき、変化を検知した各ノードはバス上にバスリセット信号を送信して、新たなネットワーク構成を認識するモードに入る。
【００４１】
このときの変化の検知方法は、１３９４ポート基盤上でのバイアス電圧の変化を検知することによって行われる。
【００４２】
あるノードからバスリセット信号が伝達されて、各ノードのフィジカルレイヤはこのバスリセット信号を受けると同時にリンクレイヤにバスリセットの発生を伝達し、かつ他のノードにバスリセット信号を伝達する。最終的にすべてのノードがバスリセット信号を検知した後、バスリセットが起動となる。
【００４３】
バスリセットは、先に述べたようなケーブル抜挿や、ネットワーク異常等によるハード検出による起動と、プロトコルからのホスト制御などによってフィジカルレイヤに直接命令を出すことによっても起動する。
また、バスリセットが起動するとデータ転送は一時中断され、この間のデータ転送は待たされ、終了後、新しいネットワーク構成のもとで再開される。
【００４４】
以上がバスリセットのシーケンスである。
【００４５】
ノードＩＤ決定のシーケンスについて説明する。
【００４６】
バスリセットの後、各ノードは新しいネットワーク構成を構築するために、各ノードにＩＤを与える動作に入る。このときの、バスリセットからノードＩＤ決定までの一般的なシーケンスを図６、７、８のフローチャートを用いて説明する。
【００４７】
図６のフローチャートは、バスリセットの発生からノードＩＤが決定し、データ転送が行えるようになるまでの、一連のバスの作業を示してある。
【００４８】
まず、ステップＳ１０１として、ネットワーク内にバスリセットが発生することを常時監視していて、ここでノードの電源ＯＮ／ＯＦＦなどでバスリセットが発生するとステップＳ１０２に移る。
【００４９】
ステップＳ１０２では、ネットワークがリセットされた状態から、新たなネットワークの接続状況を知るために、直接接続されている各ノード間において親子関係の宣言がなされる。ステップＳ１０３として、すべてのノード間で親子関係が決定すると、ステップＳ１０４として一つのルートが決定する。すべてのノード間で親子関係が決定するまで、ステップＳ１０２の親子関係の宣言をおこない、またルートも決定されない。
【００５０】
ステップＳ１０４でルートが決定されると、次はステップＳ１０５として、各ノードにＩＤを与えるノードＩＤの設定作業が行われる。所定のノード順序で、ノードＩＤの設定が行われ、すべてのノードにＩＤが与えられるまで繰り返し設定作業が行われ、最終的にステップＳ１０６としてすべてのノードにＩＤを設定し終えたら、新しいネットワーク構成がすべてのノードにおいて認識されたので、ステップＳ１０７としてノード間のデータ転送が行える状態となり、データ転送が開始される。
【００５１】
このステップＳ１０７の状態になると、再びバスリセットが発生するのを監視するモードに入り、バスリセットが発生したらステップＳ１０１からステップＳ１０６までの設定作業が繰り返し行われる。
【００５２】
以上が、図６のフローチャートの説明であるが、図６のフローチャートのバスリセットからルート決定までの部分と、ルート決定後からＩＤ設定終了までの手順をより詳しくフローチャート図に表したものをそれぞれ、図７、図８に示す。
【００５３】
まず、図７のフローチャートの説明を行う。
【００５４】
ステップＳ２０１としてバスリセットが発生すると、ネットワーク構成は一旦リセットされる。なお、ステップＳ２０１としてバスリセットが発生するのを常に監視している。
【００５５】
次に、ステップＳ２０２として、リセットされたネットワークの接続状況を再認識する作業の第一段階として、各機器にリーフ（ノード）であることを示すフラグを立てておく。さらに、ステップＳ２０３として各機器が自分の持つポートがいくつ他ノードと接続されているのかを調べる。
【００５６】
ステップＳ２０４のポート数の結果に応じて、これから親子関係の宣言を始めていくために、未定義（親子関係が決定されてない）ポートの数を調べる。バスリセットの直後はポート数＝未定義ポート数であるが、親子関係が決定されていくにしたがって、ステップＳ２０４で検知する未定義ポートの数は変化していくものである。
【００５７】
まず、バスリセットの直後、はじめに親子関係の宣言を行えるのはリーフに限られている。リーフであるというのはステップＳ２０３のポート数の確認で知ることができる。リーフは、ステップＳ２０５として、自分に接続されているノードに対して、「自分は子、相手は親」と宣言し動作を終了する。
【００５８】
ステップＳ２０３でポート数が複数ありブランチと認識したノードは、バスリセットの直後はステップＳ２０４で未定義ポート数＞１ということなので、ステップＳ２０６へと移り、まずブランチというフラグが立てられ、ステップＳ２０７でリーフからの親子関係宣言で「親」の受付をするために待つ。
【００５９】
リーフが親子関係の宣言を行い、ステップＳ２０７でそれを受けたブランチは適宜ステップＳ２０４の未定義ポート数の確認を行い、未定義ポート数が１になっていれば残っているポートに接続されているノードに対して、ステップＳ２０５の「自分が子」の宣言をすることが可能になる。２度目以降、ステップＳ２０４で未定義ポート数を確認しても２以上あるブランチに対しては、再度ステップＳ２０７でリーフ又は他のブランチからの「親」の受付をするために待つ。
【００６０】
最終的に、いずれか１つのブランチ、又は例外的にリーフ（子宣言を行えるのにすばやく動作しなかった為）がステップＳ２０４の未定義ポート数の結果としてゼロになったら、これにてネットワーク全体の親子関係の宣言が終了したものであり、未定義ポート数がゼロ（すべて親のポートとして決定）になった唯一のノードはステップＳ２０８としてルートのフラグが立てられ、ステップＳ２０９としてルートとしての認識がなされる。
【００６１】
このようにして、図７に示したバスリセットから、ネットワーク内すべてのノード間における親子関係の宣言までが終了する。
【００６２】
つぎに、図８のフローチャートについて説明する。
【００６３】
まず、図８までのシーケンスでリーフ、ブランチ、ルートという各ノードのフラグの情報が設定されているので、これを元にして、ステップＳ３０１でそれぞれ分類する。
【００６４】
各ノードにＩＤを与える作業として、最初にＩＤの設定を行うことができるのはリーフからである。リーフ→ブランチ→ルートの順で若い番号（ノード番号＝０〜）からＩＤの設定がなされていく。
【００６５】
ステップＳ３０２としてネットワーク内に存在するリーフの数Ｎ（Ｎは自然数）を設定する。
【００６６】
この後、ステップＳ３０３として各自リーフがルートに対して、ＩＤを与えるように要求する。この要求が複数ある場合には、ルートはステップＳ３０４としてアービトレーションを行い、ステップＳ３０５として勝ったノード１つにＩＤ番号を与え、負けたノードには失敗の結果通知を行う。
【００６７】
ステップＳ３０６としてＩＤ取得が失敗に終わったリーフは、再度ＩＤ要求を出し、同様の作業を繰り返す。ＩＤを取得できたリーフからステップＳ３０７として、そのノードのＩＤ情報をブロードキャストで全ノードに転送する。１ノードＩＤ情報のブロードキャストが終わると、ステップＳ３０８として残りのリーフの数が１つ減らされる。
【００６８】
ここで、ステップＳ３０９として、この残りのリーフの数が１以上ある時はステップＳ３０３のＩＤ要求の作業からを繰り返し行い、最終的にすべてのリーフがＩＤ情報をブロードキャストすると、ステップＳ３０９がＮ＝０となり、次はブランチのＩＤ設定に移る。ブランチのＩＤ設定もリーフの時と同様に行われる。
【００６９】
まず、ステップＳ３１０としてネットワーク内に存在するブランチの数Ｍ（Ｍは自然数）を設定する。
【００７０】
この後、ステップＳ３１１として各自ブランチがルートに対して、ＩＤを与えるように要求する。これに対してルートは、ステップＳ３１２としてアービトレーションを行い、勝ったブランチから順にリーフに与え終った次の若い番号から与えていく。
【００７１】
ステップＳ３１３として、ルートは要求を出したブランチにＩＤ情報又は失敗結果を通知し、ステップＳ３１４としてＩＤ取得が失敗に終わったブランチは、再度ＩＤ要求を出し、同様の作業を繰り返す。
【００７２】
ＩＤを取得できたブランチからステップＳ３１５として、そのノードのＩＤ情報をブロードキャストで全ノードに転送する。
【００７３】
１ノードＩＤ情報のブロードキャストが終わると、ステップＳ３１６として残りのブランチの数が１つ減らされる。
【００７４】
ここで、ステップＳ３１７として、この残りのブランチの数が１以上ある時はステップＳ３１１のＩＤ要求の作業からを繰り返し、最終的にすべてのブランチがＩＤ情報をブロードキャストするまで行われる。すべてのブランチがノードＩＤを取得すると、ステップＳ３１７はＭ＝０となり、ブランチのＩＤ取得モードも終了する。
【００７５】
ここまで終了すると、最終的にＩＤ情報を取得していないノードはルートのみなので、ステップＳ３１８として与えていない番号で最も若い番号を自分のＩＤ番号と設定し、ステップＳ３１９としてルートのＩＤ情報をブロードキャストする。
【００７６】
以上で、図８に示したように、親子関係が決定した後から、すべてのノードのＩＤが設定されるまでの手順が終了する。
【００７７】
次に、一例として図９に示した実際のネットワークにおける動作を図９を参照しながら説明する。
【００７８】
図９の説明として、（ルート）ノードＢの下位にはノードＡとノードＣが直接接続されており、更にノードＣの下位にはノードＤが直接接続されており、更にノードＤの下位にはノードＥとノードＦが直接接続された階層構造になっている。この、階層構造やルートノード、ノードＩＤを決定する手順を以下で説明する。
【００７９】
バスリセットがされた後、まず各ノードの接続状況を認識するために、各ノードの直接接続されているポート間において、親子関係の宣言がなされる。この親子とは親側が階層構造で上位となり、子側が下位となると言うことができる。
【００８０】
図９ではバスリセットの後、最初に親子関係の宣言を行なったのはノードＡである。基本的にノードの１つのポートにのみ接続があるノード（リーフと呼ぶ）から親子関係の宣言を行なうことができる。これは自分には１ポートの接続のみということをまず知ることができるので、これによってネットワークの端であることを認識し、その中で早く動作を行なったノードから親子関係が決定されていく。こうして親子関係の宣言を行なった側（Ａ−Ｂ間ではノードＡ）のポートが子と設定され、相手側（ノードＢ）のポートが親と設定される。こうして、ノードＡ−Ｂ間では子−親、ノードＥ−Ｄ間で子−親、ノードＦ−Ｄ間で子−親と決定される。
【００８１】
さらに１階層あがって、今度は複数個接続ポートを持つノード（ブランチと呼ぶ）のうち、他ノードからの親子関係の宣言を受けたものから順次、更に上位に親子関係の宣言を行なっていく。図９ではまずノードＤがＤ−Ｅ間、Ｄ−Ｆ間と親子関係が決定した後、ノードＣに対する親子関係の宣言を行っており、その結果ノードＤ−Ｃ間で子−親と決定している。
【００８２】
ノードＤからの親子関係の宣言を受けたノードＣは、もう一つのポートに接続されているノードＢに対して親子関係の宣言を行なっている。これによってノードＣ−Ｂ間で子−親と決定している。
【００８３】
このようにして、図９のような階層構造が構成され、最終的に接続されているすべてのポートにおいて親となったノードＢが、ルートノードと決定された。
ルートは１つのネットワーク構成中に一つしか存在しないものである。
【００８４】
なお、この図９においてノードＢがルートノードと決定されたが、これはノードＡから親子関係宣言を受けたノードＢが、他のノードに対して親子関係宣言を早いタイミングで行なっていれば、ルートノードは他ノードに移っていたこともあり得る。すなわち、伝達されるタイミングによってはどのノードもルートノードとなる可能性があり、同じネットワーク構成でもルートノードは一定とは限らない。
【００８５】
ルートノードが決定すると、次は各ノードＩＤを決定するモードに入る。ここではすべてのノードが、決定した自分のノードＩＤを他のすべてのノードに通知する（ブロードキャスト機能）。
【００８６】
自己ＩＤ情報は、自分のノード番号、接続されている位置の情報、持っているポートの数、接続のあるポートの数、各ポートの親子関係の情報等を含んでいる。
【００８７】
ノードＩＤ番号の割り振りの手順としては、まず１つのポートにのみ接続があるノード（リーフ）から起動することができ、この中から順にノード番号＝０、１、２、・・・と割り当てられる。
【００８８】
ノードＩＤを手にしたノードは、ノード番号を含む情報をブロードキャストで各ノードに送信する。これによって、そのＩＤ番号は「割り当て済み」であることが認識される。
【００８９】
すべてのリーフが自己ノードＩＤを取得し終ると、次はブランチへ移りリーフに引き続いたノードＩＤ番号が各ノードに割り当てられる。リーフと同様に、ノードＩＤ番号が割り当てられたブランチから順次ノードＩＤ情報をブロードキャストし、最後にルートノードが自己ＩＤ情報をブロードキャストする。すなわち、常にルートは最大のノードＩＤ番号を所有するものである。
【００９０】
以上のようにして、階層構造全体のノードＩＤの割り当てが終わり、ネットワーク構成が再構築され、バスの初期化作業が完了する。
【００９１】
アービトレーションについて説明する。
【００９２】
１３９４シリアルバスでは、データ転送に先立って必ずバス使用権のアービトレーション（調停）を行なう。１３９４シリアルバスは個別に接続された各機器が、転送された信号をそれぞれ中継することによって、ネットワーク内すべての機器に同信号を伝えるように、論理的なバス型ネットワークであるので、パケットの衝突を防ぐ意味でアービトレーションは必要である。これによってある時間には、たった一つのノードのみ転送を行なうことができる。
【００９３】
アービトレーションを説明するための図として図１０（ａ）にバス使用要求の図（ｂ）にバス使用許可の図を示し、以下これを用いて説明する。
【００９４】
アービトレーションが始まると、１つもしくは複数のノードが親ノードに向かって、それぞれバス使用権の要求を発する。図１０（ａ）のノードＣとノードＦがバス使用権の要求を発しているノードである。これを受けた親ノード（図１０ではノードＡ）は更に親ノードに向かって、バス使用権の要求を発する（中継する）。この要求は最終的に調停を行なうルートに届けられる。
【００９５】
バス使用要求を受けたルートノードは、どのノードにバスを使用させるかを決める。この調停作業はルートノードのみが行なえるものであり、調停によって勝ったノードにはバスの使用許可を与える。図１０（ｂ）ではノードＣに使用許可が与えられ、ノードＦの使用は拒否された図である。
【００９６】
アービトレーションに負けたノードに対してはＤＰ（data prefix ）パケットを送り、拒否されたことを知らせる。拒否されたノードのバス使用要求は次回のアービトレーションまで待たされる。
【００９７】
以上のようにして、アービトレーションに勝ってバスの使用許可を得たノードは、以降データの転送を開始できる。
【００９８】
ここで、アービトレーションの一連の流れをフローチャート図１１に示して、説明する。
【００９９】
ノードがデータ転送を開始できる為には、バスがアイドル状態であることが必要である。先に行われていたデータ転送が終了して、現在バスが空き状態であることを認識するためには、各転送モードで個別に設定されている所定のアイドル時間ギャップ長（例えば、サブアクション・ギャップ）を経過する事によって、各ノードは自分の転送が開始できると判断する。
【０１００】
ステップＳ４０１として、Ａｓｙｎｃデータ、Ｉｓｏデータ等それぞれ転送するデータに応じた所定のギャップ長が得られたか判断する。所定のギャップ長が得られない限り、転送を開始するために必要なバス使用権の要求はできないので、所定のギャップ長が得られるまで待つ。
【０１０１】
ステップＳ４０１で所定のギャップ長が得られたら、ステップＳ４０２として転送すべきデータがあるか判断し、ある場合はステップＳ４０３として転送するためにバスを確保するよう、バス使用権の要求をルートに対して発する。このときの、バス使用権の要求を表す信号の伝達は、図１０に示したように、ネットワーク内各機器を中継しながら、最終的にルートに届けられる。ステップＳ４０２で転送するデータがない場合は、そのまま待機する。
【０１０２】
次に、ステップＳ４０４として、ステップＳ４０３のバス使用要求を１つ以上ルートが受信したら、ルートはステップＳ４０５として使用要求を出したノードの数を調べる。
【０１０３】
ステップＳ４０５での選択値がノード数＝１（使用権要求を出したノードは１つ）だったら、そのノードに直後のバス使用許可が与えられることとなる。ステップＳ４０５での選択値がノード数＞１（使用要求を出したノードは複数）だったら、ルートはステップＳ４０６として使用許可を与えるノードを１つに決定する調停作業を行う。この調停作業は公平なものであり、毎回同じノードばかりが許可を得る様なことはなく、平等に権利を与えていくような構成となっている（フェア・アービトレーション）。
【０１０４】
ステップＳ４０７として、ステップＳ４０６で使用要求を出した複数ノードの中からルートが調停して使用許可を得た１つのノードと、敗れたその他のノードに分ける選択を行う。ここで、調停されて使用許可を得た１つのノード、またはステップＳ４０５の選択値から使用要求ノード数＝１で調停無しに使用許可を得たノードには、ステップＳ４０８として、ルートはそのノードに対して許可信号を送る。
【０１０５】
許可信号を得たノードは、受け取った直後に転送すべきデータ（パケット）を転送開始する。また、ステップＳ４０６の調停で敗れて、バス使用が許可されなかったノードにはステップＳ４０９としてルートから、アービトレーション失敗を示すＤＰ（data prefix ）パケットを送られ、これを受け取ったノードは再度転送を行うためのバス使用要求を出すため、ステップＳ４０１まで戻り、所定ギャップ長が得られるまで待機する。
【０１０６】
以上がアービトレーションの流れを説明した、フローチャート図１１の説明である。
【０１０７】
Ａｓｙｎｃｈｒｏｎｏｕｓ（非同期）転送について説明する。
【０１０８】
アシンクロナス転送は、非同期転送である。図１２にアシンクロナス転送における時間的な遷移状態を示す。
【０１０９】
図１２の最初のサブアクション・ギャップは、バスのアイドル状態を示すものである。このアイドル時間が一定値になった時点で、転送を希望するノードはバスが使用できると判断して、バス獲得のためのアービトレーションを実行する。
【０１１０】
アービトレーションでバスの使用許可を得ると、次にデータの転送がパケット形式で実行される。データ転送後、受信したノードは転送されたデータに対しての受信結果のａｓｋ（受信確認用返送コード）をａｓｋ ｇａｐという短いギャップの後、返送して応答するか、応答パケットを送ることによって転送が完了する。ａｓｋは４ビットの情報と４ビットのチェックサムからなり、成功か、ビジー状態か、ペンディング状態であるかといった情報を含み、すぐに送信元ノードに返送される。
【０１１１】
つぎに、図１３にアシンクロナス転送のパケットフォーマットの例を示す。
【０１１２】
パケットには、データ部及び誤り訂正用のデータＣＲＣの他にはヘッダ部があり、そのヘッダ部には図１３に示すような、目的ノードＩＤ、ソースノードＩＤ、転送データ長さや各種コードなどが書き込まれ、転送が行なわれる。
【０１１３】
また、アシンクロナス転送は自己ノードから相手ノードへの１対１の通信である。転送元ノードから転送されたパケットは、ネットワーク中の各ノードに行き渡るが、自分宛てのアドレス以外のものは無視されるので、宛先の１つのノードのみが読込むことになる。
【０１１４】
以上がアシンクロナス転送の説明である。
【０１１５】
Ｉｓｏｃｈｒｏｎｏｕｓ（同期）転送について説明する。
【０１１６】
アイソクロナス転送は同期転送である。１３９４シリアルバスの最大の特徴であるともいえるこのアイソクロナス転送は、特に映像データや音声データといったマルチメディアデータなど、リアルタイムな転送を必要とするデータの転送に適した転送モードである。
【０１１７】
また、アシンクロナス転送（非同期）が１対１の転送であったのに対し、このアイソクロナス転送はブロードキャスト機能によって、転送元の１つのノードから他のすべてのノードへ一様に転送される。
【０１１８】
図１４はアイソクロナス転送における、時間的な遷移状態を示す図である。
【０１１９】
アイソクロナス転送は、バス上一定時間毎に実行される。この時間間隔をアイソクロナスサイクルと呼ぶ。アイソクロナスサイクル時間は、１２５μS である。この各サイクルの開始時間を示し、各ノードの時間調整を行なう役割を担っているのがサイクル・スタート・パケットである。サイクル・スタート・パケットを送信するのは、サイクル・マスタと呼ばれるノードであり、１つ前のサイクル内の転送終了後、所定のアイドル期間（サブアクションギャップ）を経た後、本サイクルの開始を告げるサイクル・スタート・パケットを送信する。
【０１２０】
このサイクル・スタート・パケットの送信される時間間隔が１２５μS となる。
【０１２１】
また、図１４にチャネルＡ、チャネルＢ、チャネルＣと示したように、１サイクル内において複数種のパケットがチャネルＩＤをそれぞれ与えられることによって、区別して転送できる。これによって同時に複数ノード間でのリアルタイムな転送が可能であり、また受信するノードでは自分が欲しいチャネルＩＤのデータのみを取り込む。このチャネルＩＤは送信先のアドレスを表すものではなく、データに対する論理的な番号を与えているに過ぎない。よって、あるパケットの送信は１つの送信元ノードから他のすべてのノードに行き渡る、ブロードキャストで転送されることになる。
【０１２２】
アイソクロナス転送のパケット送信に先立って、アシンクロナス転送同様アービトレーションが行われる。しかし、アシンクロナス転送のように１対１の通信ではないので、アイソクロナス転送にはａｓｋ（受信確認用返信コード）は存在しない。
【０１２３】
また、図１４に示したｉｓｏ ｇａｐ（アイソクロナスギャップ）とは、アイソクロナス転送を行なう前にバスが空き状態であると認識するために必要なアイドル期間を表している。この所定のアイドル期間を経過すると、アイソクロナス転送を行ないたいノードはバスが空いていると判断し、転送前のアービトレーションを行なうことができる。
【０１２４】
つぎに、図１５にアイソクロナス転送のパケットフォーマットの例を示し、説明する。
【０１２５】
各チャネルに分かれた、各種のパケットにはそれぞれデータ部及び誤り訂正用のデータＣＲＣの他にヘッダ部があり、そのヘッダ部には図１５に示すような、転送データ長やチャネルＮＯ、その他各種コード及び誤り訂正用のヘッダＣＲＣなどが書き込まれ、転送が行なわれる。
【０１２６】
以上がアイソクロナス転送の説明である。
【０１２７】
つぎに、バス・サイクルについて説明する。
【０１２８】
実際の１３９４シリアルバス上の転送では、アイソクロナス転送と、アシンクロナス転送は混在できる。その時の、アイソクロナス転送とアシンクロナス転送が混在した、バス上の転送状態の時間的な遷移の様子を表した図を図１６に示す。
【０１２９】
アイソクロナス転送はアシンクロナス転送より優先して実行される。その理由は、サイクル・スタート・パケットの後、アシンクロナス転送を起動するために必要なアイドル期間のギャップ長（サブアクションギャップ）よりも短いギャップ長（アイソクロナスギャップ）で、アイソクロナス転送を起動できるからである。したがって、アシンクロナス転送より、アイソクロナス転送は優先して実行されることとなる。
【０１３０】
図１６に示した、一般的なバスサイクルにおいて、サイクル＃ｍのスタート時にサイクル・スタート・パケットがサイクル・マスタから各ノードに転送される。これによって、各ノードで時刻調整を行ない、所定のアイドル期間（アイソクロナスギャップ）を待ってからアイソクロナス転送を行なうべきノードはアービトレーションを行い、パケット転送に入る。図１６ではチャネルｅとチャネルｓとチャネルｋが順にアイソクロナス転送されている。
【０１３１】
このアービトレーションからパケット転送までの動作を、与えられているチャネル分繰り返し行なった後、サイクル＃ｍにおけるアイソクロナス転送がすべて終了したら、アシンクロナス転送を行うことができるようになる。
【０１３２】
アイドル時間がアシンクロナス転送が可能なサブアクションギャップに達する事によって、アシンクロナス転送を行いたいノードはアービトレーションの実行に移れると判断する。
【０１３３】
ただし、アシンクロナス転送が行える期間は、アイソクロナス転送終了後から、次のサイクル・スタート・パケットを転送すべき時間（cycle synch ）までの間にアシンクロナス転送を起動するためのサブアクションギャップが得られた場合に限っている。
【０１３４】
図１６のサイクル＃ｍでは３つのチャネル分のアイソクロナス転送と、その後アシンクロナス転送（含むack ）が２パケット（パケット１、パケット２）転送されている。このアシンクロナスパケット２の後は、サイクルｍ＋１をスタートすべき時間（cycle synch ）にいたるので、サイクル＃ｍでの転送はここまでで終わる。
【０１３５】
ただし、非同期または同期転送動作中に次のサイクル・スタート・パケットを送信すべき時間（cycle synch ）に至ったとしたら、無理に中断せず、その転送が終了した後のアイドル期間を待ってから次サイクルのサイクル・スタート・パケットを送信する。すなわち、１つのサイクルが１２５μS 以上続いたときは、その分次サイクルは基準の１２５μS より短縮されたとする。このようにアイソクロナス・サイクルは１２５μS を基準に超過、短縮し得るものである。
【０１３６】
しかし、アイソクロナス転送はリアルタイム転送を維持するために毎サイクル必要であれば必ず実行され、アシンクロナス転送はサイクル時間が短縮されたことによって次以降のサイクルにまわされることもある。
こういった遅延情報も含めて、サイクル・マスタによって管理される。
【０１３７】
そこで、まず、第１の実施の形態について説明する。
【０１３８】
図１７は、本発明の特徴を最もよく表す図であり、同図において１３９４のインターフェイスをＬＡＮで用いられるＯＳＩモデルの各層と対比させてみると、ＯＳＩモデルの物理層１とデータリンク層２が、１３９４インターフェイスの下位層４であるフィジカル・リンク層に該当し、それら下位層４の上に存在する上位層３が１３９４インターフェイスではトランスポートプロトコル層５とプレゼンテーション層６に該当する。また、本発明の特徴となるＬＯＧＩＮプロトコル７は、１３９４インターフェイスの下位層４とトランスポートプロトコル５との間で動作するものである。
【０１３９】
この実施の形態では、シリアルバスプロトコル（ＳＢＰ−２）８に準拠したデバイスにＬＯＧＩＮプロトコルを挿入することによって、相手のデバイスに対して自分がＳＢＰ−２に準拠したプロトコルを使ってやり取りを行いたいことを通知することができる。また、後述する第３の実施の形態では、１３９４インターフェイス上で特化されたデバイスプロトコル９についてもＬＯＧＩＮプロトコルを挿入することで、お互いのデバイスがそのプロトコルがサポートされているかを判別してデータのやり取りを行うことができる。
【０１４０】
図１８は、ＬＯＧＩＮプロトコルの基本動作を示した図であり、プリンタは印字タスク１０を実行する際にまず初めにＬＯＧＩＮプロトコルを使ってプリンタで用意しているプリンタプロトコルＡ・Ｂ・Ｃのうち、どれを選択して印字するかを決定し、その後は決定されたプロトコルに沿って印字動作を行う。
すなわち、プリンタ側でいくつかのプリンタプロトコルをサポートしているデバイスにおいて、ターゲットとの接続の際にまず初めに相手のデバイスのプロトコルをＬＯＧＩＮプロトコルを使って判別し、プリンタは相手のプロトコルに合わせたプリンタプロトコルを複数の中からひとつ選択し、この選ばれたプロトコルに沿って印字データやコマンドのやり取りを行って印字処理を行う。
【０１４１】
図１９は、この実施の形態におけるＬＯＧＩＮプロトコルを実装した１３９４インターフェイスにおける各デバイスの接続形態を示した図で、複数のプリンタプロトコルに対応したプリンタ１１に対してＬＯＧＩＮプロトコルを実装したデバイス（ＰＣ１２、スキャナ１３、ＶＣＲ１４等）が接続された場合に、ＬＯＧＩＮプロトコルを使用して相手のトランスポートプロトコルに応じてプリンタ側でプリンタプロトコルを切り替えることにより、各デバイスからの印字タスクを問題なく処理することが可能となる。
【０１４２】
図２０はログイン動作の流れを示したものである。
【０１４３】
第一ステップ：
・デバイス（この場合マルチプロトコルプリンタ）をロック
・プリンタのケーパビリティ（受け付けるプロトコル等）を取得
かかるケーパビリティは、後述するレジスタ５０３に格納される。
・ホストのケーパビリティをプリンタにセット
第二ステップ：
・第一ステップで決定したプロトコルで、プリントデータの通信
第三ステップ：
・プリンタとホストは、コネクションを切断
【０１４４】
図２１は、この実施の形態においてＬＯＧＩＮプロトコルのためにプリンタが備える１３９４シリアルバスのＣＳＲを示し、図中、５０１はロックレジスタ（ｌｏｃｋ）、５０２はプロトコルレジスタ（ｐｒｏｔｏｃｏｌ）、５０３はケーパビリティレジスタ（ｃａｐａｂｉｌｉｔｙ）を示す。これらのレジスタは１３９４シリアルバスのアドレス空間における初期ユニット空間の定められたアドレスに配置される。ロックレジスタ５０１はリソースのロック状態を示し、値０はログイン可能な状態をあらわし、０以外はロック状態ですでにログインされていることをあらわす。ケーパビリティレジスタ５０３は設定可能なプロトコルを示し、ビット毎にプロトコルに対応し、ビットの値１はそのプロトコルが設定可能であることをあらわし、０は設定不可能であることをあらわす。プロトコルレジスタ５０２は現在設定されたプロトコルを示し、設定されたプロトコルに対応するケーパビリティレジスタ５０３のビットに相当するビットの値が１になる。
【０１４５】
図２２は、１３９４シリアルバスにより構成されたネットワーク（１３９４ネットワーク）におけるプリンタマップのフォーマットを示した図である。
【０１４６】
このプリンタマップには、応答を返してきたプリンタノードのユニークＩＤ（Unique ID ）、ノードＩＤ（Node ID ）、ステータス（Status）、ケーパビリティ（Capability）が保存される。
ここでいうステータス（Status）は、例えば、図２１のプロトコルレジスタ５０２の内容等を示し、ケーパビリティ（Capability）は、例えば、図２１のケーパビリティレジスタ５０３の内容等を示す。
【０１４７】
図２３は、ＣＲＣアーキテクチャにおけるノードユニークＩＤのフォーマットを示した図である。
【０１４８】
図２４は、プリンタマップ（図２２）の作成コマンドのフィーマットを示した図であり、このコマンドは、非同期パケットのライトトランザクションにより、ターゲットに通知される。
【０１４９】
図２４に示すようなコマンドは、このプロトコルにおいて、１３９４アドレス空間におけるターゲットのユニット空間の定められたアドレスに配置される。
【０１５０】
図２５は、複数のマルチプロトコルプリンタが１３９４ネットワークに接続されている場合のホスト側プリンティングプロトコル（ホスト側プリンタマップ作成処理）を示したフローチャートである。
【０１５１】
ここで、ネットワークにノードには、通常様々なデバイスが接続されている。このような状況下で、イニシエータ（ホスト）がプリンタの出力を試みる時、どのノードにプリンタが接続されているかを知る必要がある。また、プリンタの適切な出力を得るためには、プリンタの物理的な場所、その能力、その余力等を予め知っておくと非常に都合がよい。
【０１５２】
そこで、この実施の形態では、同一ネットワークに接続されているプリンタを調査する。
例えば、プリンタの出力時に、イニシエータ（ホスト）がネットワーク上のプリンタについて上述したような物理的な場所、能力及び余力等の情報（以下、トポロジー／能力情報とも言う）を得てプリンタマップを予め作成し、そのプリンタマップに基づいて目的のプリンタを選択する。
【０１５３】
以下、図２５を用いて、ホスト側のプリンタマップ作成処理について説明する。
【０１５４】
先ず、ホスト側は、プリンタマップ（図２２）を作成するために、その作成コマンド（図２４）をブロードキャストし（ステップＳ３００１）、ターゲットであるプリンタからの応答コマンドの受信待ち状態になる（ステップＳ３００２）。
【０１５５】
ホスト側は、ターゲットからの応答コマンドを受信すると、次に、その応答コマンドを返してきたターゲットのプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３００３）。これにより、ホスト側は、そのターゲットの能力や状態等を認識する。
【０１５６】
そして、ホスト側は、ステップＳ３００３で得た情報を基に、現在の１３９４ネットワーク上のプリンタについてのプリンタマップを作成する（ステップＳ３００４）。
【０１５７】
図２６は、上述したホスト側でのプリンタマップ作成処理時のターゲット側、すなわちプリンタ側の処理を示すフローチャートである。
【０１５８】
先ず、プリンタは、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３１０１）。
具体的には、例えば、現在の自プリンタの能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、プリンタ内部でのステータス及びケーパビリティの変化は、このステップでのステータス及びケーパビリティを提示にも反映する。
【０１５９】
次に、プリンタは、ホスト側からのプリンタマップ作成コマンドの受信待ち状態となる（ステップＳ３１０２）。
【０１６０】
そして、プリンタは、ホスト側からのプリンタマップ作成コマンドを受信すると、そのコマンドに対する応答コマンドをホスト側へ返す（ステップＳ３１０３）。
【０１６１】
図２７は、ログイン処理のホスト側のフローチャートである。
【０１６２】
ログインを開始するためには、図２５に示したプリンタマップ作成処理（ステップＳ６００）の後、ログインしようとするプリンタのロックレジスタ５０１、プロトコルレジスタ５０２、ケーパビリティレジスタ５０３をリードトランザクションにより確認する。ここで、ケーパビリティレジスタ５０３の内容から、ホストが通信に用いるプロトコルをプリンタがサポートしているかどうか確認する（ステップ６０１）。もしホストのプロトコルがプリンタのサポート外ならば、次のステップでログインを中止する。
【０１６３】
ロックレジスタ５０１が０以外であれば、他のデバイスがログイン中であるとみなし、ログインを中止する。ログインレジスタ５０１が０であれば、現在ログイン可能とみなす（ステップ６０２）。
【０１６４】
ログイン可能の場合リソースロック処理に移り、プリンタのロックレジスタ５０１にロックトランザクションを用いて１を書き込み、ホスト側のログイン設定とする（ステップ６０３）。この状態でプリンタはロックされたことになり、他のデバイスからの出力は不可能。またレジスタの変更も不可能とする。
【０１６５】
上記のようにプリンタのリソースがロックされた状態で、次にプロトコルの設定を行なう。本実施の形態におけるプリンタは、複数プリントプロトコルをサポートするため、プリントデータを受け取る前に、ホスト側のプロトコルを知らねばならない。ここでは、ホスト側がプリンタのプロトコルレジスタ５０２に対して、ライトトランザクションにより、これから使用するプロトコルに相当するビットを立て通知する（ステップ６０４）、という手段を用いる。
【０１６６】
この時点で、ホストが通信に用いるプロトコルがプリンタに通知され、かつプリンタがロック状態なので、現在ログインしているホストが通常のプロトコルでプリントデータの送信を行なう（ステップ６０５）。
【０１６７】
プリントデータの送信が終了したら、ホストはプリンタのロックレジスタ５０１、プロトコルレジスタ５０２、ケーパビリティレジスタ５０３をクリアすることにより、プリンタからログアウトする（ステップ６０６）。
【０１６８】
図２８は、ログイン処理のプリンタ側のフローチャートである。
【０１６９】
プリンタ側は、図２６に示したプリンタマップ作成処理（ステップＳ７００）の後、通常ホストからのログイン待ちの状態にいる。ホストからのプリントリクエストは、プリンタのロックレジスタ５０１、プロトコルレジスタ５０２、ケーパビリティレジスタ５０３の読み取りにより開始されるので、前記レジスタは、常に他のデバイスから読み出し可能の状態にしておく。今、プリントアウトを実行しようとするホストがプリンタをロックしたとする（ステップ７０１）。
【０１７０】
ロックレジスタ５０１への書き込みによりプリンタがロックされたら、次にホストからの、使用プロトコルの通知を待つ（ステップ７０２）。ロック状態になってからプロトコルの通知を待つのは、ログインの途中で、さらに他のデバイスからのリクエストにより、プロトコルレジスタ５０２を書き換えられないようにするためである。
【０１７１】
プロトコルの通知があったら、プリンタは自分の受け付けるプロトコルをスイッチし、ホスト側に合わせ、通信を行なう（ステップ７０３〜７１０）。
【０１７２】
通信が終了したら、プリンタはロックレジスタ５０１、プロトコルレジスタ５０２、ケーパビリティレジスタ５０３がクリアされたのを確認し（ステップ７１１）、ログイン待ち状態（ステップ７０１）に戻る。
【０１７３】
つぎに、第２の実施の形態について説明する。
【０１７４】
上述した第１の実施の形態では、図２５及び図２６を用いて説明したように、１３９４ネットワークに複数のプリンタが接続された場合において、ホストがネットワーク上のプリンタについてプリンタマップを作成し、そのプリンタマップに基づいて目的のプリンタを選択するようにしたが、この第２の実施の形態では、１３９４ネットワーク上でホスト及びプリンタが共に複数プロトコルをサポートしており、さらにそのようなプリンタが複数接続されている場合において、ホストが各プリンタの使用可能なプロトコルを調べて多数決を取り、最も多くサポートされているプロトコルを決定する。
【０１７５】
尚、この第２の実施の形態は、図２５及び図２６に示した処理以外については第１の実施の形態と同様であるため、その詳細な説明は省略し、ここでは、第１の実施の形態と異なる点についてのみ具体的に説明する。
【０１７６】
まず、図２９は、この実施の形態におけるホスト側のプリンタマップ作成処理を示すフローチャートであり、図３０は、この処理時のプリンタ側の処理を示すフローチャートである。
図２９の処理は、図２７に示したホスト側のログイン処理のステップＳ６００で行われる処理であり、図３０の処理は、図２９に示したプリンタ側のログイン処理のステップＳ７００で行われる処理である。
【０１７７】
ここで、この実施の形態では上述したように、１３９４ネットワーク上において、イニシエータ（ホスト）及びターゲット（プリンタ）共に複数プロトコルをサポートしており、さらにそのようなプリンタが同一ネットワークに複数台接続されている場合、当然イニシエータとターゲットが同一プロトコルを用いる必要があるが、今どのプロトコルを用いるかを決定するために、イニシエータが各プリンタの使用可能なプロトコルを調べ、その中で多数決を取り、最も多くサポートされているプロトコルを用いる。
【０１７８】
このように、多くのプロトコルが使用可能な状況下で多数決を取るように構成することで、実際に使用するプロトコルの種類を削減することができ、その結果、イニシエータのプロトコルスイッチによる負荷を下げることができる。
【０１７９】
以下、図２９及び図３０を用いて、イニシエータ側（ホスト側）及びターゲット側（プリンタ側）のプリンタマップ作成処理（相対多数プロトコル決定プリンタマップ処理）について説明する。
【０１８０】
先ず、ホスト側は、図２２に示したようなプリンタマップを作成するために、その作成コマンドをブロードキャストし（ステップＳ３２０１）、ターゲットであるプリンタからの応答コマンドの受信待ち状態になる（ステップＳ３２０２）。
【０１８１】
ホスト側は、ターゲットからの応答コマンドを受信すると、次に、その応答コマンドを返してきたターゲットのプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３２０３）。これにより、ホスト側は、そのターゲットの能力や状態等を認識する。
【０１８２】
次に、ホスト側は、ステップＳ３２０３で得た情報を基に、現在の１３９４ネットワーク上のプリンタについてのプリンタマップを作成する（ステップＳ３２０４）。
【０１８３】
次に、ホスト側は、ステップＳ３２０４で作成したプリンタマップより、現在ネットワークに接続されているマルチプロトコルプリンタの使用可能なプロトコルを調べ、それらのプロトコルの中から、最も多くサポートされているプロトコルを選択する（ステップＳ３２０５）。
【０１８４】
そして、ホスト側は、ステップＳ３２０５で選択したプロトコルを、プロトコル通知コマンドとして各プリンタに通知する（ステップＳ３２０６）。
【０１８５】
一方、プリンタは、先ず、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３３０１）。
具体的には、例えば、現在の自プリンタの能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、プリンタ内部でのステータス及びケーパビリティの変化は、このステップでのステータス及びケーパビリティを提示にも反映する。
【０１８６】
次に、プリンタは、ホスト側からのプリンタマップ作成コマンドの受信待ち状態となる（ステップＳ３３０２）。
【０１８７】
次に、プリンタは、ホスト側からのプリンタマップ作成コマンドを受信すると、そのコマンドに対する応答コマンドをホスト側へ返す（ステップＳ３３０３）。
【０１８８】
次に、プリンタは、ホスト側からのプロトコル通知コマンドの受信待ち状態となる（ステップＳ３４０２）。
【０１８９】
そして、プリンタは、ホスト側からのプロトコル通知コマンドを受信すると、そのコマンドに対する応答コマンドをホスト側へ返す（ステップＳ３５０３）。
【０１９０】
つぎに、第３の実施の形態について説明する。
【０１９１】
図３１は、この実施の形態における動作を示した図であり、図２に示した第１の実施の形態と比較してみるとＬＯＧＩＮプロトコルを実装していないプロトコルＤについても対応している点が特徴といえる。
すなわち、ＬＯＧＩＮプロトコルを持ったターゲットに対してだけでなく、既存のプロトコルＤ（例えばＡＶ／Ｃプロトコル）にのみ対応しているデバイスに対しても印字動作の保証を行う為に、プリンタ側で対応するプリンタプロトコルをＬＯＧＩＮプロトコルの持っていないデバイス用に追加を行ったものである。
【０１９２】
この動作について説明すると、接続の初めに行われるＬＯＧＩＮプロトコルによる会話によってターゲット側がＬＯＧＩＮプロトコルに対応していないことをプリンタ側が認識した際、プリンタ側はその他のプロトコルＤを使ってターゲットに会話を行い、そこで会話が成立した場合はそのプロトコルＤに沿った印字タスクを実行することができる。
【０１９３】
図３２は、この実施の形態におけるＯＳＩモデルとの対比を示した図であり、この実施の形態ではＬＯＧＩＮプロトコルの実装されていない現行のＡＶ／Ｃプロトコルに準拠したプリンタをモデルとしている。例４は、現行のプロトコルではまだ定義されていない、スキャナ用に作られたＬＯＧＩＮプロトコルの機能を持っていないプロトコルが実装されていた場合を表している。
すなわち、ＬＯＧＩＮプロトコルを実装していないプロトコルついてもプリンタ側で対応することができれば、繋がるターゲットデバイスの種類に幅ができるわけである。
【０１９４】
尚、上述した実施の形態では、主にネットワーク上のデバイスとしてプリンタを説明したが、これに限らず、モニタやコンピュータ、ディジタルカメラ等でもよく、特定の機種のデバイスに限定されるものではない。
【０１９５】
また、図２７のステップＳ６００、図２８のステップＳ７００、及び図２９のステップＳ３２０１で実行されるプリンタマップの作成においては、トポロジ接続状態が例えば図９のように調査され表示用マップが作成される、かかるトポロジ接続状態が判定されることによって、単なる多数決ではなく、トポロジ接続状態を加味して実際に使用するプロトコルを決定することができる。
【０１９６】
また、本発明は、図１９に示すような、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置内のデータ処理方法に適用してもよい。
【０１９７】
また、本発明の目的は、上述した各実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、達成されることは言うまでもない。
【０１９８】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した各実施の形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することとなる。
【０１９９】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０２００】
また、コンピュータが読みだしたプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２０１】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２０２】
【発明の効果】
以上説明したように本発明によれば、拡張性の高いデータ処理方法、データ処理装置、プリンタ及び記憶媒体を提供することができる。特に、複数種類のプリンタのプロトコルに対応可能であるので、拡張性が極めて高い。
また、同一ネットワークに接続されたプリンタを調査することで、目的とするプリンタを選択することができるため、最適なプリンタ出力を得ることができる。さらに、多くのプロトコルが使用可能な状況下であっても、それらのプロトコルのうちプリンタから最も多くサポートされているプロトコルを決定することで、実際に使用するプロトコルの種類を削減することができるため、ホスト側のプロトコルに切り替えによる負荷を下げることができる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４ケーブルを用いた通信システムの一例を示す図である。
【図２】ＩＥＥＥ１３９４の階層構造を示す図である。
【図３】ＩＥＥＥ１３９４のアドレスを示す図である。
【図４】ＩＥＥＥ１３９４のケーブル断面図である。
【図５】ＤＳ−Ｌｉｎｋ符号化方式を説明するための図である。
【図６】バスリセットからＩＤの設定までを説明するフローチャートである。
【図７】ルートの決定方法を説明するフローチャートである。
【図８】親子関係決定からすべてのノードＩＤの設定までの手順を説明するフローチャートである。
【図９】ノード間の親子関係を示す図である。
【図１０】アービトレーションの過程を説明するための図である。
【図１１】アービトレーションの過程を示すフローチャートである。
【図１２】Ａｓｙｎｃｈｒｏｎｏｕｓ転送におけるサブアクションを説明するための図である。
【図１３】Ａｓｙｎｃｈｒｏｎｏｕｓ転送におけるパケット構造を説明するための図である。
【図１４】Ｉｓｏｃｈｒｏｎｏｕｓ転送におけるサブアクションを説明するための図である。
【図１５】Ｉｓｏｃｈｒｏｎｏｕｓ転送におけるパケット構造を示す図である。
【図１６】ＩＥＥＥ１３９４の通信サイクルの一例を説明するための図である。
【図１７】第１の実施の形態において、本発明を適用したシステムを説明するための図である。
【図１８】ＬＯＧＩＮプロトコルの基本動作を説明するための図である。
【図１９】ＬＯＧＩＮプロトコルを実装した１３９４インターフェイスにおける各デバイスの接続形態を説明するための図である。
【図２０】ログイン動作の流れを説明するための図である。
【図２１】ＬＯＧＩＮプロトコルのためにプリンタが備える１３９４シリアルバスのＣＳＲを説明するための図である。
【図２２】１３９４ネットワークにおけるプリンタマップを説明するための図である。
【図２３】ＣＲＣアーキテクチャにおけるノードＩＤを説明するための図である。
【図２４】プリンタマップ作成のコマンドを説明するための図である。
【図２５】ホスト側のプリンタマップ作成処理を説明するためのフローチャートである。
【図２６】プリンタ側のプリンタマップ作成処理を説明するためのフローチャートである。
【図２７】ログイン処理のホスト側の処理を説明するためのフローチャートである。
【図２８】ログイン処理のプリンタ側の処理を説明するためのフローチャートである。
【図２９】第２の実施の形態におけるホスト側のプリンタマップ作成処理を説明するためのフローチャートである。
【図３０】上記第２の実施の形態におけるプリンタ側のプリンタマップ作成処理を説明するためのフローチャートである。
【図３１】第３の実施の形態におけるシステム動作を説明するための図である。
【図３２】上記第３の実施の形態におけるＯＳＩモデルとの対比を説明するための図である。
【符号の説明】
１ ＯＳＩモデルの物理層
２ データリンク層
３ 上位層
４ 上位層
５ トランスポートプロトコル層
６ プレゼンテーション層
７ ＬＯＧＩＮプロトコル
８ シリアルバスプロトコル（ＳＢＰ−２）
９ デバイスプロトコル
Claims (28)
- 共通シリアスバスを介して複数デバイスのプロトコルを切り換えるためのデータ処理方法であって、
前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行し、
前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定し、
前記初期プロトコルに続いて、決定されたプロトコルを実行することを特徴とするデータ処理方法。 - 前記初期プロトコルは、前記デバイスとしてのプリンタのＩＤ及び前記プリンタに固有のプロトコルを含む能力情報を得る処理を含むことを特徴とする請求項１記載のデータ処理方法。
- 前記プリンタのプロトコルは、インクジェットプリンタ用のプロトコルであることを特徴とする請求項２記載のデータ処理方法。
- 前記プリンタに固有のプロトコルの実行後に、プリントすべき画像データを伝送することを特徴とする請求項２または３記載のデータ処理方法。
- 前記画像データは、撮像手段によって光電変換されたデータであることを特徴とする請求項４に記載のデータ処理方法。
- 前記共通シリアルバスは、ＩＥＥＥ１３９４規格に適合したバスであることを特徴とする請求項１ないし５のいずれか１項に記載のデータ処理方法。
- 前記共通シリアルバスは、ＵＳＢ規格に適合したバスであることを特徴とする請求項１ないし５のいずれか１項に記載のデータ処理方法。
- 前記初期プロトコルは、ＯＳＩモデルのデータリンク層よりも上位の層で実行されるプロトコルであることを特徴とする請求項１ないし７のいずれか１項に記載のデータ処理方法。
- 共通シリアスバスを介して複数デバイスのプロトコルを切り換えるためのデータ処理装置であって、
前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行する第１の実行手段と、
前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定手段と、
前記初期プロトコルに続いて、決定されたプロトコルを実行する第２の実行手段とを備えることを特徴とするデータ処理装置。 - 前記初期プロトコルは、前記デバイスとしてのプリンタのＩＤ及び前記プリンタに固有のプロトコルを含む能力情報を得る処理を含むことを特徴とする請求項９記載のデータ処理装置。
- 前記プリンタのプロトコルは、インクジェットプリンタ用のプロトコルであることを特徴とする請求項１０記載のデータ処理装置。
- 前記第２の実行手段は、前記デバイスとしてのプリンタに固有のプロトコルの実行後に、プリントすべき画像データを伝送することを特徴とする請求項１０又は１１記載のデータ処理装置。
- 光電変換を行って得た前記画像データを前記第２の実行手段に与える撮像手段を備えることを特徴とする請求項１２記載のデータ処理装置。
- 前記共通シリアルバスは、ＩＥＥＥ１３９４規格に適合したバスであることを特徴とする請求項９ないし１３のいずれか１項に記載のデータ処理装置。
- 前記共通シリアルバスは、ＵＳＢ規格に適合したバスであることを特徴とする請求項９ないし１３のいずれか１項に記載のデータ処理装置。
- 前記初期プロトコルは、ＯＳＩモデルのデータリンク層よりも上位の層で実行されるプロトコルであることを特徴とする請求項９ないし１５のいずれか１項に記載のデータ処理装置。
- 共通シリアスバスを介して複数デバイスのプロトコルをホストに対応して切り換えるプリンタであって、
前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行する第１の実行手段と、
前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定手段と、
前記初期プロトコルに続いて、決定されたプロトコルを実行する第２の実行手段とを備えることを特徴とするプリンタ。 - 前記初期プロトコルは、プリンタのＩＤ及び前記プリンタに固有のプロトコルを含む能力情報を得る処理を含むことを特徴とする請求項１７記載のプリンタ。
- 前記プリンタのプロトコルは、インクジェットプリンタ用のプロトコルであることを特徴とする請求項１８記載のプリンタ。
- 光電変換を行って得た画像データを前記印字データとして前記受信手段に送信する撮像手段を備えることを特徴とする請求項１７ないし１９のいずれか１項に記載のプリンタ。
- 前記共通シリアルバスは、ＩＥＥＥ１３９４規格に適合したバスであることを特徴とする請求項１７ないし２０のいずれか１項に記載のプリンタ。
- 前記共通シリアルバスは、ＵＳＢ規格に適合したバスであることを特徴とする請求項１７ないし２０のいずれか１項に記載のプリンタ。
- 前記初期プロトコルは、ＯＳＩモデルのデータリンク層よりも上位の層で実行されるプロトコルであることを特徴とする請求項１７ないし２２のいずれか１項に記載のプリンタ。
- 共通シリアスバスを介して複数デバイスのプロトコルを切り換えるためのデータ処理方法を実行するためのデータ処理ステップをコンピュータに実行させるためのコンピュータプログラムをコンピュータが読み取り可能に記憶した記憶媒体であって、前記データ処理方法は、
前記デバイスとの間で行われる初期プロトコルの通信により、前記共通シリアスバスによる同一ネットワークにおける前記デバイスのＩＤを調査する第１の調査処理と、前記デバイスに固有のプロトコルを調査する第２の調査処理を実行するステップと、
前記第１の調査処理で得られたＩＤ及び前記第２の調査処理で得られたプロトコルに基づいて実行すべきプロトコルを決定するステップと、
前記初期プロトコルに続いて、決定されたプロトコルを実行するステップとを有することを特徴とする記憶媒体。 - 前記初期プロトコルは、前記デバイスとしてのプリンタのＩＤ及び前記プリンタに固有のプロトコルを含む能力情報を得る処理を含むことを特徴とする請求項２４記載の記憶媒体。
- 前記プリンタのプロトコルは、インクジェットプリンタ用のプロトコルであることを特徴とする請求項２５記載の記憶媒体。
- 前記第２の実行ステップは、前記デバイスとしてのプリンタに固有のプロトコルの実行後に、プリントすべき画像データを伝送するステップを含むことを特徴とする請求項２５または２６記載の記憶媒体。
- 前記初期プロトコルは、ＯＳＩモデルのデータリンク層よりも上位の層で実行されるプロトコルであることを特徴とする請求項２４ないし２７のいずれか１項に記載の記憶媒体。
Priority Applications (14)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11280997A JP3774542B2 (ja) | 1997-04-30 | 1997-04-30 | データ処理方法、データ処理装置、プリンタ及び記憶媒体 |
| SG200105141A SG101460A1 (en) | 1997-02-14 | 1998-02-10 | Data communication apparatus and method |
| TW087101785A TW384611B (en) | 1997-02-14 | 1998-02-10 | Data communication apparatus and method |
| SG1998000294A SG74611A1 (en) | 1997-02-14 | 1998-02-10 | Data communication apparatus and method |
| CA002229472A CA2229472C (en) | 1997-02-14 | 1998-02-11 | Data communication apparatus and method |
| MX9801199A MX9801199A (es) | 1997-02-14 | 1998-02-12 | Aparato y metodo de comunicacion de datos. |
| KR1019980004329A KR100298140B1 (ko) | 1997-02-14 | 1998-02-13 | 데이타통신장치및방법 |
| CN98104444A CN1126343C (zh) | 1997-02-14 | 1998-02-13 | 数据通信方法、设备和系统 |
| AU53921/98A AU5392198A (en) | 1997-02-14 | 1998-02-13 | Data communication apparatus and method |
| EP98301120A EP0859325A3 (en) | 1997-02-14 | 1998-02-16 | Data communication apparatus and method |
| EP05076775A EP1612691A1 (en) | 1997-02-14 | 1998-02-16 | Data communication apparatus and method |
| US09/025,128 US6425019B1 (en) | 1997-02-14 | 1998-02-17 | Data communication on a serial bus using an initial protocol which being executed in a transaction layer |
| US10/041,647 US6874082B2 (en) | 1997-02-14 | 2002-01-10 | Data communication on a serial bus using a selected protocol based on an obtained device identifier |
| US11/033,292 US7401213B2 (en) | 1997-02-14 | 2005-01-12 | Data communication apparatus and method of a device that supports plural communication methods |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11280997A JP3774542B2 (ja) | 1997-04-30 | 1997-04-30 | データ処理方法、データ処理装置、プリンタ及び記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10304007A JPH10304007A (ja) | 1998-11-13 |
| JP3774542B2 true JP3774542B2 (ja) | 2006-05-17 |
Family
ID=14596083
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP11280997A Expired - Fee Related JP3774542B2 (ja) | 1997-02-14 | 1997-04-30 | データ処理方法、データ処理装置、プリンタ及び記憶媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3774542B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11265338A (ja) * | 1998-03-13 | 1999-09-28 | Canon Inc | 情報処理装置、接続状態表示方法、情報処理システム及び記憶媒体 |
| JP5084359B2 (ja) | 2007-06-13 | 2012-11-28 | キヤノン株式会社 | 印刷装置およびその制御方法 |
| JP6155664B2 (ja) | 2013-01-30 | 2017-07-05 | セイコーエプソン株式会社 | プリンター、制御方法、及び制御プログラム |
-
1997
- 1997-04-30 JP JP11280997A patent/JP3774542B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10304007A (ja) | 1998-11-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6425019B1 (en) | Data communication on a serial bus using an initial protocol which being executed in a transaction layer | |
| JP3293779B2 (ja) | 信号処理装置およびその制御方法 | |
| JP3630971B2 (ja) | データ通信方法、装置、システム、及び記憶媒体 | |
| JP4018187B2 (ja) | 画像形成装置、画像形成システム、及び、画像形成方法 | |
| JP4072215B2 (ja) | 画像処理装置及びその制御方法、画像処理システム | |
| JP3682512B2 (ja) | 画像取り込み装置及びその制御方法、印刷システム、印刷方法、及び、印刷装置及びその制御方法 | |
| JP3774542B2 (ja) | データ処理方法、データ処理装置、プリンタ及び記憶媒体 | |
| JP3495879B2 (ja) | データ処理方法、データ処理装置、及びコンピュータ読み取り可能な記録媒体 | |
| JP3647328B2 (ja) | 画像処理装置及びその制御方法並びに画像処理システム | |
| JP3495878B2 (ja) | データ処理方法、データ処理装置及びプリンタ | |
| JP4058156B2 (ja) | データ処理方法、データ処理装置、プリンタ、及び記憶媒体 | |
| JP2000196873A (ja) | 情報処理装置及び情報処理システム及びそれらの方法と記憶媒体 | |
| JP3897773B2 (ja) | 通信方法及び通信装置 | |
| JPH10228364A (ja) | データ転送装置及びその制御方法及び印刷システム | |
| JP2003333045A (ja) | パワーマネージメント | |
| JP4463953B2 (ja) | 画像処理システム及びデジタルカメラとその制御方法 | |
| AU762552B2 (en) | Data communication apparatus and method | |
| JP3869941B2 (ja) | 印刷システム、印刷装置、および印刷方法 | |
| JPH10307691A (ja) | データ通信方法と装置及び印刷装置と前記装置を含む印刷システム | |
| JPH11177589A (ja) | データ転送装置およびデータ転送装置のデータ処理方法およびコンピュータが読み出し可能なプログラムを格納した記憶媒体 | |
| JP4653955B2 (ja) | 電子装置及びその制御方法 | |
| JPH11165454A (ja) | 画像処理装置及び画像処理システム | |
| JPH11284649A (ja) | ネットワークシステム及びネットワーク管理装置及び方法 | |
| JP2005269660A (ja) | 画像取り込み装置及びそのの制御方法、印刷システム、印刷方法、及び、印刷装置、及びそのの制御方法 | |
| JPH11185030A (ja) | 画像処理装置及び画像処理システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040428 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050930 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051115 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060113 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060207 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060220 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100224 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100224 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110224 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120224 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130224 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140224 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |