【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、概して、コンピュータネットワーキングに関し、特に、ユニバーサルシリアルバスをピアツーピアネットワークとして用いる方法およびシステムに関する。

【０００２】

【従来の技術】ピアツーピアネットワークは、各コンピュータがネットワーク上の任意の他のコンピュータへのメッセージ送信を開始でき、またネットワーク上の任意の他のコンピュータからのメッセージ送信を受信することが可能なように、電子ネットワークで接続された複数のコンピュータと定義される。 ローカルエリアネットワーク（ＬＡＮ）は、ピアツーピアネットワークの一例である。

【０００３】ユニバーサルシリアルバス（ＵＳＢ）は、
一般に、パケットまたはメッセージの交換によってホストからデバイスへの通信を可能にするコンピューティングデバイスに関連する通信バスアーキテクチャである。
ＵＳＢメッセージは、通常、ヘッダ情報と、データとを含む。 例えば、パーソナルコンピュータについていえば、コンピュータプロセッサをホストと考え、マウス、
キーボード、プリンタ、ジョイスティック、ディスクドライブ等をホストと通信するデバイスと考えることができる。 従来のＵＳＢプロトコルでは、すべての通信メッセージがＵＳＢホストと該ホストに取り付けられたデバイス間で転送されるよう条件付けられている。 統合されたＵＳＢデバイスインタフェースを含む、競争力のある価格が付けられたマイクロプロセッサが利用しやすいために、ＵＳＢアーキテクチャを採用することは経済的である。

【０００４】従来のＵＳＢプロトコルは、また、広い帯域幅、およびプロセッサモジュールを「ホットスワップ（hotswap）」する能力が重要な通信に対しても有用である。 「ホットスワップ」という用語は、システムの電源を切ることなく、ＵＳＢデバイスを動作中のコンピュータシステムからはずし、別のプロセッサと取り替える状況を指す。

【０００５】

【発明が解決しようとする課題】不都合なことに、この従来のプロトコルでは、ＵＳＢに接続されるデバイス間の通信がすべてホスト−デバイス間通信を介して行われるよう要請されるために、「ピアツーピア」通信とも呼ばれるデバイス間の直接通信を行うことができない。

【０００６】したがって、システムの電源を切ることなく、プロセッサモジュールの取り外しおよび置換が可能であり、かつ通信バスに接続されたデバイス間でのピアツーピア通信が可能な高帯域幅通信プロトコルおよびバスが必要とされている。

【０００７】

【課題を解決するための手段】本発明は、ＵＳＢに接続されたデバイス間でのピアツーピア通信のための方法およびシステムを提供する。

【０００８】本発明は、ＵＳＢをピアツーピアネットワークとして用いる方法として概念化することができ、本方法は、ルータを備えるホストプロセッサをＵＳＢに接続するステップと、それぞれ互いに対して、かつホストプロセッサに対してピアである複数のデバイスをＵＳＢ
に接続するステップと、を含む。 本方法はまた、複数のデバイスまたはホストプロセッサのうちの１つにおいて、メッセージを形成するステップと、該メッセージの前にヘッダを付加するステップと、ルータおよびＵＳＢ
を介して、該メッセージをデバイスのうちの１つから他の任意のデバイス、またはホストプロセッサに直接伝送するステップと、含む。

【０００９】アーキテクチャにおいて、本発明は、ＵＳ
Ｂをピアツーピアネットワークとして用いるためのシステムであり、メッセージハンドラを含むホストプロセッサを備える。 ホストプロセッサは、メッセージの前にヘッダを付加するよう構成され、ホストメッセージハンドラは、該ヘッダを認識するよう構成される。 本システムはまた、それぞれデバイスメッセージハンドラを含む、
ホストプロセッサに連係された複数のデバイスも備える。 複数のデバイスはそれぞれ、メッセージの前にヘッダを付加するよう構成される。 デバイスメッセージハンドラはまた、ヘッダを認識するよう構成される。 本システムは、ホストプロセッサと、ホストプロッサに連係された複数のデバイスのうちの任意のデバイス間で直接、
ＵＳＢを介してメッセージをルーティングするよう構成された、ホストプロセッサに連係されたルータも備える。

【００１０】特許請求の範囲において定義付けられる本発明について、添付図面を参照することでより良好に理解することができる。 図面内の構成要素は、必ずしも互いに対して一定の縮尺ではなく、本発明の原理を明白に示す部分を強調している。

【００１１】

【発明の実施の形態】ＵＳＢをピアツーピアネットワークとして用いる方法およびシステムの好ましい実施形態について、サーバコンピュータシステムを制御するために、ＵＳＢを用いて互いに対話する多数のマイクロプロセッサ駆動式デバイスを例として説明するが、本発明は、多数のデバイスがＵＳＢを介して通信するあらゆる状況において適用可能である。

【００１２】ＵＳＢをピアツーピアネットワークとして用いる方法およびシステムは、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせにおいて実施することができる。 好ましい実施形態において、本発明は、ハードウェアと、ソフトウェアまたはファームウェアとの組み合わせにおいて実施される。 ハードウェアまたはファームウェアはメモリに格納し、適した命令実行システムで実行することができる。 代替の実施形態におけるように、ハードウェアにおいて実施される場合、本発明は当技術分野で周知の次の技術、すなわち、データ信号に対して論理関数処理を行う論理ゲートを有する離散論理回路、適切な組み合わせ論理ゲートを備えた特定用途向け集積回路（ＡＳＩＣ）、プログラマブル・ゲートアレイ（ＰＧＡ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）等のいずれか一つ、
あるいはそれらの組み合わせを用いて実施することができる。

【００１３】ＵＳＢをピアツーピアネットワークとして用いる方法およびシステムのソフトウェア部分は、論理関数処理を行うための実行可能命令の順序付きリストを含み、コンピュータベースのシステム、プロセッサ包含システム、または媒体から命令をフェッチして実行することのできる他のシステム等のような、命令実行システム、装置、またはデバイスによって、またはこれらと併せて用いるため、任意のコンピュータ読み取り可能媒体において実施することができる。 本明細書において、
「コンピュータ読み取り可能媒体」とは、命令実行システム、装置、またはデバイスによって、またはこれらと併せて用いるため、プログラムを包含、格納、通信、伝搬、または搬送することが可能な任意の手段でありうる。 コンピュータ読み取り媒体は、例えば、電気、磁気、光学、電磁、赤外線、または半導体のシステム、装置、デバイス、または伝搬媒体でありうるが、これらに制限されない。 コンピュータ読み取り媒体のより具体的な例（非網羅的リスト）としては、以下が挙げられる。
すなわち、１本または複数本のワイヤを有する電気接続（電気）、ポータブルコンピュータディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（電気）、読み取り専用メモリ（ＲＯＭ）（電気）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）（電気）、光ファイバ（光学）、およびポータブルコンパクトディスク読み取り専用メモリ（ＣＤ
−ＲＯＭ）（光学）である。 なお、コンピュータ読み取り可能媒体は、紙またはプログラムを印刷可能な別の適した媒体であってもよいことに留意する。 これは、例えば光学スキャン等により紙または他の媒体上のプログラムを電子的に取り込んでから、必要であればコンパイル、解釈するか、そうでなければ適宜処理し、コンピュータメモリに格納することができるためである。

【００１４】次に、図面に目を向けて、図１は、本発明の概念を示すために用いられる、サーバシステム１１を示すブロック図である。 なお、サーバシステム１１として図示されるが、ＵＳＢをピアツーピアネットワークとして用いる方法およびシステムは、それぞれＵＳＢインタフェースを有する複数のプロセッサデバイスがピアツーピア構成でＵＳＢを介して通信する任意のシステムに適用可能であることに留意されたい。 サーバシステム１
１は、多数のキャビネットに分割してもよい。 例えば、
説明のために、サーバ１１は、時にキャビネット２７および２８と呼ばれるノードに分割される。 キャビネット２７は、メモリ要素１２と、プロセッサ１４とを備える。 キャビネット２８は、メモリ要素３６と、プロセッサ３７とを備える。 各キャビネット２７および２８はまた、メモリ要素１２および３６と、プロセッサ１４および３７をそれぞれ制御し、監視するユーティリティサブシステム５０および３０もそれぞれ備える。

【００１５】ユーティリティサブシステム５０は、ＵＳ
Ｂ２０に接続され、ＵＳＢ２０を介して通信する多数のプロセッサデバイスを備え、本明細書では、キャビネットレベルユーティリティ（ＣＬＵ）デバイス６０と、パワーモニタ３（ＰＭ３）デバイス７０と、システム抽象レイヤインタフェースネットワークコントローラ（ＳＩ
ＮＣ）デバイス１００と、サービスプロセッサ２００
と、を備えるものとして図示される。 通常の適用においては、各ユーティリティサブシステム５０および３０
は、ＣＬＵデバイス、ＰＭ３デバイス、およびＳＩＮＣ
デバイスの組を繰り返し多数含むと共に、追加のプロセッサおよび制御デバイスを備える。 そのため、複数のユーティリティサブシステム５０および３０が図示されている。 しかし、簡略化のために、それぞれＣＬＵデバイス、ＰＭ３デバイス、ＳＩＮＣデバイスを一組ずつ備える二組のユーティリティサブシステムのみが図示されている。 ユーティリティサブシステム５０の場合には、それらに加えてサービスプロセッサ２００を備える。 しかし、サーバ１１に連係されるサービスプロセッサ２００
は（ユーティリティサブシステム５０に配置される）一つのみであることに留意されたい。 本発明の一形態においては、サービスプロセッサ２００はホストプロセッサとして機能する。 ＵＳＢプロトコルは一つのホストしか許容しないため、ユーティリティプロセッサおよび関連デバイスの数に関係なく、サービスプロセッサ２００は一つだけである。 本発明の一形態において重要なことは、各ユーティリティサブシステム５０および３０内の各デバイスがＵＳＢ２０を介して通信するということである。

【００１６】ＳＩＮＣデバイス１００は、接続２１を介して、メモリ１２およびプロセッサ１４と通信し、これらを制御する。 ＣＬＵデバイス６０は、接続２２を介して、バックプレーン要素１６と通信してこれを制御し、
ＰＭ３デバイス７０は、接続２４を介して、電源およびファンモジュール１８と通信し、これらを制御する。 同様に、ＳＩＮＣデバイス３１は、接続４１を介して、メモリ３６およびプロセッサ３７と通信し、これらを制御する。 ＣＬＵデバイス３２は、接続４２を介して、バックプレーン要素３８と通信してこれを制御し、ＰＭ３デバイス３４は、接続４４を介して、電源およびファンモジュール３９と通信し、これらを制御する。

【００１７】図２は、図１のユーティリティサブシステム５０を示すブロック図である。 ユーティリティサブシステム５０は、ＵＳＢ２０を介して、ＳＩＮＣデバイス１００、ＣＬＵデバイス６０、およびＰＭ３デバイス７
０と通信するサービスプロセッサ２００を備える。 サービスプロセッサ２００は、協働して、ユーティリティサブシステム５０の動作を制御するハードウェア要素とソフトウェア要素の双方で構成される。 サービスプロセッサ２００は、ＵＳＢホストコントローラ２２６およびＵ
ＳＢホストドライバ２２４を用いて、ＵＳＢ２０を介して通信する。 ＵＳＢホストコントローラ２２６は、ハードウェア要素（ＵＳＢコントローラチップ）であり、Ｕ
ＳＢホストドライバ２２４は、それに対応した、ＵＳＢ
通信の制御に用いられるソフトウェアドライバである。

【００１８】サービスプロセッサ２００はまた、サービスプロセッサ２００の動作を制御するソフトウェア要素である、オペレーティングシステム２２１を備える。 サービスプロセッサ２００はまた、ＵＳＢルータ２１８も含む。 ＵＳＢルータ２１８は、サービスプロセッサ２０
０と、ユーティリティサブシステム５０内の各デバイス６０、７０、および１００との間に論理接続を提供する、デバイスドライバ２２０を介して、オペレーティングシステム２２１と通信する。 デバイスドライバ２２０
については後にさらに詳細に説明される。

【００１９】サービスプロセッサ２００はまた、各種機能性をサーバシステム１１に提供する多数のソフトウェアモジュールも備える。 例えば、サービスプロセッサ２
００は、スキャンサポートモジュール２０８、ファームウェア更新モジュール２１１、ならびにサーバシステム１１の全体設計の一部であり、かつ他のＵＳＢ接続されたマイクロプロセッサと通信を行い動作する他のモジュールを備える。 基本的に、サービスプロセッサ２００
は、サーバシステム１１が適切に機能できるようにする、ユーティリティサブシステム５０内の様々な制御機能を提供する。

【００２０】なお図２を参照して、ユーティリティサブシステム５０は、ＳＩＮＣデバイス１００と、ＣＬＵデバイス６０と、ＰＭ３デバイス７０と、をさらに備える。 これらデバイスはそれぞれ、互いに対してピアと見なされる。 同様に、サービスプロセッサもまた、各デバイス６０、７０、および１００に対してピアである。 例えば、後に詳細に説明される本発明によれば、各デバイス（ＳＩＮＣ１００、ＣＬＵ６０、およびＰＭ３７０）
は、ＵＳＢ２０をピアツーピアネットワークとして用いることで、互いに対して、かつサービスプロセッサ２０
０と双方向通信することができる。 この例においては、
ＵＳＢはＬＡＮであると考えることができる。

【００２１】本発明の一形態によれば、ＳＩＮＣデバイス１００、ＣＬＵデバイス６０、およびＰＭ３デバイス７０内に含まれるメッセージロジック１５０は、デバイスと協働して、各デバイスが特別な（unique）通信プロトコルヘッダをデータブロックの前に付加することができるようにし、これによってＵＳＢに接続された別のデバイスに直接アドレス指定される通信メッセージを形成する。 特別通信プロトコルヘッダおよびデータ（すなわち、通信メッセージ）は、次に、標準ＵＳＢヘッダおよびトレーラで収容され、ＵＳＢを介して転送される。 特別通信プロトコルヘッダにより、各デバイスがまるでピアツーピアネットワークに接続されているかのように、
各デバイスが他のデバイスと互いに通信することが可能になる。

【００２２】ＳＩＮＣデバイス１００は、エグゼクティブ１０１、メッセージロジック１５０、ＵＳＢドライバ１０２、ハードウェアインタフェース１０４、およびＵ
ＳＢデバイスコントローラ１０６を備える。 ＵＳＢデバイスコントローラ１０６は、ＵＳＢ２０を介してメッセージを通信するために、ＵＳＢデバイスインタフェースチップおよびＵＳＢドライバ１０２とのインタフェースを備えたハードウェア要素である。 ハードウェアインタフェース１０４により、エグゼクティブ１０１は、ＳＩ
ＮＣデバイス１００に存在する他のハードウェア要素（図示せず）と通信可能になる。 メッセージロジック１
５０（後により詳細に説明する）は、エグゼクティブ１
０１と協働して、ＳＩＮＣデバイス１００が、上述した特別通信プロトコルヘッダを生成し、該ヘッダをデバイスが送信したいと望むデータの前に付加することによって、ＵＳＢ２０に接続された任意の他のデバイスにメッセージを送信できるようにする。

【００２３】従来の使用方法では、ＵＳＢでは、ホストと遠隔的に接続された個々のデバイスとの間のメッセージ通信しかできない。 例えば、パーソナルコンピュータ（ＰＣ）環境において、ＵＳＢは、プロセッサと、プリンタ、マウス、およびキーボード等遠隔的に接続される周辺装置との間のメッセージ通信に用いられる。 例えば、マウスがプリンタと通信する方法はない（理由もない）。 従来の適用において、ＵＳＢではホスト−デバイス間の通信しかできなかった。

【００２４】本発明の一形態によると、メッセージロジック１５０は、ＵＳＢルータ２１８と協働して、特別通信プロトコルヘッダを解析し、ＵＳＢ２０に接続された任意のデバイス間のピアツーピア通信を可能にする。 それによって、ＵＳＢ２０はピアツーピアネットワークとして機能できるようになる。

【００２５】ＣＬＵデバイス６０は、エグゼクティブ６
１、メッセージロジック１５０、ＵＳＢドライバ６２、
ハードウェアインタフェース６４、スキャンインタフェース６７、およびＵＳＢデバイスコントローラ６６を備える。 同様に、ＰＭ３デバイス７０は、エグゼクティブ７１、メッセージロジック１５０、ＵＳＢドライバ７
２、ハードウェアインタフェース７４、およびＵＳＢデバイスコントローラ７６を備える。 エグゼクティブ６１
と７１、ＵＳＢドライバ６２と７２、ハードウェアインタフェース６４と７４、およびＵＳＢデバイスコントローラ６６と７６はすべて、ＳＩＮＣデバイス１００における各デバイスと同様に動作する。

【００２６】簡略化のために図２からは省略されているが、サービスプロセッサ２００、ＳＩＮＣデバイス１０
０、ＣＬＵデバイス６０、およびＰＭ３デバイス７０はそれぞれ、本発明のソフトウェア部分の実行に必要なプロセッサ、メモリ（ランダムアクセスメモリ（ＲＡＭ）
および読み出し専用メモリ（ＲＯＭ）を含む）、インタフェース、および接続を備える。

【００２７】 本発明のプロトコルスタック概観図３は、本発明の一形態によるプロトコルスタック３０
０を示す概略図である。 サービスプロセッサ２００は、
ＵＳＢホストコントローラ２２６、ＵＳＢホストドライバ２２４、およびＵＳＢルータ２１８を備える。

【００２８】ＳＩＮＣデバイス１００は、ＵＳＢデバイスコントローラ１０６、ＵＳＢデバイスドライバ１０
２、およびメッセージロジック１５０を備える。 図３に示すように、ＵＳＢホストコントローラ２２６は、物理的接続（ＵＳＢ）２０を介して、ＵＳＢデバイスコントローラ１０６と通信する。 ＵＳＢホストドライバ２２４
は、論理接続３２１を介して、ＵＳＢデバイスドライバ１０２と論理的に通信する。 ＵＳＢルータ２１８は、本発明に関連する通信プロトコルを用い、パイプ１１１、
１１２および１１４を介して、メッセージロジック１５
０と論理的に通信する。

【００２９】図４は、本発明による、メッセージフォーマット３３０を示す概略図である。 メッセージフォーマット３３０は、ＵＳＢヘッダ３３１、通信プロトコルヘッダ３５５、データ３６０、およびＵＳＢトレーラ３３
２を含む。 本発明の一形態によれば、任意のデバイス、
例えば上述したＳＩＮＣデバイス１００、ＣＬＵデバイス６０、ＰＭ３デバイス７０、およびサービスプロセッサ２００によって、通信プロトコルヘッダ３５５（後により詳細に説明される）がデータ３６０の前に付加され（前に取り付けられ）、その結果通信メッセージ３５０
が形成される。 通信メッセージ３５０は、標準ＵＳＢヘッダ３３１およびトレーラ３３２によって収容される。
このようにして、ＵＳＢ２０に接続された個々の任意のデバイスが、一意に識別されるメッセージを、ＵＳＢ２
０に接続された他の任意のデバイスに送信することができる。

【００３０】 システム動作図５は、図２のサービスプロセッサ２００とＳＩＮＣデバイス１００間の接続性を示すブロック図である。 図５
には、１つのみのデバイス（すなわち、ＳＩＮＣデバイス１００）をＵＳＢ２０を介してサービスプロセッサ２
００に接続して図示するが、かかる多くのデバイスがサービスプロセッサ２００に接続されるものと意図される。 本発明の動作を説明するために、かつ例として、ファームウェア更新モジュール２１１（図２におけるいかなるモジュールもメッセージを送信可能であるが）が、
接続２６６を介して、通信メッセージをＵＳＢルータ２
１８に送信する。 接続２６６を介して送信されるメッセージは、通信プロトコルヘッダ３５５およびデータ３６
０を含み、このメッセージは、ＵＳＢルータ２１８によって受信される。 通信プロトコルヘッダ３５５およびデータ３６０については、後に図７に関してより詳細に説明する。 ＵＳＢルータ２１８は、接続２６６を介して受信したメッセージを検査し、添付された通信プロトコルヘッダ３５５を解析することで、メッセージをどこに送信すべきかを決定する。 例えば、ファームウェア更新モジュール２１１からのメッセージは、例えば、ＳＩＮＣ
デバイス１００、ＣＬＵデバイス６０、およびＰＭ３デバイス７０等（これらに制限されない）、ＵＳＢに接続された他の任意のデバイスを宛先とすることができる。
ＵＳＢルータ２１８は、複数のデバイスドライバ２５
１、２５２、および２５４に接続される。 デバイスドライバ２５１は、ＳＩＮＣデバイス１００と関連付けられる。 デバイスドライバ２５２は、ＣＬＵデバイス６０に関連付けられ、デバイスドライバ２５４はＰＭ３デバイス７０に関連付けられる。 各デバイスタイプ毎にデバイスドライバを設けることで、異なるデバイスタイプに行くメッセージに優先順位を付けることが可能になる。 しかし、デバイスドライバは一つだけでもすべてのデバイスタイプに対応することができる。 好ましい実施形態においては、接続されたデバイスタイプ（すなわち、ＳＩ
ＮＣデバイス１００、ＣＬＵデバイス６０、およびＰＭ
３デバイス７０）それぞれに関連したデバイスドライバが一つずつサービスプロセッサ２００に備えられる。 これらのデバイスドライバ２５１、２５２、および２５４
は、例としてのみ図示されるものである。

【００３１】接続２６６を介して受信したメッセージの宛先に応じて、ＵＳＢルータ２１８は、メッセージがＳ
ＩＮＣデバイス１００、ＣＬＵデバイス６０、またはＰ
Ｍ３デバイス７０に宛先付けられている場合には、そのメッセージを適切なデバイスドライバ２５１、２５２、
または２５４に提供し、サービスプロセッサ２００に宛先付けられている場合には、サービスプロセッサ２００
における別のエンティティに提供する。 例として、図５
は、ＳＩＮＣデバイス１００を備え、これは、あくまで例を示すためのものとして、接続２６６を介して受信したメッセージがアドレス指定されるデバイスであると仮定する。 ＵＳＢルータ２１８は、接続２６６を介して受信したメッセージが、ＳＩＮＣデバイス１００に宛先付けられていることを認識し、該メッセージをデバイスドライバ２５１に送る。 メッセージがＳＩＮＣデバイス１
００からサービスプロセッサ２００において受信されると、該メッセージもまたデバイスドライバ２５１に現れる。 このような場合、受信したメッセージは、ＵＳＢルータ２１８に転送され、ＵＳＢルータ２１８は、本発明の一形態により、該メッセージの前に付加された通信プロトコルヘッダを解析し、該メッセージをどこに送信すべきかを決定する。 例えば、もしＳＩＮＣデバイス１０
０がメッセージをＣＬＵデバイス６０に送信すると、メッセージはデバイスドライバ２５１に現れ、ＵＳＢルータ２１８に転送される。 次に、ＵＳＢルータ２１８は、
該メッセージをＣＬＵデバイス６０に関連付けられたデバイスドライバ２５２に送る。 ＳＩＮＣ１００から受信したメッセージがサービスプロセッサ２００に宛先付けられていた場合、ＵＳＢルータ２１８は、デバイスドライバ２５１から受信したメッセージを受け入れ、接続２
６２を介して、該メッセージをサービスプロセッサ入力メッセージハンドラ２５０に転送する。 サービスプロセッサ入力メッセージハンドラ２５０は、通信プロトコルヘッダ３５５を除去し、データ３６０を適切なモジュール、本例では、ファームウェア更新モジュール２１１に接続２６４を介して転送する。 あるいはまた、サービスプロセッサ入力メッセージハンドラ２５０は、データ３
６０を接続２６７を介して、他のアプリケーションモジュール２６８として表される任意適切な他のアプリケーションモジュールに転送する。

【００３２】ここで再び、ファームウェア更新モジュール２１１からＳＩＮＣデバイス１００に送信されるメッセージについての考察に戻ると、ＵＳＢルータ２１８
は、メッセージをデバイスドライバ２５１に入れ、該デバイスドライバ２５１は、次に、メッセージをキュー２
５６に入れる。 図５のデバイスドライバ２５１、２５
２、および２５４は、図２のデバイスドライバ２２０を示し、かつこれに対応する。 例示のために説明される本例では、上記タイプ（ＳＩＮＣ、ＰＭ３、およびＣＬ
Ｕ）毎に１つのデバイスがあるものと仮定される。 実際には、デバイスタイプ毎に複数のデバイスがありうる。
同一のデバイスタイプのデバイスはそれぞれ、そのデバイスタイプ用のデバイスドライバ内に、各自専用のキューを有する。 したがって、それぞれドライバの対応するデバイスタイプの特定のデバイスに対応する複数のキューセットを処理することによって、一台のデバイスドライバで各自のデバイスタイプのデバイスを複数扱うことができる。

【００３３】本発明によれば、論理接続が、サービスプロセッサ２００と、ＳＩＮＣデバイス１００等の遠隔的に接続されたデバイスとの間に確立される。 サービスプロセッサ２００およびＳＩＮＣデバイス１００の双方に示される矢印１１１、１１２、および１１４は、サービスプロセッサ２００とＳＩＮＣデバイス１００の間に存在する論理接続を表す、「パイプ」の概念を示している。 矢印１１１は、バルクアウトパイプを表し、矢印１
１２は、割り込みパイプを表し、矢印１１４は、バルクインパイプを表す。 パイプの概念は、ＵＳＢバス通信システムの分野において周知であり、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）ネットワークスタックにおける接続ソケットの概念に対応する。

【００３４】 入力メッセージ動作例本発明の一形態によれば、ＵＳＢホストコントローラ２
２６およびサービスプロセッサ２００は、ＳＩＮＣデバイス１００内のＵＳＢデバイスコントローラ１０６を介して、割り込みパイプ１１２を定期的にポーリングする。 ＳＩＮＣデバイス１００が、サービスプロセッサ２
００あるいはＵＳＢ２０に接続された別のデバイスのいずれかに送信したいデータを有する場合、デバイスによりデータ３６０の前に付加された通信プロトコルヘッダ３５５がキュー１５６に入れられる。 キュー１５６は、
デバイス出力メッセージハンドラ１５２内にあり、デバイス出力メッセージハンドラ１５２は、通信プロトコルヘッダ３５５を割り込みパイプ１１２に入れる。 ＵＳＢ
ホストコントローラ２２６は、割り込みパイプ１１２をポーリングすると、割り込みパイプにおける通信プロトコルヘッダ３５５の存在を認識し、それによって、ＳＩ
ＮＣデバイス１００が送信したい情報を有していることを知らせる。 次に、通信プロトコルヘッダ３５５が、デバイス出力メッセージハンドラ１５２から割り込みパイプ１１２を介してＳＩＮＣデバイスドライバ２５１に転送される。 ＵＳＢ業界規格用語において、通信プロトコルヘッダ３５５は、割り込みデータパケットと呼ばれる。

【００３５】ＳＩＮＣデバイスドライバ２５１は、ヘッダ３５５の長さフィールド（図７において後述するバイト６および７）を読み出すことで、通信プロトコルヘッダ３５５にデータフィールド３６０を足した長さを読み出す。 ＳＩＮＣデバイスドライバ２５１は、ＳＩＮＣデバイス１００が送信データをさらに有しているか否かを判断する。 これは、通信プロトコルヘッダ３５５内の特定フィールドを解析することで達成され、これについては、後に図７に関して詳細に説明する。 ＳＩＮＣデバイスドライバ２５１が、ＳＩＮＣデバイス１００が送信する情報をさらに有していると判断した場合、ＳＩＮＣデバイスドライバ２５１は、「ＵＳＢバルク読み出し」コマンドをＳＩＮＣデバイス１００に送信する。 この結果、デバイス出力メッセージハンドラ１５２からキュー１５８を通して、次にバルクインパイプ１１４を通してサービスプロセッサ２００に転送される通信メッセージ（すなわち、データ３６０）の平衡が保たれる。 転送はパイプ１１１、１１２、および１１４を介して行われるものとして説明したが、重要なことは、パイプは論理接続であり、情報の転送は、実際にはＵＳＢ２０を介して行われることであることに留意されたい。

【００３６】本発明の本形態において、上記のメッセージ交換が行われた場合、デバイス出力メッセージハンドラ１５２は、ＳＩＮＣ１００上のいくつかのソフトウェアモジュール（例えば、新メッセージブロック１２６、
ファームウェア更新ルーチン１１９、またはリセットルーチン１１８）のうちの１つからメッセージを受信したものと考えられる。 メッセージを発するモジュールは、
通信プロトコルヘッダ３５５をデータ３６０の前に付加したものと考えられる。 デバイス出力メッセージハンドラ１５２は、次に、通信プロトコルヘッダ３５５をキュー１５６に入れ、データ３６０をキュー１５８に入れたと考えられる。 リセットルーチン１１８、ファームウェア更新ルーチン１１９、および新メッセージブロック１
２６を用いて説明されたが、ＳＩＮＣデバイス１００から送信されるメッセージは、ＳＩＮＣデバイス１００上に存在するが図示されていない種々多数のメッセージ源のうちのいずれから発せられてもよい。

【００３７】本発明の一形態によれば、デバイスドライバ２５１は、「読み出し」呼び出しを用いることで、割り込みパイプ１１２から読み出しを行う。 呼び出しの概念は当業者には周知である。 割り込みパイプ１１２にメッセージがない場合、呼び出しは保留される。 ＵＳＢホストドライバ２２４が、割り込みパイプ１１２において通信プロトコルヘッダ３５５を検出した場合、呼び出しが戻される。 次に、デバイスドライバ２５１は、通信プロトコルヘッダ３５５を割り込みパイプ１１２から除去する。 そして、通信プロトコルヘッダ３５５が、付随するデータ３６０があることを示す場合には、デバイスドライバ２５１は、読み出し呼び出しをバルクインパイプ１１４に出す。 この読み出し呼び出しは、読み出しが完了するまで保留される。

【００３８】 出力メッセージ動作例出力メッセージ（すなわち、サービスプロセッサ２００
からＳＩＮＣデバイス１００等の遠隔デバイスに送信されるメッセージ）の転送について、次に説明する。 サービスプロセッサ２００によって処理されるメッセージは、サービスプロセッサ２００から発せられるか、あるいはＵＳＢ２０に接続された別のデバイス（ＳＩＮＣデバイス１００等）から発せられる。 本発明によれば、Ｕ
ＳＢルータ２１８は、出力メッセージをキュー２５６、
２５７、または２５８のうち、メッセージがアドレス指定されているデバイスに関連する１つに入れる。 本例において、ＵＳＢルータ２１８は、メッセージをデバイスドライバ２５１に渡し、デバイスドライバ２５１は、最終的にＳＩＮＣデバイス１００に伝送するために、キュー２５６にメッセージを入れる。 現在ＳＩＮＣデバイス１００に送信処理中のメッセージがない場合には、デバイスドライバ２５１は、すぐにキュー２５６からメッセージを抽出して、該メッセージをＳＩＮＣデバイス１０
０に送信する。 送信中の前の出力メッセージがある場合には、新しいメッセージはキュー２５６に保持され、前のメッセージに対する「送信完了」割り込みが発生すると、取り出されてＳＩＮＣデバイス１００に送信される。 ＵＳＢルータ２１８からバルクパイプ１１１を通して送信されたメッセージは、次に、デバイス入力メッセージハンドラ１５１に受信され、キュー１５４に入れられる。 当技術分野で周知の「関数呼び出し」を用いて、
エグゼクティブ１０１は、接続１０９を介して、デバイス入力メッセージハンドラ１５１を定期的に呼び出し、
すなわちポーリングし、キュー１５４にメッセージがあるか否かを判断する。 エグゼクティブ１０１はまた、同様に他の関数呼び出しも行う。 例えば、エグゼクティブ１０１は、接続１０３を介して定期的にハードウェアインタフェース１０４を呼び出し、ＳＩＮＣデバイス１０
０におけるハードウェアの状態を判断する。 ハードウェアインタフェース１０４は、ＵＳＢ２０に接続された他の任意のデバイスに送信する情報を有している場合には、接続１０８を介してメッセージロジック１５０と通信することができる。 デバイス入力メッセージハンドラ１５１がキュー１５４に情報を有している場合、エグゼクティブ１０１にポーリングされると、デバイス入力メッセージハンドラ１５１は、キュー１５４に存在するメッセージを実行するために、適切な関数呼び出しを生成する。

【００３９】例えば、ファームウェア更新モジュール２
１１が、ＵＳＢ２０を介してファームウェア更新メッセージをＳＩＮＣデバイス１００に送信したものと仮定した場合、デバイス入力メッセージハンドラ１５１は、このメッセージをキュー１５４において検出すると、接続１１７を介して適切な関数呼び出しを実行して、ファームウェア更新ルーチン１１９を実行する。 このファームウェア更新は、例示目的のためにのみ示されるものである。 他のメッセージならば、異なるルーチンを呼び出す。 デバイス入力メッセージハンドラ１５１がファームウェア更新のメッセージの代わりにリセットコマンドを受信したならば、リセットルーチン１１８に対して接続１１６を介して関数呼び出しを実行し、リセットルーチン１１８が、接続１２７を介して、リセットコマンドをリセットハードウェア１２８に送信する。

【００４０】ＳＩＮＣデバイス１００がメッセージをＵ
ＳＢ２０に配置された別のデバイスまたはサービスプロセッサ２００に送信するには、種々多数のシナリオがある。 例えば、ファームウェア更新モジュール２１１から受信したファームウェア更新メッセージに応答して、ファームウェア更新ルーチン１１９を実行すると、ファームウェア更新ルーチン１１９は、メッセージの受信承認と、メッセージにおいて要求されたアクションの成功または失敗を示すメッセージの双方またはいずれかを送信することができる。 これは、図７および図８に関して説明する通信プロトコルヘッダ３５５によって達成することができる。 あるいは、非送信請求状態更新メッセージをＳＩＮＣデバイス１００から新メッセージブロック１
２６を介して送信することもできる。 別の例として、新メッセージブロック１２６は、メッセージをパワーモニタであるＰＭ３デバイス７０に送信し、ＳＩＮＣが必要とする電力を知らせる。

【００４１】メッセージを与えられる方法に関わりなく、デバイス出力メッセージハンドラ１５２は、通信プロトコルヘッダ３５５およびデータ３６０を含むメッセージを解析し、ヘッダ３５５をキュー１５６に入れ、データ３６０をキュー１５８に入れる。 本発明において、
通信プロトコルヘッダ３５５は、メッセージを送信したデバイスによって、データ３６０の前に付加される。 例えば、ファームウェア更新ルーチン１１９が、ファームウェア更新モジュール２１１から受信したメッセージに対して返信するよう命令された場合、ファームウェア更新ルーチン１１９は、以下の説明に従って、メッセージの前に通信プロトコルヘッダ３５５を付加し、ヘッダおよびメッセージをデバイス出力メッセージハンドラ１５
２に送信する。 ファームウェア更新ルーチン１１９によって前に付加された通信プロトコルヘッダ３５５は、メッセージの宛先としてサービスプロセッサ２００を識別する。 ファームウェア更新モジュール２１１は、ファームウェア更新ルーチン１１９が現在応答しているメッセージを送信する際、ヘッダのプライベートエリア（図７
において後に説明されるバイト８〜１１）に特別な番号を挿入している。 この特別な番号は、ファームウェア更新ルーチン１１９には認識されないが、サービスプロセッサ入力メッセージハンドラ２５０がファームウェア更新モジュール２１１を応答メッセージの所期の受信先として識別できるようにするための識別子である。 ファームウェア更新ルーチン１１９が応答メッセージを作成する際、要求メッセージから応答メッセージにプライベートバイト３６２、３６４、３６６、および３６７（図７）をコピーする。 メッセージヘッダのプライベートエリアの使用については、図７に関して後に説明される。

【００４２】デバイス出力メッセージハンドラ１５２
は、通信プロトコルヘッダ３５５を、キュー１５６に対応する割り込みパイプ１１２に入れ、もし存在すれば、
データ３６０をキュー１５８に関連するバルクインパイプ１１４に入れる。 キュー１５６は、二重バッファキューであり、二重バッファされるＵＳＢデバイスコントローラ１０６に対応する。

【００４３】図６は、図５におけるキューとして与えられる図３のパイプを示す略図である。 図示のように、ルータ２１８およびＳＩＮＣデバイス１００は、バルクアウトパイプ１１１、割り込みパイプ１１２、およびバルクインパイプ１１４を介して接続される。 図６は、メッセージが交換される個々の経路としてパイプを示している。 なお、図６には三本の個々のパイプとして示されるが、パイプはすべてＵＳＢ２０に存在することに留意されたい。

【００４４】 メッセージヘッダフォーマット図７は、図４のメッセージフォーマット３３０の通信メッセージ３５０の一例を示す概略図である。 通信メッセージ３５０は、通信プロトコルヘッダ３５５およびデータ３６０を含む。 通信プロトコルヘッダ３５５は、１２
バイトの情報を含む。 該バイトは、必ずしも図示した順序である必要はない。 宛先キャビネット番号３５１（バイト０）は、宛先キャビネット番号に関する情報を含む。

【００４５】宛先アドレス３５２（バイト１）は、メッセージが宛先付けられたデバイスのキャビネット内のアドレスである。 特別なデバイス番号をＵＳＢ２０に接続された各デバイスに割り当てることによって、キャビネット番号と宛先アドレス３５２（バイト１）を合わせて、デバイス（すなわち、ＳＩＮＣデバイス１００、Ｃ
ＬＵデバイス６０、およびＰＭ３デバイス７０）が識別される。

【００４６】ソースキャビネット番号３５４（バイト２）は、ソースキャビネット番号（すなわち、メッセージを発したデバイスを含むキャビネットの番号）であり、ソースアドレス３５６（バイト３）は、メッセージを送信した、デバイスのキャビネット内のアドレスである。 キャビネット内の宛先アドレスおよびソースアドレスを以下の表１に示す。

【００４７】

【表１】

【００４８】表１に見られるアドレスは、他とは異なる任意の値を用いることができるという点において、自由に決めることのできるものである。 名称の欄はあらかじめ定義されており、デバイスに自由に名称をつけることはできない。 デバイスが自身の名称（アドレス）および通信先のデバイスの名称（アドレス）を知ることができるように、全般的なネーミング方式を予め決めておくことが望ましい。 あるいは、ディレクトリサービスがそのようなネーミング方式にとってかわってもよい。

【００４９】コマンドバイト３５７（バイト４）は、受信モジュールにメッセージの処理の方法を指示する。 好ましい実施形態において用いられるコマンドおよび値のいくつかの具体例を以下に示す。

【００５０】 BusboyCmmdExecStatus ＝０×００ BusboyCmmdUnsolicitedStatus ＝０×０１、/*CLU/SINC/PM3/PDI to SUB */ BusboyCmmdBootNormal ＝０×０２、/*SUB to SINC */ BusboyCmmdBootType1 ＝０×０３、/*SUB to SINC */ BusboyCmmdTocCell ＝０×０４、/*SUB to SINC */ BusboyCmmdResetCell ＝０×０５、/*SUB to SINC */ BusboyCmmdResetYourself ＝０×０６、/*SUB to CLU/SINC/PM3/PDI */ BusboyHdrIdIcmHdrResponse ＝０×ｆ３、/*SINC to SUB */ コマンドの意味および値は、本発明に従って構築されたシステムの実施の詳細によって決定される。

【００５１】フラグバイト３５８（バイト５）は、フラグを表す。 フラグについては、後に図８に関してより詳細に説明される。 メッセージ長３５９（バイト６）は、
メッセージ長（最下位バイト）を表し、メッセージ長３
６１（バイト７）は、メッセージ長（最上位バイト）を表す。 メッセージ長は、メッセージにおけるバイトの数であり、メッセージヘッダ３５５の１２バイトを含む。
入力メッセージハンドラは、メッセージ長が１２バイトよりも大きいか否かをチェックすることで、メッセージ３５０のデータ部分３６０があるか否かを判断することができる。

【００５２】バイト８ ３６２からバイト１１ ３６７
は、応答を要する要求を発したソフトウェアモジュール（本例ではファームウェア更新モジュール２１１）を識別するプライベートデータを表す。 メッセージを送信する相手のデバイス（例えば、ＳＩＮＣデバイス１００）
に送信メッセージに対する返信を期待する場合、送信側のデバイスにおけるモジュール（例えば、サービスプロセッサ２００におけるファームウェア更新モジュール２
１１）は、識別子をバイト３６２、３６４、３６６、３
６７におけるヘッダのプライベートエリアに挿入することによって、自身の宛て先を知らせる。 応答側デバイスにおける応答モジュール（例えば、ＳＩＮＣデバイス１
００におけるファームウェア更新ルーチン１１９）は、
プライベートエリアの内容を返信メッセージにコピーするよう要求される。

【００５３】プライベートエリアにおける識別子は、発信デバイス上の入力メッセージハンドラ（例えば、サービスプロセッサ２００上のサービスプロセッサ入力メッセージハンドラ２５０）が、返信先モジュール（例えば、ファームウェア更新モジュール２１１応答キュー）
として認識することができる値である。 識別子は、例えば、元の要求を送信したモジュールにおいて呼び出す関数についての応答キューの識別子、またはアドレスでありうる。 サービスプロセッサ入力メッセージハンドラ２
５０は、プライベートエリア（ヘッダ３５５におけるバイト８からバイト１１）の内容に基づいて、すべての返信を指定されたモジュールに送信する。

【００５４】アドレス指定を説明するために、図７に示す発信元および宛先バイト３５１、３５２、３５４、３
５６は、デバイスを識別指定するものとする。 メッセージが（あるモジュールによって発せられた）コマンドであり、かつ宛先デバイスに２つ以上のコマンド処理モジュールがある場合、コマンドバイト３５７（バイト４）
の内容によって、所与のコマンドを処理する、デバイス内の特定のモジュールを識別することができる。 メッセージが（先に受信したコマンドに応答して発せされた）
返信メッセージである場合、コマンドバイト３５７（バイト４）の内容は、プライベートエリアバイト３６２、
３６４、３６６、および３６７（バイト８〜バイト１
１）の内容と合わせて、返信メッセージを渡すべきモジュールを指定する。 コマンドバイト３５７（バイト４）
の内容はまた、プライベートエリアバイト３６２、３６
４、３６６、および３６７（バイト８〜バイト１１）の内容と合わせて、異なるデバイスに対する複数の未処理要求を有するモジュールが、各デバイスからの返信メッセージを未処理の要求と結びつけることができるようにする。

【００５５】メッセージフォーマット３５０はまた、メッセージフォーマット３５０のオプションコマンドデータバイト３６８および３６９（バイト１２からバイト長＋１１まで）を含む、データ３６０も含む。 オプションコマンドデータは、オプションデータを含む。 データ３
６０は、０バイト以上のデータを含む可変長フィールドである。 このデータは、コマンドバイト３５７（バイト４）における特定のコマンドに関連するものである。 例えば、コマンドが「ＥＰＲＯＭセクタプログラム」である場合には、パケットのデータ部分は、ＥＰＲＯＭセクタにプログラムされるデータである。 コマンドが「状態応答」であり、かつパケットが先の「状態照会」メッセージの結果として送信される場合には、データ部分は、
実際のデバイス状態である。

【００５６】図８は、図７のフラグバイト３５８（バイト５）を示す概略図である。 図示のように、このフォーマットにおいては、フラグバイト３５８のビット４〜ビット７はメッセージ識別情報を含む。 ビット０およびビット１は、ＵＳＢ２０に接続されたＳＩＮＣ１００等、
個々のデバイスに要求する応答に応じてセットすることができる。 例えば、最下位ビット（ＬＳＢ）０がロジック「０」にセットされる場合は、図５のＳＩＮＣデバイス１００は、送信されたメッセージの受信の確認通知をする必要がないことを示す。 ＬＳＢ０がロジック「１」
にセットされる場合は、受信デバイス（すなわち、図５
に関して先に説明した例では、ＳＩＮＣデバイス１０
０）はメッセージの受信の確認通知をしなければならないことを示す。 同様に、フラグバイト３５８（バイト５）のビット１がロジック「０」にセットされる場合は、メッセージに含まれるコマンドの処理が成功したか失敗したかについて、メッセージの発信元に報告する必要がないことを示す。 同様に、ビット１がロジック「１」にセットされる場合は、メッセージに含まれるコマンドの処理が成功したか失敗したかについて、発信デバイスに報告しなければならないことを示す。

【００５７】 初期化再度、図５を参照して、標準ＵＳＢ初期化の一部として、ＵＳＢホストドライバ２２４は、デバイスがバスに接続されるときに、各デバイス（すなわち、ＳＩＮＣデバイス１００、ＣＬＵデバイス６０等）を列挙する（アドレスを割り当てる）。 （なお、これは物理レイヤアドレスであり、表１に示す論理レイヤアドレスとは異なることに留意する）。 その際、デバイスは、デバイス記述子をホストに戻す。 デバイス記述子によって、デバイスのタイプが識別される。 これは、ＵＳＢ通信の分野における当業者に良く知られている。 このとき、好ましい実施形態におけるデバイスは、それが、例えば、ＰＭ３デバイス７０、ＣＬＵデバイス６０、またはＳＩＮＣデバイス１００であると報告する。 デバイスはまた、表１に示す符号化を用いて、自身の固有のアドレス（例えば、
キャビネット０におけるＳＩＮＣ１００、ＳＩＮＣ番号２）も報告する。 これにより、ＵＳＢホストドライバ２
２４は、この特定のデバイスに適したキュー（例えば、
キュー２５６と、パイプ１１２および１１４）を初期化することができる。

【００５８】表１に示されるデバイスのアドレスは、デバイスの名称と同義であり固定されたものである。 これに対して、デバイスタイプおよび番号のアドレスを固定せず、動的に割り当てる方式を考えることもできる。 諸タイプのデバイスの組み合わせをより柔軟に行う必要がある場合に、このような方式の方が望ましいことがある。 もしそのようなシステムが設計されたとしても、他のエンティティがそのデバイスをアドレス指定することができるように、なお一つのデバイスごとに一つの「名称」を持たせておくべきである。 しかし、このような場合は、任意のデバイスが名称に対応するアドレスを得られるように、ディレクトリサービスを設けることが望ましい。 ディレクトリサービスの概念は、ネットワーキングの分野における当業者には周知である。

【００５９】この発明は例として次の実施形態を含む。

【００６０】（１） ユニバーサルシリアルバス（ＵＳ
Ｂ）（２０）をピアツーピアネットワークとして用いる方法であって、ルータ（２１８）を備えるホストプロセッサ（２００）をＵＳＢ（２０）に接続するステップと、それぞれ互いに対して、かつ前記ホストプロセッサ（２００）に対してピアである複数のデバイス（６０、
７０、１００）を前記ＵＳＢ（２０）に接続するステップと、前記複数のデバイス（６０、７０、１００）または前記ホストプロセッサ（２００）のうちの１つにおいて、メッセージ（３６０）を形成するステップと、前記メッセージ（３６０）の前にヘッダ（３５５）を付加するステップと、前記ルータ（２１８）および前記ＵＳＢ
（２０）を介して、前記メッセージ（３６０）を前記デバイス（６０、７０、１００）のうちの１つから他の任意のデバイスに、または前記ホストプロセッサ（２０
０）に直接伝送するステップと、を含む、方法。

【００６１】（２） 前記ヘッダ（３５５）は、前記デバイス（６０、７０、１００）のうちの一つを識別する複数のフィールドをさらに含む、上記（１）記載の方法。

【００６２】（３） 前記デバイス（６０、７０、１０
０）はそれぞれ、前記複数のフィールドを認識するよう構成されたロジック（１５０）をさらに備える、上記（１）記載の方法。

【００６３】（４） 前記ホストプロセッサ（２００）
は、前記ルータ（２１８）に関連する第１のデバイスドライバ（２５１）をさらに備え、前記デバイス（６０、
７０、１００）はそれぞれ、前記ルータ（２１８）における前記第１のデバイスドライバ（２５１）に対応する第２のデバイスドライバ（１０２）をさらに備え、前記第１のデバイスドライバ（２５１）および第２のデバイスドライバ（１０２）は、前記ルータ（２１８）と前記デバイス（６０、７０、１００）それぞれの間に論理接続（３２１）を確立するよう構成された、上記（１）記載の方法。

【００６４】（５） 前記論理接続（３２１）は、割り込みパイプ（１１２）と、バルクインパイプ（１１４）
と、バルクアウトパイプ（１１１）と、を含む、上記（４）記載の方法。

【００６５】（６） ユニバーサルシリアルバス（ＵＳ
Ｂ）（２０）をピアツーピアネットワークを用いるシステムであって、ホストメッセージハンドラ（２５０）を含み、メッセージ（３６０）の前にヘッダ（３５５）を付加するよう構成され、該ホストメッセージハンドラ（２５０）は、該ヘッダ（３５５）を認識するよう構成された、ホストプロセッサ（２００）と、前記ホストプロセッサ（２００）に連係され、それぞれデバイスメッセージハンドラ（１５０）を含み、前記メッセージ（３
６０）の前に前記ヘッダ（３５５）を付加するよう構成された複数のデバイス（６０、７０、１００）であって、前記デバイスメッセージハンドラ（１５０）もまた、前記ヘッダ（３５５）を認識するよう構成された、
複数のデバイス（６０、７０、１００）と、前記ホストプロッサ（２００）に連係された前記複数のデバイス（６０、７０、１００）のうちの任意のデバイスと前記ホストプロセッサ（２００）間で、ユニバーサルシリアルバス（ＵＳＢ）（２０）を介して前記メッセージ（３
６０）を直接ルーティングするよう構成された、前記ホストプロセッサ（２００）に連係されたルータ（２１
８）と、を備える、システム。

【００６６】（７） 前記ヘッダ（３５５）は、前記デバイス（６０、７０、１００）のうちの一つを識別する複数のフィールドをさらに含む、上記（６）記載のシステム。

【００６７】（８） 前記ホストプロセッサ（２００）
は、前記ルータ（２１８）に関連する第１のデバイスドライバ（２５１）をさらに備え、前記デバイス（６０、
７０、１００）はそれぞれ、前記ルータ（２１８）における前記第１のデバイスドライバ（２５１）に対応する第２のデバイスドライバ（１０２）をさらに備え、前記第１のデバイスドライバ（２５１）および第２のデバイスドライバ（１０２）は、前記ルータ（２１８）と前記デバイス（６０、７０、１００）それぞれの間に論理接続（３２１）を確立するよう構成された、上記（６）記載のシステム。

【００６８】（９） 前記論理接続（３２１）は、割り込みパイプ（１１２）と、バルクインパイプ（１１４）
と、バルクアウトパイプ（１１１）と、を含む、上記（８）記載のシステム。

【００６９】（１０） 前記デバイスメッセージハンドラ（１５０）は、前記メッセージ（３６０）を前記バルクアウトパイプ（１１１）から受信するよう構成された入力メッセージハンドラ（１５１）と、前記ヘッダ（３
５５）を前記割り込みパイプ（１１２）に挿入するとともに、前記メッセージ（３６０）に関連するデータを前記バルクインパイプ（１１４）に挿入するよう構成された出力メッセージハンドラ（１５２）と、をさらに備える、上記（９）記載のシステム。

【００７０】本発明の原理から本質的に逸脱せずに、本発明の好ましい実施形態に、多くの変更および変形を行いうることが、当業者には理解されよう。 例えば、多数のデバイスがＵＳＢを介して通信する任意のシステムにおいて、本発明を用いることができる。 このような変更および変形はすべて、特許請求の範囲に規定される本発明の範囲に包含される。

【図面の簡単な説明】

【図１】 本発明の概念を示すために用いられる、サーバシステムを示すブロック図。

【図２】 図１のユーティリティサブシステムを示すブロック図。

【図３】 本発明の一態様によるプロトコルスタック３
００を示す概略図。

【図４】 本発明によるメッセージフォーマットを示す概略図。

【図５】 図２のサービスプロセッサと、システム抽象レイヤインタフェースネットワークコントローラ（ＳＩ
ＮＣ）デバイス間の接続性を示すブロック図。

【図６】 図５においてキューとして実施される、図３
のパイプを示す略図。

【図７】 図４のメッセージフォーマットの通信メッセージの一例を示す概略図。

【図８】 図７の通信プロトコルフラグバイトを示す概略図。

【符号の説明】

２０ ユニバーサルシリアルバス ６０、７０、１００ デバイス １０２ 第２のデバイスドライバ １１１ バルクアウトパイプ １１２ 割り込みパイプ １１４ バルクインパイプ １５０ ロジック、デバイスメッセージハンドラ １５１ 入力メッセージハンドラ １５２ 出力メッセージハンドラ ２００ ホストプロセッサ ２１８ ルータ ２５０ ホストメッセージハンドラ ２５１ 第１のデバイスドライバ ３２１ 論理接続 ３５５ ヘッダ ３６０ メッセージ

フロントページの続き (72)発明者 ロナルド・イー・ギルバート・ジュニア アメリカ合衆国75093テキサス州プラノ、 ミスティ・ヘヴン・レーン 2017 (72)発明者 クリスチーヌ・コーバー アメリカ合衆国75287テキサス州ダラス、 ホライゾン・エヌ・パークウェイ 4341、 ナンバー 131 Ｆターム(参考） 5B014 GC01 5K032 AA09 BA04 CC01 CD01 DA01 DB26