JP4109983B2 - 通信システム - Google Patents
通信システム Download PDFInfo
- Publication number
- JP4109983B2 JP4109983B2 JP2002373106A JP2002373106A JP4109983B2 JP 4109983 B2 JP4109983 B2 JP 4109983B2 JP 2002373106 A JP2002373106 A JP 2002373106A JP 2002373106 A JP2002373106 A JP 2002373106A JP 4109983 B2 JP4109983 B2 JP 4109983B2
- Authority
- JP
- Japan
- Prior art keywords
- command
- node
- data
- orb
- commands
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４等のインターフェースで接続される通信システムに関するものである。
【０００２】
【従来の技術】
セントロニクス、ＵＳＢ、そしてIEEE1394等の各種インターフェースにおいてホストとデバイスの１対１接続で通信を行なう場合、ホスト−デバイス間では、デバイスの各種機能を制御するために通信プロトコルの１セッション中に複数の論理チャネル接続を樹立し、チャネルごとにデータ転送を行なう。
【０００３】
IEEE1394上のデータ通信プロトコルであるＳＢＰ−２は、ひとつのイニシエータとひとつのターゲットの対から構成されるひとつのロジカルユニットにおいて、データ転送の単位であるＯＲＢ１個に対して１つのデータバッファが参照される。そのため、片方向の単一データチャネルあるいは片方向半二重のデータ通信を行なう仕組みになっており、複数論理チャネルを実現するのは困難である。現在規格策定中のＳＢＰ−２の機能拡張版であるＳＢＰ−３においてはこの点に注目し、ロジカルユニットにおけるデータ転送の単位であるＯＲＢに対して２つのデータバッファを参照できるようにして１ロジカルユニットにつき２つのデータ転送チャネルを実現することを可能とする拡張が行なわれた。
【０００４】
【発明が解決しようとする課題】
しかしながらＳＢＰ−３のデータ転送においては２つのデータ転送チャネルのフローコントロールはあくまでもＯＲＢ単位で行なわれるため、何らかの理由によりどちらかのデータ転送チャネルにおいてデータの送受信が出来なくなった場合、またどちらかのデータ転送チャネルのデータ転送が他のチャネルよりも遅い場合、速いほうのチャネルが遅いチャネルの影響を受けてしまう。これは、片方のデータバッファに対するアクセスが正常終了しても、もう片方のデータバッファへのアクセスが完了しないとそのＯＲＢに対する完了通知（ステータスブロック）をＳＢＰ−３のイニシエータに対して通知できないためで、ロジカルユニットとしてのデータ転送が滞ってしまう為である。
【０００５】
また１つのＯＲＢに２つのデータバッファとコマンドを配置することが出来るコマンドセットをＳＢＰ−３で実現するような場合、ターゲットデバイスによっては各コマンドが独立した条件に従って実行されることでより効率的なデータ転送を行うことが出来る場合がある。
【０００６】
本発明は上記従来例に鑑みてなされたもので、コマンドごとに独立した条件を設定することを可能とし、コマンドごとに設定された条件に応じて実行する通信システムを提供することを目的とする。
【０００７】
【課題を解決するための手段】
上記目的を達成するために本発明の通信システムは次の構成を備える。
【０００８】
一次側装置において、１つのコマンドブロックに複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てて二次側装置に引き渡し、二次側装置において、コマンドブロックに含まれる複数のコマンドを独立して実行する通信システムであって、
前記一次側装置は、前記各データバッファに対応した複数のコマンドそれぞれに対して独立した条件を設定し、当該独立した条件がそれぞれ設定された複数のコマンドを含む１つのコマンドブロックを作成し、作成された前記１つのコマンドブロックを前記二次側装置に送信し、
前記二次側装置は、前記一次側装置から送信された前記１つのコマンドブロックを受信し、当該コマンドブロックに含まれる複数のコマンドを、それぞれのコマンドに設定されている条件に応じて実行する。
【０００９】
【発明の実施の形態】
図１は、本発明を最もよくあらわす図であり、ＩＥＥＥ１３９４で接続されたホストコンピュータ（以下ホスト）１−ａとプリンタ１−ｂを表している。
【００１０】
コンピュータＡとプリンタＢの通信は、ＩＥＥＥ１３９４インターフェース上で使われる代表的なデータ転送プロトコルであるＳＢＰ（Serial Bus Protocol）−３（改）プロトコルを使って行なわれ、ホストープリンタ間のデータ転送を行なうための通信チャネルとしてＬＵＮ０が予め定められている。なおＳＢＰ−３（改）プロトコルは標準化されているＳＢＰ−３に若干の変更を施したもので、その概要は後述する。
【００１１】
本実施形態では、ＳＢＰ−３改プロトコル上において、イニシエータのクラスドライバ１０１（本実施形態ではプリンタクラス）と、ターゲットのコマンド処理部１０３との間で定義されたプロトコル層が定義されており、さらにその上に、イニシエータ上のプリンタドライバ１０１とターゲット上のＰＤＬ処理部１０４との間において、アプリケーション層のプロトコルが定義されている。アプリケーション層における取り決めは、ページ記述言語（ＰＤＬ）の定義がその中心となる。中間層は、ＳＢＰ−３とアプリケーション層との間にあってデバイスの種類等に応じて定義され、本実施形態ではデバイスがプリンタであるとして定義されている。この層における処理手順についても後述する。
【００１２】
〈ＩＥＥＥ１３９４の技術の概要〉
以下、本実施例のデジタルインタフェースに適用されるＩＥＥＥ１３９４−１９９５規格の技術について簡単に説明する。尚、ＩＥＥＥ１３９４−１９９５規格（以下、ＩＥＥＥ１３９４規格）についての詳細は、１９９６年の８月３０日にＩＥＥＥ（The Institute of Electrical and Electronics Engineers, Inc．）から出版された「ＩＥＥＥ Standard for a High Performance Serial Bus」に記述されている。
【００１３】
（１）概要
図２にＩＥＥＥ１３９４規格に準拠したデジタルインタフェース（以下、１３９４インタフェース）を具備するノードにより構成される通信システム（以下、１３９４ネットワーク）の一例を示す。１３９４ネットワークは、シリアルデータの通信可能なバス型ネットワークを構成するものである。
【００１４】
図２において、各ノードＡ〜Ｆは、ＩＥＥＥ１３９４規格に準拠した通信ケーブルを介して接続されている。これらのノードＡ〜Ｈは、例えば、ＰＣ（Personal Computer）、デジタルＶＴＲ（Video Tape Recorder）、ＤＶＤ（Digital Video Disc）プレーヤ、デジタルカメラ、ハードディスク、モニタ等の電子機器である。
【００１５】
１３９４ネットワークの接続方式は、ディジーチェーン方式とノード分岐方式とに対応しており、自由度の高い接続を可能としている。
【００１６】
又、１３９４ネットワークでは、例えば、既存の機器を削除したり、新たな機器を追加したり、既存の機器の電源をON／OFFしたりした場合に、自動的にバスリセットを行う。このバスリセットを行うことにより、１３９４ネットワークは、新たな接続構成の認識と各機器に対するＩＤ情報の割り当てとを自動的に行うことができる。この機能によって、１３９４ネットワークは、ネットワークの接続構成を常時認識することができる。
【００１７】
又、１３９４ネットワークは、他の機器から転送されたデータを中継する機能を有している。この機能により、全ての機器がバスの動作状況を把握することができる。
【００１８】
又、１３９４ネットワークは、Plug＆Playと呼ばれる機能を有している。この機能により、全ての機器の電源をＯＦＦにすることなく、接続するだけで自動に接続機器を認識することができる。
【００１９】
又、１３９４ネットワークは、１００／２００／４００Ｍｂｐｓのデータ転送速度に対応している。上位のデータ転送速度を持つ機器は、下位のデータ転送速度をサポートすることができるため、異なるデータ転送速度に対応する機器同士を接続することができる。
【００２０】
更に、１３９４ネットワークは、２つの異なるデータ転送方式（即ち、Asynchronous転送モードとIsochronous転送モード）に対応している。
【００２１】
Asynchronous転送モードは、必要に応じて非同期に転送することが要求されるデータ（即ち、コントロール信号やファイルデータ等）を転送する際に有効である。又、Isochronous転送モードは、所定量のデータを一定のデータレートで連続的に転送することが要求されるデータ（即ち、ビデオデータやオーディオデータ等）を転送する際に有効である。
【００２２】
Asynchronous転送モードとIsochronous転送モードとは、各通信サイクル（通常１サイクルは、１２５μＳ）内において、混在させることが可能である。各転送モードは、サイクルの開始を示すサイクル・スタート・パケット（以下、ＣＳＰ）の転送後に実行される。 尚、各通信サイクル期間において、Isochronous転送モードは、Asynchronous転送モードよりも優先順位が高く設定されている。又、Isochronous転送モードの転送帯域は、各通信サイクル内で保証されている。
【００２３】
（２）アーキテクチャ
次に、図３を用いて１３９４インタフェースの構成要素を説明する。
【００２４】
１３９４インタフェースは、機能的に複数のレイヤ（階層）から構成されている。図３において、１３９４インタフェースは、ＩＥＥＥ１３９４規格に準拠した通信ケーブル３０１を介して他のノードの１３９４インタフェースと接続される。又、１３９４インタフェースは、１つ以上の通信ポート３０２を有し、通信ポート３０２は、ハードウェア部に含まれるフィジカル・レイヤ３０３と接続される。
【００２５】
図３において、ハードウェア部は、フィジカル・レイヤ３０３とリンク・レイヤ３０４とから構成されている。フィジカル・レイヤ３０３は、他のノードとの物理的、電気的なインタフェース、バスリセットの検出とそれに伴う処理、入出力信号の符号化／復号化、バス使用権の調停等を行う。又、リンク・レイヤ３０４は、通信パケットの生成と送受信、サイクルタイマの制御等を行なう。
【００２６】
又、図３において、ファームウェア部は、トランザクション・レイヤ３０５とシリアル・バス・マネージメント３０６とを含んでいる。トランザクション・レイヤ３０５は、Asynchronous転送モードを管理し、各種のトランザクション（リード、ライト、ロック）を提供する。シリアル・バス・マネージメント３０６は、後述するＣＳＲアーキテクチャに基づいて、自ノードの制御、自ノードの接続状態の管理、自ノードのＩＤ情報の管理、シリアルバスネットワークの資源管理を行う機能を提供する。
【００２７】
以上、ハードウェア部とファームウェア部とが実質的に１３９４インタフェースを構成するものであり、それらの基本構成は、ＩＥＥＥ１３９４規格により規定されている。
【００２８】
又、ソフトウェア部に含まれるアプリケーション・レイヤ３０７は、使用するアプリケーションソフトによって異なり、ネットワーク上でどのようにデータを通信するのかを制御する。例えば、デジタルＶＴＲの動画像データの場合は、ＡＶ／Ｃプロトコルなどの通信プロトコルによって規定されている。
【００２９】
（２−１）リンク・レイヤ３０４
図４は、リンク・レイヤ３０４の提供可能なサービスを示す図である。図４において、リンク・レイヤ３０４は、次の４つのサービスを提供する。即ち、(1)応答ノードに対して所定のパケットの転送を要求するリンク要求（LK_DATA.request）、(2)応答ノードに所定のパケットの受信を通知するリンク通知（LK_DATA.indication）、(3)応答ノードからのアクノリッジを受信したことを示すリンク応答（LK_DATA.response）、(4)要求ノードからのアクノリッジを確認するリンク確認（LK_DATA.confirmation）である。尚、リンク応答（LK_DATA.response）は、ブロードキャスト通信、Isochronousパケットの転送の場合には存在しない。
【００３０】
又、リンク・レイヤ３０４は、上述のサービスに基づいて、上述の２種類の転送方式、即ち、Asynchronous転送モード、Isochronous転送モードを実現する。
【００３１】
（２−２）トランザクション・レイヤ３０５
図５は、トランザクション・レイヤ３０５の提供可能なサービスを示す図である。図５において、トランザクション・レイヤ３０５は、次の４つのサービスを提供する。即ち、(1)応答ノードに対して所定のトランザクションを要求するトランザクション要求（TR_DATA.request）、(2)応答ノードに所定のトランザクション要求の受信を通知するトランザクション通知（TR_DATA.indication）、(3)応答ノードからの状態情報（ライト、ロックの場合は、データを含む）を受信したことを示すトランザクション応答（TR_DATA.response）、(4)要求ノードからの状態情報を確認するトランザクション確認（TR_DATA.confirmation）である。
【００３２】
又、トランザクション・レイヤ３０５は、上述のサービスに基づいてAsynchronous転送を管理し、次の３種類のトランザクション、即ち、(1)リード・トランザクション、(2)ライト・トランザクション、(3)ロック・トランザクションを実現する。
(1)リード・トランザクションは、要求ノードが応答ノードの特定アドレスに格納された情報を読み取る。
(2)ライト・トランザクションは、要求ノードが応答ノードの特定アドレスに所定の情報を書き込む。
(3)ロック・トランザクションは、要求ノードが応答ノードに対して参照データと更新データとを転送し、応答ノードの特定アドレスの情報とその参照データとを比較し、その比較結果に応じて特定アドレスの情報を更新データに更新する。
【００３３】
（２−３）シリアル・バス・マネージメント３０６
シリアル・バス・マネージメント３０６は、具体的に、次の３つの機能を提供することができる。３つの機能とは、即ち、(1)ノード制御、(2)アイソクロナス・リソース・マネージャ（以下、ＩＲＭ）、(3)バスマネージャである。
【００３４】
(1)ノード制御は、上述の各レイヤを管理し、他のノードとの間で実行されるAsynchronous転送を管理する機能を提供する。
【００３５】
(2)ＩＲＭは、他のノードとの間で実行されるIsochronous転送を管理する機能を提供する。具体的には、転送帯域幅とチャネル番号の割り当てに必要な情報を管理し、これらの情報を他のノードに対して提供する。
【００３６】
ＩＲＭは、ローカルバス上に唯一存在し、バスリセット毎に他の候補者（ＩＲＭの機能を有するノード）の中から動的に選出される。又、ＩＲＭは、後述のバスマネージャの提供可能な機能（接続構成の管理、電源管理、速度情報の管理等）の一部を提供してもよい。
【００３７】
(3)バスマネージャは、ＩＲＭの機能を有し、ＩＲＭよりも高度なバス管理機能を提供する。具体的には、より高度な電源管理（通信ケーブルを介して電源の供給が可能か否か、電源の供給が必要か否か等の情報を各ノード毎に管理）、より高度な速度情報の管理（各ノード間の最大転送速度の管理）、より高度な接続構成の管理（トポロジ・マップの作成）、これらの管理情報に基づくバスの最適化等を行ない、更にこれらの情報を他のノードに提供する機能を有する。
【００３８】
又、バスマネージャは、シリアルバスネットワークを制御するためのサービスをアプリケーションに対して提供できる。ここで、サービスには、シリアルバス制御要求（SB_CONTROL.request）、シリアルバス・イベント制御確認（SB_CONTROL.confirmation）、シリアルバス・イベント通知（SB_CONTROL.indication）等がある。
【００３９】
SB_CONTROL.requestは、アプリケーションがバスリセットを要求するサービスである。SB_CONTROL.confirmationは、SB_CONTROL.requestをアプリケーションに対して確認するサービスである。SB_CONTROL.indicationは、非同期に発生するイベントをアプリケーションに対して通知するサービスである。
【００４０】
（３）アドレス指定
図６は、１３９４インタフェースにおけるアドレス空間を説明する図である。尚、１３９４インタフェースは、ISO/IEC 13213:1994に準じたＣＳＲ（Command and Status Register）アーキテクチャに従い、６４ビット幅のアドレス空間を規定している。
【００４１】
図６において、最初の１０ビットのフィールド６０１は、所定のバスを指定するＩＤ番号に使用され、次の６ビットのフィールド６０２は、所定の機器（ノード）を指定するＩＤ番号に使用される。この上位１６ビットを「ノードＩＤ」と呼び、各ノードはこのノードＩＤにより他のノードを識別する。又、各ノードは、このノードＩＤを用いて相手を識別した通信を行うことができる。
【００４２】
残りの４８ビットからなるフィールドは、各ノードの具備するアドレス空間（２５６Ｍバイト構造）を指定する。その内の２０ビットのフィールド６０３は、アドレス空間を構成する複数の領域を指定する。
【００４３】
フィールド６０３において、「０〜０ｘＦＦＦＦＤ」の部分は、メモリ空間と呼ばれる。「０ｘＦＦＦＦＥ」の部分は、プライベート空間と呼ばれ、各ノードで自由に利用できるアドレスである。又、「０ｘＦＦＦＦＥ」の部分は、レジスタ空間と呼ばれ、バスに接続されたノード間において共通の情報を格納する。各ノードは、レジスタ空間の情報を用いることにより、各ノード間の通信を管理することができる。
【００４４】
最後の２８ビットのフィールド６０４は、各ノードにおいて共通或いは固有となる情報が格納されるアドレスを指定する。
【００４５】
例えば、レジスタ空間において、最初の５１２バイトは、ＣＳＲアーキテクチャーのコア（ＣＳＲコア）レジスタ用に使用される。ＣＳＲコア・レジスタに格納される情報のアドレス及び機能を図７に示す。図中のオフセットは、「０ｘＦＦＦＦＦ０００００００」からの相対位置である。
【００４６】
次の５１２バイトは、シリアルバス用のレジスタとして使用される。シリアルバス・レジスタに格納される情報のアドレス及び機能を図８に示す。図中のオフセットは、「０ｘＦＦＦＦＦ００００２００」からの相対位置である。
【００４７】
その次の１０２４バイトは、Configuration ROM用に使用される。
【００４８】
Configuration ROMには最小形式と一般形式とがあり、「０ｘＦＦＦＦＦ００００４００」から配置される。最小形式のConfiguration ROMを図９に示す。図９において、ベンダＩＤは、ＩＥＥＥにより各ベンダに対して固有に割り当てられた２４ビットの数値である。
【００４９】
又、一般形式のConfiguration ROMを図１０に示す。図１０において、上述のベンダＩＤは、Root Directory１００２に格納されている。Bus Info Block１００１とRoot Leaf１００５とには、各ノードを識別する固有のＩＤ情報としてノードユニークＩＤを保持することが可能である。
【００５０】
ここで、ノードユニークＩＤは、メーカ、機種に関わらず、１つのノードを特定することのできる固有のＩＤを定めるようになっている。ノードユニークＩＤは６４ビットにより構成され、上位２４ビットは上述のベンダＩＤを示し、下位４８ビットは各ノードを製造するメーカにおいて自由に設定可能な情報（例えば、ノードの製造番号等）を示す。尚、このノードユニークＩＤは、例えばバスリセットの前後で継続して特定のノードを認識する場合に使用される。
【００５１】
又、図１０において、Root Directory１００２には、ノードの基本的な機能に関する情報を保持することが可能である。詳細な機能情報は、Root Directory１００２からオフセットされるサブディレクトリ（Unit Directories１００４）に格納される。Unit Directories１００４には、例えば、ノードのサポートするソフトウェアユニットに関する情報が格納される。具体的には、ノード間のデータ通信を行うためのデータ転送プロトコル、所定の通信手順を定義するコマンドセット等に関する情報が保持される。
【００５２】
又、図１０において、Node Dependent Info Directory１００３には、デバイス固有の情報を保持することが可能である。Node Dependent Info Directory１００３は、Root Directory１００２によりオフセットされる。
【００５３】
更に、図１０において、Vendor Dependent Information１００６には、ノードを製造、或いは販売するベンダ固有の情報を保持することができる。
【００５４】
残りの領域は、ユニット空間と呼ばれ、各ノード固有の情報、例えば、各機器の識別情報（会社名、機種名等）や使用条件等が格納されたアドレスを指定する。ユニット空間のシリアルバス装置レジスタに格納される情報のアドレス及び機能を図１１に示す。図中のオフセットは、「０ｘＦＦＦＦＦ００００８００」からの相対位置である。
【００５５】
尚、一般的に、異種のバスシステムの設計を簡略化したい場合、各ノードは、レジスタ空間の最初の２０４８バイトのみを使うべきである。つまり、ＣＳＲコア・レジスタ、シリアルバス・レジスタ、Configuration ROM、ユニット空間の最初の２０４８バイトの合わせて４０９６バイトで構成することが望ましい。
【００５６】
（４）通信ケーブルの構成
図１２にＩＥＥＥ１３９４規格に準拠した通信ケーブルの断面図を示す。
【００５７】
通信ケーブルは、２組のツイストペア信号線と電源ラインとにより構成されている。電源ラインを設けることによって、１３９４インタフェースは、主電源のＯＦＦとなった機器、故障により電力低下した機器等にも電力を供給することができる。尚、電源線内を流れる電源の電圧は８〜４０Ｖ、電流は最大電流ＤＣ１．５Ａと規定されている。
【００５８】
２組のツイストペア信号線には、DS-Link（Data/Strobe Link）符号化方式にて符号化された情報信号が伝送される。図１３は、DS-Link符号化方式を説明する図である。
【００５９】
このDS-Link符号化方式は、高速なシリアルデータ通信に適しており、その構成は、２組のより対線を必要とする。一組のより対線は、データ信号を送り、他のより対線は、ストローブ信号を送る構成になっている。受信側は、２組の信号線から受信したデータ信号とストローブ信号との排他的論理和をとることによって、クロックを再現することができる。
【００６０】
尚、DS-Link符号化方式を用いることにより、１３９４インタフェースには、例えば次のような利点がある。(1)他の符号化方式に比べて転送効率が高い。(2)ＰＬＬ回路が不要となり、コントローラＬＳＩの回路規模を小さくできる。(3)アイドル状態であることを示す情報を送る必要が無いため、トランシーバ回路をスリープ状態とし易く、消費電力の低減が図れる。
【００６１】
（５）バスリセット
各ノードの１３９４インタフェースは、ネットワークの接続構成に変化が生じたことを自動的に検出することができる。この場合、１３９４ネットワークは以下に示す手順によりバスリセットと呼ばれる処理を行う。尚、接続構成に変化は、各ノードの具備する通信ポートかかるバイアス電圧の変化により検知することができる。
【００６２】
ネットワークの接続構成の変化（例えば、ノードの挿抜、ノードの電源のＯＮ／ＯＦＦなどによるノード数の増減）を検出したノード、又は新たな接続構成を認識する必要のあるノードは、１３９４インタフェースを介して、バス上にバスリセット信号を送信する。
【００６３】
バスリセット信号を受信したノードの１３９４インタフェースは、バスリセットの発生を自身のリンク・レイヤ３０４に伝達すると共に、そのバスリセット信号を他のノードに転送する。バスリセット信号を受信したノードは、今まで認識していたネットワークの接続構成及び各機器に割り当てられたノードＩＤをクリアにする。最終的に全てのノードがバスリセット信号を検知した後、各ノードは、バスリセットに伴う初期化処理（即ち、新たな接続構成の認識と新たなノードＩＤの割り当て）を自動的に行う。
【００６４】
尚、バスリセットは、先に述べたような接続構成の変化による起動の他に、ホスト側の制御によって、アプリケーション・レイヤ３０７がフィジカル・レイヤ３０３に対して直接命令を出すことによって起動させることも可能である。
【００６５】
又、バスリセットが起動するとデータ転送は一時中断され、バスリセットに伴う初期化処理の終了後、新しいネットワークのもとで再開される。
【００６６】
（６）バスリセット起動後のシーケンス
バスリセットの起動後、各ノードの１３９４インタフェースは、新たな接続構成の認識と新たなノードＩＤの割り当てとを自動的に実行する。以下、バスリセットの開始からノードＩＤの割り当て処理までの基本的なシーケンスを図１４〜１６を用いて説明する。
【００６７】
図１４は、図２の１３９４ネットワークにおけるバスリセット起動後の状態を説明する図である。
【００６８】
図１４において、ノードＡは１つの通信ポート、ノードＢは２つの通信ポート、ノードＣは２つの通信ポート、ノードＤは３つの通信ポート、ノードＥは１つの通信ポート、ノードＦは１つの通信ポートを具備している。各ノードの通信ポートには、各ポートを識別するためにポート番号を付されている。
【００６９】
以下、図１４におけるバスリセットの開始からノードＩＤの割り当てまでを図１５のフローチャートを用いて説明する。
【００７０】
図１５において、１３９４ネットワークを構成する各ノードＡ〜Ｆは、バスリセットが発生したか否かを常時監視している（ステップＳ１５０１）。接続構成の変化を検出したノードからバスリセット信号が出力されると、各ノードは以下の処理を実行する。
【００７１】
バスリセットの発生後、各ノードは、夫々の具備する通信ポート間において親子関係の宣言を行なう（ステップＳ１５０２）。
【００７２】
各ノードは、全てのノード間の親子関係が決定されるまで、ステップＳ１５０２の処理を繰り返し行なう（ステップＳ１５０３）。
【００７３】
全てのノード間の親子関係が決定した後、１３９４ネットワークは、ネットワークの調停を行なうノード、即ちルートを決定する。（ステップＳ１５０４）。
【００７４】
ルートを決定した後、各ノードの１３９４インタフェース夫々は、自己のノードＩＤを自動的に設定する作業を実行する（ステップＳ１５０５）。
【００７５】
全てのノードに対してノードＩＤの設定がなされるまで、各ノードは所定の手順に基づきステップＳ１５０５の処理を実行する（ステップＳ１５０６）。
【００７６】
最終的に全てのノードに対してノードＩＤが設定された後、各ノードは、Isochronous転送或いはAsynchronous転送を実行する（ステップＳ１５０７）。
【００７７】
ステップＳ１５０７の処理を実行すると共に、各ノードの１３９４インタフェースは、再びバスリセットの発生を監視する。バスリセットが発生した場合には、ステップＳ１５０１以降の処理を再び実行する。
【００７８】
以上の手順により、各ノードの１３９４インタフェースは、バスリセットが起動する毎に、新たな接続構成の認識と新たなノードＩＤの割り当てとを自動的に実行することができる。
【００７９】
（７）親子関係の決定
次に、図１６を用いて、図１５に示したステップＳ１５０２の処理（即ち、各ノード間の親子関係を認識する処理）について詳細に説明する。
【００８０】
図１６において、バスリセットの発生後、１３９４ネットワーク上の各ノードＡ〜Ｆは、自分の具備する通信ポートの接続状態（接続又は未接続）を確認する（ステップＳ１６０１）。
【００８１】
通信ポートの接続状態の確認後、各ノードは、他のノードと接続されている通信ポート（以下、接続ポート）の数をカウントする（ステップＳ１６０２）。
【００８２】
ステップＳ１６０２の処理の結果、接続ポートの数が１つである場合、そのノードは、自分が「リーフ」であると認識する（ステップＳ１６０３）。ここで、リーフとは、１つのノードとのみ接続されているノードのことである。
【００８３】
リーフとなるノードは、その接続ポートに接続されているノードに対して、「自分は子（Ｃｈｉｌｄ）」であることを宣言する（ステップＳ１６０４）。このとき、リーフは、その接続ポートが「親ポート（親ノードと接続された通信ポート）」であると認識する。
【００８４】
ここで、親子関係の宣言は、まず、ネットワークの末端であるリーフとブランチとの間にて行われ、続いて、ブランチとブランチとの間で順次に行われる。各ノード間の親子関係は、早く宣言の行なえる通信ポートから順に決定される。又、各ノード間において、子であることを宣言した通信ポートは「親ポート」であると認識され、その宣言を受けた通信ポートは「子ポート（子ノードと接続された通信ポート）」であると認識される。例えば、図１４において、ノードＡ、Ｅ、Ｆは、自分がリーフであると認識した後、親子関係の宣言を行う。これにより、ノードＡ−Ｂ間では子−親、ノードＥ−Ｄ間では子−親、ノードＦ−Ｄ間では子−親と決定される。
【００８５】
又、ステップＳ１６０２の処理の結果、接続ポートの数が２つ以上の場合、そのノードは、自分を「ブランチ」であると認識する（ステップＳ１６０５）。ここで、ブランチとは、２つ以上のノードと接続されているノードのことである。
【００８６】
ブランチとなるノードは、各接続ポートのノードから親子関係の宣言を受け付ける（ステップＳ１６０６）。宣言を受け付けた接続ポートは、「子ポート」として認識される。
【００８７】
１つの接続ポートを「子ポート」と認識した後、ブランチは、まだ親子関係の決定されていない接続ポート（即ち、未定義ポート）が２つ以上あるか否かを検出する（ステップＳ１６０７）。その結果、未定義ポートが２つ以上ある場合、ブランチは、再びステップＳ１６０６の動作を行う。
【００８８】
ステップＳ１６０７の結果、未定義ポートが１つだけ存在する場合、ブランチは、その未定義ポートが「親ポート」であると認識し、そのポートに接続されているノードに対して「自分は子」であることを宣言する（ステップＳ１６０８、Ｓ１６０９）。
【００８９】
ここで、ブランチは、残りの未定義ポートが１つになるまで自分自身が子であると他のノードに対して宣言することができない。例えば、図１４において、ノードＢ、Ｃ、Ｄは、自分がブランチであると認識すると共に、リーフ或いは他のブランチからの宣言を受け付ける。ノードＤは、Ｄ−Ｅ間、Ｄ−Ｆ間の親子関係が決定した後、ノードＣに対して親子関係の宣言を行っている。又、ノードＤからの宣言を受けたノードＣは、ノードＢに対して親子関係の宣言を行っている。
【００９０】
又、ステップＳ１６０８の処理の結果、未定義ポートが存在しない場合（つまり、ブランチの具備する全ての接続ポートが親ポートとなった場合）、そのブランチは、自分自身がルートであることを認識する。（ステップＳ１６１０）。
【００９１】
例えば、図１４において、接続ポートの全てが親ポートとなったノードＢは、１３９４ネットワーク上の通信を調停するルートとして他のノードに認識される。ここで、ノードＢがルートと決定されたが、ノードＢの親子関係を宣言するタイミングが、ノードＣの宣言するタイミングに比べて早い場合には、他のノードがルートになる可能性もある。即ち、宣言するタイミングによっては、どのノードもルートとなる可能性がある。従って、同じネットワーク構成であっても同じノードがルートになるとは限らない。
【００９２】
このように全ての接続ポートの親子関係が宣言されることによって、各ノードは、１３９４ネットワークの接続構成を階層構造（ツリー構造）として認識することができる（ステップＳ１６１１）。尚、上述の親ノードは階層構造における上位であり、子ノードは階層構造における下位となる。
【００９３】
（８）ノードＩＤの割り当て
図１７は、図１５に示したステップＳ１５０５の処理（即ち、自動的に各ノードのノードＩＤを割り当てる処理）を詳細に説明するフローチャートである。ここで、ノードＩＤは、バス番号とノード番号とから構成されるが、本実施例では、各ノードを同一バス上に接続するものとし、各ノードには同一のバス番号が割り当てられるものとする。
【００９４】
図１７において、ルートは、ノードＩＤが未設定のノードが接続されている子ポートの内、最小番号を有する通信ポートに対してノードＩＤの設定許可を与える（ステップＳ１７０１）。
【００９５】
尚、図１７において、ルートは、最小番号の子ポートに接続されている全ノードのノードＩＤを設定した後、その子ポートを設定済とし、次に最小となる子ポートに対して同様の制御を行なう。最終的に子ポートに接続された全てのノードのＩＤ設定が終了した後、ルート自身のノードＩＤを設定する。尚、ノードＩＤに含まれるノード番号は、基本的にリーフ、ブランチの順に０、１、２…と割り当てられる。従って、ルートが最も大きなノード番号を有することになる。
【００９６】
ステップＳ１７０１において、設定許可を得たノードは、自分の子ポートの内、ノードＩＤが未設定となるノードを含む子ポートがあるか否かを判断する（ステップＳ１７０２）。
【００９７】
ステップＳ１７０２において、未設定ノードを含む子ポートが検出された場合、上述の設定許可を得たノードは、その子ポートに直接接続されたノードに対してその設定許可を与えるように制御する（ステップＳ１７０３）。
【００９８】
ステップＳ１７０３の処理後、上述の設定許可を得たノードは、自分の子ポートの内、ノードＩＤが未設定であるノードを含む子ポートがあるか否かを判断する（ステップＳ１７０４）。ここで、ステップＳ１７０４の処理後、未設定ノードを含む子ポートの存在が検出された場合、そのノードは、再びステップＳ１７０３の処理を実行する。
【００９９】
又、ステップＳ１７０２或いはＳ１７０４において、未設定ノードを含む子ポートが検出されなかった場合、設定許可を得たノードは、自分自身のノードＩＤを設定する（ステップＳ１７０５）。
【０１００】
自分のノードＩＤを設定したノードは、自己のノード番号、通信ポートの接続状態に関する情報等を含んだセルフＩＤパケットをブロードキャストする（ステップＳ１７０６）。尚、ブロードキャストとは、あるノードの通信パケットを、１３９４ネットワークを構成する不特定多数のノードに対して転送することである。
【０１０１】
ここで、各ノードは、このセルフＩＤパケットを受信することにより、各ノードに割り当てられたノート番号を認識することができ、自分に割り当てられるノード番号を知ることができる。例えば、図１４において、ルートであるノードＢは、最小ポート番号「＃１」の通信ポートに接続されたノードＡに対してノードＩＤ設定の許可を与える。ノードＡは、自己のノード番号「Ｎｏ．０」と割り当て、自分自身に対してバス番号とノード番号とからなるノードＩＤを設定する。又、ノードＡは、そのノード番号を含むセルフＩＤパケットをブロードキャストする。
【０１０２】
図１８にセルフＩＤパケットの構成例を示す。図１８において、１８０１はセルフＩＤパケットを送出したノードのノード番号を格納するフィールド、１８０２は対応可能な転送速度に関する情報を格納するフィールド、１８０３はバス管理機能（バスマネージャの能力の有無等）の有無を示すフィールド、１８０４は電力の消費及び供給の特性に関する情報を格納するフィールドである。
【０１０３】
又、図１８において、１８０５はポート番号「＃０」となる通信ポートの接続状態に関する情報（接続、未接続、通信ポートの親子関係等）を格納するフィールド、１８０６はポート番号「＃１」となる通信ポートの接続状態に関する情報（接続、未接続、通信ポートの親子関係等）を格納するフィールド、１８０７はポート番号「＃２」となる通信ポートの接続状態に関する情報（接続、未接続、通信ポートの親子関係等）を格納するフィールドである。
【０１０４】
尚、セルフＩＤパケットを送出するノードにバスマネージャとなり得る能力がある場合には、フィールド１８０３に示すコンテンダビットを「１」とし、なり得る能力がなければ、コンテンダビットを０とする。
【０１０５】
ここで、バスマネージャとは、上述のセルフＩＤパケットに含まれる各種の情報に基づいて、バスの電源管理（通信ケーブルを介して電源の供給が可能か否か、電源の供給が必要か否か等の情報を各ノード毎に管理する）、速度情報の管理（各ノードの対応可能な転送速度に関する情報から各ノード間の最大転送速度を管理する）、トポロジ・マップ情報の管理（通信ポートの親子関係情報からネットワークの接続構成を管理する）、トポロジ・マップ情報に基づくバスの最適化等を行ない、それらの情報を他のノードに提供する機能を有するノードである。これらの機能により、バスマネージャとなるノードは１３９４ネットワーク全体のバス管理を行なうことができる。
【０１０６】
ステップＳ１７０６の処理後、ノードＩＤの設定を行ったノードは、親ノードがあるか否かを判断する（ステップＳ１７０７）。親ノードがある場合、その親ノードが、ステップＳ１７０２以下の処理を再び実行する。そして、まだノードＩＤの設定されていないノードに対して許可を与える。
【０１０７】
又、親ノードが存在しない場合、そのノードは、ルート自身であると判断される。ルートは、全ての子ポートに接続されたノードに対してノードＩＤが設定されたか否かを判別する（ステップＳ１７０８）。
【０１０８】
ステップＳ１７０８において、全てのノードに対するＩＤ設定処理が終了しなかった場合、ルートは、そのノードを含む子ポートの内、最小番号となる子ポートに対してＩＤ設定の許可を与える（ステップＳ１７０１）。その後、ステップＳ１７０２以下の処理を実行する。
【０１０９】
又、全てのノードに対するＩＤ設定処理が終了した場合、ルートは、自分自身のノードＩＤの設定を実行する（ステップＳ１７０９）。ノードＩＤの設定後、ルートは、セルフＩＤパケットをブロードキャストする（ステップＳ１７１０）。
【０１１０】
以上の処理によって、１３９４ネットワークは、各ノードに対して自動的にノードＩＤを割り当てることができる。
【０１１１】
ここで、ノードＩＤの設定処理後、複数のノードがバスマネージャの能力を具備する場合、ノード番号の最も大きいノードがバスマネージャとなる。つまり、ネットワーク内で最大となるノード番号を持つルートがバスマネージャになり得る機能を有している場合には、ルートがバスマネージャとなる。
【０１１２】
しかしながら、ルートにその機能が備わっていない場合には、ルートの次に大きいノード番号を具備するノードがバスマネージャとなる。又、どのノードがバスマネージャになったかについては、各ノードがブロードキャストするセルフＩＤパケット内のコンテンダビット１８０３をチェックすることにより把握することができる。
【０１１３】
（９）アービトレーション
図１９は、図１の１３９４ネットワークにおけるアービトレーションを説明する図である。
【０１１４】
１３９４ネットワークでは、データ転送に先立って、必ずバス使用権のアービトレーション（調停）を行なう。１３９４ネットワークは、論理的なバス型ネットワークであり、各ノードから転送された通信パケットを他のノードに中継することによって、ネットワーク内の全てのノードに同じ通信パケットを転送することのできる。従って、通信パケットの衝突を防ぐために、必ずアービトレーションが必要となる。これによって、ある時間において一つのノードのみが転送を行なうことができる。
【０１１５】
図１９（ａ）は、ノードＢとノードＦとが、バス使用権の要求を発している場合について説明する図である。
【０１１６】
アービトレーションが始まるとノードＢ、Ｆは、夫々親ノードに向かって、バス使用権の要求を発する。ノードＢの要求を受けた親ノード（即ち、ノードＣ）は、自分の親ノード（即ち、ノードＤ）に向かって、そのバス使用権を中継する。この要求は、最終的に調停を行なうルート（ノードＤ）に届けられる。
【０１１７】
バス使用要求を受けたルートは、どのノードにバスを使用させるかを決める。この調停作業はルートとなるノードのみが行なえるものであり、調停によって勝ったノードにはバスの使用許可が与えられる。
【０１１８】
図１９（ｂ）は、ノードＦの要求が許可され、ノードＢの要求が拒否されたことを示す図である。
【０１１９】
アービトレーションに負けたノードに対してルートは、ＤＰ（Data prefix）パケットを送り、拒否されたことを知らせる。拒否されたノードは、次回のアービトレーションまでバス使用要求を待機する。
【０１２０】
以上のようにアービトレーションを制御することによって、１３９４ネットワークは、バスの使用権を管理することができる。
【０１２１】
（１０）通信サイクル
Isochronous転送モードとAsynchronous転送モードとは、各通信サイクル期間内において時分割に混在させることができる。ここで、通信サイクルの期間は、通常、１２５μＳである。
【０１２２】
図２０は、１通信サイクルにおいてIsochronous転送モードとAsynchronous転送モードとを混在させた場合を説明する図である。
【０１２３】
Isochronous転送モードは、Asynchronous転送モードより優先して実行される。その理由は、サイクル・スタート・パケットの後、Asynchronous転送を起動するために必要なアイドル期間（subaction gap）が、Isochronous転送を起動するため必要なアイドル期間（Isochronous gap）よりも長くなるように設定されているためである。これにより、Isochronous転送は、Asynchronous転送に優先して実行される。
【０１２４】
図２０において、各通信サイクルのスタート時には、サイクル・スタート・パケット（以下、ＣＳＰ）が所定のノードから転送される。各ノードは、このＣＳＰを用いて時刻調整を行うことによって、他のノードと同じ時間を計時することができる。
【０１２５】
（１１）Isochronous転送モード
Isochronous転送モードは、同期型の転送方式である。Isochronousモード転送は、通信サイクルの開始後、所定の期間において実行可能である。又、Isochronous転送モードは、リアルタイム転送を維持するために、各サイクル毎に必ず実行される。
【０１２６】
Isochronous転送モードは、特に動画像データや音声データ等のリアルタイムな転送を必要とするデータの転送に適した転送モードである。Isochronous転送モードは、Asynchronous転送モードのように１対１の通信ではなく、ブロードキャスト通信である。つまり、あるノードから送出されたパケットは、ネットワーク上の全てのノードに対して一様に転送される。尚、Isochronous転送には、ack（受信確認用返信コード）は存在しない。
【０１２７】
図２０において、チャネルｅ（ch e）、チャネルｓ（ch s）、チャネルｋ（ch k）は、各ノードがIsochronous転送を行う期間を示す。１３９４インタフェースでは、複数の異なるIsochronous転送を区別するために、夫々異なるチャネル番号を与えている。これにより、複数ノード間でのIsochronous転送が可能となる。ここで、このチャネル番号は、送信先を特定するものではなく、データに対する論理的な番号を与えているに過ぎない。
【０１２８】
又、図２０に示したIsochronous gapとは、バスのアイドル状態を示すものである。このアイドル状態が一定時間を経過した後、Isochronous転送を希望するノードは、バスが使用できると判断し、アービトレーションを実行する。
【０１２９】
次に、図２１にIsochronous転送モードに基づいて転送される通信パケットのフォーマットを示す。以下、Isochronous転送モードに基づいて転送される通信パケットを、Isochronousパケットと称する。
【０１３０】
図２１において、Isochronousパケットはヘッダ部２１０１、ヘッダＣＲＣ２１０２、データ部２１０３、データＣＲＣ２１０４から構成される。
【０１３１】
ヘッダ部２１０１には、データ部２１０３のデータ長を格納するフィールド２１０５、Isochronousパケットのフォーマット情報を格納するフィールド２１０６、Isochronousパケットのチャネル番号を格納するフィールド２１０７、パケットのフォーマット及び実行しなければならない処理を識別するトランザクションコード（tcode）を格納するフィールド２１０８、同期化コードを格納するフィールド２１０９がある。
【０１３２】
（１２）Asynchronous転送モード
Asynchronous転送モードは、非同期型の転送方式である。Asynchronous転送は、Isochronous転送期間の終了後、次の通信サイクルが開始されるまでの間（即ち、次の通信サイクルのＣＳＰが転送されるまでの間）、実行可能である。
【０１３３】
図２０において、最初のサブアクション・ギャップ（subaction gap）は、バスのアイドル状態を示すものである。このアイドル時間が一定値になった後、Asynchronous転送を希望するノードは、バスが使用できると判断し、アービトレーションを実行する。
【０１３４】
アービトレーションによりバスの使用権を得たノードは、図２２に示すパケットを所定のノードに対して転送する。このパケットを受信したノードは、ack（受信確認用返送コード）或いは応答パケットをack gap後に返送する。
【０１３５】
図２２は、Asynchronous転送モードに基づく通信パケットのフォーマットを示す図である。以下、Asynchronous転送モードに基づいて転送される通信パケットを、Asynchronousパケットと称する。
【０１３６】
図２２において、Asynchronousパケットは、ヘッダ部２２０１、ヘッダＣＲＣ２２０２、データ部２２０３、データＣＲＣ２２０４から構成される。
【０１３７】
ヘッダ部２２０１において、フィールド２２０５には宛先となるノードのノードＩＤ、フィールド２２０６にはソースとなるノードのノードＩＤ、フィールド２２０７には一連のトランザクションを示すためのラベル、フィールド２２０８には再送ステータスを示すコード、フィールド２２０９にはパケットのフォーマット及び実行しなければならない処理を識別するトランザクションコード（tcode）、フィールド２２１０には優先順位、フィールド２２１１には宛先のメモリ・アドレス、フィールド２２１２にはデータ部のデータ長、フィールド２２１３には拡張されたトランザクション・コードが格納される。
【０１３８】
又、Asynchronous転送は、自己ノードから相手ノードへの１対１の通信である。転送元ノードから転送されたパケットは、ネットワーク中の各ノードに行き渡るが、自分宛てのアドレス以外のものは無視される。従って、宛先となるノードのみが、そのパケットを読み込むことができる。
【０１３９】
尚、Asynchronous転送中に次のＣＳＰを転送すべき時間に至った場合、無理に転送を中断せず、その転送が終了した後、次のＣＳＰを送信する。これにより、１つの通信サイクルが１２５μＳ以上続いたときは、その分、次の通信サイクル期間を短縮する。このようにすることによって、１３９４ネットワークは、ほぼ一定の通信サイクルを保持することができる。
【０１４０】
（１３）デバイス・マップ
デバイスマップを作成するためにアプリケーションが１３９４ネットワークのトポロジーを知る手段として、ＩＥＥＥ１３９４規格上は以下の手段がある。
１．バスマネージャーのトポロジーマップレジスターをリードする
２．バスリセット時にセルフＩＤパケットから推定する
しかし上記１、２の手段では、各ノードの親子関係によるケーブル接続順のトポロジーは判明するものの、物理的な位置関係のトポロジーを知ることは出来ない。(実装されていないポートまで見えてしまう、といった問題もある)
また、デバイスマップを作成するための情報を、コンフィギュレーションＲＯＭ以外のデータベースとして持つ、といった手段もあるが、その場合、各種情報を得る手段はデータベースアクセスのためのプロトコルに依存してしまう。
【０１４１】
ところで、コンフィギュレーションＲＯＭ自体やコンフィギュレーションＲＯＭを読む機能は、ＩＥＥＥ１３９４規格を遵守したデバイスが必ず持つものである。そこで、デバイスの位置、機能等の情報を各ノードのコンフィギュレーションＲＯＭに格納し、それらをアプリケーションから読む機能を与えることにより、データベースアクセス、データ転送等の特定のプロトコルに依存することなく、各ノードのアプリケーションがいわゆるデバイスマップ表示機能を実装することができる。
【０１４２】
コンフィグレーションＲＯＭにはノード固有の情報として物理的な位置、機能などが格納可能であり、デバイスマップ表示機能の実現に使用することが可能である。
【０１４３】
この場合、アプリケーションが物理的な位置関係による１３９４ネットワークトポロジーを知る手段としては、バスリセット時やユーザーからの要求時に、各ノードのコンフィギュレーションＲＯＭを読み取ることにより、１３９４ネットワークのトポロジーを知る、という方法が可能となる。さらに、コンフィギュレーションＲＯＭ内にノードの物理的位置のみならず、機能などの各種ノード情報も記述することによって、コンフィギュレーションＲＯＭを読むことで、ノードの物理的位置と同時に各ノードの機能情報等も得ることができる。アプリケーションが各ノードのコンフィギュレーションＲＯＭ情報を取得する際には、指定ノードの任意のコンフィギュレーションＲＯＭ情報を取得するＡＰＩを用いる。
【０１４４】
このような手段を用いることにより、ＩＥＥＥ１３９４ネットワーク上のデバイスのアプリケーションは、物理的なトポロジーマップ、各ノードの機能マップなど、用途に応じて様々なデバイスマップを作成することができ、ユーザーが必要な機能をもつデバイスを選択する、といったことも可能となる。
【０１４５】
〈SBP-2の概要〉
SBP-2（Serial Bus Protocol２）は、NCITS傘下のTechnical Committee T10のプロジェクトとして1996より標準化の審議が進められ、1998年にANSI NCITS 325-1998として標準化が認可された、IEEE1394バスに依存したプロトコルで有る。レイヤとしては、IEEE1394-1995のトランザクション層の上位に位置するコマンド／データトランスポートプロトコルで有る。当初SBP-2は、IEEE1394 上のデバイスをSCSIコマンドを用いて動作させる事を可能にする事を主な目的として開発されたが、SCSIコマンドに限らず他のコマンドを載せる事も出来る。SBP-2の特長を挙げると以下の通りになる。
【０１４６】
（１）イニシエータ（Initiator）/ターゲット（Target）構成のマスタスレーブモデルで有り、マスタで有るイニシエータがログイン、ログアウト、タスク管理、コマンド発行等の全ての権限と責任を持つ。
【０１４７】
（２）バスモデルとしてのIEEE1394の特長を生かした共有メモリモデルで有る（コマンド等のターゲットへの要求内容は、基本的には全てシステムメモリ内に置かれ、要求を受けたターゲットがシステムメモリの内容を読みに行く。又は、システムメモリへ要求されたステータス等の情報をを書きこむ）。
【０１４８】
即ち、通信の為のリソースを一箇所に集中出来るので、リソースの負担を非常に軽く出来、かつターゲットが自分のペースでシステムメモリへ読み書き出来るので、ターゲットの設計の自由度が高く、システムメモリのアクセスをハードウエア化することにより高速化が容易である（高性能にも、徹底した低コストモデルにも出来る）。
【０１４９】
（３）メッセージ交換の為のコマンド群を一連のリンクリストとして記述する仕組みが有る為、レイテンシによる効率低下を隠蔽できるため、IEEE1394バスの特長を生かした高速で、効率の高いデータ通信を実現できる。
【０１５０】
（４）コマンドセットインデペンデントな構造である（様々なコマンドセットに対応可能）。
【０１５１】
SBP-2はマスタで有るイニシエータが全ての権限と責任を持つマスタ−スレーブモデルで有り、全てはイニシエータからの動作をきっかけにして行われる。イニシエータからのログイン、ログアウト要求やタスク管理要求、コマンド等は、ORB(Operation Request Block)と呼ぶデータ構造に内包された形でターゲットに送られる。（正しくは、イニシエータが自メモリに置き、ターゲットがそれを読み出す）。図２３に、主なORBの種類を示す。
【０１５２】
（１）ダミーORB：ターゲットフェッチエージェントのイニシャライズ時、タスクのキャンセル等に使用する。ターゲットにはno operation（無処理命令）として扱われる
（２）コマンドブロックORB：データ転送コマンド、デバイス制御コマンド等のコマンドを内包するORBで有る。対応するデータバッファ又はページテーブルのアドレス及びサイズを示すdata_descriptor, data_sizeフィールドを有する。次のコマンドブロックORBのアドレスを示すnext_ORBフィールドを有するので、コマンドをリンク出来るのが特長である（図２４参照の事）。
【０１５３】
（３）管理ORB：マネージメント要求（ログイン、ログアウトを含むアクセス要求、及びタスクマネージメント要求）を内包するORBである。タスク管理の要求内容（タスクセット中断, ターゲットリセット等）を示すファンクションフィールドと、ターゲットからの完了ステータスのアドレスを示すステータスFIFOのフィールドを有するのが特長である（図２５参照の事）。
【０１５４】
この内、管理ORB については、ターゲットが応答を返すまでイニシエータは次のORBを発行する事は出来ないが、Dummy ORBを含むコマンド Block ORBは、図２６の様にリンクされたリストの形で一連のコマンド列として発行する事が出来る。即ちコマンドブロックORBには図２の様にnext_ORBフィールドとして次のORBのアドレスを指示するフィールドが有る為、次々とコマンドを連結する事が出来る。このフィールドがnullの場合は、次に続くORBが無いことを示す。
【０１５５】
また、このコマンドブロックORBの他のフィールドにはデータバッファ又はページテーブルのアドレス及びサイズを示すフィールド(data_descriptor及びdata_size)が有り、例えばコマンドの内容がライト（write）コマンドならばターゲットはdata_descriptorで示されたシステムメモリ上のData_Bufferにアクセスし、そこから書き込むべきデータを読みこむ。また、コマンドの内容がリード（Read）コマンドならばターゲットはdata_descriptorで示されたシステムメモリ上のData_Bufferにアクセスし、そこへコマンドの要求するデータを書きこむ。
【０１５６】
図２７及び図２８に、データバッファを直接示す場合と、ページテーブルを経由する場合を示す。ページテーブルにより、物理的に不連続な領域のデータバッファを、連続的に扱う事が出来、仮想記憶による連続論理領域を物理的に再配置する必要がなくなる訳である。
【０１５７】
イニシエータからの様々な要求を実行するターゲット側の仕組みを、エージェントと称する。エージェントには、管理ORBを実行する管理エージェントと、コマンドブロックORBを実行するコマンドブロックエージェントが有る。
【０１５８】
管理エージェントには、管理ORBのアドレスをイニシエータがターゲットに知らせる為にストアする、管理エージェントレジスタrが有る。
【０１５９】
コマンドブロックエージェントは、イニシエータのコマンドのリンクされたリストからコマンドをフェッチして来る為、フェッチエージェントとも呼ばれる。フェッチエージェントにも、コマンドブロックORBの先頭アドレスをイニシエータがストアするORBポインタレジスタと、イニシエータがターゲットにコマンドをフェッチして貰いたい事を知らせるドアベルレジスタ等を含む、コマンドブロックエージェントレジスタが有る。
【０１６０】
ターゲットはイニシエータからのORBの実行を完了すると、その実行完了のステータスを、ステータスブロックと言うデータ構造の形で（完了の成否に拘らず）イニシエータのステータスFIFOの示すアドレスにストアする。ステータスブロックの例を、図２９に示す。
【０１６１】
ターゲットは最低８バイト、最大32バイトのステータス情報をストアする事が出来る。管理ORBの場合は、図２５のステータスFIFOフィールドにORBの一部として明示的にステータスFIFOアドレスが提供されるので、ターゲットは指定されたアドレスにステータスブロックをストアする。それ以外の場合は、フェッチエージェントのコンテクストから得られるステータスFIFOにステータスブロックをストアする。コマンドブロックORBの場合は、イニシエータはステータスFIFOアドレスをログイン要求の一部として提供する。
【０１６２】
通常ターゲットは、イニシエータの発するORBに対してステータスFIFOアドレスにステータスブロックを書き込む事によって応答するが、デバイス側に変化が発生し、ロジカルユニットに影響する場合は、イニシエータからの要求が無くても自発的にアンソリシテッドステータスを返すことも出来る。この場合のステータスFIFOアドレスは、イニシエータからのログイン要求の際にイニシエータから提供されるステータスFIFOアドレスで有る。
【０１６３】
SBP-2におけるイニシエータとターゲットの動作を、図３０の動作モデルを用いて説明する。
【０１６４】
SBP-2の動作は、イニシエータが、ターゲットに対してログイン要求の為の管理ORB（ログインORB）を発行する事から始まる。ターゲットは、イニシエータからの要求に対してログイン応答で応える（図３０参照の事）。ログイン要求が受け入れられると、ターゲットからはログイン応答としてコマンドブロックエージェントレジスタの先頭アドレスが返って来る。
【０１６５】
ログイン要求が受け入れられると、ターゲットの管理エージェントは、イニシエータからのその後のタスク管理要求を受け付ける。イニシエータはタスク管理ORBを発行して、タスクの実行に必要な情報のやり取りをターゲットとの間で行う。ターゲットはイニシエータの発するORBに対してステータスFIFOにステータスブロックを書き込む事によって応答するが、デバイス側に変化が発生し、ロジカルユニットに影響する場合は、イニシエータからの要求が無くても自主的にアンソリシテッドステータスを返すことも出来る事は前述の通りである。タスク管理に関するやり取りに続いて、イニシエータは必要なコマンドブロックORB（リスト）を自分のメモリ領域に形成し、ターゲットのコマンドブロックエージェントレジスタのORBポインタに前記ORBの先頭アドレスを書きこみか又はコマンドブロックエージェントレジスタのドアベルレジスタを叩いて、ターゲットに対して通信すべきORBがイニシエータに有ることを知らせる（図３１）。ターゲットは、上記ORBポインタに書かれた前記ORBの先頭アドレス情報をもとにイニシエータのメモリにアクセスし、ORBを順次処理する（図３２）。
【０１６６】
ところで、タスクの実行モデルには、順序モデル（Ordered Model）と非順序モデル（Unordered Model）が有る。順序モデルでは、ORBはリストの順番に沿って行われ、ターゲットの完了ステータスも順番に返って来る。非順序モデルでは、ORBの実行順位に制約は無いが、どの順序でも最終的に同じ実行結果が得られる様にイニシエータが責任を持たなければならない。イニシエータからターゲットへのデータ転送はターゲットからシステムメモリへのリードトランザクションによって行われ、一方ターゲットからイニシエータへのデータ転送は、システムメモリへのライトトランザクションによって行われる。即ちデータバッファの転送は方向によらずターゲットが主導する。逆に言えば、ターゲットは自分に都合の良いペースでシステムメモリからのデータを読み出すことが出来る訳で有る。イニシエータはターゲットがORBを実行中でも、Listの最後のORBのnext_addressを次のORBのアドレスに書き換え、ターゲットのドアベルレジスタを再び叩いてターゲットに変更を知らせる事により、リンクされたリストにORBを追加する事が出来る。ターゲットは、イニシエータのステータスFIFOのアドレスに完了ステータス（ステータスブロック）を返す。イニシエータは完了ステータス（ステータスブロック）が返されたのを見て、その対象ORBのターゲットによる実行が完了した事を知る。完了したORBは、(next_ORBフィールドがnullでなければ)タスクセットのリンクされたリストから外す事が出来、イニシエータはその空いたリソースを利用して、必要なら次のコマンドをコマンドがリンクされたリストの最後に追加しても良い。このようにしてORBが実行されタスクが実行される。
【０１６７】
タスクが終了し、アクセスをつづける必要が無い場合は、イニシエータはログアウトORBを発行し、ターゲットが応えてログアウトが完了する。
【０１６８】
〈SBP-3の双方向データ転送機能〉
SBP-3（Serial Bus Protocol3）は、SBP-2を拡張し機能を追加することによりSBP-2において効率が悪かった点、欠いていた機能を補充する目的で2000年後半から規格化作業が行なわれている。
【０１６９】
SBP-3において拡張された代表的な機能を挙げると以下の通りになる。
1. アイソクロナス（Isochronous）データ転送機能
2. デバイスハンドルによるイニシエータ／ターゲットの特定によるノードID非依存機能
3. １つのＯＲＢ内の双方向データ転送機能
ここでは上記機能のうち第３番目の機能について説明する。
【０１７０】
SBP-3はSBP-2と下位互換性を持っており、その基本的なデータ転送シーケンスはSBP-2の概要で説明した通りである。すなわち、イニシエータからターゲットへのデータ転送はターゲットからシステムメモリへのリードトランザクションによって行われ、一方ターゲットからイニシエータへのデータ転送は、システムメモリへのライトトランザクションによって行われる。ターゲットは自分に都合の良いペースでORBを読み出し、ORBの内容をデコードすることによって転送動作の種別情報を知る。ターゲットはORBに対応する転送動作がイニシエータからターゲットへのデータ転送か、ターゲットからイニシエータへのデータ転送なのか、そしてその転送動作が、イニシエータ内のどのシステムメモリ領域に対して行なわれるかをデコードし、該当する転送動作を行なう。またターゲットはそのORBで指定された転送動作を完了した際には、イニシエータのステータスFIFOのアドレスに完了ステータス（ステータスブロック）を返す。
【０１７１】
SBP-3ではコマンドブロックORB、すなわちデータ転送コマンドや、デバイス制御コマンド等のコマンドを内包するORBとして２種類定義している。ひとつはコマンドブロックORBが有するリクエストフォーマットフィールドの値が０のものであり、SBP-2で定義されたコマンドブロックORBと同一のものである。〈SBP-2の概要〉の欄で説明したように、ORBが参照するデータバッファ又はページテーブルのアドレス及びサイズを示すdata _descriptor, data_size_field、次のコマンドブロックORBのアドレスを示すnext_ORBフィールド、そしてデータバッファに対するデータ転送方向を示すdirectionフィールドに代表されるデータ転送に関わるパラメータを指定するフィールドからなる。
【０１７２】
SBP-3で新規に定義されたコマンドブロックORB はリクエストフォーマットフィールドの値が１となっており従来のORBと区別がつけられる。
【０１７３】
このORBの特徴はひとつのＯＲＢから２つのデータバッファが参照されるということである。データバッファ又はページテーブルのアドレス及びサイズを示すdata_descriptor, data_sizeフィールド、directionフィールド等データバッファに関するフィールドがそれぞれ２組用意され、
これによりＯＲＢから２つのデータバッファの参照が可能となる。
【０１７４】
このＯＲＢを使用し、一つのデータバッファはターゲットへのライト用、もう一方のデータバッファはターゲットからのリード用バッファとして使うことにより双方向ＯＲＢとして活用することが出来る。
【０１７５】
イニシエータは必要なコマンドブロックORB（リスト）を自分のメモリ領域に形成し、上記のように双方向ＯＲＢをアペンドしてターゲットのコマンドブロックエージェントレジスタ のORBポインタに前記ORB（リスト）の先頭アドレスを書きこみか又はコマンドブロックエージェントレジスタのドアベルレジスタを叩いて、ターゲットに対して通信すべきORBがイニシエータに有ることを知らせる。ターゲットは、上記ORBポインタに書かれた前記ORBの先頭アドレス情報をもとにイニシエータのメモリにアクセスし、ORBをフェッチ、順次処理する。
【０１７６】
双方向ＯＲＢをフェッチしたターゲットは指定された２つのデータバッファそれぞれに対してデータ転送処理を行なう。片側のバッファに対応するdirectionフィールドは0となっていて、ターゲットはdata_descriptorで示されたシステムメモリ上のデータバッファにアクセスし、そこから書き込むべきデータを読みこむ。またもう片方ののバッファに対応するdirectionフィールドは1となっていてターゲットはdata_descriptorで示されたシステムメモリ上のデータバッファにアクセスし、そこへコマンドの要求するデータを書きこむ。
【０１７７】
両方のデータバッファアクセスが完了するとターゲットはイニシエータのステータスFIFOのアドレスに完了ステータス（ステータスブロック）を返し、そのＯＲＢの実行完了を通知する。
【０１７８】
図３３にSBP-3でのコマンドブロックORBの動作を示している、図３２で示したSBP-2と比較すると、SBP-3では1つのORBに対してデータバッファアクセスを示す線が2本になっており、SBP-2が1つのデータバッファへのアクセスしか出来なかった点が変更されている。2つのデータバッファに独立してアクセスできることにより、イニシエータからターゲットへの2つのデータチャネルを1つのORBに当てはめることが出来る。データバッファへのデータの流れる方向はそれぞれのデータバッファで規定できるため、イニシエータからターゲットへの方向を2本、イニシエータからターゲットへの方向を１本ターゲットからイニシエータへの方向を１本、ターゲットからイニシエータへの方向を２本設定することが可能になる。ホストとプリンタで使うような場合、1本をホストからプリンタへの印字データのために使い、もう1本をプリンタからホストへのステータス情報を流すために使うことも可能となる。
【０１７９】
図３４にSBP-3の2つのデータバッファを保持する場合のコマンドブロックORBの詳細を示している。2組のデータバッファを扱えるようにするために、2つのdata_descritorとバッファ情報"d"〜"data_size"とがSBP-2に対して拡張されている。図中"d"で示したdirectionでそれぞれのデータバッファの方向を指定することが出来る。内容はSBP-2と同様で0であればイニシエータからターゲット、1であればターゲットからイニシエータへの方向を示している。
【０１８０】
〈本実施形態の説明〉
以下本発明の実施形態に関して詳細に説明する。
【０１８１】
図３５に、SBP-2,SBP-3で使用されるステータスブロックに対して、本発明に係るSBP-3の改良版であるSBP-3改で使われるステータスブロックを示す。SBP-2,SBP-3と基本的には同じ構成となっていて、3番目のクアドレット（quadlet：４バイト分のデータ）に"a","b0","b1"の各フラグを配置した部分の追加がされている。"a","b0","b1"はそれぞれ対応するデータバッファの表していて、"b0"は図３４で示した1番目のdata_descriptorに対応しており、"b1"は２番目のdata_descriptorに対応している。"a"はこれら2つのデータバッファ両方を同時に対応することを意味する。"a","b0","b1"はそれぞれ0,1の値が指定され、1の場合に対応するバッファの完了を示し、0であれば対応するバッファの未完了を示す。"a"に1が指定された場合、2つのバッファが同時に完了したことを示す。"a","b0","b1"3つのの指定の組み合わせにより、1つ目のバッファの完了、2つ目のバッファの完了、１，２両方のバッファの完了を個別あるいは同時に通知することが出来る。
【０１８２】
図３６にSBP-3改でのコマンドブロックORBの動作を示している、ステータスFIFOに対するアクセスが複数回（この場合2回）行われることが示されている。図３３のSBP-3の動作ではステータスFIFOへのアクセスは1度だけ行われている。図３６で行われるステータスFIFOへのアクセスは図３５に示したステータスブロックで行われ、"a","b0","b1"のいずれかのビットに1が設定される。例えば、2つ目のバッファに対する処理が完了した場合、1度目のステータスブロックへのアクセスでは、"b1"が1、"b0"に0がセットされ、1つ目のバッファの処理が完了した場合、２度目のステータスブロックへのアクセスでは、"b1"が0、"b0"に1がセットされる。それぞれのバッファに対して、個別にステータスブロックへのアクセスが行われる。"b0","b1"共に完了が通知されれば、処理していたORBが完了全てのコマンド完了が通知されたことになる。
【０１８３】
また、SBP-3と同じ動作を実現するためには"a"に1を設定することで2つのバッファの終了を1回のステータスブロックへのアクセスで行うことも出来る。
【０１８４】
SBP-3では、2つのデータバッファに対する処理が両方共に終了した時点で、ステータスFIFOにアクセスしORBの完了を通知する。このような動作のため、一方のデータバッファの終了を先に通知することが出来なかった。これをホストとプリンタの関係に当てはめて考えた場合、いつのデータバッファを印字データ、もう1つをステータスのために使うとすると、プリンタが印字データのデータバッファを全て受け取るまで、ホストに対してステータスを戻せないことが発生する。ステータス情報を随時受け取りことができないことになる。SBP-3改ではデータバッファごとに独立してステータスFIFOを戻せるように改造しているため、印字データとは独立してステータスを戻すことも可能となる。
【０１８５】
以上説明した、SBP-3改のプロトコルを用いたコマンドセットの一例について説明する。コマンドセットはプロトコル上でターゲットデバイスを制御するためのコマンドで、本実施形態では、ターゲットデバイスとして印字装置（プリンタ）を想定したコマンドとする。
【０１８６】
図３７にその詳細な構成を示す。これは図３４のcommand_blockの部分を詳細に記述した図で、１つのORBで２つのコマンドを扱えるようにするために、同じ形式をしたコマンド１，コマンド２（図３７）を規定している。符号３７１２ａで示した部分に対応するコマンドがコマンド１（Command1）であり、符号３７０２で示した部分に対応するコマンドがコマンド２（Command2）である。各コマンドはOpcode３７１１，Datalength_hi３７１２，Datalength_lo３７１３，Count３７１４，Interval３７１５から構成されている。
【０１８７】
Opcode３７１１は実行されるコマンドの種類を表し、図３７の例では、WRITE，STATUSが定義されている。WRITEはプリンタへの印字データの書き込みを実行するコマンドで、イニシエータからターゲットであるプリンタ方向へのデータが流れることを示す。STATUSは、プリンタのステータス情報を取得するコマンドで、ステータス情報はターゲットのプリンタからイニシエータ方向へのデータが流れることを示す。イニシエータは印刷処理を行う際、印字データをプリンタへ送るコマンドを実行するのと同時に定期的にプリンタのステータス情報を取得する。イニシエータは取得したステータス情報からプリンタの状態をユーザに通知する作業を行う。これによりユーザはプリンタにエラー等が発生したことを知ることが出来る。
【０１８８】
Datalength_hi３７１２，Datalength_lo３７１３はイニシエータからターゲット（プリンタ）、あるいはターゲット（プリンタ）からイニシエータへの書き込みされたデータの量を示す。Count３７１４は、コマンドが実行される回数を指定する値で、１以上の値を取る。ただし、−１は無限の継続を意味する。Interval３７１５は、Count３７１４で指定された回数分のコマンドを実行する実行時間間隔を指定する値である。１以上の値をとり、本実施形態では１が1ms(ミリ秒)の単位を示すものとする、−１の値がInterval３７１５に指定された場合Interval３７１５の指定は行われないことを示す。このCount３７１４とInterval３７１５は２つの値の組み合わせによりいろいろなコマンドの実行条件を規定する。
【０１８９】
また、この時間間隔内でコマンドが完了しない場合には、タイムアウトと判定される。そのため、Count,Intervalは、コマンドが一定時間（Count * Interval）実行できないような場合のタイムアウト時間として使うことも出来る。例えばCount=1,Interval=1000を指定したような場合、コマンドの実行は１回のみで、1000msの時間が経過してもコマンドが実行されない場合、タイムアウトとなりその内容がイニシエータにステータスブロックで知らされることになる。またIntervalに−１が指定された場合にはコマンドがタイムアウトしない指定となる。
【０１９０】
図３８にこのコマンドセットでのステータスブロックの詳細を示し、図３５に示したSBP-3改でのステータスブロックに対して、コマンドセットに依存する部分を規定するものである。コマンドに対するステータスブロックは、元の形式にステータスが追加されている。STATUSフィールド３８０１はコマンドの完了状況を示し、本実施形態では完了（COMPLETE），タイムアウト（TIMEOUT）の２種類を定義する。COMPLETEはコマンドが正常に終了したことを示し、TIMEOUTはコマンドに指定されたCount,Intervalの条件によりコマンドの実行がタイムアウトしてコマンドの実行が行われなかったことを示す。
【０１９１】
図３９は、イニシエーターとプリンタでの印字データとステータス情報の流れとステータスブロックへの書き込みを示した図で、ここではイニシエータは１つのORBの場合を示していて、ORBには印字データを保持するバッファ1とステータス情報を受け取るためのバッファ2を有している。ORBのコマンド実行に際してプリンタは、バッファ1から印字データを受け取り、ステータスバッファ2にプリンタのステータス情報を書き込み、ステータスブロックにそれぞれの完了を書き込むことで１つのORBに対する２つのコマンドの実行が完了したこととなる。この場合のコマンド内容を示したのが図４０である。
【０１９２】
図４０において、コマンド１については、data_descriptorにはバッファ1のアドレスがセットされ、方向を示すdにはイニシエータからプリンタの方向を示す0がセットされる。コマンドのopcodeには印字データの書き込みコマンドであるWRITEコマンドが指定され、Count=1,Interval=3000が指定されている。これはWRITEコマンドが１回実行されること、実行できない場合3000msでタイムアウトすることを指定している。
【０１９３】
コマンド２に対してはdata_descriptorにはバッファ2のアドレスがセットされ、方向を示すdにはプリンタからイニシエータの方向を示す1がセットされる。コマンドのopcodeにはステータス情報の書き込みコマンドであるSTATUSコマンドが指定され、Count=-1,Interval=1000が指定されている。これはコマンド２がステータス情報の取得コマンドであるSTATUSの実行で、Count=-1,Interval=1000が指定されている。これがSTATUSコマンドが、1000msの時間間隔で、無限に実行されることを意味している。図４０に示したコマンドORBで、WRITE,STATUSの２つのコマンドの実行が指示されたことになる。
【０１９４】
このコマンドが問題なく実行された場合にプリンタか書き込むステータスブロックの例を図４１に示す。１回のステータスブロックで完了を示すために、フラグa（図３８）のところに1がセットされ、Status３８０１にCOMPLETEが指定されている。このステータスブロックの書き込み終了後、バッファ2にセットされている内容が最新のステータス情報になり、この情報を用いてユーザーに印字の状況を知らせることが出来る。
【０１９５】
図４０，４１で示したようにコマンドが２つとも同時に実行可能である場合には、特別に問題は発生しない。しかし実際のプリンタではこのように２つのコマンドを同時に実行することが出来ない場合が存在する。プリンタの種類、構成内容により異なるが、例えばインクジェットプリンタの場合では、印字データを受信できない時間帯（給紙、排紙中、回復動作中など）がある。それらが発生した場合、印字動作が一時的に中断されるため、すでに受け取っている印字データがあるために印字のためのバッファが一杯となり、次からの印字データを受け取ることが出来ない状態となる。一般的にそのような状態でもステータスのコマンドは実行できる場合が多い。ちょうどこの時に出されたコマンドは、本実施形態で示した、Count,Intervalの指定がないものであれば、プリンタが印字データを受信できるようになるまで、コマンドの実行は待たされたままとなる。
【０１９６】
図４２に、このようなプリンタが印字データを受信できない状態、すなわちターゲットがイニシエータからデータを読むことができない状態で、図４０に示したコマンドを実行した場合のステータスブロックに書き込まれる内容を示している。図４２（a）に示すように、STATUSコマンドに対するステータスブロックの書き込みは、印字データ受け取れない状況でもステータス情報を書き込むことが出来るので、正常に行われてCOMPLETEが書き込まれる。STATUSコマンドはIntervalに1000msが指定されていて、実行回数Countは-1で無限が指定されているので、1000ms間隔で新しいステータス情報の書き込みを実行してステータスブロックに図４２(a)でCOMPLETEの書き込みが行われる。
【０１９７】
一方WRITEコマンドはIntervalに3000msが指定されているので、この3000msの間にプリンタの印字データを受け取れない状態が解消されればステータスブロックにCOMPLETEで書き込むことが出来るが、3000msの間に解消されない場合には、図４２(b)で示した、TIMEOUTでステータスブロックの書き込みが行われる。この場合、WRITEのコマンドは正しく実行されずTIMEOUTとなってしまったので、イニシエーターは印字を止めてしまうか、同じデータでリトライを実行する必要がある。イニシエーターはステータスブロックでTIMEOUTを知ることが出来、以降どうのように継続するかどうかを決めることが可能となる。WRITEコマンドがプリンタの印字データを受け取れないことで、実行できない状態でいる間でも、もう１つのコマンド（STATUSコマンド）は指定された一定間隔で実行することが出来るので、最新のステータス情報がこの時でも受け取ることが出来る。
【０１９８】
またタイムアウトの時間を指定できるので、印字の実行を中止するような場合にも有効に利用することが出来る。
【０１９９】
＜本実施形態における処理手順の概略＞
図４３乃至図４６に、上記説明したイニシエータおよびターゲットにおける処理の概略フローチャートを示す。
【０２００】
図４３は、図１のクラスドライバ１０２におけるコマンド発行時の処理手順である。クラスドライバ１０２は、プリンタドライバ１０１から、ＰＤＬコマンドリスト等をデータとしてターゲットのプリンタへ発行する依頼を受けた際の処理手順である。プリンタドライバ１０１は、例えばデータや前述したコマンドの実行回数、時間間隔等、コマンド等をパラメータとして、クラスドライバ１０２が提供する関数を呼び出す。もちろん、コマンドは２つまで指定できる。また、コマンドに従属する実行回数や時間間隔、データ長等のパラメータは、コマンドごとに指定される。なお、コマンドは１つであっても良いことは既に説明したとおりである。
【０２０１】
クラスドライバ１０２は、コマンドからコマンドブロックを作成し（ステップＳ４３０１）、指定されたパラメータとともにＳＢＰ−３のプロセッサ１１１（図１）に渡す（ステップＳ４３０２）。プロセッサ１１１は、引き渡されたパラメータに従ったアドレスやデータ長をdata_descripterやdata_sizeフィールドに記述し、コマンドの種類に基づいて方向フィールドｄ等を記述して、図３７に示すＯＲＢを作成する。そして、作成したＯＲＢをＯＲＢリストにチェインする。
【０２０２】
チェインされたＯＲＢは、Ordered Modelであれば順次、Unordered Modelであれば、適切な順序で処理されていく。
【０２０３】
ターゲット１ｂへは、ドアベルレジスタ１２１へ書き込みを行うことでＯＲＢ処理のきっかけを与える。ターゲットのコマンドブロックエージェント１２２は、イニシエータ１ａにチェインされたＯＲＢのうち先頭のＯＲＢのアドレスをＯＲＢポインタ１２４にコピーして実行エージェント１２３へとＯＲＢの受信を通知する。
【０２０４】
図４４は、実行エージェント１２３におけるＯＲＢ処理手順のフローチャートである。
【０２０５】
ステップＳ４４０１において、ＯＲＢポインタ１２４で示されるＯＲＢのリクエストフォーマットフィールドをテストして、それが１であれば、コマンドが２つ含まれたＯＲＢであると判定する。このＯＲＢのことを以下の説明では単に２コマンドＯＲＢと呼ぶことにする。２コマンドＯＲＢでなければ通常のＳＢＰ−３（あるいはＳＢＰ−２）処理手順を遂行する。
【０２０６】
２コマンドＯＲＢであれば、ステップＳ４４０２においてそのうちの一方に注目し、ステップＳ４４０３において方向ビットｄを判定する。方向ビットがイニシエータからターゲットへであれば、イニシエータからターゲットへのデータの引き渡しなので、ステップＳ４４０４において、ＯＲＢのコマンド部およびバッファのアドレス（data_descripter）やサイズ（data_size）にしたがってデータを読み出し、コマンド処理部１０３に渡す。
【０２０７】
一方、方向ビットｄがターゲットからイニシエータへであれば、ターゲットからイニシエータへのデータの引き渡しであるので、ＯＲＢのコマンド部とデータを書き込むべきバッファ領域のアドレス（data_descripter）およびサイズ（data_size）をコマンド処理部１０３に渡す。
【０２０８】
ステップＳ４４０６では、注目ＯＲＢ中の２つのコマンドについて処理が終えたか判定し、終えていなければステップＳ４４０２に戻る。
【０２０９】
図４５は、図４４のステップＳ４４０４またはＳ４４０５において引き渡されたデータを処理するコマンド処理部１０３における処理手順を示す。
【０２１０】
まずステップＳ４５０１においてコマンドを解析し、ステップＳ４５０２においてコマンドの内容に応じた処理を行う。例えばライトコマンドであれば、実行エージェントから受け取ったバッファの内容を、ＰＤＬ処理部１０４に引き渡す。また、ステータスコマンドであれば、ステータスを読み取り（あるいはＰＤＬ処理部により読み取らせて）、それをクラスドライバ１０２に応答する。この処理は後述する。
【０２１１】
次にステップＳ４５０３で、コマンドのIntervalフィールドで指定された時間間隔に従って、応答監視タイマを設定する。そして、処理の応答（成功あるいは失敗あるいはタイムアウトなど）を待つ。そして、応答待ち状態となる。この状態は、ターゲットの処理系次第であり、たとえばいったんタスク終了したりあるいは係属するなど、いくつかの処理の選択肢をとり得る。ただし、いったんタスクを終了すると応答を非同期に処理する必要があるので、コマンド処理とその応答とを対応付けるための識別子等を、コマンドごとに管理する必要がある。
【０２１２】
応答が返るとまずステップＳ４５０４でその内容を判定する。ただし、タイムアウトの場合には、タイマ満了の割り込みによりそれを知ることになると考えられるので、判別すべきはどのコマンドに対するタイムアウトであるか、という点となる。
【０２１３】
さて、応答内容が処理の成功であれば、ステップＳ４５０４において「成功」である旨示すステータスブロックの内容を用意する。一方、タイムアウトであれば、「タイムアウト」であることを示すステータスブロックの内容をステップＳ４５０５で用意する。他のステータスがあれば、ステータスに応じた内容が用意されることはもちろんである。
【０２１４】
そして用意したステータスブロックの内容を、ステップＳ４５０７で実行エージェント１２３へと渡す。実行エージェント１２３は、イニシエータに用意されているアンソリシテッドレジスタを叩き（書き込み）、ステータスブロックがあることをイニシエータに通知する。
【０２１５】
最後に、ステップＳ４５０８で、コマンドのCountフィールドで指定される実行回数の繰返しが終了したか判定し、終了していなければステップＳ４５０２から繰り返す。もちろん残りの繰返し回数は１回減算しておき、次回はその値がステップＳ４５０８でテストされる。
【０２１６】
図４６は、ステータスブロックを受信したイニシエータにおけるプロセッサ１１１による処理手順である。
【０２１７】
まずステップＳ４６００で、受信したステータスブロックがアンソリシテッドステータスであるか、すなわち、対応するＯＲＢがＯＲＢリストにチェインされているか判定する。アンソリシテッドステータスであれば、そのステータスブロックに含まれるあるいは添付されたバッファの内容をクラスドライバ１０２に渡して、処理をゆだねる。
【０２１８】
一方、アンソリシテッドステータスでなければ、ステップＳ４６０１でクラスドライバ１０２へ終了の通知（成功あるいはタイムアウトなど）を行う。そして、ステップＳ４６０３において対応ＯＲＢが２コマンドＯＲＢであるか判定する。
【０２１９】
２コマンドＯＲＢであれば、ステップＳ４６０３において２つのコマンドに対するステータスブロックを受信しているか判定する。この判定は、ＯＲＢに関連づけてコマンド１およびコマンド２に対するステータスブロックの受信の履歴を記録しておくことで可能となる。
【０２２０】
全コマンドについてステータスブロックを受信していれば、ステップＳ４６０５において対応ＯＲＢをＯＲＢリストから削除する。一方、片方のコマンドについてのステータスブロックのみを受信した場合には、ステップＳ４６０４においてその旨を記録し、処理を終了する。
【０２２１】
以上の手順により、１つのＯＲＢに２つのコマンドを載せ、各コマンドについて指定された回数だけ指定された時間間隔で実行させることができる。あるいは、各コマンドについてタイムアウトの時間を設定することができる。
【０２２２】
さらに、２コマンドＯＲＢは、２つのコマンドについてステータスブロックを受信するまで削除されないので、イニシエータからターゲットへのデータの受け渡しを確実に行え、また、イニシエータの送信待機タイマがタイムアウトした場合であっても、再送信することが可能である。そしていったんデータ（コマンド）がターゲットにわたれば、ターゲットからのステータスは、アンソリシテッドステータスとして処理されるために、ＯＲＢリストがはけずに処理が遅滞する事態が生じることもない。
【０２２３】
また、SBP-3プロトコルでは２つのコマンドが１つのORBで実行できるようになったがコマンドごとに完了を確認する手段がなく、その点を改良したSBP-3改ではコマンドごとに完了の通知を受けることができるようになった。さらに、本実施形態においては、完了の条件をコマンド単位で指定することが出来るようになり、コマンドの内容やデバイスの構成により発生していた片方のコマンドが実行できない状況でも、他方のコマンドを期待どうりに有効に実行することが出来る。
【０２２４】
なお、上記手順において、２つのコマンドに対する応答を１つのステータスブロックで返す場合は、たとえば、２つのコマンドに対する応答がほぼ同時に得られることが期待できる場合が考えられる。たとえばコマンドが一致し、かつ、実行回数(Count)および時間間隔(Interval)が２つのコマンドについて一致する場合などに、適用できる。
【０２２５】
＜プリンタシステムのハードウエア構成＞
最後に、イニシエータであるホスト装置５１（図１の１ａに相当）とターゲットであるプリンタ５２（図１の１ｂに相当）のハードウェア構成について説明する。図４７は情報処理システムを構成するホスト装置５１とプリンタ５２のハードウェア構成概要を示すブロック図である。
【０２２６】
図２に示されているように、ホスト装置５１は処理部１０００とこれに周辺装置を含めてホスト装置全体を構成している。また、画像出力装置５２は、記録ヘッド３０１０、記録ヘッド３０１０を搬送するキャリアを駆動するキャリア（ＣＲ）モータ３０１１、用紙を搬送する搬送モータ３０１２などの駆動部と、制御回路部３００３とから構成されている。
【０２２７】
ホスト装置５１の処理部１０００は、制御プログラムに従ってホスト装置の全体制御を司るＭＰＵ１００１、システム構成要素を互いに接続するバス１００２、ＭＰＵ１００１が実行するプログラムやデータ等を一時記憶するＤＲＡＭ１００３、システムバスとメモリバス、ＭＰＵ１００１を接続するブリッジ１００４、例えば、ＣＲＴなどの表示装置２００１にグラフィック情報を表示するための制御機能を備えたグラフィックアダプタ１００５を含んでいる。
【０２２８】
さらに、処理部１０００はＨＤＤ装置２００２とのインタフェースを司るＨＤＤコントローラ１００６、キーボード２００３とのインタフェースを司るキーボードコントローラ１００７、ＩＥＥＥ１３９４規格に従ってプリンタ５２との間の通信を司る、ＩＥＥＥ１３９４である通信Ｉ／Ｆ１００８を備えている。
【０２２９】
さらに、処理部１０００には、グラフィックアダプタ１００５を介して操作者にグラフィック情報等を表示する表示装置２００１（この例では、ＣＲＴ）が接続されている。更に、プログラムやデータが格納された大容量記憶装置であるハードディスクドライブ（ＨＤＤ）装置２００２、キーボード２００３が夫々、コントローラを介して接続されている。
【０２３０】
一方、プリンタ５２の制御回路部３００３は、制御プログラム実行機能と周辺装置制御機能とを兼ね備えた、プリンタ５２の全体制御を司るＭＣＵ３００１、制御回路部内部の各構成要素を接続するシステムバス３００２、記録データの記録ヘッド３０１０への供給、メモリアドレスデコーディング、キャリアモータへの制御パルス発生機構等を制御回路として内部に納めたゲートアレイ（Ｇ．Ａ．）を備えている。
【０２３１】
また、制御回路部３００３は、ＭＣＵ３００１が実行する制御プログラムやホスト印刷情報等を格納するＲＯＭ３００４、各種データ（画像記録情報やヘッドに供給される記録データ等）を保存するＤＲＡＭ３００５、ＩＥＥＥ１３９４規格に従いホスト装置５１との間の通信を司るシリアルインタフェースである通信Ｉ／Ｆ３００６、ゲートアレイ３００３から出力されたヘッド記録信号に基づき、記録ヘッド３０１０を駆動する電気信号に変換するヘッドドライバ３００７を備えている。
【０２３２】
さらに、制御回路部３００３は、ゲートアレイ３００３から出力されるキャリアモータ制御パルスを実際にキャリア（ＣＲ）モータ３０１１を駆動する電気信号に変換するＣＲモータドライバ３００８、ＭＣＵ３００１から出力された搬送モータ制御パルスを、実際に搬送モータを駆動する電気信号に変換するＬＦモータドライバ３００９を備えている。
【０２３３】
＜他の実施形態＞
以上説明した実施形態によれば、本発明は次のようなものとして把握できる。
【０２３４】
（１）一次側装置において、１つのコマンドブロックに複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てて二次側装置に引き渡し、二次側装置において、コマンドブロックに含まれる複数のコマンドを独立してあるいは非同期に実行する通信システムであって、
前記一次側装置は、各コマンドに対応する条件を当該コマンドが割り当てられたコマンドブロックに記述し、
前記二次側装置は、各コマンドを、それぞれに対応する条件に応じて実行する。
【０２３５】
（２）（１）において、前記条件は、コマンドの実行回数と実行間隔を含むことを特徴とする請求項１に記載の通信システム。
【０２３６】
（３）（１）または（２）において、前記二次側装置は、各コマンドの実行が終了する都度、独立して前記一次側装置に対して実行結果を応答する。
【０２３７】
（４）（３）において、前記一次側装置は、前記二次側装置に引き渡すコマンドブロックのリストを保持し、前記二次側装置から、１つのコマンドブロックに含まれる全コマンドについて実行結果の応答を受けた場合に、当該コマンドブロックを前記リストから削除する。
【０２３８】
（５）（１）乃至（４）において、前記一次側装置は前記コマンドブロックおよびデータバッファを格納するための記憶部を備え、前記二次側装置は、前記一時側装置の備える記憶部にアクセスすることでデータを交換する。
【０２３９】
（６）（１）乃至（５）において、前記一次側装置はホストコンピュータであり、前記二次側装置はプリンタであって、前記ホストコンピュータは、前記データバッファに印刷コマンドを書き込んで前記プリンタに引き渡し、前記プリンタは、引き渡された印刷コマンドに従って印刷処理を遂行する。
【０２４０】
（７）１つのコマンドブロックに複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てて二次側装置に引き渡す通信装置であって、
各コマンドに対応する条件を当該コマンドが割り当てられたコマンドブロックに記述し、前記二次側装置に前記コマンドブロックを引き渡す。
【０２４１】
（８）（７）において、前記条件は、コマンドの実行回数と実行間隔を含む。
【０２４２】
（９）（８）において、前記二次側装置に引き渡すコマンドブロックのリストを保持し、前記二次側装置から、１つのコマンドブロックに含まれる全コマンドについて実行結果の応答を受けた場合に、当該コマンドブロックを前記リストから削除する。
【０２４３】
（１０）（７）乃至（９）において、前記コマンドブロックおよびデータバッファを格納するための記憶部を備え、前記二次側装置から前記記憶部にアクセスすることで前記二次側装置とデータを交換する。
【０２４４】
（１１）（７）乃至（１０）において、前記二次側装置はプリンタであって、前記データバッファに印刷コマンドを書き込んで前記プリンタに引き渡す。
【０２４５】
（１２）一次側装置から、複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てられたコマンドブロックを読む通信装置であって、
前記コマンドブロックからコマンドおよびその条件を読み、各コマンドを、それぞれに対応する条件に応じて実行する。
【０２４６】
（１３）（１２）において、前記条件は、コマンドの実行回数と実行間隔を含む。
【０２４７】
（１４）（１２）または（１３）において、各コマンドの実行が終了する都度、独立して前記一次側装置に対して実行結果を応答する。
【０２４８】
（１５）（１２）乃至（１４）において、前記一次側装置は前記コマンドブロックおよびデータバッファを格納するための記憶部を備え、前記一時側装置の備える記憶部にアクセスすることでデータを交換する。
【０２４９】
（１６）（１２）乃至（１５）を用いたプリンタであって、前記一次側装置はホストコンピュータであり、前記ホストコンピュータは、前記データバッファに印刷コマンドを書き込んで引き渡された印刷コマンドに従って印刷処理を遂行する。
【０２５０】
（１７）また、（７）乃至（１１）または（１２）乃至（１５）の機能を、コンピュータにより実現するためのプログラムも本発明に含まれる。
【０２５１】
【発明の効果】
上記説明したように、本発明によれば、複数のコマンドを含むコマンドブロックを二次側装置で処理させる場合に、実行の条件をコマンド単位で指定することが出来るようになり、コマンドの内容やデバイスの構成により発生していた片方のコマンドが実行できない状況でも、他方のコマンドを期待どうりに有効に実行することが出来る。
【図面の簡単な説明】
【図１】本発明のホスト・プリンタ通信システムの構成を示した図である。
【図２】１３９４シリアルバスのネットワークの構成を示した図である。
【図３】本発明の１３９４シリアルバスの構成要素を示した図である。
【図４】本発明の１３９４シリアルバスのリンク・レイヤ提供可能なサービスを示す図である。
【図５】本発明の１３９４シリアルバスのトランズアクション・レイヤ提供可能なサービスを示す図である。
【図６】１３９４インタフェースにおけるアドレス空間を説明する図である
【図７】１３９４インタフェースにおけるＣＳＲコア・レジスタに格納される情報のアドレス及び機能を示す図である。
【図８】１３９４インタフェースにおけるシリアルバス・レジスタに格納される情報のアドレス及び機能を示す図である。
【図９】１３９４インタフェースにおける最小形式のConfiguration ROMを示す図である。
【図１０】１３９４インタフェースにおける一般形式のConfiguration ROMを示す図である。
【図１１】１３９４インタフェースにおけるシリアルバス装置レジスタに格納される情報のアドレス及び機能を示す図である。
【図１２】ＩＥＥＥ１３９４規格に準拠した通信ケーブルの断面図である。
【図１３】DS-Link符号化方式を説明する図である。
【図１４】、
【図１５】、
【図１６】バスリセットの開始からノードＩＤの割り当て処理までの基本的なシーケンスを示した図である。。
【図１７】図１５に示したステップＳ１５０５の処理（即ち、自動的に各ノードのノードＩＤを割り当てる処理）を詳細に説明するフローチャートである。
【図１８】１３９４インターフェースにおけるセルフＩＤパケットの構成を示した図である。
【図１９】１３９４ネットワークにおけるアービトレーションを説明する図である。
【図２０】１通信サイクルにおいてIsochronous転送モードとAsynchronous転送モードとを混在させた場合を説明する図である。
【図２１】Isochronous転送モードに基づいて転送される通信パケットのフォーマットを示した図である。
【図２２】本発明のアシンクロナス転送のパケットフォーマットを示した図である。
【図２３】ＳＢＰ−２におけるＯＲＢ種別を示した図である。
【図２４】ＳＢＰ−２におけるコマンドブロックＯＲＢのフォーマットを示した図である。
【図２５】ＳＢＰ−２におけるマネージメントＯＲＢのフォーマットを示した図である。
【図２６】ＳＢＰ−２におけるコマンドブロックＯＲＢのリンクリストを示した図である。
【図２７】ＳＢＰ−２におけるデータバッファの直接アクセスを示した図である。
【図２８】ＳＢＰ−２におけるページテーブルの使用を示した図である。
【図２９】ＳＢＰ−２におけるステータスＦＩＦＯのフォーマットを示した図である。
【図３０】ＳＢＰ−２におけるログイン動作を示した図である。
【図３１】ＳＢＰ−２にタスク実行の最初の動作を示した図である。
【図３２】ＳＢＰ−２におけるコマンドＯＲＢの動作を示した図である。
【図３３】ＳＢＰ−３におけるコマンドＯＲＢの動作を示した図である。
【図３４】ＳＢＰ−３におけるコマンドブロックＯＲＢのフォーマットを示した図である。
【図３５】ＳＢＰ−３改におけるステータスＦＩＦＯのフォーマットを示した図である。
【図３６】ＳＢＰ−３改におけるコマンドＯＲＢの動作を示した図である。
【図３７】本実施形態におけるコマンドブロックＯＲＢのフォーマットを示した図である。
【図３８】本実施形態におけるステータスＦＩＦＯのフォーマットを示した図である。
【図３９】本実施形態におけるコマンドＯＲＢの動作を示した図である。
【図４０】本実施形態におけるコマンドブロックＯＲＢの具体例を示した図である。
【図４１】本実施形態における正常に終了したステータスＦＩＦＯの具体例を示した図である。
【図４２】本実施形態におけるタイムアウトしたステータスＦＩＦＯの具体例を示した図である。
【図４３】本実施形態におけるクラスドライバにおける処理手順の一例を示した図である。
【図４４】本実施形態における実行エージェントにおける処理手順の一例を示した図である。
【図４５】本実施形態におけるコマンド処理部における処理手順の一例を示した図である。
【図４６】本実施形態におけるイニシエータにおけるステータスブロック処理手順の一例を示した図である。
【図４７】本実施形態における印刷システムのハードウエアブロック図である。
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４等のインターフェースで接続される通信システムに関するものである。
【０００２】
【従来の技術】
セントロニクス、ＵＳＢ、そしてIEEE1394等の各種インターフェースにおいてホストとデバイスの１対１接続で通信を行なう場合、ホスト−デバイス間では、デバイスの各種機能を制御するために通信プロトコルの１セッション中に複数の論理チャネル接続を樹立し、チャネルごとにデータ転送を行なう。
【０００３】
IEEE1394上のデータ通信プロトコルであるＳＢＰ−２は、ひとつのイニシエータとひとつのターゲットの対から構成されるひとつのロジカルユニットにおいて、データ転送の単位であるＯＲＢ１個に対して１つのデータバッファが参照される。そのため、片方向の単一データチャネルあるいは片方向半二重のデータ通信を行なう仕組みになっており、複数論理チャネルを実現するのは困難である。現在規格策定中のＳＢＰ−２の機能拡張版であるＳＢＰ−３においてはこの点に注目し、ロジカルユニットにおけるデータ転送の単位であるＯＲＢに対して２つのデータバッファを参照できるようにして１ロジカルユニットにつき２つのデータ転送チャネルを実現することを可能とする拡張が行なわれた。
【０００４】
【発明が解決しようとする課題】
しかしながらＳＢＰ−３のデータ転送においては２つのデータ転送チャネルのフローコントロールはあくまでもＯＲＢ単位で行なわれるため、何らかの理由によりどちらかのデータ転送チャネルにおいてデータの送受信が出来なくなった場合、またどちらかのデータ転送チャネルのデータ転送が他のチャネルよりも遅い場合、速いほうのチャネルが遅いチャネルの影響を受けてしまう。これは、片方のデータバッファに対するアクセスが正常終了しても、もう片方のデータバッファへのアクセスが完了しないとそのＯＲＢに対する完了通知（ステータスブロック）をＳＢＰ−３のイニシエータに対して通知できないためで、ロジカルユニットとしてのデータ転送が滞ってしまう為である。
【０００５】
また１つのＯＲＢに２つのデータバッファとコマンドを配置することが出来るコマンドセットをＳＢＰ−３で実現するような場合、ターゲットデバイスによっては各コマンドが独立した条件に従って実行されることでより効率的なデータ転送を行うことが出来る場合がある。
【０００６】
本発明は上記従来例に鑑みてなされたもので、コマンドごとに独立した条件を設定することを可能とし、コマンドごとに設定された条件に応じて実行する通信システムを提供することを目的とする。
【０００７】
【課題を解決するための手段】
上記目的を達成するために本発明の通信システムは次の構成を備える。
【０００８】
一次側装置において、１つのコマンドブロックに複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てて二次側装置に引き渡し、二次側装置において、コマンドブロックに含まれる複数のコマンドを独立して実行する通信システムであって、
前記一次側装置は、前記各データバッファに対応した複数のコマンドそれぞれに対して独立した条件を設定し、当該独立した条件がそれぞれ設定された複数のコマンドを含む１つのコマンドブロックを作成し、作成された前記１つのコマンドブロックを前記二次側装置に送信し、
前記二次側装置は、前記一次側装置から送信された前記１つのコマンドブロックを受信し、当該コマンドブロックに含まれる複数のコマンドを、それぞれのコマンドに設定されている条件に応じて実行する。
【０００９】
【発明の実施の形態】
図１は、本発明を最もよくあらわす図であり、ＩＥＥＥ１３９４で接続されたホストコンピュータ（以下ホスト）１−ａとプリンタ１−ｂを表している。
【００１０】
コンピュータＡとプリンタＢの通信は、ＩＥＥＥ１３９４インターフェース上で使われる代表的なデータ転送プロトコルであるＳＢＰ（Serial Bus Protocol）−３（改）プロトコルを使って行なわれ、ホストープリンタ間のデータ転送を行なうための通信チャネルとしてＬＵＮ０が予め定められている。なおＳＢＰ−３（改）プロトコルは標準化されているＳＢＰ−３に若干の変更を施したもので、その概要は後述する。
【００１１】
本実施形態では、ＳＢＰ−３改プロトコル上において、イニシエータのクラスドライバ１０１（本実施形態ではプリンタクラス）と、ターゲットのコマンド処理部１０３との間で定義されたプロトコル層が定義されており、さらにその上に、イニシエータ上のプリンタドライバ１０１とターゲット上のＰＤＬ処理部１０４との間において、アプリケーション層のプロトコルが定義されている。アプリケーション層における取り決めは、ページ記述言語（ＰＤＬ）の定義がその中心となる。中間層は、ＳＢＰ−３とアプリケーション層との間にあってデバイスの種類等に応じて定義され、本実施形態ではデバイスがプリンタであるとして定義されている。この層における処理手順についても後述する。
【００１２】
〈ＩＥＥＥ１３９４の技術の概要〉
以下、本実施例のデジタルインタフェースに適用されるＩＥＥＥ１３９４−１９９５規格の技術について簡単に説明する。尚、ＩＥＥＥ１３９４−１９９５規格（以下、ＩＥＥＥ１３９４規格）についての詳細は、１９９６年の８月３０日にＩＥＥＥ（The Institute of Electrical and Electronics Engineers, Inc．）から出版された「ＩＥＥＥ Standard for a High Performance Serial Bus」に記述されている。
【００１３】
（１）概要
図２にＩＥＥＥ１３９４規格に準拠したデジタルインタフェース（以下、１３９４インタフェース）を具備するノードにより構成される通信システム（以下、１３９４ネットワーク）の一例を示す。１３９４ネットワークは、シリアルデータの通信可能なバス型ネットワークを構成するものである。
【００１４】
図２において、各ノードＡ〜Ｆは、ＩＥＥＥ１３９４規格に準拠した通信ケーブルを介して接続されている。これらのノードＡ〜Ｈは、例えば、ＰＣ（Personal Computer）、デジタルＶＴＲ（Video Tape Recorder）、ＤＶＤ（Digital Video Disc）プレーヤ、デジタルカメラ、ハードディスク、モニタ等の電子機器である。
【００１５】
１３９４ネットワークの接続方式は、ディジーチェーン方式とノード分岐方式とに対応しており、自由度の高い接続を可能としている。
【００１６】
又、１３９４ネットワークでは、例えば、既存の機器を削除したり、新たな機器を追加したり、既存の機器の電源をON／OFFしたりした場合に、自動的にバスリセットを行う。このバスリセットを行うことにより、１３９４ネットワークは、新たな接続構成の認識と各機器に対するＩＤ情報の割り当てとを自動的に行うことができる。この機能によって、１３９４ネットワークは、ネットワークの接続構成を常時認識することができる。
【００１７】
又、１３９４ネットワークは、他の機器から転送されたデータを中継する機能を有している。この機能により、全ての機器がバスの動作状況を把握することができる。
【００１８】
又、１３９４ネットワークは、Plug＆Playと呼ばれる機能を有している。この機能により、全ての機器の電源をＯＦＦにすることなく、接続するだけで自動に接続機器を認識することができる。
【００１９】
又、１３９４ネットワークは、１００／２００／４００Ｍｂｐｓのデータ転送速度に対応している。上位のデータ転送速度を持つ機器は、下位のデータ転送速度をサポートすることができるため、異なるデータ転送速度に対応する機器同士を接続することができる。
【００２０】
更に、１３９４ネットワークは、２つの異なるデータ転送方式（即ち、Asynchronous転送モードとIsochronous転送モード）に対応している。
【００２１】
Asynchronous転送モードは、必要に応じて非同期に転送することが要求されるデータ（即ち、コントロール信号やファイルデータ等）を転送する際に有効である。又、Isochronous転送モードは、所定量のデータを一定のデータレートで連続的に転送することが要求されるデータ（即ち、ビデオデータやオーディオデータ等）を転送する際に有効である。
【００２２】
Asynchronous転送モードとIsochronous転送モードとは、各通信サイクル（通常１サイクルは、１２５μＳ）内において、混在させることが可能である。各転送モードは、サイクルの開始を示すサイクル・スタート・パケット（以下、ＣＳＰ）の転送後に実行される。 尚、各通信サイクル期間において、Isochronous転送モードは、Asynchronous転送モードよりも優先順位が高く設定されている。又、Isochronous転送モードの転送帯域は、各通信サイクル内で保証されている。
【００２３】
（２）アーキテクチャ
次に、図３を用いて１３９４インタフェースの構成要素を説明する。
【００２４】
１３９４インタフェースは、機能的に複数のレイヤ（階層）から構成されている。図３において、１３９４インタフェースは、ＩＥＥＥ１３９４規格に準拠した通信ケーブル３０１を介して他のノードの１３９４インタフェースと接続される。又、１３９４インタフェースは、１つ以上の通信ポート３０２を有し、通信ポート３０２は、ハードウェア部に含まれるフィジカル・レイヤ３０３と接続される。
【００２５】
図３において、ハードウェア部は、フィジカル・レイヤ３０３とリンク・レイヤ３０４とから構成されている。フィジカル・レイヤ３０３は、他のノードとの物理的、電気的なインタフェース、バスリセットの検出とそれに伴う処理、入出力信号の符号化／復号化、バス使用権の調停等を行う。又、リンク・レイヤ３０４は、通信パケットの生成と送受信、サイクルタイマの制御等を行なう。
【００２６】
又、図３において、ファームウェア部は、トランザクション・レイヤ３０５とシリアル・バス・マネージメント３０６とを含んでいる。トランザクション・レイヤ３０５は、Asynchronous転送モードを管理し、各種のトランザクション（リード、ライト、ロック）を提供する。シリアル・バス・マネージメント３０６は、後述するＣＳＲアーキテクチャに基づいて、自ノードの制御、自ノードの接続状態の管理、自ノードのＩＤ情報の管理、シリアルバスネットワークの資源管理を行う機能を提供する。
【００２７】
以上、ハードウェア部とファームウェア部とが実質的に１３９４インタフェースを構成するものであり、それらの基本構成は、ＩＥＥＥ１３９４規格により規定されている。
【００２８】
又、ソフトウェア部に含まれるアプリケーション・レイヤ３０７は、使用するアプリケーションソフトによって異なり、ネットワーク上でどのようにデータを通信するのかを制御する。例えば、デジタルＶＴＲの動画像データの場合は、ＡＶ／Ｃプロトコルなどの通信プロトコルによって規定されている。
【００２９】
（２−１）リンク・レイヤ３０４
図４は、リンク・レイヤ３０４の提供可能なサービスを示す図である。図４において、リンク・レイヤ３０４は、次の４つのサービスを提供する。即ち、(1)応答ノードに対して所定のパケットの転送を要求するリンク要求（LK_DATA.request）、(2)応答ノードに所定のパケットの受信を通知するリンク通知（LK_DATA.indication）、(3)応答ノードからのアクノリッジを受信したことを示すリンク応答（LK_DATA.response）、(4)要求ノードからのアクノリッジを確認するリンク確認（LK_DATA.confirmation）である。尚、リンク応答（LK_DATA.response）は、ブロードキャスト通信、Isochronousパケットの転送の場合には存在しない。
【００３０】
又、リンク・レイヤ３０４は、上述のサービスに基づいて、上述の２種類の転送方式、即ち、Asynchronous転送モード、Isochronous転送モードを実現する。
【００３１】
（２−２）トランザクション・レイヤ３０５
図５は、トランザクション・レイヤ３０５の提供可能なサービスを示す図である。図５において、トランザクション・レイヤ３０５は、次の４つのサービスを提供する。即ち、(1)応答ノードに対して所定のトランザクションを要求するトランザクション要求（TR_DATA.request）、(2)応答ノードに所定のトランザクション要求の受信を通知するトランザクション通知（TR_DATA.indication）、(3)応答ノードからの状態情報（ライト、ロックの場合は、データを含む）を受信したことを示すトランザクション応答（TR_DATA.response）、(4)要求ノードからの状態情報を確認するトランザクション確認（TR_DATA.confirmation）である。
【００３２】
又、トランザクション・レイヤ３０５は、上述のサービスに基づいてAsynchronous転送を管理し、次の３種類のトランザクション、即ち、(1)リード・トランザクション、(2)ライト・トランザクション、(3)ロック・トランザクションを実現する。
(1)リード・トランザクションは、要求ノードが応答ノードの特定アドレスに格納された情報を読み取る。
(2)ライト・トランザクションは、要求ノードが応答ノードの特定アドレスに所定の情報を書き込む。
(3)ロック・トランザクションは、要求ノードが応答ノードに対して参照データと更新データとを転送し、応答ノードの特定アドレスの情報とその参照データとを比較し、その比較結果に応じて特定アドレスの情報を更新データに更新する。
【００３３】
（２−３）シリアル・バス・マネージメント３０６
シリアル・バス・マネージメント３０６は、具体的に、次の３つの機能を提供することができる。３つの機能とは、即ち、(1)ノード制御、(2)アイソクロナス・リソース・マネージャ（以下、ＩＲＭ）、(3)バスマネージャである。
【００３４】
(1)ノード制御は、上述の各レイヤを管理し、他のノードとの間で実行されるAsynchronous転送を管理する機能を提供する。
【００３５】
(2)ＩＲＭは、他のノードとの間で実行されるIsochronous転送を管理する機能を提供する。具体的には、転送帯域幅とチャネル番号の割り当てに必要な情報を管理し、これらの情報を他のノードに対して提供する。
【００３６】
ＩＲＭは、ローカルバス上に唯一存在し、バスリセット毎に他の候補者（ＩＲＭの機能を有するノード）の中から動的に選出される。又、ＩＲＭは、後述のバスマネージャの提供可能な機能（接続構成の管理、電源管理、速度情報の管理等）の一部を提供してもよい。
【００３７】
(3)バスマネージャは、ＩＲＭの機能を有し、ＩＲＭよりも高度なバス管理機能を提供する。具体的には、より高度な電源管理（通信ケーブルを介して電源の供給が可能か否か、電源の供給が必要か否か等の情報を各ノード毎に管理）、より高度な速度情報の管理（各ノード間の最大転送速度の管理）、より高度な接続構成の管理（トポロジ・マップの作成）、これらの管理情報に基づくバスの最適化等を行ない、更にこれらの情報を他のノードに提供する機能を有する。
【００３８】
又、バスマネージャは、シリアルバスネットワークを制御するためのサービスをアプリケーションに対して提供できる。ここで、サービスには、シリアルバス制御要求（SB_CONTROL.request）、シリアルバス・イベント制御確認（SB_CONTROL.confirmation）、シリアルバス・イベント通知（SB_CONTROL.indication）等がある。
【００３９】
SB_CONTROL.requestは、アプリケーションがバスリセットを要求するサービスである。SB_CONTROL.confirmationは、SB_CONTROL.requestをアプリケーションに対して確認するサービスである。SB_CONTROL.indicationは、非同期に発生するイベントをアプリケーションに対して通知するサービスである。
【００４０】
（３）アドレス指定
図６は、１３９４インタフェースにおけるアドレス空間を説明する図である。尚、１３９４インタフェースは、ISO/IEC 13213:1994に準じたＣＳＲ（Command and Status Register）アーキテクチャに従い、６４ビット幅のアドレス空間を規定している。
【００４１】
図６において、最初の１０ビットのフィールド６０１は、所定のバスを指定するＩＤ番号に使用され、次の６ビットのフィールド６０２は、所定の機器（ノード）を指定するＩＤ番号に使用される。この上位１６ビットを「ノードＩＤ」と呼び、各ノードはこのノードＩＤにより他のノードを識別する。又、各ノードは、このノードＩＤを用いて相手を識別した通信を行うことができる。
【００４２】
残りの４８ビットからなるフィールドは、各ノードの具備するアドレス空間（２５６Ｍバイト構造）を指定する。その内の２０ビットのフィールド６０３は、アドレス空間を構成する複数の領域を指定する。
【００４３】
フィールド６０３において、「０〜０ｘＦＦＦＦＤ」の部分は、メモリ空間と呼ばれる。「０ｘＦＦＦＦＥ」の部分は、プライベート空間と呼ばれ、各ノードで自由に利用できるアドレスである。又、「０ｘＦＦＦＦＥ」の部分は、レジスタ空間と呼ばれ、バスに接続されたノード間において共通の情報を格納する。各ノードは、レジスタ空間の情報を用いることにより、各ノード間の通信を管理することができる。
【００４４】
最後の２８ビットのフィールド６０４は、各ノードにおいて共通或いは固有となる情報が格納されるアドレスを指定する。
【００４５】
例えば、レジスタ空間において、最初の５１２バイトは、ＣＳＲアーキテクチャーのコア（ＣＳＲコア）レジスタ用に使用される。ＣＳＲコア・レジスタに格納される情報のアドレス及び機能を図７に示す。図中のオフセットは、「０ｘＦＦＦＦＦ０００００００」からの相対位置である。
【００４６】
次の５１２バイトは、シリアルバス用のレジスタとして使用される。シリアルバス・レジスタに格納される情報のアドレス及び機能を図８に示す。図中のオフセットは、「０ｘＦＦＦＦＦ００００２００」からの相対位置である。
【００４７】
その次の１０２４バイトは、Configuration ROM用に使用される。
【００４８】
Configuration ROMには最小形式と一般形式とがあり、「０ｘＦＦＦＦＦ００００４００」から配置される。最小形式のConfiguration ROMを図９に示す。図９において、ベンダＩＤは、ＩＥＥＥにより各ベンダに対して固有に割り当てられた２４ビットの数値である。
【００４９】
又、一般形式のConfiguration ROMを図１０に示す。図１０において、上述のベンダＩＤは、Root Directory１００２に格納されている。Bus Info Block１００１とRoot Leaf１００５とには、各ノードを識別する固有のＩＤ情報としてノードユニークＩＤを保持することが可能である。
【００５０】
ここで、ノードユニークＩＤは、メーカ、機種に関わらず、１つのノードを特定することのできる固有のＩＤを定めるようになっている。ノードユニークＩＤは６４ビットにより構成され、上位２４ビットは上述のベンダＩＤを示し、下位４８ビットは各ノードを製造するメーカにおいて自由に設定可能な情報（例えば、ノードの製造番号等）を示す。尚、このノードユニークＩＤは、例えばバスリセットの前後で継続して特定のノードを認識する場合に使用される。
【００５１】
又、図１０において、Root Directory１００２には、ノードの基本的な機能に関する情報を保持することが可能である。詳細な機能情報は、Root Directory１００２からオフセットされるサブディレクトリ（Unit Directories１００４）に格納される。Unit Directories１００４には、例えば、ノードのサポートするソフトウェアユニットに関する情報が格納される。具体的には、ノード間のデータ通信を行うためのデータ転送プロトコル、所定の通信手順を定義するコマンドセット等に関する情報が保持される。
【００５２】
又、図１０において、Node Dependent Info Directory１００３には、デバイス固有の情報を保持することが可能である。Node Dependent Info Directory１００３は、Root Directory１００２によりオフセットされる。
【００５３】
更に、図１０において、Vendor Dependent Information１００６には、ノードを製造、或いは販売するベンダ固有の情報を保持することができる。
【００５４】
残りの領域は、ユニット空間と呼ばれ、各ノード固有の情報、例えば、各機器の識別情報（会社名、機種名等）や使用条件等が格納されたアドレスを指定する。ユニット空間のシリアルバス装置レジスタに格納される情報のアドレス及び機能を図１１に示す。図中のオフセットは、「０ｘＦＦＦＦＦ００００８００」からの相対位置である。
【００５５】
尚、一般的に、異種のバスシステムの設計を簡略化したい場合、各ノードは、レジスタ空間の最初の２０４８バイトのみを使うべきである。つまり、ＣＳＲコア・レジスタ、シリアルバス・レジスタ、Configuration ROM、ユニット空間の最初の２０４８バイトの合わせて４０９６バイトで構成することが望ましい。
【００５６】
（４）通信ケーブルの構成
図１２にＩＥＥＥ１３９４規格に準拠した通信ケーブルの断面図を示す。
【００５７】
通信ケーブルは、２組のツイストペア信号線と電源ラインとにより構成されている。電源ラインを設けることによって、１３９４インタフェースは、主電源のＯＦＦとなった機器、故障により電力低下した機器等にも電力を供給することができる。尚、電源線内を流れる電源の電圧は８〜４０Ｖ、電流は最大電流ＤＣ１．５Ａと規定されている。
【００５８】
２組のツイストペア信号線には、DS-Link（Data/Strobe Link）符号化方式にて符号化された情報信号が伝送される。図１３は、DS-Link符号化方式を説明する図である。
【００５９】
このDS-Link符号化方式は、高速なシリアルデータ通信に適しており、その構成は、２組のより対線を必要とする。一組のより対線は、データ信号を送り、他のより対線は、ストローブ信号を送る構成になっている。受信側は、２組の信号線から受信したデータ信号とストローブ信号との排他的論理和をとることによって、クロックを再現することができる。
【００６０】
尚、DS-Link符号化方式を用いることにより、１３９４インタフェースには、例えば次のような利点がある。(1)他の符号化方式に比べて転送効率が高い。(2)ＰＬＬ回路が不要となり、コントローラＬＳＩの回路規模を小さくできる。(3)アイドル状態であることを示す情報を送る必要が無いため、トランシーバ回路をスリープ状態とし易く、消費電力の低減が図れる。
【００６１】
（５）バスリセット
各ノードの１３９４インタフェースは、ネットワークの接続構成に変化が生じたことを自動的に検出することができる。この場合、１３９４ネットワークは以下に示す手順によりバスリセットと呼ばれる処理を行う。尚、接続構成に変化は、各ノードの具備する通信ポートかかるバイアス電圧の変化により検知することができる。
【００６２】
ネットワークの接続構成の変化（例えば、ノードの挿抜、ノードの電源のＯＮ／ＯＦＦなどによるノード数の増減）を検出したノード、又は新たな接続構成を認識する必要のあるノードは、１３９４インタフェースを介して、バス上にバスリセット信号を送信する。
【００６３】
バスリセット信号を受信したノードの１３９４インタフェースは、バスリセットの発生を自身のリンク・レイヤ３０４に伝達すると共に、そのバスリセット信号を他のノードに転送する。バスリセット信号を受信したノードは、今まで認識していたネットワークの接続構成及び各機器に割り当てられたノードＩＤをクリアにする。最終的に全てのノードがバスリセット信号を検知した後、各ノードは、バスリセットに伴う初期化処理（即ち、新たな接続構成の認識と新たなノードＩＤの割り当て）を自動的に行う。
【００６４】
尚、バスリセットは、先に述べたような接続構成の変化による起動の他に、ホスト側の制御によって、アプリケーション・レイヤ３０７がフィジカル・レイヤ３０３に対して直接命令を出すことによって起動させることも可能である。
【００６５】
又、バスリセットが起動するとデータ転送は一時中断され、バスリセットに伴う初期化処理の終了後、新しいネットワークのもとで再開される。
【００６６】
（６）バスリセット起動後のシーケンス
バスリセットの起動後、各ノードの１３９４インタフェースは、新たな接続構成の認識と新たなノードＩＤの割り当てとを自動的に実行する。以下、バスリセットの開始からノードＩＤの割り当て処理までの基本的なシーケンスを図１４〜１６を用いて説明する。
【００６７】
図１４は、図２の１３９４ネットワークにおけるバスリセット起動後の状態を説明する図である。
【００６８】
図１４において、ノードＡは１つの通信ポート、ノードＢは２つの通信ポート、ノードＣは２つの通信ポート、ノードＤは３つの通信ポート、ノードＥは１つの通信ポート、ノードＦは１つの通信ポートを具備している。各ノードの通信ポートには、各ポートを識別するためにポート番号を付されている。
【００６９】
以下、図１４におけるバスリセットの開始からノードＩＤの割り当てまでを図１５のフローチャートを用いて説明する。
【００７０】
図１５において、１３９４ネットワークを構成する各ノードＡ〜Ｆは、バスリセットが発生したか否かを常時監視している（ステップＳ１５０１）。接続構成の変化を検出したノードからバスリセット信号が出力されると、各ノードは以下の処理を実行する。
【００７１】
バスリセットの発生後、各ノードは、夫々の具備する通信ポート間において親子関係の宣言を行なう（ステップＳ１５０２）。
【００７２】
各ノードは、全てのノード間の親子関係が決定されるまで、ステップＳ１５０２の処理を繰り返し行なう（ステップＳ１５０３）。
【００７３】
全てのノード間の親子関係が決定した後、１３９４ネットワークは、ネットワークの調停を行なうノード、即ちルートを決定する。（ステップＳ１５０４）。
【００７４】
ルートを決定した後、各ノードの１３９４インタフェース夫々は、自己のノードＩＤを自動的に設定する作業を実行する（ステップＳ１５０５）。
【００７５】
全てのノードに対してノードＩＤの設定がなされるまで、各ノードは所定の手順に基づきステップＳ１５０５の処理を実行する（ステップＳ１５０６）。
【００７６】
最終的に全てのノードに対してノードＩＤが設定された後、各ノードは、Isochronous転送或いはAsynchronous転送を実行する（ステップＳ１５０７）。
【００７７】
ステップＳ１５０７の処理を実行すると共に、各ノードの１３９４インタフェースは、再びバスリセットの発生を監視する。バスリセットが発生した場合には、ステップＳ１５０１以降の処理を再び実行する。
【００７８】
以上の手順により、各ノードの１３９４インタフェースは、バスリセットが起動する毎に、新たな接続構成の認識と新たなノードＩＤの割り当てとを自動的に実行することができる。
【００７９】
（７）親子関係の決定
次に、図１６を用いて、図１５に示したステップＳ１５０２の処理（即ち、各ノード間の親子関係を認識する処理）について詳細に説明する。
【００８０】
図１６において、バスリセットの発生後、１３９４ネットワーク上の各ノードＡ〜Ｆは、自分の具備する通信ポートの接続状態（接続又は未接続）を確認する（ステップＳ１６０１）。
【００８１】
通信ポートの接続状態の確認後、各ノードは、他のノードと接続されている通信ポート（以下、接続ポート）の数をカウントする（ステップＳ１６０２）。
【００８２】
ステップＳ１６０２の処理の結果、接続ポートの数が１つである場合、そのノードは、自分が「リーフ」であると認識する（ステップＳ１６０３）。ここで、リーフとは、１つのノードとのみ接続されているノードのことである。
【００８３】
リーフとなるノードは、その接続ポートに接続されているノードに対して、「自分は子（Ｃｈｉｌｄ）」であることを宣言する（ステップＳ１６０４）。このとき、リーフは、その接続ポートが「親ポート（親ノードと接続された通信ポート）」であると認識する。
【００８４】
ここで、親子関係の宣言は、まず、ネットワークの末端であるリーフとブランチとの間にて行われ、続いて、ブランチとブランチとの間で順次に行われる。各ノード間の親子関係は、早く宣言の行なえる通信ポートから順に決定される。又、各ノード間において、子であることを宣言した通信ポートは「親ポート」であると認識され、その宣言を受けた通信ポートは「子ポート（子ノードと接続された通信ポート）」であると認識される。例えば、図１４において、ノードＡ、Ｅ、Ｆは、自分がリーフであると認識した後、親子関係の宣言を行う。これにより、ノードＡ−Ｂ間では子−親、ノードＥ−Ｄ間では子−親、ノードＦ−Ｄ間では子−親と決定される。
【００８５】
又、ステップＳ１６０２の処理の結果、接続ポートの数が２つ以上の場合、そのノードは、自分を「ブランチ」であると認識する（ステップＳ１６０５）。ここで、ブランチとは、２つ以上のノードと接続されているノードのことである。
【００８６】
ブランチとなるノードは、各接続ポートのノードから親子関係の宣言を受け付ける（ステップＳ１６０６）。宣言を受け付けた接続ポートは、「子ポート」として認識される。
【００８７】
１つの接続ポートを「子ポート」と認識した後、ブランチは、まだ親子関係の決定されていない接続ポート（即ち、未定義ポート）が２つ以上あるか否かを検出する（ステップＳ１６０７）。その結果、未定義ポートが２つ以上ある場合、ブランチは、再びステップＳ１６０６の動作を行う。
【００８８】
ステップＳ１６０７の結果、未定義ポートが１つだけ存在する場合、ブランチは、その未定義ポートが「親ポート」であると認識し、そのポートに接続されているノードに対して「自分は子」であることを宣言する（ステップＳ１６０８、Ｓ１６０９）。
【００８９】
ここで、ブランチは、残りの未定義ポートが１つになるまで自分自身が子であると他のノードに対して宣言することができない。例えば、図１４において、ノードＢ、Ｃ、Ｄは、自分がブランチであると認識すると共に、リーフ或いは他のブランチからの宣言を受け付ける。ノードＤは、Ｄ−Ｅ間、Ｄ−Ｆ間の親子関係が決定した後、ノードＣに対して親子関係の宣言を行っている。又、ノードＤからの宣言を受けたノードＣは、ノードＢに対して親子関係の宣言を行っている。
【００９０】
又、ステップＳ１６０８の処理の結果、未定義ポートが存在しない場合（つまり、ブランチの具備する全ての接続ポートが親ポートとなった場合）、そのブランチは、自分自身がルートであることを認識する。（ステップＳ１６１０）。
【００９１】
例えば、図１４において、接続ポートの全てが親ポートとなったノードＢは、１３９４ネットワーク上の通信を調停するルートとして他のノードに認識される。ここで、ノードＢがルートと決定されたが、ノードＢの親子関係を宣言するタイミングが、ノードＣの宣言するタイミングに比べて早い場合には、他のノードがルートになる可能性もある。即ち、宣言するタイミングによっては、どのノードもルートとなる可能性がある。従って、同じネットワーク構成であっても同じノードがルートになるとは限らない。
【００９２】
このように全ての接続ポートの親子関係が宣言されることによって、各ノードは、１３９４ネットワークの接続構成を階層構造（ツリー構造）として認識することができる（ステップＳ１６１１）。尚、上述の親ノードは階層構造における上位であり、子ノードは階層構造における下位となる。
【００９３】
（８）ノードＩＤの割り当て
図１７は、図１５に示したステップＳ１５０５の処理（即ち、自動的に各ノードのノードＩＤを割り当てる処理）を詳細に説明するフローチャートである。ここで、ノードＩＤは、バス番号とノード番号とから構成されるが、本実施例では、各ノードを同一バス上に接続するものとし、各ノードには同一のバス番号が割り当てられるものとする。
【００９４】
図１７において、ルートは、ノードＩＤが未設定のノードが接続されている子ポートの内、最小番号を有する通信ポートに対してノードＩＤの設定許可を与える（ステップＳ１７０１）。
【００９５】
尚、図１７において、ルートは、最小番号の子ポートに接続されている全ノードのノードＩＤを設定した後、その子ポートを設定済とし、次に最小となる子ポートに対して同様の制御を行なう。最終的に子ポートに接続された全てのノードのＩＤ設定が終了した後、ルート自身のノードＩＤを設定する。尚、ノードＩＤに含まれるノード番号は、基本的にリーフ、ブランチの順に０、１、２…と割り当てられる。従って、ルートが最も大きなノード番号を有することになる。
【００９６】
ステップＳ１７０１において、設定許可を得たノードは、自分の子ポートの内、ノードＩＤが未設定となるノードを含む子ポートがあるか否かを判断する（ステップＳ１７０２）。
【００９７】
ステップＳ１７０２において、未設定ノードを含む子ポートが検出された場合、上述の設定許可を得たノードは、その子ポートに直接接続されたノードに対してその設定許可を与えるように制御する（ステップＳ１７０３）。
【００９８】
ステップＳ１７０３の処理後、上述の設定許可を得たノードは、自分の子ポートの内、ノードＩＤが未設定であるノードを含む子ポートがあるか否かを判断する（ステップＳ１７０４）。ここで、ステップＳ１７０４の処理後、未設定ノードを含む子ポートの存在が検出された場合、そのノードは、再びステップＳ１７０３の処理を実行する。
【００９９】
又、ステップＳ１７０２或いはＳ１７０４において、未設定ノードを含む子ポートが検出されなかった場合、設定許可を得たノードは、自分自身のノードＩＤを設定する（ステップＳ１７０５）。
【０１００】
自分のノードＩＤを設定したノードは、自己のノード番号、通信ポートの接続状態に関する情報等を含んだセルフＩＤパケットをブロードキャストする（ステップＳ１７０６）。尚、ブロードキャストとは、あるノードの通信パケットを、１３９４ネットワークを構成する不特定多数のノードに対して転送することである。
【０１０１】
ここで、各ノードは、このセルフＩＤパケットを受信することにより、各ノードに割り当てられたノート番号を認識することができ、自分に割り当てられるノード番号を知ることができる。例えば、図１４において、ルートであるノードＢは、最小ポート番号「＃１」の通信ポートに接続されたノードＡに対してノードＩＤ設定の許可を与える。ノードＡは、自己のノード番号「Ｎｏ．０」と割り当て、自分自身に対してバス番号とノード番号とからなるノードＩＤを設定する。又、ノードＡは、そのノード番号を含むセルフＩＤパケットをブロードキャストする。
【０１０２】
図１８にセルフＩＤパケットの構成例を示す。図１８において、１８０１はセルフＩＤパケットを送出したノードのノード番号を格納するフィールド、１８０２は対応可能な転送速度に関する情報を格納するフィールド、１８０３はバス管理機能（バスマネージャの能力の有無等）の有無を示すフィールド、１８０４は電力の消費及び供給の特性に関する情報を格納するフィールドである。
【０１０３】
又、図１８において、１８０５はポート番号「＃０」となる通信ポートの接続状態に関する情報（接続、未接続、通信ポートの親子関係等）を格納するフィールド、１８０６はポート番号「＃１」となる通信ポートの接続状態に関する情報（接続、未接続、通信ポートの親子関係等）を格納するフィールド、１８０７はポート番号「＃２」となる通信ポートの接続状態に関する情報（接続、未接続、通信ポートの親子関係等）を格納するフィールドである。
【０１０４】
尚、セルフＩＤパケットを送出するノードにバスマネージャとなり得る能力がある場合には、フィールド１８０３に示すコンテンダビットを「１」とし、なり得る能力がなければ、コンテンダビットを０とする。
【０１０５】
ここで、バスマネージャとは、上述のセルフＩＤパケットに含まれる各種の情報に基づいて、バスの電源管理（通信ケーブルを介して電源の供給が可能か否か、電源の供給が必要か否か等の情報を各ノード毎に管理する）、速度情報の管理（各ノードの対応可能な転送速度に関する情報から各ノード間の最大転送速度を管理する）、トポロジ・マップ情報の管理（通信ポートの親子関係情報からネットワークの接続構成を管理する）、トポロジ・マップ情報に基づくバスの最適化等を行ない、それらの情報を他のノードに提供する機能を有するノードである。これらの機能により、バスマネージャとなるノードは１３９４ネットワーク全体のバス管理を行なうことができる。
【０１０６】
ステップＳ１７０６の処理後、ノードＩＤの設定を行ったノードは、親ノードがあるか否かを判断する（ステップＳ１７０７）。親ノードがある場合、その親ノードが、ステップＳ１７０２以下の処理を再び実行する。そして、まだノードＩＤの設定されていないノードに対して許可を与える。
【０１０７】
又、親ノードが存在しない場合、そのノードは、ルート自身であると判断される。ルートは、全ての子ポートに接続されたノードに対してノードＩＤが設定されたか否かを判別する（ステップＳ１７０８）。
【０１０８】
ステップＳ１７０８において、全てのノードに対するＩＤ設定処理が終了しなかった場合、ルートは、そのノードを含む子ポートの内、最小番号となる子ポートに対してＩＤ設定の許可を与える（ステップＳ１７０１）。その後、ステップＳ１７０２以下の処理を実行する。
【０１０９】
又、全てのノードに対するＩＤ設定処理が終了した場合、ルートは、自分自身のノードＩＤの設定を実行する（ステップＳ１７０９）。ノードＩＤの設定後、ルートは、セルフＩＤパケットをブロードキャストする（ステップＳ１７１０）。
【０１１０】
以上の処理によって、１３９４ネットワークは、各ノードに対して自動的にノードＩＤを割り当てることができる。
【０１１１】
ここで、ノードＩＤの設定処理後、複数のノードがバスマネージャの能力を具備する場合、ノード番号の最も大きいノードがバスマネージャとなる。つまり、ネットワーク内で最大となるノード番号を持つルートがバスマネージャになり得る機能を有している場合には、ルートがバスマネージャとなる。
【０１１２】
しかしながら、ルートにその機能が備わっていない場合には、ルートの次に大きいノード番号を具備するノードがバスマネージャとなる。又、どのノードがバスマネージャになったかについては、各ノードがブロードキャストするセルフＩＤパケット内のコンテンダビット１８０３をチェックすることにより把握することができる。
【０１１３】
（９）アービトレーション
図１９は、図１の１３９４ネットワークにおけるアービトレーションを説明する図である。
【０１１４】
１３９４ネットワークでは、データ転送に先立って、必ずバス使用権のアービトレーション（調停）を行なう。１３９４ネットワークは、論理的なバス型ネットワークであり、各ノードから転送された通信パケットを他のノードに中継することによって、ネットワーク内の全てのノードに同じ通信パケットを転送することのできる。従って、通信パケットの衝突を防ぐために、必ずアービトレーションが必要となる。これによって、ある時間において一つのノードのみが転送を行なうことができる。
【０１１５】
図１９（ａ）は、ノードＢとノードＦとが、バス使用権の要求を発している場合について説明する図である。
【０１１６】
アービトレーションが始まるとノードＢ、Ｆは、夫々親ノードに向かって、バス使用権の要求を発する。ノードＢの要求を受けた親ノード（即ち、ノードＣ）は、自分の親ノード（即ち、ノードＤ）に向かって、そのバス使用権を中継する。この要求は、最終的に調停を行なうルート（ノードＤ）に届けられる。
【０１１７】
バス使用要求を受けたルートは、どのノードにバスを使用させるかを決める。この調停作業はルートとなるノードのみが行なえるものであり、調停によって勝ったノードにはバスの使用許可が与えられる。
【０１１８】
図１９（ｂ）は、ノードＦの要求が許可され、ノードＢの要求が拒否されたことを示す図である。
【０１１９】
アービトレーションに負けたノードに対してルートは、ＤＰ（Data prefix）パケットを送り、拒否されたことを知らせる。拒否されたノードは、次回のアービトレーションまでバス使用要求を待機する。
【０１２０】
以上のようにアービトレーションを制御することによって、１３９４ネットワークは、バスの使用権を管理することができる。
【０１２１】
（１０）通信サイクル
Isochronous転送モードとAsynchronous転送モードとは、各通信サイクル期間内において時分割に混在させることができる。ここで、通信サイクルの期間は、通常、１２５μＳである。
【０１２２】
図２０は、１通信サイクルにおいてIsochronous転送モードとAsynchronous転送モードとを混在させた場合を説明する図である。
【０１２３】
Isochronous転送モードは、Asynchronous転送モードより優先して実行される。その理由は、サイクル・スタート・パケットの後、Asynchronous転送を起動するために必要なアイドル期間（subaction gap）が、Isochronous転送を起動するため必要なアイドル期間（Isochronous gap）よりも長くなるように設定されているためである。これにより、Isochronous転送は、Asynchronous転送に優先して実行される。
【０１２４】
図２０において、各通信サイクルのスタート時には、サイクル・スタート・パケット（以下、ＣＳＰ）が所定のノードから転送される。各ノードは、このＣＳＰを用いて時刻調整を行うことによって、他のノードと同じ時間を計時することができる。
【０１２５】
（１１）Isochronous転送モード
Isochronous転送モードは、同期型の転送方式である。Isochronousモード転送は、通信サイクルの開始後、所定の期間において実行可能である。又、Isochronous転送モードは、リアルタイム転送を維持するために、各サイクル毎に必ず実行される。
【０１２６】
Isochronous転送モードは、特に動画像データや音声データ等のリアルタイムな転送を必要とするデータの転送に適した転送モードである。Isochronous転送モードは、Asynchronous転送モードのように１対１の通信ではなく、ブロードキャスト通信である。つまり、あるノードから送出されたパケットは、ネットワーク上の全てのノードに対して一様に転送される。尚、Isochronous転送には、ack（受信確認用返信コード）は存在しない。
【０１２７】
図２０において、チャネルｅ（ch e）、チャネルｓ（ch s）、チャネルｋ（ch k）は、各ノードがIsochronous転送を行う期間を示す。１３９４インタフェースでは、複数の異なるIsochronous転送を区別するために、夫々異なるチャネル番号を与えている。これにより、複数ノード間でのIsochronous転送が可能となる。ここで、このチャネル番号は、送信先を特定するものではなく、データに対する論理的な番号を与えているに過ぎない。
【０１２８】
又、図２０に示したIsochronous gapとは、バスのアイドル状態を示すものである。このアイドル状態が一定時間を経過した後、Isochronous転送を希望するノードは、バスが使用できると判断し、アービトレーションを実行する。
【０１２９】
次に、図２１にIsochronous転送モードに基づいて転送される通信パケットのフォーマットを示す。以下、Isochronous転送モードに基づいて転送される通信パケットを、Isochronousパケットと称する。
【０１３０】
図２１において、Isochronousパケットはヘッダ部２１０１、ヘッダＣＲＣ２１０２、データ部２１０３、データＣＲＣ２１０４から構成される。
【０１３１】
ヘッダ部２１０１には、データ部２１０３のデータ長を格納するフィールド２１０５、Isochronousパケットのフォーマット情報を格納するフィールド２１０６、Isochronousパケットのチャネル番号を格納するフィールド２１０７、パケットのフォーマット及び実行しなければならない処理を識別するトランザクションコード（tcode）を格納するフィールド２１０８、同期化コードを格納するフィールド２１０９がある。
【０１３２】
（１２）Asynchronous転送モード
Asynchronous転送モードは、非同期型の転送方式である。Asynchronous転送は、Isochronous転送期間の終了後、次の通信サイクルが開始されるまでの間（即ち、次の通信サイクルのＣＳＰが転送されるまでの間）、実行可能である。
【０１３３】
図２０において、最初のサブアクション・ギャップ（subaction gap）は、バスのアイドル状態を示すものである。このアイドル時間が一定値になった後、Asynchronous転送を希望するノードは、バスが使用できると判断し、アービトレーションを実行する。
【０１３４】
アービトレーションによりバスの使用権を得たノードは、図２２に示すパケットを所定のノードに対して転送する。このパケットを受信したノードは、ack（受信確認用返送コード）或いは応答パケットをack gap後に返送する。
【０１３５】
図２２は、Asynchronous転送モードに基づく通信パケットのフォーマットを示す図である。以下、Asynchronous転送モードに基づいて転送される通信パケットを、Asynchronousパケットと称する。
【０１３６】
図２２において、Asynchronousパケットは、ヘッダ部２２０１、ヘッダＣＲＣ２２０２、データ部２２０３、データＣＲＣ２２０４から構成される。
【０１３７】
ヘッダ部２２０１において、フィールド２２０５には宛先となるノードのノードＩＤ、フィールド２２０６にはソースとなるノードのノードＩＤ、フィールド２２０７には一連のトランザクションを示すためのラベル、フィールド２２０８には再送ステータスを示すコード、フィールド２２０９にはパケットのフォーマット及び実行しなければならない処理を識別するトランザクションコード（tcode）、フィールド２２１０には優先順位、フィールド２２１１には宛先のメモリ・アドレス、フィールド２２１２にはデータ部のデータ長、フィールド２２１３には拡張されたトランザクション・コードが格納される。
【０１３８】
又、Asynchronous転送は、自己ノードから相手ノードへの１対１の通信である。転送元ノードから転送されたパケットは、ネットワーク中の各ノードに行き渡るが、自分宛てのアドレス以外のものは無視される。従って、宛先となるノードのみが、そのパケットを読み込むことができる。
【０１３９】
尚、Asynchronous転送中に次のＣＳＰを転送すべき時間に至った場合、無理に転送を中断せず、その転送が終了した後、次のＣＳＰを送信する。これにより、１つの通信サイクルが１２５μＳ以上続いたときは、その分、次の通信サイクル期間を短縮する。このようにすることによって、１３９４ネットワークは、ほぼ一定の通信サイクルを保持することができる。
【０１４０】
（１３）デバイス・マップ
デバイスマップを作成するためにアプリケーションが１３９４ネットワークのトポロジーを知る手段として、ＩＥＥＥ１３９４規格上は以下の手段がある。
１．バスマネージャーのトポロジーマップレジスターをリードする
２．バスリセット時にセルフＩＤパケットから推定する
しかし上記１、２の手段では、各ノードの親子関係によるケーブル接続順のトポロジーは判明するものの、物理的な位置関係のトポロジーを知ることは出来ない。(実装されていないポートまで見えてしまう、といった問題もある)
また、デバイスマップを作成するための情報を、コンフィギュレーションＲＯＭ以外のデータベースとして持つ、といった手段もあるが、その場合、各種情報を得る手段はデータベースアクセスのためのプロトコルに依存してしまう。
【０１４１】
ところで、コンフィギュレーションＲＯＭ自体やコンフィギュレーションＲＯＭを読む機能は、ＩＥＥＥ１３９４規格を遵守したデバイスが必ず持つものである。そこで、デバイスの位置、機能等の情報を各ノードのコンフィギュレーションＲＯＭに格納し、それらをアプリケーションから読む機能を与えることにより、データベースアクセス、データ転送等の特定のプロトコルに依存することなく、各ノードのアプリケーションがいわゆるデバイスマップ表示機能を実装することができる。
【０１４２】
コンフィグレーションＲＯＭにはノード固有の情報として物理的な位置、機能などが格納可能であり、デバイスマップ表示機能の実現に使用することが可能である。
【０１４３】
この場合、アプリケーションが物理的な位置関係による１３９４ネットワークトポロジーを知る手段としては、バスリセット時やユーザーからの要求時に、各ノードのコンフィギュレーションＲＯＭを読み取ることにより、１３９４ネットワークのトポロジーを知る、という方法が可能となる。さらに、コンフィギュレーションＲＯＭ内にノードの物理的位置のみならず、機能などの各種ノード情報も記述することによって、コンフィギュレーションＲＯＭを読むことで、ノードの物理的位置と同時に各ノードの機能情報等も得ることができる。アプリケーションが各ノードのコンフィギュレーションＲＯＭ情報を取得する際には、指定ノードの任意のコンフィギュレーションＲＯＭ情報を取得するＡＰＩを用いる。
【０１４４】
このような手段を用いることにより、ＩＥＥＥ１３９４ネットワーク上のデバイスのアプリケーションは、物理的なトポロジーマップ、各ノードの機能マップなど、用途に応じて様々なデバイスマップを作成することができ、ユーザーが必要な機能をもつデバイスを選択する、といったことも可能となる。
【０１４５】
〈SBP-2の概要〉
SBP-2（Serial Bus Protocol２）は、NCITS傘下のTechnical Committee T10のプロジェクトとして1996より標準化の審議が進められ、1998年にANSI NCITS 325-1998として標準化が認可された、IEEE1394バスに依存したプロトコルで有る。レイヤとしては、IEEE1394-1995のトランザクション層の上位に位置するコマンド／データトランスポートプロトコルで有る。当初SBP-2は、IEEE1394 上のデバイスをSCSIコマンドを用いて動作させる事を可能にする事を主な目的として開発されたが、SCSIコマンドに限らず他のコマンドを載せる事も出来る。SBP-2の特長を挙げると以下の通りになる。
【０１４６】
（１）イニシエータ（Initiator）/ターゲット（Target）構成のマスタスレーブモデルで有り、マスタで有るイニシエータがログイン、ログアウト、タスク管理、コマンド発行等の全ての権限と責任を持つ。
【０１４７】
（２）バスモデルとしてのIEEE1394の特長を生かした共有メモリモデルで有る（コマンド等のターゲットへの要求内容は、基本的には全てシステムメモリ内に置かれ、要求を受けたターゲットがシステムメモリの内容を読みに行く。又は、システムメモリへ要求されたステータス等の情報をを書きこむ）。
【０１４８】
即ち、通信の為のリソースを一箇所に集中出来るので、リソースの負担を非常に軽く出来、かつターゲットが自分のペースでシステムメモリへ読み書き出来るので、ターゲットの設計の自由度が高く、システムメモリのアクセスをハードウエア化することにより高速化が容易である（高性能にも、徹底した低コストモデルにも出来る）。
【０１４９】
（３）メッセージ交換の為のコマンド群を一連のリンクリストとして記述する仕組みが有る為、レイテンシによる効率低下を隠蔽できるため、IEEE1394バスの特長を生かした高速で、効率の高いデータ通信を実現できる。
【０１５０】
（４）コマンドセットインデペンデントな構造である（様々なコマンドセットに対応可能）。
【０１５１】
SBP-2はマスタで有るイニシエータが全ての権限と責任を持つマスタ−スレーブモデルで有り、全てはイニシエータからの動作をきっかけにして行われる。イニシエータからのログイン、ログアウト要求やタスク管理要求、コマンド等は、ORB(Operation Request Block)と呼ぶデータ構造に内包された形でターゲットに送られる。（正しくは、イニシエータが自メモリに置き、ターゲットがそれを読み出す）。図２３に、主なORBの種類を示す。
【０１５２】
（１）ダミーORB：ターゲットフェッチエージェントのイニシャライズ時、タスクのキャンセル等に使用する。ターゲットにはno operation（無処理命令）として扱われる
（２）コマンドブロックORB：データ転送コマンド、デバイス制御コマンド等のコマンドを内包するORBで有る。対応するデータバッファ又はページテーブルのアドレス及びサイズを示すdata_descriptor, data_sizeフィールドを有する。次のコマンドブロックORBのアドレスを示すnext_ORBフィールドを有するので、コマンドをリンク出来るのが特長である（図２４参照の事）。
【０１５３】
（３）管理ORB：マネージメント要求（ログイン、ログアウトを含むアクセス要求、及びタスクマネージメント要求）を内包するORBである。タスク管理の要求内容（タスクセット中断, ターゲットリセット等）を示すファンクションフィールドと、ターゲットからの完了ステータスのアドレスを示すステータスFIFOのフィールドを有するのが特長である（図２５参照の事）。
【０１５４】
この内、管理ORB については、ターゲットが応答を返すまでイニシエータは次のORBを発行する事は出来ないが、Dummy ORBを含むコマンド Block ORBは、図２６の様にリンクされたリストの形で一連のコマンド列として発行する事が出来る。即ちコマンドブロックORBには図２の様にnext_ORBフィールドとして次のORBのアドレスを指示するフィールドが有る為、次々とコマンドを連結する事が出来る。このフィールドがnullの場合は、次に続くORBが無いことを示す。
【０１５５】
また、このコマンドブロックORBの他のフィールドにはデータバッファ又はページテーブルのアドレス及びサイズを示すフィールド(data_descriptor及びdata_size)が有り、例えばコマンドの内容がライト（write）コマンドならばターゲットはdata_descriptorで示されたシステムメモリ上のData_Bufferにアクセスし、そこから書き込むべきデータを読みこむ。また、コマンドの内容がリード（Read）コマンドならばターゲットはdata_descriptorで示されたシステムメモリ上のData_Bufferにアクセスし、そこへコマンドの要求するデータを書きこむ。
【０１５６】
図２７及び図２８に、データバッファを直接示す場合と、ページテーブルを経由する場合を示す。ページテーブルにより、物理的に不連続な領域のデータバッファを、連続的に扱う事が出来、仮想記憶による連続論理領域を物理的に再配置する必要がなくなる訳である。
【０１５７】
イニシエータからの様々な要求を実行するターゲット側の仕組みを、エージェントと称する。エージェントには、管理ORBを実行する管理エージェントと、コマンドブロックORBを実行するコマンドブロックエージェントが有る。
【０１５８】
管理エージェントには、管理ORBのアドレスをイニシエータがターゲットに知らせる為にストアする、管理エージェントレジスタrが有る。
【０１５９】
コマンドブロックエージェントは、イニシエータのコマンドのリンクされたリストからコマンドをフェッチして来る為、フェッチエージェントとも呼ばれる。フェッチエージェントにも、コマンドブロックORBの先頭アドレスをイニシエータがストアするORBポインタレジスタと、イニシエータがターゲットにコマンドをフェッチして貰いたい事を知らせるドアベルレジスタ等を含む、コマンドブロックエージェントレジスタが有る。
【０１６０】
ターゲットはイニシエータからのORBの実行を完了すると、その実行完了のステータスを、ステータスブロックと言うデータ構造の形で（完了の成否に拘らず）イニシエータのステータスFIFOの示すアドレスにストアする。ステータスブロックの例を、図２９に示す。
【０１６１】
ターゲットは最低８バイト、最大32バイトのステータス情報をストアする事が出来る。管理ORBの場合は、図２５のステータスFIFOフィールドにORBの一部として明示的にステータスFIFOアドレスが提供されるので、ターゲットは指定されたアドレスにステータスブロックをストアする。それ以外の場合は、フェッチエージェントのコンテクストから得られるステータスFIFOにステータスブロックをストアする。コマンドブロックORBの場合は、イニシエータはステータスFIFOアドレスをログイン要求の一部として提供する。
【０１６２】
通常ターゲットは、イニシエータの発するORBに対してステータスFIFOアドレスにステータスブロックを書き込む事によって応答するが、デバイス側に変化が発生し、ロジカルユニットに影響する場合は、イニシエータからの要求が無くても自発的にアンソリシテッドステータスを返すことも出来る。この場合のステータスFIFOアドレスは、イニシエータからのログイン要求の際にイニシエータから提供されるステータスFIFOアドレスで有る。
【０１６３】
SBP-2におけるイニシエータとターゲットの動作を、図３０の動作モデルを用いて説明する。
【０１６４】
SBP-2の動作は、イニシエータが、ターゲットに対してログイン要求の為の管理ORB（ログインORB）を発行する事から始まる。ターゲットは、イニシエータからの要求に対してログイン応答で応える（図３０参照の事）。ログイン要求が受け入れられると、ターゲットからはログイン応答としてコマンドブロックエージェントレジスタの先頭アドレスが返って来る。
【０１６５】
ログイン要求が受け入れられると、ターゲットの管理エージェントは、イニシエータからのその後のタスク管理要求を受け付ける。イニシエータはタスク管理ORBを発行して、タスクの実行に必要な情報のやり取りをターゲットとの間で行う。ターゲットはイニシエータの発するORBに対してステータスFIFOにステータスブロックを書き込む事によって応答するが、デバイス側に変化が発生し、ロジカルユニットに影響する場合は、イニシエータからの要求が無くても自主的にアンソリシテッドステータスを返すことも出来る事は前述の通りである。タスク管理に関するやり取りに続いて、イニシエータは必要なコマンドブロックORB（リスト）を自分のメモリ領域に形成し、ターゲットのコマンドブロックエージェントレジスタのORBポインタに前記ORBの先頭アドレスを書きこみか又はコマンドブロックエージェントレジスタのドアベルレジスタを叩いて、ターゲットに対して通信すべきORBがイニシエータに有ることを知らせる（図３１）。ターゲットは、上記ORBポインタに書かれた前記ORBの先頭アドレス情報をもとにイニシエータのメモリにアクセスし、ORBを順次処理する（図３２）。
【０１６６】
ところで、タスクの実行モデルには、順序モデル（Ordered Model）と非順序モデル（Unordered Model）が有る。順序モデルでは、ORBはリストの順番に沿って行われ、ターゲットの完了ステータスも順番に返って来る。非順序モデルでは、ORBの実行順位に制約は無いが、どの順序でも最終的に同じ実行結果が得られる様にイニシエータが責任を持たなければならない。イニシエータからターゲットへのデータ転送はターゲットからシステムメモリへのリードトランザクションによって行われ、一方ターゲットからイニシエータへのデータ転送は、システムメモリへのライトトランザクションによって行われる。即ちデータバッファの転送は方向によらずターゲットが主導する。逆に言えば、ターゲットは自分に都合の良いペースでシステムメモリからのデータを読み出すことが出来る訳で有る。イニシエータはターゲットがORBを実行中でも、Listの最後のORBのnext_addressを次のORBのアドレスに書き換え、ターゲットのドアベルレジスタを再び叩いてターゲットに変更を知らせる事により、リンクされたリストにORBを追加する事が出来る。ターゲットは、イニシエータのステータスFIFOのアドレスに完了ステータス（ステータスブロック）を返す。イニシエータは完了ステータス（ステータスブロック）が返されたのを見て、その対象ORBのターゲットによる実行が完了した事を知る。完了したORBは、(next_ORBフィールドがnullでなければ)タスクセットのリンクされたリストから外す事が出来、イニシエータはその空いたリソースを利用して、必要なら次のコマンドをコマンドがリンクされたリストの最後に追加しても良い。このようにしてORBが実行されタスクが実行される。
【０１６７】
タスクが終了し、アクセスをつづける必要が無い場合は、イニシエータはログアウトORBを発行し、ターゲットが応えてログアウトが完了する。
【０１６８】
〈SBP-3の双方向データ転送機能〉
SBP-3（Serial Bus Protocol3）は、SBP-2を拡張し機能を追加することによりSBP-2において効率が悪かった点、欠いていた機能を補充する目的で2000年後半から規格化作業が行なわれている。
【０１６９】
SBP-3において拡張された代表的な機能を挙げると以下の通りになる。
1. アイソクロナス（Isochronous）データ転送機能
2. デバイスハンドルによるイニシエータ／ターゲットの特定によるノードID非依存機能
3. １つのＯＲＢ内の双方向データ転送機能
ここでは上記機能のうち第３番目の機能について説明する。
【０１７０】
SBP-3はSBP-2と下位互換性を持っており、その基本的なデータ転送シーケンスはSBP-2の概要で説明した通りである。すなわち、イニシエータからターゲットへのデータ転送はターゲットからシステムメモリへのリードトランザクションによって行われ、一方ターゲットからイニシエータへのデータ転送は、システムメモリへのライトトランザクションによって行われる。ターゲットは自分に都合の良いペースでORBを読み出し、ORBの内容をデコードすることによって転送動作の種別情報を知る。ターゲットはORBに対応する転送動作がイニシエータからターゲットへのデータ転送か、ターゲットからイニシエータへのデータ転送なのか、そしてその転送動作が、イニシエータ内のどのシステムメモリ領域に対して行なわれるかをデコードし、該当する転送動作を行なう。またターゲットはそのORBで指定された転送動作を完了した際には、イニシエータのステータスFIFOのアドレスに完了ステータス（ステータスブロック）を返す。
【０１７１】
SBP-3ではコマンドブロックORB、すなわちデータ転送コマンドや、デバイス制御コマンド等のコマンドを内包するORBとして２種類定義している。ひとつはコマンドブロックORBが有するリクエストフォーマットフィールドの値が０のものであり、SBP-2で定義されたコマンドブロックORBと同一のものである。〈SBP-2の概要〉の欄で説明したように、ORBが参照するデータバッファ又はページテーブルのアドレス及びサイズを示すdata _descriptor, data_size_field、次のコマンドブロックORBのアドレスを示すnext_ORBフィールド、そしてデータバッファに対するデータ転送方向を示すdirectionフィールドに代表されるデータ転送に関わるパラメータを指定するフィールドからなる。
【０１７２】
SBP-3で新規に定義されたコマンドブロックORB はリクエストフォーマットフィールドの値が１となっており従来のORBと区別がつけられる。
【０１７３】
このORBの特徴はひとつのＯＲＢから２つのデータバッファが参照されるということである。データバッファ又はページテーブルのアドレス及びサイズを示すdata_descriptor, data_sizeフィールド、directionフィールド等データバッファに関するフィールドがそれぞれ２組用意され、
これによりＯＲＢから２つのデータバッファの参照が可能となる。
【０１７４】
このＯＲＢを使用し、一つのデータバッファはターゲットへのライト用、もう一方のデータバッファはターゲットからのリード用バッファとして使うことにより双方向ＯＲＢとして活用することが出来る。
【０１７５】
イニシエータは必要なコマンドブロックORB（リスト）を自分のメモリ領域に形成し、上記のように双方向ＯＲＢをアペンドしてターゲットのコマンドブロックエージェントレジスタ のORBポインタに前記ORB（リスト）の先頭アドレスを書きこみか又はコマンドブロックエージェントレジスタのドアベルレジスタを叩いて、ターゲットに対して通信すべきORBがイニシエータに有ることを知らせる。ターゲットは、上記ORBポインタに書かれた前記ORBの先頭アドレス情報をもとにイニシエータのメモリにアクセスし、ORBをフェッチ、順次処理する。
【０１７６】
双方向ＯＲＢをフェッチしたターゲットは指定された２つのデータバッファそれぞれに対してデータ転送処理を行なう。片側のバッファに対応するdirectionフィールドは0となっていて、ターゲットはdata_descriptorで示されたシステムメモリ上のデータバッファにアクセスし、そこから書き込むべきデータを読みこむ。またもう片方ののバッファに対応するdirectionフィールドは1となっていてターゲットはdata_descriptorで示されたシステムメモリ上のデータバッファにアクセスし、そこへコマンドの要求するデータを書きこむ。
【０１７７】
両方のデータバッファアクセスが完了するとターゲットはイニシエータのステータスFIFOのアドレスに完了ステータス（ステータスブロック）を返し、そのＯＲＢの実行完了を通知する。
【０１７８】
図３３にSBP-3でのコマンドブロックORBの動作を示している、図３２で示したSBP-2と比較すると、SBP-3では1つのORBに対してデータバッファアクセスを示す線が2本になっており、SBP-2が1つのデータバッファへのアクセスしか出来なかった点が変更されている。2つのデータバッファに独立してアクセスできることにより、イニシエータからターゲットへの2つのデータチャネルを1つのORBに当てはめることが出来る。データバッファへのデータの流れる方向はそれぞれのデータバッファで規定できるため、イニシエータからターゲットへの方向を2本、イニシエータからターゲットへの方向を１本ターゲットからイニシエータへの方向を１本、ターゲットからイニシエータへの方向を２本設定することが可能になる。ホストとプリンタで使うような場合、1本をホストからプリンタへの印字データのために使い、もう1本をプリンタからホストへのステータス情報を流すために使うことも可能となる。
【０１７９】
図３４にSBP-3の2つのデータバッファを保持する場合のコマンドブロックORBの詳細を示している。2組のデータバッファを扱えるようにするために、2つのdata_descritorとバッファ情報"d"〜"data_size"とがSBP-2に対して拡張されている。図中"d"で示したdirectionでそれぞれのデータバッファの方向を指定することが出来る。内容はSBP-2と同様で0であればイニシエータからターゲット、1であればターゲットからイニシエータへの方向を示している。
【０１８０】
〈本実施形態の説明〉
以下本発明の実施形態に関して詳細に説明する。
【０１８１】
図３５に、SBP-2,SBP-3で使用されるステータスブロックに対して、本発明に係るSBP-3の改良版であるSBP-3改で使われるステータスブロックを示す。SBP-2,SBP-3と基本的には同じ構成となっていて、3番目のクアドレット（quadlet：４バイト分のデータ）に"a","b0","b1"の各フラグを配置した部分の追加がされている。"a","b0","b1"はそれぞれ対応するデータバッファの表していて、"b0"は図３４で示した1番目のdata_descriptorに対応しており、"b1"は２番目のdata_descriptorに対応している。"a"はこれら2つのデータバッファ両方を同時に対応することを意味する。"a","b0","b1"はそれぞれ0,1の値が指定され、1の場合に対応するバッファの完了を示し、0であれば対応するバッファの未完了を示す。"a"に1が指定された場合、2つのバッファが同時に完了したことを示す。"a","b0","b1"3つのの指定の組み合わせにより、1つ目のバッファの完了、2つ目のバッファの完了、１，２両方のバッファの完了を個別あるいは同時に通知することが出来る。
【０１８２】
図３６にSBP-3改でのコマンドブロックORBの動作を示している、ステータスFIFOに対するアクセスが複数回（この場合2回）行われることが示されている。図３３のSBP-3の動作ではステータスFIFOへのアクセスは1度だけ行われている。図３６で行われるステータスFIFOへのアクセスは図３５に示したステータスブロックで行われ、"a","b0","b1"のいずれかのビットに1が設定される。例えば、2つ目のバッファに対する処理が完了した場合、1度目のステータスブロックへのアクセスでは、"b1"が1、"b0"に0がセットされ、1つ目のバッファの処理が完了した場合、２度目のステータスブロックへのアクセスでは、"b1"が0、"b0"に1がセットされる。それぞれのバッファに対して、個別にステータスブロックへのアクセスが行われる。"b0","b1"共に完了が通知されれば、処理していたORBが完了全てのコマンド完了が通知されたことになる。
【０１８３】
また、SBP-3と同じ動作を実現するためには"a"に1を設定することで2つのバッファの終了を1回のステータスブロックへのアクセスで行うことも出来る。
【０１８４】
SBP-3では、2つのデータバッファに対する処理が両方共に終了した時点で、ステータスFIFOにアクセスしORBの完了を通知する。このような動作のため、一方のデータバッファの終了を先に通知することが出来なかった。これをホストとプリンタの関係に当てはめて考えた場合、いつのデータバッファを印字データ、もう1つをステータスのために使うとすると、プリンタが印字データのデータバッファを全て受け取るまで、ホストに対してステータスを戻せないことが発生する。ステータス情報を随時受け取りことができないことになる。SBP-3改ではデータバッファごとに独立してステータスFIFOを戻せるように改造しているため、印字データとは独立してステータスを戻すことも可能となる。
【０１８５】
以上説明した、SBP-3改のプロトコルを用いたコマンドセットの一例について説明する。コマンドセットはプロトコル上でターゲットデバイスを制御するためのコマンドで、本実施形態では、ターゲットデバイスとして印字装置（プリンタ）を想定したコマンドとする。
【０１８６】
図３７にその詳細な構成を示す。これは図３４のcommand_blockの部分を詳細に記述した図で、１つのORBで２つのコマンドを扱えるようにするために、同じ形式をしたコマンド１，コマンド２（図３７）を規定している。符号３７１２ａで示した部分に対応するコマンドがコマンド１（Command1）であり、符号３７０２で示した部分に対応するコマンドがコマンド２（Command2）である。各コマンドはOpcode３７１１，Datalength_hi３７１２，Datalength_lo３７１３，Count３７１４，Interval３７１５から構成されている。
【０１８７】
Opcode３７１１は実行されるコマンドの種類を表し、図３７の例では、WRITE，STATUSが定義されている。WRITEはプリンタへの印字データの書き込みを実行するコマンドで、イニシエータからターゲットであるプリンタ方向へのデータが流れることを示す。STATUSは、プリンタのステータス情報を取得するコマンドで、ステータス情報はターゲットのプリンタからイニシエータ方向へのデータが流れることを示す。イニシエータは印刷処理を行う際、印字データをプリンタへ送るコマンドを実行するのと同時に定期的にプリンタのステータス情報を取得する。イニシエータは取得したステータス情報からプリンタの状態をユーザに通知する作業を行う。これによりユーザはプリンタにエラー等が発生したことを知ることが出来る。
【０１８８】
Datalength_hi３７１２，Datalength_lo３７１３はイニシエータからターゲット（プリンタ）、あるいはターゲット（プリンタ）からイニシエータへの書き込みされたデータの量を示す。Count３７１４は、コマンドが実行される回数を指定する値で、１以上の値を取る。ただし、−１は無限の継続を意味する。Interval３７１５は、Count３７１４で指定された回数分のコマンドを実行する実行時間間隔を指定する値である。１以上の値をとり、本実施形態では１が1ms(ミリ秒)の単位を示すものとする、−１の値がInterval３７１５に指定された場合Interval３７１５の指定は行われないことを示す。このCount３７１４とInterval３７１５は２つの値の組み合わせによりいろいろなコマンドの実行条件を規定する。
【０１８９】
また、この時間間隔内でコマンドが完了しない場合には、タイムアウトと判定される。そのため、Count,Intervalは、コマンドが一定時間（Count * Interval）実行できないような場合のタイムアウト時間として使うことも出来る。例えばCount=1,Interval=1000を指定したような場合、コマンドの実行は１回のみで、1000msの時間が経過してもコマンドが実行されない場合、タイムアウトとなりその内容がイニシエータにステータスブロックで知らされることになる。またIntervalに−１が指定された場合にはコマンドがタイムアウトしない指定となる。
【０１９０】
図３８にこのコマンドセットでのステータスブロックの詳細を示し、図３５に示したSBP-3改でのステータスブロックに対して、コマンドセットに依存する部分を規定するものである。コマンドに対するステータスブロックは、元の形式にステータスが追加されている。STATUSフィールド３８０１はコマンドの完了状況を示し、本実施形態では完了（COMPLETE），タイムアウト（TIMEOUT）の２種類を定義する。COMPLETEはコマンドが正常に終了したことを示し、TIMEOUTはコマンドに指定されたCount,Intervalの条件によりコマンドの実行がタイムアウトしてコマンドの実行が行われなかったことを示す。
【０１９１】
図３９は、イニシエーターとプリンタでの印字データとステータス情報の流れとステータスブロックへの書き込みを示した図で、ここではイニシエータは１つのORBの場合を示していて、ORBには印字データを保持するバッファ1とステータス情報を受け取るためのバッファ2を有している。ORBのコマンド実行に際してプリンタは、バッファ1から印字データを受け取り、ステータスバッファ2にプリンタのステータス情報を書き込み、ステータスブロックにそれぞれの完了を書き込むことで１つのORBに対する２つのコマンドの実行が完了したこととなる。この場合のコマンド内容を示したのが図４０である。
【０１９２】
図４０において、コマンド１については、data_descriptorにはバッファ1のアドレスがセットされ、方向を示すdにはイニシエータからプリンタの方向を示す0がセットされる。コマンドのopcodeには印字データの書き込みコマンドであるWRITEコマンドが指定され、Count=1,Interval=3000が指定されている。これはWRITEコマンドが１回実行されること、実行できない場合3000msでタイムアウトすることを指定している。
【０１９３】
コマンド２に対してはdata_descriptorにはバッファ2のアドレスがセットされ、方向を示すdにはプリンタからイニシエータの方向を示す1がセットされる。コマンドのopcodeにはステータス情報の書き込みコマンドであるSTATUSコマンドが指定され、Count=-1,Interval=1000が指定されている。これはコマンド２がステータス情報の取得コマンドであるSTATUSの実行で、Count=-1,Interval=1000が指定されている。これがSTATUSコマンドが、1000msの時間間隔で、無限に実行されることを意味している。図４０に示したコマンドORBで、WRITE,STATUSの２つのコマンドの実行が指示されたことになる。
【０１９４】
このコマンドが問題なく実行された場合にプリンタか書き込むステータスブロックの例を図４１に示す。１回のステータスブロックで完了を示すために、フラグa（図３８）のところに1がセットされ、Status３８０１にCOMPLETEが指定されている。このステータスブロックの書き込み終了後、バッファ2にセットされている内容が最新のステータス情報になり、この情報を用いてユーザーに印字の状況を知らせることが出来る。
【０１９５】
図４０，４１で示したようにコマンドが２つとも同時に実行可能である場合には、特別に問題は発生しない。しかし実際のプリンタではこのように２つのコマンドを同時に実行することが出来ない場合が存在する。プリンタの種類、構成内容により異なるが、例えばインクジェットプリンタの場合では、印字データを受信できない時間帯（給紙、排紙中、回復動作中など）がある。それらが発生した場合、印字動作が一時的に中断されるため、すでに受け取っている印字データがあるために印字のためのバッファが一杯となり、次からの印字データを受け取ることが出来ない状態となる。一般的にそのような状態でもステータスのコマンドは実行できる場合が多い。ちょうどこの時に出されたコマンドは、本実施形態で示した、Count,Intervalの指定がないものであれば、プリンタが印字データを受信できるようになるまで、コマンドの実行は待たされたままとなる。
【０１９６】
図４２に、このようなプリンタが印字データを受信できない状態、すなわちターゲットがイニシエータからデータを読むことができない状態で、図４０に示したコマンドを実行した場合のステータスブロックに書き込まれる内容を示している。図４２（a）に示すように、STATUSコマンドに対するステータスブロックの書き込みは、印字データ受け取れない状況でもステータス情報を書き込むことが出来るので、正常に行われてCOMPLETEが書き込まれる。STATUSコマンドはIntervalに1000msが指定されていて、実行回数Countは-1で無限が指定されているので、1000ms間隔で新しいステータス情報の書き込みを実行してステータスブロックに図４２(a)でCOMPLETEの書き込みが行われる。
【０１９７】
一方WRITEコマンドはIntervalに3000msが指定されているので、この3000msの間にプリンタの印字データを受け取れない状態が解消されればステータスブロックにCOMPLETEで書き込むことが出来るが、3000msの間に解消されない場合には、図４２(b)で示した、TIMEOUTでステータスブロックの書き込みが行われる。この場合、WRITEのコマンドは正しく実行されずTIMEOUTとなってしまったので、イニシエーターは印字を止めてしまうか、同じデータでリトライを実行する必要がある。イニシエーターはステータスブロックでTIMEOUTを知ることが出来、以降どうのように継続するかどうかを決めることが可能となる。WRITEコマンドがプリンタの印字データを受け取れないことで、実行できない状態でいる間でも、もう１つのコマンド（STATUSコマンド）は指定された一定間隔で実行することが出来るので、最新のステータス情報がこの時でも受け取ることが出来る。
【０１９８】
またタイムアウトの時間を指定できるので、印字の実行を中止するような場合にも有効に利用することが出来る。
【０１９９】
＜本実施形態における処理手順の概略＞
図４３乃至図４６に、上記説明したイニシエータおよびターゲットにおける処理の概略フローチャートを示す。
【０２００】
図４３は、図１のクラスドライバ１０２におけるコマンド発行時の処理手順である。クラスドライバ１０２は、プリンタドライバ１０１から、ＰＤＬコマンドリスト等をデータとしてターゲットのプリンタへ発行する依頼を受けた際の処理手順である。プリンタドライバ１０１は、例えばデータや前述したコマンドの実行回数、時間間隔等、コマンド等をパラメータとして、クラスドライバ１０２が提供する関数を呼び出す。もちろん、コマンドは２つまで指定できる。また、コマンドに従属する実行回数や時間間隔、データ長等のパラメータは、コマンドごとに指定される。なお、コマンドは１つであっても良いことは既に説明したとおりである。
【０２０１】
クラスドライバ１０２は、コマンドからコマンドブロックを作成し（ステップＳ４３０１）、指定されたパラメータとともにＳＢＰ−３のプロセッサ１１１（図１）に渡す（ステップＳ４３０２）。プロセッサ１１１は、引き渡されたパラメータに従ったアドレスやデータ長をdata_descripterやdata_sizeフィールドに記述し、コマンドの種類に基づいて方向フィールドｄ等を記述して、図３７に示すＯＲＢを作成する。そして、作成したＯＲＢをＯＲＢリストにチェインする。
【０２０２】
チェインされたＯＲＢは、Ordered Modelであれば順次、Unordered Modelであれば、適切な順序で処理されていく。
【０２０３】
ターゲット１ｂへは、ドアベルレジスタ１２１へ書き込みを行うことでＯＲＢ処理のきっかけを与える。ターゲットのコマンドブロックエージェント１２２は、イニシエータ１ａにチェインされたＯＲＢのうち先頭のＯＲＢのアドレスをＯＲＢポインタ１２４にコピーして実行エージェント１２３へとＯＲＢの受信を通知する。
【０２０４】
図４４は、実行エージェント１２３におけるＯＲＢ処理手順のフローチャートである。
【０２０５】
ステップＳ４４０１において、ＯＲＢポインタ１２４で示されるＯＲＢのリクエストフォーマットフィールドをテストして、それが１であれば、コマンドが２つ含まれたＯＲＢであると判定する。このＯＲＢのことを以下の説明では単に２コマンドＯＲＢと呼ぶことにする。２コマンドＯＲＢでなければ通常のＳＢＰ−３（あるいはＳＢＰ−２）処理手順を遂行する。
【０２０６】
２コマンドＯＲＢであれば、ステップＳ４４０２においてそのうちの一方に注目し、ステップＳ４４０３において方向ビットｄを判定する。方向ビットがイニシエータからターゲットへであれば、イニシエータからターゲットへのデータの引き渡しなので、ステップＳ４４０４において、ＯＲＢのコマンド部およびバッファのアドレス（data_descripter）やサイズ（data_size）にしたがってデータを読み出し、コマンド処理部１０３に渡す。
【０２０７】
一方、方向ビットｄがターゲットからイニシエータへであれば、ターゲットからイニシエータへのデータの引き渡しであるので、ＯＲＢのコマンド部とデータを書き込むべきバッファ領域のアドレス（data_descripter）およびサイズ（data_size）をコマンド処理部１０３に渡す。
【０２０８】
ステップＳ４４０６では、注目ＯＲＢ中の２つのコマンドについて処理が終えたか判定し、終えていなければステップＳ４４０２に戻る。
【０２０９】
図４５は、図４４のステップＳ４４０４またはＳ４４０５において引き渡されたデータを処理するコマンド処理部１０３における処理手順を示す。
【０２１０】
まずステップＳ４５０１においてコマンドを解析し、ステップＳ４５０２においてコマンドの内容に応じた処理を行う。例えばライトコマンドであれば、実行エージェントから受け取ったバッファの内容を、ＰＤＬ処理部１０４に引き渡す。また、ステータスコマンドであれば、ステータスを読み取り（あるいはＰＤＬ処理部により読み取らせて）、それをクラスドライバ１０２に応答する。この処理は後述する。
【０２１１】
次にステップＳ４５０３で、コマンドのIntervalフィールドで指定された時間間隔に従って、応答監視タイマを設定する。そして、処理の応答（成功あるいは失敗あるいはタイムアウトなど）を待つ。そして、応答待ち状態となる。この状態は、ターゲットの処理系次第であり、たとえばいったんタスク終了したりあるいは係属するなど、いくつかの処理の選択肢をとり得る。ただし、いったんタスクを終了すると応答を非同期に処理する必要があるので、コマンド処理とその応答とを対応付けるための識別子等を、コマンドごとに管理する必要がある。
【０２１２】
応答が返るとまずステップＳ４５０４でその内容を判定する。ただし、タイムアウトの場合には、タイマ満了の割り込みによりそれを知ることになると考えられるので、判別すべきはどのコマンドに対するタイムアウトであるか、という点となる。
【０２１３】
さて、応答内容が処理の成功であれば、ステップＳ４５０４において「成功」である旨示すステータスブロックの内容を用意する。一方、タイムアウトであれば、「タイムアウト」であることを示すステータスブロックの内容をステップＳ４５０５で用意する。他のステータスがあれば、ステータスに応じた内容が用意されることはもちろんである。
【０２１４】
そして用意したステータスブロックの内容を、ステップＳ４５０７で実行エージェント１２３へと渡す。実行エージェント１２３は、イニシエータに用意されているアンソリシテッドレジスタを叩き（書き込み）、ステータスブロックがあることをイニシエータに通知する。
【０２１５】
最後に、ステップＳ４５０８で、コマンドのCountフィールドで指定される実行回数の繰返しが終了したか判定し、終了していなければステップＳ４５０２から繰り返す。もちろん残りの繰返し回数は１回減算しておき、次回はその値がステップＳ４５０８でテストされる。
【０２１６】
図４６は、ステータスブロックを受信したイニシエータにおけるプロセッサ１１１による処理手順である。
【０２１７】
まずステップＳ４６００で、受信したステータスブロックがアンソリシテッドステータスであるか、すなわち、対応するＯＲＢがＯＲＢリストにチェインされているか判定する。アンソリシテッドステータスであれば、そのステータスブロックに含まれるあるいは添付されたバッファの内容をクラスドライバ１０２に渡して、処理をゆだねる。
【０２１８】
一方、アンソリシテッドステータスでなければ、ステップＳ４６０１でクラスドライバ１０２へ終了の通知（成功あるいはタイムアウトなど）を行う。そして、ステップＳ４６０３において対応ＯＲＢが２コマンドＯＲＢであるか判定する。
【０２１９】
２コマンドＯＲＢであれば、ステップＳ４６０３において２つのコマンドに対するステータスブロックを受信しているか判定する。この判定は、ＯＲＢに関連づけてコマンド１およびコマンド２に対するステータスブロックの受信の履歴を記録しておくことで可能となる。
【０２２０】
全コマンドについてステータスブロックを受信していれば、ステップＳ４６０５において対応ＯＲＢをＯＲＢリストから削除する。一方、片方のコマンドについてのステータスブロックのみを受信した場合には、ステップＳ４６０４においてその旨を記録し、処理を終了する。
【０２２１】
以上の手順により、１つのＯＲＢに２つのコマンドを載せ、各コマンドについて指定された回数だけ指定された時間間隔で実行させることができる。あるいは、各コマンドについてタイムアウトの時間を設定することができる。
【０２２２】
さらに、２コマンドＯＲＢは、２つのコマンドについてステータスブロックを受信するまで削除されないので、イニシエータからターゲットへのデータの受け渡しを確実に行え、また、イニシエータの送信待機タイマがタイムアウトした場合であっても、再送信することが可能である。そしていったんデータ（コマンド）がターゲットにわたれば、ターゲットからのステータスは、アンソリシテッドステータスとして処理されるために、ＯＲＢリストがはけずに処理が遅滞する事態が生じることもない。
【０２２３】
また、SBP-3プロトコルでは２つのコマンドが１つのORBで実行できるようになったがコマンドごとに完了を確認する手段がなく、その点を改良したSBP-3改ではコマンドごとに完了の通知を受けることができるようになった。さらに、本実施形態においては、完了の条件をコマンド単位で指定することが出来るようになり、コマンドの内容やデバイスの構成により発生していた片方のコマンドが実行できない状況でも、他方のコマンドを期待どうりに有効に実行することが出来る。
【０２２４】
なお、上記手順において、２つのコマンドに対する応答を１つのステータスブロックで返す場合は、たとえば、２つのコマンドに対する応答がほぼ同時に得られることが期待できる場合が考えられる。たとえばコマンドが一致し、かつ、実行回数(Count)および時間間隔(Interval)が２つのコマンドについて一致する場合などに、適用できる。
【０２２５】
＜プリンタシステムのハードウエア構成＞
最後に、イニシエータであるホスト装置５１（図１の１ａに相当）とターゲットであるプリンタ５２（図１の１ｂに相当）のハードウェア構成について説明する。図４７は情報処理システムを構成するホスト装置５１とプリンタ５２のハードウェア構成概要を示すブロック図である。
【０２２６】
図２に示されているように、ホスト装置５１は処理部１０００とこれに周辺装置を含めてホスト装置全体を構成している。また、画像出力装置５２は、記録ヘッド３０１０、記録ヘッド３０１０を搬送するキャリアを駆動するキャリア（ＣＲ）モータ３０１１、用紙を搬送する搬送モータ３０１２などの駆動部と、制御回路部３００３とから構成されている。
【０２２７】
ホスト装置５１の処理部１０００は、制御プログラムに従ってホスト装置の全体制御を司るＭＰＵ１００１、システム構成要素を互いに接続するバス１００２、ＭＰＵ１００１が実行するプログラムやデータ等を一時記憶するＤＲＡＭ１００３、システムバスとメモリバス、ＭＰＵ１００１を接続するブリッジ１００４、例えば、ＣＲＴなどの表示装置２００１にグラフィック情報を表示するための制御機能を備えたグラフィックアダプタ１００５を含んでいる。
【０２２８】
さらに、処理部１０００はＨＤＤ装置２００２とのインタフェースを司るＨＤＤコントローラ１００６、キーボード２００３とのインタフェースを司るキーボードコントローラ１００７、ＩＥＥＥ１３９４規格に従ってプリンタ５２との間の通信を司る、ＩＥＥＥ１３９４である通信Ｉ／Ｆ１００８を備えている。
【０２２９】
さらに、処理部１０００には、グラフィックアダプタ１００５を介して操作者にグラフィック情報等を表示する表示装置２００１（この例では、ＣＲＴ）が接続されている。更に、プログラムやデータが格納された大容量記憶装置であるハードディスクドライブ（ＨＤＤ）装置２００２、キーボード２００３が夫々、コントローラを介して接続されている。
【０２３０】
一方、プリンタ５２の制御回路部３００３は、制御プログラム実行機能と周辺装置制御機能とを兼ね備えた、プリンタ５２の全体制御を司るＭＣＵ３００１、制御回路部内部の各構成要素を接続するシステムバス３００２、記録データの記録ヘッド３０１０への供給、メモリアドレスデコーディング、キャリアモータへの制御パルス発生機構等を制御回路として内部に納めたゲートアレイ（Ｇ．Ａ．）を備えている。
【０２３１】
また、制御回路部３００３は、ＭＣＵ３００１が実行する制御プログラムやホスト印刷情報等を格納するＲＯＭ３００４、各種データ（画像記録情報やヘッドに供給される記録データ等）を保存するＤＲＡＭ３００５、ＩＥＥＥ１３９４規格に従いホスト装置５１との間の通信を司るシリアルインタフェースである通信Ｉ／Ｆ３００６、ゲートアレイ３００３から出力されたヘッド記録信号に基づき、記録ヘッド３０１０を駆動する電気信号に変換するヘッドドライバ３００７を備えている。
【０２３２】
さらに、制御回路部３００３は、ゲートアレイ３００３から出力されるキャリアモータ制御パルスを実際にキャリア（ＣＲ）モータ３０１１を駆動する電気信号に変換するＣＲモータドライバ３００８、ＭＣＵ３００１から出力された搬送モータ制御パルスを、実際に搬送モータを駆動する電気信号に変換するＬＦモータドライバ３００９を備えている。
【０２３３】
＜他の実施形態＞
以上説明した実施形態によれば、本発明は次のようなものとして把握できる。
【０２３４】
（１）一次側装置において、１つのコマンドブロックに複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てて二次側装置に引き渡し、二次側装置において、コマンドブロックに含まれる複数のコマンドを独立してあるいは非同期に実行する通信システムであって、
前記一次側装置は、各コマンドに対応する条件を当該コマンドが割り当てられたコマンドブロックに記述し、
前記二次側装置は、各コマンドを、それぞれに対応する条件に応じて実行する。
【０２３５】
（２）（１）において、前記条件は、コマンドの実行回数と実行間隔を含むことを特徴とする請求項１に記載の通信システム。
【０２３６】
（３）（１）または（２）において、前記二次側装置は、各コマンドの実行が終了する都度、独立して前記一次側装置に対して実行結果を応答する。
【０２３７】
（４）（３）において、前記一次側装置は、前記二次側装置に引き渡すコマンドブロックのリストを保持し、前記二次側装置から、１つのコマンドブロックに含まれる全コマンドについて実行結果の応答を受けた場合に、当該コマンドブロックを前記リストから削除する。
【０２３８】
（５）（１）乃至（４）において、前記一次側装置は前記コマンドブロックおよびデータバッファを格納するための記憶部を備え、前記二次側装置は、前記一時側装置の備える記憶部にアクセスすることでデータを交換する。
【０２３９】
（６）（１）乃至（５）において、前記一次側装置はホストコンピュータであり、前記二次側装置はプリンタであって、前記ホストコンピュータは、前記データバッファに印刷コマンドを書き込んで前記プリンタに引き渡し、前記プリンタは、引き渡された印刷コマンドに従って印刷処理を遂行する。
【０２４０】
（７）１つのコマンドブロックに複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てて二次側装置に引き渡す通信装置であって、
各コマンドに対応する条件を当該コマンドが割り当てられたコマンドブロックに記述し、前記二次側装置に前記コマンドブロックを引き渡す。
【０２４１】
（８）（７）において、前記条件は、コマンドの実行回数と実行間隔を含む。
【０２４２】
（９）（８）において、前記二次側装置に引き渡すコマンドブロックのリストを保持し、前記二次側装置から、１つのコマンドブロックに含まれる全コマンドについて実行結果の応答を受けた場合に、当該コマンドブロックを前記リストから削除する。
【０２４３】
（１０）（７）乃至（９）において、前記コマンドブロックおよびデータバッファを格納するための記憶部を備え、前記二次側装置から前記記憶部にアクセスすることで前記二次側装置とデータを交換する。
【０２４４】
（１１）（７）乃至（１０）において、前記二次側装置はプリンタであって、前記データバッファに印刷コマンドを書き込んで前記プリンタに引き渡す。
【０２４５】
（１２）一次側装置から、複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てられたコマンドブロックを読む通信装置であって、
前記コマンドブロックからコマンドおよびその条件を読み、各コマンドを、それぞれに対応する条件に応じて実行する。
【０２４６】
（１３）（１２）において、前記条件は、コマンドの実行回数と実行間隔を含む。
【０２４７】
（１４）（１２）または（１３）において、各コマンドの実行が終了する都度、独立して前記一次側装置に対して実行結果を応答する。
【０２４８】
（１５）（１２）乃至（１４）において、前記一次側装置は前記コマンドブロックおよびデータバッファを格納するための記憶部を備え、前記一時側装置の備える記憶部にアクセスすることでデータを交換する。
【０２４９】
（１６）（１２）乃至（１５）を用いたプリンタであって、前記一次側装置はホストコンピュータであり、前記ホストコンピュータは、前記データバッファに印刷コマンドを書き込んで引き渡された印刷コマンドに従って印刷処理を遂行する。
【０２５０】
（１７）また、（７）乃至（１１）または（１２）乃至（１５）の機能を、コンピュータにより実現するためのプログラムも本発明に含まれる。
【０２５１】
【発明の効果】
上記説明したように、本発明によれば、複数のコマンドを含むコマンドブロックを二次側装置で処理させる場合に、実行の条件をコマンド単位で指定することが出来るようになり、コマンドの内容やデバイスの構成により発生していた片方のコマンドが実行できない状況でも、他方のコマンドを期待どうりに有効に実行することが出来る。
【図面の簡単な説明】
【図１】本発明のホスト・プリンタ通信システムの構成を示した図である。
【図２】１３９４シリアルバスのネットワークの構成を示した図である。
【図３】本発明の１３９４シリアルバスの構成要素を示した図である。
【図４】本発明の１３９４シリアルバスのリンク・レイヤ提供可能なサービスを示す図である。
【図５】本発明の１３９４シリアルバスのトランズアクション・レイヤ提供可能なサービスを示す図である。
【図６】１３９４インタフェースにおけるアドレス空間を説明する図である
【図７】１３９４インタフェースにおけるＣＳＲコア・レジスタに格納される情報のアドレス及び機能を示す図である。
【図８】１３９４インタフェースにおけるシリアルバス・レジスタに格納される情報のアドレス及び機能を示す図である。
【図９】１３９４インタフェースにおける最小形式のConfiguration ROMを示す図である。
【図１０】１３９４インタフェースにおける一般形式のConfiguration ROMを示す図である。
【図１１】１３９４インタフェースにおけるシリアルバス装置レジスタに格納される情報のアドレス及び機能を示す図である。
【図１２】ＩＥＥＥ１３９４規格に準拠した通信ケーブルの断面図である。
【図１３】DS-Link符号化方式を説明する図である。
【図１４】、
【図１５】、
【図１６】バスリセットの開始からノードＩＤの割り当て処理までの基本的なシーケンスを示した図である。。
【図１７】図１５に示したステップＳ１５０５の処理（即ち、自動的に各ノードのノードＩＤを割り当てる処理）を詳細に説明するフローチャートである。
【図１８】１３９４インターフェースにおけるセルフＩＤパケットの構成を示した図である。
【図１９】１３９４ネットワークにおけるアービトレーションを説明する図である。
【図２０】１通信サイクルにおいてIsochronous転送モードとAsynchronous転送モードとを混在させた場合を説明する図である。
【図２１】Isochronous転送モードに基づいて転送される通信パケットのフォーマットを示した図である。
【図２２】本発明のアシンクロナス転送のパケットフォーマットを示した図である。
【図２３】ＳＢＰ−２におけるＯＲＢ種別を示した図である。
【図２４】ＳＢＰ−２におけるコマンドブロックＯＲＢのフォーマットを示した図である。
【図２５】ＳＢＰ−２におけるマネージメントＯＲＢのフォーマットを示した図である。
【図２６】ＳＢＰ−２におけるコマンドブロックＯＲＢのリンクリストを示した図である。
【図２７】ＳＢＰ−２におけるデータバッファの直接アクセスを示した図である。
【図２８】ＳＢＰ−２におけるページテーブルの使用を示した図である。
【図２９】ＳＢＰ−２におけるステータスＦＩＦＯのフォーマットを示した図である。
【図３０】ＳＢＰ−２におけるログイン動作を示した図である。
【図３１】ＳＢＰ−２にタスク実行の最初の動作を示した図である。
【図３２】ＳＢＰ−２におけるコマンドＯＲＢの動作を示した図である。
【図３３】ＳＢＰ−３におけるコマンドＯＲＢの動作を示した図である。
【図３４】ＳＢＰ−３におけるコマンドブロックＯＲＢのフォーマットを示した図である。
【図３５】ＳＢＰ−３改におけるステータスＦＩＦＯのフォーマットを示した図である。
【図３６】ＳＢＰ−３改におけるコマンドＯＲＢの動作を示した図である。
【図３７】本実施形態におけるコマンドブロックＯＲＢのフォーマットを示した図である。
【図３８】本実施形態におけるステータスＦＩＦＯのフォーマットを示した図である。
【図３９】本実施形態におけるコマンドＯＲＢの動作を示した図である。
【図４０】本実施形態におけるコマンドブロックＯＲＢの具体例を示した図である。
【図４１】本実施形態における正常に終了したステータスＦＩＦＯの具体例を示した図である。
【図４２】本実施形態におけるタイムアウトしたステータスＦＩＦＯの具体例を示した図である。
【図４３】本実施形態におけるクラスドライバにおける処理手順の一例を示した図である。
【図４４】本実施形態における実行エージェントにおける処理手順の一例を示した図である。
【図４５】本実施形態におけるコマンド処理部における処理手順の一例を示した図である。
【図４６】本実施形態におけるイニシエータにおけるステータスブロック処理手順の一例を示した図である。
【図４７】本実施形態における印刷システムのハードウエアブロック図である。
Claims (13)
- 一次側装置において、１つのコマンドブロックに複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てて二次側装置に引き渡し、二次側装置において、コマンドブロックに含まれる複数のコマンドを独立して実行する通信システムであって、
前記一次側装置は、前記各データバッファに対応した複数のコマンドそれぞれに対して独立した条件を設定し、当該独立した条件がそれぞれ設定された複数のコマンドを含む１つのコマンドブロックを作成し、作成された前記１つのコマンドブロックを前記二次側装置に送信し、
前記二次側装置は、前記一次側装置から送信された前記１つのコマンドブロックを受信し、当該コマンドブロックに含まれる複数のコマンドを、それぞれのコマンドに設定されている条件に応じて実行する事を特徴とする通信システム。 - 前記条件は、コマンドの実行回数と実行間隔を含むことを特徴とする請求項１に記載の通信システム。
- 前記二次側装置は、各コマンドの実行が終了する都度、独立して前記一次側装置に対して実行結果を応答することを特徴とする請求項１或いは２に記載の通信システム。
- 前記一次側装置は、前記二次側装置に引き渡すコマンドブロックのリストを保持し、前記二次側装置から、１つのコマンドブロックに含まれる全コマンドについて実行結果の応答を受けた場合に、当該コマンドブロックを前記リストから削除することを特徴とする請求項１乃至３のいずれかに記載の通信システム。
- 前記一次側装置は前記データバッファにアクセスすることでデータを交換することを特徴とする請求項１乃至４のいずれかに記載の通信システム。
- 前記一次側装置はホストコンピュータであり、前記二次側装置はプリンタであって、前記ホストコンピュータは、前記データバッファに印刷コマンドを書き込んで前記プリンタに引き渡し、前記プリンタは、引き渡された印刷コマンドに従って印刷処理を遂行することを特徴とする請求項１乃至５のいずれかに記載の通信システム。
- 他の機器と通信可能な通信装置であって、
複数のデータ格納領域のそれぞれに対応する複数のコマンドと、当該複数のコマンドのそれぞれに対して設定された独立した条件とを含む１つのコマンドブロックを生成する生成手段と、
前記生成手段により生成された１つのコマンドブロックを他の機器に送信する送信手段とを有することを特徴とする通信装置。 - 前記条件は、コマンドの実行回数または実行間隔を含むことを特徴とする請求項７に記載の通信装置。
- コマンドブロックのリストを保持し、他の機器から、１つのコマンドブロックに含まれるコマンドに対する応答を受けた場合に、当該コマンドブロックを前記リストから削除することを特徴とする請求項７或いは８に記載の通信装置。
- 他の機器と通信可能な通信装置であって、
複数のデータ格納領域のそれぞれに対応する複数のコマンドと、当該複数のコマンドのそれぞれに対して独立に設定された条件とを含む１つのコマンドブロックを前記他の機器 から受信する受信手段と、
前記受信手段により受信された１つのコマンドブロックに含まれる前記複数のコマンドを、それぞれのコマンドに対して設定された条件に従って実行する実行手段とを有することを特徴とする通信装置。 - 前記条件は、コマンドの実行回数と実行間隔を含むことを特徴とする請求項１０に記載の通信装置。
- 前記データ通信手段は、前記受信手段により受信されたコマンドブロックに含まれる複数の条件のそれぞれに従って、データ格納領域にデータを書き込む、またはデータ格納領域からデータを読み出すことを特徴とする請求項１０或いは１１に記載の通信装置。
- 一次側装置において、１つのコマンドブロックに複数の独立したデータバッファと各データバッファに対応した複数のコマンドを割り当てて二次側装置に引き渡し、二次側装置において、コマンドブロックに含まれる複数のコマンドを独立して実行する通信システムの制御方法であって、
前記一次側装置が、前記各データバッファに対応した複数のコマンドそれぞれに対して独立した条件を設定し、当該独立した条件がそれぞれ設定された複数のコマンドを含む１つのコマンドブロックを作成し、作成された前記１つのコマンドブロックを前記二次側装置に送信し、
前記二次側装置が、前記一次側装置から送信された前記１つのコマンドブロックを受信し、当該コマンドブロックに含まれる複数のコマンドを、それぞれのコマンドに設定されている条件に応じて実行する事を特徴とする通信システムの制御方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002373106A JP4109983B2 (ja) | 2002-12-24 | 2002-12-24 | 通信システム |
| US10/654,025 US7346714B2 (en) | 2002-09-05 | 2003-09-04 | Notification of completion of communication with a plurality of data storage areas |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002373106A JP4109983B2 (ja) | 2002-12-24 | 2002-12-24 | 通信システム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004207908A JP2004207908A (ja) | 2004-07-22 |
| JP2004207908A5 JP2004207908A5 (ja) | 2005-12-22 |
| JP4109983B2 true JP4109983B2 (ja) | 2008-07-02 |
Family
ID=32811505
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002373106A Expired - Fee Related JP4109983B2 (ja) | 2002-09-05 | 2002-12-24 | 通信システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4109983B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008245046A (ja) | 2007-03-28 | 2008-10-09 | Brother Ind Ltd | 複合機、およびデバイス制御システム |
| JP4333765B2 (ja) | 2007-03-28 | 2009-09-16 | ブラザー工業株式会社 | デバイス制御システム |
-
2002
- 2002-12-24 JP JP2002373106A patent/JP4109983B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004207908A (ja) | 2004-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4035235B2 (ja) | 電子機器 | |
| EP1134937B1 (en) | Information signal processing apparatus, corresponding system, method and computer readable storage medium | |
| JP4027189B2 (ja) | 情報処理システム、情報処理装置、情報処理方法、プログラム及び記憶媒体 | |
| US6823408B2 (en) | Electronic equipment, and method for controlling state of physical layer circuit therefor | |
| US6963938B2 (en) | Information processing apparatus and method therefor | |
| JP2001119410A (ja) | 自己識別フェーズにおける処理方法 | |
| JP4424700B2 (ja) | 情報処理装置およびその制御方法 | |
| JP4109983B2 (ja) | 通信システム | |
| US7346714B2 (en) | Notification of completion of communication with a plurality of data storage areas | |
| JP2001274813A (ja) | 情報信号処理装置及び情報信号処理方法並びに記憶媒体 | |
| JP4095384B2 (ja) | 情報処理システム、情報処理装置、情報処理方法、プログラム及び記憶媒体 | |
| JP2003110651A (ja) | データ処理方法、データ処理装置、通信プロトコル及びプログラム | |
| JP2004064665A (ja) | データ転送装置及び送信装置及び受信装置及びそれらの制御方法 | |
| JP2004102443A (ja) | 情報処理システム、情報処理方法、プログラム及び記憶媒体 | |
| US7003604B2 (en) | Method of and apparatus for cancelling a pending AV/C notify command | |
| JP3943722B2 (ja) | データ転送装置、データ転送システムおよびその方法、画像処理装置、並びに、記録媒体 | |
| JP2005044078A (ja) | 通信方法、印刷装置及びホスト装置 | |
| JP2004179898A (ja) | 画像処理装置 | |
| EP1182827A2 (en) | Information control method, information processing apparatus, and information control system | |
| JP2009027349A (ja) | ネットワーク機器 | |
| JP2006134222A (ja) | 情報処理装置及び方法 | |
| JP2001144783A (ja) | シリアルバスブリッジ、端末装置、情報通信システム、情報通信方法並びに記憶媒体 | |
| JP2001160938A (ja) | 画像処理装置及び画像処理システム、及びその制御方法 | |
| JP2004179899A (ja) | 画像処理装置 | |
| JP2004192559A (ja) | 画像処理システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051028 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051028 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071203 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080107 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080307 |
|
| 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: 20080324 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080407 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110411 Year of fee payment: 3 |
|
| 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: 20130411 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130411 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140411 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |