(57)【特許請求の範囲】
【請求項１】
ネットワークを介して複数のポスティング機器から機器のリソースをスケジューリングするアーキテクチャにおいて、
上記複数のポスティング機器からリソース要求を受信し、掲示されたスケジュールエントリを格納するリソーススケジュールを備え、
上記各リソース要求は、開始時刻、継続時間及び間隔時間を含む時間データフィールドを有し、上記掲示されたスケジュールエントリはそれぞれ、要求中のポスティング機器と要求されているリソースを識別し、定期的に更新される状態値を含む状態データフィールドを有し、さらに、
上記スケジュールエントリは、経過データフィールドを有し、上記経過データフィールドは、経過値を用いて更新される上記リソース要求の完了への経過を掲示することを特徴とするアーキテクチャ。
【請求項２】
ネットワークを介して複数のポスティング機器から機器のリソースをスケジューリングするアーキテクチャにおいて、
上記複数のポスティング機器からリソース要求を受信し、掲示されたスケジュールエントリを格納するリソーススケジュールを備え、
上記各リソース要求は、開始時刻、継続時間及び間隔時間を含む時間データフィールドを有し、上記掲示されたスケジュールエントリはそれぞれ、要求中のポスティング機器と要求されているリソースを識別し、定期的に更新される状態値を含む状態データフィールドを有し、さらに、
上記状態データフィールドは、上記ポスティング機器によって更新されることを特徴とするアーキテクチャ。
【請求項３】
ネットワークを介して複数のポスティング機器から機器のリソースをスケジューリングするアーキテクチャにおいて、
上記複数のポスティング機器からリソース要求を受信し、掲示されたスケジュールエントリを格納するリソーススケジュールを備え、
上記各リソース要求は、開始時刻、継続時間及び間隔時間を含む時間データフィールドを有し、上記掲示されたスケジュールエントリはそれぞれ、要求中のポスティング機器と要求されているリソースを識別し、定期的に更新される状態値を含む状態データフィールドを有し、さらに、
上記状態値は、スケジュールエントリが開始するのを待っているとき、アクティブ状態で使用されているとき、正常に完了するとき、異常な状態で完了するとき及び他のポスティング機器に優先されるときに掲示されることを特徴とするアーキテクチャ。
【請求項４】
上記経過データフィールドは、掲示されたスケジュールエントリが実行されている間、所定の時間間隔で更新されることを特徴とする請求項１記載のアーキテクチャ。
【請求項５】
上記経過データフィールドは、上記要求中のポスティング機器によって更新されることを特徴とする請求項４記載のアーキテクチャ。
【請求項６】
上記状態データフィールドは、上記要求中のポスティング機器が所定の時間間隔内で上記経過データフィールドを更新できないときに更新されることを特徴とする請求項５記載のアーキテクチャ。
【請求項７】
ネットワークを介して複数のポスティング機器から機器のリソースをスケジューリングするアーキテクチャにおいて、
上記複数のポスティング機器からリソース要求を受信し、掲示されたスケジュールエントリを格納するリソーススケジュールを備え、
上記各リソース要求は、開始時刻、継続時間及び間隔時間を含む時間データフィールドを有し、上記掲示されたスケジュールエントリはそれぞれ、要求中のポスティング機器と要求されているリソースを識別し、定期的に更新される状態値を含む状態データフィールドを有し、さらに、
上記リソース要求は、保存履歴データフィールドを有し、上記スケジュールされた要求中のポスティング機器は、掲示された状態値及び経過値を保存して、上記スケジュールエントリの実行履歴を提供することを特徴とするアーキテクチャ。
【請求項８】
ネットワークを介して複数のポスティング機器から機器のリソースをスケジューリングするアーキテクチャにおいて、
上記複数のポスティング機器からリソース要求を受信し、掲示されたスケジュールエントリを格納するリソーススケジュールを備え、
上記各リソース要求は、開始時刻、継続時間及び間隔時間を含む時間データフィールドを有し、上記掲示されたスケジュールエントリはそれぞれ、要求中のポスティング機器と要求されているリソースを識別し、定期的に更新される状態値を含む状態データフィールドを有し、さらに、
上記リソーススケジュールは、ＡＶ／Ｃリソーススケジュール掲示板であることを特徴とするアーキテクチャ。
【請求項９】
ネットワークを介して複数のポスティング機器から機器のリソースをスケジューリングするアーキテクチャにおいて、
上記複数のポスティング機器からリソース要求を受信し、掲示されたスケジュールエントリを格納するリソーススケジュールを備え、
上記各リソース要求は、開始時刻、継続時間及び間隔時間を含む時間データフィールドを有し、上記掲示されたスケジュールエントリはそれぞれ、要求中のポスティング機器と要求されているリソースを識別し、定期的に更新される状態値を含む状態データフィールドを有し、さらに、
上記ネットワークは、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスを有することを特徴とするアーキテクチャ。
【請求項１０】
ネットワークを介して複数のポスティング機器から機器のリソースをスケジューリングするアーキテクチャにおいて、
上記複数のポスティング機器からリソース要求を受信し、掲示されたスケジュールエントリを格納するリソーススケジュールを備え、
上記各リソース要求は、開始時刻、継続時間及び間隔時間を含む時間データフィールドを有し、上記掲示されたスケジュールエントリはそれぞれ、要求中のポスティング機器と要求されているリソースを識別し、定期的に更新される状態値を含む状態データフィールドを有し、さらに、
上記リソース機器用のサブユニットエントリリストを有し、上記サブユニットエントリリストは、
ａ．各機器リソース用のリソースサブユニット識別と、
ｂ．リソーススケジュールエントリを掲示した各上記ポスティング機器用のポスティング機器識別と、
ｃ．リソーススケジュールエントリを掲示した各ポスティング機器用の利用状態を示す状態データフィールドとを掲示することを特徴とするアーキテクチャ。
【請求項１１】
ネットワークを介して複数のポスティング機器から機器のリソースをスケジューリングするアーキテクチャにおいて、
上記複数のポスティング機器からリソース要求を受信し、掲示されたスケジュールエントリを格納するリソーススケジュールを備え、
上記各リソース要求は、開始時刻、継続時間及び間隔時間を含む時間データフィールドを有し、上記掲示されたスケジュールエントリはそれぞれ、要求中のポスティング機器と要求されているリソースを識別し、定期的に更新される状態値を含む状態データフィールドを有し、さらに、
機器リソースに対応する上記状態値を掲示するサブユニット状態フィールドを有することを特徴とするアーキテクチャ。
【請求項１２】
上記サブユニット状態フィールドは、上記機器リソースがいつでも使用可能であるとき、アクティブ状態で使用されているとき、期間以上に動作しているとき及び競合するスケジュールエントリによって放棄されたときという状態値を掲示することを特徴とする請求項１１記載のアーキテクチャ。
【請求項１３】
機器が接続されているネットワークを介してリソーススケジュールを更新するリソーススケジュール更新方法において、
ａ．開始時刻、継続時間及び間隔時間を有するリソース要求をポスティング機器から上記リソーススケジュールに送信するステップと、
ｂ．スケジュールされるリソースと上記リソース要求を送信する上記ポスティング機器を識別し、状態値を含む状態フィールドを有するリソーススケジュールエントリを生成するステップと、
ｃ．リソース要求の動作を監視するステップと、
ｄ．上記状態値を上記状態データフィールドに掲示して上記リソーススケジュールエントリの状態を表すステップと、
ｅ．上記状態フィールドを更新して、上記状態フィールドが更新される毎に状態データを格納するステップとを有することを特徴とするリソーススケジュール更新方法。
【請求項１４】
機器が接続されているネットワークを介してリソーススケジュールを更新するリソーススケジュール更新方法において、
ａ．開始時刻、継続時間及び間隔時間を有するリソース要求をポスティング機器から上記リソーススケジュールに送信するステップと、
ｂ．スケジュールされるリソースと上記リソース要求を送信する上記ポスティング機器を識別し、状態値を含む状態フィールドを有するリソーススケジュールエントリを生成するステップと、
ｃ．リソース要求の動作を監視するステップと、
ｄ．上記状態値を上記状態データフィールドに掲示して上記リソーススケジュールエントリの状態を表すステップと、
ｅ．リソース機器が利用可能であることを確認するステップと、
ｆ．上記スケジュールエントリを生成するステップに先立ってリソースの状態を上記ポスティング機器に報知するステップとを有することを特徴とするリソーススケジュール更新方法。
【請求項１５】
機器が接続されているネットワークを介してリソーススケジュールを更新するリソーススケジュール更新方法において、
ａ．開始時刻、継続時間及び間隔時間を有するリソース要求をポスティング機器から上記リソーススケジュールに送信するステップと、
ｂ．スケジュールされるリソースと上記リソース要求を送信する上記ポスティング機器を識別し、状態値を含む状態フィールドを有するリソーススケジュールエントリを生成するステップと、
ｃ．リソース要求の動作を監視するステップと、
ｄ．上記状態値を上記状態データフィールドに掲示して上記リソーススケジュールエントリの状態を表すステップと、
ｅ．上記リソース要求の経過を、その要求がスケジュールされた時間の間、監視するステップとを有することを特徴とするリソーススケジュール更新方法。
【請求項１６】
機器が接続されているネットワークを介してリソーススケジュールを更新するリソーススケジュール更新方法において、
ａ．開始時刻、継続時間及び間隔時間を有するリソース要求をポスティング機器から上記リソーススケジュールに送信するステップと、
ｂ．スケジュールされるリソースと上記リソース要求を送信する上記ポスティング機器を識別し、状態値を含む状態フィールドを有するリソーススケジュールエントリを生成するステップと、
ｃ．リソース要求の動作を監視するステップと、
ｄ．上記状態値を上記状態データフィールドに掲示して上記リソーススケジュールエントリの状態を表すステップとを有し、
上記リソース要求の動作の監視は、上記ポスティング機器の動作を監視することによって達成されることを特徴とするリソーススケジュール更新方法。
【請求項１７】
機器が接続されているネットワークを介してリソーススケジュールを更新するリソーススケジュール更新方法において、
ａ．開始時刻、継続時間及び間隔時間を有するリソース要求をポスティング機器から上記リソーススケジュールに送信するステップと、
ｂ．スケジュールされるリソースと上記リソース要求を送信する上記ポスティング機器を識別し、状態値を含む状態フィールドを有するリソーススケジュールエントリを生成するステップと、
ｃ．リソース要求の動作を監視するステップと、
ｄ．上記状態値を上記状態データフィールドに掲示して上記リソーススケジュールエントリの状態を表すステップと、
ｅ．上記リソースの状態用の上記リソーススケジュールエントリを符号化するサブユニット状態データフィールドを生成するステップとを有することを特徴とするリソーススケジュール更新方法。
【請求項１８】
機器が接続されているネットワークを介してリソーススケジュールを更新するリソーススケジュール更新方法において、
ａ．開始時刻、継続時間及び間隔時間を有するリソース要求をポスティング機器から上記リソーススケジュールに送信するステップと、
ｂ．スケジュールされるリソースと上記リソース要求を送信する上記ポスティング機器を識別し、状態値を含む状態フィールドを有するリソーススケジュールエントリを生成するステップと、
ｃ．リソース要求の動作を監視するステップと、
ｄ．上記状態値を上記状態データフィールドに掲示して上記リソーススケジュールエントリの状態を表すステップとを有し、
上記リソーススケジュールは、ＡＶ／Ｃリソーススケジュール掲示版であることを特徴とするリソーススケジュール更新方法。
【請求項１９】
機器が接続されているネットワークを介してリソーススケジュールを更新するリソーススケジュール更新方法において、
ａ．開始時刻、継続時間及び間隔時間を有するリソース要求をポスティング機器から上記リソーススケジュールに送信するステップと、
ｂ．スケジュールされるリソースと上記リソース要求を送信する上記ポスティング機器を識別し、状態値を含む状態フィールドを有するリソーススケジュールエントリを生成するステップと、
ｃ．リソース要求の動作を監視するステップと、
ｄ．上記状態値を上記状態データフィールドに掲示して上記リソーススケジュールエントリの状態を表すステップとを有し、
上記ネットワークは、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスを備えることを特徴とするリソーススケジュール更新方法。
【請求項２０】
ネットワーク上のリソースをスケジュールするシステムにおいて、
ａ．各リソーススケジュールエントリの状態を掲示するためのデータフィールドを有するＡＶ／Ｃリソーススケジュール掲示版に掲示される上記リソーススケジュールエントリを実行するリソース機器と、
ｂ．上記リソース機器とデータの送受信を行い、上記ＡＶ／Ｃリソーススケジュール掲示版に上記リソーススケジュールを掲示するポスティング機器とを備え、上記各リソーススケジュールエントリは、開始時刻、継続時間及び間隔時間を含むことを特徴とするシステム。
【請求項２１】
上記ＡＶ／Ｃリソーススケジュール掲示版は、上記リソース機器によって上記スケジュールエントリが実行されている間、上記スケジュールエントリの経過を掲示するための経過データフィールドを有することを特徴とする請求項２０記載のシステム。
【請求項２２】
上記リソース機器は、上記リソーススケジュールエントリ用の、上記掲示された状態値及び経過値を格納するためのデータ格納ユニットを有することを特徴とする請求項２０記載のシステム。
【請求項２３】
上記経過データフィールドは、上記リソース機器が上記スケジュールエントリを実行している間、上記ポスティング機器によって、所定の時間間隔で、経過データを用いて更新されることを特徴とする請求項２１記載のシステム。
【請求項２４】
上記状態データフィールドは、上記リソース機器によって更新されることを特徴とする請求項２０記載のシステム。
【請求項２５】
上記リソース機器は、ビデオ受信器及び転送器を備えることを特徴とする請求項２０記載のシステム。
【請求項２６】
上記ポスティング機器及びリソース機器は、ＩＥＥＥ１３９４シリアルバスによって接続されていることを特徴とする請求項２０記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上のリーソスをスケージューリングする（scheduling）アーキテクチャ（architecture）、システム及び方法に関する。特に、本発明は、ＩＥＥＥ１３９４シリアルバスを利用したネットワーク内で動作する機器間で、動的なリソーススケジューリング（resource scheduling）を行うアーキテクチャ、システム及び方法に関する。
【０００２】
【従来の技術】
１９９５年に草案が承認された「高性能シリアルバスのためのＩＥＥＥ１３９４規格」は、非同期フォーマットのデータ転送とアイソクロノスフォーマットのデータ転送（asynchronous and isochronous format data transfer）の両方をサポートする安価な高速のシリアルバスアーキテクチャを実現する国際規格である。アイソクロノスデータ転送は、リアルタイム転送（real-time transfer）であり、送信アプリケーションと受信のアプリケーションの両方における重要なインスタンス（significant instance）間の時間間隔（time interval）が同じ継続時間（duration）を有する。アイソクロノス的に転送されるデータの各パケットは、それ自身が有する周期（period）で転送される。アイソクロノスデータ転送の理想的なアプリケーションとして、ビデオレコーダからテレビジョン受像機へのデータ転送がある。ビデオレコーダは、画像と音声を、画像データ及び音声データの個別の固まり（chunk）、すなわちパケットとして記録及び保存する。そして、ビデオレコーダは、規定された周期で、記録された画像と音声を表す各パケットを、テレビジョン受像機に転送し、テレビジョン受像機は、それらを表示する。ＩＥＥＥ１３９４シリアルバスアーキテクチャは、アプリケーション間のアイソクロノスデータ転送のために多重チャンネル（multiple channel）を提供する。データが適切なアプリケーションによって確実に受信されるように、６ビットのチャンネル番号が、データとともに報知される。これによって、複数のアプリケーションは、バス構造を介してアイソクロノスデータを同時に転送することができる。非同期転送は、伝統的なデータ転送動作であり、転送元から転送先に大量のデータをできるだけ速く転送するためのものである。
【０００３】
ＩＥＥＥ１３９４規格（１９９５年版）は、デジタル機器を相互接続する高速シリアルバスを提供するとともに、汎用の入出力（Ｉ／Ｏ）接続を提供する。ＩＥＥＥ１３９４規格（１９９５年版）は、アプリケーションのデジタルインターフェースを定義するものであり、これによって、アプリケーションは、デジタルデータをバスを介して転送する前に、アナログデータに変換する必要がない。同様に、受信アプリケーションは、バスからアナログデータでなく、デジタルデータを受信するので、アナログデータをデジタルデータに変換する必要はない。ＩＥＥＥ１３９４規格（１９９５年版）によって規定されるケーブルは、そのような機器を接続するために用いられている他の嵩張ったケーブルと比較して、サイズが非常に細い。ＩＥＥＥ１３９４規格（１９９５年版）のバスが活線状態においても、機器を取り付けたり、取り外したりすることができる。機器が取り付けられたり、取り外されたりすると、バスは、それ自体を自動的に再構成し、既存のノード間でデータを転送する。ノードは、バス構造上の固有のアドレスを有する論理構成体（logical entity）とみなされる。各ノードは、認識ＲＯＭ（identification ROM）と、標準化された制御レジスタのセット（set of control registers）と、それ自身のアドレス空間（address space）とを有する。これらの特徴によって、ＩＥＥＥ１３９４規格（１９９５年版）は、オーディオ／ビデオ機器、媒体再生／記録機器（media play/record device）、コンピュータ／表示装置（computer/display device）を協働させることができる類のないネットワーク構成を提供する。
【０００４】
ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワークによって、多様な範囲の機器を接続することができる。これらの機器の性能及び機能は、非常に単純なものから非常に複雑なものにまで亘っている。具体的には、多種多様なオーディオ／ビデオ機器、媒体再生／記録機器及びコンピュータ／表示機器を、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワーク構成上で互いにリンクし、それらの機器間で非同期データ転送及びアイソクロノスデータ転送をサポートすることができる。
【０００５】
ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスにより、広帯域分散環境（high bandwidth, distributed environment）において、機器を一体化させて働かせ、ネットワーク全体の効率及び機能を最大限にすることができる。これにより、製造業者は、ある機能をネットワーク上の全ての機器において重複させないように、ネットワーク上の１つの機器が有する高価な機能を他の機器に設けないようにすることができる。ある機器は、機能が制限された比較的安価なものであるが、ユーザに対し、ネットワーク内の全ての機能を提供するためには、他の機器のサポート及び他の機器との相互作用を必要とする。
【０００６】
オーディオビデオ／コンピュータのデジタルインターフェースコマンドセット（AV/C Digital Interface Command Set：以下、ＡＶ／Ｃコマンドという。）は、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバス上の民生用オーディオ／ビデオ機器間のデータトランザクションのために用いられるコマンドセットである。ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバス及びＡＶ／Ｃコマンドセットはともに、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワーク内で接続された機器間におけるマスタ／スレーブ関係（master/slave relationship）を提供しない。その代わりに、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバス及びＡＶ／Ｃコマンドセットは、ネットワーク内で、機器の協調的なピアトゥピア共存関係（cooperative peer-to-peer coexistence）に基づいて動作する。それぞれのＡＶ／Ｃコマンド及び応答データパケットは、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバス上でネットワークによって接続された機器間で、非同期データストリームとして転送される。ＡＶ／Ｃコマンド及び応答データパケットは、通常、ＡＣ／Ｃコマンドセットで略述されたＡＶ／Ｃプロトコルに基づいてフォーマットされる。ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワーク上のＡＶ／Ｃコマンド及び応答データパケットの転送は、ＡＶ／Ｃアーキテクチャによってサポートされる。ＡＶ／Ｃアーキテクチャは、機器がＡＶ／Ｃコマンド及び応答データパケットを生成し、処理し及び／又は伝送するのをサポートするリストとテーブルを有する。ＡＶ／Ｃアーキテクチャは、通常チューナ、受信機又は記録装置等のリソース機器サブユニット（resource device subunit）に対して専用とされたＡＶ／Ｃ掲示板サブユニット（AV/C bulletin board subunit）を有する。
【０００７】
ＡＶ／Ｃ掲示板サブユニットは、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワーク上でネットワークによって接続された機器間で共用される情報構造を有する。リソーススケジュール掲示板（resource schedule bulletin board）もまた、ネットワーク内で接続された機器間で共用される情報をサポートする情報構造を有する。リソーススケジュール掲示板は、組織構造（organizational structure）を提供し、これにより、共用されるデータは組織化され、送受信される。リソーススケジュール掲示板は、ネットワーク内の機器間で記述コマンドを介して共用することができる符号化データを表すエントリ記述子のリストからなるサブ掲示板（sub-board）を含んでいる。専用のＡＶ／Ｃ掲示板サブユニットは、通常、その機器と、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワーク内の全ての互換性のあるポスティング機器との間の情報アーキテクチャをサポートする。ポスティング機器は、リソーススケジュール掲示板内の書込み可能リストに、いつリソースを使用するかを特定する要求エントリ（request entry）を書き込む。
【０００８】
ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスとＡＶ／Ｃコマンドセットはともに、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワーク内で接続された機器間におけるマスタ／スレーブ関係（master/slave relationship）を提供しない。その代わりに、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバス及びＡＶ／Ｃコマンドセットは、ＡＶ／Ｃプロトコルに従ってフォーマットされたデータを転送するネットワーク内で、機器の協調的なピアトゥピア共存関係（cooperative peer-to-peer coexistence）に基づいて動作する。通信を行う機器は、システムリソースマネージャによって介入されることなく、互いに直接コマンド及び応答データを送信する。各機器、すなわち機器サブユニットは、スケジューリングを管理し、リソース要求を格納する責任を有する。
【０００９】
【発明が解決しようとする課題】
従来の標準のＡＶ／Ｃプロトコルでは、スケジューリングの競合を解決する方法、スケジュールエントリの経過を識別する方法、又はスケジューリングされたリソースエントリの履歴を提供する方法がない。通常、ＡＶ／Ｃプロトコルは、使用を前提とした（use base）要求で動作し、利用可能なリソース機器のリソース時間は、要求した何れの機器に対しても利用可能とされる。このＡＶ／Ｃプロトコルでは、リソース機器の使用において競合する機器は、リソース機器を予約することによって、他のクライアント機器が、そのリソース機器を同じ時間に要求するエントリをリソーススケジュール掲示板に予め提示していても、その機器を使用する権利を得ることができる。すなわち、従来のアーキテクチャでは、リソーススケジュール掲示板を管理する方法、スケジューリングの競合を解決する方法、又は競合する制御機器間でリソース時間を交渉する方法がない。また、従来のリソーススケジュール掲示板によって管理されるリソーススケジュールは、ネットワーク内の機器のシステム要求（sisytem need）を、常に反映していない。
【００１０】
本発明は、このような実情に鑑みてなされたものであり、本発明の目的は、複数のポスティング機器、すなわちクライアント機器から、ネットワーク上のリソースサブユニットをスケージューリングする有益なスケージューリング機能を有するＡＶ／Ｃアーキテクチャ、リソーススケジュール更新方法を提供することである。
【００１１】
【課題を解決するための手段】
本発明に係るＡＶ／Ｃアーキテクチャは、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワーク上で互いに接続された機器のスケジューリングをサポートする。リソース要求は、ＡＶ／Ｃリソーススケージュール掲示板に提示され、ＡＶ／Ｃリソーススケージュール掲示板は、提示された要求をスケジュールエントリとして掲示して格納する。リソース要求とスケジュールエントリは、類似した要求及びスケジューリング情報を有する。ここで、リソース要求とスケジュールエントリは、区別されてネットワーク内のスケジュール情報の物理的な位置を示す。リソース要求とは、ポスティング機器すなわち制御機器から供給される要求及びスケジューリング情報である。これに対してスケジュールエントリとは、目的の機器に備わるＡＶ／Ｃリソーススケージュール掲示板に提示されて格納される要求及びスケジュール情報である。リソース要求とこれに対応するスケジュールエントリはともに、各要求用の開始時刻（start time）、継続時間(duration time)、インターバル時間（interval time）及び繰返し回数（repeat count）を特定するスケージューリングデータ（scheduling data）を有する。さらに、リソース要求と対応するスケジュールエントリは、リソースサブユニット識別データ（resource subunit identification data）を有し、リソースサブユニット識別データは、スケジュールエントリ内でリソースサブユニットを独自に識別する。
【００１２】
本発明のＡＶ／Ｃアーキテクチャによると、ＡＶ／Ｃリソーススケージュール掲示板は、各掲示されるスケジュールエントリ用の、状態データフィールド（satus data field）を有する。状態データフィールド内に、状態値（status value）が掲示されて、システム内での要求の状態が符号化される。独自の状態値が提供されて、スケジュールエントリが開始するのを待っているとき、スケジュールエントリがアクティブ状態で使用されているとき、スケジュールエントリが正常な状態で完了したとき、スケジュールエントリが異常な状態で完了したとき、スケジュールエントリが競合するポスティング機器に優先されたときを表すことが望ましい。状態データフィールドは、要求の状態が変わったとき、スケジュールされたポスティング機器によって更新されることが望ましいが、リソース機器によって更新されてもよい。
【００１３】
本発明のＡＶ／Ｃアーキテクチャはまた、各掲示されるスケジュールエントリ用の、経過データフィールド（progress data field）を有する。経過データフィールドは、要求が完了する経過を表す経過値（progress value）を掲示するために用いられる。経過データフィールドもまた、スケジュールされたポスティング機器によって更新されることが望ましい。スケジュールされたポスティング機器は、それ自身の要求の経過を監視し、ＡＶ／Ｃリソーススケージュール掲示板で、経過データフィールドを所定の時間間隔内で更新する。時間間隔は、対象のアプリケーションに適する値に設定される。
【００１４】
本発明の好ましい実施例において、状態データフィールドと経過データフィールドは、相互に関連して、ポスティング機器が所定の時間間隔内で経過データフィールドを更新できない場合は、状態データフィールドが、リソース機器又はシステムによって更新されて、ポスティング機器が適切に応答していない、すなわちオフラインであることを示す。
【００１５】
本発明の別の実施例において、ＡＶ／Ｃアーキテクチャは、ネットワーク接続されたリソースサブユニットの活動（activity）を表す値を掲示するサブユニットデータフィールドを有する。リソースサブユニットがいつでも使用可能であるとき、リソースサブユニットがアクティブ状態で使用されているとき、リソースサブユニットが期間以上に動作しているとき、競合するスケジュールエントリによって放棄されたときを表す独自の値が、サブユニットデータフィールド内に掲示されることが望ましい。サブユニット状態値（subunit status value）は、要求するポスティング機器（requesting posting device）とリソースサブユニット用の識別データ値を掲示する表にコンパイル（compile）されることが望ましい。
【００１６】
各スケジュールエントリ用の更新された状態フィールド及び経過フィールドは、ＡＶ／Ｃリソーススケージュール掲示板に送信され掲示された各要求用の実行履歴を提供するために格納される。本発明の好ましい実施例において、リソース要求は、保存履歴データフィールド値（keep history data field value）とともに提示され、保存履歴データフィールド値は、要求の状態が変更されるとき、又は要求が完了するときに、状態値及び経過値を保存するか否かをシステムに報知する。
【００１７】
本発明の他の実施例において、状態値及び経過値は、機器間で送受信され、スケジュールの競合を処理するための機構が提供される。具体的には、リソース要求の状態値及び経過値は、継続的に監視されて更新される。競合する制御機器が、掲示されたスケジュールエントリと競合しているスケジュールエントリを、ＡＶ／Ｃリソーススケージュール掲示板に送信する場合、システムは、競合する制御機器に対して、リソースが使用中であるか否かを特定するメッセージを送信する。リソースが使用中である場合、システムは、競合する機器に対して、競合している要求の状態及び／又は経過を報知するメッセージを送信し、競合する機器に、競合している要求の状態及び／又は経過、システムのニーズ、あるいはネットワーク内の機器の順位に応じて、競合している要求に優先する機会が与えられることが望ましい。
【００１８】
本発明に係るネットワーク上のリソースをスケージューリングするアーキテクチャ、システム及び方法は、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスを介して接続されている機器のネットワークに機能を提供して、ＡＶ／Ｃリソーススケージュール掲示板が、ネットワークの動的な環境を反映できるようにすることが望ましい。本発明はまた、リソースの管理者によって介入されることなくポスティング機器間で行われる、より効果的なピィアトゥピァスケジュール管理を提供する。本発明は特に、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワークを介して、オーディオ／ビデオ機器をスケジュールするために有益であるが、コンピュータを含め、他のネットワーク上の互換性のある機器をスケジュールするためにも有益である。
【００１９】
【発明の実施の形態】
以下、本発明に係るアーキテクチャ、リソーススケジュール更新方法及びシステムについて、図面を参照しながら説明する。
【００２０】
図１は、コンピュータシステム及びビデオカメラを含むＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワークの具体例を示すブロック図である。コンピュータシステム１０は、表示器１２を備え、ＩＥＥＥ１３９４規格（１９９５年版）に準拠したシリアルバスケーブル１６を介して、ビデオカメラ１４に接続されている。ビデオデータ及び関連するデータは、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスケーブル１６を介して、ビデオカメラ１４とコンピュータ１０間で送受信される。
【００２１】
図２は、コンピュータシステム１０の内部構成を示すブロック図である。コンピュータシステム１０は、中央演算処理装置（central processor unit：以下、ＣＰＵという。）２３と、メインメモリ２１と、ビデオメモリ２５と、マスストレージ装置（mass storage device）２４と、ＩＥＥＥ１３９４規格（１９９５年版）に準拠したインターフェース回路１９を備え、これらは全て、従来の双方向システムバス２９を介して接続されている。インターフェース回路１９は、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスを介して情報を送受信する物理インターフェース回路１７を含む。物理インターフェース１７は、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスケーブル１６を介してビデオカメラ１４に接続されている。本発明の好ましい実施例においては、インターフェース回路１９は、コンピュータシステム１０内のＩＥＥＥ１３９４規格（１９９５年版）のインターフェースカード上に実現されている。なお、当該技術分野において知られているように、インターフェース回路１９は、例えばマザーボード上に設けられる等の他の適切な方法によって、コンピュータシステム内に実現されてもよい。マスストレージ装置２４は、磁気、光又は光磁気ストレージ技術、又は他の利用可能なマスストレージ技術のうちの１つ以上の技術を用いた固定及び取外可能記録媒体の両方を有してもよい。システムバス２９は、メインメモリ２１及びビデオメモリ２５の記憶領域を指定するためのアドレスバスを含んでいる。また、システムバス２９は、ＣＰＵ２３、メインメモリ２１、ビデオメモリ２５、マスストレージ装置２４及びインターフェース回路１９間で、データを転送するためのデータバスも含んでいる。
【００２２】
また、コンピュータシステム１０には、キーボード２６、マウス２８及び表示器１２を含む多数の周辺入出力装置に接続されている。キーボード２６は、ＣＰＵ２３に接続され、これによりユーザは、データ及び制御コマンドをコンピュータシステム１０に入力することができる。マウス２８は、キーボード２６に接続された従来のカーソル制御装置であり、これにより、表示器１２上でグラフィック画像を操作することができる。
【００２３】
ビデオメモリ２５の出力ポートは、ビデオ多重／シフト回路（video multiplex and shifter circuit）１１に接続されており、ビデオ多重／シフト回路１１は、ビデオ増幅器２７に接続されている。ビデオ増幅器２７は、表示器１２を駆動する。ビデオ多重／シフト回路１１及びビデオ増幅器２７は、ビデオメモリ２５に記憶されている画素データを、表示器１２での表示に適したラスタ信号に変換する。
【００２４】
図３は、本発明を適用したＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスで接続された機器システム（system of devices）を示すブロック図である。図３に示すように、ビデオモニタ機器（video monitoring device）３１，３５は、オーディオ／ビデオ機器であり、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバス３３を介して、ビデオ録画及び媒体再生装置（video recording and media playing device）３７に接続されている。また、コンピュータシステム３２も、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバス３３を介して、ビデオ録画及び媒体再生装置３７に接続されている。ユーザが、スケジュール要求（scheduling request）をコンピュータシステム３２に入力すると、コンピュータシステム３２は、適切なスケジュール要求情報を、ビデオ録画及び媒体再生装置３７によって管理されているリソーススケジュール掲示板（resource schedule board）に伝送する。そして、スケジュール要求情報は、ＡＶ／Ｃリソーススケージュール掲示板（AV/C resource schedule bulletin board）内の掲示スケジュールエントリに格納される。なお、図３は、説明を分かり易くするためにシステム構成３０を簡単なものとしているが、ポイントツーポイントのデータストリーム伝送（point-to-point data stream transmission）を提供するＩＥＥＥ１３９４規格（１９９５年版）のシリアルバス内には、多種多様な機器が存在する。また、本発明を実施するためには、全ての機器をＩＥＥＥ１３９４（１９９５年版）のシリアルバスで接続しなければならないというシステム上の制限はない。
【００２５】
図４は、本発明を適用し、リソースの使用を要求するポスティング機器（posting device）と、リソースの使用が要求される目的機器（target device）とを有する機器ネットワークの具体例を示すブロック図である。この実施例において、図４に示すように、目的機器４３内に設けられたリソーススケジュールエントリ４４は、リソースのスケジュール情報を含んでいる。リソース要求エントリは、ネットワークに接続されたクライアント、すなわちポスティング機器４１から生成される。具体的には、ポスティング機器４１は、周知の適切な方法、例えばスケジューリングプロトコル（scheduling protocol）等を用いて、このリソース要求エントリを生成し、典型的な目的機器であるＶＴＲ機器（ビデオテープレコーダ）に供給する。目的機器４３は、リソーススケジュール板（resource schedule board：以下、ＲＳＢという。）４５を含む掲示板サブユニット（bulletin board subunit）を有し、リソース要求エントリを用いて、ネットワークに接続された要求クライアント機器用の様々なリソースサブユニットに割り当てられるリソース時間からなるリソーススケジュールを作成する。
【００２６】
なお、一実施例において、スケジューリングデータとスケジューリングアーキテクチャは、ユーザに対して透過的であり、機器間のデータ転送をシステムレベルで調整するための情報を提供する。他の実施例において、スケジューリングデータ及びリソーススケジュールは、ネットワークを介し、ユーザによってアクセス可能である。更なる実施例において、可視可能なスケジューリングメニュ及びリソーススケジュールは、グラフィカルユーザインターフェース（graphical user interface）によって生成される。
【００２７】
スケジュールエントリ４４は、ポスティング機器４１からデータをリソース要求とし、ネットワークを介して目的機器４３に送り、スケジュールデータをスケジューリングメニュに入力することによって、生成される。全ての要求クライアント機器からのリソース要求は、中央に位置する（central location）メモリユニットに格納され、このリソース要求から、グラフィカルユーザインターフェースによって、ユーザの目に見えるリソーススケジュールが生成される。メニュのスケジューリングをサポートするために用いられる内部データ構成、すなわちグラフィカルユーザインターフェースは、アプリケーション及び装置に依存する。
【００２８】
また、図４に示すように、リソース要求は、スケジュールデータをリソース要求エントリボックス（resource request entry box）４２に入力することによって作成される。スケジュールデータは、開始時刻と、開始日時と、継続時間と、必要に応じて事象の間隔値（interval value）及び事象の回数値（a number of event value）を含む繰返し情報（repeat information）と、リソースインディケータ（resource indicator）とを含んでいる。リソース要求エントリボックス４２に示されるスケジュールデータを含むリソース要求は、ネットワークを介して送信及び転送され、新しいリソーススケジュールエントリ４４を作成するために用いられる。リソーススケジュール板４５は、１つ以上のリソーススケジュールエントリ４４を有する。各リソーススケジュールエントリ４４は、受信リソース要求と、ポスティング機器がリソーススケジュールエントリ４４において特定される情報に応じて、リソース機器を利用する予定であることを示す細目（specification）を表している。別の実施例においては、リソーススケジュールエントリ４４のフィールド値（field value）は、ネットワークを介してアクセス可能なリソーススケジュールの生成のめに必要なスケジューリングデータを有するグラフィカルユーザインターフェースを提供するために用いられる。
【００２９】
図５は、完全なリソース要求を生成するために、ポスティング機器、すなわちスケジュール機器から入力されるスケジュールエントリの詳細を示す高レベルのスケジュールエントリセクション（high level schedule entry section）を示す図である。この図５に示すように、高レベルのスケジュールエントリセクション５１は、複数のエントリブロック５２，５５，５７，５８，５９を有し、開始時刻がエントリブロック５７に入力され、継続時間がエントリブロック５９に入力され、リソース機器情報がエントリブロック５８に入力される。繰返し時間の順序（repeat-time sequence）は、エントリブロック５２，５５に入力される。エントリブロック５２，５５は、リソース要求が繰り返されるときに、何れか一つが用いられる。エントリブロック５２は、週単位で繰り返されるリソーススケジュールエントリのために用いられる。エントリブロック５５は、特定の間隔で繰り返されるリソーススケジュールエントリのために用いられる。
【００３０】
繰返し時間順序エントリ（repeat-time sequence entry）を特定するためには、事象の回数値及び繰返し間隔（repeat interval）が必要とされる。事象の回数値は、１を含めた適切な値であり、エントリの繰返し回数を特定するものである。繰返し間隔は、事象間の時間であり、日毎、週毎、月毎又は適切な間隔である。例えば、エントリブロック５２において、日毎、週毎又は月毎等の間隔がMon,Tue,...,Sunフィールドに入力され、事象の回数値がnumber_of_eventsフィールドに入力され、この事象の回数値は、事象の回数を特定し、すなわち要求が何回実行されるかを表し、したがって、実行される全体の時間を定義している。なお、週のある特定の曜日をスケジュール内に入力するようにしてもよい。全体の継続時間内の曜日を示すことによって、他のクライアント機器は、リソースをより効率的に用いることができる。例えば、スケジュール要求は、リソースが、二週間の間、第二週目の火曜日を除いて毎日必要とされることを示すフィールド値を含むようにしてもよい。これにより、他のクライアント機器、すなわち他のスケジュール機器は、リソーススケジュールを見ることによって、そのリソースが第二週目の火曜日は利用可能であること、すなわち第二週目の火曜日に相当するスケジュールリソース時間が利用可能であることが分かる。エントリブロック５２に示すMon,Tue,...,Sunフィールドのように、曜日選択（day selection）のためのフィールドを設けると、非常に便利である。すなわち、この曜日選択フィールドを用いて、ユーザがある特定の曜日にリソースをスケジュールすると、そのリソースは、スケジュールエントリ全体の期間に亘って、選択された曜日に自動的にスケジュールされる。
【００３１】
エントリブロック５５は、特定の間隔単位で繰り返されるリソーススケジュールエントリのために用いられるエントリフォーム（entry form）である。エントリライン（entry line）５６には、時間間隔が入力され、この時間間隔は、規則的な時間間隔（時、日等）、又は不規則な時間間隔の何れかである。エントリライン５４には、リソース要求が実行される回数を特定する事象の回数値が入力される。例えば、ユーザが、１時間２０分に相当する間隔値と、９の事象の回数値とを有するスケジュールエントリを入力すると、共有されるリソースは、エントリブロック５７で特定される時刻に開始され、継続エントリブロック５９で特定される期間継続され、１時間２０分の間隔で９回実行されるようにスケジュールされる。
【００３２】
リソース要求及びスケジュールエントリ用の時間データフィールドは、システムの適切なアプリケーションを反映するように選択される。例えば、家庭又は娯楽用のオーディオ／ビデオ機器をスケジュールするときは、通常、エントリブロック５９に示すように、要求の時間、分及び秒を特定すれば十分である。ところで、特殊なアプリケーションでは、時間データフィールドを、より長い又はより短い時間増分（increments of time）を含むように拡張する必要がある。例えば、深宇宙の研究という天文学の研究においては、オーディオ／ビデオ機器を、１年又はそれ以上に亘って、非常に精密な周期でスケジュールする必要がある。したがって、エントリブロック５７，５９に示される時間データフィールドは、単なる一例にすぎず、それらを拡張して、対象とするアプリケーションに適する時間増分を含むようにしてもよい。
【００３３】
図６は、本発明を適用したシステムの構成を示すブロック図であり、このシステムは、リソース機器６３と、２つのポスティング機器６５，６７とを備える。リソース機器６３は、本発明を適用したＡＶ／Ｃ掲示板サブユニット６１を備える。実線１１０及び１１１は、リソース機器６３内のリソースサブユニット６２，６４からのコンテンツを伝送する伝送路を表している。点線１１２，１１３，１１４，１１５は、ポスティング機器、すなわち制御機器６５，６７及びリソースサブユニット６２，６４からＡＶ／Ｃリソーススケージュール掲示板サブユニット６１に、制御データを伝送する伝送路を表している。
【００３４】
ＡＶ／Ｃリソーススケージュール掲示板サブユニット６１は、スケジュールエントリ及びスケジューリングデータを編成して格納するＡＶ／Ｃ掲示板６６（AV/C bulletin board）と、メモリ／ＣＰＵユニット（memory/CPU unit）６９とを備える。制御機器６５，６７は、リソース要求６８，６８’をＡＶ／Ｃ掲示板６６に送信し、ＡＶ／Ｃ掲示板６６は、リソース要求６８，６８’を編成して、スケジュールエントリとして掲示し、メモリ／ＣＰＵユニット６９は、リソース要求６８，６８’を格納する。ＡＶ／Ｃリソーススケージュール掲示板サブユニット６１内の編成されたスケジュールエントリは、リソーススケジュールカレンダを提供する。このリソーススケジュールカレンダに応じて、各リソースサブユニット６２，６４からのリソース時間が、要求する制御機器（requesteing contorol device）６５，６７に割り当てられる。
【００３５】
また、図６に示すように、ＡＶ／Ｃリソーススケージュール掲示板サブユニット６１は、例えばユーザに対して透過的であり、リソーススケジュールカレンダは、システムレベルで更新又は変更される。ところで、ＡＶ／Ｃリソーススケージュール掲示板サブユニット６１を、ユーザが機器のスケジューリングに直接関与できるグラフィカルユーザインターフェースプログラム（graphical user interface program、図示せず）によってサポートするようにしてよい。このことは、本発明に含まれるものである。
【００３６】
また、図６に示すように、制御機器６５，６７によって送信されるリソース要求６８，６８’は、ＡＶ／Ｃ掲示板６６に対して、どの制御機器が要求を送信しているか、どのリソースサブユニットが要求されているか、及び何時リソースが要求されるかを通知するスケジュールデータを含んでいる。好ましい実施例において、ＡＶ／Ｃ掲示板６６は、掲示される各スケジュールエントリ用の状態データフィールド（satus data field）と経過データフィールド（progress data field）とを有する。状態データフィールドと経過データフィールドは、定期的に又は要求の状態が変わったときに、状態値と経過値によって更新される。ＡＶ／Ｃ掲示板６６は、状態値及び経過値をこのように更新することによって、システム６０の動的なスケジューリング環境を表すことができる。状態データフィールド及び経過データフィールドは、後述するように、ポスティング機器６５，６７、リソースサブユニット６２，６４、又はシステム６０によって更新される。状態値及び経過値は、各スケジュールエントリの詳細な履歴を提供するために、メモリ／ＣＰＵユニット６９に格納される。また、状態値及び経過値は、スケジュールの競合が起こったときに、制御機器６５と制御機器６７間で通信を行うために用いられる。
【００３７】
図７（ａ）は、経過データフィールドを示す図である。経過データフィールド７０は、例えば、ＡＶ／Ｃ掲示板６６に掲示される各スケジュールエントリ内に設けられている。経過データフィールド７０は、データブロック（data block）７１に設定されている所定の時間間隔で更新される。データブロック７１における更新間隔は、対象のアプリケーションに適する値に選択される。なお、経過データフィールド７０は、典型的には、スケジュールエントリが処理されている間、すなわちアクティブ状態にある間のみ、所定の時間間隔で更新される。経過データブロック７３内に経過データ値が設けられ、経過データ値は、現在要求されるタスクを完了するまでの経過を表している。経過データ値は、現在のタスクを完了するまでの経過を、ネットワークに接続されている他の機器に通知するために用いられる。例えば、経過データフィールド７０の値は、スケジュールエントリ内に表されている要求を完了するために必要な全体の時間に対する、要求を完了するために残されている時間の割合、要求を実際に実行した時間の割合、要求を実際に実行した時間、要求を完了するために残されている推定時間を判定するために用いられる。他の機器が、アクティブ要求（active request）と競合するリソース要求を送信したときは、経過状態値が競合する機器に送信され、アクティブ要求は、システムのニーズに基づいて、その競合する要求に優先されてもよいし、あるいは、競合する機器は、アクティブ要求が完了するまで、待機してもよい。
【００３８】
図７（ｂ）は、本発明の別の実施例を示す図である。スケジュールエントリは、図７（ａ）に示す経過データフィールドと類似した状態データフィールドを有する。状態データフィールドは、図７（ｂ）の表にリストアップされた状態値のうちの１つを含むことが望ましい。状態データフィールドは、状態値７５を掲示し、掲示されるスケジュールエントリの状態７７を示す。状態値７５は、多数の状態条件に対して掲示されてもよいが、特有の状態値が、制御機器の状態条件に対して掲示されることが望ましい。制御機器の状態条件は、制御機器がリソースを使用するために待機しているとき７６、制御機器がリソースを実際に使用しているとき７８、制御機器がスケジュールエントリを正常に完了したとき７９、制御機器がスケジュールエントリを異常な状態で完了したとき７４、又は制御機器のスケジュールエントリが優先されたとき７２を表している。
【００３９】
また、本発明の別の実施例において、各スケジュールエントリは、図７（ａ）に示す経過データフィールド７０及び状態データフィールドを有する。スケジュールされた制御機器は、データブロック７１において設定される所定の時間内で、経過データブロック７３を更新しなければならない。スケジュールされた制御機器が、所定時間内に経過データブロック７３を更新できない場合は、状態データフィールド７７が更新されて、ポスティング機器が適切に動作していないことを示す。制御機器がオフラインになる場合、又は動作していない場合に、この状態になってもよい。
【００４０】
図８（ａ）は、本発明のさらなる別の実施例を示す図である。スケジュールエントリは、図７（ａ）に示す経過データフィールドと類似したサブユニット状態データフィールド（subunit status data field）を有する。サブユニット状態データフィールドは、図８（ａ）の表にリストアップされた状態値のうちの一つを含んでいることが望ましい。各スケジュールエントリが、独自のサブユニット状態データフィールドを有し、各サブユニット状態データフィールドは、掲示されるサブユニット状態値８０を含み、掲示されたサブユニット状態値８０は、スケジュールされたリソースサブユニット８１の状態を表すことが望ましい。サブユニット状態値８０は、サブユニット状態フィールドを有するスケジュールエントリ内に掲示され、多数のサブユニット条件を表してもよい。しかし、特有のサブユニット状態値８０が掲示されることが望ましく、特有のサブユニット状態値は、リソースサブユニットをすぐに使用できるとき８２、リソースサブユニットがアクティブ状態であるとき８３、リソースサブユニットが期間以上に動作しているとき８４、又はリソースサブユニットが、ポスティング機器によって放棄されたとき８６を表している。本発明のＡＶ／Ｃアーキテクチャはまた、図８（ｂ）に示すサブユニット情報テーブル（subunit information table）８５を備える。サブユニット情報テーブル８５は、適切な書式（format）で、制御機器識別コード（control device identification code）８８、リソースサブユニット識別コード（resource subunit identification）８７及びリソースサブユニット状態値（resource subunit status value）８９を格納する。
【００４１】
図９は、本発明による、ＩＥＥＥ１３９４シリアルバスを利用したネットワーク内で動作する機器間で、動的なリソーススケジューリングを行う方法を示すフローチャートである。ステップ９１で、ポスティング機器は、時間フィールドデータ値（time field data）を有するリソース要求を生成して、リソース要求用の開始時刻、継続時間及び間隔時間を特定する。リソース要求はまた、リソースサブユニットと要求を行う制御機器とを識別する。リソース要求は、ネットワークを介してリソース機器に送信され、ステップ９３で、リソース機器は、リソースサブユニットが要求された時間に利用可能であるか否か判定する。リソース機器ユニットが要求された時間に利用可能である場合、ステップ９５で、その要求は、スケジュールエントリとしてリソース掲示板内に掲示される。リソーススケジュールエントリには、図７（ａ），７（ｂ）で説明した状態データフィールド及び経過データフィールドを有する。掲示されたリソーススケジュールエントリはまた、制御機器及びスケジュールされたリソースサブユニットを独自に識別するデータフィールドを有する。要求がアクティブ状態にある間、ステップ９７で、システムはその要求の経過を監視する。具体的には、ステップ９９で、システムは、スケジュールエントリが掲示された時間フィールド値に応じて受け入れられているかを判定する。システムが、要求は掲示された時間フィールド値に応じて受け入れられていると判定する場合、ステップ１０１で、経過データは更新されて、要求を完了するまでの経過度（degree）が示される。ステップ１０３で、システムは、要求が完了したか否かを判定する。要求が完全に受け入れられたと判定される場合は、ステップ１０５で、状態値は変更されて、要求が受け入れられたことが示される。ステップ１０７で、完了した状態値及び経過値は、格納されてスケジュールエントリに関する履歴が掲示される。ステップ１０３で、システムが、要求は完了していないと判定する場合、要求を完了するためのシステムの活動状態を監視すること、及び経過データを更新することを含む、ステップ９７からステップ１０１迄の行程が、スケジュールエントリが完全に受け入れられる、又は中止されるまで繰り返される。ステップ９９で、システムが、スケジュールエントリが中止された又は介入されていると判定する場合は、ステップ１０９で、スケジュールエントリの状態が変更され、ステップ１０７で、その状態値及び経過値は格納される。
【００４２】
ステップ９３で、リソース機器が、リソースサブユニットは、要求された時間に利用可能でないと判定する場合は、ステップ１１５で、ポスティング機器に対して、要求された時間中は、そのリソースが利用可能ではないことを示すメッセージが送信される。ステップ１１５でポスティング機器に送信されるメッセージが、競合するスケジュールエントリの現在の状態及び経過を示すことが望ましい。ステップ１１３で、ポスティング機器は、競合するスケジュールエントリに優先する必要があるか否か、言い換えると、現在のタスクが完了するまで待機するか否かを判定する。競合するスケジュールエントリに優先するか、又は待機するかは、競合する要求の状態値及び経過値、システムのニーズ、又はシステム内で競合する機器の順位、あるいはこれらの判定要素のいくつかに基づいて判定される。競合する制御機器が、競合しているスケジュールエントリに優先することを選択する場合は、ステップ９５で、新しいスケジュール要求が受け入れられ、ＡＶ／Ｃ掲示板に入力される。また、ステップ１１１で、優先されたスケジュールエントリの状態データフィールドは、更新されて、優先されたことが示され、ステップ１０７で、優先されたスケジュールエントリの状態値及び経過値は格納される。別の状況すなわち、競合する制御機器が、競合するスケジュールエントリに優先しないことを選択する場合は、ステップ１２０で、この要求に関するプログラムは終了する。
【００４３】
本発明の構成及び動作を明瞭に説明するために、詳細な具体例を用いて本発明を説明した。参照した具体例における細部は、添付の請求範囲を制限するものではない。本発明の趣旨及び範囲から逸脱することなく、ここに説明した具体例を変形できることは当業者にとって明らかである。例えば、本発明の機器は、いろいろな異なる方法で実限されてもよいこと、上述された本発明の好適な具体例における、アーキテクチャ、システム及び方法は、もっぱら説明上のものであることは、当業者にとって明らかである。本発明の好適な具体例では、ＩＥＥＥ１３９４規格（１９９５年版）のシリアルバス構造を用いているが、本発明は、別のまたは最新版のＩＥＥＥ１３９４シリアルバスを含む、適切な他のいかなるデジタルインターフェース、又はバス構造とともに実現してもよいことは、当業者にとって明らかである。
【００４４】
【発明の効果】
複数のポスティング機器からリソース要求を受信し、掲示されたスケジュールエントリを格納するリソーススケジュールを備える。各リソース要求は、開始時刻、継続時間及び間隔時間を含む時間データフィールドを有し、掲示されたスケジュールエントリはそれぞれ、要求するポスティング機器と要求されたリソースを識別し、定期的に更新される状態値を含む状態データフィールドを有する。これにより、複数のポスティング機器から、ネットワーク上のリソースサブユニットをスケージューリングする有益なスケージューリング機能を提供することができる。
【図面の簡単な説明】
【図１】コンピュータシステム及びビデオカメラを含むＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスネットワークの具体例を示すブロック図である。
【図２】コンピュータシステム１０の内部構成を示すブロック図である。
【図３】本発明を適用したＩＥＥＥ１３９４規格（１９９５年版）のシリアルバスで接続された機器システムを示すブロック図である。
【図４】本発明を適用し、リソースの使用を要求するポスティング機器と、リソースの使用が要求される目的機器とを有する機器ネットワークの具体例を示すブロック図である。
【図５】スケジュールエントリの詳細を示す高レベルのスケジュールエントリセクションを示す図である。
【図６】本発明を適用したシステムの構成を示すブロック図である。
【図７】経過データフィールドを示す図である。
【図８】本発明のさらなる別の実施例を示す図である。
【図９】ＩＥＥＥ１３９４シリアルバスを利用したネットワーク内で動作する機器間で、動的なリソーススケジューリングを行う方法を示すフローチャートである。
【符号の説明】
６１  ＡＶ／Ｃリソーススケジュール掲示板サブユニット、６３  リソース機器、６２，６４  リソースサブユニット、６５，６７  制御機器、６９  ＣＰＵ／メモリ
【図１】
0004323114.tif 000002
【図２】
0004323114.tif 000003
【図３】
0004323114.tif 000004
【図４】
0004323114.tif 000005
【図５】
0004323114.tif 000006
【図６】
0004323114.tif 000007
【図７】
0004323114.tif 000008
【図８】
0004323114.tif 000009
【図９】
0004323114.tif 000010