(57)【特許請求の範囲】
【請求項１】
通信ネットワークによって連結される機器のリソースに対するアプリケーションのアクセス優先順位を管理する方法であって：
前記ネットワークの前記リソースに対するアクセス優先順位のレベルを各アプリケーションに割り当てるステップであり、前記レベルは少なくとも２つのレベルのアクセス優先順位を有する、ところの割当ステップ；
リソースの予約を要求する第一アプリケーションが、現在リソースを使用している第二アプリケーションと同一又はより低いアクセス優先順位レベルを有する場合において、第一アプリケーションが、該第一アプリケーションの利益のために、前記第二アプリケーションに対してリソースの放棄の要求を送信し、前記第二アプリケーションが、前記リソースを放棄することを承認し或いは前記リソースを放棄することを拒否する交渉ステップ；及び
前記第一アプリケーションが前記第二アプリケーションより高いアクセス優先順位レベルを有する場合には、前記第一アプリケーションが、前記第一アプリケーション及び前記第二アプリケーションのアクセス優先順位のそれぞれのレベルに応じてプリエンプションを実行し、第一アプリケーションが第二アプリケーションと同一又はより低いアクセス優先順位レベルを有する場合には、第一アプリケーションが、前記交渉ステップの結果に応じて、前記第二アプリケーションによる前記リソースに対するアクセスに優先するプリエンプションを行うプリエンプションステップ；
を含む方法。
【請求項２】
前記リソースは、同時に少なくともＮ個のアプリケーションによるアクセスを許容し、ここで、Ｎは、１以上である、請求項１に記載の方法。
【請求項３】
前記アクセス優先順位のレベルは、ユーザの直接的な制御の下にないアプリケーションのための第一レベルアクセス優先順位と、ユーザによって直接的に制御され得るアプリケーションのための第二レベルアクセス優先順位とを含む、請求項１に記載の方法。
【請求項４】
Ｎ個のアプリケーションによって既に予約されたリソースのためのアクセスを予約することを試みるアプリケーションが、キュー中に配置され、前記Ｎ個のアプリケーションの１つによる前記リソースの開放のために待機する、請求項２に記載の方法。
【請求項５】
アプリケーションのアクセス要求中に、待機が前記アプリケーションによって特定される場合に限り、前記アプリケーションが前記キュー中で待機下に置かれる、請求項４に記載の方法。
【請求項６】
前記交渉ステップ中に前記第二レベルアクセス優先順位のアプリケーションによって予約される前記リソースを放棄する或いは放棄しないことについてのユーザの認可を要求するステップをさらに含む、請求項３に記載の方法。
【発明の詳細な説明】
【０００１】
本発明は、家庭内通信ネットワークにおけるプリケーションによるリソースに対するアクセスの優先順位の管理、並びに、プロセスを実行する機器に関する。
【０００２】
家庭内通信ネットワークでは、幾つかの機器が通信ネットワークによって連結され共通の言語によって通信される。このようなネットワークは、オーディオ及びビデオデータの分野で発展され、例えば、ＩＥＥＥ１３９４タイプのシリアルバスに基づいてもよい。ネットワークに接続される機器は、「リソース」つまり、特定のファシリティを有してもよい。テレビジョンは、例えば、チューナ、陰極線スクリーンを有する一方で、ビデオレコーダは、チューナ及び記録ファシリティを有する。機器のリソースがネットワークの他の機器に利用できるようにされ得る（例えば、ビデオレコーダは、テレビジョンのチューナを制御することで送信されるサービスを記録する）ため、リソースに対するアクセスの衝突が生じ得、リソースは、様々なアプリケーションから矛盾するコマンドを受信する可能性がある。
【０００３】
本発明は、アクセスの優先順位の管理を提案することを目的とする。
【０００４】
本発明の技術的内容は、通信ネットワークによって連結される機器のリソースに対するアプリケーションのアクセス優先順位を管理するプロセスに関わり、上記プロセスは、ネットワークのリソースに対する、少なくとも（ａ）ユーザによって直接制御されないアプリケーションの第１のアクセス優先レベル及び（ｂ）ユーザによって直接制御され得るアプリケーションに対する第２の優先レベルを含むアクセス優先レベルを各アプリケーションに割り当てる段階と、第２のアプリケーションによって前に得られたリソースに対するアクセスにおいて第１のアプリケーションによるプリエンプションを第１及び第２のアプリケーション夫々のアクセス優先順位に従って認可する段階とを有する。
【０００５】
変形例によると、リソースは、同時に少なくともＮのアプリケーションによるアクセスを可能にし、このとき、Ｎは１以上である。
【０００６】
変形例によると、プリエンプション段階の前に交渉フェーズがあり、この交渉フェーズ中、第１のアプリケーションは、第１のアプリケーションのためにアクセスを放棄することを承認又は拒否するかを問うメッセージを第２のアプリケーションに対して送信する。
【０００７】
第１の実施例によると、第１の優先レベルを有するアプリケーションによる第２の優先レベルを有するアプリケーションのプリエンプションフェーズの前には常に交渉フェーズがある。
【０００８】
第１の実施例によると、第２の優先レベルを有するアプリケーションによる第２の優先レベルを有するアプリケーションのプリエンプションフェーズの前には常に交渉フェーズがある。
【０００９】
特定的には、第１の実施例によると、第２の優先レベルは、ユーザによって制御可能なアプリケーションのために特徴付けられるレベルである。第２の優先レベルが存在することが仮定されると、交渉は、上記の場合、全てのプリエンプションの前に行われる。
【００１０】
第２の実施例によると、少なくとも３つの優先レベルが設けられ、第３の優先レベルは、第２の優先レベルよりも高く、第２の優先レベルは、第１の優先レベルよりも高く、第１のアプリケーションの優先レベルが第２のアプリケーションの優先レベルと同一又は低い場合交渉フェーズがある。
【００１１】
第２の実施例によると、第１のアプリケーションのセキュリティレベルが第２のアプリケーションのセキュリティレベルよりも高い場合に交渉を行うこと無くプリエンプションが直接行なわれる。
【００１２】
変形例によると、Ｎのクライアントアプリケーションによって既に予約されたリソースに対してアクセスを予約することを試みるアプリケーションは、キュー中におかれ、Ｎのクライアントアプリケーションの一つによってリソースが自由になるまでスタンバイする。
【００１３】
変形例によると、アプリケーションのアクセス要求においてこのアプリケーションがキュー中におかれることが特定された場合だけこのアプリケーションは、キュー中でスタンバイする。
【００１４】
本発明は、更に、所与のリソースに対して要求されるアクセスを最初に有するアプリケーションに一次レベルのアクセス権利を割り当てる段階と、上記リソースを予約する他のアプリケーションに対して二次レベルのアクセス権利を割り当てる段階とを有し、二次レベルのアクセス権利は、一次レベルのアクセス権利と干渉しない。
【００１５】
変形例によると、リソースに対して二次レベルのアクセス権利を有するアプリケーションによってコマンドが送信されることに続いて、リソース自体は、このコマンドが一次レベルのアクセス権利と干渉するか否かを決定する。
【００１６】
変形例によると、コマンドの実行が二次レベルのアクセス権利を有するアプリケーションから前に受信されるコマンドと干渉する場合でもこのリソースは、このリソースに対する一次のアクセス権利を有するアプリケーションから受信される全てのコマンドを承認する。
【００１７】
変形例によると、プリエンプション及び／又は交渉は、一次アクセスレベルを有するアプリケーションによって保持されるアクセスの放棄を強制させるためにだけ認可される。
【００１８】
一次及び二次アクセスレベルの概念に関連する上記特徴、並びに、以下に説明するこの概念に関する追加的な特徴は、後に独立したクレームの組の技術的内容を形成することができることに注意すべきである。
【００１９】
本発明の他の特徴及び利点は、添付図面によって例示される非制限的な実施例の説明を通じて明らかになる。
【００２０】
異なる図面では、同じ要素は、同一の参照番号を有する。
【００２１】
図１のネットワークは、ＩＥＥＥ１３９４−１９９５規格に従うシリアルバルの本実施例を含む。このバス１は、機器２、４、５、及び、６を連結させる。「機器」といった用語は、ネットワークに連結された物理的に異なる装置を意味すると理解される。各機器は、サブ機器３のようなサブ機器を１つ以上含み得る。これらサブ機器は、機器のファシリティであるリソースでもよい。リソースは、後に述べる「ＨＡＶｉ」仕様書の意味内でソフトウェアモジュール（又は「ソフトウェア要素」）を形成する。
【００２２】
例によって（図２を参照すると）、機器１は、ディジタルテレビジョンデコーダである一方で別の機器、例えば、機器Ｂは、ビデオレオーダである。デコーダＡは、２つのリソース、即ち、チューナ１２及びデマルチプレクサ１３を有する。ビデオレコーダＢもチューナ１４及び記録ファシリティ１５といった２つのリソースを有する。機器Ａ及びＢは、夫々グラフィカル・ユーザ・インタフェースであるアプリケーション（夫々１８及び１９）を有し、このグラフィカル・ユーザ・インタフェースは、ユーザに各機器のファシリティを直接管理することを可能にさせる。機器Ａのユーザ・インタフェースは、本実施例により、デマルチプレクサ１３から発せられるプログラムをネットワークの別の機器によって記録することを管理することを可能にする。リソースは、常駐され得、つまり、機器中に最初から常駐され得るが、ダウンロードされてもよい。
【００２３】
ＨＡＶｉに関連するファシリティ及びプロトコルの実行のために、各機器は、適当な情報処理手段、メモリ手段、及び、接続手段を有する。処理手段は、マイクロプロセッサ７或いはマイクロコントローラ又はより特定のタスク（エラー補正、信号処理、復調等）のための様々な専門回路に関連する同等のものを有し得る。メモリ手段（１０）は、ソフトウェアカーネルを含むために固定された静的メモリ或いはプログラム変更可能なメモリでもよく、及び／又は符号及び／又はデータのダウンロードされたセグメントでもよい。メモリ手段は、マイクロプロセッサカード及びＰＣＭＣＩＡ−タイプのカードのような移動可能な記憶装置、並びに、ハードディスク又は他の記憶手段も含み得る。接続手段は、特にＩＥＥＥ１３９４バスに対するインタフェースを含み、この手段は、図１中参照番号９で示される。本発明は、特定の構造の実行に制限されないことが明らかである。本説明によると、機器の様々な要素は、内部バス８によって連結される。明らかに、サブ機器も内部バスと通信するが、これらサブ機器がマイクロプロセッサ７並びにマイクロプロセッサから離れた別のハードウェアセグメントによって実行されるソフトウェアアプリケーションでもよいため、別々に例示される。
【００２４】
各機器は、レジストリー（各機器Ａ及びＢにおいて夫々１６及び１７と参照番号が付けられる）も含む。レジストリーは、出願人の名の下で１９９８年４月２３日に出願され第９８０５１１０号の番号が付けられた、仏国特許出願の技術的内容である。本特許出願の技術的内容に関連する別の特許出願は、本出願の優先日に出願された仏国特許出願第９８０７１８７号である。この特許出願は、通信ネットワークにおけるリソースの動作のプログラミングに関連する。
【００２５】
本発明に関連する他の面は、１９９８年５月１１日付のバージョン０．８において文献“The  HAVi  Architecture−Specification  of  the  Home  Audio/Video  interoperability（ＨＡＶｉ）Architecuture”中のバージョン０．８においてで更に説明され、この文献は、１９９８年５月１５日から公的に入手可能である。この仕様書のバージョン１．０が今日では入手可能である。ネットワークの様々な要素に関するより完全な事項のためにこれらの仕様書を参照してもく、本説明は、本発明を説明するのに必要な要素に制限される。
【００２６】
機器のレジストリー（他の機器に常駐する「リモート・レジストリー」に対してこの機器では「ローカル・レジストリー」とも称される）は、この機器の全てのリソースを管理することに関与する。このために、レジストリーは、機器の他のリソースが夫々の属性（リソースのタイプ、ネットワーク中のリソースの識別子等）を表示することで登録されるテーブルを有する。ソフトウェアモジュールが別のローカル・ソフトウェアモジュールと通信しなくてはならないとき、ソフトウェアモジュールは、既知のローカル・アドレスを有するローカル・レジストリーによりこれらのモジュールのリストを得ることができる。ソフトウェアモジュールが別の機器のリモート・ソフトウェアモジュールと通信しなくてはならないとき、ソフトウェアモジュールは、ローカル・レジストリー中を通ることでリモート・ソフトウェアモジュールのアドレス（「ＳＥＩＤ」）を得ることができる。ソフトウェアモジュールは、ローカル・レジストリーに要求を送信し、このローカル・レジストリーがこの要求をリモート・レジストリーに伝搬することで、ある検索基準に対応するモジュールのリストをこれらモジュールの場所とは無関係に決定し得る。要求は、探し求めたソフトウェアモジュール、例えば、モジュールのタイプ（ディスプレイ、レコーダ等）を選択する基準をパラメータの形態で含む。
【００２７】
これに関連して、機器のリソースも他のソフトウェアモジュールのようにローカル・レジストリーのレベルで登録される。ダウンロードされたモジュールは、機器のレジストリで登録されこのレジストリーは、このモジュールに対して実行プラットホームとして機能する。
【００２８】
レジストリーは、本発明によると、機器のメモリ１０に記憶されマイクロプロセッサ７によって実行されるプログラムである。
【００２９】
アプリケーションは、ユーザ（User）又は機械（Machine）の２つのプロファイルのうち一方でよい。ユーザプロファイルは、例えば、機器Ａのグラフィカル・ユーザ・インタフェース１８のようなユーザと直接相互作用することができるアプリケーションに対応する。機械プロファイルアプリケーションは、ユーザによって直接制御されないが例えば、プログラムされた動作を実行するアプリケーションに対応する。アプリケーションは、リソースを制御し得る。アプリケーションは、リソースでもよく、この場合、アプリケーションは、別のアプリケーションによって制御される。本実施例によると、リソースの予約の衝突を解決することに関連するとき、ユーザプロファイルアプリケーションの方が、機械プロファイルアプリケーションよりも優先される。ユーザプロファイルは、機械プロファイルよりも優先レベルが高いといえる。
【００３０】
リソースは、幾つかの特性を有する。
【００３１】
リソースは、いわゆる静的又は動的の種類のものでもよい。動的リソースは、適切なパラメータを特定することで幾つかの独立したセグメントに分割され得る。典型的には、通過帯域は、動的リソースであり、通過帯域を予約するアプリケーションは、予約されるべき帯域幅を特定しなくてはならない。静的な種類のリソースは、このような方法で予約され得ないリソースである。
【００３２】
動的リソースには、利用できる残量に対応する予約状態がある。
【００３３】
静的リソースは、いわゆる利用できる状態、いわゆる共有される状態、及び、いわゆるロックされた状態の３つの予約状態のうちの一つに成り得る。利用できる状態ではリソースは、全てのアプリケーションによって制御されない。共有される状態ではリソースは、少なくとも１つのアプリケーションによって制御されるが、それにもかかわらず他のアプリケーションに対して許可される制御コマンドに関するある制約を有して他のアプリケーションは、リソースを使用し得る。ロックされた状態ではリソースは、少なくとも１つのアプリケーションによって制御され、別のアプリケーションから生じる全ての制御コマンドを拒否する。
【００３４】
更に、各リソースにはリソースのファシリティを識別する変数値を有する記述子、つまり、データ構造又はレジストレーション、並びに、ネットワーク中のアドレスが関連する。既に述べたように、この記述子は、ローカル・レジストリのレベルで登録される。
【００３５】
本実施例によると、リソースの記述子は、リソース（例えば、オーディオ／ビデオ、ヒーティング、家庭用機器等）の活動範囲、リソースの機能（チューナ、デコーダ、モデム等）を示すリソースのタイプ、及び、接近容易性のレベル（同じ機器中に常駐するアプリケーションによってだけアクセス可能な「ローカル」リソース、又は、パブリックアプリケーションが常駐する機器以外の他の機器のプラットホームで実行されるアプリケーションによってもアクセス可能な「パブリック」リソース）を示す。
【００３６】
リソースの管理は、予約機構に基づく。予約は、制御コマンドの実行及びより一般的にはリソースの状態を変化させる全ての書き込みアクセスのために必要である。予約は、読み取りアクセスのためには一般的に必要でない。一旦予約が承認されると、アプリケーションは、リソースのクライアントアプリケーションとなり、このクライアントアプリケーションは、リソースに対して制御を有するが、この場合、このアプリケーションが唯一のアプリケーションとは限らず、従って、リソースに対するアクセスの衝突を解決する機構が必要である。
【００３７】
各機器は、「リソースマネージャ」と称されるソフトモジュールを具備する。図２のネットワークでは、機器Ａのリソースマネージャ及び機器Ｂのリソースマネージュは、夫々２０及び１１と参照番号が付される。これらモジュールは、レジストリーと協働する。レジストリーは、利用できるソフトウェアモジュール（リソース、アプリケーション等）のリストを局部的に保持し、リソースマネージャは、ローカル・リソースに対する予約を管理する。レジストリーによって保持される情報は、比較的静的である一方でリソースによって保持される情報は、一般的に早く発展されやすい。
【００３８】
本発明の実施例によると、リソースマネージャは、ローカル・レジストリーから直接ローカル・リソースのリストを得、ローカル・レジストリーがリーモートレジストリーに情報の要求をディスパッチした後にリモート・リソースは、ローカル・レジストリーからリモート・リソースのリストを得る。常駐しないリソースは、従って、リソースマネージャから容易にアクセスされる。例えば、機能を制御するモジュール（ＨＡＶｉ用語によると「ＦＣＭ」）がベースのオーディオ／ビデオ機器（ＨＡＶｉ用語によると「ＢＡＶ」）からダウンロードされるとき、この制御モジュールは、完全なファシリティ（「ＦＡＶ」）を含むオーディオ／ビデオ機器のような制御モジュールの実行プラットホームとして機能する機器のローカル・レジストリーで登録される。
【００３９】
登録に使用される原理は、リソース制御コマンドをディスパッチする前にアプリケーションは、このリソースが常駐する機器のリソースマネージャによってこのリソースを予約しなくてはならず、又、アプリケーションは、もはや使用していないリソースを自由にしなくてはならないことである。
【００４０】
本実施例によると、予約することを望むアプリケーションは、アプリケーションが常駐する機器のレジストリーによってリソースが常駐する機器のリソースマネージャのアドレスを決定する。一方で一旦アドレスが得られると、アプリケーションは、リソースの状態を確実にするためにリソースマネージャと接触し得る。他方で、一旦予約が得られると、この予約を行ったアプリケーションは、リソースの制御を得てその制御コマンドをリソースに直接向ける。リソースマネージャは、その後、リソースが自由にされる必要があるか否かを表示する以外では接触されない。
【００４１】
各リソースは、以下の（１）静的及び（２）動的情報を含む「コンテンション構造」として既知のデータ構造を保持する。
（１）静的情報
このタイプの情報は、先験的に発展される傾向がない。この情報は、リソースからリソースマネージャによって要求され得る。
（ａ）リソース制御モード
制御モードは、透明なモード、共有可能なモード、排他モードのうちの一つでもよい。
（ｂ）支持されるアプリケーションの最大数
このフィールドは、共有可能又は排他モードの場合に使用される。リソースは、同時に支持されるアプリケーションの最大数を示し、最小数は、１である。
（２）動的情報
（ａ）リソースを制御するアプリケーションに関する情報
各アプリケーションに関連する記憶されたデータの中には、
アプリケーションのプロファイル（ユーザ又は機械）、
適当なときに一次又は二次アプリケーション（以下参照）を取扱うときは、
いわゆるまだ明示されていない使用のために予約されたプライベートデータ、
予約の理由の説明を含むテキストフィールド（例えば、「ｚチャネルの登録」）があり、
（ｂ）リソースの現在の状態、即ち、利用できる、共有される、ロックされる
（ｃ）リソースを制御するアプリケーションの数
（ｄ）リソースを制御するアプリケーションのリスト
（ｅ）（例えば、このリソースに対するアプリケーションの最大数が超過したために）リソースを制御することができるよう待機するスタンバイされるアプリケーションのリストといった情報を含む。
【００４２】
リソースと同様にアプリケーションは、ＨＡＶｉ仕様書中に記載され「ＳＥＩＤ」の名を有するアドレスによって識別される。
【００４３】
より特定的には、リソースは、プリエンプション及び交渉機構を実行するためにリソースを制御するアプリケーションに関連する最小のデータを保持する。一次アプリケーションと二次アプリケーションに分割する機構を実行するために、リソースは、少なくとも一次アプリケーションの識別子を記憶する。これに関して、特に表１を参照してもよい。
【００４４】
共有可能な制御モードの場合、認可されるアクセスのタイプ、即ち、アプリケーションを一次アプリケーションと二次アプリケーションに分割する又は全てのアプリケーションに対して同等に処理することも示される。
【００４５】
透明な制御モードでは、リソースは、アプリケーションの間で区別を全く付けることなく幾つかのアプリケーションの部分に対して制約を課すこと無く同時に制御することを承認する。
【００４６】
共有可能なモードでは、幾つかのアプリケーションがリソースを同時に制御し得るが、アプリケーションのコマンドが不正確な動作につながる危険がある場合このリソースは、リソースの共有化を実行し、衝突を解決するプロセスにアクセスする。
【００４７】
この例は、図２のデコーダＡの場合である。この機器のチューナは、ある多重化されたストリームに対応する特定のトランスポンダから生じる信号を受信するために調節される。このストリーム中では、デマルチプレクサは、１つのサービス又は別のサービスに対応するパケットに標識をつけ、これらのパケットをクライアントアプリケーションに向けて抽出する能力を有する。所与のストリームが約十のサービスを伝達すると推定すると、別々のアプリケーションが同一の又は異なるサービスにアクセスするためにデマルチプレクサリソースを使用し得る。デマルチプレクサは、サーバとして動作される。アプリケーションがトランスポンダを変更しようと望むときに衝突が生じ、これは、全ての他のアプリケーションが現在のトランスポンダ上で送信されるサービスに対してアクセスを失うことを意味する。
【００４８】
本発明によると、このような衝突を解決する好ましいプロセスは、リソースのクライアントアプリケーションが一次及び二次クライアントアプリケーションに分類されることである。単一のアプリケーションがリソースのための一次アプリケーションとなり得、このアプリケーションは、最初にリソースを予約したアプリケーションである。全ての他のアプリケーションは、二次アプリケーションである。リソースは、一次アプリケーションから発生する全てのコマンドを受け入れるが、二次アプリケーションからはあるコマンドだけを限られた形で受け入れ得る。二次アプリケーションのコマンドは、一次アプリケーションのコマンドと衝突しない限りは考慮される。上記のデマルチプレクサの例では、一次アプリケーションだけがトランスポンダを変更する可能性を有する。二次アプリケーションは、単に現在のトランスポンダ上でサービスを選択する権利を有する。
【００４９】
変形例によると、一次アプリケーションは、その最後のユーザ（例えば、テレビジョンビューア）に対してユーザの動作が生じさせ得る妨害を通知する。前に説明した実施例に戻ると、ユーザにトランスポンダを変更させることを許可する前に一次アプリケーションは、該チューナを管理するリソースから適当に二次アプリケーションのリスト並びに対応する予約理由のリストを要求する。これらの理由は、ユーザの注意のために表示され、このユーザは、自身の動作による可能な影響を念頭にトランスポンダの変更を進めてもよいし進めなくてもよい。
【００５０】
本発明の実施例によると、全ての二次アプリケーションは、同一のコマンドの可能性を有する。２つのプロセスが区別され得、第１のプロセスによるとアプリケーションは、別のアプリケーションによってリソースに対して前に送信されたコマンドを妨害し得ない（「相互尊重の原理」（Principle  of  Mutual  Respect））一方で第２のプロセスによると、１つのアプリケーションは、別のアプリケーションを妨害し得る。
【００５１】
全ての場合において、別のアプリケーショによる二次アプリケーションの「妨害」を構成するものが何かは、制御されるリソースの性質に依存し、リソースの性質が解決されなくてはならないことである。本発明の実施例によると、二次アプリケーションの間のアクセスの衝突に関して相互尊重の原理が実行される。
【００５２】
変形例によると、一次アプリケーションと共に既に述べたように、必要であれば二次アプリケーションは、その最後のユーザに対してユーザの動作に課される制約を忠告する。
【００５３】
例によって、共有可能なリソースに対して、表１は、各リソースのレベルで記憶される幾つかの情報を提供する。
【００５４】
【表１】
0004918189.tif 000002
排他モードでは、リソースは、所与の瞬間に単一のアプリケーションによってだけ制御されてもよい。リソースは、少なくともこのアプリケーションの本来の性質並びにその優先レベル（本実施例によるとユーザ又は機械タイプ）を記憶する。例によって、図２の機器Ｂのようなビデオレコーダの機構を制御してもよい。アプリケーションが送信されるサービスの記録を要求する一方でその少し後に別のアプリケーションが記録媒体の取り出しを要求する場合に問題が生じ得る。この場合、最初のアプリケーションが唯一の制御を有する。
【００５５】
リソースのタイプに依存して、リソースに対するアクセスモードは、様々なコマンドに対して異なり得る。例えば、リソースの動作モードを変更するコマンドだけが衝突を発生し従って排他又は共有可能な制御モードを正当化し得る一方で全ての他のコマンド、例えば、読み出しアクセス又はイベント要求は、透明モードによって管理される。
【００５６】
リソースを予約するためにアプリケーションは、対応するコマンドをリソースの局部にあるリソースマネージャ、又は、アプリケーション自体の局部にあるマネージャに送信する。このコマンドは、後にリソースのレベルでコンテンション構造の後に書き込まれるアプリケーションに関連する情報をパラメータとして含む。透明モードにおけるリソースに関して、アプリケーションによって予約が全く行なわれない。本例によると、予約は、リソースの制御を直接得ることに関してなされ、つまり、本発明の説明を簡略化するために時間的な概念は、考慮されない。しかしながら、原理は、重なり合う将来的な期間に関して一つの同じリソースに対するアクセスの衝突に対しても類似する。本出願と同じ優先日を有する特許出願は、将来的な期間に関するこれらの予約に特に関連する。
【００５７】
リソースの現在の状態によって、以下の３つの場合が生じ得る。
【００５８】
第１に、予約が受け入れられ、アプリケーションが一次アプリケーション又は二次アプリケーションとなる場合である。これは、リソースが最初に利用できる又は共有可能な状態に夫々あるときの場合である。
【００５９】
第２に、リソースがロックされたため（例えば、最大数のアプリケーションに到達したため）予約が拒否される場合である。アプリケーションは、予約コマンドにおけるフラグの形態でこのリソースのキューにおかれること、及び、リソースマネージャが新しいアクセスレベル（二次アクセスが一次アクセスになるかキュー中のアプリケーションが二次又は一次アプリケーションとなるのいずれか）をリソースに自動的に割り当てたときにリソースマネージャから通知を得ることを要求してもよい。アプリケーションのアドレスは、適当なリソースのためにコンテンション構造のスタック中に記憶される。
【００６０】
第３に、アプリケーションのプロファイルが一次アプリケーションのタイトルを現在の一次アプリケーションと交渉することを可能にするようなプロファイルである場合にアプリケーションをスタンバイさせる場合である。本発明によると、交渉又はプリエンプション機構は、リソースマネージャを介して実行される。
【００６１】
リソースマネージャは、予約の結果をアプリケーションに送信し返す。予約が受け入れられた場合、メッセージは、アプリケーションが一次か二次かといった情報も含む。
【００６２】
アプリケーションがリソースに対する制御を有し、リソースの動作が終了したとき、アプリケーションは、リソースを自由にするコマンドをリソースマネージャに送信する。これは、アプリケーション及び適当なコンテンション構造に関する情報を消去する。
【００６３】
これは、過去に予約を試みたリソースをもはや必要としないスタンバイのアプリケーションに対する場合でもあり、アプリケーションは、リソースを自由にしなくてはならない。
【００６４】
本発明の実施例によると、プリエンプション及び交渉といった２つの機構が一次アプリケーションを別のアプリケーションで置換するために設けられる。機構のタイプは、アプリケーションからリソ−スマネージャに送られる予約コマンド中で識別される。プリエンプションフェーズの前に交渉フェーズがあってもよい。
【００６５】
アプリケーションが一次アプリケーションの状態を現在の一次アプリケーションと交渉することを望むとき、アプリケーションは、これに関するメッセージをリソースマネージャに送り、反対に、リソースマネージャは、一次アプリケーションにメッセージを送信する。一次アプリケーションは、その位置を放棄することに承認又は拒否し得る。ユーザタイプのアプリケーションは、例えば、要求をユーザ自身に送信し得る。
【００６６】
アプリケーションは、一次アプリケーションの状態を充当するためにプリエンプション機構を実行し得る。この場合、リソースマネージャは、このアプリケーションが実際に現在の一次アプリケーションの優先順位に対してこの要求を行う優先順位を有することを確認する。リソースマネージャがプリエンプションを認可する場合、リソースマネージャは、一次アプリケーションが受けなくてはならない転送コマンドを送る。リソースを自由にするために所定の時間が一次アプリケーションに与えられる。この時間に従わない場合、リソースマネージャは、リソースのデューティの転送を行う。
【００６７】
クライアントアプリケーションを一次アプリケーションと二次アプリケーションに分割する機構と共に予約中に一次アプリケーションの位置に関して衝突を解決することは、ユーザ及び機械プロファイルだけが存在する場合の観点が与えられて以下のルールに従う。
（１）ユーザプロファイルとのアプリケーションは、機械プロファイルとのアプリケーションに対して常に優先順位を有する。
（２）共有可能なリソースを予約する最初のアプリケーションが一次アプリケーションとなる。一次アプリケーションは、二次アプリケーションのコマンドと干渉し得る。二次アプリケーションは、一次アプリケーションのコマンドと干渉し得ない。
（３）ユーザプロファイルとのアリケーションは、交渉フェーズ無くして別のアプリケーション（ユーザ又は機械）のプリエンプションの権利を受けることができない。
（４）一次アプリケーションがリソースを自由にするとき、最も優先レベルが高い二次アプリケーションが一次アプリケーションとなる。幾つかの二次アプリケーションがこの優先レベルを有する場合、最も古いアプリケーションが一次アプリケーションとなる。このとき、スタンバイするアプリケーションが二次アプリケーションの場所に入れられ得る。
【００６８】
一次アプリケーションのプロファイル及び予約を探すアプリケーションに依存して４つの場合の衝突が生じ得る（ここでは、一次アプリケーションがユーザプロファイルを有するときいつでも交渉があると仮定する）。
（ａ）一次アプリケーションがユーザプロファイルを有し予約を要求するアプリケーションが機械プロファイルを有する。
【００６９】
この場合、リソースは、ユーザアプリケーションが退き得るか否かを確認するためにユーザアプリケーションにメッセージを送信する。これが交渉である。こうなった場合、機械プロファイルを有するアプリケーションが一次アプリケーションとなる。さもなければ、機械アプリケーションは、その試みを放棄する。
【００７０】
この場合に対応する例は、トランスポンダＡでサービス放送を見る一方で同じチューナを使用して予めプログラムされたビデオレコーダでトランスポンダＢ上のサービスを記録するテレビジョンビューアの例である。
（ｂ）一次アプリケーションは、機械プロファイルを有し、予約を要求するアプリケーションは、ユーザプロファイルを有する。
【００７１】
機械一次アプリケーションをユーザアプリケーションで置換する前にリソースマネージャは、この置換によって起こり得る結果をユーザアプリケーションに知らせ、ユーザアプリケーションがその置換を確認することを要求する一方で一次アプリケーションがそのタスクを終了させる可能性を与える。
【００７２】
この場合に対応する例は、ビデオレコーダがトランスポンダＡのサービスを記録する一方でテレビジョンビューアが同じチューナを使用してトランスポンダＢでサービスを見ることを望む場合の例である。テレビジョンビューアは、自身の決定を確認した場合進行中の記録が停止されなくてはならないことを忠告される。
（ｃ）一次アプリケーションは、ユーザプロァイルを有し、予約を要求するアプリケーションもユーザプロファイルを有する。
この場合、一次アプリケーションは、その一次レベルを保持又は放棄するかを決定し、原理は、場合（ａ）と同じで交渉がある。
この場合に対応する例は、第１のテレビジョンビューアが（一次アプリケーションによって制御を有する）第１のトランスポンダのサービスを見る一方で第２のテレビジョンビューアが同じチューナを使用して別のトランスポンダの別のサービスを見ることを望む場合の例である。第２のテレビジョンビューアは、第１のテレビジョンビューアの承認の下でだけ新しいトランスポンダの周波数にチューナを調節することができる。
（ｄ）一次アプリケーションは、機械プロァイルを有し、予約を要求するアプリケーションも機械プロファイルを有する。
本発明によると、機械プロファイルを有する全てのアプリケーションは、同じ優先順位を有するとして、一次アプリケーションは、そのタスクを置換されること無く終了する。
【００７３】
異なる実施例によると、アプリケーションの他のプロファイル、バックグラウンド（Background）、インストレーション（Installation）、（セキュリティ・アンド・システム（Security  and  System）が提供され、これらは、バックグラウンドタスク（例えば、使用されなくなったデータの拭き取り）で使用される低い優先順位のアプリケーション、ネットワークのインストール中及びコンフィギュレーションで使用されるアプリケーション、ある重要なイベント（例えば、セキュリティ警告）をユーザに通知するアプリケーション、及び、システムアプリケーション（例えば、レジストリー及びリソースマネージャ）に夫々対応する。２つ以上のプロファイルが存在するとき、システムの挙動は、一般的に表２によって説明される。上述の２つ以上のプロファイルを有する変形例では、Security  and  Systemは、例によってユーザプロファイルよりも優先レベルが高い。交渉フェーズ無くして、同一又は優先レベルが低いアプリケーションによってユーザプロファイルを有するアプリケーションのプレエンプションはない。しかしながら、表２に説明する例によって、一次アプリケーションがユーザプロファイルを有するが、制御を得ることを望むアプリケーションが厳密に優先レベルが高いとき交渉はない。
【００７４】
【表２】
0004918189.tif 000003
【図面の簡単な説明】
【図１】  本発明に従ってプロセスを実行する機器のネットワークのブロック図である。
【図２】  図１の機器の論理的構成を示す図である。
【図２】
0004918189.tif 000004