(57)【特許請求の範囲】
【請求項１】
シリアルバスにより接続される画像供給デバイスとターゲットデバイスとの間で利用されるデータ転送方法であって、
前記ターゲットデバイスのリソースを前記画像供給デバイスに固定し、
前記リソースの固定後、前記画像供給デバイスと前記ターゲットデバイスとの双方向通信において、前記画像供給デバイスと前記ターゲットデバイスとの間で利用可能なデータ転送方式を判別し、
前記画像供給デバイスの発行する要求に基づいて、前記ターゲットデバイスに設定されるデータ転送方式を、少なくとも、プッシュ方式又はプル方式のいずれかに設定し、
前記データ転送方式が前記プル方式に設定された場合に、前記ターゲットデバイスの発行する要求に基づいて前記画像供給デバイスからデータが読み出されるように制御し、
前記データの転送中は、前記ターゲットデバイスは前記画像供給デバイス以外の装置からの制御を受付けずに、前記データの転送後に前記画像供給デバイスの要求に基づき、前記リソースの固定を解除することを特徴とするデータ転送方法。
【請求項２】
ターゲットデバイスとシリアルバスで接続されるデータ転送装置であって、
前記ターゲットデバイスのリソースが前記データ転送装置に固定された後、前記ターゲットデバイスとの間で双方向通信を行う通信手段と、
前記双方向通信により、前記ターゲットデバイスとの間で利用可能なデータ転送方式を判別し、前記データ転送装置の発行する要求に基づいて、前記ターゲットデバイスに設定されるデータ転送方式として、少なくとも、プッシュモデル又はプルモデルのいずれかを設定する設定手段とを有し、
前記通信手段は、前記データ転送方式が前記プル方式に設定された場合に、前記ターゲットデバイスの発行する要求に基づいて前記データ転送装置からデータが読み出され、前記データの転送後に前記データ転送装置の要求に基づき、前記リソースの固定を解除することを特徴とするデータ転送装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体に関し、例えば、ＩＥＥＥ１３９４などにより規定されるシリアルインタフェイスを介して、ディジタルカメラなどの画像供給デバイスとプリンタなどの画像処理デバイスとを直結する場合のデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体に関するものである。
【０００２】
【従来の技術】
プリンタは、セントロニクスやＲＳ２３２Ｃと言ったパラレルあるいはシリアルインタフェイスを介して、ホストデバイスであるパーソナルコンピュータ（ＰＣ）と接続されている。
【０００３】
また、スキャナ、ディジタルスチルカメラ、ディジタルビデオカメラといった画像供給デバイスであるディジタル機器もＰＣに接続されている。各ディジタル機器により取込まれた画像データは、一旦ＰＣ上のハードディスクなどに取込まれた後、ＰＣ上のアプリケーションソフトウェアなどにより処理されてプリンタ用の印刷データに変換され、上記のインタフェイスを経由してプリンタに送られる。
【０００４】
上記のようなシステムでは、各ディジタル機器やプリンタなどを制御するためのドライバソフトウェアがそれぞれ独立にＰＣに存在し、ディジタル機器から出力された画像データは、それらドライバソフトウェアによりＰＣ上で使い易くかつ表示し易い形式のデータとして保存される。保存されたデータは、入力機器の画像特性と出力機器の画像特性とを考慮した画像処理方法により印刷データに変換される。
【０００５】
今日、ＩＥＥＥ１３９４により規定されるインタフェイス（以下「１３９４シリアルバス」と呼ぶ）のような新しいインタフェイスでは、画像供給デバイスとプリンタとを直結することも可能である。１３９４シリアルバスにより画像供給デバイスとプリンタとを直結する場合、ＦＣＰ（Ｆｕｎｃｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）のオペランドに印刷データを含める方法が考えられる。また、１３９４シリアルバスでは、データ転送のためのレジスタ領域を設けて、そのレジスタ領域にデータを書込むことでデータ転送を行う方法も考えられる。
【０００６】
また、１３９４シリアルバスには、データ転送用の制御手順として複数の方法があり、それぞれの機器に適した方式によるデータ転送を行うことができる。
【０００７】
【発明が解決しようとする課題】
しかし、上述した技術においては、次のような問題点がある。
前述したように、画像供給デバイスから出力される画像データは、ＰＣにより印刷データに変換されてプリンタにより印刷されるものであるから、画像供給デバイスとプリンタを直結したとしても、ＰＣが無ければ印刷を行うことができない。ディジタルビデオカメラから出力される画像データを直接印刷するビデオプリンタと呼ばれるプリンタもあるが、特定の機種間で接続ができるだけであり、多数の画像供給デバイスと直結して使える汎用性の高いビデオプリンタはない。つまり、１３９４シリアルバスなどの特徴であるデバイス間を直結する機能を生かし、画像供給デバイスからプリンタへ画像データを直接送って印刷することはできない。
【０００８】
１３９４シリアルバスにより画像供給デバイスとプリンタを直結し、ＦＣＰのオペランドに印刷データを含める前述した方法は、制御コマンドと印刷データとを分離することができない問題がある上、コマンドに対して常にレスポンスが必要なため転送効率が低いという問題もある。また、前述したデータ転送のためのレジスタ領域を設ける方法は、そのレジスタ領域にデータを書込むことが可能であるかどうかを判定するための処理がデータ転送の度に必要になる。従って、この判定処理のオーバヘッドが大きくなり、やはり転送効率が低下するという問題が発生する。
【０００９】
また、多種類のデバイスとの間の接続性を確保するためには、各種デバイスに適したデータ転送方式が存在するので、それら複数のデータ転送方式が必要になる。
【００１０】
また、データ転送方式には、ホストデバイスからターゲットデバイスへデータを書込むプッシュ（ＰＵＳＨ）方式と、ターゲットデバイスがホストデバイスのデータを読込むプル（ＰＵＬＬ）方式の二つの基本的な方式があり、両デバイスが有するリソースにより何れかのデータ転送方式が決まることになる。しかし、多種類のデバイスを直結することを考慮すると、データ転送方式をプッシュ方式あるいはプル方式の何れかに決めることはできない。
【００１１】
本発明は、上述した問題を個々にまたはまとめて解決するためのものであり、１３９４シリアルバスなどによりホストデバイスとターゲットデバイスを直結し、ホストデバイスから直接ターゲットデバイスへ送られる画像データの処理をターゲットデバイスに行わせるのに適したデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体を提供することを目的とする。
【００１２】
また、制御コマンドとデータの分離が可能で転送効率のよいデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体を提供することを他の目的とする。
【００１３】
また、接続するデバイスに合ったデータ転送方法を設定することができるデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体を提供することを他の目的とする。
【００１４】
また、プル（ＰＵＬＬ）方式によるデータ転送を行うことができるデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体を提供することを他の目的とする。
【００１５】
【課題を解決するための手段】
本発明は、前記の目的を達成する一手段として、以下の構成を備える。
【００１７】
本発明にかかるデータ転送方法は、シリアルバスにより接続される画像供給デバイスとターゲットデバイスとの間で利用されるデータ転送方法であって、前記ターゲットデバイスのリソースを前記画像供給デバイスに固定し、前記リソースの固定後、前記画像供給デバイスと前記ターゲットデバイスとの双方向通信において、前記画像供給デバイスと前記ターゲットデバイスとの間で利用可能なデータ転送方式を判別し、前記画像供給デバイスの発行する要求に基づいて、前記ターゲットデバイスに設定されるデータ転送方式を、少なくとも、プッシュ方式又はプル方式のいずれかに設定し、前記データ転送方式が前記プル方式に設定された場合に、前記ターゲットデバイスの発行する要求に基づいて前記画像供給デバイスからデータが読み出されるように制御し、前記データの転送中は、前記ターゲットデバイスは前記画像供給デバイス以外の装置からの制御を受付けずに、前記データの転送後に前記画像供給デバイスの要求に基づき、前記リソースの固定を解除することを特徴とする。
【００１９】
本発明にかかるデータ転送装置は、ターゲットデバイスとシリアルバスで接続されるデータ転送装置であって、前記ターゲットデバイスのリソースが前記データ転送装置に固定された後、前記ターゲットデバイスとの間で双方向通信を行う通信手段と、前記双方向通信により、前記ターゲットデバイスとの間で利用可能なデータ転送方式を判別し、前記データ転送装置の発行する要求に基づいて、前記ターゲットデバイスに設定されるデータ転送方式として、少なくとも、プッシュモデル又はプルモデルのいずれかを設定する設定手段とを有し、前記通信手段は、前記データ転送方式が前記プル方式に設定された場合に、前記ターゲットデバイスの発行する要求に基づいて前記データ転送装置からデータが読み出され、前記データの転送後に前記データ転送装置の要求に基づき、前記リソースの固定を解除することを特徴とする。
【００２１】
【発明の実施の形態】
以下、本発明にかかる一実施形態のデータ転送方法を図面を参照して詳細に説明する。
【００２２】
図１は本発明を適用するシステムの一般的な構成例を示す図で、ＰＣ１０３、プリンタ１０２およびディジタルビデオカメラ（ＤＶＣ）１０１を１３９４シリアルバスを用いて接続するものである。そこで、予め、１３９４シリアルバスの概要を説明をする。
【００２３】
【ＩＥＥＥ１３９４の概要】
家庭用ディジタルＶＴＲやディジタルビデオディスク（ＤＶＤ）の登場に伴い、ビデオデータやオーディオデータ（以下、まとめて「ＡＶデータ」と呼ぶ）など、リアルタイムかつ情報量の多いデータを転送する必要が生じている。ＡＶデータをリアルタイムに、ＰＣへ転送したり、その他のディジタル機器に転送するには、高速のデータ転送能力をもつインタフェイスが必要になる。そういった観点から開発されたインタフェイスが１３９４シリアルバスである。
【００２４】
図２に１３９４シリアルバスを用いて構成されるネットワークシステムの例を示す。このシステムは機器ＡからＨを備え、Ａ−Ｂ間、Ａ−Ｃ間、Ｂ−Ｄ間、Ｄ−Ｅ間、Ｃ−Ｆ間、Ｃ−Ｇ間、およびＣ−Ｈ間がそれぞれ１３９４シリアルバス用のツイストペアケーブルで接続されている。これらの機器ＡからＨの例としては、パソコンなどのホストコンピュータ装置、および、コンピュータ周辺機器である。コンピュータ周辺機器としては、ディジタルＶＣＲ、ＤＶＤプレーヤ、ディジタルスチルカメラ、ハードディスクや光ディスクなどのメディアを用いる記憶装置、ＣＲＴやＬＣＤのモニタ、チューナ、イメージスキャナ、フィルムスキャナ、プリンタ、ＭＯＤＥＭ、ターミナルアダプタ（ＴＡ）などコンピュータ周辺機器のすべてが対象になる。なお、プリンタの記録方式は、レーザビームやＬＥＤを用いた電子写真方式、インクジェット方式、インク溶融型や昇華型の熱転写方式、感熱記録方式など、どんな方式でも構わない。
【００２５】
各機器間の接続は、ディジーチェーン方式とノード分岐方式との混在が可能であり、自由度の高い接続を行うことができる。また、各機器はそれぞれＩＤを有し、互いにＩＤを認識し合うことによって、１３９４シリアルバスで接続された範囲において、一つのネットワークを構成している。例えば、各機器間をそれぞれ一本の１３９４シリアルバス用ケーブルでディジーチェーン接続するだけで、それぞれの機器が中継の役割を担うので、全体として一つのネットワークを構成することができる。
【００２６】
また、１３９４シリアルバスはＰｌｕｇ  ａｎｄ  Ｐｌａｙ機能に対応し、１３９４シリアルバス用ケーブルを機器に接続するだけで自動的に機器を認識し、接続状況を認識する機能を有している。また、図２に示すようなシステムにおいて、ネットワークからある機器が外されたり、または新たに加えられたときなど、自動的にバスをリセット（それまでのネットワークの構成情報をリセット）して、新たなネットワークを再構築する。この機能によって、その時々のネットワークの構成を常時設定、認識することができる。
【００２７】
また、１３９４シリアルバスのデータ転送速度は、１００／２００／４００Ｍｂｐｓが定義されていて、上位の転送速度をもつ機器が下位の転送速度をサポートすることで、互換性が保たれている。データ転送モードとしては、コントロール信号などの非同期データを転送する非同期（Ａｓｙｎｃｈｒｏｎｏｕｓ）転送モード（ＡＴＭ）と、リアルタイムなＡＶデータ等の同期データを転送する同期（Ｉｓｏｃｈｒｏｎｏｕｓ）転送モードがある。この非同期データと同期データは、各サイクル（通常１２５μｓ／サイクル）の中で、サイクル開始を示すサイクルスタートパケット（ＣＳＰ）の転送に続き、同期データの転送を優先しつつ、サイクル内で混在して転送される。
【００２８】
図３は１３９４シリアルバスの構成例を示す図である。１３９４シリアルバスはレイヤ構造で構成されている。図３に示すように、コネクタポート８１０には、１３９４シリアルバス用のケーブル８１３の先端のコネクタが接続される。コネクタポート８１０の上位には、ハードウェア部８００で構成されるフィジカルレイヤ８１１とリンクレイヤ８１２がある。ハードウェア部８００はインタフェイス用チップで構成され、そのうちフィジカルレイヤ８１１は符号化やコネクション関連の制御等を行い、リンクレイヤ８１２はパケット転送やサイクルタイムの制御等を行う。
【００２９】
ファームウェア部８０１のトランザクションレイヤ８１４は、転送（トランザクション）すべきデータの管理を行い、Ｒｅａｄ、Ｗｒｉｔｅ、Ｌｏｃｋの命令を出す。ファームウェア部８０１のマネージメントレイヤ８１５は、１３９４シリアルバスに接続されている各機器の接続状況やＩＤの管理を行い、ネットワークの構成を管理する。上記のハードウェアとファームウェアまでが、１３９４シリアルバスの実質的な構成である。
【００３０】
また、ソフトウェア部８０２のアプリケーションレイヤ８１６は、利用されるソフトによって異なり、インタフェイス上でどのようにしてデータを転送するかは、プリンタやＡＶ／Ｃプロトコルなどのプロトコルによって定義される。
【００３１】
図４は１３９４シリアルバスにおけるアドレス空間の一例を示す図である。１３９４シリアルバスに接続された各機器（ノード）には必ずノードに固有の６４ビットアドレスをもたせる。そして、このアドレスは機器のメモリに格納されていて、自分や相手のノードアドレスを常時認識することで、通信相手を指定したデータ通信を行うことができる。
【００３２】
１３９４シリアルバスのアドレッシングは、ＩＥＥＥ１２１２規格に準じた方式であり、アドレス設定は、最初の１０ビットがバスの番号の指定用に、次の６ビットがノードＩＤの指定用に使われる。
【００３３】
それぞれの機器内で使用される４８ビットのアドレスについても、２０ビットと２８ビットに分けられ、２５６Ｍバイト単位の構造をもって利用される。最初の２０ビットのアドレス空間のうち０〜０ｘＦＦＦＦＤはメモリ空間、０ｘＦＦＦＦＥはプライベート空間、０ｘＦＦＦＦＦはレジスタ空間とそれぞれ呼ばれる。プライベート空間は機器内で自由に利用できるアドレスであり、レジスタ空間にはバスに接続された機器間で共通な情報が置かれ、各機器間のコミュニケーションに使われる。
【００３４】
レジスタ空間の、最初の５１２バイトにはＣＳＲアーキテクチャのコアになるレジスタ（ＣＳＲコア）が、次の５１２バイトにはシリアルバスのレジスタが、その次の１０２４バイトにはコンフィグレーションＲＯＭが、残りはユニット空間で機器固有のレジスタが、それぞれ置かれる。
【００３５】
一般的には異種バスシステムの設計の簡略化のため、ノードは初期ユニット空間の最初の２０４８バイトだけを使うべきであり、この結果としてＣＳＲコア、シリアルバスのレジスタ、コンフィグレーションＲＯＭおよびユニット空間の最初の２０４８バイトを合わせて４０９６バイトで構成することが望ましい。
【００３６】
以上が、１３９４シリアルバスの概要である。次に、１３９４シリアルバスの特徴をより詳細に説明する。
【００３７】
【１３９４シリアルバスの詳細】
［１３９４シリアルバスの電気的仕様］
図５は１３９４シリアルバス用のケーブルの断面を示す図である。１３９４シリアルバス用ケーブルには、二組のツイストペア信号線の他に、電源ラインが設けられている。これによって、電源を持たない機器や、故障などにより電圧が低下した機器にも電力の供給が可能になる。電源線により供給される直流電力の電圧は８〜４０Ｖ、電流は最大電流１．５Ａに規定されている。なお、ＤＶケーブルと呼ばれる規格では、電源ラインを省いた四線で構成される。
【００３８】
［ＤＳ−Ｌｉｎｋ方式］
図６は１３９４シリアルバスで採用されている、データ転送方式のＤＳ−Ｌｉｎｋ（Ｄａｔａ／Ｓｔｒｏｂｅ  Ｌｉｎｋ）方式を説明するための図である。
【００３９】
ＤＳ−Ｌｉｎｋ方式は、高速なシリアルデータ通信に適し、二組の信号線を必要とする。つまり、二組のより対線のうち一組でデータ信号を送り、もう一組でストローブ信号を送る構成になっている。受信側では、このデータ信号と、ストローブ信号との排他的論理和をとることによってクロックを生成することができるという特徴がある。このため、ＤＳ−Ｌｉｎｋ方式を用いると、データ信号中にクロック信号を混入させる必要がないので他のシリアルデータ転送方式に比べて転送効率が高い、クロック信号を生成できるので位相ロックドループ（ＰＬＬ）回路が不要になり、その分コントローラＬＳＩの回路規模を小さくすることができる。さらに、転送すべきデータが無いときにアイドル状態であることを示す情報を送る必要が無いので、各機器のトランシーバ回路をスリープ状態にすることができ、消費電力の低減が図れる、などが挙げられる。
【００４０】
［バスリセットのシーケンス］
１３９４シリアルバスに接続されている各機器（ノード）にはノードＩＤが与えられ、ネットワークを構成するノードとして認識される。例えば、ネットワーク機器の接続分離や電源のオン／オフなどによるノード数の増減、つまりネットワーク構成に変化があり、新たなネットワーク構成を認識する必要があるとき、その変化を検知した各ノードはバス上にバスリセット信号を送信して、新たなネットワーク構成を認識するモードに入る。このネットワーク構成の変化の検知は、コネクタポート８１０においてバイアス電圧の変化を検知することによって行われる。
【００４１】
あるノードからバスリセット信号が送信されると、各ノードのフィジカルレイヤ８１１はこのバスリセット信号を受けると同時にリンクレイヤ８１２にバスリセットの発生を伝達し、かつ他のノードにバスリセット信号を伝達する。最終的にすべてのノードがバスリセット信号を受信した後、バスリセットのシーケンスが起動される。なお、バスリセットのシーケンスは、ケーブルが抜き挿しされた場合や、ネットワークの異常等をハードウェアが  検出した場合に起動されるとともに、プロトコルによるホスト制御などフィジカルレイヤ８１１に直接命令を与えることによっても起動される。また、バスリセットのシーケンスが起動されると、データ転送は、一時中断され、バスリセットの間は待たされ、バスリセット終了後、新しいネットワーク構成の基で再開される。
【００４２】
［ノードＩＤ決定のシーケンス］
バスリセットの後、各ノードは新しいネットワーク構成を構築するために、各ノードにＩＤを与える動作に入る。このときの、バスリセットからノードＩＤ決定までの一般的なシーケンスを図７から図９に示すフローチャートを用いて説明する。
【００４３】
図７は、バスリセット信号の発生から、ノードＩＤが決定し、データ転送が行えるようになるまでの一連のシーケンス例を示すフローチャートである。各ノードは、ステップＳ１０１でバスリセット信号の発生を常時監視し、バスリセット信号が発生するとステップＳ１０２に移り、ネットワーク構成がリセットされた状態において新たなネットワーク構成を得るために、互いに直結されているノード間で親子関係が宣言される。そしてステップＳ１０３の判定により、すべてのノード間で親子関係が決ったと判定されるまでステップＳ１０２が繰り返される。
【００４４】
親子関係が決定するとステップＳ１０４へ進みルート（ｒｏｏｔ）ノードが決定され、ステップＳ１０５で各ノードにＩＤを与えるノードＩＤの設定作業が行われる。ルートノードから所定のノード順にノードＩＤの設定が行われ、ステップＳ１０６の判定により、すべてのノードにＩＤが与えられたと判定されるまでステップＳ１０５が繰り返される。
【００４５】
ノードＩＤの設定が終了すると、新しいネットワーク構成がすべてのノードにおいて認識されたことになるのでノード間のデータ転送が行える状態になり、ステップＳ１０７でデータ転送が開始されるとともに、シーケンスはステップＳ１０１へ戻り、再びバスリセット信号の発生が監視される。
【００４６】
図８はバスリセット信号の監視（Ｓ１０１）からルートノードの決定（Ｓ１０４）までの詳細例を示すフローチャート、図９はノードＩＤ設定（Ｓ１０５，Ｓ１０６）の詳細例を示すフローチャートである。
【００４７】
図８において、ステップＳ２０１でバスリセット信号の発生が監視され、バスリセット信号が発生すると、ネットワーク構成は一旦リセットされる。次に、ステップＳ２０２で、リセットされたネットワーク構成を再認識する作業の第一歩として、各機器はフラグＦＬをリーフノードであることを示すデータでリセットする。そして、ステップＳ２０３で、各機器はポート数、つまり自分に接続されている他ノードの数を調べ、ステップＳ２０４で、ステップＳ２０３の結果に応じて、これから親子関係の宣言を始めるために、未定義（親子関係が決定されていない）ポートの数を調べる。ここで、未定義ポート数は、バスリセットの直後はポート数に等しいが、親子関係が決定されて行くにしたがって、ステップＳ２０４で検知される未定義ポートの数は減少する。
【００４８】
バスリセットの直後に親子関係の宣言を行えるのは実際のリーフノードに限られている。リーフノードであるか否かはステップＳ２０３のポート数の確認結果から知ることができ、つまりポート数が「１」であればリーフノードである。リーフノードは、ステップＳ２０５で、接続相手のノードに対して親子関係の宣言「自分は子、相手は親」を行い動作を終了する。
【００４９】
一方、ステップＳ２０３でポート数が「２以上」であったノード、つまりブランチノードは、バスリセットの直後は「未定義ポート数＞１」であるからステップＳ２０６へ進み、フラグＦＬにブランチノードを示すデータをセットし、ステップＳ２０７で他ノードから親子関係が宣言されるのを待つ。他ノードから親子関係が宣言され、それを受けたブランチノードはステップＳ２０４に戻り、未定義ポート数を確認するが、もし未定義ポート数が「１」になっていれば残るポートに接続された他ノードに対して、ステップＳ２０５で「自分は子、相手は親」の親子関係を宣言することができる。また、未だ未定義ポート数が「２以上」あるブランチノードは、ステップＳ２０７で再び他ノードから親子関係が宣言されるのを待つことになる。
【００５０】
何れか一つのブランチノード（または例外的に、子宣言を行えるのにもかかわらず、すばやく動作しなかったリーフノード）の未定義ポート数が「０」になると、ネットワーク全体の親子関係の宣言が終了したことになり、未定義ポート数が「０」になった唯一のノード、つまりすべてノードの親に決まったノードは、ステップＳ２０８でフラグＦＬにルートノードを示すデータをセットし、ステップＳ２０９でルートノードとして認識される。
【００５１】
このようにして、バスリセットから、ネットワーク内のすべてのノード間における親子関係の宣言までの手順が終了する。
【００５２】
次に、各ノードにＩＤを与える手順を説明するが、最初にＩＤの設定を行うことができるのはリーフノードである。そして、リーフ→ブランチ→ルートの順に若い番号（ノード番号：  ０）からＩＤを設定する。
【００５３】
図９のステップＳ３０１で、フラグＦＬに設定されたデータを基にノードの種類、つまりリーフ、ブランチおよびルートに応じた処理に分岐する。
【００５４】
まずリーフノードの場合は、ステップＳ３０２でネットワーク内に存在するリーフノードの数（自然数）を変数Ｎに設定した後、ステップＳ３０３で各リーフノードがルートノードに対して、ノード番号を要求する。この要求が複数ある場合、ルートノードはステップＳ３０４でアービトレーションを行い、ステップＳ３０５である一つのノードにノード番号を与え、他のノードにはノード番号の取得失敗を示す結果を通知する。
【００５５】
ステップＳ３０６の判断により、ノード番号を取得できなかったリーフノードは、再びステップＳ３０３でノード番号の要求を繰り返す。一方、ノード番号を取得できたリーフノードは、ステップＳ３０７で、取得したノード番号を含むＩＤ情報をブロードキャストすることで全ノードに通知する。ＩＤ情報のブロードキャストが終わるとステップＳ３０８で、リーフ数を表す変数Ｎがデクリメントされる。そして、ステップＳ３０９の判定により変数Ｎが「０」になるまでステップＳ３０３からＳ３０８の手順が繰り返され、すべてのリーフノードのＩＤ情報がブロードキャストされた後、ステップＳ３１０へ進んで、ブランチノードのＩＤ設定に移る。
【００５６】
ブランチノードのＩＤ設定もリーフノードとほぼ同様に行われる。まず、ステップＳ３１０でネットワーク内に存在するブランチノードの数（自然数）を変数Ｍに設定した後、ステップＳ３１１で各ブランチノードがルートノードに対して、ノード番号を要求する。この要求に対してルートノードは、ステップＳ３１２でアービトレーションを行い、ステップＳ３１３である一つのブランチノードにリーフノードに続く若い番号を与え、ノード番号を取得できなかったブランチノードには取得失敗を示す結果を通知する。
【００５７】
ステップＳ３１４の判定により、ノード番号の取得に失敗したことを知ったブランチノードは、再びステップＳ３１１でノード番号の要求を繰り返す。一方、ノード番号を取得できたブランチノードはステップＳ３１５で、取得したノード番号を含むＩＤ情報をブロードキャストすることで全ノードに通知する。ＩＤ情報のブロードキャストが終わるとステップＳ３１６で、ブランチ数を表す変数Ｍがデクリメントされる。そして、ステップＳ３１７の判定により、変数Ｍが「０」になるまでステップＳ３１１からＳ３１６の手順が繰返され、すべてのブランチノードのＩＤ情報がブロードキャストされた後、ステップＳ３１８へ進んで、ルートノードのＩＤ設定に移る。
【００５８】
ここまで終了すると、最終的にＩＤを取得していないノードはルートノードのみなので、ステップＳ３１８では、他のノードに与えていない最も若い番号を自分のノード番号に設定し、ステップＳ３１９でルートノードのＩＤ情報をブロードキャストする。
【００５９】
以上で、すべてのノードのＩＤが設定されるまでの手順が終了する。次に、図１０に示すネットワーク例を用いてノードＩＤ決定のシーケンスの具体的な手順を説明する。
【００６０】
図１０に示すネットワークは、ルートであるノードＢの下位にはノードＡとノードＣが直結され、ノードＣの下位にはノードＤが直結され、ノードＤの下位にはノードＥとノードＦが直結された階層構造を有する。この、階層構造やルートノード、ノードＩＤを決定する手順は以下のようになる。
【００６１】
バスリセットが発生した後、各ノードの接続状況を認識するために、各ノードの直結されているポート間において、親子関係の宣言がなされる。ここでいう親子とは、階層構造の上位が「親」、下位が「子」という意味である。図１０では、バスリセットの後、最初に親子関係を宣言したのはノードＡである。前述したように、一つのポートだけが接続されたノード（リーフ）から親子関係の宣言を開始することができる。これは、ポート数が「１」であればネットワークツリーの末端、つまりリーフノードであることが認識され、それらリーフノードの中で最も早く動作を行ったノードから親子関係が決定されて行くことになる。こうして親子関係の宣言を行ったノードのポートが、互いに接続された二つのノードの「子」と設定され、相手ノードのノードが「親」と設定される。こうして、ノードＡ−Ｂ間、ノードＥ−Ｄ間、ノードＦ−Ｄ間で「子−親」の関係が設定される。
【００６２】
さらに、階層が一つ上がって、複数のポートをもつノード、つまりブランチノードのうち他ノードから親子関係の宣言を受けたノードから順次、上位のノードに対して親子関係を宣言する。図１０ではまずノードＤ−Ｅ間、Ｄ−Ｆ間の親子関係が決定された後、ノードＤがノードＣに対して親子関係を宣言し、その結果、ノードＤ−Ｃ間で「子−親」の関係が設定される。ノードＤから親子関係の宣言を受けたノードＣは、もう一つのポートに接続されているノードＢに対して親子関係を宣言し、これによってノードＣ−Ｂ間で「子−親」の関係が設定される。
【００６３】
このようにして、図１０に示すような階層構造が構成され、最終的に接続されているすべてのポートにおいて親となったノードＢが、ルートノードと決定される。なお、ルートノードは一つのネットワーク構成中に一つしか存在しない。また、ノードＡから親子関係を宣言されたノードＢが、速やかに、他のノードに対して親子関係を宣言した場合は、例えばノードＣなどの他のノードがルートノードになる可能性もあり得る。すなわち、親子関係の宣言が伝達されるタイミングによっては、どのノードもルートノードになる可能性があり、ネットワーク構成が同一であっても、特定のノードがルートノードになるとは限らない。
【００６４】
ルートノードが決定されると、各ノードＩＤの決定モードに入る。すべてのノードは、決定した自分のＩＤ情報を、他のすべてのノードに通知するプロードキャスト機能をもっている。なお、ＩＤ情報は、ノード番号、接続されている位置の情報、もっているポートの数、接続のあるポートの数、各ポートの親子関係の情報などを含むＩＤ情報としてブロードキャストされる。
【００６５】
ノード番号の割当ては、前述したようにリーフノードから開始され、順に、ノード番号＝０，１，２，…が割当てられる。そしてＩＤ情報のブロードキャストによって、そのノード番号は割当て済みであることが認識される。
【００６６】
すべてのリーフノードがノード番号を取得し終わると、次はブランチノードへ移りリーフノードに続くノード番号が割当てられる。リーフノードと同様に、ノード番号が割当てられたブランチノードから順にＩＤ情報がブロードキャストされ、最後にルートノードが自己のＩＤ情報をブロードキャストする。従って、ルートノードは常に最大のノード番号を所有することになる。
【００６７】
以上のようにして、階層構造全体のＩＤ設定が終わり、ネットワーク構成が構築され、バスの初期化作業が完了する。
【００６８】
［ノード管理のための制御情報］
ノード管理を行うためのＣＳＲアーキテクチャの基本的な機能として、図４に示したＣＳＲコアがレジスタ上に存在する。それらレジスタの位置と機能を図１１に示すが、図中のオフセットは０ｘＦＦＦＦＦ０００００００からの相対位置である。
【００６９】
ＣＳＲアーキテクチャでは、０ｘＦＦＦＦＦ００００２００からシリアルバスに関するレジスタが配置されている。それらのレジスタの位置と機能を図１２に示す。
【００７０】
また、０ｘＦＦＦＦＦ００００８００から始まる場所には、シリアルバスのノード資源に関する情報が配置されている。それらのレジスタの位置と機能を図１３に示す。
【００７１】
ＣＳＲアーキテクチャでは、各ノードの機能を表すためコンフィグレーションＲＯＭをもっているが、このＲＯＭには最小形式と一般形式があり、０ｘＦＦＦＦＦ００００４００から配置される。最小形式では図１４に示すようにベンダＩＤを表すだけであり、このベンダＩＤは２４ビットで表される全世界で固有の値である。
【００７２】
また、一般形式は図１５に示すような形式で、ノードに関する情報をもっているが、この場合、ベンダＩＤはルートディレクトリ（ｒｏｏｔ＿ｄｉｒｅｃｔｏｒｙ）にもつことができる。また、バス情報ブロック（ｂｕｓ  ｉｎｆｏ  ｂｌｏｃｋ）とルートリーフ（ｒｏｏｔ  ｌｅａｆ）にはベンダＩＤを含む６４ビットの全世界で固有な装置番号をもっている。この装置番号は、バスリセットなどの再構成後に継続してノードを認識するために使用される。
【００７３】
［シリアルバス管理］
１３９４シリアルバスのプロトコルは、図３に示したように、フィジカルレイヤ８１１、リンクレイヤ８１２およびトランザクションレイヤ８１４から構成されている。この中で、バス管理は、ＣＳＲアーキテクチャに基づくノードの制御とバス資源管理のための基本的な機能を提供している。
【００７４】
バス管理を行うノード（以下「バス管理ノード」と呼ぶ）は、同一バス上に唯一存在し、シリアルバス上の他のノードに管理機能を提供するが、この管理機能にはサイクルマスタの制御や、性能の最適化、電源管理、伝送速度管理、構成管理などがある。
【００７５】
バス管理機能は、バスマネージャ、同期（アイソクロノス）リソースマネージャおよびノード制御の三つの機能に大きく別けられる。ノード制御は、ＣＳＲによってフィジカルレイヤ８１１、リンクレイヤ８１２、トランザクションレイヤ８１４およびアプリケーションにおけるノード間通信を可能にする管理機能である。同期リソースマネージャは、シリアルバス上で同期型のデータ転送を行うために必要になる管理機能で、同期データの転送帯域幅とチャネル番号の割当てを管理するものである。この管理を行うためにバス管理ノードは、バスの初期化後に、同期リソースマネージャ機能をもつノードの中から動的に選出される。
【００７６】
また、バス上にバス管理ノードが存在しない構成では、電源管理やサイクルマスタの制御のようなバス管理の一部の機能を同期リソースマネージャ機能をもつノードが行う。さらにバス管理は、アプリケーションに対してバス制御のインタフェイスを提供するサービスを行う管理機能であり、その制御インタフェイスにはシリアルバス制御要求（ＳＢ＿ＣＯＮＴＲＯＬ．ｒｅｑｕｅｓｔ）、シリアルバスイベント制御確認（ＳＢ＿ＣＯＮＴＲＯＬ．ｃｏｎｆｉｒｍａｔｉｏｎ）、シリアルバスイベント通知（ＳＢ＿ＥＶＥＮＴ．ｉｎｄｉｃａｔｉｏｎ）がある。
【００７７】
シリアルバス制御要求は、バスのリセット、バスの初期化、バスの状態情報などを、アプリケーションからバス管理ノードに要求する場合に利用される。シリアルバスイベント制御確認は、シリアルバス制御要求の結果で、バス管理ノードからアプリケーションに確認通知される。シリアルバスイベント通知は、バス管理ノードからアプリケーションに対して、非同期に発生されるイベントを通知するためのものである。
【００７８】
［データ転送プロトコル］
１３９４シリアルバスのデータ転送は、周期的に送信する必要のある同期データ（同期パケット）と、任意タイミングのデータ送受信が許容される非同期データ（非同期パケット）とが同時に存在し、なおかつ、同期データのリアルタイム性を保証している。データ転送では、転送に先立ってバス使用権を要求し、バスの使用許可を得るためのバスアービトレーションが行われる。
【００７９】
非同期転送においては、送信ノードＩＤおよび受信ノードＩＤが転送データと一緒にパケットデータとして送られる。受信ノードは、自分のノードＩＤを確認してパケットを受取るとアクノリッジ信号を送信ノードに返すことで、一つのトランザクショが完了する。
【００８０】
同期転送においては、送信ノードが伝送速度とともに同期チャネルを要求し、チャネルＩＤが転送データと一緒にパケットデータとして送られる。受信ノードは、所望するチャネルＩＤを確認してデータパケットを受取る。必要になるチャネル数と伝送速度はアプリケーションレイヤ８１６で決定される。
【００８１】
これらのデータ転送プロトコルは、フィジカルレイヤ８１１、リンクレイヤ８１２およびトランザクションレイヤ８１４の三つのレイヤによって定義される。フィジカルレイヤ８１１は、バスとの物理的・電気的インタフェイス、ノード接続の自動認識、ノード間のバス使用権のバスアービトレーションなどを行う。リンクレイヤ８１２は、アドレッシング、データチェック、パケット送受信、そして同期転送のためのサイクル制御を行う。トランザクションレイヤ８１４は、非同期データに関する処理を行う。以下、各レイヤにおける処理について説明する。
【００８２】
［フィジカルレイヤ］
次に、フィジカルレイヤ８１１におけるバスアービトレーションを説明する。
【００８３】
１３９４シリアルバスは、データ転送に先立って、必ず、バス使用権のアービトレーションを行う。１３９４シリアルバスに接続された各機器は、ネットワーク上を転送される信号をそれぞれ中継することによって、ネットワーク内のすべての機器に同信号を伝える論理的なバス型ネットワークを構成するので、パケットの衝突を防ぐ意味でバスアービトレーションが必要である。これによって、ある時間には、一つのノードだけが転送を行うことができる。
【００８４】
図１６はバス使用権の要求を説明する図、図１７はバス使用の許可を説明する図である。バスアービトレーションが始まると、一つもしくは複数のノードが親ノードに向かって、それぞれバスの使用権を要求する。図１６においては、ノードＣとノードＦがバス使用権を要求している。この要求を受けた親ノード（図１６ではノードＡ）は、さらに親ノードに向かって、バスの使用権を要求することで、ノードＦによるバスの使用権の要求を中継する。この要求は最終的に、アービトレーションを行うルートノードに届けられる。
【００８５】
バスの使用権の要求を受けたルートノードは、どのノードにバスの使用権を与えるかを決める。このアービトレーション作業はルートノードのみが行えるものであり、アービトレーションに勝ったノードにはバスの使用許可が与えるられる。図１７は、ノードＣにバスの使用許可が与えられ、ノードＦのバスの使用権の要求は拒否された状態を示している。
【００８６】
ルートノードは、バスアービトレーションに負けたノードに対してはＤＰ（ｄａｔａ  ｐｒｅｆｉｘ）パケットを送り、そのバスの使用権の要求が拒否されたことを知らせる。バスアービトレーションに負けたノードのバスの使用権の要求は、次回のバスアービトレーションまで待たされることになる。
【００８７】
以上のようにして、アービトレーションに勝ってバス使用の許可を得たノードは、以降、データ転送を開始することができる。ここで、バスアービトレーションの一連の流れを図１８に示すフローチャートにより説明する。
【００８８】
ノードがデータ転送を開始できるためには、バスがアイドル状態であることが必要である。先に開始されたデータ転送が終了し、現在、バスがアイドル状態にあることを確認するためには、各転送モードで個別に設定されている所定のアイドル時間ギャップ長（例えば、サブアクションギャップ）の経過を検出し、所定のギャップ長が検出された場合、各ノードはバスがアイドル状態になったと判断する。各ノードは、ステップＳ４０１で、非同期データ、同期データなどそれぞれ転送するデータに応じた所定のギャップ長が検出されたか否かを判断する。所定のギャップ長が検出されない限り、転送を開始するために必要なバス使用権を要求することはできない。
【００８９】
各ノードは、ステップＳ４０１で所定のギャップ長が検出されると、ステップＳ４０２で転送すべきデータがあるか判断し、ある場合はステップＳ４０３でバスの使用権を要求する信号をルートに対して発信する。このバスの使用権の要求を表す信号は、図１６に示すように、ネットワーク内の各機器に中継されながら、最終的にルートノードに届けられる。ステップＳ４０２で転送するデータがないと判断した場合は、ステップＳ４０１に戻る。
【００９０】
ルートノードは、ステップＳ４０４でバスの使用権を要求する信号を一つ以上受信したら、ステップＳ４０５で使用権を要求したノードの数を調べる。ステップＳ４０５の判定により、使用権を要求したノードが一つだったら、そのノードに、直後のバス使用許可が与えられることになる。また、使用権を要求したノードが複数だったら、ステップＳ４０６で直後のバス使用許可を与えるノードを一つに絞るアービトレーション作業が行われる。このアービトレーション作業は、毎回同じノードばかりにバスの使用許可を与えるようなことはなく、平等にバスの使用許可を与えるようになっている（フェア・アービトレーション）。
【００９１】
ルートノードの処理は、ステップＳ４０７で、ステップＳ４０６のアービトレーションに勝った一つのノードと、敗れたその他のノードとに応じて分岐する。アービトレーションに勝った一つのノード、またはバスの使用権を要求したノードが一つの場合は、ステップＳ４０８でそのノードに対してバスの使用許可を示す許可号が送られる。この許可信号を受信したノードは、直後に転送すべきデータ（パケット）の転送を開始する（ステップＳ４１０）。また、アービトレーションに敗れたノードにはステップＳ４０９で、バス使用権の要求が拒否されたことを示すＤＰ（ｄａｔａ  ｐｒｅｆｉｘ）パケットが送られる。ＤＰパケットを受取ったノードの処理は、再度、バスの使用権を要求するためにステップＳ４０１まで戻る。ステップＳ４１０におけるデータの転送が完了したノードの処理もステップＳ４０１へ戻る。
【００９２】
［トランザクションレイヤ］
トランザクションの種類には、リードトランザクション、ライトトランザクションおよびロックトランザクションの三種類がある。
【００９３】
リードトランザクションでは、イニシエータ（要求ノード）がターゲット（レスポンスノード）のメモリの特定アドレスからデータを読取る。ライトトランザクションでは、イニシエータがターゲットのメモリの特定アドレスにデータを書込む。また、ロックトランザクションでは、イニシエータからターゲットに参照データと更新データを転送する。その参照データは、ターゲットのアドレスのデータと組み合わされて、ターゲットの特定のアドレスを指示する指定アドレスになる。そして、この指定アドレスのデータが更新データにより更新される。
【００９４】
図１９はトランザクションレイヤ８１４におけるＣＳＲアーキテクチャに基づくリード、ライト、ロックの各コマンドの要求・レスポンスプロトコルを示す図で、図に示す要求、通知、レスポンスおよび確認は、トランザクションレイヤ８１４でのサービス単位である。
【００９５】
トランザクション要求（ＴＲ＿ＤＡＴＡ．ｒｅｑｕｅｓｔ）はレスポンスノードに対するパケットの転送、トランザクション通知（ＴＲ＿ＤＡＴＡ．ｉｎｄｉｃａｔｉｏｎ）はレスポンスノードに要求が届いたことの通知、トランザクションレスポンス（ＴＲ＿ＤＡＴＡ．ｒｅｓｐｏｎｓｅ）はアクノリッジの送信、トランザクション確認（ＴＲ＿ＤＡＴＡ．ｃｏｎｆｉｒｍａｔｉｏｎ）はアクノリッジの受信である。
【００９６】
［リンクレイヤ］
図２０はリンクレイヤ８１２におけるサービスを示す図で、レスポンスノードに対するパケットの転送を要求するリンク要求（ＬＫ＿ＤＡＴＡ．ｒｅｑｕｅｓｔ）、レスポンスノードにパケット受信を通知するリンク通知（ＬＫ＿ＤＡＴＡ．ｉｎｄｉｃａｔｉｏｎ）、レスポンスノードからのアクノリッジ送信のリンクレスポンス（ＬＫ＿ＤＡＴＡ．ｒｅｓｐｏｎｓｅ）、要求ノードのアクノリッジ送信のリンク確認（ＬＫ＿ＤＡＴＡ．ｃｏｎｆｉｒｍａｔｉｏｎ）のサービス単位に分けられる。一つのパケット転送プロセスはサブアクションと呼ばれ、非同期サブアクションと同期サブアクションの二つの種類がある。以下では、各サブアクションの動作について説明する。
【００９７】
［非同期サブアクション］
非同期サブアクションは非同期データ転送である。図２１は非同期転送における時間的な遷移を示す図である。図２１に示す最初のサブアクションギャップは、バスのアイドル状態を示すものである。このアイドル時間が所定値になった時点で、データ転送を希望するノードがバス使用権を要求し、バスアービトレーションが実行される。
【００９８】
バスアービトレーションによりバスの使用が許可されると、次に、データがパケット転送され、このデータを受信したノードは、ＡＣＫギャップという短いギャップの後、受信確認用返送コードＡＣＫを返してレスポンスするか、レスポンスパケットを返送することでデータ転送が完了する。ＡＣＫは４ビットの情報と４ビットのチェックサムからなり、成功、ビジー状態またはペンディング状態であることを示す情報を含み、すぐにデータ送信元のノードに返される。
【００９９】
図２２は非同期転送用パケットのフォーマットを示す図である。パケットには、データ部および誤り訂正用のデータＣＲＣのほかにヘッダ部があり、そのヘッダ部には目的ノードＩＤ、ソースノードＩＤ、転送データ長や各種コードなどが書込まれている。
【０１００】
また、非同期転送は送信ノードから受信ノードへの一対一の通信である。送信元ノードから送り出されたパケットは、ネットワーク中の各ノードに行き渡るが、各ノードは自分宛てのパケット以外は無視するので、宛先に指定されたノードだけがそのパケットを受取ることになる。
【０１０１】
［スプリットトランザクション］
トランザクションレイヤ８１４におけるサービスは、図１９で示したトランザクション要求およびトランザクションレスポンスのセットで行われる。ここで、ターゲット（レスポンスノード）のリンクレイヤ８１２およびトランザクションレイヤ８１４における処理が充分高速であれば、要求とレスポンスをリンクレイヤ８１２のそれぞれ独立したサブアクションで処理せず、一つのサブアクションで処理することが可能になる。しかし、ターゲットの処理速度が遅い場合は、要求とレスポンスを個別のトランザクションで処理する必要がある。そして、この動作をスプリットトランザクションと呼ぶ。
【０１０２】
図２３はスプリットトランザクションの動作例を示す図で、イニシエータ（要求ノード）のコントローラからのライト要求に対して、ターゲットはペンディングを返す。これにより、ターゲットは、コントローラのライト要求に対する確認情報を返すことができ、データを処理するための時間を稼ぐことができる。そして、データ処理に充分な時間が経過した後、ターゲットは、ライトレスポンスをコントローラに通知してライトトランザクションを終了させる。なお、このときの要求とレスポンスのサブアクションの間には、他のノードによるリンクレイヤ８１２の操作が可能である。
【０１０３】
図２４はスプリットトランザクションを行う場合の転送状態の時間的遷移例を示す図で、サブアクション１は要求サブアクションを、サブアクション２はレスポンスサブアクションをそれぞれ表している。
【０１０４】
サブアクション１で、イニシエータはライト要求を表すデータパケットをターゲットに送り、これを受けたターゲットはアクノリッジパケットにより上記の確認情報を示すペンディングを返すことで要求サブアクションが終了する。
【０１０５】
そして、サブアクションギャップが挿入された後、サブアクション２で、ターゲットはデータパケットが無データであるライトレスポンスを送り、これを受けたイニシエータはアクノリッジパケットでコンプリートレスポンスを返すことでレスポンスサブアクションが終了する。
【０１０６】
なお、サブアクション１の終了からサブアクション２の開始に至る時間は、最小はサブアクションギャップに相当する時間であり、最大はノードに設定された最大待ち時間まで伸ばすことが可能である。
【０１０７】
［同期サブアクション］
１３９４シリアルバスの最大の特徴であるともいえるこの同期転送は、とくにＡＶデータなどのリアルタイム転送を必要とするデータの転送に適している。また、非同期転送が一対一の転送であるのに対し、この非同期転送はブロードキャスト機能によって、一つの送信元ノードから他のすべてのノードへ一様にデータを転送することができる。
【０１０８】
図２５は同期転送における時間的な遷移を示す図で、同期転送はバス上で一定時間毎に実行され、この時間間隔を同期サイクルと呼ぶ。同期サイクル時間は１２５μｓである。この同期サイクルの開始を示し、各ノードの動作を同期させる役割を担っているのがサイクルスタートパケット（ＣＳＰ）２０００である。ＣＳＰ２０００を送信するのは、サイクルマスタと呼ばれるノードであり、一つ前のサイクル内の転送が終了し、所定のアイドル期間（サブアクションギャップ２００１）を経た後、本サイクルの開始を告げるＣＳＰ２０００を送信する。つまり、このＣＳＰ２０００が送信される時間間隔が１２５μＳになる。
【０１０９】
また、図２５にチャネルＡ、チャネルＢおよびチャネルＣと示すように、一つの同期サイクル内において複数種のパケットにチャネルＩＤをそれぞれ与えることにより、それらのパケットを区別して転送することができる。これにより、複数ノード間で、略同時に、リアルタイム転送が可能であり、また、受信ノードは所望するチャネルＩＤのデータのみを受信すればよい。このチャネルＩＤは、受信ノードのアドレスなどを表すものではなく、データに対する論理的な番号に過ぎない。従って、送信されたあるパケットは、一つの送信元ノードから他のすべてのノードに行き渡る、つまりブロードキャストされることになる。
【０１１０】
同期転送によるパケット送信に先立ち、非同期転送と同様に、バスアービトレーションが行われる。しかし、非同期転送のように一対一の通信ではないので、同期転送には受信確認用の返送コードのＡＣＫは存在しない。
【０１１１】
また、図２５に示したｉｓｏギャップ（同期ギャップ）は、同期転送を行う前にバスがアイドル状態であることを確認するために必要なアイドル期間を表している。この所定のアイドル期間を検出したノードは、バスがアイドル状態にあると判断し、同期転送を行いたい場合はバス使用権を要求するのでバスアービトレーションが行われることになる。
【０１１２】
図２６は同期転送用のパケットフォーマット例を示す図である。各チャネルに分けられた各種のパケットには、それぞれデータ部および誤り訂正用のデータＣＲＣのほかにヘッダ部があり、そのヘッダ部には図２７に示すような、転送データ長、チャネル番号、その他各種コードおよび誤り訂正用のヘッダＣＲＣなどが書込まれている。
【０１１３】
［バス・サイクル］
実際に、１３９４シリアルバスにおいては、同期転送と非同期転送が混在できる。図２８は同期転送と非同期転送が混在するときの転送状態の時間的遷移を示す図である。
【０１１４】
ここで、前述したように同期転送は非同期転送より優先して実行される。その理由は、ＣＳＰの後、非同期転送を起動するために必要なアイドル期間のギャップ（サブアクションギャップ）よりも短いギャップ（アイソクロナスギャップ）で、同期転送を起動できるからである。従って、非同期転送より同期転送は優先して実行されることになる。
【０１１５】
図２８に示す一般的なバスサイクルにおいて、サイクル＃ｍのスタート時にＣＳＰがサイクルマスタから各ノードに転送される。ＣＳＰによって、各ノードの動作が同期され、所定のアイドル期間（同期ギャップ）を待ってから同期転送を行おうとするノードはバスアービトレーションに参加し、パケット転送に入る。図２８ではチャネルｅ、チャネルｓおよびチャネルｋが順に同期転送されている。
【０１１６】
このバスアービトレーションからパケット転送までの動作を、与えられているチャネル分繰り返し行った後、サイクル＃ｍにおける同期転送がすべて終了すると、非同期転送を行うことができるようになる。つまり、アイドル時間が、非同期転送が可能なサブアクションギャップに達することによって、非同期転送を行いたいノードはバスアービトレーションに参加する。ただし、非同期転送が行えるのは、同期転送の終了から、次のＣＳＰを転送すべき時間（ｃｙｃｌｅ  ｓｙｎｃｈ）までの間に、非同期転送を起動するためのサブアクションギャップが検出された場合に限られる。
【０１１７】
図２８に示すサイクル＃ｍでは、三つのチャネル分の同期転送の後、非同期転送によりＡＣＫを含む２パケット（パケット１、パケット２）が転送されている。この非同期パケット２の後、サイクルｍ＋１をスタートすべき時間（ｃｙｃｌｅ  ｓｙｎｃｈ）に至るので、サイクル＃ｍにおける転送はこれで終わる。ただし、非同期または同期転送中に次のＣＳＰを送信すべき時間（ｃｙｃｌｅ  ｓｙｎｃｈ）に至ったら、転送を無理に中断せず、その転送が終了した後にアイドル期間を経て次の同期サイクルのＣＳＰを送信する。すなわち、一つの同期サイクルが１２５μｓ以上続いたときは、その延長分、次の同期サイクルは基準の１２５μｓより短縮される。このように同期サイクルは１２５μｓを基準に超過、短縮し得るものである。
【０１１８】
しかし、同期転送はリアルタイム転送を維持するために、必要であれば毎サイクル実行され、非同期転送は同期サイクル時間が短縮されたことによって次以降の同期サイクルに延期されることもある。サイクルマスタは、こういった遅延情報も管理する。
【０１１９】
［ＦＣＰ］
ＡＶ／Ｃプロトコルでは、１３９４シリアルバス上の装置を制御するために機能制御プロトコルＦＣＰ（Ｆｕｎｃｔｉｏｎａｌ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）が用意されている。ＦＣＰの制御コマンドの送信とレスポンスには、ＩＥＥＥ１３９４で規定されている非同期パケットが用いられる。ＦＣＰにおいては、制御側のノードをコントローラ、被制御側のノードをターゲットと呼び、コントローラからターゲットに送られるＦＣＰパケットフレームをＡＶ／Ｃコマンドフレーム、逆にターゲットからコントローラに返されるＦＣＰパケットフレームをＡＶ／Ｃレスポンスフレームと呼ぶ。
【０１２０】
図２９は、ノードＡがコントローラ、ノードＢがターゲットの場合を示し、それぞれに用意されているレジスタアドレスのうち０ｘ００００Ｂ００番地からの５１２バイトがコマンドレジスタ、０ｘ００００Ｄ００番地からの５１２バイトがレスポンスレジスタであり、それぞれ非同期転送を用いたパケットフレームにより、指定されたアドレスのレジスタにデータが書込まれる。このときのコントローラによるＡＶ／Ｃコマンドフレームの送信と、ターゲットによるＡＶ／Ｃレスポンスフレームのレスポンスの関係は、ＡＶ／Ｃトランザクションと呼ばれる。一般的なＡＶ／Ｃトランザクションでは、ターゲットはコマンドフレームを受取ってから１００ｍｓ以内に、コントローラに対してレスポンスフレームをレスポンスする必要がある。
【０１２１】
図３０はＦＣＰパケットフレームを含む非同期転送のパケットフォーマットを示す図で、図２２に示した非同期データパケットのデータ領域に対して、コマンドフレームやレスポンスフレームを挿入してＡＶ／Ｃトランザクションが実行される。
【０１２２】
図３１はＡＶ／Ｃコマンドフレームの構造を示す図、図３２はＡＶ／Ｃレスポンスフレームの構造を示す図で、ＦＣＰパケットフレームとしてはヘッダのｃｔｙｐｅ、ｒｅｓｐｏｎｓｅ、ｓｕｂｕｎｉｔ＿ｔｙｐｅ、ｓｕｂｕｎｉｔ＿ＩＤの後に、ＦＣＰのデータ部分がつながった構造になっている。
【０１２３】
ｃｔｙｐｅは、コマンドフレームにおけるコマンドタイプを示し、ＣＯＮＴＲＯＬ、ＳＴＡＴＵＳ、ＩＮＱＵＩＲＹ、ＮＯＴＩＦＹの各状態を示している。
【０１２４】
ｒｅｓｐｏｎｓｅは、レスポンスフレームにおけるレスポンスコードを示し、ＡＣＣＥＰＴＥＤ、ＲＥＪＥＣＴＥＤ、ＩＮ＿ＴＲＡＮＳＩＴＩＯＮ、ＩＭＰＬＥＭＥＮＴＥＤ、ＣＨＡＮＧＥＤ、ＩＮＴＥＲＩＭなどの各状態を示している。
【０１２５】
また、ｓｕｂｕｎｉｔ＿ｔｙｐｅはデバイスの分類、ｓｕｂｕｎｉｔ＿ＩＤはインスタンス番号を示している。
【０１２６】
ＦＣＰのデータ部分はオペコード＋オペランドの構成になっていて、各種のＡＶ／Ｃコマンドを使ってターゲットの制御を行ったり、ＡＶ／Ｃレスポンスのレスポンスをすることができる。
【０１２７】
コマンドフレームにおけるオペコード（ｏｐｃｏｄｅ）は、図５０に示すｃｏｍｍａｎｄ列に示されたコマンド群の一つであり、各コマンドはｃｔｙｐｅにセットされるコマンドタイプに従った内容で実行される。
【０１２８】
ｃｔｙｐｅにより「ＣＯＮＴＲＯＬ」が指定されたコマンドは、制御コマンドを意味し、ターゲットの機器を制御したり、オペランド（ｏｐｒａｎｄ）以降に設定された内容でターゲットを設定する。ｃｔｙｐｅにより「ＳＴＡＴＵＳ」が指定されたコマンドは、そのコマンドに対応するステータスを得るためのものである。ｃｔｙｐｅにより「ＩＮＱＵＩＲＹ」が指定されたコマンドは、そのコマンドにより設定可能な内容を問い合わせるためのものである。ｃｔｙｐｅに「ＮＯＴＩＦＹ」が指定されたコマンドは、そのコマンドの確認を行うためのものである。
【０１２９】
各コマンドは、各コマンドに必要な内容がオペランドに設定され、コマンドフレームに書込まれる。
【０１３０】
レスポンスフレームにおけるオペコードには、図５０のｒｅｓｐｏｎｓｅ列に示されるレスポンスコードが設定される。各レスポンスは、各レスポンスに対応するオペランドを有する。レスポンスのオペランドには、コマンドの実行が正常に終了したか、エラー終了したかを示す情報がセットされるので、このオペランドに従ってエラー処理を行うことができる。
【０１３１】
【ＬＯＧＩＮプロトコル】
［ＬＯＧＩＮプロトコルを用いた通信］
図３３は、１３９４シリアルバスのインタフェイスをＬＡＮでよく用いられるＯＳＩモデルの各層と対比させた図である。ＯＳＩモデルの物理層１とデータリンク層２が、１３９４シリアルバスのインタフェイスの下位層４であるフィジカルレイヤ８１１およびリンクレイヤ８１２に該当する。下位層４の上に存在する１３９４シリアルバスのインタフェイスにおけるトランスポートプロトコル層５とプレゼンテーション層６は、ＯＳＩモデルのネットワーク層、トランスポート層、セッション層およびプレゼンテーション層を含む上位層３に該当する。また、ＬＯＧＩＮプロトコル７は、１３９４シリアルバスのインタフェイスの下位層４とトランスポートプロトコル層５との間で動作するものである。
【０１３２】
図３３に示す例１では、プリンタなどの周辺機器用のシリアルバスプロトコル（ＳＢＰ−２）８に準拠したデバイスにＬＯＧＩＮプロトコル７をもたせることによって、相手のデバイスに対してＳＢＰ−２に準拠したプロトコルを使ってデータのやり取りを行いたいことを通知させることができる。
【０１３３】
また図３３に示す例２では、１３９４シリアルバスのインタフェイス上で特化されたデバイスプロトコル９についても、ＬＯＧＩＮプロトコル７をもたせることで、デバイスが互いに、互いのプロトコルをサポートしているかを判別させることができる。
【０１３４】
図３４はＬＯＧＩＮプロトコル７の基本動作を示す図で、プリンタデバイスは、ホストデバイスからの印刷タスク（ｐｒｉｎｔ  ｔａｓｋ）１０を実行する際に、まず、プリンタに用意されているプリンタプロトコルＡ、ＢおよびＣの内、どれを選択して印刷データをやり取りするかをＬＯＧＩＮプロトコル７による通信に基づき決定し、その後は、決定したプリンタプロトコルに従って印刷データのやり取りを行う。すなわち、幾つかのプリンタプロトコルをサポートしているプリンタデバイスは、ホストデバイスと接続する際に、まずホストデバイスに用意されているトランスポートプロトコル５をＬＯＧＩＮプロトコル７によって判別し、ホストデバイスのトランスポートプロトコル５に合ったプリンタプロトコルを選択し、選んだプリンタプロトコルに従って印刷データやコマンドのやり取りを行うことで、印刷タスク１０の処理を行う。
【０１３５】
図３５は１３９４シリアルバスにおける接続形態の一例を示す図で、複数のプリンタプロトコルに対応（ｍｕｌｔｉ−ｐｒｏｔｏｃｏｌ  ｓｕｐｐｏｒｔ）するプリンタ１１に対してＬＯＧＩＮプロトコル７を実装したデバイス（ＰＣ１２、スキャナ１３、ＤＶＣ１４等）が接続された状態を示している。プリンタ１１は、ＬＯＧＩＮプロトコル７により判別した、接続を要求する相手デバイスのトランスポートプロトコル５に応じてプリンタプロトコルを切替えることにより、各デバイスからの印刷タスクを問題なく処理することが可能となる。
【０１３６】
図３６はログイン動作の流れを示す図である。ステップ１において：  ホストデバイスは、ターゲットデバイス（この場合マルチプロトコルプリンタ）をロックする。ターゲットデバイスは、ホストデバイスのケーパビリティ（トランスポートプロトコルを含む）を調べ、かかるケーパビリティは、後述するレジスタ５０３に格納される。
【０１３７】
ステップ２において：  ステップ１で設定されたプロトコルによりプリントデータの通信が行われる。
【０１３８】
ステップ３において：  ホストデバイスは、ターゲットデバイスとのコネクションを切断する。
【０１３９】
図３７はＬＯＧＩＮプロトコル７のためにターゲットデバイスであるプリンタが備える１３９４シリアルバスのＣＳＲを示し、ロックレジスタ（ｌｏｃｋ）５０１、プロトコルレジスタ（ｐｒｏｔｏｃｏｌ）５０２、ケーパビリティレジスタ（ｃａｐａｂｉｌｉｔｙ）５０３を示している。これらのレジスタは１３９４シリアルバスのアドレス空間における初期ユニット空間の定められたアドレスに配置される。つまり、図４を用いて説明したように、機器に与えられたアドレス幅４８ｂｉｔのうち、最初の２０ビットにおける０ｘＦＦＦＦＦがレジスタ空間と呼ばれ、その最初の５１２バイトにＣＳＲアーキテクチャのコアになるレジスタ（ＣＳＲコア）が配置されている。
【０１４０】
ロックレジスタ５０１は、リソースのロック状態を示し、値「０」はログイン可能な状態を表し、「０」以外はロック状態で既にログインされていることを表す。ケーパビリティレジスタ５０３は、そのビット毎に設定可能なプロトコルを示し、値‘１’のビットに対応するプロトコルは設定可能であることを表し、‘０’に対応するプロトコルは設定不可能であることを表す。プロトコルレジスタ５０２は、現在設定されているプロトコルを示し、設定されたプロトコルに対応するケーパビリティレジスタ５０３のビットに相当するビットの値が‘１’になる。図３８はホストデバイスにおけるログイン処理を示すフローチャートである。
【０１４１】
ログインを開始するためには、まずログインしようとするターゲットデバイス、例えばプリンタのロックレジスタ５０１、プロトコルレジスタ５０２およびケーパビリティレジスタ５０３のデータをリードトランザクションにより確認する。ここで、ケーパビリティレジスタ５０３のデータから、ホストデバイスが通信に用いるプロトコルをターゲットデバイスがサポートしているかどうか確認する（ステップＳ６０１）。
【０１４２】
もしホストデバイスのプロトコルがターゲットデバイスのサポート外ならば、次のステップＳ６０２でログインを中止する。また、ロックレジスタ５０１のデータが「０」以外であれば、他のデバイスがログイン中であるとみなしログインを中止する。ログインレジスタ５０１のデータが「０」であれば現在ログイン可能とみなす（ステップＳ６０２）。
【０１４３】
ログイン可能の場合、リソースロック処理に移り、プリンタのロックレジスタ５０１にロックトランザクションを用いて例えば「１」を書き込みログインを設定する（ステップＳ６０３）。この状態でターゲットデバイスはロックされたことになり、他のデバイスからの制御は不可、またレジスタの変更も不可能となる。
【０１４４】
上記のようにターゲットデバイスのリソースがロックされた状態で、次にプロトコルの設定を行う。ターゲットデバイスである本実施例のプリンタは、複数のプリンタプロトコルをサポートするため、プリントデータを受取る前に、ホストデバイスが使用できるプロトコルを知らねばならない。本実施例においては、ホストデバイスのライトトランザクションにより、プリンタのプロトコルレジスタ５０２の相当するビットを設定することで、これから使用するプロトコルをプリンタに通知する（ステップＳ６０４）。
【０１４５】
この時点で、ホストデバイスが通信に用いるプロトコルがターゲットデバイスに通知され、かつターゲットデバイスがロック状態なので、現在、ターゲットデバイスにログインしているホストデバイスがデータ、この場合はプリントデータの送信を行う（ステップＳ６０５）。
【０１４６】
データの送信が終了したら、ホストデバイスはターゲットデバイスのロックレジスタ５０１およびプロトコルレジスタ５０３をクリアすることにより、プリンタからログアウトする（ステップＳ６０６）。
【０１４７】
図３９はターゲットデバイスであるプリンタのログイン処理を示すフローチャートである。プリンタは、通常、ホストデバイスからログインされるのを待つ状態にある。ホストデバイスからのプリントリクエストは、プリンタのロックレジスタ５０１、プロトコルレジスタ５０２およびケーパビリティレジスタ５０３の読取りにより開始されるので、前記レジスタは、常に他のデバイスから読み出し可能な状態にしておく必要がある。
【０１４８】
今、プリントアウトを実行しようとするホストデバイスによりプリンタがロックされたとする（ステップＳ７０１）。プリンタは、次にホストデバイスから使用プロトコルが通知されるのを待つ（ステップＳ７０２）。プリンタが、ロック状態になってから使用プロトコルの通知を待つのは、ログインの途中で、他のデバイスからのリクエストにより、プロトコルレジスタ５０３を書き換えられないようにするためである。
【０１４９】
使用プロトコルの通知があったら（ステップＳ７０３）、プリンタは、通知された使用プロトコルに自分のプロトコルをスイッチして（ステップＳ７０４、Ｓ７０６およびＳ７０８）、ホストデバイスのプロトコルに合わせて通信を行う（ステップＳ７０５、Ｓ７０７またはＳ７０９）。
【０１５０】
通信が終了したら、プリンタはロックレジスタ５０１およびプロトコルレジスタ５０３がクリアされたのを確認し（ステップＳ７１０）、ログインを待つ状態（ステップＳ７０１）に戻る。
【０１５１】
［ＬＯＧＩＮプロトコルをもたないデバイスを考慮した例］
図４０はＬＯＧＩＮプロトコル７を実装していないデバイスを考慮した例を説明する図で、図３４に示した第一例と比較すると、ＬＯＧＩＮプロトコル７をもたずプロトコルＤをもつデバイスについても対応している点が特徴である。すなわち、ＬＯＧＩＮプロトコル７をもつデバイスだけでなく、既存のプロトコルＤ（例えばＡＶ／Ｃプロトコル）にのみ対応しているデバイスに対しても例えば印刷動作を保証するために、プリンタ側にＬＯＧＩＮプロトコル７をもたないデバイスに対応するプリンタプロトコルを追加したものである。
【０１５２】
この動作について説明すると、接続の初めに行われるプリントリクエストによってホストデバイスがＬＯＧＩＮプロトコル７に対応していないことをプリンタが認識した場合、プリンタはプロトコルＤを使ってホストデバイスとの通信を試み、通信が成立した場合はそのプロトコルＤに従って印刷タスク１０を実行する。
【０１５３】
図４１は、図４０に示した構成とＯＳＩモデルの各層とを対比させた図で、例３は、ＬＯＧＩＮプロトコル７が実装されていない現行のＡＶ／Ｃプロトコルに準拠したＡＶデバイス１５をモデルとしている。例４は、ＬＯＧＩＮプロトコル７が実装されていないスキャナ用の非標準プロトコルが実装されているスキャナ１６をモデルとしている。
【０１５４】
すなわち、ＬＯＧＩＮプロトコル７を実装していないプロトコルをもつデバイスについても、そのデバイスがもつプロトコルにプリンタが対応することができれば、そのプリンタを利用することができるデバイスの種類を拡げることができる。
【０１５５】
【ダイレクトプリントプロトコル】
以下では、本発明にかかるプリンタと画像供給デバイスとの印刷手順を説明するが、プリンタと画像供給デバイスとを直結し、画像供給デバイスから供給される画像データに基づく画像形成をプリンタに行わせるためのプロトコルを「ダイレクトプリントプロトコル（ＤＰＰ）」と呼ぶ。
【０１５６】
ＤＰＰの基本は、１３９４シリアルバスの初期ユニット空間（図４のユニット空間で示される）内にコマンド書込みのためのコマンドレジスタ（ｃｏｍｍａｎｄ）、コマンドに対するレスポンスを書込むためのレスポンスレジスタ（ｒｅｓｐｏｎｓｅ）、転送データを書込むためのデータレジスタ（ｄａｔａ）、転送データ個別のデータフォーマットに対応したフォーマット情報を扱うためのフォーマットレジスタ（ｆｏｒｍａｔ）から構成される。
【０１５７】
図４２はこのレジスタマップを示す図で、コマンドレジスタ、レスポンスレジスタは図２９を用いて説明したものと同じである。以降の説明では、画像供給デバイスをコントローラ、プリンタをターゲットとし、画像供給デバイスからプリンタへ画像データを供給して画像を印刷する例を説明する。
【０１５８】
コマンドレジスタ４２−１は、プリンタ側の０ｘＦＦＦＦＦ００００Ｂ００の固定アドレスに配置され、５１２バイトのメモリ空間を有し、画像供給デバイスがプリンタに対する各種コマンドを書込むためのものである。勿論、コマンドレジスタが画像供給デバイス側にもある場合、プリンタからコマンドを書込むことも可能になる。コマンドレジスタ４２−１に書込まれるコマンドをコマンドフレームという。
【０１５９】
レスポンスレジスタ４２−２は、画像供給デバイス側の０ｘＦＦＦＦＦ００００Ｄ００の固定アドレスに配置され、５１２バイトのメモリ空間を有し、画像供給デバイスからプリンタに対して書込まれた各種コマンドに対するレスポンスが書込まれるためのものである。勿論、レスポンスレジスタがプリンタ側にもある場合、画像供給デバイスからレスポンスを書込むことも可能になる。レスポンスレジスタ４２−２に書込まれるレスポンスをレスポンスフレームという。なお、図２９においてはアドレスの上位０ｘＦＦＦＦが省略して記述されている。
【０１６０】
データレジスタ４２−３は、ＦＦＦＦＦＦ０００３０００ｈをデフォルトアドレスとし、ＢｌｏｃｋＡｄｄｒｅｓｓ，  ＢｕｆｆｅｒＣｏｎｆｉｇコマンド（データレジスタのアドレスを定義するコマンド）により有効な任意のアドレスに設定される。データレジスタ４２−３のメモリ空間は、ＢｌｏｃｋＳｉｚｅ，  ＢｕｆｆｅｒＣｏｎｆｉｇコマンド（データレジスタのメモリ空間を定義するコマンド）で前もって決められた範囲で設定される。データレジスタ４２−３は、画像供給デバイスとプリンタの間でデータの転送を行うためのレジスタで、印刷を行う場合には画像供給デバイスからプリンタに印刷データが書込まれる。印刷データは、予め設定された画像フォーマットのデータ形式に従い、データレジスタ４２−３に書込まれるデータをデータフレームという。
【０１６１】
フォーマットレジスタ４２−４は、後述する各データフォーマットに対応したレジスタ群をまとめたもので、各レジスタは各データフォーマットに必要なフォーマット情報を設定するためのレジスタになっている。つまり、フォーマットレジスタ４２−２は、画像供給デバイスからプリンタに対してフォーマット情報を書込むためのレジスタである。フォーマットレジスタ４２−２に書込まれるフォーマット情報をフォーマットフレームという。
【０１６２】
図４３は画像供給デバイスからプリンタへのフレームの流れを示す図で、コマンドフレーム、レスポンスフレーム、データフレーム、フォーマットフレームの流れを表し、画像供給デバイスから出力されたフレームに従いプリンタは印刷を行う。
【０１６３】
画像供給デバイスからプリンタへ送られるコマンドは、コマンドフレームとしてプリンタのコマンドレジスタ４３−４へ書込まれる。このコマンドは、図５０に示す印刷を行わせるためのコマンドである。このコマンドに対するレスポンスは、プリンタにより画像供給デバイスのレスポンスレジスタ４３−２に書込まれる。このレスポンスは、コマンドを正しく実行されたかどうかを示す情報およびコマンドに対する戻り値などを含む。画像供給デバイスからプリンタへ送られるプリントデータは、データフレームとしてプリンタのデータレジスタ４３−６へ書込まれる。画像供給デバイスからプリンタへ送られるフォーマット情報は、フォーマットフレームとしてプリンタのフォーマットレジスタ４３−７に書込まれる。
【０１６４】
図４４はフォーマットレジスタ４３−７の構成例を示す図である。フォーマットレジスタ４３−７は、問い合わせのための読込専用レジスタＩＮＱＵＩＲＹ  ４４−１と、設定および情報取得のための読込／書込レジスタＣＯＮＴＲＯＬ／ＳＴＡＴＵＳ  ４４−２とに区分される。ＩＮＱＵＩＲＹ  ４４−１およびＣＯＮＴＲＯＬ／ＳＴＡＴＵＳ  ４４−２は、同じ構成のレジスタグループから構成される。つまり、レジスタグループを構成するレジスタ４４−３から４４−７と、レジスタ４４−９から４４−１３とである。
【０１６５】
さらに詳しく説明すると、フォーマットレジスタグループは、共通レジスタグループ（ｐｒｉｎｔ  ｃｏｍｍｏｎ  ｒｅｇｉｓｔｅｒ  ｇｒｏｕｐ）を構成するレジスタ４４−３および４４−４（４４−９および４４−１０）と、プリンタフォーマットレジスタグループ（ｐｒｉｎｔ  ｆｏｒｍａｔ  ｒｅｇｉｓｔｅｒ  ｇｒｏｕｐ）を構成するレジスタ４４−５から４４−７（４４−１１から４４−１３）とから構成される。
【０１６６】
共通レジスタグループは、すべてのデータフォーマットに共通なレジスタを集めたレジスタ群であり、すべてのプリンタに共通なレジスタＧＬＯＢＡＬ  ４４−３（４４−９）と、個別のプリンタに固有のレジスタＬＯＣＡＬ  ４４−４（４４−１０）とから構成される。
【０１６７】
プリンタフォーマットレジスタグループは、各データフォーマットに独自の情報を集めたレジスタ群であり、レジスタｆｏｒｍａｔ［１］  ４４−５（４４−１１）からｆｏｒｍａｔ［ｎ］  ４４−７（４４−１３）までのｎ個のレジスタ群からなる。レジスタｆｏｒｍａｔ［１］からｆｏｒｍａｔ［ｎ］は、後述するデータフォーマットに対応し、実装するデータフォーマットごとに一つのプリンタフォーマットレジスタグループが割り当てられる。
【０１６８】
なお、各フォーマットレジスタのアドレスは、データフォーマットを設定するコマンドに対するレスポンスとして画像供給デバイスに与えられる。
【０１６９】
図４５は共通レジスタグループのステータスレジスタｓｔａｔｕｓ  ｒｅｇｉｓｔｅｒ  ４４−８の詳細な構成例を示す図である。ステータスレジスタ４４−８はそれぞれ３２ビットの、各ベンダのプリンタに共通なステータスを保持する共通ステータスレジスタ（ｃｏｍｍｏｎ  ｓｔａｔｕｓ  ｒｅｇｉｓｔｅｒ）４５−１と、各ベンダにより定義されるステータスを保持するベンダ固有ステータス（ｖｅｎｄｏｒ  ｓｐｅｃｉｆｉｃ  ｓｔａｔｕｓ  ｒｅｇｉｓｔｅｒ）４５−２とから構成される。また、共通ステータスレジスタ４５−１の第３１ビットにあるｖフラグ（ｖｅｎｄｏｒ  ｓｔａｔｕｓ  ａｖａｉｌａｂｌｅ  ｆｌａｇ）により、ベンダ固有ステータスレジスタ４５−２への拡張が次のように定義される。
ｖフラグ：‘０’＝  ｎｏｔ  ａｖａｉｌａｂｌｅ
‘１’＝  ａｖａｉｌａｂｌｅ
【０１７０】
また、共通ステータスレジスタ４５−１に保持される情報は次のようなものがある。
ｅｒｒｏｒ．ｗａｒｎｉｎｇ：  エラー、ワーニングなどのステータス
ｐａｐｅｒ  ｓｔａｔｅ：    記録紙に関するステータス
ｐｒｉｎｔ  ｓｔａｔｅ：    印刷状況に関するステータス
【０１７１】
図４６は共通レジスタグループのレジスタＧＬＯＢＡＬ  ４４−３（４４−９）に保持される情報の詳細例を示す図である。レジスタＧＬＯＢＡＬ  ４４−３（４４−９）は、ＤＰＰ（ダイレクトプリントプロトコル）を搭載するプリンタすべてに共通な情報を保持する、つまり、プリンタの種別による差異がない情報を集めたレジスタである。図４６はその一例を示し、記録媒体の種類を示すｍｅｄｉａ−ｔｙｐｅ  ４６−１、記録紙の大きさを示すｐａｐｅｒ−ｓｉｚｅ  ４６−２、ページのマージン値を示すｐａｇｅ−ｍａｒｇｉｎ  ４６−３、ページの長さを示すｐａｇｅ−ｌｅｎｇｔｈ  ４６−４、ページのオフセットを示すｐａｇｅ−ｏｆｆｓｅｔ  ４６−５、プリンタのユニット情報を示すｐｒｉｎｔ−ｕｎｉｔ  ４６−６、プリンタのカラータイプを示すｃｏｌｏｒ−ｔｙｐｅ  ４６−７、データのビット順序を示すｂｉｔ−ｏｒｄｅｒ  ４６−８などを含む。
【０１７２】
図４７は共通レジスタグループのレジスタＬＯＣＡＬ  ４４−４（４４−１０）に保持される情報の詳細例を示す図である。レジスタＬＯＣＡＬ  ４４−４（４４−１０）は、ＤＰＰを搭載するプリンタの機種それぞれに独自な情報を保持する、つまり、プリンタの種別により異なる情報を集めたレジスタである。図４７はその一例を示し、プリンタ独自の記録紙の種類を示すｐａｐｅｒ  ４７−１、カラーマッチング方法を示すＣＭＳ  ４７−２、例えばインクジェットプリンタのインクの種類を示すｉｎｋ  ４７−３などを含む。
【０１７３】
図４８はレジスタｆｏｒｍａｔ［１］  ４４−５に保持される情報の一例を示す図で、画像データフォーマットの一つであるＥＸＩＦ（Ｅｘｃｈａｎｇｅａｂｌｅ  Ｉｍａｇｅ  Ｆｉｌｅ  Ｆｏｒｍａｔ）に関する情報が保持された例である。この場合、入力のＸ方向の割合ｉｎＸ−ｒａｔｅ  ４８−１、入力のＹ方向の割合ｉｎＹ−ｒａｔｅ  ４８−２、出力のＸ方向の割合ｏｕｔＸ−ｒａｔｅ  ４８−３、出力のＹ方向の割合ｏｕｔＹ−ｒａｔｅ  ４８−４を含む。この場合、与えられたＥＸＩＦフォーマットの画像データを各レジスタの内容に合わせてＸＹ方向に変倍することにより印刷が可能になる。
【０１７４】
図４９はレジスタｆｏｒｍａｔ［２］  ４４−６に保持される情報の一例を示す図で、画像データフォーマットの一つであるＲａｗ  ＲＧＢフォーマットに関する情報が保持された例である。Ｒａｗ  ＲＧＢフォーマットは、各ピクセルをＲ（ｒｅｄ），  Ｇ（ｇｒｅｅｎ），  Ｂ（ｂｌｕｅ）のデータで構成する画像フォーマットである。この場合、入力のＸ方向の割合ｉｎＸ−ｒａｔｅ  ４９−１、入力のＹ方向の割合ｉｎＹ−ｒａｔｅ  ４９−２、出力のＸ方向の割合ｏｕｔＸ−ｒａｔｅ  ４９−３、出力のＹ方向の割合ｏｕｔＹ−ｒａｔｅ  ４９−４、ＸＹの固定ピクセルサイズ示すＸＹ−ｓｉｚｅ  ４９−５、ピクセル当りのビット数を示すｂｉｔ−ｐｉｘｅｌ  ４９−６、Ｘ方向のピクセル数を示すＸ−ｓｉｚｅ  ４９−７、Ｙ方向のピクセル数を示すＹ−ｓｉｚｅ  ４９−８、色プレーン数を示すｐｌａｎｅ  ４９−９、Ｘ方向の解像度を示すＸ−ｒｅｓｏｌｕｔｉｏｎ  ４９−１０、Ｙ方向の解像度を示すＹ−ｒｅｓｏｌｕｔｉｏｎ  ４９−１１、ピクセルの種類を示すｐｉｘｅｌ−ｆｏｒｍａｔ  ４９−１２などを含む。この場合、与えられたＲａｗ  ＲＧＢフォーマットの画像データを各レジスタの内容に合わせてＸＹ方向の変倍や解像度変換を行い、さらに画像サイズに関する情報などに基づいて処理することにより印刷することが可能になる。
【０１７５】
図５０はコマンドおよびコマンドに対するレスポンスの一覧を示す図である。コマンドは幾つかの種類に分類される。分類としては、ステータス関係の「ステータス」、プリンタ制御のための「コントロール」、データ転送の設定のための「ブロック／バッファ」、チャネル設定を行う「チャネル」、転送方法に関する「転送」、フォーマット設定に関する「フォーマット」、ログインに関する「ログイン」およびデータ転送に関する「データ」などがある。
【０１７６】
さらに詳しく説明すれば、「ステータス」としてプリンタのステータスを得るためのコマンドＧｅｔＳｔａｔｕｓおよびそのレスポンスＧｅｔＳｔａｔｕｓｒｅｓｐｏｎｓｅ  ５０−１などがある。
【０１７７】
「コントロール」としては、プリンタのリセットを行うコマンドＰｒｉｎｔＲｅｓｅｔおよびそのレスポンスＰｒｉｎｔＲｅｓｅｔＲｅｓｐｏｎｓｅ  ５０−２、印刷の開始を指示するＰｒｉｎｔＳｔａｒｔおよびそのレスポンスＰｒｉｎｔＳｔａｒｔＲｅｓｐｏｎｓｅ  ５０−３、印刷の中止を指示するＰｒｉｎｔＳｔｏｐおよびそのレスポンスＰｒｉｎｔＳｔｏｐＲｅｓｐｏｎｓｅ  ５０−４、記録紙の供給を指示するＩｎｓｅｒｔＰａｐｅｒおよびそのレスポンスＩｎｓｅｒｔＰａｐｅｒＲｅｓｐｏｎｓｅ  ５０−５、記録紙の排出を指示するＥｊｅｃｔＰａｐｅｒおよびそのレスポンスＥｊｅｃｔＰａｐｅｒＲｅｓｐｏｎｓｅ  ５０−６、画像データのコピー開始を指示するＣｏｐｙＳｔａｒｔおよびそのレスポンスＣｏｐｙＳｔａｒｔＲｅｓｐｏｎｓｅ  ５０−７、並びに、画像データのコピー終了を指示するＣｏｐｙＥｎｄおよびそのレスポンスＣｏｐｙＥｎｄＲｅｓｐｏｎｓｅ  ５０−８などがある。
【０１７８】
「ブロック／バッファ」としては、ブロックのサイズを指定するＢｌｏｃｋＳｉｚｅおよびそのレスポンスＢｌｏｃｋＳｉｚｅＲｅｓｐｏｎｓｅ  ５０−９、ブロックのアドレスを指定するＢｌｏｃｋＡｄｄｒｅｓｓおよびそのレスポンスＢｌｏｃｋＡｄｄｒｅｓｓＲｅｓｐｏｎｓｅ  ５０−１０、空きブロックの数を取得するＦｒｅｅＢｌｏｃｋおよびそのレスポンスＦｒｅｅＢｌｏｃｋＲｅｓｐｏｎｓｅ  ５０−１１、ブロックへのデータ書き込みを指示するＷｒｉｔｅＢｌｏｃｋｓおよびそのレスポンスＷｒｉｔｅＢｌｏｃｋｓＲｅｓｐｏｎｓｅ  ５０−１２、バッファの情報を指定するＢｕｆｆｅｒＣｏｎｆｉｇおよびそのレスポンスＢｕｆｆｅｒＣｏｎｆｉｇＲｅｓｐｏｎｓｅ  ５０−１３、並びに、バッファからのデータ取得の開始を指定するＳｅｔＢｕｆｆｅｒおよびそのレスポンスＳｅｔＢｕｆｆｅｒＲｅｓｐｏｎｓｅ  ５０−１４などがある。
【０１７９】
「チャネル」としては、チャネルをオープンするＯｐｅｎＣｈａｎｎｅｌおよびそのレスポンスＯｐｅｎＣｈａｎｎｅｌＲｅｓｐｏｎｓｅ  ５０−１５、並びに、チャネルをクローズするＣｌｏｓｅＣｈａｎｎｅｌおよびそのレスポンスＣｌｏｓｅＣｈａｎｎｅｌＲｅｓｐｏｎｓｅ  ５０−１６などがある。
【０１８０】
「転送」としてはデータ転送方法を指定するＴｒａｎｓｆｅｒＭｅｔｈｏｄおよびそのレスポンスＴｒａｎｓｆｅｒＭｅｔｈｏｄＲｅｓｐｏｎｓｅ  ５０−１７などがある。
【０１８１】
「フォーマット」としてはフォーマットを設定するＳｅｔＦｏｒｍａｔおよびそのレスポンスＳｅｔＦｏｒｍａｔＲｅｓｐｏｎｓｅ  ５０−１８などがある。
【０１８２】
「ログイン」としては、ログインを行うＬｏｇｉｎおよびそのレスポンスＬｏｇｉｎＲｅｓｐｏｎｓｅ  ５０−１９、ログアウトを行うＬｏｇｏｕｔおよびそのレスポンスＬｏｇｏｕｔＲｅｓｐｏｎｓｅ  ５０−２０、並びに、リコネクションを行うＲｅｃｏｎｎｅｃｔおよびそのレスポンスＲｅｏｎｎｅｃｔＲｅｓｐｏｎｓｅ  ５０−２１などがある。
【０１８３】
以上のコマンドはコマンドフレームに書込まれるものである。
【０１８４】
さらに、「データ」として、データを書込むためのＷｒｉｔｅＢｌｏｃｋ  ５０−２２、ＷｒｉｔｅＢｕｆｆｅｒ  ５０−２３、および、データを読込むためのＰｕｌｌＢｕｆｆｅｒ  ５０−２４などかある。これらのコマンドは、データフレームに対して書込み、読込みを行うものであり、対応するレスポンスはない。
【０１８５】
画像供給デバイスは、図３１に示したコマンドフレームのオペコード（ｏｐｃｏｄｅ）に、図５０に示す各コマンドに対応する値をセットし、プリンタのコマンドレジスタ４３−４に書込むことにより、プリンタによってそのコマンドが実行される。コマンドに対するレスポンスはコマンドと等しい値をもつ。プリンタは、図３２に示したレスポンスフレームのオペコードにレスポンスをセットし、画像供給デバイスのレスポンスレジスタ４３−２に書込む。このレスポンスにより、画像供給デバイスは各コマンドの実行結果を受取ることができる。
【０１８６】
図５１はＤＰＰがサポートする画像データフォーマット例を示す図である。プリンタはこれらのフォーマットのうち、少なくとも一つのロー（ＲＡＷ）画像データをサポートしなければならない。またオプションとして、他の複数のフォーマットをサポートすることができる。
【０１８７】
図５２はフォーマット設定処理の流れを示す図である。まず、画像供給デバイスは、ステップＳ５００でＳｅｔＦｏｒｍａｔ（ＩＮＱＵＩＲＹ）コマンドをプリンタへ送り、プリンタはステップＳ５０１でＳｅｔＦｏｒｍａｔレスポンスを返す。返されたレスポンスにより、画像供給デバイスはプリンタのＩＮＱＵＩＲＹレジスタのアドレスを知る。
【０１８８】
次に、画像供給デバイスは、ステップＳ５０２でＳｅｔＦｏｒｍａｔ（ＣＯＮＴＲＯＬ／ＳＴＡＴＵＳ）コマンドをプリンタへ送り、プリンタはステップＳ５０３でＳｅｔＦｏｒｍａｔレスポンスを返す。返されたレスポンスにより、画像供給デバイスはプリンタのＣＯＮＴＲＯＬ／ＳＴＡＴＵＳレジスタのアドレスを知る。
【０１８９】
画像供給デバイスは、ステップＳ５０４−１からＳ５０４−ｍでプリンタのＩＮＱＵＩＲＹレジスタを読み、プリンタがサポートするフォーマットおよびフォーマットの設定項目を知る。次に、画像供給デバイスは、ステップＳ５０５−１からＳ５０５−ｎでプリンタのＳＴＡＴＵＳ／ＣＯＮＴＲＯＬレジスタを読み、フォーマットの設定値を知るとともに、ステップＳ５０６−１からＳ５０６−ｎでプリンタのＳＴＡＴＵＳ／ＣＯＮＴＲＯＬレジスタにデータを書込み、フォーマットを設定する。
【０１９０】
ＤＰＰにおけるデータ転送には以下の二種類のパケットを用いる。
・フロー制御のための制御コマンドパケット
・データ送信のためのパケット
【０１９１】
本実施形態では、フロー制御、データ送信方法の違いにより、以下に五種類のデータ転送方式を列挙するが、何れの方式においてもフロー制御のための制御コマンドはＦＣＰに準拠している。
転送方式１：  レスポンスモデル（Ｒｅｓｐｏｎｓｅ  Ｍｏｄｅｌ）
転送方式２：  簡易レスポンスモデル（Ｓｉｍｐｌｉｆｅｄ  Ｒｅｓｐｏｎｓｅ  Ｍｏｄｅｌ）
転送方式３：  プッシュラージバッファモデル（ＰＵＳＨ  Ｌａｒｇｅ  Ｂｕｆｆｅｒ  Ｍｏｄｅｌ）
転送方式４：  プルバッファモデル（ＰＵＬＬ  Ｂｕｆｆｅｒ  Ｍｏｄｅｌ）
転送方式５：  同期モデル（Ｉｓｏｃｈｒｏｎｏｕｓ  Ｍｏｄｅｌ）
【０１９２】
実際の転送においては上記の方式の一つを選択し設定するが、その手順は図５２に示したフォーマット設定手順と同様である。なお、図５３に示すように、コマンドにはＴｒａｎｓｆｅｒＭｅｔｈｏｄを、レスポンスにはＴｒａｎｓｆｅｒＭｅｔｈｏｄＲｅｓｐｏｎｓｅを用いる。
【０１９３】
図５３はデータ転送方式の設定手順の一例を示す図である。画像供給デバイスは、コマンドタイプＩＮＱＵＩＲＹのＴｒａｓｆｅｒＭｅｔｈｏｄコマンドおよびレスポンスにより、現在使用可能なプリンタのデータ転送方式を取得し（Ｓ６００−１およびＳ６００−２）、コマンドタイプＣＯＮＴＲＯＬ／ＳＴＡＴＵＳのＴｒａｎｓｆｅｒＭｅｔｈｏｄコマンドおよびレスポンスにより、現在、プリンタに設定されているデータ転送方式を取得し、設定する（Ｓ６００−３およびＳ６００−４）。
【０１９４】
ところで、上記の五種類の何れの方式においても、フロー制御のための制御コマンドは、１３９４シリアルバス上の装置を制御するためのプロトコルであるＦＣＰに準拠している。ＦＣＰの制御コマンドの転送は、送信−応答とも、常に非同期のライトトランザクションにより行われる。
【０１９５】
図５４は前記転送方式１および転送方式２に必要なレジスタの１３９４シリアルバスのアドレス空間におけるレジスタマップを示す図である。本実施形態では、制御する側のノードを画像供給デバイス（ＦＣＰではコントローラに対応）に、制御される側のノードをプリンタ（ＦＣＰではターゲットに対応）にする。
【０１９６】
画像供給デバイス、プリンタともに、レジスタ空間のオフセット０ｘ０Ｂ００から５１２バイトのコマンドレジスタ（６０１−１および６０１−７）、オフセット０ｘ０Ｄ００から５１２バイトのレスポンスレジスタ（６０１−２および６０１−８）をもつ。これらレジスタはＦＣＰプロトコルおよびＡＶ／Ｃコマンドに準拠している。
【０１９７】
フロー制御は、これらのコマンドレジスタ（６０１−１および６０１−７）およびレスポンスレジスタ（６０１−２および６０１−８）にコマンドフレーム６０１−４およびレスポンスフレーム６０１−５を書き込むことにより行われる。また、印刷データの転送については専用のデータフレームを定義する。つまり、レジスタ空間のオフセット０ｘ３０００からブロックサイズ分のデータレジスタ（６０１−３および６０１−９）を設け、データレジスタ（６０１−３および６０１−９）にデータフレーム６０１−６を書き込むことで印刷データの転送が行われる。なお、ブロックサイズは例えば５１２バイトにする。
【０１９８】
図５５はデータパケットフレームの一例を示す図で、データヘッダ６０２−１、データペイロード６０２−２などから構成される。
【０１９９】
図５６はデータヘッダ６０２−１の構成例を示す図で、上位８ビットはブロックカウント領域６０３−１であり、下位８ビットは将来のための予約領域Ｓ６０３−２である。ブロックカウント領域６０３−１は、ターゲット（プリンタ）により内部的に用いられるもので、一回のブロック転送により転送されるブロックの数をカウントするカウンタである。なお、ブロックカウント領域６０３−１は８ビットなので０から２５５の値を取り得る。
【０２００】
図５７はブロック転送におけるプリンタ内のデータパケットフレーム処理を示す図である。プリンタに受信されたデータパケットは、まず、プリンタのデータレジスタ６０４−１に書き込まれる。プリンタはデータパケットと同じサイズのバッファ（６０４−２から６０４−５）を有し、データレジスタ６０４−１に書き込まれたデータパケットは、順次、これらのバッファ（６０４−２から６０４−５）に移される。なお、これらデータバッファの数は、ブロックカウント数の最大値に等しい２５５個あることが望ましいが、これ以下でもよい。ここで、各バッファはブロックカウント値に対応し、ブロックカウントが「０」のデータパケットはＢｌｏｃｋ［０］のバッファに、ブロックカウントが「１」のデータパケットはＢｌｏｃｋ［１］のバッファに、順次、格納される。バッファ（６０４−２から６０４−５）に格納されたデータパケットは、データヘッダ６０２−１が取除かれた上で、プリンタのメモリ空間６０４−６に展開される。
【０２０１】
［転送方式１］
Ｒｅｓｐｏｎｓｅ  Ｍｏｄｅｌである転送方式１は、データ送信のためにデータパケットフレームを定義し、データレジスタを設け、制御コマンドによりフロー制御を行いつつ、印刷データをライトトランザクションにより転送する方式である。
【０２０２】
図５８は転送方式１におけるＦｒｅｅＢｌｏｃｋコマンドおよびレスポンスを示す図である。転送方式１においては、データの転送に先立ち、画像供給デバイスが幾つのデータパケットを転送するかを示す情報を取得するためにＦｒｅｅＢｌｏｃｋコマンドおよびレスポンスが用いられる。
【０２０３】
画像供給デバイスはＦｒｅｅＢｌｏｃｋコマンドをライトトランザクションで転送し（Ｓ６０５−１）、プリンタはそのトランザクションに対する確認を示すＡＣＫパケットを返す（Ｓ６０５−２）。プリンタは現在使用可能なＦｒｅｅＢｌｏｃｋＣｏｕｎｔを通知するためにＦｒｅｅＢｌｏｃｋレスポンスを返し（Ｓ６０５−３）、画像供給デバイスはそのトランザクションに対する確認を示すＡＣＫパケットを返す（Ｓ６０５−４）。
【０２０４】
図５９は転送方式１におけるデータ転送フローの一例を示す図である。画像供給デバイスは、ＤＰＰのＬｏｇｉｎコマンドおよびレスポンスによりプリンタにログインし（Ｓ６０６−１およびＳ６０６−２）、前記のフォーマットレジスタグループを用いて、データ転送に使用するフォーマットを設定する（Ｓ６０６−３）。その後、ＯｐｅｎＣｈａｎｎｅｌコマンドおよびレスポンスにより論理チャネルを開く（Ｓ６０６−４およびＳ６０６−５）。続いてデータ転送が開始されるが、印刷データは図５５に示したデータパケット形式で転送される。また、パケットの転送は、図５７に符号６０４−２から６０４−５で示したプリンタ側のデータバッファ数に等しい数のブロック分の転送を一周期として行われる。
【０２０５】
転送方式１における印刷データの転送は次のように行われる。画像供給デバイスは、ＦｒｅｅＢｌｏｃｋコマンドおよびレスポンスによりプリンタのＦｒｅｅＢｌｏｃｋ数を得（Ｓ６０６−６およびＳ６０６−７）、そのＦｒｅｅＢｌｏｃｋ数と同数のデータパケットを、順次、ＷｒｉｔｅＢｌｏｃｋにより転送する（Ｓ６０６−８）。なお、ＷｒｉｔｅＢｌｏｃｋは図５４に示したデータレジスタ６０１−３からデータレジスタ６０１−９に印刷データ用のパケットを転送するコマンドである。ただし、ＷｒｉｔｅＢｌｏｃｋコマンドにはレスポンスはなく、データレジスタ６０１−９にデータパケットを格納したことを確認するためのＡＣＫパケットがプリンタから返される（Ｓ６０６−９）。
【０２０６】
そして、ＦｒｅｅＢｌｏｃｋ数に等しい数の、ＷｒｉｔｅＢｌｏｃｋコマンドによるパケット転送およびそれに対応するＡＣＫパケットの返送の繰返しからなるブロック転送が、画像供給デバイスから一連の印刷データがすべて出力されるまで繰返され、各ブロック転送の間には、ＦｒｅｅＢｌｏｃｋコマンドおよびレスポンスによるプリンタのＦｒｅｅＢｌｏｃｋ数の取得が行われる。
【０２０７】
印刷データの転送が終了すると、画像供給デバイスは、ＣｌｏｓｅＣｈａｎｎｅｌコマンドおよびレスポンスにより論理チャネルを閉じ（Ｓ６０６−１０およびＳ６０６−１１）、ＤＰＰのＬｏｇｏｕｔコマンドおよびレスポンスによりプリンタからログアウトする（Ｓ６０６−１２およびＳ６０６−１３）。
【０２０８】
［転送方式２］
Ｓｉｍｐｌｉｆｉｅｄ  Ｒｅｓｐｏｎｓｅ  Ｍｏｄｅｌである転送方式２は、ＦｒｅｅＢｌｏｃｋ数を獲得する方法以外は転送方式１と同じ手順でデータ転送を行う。
【０２０９】
図６０は転送方式２におけるデータ転送フローの一例を示す図である。画像供給デバイスは、ＤＰＰのＬｏｇｉｎコマンドおよびレスポンスによりプリンタにログインし（Ｓ６０７−１およびＳ６０７−２）、前記のフォーマットレジスタグループを用いて、データ転送に使用するフォーマットを設定する（Ｓ６０７−３）。その後、ＯｐｅｎＣｈａｎｎｅｌコマンドおよびレスポンスにより論理チャネルを開く（Ｓ６０７−４およびＳ６０７−５）。続いてデータ転送が開始されるが、印刷データは図５５に示したデータパケット形式で転送される。また、パケットの転送は、図５７に符号６０４−２から６０４−５で示したプリンタ側のデータバッファ数に等しい数のブロック分の転送を一周期として行われる。
【０２１０】
転送方式２における印刷データの転送は次のように行われる。画像供給デバイスは、ＷｒｉｔｅＢｌｏｃｋｓコマンドおよびレスポンスによりプリンタのＦｒｅｅＢｌｏｃｋ数を得る（Ｓ６０７−６およびＳ６０７−７）。ただし、ステップＳ６０７−７のレスポンスは、これ以降のＦｒｅｅＢｌｏｃｋ数の獲得をプリンタ側からのレスポンスのみにより行うために、ＩＮＴＥＲＩＭ（暫定）タイプである。画像供給デバイスは、得られたＦｒｅｅＢｌｏｃｋ数と同数のデータパケットを、順次、ＷｒｉｔｅＢｌｏｃｋにより転送し（Ｓ６０７−８）、プリンタからは前述したＡＣＫパケットが返される（Ｓ６０７−９）。そして、ＦｒｅｅＢｌｏｃｋ数に等しい数の、ＷｒｉｔｅＢｌｏｃｋコマンドによるパケット転送およびそれに対応するＡＣＫパケットの返送の繰返しからなるブロック転送が、画像供給デバイスから一連の印刷データがすべて出力されるまで繰返される。ただし、二周目以降のブロック転送におけるＦｒｅｅＢｌｏｃｋ数は、ブロック転送周期の終りごとに、プリンタから送られてくるＷｒｉｔｅＢｌｏｃｋｓレスポンスにより、画像供給デバイスに通知される（Ｓ６０７−１０）。このＷｒｉｔｅＢｌｏｃｋｓレスポンスは、プリンタのレスポンスのみによるＦｒｅｅＢｌｏｃｋ数の取得を継続するためにＣＯＮＴＩＮＵＥタイプである。
【０２１１】
印刷データの転送が終了すると、画像供給デバイスは、ＣｌｏｓｅＣｈａｎｎｅｌコマンドおよびレスポンスにより論理チャネルを閉じ（Ｓ６０７−１１およびＳ６０７−１２）、ＤＰＰのＬｏｇｏｕｔコマンドおよびレスポンスによりプリンタからログアウトする（Ｓ６０７−１３およびＳ６０７−１４）。
【０２１２】
［ＦｒｅｅＢｌｏｃｋ数の取得方法］
以下では、転送方式１と転送方式２の違いであるＦｒｅｅＢｌｏｃｋ数の取得方法について詳細に説明する。
【０２１３】
図６１は転送方式１のステップＳ６０６−６およびＳ６０６−７におけるＦｒｅｅＢｌｏｃｋコマンドおよびレスポンスを詳細に示す図で、図５９では省略したライトトランザクションのＡＣＫパケットを含めて示したもので、イニシエータデバイス（画像供給デバイス）、ターゲットデバイス（プリンタ）とも、リンクレイヤおよびトランザクションレイヤの処理速度が比較的低速な場合を示している。
【０２１４】
ライトトランザクションにより、画像供給デバイスがＦｒｅｅＢｌｏｃｋコマンドをコマンドレジスタに書き込む際（Ｓ６０８−１）、プリンタのリンクレイヤからは前述したｐｅｎｄｉｎｇを示すＡＣＫパケットが返る（Ｓ６０８−２）。次に、画像供給デバイスは、無データのＦｒｅｅＢｌｏｃｋコマンドを送り（Ｓ６０８−３）、プリンタからｃｏｍｐｌｅｔｅを示すＡＣＫパケット（Ｓ６０８−４）を受取って一つのライトトランザクションが終了する。
【０２１５】
続いて、プリンタは、ＦｒｅｅＢｌｏｃｋレスポンスを返すが、これもステップＳ６０８−１のＦｒｅｅＢｌｏｃｋコマンドと同様に、ＦｒｅｅＢｌｏｃｋ数を含むＦｒｅｅＢｌｏｃｋレスポンスとしてレスポンスレジスタに書き込まれる（Ｓ６０８−５）。画像供給デバイスのリンク層からは、ｐｅｎｄｉｎｇを示すＡＣＫパケットが返され（Ｓ６０８−６）、無データのＦｒｅｅＢｌｏｃｋレスポンス（Ｓ６０８−７）が送られ、ｃｏｍｐｌｅｔｅを示すＡＣＫパケットを受取って（Ｓ６０８−８）、一つのライトトランザクションが終了する。
【０２１６】
一方、転送方式２におけるＦｒｅｅＢｌｏｃｋ数の取得方法は、印刷データのブロック転送サイクルの二周期目以降では、プリンタからのＦｒｅｅＢｌｏｃｋレスポンスのみを用いるので、ステップＳ６０８−５からＳ６０８−８だけの動作でＦｒｅｅＢｌｏｃｋ数を取得することができる。
【０２１７】
ＦｒｅｅＢｌｏｃｋ数の取得は、ブロック転送の一周期ごとに必要である。従って、転送方式１よりも転送方式２の方がバス上を転送されるパケットの数を減らすことができる。
【０２１８】
図６２は転送方式１および転送方式２のＷｒｉｔｅＢｌｏｃｋを詳細に示す図である。ＷｒｉｔｅＢｌｏｃｋはレスポンスを必要としないので、ＷｒｉｔｅＢｌｏｃｋ（Ｓ６０９−１）、ｐｅｎｄｉｎｇを示すＡＣＫパケット（Ｓ６０９−２）、無データのＷｒｉｔｅＢｌｏｃｋ（Ｓ６０９−３）およびｃｏｍｐｌｅｔｅを示すＡＣＫパケット（Ｓ６０９−４）という手順になり、コマンドおよびレスポンスを転送する場合に比べて半分の手順でデータを転送することができ、リンクレイヤとトランザクションレイヤの処理が比較的低速の場合でも比較的高速のデータ転送を実行することができる。
【０２１９】
図６３は転送方式１および転送方式２のＷｒｉｔｅＢｌｏｃｋを詳細に示す図であるが、リンクレイヤとトランザクションレイヤの処理が充分高速な場合である。この場合は、ＷｒｉｔｅＢｌｏｃｋ（Ｓ６１０−１）、ｃｏｍｐｌｅｔｅを示すＡＣＫパケット（Ｓ６１０−２）という手順になり、さらに効率的なデータ転送を実行することができる。
【０２２０】
図６４はバスリセットが発生した場合のＷｒｉｔｅＢｌｏｃｋのエラー処理を説明する図で、あるブロック転送サイクルのｎ（＝０〜２５５）個目のパケット転送時にバスリセットが発生した場合を示している。ライトトランザクションでは、通常のデータパケット転送の失敗はＡＣＫパケットにより検知できるが、バスリセット発生時のエラーは検知できない。そこで本実施形態においては次の手順でエラー処理を実行する。つまり、ＦｒｅｅＢｌｏｃｋ数を取得し（Ｓ６１１−１）、ＷｒｉｔｅＢｌｏｃｋをｎ回行い（Ｓ６１１−２から〜Ｓ６１１−６）、ここでバスリセットが発生すると（Ｓ６１１−７）、画像供給デバイスは、バスリセット発生直前のＷｒｉｔｅＢｌｏｃｋ［ｎ］をを再度行い（Ｓ６１１−８）、その後は通常の処理を続ける（Ｓ６１１−９からＳ６１１−１４）。
【０２２１】
［転送方式３］
図６５はＰＵＳＨ  Ｌａｒｇｅ  Ｂｕｆｆｅｒ  Ｍｏｄｅｌにおける画像供給デバイスおよびプリンタのコマンドレジスタ、レスポンスレジスタおよびデータレジスタの構成例を示す図である。
【０２２２】
ＦＣＰに準拠した画像供給デバイスおよびプリンタ間のコマンドおよびレスポンスは、画像供給デバイスのコマンドレジスタ６５−１からプリンタのコマンドレジスタ６５−４にコマンドの要求データとしてのコマンドフレーム６５−７を書込む動作と、プリンタのレスポンスレジスタ６５−５から画像供給デバイスのレスポンスレジスタ６５−２にレスポンスデータとしてレスポンスフレーム６５−８を書込む動作により実行される。
【０２２３】
また、データフレーム６５−９についてはＦＣＰとは異なり、ライトトランザクションを用いて画像供給デバイスのデータレジスタ６５−３からプリンタのデータレジスタ６５−６へ画像データを書込む一方向動作に、データフレーム６５−９が使用される。
【０２２４】
図６６は画像供給デバイスおよびプリンタ間におけるＰＵＳＨバッファモデルの動作フローの一例を示す図である。なお、コマンドフレーム、レスポンスフレームにおける、Ｌｏｇｉｎ、Ｌｏｇｏｕｔ、ＯｐｅｎＣｈａｎｎｅｌ、ＣｌｏｓｅＣｈａｎｎｅｌ、フォーマット設定についての動作は、前述した転送方式１と同様であるから詳細な説明は省略する。
【０２２５】
図６６において、画像供給デバイスは、ＢｕｆｆｅｒＣｏｎｆｉｇコマンドのＩＮＱＵＩＲＹにより、プリンタのバッファ領域について問い合わせる（Ｓ７０１）。これに対してプリンタは、ＢｕｆｆｅｒＣｏｎｆｉｇレスポンスにより、バッファサイズやバッファアドレスを返す（Ｓ７０２）。
【０２２６】
次に、画像供給デバイスは、ＢｕｆｆｅｒＣｏｎｆｉｇコマンドのＣＯＮＴＲＯＬにより、データを書込むプリンタのバッファサイズおよびバッファアドレスを設定する（Ｓ７０３）。これに対してプリンタは、ＢｕｆｆｅｒＣｏｎｆｉｇレスポンスにより、設定が完了したことを返す（Ｓ７０４）。
【０２２７】
続いて、画像供給デバイスは、ＳｅｔＢｕｆｆｅｒコマンドのＮＯＴＩＦＹにより、データの転送を開始することをプリンタに通知する（Ｓ７０５）。これに対してプリンタは、ＳｅｔＢｕｆｆｅｒレスポンスのＩＮＴＥＲＩＭにより、取り敢えずデータを受信する準備ができたことを返し（Ｓ７０６）、データの転送を開始させる。そして、プリンタは、ＳｅｔＢｕｆｆｅｒレスポンスのＣＯＮＴＩＮＵＥにより、初めに設定されたバッファ領域に対するデータ転送が完了したことを画像供給デバイスに通知する（Ｓ７０９）。
【０２２８】
ステップＳ７０７のＷｒｉｔｅＢｕｆｆｅｒは、画像供給デバイスによるデータフレームの書込み動作を示すもので、プリンタに設定したバッファアドレスに対してデータを順次書込む動作を行うものである。
【０２２９】
ステップＳ７０８のＷｒｉｔｅＴｒａｎｓａｃｔｉｏｎＲｅｓｐｏｎｓｅは、データフレームを同期転送したときのレスポンスパケットを示す。前述したように、プリンタのデータ取込み速度が充分に速ければ、一つのライトトランザクションのアクノリッジを使って処理を完了することができるが、データの取込みに時間がかかる場合はスプリットトランザクションとして独立したレスポンスが発生することになる。
【０２３０】
ステップＳ７１０は複数のデータフレームの転送処理を示す。つまり、ＢｕｆｆｅｒＣｏｎｆｉｇコマンドで設定したバッファサイズに対して連続するライトトランザクションによりデータを転送する。このように連続したライトトランザクションを用いるデータ転送方式を「ＰＵＳＨ型データ転送方式」あるいは略して「ＰＵＳＨ方式」と呼ぶ。
【０２３１】
図６７はデータフレームにおけるデータパケットの構成例を示す図で、プリンタのバッファを直接アドレスしてデータを書込むことができるので、データパケット６７−１はヘッダなどを含まない構成にすることができる。
【０２３２】
図６８はプリンタのデータレジスタとバッファの関係例を示す図で、データレジスタ６８−１に書込まれたデータは、オフセットＤｅｓｔｉｎａｔｉｏｎ＿Ｏｆｆｓｅｔにより決定されるＢｕｆｆｅｒＡｄｄｒｅｓｓが指すプリンタのメモリ空間６８−２のアドレスに直接書込まれる。オフセット値は、データ長Ｄａｔａ＿Ｌｅｎｇｔｈ分ずつインクリメントされるので、連続したバッファアドレスに対して繰返しデータを書込むことで、バッファサイズＢｕｆｆｅｒＳｉｚｅで示される領域内にデータが連続して書込むことができる。
【０２３３】
［転送方式４］
図６９はＰＵＬＬ  Ｂｕｆｆｅｒ  Ｍｏｄｅｌにおける画像供給デバイスおよびプリンタのコマンドレジスタ、レスポンスレジスタおよびデータレジスタの構成例を示す図である。
【０２３４】
ＦＣＰに準拠した画像供給デバイスおよびプリンタ間のコマンドおよびレスポンスは、画像供給デバイスのコマンドレジスタ６９−１からプリンタのコマンドレジスタ６９−４にコマンドの要求データとしてのコマンドフレーム６９−７を書込む動作と、プリンタのレスポンスレジスタ６９−５から画像供給デバイスのレスポンスレジスタ６９−２にレスポンスデータとしてレスポンスフレーム６９−８を書込む動作により実行される。
【０２３５】
また、データフレーム６９−９についてはＦＣＰとは異なり、リードトランザクションを用いて画像供給デバイスのデータレジスタ６９−３からプリンタのデータレジスタ６９−６へ画像データを読取る一方向動作に、データフレーム６９−９が使用される。
【０２３６】
図７０は画像供給デバイスおよびプリンタ間におけるＰＵＬＬバッファモデルの動作フローの一例を示す図である。なお、コマンドフレーム、レスポンスフレームにおける、Ｌｏｇｉｎ、Ｌｏｇｏｕｔ、ＯｐｅｎＣｈａｎｎｅｌ、ＣｌｏｓｅＣｈａｎｎｅｌ、フォーマット設定についての動作は前述した転送方式１と同様であり、ＢｕｆｆｅｒＣｏｎｆｉｇ、ＳｅｔＢｕｆｆｅｒのコマンドおよびレスポンス（Ｓ７１１からＳ７１４）については前述した転送方式３と同様であるから詳細な説明は省略する。
【０２３７】
図７０において、画像供給デバイスは、ＳｅｔＢｕｆｆｅｒコマンドのＮＯＴＩＦＹにより、データの転送を開始できることをプリンタに通知する（Ｓ７１５）。これに対してプリンタは、ＳｅｔＢｕｆｆｅｒレスポンスのＩＮＴＥＲＩＭにより、取り敢えず受信する準備ができたことを返し（Ｓ７１６）、データの転送を開始させる。そして、プリンタは、ＳｅｔＢｕｆｆｅｒレスポンスのＣＯＮＴＩＮＵＥにより、初めに設定されたバッファ領域に対するデータ転送が完了したことを画像供給デバイスに通知する（Ｓ７１９）。
【０２３８】
プリンタは、ＰｕｌｌＢｕｆｆｅｒリクエストにより、リードトランザクションを要求する（Ｓ７１７）。これに対して画像供給デバイスは、ＰｕｌｌＢｕｆｆｅｒレスポンスパケットによりデータを転送し（Ｓ７１８）、プリンタに設定されたバッファアドレスにデータが順次書込まれる。
【０２３９】
ステップＳ７２０は複数のデータフレームの転送処理を示す。つまり、ＢｕｆｆｅｒＣｏｎｆｉｇコマンドで設定したバッファサイズに対して連続するリードトランザクションによりデータを転送する。このように連続したリードトランザクションを用いるデータ転送方式を「ＰＵＬＬ型データ転送方式」あるいは略して「ＰＵＬＬ方式」と呼ぶ。
【０２４０】
図７１は画像供給デバイスのデータレジスタとバッファの関係例を示す図で、データレジスタ７１−１に設定されたオフセットＤｅｓｔｉｎａｔｉｏｎ＿Ｏｆｆｓｅｔにより決定されるＢｕｆｆｅｒＡｄｄｒｅｓｓが指す画像供給デバイスのメモリ空間７２−２のアドレスのデータをリードトランザクションにより読出す。オフセット値は、データ長Ｄａｔａ＿Ｌｅｎｇｔｈ分ずつインクリメントされるので、連続したバッファアドレスに対して繰返しデータを読出すことで、バッファサイズＢｕｆｆｅｒＳｉｚｅで示される領域からデータを連続して読出すことができる。
【０２４１】
［転送方式５］
Ｉｓｏｃｈｒｏｎｏｕｓ  Ｍｏｄｅｌである転送方式５は、前述した転送方式１の非同期ライトトランザクションを用いた印刷データの転送を、同期ライトトランザクションを用いた印刷データの転送に置き換えたものである。なお、データパケットの構成は、図５５および図５６に示した構成と同じである。また、ブロック転送におけるプリンタ内のデータパケットフレーム処理は、図５７に示した処理と同じである。
【０２４２】
なお、本転送方式によれば、同期ライトトランザクションを用いることにより、時間を定めてデータ転送することができる。
【０２４３】
また、ブロック転送することにより、例えば一頁分の印刷データをまとめて転送した際にエラーが発生すると、一頁分の印刷データを再送することになり時間がかかる。しかし、より細かいブロック単位、例えばインクジェットプリンタなどにおける印刷バンド単位で印刷データを転送すればエラー発生にともなう印刷データの再送を効率的に行うことができる。
【０２４４】
図７２はフロー制御のためのコマンドフレームおよびレスポンスフレームを示す図である。画像供給デバイスは、非同期ライトトランザクションにより、プリンタのコマンドレジスタ７５−３にコマンドフレームを書込む。これに対してプリンタは、非同期ライトトランザクションにより、そのコマンドに対するレスポンスフレームを画像供給デバイスのレスポンスレジスタ７５−２に書込む。
【０２４５】
図７３は印刷処理のフロー例を示す図である。まず、前述した転送方式１と同様に、画像供給デバイスはＬｏｇｉｎコマンドをプリンタへ送る（Ｓ５０７）。これに対してプリンタはＬｏｇｉｎレスポンスを返し（Ｓ５０８）、コネクションが確立される。
【０２４６】
次に、前述した転送方式１と同様に、画像供給デバイスは、フォーマット設定を行い（Ｓ５０９）、ＯｐｅｎＣｈａｎｎｅｌコマンドをプリンタへ送る（Ｓ５１０）。これに対してプリンタは、ＯｐｅｎＣｈａｎｎｅｌレスポンスを返し（Ｓ５１１）、論理チャネルがオープンされる。
【０２４７】
続いて、画像供給デバイスは、ＦｒｅｅＢｌｏｃｋコマンドをプリンタに送る（Ｓ５１２）。これに対してプリンタは、ＦｒｅｅＢｌｏｃｋレスポンスを返す（Ｓ５１３）。このＦｒｅｅＢｌｏｃｋレスポンスにはＦｒｅｅＢｌｏｃｋ数とＥｒｒｏｒＳｔａｔｕｓが含まれる。ＦｒｅｅＢｌｏｃｋ数は、プリンタのメモリ空間内にブロック単位で確保されたブロックバッファの数であり、ＥｒｒｏｒＳｔａｔｕｓは前回のブロック転送におけるエラー情報を画像供給デバイスに知らせるためのものである。なお、プリンタは、論理チャネルがオープンされた後の最初のＦｒｅｅＢｌｏｃｋコマンドに対するＥｒｒｏｒＳｔａｔｕｓには常に正常を返す。
【０２４８】
続いて、画像供給デバイスは、同期トランザクションにより印刷データをブロック転送する（Ｓ５１４）。このとき、画像供給デバイスは、ＦｒｅｅＢｌｏｃｋ数により示される数分のデータパケットを送出する。
【０２４９】
次に、画像供給デバイスは、ＦｒｅｅＢｌｏｃｋコマンドをプリンタに送る（Ｓ５１５）。これに対してプリンタは、ＦｒｅｅＢｌｏｃｋレスポンスを返す（Ｓ５１６）。このレスポンスのＥｒｒｏｒＳｔａｔｕｓが異常を示す場合、つまり先のブロック転送でエラーが生じた場合、画像供給デバイスはステップＳ５１４で転送したデータを再送する（Ｓ５１７）。この後、データ転送が正常に終了するまで、ステップＳ５１５、Ｓ５１６およびＳ５１７の処理を繰返し実行する。また、ＥｒｒｏｒＳｔａｔｕｓが正常を示す場合、画像供給デバイスはＦｒｅｅＢｌｏｃｋレスポンスに含まれるＦｒｅｅＢｌｏｃｋ数のデータパケットを送出する（Ｓ５１７）。
【０２５０】
なお、プリンタは、転送されるデータのヘッダ部のブロックカウント（図７３）を参照することにより、エラーが生じたか否かを認識することができる。また、転送すべきデータのブロック数よりＦｒｅｅＢｌｏｃｋ数の方が大きい場合、画像供給デバイスは、その大きい分に相当する数のダミーパケットを送出する。
【０２５１】
以降、画像供給デバイスから一連の印刷データがすべて出力されるまで同期トランザクションによるデータの転送が繰返される。
【０２５２】
データの転送が終わると、前述した転送方式１と同様に、画像供給デバイスは、ＣｌｏｓｅＣｈａｎｎｅｌコマンドおよびレスポンスにより論理チャネルを閉じ（Ｓ５１８およびＳ５１９）、ＤＰＰのＬｏｇｏｕｔコマンドおよびレスポンスによりプリンタからログアウトする（Ｓ５２０およびＳ５２１）。
【０２５３】
以上説明したように、本実施形態によれば、１３９４シリアルバスなどにより画像供給デバイスとプリンタを直結し、画像供給デバイスの画像データを直接プリンタへ送り、その画像データに基づく画像をプリンタに印刷させることができる。
【０２５４】
また、制御コマンドと印刷データとを分離することができるので、１３９４シリアルバスなどにおいて効率的なデータ転送方式を提供することができる。
【０２５５】
また、１３９４シリアルバスにおいて転送エラーを回復することが可能なデータ転送方式を提供することができる。
【０２５６】
また、データ転送用のレジスタ領域に関する空きブロック数を通知することにより、そのレジスタ領域にデータを書込む際の書込みの可否の判定を不要とし、その判定に要するオーバヘッドを削除したデータ転送方式を提供することができる。さらに、通知された空きブロック数分のデータをまとめて送信し受信するので、転送効率の良いデータ転送方式を提供することができる。
【０２５７】
また、複数のデータ転送方式の中から転送先のデバイスに合ったデータ転送方式を選択することができるデータ転送方式を提供することができる。
【０２５８】
また、ホストデバイスからターゲットデバイスへデータを転送する際に、コマンドとそれに対するレスポンスのやり取りを、データ転送の開始を指示するコマンドとそのコマンドに対するレスポンスだけにして、つまり、データ転送の開始後はコマンドの送信を行わないことで、コマンドの送信による転送効率の低下を回避したデータ転送方式を提供することができる。
【０２５９】
また、ホストデバイスとターゲットデバイス間でデータ転送を行う際に、ＰＵＳＨ方式またはＰＵＬＬ方式によるデータ転送方式を提供することができる。
【０２６０】
また、ホストデバイスとターゲットデバイス間でデータ転送を行う際に、同期転送と非同期転送を同じ転送手順で行うことができるデータ転送方式を提供することができる。
【０２６１】
また、ホストデバイスとターゲットデバイス間でデータ転送を行う際に、同期転送においてあるデータ単位で転送エラーが発生した場合に、そのデータ単位について再転送を行うことができるデータ転送方式を提供することができる。
【０２６２】
また、ホストデバイスとターゲットデバイス間でデータ転送を行う際に、バスリセットが発生した場合でも正しいデータ転送が行うことができるデータ転送方式を提供することができる。
【０２６３】
さらに、上記のデータ転送方法を利用するプリンタなどの周辺機器を提供することができる。
【０２６４】
【変形例】
上述した実施形態においては、ＦＣＰに基づいたコマンドおよびコマンドに対するレスポンスを用い、レスポンスに情報をセットしてホストデバイスに通知する方法を用いる例を説明したが、ＩＥＥＥ１３９４のメモリバスモデルの特徴である、メモリ上にレジスタをマッピングする方法も考えられる。
【０２６５】
この場合、メモリの特定のアドレスに割り当てられたコマンドレジスタにコマンドデータを書き込むことによりコマンドを実行させる。同様に、メモリの特定のアドレスに割り当てられたレスポンスレジスタのデータを読むことでレスポンスが示される。
【０２６６】
従って、ターゲットデバイスは、コマンドレジスタにコマンドが書き込まれたことを認識すると、そのコマンドを実行し、その後、レスポンスレジスタにその結果や情報を書き込む。ホストデバイスは、コマンドレジスタにコマンドを書き込んだ後、ターゲットデバイスのレスポンスレジスタを読むことで、コマンドの実行結果や情報を得ることができる。
【０２６７】
このように、メモリバスモデルでのレジスタを用いて本発明を実現することもできる。
【０２６８】
また、上述した実施形態においてはＩＥＥＥ１９３４に規定されるシリアルインタフェイスを用いてネットワークを構成する例を説明したが、本発明はこれに限定されるものではなく、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ）と呼ばれるシリアルインタフェイスなど、任意のシリアルインタフェイスを用いて構成されるネットワークにも適用することができる。
【０２６９】
【他の実施形態】
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器，リーダ，プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用してもよい。
【０２７０】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０２７１】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２７２】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２７３】
【発明の効果】
以上説明したように、本発明によれば、１３９４シリアルバスなどによりホストデバイスとターゲットデバイスを直結し、ホストデバイスから直接ターゲットデバイスへ送られる画像データの処理をターゲットデバイスに行わせるのに適したデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体を提供することができる。
【０２７４】
また、制御コマンドとデータの分離が可能で転送効率のよいデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体を提供することができる。
【０２７５】
また、接続するデバイスに合ったデータ転送方法を設定するデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体を提供することができる。
【０２７６】
また、プル（ＰＵＬＬ）方式によるデータ転送を行うデータ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体を提供することができる。
【図面の簡単な説明】
【図１】本発明を適用するシステムの一般的な構成例を示す図、
【図２】１３９４シリアルバスによるネットワークの構成例を示す図、
【図３】１３９４シリアルバスの構成例を示す図、
【図４】１３９４シリアルバスにおけるアドレス空間の一例を示す図、
【図５】１３９４シリアルバス用のケーブルの断面を示す図、
【図６】１３９４シリアルバスで採用されている、データ転送方式のＤＳ−Ｌｉｎｋ方式を説明するための図、
【図７】バスリセット信号の発生から、ノードＩＤが決定し、データ転送が行えるようになるまでの一連のシーケンス例を示すフローチャート、
【図８】バスリセット信号の監視からルートノードの決定までの詳細例を示すフローチャート、
【図９】ノードＩＤ設定の詳細例を示すフローチャート、
【図１０】１３９４シリアルバスのネットワーク動作例を示す図、
【図１１】１３９４シリアルバスのＣＳＲアーキテクチャの機能を示す図、
【図１２】１３９４シリアルバスに関するレジスタを示す図、
【図１３】１３９４シリアルバスのノード資源に関するレジスタを示す図、
【図１４】１３９４シリアルバスのコンフィギュレーションＲＯＭの最小形式を示す図、
【図１５】１３９４シリアルバスのコンフィギュレーションＲＯＭの一般形式を示す図、
【図１６】バス使用権の要求を説明する図、
【図１７】バス使用の許可を説明する図、
【図１８】１３９４シリアルバスにおけるアービトレーションの流れを示すフローチャート、
【図１９】トランザクションレイヤにおけるＣＳＲアーキテクチャに基づくリード、ライト、ロックの各コマンドの要求・レスポンスプロトコルを示す図、
【図２０】リンクレイヤにおけるサービスを示す図、
【図２１】非同期転送における時間的な遷移を示す図、
【図２２】非同期転送用パケットのフォーマットを示す図、
【図２３】スプリットトランザクションの動作例を示す図、
【図２４】スプリットトランザクションを行う場合の転送状態の時間的遷移例を示す図、
【図２５】同期転送における時間的な遷移を示す図、
【図２６】同期転送用のパケットフォーマット例を示す図、
【図２７】１３９４シリアルバスにおける同期転送のパケットフォーマットのフィールドの詳細を示す図、
【図２８】同期転送と非同期転送が混在するときの転送状態の時間的遷移を示す図、
【図２９】１３９４シリアルバスにおけるＡＶ／Ｃトランザクションの動作を示す図、
【図３０】ＦＣＰパケットフレームを含む非同期転送のパケットフォーマットを示す図、
【図３１】ＡＶ／Ｃコマンドフレームの構造を示す図、
【図３２】ＡＶ／Ｃレスポンスフレームの構造を示す図、
【図３３】１３９４シリアルバスのインタフェイスをＯＳＩモデルの各層と対比させた図、
【図３４】ＬＯＧＩＮプロトコルの基本動作を示す図、
【図３５】１３９４シリアルバスにおける接続形態の一例を示す図、
【図３６】ログイン動作の流れを示す図、
【図３７】ＬＯＧＩＮプロトコルのためにターゲットデバイスであるプリンタが備える１３９４シリアルバスのＣＳＲを示す図、
【図３８】ホストデバイスにおけるログイン処理を示すフローチャート、
【図３９】ターゲットデバイスであるプリンタのログイン処理を示すフローチャート、
【図４０】ＬＯＧＩＮプロトコルを実装していないデバイスを考慮した例を説明する図、
【図４１】図４０に示した構成とＯＳＩモデルの各層とを対比させた図、
【図４２】レジスタマップを示す図、
【図４３】画像供給デバイスからプリンタへのフレームの流れを示す図、
【図４４】フォーマットレジスタの構成例を示す図、
【図４５】共通レジスタグループのステータスレジスタｓｔａｔｕｓ  ｒｅｇｉｓｔｅｒの詳細な構成例を示す図、
【図４６】共通レジスタグループのレジスタＧＬＯＢＡＬに保持される情報の詳細例を示す図、
【図４７】共通レジスタグループのレジスタＬＯＣＡＬに保持される情報の詳細例を示す図、
【図４８】レジスタｆｏｒｍａｔ［１］に保持される情報の一例を示す図、
【図４９】レジスタｆｏｒｍａｔ［２］に保持される情報の一例を示す図、
【図５０】コマンドおよびコマンドに対するレスポンスの一覧を示す図、
【図５１】ＤＰＰがサポートする画像データフォーマット例を示す図、
【図５２】フォーマット設定処理の流れを示す図、
【図５３】データ転送方式の設定手順の一例を示す図、
【図５４】転送方式１および転送方式２に必要なレジスタの１３９４シリアルバスのアドレス空間におけるレジスタマップを示す図、
【図５５】データパケットフレームの一例を示す図、
【図５６】データヘッダの構成例を示す図、
【図５７】ブロック転送におけるプリンタ内のデータパケットフレーム処理を示す図、
【図５８】転送方式１におけるＦｒｅｅＢｌｏｃｋコマンドおよびレスポンスを示す図、
【図５９】転送方式１におけるデータ転送フローの一例を示す図、
【図６０】転送方式２におけるデータ転送フローの一例を示す図、
【図６１】転送方式１におけるＦｒｅｅＢｌｏｃｋコマンドおよびレスポンスを詳細に示す図、
【図６２】転送方式１および転送方式２のＷｒｉｔｅＢｌｏｃｋを詳細に示す図、
【図６３】転送方式１および転送方式２のＷｒｉｔｅＢｌｏｃｋを詳細に示す図、
【図６４】バスリセットが発生した場合のＷｒｉｔｅＢｌｏｃｋのエラー処理を説明する図、
【図６５】ＰＵＳＨ  Ｌａｒｇｅ  Ｂｕｆｆｅｒ  Ｍｏｄｅｌにおける画像供給デバイスおよびプリンタのコマンドレジスタ、レスポンスレジスタおよびデータレジスタの構成例を示す図、
【図６６】画像供給デバイスおよびプリンタ間におけるＰＵＳＨバッファモデルの動作フローの一例を示す図、
【図６７】データフレームにおけるデータパケットの構成例を示す図、
【図６８】プリンタのデータレジスタとバッファの関係例を示す図、
【図６９】ＰＵＬＬ  Ｂｕｆｆｅｒ  Ｍｏｄｅｌにおける画像供給デバイスおよびプリンタのコマンドレジスタ、レスポンスレジスタおよびデータレジスタの構成例を示す図、
【図７０】画像供給デバイスおよびプリンタ間におけるＰＵＬＬバッファモデルの動作フローの一例を示す図、
【図７１】画像供給デバイスのデータレジスタとバッファの関係例を示す図、
【図７２】フロー制御のためのコマンドフレームおよびレスポンスフレームを示す図、
【図７３】印刷処理のフロー例を示す図である。
【図１】
0003566495.tif 000002
【図２】
0003566495.tif 000003
【図３】
0003566495.tif 000004
【図４】
0003566495.tif 000005
【図５】
0003566495.tif 000006
【図６】
0003566495.tif 000007
【図７】
0003566495.tif 000008
【図８】
0003566495.tif 000009
【図９】
0003566495.tif 000010
【図１０】
0003566495.tif 000011
【図１１】
0003566495.tif 000012
【図１２】
0003566495.tif 000013
【図１３】
0003566495.tif 000014
【図１４】
0003566495.tif 000015
【図１５】
0003566495.tif 000016
【図１６】
0003566495.tif 000017
【図１７】
0003566495.tif 000018
【図１８】
0003566495.tif 000019
【図１９】
0003566495.tif 000020
【図２０】
0003566495.tif 000021
【図２１】
0003566495.tif 000022
【図２２】
0003566495.tif 000023
【図２３】
0003566495.tif 000024
【図２４】
0003566495.tif 000025
【図２５】
0003566495.tif 000026
【図２６】
0003566495.tif 000027
【図２７】
0003566495.tif 000028
【図２８】
0003566495.tif 000029
【図２９】
0003566495.tif 000030
【図３０】
0003566495.tif 000031
【図３１】
0003566495.tif 000032
【図３２】
0003566495.tif 000033
【図３３】
0003566495.tif 000034
【図３４】
0003566495.tif 000035
【図３５】
0003566495.tif 000036
【図３６】
0003566495.tif 000037
【図３７】
0003566495.tif 000038
【図３８】
0003566495.tif 000039
【図３９】
0003566495.tif 000040
【図４０】
0003566495.tif 000041
【図４１】
0003566495.tif 000042
【図４２】
0003566495.tif 000043
【図４３】
0003566495.tif 000044
【図４４】
0003566495.tif 000045
【図４５】
0003566495.tif 000046
【図４６】
0003566495.tif 000047
【図４７】
0003566495.tif 000048
【図４８】
0003566495.tif 000049
【図４９】
0003566495.tif 000050
【図５０】
0003566495.tif 000051
【図５１】
0003566495.tif 000052
【図５２】
0003566495.tif 000053
【図５３】
0003566495.tif 000054
【図５４】
0003566495.tif 000055
【図５５】
0003566495.tif 000056
【図５６】
0003566495.tif 000057
【図５７】
0003566495.tif 000058
【図５８】
0003566495.tif 000059
【図５９】
0003566495.tif 000060
【図６０】
0003566495.tif 000061
【図６１】
0003566495.tif 000062
【図６２】
0003566495.tif 000063
【図６３】
0003566495.tif 000064
【図６４】
0003566495.tif 000065
【図６５】
0003566495.tif 000066
【図６６】
0003566495.tif 000067
【図６７】
0003566495.tif 000068
【図６８】
0003566495.tif 000069
【図６９】
0003566495.tif 000070
【図７０】
0003566495.tif 000071
【図７１】
0003566495.tif 000072
【図７２】
0003566495.tif 000073
【図７３】
0003566495.tif 000074