JP4058156B2 - データ処理方法、データ処理装置、プリンタ、及び記憶媒体 - Google Patents
データ処理方法、データ処理装置、プリンタ、及び記憶媒体 Download PDFInfo
- Publication number
- JP4058156B2 JP4058156B2 JP06366598A JP6366598A JP4058156B2 JP 4058156 B2 JP4058156 B2 JP 4058156B2 JP 06366598 A JP06366598 A JP 06366598A JP 6366598 A JP6366598 A JP 6366598A JP 4058156 B2 JP4058156 B2 JP 4058156B2
- Authority
- JP
- Japan
- Prior art keywords
- protocol
- serial bus
- printer
- data processing
- common serial
- 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
Description
【０００１】
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４−１９９５等のインターフェースを介して、複数種類のデバイスのプロトコルを切り換えるためのデータ処理方法、データ処理装置、プリンタ、及びそれらを実施するための処理ステップをコンピュータが読出可能に格納した記憶媒体に関するものである。
【０００２】
【従来の技術】
従来より、汎用インターフェースを介してプリンタにデータを送出するシステムとして、様々な種類のシステムが知られている。
例えば、ＳＣＳＩ（Small Computer System Interface ）や、セントロニクス等、一般に広く用いられるようになったデファクトスタンダードのインターフェースを用いて、コンピュータからプリンタにデータを出力する技術が知られている。
【０００３】
【発明が解決しようとする課題】
しかしながら、汎用インターフェースを介して、あるプリンタにプリントデータを転送するためのプリンタプロトコルは、そのプリンタの固有のものに限られていた。このように、従来では、ホストデバイスとターゲットデバイス間でデータ通信を行う際の通信プロトコルが、そのターゲットデバイスによって限定され、拡張性に欠ける、という問題が生じていた。
特に、様々な種類の機器を接続するインターフェース、例えば、ＩＥＥＥ１３９４のようなシリアルインターフェースを介してデータ転送する場合には、かかる拡張性に欠けるという問題点は解決すべき大きな課題である。
【０００４】
そこで、本発明は、上記の欠点を除去するために成されたもので、ホストデバイスとターゲットデバイス間でデータ通信を行う際の通信プロトコルが、そのターゲットデバイスによって限定されることがない、拡張性の高いデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
また、本発明は、ＩＥＥＥ１３９４規格等のシリアルインターフェースを用いた好適なデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
また、本発明は、コンピュータを介することなく、ホストデバイスからターゲットデバイスへ直接画像データ等を転送するのに好適なデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
また、本発明は、最適なプリンタ出力を得ることができるデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
また、本発明は、通信プロトコルの切り換えによる負荷を下げることができるデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
【０００５】
【課題を解決するための手段】
本発明のデータ処理方法は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理方法であって、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記初期プロトコルに続いて、上記複数種類のデバイス固有のプロトコルを実行し、上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する第１の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、上記第１の種類のデバイスに対してデータを出力する第２の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含む。
【０００６】
本発明のデータ処理方法における他の態様は、上記第１及び第２の調査処理は各々、デバイスの機能を調査する第３の調査処理を含み、上記初期プロトコルは、上記第１の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第１の種類のデバイスに対する実行すべきプロトコルを決定する処理と、上記第２の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第２の種類のデバイスに対する実行すべきプロトコルを決定する処理とを含む。
【０００７】
また、本発明のデータ処理方法におけるその他の態様は、上記第１の調査処理は、デバイスとしてのプリンタの状態及び能力を含む情報を得る処理を含み、上記第２の調査処理は、デバイスとしてのイメージ入力装置の状態及び能力を含む情報を得る処理を含む。
【０００８】
また、本発明のデータ処理方法におけるその他の態様は、上記プリンタに固有のプロトコルの実行後に、プリントすべき画像データを上記イメージ入力装置から上記プリンタに対して伝送する。
【０００９】
また、本発明のデータ処理方法におけるその他の態様は、上記共通シリアルバスは、ＩＥＥＥ１３９４規格に適合したバス、またはＵＳＢ規格に適合したバスである。
【００１０】
また、本発明のデータ処理方法におけるその他の態様は、上記初期プロトコルは、ＯＳＩモデルのデータリンク層よりも上位の層で実行されるプロトコルである。
【００１１】
また、本発明のデータ処理方法におけるその他の態様は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理方法であって、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記共通シリアルバスによる同一ネットワーク上に存在し、上記複数種類のうちの少なくとも１種のデバイスに対してデータを出力する種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する調査処理を含む。
【００１３】
本発明のデータ処理装置は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理装置であって、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行する第１の実行手段と、上記初期プロトコルに続いて、上記複数種類のデバイス固有のプロトコルを実行する第２の実行手段とを備え、上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する第１の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、上記第１の種類のデバイスに対してデータを出力する第２の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含む。
【００１４】
本発明のデータ処理装置における他の態様は、上記第１及び第２の調査処理は各々、デバイスの機能を調査する第３の調査処理を含み、上記初期プロトコルは、上記第１の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第１の種類のデバイスに対する実行すべきプロトコルを決定する処理と、上記第２の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第２の種類のデバイスに対する実行すべきプロトコルを決定する処理とを含む。
【００１５】
また、本発明のデータ処理装置におけるその他の態様は、上記第１の調査処理は、デバイスとしてのプリンタの状態及び能力を含む情報を得る処理を含み、上記第２の調査処理は、デバイスとしてのイメージ入力装置の状態及び能力を含む情報を得る処理を含む。
【００１６】
また、本発明のデータ処理装置におけるその他の態様は、上記第２の実行手段は、上記プリンタに固有のプロトコルの実行後に、プリントすべき画像データを上記イメージ入力装置から上記プリンタに対して伝送する。
【００１７】
また、本発明のデータ処理装置におけるその他の態様は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理装置であって、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記共通シリアルバスによる同一ネットワーク上に存在し、上記複数種類のうちの少なくとも１種のデバイスに対してデータを出力する種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する調査処理手段を備える。
【００１９】
本発明のデータ処理装置は、共通シリアルバスを介して複数のプロトコルをホストデバイスに対応して切り換えるプリンタであって、上記プロトコルの種類に係わらない初期プロトコルを実行する実行手段と、上記初期プロトコルに続いて、自機器に固有のプロトコルを実行した後、印字データを受信する受信手段とを備え、上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する自機器についての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、自機器に対して画像データを出力するイメージ入力装置についての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含む。
【００２０】
本発明の記憶媒体は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるデータ処理ステップをコンピュータに実行させるためのプログラムを格納するコンピュータ読み取り可能な記憶媒体であって、上記データ処理ステップは、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行する第１の実行ステップと、上記初期プロトコルに続いて、上記複数種類のデバイスに固有のプロトコルを実行する第２の実行ステップとを含み、上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する第１の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、上記第１の種類のデバイスに対してデータを出力する第２の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含む。
【００２１】
また、本発明の記憶媒体におけるその他の態様は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるデータ処理ステップをコンピュータに実行させるためのプログラムを格納するコンピュータ読み取り可能な記憶媒体であって、上記データ処理ステップは、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記共通シリアルバスによる同一ネットワーク上に存在し、上記複数種類のうちの少なくとも１種のデバイスに対してデータを出力する種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する調査処理ステップを含む。
【００６１】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００６２】
以下に説明する第１及び第２の実施の形態では、各機器間を接続するディジタルインターフェース（Ｉ／Ｆ）として、例えば、ＩＥＥＥ１３９４−１９９５（High Performance Serial Bus 、以下、単に「１３９４シリアルバス」と言う）を用いているため、まず、１３９４シリアルバスについて予めその概要を説明する。
【００６３】
［１３９４シリアルバスの概要］
【００６４】
民生用デジタルビデオカムレコーダ（ＶＣＲ）やディジタルビデオディスク（ＤＶＤ）プレーヤの登場に伴なって、ビデオデータやオーディオデータ（以下、これらをまとめて「ＡＶデータ」と言う）等、リアルタイムで且つ高情報量のデータを転送する必要が生じている。このようなＡＶデータをリアルタイムでパーソナルコンピュータ（ＰＣ、以下、単に「パソコン」と言う）や、その他のディジタル機器に転送して取り込ませるには、高速なデータ転送が可能なインターフェースが必要となる。そういった観点から開発されたインタフェースが、この１３９４シリアルバスである。
【００６５】
図１は、１３９４シリアルバスを用いて構成されるネットワーク・システムの一例を示した図である。
このシステムは、機器Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈを備えており、Ａ−Ｂ間、Ａ−Ｃ間、Ｂ−Ｄ間、Ｄ−Ｅ間、Ｃ−Ｆ間、Ｃ−Ｇ間、及びＣ−Ｈ間が、各々１３９４シリアルバス用のツイスト・ペア・ケーブルで接続された構成としている。
これらの機器Ａ〜Ｈの一例としては、パソコン等のホストコンピュータ装置、及びコンピュータ周辺機器である。
尚、ここでのコンピュータ周辺機器としては、ディジタルＶＣＲ、ＤＶＤプレーヤ、ディジタルスチルカメラ、ハードディスクや光ディスク等の記録媒体を用いる記憶装置、ＣＲＴやＬＣＤ等のモニタ、チューナ、イメージスキャナ、フィルムスキャナ、プリンタ、ＭＯＤＥＭ、ターミナルアダプタ（ＴＡ）等、コンピュータ周辺機器の全てが対象になる。
【００６６】
各機器間の接続は、ディジーチェーン方式とノード分岐方式との混在が可能であり、自由度の高い接続を行うことができるようになされている。また、各機器は各自固有のＩＤを有し、互いにＩＤを認識し合うことによって、１３９４シリアルバスで接続された範囲にて、１つのネットワークを構成している。
例えば、各機器間を各々１本の１３９４シリアルバス用ケーブルでディジーチェーン接続するだけで、各々の機器が中継の役割を担うため、全体として１つのネットワークを構成することができる。
【００６７】
また、１３９４シリアルバスは、Plug and Play 機能に対応しており、ケーブルを機器に接続するだけで自動的に機器を認識し、接続状況を認識する機能を有している。
このため、上記図１のシステムにおいて、ネットワークから任意の機器が外されたり、或いは、新たに加えられたとき等には、自動的にバスがリセット、すなわちそれまでのネットワークの構成情報がリセットされ、新たなネットワークが再構築される。このような機能によって、その時々のネットワークの構成を常時設定、認識することができる。
【００６８】
１３９４シリアルバスのデータ転送速度は、１００／２００／４００Ｍｂｐｓが定義されており、上位の転送速度を持つ機器が下位の転送速度をサポートすることで、互換性を保つようになされている。
【００６９】
データ転送モードとしては、コントロール信号等の非同期データを転送するAsynchronous転送モード（ＡＴＭ）と、リアルタイムなＡＶデータの同期データを転送するIsochronous 転送モードがある。
これらの転送モードにより、非同期データ及び同期データは、各サイクル（通常１２５μS ／サイクル）の中で、サイクル開始を示すサイクル・スタート・パケット（ＣＳＰ）の転送に続き、同期データの転送を優先しつつ、サイクル内で混在して転送される。
【００７０】
図２は、１３９４シリアルバスの構成要素を示す図である。
この１３９４シリアルバスは、レイヤ構造で構成されている。上記図２に示すように、１３９４シリアルバス用のケーブル８１３の先端のコネクタには、１３９４コネクタ・ポート８１０が接続される。
【００７１】
１３９４コネクタ・ポート８１０の上位には、フィジカルレイヤ８１１及びリンクレイヤ８１２を含むハードウェア部８００が位置づけられている。
ハードウェア部８００は、インターフェース用チップで構成され、そのうちフィジカルレイヤ８１１は、符号化やコネクタ関連の制御等を行い、リンクレイヤ８１２は、パケット転送やサイクルタイムの制御等を行なう。
【００７２】
ハードウェア部８００の上位には、トランザクションレイヤ８１４及びマネージメントレイヤ８１５を含むファームウェア部８０１が位置づけられている。そのトランザクションレイヤ８１４は、転送（トランザクション）すべきデータの管理を行ない、Ｒｅａｄ、Ｗｒｉｔｅ、Ｌｏｃｋの命令を出す。また、マネージメントレイヤ８１５は、１３９４シリアルバスに接続されている各機器の接続状況やＩＤの管理を行ない、ネットワークの構成を管理する。
【００７３】
これらのハードウェア部８００及びファームウェア８０１までが、１３９４シリアルバスの実質的な構成である。
【００７４】
ファームウェア８０１の上位には、アプリケーションレイヤ８１６を含むソフトウェア部８０２が位置づけられている。そのアプリケーションレイヤ８１６は、利用されるソフトによって異なり、インタフェース上でどのようにしてデータを転送するかは、プリンタやＡＶ／Ｃプロトコル等のプロトコルによって定義されている。
【００７５】
図３は、１３９４シリアルバスにおけるアドレス空間の図を示す図である。
１３９４シリアルバスに接続された各機器（ノード）には必ず、上記図３に示すような、各ノード固有の６４ビットアドレスを持たせておく。このアドレスは機器のメモリに格納されており、これにより自分や相手のノードアドレスを常時認識することで、通信相手を指定したデータ通信が行える。
【００７６】
１３９４シリアルバスのアドレッシングは、ＩＥＥＥ１２１２規格に準じた方式で行われ、アドレス設定については、最初の１０ビットがバスの番号（バスＮｏ．）の指定用に、次の６ビットがノードＩＤ（ノードＮｏ．）の指定用に使用される。そして、残りの４８ビットが、機器に与えられたアドレス幅になる。この４８ビット領域は、各々固有のアドレス空間として使用できる。そのうちの最後の２８ビットについては、機器に固有のデータの領域（固有データ領域）であり、各機器の識別や使用条件の指定の情報等が格納される。
【００７７】
以上が、１３９４シリアルバスについての概要である。
つぎに、１３９４シリアルバスの特徴をより詳細に説明する。
【００７８】
［１３９４シリアルバスの電気的仕様］
【００７９】
図４は、１３９４シリアルバス用のケーブルの断面を示す図である。
この図４に示すように、１３９４シリアルバス用のケーブルでは、２組のツイストペア信号線の他に、電源ラインが設けられている。このような構成によって、電源を持たない機器や、故障等により電圧低下した機器等にも、電力の供給が可能となる。
また、電源線により供給される直流電力の電圧は、８〜４０Ｖ、その電流は、最大電流１．５Ａに規定されている。
尚、ＤＶケーブルと呼ばれる規格では、電源ラインを省いた四線で構成される。
【００８０】
［ＤＳ−Ｌｉｎｋ方式］
【００８１】
図５は、１３９４シリアルバスでデータ転送方式として採用されている、ＤＳ−Ｌｉｎｋ（Data/Strobe Link）方式を説明するための図である。
ＤＳ−Ｌｉｎｋ方式は、高速なシリアルデータ通信に適し、２組の信号線を必要とする。すなわち、２組の対線のうち一方の信号線でデータ信号を送り、他方の信号線でストローブ信号を送る構成となっている。したがって、受信側は、このデータ信号とストローブ信号を受信して排他的論理和をとることによって、クロックを再現することができる、という特徴がある。
このように、ＤＳ−Ｌｉｎｋ方式では、データ信号中にクロック信号を混入させる必要がない。したがって、ＤＳ−Ｌｉｎｋ方式では、他のシリアルデータ転送方式に比べ転送効率が高いクロック信号を生成できるため、位相ロックドループ（ＰＬＬ）回路が不要になり、その分コントローラＬＳＩの回路規模を小さくすることができる。また、転送すべきデータが無いときに、アイドル状態であることを示す情報を送る必要が無いため、各機器のトランシーバ回路をスリープ状態にすることができ、消費電力の低減が図れる。
【００８２】
［バスリセットのシーケンス］
【００８３】
１３９４シリアルバスに接続されている各機器（ノード）には、ノードＩＤが与えられ、ネットワークを構成するノードとして認識される。
【００８４】
例えば、ネットワーク機器の接続分離や、電源のＯＮ／ＯＦＦ等によるノード数の増減、すなわちネットワーク構成に変化があり、新たなネットワーク構成を認識する必要があるとき、その変化を検知した各ノードは、バス上にバスリセット信号を送信して、新たなネットワーク構成を認識するモードに入る。
このときのネットワーク構成の変化の検知は、１３９４コネクタ・ポート（上記図２、以下、単に「コネクタポート」と言う）において、バイアス電圧の変化を検知することによって行われる。
【００８５】
そこで、あるノードからバスリセット信号が送信されると、各ノードのフィジカルレイヤ８１１（上記図２）は、送信されてきたバスリセット信号を受信すると同時に、リンクレイヤ８１２（上記図２）にバスリセット信号の発生を伝達し、且つ他のノードに対してバスリセット信号を送信する。そして、最終的に全てのノードがバスリセット信号を受信した後、バスリセットのシーケンスが起動される。
【００８６】
尚、バスリセットのシーケンスは、ケーブルが抜き挿しされた場合や、ネットワークの異常等をハードウェアが検出した場合に起動されると共に、プロトコルによるホスト制御等、フィジカルレイヤ８１１（上記図２）に直接命令を与えることによっても起動される。また、バスリセットのシーケンスが起動されると、データ転送は一時中断され、そのシーケンスの起動間は待機状態となり、バスリセット終了後、新しいネットワーク構成のもとで再開される。
【００８７】
［ノードＩＤ決定のシーケンス］
【００８８】
上述のようにして、バスリセットのシーケンスが起動され、バスリセットが終了した後、各ノードは、新しいネットワーク構成を構築するために、各ノードにＩＤを与える動作に入る。このときの、バスリセットからノードＩＤ決定までの一般的なシーケンスについてを、図６〜図８の各フローチャートを用いて説明する。
【００８９】
上記図６は、バスリセット信号の発生から、ノードＩＤが決定してデータ転送が行えるようになるまでの、一連のシーケンスを示すフローチャートである。
この図６において、先ず、各ノードは、バスリセット信号を常時監視し（ステップＳ１０１）、バスリセット信号が発生したことを検知すると、ネットワーク構成がリセットされた状態において新たなネットワーク構成を得るために、互いに直結されている各ノード間で親子関係を宣言する（ステップＳ１０２）。
このステップＳ１０２の処理は、ステップＳ１０３の判定により、全てのノード間で親子関係が決定されたと判定されるまで繰り返される。そして、全てのノード間で親子関係が決定されると、次に、ルートを決定する（ステップＳ１０４）。
【００９０】
ステップＳ１０４にてルートが決定されると、次に、各ノードにＩＤを与えるノードＩＤの設定作業を行う（ステップＳ１０５）。
このステップＳ１０５の処理は、ルートから所定のノード順にノードＩＤの設定を行う処理であり、ステップＳ１０６の判定により、全てのノードにＩＤが与えられたと判定されるで繰り返される。
そして、全てのノードへのノードＩＤの設定が終了すると、新しいネットワーク構成が全てのノードにおいて認識され、ノード間のデータ転送が行える状態となる。この状態にて、各ノードは、データ転送を開始し（ステップＳ１０７）、これと同時にステップＳ１０１へと戻り、再びバスリセット信号の発生を監視する。
【００９１】
そこで、上記図７は、上述のバスリセット信号の監視（ステップＳ１０１）からルート決定（ステップＳ１０４）までの処理の詳細を示すフローチャートであり、上記図８は、上述のＩＤ設定（ステップＳ１０５、Ｓ１０６）の処理の詳細を示すフローチャートである。
【００９２】
先ず、上記図７において、各ノード（機器）は、バスリセット信号の発生を監視し（ステップＳ２０１）、バスリセット信号が発生したこと検知する。これにより、ネットワーク構成は、一旦リセットされる。
【００９３】
次に、リセットされたネットワーク構成を再認識する作業の第一段階として、各ノードは、フラグＦＬをリーフ（ノード）であることを示すデータでリセットする（ステップＳ２０２）。
その後、各ノードは、ポート数、すなわち自分に接続されている他ノードの数を調べ（ステップＳ２０３）、その結果に応じて、これから親子関係の宣言を始めるために、未定義（親子関係が決定されていない）ポートの数を調べる（ステップＳ２０４）。
尚、ステップＳ２０４で検知される未定義ポート数は、バスリセットの直後はポート数に等しいが、親子関係が決定されていくに従って減少する。
【００９４】
ここで、バスリセットの直後、親子関係の宣言を行えるのは、実際のリーフに限られている。リーフであるか否かは、ステップＳ２０３のポート数の確認結果から知ることができ、すなわちこのポート数が”１”であればリーフである。したがって、ステップＳ２０４で検知される未定義ポート数が”１”であった場合、リーフは、接続相手のノードに対して親子関係の宣言「自分は子、相手は親」を行い（ステップＳ２０５）、本シーケンスを終了する。
【００９５】
また、ステップＳ２０３のポート数の確認結果が”２”以上であったノード、すなわちブランチ（ノード）は、バスリセットの直後はステップＳ２０４で検知される未定義ポート数が”未定義ポート数＞１”となるため、フラグＦＬにブランチを示すデータをセットして（ステップＳ２０６）、他ノードから親子関係が宣言されるのを待つ（ステップＳ２０７）。
そして、他ノードから親子関係が宣言され、それを受けたブランチは、ステップＳ２０４に戻って未定義ポート数を確認する。このとき、もし未定義ポート数が”１”になっていれば、残ポートに接続されている他ノードに対して、ステップＳ２０５で「自分は子、相手は親」の親子関係を宣言することができる。また、まだ未定義ポート数が”２”以上あるブランチは、再度ステップＳ２０７で再び他ノードから「親子関係」が宣言されるのを待つことになる。
【００９６】
また、何れか１つのブランチ、又は、例外的に子宣言を行えるのにもかかわらずすばやく動作しなかったリーフの未定義ポート数が”０”になると、ネットワーク全体の親子関係の宣言が終了したことになる。このため、未定義ポート数が”０”になった唯一のノード、すなわち全てノードの親に決まったノードは、フラグＦＬにルート（ノード）を示すデータをセットする（ステップＳ２０８）。これにより、このノードは、ルートとして認識されることになり（ステップＳ２０９）、その後、本シーケンス終了となる。
【００９７】
上述のようにして、バスリセットから、ネットワーク内のノード間における親子関係の宣言までの処理が終了する。
次に、各ノードにＩＤを与える処理を行うが、ここで、最初にＩＤの設定を行うことができるのは、リーフである。したがって、ここでは、リーフ→ブランチ→ルートの順に若い番号（ノード番号：０）からＩＤを設定する。
【００９８】
すなわち、上記図８において、先ず、フラグＦＬに設定されたデータを基に、ノードの種類、すなわちリーフ、ブランチ、及びルートに応じた処理に分岐する（ステップＳ３０１）。
【００９９】
ステップＳ３０１の結果が”リーフ”であった場合、ネットワーク内に存在するリーフの数（自然数）が変数Ｎに設定される（ステップＳ３０２）。その後、リーフは、ルートに対してノード番号を要求する（ステップＳ３０３）。この要求が複数ある場合、これを受けたルートは、アービトレーションを行い（ステップＳ３０４）、ある１つのノードにノード番号を与え、他のノードにはノード番号の取得失敗を示す結果を通知する（ステップＳ３０５）。
【０１００】
ステップＳ３０６の判定により、ノード番号を取得できなかったリーフは、再びステップＳ３０３でノード番号の要求を繰り返す。
【０１０１】
一方、ステップＳ３０６の判定により、ノード番号を取得できたリーフは、取得したノード番号を含むＩＤ情報をブロードキャストすることで、全ノードに通知する（ステップＳ３０７）。このＩＤ情報のブロードキャストが終了すると、リーフの数を表す変数Ｎがデクリメントされる（ステップＳ３０８）。
その後、ステップＳ３０９の判定により、変数Ｎが”０”になるまで、ステップＳ３０３〜ステップＳ３０８の処理が繰り返される。全てのリーフのＩＤ情報がブロードキャストされると、次のブランチのＩＤ設定処理（ステップＳ３１０〜Ｓ３１７）に移る。
【０１０２】
このブランチのＩＤ設定処理は、ステップＳ３０１の結果がブランチであった場合にも実行される処理であり、上述のリーフのＩＤ設定時と同様に、先ず、ネットワーク内に存在するブランチの数（自然数）が変数Ｍに設定される（ステップＳ３１０）。その後、ブランチは、ルートに対してノード番号を要求する（ステップＳ３１１）。
この要求に対してルートは、アービトレーションを行い（ステップＳ３１２）、ある１つのブランチにはリーフに続く若い番号を与え、ノード番号を取得できなかったブランチには取得失敗を示す結果を通知する（ステップＳ３１３）。
【０１０３】
ステップＳ３２４の判定により、ノード番号の取得できなかったブランチは、再びステップＳ３１１でノード番号の要求を繰り返す。
【０１０４】
一方、ノード番号を取得できたブランチは、取得したノード番号を含むＩＤ情報をブロードキャストすることで、全ノードに通知する（ステップＳ３１５）、。このＩＤ情報のブロードキャストが終了すると、ブランチ数を示す変数Ｍがデクリメントされる（ステップＳ３１６）。
その後、ステップＳ３１７の判定により、変数Ｍが”０”になるまで、ステップＳ３１１〜ステップＳ３１６の処理が繰り返され、全てのブランチのＩＤ情報がブロードキャストされると、次のルートのＩＤ設定処理（ステップＳ３１８、Ｓ３１９）に移る。
【０１０５】
ここまでの処理が終了すると、最終的にＩＤ情報を取得していないノードはルートのみであるため、次のルートのＩＤ設定処理では、ルートは、他のノードに与えていない最も若い番号を自分のノード番号に設定し（ステップＳ３１８）、そのノード番号を含むＩＤ情報をブロードキャストする（ステップＳ３１９）。尚、このルートのＩＤ設定処理は、ステップＳ３０１の結果がルートの場合にも実行される処理である。
【０１０６】
上述のような処理により、全てのノードに対してＩＤが設定される。
そこで、図９に示すネットワーク例を用いて、ノードＩＤ決定のシーケンスの具体的な手順を説明する。
【０１０７】
この図９に示すネットワークは、ルートであるノードＢの下位にはノードＡとノードＣが直結され、ノードＣの下位にはノードＤが直結され、ノードＤの下位にはノードＥとノードＦが直結された階層構造を有する。このようなネットワークでの階層構造やルートノード、ノードＩＤを決定する手順は、以下のようになる。
【０１０８】
バスリセット信号が発生した後、各ノードの接続状況を認識するために、先ず、各ノードの直接接続されているポート間において親子関係の宣言がなされる。ここでいう「親子」とは、階層構造の上位が「親」、下位が「子」という意味である。
【０１０９】
上記図９では、バスリセットの後、最初に親子関係を宣言したのはノードＡである。
ここで、上述したように、１つのポートだけが接続されたノード（リーフ）から親子関係の宣言を開始することができる。これは、ポート数が”１”であれば、ネットワークの末端、すなわちリーフであるためである。これがが認識されると、それらのリーフ中で最も早く動作を行なったノードから親子関係が決定されていくことになる。このようにして、親子関係の宣言を行なったノードのポートが互いに接続された２つのノードの「子」と設定され、相手ノードのポートが「親」と設定される。したがって、上記図９では、ノードＡ−Ｂ間、ノードＥ−Ｄ間、ノードＦ−Ｄ間で「子−親」と設定されることになる。
【０１１０】
次に、階層が１つ上がって、複数のポートを持つノード、すなわちブランチのうち、他ノードから親子関係の宣言を受けたノードから順次、上位のノードに対して親子関係の宣言がなされる。
【０１１１】
上記図９では、先ず、ノードＤ−Ｅ間、Ｄ−Ｆ間の親子関係が決定された後、ノードＤがノードＣに対して親子関係を宣言し、その結果、ノードＤ−Ｃ間で「子−親」の関係が設定される。
ノードＤからの親子関係の宣言を受けたノードＣは、もう１つのポートに接続されているノードＢに対して親子関係を宣言し、これによってノードＣ−Ｂ間で「子−親」の関係が設定される。
【０１１２】
このようにして、上記図９に示すような階層構造が構成され、最終的に接続されている全てのポートにおいて親となったノードがルートと決定される（上記図９では、ノードＢがルートとなる）。
尚、ルートは、１つのネットワーク構成中に１つしか存在しない。また、ノードＡから親子関係を宣言されたノードＢが速やかに他のノードに対して親子関係を宣言した場合は、例えば、ノードＣ等の他のノードがルートになる可能性もあり得る。すなわち、親子関係の宣言が伝達されるタイミングによっては、どのノードもルートとなる可能性があり、ネットワーク構成が同一であっても、特定のノードがルートになるとは限らない。
【０１１３】
ルートが決定されると、各ノードＩＤの決定モードに入る。全てのノードは、決定した自分のＩＤ情報を、他の全てのノードに通知するブロードキャスト機能を持っている。
尚、ＩＤ情報は、ノード番号、接続されている位置の情報、持っているポートの数、接続のあるポートの数、各ポートの親子関係の情報等を含む情報として、ブロードキャストされる。
【０１１４】
ノード番号の割当としては、上述したようにリーフから開始され、順に、ノード番号＝０、１、２、・・・が割り当てられる。そして、ＩＤ情報のブロードキャストによって、そのノード番号は、割り当て済みであることが認識される。
全てのリーフがノード番号を取得し終ると、次はブランチへ移り、リーフに続くノード番号が割り当てられる。リーフと同様に、ノード番号が割り当てられたブランチから順にＩＤ情報がブロードキャストされ、最後にルートが自己のＩＤ情報をブロードキャストする。したがって、ルートは常に最大のノード番号を所有することになる。
【０１１５】
以上のようにして、階層構造全体のＩＤ設定が終了し、ネットワーク構成が再構築され、バスの初期化作業が完了することになる。
【０１１６】
［バスアービトレーション］
【０１１７】
１３９４シリアルバスは、データ転送に先立って必ずバスの使用権のアービトレーションを行なう。１３９４シリアルバスに接続された各機器（ノード）は、ネットワーク上で転送されるデータを各々中継することによって、ネットワーク内の全ての機器に同データを伝える論理的なバス型ネットワークを構成するため、パケットの衝突を防ぐ意味でバスアービトレーションが必要である。これによって、ある時間には、１つの機器だけがデータ転送を行なうことができる。
【０１１８】
図１０（ａ）及び（ｂ）は、アービトレーションを説明するための図であり、上記図１０（ａ）は、バス使用権を要求する動作を示し、上記図１０（ｂ）は、バスの使用を許可する動作を示している。
【０１１９】
バスアービトレーションが始まると、１つ若しくは複数のノードが親ノードに向かって、各々バス使用権を要求する。上記図１０（ａ）では、ノードＣが、その親ノードであるノードＢに対して、ノードＦが、その親ノードであるノードＡに対して、各々バス使用権を要求している。
この要求を受けた親ノードは、更に親ノードに向かって、バス使用権を要求することで、子ノードによるバス使用権の要求を中継する。この要求は最終的に調停を行なうルートに届けられる。上記図１０（ａ）では、ノードＦからの要求を受けたノードＡが、その親ノードであるノードＦに対してバス使用権を要求している。すなわち、ノードＡがノードＦによるバス使用権の要求を中継している。
【０１２０】
バス使用権の要求を受けたルートは、どのノードにバス使用権を与えるかを決定する。この調停作業はルートのみが行なえるものであり、調停に勝ったノードには、バス使用の許可が与えられる。上記図１０（ｂ）は、ノードＣにバス使用許可が与えられ、ノードＦのバス使用権の要求は拒否された状態を示している。このとき、ルートは、バスアービトレーションに負けたノードに対してＤＰ（data prefix ）パケットを送り、そのバス使用権の要求が拒否されたことを知らせる。バスアービトレーションに負けたノードのバス使用権の要求は、次回のバスアービトレーションまで待たされることになる。
一方、バスアービトレーションに勝ち、バス使用許可を得たノードは、以降、データ転送を開始することができる。
【０１２１】
ここで、バスアービトレーションの一連の流れのフローチャートを、図１１に示して説明する。
【０１２２】
まず、ノードがデータ転送を開始できる為には、バスがアイドル状態であることが必要である。先に行われていたデータ転送が終了して、現在、バスがアイドル状態にあることを認識するためには、各転送モードで個別に設定されている所定のアイドル時間のギャップ長（例えば、サブアクション・ギャップ）の経過を検出すればよい。
【０１２３】
そこで、先ず、各ノードは、転送する非同期データ又は同期データに応じた所定のギャップ長が得られたか否かを判定する（ステップＳ４０１）。この所定のギャップ長が得られない限り、各ノードは、転送を開始するために必要なバス使用権を要求することはできない。したがって、各ノードは、所定のギャップ長が得られるまで待ち状態となる。
【０１２４】
ステップＳ４０１により、所定のギャップ長が得られると、そのノードは、転送すべきデータがあるか判定し（ステップＳ４０２）、転送データ有りの場合には、バス使用権を要求する信号をルートに対して送信する（ステップＳ４０３）。このバス使用権の要求を示す信号は、上記図１０（ａ）に示したように、ネットワーク内の各機器に中継されながら、最終的にルートに届けられる。
尚、ステップＳ４０２において、転送データ無しと判定された場合、そのノードは、そのまま待機状態となる。
【０１２５】
ルートは、バス使用権を要求する信号を１つ以上受信すると（ステップＳ４０４）、そのバス使用権を要求したノードの数を調べる（ステップＳ４０５）。
このステップＳ４０５の結果、バス使用権を要求したノードが１つであった場合、ルートは、そのノードに直後のバス使用許可を与える（ステップＳ４０８）。
【０１２６】
一方、ステップＳ４０５の結果、バス使用権を要求したノードが複数であった場合、ルートは、直後のバス使用許可を与えるノードを１つに絞る調停作業を行う（ステップＳ４０６）。この調停作業は、毎回同じノードのみにバスの使用許可が与えられるという様なことはなく、平等にバス使用権が与えられるようにするための作業である（フェア・アービトレーション）。
【０１２７】
その結果、調停に勝った１つのノードと、敗れたその他のノードとに応じて、処理が分岐する（ステップＳ４０７）。
これにより、調停に勝った１つのノードには、直後のバス使用許可を示す許可信号が送られる（ステップＳ４０８）。したがって、この許可信号を受信したノードは、直後に転送すべきデータ（パケット）の転送を開始する。そして、そのデータ転送完了後、ステップＳ４０１へと戻る。
また、調停に敗れたノードには、バス使用権の要求が拒否されたことを示すＤＰ（data prefix ）パケットが送られる（ステップＳ４０９）。したがって、ＤＰパケットを受け取ったノードは、再度バス使用権を要求するために、ステップＳ４０１へと戻る。
【０１２８】
［Asynchronous転送］
【０１２９】
図１２は、アシンクロナス転送における時間的な遷移状態を示した図である。この図１２において、最初の”subaction gap ”（サブアクション・ギャップ）は、バスのアイドル状態を示すものである。このアイドル状態の時間が所定値になった時点で、データ転送を希望するノードがバス使用権を要求できると判定し、したがって、上記図１１で説明したようなバスアービトレーションが実行されることになる。
【０１３０】
バスアービトレーションによりバスの使用が許可されると、データ転送がパケットされる。このデータを受信したノードは、”ａｓｋ ｇａｐ”という短いギャップの後、受信確認用の返送コード”ａｃｋ”を返して応答する（又は、応答パケットを送る）ことによってデータ転送が完了する。この”ａｃｋ”は、４ビットの情報と４ビットのチェックサムからなり、成功、ビジー状態、又は、ペンディング状態を示す情報を含み、すぐにデータ送信元のノードに返される情報である。
【０１３１】
図１３は、アシンクロナス転送用のパケットフォーマットを示す図である。
パケットには、データ部及び誤り訂正用のデータＣＲＣの他にヘッダ部があり、そのヘッダ部には、目的ノードＩＤ、ソースノードＩＤ、転送データ長や各種コード等が書き込まれている。
ここで、アシンクロナス転送は、自己ノードから相手ノードへの１対１の通信である。したがって、転送元ノードから送り出されたパケットは、ネットワーク中の各ノードに行き渡るが、各ノードは自分宛てのパケット以外は無視するので、宛先に指定されたノードのみがそのパケットを受け取ることになる。
【０１３２】
［Isochronous 転送］
【０１３３】
１３９４シリアルバスの最大の特徴であるともいえるこのアイソクロナス転送は、特に、ＡＶデータ等のリアルタイム転送を必要とするマルチメディアデータの転送に適している。
また、アシンクロナス転送が１対１の転送であったのに対し、このアイソクロナス転送は、ブロードキャスト機能によって、１つの転送元ノードから他の全てのノードへ一様にデータを転送することができる。
【０１３４】
図１４は、アイソクロナス転送における時間的な遷移状態を示す図である。
アイソクロナス転送は、バス上で一定時間毎に実行される。この時間間隔は、アイソクロナスサイクルと呼ばれ、１２５μS としてる。この各サイクルの開始時間を示し、各ノードの時間調整を行なう役割を担っているのが、サイクル・スタート・パケット（ＣＳＰ）である。ＣＳＰを送信するのは、サイクル・マスタと呼ばれるノードであり、１つ前のサイクル内の転送終了し、所定のアイドル期間（サブアクションギャップ）を経た後、本サイクルの開始を告げるＣＳＰを送信する。すなわち、ＣＳＰの送信される時間間隔が１２５μS となる。
【０１３５】
また、上記図１４に”チャネルＡ”、”チャネルＢ”、及び”チャネルＣ”と示すように、１つの同期サイクル内において、複数種のパケットにチャネルＩＤを各々与えることによって、それらのパケットを区別して転送することができる。これによって、複数のノード間で、略同時に、リアルタイム転送が可能となり、また、受信ノードは、自分が望むチャネルＩＤのデータのみを受信すればよい。
尚、チャネルＩＤは、受信ノードのアドレス等を表すものではなく、データに対する論理的な番号を与えているに過ぎないものである。したがって、送信されたパケットは、１つの送信元ノードから他の全てのノードに行き渡る、すなわちブロードキャストされることになる。
【０１３６】
アイソクロナス転送では、そのパケット送信に先立って、上述のアシンクロナス転送と同様にバスアービトレーションが行われる。しかしながら、アイソクロナス転送はアシンクロナス転送のように１対１の通信ではないため、上記図１４に示すように、アイソクロナス転送には、受信確認用の返送コードである”ａｓｋ”は存在しない。
また、上記図１４に示す”ｉｓｏ ｇａｐ”（アイソクロナスギャップ）は、アイソクロナス転送を行なう前にバスがアイドル状態であることを認識するために必要なアイドル期間を表している。この所定のアイドル期間を経過すると、アイソクロナス転送を行ないたいノードに対するバスのアービトレーションが行なわれる。
【０１３７】
図１５は、アイソクロナス転送用のパケットフォーマットを示す図である。
各チャネルに分けられた各種のパケットには、各々データ部及び誤り訂正用のデータＣＲＣの他にヘッダ部があり、そのヘッダ部には、転送データ長やチャネルＮｏ．、その他各種コード及び誤り訂正用のヘッダＣＲＣ等が書き込まれている。
【０１３８】
［バス・サイクル］
【０１３９】
実際に、１３９４シリアルバスにおいては、アイソクロナス転送とアシンクロナス転送が混在できる。その時のバス上の転送状態の時間的な遷移の様子を、図１６に示す。
アイソクロナス転送は、アシンクロナス転送より優先して実行される。その理由は、ＣＳＰの後、アシンクロナス転送を起動するために必要なアイドル期間のギャップ長（”subaction gap ”サブアクションギャップ）よりも短いギャップ長（”ack gap ”アイソクロナスギャップ）で、アイソクロナス転送を起動できるからである。したがって、アシンクロナス転送よりアイソクロナス転送が、優先して実行されることとなる。
【０１４０】
上記図１６示す一般的なバスサイクルでは、サイクル＃ｍのスタート時にＣＳＰがサイクル・マスタから各ノードに転送される。このＣＳＰによって、各ノードの動作の同期がとられ、所定のアイドル期間（アイソクロナスギャップ）を待ってからアイソクロナス転送を行おうとするノードは、バスアービトレーションに参加して、パケット転送に入る。上記図１６では、”チャネルｅ”、”チャネルｓ”、”チャネルｋ”が順にアイソクロナス転送されている。
このバスアービトレーションからパケット転送までの動作を、与えられているチャネル分繰り返し行なった後、サイクル＃ｍにおけるアイソクロナス転送が全て終了すると、アシンクロナス転送を行うことができるようになる。
【０１４１】
すなわち、アイドル時間が、アシンクロナス転送が可能なサブアクションギャップに達することによって、アシンクロナス転送を行いたいノードは、バスアービトレーションに参加する。
尚、アシンクロナス転送が行えるのは、アイソクロナス転送終了後から、次のＣＳＰを転送すべき時間（cycle synch ）までの間に、アシンクロナス転送を起動するためのサブアクションギャップが得られた場合に限られる。
【０１４２】
上記図１６のサイクル＃ｍでは、３つのチャネル分のアイソクロナス転送の後、アシンクロナス転送により、”ａｃｋ”を含む２つのパケット（パケット１、パケット２）転送されている。この２つのパケット転送後は、サイクル＃（ｍ＋１）をスタートすべき時間（cycle synch ）に至るので、サイクル＃ｍでの転送はこれ終了する。
このとき、非同期又は同期転送中に次のＣＳＰを送信すべき時間（cycle synch ）に至った場合、転送を無理に中断せず、その転送が終了した後に、アイドル期間を経て、次サイクルのＣＳＰを送信する。すなわち、１つのサイクルが１２５μS 以上続いた場合は、その延長分、次サイクルが基準の１２５μS より短縮される。このように、アイソクロナス・サイクルは、１２５μS を基準に超過或いは短縮し得るものである。
尚、アイソクロナス転送は、リアルタイム転送を維持するために、必要であれば毎サイクル実行され、アシンクロナス転送は、サイクル時間が短縮されたことによって、次以降のサイクルに延期されることもある。こういった遅延情報も、サイクル・マスタによって管理される。
【０１４３】
（第１の実施の形態）
【０１４４】
図１７は、１３９４シリアルバスのインターフェースをＬＡＮでよく用いられるＯＳＩモデルの各層と対比させた図である。
ＯＳＩモデルの物理層（Physical）１とデータリンク層（Datalink）２が、１３９４シリアルバスのインターフェースの下位層（IEEE1394 Layers ）４であるフィジカル層８１１及びリンク層８１２（上記図２）に該当する。下位層４の上に存在する１３９４シリアルバスのインターフェースにおけるトランスポートプロトコル層（Transprt Protocols）５とプレゼンテーション層（Presentation）６は、ＯＳＩモデルのネットワーク層（Network ）、トランスポート層（Transport ）、セッション層（Session ）、及びプレゼンテーション層（Presentation）を含む上位層３に該当する。
また、本発明の特徴であるＬＯＧＩＮプロトコル（Login Protocol）（初期プロトコル）７は、１３９４シリアルバスのインターフェースの下位層４とトランスポートプロトコル層５の間で動作するものである。
【０１４５】
上記図１７に示す例１（Example 1 ）では、プリンタ等の周辺機器用のシリアルバスプロトコル（ＳＢＰ−２）（デバイス固有のプロトコル）８に準拠したデバイスに対して、ＬＯＧＩＮプロトコル７を持たせる。これにより、相手のデバイスに対してＳＢＰ−２に準拠したプロトコルを使って、データのやり取りを行いたいことを通知することができる。
また、上記図１７に示す例２（Example 2 ）では、１３９４シリアルバスのインターフェース上で特化されたデバイスプロトコル（Device Specific Protocol）（デバイス固有のプロトコル）９に対して、ＬＯＧＩＮプロトコル７を持たせる。これにより、この例２においても、デバイスが互いに、互いのプロトコルをサポートしていることを判別することができる。
【０１４６】
図１８は、ＬＯＧＩＮプロトコルの基本動作を示す図であり、プリンタデバイスは、ホストデバイスからの印字タスク（Print task）１０を実行する際に、先ず、プリンタに用意されているプリンタプロトコルＡ、Ｂ、及びＣ（Protocol A、B 、C ）のうち、どれを選択して印字データのやり取りを行うかをＬＯＧＩＮプロトコル７による通信に基づいて決定し、その後、その決定したプリンタプロトコルに従って、印字データのやり取りを行う。
すなわち、いくつかのプリンタプロトコルをサポートしているデバイスは、ホストデバイスと接続する際に、先ず、ホストデバイスに用意されているトランスポートプロトコル５をＬＯＧＩＮプロトコル７によって判別し、ホストデバイスのトランスポートプロトコル５に合ったプリンタプロトコルを選択し、選択したプリンタプロトコルに従った印字データやコマンドのやり取りを行うことで、印字タスク１０の処理を行う。
【０１４７】
図１９は、１３９４シリアルバスにおける接続形態を示す図であり、ここでは、複数のプリンタプロトコルに対応したプリンタ１１に対してＬＯＧＩＮプロトコル７を実装したデバイス（ＰＣ１２、スキャナ１３、ＶＣＲ１４等）が接続された状態を示している。
プリンタ１１は、ＬＯＧＩＮプロトコル７により判別した、接続を要求する相手デバイスのトランスポートプロトコル５に応じてプリンタプロトコルを切り替えることにより、各デバイス１２〜１４からの印字タスクを問題なく処理することができる。
【０１４８】
図２０は、ログイン動作の流れを示す図である。
第１ステップ（STEP 1）において、
・ホストデバイス（HOST）は、ターゲットデバイス（DEVICE、この場合マルチプロトコルプリンタ）をロックする。
・ターゲットデバイスは、ホストデバイスのケーパビリティ（トランスポートプロトコル等を含む）を調べる。このケーパビリティは、後述するレジスタ５０３に格納される。
・ターゲットデバイスは、ホストデバイスのケーパビリティ（トランスポートプロトコル等を含む）をセットする。
第２ステップ（STEP 2）において、
・第１ステップで決定されたプロトコルで、プリントデータを通信する。
第３ステップ（STEP 3）において、
・ホストデバイスは、ターゲットデバイスとのコネクションを切断する。
【０１４９】
図２１は、ＬＯＧＩＮプロトコルのためにターゲットデバイスであるプリンタが備える１３９４シリアルバスのＣＳＲにおいて、ロックレジスタ（lock）５０１、プロトコルレジスタ（protocol）５０２、ケーパビリティレジスタ（capability）５０３を示した図である。
これらのレジスタは、１３９４シリアルバスのアドレス空間における初期ユニット空間の定められたアドレスに配置される。すなわち、上記図３に示したように、機器に与えられたアドレス幅４８ビットのうち、最初の２０ビットにおける0xFFFFF がレジスタ空間と呼ばれ、その最初の５１２バイトにＣＳＲアーキテクチャのコアになるレジスタ（ＣＳＲコア）が配置されている。
尚、このレジスタ空間には、バスに接続された機器間で共通な情報が置かれる。また、0 〜0xFFFFD はメモリ空間、0xFFFFE はプライベート空間と、各々呼ばれ、プライベート空間は、機器内で自由に利用できるアドレスであり、各機器間のコミュニケーションに使われる。
【０１５０】
ロックレジスタ５０１は、リソースのロック状態（専有状態）を示し、”０”でログイン可能な状態を表し、”０”以外でロック状態で既にログインされていることを表す。
プロトコルレジスタ５０２には、実際に通信に使用するプロトコルが書き込まれる。したがって、このプロトコルレジスタ５０２は、現在設定されているプロトコルを示し、設定されたプロトコルに対応するケーパビリティレジスタ５０３のビットに相当するビットの値が”１”になる。
ケーパビリティレジスタ５０３には、各々のデバイスが対応可能なプロトコルを示す情報が格納され、各ビットの各々が独立に対応可能なデータトランスポートプロトコルを示す。すなわち、ケーパビリティレジスタ５０３は、複数ビットを有し、そのビット毎で設定可能なトランスポートプロトコルを各々独立に示す。例えば、”１”のビットに対応するプロトコルは設定可能であることを表し、”０”のビットに対応するプロトコルは設定不可能であることを表す。
【０１５１】
図２２は、１３９４シリアルバスにより構成されたネットワーク（１３９４ネットワーク）におけるプリンタマップのフォーマットを示した図である。
このプリンタマップには、応答を返してきたプリンタのユニークＩＤ（Unique ID ）、ノードＩＤ（Node ID ）、ステータス（Status）、及びケーパビリティ（Capability）等の情報が保存される。このとき、”ノードＩＤ”は、図２３に示すようなＣＳＲアーキテクチャにおけるフォーマットに従って保存される。
尚、ここでの”ステータス（Status）”は、例えば、上記図２１に示したプロトコルレジスタ５０２の内容を示し、”ケーパビリティ（Capability）”は、例えば、上記図２１に示したケーパビリティレジスタ５０３の内容を示す。
【０１５２】
図２４は、上記図２２に示したようなプリンタマップの作成コマンドのフィーマットを示した図である。このコマンドは、非同期パケットのライトトランザクションにより、ターゲットデバイスに対して送信される。また、このコマンドは、１３９４シリアルバスのアドレス空間におけるユニット空間の定められたアドレスに配置される。
【０１５３】
図２５は、複数のプロトコルに対応可能なプリンタが１３９４シリアルバスに接続されて構成されるネットワークにおいて、ホストデバイスでのプリンタマップ作成処理を示したフローチャートである。
【０１５４】
ここで、ネットワーク上には、通常、様々なデバイスが接続されている。このような状況下で、イニシエータ（ホストデバイス）がターゲットデバイスであるプリンタとの通信を試みるとき、どのデバイスが目的とするプリンタに対応しているかを認識する必要がある。また、適切なプリンタ出力を得るためには、それに対応したプリンタの物理的な場所、その能力、その余力等を予め認識しておくと非常に都合がよい。
【０１５５】
そこで、ここでは、同一ネットワークに存在する各プリンタを予め調査する。
具体的には、ホストデバイスは、予め、ネットワーク上に存在する各プリンタを調査することで（第１の調査処理）、各々の物理的な場所、能力、及び余力等の情報（以下、トポロジー／能力情報とも言う）を得て、上記図２２に示したようなプリンタマップを作成する。そして、そのプリンタマップに基づいて、目的とするプリンタを選択する。
【０１５６】
プリンタマップの作成については、上記図２５に示すように、先ず、ホストデバイスは、上記図２４に示したようなプリンタマップ作成のためのコマンド（作成コマンド）を、ブロードキャストすることで（ステップＳ３００１）、ネットワーク上に存在する全てのデバイスに送信する。
そして、ホストデバイスは、各デバイスからの応答、すなわちネットワーク上に存在する各プリンタからの応答（応答コマンド）を待つ（ステップＳ３００２）。
【０１５７】
次に、ホストデバイスは、各プリンタからの応答コマンドを受信すると、その応答コマンドを返してきたプリンタのプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３００３）。これにより、ホストデバイスは、そのプリンタの能力や状態等を認識する。
【０１５８】
そして、ホストデバイスは、ステップＳ３００３で得た情報を基に、現在のネットワーク上のプリンタについてのプリンタマップを作成して（ステップＳ３００４）、本処理を終了する。
【０１５９】
図２６は、上述したホストデバイスから作成コマンドが与えられるターゲットデバイス、特に、プリンタでの処理を示すフローチャートである。
上記図２６において、先ず、プリンタは、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３１０１）。
具体的には、例えば、現在の自プリンタの能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、プリンタ内部でのステータス及びケーパビリティの変化は、このステップＳ３１０１でのステータス及びケーパビリティの提示にも反映することになる。
【０１６０】
次に、プリンタは、ホストデバイスからの作成コマンドを待つ（ステップＳ３１０２）。
そして、プリンタは、ホストデバイス側からの作成コマンドを受信すると、その作成コマンドに対する応答コマンドをホストデバイスへ返送する（ステップＳ３１０３）。
【０１６１】
図２７は、ホストデバイスにおけるログイン処理を示すフローチャートである。
ここで、ホストデバイスがターゲットデバイス（ここでは、プリンタ）へのログインを開始するためには、上記図２５に示したプリンタマップ作成処理（ステップＳ６００）の後、リード又はロックトランザクションによって、ログインしようとするプリンタのロックレジスタ５０１、プロトコルレジスタ５０２、及びケーパビリティレジスタ５０３のデータを確認する必要がある。
【０１６２】
そこで、先ず、ホストデバイスは、プリンタのケーパビリティレジスタ５０３のビット毎のデータから、自分が通信に用いようとしているプロトコルをプリンタがサポートしているかを確認する（ステップ６０１）。このとき、もし、プリンタが自分のプロトコルをサポートしていない場合には、そのプリンタへのログインを中止とする。
【０１６３】
次に、ホストデバイスは、プリンタのロックレジスタ５０１のデータから、現在ログイン可能であるかを確認する（ステップ６０２）。すなわち、プリンタのロックレジスタ５０１のデータが”０”以外であれば、他のデバイスがプリンタへログイン中であると見なし、ログイン中止（Login N.G.）とし、本処理を終了する。一方、プリンタのログインレジスタ５０１のデータが”０”であれば、現在ログイン可能（Login O.K.）と見なし、次のステップに進む。
尚、ステップ６０１において、プリンタがホストデバイスのプロトコルをサポートしておらず、ログインを中止とされた場合、このステップ６０２の判定により、本処理終了となる。
【０１６４】
ステップ６０２の判定により、プリンタへのログインが可能であった場合、ホストデバイスは、ロックトランザクションによって、プリンタのロックレジスタ５０１に”１”を書き込み、ログインを設定する（ステップ６０３）。この状態でプリンタはロックされたことになり、他のデバイスからの制御は不可能となり、また、レジスタの変更も不可能となる。
【０１６５】
上述のようにして、プリンタのリソースがロックされた状態となると、次に、ホストデバイスは、プロトコルの設定を行なう。
ここで、プリンタは、複数のプリンタプロトコルをサポートするため、プリントデータを受け取る前に、ホストデバイスが使用できるプロトコルを知る必要がある。
そこで、ホストデバイスは、ライトトランザクションによって、プリンタのプロトコルレジスタ５０２の相当するビットを設定することで、これから使用するプロトコルをプリンタに通知する（ステップ６０４）。
【０１６６】
この時点で、ホストデバイスが通信に用いるプロトコルがプリンタに通知され、且つプリンタがロック状態であるため、現在、プリンタでバスにログインしているホストデバイスがデータ（ここでは、プリントデータ）の送信を行なう（ステップ６０５）。
【０１６７】
プリントデータの送信が終了すると、ホストデバイスは、プリンタのロックレジスタ５０１、プロトコルレジスタ５０２、及びケーパビリティレジスタ５０３をクリアすることにより、プリンタからログアウトする（ステップ６０６）。
【０１６８】
図２８は、ターゲットデバイスであるプリンタのログイン処理を示す図である。
先ず、プリンタ側では、図２６に示したプリンタマップ作成処理が実行される（ステップＳ７００）。
ここで、通常、ホストデバイスからログインされるのを待つ状態にあるホストデバイスからのプリントリクエストは、プリンタのロックレジスタ５０１、プロトコルレジスタ５０２、及びケーパビリティレジスタ５０３の読み取りにより開始されるため、プリンタは、これらのレジスタを常に他のデバイスから読み出し可能の状態にしておく。この状態により、今、プリントアウトを実行しようとするホストデバイスからプリンタがロックされたとする（ステップＳ７０１）。
【０１６９】
次に、プリンタは、ホストデバイスから使用プロトコルが通知されるのを待つ（ステップＳ７０２）。このように、プリンタがロック状態になってから使用プロトコルの通知を待つのは、ログインの途中で他のデバイスからのリクエストにより、プロトコルレジスタ５０２の内容が書き換えられないようにするためである。
【０１７０】
そして、ホストデバイスからプリンタへ使用プロトコルの通知があると（ステップＳ７０３）、プリンタは、自分のプロトコルを通知された使用プロトコルに切り換えて、ホストデバイスのプロトコルに合わせた通信を行う（ステップＳ７０４〜Ｓ７０９）。
【０１７１】
通信が終了したら、プリンタは、ロックレジスタ５０１及びケーパビリティレジスタ５０３がクリアされたのを確認し（ステップＳ７１０）、ログインを待つ状態（ステップ７０１）に戻る。
【０１７２】
（第２の実施の形態）
【０１７３】
上述した第１の実施の形態では、上記図２５及び図２６を用いて説明したように、１３９４シリアルバスに複数のプリンタを含む各デバイスが接続されてなるネットワーク上において、ホストデバイスが各プリンタについてのプリンタマップを作成し、そのプリンタマップに基づいて目的のプリンタを選択するようにしたが、本実施の形態では、ホストデバイスとプリンタが共に複数のプロトコルをサポートしており、さらにそのようなプリンタが複数存在する場合、ホストデバイスが各プリンタの使用可能なプロトコルを調べて多数決を取り、最も多くサポートされているプロトコルを決定する。
このように、多くのプロトコルが使用可能な状況下で多数決を取るように構成することで、実際に使用するプロトコルの種類を削減することを可能とし、ホストデバイスのプロトコルスイッチによる負荷を下げることを可能とする。
【０１７４】
尚、本実施の形態は、上記図２５及び図２６に示した処理以外については第１の実施の形態と同様であるため、その詳細な説明は省略し、ここでは、第１の実施の形態と異なる点についてのみ具体的に説明する。
【０１７５】
具体的には、まず、１３９４シリアルバスを用いたネットワーク上において、ホストデバイス（イニシエータ）とターゲットデバイス（プリンタ）が共に複数のプロトコルをサポートしており、さらにそのようなターゲットデバイスが同一ネットワークに複数接続されている場合、当然、ホストデバイスとターゲットデバイスは同一プロトコルを用いる必要がある。
そこで、ここでは、今、どのプロトコルを用いるかを決定するために、ホストデバイスが各ターゲットデバイスの使用可能なプロトコルを調べ、その中で多数決を取り、最も多くサポートされているプロトコルを決定する。
【０１７６】
このため、本実施の形態では、第１の実施の形態における上記図２５及び図２６の処理の代わりに、図２９及び図３０に示す処理を実行する。
尚、上記図２９は、ホストデバイスのプリンタマップ作成処理（相対多数プロトコル決定プリンタマップ処理）を示すフローチャートであり、ホストデバイスのログイン処理（上記図２７：ステップＳ６００）で実行される。また、上記図３０は、この処理時におけるプリンタの処理を示すフローチャートであり、プリンタのログイン処理（上記図２９：ステップＳ７００）で実行される。
【０１７７】
すなわち、上記図２９において、先ず、ホストデバイスは、上記図２２に示したプリンタマップを作成するために、その作成コマンドをブロードキャストすることで、ネットワーク上に存在する全てのデバイスに送信する（ステップＳ３２０１）。
そして、ホストデバイスは、各デバイスからの応答、すなわちネットワーク上に存在する各プリンタからの応答（応答コマンド）を待つ（ステップＳ３２０２）。
【０１７８】
次に、ホストデバイスは、各プリンタからの応答コマンドを受信すると、その応答コマンドを返してきたプリンタのプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３２０３）。これにより、ホストデバイスは、そのプリンタの能力や状態等を認識する。
【０１７９】
次に、ホストデバイスは、ステップＳ３２０３で得た情報を基に、現在のネットワーク上のプリンタについてのプリンタマップを作成する（ステップＳ３２０４）。
【０１８０】
次に、ホストデバイスは、ステップＳ３２０４で作成したプリンタマップより、現在ネットワークに接続されているプリンタ（複数のプロトコルをサポートしているマルチプロトコルプリンタ）の使用可能なプロトコルを調べ、それらのプロトコルの中から、最も多くサポートされているプロトコルを選択する（ステップＳ３２０５）。
【０１８１】
そして、ホストデバイスは、ステップＳ３２０５で選択したプロトコルを、プロトコル通知コマンドとして各プリンタに通知して（ステップＳ３２０６）、本処理を終了する。
【０１８２】
一方、プリンタは、上記図３０に示すように、先ず、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３３０１）。
具体的には、例えば、現在の自プリンタの能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、プリンタ内部でのステータス及びケーパビリティの変化は、このステップＳ３３０１でのステータス及びケーパビリティを提示にも反映することになる。
【０１８３】
次に、プリンタは、ホストデバイスからの作成コマンドを待つ（ステップＳ３３０２）。
そして、プリンタは、ホストデバイスからの作成コマンドを受信すると、そのコマンドに対する応答コマンドをホストデバイスへ返送する（ステップＳ３３０３）。
【０１８４】
次に、プリンタは、ホストデバイスからのプロトコル通知コマンドを待つ（ステップＳ３３０４）。
そして、プリンタは、ホストデバイスからのプロトコル通知コマンドを受信すると、そのコマンドにより示されるプロトコルに自分のプロトコルを切り換える（ステップＳ３３０５）。
【０１８５】
（第３の実施の形態）
【０１８６】
図３１は、本実施の形態における動作を示した図であり、上記図１８に示した第１の実施の形態と比較すると、ＬＯＧＩＮプロトコル７を実装していないプロトコルＤを持つデバイスについても対応している点が特徴である。
すなわち、ＬＯＧＩＮプロトコル７を持つデバイスだけでなく、既存のプロトコルＤ（例えば、ＡＶ／Ｃプロトコル）にのみ対応しているデバイスに対しても印字動作の保証を行う為に、プリンタに、ＬＯＧＩＮプロトコル７を持たないデバイスに対応するプリンタプロトコルを追加する。
【０１８７】
この動作について説明すると、接続の初めに行われるプリントリクエストによってホストデバイスがＬＯＧＩＮプロトコル７に対応していないことをプリンタが認識した場合、プリンタは、プロトコルＤを使ってホストデバイスとの通信を試み、通信が成立した場合は、そのプロトコルＤに従って印字タスク１０を実行する。
【０１８８】
図３２は、本実施の形態と、ＯＳＩモデルとを対比させた図であり、例３（Example 3 ）では、ＬＯＧＩＮプロトコル７の実装されていない現行のＡＶ／Ｃプロトコルに準拠したＡＶデバイス１５をモデルとしている。例４（Example 4 ）では、ＬＯＧＩＮプロトコル７が実装されていないスキャナ用の非標準プロトコルが実装されているスキャナ１６をモデルとしている。
すなわち、ＬＯＧＩＮプロトコル７を実装していないプロトコルを持つデバイスについても、そのデバイスが持つプロトコルにプリンタが対応することができれば、そのプリンタを利用することができるデバイスの種類を広げることができる。
【０１８９】
（第４の実施の形態）
【０１９０】
上述した第１の実施の形態では、上記図２５及び図２６を用いて説明したように、１３９４シリアルバスに複数のプリンタを含む各デバイスが接続されてなるネットワーク上において、ホストデバイス（イニシエータ）がターゲットデバイスである各プリンタについてのプリンタマップを作成し、そのプリンタマップに基づいて目的のプリンタを選択するようにしたが、本実施の形態では、プリンタをネットワーク上の１出力デバイス（ホストデバイス）とし、ディジタルビデオ、ディジタルカメラ、スキャナ、モニタ、コンピュータ等をイメージ入力装置（ターゲットデバイス）とし、プリンタがイメージ入力装置にログインして画像情報を取得するために、プリンタがイメージ入力装置についてのマップ（上述のプリンタマップに相当するマップ）を作成し、そのマップに基づいて目的のイメージ入力装置を選択する。
【０１９１】
尚、本実施の形態は、上記図２５及び図２６に示した処理以外については第１の実施の形態と同様であるため、その詳細な説明は省略し、ここでは、第１の実施の形態と異なる点についてのみ具体的に説明する。
【０１９２】
まず、上述したように、ネットワーク上には、通常、様々なデバイスが接続されている。このような状況下で、プリンタ（イニシエータ）がターゲットデバイスであるイメージ入力装置との通信を試みるとき、どのデバイスが目的とするイメージ入力装置に対応しているかを認識する必要がある。また、適切なプリンタ出力を得るためには、それに対応したイメージ入力装置の物理的な場所、その能力、その余力等を予め認識しておくと非常に都合がよい。
【０１９３】
そこで、ここでは、同一ネットワークに存在する各イメージ入力装置を予め調査する。
具体的には、プリンタは、予め、ネットワーク上に存在する各イメージ入力装置を調査することで（第２の調査処理）、各々の物理的な場所、能力、及び余力等の情報（トポロジー／能力情報）を得て、上記図２２に示したようなプリンタマップに相当するマップを作成する。そして、そのマップに基づいて、目的とするイメージ入力装置を選択する。
【０１９４】
イメージ入力装置についてのマップの作成については、図３３に示すように、先ず、プリンタは、マップ作成のためのコマンド（作成コマンド）を、ブロードキャストすることで（ステップＳ３４０１）、ネットワーク上に存在する全てのデバイスに送信する。
そして、プリンタは、各デバイスからの応答、すなわちネットワーク上に存在する各イメージ入力装置からの応答（応答コマンド）を待つ（ステップＳ３４０２）。
【０１９５】
次に、プリンタは、各イメージ入力装置からの応答コマンドを受信すると、その応答コマンドを返してきたイメージ入力装置のプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３４０３）。これにより、プリンタは、そのイメージ入力装置の能力や状態等を認識する。
【０１９６】
そして、プリンタは、ステップＳ３４０３で得た情報を基に、現在のネットワーク上のイメージ入力装置についてのマップを作成して（ステップＳ３４０４）、本処理を終了する。
【０１９７】
図３４は、上述したプリンタから作成コマンドが与えられるターゲットデバイス、すなわちイメージ入力装置での処理を示すフローチャートである。
上記図３４において、先ず、イメージ入力装置は、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３５０１）。
具体的には、例えば、現在の自装置の能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、装置内部でのステータス及びケーパビリティの変化は、このステップＳ３５０１でのステータス及びケーパビリティの提示にも反映することになる。
【０１９８】
次に、イメージ入力装置は、プリンタからの作成コマンドを待つ（ステップＳ３５０２）。
そして、イメージ入力装置は、プリンタからの作成コマンドを受信すると、その作成コマンドに対する応答コマンドをプリンタへ返送して（ステップＳ３５０３）、本処理を終了する。
【０１９９】
上述のようにして、プリンタにて、イメージ入力装置についてのマップが作成された後、上記図２７及び図２８に示したようなログイン処理が実行される。この結果、プリンタは、ネットワーク上に存在する各イメージ入力装置から選択した適切なイメージ入力装置からの画像情報をプリント出力することになる。
【０２００】
尚、上述した各実施の形態では、ＩＥＥＥ１９３４シリアルバスを用いてネットワークを構成するものとしたが、本発明はこれに限定されるものではなく、例えば、Universal Serial Bus（ＵＳＢ）と呼ばれるシリアルインターフェース等、任意のシリアルインターフェースを用いて構成されるネットワークにも適用することができる。
【０２０１】
また、ホストデバイスとしては、例えば、コンピュータ、ディジタルカメラ、スキャナ、ＤＶＤ、Ｓｅｔ−ｔｏｐ−Ｂｏｘ、ディジタルテレビ、コンファレンスカメラ、ディジタルビデオ、及びこれらを含む複合機等を用いることができる。一方、ターゲットデバイスとしては、モニタ、コンピュータ、外部記憶装置、Ｓｅｔ−ｔｏｐ−Ｂｏｘ、プリンタ及びこれらを含む複合機等を用いることができる。
【０２０２】
また、上記図２７のステップＳ６００、上記図２８のステップＳ７００、及び上記図２９のステップＳ３２０４で実行されるプリンタマップ作成処理や、上記図３３のステップＳ３４０４で実行されるイメージ入力装置についてのマップ作成処理においては、トポロジ接続状態が上記図９のように調査されマップが作成される、かかるトポロジ接続状態が判定されることによって、単なる多数決ではなく、トポロジ接続状態を加味して実際に使用するプロトコルを決定することができる。
【０２０３】
また、上述した実施の形態では、ネットワーク上の各デバイスを、画像データを出力或いは入力する機器としたが、これに限らず、例えば、ネットワーク上のデバイスのうち任意のデバイスを、画像データの出力或いは入力することなく、単にネットワーク上の状態を検出し、他の機器とネットワークの関係を調査する機能を有する機器としてもよい。
【０２０４】
また、本発明は、上記図１９に示すような複数の機器から構成されるシステムに適用しても、１つの機器からなる装置内のデータ処理方法に適用してもよい。
【０２０５】
また、本発明の目的は、上述した各実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、達成されることは言うまでもない。
【０２０６】
この場合、記憶媒体から読み出されたプログラムコード自体が各実施の形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することとなる。
【０２０７】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０２０８】
また、コンピュータが読みだしたプログラムコードを実行することにより、各実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって各実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２０９】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって各実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２１０】
【発明の効果】
以上説明したように本発明によれば、ホストデバイスとターゲットデバイス間でデータ通信を行う際の通信プロトコルが、そのターゲットデバイスによって限定されることがない、拡張性の高いデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することができる。特に、複数種類のターゲットデバイス（プリンタやイメージ入力装置等）のプロトコルに対応可能であるので、拡張性が極めて高い。
【０２１１】
また、同一ネットワークに接続されたターゲットデバイスを調査することで、目的とするターゲットデバイスを選択することができるため、最適な出力（プリンタ出力等）を得ることができる。特に、プリンタ出力するのに適切なプリンタ（第１の種類のターゲットデバイス）を選択することができると共に、該プリンタに適切なイメージ入力装置（第１の種類のデバイスをホストデバイスとする第２の種類のターゲットデバイス）も選択することができるため、極めて良好なプリンタ出力を得ることができる。
【０２１２】
また、多くのプロトコルが使用可能な状況下であっても、それらのプロトコルのうちターゲットデバイスから最も多くサポートされているプロトコルを決定することで、実際に使用するプロトコルの種類を削減することができるため、ホストデバイスのプロトコルに切り替えによる負荷を下げることができる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４シリアルインターフェースを用いて構成されるネットワークシステムの一例を示すブロック図である。
【図２】ＩＥＥＥ１３９４シリアルインターフェースの構成を説明するための図である。
【図３】ＩＥＥＥ１３９４シリアルインターフェースにおけるアドレス空間を説明するための図である。
【図４】ＩＥＥＥ１３９４シリアルインターフェース用のケーブルの断面を説明するための図である。
【図５】ＤＳ−Ｌｉｎｋ方式を説明するための図である。
【図６】ＩＥＥＥ１３９４シリアルインターフェースにおけるネットワーク構築手順を説明するためのフローチャートである。
【図７】ルートの決定方法を説明するためのフローチャートである。
【図８】親子関係決定から全てのノードＩＤの設定までの手順を説明するためのフローチャートである。
【図９】ネットワークの一例を説明するための図である。
【図１０】バスアービトレーションを説明するための図である。
【図１１】アービトレーションの手順を説明するためのフローチャートである。
【図１２】アシンクロナス転送における時間的な遷移状態を説明するための図である。
【図１３】アシンクロナス転送用のパケットフォーマットを説明するための図である。
【図１４】アイソクロナス転送における時間的な遷移状態を説明するための図である。
【図１５】アイソクロナス転送用のパケットフォーマットを説明するための図である。
【図１６】アシンクロナス転送とアイソクロナス転送が混在する場合のバス上の転送状態の時間的な遷移の様子を説明するための図である。
【図１７】ＩＥＥＥ１３９４シリアルインターフェースとＯＳＩモデルの対比を説明するための図である。
【図１８】ＬＯＧＩＮプロトコルの基本動作を説明するための図である。
【図１９】第１の実施の形態において、ＩＥＥＥ１３９４シリアルインターフェースにおける接続形態を説明するための図である。
【図２０】ログイン動作の流れを説明するための図である。
【図２１】ＬＯＧＩＮプロトコルのためにプリンタが備えるＣＳＲを説明するための図である。
【図２２】ホストデバイスで作成されるプリンタマップを説明するための図である。
【図２３】ＣＲＣアーキテクチャにおけるノードＩＤを説明するための図である。
【図２４】プリンタマップ作成のためのコマンドフォーマットを説明するための図である。
【図２５】ホストデバイスで実行されるプリンタマップ作成処理を説明するためのフローチャートである。
【図２６】上記プリンタマップ作成処理時にプリンタで実行される処理を説明するためのフローチャートである。
【図２７】ホストデバイスにおけるＬＯＧＩＮ処理を説明するためのフローチャートである。
【図２８】プリンタ（ターゲットデバイス）におけるＬＯＧＩＮ処理を説明するためのフローチャートである。
【図２９】第２の実施の形態において、ホストデバイスで実行されるプリンタマップ作成処理を説明するためのフローチャートである。
【図３０】上記プリンタマップ作成処理時にプリンタで実行される処理を説明するためのフローチャートである。
【図３１】第３の実施の形態において、システム動作を説明するための図である。
【図３２】ＯＳＩモデルとの対比を説明するための図である。
【図３３】第４の実施の形態において、プリンタ（ホストデバイス）で実行されるイメージ入力装置についてのマップ作成処理を説明するためのフローチャートである。
【図３４】上記マップ作成処理時にイメージ入力装置で実行される処理を説明するためのフローチャートである。
【符号の説明】
１ ＯＳＩモデルの物理層
２ データリンク層
３ 上位層
４ 上位層
５ トランスポートプロトコル層
６ プレゼンテーション層
７ ＬＯＧＩＮプロトコル
８ シリアルバスプロトコル（ＳＢＰ−２）
９ デバイスプロトコル
１１ プリンタ
１２ ＰＣ
１３ スキャナ
１４ ＶＣＲ
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４−１９９５等のインターフェースを介して、複数種類のデバイスのプロトコルを切り換えるためのデータ処理方法、データ処理装置、プリンタ、及びそれらを実施するための処理ステップをコンピュータが読出可能に格納した記憶媒体に関するものである。
【０００２】
【従来の技術】
従来より、汎用インターフェースを介してプリンタにデータを送出するシステムとして、様々な種類のシステムが知られている。
例えば、ＳＣＳＩ（Small Computer System Interface ）や、セントロニクス等、一般に広く用いられるようになったデファクトスタンダードのインターフェースを用いて、コンピュータからプリンタにデータを出力する技術が知られている。
【０００３】
【発明が解決しようとする課題】
しかしながら、汎用インターフェースを介して、あるプリンタにプリントデータを転送するためのプリンタプロトコルは、そのプリンタの固有のものに限られていた。このように、従来では、ホストデバイスとターゲットデバイス間でデータ通信を行う際の通信プロトコルが、そのターゲットデバイスによって限定され、拡張性に欠ける、という問題が生じていた。
特に、様々な種類の機器を接続するインターフェース、例えば、ＩＥＥＥ１３９４のようなシリアルインターフェースを介してデータ転送する場合には、かかる拡張性に欠けるという問題点は解決すべき大きな課題である。
【０００４】
そこで、本発明は、上記の欠点を除去するために成されたもので、ホストデバイスとターゲットデバイス間でデータ通信を行う際の通信プロトコルが、そのターゲットデバイスによって限定されることがない、拡張性の高いデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
また、本発明は、ＩＥＥＥ１３９４規格等のシリアルインターフェースを用いた好適なデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
また、本発明は、コンピュータを介することなく、ホストデバイスからターゲットデバイスへ直接画像データ等を転送するのに好適なデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
また、本発明は、最適なプリンタ出力を得ることができるデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
また、本発明は、通信プロトコルの切り換えによる負荷を下げることができるデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することを目的とする。
【０００５】
【課題を解決するための手段】
本発明のデータ処理方法は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理方法であって、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記初期プロトコルに続いて、上記複数種類のデバイス固有のプロトコルを実行し、上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する第１の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、上記第１の種類のデバイスに対してデータを出力する第２の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含む。
【０００６】
本発明のデータ処理方法における他の態様は、上記第１及び第２の調査処理は各々、デバイスの機能を調査する第３の調査処理を含み、上記初期プロトコルは、上記第１の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第１の種類のデバイスに対する実行すべきプロトコルを決定する処理と、上記第２の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第２の種類のデバイスに対する実行すべきプロトコルを決定する処理とを含む。
【０００７】
また、本発明のデータ処理方法におけるその他の態様は、上記第１の調査処理は、デバイスとしてのプリンタの状態及び能力を含む情報を得る処理を含み、上記第２の調査処理は、デバイスとしてのイメージ入力装置の状態及び能力を含む情報を得る処理を含む。
【０００８】
また、本発明のデータ処理方法におけるその他の態様は、上記プリンタに固有のプロトコルの実行後に、プリントすべき画像データを上記イメージ入力装置から上記プリンタに対して伝送する。
【０００９】
また、本発明のデータ処理方法におけるその他の態様は、上記共通シリアルバスは、ＩＥＥＥ１３９４規格に適合したバス、またはＵＳＢ規格に適合したバスである。
【００１０】
また、本発明のデータ処理方法におけるその他の態様は、上記初期プロトコルは、ＯＳＩモデルのデータリンク層よりも上位の層で実行されるプロトコルである。
【００１１】
また、本発明のデータ処理方法におけるその他の態様は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理方法であって、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記共通シリアルバスによる同一ネットワーク上に存在し、上記複数種類のうちの少なくとも１種のデバイスに対してデータを出力する種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する調査処理を含む。
【００１３】
本発明のデータ処理装置は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理装置であって、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行する第１の実行手段と、上記初期プロトコルに続いて、上記複数種類のデバイス固有のプロトコルを実行する第２の実行手段とを備え、上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する第１の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、上記第１の種類のデバイスに対してデータを出力する第２の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含む。
【００１４】
本発明のデータ処理装置における他の態様は、上記第１及び第２の調査処理は各々、デバイスの機能を調査する第３の調査処理を含み、上記初期プロトコルは、上記第１の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第１の種類のデバイスに対する実行すべきプロトコルを決定する処理と、上記第２の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第２の種類のデバイスに対する実行すべきプロトコルを決定する処理とを含む。
【００１５】
また、本発明のデータ処理装置におけるその他の態様は、上記第１の調査処理は、デバイスとしてのプリンタの状態及び能力を含む情報を得る処理を含み、上記第２の調査処理は、デバイスとしてのイメージ入力装置の状態及び能力を含む情報を得る処理を含む。
【００１６】
また、本発明のデータ処理装置におけるその他の態様は、上記第２の実行手段は、上記プリンタに固有のプロトコルの実行後に、プリントすべき画像データを上記イメージ入力装置から上記プリンタに対して伝送する。
【００１７】
また、本発明のデータ処理装置におけるその他の態様は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理装置であって、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記共通シリアルバスによる同一ネットワーク上に存在し、上記複数種類のうちの少なくとも１種のデバイスに対してデータを出力する種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する調査処理手段を備える。
【００１９】
本発明のデータ処理装置は、共通シリアルバスを介して複数のプロトコルをホストデバイスに対応して切り換えるプリンタであって、上記プロトコルの種類に係わらない初期プロトコルを実行する実行手段と、上記初期プロトコルに続いて、自機器に固有のプロトコルを実行した後、印字データを受信する受信手段とを備え、上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する自機器についての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、自機器に対して画像データを出力するイメージ入力装置についての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含む。
【００２０】
本発明の記憶媒体は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるデータ処理ステップをコンピュータに実行させるためのプログラムを格納するコンピュータ読み取り可能な記憶媒体であって、上記データ処理ステップは、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行する第１の実行ステップと、上記初期プロトコルに続いて、上記複数種類のデバイスに固有のプロトコルを実行する第２の実行ステップとを含み、上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する第１の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、上記第１の種類のデバイスに対してデータを出力する第２の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含む。
【００２１】
また、本発明の記憶媒体におけるその他の態様は、共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるデータ処理ステップをコンピュータに実行させるためのプログラムを格納するコンピュータ読み取り可能な記憶媒体であって、上記データ処理ステップは、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記共通シリアルバスによる同一ネットワーク上に存在し、上記複数種類のうちの少なくとも１種のデバイスに対してデータを出力する種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する調査処理ステップを含む。
【００６１】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００６２】
以下に説明する第１及び第２の実施の形態では、各機器間を接続するディジタルインターフェース（Ｉ／Ｆ）として、例えば、ＩＥＥＥ１３９４−１９９５（High Performance Serial Bus 、以下、単に「１３９４シリアルバス」と言う）を用いているため、まず、１３９４シリアルバスについて予めその概要を説明する。
【００６３】
［１３９４シリアルバスの概要］
【００６４】
民生用デジタルビデオカムレコーダ（ＶＣＲ）やディジタルビデオディスク（ＤＶＤ）プレーヤの登場に伴なって、ビデオデータやオーディオデータ（以下、これらをまとめて「ＡＶデータ」と言う）等、リアルタイムで且つ高情報量のデータを転送する必要が生じている。このようなＡＶデータをリアルタイムでパーソナルコンピュータ（ＰＣ、以下、単に「パソコン」と言う）や、その他のディジタル機器に転送して取り込ませるには、高速なデータ転送が可能なインターフェースが必要となる。そういった観点から開発されたインタフェースが、この１３９４シリアルバスである。
【００６５】
図１は、１３９４シリアルバスを用いて構成されるネットワーク・システムの一例を示した図である。
このシステムは、機器Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈを備えており、Ａ−Ｂ間、Ａ−Ｃ間、Ｂ−Ｄ間、Ｄ−Ｅ間、Ｃ−Ｆ間、Ｃ−Ｇ間、及びＣ−Ｈ間が、各々１３９４シリアルバス用のツイスト・ペア・ケーブルで接続された構成としている。
これらの機器Ａ〜Ｈの一例としては、パソコン等のホストコンピュータ装置、及びコンピュータ周辺機器である。
尚、ここでのコンピュータ周辺機器としては、ディジタルＶＣＲ、ＤＶＤプレーヤ、ディジタルスチルカメラ、ハードディスクや光ディスク等の記録媒体を用いる記憶装置、ＣＲＴやＬＣＤ等のモニタ、チューナ、イメージスキャナ、フィルムスキャナ、プリンタ、ＭＯＤＥＭ、ターミナルアダプタ（ＴＡ）等、コンピュータ周辺機器の全てが対象になる。
【００６６】
各機器間の接続は、ディジーチェーン方式とノード分岐方式との混在が可能であり、自由度の高い接続を行うことができるようになされている。また、各機器は各自固有のＩＤを有し、互いにＩＤを認識し合うことによって、１３９４シリアルバスで接続された範囲にて、１つのネットワークを構成している。
例えば、各機器間を各々１本の１３９４シリアルバス用ケーブルでディジーチェーン接続するだけで、各々の機器が中継の役割を担うため、全体として１つのネットワークを構成することができる。
【００６７】
また、１３９４シリアルバスは、Plug and Play 機能に対応しており、ケーブルを機器に接続するだけで自動的に機器を認識し、接続状況を認識する機能を有している。
このため、上記図１のシステムにおいて、ネットワークから任意の機器が外されたり、或いは、新たに加えられたとき等には、自動的にバスがリセット、すなわちそれまでのネットワークの構成情報がリセットされ、新たなネットワークが再構築される。このような機能によって、その時々のネットワークの構成を常時設定、認識することができる。
【００６８】
１３９４シリアルバスのデータ転送速度は、１００／２００／４００Ｍｂｐｓが定義されており、上位の転送速度を持つ機器が下位の転送速度をサポートすることで、互換性を保つようになされている。
【００６９】
データ転送モードとしては、コントロール信号等の非同期データを転送するAsynchronous転送モード（ＡＴＭ）と、リアルタイムなＡＶデータの同期データを転送するIsochronous 転送モードがある。
これらの転送モードにより、非同期データ及び同期データは、各サイクル（通常１２５μS ／サイクル）の中で、サイクル開始を示すサイクル・スタート・パケット（ＣＳＰ）の転送に続き、同期データの転送を優先しつつ、サイクル内で混在して転送される。
【００７０】
図２は、１３９４シリアルバスの構成要素を示す図である。
この１３９４シリアルバスは、レイヤ構造で構成されている。上記図２に示すように、１３９４シリアルバス用のケーブル８１３の先端のコネクタには、１３９４コネクタ・ポート８１０が接続される。
【００７１】
１３９４コネクタ・ポート８１０の上位には、フィジカルレイヤ８１１及びリンクレイヤ８１２を含むハードウェア部８００が位置づけられている。
ハードウェア部８００は、インターフェース用チップで構成され、そのうちフィジカルレイヤ８１１は、符号化やコネクタ関連の制御等を行い、リンクレイヤ８１２は、パケット転送やサイクルタイムの制御等を行なう。
【００７２】
ハードウェア部８００の上位には、トランザクションレイヤ８１４及びマネージメントレイヤ８１５を含むファームウェア部８０１が位置づけられている。そのトランザクションレイヤ８１４は、転送（トランザクション）すべきデータの管理を行ない、Ｒｅａｄ、Ｗｒｉｔｅ、Ｌｏｃｋの命令を出す。また、マネージメントレイヤ８１５は、１３９４シリアルバスに接続されている各機器の接続状況やＩＤの管理を行ない、ネットワークの構成を管理する。
【００７３】
これらのハードウェア部８００及びファームウェア８０１までが、１３９４シリアルバスの実質的な構成である。
【００７４】
ファームウェア８０１の上位には、アプリケーションレイヤ８１６を含むソフトウェア部８０２が位置づけられている。そのアプリケーションレイヤ８１６は、利用されるソフトによって異なり、インタフェース上でどのようにしてデータを転送するかは、プリンタやＡＶ／Ｃプロトコル等のプロトコルによって定義されている。
【００７５】
図３は、１３９４シリアルバスにおけるアドレス空間の図を示す図である。
１３９４シリアルバスに接続された各機器（ノード）には必ず、上記図３に示すような、各ノード固有の６４ビットアドレスを持たせておく。このアドレスは機器のメモリに格納されており、これにより自分や相手のノードアドレスを常時認識することで、通信相手を指定したデータ通信が行える。
【００７６】
１３９４シリアルバスのアドレッシングは、ＩＥＥＥ１２１２規格に準じた方式で行われ、アドレス設定については、最初の１０ビットがバスの番号（バスＮｏ．）の指定用に、次の６ビットがノードＩＤ（ノードＮｏ．）の指定用に使用される。そして、残りの４８ビットが、機器に与えられたアドレス幅になる。この４８ビット領域は、各々固有のアドレス空間として使用できる。そのうちの最後の２８ビットについては、機器に固有のデータの領域（固有データ領域）であり、各機器の識別や使用条件の指定の情報等が格納される。
【００７７】
以上が、１３９４シリアルバスについての概要である。
つぎに、１３９４シリアルバスの特徴をより詳細に説明する。
【００７８】
［１３９４シリアルバスの電気的仕様］
【００７９】
図４は、１３９４シリアルバス用のケーブルの断面を示す図である。
この図４に示すように、１３９４シリアルバス用のケーブルでは、２組のツイストペア信号線の他に、電源ラインが設けられている。このような構成によって、電源を持たない機器や、故障等により電圧低下した機器等にも、電力の供給が可能となる。
また、電源線により供給される直流電力の電圧は、８〜４０Ｖ、その電流は、最大電流１．５Ａに規定されている。
尚、ＤＶケーブルと呼ばれる規格では、電源ラインを省いた四線で構成される。
【００８０】
［ＤＳ−Ｌｉｎｋ方式］
【００８１】
図５は、１３９４シリアルバスでデータ転送方式として採用されている、ＤＳ−Ｌｉｎｋ（Data/Strobe Link）方式を説明するための図である。
ＤＳ−Ｌｉｎｋ方式は、高速なシリアルデータ通信に適し、２組の信号線を必要とする。すなわち、２組の対線のうち一方の信号線でデータ信号を送り、他方の信号線でストローブ信号を送る構成となっている。したがって、受信側は、このデータ信号とストローブ信号を受信して排他的論理和をとることによって、クロックを再現することができる、という特徴がある。
このように、ＤＳ−Ｌｉｎｋ方式では、データ信号中にクロック信号を混入させる必要がない。したがって、ＤＳ−Ｌｉｎｋ方式では、他のシリアルデータ転送方式に比べ転送効率が高いクロック信号を生成できるため、位相ロックドループ（ＰＬＬ）回路が不要になり、その分コントローラＬＳＩの回路規模を小さくすることができる。また、転送すべきデータが無いときに、アイドル状態であることを示す情報を送る必要が無いため、各機器のトランシーバ回路をスリープ状態にすることができ、消費電力の低減が図れる。
【００８２】
［バスリセットのシーケンス］
【００８３】
１３９４シリアルバスに接続されている各機器（ノード）には、ノードＩＤが与えられ、ネットワークを構成するノードとして認識される。
【００８４】
例えば、ネットワーク機器の接続分離や、電源のＯＮ／ＯＦＦ等によるノード数の増減、すなわちネットワーク構成に変化があり、新たなネットワーク構成を認識する必要があるとき、その変化を検知した各ノードは、バス上にバスリセット信号を送信して、新たなネットワーク構成を認識するモードに入る。
このときのネットワーク構成の変化の検知は、１３９４コネクタ・ポート（上記図２、以下、単に「コネクタポート」と言う）において、バイアス電圧の変化を検知することによって行われる。
【００８５】
そこで、あるノードからバスリセット信号が送信されると、各ノードのフィジカルレイヤ８１１（上記図２）は、送信されてきたバスリセット信号を受信すると同時に、リンクレイヤ８１２（上記図２）にバスリセット信号の発生を伝達し、且つ他のノードに対してバスリセット信号を送信する。そして、最終的に全てのノードがバスリセット信号を受信した後、バスリセットのシーケンスが起動される。
【００８６】
尚、バスリセットのシーケンスは、ケーブルが抜き挿しされた場合や、ネットワークの異常等をハードウェアが検出した場合に起動されると共に、プロトコルによるホスト制御等、フィジカルレイヤ８１１（上記図２）に直接命令を与えることによっても起動される。また、バスリセットのシーケンスが起動されると、データ転送は一時中断され、そのシーケンスの起動間は待機状態となり、バスリセット終了後、新しいネットワーク構成のもとで再開される。
【００８７】
［ノードＩＤ決定のシーケンス］
【００８８】
上述のようにして、バスリセットのシーケンスが起動され、バスリセットが終了した後、各ノードは、新しいネットワーク構成を構築するために、各ノードにＩＤを与える動作に入る。このときの、バスリセットからノードＩＤ決定までの一般的なシーケンスについてを、図６〜図８の各フローチャートを用いて説明する。
【００８９】
上記図６は、バスリセット信号の発生から、ノードＩＤが決定してデータ転送が行えるようになるまでの、一連のシーケンスを示すフローチャートである。
この図６において、先ず、各ノードは、バスリセット信号を常時監視し（ステップＳ１０１）、バスリセット信号が発生したことを検知すると、ネットワーク構成がリセットされた状態において新たなネットワーク構成を得るために、互いに直結されている各ノード間で親子関係を宣言する（ステップＳ１０２）。
このステップＳ１０２の処理は、ステップＳ１０３の判定により、全てのノード間で親子関係が決定されたと判定されるまで繰り返される。そして、全てのノード間で親子関係が決定されると、次に、ルートを決定する（ステップＳ１０４）。
【００９０】
ステップＳ１０４にてルートが決定されると、次に、各ノードにＩＤを与えるノードＩＤの設定作業を行う（ステップＳ１０５）。
このステップＳ１０５の処理は、ルートから所定のノード順にノードＩＤの設定を行う処理であり、ステップＳ１０６の判定により、全てのノードにＩＤが与えられたと判定されるで繰り返される。
そして、全てのノードへのノードＩＤの設定が終了すると、新しいネットワーク構成が全てのノードにおいて認識され、ノード間のデータ転送が行える状態となる。この状態にて、各ノードは、データ転送を開始し（ステップＳ１０７）、これと同時にステップＳ１０１へと戻り、再びバスリセット信号の発生を監視する。
【００９１】
そこで、上記図７は、上述のバスリセット信号の監視（ステップＳ１０１）からルート決定（ステップＳ１０４）までの処理の詳細を示すフローチャートであり、上記図８は、上述のＩＤ設定（ステップＳ１０５、Ｓ１０６）の処理の詳細を示すフローチャートである。
【００９２】
先ず、上記図７において、各ノード（機器）は、バスリセット信号の発生を監視し（ステップＳ２０１）、バスリセット信号が発生したこと検知する。これにより、ネットワーク構成は、一旦リセットされる。
【００９３】
次に、リセットされたネットワーク構成を再認識する作業の第一段階として、各ノードは、フラグＦＬをリーフ（ノード）であることを示すデータでリセットする（ステップＳ２０２）。
その後、各ノードは、ポート数、すなわち自分に接続されている他ノードの数を調べ（ステップＳ２０３）、その結果に応じて、これから親子関係の宣言を始めるために、未定義（親子関係が決定されていない）ポートの数を調べる（ステップＳ２０４）。
尚、ステップＳ２０４で検知される未定義ポート数は、バスリセットの直後はポート数に等しいが、親子関係が決定されていくに従って減少する。
【００９４】
ここで、バスリセットの直後、親子関係の宣言を行えるのは、実際のリーフに限られている。リーフであるか否かは、ステップＳ２０３のポート数の確認結果から知ることができ、すなわちこのポート数が”１”であればリーフである。したがって、ステップＳ２０４で検知される未定義ポート数が”１”であった場合、リーフは、接続相手のノードに対して親子関係の宣言「自分は子、相手は親」を行い（ステップＳ２０５）、本シーケンスを終了する。
【００９５】
また、ステップＳ２０３のポート数の確認結果が”２”以上であったノード、すなわちブランチ（ノード）は、バスリセットの直後はステップＳ２０４で検知される未定義ポート数が”未定義ポート数＞１”となるため、フラグＦＬにブランチを示すデータをセットして（ステップＳ２０６）、他ノードから親子関係が宣言されるのを待つ（ステップＳ２０７）。
そして、他ノードから親子関係が宣言され、それを受けたブランチは、ステップＳ２０４に戻って未定義ポート数を確認する。このとき、もし未定義ポート数が”１”になっていれば、残ポートに接続されている他ノードに対して、ステップＳ２０５で「自分は子、相手は親」の親子関係を宣言することができる。また、まだ未定義ポート数が”２”以上あるブランチは、再度ステップＳ２０７で再び他ノードから「親子関係」が宣言されるのを待つことになる。
【００９６】
また、何れか１つのブランチ、又は、例外的に子宣言を行えるのにもかかわらずすばやく動作しなかったリーフの未定義ポート数が”０”になると、ネットワーク全体の親子関係の宣言が終了したことになる。このため、未定義ポート数が”０”になった唯一のノード、すなわち全てノードの親に決まったノードは、フラグＦＬにルート（ノード）を示すデータをセットする（ステップＳ２０８）。これにより、このノードは、ルートとして認識されることになり（ステップＳ２０９）、その後、本シーケンス終了となる。
【００９７】
上述のようにして、バスリセットから、ネットワーク内のノード間における親子関係の宣言までの処理が終了する。
次に、各ノードにＩＤを与える処理を行うが、ここで、最初にＩＤの設定を行うことができるのは、リーフである。したがって、ここでは、リーフ→ブランチ→ルートの順に若い番号（ノード番号：０）からＩＤを設定する。
【００９８】
すなわち、上記図８において、先ず、フラグＦＬに設定されたデータを基に、ノードの種類、すなわちリーフ、ブランチ、及びルートに応じた処理に分岐する（ステップＳ３０１）。
【００９９】
ステップＳ３０１の結果が”リーフ”であった場合、ネットワーク内に存在するリーフの数（自然数）が変数Ｎに設定される（ステップＳ３０２）。その後、リーフは、ルートに対してノード番号を要求する（ステップＳ３０３）。この要求が複数ある場合、これを受けたルートは、アービトレーションを行い（ステップＳ３０４）、ある１つのノードにノード番号を与え、他のノードにはノード番号の取得失敗を示す結果を通知する（ステップＳ３０５）。
【０１００】
ステップＳ３０６の判定により、ノード番号を取得できなかったリーフは、再びステップＳ３０３でノード番号の要求を繰り返す。
【０１０１】
一方、ステップＳ３０６の判定により、ノード番号を取得できたリーフは、取得したノード番号を含むＩＤ情報をブロードキャストすることで、全ノードに通知する（ステップＳ３０７）。このＩＤ情報のブロードキャストが終了すると、リーフの数を表す変数Ｎがデクリメントされる（ステップＳ３０８）。
その後、ステップＳ３０９の判定により、変数Ｎが”０”になるまで、ステップＳ３０３〜ステップＳ３０８の処理が繰り返される。全てのリーフのＩＤ情報がブロードキャストされると、次のブランチのＩＤ設定処理（ステップＳ３１０〜Ｓ３１７）に移る。
【０１０２】
このブランチのＩＤ設定処理は、ステップＳ３０１の結果がブランチであった場合にも実行される処理であり、上述のリーフのＩＤ設定時と同様に、先ず、ネットワーク内に存在するブランチの数（自然数）が変数Ｍに設定される（ステップＳ３１０）。その後、ブランチは、ルートに対してノード番号を要求する（ステップＳ３１１）。
この要求に対してルートは、アービトレーションを行い（ステップＳ３１２）、ある１つのブランチにはリーフに続く若い番号を与え、ノード番号を取得できなかったブランチには取得失敗を示す結果を通知する（ステップＳ３１３）。
【０１０３】
ステップＳ３２４の判定により、ノード番号の取得できなかったブランチは、再びステップＳ３１１でノード番号の要求を繰り返す。
【０１０４】
一方、ノード番号を取得できたブランチは、取得したノード番号を含むＩＤ情報をブロードキャストすることで、全ノードに通知する（ステップＳ３１５）、。このＩＤ情報のブロードキャストが終了すると、ブランチ数を示す変数Ｍがデクリメントされる（ステップＳ３１６）。
その後、ステップＳ３１７の判定により、変数Ｍが”０”になるまで、ステップＳ３１１〜ステップＳ３１６の処理が繰り返され、全てのブランチのＩＤ情報がブロードキャストされると、次のルートのＩＤ設定処理（ステップＳ３１８、Ｓ３１９）に移る。
【０１０５】
ここまでの処理が終了すると、最終的にＩＤ情報を取得していないノードはルートのみであるため、次のルートのＩＤ設定処理では、ルートは、他のノードに与えていない最も若い番号を自分のノード番号に設定し（ステップＳ３１８）、そのノード番号を含むＩＤ情報をブロードキャストする（ステップＳ３１９）。尚、このルートのＩＤ設定処理は、ステップＳ３０１の結果がルートの場合にも実行される処理である。
【０１０６】
上述のような処理により、全てのノードに対してＩＤが設定される。
そこで、図９に示すネットワーク例を用いて、ノードＩＤ決定のシーケンスの具体的な手順を説明する。
【０１０７】
この図９に示すネットワークは、ルートであるノードＢの下位にはノードＡとノードＣが直結され、ノードＣの下位にはノードＤが直結され、ノードＤの下位にはノードＥとノードＦが直結された階層構造を有する。このようなネットワークでの階層構造やルートノード、ノードＩＤを決定する手順は、以下のようになる。
【０１０８】
バスリセット信号が発生した後、各ノードの接続状況を認識するために、先ず、各ノードの直接接続されているポート間において親子関係の宣言がなされる。ここでいう「親子」とは、階層構造の上位が「親」、下位が「子」という意味である。
【０１０９】
上記図９では、バスリセットの後、最初に親子関係を宣言したのはノードＡである。
ここで、上述したように、１つのポートだけが接続されたノード（リーフ）から親子関係の宣言を開始することができる。これは、ポート数が”１”であれば、ネットワークの末端、すなわちリーフであるためである。これがが認識されると、それらのリーフ中で最も早く動作を行なったノードから親子関係が決定されていくことになる。このようにして、親子関係の宣言を行なったノードのポートが互いに接続された２つのノードの「子」と設定され、相手ノードのポートが「親」と設定される。したがって、上記図９では、ノードＡ−Ｂ間、ノードＥ−Ｄ間、ノードＦ−Ｄ間で「子−親」と設定されることになる。
【０１１０】
次に、階層が１つ上がって、複数のポートを持つノード、すなわちブランチのうち、他ノードから親子関係の宣言を受けたノードから順次、上位のノードに対して親子関係の宣言がなされる。
【０１１１】
上記図９では、先ず、ノードＤ−Ｅ間、Ｄ−Ｆ間の親子関係が決定された後、ノードＤがノードＣに対して親子関係を宣言し、その結果、ノードＤ−Ｃ間で「子−親」の関係が設定される。
ノードＤからの親子関係の宣言を受けたノードＣは、もう１つのポートに接続されているノードＢに対して親子関係を宣言し、これによってノードＣ−Ｂ間で「子−親」の関係が設定される。
【０１１２】
このようにして、上記図９に示すような階層構造が構成され、最終的に接続されている全てのポートにおいて親となったノードがルートと決定される（上記図９では、ノードＢがルートとなる）。
尚、ルートは、１つのネットワーク構成中に１つしか存在しない。また、ノードＡから親子関係を宣言されたノードＢが速やかに他のノードに対して親子関係を宣言した場合は、例えば、ノードＣ等の他のノードがルートになる可能性もあり得る。すなわち、親子関係の宣言が伝達されるタイミングによっては、どのノードもルートとなる可能性があり、ネットワーク構成が同一であっても、特定のノードがルートになるとは限らない。
【０１１３】
ルートが決定されると、各ノードＩＤの決定モードに入る。全てのノードは、決定した自分のＩＤ情報を、他の全てのノードに通知するブロードキャスト機能を持っている。
尚、ＩＤ情報は、ノード番号、接続されている位置の情報、持っているポートの数、接続のあるポートの数、各ポートの親子関係の情報等を含む情報として、ブロードキャストされる。
【０１１４】
ノード番号の割当としては、上述したようにリーフから開始され、順に、ノード番号＝０、１、２、・・・が割り当てられる。そして、ＩＤ情報のブロードキャストによって、そのノード番号は、割り当て済みであることが認識される。
全てのリーフがノード番号を取得し終ると、次はブランチへ移り、リーフに続くノード番号が割り当てられる。リーフと同様に、ノード番号が割り当てられたブランチから順にＩＤ情報がブロードキャストされ、最後にルートが自己のＩＤ情報をブロードキャストする。したがって、ルートは常に最大のノード番号を所有することになる。
【０１１５】
以上のようにして、階層構造全体のＩＤ設定が終了し、ネットワーク構成が再構築され、バスの初期化作業が完了することになる。
【０１１６】
［バスアービトレーション］
【０１１７】
１３９４シリアルバスは、データ転送に先立って必ずバスの使用権のアービトレーションを行なう。１３９４シリアルバスに接続された各機器（ノード）は、ネットワーク上で転送されるデータを各々中継することによって、ネットワーク内の全ての機器に同データを伝える論理的なバス型ネットワークを構成するため、パケットの衝突を防ぐ意味でバスアービトレーションが必要である。これによって、ある時間には、１つの機器だけがデータ転送を行なうことができる。
【０１１８】
図１０（ａ）及び（ｂ）は、アービトレーションを説明するための図であり、上記図１０（ａ）は、バス使用権を要求する動作を示し、上記図１０（ｂ）は、バスの使用を許可する動作を示している。
【０１１９】
バスアービトレーションが始まると、１つ若しくは複数のノードが親ノードに向かって、各々バス使用権を要求する。上記図１０（ａ）では、ノードＣが、その親ノードであるノードＢに対して、ノードＦが、その親ノードであるノードＡに対して、各々バス使用権を要求している。
この要求を受けた親ノードは、更に親ノードに向かって、バス使用権を要求することで、子ノードによるバス使用権の要求を中継する。この要求は最終的に調停を行なうルートに届けられる。上記図１０（ａ）では、ノードＦからの要求を受けたノードＡが、その親ノードであるノードＦに対してバス使用権を要求している。すなわち、ノードＡがノードＦによるバス使用権の要求を中継している。
【０１２０】
バス使用権の要求を受けたルートは、どのノードにバス使用権を与えるかを決定する。この調停作業はルートのみが行なえるものであり、調停に勝ったノードには、バス使用の許可が与えられる。上記図１０（ｂ）は、ノードＣにバス使用許可が与えられ、ノードＦのバス使用権の要求は拒否された状態を示している。このとき、ルートは、バスアービトレーションに負けたノードに対してＤＰ（data prefix ）パケットを送り、そのバス使用権の要求が拒否されたことを知らせる。バスアービトレーションに負けたノードのバス使用権の要求は、次回のバスアービトレーションまで待たされることになる。
一方、バスアービトレーションに勝ち、バス使用許可を得たノードは、以降、データ転送を開始することができる。
【０１２１】
ここで、バスアービトレーションの一連の流れのフローチャートを、図１１に示して説明する。
【０１２２】
まず、ノードがデータ転送を開始できる為には、バスがアイドル状態であることが必要である。先に行われていたデータ転送が終了して、現在、バスがアイドル状態にあることを認識するためには、各転送モードで個別に設定されている所定のアイドル時間のギャップ長（例えば、サブアクション・ギャップ）の経過を検出すればよい。
【０１２３】
そこで、先ず、各ノードは、転送する非同期データ又は同期データに応じた所定のギャップ長が得られたか否かを判定する（ステップＳ４０１）。この所定のギャップ長が得られない限り、各ノードは、転送を開始するために必要なバス使用権を要求することはできない。したがって、各ノードは、所定のギャップ長が得られるまで待ち状態となる。
【０１２４】
ステップＳ４０１により、所定のギャップ長が得られると、そのノードは、転送すべきデータがあるか判定し（ステップＳ４０２）、転送データ有りの場合には、バス使用権を要求する信号をルートに対して送信する（ステップＳ４０３）。このバス使用権の要求を示す信号は、上記図１０（ａ）に示したように、ネットワーク内の各機器に中継されながら、最終的にルートに届けられる。
尚、ステップＳ４０２において、転送データ無しと判定された場合、そのノードは、そのまま待機状態となる。
【０１２５】
ルートは、バス使用権を要求する信号を１つ以上受信すると（ステップＳ４０４）、そのバス使用権を要求したノードの数を調べる（ステップＳ４０５）。
このステップＳ４０５の結果、バス使用権を要求したノードが１つであった場合、ルートは、そのノードに直後のバス使用許可を与える（ステップＳ４０８）。
【０１２６】
一方、ステップＳ４０５の結果、バス使用権を要求したノードが複数であった場合、ルートは、直後のバス使用許可を与えるノードを１つに絞る調停作業を行う（ステップＳ４０６）。この調停作業は、毎回同じノードのみにバスの使用許可が与えられるという様なことはなく、平等にバス使用権が与えられるようにするための作業である（フェア・アービトレーション）。
【０１２７】
その結果、調停に勝った１つのノードと、敗れたその他のノードとに応じて、処理が分岐する（ステップＳ４０７）。
これにより、調停に勝った１つのノードには、直後のバス使用許可を示す許可信号が送られる（ステップＳ４０８）。したがって、この許可信号を受信したノードは、直後に転送すべきデータ（パケット）の転送を開始する。そして、そのデータ転送完了後、ステップＳ４０１へと戻る。
また、調停に敗れたノードには、バス使用権の要求が拒否されたことを示すＤＰ（data prefix ）パケットが送られる（ステップＳ４０９）。したがって、ＤＰパケットを受け取ったノードは、再度バス使用権を要求するために、ステップＳ４０１へと戻る。
【０１２８】
［Asynchronous転送］
【０１２９】
図１２は、アシンクロナス転送における時間的な遷移状態を示した図である。この図１２において、最初の”subaction gap ”（サブアクション・ギャップ）は、バスのアイドル状態を示すものである。このアイドル状態の時間が所定値になった時点で、データ転送を希望するノードがバス使用権を要求できると判定し、したがって、上記図１１で説明したようなバスアービトレーションが実行されることになる。
【０１３０】
バスアービトレーションによりバスの使用が許可されると、データ転送がパケットされる。このデータを受信したノードは、”ａｓｋ ｇａｐ”という短いギャップの後、受信確認用の返送コード”ａｃｋ”を返して応答する（又は、応答パケットを送る）ことによってデータ転送が完了する。この”ａｃｋ”は、４ビットの情報と４ビットのチェックサムからなり、成功、ビジー状態、又は、ペンディング状態を示す情報を含み、すぐにデータ送信元のノードに返される情報である。
【０１３１】
図１３は、アシンクロナス転送用のパケットフォーマットを示す図である。
パケットには、データ部及び誤り訂正用のデータＣＲＣの他にヘッダ部があり、そのヘッダ部には、目的ノードＩＤ、ソースノードＩＤ、転送データ長や各種コード等が書き込まれている。
ここで、アシンクロナス転送は、自己ノードから相手ノードへの１対１の通信である。したがって、転送元ノードから送り出されたパケットは、ネットワーク中の各ノードに行き渡るが、各ノードは自分宛てのパケット以外は無視するので、宛先に指定されたノードのみがそのパケットを受け取ることになる。
【０１３２】
［Isochronous 転送］
【０１３３】
１３９４シリアルバスの最大の特徴であるともいえるこのアイソクロナス転送は、特に、ＡＶデータ等のリアルタイム転送を必要とするマルチメディアデータの転送に適している。
また、アシンクロナス転送が１対１の転送であったのに対し、このアイソクロナス転送は、ブロードキャスト機能によって、１つの転送元ノードから他の全てのノードへ一様にデータを転送することができる。
【０１３４】
図１４は、アイソクロナス転送における時間的な遷移状態を示す図である。
アイソクロナス転送は、バス上で一定時間毎に実行される。この時間間隔は、アイソクロナスサイクルと呼ばれ、１２５μS としてる。この各サイクルの開始時間を示し、各ノードの時間調整を行なう役割を担っているのが、サイクル・スタート・パケット（ＣＳＰ）である。ＣＳＰを送信するのは、サイクル・マスタと呼ばれるノードであり、１つ前のサイクル内の転送終了し、所定のアイドル期間（サブアクションギャップ）を経た後、本サイクルの開始を告げるＣＳＰを送信する。すなわち、ＣＳＰの送信される時間間隔が１２５μS となる。
【０１３５】
また、上記図１４に”チャネルＡ”、”チャネルＢ”、及び”チャネルＣ”と示すように、１つの同期サイクル内において、複数種のパケットにチャネルＩＤを各々与えることによって、それらのパケットを区別して転送することができる。これによって、複数のノード間で、略同時に、リアルタイム転送が可能となり、また、受信ノードは、自分が望むチャネルＩＤのデータのみを受信すればよい。
尚、チャネルＩＤは、受信ノードのアドレス等を表すものではなく、データに対する論理的な番号を与えているに過ぎないものである。したがって、送信されたパケットは、１つの送信元ノードから他の全てのノードに行き渡る、すなわちブロードキャストされることになる。
【０１３６】
アイソクロナス転送では、そのパケット送信に先立って、上述のアシンクロナス転送と同様にバスアービトレーションが行われる。しかしながら、アイソクロナス転送はアシンクロナス転送のように１対１の通信ではないため、上記図１４に示すように、アイソクロナス転送には、受信確認用の返送コードである”ａｓｋ”は存在しない。
また、上記図１４に示す”ｉｓｏ ｇａｐ”（アイソクロナスギャップ）は、アイソクロナス転送を行なう前にバスがアイドル状態であることを認識するために必要なアイドル期間を表している。この所定のアイドル期間を経過すると、アイソクロナス転送を行ないたいノードに対するバスのアービトレーションが行なわれる。
【０１３７】
図１５は、アイソクロナス転送用のパケットフォーマットを示す図である。
各チャネルに分けられた各種のパケットには、各々データ部及び誤り訂正用のデータＣＲＣの他にヘッダ部があり、そのヘッダ部には、転送データ長やチャネルＮｏ．、その他各種コード及び誤り訂正用のヘッダＣＲＣ等が書き込まれている。
【０１３８】
［バス・サイクル］
【０１３９】
実際に、１３９４シリアルバスにおいては、アイソクロナス転送とアシンクロナス転送が混在できる。その時のバス上の転送状態の時間的な遷移の様子を、図１６に示す。
アイソクロナス転送は、アシンクロナス転送より優先して実行される。その理由は、ＣＳＰの後、アシンクロナス転送を起動するために必要なアイドル期間のギャップ長（”subaction gap ”サブアクションギャップ）よりも短いギャップ長（”ack gap ”アイソクロナスギャップ）で、アイソクロナス転送を起動できるからである。したがって、アシンクロナス転送よりアイソクロナス転送が、優先して実行されることとなる。
【０１４０】
上記図１６示す一般的なバスサイクルでは、サイクル＃ｍのスタート時にＣＳＰがサイクル・マスタから各ノードに転送される。このＣＳＰによって、各ノードの動作の同期がとられ、所定のアイドル期間（アイソクロナスギャップ）を待ってからアイソクロナス転送を行おうとするノードは、バスアービトレーションに参加して、パケット転送に入る。上記図１６では、”チャネルｅ”、”チャネルｓ”、”チャネルｋ”が順にアイソクロナス転送されている。
このバスアービトレーションからパケット転送までの動作を、与えられているチャネル分繰り返し行なった後、サイクル＃ｍにおけるアイソクロナス転送が全て終了すると、アシンクロナス転送を行うことができるようになる。
【０１４１】
すなわち、アイドル時間が、アシンクロナス転送が可能なサブアクションギャップに達することによって、アシンクロナス転送を行いたいノードは、バスアービトレーションに参加する。
尚、アシンクロナス転送が行えるのは、アイソクロナス転送終了後から、次のＣＳＰを転送すべき時間（cycle synch ）までの間に、アシンクロナス転送を起動するためのサブアクションギャップが得られた場合に限られる。
【０１４２】
上記図１６のサイクル＃ｍでは、３つのチャネル分のアイソクロナス転送の後、アシンクロナス転送により、”ａｃｋ”を含む２つのパケット（パケット１、パケット２）転送されている。この２つのパケット転送後は、サイクル＃（ｍ＋１）をスタートすべき時間（cycle synch ）に至るので、サイクル＃ｍでの転送はこれ終了する。
このとき、非同期又は同期転送中に次のＣＳＰを送信すべき時間（cycle synch ）に至った場合、転送を無理に中断せず、その転送が終了した後に、アイドル期間を経て、次サイクルのＣＳＰを送信する。すなわち、１つのサイクルが１２５μS 以上続いた場合は、その延長分、次サイクルが基準の１２５μS より短縮される。このように、アイソクロナス・サイクルは、１２５μS を基準に超過或いは短縮し得るものである。
尚、アイソクロナス転送は、リアルタイム転送を維持するために、必要であれば毎サイクル実行され、アシンクロナス転送は、サイクル時間が短縮されたことによって、次以降のサイクルに延期されることもある。こういった遅延情報も、サイクル・マスタによって管理される。
【０１４３】
（第１の実施の形態）
【０１４４】
図１７は、１３９４シリアルバスのインターフェースをＬＡＮでよく用いられるＯＳＩモデルの各層と対比させた図である。
ＯＳＩモデルの物理層（Physical）１とデータリンク層（Datalink）２が、１３９４シリアルバスのインターフェースの下位層（IEEE1394 Layers ）４であるフィジカル層８１１及びリンク層８１２（上記図２）に該当する。下位層４の上に存在する１３９４シリアルバスのインターフェースにおけるトランスポートプロトコル層（Transprt Protocols）５とプレゼンテーション層（Presentation）６は、ＯＳＩモデルのネットワーク層（Network ）、トランスポート層（Transport ）、セッション層（Session ）、及びプレゼンテーション層（Presentation）を含む上位層３に該当する。
また、本発明の特徴であるＬＯＧＩＮプロトコル（Login Protocol）（初期プロトコル）７は、１３９４シリアルバスのインターフェースの下位層４とトランスポートプロトコル層５の間で動作するものである。
【０１４５】
上記図１７に示す例１（Example 1 ）では、プリンタ等の周辺機器用のシリアルバスプロトコル（ＳＢＰ−２）（デバイス固有のプロトコル）８に準拠したデバイスに対して、ＬＯＧＩＮプロトコル７を持たせる。これにより、相手のデバイスに対してＳＢＰ−２に準拠したプロトコルを使って、データのやり取りを行いたいことを通知することができる。
また、上記図１７に示す例２（Example 2 ）では、１３９４シリアルバスのインターフェース上で特化されたデバイスプロトコル（Device Specific Protocol）（デバイス固有のプロトコル）９に対して、ＬＯＧＩＮプロトコル７を持たせる。これにより、この例２においても、デバイスが互いに、互いのプロトコルをサポートしていることを判別することができる。
【０１４６】
図１８は、ＬＯＧＩＮプロトコルの基本動作を示す図であり、プリンタデバイスは、ホストデバイスからの印字タスク（Print task）１０を実行する際に、先ず、プリンタに用意されているプリンタプロトコルＡ、Ｂ、及びＣ（Protocol A、B 、C ）のうち、どれを選択して印字データのやり取りを行うかをＬＯＧＩＮプロトコル７による通信に基づいて決定し、その後、その決定したプリンタプロトコルに従って、印字データのやり取りを行う。
すなわち、いくつかのプリンタプロトコルをサポートしているデバイスは、ホストデバイスと接続する際に、先ず、ホストデバイスに用意されているトランスポートプロトコル５をＬＯＧＩＮプロトコル７によって判別し、ホストデバイスのトランスポートプロトコル５に合ったプリンタプロトコルを選択し、選択したプリンタプロトコルに従った印字データやコマンドのやり取りを行うことで、印字タスク１０の処理を行う。
【０１４７】
図１９は、１３９４シリアルバスにおける接続形態を示す図であり、ここでは、複数のプリンタプロトコルに対応したプリンタ１１に対してＬＯＧＩＮプロトコル７を実装したデバイス（ＰＣ１２、スキャナ１３、ＶＣＲ１４等）が接続された状態を示している。
プリンタ１１は、ＬＯＧＩＮプロトコル７により判別した、接続を要求する相手デバイスのトランスポートプロトコル５に応じてプリンタプロトコルを切り替えることにより、各デバイス１２〜１４からの印字タスクを問題なく処理することができる。
【０１４８】
図２０は、ログイン動作の流れを示す図である。
第１ステップ（STEP 1）において、
・ホストデバイス（HOST）は、ターゲットデバイス（DEVICE、この場合マルチプロトコルプリンタ）をロックする。
・ターゲットデバイスは、ホストデバイスのケーパビリティ（トランスポートプロトコル等を含む）を調べる。このケーパビリティは、後述するレジスタ５０３に格納される。
・ターゲットデバイスは、ホストデバイスのケーパビリティ（トランスポートプロトコル等を含む）をセットする。
第２ステップ（STEP 2）において、
・第１ステップで決定されたプロトコルで、プリントデータを通信する。
第３ステップ（STEP 3）において、
・ホストデバイスは、ターゲットデバイスとのコネクションを切断する。
【０１４９】
図２１は、ＬＯＧＩＮプロトコルのためにターゲットデバイスであるプリンタが備える１３９４シリアルバスのＣＳＲにおいて、ロックレジスタ（lock）５０１、プロトコルレジスタ（protocol）５０２、ケーパビリティレジスタ（capability）５０３を示した図である。
これらのレジスタは、１３９４シリアルバスのアドレス空間における初期ユニット空間の定められたアドレスに配置される。すなわち、上記図３に示したように、機器に与えられたアドレス幅４８ビットのうち、最初の２０ビットにおける0xFFFFF がレジスタ空間と呼ばれ、その最初の５１２バイトにＣＳＲアーキテクチャのコアになるレジスタ（ＣＳＲコア）が配置されている。
尚、このレジスタ空間には、バスに接続された機器間で共通な情報が置かれる。また、0 〜0xFFFFD はメモリ空間、0xFFFFE はプライベート空間と、各々呼ばれ、プライベート空間は、機器内で自由に利用できるアドレスであり、各機器間のコミュニケーションに使われる。
【０１５０】
ロックレジスタ５０１は、リソースのロック状態（専有状態）を示し、”０”でログイン可能な状態を表し、”０”以外でロック状態で既にログインされていることを表す。
プロトコルレジスタ５０２には、実際に通信に使用するプロトコルが書き込まれる。したがって、このプロトコルレジスタ５０２は、現在設定されているプロトコルを示し、設定されたプロトコルに対応するケーパビリティレジスタ５０３のビットに相当するビットの値が”１”になる。
ケーパビリティレジスタ５０３には、各々のデバイスが対応可能なプロトコルを示す情報が格納され、各ビットの各々が独立に対応可能なデータトランスポートプロトコルを示す。すなわち、ケーパビリティレジスタ５０３は、複数ビットを有し、そのビット毎で設定可能なトランスポートプロトコルを各々独立に示す。例えば、”１”のビットに対応するプロトコルは設定可能であることを表し、”０”のビットに対応するプロトコルは設定不可能であることを表す。
【０１５１】
図２２は、１３９４シリアルバスにより構成されたネットワーク（１３９４ネットワーク）におけるプリンタマップのフォーマットを示した図である。
このプリンタマップには、応答を返してきたプリンタのユニークＩＤ（Unique ID ）、ノードＩＤ（Node ID ）、ステータス（Status）、及びケーパビリティ（Capability）等の情報が保存される。このとき、”ノードＩＤ”は、図２３に示すようなＣＳＲアーキテクチャにおけるフォーマットに従って保存される。
尚、ここでの”ステータス（Status）”は、例えば、上記図２１に示したプロトコルレジスタ５０２の内容を示し、”ケーパビリティ（Capability）”は、例えば、上記図２１に示したケーパビリティレジスタ５０３の内容を示す。
【０１５２】
図２４は、上記図２２に示したようなプリンタマップの作成コマンドのフィーマットを示した図である。このコマンドは、非同期パケットのライトトランザクションにより、ターゲットデバイスに対して送信される。また、このコマンドは、１３９４シリアルバスのアドレス空間におけるユニット空間の定められたアドレスに配置される。
【０１５３】
図２５は、複数のプロトコルに対応可能なプリンタが１３９４シリアルバスに接続されて構成されるネットワークにおいて、ホストデバイスでのプリンタマップ作成処理を示したフローチャートである。
【０１５４】
ここで、ネットワーク上には、通常、様々なデバイスが接続されている。このような状況下で、イニシエータ（ホストデバイス）がターゲットデバイスであるプリンタとの通信を試みるとき、どのデバイスが目的とするプリンタに対応しているかを認識する必要がある。また、適切なプリンタ出力を得るためには、それに対応したプリンタの物理的な場所、その能力、その余力等を予め認識しておくと非常に都合がよい。
【０１５５】
そこで、ここでは、同一ネットワークに存在する各プリンタを予め調査する。
具体的には、ホストデバイスは、予め、ネットワーク上に存在する各プリンタを調査することで（第１の調査処理）、各々の物理的な場所、能力、及び余力等の情報（以下、トポロジー／能力情報とも言う）を得て、上記図２２に示したようなプリンタマップを作成する。そして、そのプリンタマップに基づいて、目的とするプリンタを選択する。
【０１５６】
プリンタマップの作成については、上記図２５に示すように、先ず、ホストデバイスは、上記図２４に示したようなプリンタマップ作成のためのコマンド（作成コマンド）を、ブロードキャストすることで（ステップＳ３００１）、ネットワーク上に存在する全てのデバイスに送信する。
そして、ホストデバイスは、各デバイスからの応答、すなわちネットワーク上に存在する各プリンタからの応答（応答コマンド）を待つ（ステップＳ３００２）。
【０１５７】
次に、ホストデバイスは、各プリンタからの応答コマンドを受信すると、その応答コマンドを返してきたプリンタのプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３００３）。これにより、ホストデバイスは、そのプリンタの能力や状態等を認識する。
【０１５８】
そして、ホストデバイスは、ステップＳ３００３で得た情報を基に、現在のネットワーク上のプリンタについてのプリンタマップを作成して（ステップＳ３００４）、本処理を終了する。
【０１５９】
図２６は、上述したホストデバイスから作成コマンドが与えられるターゲットデバイス、特に、プリンタでの処理を示すフローチャートである。
上記図２６において、先ず、プリンタは、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３１０１）。
具体的には、例えば、現在の自プリンタの能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、プリンタ内部でのステータス及びケーパビリティの変化は、このステップＳ３１０１でのステータス及びケーパビリティの提示にも反映することになる。
【０１６０】
次に、プリンタは、ホストデバイスからの作成コマンドを待つ（ステップＳ３１０２）。
そして、プリンタは、ホストデバイス側からの作成コマンドを受信すると、その作成コマンドに対する応答コマンドをホストデバイスへ返送する（ステップＳ３１０３）。
【０１６１】
図２７は、ホストデバイスにおけるログイン処理を示すフローチャートである。
ここで、ホストデバイスがターゲットデバイス（ここでは、プリンタ）へのログインを開始するためには、上記図２５に示したプリンタマップ作成処理（ステップＳ６００）の後、リード又はロックトランザクションによって、ログインしようとするプリンタのロックレジスタ５０１、プロトコルレジスタ５０２、及びケーパビリティレジスタ５０３のデータを確認する必要がある。
【０１６２】
そこで、先ず、ホストデバイスは、プリンタのケーパビリティレジスタ５０３のビット毎のデータから、自分が通信に用いようとしているプロトコルをプリンタがサポートしているかを確認する（ステップ６０１）。このとき、もし、プリンタが自分のプロトコルをサポートしていない場合には、そのプリンタへのログインを中止とする。
【０１６３】
次に、ホストデバイスは、プリンタのロックレジスタ５０１のデータから、現在ログイン可能であるかを確認する（ステップ６０２）。すなわち、プリンタのロックレジスタ５０１のデータが”０”以外であれば、他のデバイスがプリンタへログイン中であると見なし、ログイン中止（Login N.G.）とし、本処理を終了する。一方、プリンタのログインレジスタ５０１のデータが”０”であれば、現在ログイン可能（Login O.K.）と見なし、次のステップに進む。
尚、ステップ６０１において、プリンタがホストデバイスのプロトコルをサポートしておらず、ログインを中止とされた場合、このステップ６０２の判定により、本処理終了となる。
【０１６４】
ステップ６０２の判定により、プリンタへのログインが可能であった場合、ホストデバイスは、ロックトランザクションによって、プリンタのロックレジスタ５０１に”１”を書き込み、ログインを設定する（ステップ６０３）。この状態でプリンタはロックされたことになり、他のデバイスからの制御は不可能となり、また、レジスタの変更も不可能となる。
【０１６５】
上述のようにして、プリンタのリソースがロックされた状態となると、次に、ホストデバイスは、プロトコルの設定を行なう。
ここで、プリンタは、複数のプリンタプロトコルをサポートするため、プリントデータを受け取る前に、ホストデバイスが使用できるプロトコルを知る必要がある。
そこで、ホストデバイスは、ライトトランザクションによって、プリンタのプロトコルレジスタ５０２の相当するビットを設定することで、これから使用するプロトコルをプリンタに通知する（ステップ６０４）。
【０１６６】
この時点で、ホストデバイスが通信に用いるプロトコルがプリンタに通知され、且つプリンタがロック状態であるため、現在、プリンタでバスにログインしているホストデバイスがデータ（ここでは、プリントデータ）の送信を行なう（ステップ６０５）。
【０１６７】
プリントデータの送信が終了すると、ホストデバイスは、プリンタのロックレジスタ５０１、プロトコルレジスタ５０２、及びケーパビリティレジスタ５０３をクリアすることにより、プリンタからログアウトする（ステップ６０６）。
【０１６８】
図２８は、ターゲットデバイスであるプリンタのログイン処理を示す図である。
先ず、プリンタ側では、図２６に示したプリンタマップ作成処理が実行される（ステップＳ７００）。
ここで、通常、ホストデバイスからログインされるのを待つ状態にあるホストデバイスからのプリントリクエストは、プリンタのロックレジスタ５０１、プロトコルレジスタ５０２、及びケーパビリティレジスタ５０３の読み取りにより開始されるため、プリンタは、これらのレジスタを常に他のデバイスから読み出し可能の状態にしておく。この状態により、今、プリントアウトを実行しようとするホストデバイスからプリンタがロックされたとする（ステップＳ７０１）。
【０１６９】
次に、プリンタは、ホストデバイスから使用プロトコルが通知されるのを待つ（ステップＳ７０２）。このように、プリンタがロック状態になってから使用プロトコルの通知を待つのは、ログインの途中で他のデバイスからのリクエストにより、プロトコルレジスタ５０２の内容が書き換えられないようにするためである。
【０１７０】
そして、ホストデバイスからプリンタへ使用プロトコルの通知があると（ステップＳ７０３）、プリンタは、自分のプロトコルを通知された使用プロトコルに切り換えて、ホストデバイスのプロトコルに合わせた通信を行う（ステップＳ７０４〜Ｓ７０９）。
【０１７１】
通信が終了したら、プリンタは、ロックレジスタ５０１及びケーパビリティレジスタ５０３がクリアされたのを確認し（ステップＳ７１０）、ログインを待つ状態（ステップ７０１）に戻る。
【０１７２】
（第２の実施の形態）
【０１７３】
上述した第１の実施の形態では、上記図２５及び図２６を用いて説明したように、１３９４シリアルバスに複数のプリンタを含む各デバイスが接続されてなるネットワーク上において、ホストデバイスが各プリンタについてのプリンタマップを作成し、そのプリンタマップに基づいて目的のプリンタを選択するようにしたが、本実施の形態では、ホストデバイスとプリンタが共に複数のプロトコルをサポートしており、さらにそのようなプリンタが複数存在する場合、ホストデバイスが各プリンタの使用可能なプロトコルを調べて多数決を取り、最も多くサポートされているプロトコルを決定する。
このように、多くのプロトコルが使用可能な状況下で多数決を取るように構成することで、実際に使用するプロトコルの種類を削減することを可能とし、ホストデバイスのプロトコルスイッチによる負荷を下げることを可能とする。
【０１７４】
尚、本実施の形態は、上記図２５及び図２６に示した処理以外については第１の実施の形態と同様であるため、その詳細な説明は省略し、ここでは、第１の実施の形態と異なる点についてのみ具体的に説明する。
【０１７５】
具体的には、まず、１３９４シリアルバスを用いたネットワーク上において、ホストデバイス（イニシエータ）とターゲットデバイス（プリンタ）が共に複数のプロトコルをサポートしており、さらにそのようなターゲットデバイスが同一ネットワークに複数接続されている場合、当然、ホストデバイスとターゲットデバイスは同一プロトコルを用いる必要がある。
そこで、ここでは、今、どのプロトコルを用いるかを決定するために、ホストデバイスが各ターゲットデバイスの使用可能なプロトコルを調べ、その中で多数決を取り、最も多くサポートされているプロトコルを決定する。
【０１７６】
このため、本実施の形態では、第１の実施の形態における上記図２５及び図２６の処理の代わりに、図２９及び図３０に示す処理を実行する。
尚、上記図２９は、ホストデバイスのプリンタマップ作成処理（相対多数プロトコル決定プリンタマップ処理）を示すフローチャートであり、ホストデバイスのログイン処理（上記図２７：ステップＳ６００）で実行される。また、上記図３０は、この処理時におけるプリンタの処理を示すフローチャートであり、プリンタのログイン処理（上記図２９：ステップＳ７００）で実行される。
【０１７７】
すなわち、上記図２９において、先ず、ホストデバイスは、上記図２２に示したプリンタマップを作成するために、その作成コマンドをブロードキャストすることで、ネットワーク上に存在する全てのデバイスに送信する（ステップＳ３２０１）。
そして、ホストデバイスは、各デバイスからの応答、すなわちネットワーク上に存在する各プリンタからの応答（応答コマンド）を待つ（ステップＳ３２０２）。
【０１７８】
次に、ホストデバイスは、各プリンタからの応答コマンドを受信すると、その応答コマンドを返してきたプリンタのプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３２０３）。これにより、ホストデバイスは、そのプリンタの能力や状態等を認識する。
【０１７９】
次に、ホストデバイスは、ステップＳ３２０３で得た情報を基に、現在のネットワーク上のプリンタについてのプリンタマップを作成する（ステップＳ３２０４）。
【０１８０】
次に、ホストデバイスは、ステップＳ３２０４で作成したプリンタマップより、現在ネットワークに接続されているプリンタ（複数のプロトコルをサポートしているマルチプロトコルプリンタ）の使用可能なプロトコルを調べ、それらのプロトコルの中から、最も多くサポートされているプロトコルを選択する（ステップＳ３２０５）。
【０１８１】
そして、ホストデバイスは、ステップＳ３２０５で選択したプロトコルを、プロトコル通知コマンドとして各プリンタに通知して（ステップＳ３２０６）、本処理を終了する。
【０１８２】
一方、プリンタは、上記図３０に示すように、先ず、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３３０１）。
具体的には、例えば、現在の自プリンタの能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、プリンタ内部でのステータス及びケーパビリティの変化は、このステップＳ３３０１でのステータス及びケーパビリティを提示にも反映することになる。
【０１８３】
次に、プリンタは、ホストデバイスからの作成コマンドを待つ（ステップＳ３３０２）。
そして、プリンタは、ホストデバイスからの作成コマンドを受信すると、そのコマンドに対する応答コマンドをホストデバイスへ返送する（ステップＳ３３０３）。
【０１８４】
次に、プリンタは、ホストデバイスからのプロトコル通知コマンドを待つ（ステップＳ３３０４）。
そして、プリンタは、ホストデバイスからのプロトコル通知コマンドを受信すると、そのコマンドにより示されるプロトコルに自分のプロトコルを切り換える（ステップＳ３３０５）。
【０１８５】
（第３の実施の形態）
【０１８６】
図３１は、本実施の形態における動作を示した図であり、上記図１８に示した第１の実施の形態と比較すると、ＬＯＧＩＮプロトコル７を実装していないプロトコルＤを持つデバイスについても対応している点が特徴である。
すなわち、ＬＯＧＩＮプロトコル７を持つデバイスだけでなく、既存のプロトコルＤ（例えば、ＡＶ／Ｃプロトコル）にのみ対応しているデバイスに対しても印字動作の保証を行う為に、プリンタに、ＬＯＧＩＮプロトコル７を持たないデバイスに対応するプリンタプロトコルを追加する。
【０１８７】
この動作について説明すると、接続の初めに行われるプリントリクエストによってホストデバイスがＬＯＧＩＮプロトコル７に対応していないことをプリンタが認識した場合、プリンタは、プロトコルＤを使ってホストデバイスとの通信を試み、通信が成立した場合は、そのプロトコルＤに従って印字タスク１０を実行する。
【０１８８】
図３２は、本実施の形態と、ＯＳＩモデルとを対比させた図であり、例３（Example 3 ）では、ＬＯＧＩＮプロトコル７の実装されていない現行のＡＶ／Ｃプロトコルに準拠したＡＶデバイス１５をモデルとしている。例４（Example 4 ）では、ＬＯＧＩＮプロトコル７が実装されていないスキャナ用の非標準プロトコルが実装されているスキャナ１６をモデルとしている。
すなわち、ＬＯＧＩＮプロトコル７を実装していないプロトコルを持つデバイスについても、そのデバイスが持つプロトコルにプリンタが対応することができれば、そのプリンタを利用することができるデバイスの種類を広げることができる。
【０１８９】
（第４の実施の形態）
【０１９０】
上述した第１の実施の形態では、上記図２５及び図２６を用いて説明したように、１３９４シリアルバスに複数のプリンタを含む各デバイスが接続されてなるネットワーク上において、ホストデバイス（イニシエータ）がターゲットデバイスである各プリンタについてのプリンタマップを作成し、そのプリンタマップに基づいて目的のプリンタを選択するようにしたが、本実施の形態では、プリンタをネットワーク上の１出力デバイス（ホストデバイス）とし、ディジタルビデオ、ディジタルカメラ、スキャナ、モニタ、コンピュータ等をイメージ入力装置（ターゲットデバイス）とし、プリンタがイメージ入力装置にログインして画像情報を取得するために、プリンタがイメージ入力装置についてのマップ（上述のプリンタマップに相当するマップ）を作成し、そのマップに基づいて目的のイメージ入力装置を選択する。
【０１９１】
尚、本実施の形態は、上記図２５及び図２６に示した処理以外については第１の実施の形態と同様であるため、その詳細な説明は省略し、ここでは、第１の実施の形態と異なる点についてのみ具体的に説明する。
【０１９２】
まず、上述したように、ネットワーク上には、通常、様々なデバイスが接続されている。このような状況下で、プリンタ（イニシエータ）がターゲットデバイスであるイメージ入力装置との通信を試みるとき、どのデバイスが目的とするイメージ入力装置に対応しているかを認識する必要がある。また、適切なプリンタ出力を得るためには、それに対応したイメージ入力装置の物理的な場所、その能力、その余力等を予め認識しておくと非常に都合がよい。
【０１９３】
そこで、ここでは、同一ネットワークに存在する各イメージ入力装置を予め調査する。
具体的には、プリンタは、予め、ネットワーク上に存在する各イメージ入力装置を調査することで（第２の調査処理）、各々の物理的な場所、能力、及び余力等の情報（トポロジー／能力情報）を得て、上記図２２に示したようなプリンタマップに相当するマップを作成する。そして、そのマップに基づいて、目的とするイメージ入力装置を選択する。
【０１９４】
イメージ入力装置についてのマップの作成については、図３３に示すように、先ず、プリンタは、マップ作成のためのコマンド（作成コマンド）を、ブロードキャストすることで（ステップＳ３４０１）、ネットワーク上に存在する全てのデバイスに送信する。
そして、プリンタは、各デバイスからの応答、すなわちネットワーク上に存在する各イメージ入力装置からの応答（応答コマンド）を待つ（ステップＳ３４０２）。
【０１９５】
次に、プリンタは、各イメージ入力装置からの応答コマンドを受信すると、その応答コマンドを返してきたイメージ入力装置のプロトコルレジスタ及びケーパビリティレジスタの内容を読み取る（ステップＳ３４０３）。これにより、プリンタは、そのイメージ入力装置の能力や状態等を認識する。
【０１９６】
そして、プリンタは、ステップＳ３４０３で得た情報を基に、現在のネットワーク上のイメージ入力装置についてのマップを作成して（ステップＳ３４０４）、本処理を終了する。
【０１９７】
図３４は、上述したプリンタから作成コマンドが与えられるターゲットデバイス、すなわちイメージ入力装置での処理を示すフローチャートである。
上記図３４において、先ず、イメージ入力装置は、電源投入時からステータス及びケーパビリティを提示する（ステップＳ３５０１）。
具体的には、例えば、現在の自装置の能力や状態等に応じて、プロトコルレジスタ及びケーパビリティレジスタの設定処理を行う。したがって、装置内部でのステータス及びケーパビリティの変化は、このステップＳ３５０１でのステータス及びケーパビリティの提示にも反映することになる。
【０１９８】
次に、イメージ入力装置は、プリンタからの作成コマンドを待つ（ステップＳ３５０２）。
そして、イメージ入力装置は、プリンタからの作成コマンドを受信すると、その作成コマンドに対する応答コマンドをプリンタへ返送して（ステップＳ３５０３）、本処理を終了する。
【０１９９】
上述のようにして、プリンタにて、イメージ入力装置についてのマップが作成された後、上記図２７及び図２８に示したようなログイン処理が実行される。この結果、プリンタは、ネットワーク上に存在する各イメージ入力装置から選択した適切なイメージ入力装置からの画像情報をプリント出力することになる。
【０２００】
尚、上述した各実施の形態では、ＩＥＥＥ１９３４シリアルバスを用いてネットワークを構成するものとしたが、本発明はこれに限定されるものではなく、例えば、Universal Serial Bus（ＵＳＢ）と呼ばれるシリアルインターフェース等、任意のシリアルインターフェースを用いて構成されるネットワークにも適用することができる。
【０２０１】
また、ホストデバイスとしては、例えば、コンピュータ、ディジタルカメラ、スキャナ、ＤＶＤ、Ｓｅｔ−ｔｏｐ−Ｂｏｘ、ディジタルテレビ、コンファレンスカメラ、ディジタルビデオ、及びこれらを含む複合機等を用いることができる。一方、ターゲットデバイスとしては、モニタ、コンピュータ、外部記憶装置、Ｓｅｔ−ｔｏｐ−Ｂｏｘ、プリンタ及びこれらを含む複合機等を用いることができる。
【０２０２】
また、上記図２７のステップＳ６００、上記図２８のステップＳ７００、及び上記図２９のステップＳ３２０４で実行されるプリンタマップ作成処理や、上記図３３のステップＳ３４０４で実行されるイメージ入力装置についてのマップ作成処理においては、トポロジ接続状態が上記図９のように調査されマップが作成される、かかるトポロジ接続状態が判定されることによって、単なる多数決ではなく、トポロジ接続状態を加味して実際に使用するプロトコルを決定することができる。
【０２０３】
また、上述した実施の形態では、ネットワーク上の各デバイスを、画像データを出力或いは入力する機器としたが、これに限らず、例えば、ネットワーク上のデバイスのうち任意のデバイスを、画像データの出力或いは入力することなく、単にネットワーク上の状態を検出し、他の機器とネットワークの関係を調査する機能を有する機器としてもよい。
【０２０４】
また、本発明は、上記図１９に示すような複数の機器から構成されるシステムに適用しても、１つの機器からなる装置内のデータ処理方法に適用してもよい。
【０２０５】
また、本発明の目的は、上述した各実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、達成されることは言うまでもない。
【０２０６】
この場合、記憶媒体から読み出されたプログラムコード自体が各実施の形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することとなる。
【０２０７】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０２０８】
また、コンピュータが読みだしたプログラムコードを実行することにより、各実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって各実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２０９】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって各実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２１０】
【発明の効果】
以上説明したように本発明によれば、ホストデバイスとターゲットデバイス間でデータ通信を行う際の通信プロトコルが、そのターゲットデバイスによって限定されることがない、拡張性の高いデータ処理方法、データ処理装置、プリンタ、及び記憶媒体を提供することができる。特に、複数種類のターゲットデバイス（プリンタやイメージ入力装置等）のプロトコルに対応可能であるので、拡張性が極めて高い。
【０２１１】
また、同一ネットワークに接続されたターゲットデバイスを調査することで、目的とするターゲットデバイスを選択することができるため、最適な出力（プリンタ出力等）を得ることができる。特に、プリンタ出力するのに適切なプリンタ（第１の種類のターゲットデバイス）を選択することができると共に、該プリンタに適切なイメージ入力装置（第１の種類のデバイスをホストデバイスとする第２の種類のターゲットデバイス）も選択することができるため、極めて良好なプリンタ出力を得ることができる。
【０２１２】
また、多くのプロトコルが使用可能な状況下であっても、それらのプロトコルのうちターゲットデバイスから最も多くサポートされているプロトコルを決定することで、実際に使用するプロトコルの種類を削減することができるため、ホストデバイスのプロトコルに切り替えによる負荷を下げることができる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４シリアルインターフェースを用いて構成されるネットワークシステムの一例を示すブロック図である。
【図２】ＩＥＥＥ１３９４シリアルインターフェースの構成を説明するための図である。
【図３】ＩＥＥＥ１３９４シリアルインターフェースにおけるアドレス空間を説明するための図である。
【図４】ＩＥＥＥ１３９４シリアルインターフェース用のケーブルの断面を説明するための図である。
【図５】ＤＳ−Ｌｉｎｋ方式を説明するための図である。
【図６】ＩＥＥＥ１３９４シリアルインターフェースにおけるネットワーク構築手順を説明するためのフローチャートである。
【図７】ルートの決定方法を説明するためのフローチャートである。
【図８】親子関係決定から全てのノードＩＤの設定までの手順を説明するためのフローチャートである。
【図９】ネットワークの一例を説明するための図である。
【図１０】バスアービトレーションを説明するための図である。
【図１１】アービトレーションの手順を説明するためのフローチャートである。
【図１２】アシンクロナス転送における時間的な遷移状態を説明するための図である。
【図１３】アシンクロナス転送用のパケットフォーマットを説明するための図である。
【図１４】アイソクロナス転送における時間的な遷移状態を説明するための図である。
【図１５】アイソクロナス転送用のパケットフォーマットを説明するための図である。
【図１６】アシンクロナス転送とアイソクロナス転送が混在する場合のバス上の転送状態の時間的な遷移の様子を説明するための図である。
【図１７】ＩＥＥＥ１３９４シリアルインターフェースとＯＳＩモデルの対比を説明するための図である。
【図１８】ＬＯＧＩＮプロトコルの基本動作を説明するための図である。
【図１９】第１の実施の形態において、ＩＥＥＥ１３９４シリアルインターフェースにおける接続形態を説明するための図である。
【図２０】ログイン動作の流れを説明するための図である。
【図２１】ＬＯＧＩＮプロトコルのためにプリンタが備えるＣＳＲを説明するための図である。
【図２２】ホストデバイスで作成されるプリンタマップを説明するための図である。
【図２３】ＣＲＣアーキテクチャにおけるノードＩＤを説明するための図である。
【図２４】プリンタマップ作成のためのコマンドフォーマットを説明するための図である。
【図２５】ホストデバイスで実行されるプリンタマップ作成処理を説明するためのフローチャートである。
【図２６】上記プリンタマップ作成処理時にプリンタで実行される処理を説明するためのフローチャートである。
【図２７】ホストデバイスにおけるＬＯＧＩＮ処理を説明するためのフローチャートである。
【図２８】プリンタ（ターゲットデバイス）におけるＬＯＧＩＮ処理を説明するためのフローチャートである。
【図２９】第２の実施の形態において、ホストデバイスで実行されるプリンタマップ作成処理を説明するためのフローチャートである。
【図３０】上記プリンタマップ作成処理時にプリンタで実行される処理を説明するためのフローチャートである。
【図３１】第３の実施の形態において、システム動作を説明するための図である。
【図３２】ＯＳＩモデルとの対比を説明するための図である。
【図３３】第４の実施の形態において、プリンタ（ホストデバイス）で実行されるイメージ入力装置についてのマップ作成処理を説明するためのフローチャートである。
【図３４】上記マップ作成処理時にイメージ入力装置で実行される処理を説明するためのフローチャートである。
【符号の説明】
１ ＯＳＩモデルの物理層
２ データリンク層
３ 上位層
４ 上位層
５ トランスポートプロトコル層
６ プレゼンテーション層
７ ＬＯＧＩＮプロトコル
８ シリアルバスプロトコル（ＳＢＰ−２）
９ デバイスプロトコル
１１ プリンタ
１２ ＰＣ
１３ スキャナ
１４ ＶＣＲ
Claims (15)
- 共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理方法であって、
上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、
上記初期プロトコルに続いて、上記複数種類のデバイス固有のプロトコルを実行し、
上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する第１の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、上記第１の種類のデバイスに対してデータを出力する第２の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含むことを特徴とするデータ処理方法。 - 上記第１及び第２の調査処理は各々、デバイスの機能を調査する第３の調査処理を含み、
上記初期プロトコルは、上記第１の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第１の種類のデバイスに対する実行すべきプロトコルを決定する処理と、上記第２の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第２の種類のデバイスに対する実行すべきプロトコルを決定する処理とを含むことを特徴とする請求項１に記載のデータ処理方法。 - 上記第１の調査処理は、デバイスとしてのプリンタの状態及び能力を含む情報を得る処理を含み、
上記第２の調査処理は、デバイスとしてのイメージ入力装置の状態及び能力を含む情報を得る処理を含むことを特徴とする請求項１に記載のデータ処理方法。 - 上記プリンタに固有のプロトコルの実行後に、プリントすべき画像データを上記イメージ入力装置から上記プリンタに対して伝送することを特徴とする請求項３に記載のデータ処理方法。
- 上記共通シリアルバスは、ＩＥＥＥ１３９４規格に適合したバス、またはＵＳＢ規格に適合したバスであることを特徴とする請求項１に記載のデータ処理方法。
- 上記初期プロトコルは、ＯＳＩモデルのデータリンク層よりも上位の層で実行されるプロトコルであることを特徴とする請求項１に記載のデータ処理方法。
- 共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理装置であって、
上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行する第１の実行手段と、
上記初期プロトコルに続いて、上記複数種類のデバイス固有のプロトコルを実行する第２の実行手段とを備え、
上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する第１の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、上記第１の種類のデバイスに対してデータを出力する第２の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含むことを特徴とするデータ処理装置。 - 上記第１及び第２の調査処理は各々、デバイスの機能を調査する第３の調査処理を含み、
上記初期プロトコルは、上記第１の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第１の種類のデバイスに対する実行すべきプロトコルを決定する処理と、上記第２の調査処理で得られたトポロジ接続状態及び上記第３の調査処理で得られた複数のプロトコルに基づいて上記第２の種類のデバイスに対する実行すべきプロトコルを決定する処理とを含むことを特徴とする請求項７に記載のデータ処理装置。 - 上記第１の調査処理は、デバイスとしてのプリンタの状態及び能力を含む情報を得る処理を含み、
上記第２の調査処理は、デバイスとしてのイメージ入力装置の状態及び能力を含む情報を得る処理を含むことを特徴とする請求項７に記載のデータ処理装置。 - 上記第２の実行手段は、上記プリンタに固有のプロトコルの実行後に、プリントすべき画像データを上記イメージ入力装置から上記プリンタに対して伝送することを特徴とする請求項９に記載のデータ処理装置。
- 共通シリアルバスを介して複数のプロトコルをホストデバイスに対応して切り換えるプリンタであって、
上記プロトコルの種類に係わらない初期プロトコルを実行する実行手段と、
上記初期プロトコルに続いて、自機器に固有のプロトコルを実行した後、印字データを受信する受信手段とを備え、
上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する自機器についての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、自機器に対して画像データを出力するイメージ入力装置についての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含むことを特徴とするプリンタ。 - 共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるデータ処理ステップをコンピュータに実行させるためのプログラムを格納するコンピュータ読み取り可能な記憶媒体であって、
上記データ処理ステップは、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行する第１の実行ステップと、上記初期プロトコルに続いて、上記複数種類のデバイスに固有のプロトコルを実行する第２の実行ステップとを含み、
上記初期プロトコルは、上記共通シリアルバスによる同一ネットワーク上に存在する第１の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第１の調査処理を含むと共に、上記共通シリアルバスによる同一ネットワーク上に存在し、上記第１の種類のデバイスに対してデータを出力する第２の種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する第２の調査処理を含むことを特徴とするコンピュータ読み取り可能な記憶媒体。 - 共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理方法であって、
上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記共通シリアルバスによる同一ネットワーク上に存在し、上記複数種類のうちの少なくとも１種のデバイスに対してデータを出力する種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する調査処理を含むことを特徴とするデータ処理方法。 - 共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるためのデータ処理装置であって、
上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記共通シリアルバスによる同一ネットワーク上に存在し、上記複数種類のうちの少なくとも１種のデバイスに対してデータを出力する種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する調査処理手段を備えることを特徴とするデータ処理装置。 - 共通シリアルバスを介して複数種類のデバイスのプロトコルを切り換えるデータ処理ステップをコンピュータに実行させるためのプログラムを格納するコンピュータ読み取り可能な記憶媒体であって、
上記データ処理ステップは、上記デバイスのプロトコルの種類に係わらない初期プロトコルを実行し、上記共通シリアルバスによる同一ネットワーク上に存在し、上記複数種類のうちの少なくとも１種のデバイスに対してデータを出力する種類のデバイスについての当該共通シリアルバスを用いた接続形態を示すトポロジ接続状態を調査する調査処理ステップを含むことを特徴とするコンピュータ読み取り可能な記憶媒体。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP06366598A JP4058156B2 (ja) | 1998-03-13 | 1998-03-13 | データ処理方法、データ処理装置、プリンタ、及び記憶媒体 |
| EP99301968.6A EP0949782B1 (en) | 1998-03-13 | 1999-03-15 | Information processing apparatus and method |
| ES99301968.6T ES2546173T3 (es) | 1998-03-13 | 1999-03-15 | Aparato y procedimiento para el procesamiento de la información |
| US09/270,210 US6477589B1 (en) | 1998-03-13 | 1999-03-15 | Information processing apparatus and method |
| US10/222,017 US6745256B2 (en) | 1998-03-13 | 2002-08-15 | Information processing apparatus and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP06366598A JP4058156B2 (ja) | 1998-03-13 | 1998-03-13 | データ処理方法、データ処理装置、プリンタ、及び記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11259259A JPH11259259A (ja) | 1999-09-24 |
| JP4058156B2 true JP4058156B2 (ja) | 2008-03-05 |
Family
ID=13235875
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP06366598A Expired - Fee Related JP4058156B2 (ja) | 1998-03-13 | 1998-03-13 | データ処理方法、データ処理装置、プリンタ、及び記憶媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4058156B2 (ja) |
-
1998
- 1998-03-13 JP JP06366598A patent/JP4058156B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11259259A (ja) | 1999-09-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100298140B1 (ko) | 데이타통신장치및방법 | |
| JP3884862B2 (ja) | データ転送装置、データ転送装置の制御方法、記憶媒体 | |
| JP2000358033A (ja) | データ通信システム及びデータ通信方法 | |
| US6412076B1 (en) | Signal processing apparatus and image sensing apparatus | |
| JP3630971B2 (ja) | データ通信方法、装置、システム、及び記憶媒体 | |
| JP4463952B2 (ja) | 画像処理システム及びデジタルカメラと印刷装置及びその制御方法と記録媒体 | |
| JP3682512B2 (ja) | 画像取り込み装置及びその制御方法、印刷システム、印刷方法、及び、印刷装置及びその制御方法 | |
| JP4058156B2 (ja) | データ処理方法、データ処理装置、プリンタ、及び記憶媒体 | |
| JP3774542B2 (ja) | データ処理方法、データ処理装置、プリンタ及び記憶媒体 | |
| JP3897773B2 (ja) | 通信方法及び通信装置 | |
| JP3566495B2 (ja) | データ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体 | |
| JP3495879B2 (ja) | データ処理方法、データ処理装置、及びコンピュータ読み取り可能な記録媒体 | |
| JP3495878B2 (ja) | データ処理方法、データ処理装置及びプリンタ | |
| JP4463953B2 (ja) | 画像処理システム及びデジタルカメラとその制御方法 | |
| JP3647328B2 (ja) | 画像処理装置及びその制御方法並びに画像処理システム | |
| JP3943722B2 (ja) | データ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体 | |
| JP3535694B2 (ja) | データ転送装置およびその方法、並びに、画像処理装置 | |
| JP2000196873A (ja) | 情報処理装置及び情報処理システム及びそれらの方法と記憶媒体 | |
| JP2003333045A (ja) | パワーマネージメント | |
| AU762552B2 (en) | Data communication apparatus and method | |
| JP3517552B2 (ja) | データ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体 | |
| JPH11177589A (ja) | データ転送装置およびデータ転送装置のデータ処理方法およびコンピュータが読み出し可能なプログラムを格納した記憶媒体 | |
| JP2001257685A (ja) | 情報信号処理装置及び情報信号処理方法並びに記憶媒体 | |
| JPH11284649A (ja) | ネットワークシステム及びネットワーク管理装置及び方法 | |
| JPH11196099A (ja) | データ通信方法及び装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041130 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041130 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061127 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070720 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070731 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071001 |
|
| 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: 20071211 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071217 |
|
| 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: 20101221 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111221 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121221 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131221 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |