(57)【要約】【課題】ネットワークに接続され、遠隔制御される遠隔装置間の接続の確立を容易にする。【解決手段】複数の遠隔装置間の接続を確立する接続確立装置は、複数の遠隔装置のそれぞれに対して割り当てられた所定のユニバーサルリソースロケータに基づき、接続された遠隔装置のそれぞれを、ハイパーテキスト転送プロトコルを用いて制御する遠隔制御手段を備える。所定のユニバーサルリソースロケータは、遠隔装置を識別する識別情報を前置して構成される。【選択図】図２
2010004569.tif 000002
【特許請求の範囲】
【請求項１】
複数の遠隔装置間の接続を確立する接続確立装置であって、
上記複数の遠隔装置のそれぞれに対して割り当てられた所定のユニバーサルリソースロケータに基づき、上記接続された遠隔装置のそれぞれを、ハイパーテキスト転送プロトコルを用いて制御する遠隔制御手段を備え、
上記所定のユニバーサルリソースロケータは、上記遠隔装置を識別する識別情報を前置して構成される接続確立装置。
【請求項２】
ハイパーテキスト転送プロトコルを用いて遠隔制御される請求項１記載の接続確立装置。
【請求項３】
ユーザインタフェースを介して直接制御される請求項２記載の接続確立装置。
【請求項４】
上記接続が確立される遠隔装置のそれぞれからユーザインタフェースをダウンロードするインタフェースを備え、
上記遠隔制御手段は、上記ダウンロードされたユーザインタフェース又は該ユーザインタフェースを修正したユーザインタフェースを表示する請求項２又は３記載の接続確立装置。
【請求項５】
上記ユーザインタフェースは、グラフィカルユーザインタフェースである請求項３又は４記載の接続確立装置。
【請求項６】
上記遠隔装置間で確立される接続は、通信帯域幅が保証されている請求項１乃至５いずれか１項記載の接続確立装置。
【請求項７】
上記遠隔装置間は、ＩＥＥＥ１３９４に準拠したバスを介して接続される請求項１乃至６いずれか１項記載の接続確立装置。
【請求項８】
上記遠隔装置を識別する識別情報は、該遠隔装置の名称である請求項１乃至７いずれか１項記載の接続確立装置。
【請求項９】
制御装置によって、複数の遠隔装置間の接続を確立する接続確立方法であって、
上記制御装置によって、上記複数の遠隔装置のそれぞれに対して割り当てられた所定のユニバーサルリソースロケータに基づき、上記接続された遠隔装置のそれぞれを、ハイパーテキスト転送プロトコルを用いて制御するステップを有し、
上記所定のユニバーサルリソースロケータは、上記遠隔装置を識別する識別情報を前置して構成される接続確立方法。
【請求項１０】
上記制御装置は、ハイパーテキスト転送プロトコルを用いて遠隔制御される請求項９記載の接続確立方法。
【請求項１１】
上記制御装置は、ユーザインタフェースを介して直接制御される請求項１０記載の接続確立方法。
【請求項１２】
上記制御装置によって、上記接続が確立される遠隔装置のそれぞれからユーザインタフェースをダウンロードするステップを有し、
上記制御装置によって、上記ダウンロードされたユーザインタフェース又は該ユーザインタフェースを修正したユーザインタフェースを表示する請求項１０又は１１記載の接続確立方法。
【請求項１３】
上記ユーザインタフェースは、グラフィカルユーザインタフェースである請求項１１又は１２記載の接続確立方法。
【請求項１４】
上記遠隔装置間で確立される接続は、通信帯域幅が保証されている請求項９乃至１３いずれか１項記載の接続確立方法。
【請求項１５】
上記遠隔装置間は、ＩＥＥＥ１３９４に準拠したバスを介して接続される請求項９乃至１４いずれか１項記載の接続確立方法。
【請求項１６】
上記遠隔装置を識別する識別情報は、該遠隔装置の名称である請求項９乃至１５いずれか１項記載の接続確立方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、遠隔装置の接続確立方法及び接続確立装置に関し、詳しくは、ハイパーテキスト転送プロトコルを用いた遠隔装置の接続確立方法及び接続確立装置に関する。
【背景技術】
【０００２】
インターネットを利用し、ＨＴＴＰ（hyper text transfer protocol：以下、ＨＴＴＰという。）を用いて遠隔装置を制御する方法が知られている。あるインターネットサイトは、別のチャンネルに切り換えることによって選択が可能な様々な情報をインターネットを介して放送する、オーディオチューナや、テレビジョン受像機等のオーディオ−ビデオ装置（ＡＶ装置）の制御の仕方をデモンストレーションしている。このようなシステムの一例を図１０に示す。ここでは、ＨＴＴＰによるラジオ放送を制御するシステムを示している。
【０００３】
ソース装置であるラジオ送信機３０は、http//www.chilton.com.sctipts/radio/R8-receiverといったユニバーサルリソースロケータ（universal resource locator：以下、ＵＲＬという。）を有するターゲット装置（ここではサーバ３１）に、複数のサービスを提供するためのアナログ信号を供給する。サーバ３１は、マイクロコントローラ及びＨＴＴＰサーバ３３を有しており、このため、インターネットを介してラジオ送信機３０から入手できる様々なサービス内容のうちの１つを選択し、それをインターネットに出力することができる。この例においては、ＨＴＴＰは、転送プロトコルとして用いられている。
【０００４】
マイクロコントローラ及びＨＴＴＰサーバ３３は、サーバ３１のＵＲＬを選択している全てのインターネットユーザに対するグラフィカルユーザインタフェースを有する。また、インターネットユーザの側では、サーバ３１への非同期接続を行うためには、例えばウェブブラウザ等を表示できるコントローラ３２を備える必要がある。この非同期ポイントツーポイント（point-to-point）接続は、オーディオデータ及びＨＴＴＰ制御プロトコルについて行われている。
【０００５】
また、インターネットにおいて、例えば２つのＨＴＴＰサーバ等の２つの遠隔装置間で接続が行われることも知られている。このような接続の例を図１１に示す。インターネットユーザは、サーチエンジン機能を有するＨＴＴＰサーバ３３であるターゲット装置３５に接続する。ターゲット装置３５への接続は、ターゲット装置３５を制御し、ターゲット装置３５から、インターネットユーザの、例えばウェブブラウザであるコントローラ３２にデータを取り込むための非同期接続である。また、ＨＴＴＰサーバ３３、すなわちターゲット装置３５は、それ自体では所望のデータを供給できない場合もある。この場合、このターゲット装置３５は、サーチエンジンとして機能する別のＨＴＴＰサーバ３４に第２の非同期接続を行う。このように、ＨＴＴＰサーバ３４とＨＴＴＰサーバ３３（ターゲット装置３５）のように２つの遠隔サーバ間の接続は、インターネットユーザによって制御されるのではなく、インターネットユーザに選択されたターゲット装置３５自身によって制御されている。図１１に示す例では、インターネットユーザは、ウェブブラウザとして機能するコントローラ３２を利用し、"www.Yahoo.com"というＵＲＬを有するターゲット装置３５のYahooに接続し、また、ターゲット装置３５であるYahooは、"www.Altavista.digital.com"というＵＲＬを有する、ソースサーバであるアルタビスタに接続する。
【０００６】
図１０及び図１１に示すいずれの例においても、制御データ以外に、オーディオデータや検索データも、帯域幅の保証されていない従来の伝送制御プロトコル／インターネットプロトコル（Transmission Control Protocol：以下、ＴＣＰ／ＩＰという）接続によって伝送されている。このため、例えばＨＴＴＰを用いてターゲット装置３５が制御された後、さらに所望の情報も、インターネット経由で、ＨＴＴＰを用いたユーザのウェブブラウザ、すなわちコントローラ３２に送信される。つまり、ＨＴＴＰ接続の帯域幅が保証されていないので、長い待ち時間が生じることがしばしばある。
【０００７】
一方、ネットワーク環境においては、オーディオ／ビデオソース装置とターゲット装置との間の相互運用性が求められ、例えばＩＥＥＥ１３９４によって定められたような通信機構を有し、保証された帯域幅を有する装置間での通信が可能であることも知られている。このようなネットワーク環境の例を図９に示す。ＩＥＥＥ１３９４は、接続されたソース装置とターゲット装置間の通信帯域幅を保証するアイソクロノスチャンネルを定めている。さらに、システム固有の制御プロトコルのポイントツーポイント接続を提供する非同期チャンネルがある。ここでは、例えば、デジタルＶＴＲ（video tape recorder：以下、ＶＴＲという。）、デジタルビデオ放送（digital video broadcast：以下、ＤＶＤという。）チューナ、デジタルオーディオ放送（digital audio broadcast：以下ＤＡＢという。）チューナ等の様々なシステム固有のプロトコルが定められており、様々な種類の対応する装置を制御できるようになっている。
【０００８】
図９に示す遠隔装置２１Ａは、チューナ装置として機能し、遠隔装置２１Ｂは、ストレージ装置として機能する。遠隔装置２１Ａ、遠隔装置２１Ｂのいずれも、ＩＥＥＥ１３９４ネットワークのアイソクロノスチャンネルに接続された論理インタフェース２４を有する。また、遠隔装置２１Ａ、遠隔装置２１Ｂのいずれも、それらの装置を制御するマイクロプロセッサ２９を有する。またさらに、遠隔装置２１Ａ、遠隔装置２１Ｂのいずれも、ＩＥＥＥ１３９４ネットワークの非同期チャンネルを通してコントローラ２２に接続された論理インタフェースを有する。遠隔装置２１Ａ、遠隔装置２１Ｂを制御する多機能のコントローラ２２は、全てのシステム固有のプロトコルに対応する必要があり、そのため、比較的複雑な構造を有している。さらに、異なる種類の遠隔装置２１Ａ及び遠隔装置２１Ｂは、非同期チャンネルを通して送信されるシステム固有の制御プロトコルをそれぞれ必要とするので、別の種類の装置を追加する場合には、通常、対応するコントローラ２２をアップグレードしなければならない。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特表２００２−５１０４１５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
上述のように、ＩＥＥＥ１３９４ネットワークシステムに接続された各種の遠隔装置は、それぞれ固有の制御プロトコルを必要とする。コントローラ２２は、全ての制御プロトコルに対応する必要があり、したがって、ユーザ側で全ての機器を制御できるようなコントローラ２２を設計することは容易ではない。また、１つの種類のシステムを想定した、所謂システム専用のコントローラが用いられることから、１つのコントローラが全てのシステムを制御することも難しい。
【００１１】
さらに、システム固有のプロトコルは、装置の下位レベルの機能を制御することを目的として定められているので、このようなプロトコルは、比較的柔軟性がない。このため、ＩＥＥＥ１３９４ネットワーク上の遠隔装置２１Ａ、遠隔装置２１Ｂをアップグレードする際には、既存のプロトコルを拡張しなければならず、また、遠隔装置２１Ａ、遠隔装置２１Ｂに関連するコントローラ２２もアップグレードしなければならない。
【００１２】
さらに、ＩＥＥＥ１３９４ネットワークに新たな遠隔装置を追加する場合、コントローラ２２を新しいシステム固有のプロトコルに対応させるか、あるいは新しい遠隔装置を既存のプロトコルに対応させる必要がある等の制約が生じる。システム固有のプロトコルは、上述のように、柔軟性に劣るため、コントローラ２２の設計によっては、遠隔装置の機能や操作性が十分に発揮されない場合もある。このような理由から、ＩＥＥＥ１３９４ネットワークへの対応に消極的な製造業者もあり、したがって、互換性のないネットワークプロトコルが増加し、ネットワークに接続された装置間の相互運用（interoperability）に問題が生じることもある。
【００１３】
上述のような問題は、現在インターネットにおいて行われているＨＴＴＰを用いた装置制御によって解決される。しかしながら、その場合、２つの遠隔装置間に確立される接続を直接制御することはできず、また、オーディオデータやビデオデータといった所望のデータは、十分な帯域幅を保証していない接続を介して伝送されるため、ネットワーク混雑時には、データフローが不連続となり、オーディオ／ビデオの再生が途切れがちとなる。
【００１４】
本発明は、上述の課題に鑑みてなされたものであり、ネットワークに接続され、遠隔制御される遠隔装置間の接続を容易に確立するための接続確立方法及び接続確立装置を提供することを目的とする。
【課題を解決するための手段】
【００１５】
上述の課題を解決するために、本発明に係る、制御装置によって、複数の遠隔装置間の接続を確立する接続確立方法は、制御装置によって、複数の遠隔装置のそれぞれに対して割り当てられた所定のユニバーサルリソースロケータに基づき、接続された遠隔装置のそれぞれを、ハイパーテキスト転送プロトコルを用いて制御するステップを有する。所定のユニバーサルリソースロケータは、遠隔装置を識別する識別情報を前置して構成される。ここで、遠隔装置は、コントローラにより制御され、コントローラはハイパーテキスト転送プロトコルを用いて遠隔装置を制御する。また、コントローラは、ハイパーテキスト転送プロトコルを用いて遠隔的に制御されるか、あるいは、コントローラに備えられたユーザインタフェースを介して制御される。さらに、遠隔装置間の接続においては、好ましくは帯域幅を保証する。
【００１６】
本発明では、複数のシステム固有プロトコルの代わりに、ハイパーテキスト転送プロトコル、すなわちＨＴＴＰを用いて複数の遠隔装置間の接続を確立する。各遠隔装置は、インターネットサーバのように機能して、特定の制御機能に対応したメニューの選択肢を提供できる。コントローラは、ハイパーテキスト転送プロトコルをサポートしていればよいため、コントローラの設計が非常に簡単になる。ネットワークに遠隔装置を追加する場合、コントローラに新しい制御プロトコルを追加する必要はない。ネットワークのアップグレードを行うには、コントローラにより制御される各遠隔装置からコントローラ内に、ユーザインタフェースをダウンロードし、ダウンロードしたインタフェースを表示することにより、ユーザは遠隔装置を制御することができる。
【００１７】
また、本発明に係る、複数の遠隔装置間の接続を確立する接続確立装置は、複数の遠隔装置のそれぞれに対して割り当てられた所定のユニバーサルリソースロケータに基づき、接続された遠隔装置のそれぞれを、ハイパーテキスト転送プロトコルを用いて制御する遠隔制御手段を備える。所定のユニバーサルリソースロケータは、遠隔装置を識別する識別情報を前置して構成される。制御インタフェースは、ユーザインタフェースを格納しており、このユーザインタフェースは、好ましくは、グラフィカルユーザインタフェースである。本発明に係る遠隔装置は、このようなユーザインタフェースによって、効果的にＨＴＴＰサーバとしての機能を果たす。この場合、コントローラを介してユーザが遠隔装置にアクセスしたときに、制御インタフェースに格納されたユーザインタフェースは遠隔装置からコントローラにダウンロードされる。そうして、ユーザは自ら操作する制御装置を介して遠隔装置の全ての機能にアクセスすることができる。
【発明の効果】
【００１８】
以上のように、本発明に係る接続確立方法及び接続確立装置によれば、複数の遠隔装置間の通信において、複数のシステム固有プロトコルの代わりに、ハイパーテキスト転送プロトコル、すなわちＨＴＴＰを用いて遠隔装置間の接続を確立する。
【図面の簡単な説明】
【００１９】
【図１】本発明を適用したＩＥＥＥ１３９４ネットワークの構成を示す図である。
【図２】図１の各機器のＩＰアドレスの割当を説明する図である。
【図３】ホームネットワークのＤＮＳサーバの初期化処理を示す図である。
【図４】ＤＮＳサーバによる外部リクエストを説明する図である。
【図５】ＨＴＴＰサーバ初期化を説明する図である。
【図６】ユーザコマンドに基づくネットワーク機器の処理を示すフローチャートである。
【図７】拡張されたネットワークの論理的接続状態を示す図である。
【図８】本発明を適用したネットワーク環境の物理的接続状態を示す図である。
【図９】従来のＩＥＥＥ１３９４ネットワーク構成を示す図である。
【図１０】インターネットを用いてラジオ放送を制御する従来の手法を説明する図である。
【図１１】インターネット上の２つの遠隔装置間に確立される従来の式自動接続を説明する図である。
【発明を実施するための形態】
【００２０】
以下、本発明に係る遠隔装置の接続確立方法及び接続確立装置について、図面を参照して詳細に説明する。
【００２１】
図１は、本発明を適用したＩＥＥＥ１３９４ネットワークの構成を示す図である。図１に示す遠隔装置１Ａ、遠隔装置１Ｂ及び遠隔装置１Ｃ（以下、個別に説明する場合を除いて遠隔装置１と総称する。）は、保証された帯域幅のオーディオ／ビデオデータを通信するために、それぞれの遠隔装置自体に含まれるデータインタフェース４を介して、アイソクロノス接続ライン５に接続されている。このようなアイソクロノス接続は、ＩＥＥＥバスシステムを用いて実現することができる。また、帯域幅を保証した接続ではなく、非同期接続を行ってもよい。また、遠隔装置１Ａ、１Ｂ、１Ｃは、それぞれ、制御インタフェース、すなわちハイパーテキスト転送プロトコルサーバ３（以下、ＨＴＴＰサーバ３ともいう。）を有し、それらを介して、コントローラ２との非同期接続を確立する。
【００２２】
ハイパーテキスト転送プロトコルサーバ３は、少なくともマイクロコントローラと、メモリとを有する。このような非同期接続は、機器制御プロトコルのためのポイントツーポイント接続である。図１に示すＩＥＥＥ１３９４ネットワークにおいては、ハイパーテキスト転送プロトコル、すなわちＨＴＴＰが、機器制御プロトコルとして用いられる。各遠隔装置１Ａ、１Ｂ、１Ｃ内の、マイクロコントローラ及びメモリを有するＨＴＴＰサーバ３は、遠隔装置１Ａ、１Ｂ、１Ｃをそれぞれ制御し、例えば遠隔装置１Ａ、１Ｂ、１Ｃのそれぞれの論理インタフェース４及びそれぞれの処理を制御するゲートウェイとして機能する。
【００２３】
なお、この実施の形態においては、遠隔装置１Ａは、同時に放送されている複数の放送サービスのうちの１つを選択するチューナ装置として機能し、遠隔装置１Ｂは、放送サービス等の信号に基づくデータを記録又は記憶するストレージ装置として機能する。また、遠隔装置１Ｃは、放送サービス等を表示する表示装置として機能する。
【００２４】
遠隔装置１Ａは、複数の入力信号のうちの１つを選択するスイッチ６を有する。遠隔装置１ＡのＨＴＴＰサーバ３は、遠隔装置１Ａ内の処理と、遠隔装置１Ａのデータインタフェース４とを所定のアルゴリズムに基づいて制御し、スイッチ６は、コントローラ２及び遠隔装置１ＡのＨＴＴＰサーバ３を介して、ユーザによって制御される。さらに、遠隔装置１Ｂにおいて、記録媒体７自身と、遠隔装置１Ｂ内の処理とが、所定のアルゴリズムに基づいて制御され、また、ある接続されたアイソクロノス接続ライン５のデータの記録又は再生の開始及び終了の選択が、コントローラ２及び遠隔装置１ＢのＨＴＴＰサーバ３を介して、ユーザによって行われる。
【００２５】
図１に示す例においては、遠隔装置１Ｃも、アイソクロノス接続ライン５と、コントローラ２とに接続されている。この遠隔装置１Ｃは、コントローラ２とは非同期接続によって接続されている。遠隔装置１Ｃは、遠隔装置１Ｂと同じプロトコル、すなわちＨＴＴＰにより、同じコントローラ２によって制御されるが、選択されたアイソクロノス接続のデータは、記録されずに表示される。図１に破線で示すように、このような表示装置である遠隔装置１Ｃは、必ずしも非同期接続である必要はなく、また、必ずしもＨＴＴＰを用いて制御される必要はない。
【００２６】
コントローラ２には、そこに接続されている遠隔装置１Ａ、１Ｂ、１Ｃを制御するために、ユーザからアクセスできるようになっている。帯域幅を保証した接続でのデータ放送のために遠隔装置１Ａ、１Ｂ、１Ｃが用いるアイソクロノスチャンネルは、そのときの許容能力とは全く関係なく、システム自身によって選択されるので、そうした選択にとらわれることなく、ユーザは、遠隔装置１Ａ、１Ｂ、１Ｃのそれぞれを十分に制御することができる。
【００２７】
図１に示す実施の形態においては、ユーザは、スイッチ６を制御して、遠隔装置１Ａに入力される複数の放送サービスのうちのいずれかを選択して、アイソクロノス接続ライン５に供給する。遠隔装置１Ｂは、接続されているアイソクロノス接続ライン５の１つを選択するように、ユーザによって制御され、選択されたアイソクロノス接続ライン５に供給されたデータは、処理されて、記録媒体７に記録される。
【００２８】
この実施の形態においては、遠隔装置１Ａ、１Ｂ、１Ｃは、同一のプロトコル、すなわちＨＴＴＰ等のハイパーテキスト転送プロトコルを用いて、それぞれ独立して制御されるので、システムに接続された遠隔装置１Ａ、１Ｂ、１Ｃの全てに特別に適合したコントローラ２、又は各遠隔装置１Ａ、１Ｂ、１Ｃ毎にそれぞれ異なるコントローラ２を必要としない。コントローラ２は、非同期接続のみに対応した比較的安価な装置であってもよい。各遠隔装置１向けに特別に設計された制御プロトコルを用いることなく、ＨＴＴＰを用いることで、コントローラ２は、効率良くウェブブラウザとしての機能を果たすことができる。既存のウェブブラウザを使用できるようにするためには、現在インターネットで用いられているのと同じプロトコル、すなわちＴＣＰ／ＩＰ及びＨＴＴＰを用いればよい。
【００２９】
図１においては、非同期接続とアイソクロノス接続を別々に示しているが、実際のシステムにおいては、ＩＥＥＥ１３９４システムにおいてもそうであるように、いずれの種類の接続も同じケーブルによってサポートされている。ＩＥＥＥ１３９４においては、ＩＥＥＥ１３９４接続の最上層のインターネットプロトコル（internet protocol：以下、ＩＰという。）をサポートするための手法が定められている。これにより、ＴＣＰ接続及びＨＴＴＰ接続もサポートすることができる。また、ドメインネームシステム（domain name system：以下、ＤＮＳという。）等のネームシステムにより、遠隔装置へのドメインネームの割当が可能となり、また、ＩＰアドレス、ネットマスク又はＤＮＳネームサーバの自動割当のためのプラグアンドプレイ動作を改良するための、他のプロトコルを導入してもよい。この場合、動的ホスト構成プロトコル（dynamic host configuration protocol：以下、ＤＨＣＰという。）又はＤＨＣＰプロトコルに類似するプロトコルを使用する。
【００３０】
図２は、本発明の原理に従い、遠隔装置１Ａ、１Ｂ、１Ｃ及びコントローラ２（インタフェース２ａ、２ｂ）に対するＩＰアドレスの割当を説明する図である。
【００３１】
ＩＥＥＥ１３９４バスシステムは、現在、民生用オーディオ／ビデオ機器の接続に用いられている。しかしながら、本発明においては、このような遠隔装置を、例えばソフトウェアのアップグレードのために、インターネットサーバに接続する目的で、また、ユーザが、コントローラ２を用いて、従来のＩＥＥＥ１３９４によるサービスを制御して見ると同時に、同じコントローラ２を用いて、インターネットサービスを選択してアクセスする目的で、また、例えば旅行中のユーザがインターネットを介して自分のホームネットワーク装置にアクセスする必要があるために、インターネットに接続する目的で、ＩＥＥＥ１３９４バスシステムを利用することができる。
【００３２】
このような様々な目的を実現するためのネットワークの初期化処理について説明する。以下に説明する具体例においては、図８に示すように、コントローラ２は、インターネットへのゲートウェイとして機能するパーソナルコンピュータ又はそれに類する装置である。インターネットへの接続は、周知の通り、例えば電話モデム又はケーブルモデムによってサポートすることができる。以下、図９を用いて、従来のネットワーク初期化後のブート処理の手順について説明する。
【００３３】
図９は、初期化されるＩＥＥＥ１３９４ネットワークを示す。例えばチューナ装置として機能する遠隔装置２１Ａと、ストレージ装置として機能する遠隔装置２１Ｂといった２つの遠隔装置は、それぞれの論理インタフェース２４を介して、ＩＥＥＥ１３９４ネットワークのアイソクロノス接続ライン２５に接続されている。さらに、これらの遠隔装置２１Ａ、２１Ｂは、論理インタフェース２４と、ＩＥＥＥ１３９４ネットワークの非同期接続とを介してコントローラ２２に接続されている。また、それぞれの種類の遠隔装置２１Ａ、２１Ｂが有する制御コマンドのセットは異なるので、遠隔装置２１Ａと遠隔装置２１Ｂにコントローラ２２を適合させる必要がある。コントローラ２２は、遠隔の表示入力装置２８にアクセスすることができ、あるいは、表示入力装置２８をコントローラ２２内に組み込むようにしてもよい。
【００３４】
従来のＩＥＥＥ１３９４ネットワークの初期化は、電源を入れた後又は再初期化の後に行われる。ここでは、ネットワークに接続されている全ての装置が、最適な状態にブートされる。ここでは、ブートを完了させるために、例えば、アイソクロノスリソースマネージャのようなマスタ装置を識別する処理、及びnode_idsを割り当ててＩＥＥＥ１３９４非同期接続をセットアップする処理が実行される。この手順は、ＩＥＥＥ１３９４仕様書に記載されている。このトランスポート層を確立した後、ネットワークに接続された装置は、それぞれ他の装置と接続してデータの送受信を行い、それらの機能についての情報を収集し、あるいは、ネットワークの接続状態を調査する。このような情報は、各遠隔装置にデータとして格納されており、基本的な通信をサポートしている。さらに、より後の段階において、ユーザに各装置の機能を通知するための情報も格納されている。
【００３５】
本発明によれば、ブート手順の第１段階においては、ＩＥＥＥ１３９４について上述したような従来のネットワーク初期化が行われる。このようなＩＥＥＥ１３９４トランスポート層が確立された後に、インターネットプロトコル（internet protocol：以下、ＩＰという。）ネットワークの初期化が開始される。プラグアンドプレイを最大限にサポートするために、例えばＩＰアドレス及びＩＰネットマスク等のパラメータを自動的に割り当てる必要がある。
【００３６】
また、ルータを介して遠隔のインターネットサイトにアクセスしなければならない装置においては、デフォルトのＩＰアドレスを知ることが必要である。基本的なＩＰファミリに加えて、このようなパラメータを自動的に割り当てる必要がある場合、例えばＤＨＣＰ等のプロトコルを用いる。単純なＩＥＥＥ１３９４ネットワークにおいては、規格化されたＩＰアドレス割当規則のようなものがあれば、ＤＨＣＰのようなプロトコルを使用する必要はない。
【００３７】
ＩＰアドレスは、ＩＥＥＥ１３９４による全世界で重複しない、すなわち固有のＩＤにより構成される。したがって、ＩＰアドレスは、ローカルエリア内でも固有のＩＤを保証する。また、固定されたネームサーバ及びデフォルトルータがＩＰ装置のそれぞれにエントリすることを可能にするために、ネームサーバ及びデフォルトルータは、規格化されたＩＰアドレスを採用する。複数の役割を有する装置は、必要に応じて、そのインタフェースに複数のＩＰアドレスを割り当てることができる。
【００３８】
図２に示す例においては、チューナ装置として機能する遠隔装置１Ａは、この遠隔装置１Ａが備えるＨＴＴＰサーバ３に以下のアドレスを割り当てる。
デフォルトルータ： 192.168.0.1
ＤＮＳサーバ： 192.168.0.1
ネットマスク： 255.255.255.0
ＩＰアドレス： 192.168.0.2
一方、ストレージ装置として機能する遠隔装置１Ｂは、この遠隔装置１Ｂが備えるＨＴＴＰサーバ３に以下のアドレスを割り当てる。
デフォルトルータ： 192.168.0.1
ＤＮＳサーバ： 192.168.0.1
ネットマスク： 255.255.255.0
ＩＰアドレス： 192.168.0.3
そして、インターネットへのゲートウェイとしての役目も果たし、表示入力装置８にアクセスするコントローラ２は、２つのインタフェース２ａ、２ｂを備える。ＤＮＳサーバ及びホームネットワークのＤＨＣＰサーバに対する内部インタフェース２ａのアドレスは、以下の通りである。
【００３９】
ＩＰアドレス： 192.168.0.1
ネットマスク： 255.255.255.0
ＤＮＳサーバ： 192.168.0.1
一方、インターネットと通信を行う外部インタフェース２ｂのアドレスは、以下の通りである。
【００４０】
ＩＰアドレス： 192.109.206.33
ネットマスク： 255.255.255.0
ディフォルトルータ： 192.109.206.1
システムをより単純化するために、これらのアドレスは、将来的な規格に基づいて、固定アドレスとしてもよいが、例えばＤＨＣＰによるＩＰネットワークの初期化中に、それらのアドレスを割り当てることもできる。
【００４１】
インターネットに外部接続する下位層、例えばポイントツーポイントプロトコル（point to point protocol：以下、ＰＰＰという。）又は電話回線が、ＩＰトラフィックをサポートするために必要である。ネットワーク初期化のこの部分は、既に標準化されているので、ここでは説明を省略する。
【００４２】
ＤＨＣＰプロトコルを用いる場合、ネットワークの初期化は、どの装置がＤＨＣＰサーバとして機能するかの条件によって決定される。ウェブブラウザによってＨＴＴＰ制御をサポートするためにＩＰスタックが必要とされるだけの場合、少なくとも１つのＨＴＴＰサーバと少なくとも１つのＨＴＴＰクライアントとがネットワークに接続されている場合、ＩＰスタックが必要とされる。ホームネットワークにおいては、ソース及びターゲットの遠隔装置の総数は、通常、コントローラの総数よりも多い。
【００４３】
ネットワークが、ＨＴＴＰクライアントとして機能する１つのコントローラ２と、ＨＴＴＰサーバとして機能する数個のソース及びターゲットの遠隔装置、すなわち遠隔装置１Ａ、１Ｂとを備えている場合、コントローラ２は、全ての遠隔装置１Ａ、１ＢとＨＴＴＰセションを行う。したがって、他の遠隔装置への依存性を制限するために、この実施の形態においては、コントローラ２にＤＨＣＰサーバを設けている。
【００４４】
なお、例えば、インターネットからコントローラ２以外の装置、すなわち遠隔装置１Ａ、１Ｂに新たな制御ソフトウェアをダウンロードする場合、及びコントローラ２がインターネットへのゲートウェイでない場合には、好ましくは、コントローラ２以外の装置にＤＨＣＰサーバを設ける。
【００４５】
ホームネットワークにおいて、インターネットによるＩＰトラフィックをサポートするためには、適切なルーチング及びアドレス値が必要である。多数のホームネットワークとそれに含まれる更に多数の装置があることを考慮すると、登録できるインターネットアドレスには限りがあることから、それらをホームネットワーク内で用いることは不可能である。したがって、この目的のために、インターネット技術タスクフォース（internet engineering task force：以下、ＩＥＴＦという。）によって割り当てられる特別の「プライベート」アドレス（例えば192.168.0.0〜192.168.255.255）を用いなければならない。これらのアドレスは、インターネット上に存在しないので、プライベートネットワークにおいて利用及び再利用することができる。
【００４６】
図２においては、ＤＨＣＰサーバは、この範囲内のアドレス、例えば192.168.0.0を使用している。さらに、ローカル的に固有のアドレスを割り当てるだけではなく、ＤＨＣＰサーバは、３バイトのネットマスクと、デフォルトルータのＩＰアドレス、すなわち192.168.0.1と、ネームサーバ、すなわち192.168.0.1とをホームネットワーク上の各遠隔装置、すなわち遠隔装置１Ａ、１Ｂに割り当ている。
【００４７】
コントローラ２は、インターネットへのゲートウェイとして機能するには、特別のＩＰ構成を必要とする。コントローラ２は、インターネットに登録されたアドレスを有する更なるＩＰインタフェース、すなわち外部インタフェース２ｂを有しており、これにより、コントローラ２は、外部のインターネットサイトと通信することができる。
【００４８】
図２に示す実施の形態では、ＩＰアドレスは、192.109.206.33.である。この目的のために、コントローラ２は、インターネット上のルータを表す異なるデフォルトルータのアドレスが必要である。このようなパラメータの値は、用いているＩＳＰ（インターネットサービスプロバイダ）のゲートウェイによって決まる。ホームネットワークのＤＨＣＰサーバが、このようなパラメータを、ホームネットワーク上の遠隔装置１Ａ、１Ｂに割り当てるのと同時に、ＩＳＰもＤＨＣＰサーバを用いて、ホームネットワークの外部インタフェース２ｂに適切なＩＰパラメータを割り当てることができる。
【００４９】
図２において、ＩＳＰのＤＨＣＰサーバは、コントローラ２の外部インタフェース２ｂに192.109.206.33というアドレスを割り当てている。さらに、ＩＳＰは、ホームネットワークのゲートウェイに、そのデフォルトルータとして、192.109.206.1を用いるように指示している。
【００５０】
ＩＰ構成の後、ホームネットワークのゲートウェイは、ＩＰパケットを外部に送信するために、あらゆる内部ＩＰアドレスを外部ＩＰアドレスに変換し、また、外部からＩＰパケットを受信するために、これと逆の変換を行う。
【００５１】
遠隔装置１Ａ、１Ｂ及びコントローラ２をアドレスのみで識別する代わりに、遠隔装置１Ａ、１Ｂ又はコントローラ２を示す名称を用いることができる。インターネットにおいては、ＩＰアドレスを用いたアドレス割当に加えて、名称によるアドレス割当が望ましいとされる理由は、４つある。
【００５２】
まず第１に、ユーザにとっての利便性を向上させるために、各装置は、それに関連した適切な名称を有するべきであるという理由である。
【００５３】
第２に、ＩＰアドレスの割当は動的であるので、ウェブブラウザ上では、分からないようにするべきであるという理由である。
【００５４】
また、そのようなＩＰアドレスが仮に固定されていたとしても、携帯型のコントローラが、このようなＩＰアドレスにブックマークを付した場合、インターネットは、そのようプライベートアドレスをサポートしていないので、携帯型のコントローラは、外部ネットワークからそのブックマークを使用することはできない。言い換えれば、ローカルホームネットワークのＩＰアドレスが有効なのは、このローカルホームネットワーク環境内においてのみである。この場合の携帯型のコントローラは、ホームネットワークから遠隔のインターネット接続に移動できる携帯端末装置である。ローカルホームネットワークのＩＰアドレスをサポートするためには、携帯端末装置は、ホームネットワークの外部ＩＰアドレスを把握しなければならない。また、この外部ＩＰアドレスは、インターネットサービスプロバイダによって動的に割り当てられるので、ブックマークとして使用することは困難である。以上が第３の理由である。
【００５５】
また、第４に、同種のサービスを提供している複数の装置が含まれているシステムにおいては、この名称を異なるＩＰアドレスにマッピングするよりも、同種のサーバ名を用いた方が好ましい場合があるという理由である。この手法の利点は、複数のクライアントが集中することによる負担を、複数のサーバに分散させることができるという点である。
【００５６】
これらの状況に対応するために、ホームネットワークは、ＤＮＳ、すなわちドメインネームシステムを用いているが、このドメインネームシステムにおいては、名前を適切なＩＰアドレスに変換するネームサーバが用いられる。ドメインネームシステムが、ある装置にその名前によってアクセスしようとする場合、まずそのネームサーバにコンタクトしなければならない。ネームサーバは、適切なＩＰアドレスを返し、それを用いることで以後の通信が可能となる。
【００５７】
本発明による、ＤＮＳを用いたホームネットワークを図３に示す。図３に示す構成例では、コントローラ２は、ＤＮＳサーバとしても機能し、遠隔装置１Ａ、１ＢのＨＴＴＰサーバ３のマイクロプロセッサのそれぞれは、更なるエントリ、すなわちＩＥＥＥ１３９４装置記述名のような、チューナ装置、ストレージ装置、コントローラ等の装置の種類を示す装置記述名を有している。
【００５８】
図２に示すコントローラ２のアドレスに加えて、図３に示すコントローラ２は、さらに、ドメインno29.bahnstrasse.bonn.deに対応するＤＮＳサーバ及び以下のようなＤＮＳデータベースを有している。
【００５９】
サブドメイン    内部装置への応答    外部装置への応答
チューナ          192.168.0.2        192.109.206.33
ストレージ        192.160.0.3        192.109.206.33
コントローラ      192.160.0.1        192.109.206.33
ここで、また、更なる装置は、２つのアドレスに割り当てられたその名前を有するエントリを有している。
【００６０】
インターネット内の装置が遠隔のホームネットワークにアクセスする必要がある場合、この装置は、遠隔のホームネットワークが接続しているインターネットサービスプロバイダと通信する必要がある。図３に示すように、このホームネットワークが、例えばボンにある場合、インターネットサービスプロバイダは、例えば"no29.bahnstrasse.bonn.de"のようなホームネットワークの所在地に関連した名称を割り当てる。
【００６１】
インターネットサービスプロバイダから与えられたドメインネーム（no29...）を用いて、コントローラ２内のホームネットワークのＤＮＳサーバは、ホームネットワーク内の遠隔装置、すなわち遠隔装置１Ａ、１Ｂに固有の名前を割り当てることができ、これらの名前は、完全修飾ドメインネームである。ＩＥＥＥ１３９４仕様書において既に装置名の規定がなされている場合、ホームネットワークのＤＮＳサーバは、ＩＥＥＥ１３９４規格によって定められたこのような装置名を使用し、その名称をホームネットワークのドメインネームに前置することができる。例えば、装置がＩＥＥＥ１３９４ネットワークにおいて"storage"という名称で呼ばれている場合、ＤＮＳサーバは、これを、例えば、"storage.no29.bahnstrasse.bonn.de"のようにそれぞれの装置を表すサブドメイン識別子として用いることができる。また、所定のドメインネームは、このように自動的に割り当ててもよく、あるいは、ホームネットワークのオペレータが任意に割り当ててもよい。
【００６２】
これらのデータ、すなわち、ＩＥＥＥ１３９４ネットワークによって定められた装置記述名と、ホームネットワークのＤＨＣＰサーバによって割り当てられたＩＰアドレスと、インターネットサービスプロバイダによって割り当てられたゲートウェイの外部インタフェースのＩＰアドレスとを用いて、コントローラ２内のホームネットワークのＤＮＳサーバは、図３に示すようなデータベースを構築する。このような初期化手順の間に、コントローラ２は、コントローラ２に接続又は組み込まれた表示入力装置８に「しばらくお待ちください」といったメッセージを表示する。
【００６３】
ＤＮＳサーバは、ホームネットワークに接続された各装置毎に、利用可能なアドレスを２つ用意しなくてはならない。内部装置が名前の変換を必要とした場合、２番目の列に示すエントリ、すなわちプライベートＩＰアドレスが用いられる。インターネットではプライベートアドレスは使用できないので、外部装置からの要求に応える場合、３番目の列の値、すなわちインターネットＩＰアドレスが用いられる。また、インターネットサービスプロバイダが、外部装置からのno29.bahnstrasse.bonn.deの名前変換の要求全てに対処することもできる。いずれの場合においても、図４に示すように、外部装置は、ホームネットワークのゲートウェイであるコントローラ２に到達できるのみで、ホームネットワーク内の遠隔装置、すなわち遠隔装置１Ａ、１Ｂのそれぞれにまでは到達することはできない。
【００６４】
図４は、図３に示すシステムと、ホームネットワークのストレージ装置として機能する遠隔装置１Ｂにアクセスするためのインターネット装置の手順とを示す。インターネット装置は、storage.no29.bahnstrasse.bonn.deを特定するために、まず最初にホームネットワークのＤＮＳサーバにクエリ「Who is storage.no29.bahnstrasse.bonn.de ?」を送信する。次に、ＤＮＳサーバから応答として、"192.109.206.33"が返される。これは、コントローラ２の外部インタフェースのＩＰアドレスである。すなわち、ＩＰアドレス"storage.no29.bahnstrasse.bonn.de"を要求している装置には、ストレージ装置として機能する遠隔装置１ＢのＩＰアドレスは供給されず、コントローラ２の外部インタフェースのＩＰアドレスのみが供給される。
【００６５】
この実施の形態においては、誰かがインターネットからそのホームネットワークにアクセスしているという警告が、表示入力装置８に表示される。また、必要に応じて、セションセットアップの間に、認証／認可処理が行われる。このように、インターネット経由で要求を送信するユーザは、ストレージ装置として機能する遠隔装置１Ｂに、コントローラ２を介してアクセスすることができるが、直接アクセスすることはできない。
【００６６】
この問題への対策として、本発明においては、インターネットからホームネットワーク内の遠隔装置、すなわち遠隔装置１Ａ、１Ｂに、ホームネットワークのゲートウェイ、すなわちコントローラ２を介して行われるＨＴＴＰアクセスをサポートする新しい統一資源識別子（ＵＲＩ）を規定する。
【００６７】
インターネットサイトから遠隔装置のＩＳＰサブドメインにアクセスするためには、完全なドメインネームが必要である。しかしながら、ホームネットワーク環境内において、それぞれの装置に対してそのような長いドメインネームを用いることは困難である。この問題を解決するために、このＩＰネットワークにおいて、ホームネットワーク内のクライアント装置は、デフォルトドメインであると仮定する。上述の例では、適切なデフォルトドメインネームは、"no29.bahnstrasse.bonn.de"である。
【００６８】
１つの名前を複数のＩＰアドレスにマッピングすることにより、ＤＮＳを用いてリソースを管理することができる。ホームネットワークが、１人のユーザ又は１つのタスクをサポートすることができる多種多様な装置を有するとき、ホームネットワークは、このような装置のうちの幾つかを有することが可能である。この実施の形態においては、インテリジェントネームサーバは、例えば"dvbtuner.no29.bonn.de"のような、装置の一般的名称を、所望の装置のＩＰアドレスにマッピングすることができる。特定の装置にアドレスを割り当てる場合は、独自の名前を割り当ててもよい。
【００６９】
以下、図１乃至図４に示すホームネットワークの遠隔装置、すなわち遠隔装置１Ａ、１Ｂの制御について、図５及び図６を参照しながら説明する。
【００７０】
通常のＨＴＴＰアプリケーションサーバには、サーバ名、すなわち所定のドメインネームと、その後に続く、そのサーバ上のＨＴＭＬ文書を示すパスとからなるユニバーサルリソースロケータ（ＵＲＬ）が割り当てられている。この手法では、ＤＶＢチューナ等のメインメニューのＵＲＬは、"http://dvbtuner.no29.bahnstrasse.bonn.de/index.html"となる。このＵＲＬを用いて、ホームネットワーク内部のブラウザは、最初にＩＰアドレス"dvbtuner.no29.bahnstrasse"を参照する。そして、ＤＮＳサーバは、内部ＩＰアドレス用いて、それに応答し、その結果、ブラウザは、ＨＴＴＰｇｅｔコマンド"GET/index.html"を、このＩＰアドレスに送信する。インターネットのブラウザも、同じくこのドメインを参照するが、上述の通り、ゲートウェイの外部ＩＰアドレスを入手することしかできない。
【００７１】
ホームネットワークのゲートウェイを介して、インターネットシステムからコントローラ２へのアクセスを可能にするためには、ゲートウェイがＨＴＴＰによる要求を受信でき、それらの要求をホームネットワークの遠隔装置１Ａ、１Ｂに送信することができ、また、ドメインネームが"http://dvbtuner.no29.bahnstrasse.bonn.de/index/html"のようなパスにコピーされるので、ゲートウェイは、ホームネットワーク内の目的の装置にアクセスすることができる。
【００７２】
この新しいＵＲＬ規定により、本発明では、図５に示すように、オーディオ／ビデオ装置は、それらのＨＴＴＰサーバ３を初期化する。チューナ装置として機能する遠隔装置１Ａの場合、メインのＨＴＭＬ文書がＨＴＴＰサーバ３内のメモリに記憶される。このメインのＨＴＭＬ文書は、例えば以下のようなものである。
【００７３】
<A HREF="http//tuner.no29.bahnstrasse.bonn.de/
tuner.no29.bahnstrasse.bonn.de/next.cgi">next<＼A>
<A HREF="http//tuner.no29.bahnstrasse.bonn.de/
tuner.no29.bahnstrasse.bonn.de/back.cgi">back<＼A>
<A HREF="http//storage.no29.bahnstrasse.bonn.de/
storage.no29.bahnstrasse.bonn.de">storage<＼A>
<A HREF="http//camera.no29.bahnstrasse.bonn.de/
camera.no29.bahnstrasse.bonn.de">camera<＼A>
ストレージ装置として機能する遠隔装置１Ｂ内に含まれるＨＴＴＰサーバ３のメモリ内のメインのＨＴＭＬ文書の例を以下に示す。
【００７４】
<A HREF="http//storage.no29.bahnstrasse.bonn.de/
storage.no29.bahnstrasse.bonn.de/next.cgi">next<＼A>
<A HREF="http//storage.no29.bahnstrasse.bonn.de/
storage.no29.bahnstrasse.bonn.de/back.cgi">back<＼A>
<A HREF="http//tuner.no29.bahnstrasse.bonn.de/
tuner.no29.bahnstrasse.bonn.de">tuner<＼A>
<A HREF="http//camera.no29.bahnstrasse.bonn.de/
camera.no29.bahnstrasse.bonn.de">camera<＼A>.
それぞれのＨＴＴＰサーバ３は、逆ＤＮＳ参照を行うことで、ローカルドメインネームを検出することができる。すなわち、全てのＨＴＴＰサーバ３は、自身のＩＰアドレスを変換するために自身のドメインネームをローカルＤＮＳサーバに問い合わせることができる。また、ネームサーバは、ホームネットワークがインターネットに接続されていない場合には、例えば"home net"等の規格化された一般的なローカルドメインネームを用いることができる。
【００７５】
全てのサーバは、以下のような記述を行うＨＴＭＬ文書をコンパイルすることができる。
【００７６】
すなわち、サーバは、現在のサービスを示すＨＴＭＬ文書をコンパイルする。例えば、チューナ装置の場合、これは、入力信号として受信する放送信号を示す。このような信号を記述するためにチューナは、ＭＰＥＧデータ／関連するＤＶＢ ＳＩ（デジタルビデオ放送信号情報）データをＨＴＭＬデータに変換する。また、記録モードにあるストレージ装置の場合、これは、アイソクロノスチャンネル上のオーディオ／ビデオデータのような入力信号を示す。さらに、図５に示すサービスのテキスト記述以外に、オーディオビデオデータもＨＴＭＬメニュー内に提示されるのが望ましい。動画をサポートするために、ピクチャを規則的に更新する"server push"や"client pull"等と呼ばれるコマンドが用いられる。
【００７７】
"next"や、前に戻る"back"等のサービスが存在する場合は、そのようなサービスを選択操作することができる。各サーバは、そのようなエントリに、適切なスクリプト又はプログラムを関連付ける。
【００７８】
さらに、各サーバは、ホームネットワーク上のその他の装置へのリンクを提供することができる。リンクを決定するために、サーバは、例えばポート８０において、それがＨＴＴＰ通信に対してデフォルトのＩＰポートであるとして、他の装置をポーリングし、また、応答があれば、その装置への関連エントリを確立する。または、各サーバは、スヌープ、すなわちＩＰパケットを捕捉して、アクティブである他の装置を判別する。このポーリング又はスヌープ処理により、サーバは、全ての遠隔装置に対するハイパーリンクを生成する。
【００７９】
図６は、ユーザコマンドに基づいて、ネットワーク内の各機器が行う処理を示すフローチャートである。ＨＴＴＰサーバ、すなわち遠隔装置１Ａ、１Ｂ及びコントローラ２の初期化の後、コントローラ２に接続された表示入力装置８は、“どの装置にアクセスしますか？”というメッセージを表示する。ここで、ステップＳ１において、ユーザが例えば"storage"というコマンドをタイプ入力又は音声入力すると、コントローラ２は、このコマンドを認識する。認識が問題なく完了すると、ステップＳ２において、コントローラ２は、本例では"no29.bahnstrasse"であるデフォルトドメインの入力コマンド"storage"のＤＮＳ参照を行う。ステップＳ３において、ＤＮＳサーバは、ストレージ装置として機能する遠隔装置１Ｂの内部ＩＰアドレスである192.168.0.3を返す。ステップＳ４において、コントローラ２のブラウザは、ＨＴＴＰコマンド"GET/"を、所望の装置の内部ＩＰアドレス、ここでは192.168.0.3というアドレスに送信する。
【００８０】
ステップＳ５及びステップＳ６において、新しいＵＲＬ規定によって送信されないユニバーサルリソースロケータに対する、192.168.0.3というアドレスを有するＨＴＴＰサーバ、すなわちここではストレージ装置として機能する遠隔装置１Ｂの応答を示す。ステップＳ５においては、サーバ、すなわちストレージ装置として機能する遠隔装置１Ｂは、この従来形式のＵＲＬを識別して、以下のようなサーバリダイレクト応答を返す。
【００８１】
try"http://storage.no29.nahnstrasse.bonn.de/
storage.no29.bahnstrasse.bonn.de"instead!
ブラウザは、このリダイレクト応答に従って、ステップＳ６において、"GET storage.no29.nahnstrasse.bonn.de"という新しいＵＲＬを送信する。このように自動変換が行われ、非同期接続のために生じる待ち時間において、コントローラ２に接続された表示入力装置８は、"メニューをフェッチしています．．．"というメッセージを表示する。
【００８２】
ステップＳ７において、ストレージ装置として機能する遠隔装置１ＢのＨＴＴＰサーバ３は、ＨＴＭＬページに"index.html"を送信する。ブラウザは、ＨＴＭＬデータを受信し、これをグラフィカルユーザインタフェース（ＧＵＩ）として表示入力装置８上に表示する。表示入力装置８は、例えばストレージ装置として機能する遠隔装置１Ｂの名前"STORAGE"と、next、back、tuner/camera及びここでは図示されていないが遠隔装置１Ｂの、その時点で選択された入力装置であるカメラにより撮影されたピクチャといった利用可能なコマンドとを表示する。
【００８３】
選択されたストレージ装置として機能する遠隔装置１Ｂから第１のメニューが供給されると、この実施の形態においては、ユーザは、その時点でこの装置がカメラに接続されていることを通知する。ユーザが、カメラの代わりに、チューナから記録をしたい場合には、ユーザは、"next"というコマンドを発し、次のサービスを要求する。ステップＳ８において、コントローラ２は、このコマンドを認識する。ステップＳ９において、ブラウザは、アンカ"next"を探し当てて、ＨＴＴＰコマンド"GET/storage.no29.bahnstrasse.bonn.de/next.cgi"を、ストレージ装置として機能する遠隔装置１ＢのＩＰアドレス192.168.0.3に送信する。ステップＳ１０において、ストレージ装置として機能する遠隔装置１ＢのＨＴＴＰサーバ３は、このコマンドを受信し、スクリプト"next.cgi"を実行する。したがって、ストレージ装置として機能する遠隔装置１Ｂは、新しいアイソクロノスチャンネルを選択して、新しいメニューを提示する。
【００８４】
ステップＳ１１において、コントローラ２は、更新されたメニューを遠隔装置１Ｂから受信し、それを、接続された表示入力装置８に表示する。この段階で、メニューには、チューナ装置として機能する遠隔装置１Ａをストレージ装置として機能する遠隔装置１Ｂに接続するアイソクロノスチャンネル上で受信された新しいデータが含まれることになるが、この実施の形態においては、そのデータは、例えばＣＮＮの映像等である。
【００８５】
ユーザは、ストレージ装置として機能する遠隔装置１Ｂを既に所望の状態にしているので、この段階で"tuner"というコマンドでチューナ装置として機能する遠隔装置１Ａに切り換えて、所望のチャンネルを選択することができる。
【００８６】
これらのコマンドをより明瞭にし、例えばメニューの最後の行がブラウザを異なるオーディオ／ビデオ装置に接続するものである場合、一層の精緻さとグラフィックとが要求され、それらを各ＨＴＭＬページ上に含めることができる。
【００８７】
ここで再び、ブラウザは、コマンド"tuner"と関連付けられたアンカを探し当てようと試みる。コマンド"tuner"は、そのアンカ内でＨＲＥＦフィールドに続いている。その結果、"tuner.no29,bahnstrasse.bonn.de"をＤＮＳ参照して、ＨＴＴＰコマンド"GET/tuner.no29.bahnstrasse.bonn.de"を適切なＩＰアドレスに送信する。後者は、そのパスに関連するメニューを返信するが、そのパスには、その時点で選択されているサービスの情報が含まれている。また、このメニューは、"next"と"back"のエントリを有するが、これらはストレージ装置として機能する遠隔装置１Ｂのnext及びback処理とは異なる処理を行う。例えば、チューナの"next"操作は、チューナの周波数を変えることがあるが、チューナからの出力信号は、同じアイソクロノスチャンネル番号を使用して送信される。
【００８８】
本発明の別の実施の形態においては、コントローラ２に接続された遠隔装置のうちの選択されたものの全て又は一部のメニューが、コントローラ２に接続された表示入力装置８上に同時に表示される。
【００８９】
より容易にアイソクロノスチャンネルをセットアップできるようにするための拡張されたネットワークの初期化について、図７を用いて説明する。ここでは、ＩＥＥＥ１３９４ネットワークシステムを用いるとともに、後述する非要求型のオーディオビデオデータの放送を受信及び記録する。
【００９０】
ＶＴＲ等の従来のＩＥＥＥ１３９４適用形態においては、例えば、コントローラは、ユーザと双方向通信を行い、ユーザの入力に基づいて、ソース装置とターゲット装置の両方をほぼ同時に制御する。したがって、従来型のコントローラは、ネットワーク構成の一部をユーザから隠してしまうことがある。この手法の短所の１つは、最悪の場合、新しく購入したソース装置やターゲット装置がコントローラのグラフィカルインタフェースに対し、ある程度しか又は全く有効でないといった状態になることである。本発明によれば、各装置の製造業者は、ユーザが各装置を直接制御できるような、各社独自のユーザインタフェースを用いた装置を開発することができる。すなわち、上述したように、ユーザがソース装置とターゲット装置の両方を連続的に制御することにより、装置間の相互関係を統括することができる。
【００９１】
ユーザにとっての利便性を向上させるためには、遠隔装置の順序を固定することは避けた方がよい。すなわち、いずれのソース／遠隔装置を最初に制御するかを、ユーザが自由に選択することができるようにした方がよい。本発明によれば、この目的のため、アイソクロノスチャンネル上でデータを送信することができる各装置は、セットアップ直後に、このようなデータを所望のデータフォーマットで送信することができる。技術的見地から見て、このような放送は、非要求型の（unsolicited）放送と呼ばれている。ここでは、アイソクロノスデータ通信を開始するのに、いかなる直接又は間接的なユーザコマンドも不要である。これらの装置は、基本的な接続が確立された後も放送を続ける。必要に応じて、帯域幅の無駄をなくすために、時間的及び空間的に高い冗長性を有するビデオデータが用いられる。例えばＭＰＥＧ２トランスポートストリームの場合、このようなビデオデータは、ビットレートを低減するために圧縮される。放送装置の入力において、このような信号が利用できない場合、すなわち、ＩＥＥＥ１３９４アイソクロノスチャンネルに送信され、利用できるビットレート信号が全くない場合には、装置内のハードウェアやソフトウェアを用いて、そのような信号を生成することができる。また、この初期アイソクロノスデータは、ユーザが装置の種類と状態を容易に把握できるようにするための情報を提供することが望ましい。
【００９２】
既存のＩＥＥＥ１３９４装置等の旧型の装置は、このような低ビットレートのデータストリームを内部で生成する能力をサポートしていない。しかしながら、本発明によれば、新しい装置は、スタートアップ直後に、従来のビットレートであっても、アイソクロノスチャンネル上でデータ放送を開始するように、これらの旧型の装置に対して指示を送る。チューナの場合には、このようにすることで、ケーブル又は衛星放送によるビットストリームを効率的にホームネットワークに送信することができる。ＶＴＲ等のチューナを備えたストレージ装置も、機械的処理を省くために、放送サービスを送信することができる。例えば、帯域幅や消費電力等の制限があって、旧型の装置でこのような処理を行うことが適切でない場合には、システムは、これらの装置をプログラミングする必要があることを、ユーザに通知する。
【００９３】
以上のように、本発明に係る接続確立方法、遠隔装置及び制御装置によれば、複数の遠隔装置間の通信において、複数のシステム固有プロトコルの代わりに、ハイパーテキスト転送プロトコル、すなわちＨＴＴＰを用いて遠隔装置間の接続を確立する。
【００９４】
遠隔装置は、インターネットサーバのように機能して、特定の制御機能に対応したメニューの選択肢を提供できる。したがって、そのコントローラは１つのプロトコルだけをサポートすればよいため、コントローラの設計が簡単になる。遠隔装置を追加することでネットワークシステムをアップグレードする場合、コントローラに新しい制御プロトコルを含める必要がない。アップグレードを行うには、当該コントローラにより制御される各遠隔装置からコントローラ内に、ユーザインタフェースをダウンロードして、ダウンロードしたインタフェースを、遠隔装置を制御したいユーザに提供することができる。
【符号の説明】
【００９５】
１Ａ  遠隔装置、１Ｂ  遠隔装置、２  コントローラ、３  ＨＴＴＰサーバ、４  データインタフェース、５  アイソクロノス接続ライン、８  表示入力装置
【図１】
2010004569.tif 000003
【図２】
2010004569.tif 000004
【図３】
2010004569.tif 000005
【図４】
2010004569.tif 000006
【図５】
2010004569.tif 000007
【図６】
2010004569.tif 000008
【図７】
2010004569.tif 000009
【図８】
2010004569.tif 000010
【図９】
2010004569.tif 000011
【図１０】
2010004569.tif 000012
【図１１】
2010004569.tif 000013