JP3613545B2 - 通信装置 - Google Patents
通信装置 Download PDFInfo
- Publication number
- JP3613545B2 JP3613545B2 JP37337598A JP37337598A JP3613545B2 JP 3613545 B2 JP3613545 B2 JP 3613545B2 JP 37337598 A JP37337598 A JP 37337598A JP 37337598 A JP37337598 A JP 37337598A JP 3613545 B2 JP3613545 B2 JP 3613545B2
- Authority
- JP
- Japan
- Prior art keywords
- control right
- vtr
- control
- identification information
- processing means
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４バス等のネットワークを介して通信を行う通信装置に関する。
【０００２】
【従来の技術】
近年、デジタル放送の開始や、デジタルＡＶ機器の発売等、いわゆる「家庭ＡＶ環境のデジタル化」が大きな注目を集めている。デジタルＡＶデータは、様々な圧縮が可能、マルチメディアデータとしての処理が可能、何回再生しても劣化が無い、等の優れた特徴を持ち、今後その用途はますます広がっていくものと考えられる。
【０００３】
家庭ＡＶ環境のデジタル化が一般化すると、必然的に「家庭ＡＶ環境のネットワーク化」が進展する。近年流行しているインターネット等と融合させることにより、コンピュータ同士をネットワーク接続し、互いにデジタルデータのやり取りを行なうことで、公衆網からのビデオオンデマンドや、部屋間／家庭間のＡＶデータの交換等、デジタルＡＶ機器の可能性は格段に拡大することが
見込まれる。
【０００４】
ＡＶ機器のネットワーク化は、現在のコンピュータネットワークにおける「サーバ」のように、家庭内のデジタルサービスを行なう、いわゆる「ホームサーバ」の登場を誘発する。この「ホームサーバ」は、ホームネットワークに接続された複数の装置からのサービス要求に応えるもので、例えば家庭内のビデオオンデマンドサーバとなることが出来よう。
【０００５】
【発明が解決しようとする課題】
ところで、家庭向けの民生機器（ＡＶ機器、パーソナルコンピュータ、白物家電等の種々の装置を含む）は、徹底的な低コストが求められる点や、既存機器のコンポーネントの流用が多く行われるであろうことから、ホームネットワークに接続可能な機器でも、当初から「複数ユーザからの同時アクセス」が可能になるとは、必ずしも限らない。例えば、ＡＶテープを駆動する形の、いわゆる一般的なＶＴＲは、同時に利用できるユーザの数は１（録画とチューナの同時利用の場合でも当該ＶＴＲについて高々２）である。また、家庭用を考えた場合、今後も、１つの装置もしくはその装置により提供されるサービスに同時アクセス可能なユーザ数はそれほど多くはなっていかないと考えられる。
【０００６】
このような民生機器を接続したホームネットワークにおいても、同一の装置等に対して同時に複数のユーザからアクセスされることを念頭に置かねばならないため、これらのユーザの排他制御を考慮する必要がある。むしろ、民生機器では同時アクセス可能なユーザ数が少ないので、家庭内で良く利用される機器は、常に排他制御発動の可能性を帯びることになる。
【０００７】
ところが、いわゆる「家庭ユーザ」についてはコンピュータやネットワークの仕組みに対する知識が充分であると仮定することはできないため、従来のように排他制御をした際に単に「アクセス失敗」の事実だけ伝えるのではサポートが不十分であるという問題が生ずる。例えば、ＶＴＲへのアクセスを要望した家庭ユーザに対して、単純に「ＶＴＲへのアクセスが失敗しました」もしくは「排他制御のためＶＴＲへのアクセスが失敗しました」と表示したのでは、この家庭ユーザは、このメッセージ自体に対してどのように対処したらよいのかわからず困惑したり、どうしてもその時間にＶＴＲを利用する必要があるときにどのようなアクションを取れば利用できるのか（もしくはその可能性が得られるのか）わからずにその時間を徒過してしまうなど、色々な好ましくない事態が想定される。また、このようなことにより、結果的に家庭ユーザにとって操作性の良くないホームネットワークになってしまったり、ユーザフレンドリーでないと評価されてしまうなどの虞がある。
【０００８】
本発明は、上記事情を考慮してなされたもので、より有効なユーザ・サポートを考慮した排他制御の可能な通信装置を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明（請求項１）は、ネットワークに接続された通信装置（被制御側となる機器）であって、前記ネットワークを通して自通信装置を制御する制御権を保有する他の装置（制御側となる機器）の識別情報を記憶する記憶手段と、前記記憶手段に前記識別情報が記憶されていないさらに他の装置（制御側となる機器）から、自通信装置に対して制御権の取得を要求するメッセージを受信した際（例えば、同時利用カウンタデクリメント要求を受信した際、あるいは制御パネル要求を受信した際）に、前記記憶手段に記憶されている前記識別情報の数が所定の数に達しているかを否か判定する判定手段と、この判定手段により前所定の数に達していないと判定された場合に、前記さらに他の装置の識別情報を前記記憶手段に追加するとともに、該さらに他の装置に制御権取得成功を通知するメッセージを送信する第１の処理手段と、前記判定手段により前記所定の数に達していると判定された場合に、前記記憶手段に識別情報が記憶されている装置（すなわち、制御権を保有する装置）のうちに、その制御権を前記さらに他の装置に譲り渡すことのできるものが存在するか否かを調べる第２の処理手段と、前記第２の処理手段によりその制御権を前記さらに他の装置に譲り渡すことのできる装置が見つかった場合に、該制御権を譲り渡す装置の識別情報を前記記憶手段から削除し前記さらに他の装置の識別情報を前記記憶手段に追加するとともに、該さらに他の装置に制御権取得成功を通知するメッセージを送信する第３の処理手段とを備えたことを特徴とする。
【００１０】
前記所定の数は、例えば、被制御装置の所有権を同時に保有可能な制御装置の数で、各被制御装置毎に（その装置の性能もしくは仕様等で）定まる数である。例えば、被制御装置がＶＴＲで同時に１つのストリームデータしか提供できない場合には所定の数は１となり、同時に３つのストリームデータを提供できる場合には所定の数は３となる。なお、ある被制御装置について同時にｎ台の制御装置が制御権を保有できる場合であっても、所定の数をｎより小さい数に設定しても構わない。
【００１１】
好ましくは、前記第２の処理手段は、自通信装置が現にデータをやり取りしている相手装置については、その制御権が維持されるべきもの（譲り渡すことはできない）と判断するようにしてもよい。
【００１２】
好ましくは、前記第２の処理手段は、自通信装置が最後にデータをやり取りしてから経過した時間が一定範囲以内である相手装置についても、その制御権が維持されるべきもの（譲り渡すことはできない）と判断するようにしてもよい。
【００１３】
好ましくは、前記第２の処理手段は、前記記憶手段に識別情報が記憶されている装置の少なくとも一部に対して、その制御権を維持するか否かを問い合わせるメッセージ（使用確認要求）を送信し、その返答により該制御権が維持されるべきもの（譲り渡すことはできない）か否かを判断する手段を含むようにしてもよい。
【００１４】
好ましくは、前記第２の処理手段は、前記メッセージを送信する対象とし得る装置が複数存在する場合に、所定の選択基準で選択した順番で、前記メッセージの送信およびその返答による前記判断を行うようにしてもよい。
【００１５】
好ましくは、自通信装置に対する制御権を保有する他の装置から該制御権を維持し続ける旨の特別のメッセージを受信した場合に、該他の装置の識別情報を登録する登録手段を更に備え、前記第２の処理手段は、前記登録手段に識別情報が登録されている装置については、その制御権が維持されるべきもの（譲り渡すことはできない）と判断するようにしてもよい。
【００１６】
好ましくは、前記第２の処理手段によりその制御権を前記さらに他の装置に譲り渡すことのできる装置が見つからなかった場合に、前記さらに他の装置に制御権取得失敗を通知するメッセージを送信する第４の処理手段を更に備えるようにしてもよい。
【００１７】
好ましくは、前記第４の処理手段は、前記さらに他の装置に制御権を保有する他の装置（すなわち、前記記憶手段に識別情報が記憶されている装置）の識別情報を前記メッセージに含めて送信するようにしてもよい。
【００１８】
好ましくは、自通信装置が複数の異なる装置またはサービスの形でネットワークに公開される場合には、公開された各装置またはサービス毎に、その制御権を保有する他の装置の識別情報を管理するようにしてもよい。
【００１９】
好ましくは、前記異なる装置またはサービスのうちの特定の２以上のものについて制御権保有可能な装置の数がそれらの総和として限定される場合には、該特定の２以上の装置またはサービスについては前記制御権を保有する他の装置の識別情報を統一して管理するようにしてもよい。
例えば、ある被制御装置において、機能ａについて同時にｘ台の制御装置が制御権を保有でき、機能ｂについても同時にｘ台の制御装置が制御権を保有できるが、機能ａについて同時にｙ台の制御装置が制御権を保有している場合には機能ｂについては同時にｘ−ｙ台の制御装置しか制御権を保有できない（同様に、機能ｂについて同時にｙ台の制御装置が制御権を保有している場合には機能ａについては同時にｘ−ｙ台の制御装置しか制御権を保有できない）ような場合には、機能ａについて制御権を保有している制御装置と機能ｂについて
制御権を保有している制御装置とを統一して管理するのが好ましい。
【００２０】
本発明（請求項１１）は、ネットワークに接続された通信装置（制御側となる機器）であって、前記ネットワークを通して他の装置を制御するためのコマンドを送信する手段と、前記他の装置から、さらに他の装置が該他の装置を制御しているために現在は制御を受け付けられない旨を示す情報と該さらに他の装置の識別情報とを含むメッセージを受信した場合に、該さらに他の装置に関する詳細情報を検索する手段と、前記詳細情報に基づいて作成した、ユーザを支援するための情報を、ユーザインタフェースを通じて呈示する手段とを備えたことを特徴とする。
【００２１】
好ましくは、前記詳細情報は、前記さらに他の装置の種類に関する情報または該装置が設置された物理的位置に関する情報の少なくとも一方を含むものであり、前記ユーザを支援するための情報は、前記さらに他の装置の種類または該装置が設置された物理的位置の少なくとも一方をユーザに通知する文言あるいは図面を含むものであるようにしてもよい。
【００２２】
本発明によれば、要求された装置（またはサービス）に対するの現在の制御権保有装置数が所定の数に達している場合でも、その時点でその要求を拒絶するのではなく、その制御権を譲り渡してくれる装置があるかどうかを探し、制御権を譲り渡してくれる装置があれば、制御権を取得することができる。
【００２３】
また、制御権が得られなかったときでも、単に制御権が得られなかった旨を呈示するだけではなく、その装置（またはサービス）に対するの現在の制御権保有装置に関する詳細な情報を含むメッセージを呈示するようにすれば、ユーザは次のアクションを取りやすくなる。
【００２４】
このように本発明によれば、より有効なユーザ・サポートを考慮した排他制御を行うことができる。
【００２５】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００２６】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２７】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２８】
図１は、ある家庭のホームネットワークの全体構成を一例として示した図である。
【００２９】
図１に例示したホームネットワークは、ＩＥＥＥ１３９４バス１００を用いて構成され、ＶＴＲ１０１、テレビ１０２、ＰＣ１０３の３つの装置が接続されているものである。ＶＴＲ１０１のノードＩＤは＃ｘ、テレビ１０２のノードＩＤは＃ｙ、ＰＣ１０３のノードＩＤは＃ｚとする。
【００３０】
本実施形態では、テレビ１０２とＰＣ１０３には、それぞれ、いわゆるディスプレイ（表示デバイス）が附属しており、それら装置（１０２，１０３）のユーザは、その付属のディスプレイを通して（例えば、ＴＶリモコン１０４やＰＣリモコン１０５およびその付属ディスプレイあるいはマウス等の入力デバイスを使って）、ＶＴＲ１０１の制御画面を操作することができるような場合を想定して説明する。また、ＶＴＲ１０１を被制御装置の一例として、テレビ１０２を制御装置（本例ではＶＴＲを制御する）の一例として、ＰＣ１０３を制御装置（本例ではテレビがＶＴＲを制御中に同じＶＴＲを制御しようとする）の一例として説明する。
【００３１】
図２に、本例でアクセスされる対象となるＶＴＲ１０１の内部構成例を示す。
【００３２】
このＶＴＲ１０１は、いわゆるデジタルＶＴＲであり、デジタル形式（例えばＭＰＥＧ２）でＡＶデータの保存、再生等を行なう。
【００３３】
ＶＴＲ処理部２０２は、テープ、および機構部分であり、録画、再生、テープの巻き戻し、早送り等の動作を行い、ＩＥＥＥ１３９４インタフェース２０１とデジタルＡＶストリームデータのやり取りを行う。
【００３４】
ＡＶ／Ｃコマンド処理部２０３は、標準化団体であるＩＥＥＥ１３９４トレードアソシエーション（１３９４ＴＡ）が決定するＡＶ機器の制御コマンド体系の処理を行なう。基本的に、ＡＶ／ＣコマンドはＩＥＥＥ１３９４バスを介してやり取りされる。なお、ＡＶ／Ｃについては、例えば、ＡＶ／Ｃ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ Ｃｏｍｍａｎｄ Ｓｅｔ Ｇｅｎｅｒａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＩＥＥＥ１３９４−１９９５等に記載されている。
【００３５】
属性情報レジスタ２０４は、ＩＥＥＥ１３９４インタフェース２０１を介して、ＩＥＥＥ１３９４バスに接続された他の装置からも、特定のアドレスを指定することの出来るメモリ領域である。具体的には、図３に例示したように、このレジスタを持つ装置についての種々の属性情報、例えば、ベンダ名、装置名（例えば、ＶＴＲ）、製造番号や型番、この装置を制御するための制御画面の構成情報（制御パネル）、この装置の現在位置を記す現在位置情報、後述する制御で使われる同時利用可能カウンタと利用者リスト等がある。なお、これらの情報は、必ずしも図３のような順序で格納されている必要はなく、例えばお互いに離れた空間に格納されていても良い。
【００３６】
ＩＥＥＥ１３９４バスにつながる他の装置は、その装置の「どのアドレス」にアクセスすれば上記したような各々の属性情報を得ることができるかについて、あらかじめ知っている（知らされている）ものとする。また、このレジスタの特定の領域（例えば、ベンダ名、装置名、製造番号や型番、制御パネル、現在位置情報）については、その装置の製造時あるいはＩＥＥＥ１３９４バス等のネットワークに接続される以前からあらかじめ登録されているとしてもよい。
【００３７】
次に、ＴＶ１０２のユーザがそのＴＶの画面を通してＶＴＲ１０１の遠隔制御を行なう場合を例にとって構成や処理の流れについて説明する。
【００３８】
図４に、この場合の処理シーケンスの一例を示す。
【００３９】
まず初期段階において、ＴＶ１０２は、ＶＴＲ１０１に対して（ＴＶは、この時点では、当該相手のことを「ノードＩＤ＝＃ｘの装置である」としか認識しておらず、ＶＴＲであるということを認識していない）、構成情報要求（Ｓ４０１）を送出する。実際には、上記の属性情報レジスタの特定のアドレスを読みに行く動作を行なうのでもよい。
【００４０】
ＶＴＲ１０１では、構成情報要求を属性情報レジスタ２０４が受信し、属性情報レジスタ２０４が構成情報要求に対する応答を行なう（Ｓ４０２）。この時点で、ＴＶ１０２は、この装置１０１がＶＴＲであることなどを認識することができ、ユーザに対して属性を認識した上での表示を行うことができる。
【００４１】
なお、ＩＥＥＥ１３９４バス１００に複数の装置が接続されている場合には、上記処理を各装置について行うと好ましい。
【００４２】
さて、例えばＴＶ１０２において当該ＴＶ１０２からアクセスあるいは制御等のできる装置もしくはサービスのアイコンなどが表示された状態等において、ＴＶ１０２のユーザが制御対象の装置としてＶＴＲを選択したとする（Ｓ４０３）。
【００４３】
すると、ＴＶ１０２のディスプレイにＶＴＲの制御画面を表示させるべく、制御パネル要求（Ｓ４０４）をＶＴＲ１０１に送出する。この要求はＡＶ／Ｃプロトコルの一部であってもよい。
【００４４】
ＶＴＲ１０１では、制御パネル要求をＡＶ／Ｃコマンド処理部２０３が受信し、制御パネル応答（Ｓ４０５）で制御パネルをＴＶ１０２に送付する。
【００４５】
制御パネルは、例えば図５に例示したようなものである。例えば、ユーザが制御画面上で再生ボタン（５０１）を押すと、「再生ボタンが押されました（ＡＶ／Ｃの再生コマンド）」、あるいは「ボタン２が押されました（ＶＴＲ１０１は、ボタン２が「再生」に相当する、ということを認識している）」といったコマンド（図４のＳ４１０に相当）が、ＩＥＥＥ１３９４バス１００を経由してＶＴＲ１０１に伝えられる。
【００４６】
さて、制御パネル応答を受信したＴＶ１０２は、図５のような制御画面をディスプレイに表示する。ユーザは、リモコンやマウス等を用いて、制御パネルの操作を行なう。ここでは、一例として、再生ボタンが押されたものとする（Ｓ４０６）。
【００４７】
すると、ＴＶ１０２は、まず、ＶＴＲ１０１の制御権を確保しようとする。
【００４８】
ここで、「制御権」とは、その装置の制御を行なうことの出来る権利である。後述のメカニズムにより、制御権の有無の判断が行われる。制御権の確保を司るのが属性情報レジスタ２０４中の同時利用可能カウンタと、利用者リストである。「同時利用可能カウンタ」は、その時点でその装置を同時に利用することの出来るユーザ数を示すカウンタである。この装置（本例ではＶＴＲ１０１）を利用しようとするＩＥＥＥ１３９４バス１００上の他の装置（本例ではＴＶ１０２）は、当該装置（ＶＴＲ１０１）の同時利用可能カウンタをデクリメントした上で、利用者リストに当該他の装置（ＴＶ１０２）のＩＤ（例えばノードＩＤやＥＵＩ６４など）を登録する。なお、ＥＵＩ６４とは、６４ビットのハードウエアアドレスのことである。
【００４９】
ＴＶ１０２は、同時利用カウンタデクリメント要求（Ｓ４０７）をＶＴＲ１０１に送出する。この要求には、何等かの形（例えばパケットの送信元アドレス）で送信元装置（ＴＶ１０２）のノードＩＤ（またはＥＵＩ６４）が含まれている。
【００５０】
これを受信したＶＴＲ１０１は、同時利用カウンタの値が１以上である場合には、このカウンタの値をデクリメントし、さらに同時利用カウンタデクリメント要求の送信元装置（ＴＶ１０２）のアドレス（ノードＩＤ＝＃ｙ）を利用者リストに登録し（Ｓ４０８）、同時利用カウンタデクリメント要求がうまく行ったことを返答する（Ｓ４０９）。
【００５１】
この時点で、ＴＶ１０２はＶＴＲ１０１の制御権を確保したことになり、操作コマンド（本例では再生コマンド）をＶＴＲ１０１に対して送付する（Ｓ４１０）。
【００５２】
再生コマンドを受信したＶＴＲ１０１は、これに応じて再生動作を行い（Ｓ４１１）、ＩＥＥＥ１３９４バス１００を経由してＡＶストリームをＴＶ１０２に送付する（Ｓ４１２）。
【００５３】
また、図４とは別の手順で制御権の確保を行なう方法もある。図６に、そのような処理シーケンスの他の例を示す。図４では、ユーザが装置（ＶＴＲ）を選択した際に、制御パネル（取得・表示・コマンド入力）→同時利用カウンタデクリメントの順で制御を行なってきたが、図６では同時利用カウンタデクリメント→制御パネルの順で制御を行なう。すなわち、制御権の確保を先に行ない（Ｓ６０４〜Ｓ６０６）、制御権が確保できた場合にのみ、制御パネルを送付する（Ｓ６０７〜Ｓ６０８）。本実施形態では、図４の方式を中心として説明するものとしているが、もちろん、いずれの場合においても、図６の方式も可能である。
【００５４】
次に、固定利用について説明する。
【００５５】
例えば、ＶＴＲ１０１の同時利用者数すなわち同時に制御権を持つことのできるものの数は１であり、現在ＴＶ１０２がその制御権を持っているものとする（この時点ではＶＴＲ１０１の同時利用カウンタは０である）。このとき、ＴＶ１０２のユーザは、自分が持っている制御権を他の装置に対しては与えたくない（制御権を維持し続けたい）と考えたとする。そのような場合に、例えば、図５のように制御パネルに「利用装置固定」のボタン（５０２）を設け、ＴＶ１０２のユーザがこのボタンを押すことにより、制御権が奪われないようにすることができる。
【００５６】
図７に、この場合の処理手順の一例を示す。
【００５７】
この「利用装置固定」ボタンが押された場合には（Ｓ７０１）、ＴＶ１０２内にある「固定利用レジスタ」に使用中の装置（ＶＴＲ１０１）が記録され（Ｓ７０２）、後述するように「その装置は自分が使用中である」と主張することが出来るようになる（制御権を保護されるようになる）。
【００５８】
また、「利用装置固定解除」ボタンを押すなり、ユーザがその装置の利用を終了するなりすると（Ｓ７０３，Ｓ７０４）、固定利用レジスタからその装置（ＶＴＲ１０１）の登録を削除する（Ｓ７０５）。
【００５９】
なお、ＩＥＥＥ１３９４バス１００を経由せず、ＶＴＲ１０１の装置そのものについているボタン等で制御を行なうことは、本実施形態における制御権とは関係なく可能であってもよい。あるいは、ＶＴＲ１０１の装置そのものについているボタン等で制御を行なう場合にも本実施形態における制御権を登録し、当該制御権を絶対的なもの（常に制御権を維持することができ、かつ、常に制御権を奪い取ることができる）とするようにしてもよい。
【００６０】
次に、ＩＥＥＥ１３９４バス１００上の第３の装置（本例ではＰＣ１０３）のユーザが、現在ＴＶ１０２が使っているＶＴＲ１０１の制御権を獲得しようとする場合について説明する。
【００６１】
図８に、この場合の処理シーケンスの一例を示す。
【００６２】
まず、前述のように、ＴＶ１０２のユーザが、「利用装置固定」のボタンを押し、ＴＶ１０２内の固定利用レジスタにＶＴＲ１０１が登録されている（Ｓ８０１〜Ｓ８０３）。
【００６３】
ここで、ＰＣ１０３のユーザがＶＴＲ１０１の制御を行なおうとして、同時利用カウンタデクリメント要求を出す（Ｓ８０４）。
【００６４】
これを受信したＶＴＲ１０１は、その許可の可否を判定する。判定中はＰＣ１０３に対して「待て」の信号を送っておいてもよい（Ｓ８０５）。
【００６５】
まず、ＶＴＲ１０１は、自身の同時利用カウンタの値が０になっていることを確認し、誰かがＶＴＲ１０１の使用権を放棄しない限り、同時利用は出来ないことを認識する。そこで、利用者リストを参照し、そこに登録されているＴＶ１０２に対して、「現在、ＶＴＲ１０１を使用しているかどうかの確認」のための信号（使用確認要求）を送付する（Ｓ８０６）。
【００６６】
図９に、使用確認要求を受けた際のＴＶ１０２の手順の一例を示す。
【００６７】
使用確認要求を受信したＴＶ１０２は（Ｓ９０１）、固定利用レジスタを参照するなどして（Ｓ９０２，Ｓ９０４，Ｓ９０５，Ｓ９０７，Ｓ９０８）、自身がＶＴＲ１０１を使用中であると認識した場合には、「使用中」を意味する応答を返す（Ｓ８０７）（Ｓ９０６）。そうでなければ、「終了」を意味する応答を返す（Ｓ９０３，Ｓ９０９／Ｓ９１０）。
【００６８】
「使用中」を意味する応答を返す場合としては、例えば、以下のような場合が考えられる（図９参照）。
（１）固定利用レジスタにその装置（ＶＴＲ１０１）が登録されている場合（あらかじめユーザが制御権を手放したくないと宣言している場合）
（２）その装置（ＶＴＲ１０１）とＡＶストリームをやりとりしている場合、あるいはやり取りをして一定時間以下しか経っていない場合
（３）その装置（ＶＴＲ１０１）と制御コマンドのやり取りをしている場合、あるいはやり取りをして一定時間以下しか経っていない場合
（４）ユーザインタフェースを通して、ユーザに「現在その装置（ＶＴＲ１０１）を使用中ですか？」と質問を出し、ユーザから使用中であるとのインタラクションを受けた場合
ＴＶ１０２から「使用中」である旨の使用確認応答を受信したＶＴＲ１０１は、要求元（ＰＣ１０３）が自装置を同時利用することは不可能であると認識し、その旨をＰＣ１０３に通知する（Ｓ８０８）。
【００６９】
なお、上記では、ＶＴＲ１０１はＴＶ１０２に依頼して使用確認を行ったが、現在ＶＴＲ１０１が使用可能であるかどうかの判断を少なくとも一部分についてＶＴＲ１０１自身が行なっうようにしてもよい。
【００７０】
図１０に、この場合のＶＴＲ１０１における処理手順の一例を示す。
【００７１】
制御パネルの送付や利用者リストの登録があった後に（Ｓ１００１，Ｓ１００２）、同時利用カウンタデクリメント要求を受信した際（Ｓ１００３）、カウンタの値が０である場合には（Ｓ１００４）、登録されている装置（ＴＶ１０２）とＡＶストリームあるいは制御コマンドをやり取りしており、もしくは一定時間以下しか経っていないならば（Ｓ１００７）、使用中であるので（Ｓ１００８）、要求元（ＰＣ１０３）に「デクリメントＮＧ」を送付する（Ｓ１００９）。そうでないならば、登録されている装置（ＴＶ１０２）に対してしよう確認要求を出し（Ｓ１０１０）、応答に応じた処理を行う。例えば、使用中の応答を受信したならば（Ｓ１０１１）、現在の利用者が使用中であるので（Ｓ１００８）、デクリメントＮＧを送付する（Ｓ１００９）。終了の応答を受信したならば（Ｓ１０１２）、この利用者を利用者リスト（ＴＶ１０２）から削除し、要求元の利用者（ＰＣ１０３）を追加し（Ｓ１０１３）、デクリメントＯＫを送付する（Ｓ１０１４）。もちろん、同時利用カウンタデクリメント要求を受信した際（Ｓ１００３）、カウンタの値が０でない場合には（Ｓ１００４）、同時利用可能カウンタをデクリメントし、要求元の利用者を利用者リストに追加し（Ｓ１００５）、デクリメントＯＫを送付する（Ｓ１００６）。
【００７２】
これらを組み合わせることにより、例えば図１１のように、ＶＴＲ１０１の現在の制御権はＴＶ１０２が持っている場合に、使用確認要求をＴＶ１０２に送付し（Ｓ１１０４）、ユーザからのインタラクションがあったときには（Ｓ１１０４）、「使用中」の旨を返答し（Ｓ１１０５）、ＰＣ１０３には制御権を渡さないようにできる。また、例えば図１２のように、ユーザからのインタラクションがなかったときには（Ｓ１２０５）、「使用終了」の旨を返答し、ＰＣ１０３に制御権を渡す（利用者リストから＃ｙを削除し、＃ｚを登録し直す）ことも可能となる。
【００７３】
このようにして、ＶＴＲ１０１は使用権の排他制御を行なうことが出来る。
【００７４】
なお、上記では、固定利用レジスタについては、制御側の装置（ＴＶ）内に被制御側の装置（ＶＴＲ）を登録したが、制御側の装置（ＴＶ）から被制御側の装置（ＶＴＲ）に特別のメッセージで通知して被制御側の装置（ＶＴＲ）内にそれを使用中の装置（ＴＶ）を登録するようにしてもよい。この場合、固定利用レジスタについての使用確認は、要求を受信した装置（ＶＴＲ）内で行うことができる。
【００７５】
さて、図１１では、ＰＣ１０３が、ＶＴＲ１０１の制御権を獲得できなかった場合、ＰＣ１０３のユーザは、単純に「同時利用カウンタのデクリメントに失敗した」、「ＶＴＲ１０１の制御権確保に失敗した」という通知しか受けない。これは、ＰＣ１０３のユーザから見ると「ここからＶＴＲの制御は今出来ない」ということを通知してもらうだけで、「では、どうすれば制御が出来るのか（そうすればＶＴＲを使うことが出来るのか）」の情報を得ることが出来ない。そこで、よりきめ細かくユーザをサポートするために、図１３のような仕組みを設けるようにしてもよい。
【００７６】
すなわち、ＶＴＲ１０１がＰＣ１０３に「同時利用カウンタのデクリメントはできない」、「ＶＴＲ１０１の制御権確保に失敗した」という通知を送る際に、利用者リストを参照して、現在自分自身（ＶＴＲ１０１）の制御権を持っている装置（本例ではＴＶ１０２）のＩＤ（本例ではノードＩＤ）を併せて通知する（Ｓ１３０７）。すると、理論的には、ＰＣ１０３（のユーザ）は少なくともＴＶ１０２がＶＴＲ１０１を制御している点、また、ＴＶ１０２を使えばＶＴＲ１０１を使うことが出来る、と言うことを認識することが出来るようになる。
【００７７】
ただし、ユーザからすると、実際にはＴＶ１０２のノードＩＤを通知してもらっただけで、このノードＩＤを持った装置が一体何なのか、またどこにある装置なのかについて認識することは、ノードＩＤとその説明を記述した一覧表でも用意しない限り困難である（また、一覧表の作成とその使用も煩雑である）。
【００７８】
そこで、ＴＶ１０２のノードＩＤ（＃ｙ）を通知してもらったＰＣ１０３は、このノードＩＤを手がかりに、そのノードＩＤ（＃ｙ）を持つノード（ＴＶ１０２）に対して、構成情報要求を送出するようにする（Ｓ１３０８）。特に、この構成情報要求にて、「その装置の種別」および「位置」を知るのは重要である。すなわち、その応答（Ｓ１３０９）により、種別および位置を知ることができれば、図１４に例示するように、ユーザに「１階の応接間のＴＶから使って下さい」といった具体的かつ直感的な指示を与えることが出来る（Ｓ１３１０）ため、（ＰＣ１０３の）ユーザにとって利便性が格段に向上する。特に、家庭環境では、このような直感的なわかりやすい指示が非常に重要であることから、このような利便性の向上は重要である。なお、図１４ではユーザを支援するための情報を、文章によって呈示したが、図面によって呈示するようにしてもよいし、その他の形態によってあるいは複数の形態を併用して呈示するようにしてもよい。
【００７９】
なお、この構成情報要求（Ｓ１３０８）はノードＩＤが＃ｙのノードに対する属性情報レジスタの読み出し要求、応用（Ｓ１３０９）は前記レジスタの読み出し結果であってもよい。
【００８０】
位置通知のメカニズムとして、本実施形態で記述した方法以外にも、コマンドレスポンス型の位置通知プロトコルの使用等、様々な方法を用いることが可能である。
【００８１】
なお、実施形態においては、同時利用可能なユーザ数は１であるとして説明してきたが、同時利用可能なユーザ数が２以上であっても良く、その場合にも図１０等にあるような処理手順に従えばよい。
【００８２】
利用者リストに登録された装置が複数存在する場合には、ランダムに使用確認してもよいが、使用確認する装置の優先順位を定めるようにしてもよい。例えば、固定利用レジスタが設定されておらず、かつ、データのやり取りが行われていない装置から順番に使用確認する方法、装置毎に予め使用確認の対象とする優先度を定めておく方法、利用者リストに最も長く存在する装置から優先して確認する方法など、あるいはそのような基準を複数組み合わせて優先度を評価する方法等、種々の方法が考えられる。
【００８３】
また、例えば制御側となる装置（本例ではＴＶ）においてメニュー画面として当該装置からアクセスあるいは制御等のできる装置もしくはサービスのアイコン（例えばＶＴＲアイコン）を表示する場合に、この時点で制御権が確保できるものと制御権が確保できないものとで、アイコン表示の表示形態を異ならせてその旨をユーザに呈示し、制御権が確保できないものについては選択できないようにしてもよい。また、制御権が確保できないものについては現在どの装置が制御権を保持しているかを併せて表示するようにしてもよい。
【００８４】
さらに、上記のように予め各装置について制御権の確保の可能性をチェックしておく第１のモードと、図４や図６の手順例のようにユーザが装置を選択した後に制御権の有無をチェックする第２のモードとをユーザが選択可能としてもよい。このモード選択を各装置毎に設定可能としてもよい。
【００８５】
また、第１のモードでメニュー画面の表示の際に、もしくは第２のモードで制御権確保ができなかったときのメッセージの表示の際に、制御権を確保できるようになるまでに要する予想時間もしくは今後少なくとも制御権を確保できないであろう予想時間等が分かれば、これを併せて表示するようにしてもよい。例えば、ＴＶ１０２がＶＴＲ１０１を利用している場合に、ＡＶストリームの残量がａ時間であるならば、その時間経過後に１つのコンテンツの視聴が終了し、制御権が解除されることが期待できるので、その旨を表示することにより、ユーザに情報を提供することができる。また、固定利用レジスタが設定されいるがデータのやり取りが何ら行われていない装置、あるいは逆に長時間データが流れ続けている装置がある場合には、その旨を表示するようにしてもよい。これ以外にも、ユーザに呈示するメッセージとしては、種々のものが考えられる。
【００８６】
次に、図１において、ＶＴＲ１０１がネットワーク上に接続された別の装置に対して、同時に２つ以上のサービスを提供しているように見せている場合についての例を示す。
【００８７】
本実施形態においては、ＶＴＲ１０１は、単純なＶＴＲとしてだけでなく、録画したテレビ番組名を指定すると、その番組が録画されている位置までテープの位置を調整し、その位置から再生する、といった機能を持つ「テレビ番組サーバ」としての機能をも、ＩＥＥＥ１３９４バス１００に接続された他の装置に対して、サービスとして見せる場合を考える。この場合、ＶＴＲ１０１は、図１５のように、属性情報レジスタとして、「ＶＴＲ」と「テレビ番組サーバ」の２つのサービスを提供しているものとして、自身の提供サービスを登録する。各々のサービスについて、制御パネル、同時利用可能カウンタ、利用者リストが存在してもよい。
【００８８】
ただし、外からは２つのサービスを提供しているように見えるものの、実体としては、ある１つの機能（ＶＴＲ機能）を、複数の見せ方（ＶＴＲと、テレビ番組サーバ）で見せているだけであり、実際には、ネットワーク上の第１の別の装置がＶＴＲとしてこの装置を使っている場合には、この装置のＶＴＲ機能は占有されている。よって、ネットワーク上の第２の別の装置が、この装置を例えばテレビ番組サーバとして使いたいと考えたとしても、実際には第１の別の装置がＶＴＲとしてこの装置を占有しているため、使用は許可されるべきではない。
【００８９】
そこで、図１５のように、ＶＴＲの属性情報レジスタ内に、例えばハード的あるいはソフト的に同一の装置を使って提供されるサービスで、同時提供が不可能なサービスを記述しておくテーブルを用意しておく。このテーブルを「サービス同一みなしテーブル」と呼ぶ。このテーブルには、「同時提供が不可能なサービス」が並ぶため、このテーブル内のあるサービスが稼動した場合、該テーブルの他のサービスの提供も制限される。すなわち、このテーブル内のある同時利用可能カウンタの値が変化した場合、該テーブルの他のサービスの同時利用可能カウンタの値も変化する。
【００９０】
これを図１５のような属性情報レジスタを持つＶＴＲ１０１の場合の動作例を図１６に示す。外部（例えば＃ｙ）から「ＶＴＲサービス」の同時利用可能カウンタのデクリメント要求を受けた場合（Ｓ１６０１）、サービス同一みなしテーブルを参照して（Ｓ１６０２）、「テレビ番組サーバ」と「ＶＴＲ」とが同一みなしのサービスであると認識し（Ｓ１６０３）、「ＶＴＲ」サービスの同時利用可能カウンタのデクリメントと利用者リストに＃ｙを加えるとともに、「テレビ番組サーバ」サービスの同時利用可能カウンタのデクリメントを行い、「テレビ番組サーバ」利用者リストに＃ｙを加える（Ｓ１６０４）。
【００９１】
このようにすることにより、１つの装置（本例ではＶＴＲ）が複数のサービスインタフェース（本例ではＶＴＲとテレビ番組サーバ）を持っている場合に、そのサービスの排他制御を実現することが出来るようになる。すなわち、外からは別の２つ以上のサービスを提供しているように見えるものの、実体としては、ある機能（ＶＴＲ機能）を、複数の見せ方（ＶＴＲと、テレビ番組サーバ）で見せているような場合、実際にはネットワーク上の第１の別の装置がＶＴＲとしてこの装置を使っているときに、ネットワーク上の第２の別の装置が、この装置を例えばテレビ番組サーバとして使いたいと考えたとしても（実際には第１の別の装置がＶＴＲとしてこの装置を専有しているため）、使用は許可しないで済むようになる。
【００９２】
なお、図１５の例では、ＶＴＲサービス機能とテレビ番組サーバ機能が、別々に同時利用可能カウンタ、利用者リストを持っている場合について説明したが、「片方への書き換えが、もう片方への書き換えに必ず反映する」場合には、別々に同時利用可能カウンタや利用者リストを持っていることが無駄になる場合も考えられる。そこで、図１７のように、片方（テレビ番組サーバ）の同時利用可能カウンタと利用者リストについては、もう片方（ＶＴＲ）の同時利用可能カウンタと利用者リストへのポインタとし、同一の内容が書き込まれることになる同時利用可能カウンタと利用者リストの実体は、一つしか存在しないようにすることも可能である。
【００９３】
次に、図１の装置の制御にリモコン（リモートコントローラ）を使う場合について説明する。
【００９４】
リモコンと各装置の間では、ＩｒＤＡや、コントロールＩｒに代表される、赤外線上で定義された制御プロトコル（赤外線プロトコルと呼ぶ）を用いるものとする。一方、第１の実施形態で説明したように、ＩＥＥＥ１３９４バス１００上ではＡＶ／Ｃ等のＩＥＥＥ１３９４上（あるいはインターネットプロトコル上）で定義された制御プロトコル（１３９４プロトコルと呼ぶ）が用いられる。このため、前者の制御プロトコル（赤外線プロトコル）と、後者のプロトコル（１３９４プロトコルと呼ぶ）との間のプロトコル変換が行われる。
【００９５】
図１８に、ＴＶがＶＴＲの制御権の獲得を試みる場合（獲得できた場合）の処理シーケンスの一例を示す。また、図１９に、ＰＣがＶＴＲの制御権の獲得を試みる場合（獲得できなかった場合）の処理シーケンスの一例を示す。
【００９６】
例えば、ユーザは、ＴＶのリモコンを操作して、ＴＶの電源をオンにするとともに、ＴＶがつながるネットワーク上の構成情報の入手を要求する（Ｓ１８０１）。この要求は赤外線プロトコルにより行われる。ここで、赤外線プロトコルに構成情報要求のコマンドが用意されているとする。
【００９７】
これを受信したＴＶ１０２は、これを１３９４プロトコルの構成情報要求に変換し、これを接続されたネットワーク（ＩＥＥＥ１３９４）上に流す（Ｓ１８０２）。第１の実施形態と同様に構成情報応答を受け取り（Ｓ１８０３）、これを赤外線プロトコルに変換して、ＴＶリモコンに対して送出する（Ｓ１８０４）。
【００９８】
例えば、この動作をＩＥＥＥ１３９４に接続された各装置に対して行なうことにより、ＴＶリモコンはＩＥＥＥ１３９４上にどのような装置／サービスが存在しているかを認識することが出来るようになり、例えば装置／サービス一覧がＴＶリモコンに表示される。
【００９９】
これらの中からユーザがＶＴＲを選択したとすると（Ｓ１８０５）、ＴＶリモコンは、ＶＴＲ制御のための画面を赤外線プロトコルで要求する（Ｓ１８０６）。
【０１００】
これを受信したＴＶ１０２は、これを１３９４プロトコルの制御パネル要求コマンドに変換し（Ｓ１８０７）送出する。制御パネルの応答を受けた（Ｓ１８０８）ＴＶ１０２は、受信した制御パネルを赤外線プロトコルで用意された制御パネルに変換し（Ｓ１８０９）、ＶＴＲ制御画面応答の形でＴＶリモコンに送出する（Ｓ１８１０）。
【０１０１】
この赤外線プロトコルで用意された制御パネルは、例えば、図５のような１３９４プロトコルの制御画面の一つ一つのボタンが、左上から右に順番にボタン１、ボタン２、、、というように展開され、それぞれのボタンの上に「巻き戻し」、「再生」といった文字が表示される、といったものでもよい。
【０１０２】
さて、ユーザが「再生」を意味するボタン（ボタン２）を選択したとすると（Ｓ１８１１）、赤外線プロトコルにてボタン２が押されたことをＴＶ１０２に通知する。
【０１０３】
これを受信したＴＶ１０２は、この時点でＶＴＲの起動はなされていない（ＴＶ１０２がＶＴＲの制御権を有してはいない）ことから、「ＶＴＲを起動する必要がある」と判断し、第１の実施形態と同様に、同時利用カウンタデクリメント（Ｓ１８１３）と、これが成功した場合に（Ｓ１８１５）続いて再生コマンド（Ｓ１８１６）が送出される。その間に、第１の実施形態と同様に、ＶＴＲの利用者リストには、ＴＶ１０２（のノードＩＤである＃ｙ）が追加されてもよい。
【０１０４】
そして、ＶＴＲ１０１は再生動作を行い、ＩＥＥＥ１３９４を通して、ＡＶストリームがＴＶに対して送出され（Ｓ１８１８）、ＴＶ１０２は、これを受信／復号／表示して、ユーザに映像を表示することになる。
【０１０５】
この状態（図１９のＳ１９０１、Ｓ１９０２）で、ＴＶリモコンにはＶＴＲ制御画面が引き続き表示されていても良い（Ｓ１９０３）。
【０１０６】
この状態で、ＰＣのリモコンが図１８のＳ１８０１〜Ｓ１８１０と同様にＶＴＲの制御画面を表示し、ＰＣのユーザがＶＴＲの制御をしようとした（再生しようとした）とする（Ｓ１９０５）。
【０１０７】
ＰＣ１０３は、ＶＴＲ１０１に対して同時利用カウンタデクリメント要求を送出する（Ｓ１９０６）。
【０１０８】
これを受信したＶＴＲは、第１の実施形態と同様に、同時利用可能カウンタを参照し、現在ＴＶ１０２が使用中ということで、ＰＣ１０３の使用は不可であると判断して、第１の実施形態と同様に、「現在ノードＩＤ＝＃ｙのノードが使用中である」として、同時利用カウンタデクリメント要求に対する応答として、ＮＧを送る。
【０１０９】
ＰＣでは、第１の実施形態と同様に、このノードＩＤ（＃ｙ）が具体的にどこのどの様なノードであるかについての構成情報の入手を行い（Ｓ１９０８〜Ｓ１９０９）、ＰＣのディスプレイに現在使用可能な装置（ＴＶ１０２）をＰＣのユーザに提示することにより、ＰＣのユーザに「ＶＴＲを使いたい場合は、ここに行けば使うことが出来る」という情報を通知する。
【０１１０】
なお、本実施形態では、テレビ１０２を制御装置（本例ではＶＴＲを制御する）の一例として、ＰＣ１０３を制御装置（本例ではテレビがＶＴＲを制御中に同じＶＴＲを制御しようとする）の一例として説明したが、もちろん、いずれの装置も、前者および後者の両方になり得るので、両方にとっての機能を設けるのが好ましい。また、ＶＴＲ１０１を被制御装置の一例として、テレビ１０２とＰＣ１０３を制御装置の一例として説明したが、もちろん、制御装置と被制御装置の両方になり得る装置については、その両方にとっての機能を設けるのが好ましい。
【０１１１】
また、本実施形態では、アクセスされる装置の一例としてＶＴＲを、アクセスする装置（家庭ユーザがネットワークを介してサービスを利用するために操作する装置）の一例としてテレビとＰＣを用いたが、もちろん、本発明はこれらの装置に限定されず、どのような装置についても適用可能である。
【０１１２】
また、本実施形態では、ネットワークの一例としてＩＥＥＥ１３９４バスを用いたが、もちろん、本発明はこれに限定されず、どのようなネットワークについても適用可能である。
【０１１３】
また、本実施形態では、ホームネットワークを一例として取り上げたが、もちろん、本発明はこれに限定されず、オフィスや学校、店舗、その他の建物、施設等に設けられるネットワークについても適用可能である。
【０１１４】
なお、以上の各機能は、ソフトウェアとしても実現可能である。
【０１１５】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０１１６】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１１７】
【発明の効果】
本発明によれば、より有効なユーザ・サポートを考慮した排他制御を行うことができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るホームネットワークの全体構成例を示す図
【図２】被制御機器の一例であるＶＴＲの内部構成例を示す図
【図３】属性情報レジスタの一例を示す図
【図４】制御権を取得する際の処理シーケンスの一例を示す図
【図５】制御画面の一例を示す図
【図６】制御権を取得する際の処理シーケンスの他の例を示す図
【図７】制御機器の一例であるＴＶにおける固定利用レジスタに関する処理手順の一例を示すフローチャート
【図８】使用確認要求に関する処理シーケンスの一例を示す図
【図９】制御機器の一例であるＴＶが使用確認要求を受信した際の処理手順の一例を示すフローチャート
【図１０】被制御機器の一例であるＶＴＲにおける処理手順の一例を示すフローチャート
【図１１】使用確認要求に関する処理シーケンスの他の例を示す図
【図１２】使用確認要求に関する処理シーケンスのさらに他の例を示す図
【図１３】使用確認要求に関する処理シーケンスのさらに他の例を示す図
【図１４】制御権が取得できなかった際にメッセージを呈示した画面の一例を示す図
【図１５】属性情報レジスタの他の例を示す図
【図１６】属性情報レジスタに対する処理の一例を示すフローチャートフローチャート
【図１７】属性情報レジスタのさらに他の例を示す図
【図１８】リモコンを使う場合で制御権を取得する際の処理シーケンスの一例を示す図
【図１９】リモコンを使う場合で制御権を取得できなかった際の処理シーケンスの一例を示す図
【符号の説明】
１００…ＩＥＥＥ１３９４バス
１０１…ＶＴＲ
１０２…テレビ
１０３…ＰＣ
１０４…ＴＶリモコン
１０５…ＰＣリモコン
２０１…ＩＥＥＥ１３９４インタフェース
２０２…ＶＴＲ処理部
２０３…ＡＶ／Ｃコマンド処理部
２０４…属性情報レジスタ
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４バス等のネットワークを介して通信を行う通信装置に関する。
【０００２】
【従来の技術】
近年、デジタル放送の開始や、デジタルＡＶ機器の発売等、いわゆる「家庭ＡＶ環境のデジタル化」が大きな注目を集めている。デジタルＡＶデータは、様々な圧縮が可能、マルチメディアデータとしての処理が可能、何回再生しても劣化が無い、等の優れた特徴を持ち、今後その用途はますます広がっていくものと考えられる。
【０００３】
家庭ＡＶ環境のデジタル化が一般化すると、必然的に「家庭ＡＶ環境のネットワーク化」が進展する。近年流行しているインターネット等と融合させることにより、コンピュータ同士をネットワーク接続し、互いにデジタルデータのやり取りを行なうことで、公衆網からのビデオオンデマンドや、部屋間／家庭間のＡＶデータの交換等、デジタルＡＶ機器の可能性は格段に拡大することが
見込まれる。
【０００４】
ＡＶ機器のネットワーク化は、現在のコンピュータネットワークにおける「サーバ」のように、家庭内のデジタルサービスを行なう、いわゆる「ホームサーバ」の登場を誘発する。この「ホームサーバ」は、ホームネットワークに接続された複数の装置からのサービス要求に応えるもので、例えば家庭内のビデオオンデマンドサーバとなることが出来よう。
【０００５】
【発明が解決しようとする課題】
ところで、家庭向けの民生機器（ＡＶ機器、パーソナルコンピュータ、白物家電等の種々の装置を含む）は、徹底的な低コストが求められる点や、既存機器のコンポーネントの流用が多く行われるであろうことから、ホームネットワークに接続可能な機器でも、当初から「複数ユーザからの同時アクセス」が可能になるとは、必ずしも限らない。例えば、ＡＶテープを駆動する形の、いわゆる一般的なＶＴＲは、同時に利用できるユーザの数は１（録画とチューナの同時利用の場合でも当該ＶＴＲについて高々２）である。また、家庭用を考えた場合、今後も、１つの装置もしくはその装置により提供されるサービスに同時アクセス可能なユーザ数はそれほど多くはなっていかないと考えられる。
【０００６】
このような民生機器を接続したホームネットワークにおいても、同一の装置等に対して同時に複数のユーザからアクセスされることを念頭に置かねばならないため、これらのユーザの排他制御を考慮する必要がある。むしろ、民生機器では同時アクセス可能なユーザ数が少ないので、家庭内で良く利用される機器は、常に排他制御発動の可能性を帯びることになる。
【０００７】
ところが、いわゆる「家庭ユーザ」についてはコンピュータやネットワークの仕組みに対する知識が充分であると仮定することはできないため、従来のように排他制御をした際に単に「アクセス失敗」の事実だけ伝えるのではサポートが不十分であるという問題が生ずる。例えば、ＶＴＲへのアクセスを要望した家庭ユーザに対して、単純に「ＶＴＲへのアクセスが失敗しました」もしくは「排他制御のためＶＴＲへのアクセスが失敗しました」と表示したのでは、この家庭ユーザは、このメッセージ自体に対してどのように対処したらよいのかわからず困惑したり、どうしてもその時間にＶＴＲを利用する必要があるときにどのようなアクションを取れば利用できるのか（もしくはその可能性が得られるのか）わからずにその時間を徒過してしまうなど、色々な好ましくない事態が想定される。また、このようなことにより、結果的に家庭ユーザにとって操作性の良くないホームネットワークになってしまったり、ユーザフレンドリーでないと評価されてしまうなどの虞がある。
【０００８】
本発明は、上記事情を考慮してなされたもので、より有効なユーザ・サポートを考慮した排他制御の可能な通信装置を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明（請求項１）は、ネットワークに接続された通信装置（被制御側となる機器）であって、前記ネットワークを通して自通信装置を制御する制御権を保有する他の装置（制御側となる機器）の識別情報を記憶する記憶手段と、前記記憶手段に前記識別情報が記憶されていないさらに他の装置（制御側となる機器）から、自通信装置に対して制御権の取得を要求するメッセージを受信した際（例えば、同時利用カウンタデクリメント要求を受信した際、あるいは制御パネル要求を受信した際）に、前記記憶手段に記憶されている前記識別情報の数が所定の数に達しているかを否か判定する判定手段と、この判定手段により前所定の数に達していないと判定された場合に、前記さらに他の装置の識別情報を前記記憶手段に追加するとともに、該さらに他の装置に制御権取得成功を通知するメッセージを送信する第１の処理手段と、前記判定手段により前記所定の数に達していると判定された場合に、前記記憶手段に識別情報が記憶されている装置（すなわち、制御権を保有する装置）のうちに、その制御権を前記さらに他の装置に譲り渡すことのできるものが存在するか否かを調べる第２の処理手段と、前記第２の処理手段によりその制御権を前記さらに他の装置に譲り渡すことのできる装置が見つかった場合に、該制御権を譲り渡す装置の識別情報を前記記憶手段から削除し前記さらに他の装置の識別情報を前記記憶手段に追加するとともに、該さらに他の装置に制御権取得成功を通知するメッセージを送信する第３の処理手段とを備えたことを特徴とする。
【００１０】
前記所定の数は、例えば、被制御装置の所有権を同時に保有可能な制御装置の数で、各被制御装置毎に（その装置の性能もしくは仕様等で）定まる数である。例えば、被制御装置がＶＴＲで同時に１つのストリームデータしか提供できない場合には所定の数は１となり、同時に３つのストリームデータを提供できる場合には所定の数は３となる。なお、ある被制御装置について同時にｎ台の制御装置が制御権を保有できる場合であっても、所定の数をｎより小さい数に設定しても構わない。
【００１１】
好ましくは、前記第２の処理手段は、自通信装置が現にデータをやり取りしている相手装置については、その制御権が維持されるべきもの（譲り渡すことはできない）と判断するようにしてもよい。
【００１２】
好ましくは、前記第２の処理手段は、自通信装置が最後にデータをやり取りしてから経過した時間が一定範囲以内である相手装置についても、その制御権が維持されるべきもの（譲り渡すことはできない）と判断するようにしてもよい。
【００１３】
好ましくは、前記第２の処理手段は、前記記憶手段に識別情報が記憶されている装置の少なくとも一部に対して、その制御権を維持するか否かを問い合わせるメッセージ（使用確認要求）を送信し、その返答により該制御権が維持されるべきもの（譲り渡すことはできない）か否かを判断する手段を含むようにしてもよい。
【００１４】
好ましくは、前記第２の処理手段は、前記メッセージを送信する対象とし得る装置が複数存在する場合に、所定の選択基準で選択した順番で、前記メッセージの送信およびその返答による前記判断を行うようにしてもよい。
【００１５】
好ましくは、自通信装置に対する制御権を保有する他の装置から該制御権を維持し続ける旨の特別のメッセージを受信した場合に、該他の装置の識別情報を登録する登録手段を更に備え、前記第２の処理手段は、前記登録手段に識別情報が登録されている装置については、その制御権が維持されるべきもの（譲り渡すことはできない）と判断するようにしてもよい。
【００１６】
好ましくは、前記第２の処理手段によりその制御権を前記さらに他の装置に譲り渡すことのできる装置が見つからなかった場合に、前記さらに他の装置に制御権取得失敗を通知するメッセージを送信する第４の処理手段を更に備えるようにしてもよい。
【００１７】
好ましくは、前記第４の処理手段は、前記さらに他の装置に制御権を保有する他の装置（すなわち、前記記憶手段に識別情報が記憶されている装置）の識別情報を前記メッセージに含めて送信するようにしてもよい。
【００１８】
好ましくは、自通信装置が複数の異なる装置またはサービスの形でネットワークに公開される場合には、公開された各装置またはサービス毎に、その制御権を保有する他の装置の識別情報を管理するようにしてもよい。
【００１９】
好ましくは、前記異なる装置またはサービスのうちの特定の２以上のものについて制御権保有可能な装置の数がそれらの総和として限定される場合には、該特定の２以上の装置またはサービスについては前記制御権を保有する他の装置の識別情報を統一して管理するようにしてもよい。
例えば、ある被制御装置において、機能ａについて同時にｘ台の制御装置が制御権を保有でき、機能ｂについても同時にｘ台の制御装置が制御権を保有できるが、機能ａについて同時にｙ台の制御装置が制御権を保有している場合には機能ｂについては同時にｘ−ｙ台の制御装置しか制御権を保有できない（同様に、機能ｂについて同時にｙ台の制御装置が制御権を保有している場合には機能ａについては同時にｘ−ｙ台の制御装置しか制御権を保有できない）ような場合には、機能ａについて制御権を保有している制御装置と機能ｂについて
制御権を保有している制御装置とを統一して管理するのが好ましい。
【００２０】
本発明（請求項１１）は、ネットワークに接続された通信装置（制御側となる機器）であって、前記ネットワークを通して他の装置を制御するためのコマンドを送信する手段と、前記他の装置から、さらに他の装置が該他の装置を制御しているために現在は制御を受け付けられない旨を示す情報と該さらに他の装置の識別情報とを含むメッセージを受信した場合に、該さらに他の装置に関する詳細情報を検索する手段と、前記詳細情報に基づいて作成した、ユーザを支援するための情報を、ユーザインタフェースを通じて呈示する手段とを備えたことを特徴とする。
【００２１】
好ましくは、前記詳細情報は、前記さらに他の装置の種類に関する情報または該装置が設置された物理的位置に関する情報の少なくとも一方を含むものであり、前記ユーザを支援するための情報は、前記さらに他の装置の種類または該装置が設置された物理的位置の少なくとも一方をユーザに通知する文言あるいは図面を含むものであるようにしてもよい。
【００２２】
本発明によれば、要求された装置（またはサービス）に対するの現在の制御権保有装置数が所定の数に達している場合でも、その時点でその要求を拒絶するのではなく、その制御権を譲り渡してくれる装置があるかどうかを探し、制御権を譲り渡してくれる装置があれば、制御権を取得することができる。
【００２３】
また、制御権が得られなかったときでも、単に制御権が得られなかった旨を呈示するだけではなく、その装置（またはサービス）に対するの現在の制御権保有装置に関する詳細な情報を含むメッセージを呈示するようにすれば、ユーザは次のアクションを取りやすくなる。
【００２４】
このように本発明によれば、より有効なユーザ・サポートを考慮した排他制御を行うことができる。
【００２５】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００２６】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２７】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２８】
図１は、ある家庭のホームネットワークの全体構成を一例として示した図である。
【００２９】
図１に例示したホームネットワークは、ＩＥＥＥ１３９４バス１００を用いて構成され、ＶＴＲ１０１、テレビ１０２、ＰＣ１０３の３つの装置が接続されているものである。ＶＴＲ１０１のノードＩＤは＃ｘ、テレビ１０２のノードＩＤは＃ｙ、ＰＣ１０３のノードＩＤは＃ｚとする。
【００３０】
本実施形態では、テレビ１０２とＰＣ１０３には、それぞれ、いわゆるディスプレイ（表示デバイス）が附属しており、それら装置（１０２，１０３）のユーザは、その付属のディスプレイを通して（例えば、ＴＶリモコン１０４やＰＣリモコン１０５およびその付属ディスプレイあるいはマウス等の入力デバイスを使って）、ＶＴＲ１０１の制御画面を操作することができるような場合を想定して説明する。また、ＶＴＲ１０１を被制御装置の一例として、テレビ１０２を制御装置（本例ではＶＴＲを制御する）の一例として、ＰＣ１０３を制御装置（本例ではテレビがＶＴＲを制御中に同じＶＴＲを制御しようとする）の一例として説明する。
【００３１】
図２に、本例でアクセスされる対象となるＶＴＲ１０１の内部構成例を示す。
【００３２】
このＶＴＲ１０１は、いわゆるデジタルＶＴＲであり、デジタル形式（例えばＭＰＥＧ２）でＡＶデータの保存、再生等を行なう。
【００３３】
ＶＴＲ処理部２０２は、テープ、および機構部分であり、録画、再生、テープの巻き戻し、早送り等の動作を行い、ＩＥＥＥ１３９４インタフェース２０１とデジタルＡＶストリームデータのやり取りを行う。
【００３４】
ＡＶ／Ｃコマンド処理部２０３は、標準化団体であるＩＥＥＥ１３９４トレードアソシエーション（１３９４ＴＡ）が決定するＡＶ機器の制御コマンド体系の処理を行なう。基本的に、ＡＶ／ＣコマンドはＩＥＥＥ１３９４バスを介してやり取りされる。なお、ＡＶ／Ｃについては、例えば、ＡＶ／Ｃ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ Ｃｏｍｍａｎｄ Ｓｅｔ Ｇｅｎｅｒａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＩＥＥＥ１３９４−１９９５等に記載されている。
【００３５】
属性情報レジスタ２０４は、ＩＥＥＥ１３９４インタフェース２０１を介して、ＩＥＥＥ１３９４バスに接続された他の装置からも、特定のアドレスを指定することの出来るメモリ領域である。具体的には、図３に例示したように、このレジスタを持つ装置についての種々の属性情報、例えば、ベンダ名、装置名（例えば、ＶＴＲ）、製造番号や型番、この装置を制御するための制御画面の構成情報（制御パネル）、この装置の現在位置を記す現在位置情報、後述する制御で使われる同時利用可能カウンタと利用者リスト等がある。なお、これらの情報は、必ずしも図３のような順序で格納されている必要はなく、例えばお互いに離れた空間に格納されていても良い。
【００３６】
ＩＥＥＥ１３９４バスにつながる他の装置は、その装置の「どのアドレス」にアクセスすれば上記したような各々の属性情報を得ることができるかについて、あらかじめ知っている（知らされている）ものとする。また、このレジスタの特定の領域（例えば、ベンダ名、装置名、製造番号や型番、制御パネル、現在位置情報）については、その装置の製造時あるいはＩＥＥＥ１３９４バス等のネットワークに接続される以前からあらかじめ登録されているとしてもよい。
【００３７】
次に、ＴＶ１０２のユーザがそのＴＶの画面を通してＶＴＲ１０１の遠隔制御を行なう場合を例にとって構成や処理の流れについて説明する。
【００３８】
図４に、この場合の処理シーケンスの一例を示す。
【００３９】
まず初期段階において、ＴＶ１０２は、ＶＴＲ１０１に対して（ＴＶは、この時点では、当該相手のことを「ノードＩＤ＝＃ｘの装置である」としか認識しておらず、ＶＴＲであるということを認識していない）、構成情報要求（Ｓ４０１）を送出する。実際には、上記の属性情報レジスタの特定のアドレスを読みに行く動作を行なうのでもよい。
【００４０】
ＶＴＲ１０１では、構成情報要求を属性情報レジスタ２０４が受信し、属性情報レジスタ２０４が構成情報要求に対する応答を行なう（Ｓ４０２）。この時点で、ＴＶ１０２は、この装置１０１がＶＴＲであることなどを認識することができ、ユーザに対して属性を認識した上での表示を行うことができる。
【００４１】
なお、ＩＥＥＥ１３９４バス１００に複数の装置が接続されている場合には、上記処理を各装置について行うと好ましい。
【００４２】
さて、例えばＴＶ１０２において当該ＴＶ１０２からアクセスあるいは制御等のできる装置もしくはサービスのアイコンなどが表示された状態等において、ＴＶ１０２のユーザが制御対象の装置としてＶＴＲを選択したとする（Ｓ４０３）。
【００４３】
すると、ＴＶ１０２のディスプレイにＶＴＲの制御画面を表示させるべく、制御パネル要求（Ｓ４０４）をＶＴＲ１０１に送出する。この要求はＡＶ／Ｃプロトコルの一部であってもよい。
【００４４】
ＶＴＲ１０１では、制御パネル要求をＡＶ／Ｃコマンド処理部２０３が受信し、制御パネル応答（Ｓ４０５）で制御パネルをＴＶ１０２に送付する。
【００４５】
制御パネルは、例えば図５に例示したようなものである。例えば、ユーザが制御画面上で再生ボタン（５０１）を押すと、「再生ボタンが押されました（ＡＶ／Ｃの再生コマンド）」、あるいは「ボタン２が押されました（ＶＴＲ１０１は、ボタン２が「再生」に相当する、ということを認識している）」といったコマンド（図４のＳ４１０に相当）が、ＩＥＥＥ１３９４バス１００を経由してＶＴＲ１０１に伝えられる。
【００４６】
さて、制御パネル応答を受信したＴＶ１０２は、図５のような制御画面をディスプレイに表示する。ユーザは、リモコンやマウス等を用いて、制御パネルの操作を行なう。ここでは、一例として、再生ボタンが押されたものとする（Ｓ４０６）。
【００４７】
すると、ＴＶ１０２は、まず、ＶＴＲ１０１の制御権を確保しようとする。
【００４８】
ここで、「制御権」とは、その装置の制御を行なうことの出来る権利である。後述のメカニズムにより、制御権の有無の判断が行われる。制御権の確保を司るのが属性情報レジスタ２０４中の同時利用可能カウンタと、利用者リストである。「同時利用可能カウンタ」は、その時点でその装置を同時に利用することの出来るユーザ数を示すカウンタである。この装置（本例ではＶＴＲ１０１）を利用しようとするＩＥＥＥ１３９４バス１００上の他の装置（本例ではＴＶ１０２）は、当該装置（ＶＴＲ１０１）の同時利用可能カウンタをデクリメントした上で、利用者リストに当該他の装置（ＴＶ１０２）のＩＤ（例えばノードＩＤやＥＵＩ６４など）を登録する。なお、ＥＵＩ６４とは、６４ビットのハードウエアアドレスのことである。
【００４９】
ＴＶ１０２は、同時利用カウンタデクリメント要求（Ｓ４０７）をＶＴＲ１０１に送出する。この要求には、何等かの形（例えばパケットの送信元アドレス）で送信元装置（ＴＶ１０２）のノードＩＤ（またはＥＵＩ６４）が含まれている。
【００５０】
これを受信したＶＴＲ１０１は、同時利用カウンタの値が１以上である場合には、このカウンタの値をデクリメントし、さらに同時利用カウンタデクリメント要求の送信元装置（ＴＶ１０２）のアドレス（ノードＩＤ＝＃ｙ）を利用者リストに登録し（Ｓ４０８）、同時利用カウンタデクリメント要求がうまく行ったことを返答する（Ｓ４０９）。
【００５１】
この時点で、ＴＶ１０２はＶＴＲ１０１の制御権を確保したことになり、操作コマンド（本例では再生コマンド）をＶＴＲ１０１に対して送付する（Ｓ４１０）。
【００５２】
再生コマンドを受信したＶＴＲ１０１は、これに応じて再生動作を行い（Ｓ４１１）、ＩＥＥＥ１３９４バス１００を経由してＡＶストリームをＴＶ１０２に送付する（Ｓ４１２）。
【００５３】
また、図４とは別の手順で制御権の確保を行なう方法もある。図６に、そのような処理シーケンスの他の例を示す。図４では、ユーザが装置（ＶＴＲ）を選択した際に、制御パネル（取得・表示・コマンド入力）→同時利用カウンタデクリメントの順で制御を行なってきたが、図６では同時利用カウンタデクリメント→制御パネルの順で制御を行なう。すなわち、制御権の確保を先に行ない（Ｓ６０４〜Ｓ６０６）、制御権が確保できた場合にのみ、制御パネルを送付する（Ｓ６０７〜Ｓ６０８）。本実施形態では、図４の方式を中心として説明するものとしているが、もちろん、いずれの場合においても、図６の方式も可能である。
【００５４】
次に、固定利用について説明する。
【００５５】
例えば、ＶＴＲ１０１の同時利用者数すなわち同時に制御権を持つことのできるものの数は１であり、現在ＴＶ１０２がその制御権を持っているものとする（この時点ではＶＴＲ１０１の同時利用カウンタは０である）。このとき、ＴＶ１０２のユーザは、自分が持っている制御権を他の装置に対しては与えたくない（制御権を維持し続けたい）と考えたとする。そのような場合に、例えば、図５のように制御パネルに「利用装置固定」のボタン（５０２）を設け、ＴＶ１０２のユーザがこのボタンを押すことにより、制御権が奪われないようにすることができる。
【００５６】
図７に、この場合の処理手順の一例を示す。
【００５７】
この「利用装置固定」ボタンが押された場合には（Ｓ７０１）、ＴＶ１０２内にある「固定利用レジスタ」に使用中の装置（ＶＴＲ１０１）が記録され（Ｓ７０２）、後述するように「その装置は自分が使用中である」と主張することが出来るようになる（制御権を保護されるようになる）。
【００５８】
また、「利用装置固定解除」ボタンを押すなり、ユーザがその装置の利用を終了するなりすると（Ｓ７０３，Ｓ７０４）、固定利用レジスタからその装置（ＶＴＲ１０１）の登録を削除する（Ｓ７０５）。
【００５９】
なお、ＩＥＥＥ１３９４バス１００を経由せず、ＶＴＲ１０１の装置そのものについているボタン等で制御を行なうことは、本実施形態における制御権とは関係なく可能であってもよい。あるいは、ＶＴＲ１０１の装置そのものについているボタン等で制御を行なう場合にも本実施形態における制御権を登録し、当該制御権を絶対的なもの（常に制御権を維持することができ、かつ、常に制御権を奪い取ることができる）とするようにしてもよい。
【００６０】
次に、ＩＥＥＥ１３９４バス１００上の第３の装置（本例ではＰＣ１０３）のユーザが、現在ＴＶ１０２が使っているＶＴＲ１０１の制御権を獲得しようとする場合について説明する。
【００６１】
図８に、この場合の処理シーケンスの一例を示す。
【００６２】
まず、前述のように、ＴＶ１０２のユーザが、「利用装置固定」のボタンを押し、ＴＶ１０２内の固定利用レジスタにＶＴＲ１０１が登録されている（Ｓ８０１〜Ｓ８０３）。
【００６３】
ここで、ＰＣ１０３のユーザがＶＴＲ１０１の制御を行なおうとして、同時利用カウンタデクリメント要求を出す（Ｓ８０４）。
【００６４】
これを受信したＶＴＲ１０１は、その許可の可否を判定する。判定中はＰＣ１０３に対して「待て」の信号を送っておいてもよい（Ｓ８０５）。
【００６５】
まず、ＶＴＲ１０１は、自身の同時利用カウンタの値が０になっていることを確認し、誰かがＶＴＲ１０１の使用権を放棄しない限り、同時利用は出来ないことを認識する。そこで、利用者リストを参照し、そこに登録されているＴＶ１０２に対して、「現在、ＶＴＲ１０１を使用しているかどうかの確認」のための信号（使用確認要求）を送付する（Ｓ８０６）。
【００６６】
図９に、使用確認要求を受けた際のＴＶ１０２の手順の一例を示す。
【００６７】
使用確認要求を受信したＴＶ１０２は（Ｓ９０１）、固定利用レジスタを参照するなどして（Ｓ９０２，Ｓ９０４，Ｓ９０５，Ｓ９０７，Ｓ９０８）、自身がＶＴＲ１０１を使用中であると認識した場合には、「使用中」を意味する応答を返す（Ｓ８０７）（Ｓ９０６）。そうでなければ、「終了」を意味する応答を返す（Ｓ９０３，Ｓ９０９／Ｓ９１０）。
【００６８】
「使用中」を意味する応答を返す場合としては、例えば、以下のような場合が考えられる（図９参照）。
（１）固定利用レジスタにその装置（ＶＴＲ１０１）が登録されている場合（あらかじめユーザが制御権を手放したくないと宣言している場合）
（２）その装置（ＶＴＲ１０１）とＡＶストリームをやりとりしている場合、あるいはやり取りをして一定時間以下しか経っていない場合
（３）その装置（ＶＴＲ１０１）と制御コマンドのやり取りをしている場合、あるいはやり取りをして一定時間以下しか経っていない場合
（４）ユーザインタフェースを通して、ユーザに「現在その装置（ＶＴＲ１０１）を使用中ですか？」と質問を出し、ユーザから使用中であるとのインタラクションを受けた場合
ＴＶ１０２から「使用中」である旨の使用確認応答を受信したＶＴＲ１０１は、要求元（ＰＣ１０３）が自装置を同時利用することは不可能であると認識し、その旨をＰＣ１０３に通知する（Ｓ８０８）。
【００６９】
なお、上記では、ＶＴＲ１０１はＴＶ１０２に依頼して使用確認を行ったが、現在ＶＴＲ１０１が使用可能であるかどうかの判断を少なくとも一部分についてＶＴＲ１０１自身が行なっうようにしてもよい。
【００７０】
図１０に、この場合のＶＴＲ１０１における処理手順の一例を示す。
【００７１】
制御パネルの送付や利用者リストの登録があった後に（Ｓ１００１，Ｓ１００２）、同時利用カウンタデクリメント要求を受信した際（Ｓ１００３）、カウンタの値が０である場合には（Ｓ１００４）、登録されている装置（ＴＶ１０２）とＡＶストリームあるいは制御コマンドをやり取りしており、もしくは一定時間以下しか経っていないならば（Ｓ１００７）、使用中であるので（Ｓ１００８）、要求元（ＰＣ１０３）に「デクリメントＮＧ」を送付する（Ｓ１００９）。そうでないならば、登録されている装置（ＴＶ１０２）に対してしよう確認要求を出し（Ｓ１０１０）、応答に応じた処理を行う。例えば、使用中の応答を受信したならば（Ｓ１０１１）、現在の利用者が使用中であるので（Ｓ１００８）、デクリメントＮＧを送付する（Ｓ１００９）。終了の応答を受信したならば（Ｓ１０１２）、この利用者を利用者リスト（ＴＶ１０２）から削除し、要求元の利用者（ＰＣ１０３）を追加し（Ｓ１０１３）、デクリメントＯＫを送付する（Ｓ１０１４）。もちろん、同時利用カウンタデクリメント要求を受信した際（Ｓ１００３）、カウンタの値が０でない場合には（Ｓ１００４）、同時利用可能カウンタをデクリメントし、要求元の利用者を利用者リストに追加し（Ｓ１００５）、デクリメントＯＫを送付する（Ｓ１００６）。
【００７２】
これらを組み合わせることにより、例えば図１１のように、ＶＴＲ１０１の現在の制御権はＴＶ１０２が持っている場合に、使用確認要求をＴＶ１０２に送付し（Ｓ１１０４）、ユーザからのインタラクションがあったときには（Ｓ１１０４）、「使用中」の旨を返答し（Ｓ１１０５）、ＰＣ１０３には制御権を渡さないようにできる。また、例えば図１２のように、ユーザからのインタラクションがなかったときには（Ｓ１２０５）、「使用終了」の旨を返答し、ＰＣ１０３に制御権を渡す（利用者リストから＃ｙを削除し、＃ｚを登録し直す）ことも可能となる。
【００７３】
このようにして、ＶＴＲ１０１は使用権の排他制御を行なうことが出来る。
【００７４】
なお、上記では、固定利用レジスタについては、制御側の装置（ＴＶ）内に被制御側の装置（ＶＴＲ）を登録したが、制御側の装置（ＴＶ）から被制御側の装置（ＶＴＲ）に特別のメッセージで通知して被制御側の装置（ＶＴＲ）内にそれを使用中の装置（ＴＶ）を登録するようにしてもよい。この場合、固定利用レジスタについての使用確認は、要求を受信した装置（ＶＴＲ）内で行うことができる。
【００７５】
さて、図１１では、ＰＣ１０３が、ＶＴＲ１０１の制御権を獲得できなかった場合、ＰＣ１０３のユーザは、単純に「同時利用カウンタのデクリメントに失敗した」、「ＶＴＲ１０１の制御権確保に失敗した」という通知しか受けない。これは、ＰＣ１０３のユーザから見ると「ここからＶＴＲの制御は今出来ない」ということを通知してもらうだけで、「では、どうすれば制御が出来るのか（そうすればＶＴＲを使うことが出来るのか）」の情報を得ることが出来ない。そこで、よりきめ細かくユーザをサポートするために、図１３のような仕組みを設けるようにしてもよい。
【００７６】
すなわち、ＶＴＲ１０１がＰＣ１０３に「同時利用カウンタのデクリメントはできない」、「ＶＴＲ１０１の制御権確保に失敗した」という通知を送る際に、利用者リストを参照して、現在自分自身（ＶＴＲ１０１）の制御権を持っている装置（本例ではＴＶ１０２）のＩＤ（本例ではノードＩＤ）を併せて通知する（Ｓ１３０７）。すると、理論的には、ＰＣ１０３（のユーザ）は少なくともＴＶ１０２がＶＴＲ１０１を制御している点、また、ＴＶ１０２を使えばＶＴＲ１０１を使うことが出来る、と言うことを認識することが出来るようになる。
【００７７】
ただし、ユーザからすると、実際にはＴＶ１０２のノードＩＤを通知してもらっただけで、このノードＩＤを持った装置が一体何なのか、またどこにある装置なのかについて認識することは、ノードＩＤとその説明を記述した一覧表でも用意しない限り困難である（また、一覧表の作成とその使用も煩雑である）。
【００７８】
そこで、ＴＶ１０２のノードＩＤ（＃ｙ）を通知してもらったＰＣ１０３は、このノードＩＤを手がかりに、そのノードＩＤ（＃ｙ）を持つノード（ＴＶ１０２）に対して、構成情報要求を送出するようにする（Ｓ１３０８）。特に、この構成情報要求にて、「その装置の種別」および「位置」を知るのは重要である。すなわち、その応答（Ｓ１３０９）により、種別および位置を知ることができれば、図１４に例示するように、ユーザに「１階の応接間のＴＶから使って下さい」といった具体的かつ直感的な指示を与えることが出来る（Ｓ１３１０）ため、（ＰＣ１０３の）ユーザにとって利便性が格段に向上する。特に、家庭環境では、このような直感的なわかりやすい指示が非常に重要であることから、このような利便性の向上は重要である。なお、図１４ではユーザを支援するための情報を、文章によって呈示したが、図面によって呈示するようにしてもよいし、その他の形態によってあるいは複数の形態を併用して呈示するようにしてもよい。
【００７９】
なお、この構成情報要求（Ｓ１３０８）はノードＩＤが＃ｙのノードに対する属性情報レジスタの読み出し要求、応用（Ｓ１３０９）は前記レジスタの読み出し結果であってもよい。
【００８０】
位置通知のメカニズムとして、本実施形態で記述した方法以外にも、コマンドレスポンス型の位置通知プロトコルの使用等、様々な方法を用いることが可能である。
【００８１】
なお、実施形態においては、同時利用可能なユーザ数は１であるとして説明してきたが、同時利用可能なユーザ数が２以上であっても良く、その場合にも図１０等にあるような処理手順に従えばよい。
【００８２】
利用者リストに登録された装置が複数存在する場合には、ランダムに使用確認してもよいが、使用確認する装置の優先順位を定めるようにしてもよい。例えば、固定利用レジスタが設定されておらず、かつ、データのやり取りが行われていない装置から順番に使用確認する方法、装置毎に予め使用確認の対象とする優先度を定めておく方法、利用者リストに最も長く存在する装置から優先して確認する方法など、あるいはそのような基準を複数組み合わせて優先度を評価する方法等、種々の方法が考えられる。
【００８３】
また、例えば制御側となる装置（本例ではＴＶ）においてメニュー画面として当該装置からアクセスあるいは制御等のできる装置もしくはサービスのアイコン（例えばＶＴＲアイコン）を表示する場合に、この時点で制御権が確保できるものと制御権が確保できないものとで、アイコン表示の表示形態を異ならせてその旨をユーザに呈示し、制御権が確保できないものについては選択できないようにしてもよい。また、制御権が確保できないものについては現在どの装置が制御権を保持しているかを併せて表示するようにしてもよい。
【００８４】
さらに、上記のように予め各装置について制御権の確保の可能性をチェックしておく第１のモードと、図４や図６の手順例のようにユーザが装置を選択した後に制御権の有無をチェックする第２のモードとをユーザが選択可能としてもよい。このモード選択を各装置毎に設定可能としてもよい。
【００８５】
また、第１のモードでメニュー画面の表示の際に、もしくは第２のモードで制御権確保ができなかったときのメッセージの表示の際に、制御権を確保できるようになるまでに要する予想時間もしくは今後少なくとも制御権を確保できないであろう予想時間等が分かれば、これを併せて表示するようにしてもよい。例えば、ＴＶ１０２がＶＴＲ１０１を利用している場合に、ＡＶストリームの残量がａ時間であるならば、その時間経過後に１つのコンテンツの視聴が終了し、制御権が解除されることが期待できるので、その旨を表示することにより、ユーザに情報を提供することができる。また、固定利用レジスタが設定されいるがデータのやり取りが何ら行われていない装置、あるいは逆に長時間データが流れ続けている装置がある場合には、その旨を表示するようにしてもよい。これ以外にも、ユーザに呈示するメッセージとしては、種々のものが考えられる。
【００８６】
次に、図１において、ＶＴＲ１０１がネットワーク上に接続された別の装置に対して、同時に２つ以上のサービスを提供しているように見せている場合についての例を示す。
【００８７】
本実施形態においては、ＶＴＲ１０１は、単純なＶＴＲとしてだけでなく、録画したテレビ番組名を指定すると、その番組が録画されている位置までテープの位置を調整し、その位置から再生する、といった機能を持つ「テレビ番組サーバ」としての機能をも、ＩＥＥＥ１３９４バス１００に接続された他の装置に対して、サービスとして見せる場合を考える。この場合、ＶＴＲ１０１は、図１５のように、属性情報レジスタとして、「ＶＴＲ」と「テレビ番組サーバ」の２つのサービスを提供しているものとして、自身の提供サービスを登録する。各々のサービスについて、制御パネル、同時利用可能カウンタ、利用者リストが存在してもよい。
【００８８】
ただし、外からは２つのサービスを提供しているように見えるものの、実体としては、ある１つの機能（ＶＴＲ機能）を、複数の見せ方（ＶＴＲと、テレビ番組サーバ）で見せているだけであり、実際には、ネットワーク上の第１の別の装置がＶＴＲとしてこの装置を使っている場合には、この装置のＶＴＲ機能は占有されている。よって、ネットワーク上の第２の別の装置が、この装置を例えばテレビ番組サーバとして使いたいと考えたとしても、実際には第１の別の装置がＶＴＲとしてこの装置を占有しているため、使用は許可されるべきではない。
【００８９】
そこで、図１５のように、ＶＴＲの属性情報レジスタ内に、例えばハード的あるいはソフト的に同一の装置を使って提供されるサービスで、同時提供が不可能なサービスを記述しておくテーブルを用意しておく。このテーブルを「サービス同一みなしテーブル」と呼ぶ。このテーブルには、「同時提供が不可能なサービス」が並ぶため、このテーブル内のあるサービスが稼動した場合、該テーブルの他のサービスの提供も制限される。すなわち、このテーブル内のある同時利用可能カウンタの値が変化した場合、該テーブルの他のサービスの同時利用可能カウンタの値も変化する。
【００９０】
これを図１５のような属性情報レジスタを持つＶＴＲ１０１の場合の動作例を図１６に示す。外部（例えば＃ｙ）から「ＶＴＲサービス」の同時利用可能カウンタのデクリメント要求を受けた場合（Ｓ１６０１）、サービス同一みなしテーブルを参照して（Ｓ１６０２）、「テレビ番組サーバ」と「ＶＴＲ」とが同一みなしのサービスであると認識し（Ｓ１６０３）、「ＶＴＲ」サービスの同時利用可能カウンタのデクリメントと利用者リストに＃ｙを加えるとともに、「テレビ番組サーバ」サービスの同時利用可能カウンタのデクリメントを行い、「テレビ番組サーバ」利用者リストに＃ｙを加える（Ｓ１６０４）。
【００９１】
このようにすることにより、１つの装置（本例ではＶＴＲ）が複数のサービスインタフェース（本例ではＶＴＲとテレビ番組サーバ）を持っている場合に、そのサービスの排他制御を実現することが出来るようになる。すなわち、外からは別の２つ以上のサービスを提供しているように見えるものの、実体としては、ある機能（ＶＴＲ機能）を、複数の見せ方（ＶＴＲと、テレビ番組サーバ）で見せているような場合、実際にはネットワーク上の第１の別の装置がＶＴＲとしてこの装置を使っているときに、ネットワーク上の第２の別の装置が、この装置を例えばテレビ番組サーバとして使いたいと考えたとしても（実際には第１の別の装置がＶＴＲとしてこの装置を専有しているため）、使用は許可しないで済むようになる。
【００９２】
なお、図１５の例では、ＶＴＲサービス機能とテレビ番組サーバ機能が、別々に同時利用可能カウンタ、利用者リストを持っている場合について説明したが、「片方への書き換えが、もう片方への書き換えに必ず反映する」場合には、別々に同時利用可能カウンタや利用者リストを持っていることが無駄になる場合も考えられる。そこで、図１７のように、片方（テレビ番組サーバ）の同時利用可能カウンタと利用者リストについては、もう片方（ＶＴＲ）の同時利用可能カウンタと利用者リストへのポインタとし、同一の内容が書き込まれることになる同時利用可能カウンタと利用者リストの実体は、一つしか存在しないようにすることも可能である。
【００９３】
次に、図１の装置の制御にリモコン（リモートコントローラ）を使う場合について説明する。
【００９４】
リモコンと各装置の間では、ＩｒＤＡや、コントロールＩｒに代表される、赤外線上で定義された制御プロトコル（赤外線プロトコルと呼ぶ）を用いるものとする。一方、第１の実施形態で説明したように、ＩＥＥＥ１３９４バス１００上ではＡＶ／Ｃ等のＩＥＥＥ１３９４上（あるいはインターネットプロトコル上）で定義された制御プロトコル（１３９４プロトコルと呼ぶ）が用いられる。このため、前者の制御プロトコル（赤外線プロトコル）と、後者のプロトコル（１３９４プロトコルと呼ぶ）との間のプロトコル変換が行われる。
【００９５】
図１８に、ＴＶがＶＴＲの制御権の獲得を試みる場合（獲得できた場合）の処理シーケンスの一例を示す。また、図１９に、ＰＣがＶＴＲの制御権の獲得を試みる場合（獲得できなかった場合）の処理シーケンスの一例を示す。
【００９６】
例えば、ユーザは、ＴＶのリモコンを操作して、ＴＶの電源をオンにするとともに、ＴＶがつながるネットワーク上の構成情報の入手を要求する（Ｓ１８０１）。この要求は赤外線プロトコルにより行われる。ここで、赤外線プロトコルに構成情報要求のコマンドが用意されているとする。
【００９７】
これを受信したＴＶ１０２は、これを１３９４プロトコルの構成情報要求に変換し、これを接続されたネットワーク（ＩＥＥＥ１３９４）上に流す（Ｓ１８０２）。第１の実施形態と同様に構成情報応答を受け取り（Ｓ１８０３）、これを赤外線プロトコルに変換して、ＴＶリモコンに対して送出する（Ｓ１８０４）。
【００９８】
例えば、この動作をＩＥＥＥ１３９４に接続された各装置に対して行なうことにより、ＴＶリモコンはＩＥＥＥ１３９４上にどのような装置／サービスが存在しているかを認識することが出来るようになり、例えば装置／サービス一覧がＴＶリモコンに表示される。
【００９９】
これらの中からユーザがＶＴＲを選択したとすると（Ｓ１８０５）、ＴＶリモコンは、ＶＴＲ制御のための画面を赤外線プロトコルで要求する（Ｓ１８０６）。
【０１００】
これを受信したＴＶ１０２は、これを１３９４プロトコルの制御パネル要求コマンドに変換し（Ｓ１８０７）送出する。制御パネルの応答を受けた（Ｓ１８０８）ＴＶ１０２は、受信した制御パネルを赤外線プロトコルで用意された制御パネルに変換し（Ｓ１８０９）、ＶＴＲ制御画面応答の形でＴＶリモコンに送出する（Ｓ１８１０）。
【０１０１】
この赤外線プロトコルで用意された制御パネルは、例えば、図５のような１３９４プロトコルの制御画面の一つ一つのボタンが、左上から右に順番にボタン１、ボタン２、、、というように展開され、それぞれのボタンの上に「巻き戻し」、「再生」といった文字が表示される、といったものでもよい。
【０１０２】
さて、ユーザが「再生」を意味するボタン（ボタン２）を選択したとすると（Ｓ１８１１）、赤外線プロトコルにてボタン２が押されたことをＴＶ１０２に通知する。
【０１０３】
これを受信したＴＶ１０２は、この時点でＶＴＲの起動はなされていない（ＴＶ１０２がＶＴＲの制御権を有してはいない）ことから、「ＶＴＲを起動する必要がある」と判断し、第１の実施形態と同様に、同時利用カウンタデクリメント（Ｓ１８１３）と、これが成功した場合に（Ｓ１８１５）続いて再生コマンド（Ｓ１８１６）が送出される。その間に、第１の実施形態と同様に、ＶＴＲの利用者リストには、ＴＶ１０２（のノードＩＤである＃ｙ）が追加されてもよい。
【０１０４】
そして、ＶＴＲ１０１は再生動作を行い、ＩＥＥＥ１３９４を通して、ＡＶストリームがＴＶに対して送出され（Ｓ１８１８）、ＴＶ１０２は、これを受信／復号／表示して、ユーザに映像を表示することになる。
【０１０５】
この状態（図１９のＳ１９０１、Ｓ１９０２）で、ＴＶリモコンにはＶＴＲ制御画面が引き続き表示されていても良い（Ｓ１９０３）。
【０１０６】
この状態で、ＰＣのリモコンが図１８のＳ１８０１〜Ｓ１８１０と同様にＶＴＲの制御画面を表示し、ＰＣのユーザがＶＴＲの制御をしようとした（再生しようとした）とする（Ｓ１９０５）。
【０１０７】
ＰＣ１０３は、ＶＴＲ１０１に対して同時利用カウンタデクリメント要求を送出する（Ｓ１９０６）。
【０１０８】
これを受信したＶＴＲは、第１の実施形態と同様に、同時利用可能カウンタを参照し、現在ＴＶ１０２が使用中ということで、ＰＣ１０３の使用は不可であると判断して、第１の実施形態と同様に、「現在ノードＩＤ＝＃ｙのノードが使用中である」として、同時利用カウンタデクリメント要求に対する応答として、ＮＧを送る。
【０１０９】
ＰＣでは、第１の実施形態と同様に、このノードＩＤ（＃ｙ）が具体的にどこのどの様なノードであるかについての構成情報の入手を行い（Ｓ１９０８〜Ｓ１９０９）、ＰＣのディスプレイに現在使用可能な装置（ＴＶ１０２）をＰＣのユーザに提示することにより、ＰＣのユーザに「ＶＴＲを使いたい場合は、ここに行けば使うことが出来る」という情報を通知する。
【０１１０】
なお、本実施形態では、テレビ１０２を制御装置（本例ではＶＴＲを制御する）の一例として、ＰＣ１０３を制御装置（本例ではテレビがＶＴＲを制御中に同じＶＴＲを制御しようとする）の一例として説明したが、もちろん、いずれの装置も、前者および後者の両方になり得るので、両方にとっての機能を設けるのが好ましい。また、ＶＴＲ１０１を被制御装置の一例として、テレビ１０２とＰＣ１０３を制御装置の一例として説明したが、もちろん、制御装置と被制御装置の両方になり得る装置については、その両方にとっての機能を設けるのが好ましい。
【０１１１】
また、本実施形態では、アクセスされる装置の一例としてＶＴＲを、アクセスする装置（家庭ユーザがネットワークを介してサービスを利用するために操作する装置）の一例としてテレビとＰＣを用いたが、もちろん、本発明はこれらの装置に限定されず、どのような装置についても適用可能である。
【０１１２】
また、本実施形態では、ネットワークの一例としてＩＥＥＥ１３９４バスを用いたが、もちろん、本発明はこれに限定されず、どのようなネットワークについても適用可能である。
【０１１３】
また、本実施形態では、ホームネットワークを一例として取り上げたが、もちろん、本発明はこれに限定されず、オフィスや学校、店舗、その他の建物、施設等に設けられるネットワークについても適用可能である。
【０１１４】
なお、以上の各機能は、ソフトウェアとしても実現可能である。
【０１１５】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【０１１６】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１１７】
【発明の効果】
本発明によれば、より有効なユーザ・サポートを考慮した排他制御を行うことができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るホームネットワークの全体構成例を示す図
【図２】被制御機器の一例であるＶＴＲの内部構成例を示す図
【図３】属性情報レジスタの一例を示す図
【図４】制御権を取得する際の処理シーケンスの一例を示す図
【図５】制御画面の一例を示す図
【図６】制御権を取得する際の処理シーケンスの他の例を示す図
【図７】制御機器の一例であるＴＶにおける固定利用レジスタに関する処理手順の一例を示すフローチャート
【図８】使用確認要求に関する処理シーケンスの一例を示す図
【図９】制御機器の一例であるＴＶが使用確認要求を受信した際の処理手順の一例を示すフローチャート
【図１０】被制御機器の一例であるＶＴＲにおける処理手順の一例を示すフローチャート
【図１１】使用確認要求に関する処理シーケンスの他の例を示す図
【図１２】使用確認要求に関する処理シーケンスのさらに他の例を示す図
【図１３】使用確認要求に関する処理シーケンスのさらに他の例を示す図
【図１４】制御権が取得できなかった際にメッセージを呈示した画面の一例を示す図
【図１５】属性情報レジスタの他の例を示す図
【図１６】属性情報レジスタに対する処理の一例を示すフローチャートフローチャート
【図１７】属性情報レジスタのさらに他の例を示す図
【図１８】リモコンを使う場合で制御権を取得する際の処理シーケンスの一例を示す図
【図１９】リモコンを使う場合で制御権を取得できなかった際の処理シーケンスの一例を示す図
【符号の説明】
１００…ＩＥＥＥ１３９４バス
１０１…ＶＴＲ
１０２…テレビ
１０３…ＰＣ
１０４…ＴＶリモコン
１０５…ＰＣリモコン
２０１…ＩＥＥＥ１３９４インタフェース
２０２…ＶＴＲ処理部
２０３…ＡＶ／Ｃコマンド処理部
２０４…属性情報レジスタ
Claims (10)
- ネットワークに接続された通信装置であって、
前記ネットワークを通して自通信装置を制御する制御権を保有する他の装置の識別情報を記憶する記憶手段と、
前記記憶手段に前記識別情報が記憶されていないさらに他の装置から、自通信装置に対して制御権の取得を要求するメッセージを受信した際に、前記記憶手段に記憶されている前記識別情報の数が前記自通信装置を制御する制御権を同時に保有可能な他の装置の数に相当する、所定の数に達しているかを否か判定する判定手段と、
この判定手段により前記所定の数に達していないと判定された場合に、前記さらに他の装置の識別情報を前記記憶手段に追加するとともに、該さらに他の装置に制御権取得成功を通知するメッセージを送信する第１の処理手段と、
前記判定手段により前記所定の数に達していると判定された場合に、前記記憶手段に識別情報が記憶されている装置のうちに、その制御権を前記さらに他の装置に譲り渡すことのできるものが存在するか否かを調べる第２の処理手段と、
前記第２の処理手段によりその制御権を前記さらに他の装置に譲り渡すことのできる装置が見つかった場合に、該制御権を譲り渡す装置の識別情報を前記記憶手段から削除し前記さらに他の装置の識別情報を前記記憶手段に追加するとともに、該さらに他の装置に制御権取得成功を通知するメッセージを送信する第３の処理手段とを備えたことを特徴とする通信装置。 - 前記第２の処理手段は、自通信装置が現にデータをやり取りしている相手装置については、その制御権が維持されるべきものと判断することを特徴とする請求項１に記載の通信装置。
- 前記第２の処理手段は、自通信装置が最後にデータをやり取りしてから経過した時間が一定範囲以内である相手装置についても、その制御権が維持されるべきものと判断することを特徴とする請求項２に記載の通信装置。
- 前記第２の処理手段は、前記記憶手段に識別情報が記憶されている装置の少なくとも一部に対して、その制御権を維持するか否かを問い合わせるメッセージを送信し、その返答により該制御権が維持されるべきものか否かを判断する手段を含むことを特徴とする請求項１ないし３のいずれか１項に記載の通信装置。
- 前記第２の処理手段は、前記メッセージを送信する対象とし得る装置が複数存在する場合に、所定の選択基準で選択した順番で、前記メッセージの送信およびその返答による前記判断を行うことを特徴とする請求項１ないし４のいずれか１項に記載の通信装置。
- 自通信装置に対する制御権を保有する他の装置から該制御権を維持し続ける旨の特別のメッセージを受信した場合に、該他の装置の識別情報を登録する登録手段を更に備え、前記第２の処理手段は、前記登録手段に識別情報が登録されている装置については、その制御権が維持されるべきものと判断することを特徴とする請求項１ないし５のいずれか１項に記載の通信装置。
- 前記第２の処理手段によりその制御権を前記さらに他の装置に譲り渡すことのできる装置が見つからなかった場合に、前記さらに他の装置に制御権取得失敗を通知するメッセージを送信する第４の処理手段を更に備えたことを特徴とする請求項１ないし６のいずれか１項に記載の通信装置。
- 前記第４の処理手段は、前記さらに他の装置に制御権を保有する他の装置の識別情報を前記メッセージに含めて送信することを特徴とする請求項７に記載の通信装置。
- 自通信装置が複数の異なる装置またはサービスの形でネットワークに公開される場合には、公開された各装置またはサービス毎に、その制御権を保有する他の装置の識別情報を管理することを特徴とする請求項１ないし８のいずれか１項に記載の通信装置。
- 前記異なる装置またはサービスのうちの特定の２以上のものについて制御権保有可能な装置の数がそれらの総和として限定される場合には、該特定の２以上の装置またはサービスについては前記制御権を保有する他の装置の識別情報を統一して管理することを特徴とする請求項９に記載の通信装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP37337598A JP3613545B2 (ja) | 1998-12-28 | 1998-12-28 | 通信装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP37337598A JP3613545B2 (ja) | 1998-12-28 | 1998-12-28 | 通信装置 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004257416A Division JP2005094752A (ja) | 2004-09-03 | 2004-09-03 | 通信装置、通信方法及び通信制御プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000196636A JP2000196636A (ja) | 2000-07-14 |
| JP3613545B2 true JP3613545B2 (ja) | 2005-01-26 |
Family
ID=18502053
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP37337598A Expired - Fee Related JP3613545B2 (ja) | 1998-12-28 | 1998-12-28 | 通信装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3613545B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001230793A (ja) * | 1999-12-06 | 2001-08-24 | Sony Corp | 機器制御方法及び伝送装置 |
| JP4798676B2 (ja) * | 2001-01-09 | 2011-10-19 | シャープ株式会社 | 表示装置、録画再生システムおよび録画再生方法 |
| US7620713B2 (en) | 2002-04-23 | 2009-11-17 | Sharp Kabushiki Kaisha | Device control management apparatus |
| JP3842768B2 (ja) | 2003-08-26 | 2006-11-08 | 株式会社東芝 | サービス検索装置およびサービス検索方法 |
| JP2006033375A (ja) * | 2004-07-15 | 2006-02-02 | Mitsubishi Electric Corp | 車載マルチメディア制御システム |
| JP5042050B2 (ja) * | 2008-01-25 | 2012-10-03 | シャープ株式会社 | テレビジョン受像機、サーバ、テレビジョン受像機の操作システムおよびテレビジョン受像機の操作用プログラム |
| JP2013157962A (ja) * | 2012-01-31 | 2013-08-15 | Toshiba Corp | 電子機器、外部機器、電子機器の制御方法、電子機器の制御プログラム |
-
1998
- 1998-12-28 JP JP37337598A patent/JP3613545B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000196636A (ja) | 2000-07-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4059214B2 (ja) | 情報再生システムの制御方法、情報再生システム、情報提供装置、および情報提供プログラム | |
| EP1112650B1 (en) | A method and system for electronic communication | |
| US8713614B2 (en) | Audiovisual multi-room support | |
| EP1856891B1 (en) | System and method for providing "universal 'follow-me' functionality in a upnp av network | |
| JP3852892B2 (ja) | ネットワーク制御システム | |
| US8914464B2 (en) | Information processing device, information processing method, and information processing system | |
| JP5117603B1 (ja) | コンテンツ処理装置 | |
| JP2006227843A (ja) | コンテンツ情報管理システム、コンテンツ情報管理装置及びコンテンツ情報管理方法、並びにコンピュータ・プログラム | |
| WO1999059374A1 (fr) | Systeme de commande de reseau, unite de commande et dispositif associe | |
| JP5089916B2 (ja) | 制御装置及び制御方法 | |
| KR20110085520A (ko) | 멀티미디어 데이터 제공 시스템에서 컨텐츠 재생 방법 및 장치 | |
| JP2007184746A (ja) | リモコン・システム、リモコン制御対象機器、並びにコンピュータ・システム | |
| JP5314840B2 (ja) | コンテンツ再生装置及びコンテンツ再生方法 | |
| JP3850160B2 (ja) | ネットワーク制御システム、コントローラ、及びターゲット | |
| RU2518494C2 (ru) | Устройство обработки информации, способ обработки информации, система обработки информации и программа для них | |
| JP2007184745A (ja) | リモコン・システム、リモコン制御対象機器、並びにコンピュータ・システム | |
| JP3613545B2 (ja) | 通信装置 | |
| WO1999045699A1 (fr) | Systeme de commande de reseau, dispositif pour systeme de commande de reseau et controleur | |
| JP2003046958A (ja) | ビデオデータ格納装置及びビデオデータ取得装置 | |
| JPH1188865A (ja) | 分散型ホームネットワーク | |
| JP2007173918A (ja) | 録画予約システム | |
| JP2005094752A (ja) | 通信装置、通信方法及び通信制御プログラム | |
| JP2001045575A (ja) | ネットワーク制御システム、及びネットワーク制御システムに用いるデバイス並びにコントローラ | |
| JP4529478B2 (ja) | 情報再生システム、情報提供装置、情報再生方法および情報管理プログラム | |
| JP2008097625A (ja) | 表示制御装置、表示方法、およびプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040120 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040322 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040706 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040903 |
|
| A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20040928 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20041022 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041025 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071105 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081105 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091105 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |