(57)【特許請求の範囲】
【請求項１】
（ａ）ネットワーク・バス上で接続された第１の装置を制御する方法であって、
（ｂ）前記ネットワーク・バス上の前記第１の装置と相互接続された少なくとも第２の装置と通信し、それによって前記第１の装置と前記第２の装置の間の関係を形成するステップと、
（ｃ）少なくとも１つの動作モードが前記ネットワーク・バスを介して前記第２の装置によって制御可能な前記第１の装置の動作モードを制御するステップと、
（ｄ）前記関係の持続性に関係する情報と前記関係を終了させる条件に関係する所定の条件とを記憶するステップと、
（ｅ）第３の装置から問い合わせデータを受信するステップと、
（ｆ）前記関係の持続性に関係する情報と前記問い合わせデータとを処理するステップと、
（ｇ）前記終了条件および前記問い合わせデータのうちの一方に応答して前記第１の装置と前記第２の装置との間の関係を終了させるステップと、
からなり、
前記第１の装置と前記第２の装置との間の前記関係の持続性に関する情報が少なくとも２つの異なる持続性レベルの１つからなる、前記方法。
【請求項２】
前記第１の装置と前記第２の装置との間の関係を終了させるステップは、前記第１の装置と前記第３の装置の間に新しい関係を形成するステップを含むものである、請求項１に記載の方法。
【請求項３】
さらに、前記関係を終了させるステップは、許可を得るために前記第２の装置にポーリングするステップに応答して実行される、請求項１に記載の方法。
【請求項４】
さらに、前記第２の装置の状態をモニタするステップを含む、請求項３に記載の方法。
【請求項５】
さらに、前記第１の装置に含まれている情報を変更するよう前記第２の装置をイネーブルするステップを含む、請求項４に記載の方法。
【発明の詳細な説明】
発明の属する技術分野
本発明は、例えばディジタル・データバスのような相互接続を介して、例えば消費者用電子装置等のような複数の装置（デバイス）の間で通信を行うためのシステムに関する。また、本発明は、特に、そのような装置の間のインターオペラビリティ（相互運用性、相互操作性、相互情報交換性）を管理（統御）するための構成に関する。
発明の背景
例えばテレビジョン受信機または受像機、表示装置、ビデオカセット・レコーダ（記録装置）（ＶＣＲ）、直接放送衛星（ＤＢＳ）受信機、およびホーム・コントロール装置（例えばセキュリティ（安全）システムまたは温度制御装置）のような電子装置（デバイス）を相互接続するために、データバスを用いることができる。データバスを用いた通信はバス・プロトコルに従って行われる。バス・プロトコルの例として、コンシューマ・エレクトロニクス・バス（Consumer Electronics Bus）即ちＣＥＢｕｓおよびＩＥＥＥ１３９４ハイ・パフォーマンス（高性能）シリアル・バス（High Performance Serial Bus）がある。
バス・プロトコルは、典型的には、制御情報とデータの両方の通信を行うために設けられる。例えば、ＣＥＢｕｓ制御情報は、エレクトロニクス・インダストリーズ・アソシエーション（ＥＩＡ、電子産業協会）規格書ＩＳ−６０で規定されたプロトコルを有する“コントロール・チャネル（制御チャネル）”上で通信される。特定のアプリケーション用の制御情報は、ＣＡＬ（共通アプリケーション言語、Common Application Language）として知られているプログラミング言語の形式を用いて規定することができる。
消費者用電子装置は、ますます複雑になり、増加し続ける多数の機能を備えている。完全なオーディオ−ビデオ（Ａ／Ｖ）システムを構築するには、それらの複雑な装置を共にデータバスを介して結合する必要がある一方で、その構築には多数の問題が生じる。例えば、１つの装置の或る複数の機能が、データバスに結合される１つまたは２つ以上の装置との対話（インタラクション）を要求することがある。別の装置における特定の動作を完了または完成（完結）させるためには、１つの装置の或る機能が必要かもしれない。種々の装置の各要求の間に競合（コンフリクト、衝突）が生じることがある。欧州特許出願０６０４１６６は、伝送信号のデータフィールドにおいて規定されているよりも多いデータの伝送を中断することなく実施することのできる通信システムを開示するものである。
現在、２つ以上の装置が共通の資源（リソース）の使用、例えばネットワーク・バス上に接続された第３の装置の使用について（その使用を求めて）競合（compete）したときには、時間的に最初のものがその装置を制御する。その最初の装置が共通の資源の捕捉を解除するまでは、他の装置は共通の資源にアクセスすることができない。その場合でも、単純なネットワーク、例えばテレビジョン、ケーブルボックス（cable box）およびＶＣＲで構成されたネットワークにおいては問題が生じない。そのような単純なネットワークでは、ＶＣＲはケーブルボックスによって“制御”され、即ちＶＣＲはケーブルボックスが供給しているものだけを記録する。しかし、もっと複雑なネットワークでは、２つの装置、例えばケーブルボックスとディジタル放送受信機が、共用の資源、即ちＶＣＲの制御権について（制御権をめぐって）競合することがある。
発明の概要
多くの制御アプリケーションにおいては、装置（デバイス）に対する一般的なアクセスを区別（差別）することが望ましい。この区別は、通常、１つの装置に便利性を与える。そのような場合、短時間（短期間）または長時間（長期間）の間、２つの装置の間に“ロッキンッグ（locking、閉錠）”といわれる特別な関係（relationship）が成立する。ロッキンッグの関係は、１つの装置が第２の装置（即ち“ロックされた装置”）に対するアクセスを制御することを可能にする。
一般的に、２つのタイプのロッキング方法（アプローチ）がある。第１の方法では、ロックされた装置が、自己が別の装置に対してアンロック（unlocked、開錠）され得るか（非ロック状態にできるか）および／またはロックされ得るか（ロック状態にできるか）を判断する。その装置をロックすることを求める要求は、そのロックされた装置に対して直接行われる。そのロックされた装置が新しい要求を満たすことができない場合には、ロックされた装置はそれをロックした装置（即ちロッキング装置）をポーリング（poll）して、現在のロック状態を終了できるかどうかおよび新しいロッキングを完成させる（consummate）ことができるか否かを確認する。そのロッキング装置が応答しない場合には、例えば失敗（failure）した場合には、ロックされた装置はそのロックを終了させて新しいロックを設定する。第２の方法においては、別の装置をロックしようとする装置が、ネットワークを通して、所望の装置とロックを形成している任意の装置に対してロックを終了させることを求める要求を伝達（ブロードキャスト、放送）する。
発明の概要
一般的に、本発明によれば、第１の電子装置は、データバスに結合するための手段と、データバスに結合された第１の電子装置と第２および第３の電子装置の間でのデータバスを介した通信を制御する制御手段と、を具えている。この制御手段は、それら装置間の相互の通信関係を管理（統御）する第２および第３の装置から受取った制御および問合せ（クエリ、質問）データを処理する。
本発明の１つの特徴によれば、ネットワーク・バスによって相互接続された少なくとも第２の装置と通信する通信手段を有する装置（第１の装置）が設けられており、それによって上述の上記第１の装置と上記第２の装置の間の関係が形成される。また、その通信手段は第３の装置から問合せデータを受取ることができるものである。さらに、その装置は、上記関係の持続性（persistence、パーシスタンス）に関係する情報を記憶するための第１の手段と、上記関係を終了させるための条件に関係する情報を記憶するための第２の手段と、上記第２の装置からの制御データに応答して上記装置の動作モードを制御する制御手段とを有する。この制御手段は、上記関係の情報および上記問合せデータを処理することができ、また、上記終了条件および上記問合せデータのうちの一方に応答して上記関係を終了させることができる。
本発明の別の特徴によれば、関係の情報は、上記関係が上記問合せデータに応答して終了する第１の状態と、上記関係が上記問合せデータに関係なく維持される第２の状態の２つの状態のうちの一方を含んでいる。
本発明のさらに別の特徴によれば、上記問合せデータに応答する上記関係の終了は、上記消費者電子装置と上記第３の装置の間に新しい関係を形成することを含んでいる。
本発明のさらに別な特徴によれば、制御手段は、上記関係を終了させる許可を得るために、上記問合せデータの受領に応答して上記第２の装置をポーリングすることができる。
本発明のさらに別な特徴によれば、ネットワーク・バスによって相互接続された複数の装置を有するシステムが設けられている。各装置は、通信手段と、情報を記憶する第１と第２の手段と、上述のような上記装置の動作モードを制御する制御手段と、を有する。
本発明の方法の特徴によれば、ネットワーク・バス上で接続された消費者電子装置のための方法は、ネットワーク・バスによって相互接続された少なくとも第２の装置と通信し、上記消費者電子装置の動作モードを制御し、上記関係の持続性に関係する情報と上記関係を終了させるための条件に関係する所定の条件とを記憶し、第３の装置から問合せデータを受取り、上記関係の重要性（重要度、重み、意味）に関係する上記情報と上記問合せデータとを処理し、上記終了条件と上記問合せデータのうちの一方に応答して上記関係を終了させることからなる。
【図面の簡単な説明】
図１Ａは、データバスを用いて互いに結合された電子装置のシステムをブロック図形式で示している。
図１Ｂは、図１Ａに示されているシステムの一部分の詳細をブロック図形式で示している。
図２〜図７は、図１に示されたシステムの動作を示すフロー図を示している。
図面において、異なる図面における同じ参照番号は同じまたは同様の機能を示している。
発明の詳細な説明
図１Ａは、データバス１３０を介して互いに結合された、参照番号１１０、１００および１２０によって識別される３つの電子装置（デバイス）Ａ、ＢおよびＣを含んだシステムを示している。装置Ａ、Ｂ、およびＣは、例えばオーディオおよび／またはビデオ信号処理装置およびホーム・コントロール装置のような消費者用電子装置を含んだ種々のタイプの電子装置であればよい。消費者用電子装置の具体例には、テレビジョン（ＴＶ）受信機（受像機）、表示装置、ケーブルボックス、ビデオ・テープレコーダ（ＶＴＲまたはＶＣＲ）、直接放送衛星受信機（例えばＤＳＳ衛星受信機）、コンパクト・ディスク（ＣＤ）ユニット、ディジタル・ビデオディスク（ＤＶＤ）ユニット、等が含まれる。ホーム・コントロール装置には、セキュリティ（安全）装置（例えば、カメラ、錠）、遠隔制御スイッチング装置および環境制御装置（例えば、暖房、冷房）等が含まれる。本発明の原理を取入れたシステムは、図１Ａに示されているような３つの装置より多い数の装置を含んでいてもよい。また、各装置は、相異なるタイプの装置でもよい。例えば、本発明によるシステムは、ＴＶ、ＶＣＲ、ケーブルボックス、衛星受信機、オーディオ・システムおよびホーム・コントロール装置を含めた家庭全体の多数の装置を含むものであってもよい。
図１Ａに示された例において、データバス１３０は、各装置間のデータおよび制御情報を通信するための複数の信号パス（経路）を含んでいる。このバス構成は、シリアル（直列）でもまたはパラレル（並列）でもよい。データバス上のデータ通信は、例えば上述のＣＥＢｕｓまたはＩＥＥＥ１３９４のプロトコルのような種々のバス・プロトコルの中の任意のものを用いて構成することができる。バス１３０を介して通信されるデータはビデオおよびオーディオ・データを含んでいる。例えば、ディジタル・ビデオ信号を受信する衛星受信機は、バス１３０を介してディジタルのビデオおよびオーディオ・データを、記録用のディジタル・テープレコーダ（ＤＴＲ）に転送することもできる。
装置１００は、装置１００をバス１３０に結合するためのバス・インタフェース・ユニット１０２を含んでいる。バス・インタフェース１０２は、バス１３０からデータを受信するのに適し、またバス１３０上にデータを送信するのに適したハードウェアを含んでいる。例えば、インタフェース１０２は、バス１３０からデータを受信して、装置１００がデータ処理準備完了状態になるまで一時記憶し、またバス１３０上での送信が準備完了状態になるまでデータを記憶するレジスタまたはバッファメモリを含んでいてもよい。
インタフェース１０２は制御マイクロコンピュータ（μＣ）１０４によって制御される。用語“マイクロコンピュータ”は、１つまたはそれ以上の集積回路および／または別個の複数の構成要素を用いて実装構成されたマイクロプロセッサ、マイクロコンピュータ、制御器（コントローラ）および制御コンピュータのような装置を含めた種々の装置を表すことを意図しているが、これらの装置に限定されるものではない。マイクロコンピュータ１０４は、装置１００内におけるインタフェース１０２と、例えば信号処理ユニット（図１Ａには図示せず）のようなその他のユニットとの間でデータを渡す処理を制御する。例えば、装置１００がＤＴＲであり、バス・インタフェース・ユニット１０２が記録用のディジタル・ビデオデータを受信する場合には、μＣ１０４は、インタフェース１０２が、装置１００内の、意図通りに記録を行うような信号処理回路にビデオおよびオーディオ・データを渡すことを保証する。また、μＣ１０４は、インタフェース１０２が、適切なバス・プロトコルに従ってバス１３０を介してデータを通信するように、インタフェース１０２を制御する。
マイクロコンピュータ１０４は、メモリ１０６に記憶された制御プログラムおよびデータによる制御の下で所要のバス・プロトコルを実行する。メモリ１０６は、例えば、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭを含む種々のタイプのメモリ、およびハード・ドライブまたはその他のタイプのバルク（bulk）記憶装置を含んでいる。制御プログラムは、バス・インタフェース１０２の機能、例えば通信をイネーブルまたはディセーブル（disable）し、装置１００内の他の動作に対してバス動作を調整し、バス通信用のデータをフォーマット化する等の各機能を制御するためのルーチンを含んでいればよい。
μＣ１０４によって行われるバス・インターフェース１０２の制御の１つの特徴は、装置１００内の資源の利用に対する競合する複数の要求を解決（resolve）する方法を決定することである。例えば、装置１１０がケーブルボックスであり、装置１２０がＤＳＳ衛星受信機であり、ユニット１００がビデオ・テープレコーダ（ＶＴＲ）である場合を想定する。ユーザ（使用者）は、特定の時間にケーブルボックス１１０を介して特定のプログラム（番組）の記録を開始するようにＶＴＲ１００をプログラムすることができる。ＶＴＲ１００がケーブルボックス１１０を介してプログラムを記録している間に、それと競合する命令（コマンド）が、ＤＳＳユニット１２０にＶＴＲ１００に対するアクセスを試行させる。通常のシステムでは、ＤＳＳユニット１２０により試みられるアクセスを無視することによって、またはＶＴＲ１００が利用できない状態にあることをユーザ（使用者）に伝えることによって、上述の問題を解決する。
本発明の特徴によれば、図１Ａに示されたシステムは、後で詳細に説明するような方法で資源に対する競合を解決するロック・マネージャ（管理装置）を実現する。図１Ａに示された典型例の実施形態において、μＣ１０４は、バス制御プログラム内に含まれている“ロック・マネージャ”ルーチンによる制御の下で動作して、装置１００が後で詳細に説明する方法で競合を確実に解決するようにする。“ロック機構”１０７０のルーチンもバス制御プログラム内に含まれており、ロック機構１０７０の動作については後の図２の詳細な説明において説明する。ロック・マネージャは、バス１３０に結合される各装置間で通信関係またはロッキング条件（コンディション）を設定し、またその関係がどのような条件で変更されるかを決定するように構成されている。ロック・マネージャの動作には、後で詳細に説明するような、メモリ１０６の部分１０７に記憶された各パラメータが必要である。競合を解決するときに必要となるロック関係に関連するパラメータは、図１Ａにおけるメモリ１０６のロック・マネージャ領域１０７内に記憶される。そのような３つのパラメータは、パーシスタンス（持続性）、ロックド（ロックされた）アドレス、およびアンロック（開錠）条件である。図１Ｂは、メモリ領域１０７における別々の３つのエントリー（項目）１０７１、１０７２、および１０７３に記憶されたその３つのパラメータを示している。図１Ａには示されていないが、装置１１０および１２０はそれぞれ、ユニット１００内のユニット１０２、１０４、１０６、および１０７によって形成されるものとして記載した機能と同様の機能を形成する各機能を含んでいる。ユニット１１０および１２０内の構成は装置１００内に示された構成と同様でもよいが、同様の機能は他の構成を用いて形成することもできる。
ロック・マネージャの動作の一例として、上述の競合の例について考える。ロック・マネージャを用いて、ケーブルボックス１１０からのプログラムをＶＴＲ１００を用いて記録するには、ロック要求をＶＴＲ１００に送信するケーブルボックス１１０のバス制御機能が必要である。このロック要求は、ＶＴＲ１００に対して、ケーブルボックス１１０との或る関係、即ちロック条件を設定するように依頼するものである。マイクロコンピュータ１０４は、バス・インタフェース・ユニット１０２を介してロック要求を受信し、ＶＴＲ１００が既に別の装置にロック状態されている否かを判断する。否であれば、即ち、ＶＴＲがロッキング可能である場合には、ＶＴＲ１００は、ロック機構１０７０において、ロックが設定されたことを示す応答をケーブルボックス１１０に送信する。ケーブルボックス１１０からの所望のプログラムの記録が進行し、そのロック関係によって、上述のパーシスタンス（持続性）およびアンロック条件のようなパラメータによって規定される或る条件以外の場合にはその記録動作への割込みが防止される。この或る条件は、後で詳細に説明すようにロック関係に関連するものである。各パラメータの値は、ロッキング装置、即ちロック条件を開始するユニット（この例ではケーブルボックス１１０）によって設定され、ロックされた装置（この例におけるＶＴＲ）におけるメモリ１０６の領域１０７のそれぞれの部分に転送されて記憶される。ＤＳＳユニット１２０がＶＴＲ１００の使用を要求するときには、ＤＳＳユニット１２０内のロック・マネージャ機能がＶＴＲ１００にロック要求を送る。先に形成された現在のロック関係がＶＴＲ１００とケーブルボックス１１０の間に存在するので、ＶＴＲ１００内のロック・マネージャは、ＶＴＲ１００に記憶された現在のロック条件のパラメータに従ってＤＳＳ１２０からのロック要求を処理し、後で説明する方法で、競合する要求を解決（処理）する。
図２は、ロック・マネージャ１０７と協調動作するロッキング機構１０７０の動作を示している。ロック・マネージャ１０７は、“マスター装置”が開始する関係またはロックを管理する。ロック機構１０７０は、２つの装置のロッキングを共に実行する。マスター（主）装置がロックの開始を希望するときには、マスター装置はスレーブ（従）装置に命令を送信する。装置はロック制御に関係する種々の状態の中の任意の１つの状態になっていればよい。そのような４つの状態、アンロック状態、ロック状態、アンロック要求のペンディング（未処理）状態、およびロック・ポインタ変更状態が、図２における楕円２１０、２２０、２３０、および２４０によって示されている。各状態間の遷移は各楕円部分間をつなぐ線によって示されている。図２の上部に示されているように、ロック・マネージャは、ロックおよびアンロック要求を含む各要求を受取る。図２の下部に示されているように、ロック機構は、要求に応答して、“グラント＿ロック（grant＿lock、ロック許可）”または“ロック＿イン＿ユース（lock＿in＿use、ロック使用中）”のような応答を発生することができる。また、ロック機構は、アンロック要求および装置エラー／リセット指示（indication）を発生することができる。
図２に示されているように、このシステムは、ロック要求に応答してアンロック状態２１０からロック状態２２０に遷移して、グラント＿ロック（grant＿lock）応答を発生する。ロック状態２２０からアンロック状態２１０への復帰（リターン）は、ロックの解除に応答して発生する。ロック解除は、状態２３０と２４０を経由した遷移によって発生する。このシステムは、アンロック要求に応答して、状態２２０からアンロック要求ペンディング状態２３０に移行する。状態２３０において、システムは、パーシスタンス・パラメータおよびアンロック条件のようなパラメータを処理して、ロックが解除されるべきかどうかを決定する。ロックが解除（dissolve）されない場合には、ロック＿イン＿ユース（lock＿in＿use）メッセージが送信されて、システムがロック状態２２０に復帰する。ロックが解除できる場合には、アンロック・メッセージが発生されて、システムは状態２４０に遷移し、状態２４０において、ロックされていたアドレスまたはロッキング・ポインタが、現在ロックを要求している装置のアドレスまたはポインタに変更される。その後、システムはロック状態２２０に遷移して、グラント＿ロック（grant＿lock）メッセージを発生する。
種々の条件下における、即ち装置間の種々のタイプのトランザクションの期間におけるロック・マネージャ１０７およびロック機構１０７０の動作が、図３〜図７に示されている。図３において、装置Ｂがロックされておらず、装置Ｂは、装置Ａからのロック要求に応答して装置Ａとのロックを設定する。
図４において、装置Ｂは、前のロック要求に応答して装置Ｃにロックされており、装置Ａからの競合するロック要求を受け取る。そのパーシスタンス・パラメータは、アンロッキングして装置Ａと再ロッキングする前に、装置Ｃに対してアンロッキング承認（approval）を要求する必要がないことを意味する０（ゼロ）に設定されている。装置Ｂはアンロック条件パラメータの評価だけを行って、装置Ｃとのロックを解除するか否かを決定しなければならない。
図５において、装置Ｂは、装置Ｃからの前のロック要求に応答して装置Ｃにロックされており、パーシスタンス・パラメータが１に設定されている。装置Ｂは、“ディスインヘリット・ロック（disinherit lock、ロック承継排除）”要求ともいわれるアンロック要求を装置Ｃに送信する。装置Ｃにおけるロック・マネージャは、ロックを解除すべきか否かを決定する。図４において、装置Ｃは、ロックを維持するよう決定し、“リソース・イン・ユース（resource in use、資源使用中）”のメッセージを送信し、このメッセージは装置Ｂによって装置Ａに中継される。
図６に示されているトランザクションは、装置Ｃの装置Ｂとのロックを解除することによって装置Ｃが装置Ａのロック要求に応答することを除けば、図４におけるトランザクション（即ちパーシスタンス（持続性）＝１）と同様である。こうして、装置Ｃはアンロック・メッセージを装置Ｂに送信し、その後、装置Ｂは装置Ａとのロックを許可する。
図７は装置Ｂが装置Ｃにロックされていて、そのパーシスタンス（持続性）が０（ゼロ）に等しい場合のトランザクションを示しており、装置Ａは、全てのロッキング・マネージャに呼かけ（hail）て、装置Ｂとロックしたいという装置Ａの希望を示す。装置Ｃは、装置Ａに対して、装置Ｃが装置Ｂとのロックを解除することを通知する。次いで、パーシスタンス（持続性）パラメータが０（ゼロ）に設定されているので、装置Ａは装置Ｂにロック要求を送信し、装置Ｂは装置Ａにロックし、装置Ｂとのロックを解除するように装置Ｃに命令するメッセージを装置Ｃに送信することができる。
さらに、ロッキング装置またはマスター装置だけがロック・マネージャ１０７に要求すること、およびスレーブ装置またはロック可能な装置がロック機構１０７０を使用するだけであることは、本発明の範囲内の事項である。そのようなシステムの動作は本明細書に記載したシステムと同様である。
上述した事項に加えて、ロック・マネージャの特徴を含んだ本発明のロック・マネージャの特徴に関して、後でさらに詳細に説明する。単に便宜上、次の詳細な説明は、ＣＡＬプログラミング言語の使用に基づく態様を含んでいる。しかし、それに代えて別の任意のプログラミング言語を用いてもよいことに留意すべきである。
ロッキングを用いるアプリケーションの例
次に、上述したアプリケーションに加えて、ロッキング関係（relationship）が必要なアプリケーションについて説明する。第１の例において、装置（“装置Ａ”）は、幾つかのデータ・パケットを遠隔装置（“装置Ｂ”）にダウンロードすることを希望する。装置Ａは、そのダウンロードが完了するまでは、装置Ｂ中に存在するデータが上書き（overwrite）されるのを好まない。通常、この機能は、両装置におけるセグメント化されたネットワーク・サービス（Segmented Network Service）を要求する。しかし、本発明に従って、装置Ａは一時的ロッキング関係を設定し、この一時的ロッキング関係によって、装置Ａが装置Ｂに書込むことのできる唯一の装置であることが保証される。データ転送の後、装置Ａは、ロッキング関係を終了させ、装置Ｂを“アンロック”（開錠）する。
第２の例において、ケーブルボックスのような外部装置はプログラム・タイマ・イベント（事象）を実行する。ケーブルボックスは、ＶＣＲトランスポート機構を“ロック”する。これによって、そのセッションが終了するかまたはオーバライド（無効化）条件が発生するまで、ＶＣＲが記録モードに維持される。ケーブルボックスは、そのイベントが終了したときにストップ命令（Stop）をＶＣＲに送信してＶＣＲをアンロックする。
第３の例において、装置は、或る期間にＯＳＤメッセージを表示することを希望する。その装置は、ディスプレイ（表示装置）を自己にロックして、関連する表示情報を送信する。この表示装置は、或る期間に情報を表示する。ロックされた装置は、ロッキング装置自体によって、または例えばタイムアウト等の条件付きイベントによってアンロックされる。
また、特別な形式のロッキング、“リスニング（聴取）”も実行される。種々の装置を制御し、種々の装置とインターオペレーティング（相互運用、相互操作、相互情報交換）するには、それらの状態を知る機能が必要である。リスニング機能を含んでいる装置は、例えば家庭内に置かれた装置等の特別なグループの装置によって送信された各同報レポート（報告）間の区別（判別）を行う。
例えば、状態変更情報が或る装置から別の装置へと自動的に送信される。ＶＣＲが表示装置に対してモーション（動き）モード状態を更新し、または温度センサが環境マネージャに対して更新情報を送信する。この方法（アプローチ）には２つの問題がある。第１の問題は、そのレポートの行き先を決定することである。コンパニオン（連係、協調）の問題は、受信装置がその機能にとってどのレポート情報が重要かを決定することである。このような状況が生じるのは、同じ装置タイプ、例えばサーモスタットまたはセキュリティ・センサ（安全検知器）のような同じ装置タイプの複数のインスタンス（事柄）が存在していて、同じ家庭内の種々のサブ・システムに報告するときである。各情報ソース（源）間の区別を行う必要がある。リスニング機能はこの機能を実現する。
リスニングの種々のアプリケーションが存在する。幾つかのアプリケーションは他のアプリケーションよりも動的（ダイナミック）である。環境制御は、安定な（静的）リスニング・アプリケーションの例である。そのようなシステムでは、リスニング機能は、初期設定機能の後は相対的に静的である。これらのシステムでは、リスニングを行うのに信頼性が高く安価な手段が必要である。例えば、セキュリティおよび特別なアクセスのような問題は重要である。このシステムの装置構成は、設置（インストール）のときに形成され、高頻度で変更されることはまれである。
これはＡ／Ｖシステムと全く対照的である。Ａ／Ｖシステムは非常にダイナミック（動的）である。装置は、比較的高頻度で設置され取外される。ビデオ・ソース（源）および要求機能によって、システム装置構成が迅速に規則的に変化する。再生、記録、表示メッセージおよびタイマ・イベントの全てが、装置のリスニングおよびロッキングの変更を要求する。リスニング・ソース（聴取源）装置を瞬間的にＶＣＲからＤＢＳ装置に変更する必要がある。また、非常に多くの装置間リスニングが存在する。ケーブルボックスがＶＣＲの状態をリスニングしている間に、ＴＶは、表示のために１つの装置、環境システムをリスニングすることができる。
種々のレベルの望ましいロッキングおよびリスニングが存在する。多くのインスタンス（事柄）において、アプリケーションは装置レベルのロッキングだけを要求する。しかし、オブジェクト（対象）レベルでロックすることが望ましい場合もある。（即ち、装置が２つ以上の（１つより多い）オブジェクトで構成されることがある。例えば、装置が、装置自体の内部における別々の制御可能な機能を有することがある。）このような１つの状況は、ＶＣＲアプリケーションにおいて、他の装置にタイマ・イベント（事象）をエディット（編集）または付加させている間に、トランスポート機構をロックすることが望ましい場合である。同様に、適正な表示を保証するために、ＴＶにおけるディスプレイ・オブジェクトをロックすることが望ましいが、他の通信に応答する装置の機能をロックすることは望ましくない。
ロッキング属性（attribute）は、関係（リレーショナル）、条件付き（conditional）および継承（inherited）の各特性を有する。条件付きロッキング特性の例は、オブジェクト（object）が装置によって既にロックされているときである。アンロック状態のオブジェクトはロック可能である。しかし、その装置はロック可能でないかもしれない。そのような状況において、その装置は、オブジェクトの１つをロックした同じ装置によってのみロック可能である。継承されたロッキングでは、装置内の全てのオブジェクトがオブジェクトのロック状態（status）を継承すると推定される。
ロック・マネージャ
他の装置をロックすることを希望する全ての装置は、装置によって開始された活性状態の全てのロックを追跡し且つ遠隔装置をロッキングしアンロッキングする責務のある“ロック・マネージャ”を持っていなければならい。ＣＡＬを用いて実装構成された、そのようなロック・マネージャの構成を次に説明する。
0004079335.tif 000002
上述の区分けされた各パラメータについて以下に説明する。
１．ロック＿ポインタ（Lock＿pointer）定義
データ・メモリ（Data Memory）のメモリ＿ブロック（memory＿block）インスタンス変数（ＩＶ）の各レコード（記録）は、ネットワーク上の遠隔位置にあるロックされた装置を指すポインタである。ロック＿ポインタ（lock＿pointer）データは、３つのフィールド、（１）＜デバイス＿ネットワーク＿アドレス＞（<Device＿Network＿Address>）、（２）＜ロックド＿コンテキスト＿ＩＤ＞（<Locked＿Context＿ID>）、および（３）＜ロックド＿オブジェクト＿ＩＤ＞（<Locked＿Object＿ID>）、を含んでいる。左側の空欄のフィールドは、ナル（null：空、０）と考えられる。
デバイス・ネットワーク・アドレス（Device Network Address）フィールドは、ロックされた装置（デバイス）のネットワーク・アドレスである。ＣＥＢｕｓアプリケーションにおいて、ＭＡＣアドレスはネットワーク・アドレスとして使用される。
ロックド＿コンテキスト＿ＩＤ（Locked＿Context＿ID）フィールドは２つのバイトを含んでいる。第１のバイトはコンテキスト番号またはコンテキスト・ワイルドカード（context wildcard）“ＤＥ”の何れかである。ＤＥワイルドカードは、ロックが装置中の同じコンテキストの全てのインスタンスまたは全ての例示（instanciation）に対応することを示唆する。第２のバイトは、コンテキスト＿クラス＿ＩＤ（Context＿Class＿ID）である。残りのバイトはナル（空）である。
このロックド＿オブジェクト＿ＩＤ（Locked＿Object＿ID）フィールドは２つのバイトに分割されている。第１のバイトはオブジェクト＿ナンバー（Object＿Number）またはオブジェクト・ワイルドカード“００”の何れかである。オブジェクト・ワイルドカードが使用されるときには、第２のバイトはオブジェクト＿クラス（Object＿Class）である。ワイルドカードが使用されないときには、第２のバイトはナル（空、０）である。これは、同じオブジェクト・クラス（Object＿Class）内の全てのオブジェクトのロッキングすることを可能にする。
２．アンロック・メッセージ（Unlock Message）定義
ロックされた装置は、アンロック・メッセージをロッキング・マネージャに送信する。３つの定義されたアンロック・メッセージ、（１）デバイス＿アンロック（Device＿Unlock、装置アンロック）、（２）コンテキスト＿アンロック（Context＿Unlock）、および（３）オブジェクト・アンロック（Object＿Unlock）、が存在する。
アンロック・メッセージはマクロ（Macro）、Ｕ４を用いて送信される。Ｕ４マクロは２つのアーギュメント（argument、引き数、変数）フィールドを含んでいる。第１のアーギュメントはデバイス＿ネットワーク＿アドレス（Device＿Network＿Address、装置ネットワーク・アドレス）を含んでいる。第２のアーギュメントはコンテキストおよびオブジェクト情報を含んでいる。マクロ・プロトタイプ（原型）は次の通りである。
“<context＿ID> <object＿ID> U4 <data token> <size of data> <escape token> <Device＿Network＿Address> F5 > <data＿token> <size of data> <escape token> <Context＿Number> <Context＿Class＿ID> <Object＿ID> <Object＿Class>“
〔訳、data token：データ・トークン、size of data：データのサイズ、escape token：エスケープ・トークン〕
コンテキストがロックされたときには、コンテキスト＿ナンバー（Context＿Number）およびコンテキスト＿クラス＿ＩＤ（Context＿Class＿ID）が第２のアーギュメント・フィールドに置かれる（オブジェクト＿ＩＤ（Object＿ID）およびオブジェクト＿クラス（Object＿Class）は与えられない）。オブジェクト情報はナルである。
また、オブジェクトがロックされたときには、コンテキスト＿ナンバー（Context＿Number）、コンテキスト＿クラス＿ＩＤ（Context＿Class＿ID）およびオブジェクト＿クラス（Object＿Class）は、第２のアーギュメントで与えられる。
ａ）装置アンロック・メッセージ（Device Unlock Message）
デバイス＿アンロック（Device＿Unlock、装置アンロック）メッセージは、ロックされていた装置の＜デバイス＿ネットワーク＿アドレス＞（<Device＿Network＿Address>）を含んでいなければならない。第２のアーギュメントはそのメッセージ中に含まれていない。
“00 04 55 34 F5 F5 F4 34 F6<Device＿Network＿Address>F5“
ロック・マネージャ・オブジェクト中に置かれたロッキング・ポインティング
・ベクトルの例
0004079335.tif 000003
ロッキング装置
装置をロックする機能は、前に設定されたロックに依存する。装置のロッキングには、他の全てのロックを上書きすることが必要である。
ロッキング実装構成には次のテーブルにおける変数（ＩＶ）が使用される。ロッキング＿アドレス（Locking＿Address）ＩＶは全ての実装構成中に存在しなければならない。パーシスタンス（持続性）のデフォルト・レベルは“０”である。次のサブセクションはＩＶの詳細な説明を含んでいる。
0004079335.tif 000004
ａ）パーシスタンス（持続性）ＩＶ
パーシスタンス（持続性）ＩＶは装置のアンロックの振る舞いに影響を与える。現在、３つの定義されたパーシスタンス・レベル、（０）ルース（疎）、（１）タイト（密）、および（２）リスニング（聴取）が存在する。パーシスタンス（持続性）ＩＶはルース（Loose）のデフォルト・レベルを有する。装置がアンロック状態に反転したときには、装置はパーシスタンスにデフォルト・レベルを設定する。
ルース・ロッキング・レベルはパーシスタンス・レベルが“０”のときに発生する。ルース・ロッキングの結果、装置はそれを制御しようとする各装置の間の区別（差別）を行う。しかし、その結合（binding）はルースである。これは、ロックされた装置が、前のロッキング装置が先に形成された現在のロックを解除しなければならないという確信の下で新しいロックに対する要求を許可することができることを意味する。ロッキング・レベルがルースであるときには、ロッキング装置は要求があったときに自動的にロックを解除する。その結果、前のロックは速やかに解除され、新しいロックが許可される。
ルースにロックされた装置は、ロッキング＿アドレス（Locking＿Address）を変更することを求める要求を受信すると、完了メッセージを返送（リターン）して、前のロッキング装置に対してロックを解除するよう通知を送信する。ルース・ロッキングは任意の装置がロッキング＿アドレスＩＶ（Locking＿Address IV）を変更できると推定する。
タイト・ロッキングは、パーシスタンス・フィールドが“１”に設定されたときに生じる。これによって、そのロッキング装置だけがロッキング＿アドレスＩＶ（Locking＿Address IV）を変更するまたは変更する許可を与えることが可能になる。これは、第３の装置がロック状態の装置とのロックを形成することを希望するときに有用である。この場合、第３の装置はロック状態の装置に問合せる。このロック状態の装置は、ロッキング装置のロック・マネージャ・オブジェクト（Lock Manager Object）にアンロック・メッセージを送信する。このロッキング装置は、ロックを形成できるかまたはロックを形成できないかの何れかである。即ち、ロッキング装置は前のロックを解除するときに完了トークン（Completed Token）、ＦＥを返送（リターン）する。それ以外の場合には、ロッキング・マネージャは、エラー−資源使用中の（８）コードを有するＦＤトークンを返送（リターン）する。
パーシスタンスＩＶを“２”に設定すると、リスニングといわれるロッキングの形式が生じる（上述の通り）。リスニングにおいては、“ロックされた”装置は自己を別の装置に結合する。装置はそのアプリケーションに応じて種々のレベルのパーシスタンスを実現することができる。
ｂ）キー＿エントリーＩＶ（Key＿Entry IV）
キー＿エントリーＩＶ（Key＿Entry IV）は、ロックされた装置に入力される単純なキーとして作用する。このＩＶは保護された変数にアクセスすることを可能にする。このオプション（任意選択）は、例えば特別な診断動作およびセットアップ動作のようなプライベートな（個人的な）機能を一般のアクセスから保護する。また、それは、装置がリスニング・アプリケーションにおける各ソース（源）の間の区別を行うことを可能にする。
キー＿エントリーＩＶ（Key＿Entry IV）の使用方法は２つある。第１の使用法は、タイト・ロック（パーシスタンス＝１）のときに設定される。ロッキング装置は、装置のプライベート領域に対するアクセスを許可するデータ・タイプ変数キー＿エントリー（Key＿Entry）値を与える。この値は、説明の便宜上、“ロック＿キー（lock＿key）”として定義される。
第２の使用方法は、リスニング・アプリケーション（パーシスタンス＝２）におけるものである。リスニング機能は、キー＿エントリーＩＶ（Key＿Entry IV）を追加のディスクリミネータとして使用する。このキー＿エントリー（Key＿Entry）機能についてはこのドキュメントの後の方で説明する。
第１のレベルのプライバシーに加えて、製造業者は、キー＿エントリーＩＶ（Key＿Entry IV）を、認証（authentication）を必要とする保護変数となるように選択することができる。これによって、特別なアクセスおよび認証の発生（発行）が分離される。キー＿エントリーＩＶ（Key＿Entry IV）は、装置がアンロック状態にあるときまたはパーシスタンスが“ルース”に設定されていないときには、不活性状態にある。デフォルト・キー＿エントリー値は“ナル（０）”である。装置がアンロックされるかまたはパーシスタンス・レベルが変更されたときには、キー＿エントリーＩＶ（Key＿Entry IV）はデフォルト値に反転する。その結果、ロッキング装置だけがキー＿エントリーＩＶ（Key＿Entry IV）値を供給するかまたは読取ることができるようになる。それによって、１つの装置だけがプライベートなデータまたは機能にアクセスすることが可能になる。
アプリケーションに応じて、“ロック＿キー（lock＿key）”は、ＲＯＭ内に位置する固定されたキー、または“トラステッド・キー（trusted key）”のような書込み可能なキーであり得る。通常、唯一の有効キー＿エントリ（Key＿Entry）値が存在するが、複数の有効キー＿エントリーＩＶ（Key＿Entry IV）の値も存在し得る。製造業者はロック＿キーＩＶ（lock＿Entry IV）を書込み可能であるように選択することができる。保護された装置は、キー＿エントリーＩＶ（Key＿Entry IV）を無効エントリー（例えば論理長さを０）または偽値に設定することによって、ロックの解除（disarm）によって、またはロック・パーシスタンス＜＞１の変更によって、再びプライベートになる。
ｃ）ロッキング＿アドレスＩＶ（Locking＿Address IV）
ロッキング＿アドレスＩＶ（Locking＿Address IV）は、データ・タイプ変数であり、その装置をロックしたネットワーク・アドレスである。ＣＥＢｕｓアプリケーションにおいて、ＭＡＣアドレスはネットワーク・アドレスとして使用される。
ロッキング装置は、ネットワーク・アドレスを適正なロッキング＿アドレスＩＶ（Locking＿Address IV）に書込んだときに、装置とのロック状態を開始する。いったんロックが設定された後は、ロッキング＿アドレスＩＶ（Locking＿Address IV）が無効アドレス（例えば、論理長さが０）に設定されることによってロックが解除される。ロッキングを支援しない装置に対してロック要求すると、結果としてリターン・エラー−無効ＩＶ（Error-Invalid IV）が生じる。
ｄ）アンロック＿コンディションＩＶ（Unlock＿Condition IV）
第３の変数はアンロック＿コンディションＩＶ（Unlock＿Condition IV）であり、このアンロック＿コンディションＩＶによって、ユーザはロックを自動的に解除する条件を指定することが可能になる。アンロック条件は、装置において見つけられたＩＶ’ｓを用いることができる（これはイベント・マネージャ・オブジェクト（Event Manager Object）と同様である。）
アンロッキング＿コンディションＩＶ（Unlocking＿Condition IV）は、装置に対するアンロック条件を定義するブール式（論理式）を含んでいる。そのブール式は、ＣＡＬ文法（グラマ）で定義されたＣＡＬ表現である。このプログラムは、例えばタイマ時間の経過（終了）またはスレッショルドを横切る（cross）ような或る条件が装置内で発生するのを待つ。その装置は、指定されたアンロック条件が生じたときにロックを解除（解決）する。アンロック条件はロックされた装置に存在することに留意されたい。パーシスタンス・レベルはルース（疎）またはタイト（密）の何れであってもよい。
条件はセットアレイ（setArray）方法を用いてアンロック＿コンディション（Unlock＿Condition）にロードされる。この場合、ロードされるデータは、実際のＣＡＬ条件プログラムである。このプログラムはアンロック作用を生じさせる条件を監視する（watch）条件を含んでいる。
まさにイベント・マネージャ・オブジェクトの場合のように、アンロッキング＿コンディションＩＶ（Unlocking＿Condition IV）が正確に動作するためのＣＡＬ文法には、２つの僅かな相違がある。第１の相違は、監視（ウォッチ）すべきインスタンス変数を識別することである。単純なＩＶ識別子（identifier）ではなくて、ＩＶのコンテキストおよびオジェクト位置が与えられなければならない。例えば、（カレント＿バリュー  ＞  マックス＿バリュー（current＿value >max＿value、現在値＞最大値）をテストする代わりに、アンロッキング＿コンディション（Unlocking＿Condition、アンロッキング条件）が（オーディオ・コンテキスト、ボリューム・コントロール、カレント＿バリュー  ＞  オーディオ・コンテキスト、ボリューム・コントロール、マックス＿バリュー（Audio Context_, Volume Control, current＿value＞Audio Context, Volume Control,max＿value）をテストする。全てのバイトを要求することによって、ステートメント（文）は正確に構文解析（パース：parse）することができる。
アンロック＿コンディション（Unlocked＿Condition）に含まれているブール式（ブール表現）は、最大で２つの関係を評価することを可能にする。例えば、クロック・オブジェクト（Clock Object）は、時間が１２に等しく月が６に等しいときにアンロックすることができる。ブール式における第１のＩＶはレポートされた値である。標準の関係（リレーショナル）オペレータ（演算子）と共に、追加のオペレータ、ＤＥＬＴＡオペレータが定義される。アンロック＿コンディションＩＶ（Unlock＿condition IV）が（セットアレイ（setArray）方法を用いて）書き込まれたときには、オブジェクトはＩＶ中に置かれた条件の有効性をチェックしなければならないことに留意されたい。その条件が無効である場合には、エラーバッド（不良）アーギュメント・タイプ（Error-Bad Argument Type）（１２）が返送（リターン）され、アンロック＿コンディション（Unlock＿Condition）は発生しない。
ロッキング実装構成
セットアレイ（setArray）方法を使用して、ロッキング＿アドレスＩＶ（Locking＿Address ＩＶ）に有効宛先アドレスを設定することにより装置がロックされる。ＣＥＢｕｓアプリケーションの場合において、ネットワーク・アドレスは、ＭＳＢ、ＬＳＢの順に現れるユニット・アドレス（Unit address）およびハウス・コード（House Code）で構成される。ユニット・コードUnit Code 0034、ハウス・コードHouse Code 001Aを用いたロッキング・メッセージの例では、次のようなメッセージが得られる。
<context> <object> 46 471 Ff5 Ff5 Ff4 34 Ff6 00 34 00 1A
（<context> <object> setArray‘GA’<DEL> <DEL> <DATA> 34 <ESCAPE> 0034 001A）
〔訳、DEL：削除、ESCAPE：エスケープ〕
オブジェクト・ロッキング＿アドレスＩＶ（Locking＿Address IV）を無効アドレス（例えば、論理長さを０）に設定することによって、それがアンロックされる。
（<context> <object> setArray‘GA’<DEL> <DATA> 30< ESCAPE>）
エラー−無効ＩＶは、この機能が支援（支持）されないときに返送（リターン）される。
１．オブジェクト・ロッキング実装構成（Object Locking Implementation）
オブジェクト・レベルでのロッキングは、個々のオブジェクトにロッキング機構を設定することによって実現される。
２．コンテキスト・ロッキング実装構成（Context Locking Implementation）
オブジェクト・レベル・ロッキングはコンテキストに拡張することができる。コンテキスト・レベルでのロッキングは、コンテキスト・コントロール・オブジェクトにロッキンッグ機構を設定することによって実現される。
ロッキング＿アドレスＩＶ（Locking＿Address IV）に有効値を設定することによってコンテキストがロックされる。コンテキストにおける例示（instantiate、インスタンス化）されたオブジェクトは、同じロッキング＿アドレス（Locking＿Address）を継承する。（これは、パーシスタンス＜＞2のときだけ適用される。）コンテキスト内のオブジェクトが既にロックされている場合には、オブジェクト・ロッキング＿アドレスＩＶ（Locking＿Address IV）値がコンテキスト・ロッキング＿アドレス（Locking＿Address）値と同じでない場合には、コンテキストはロックできない。
ロッキング装置のネットワーク・アドレスを、コンテキスト・コントロール・オブジェクト（Context Control Object）中に置かれたコンテキスト＿ロッキング＿アドレスＩＶ（Context＿Locking＿Address IV）に書込むことによって、コンテキスト・ロックが開始される。
<context＿ID> 01 01 46 47 F5 F5 F4 34 F6 <Locking＿Address>
コンテキスト＿パーシスタンス（Context＿Persistence）、コンテキスト＿キー＿エントリー（Context＿Key＿Entry）、コンテキスト＿ロッキング＿アドレス（Context＿Locking＿Address）、およびコンテキスト＿アンロック＿コンディションＩＶｓ（Contex＿Unlock＿Condition  IVs）は、その振る舞い（behavior）を、オブジェクトＩＶｓパーシスタンス（Object IVs Persistence）、キー＿エントリー（Key＿Entry）、ロッキング・アドレス（Locking＿Address）、およびアンロック＿コンディション（Unlock＿Condition）からそれぞれ継承する。
３．デバイス・ロッキング実装構成
装置レベルにおけるロッキングは、ノード・コントロール・オブジェクト（Node Control Object）に、装置ロッキング機構を設定することによって実現される。このノード・コントロール・オブジェクトは、自己の個別のオブジェクト・ロッキング機構を持つことができる。装置レベル・ロッキング変数は次の通りである。
0004079335.tif 000005
デバイス＿パーシスタンス（Device＿Persistence）、デバイス＿キー＿エントリー（Device＿Key＿Entry）、デバイス＿ロッキング＿アドレス（Device＿Locking＿Address）、およびデバイス＿アンロック＿コンディションＩＶｓ（Device＿Unlock＿Condition IVs）は、その振る舞いを、オブジェクトＩＶｓパーシスタンス（Object＿IVs Persistence）、キー＿エントリー（Key＿Entry）、ロッキング＿アドレス（Locking＿Address）、およびアンロック＿コンディション（Unlock＿Condition）からそれぞれ承継する。
装置ロックは、ロッキング装置のネットワーク・アドレスをデバイス＿ロッキング＿アドレスＩＶ（Device＿Locking＿Address IV）に書込むことによって開始される。
00 01 46 54 F5 F5 F4 34 F6 <Locking＿Address>
ロッキング・シナリオ（Locking Scenarios）
デモンストレーションのために、ロッキング装置は、別の装置をロックすることを希望する装置であるものとする。このロックされる装置はロックしようとする装置である。ロッキング要求は、ロックされるべき装置またはロックを保持するロック・マネージャの何れかに対して行うことができる。通常の条件下において、ロッキング要求は、新しいアドレスをロッキング＿アドレスＩＶ（Locking＿Address IV）に書き込む試みによって行われる。その要求は直接的または条件付きであってもよい。
ａ）直接ロッキング要求
ユニット・コード００３４（Unit Code 0034）、ハウス・コード００１Ａ（House Code 001A）を用いたロッキング・メッセージの一例の結果として、次のメッセージが得られる。
<context> <object> 46 4741 Ff5 Ff5 Ff4 34 Ff6 00 34 00 1A
（<context> <object> setArray‘G’<DEL> <DEL> <DATA>‘4’<ESCAPE> 0034 001A）
装置は、それがロック可能かどうかを決定しなければならない。装置、オブジェクト、コンテキストがロックされていない場合には、完了トークンＦＥが返送（リターン）される。ロッキング装置は、ロッキング・ポインタをロック・マネージャ・オブジェクト中に置く。
ｂ）条件付きオブジェクト・ロッキング要求
ユニット・コード００３４（Unit Code 0034）、ハウス・コード００１Ａ（House Code 001A）を用いたロッキング・メッセージの一例の結果、次のメッセージが得られる。
<context> <object> 56 47 F7 <context> <object> 46 471 F5f5 Ff5 Ff4 34 Ff6 00 34 00 1A EB 44 47 F8
<context> <object> I（IF“G”<BEGIN> <context> <object> setArray‘G’<DEL> <DEL> <DATA>‘4’<ESCAPE> 0034 001A <ELSE> setArray“G”<END>）
〔訳、IF〜：〜の場合は、BEGIN：開始する、ELSE：その他の場合は〕
アレイ“Ｇ”が使用中でない場合には、装置はロックされる。それ以外の場合には、装置がロックされることはない。この方法は資源ロッキングと共に用いられる。装置が使用中の場合には、要求する装置は、同報（broadcast）メッセージを送信することによって装置のロックを断念（放棄）するようロッキング装置に要求“呼びかけ（hail）”することができる。
ｃ）ロック・マクロＵ２（LOCK Macro U2）の使用
ロック・マクロＵ２（LOCK Macro U2）を用いてコンテキストとオブジェクトをロックする。マクロ・メッセージはマクロＩＤを含んでおり、そのマクロＩＤの後にアーギュメント・リストが続く。２つの必須のアーギュメント、（１）ロッキング＿アドレス（Locking＿Address）、および（２）パーシスタンス（persistence）が存在する。アーギュメント・リストは、それが満たされて（詰め込まれて）いない場合には、ナル（０、空）と見なされる。ロックが設定された後、キー＿エントリー（Key＿Entry）およびアンロック＿コンディションＩＶｓ（Unlock＿Condition IVs）が更新される。
<context＿ID> <object＿ID>“U2”<data token> <size of data> <escape token> <locking＿address> F5 <persistence> F5 <Key＿Entry>
例えば、コンテキスト１１をロックするＣＡＬマクロ（CAL Macro）メッセージについて：
“11 011 55U 322 F4 34 F6 0F 32 23 34 F5 01“
アーギュメント0Ff32 2334はロッキング・アドレスであり、パーシスタンスは１に設定される。この時点で、ロッキング装置は、エントリー＿キーＩＶ（Entry＿Key IV）データおよびアンロック＿コンディションＩＶ（Unlock＿Condition IV）データを送信することができる。
ロッキング＿アドレス（Locking＿Address）が与えられないときには、それをマクロ・メッセージのソース・アドレス（出所アドレス）であると仮定する。
“11 01 55 32 F5 F5 01”
ロッキング解除要求
ａ）ロッキング・マスターに対するロッキング解除要求
（１）ディスインヘリット（DISINHERIT、承継排除）（オプション１）の使用
オブジェクト、コンテキストまたは装置のレベルの何れかにおいてオブジェクトがロックされている場合に、そのオブジェクトは、妨げとなるロック装置に対して、そのロックを放棄するように要求する。次の通り、メッセージがロッキング・マネージャ・オブジェクト（Locking Manager Object）に送信される。
<Universal Context> <Locking Manager Object>・disinherit
<lock＿pointer（6C）> F4［number of bytes］F6 <device＿address>
<context＿id> <object>
〔訳、disinherit：承継排除する、number of bytes：バイト数〕
disinherit the lock with <device> <context> <object>
〔訳、disinherit the lock with〜：〜とのロック承継排除する〕
コンテキスト＿ＩＤ（context＿ID）は、それがＡ０でない限り、コンテキスト＿ナンバー（context＿number）を含んでいる。それがＡ０の場合には、コンテキスト・ナンバーはオプションとして（任意選択的に）含めることができる。
（２）アンロック・マクロＵ４１（UNLOCK Macro U41）（オプション２１）の使用アンロック・マクロＵ１４（UNLOCK Macro U14）はイベント・マネージャ・オブジェクト（EVENT Manager Object）に送信される。そのマクロは、所望のロッキング・ポインタをマッチ（match：整合、一致）させて、それを削除するように要求する。マッチが存在する場合には、ロッキング・マネージャは、要求を許可するかまたは要求を拒否する。ロッキング装置を見つけることができない場合には、ロックされた装置はロックを解除する。詳細についてはセクション２．１．２を参照されたい。
リスニング実装構成
リスニング機能はレポート方法のコンパニオン（対の一方、連係関係にあるもの）である。リスニングは、他の装置またはネットワーク資源の状態に関係のある（関心を持つ）オブジェクトにおいて実行される。ネットワーク資源の例は時間である。
リスニング機能によって、装置は状態情報を含んだ各同報メッセージ間の区別ができるようになる。リスニング機能は、ロッキング機能の特別なアプリケーションである。リスニング・モードにおいて、オブジェクトは、コンテキストまたは装置のロッキング状態を承継しない。（これは、装置またはコンテキストがロックされたときに、リスニング機能が正しく実行されるのに必要である。）
リスニングにおいて、装置は自己を別の装置に結合（バインド）する。これは、装置が自己のロッキング＿アドレスＩＶ（locking＿Address IV）を設定することができることを意味する。ロッキング＿アドレスＩＶ（locking＿Address IV）は、読出しのみ（リードオンリー）形または読出し／書込み（リード／ライト）形の何れかである。書込みオプション（任意選択）は、実際には、ルース・ロッキングのタイプである。パーシスタンスＩＶは“２”に設定される。キー＿エントリーＩＶ（Key＿Entry IV）は、特別なアクセス・ディスクリミネータとして作用する。次のテーブルはリスニングＩＶリストを含んでいる。
0004079335.tif 000006
ロッキング＿アドレス（Locking＿Address）が読出しのみ（リードオンリ）変数であるときには、装置は自己のロッキング・アドレスを設定する。ロッキング＿アドレス（Locking＿Address）が外部から設定されるときには、ロッキング装置は、そのロッキング・マネージャ（Locking＿Manager）にロック＿ポインタ（lock＿pointer）を置かない。
リスニングには３つの相異なる実装構成が存在する。第１の方法では、ソース・ネットワーク・アドレスを用いて、リスニング・オブジェクトに対するアクセスをゲート処理する。そのオブジェクトは、ロッキング＿アドレスＩＶ（Locking＿Address IV）に対応するソース装置アドレスに有利な形で区別を行う（を優先させる）。この場合、メッセージは適切なインスタント・バリアブル（Instant Variable、瞬間変数）に書込まれる。
第２と第３のリスニング実装構成では、キー＿エントリー装置が使用される。この実装構成では、マクロ・メッセージが必要である。マクロ・メッセージ、Ｌ１を使用して、キー＿エントリー（Key＿Entry）値およびデータが同時に与えられる。リスニング装置は、マクロが正しいソース・アドレスからのものであること、および与えられたキー＿エントリー（Key＿Entry）値が所望の値とマッチすることを検証（ベリファイ）する。
１．複数ソース・リスニング実装構成
リスニング・オブジェクトが、区別（差別）することなく、全ての同報ソース（源）に対してリスニング（聴取）することを希望することもある。そのような１つの状況は、火災を検出していることを火災センサが同報するときに発生する。火災センサは、その情報をネットワーク上で同報する。リスニング装置は、火災を報告する可能性のある全ての資源をリスニングすることを希望する。
一般的に、複数ソース・リスニング・アプリケーションは、装置が任意の装置（センサ）の状態を受信できるようにすることによって実行される。これは、ロッキング＿アドレスＩＶ（Locking＿Address IV）に同報アドレスを設定することによって規定される。ＣＥＢｕｓアプリケーションにおいては、リスニング・ディスクリミネータが、特別ハウス・コード（House Code）内の全てのユニット＿アドレス（Unit＿Address）またはネットワーク上の全てのアドレスの何れかに設定される。メッセージに含まれているアラーム・オーサ・ソース（alarm author source、警報発生源）またはゾーン・アドレス（zone address）は、メッセージ中に含まれており、そのメッセージに含まれているソース＿アドレス（source＿address）フィールドまたは状態ベクトルから抽出することができる。
２．キー＿エントリー（Key＿Entry）およびロッキング＿アドレス（Locking＿Address）を介したリスニング
このようにして、ロック＿キー（lock＿key）値は、装置が個々のコンテキストおよびオブジェクトの間の区別を行うことを可能にするセレクタ値（選択値）となる。例えば、タイム・コンテキストにおいて、タイム・タイプ識別子（time type identifier、時間タイプ識別子）をマクロ・メッセージにおいて与えることができる。この値は所望の時間タイプについてチェックされる。装置がレポーティング・コンテキストの複数のインスタンス（例示）を有する場合には、装置はキー＿エントリー（Key＿Entry）フィールド中にコンテキスト番号を含むことができる。受信ノードは入来（incoming）コンテキスト番号をチェックして、関係するものの１つであることを検証する。
<context＿ID> <object＿ID> 53 31 F4 <size of data> <escape token> 5
<Locking＿Address> F5 <data token> <size of data> <escape token>
<Key＿Entry> F5 <Argument Listmessage>
リスニングにおいて、装置は自己を別の装置に結合する。リスニングの場合、装置は自己のロッキング＿アドレスＩＶ（Locking＿Address IV）を設定することができる。ロッキング＿アドレスＩＶ（Locking＿Address IV）は読出しのみ（リードオンリ）形または書込み／読出し形の何れかである。
３．キー＿エントリー（Key＿Entry）を介したリスニング
また、リスニングはロッキング＿アドレス（Locking＿Address）を“00 00 00 00”に設定することによって実行される。この場合は、ディスクリミネータだけがキー＿エントリー（Key＿Entry）値である。これによって、オブジェクトはアクセス・キーに基づいて区別を行うことが可能となる。これは次のように行われる。
<context＿ID> <object＿ID> 53 31 F5 00 00 00 00 F5 <data token> <size of data> <escape token> <Key＿Entry> F5 <Argument＿List>
ロッキング＿アドレス（Locking＿Address）が読出しのみ（リードオンリ）形であるときには、装置は排他的に自己のロッキング・アドレスを設定する。ロッキング＿アドレスＩＶ（Locking＿Address IV）がＲ／Ｗのときには、ロッキングはルース（疎）である。ロッキング装置はロッキング＿ポインタ（locking＿pointer）をロッキング・マネージャ（Locking Manager）中に設定しない。
<context＿ID> <object＿ID> L1 <data token> <size of data> <escape token> <Locking＿Address> F5 F5 <message>
固有の識別子が、１つの装置において、複数のコンテキストまたはオブジェクトの間の区別を可能にすることが望ましいような幾つかのインスタンス（事例）がある。その１つの例は、複数のセンサを含んだ温度センサ装置である。各センサを対応するリスニング・オブジェクトに結合することが望ましいことがある。これは、キー＿エントリー＝ナル（０）（key＿entry = null）である場合には区別が存在しなくなるようなキー＿エントリー（key＿entry）法を用いて実行される。キー＿エントリー（key＿entry）が或る値に設定されるときには、リスニング装置が、オブジェクトを更新する前に、適正なキー＿エントリー（key＿entry）値を要求する。
例：  リスニング変数は、ユーザがディスクリミネータ（discriminator）を設定するのを可能とするキー＿エントリー＿ナンバー（key＿entry＿number）のようなディスクリミネータを有する。データおよびディスクリミネータはマクロ＿ＩＤ（Macro＿ID）キー＿エントリーＦ５リスニング・データ（key＿entry F5 Listening DATA）で送信される。キー＿エントリー（key＿entry）が与えられない場合には、ディスクリミネータはネットワーク・アドレスである。
本発明を多数の実施形態に基づいて詳細に説明したが、以上の記載を読んで理解すれば、この分野の専門家が上述の実施形態に対する多数の代替構成例を思いつき、そのような代替構成例が本発明の請求の範囲内に含まれることは明らかである。
【図１Ａ】
0004079335.tif 000007
【図１Ｂ】
0004079335.tif 000008
【図２】
0004079335.tif 000009
【図３】
0004079335.tif 000010
【図４】
0004079335.tif 000011
【図５】
0004079335.tif 000012
【図６】
0004079335.tif 000013
【図７】
0004079335.tif 000014