(57)【特許請求の範囲】
【請求項１】
ＰＣＩｅネットワークにおいてパケットを処理するシステムであって、
受信されるタグ識別子と、リクエスト側デバイスを識別するリクエスト側デバイス識別子とを含むＰＣＩｅポステッド・ライト・パケットを受信するようＰＣＩｅスイッチと通信する受信器と、
前記リクエスト側デバイスの期待されるタグ識別子を記憶するストレージ・メカニズムと、
前記受信されるタグ識別子と、前記期待されるタグ識別子とを比較し、前記受信されるタグ識別子が前記期待されるタグ識別子と一致しないことに応答して、エラー・フラグをセットして、前記受信されるタグ識別子および前記期待されるタグ識別子を同期させるリカバリ処理を開始させる比較器と、
を含み、
前記リクエスト側デバイスおよび前記ＰＣＩｅポステッド・ライト・パケットを受信する受信側デバイスは、前記受信されるタグ識別子および前記期待されるタグ識別子の開始値を含むＰＣＩ機能構造によって同期される、
前記システム。
【請求項２】
前記比較の完了に応答して、前記リクエスト側デバイスの前記期待されるタグ識別子をインクリメントするインクリメンタをさらに含む、請求項１に記載のシステム。
【請求項３】
前記受信されるタグ識別子および前記期待されるタグ識別子は、前記リクエスト側デバイスと、前記受信側デバイスとの間で定期的に同期される、請求項１または請求項２に記載のシステム。
【請求項４】
前記受信側デバイスは、ＰＣＩｅルート・コンプレックス・デバイスであり、前記ストレージ・メカニズムは、リクエスト側デバイス識別子によって索引付けされているデバイス・テーブルを含む、請求項１〜３のいずれかに記載のシステム。
【請求項５】
前記受信側デバイスは、ＰＣＩｅエンド・ポイントであり、前記ストレージ・メカニズムは、前記リクエスト側デバイスに対応するレジスタを含む、請求項１〜４のいずれかに記載のシステム。
【請求項６】
リクエスト側デバイスにあるポステッド・ライト・パケット・メカニズムであって、受信側デバイスを識別するＰＣＩｅポステッド・ライト・パケットにアクセスして、前記受信側デバイスに対応する現在のタグ識別子を前記ポステッド・ライト・パケット内のタグ・フィールドに挿入する、前記ポステッド・ライト・パケット・メカニズムと、
前記リクエスト側デバイスにあるストレージ・メカニズムであって、前記受信側デバイスに対応する前記現在のタグ識別子を記憶する、前記ストレージ・メカニズムと、
前記リクエスト側デバイスにある送信器であって、ＰＣＩｅスイッチを介して前記受信側デバイスに前記ＰＣＩｅポステッド・ライト・パケットを送信するよう前記ＰＣＩｅスイッチと通信する、前記送信器と、
をさらに含む、請求項１〜５のいずれかに記載のシステム。
【請求項７】
前記リクエスト側デバイスにあるインクリメンタであって、前記挿入の完了に応答して、前記受信側デバイスに対応する前記現在のタグ識別子をインクリメントする、前記インクリメンタをさらに含む、請求項６に記載のシステム。
【請求項８】
ＰＣＩｅネットワークにおいてパケットを処理する方法であって、
受信されるタグ識別子と、リクエスト側デバイスを識別するリクエスト側デバイス識別子とを含むＰＣＩｅポステッド・ライト・パケットを、受信側デバイスにて受信するステップと、
前記リクエスト側デバイスの期待されるタグ識別子を判断するステップと、
前記受信されるタグ識別子と、前記期待されるタグ識別子とを比較するステップと、
前記受信されるタグ識別子が前記期待されるタグ識別子と一致しないことに応答して、エラー・フラグをセットして、前記受信されるタグ識別子および前記期待されるタグ識別子を同期させるリカバリ処理を開始させるステップと、
を含み、
前記リクエスト側デバイスおよび前記ＰＣＩｅポステッド・ライト・パケットを受信する受信側デバイスは、前記受信されるタグ識別子および前記期待されるタグ識別子の開始値を含むＰＣＩ機能構造によって同期される、方法。
【請求項９】
前記方法は、前記比較の完了に応答して、前記リクエスト側デバイスの前記期待されるタグ識別子をインクリメントするステップをさらに含む、請求項８に記載の方法。
【請求項１０】
受信側デバイスを識別するＰＣＩｅポステッド・ライト・パケットに、リクエスト側デバイスにてアクセスするステップと、
前記受信側デバイスに対応する現在のタグ識別子を判断するステップと、
前記ポステッド・ライト・パケット内のタグ・フィールドに前記現在のタグ識別子を挿入するステップと、
ポステッド・ライト・パケットを前記受信側デバイスに送信するステップと、
をさらに含む、請求項８または請求項９に記載の方法。
【請求項１１】
前記挿入の完了に応答して、前記受信側デバイスに対応する前記現在のタグ識別子をインクリメントするステップをさらに含む、請求項８〜１０のいずれかに記載の方法。
【請求項１２】
前記リクエスト側デバイスにある前記現在のタグ識別子は、前記受信側デバイスにある期待されるタグ識別子と定期的に同期される、請求項８〜１１のいずれかに記載の方法。
【請求項１３】
前記リクエスト側デバイスは、前記ＰＣＩｅネットワーク内のルート・コンプレックス・デバイスであり、現在のタグ識別子を判断する前記ステップは、アドレス・ルックアップ・テーブルおよび下りタグ・テーブルのうちの１つ以上にアクセスするステップを含む、請求項８〜１２のいずれかに記載の方法。
【請求項１４】
前記リクエスト側デバイスは、ＰＣＩｅネットワーク内のエンド・ポイントであり、現在のタグ識別子を判断する前記ステップは、前記受信側デバイスに対応するレジスタを読み取るステップを含む、請求項８〜１３のいずれかに記載の方法。
【請求項１５】
コンピュータ・プログラム・コードを含むコンピュータ・プログラムであって、前記コンピュータ・プログラム・コードは、コンピュータ・システムにロードされ前記コンピュータ・システム上で実行されると、前記コンピュータ・システムに、請求項８〜１４のいずれかに記載の方法の前記ステップすべてを実行させる、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、全般的にコンピュータ・システムに関し、特に、ペリフェラル・コンポーネント・インターコネクト・エクスプレス（ＰＣＩｅ：ｐｅｒｉｐｈｅｒａｌ  ｃｏｍｐｏｎｅｎｔ  ｉｎｔｅｒｃｏｎｎｅｃｔ  ｅｘｐｒｅｓｓ）ネットワークにおけるデータの書き込みに関する。
【背景技術】
【０００２】
ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ  ｃｏｍｐｏｎｅｎｔ  ｉｎｔｅｒｃｏｎｎｅｃｔ）は、コンピュータ内でハードウェア・デバイスを接続するコンピュータ・バス・アーキテクチャである。ＰＣＩエクスプレス（ＰＣＩｅ）は、ＰＣＩにより採用された共有パラレル・バス・アーキテクチャの代わりに、ポイント・ツー・ポイント・シリアル・リンクを利用する、より新しいバージョンのＰＣＩである。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
ＰＣＩｅを採用するコンピュータ・システムは、パケットを送ることによって通信する。
【課題を解決するための手段】
【０００４】
したがって、本発明は第１の側面において、ＰＣＩｅネットワークにおいてパケットを処理するシステムを提供し、このシステムは、受信されるタグ識別子（ｒｅｃｅｉｖｅｄ  ｔａｇ  ｉｄｅｎｔｉｆｉｅｒ）と、リクエスト側デバイスを識別するリクエスト側デバイス識別子（ｒｅｑｕｅｓｔｉｎｇ  ｄｅｖｉｃｅ  ｉｄｅｎｔｉｆｉｅｒ）とを含むＰＣＩｅポステッド・ライト・パケット（ｐｏｓｔｅｄ  ｗｒｉｔｅ  ｐａｃｋｅｔ）を受信するようＰＣＩｅスイッチと通信する受信器と、リクエスト側デバイスの期待されるタグ識別子（ｅｘｐｅｃｔｅｄ  ｔａｇ  ｉｄｅｎｔｉｆｉｅｒ）を記憶するストレージ・メカニズムと、受信されるタグ識別子と、期待されるタグ識別子とを比較し、受信されるタグ識別子が期待されるタグ識別子と一致しないことに応答して、エラー・フラグをセットする比較器とを含む。
【０００５】
このシステムは、比較の完了に応答して、リクエスト側デバイスの期待されるタグ識別子をインクリメントするインクリメンタをさらに含む。受信されるタグ識別子および期待されるタグ識別子は、リクエスト側デバイスと、受信側デバイスとの間で定期的に同期されることが好ましい。受信側デバイスは、ＰＣＩｅルート・コンプレックス・デバイスであり、ストレージ・メカニズムは、リクエスト側デバイス識別子によって索引付けされているデバイス・テーブルを含むことが好ましい。受信側デバイスは、ＰＣＩｅエンド・ポイントであり、ストレージ・メカニズムは、リクエスト側デバイスに対応するレジスタを含むことが好ましい。このシステムは、リクエスト側デバイスにあるポステッド・ライト・パケット・メカニズムであって、受信側デバイスを識別するＰＣＩｅポステッド・ライト・パケットにアクセスして、受信側デバイスに対応する現在のタグ識別子をポステッド・ライト・パケット内のタグ・フィールドに挿入する、該ポステッド・ライト・パケット・メカニズムと、リクエスト側デバイスにあるストレージ・メカニズムであって、受信側デバイスに対応する現在のタグ識別子を記憶する、該ストレージ・メカニズムと、リクエスト側デバイスにある送信器であって、ＰＣＩｅスイッチを介して受信側デバイスにＰＣＩｅポステッド・ライト・パケットを送信するようＰＣＩｅスイッチと通信する、該送信器とをさらに含むとよい。システムは、リクエスト側デバイスにあるインクリメンタであって、挿入の完了に応答して、受信側デバイスに対応する現在のタグ識別子をインクリメントする、該インクリメンタをさらに含むとよい。
【０００６】
第２の側面において、本発明は、ＰＣＩｅネットワークにおいてパケットを処理する方法を提供し、本方法は、受信されるタグ識別子と、リクエスト側デバイスを識別するリクエスト側デバイス識別子とを含むＰＣＩｅポステッド・ライト・パケットを、受信側デバイスにて受信するステップと、リクエスト側デバイスの期待されるタグ識別子を判断するステップと、受信されるタグ識別子と、期待されるタグ識別子とを比較するステップと、受信されるタグ識別子が期待されるタグ識別子と一致しないことに応答して、エラー・フラグをセットするステップとを含む。本方法は、比較の完了に応答して、リクエスト側デバイスの期待されるタグ識別子をインクリメントするステップをさらに含むことが好ましい。本方法は、受信側デバイスを識別するＰＣＩｅポステッド・ライト・パケットに、リクエスト側デバイスにてアクセスするステップと、受信側デバイスに対応する現在のタグ識別子を判断するステップと、ポステッド・ライト・パケット内のタグ・フィールドに現在のタグ識別子を挿入するステップと、ポステッド・ライト・パケットを受信側デバイスに送信するステップとをさらに含むとよい。本方法は、挿入の完了に応答して、受信側デバイスに対応する現在のタグ識別子をインクリメントするステップをさらに含むとよい。リクエスト側デバイスにある現在のタグ識別子は、受信側デバイスにある期待されるタグ識別子と定期的に同期されることが好ましい。リクエスト側デバイスは、ＰＣＩｅネットワーク内のルート・コンプレックス・デバイスであり、現在のタグ識別子を判断するステップは、アドレス・ルックアップ・テーブルおよび下りタグ・テーブル（ｄｏｗｎ−ｂｏｕｎｄ  ｔａｇ  ｔａｂｌｅ）のうちの１つ以上にアクセスするステップを含むことが好ましい。リクエスト側デバイスは、ＰＣＩｅネットワーク内のエンド・ポイントであり、現在のタグ識別子を判断するステップは、受信側デバイスに対応するレジスタを読み取るステップを含むことが好ましい。
【０００７】
第３の側面において、コンピュータ・プログラム・コードを含むコンピュータ・プログラムが提供され、コンピュータ・プログラム・コードは、コンピュータ・システムにロードされコンピュータ・システム上で実行されると、前記コンピュータ・システムに、第２の側面の方法のステップすべてを実行させる。
【０００８】
例示の実施形態は、ペリフェラル・コンポーネント・インターコネクト・エクスプレス（ＰＣＩｅ）ネットワークにおいてパケットを処理するコンピュータ・プログラム製品を含む。コンピュータ・プログラム製品は、処理回路によって読み取り可能であり方法を実行するよう処理回路によって実行される命令を記憶する、有形のストレージ媒体を含む。この方法は、受信されるタグ識別子と、リクエスト側デバイスを識別するリクエスト側デバイス識別子とを含むＰＣＩｅポステッド・ライト・パケットを、受信側デバイスにて受信するステップを含む。期待されるタグ識別子が、リクエスト側デバイスに関して判断される。受信されるタグ識別子が、期待されるタグ識別子と比較される。受信されるタグ識別子が期待されるタグ識別子と一致しなければ、エラー・フラグがセットされる。
【０００９】
別の例示の実施形態は、ＰＣＩｅネットワークにおいてパケットを処理するシステムである。このシステムは、ＰＣＩｅポステッド・ライト・パケットを受信するようＰＣＩｅスイッチと通信する受信器を含む。ＰＣＩｅポステッド・ライト・パケットは、受信されるタグ識別子と、リクエスト側デバイスを識別するリクエスト側デバイス識別子とを含む。システムは、リクエスト側デバイスの期待されるタグ識別子を記憶するストレージ・メカニズムも含む。このシステムは、受信されるタグ識別子と、期待されるタグ識別子とを比較して、受信されるタグ識別子が期待されるタグ識別子と一致しなければ、エラー・フラグをセットする比較器をさらに含む。
【００１０】
別の例示の実施形態は、ＰＣＩｅネットワークにおいてパケットを処理する方法である。本方法は、受信されるタグ識別子と、リクエスト側デバイスを識別するリクエスト側デバイス識別子とを含むＰＣＩｅポステッド・ライト・パケットを、受信側デバイスにて受信するステップを含む。期待されるタグ識別子が、リクエスト側デバイスに関して判断される。受信されるタグ識別子が、期待されるタグ識別子と比較される。受信されるタグ識別子が期待されるタグ識別子と一致しなければ、エラー・フラグがセットされる。
【００１１】
さらなる例示の実施形態は、ＰＣＩｅネットワークにおいてパケットを処理するコンピュータ・プログラム製品である。コンピュータ・プログラム製品は、処理回路によって読み取り可能であり方法を実行するよう処理回路によって実行される命令を記憶する、有形のストレージ媒体を含む。本方法は、受信側デバイスを識別するＰＣＩｅポステッド・ライト・パケットに、リクエスト側デバイスにてアクセスするステップを含む。受信側デバイスに対応する現在のタグ識別子が判断される。現在のタグ識別子が、ポステッド・ライト・パケット内のタグ・フィールドに挿入される。ポステッド・ライト・パケットは、ＰＣＩｅネットワークを介して受信側デバイスに送信される。
【００１２】
さらなる例示の実施形態は、ＰＣＩｅネットワークにおいてパケットを処理するシステムを含む。このシステムは、リクエスト側デバイスにあるポステッド・ライト・パケット・メカニズムであって、受信側デバイスを識別するＰＣＩｅポステッド・ライト・パケットにアクセスして、受信側デバイスに対応する現在のタグ識別子をポステッド・ライト・パケット内のタグ・フィールドに挿入する、該ポステッド・ライト・パケット・メカニズムを含む。このシステムはさらに、リクエスト側デバイスにあるストレージ・メカニズムであって、受信側デバイスに対応する現在のタグ識別子を記憶する、該ストレージ・メカニズムを含む。このシステムは、リクエスト側デバイスにありＰＣＩｅスイッチと通信する送信器をさらに含み、送信器は、ＰＣＩｅスイッチを介して受信側デバイスにＰＣＩｅポステッド・ライト・パケットを送信するためのものである。
【００１３】
以下、添付の図面を参照しながら、単なる例として本発明の好適な実施形態について記載する。
【図面の簡単な説明】
【００１４】
【図１】例示の実施形態によって実装されるとよいＰＣＩｅネットワークを示す。
【図２】例示の実施形態によって実装されるとよいＰＣＩｅパケット・ヘッダおよびペイロード・フォーマットを示す。
【図３】例示の実施形態によって実装されるとよい、シーケンシャル・タグを使用してポステッド・ライト・パケットを生成するプロセスを示す。
【図４】例示の実施形態によって実装されるとよい、シーケンシャル・タグを使用してポステッド・ライト・パケットを受信するプロセスを示す。
【図５】例示の実施形態によって実装されるとよい、ルート・コンプレックスおよび複数のエンド・ポイントを含むＰＣＩｅネットワークを示す。
【図６】例示の実施形態により実装されるとよいＰＣＩ機能構造を示す。
【図７】例示の実施形態により実装されるとよい製品を示す。
【発明を実施するための形態】
【００１５】
ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）およびＰＣＩエクスプレス（ＰＣＩｅ）は、「ポステッド・ライト・メモリ・リクエスト」の概念を上りおよび下りの両方向において実装し、ポステッド・ライト・コマンド、ライト・アドレス、およびライト・データを含むパケットが、ライトが生じる最終宛先（例えばエンド・ポイントまたはルート・コンプレックス）に到着する前に、中間の位置（例えばＰＣＩｅスイッチ）にポストされる。ポステッド・ライト・パケットに関連する完了はないため、それらが損失されても、それを示すものはなく、ポステッド・ライト・パケットの損失を検出するメカニズムはない。ＰＣＩｅの問題の１つは、ＰＣＩｅ、およびＰＣＩｅ−ＰＣＩｅブリッジ、ルート・コンプレックス、スイッチ、およびエンド・ポイントの追加された複雑性が原因で、ポステッド・ライト・メモリ・リクエストをサイレントに落とす、重複させる、またはその順番を変える可能性が、小さいながらもゼロではなくなっているということである。したがって、パケット損失、重複パケット、またはパケットの順序狂いがあると、ＰＣＩｅにおけるポステッド・ライト・メモリ・リクエストの使用は、ホストまたはアダプタ・メモリに穴（すなわち未知値）を残すことになり、こうした穴がデータ完全性の損失のあり得る状態を生じることもある。
【００１６】
例示の実施形態は、ＰＣＩｅパケット・ヘッダのトランザクション識別子内の、ＰＣＩｅにより定義されたヘッダ・タグ・フィールドの新たな定義を含む。この新たな定義は、タグ・フィールドを、リクエスタによって生成されコンプリータによって検証されるエンド・ツー・エンド・シーケンス番号として使用する。新たに定義されたタグ・フィールドをコントロールおよび初期化するために、新たな機能構造が定義される。例示の実施形態では、ポステッド・メモリ・ライト・パケットのエンド・ツー・エンド検査を提供するためのタグ・フィールドの新たな使用によって、ＰＣＩｅスイッチが影響を受けることはないままである。ＰＣＩｅに関する詳細は、２００６年１２月２０日の「ＰＣＩ  Ｅｘｐｒｅｓｓ  Ｂａｓｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，Ｒｅｖｉｓｉｏｎ  ２．０」、ＰＣＩ−ＳＩＧを参照されたい。
【００１７】
図１は、例示の実施形態によって実装されるとよいＰＣＩｅネットワークを示す。図１は、ＰＣＩｅスイッチ１０４を介して通信するルート・コンプレックス・デバイス１０２（例えばホスト・システムに位置する）および複数のエンド・ポイント・デバイス１０６（例えばストレージ・コントローラ、ネットワーク・アダプタなど）を含む。本願明細書で使用される「リクエスト側デバイス」という用語は、ポステッド・メモリ・ライト・リクエストが生成される、ＰＣＩｅネットワーク内のデバイスを指す。リクエスト側デバイスは、ルート・コンプレックス・デバイス１０２またはエンド・ポイント・デバイス１０６のいずれかとするとよい。本願明細書で使用される「受信側デバイス」という用語は、ポステッド・メモリ・ライト・リクエストを受信し、メモリ・ライトを完了する（すなわち、指定されたデータを指定されたアドレスに書き込む）、ＰＣＩｅネットワーク内のデバイスを指す。受信側デバイスは、ルート・コンプレックス・デバイス１０２またはエンド・ポイント・デバイス１０６のいずれかとするとよい。受信側デバイスは、本願明細書において「コンプリータ」または「コンプリータ・デバイス」とも呼ばれることもある。本願明細書で使用される「ＰＣＩｅデバイス」という用語は、ＰＣＩｅネットワーク内で通信する（例えばＰＣＩｅスイッチ１０４を介して）デバイスを指す。ルート・コンプレックス・デバイス１０２およびエンド・ポイント・デバイス１０６は、どちらもＰＣＩｅデバイスの例である。
【００１８】
例示の実施形態では、ＰＣＩｅスイッチ１０４は、グレッグ（Ｇｒｅｇｇ）の、本願と共通譲渡の米国特許第７，５１９，７６１号で開示されたものなどの、トランスペアレントなＰＣＩベースのマルチホスト・スイッチ１０４であり、スイッチ１０４を複数のホストに連結するための複数の北向きポート（ｎｏｒｔｈ  ｆａｃｉｎｇ  ｐｏｒｔ）を備えて構成され得る。マルチホスト・スイッチ１０４は、様々なスイッチ構成に含まれることが可能であり、１つのマルチホスト・スイッチを有する構成、複数のマルチホスト・スイッチを有する構成、ならびに１つ以上のマルチホスト・スイッチおよび１つ以上の単一ホスト・スイッチを含む構成が含まれる。スイッチ１０４は、スイッチを経由してパケットを正確にルーティングするためのコントロールを含むよう設計されている。
【００１９】
図２は、例示の実施形態によって実装されるとよいＰＣＩｅパケット・ヘッダおよびペイロードのフォーマットを示す。標準のＰＣＩｅパケット・ヘッダ・フォーマットが、例示の実施形態によって実装されるが、１つの例外として、ポステッド・ライトのリクエスタによって生成されポステッド・ライトのコンプリータによって検証されるエンド・ツー・エンド・シーケンス番号として、タグ・フィールド２０２が再定義される。タグ・フィールド２０２をこのように使用することによって、ポステッド・ライトのコンプリータは、リクエスタによって送られたパケットがすべて受信された（すなわち、順序正しく一度）ことを検証することができる。
【００２０】
図２に示されている例示のポステッド・メモリ・ライト・リクエスト・パケットは、‘０００００’ｂの「タイプ」フィールドによって識別される。アドレス・フィールドが、示されているように８バイトであれば、その結果フォーマット・フィールド（「Ｆｍｔ」）は‘１１’ｂであり、アドレス・フィールドが４バイトであれば、フォーマット・フィールドは‘１０’ｂである。「Ｒ」ビットおよび「予約」フィールドは予約されており、ゼロにセットされる。「ＴＣ」フィールドは、トラフィック・クラスであり、「ＴＤ」フィールドは、パケットの最後にトランザクション・レイヤ・パケット（ＴＬＰ：ｔｒａｎｓａｃｔｉｏｎ  ｌａｙｅｒ  ｐａｃｋｅｔ）ダイジェスト（４バイトの巡回冗長検査すなわち「ＣＲＣ（ｃｙｃｌｉｃａｌ  ｒｅｄｕｎｄａｎｃｙ  ｃｈｅｃｋ）」が付加されているかどうかを示す。「ＥＰ」フィールドは、ＴＬＰがポイズンド（ｐｏｉｓｏｎｅｄ）であるかどうかを示し、「Ａｔｔｒ」（属性）フィールドは、リラックス・オーダリング（ｒｅｌａｘｅｄ  ｏｒｄｅｒｉｎｇ）およびスヌープなし（ｎｏ  ｓｎｏｏｐ）ビットを含み、「長さ」フィールドは、４バイト単位の量でのパケット・データ・ペイロードの長さである。「リクエスタＩＤ」（ＲＩＤ：Ｒｅｑｕｅｓｔｅｒ  ＩＤ）フィールドは、リクエスタのバス番号（８ビット）、デバイス番号（３ビット）、および機能番号（５ビット）を示す。
【００２１】
「最終ＤＷ  ＢＥ」および「先頭ＤＷ  ＢＥ」フィールドは、ダブル・ワード・バイト・イネーブルであり、それぞれが４ビットで、最後および先頭のダブル・ワード（４バイト・ダブル・ワード）における有効なペイロード・バイトを示す。アドレス・フィールドは、コンプリータ（本願明細書では受信側デバイスとも呼ばれる）でパケット・データ・ペイロードが書き込まれる場所をポイントする。８バイト・アドレスは「アドレス［６３：３２］」および「アドレス［３１：２］」に含まれ、４バイト・アドレスはアドレス［３１：２］に含まれ、その場合アドレス［６３：３２］は存在しない。書き込まれるデータを含む「パケット・データ・ペイロード」フィールドは、４〜４０９６バイトの長さとするとよい。
【００２２】
図３は、例示の実施形態によって実装されるとよい、シーケンシャル・タグを使用してポステッド・ライト・パケットを生成するプロセスを示す。図３に示されているプロセスは、リクエスト側デバイスの例示の実施形態によって実装される追加の処理（すなわち標準のＰＣＩｅ処理に加えて）を含み、タグ・フィールド２０２を、損失された、重複した、および順序の狂ったパケットを識別するためのシーケンシャル・カウンタとして利用する。図３に示されている処理の全部または一部が、ポステッド・ライト・パケット・メカニズムによって実装され得る。図３に示されている処理は、ハードウェアまたはソフトウェアあるいはその両方によって実装され、リクエスト側デバイス内に位置するか、またはリクエスト側デバイスによりアクセス可能であるとよい。ブロック３０２において、受信側デバイスへのポステッド・ライト・パケットが、リクエスト側デバイスによって生成されている。ポステッド・ライト・パケットは、例えば下位および上位アドレス・フィールドによって、受信側デバイスを識別する。ブロック３０４において、リクエスタ・デバイスは、受信側デバイスの現在のタグ識別子を判断する。例示の実施形態では、現在のタグ識別子は、リクエスタ・デバイス上の、またはリクエスタ・デバイスによってアクセス可能な、レジスタ、バックアップ・テーブル、またはその他のストレージ・メカニズムに記憶されている。ブロック３０６にて、現在のタグ識別子は、ポステッド・ライト・パケット内のタグ・フィールド２０２に書き込まれる。ブロック３０８にて、受信側デバイスの現在のタグ識別子がインクリメントされ（例えばインクリメンタによって）、続いてブロック３１０にて、ポステッド・ライト・データ・パケットが受信側デバイスに送られる（例えば送信器を介して）。例示の実施形態では、現在のタグ識別子は、パケットがポステッド・ライト・データ・リクエストを示すときにのみタグ・フィールドに書き込まれる。
【００２３】
図４は、例示の実施形態によって実装されるとよい、シーケンシャル・タグを使用してポステッド・ライト・パケットを受信するプロセスを示す。図４に示されているプロセスは、受信側デバイスの例示の実施形態によって実装される追加の処理（すなわち標準のＰＣＩｅ処理に加えて）を含み、タグ・フィールド２０２を、損失された、重複した、または順序の狂ったパケットを識別するためのシーケンシャル・カウンタとして利用する。処理は、ハードウェアまたはソフトウェアあるいはその両方によって実装され、受信側デバイス内に位置するか、または受信側デバイスによりアクセス可能であるとよい。ブロック４０２にて、ポステッド・ライト・パケットが受信側デバイスにて受信される（例えば受信器を介して）。ポステッド・ライト・パケットは、リクエスト側デバイスからである。ブロック４０４にて、受信されるタグ識別子が、受信されたパケットのタグ・フィールド２０２から抽出される。ブロック４０６において、リクエスト側デバイスに関連する、期待されるタグ識別子が判断される。例示の実施形態では、リクエスト側デバイスの期待されるタグ識別子は、受信側デバイス上の、または受信側デバイスによってアクセス可能な、レジスタ、ルック・アップ・テーブル、またはその他のストレージ・メカニズムに記憶されている。ブロック４１０にて、受信されるタグ識別子が、期待されるタグ識別子と等しいかどうかが判断される（例えば比較器を使用して）。等しくなければ、続いてブロック４１２が実行され、損失された、重複した、または順番の狂ったパケットを示すエラー・フラグがセットされる。例示の実施形態では、エラー・フラグをセットすることは、標準エラーＰＣＩｅエラー／リカバリ処理の実行を生じさせる。ブロック４１０における判断で、受信されるタグが期待されるタグと等しければ、続いてブロック４１４にて、受信されたパケットの処理が続く。ブロック４０８にて、次のパケットの受信に備えて、リクエスト側デバイスに関連する期待されるタグ識別子がインクリメントされる（例えばインクリメンタを使用して）。
【００２４】
図５は、複数のＰＣＩｅブリッジ（この例ではＢ１〜Ｂ５）を含むＰＣＩｅスイッチ５０６によって相互接続されているルート・コンプレックス５０２および複数のエンド・ポイント５０４を有するＰＣＩｅネットワークを示す。図５に示されているＰＣＩｅネットワーク、またはシステムは、損失された、重複した、および順序の狂ったポステッド・ライト・パケットを検出する例示の実施形態によって実装されるとよい。図５に示されている実施形態では、各エンド・ポイント５０４が単一のデバイスのルート・コンプレックス５０２と通信するが、他の例示の実施形態では、エンド・ポイントは複数のデバイスと通信する。
【００２５】
図５に示されているエンド・ポイント５０４はそれぞれ、ルート・コンプレックス５０２に送るポステッド・メモリ・ライト・リクエストの現在のタグ識別子値を含む単一のレジスタと、ルート・コンプレックス５０２から受信するポステッド・メモリ・ライト・リクエストの期待されるタグ識別子値を含む単一のレジスタとを含む。さらに、エンド・ポイント５０４はそれぞれ、パケットを送受信する受信器／送信器５２２、タグ識別子値をインクリメントする１つまたは２つのインクリメンタ、および期待されるタグ識別子値と、受信されるタグ識別子値とを比較する１つまたは２つの比較器を含む。例示の実施形態では、エンド・ポイント５０４は、エンド・ポイント５０４が受信側デバイスのみであるか、またはリクエスト側デバイスのみであるかに応じて、受信器または送信器のいずれかを有してもよい。例示の実施形態では、エンド・ポイントが２つ以上のデバイスと通信する場合、エンド・ポイントは、追加のタグ（単数または複数）を記憶する追加のレジスタ（単数または複数）を少なくとも含み、さらに任意選択で、追加のインクリメンタまたは比較器あるいはその両方を含む。
【００２６】
図５に示されている例示のルート・コンプレックス５０２は、受信器／送信器５２４、デバイス・テーブル５０８、リクエスタ識別子（ＲＩＤ）連想メモリ（ＣＡＭ：ｃｏｎｔｅｎｔ  ａｄｄｒｅｓｓａｂｌｅ  ｍｅｍｏｒｙ）、比較器５１２、およびインクリメンタ５１４を含み、これらは、エンド・ポイント５０４から上りポステッド・メモリ・ライト・パケットが受信されると利用される。当該技術分野で既知のように、ＣＡＭの使用は、ＲＩＤとエンド・ポイントとを関連付ける一方法である。この関連付けを行う他の方法が、別の例示の実施形態によって実装されてもよい。図５に示されているように、エンド・ポイント５０４は、ルート・コンプレックス５０２に送られる上りポステッド・ライト・リクエスト・パケットに追加されるべきタグの現在のタグ識別子値を記憶するレジスタ（「ＵｐＴａｇＲｅｇ」）を含む。パケットが上り方向で受信されるときは、ルート・コンプレックス５０２が受信側デバイスであり、エンド・ポイント５０４がリクエスト側デバイスである。例示の実施形態では、ルート・コンプレックス５０２は、ルート・コンプレックス５０２が受信側デバイスのみであるか、またはリクエスト側デバイスのみであるかに応じて、受信器または送信器のいずれかを有してもよい。例示の実施形態では、シーケンシャル・タグを実装するために必要な追加の処理と共に、標準のＰＣＩｅ処理が実行される。
【００２７】
図５に示されているように、ルート・コンプレックス５０２によって、受信器／送信器５２４を介してパケットが受信され、ＲＩＤ  ＣＡＭ５１０が、デバイス・テーブル５０８への索引として利用される。ポステッド・ライト・パケットは、エンド・ポイント５０４によってパケットに挿入された、受信されるタグ識別子を含むタグ・フィールド２０２を含む。図５に示されている実施形態では、リクエスト側デバイスからのタグ・フィールドの期待される値が、ＰＣＩｅデバイス・テーブル５０８に記憶されている。デバイス・テーブル５０８内のタグ・フィールド値によって判断された、タグ識別子の期待される値が、受信されるタグ・フィールドと、比較器５１２を使用して比較される。２つの値が等しくないことに応答して、フラグがセットされるか、またはリカバリ・プロセスが開始される。タグ識別子の期待される値は、インクリメンタ５１４によってインクリメントされ、リクエスト側デバイスに対応するデバイス・テーブル５０８内の位置に再び記憶される。
【００２８】
図５に示されている例示のルート・コンプレックス５０２は、アドレス・ルックアップ・テーブル５１６、下りタグ・テーブル５１８、および第２のインクリメンタ５２０も含み、これらは、エンド・ポイント５０４に送信される（例えば受信器／送信器５２４を介して）下りポステッド・メモリ・ライト・パケットを生成するために利用される。下りパケットが生成されるときは、ルート・コンプレックス５０２がリクエスト側デバイスであり、エンド・ポイント５０４が受信側デバイスである。例示の実施形態では、シーケンシャル・タグを実装するために必要な追加の処理と共に、標準のＰＣＩｅ処理が実行される。
【００２９】
図５に示されているように、ポステッド・パケットが、ルート・コンプレックス５０２によって生成され、アドレス・ルックアップ・テーブル５１６が、受信側デバイスの現在のタグ識別子を判断するために下りタグ・テーブル５１８への索引として利用される。例示の実施形態では、下りタグ・テーブルは、各エンド・ポイント５０４に関連する、１バイトの現在のタグ識別子を含む。現在のタグ識別子は、ポステッド・ライト・パケットのタグ・フィールド２０２に、ポステッド・ライト・パケットが指定の受信側デバイスに送信される前に挿入される。現在のタグ識別子は、インクリメンタ５２０によってインクリメントされ、下りタグ・テーブル５１８に再び記憶される。パケットが受信側デバイス（例えばエンド・ポイント５０４）において受信されると、受信側デバイスは、受信されるタグ識別子が、レジスタ（「ＤｏｗｎＴａｇＲｅｇ」）に記憶されている期待されるタグ識別子と等しいことを検証する。値が一致しなければ、その結果、エラーを示すよう、またはリカバリ・プロセスを開始するようフラグがセットされる。
【００３０】
上りポステッド・ライト・メモリ・リクエストの例示の実施形態に関して、図５に示されているように、複数のエンド・ポイント５０４があり（例えば、仮想機能すなわち「ＶＦ（ｖｉｒｔｕａｌ  ｆｕｎｃｔｉｏｎ）」、物理機能すなわち「ＰＦ（ｐｈｙｓｉｃａｌ  ｆｕｎｃｔｉｏｎ）」などを含む）、それぞれルート・コンプレックス５０２へパケットを送ることができる固有ＲＩＤを備える。図５に示されている実施形態では、この例ではアクセス・コントロール・サービス（ＡＣＳ：ａｃｃｅｓｓ  ｃｏｎｔｒｏｌｓ  ｓｅｒｖｉｃｅ）が、すべてのリクエストがルート・コンプレックス５０２へ進むことを強制するため、上りスイッチ・ルーティングは黙示的である。例示の実施形態では、各エンド・ポイント５０４（およびＲＩＤ）が、実行中の現在のタグ値を保持する。実行中の現在のタグ値は、下記で図６に示されているものなどの、エンド・ツー・エンド・シーケンス番号（ＥＳＥＱ：ｅｎｄ−ｔｏ−ｅｎｄ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ）機能構造によって、システム起動時に初期化される。リクエストが生成されるとき、タグ・フィールドが、各リクエストごとにインクリメントされる。タグ・フィールドのこの使用は、ＰＣＩｅのタグ利用法とほぼ一致するが、例示の実施形態では、タグ・フィールドはもはや不透明な手段ではなく、生成に関するルールがある。例示の実施形態では、タグ値は「０ｘＦＦ」から「０ｘ００」に折り返す（ｗｒａｐ）。タグ値の範囲は、どの時点でも、タグ・フィールド値が固有識別子であることを保証するよう選ばれる。例示の実施形態では、ルート・コンプレックス５０２は、各ＲＩＤの期待されるタグを保持する。例示の実施形態では、タグの不一致は、ルート・コンプレックス５０２に、エンド・ポイントをエラー状態にさせる。
【００３１】
例示の実施形態では、ルート・コンプレックス５０２内に示されている上りタグ・シーケンス機能が、一般に利用可能なアドレス変換および保護メカニズムの拡張として実装されてもよい。例えば、アドレス変換および保護の実行のために、Ａｄｖａｎｃｅｄ  Ｍｉｃｒｏ  Ｄｅｖｉｃｅｓ（ＡＭＤ）は、Ｉ／Ｏメモリ管理ユニット（ＩＯＭＭＵ：Ｉ／Ｏ  ｍｅｍｏｒｙ  ｍａｎａｇｅｍｅｎｔ  ｕｎｉｔ）を定義しており、Ｉｎｔｅｌは、直接メモリ・アクセス（ＤＭＡ：ｄｉｒｅｃｔ  ｍｅｍｏｒｙ  ａｃｃｅｓｓ）リマッピングを定義している。これらの実装両方において、リクエスタのアイデンティティ（ＲＩＤ）が、個々のリクエスタ・アドレス変換テーブルおよびアクセス権を判断するために使用される。デバイス・テーブルは、個々のリクエスタそれぞれに関する情報を含む。例示の実施形態では、タグ・シーケンス番号機能が、既存のデバイス・テーブルに追加される。
【００３２】
下りポステッド・ライト・メモリ・リクエストの例示の実施形態に関して、図５に示されているように、下りリクエストがアドレス・ルーティングされる。ルート・コンプレックス５０２は、ＰＣＩｅアドレス範囲と、ＰＣＩｅエンド・ポイントとの間の関係を保持する。ルート・コンプレックス５０２は、各ＰＣＩｅエンド・ポイントの実行中の現在のタグ値を保持する。図５に示されているように、各エンド・ポイント５０４は、実行中の現在のタグ値を保持し、これは、下記で図６に示されているものなどのＥＳＥＱ機能構造によってシステム起動時に初期化される。例示の実施形態では、ルート・コンプレックス５０２においてリクエストが生成されるとき、タグ・フィールドが各リクエストごとにインクリメントされる。例示の実施形態では、タグ値は「０ｘＦＦ」から「０ｘ００」に折り返す。タグ値の範囲は、どの時点でも、タグ・フィールド値が固有識別子であることを保証するよう選ばれる。例示の実施形態では、タグ値の不一致は、エンド・ポイントにエラーを示させ、ＰＣＩｅのＡＥＲ（ａｄｖａｎｃｅｄ  ｅｒｒｏｒ  ｒｅｐｏｒｔｉｎｇ：アドバンスト・エラー・レポーティング）レジスタおよびレポーティング・メカニズムが、エラーをレポートするために利用されるとよい。
【００３３】
図６は、ポステッド・ライト・パケットのタグ・シーケンシングにおいて使用されるレジスタを初期化するために例示の実施形態によって実装されるとよい、ＰＣＩ機能構造を示す。例示の実施形態では、このＰＣＩ機能構造は、ＰＣＩｅネットワーク内のリクエスト側デバイスおよび受信側デバイスのペアに対して、各ペアの両エンドを同期するために適用される。同期は、定期的に実行されるが、これは、システム初期化時および任意選択でリカバリ・アクションの一部として実行されるということを意味する。図６に示されている例示のＰＣＩ機能構造は、エンド・ツー・エンド・シーケンス番号機能レジスタ・フィールド内に、上りＥＳＥＱ生成がサポートされていることを示すようビットをセットし、さらにこの機能構造は、エンド・ツー・エンド・シーケンス番号機能レジスタ・フィールド内に、下りＥＳＥＱ生成がサポートされていることを示すようビットをセットする。当該技術分野で既知のように、次の機能ポインタ・フィールドは、リスト内の次の機能構造をポイントする。ＥＳＥＱ機能識別子フィールドは、本機能構造に関連する固有の機能番号を定義する。図６に示されている例示のコマンドは、ＥＳＥＱコントロール・レジスタ内に、上り開始タグを使用する上りＥＳＥＱ生成を可能にするようビットをセットして、ＥＳＥＱコントロール・レジスタ内に、下り開始タグを使用する下りＥＳＥＱ検査を可能にするようビットをセットして、さらに、下りＥＳＥＱエラーが検出されたことを示すために利用されるビットをセットする（または代わりに、ＰＣＩｅのアドバンスト・エラー・レポーティング、すなわち「ＡＥＲ」メカニズムが利用されるべきであることを示す）。上りタグ開始フィールドは、上りＥＳＥＱ生成の開始値を含み、下りタグ開始フィールドは、下りＥＳＥＱ検査の開始値を含む。
【００３４】
例示の実施形態の技術的効果および利点は、ＰＣＩｅネットワーク内のポステッド・メモリ・ライト・リクエストが順序正しく一度受信されたことを検証する能力を含む。これは、ＰＣＩｅの信頼性の改善につながり得る。
【００３５】
本願明細書で使用される専門用語は、特定の実施形態を説明するためのものでしかなく、本発明の限定となることは目的としていない。本願明細書で使用される、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、文脈によりそうでないことが明確に示されていない限り、複数形も含むものとする。さらに、当然のことながら、「含む」または「含んでいる」あるいはその両方の用語は、本明細書で使用されるとき、記載された機能、整数、ステップ、動作、構成要素、またはコンポーネント、あるいはそのいずれかの組み合わせの存在を指定するが、１つ以上の他の機能、整数、ステップ、動作、構成要素、コンポーネント、またはそのグループ、あるいはそのいずれかの組み合わせの存在または追加を除外するものではない。
【００３６】
以下の特許請求の範囲のミーンズまたはステップ・プラス・ファンクション構成要素すべての対応する構造、材料、動作、および等価物は、明確に請求されている他の請求される構成要素と共に機能を実行する任意の構造、材料、または動作を含むものとする。本発明の記載は、例証および説明のために示されたものであるが、包括的であることも、開示された形態の発明に限定されることも目的としていない。当業者には、本発明の範囲から逸脱することのない、多数の変更および変形が明らかであろう。実施形態は、本発明の原理および実際の応用をもっともよく説明して、当業者が、意図される特定の用途に適する様々な変更を用いた様々な実施形態に関して、本発明を理解できるように選ばれ、記載された。
【００３７】
当業者であれば当然のことであるが、本発明は、システム、方法またはコンピュータ・プログラム製品として具現化されるとよい。したがって、本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本願明細書においてすべて概して「回路」、「モジュール」または「システム」と呼ばれ得る、ソフトウェアおよびハードウェアの側面を兼ね備えた実施形態の形態をとるとよい。さらに、本発明は、任意の有形の表現媒体において具現化されたコンピュータ使用可能プログラム・コードを有する該媒体において具現化されたコンピュータ・プログラム製品の形態をとることもできる。１つ以上のコンピュータ使用可能またはコンピュータ可読媒体（単数または複数）の任意の組み合わせが利用され得る。コンピュータ使用可能またはコンピュータ可読媒体は、例えば、限定はされないが、電子、磁気、光学、電磁気、赤外線、もしくは半導体システム、装置、デバイス、または伝播媒体とすることもできる。コンピュータ可読媒体のより具体的な例（包括的でないリスト）には、１つ以上のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ（ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）すなわちフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤＲＯＭ：ｃｏｍｐａｃｔ  ｄｉｓｃ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、光学式ストレージ・デバイス、インターネットもしくはイントラネットをサポートする送信媒体などの送信媒体、または磁気ストレージ・デバイスがあると考えられる。なお、プログラムは、例えば紙または他の媒体の光学式走査により電子的に獲得され、続いて必要に応じコンパイル、解釈、または適切な方法により別の形で処理され、続いてコンピュータ・メモリに記憶されることが可能なため、コンピュータ使用可能またはコンピュータ可読媒体は、プログラムが印刷される紙または別の適切な媒体とすることさえもできる。この文書の文脈では、コンピュータ使用可能またはコンピュータ可読媒体は、命令実行システム、装置もしくはデバイスによって、もしくはそれに関連して使用されるプログラムを含むこと、記憶すること、伝達すること、伝播させること、または搬送することができる任意の媒体であればよい。コンピュータ使用可能媒体は、ベースバンドにおいて、または搬送波の一部として伝播データ信号により具現化されたコンピュータ使用可能プログラム・コードを備える該伝播データ信号を含むこともできる。コンピュータ使用可能プログラム・コードは、限定はされないが、無線、有線、光ファイバ・ケーブル、ＲＦなどを含め、任意の適切な媒体を使用して送信されることもできる。
【００３８】
本発明の動作を実行するコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋または同様のものなどのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは同様のプログラミング言語などの従来の手続きプログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで書かれることもできる。プログラム・コードは、スタンド・アロン・ソフトウェア・パッケージとして、完全にユーザのコンピュータ上で実行されること、部分的にユーザのコンピュータ上で実行されること、または部分的にユーザのコンピュータ上で、かつ部分的にリモート・コンピュータ上で実行されること、または完全にリモート・コンピュータもしくはサーバ上で実行されることもできる。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）もしくは広域ネットワーク（ＷＡＮ：ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）を含む任意の種類のネットワークを経由してリモート・コンピュータがユーザのコンピュータに接続されてもよく、または、外部コンピュータに対する接続が行われてもよい（例えば、インターネット・サービス・プロバイダを使用しインターネットを経由して）。
【００３９】
方法、装置（システム）およびコンピュータ・プログラムのフローチャート図またはブロック図、あるいはその両方を参照して、本発明の好適な実施形態について記載する。当然のことながら、フローチャート図またはブロック図、あるいはその両方の各ブロック、およびフローチャート図またはブロック図、あるいはその両方の複数ブロックの組み合わせは、コンピュータ・プログラム命令により実装されることが可能である。マシンを生じるよう、当該コンピュータ・プログラム命令が、汎用コンピュータ、専用コンピュータ、またはその他のプログラム可能データ処理装置のプロセッサに提供されて、この命令が、コンピュータまたはその他のプログラム可能データ処理装置のプロセッサにより実行されて、フローチャートまたはブロック図あるいはその両方のブロックもしくは複数ブロックにおいて指定された機能／動作を実装する手段を作り出すようにすることもできる。さらに、特定の形で機能するようコンピュータまたはその他のプログラム可能データ処理装置に指示することができる当該コンピュータ・プログラム命令は、コンピュータ可読媒体に記憶されて、コンピュータ可読媒体に記憶されたこの命令が、フローチャートまたはブロック図あるいはその両方のブロックもしくは複数ブロックにおいて指定された機能／動作を実装する命令手段を含む製品を生じるようにすることもできる。
【００４０】
さらに、コンピュータ・プログラム命令は、コンピュータまたはその他のプログラム可能データ処理装置にロードされて、コンピュータまたはその他のプログラム可能装置上で一連の動作ステップが実行されるようにしてコンピュータに実装されるプロセスを生じさせ、コンピュータまたはその他のプログラム可能装置上で実行される命令が、フローチャートまたはブロック図あるいはその両方のブロックもしくは複数ブロックにおいて指定された機能／動作を実装するためのプロセスを提供するようにすることもできる。
【００４１】
上記のように、実施形態は、コンピュータに実装されるプロセスと、当該プロセスを実行する装置との形態で具現化されることが可能である。例示の実施形態では、本発明は、１つ以上のネットワーク構成要素によって実行されるコンピュータ・プログラム・コードにおいて具現化される。実施形態は、図７に示されているように、製品として有形媒体において具現化された命令を含むコンピュータ・プログラム・コード論理７０４を備えるコンピュータ使用可能媒体７０２上の、コンピュータ・プログラム製品７００を含む。コンピュータ使用可能媒体７０２の例示の製品には、フロッピー・ディスケット、ＣＤ−ＲＯＭ、ハード・ドライブ、ユニバーサル・シリアル・バス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）フラッシュ・ドライブ、またはその他任意のコンピュータ可読ストレージ媒体が含まれることもでき、コンピュータ・プログラム・コード論理７０４がコンピュータにロードされそれによって実行されると、コンピュータが、本発明を実行する装置になる。実施形態には、例えば、ストレージ媒体に記憶され、コンピュータへのロードもしくはコンピュータによる実行あるいはその両方が行われるコンピュータ・プログラム・コード論理７０４、または電気配線もしくはケーブル上で、光ファイバを経由して、もしくは電磁放射を介してなど、何らかの送信媒体上で送信されるコンピュータ・プログラム・コード論理７０４が含まれ、コンピュータ・プログラム・コード論理７０４がコンピュータにロードされそれによって実行されると、コンピュータは、本発明を実行する装置になる。汎用マイクロプロセッサ上に実装されると、コンピュータ・プログラム・コード論理７０４セグメントが、特定の論理回路を作るようマイクロプロセッサを構成する。
【００４２】
各図面のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法およびコンピュータ・プログラム製品の考えられる実装のアーキテクチャ、機能性および動作を示す。この関連で、フローチャートまたはブロック図内の各ブロックは、指定の論理機能（単数または複数）を実装する１つ以上の実行可能命令を含むモジュール、セグメント、またはコードの一部を表すこともできる。なお、さらに、いくつかの代わりの実装では、ブロック内に示されている機能が、図面に示されているのとは異なる順序で生じてもよい。例えば、関連する機能性次第で、連続して示されている２つのブロックが実際には事実上同時に実行されてもよく、または、各ブロックが逆順で実行されることがあってもよい。なお、さらに、ブロック図もしくはフローチャート図あるいはその両方の各ブロック、およびブロック図もしくはフローチャート図あるいはその両方の複数ブロックの組み合わせは、指定の機能もしくは動作を実行する専用ハードウェア・ベース・システム、または専用ハードウェアおよびコンピュータ命令の組み合わせにより実装することができる。
【図１】
0005658239.tif 000002
【図２】
0005658239.tif 000003
【図３】
0005658239.tif 000004
【図４】
0005658239.tif 000005
【図５】
0005658239.tif 000006
【図６】
0005658239.tif 000007
【図７】
0005658239.tif 000008