JP3495878B2 - データ処理方法、データ処理装置及びプリンタ - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、シリアルバスを介
して、複数種類のプリンタのプロトコルの中からホスト
に対応したプロトコルに切り換えるためのデータ処理方
法、データ処理装置及びプリンタに関するものである。

【０００２】

【従来の技術】従来より、シリアルバスを介してプリン
タにデータを送出するシステムとして、様々な種類のシ
ステムが知られている。

【０００３】例えば、ＳＣＳＩ（Small Computer Syste
m Interface ）、セントロニクス等、一般に広く用いら
れるようになったデファクトスタンダードのインターフ
ェースを用いて、コンピュータからプリンタにデータを
出力する技術が知られている。

【０００４】

【発明が解決しようとする課題】しかしながら、シリア
ルバスを用いてプリンタデータを送出する従来のプリン
タプロトコルは、プリンタメーカ固有の１つに限られて
いた。したがって、拡張性に欠ける、という問題が生じ
ていた。特に、様々な種類の機器を接続するインターフ
ェース、例えば、ＩＥＥＥ１３９４のようなインターフ
ェースを用いて、プリントデータを出力する際には、か
かる拡張性に欠けるという問題点は解決すべき大きな課
題であった。

【０００５】そこで、本発明は、上記の欠点を除去する
ために成されたもので、システムバスを介してプリント
データを送出する際に、拡張性の高いデータ処理方法、
データ処理装置、プリンタ及び記憶媒体を提供すること
を目的とする。また、本発明は、ＩＥＥＥ１３９４規格
に好適なデータ処理方法、データ処理装置、プリンタ及
び記憶媒体を提供することを目的とする。また、本発明
は、コンピュータを介することなく、画像データ出力デ
バイスから直接プリンタを接続するのに好適なデータ処
理方法、データ処理装置、プリンタ及び記憶媒体を提供
することを目的とする。また、初期プロトコルに対応し
ないホストに対しても、プロトコルを適合させることが
できるデータ処理方法、データ処理装置、プリンタ及び
記憶媒体を提供することを目的とする。

【０００６】

【課題を解決するための手段】本発明に係るデータ処理
方法は、シリアルバスを介して複数種類のプロトコルで
通信が可能なプリンタのプロトコルを切り換えるための
データ処理方法であって、前記プリンタのプロトコルの
種類に係わらない初期プロトコルによる通信がホストか
らない場合、前記ホストの固有の識別子を取得する取得
ステップと、前記取得ステップで取得された識別子に基
づいてプロトコルを決定する決定ステップと、前記決定
ステップで決定されたプロトコルの設定を行うプロトコ
ル設定ステップとを有することを特徴とする。このと
き、前記シリアルバスは、ＩＥＥＥ１３９４規格に適合
したバス、またはＵＳＢ規格に適合したバスであっても
よい。また、前記初期プロトコルは、ＯＳＩモデルのデ
ータリンク層よりも上位の層で実行されるプロトコルで
あってもよい。また、前記初期プロトコルはログインプ
ロトコルであり、前記取得ステップでは、前記ログイン
プロトコルによるログインが前記ホストからない場合、
前記ホストの固有の識別子を取得してもよい。また、前
記取得ステップでは、前記初期プロトコルによる通信が
所定の時間ない場合、前記ホストの固有の識別子を取得
してもよい。本発明に係るデータ処理装置は、シリアル
バスを介して複数種類のプロトコルで通信が可能なプリ
ンタのプロトコルを切り換えるためのデータ処理装置で
あって、前記プリンタのプロトコルの種類に係わらない
初期プロトコルによる通信がホストからない場合、前記
ホストの固有の識別子を取得する取得手段と、前記取得
手段により取得された識別子に基づいてプロトコルを決
定する決定手段と、前記決定手段により決定されたプロ
トコルの設定を行うプロトコル設定手段とを有すること
を特徴とする。このとき、前記初期プロトコルは、ＯＳ
Ｉモデルのデータリンク層よりも上位の層で実行される
プロトコルであってもよい。また、前記初期プロトコル
はログインプロトコルであり、前記取得手段は、前記ロ
グインプロトコルによるログインが前記ホストからない
場合、前記ホストの固有の識別子を取得してもよい。ま
た、前記取得手段は、前記初期プロトコルによる通信が
所定の時間ない場合、前記ホストの固有の識別子を取得
してもよい。本発明に係るプリンタは、シリアルバスを
介して複数種類のプロトコルで通信が可能なプリンタで
あって、前記プリンタのプロトコルの種類に係わらない
初期プロトコルによる通信がホストからない場合、前記
ホストの固有の識別子を取得する取得手段と、前記取得
手段により取得された識別子に基づいてプロトコルを決
定する決定手段と、前記決定手段により決定されたプロ
トコルの設定を行うプロトコル設定手段とを有すること
を特徴とする。このとき、前記シリアルバスは、ＩＥＥ
Ｅ１３９４規格に適合したバス、またはＵＳＢ規格に適
合したバスであってもよい。また、前記初期プロトコル
は、ＯＳＩモデルのデータリンク層よりも上位の層で実
行されるプロトコルであってもよい。また、前記初期プ
ロトコルはログインプロトコルであり、前記取得手段
は、前記ログインプロトコルによるログインが前記ホス
トからない場合、前記ホストの固有の識別子を取得して
もよい。また、前記取得手段は、前記初期プロトコルに
よる通信が所定の時間ない場合、前記ホストの固有の識
別子を取得してもよい。

【０００７】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を用いて説明する。

【０００８】ここで、まず、以下に説明する第１及び第
２の実施の形態では、各機器間を接続するディジタルＩ
／Ｆとして、ＩＥＥＥ１３９４シリアルバスを用いてい
るため、ＩＥＥＥ１３９４シリアルバスについて、予め
説明する。

【０００９】民生用デジタルＶＣＲやＤＶＤプレーヤの
登場に伴なって、ビデオデータやオーディオデータなど
のリアルタイムで、かつ高情報量のデータ転送のサポー
トが必要になっている。こういったビデオデータやオー
ディオデータをリアルタイムで転送し、パソコン（Ｐ
Ｃ）に取り込んだり、またはその他のデジタル機器に転
送を行なうには、必要な転送機能を備えた高速データ転
送可能なインタフェースが必要になってくるものであ
り、そういった観点から開発されたインタフェースが、
ＩＥＥＥ１３９４−1995（High Performance Serial Bu
s ）（以下、単に１３９４シリアルバスとも言う）であ
る。

【００１０】図１に１３９４シリアルバスを用いて構成
されるネットワーク・システムの例を示す。

【００１１】このシステムは、機器Ａ，Ｂ，Ｃ，Ｄ，
Ｅ，Ｆ，Ｇ，Ｈを備えており、Ａ−Ｂ間、Ａ−Ｃ間、Ｂ
−Ｄ間、Ｄ−Ｅ間、Ｃ−Ｆ間、Ｃ−Ｇ間、及びＣ−Ｈ間
をそれぞれ１３９４シリアルバスのツイスト・ペア・ケ
ーブルで接続されている。この機器Ａ〜Ｈは、例えばパ
ソコン、デジタルＶＴＲ、ＤＶＤ、デジタルカメラ、ハ
ードディスク、モニタ、チューナー、モニター等であ
る。

【００１２】各機器間の接続方式は、ディジーチェーン
方式とノード分岐方式とを混在可能としたものであり、
自由度の高い接続が可能である。

【００１３】また、各機器は各自固有のＩＤを有し、そ
れぞれが認識し合うことによって１３９４シリアルバス
で接続された範囲において、１つのネットワークを構成
している。各デジタル機器間をそれぞれ１本の１３９４
シリアルバスケーブルで順次接続するだけで、それぞれ
の機器が中継の役割を行い、全体として１つのネットワ
ークを構成するものである。また、１３９４シリアルバ
ス、Ｐｌｕｇ＆Ｐｌａｙ機能でケーブルを機器に接続し
た時点で自動で機器の認識や接続状況などを認識する機
能を有している。

【００１４】また、図１に示したようなシステムにおい
て、ネットワークからある機器が削除されたり、または
新たに追加されたときなど、自動的にバスリセットを行
い、それまでのネットワーク構成をリセットしてから、
新たなネットワークの再構築を行なう。この機能によっ
て、その時々のネットワークの構成を常時設定、認識す
ることができる。

【００１５】またデータ転送速度は、１００／２００／
４００Ｍｂｐｓと備えており、上位の転送速度を持つ機
器が下位の転送速度をサポートし、互換をとるようにな
っている。

【００１６】データ転送モードとしては、コントロール
信号などの非同期データ（Ａｓｙｎｃｈｒｏｎｏｕｓデ
ータ：以下、Ａｓｙｎｃデータと言う）を転送するＡｓ
ｙｎｃｈｒｏｎｏｕｓ転送モードとリアルタイムなビデ
オデータやオーディオデータ等の同期データ（Ｉｓｏｃ
ｈｒｏｎｏｕｓデータ：以下、Ｉｓｏデータと言う）を
転送するＩｓｏｃｈｒｏｎｏｕｓ転送モードがある。こ
のＡｓｙｎｃデータとＩｓｏデータは各サイクル（通常
１サイクル１２５μS ）の中において、サイクル開始を
示すサイクル・スタート・パケット（ＣＳＰ）を転送し
た後、Ｉｓｏデータの転送をＡｓｙｎｃデータより優先
しつつサイクル内で混在して転送される。

【００１７】つぎに、図２に１３９４シリアルバスの構
成要素を示す。

【００１８】１３９４シリアルバスは全体としてレイヤ
（階層）構造で構成されている。図２に示したように、
１３９４シリアルバスのケーブルとコネクタが接続され
るコネクタポートがあり、その上にハードウェアとして
フィジカル・レイヤとリンク・レイヤを位置づけしてい
る。

【００１９】ハードウェア部は実質的なインターフェイ
スチップの部分であり、そのうちフィジカル・レイヤは
符号化やコネクタ関連の制御等を行い、リンク・レイヤ
はパケット転送やサイクルタイムの制御等を行なう。

【００２０】ファームウェア部のトランザクション・レ
イヤは、転送（トランザクション）すべきデータの管理
を行ない、Ｒｅａｄ、Ｗｒｉｔｅ、Ｌｏｃｋの命令を出
す。マネージメント・レイヤは、接続されている各機器
の接続状況や識別子（ＩＤ）の管理を行ない、ネットワ
ークの構成を管理する部分である。

【００２１】このハードウェアとファームウェアまでが
実質上の１３９４シリアルバスの構成である。

【００２２】またソフトウェア部のアプリケーション・
レイヤは使うソフトによって異なり、インタフェース上
にどのようにデータをのせるか規定する部分であり、プ
リンタやＡＶＣプロトコルなどが規定されている。

【００２３】以上が１３９４シリアルバスの構成であ
る。

【００２４】つぎに、図３に１３９４シリアルバスにお
けるアドレス空間の図を示す。

【００２５】１３９４シリアルバスに接続された各機器
（ノード）には必ず各ノード固有の、６４ビットアドレ
スを持たせておく。そしてこのアドレスをＲＯＭに格納
しておくことで、自分や相手のノードアドレスを常時認
識でき、相手を指定した通信も行なえる。

【００２６】１３９４シリアルバスのアドレッシング
は、ＩＥＥＥ１２１２規格に準じた方式であり、アドレ
ス設定は、最初の１０ｂｉｔがバスの番号の指定用に、
次の６ｂｉｔがノードID番号の指定用に使われる。残り
の４８ｂｉｔが機器に与えられたアドレス幅になり、そ
れぞれ固有のアドレス空間として使用できる。最後の２
８ｂｉｔは固有データの領域として、各機器の識別や使
用条件の指定の情報などを格納する。

【００２７】ＣＲＳアークテクチャでは、各ノードの機
能を表すためのＣｏｎｆｉｇｕｒａｔｉｏｎ ＲＯＭを
持っているが、このＲＯＭには、最小形式と一般形式が
あり、ｘＦＦＦＦＦ００００４００から配置される。こ
のようなＲＯＭが、図３中のＲＯＭに対応している。

【００２８】最小形式では、図４に示すように、ベンダ
ＩＤを表しているだけであり、このＩＤは、２４ビット
で表される全世界で固有の数値である。

【００２９】一般形式では、図５に示すような形式で、
ノードに関する情報を持っているが、この場合のベンダ
ＩＤは、ｒｏｏｔ＿ｄｉｒｅｃｔｏｒｙに持つことがで
きる。

【００３０】また、ｂｉｓ＿ｉｎｆ＿ｂｌｏｃｋとｒｏ
ｏｔ＿ｌｅａｆには、ベンダＩＤを含んだ６４ビットの
全世界で固有な装置番号を持っている。

【００３１】この装置番号は、バスリセットなどの再構
成後に継続してノードを認識するために使用する。

【００３２】図６は、ディジタルカメラのコンフィグレ
ーションＲＯＭの一例を示したものである。

【００３３】図６中のベンダＩＤは、ｎｏｄｅ＿ｖｅｎ
ｄｏｒ＿ｉｄ、ｃｈｉｐ＿ｉｄ＿ｈｉ、ｃｈｉｐ＿ｉｄ
＿ｌｏの６４ビットで表されている。

【００３４】以上が１３９４シリアルバスの技術の概要
である。

【００３５】つぎに、１３９４シリアルバスの特徴とい
える技術の部分を、より詳細に説明する。

【００３６】１３９４シリアルバスの電気的仕様につい
て説明する。

【００３７】図７に１３９４シリアルバス・ケーブルの
断面図を示す。

【００３８】１３９４シリアルバスでは接続ケーブル内
に６ピン、即ち２組のツイストペア信号線の他に、電源
ラインを設けている。これによって、電源を持たない機
器や、故障により電圧低下した機器等にも電力の供給が
可能になっている。

【００３９】電源線内を流れる電源の電圧は８〜４０
Ｖ、電流は最大電流ＤＣ１．５Ａと規定されている。

【００４０】なお、ＤＶケーブルと呼ばれる規格では電
源を省いた４ピンで構成されている。

【００４１】ＤＳ−Ｌｉｎｋ符号化について説明する。

【００４２】１３９４シリアルバスで採用されている、
データ転送フォーマットのＤＳ−Ｌｉｎｋ符号化方式を
説明するための図を図８に示す。

【００４３】１３９４シリアルバスでは、ＤＳ−Ｌｉｎ
ｋ（Data／Strobe Link ）符号化方式が採用されてい
る。このＤＳ−Ｌｉｎｋ符号化方式は、高速なシリアル
データ通信に適しており、その構成は、２本の信号線を
必要とする。より対線のうち１本に主となるデータを送
り、他方のより対線にはストローブ信号を送る構成にな
っている。受信側では、この通信されるデータと、スト
ローブとの排他的論理和をとることによってクロックを
再現する。

【００４４】このＤＳ−Ｌｉｎｋ符号化方式を用いるメ
リットとして、８／１０Ｂ変換に比べて転送効率が高い
こと、ＰＬＬ回路が不要となるのでコントローラＬＳＩ
の回路規模を小さくできること、更には、転送すべきデ
ータが無いときにアイドル状態であることを示す情報を
送る必要が無いので、各機器のトランシーバ回路をスリ
ープ状態にすることができることによって、消費電力の
低減が図れる、などが挙げられる。

【００４５】バスリセットのシーケンスについて説明す
る。

【００４６】１３９４シリアルバスでは、接続されてい
る各機器（ノード）にはノードＩＤが与えられ、ネット
ワーク構成として認識されている。

【００４７】このネットワーク構成に変化があったと
き、例えばノードの挿抜や電源のＯＮ／ＯＦＦなどによ
るノード数の増減などによって変化が生じて、新たなネ
ットワーク構成を認識する必要があるとき、変化を検知
した各ノードはバス上にバスリセット信号を送信して、
新たなネットワーク構成を認識するモードに入る。

【００４８】このときの変化の検知方法は、１３９４ポ
ート基盤上でのバイアス電圧の変化を検知することによ
って行われる。

【００４９】あるノードからバスリセット信号が伝達さ
れて、各ノードのフィジカルレイヤはこのバスリセット
信号を受けると同時にリンクレイヤにバスリセットの発
生を伝達し、かつ他のノードにバスリセット信号を伝達
する。最終的にすべてのノードがバスリセット信号を検
知した後、バスリセットが起動となる。

【００５０】バスリセットは、先に述べたようなケーブ
ル抜挿や、ネットワーク異常等によるハード検出による
起動と、プロトコルからのホスト制御などによってフィ
ジカルレイヤに直接命令を出すことによっても起動す
る。また、バスリセットが起動するとデータ転送は一時
中断され、この間のデータ転送は待たされ、終了後、新
しいネットワーク構成のもとで再開される。

【００５１】以上がバスリセットのシーケンスである。

【００５２】ノードＩＤ決定のシーケンスについて説明
する。

【００５３】バスリセットの後、各ノードは新しいネッ
トワーク構成を構築するために、各ノードにＩＤを与え
る動作に入る。このときの、バスリセットからノードＩ
Ｄ決定までの一般的なシーケンスを図９、１０、１１の
フローチャートを用いて説明する。

【００５４】図９のフローチャートは、バスリセットの
発生からノードＩＤが決定し、データ転送が行えるよう
になるまでの、一連のバスの作業を示してある。

【００５５】まず、ステップＳ１０１として、ネットワ
ーク内にバスリセットが発生することを常時監視してい
て、ここでノードの電源ＯＮ／ＯＦＦなどでバスリセッ
トが発生するとステップＳ１０２に移る。

【００５６】ステップＳ１０２では、ネットワークがリ
セットされた状態から、新たなネットワークの接続状況
を知るために、直接接続されている各ノード間において
親子関係の宣言がなされる。ステップＳ１０３として、
すべてのノード間で親子関係が決定すると、ステップＳ
１０４として一つのルートが決定する。すべてのノード
間で親子関係が決定するまで、ステップＳ１０２の親子
関係の宣言をおこない、またルートも決定されない。

【００５７】ステップＳ１０４でルートが決定される
と、次はステップＳ１０５として、各ノードにＩＤを与
えるノードＩＤの設定作業が行われる。所定のノード順
序で、ノードＩＤの設定が行われ、すべてのノードにＩ
Ｄが与えられるまで繰り返し設定作業が行われ、最終的
にステップＳ１０６としてすべてのノードにＩＤを設定
し終えたら、新しいネットワーク構成がすべてのノード
において認識されたので、ステップＳ１０７としてノー
ド間のデータ転送が行える状態となり、データ転送が開
始される。

【００５８】このステップＳ１０７の状態になると、再
びバスリセットが発生するのを監視するモードに入り、
バスリセットが発生したらステップＳ１０１からステッ
プＳ１０６までの設定作業が繰り返し行われる。

【００５９】 以上が、図９のフローチャートの説明で
あるが、図９のフローチャートのバスリセットからルー
ト決定までの部分と、ルート決定後からＩＤ設定終了ま
での手順をより詳しくフローチャート図に表したものを
それぞれ、図１０、図１１に示す。

【００６０】まず、図１０のフローチャートの説明を行
う。

【００６１】ステップＳ２０１としてバスリセットが発
生すると、ネットワーク構成は一旦リセットされる。な
お、ステップＳ２０１としてバスリセットが発生するの
を常に監視している。

【００６２】次に、ステップＳ２０２として、リセット
されたネットワークの接続状況を再認識する作業の第一
段階として、各機器にリーフ（ノード）であることを示
すフラグを立てておく。さらに、ステップＳ２０３とし
て各機器が自分の持つポートがいくつ他ノードと接続さ
れているのかを調べる。

【００６３】ステップＳ２０４のポート数の結果に応じ
て、これから親子関係の宣言を始めていくために、未定
義（親子関係が決定されてない）ポートの数を調べる。
バスリセットの直後はポート数＝未定義ポート数である
が、親子関係が決定されていくにしたがって、ステップ
Ｓ２０４で検知する未定義ポートの数は変化していくも
のである。

【００６４】まず、バスリセットの直後、はじめに親子
関係の宣言を行えるのはリーフに限られている。リーフ
であるというのはステップＳ２０３のポート数の確認で
知ることができる。リーフは、ステップＳ２０５とし
て、自分に接続されているノードに対して、「自分は
子、相手は親」と宣言し動作を終了する。

【００６５】ステップＳ２０３でポート数が複数ありブ
ランチと認識したノードは、バスリセットの直後はステ
ップＳ２０４で未定義ポート数＞１ということなので、
ステップＳ２０６へと移り、まずブランチというフラグ
が立てられ、ステップＳ２０７でリーフからの親子関係
宣言で「親」の受付をするために待つ。

【００６６】リーフが親子関係の宣言を行い、ステップ
Ｓ２０７でそれを受けたブランチは適宜ステップＳ２０
４の未定義ポート数の確認を行い、未定義ポート数が１
になっていれば残っているポートに接続されているノー
ドに対して、ステップＳ２０５の「自分が子」の宣言を
することが可能になる。２度目以降、ステップＳ２０４
で未定義ポート数を確認しても２以上あるブランチに対
しては、再度ステップＳ２０７でリーフ又は他のブラン
チからの「親」の受付をするために待つ。

【００６７】最終的に、いずれか１つのブランチ、又は
例外的にリーフ（子宣言を行えるのにすばやく動作しな
かった為）がステップＳ２０４の未定義ポート数の結果
としてゼロになったら、これにてネットワーク全体の親
子関係の宣言が終了したものであり、未定義ポート数が
ゼロ（すべて親のポートとして決定）になった唯一のノ
ードはステップＳ２０８としてルートのフラグが立てら
れ、ステップＳ２０９としてルートとしての認識がなさ
れる。

【００６８】このようにして、図１０に示したバスリセ
ットから、ネットワーク内すべてのノード間における親
子関係の宣言までが終了する。

【００６９】つぎに、図１１のフローチャートについて
説明する。

【００７０】まず、図１１までのシーケンスでリーフ、
ブランチ、ルートという各ノードのフラグの情報が設定
されているので、これを元にして、ステップＳ３０１で
それぞれ分類する。

【００７１】各ノードにＩＤを与える作業として、最初
にＩＤの設定を行うことができるのはリーフからであ
る。リーフ→ブランチ→ルートの順で若い番号（ノード
番号＝０〜）からＩＤの設定がなされていく。

【００７２】ステップＳ３０２としてネットワーク内に
存在するリーフの数Ｎ（Ｎは自然数）を設定する。

【００７３】この後、ステップＳ３０３として各自リー
フがルートに対して、ＩＤを与えるように要求する。こ
の要求が複数ある場合には、ルートはステップＳ３０４
としてアービトレーションを行い、ステップＳ３０５と
して勝ったノード１つにＩＤ番号を与え、負けたノード
には失敗の結果通知を行う。

【００７４】ステップＳ３０６としてＩＤ取得が失敗に
終わったリーフは、再度ＩＤ要求を出し、同様の作業を
繰り返す。ＩＤを取得できたリーフからステップＳ３０
７として、そのノードのＩＤ情報をブロードキャストで
全ノードに転送する。１ノードＩＤ情報のブロードキャ
ストが終わると、ステップＳ３０８として残りのリーフ
の数が１つ減らされる。

【００７５】ここで、ステップＳ３０９として、この残
りのリーフの数が１以上ある時はステップＳ３０３のＩ
Ｄ要求の作業からを繰り返し行い、最終的にすべてのリ
ーフがＩＤ情報をブロードキャストすると、ステップＳ
３０９がＮ＝０となり、次はブランチのＩＤ設定に移
る。ブランチのＩＤ設定もリーフの時と同様に行われ
る。

【００７６】まず、ステップＳ３１０としてネットワー
ク内に存在するブランチの数Ｍ（Ｍは自然数）を設定す
る。

【００７７】この後、ステップＳ３１１として各自ブラ
ンチがルートに対して、ＩＤを与えるように要求する。
これに対してルートは、ステップＳ３１２としてアービ
トレーションを行い、勝ったブランチから順にリーフに
与え終った次の若い番号から与えていく。

【００７８】ステップＳ３１３として、ルートは要求を
出したブランチにＩＤ情報又は失敗結果を通知し、ステ
ップＳ３１４としてＩＤ取得が失敗に終わったブランチ
は、再度ＩＤ要求を出し、同様の作業を繰り返す。

【００７９】ＩＤを取得できたブランチからステップＳ
３１５として、そのノードのＩＤ情報をブロードキャス
トで全ノードに転送する。

【００８０】１ノードＩＤ情報のブロードキャストが終
わると、ステップＳ３１６として残りのブランチの数が
１つ減らされる。

【００８１】ここで、ステップＳ３１７として、この残
りのブランチの数が１以上ある時はステップＳ３１１の
ＩＤ要求の作業からを繰り返し、最終的にすべてのブラ
ンチがＩＤ情報をブロードキャストするまで行われる。
すべてのブランチがノードＩＤを取得すると、ステップ
Ｓ３１７はＭ＝０となり、ブランチのＩＤ取得モードも
終了する。

【００８２】ここまで終了すると、最終的にＩＤ情報を
取得していないノードはルートのみなので、ステップＳ
３１８として与えていない番号で最も若い番号を自分の
ＩＤ番号と設定し、ステップＳ３１９としてルートのＩ
Ｄ情報をブロードキャストする。

【００８３】以上で、図１１に示したように、親子関係
が決定した後から、すべてのノードのＩＤが設定される
までの手順が終了する。

【００８４】次に、一例として図１２に示した実際のネ
ットワークにおける動作を図１２を参照しながら説明す
る。

【００８５】図１２の説明として、（ルート）ノードＢ
の下位にはノードＡとノードＣが直接接続されており、
更にノードＣの下位にはノードＤが直接接続されてお
り、更にノードＤの下位にはノードＥとノードＦが直接
接続された階層構造になっている。この、階層構造やル
ートノード、ノードIDを決定する手順を以下で説明す
る。

【００８６】バスリセットがされた後、まず各ノードの
接続状況を認識するために、各ノードの直接接続されて
いるポート間において、親子関係の宣言がなされる。こ
の親子とは親側が階層構造で上位となり、子側が下位と
なると言うことができる。

【００８７】図１２ではバスリセットの後、最初に親子
関係の宣言を行なったのはノードＡである。基本的にノ
ードの１つのポートにのみ接続があるノード（リーフと
呼ぶ）から親子関係の宣言を行なうことができる。これ
は自分には１ポートの接続のみということをまず知るこ
とができるので、これによってネットワークの端である
ことを認識し、その中で早く動作を行なったノードから
親子関係が決定されていく。こうして親子関係の宣言を
行なった側（Ａ- Ｂ間ではノードＡ）のポートが子と設
定され、相手側（ノードＢ）のポートが親と設定され
る。こうして、ノードＡ−Ｂ間では子−親、ノードＥ−
Ｄ間で子−親、ノードＦ−Ｄ間で子−親と決定される。

【００８８】さらに１階層あがって、今度は複数個接続
ポートを持つノード（ブランチと呼ぶ）のうち、他ノー
ドからの親子関係の宣言を受けたものから順次、更に上
位に親子関係の宣言を行なっていく。図12ではまずノー
ドＤがＤ−Ｅ間、Ｄ−Ｆ間と親子関係が決定した後、ノ
ードＣに対する親子関係の宣言を行っており、その結果
ノードＤ−Ｃ間で子−親と決定している。

【００８９】ノードＤからの親子関係の宣言を受けたノ
ードＣは、もう一つのポートに接続されているノードＢ
に対して親子関係の宣言を行なっている。これによって
ノードＣ−Ｂ間で子−親と決定している。

【００９０】このようにして、図１２のような階層構造
が構成され、最終的に接続されているすべてのポートに
おいて親となったノードＢが、ルートノードと決定され
た。ルートは１つのネットワーク構成中に一つしか存在
しないものである。

【００９１】なお、この図１２においてノードＢがルー
トノードと決定されたが、これはノードＡから親子関係
宣言を受けたノードＢが、他のノードに対して親子関係
宣言を早いタイミングで行なっていれば、ルートノード
は他ノードに移っていたこともあり得る。すなわち、伝
達されるタイミングによってはどのノードもルートノー
ドとなる可能性があり、同じネットワーク構成でもルー
トノードは一定とは限らない。

【００９２】ルートノードが決定すると、次は各ノード
IDを決定するモードに入る。ここではすべてのノード
が、決定した自分のノードIDを他のすべてのノードに通
知する（ブロードキャスト機能）。

【００９３】自己ID情報は、自分のノード番号、接続さ
れている位置の情報、持っているポートの数、接続のあ
るポートの数、各ポートの親子関係の情報等を含んでい
る。

【００９４】ノードID番号の割り振りの手順としては、
まず１つのポートにのみ接続があるノード（リーフ）か
ら起動することができ、この中から順にノード番号＝
０、１、２、・・・と割り当てられる。

【００９５】ノードＩＤを手にしたノードは、ノード番
号を含む情報をブロードキャストで各ノードに送信す
る。これによって、そのＩＤ番号は「割り当て済み」で
あることが認識される。

【００９６】すべてのリーフが自己ノードＩＤを取得し
終ると、次はブランチへ移りリーフに引き続いたノード
ＩＤ番号が各ノードに割り当てられる。リーフと同様
に、ノードID番号が割り当てられたブランチから順次ノ
ードＩＤ情報をブロードキャストし、最後にルートノー
ドが自己ＩＤ情報をブロードキャストする。すなわち、
常にルートは最大のノードＩＤ番号を所有するものであ
る。

【００９７】以上のようにして、階層構造全体のノード
ＩＤの割り当てが終わり、ネットワーク構成が再構築さ
れ、バスの初期化作業が完了する。

【００９８】アービトレーションについて説明する。

【００９９】１３９４シリアルバスでは、データ転送に
先立って必ずバス使用権のアービトレーション（調停）
を行なう。１３９４シリアルバスは個別に接続された各
機器が、転送された信号をそれぞれ中継することによっ
て、ネットワーク内すべての機器に同信号を伝えるよう
に、論理的なバス型ネットワークであるので、パケット
の衝突を防ぐ意味でアービトレーションは必要である。
これによってある時間には、たった一つのノードのみ転
送を行なうことができる。

【０１００】アービトレーションを説明するための図と
して図１３（ａ）にバス使用要求の図（ｂ）にバス使用
許可の図を示し、以下これを用いて説明する。

【０１０１】アービトレーションが始まると、１つもし
くは複数のノードが親ノードに向かって、それぞれバス
使用権の要求を発する。図１３（ａ）のノードＣとノー
ドＦがバス使用権の要求を発しているノードである。こ
れを受けた親ノード（図１３ではノードＡ）は更に親ノ
ードに向かって、バス使用権の要求を発する（中継す
る）。この要求は最終的に調停を行なうルートに届けら
れる。

【０１０２】バス使用要求を受けたルートノードは、ど
のノードにバスを使用させるかを決める。この調停作業
はルートノードのみが行なえるものであり、調停によっ
て勝ったノードにはバスの使用許可を与える。図１３
（ｂ）ではノードＣに使用許可が与えられ、ノードＦの
使用は拒否された図である。

【０１０３】アービトレーションに負けたノードに対し
てはＤＰ（data prefix ）パケットを送り、拒否された
ことを知らせる。拒否されたノードのバス使用要求は次
回のアービトレーションまで待たされる。

【０１０４】以上のようにして、アービトレーションに
勝ってバスの使用許可を得たノードは、以降データの転
送を開始できる。

【０１０５】ここで、アービトレーションの一連の流れ
をフローチャート図１４に示して、説明する。

【０１０６】ノードがデータ転送を開始できる為には、
バスがアイドル状態であることが必要である。先に行わ
れていたデータ転送が終了して、現在バスが空き状態で
あることを認識するためには、各転送モードで個別に設
定されている所定のアイドル時間ギャップ長（例えば、
サブアクション・ギャップ）を経過する事によって、各
ノードは自分の転送が開始できると判断する。

【０１０７】ステップＳ４０１として、Ａｓｙｎｃデー
タ、Ｉｓｏデータ等それぞれ転送するデータに応じた所
定のギャップ長が得られたか判断する。所定のギャップ
長が得られない限り、転送を開始するために必要なバス
使用権の要求はできないので、所定のギャップ長が得ら
れるまで待つ。

【０１０８】ステップＳ４０１で所定のギャップ長が得
られたら、ステップＳ４０２として転送すべきデータが
あるか判断し、ある場合はステップＳ４０３として転送
するためにバスを確保するよう、バス使用権の要求をル
ートに対して発する。このときの、バス使用権の要求を
表す信号の伝達は、図１３に示したように、ネットワー
ク内各機器を中継しながら、最終的にルートに届けられ
る。ステップＳ４０２で転送するデータがない場合は、
そのまま待機する。

【０１０９】次に、ステップＳ４０４として、ステップ
Ｓ４０３のバス使用要求を１つ以上ルートが受信した
ら、ルートはステップＳ４０５として使用要求を出した
ノードの数を調べる。

【０１１０】ステップＳ４０５での選択値がノード数＝
１（使用権要求を出したノードは１つ）だったら、その
ノードに直後のバス使用許可が与えられることとなる。
ステップＳ４０５での選択値がノード数＞１（使用要求
を出したノードは複数）だったら、ルートはステップＳ
４０６として使用許可を与えるノードを１つに決定する
調停作業を行う。この調停作業は公平なものであり、毎
回同じノードばかりが許可を得る様なことはなく、平等
に権利を与えていくような構成となっている（フェア・
アービトレーション）。

【０１１１】ステップＳ４０７として、ステップＳ４０
６で使用要求を出した複数ノードの中からルートが調停
して使用許可を得た１つのノードと、敗れたその他のノ
ードに分ける選択を行う。ここで、調停されて使用許可
を得た１つのノード、またはステップＳ４０５の選択値
から使用要求ノード数＝１で調停無しに使用許可を得た
ノードには、ステップＳ４０８として、ルートはそのノ
ードに対して許可信号を送る。

【０１１２】許可信号を得たノードは、受け取った直後
に転送すべきデータ（パケット）を転送開始する。ま
た、ステップＳ４０６の調停で敗れて、バス使用が許可
されなかったノードにはステップＳ４０９としてルート
から、アービトレーション失敗を示すＤＰ（data prefi
x ）パケットを送られ、これを受け取ったノードは再度
転送を行うためのバス使用要求を出すため、ステップＳ
４０１まで戻り、所定ギャップ長が得られるまで待機す
る。

【０１１３】以上がアービトレーションの流れを説明し
た、フローチャート図１４の説明である。

【０１１４】Ａｓｙｎｃｈｒｏｎｏｕｓ（非同期）転送
について説明する。

【０１１５】アシンクロナス転送は、非同期転送であ
る。図１５にアシンクロナス転送における時間的な遷移
状態を示す。

【０１１６】図１５の最初のサブアクション・ギャップ
は、バスのアイドル状態を示すものである。このアイド
ル時間が一定値になった時点で、転送を希望するノード
はバスが使用できると判断して、バス獲得のためのアー
ビトレーションを実行する。

【０１１７】アービトレーションでバスの使用許可を得
ると、次にデータの転送がパケット形式で実行される。
データ転送後、受信したノードは転送されたデータに対
しての受信結果のack （受信確認用返送コード）をａｃ
ｋ ｇａｐという短いギャップの後、返送して応答する
か、応答パケットを送ることによって転送が完了する。
ａｃｋは４ビットの情報と４ビットのチェックサムから
なり、成功か、ビジー状態か、ペンディング状態である
かといった情報を含み、すぐに送信元ノードに返送され
る。

【０１１８】つぎに、図１６にアシンクロナス転送のパ
ケットフォーマットの例を示す。

【０１１９】パケットには、データ部及び誤り訂正用の
データＣＲＣの他にはヘッダ部があり、そのヘッダ部に
は図１６に示したような、目的ノードＩＤ、ソースノー
ドＩＤ、転送データ長さや各種コードなどが書き込ま
れ、転送が行なわれる。

【０１２０】また、アシンクロナス転送は自己ノードか
ら相手ノードへの１対１の通信である。転送元ノードか
ら転送されたパケットは、ネットワーク中の各ノードに
行き渡るが、自分宛てのアドレス以外のものは無視され
るので、宛先の１つのノードのみが読込むことになる。

【０１２１】以上がアシンクロナス転送の説明である。

【０１２２】Ｉｓｏｃｈｒｏｎｏｕｓ（同期）転送につ
いて説明する。

【０１２３】アイソクロナス転送は同期転送である。１
３９４シリアルバスの最大の特徴であるともいえるこの
アイソクロナス転送は、特に映像データや音声データと
いったマルチメディアデータなど、リアルタイムな転送
を必要とするデータの転送に適した転送モードである。

【０１２４】また、アシンクロナス転送（非同期）が１
対１の転送であったのに対し、このアイソクロナス転送
はブロードキャスト機能によって、転送元の１つのノー
ドから他のすべてのノードへ一様に転送される。

【０１２５】図１７はアイソクロナス転送における、時
間的な遷移状態を示す図である。

【０１２６】アイソクロナス転送は、バス上一定時間毎
に実行される。この時間間隔をアイソクロナスサイクル
と呼ぶ。アイソクロナスサイクル時間は、１２５μS で
ある。この各サイクルの開始時間を示し、各ノードの時
間調整を行なう役割を担っているのがサイクル・スター
ト・パケットである。サイクル・スタート・パケットを
送信するのは、サイクル・マスタと呼ばれるノードであ
り、１つ前のサイクル内の転送終了後、所定のアイドル
期間（サブアクションギャップ）を経た後、本サイクル
の開始を告げるサイクル・スタート・パケットを送信す
る。

【０１２７】このサイクル・スタート・パケットの送信
される時間間隔が１２５μS となる。

【０１２８】また、図１７にチャネルＡ、チャネルＢ、
チャネルＣと示したように、１サイクル内において複数
種のパケットがチャネルIDをそれぞれ与えられることに
よって、区別して転送できる。これによって同時に複数
ノード間でのリアルタイムな転送が可能であり、また受
信するノードでは自分が欲しいチャネルＩＤのデータの
みを取り込む。このチャネルＩＤは送信先のアドレスを
表すものではなく、データに対する論理的な番号を与え
ているに過ぎない。よって、あるパケットの送信は１つ
の送信元ノードから他のすべてのノードに行き渡る、ブ
ロードキャストで転送されることになる。

【０１２９】アイソクロナス転送のパケット送信に先立
って、アシンクロナス転送同様アービトレーションが行
われる。しかし、アシンクロナス転送のように１対１の
通信ではないので、アイソクロナス転送にはａｃｋ（受
信確認用返信コード）は存在しない。

【０１３０】また、図１７に示したｉｓｏ ｇａｐ（ア
イソクロナスギャップ）とは、アイソクロナス転送を行
なう前にバスが空き状態であると認識するために必要な
アイドル期間を表している。この所定のアイドル期間を
経過すると、アイソクロナス転送を行ないたいノードは
バスが空いていると判断し、転送前のアービトレーショ
ンを行なうことができる。

【０１３１】つぎに、図１８にアイソクロナス転送のパ
ケットフォーマットの例を示し、説明する。

【０１３２】各チャネルに分かれた、各種のパケットに
はそれぞれデータ部及び誤り訂正用のデータＣＲＣの他
にヘッダ部があり、そのヘッダ部には図１８に示したよ
うな、転送データ長やチャネルNO、その他各種コード及
び誤り訂正用のヘッダＣＲＣなどが書き込まれ、転送が
行なわれる。

【０１３３】以上がアイソクロナス転送の説明である。

【０１３４】バス・サイクルについて説明する。

【０１３５】実際の１３９４シリアルバス上の転送で
は、アイソクロナス転送と、アシンクロナス転送は混在
できる。その時の、アイソクロナス転送とアシンクロナ
ス転送が混在した、バス上の転送状態の時間的な遷移の
様子を表した図を図１９に示す。

【０１３６】アイソクロナス転送はアシンクロナス転送
より優先して実行される。その理由は、サイクル・スタ
ート・パケットの後、アシンクロナス転送を起動するた
めに必要なアイドル期間のギャップ長（サブアクション
ギャップ）よりも短いギャップ長（アイソクロナスギャ
ップ）で、アイソクロナス転送を起動できるからであ
る。したがって、アシンクロナス転送より、アイソクロ
ナス転送は優先して実行されることとなる。

【０１３７】図１９に示した、一般的なバスサイクルに
おいて、サイクル＃ｍのスタート時にサイクル・スター
ト・パケットがサイクル・マスタから各ノードに転送さ
れる。これによって、各ノードで時刻調整を行ない、所
定のアイドル期間（アイソクロナスギャップ）を待って
からアイソクロナス転送を行なうべきノードはアービト
レーションを行い、パケット転送に入る。図１９ではチ
ャネルｅとチャネルｓとチャネルｋが順にアイソクロナ
ス転送されている。

【０１３８】このアービトレーションからパケット転送
までの動作を、与えられているチャネル分繰り返し行な
った後、サイクル＃ｍにおけるアイソクロナス転送がす
べて終了したら、アシンクロナス転送を行うことができ
るようになる。

【０１３９】アイドル時間がアシンクロナス転送が可能
なサブアクションギャップに達する事によって、アシン
クロナス転送を行いたいノードはアービトレーションの
実行に移れると判断する。

【０１４０】ただし、アシンクロナス転送が行える期間
は、アイソクロナス転送終了後から、次のサイクル・ス
タート・パケットを転送すべき時間（cycle synch ）ま
での間にアシンクロナス転送を起動するためのサブアク
ションギャップが得られた場合に限っている。

【０１４１】図１９のサイクル＃ｍでは３つのチャネル
分のアイソクロナス転送と、その後アシンクロナス転送
（含むack ）が２パケット（パケット１、パケット２）
転送されている。このアシンクロナスパケット２の後
は、サイクルｍ＋１をスタートすべき時間（cycle sync
h ）にいたるので、サイクル＃ｍでの転送はここまでで
終わる。

【０１４２】ただし、非同期または同期転送動作中に次
のサイクル・スタート・パケットを送信すべき時間（cy
cle synch ）に至ったとしたら、無理に中断せず、その
転送が終了した後のアイドル期間を待ってから次サイク
ルのサイクル・スタート・パケットを送信する。すなわ
ち、１つのサイクルが１２５μS 以上続いたときは、そ
の分次サイクルは基準の１２５μS より短縮されたとす
る。このようにアイソクロナス・サイクルは１２５μS
を基準に超過、短縮し得るものである。

【０１４３】しかし、アイソクロナス転送はリアルタイ
ム転送を維持するために毎サイクル必要であれば必ず実
行され、アシンクロナス転送はサイクル時間が短縮され
たことによって次以降のサイクルにまわされることもあ
る。こういった遅延情報も含めて、サイクル・マスタに
よって管理される。

【０１４４】そこで、まず、第１の実施の形態について
説明する。

【０１４５】図２０は、本発明の特徴を最もよく表す図
であり、同図において１３９４のインターフェイスをＬ
ＡＮで用いられるＯＳＩモデルの各層と対比させてみる
と、ＯＳＩモデルの物理層１とデータリンク層２が、１
３９４インターフェイスの下位層４であるフィジカル・
リンク層に該当し、それら下位層４の上に存在する上位
層３が１３９４インターフェイスではトランスポートプ
ロトコル層５とプレゼンテーション層６に該当する。ま
た、本発明の特徴となるＬＯＧＩＮプロトコル７は、１
３９４インターフェイスの下位層４とトランスポートプ
ロトコル５との間で動作するものである。

【０１４６】この実施の形態では、シリアルバスプロト
コル（ＳＢＰ−２）８に準拠したデバイスにＬＯＧＩＮ
プロトコルを挿入することによって、相手のデバイスに
対して自分がＳＢＰ−２に準拠したプロトコルを使って
やり取りを行いたいことを通知することができる。また
例２では、１３９４インターフェイス上で特化されたデ
バイスプロトコル９についてもＬＯＧＩＮプロトコルを
挿入することで、お互いのデバイスがそのプロトコルが
サポートされているかを判別してデータのやり取りを行
うことができる。

【０１４７】図２１は、ＬＯＧＩＮプロトコルの基本動
作を示した図であり、プリンタは印字タスク１０を実行
する際にまず初めにＬＯＧＩＮプロトコルを使ってプリ
ンタで用意しているプリンタプロトコルＡ・Ｂ・Ｃのう
ち、どれを選択して印字するかを決定し、その後は決定
されたプロトコルに沿って印字動作を行う。すなわち、
プリンタ側でいくつかのプリンタプロトコルをサポート
しているデバイスにおいて、ターゲットとの接続の際に
まず初めに相手のデバイスのプロトコルをＬＯＧＩＮプ
ロトコルを使って判別し、プリンタは相手のプロトコル
に合わせたプリンタプロトコルを複数の中からひとつ選
択し、この選ばれたプロトコルに沿って印字データやコ
マンドのやり取りを行って印字処理を行う。

【０１４８】図２２は、この実施の形態におけるＬＯＧ
ＩＮプロトコルを実装した１３９４インターフェイスに
おける各デバイスの接続形態を示した図で、複数のプリ
ンタプロトコルに対応したプリンタ１１に対してＬＯＧ
ＩＮプロトコルを実装したデバイス（ＰＣ１２、スキャ
ナ１３、ＶＣＲ１４等）が接続された場合に、ＬＯＧＩ
Ｎプロトコルを使用して相手のトランスポートプロトコ
ルに応じてプリンタ側でプリンタプロトコルを切り替え
ることにより、各デバイスからの印字タスクを問題なく
処理することが可能となる。

【０１４９】図２３はログイン動作の流れを示したもの
である。

【０１５０】第一ステップ： ・デバイス（この場合マルチプロトコルプリンタ）をロ
ック ・プリンタのケーパビリティ（受け付けるプロトコル
等）を取得 かかるケーパビリティは、後述するレジスタ５０３に格
納される。 ・ホストのケーパビリティをプリンタにセット 第二ステップ： ・第一ステップで決定したプロトコルで、プリントデー
タの通信 第三ステップ： ・プリンタとホストは、コネクションを切断

【０１５１】図２４は、この実施の形態においてＬＯＧ
ＩＮプロトコルのためにプリンタが備える１３９４シリ
アルバスのＣＳＲを示し、図中、５０１はロックレジス
タ（ｌｏｃｋ）、５０２はプロトコルレジスタ（ｐｒｏ
ｔｏｃｏｌ）、５０３はケーパビリティレジスタ（ｃａ
ｐａｂｉｌｉｔｙ）を示す。これらのレジスタは１３９
４シリアルバスのアドレス空間における初期ユニット空
間の定められたアドレスに配置される。ロックレジスタ
５０１はリソースのロック状態を示し、値０はログイン
可能な状態をあらわし、０以外はロック状態ですでにロ
グインされていることをあらわす。ケーパビリティレジ
スタ５０３は設定可能なプロトコルを示し、ビット毎に
プロトコルに対応し、ビットの値１はそのプロトコルが
設定可能であることをあらわし、０は設定不可能である
ことをあらわす。プロトコルレジスタ５０２は現在設定
されたプロトコルを示し、設定されたプロトコルに対応
するケーパビリティレジスタ５０３のビットに相当する
ビットの値が１になる。

【０１５２】図２５は、ログイン処理のホスト側のフロ
ーチャートである。

【０１５３】ログインを開始するためには、まずログイ
ンしようとするプリンタのロックレジスタ５０１、プロ
トコルレジスタ５０２、ケーパビリティレジスタ５０３
をリードトランザクションにより確認する。ここで、ケ
ーパビリティレジスタ５０３の内容から、ホストが通信
に用いるプロトコルをプリンタがサポートしているかど
うか確認する（ステップＳ６０１）。もしホストのプロ
トコルがプリンタのサポート外ならば、次のステップで
ログインを中止する。

【０１５４】ロックレジスタ５０１が０以外であれば、
他のデバイスがログイン中であるとみなし、ログインを
中止する。ログインレジスタ５０１が０であれば、現在
ログイン可能とみなす（ステップＳ６０２）。

【０１５５】ログイン可能の場合リソースロック処理に
移り、プリンタのロックレジスタ５０１にロックトラン
ザクションを用いて１を書き込み、ホスト側のログイン
設定とする（ステップＳ６０３）。この状態でプリンタ
はロックされたことになり、他のデバイスからの出力は
不可能。またレジスタの変更も不可能とする。

【０１５６】上記のようにプリンタのリソースがロック
された状態で、次にプロトコルの設定を行なう。本実施
の形態におけるプリンタは、複数プリントプロトコルを
サポートするため、プリントデータを受け取る前に、ホ
スト側のプロトコルを知らねばならない。ここでは、ホ
スト側がプリンタのプロトコルレジスタ５０２に対し
て、ライトトランザクションにより、これから使用する
プロトコルに相当するビットを立て通知する（ステップ
Ｓ６０４）、という手段を用いる。

【０１５７】この時点で、ホストが通信に用いるプロト
コルがプリンタに通知され、かつプリンタがロック状態
なので、現在ログインしているホストが通常のプロトコ
ルでプリントデータの送信を行なう（ステップＳ６０
５）。

【０１５８】プリントデータの送信が終了したら、ホス
トはプリンタのロックレジスタ５０１、プロトコルレジ
スタ５０２、ケーパビリティレジスタ５０３をクリアす
ることにより、プリンタからログアウトする（ステップ
Ｓ６０６）。

【０１５９】図２６は、ログイン処理のプリンタ側のフ
ローチャートである。

【０１６０】先ず、プリンタ側は、通常ホストからのロ
グイン待ち状態となる（ステップＳ７０１）。ログイン
は、ホストからプリンタロックレジスタ５０１、プロト
コルレジスタ５０２、ケーパビリティレジスタ５０３の
読み取りから開始される。これは、ログインに対応した
ホストの場合であり、ログインに対応していないホスト
では、これらのレジスタに対するアクセスは行われな
い。

【０１６１】ログイン待ち状態（ステップＳ７０１）
は、所定の時間でタイムアウトとなるようになされてお
り、次のステップＳ７０２で、タイムアウトか否かが判
定される。

【０１６２】ステップＳ７０２の判定により、タイムア
ウトせずにその時間内でログインが行われれば、使用プ
ロトコル種の受信待ち（ステップＳ７０５）へ進み、使
用プロトコルの通知待ち状態となる。

【０１６３】一方、ステップＳ７０２の判定により、タ
イムアウトとなった場合、プロトコル検索を行う（ステ
ップＳ７０３）。プロトコル検索は、詳細は後述する
が、ホストとなるノードを探し、ノードＩＤからホスト
のプロトコルを検索する処理である。

【０１６４】ステップＳ７０３のプロトコル検索の結果
を用いて、次のステップＳ７０４でプリンタが対応する
プロトコルであるか否が判定される。

【０１６５】ステップＳ７０４の判定により、プリンタ
が対応するプロトコルである場合には、プロトコルの設
定を行う（ステップＳ７０６）。

【０１６６】一方、プリンタが対応するプロトコルでな
ければ、ログイン待ち状態（ステップＳ７０１）とな
る。

【０１６７】したがって、ログインされて使用プロトコ
ルが通知される（ステップＳ７０５）か、或いは、プロ
トコル検索で対応プロトコルが見つかった（ステップＳ
７０４）場合に、プロトコルの設定を行う（ステップＳ
７０６）。

【０１６８】プロトコルの設定（ステップＳ７０６）
後、次のステップＳ７０７〜ステップＳ７１２により、
各プロトコルへのスイッチを行い、各プロトコルでデー
タ通信を行う。

【０１６９】そして、データ通信が終了すると、プリン
タは、ロックレジスタ５０１、プロトコルレジスタ５０
２、ケーパビリティレジスタ５０３がクリアされたのを
確認し（ステップＳ７１３）、ログイン待ち状態（ステ
ップＳ７０１）に戻る。

【０１７０】但し、プロトコル検索（ステップＳ７０
３）にて、プロトコルが決定されるような場合、当然ロ
グアウトにも対応していないわけであるため、この場合
には、バスのリセット、ホスト、プリンタのリセット等
により、初期状態のログイン待ち状態となる。

【０１７１】図２７は、上述したプロトコル検索を示す
フローチャートである。

【０１７２】先ず、バス上にあるノードの総数を得る
（ステップＳ８０１）。バスノードの総数は、バスマネ
ージャが保持するトポロジーマップ等から判断すること
ができる。

【０１７３】次に、ステップＳ８０１により得られたノ
ードの総数が有効であるか否かを判定する（ステップＳ
８０２）。この判定は、上記ノード総数が３以上の場合
か、或いは、自分以外に存在しない場合（ステップＳ８
０２）、対応プロトコル無し（無効）とする処理であ
る。

【０１７４】ステップＳ８０２の判定により、ノード総
数が無効であった場合には、対応プロトコル無しとして
（ステップＳ８０７）、リターンする。

【０１７５】一方、ノードの総数が有効であった場合、
相手のノード番号を得る（ステップＳ８０３）。自分の
ノード番号が「０」であるならば、相手のノード番号は
「１」、自分のノード番号が「１」であるならば、相手
のノード番号は「０」というように、相手のノード番号
は単純に決定することができる。

【０１７６】次に、相手のノードＩＤを得る（ステップ
Ｓ８０４）。ノードＩＤは、図６に示したＣｏｎｆｉｇ
ｕｒａｔｉｏｎ ＲＯＭのｎｏｄｅ＿ｖｅｎｄｏｒ＿ｉ
ｄ，ｃｈｉｐ＿ｉｄ＿ｈｉ，ｃｈｉｐ＿ｉｄ＿ｌｏをｒ
ｅａｄトランザクションで読み込むことにより、得るこ
とができる。また、ノードＩＤは、機器により固有のナ
ンバーを有するため、相手の機器を特定することができ
る。

【０１７７】次に、相手の機器から相手のプロトコルを
決定する（ステップＳ８０５）。

【０１７８】次に、相手のプロトコルがプリンタに有効
か否かを判定し（ステップＳ８０６）、有効でなければ
対応プロトコル無しとし（ステップＳ８０７）、有効で
あれば対応プロトコル有りとして（ステップＳ８０
８）、リターンする。

【０１７９】したがって、上述したプロトコル検索の結
果が、対応プロトコルの有無と、プロトコルとして通知
されることとなる。

【０１８０】以上の図２６及び図２７に示した処理によ
り、ログインを行わない機器に対してプリンタが相手の
ノードＩＤから相手のプロトコルを特定し、そのプロト
コルに自らのプロトコルを合わせることができる。

【０１８１】尚、本発明は、図２２に示すような、複数
の機器から構成されるシステムに適用しても、１つの機
器からなる装置内のデータ処理方法に適用してもよい。

【０１８２】また、本発明の目的は、上述した各実施の
形態のホスト及び端末の機能を実現するソフトウェアの
プログラムコードを記憶した記憶媒体を、システム或い
は装置に供給し、そのシステム或いは装置のコンピュー
タ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプロ
グラムコードを読みだして実行することによっても、達
成されることは言うまでもない。

【０１８３】この場合、記憶媒体から読み出されたプロ
グラムコード自体が前述した各実施の形態の機能を実現
することとなり、そのプログラムコードを記憶した記憶
媒体は本発明を構成することとなる。

【０１８４】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピーディスク、ハードディ
スク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、Ｃ
Ｄ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ
等を用いることができる。

【０１８５】また、コンピュータが読みだしたプログラ
ムコードを実行することにより、前述した実施の形態の
機能が実現されるだけでなく、そのプログラムコードの
指示に基づき、コンピュータ上で稼動しているＯＳ等が
実際の処理の一部又は全部を行い、その処理によって実
施の形態の機能が実現される場合も含まれることは言う
までもない。

【０１８６】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された拡張機能ボー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書き込まれた後、そのプログラムコードの指
示に基づき、その機能拡張ボードや機能拡張ユニットに
備わるＣＰＵなどが実際の処理の一部又は全部を行い、
その処理によって前述した実施の形態の機能が実現され
る場合も含まれることは言うまでもない。

【０１８７】さらにまた、本発明におけるホスト固有の
識別子としては、アスキーコードでもよいし、２値デー
タでもよいし、或いは、ホストを専有している法人、個
人の名前でもよい。また、識別子としては、ネットワー
クアドレスでもよいし、例えば、ＩＰアドレスや、ＭＡ
Ｃアドレスと呼ばれるアドレスでもよい。また、例え
ば、ホストに固有の識別子でなく、変動型の識別子でも
よいし、又は、暗号化のキー等でもよい。すなわち、ホ
ストが識別できる情報であれば、全て本発明における識
別子に含まれる。

【０１８８】

【発明の効果】以上説明したように本発明によれば、初
期プロトコルに対応しないホストに対してプリンタのプ
ロトコルを適合させることができ、初期プロトコルを実
装しないホストに対しても、プロトコルを一致させ、幅
広く対応することができる。

【図面の簡単な説明】

【図１】ＩＥＥＥ１３９４ケーブルを用いた通信システ
ムの一例を示す図である。

【図２】ＩＥＥＥ１３９４の階層構造を示す図である。

【図３】ＩＥＥＥ１３９４のアドレスを示す図である。

【図４】最小形式のＣｏｎｆｉｇｒａｔｉｏｎ ＲＯＭ
を説明するための図である。

【図５】一般形式のＣｏｎｆｉｇｒａｔｉｏｎ ＲＯＭ
を説明するための図である。

【図６】ディジタルカメラのＣｏｎｆｉｇｒａｔｉｏｎ
ＲＯＭを説明するための図である。

【図７】ＩＥＥＥ１３９４のケーブル断面図である。

【図８】DS-Link 符号化方式を説明するための図であ
る。

【図９】バスリセットからIDの設定までを説明するフロ
ーチャートである。

【図１０】ルートの決定方法を説明するフローチャート
である。

【図１１】親子関係決定からすべてのノードＩＤの設定
までの手順を説明するフローチャートである。

【図１２】ノード間の親子関係を示す図である。

【図１３】アービトレーションの過程を説明するための
図である。

【図１４】アービトレーションの過程を示すフローチャ
ートである。

【図１５】Asynchronous転送におけるサブアクションを
示す図である。

【図１６】Asynchronous転送におけるパケット構造を示
す図である。

【図１７】Isochronous 転送におけるサブアクションを
示す図である。

【図１８】Isochronous 転送におけるパケット構造を示
す図である。

【図１９】ＩＥＥＥ１３９４の通信サイクルの一例を説
明するための図である。

【図２０】本発明を適用したシステムを説明するための
図である。

【図２１】ＬＯＧＩＮプロトコルの基本動作を説明する
ための図である。

【図２２】ＬＯＧＩＮプロトコルを実装した１３９４イ
ンターフェイスにおける各デバイスの接続形態を説明す
るための図である。

【図２３】ログイン動作の流れを説明するための図であ
る。

【図２４】ＬＯＧＩＮプロトコルのためにプリンタが備
える１３９４シリアルバスのＣＳＲを説明するための図
である。

【図２５】ログイン処理のホスト側の処理を説明するた
めのフローチャートである。

【図２６】ログイン処理のプリンタ側の処理を説明する
ためのフローチャートである。

【図２７】プロトコル検索処理を説明するためのフロー
チャートである。

【符号の説明】

１ ＯＳＩモデルの物理層 ２ データリンク層 ３ 上位層 ４ 上位層 ５ トランスポートプロトコル層 ６ プレゼンテーション層 ７ ＬＯＧＩＮプロトコル ８ シリアルバスプロトコル（ＳＢＰ−２） ９ デバイスプロトコル

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平４−227524（ＪＰ，Ａ) 特開 平９−26860（ＪＰ，Ａ) 特開 平10−290247（ＪＰ，Ａ) 特開 平10−228427（ＪＰ，Ａ) 特開 平10−126426（ＪＰ，Ａ) 特開 平10−304005（ＪＰ，Ａ) 特開 平７−325684（ＪＰ，Ａ) 特開 平７−325683（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 3/12 B41J 29/00 G06F 13/00 H04L 29/00

Claims (14)

(57)【特許請求の範囲】
1. 【請求項１】 シリアルバスを介して複数種類のプロト
   コルで通信が可能なプリンタのプロトコルを切り換える
   ためのデータ処理方法であって、 前記プリンタのプロトコルの種類に係わらない初期プロ
   トコルによる通信がホストからない場合、前記ホストの
   固有の識別子を取得する取得ステップと、 前記取得ステップで取得された識別子に基づいてプロト
   コルを決定する決定ステップと、 前記決定ステップで決定されたプロトコルの設定を行う
   プロトコル設定ステップとを有することを特徴とするデ
   ータ処理方法。
2. 【請求項２】 前記シリアルバスは、ＩＥＥＥ１３９４
   規格に適合したバス、またはＵＳＢ規格に適合したバス
   であることを特徴とする請求項１記載のデータ処理方
   法。
3. 【請求項３】 前記初期プロトコルは、ＯＳＩモデルの
   データリンク層よりも上位の層で実行されるプロトコル
   であることを特徴とする請求項１又は２に記載のデータ
   処理方法。
4. 【請求項４】 前記初期プロトコルはログインプロトコ
   ルであり、 前記取得ステップでは、前記ログインプロトコルによる
   ログインが前記ホストからない場合、前記ホストの固有
   の識別子を取得することを特徴とする請求項１乃至３の
   いずれか１項に記載のデータ処理方法。
5. 【請求項５】 前記取得ステップでは、前記初期プロト
   コルによる通信が所定の時間ない場合、前記ホストの固
   有の識別子を取得することを特徴とする請求項１乃至４
   のいずれか１項に記載のデータ処理方法。
6. 【請求項６】 シリアルバスを介して複数種類のプロト
   コルで通信が可能なプリンタのプロトコルを切り換える
   ためのデータ処理装置であって、 前記プリンタのプロトコルの種類に係わらない初期プロ
   トコルによる通信がホストからない場合、前記ホストの
   固有の識別子を取得する取得手段と、 前記取得手段により取得された識別子に基づいてプロト
   コルを決定する決定手段と、 前記決定手段により決定されたプロトコルの設定を行う
   プロトコル設定手段とを有することを特徴とするデータ
   処理装置。
7. 【請求項７】 前記初期プロトコルは、ＯＳＩモデルの
   データリンク層よりも上位の層で実行されるプロトコル
   であることを特徴とする請求項６記載のデータ処理装
   置。
8. 【請求項８】 前記初期プロトコルはログインプロトコ
   ルであり、 前記取得手段は、前記ログインプロトコルによるログイ
   ンが前記ホストからない場合、 前記ホストの固有の識別子を取得することを特徴とする
   請求項６又は７に記載のデータ処理装置。
9. 【請求項９】 前記取得手段は、前記初期プロトコルに
   よる通信が所定の時間ない場合、前記ホストの固有の識
   別子を取得することを特徴とする請求項６乃至８のいず
   れか１項に記載のデータ処理装置。
10. 【請求項１０】 シリアルバスを介して複数種類のプロ
    トコルで通信が可能なプリンタであって、 前記プリンタのプロトコルの種類に係わらない初期プロ
    トコルによる通信がホストからない場合、前記ホストの
    固有の識別子を取得する取得手段と、 前記取得手段により取得された識別子に基づいてプロト
    コルを決定する決定手段と、 前記決定手段により決定されたプロトコルの設定を行う
    プロトコル設定手段とを有することを特徴とするプリン
    タ。
11. 【請求項１１】 前記シリアルバスは、ＩＥＥＥ１３９
    ４規格に適合したバス、またはＵＳＢ規格に適合したバ
    スであることを特徴とする請求項１０記載のプリンタ。
12. 【請求項１２】 前記初期プロトコルは、ＯＳＩモデル
    のデータリンク層よりも上位の層で実行されるプロトコ
    ルであることを特徴とする請求項１０又は１１に記載の
    プリンタ。
13. 【請求項１３】 前記初期プロトコルはログインプロト
    コルであり、 前記取得手段は、前記ログインプロトコルによるログイ
    ンが前記ホストからない場合、 前記ホストの固有の識別子を取得することを特徴とする
    請求項１０乃至１２のいずれか１項に記載のプリンタ。
14. 【請求項１４】 前記取得手段は、前記初期プロトコル
    による通信が所定の時間ない場合、前記ホストの固有の
    識別子を取得することを特徴とする請求項１０乃至１３
    のいずれか１項に記載のプリンタ。