リモート制御システム
【課題】 複数のデバイス間でユーザにより設定されたＩＤが重複する場合でも、直近の動作時に一群の制御対象として動作していたデバイスを識別して制御対象を選択できるようにする。
【解決手段】 複数の制御装置と、その制御装置により制御される複数のデバイスとを備えるリモート制御システムにおいて、各デバイスに、ユーザが設定する第１ＩＤと、制御装置による制御対象となったデバイスに共通して記憶させる第２ＩＤとを記憶させておき、制御装置が、第２ＩＤを記憶すると共に制御対象とする複数のデバイスを第１ＩＤによりデバイス毎に特定しつつ、各デバイスから上記第１ＩＤ及び第２ＩＤを取得し、第１ＩＤに基づいて制御対象に対応付けるべきデバイスを選択し、そのデバイスの第２ＩＤが制御装置の記憶する第２ＩＤと一致すれば対応付けを行い、一致しなければ警告を行うようにした（Ｓ３０５〜Ｓ３０７）。
【解決手段】 複数の制御装置と、その制御装置により制御される複数のデバイスとを備えるリモート制御システムにおいて、各デバイスに、ユーザが設定する第１ＩＤと、制御装置による制御対象となったデバイスに共通して記憶させる第２ＩＤとを記憶させておき、制御装置が、第２ＩＤを記憶すると共に制御対象とする複数のデバイスを第１ＩＤによりデバイス毎に特定しつつ、各デバイスから上記第１ＩＤ及び第２ＩＤを取得し、第１ＩＤに基づいて制御対象に対応付けるべきデバイスを選択し、そのデバイスの第２ＩＤが制御装置の記憶する第２ＩＤと一致すれば対応付けを行い、一致しなければ警告を行うようにした（Ｓ３０５〜Ｓ３０７）。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数の制御装置と、その制御装置により制御される複数のデバイスとを備えるリモート制御システムに関する。
【背景技術】
【０００２】
従来から、複数のデバイス間でデータの伝送を行うための種々のネットワークシステムが知られている。
例えば、複数のノード間で音響信号の伝送を行うためのオーディオネットワークシステムが知られており、コンサート、演劇、音楽製作、構内放送等において用いられている。このようなオーディオネットワークシステムの例としては、以下の非特許文献１，２に記載のような、ＣｏｂｒａＮｅｔ（商標），ＥｔｈｅｒＳｏｕｎｄ（商標）が知られている。
【０００３】
また、これら以外に、特許文献１に記載のネットワークシステムも提案されている。
この特許文献１に記載のネットワークシステムにおいては、システムを構成する各デバイスにより形成されるリング状の伝送路にフレームを定期的に循環させ、各デバイスがそのフレームに対して必要な情報を読み書きすることにより、システムを構成する任意のデバイスから任意のデバイスへ、音響信号だけでなくイーサネット（登録商標）フレーム等の制御信号も、安定して伝送することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−９４５８９号公報
【非特許文献】
【０００５】
【非特許文献１】「CobraNet(TM)」、[online]、バルコム株式会社、［平成１８年３月２１日検索］、インターネット＜ＵＲＬ：http://www.balcom.co.jp/cobranet.htm＞
【非特許文献２】Carl Conrad、「EtherSound(TM) in a studio environment」、[online]、Digigram S.A.、［平成１８年３月２１日検索］、インターネット＜ＵＲＬ：http://www.ethersound.com/news/getnews.php?enews_key=101＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、上述したようなネットワークシステムにおいて、ある制御装置によりシステム内のデバイスを制御するリモート制御システムを構成しようとする場合、その制御範囲を特定するためにシステムＩＤを用いたり、具体的な制御対象を特定するためにデバイスＩＤを用いたりすることが考えられる。そしてこの場合、各デバイスにシステムＩＤとデバイスＩＤを予め設定しておき、制御装置がこれらのＩＤに基づいて制御対象のデバイスを特定することが考えられる。
【０００７】
このような用途のＩＤは、ユーザによる設定を楽にしたり、設定画面を簡素にしたりするために、１〜数桁の数字や１〜数文字のアルファベットなど、簡単な内容にすることが好ましい。
しかし、このようなＩＤを採用した場合、ユーザが把握できる範囲ではデバイス間で一意性を確保できるとしても、偶然やミスによりデバイス間でＩＤが重複してしまい、デバイスを識別できなくなる恐れがあった。
【０００８】
例えば、システムに新たなデバイスを追加しようとした場合に、その新たなデバイスに誤って既存のデバイスと同じＩＤが設定されていると、それらのどちらのデバイスが新たに追加されたデバイスであるのか、制御装置から容易に判別できない。また、システム内のデバイスが故障して、これを別のデバイスに置き換える場合にも、その別のデバイスに誤って既存のデバイスと同じＩＤが設定されていると、それらのどちらのデバイスが置き換え後のデバイスであるのか、制御装置から容易に判別できない。
【０００９】
従って、制御装置においてＩＤの設定が誤っていることが把握できたとしても、誤設定のない範囲で制御を開始することすら、難しい場合もあった。
このような問題は、複雑なＩＤを用いる場合であっても、誤設定による重複が無視できない場合には、同様に発生するものである。
【００１０】
この発明は、このような問題を解決し、制御装置が複数のデバイスの制御を開始する際に、その複数のデバイス間でユーザにより設定されたＩＤが重複する場合でも、直近の動作時に一群の制御対象として動作していたデバイスと、そうでないデバイスとを制御装置が容易に識別して、制御対象を選択できるようにすることを目的とする。
特に、複数の制御装置により同じデバイスを制御しようとする場合でも、直近の動作時に一群の制御対象として動作していたデバイスと、そうでないデバイスとを制御装置が容易に識別して、制御対象を選択できるようにすることを目的とする。
【課題を解決するための手段】
【００１１】
上記の目的を達成するため、この発明のリモート制御システムは、複数の制御装置と、その複数の制御装置により制御される複数のデバイスとを備えるリモート制御システムにおいて、まず、上記各デバイスに、そのデバイスの第１ＩＤ及び第２ＩＤを記憶する記憶手段と、ユーザの操作に応じて上記第１ＩＤを上記記憶手段に記憶させる第１設定手段と、上記制御装置からＩＤを受信して上記第２ＩＤとして上記記憶手段に記憶させる第２設定手段とを設けたものである。
【００１２】
さらに、上記各制御装置に、第２ＩＤを記憶する第２ＩＤ記憶手段と、制御対象とする複数のデバイスを上記第１ＩＤによりデバイス毎に特定するデバイスデータを記憶する制御対象記憶手段と、上記各デバイスからそれぞれそのデバイスの第１ＩＤ及び第２ＩＤを取得するＩＤ取得手段と、上記ＩＤ取得手段が取得した第１ＩＤ及び第２ＩＤに基づき、上記制御対象記憶手段に記憶された各デバイスデータに対し、ＩＤの取得元である各デバイスのうち、そのデバイスデータと上記第１ＩＤの値が共通する最大１つのデバイスを対応付ける手段であって、ａ）上記ＩＤの取得元である各デバイスの中に、上記デバイスデータと上記第１ＩＤの値が共通であり、かつ上記第２ＩＤ記憶手段が記憶する第２ＩＤと同じ値の第２ＩＤを有するデバイスがあった場合に、そのデバイスをそのデバイスデータに対応付け、ｂ）上記ＩＤの取得元である各デバイスの中に、上記デバイスデータと上記第１ＩＤの値が共通であり、かつ上記第２ＩＤ記憶手段が記憶する第２ＩＤと異なる値の第２ＩＤを有するデバイスがあった場合に、ユーザに対して警告を行う対応付け手段と、上記対応付け手段による対応付けができたデバイスを、制御対象のデバイスとして設定する制御対象設定手段と、上記制御対象設定手段が設定した制御対象のデバイスを、上記第１ＩＤにより特定して制御するリモート制御手段とを設けたものである。
【００１３】
さらに、上記複数の制御装置のうち特定の制御装置に、上記デバイスデータのいずれかについて、上記ＩＤの取得元である各デバイスの中に、そのデバイスデータと上記第１ＩＤの値が共通であるデバイスが１以上あった場合に、ユーザの操作に応じて、その各デバイスの上記第２ＩＤの値によらず、上記１以上のデバイスのうち１つをそのデバイスデータに対応付ける手動対応付け手段と、上記制御対象設定手段による制御対象の設定に際して、制御対象とするデバイスの中に、上記手動対応付け手段による対応付けがなされたデバイスが含まれている場合、１つのユニークなＩＤを生成し、上記第２ＩＤ記憶手段に記憶している第２ＩＤをその生成したＩＤに書き換えると共に、上記制御対象設定手段が設定する制御対象の各デバイスに送信して上記第２ＩＤとして記憶させる第２ＩＤ付与手段とを設けたものである。
【００１４】
また、この発明の別のリモート制御システムは、複数の制御装置と、その複数の制御装置により制御される複数のデバイスとを備えるリモート制御システムにおいて、まず、上記各デバイスに、そのデバイスの第１ＩＤ及び第２ＩＤを記憶する記憶手段と、ユーザの操作に応じて上記第１ＩＤを上記記憶手段に記憶させる第１設定手段と、上記制御装置からＩＤを受信して上記第２ＩＤとして上記記憶手段に記憶させる第２設定手段とを設けたものである。
【００１５】
さらに、上記各制御装置に、第２ＩＤを記憶する第２ＩＤ記憶手段と、制御対象とする複数のデバイスを上記第１ＩＤによりデバイス毎に特定するデバイスデータを記憶する制御対象記憶手段と、上記各デバイスからそれぞれそのデバイスの第１ＩＤ及び第２ＩＤを取得するＩＤ取得手段と、上記ＩＤ取得手段が取得した第１ＩＤ及び第２ＩＤに基づき、上記制御対象記憶手段に記憶された各デバイスデータに対し、ＩＤの取得元である各デバイスのうち、そのデバイスデータと上記第１ＩＤの値が共通する最大１つのデバイスを対応付ける手段であって、ａ）上記ＩＤの取得元である各デバイスの中に、上記デバイスデータと上記第１ＩＤの値が共通であり、かつ上記第２ＩＤ記憶手段が記憶する第２ＩＤと同じ値の第２ＩＤを有するデバイスがあった場合に、そのデバイスをそのデバイスデータに対応付け、ｂ）上記ＩＤの取得元である各デバイスの中に、上記デバイスデータと上記第１ＩＤの値が共通であり、かつ上記第２ＩＤ記憶手段が記憶する第２ＩＤと異なる値の第２ＩＤを有するデバイスがあった場合に、ユーザに対して警告を行う対応付け手段と、上記対応付け手段による対応付けができたデバイスを、制御対象のデバイスとして設定する制御対象設定手段と、上記制御対象設定手段が設定した制御対象のデバイスを、上記第１ＩＤにより特定して制御するリモート制御手段とを設けたものである。
【００１６】
さらに、上記複数の制御装置のうち特定の制御装置に、ユーザの操作に応じて上記制御対象記憶手段に対してデバイスデータの追加及び削除を行う制御対象編集手段と、上記デバイスデータのいずれかについて、上記ＩＤの取得元である各デバイスの中に、そのデバイスデータと上記第１ＩＤの値が共通であるデバイスが１以上あった場合に、ユーザの操作に応じて、その各デバイスの上記第２ＩＤの値によらず、上記１以上のデバイスのうち１つをそのデバイスデータに対応付ける手動対応付け手段と、上記制御対象設定手段による制御対象の設定に際して、上記制御対象編集手段によりデバイスデータの追加又は削除がなされた場合及び、制御対象とするデバイスの中に、上記手動対応付け手段による対応付けがなされたデバイスが含まれている場合に、１つのユニークなＩＤを生成し、上記第２ＩＤ記憶手段に記憶している第２ＩＤをその生成したＩＤに書き換えると共に、上記制御対象設定手段が設定する制御対象の各デバイスに送信して上記第２ＩＤとして記憶させる第２ＩＤ付与手段とを設けたものである。
【００１７】
上記の各リモート制御システムにおいて、上記特定の制御装置の第２ＩＤ付与手段が、上記ユニークなＩＤを生成した場合、そのＩＤを他の制御装置に通知し、その他の制御装置が、上記第２ＩＤ記憶手段に記憶している第２ＩＤをその通知されたＩＤに書き換えると共に、上記制御対象記憶手段に記憶しているデバイスデータを、上記特定の制御装置の制御対象記憶手段が記憶しているデバイスデータに書き換えるようにするとよい。
【発明の効果】
【００１８】
この発明によるリモート制御システムによれば、複数の制御装置により同じデバイスを制御しようとする場合でも、同じシステムを制御対象とする複数の制御装置間で共通となるシステムＵＩＤ（第２ＩＤ）に基づいて、直近の動作時に一群の制御対象として動作していたデバイスと、そうでないデバイスとを制御装置が容易に識別して、制御対象を選択できるようにすることができる。
【図面の簡単な説明】
【００１９】
【図１】この発明のリモート制御システムの実施形態において制御装置により制御されるデバイスが形成するオーディオネットワークシステムの概略構成を示す図である。
【図２】図１に示したオーディオネットワークシステムの伝送路で伝送されるＴＬフレームの構成例を示す図である。
【図３】ＴＬフレームの伝送タイミングを示す図である。
【図４】オーディオネットワークシステム上での音響信号の伝送時における、ＴＬフレームの伝送状況について説明するための図である。
【図５】図１に示したオーディオネットワークシステムを構成する各ノードとなる音響信号処理装置のハードウェア構成を示す図である。
【図６】図１に示した方式のオーディオネットワークシステムのより具体的な構成例を示す図である。
【図７】各デバイスに記憶させるＩＤについて説明するための図である。
【図８】仮想デバイステーブルの例を示す図である。
【図９】制御装置に記憶させる、オーディオネットワークシステムを構成するデバイスを制御するためのパラメータの例を示す図である。
【図１０】制御装置のＣＰＵが実行する仮想デバイス追加処理のフローチャートである。
【００２０】
【図１１】同じく仮想デバイス削除処理のフローチャートである。
【図１２】制御装置が収集した各デバイスのＩＤの例を示す図である。
【図１３】制御装置のＣＰＵが実行する自動対応付け処理のフローチャートである。
【図１４】同じくデバイス検索処理のフローチャートである。
【図１５】同じく同期化処理のフローチャートである。
【図１６】同じく現在の制御対象を示すシステムＩＤを設定する処理のフローチャートである。
【図１７】同じく手動対応付け処理のフローチャートである。
【図１８】同じく新規デバイスの追加を検出した場合の処理のフローチャートである。
【図１９】制御装置による制御対象デバイス認識の具体例を示す図である。
【図２０】第２の実施形態における仮想デバイステーブルの例を示す図である。
【００２１】
【図２１】第２の実施形態における自動対応付け処理のフローチャートである。
【図２２】第２の実施形態における手動対応付け処理のフローチャートである。
【図２３】第２の実施形態における同期化処理のフローチャートである。
【図２４】制御装置が他の制御装置からシステムＵＩＤ更新に伴う仮想デバイステーブルの通知を受けた場合に実行する処理のフローチャートである。
【図２５】第２の実施形態における制御装置による制御対象デバイス認識の具体例を示す図である。
【図２６】その別の例を示す図である。
【発明を実施するための形態】
【００２２】
以下、この発明を実施するための形態を図面に基づいて具体的に説明する。
１． この発明のリモート制御システムの実施形態の概要（第１の実施形態）
この発明のリモート制御システムは、１又は複数の制御装置と、その制御装置により制御される複数のデバイスとを備えたシステムとして構成することができる。そして、その制御装置はそれぞれ、どのデバイスを制御対象とするかという設定に従って、ネットワークシステムを構成する複数のデバイスから適当なデバイスを選択してリモート制御の対象とし、その制御装置と、選択した制御対象デバイスとにより、リモート制御システムを構成することができる。
【００２３】
また、制御装置により制御されるデバイスとしては、例えば、相互に音響信号を送受信可能なオーディオネットワークシステムを構成するデバイスが考えられる。
ここではまず、背景技術の項で述べた特開２００９−９４５８９号公報に記載のようなオーディオネットワークシステムを構成するデバイスを制御装置により制御され得るデバイスとする場合のリモート制御システムの構成例について説明する。
【００２４】
１．１ 制御装置により制御されるデバイスが形成するネットワークシステムの例
まず、図１に、この発明のリモート制御システムの実施形態において制御装置により制御されるデバイスが形成するオーディオネットワークシステムの概略構成を示す。
図１（ａ），（ｂ）に示すように、このオーディオネットワークシステム１は、それぞれ単方向の通信を行う受信手段である受信インタフェース（Ｉ／Ｆ）と送信手段である送信Ｉ／Ｆの組を２組備えたデバイスであるノードＡ〜Ｃを、通信ケーブルＣＢで順次接続することにより構成したものである。ここでは３つのノードにより構成した例を示しているが、ノードの数は２以上の任意でよい。
【００２５】
ノードＡにおいては、受信Ｉ／Ｆ＿ＡＲ１と送信Ｉ／Ｆ＿ＡＴ１が一組のＩ／Ｆで、受信Ｉ／Ｆ＿ＡＲ２と送信Ｉ／Ｆ＿ＡＴ２がもう一組のＩ／Ｆである。ノードＢ及びＣについても、符号の先頭の文字「Ａ」を「Ｂ」あるいは「Ｃ」に置き換えたＩ／Ｆが、同様な関係に当たる。
【００２６】
そして、ノード間の接続は、１組の受信Ｉ／Ｆ及び送信Ｉ／Ｆを、別のノードの１組の送信Ｉ／Ｆ及び受信Ｉ／Ｆとそれぞれ通信ケーブルＣＢで接続することにより行っている。例えば、ノードＡとノードＢとの間では、受信Ｉ／Ｆ＿ＡＲ２と送信Ｉ／Ｆ＿ＢＴ１とを接続すると共に、送信Ｉ／Ｆ＿ＡＴ２と受信Ｉ／Ｆ＿ＢＲ１とを接続している。また、ノードＢとノードＣとの間では、ノードＢのもう１組のＩ／Ｆと、ノードＣの１組のＩ／Ｆとを接続している。
なお、図１に示す各ノードは、アナログ入力，アナログ出力，デジタル入力，デジタル出力，ミキシング，エフェクト付与，録音再生，リモート制御，あるいはこれらの組み合わせ等の各種機能を有する音響信号処理装置である。ノード毎に機能が違っていても当然構わない。
【００２７】
ここで、（ａ）に示すように、各ノードを、端部を有する１本のラインのように接続した状態を、「カスケード接続」と呼ぶことにする。そしてこの場合、各ノード間を結ぶケーブルＣＢにより、破線で示すように１つのリング状のデータ伝送経路を形成することができ、各ノードは、この経路でフレームを一定周期で循環させるように伝送し、そのフレームに対して必要な情報を読み書きすることにより、経路上の任意のノードとの間でデータの送受信を行うことができる。
そして、オーディオネットワークシステム１内において、１つのノードがマスタノードとなり、音響信号を伝送するためのフレームを生成し、定期的に伝送経路を循環させたり、ネットワークの管理を行ったりする。このマスタノードが生成するフレームを、その他のフレームと区別して「ＴＬフレーム」と呼ぶことにする。
【００２８】
また、（ａ）に示したカスケード接続に加え、両端のノードで使用していないＩ／Ｆ同士も通信ケーブルＣＢで接続すると、（ｂ）に示すように、リング状のデータ伝送経路を２つ形成することができる。そして、各ノードは、これらの経路でそれぞれフレームを伝送し、その各フレームに対して必要な情報を読み書きすることにより、経路上の任意のノードとの間でデータの送受信を行うことができる。このようなノード間の接続状態を、「ループ接続」と呼ぶことにする。
【００２９】
このループ接続の状態で、一方の伝送路を循環させるＴＬフレームのみで伝送可能な情報量の通信を行っている場合、１カ所で断線が発生したとしても、その断線箇所の両側でＴＬフレームの伝送を折り返すことにより、断線箇所の両側をカスケード接続の両端と見て、速やかに（ａ）に示したようなカスケード接続のシステムに組み換え、０〜２フレーム程度の損失でＴＬフレームの伝送を継続することができる。
【００３０】
また、カスケード接続の状態で両端に新たにノードを追加接続した場合には、接続箇所の両側でＴＬフレーム伝送の折り返しを解除することにより、そのノードを通るデータ伝送経路を形成してそのノードをシステムに取り込むことができる。逆に、カスケード接続の状態でいずれかのノード間の接続が切断された場合には、切断箇所の両側でＴＬフレーム伝送の折り返しを開始することにより、マスタノードから見て切断箇所よりも先のノードを切離し、接続が維持されている箇所についてはＴＬフレームの伝送を継続することができる。
【００３１】
なお、図１ではケーブルを２本示しているが、１組の受信Ｉ／Ｆと送信Ｉ／Ｆとを近接してあるいは一体として設ければ、２本を束ねて１本にしたケーブルにより、１組のＩ／Ｆ同士の接続を行うことも可能である。
また、各ノードには、必要なＩ／Ｆを設ければ、（ｃ）に示すように、外部機器Ｎを接続し、外部機器Ｎから受信したデータをＴＬフレームに書き込んで他のノードに送信したり、ＴＬフレームから読み出したデータを外部機器Ｎに送信したりすることもできる。
【００３２】
ここで説明するリモート制御システムにおいて、制御装置は、オーディオネットワークシステム１を構成するデバイスのいずれかとすることもできるし、外部機器Ｎのようにオーディオネットワークシステム１を構成するデバイスのいずれかに接続された外部機器とすることもできる。
【００３３】
前者の場合、例えばオーディオネットワークシステム１を構成するコンソールを制御装置として用いることができる。
後者の場合、外部機器として、パーソナルコンピュータ（ＰＣ）を用い、このＰＣ上でリモート制御システム制御用のアプリケーションを起動することにより制御装置として機能させることが考えられる。そして、ＰＣがユーザから受け付けた操作に応じたコマンドをノードＢに送信し、ノードＢがこれをＴＬフレームに書き込んで他のノードに送信したり、他のノードがＴＬフレームに書き込んで送信してきた応答やレベルデータ等をノードＢが読み出してＰＣに送信し、ＰＣにおける操作子状態の表示やレベル表示に使用するといった動作を行わせることが考えられる。
制御装置の数は任意であるし、両者が混在していても構わない。
【００３４】
１．２ ＴＬフレームの構成
次に、図２に、上述したオーディオネットワークシステム１の伝送路で伝送されるＴＬフレームの構成例を示す。なお、この図に示した各領域の幅は必ずしもデータ量と対応しない。
図２に示すように、このＴＬフレーム１００は、サイズが１２８２バイトであり、先頭から順に、プリアンブル１０１，管理データ１０２，波形データ（オーディオデータ）領域１０３，制御データ領域１０４，ＦＣＳ（Frame Check Sequence）１０５の各領域からなる。各領域のサイズは、その領域に記載するデータ量に関わらずそれぞれ一定である。また、ここで示すＦＣＳ１０５以外の各領域のサイズは一例であり、適宜変更してよい。
【００３５】
そして、プリアンブル１０１は、計８バイトのデータであり、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２．３で規定されるプリアンブルとＳＦＤ（Start Frame Delimiter）とを記載する。
管理データ１０２は、８バイトのデータであり、オーディオネットワークシステム１内の各ノードがＴＬフレームに含まれるデータの管理に利用するデータとして、システム内のどの伝送路を循環させるフレームかを示すリングＩＤ、フレーム通し番号であるフレームＩＤ、波形データ１０３中の波形データのｃｈ数等を記載する。
【００３６】
また、波形データ領域１０３としては１０２４バイトを確保しており、音響信号のデータである１サンプル３２ビットの波形データを２５６ｃｈ分記載できる。すなわち、本システムでは、１つのＴＬフレーム１００を循環させることにより、２５６ｃｈ分の音響信号を伝送することができる。なお、２５６ｃｈ中の伝送に使われていないｃｈ（空きｃｈ）の領域については、そこに何が記載されているか気にしなくて良い。なお、波形データのビット数に応じて各ｃｈの領域のサイズを変更するようにしてもよい。その場合、１６ビットの波形データは５１２ｃｈ分伝送可能であり、２４ビットであれば３４０ｃｈ分伝送可能になる。
【００３７】
また、波形データ領域１０３においては、予めオーディオネットワークシステム１を構成する各ノードにｃｈを割り当てておき、各ノードは、自身に割り当てられたｃｈの位置に、出力波形データの書き込みを行う。この割り当ては、システム全体の管理動作を行うマスタノードが、各ノードからの要求に基づいて行う。
【００３８】
一方、制御データ領域１０４としては２３８バイトを確保し、ここには、イーサネットフレーム領域１０６、ＩＴＬフレーム領域１０７、および管理データ領域１０８設けている。
このうちイーサネットフレーム領域１０６には、ＩＰ（Internet Protocol）に基づくノード間通信用のパケットであるＩＰパケットをさらにフレーム化したＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２．３形式のフレーム（イーサネットフレーム）を記載する。
【００３９】
また、記載すべきイーサネットフレームが用意したサイズ（ここでは１７８バイト）に収まらない場合には、フレームの送信側で必要な数のブロックに分割し、ＴＬフレーム１つにつき、そのブロック１つを記載する。そして、フレームの受信側で複数のＴＬフレーム１００からデータを取り出して結合し、分割前のフレームを復元することにより、通常のイーサネット（登録商標）での伝送と同様にイーサネットフレームをノード間で伝送することができる。
【００４０】
また、ＩＴＬフレーム領域１０７には、隣接ノード間でのコマンド及びコマンドに対する応答の伝送に使用するフレームであるＩＴＬフレームのデータを記載する。このＩＴＬフレームは、詳細な説明は省略するが、システム内でフレーム伝送路を形成する際の情報伝達や、システム形成後の情報伝達に使用する。
【００４１】
管理データ領域１０８は、システム内の各ノードがＴＬフレーム１００に含まれるデータの管理に利用するデータを記載する領域である。ここに記載するデータとしては、例えば、レベル表示に使用するメータデータ、ＴＬフレーム１００が伝送中に切断されたことを示す切断検出フラグ、ＴＬフレーム１００の伝送にエラーが生じたことを示すエラーフラグ等が挙げられる。
また、ＦＣＳ１０５は、ＩＥＥＥ８０２．３で規定される、フレームのエラーを検出するためのフィールドである。
【００４２】
オーディオネットワークシステム１においては、以上のようなＴＬフレームに各ノード間を巡回させることにより、オーディオ信号のリアルタイム伝送とイーサネットフレームの伝送とを同時に行うことができる。そして、イーサネットフレーム領域１０６を用いたイーサネットフレームの伝送により、オーディオネットワークシステム１を構成する各ノードは、１つのイーサネット（商標）で接続されているのと等価な環境にある。
【００４３】
１．３ ＴＬフレームの伝送方式
次に、図３に、図２に示したＴＬフレーム１００の伝送タイミングを示す。
この図に示すように、オーディオネットワークシステム１においては、ＴＬフレーム１００を、９６ｋＨｚ（キロヘルツ）のサンプリング周期１周期である１０．４μｓｅｃ（マイクロ秒）毎に１つ、ノード間を循環させ、各ノードはＴＬフレームの所望のｃｈへの音響信号の書き込みないし所望のｃｈからの音響信号の読み出しを行うようになっている。従って、各サンプリング周期に、２５６の信号伝送ｃｈについて、それぞれ１サンプル分の波形データを、各ノード間で伝送できる。
１Ｇｂｐｓ（ギガビット・パー・セカンド）のイーサネット（登録商標）方式のデータ転送を採用すれば、ＴＬフレーム１００の時間長は、１ナノ秒×８ビット×１２８２バイト＝１０．２６μｓｅｃであり、１サンプリング周期内に伝送が完了する。
【００４４】
次に、図４に、オーディオネットワークシステム上での音響信号の伝送時における、図２に示したＴＬフレームの伝送状況を示す。
ここでは、ノードＡからノードＤまでの４つのノードをカスケード接続したシステムを考える。そして、このシステム内の各ノードにＴＬフレーム１００を循環させる場合、いずれか１つのノードをマスタノードと定め、そのノードのみが新たなサンプリング周期のＴＬフレーム（通し番号の異なるＴＬフレーム）の生成を行い、サンプリング周期毎に生成されたＴＬフレームを次のノードへ送信する。マスタノード以外のノードはスレーブノードであり、それぞれ前のノードからＴＬフレームを受信し、次のノードへ送信する転送処理を行う。
【００４５】
そして、マスタノードであるノードＢが最初に図で右向きに、ワードクロックのタイミングに合わせて、ノードＣに向かってＴＬフレームを送信すると、そのＴＬフレームは、破線で示すように、ノードＢ→Ｃ→Ｄ→Ｃ→Ｂ→Ａ→Ｂの順で伝送され、ノードＢに戻ってくる。この伝送の際、各ノードは、ＴＬフレームを受信してから送信するまでに、他のノードから受信すべき波形データや制御データをＴＬフレームから読み取り、また他のノードに送信すべき波形データや制御データをＴＬフレームに書き込む。
【００４６】
そして、マスタノードは、ＴＬフレームが伝送路を１周して戻ってくると、そのＴＬフレームの管理データを書き換えて後のサンプル周期のＴＬフレームを生成し、適当なサンプル周期での送信に供する。またこのとき、マスタノードも他のノードと同様にＴＬフレームに対してデータの読み書きを行う。
【００４７】
以上を繰り返すことにより、１サンプリング周期につき１つのＴＬフレームに、（ａ）から（ｅ）に時系列的に示すように、各ノードを循環させることができる。これらの図において、黒塗りの矢印はＴＬフレームの先頭を、黒丸はＴＬフレームの末端を示す。線の矢印は、ＴＬフレームの切れ目を分かり易くするために記載したものである。
【００４８】
なお、ループ接続を行い、部分システム内に伝送路を２本形成する場合には、図１からわかるように、マスタノードであるノードＢが生成して図で右向きに送信したＴＬフレームを、ノードＢ→Ｃ→Ｄ→Ａ→Ｂの順で伝送する伝送路と、ノードＢが生成して図で左向きに送信したＴＬフレームを、ノードＢ→Ａ→Ｄ→Ｃ→Ｂの順で伝送する伝送路とができることになる。そしてこの場合、ＴＬフレームが伝送路を１周する間に全てのノードを１回ずつ通過することになるため、各ノードは、その通過の際にデータの読み書きを行う。
【００４９】
１．４ システムを構成する各装置のハードウェア構成及び基本動作
次に、以上説明してきたようなＴＬフレームの伝送を行うためのハードウェア及びその動作について説明する。
図５に、上述のオーディオネットワークシステム１を構成する各ノードとなる音響信号処理装置のハードウェア構成を示す。
【００５０】
図５に示すように、この音響信号処理装置１０は、ＣＰＵ２０１，フラッシュメモリ２０２，ＲＡＭ２０３，外部機器Ｉ／Ｆ（インタフェース）２０４，表示器２０５，操作子２０６を備え、これらがシステムバス２０７により接続されている。また、外部機器Ｉ／Ｆ２０４とシステムバス２０７とに接続するカードＩ／Ｏ（入出力部）２１０も備えている。
【００５１】
そして、ＣＰＵ２０１は、この音響信号処理装置１０の動作を統括制御する制御手段であり、フラッシュメモリ２０２に記憶された所要の制御プログラムを実行することにより、表示器２０５における表示を制御したり、操作子２０６の操作を検出してその操作に従ってパラメータの値の設定／変更や各部の動作を制御したり、コマンドをカードＩ／Ｏ２１０を介して他の音響信号処理装置に送信したり、カードＩ／Ｏ２１０を介して他の音響信号処理装置から受信したコマンドに従った処理を行ったりする。
【００５２】
フラッシュメモリ２０２は、ＣＰＵ２０１が実行する制御プログラムを始め、電源を切っても残しておくべきデータを記憶する書き換え可能な不揮発性記憶手段である。
ＲＡＭ２０３は、一時的に記憶すべきデータを記憶したり、ＣＰＵ２０１のワークメモリとして使用したりする記憶手段である。
【００５３】
外部機器Ｉ／Ｆ２０４は、種々の外部機器を接続し入出力を行うためのインタフェースであり、例えば外部のディスプレイ、マウス、文字入力用のキーボード、操作パネル、ＰＣ等を接続するためのインタフェースが用意される。ＰＣは、ＣＰＵ、メモリ、ハードディスク、ディスプレイ、キーボード、マウス、各種インターフェース、等を備え、Ｗｉｎｄｏｗｓ（商標）等のオペレーティングシステム（ＯＳ）が走る、通常のパーソナルコンピュータである。ユーザは、そのＯＳの元で、所望のアプリケーションソフトを起動して、ＰＣを使用する。
【００５４】
外部機器Ｉ／Ｆ２０４は、カードＩ／Ｏ２１０のオーディオバス２１７にも接続しており、オーディオバス２１７を流れる波形データを外部装置に送信したり、外部装置から受信した波形データをオーディオバス２１７に入力したりすることができる。この外部機器Ｉ／Ｆ２０４は、イーサネット、ＵＳＢ、ＩＥＥＥ１３９４等のいずれのインターフェースであってもよい。
【００５５】
表示器２０５は、ＣＰＵ２０１による制御に従って種々の情報を表示する表示手段であり、例えば、液晶ディスプレイ（ＬＣＤ）や発光ダイオード（ＬＥＤ）によって構成することができる。
操作子２０６は、音響信号処理装置１０に対する操作を受け付けるためのものであり、種々のキー、ボタン、ダイヤル、スライダ等によって構成することができる。
【００５６】
これらの表示器２０５及び操作子２０６は、例えば音響信号処理装置１０をコンソールとして構成する場合には、多数のｃｈについて信号処理パラメータやパッチの設定を受け付けるための大型のディスプレイや多数のボタン、スイッチ、電動フェーダ等を設け、入出力装置として構成する場合には電源及びモード設定のための簡単なランプやボタンを設ける等、装置の機能に応じて大きく構成が異なるものである。
【００５７】
また、カードＩ／Ｏ２１０は、オーディオバス２１７と制御バス２１８を備え、これらのバスに種々のカードモジュールを装着することにより、音響信号処理装置１０に対する音響信号及び制御信号の入出力及びその処理を行うことができるようにするためのインタフェースである。ここに装着される各カードモジュールは、オーディオバス２１７を介して相互に波形データを送受信すると共に、制御バス２１８を介してＣＰＵ２０１との間で制御信号を送受信し、ＣＰＵ２０１の制御を受ける。
【００５８】
オーディオバス２１７は、任意のカードから任意のカードへ、複数チャンネルの波形データをサンプリング周期に基づくタイミングで各１サンプルずつ時分割伝送する音響信号伝送用ローカルバスである。接続された複数カードの何れか１つがマスタとなり、当該カードが生成し供給するワードクロックに基づいてオーディオバス２１７の時分割伝送の基準タイミングを制御する。その他の各カードはスレーブとなり、その基準タイミングに基づいて各カードのワードクロックを生成する。
【００５９】
図５には、カードＩ／Ｏ２１０にＤＳＰ（デジタル・シグナル・プロセッサ）カード２１１，２１２，アナログ入力カード２１３，アナログ出力カード２１４，ネットワークＩ／Ｆカード２１５を装着した例を示している。
カードＩ／Ｏ２１０に装着される各種カードは、そのカードの機能に応じた波形データの処理を、それぞれ、ワードクロック（波形データのサンプリング周期）に基づくタイミングで実行する。
【００６０】
また、これらのカードのうちネットワークＩ／Ｆカード２１５が、送信Ｉ／Ｆと受信Ｉ／Ｆを２組備え、図１乃至図４を用いて説明したオーディオネットワークシステム１におけるＴＬフレーム１００の伝送と、ＴＬフレーム１００に対する波形データや制御データ等の読み書きとを行う機能を有する。これらの機能を実現するために必要なネットワークＩ／Ｆカード２１５の構成の詳細については、特開２００９−９４５８９号公報を参照されたい。
【００６１】
そして、ネットワークＩ／Ｆカード２１５以外のカードは、音響信号処理、アナログ信号の入出力などの機能を担うものであるが、音響信号処理装置１０に持たせたい機能に応じて任意に選択して装着することができる。さらに、ここで挙げたもの以外でも、その他カード２１６として、デジタル入出力、音源、レコーダ、エフェクタ等の、種々のカードモジュールを装着可能とすることが考えられる。
【００６２】
２．ＩＤを利用したデバイスの管理
ところで、上述したオーディオネットワークシステムを構成する各デバイスのように、リモート制御システムにおいて制御装置による制御対象とする各デバイスには、制御装置がそのデバイスを識別するための識別情報として、種々のＩＤを記憶させておく。
次に、このＩＤ及びＩＤを利用したデバイスの管理について説明する。なお、以下の説明において、「実デバイス」の用語を用いるが、これは、現実に存在して制御装置と通信可能な状態であるデバイス（例えば制御装置を含むオーディオネットワークシステムを構成するデバイス）を、後述する仮想デバイスと特に区別するための用語である。
【００６３】
また、以後の説明においては、この実施形態の特徴を説明し易くするため、図１乃至図６を用いて説明してきたようなＴＬフレームの定期的な循環を行うオーディオネットワークシステムを、図６に示すような、コンソール２Ｃｂ、ミキサエンジン２Ｅｘ、および入出力装置２Ｂａ，２Ｂｃ，２Ｂｄ，２Ｂｅ、２Ｂｆ，３Ｂａの８つのデバイスをカスケード接続して構成し、それらのデバイスの全部又は一部をリモート制御システムにおいて制御装置による制御の対象とする場合を例として用いる。図６において、実線がデバイス間の接続ケーブルを、破線がＴＬフレームの伝送経路を示す。
【００６４】
２．１ 各デバイスに記憶させるＩＤ
まず図７に、各デバイスに記憶させるＩＤの例を示す。ここで注目するのは、システムＩＤ、ユニークＩＤ、機種ＩＤ及びデバイスＩＤの４種である。
このうちシステムＩＤは、ＤＳＰカードにおける信号処理に用いるパラメータの設定や、ルーティングの設定など、音響信号処理に関するパラメータのリモート制御（設定）を制御装置から行う場合に、一度に制御の対象とするデバイスの範囲を１つのリモート制御システムとして規定するためのＩＤである。複数のデバイスを複数のシステムに分けて制御する場合、制御装置は、現在の制御対象のシステムを示すシステムＩＤを１つだけ選択し、自身と通信可能なデバイスのうち、そのシステムＩＤを持つデバイスのみを制御対象とする。
【００６５】
なお、システムＩＤは、ユーザが任意に設定可能なＩＤであるが、ここでは、容易に設定できるように、０から１５までの数字等、比較的少ない数の予め用意された選択肢から選択して設定するようにしている。
また、このシステムＩＤは、特開２００９−９４５８９号公報に記載のネットワークＩＤとは異なるものである。ここで、ネットワークＩＤは、一つながりのＴＬフレームの伝送経路（ループ接続の場合には伝送経路は２つになる）を形成するデバイスの範囲を示すＩＤであり、マスタノードが自動的に設定するものである。一方、システムＩＤはユーザが設定するものであるし、共通のシステムＩＤを付すデバイスの範囲は、一つながりの伝送経路が形成される範囲内とするのがよいが、必ずしもその範囲内に限定されるものではない。
【００６６】
ユニークＩＤは、制御装置と通信可能なデバイスのうち、以前から制御装置による制御対象の一群のデバイスとして動作していたデバイスと、そうでない（入れ替えや追加がなされた）デバイスとを制御装置が識別できるようにするために設けたＩＤである。詳細は後述するが、このユニークＩＤは、制御装置がデバイスにおけるパラメータの制御開始のための同期化を行う度に、一意な値を生成して、その時同期化した全てのデバイスに、その生成した値を設定させる。従って、ユーザはこのユニークＩＤの設定を行うことはできない。また、その値を知る必要もない。なお、図では「u2」と記載しているが、実際にはもっと長くて複雑なデータになって構わない。
【００６７】
機種ＩＤは、デバイスが、複数の機種のうちどの機種であるかを示すＩＤである。このＩＤは、デバイスのメーカーが各機種毎に設定する固定的なものであり、ユーザが変更することはできない。図６の例では、各入出力装置は同じ機種であり、同じ機種ＩＤを付している。コンソール２Ｃｂ及びミキサエンジン２Ｅｄは、それぞれ機種が異なるため、機種ＩＤも異なる。
【００６８】
デバイスＩＤは、ユーザが、各デバイスを識別するためにリモート制御システムの各仮想デバイス（後述）および各実デバイスに任意に設定する、例えば、アルファベットの１文字からなるＩＤである。２文字以上のアルファベットであってもよく、１〜３桁の数字、あるいは、アルファベットと数字の組み合わせであってもよい。とにかく、システムを構成する最大数のデバイスを識別できるＩＤであればよく、さらに言えば、ユーザが、限られた選択肢の中から容易に設定できる単純なＩＤとするのがよい。
【００６９】
デバイスＩＤの設定においては、あるシステムＩＤを記憶する異なる２つの実デバイスに同じデバイスＩＤを設定することはできるが、後述のように、ある１つのリモート制御システムの異なる２つの仮想デバイスには同じデバイスＩＤを設定することはできないよう、制限が掛けられている。その意味で、デバイスＩＤは、「リモート制御システム内の複数の仮想デバイスの１を特定するＩＤである」と言える。
【００７０】
なお、デバイスＩＤは、各デバイスを識別するためのＩＤであるから、基本的には各実デバイスに異なる値を設定すべきものである。しかし、リモート制御システムを構成していた実デバイスの一部を故障のため入れ替えたり、制御装置と通信可能な範囲に新たに実デバイスを追加したりしたような場合、たまたま、その入れ替えや追加に係るデバイスと、制御装置と通信可能な範囲の他のデバイスとでデバイスＩＤが一致してしまう場合もあり得る。
【００７１】
このような場合でも、ユニークＩＤを利用して、以前から制御装置による制御対象の一群のデバイスとして動作していたデバイス（１つのリモート制御システムを構成していたデバイス）と、入れ替えや追加に係るデバイスとを、制御装置が区別できるようにした点が、この実施形態の特徴である。
【００７２】
なお、デバイスＩＤはこのように異なる実デバイス間での重複があり得るため、実デバイスを確実に特定したい場合には、デバイスＩＤではなく、各実デバイスのネットワークカードに付与されたユニークなＭＡＣアドレスを用いる。しかし、ＭＡＣアドレスは書き換えられるものではないので、複数の制御装置がある場合、それを基準にして最後にシステムとして制御された複数のデバイスを識別することはできない。
【００７３】
２．２ 制御装置に記憶させる仮想デバイステーブル
次に、制御装置がリモート制御システムにおける制御対象デバイスを特定するために記憶する情報である、仮想デバイステーブルについて説明する。
【００７４】
図８に、この仮想デバイステーブルの例を示す。
この図に示すように、仮想デバイステーブルは、システムＩＤ毎に、それぞれそのシステムＩＤで特定されるリモート制御システムを構成すべき１つの制御対象デバイスを示す仮想デバイスの情報を記憶するテーブルである。仮想デバイステーブルは、ユーザが仮想デバイスを登録したシステムＩＤについてのみ用意すればよく、採りえる全てのシステムＩＤに対応してテーブルを用意する必要はない。また、ＶＤＮは、カッコ内のシステムＩＤについて登録されている仮想デバイスの数を示す変数である。
【００７５】
この仮想デバイステーブルにおいて、各仮想デバイスは、システムＩＤ，機種ＩＤ及びデバイスＩＤを特定して登録する。番号は、登録されている各仮想デバイスに、若い番号「１」から順番に自動付与されるものである。
また、ＭＤは仮想デバイスと対応づけた実デバイスのＭＡＣアドレスである。ＯＦは、仮想デバイスが、制御装置が対応する実デバイスのリモート制御を行うオンライン状態になっているか否かを示すフラグであるが、これらについては後述する。
【００７６】
なお、リモート制御システムへの仮想デバイスの追加ないし削除は、制御装置が実デバイスのリモート制御を行っていないオフライン状態で行われる。従って、仮想デバイスを登録する段階では、各仮想デバイスに対応する実デバイスが在るか否かは気にする必要がない。仮想デバイスは、対応する機種の実デバイスと同じ構成のパラメータを記憶する仮想的なデバイスであり、制御装置では、登録された仮想デバイスに関し、実デバイスと同様に各パラメータ値を編集することができる。
【００７７】
また、制御装置がコンソール２Ｃｂである場合、コンソール２Ｃｂの備えている波形データの信号処理（ＤＳＰ）、入出力（Ａ／Ｄ，Ｄ／Ａ）、送受信（ネットワークＩ／Ｆ）等のオーディオ機能は、それ自体が１つのデバイスに相当するものであって、他のデバイスと同様に、仮想デバイス（コンソール２Ｃｂ）として仮想デバイステーブルに登録される。その際、１つの仮想デバイスとして１つのシステムのみに登録されるようにしてもよいし、機能を複数に分割して、複数の仮想デバイスとして複数のシステムに登録できるようにしてもよい。ただし、コンソール２Ｃｂにおいて、仮想デバイス（コンソール２Ｃｂ）は常時オンラインであり、オフラインになることはない。
図８には、システムＩＤ＝２の仮想デバイス（番号＝７）としてコンソール２Ｃｂを登録した例を示している。
【００７８】
また、制御装置は、図９に示すように、リモート制御システムにおける各仮想デバイスのパラメータを記憶しており、各仮想デバイスが対応付けられた実デバイスとオンラインかオフラインかに関わらず、その各パラメータ値を変更できる。
ここでいうパラメータは、実デバイス内において行われるレベル調整や遅延、イコライザ等の信号処理の特性の制御や、パッチ処理の信号経路の制御、実デバイスのネットワークＩ／Ｆにおける波形データの送信や受信の制御を行う各種パラメータである。
【００７９】
制御装置によるリモート制御とは、これらの動作に使用するパラメータの値を、制御装置が受け付けたユーザ操作に従ってリモートで変更することを意味する。そして、制御装置が実デバイスのリモート制御を開始する際には、その実デバイス内のカレントメモリに記憶されたパラメータと、対応付けられた仮想デバイスのパラメータとの間で、各パラメータ値を同じとするためのコピー（同期化）が行われる。
【００８０】
各実デバイスのカレントメモリに記憶されているパラメータの構成（種類や数）は、その実デバイスの機種、装着されるオプション等に応じて決まる。制御装置には、登録された各仮想デバイスに対応して、その仮想デバイスと対応付けられる実デバイスのカレントメモリに記憶されるパラメータと全く同じ構成のパラメータが記憶される。
【００８１】
上述した同期化は、そのパラメータに関して行うものである。制御装置には、各機種ＩＤの示す機種および、装着される各種オプションに対応してメーカーが用意したパラメータ構成情報が記憶されている。ユーザがシステムにある機種ＩＤの仮想デバイスを登録する際には、その仮想デバイスに対応して、制御装置内に、その機種ＩＤに対応したパラメータ構成情報が示す構成のパラメータ領域が形成される。また、仮想デバイスに実デバイスのオプションに対応づけるための仮想オプションを装着する際には、同パラメータ領域内に同仮想オプションに応じたサブ領域が形成される。
【００８２】
以上のような図９に示すデータは、リモート制御に関する表示のレスポンスをよくするため、リモート制御操作に応じてまず制御装置自身が記憶するパラメータの内容を更新して、制御対象の装置に操作内容を通知する前に先に結果を表示できるようにするために用いることができる。リモート制御の開始に先立って、リモート制御の対象となるデバイスと、その内容について同期を取るのはこのためである。
【００８３】
なお、図９においては、参考のために仮想デバイスの番号を示したが、各仮想デバイスはシステムＩＤとデバイスＩＤのみで特定可能であるから、番号を記憶する必要はない。
また、以上のような制御装置におけるパラメータの記憶及び同期化の対象には、カレントメモリに記憶させて実際の信号処理内容に反映させるデータの他、カレントメモリの内容を保存して後で読み出せるようにしたシーン等のデータを含めるようにしてもよい。
また、制御装置が記憶するパラメータには、複数のシステムが関わる制御を行うためのデータであるシステム制御用パラメータ（制御対象システムＩＤ等）も含まれている。
【００８４】
次に、上述した仮想デバイステーブルの編集に係る処理について説明する。仮想デバイステーブルの編集は、制御装置が記憶する全仮想デバイスがオフラインの場合（後述するオンライン状態になっている仮想デバイスがない場合。ただし制御装置自身が仮想デバイステーブルに登録されている場合には制御装置自身はオンラインになっていてよい）にのみ行うことができる。また、編集に際し、情報を登録あるいは削除しようとする仮想デバイスと対応するデバイスが実際に存在しているかどうかを気にする必要はない。
【００８５】
まず、図１０に、仮想デバイス追加処理のフローチャートを示す。
この処理は、制御装置のＣＰＵ（制御装置がコンソール２Ｃｂである場合にはＣＰＵ２０１であり、ＰＣである場合はそのＰＣのＣＰＵ、以下同様）が、ユーザの操作による仮想デバイス追加指示を検出した場合に実行する処理である。また、追加指示は、例えば、追加する仮想デバイスのシステムＩＤ（ｓとする）、機種ＩＤ（ｋとする）及びデバイスＩＤ（ｄとする）を指定して行うものである。
【００８６】
この処理において、制御装置のＣＰＵはまず、仮想デバイステーブルに既に登録されている仮想デバイス中に、追加指示に係る仮想デバイスとシステムＩＤ及びデバイスＩＤの双方が一致するものがあるか否か判断する（Ｓ１０１）。
なければ、指示に従って仮想デバイスを追加すべく、まずシステムＩＤ＝ｓについての仮想デバイス数ＶＤＮ（ｓ）をインクリメントする（Ｓ１０２）。そして、システムＩＤ＝ｓのシステムについて、機種ＩＤ＝ｋで特定される機種の制御に用いるパラメータの記憶領域を確保すると共に、所定の初期値を設定する（Ｓ１０３）。
【００８７】
次に、仮想デバイステーブルに、システムＩＤ＝ｓのシステムの新たな番号の仮想デバイスのデータとして、機種ＩＤ＝ｋ及びデバイスＩＤ＝ｄを登録する（Ｓ１０４）。その後、登録結果をディスプレイの画面に表示させ（Ｓ１０５）、処理を終了する。
ステップＳ１０１で一致するものがあった場合、重複登録を避けるため、登録エラーをディスプレイの画面に表示させ（Ｓ１０６）、登録せずに処理を終了する。
【００８８】
以上の処理により、ユーザの指示に従って仮想デバイステーブルに新たな仮想デバイスのデータを追加すると共に、その仮想デバイスのパラメータを記憶する記憶領域を用意し、初期値をセットすることができる。また、先述したように、各システムＩＤについて、同じデバイスＩＤの仮想デバイスが重複登録されないようにすることができる。
なお、仮想デバイスの追加指示受付時に、既存の追加デバイスとシステムＩＤ及びデバイスＩＤの双方が一致するものについて、選択肢から外す等して追加の指示を受け付けることができないようにしている場合には、ステップＳ１０１の分岐は不要である。
【００８９】
次に、図１１に、仮想デバイス削除処理のフローチャートを示す。
この処理は、制御装置のＣＰＵが、ユーザの操作や外部装置からの要求による仮想デバイス削除指示を検出した場合に実行する処理である。また、削除指示は、削除する仮想デバイスのシステムＩＤ（ｓとする）及びデバイスＩＤ（ｄとする）を指定して行うものである。
【００９０】
この処理において、制御装置のＣＰＵはまず、削除指示に係るシステムＩＤ＝ｓについて、仮想デバイス数ＶＤＮ（ｓ）をデクリメントする（Ｓ１１１）と共に、削除指示に係るデバイスＩＤ＝ｄで特定される仮想デバイスの制御に用いるパラメータの記憶領域を解放する（Ｓ１１２）。
次に、仮想デバイステーブルから、システムＩＤ＝ｓのシステムの、デバイスＩＤ＝ｄが登録されている仮想デバイスのデータを削除する（Ｓ１１３）と共に、削除結果をディスプレイの画面に表示させ（Ｓ１１４）、処理を終了する。
【００９１】
以上の処理により、ユーザの指示に従って仮想デバイステーブルから仮想デバイスのデータを削除すると共に、そのデバイスの制御に使用するパラメータのデータも削除することができる。
【００９２】
２．３ 仮想デバイスと実デバイスの対応付け
次に、仮想デバイステーブルのデータを用いた、仮想デバイスと実デバイスとの対応付けについて説明する。
この対応付けは、基本的には制御装置が自動的に行うものであるが、一部ユーザの選択に従ったり、また、自動的な対応付けの後ユーザが手動でその内容を変更したりすることができる。また、対応付けの処理自体は、自動であっても手動であっても、仮想デバイステーブルのデータと、各デバイスから収集した図７に示した各ＩＤとに基づいて制御装置が内部的に行う処理であり、それ自体で他のデバイスに影響を与えるものではない。対応付けの結果に基づいてデバイスの制御を開始する処理については、別途後述する。
【００９３】
なお、制御装置がＩＤを収集するデバイスの範囲は、制御装置が接続されているのと同じネットワークに接続された全デバイスである（図６の例ではオーディオネットワークシステムＳに所属するデバイスであるが、ネットワークにおけるデバイスの接続態様や通信プロトコルはこれに限られない）。なお、隣接する１ないし複数のネットワークまで、ネットワーク間のルータを越えてデバイスをサーチし、発見されたデバイスのＩＤを収集するようにしてもよい。ＩＤ収集のための処理の図示は省略するが、制御装置は、ＡＲＰ（Address Resolution Protocol），ＩＣＭＰ（Internet Control Message Protocol）等のプロトコルを使用して定期的にネットワークをスキャンし、新たに接続されたデバイスの検出を行う。そして、デバイスが検出された場合には、該デバイスにＩＤを要求し、その要求に応じて要求先のデバイスが送信してくる、図７に示した各種ＩＤを受信する
【００９４】
なお、各実デバイスは、その実デバイスのネットワークＩ／Ｆカードに付与されたＭＡＣアドレスにより特定できる。ここでは、収集した各ＩＤは、図１２の実デバイステーブルに示すように、各デバイスのＭＡＣアドレスと対応付けて管理するようになっている。また、ＩＤ収集処理では、ネットワークから消滅したデバイスも検出され、消滅したデバイスの情報は実デバイステーブルから削除される。
【００９５】
ここで、図１３に、自動対応付け処理のフローチャートを示す。なお、この処理の説明において、具体的な対応付けの例は、仮想デバイステーブルの内容が図８に示したものであり、制御装置は図６に示したオーディオネットワークシステムＳを構成する各デバイスからＩＤを収集し、その収集したＩＤが、図１２に示すものであるとして説明する。
【００９６】
また、図１３の処理は、制御装置が新たにネットワークに接続され、その制御装置が、そのネットワークに接続されているデバイスを検出したとき（一通り終わるまで待ってからでもよい）、リモート制御システムのリセットが指示されたとき、等に実行されるものである。また、ネットワークに接続された複数のデバイスの電源を投入し、または、制御対象のデバイスが属するネットワークの全デバイスをリセットして、そのネットワークを最初から形成しようとするとき、にも実行される。
【００９７】
そして、これらの場合、制御装置のＣＰＵは自動的に図１３に示す処理を開始する。
この処理において、制御装置のＣＰＵはまず、ＩＤを収集した各デバイスのうち、システムＩＤが、現在の制御対象となっているシステムＩＤを示す変数ＴＧの値と一致するものを、ユニークＩＤが同じもの毎にグループ化する（Ｓ２０１）。
ＴＧ＝２である場合、図１２に示した７つのデバイスのうち、システムＩＤ＝２である６つのデバイスを、ユニークＩＤが「ｕ１」であるグループと、ユニークＩＤが「ｕ２」であるグループと、ユニークＩＤが「none（未設定）」であるグループとに分けることになる。なお、ユニークＩＤが「none（未設定）」であるグループは、作成しなくてもよい。
【００９８】
次に、制御装置のＣＰＵは、ステップＳ２０１で作成したグループ毎に、仮想デバイステーブルに登録されたシステムＩＤがＴＧの各仮想デバイスに対し、グループ内のデバイスのうち機種ＩＤ及びデバイスＩＤが一致するものを対応付ける（Ｓ２０２）。システムＩＤについては、ステップＳ２０１でシステムＩＤがＴＧであるデバイスのみを処理対象としているため、必ず一致する。
【００９９】
例えば、ユニークＩＤが「ｕ１」であるグループについては、番号が２である仮想デバイスが、図１２の一番上のデバイスと対応付けられることになる。ユニークＩＤが「ｕ２」であるグループについては、番号が４である仮想デバイスが、図１２の上から２番目のデバイスと、番号が６である仮想デバイスが、同じく３番目のデバイスと対応付けられることになる。図１２の上から５番目のデバイスについては、対応付ける相手がない。
このステップＳ２０２での対応付けは、優先グループの選択基準とする情報を取得するための予備的な対応付けである。
【０１００】
そして次に、制御装置のＣＰＵは、ステップＳ２０２での各グループについての対応付けの結果に基づき、ステップＳ２０１で作成したグループの１つを優先グループとして選択する（Ｓ２０３）。
この優先グループは、ＩＤの重複があった場合に優先的に仮想デバイスと対応付けるデバイスを規定するグループである。そして、ここでの選択基準は種々のものが考えられ、例えば、対応付けできたデバイスの数が多いグループを選択したり、対応付けの結果をユーザに提示し、ユーザに選択させたり、またはその組み合わせとしたりすることが考えられる。
なお、ステップＳ２０２での結果によらず、ユーザが予めＭＡＣアドレス等により指定しておいたデバイスを含むグループを優先グループとすることも考えられる。この場合、ステップＳ２０１の処理は不要である。
【０１０１】
以上の後、処理はステップＳ２０４のデバイス検索処理に進む。
図１４に、このデバイス検索処理のフローチャートを示す。
この処理において、制御装置のＣＰＵはまず処理対象の仮想デバイスの番号を示す変数ｉに１を設定し（Ｓ２１１）、仮想デバイステーブルに登録された仮想デバイスのうちシステムＩＤ＝ＴＧで番号＝ｉのものと同じシステムＩＤ、機種ＩＤ及びデバイスＩＤを持つデバイスを、ＩＤを収集したデバイスの中から検索する（Ｓ２１２）。そして、検索によりデバイスをいくつ発見したか判断する（Ｓ２１３）。
【０１０２】
ここで、発見数が０の場合、オーディオネットワーシステムＳ中（ＩＤの収集を行った範囲）には、処理対象の（システムＩＤ＝ＴＧで番号＝ｉの）仮想デバイスに対応付けるべきデバイス、すなわちその仮想デバイスに関するデータを用いて制御すべきデバイスがないことがわかる。そこで、その仮想デバイスに対応付けるデバイスのアドレスを示す仮想デバイステーブル（図８参照）のＭＤ（ＴＧ，ｉ）に、対応付けるデバイスがないことを示すｎｕｌｌを設定する（Ｓ２１４）。
また、発見数が１の場合、処理対象の仮想デバイスについては、デバイスＩＤの重複設定はなく、オーディオネットワーシステムＳ中で対応付けるべきデバイスを一意に特定できることがわかる。そこで、ＭＤ（ＴＧ，ｉ）に、発見したデバイスのＭＡＣアドレスを設定する（Ｓ２１５）。先述したように、ＭＡＣアドレスは、実デバイスを特定するための情報であるので、ここでのＭＡＣアドレスを書き込みは、仮想デバイスへの実デバイスの対応付けに相当する。
【０１０３】
一方、発見数が２以上の場合、オーディオネットワーシステムＳ中に、システムＩＤ、機種ＩＤ及びデバイスＩＤにより区別できないデバイスが２以上あり、ＩＤの設定が適切になされていないことがわかる。そこで、ディスプレイにメッセージを表示させる等により、ユーザにこの点を警告する（Ｓ２１６）。
【０１０４】
その後、発見したデバイス中に図１３のステップＳ２０３で選択した優先グループのデバイスがあれば（Ｓ２１７のＹＥＳ）、ＭＤ（ＴＧ，ｉ）にその優先グループのデバイスのＭＡＣアドレスを設定する（Ｓ２１８）。優先グループのデバイスがなければ、発見したデバイスの１つをユーザに選択させ（Ｓ２１９）、ＭＤ（ＴＧ，ｉ）にその選択されたデバイスのＭＡＣアドレスを設定する（Ｓ２２０）。
【０１０５】
ステップＳ２１４，Ｓ２１５，Ｓ２１８，Ｓ２２０のいずれの場合も、ＭＤ（ＴＧ，ｉ）へのデータ設定完了後、ｉをインクリメントし（Ｓ２２１）、仮想デバイスの数ＶＤＮ（ＴＧ）を超えていなければ（Ｓ２２２のＮＯ）、ステップＳ２１２に戻って処理を繰り返す。超えていれば、処理対象のシステムＩＤに関する対応付けは完了であるので、元の処理に戻る。
図１３の説明に戻ると、以上のデバイス検索処理により、自動対応付けは完了するので、対応付け結果をディスプレイの画面に表示させ（Ｓ２０５）、処理を終了する。
【０１０６】
以上の処理により、仮想デバイステーブルに登録されている仮想デバイスのうち、現在の制御対象として設定されているシステムＩＤを有する各仮想デバイスと、制御装置が接続されているオーディオネットワークシステムＳを構成するデバイスとを、デバイス間にユーザが設定するシステムＩＤやデバイスＩＤの重複がある場合でも、ユニークＩＤを参照して適切に自動的に対応付けることができる。
【０１０７】
なお、図１４のステップＳ２１９ではユーザに選択を求めているが、ステップＳ２１７でＮＯになるのは、かなり例外的な場合であり、このような状況になることはほとんどない。しかし、ここで説明している対応付けは、所与のアルゴリズムで決定できない場合でもランダムで行うべきものではないため、念のためステップＳ２１９以下の処理を設けている。
【０１０８】
ここで、例えば、図１３のステップＳ２０３で、優先グループを１つ選択するだけでなく、対応付けできたデバイスの数が多い順にグループに優先順位を付し、図１４のステップＳ２１３で判断が２以上になった場合に、優先順位の高いグループのデバイスを優先的に対応付けるようにすれば、対応付けが自動的に決まらず、ユーザに選択を求める可能性をさらに減らすことができる。
また、複数の制御装置が存在する場合、それらが実デバイスと順次同期化すれば、その度に各デバイスのユニークＩＤが書き換わることになる。本発明では、仮想デバイスとの対応付けができるグループが多いグループを優先することにより、そういった状況であっても、それら各制御装置において、仮想デバイスと実デバイスの適切な対応付けを行うことができる。
【０１０９】
次に、図１５に、同期化処理のフローチャートを示す。
この同期化処理は、制御装置によるデバイスの制御を開始するための処理であるが、同時に、上述の対応付けの際に重要な役割を果たすユニークＩＤの設定を行う処理でもある。
制御装置のＣＰＵは、ユーザの操作によるオンライン移行指示を検出した場合に、その時点でなされている対応付けに従ってオーディオネットワークシステムＳ中のデバイスの制御を開始するため、図１５に示す処理を開始する。
【０１１０】
この処理において、制御装置のＣＰＵはまずユニークなＩＤを生成する（Ｓ２３１）。生成方法は問わないが、オーディオネットワークシステムＳと同種のシステムが運用される範囲で重複がないと期待できる程度のユニークさが望ましく、例えば、制御装置のＭＡＣアドレスと生成時点の時刻とを含むＩＤとすることが考えられる。また、ユニークＩＤをＵＵＩＤ（汎用一意識別子：Universally Unique Identifier）やＧＵＩＤ（グローバル一意識別子）などに基づいて生成してもよい。
【０１１１】
そして、生成したユニークなＩＤを、仮想デバイステーブルに登録されている仮想デバイスのうち、現在の制御対象を示すシステムＩＤ（＝ＴＧ）を有する全ての仮想デバイスについて、その仮想デバイスと対応付けられているデバイスに送信し、ユニークＩＤとして記憶するよう要求する。ここでは、システムＩＤ＝ＴＧの仮想デバイステーブルに登録されている全ての仮想デバイスの番号ｉについて、それぞれＭＤ（ＴＧ，ｉ）に設定したＭＡＣアドレスを宛先として送信を行えばよい（Ｓ２３２）。ただし、ＭＤ（ＴＧ，ｉ）の値がｎｕｌｌのものについては、送信不要である。また、ＭＡＣアドレスが、上述の自動対応付けにより設定されたものであるか、後述する手動対応付けにより設定されたものであるかを考慮する必要はない。
【０１１２】
また、デバイスのリモート制御に関するデバイス間のあらゆる送信は、すべて、イーサネットの通信帯域を使用して行われる。ここでは、ＭＡＣ層の処理として説明されているが、ＭＡＣ層の上のインターネット層の処理とすることも可能であり、その場合、インターネットパケットに書き込まれる宛先アドレスは、ＭＡＣアドレスに対応するデバイスのＩＰアドレスである。何れの場合であっても、ＭＡＣ層においてはイーサネットフレームには同じＭＡＣアドレスが記載され、同じデバイス宛てに送信される。
【０１１３】
そして、ステップＳ２３２で送信される情報を受信した宛先のデバイスは、要求に応じて、受信したＩＤをユニークＩＤとして設定する（Ｓ１３１）。
また、制御装置のＣＰＵは、ステップＳ２３２の後、実デバイスが対応付けられているシステムＩＤ＝ＴＧの各仮想デバイスにつき、その仮想デバイスのパラメータと、対応付けられた実デバイスのカレントメモリのパラメータとを、ユーザが指定した方向に同期化させる（Ｓ２３３）。この同期化は、何れか一方のパラメータをコピー元、他方のパラメータをコピー先として、１デバイス分の全パラメータをコピーして、それらの値を相互に一致させることによって行う。また、コピーするパラメータの転送は、転送元の制御装置ないしデバイスのパラメータを複数の部分に分けて各部分毎にダンプし、ダンプされたデータをイーサネットフレームに記載して、コピー先のデバイスないし制御装置に転送することにより、実行できる。コピー先のデバイスないし制御装置は、転送されたパラメータを既存のパラメータに上書きする。
【０１１４】
ここで、上述のように、各実デバイスは、制御装置に記憶されている仮想デバイスのパラメータではなく、デバイス自身が記憶しているパラメータの値に従って、信号伝送や信号処理を行う。そこで、この処理の状態を維持することを優先する場合（例えば、稼働中のシステムのネットワークに後から制御装置を接続し、そのシステムの動作を継続させたい場合など）には、各実デバイスのカレントメモリのパラメータをコピー元とし、制御装置の対応付けられた仮想デバイスのパラメータをコピー先とすればよい。
【０１１５】
一方、制御装置の記憶している仮想デバイスのパラメータに従った信号処理を各実デバイスに行わせたい場合（例えば、新たなネットワークシステムあるいはリモート制御システムを稼動させたい場合や、稼働中のシステムを止めて別の論理構成のシステムを立ち上げたい場合など）は、制御装置の各仮想デバイスのパラメータをコピー元とし、対応付けられた実デバイスのカレントメモリのパラメータをコピー先とすればよい。
ユーザは、どちらの方向に同期化を行うかを、全仮想デバイスについて一括して、又は仮想デバイス毎に個別に設定することができる。
【０１１６】
そして、制御装置のＣＰＵは、以上の同期化の後、同期化した全ての仮想デバイスにつき、仮想デバイステーブルのフラグＯＦを「１」に設定してその仮想デバイスが対応付けられた実デバイスとオンラインになった旨を記憶する（Ｓ２３４）と共に、各仮想デバイスがオンラインかオフラインかを区別してディスプレイの画面に表示させてユーザに通知し（Ｓ２３５）、処理を終了する。
【０１１７】
なお、ある仮想デバイスがオフラインの場合、フラグＯＦの値は「０」であり、制御装置でユーザがその仮想デバイスのパラメータ値の変更操作をすると、制御装置が記憶するその仮想デバイスのパラメータの値のみが変更される。対応付けられた実デバイスがあったとしても、そのパラメータ値は変更されず、リモート制御は行われない。
【０１１８】
一方、ある仮想デバイスが対応付けられた実デバイスとオンラインの場合には、オンライン移行時の同期化処理でその仮想デバイスと実デバイスは同じ値のパラメータを記憶している。そして、制御装置でその仮想デバイスのパラメータ値を変更すると、その変更が対応する実デバイスに通知され、その実デバイスにおいても同様にパラメータ値が変更される。また、その実デバイスを操作して実デバイスのパラメータ値を変更すると、その変更が制御装置に通知され、対応する仮想デバイスのパラメータ値が同様に変更される。このように、オンライン状態にある場合、制御装置の仮想デバイスと実デバイスとでパラメータの値が連動しており、制御装置でその仮想デバイスのパラメータ値を変更することにより、対応する実デバイスのパラメータ値を変更して、その実デバイスの動作をリモート制御することができる。
【０１１９】
以上の処理により、制御装置がＩＤを収集した実デバイスのうちの、何れかの仮想デバイスと対応付けられた各実デバイスは、対応する仮想デバイスとオンラインとなり、制御装置からのリモート制御を受け付ける。その際、オンラインとなった各実デバイスには、制御装置が新たに生成した１つのユニークＩＤが記憶される。そして、このユニークＩＤは、別の制御装置をネットワークに接続するとき、ないし、同じ制御装置をネットワークから一旦切り離して再接続する際の、図１３に示す自動対応付け処理で参照する。なお、制御装置を新たにネットワークに接続して、最初に図１５の処理を実行する前は、その制御装置の全ての仮想デバイスはオフラインである。
【０１２０】
また、図１５の処理でオンラインになった仮想デバイスは、対応するデバイスがオーディオネットワークシステムＳから除外されたり、動作を停止するなどして制御装置と該当デバイスとの接続が切れたりした場合に、オフラインに戻る。また、ユーザによるオフライン移行指示があった場合には、制御装置のＣＰＵが全仮想デバイスをオフラインに戻す。
また、図１５の処理では、実デバイスが対応付けられた全ての仮想デバイスの同期化を行っているが（ステップＳ２３３）、同期化処理の開始時に既にオンラインの仮想デバイスがある場合、その仮想デバイスは既に対応付けられた実デバイスとパラメータが同期しているので、その仮想デバイスに関する同期化の処理を省略してもよい。
【０１２１】
ところで、図１３の処理での自動対応付けや図１５の処理での同期化は、現在の制御対象として設定されているシステムＩＤを持つ仮想デバイスについてのみ行ったが、この「現在の制御対象」を示すシステムＩＤは、ユーザが制御装置のユーザインタフェースを操作して変更可能である。なお、１つの制御装置が複数のシステムＩＤのシステムを任意に切り替えて制御する場合、その制御装置に各システムの情報（仮想デバイステーブル、仮想デバイスのパラメータ等）を独立して記憶するようにすれば、制御対象のシステムの変更をレスポンスよく行うことができる。
【０１２２】
図１６に、この変更のための処理を示す。
制御装置のＣＰＵは、現在の制御対象を示すシステムＩＤを変更するための制御対象システム設定指示を検出すると、図１６に示す処理を開始する。
そしてまず、オンライン中の仮想デバイスを全てオフラインにすると共に（Ｓ２４１）、指示に従って、現在の制御対象を示すシステムＩＤの値を変数ＴＧに設定する（Ｓ２４２）。そしてその後、その新たに設定したＩＤ値を用いて、図１３に示した自動対応付け処理を行って（Ｓ２４３）、処理を終了する。
なお、制御対象システムの設定指示を、全仮想デバイスがオフラインの場合のみ行うことができるようにした場合は、ステップＳ２４１の処理は不要である。
【０１２３】
以上の処理により、常に、現在の制御対象として設定されているシステムＩＤを有する仮想デバイスが、オーディオネットワークシステムＳを構成する（制御装置がＩＤを収集した範囲の）適当なデバイスと対応付けられ、オンライン状態にすることにより制御装置から制御可能な状態を保つことができる。
従って、例えばシステムＩＤが「３」であるデバイスを制御したい場合には、ユーザは、現在の制御対象を示すシステムＩＤを「３」に設定した上で、図１５の処理の実行を指示するオンライン移行指示を行えばよい。
【０１２４】
以上のようにシステムＩＤで制御対象を区別することにより、複数の異なるリモート制御システムを制御対象として指定して、そのリモート制御システムを構成すべき実デバイスをリモート制御することができるようになる。なお、異なるリモート制御システムの仮想デバイスを、同時にオンラインにできるようにすることもできる。その場合であっても、制御対象として指定されるシステムＩＤは制御装置で１つだけとして、何れか１つのシステムのみを制御対象としてリモート制御するのがよい。
【０１２５】
また、図１３の処理により行われた、仮想デバイスと実デバイスとの対応付けは、ユーザが制御装置のユーザインタフェースを操作して手動で変更することもできる。
図１７に、この変更のための手動対応付け処理のフローチャートを示す。
制御装置のＣＰＵは、ユーザから、仮想デバイスの指定と共にその仮想デバイスに関する手動対応付けを指示された場合に図１７のフローチャートに示す処理を開始する。なお、指定できるのは、現在の制御対象を示すシステムＩＤ（ＴＧとする）を有する仮想デバイスのみである。
【０１２６】
図１７の処理において、制御装置のＣＰＵはまず、対応付けを指示された仮想デバイスをオフラインにする（Ｓ２５１）。この場合、その仮想デバイスと対応する実デバイスがあれば、そのデバイスの制御を中止するが、中止に応じてその仮想デバイスの制御に用いる制御パラメータの値を変更する必要はない。また、もともとオフラインであれば、何もしなくてよい。
また、手動対応付けの指示を、全部の仮想デバイスがオフラインの場合、ないし、対象の仮想デバイスがオフラインの場合にのみ行うことができるよう制限した場合は、ステップＳ２５１の処理は不要である。
【０１２７】
次に、指示に係る仮想デバイスに対応付けることができる実デバイスの候補として、その仮想デバイスとシステムＩＤ、機種ＩＤ及びデバイスＩＤが一致する実デバイスを、ＩＤを収集してあるデバイスの中から検索する（Ｓ２５２）。この検索範囲は、実デバイスの追加や除去がなければ、図１４のステップＳ２１２の場合と同じである。
そして、ここで検索されたデバイスの１つを、仮想デバイスに対応付ける実デバイスとしてユーザに選択させ（Ｓ２５３）、指示に係る仮想デバイスについての対応する実デバイスのアドレスＭＤ（ＴＧ，ｉ）に、選択されたデバイスのＭＡＣアドレスを設定する（Ｓ２５４）と共に、対応付け結果をディスプレイの画面に表示させて（Ｓ２５５）、処理を終了する。
【０１２８】
以上の処理により、自動対応付け処理による対応付けの内容がユーザの希望と合わない場合に、ユーザが対応付けの内容を事後的に変更することができる。この手動での対応付けの際には、システムＵＩＤと実デバイス側のユニークＩＤとの一致／不一致を気にする必要はない。また、手動により変更された仮想デバイスと実デバイスの対応付けは、この後、ユーザがオンラインへの移行を指示し、図１５の同期化処理が実行することにより、ネットワークに接続された実デバイスに反映される。その際、制御装置は新たなユニークＩＤを生成し、生成されたユニークＩＤは各実デバイスに記憶される。
【０１２９】
なお、ＩＤを収集する範囲内に、システムＩＤ、機種ＩＤ及びデバイスＩＤの一致するデバイスが２つ以上存在しない通常の場合には、ステップＳ２５２の検索で発見されるデバイスは最大１つである。この場合、ステップＳ２５３で選択を受け付ける必要はないが、代わりに、発見されたデバイスを対応付けるか否かの選択を受け付けるようにするとよい。
【０１３０】
逆に、ステップＳ２５２で複数のデバイスが発見される場合、それらのデバイスはシステムＩＤ、機種ＩＤ及びデバイスＩＤが共通であるので、ステップＳ２５３での選択受付時には、これ以外の情報、例えばＭＡＣアドレスを提示して、発見された複数のデバイスをユーザが区別できるようにする。あるいは、発見された各実デバイスに対応するボタンをディスプレイ画面上に表示し、ユーザの操作に応じて、対応する実デバイスに反応指示を送信し、受信した実デバイスが本体の表示器を点滅させる、等して区別できるようにしてもよい。
【０１３１】
２．４ システムの構成変更時の対応
次に、制御装置により実デバイスをリモート制御中に、ネットワークに対して実デバイスが追加されたり、実デバイスのシステムＩＤやデバイスＩＤが変更されたりした場合でも、仮想デバイスと実デバイスとの対応付けを適切に維持し、制御装置によるデバイスの制御を継続できるようにするための処理について説明する。
【０１３２】
まず、図１８に、制御装置のＣＰＵが、ネットワークに新たに接続されたデバイスを検出した場合に実行する処理のフローチャートを示す。
図６に示したオーディオネットワークシステムＳでは、特開２００９−９４５８９号公報に記載のものと同様、ＴＬフレームの巡回を継続しつつ、カスケード接続されたデバイス上に形成されるループ上のフレーム伝送路を動的に変更することができる。新たなデバイスがカスケード接続されているデバイス群の端部に接続された場合は、そのデバイスを含むようにフレーム伝送路が変更され、既存のデバイスとそのデバイスとの間でのオーディオ伝送やイーサネットフレーム伝送が可能となる。
【０１３３】
そしてこの場合、制御装置と新たに接続されたデバイスとの間のイーサネットフレーム伝送が可能となり、制御装置による上述したネットワークスキャンにより、新たに接続された実デバイスを発見することができる。そこで、そのデバイスを発見した制御装置は、図１８のフローチャートに示す処理を開始する。
この処理において、制御装置のＣＰＵはまず、新たに接続された実デバイスからＭＡＣアドレス、システムＩＤ、ユニークＩＤ、機種ＩＤ及びデバイスＩＤを取得し、図１２に示したような既知デバイスの情報（実デバイステーブル）に追加する（Ｓ２７１）。
【０１３４】
そして、新たに接続された実デバイスのシステムＩＤが、現在の制御対象を示すシステムＩＤ（ＴＧとする）と一致するか否か判断する（Ｓ２７２）。ここで一致していれば、仮想デバイステーブルから、新たに接続された実デバイスとシステムＩＤ、機種ＩＤ及びデバイスＩＤの全てが一致する仮想デバイス、すなわち新たに接続された実デバイスと対応付けることができる仮想デバイスを検索する（Ｓ２７３）。
【０１３５】
そして、もしあれば（Ｓ２７４のＹＥＳ）、発見した仮想デバイスの番号をｉとし（Ｓ２７５）、ＭＤ（ＴＧ，ｉ）＝Ｎｕｌｌであれば、すなわち発見した仮想デバイスに対応付けられているデバイスがなければ（Ｓ２７６のＹＥＳ）、ＭＤ（ＴＧ，ｉ）に新たに接続された実デバイスのＭＡＣアドレスを設定して、発見した仮想デバイスに新たに接続された実デバイスを対応付ける（Ｓ２７７）と共に、その対応付け結果をディスプレイの画面に表示させてユーザに通知し（Ｓ２７８）、処理を終了する。
【０１３６】
一方、ステップＳ２７２でＮＯの場合には、新たに接続された実デバイスは現在は制御装置による制御対象とならないデバイスであるので、この時点では対応付けは行わず、そのまま処理を終了する。
ステップＳ２７４でＮＯの場合には、新たに接続された実デバイスを対応付けることのできる仮想デバイスがないことがわかるため、その旨をユーザに警告して（Ｓ２７９）、処理を終了する。
また、ステップＳ２７６でＮＯの場合には、新たに接続されたデバイスを対応づけるべき仮想デバイスには既に実デバイスが対応付けられていて、デバイス間でシステムＩＤ、機種ＩＤ及びデバイスＩＤの設定が重複していることがわかる。そこで、その旨をユーザに警告して（Ｓ２８０）、処理を終了する。なお、この場合には、図１７に示した手動対応付け処理により、その対応付けるべき仮想デバイスに新たに接続された実デバイスを対応付けるよう変更することができる。
【０１３７】
以上説明してきた図１８の処理によれば、制御装置がＩＤを収集する範囲のネットワークに新たにデバイスが追加された場合でも、制御装置がそのデバイスを適切に仮想デバイスに対応付けることができる。この後、ユーザがオンラインへの移行を指示し、図１５の同期化処理を実行することにより、対応付けの内容がネットワークに接続された実デバイスに反映される。
【０１３８】
次に、制御装置によるリモート制御の対象となり得るデバイスにおけるデバイスＩＤ及びシステムＩＤを設定する場合の処理について説明する。
各デバイスのデバイスＩＤ及びシステムＩＤの設定（変更）は、そのデバイスが全ての制御装置の仮想デバイスとオフラインである場合に、ユーザが操作子２０６を操作することで行われる。
【０１３９】
この場合、該当デバイスは、ユーザが入力したＩＤを新たに設定されるデバイスＩＤ又はシステムＩＤとしてフラッシュメモリ２０２として記録すると共に、フラッシュメモリ２０２に記録してあったユニークＩＤをクリアする。そしてこのことにより、どの制御装置においても、図１３のステップＳ２０１におけるグループ化の対象外となる。しかし、変更後のシステムＩＤとデバイスＩＤの組が重複しているデバイスが他になければ（図１４のステップＳ２１３での発見数が１であれば）、グループ化されたか否かに関わらず、ＩＤを変更したデバイスを適当な仮想デバイスと対応付けることができる。
なお、実デバイスが何れかの仮想デバイスとオンラインである場合には、その実デバイスにおいてデバイスＩＤ及びシステムＩＤの設定を行うことはできない。
【０１４０】
２．５ 対応付けの具体例
次に、制御装置が以上説明してきた各種ＩＤ及び仮想デバイステーブルを用いて行う制御対象デバイスの認識について、図１９に示す具体例を用いて説明する。
図１９に示す例において、実線の枠はこの発明の実施形態のリモート制御システムにおける制御対象のデバイスを含むネットワークシステム（図６に示したものとは異なる）を構成する１つ１つの実デバイスを示す。そして、その枠内の文字は、そのデバイスが記憶しているＩＤを、「システムＩＤ，ユニークＩＤ／機種ＩＤ／デバイスＩＤ」の書式で示している。なお、これらのＩＤは、分かりやすいように単純な数字や文字により記載しているが、特にユニークＩＤについては、一意性を確保するためにより長いデータ長（ビット数）とする必要があり、とにかく、何れのＩＤについても、実際の装置に適用する際にこのような形式を採ることが好ましいという意味ではない。
【０１４１】
また、図中の「システムを構成するデバイス」及び「オンライン後の各デバイスの状態」における各実デバイスの縦方向における位置は、ネットワークシステムにおける各デバイスの物理的な接続順ではなく、個々のデバイスを特定するもの（ＭＡＣアドレスに相当）である。すなわち、この図中の異なる場所の、縦方向の位置が同じデバイスは、同じ実デバイスに相当する。
【０１４２】
そして、「オンライン後の各デバイスの状態」の欄では、いずれかの仮想デバイスと対応付けられている実デバイスを示す枠を太線で、仮想デバイスと対応付けられていない実デバイスを示す枠を通常の線で記載している。
また、破線の枠は、仮想デバイステーブルに登録されている１つ１つの仮想デバイスのデータを示す。そして、その枠内の文字は、その仮想デバイスについて設定されているＩＤを、「システムＩＤ／機種ＩＤ／デバイスＩＤ」の書式で示している。仮想デバイスの番号については、図示していない。
そして、各仮想デバイスに対応付けられるデバイスがある場合、図で中央の欄において、仮想デバイスを示す枠と実デバイスを示す枠とを実線で結んでこれを示している。
【０１４３】
まず、図１９に示す例では、（ａ）の「システムを構成するデバイス」の欄に示す５台の実デバイス（制御装置がこれらのデバイス以外の装置である場合にはこれらに加えて不図示の制御装置）がネットワークシステムを構成し、仮想デバイステーブルにはそれらの実デバイスを示す仮想デバイスが適切に設定されている状態において、ネットワークシステムを構成する実デバイスをスペアと入れ替える場合を考える。
この場合、現在の制御対象を示すシステムＩＤとして図に示す「１」が設定されていれば、図１３に示した自動対応付け処理により、図に示すように、ネットワークシステムを構成する全ての実デバイスが仮想デバイスに対応付けられ、制御装置による制御の対象となる。
【０１４４】
そして、制御装置において仮想デバイスをオンラインにすると、図１５の同期化処理により各デバイスとの間でパラメータの同期化が行われると共に、新たに生成したユニークＩＤが、制御対象となっている各実デバイス（ここでは図示した全てのデバイス）に設定される。
この状態は、デバイスを入れ替えたり仮想デバイステーブルの内容を変更したりしなければ、何度電源オンオフやシステムの再起動を行っても、同様に維持される（ただし、設定されるユニークＩＤの値自体はオンライン化の動作を行うたびに変わる）。
【０１４５】
また、故障等の理由により実デバイスを入れ替えても、入れ替え後の実デバイスにシステムＩＤ、機種ＩＤ及びデバイスＩＤが仮想デバイステーブルの内容と対応するように適切に設定されていれば、ユニークＩＤが他の実デバイスと統一されていなくても、入れ替え前と同様に対応付け及び制御装置による制御が可能である（図１３のステップＳ２０１のグループ化では入れ替えた実デバイスは別グループになるが、図１４のステップＳ２１３で発見数が「１」となるため、グループ分けの影響はない）。一旦オンライン化を行えば、ユニークＩＤも他の実デバイスと統一される。
【０１４６】
しかし、（ｂ）に示すように、入れ替え後の実デバイスに、古い設定の変更し忘れなどにより、誤って、入れ替えを行っていない（以前からネットワークにおいて制御装置による制御の対象であった）実デバイスのいずれかと全く同じシステムＩＤ、機種ＩＤ及びデバイスＩＤが設定されてしまっている場合には、これらのＩＤだけではどちらが入れ替えた実デバイスでどちらが入れ替えを行っていない実デバイスであるか、区別することができない。
【０１４７】
例えば、（ｂ）に示す例では上から２番目の実デバイスと６番目の実デバイスでシステムＩＤ、機種ＩＤ及びデバイスＩＤが一致しているため、図１４のステップＳ２１２で上から２番目の１／Ａ／ｂの仮想デバイスと対応付ける実デバイスを検索した際、これらの２つの実デバイスが発見される。
しかし、入れ替えた上から６番目の実デバイスには、入れ替えを行っていない２番目の実デバイスとは異なるユニークＩＤが設定されている。従って、その前の図１３のステップＳ２０１で異なるグループに分けられる。
【０１４８】
そして、２番目の実デバイスが属するグループが図１３のステップＳ２０３で優先グループとして選択されるようにしておけば、図１４のステップＳ２１７及びＳ２１８で、２番目の仮想デバイスに、入れ替え前の状態で対応付けられていたものと同じ、２番目の実デバイスを自動的に対応付けることができる。
ここで、通常は、入れ替えを行う実デバイスより、入れ替えを行っていない実デバイスの方が数が多いと考えられる。そこで、図１３のステップＳ２０３での優先グループの選択基準を、ステップＳ２０２で対応付けのできた実デバイスの数が最も多いグループとすれば、多くの場合に、入れ替えていない実デバイスで構成されるグループが優先グループになるようにすることができると考えられる。図１９の例では、この基準を採用しているとして説明する。
【０１４９】
以上の通りであるので、（ｂ）に示す状態では、５つの仮想デバイスのうち４つに、図示のように実デバイスが対応付けられる。システムＩＤ、機種ＩＤ及びデバイスＩＤが共通なデバイスについても、以前から制御対象になっていた実デバイスを適切に見分けて対応付けを行うことができる。
【０１５０】
デバイスの入れ替え等においては、以前から制御対象になっていた実デバイスの設定はそのままとして、新たに入れるデバイスの設定を変更する場合が多い。そのため、設定ミスは、新たに入れる実デバイスで生じている確率が高い。そこで、本実施形態の自動割当処理では、設定ミスの確率が低いと考えられる、以前から制御対象になっていた実デバイスを、仮想デバイスに優先的に割り当てるようになっている。
【０１５１】
なお、（ｂ）の対応付けがなされた状態で各仮想デバイスをオンラインにすると、対応付けがなされた４つの実デバイスについてのみ同期化が行われ、共通の新たなユニークＩＤ（ｕ２）が設定される。一方、仮想デバイスと対応付けられていない６番目の実デバイスのユニークＩＤは更新されない。従って、６番目の実デバイスのみ他の実デバイスとユニークＩＤが異なるという状態は、オンライン後も維持される。また、実デバイスをさらに入れ替えたり仮想デバイステーブルの内容を変更したりしなければ、次に電源がオンされたりシステムの再起動がされたりした場合も、同様な対応付けにより、６番目の実デバイスのみ他のデバイスとユニークＩＤが異なるという状態が維持される。
【０１５２】
また、上述のように、各実デバイスに設定されているデバイスＩＤは変更可能である。そこで、ユーザは、（ｂ）の状態において、６番目の実デバイスのデバイスＩＤを「ｂ」から「ｃ」に変更して、仮想デバイスと対応する「正しい」設定とすることができる。
この設定を行った状態が（ｃ）である。この状態でも、図１３のステップＳ２０１のグループ化では３番目の実デバイスは他の実デバイスと別グループになる。しかし、ネットワーク内に、システムＩＤ、機種ＩＤ及びデバイスＩＤが重複するデバイスがなく、全ての仮想デバイスについて図１４のステップＳ２１３で発見数が「１」となるため、グループ分けに関係なく、実デバイスを対応付けることができる。そして、一旦オンライン化を行えば、ユニークＩＤも他の実デバイスと統一され、実質的に（ａ）と同様な、適切な制御の可能な状態になる。
なお、入れ替えた実デバイスに入れ替え時点から適切なＩＤの設定がなされていれば、（ａ）の状態から（ｂ）を経ずに（ｃ）の状態へ移行する。
【０１５３】
３．第２の実施形態
次に、この発明のリモート制御システムの第２の実施形態について説明する。
上述した第１の実施形態においては、仮想デバイスと実デバイスの対応付けに変更があったか否かに関わらず同期化処理を行う度にユニークＩＤを更新するようにしていたが、この第２の実施形態では、対応付けに変更があった場合にのみユニークＩＤを更新するようにした点が、第１の実施形態と異なる。また、各制御装置が、制御対象デバイスに記憶させた最新のユニークＩＤを記憶しておき、実デバイスが記憶しているユニークＩＤがこれと一致するか否かに応じて、その実デバイスに対して異なる取扱いをするようにした点も、第１の実施形態と異なる。
そこで、この相違点及びそれに関連して処理内容を変更すべき点についてのみ説明する。
【０１５４】
３．１ 制御装置に記憶させる仮想デバイステーブル
まず、図２０に、この実施形態において制御装置が記憶する仮想デバイステーブルの例を示す。
この図に示すように、仮想デバイステーブルに、上記の「制御対象デバイスに記憶させた最新のユニークＩＤ」を、システムＵＩＤとして、システムＩＤ毎に登録する。例えば、システムＵＩＤ（２）＝u2は、システムＩＤが「２」のシステムにおいて最後に制御対象デバイスに記憶させたユニークＩＤが「u2」であることを示す。
【０１５５】
なお、このユニークＩＤは、自身で生成した場合には、後述する図２３のステップＳ３２３で生成及び設定するものである。また、自身でユニークＩＤの生成及び設定を行った後で他の制御装置がユニークＩＤの生成及び設定を行った場合には、該他の制御装置からそのユニークＩＤを含む仮想デバイステーブルが通知され、ユーザの指示に応じて図２４のステップＳ３４３で設定する。
【０１５６】
仮想デバイステーブルに登録するその他の情報については、第１の実施形態の場合と同じであり、図１０や図１１の処理による仮想デバイスの追加や削除も同様に行うことができる。
なお、第１の実施形態の場合には、仮想デバイスと対応付けられている実デバイスのＭＡＣアドレスを示すＭＤの値は、制御装置のリセット時や電源ＯＦＦ時には削除してしまってもよかったが、第２の実施形態の場合には、リセット時や電源ＯＦＦ時でもＭＤの値を保持しておく。
【０１５７】
３．２ 仮想デバイスと実デバイスの対応付け
次に、図２１に、自動対応付け処理のフローチャートを示す。この処理は、第１の実施形態で図１３に示した処理と対応するものである。そして、この処理も、図１３の場合と同様、制御装置が新たにネットワークに接続された場合や、リモート制御システムのリセットが指示された場合などに制御装置のＣＰＵが自動的に実行する。
この処理において、制御装置のＣＰＵはまず、ＩＤを収集した各実デバイスのうち、システムＩＤが、現在の制御対象となっているシステムＩＤを示す変数ＴＧの値と一致するものを選定する（Ｓ３０１）。
【０１５８】
そして、仮想デバイステーブルに登録されたシステムＩＤの値がＴＧの各仮想デバイスに対し、ステップＳ３０１で選定した実デバイスのうち機種ＩＤ及びデバイスＩＤが一致するものを対応付ける（Ｓ３０２）と共に、システムＩＤがＴＧのデバイスに記憶させた最新のユニークＩＤ＝システムＵＩＤ（ＴＧ）の値を準備する（Ｓ３０３）。このシステムＵＩＤ（ＴＧ）の値が、必ずしも図２１の処理を実行中の制御装置自身が生成した値とは限らないことは、上述の通りである。
【０１５９】
制御装置のＣＰＵは、その後、ｉを１からシステムＩＤがＴＧの仮想デバイスの数ＶＤＮ（ＴＧ）まで順次増加させながら、ステップＳ３０２で行った対応付けの内容を確認する処理（Ｓ３０４〜Ｓ３０９）を行う。
この際の確認において重要なポイントの１つは、ステップＳ３０２で対応付けられた実デバイスに、仮想デバイスとＭＡＣアドレスが一致し、かつシステムＵＩＤ（ＴＧ）とユニークＩＤが一致する実デバイスが含まれているか否か、という点である。
【０１６０】
仮想デバイスと対応付けた実デバイスとでＭＡＣアドレスが一致していることにより、自機においてその仮想デバイスに対応付けてある実デバイスと同じ個体が、今回の自動対応付けの時点でも依然として自機と同じネットワークに接続されており、自機からリモート制御可能な状態であることがわかる。また、同じくユニークＩＤがシステムＵＩＤ（ＴＧ）と一致していることにより、その対応付けてある実デバイスが、最新のオンライン移行指示（自機が行ったものか他の制御装置が行ったものかは問わない）の際にオンラインになったデバイスであることがわかる。
【０１６１】
従って、上記のＭＡＣアドレス及びユニークＩＤの一致を確認できれば、該当の実デバイスは、過去にも仮想デバイスと対応付られていたデバイスであり、自機の把握していないところで仮想デバイスとの対応付けが変更されてリモート制御システムから除外されているようなこともなく、自機の仮想デバイステーブルに登録されている対応付け（ＭＤの値）を維持して問題ないデバイスであると考えることができる。このような意味で、上記のＭＡＣアドレス及びユニークＩＤの一致を確認できたデバイスを、「既知デバイス」と呼ぶことにする。
【０１６２】
そして、ステップＳ３０２でｉ番目の仮想デバイスと対応付けられた実デバイス、すなわち仮想デバイスとシステムＩＤ、機種ＩＤ及びデバイスＩＤの一致するデバイス（システムＩＤの一致はステップＳ３０１で保証される）が、既知デバイス１つのみであれば、その仮想デバイスについて、実デバイス側にＩＤの設定漏れや重複等の不備はなく、対応付けの変更も必要ないことがわかる。すなわち現在の設定に問題ないことがわかる。
従って、ステップＳ３０５での判断結果がこのようなものであった仮想デバイスについては、特に何の処理も行わず、それまでの設定内容を維持する。設定に問題がない旨をユーザに通知してもよい。
【０１６３】
また、ステップＳ３０２でｉ番目の仮想デバイスと対応付けられる実デバイスがなかった場合には、ｉ番目の仮想デバイスと対応付けるべき実デバイスは自機が接続されているネットワークシステムに含まれていないことがわかる。この場合、該当する仮想デバイスの制御はできないが、第１の実施形態の場合と同様、それ以上の問題はなく、この時点で対応付けの内容を変更する必要もない。
従って、ステップＳ３０５での判断結果がこのようなものであった仮想デバイスについても、特に何の処理も行わず、それまでの設定内容を維持する。対応する実デバイスがない旨をユーザに通知してもよい。
【０１６４】
一方、ステップＳ３０２でｉ番目の仮想デバイスと対応付けられた実デバイスが既知デバイスを含む複数のデバイスであった場合、対応付け自体には深刻な問題はないが、ネットワークシステム内にシステムＩＤ、機種ＩＤ及びデバイスＩＤの重複する複数の実デバイスが存在することになり、実デバイスにおけるＩＤの設定が適切になされていないことがわかる。従って、ユーザにその旨を警告する（Ｓ３０６）。図１７のステップＳ２５３の場合と同様な手法により、どのデバイスが既知デバイスで、どのデバイスがその他の対応付けられたデバイスであるかをユーザが区別できるようにしてもよい。
そして、この警告を受けたユーザは、実デバイスにおけるＩＤの設定を変更して重複を解消したり、手動対応付けにより仮想デバイスと対応付ける実デバイスを変更したりする対応を行うことが考えられる。
【０１６５】
ここで、手動対応付け処理は、第１の実施形態において図１７を用いて説明したものと概ね同様である。しかし、図２２に示すように、手動対応付けにより実際に対応付けの内容（仮想デバイステーブルにおけるＭＤの値）が変更された場合に、システムＩＤ＝ＴＧのシステムにおける同期化処理時のユニークＩＤ更新要否を示すフラグＣＦ（ＴＧ）に更新要を示す「１」を設定する処理（Ｓ３１１，Ｓ３１２）が追加されている点が、図１７の場合と異なる。
【０１６６】
図２１の説明に戻ると、ステップＳ３０２でｉ番目の仮想デバイスと対応付けられた実デバイスが既知デバイスを含まない１又は複数のデバイスであった場合、２つの可能性及びその複合が考えられる。
【０１６７】
まず、対応付けられた実デバイスの中にＭＡＣアドレスの一致する実デバイスがなかった場合には、以前ｉ番目の仮想デバイスと対応付けていた実デバイスが何からの理由に撤去され、その代替となる実デバイスがネットワークシステムに接続されていることがわかる。この場合、ステップＳ３０２で対応付けられた実デバイスが１つだけであればその実デバイスを、複数あればそのうちいずれかの実デバイスを、ｉ番目の仮想デバイスに新たに対応付ければ（ＭＤの値をその実デバイスのＭＡＣアドレスに更新すれば）よいと考えられる。このような対応付けを自動で行ったり、また自動対応付け処理の中でユーザに設定変更の許可を求めたりすることも考えられるが、ここでは、デバイスが入れ替えられた旨をユーザに警告する（Ｓ３０７）に留め、実際の対応付けは、手動対応付けにより行うようにしている。
【０１６８】
また、ステップＳ３０２で対応付けられた実デバイスの中にＭＡＣアドレスが一致する実デバイスはあったがそのデバイスについてユニークＩＤが一致しない場合、以前ｉ番目の仮想デバイスと対応付けていた実デバイスはシステムＩＤ及びデバイスＩＤの設定内容を維持したまま残っているものの、他の制御装置により、仮想デバイスとの対応付けが解除されていることがわかる。他の制御装置が図２３により後述する同期化処理においてオンラインにする（仮想デバイスと対応付けてある）実デバイスにユニークＩＤを設定する際に、仮想デバイスと対応付けられていなかったためユニークＩＤの設定対象とならなかった実デバイスが、このような、ＭＡＣアドレスが一致するもののユニークＩＤが一致しない状態となるためである。
【０１６９】
この場合には、必ずしも自機における仮想デバイスと実デバイスとの対応付けを他の制御装置に合わせて変更する必要はないが、変更することが好ましい場合もあるので、他の制御装置により仮想デバイスと実デバイスとの対応関係が変更されている旨をユーザに警告する（Ｓ３０７）。ユーザは、この警告に応じて任意に手動対応付けにより対応関係を変更することができる。
【０１７０】
以上の処理により、制御装置のＣＰＵは、仮想デバイステーブルの内容と、各実デバイスから収集したシステムＩＤ、機種ＩＤ、デバイスＩＤ及びユニークＩＤの値とに基づき、各仮想デバイスと実デバイスとの対応付を行うと共に、対応付けに不具合又はその恐れがある場合には、その旨をユーザに警告することができる。
この警告に従った不具合の是正は、次の図２２に示す手動対応付けの処理あるいは各実デバイスにおけるＩＤの設定変更により行うことができる。そして、手動対応付けにより仮想デバイステーブルの内容を変更した場合には、ＣＦ（ＴＧ）に「１」が設定されることになる。
【０１７１】
また、上述の通り図２１の処理において自動で対応付けの不具合を是正するようにしてもよいが、この場合も、仮想デバイステーブルの内容を更新した場合には、ＣＦ（ＴＧ）を「１」に設定する必要がある。また、図示は省略したが、仮想デバイステーブルに対する仮想デバイスの追加や削除あるいはＩＤの設定変更を行った場合も、同様にＣＦ（ＴＧ）を「１」に設定する。
【０１７２】
なお、ステップＳ３０６又はＳ３０７で警告を行った場合にその旨を記憶しておき、警告がある仮想デバイスにつきユーザが手動対応付けや警告無視の指示を行うまでは図２３の同期化処理を行えないようにしたり、同期化処理において、既知のデバイスについてのみオンライン化を行うようにしたり、警告がある仮想デバイスについてはオンライン化を行わないようにしたりすることも考えられる。
【０１７３】
次に、図２３に、同期化処理のフローチャートを示す。この処理は、第１の実施形態で図１５に示した処理と対応するものである。そして、この処理も、図１５の場合と同様、ユーザの操作によるオンライン移行指示を検出した場合に制御装置のＣＰＵが実行するものである。
【０１７４】
この処理において、制御装置のＣＰＵはまず、ＣＦ（ＴＧ）の値により、ユニークＩＤの更新が必要か否か判断する（Ｓ３２１）。そして、更新要を示す「１」であれば、ＣＦ（ＴＧ）を「０」にリセットする（Ｓ３２２）と共に、図１５のステップＳ２３１の場合と同様にユニークなＩＤを生成し、仮想デバイステーブルにシステムＵＩＤ（ＴＧ）の値として設定する。また、存在を把握している他の制御装置に対して、その新たなシステムＵＩＤ（ＴＧ）を含むシステムＩＤ＝ＴＧの仮想デバイステーブルの内容を通知する（Ｓ３２３）。
【０１７５】
ステップＳ３２３の通知を受けた制御装置のＣＰＵは、図２４のフローチャートに示す処理を開始し、まず、通知された仮想デバイステーブルに含まれるシステムＵＩＤを引き継ぐか否かを、適当な選択画面をディスプレイに表示させる等してユーザに選択させる（Ｓ３４１）。
そして、ユーザが引き継ぐことを選択した場合（Ｓ３４２のＹＥＳ）、通知されたシステムＩＤ＝ＴＧの内容で、自身が記憶するシステムＩＤ＝ＴＧの仮想デバイステーブルを置き換え（Ｓ３４３）、処理を終了する。
ユーザが引き継がないことを選択した場合、そのまま処理を終了する。この場合、受信した仮想デバイステーブルの内容を破棄されることになる。
【０１７６】
ここで、図２４に示した処理によるシステムＵＩＤの引き継ぎの意義について説明する。
まず、リモート制御システムに制御装置が複数含まれる場合、そのいずれからも同じようにシステムの構成を変更できるようにすると、制御動作に混乱が生じる可能性がある。そこで、システムの構成の変更は、ユーザアカウントの権限制御などにより、特定のオペレータ（システム管理者）だけが行えるようにすることが好ましい。
なお、ここでまでに説明してきた仮想デバイステーブルの内容変更（仮想デバイスの追加や削除）や、仮想デバイスと実デバイスとの対応付けの変更は、システムの構成の変更の具体例である。
【０１７７】
そして、図２３のステップＳ３２３で制御装置が行う他の制御装置への仮想デバイステーブルの通知は、仮想デバイスと実デバイスとの対応付けが変更され、ＣＦ（ＴＧ）が１となった場合に実行されるものであるので、システム管理者が行う、「それまでとは異なるシステムの制御を開始したので、他の制御装置もそれに同期しなさい。」という指示のようなものと考えることができる。
【０１７８】
また、新たなシステムＵＩＤを含む仮想デバイステーブルの通知は、システム管理者からの通知であるため、通知を受けた他の制御装置のオペレータは、その制御装置が同じシステムＩＤのシステムを制御していれば、基本的には、その通知を受け入れると考えられる。
そして、ステップＳ３４３で、自身が記憶する仮想デバイステーブルを通知された仮想デバイステーブルの内容に置き換えることにより、通知元の制御装置とシステムＵＩＤ及び仮想デバイスを統一できる。従って、仮想デバイステーブルを通知された制御装置も、オンライン移行指示に応じて図２３の処理を実行することにより、以下に説明する通知元の制御装置の場合と同じ仮想デバイスに、同じ実デバイスを対応付けられることになる。
【０１７９】
なお、ステップＳ３２３での仮想デバイステーブルの通知対象は、例えば、同じネットワークシステムに接続された全ての制御装置、とすればよい。あるいは、それらの制御装置のうち、システムＩＤ＝ＴＧの仮想デバイステーブルを記憶している制御装置に限定してもよい。
さらに、自身と重複する範囲の実デバイスを制御対象とする他の制御装置のアドレスなどを予め登録しておき、その登録した制御装置を通知対象としてもよい。システム管理者のアカウントで動作する制御装置が、自機と異なるシステムＵＩＤを記憶した他の制御装置を発見したときに通知するようにすることも考えられる。
【０１８０】
また、通知対象の制御装置の動作として、仮想デバイステーブルを通知された場合でも、通知された仮想デバイステーブルと同じシステムＩＤの仮想デバイステーブルを記憶していない場合や、通知された仮想デバイステーブルに登録されている仮想デバイスと、自身における同じシステムＩＤの仮想デバイステーブルに登録されている仮想デバイスとに全く共通のものがない場合には、通知を受け取らないようにしたり、受け取っても、ユーザに引き継ぎ要否を確認せずに廃棄するようにしてもよい。これらの場合、通知元の制御装置は通知対象の制御装置と関連が薄く、むしろ仮想デバイステーブルの内容を統一しない方が好ましいと考えられるためである。
【０１８１】
図２３の説明に戻ると、制御装置のＣＰＵは、ステップＳ３２３の後、ｉを１から仮想デバイスの数ＶＤＮ（ＴＧ）まで順次増加させながら（Ｓ３２４，Ｓ３２９，Ｓ３３０）、システムＩＤ＝ＴＧのｉ番目の仮想デバイスをオンラインにするための処理（Ｓ３２５〜Ｓ３２８）を行う。
【０１８２】
すなわち、システムＩＤ＝ＴＧのｉ番目の仮想デバイスとＭＡＣアドレス、システムＩＤ及びデバイスＩＤの全てが一致する実デバイスが実デバイステーブルにあれば（Ｓ３２５）、その実デバイスが、ｉ番目の仮想デバイスと対応付けられているデバイスであることがわかる。そこで、その実デバイスにシステムＵＩＤ（ＴＧ）を送信してユニークＩＤとして記憶するよう要求する（Ｓ３２６）と共に、その仮想デバイスのパラメータと、対応付けられた実デバイスのカレントメモリのパラメータとを、ユーザが指定した方向に同期化させる（Ｓ３２７）。その後、ｉ番目の仮想デバイスについてのフラグＯＦを「１」に設定して、その仮想デバイスが対応付けられた実デバイスとオンラインになった旨を記憶する（Ｓ３２８）。
【０１８３】
なお、ステップＳ３２５でシステムＩＤ及びデバイスＩＤの一致を確認するのは、図２１や図２２の処理による対応付けの後で、実デバイスに対する直接操作によってその実デバイスのシステムＩＤやデバイスＩＤが変更されている可能性があるためである。
また、同期化については、システム管理者のアカウントで動作中の制御装置が行う場合には、どちら向きに行ってもよい。しかし、その他の制御装置が行う場合には、システム管理者がリモート制御中のシステムへのオンライン化となるので、実デバイスにおけるパラメータを読み出して仮想デバイスのパラメータとしてコピーする方向で行うことが好ましい。
【０１８４】
また、ステップＳ３２６で送信されるシステムＵＩＤ（ＴＧ）を受信した宛先のデバイスは、要求に応じて、受信したＩＤをユニークＩＤとして設定する（Ｓ３５１）。
そして、ｉがＶＤＮ（ＴＧ）に達し、ステップＳ３３０でＹＥＳとなった時点で、各仮想デバイスがオンラインかオフラインかを区別してディスプレイの画面に表示させてユーザに通知し（Ｓ３３１）、処理を終了する。
【０１８５】
以上の処理により、制御装置がＩＤを収集した実デバイスのうちの、何れかの仮想デバイスと対応付けられた各実デバイスは、対応する仮想デバイスとオンラインとなり、制御装置からのリモート制御を受け付ける。その際、オンラインとなった各実デバイスには、制御装置が記憶するシステムＵＩＤ（ＴＧ）と同じ値のユニークＩＤが設定されることになる。ステップＳ３２６で送信するシステムＵＩＤ（ＴＧ）は、ステップＳ３２３で新たなＩＤを設定していればそのＩＤであるし、そうでない場合には以前から仮想デバイステーブルに登録されていたＩＤであるが、どちらの場合でも、システムＵＩＤ（ＴＧ）と同じ値であることに変わりはない。また、複数の制御装置が存在する場合には、システムＵＩＤ（ＴＧ）の値は、それら制御装置間で共有される。
【０１８６】
従って、複数ある制御装置のうちいずれが図２３の処理を行った場合であっても、最新のオンライン移行指示の際に仮想デバイスに対応付けられているデバイスのみに、各制御装置が記憶するシステムＵＩＤ（ＴＧ）と共通のユニークＩＤを設定されることになる。
複数ある制御装置のうちいずれが図２２の処理などにより仮想デバイステーブルの内容を変更した場合であっても、その後その制御装置が図２３の処理を行う際に、その時点でその制御装置において仮想デバイスに対応付けられているデバイスのみに、各制御装置が記憶するシステムＵＩＤ（ＴＧ）と共通のユニークＩＤを設定されることになる。
【０１８７】
従って、各制御装置は、図２１の自動対応付け処理において、各実デバイスに設定されているユニークＩＤと、自身が記憶するシステムＵＩＤ（ＴＧ）とを比較することにより、実デバイスの配置やデバイスＩＤの設定自体には何の変更もない場合であっても、他の制御装置が行った仮想デバイステーブルの内容変更（及びそれに伴う仮想デバイスと実デバイスとの対応関係の変更）を検出し、ユーザに注意を喚起することができる。このような検出は、ＭＡＣアドレスの比較のみでは行うことができない。
【０１８８】
なお、この実施形態においては、仮想デバイスと実デバイスの対応付けに変更があった場合（仮想デバイステーブルの内容に変更があった場合）にのみユニークＩＤの値を更新するようにしている。そして、仮想デバイステーブルの内容にも、仮想デバイスに対応付けられている実デバイス（ＭＡＣアドレス）にも変更のない場合には、その実デバイスがネットワーク上から消滅（主に電源ＯＦＦによると考えられる）したり、ネットワーク上に新たに登場（主に電源ＯＮによると考えられる）したりしても、新たなシステムＵＩＤを生成することなく、従来のＵＩＤを続けて用いるようにしている。従って、ユニークＩＤの更新回数を抑えることができる。
【０１８９】
また、図２１の処理によれば、上記の主に電源ＯＮ／ＯＦＦに起因すると考えられる実デバイスの消滅や登場にいちいち警告を発することなく、異なるデバイスが導入された時など、ユーザが特段の注意を払う必要がある場合についてのみ、的確に警告を行うことができる。
【０１９０】
また、この実施形態において、複数ある制御装置のうち一部の制御装置のみが仮想デバイステーブルの内容変更及び手動対応付けを行うことができるようにしてもよい。このようにした場合、仮想デバイステーブルの内容変更及び手動対応付けの機能を有する装置をシステム管理者が操作し、その他の装置を一般ユーザが操作するようにするとよい。そして、該その他の装置においては、フラグＣＦ（ＴＧ）が「１」になることはないので、該その他の装置が新たなシステムＵＩＤを生成することはない。
また、この実施形態において、制御装置が、仮想デバイステーブルの内容変更及び手動対応付けの機能を有する装置１台だけであっても、ユニークＩＤを用いた仮想デバイスと実デバイスの対応付けによる効果は得られる。
【０１９１】
３．３ 対応付けの具体例
次に、制御装置が以上説明してきた処理により行う制御対象デバイスの認識について、図２５及び図２６に示す具体例を用いて説明する。これらの図の書式は、特に断らない限り、図１９と同じである。
【０１９２】
まず、図２５に示す例では、（ａ）の「システムを構成するデバイス」の欄に示す５台の実デバイスがネットワークシステムを構成し、これらの実デバイスを制御する制御装置としてＡとＢの２台の制御装置（実デバイスのいずれかが制御装置として機能してもよい）がネットワークシステムに接続され、そのうち制御装置Ａがシステム管理者のアカウントで動作している場合を考える。
【０１９３】
（ａ）に示す状態では、各実デバイスはデバイスＩＤの設定を行った直後の状態であり、ユニークＩＤはクリアされている。そしてこの状態では、図２１に示した自動対応付け処理において、ユニークＩＤは制御装置のシステムＵＩＤと一致しないため、実デバイスは既知デバイスとはならない。なおここでは、図２１の処理で既知デバイスとならない実デバイスを「未知デバイス」と呼ぶことにする。
【０１９４】
図２５（ａ）に破線の枠で示す仮想デバイスが登録された仮想デバイステーブルを有する制御装置Ａにおいて自動対応付け処理を行うと、図２１のステップＳ３０２の処理において、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられる。しかし、上記のように、これらの実デバイスは全て未知デバイスであるので、ステップＳ３０７で警告がなされる。そして、ユーザは、その後図２２に示した手動対応付け処理により、図２１のステップＳ３０２で行われた対応付けを仮想デバイステーブルに（ＭＤの値として）登録することができる。このとき、フラグＣＦ（１）に「１」がセットされる。なお、ＣＦ（１）は、ＴＧ＝１の場合のＣＦ（ＴＧ）である。
【０１９５】
その後、ユーザが制御装置Ａにおいてオンライン移行指示を行うと、制御装置Ａは図２３の同期化処理を実行し、実デバイスと仮想デバイスとの間でパラメータの同期化を行う。このとき、ＣＦ（１）が「１」であるので、制御装置Ａは新たなシステムＵＩＤ（値は「u1」とする）を生成して仮想デバイステーブルに設定し、その仮想デバイステーブルを他の制御装置（ここでは制御装置Ｂ）に通知する。またその新たなシステムＵＩＤを、仮想デバイスと対応付けた図で上から３つの実デバイスにユニークＩＤとして記憶させる。
【０１９６】
このシステムＵＩＤやユニークＩＤは、デバイスを入れ替えたり仮想デバイステーブルの内容を変更したりしなければ、何度電源オンオフやシステムの再起動を行っても、同様に維持される。
【０１９７】
一方、制御装置Ｂは、（ａ）で制御装置Ａから仮想デバイステーブルを通知された際にユーザがシステムＵＩＤを引き継ぐ選択をすると、（ｂ）に示すように、システムＵＩＤの値を含め、仮想デバイステーブルの内容が（ａ）の動作終了後の制御装置Ａと同じものになる。
この状態で自動対応付け処理を行うと、図２１のステップＳ３０２の処理おいて、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられるが、これらすべてのデバイスは既知デバイスであるので、警告は発生しない。また、手動対応付けを行う必要もないので、フラグＣＦ（１）が「０」のままオンライン移行指示を行うことができる。
【０１９８】
そして、この状態で同期化処理を行うと、新たなシステムＵＩＤの生成は行わずに、パラメータの同期化を行う。ステップＳ３２６ではシステムＵＩＤの値を実デバイスに記憶させるが、ここで記憶させる値は、実デバイスが既に記憶している値を同じ値のはずであり、確認的な処理となる。
そして、同期化処理により、実デバイスと制御装置Ｂの仮想デバイスとの間でも、パラメータの同期化が行われる。
なお、制御装置Ａの仮想デバイスが実デバイスとオンラインのままでも、同時に制御装置Ｂの仮想デバイスを同じ実デバイスとオンラインにすることは可能である。
【０１９９】
次に、（ｂ）に示した状態で、上から３番目の実デバイスを、故障等の理由により（ｃ）に示す上から６番目の実デバイスに入れ替えた場合を考える。
（ｃ）の状態で制御装置Ａにおいて自動対応付け処理を行うと、図２１のステップＳ３０２の処理において、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられる。これらの実デバイスのうち上２つは既知デバイスであるが、交換で新しく加えた「1,uy/A/c」の実デバイスは、ユニークＩＤが仮想デバイステーブルと一致せず、未知デバイスであるので、ステップＳ３０７で警告がなされる。そして、ユーザは、その後図２２に示した手動対応付け処理により、「1,uy/A/c」の実デバイスを「1/A/c」の仮想デバイスに対応付けることができる。
【０２００】
その後、ユーザが制御装置Ａにおいてオンライン移行指示を行うと、制御装置Ａは図２３の同期化処理を実行する。このとき、手動対応付けによりＣＦ（１）が「１」になっているため、制御装置Ａは再度新たなシステムＵＩＤ（値は「u2」とする）を生成して仮想デバイステーブルに設定し、その仮想デバイステーブルを制御装置Ｂに通知する。またその新たなシステムＵＩＤを、仮想デバイスと対応付けた実デバイスにユニークＩＤとして記憶させる。
【０２０１】
一方、制御装置Ｂは、（ｃ）で制御装置Ａから仮想デバイステーブルを通知された際にもユーザがシステムＵＩＤを引き継ぐ選択をすると、（ｄ）に示すように、新たなシステムＵＩＤの値を含め、仮想デバイステーブルの内容が（ｃ）の動作終了後の制御装置Ａと同じものになる。
この状態で自動対応付け処理を行うと、図２１のステップＳ３０２の処理おいて、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられるが、これらすべてのデバイスは既知デバイスであるので、警告は発生しない。
【０２０２】
そして、この状態で同期化処理を行うと、新たなシステムＵＩＤの生成は行わずに、パラメータの同期化を行う。
すなわち、制御装置Ｂが関与していない、制御装置Ａにおける仮想デバイスと実デバイスの対応付けの変更を、制御装置Ｂにおいても把握し、ユーザに警告確認や手動対応付けの手間をかけさせずに、交換後の実デバイスをオンライン化することができる。
なお、制御装置ＢがシステムＵＩＤを引き継ぐのは、制御装置Ｂのユーザが、制御装置Ｂを使用して、制御装置Ａが制御している又は制御していたのと同じシステムを制御しようとする場合である。
【０２０３】
次に、図２６に示す例では、制御装置Ｂが制御装置ＡからシステムＵＩＤを引き継がない場合を考える。
図２６（ａ）に示すのは、図２５（ａ）と同じ状態である。ここで、制御装置Ｂにおいて、制御装置Ａから仮想デバイステーブルを通知された際にユーザがシステムＵＩＤを引き継がない選択をすると、制御装置Ｂに記憶されている仮想デバイステーブルがそのまま残り、（ｂ）に示すように、制御装置Ｂの仮想デバイステーブルに制御装置Ａとは異なる仮想デバイスが登録された状態になり得る。もちろん、システムＵＩＤの値も制御装置Ａが記憶するものとは異なる。
【０２０４】
このとき、制御装置Ｂの仮想デバイステーブルには、「1/A/c」のように制御装置Ａ側と重複する仮想デバイスを登録しておくこともできる。
この状態で自動対応付け処理を行うと、図２１のステップＳ３０２の処理おいて、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられる。ここで、「1/A/c」の仮想デバイスには、制御装置ＡがユニークＩＤを設定させた「1,u1/A/c」が対応付けられることになるので、少なくともこのデバイスについては、仮想デバイスとユニークＩＤが一致しない未知デバイスとなる。他の実デバイスについては、図示のようにユニークＩＤの設定がなければ未知デバイスとなるし、過去に対応付けが行われてユニークＩＤが設定されていれば既知デバイスとなる。
【０２０５】
そして、ユーザは、その後図２２に示した手動対応付け処理により、図２１のステップＳ３０２で行われた対応付けを仮想デバイステーブルに（ＭＤの値として）登録することができる。このとき、フラグＣＦ（１）に「１」がセットされる。
その後、ユーザが制御装置Ｂにおいてオンライン移行指示を行うと、制御装置Ｂは図２３の同期化処理を実行し、実デバイスと仮想デバイスとの間でパラメータの同期化を行う。このとき、ＣＦ（１）が「１」であるので、制御装置Ｂは新たなシステムＵＩＤ（値は「ux2」とする）を生成し、仮想デバイスと対応付けた図で下から３つの実デバイスにユニークＩＤとして記憶させる。
また、制御装置Ｂは新たなシステムＵＩＤを設定した仮想デバイステーブルを制御装置Ａに通知するが、ここでは制御装置Ａも制御装置ＢのシステムＵＩＤを引き継がないものとする。
【０２０６】
なお、制御装置Ｂが制御装置ＡのシステムＵＩＤを引き継がない場合、通常は、制御装置Ｂは制御装置Ａとな異なる組み合わせのデバイスを制御対象とすることになる。ここで、制御装置ＢがシステムＵＩＤを引き継がないのは、制御装置Ｂのユーザが、制御装置Ｂを使用して、制御装置Ａが制御している又は制御していたのとは異なるシステムを制御しようとしている場合である。
【０２０７】
このような場合に、１つの実デバイスが制御装置Ｂと制御装置Ａの双方（の仮想デバイス）と同時にオンラインになると、制御に混乱が生じる恐れがあり、好ましくない。
そこで、例えば実デバイスにおいてユニークＩＤが別の値に書き換えられた時点でそれまでオンラインだった制御装置とのオンライン状態を解消するようにするとよい。このようにすれば、現在オンライン中の制御装置と異なる内容の仮想デバイステーブルに基づき別の制御装置からオンライン状態への移行（パラメータの同期化）を要求されたことを適切に把握し、後着優先で１つの制御装置とのみオンラインの状態とすることができる。
【０２０８】
このようにした場合、制御装置Ｂによる同期化処理の後は、制御装置Ａは上から３番目の実デバイスとはオフラインとなり、制御装置Ａとオンラインになっているのは、（ｃ）の「システムを構成するデバイス」の欄に太線で示すように、上２つのデバイスのみである。
また、この状態で制御装置Ａが自動対応付け処理を行うと、「1/A/c」の仮想デバイスには、制御装置ＢがユニークＩＤを設定させた「1,ux2/A/c」が対応付けられることになり、このデバイスは未知デバイスとなる。従ってこのデバイスについてステップＳ３０７での警告がなされる。従って、一旦オンラインにした実デバイスが他の制御装置によってデバイス構成の異なるシステムに組み入れられて使用された場合にも、警告を行うことができると言える。
【０２０９】
なお、制御装置Ａにおいてユーザが手動対応付けで図に示すとおりの対応付けを行った後、オンライン移行指示を行うと、制御装置Ａは、同期化処理により、上から３番目の実デバイスをオンラインにすることができる。またこのとき、制御装置Ａは新たなシステムＵＩＤ（値は「u2」とする）を生成し、仮想デバイスと対応付けた図で上から３つの実デバイスにユニークＩＤとして記憶させる。そして、上から３番目の実デバイスにも新たなユニークＩＤが記憶されることになるため、この実デバイスは制御装置Ｂとのオンライン状態を解消する。
【０２１０】
また、（ｄ）に示すように、制御装置Ａにおいて仮想デバイステーブルの内容が変更されると、変更した箇所については、自動対応付け処理において仮想デバイスに未知デバイスが対応付けられ、警告が行われることになる。
しかし、ユーザが手動対応付けで適当な対応付けを行った後、オンライン移行指示を行うと、制御装置Ａは、同期化処理により、各仮想デバイスと、その仮想デバイスと対応付けた実デバイスとをオンラインにすることができる。またこのとき、制御装置Ａは新たなシステムＵＩＤ（値は「u3」とする）を生成し、仮想デバイスと対応付けた各実デバイスにユニークＩＤとして記憶させる。
【０２１１】
４．変形例
以上で実施形態の説明を終了するが、装置の構成、データの構成、ユーザによる操作の手順、具体的な処理内容等が上述の実施形態で説明したものに限られないことはもちろんである。
例えば、上述の実施形態では、仮想デバイス及び各デバイスについてシステムＩＤを設定しておき、制御装置が現在の制御対象とするシステムを、システムＩＤにより設定する例について説明した。
【０２１２】
しかし、現在の制御対象とするシステムを、設定し得るデバイスＩＤの選択肢の中から１又は複数のデバイスＩＤを指定して設定できるようにしてもよい。ただしこの場合、全デバイス及び仮想デバイスをデバイスＩＤのみ（あるいはデバイスＩＤと機種ＩＤの組み合わせ）によって識別できるようにする必要がある。従って、仮想デバイスとシステムを構成するデバイスとの対応付けに際しては、システムＩＤは無視して（又は設定自体せず）、現在の制御対象として設定されているデバイスＩＤを有する仮想デバイスについてのみ、対応付けを行い、他の仮想デバイスについては何らのデバイスも対応付けないことになる。
【０２１３】
また、上述の実施形態では、現在の制御対象として設定されているシステムＩＤを有しない仮想デバイスについては、デバイスとの対応付けを行わない例について説明した。しかし、全仮想デバイスについて対応付けを行っておく一方、現在の制御対象として設定されていない仮想デバイスについては、オンラインにしないような制御を行ってもよい。
【０２１４】
また、優先グループの選択手法につき、図１３に示したような、仮想デバイスとの対応付けに基づくもの以外にも、任意の手法を採用可能である。例えば、マスタノードとなるデバイスは重要なデバイスであるのであまり入れ替えないが他のデバイスについては頻繁に入れ替えがある、というような場合には、マスタノードが属するグループを無条件に優先グループとする手法も考えられる。
【０２１５】
また、図２３のステップＳ３２３において、必ずしも仮想デバイステーブルの内容を全て通知しなくても、通知対象の制御装置との間で仮想デバイステーブルの内容を共通化できれば問題ない。例えば、通知対象の制御装置においてシステムＵＩＤを引き継ぐ選択がなされた時点で仮想デバイステーブルを渡してもよいし、仮想デバイステーブルにおける仮想デバイスの内容が制御装置間で一致していることが何らかの手段で保証されるなら、システムＵＩＤを通知するのみでもよい。
【０２１６】
また、各仮想デバイスに対応付けるデバイスを特定するための情報として、ＭＡＣアドレス以外の情報を用いてもよい。ユーザが行うシステムＩＤやデバイスＩＤの設定内容によらず、デバイス間で重複が起こらず、常にデータの送信先を一意に特定できるような情報であれば、その情報を用いて、仮想デバイスに対応付けるデバイスを特定することができる。デバイスのメーカーがこのようなＩＤを予めデバイスに設定しておいてもよい。
【０２１７】
また、この発明は、上述したようなリング状のフレーム伝送経路を用いるシステムだけでなく、ＣｏｂｒａＮｅｔ（商標）やＥｔｈｅｒＳｏｕｎｄ（商標）をはじめ、制御装置から他の装置に対して制御用データを送信可能な任意の形態のネットワークシステムに適用可能である。
【０２１８】
さらに、ネットワークを介して音響信号を送信可能であることも必須ではない。従って、イーサネット（商標）、無線ＬＡＮ、ＵＳＢ、ＩＥＥＥ１３９４等の任意のプロトコルによって通信を行うネットワークシステムにも適用可能である。この場合、音響信号は、制御信号の伝送に用いるネットワークとは別のネットワークや、ＭＡＤＩ（Multichannel Audio Digital Interface）等のケーブルを使用して別途伝送するようにしてもよい。
【０２１９】
さらにまた、制御装置がコンソールやＰＣであることも、制御対象のデバイスが音響信号処理装置であることも、必須ではない。
以上説明してきた変形及び実施形態の説明において述べた変形は、矛盾しない範囲で任意に組み合わせて適用可能である。また逆に、ネットワークシステムが実施形態の説明において述べた特徴を全て有している必要もない。
【産業上の利用可能性】
【０２２０】
以上の説明から明らかなように、この発明のリモート制御システムによれば、複数の制御装置により同じデバイスを制御しようとする場合でも、同じシステムを制御対象とする複数の制御装置間で共通となるシステムＵＩＤ（第２ＩＤ）に基づいて、直近の動作時に一群の制御対象として動作していたデバイスと、そうでないデバイスとを制御装置が容易に識別して、制御対象を選択できるようにすることができる。
従って、この発明を適用することにより、リモート制御システムの利便性を向上させることができる。
【符号の説明】
【０２２１】
１，Ｓ…オーディオネットワークシステム、２Ｂａ、２Ｂｃ，２Ｂｅ，２Ｂｆ，２Ｂｘ，３Ｂａ…入出力装置、２Ｃｂ…コンソール、２Ｅｄ…ミキサエンジン、１０…音響信号処理装置、１００…ＴＬフレーム
【技術分野】
【０００１】
この発明は、複数の制御装置と、その制御装置により制御される複数のデバイスとを備えるリモート制御システムに関する。
【背景技術】
【０００２】
従来から、複数のデバイス間でデータの伝送を行うための種々のネットワークシステムが知られている。
例えば、複数のノード間で音響信号の伝送を行うためのオーディオネットワークシステムが知られており、コンサート、演劇、音楽製作、構内放送等において用いられている。このようなオーディオネットワークシステムの例としては、以下の非特許文献１，２に記載のような、ＣｏｂｒａＮｅｔ（商標），ＥｔｈｅｒＳｏｕｎｄ（商標）が知られている。
【０００３】
また、これら以外に、特許文献１に記載のネットワークシステムも提案されている。
この特許文献１に記載のネットワークシステムにおいては、システムを構成する各デバイスにより形成されるリング状の伝送路にフレームを定期的に循環させ、各デバイスがそのフレームに対して必要な情報を読み書きすることにより、システムを構成する任意のデバイスから任意のデバイスへ、音響信号だけでなくイーサネット（登録商標）フレーム等の制御信号も、安定して伝送することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−９４５８９号公報
【非特許文献】
【０００５】
【非特許文献１】「CobraNet(TM)」、[online]、バルコム株式会社、［平成１８年３月２１日検索］、インターネット＜ＵＲＬ：http://www.balcom.co.jp/cobranet.htm＞
【非特許文献２】Carl Conrad、「EtherSound(TM) in a studio environment」、[online]、Digigram S.A.、［平成１８年３月２１日検索］、インターネット＜ＵＲＬ：http://www.ethersound.com/news/getnews.php?enews_key=101＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、上述したようなネットワークシステムにおいて、ある制御装置によりシステム内のデバイスを制御するリモート制御システムを構成しようとする場合、その制御範囲を特定するためにシステムＩＤを用いたり、具体的な制御対象を特定するためにデバイスＩＤを用いたりすることが考えられる。そしてこの場合、各デバイスにシステムＩＤとデバイスＩＤを予め設定しておき、制御装置がこれらのＩＤに基づいて制御対象のデバイスを特定することが考えられる。
【０００７】
このような用途のＩＤは、ユーザによる設定を楽にしたり、設定画面を簡素にしたりするために、１〜数桁の数字や１〜数文字のアルファベットなど、簡単な内容にすることが好ましい。
しかし、このようなＩＤを採用した場合、ユーザが把握できる範囲ではデバイス間で一意性を確保できるとしても、偶然やミスによりデバイス間でＩＤが重複してしまい、デバイスを識別できなくなる恐れがあった。
【０００８】
例えば、システムに新たなデバイスを追加しようとした場合に、その新たなデバイスに誤って既存のデバイスと同じＩＤが設定されていると、それらのどちらのデバイスが新たに追加されたデバイスであるのか、制御装置から容易に判別できない。また、システム内のデバイスが故障して、これを別のデバイスに置き換える場合にも、その別のデバイスに誤って既存のデバイスと同じＩＤが設定されていると、それらのどちらのデバイスが置き換え後のデバイスであるのか、制御装置から容易に判別できない。
【０００９】
従って、制御装置においてＩＤの設定が誤っていることが把握できたとしても、誤設定のない範囲で制御を開始することすら、難しい場合もあった。
このような問題は、複雑なＩＤを用いる場合であっても、誤設定による重複が無視できない場合には、同様に発生するものである。
【００１０】
この発明は、このような問題を解決し、制御装置が複数のデバイスの制御を開始する際に、その複数のデバイス間でユーザにより設定されたＩＤが重複する場合でも、直近の動作時に一群の制御対象として動作していたデバイスと、そうでないデバイスとを制御装置が容易に識別して、制御対象を選択できるようにすることを目的とする。
特に、複数の制御装置により同じデバイスを制御しようとする場合でも、直近の動作時に一群の制御対象として動作していたデバイスと、そうでないデバイスとを制御装置が容易に識別して、制御対象を選択できるようにすることを目的とする。
【課題を解決するための手段】
【００１１】
上記の目的を達成するため、この発明のリモート制御システムは、複数の制御装置と、その複数の制御装置により制御される複数のデバイスとを備えるリモート制御システムにおいて、まず、上記各デバイスに、そのデバイスの第１ＩＤ及び第２ＩＤを記憶する記憶手段と、ユーザの操作に応じて上記第１ＩＤを上記記憶手段に記憶させる第１設定手段と、上記制御装置からＩＤを受信して上記第２ＩＤとして上記記憶手段に記憶させる第２設定手段とを設けたものである。
【００１２】
さらに、上記各制御装置に、第２ＩＤを記憶する第２ＩＤ記憶手段と、制御対象とする複数のデバイスを上記第１ＩＤによりデバイス毎に特定するデバイスデータを記憶する制御対象記憶手段と、上記各デバイスからそれぞれそのデバイスの第１ＩＤ及び第２ＩＤを取得するＩＤ取得手段と、上記ＩＤ取得手段が取得した第１ＩＤ及び第２ＩＤに基づき、上記制御対象記憶手段に記憶された各デバイスデータに対し、ＩＤの取得元である各デバイスのうち、そのデバイスデータと上記第１ＩＤの値が共通する最大１つのデバイスを対応付ける手段であって、ａ）上記ＩＤの取得元である各デバイスの中に、上記デバイスデータと上記第１ＩＤの値が共通であり、かつ上記第２ＩＤ記憶手段が記憶する第２ＩＤと同じ値の第２ＩＤを有するデバイスがあった場合に、そのデバイスをそのデバイスデータに対応付け、ｂ）上記ＩＤの取得元である各デバイスの中に、上記デバイスデータと上記第１ＩＤの値が共通であり、かつ上記第２ＩＤ記憶手段が記憶する第２ＩＤと異なる値の第２ＩＤを有するデバイスがあった場合に、ユーザに対して警告を行う対応付け手段と、上記対応付け手段による対応付けができたデバイスを、制御対象のデバイスとして設定する制御対象設定手段と、上記制御対象設定手段が設定した制御対象のデバイスを、上記第１ＩＤにより特定して制御するリモート制御手段とを設けたものである。
【００１３】
さらに、上記複数の制御装置のうち特定の制御装置に、上記デバイスデータのいずれかについて、上記ＩＤの取得元である各デバイスの中に、そのデバイスデータと上記第１ＩＤの値が共通であるデバイスが１以上あった場合に、ユーザの操作に応じて、その各デバイスの上記第２ＩＤの値によらず、上記１以上のデバイスのうち１つをそのデバイスデータに対応付ける手動対応付け手段と、上記制御対象設定手段による制御対象の設定に際して、制御対象とするデバイスの中に、上記手動対応付け手段による対応付けがなされたデバイスが含まれている場合、１つのユニークなＩＤを生成し、上記第２ＩＤ記憶手段に記憶している第２ＩＤをその生成したＩＤに書き換えると共に、上記制御対象設定手段が設定する制御対象の各デバイスに送信して上記第２ＩＤとして記憶させる第２ＩＤ付与手段とを設けたものである。
【００１４】
また、この発明の別のリモート制御システムは、複数の制御装置と、その複数の制御装置により制御される複数のデバイスとを備えるリモート制御システムにおいて、まず、上記各デバイスに、そのデバイスの第１ＩＤ及び第２ＩＤを記憶する記憶手段と、ユーザの操作に応じて上記第１ＩＤを上記記憶手段に記憶させる第１設定手段と、上記制御装置からＩＤを受信して上記第２ＩＤとして上記記憶手段に記憶させる第２設定手段とを設けたものである。
【００１５】
さらに、上記各制御装置に、第２ＩＤを記憶する第２ＩＤ記憶手段と、制御対象とする複数のデバイスを上記第１ＩＤによりデバイス毎に特定するデバイスデータを記憶する制御対象記憶手段と、上記各デバイスからそれぞれそのデバイスの第１ＩＤ及び第２ＩＤを取得するＩＤ取得手段と、上記ＩＤ取得手段が取得した第１ＩＤ及び第２ＩＤに基づき、上記制御対象記憶手段に記憶された各デバイスデータに対し、ＩＤの取得元である各デバイスのうち、そのデバイスデータと上記第１ＩＤの値が共通する最大１つのデバイスを対応付ける手段であって、ａ）上記ＩＤの取得元である各デバイスの中に、上記デバイスデータと上記第１ＩＤの値が共通であり、かつ上記第２ＩＤ記憶手段が記憶する第２ＩＤと同じ値の第２ＩＤを有するデバイスがあった場合に、そのデバイスをそのデバイスデータに対応付け、ｂ）上記ＩＤの取得元である各デバイスの中に、上記デバイスデータと上記第１ＩＤの値が共通であり、かつ上記第２ＩＤ記憶手段が記憶する第２ＩＤと異なる値の第２ＩＤを有するデバイスがあった場合に、ユーザに対して警告を行う対応付け手段と、上記対応付け手段による対応付けができたデバイスを、制御対象のデバイスとして設定する制御対象設定手段と、上記制御対象設定手段が設定した制御対象のデバイスを、上記第１ＩＤにより特定して制御するリモート制御手段とを設けたものである。
【００１６】
さらに、上記複数の制御装置のうち特定の制御装置に、ユーザの操作に応じて上記制御対象記憶手段に対してデバイスデータの追加及び削除を行う制御対象編集手段と、上記デバイスデータのいずれかについて、上記ＩＤの取得元である各デバイスの中に、そのデバイスデータと上記第１ＩＤの値が共通であるデバイスが１以上あった場合に、ユーザの操作に応じて、その各デバイスの上記第２ＩＤの値によらず、上記１以上のデバイスのうち１つをそのデバイスデータに対応付ける手動対応付け手段と、上記制御対象設定手段による制御対象の設定に際して、上記制御対象編集手段によりデバイスデータの追加又は削除がなされた場合及び、制御対象とするデバイスの中に、上記手動対応付け手段による対応付けがなされたデバイスが含まれている場合に、１つのユニークなＩＤを生成し、上記第２ＩＤ記憶手段に記憶している第２ＩＤをその生成したＩＤに書き換えると共に、上記制御対象設定手段が設定する制御対象の各デバイスに送信して上記第２ＩＤとして記憶させる第２ＩＤ付与手段とを設けたものである。
【００１７】
上記の各リモート制御システムにおいて、上記特定の制御装置の第２ＩＤ付与手段が、上記ユニークなＩＤを生成した場合、そのＩＤを他の制御装置に通知し、その他の制御装置が、上記第２ＩＤ記憶手段に記憶している第２ＩＤをその通知されたＩＤに書き換えると共に、上記制御対象記憶手段に記憶しているデバイスデータを、上記特定の制御装置の制御対象記憶手段が記憶しているデバイスデータに書き換えるようにするとよい。
【発明の効果】
【００１８】
この発明によるリモート制御システムによれば、複数の制御装置により同じデバイスを制御しようとする場合でも、同じシステムを制御対象とする複数の制御装置間で共通となるシステムＵＩＤ（第２ＩＤ）に基づいて、直近の動作時に一群の制御対象として動作していたデバイスと、そうでないデバイスとを制御装置が容易に識別して、制御対象を選択できるようにすることができる。
【図面の簡単な説明】
【００１９】
【図１】この発明のリモート制御システムの実施形態において制御装置により制御されるデバイスが形成するオーディオネットワークシステムの概略構成を示す図である。
【図２】図１に示したオーディオネットワークシステムの伝送路で伝送されるＴＬフレームの構成例を示す図である。
【図３】ＴＬフレームの伝送タイミングを示す図である。
【図４】オーディオネットワークシステム上での音響信号の伝送時における、ＴＬフレームの伝送状況について説明するための図である。
【図５】図１に示したオーディオネットワークシステムを構成する各ノードとなる音響信号処理装置のハードウェア構成を示す図である。
【図６】図１に示した方式のオーディオネットワークシステムのより具体的な構成例を示す図である。
【図７】各デバイスに記憶させるＩＤについて説明するための図である。
【図８】仮想デバイステーブルの例を示す図である。
【図９】制御装置に記憶させる、オーディオネットワークシステムを構成するデバイスを制御するためのパラメータの例を示す図である。
【図１０】制御装置のＣＰＵが実行する仮想デバイス追加処理のフローチャートである。
【００２０】
【図１１】同じく仮想デバイス削除処理のフローチャートである。
【図１２】制御装置が収集した各デバイスのＩＤの例を示す図である。
【図１３】制御装置のＣＰＵが実行する自動対応付け処理のフローチャートである。
【図１４】同じくデバイス検索処理のフローチャートである。
【図１５】同じく同期化処理のフローチャートである。
【図１６】同じく現在の制御対象を示すシステムＩＤを設定する処理のフローチャートである。
【図１７】同じく手動対応付け処理のフローチャートである。
【図１８】同じく新規デバイスの追加を検出した場合の処理のフローチャートである。
【図１９】制御装置による制御対象デバイス認識の具体例を示す図である。
【図２０】第２の実施形態における仮想デバイステーブルの例を示す図である。
【００２１】
【図２１】第２の実施形態における自動対応付け処理のフローチャートである。
【図２２】第２の実施形態における手動対応付け処理のフローチャートである。
【図２３】第２の実施形態における同期化処理のフローチャートである。
【図２４】制御装置が他の制御装置からシステムＵＩＤ更新に伴う仮想デバイステーブルの通知を受けた場合に実行する処理のフローチャートである。
【図２５】第２の実施形態における制御装置による制御対象デバイス認識の具体例を示す図である。
【図２６】その別の例を示す図である。
【発明を実施するための形態】
【００２２】
以下、この発明を実施するための形態を図面に基づいて具体的に説明する。
１． この発明のリモート制御システムの実施形態の概要（第１の実施形態）
この発明のリモート制御システムは、１又は複数の制御装置と、その制御装置により制御される複数のデバイスとを備えたシステムとして構成することができる。そして、その制御装置はそれぞれ、どのデバイスを制御対象とするかという設定に従って、ネットワークシステムを構成する複数のデバイスから適当なデバイスを選択してリモート制御の対象とし、その制御装置と、選択した制御対象デバイスとにより、リモート制御システムを構成することができる。
【００２３】
また、制御装置により制御されるデバイスとしては、例えば、相互に音響信号を送受信可能なオーディオネットワークシステムを構成するデバイスが考えられる。
ここではまず、背景技術の項で述べた特開２００９−９４５８９号公報に記載のようなオーディオネットワークシステムを構成するデバイスを制御装置により制御され得るデバイスとする場合のリモート制御システムの構成例について説明する。
【００２４】
１．１ 制御装置により制御されるデバイスが形成するネットワークシステムの例
まず、図１に、この発明のリモート制御システムの実施形態において制御装置により制御されるデバイスが形成するオーディオネットワークシステムの概略構成を示す。
図１（ａ），（ｂ）に示すように、このオーディオネットワークシステム１は、それぞれ単方向の通信を行う受信手段である受信インタフェース（Ｉ／Ｆ）と送信手段である送信Ｉ／Ｆの組を２組備えたデバイスであるノードＡ〜Ｃを、通信ケーブルＣＢで順次接続することにより構成したものである。ここでは３つのノードにより構成した例を示しているが、ノードの数は２以上の任意でよい。
【００２５】
ノードＡにおいては、受信Ｉ／Ｆ＿ＡＲ１と送信Ｉ／Ｆ＿ＡＴ１が一組のＩ／Ｆで、受信Ｉ／Ｆ＿ＡＲ２と送信Ｉ／Ｆ＿ＡＴ２がもう一組のＩ／Ｆである。ノードＢ及びＣについても、符号の先頭の文字「Ａ」を「Ｂ」あるいは「Ｃ」に置き換えたＩ／Ｆが、同様な関係に当たる。
【００２６】
そして、ノード間の接続は、１組の受信Ｉ／Ｆ及び送信Ｉ／Ｆを、別のノードの１組の送信Ｉ／Ｆ及び受信Ｉ／Ｆとそれぞれ通信ケーブルＣＢで接続することにより行っている。例えば、ノードＡとノードＢとの間では、受信Ｉ／Ｆ＿ＡＲ２と送信Ｉ／Ｆ＿ＢＴ１とを接続すると共に、送信Ｉ／Ｆ＿ＡＴ２と受信Ｉ／Ｆ＿ＢＲ１とを接続している。また、ノードＢとノードＣとの間では、ノードＢのもう１組のＩ／Ｆと、ノードＣの１組のＩ／Ｆとを接続している。
なお、図１に示す各ノードは、アナログ入力，アナログ出力，デジタル入力，デジタル出力，ミキシング，エフェクト付与，録音再生，リモート制御，あるいはこれらの組み合わせ等の各種機能を有する音響信号処理装置である。ノード毎に機能が違っていても当然構わない。
【００２７】
ここで、（ａ）に示すように、各ノードを、端部を有する１本のラインのように接続した状態を、「カスケード接続」と呼ぶことにする。そしてこの場合、各ノード間を結ぶケーブルＣＢにより、破線で示すように１つのリング状のデータ伝送経路を形成することができ、各ノードは、この経路でフレームを一定周期で循環させるように伝送し、そのフレームに対して必要な情報を読み書きすることにより、経路上の任意のノードとの間でデータの送受信を行うことができる。
そして、オーディオネットワークシステム１内において、１つのノードがマスタノードとなり、音響信号を伝送するためのフレームを生成し、定期的に伝送経路を循環させたり、ネットワークの管理を行ったりする。このマスタノードが生成するフレームを、その他のフレームと区別して「ＴＬフレーム」と呼ぶことにする。
【００２８】
また、（ａ）に示したカスケード接続に加え、両端のノードで使用していないＩ／Ｆ同士も通信ケーブルＣＢで接続すると、（ｂ）に示すように、リング状のデータ伝送経路を２つ形成することができる。そして、各ノードは、これらの経路でそれぞれフレームを伝送し、その各フレームに対して必要な情報を読み書きすることにより、経路上の任意のノードとの間でデータの送受信を行うことができる。このようなノード間の接続状態を、「ループ接続」と呼ぶことにする。
【００２９】
このループ接続の状態で、一方の伝送路を循環させるＴＬフレームのみで伝送可能な情報量の通信を行っている場合、１カ所で断線が発生したとしても、その断線箇所の両側でＴＬフレームの伝送を折り返すことにより、断線箇所の両側をカスケード接続の両端と見て、速やかに（ａ）に示したようなカスケード接続のシステムに組み換え、０〜２フレーム程度の損失でＴＬフレームの伝送を継続することができる。
【００３０】
また、カスケード接続の状態で両端に新たにノードを追加接続した場合には、接続箇所の両側でＴＬフレーム伝送の折り返しを解除することにより、そのノードを通るデータ伝送経路を形成してそのノードをシステムに取り込むことができる。逆に、カスケード接続の状態でいずれかのノード間の接続が切断された場合には、切断箇所の両側でＴＬフレーム伝送の折り返しを開始することにより、マスタノードから見て切断箇所よりも先のノードを切離し、接続が維持されている箇所についてはＴＬフレームの伝送を継続することができる。
【００３１】
なお、図１ではケーブルを２本示しているが、１組の受信Ｉ／Ｆと送信Ｉ／Ｆとを近接してあるいは一体として設ければ、２本を束ねて１本にしたケーブルにより、１組のＩ／Ｆ同士の接続を行うことも可能である。
また、各ノードには、必要なＩ／Ｆを設ければ、（ｃ）に示すように、外部機器Ｎを接続し、外部機器Ｎから受信したデータをＴＬフレームに書き込んで他のノードに送信したり、ＴＬフレームから読み出したデータを外部機器Ｎに送信したりすることもできる。
【００３２】
ここで説明するリモート制御システムにおいて、制御装置は、オーディオネットワークシステム１を構成するデバイスのいずれかとすることもできるし、外部機器Ｎのようにオーディオネットワークシステム１を構成するデバイスのいずれかに接続された外部機器とすることもできる。
【００３３】
前者の場合、例えばオーディオネットワークシステム１を構成するコンソールを制御装置として用いることができる。
後者の場合、外部機器として、パーソナルコンピュータ（ＰＣ）を用い、このＰＣ上でリモート制御システム制御用のアプリケーションを起動することにより制御装置として機能させることが考えられる。そして、ＰＣがユーザから受け付けた操作に応じたコマンドをノードＢに送信し、ノードＢがこれをＴＬフレームに書き込んで他のノードに送信したり、他のノードがＴＬフレームに書き込んで送信してきた応答やレベルデータ等をノードＢが読み出してＰＣに送信し、ＰＣにおける操作子状態の表示やレベル表示に使用するといった動作を行わせることが考えられる。
制御装置の数は任意であるし、両者が混在していても構わない。
【００３４】
１．２ ＴＬフレームの構成
次に、図２に、上述したオーディオネットワークシステム１の伝送路で伝送されるＴＬフレームの構成例を示す。なお、この図に示した各領域の幅は必ずしもデータ量と対応しない。
図２に示すように、このＴＬフレーム１００は、サイズが１２８２バイトであり、先頭から順に、プリアンブル１０１，管理データ１０２，波形データ（オーディオデータ）領域１０３，制御データ領域１０４，ＦＣＳ（Frame Check Sequence）１０５の各領域からなる。各領域のサイズは、その領域に記載するデータ量に関わらずそれぞれ一定である。また、ここで示すＦＣＳ１０５以外の各領域のサイズは一例であり、適宜変更してよい。
【００３５】
そして、プリアンブル１０１は、計８バイトのデータであり、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２．３で規定されるプリアンブルとＳＦＤ（Start Frame Delimiter）とを記載する。
管理データ１０２は、８バイトのデータであり、オーディオネットワークシステム１内の各ノードがＴＬフレームに含まれるデータの管理に利用するデータとして、システム内のどの伝送路を循環させるフレームかを示すリングＩＤ、フレーム通し番号であるフレームＩＤ、波形データ１０３中の波形データのｃｈ数等を記載する。
【００３６】
また、波形データ領域１０３としては１０２４バイトを確保しており、音響信号のデータである１サンプル３２ビットの波形データを２５６ｃｈ分記載できる。すなわち、本システムでは、１つのＴＬフレーム１００を循環させることにより、２５６ｃｈ分の音響信号を伝送することができる。なお、２５６ｃｈ中の伝送に使われていないｃｈ（空きｃｈ）の領域については、そこに何が記載されているか気にしなくて良い。なお、波形データのビット数に応じて各ｃｈの領域のサイズを変更するようにしてもよい。その場合、１６ビットの波形データは５１２ｃｈ分伝送可能であり、２４ビットであれば３４０ｃｈ分伝送可能になる。
【００３７】
また、波形データ領域１０３においては、予めオーディオネットワークシステム１を構成する各ノードにｃｈを割り当てておき、各ノードは、自身に割り当てられたｃｈの位置に、出力波形データの書き込みを行う。この割り当ては、システム全体の管理動作を行うマスタノードが、各ノードからの要求に基づいて行う。
【００３８】
一方、制御データ領域１０４としては２３８バイトを確保し、ここには、イーサネットフレーム領域１０６、ＩＴＬフレーム領域１０７、および管理データ領域１０８設けている。
このうちイーサネットフレーム領域１０６には、ＩＰ（Internet Protocol）に基づくノード間通信用のパケットであるＩＰパケットをさらにフレーム化したＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２．３形式のフレーム（イーサネットフレーム）を記載する。
【００３９】
また、記載すべきイーサネットフレームが用意したサイズ（ここでは１７８バイト）に収まらない場合には、フレームの送信側で必要な数のブロックに分割し、ＴＬフレーム１つにつき、そのブロック１つを記載する。そして、フレームの受信側で複数のＴＬフレーム１００からデータを取り出して結合し、分割前のフレームを復元することにより、通常のイーサネット（登録商標）での伝送と同様にイーサネットフレームをノード間で伝送することができる。
【００４０】
また、ＩＴＬフレーム領域１０７には、隣接ノード間でのコマンド及びコマンドに対する応答の伝送に使用するフレームであるＩＴＬフレームのデータを記載する。このＩＴＬフレームは、詳細な説明は省略するが、システム内でフレーム伝送路を形成する際の情報伝達や、システム形成後の情報伝達に使用する。
【００４１】
管理データ領域１０８は、システム内の各ノードがＴＬフレーム１００に含まれるデータの管理に利用するデータを記載する領域である。ここに記載するデータとしては、例えば、レベル表示に使用するメータデータ、ＴＬフレーム１００が伝送中に切断されたことを示す切断検出フラグ、ＴＬフレーム１００の伝送にエラーが生じたことを示すエラーフラグ等が挙げられる。
また、ＦＣＳ１０５は、ＩＥＥＥ８０２．３で規定される、フレームのエラーを検出するためのフィールドである。
【００４２】
オーディオネットワークシステム１においては、以上のようなＴＬフレームに各ノード間を巡回させることにより、オーディオ信号のリアルタイム伝送とイーサネットフレームの伝送とを同時に行うことができる。そして、イーサネットフレーム領域１０６を用いたイーサネットフレームの伝送により、オーディオネットワークシステム１を構成する各ノードは、１つのイーサネット（商標）で接続されているのと等価な環境にある。
【００４３】
１．３ ＴＬフレームの伝送方式
次に、図３に、図２に示したＴＬフレーム１００の伝送タイミングを示す。
この図に示すように、オーディオネットワークシステム１においては、ＴＬフレーム１００を、９６ｋＨｚ（キロヘルツ）のサンプリング周期１周期である１０．４μｓｅｃ（マイクロ秒）毎に１つ、ノード間を循環させ、各ノードはＴＬフレームの所望のｃｈへの音響信号の書き込みないし所望のｃｈからの音響信号の読み出しを行うようになっている。従って、各サンプリング周期に、２５６の信号伝送ｃｈについて、それぞれ１サンプル分の波形データを、各ノード間で伝送できる。
１Ｇｂｐｓ（ギガビット・パー・セカンド）のイーサネット（登録商標）方式のデータ転送を採用すれば、ＴＬフレーム１００の時間長は、１ナノ秒×８ビット×１２８２バイト＝１０．２６μｓｅｃであり、１サンプリング周期内に伝送が完了する。
【００４４】
次に、図４に、オーディオネットワークシステム上での音響信号の伝送時における、図２に示したＴＬフレームの伝送状況を示す。
ここでは、ノードＡからノードＤまでの４つのノードをカスケード接続したシステムを考える。そして、このシステム内の各ノードにＴＬフレーム１００を循環させる場合、いずれか１つのノードをマスタノードと定め、そのノードのみが新たなサンプリング周期のＴＬフレーム（通し番号の異なるＴＬフレーム）の生成を行い、サンプリング周期毎に生成されたＴＬフレームを次のノードへ送信する。マスタノード以外のノードはスレーブノードであり、それぞれ前のノードからＴＬフレームを受信し、次のノードへ送信する転送処理を行う。
【００４５】
そして、マスタノードであるノードＢが最初に図で右向きに、ワードクロックのタイミングに合わせて、ノードＣに向かってＴＬフレームを送信すると、そのＴＬフレームは、破線で示すように、ノードＢ→Ｃ→Ｄ→Ｃ→Ｂ→Ａ→Ｂの順で伝送され、ノードＢに戻ってくる。この伝送の際、各ノードは、ＴＬフレームを受信してから送信するまでに、他のノードから受信すべき波形データや制御データをＴＬフレームから読み取り、また他のノードに送信すべき波形データや制御データをＴＬフレームに書き込む。
【００４６】
そして、マスタノードは、ＴＬフレームが伝送路を１周して戻ってくると、そのＴＬフレームの管理データを書き換えて後のサンプル周期のＴＬフレームを生成し、適当なサンプル周期での送信に供する。またこのとき、マスタノードも他のノードと同様にＴＬフレームに対してデータの読み書きを行う。
【００４７】
以上を繰り返すことにより、１サンプリング周期につき１つのＴＬフレームに、（ａ）から（ｅ）に時系列的に示すように、各ノードを循環させることができる。これらの図において、黒塗りの矢印はＴＬフレームの先頭を、黒丸はＴＬフレームの末端を示す。線の矢印は、ＴＬフレームの切れ目を分かり易くするために記載したものである。
【００４８】
なお、ループ接続を行い、部分システム内に伝送路を２本形成する場合には、図１からわかるように、マスタノードであるノードＢが生成して図で右向きに送信したＴＬフレームを、ノードＢ→Ｃ→Ｄ→Ａ→Ｂの順で伝送する伝送路と、ノードＢが生成して図で左向きに送信したＴＬフレームを、ノードＢ→Ａ→Ｄ→Ｃ→Ｂの順で伝送する伝送路とができることになる。そしてこの場合、ＴＬフレームが伝送路を１周する間に全てのノードを１回ずつ通過することになるため、各ノードは、その通過の際にデータの読み書きを行う。
【００４９】
１．４ システムを構成する各装置のハードウェア構成及び基本動作
次に、以上説明してきたようなＴＬフレームの伝送を行うためのハードウェア及びその動作について説明する。
図５に、上述のオーディオネットワークシステム１を構成する各ノードとなる音響信号処理装置のハードウェア構成を示す。
【００５０】
図５に示すように、この音響信号処理装置１０は、ＣＰＵ２０１，フラッシュメモリ２０２，ＲＡＭ２０３，外部機器Ｉ／Ｆ（インタフェース）２０４，表示器２０５，操作子２０６を備え、これらがシステムバス２０７により接続されている。また、外部機器Ｉ／Ｆ２０４とシステムバス２０７とに接続するカードＩ／Ｏ（入出力部）２１０も備えている。
【００５１】
そして、ＣＰＵ２０１は、この音響信号処理装置１０の動作を統括制御する制御手段であり、フラッシュメモリ２０２に記憶された所要の制御プログラムを実行することにより、表示器２０５における表示を制御したり、操作子２０６の操作を検出してその操作に従ってパラメータの値の設定／変更や各部の動作を制御したり、コマンドをカードＩ／Ｏ２１０を介して他の音響信号処理装置に送信したり、カードＩ／Ｏ２１０を介して他の音響信号処理装置から受信したコマンドに従った処理を行ったりする。
【００５２】
フラッシュメモリ２０２は、ＣＰＵ２０１が実行する制御プログラムを始め、電源を切っても残しておくべきデータを記憶する書き換え可能な不揮発性記憶手段である。
ＲＡＭ２０３は、一時的に記憶すべきデータを記憶したり、ＣＰＵ２０１のワークメモリとして使用したりする記憶手段である。
【００５３】
外部機器Ｉ／Ｆ２０４は、種々の外部機器を接続し入出力を行うためのインタフェースであり、例えば外部のディスプレイ、マウス、文字入力用のキーボード、操作パネル、ＰＣ等を接続するためのインタフェースが用意される。ＰＣは、ＣＰＵ、メモリ、ハードディスク、ディスプレイ、キーボード、マウス、各種インターフェース、等を備え、Ｗｉｎｄｏｗｓ（商標）等のオペレーティングシステム（ＯＳ）が走る、通常のパーソナルコンピュータである。ユーザは、そのＯＳの元で、所望のアプリケーションソフトを起動して、ＰＣを使用する。
【００５４】
外部機器Ｉ／Ｆ２０４は、カードＩ／Ｏ２１０のオーディオバス２１７にも接続しており、オーディオバス２１７を流れる波形データを外部装置に送信したり、外部装置から受信した波形データをオーディオバス２１７に入力したりすることができる。この外部機器Ｉ／Ｆ２０４は、イーサネット、ＵＳＢ、ＩＥＥＥ１３９４等のいずれのインターフェースであってもよい。
【００５５】
表示器２０５は、ＣＰＵ２０１による制御に従って種々の情報を表示する表示手段であり、例えば、液晶ディスプレイ（ＬＣＤ）や発光ダイオード（ＬＥＤ）によって構成することができる。
操作子２０６は、音響信号処理装置１０に対する操作を受け付けるためのものであり、種々のキー、ボタン、ダイヤル、スライダ等によって構成することができる。
【００５６】
これらの表示器２０５及び操作子２０６は、例えば音響信号処理装置１０をコンソールとして構成する場合には、多数のｃｈについて信号処理パラメータやパッチの設定を受け付けるための大型のディスプレイや多数のボタン、スイッチ、電動フェーダ等を設け、入出力装置として構成する場合には電源及びモード設定のための簡単なランプやボタンを設ける等、装置の機能に応じて大きく構成が異なるものである。
【００５７】
また、カードＩ／Ｏ２１０は、オーディオバス２１７と制御バス２１８を備え、これらのバスに種々のカードモジュールを装着することにより、音響信号処理装置１０に対する音響信号及び制御信号の入出力及びその処理を行うことができるようにするためのインタフェースである。ここに装着される各カードモジュールは、オーディオバス２１７を介して相互に波形データを送受信すると共に、制御バス２１８を介してＣＰＵ２０１との間で制御信号を送受信し、ＣＰＵ２０１の制御を受ける。
【００５８】
オーディオバス２１７は、任意のカードから任意のカードへ、複数チャンネルの波形データをサンプリング周期に基づくタイミングで各１サンプルずつ時分割伝送する音響信号伝送用ローカルバスである。接続された複数カードの何れか１つがマスタとなり、当該カードが生成し供給するワードクロックに基づいてオーディオバス２１７の時分割伝送の基準タイミングを制御する。その他の各カードはスレーブとなり、その基準タイミングに基づいて各カードのワードクロックを生成する。
【００５９】
図５には、カードＩ／Ｏ２１０にＤＳＰ（デジタル・シグナル・プロセッサ）カード２１１，２１２，アナログ入力カード２１３，アナログ出力カード２１４，ネットワークＩ／Ｆカード２１５を装着した例を示している。
カードＩ／Ｏ２１０に装着される各種カードは、そのカードの機能に応じた波形データの処理を、それぞれ、ワードクロック（波形データのサンプリング周期）に基づくタイミングで実行する。
【００６０】
また、これらのカードのうちネットワークＩ／Ｆカード２１５が、送信Ｉ／Ｆと受信Ｉ／Ｆを２組備え、図１乃至図４を用いて説明したオーディオネットワークシステム１におけるＴＬフレーム１００の伝送と、ＴＬフレーム１００に対する波形データや制御データ等の読み書きとを行う機能を有する。これらの機能を実現するために必要なネットワークＩ／Ｆカード２１５の構成の詳細については、特開２００９−９４５８９号公報を参照されたい。
【００６１】
そして、ネットワークＩ／Ｆカード２１５以外のカードは、音響信号処理、アナログ信号の入出力などの機能を担うものであるが、音響信号処理装置１０に持たせたい機能に応じて任意に選択して装着することができる。さらに、ここで挙げたもの以外でも、その他カード２１６として、デジタル入出力、音源、レコーダ、エフェクタ等の、種々のカードモジュールを装着可能とすることが考えられる。
【００６２】
２．ＩＤを利用したデバイスの管理
ところで、上述したオーディオネットワークシステムを構成する各デバイスのように、リモート制御システムにおいて制御装置による制御対象とする各デバイスには、制御装置がそのデバイスを識別するための識別情報として、種々のＩＤを記憶させておく。
次に、このＩＤ及びＩＤを利用したデバイスの管理について説明する。なお、以下の説明において、「実デバイス」の用語を用いるが、これは、現実に存在して制御装置と通信可能な状態であるデバイス（例えば制御装置を含むオーディオネットワークシステムを構成するデバイス）を、後述する仮想デバイスと特に区別するための用語である。
【００６３】
また、以後の説明においては、この実施形態の特徴を説明し易くするため、図１乃至図６を用いて説明してきたようなＴＬフレームの定期的な循環を行うオーディオネットワークシステムを、図６に示すような、コンソール２Ｃｂ、ミキサエンジン２Ｅｘ、および入出力装置２Ｂａ，２Ｂｃ，２Ｂｄ，２Ｂｅ、２Ｂｆ，３Ｂａの８つのデバイスをカスケード接続して構成し、それらのデバイスの全部又は一部をリモート制御システムにおいて制御装置による制御の対象とする場合を例として用いる。図６において、実線がデバイス間の接続ケーブルを、破線がＴＬフレームの伝送経路を示す。
【００６４】
２．１ 各デバイスに記憶させるＩＤ
まず図７に、各デバイスに記憶させるＩＤの例を示す。ここで注目するのは、システムＩＤ、ユニークＩＤ、機種ＩＤ及びデバイスＩＤの４種である。
このうちシステムＩＤは、ＤＳＰカードにおける信号処理に用いるパラメータの設定や、ルーティングの設定など、音響信号処理に関するパラメータのリモート制御（設定）を制御装置から行う場合に、一度に制御の対象とするデバイスの範囲を１つのリモート制御システムとして規定するためのＩＤである。複数のデバイスを複数のシステムに分けて制御する場合、制御装置は、現在の制御対象のシステムを示すシステムＩＤを１つだけ選択し、自身と通信可能なデバイスのうち、そのシステムＩＤを持つデバイスのみを制御対象とする。
【００６５】
なお、システムＩＤは、ユーザが任意に設定可能なＩＤであるが、ここでは、容易に設定できるように、０から１５までの数字等、比較的少ない数の予め用意された選択肢から選択して設定するようにしている。
また、このシステムＩＤは、特開２００９−９４５８９号公報に記載のネットワークＩＤとは異なるものである。ここで、ネットワークＩＤは、一つながりのＴＬフレームの伝送経路（ループ接続の場合には伝送経路は２つになる）を形成するデバイスの範囲を示すＩＤであり、マスタノードが自動的に設定するものである。一方、システムＩＤはユーザが設定するものであるし、共通のシステムＩＤを付すデバイスの範囲は、一つながりの伝送経路が形成される範囲内とするのがよいが、必ずしもその範囲内に限定されるものではない。
【００６６】
ユニークＩＤは、制御装置と通信可能なデバイスのうち、以前から制御装置による制御対象の一群のデバイスとして動作していたデバイスと、そうでない（入れ替えや追加がなされた）デバイスとを制御装置が識別できるようにするために設けたＩＤである。詳細は後述するが、このユニークＩＤは、制御装置がデバイスにおけるパラメータの制御開始のための同期化を行う度に、一意な値を生成して、その時同期化した全てのデバイスに、その生成した値を設定させる。従って、ユーザはこのユニークＩＤの設定を行うことはできない。また、その値を知る必要もない。なお、図では「u2」と記載しているが、実際にはもっと長くて複雑なデータになって構わない。
【００６７】
機種ＩＤは、デバイスが、複数の機種のうちどの機種であるかを示すＩＤである。このＩＤは、デバイスのメーカーが各機種毎に設定する固定的なものであり、ユーザが変更することはできない。図６の例では、各入出力装置は同じ機種であり、同じ機種ＩＤを付している。コンソール２Ｃｂ及びミキサエンジン２Ｅｄは、それぞれ機種が異なるため、機種ＩＤも異なる。
【００６８】
デバイスＩＤは、ユーザが、各デバイスを識別するためにリモート制御システムの各仮想デバイス（後述）および各実デバイスに任意に設定する、例えば、アルファベットの１文字からなるＩＤである。２文字以上のアルファベットであってもよく、１〜３桁の数字、あるいは、アルファベットと数字の組み合わせであってもよい。とにかく、システムを構成する最大数のデバイスを識別できるＩＤであればよく、さらに言えば、ユーザが、限られた選択肢の中から容易に設定できる単純なＩＤとするのがよい。
【００６９】
デバイスＩＤの設定においては、あるシステムＩＤを記憶する異なる２つの実デバイスに同じデバイスＩＤを設定することはできるが、後述のように、ある１つのリモート制御システムの異なる２つの仮想デバイスには同じデバイスＩＤを設定することはできないよう、制限が掛けられている。その意味で、デバイスＩＤは、「リモート制御システム内の複数の仮想デバイスの１を特定するＩＤである」と言える。
【００７０】
なお、デバイスＩＤは、各デバイスを識別するためのＩＤであるから、基本的には各実デバイスに異なる値を設定すべきものである。しかし、リモート制御システムを構成していた実デバイスの一部を故障のため入れ替えたり、制御装置と通信可能な範囲に新たに実デバイスを追加したりしたような場合、たまたま、その入れ替えや追加に係るデバイスと、制御装置と通信可能な範囲の他のデバイスとでデバイスＩＤが一致してしまう場合もあり得る。
【００７１】
このような場合でも、ユニークＩＤを利用して、以前から制御装置による制御対象の一群のデバイスとして動作していたデバイス（１つのリモート制御システムを構成していたデバイス）と、入れ替えや追加に係るデバイスとを、制御装置が区別できるようにした点が、この実施形態の特徴である。
【００７２】
なお、デバイスＩＤはこのように異なる実デバイス間での重複があり得るため、実デバイスを確実に特定したい場合には、デバイスＩＤではなく、各実デバイスのネットワークカードに付与されたユニークなＭＡＣアドレスを用いる。しかし、ＭＡＣアドレスは書き換えられるものではないので、複数の制御装置がある場合、それを基準にして最後にシステムとして制御された複数のデバイスを識別することはできない。
【００７３】
２．２ 制御装置に記憶させる仮想デバイステーブル
次に、制御装置がリモート制御システムにおける制御対象デバイスを特定するために記憶する情報である、仮想デバイステーブルについて説明する。
【００７４】
図８に、この仮想デバイステーブルの例を示す。
この図に示すように、仮想デバイステーブルは、システムＩＤ毎に、それぞれそのシステムＩＤで特定されるリモート制御システムを構成すべき１つの制御対象デバイスを示す仮想デバイスの情報を記憶するテーブルである。仮想デバイステーブルは、ユーザが仮想デバイスを登録したシステムＩＤについてのみ用意すればよく、採りえる全てのシステムＩＤに対応してテーブルを用意する必要はない。また、ＶＤＮは、カッコ内のシステムＩＤについて登録されている仮想デバイスの数を示す変数である。
【００７５】
この仮想デバイステーブルにおいて、各仮想デバイスは、システムＩＤ，機種ＩＤ及びデバイスＩＤを特定して登録する。番号は、登録されている各仮想デバイスに、若い番号「１」から順番に自動付与されるものである。
また、ＭＤは仮想デバイスと対応づけた実デバイスのＭＡＣアドレスである。ＯＦは、仮想デバイスが、制御装置が対応する実デバイスのリモート制御を行うオンライン状態になっているか否かを示すフラグであるが、これらについては後述する。
【００７６】
なお、リモート制御システムへの仮想デバイスの追加ないし削除は、制御装置が実デバイスのリモート制御を行っていないオフライン状態で行われる。従って、仮想デバイスを登録する段階では、各仮想デバイスに対応する実デバイスが在るか否かは気にする必要がない。仮想デバイスは、対応する機種の実デバイスと同じ構成のパラメータを記憶する仮想的なデバイスであり、制御装置では、登録された仮想デバイスに関し、実デバイスと同様に各パラメータ値を編集することができる。
【００７７】
また、制御装置がコンソール２Ｃｂである場合、コンソール２Ｃｂの備えている波形データの信号処理（ＤＳＰ）、入出力（Ａ／Ｄ，Ｄ／Ａ）、送受信（ネットワークＩ／Ｆ）等のオーディオ機能は、それ自体が１つのデバイスに相当するものであって、他のデバイスと同様に、仮想デバイス（コンソール２Ｃｂ）として仮想デバイステーブルに登録される。その際、１つの仮想デバイスとして１つのシステムのみに登録されるようにしてもよいし、機能を複数に分割して、複数の仮想デバイスとして複数のシステムに登録できるようにしてもよい。ただし、コンソール２Ｃｂにおいて、仮想デバイス（コンソール２Ｃｂ）は常時オンラインであり、オフラインになることはない。
図８には、システムＩＤ＝２の仮想デバイス（番号＝７）としてコンソール２Ｃｂを登録した例を示している。
【００７８】
また、制御装置は、図９に示すように、リモート制御システムにおける各仮想デバイスのパラメータを記憶しており、各仮想デバイスが対応付けられた実デバイスとオンラインかオフラインかに関わらず、その各パラメータ値を変更できる。
ここでいうパラメータは、実デバイス内において行われるレベル調整や遅延、イコライザ等の信号処理の特性の制御や、パッチ処理の信号経路の制御、実デバイスのネットワークＩ／Ｆにおける波形データの送信や受信の制御を行う各種パラメータである。
【００７９】
制御装置によるリモート制御とは、これらの動作に使用するパラメータの値を、制御装置が受け付けたユーザ操作に従ってリモートで変更することを意味する。そして、制御装置が実デバイスのリモート制御を開始する際には、その実デバイス内のカレントメモリに記憶されたパラメータと、対応付けられた仮想デバイスのパラメータとの間で、各パラメータ値を同じとするためのコピー（同期化）が行われる。
【００８０】
各実デバイスのカレントメモリに記憶されているパラメータの構成（種類や数）は、その実デバイスの機種、装着されるオプション等に応じて決まる。制御装置には、登録された各仮想デバイスに対応して、その仮想デバイスと対応付けられる実デバイスのカレントメモリに記憶されるパラメータと全く同じ構成のパラメータが記憶される。
【００８１】
上述した同期化は、そのパラメータに関して行うものである。制御装置には、各機種ＩＤの示す機種および、装着される各種オプションに対応してメーカーが用意したパラメータ構成情報が記憶されている。ユーザがシステムにある機種ＩＤの仮想デバイスを登録する際には、その仮想デバイスに対応して、制御装置内に、その機種ＩＤに対応したパラメータ構成情報が示す構成のパラメータ領域が形成される。また、仮想デバイスに実デバイスのオプションに対応づけるための仮想オプションを装着する際には、同パラメータ領域内に同仮想オプションに応じたサブ領域が形成される。
【００８２】
以上のような図９に示すデータは、リモート制御に関する表示のレスポンスをよくするため、リモート制御操作に応じてまず制御装置自身が記憶するパラメータの内容を更新して、制御対象の装置に操作内容を通知する前に先に結果を表示できるようにするために用いることができる。リモート制御の開始に先立って、リモート制御の対象となるデバイスと、その内容について同期を取るのはこのためである。
【００８３】
なお、図９においては、参考のために仮想デバイスの番号を示したが、各仮想デバイスはシステムＩＤとデバイスＩＤのみで特定可能であるから、番号を記憶する必要はない。
また、以上のような制御装置におけるパラメータの記憶及び同期化の対象には、カレントメモリに記憶させて実際の信号処理内容に反映させるデータの他、カレントメモリの内容を保存して後で読み出せるようにしたシーン等のデータを含めるようにしてもよい。
また、制御装置が記憶するパラメータには、複数のシステムが関わる制御を行うためのデータであるシステム制御用パラメータ（制御対象システムＩＤ等）も含まれている。
【００８４】
次に、上述した仮想デバイステーブルの編集に係る処理について説明する。仮想デバイステーブルの編集は、制御装置が記憶する全仮想デバイスがオフラインの場合（後述するオンライン状態になっている仮想デバイスがない場合。ただし制御装置自身が仮想デバイステーブルに登録されている場合には制御装置自身はオンラインになっていてよい）にのみ行うことができる。また、編集に際し、情報を登録あるいは削除しようとする仮想デバイスと対応するデバイスが実際に存在しているかどうかを気にする必要はない。
【００８５】
まず、図１０に、仮想デバイス追加処理のフローチャートを示す。
この処理は、制御装置のＣＰＵ（制御装置がコンソール２Ｃｂである場合にはＣＰＵ２０１であり、ＰＣである場合はそのＰＣのＣＰＵ、以下同様）が、ユーザの操作による仮想デバイス追加指示を検出した場合に実行する処理である。また、追加指示は、例えば、追加する仮想デバイスのシステムＩＤ（ｓとする）、機種ＩＤ（ｋとする）及びデバイスＩＤ（ｄとする）を指定して行うものである。
【００８６】
この処理において、制御装置のＣＰＵはまず、仮想デバイステーブルに既に登録されている仮想デバイス中に、追加指示に係る仮想デバイスとシステムＩＤ及びデバイスＩＤの双方が一致するものがあるか否か判断する（Ｓ１０１）。
なければ、指示に従って仮想デバイスを追加すべく、まずシステムＩＤ＝ｓについての仮想デバイス数ＶＤＮ（ｓ）をインクリメントする（Ｓ１０２）。そして、システムＩＤ＝ｓのシステムについて、機種ＩＤ＝ｋで特定される機種の制御に用いるパラメータの記憶領域を確保すると共に、所定の初期値を設定する（Ｓ１０３）。
【００８７】
次に、仮想デバイステーブルに、システムＩＤ＝ｓのシステムの新たな番号の仮想デバイスのデータとして、機種ＩＤ＝ｋ及びデバイスＩＤ＝ｄを登録する（Ｓ１０４）。その後、登録結果をディスプレイの画面に表示させ（Ｓ１０５）、処理を終了する。
ステップＳ１０１で一致するものがあった場合、重複登録を避けるため、登録エラーをディスプレイの画面に表示させ（Ｓ１０６）、登録せずに処理を終了する。
【００８８】
以上の処理により、ユーザの指示に従って仮想デバイステーブルに新たな仮想デバイスのデータを追加すると共に、その仮想デバイスのパラメータを記憶する記憶領域を用意し、初期値をセットすることができる。また、先述したように、各システムＩＤについて、同じデバイスＩＤの仮想デバイスが重複登録されないようにすることができる。
なお、仮想デバイスの追加指示受付時に、既存の追加デバイスとシステムＩＤ及びデバイスＩＤの双方が一致するものについて、選択肢から外す等して追加の指示を受け付けることができないようにしている場合には、ステップＳ１０１の分岐は不要である。
【００８９】
次に、図１１に、仮想デバイス削除処理のフローチャートを示す。
この処理は、制御装置のＣＰＵが、ユーザの操作や外部装置からの要求による仮想デバイス削除指示を検出した場合に実行する処理である。また、削除指示は、削除する仮想デバイスのシステムＩＤ（ｓとする）及びデバイスＩＤ（ｄとする）を指定して行うものである。
【００９０】
この処理において、制御装置のＣＰＵはまず、削除指示に係るシステムＩＤ＝ｓについて、仮想デバイス数ＶＤＮ（ｓ）をデクリメントする（Ｓ１１１）と共に、削除指示に係るデバイスＩＤ＝ｄで特定される仮想デバイスの制御に用いるパラメータの記憶領域を解放する（Ｓ１１２）。
次に、仮想デバイステーブルから、システムＩＤ＝ｓのシステムの、デバイスＩＤ＝ｄが登録されている仮想デバイスのデータを削除する（Ｓ１１３）と共に、削除結果をディスプレイの画面に表示させ（Ｓ１１４）、処理を終了する。
【００９１】
以上の処理により、ユーザの指示に従って仮想デバイステーブルから仮想デバイスのデータを削除すると共に、そのデバイスの制御に使用するパラメータのデータも削除することができる。
【００９２】
２．３ 仮想デバイスと実デバイスの対応付け
次に、仮想デバイステーブルのデータを用いた、仮想デバイスと実デバイスとの対応付けについて説明する。
この対応付けは、基本的には制御装置が自動的に行うものであるが、一部ユーザの選択に従ったり、また、自動的な対応付けの後ユーザが手動でその内容を変更したりすることができる。また、対応付けの処理自体は、自動であっても手動であっても、仮想デバイステーブルのデータと、各デバイスから収集した図７に示した各ＩＤとに基づいて制御装置が内部的に行う処理であり、それ自体で他のデバイスに影響を与えるものではない。対応付けの結果に基づいてデバイスの制御を開始する処理については、別途後述する。
【００９３】
なお、制御装置がＩＤを収集するデバイスの範囲は、制御装置が接続されているのと同じネットワークに接続された全デバイスである（図６の例ではオーディオネットワークシステムＳに所属するデバイスであるが、ネットワークにおけるデバイスの接続態様や通信プロトコルはこれに限られない）。なお、隣接する１ないし複数のネットワークまで、ネットワーク間のルータを越えてデバイスをサーチし、発見されたデバイスのＩＤを収集するようにしてもよい。ＩＤ収集のための処理の図示は省略するが、制御装置は、ＡＲＰ（Address Resolution Protocol），ＩＣＭＰ（Internet Control Message Protocol）等のプロトコルを使用して定期的にネットワークをスキャンし、新たに接続されたデバイスの検出を行う。そして、デバイスが検出された場合には、該デバイスにＩＤを要求し、その要求に応じて要求先のデバイスが送信してくる、図７に示した各種ＩＤを受信する
【００９４】
なお、各実デバイスは、その実デバイスのネットワークＩ／Ｆカードに付与されたＭＡＣアドレスにより特定できる。ここでは、収集した各ＩＤは、図１２の実デバイステーブルに示すように、各デバイスのＭＡＣアドレスと対応付けて管理するようになっている。また、ＩＤ収集処理では、ネットワークから消滅したデバイスも検出され、消滅したデバイスの情報は実デバイステーブルから削除される。
【００９５】
ここで、図１３に、自動対応付け処理のフローチャートを示す。なお、この処理の説明において、具体的な対応付けの例は、仮想デバイステーブルの内容が図８に示したものであり、制御装置は図６に示したオーディオネットワークシステムＳを構成する各デバイスからＩＤを収集し、その収集したＩＤが、図１２に示すものであるとして説明する。
【００９６】
また、図１３の処理は、制御装置が新たにネットワークに接続され、その制御装置が、そのネットワークに接続されているデバイスを検出したとき（一通り終わるまで待ってからでもよい）、リモート制御システムのリセットが指示されたとき、等に実行されるものである。また、ネットワークに接続された複数のデバイスの電源を投入し、または、制御対象のデバイスが属するネットワークの全デバイスをリセットして、そのネットワークを最初から形成しようとするとき、にも実行される。
【００９７】
そして、これらの場合、制御装置のＣＰＵは自動的に図１３に示す処理を開始する。
この処理において、制御装置のＣＰＵはまず、ＩＤを収集した各デバイスのうち、システムＩＤが、現在の制御対象となっているシステムＩＤを示す変数ＴＧの値と一致するものを、ユニークＩＤが同じもの毎にグループ化する（Ｓ２０１）。
ＴＧ＝２である場合、図１２に示した７つのデバイスのうち、システムＩＤ＝２である６つのデバイスを、ユニークＩＤが「ｕ１」であるグループと、ユニークＩＤが「ｕ２」であるグループと、ユニークＩＤが「none（未設定）」であるグループとに分けることになる。なお、ユニークＩＤが「none（未設定）」であるグループは、作成しなくてもよい。
【００９８】
次に、制御装置のＣＰＵは、ステップＳ２０１で作成したグループ毎に、仮想デバイステーブルに登録されたシステムＩＤがＴＧの各仮想デバイスに対し、グループ内のデバイスのうち機種ＩＤ及びデバイスＩＤが一致するものを対応付ける（Ｓ２０２）。システムＩＤについては、ステップＳ２０１でシステムＩＤがＴＧであるデバイスのみを処理対象としているため、必ず一致する。
【００９９】
例えば、ユニークＩＤが「ｕ１」であるグループについては、番号が２である仮想デバイスが、図１２の一番上のデバイスと対応付けられることになる。ユニークＩＤが「ｕ２」であるグループについては、番号が４である仮想デバイスが、図１２の上から２番目のデバイスと、番号が６である仮想デバイスが、同じく３番目のデバイスと対応付けられることになる。図１２の上から５番目のデバイスについては、対応付ける相手がない。
このステップＳ２０２での対応付けは、優先グループの選択基準とする情報を取得するための予備的な対応付けである。
【０１００】
そして次に、制御装置のＣＰＵは、ステップＳ２０２での各グループについての対応付けの結果に基づき、ステップＳ２０１で作成したグループの１つを優先グループとして選択する（Ｓ２０３）。
この優先グループは、ＩＤの重複があった場合に優先的に仮想デバイスと対応付けるデバイスを規定するグループである。そして、ここでの選択基準は種々のものが考えられ、例えば、対応付けできたデバイスの数が多いグループを選択したり、対応付けの結果をユーザに提示し、ユーザに選択させたり、またはその組み合わせとしたりすることが考えられる。
なお、ステップＳ２０２での結果によらず、ユーザが予めＭＡＣアドレス等により指定しておいたデバイスを含むグループを優先グループとすることも考えられる。この場合、ステップＳ２０１の処理は不要である。
【０１０１】
以上の後、処理はステップＳ２０４のデバイス検索処理に進む。
図１４に、このデバイス検索処理のフローチャートを示す。
この処理において、制御装置のＣＰＵはまず処理対象の仮想デバイスの番号を示す変数ｉに１を設定し（Ｓ２１１）、仮想デバイステーブルに登録された仮想デバイスのうちシステムＩＤ＝ＴＧで番号＝ｉのものと同じシステムＩＤ、機種ＩＤ及びデバイスＩＤを持つデバイスを、ＩＤを収集したデバイスの中から検索する（Ｓ２１２）。そして、検索によりデバイスをいくつ発見したか判断する（Ｓ２１３）。
【０１０２】
ここで、発見数が０の場合、オーディオネットワーシステムＳ中（ＩＤの収集を行った範囲）には、処理対象の（システムＩＤ＝ＴＧで番号＝ｉの）仮想デバイスに対応付けるべきデバイス、すなわちその仮想デバイスに関するデータを用いて制御すべきデバイスがないことがわかる。そこで、その仮想デバイスに対応付けるデバイスのアドレスを示す仮想デバイステーブル（図８参照）のＭＤ（ＴＧ，ｉ）に、対応付けるデバイスがないことを示すｎｕｌｌを設定する（Ｓ２１４）。
また、発見数が１の場合、処理対象の仮想デバイスについては、デバイスＩＤの重複設定はなく、オーディオネットワーシステムＳ中で対応付けるべきデバイスを一意に特定できることがわかる。そこで、ＭＤ（ＴＧ，ｉ）に、発見したデバイスのＭＡＣアドレスを設定する（Ｓ２１５）。先述したように、ＭＡＣアドレスは、実デバイスを特定するための情報であるので、ここでのＭＡＣアドレスを書き込みは、仮想デバイスへの実デバイスの対応付けに相当する。
【０１０３】
一方、発見数が２以上の場合、オーディオネットワーシステムＳ中に、システムＩＤ、機種ＩＤ及びデバイスＩＤにより区別できないデバイスが２以上あり、ＩＤの設定が適切になされていないことがわかる。そこで、ディスプレイにメッセージを表示させる等により、ユーザにこの点を警告する（Ｓ２１６）。
【０１０４】
その後、発見したデバイス中に図１３のステップＳ２０３で選択した優先グループのデバイスがあれば（Ｓ２１７のＹＥＳ）、ＭＤ（ＴＧ，ｉ）にその優先グループのデバイスのＭＡＣアドレスを設定する（Ｓ２１８）。優先グループのデバイスがなければ、発見したデバイスの１つをユーザに選択させ（Ｓ２１９）、ＭＤ（ＴＧ，ｉ）にその選択されたデバイスのＭＡＣアドレスを設定する（Ｓ２２０）。
【０１０５】
ステップＳ２１４，Ｓ２１５，Ｓ２１８，Ｓ２２０のいずれの場合も、ＭＤ（ＴＧ，ｉ）へのデータ設定完了後、ｉをインクリメントし（Ｓ２２１）、仮想デバイスの数ＶＤＮ（ＴＧ）を超えていなければ（Ｓ２２２のＮＯ）、ステップＳ２１２に戻って処理を繰り返す。超えていれば、処理対象のシステムＩＤに関する対応付けは完了であるので、元の処理に戻る。
図１３の説明に戻ると、以上のデバイス検索処理により、自動対応付けは完了するので、対応付け結果をディスプレイの画面に表示させ（Ｓ２０５）、処理を終了する。
【０１０６】
以上の処理により、仮想デバイステーブルに登録されている仮想デバイスのうち、現在の制御対象として設定されているシステムＩＤを有する各仮想デバイスと、制御装置が接続されているオーディオネットワークシステムＳを構成するデバイスとを、デバイス間にユーザが設定するシステムＩＤやデバイスＩＤの重複がある場合でも、ユニークＩＤを参照して適切に自動的に対応付けることができる。
【０１０７】
なお、図１４のステップＳ２１９ではユーザに選択を求めているが、ステップＳ２１７でＮＯになるのは、かなり例外的な場合であり、このような状況になることはほとんどない。しかし、ここで説明している対応付けは、所与のアルゴリズムで決定できない場合でもランダムで行うべきものではないため、念のためステップＳ２１９以下の処理を設けている。
【０１０８】
ここで、例えば、図１３のステップＳ２０３で、優先グループを１つ選択するだけでなく、対応付けできたデバイスの数が多い順にグループに優先順位を付し、図１４のステップＳ２１３で判断が２以上になった場合に、優先順位の高いグループのデバイスを優先的に対応付けるようにすれば、対応付けが自動的に決まらず、ユーザに選択を求める可能性をさらに減らすことができる。
また、複数の制御装置が存在する場合、それらが実デバイスと順次同期化すれば、その度に各デバイスのユニークＩＤが書き換わることになる。本発明では、仮想デバイスとの対応付けができるグループが多いグループを優先することにより、そういった状況であっても、それら各制御装置において、仮想デバイスと実デバイスの適切な対応付けを行うことができる。
【０１０９】
次に、図１５に、同期化処理のフローチャートを示す。
この同期化処理は、制御装置によるデバイスの制御を開始するための処理であるが、同時に、上述の対応付けの際に重要な役割を果たすユニークＩＤの設定を行う処理でもある。
制御装置のＣＰＵは、ユーザの操作によるオンライン移行指示を検出した場合に、その時点でなされている対応付けに従ってオーディオネットワークシステムＳ中のデバイスの制御を開始するため、図１５に示す処理を開始する。
【０１１０】
この処理において、制御装置のＣＰＵはまずユニークなＩＤを生成する（Ｓ２３１）。生成方法は問わないが、オーディオネットワークシステムＳと同種のシステムが運用される範囲で重複がないと期待できる程度のユニークさが望ましく、例えば、制御装置のＭＡＣアドレスと生成時点の時刻とを含むＩＤとすることが考えられる。また、ユニークＩＤをＵＵＩＤ（汎用一意識別子：Universally Unique Identifier）やＧＵＩＤ（グローバル一意識別子）などに基づいて生成してもよい。
【０１１１】
そして、生成したユニークなＩＤを、仮想デバイステーブルに登録されている仮想デバイスのうち、現在の制御対象を示すシステムＩＤ（＝ＴＧ）を有する全ての仮想デバイスについて、その仮想デバイスと対応付けられているデバイスに送信し、ユニークＩＤとして記憶するよう要求する。ここでは、システムＩＤ＝ＴＧの仮想デバイステーブルに登録されている全ての仮想デバイスの番号ｉについて、それぞれＭＤ（ＴＧ，ｉ）に設定したＭＡＣアドレスを宛先として送信を行えばよい（Ｓ２３２）。ただし、ＭＤ（ＴＧ，ｉ）の値がｎｕｌｌのものについては、送信不要である。また、ＭＡＣアドレスが、上述の自動対応付けにより設定されたものであるか、後述する手動対応付けにより設定されたものであるかを考慮する必要はない。
【０１１２】
また、デバイスのリモート制御に関するデバイス間のあらゆる送信は、すべて、イーサネットの通信帯域を使用して行われる。ここでは、ＭＡＣ層の処理として説明されているが、ＭＡＣ層の上のインターネット層の処理とすることも可能であり、その場合、インターネットパケットに書き込まれる宛先アドレスは、ＭＡＣアドレスに対応するデバイスのＩＰアドレスである。何れの場合であっても、ＭＡＣ層においてはイーサネットフレームには同じＭＡＣアドレスが記載され、同じデバイス宛てに送信される。
【０１１３】
そして、ステップＳ２３２で送信される情報を受信した宛先のデバイスは、要求に応じて、受信したＩＤをユニークＩＤとして設定する（Ｓ１３１）。
また、制御装置のＣＰＵは、ステップＳ２３２の後、実デバイスが対応付けられているシステムＩＤ＝ＴＧの各仮想デバイスにつき、その仮想デバイスのパラメータと、対応付けられた実デバイスのカレントメモリのパラメータとを、ユーザが指定した方向に同期化させる（Ｓ２３３）。この同期化は、何れか一方のパラメータをコピー元、他方のパラメータをコピー先として、１デバイス分の全パラメータをコピーして、それらの値を相互に一致させることによって行う。また、コピーするパラメータの転送は、転送元の制御装置ないしデバイスのパラメータを複数の部分に分けて各部分毎にダンプし、ダンプされたデータをイーサネットフレームに記載して、コピー先のデバイスないし制御装置に転送することにより、実行できる。コピー先のデバイスないし制御装置は、転送されたパラメータを既存のパラメータに上書きする。
【０１１４】
ここで、上述のように、各実デバイスは、制御装置に記憶されている仮想デバイスのパラメータではなく、デバイス自身が記憶しているパラメータの値に従って、信号伝送や信号処理を行う。そこで、この処理の状態を維持することを優先する場合（例えば、稼働中のシステムのネットワークに後から制御装置を接続し、そのシステムの動作を継続させたい場合など）には、各実デバイスのカレントメモリのパラメータをコピー元とし、制御装置の対応付けられた仮想デバイスのパラメータをコピー先とすればよい。
【０１１５】
一方、制御装置の記憶している仮想デバイスのパラメータに従った信号処理を各実デバイスに行わせたい場合（例えば、新たなネットワークシステムあるいはリモート制御システムを稼動させたい場合や、稼働中のシステムを止めて別の論理構成のシステムを立ち上げたい場合など）は、制御装置の各仮想デバイスのパラメータをコピー元とし、対応付けられた実デバイスのカレントメモリのパラメータをコピー先とすればよい。
ユーザは、どちらの方向に同期化を行うかを、全仮想デバイスについて一括して、又は仮想デバイス毎に個別に設定することができる。
【０１１６】
そして、制御装置のＣＰＵは、以上の同期化の後、同期化した全ての仮想デバイスにつき、仮想デバイステーブルのフラグＯＦを「１」に設定してその仮想デバイスが対応付けられた実デバイスとオンラインになった旨を記憶する（Ｓ２３４）と共に、各仮想デバイスがオンラインかオフラインかを区別してディスプレイの画面に表示させてユーザに通知し（Ｓ２３５）、処理を終了する。
【０１１７】
なお、ある仮想デバイスがオフラインの場合、フラグＯＦの値は「０」であり、制御装置でユーザがその仮想デバイスのパラメータ値の変更操作をすると、制御装置が記憶するその仮想デバイスのパラメータの値のみが変更される。対応付けられた実デバイスがあったとしても、そのパラメータ値は変更されず、リモート制御は行われない。
【０１１８】
一方、ある仮想デバイスが対応付けられた実デバイスとオンラインの場合には、オンライン移行時の同期化処理でその仮想デバイスと実デバイスは同じ値のパラメータを記憶している。そして、制御装置でその仮想デバイスのパラメータ値を変更すると、その変更が対応する実デバイスに通知され、その実デバイスにおいても同様にパラメータ値が変更される。また、その実デバイスを操作して実デバイスのパラメータ値を変更すると、その変更が制御装置に通知され、対応する仮想デバイスのパラメータ値が同様に変更される。このように、オンライン状態にある場合、制御装置の仮想デバイスと実デバイスとでパラメータの値が連動しており、制御装置でその仮想デバイスのパラメータ値を変更することにより、対応する実デバイスのパラメータ値を変更して、その実デバイスの動作をリモート制御することができる。
【０１１９】
以上の処理により、制御装置がＩＤを収集した実デバイスのうちの、何れかの仮想デバイスと対応付けられた各実デバイスは、対応する仮想デバイスとオンラインとなり、制御装置からのリモート制御を受け付ける。その際、オンラインとなった各実デバイスには、制御装置が新たに生成した１つのユニークＩＤが記憶される。そして、このユニークＩＤは、別の制御装置をネットワークに接続するとき、ないし、同じ制御装置をネットワークから一旦切り離して再接続する際の、図１３に示す自動対応付け処理で参照する。なお、制御装置を新たにネットワークに接続して、最初に図１５の処理を実行する前は、その制御装置の全ての仮想デバイスはオフラインである。
【０１２０】
また、図１５の処理でオンラインになった仮想デバイスは、対応するデバイスがオーディオネットワークシステムＳから除外されたり、動作を停止するなどして制御装置と該当デバイスとの接続が切れたりした場合に、オフラインに戻る。また、ユーザによるオフライン移行指示があった場合には、制御装置のＣＰＵが全仮想デバイスをオフラインに戻す。
また、図１５の処理では、実デバイスが対応付けられた全ての仮想デバイスの同期化を行っているが（ステップＳ２３３）、同期化処理の開始時に既にオンラインの仮想デバイスがある場合、その仮想デバイスは既に対応付けられた実デバイスとパラメータが同期しているので、その仮想デバイスに関する同期化の処理を省略してもよい。
【０１２１】
ところで、図１３の処理での自動対応付けや図１５の処理での同期化は、現在の制御対象として設定されているシステムＩＤを持つ仮想デバイスについてのみ行ったが、この「現在の制御対象」を示すシステムＩＤは、ユーザが制御装置のユーザインタフェースを操作して変更可能である。なお、１つの制御装置が複数のシステムＩＤのシステムを任意に切り替えて制御する場合、その制御装置に各システムの情報（仮想デバイステーブル、仮想デバイスのパラメータ等）を独立して記憶するようにすれば、制御対象のシステムの変更をレスポンスよく行うことができる。
【０１２２】
図１６に、この変更のための処理を示す。
制御装置のＣＰＵは、現在の制御対象を示すシステムＩＤを変更するための制御対象システム設定指示を検出すると、図１６に示す処理を開始する。
そしてまず、オンライン中の仮想デバイスを全てオフラインにすると共に（Ｓ２４１）、指示に従って、現在の制御対象を示すシステムＩＤの値を変数ＴＧに設定する（Ｓ２４２）。そしてその後、その新たに設定したＩＤ値を用いて、図１３に示した自動対応付け処理を行って（Ｓ２４３）、処理を終了する。
なお、制御対象システムの設定指示を、全仮想デバイスがオフラインの場合のみ行うことができるようにした場合は、ステップＳ２４１の処理は不要である。
【０１２３】
以上の処理により、常に、現在の制御対象として設定されているシステムＩＤを有する仮想デバイスが、オーディオネットワークシステムＳを構成する（制御装置がＩＤを収集した範囲の）適当なデバイスと対応付けられ、オンライン状態にすることにより制御装置から制御可能な状態を保つことができる。
従って、例えばシステムＩＤが「３」であるデバイスを制御したい場合には、ユーザは、現在の制御対象を示すシステムＩＤを「３」に設定した上で、図１５の処理の実行を指示するオンライン移行指示を行えばよい。
【０１２４】
以上のようにシステムＩＤで制御対象を区別することにより、複数の異なるリモート制御システムを制御対象として指定して、そのリモート制御システムを構成すべき実デバイスをリモート制御することができるようになる。なお、異なるリモート制御システムの仮想デバイスを、同時にオンラインにできるようにすることもできる。その場合であっても、制御対象として指定されるシステムＩＤは制御装置で１つだけとして、何れか１つのシステムのみを制御対象としてリモート制御するのがよい。
【０１２５】
また、図１３の処理により行われた、仮想デバイスと実デバイスとの対応付けは、ユーザが制御装置のユーザインタフェースを操作して手動で変更することもできる。
図１７に、この変更のための手動対応付け処理のフローチャートを示す。
制御装置のＣＰＵは、ユーザから、仮想デバイスの指定と共にその仮想デバイスに関する手動対応付けを指示された場合に図１７のフローチャートに示す処理を開始する。なお、指定できるのは、現在の制御対象を示すシステムＩＤ（ＴＧとする）を有する仮想デバイスのみである。
【０１２６】
図１７の処理において、制御装置のＣＰＵはまず、対応付けを指示された仮想デバイスをオフラインにする（Ｓ２５１）。この場合、その仮想デバイスと対応する実デバイスがあれば、そのデバイスの制御を中止するが、中止に応じてその仮想デバイスの制御に用いる制御パラメータの値を変更する必要はない。また、もともとオフラインであれば、何もしなくてよい。
また、手動対応付けの指示を、全部の仮想デバイスがオフラインの場合、ないし、対象の仮想デバイスがオフラインの場合にのみ行うことができるよう制限した場合は、ステップＳ２５１の処理は不要である。
【０１２７】
次に、指示に係る仮想デバイスに対応付けることができる実デバイスの候補として、その仮想デバイスとシステムＩＤ、機種ＩＤ及びデバイスＩＤが一致する実デバイスを、ＩＤを収集してあるデバイスの中から検索する（Ｓ２５２）。この検索範囲は、実デバイスの追加や除去がなければ、図１４のステップＳ２１２の場合と同じである。
そして、ここで検索されたデバイスの１つを、仮想デバイスに対応付ける実デバイスとしてユーザに選択させ（Ｓ２５３）、指示に係る仮想デバイスについての対応する実デバイスのアドレスＭＤ（ＴＧ，ｉ）に、選択されたデバイスのＭＡＣアドレスを設定する（Ｓ２５４）と共に、対応付け結果をディスプレイの画面に表示させて（Ｓ２５５）、処理を終了する。
【０１２８】
以上の処理により、自動対応付け処理による対応付けの内容がユーザの希望と合わない場合に、ユーザが対応付けの内容を事後的に変更することができる。この手動での対応付けの際には、システムＵＩＤと実デバイス側のユニークＩＤとの一致／不一致を気にする必要はない。また、手動により変更された仮想デバイスと実デバイスの対応付けは、この後、ユーザがオンラインへの移行を指示し、図１５の同期化処理が実行することにより、ネットワークに接続された実デバイスに反映される。その際、制御装置は新たなユニークＩＤを生成し、生成されたユニークＩＤは各実デバイスに記憶される。
【０１２９】
なお、ＩＤを収集する範囲内に、システムＩＤ、機種ＩＤ及びデバイスＩＤの一致するデバイスが２つ以上存在しない通常の場合には、ステップＳ２５２の検索で発見されるデバイスは最大１つである。この場合、ステップＳ２５３で選択を受け付ける必要はないが、代わりに、発見されたデバイスを対応付けるか否かの選択を受け付けるようにするとよい。
【０１３０】
逆に、ステップＳ２５２で複数のデバイスが発見される場合、それらのデバイスはシステムＩＤ、機種ＩＤ及びデバイスＩＤが共通であるので、ステップＳ２５３での選択受付時には、これ以外の情報、例えばＭＡＣアドレスを提示して、発見された複数のデバイスをユーザが区別できるようにする。あるいは、発見された各実デバイスに対応するボタンをディスプレイ画面上に表示し、ユーザの操作に応じて、対応する実デバイスに反応指示を送信し、受信した実デバイスが本体の表示器を点滅させる、等して区別できるようにしてもよい。
【０１３１】
２．４ システムの構成変更時の対応
次に、制御装置により実デバイスをリモート制御中に、ネットワークに対して実デバイスが追加されたり、実デバイスのシステムＩＤやデバイスＩＤが変更されたりした場合でも、仮想デバイスと実デバイスとの対応付けを適切に維持し、制御装置によるデバイスの制御を継続できるようにするための処理について説明する。
【０１３２】
まず、図１８に、制御装置のＣＰＵが、ネットワークに新たに接続されたデバイスを検出した場合に実行する処理のフローチャートを示す。
図６に示したオーディオネットワークシステムＳでは、特開２００９−９４５８９号公報に記載のものと同様、ＴＬフレームの巡回を継続しつつ、カスケード接続されたデバイス上に形成されるループ上のフレーム伝送路を動的に変更することができる。新たなデバイスがカスケード接続されているデバイス群の端部に接続された場合は、そのデバイスを含むようにフレーム伝送路が変更され、既存のデバイスとそのデバイスとの間でのオーディオ伝送やイーサネットフレーム伝送が可能となる。
【０１３３】
そしてこの場合、制御装置と新たに接続されたデバイスとの間のイーサネットフレーム伝送が可能となり、制御装置による上述したネットワークスキャンにより、新たに接続された実デバイスを発見することができる。そこで、そのデバイスを発見した制御装置は、図１８のフローチャートに示す処理を開始する。
この処理において、制御装置のＣＰＵはまず、新たに接続された実デバイスからＭＡＣアドレス、システムＩＤ、ユニークＩＤ、機種ＩＤ及びデバイスＩＤを取得し、図１２に示したような既知デバイスの情報（実デバイステーブル）に追加する（Ｓ２７１）。
【０１３４】
そして、新たに接続された実デバイスのシステムＩＤが、現在の制御対象を示すシステムＩＤ（ＴＧとする）と一致するか否か判断する（Ｓ２７２）。ここで一致していれば、仮想デバイステーブルから、新たに接続された実デバイスとシステムＩＤ、機種ＩＤ及びデバイスＩＤの全てが一致する仮想デバイス、すなわち新たに接続された実デバイスと対応付けることができる仮想デバイスを検索する（Ｓ２７３）。
【０１３５】
そして、もしあれば（Ｓ２７４のＹＥＳ）、発見した仮想デバイスの番号をｉとし（Ｓ２７５）、ＭＤ（ＴＧ，ｉ）＝Ｎｕｌｌであれば、すなわち発見した仮想デバイスに対応付けられているデバイスがなければ（Ｓ２７６のＹＥＳ）、ＭＤ（ＴＧ，ｉ）に新たに接続された実デバイスのＭＡＣアドレスを設定して、発見した仮想デバイスに新たに接続された実デバイスを対応付ける（Ｓ２７７）と共に、その対応付け結果をディスプレイの画面に表示させてユーザに通知し（Ｓ２７８）、処理を終了する。
【０１３６】
一方、ステップＳ２７２でＮＯの場合には、新たに接続された実デバイスは現在は制御装置による制御対象とならないデバイスであるので、この時点では対応付けは行わず、そのまま処理を終了する。
ステップＳ２７４でＮＯの場合には、新たに接続された実デバイスを対応付けることのできる仮想デバイスがないことがわかるため、その旨をユーザに警告して（Ｓ２７９）、処理を終了する。
また、ステップＳ２７６でＮＯの場合には、新たに接続されたデバイスを対応づけるべき仮想デバイスには既に実デバイスが対応付けられていて、デバイス間でシステムＩＤ、機種ＩＤ及びデバイスＩＤの設定が重複していることがわかる。そこで、その旨をユーザに警告して（Ｓ２８０）、処理を終了する。なお、この場合には、図１７に示した手動対応付け処理により、その対応付けるべき仮想デバイスに新たに接続された実デバイスを対応付けるよう変更することができる。
【０１３７】
以上説明してきた図１８の処理によれば、制御装置がＩＤを収集する範囲のネットワークに新たにデバイスが追加された場合でも、制御装置がそのデバイスを適切に仮想デバイスに対応付けることができる。この後、ユーザがオンラインへの移行を指示し、図１５の同期化処理を実行することにより、対応付けの内容がネットワークに接続された実デバイスに反映される。
【０１３８】
次に、制御装置によるリモート制御の対象となり得るデバイスにおけるデバイスＩＤ及びシステムＩＤを設定する場合の処理について説明する。
各デバイスのデバイスＩＤ及びシステムＩＤの設定（変更）は、そのデバイスが全ての制御装置の仮想デバイスとオフラインである場合に、ユーザが操作子２０６を操作することで行われる。
【０１３９】
この場合、該当デバイスは、ユーザが入力したＩＤを新たに設定されるデバイスＩＤ又はシステムＩＤとしてフラッシュメモリ２０２として記録すると共に、フラッシュメモリ２０２に記録してあったユニークＩＤをクリアする。そしてこのことにより、どの制御装置においても、図１３のステップＳ２０１におけるグループ化の対象外となる。しかし、変更後のシステムＩＤとデバイスＩＤの組が重複しているデバイスが他になければ（図１４のステップＳ２１３での発見数が１であれば）、グループ化されたか否かに関わらず、ＩＤを変更したデバイスを適当な仮想デバイスと対応付けることができる。
なお、実デバイスが何れかの仮想デバイスとオンラインである場合には、その実デバイスにおいてデバイスＩＤ及びシステムＩＤの設定を行うことはできない。
【０１４０】
２．５ 対応付けの具体例
次に、制御装置が以上説明してきた各種ＩＤ及び仮想デバイステーブルを用いて行う制御対象デバイスの認識について、図１９に示す具体例を用いて説明する。
図１９に示す例において、実線の枠はこの発明の実施形態のリモート制御システムにおける制御対象のデバイスを含むネットワークシステム（図６に示したものとは異なる）を構成する１つ１つの実デバイスを示す。そして、その枠内の文字は、そのデバイスが記憶しているＩＤを、「システムＩＤ，ユニークＩＤ／機種ＩＤ／デバイスＩＤ」の書式で示している。なお、これらのＩＤは、分かりやすいように単純な数字や文字により記載しているが、特にユニークＩＤについては、一意性を確保するためにより長いデータ長（ビット数）とする必要があり、とにかく、何れのＩＤについても、実際の装置に適用する際にこのような形式を採ることが好ましいという意味ではない。
【０１４１】
また、図中の「システムを構成するデバイス」及び「オンライン後の各デバイスの状態」における各実デバイスの縦方向における位置は、ネットワークシステムにおける各デバイスの物理的な接続順ではなく、個々のデバイスを特定するもの（ＭＡＣアドレスに相当）である。すなわち、この図中の異なる場所の、縦方向の位置が同じデバイスは、同じ実デバイスに相当する。
【０１４２】
そして、「オンライン後の各デバイスの状態」の欄では、いずれかの仮想デバイスと対応付けられている実デバイスを示す枠を太線で、仮想デバイスと対応付けられていない実デバイスを示す枠を通常の線で記載している。
また、破線の枠は、仮想デバイステーブルに登録されている１つ１つの仮想デバイスのデータを示す。そして、その枠内の文字は、その仮想デバイスについて設定されているＩＤを、「システムＩＤ／機種ＩＤ／デバイスＩＤ」の書式で示している。仮想デバイスの番号については、図示していない。
そして、各仮想デバイスに対応付けられるデバイスがある場合、図で中央の欄において、仮想デバイスを示す枠と実デバイスを示す枠とを実線で結んでこれを示している。
【０１４３】
まず、図１９に示す例では、（ａ）の「システムを構成するデバイス」の欄に示す５台の実デバイス（制御装置がこれらのデバイス以外の装置である場合にはこれらに加えて不図示の制御装置）がネットワークシステムを構成し、仮想デバイステーブルにはそれらの実デバイスを示す仮想デバイスが適切に設定されている状態において、ネットワークシステムを構成する実デバイスをスペアと入れ替える場合を考える。
この場合、現在の制御対象を示すシステムＩＤとして図に示す「１」が設定されていれば、図１３に示した自動対応付け処理により、図に示すように、ネットワークシステムを構成する全ての実デバイスが仮想デバイスに対応付けられ、制御装置による制御の対象となる。
【０１４４】
そして、制御装置において仮想デバイスをオンラインにすると、図１５の同期化処理により各デバイスとの間でパラメータの同期化が行われると共に、新たに生成したユニークＩＤが、制御対象となっている各実デバイス（ここでは図示した全てのデバイス）に設定される。
この状態は、デバイスを入れ替えたり仮想デバイステーブルの内容を変更したりしなければ、何度電源オンオフやシステムの再起動を行っても、同様に維持される（ただし、設定されるユニークＩＤの値自体はオンライン化の動作を行うたびに変わる）。
【０１４５】
また、故障等の理由により実デバイスを入れ替えても、入れ替え後の実デバイスにシステムＩＤ、機種ＩＤ及びデバイスＩＤが仮想デバイステーブルの内容と対応するように適切に設定されていれば、ユニークＩＤが他の実デバイスと統一されていなくても、入れ替え前と同様に対応付け及び制御装置による制御が可能である（図１３のステップＳ２０１のグループ化では入れ替えた実デバイスは別グループになるが、図１４のステップＳ２１３で発見数が「１」となるため、グループ分けの影響はない）。一旦オンライン化を行えば、ユニークＩＤも他の実デバイスと統一される。
【０１４６】
しかし、（ｂ）に示すように、入れ替え後の実デバイスに、古い設定の変更し忘れなどにより、誤って、入れ替えを行っていない（以前からネットワークにおいて制御装置による制御の対象であった）実デバイスのいずれかと全く同じシステムＩＤ、機種ＩＤ及びデバイスＩＤが設定されてしまっている場合には、これらのＩＤだけではどちらが入れ替えた実デバイスでどちらが入れ替えを行っていない実デバイスであるか、区別することができない。
【０１４７】
例えば、（ｂ）に示す例では上から２番目の実デバイスと６番目の実デバイスでシステムＩＤ、機種ＩＤ及びデバイスＩＤが一致しているため、図１４のステップＳ２１２で上から２番目の１／Ａ／ｂの仮想デバイスと対応付ける実デバイスを検索した際、これらの２つの実デバイスが発見される。
しかし、入れ替えた上から６番目の実デバイスには、入れ替えを行っていない２番目の実デバイスとは異なるユニークＩＤが設定されている。従って、その前の図１３のステップＳ２０１で異なるグループに分けられる。
【０１４８】
そして、２番目の実デバイスが属するグループが図１３のステップＳ２０３で優先グループとして選択されるようにしておけば、図１４のステップＳ２１７及びＳ２１８で、２番目の仮想デバイスに、入れ替え前の状態で対応付けられていたものと同じ、２番目の実デバイスを自動的に対応付けることができる。
ここで、通常は、入れ替えを行う実デバイスより、入れ替えを行っていない実デバイスの方が数が多いと考えられる。そこで、図１３のステップＳ２０３での優先グループの選択基準を、ステップＳ２０２で対応付けのできた実デバイスの数が最も多いグループとすれば、多くの場合に、入れ替えていない実デバイスで構成されるグループが優先グループになるようにすることができると考えられる。図１９の例では、この基準を採用しているとして説明する。
【０１４９】
以上の通りであるので、（ｂ）に示す状態では、５つの仮想デバイスのうち４つに、図示のように実デバイスが対応付けられる。システムＩＤ、機種ＩＤ及びデバイスＩＤが共通なデバイスについても、以前から制御対象になっていた実デバイスを適切に見分けて対応付けを行うことができる。
【０１５０】
デバイスの入れ替え等においては、以前から制御対象になっていた実デバイスの設定はそのままとして、新たに入れるデバイスの設定を変更する場合が多い。そのため、設定ミスは、新たに入れる実デバイスで生じている確率が高い。そこで、本実施形態の自動割当処理では、設定ミスの確率が低いと考えられる、以前から制御対象になっていた実デバイスを、仮想デバイスに優先的に割り当てるようになっている。
【０１５１】
なお、（ｂ）の対応付けがなされた状態で各仮想デバイスをオンラインにすると、対応付けがなされた４つの実デバイスについてのみ同期化が行われ、共通の新たなユニークＩＤ（ｕ２）が設定される。一方、仮想デバイスと対応付けられていない６番目の実デバイスのユニークＩＤは更新されない。従って、６番目の実デバイスのみ他の実デバイスとユニークＩＤが異なるという状態は、オンライン後も維持される。また、実デバイスをさらに入れ替えたり仮想デバイステーブルの内容を変更したりしなければ、次に電源がオンされたりシステムの再起動がされたりした場合も、同様な対応付けにより、６番目の実デバイスのみ他のデバイスとユニークＩＤが異なるという状態が維持される。
【０１５２】
また、上述のように、各実デバイスに設定されているデバイスＩＤは変更可能である。そこで、ユーザは、（ｂ）の状態において、６番目の実デバイスのデバイスＩＤを「ｂ」から「ｃ」に変更して、仮想デバイスと対応する「正しい」設定とすることができる。
この設定を行った状態が（ｃ）である。この状態でも、図１３のステップＳ２０１のグループ化では３番目の実デバイスは他の実デバイスと別グループになる。しかし、ネットワーク内に、システムＩＤ、機種ＩＤ及びデバイスＩＤが重複するデバイスがなく、全ての仮想デバイスについて図１４のステップＳ２１３で発見数が「１」となるため、グループ分けに関係なく、実デバイスを対応付けることができる。そして、一旦オンライン化を行えば、ユニークＩＤも他の実デバイスと統一され、実質的に（ａ）と同様な、適切な制御の可能な状態になる。
なお、入れ替えた実デバイスに入れ替え時点から適切なＩＤの設定がなされていれば、（ａ）の状態から（ｂ）を経ずに（ｃ）の状態へ移行する。
【０１５３】
３．第２の実施形態
次に、この発明のリモート制御システムの第２の実施形態について説明する。
上述した第１の実施形態においては、仮想デバイスと実デバイスの対応付けに変更があったか否かに関わらず同期化処理を行う度にユニークＩＤを更新するようにしていたが、この第２の実施形態では、対応付けに変更があった場合にのみユニークＩＤを更新するようにした点が、第１の実施形態と異なる。また、各制御装置が、制御対象デバイスに記憶させた最新のユニークＩＤを記憶しておき、実デバイスが記憶しているユニークＩＤがこれと一致するか否かに応じて、その実デバイスに対して異なる取扱いをするようにした点も、第１の実施形態と異なる。
そこで、この相違点及びそれに関連して処理内容を変更すべき点についてのみ説明する。
【０１５４】
３．１ 制御装置に記憶させる仮想デバイステーブル
まず、図２０に、この実施形態において制御装置が記憶する仮想デバイステーブルの例を示す。
この図に示すように、仮想デバイステーブルに、上記の「制御対象デバイスに記憶させた最新のユニークＩＤ」を、システムＵＩＤとして、システムＩＤ毎に登録する。例えば、システムＵＩＤ（２）＝u2は、システムＩＤが「２」のシステムにおいて最後に制御対象デバイスに記憶させたユニークＩＤが「u2」であることを示す。
【０１５５】
なお、このユニークＩＤは、自身で生成した場合には、後述する図２３のステップＳ３２３で生成及び設定するものである。また、自身でユニークＩＤの生成及び設定を行った後で他の制御装置がユニークＩＤの生成及び設定を行った場合には、該他の制御装置からそのユニークＩＤを含む仮想デバイステーブルが通知され、ユーザの指示に応じて図２４のステップＳ３４３で設定する。
【０１５６】
仮想デバイステーブルに登録するその他の情報については、第１の実施形態の場合と同じであり、図１０や図１１の処理による仮想デバイスの追加や削除も同様に行うことができる。
なお、第１の実施形態の場合には、仮想デバイスと対応付けられている実デバイスのＭＡＣアドレスを示すＭＤの値は、制御装置のリセット時や電源ＯＦＦ時には削除してしまってもよかったが、第２の実施形態の場合には、リセット時や電源ＯＦＦ時でもＭＤの値を保持しておく。
【０１５７】
３．２ 仮想デバイスと実デバイスの対応付け
次に、図２１に、自動対応付け処理のフローチャートを示す。この処理は、第１の実施形態で図１３に示した処理と対応するものである。そして、この処理も、図１３の場合と同様、制御装置が新たにネットワークに接続された場合や、リモート制御システムのリセットが指示された場合などに制御装置のＣＰＵが自動的に実行する。
この処理において、制御装置のＣＰＵはまず、ＩＤを収集した各実デバイスのうち、システムＩＤが、現在の制御対象となっているシステムＩＤを示す変数ＴＧの値と一致するものを選定する（Ｓ３０１）。
【０１５８】
そして、仮想デバイステーブルに登録されたシステムＩＤの値がＴＧの各仮想デバイスに対し、ステップＳ３０１で選定した実デバイスのうち機種ＩＤ及びデバイスＩＤが一致するものを対応付ける（Ｓ３０２）と共に、システムＩＤがＴＧのデバイスに記憶させた最新のユニークＩＤ＝システムＵＩＤ（ＴＧ）の値を準備する（Ｓ３０３）。このシステムＵＩＤ（ＴＧ）の値が、必ずしも図２１の処理を実行中の制御装置自身が生成した値とは限らないことは、上述の通りである。
【０１５９】
制御装置のＣＰＵは、その後、ｉを１からシステムＩＤがＴＧの仮想デバイスの数ＶＤＮ（ＴＧ）まで順次増加させながら、ステップＳ３０２で行った対応付けの内容を確認する処理（Ｓ３０４〜Ｓ３０９）を行う。
この際の確認において重要なポイントの１つは、ステップＳ３０２で対応付けられた実デバイスに、仮想デバイスとＭＡＣアドレスが一致し、かつシステムＵＩＤ（ＴＧ）とユニークＩＤが一致する実デバイスが含まれているか否か、という点である。
【０１６０】
仮想デバイスと対応付けた実デバイスとでＭＡＣアドレスが一致していることにより、自機においてその仮想デバイスに対応付けてある実デバイスと同じ個体が、今回の自動対応付けの時点でも依然として自機と同じネットワークに接続されており、自機からリモート制御可能な状態であることがわかる。また、同じくユニークＩＤがシステムＵＩＤ（ＴＧ）と一致していることにより、その対応付けてある実デバイスが、最新のオンライン移行指示（自機が行ったものか他の制御装置が行ったものかは問わない）の際にオンラインになったデバイスであることがわかる。
【０１６１】
従って、上記のＭＡＣアドレス及びユニークＩＤの一致を確認できれば、該当の実デバイスは、過去にも仮想デバイスと対応付られていたデバイスであり、自機の把握していないところで仮想デバイスとの対応付けが変更されてリモート制御システムから除外されているようなこともなく、自機の仮想デバイステーブルに登録されている対応付け（ＭＤの値）を維持して問題ないデバイスであると考えることができる。このような意味で、上記のＭＡＣアドレス及びユニークＩＤの一致を確認できたデバイスを、「既知デバイス」と呼ぶことにする。
【０１６２】
そして、ステップＳ３０２でｉ番目の仮想デバイスと対応付けられた実デバイス、すなわち仮想デバイスとシステムＩＤ、機種ＩＤ及びデバイスＩＤの一致するデバイス（システムＩＤの一致はステップＳ３０１で保証される）が、既知デバイス１つのみであれば、その仮想デバイスについて、実デバイス側にＩＤの設定漏れや重複等の不備はなく、対応付けの変更も必要ないことがわかる。すなわち現在の設定に問題ないことがわかる。
従って、ステップＳ３０５での判断結果がこのようなものであった仮想デバイスについては、特に何の処理も行わず、それまでの設定内容を維持する。設定に問題がない旨をユーザに通知してもよい。
【０１６３】
また、ステップＳ３０２でｉ番目の仮想デバイスと対応付けられる実デバイスがなかった場合には、ｉ番目の仮想デバイスと対応付けるべき実デバイスは自機が接続されているネットワークシステムに含まれていないことがわかる。この場合、該当する仮想デバイスの制御はできないが、第１の実施形態の場合と同様、それ以上の問題はなく、この時点で対応付けの内容を変更する必要もない。
従って、ステップＳ３０５での判断結果がこのようなものであった仮想デバイスについても、特に何の処理も行わず、それまでの設定内容を維持する。対応する実デバイスがない旨をユーザに通知してもよい。
【０１６４】
一方、ステップＳ３０２でｉ番目の仮想デバイスと対応付けられた実デバイスが既知デバイスを含む複数のデバイスであった場合、対応付け自体には深刻な問題はないが、ネットワークシステム内にシステムＩＤ、機種ＩＤ及びデバイスＩＤの重複する複数の実デバイスが存在することになり、実デバイスにおけるＩＤの設定が適切になされていないことがわかる。従って、ユーザにその旨を警告する（Ｓ３０６）。図１７のステップＳ２５３の場合と同様な手法により、どのデバイスが既知デバイスで、どのデバイスがその他の対応付けられたデバイスであるかをユーザが区別できるようにしてもよい。
そして、この警告を受けたユーザは、実デバイスにおけるＩＤの設定を変更して重複を解消したり、手動対応付けにより仮想デバイスと対応付ける実デバイスを変更したりする対応を行うことが考えられる。
【０１６５】
ここで、手動対応付け処理は、第１の実施形態において図１７を用いて説明したものと概ね同様である。しかし、図２２に示すように、手動対応付けにより実際に対応付けの内容（仮想デバイステーブルにおけるＭＤの値）が変更された場合に、システムＩＤ＝ＴＧのシステムにおける同期化処理時のユニークＩＤ更新要否を示すフラグＣＦ（ＴＧ）に更新要を示す「１」を設定する処理（Ｓ３１１，Ｓ３１２）が追加されている点が、図１７の場合と異なる。
【０１６６】
図２１の説明に戻ると、ステップＳ３０２でｉ番目の仮想デバイスと対応付けられた実デバイスが既知デバイスを含まない１又は複数のデバイスであった場合、２つの可能性及びその複合が考えられる。
【０１６７】
まず、対応付けられた実デバイスの中にＭＡＣアドレスの一致する実デバイスがなかった場合には、以前ｉ番目の仮想デバイスと対応付けていた実デバイスが何からの理由に撤去され、その代替となる実デバイスがネットワークシステムに接続されていることがわかる。この場合、ステップＳ３０２で対応付けられた実デバイスが１つだけであればその実デバイスを、複数あればそのうちいずれかの実デバイスを、ｉ番目の仮想デバイスに新たに対応付ければ（ＭＤの値をその実デバイスのＭＡＣアドレスに更新すれば）よいと考えられる。このような対応付けを自動で行ったり、また自動対応付け処理の中でユーザに設定変更の許可を求めたりすることも考えられるが、ここでは、デバイスが入れ替えられた旨をユーザに警告する（Ｓ３０７）に留め、実際の対応付けは、手動対応付けにより行うようにしている。
【０１６８】
また、ステップＳ３０２で対応付けられた実デバイスの中にＭＡＣアドレスが一致する実デバイスはあったがそのデバイスについてユニークＩＤが一致しない場合、以前ｉ番目の仮想デバイスと対応付けていた実デバイスはシステムＩＤ及びデバイスＩＤの設定内容を維持したまま残っているものの、他の制御装置により、仮想デバイスとの対応付けが解除されていることがわかる。他の制御装置が図２３により後述する同期化処理においてオンラインにする（仮想デバイスと対応付けてある）実デバイスにユニークＩＤを設定する際に、仮想デバイスと対応付けられていなかったためユニークＩＤの設定対象とならなかった実デバイスが、このような、ＭＡＣアドレスが一致するもののユニークＩＤが一致しない状態となるためである。
【０１６９】
この場合には、必ずしも自機における仮想デバイスと実デバイスとの対応付けを他の制御装置に合わせて変更する必要はないが、変更することが好ましい場合もあるので、他の制御装置により仮想デバイスと実デバイスとの対応関係が変更されている旨をユーザに警告する（Ｓ３０７）。ユーザは、この警告に応じて任意に手動対応付けにより対応関係を変更することができる。
【０１７０】
以上の処理により、制御装置のＣＰＵは、仮想デバイステーブルの内容と、各実デバイスから収集したシステムＩＤ、機種ＩＤ、デバイスＩＤ及びユニークＩＤの値とに基づき、各仮想デバイスと実デバイスとの対応付を行うと共に、対応付けに不具合又はその恐れがある場合には、その旨をユーザに警告することができる。
この警告に従った不具合の是正は、次の図２２に示す手動対応付けの処理あるいは各実デバイスにおけるＩＤの設定変更により行うことができる。そして、手動対応付けにより仮想デバイステーブルの内容を変更した場合には、ＣＦ（ＴＧ）に「１」が設定されることになる。
【０１７１】
また、上述の通り図２１の処理において自動で対応付けの不具合を是正するようにしてもよいが、この場合も、仮想デバイステーブルの内容を更新した場合には、ＣＦ（ＴＧ）を「１」に設定する必要がある。また、図示は省略したが、仮想デバイステーブルに対する仮想デバイスの追加や削除あるいはＩＤの設定変更を行った場合も、同様にＣＦ（ＴＧ）を「１」に設定する。
【０１７２】
なお、ステップＳ３０６又はＳ３０７で警告を行った場合にその旨を記憶しておき、警告がある仮想デバイスにつきユーザが手動対応付けや警告無視の指示を行うまでは図２３の同期化処理を行えないようにしたり、同期化処理において、既知のデバイスについてのみオンライン化を行うようにしたり、警告がある仮想デバイスについてはオンライン化を行わないようにしたりすることも考えられる。
【０１７３】
次に、図２３に、同期化処理のフローチャートを示す。この処理は、第１の実施形態で図１５に示した処理と対応するものである。そして、この処理も、図１５の場合と同様、ユーザの操作によるオンライン移行指示を検出した場合に制御装置のＣＰＵが実行するものである。
【０１７４】
この処理において、制御装置のＣＰＵはまず、ＣＦ（ＴＧ）の値により、ユニークＩＤの更新が必要か否か判断する（Ｓ３２１）。そして、更新要を示す「１」であれば、ＣＦ（ＴＧ）を「０」にリセットする（Ｓ３２２）と共に、図１５のステップＳ２３１の場合と同様にユニークなＩＤを生成し、仮想デバイステーブルにシステムＵＩＤ（ＴＧ）の値として設定する。また、存在を把握している他の制御装置に対して、その新たなシステムＵＩＤ（ＴＧ）を含むシステムＩＤ＝ＴＧの仮想デバイステーブルの内容を通知する（Ｓ３２３）。
【０１７５】
ステップＳ３２３の通知を受けた制御装置のＣＰＵは、図２４のフローチャートに示す処理を開始し、まず、通知された仮想デバイステーブルに含まれるシステムＵＩＤを引き継ぐか否かを、適当な選択画面をディスプレイに表示させる等してユーザに選択させる（Ｓ３４１）。
そして、ユーザが引き継ぐことを選択した場合（Ｓ３４２のＹＥＳ）、通知されたシステムＩＤ＝ＴＧの内容で、自身が記憶するシステムＩＤ＝ＴＧの仮想デバイステーブルを置き換え（Ｓ３４３）、処理を終了する。
ユーザが引き継がないことを選択した場合、そのまま処理を終了する。この場合、受信した仮想デバイステーブルの内容を破棄されることになる。
【０１７６】
ここで、図２４に示した処理によるシステムＵＩＤの引き継ぎの意義について説明する。
まず、リモート制御システムに制御装置が複数含まれる場合、そのいずれからも同じようにシステムの構成を変更できるようにすると、制御動作に混乱が生じる可能性がある。そこで、システムの構成の変更は、ユーザアカウントの権限制御などにより、特定のオペレータ（システム管理者）だけが行えるようにすることが好ましい。
なお、ここでまでに説明してきた仮想デバイステーブルの内容変更（仮想デバイスの追加や削除）や、仮想デバイスと実デバイスとの対応付けの変更は、システムの構成の変更の具体例である。
【０１７７】
そして、図２３のステップＳ３２３で制御装置が行う他の制御装置への仮想デバイステーブルの通知は、仮想デバイスと実デバイスとの対応付けが変更され、ＣＦ（ＴＧ）が１となった場合に実行されるものであるので、システム管理者が行う、「それまでとは異なるシステムの制御を開始したので、他の制御装置もそれに同期しなさい。」という指示のようなものと考えることができる。
【０１７８】
また、新たなシステムＵＩＤを含む仮想デバイステーブルの通知は、システム管理者からの通知であるため、通知を受けた他の制御装置のオペレータは、その制御装置が同じシステムＩＤのシステムを制御していれば、基本的には、その通知を受け入れると考えられる。
そして、ステップＳ３４３で、自身が記憶する仮想デバイステーブルを通知された仮想デバイステーブルの内容に置き換えることにより、通知元の制御装置とシステムＵＩＤ及び仮想デバイスを統一できる。従って、仮想デバイステーブルを通知された制御装置も、オンライン移行指示に応じて図２３の処理を実行することにより、以下に説明する通知元の制御装置の場合と同じ仮想デバイスに、同じ実デバイスを対応付けられることになる。
【０１７９】
なお、ステップＳ３２３での仮想デバイステーブルの通知対象は、例えば、同じネットワークシステムに接続された全ての制御装置、とすればよい。あるいは、それらの制御装置のうち、システムＩＤ＝ＴＧの仮想デバイステーブルを記憶している制御装置に限定してもよい。
さらに、自身と重複する範囲の実デバイスを制御対象とする他の制御装置のアドレスなどを予め登録しておき、その登録した制御装置を通知対象としてもよい。システム管理者のアカウントで動作する制御装置が、自機と異なるシステムＵＩＤを記憶した他の制御装置を発見したときに通知するようにすることも考えられる。
【０１８０】
また、通知対象の制御装置の動作として、仮想デバイステーブルを通知された場合でも、通知された仮想デバイステーブルと同じシステムＩＤの仮想デバイステーブルを記憶していない場合や、通知された仮想デバイステーブルに登録されている仮想デバイスと、自身における同じシステムＩＤの仮想デバイステーブルに登録されている仮想デバイスとに全く共通のものがない場合には、通知を受け取らないようにしたり、受け取っても、ユーザに引き継ぎ要否を確認せずに廃棄するようにしてもよい。これらの場合、通知元の制御装置は通知対象の制御装置と関連が薄く、むしろ仮想デバイステーブルの内容を統一しない方が好ましいと考えられるためである。
【０１８１】
図２３の説明に戻ると、制御装置のＣＰＵは、ステップＳ３２３の後、ｉを１から仮想デバイスの数ＶＤＮ（ＴＧ）まで順次増加させながら（Ｓ３２４，Ｓ３２９，Ｓ３３０）、システムＩＤ＝ＴＧのｉ番目の仮想デバイスをオンラインにするための処理（Ｓ３２５〜Ｓ３２８）を行う。
【０１８２】
すなわち、システムＩＤ＝ＴＧのｉ番目の仮想デバイスとＭＡＣアドレス、システムＩＤ及びデバイスＩＤの全てが一致する実デバイスが実デバイステーブルにあれば（Ｓ３２５）、その実デバイスが、ｉ番目の仮想デバイスと対応付けられているデバイスであることがわかる。そこで、その実デバイスにシステムＵＩＤ（ＴＧ）を送信してユニークＩＤとして記憶するよう要求する（Ｓ３２６）と共に、その仮想デバイスのパラメータと、対応付けられた実デバイスのカレントメモリのパラメータとを、ユーザが指定した方向に同期化させる（Ｓ３２７）。その後、ｉ番目の仮想デバイスについてのフラグＯＦを「１」に設定して、その仮想デバイスが対応付けられた実デバイスとオンラインになった旨を記憶する（Ｓ３２８）。
【０１８３】
なお、ステップＳ３２５でシステムＩＤ及びデバイスＩＤの一致を確認するのは、図２１や図２２の処理による対応付けの後で、実デバイスに対する直接操作によってその実デバイスのシステムＩＤやデバイスＩＤが変更されている可能性があるためである。
また、同期化については、システム管理者のアカウントで動作中の制御装置が行う場合には、どちら向きに行ってもよい。しかし、その他の制御装置が行う場合には、システム管理者がリモート制御中のシステムへのオンライン化となるので、実デバイスにおけるパラメータを読み出して仮想デバイスのパラメータとしてコピーする方向で行うことが好ましい。
【０１８４】
また、ステップＳ３２６で送信されるシステムＵＩＤ（ＴＧ）を受信した宛先のデバイスは、要求に応じて、受信したＩＤをユニークＩＤとして設定する（Ｓ３５１）。
そして、ｉがＶＤＮ（ＴＧ）に達し、ステップＳ３３０でＹＥＳとなった時点で、各仮想デバイスがオンラインかオフラインかを区別してディスプレイの画面に表示させてユーザに通知し（Ｓ３３１）、処理を終了する。
【０１８５】
以上の処理により、制御装置がＩＤを収集した実デバイスのうちの、何れかの仮想デバイスと対応付けられた各実デバイスは、対応する仮想デバイスとオンラインとなり、制御装置からのリモート制御を受け付ける。その際、オンラインとなった各実デバイスには、制御装置が記憶するシステムＵＩＤ（ＴＧ）と同じ値のユニークＩＤが設定されることになる。ステップＳ３２６で送信するシステムＵＩＤ（ＴＧ）は、ステップＳ３２３で新たなＩＤを設定していればそのＩＤであるし、そうでない場合には以前から仮想デバイステーブルに登録されていたＩＤであるが、どちらの場合でも、システムＵＩＤ（ＴＧ）と同じ値であることに変わりはない。また、複数の制御装置が存在する場合には、システムＵＩＤ（ＴＧ）の値は、それら制御装置間で共有される。
【０１８６】
従って、複数ある制御装置のうちいずれが図２３の処理を行った場合であっても、最新のオンライン移行指示の際に仮想デバイスに対応付けられているデバイスのみに、各制御装置が記憶するシステムＵＩＤ（ＴＧ）と共通のユニークＩＤを設定されることになる。
複数ある制御装置のうちいずれが図２２の処理などにより仮想デバイステーブルの内容を変更した場合であっても、その後その制御装置が図２３の処理を行う際に、その時点でその制御装置において仮想デバイスに対応付けられているデバイスのみに、各制御装置が記憶するシステムＵＩＤ（ＴＧ）と共通のユニークＩＤを設定されることになる。
【０１８７】
従って、各制御装置は、図２１の自動対応付け処理において、各実デバイスに設定されているユニークＩＤと、自身が記憶するシステムＵＩＤ（ＴＧ）とを比較することにより、実デバイスの配置やデバイスＩＤの設定自体には何の変更もない場合であっても、他の制御装置が行った仮想デバイステーブルの内容変更（及びそれに伴う仮想デバイスと実デバイスとの対応関係の変更）を検出し、ユーザに注意を喚起することができる。このような検出は、ＭＡＣアドレスの比較のみでは行うことができない。
【０１８８】
なお、この実施形態においては、仮想デバイスと実デバイスの対応付けに変更があった場合（仮想デバイステーブルの内容に変更があった場合）にのみユニークＩＤの値を更新するようにしている。そして、仮想デバイステーブルの内容にも、仮想デバイスに対応付けられている実デバイス（ＭＡＣアドレス）にも変更のない場合には、その実デバイスがネットワーク上から消滅（主に電源ＯＦＦによると考えられる）したり、ネットワーク上に新たに登場（主に電源ＯＮによると考えられる）したりしても、新たなシステムＵＩＤを生成することなく、従来のＵＩＤを続けて用いるようにしている。従って、ユニークＩＤの更新回数を抑えることができる。
【０１８９】
また、図２１の処理によれば、上記の主に電源ＯＮ／ＯＦＦに起因すると考えられる実デバイスの消滅や登場にいちいち警告を発することなく、異なるデバイスが導入された時など、ユーザが特段の注意を払う必要がある場合についてのみ、的確に警告を行うことができる。
【０１９０】
また、この実施形態において、複数ある制御装置のうち一部の制御装置のみが仮想デバイステーブルの内容変更及び手動対応付けを行うことができるようにしてもよい。このようにした場合、仮想デバイステーブルの内容変更及び手動対応付けの機能を有する装置をシステム管理者が操作し、その他の装置を一般ユーザが操作するようにするとよい。そして、該その他の装置においては、フラグＣＦ（ＴＧ）が「１」になることはないので、該その他の装置が新たなシステムＵＩＤを生成することはない。
また、この実施形態において、制御装置が、仮想デバイステーブルの内容変更及び手動対応付けの機能を有する装置１台だけであっても、ユニークＩＤを用いた仮想デバイスと実デバイスの対応付けによる効果は得られる。
【０１９１】
３．３ 対応付けの具体例
次に、制御装置が以上説明してきた処理により行う制御対象デバイスの認識について、図２５及び図２６に示す具体例を用いて説明する。これらの図の書式は、特に断らない限り、図１９と同じである。
【０１９２】
まず、図２５に示す例では、（ａ）の「システムを構成するデバイス」の欄に示す５台の実デバイスがネットワークシステムを構成し、これらの実デバイスを制御する制御装置としてＡとＢの２台の制御装置（実デバイスのいずれかが制御装置として機能してもよい）がネットワークシステムに接続され、そのうち制御装置Ａがシステム管理者のアカウントで動作している場合を考える。
【０１９３】
（ａ）に示す状態では、各実デバイスはデバイスＩＤの設定を行った直後の状態であり、ユニークＩＤはクリアされている。そしてこの状態では、図２１に示した自動対応付け処理において、ユニークＩＤは制御装置のシステムＵＩＤと一致しないため、実デバイスは既知デバイスとはならない。なおここでは、図２１の処理で既知デバイスとならない実デバイスを「未知デバイス」と呼ぶことにする。
【０１９４】
図２５（ａ）に破線の枠で示す仮想デバイスが登録された仮想デバイステーブルを有する制御装置Ａにおいて自動対応付け処理を行うと、図２１のステップＳ３０２の処理において、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられる。しかし、上記のように、これらの実デバイスは全て未知デバイスであるので、ステップＳ３０７で警告がなされる。そして、ユーザは、その後図２２に示した手動対応付け処理により、図２１のステップＳ３０２で行われた対応付けを仮想デバイステーブルに（ＭＤの値として）登録することができる。このとき、フラグＣＦ（１）に「１」がセットされる。なお、ＣＦ（１）は、ＴＧ＝１の場合のＣＦ（ＴＧ）である。
【０１９５】
その後、ユーザが制御装置Ａにおいてオンライン移行指示を行うと、制御装置Ａは図２３の同期化処理を実行し、実デバイスと仮想デバイスとの間でパラメータの同期化を行う。このとき、ＣＦ（１）が「１」であるので、制御装置Ａは新たなシステムＵＩＤ（値は「u1」とする）を生成して仮想デバイステーブルに設定し、その仮想デバイステーブルを他の制御装置（ここでは制御装置Ｂ）に通知する。またその新たなシステムＵＩＤを、仮想デバイスと対応付けた図で上から３つの実デバイスにユニークＩＤとして記憶させる。
【０１９６】
このシステムＵＩＤやユニークＩＤは、デバイスを入れ替えたり仮想デバイステーブルの内容を変更したりしなければ、何度電源オンオフやシステムの再起動を行っても、同様に維持される。
【０１９７】
一方、制御装置Ｂは、（ａ）で制御装置Ａから仮想デバイステーブルを通知された際にユーザがシステムＵＩＤを引き継ぐ選択をすると、（ｂ）に示すように、システムＵＩＤの値を含め、仮想デバイステーブルの内容が（ａ）の動作終了後の制御装置Ａと同じものになる。
この状態で自動対応付け処理を行うと、図２１のステップＳ３０２の処理おいて、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられるが、これらすべてのデバイスは既知デバイスであるので、警告は発生しない。また、手動対応付けを行う必要もないので、フラグＣＦ（１）が「０」のままオンライン移行指示を行うことができる。
【０１９８】
そして、この状態で同期化処理を行うと、新たなシステムＵＩＤの生成は行わずに、パラメータの同期化を行う。ステップＳ３２６ではシステムＵＩＤの値を実デバイスに記憶させるが、ここで記憶させる値は、実デバイスが既に記憶している値を同じ値のはずであり、確認的な処理となる。
そして、同期化処理により、実デバイスと制御装置Ｂの仮想デバイスとの間でも、パラメータの同期化が行われる。
なお、制御装置Ａの仮想デバイスが実デバイスとオンラインのままでも、同時に制御装置Ｂの仮想デバイスを同じ実デバイスとオンラインにすることは可能である。
【０１９９】
次に、（ｂ）に示した状態で、上から３番目の実デバイスを、故障等の理由により（ｃ）に示す上から６番目の実デバイスに入れ替えた場合を考える。
（ｃ）の状態で制御装置Ａにおいて自動対応付け処理を行うと、図２１のステップＳ３０２の処理において、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられる。これらの実デバイスのうち上２つは既知デバイスであるが、交換で新しく加えた「1,uy/A/c」の実デバイスは、ユニークＩＤが仮想デバイステーブルと一致せず、未知デバイスであるので、ステップＳ３０７で警告がなされる。そして、ユーザは、その後図２２に示した手動対応付け処理により、「1,uy/A/c」の実デバイスを「1/A/c」の仮想デバイスに対応付けることができる。
【０２００】
その後、ユーザが制御装置Ａにおいてオンライン移行指示を行うと、制御装置Ａは図２３の同期化処理を実行する。このとき、手動対応付けによりＣＦ（１）が「１」になっているため、制御装置Ａは再度新たなシステムＵＩＤ（値は「u2」とする）を生成して仮想デバイステーブルに設定し、その仮想デバイステーブルを制御装置Ｂに通知する。またその新たなシステムＵＩＤを、仮想デバイスと対応付けた実デバイスにユニークＩＤとして記憶させる。
【０２０１】
一方、制御装置Ｂは、（ｃ）で制御装置Ａから仮想デバイステーブルを通知された際にもユーザがシステムＵＩＤを引き継ぐ選択をすると、（ｄ）に示すように、新たなシステムＵＩＤの値を含め、仮想デバイステーブルの内容が（ｃ）の動作終了後の制御装置Ａと同じものになる。
この状態で自動対応付け処理を行うと、図２１のステップＳ３０２の処理おいて、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられるが、これらすべてのデバイスは既知デバイスであるので、警告は発生しない。
【０２０２】
そして、この状態で同期化処理を行うと、新たなシステムＵＩＤの生成は行わずに、パラメータの同期化を行う。
すなわち、制御装置Ｂが関与していない、制御装置Ａにおける仮想デバイスと実デバイスの対応付けの変更を、制御装置Ｂにおいても把握し、ユーザに警告確認や手動対応付けの手間をかけさせずに、交換後の実デバイスをオンライン化することができる。
なお、制御装置ＢがシステムＵＩＤを引き継ぐのは、制御装置Ｂのユーザが、制御装置Ｂを使用して、制御装置Ａが制御している又は制御していたのと同じシステムを制御しようとする場合である。
【０２０３】
次に、図２６に示す例では、制御装置Ｂが制御装置ＡからシステムＵＩＤを引き継がない場合を考える。
図２６（ａ）に示すのは、図２５（ａ）と同じ状態である。ここで、制御装置Ｂにおいて、制御装置Ａから仮想デバイステーブルを通知された際にユーザがシステムＵＩＤを引き継がない選択をすると、制御装置Ｂに記憶されている仮想デバイステーブルがそのまま残り、（ｂ）に示すように、制御装置Ｂの仮想デバイステーブルに制御装置Ａとは異なる仮想デバイスが登録された状態になり得る。もちろん、システムＵＩＤの値も制御装置Ａが記憶するものとは異なる。
【０２０４】
このとき、制御装置Ｂの仮想デバイステーブルには、「1/A/c」のように制御装置Ａ側と重複する仮想デバイスを登録しておくこともできる。
この状態で自動対応付け処理を行うと、図２１のステップＳ３０２の処理おいて、各仮想デバイスに対して線で結んだ実線の枠で示す実デバイスが対応付けられる。ここで、「1/A/c」の仮想デバイスには、制御装置ＡがユニークＩＤを設定させた「1,u1/A/c」が対応付けられることになるので、少なくともこのデバイスについては、仮想デバイスとユニークＩＤが一致しない未知デバイスとなる。他の実デバイスについては、図示のようにユニークＩＤの設定がなければ未知デバイスとなるし、過去に対応付けが行われてユニークＩＤが設定されていれば既知デバイスとなる。
【０２０５】
そして、ユーザは、その後図２２に示した手動対応付け処理により、図２１のステップＳ３０２で行われた対応付けを仮想デバイステーブルに（ＭＤの値として）登録することができる。このとき、フラグＣＦ（１）に「１」がセットされる。
その後、ユーザが制御装置Ｂにおいてオンライン移行指示を行うと、制御装置Ｂは図２３の同期化処理を実行し、実デバイスと仮想デバイスとの間でパラメータの同期化を行う。このとき、ＣＦ（１）が「１」であるので、制御装置Ｂは新たなシステムＵＩＤ（値は「ux2」とする）を生成し、仮想デバイスと対応付けた図で下から３つの実デバイスにユニークＩＤとして記憶させる。
また、制御装置Ｂは新たなシステムＵＩＤを設定した仮想デバイステーブルを制御装置Ａに通知するが、ここでは制御装置Ａも制御装置ＢのシステムＵＩＤを引き継がないものとする。
【０２０６】
なお、制御装置Ｂが制御装置ＡのシステムＵＩＤを引き継がない場合、通常は、制御装置Ｂは制御装置Ａとな異なる組み合わせのデバイスを制御対象とすることになる。ここで、制御装置ＢがシステムＵＩＤを引き継がないのは、制御装置Ｂのユーザが、制御装置Ｂを使用して、制御装置Ａが制御している又は制御していたのとは異なるシステムを制御しようとしている場合である。
【０２０７】
このような場合に、１つの実デバイスが制御装置Ｂと制御装置Ａの双方（の仮想デバイス）と同時にオンラインになると、制御に混乱が生じる恐れがあり、好ましくない。
そこで、例えば実デバイスにおいてユニークＩＤが別の値に書き換えられた時点でそれまでオンラインだった制御装置とのオンライン状態を解消するようにするとよい。このようにすれば、現在オンライン中の制御装置と異なる内容の仮想デバイステーブルに基づき別の制御装置からオンライン状態への移行（パラメータの同期化）を要求されたことを適切に把握し、後着優先で１つの制御装置とのみオンラインの状態とすることができる。
【０２０８】
このようにした場合、制御装置Ｂによる同期化処理の後は、制御装置Ａは上から３番目の実デバイスとはオフラインとなり、制御装置Ａとオンラインになっているのは、（ｃ）の「システムを構成するデバイス」の欄に太線で示すように、上２つのデバイスのみである。
また、この状態で制御装置Ａが自動対応付け処理を行うと、「1/A/c」の仮想デバイスには、制御装置ＢがユニークＩＤを設定させた「1,ux2/A/c」が対応付けられることになり、このデバイスは未知デバイスとなる。従ってこのデバイスについてステップＳ３０７での警告がなされる。従って、一旦オンラインにした実デバイスが他の制御装置によってデバイス構成の異なるシステムに組み入れられて使用された場合にも、警告を行うことができると言える。
【０２０９】
なお、制御装置Ａにおいてユーザが手動対応付けで図に示すとおりの対応付けを行った後、オンライン移行指示を行うと、制御装置Ａは、同期化処理により、上から３番目の実デバイスをオンラインにすることができる。またこのとき、制御装置Ａは新たなシステムＵＩＤ（値は「u2」とする）を生成し、仮想デバイスと対応付けた図で上から３つの実デバイスにユニークＩＤとして記憶させる。そして、上から３番目の実デバイスにも新たなユニークＩＤが記憶されることになるため、この実デバイスは制御装置Ｂとのオンライン状態を解消する。
【０２１０】
また、（ｄ）に示すように、制御装置Ａにおいて仮想デバイステーブルの内容が変更されると、変更した箇所については、自動対応付け処理において仮想デバイスに未知デバイスが対応付けられ、警告が行われることになる。
しかし、ユーザが手動対応付けで適当な対応付けを行った後、オンライン移行指示を行うと、制御装置Ａは、同期化処理により、各仮想デバイスと、その仮想デバイスと対応付けた実デバイスとをオンラインにすることができる。またこのとき、制御装置Ａは新たなシステムＵＩＤ（値は「u3」とする）を生成し、仮想デバイスと対応付けた各実デバイスにユニークＩＤとして記憶させる。
【０２１１】
４．変形例
以上で実施形態の説明を終了するが、装置の構成、データの構成、ユーザによる操作の手順、具体的な処理内容等が上述の実施形態で説明したものに限られないことはもちろんである。
例えば、上述の実施形態では、仮想デバイス及び各デバイスについてシステムＩＤを設定しておき、制御装置が現在の制御対象とするシステムを、システムＩＤにより設定する例について説明した。
【０２１２】
しかし、現在の制御対象とするシステムを、設定し得るデバイスＩＤの選択肢の中から１又は複数のデバイスＩＤを指定して設定できるようにしてもよい。ただしこの場合、全デバイス及び仮想デバイスをデバイスＩＤのみ（あるいはデバイスＩＤと機種ＩＤの組み合わせ）によって識別できるようにする必要がある。従って、仮想デバイスとシステムを構成するデバイスとの対応付けに際しては、システムＩＤは無視して（又は設定自体せず）、現在の制御対象として設定されているデバイスＩＤを有する仮想デバイスについてのみ、対応付けを行い、他の仮想デバイスについては何らのデバイスも対応付けないことになる。
【０２１３】
また、上述の実施形態では、現在の制御対象として設定されているシステムＩＤを有しない仮想デバイスについては、デバイスとの対応付けを行わない例について説明した。しかし、全仮想デバイスについて対応付けを行っておく一方、現在の制御対象として設定されていない仮想デバイスについては、オンラインにしないような制御を行ってもよい。
【０２１４】
また、優先グループの選択手法につき、図１３に示したような、仮想デバイスとの対応付けに基づくもの以外にも、任意の手法を採用可能である。例えば、マスタノードとなるデバイスは重要なデバイスであるのであまり入れ替えないが他のデバイスについては頻繁に入れ替えがある、というような場合には、マスタノードが属するグループを無条件に優先グループとする手法も考えられる。
【０２１５】
また、図２３のステップＳ３２３において、必ずしも仮想デバイステーブルの内容を全て通知しなくても、通知対象の制御装置との間で仮想デバイステーブルの内容を共通化できれば問題ない。例えば、通知対象の制御装置においてシステムＵＩＤを引き継ぐ選択がなされた時点で仮想デバイステーブルを渡してもよいし、仮想デバイステーブルにおける仮想デバイスの内容が制御装置間で一致していることが何らかの手段で保証されるなら、システムＵＩＤを通知するのみでもよい。
【０２１６】
また、各仮想デバイスに対応付けるデバイスを特定するための情報として、ＭＡＣアドレス以外の情報を用いてもよい。ユーザが行うシステムＩＤやデバイスＩＤの設定内容によらず、デバイス間で重複が起こらず、常にデータの送信先を一意に特定できるような情報であれば、その情報を用いて、仮想デバイスに対応付けるデバイスを特定することができる。デバイスのメーカーがこのようなＩＤを予めデバイスに設定しておいてもよい。
【０２１７】
また、この発明は、上述したようなリング状のフレーム伝送経路を用いるシステムだけでなく、ＣｏｂｒａＮｅｔ（商標）やＥｔｈｅｒＳｏｕｎｄ（商標）をはじめ、制御装置から他の装置に対して制御用データを送信可能な任意の形態のネットワークシステムに適用可能である。
【０２１８】
さらに、ネットワークを介して音響信号を送信可能であることも必須ではない。従って、イーサネット（商標）、無線ＬＡＮ、ＵＳＢ、ＩＥＥＥ１３９４等の任意のプロトコルによって通信を行うネットワークシステムにも適用可能である。この場合、音響信号は、制御信号の伝送に用いるネットワークとは別のネットワークや、ＭＡＤＩ（Multichannel Audio Digital Interface）等のケーブルを使用して別途伝送するようにしてもよい。
【０２１９】
さらにまた、制御装置がコンソールやＰＣであることも、制御対象のデバイスが音響信号処理装置であることも、必須ではない。
以上説明してきた変形及び実施形態の説明において述べた変形は、矛盾しない範囲で任意に組み合わせて適用可能である。また逆に、ネットワークシステムが実施形態の説明において述べた特徴を全て有している必要もない。
【産業上の利用可能性】
【０２２０】
以上の説明から明らかなように、この発明のリモート制御システムによれば、複数の制御装置により同じデバイスを制御しようとする場合でも、同じシステムを制御対象とする複数の制御装置間で共通となるシステムＵＩＤ（第２ＩＤ）に基づいて、直近の動作時に一群の制御対象として動作していたデバイスと、そうでないデバイスとを制御装置が容易に識別して、制御対象を選択できるようにすることができる。
従って、この発明を適用することにより、リモート制御システムの利便性を向上させることができる。
【符号の説明】
【０２２１】
１，Ｓ…オーディオネットワークシステム、２Ｂａ、２Ｂｃ，２Ｂｅ，２Ｂｆ，２Ｂｘ，３Ｂａ…入出力装置、２Ｃｂ…コンソール、２Ｅｄ…ミキサエンジン、１０…音響信号処理装置、１００…ＴＬフレーム
【特許請求の範囲】
【請求項１】
複数の制御装置と、該複数の制御装置により制御される複数のデバイスとを備えるリモート制御システムであって、
前記各デバイスが、
該デバイスの第１ＩＤ及び第２ＩＤを記憶する記憶手段と、
ユーザの操作に応じて前記第１ＩＤを前記記憶手段に記憶させる第１設定手段と、
前記制御装置からＩＤを受信して前記第２ＩＤとして前記記憶手段に記憶させる第２設定手段とを備え、
前記各制御装置が、
第２ＩＤを記憶する第２ＩＤ記憶手段と、
制御対象とする複数のデバイスを前記第１ＩＤによりデバイス毎に特定するデバイスデータを記憶する制御対象記憶手段と、
前記各デバイスからそれぞれ該デバイスの第１ＩＤ及び第２ＩＤを取得するＩＤ取得手段と、
前記ＩＤ取得手段が取得した第１ＩＤ及び第２ＩＤに基づき、前記制御対象記憶手段に記憶された各デバイスデータに対し、ＩＤの取得元である各デバイスのうち、該デバイスデータと前記第１ＩＤの値が共通する最大１つのデバイスを対応付ける手段であって、
ａ）前記ＩＤの取得元である各デバイスの中に、前記デバイスデータと前記第１ＩＤの値が共通であり、かつ前記第２ＩＤ記憶手段が記憶する第２ＩＤと同じ値の第２ＩＤを有するデバイスがあった場合に、該デバイスを当該デバイスデータに対応付け、
ｂ）前記ＩＤの取得元である各デバイスの中に、前記デバイスデータと前記第１ＩＤの値が共通であり、かつ前記第２ＩＤ記憶手段が記憶する第２ＩＤと異なる値の第２ＩＤを有するデバイスがあった場合に、ユーザに対して警告を行う対応付け手段と、
前記対応付け手段による対応付けができたデバイスを、制御対象のデバイスとして設定する制御対象設定手段と、
前記制御対象設定手段が設定した制御対象のデバイスを、前記第１ＩＤにより特定して制御するリモート制御手段とを備え、
前記複数の制御装置のうち特定の制御装置が、さらに
前記デバイスデータのいずれかについて、前記ＩＤの取得元である各デバイスの中に、該デバイスデータと前記第１ＩＤの値が共通であるデバイスが１以上あった場合に、ユーザの操作に応じて、該各デバイスの前記第２ＩＤの値によらず、前記１以上のデバイスのうち１つを該デバイスデータに対応付ける手動対応付け手段と、
前記制御対象設定手段による制御対象の設定に際して、制御対象とするデバイスの中に、前記手動対応付け手段による対応付けがなされたデバイスが含まれている場合、１つのユニークなＩＤを生成し、前記第２ＩＤ記憶手段に記憶している第２ＩＤを該生成したＩＤに書き換えると共に、前記制御対象設定手段が設定する制御対象の各デバイスに送信して前記第２ＩＤとして記憶させる第２ＩＤ付与手段とを備えることを特徴とするリモート制御システム。
【請求項２】
複数の制御装置と、該複数の制御装置により制御される複数のデバイスとを備えるリモート制御システムであって、
前記各デバイスが、
該デバイスの第１ＩＤ及び第２ＩＤを記憶する記憶手段と、
ユーザの操作に応じて前記第１ＩＤを前記記憶手段に記憶させる第１設定手段と、
前記制御装置からＩＤを受信して前記第２ＩＤとして前記記憶手段に記憶させる第２設定手段とを備え、
前記各制御装置が、
第２ＩＤを記憶する第２ＩＤ記憶手段と、
制御対象とする複数のデバイスを前記第１ＩＤによりデバイス毎に特定するデバイスデータを記憶する制御対象記憶手段と、
前記各デバイスからそれぞれ該デバイスの第１ＩＤ及び第２ＩＤを取得するＩＤ取得手段と、
前記ＩＤ取得手段が取得した第１ＩＤ及び第２ＩＤに基づき、前記制御対象記憶手段に記憶された各デバイスデータに対し、ＩＤの取得元である各デバイスのうち、該デバイスデータと前記第１ＩＤの値が共通する最大１つのデバイスを対応付ける手段であって、
ａ）前記ＩＤの取得元である各デバイスの中に、前記デバイスデータと前記第１ＩＤの値が共通であり、かつ前記第２ＩＤ記憶手段が記憶する第２ＩＤと同じ値の第２ＩＤを有するデバイスがあった場合に、該デバイスを当該デバイスデータに対応付け、
ｂ）前記ＩＤの取得元である各デバイスの中に、前記デバイスデータと前記第１ＩＤの値が共通であり、かつ前記第２ＩＤ記憶手段が記憶する第２ＩＤと異なる値の第２ＩＤを有するデバイスがあった場合に、ユーザに対して警告を行う対応付け手段と、
前記対応付け手段による対応付けができたデバイスを、制御対象のデバイスとして設定する制御対象設定手段と、
前記制御対象設定手段が設定した制御対象のデバイスを、前記第１ＩＤにより特定して制御するリモート制御手段とを備え、
前記複数の制御装置のうち特定の制御装置が、さらに
ユーザの操作に応じて前記制御対象記憶手段に対してデバイスデータの追加及び削除を行う制御対象編集手段と、
前記デバイスデータのいずれかについて、前記ＩＤの取得元である各デバイスの中に、該デバイスデータと前記第１ＩＤの値が共通であるデバイスが１以上あった場合に、ユーザの操作に応じて、該各デバイスの前記第２ＩＤの値によらず、前記１以上のデバイスのうち１つを該デバイスデータに対応付ける手動対応付け手段と、
前記制御対象設定手段による制御対象の設定に際して、前記制御対象編集手段によりデバイスデータの追加又は削除がなされた場合及び、制御対象とするデバイスの中に、前記手動対応付け手段による対応付けがなされたデバイスが含まれている場合に、１つのユニークなＩＤを生成し、前記第２ＩＤ記憶手段に記憶している第２ＩＤを該生成したＩＤに書き換えると共に、前記制御対象設定手段が設定する制御対象の各デバイスに送信して前記第２ＩＤとして記憶させる第２ＩＤ付与手段とを備えることを特徴とするリモート制御システム。
【請求項３】
請求項１又は２に記載のリモート制御システムであって、
前記特定の制御装置の第２ＩＤ付与手段は、前記ユニークなＩＤを生成した場合、そのＩＤを他の制御装置に通知し、
該他の制御装置は、前記第２ＩＤ記憶手段に記憶している第２ＩＤを該通知されたＩＤに書き換えると共に、前記制御対象記憶手段に記憶しているデバイスデータを、前記特定の制御装置の制御対象記憶手段が記憶しているデバイスデータに書き換えることを特徴とするリモート制御システム。
【請求項１】
複数の制御装置と、該複数の制御装置により制御される複数のデバイスとを備えるリモート制御システムであって、
前記各デバイスが、
該デバイスの第１ＩＤ及び第２ＩＤを記憶する記憶手段と、
ユーザの操作に応じて前記第１ＩＤを前記記憶手段に記憶させる第１設定手段と、
前記制御装置からＩＤを受信して前記第２ＩＤとして前記記憶手段に記憶させる第２設定手段とを備え、
前記各制御装置が、
第２ＩＤを記憶する第２ＩＤ記憶手段と、
制御対象とする複数のデバイスを前記第１ＩＤによりデバイス毎に特定するデバイスデータを記憶する制御対象記憶手段と、
前記各デバイスからそれぞれ該デバイスの第１ＩＤ及び第２ＩＤを取得するＩＤ取得手段と、
前記ＩＤ取得手段が取得した第１ＩＤ及び第２ＩＤに基づき、前記制御対象記憶手段に記憶された各デバイスデータに対し、ＩＤの取得元である各デバイスのうち、該デバイスデータと前記第１ＩＤの値が共通する最大１つのデバイスを対応付ける手段であって、
ａ）前記ＩＤの取得元である各デバイスの中に、前記デバイスデータと前記第１ＩＤの値が共通であり、かつ前記第２ＩＤ記憶手段が記憶する第２ＩＤと同じ値の第２ＩＤを有するデバイスがあった場合に、該デバイスを当該デバイスデータに対応付け、
ｂ）前記ＩＤの取得元である各デバイスの中に、前記デバイスデータと前記第１ＩＤの値が共通であり、かつ前記第２ＩＤ記憶手段が記憶する第２ＩＤと異なる値の第２ＩＤを有するデバイスがあった場合に、ユーザに対して警告を行う対応付け手段と、
前記対応付け手段による対応付けができたデバイスを、制御対象のデバイスとして設定する制御対象設定手段と、
前記制御対象設定手段が設定した制御対象のデバイスを、前記第１ＩＤにより特定して制御するリモート制御手段とを備え、
前記複数の制御装置のうち特定の制御装置が、さらに
前記デバイスデータのいずれかについて、前記ＩＤの取得元である各デバイスの中に、該デバイスデータと前記第１ＩＤの値が共通であるデバイスが１以上あった場合に、ユーザの操作に応じて、該各デバイスの前記第２ＩＤの値によらず、前記１以上のデバイスのうち１つを該デバイスデータに対応付ける手動対応付け手段と、
前記制御対象設定手段による制御対象の設定に際して、制御対象とするデバイスの中に、前記手動対応付け手段による対応付けがなされたデバイスが含まれている場合、１つのユニークなＩＤを生成し、前記第２ＩＤ記憶手段に記憶している第２ＩＤを該生成したＩＤに書き換えると共に、前記制御対象設定手段が設定する制御対象の各デバイスに送信して前記第２ＩＤとして記憶させる第２ＩＤ付与手段とを備えることを特徴とするリモート制御システム。
【請求項２】
複数の制御装置と、該複数の制御装置により制御される複数のデバイスとを備えるリモート制御システムであって、
前記各デバイスが、
該デバイスの第１ＩＤ及び第２ＩＤを記憶する記憶手段と、
ユーザの操作に応じて前記第１ＩＤを前記記憶手段に記憶させる第１設定手段と、
前記制御装置からＩＤを受信して前記第２ＩＤとして前記記憶手段に記憶させる第２設定手段とを備え、
前記各制御装置が、
第２ＩＤを記憶する第２ＩＤ記憶手段と、
制御対象とする複数のデバイスを前記第１ＩＤによりデバイス毎に特定するデバイスデータを記憶する制御対象記憶手段と、
前記各デバイスからそれぞれ該デバイスの第１ＩＤ及び第２ＩＤを取得するＩＤ取得手段と、
前記ＩＤ取得手段が取得した第１ＩＤ及び第２ＩＤに基づき、前記制御対象記憶手段に記憶された各デバイスデータに対し、ＩＤの取得元である各デバイスのうち、該デバイスデータと前記第１ＩＤの値が共通する最大１つのデバイスを対応付ける手段であって、
ａ）前記ＩＤの取得元である各デバイスの中に、前記デバイスデータと前記第１ＩＤの値が共通であり、かつ前記第２ＩＤ記憶手段が記憶する第２ＩＤと同じ値の第２ＩＤを有するデバイスがあった場合に、該デバイスを当該デバイスデータに対応付け、
ｂ）前記ＩＤの取得元である各デバイスの中に、前記デバイスデータと前記第１ＩＤの値が共通であり、かつ前記第２ＩＤ記憶手段が記憶する第２ＩＤと異なる値の第２ＩＤを有するデバイスがあった場合に、ユーザに対して警告を行う対応付け手段と、
前記対応付け手段による対応付けができたデバイスを、制御対象のデバイスとして設定する制御対象設定手段と、
前記制御対象設定手段が設定した制御対象のデバイスを、前記第１ＩＤにより特定して制御するリモート制御手段とを備え、
前記複数の制御装置のうち特定の制御装置が、さらに
ユーザの操作に応じて前記制御対象記憶手段に対してデバイスデータの追加及び削除を行う制御対象編集手段と、
前記デバイスデータのいずれかについて、前記ＩＤの取得元である各デバイスの中に、該デバイスデータと前記第１ＩＤの値が共通であるデバイスが１以上あった場合に、ユーザの操作に応じて、該各デバイスの前記第２ＩＤの値によらず、前記１以上のデバイスのうち１つを該デバイスデータに対応付ける手動対応付け手段と、
前記制御対象設定手段による制御対象の設定に際して、前記制御対象編集手段によりデバイスデータの追加又は削除がなされた場合及び、制御対象とするデバイスの中に、前記手動対応付け手段による対応付けがなされたデバイスが含まれている場合に、１つのユニークなＩＤを生成し、前記第２ＩＤ記憶手段に記憶している第２ＩＤを該生成したＩＤに書き換えると共に、前記制御対象設定手段が設定する制御対象の各デバイスに送信して前記第２ＩＤとして記憶させる第２ＩＤ付与手段とを備えることを特徴とするリモート制御システム。
【請求項３】
請求項１又は２に記載のリモート制御システムであって、
前記特定の制御装置の第２ＩＤ付与手段は、前記ユニークなＩＤを生成した場合、そのＩＤを他の制御装置に通知し、
該他の制御装置は、前記第２ＩＤ記憶手段に記憶している第２ＩＤを該通知されたＩＤに書き換えると共に、前記制御対象記憶手段に記憶しているデバイスデータを、前記特定の制御装置の制御対象記憶手段が記憶しているデバイスデータに書き換えることを特徴とするリモート制御システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【公開番号】特開２０１１−１８２３２９（Ｐ２０１１−１８２３２９Ａ）
【公開日】平成２３年９月１５日（２０１１．９．１５）
【国際特許分類】
【出願番号】特願２０１０−４６８７５（Ｐ２０１０−４６８７５）
【出願日】平成２２年３月３日（２０１０．３．３）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
【公開日】平成２３年９月１５日（２０１１．９．１５）
【国際特許分類】
【出願日】平成２２年３月３日（２０１０．３．３）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
[ Back to top ]