JP2003051824A

JP2003051824A - 通信方法、通信システム、プログラム及び記憶媒体

Info

Publication number: JP2003051824A
Application number: JP2001240737A
Authority: JP
Inventors: Takuya Tsujimoto; 卓哉辻本
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2001-08-08
Filing date: 2001-08-08
Publication date: 2003-02-21

Abstract

(57)【要約】【課題】タイムアウトによる紙やインク（トナー）や
時間の無駄を省くことや、いたずらに時間を費やすこと
なく次のリクエストに応える等、再接続に最適な操作を
行うことが可能で、また、通信途中で該当するデバイス
が取り外されてもセッションの中断が起こらない通信方
法、通信システム、プログラム及び記憶媒体を提供す
る。【解決手段】通信途中でバスリセットが発生してもそ
のバスリセットの発生原因によってコネクションを回復
するまでの時間をＰＣ４０３により変更する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、通信装置、特にＩ
ＥＥＥ１３９４の規格に準拠したインタフェースを介し
て通信を行う装置で構成される通信システムにおいて、
バスに接続された装置間の通信がバスリセット後も自動
的に再開される通信方法、通信システム、プログラム及
び記録媒体に関する。

【０００２】

【従来の技術】近年、シリアルバスインタフェースは、
信号線が少ないこと、ケーブルが細いこと、コネクタが
小さいこと、ＩＤ（識別子）やターミネータ等の設定が
不要なこと、活線挿抜が可能なこと、等時性のあるデー
タ転送（アイソクロナス転送）が可能なこと等の優れた
特長を持つことから脚光を浴びてきている。

【０００３】特に、ＩＥＥＥ１３９４で規定されるシリ
アルバスインタフェースは、動画像等の大容量データの
高速伝送が可能であること、バスアーキテクチャによっ
てメモリアクセスが可能であること、ホットプラグイン
やプラグアンドプレイが可能であること、及びピア・ツ
ー・ピア接続が可能であること等の特長を持つことによ
って、パーソナルコンピュータのみならず家庭内のＡＶ
（オーディオビジュアル）機器（ディジタルビデオカメ
ラ等）やそれ以外の機器（ＢＳディジタル放送用チュー
ナー等）への適用も盛んに進められている。また、更な
る高速化や長距離化に対応した規格（Ｐ１３９４．ｂ）
も策定された。

【０００４】ＩＥＥＥ１３９４インタフェース上の上位
のプロトコルとしては、様々なものが規格化、提案され
ているが、ＰＣ（パーソナルコンピュータ）とその周辺
機器（プリンタ、スキャナ、ハードディスク等の各種記
憶装置等）との間では、ＳＢＰ−２（ＳｅｒｉａｌＢ
ｕｓＰｒｏｔｏｃｏｌ２）と呼ばれるトランスポート
層が定義されており、更に、その上位にアプリケーショ
ン毎のプロトコルやコマンドが定義されている。

【０００５】例えば、ＰＣとプリンタとの間ではＳＢＣ
−２の上にＳＣＳＩコマンドや、ＰＰＤＴ（Ｐｅｅｒ
ｔｏＰｅｅｒＤａｔａＴｒａｎｓｐｏｒｔ）を乗
せた組み合わせでプリントを実現させる仕組みなどが用
意されている。そこでは通信途中にバスリセットが発生
した場合、それまで通信を行っていたデバイスを特定
後、データ転送を再開する仕組みが用意されているもの
もある。

【０００６】このような再開手段が用意されていない場
合は、印字過程は全て最初からやり直しとなり、プリン
タへの印字であれば、それまでの印字に要した時間、イ
ンク（トナー）、用紙等に大きな無駄を生じることにな
る。

【０００７】通信の再開には、バスに接続されているデ
バイスの特定が必須となるが、以下にデバイスを特定す
るための手順を説明する。

【０００８】ＩＥＥＥ１３９４で規定されたインタフェ
ースを備えたデバイスは、コネクタの活線挿抜、電源の
ＯＮ／ＯＦＦ等が行われると、バスリセット信号と呼ば
れる特定の信号を発生し、ツリー識別と呼ばれるプロセ
スを実行する。

【０００９】図８は、従来のツリー識別を実行した直後
のシステム構成の一例を示す図である。

【００１０】尚、ＩＥＥＥ１３９４では、接続されるデ
バイスをノードと呼んでいる。

【００１１】図８において、８０１はノードＡであり、
ポート０（ｐ０）とポート１（ｐ１）の２つのＩＥＥＥ
１３９４インタフェースポートを有していることを示し
ている。８０２，８０３はそれぞれノードＢ、ノードＣ
であり、各々３つのＩＥＥＥ１３９４インタフェースポ
ートを有している。８０４，８０５，８０６はそれぞれ
ノードＤ、ノードＥ、ノードＦであり、各々１つのＩＥ
ＥＥ１３９４インタフェースポートを有している。

【００１２】ノードＡ８０１のポート０はノードＢ８０
２のポート０に接続されており、ツリー識別プロセスに
よってノードＡがノードＢの親ノードとなり、逆にノー
ドＢはノードＡの子ノードの関係となっている。

【００１３】同様に各ノード間で図８に示されるような
親子関係が決定する。

【００１４】ツリー識別プロセス終了後に各ノードは自
己識別プロセスを実行する。これは、Ｐｈｙｓｉｃａｌ
_ＩＤと呼ばれるノード固有番号を各ノードに選択する
機会を与え、接続されている任意のノードに自らのノー
ドを識別させるものである。

【００１５】具体的には下記の手順に従って、セルフＩ
Ｄパケットをバスに接続されている全てのノードに対し
て送信する。自己識別プロセスは決定論的な選択プロセ
スを採用しており、ルートノードが最小番号を持つ接続
ポートに接続されたノードに制御権を渡し、そのノード
が自身と自身の全ての子ノードがセルフＩＤパケットを
送信するまで待機する。その後ルートノードは、次の番
号を持つポートに接続されたノードに制御権を渡し、そ
のノードの処理が終了するのを待つ。

【００１６】このように、ルートノードの全てのポート
に接続されたノードが処理を終了すると、ルート自身が
自己識別を行う。子ノードも同様なプロセスを再帰的に
行う。

【００１７】図８に示す例では、ノードＤ８０４、ノー
ドＢ８０２、ノードＥ８０５、ノードＦ８０６、ノード
Ｃ８０３、ノードＡ８０１の順でセルフＩＤパケットを
送信する。

【００１８】図９は、従来の自己識別プロセス中に送信
されるセルフＩＤパケットのフォーマットの一例を示す
図である。その詳細説明については省略するが、セルフ
ＩＤパケットは、デバイスの物理的なＩＤ番号、サポー
トする通信速度、電力に関する能力、ポートの接続状態
等を表わす内容を含んでいる。ここでいうＰｈｙｓｉｃ
ａｌ_ＩＤは、自ノードがセルフＩＤパケットを送信す
る以前に、他ノードから受信したセルフＩＤパケットの
数となる。

【００１９】以上より、先に示したセルフＩＤパケット
送信の順序から、ノードＡ８０１のＰｈｙｓｉｃａｌ_
ＩＤは５、以後ノードＢ８０２は１、ノードＣ８０３は
４、ノードＤ８０４は０、ノードＥ８０５は３、ノード
Ｆ８０６は２となる。

【００２０】ここまではバスの構成に関する情報の取得
に関するもので、個々のデバイスの持つ機能、サービス
については、下記のプロセスによって得ることが可能で
ある。

【００２１】具体的には、各ノードが実装しているコン
フィギュレーションＲＯＭと呼ばれる領域をリードトラ
ンザクションで読むことによって実現する。

【００２２】図１０は、従来のコンフィギュレーション
ＲＯＭのフォーマットの一例を示す図である。例えば、
その中のＢｕｓ_Ｉｎｆｏ_Ｂｌｏｃｋ（オフセット値４
０４ｈ）の内容からは以下のような情報を得ることがで
きる。

【００２３】ｉｒｍｃビットは、アイソクロナス・リソ
ース・マネージャ機能を有するデバイスである場合に１
に、同機能を有さない場合に０にセットされる。ｃｍｃ
ビットはサイクルマスタ機能を、Ｉｓｃビットはアイソ
クロナス動作機能を、ｂｍｃビットはバス・マネージャ
機能をそれぞれ有するデバイスである場合に１に、機能
を有さない場合に０にセットされる。４０Ｃｈ及び４１
０ｈに格納されたｎｏｄｅ_ｖｅｎｄｏｒ_ｉｄ及びｃｈ
ｉｐ_ｉｄからは、ベンダーＩＤとチップＩＤがわか
り、これらを合わせた６４ビットで構成されるＥＵＩ６
４の値はユニークであるため、デバイスの絶対的な識別
にも用いられる。

【００２４】また、Ｕｎｉｔ_Ｄｉｒｅｃｔｏｒｙ（オ
フセット値４２８ｈ）のｕｎｉｔ_ｓｐｅｃ_ｉｄエント
リや、ｕｎｉｔ_ｓｗ_ｖｅｒｓｉｏｎエントリは、Ｍｉ
ｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）によっ
て認識することが可能なサービスを定義している。その
他、様々な機能の有無、サービスの種類を示すフィール
ドが用意されているが、ここでは、それらの詳細につい
ての説明は省略する。

【００２５】これらデバイス情報取得のためのコンフィ
ギュレーションＲＯＭのリードトランザクションは、ク
ワドレット単位（４ｂｙｔｅｓ単位）で行われる。

【００２６】以上のように、ツリー識別、自己識別及び
コンフィギュレーションＲＯＭリードの各プロセスを実
行することによって、バスの構成情報であるデバイスの
接続状況及びデバイス情報を取得し、それを基に各種マ
ップやデバイス機能等の情報を把握することが可能とな
る。

【００２７】通信の再開には、上記の手順でバスに接続
されているバス構成情報を把握し、それまで通信してい
た相手を特定する必要がある。その場合バスリセット発
生前まで通信を行っていたデバイスとの間のセッション
を一定時間保持し、その時間内にコネクション（論理的
な接続）が回復した場合はデータ転送を再開し、回復で
きなかった場合はセッションを切断するのが通例であ
る。

【００２８】これは、規定時間を設けずにバスリセット
の発生によって必ずセッションを切断すれば通信の再開
を行うことが不可能であることと、時間を規定せずにセ
ッションを保持し続けようとした場合は、仮に相手側の
デバイスがバスから取り外されていれば、セッションを
保持しているデバイスをリセットしてセッションを切断
する以外には、永久に他のデバイスとのセッションを形
成することができないことからも自明である。また、バ
スリセット後に通信を行っていた相手デバイスがバス上
に存在しない場合には、セッションを切断するといった
方法も採られている。

【００２９】従来の通信システムにおける通信途中のバ
スリセットの発生からコネクションを回復するまでの動
作について、図１１のフローチャートを用いて説明す
る。

【００３０】まず、ステップ１１０１では、データ転送
途中にバスリセットが発生したか否かを判断する。そし
て、バスリセットが発生しないと判断された場合は、何
も処理せずに本処理動作を終了し、また、バスリセット
が発生したと判断された場合は、次のステップＳ１１０
２へ進む。

【００３１】ステップ１１０２では、ツリー識別プロセ
スを実行した後、次のステップＳ１１０３へ進む。尚、
前記ステップＳ１１０２において実行されるツリー識別
プロセスの内容については、先に説明しているため、こ
こでの詳細な説明は省略する。

【００３２】ステップ１１０３では、自己識別プロセス
を実行した後、次のステップＳ１１０４へ進む。前記ス
テップＳ１１０３において実行される自己識別プロセス
とは、具体的にはＰＨＹコントローラからブロードキャ
ストで送信されるセルフＩＤパケットを受信し、格納す
るものである。

【００３３】ステップ１１０４では、セッションを保持
し続ける時間を監視するためのタイマを起動した後、次
のステップＳ１１０５へ進む。

【００３４】ステップ１１０５では、１３９４バスに接
続されている他のデバイスがどのような能力、機能、サ
ービスを有するノードであるかを探索するため、各デバ
イスが実装しているコンフィギュレーションＲＯＭ情報
を、リードトランザクションによって読み込む。

【００３５】次に、ステップ１１０６で、それまでに得
られたバス構成情報に基づき、バスリセット発生以前に
通信していたデバイスがバス上に存在しているか否かを
判断する。そして、通信相手がバス上に存在すると判断
された場合はステップ１１０７へ、また、通信相手がバ
ス上に存在しないと判断された場合はステップ１１０８
へそれぞれ進む。

【００３６】ステップ１１０７では、セッション保持中
にリコネクト（論理的な接続の回復動作）されたか否か
を判断する。そして、リコネクトされたと判断された場
合はステップ１１０９へ、また、リコネクトされずタイ
ムアウトが発生したと判断された場合はステップ１１１
０へそれぞれ進む。

【００３７】ステップ１１０８では、通信相手がバス上
に存在しないことを受けて保持していたセッションを切
断する。合わせて前記ステップ１１０４において起動し
たセッション保持を監視するためのタイマを停止する。

【００３８】また、ステップ１１０９では、セッション
が回復されたのを受けてデータ転送を再開する。

【００３９】また、ステップ１１１０では、セッション
が切断されたのを受けて、バスリセット以前に転送して
いたデータの破棄とそのデータ転送を行うタスクのリセ
ットを行う。

【００４０】前記ステップＳ１１０９及びステップ１１
１０の処理を終了後は、いずれも本処理動作を終了す
る。

【００４１】このように、通信途中でバスリセットが発
生した場合でも、データ転送が途中から再開できるよう
にするためには、通信相手のデバイスのバス上での存在
有無の把握や、通信を再開するまでに要する最大の時間
（タイムアウト値）を規定する等して、その後の対応を
行うようにしている。

【００４２】

【発明が解決しようとする課題】しかしながら上述した
従来例においては、以下のような問題があった。

【００４３】◇バスリセット後に通信を行っていた相手
デバイスがバス上に存在しない場合にセッションを切断
する方法を採用すると、当然のことながら通信中のデバ
イスが取り外された場合には通信の再開が行えない。

【００４４】また、採用する上位のプロトコルによって
規定される時間は異なるが、セッションを回復するまで
の時間を一律に定義することによって、以下のような問
題があった。

【００４５】◇ セッション回復までの時間を短めに設
定していると、万が一セッションを回復しようとしてい
るデバイスがバスから取り外されていた場合には、再度
バスに接続する前にセッションが切断されてしまう可能
性がある。これはユーザーの不注意等により通信中のデ
バイスのケーブルを誤って抜いてしまった場合等が該当
し、ケーブルを抜いてしまったことの認識や、その後に
行われる再度ケーブルを挿入する動作等、再接続に要す
る時間が電源投入等の通常のバスリセット発生時に比べ
てかなり長くかかるためである。

【００４６】◇通信中のデバイスのバスからの取り外し
を考慮してセッション回復までの時間を一律に長めに設
定していると、新たなデバイスのバスへの追加接続や通
信している以外のデバイスのバスからの取り外しや電源
投入及び電源ＯＦＦ等の場合には、一般にはそうあり得
ることではないが、仮にホストＰＣがビジーとなったよ
うな場合、その時間内に他のＰＣからプリンタに対して
リクエストがあっても、それに応えることができない。

【００４７】本発明は上述した従来技術の有する問題点
を解消するためになされたもので、その目的は、タイム
アウトによる紙やインク（トナー）や時間の無駄を省く
ことや、いたずらに時間を費やすことなく次のリクエス
トに応える等、再接続に最適な操作を行うことが可能
で、また、通信途中で該当するデバイスが取り外されて
もセッションの中断が起こらない通信方法、通信システ
ム、プログラム及び記憶媒体を提供することである。

【００４８】

【課題を解決するための手段】上記目的を達成するため
本発明の請求項１に記載の通信方法は、通信途中でバス
リセットが発生した場合そのバスリセットの発生原因に
よってコネクションを回復するまでの時間を変更する時
間変更ステップを有することを特徴とする。

【００４９】また、上記目的を達成するため本発明の請
求項２に記載の通信システムは、通信途中でバスリセッ
トが発生した場合そのバスリセットの発生原因によって
コネクションを回復するまでの時間を変更する時間変更
手段を有することを特徴とする。

【００５０】また、上記目的を達成するため本発明の請
求項３に記載の通信方法は、デバイスの電源投入時、新
たなデバイスの追加接続及びバスからのデバイス取り外
し時にバスを再構成するシリアルバスインタフェースを
伝送媒体として用いる通信方法において、バスリセット
発生時の発生原因を把握するための把握ステップと、通
信中のデバイス同士がバスリセット後も相手デバイスを
特定して通信を行うことを可能とする通信再開ステップ
と、前記把握ステップで把握したバスリセットの発生原
因によって予め規定されている相手デバイスとの通信再
開までの猶予時間を規定値から変更する変更ステップと
を有することを特徴とする。

【００５１】また、上記目的を達成するため本発明の請
求項４に記載の通信方法は、請求項３に記載の通信方法
において、前記シリアルバスインタフェースは、ＩＥＥ
Ｅ１３９４に準拠したものであることを特徴とする。

【００５２】また、上記目的を達成するため本発明の請
求項５に記載の通信方法は、請求項３に記載の通信方法
において、前記バスリセット発生原因把握ステップは、
バスリセット発生前後のバス構成情報の比較によって実
行されることを特徴とする。

【００５３】また、上記目的を達成するため本発明の請
求項６に記載の通信方法は、請求項５に記載の通信方法
において、前記バス構成情報は、デバイスの接続状況を
示すトポロジーマップ等の各種マップ及びデバイスの機
能やサービスを示すデバイス情報から構成されることを
特徴とする。

【００５４】また、上記目的を達成するため本発明の請
求項７に記載の通信方法は、請求項６に記載の通信方法
において、前記デバイスの接続状況は、バス構成時に各
デバイスから送出されるセルフＩＤパケットの取得及び
ツリー識別プロセスによって把握されることを特徴とす
る。

【００５５】また、上記目的を達成するため本発明の請
求項８に記載の通信方法は、請求項６に記載の通信方法
において、前記デバイスの機能やサービスを示すデバイ
ス情報は、各デバイスの持つコンフィギュレーションＲ
ＯＭ情報の取得によって得られることを特徴とする。

【００５６】また、上記目的を達成するため本発明の請
求項９に記載の通信方法は、請求項５に記載の通信方法
において、前記バス構成情報は、ＲＡＭ（ランダムアク
セスメモリ）等の揮発性のメモリに格納されることを特
徴とする。

【００５７】また、上記目的を達成するため本発明の請
求項１０に記載の通信方法は、請求項３に記載の通信方
法において、前記通信再開までの猶予時間変更の判断基
準となるバスリセットの発生原因とは、通信途中で相手
デバイスがバスから取り外されたことであることを特徴
とする。

【００５８】また、上記目的を達成するため本発明の請
求項１１に記載の通信方法は、請求項３または４に記載
の通信方法において、前記シリアルバスインタフェース
のトランスポート層は、ＳＢＰ−２（ＳｅｒｉａｌＢ
ｕｓＰｒｏｔｏｃｏｌ２）であることを特徴とする。

【００５９】また、上記目的を達成するため本発明の請
求項１２に記載の通信方法は、請求項３または４に記載
の通信方法において、前記通信再開ステップを実行する
デバイスは、ＰＣ（パーソナルコンピュータ）とプリン
タであることを特徴とする。

【００６０】また、上記目的を達成するため本発明の請
求項１３に記載の通信システムは、デバイスの電源投入
時、新たなデバイスの追加接続及びバスからのデバイス
取り外し時にバスを再構成するシリアルバスインタフェ
ースを伝送媒体として用いる通信システムにおいて、バ
スリセット発生時の発生原因を把握するための把握手段
と、通信中のデバイス同士がバスリセット後も相手デバ
イスを特定して通信を行うことを可能とする通信再開手
段と、前記把握手段で把握したバスリセットの発生原因
によって予め規定されている相手デバイスとの通信再開
までの猶予時間を規定値から変更する変更手段とを有す
ることを特徴とする。

【００６１】また、上記目的を達成するため本発明の請
求項１４に記載の通信システムは、請求項１３に記載の
通信システムにおいて、前記シリアルバスインタフェー
スは、ＩＥＥＥ１３９４に準拠したものであることを特
徴とする。

【００６２】また、上記目的を達成するため本発明の請
求項１５に記載の通信システムは、請求項１３に記載の
通信システムにおいて、前記バスリセット発生原因把握
ステップは、バスリセット発生前後のバス構成情報の比
較によって実行されることを特徴とする。

【００６３】また、上記目的を達成するため本発明の請
求項１６に記載の通信システムは、請求項１５に記載の
通信システムにおいて、前記バス構成情報は、デバイス
の接続状況を示すトポロジーマップ等の各種マップ及び
デバイスの機能やサービスを示すデバイス情報から構成
されることを特徴とする。

【００６４】また、上記目的を達成するため本発明の請
求項１７に記載の通信システムは、請求項１６に記載の
通信システムにおいて、前記デバイスの接続状況は、バ
ス構成時に各デバイスから送出されるセルフＩＤパケッ
トの取得及びツリー識別プロセスによって把握されるこ
とを特徴とする。

【００６５】また、上記目的を達成するため本発明の請
求項１８に記載の通信システムは、請求項１６に記載の
通信システムにおいて、前記デバイスの機能やサービス
を示すデバイス情報は、各デバイスの持つコンフィギュ
レーションＲＯＭ情報の取得によって得られることを特
徴とする。

【００６６】また、上記目的を達成するため本発明の請
求項１９に記載の通信システムは、請求項１５に記載の
通信システムにおいて、前記バス構成情報は、ＲＡＭ
（ランダムアクセスメモリ）等の揮発性のメモリに格納
されることを特徴とする。

【００６７】また、上記目的を達成するため本発明の請
求項２０に記載の通信システムは、請求項１３に記載の
通信システムにおいて、前記通信再開までの猶予時間変
更の判断基準となるバスリセットの発生原因とは、通信
途中で相手デバイスがバスから取り外されたことである
ことを特徴とする。

【００６８】また、上記目的を達成するため本発明の請
求項２１に記載の通信システムは、請求項１３または１
４に記載の通信システムにおいて、前記シリアルバスイ
ンタフェースのトランスポート層は、ＳＢＰ−２（Ｓｅ
ｒｉａｌＢｕｓＰｒｏｔｏｃｏｌ２）であることを
特徴とする。

【００６９】また、上記目的を達成するため本発明の請
求項２２に記載の通信システムは、請求項１３または１
４に記載の通信システムにおいて、前記通信再開ステッ
プを実行するデバイスは、ＰＣ（パーソナルコンピュー
タ）とプリンタであることを特徴とする。

【００７０】また、上記目的を達成するため本発明の請
求項２３に記載の通信方法は、デバイスの電源投入時、
新たなデバイスの追加接続及びバスからのデバイス取り
外し時にバスを再構成するシリアルバスインタフェース
を伝送媒体として用いる通信方法において、バスリセッ
ト発生時の発生原因を把握するための把握ステップと、
通信中のデバイス同士がバスリセット後も相手デバイス
を特定して通信を行うことを可能とする通信再開ステッ
プと、前記把握ステップで把握したバスリセットの発生
原因が通信途中で相手デバイスがバスから取り外された
場合その取り外されたデバイスが再度バスに接続される
ことを期待して予め規定されている相手デバイスとの通
信再開までの猶予時間内はセッションを維持する維持ス
テップとを有することを特徴とする。

【００７１】また、上記目的を達成するため本発明の請
求項２４に記載の通信方法は、請求項２３に記載の通信
方法において、前記シリアルバスインタフェースは、Ｉ
ＥＥＥ１３９４に準拠したものであることを特徴とす
る。

【００７２】また、上記目的を達成するため本発明の請
求項２５に記載の通信方法は、請求項２３に記載の通信
方法において、前記バスリセット発生原因把握ステップ
は、バスリセット発生前後のバス構成情報の比較によっ
て実行されることを特徴とする。

【００７３】また、上記目的を達成するため本発明の請
求項２６に記載の通信方法は、請求項２５に記載の通信
方法において、前記バス構成情報は、デバイスの接続状
況を示すトポロジーマップ等の各種マップ及びデバイス
の機能やサービスを示すデバイス情報から構成されるこ
とを特徴とする。

【００７４】また、上記目的を達成するため本発明の請
求項２７に記載の通信方法は、請求項２６に記載の通信
方法において、前記デバイスの接続状況は、バス構成時
に各デバイスから送出されるセルフＩＤパケットの取得
及びツリー識別プロセスによって把握されることを特徴
とする。

【００７５】また、上記目的を達成するため本発明の請
求項２８に記載の通信方法は、請求項２６に記載の通信
方法において、前記デバイスの機能やサービスを示すデ
バイス情報は、各デバイスの持つコンフィギュレーショ
ンＲＯＭ情報の取得によって得られることを特徴とす
る。

【００７６】また、上記目的を達成するため本発明の請
求項２９に記載の通信方法は、請求項２５に記載の通信
方法において、前記バス構成情報は、ＲＡＭ（ランダム
アクセスメモリ）等の揮発性のメモリに格納されること
を特徴とする。

【００７７】また、上記目的を達成するため本発明の請
求項３０に記載の通信方法は、請求項２３に記載の通信
方法において、前記通信再開までの猶予時間変更の判断
基準となるバスリセットの発生原因とは、通信途中で相
手デバイスがバスから取り外されたことであることを特
徴とする。

【００７８】また、上記目的を達成するため本発明の請
求項３１に記載の通信方法は、請求項２３または２４に
記載の通信方法において、前記シリアルバスインタフェ
ースのトランスポート層は、ＳＢＰ−２（Ｓｅｒｉａｌ
ＢｕｓＰｒｏｔｏｃｏｌ２）であることを特徴とす
る。

【００７９】また、上記目的を達成するため本発明の請
求項３２に記載の通信方法は、請求項２３または２４に
記載の通信方法において、前記通信再開ステップを実行
するデバイスは、ＰＣ（パーソナルコンピュータ）とプ
リンタであることを特徴とする。

【００８０】また、上記目的を達成するため本発明の請
求項３３に記載の通信システムは、デバイスの電源投入
時、新たなデバイスの追加接続及びバスからのデバイス
取り外し時にバスを再構成するシリアルバスインタフェ
ースを伝送媒体として用いる通信システムにおいて、バ
スリセット発生時の発生原因を把握するための把握手段
と、通信中のデバイス同士がバスリセット後も相手デバ
イスを特定して通信を行うことを可能とする通信再開手
段と、前記把握手段で把握したバスリセットの発生原因
が通信途中で相手デバイスがバスから取り外された場合
その取り外されたデバイスが再度バスに接続されること
を期待して予め規定されている相手デバイスとの通信再
開までの猶予時間内はセッションを維持する維持手段と
を有することを特徴とする。

【００８１】また、上記目的を達成するため本発明の請
求項３４に記載の通信システムは、請求項３３に記載の
通信システムにおいて、前記シリアルバスインタフェー
スは、ＩＥＥＥ１３９４に準拠したものであることを特
徴とする。

【００８２】また、上記目的を達成するため本発明の請
求項３５に記載の通信システムは、請求項３３に記載の
通信システムにおいて、前記バスリセット発生原因把握
ステップは、バスリセット発生前後のバス構成情報の比
較によって実行されることを特徴とする。

【００８３】また、上記目的を達成するため本発明の請
求項３６に記載の通信システムは、請求項３５に記載の
通信システムにおいて、前記バス構成情報は、デバイス
の接続状況を示すトポロジーマップ等の各種マップ及び
デバイスの機能やサービスを示すデバイス情報から構成
されることを特徴とする。

【００８４】また、上記目的を達成するため本発明の請
求項３７に記載の通信システムは、請求項３６に記載の
通信システムにおいて、前記デバイスの接続状況は、バ
ス構成時に各デバイスから送出されるセルフＩＤパケッ
トの取得及びツリー識別プロセスによって把握されるこ
とを特徴とする。

【００８５】また、上記目的を達成するため本発明の請
求項３８に記載の通信システムは、請求項３６に記載の
通信システムにおいて、前記デバイスの機能やサービス
を示すデバイス情報は、各デバイスの持つコンフィギュ
レーションＲＯＭ情報の取得によって得られることを特
徴とする。

【００８６】また、上記目的を達成するため本発明の請
求項３９に記載の通信システムは、請求項３５に記載の
通信システムにおいて、前記バス構成情報は、ＲＡＭ
（ランダムアクセスメモリ）等の揮発性のメモリに格納
されることを特徴とする。

【００８７】また、上記目的を達成するため本発明の請
求項４０に記載の通信システムは、請求項３３に記載の
通信システムにおいて、前記通信再開までの猶予時間変
更の判断基準となるバスリセットの発生原因とは、通信
途中で相手デバイスがバスから取り外されたことである
ことを特徴とする。

【００８８】また、上記目的を達成するため本発明の請
求項４１に記載の通信システムは、請求項３３または３
４に記載の通信システムにおいて、前記シリアルバスイ
ンタフェースのトランスポート層は、ＳＢＰ−２（Ｓｅ
ｒｉａｌＢｕｓＰｒｏｔｏｃｏｌ２）であることを
特徴とする。

【００８９】また、上記目的を達成するため本発明の請
求項４２に記載の通信システムは、請求項３３または３
４に記載の通信システムにおいて、前記通信再開ステッ
プを実行するデバイスは、ＰＣ（パーソナルコンピュー
タ）とプリンタであることを特徴とする。

【００９０】また、上記目的を達成するため本発明の請
求項４３に記載のプログラムは、通信システムを制御す
るためのコンピュータ読み取り可能なプログラムであっ
て、通信途中でバスリセットが発生してもそのバスリセ
ットの発生原因によってコネクションを回復するまでの
時間を変更する時間変更ステップをコンピュータに実行
させるためのプログラムコードから成ることを特徴とす
る。

【００９１】また、上記目的を達成するため本発明の請
求項４４に記載のプログラムは、デバイスの電源投入
時、新たなデバイスの追加接続及びバスからのデバイス
取り外し時にバスを再構成するシリアルバスインタフェ
ースを伝送媒体として用いる通信システムを制御するた
めのコンピュータ読み取り可能なプログラムであって、
バスリセット発生時の発生原因を把握するための把握ス
テップと、通信中のデバイス同士がバスリセット後も相
手デバイスを特定して通信を行うことを可能とする通信
再開ステップと、前記把握ステップで把握したバスリセ
ットの発生原因によって予め規定されている相手デバイ
スとの通信再開までの猶予時間を規定値から変更する変
更ステップとをコンピュータに実行させるためのプログ
ラムコードから成ることを特徴とする。

【００９２】また、上記目的を達成するため本発明の請
求項４５に記載のプログラムは、デバイスの電源投入
時、新たなデバイスの追加接続及びバスからのデバイス
取り外し時にバスを再構成するシリアルバスインタフェ
ースを伝送媒体として用いる通信システムを制御するた
めのコンピュータ読み取り可能なプログラムであって、
バスリセット発生時の発生原因を把握するための把握ス
テップと、通信中のデバイス同士がバスリセット後も相
手デバイスを特定して通信を行うことを可能とする通信
再開ステップと、前記把握ステップで把握したバスリセ
ットの発生原因が通信途中で相手デバイスがバスから取
り外された場合その取り外されたデバイスが再度バスに
接続されることを期待して予め規定されている相手デバ
イスとの通信再開までの猶予時間内はセッションを維持
する維持ステップとをコンピュータに実行させるための
プログラムコードから成ることを特徴とする。

【００９３】更に、上記目的を達成するため本発明の請
求項４６に記載の記憶媒体は、請求項４３乃至４５に記
載のプログラムを格納したことを特徴とする。

【００９４】

【発明の実施の形態】以下、本発明の各実施の形態を図
面に基づき説明する。

【００９５】（第１の実施の形態）まず、本発明の第１
の実施の形態を図１乃至図６に基づき説明する。

【００９６】図１は、本実施の形態に係る通信システム
におけるセッション回復処理動作の流れを示すフローチ
ャートである。ここではＰＣ（パーソナルコンピュー
タ）とプリンタとを例にとって、データ送信中に発生し
たバスリセットへの対応について、図１を用いて説明す
る。

【００９７】まず、ステップＳ１０１で、ＩＥＥＥ１３
９４インタフェース上に接続された本実施の形態に係る
通信システムを実現するデバイス本体の電源投入によっ
てバスリセットが発生する。ここでは、本実施の形態に
係る通信システムを実現するバス構成情報及びデバイス
情報を把握・管理するデバイスとしてＰＣを想定してい
る。このＰＣの構成については後述する。

【００９８】本実施の形態に係る通信システムを実現す
るデバイスとしては、ＰＣ以外の一般的な１３９４デバ
イスであっても良い。ＰＣの電源投入時には、オンボー
ド若しくは拡張スロットに挿入されたＩＥＥＥ１３９４
カードのＰＨＹコントローラに電力が供給され、バスリ
セットが発生する。

【００９９】一般に、ＰＣの場合はＯＳ（オペレーティ
ングシステム）の起動が電源投入によるバスリセットの
検知を受けるのに間に合わないことも少なくないため、
本実施の形態において説明しているバス構成情報やデバ
イス情報を取得・管理するためのプログラムが起動され
る際に、ソフト的にバスリセット（ソフトバスリセッ
ト）を発生させることで、以後のバス構成情報の把握動
作等に対応することができる。ここでは、そうしたプロ
グラム初期起動時のバスリセットの発生も該当する。

【０１００】次に、ステップＳ１０２で、バス構成情報
の把握プロセスを実行する。このバス構成情報の把握プ
ロセス処理の具体的な内容について、図３を用いて説明
する。

【０１０１】まず、ステップＳ３０１で、バス構成情報
の把握のうち、ツリー識別のプロセスを実行する。この
ツリー識別のプロセスについては、上述した従来例で説
明しているため、その詳細説明については省略する。

【０１０２】次に、ステップＳ３０２で、自己識別プロ
セスを実行する。この自己識別プロセスとは、具体的に
はＰＨＹコントローラからブロードキャストで送信され
るセルフＩＤパケットを受信し、格納することである。
この自己識別プロセスについては、上述した従来例で説
明しているため、その詳細説明については、同じく省略
する。

【０１０３】次に、ステップＳ３０３で、前記ステップ
Ｓ３０２における自己識別プロセス処理が終了して通常
のパケットを送信できる状態になった時に、１３９４バ
ス上に接続される他のデバイスがどのような能力、機
能、サービスを有するノードであるかを探索するため、
各デバイスが実装しているコンフィギュレーションＲＯ
Ｍに格納されている情報を、リードトランザクションに
よって読み込む。

【０１０４】前記コンフィグレーションＲＯＭは、ＩＳ
Ｏ／ＩＥＣ１３２１３で定義されているノードの持つ各
種情報を格納したもので、ミニマルフォーマット（Ｍｉ
ｎｉｍａｌＦｏｒｍａｔ）とゼネラルフォーマット
（ＧｅｎｅｒａｌＦｏｒｍａｔ）の２種類のフォーマ
ットが存在する。ミニマルフォーマットはメーカーを識
別するｎｏｄｅ_ｖｅｎｄｏｒ_ｉｄ情報のみを持ち、Ｒ
ＯＭサイズは４ｂｙｔｅｓである。ゼネラルフォーマッ
トは、それ以外に、Ｂｕｓ_ｉｎｆｏ_ＢｌｏｃｋとＲｏ
ｏｔ_Ｄｉｒｅｃｔｏｒｙの他、上述した従来例の図１
０で示したような各種追加情報を持つ。

【０１０５】ここでは１３９４バスに接続された各デバ
イスが、ゼネラルフォーマットのコンフィギュレーショ
ンＲＯＭを実装していると仮定し、情報取得のための複
数のリードトランザクションを実行するものとする。コ
ンフィギュレーションＲＯＭのリードがクワドレット単
位で行われることについては、上述した従来例で説明し
ているので、その詳細説明については省略する。

【０１０６】コンフィギュレーションＲＯＭのリードの
中で特に大切なのは、ユニークＩＤの取得である。ユニ
ークＩＤは、上述した従来例の図１０に示されるよう
に、オフセットアドレス４０Ｃｈ及び４１０ｈに格納さ
れている。ユニークＩＤは、２４ビットのベンダーＩＤ
と４０ビットのチップＩＤとから成り、これを合わせて
ＥＵＩ６４という。このＥＵＩ６４は、１３９４におい
てノードＩＤという動作状況（バスリセット）に応じて
動的に変化するものとは異なり、デバイス製造時に固定
的に割り振られたＩＤである。ベンダーＩＤはＩＥＥＥ
から割り振られ、製造するメーカーを表わす。チップＩ
Ｄは、ベンダーによって割り振ることができるもので、
シリアル番号や機種名の他、機能を示すビットとして使
用しても構わない。ユニークＩＤの取得は、４０Ｃｈ及
び４１０ｈへの２回のリードクワドレットトランザクシ
ョンによって実現される。

【０１０７】まず、コンフィギュレーションＲＯＭのオ
フセット値４０Ｃｈを示すアドレスに対してクワドレッ
トのリードトランザクションを行う。相手ノードから正
常なレスポンスが返り、情報を格納したら、続いてオフ
セット値４１０ｈを示すアドレスに対して同じくクワド
レットのリードトランザクションを行う。返ってきたレ
スポンスを合わせて格納することによって、ＥＵＩ６４
であるユニークＩＤの値をコンフィギュレーションＲＯ
Ｍから取得することができる。

【０１０８】尚、相手ノードがミニマルフォーマットの
コンフィギュレーションＲＯＭを実装している場合は、
最初のトランザクションのレスポンスがアドレスエラー
となるため、これによって格納すべき情報が無いことを
判断する。

【０１０９】次に、ステップＳ３０４で、前記ステップ
Ｓ３０２において受信して格納したセルフＩＤパケット
に含まれる情報からバス構成情報を、また、前記ステッ
プＳ３０３において読み込んだ各デバイスのコンフィギ
ュレーションＲＯＭに格納されている情報から本デバイ
スにとって必要な情報を、それぞれ把握する。

【０１１０】本デバイスにとって必要な情報とは、例え
ば、１３９４ノードとしての能力、サポートしているプ
ロトコル、デバイスの種類、ベンダー（メーカー）名、
機種名、使用可能なサービス、ユニークＩＤ等である。

【０１１１】バス構成情報の把握は、具体的にはノード
ＩＤの把握・管理や各種マップの作成によって行われ
る。一般に、マップ作成を行う機能を有するノードは、
バス・マネージャノード若しくはアイソクロナス・リソ
ース・マネージャノードであるが、ここではバス上にそ
れらの機能を有するノードが他に存在するか否かに関係
なく情報を把握するものとする。

【０１１２】ここで、トポロジーマップの作成方法につ
いて説明する。その説明にあたっては、上述した従来例
の説明で使用した図８を用いる。バスに接続されるデバ
イスの中でバス・マネージャ若しくはアイソクロナス・
リソース・マネージャと呼ばれるトポロジーの構築プロ
セス機能（トポロジーマップ作成機能）を有するノード
は、セルフＩＤパケットからバスのトポロジーを推定す
ることが可能である（本実施の形態では、それ以外のノ
ードであっても構わない。）ノードＤ８０４、ノードＥ
８０５及びノードＦ８０６は、それぞれ図８に示すセル
フＩＤパケット内のｐ０＝１０、ｐ１＝００、ｐ２＝０
０であるセルフＩＤパケットを送信するため、ポート０
のみ有し、親ノードに接続されているリーフノードであ
ることがわかる。ノードＢ８０２は、ｐ０＝１０、ｐ１
＝１１、ｐ２＝０１であるセルフＩＤパケットを送信す
るため、ポート０は親ノードに、ポート１は子ノードに
接続され、ポート２は接続されていないブランチノード
であることがわかる。更に、上述した決定論的プロセス
に従っているため、ポート１はノードＤ８０４に接続さ
れていることがわかる。ノードＣ８０３は、ｐ＝１０、
ｐ１＝１１、ｐ２＝１１であるセルフＩＤパケットを送
信するため、ポート０は親ノードに、ポート１とポート
２は子ノードに接続されているブランチノードで、更
に、ノードＢ８０２と同様に、ポート１はノードＥ８０
５に、ポート２はノードＦ８０６に接続されていること
がわかる。最後に、ノードＡ８０１は、ｐ０＝１１、ｐ
１＝１１、ｐ２＝００であるセルフＩＤパケットを送信
するため、ポート０とポート１は子ノードに接続されて
おり、ポート２は存在しないブランチノードで、ポート
０はノードＢ８０２に、ポート１はノードＣ８０３に接
続されていることがわかる。

【０１１３】以上の推論によってバスに接続されている
各デバイスの構成状態を把握することが可能となる。

【０１１４】また、同様に、セルフＩＤパケット内の通
信速度を示すｓｐフィールドの値からスピードマップ
を、電力情報を示すｐｗｒフィールドの値から電力マッ
プを、それぞれ作成することが可能である。

【０１１５】本実施の形態では各種マップを作成する構
成としているが、バス構成情報として本件で重要なのは
ノードＩＤであるため、ノードＩＤの把握、管理のみを
行っても良い（各種マップの作成については行わなくて
も良い。）。

【０１１６】再び図１に戻って、ステップＳ１０３で、
前記ステップＳ１０２において把握したバス構成情報及
びデバイス情報をそれぞれ格納する。格納場所として
は、ここではＰＣの持つメモリ（ＲＡＭ：ランダムアク
セスメモリ）を想定している。各種情報が格納されてい
るか否かを示すフラグを用意して、以後の処理を行い易
くしても良い。

【０１１７】次に、ステップＳ１０４で、ＰＣが１３９
４バス上の特定のプリンタを占有して印字を行うために
Ｌｏｇｉｎコマンドを発行し、セッションを形成する。
ここでは、ＳＢＰ−２のトランスポート層を使用してデ
ータの送受信を行うものとする。

【０１１８】次に、ステップＳ１０５で、セッション形
成後にＰＣ上にある印字データをプリンタに対して転送
するトランザクションを開始する。具体的には、印字デ
ータは、プリンタ側からのリードトランザクションによ
ってＰＣからプリンタへと転送される。

【０１１９】次に、ステップＳ１０６で、印字データ及
び制御用コマンドの転送開始後にバスリセットが発生し
たか否かを判断する。バスリセットは、一般に、新たな
デバイスをバスに接続した場合、バスに接続されている
デバイスを取り外した場合、既にバスに接続されている
デバイスの電源を落とした場合、その逆にもともとバス
に接続されていて電源が投入されていないデバイスの電
源を入れた場合及びソフト的にバス構成をリフレッシュ
させようとした場合等に発生する。バスリセットが発生
したことを検知した場合はステップＳ１０８へ、発生し
なかった場合はステップＳ１０７へそれぞれ進む。

【０１２０】ステップＳ１０７では、印字データの転送
が終了してセッションが切断されたか否かを判断する。
そして、データ転送が終了していない場合は前記ステッ
プＳ１０６へ戻って再びバスリセットの発生を監視す
る。また、データ転送が終了した場合は本処理動作を終
了する。そして、再び印字を開始する場合は、セッショ
ンを形成するステップＳ１０４から実行することにな
る。

【０１２１】ステップＳ１０８では、バスリセットの発
生を受けて図３のステップＳ３０１、ステップＳ３０２
と同じくツリー識別プロセス及び自己識別プロセスを実
行する。このプロセスの説明は、図３のステップＳ３０
１、ステップＳ３０２と同じであるため省略する。

【０１２２】次に、ステップＳ１０９で、前記ステップ
Ｓ１０４において形成したセッションを回復するまでの
猶予時間を監視するためのタイマを起動する。ここで
は、タイマで監視される時間はプロトコルによって一意
に規定されているものとする。タイマは、専用及び汎用
のハードウェアタイマでもソフトウェアタイマでも構わ
ない。

【０１２３】次に、ステップＳ１１０で、前記図３のス
テップＳ３０３と同じくコンフィギュレーションＲＯＭ
のリードプロセスを実行する。このリードプロセスの説
明は、前記図３のステップＳ３０３と同じであるため、
ここでは省略する。

【０１２４】次に、ステップＳ１１１で、バスリセット
の発生を受けて、このバスリセットの発生要因を把握す
る。この判断は、図９に示されるセルフＩＤパケット内
のｉビット（ｉｎｉｔｉａｔｅｄ_ｒｅｓｅｔｂｉｔ）
がセットされているか否か、バスリセット発生以前のバ
ス構成（どのようなデバイスがバスに接続されている
か）との比較等によって行われる。

【０１２５】次に、図２のステップＳ１１２で、セッシ
ョン保持中のデバイスが１３９４バス上に存在するか否
かを判断する。前記１のステップＳ１１１において行わ
れるバスリセット要因の把握の結果、該当する１３９４
デバイスがバス上に存在しない場合、つまりＰＣとのセ
ッションを保持しているプリンタデバイスがバスから取
り外されていた場合はステップＳ１１３を介してステッ
プＳ１１４へ、他の要因でバスリセットが発生した場合
は直接ステップＳ１１３へそれぞれ進む。

【０１２６】ステップＳ１１３では、通信相手のデバイ
スであるプリンタがバスから取り外されている、若しく
はプリンタデバイスが接続されている１３９４バスから
自身のデバイス（ＰＣ）が取り外されたと判断されたこ
とを受けて、セッションを回復するまでの猶予時間を監
視するタイマを一旦停止し、タイマ値を変更した後に再
度タイマを起動する。これは何らかのトラブルによって
通信中のＰＣとプリンタが同じ１３９４バス上に存在し
ない場合、再び接続がなされ印字を再開することが期待
されることを手助けする意味がある。つまり、通常の猶
予時間内にセッションを回復することが一般には難しい
ためで、ここでは、規定の猶予時間より長い時間を設定
することにより、ユーザーは、デバイスが取り外された
ことを認識してから再度ケーブルを挿入するまでの十分
な時間が得られることになる。

【０１２７】ステップＳ１１４では、セッション保持中
のデバイスがバス上に存在することを受けて、タイマが
監視する猶予時間のタイムアウト前に再びバスリセット
が発生したか否かを判断する。再度のバスリセット発生
は、フォースルートパケット送信や１３９４バス上で特
定の機能を持つノードとなれなかったデバイスがソフト
リセットを発生させた場合等に現れる。再びバスリセッ
トが発生した場合は前記図１のステップＳ１０８へ戻
り、以後同様の操作を繰り返す。また、タイムアウト前
にバスリセットが発生しなかった場合は次のステップＳ
１１５へ進む。

【０１２８】ステップＳ１１５では、タイムアウトが発
生したか否かを判断する。そして、タイムアウトが発
生、つまり規定時間内にセッションを回復できなかった
場合にはステップＳ１１６へ、また、タイムアウト以前
にセッションの回復を行うことができた場合はステップ
Ｓ１１８へそれぞれ進む。このフローチャートではタイ
ムアウトが発生したかどうかを確認しているが、同時に
タイムアウトまでにセッションが回復されたか否かも監
視している。また、前記ステップＳ１１４において再度
のバスリセットを監視している間にセッションが回復さ
れたか否かも監視している。つまり、規定時間内にバス
リセットが発生せず、セッションが回復された場合はス
テップＳ１１８へ進むことになる。

【０１２９】ステップＳ１１６では、規定時間内にセッ
ションが回復できなかったのを受けて、ＰＣ側ではプリ
ンタドライバによって生成された送信途中の印字データ
をクリアする。プリンタ側では、それまで受信していた
データの破棄や途中まで印字していた用紙の排出を行
い、この印字に関わる全てのジョブをクリアにする。

【０１３０】次に、ステップＳ１１７で、印字データの
クリアを受けて、ユーザーから要求のあったプリント要
求を実行することができなかったことを伝える。具体的
には、ＰＣの持つ表示装置等に印字中止を伝えるダイア
ログを表示したり、同じくＰＣの持つスピーカ等を通じ
て音により伝えたりする。

【０１３１】一方、ステップＳ１１８では、セッション
の回復を受けて、リコネクトの手続きを行う。ＰＣで
は、合わせて猶予時間を監視しているタイマを停止す
る。

【０１３２】次に、ステップＳ１１９で、前記図１のス
テップＳ１０６において検知したバスリセットの発生前
の状態に戻ったことを受けて、データの送信を再開す
る。再度通信途中でバスリセットが発生した場合は前記
図１のステップＳ１０６からの処理を繰り返す。

【０１３３】図４は、本実施の形態に係る通信システム
における１３９４バスの構成例を示す図である。

【０１３４】同図において、４０１から４０６はＩＥＥ
Ｅ１３９４の規格に準拠した各種デバイスであり、４０
１及び４０３はＰＣ、４０２はハードディスクドライ
ブ、４０４はプリンタ、４０５はＭＯドライブ、４０６
はＣＣＤカメラの各１３９４デバイスをそれぞれ示して
いる。デバイス間は図に示されるようにシリアルのケー
ブルで接続されている。図１及び図２で説明したプリン
トデータの転送を行うデバイスを、ここでは、ＰＣ４０
３とプリンタ４０４と仮定する。

【０１３５】図５は、本実施の形態に係る通信システム
におけるＰＣの概略構成を示すブロック図である。

【０１３６】同図において、５０１はＩＥＥＥ１３９４
シリアルバスに接続可能なデバイス（ノード）であり、
ここではＰＣを想定している。デバイス５０１は、以下
に示す５０２から５０８の各種ブロック及び不図示の電
源等によって構成されている。

【０１３７】５０２はＣＰＵ（中央制御装置）で、後述
するハードディスクドライブ５０３及びＲＡＭ５０４に
格納されたプログラムに従って各部を制御するものであ
る。本実施の形態に係る通信システムの機能の一部を実
現するプログラムはＣＰＵ５０２によって実行される。

【０１３８】５０３はハードディスクドライブ（ＨＤ
Ｄ）で、ＣＰＵ５０２が読み出す本実施の形態に係る通
信システムの機能の一部を実現するプログラムが格納さ
れているものである。ここではハードディスクドライブ
を想定しているが、不揮発性の記憶媒体及びその記憶媒
体を使用した装置であれば、その種類は問わない。例え
ば、ＦＤ、ＭＯ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、フラッ
シュメモリ、テープデバイス等が該当する。

【０１３９】５０４はＲＡＭ（ランダムアクセスメモ
リ）で、必要に応じてＣＰＵ５０２がデータの書き込み
や読み出しを行ったり、ダイレクトメモリアクセスによ
って後述する１３９４のＬＩＮＫコントローラ５１７か
らデータを読み出して格納したり、逆にデータを読み込
んでＬＩＮＫコントローラ５１７へデータを書き込んだ
りするためのメモリである。

【０１４０】５０５はハードウェアタイマ（タイマ）
で、必要に応じてＣＰＵ５０２による計時や、カレンダ
ー・時計機能を実現するために、日付、曜日、時刻等の
読み出し等に使用されるものである。また、本実施の形
態においては、保持しているセッションを維持する時間
を監視するタイマとして使用しても構わない。

【０１４１】５０６は入力デバイス制御部で、ユーザー
インタフェースにとって重要な後述するキーボードやマ
ウス等の各種入力デバイス５０９を制御するものであ
る。入力デバイス５０９とＰＣ５０１との間のインタフ
ェースは、ＰＳ／２やＵＳＢ等のシリアルインタフェー
スが用いられる。また、音声を入力手段として考えるこ
とも可能である。

【０１４２】５０７は表示装置制御部で、後述する表示
装置５１０へ送る信号の生成や変換等を行うものであ
る。５０８は音源制御部で、ＣＰＵ５０２によって制御
され、音声信号の増幅や、後述するスピーカ５１１へ出
力する信号を切り替えるものである。１３９４経由で送
信された音声情報、音楽データ等を、後述するシステム
バス５２１を介して受け取る。

【０１４３】５０９はユーザーからの指示を伝える入力
デバイスである。ここでは、キーボードやマウスを想定
している。５１０は、ブラウン管や液晶等によって構成
される表示装置（モニタ）である。５１１はスピーカ等
の音声出力装置で、音源制御部５０８からの音声信号を
出力するものである。５１２は１３９４インタフェース
の機能を持つ１３９４カードで、以下に示す５１３から
５２０の各構成要素からなる。また、１３９４カード５
１２は、ＰＣＩやＰＣＭＣＩＡ等のインタフェースによ
ってＰＣ５０１と接続される。ここではカードの形態を
考えたが、拡張ではなくオンボードで構成される形態を
とっても構わない。

【０１４４】５１３，５１４，５１５は１３９４バスと
ＰＣ５０１とを接続するための１３９４ポートである。
この装置（１３９４カード５１２）では3つのポートを
持つものとする。

【０１４５】５１６はＰＨＹレイヤ若しくはフィジカル
レイヤ（物理層）と呼ばれるＩＥＥＥ１３９４インタフ
ェース上の信号を直接ドライブする機能を実現するＰＨ
Ｙコントローラである。ＩＥＥＥ１３９４に準拠した１
００Ｍｂｐｓ〜４００Ｍｂｐｓの転送スピードをサポー
トする物理レイヤを実現し、各種のハードウェアロジッ
ク（ＬＩＮＫコントローラ５１７とのインタフェース、
パケットデータのシンクロナイズと再構成、ビットレベ
ルのアービトレーション、タイマ等）によって構成され
る。また、バスの構成を行うためのツリー識別プロセス
を実行する。

【０１４６】５１７はＬＩＮＫレイヤ（リンク層）の機
能を実現するＬＳＩによって構成されるＬＩＮＫコント
ローラである。各種パケットの受信、送信処理やＰＣ５
０１とのインタフェースを有する。デバイス情報を取得
するためのコンフィギュレーションＲＯＭへのリードリ
クエスト及びレスポンスパケットの受信等はここで行わ
れる。

【０１４７】５１８はＩＥＥＥ１３９４のアイソクロナ
ス転送専用に使用するバッファメモリで、後述するＦＩ
ＦＯ制御部５１９によって制御され、ＬＩＮＫコントロ
ーラ５１７からのアイソクロナスデータを一時格納し、
格納した順に後述するＣＯＤＥＣ５２０へ送出するため
のＦＩＦＯである。

【０１４８】５１９はＦＩＦＯ５１８へのアイソクロナ
スデータの格納や引き出しを制御するＦＩＦＯ制御部で
ある。５２０はＦＩＦＯ５１８から引き出されたアイソ
クロナスデータを所定方式で符号化/復号化するための
ＣＯＤＥＣ（ＣＯＤＥＲ/ＤＥＣＯＤＥＲ）である。５
２１はＰＣ５０１のシステムバス（ＣＰＵバス）であ
る。１３９４カード５１２からのデータは、このシステ
ムバス５２１を介してＣＰＵ５０２やＲＡＭ５０４及び
ハードディスクドライブ５０３へ転送される。

【０１４９】５２２はＩＥＥＥ１３９４インタフェース
のバスである。このバス５２２上に存在するノードとケ
ーブルによって接続される。このケーブル内には２組の
ツイストペアケーブル（一方がＡ、他方がＢと称される
信号線）と1組の電源ペアケーブルの合わせて６本のケ
ーブルがクロスしている。また、電源ラインの無い４本
のケーブルで構成されているものも存在する。

【０１５０】このようにＰＣ５０１は、１３９４インタ
フェースコントロール部の他、本実施の形態に係る通信
システムを実現するための制御プログラムを実行する処
理装置とプログラムを格納する記憶装置等によって構成
される。

【０１５１】図６は、本実施の形態に係る通信システム
におけるプリンタの概略構成を示すブロック図である。

【０１５２】同図において、６０１はＩＥＥＥ１３９４
インタフェースの規格に対応するデバイスで、ここでは
プリンタ機能を持ったデバイス（プリンタ）を想定す
る。プリンタ（デバイス）６０１は、図６に示されるよ
うに、以下に説明される６０３から６０６までの各種ハ
ードウェア、６０７から６１２までの各１３９４レイ
ヤ、プリンタ機能６１３等によって構成される。

【０１５３】６０２はＩＥＥＥ１３９４インタフェース
のバスである。このバス６０２上に存在するノードとケ
ーブルとによって接続される。６０３はＣＰＵ（中央制
御装置）で、ＲＯＭ６０４及びＲＡＭ６０５に格納され
たプログラムに従って各部を制御するものである。６０
４はＲＯＭ（リードオンリーメモリ）で、ＣＰＵ６０３
が読み出すプログラムが格納されているメモリである。
６０５はＲＡＭ（ランダムアクセスメモリ）で、受信し
たプリントデータの格納や展開等に使用されるメモリで
ある。

【０１５４】６０６はハードウェアタイマである。本実
施の形態においては、このハードウェアタイマ６０６
を、保持しているセッションを維持する時間を監視する
タイマとして使用しても構わない。６０７はインタフェ
ース制御部で、ＰＨＹレイヤ若しくはフィジカルレイヤ
（物理層）と呼ばれるＩＥＥＥ１３９４インタフェース
上の信号を直接ドライブする機能を実現するＬＳＩと、
ＬＩＮＫレイヤ（リンク層）の機能を実現するＬＳＩと
によって構成される。そして、インタフェース制御部６
０７は、送信側ノードから送られてきたプリントデータ
の受信処理やバスの構成等を行う。

【０１５５】６０８はドライバで、トランザクションレ
イヤと呼ばれる（一部リンクレイヤの機能も含む）ＩＥ
ＥＥ１３９４インタフェースに対して実際のオペレーシ
ョンを管理・実行するものである。このトランザクショ
ンレイヤは、ＩＥＥＥ１３９４インタフェース上で行わ
れるアシンクロナス転送のリード/ライト/ロックの各ト
ランザクションを管理・制御する。また、受信側ノード
がビジーの場合の再送（リトライ）要求も、このトラン
ザクションレイヤで管理する。

【０１５６】６０９はシリアルバスマネージメント（Ｓ
ＢＭ）を行うレイヤで、ＩＥＥＥ１３９４インタフェー
スの管理用ドライバによって構成されるノードコントロ
ーラである。機能としてはＣＳＲ（コントロールアンド
ステータスレジスタ）及びコンフィグレーションＲＯＭ
の実装・管理を行う。また、セルフＩＤパケットの受信
に伴う他ノード情報の管理も取り扱う。ＳＢＭは、ノー
ドコントローラ以外の機能としてアイソクロナスリソー
スマネージャ及びバスマネージャの機能を持つことが可
能であるが、オプションであるため、プリンタ６０１で
はその機能は有さないものとする。プリンタ６０１はゼ
ネラルフォーマットを持つ。

【０１５７】６１０はＳＢＰ−２（ＳｅｒｉａｌＢｕ
ｓＰｒｏｔｏｃｏｌ２）制御部で、１３９４上に複数
存在するプロトコルのうち、ＳＢＰ−２に対応した制御
を行うための制御部である。ＳＢＰ−２は、１３９４に
適したトランスポートプロトコルで、更に上位で定義さ
れたコマンドセットのためのフレームワークを提供して
いる。通信を行うデバイス間の構造は、Ｉｎｉｔｉａｔ
ｏｒＴａｒｇｅｔ（ｍａｓｔｅｒ−ｓｌａｖｅ）の形
式を採っており、非対称となっている。ホストであるＩ
ｎｉｔｉａｔｏｒ側が主導権を握り、接続はｌｏｇｉ
ｎ、ｌｏｇｏｕｔによって行われる。本実施の形態では
プリンタ６０１が受信側ノードであるため、Ｔａｒｇｅ
ｔデバイスとなる。ＳＢＰ−２フレームワーク上に更に
上位のプロトコルが載る形で転送が行われるが、プリン
タデバイスを想定しているため、上位にはＳＣＳＩｃや
ＰＰＤＴ（ＰｅｅｒｔｏＰｅｅｒＤａｔａＴｒ
ａｎｓｐｏｒｔ）等のプロトコル、コマンドセットが適
用され、ホストであるＰＣとの間で通信が行われる。通
信はＩｎｉｔｉａｔｏｒであるＰＣが主導権を持って行
うが、データ転送自体はＴａｒｇｅｔデバイスからのリ
ードトランザクションによって行われる。

【０１５８】６１１はＤＰＰ（ＤｉｒｅｃｔＰｒｉｎ
ｔＰｒｏｔｏｃｏｌ）制御部で、同じく１３９４上に
複数存在するプロトコルのうち、ＤＰＰに対応した制御
を行うための制御部である。ＤＰＰは、ＰＣ無しでイメ
ージソースデバイス（例えば、スキャナやディジタルカ
メラ等）から直接印字を可能とするプロトコルである。
ＴｈｉｎＳｅｓｓｉｏｎ、ＴｈｉｎＴｒａｎｓａｃ
ｔｉｏｎというレイア化された構造を持ち、イメージソ
ースデバイスからのライトトランザクションによってデ
ータ転送が行われる。

【０１５９】６１２はアプリケーションソフトウェア
で、ＩＥＥＥ１３９４インタフェースを利用した各種デ
バイスの機能、例えば，プリンタやスキャナやディジタ
ルビデオカメラ等の機能を実現するソフトウェアと、ト
ランザクションレイヤ及びノードコントローラとのイン
タフェースを備えたアプリケーションソフトウェアであ
る。アプリケーションソフトウェア６１２は、本実施の
形態ではプリンタデバイスを想定しているため、プリン
トデータのコマンド解析や画像処理（補正処理や解凍処
理）、プリンタの記録部の制御等を行う。また、アプリ
ケーションソフトウェア６１２は、複数サポートしてい
るプロトコルのうち、どちらを使用してデータ転送を行
うのかといった判断も行う。

【０１６０】６１３は、アプリケーションソフトウェア
６１２若しくは不図示のハードウェアによって制御され
るプリンタの機能であり、受信したプリントデータの印
字を行う。

【０１６１】本実施の形態例では、図１でも説明したよ
うに、ＰＣとのデータ転送を想定して説明しているが、
ＰＣの他にセットトップボックスやゲーム機及びディジ
タルカメラ等の画像入力機器と直接データをやり取りす
る場合にも対応することができる。その場合は、本実施
の形態において説明した内容を実現する機能を、それぞ
れのデバイス内に持つことが必要となる。

【０１６２】以上説明したように、本実施の形態に係る
通信システムによれば、通信途中のバスリセット発生時
にバスリセットの発生原因によってコネクションを回復
するまでの時間を変更することによって、タイムアウト
による紙やインク（トナー）や時間の無駄を省くこと
や、いたずらに時間を費やすことなく次のリクエストに
応える等、再接続に最適な操作を行うことができる。ま
た、通信途中で該当する相手デバイスが取り外されても
セッションの中断が起こらない。

【０１６３】（第２の実施の形態）次に、本発明の第２
の実施の形態を、図７を用いて説明する。

【０１６４】本発明の目的は、本発明に係る通信システ
ムの機能を実現するソフトウェアのプログラムコードを
記録した記憶媒体を、システム或いは装置に供給し、そ
のシステム或いは装置のコンピュータ（または、ＣＰＵ
やＭＰＵ）が記憶媒体に格納されたプログラムコードを
読み出し、実行することによっても達成される。この場
合、記憶媒体から読み出されたプログラムコード自体が
本発明に係る通信システムの機能を実現することにな
り、そのプログラムコードを記憶した記憶媒体は本発明
を構成することになる。

【０１６５】プログラムコードを供給するための記憶媒
体としては、例えば、ＦＤ（フロッピー（登録商標）デ
ィスク）、ハードディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ
Ｗ、ＤＶＤ−ＲＡＭ及びＤＶＤ−ＲＷ等の光ディスク、
ＭＯ等の光磁気ディスク、磁気テープ、フラッシュメモ
リ等の不揮発性のメモリカード、ＲＯＭ等を用いること
ができる。

【０１６６】また、コンピュータが読み出したプログラ
ムコードを実行することにより、本発明に係る通信シス
テムの機能が実現されるだけでなく、そのプログラムコ
ードの指示に基づき、コンピュータ上で稼働しているＯ
Ｓ（オペレーティングシステム）等が実際の処理の一部
または全部を行い、その処理によっても本発明に係る通
信システムの機能が実現される場合も含まれることは言
うまでもない。

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

【０１６８】本発明を上記記憶媒体に適用する場合、そ
の記憶媒体には、先に説明したフローチャートに対応す
るプログラムコードを格納することになる。それを簡単
に説明すると、図７に一例を示すメモリマップの各モジ
ュールを記憶媒体に格納することになる。

【０１６９】即ち、少なくともバス構成情報把握処理モ
ジュール７０１、リコネクト処理モジュール７０２、記
憶処理モジュール７０３、検出処理モジュール７０４及
びユーザーインタフェースモジュール７０５の各プログ
ラムコードを記憶媒体に格納すればよい。

【０１７０】以上説明したように、本発明に係る通信シ
ステムの機能を実現する構成が異なっても、通信途中の
バスリセット発生時においてバスリセットの発生原因に
よってコネクションを回復するまでの時間を変更するこ
とによって、タイムアウトによる紙やインク（トナー）
や時間の無駄を省くことや、いたずらに時間を費やすこ
となく次のリクエストに応える等、再接続に最適な操作
を行なうことができる。また、通信途中で該当するデバ
イスが取り外されてもセッションの中断が起こらない。

【０１７１】

【発明の効果】以上詳述したように本発明によれば、バ
スリセット後に通信を行っていた相手デバイスがバス上
に存在しない場合でもセッションを切断しないことによ
り、それまでに送信したデータを無駄にすることなく再
度相手デバイスと通信を行うことができる。

【０１７２】また、その場合タイムアウト時間を通常よ
り長めに規定することで、ユーザーの不注意等により通
信中のデバイスのケーブルを誤って抜いてしまった場合
等、ケーブルを抜いてしまったことの認識や、その後行
われる再度ケーブルを挿入する動作等、再接続に要する
時間を考慮してタイムアウト時間を設定し直しているた
め、再度バスに接続する前にセッションが切断されてし
まう可能性を少なくすることが可能である。

【０１７３】更に、新たなデバイスのバスへの追加接
続、通信している以外のデバイスのバスからの取り外
し、電源投入、電源ＯＦＦ等の場合には、通信相手がバ
スから取り外された場合に比べて短いタイムアウト時間
を規定することで、その時間内に仮に他のデバイスから
リクエストがあった場合は迅速に応えることができる。

【０１７４】以上のように、仮に通信途中でバスリセッ
トが発生しても、バスリセットの発生原因によってコネ
クションを回復するまでの時間を変更することによっ
て、タイムアウトによる紙やインク（トナー）や時間の
無駄を省くことや、いたずらに時間を費やすことなく次
のリクエストに応える等、再接続に最適な操作を行うこ
とができる。また、通信途中で該当するデバイスが取り
外されてもセッションの中断が起こらない。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態に係る通信システム
におけるセッション回復処理動作の流れを示すフローチ
ャートである。

【図２】本発明の第１の実施の形態に係る通信システム
におけるセッション回復処理動作の流れを示すフローチ
ャートである。

【図３】本発明の第１の実施の形態に係る通信システム
におけるバス構成情報把握プロセス処理動作の流れを示
すフローチャートである。

【図４】本発明の第１の実施の形態に係る通信システム
における１３９４バス構成例を示す図である。

【図５】本発明の第１の実施の形態に係る通信システム
におけるホストＰＣの概略構成を示すブロック図であ
る。

【図６】本発明の第１の実施の形態に係る通信システム
におけるプリンタの概略構成を示すブロック図である。

【図７】本発明の第２の実施の形態に係る通信システム
における記憶媒体のメモリマップの構成を示す図であ
る。

【図８】従来の通信システムにおけるツリー識別終了時
のバス構成例を示す図である。

【図９】従来の通信システムにおけるセルフＩＤパケッ
トのフォーマットの構成例を示す図である。

【図１０】従来の通信システムにおけるコンフィギュレ
ーションＲＯＭのフォーマットの構成例を示す図であ
る。

【図１１】従来の通信システムにおける通信再開処理動
作の流れを示すフローチャートである。

【符号の説明】４０１ＰＣ４０２ハードディスクドライブ４０３ＰＣ４０４プリンタ４０５ＭＯドライブ４０６ＣＣＤカメラ５０１デバイス（ノード）５０２ＣＰＵ（中央制御装置）５０３ＨＤＤ（ハードディスクドライブ）５０４ＲＡＭ（ランダムアクセスメモリ）５０５タイマ（ハードウェアタイマ）５０６入力デバイス制御部５０７表示装置制御部５０８音源制御部５０９入力デバイス５１０表示装置（モニタ）５１１音声出力装置（スピーカ）５１２１３９４カード５１３１３９４ポート（ポート０）５１４１３９４ポート（ポート１）５１５１３９４ポート（ポート２）５１６ＰＨＹコントローラ（ＰＨＹ）５１７ＬＩＮＫコントローラ（ＬＩＮＫ）５１８バッファメモリ（ＦＩＦＯ）５１９ＦＩＦＯ制御部５２０ＣＯＤＥＣ（ＣＯＤＥＲ/ＤＥＣＯＤＥＲ）５２１システムバス（ＣＰＵバス）６０１デバイス（プリンタ）６０２バス６０３ＣＰＵ（中央制御装置）６０４ＲＯＭ（リードオンリーメモリ）６０５ＲＡＭ（ランダムアクセスメモリ）６０６タイマ（ハードウェアタイマ）６０７インタフェース制御部（１３９４Ｉ／Ｆ制御
部）６０８ドライバ６０９レイヤ６１０ＳＢＰ（ＳｅｒｉａｌＢｕｓＰｒｏｔｏ
ｃｏｌ）−２制御部６１１ＤＰＰ（ＤｉｒｅｃｔＰｒｉｎｔＰｒｏ
ｔｏｃｏｌ）制御部６１２アプリケーションソフトウェア。６１３プリンタの機能７０１バス構成情報把握処理モジュール７０２リコネクト処理モジュール７０３記憶処理モジュール７０４検出処理モジュール７０５ユーザーインタフェースモジュール

Claims

【特許請求の範囲】

【請求項１】通信途中でバスリセットが発生した場合
そのバスリセットの発生原因によってコネクションを回
復するまでの時間を変更する時間変更ステップを有する
ことを特徴とする通信方法。
【請求項２】通信途中でバスリセットが発生した場合
そのバスリセットの発生原因によってコネクションを回
復するまでの時間を変更する時間変更手段を有すること
を特徴とする通信システム。
【請求項３】デバイスの電源投入時、新たなデバイス
の追加接続及びバスからのデバイス取り外し時にバスを
再構成するシリアルバスインタフェースを伝送媒体とし
て用いる通信方法において、バスリセット発生時の発生原因を把握するための把握ス
テップと、通信中のデバイス同士がバスリセット後も相手デバイス
を特定して通信を行うことを可能とする通信再開ステッ
プと、前記把握ステップで把握したバスリセットの発生原因に
よって予め規定されている相手デバイスとの通信再開ま
での猶予時間を規定値から変更する変更ステップとを有
することを特徴とする通信方法。
【請求項４】前記シリアルバスインタフェースは、Ｉ
ＥＥＥ１３９４に準拠したものであることを特徴とする
請求項３に記載の通信方法。
【請求項５】前記バスリセット発生原因把握ステップ
は、バスリセット発生前後のバス構成情報の比較によっ
て実行されることを特徴とする請求項３に記載の通信方
法。
【請求項６】前記バス構成情報は、デバイスの接続状
況を示すトポロジーマップ等の各種マップ及びデバイス
の機能やサービスを示すデバイス情報から構成されるこ
とを特徴とする請求項５に記載の通信方法。
【請求項７】前記デバイスの接続状況は、バス構成時
に各デバイスから送出されるセルフＩＤパケットの取得
及びツリー識別プロセスによって把握されることを特徴
とする請求項６に記載の通信方法。
【請求項８】前記デバイスの機能やサービスを示すデ
バイス情報は、各デバイスの持つコンフィギュレーショ
ンＲＯＭ情報の取得によって得られることを特徴とする
請求項６に記載の通信方法。
【請求項９】前記バス構成情報は、ＲＡＭ（ランダム
アクセスメモリ）等の揮発性のメモリに格納されること
を特徴とする請求項５に記載の通信方法。
【請求項１０】前記通信再開までの猶予時間変更の判
断基準となるバスリセットの発生原因とは、通信途中で
相手デバイスがバスから取り外されたことであることを
特徴とする請求項３に記載の通信方法。
【請求項１１】前記シリアルバスインタフェースのト
ランスポート層は、ＳＢＰ−２（ＳｅｒｉａｌＢｕｓ
Ｐｒｏｔｏｃｏｌ２）であることを特徴とする請求項
３または４に記載の通信方法。
【請求項１２】前記通信再開ステップを実行するデバ
イスは、ＰＣ（パーソナルコンピュータ）とプリンタで
あることを特徴とする請求項３または４に記載の通信方
法。
【請求項１３】デバイスの電源投入時、新たなデバイ
スの追加接続及びバスからのデバイス取り外し時にバス
を再構成するシリアルバスインタフェースを伝送媒体と
して用いる通信システムにおいて、バスリセット発生時の発生原因を把握するための把握手
段と、通信中のデバイス同士がバスリセット後も相手デバイス
を特定して通信を行うことを可能とする通信再開手段
と、前記把握手段で把握したバスリセットの発生原因によっ
て予め規定されている相手デバイスとの通信再開までの
猶予時間を規定値から変更する変更手段とを有すること
を特徴とする通信システム。
【請求項１４】前記シリアルバスインタフェースは、
ＩＥＥＥ１３９４に準拠したものであることを特徴とす
る請求項１３に記載の通信システム。
【請求項１５】前記バスリセット発生原因把握ステッ
プは、バスリセット発生前後のバス構成情報の比較によ
って実行されることを特徴とする請求項１３に記載の通
信システム。
【請求項１６】前記バス構成情報は、デバイスの接続
状況を示すトポロジーマップ等の各種マップ及びデバイ
スの機能やサービスを示すデバイス情報から構成される
ことを特徴とする請求項１５に記載の通信システム。
【請求項１７】前記デバイスの接続状況は、バス構成
時に各デバイスから送出されるセルフＩＤパケットの取
得及びツリー識別プロセスによって把握されることを特
徴とする請求項１６に記載の通信システム。
【請求項１８】前記デバイスの機能やサービスを示す
デバイス情報は、各デバイスの持つコンフィギュレーシ
ョンＲＯＭ情報の取得によって得られることを特徴とす
る請求項１６に記載の通信システム。
【請求項１９】前記バス構成情報は、ＲＡＭ（ランダ
ムアクセスメモリ）等の揮発性のメモリに格納されるこ
とを特徴とする請求項１５に記載の通信システム。
【請求項２０】前記通信再開までの猶予時間変更の判
断基準となるバスリセットの発生原因とは、通信途中で
相手デバイスがバスから取り外されたことであることを
特徴とする請求項１３に記載の通信システム。
【請求項２１】前記シリアルバスインタフェースのト
ランスポート層は、ＳＢＰ−２（ＳｅｒｉａｌＢｕｓ
Ｐｒｏｔｏｃｏｌ２）であることを特徴とする請求項
１３または１４に記載の通信システム。
【請求項２２】前記通信再開ステップを実行するデバ
イスは、ＰＣ（パーソナルコンピュータ）とプリンタで
あることを特徴とする請求項１３または１４に記載の通
信システム。
【請求項２３】デバイスの電源投入時、新たなデバイ
スの追加接続及びバスからのデバイス取り外し時にバス
を再構成するシリアルバスインタフェースを伝送媒体と
して用いる通信方法において、バスリセット発生時の発生原因を把握するための把握ス
テップと、通信中のデバイス同士がバスリセット後も相手デバイス
を特定して通信を行うことを可能とする通信再開ステッ
プと、前記把握ステップで把握したバスリセットの発生原因が
通信途中で相手デバイスがバスから取り外された場合そ
の取り外されたデバイスが再度バスに接続されることを
期待して予め規定されている相手デバイスとの通信再開
までの猶予時間内はセッションを維持する維持ステップ
とを有することを特徴とする通信方法。
【請求項２４】前記シリアルバスインタフェースは、
ＩＥＥＥ１３９４に準拠したものであることを特徴とす
る請求項２３に記載の通信方法。
【請求項２５】前記バスリセット発生原因把握ステッ
プは、バスリセット発生前後のバス構成情報の比較によ
って実行されることを特徴とする請求項２３に記載の通
信方法。
【請求項２６】前記バス構成情報は、デバイスの接続
状況を示すトポロジーマップ等の各種マップ及びデバイ
スの機能やサービスを示すデバイス情報から構成される
ことを特徴とする請求項２５に記載の通信方法。
【請求項２７】前記デバイスの接続状況は、バス構成
時に各デバイスから送出されるセルフＩＤパケットの取
得及びツリー識別プロセスによって把握されることを特
徴とする請求項２６に記載の通信方法。
【請求項２８】前記デバイスの機能やサービスを示す
デバイス情報は、各デバイスの持つコンフィギュレーシ
ョンＲＯＭ情報の取得によって得られることを特徴とす
る請求項２６に記載の通信方法。
【請求項２９】前記バス構成情報は、ＲＡＭ（ランダ
ムアクセスメモリ）等の揮発性のメモリに格納されるこ
とを特徴とする請求項２５に記載の通信方法。
【請求項３０】前記通信再開までの猶予時間変更の判
断基準となるバスリセットの発生原因とは、通信途中で
相手デバイスがバスから取り外されたことであることを
特徴とする請求項２３に記載の通信方法。
【請求項３１】前記シリアルバスインタフェースのト
ランスポート層は、ＳＢＰ−２（ＳｅｒｉａｌＢｕｓ
Ｐｒｏｔｏｃｏｌ２）であることを特徴とする請求項
２３または２４に記載の通信方法。
【請求項３２】前記通信再開ステップを実行するデバ
イスは、ＰＣ（パーソナルコンピュータ）とプリンタで
あることを特徴とする請求項２３または２４に記載の通
信方法。
【請求項３３】デバイスの電源投入時、新たなデバイ
スの追加接続及びバスからのデバイス取り外し時にバス
を再構成するシリアルバスインタフェースを伝送媒体と
して用いる通信システムにおいて、バスリセット発生時の発生原因を把握するための把握手
段と、通信中のデバイス同士がバスリセット後も相手デバイス
を特定して通信を行うことを可能とする通信再開手段
と、前記把握手段で把握したバスリセットの発生原因が通信
途中で相手デバイスがバスから取り外された場合その取
り外されたデバイスが再度バスに接続されることを期待
して予め規定されている相手デバイスとの通信再開まで
の猶予時間内はセッションを維持する維持手段とを有す
ることを特徴とする通信システム。
【請求項３４】前記シリアルバスインタフェースは、
ＩＥＥＥ１３９４に準拠したものであることを特徴とす
る請求項３３に記載の通信システム。
【請求項３５】前記バスリセット発生原因把握ステッ
プは、バスリセット発生前後のバス構成情報の比較によ
って実行されることを特徴とする請求項３３に記載の通
信システム。
【請求項３６】前記バス構成情報は、デバイスの接続
状況を示すトポロジーマップ等の各種マップ及びデバイ
スの機能やサービスを示すデバイス情報から構成される
ことを特徴とする請求項３５に記載の通信システム。
【請求項３７】前記デバイスの接続状況は、バス構成
時に各デバイスから送出されるセルフＩＤパケットの取
得及びツリー識別プロセスによって把握されることを特
徴とする請求項３６に記載の通信システム。
【請求項３８】前記デバイスの機能やサービスを示す
デバイス情報は、各デバイスの持つコンフィギュレーシ
ョンＲＯＭ情報の取得によって得られることを特徴とす
る請求項３６に記載の通信システム。
【請求項３９】前記バス構成情報は、ＲＡＭ（ランダ
ムアクセスメモリ）等の揮発性のメモリに格納されるこ
とを特徴とする請求項３５に記載の通信システム。
【請求項４０】前記通信再開までの猶予時間変更の判
断基準となるバスリセットの発生原因とは、通信途中で
相手デバイスがバスから取り外されたことであることを
特徴とする請求項３３に記載の通信システム。
【請求項４１】前記シリアルバスインタフェースのト
ランスポート層は、ＳＢＰ−２（ＳｅｒｉａｌＢｕｓ
Ｐｒｏｔｏｃｏｌ２）であることを特徴とする請求項
３３または３４に記載の通信システム。
【請求項４２】前記通信再開ステップを実行するデバ
イスは、ＰＣ（パーソナルコンピュータ）とプリンタで
あることを特徴とする請求項３３または３４に記載の通
信システム。
【請求項４３】通信システムを制御するためのコンピ
ュータ読み取り可能なプログラムであって、通信途中でバスリセットが発生してもそのバスリセット
の発生原因によってコネクションを回復するまでの時間
を変更する時間変更ステップをコンピュータに実行させ
るためのプログラムコードから成ることを特徴とするプ
ログラム。
【請求項４４】デバイスの電源投入時、新たなデバイ
スの追加接続及びバスからのデバイス取り外し時にバス
を再構成するシリアルバスインタフェースを伝送媒体と
して用いる通信システムを制御するためのコンピュータ
読み取り可能なプログラムであって、バスリセット発生時の発生原因を把握するための把握ス
テップと、通信中のデバイス同士がバスリセット後も相手デバイス
を特定して通信を行うことを可能とする通信再開ステッ
プと、前記把握ステップで把握したバスリセットの発生原因に
よって予め規定されている相手デバイスとの通信再開ま
での猶予時間を規定値から変更する変更ステップとをコ
ンピュータに実行させるためのプログラムコードから成
ることを特徴とするプログラム。
【請求項４５】デバイスの電源投入時、新たなデバイ
スの追加接続及びバスからのデバイス取り外し時にバス
を再構成するシリアルバスインタフェースを伝送媒体と
して用いる通信システムを制御するためのコンピュータ
読み取り可能なプログラムであって、バスリセット発生時の発生原因を把握するための把握ス
テップと、通信中のデバイス同士がバスリセット後も相手デバイス
を特定して通信を行うことを可能とする通信再開ステッ
プと、前記把握ステップで把握したバスリセットの発生原因が
通信途中で相手デバイスがバスから取り外された場合そ
の取り外されたデバイスが再度バスに接続されることを
期待して予め規定されている相手デバイスとの通信再開
までの猶予時間内はセッションを維持する維持ステップ
とをコンピュータに実行させるためのプログラムコード
から成ることを特徴とするプログラム。
【請求項４６】請求項４３乃至４５に記載のプログラ
ムを格納したことを特徴とする記憶媒体。