JP2006135982A

JP2006135982A - ネットワーク接続装置、映像情報機器、情報送受信機器、及びネットワーク接続プログラム

Info

Publication number: JP2006135982A
Application number: JP2005319468A
Authority: JP
Inventors: Kyosuke Yoshimoto; 恭輔吉本; Atsumichi Murakami; 篤道村上; Tomohiro Morita; 知宏森田; Yoshiki Mizutani; 芳樹水谷; Kazuo Hirasawa; 和夫平澤; Yasuo Maeda; 泰雄前田; Mitsunobu Yoshinaga; 光伸吉永; Kozo Ishida; 晃三石田
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2003-04-24
Filing date: 2005-11-02
Publication date: 2006-05-25

Abstract

【課題】２つのネットワークを接続し、互いのネットワークに接続されている機器間での通信を可能とする。
【解決手段】ネットワーク接続装置は、第１のネットワークに接続され、前記第１のネットワークに接続される機器と通信を行う第一の通信手段と、第２のネットワークに接続され、前記第２のネットワークに接続される機器と通信を行う第二の通信手段と、前記第１のネットワークにおける識別子を出力する識別子管理手段とを備え、前記第２のネットワークに接続されている機器に対応するプログラムを起動し、前記プログラムと前記識別子とを対応付ける。
【選択図】図２３

Description

この発明は、小規模ネットワークのＬＡＮから大規模ネットワークのインターネットに接続することが可能であり、また、デジタルテレビ、ＤＶＤ／ＨＤＤレコーダなどの民生用機器や監視システムのレコーダ、ＦＡ機器など業務用機器まで幅広い機種、システムに取り付けることが可能で、かつ、操作性に優れたユビキタス（ｕｂｉｑｕｉｔｏｕｓ）映像モジュールと該ユビキタス映像モジュールをコア（中核）に形成されたユビキタス映像モジュールユニットと、該ユビキタス映像モジュールユニットを装備することが可能な映像情報装置、映像記録装置、携帯電話装置等の映像機器に関するものである。

従来のＡＶ（ＡｕｄｉｏＶｉｓｕａｌ）デジタルネットワーク機器は、例えば、特許文献１に示されているように、ひとつの機器内にネットワーク接続のためのインターフェースとネットワークへ接続するための機能を構成している。

また、例えば、特許文献２に示されているように、システムＬＳＩにてネットワークに関する機能を実現しているものもある。

近年、パーソナルコンピュータの低価格化・高機能化、インターネットコンテンツの増加、携帯電話・ＰＤＡ（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ：電子手帳）等のネットワーク接続機器の多様化などにより、一般家庭においてもローカルＬＡＮやインターネットを利用する機会が増大している。

また、ＨＡＶｉ（ＨｏｍｅＡｕｄｉｏ／Ｖｉｄｅｏｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ：家庭用ＡＶ機器をネットワーク化する時に使用されるソフトウェアの仕様のこと）、ＥＣＨＯＮＥＴなど、規格面においても家電機器をネットワークに接続するための整備が進められている。

特許文献１に示されたデジタルネットワーク機器のテレビ、ＶＴＲなどの映像情報装置は、一般的に第４４図に示されるような専用のシステムＬＳＩ（システムＬＳＩ２０８）を開発して用いられている。

システムＬＳＩ２０８は、システムの制御を行うためのＳＹＳ−ＣＰＵ２０１と、映像信号処理を行う映像信号処理部ＶＳＰ（ＶｉｄｅｏＳｉｇｎａｌＰｒｏｃｅｓｓｏｒ）２０２の論理部（以降、「ロジック部」（Ｌｏｇｉｃ）と記す。）と、ＲＯＭ２０３およびＲＡＭ２０４のメモリー部とで構成されている。

映像信号処理部ＶＳＰ２０２のロジック部は、このシステムＬＳＩを使用する映像情報装置の仕様に応じて、必要な機能が設計されている。

この機能が汎用的でメーカのインテレクチャル・プロパティ（ＩｎｔｅｌｌｅｃｔｕａｌＰｒｏｐｅｒｔｙ）が存在するなどの場合は、このインテレクチャル・プロパティを用いることにより、開発期間の短縮化ならびにコスト低減を図っている。

なお、インテレクチャル・プロパティとは、ＬＳＩ設計の場合において、既に設計されている論理回路のことを意味する。

第４４図は、システムＬＳＩ２０８を用いた従来の映像処理装置の一例を概念的に示すブロック図である。

映像入力信号２０５は、映像情報装置２０６において、表示ユニット２１１で表示可能な信号まで変換されて出力する。

映像信号装置２０６は、システムＬＳＩ２０８、システムＬＳＩの前段処理部（ＦｒｏｎｔｅｎｄＰｒｏｃｅｓｓｏｒ。以降、「ＦＰ」と記す。）２０７、システムＬＳＩ２０８の後段処理部（ＢａｃｋｅｎｄＰｒｏｃｅｓｓｏｒ。以降、「ＢＰ」と記す。）２０９およびビデオインターフェース（以降、「Ｖ−Ｉ／Ｆ」と記す。）２１０とで構成される。

ここで、映像入力信号２０５がアナログ信号の場合、ＦＰ１０７はＡ／Ｄ変換や汎用的なデコーダ（Ｄｅｃｏｄｅｒ）などの機能を有する。また、ＢＰ２０９は、出力バッファのみの機能を有する構成をしている。

ただし、システムＬＳＩ２０８の設計思想やシステムの構成によりＦＰ、ＢＰはさまざまな構成が可能である。

また、特許文献２に記載のネットワーク接続の半導体料金収集では、機器内にネットワーク機器制御部をもつことにより、ネットワーク接続が可能な構成を実現している。

さらに、第４５図は、システムＬＳＩ２１８を用いた従来の携帯電話装置の一例を概念的に示すシステム構成図である。図において、図示しない携帯電話の無線網からアンテナ２１８を介して入力されたデータは、ベースバンド部２１７により信号処理され、通信ヘッダ情報が取り除かれ、再構築される。さらにモバイル・アプリケーション・ユニット２１９で、表示ユニット２１１に表示可能な信号形態にまで変換され表示ユニット２１１へ出力される。無論、音声の入出力に関する構成ブロックもあるがここでは図示を省略し、以下の説明も映像情報の処理を主に説明する。

モバイル・アプリケーション・ユニット２１９は、システムＬＳＩ２０８と、システムＬＳＩ２０８のＦＰ２０７と、ＢＰ２０９と、Ｖ−Ｉ／Ｆ２１０で構成される。

モバイル・アプリケーション・ユニット２１９に入力されたデータは、ＣＰＵ２０１のソフトウェア、ＶＳＰ２０２のハードウェアにより、デコード、リサイズ等され、表示ユニット２１１にて表示される。

また、外部に接続されたカメラ・ユニット２１５からモバイル・アプリケーション・ユニット２１９に入力されたデータは、カメラ・エンジン２１６にてデータ処理され、ＣＰＵ２０１、ＶＳＰ２０２にて画像データとして再構築され、さらに表示ユニット２１１にて表示される場合や、さらに圧縮処理されフラッシュメモリ等の不揮発メモリに保存される場合や、さらに多重化処理され、ベースバンド部２１７より図示しない無線網へ送信される場合がある。

従来の映像情報機器設計においては、映像情報機器に対し新規にネットワーク機能を追加するような場合、新しい仕様に応じてシステムＬＳＩに機能を追加したり、新たなシステムＬＳＩを開発し、信頼性検証、ＥＭＩ（ＥｌｅｃｔｒｏＭａｇｎｅｔｉｃＩｎｔｅｒｆｅｒｅｎｃｅ：電磁波妨害）検証等を行っている。

このため、機器の仕様を変更する度に、開発費ならびに開発期間がかかっていた。

また、仕様を変更しない場合、陳腐化したシステムＬＳＩを搭載した機種では、ビジネスチャンスを逃してしまう可能性がある。

また、新規製品投入のサイクルが短く、機種の数が膨大となっている携帯電話の分野では、機種ごとの搭載機能が異なっており、使用要求を満足する専門のシステムＬＳＩの開発変更のたびに、機種ごとに搭載機能が異なっている。したがって、要求仕様を満足する専用のシステムＬＳＩの開発／変更のたびに、携帯電話装置のプリント基盤変更・ソフト変更、信頼性検証、ＥＭＩ検証など、携帯電話装置全体の新規開発と変わらぬ作業を繰り返す必要があり、やはり、開発費用が高額化し、開発期間が長期化してしまうという課題があった。

特開２００２−１６６１９号公報（図１、段落０００９）特開２００２−２３０４２９号公報（図２、段落００２８〜段落００３２）

本発明は、上述のような課題を解決する為になされたもので、機器に要求される仕様・機能が変わっても、仕様・機能変更の要求に対応したシステムＬＳＩを新たに開発する必要がなく、容易に機能の拡張・変更が可能な映像機器を提供することを目的とする。

本発明のネットワーク接続装置は、
第１のネットワークに接続され、前記第１のネットワークに接続される機器と通信を行う第一の通信手段と、
第２のネットワークに接続され、前記第２のネットワークに接続される機器と通信を行う第二の通信手段と、
前記第１のネットワークにおける識別子を出力する識別子管理手段と
を備え、
前記第２のネットワークに接続されている機器に対応するプログラムを起動し、前記プログラムと前記識別子とを対応付けること
としたものである。

本発明のネットワーク接続装置によれば、新たなＬＳＩを搭載した機器を用いることなく、第１のネットワーク上にある機器と第２のネットワーク上にある機器との通信が可能となる。

以下、本発明を図示した実施形態に基づいて説明する。

実施の形態１．
第１図は、第１の実施の形態によるユビキタス（Ｕｂｉｑｕｉｔｏｕｓ）映像モジュール（以降、「ＵＭ」と記す。）を用いた映像情報装置のネットワーク系統図を示すものである。

ネットワーク１は、小規模のＬＡＮ、大規模のインターネットを含むネットワークであって、様々な種類のパーソナルコンピュータサーバやパーソナルコンピュータクライアントが接続されている。

ＰＣ２はネットワーク１に接続されたパーソナルコンピュータであり、メールの送受信、ホームページの開発・閲覧など様々なサービス・用途で用いられている。

データベース３は、映像配信のストリーミングデータ、映像・音楽データの保管、ＦａｃｔｏｒｙＡｕｔｏｍａｔｉｏｎ（以降、「ＦＡ」と記す。）の管理データ、監視カメラの監視画面などが保管されている。

デジタルＴＶ６はデジタル入力の映像コンテンツを表示するための表示装置、ＤＶＤ／ＨＤＤレコーダ７はＤＶＤやＨＤＤなどの大容量のストレージに映像・音楽データを保存・再生するためのレコーダ、監視レコーダ８はエレベータや店内の状況等をカメラにて撮影して保管するためのレコーダ、ＦＡ９は工場内のＦＡ機器、携帯電話１０は単独でネットワーク接続が出来ない携帯電話、ＰＤＡ１１は個人用情報端末を示している。

このように、ネットワーク１へ接続する可能性のある機器は多種多様であり、ユビキタス映像モジュールユニット（以降、「ＵＭＵ」と記す。）４を各機器に取り付けることにより、ネットワーク１への接続が可能となる。すなわち、以下で説明するＵＭＵは、多種の機器間にあるハードウェア、ソフトウェア等の違いを機器とネットワークとの間に介在させることにより吸収し、この接続されたＵＭＵの持つ機能を使用することにより、仮想的に新たな機能を有する映像情報装置とするものである。

第２図は、ＵＭＵ４を構成する重要な要素のＵＭの構成を示した図である。

図中、ＵＭ１２は、ＵＭ内の後述する各ハードウェアエンジンを制御するためのコンピュータであるＵＭ用ＣＰＵ（以降、「ＵＭ−ＣＰＵ」と記す。）１３、ＵＭ−ＣＰＵ１３と各ハードウェアエンジンとを接続するためのローカルバス（内部ＢＵＳ）１４、外部の映像情報装置と接続するための汎用バス（ＵＭ−ＢＵＳ）１６、ローカルバス（内部ＢＵＳ）１４と汎用バス（ＵＭ−ＢＵＳ）１６を接続するバスブリッジ１５、ネットワークの映像処理で必要な各種の機能をハードウェアにて実現するための複数のハードウェアエンジン（ハードウェアエンジン１、・・・、Ｎ）１７にて構成される。

ここで、ハードウェアエンジン１７からは、例えば、ネットワークに接続するための有線ＬＡＮ、無線ＬＡＮ、シリアルバス接続などのためのバスライン（専用バス）１８を設けることも可能である。

各ハードウェアエンジン（ハードウェアエンジン１、・・・、Ｎ）は、映像情報ネットワークに関する機能を補充するためのエンジンであり、例えば、第３図に示すような、ネットワーク環境に接続するための有線ＬＡＮ、無線ＬＡＮ、シリアルバスとの通信を行うためのコミュニケーションエンジン２４、描画性能を向上するためのグラフィクエンジン２１、動画や静止画など撮像信号処理を行うカメラエンジン２２、動画圧縮のためのＭＰＥＧ４エンジン２３などの機能がある。すなわち、各ハードウェアエンジンは、ＵＭＵ４を装着することによって、映像情報装置には本来存在しない機能を追加・補充することを可能とするエンジンである。

なお、ここであげている例は一例であり、ネットワークを形成するために必要な機能を、本エンジンにて形成することが可能である。

また、ＤＭＡ（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）コントローラなどのメモリー制御機能も実現可能である。

第３図に示すように、本実施の形態によるＵＭ１２は、分散実行機能をサポートするＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）である組込みＬｉｎｕｘ２７、ミドルウェア２５、仮想マシン（ＶｉｒｔｕａｌＭａｃｈｉｎｅ。以降、「ＶＭ」と記す。）２６、アプリケーションソフトなどを含んでおり、ＵＭ単体でネットワークに関する機能を実現できる。

つまり、本実施の形態によるＵＭ１２は、ネットワークに関するホストコンピュータの機能を実現できるモジュールである。

なお、ここで用いられるＶＭ２６は、例えば、ＪＡＶＡ（登録商標）ＶＭのことである。

第４図ならびに第５図は、映像情報装置にＵＭを接続するためのトポロジー（ｔｏｐｏｌｏｇｙ）を示している。

システムＣＰＵ（以降、「ＳＹＳ−ＣＰＵ」と記す。）２０１とＵＭ−ＣＰＵ１３は、バス形式の接続やＨＵＢ３５を介したスター形式の接続が可能である。

以下にそれぞれの詳細な説明を加える。
第４図はバス形式の接続トポロジーであり、ＳＹＳ−ＣＰＵ２０１とＵＭ−ＣＰＵ１３は、ＵＭ−ＢＵＳ１６にバス型に接続されている。

また、ＳＹＳ−ＣＰＵ２０１は、映像情報装置のシステムの制御をつかさどるホストサーバの機能を、ＵＭ−ＣＰＵ１３はネットワークサーバの機能を実現するものである。

ここで、重要なことは、映像情報装置は、ＳＹＳ−ＣＰＵ２０１で、問題なく製品仕様を満足する動作をする点である。

ＵＭ１２のＵＭ−ＣＰＵ１３は、システム側インターフェース（以降、「Ｓ−Ｉ／Ｆ」と記す。）３１とＵＭ側インターフェース(以降、「Ｕ−Ｉ／Ｆ」と記す。)３２とにより機械的に接続することが可能である。

映像情報装置に高性能・高付加価値のネットワーク機能を付加したい状況においては、Ｓ−Ｉ／Ｆ３１ならびにＵ−Ｉ／Ｆ３２を介してＵＭＵ１２を接続する。

これにより、例えば、ＬＡＮ上の他の装置のネットワーク端末３４にアクセスするなどのネットワーク機能が実現できる。

すなわち、映像情報装置自体にはなかった、より高性能・高付加価値のネットワーク機能を付加したい場合は、Ｓ−Ｉ／Ｆ３１ならびにＵ−Ｉ／Ｆ３２を介してＵＭ４を接続することにより、例えばＬＡＮ３３上のネットワーク端末３４にアクセスする等のネットワーク機能が実現できる。

このような機能の拡張は、映像情報装置のシステムを制御するＳＹＳ−ＣＰＵ２０１を、ＵＭ１２内のＵＭ−ＣＰＵが制御することにより可能となる。

なお、汎用バスのＵＭ−ＢＵＳ上には、ホスト機能を有さないデバイス(メモリー、専用機能のＩＣ)の接続が可能であり、また、接続しない構成も可能である。

第５図はスター型の場合の配置を示しており、ＨＵＢ３５を介してＵＭ−ＣＰＵ１３が接続している構成が異なるのみで、その他の機能は、バス型の場合と同様である。

また、本構成の接続形態は、リング型についても問題なく対応することが可能となる。
ここで、Ｓ−Ｉ／Ｆ３１とＵ−Ｉ／Ｆ３２の接続は、ＡＴＡ（ＡＴＡｔｔａｃｈｍｅｎｔ：ハードディスク装置用インターフェースの１つ）、ＰＣＩ（Ｐｅｒｉ−ｐｈｅｒａｌＣｏｍｐｏｎｅｎｔＩｎｔｅｒｃｏｎｎｅｃｔ：パソコンやワークステーションに使う入出力バスの１つ）、ＳＣＳＩ（ＳｍａｌｌＣｏｍｐｕｔｅｒＳｙｓｔｅｍＩｎｔｅｒｆａｃｅ：パソコンやワークステーションに使う入出力インターフェースの規格）、ＰＣＭＣＩＡ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒＭｅｍｏｒｙＣａｒｄＩｎｔｅｒｎａｔｉｎａｌＡｓｓｏｃｉａｔｉｏｎ）、汎用ＣＰＵＢＵＳ等のパラレル転送の構成や、ＩＥＥＥ１３９４、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ：パソコンのキーボードなどの周辺装置用シリアルインターフェース）、ＵＡＲＴ（ＵｎｉｖｅｒｓａｌＡｓｙｎｃｈｒｏｎｏｕｓＲｅｃｅｉｖｅｒ−Ｔｒａｎｓｃｅｉｖｅｒ）などのシリアル転送の構成も可能である。

また、映像情報装置とＵＭの接続方法は、ＰＣカードやカードＢＵＳで使用されているコネクタ接続や、ＰＣＩバス接続などで使用されるカードエッジコネクタ接続や、ＦＰＣケーブル、フラットケーブル、ＩＥＥＥ１３９４用ケーブルなどのケーブル接続などの方法を用いることが可能である。

第６図は、本実施の形態によるＵＭＵ４２を映像情報装置４０に接続した場合の全体の構成例である。

映像情報装置４０は、第４４図に示した従来の映像情報装置２０６にＳ−Ｉ／Ｆ３１を追加した構成をしている。

また、ＵＭＵ４２は、第２図あるいは第３図に示したＵＭ１２にＵ−Ｉ／Ｆ３２を追加した構成をしている。

それぞれのインターフェースＳ−Ｉ／Ｆ３１とＵ−Ｉ／Ｆ３２を接続することにより、ＵＭの機能が付加された映像情報装置４０が実現できる。

ＵＭＵ４２は、コミュニケーションエンジン２４にて、インターネット環境に接続した後、インターネット上のサイトから画像・音声のＭＰＥＧ４ファイルをダウンロードする。

ダウンロードされたＭＰＥＧ４ファイルは、ＭＰＥＧ４エンジン２３でデコードされ、グラフィックエンジン２１でグラフィック処理され、ＵＭＵのインターフェースＵ−Ｉ／Ｆ３２を経由して映像情報装置４０で利用可能なデータ形式で出力される。

映像情報装置４０に入力されたデータは、表示ユニット２１１に表示可能な状態に信号処理され、表示ユニット２１１上に表示される。

また、カメラから入力された動画・静止画ファイルをＵＭＵ４２のカメラエンジン２２にて画素数変換、レート変換、画像処理を実施し、グラフィクエンジン２１でグラフィック処理されＵＭＵ４２のインターフェースＵ−Ｉ／Ｆ３２経由で映像情報装置４０に利用可能なデータ形式で出力される。

なお、以上の各エンジンの処理は、一例を示したものであって、エンジンの使用手順ならびにエンジンの機能については、ネットワーク機能を補強する機能であれば、本システムで実現可能である。

映像情報装置ならびにＵＭＵの構成において、主に映像データ表示するためのシステムについて説明を行っているが、同様の構成で、音声入力の再生装置・テキスト入力の表示・配信装置、情報のストレージ入力のストレージ装置にも適応することが可能である。

第７図は、ＵＭＵ４２に表示ユニット２１１へ映像を表示するための機能を付加した場合の構成の一例を示す。

ＵＶＩ４４はＵＭＵ４２のビデオ（映像）入力端子であり、映像情報装置４０の映像出力端子であるＶ−Ｉ／Ｆ２１０と接続可能なインターフェースを形成している。

ＵＶＯ４５は、ハードウェアエンジンの表示エンジンの映像出力信号端子であり、表示ユニット２１１の入力インターフェースと接続される。

例えば、映像情報装置４０の映像出力をＵＭ１２のグラフィックエンジン２１の表示画面上にオーバーレイ（ｏｖｅｒｌａｙ）することが可能である。

また、映像信号をＳ−Ｉ／Ｆ３１とＵ−Ｉ／Ｆ３２の汎用バスを使い転送する構成も可能ではあるが、本実施の形態の構成を用いることにより、汎用バスの転送効率を下げることなく、映像信号をＵＭへ供給することが可能となる。

さらに、映像情報装置４０がネットワーク対応ではない場合、インターネット上のグラフィックデータを映像信号とオーバーレイして出力する構成は困難であるが、ＵＭはあらかじめ、ネットワークの必須機能としてオーバーレイの機能を搭載するため、システムＬＳＩの新たな開発を行うことなく、映像情報装置の機能拡張が容易に実現できる。

第８図は、ＵＭＵ４２のコミュニケーションエンジン２４に外部ネットワーク接続用の端子を付加した場合の構成例を示している。

各ハードウェアエンジンに対応させて、有線ＬＡＮ用外部接続端子４６、無線ＬＡＮ用外部接続端子４７、外部接続用のシリアルバス４８を配置することにより、ＵＭＵ４２は、有線ＬＡＮ経由、無線ＬＡＮ経由、あるいは、ＩＥＥＥ１３９４などのシリアルバス経由でネットワーク接続が可能となる。

なお、ＵＭＵ４２は、上述のすべての端子を持つよう構成することも可能であるし、一つのみの端子を持つ構成も可能であり、ネットワークや製品に応じてフレキシブルに対応することが出来る。

第９図は、本実施の形態によるＵＭ１２を監視レコーダ８のシステムに適応した場合の構成例である。

図中、監視レコーダ８は監視レコーダとしての基本的なブロックを構成しており、カメラとのＩ／Ｆやその他の映像出力を持つ機器との映像信号の送受信を行うＭｕｌｔｉｐｌｅＶｉｄｅｏＩ／Ｏ５１と、ＪＰＥＧ／ＪＰＥＧ２０００などの圧縮・伸張を行うＪＰＥＧ／ＪＰＥＧ２０００Ｃｏｄｅｃ５２と、ＨＤＤ／ＤＶＤなどマスストレージ装置をドライブするＭａｓｓＳｔｏｒａｇｅドライバ５３と、監視レコーダの制御を行うＣｏｒｅコントローラ部５４と、ＯＳとして、ＵＭ−ＣＰＵ１３と同じＯＳである組込みＬｉｎｕｘ５５を搭載する構成である。

監視レコーダ８のＭｕｌｔｉｐｌｅＶｉｄｅｏＩ／Ｏ５１の機能を用いてカメラモジュールの信号処理を実現することにより、ＵＭ−ＣＰＵ１３のカメラエンジン部の機能を使用する場合は、ＵＭ−ＣＰＵ１３の機能を用いないことも可能であり、映像情報装置４０の仕様にあわせてユビキタス映像モジュールのエンジンを選択に切替える機能を有する。

また、第１０図のような構成とすることも可能である。すなわち、監視レコーダ８はＨＤＤ／ＤＶＤ５６などのマスストレージ装置のインターフェースを制御するＳｔｒａｇｅホストインターフェイス５９を備え、ユビキタス映像モジュール１２、ＨＤＤ／ＤＶＤ５６はストレージインターフェースを行うＳｔｒａｇｅデバイスコントローラ５７を有して、監視レコーダ８のＳｔｒａｇｅホストインターフェイス５９と接続されている。

さらに、第１１図は、ＵＭ１２をＤＶＤ／ＨＤＤレコーダ７のシステムに適応した場合の構成例である。図中ＤＶＤ／ＨＤＤレコーダ７は、ＤＶＤレコーダの基本的なブロックを構成しており、映像出力を持つ機器との映像信号の送受信を行うＭｕｌｔｉｐｌｅＶｉｄｅｏＩ／Ｏ６１と、ＭＰＥＧ２などの圧縮・伸張を行うＭＰＥＧ２Ｃｏｄｅｃ６２と、ＤＶＤなどストレージ装置のインターフェースを制御するＳｔａｒｇｅホストインターフェイス６５と、ＤＶＤレコーダの制御を行うＣｏｒｅコントローラ６３と、ＯＳとして、ＵＭ−ＣＰＵ１３と同じ組込みＬｉｎｕｘ６４を搭載する構成である。

これまでに、ＤＴＶ５などのような映像情報装置、ＤＶＤ／ＨＤＤレコーダ７の映像記録装置や、監視レコーダ８の監視装置に適応した事例について述べてきたが、同様の構成にて、ＦＡ９、携帯電話１０、ＰＤＡ１１についても適応可能である。

以上の説明では、映像情報装置とＵＭで同一のＯＳを用いた場合について述べているが、構成上は異なるものでも可能である。

ただし、同一のＯＳを用いることにより、ＵＭで採用されているハードウェアエンジンの機能が陳腐化した場合は、映像情報装置内に必須機能として取り込む時、ＯＳが共通であるためソフトの改定作業が容易にでき、改定のための開発費が少なく、信頼性などの面でバグ（ｂｕｇ：プログラムの欠陥）が入りにくいなどの開発面での優位性がある。

第１２図は、実施の形態１によるＵＭのソフトウェアブロック構成図である。

図に示すように、最下層はマイコン（ＣＰＵ）を含めたハードウェア層１００である。
このハードウェア層１００の上位に、ハードウェアを抽象化することにより、ハードウェアごとの違いを吸収するためのソフトウェアであるＨａｒｄｗａｒｅＡｄａｐｔａｔｉｏｎＬａｙｅｒ（以降、「ＨＡＬ」と記す。）１０１を配置する。

ＨＡＬ１０１の上位には、マルチタスクオペレーティングシステムである組込みＬｉｎｕｘ１０２を配置する。

このように、ＨＡＬ１０１はハードウェア層１００と組込みＬｉｎｕｘ１０２との間に配置されるが、ＨＡＬ１０１はハードウェア層１００と組込みＬｉｎｕｘ１０２とのインターフェースの役割を果たしていることになる。したがって、このＨＡＬ１０１は大きな意味で、ハードウェア層１００、または組込みＬｉｎｕｘ１０２の一部として捉えることができる。

組込みマルチタスクオペレーティングシステムである組込みＬｉｎｕｘ１０２は、ＨＡＬ１０１に属するソフトウェアを介して、ハードウェア層１００の構成要素である各ハードウェアデバイスを制御する他、アプリケーションの実行環境を提供する。

また、組込みＬｉｎｕｘ１０２上で動作するグラフィックシステムとしては、Ｘ−Ｗｉｎｄｏｗ（登録商標）１０３が使用される。

オペレーティングシステムＬｉｎｕｘ１０２上で動作するミドルウェアとして、大別して４つのミドルウェアを配置する。

第１は、インターネットと接続するための通信処理を行うためのものであり、次世代のインターネットプロトコルであるＩＰｖ６のプロトコルにも対応しているＩＰｖ６対応インターネット通信プロトコルミドルウェア１０４である。

第２は、当該機器をネットワークに接続する際に、自動的に設定を行うためのもので、ユニバーサルプラグアンドプレイ（ＵｎｉｖｅｒｓａｌＰｌｕｇａｎｄＰｌａｙ。以降、「ＵＰｎＰ」と記す。）ミドルウェア１０５である。

ＵＰｎＰミドルウェア１０５は、ＩＰｖ６対応インターネット通信プロトコルミドルウェア１０４に属するプロトコルを使用するために階層的にＩＰｖ６対応インターネット通信プロトコルミドルウェア１０４の上に属する。

第３は、マルチメディアのための規格であるＭＰＥＧ２／４に対応したエンコード／デコード処理、ＭＰＥＧ７に対応したデータ処理、ＭＰＥＧ２１に対応したコンテンツ管理処理の組み合わせによってマルチメディアデータの配信、蓄積等の処理を行うためのもので、ＭＰＥＧｘ映像配信蓄積プロトコルミドルウェア１０６である。

第４は、カメラの制御および２次元／３次元のグラフィック処理を行うためのもので、撮像アンド表示（グラフィック）ミドルウェア１０７である。

前述のミドルウェア群の内、ＵＰｎＰミドルウェア１０５とＭＰＥＧｘ映像配信蓄積プロトコルミドルウェア１０６の上位にＪＡＶＡ（登録商標）のアプリケーション実行環境であるＪＡＶＡ（登録商標）ＶＭ１０８を配置し、ＪＡＶＡ（登録商標）ＶＭ１０８上に、ユーザーインターフェースを含んだアプリケーションの作成を容易にするためのＵＩアプリケーションフレームワーク１０９を配置する。

ＵＩアプリケーションフレームワーク１０９は、例えば、ＪＡＶＡ（登録商標）ＶＭ１０８上で動作するクラスの集合などである。

最上位には、ＵＩアプリケーションフレームワーク１０９や撮像アンド表示（グラフィック）ミドルウェア１０７を用いて、当該ユビキタス映像モジュールを搭載する機種ごとに必要な機能を実現するための機種別アプリケーション１１０を配置する。

第１３図は、機種ごとにユビキタス映像モジュールを適用する場合のソフトウェアブロック図である。

図に示すように、最上位のアプリケーション層とハードウェア層の上位に位置するＨＡＬのみを機種ごとに変更し、その他の層は共通化して使用することにより、異なる機種に対応する機能を実現することができる。

この図では、ユビキタス映像モジュールを携帯電話に適用する場合には、携帯ＨＡＬ１２０と携帯Ａｐｐｌｉｃａｔｉｏｎ（以降、「ＡＰＰ」と記す。）１２５を組み合わせることを示している。

同様に、車載用電話に適用するためにはカー携帯ＨＡＬ１２１とカー携帯ＡＰＰ１２６を組み合わせ、カーナビゲーションシステムに適用するためにはカーナビＨＡＬ１２２とカーナビＡＰＰ１２７を組み合わせ、ＡＶ家電機器に適用するためにはＡＶ家電ＨＡＬ１２３とＡＶ家電ＡＰＰ１２８を組み合わせ、監視システム機器に適用するためには監視ＨＡＬ１２４と監視ＡＰＰ１２９を組み合わせる。

第１４図は、ＩＰｖ６対応インターネット通信プロトコルミドルウェア１０４のソフトウェアブロック構成を示した図である。

図においては、通信用のインターフェースとして、１０ＢＡＳＥ−Ｔや１００ＢＡＳＥ−ＴＸから成るイーサネット（登録商標）（Ｅｔｈｅｒｎｅｔ（登録商標））、ＩＥＥＥ８０２．１１ａ／ｂ／ｇから成る無線ＬＡＮ、ＩＥＥＥ１３９４などの高速シリアル通信の３種類を含んでいる。

それぞれのハードウェアを制御するためのデバイスドライバソフトウェアとして、イーサネット（登録商標）ドライバ１３１、無線ＬＡＮドライバ１３２、ＩＥＥＥ１３９４ドライバ１３３を配置する。

イーサネット（登録商標）ドライバ１３１および無線ＬＡＮドライバ１３２の上位層として、インターネットプロトコルの処理を行うＩＰプロトコルスタック（ＩＰ）１３７を配置する。

このＩＰスタック１３７は、次世代のインターネットプロトコルであるＩＰｖ６に対応するための処理と、セキュリティのためのプロトコルＩＰｓｅｃに対応するための処理を含む。

ＩＥＥＥ１３９４ドライバ１３３の上位層としては、ＩＥＥＥ１３９４のトランザクション（Ｔｒａｎｓａｃｔｉｏｎ）処理を行うためのＩＥＥＥ１３９４トランザクションスタック１３５を配置する。

また、ＩＥＥＥ１３９４のトランザクションを無線ＬＡＮ経由で実行できるようにするために、無線ＬＡＮドライバ１３２とＩＥＥＥ１３９４トランザクションスタック１３５の間にＰＡＬ（ＰｒｏｔｏｃｏｌＡｄａｐｔａｔｉｏｎＬａｙｅｒ）１３４を配置する。

ＰＡＬ１３４はＩＥＥＥ１３９４トランザクションと無線ＬＡＮの間のプロトコル変換を行う。

ＩＰスタック１３７の上位にはトランスポート層としてＴＣＰ（ＴｒａｎｓｍｉｓｓｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ：ネットワークのトランスポート層の通信プロトコル）およびＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ：信頼性を保証しないトランスポート層の通信プロトコル）のスタック１３８を配置する。
ＴＣＰおよびＵＤＰのスタック１３８の上位には、ＨＴＴＰ(ＨｙｐｅｒｔｅｘｔＴｒａｎｓ−ｆａｒＰｒｏｔｏｃｏｌ)のプロトコル処理を行うＨＴＴＰスタック１３９を配置する。

また、この上位にＨＴＴＰ１３９を用いてＸＭＬ形式のメッセージ通信を行うＳＯＡＰ（ＳｉｍｐｌｅＯｂｊｅｃｔＡｃｃｅｓｓＰｒｏｔｏｃｏｌ）のプロトコル処理を行うＳＯＡＰ／ＸＭＬスタック１４０とを配置する。

ＨＴＴＰスタック１３９とＴＣＰおよびＵＤＰのスタック１３８間のインターフェースはｓｏｃｋｅｔ（ネットワーク経由でデータのやりとりをするためのプログラムインターフェースのこと）を用いる。

オペレーティングシステムＬｉｎｕｘ１３０より上位の層で、ＨＴＴＰスタック１３９、ＳＯＡＰ／ＸＭＬスタック１４０、１３９４トランザクションスタック１３５までを含む層までが、ＩＰｖ６対応インターネット通信プロトコルミドルウェア１０４に含まれる。

これらより上位の層として、ＳＯＡＰ／ＸＭＬスタック１４０およびＨＴＴＰスタック１３９の上位に、インターネットプロトコルベースのＵＰｎＰ機能を実現するためのプロトコルであるＵＰｎＰの処理を行うＵＰｎＰスタック１４１を配置する。

また、ＩＥＥＥ１３９４トランザクションスタック１３５の上位にはＩＥＥＥ１３９４を用いたネットワークのＵＰｎＰ機能を実現するための処理を行うＡＶ系ミドルウェア１３６を配置する。

ＵＰｎＰスタック１４１とＡＶ系ミドルウェア１３６の上位には、それぞれのネットワークを相互的に接続する統合ミドルウェア１４２を配置する。

ＡＶ系ミドルウェア１３６、ＵＰｎＰスタック１４１、統合ミドルウェア１４２を含む層が、前述のＵＰｎＰミドルウェア１０５に含まれる。
統合ミドルウェア１４２より上位の層は、アプリケーションの層となる。

ＳＯＡＰを用いて、ネットワーク上の他のコンピュータとの間でアプリケーション連携を行うＷｅｂサービスに対応するために、Ｗｅｂサーバ１４４、ＷｅｂサービスアプリケーションＩ／Ｆ１４５、Ｗｅｂサービスアプリケーション１４６を階層的に配置する。

Ｗｅｂサービスアプリケーション１４６はＷｅｂサービスＩ／Ｆ１４５を通じて、Ｗｅｂサーバの提供するサービスを使用する。

また、Ｗｅｂサービス以外のアプリケーションが統合ミドルウェア１４２を経由して、通信を行う。主なアプリケーションとしてはＨＴＴＰを用いるブラウザソフトウェアが挙げられる。

第１５図は、第１４図で説明した、ＵＰｎＰミドルウェア１０５を拡張した場合のソフトウェアブロック構成を示した図である。

この図においては、第１４図で説明したイーサネット（登録商標）、無線ＬＡＮ、ＩＥＥＥ１３９４によるネットワーク接続に加えて、通信用インターフェースとしてＢｌｕｅｔｏｏｔｈ、特定省電力無線、電灯線を用いたＰＬＣ（ＰｏｗｅｒＬｉｎｅＣｏｍｍｕｎｉｃａｔｉｏｎ）を用いるネットワークを追加した。

最下層には、それぞれのネットワークインターフェースを制御するためのデバイスドライバとして、Ｂｌｕｅｔｏｏｔｈドライバ１５３、特定小電力ドライバ１５４、ＰＬＣドライバ１５５があり、その上位にＩＰスタック１５６、ＴＣＰおよびＵＤＰのスタック１５７を階層的に配置する。

ＴＣＰおよびＵＤＰのスタック１５７の上位層として白物家電系ネットワークミドルウェア１５８を配置する。

そして、第１４図に示した場合と同様に、統合ミドルウェア１６４をＡＶ系ミドルウェア１３６、ＵＰｎＰスタック１４１および白物家電系ネットワークミドルウェア１５８の上位に配置することで、全てのネットワークを相互的に接続することが可能となる。

第１６図は、ユビキタス映像モジュールの撮像・表示部のソフトウェアブロック構成を示す図である。

図において、１８５は撮像・表示部ミドルウェアであり、アプリケーションに撮像・表示系の機能提供を行うソフトウェアモジュール群を備えている。

撮像・表示部ミドルウェア１８５は、ハードウェアを直接制御するドライバ群と、アプリケーションへのインターフェースを提供するライブラリ群の二層構造になっており、それぞれのソフトウェアモジュールは全てＬｉｎｕｘ上に構築されている。

ドライバ群は、カメラ１７１などの撮像系のハードウェアを制御するカメラドライバ１８０、ＬＣＤ１７２、２Ｄグラッフィクスエンジン１７３などの表示系ハードウェアを制御するＸサーバ１７８、３Ｄグラフィックスエンジン１７４などの３Ｄハードウェアを制御する３Ｄグラフィックサーバ１７６より構成される。

また、ライブラリ群は、アプリケーションに撮像・表示機能のインターフェースを提供するものであり、カメラ機能を提供するカメラライブラリ１８１、Ｘ−ｗｉｎｄｏｗ（登録商標）機能を提供するＸライブラリ１７９、３Ｄ機能を提供する３Ｄグラフィックスライブラリ１７７より構成される。

アプリケーション１８２は、例えば、カメラアプリケーション、ブラウザなど、ＵＩ（ユーザインターフェース）を提供する上位のソフトウェアモジュールである。

アプリケーション１８２が撮像および表示系の機能を実現する場合、撮像・表示部ミドルウェア１８５のライブラリ群より提供されたプログラムインターフェースにて実現し、アプリケーション１８２が撮像・表示部ミドルウェアの機能を直接使用する場合と、ＵＩアプリケーションフレームワーク１８４、ＪＡＶＡ（登録商標）ＶＭ１８３経由で使用する場合がある。

撮像・表示部ミドルウェア１８５がアプリケーション１８２に提供する主な機能としては、静止画撮影、動画撮影、動画プレビュー表示、２Ｄ・３Ｄ表示などがある。

カメラ１７１より入力された画像データをＪＰＥＧやＭＰＥＧなどに符号化して蓄積・送信する場合、カメラ１７１から入力された画像データを図中で示す３Ｄグラフィックサーバ１７６より、映像配信蓄積プロトコルミドルウェアブロックに転送する。

第１７図に、ＵＭの映像配信蓄積ミドルウェアのソフトウェアブロック図を示す。

第１７図のＵＭの映像配信蓄積ミドルウェアとは、アプリケーションに対して、メディア・データの配信・受信制御、伝送に対する品質保証制御、メディア・データの多重・分離処理およびエンコード・デコード、メディアの検索機能および構造定義、識別機能を提供するソフトウェア・モジュール群であり、使用する通信経路に対応したメディアの多重化処理、伝送制御を行うメディアゲートウェイ・レイヤ１９４と、メディアの符号化処理を行うトランスコーダ・レイヤ１９５と、メディアの検索、識別などの構造記述言語を含むメディア・プレゼンテーション・レイヤ１９６とを含んでいる。

また、メディアゲートウェイ・レイヤ１９４は、さらに放送などによる配信を想定したＴＳ（トランスポート・ストリーム）を扱うＩＴＵ−ＴＨ．２２２などの処理を行うＴＳブロック１９０、ＩＳＤＮなどの伝送路を対象とし、端末間通信を想定したＨ．２２１およびモバイル機器による通信を想定したＨ．２２３をサポートする通信ブロック１９１、ＬＡＮ、インターネットによるメディア伝送を想定したＨ．２２５に代表されるＩＰブロック１９２、および主に蓄積媒体を扱うＰＳ（プログラム・ストリーム）ブロック１９３により構成されている。

以上のように構成されたＵＭの映像配信蓄積ミドルウェアは、上位アプリケーション（例えば、ブラウザ）のＵＩ操作に従い、インターネットを介してメディア・データを取得する。

上位アプリケーションは、メディア・データの取得に対し、メディア・プレゼンテーション・レイヤ１９６はＭＰＥＧ−７で規定されたＭｕｌｔｉｍｅｄｉａＣｏｎｔｅｎｔ

ＤｅｓｃｒｉｐｔｉｏｎＩｎｔｅｒｆａｃｅを用いたコンテンツ検索機能、ＭＰＥＧ−２１で規定されたＩＰＭＰ（ＩｎｔｅｌｌｅｃｔｕａｌＰｒｏｐｅｒｔｙＭａｎａｇｅｍｅｎｔａｎｄＰｒｏｔｅｃｔｉｏｎ）によるメディア著作権・保護機能を利用することができる。

取得したデータに対して、メディアゲートウェイ・レイヤ１９４による多重分離処理、トランスコーダ・レイヤ１９５によるデコード処理が行われ、ＳＭＩＬ（ＳｙｎｃｈｒｏｎｉｚｅｄＭｕｌｔｉｍｅｄｉａＩｎｔｅｇｒａｔｉｏｎＬａｎｇｕａｇｅ）／ＨＴＭＬで指定された位置、タイミングで表示することができる。

第１８図は、映像情報装置のソフトウェアとＵＭのソフトウェアの関係を示した構成図である。

ＵＭは前述の通り、ＵＭのハードウェア１１１の上位にＨＡＬ１０１を介してオペレーティングシステムＬｉｎｕｘ１０２を配置し、その上位にＵＭのミドルウェア部１１２を配置し、その上位にＪＡＶＡ（登録商標）ＶＭ１０８とＵＩアプリケーションフレームワーク１０９を配置して、最上位にＵＩアプリケーションフレームワークを用いたアプリケーション１１０を配置する。

また、映像情報装置のソフトウェア構成は、必ずしもＵＭと同様な階層構造をとる必要はないが、階層構造を揃えた方がより望ましい。

即ち、映像情報装置のハードウェア２２０の上位にオペレーティングシステムＬｉｎｕｘ２２１を配置し、その上位に映像情報装置のミドルウェア２２２を配置し、その上位にＪＡＶＡ（登録商標）ＶＭ２２３とＵＩアプリケーションフレームワーク２２４を配置して、最上位にＵＩアプリケーションフレームワークを用いたアプリケーション２２５を配置するのが理想である。

最低限の条件として、オペレーティングシステムＬｉｎｕｘの階層が合っている場合、即ち、映像情報装置のオペレーティングシステムＬｉｎｕｘ２２１が配置されている場合は、映像情報装置のオペレーティングシステムＬｉｎｕｘ２２１とＵＭのオペレーティングシステムＬｉｎｕｘ１１１の間はシステムコールレベルで透過的に接続されていることになる。

第１９図は、このときの状態を概念的に表したものである。

この結果、例えば、映像情報装置上のプログラムでオープン命令を用いて、ＵＭのデバイスをオープンすることが可能となる。

なお、上位のソフトウェアから下位のソフトウェアの機能を使用する場合（例えば、アプリケーションソフトウェアがミドルウェアの機能を使用する場合など）、ある所定の手続きに従って、命令やデータのやりとりを行う。

この際、一般的には、使用したい機能が自分自身のマシン上（ここでは映像情報装置）にある場合と、他のマシン上（ＵＭ）にある場合とで手続きが異なる。

「透過的に接続する」とは、この使用したい機能がどちらに存在する場合でも、その違いを気にすることなく、同じ手続きでやりとりを行うことができるように接続することを意味する。

次にオペレーティングシステムとミドルウェアの階層構造が合っている場合、もしくはミドルウェアの構造が合っている場合、すなわち、映像情報装置のオペレーティングシステムＬｉｎｕｘ２２１の上位にミドルウェア２２２が配置されている場合、前述のシステムコールレベルでの透過性に加えて、映像情報装置のミドルウェア２２２とＵＭのミドルウェア１１２の間は、ミドルウェアＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）レベルで透過的に接続されていることになる。

この結果、例えば、映像情報装置上のプログラムからミドルウェアＡＰＩをコールすることで、ＵＭのミドルウェアを操作することが可能となる。

また、前述の理想的な条件で階層が合っている場合、もしくはＪａｖａ（登録商標）ＶＭ２２３および／または、ＵＩアプリケーションフレームワーク２２４の構造が合っている場合、すなわち、映像情報装置のオペレーティングシステムＬｉｎｕｘ２２１が配置され、その上位にミドルウェア２２２が配置され、その上位にＪＡＶＡ（登録商標）ＶＭ２２３とＵＩアプリケーションフレームワーク２２４を配置され、最上位にＵＩアプリケーションフレームワークを用いたアプリケーション２２５が配置されている場合、前述のシステムコールおよびミドルウェアＡＰＩレベルでの透過性に加えて、映像情報装置のＪＡＶＡ（登録商標）ＶＭ２２３およびＵＩアプリケーションフレームワーク２２４とＵＭのＪＡＶＡ（登録商標）ＶＭ１０８およびＵＩアプリケーションフレームワーク１０９の間はアプリケーションを作成する際のアプリケーション設計データレベルで透過的に接続されていることになる。

第２０図は、このときの状態を概念的に表したものである。

この結果、映像情報装置、ユビキタス映像モジュールのプラットフォームの違いを気にせずにアプリケーションを作成することが可能となる。

さらに第２１図は、ＵＭを映像記録装置のシステムに適応した場合におけるソフトウェアのブロックの構成を示す図である。プロセス間通信コミュニケータ７１はプロセス間通信をＡＴＡのコマンドインターフェースに変換するモジュールであり、ＡＴＡドライバ７２、ＡＴＡホストインターフェース７３を介して、ユビキタス映像モジュールのＡＴＡデバイスコントローラ７６にＡＴＡのコマンドを送付する。

ＡＴＡデバイスコントローラ７６はＡＴＡのコマンドを受信し、ＡＴＡエミュレータ７５はＡＴＡのコマンドを解析して、プロセス間通信コミュニケータ７４によりプロセス間通信に変換する。以上により、映像記録装置のプロセスとユビキタス映像モジュールセットのプロセスがプロセス間通信可能となる。

つまり、映像記録装置上のプロセス間通信手段をストレージインターフェースに変換および逆変換する通信コミュニケータ７１と、ＵＭＵ上のプロセス間通信手段をストレージインターフェースに変換および逆変換する通信コミュニケータ７４とを備え、映像記録装置上のプロセスとＵＭＵ上のプロセスがプロセス間通信を行うことができる。

以上のように、映像情報装置、映像記録装置のソフトウェアの構成に応じて、装置とＵＭ間のソフトウェアの結合状態を変更することが可能である。この場合、双方のソフトウェアの階層構造が揃っている程、より上位の層でのソフトウェアの共用化が可能となり、結果として機能の分担や機能の移植を容易に行うことが可能となる。

以上の実施の形態では、装置およびＵＭのオペレーティングシステムとしてＬｉｎｕｘを例にとり説明しているが、代わりにＰＯＳＩＸ準拠もしくは類似の他のオペレーティングシステムを用いることも可能である。

また、装置およびＵＭの仮想マシンとして、ＪＡＶＡ（登録商標）ＶＭを例に取って説明しているが、代わりにＪＡＶＡ（登録商標）ＶＭ互換マシンや、類似の他の仮想マシンを用いることも可能である。

さらに、ストレージインターフェースとしてＡＴＡを用いたが、ＳＣＳＩなど他の汎用的なストレージインターフェースを用いてもよい。

また、ストレージインターフェースを用いたが、ＵＳＢ、ＩＥＥＥ１３９４などのストレージ用のプロトコルセットを備えた汎用的なインターフェースを用いてもよい。

また、映像記録装置とＵＭ間では、プロセス間通信コミュニケータを用いてプロセス間通信を用いたが、プログラム間通信コミュニケータを用いてプログラム間通信を用いてもよい。つまり、映像記録装置上のプログラム間通信手段をストレージインターフェースに変換および逆変換する通信コミュニケータＡと、ユビキタス映像モジュールユニット上のプログラム間通信手段をストレージインターフェースに変換および逆変換する通信コミュニケータＢとを備え、映像記録装置上のプログラムとＵＭＵ上のプログラムがプログラム間通信を行うようにしてもよい。

さらに、この実施の形態では、ＵＭＵとストレージ機器とを別構成にしたが、一体形状で構成してもよい。

以上説明した本実施の形態におけるＵＭ、ＵＭＵ、各装置は以下のような効果を奏する。

この実施の形態によるＵＭＵは、複数のハードウェアエンジンとＣＰＵの分散実行機能をサポートするＯＳが組込まれているので、映像情報装置に要求される仕様・機能が変わっても、容易、かつフレキシブルに機能変更・拡張が行え、新たな映像情報装置を開発するための開発費用ならびに開発期間を低減することができる。

また、この実施の形態によるＵＭＵは、ＯＳとＣＰＵを含むハードウェア層の間に設けられ、ハードウェアの違いを吸収するＨＡＬおよび／または、ＯＳ上で動作する機能別のミドルウェア群および／または、仮想マシン上で動作するユーザインターフェースアプリケーションを作成するためのユーザインターフェースフレームワークおよび／または、ユーザインターフェースフレームワークおよび／または、ミドルウェア群を用いて作成した映像情報装置別アプリケーションを搭載するので、映像情報装置に要求される仕様・機能が変わっても、これらを適宜組み合わせることによって、容易、かつフレキシブルに機能変更・拡張が行え、新たな映像情報装置を開発するための開発費用ならびに開発期間を低減することができる。

また、この実施の形態によるＵＭＵの複数のハードウェアエンジンは、ネットワーク環境との通信を行うためのコミュニケーションエンジンを含むので、映像情報装置を容易にネットワーク環境に接続することができる。

また、この実施の形態による映像情報システムは、ＵＭと同一の機能を有するＯＳを組込み、映像情報装置に組み込まれたＯＳとＵＭに組み込まれたＯＳとを透過的に接続することによって、システムコールのレベルで映像情報装置からＵＭに対してアクセスを行うので、映像情報装置上のプログセムから特定のハードウェアデバイスをアクセスする際に、そのハードウェアデバイスが映像情報装置上にあるのか、ＵＭ上にあるのかを意識することなく、同一の手続きでアクセスを行うことができる。

また、この実施の形態による映像情報システムは、ＵＭと同一の機能を有するＯＳを組込み、機能別のミドルウェア群を搭載し、または、映像情報装置は、ＵＭと同一の機能を有する機能別のミドルウェア群を搭載し、映像情報装置に組み込まれたＯＳとＵＭに組み込まれたＯＳとを透過的に接続することおよび／または、映像情報装置に組み込まれたミドルウェアとＵＭに組み込まれたミドルウェアとを透過的に接続することによって、ミドルウェアのＡＰＩレベルで映像情報装置からＵＭに対してアクセスを行うので、映像情報装置上のプログセムからミドルウェアを用いて特定の機能を使用する際に、その特定の機能が映像情報装置上にあるのか、ＵＭ上にあるのかを意識することなく、同一の手続きで使用することができる。

また、この実施の形態による映像情報システムは、ＵＭと同一の機能を実現する仮想マシン上で動作するユーザインターフェースアプリケーションを作成するためのユーザインターフェースフレームワークを搭載し、ＵＭと同一の機能を有する機能別のミドルウェア群および／または、ＵＭと同一の機能を有するＯＳおよび／または、を搭載し、ユーザインターフェースフレームワークおよび／または、ミドルウェア群を用いて作成した映像情報装置別アプリケーションを搭載し、映像情報装置に組み込まれたＯＳとＵＭに組み込まれたＯＳとを透過的に接続することおよび／または、映像情報装置に組み込まれたミドルウェアとＵＭに組み込まれたミドルウェアとを透過的に接続することおよび／または、映像情報装置に組み込まれた仮想マシンおよびユーザインターフェースフレームワークとＵＭに組み込まれた仮想マシンおよびユーザインターフェースフレームワークとを透過的に接続することによって、アプリケーション作成データのレベルで映像情報装置およびＵＭの相違を考慮することなくアプリケーションの作成を行うので、映像情報装置上でユーザインターフェースアプリケーションを作成する際に、そのアプリケーションが実行されるハードウェアの構成を意識することなく作成することができる。

さらに、映像情報装置のＵＭのソフトウェア構造を合わせることにより、ＵＭ側で実現している機能を将来的に映像情報装置側に移植する際に、その作業を容易に行える。

また、この実施の形態による映像情報システムは、機能別のミドルウェア群として、撮像および表示処理を行うミドルウェアおよび／または、ＩＰｖ６に対応したインターネット通信プロトコル処理を行うミドルウェアおよび／または、ユニバーサルプラグアンドプレイ処理を行うミドルウェアおよび／または、ＭＰＥＧ２／ＭＰＥＧ４／ＭＰＥＧ７／ＭＰＥＧ２１規格に準拠した映像配信および蓄積処理を行うミドルウェアとから構成するので、映像情報装置にＵＭを付加することによって、撮像・表示、ネットワーク接続、映像の配信・蓄積機能を容易に追加することが可能となる。

また、この発明による映像情報システムは、システムの種類に応じて、アプリケーションおよびＨＡＬを選択的に使用するので、ＵＭのハードウェア構成を変更することなく、異なる用途の映像情報装置を構成することができる。

実施の形態２．
本実施の形態では、ＵＭ１２を携帯電話に適用した例について説明する。
第２２図は第４５図で説明した従来の携帯電話装置に、ＵＭＵ４３を適用した携帯電話のシステム構成図である。第２２図のモバイル・アプリケーション・ユニット２１９は、第４５図のモバイル・アプリケーション・ユニット２１９と同じものであるが、まず基本的構成について、再度、説明する。

図示しない携帯電話の無線網からアンテナ２１８を介して入力されたデータは、ベースバンド部２１７により信号処理され、通信ヘッダ情報が取り除かれ、再構築される。さらにモバイル・アプリケーション・ユニット２１９で、表示装置２１１に表示可能な信号形態にまで変換され表示ユニット２１１へ出力される。無論、音声の入出力に関する構成ブロックもあるがここでは図示を省略し、以下の説明も映像情報の処理を主に説明する。

モバイル・アプリケーション・ユニット２１９は、システムＬＳＩ２０８と、システムＬＳＩ２０８のＦＰ２０７と、システムＬＳＩ２０８のＢＰ２０９と、Ｖ−Ｉ／Ｆ２１０で構成される。

モバイル・アプリケーション・ユニット２１９に入力されたデータは、ＣＰＵ２０１のソフトウェア、ＶＳＰ２０２のハードウェアにより、デコード、リサイズ等され、Ｖ−Ｉ／Ｆ２１０からＵＶＩ４４に出力される。なお、ＵＶＩ４４はＵＭＵ４２のビデオ（映像）入力端子であり、モバイル・アプリケーション・ユニット２１９の映像出力端子であるＶ−Ｉ／Ｆ２１０と接続可能なインターフェースを形成している。ＵＶＩ４４から入力されたデータはＵＭＵ４３内の各エンジンにより処理され、ＵＶＯ４５から表示ユニット２１２に入力され表示される。なお、ＵＶＯ４５は、ＵＭ４３の映像出力信号端子であり、表示ユニット２１１の入力インターフェースと接続される。

また、外部に接続されたカメラ・ユニット２１５からモバイル・アプリケーション・ユニット２０６に入力されたデータは、カメラ・エンジン２１６にてデータ処理され、第１のＣＰＵ２０１、ＶＳＰ２０２にて画像データとして再構築された後、さらにＵＭ４３にて処理され、表示ユニット２１１にて表示される場合や、さらに圧縮処理されフラッシュメモリ等の不揮発メモリに保存される場合や、さらに多重化処理され、ベースバンド部２１７より図示しない無線網へ送信される場合がある。

モバイル・アプリケーション・ユニット２１９は、本発明に言うところの、インターネットに接続可能な携帯電話網に接続してデータ通信を行う通信手段である。
このデータ通信のデータには映像情報が含まれる。

携帯電話に装着されたカメラ・ユニット２１５を高画素化した場合、処理データが増大し、カメラ・エンジン２１６が対応できなくなる場合がある。第２２図の構成では、ＵＭＵ４３を適用するので、より高性能なＵＭ１２に搭載されたカメラ・エンジン２２をカメラ・ユニット２１５の制御に利用できる。ＵＭＵ４３は、携帯電話専用に開発されるものではなく、第１図の各機器、例えば監視カメラ８やＤＶＤレコーダ７でも使用できるよう、十分な性能のカメラ・エンジンを備えており、カメラ・ユニットの変更に伴い、専用のＬＳＩを再設計することなく、モバイル・アプリケーション・ユニットの高画素化を果たすことができる。

このように、本実施の形態で説明したＵＭによれば、携帯電話装置を含むモバイルアプリケーションユニットにおいて、システムＬＳＩを新規に開発することなく、ネットワークの機能拡張や変更が実現できるため、開発費削減ならびに開発期間の短縮によるビジネスチャンス喪失の低減を図れる効果を有する。

また、ＵＭを挿抜可能な形状とした場合、ネットワークに関する必要な最新の機能を載せたユビキタス映情モジュールに取り替えることにより、様々な機器で汎用的に用いることが可能で、開発費、マスボリューム増加による量産効果が図りやすいという効果を有する。

さらに、ＵＭのインターフェースを汎用的に作ることにより、モバイルアプリケーションユニットの機能・回路を変更する必要が無いため、ソフト開発費の低減・信頼性の向上などの効果を有する。

さらに、既存開発製品に対してＵＭを付加する事で、ソフトウェアを大幅に変更することなく高機能化、新機能の追加を実現できる効果を有する。

実施の形態３．
本実施の形態では、上記実施の形態で説明した映像情報装置とＵＭＵの間の接続について、さらに詳細に説明する。

第２３図は、Ｓ−Ｉ／Ｆ３１およびＵ−Ｉ／Ｆ３２をそれぞれＩＥＥＥ１３９４シリアルバスのＩ／Ｆとして用い、映像情報装置とＵＭＵの間をＩＥＥＥ１３９４ネットワークで接続する場合の構成例である。すなわち、映像情報装置４０ａのＩＥＥＥ１３９４Ｉ／Ｆ２５０と、ＵＭＵ４２のＩＥＥＥ１３９４Ｉ／Ｆ２５１を介して、両装置が接続されている。ＩＥＥＥ１３９４ネットワークでは一つのネットワークにおいて複数機器の接続が可能である。したがって、図に示すように、映像情報装置４０ａの他、映像情報装置４０ｂ等、複数の映像情報装置が接続される場合もある。なお、第２３図では接続線が分岐して表記されているが、実際の各装置間の接続は、ＩＥＥＥ１３９４に従ったトポロジーで接続される。

ＵＭＵ４２は、イーサネット（登録商標）などの有線ＬＡＮインターフェース４６を介してＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌネットワーク（以降、「ＩＰネットワーク」と記す。）に接続されている。なお、有線ＬＡＮの他に、ＩＥＥＥ８０２．１１ａ／ｂ／ｇなどの無線ＬＡＮを用いても良い。ＩＰネットワークにはＵＰｎＰのＣｏｎｔｒｏｌＰｏｉｎｔ機能を有したＵＰｎＰＣｏｎｔｒｏｌＰｏｉｎｔ（以降、「ＵＰｎＰコントロールポイント」と記す。）３１０が接続されている。なお、ＵＰｎＰのＣｏｎｔｒｏｌＰｏｉｎｔ機能とは、ＩＰネットワークに接続されている他のＵＰｎＰデバイスをコントロールする機能を指す。実際には、パーソナルコンピュータ等にＵＰｎＰコントロールポイントをインストールして、デバイスの操作を行わせる。本実施の形態における接続形態を模式的に示したものが第２４図である。図において、ＵＭＵは、ＩＰネットワークとＩＥＥＥ１３９４ネットワーク間を接続するためのデリゲーションサーバとして動作する。また、ＩＰネットワーク上のＵＰｎＰコントロールポイントは、ＩＥＥＥ１３９４ネットワーク上にあるＵＰｎＰの機能を有さないＩＥＥＥ１３９４機器を操作する。すなわち、本実施の形態では、ＩＰネットワーク上のＵＰｎＰコントロールポイントが、デリゲーションサーバとして動作するＵＭＵを介して、ＵＰｎＰの機能を有さないＩＥＥＥ１３９４ネットワーク上の映像情報装置を操作する方法について説明する。

なお、ＩＰネットワークが第１図のネットワーク１に相当する。したがって、以下では、ＩＰネットワークを第１のネットワーク、ＩＥＥＥ１３９４ネットワークを第２のネットワークと記す場合がある。

＜ＵＰｎＰコントロールポイントとデバイスの動作＞
ところで、まず、ＵＰｎＰの規格に定められたＵＰｎＰコントロールポイントとデバイスの動作について説明する。最初に、ＵＰｎＰの規格に定められたＵＰｎＰコントロールポイントとデバイスの一般的な動作ステップについて説明する。ＵＰｎＰの規格には、第２５図に示すように、ＩＰアドレスの取得であるアドレッシング、ＵＰｎＰコントロールポイントがデバイスを検出、認識するディスカバリ、デバイスに関する情報を取得するディスクリプション、デバイスを制御するコントロール、デバイスの状態変化を検出するイベンティング、Ｗｅｂブラウザを用いてデバイスの操作、設定を行うプレゼンテーションの、合計６種類の動作ステップが定められている。以下、各動作ステップにおける詳細について説明する。

ＵＰｎＰにおける最初のステップであるアドレッシングＳ３０１は、ＩＰネットワークに参加したデバイスが自動的にＩＰアドレスを取得するステップである。アドレッシングＳ３０１のプロトコルには、基本的に、ＤｙｎａｍｉｃＨｏｓｔＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ（以降、「ＤＨＣＰ」と記す。）が使用される。なお、ＩＰネットワークがＤＨＣＰに対応していない場合は、ＡｕｔｏＩＰを用いてもよい。

アドレッシングＳ３０１によるＩＰアドレス取得の終了後、次のステップであるディスカバリＳ３０２に進む。ディスカバリＳ３０２は、ＵＰｎＰコントロールポイントがＩＰネットワーク上のデバイスを検出、認識するステップである。ディスカバリＳ３０２には、ＩＰネットワークに新規に追加されたデバイスがＵＰｎＰコントロールポイントに対してアドバタイズを行うアドバタイズ動作と、ＩＰネットワークに新規に追加されたＵＰｎＰコントロールポイントがデバイスを検索するために行うサーチ動作の２種類がある。前者の動作内容は、追加されたデバイスがアドバタイズのためのアドバタイズメッセージをマルチキャストするものである。後者の動作内容は、ＵＰｎＰコントロールポイントがサーチのためのサーチメッセージをマルチキャストして、該当するデバイスがＵＰｎＰコントロールポイントに対してサーチレスポンスメッセージを返信するものである。なお、どちらの動作にも、プロトコルとしてＳｉｍｐｌｅＳｅｒｖｉｃｅＤｉｓｃｏｖｅｒｙＰｒｏｔｏｃｏｌ（以降、「ＳＳＤＰ」と記す。）が用いられる。

ディスカバリＳ３０２によりＵＰｎＰコントロールポイントがデバイスを認識した後、次のステップであるディスクリプションＳ３０３に進む。ディスクリプションＳ３０３は、ＵＰｎＰコントロールポイントがデバイスに関する詳細な情報を取得するためのステップである。ＵＰｎＰコントロールポイントは、アドバタイズメッセージもしくはサーチレスポンスメッセージに記述されているＵＲＬにより、各デバイスの情報を得ることができる。なお、アドバタイズメッセージもしくはサーチレスポンスメッセージのＵＲＬを参照することにより、モデル名、シリアル番号、製造元名、サービス情報等が記載されているデバイスディスクリプションを取得することが可能となる。

ディスクリプションＳ３０３の動作ステップが完了した時点で、ＵＰｎＰコントロールポイントは、制御、操作の対象となるデバイスが有するサービスの内容を知ることになる。

コントロールＳ３０４は、実際にＵＰｎＰコントロールポイントがデバイスを制御する動作ステップである。ＵＰｎＰコントロールポイントはサービスディスクリプションに記載されているコマンド、アクション、サービス、各アクションのパラメータや引数のリストを元に、デバイスに対しアクション要求を含んだメッセージを送信する。なお、アクション要求を含んだメッセージの送信のプロトコルとして、ＳＯＡＰを用いる。すなわち、ＵＰｎＰコントロールポイントは、ＳＯＡＰを使用して、ＸＭＬ形式にて記述された制御コマンドをデバイスに送信する。デバイスはアクションとして要求されたサービスを行い、アクションを実行した結果をＵＰｎＰコントロールポイントに返信する。
イベンティングＳ３０５は、ＵＰｎＰコントロールポイントがデバイスの状態変化を検知する動作ステップである。デバイスは、自身が保有するサービスの状態変数が変化した場合、サブスクライブしているＵＰｎＰコントロールポイントに対して状態変化を通知する。状態変化を含んだメッセージのプロトコルには、ＧｅｎｅｒｉｃＥｖｅｎｔＮｏｒｔｉｆｉｃａｔｉｏｎＡｒｃｈｉｔｅｃｔｕｒｅ（以降、「ＧＥＮＡ」と記す。）が使用され、メッセージ自身はＸＭＬ形式で記述される。

プレゼンテーションＳ３０６は、Ｗｅｂブラウザを用いてデバイスの操作、設定を行う動作ステップである。操作、設定対象のデバイスがＨＴＭＬ形式に対応したユーザインタフェース機能を有している場合、デバイスディスクリプションに記述されているプレゼンテーションＵＲＬにアクセスすることにより、Ｗｅｂブラウザを用いてプレゼンテーション画面を表示することが可能となる。そして、そのプレゼンテーション画面を用いてユーザがデバイスの操作を行うことが可能となる。

以上では、ＵＰｎＰの規格に定められたＵＰｎＰコントロールポイントとデバイスの一般的な動作である。

＜ＡＶ機器の構成、動作＞
次に、以下では、特に、ＵＰｎＰの規格に定められたＡＶ機器の構成、動作について説明する。

ＵＰｎＰの規格では、各デバイス・タイプごとに、実装すべきインターフェイスや機能をＤｅｖｉｃｅＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ（以降、「ＤＣＰ」と記す。）として定めている。ＡＶ機器のＤＣＰは、ＭｅｄｉａＳｅｒｖｅｒ、およびＭｅｄｉａＲｅｎｄｅｒｅｒである。

ＵＰｎＰＡＶアーキテクチャを第２６図に示す。ＵＰｎＰＡＶアーキテクチャは、図に示すように、ＵＰｎＰコントロールポイント３１０が、ＭｅｄｉａＳｅｒｖｅｒ（以降、「メディア・サーバ」と記す。）３１１とＭｅｄｉａＲｅｎｄｅｒｅｒ（以降、「メディア・レンダラ」と記す。）３１２を制御するモデルである。

メディア・サーバ３１１は、コンテンツを蓄積し、蓄積したコンテンツを検索し、検索条件に適合するコンテンツをメディア・レンダラ３１２に送り出すデバイスであり、主にコンテンツの保管、ストリーミングの送り出しを行う機能を含むデバイスである。例えば、ＶＴＲや、ＤＶＤプレイヤ等の再生装置が、メディア・サーバ３１１として想定され得る。メディア・サーバ３１１は、ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅ（以降、「コンテンツ・ディレクトリ・サービス」と記す。また図中では「ＣＤＳ」と記す。）３１３、ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ（以降、「コネクション・マネージャ」と記す。また図中では「ＣＭ」と記す。）３１４、ＡＶＴｒａｎｓｐｏｒｔ（以降、「ＡＶトランスポート」と記す。また図中では「ＡＶＴ」と記す。）３１５の各サービスを含む。

メディア・レンダラ３１２は、ＩＰネットワークから入手したコンテンツを再生するために使用されるデバイスであり、主に、映像の表示、音声の出力等のコンテンツの再生、およびストリーミングの受信を行う機能を含むデバイスである。例えば、ＭＰＥＧ形式のファイルを表示する映像表示装置等が、メディア・レンダラ３１２として想定され得る。メディア・レンダラ３１２は、ＲｅｎｄｅｒｉｎｇＣｏｎｔｒｏｌ（以降、「レンダリング・コントロール」と記す。）３１６、コネクション・マネージャ３１４，ＡＶトランスポート３１５の各サービスを含む。

コンテンツ・ディレクトリ３１３は、メディア・サーバ３１１を含んだ機器から供給されるコンテンツをＵＰｎＰコントロールポイント３１０が列挙できるようなアクションセットを提供するサービスである。したがって、ＵＰｎＰコントロールポイント３１０は、コンテンツ・ディレクトリ３１３を使用することにより、コンテンツ階層の閲覧、および属性検索の実行、並びに、タイトル、作者、ＵＲＬ等属性のコンテンツのメタデータの入手、並びに、コンテンツの作成、削除などのコンテンツの操作等が可能となる。

コネクション・マネージャ３１４は、特定のデバイスに関連したコネクションを管理するアクションセットを提供するサービスである。したがって、ＵＰｎＰコントロールポイント３１０は、コネクション・マネージャ３１４を使用することより、ストリーミングのプロトコルやデータフォーマットの列挙、及び、現在のコネクション状況の列挙が可能となる。

レンダリング・コントロール３１６は、レンダラ（メディア・レンダラ３１２デバイスを含んだ機器）がコンテンツをどのように再生するかを、ＵＰｎＰコントロールポイント３１０が制御できるようにするためのアクションセットを提供するサービスである。したがって、ＵＰｎＰコントロールポイント３１０は、レンダリング・コントロール３１６を使用することで、ビデオ映像の輝度、コントラスト、音声の音量、ミュート等の制御が可能となる。

ＡＶトランスポート３１５は、ＵＰｎＰコントロールポイント３１０によるコンテンツのプレイバック制御を可能にするアクションセットを提供するサービスである。したがって、ＵＰｎＰコントロールポイント３１０は、ＡＶトランスポート３１５を使用することで、コンテンツの再生、停止、シーク等の再生制御が可能となる。

次に、ＵＰｎＰＡＶアーキテクチャにおける、コンテンツの一般的な再生フローを第２７図に示す。以下、各ステップの詳細について説明する。

最初のステップであるデバイスの発見Ｓ３１０は、ＩＰネットワーク上のデバイスの発見を行うステップである。このデバイスの発見Ｓ３１０は、ＵＰｎＰの動作ステップであるディスカバリＳ３０２とディスクリプションＳ３０３により行われる。デバイスの発見Ｓ３１０の完了後、ＵＰｎＰコントロールポイント３１０は、メディア・サーバ３１１とメディア・レンダラ３１２を認識し、制御することが可能となる。

実際のコンテンツの再生における最初のステップは、コンテンツの検索Ｓ３１０である。コンテンツの検索Ｓ３１０は、ＵＰｎＰコントロールポイント３１０が、メディア・サーバ３１１のコンテンツ・ディレクトリ３１３を使用して、コンテンツの検索を行うステップである。すなわち、ＵＰｎＰコントロールポイント３１０がメディア・サーバ３１１に対し、ＳＯＡＰを用いて「Ｂｒｏｗｓｅ」、又は「Ｓｅａｒｃｈ」アクション要求を含んだメッセージを送信する。その回答として、メディア・サーバ３１１はＵＰｎＰコントロールポイント３１０に対し、コンテンツの階層構造、転送プロトコルデータ、データフォーマットを含んだ情報を返信する。ＵＰｎＰコントロールポイント３１０が回答を受信した後、次のステップであるプロトコルデータ・フォーマットチェックＳ３１２に進む。

プロトコルデータ・フォーマットチェックＳ３１２は、ＵＰｎＰコントロールポイント３１０が、メディア・レンダラ３１２のコネクション・マネージャ３１４を使用して、メディア・レンダラ３１２がサポートしているコンテンツの転送プロトコルとフォーマットの情報を入手するステップである。すなわち、ＵＰｎＰコントロールポイント３１０がメディア・レンダラ３１２に対し、ＳＯＡＰを用いて「ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ」アクション要求を含んだメッセージを送信する。その回答として、メディア・レンダラ３１２がＵＰｎＰコントロールポイント３１０に対し、サポートしているコンテンツの転送プロトコルデータとデータフォーマットのリストを含んだ情報を返信する。

ＵＰｎＰコントロールポイント３１０が回答を受信した後、ＵＰｎＰコントロールポイント３１０は、プロトコルデータ・フォーマットチェックＳ３１２にて得た情報と、コンテンツの検索Ｓ３１１で得た情報をもとに、転送プロトコルデータとデータフォーマットを比較する。そして、比較結果から、適合する転送プロトコルデータとデータフォーマットを決定する。メディア・サーバ３１１にあるコンテンツの転送プロトコルデータ及びデータフォーマットと、メディア・レンダラ３１２がサポートするコンテンツの転送プロトコルデータ及びデータフォーマットが適合する場合、そのコンテンツはメディア・レンダラ３１２にて再生可能である。その後、次のステップであるサーバ、レンダラの準備Ｓ３１３に進む。

サーバ、レンダラの準備Ｓ３１３は、ＵＰｎＰコントロールポイント３１０が、コネクション・マネージャ３１４を使用して、メディア・サーバ３１１とメディア・レンダラ３１２に対し、プロトコルデータ・フォーマットチェックＳ３１２にて決定した転送プロトコルデータとデータフォーマットによるコネクションが生成されることを通知するステップである。すなわち、ＵＰｎＰコントロールポイント３１０が、メディア・サーバ３１１に対し、ＳＯＡＰを用いて「ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ」アクションを含んだメッセージを送信する。その回答として、メディア・サーバ３１１がＵＰｎＰコントロールポイント３１０に対し、「ＡＶＴｒａｎｓｐｏｒｔＩｎｓｔａｎｃｅＩＤ」を返信する。また、ＵＰｎＰコントロールポイント３１０は、メディア・レンダラ３１２に対しても、ＳＯＡＰを用いて「ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ」アクションを含んだメッセージを送信する。そして、その回答として、メディア・レンダラ３１２がＵＰｎＰコントロールポイント３１０に対し、「ＡＶＴｒａｎｓｐｏｒｔＩｎｓｔａｎｃｅＩＤ」、または、「ＲｅｎｄｅｒｉｎｇＣｏｎｔｒｏｌＩｎｓｔａｎｃｅＩＤ」を返信する。ＵＰｎＰコントロールポイント３１０が回答を受信した後、次のステップである、コンテンツの選択Ｓ３１４に進む。

コンテンツの選択Ｓ３１４は、ＵＰｎＰコントロールポイント３１０が、ＡＶトランスポート３１５サービスを使用して、メディア・サーバ３１１とメディア・レンダラ３１２に対し、ユーザの選択により転送されるコンテンツの情報を通知するステップである。すなわち、ＵＰｎＰコントロールポイント３１０がメディア・サーバ３１１に対し、ＳＯＡＰを用いて「ＳｅｔＡＶＴｒａｎｓｐｏｒｔＵＲＩ」アクションを含んだのメッセージを送信する。同様に、メディア・レンダラ３１２に対しても、ＳＯＡＰを用いた「ＳｅｔＡＶＴｒａｎｓｐｏｒｔＵＲＩ」アクションのメッセージが送信される。この後、実際にコンテンツの再生制御を行うステップである再生Ｓ３１５に進む。

再生Ｓ３１５は、ＵＰｎＰコントロールポイント３１０は、ＡＶトランスポート３１５サービスを使用して、メディア・サーバ３１１とメディア・レンダラ３１２に対し、ＳＯＡＰを用いて「Ｐｌａｙ」、「Ｓｔｏｐ」、「ｓｅｅｋ」等、実際の再生制御の指令を行うステップである。すなわち、ＵＰｎＰコントロールポイント３１０がメディア・サーバ３１１とメディア・レンダラ３１２に対し、例えば「Ｐｌａｙ」アクションのメッセージを送信すると、コンテンツの再生が開始される。また、コンテンツの再生を中止したい場合は、メディア・サーバ３１１とメディア・レンダラ３１２に対し「Ｓｔｏｐ」アクションを送信する。

音量・画質調整Ｓ３１６は、ＵＰｎＰコントロールポイント３１０が、レンダリング・コントロール３１６サービスを使用して、コンテンツの再生中にレンダラの音量調整や画質調整を行うステップである。例えば音量調整を行う場合は、ＵＰｎＰコントロールポイント３１０がメディア・レンダラ３１２に対し、「ＳｅｔＶｏｌｕｍｅ」アクションのメッセージを送信する。その結果、音量が変更される。コンテンツの転送が最終的に完了した後、次のステップである、転送完了Ｓ３１７に進む。

転送完了Ｓ３１７は、ＵＰｎＰコントロールポイント３１０が、コネクション・マネージャ３１４を使用して、ＵＰｎＰコントロールポイント３１０とメディア・サーバ３１１の間のコネクション、及びＵＰｎＰコントロールポイント３１０とメディア・レンダラ３１２の間のコネクションの終了処理を行うステップである。すなわち、ＵＰｎＰコントロールポイント３１０がメディア・レンダラ３１２に対し、ＳＯＡＰを用いて「ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ」アクションを含んだメッセージを送信し、その回答を受信する。同様に、メディア・サーバ３１１に対して、「ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ」アクションを含んだメッセージを送信し、その回答を受信する。以上のステップを経て、一連のコンテンツの再生が完了する。

以上が、ＵＰｎＰＡＶアーキテクチャにおける、ＵＰｎＰコントロールポイントとデバイスの動作である。

＜ＵＰｎＰコントロールポイントによる映像情報装置の操作＞
次に、第２３図に示したような、ＩＰネットワーク上のＵＰｎＰコントロールポイント３１０が、デリゲーションサーバとして動作するＵＭＵ４２を介して、ＵＰｎＰの機能を有さないＩＥＥＥ１３９４ネットワーク上の映像情報装置４０ａを実際に操作する方法について説明する。

まず、ＵＭＵのソフトウェア構成について説明する。第２８図は、ＵＭＵ４２内のソフトウェア構成を示した図である。

ＵＰｎＰスタック３２１は、ＵＰｎＰプロトコルの処理を行うソフトウェア群であり、例えば、標準的なＨＴＴＰのＧＥＴリクエストを取り扱うＨＴＴＰサーバ、ＨＴＴＰメッセージのヘッダを解釈するためのＨＴＴＰパーサ、ＸＭＬパーサ、ＳＯＡＰ、ＧＥＮＡ，ＳＳＤＰのプロトコルを扱うモジュール群等から構成される。すなわち、ＵＰｎＰスタック３２１は、ＵＰｎＰプロトコルによる通信の処理を行う。

ＩＥＥＥ１３９４スタック３２２は、ＩＥＥＥ１３９４のトランザクションや、ＦｕｎｃｔｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ（以降、「ＦＣＰ」と記す。）などのＡＶプロトコル、ＡＶ／ＣコマンドなどのＩＥＥＥ１３９４関連プロトコルを扱うためのソフトウェア群である。すなわち、ＩＥＥＥ１３９４スタック３２２は、ＩＥＥＥ１３９４プロトコルによる通信の処理を行う。

デリゲーションマネージャ３２６は、例えば映像情報装置４０ａのようなＩＥＥＥ１３９４機器がＩＥＥＥ１３９４ネットワークに接続された場合、そのＩＥＥＥ１３９４機器の情報を基にＵＰｎＰエミュレーション処理３２５を起動したり、また、ＩＥＥＥ１３９４機器がネットワークから切断された場合に、そのＩＥＥＥ１３９４機器に対応して起動したＵＰｎＰエミュレーション処理３２５を終了させる等の機能を有するソフトウェアである。

ＵＰｎＰエミュレーション処理３２５は、ＩＥＥＥ１３９４ネットワークに接続されている個々のＩＥＥＥ１３９４機器に対応して、それぞれ独立したプロセスとしてデリゲーションマネージャ３２６から起動されるソフトウェアである。すなわち、ＩＥＥＥ１３９４機器を１つのＵＰｎＰデバイスとして振舞わせるために、ＵＰｎＰの各ステップをデバイスの代わりに実行する機能を有する。したがって、ＵＰｎＰエミュレーション処理３２５は、ＩＥＥＥ１３９４ネットワークに接続されているＩＥＥＥ１３９４機器に対応するプロセスとして起動される。そして、ＵＰｎＰエミュレーション処理３２５が起動される数は、ＩＥＥＥ１３９４ネットワークに接続されているＩＥＥＥ１３９４機器の数と同じである。

ＩＥＥＥ１３９４バス制御処理は、ＩＥＥＥ１３９４機器の状態を監視する機能を有するソフトウェアであり、デリゲーションマネージャ３２６に対するＩＥＥＥ１３９４機器の接続切断の情報の通知の他、ＩＥＥＥ１３９４機器から受信したＡＶ／ＣコマンドデータのＵＰｎＰエミュレーション処理３２５への引き渡し、ＵＰｎＰエミュレーション処理３２５から受け取ったＡＶ／ＣコマンドデータのＩＥＥＥ１３９４機器への送信等を行う。

ＩＰアドレスマネージャ３２３は、ＵＰｎＰエミュレーション処理３２５によりエミュレートされている各ＩＥＥＥ１３９４機器に対し、ＩＰアドレスを割り付けるための機能を有するソフトウェアである。

次に、上記実施の形態４で説明したＵＰｎＰの各動作ステップにおける、ＵＭＵ４２内のソフトウェアの動作について説明する。

最初に、アドレッシングＳ３０１におけるソフトウェアの動作について説明する。このステップは、ＩＥＥＥ１３９４ネットワークに新たに追加されたＩＥＥＥ１３９４機器を仮想的にＩＰネットワーク上のデバイスとみなし、ＤＨＣＰサーバから与えられたＩＰアドレスを付与するステップである。

第２９図は、アドレッシングＳ３０１における、ＵＭＵ内のソフトウェアの動作のシーケンスを示した図である。まず、ステップＳ３２０にて、ＩＥＥＥ１３９４機器３２７の電源のＯＮ、または、新たなＩＥＥＥ１３９４機器３２７のＩＥＥＥ１３９４ネットワークへの接続により、バスリセットが発生する。ＩＥＥＥ１３９４スタック３２２を介しバスリセットを検出したＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ３２１にて、デリゲーションマネージャ３２６に対し、ＩＥＥＥ１３９４機器３２７が新たにネットワークに接続されたことを知らせる接続通知を行う。接続通知を受けたデリゲーションマネージャ３２６は、ステップＳ３２２にて、新たに接続されたＩＥＥＥ１３９４機器３２７に対応するＵＰｎＰエミュレーション処理３２５を起動する。ステップＳ３２２にて起動されたＵＰｎＰエミュレーション処理３２５は、以降の全てのＵＰｎＰステップにおいて、常に、接続通知の発端となったＩＥＥＥ１３９４機器に対応して動作する。すなわち、ＩＥＥＥ１３９４ネットワークに複数台のＩＥＥＥ１３９４機器が接続された場合は、各ＩＥＥＥ１３９４機器毎に、各ＩＥＥＥ１３９４機器３２７に１対１にて対応するＵＰｎＰエミュレーション処理３２５が起動されることとなる。次に、起動されたＵＰｎＰエミュレーション処理３２５は、ステップＳ３２３にて、ＩＰアドレスマネージャ３２３に対してＩＰアドレス取得要求を行う。ＩＰアドレスマネージャ３２３は、ＩＥＥＥ１３９４機器３２７に対して仮想的に割り当てるＩＰアドレスをＤＨＣＰサーバに要求し、その結果付与されたＩＰアドレスをステップＳ３２４にて、ＵＰｎＰエミュレーション処理３２５に対して通知する。なお、アドレッシングＳ３０１の手段として、ＤＨＣＰ以外にもＡｕｔｏＩＰを用いてもよい。

次に、ディスカバリＳ３０２におけるソフトウェアの動作について説明する。このステップは、ＵＰｎＰコントロールポイントがＵＰｎＰエミュレーション処理を介し、ＩＥＥＥ１３９４機器を検出、認識するステップである。

第３０図は、新たに追加されたデバイスがＵＰｎＰコントロールポイント３１０に対しアドバタイズ動作を行う場合の、ディスカバリＳ３０２におけるＵＭＵ内のソフトウェアの動作のシーケンスを示したものである。なお、第３０図では、ＩＰネットワーク上に２台のＵＰｎＰコントロールポイント３１０ａ、３１０ｂが存在する場合を示している。まず、ステップＳ３３０において、ＩＥＥＥ１３９４機器３２７に対応し、すでに起動されているＵＰｎＰエミュレーション処理３２５が、ＳＳＤＰを使用して、アドバタイズメッセージをマルチキャストする。ＵＰｎＰコントロールポイントＡ３１０ａと、ＵＰｎＰコントロールポイントＢ３１０ｂは、このメッセージを受信した後、ＵＰｎＰエミュレーション処理３２５をＵＰｎＰのデバイスとして認識する。すなわち、ＵＰｎＰコントロールポイントＡ３１０ａと、ＵＰｎＰコントロールポイントＢ３１０ｂは、ＵＰｎＰエミュレーション処理３２５を介し、ＩＥＥＥ１３９４機器３２７を認識することとなる。

第３１図は、新たに追加されたコントロールポイントがデバイスを検索するためのサーチ動作を行う場合の、ディスカバリＳ３０２におけるＵＭＵ内のソフトウェアの動作のシーケンスを示したものである。なお、第３１図では、ＩＥＥＥ１３９４ネットワーク上に２台のＩＥＥＥ１３９４機器３２７ａ、３２７ｂが存在する場合を示している。まず、ステップＳ３４０において、ＵＰｎＰコントロールポイント３１０が、ＳＳＤＰを用いて、ＩＰネットワーク上にサーチメッセージをマルチキャストする。このメッセージを受信した、ＩＥＥＥ１３９４機器３２７ａに対応したＵＰｎＰエミュレーション処理３２５ａと、ＩＥＥＥ１３９４機器３２７ｂに対応したＵＰｎＰエミュレーション処理３２５ｂは、自身に対応するＩＥＥＥ１３９４機器が、サーチメッセージの条件に示されているサービス、またはデバイスに相当する機能を有しているか否かを検出し、その機能を有している場合は、ステップＳ３４１において、レスポンスメッセージをＵＰｎＰコントロールポイント３１０に対し送信する。図では、ＵＰｎＰエミュレーション処理３２５ｂに対応したＩＥＥＥ１３９４機器３２７ｂが、サーチメッセージの条件に示されているサービス、またはデバイスに相当する機能を有している場合を示している。レスポンスメッセージを受信したＵＰｎＰコントロールポイント３１０は、ＵＰｎＰエミュレーション処理３２５を介し、ＩＥＥＥ１３９４機器３２７ｂを、自身がサーチした条件に適合するデバイスとして認識する。

次に、ディスクリプションＳ３０３におけるソフトウェアの動作について説明する。このステップは、ＵＰｎＰコントロールポイントがＵＰｎＰエミュレーション処理を介し、ＩＥＥＥ１３９４機器に関する詳細な情報を取得するステップである。

第３２図は、ディスクリプションＳ３０３におけるＵＭＵ内のソフトウェアの動作のシーケンスを示した図である。まず、ＵＰｎＰコントロールポイント３１０は、ステップＳ３５０において、アドバタイズメッセージ、またはサーチレスポンスメッセージに記述されているＵＲＬを用いて、ＩＥＥＥ１３９４機器３２７に対応したＵＰｎＰエミュレーション処理３２５に対し、デバイスディスクリプションの要求を行う。なお、ステップＳ３５０に用いられるプロトコルはＨＴＴＰである。次に、ＵＰｎＰエミュレーション処理３２５は、ＩＥＥＥ１３９４機器３２７に関するデバイス情報を、ＸＭＬ形式にてデバイスディスクリプションとして作成し、ステップＳ３５１にてＵＰｎＰコントロールポイント３１０に送信する。ステップＳ３５１におけるデバイスディスクリプションのサービスリストに、サービスディスクリプションを取得するためのＵＲＬが記載されている場合、さらに、ＵＰｎＰコントロールポイント３１０は、ステップＳ３５２において、ＵＰｎＰエミュレーション処理３２５に対し、サービスディスクリプションの要求を行う。ＵＰｎＰエミュレーション処理３２５は、ステップＳ３５２のサービスディスクリプションの要求に対し、ＩＥＥＥ１３９４機器３２７に関するサービス情報をＸＭＬ形式にてサービスディスクリプションとして作成し、ステップＳ３５１にてＵＰｎＰコントロールポイント３１０に送信する。なお、Ｓ３５０のデバイスディスクリプションの要求、Ｓ３５１のデバイスディスクリプションの送信は、ＵＰｎＰエミュレーション処理３２５に対応するＩＥＥＥ１３９４機器３２７が有するデバイスの回数行われる。同様に、Ｓ３５２のサービスディスクリプションの要求、Ｓ３５３のサービスディスクリプションの送信は、ＵＰｎＰエミュレーション処理３２５に対応するＩＥＥＥ１３９４機器３２７が有するサービスの回数行われる。このステップにより、ＵＰｎＰコントロールポイントはＵＰｎＰエミュレーション処理を介し、ＩＥＥＥ１３９４機器の有するサービス、デバイスを認識することとなる。

次に、コントロールＳ３０３におけるソフトウェアの動作について説明する。このステップは、ＵＰｎＰコントロールポイントがＵＰｎＰエミュレーション処理を介し、ＩＥＥＥ１３９４機器を制御するステップである。

第３３図は、コントロールＳ３０３におけるＵＭＵ内のソフトウェアの動作のシーケンスを示したものである。まず、ステップＳ３６０にて、ＵＰｎＰコントロールポイント３１０は、ＳＯＡＰを用いて、ＵＰｎＰエミュレーション処理３２５に対しアクション要求を行う。ＵＰｎＰエミュレーション処理３２５は、受信したＵＰｎＰのアクション要求を、そのアクション要求に対応するＡＶ／Ｃコマンドに変換し、ステップＳ３６１にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ３６２にて、ＩＥＥＥ１３９４機器３２７に対しＡＶ／Ｃコマンドを送信する。ＩＥＥＥ１３９４機器３２７は受信したＡＶ／Ｃコマンドに従った動作を行う。動作終了後、ＩＥＥＥ１３９４機器３２７は、ステップＳ３６３にてＡＶ／ＣレスポンスをＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ３６４にて、受信したＡＶ／Ｃレスポンスを、レスポンスの送信元であるＩＥＥＥ１３９４機器３２７に対応するＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、ＡＶ／ＣレスポンスをＵＰｎＰのアクションレスポンスに変換した後、ＳＯＡＰを用いてステップＳ３６５にてＵＰｎＰコントロールポイント３１０に送信する。ＵＰｎＰコントロールポイント３１０は、アクションレスポンスの受信により、自身が発行したアクション要求が実行されたことを認識する。

次に、イベンティングＳ３０５におけるソフトウェアの動作について説明する。このステップは、ＵＰｎＰコントロールポイントがＵＰｎＰエミュレーション処理を介し、ＩＥＥＥ１３９４機器の状態変化を検知するステップである。

第３４図は、ＵＰｎＰコントロールポイント３１０がＵＰｎＰデバイスに対し状態変化通知を要求するサブスクライブ動作を行う場合の、イベンティングＳ３０５のＵＭＵ内のソフトウェアの動作のシーケンスを示したものである。まず、ＵＰｎＰコントロールポイント３１０は、ステップＳ３７０において、ＧＥＮＡを用い、ＵＰｎＰエミュレーション処理３２５に対しサブスクライブ要求を行う。ＵＰｎＰエミュレーション処理３２５は、サブスクライブ要求に応じ、ＵＰｎＰコントロールポイント３１０を購読者リストに追加した後、ステップＳ３７１においてサブスクライブレスポンスをＵＰｎＰコントロールポイント３１０に対して返信する。この後、ＵＰｎＰエミュレーション処理３２５は、ステップＳ３７２にて、ＩＥＥＥ１３９４バス制御処理３２４に対し、状態変化を知らせることを要求するためのＡＶ／Ｃコマンド「Ｎｏｒｔｉｆｙ」を送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ＩＥＥＥ１３９４機器３２７に対し、ステップＳ３７３にてＡＶ／Ｃコマンド「Ｎｏｒｔｉｔｙ」を送信する。これにより、ＩＥＥＥ１３９４機器の状態変化があった場合、ＵＰｎＰコントロールポイントがＵＰｎＰエミュレーション処理を介し、その状態変化を検知することが可能となる。さらに、ＵＰｎＰエミュレーション処理３２５は、ＩＥＥＥ１３９４バス制御処理３２４に対し、現在の状態を問い合わせるＡＶ／Ｃコマンド「Ｓｔａｔｕｓ」をステップＳ３７４にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ３７５にて、ＩＥＥＥ１３９４機器３２７に対し、ＡＶ／Ｃコマンド「Ｓｔａｔｕｓ」を送信する。ＩＥＥＥ１３９４機器３２７はＡＶ／Ｃコマンド「Ｓｔａｔｕｓ」に応じて、現在の状態をＡＶ／Ｃレスポンス「Ｓｔａｔｕｓ」として、ステップＳ３７６にて、ＩＥＥＥ１３９４バス制御処理３２４に対して送信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／Ｃレスポンス「Ｓｔａｔｕｓ」を、ステップＳ３７７にてレスポンスの送信元であるＩＥＥＥ１３９４機器３２７に対応したＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、ＡＶ／Ｃレスポンス「Ｓｔａｔｕｓ」をＵＰｎＰのイニシャルイベントに変換し、ＧＥＮＡを用いてステップＳ３７８にてＵＰｎＰコントロールポイント３１０に送信する。これにより、ＵＰｎＰコントロールポイント３１０は、ＵＰｎＰエミュレーション処理３２５を介し、サブスクライブ要求を行ったＩＥＥＥ１３９４機器３２７の初期状態を知ることが可能となる。

第３５図は、ＩＥＥＥ１３９４機器３２７に状態変数の変化が発生した場合におけるソフトウエアの動作のシーケンスを示したものである。まず、ＡＶ／Ｃコマンド「Ｎｏｒｔｉｆｙ」を受け付けているＩＥＥＥ１３９４機器３２７に状態変数の変化が発生した場合、ＩＥＥＥ１３９４機器３２７はステップＳ３８０にて、ＡＶ／Ｃレスポンス「Ｎｏｒｔｉｆｙ」を、ＩＥＥＥ１３９４バス制御処理３２４に対して送信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／Ｃレスポンス「Ｎｏｒｔｉｆｙ」を、ステップＳ３８１にてレスポンスの送信元であるＩＥＥＥ１３９４機器３２７に対応したＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、自身がエミュレートしているＩＥＥＥ１３９４機器３２７の次の状態変数の変化に備えて、ステップＳ３８２にて、ＩＥＥＥ１３９４バス制御処理３２４に再度ＡＶ／Ｃコマンド「Ｎｏｒｔｉｆｙ」を送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ＩＥＥＥ１３９４機器３２７に対し、ステップＳ３８３にて、ＡＶ／Ｃコマンド「Ｎｏｒｔｉｔｙ」を送信する。その後、ＵＰｎＰエミュレーション処理３２５は、ＩＥＥＥ１３９４バス制御処理３２４に対し、ＩＥＥＥ１３９４機器３２７の現在の状態を問い合わせるＡＶ／Ｃコマンド「Ｓｔａｔｕｓ」をステップＳ３８４にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ３８５にて、ＩＥＥＥ１３９４機器３２７に対し、ＡＶ／Ｃコマンド「Ｓｔａｔｕｓ」を送信する。ＩＥＥＥ１３９４機器３２７は、ＡＶ／Ｃコマンド「Ｓｔａｔｕｓ」に応じて、現在の状態をＡＶ／Ｃレスポンス「Ｓｔａｔｕｓ」として、ステップＳ３８６にて、ＩＥＥＥ１３９４バス制御処理３２４に対して送信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／Ｃレスポンス「Ｓｔａｔｕｓ」を、ステップＳ３８７にてレスポンスの送信元であるＩＥＥＥ１３９４機器３２７に対応したＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、ＡＶ／Ｃレスポンス「Ｓｔａｔｕｓ」をＵＰｎＰのイベントメッセージ「ＮＯＲＴＩＦＹ」に変換し、ＧＥＮＡを用いてステップＳ３８８にてＵＰｎＰコントロールポイント３１０に送信する。これにより、ＵＰｎＰコントロールポイント３１０は、ＵＰｎＰエミュレーション処理３２５を介し、サブスクライブ要求を行ったＩＥＥＥ１３９４機器３２７の状態変化を知ることが可能となる。

＜ＵＭＵ内のソフトウェアの動作＞
次に、第２７図に示したコンテンツの再生フローの各ステップにおける、第２６図に示したＵＭＵ４２内のソフトウェアの実際の動作について説明する。

最初に、コンテンツの検索Ｓ３１１におけるソフトウェアの動作について説明する。第３７図は、コンテンツの検索Ｓ３１１におけるソフトウェアの動作のシーケンスを示した図である。まず、ステップＳ４００にて、ＵＰｎＰコントロールポイント３１０はＳＯＡＰを用いて、ＵＰｎＰエミュレーション処理３２５に対し、「Ｂｒｏｗｓｅ」、または「Ｓｅｒａｃｈ」アクション要求を含んだメッセージを送信する。ＩＥＥＥ１３９４機器に対応して既に起動されているＵＰｎＰエミュレーション処理３２５は、ＵＰｎＰスタック３２１を介し、送信されたメッセージを受信する。メッセージを受信したＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃコマンドとの対応表を用い、ＵＰｎＰのサービスである「Ｂｒｏｗｓｅ」、または「Ｓｅｒａｃｈ」アクションをＡＶ／Ｃコマンドの「ＲＥＡＤＤＥＳＣＲＩＰＴＯＲ」に変換し、ステップＳ４０１にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ４０２にて、ＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４機器３２７にＡＶ／Ｃコマンド「ＲＥＡＤＤＥＳＣＲＩＰＴＯＲ」を送信する。このＡＶ／Ｃコマンドを受信したＩＥＥＥ１３９４機器３２７は、Ｓ４０３にて、ＩＥＥＥ１３９４スタックを介し、自身の有するコンテンツの階層構造、転送プロトコルデータ、データフォーマットの情報を含むＡＶ／ＣレスポンスをＩＥＥＥ１３９４バス制御処理３２４に返信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／ＣレスポンスをＳ４０４にて、ＡＶ／Ｃコマンドの送信元であるＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃレスポンスとの対応表を用いＵＰｎＰのレスポンスメッセージに変換し、Ｓ４０５にてＵＰｎＰスタック３２１を介し、ＵＰｎＰコントロールポイント３１０に送信する。このステップにより、ＵＰｎＰコントロールポイント３１０は、ＩＥＥＥ１３９４機器３２７の有するコンテンツの階層構造、転送プロトコルデータ、データフォーマットの情報を認識する。なお、前述のＡＶ／Ｃコマンド「ＲＥＡＤＤＥＳＣＲＩＰＴＯＲ」の発行は、実際には「ＲＥＡＤＤＥＳＣＲＩＰＴＯＲ」の前に「ＯＰＥＮＤＥＳＣＲＩＰＴＯＲ］」サブファンクション「ＲＥＡＤＯＰＥＮ」を実行し、「ＲＥＡＤＤＥＳＣＲＩＰＴＯＲ」の後に、「ＯＰＥＮＤＥＳＣＲＩＰＴＯＲ」サブファンクション「ＣＬＯＳＥ」を発行する一連の手続きを必要とする。また必要な情報によっては「ＲＥＡＤＤＥＳＣＲＩＰＴＯＲ」の代わりに「ＲＥＡＤＩＮＦＯＢＬＯＣＫ」コマンドを使用する場合や、それぞれの手続きの組み合わせを使用する場合もある。

次に、プロトコルデータ・フォーマットチェックＳ３１２におけるソフトウェアの動作について説明する。第３８図は、プロトコルデータ・フォーマットチェックＳ３１２におけるソフトウェアの動作のシーケンスを示した図である。まず、ステップＳ４１０にて、ＵＰｎＰコントロールポイント３１０はＳＯＡＰを用いて、ＵＰｎＰエミュレーション処理３２５に対し、「ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ」アクション要求を含んだメッセージを送信する。ＩＥＥＥ１３９４機器に対応して既に起動されているＵＰｎＰエミュレーション処理３２５は、ＵＰｎＰスタック３２１を介し、送信されたメッセージを受信する。メッセージを受信したＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃコマンドとの対応表を用いＵＰｎＰのサービスである「ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ」アクションをＡＶ／Ｃコマンドの「ＩＮＰＵＴＰＬＵＧＳＩＧＮＡＬＦＯＲＭＡＴ」のｓｔａｔｕｓに変換し、ステップＳ４１１にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ４１２にて、ＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４機器３２７にＡＶ／Ｃコマンド「ＩＮＰＵＴＰＬＵＧＳＩＧＮＡＬＦＯＲＭＡＴ」のｓｔａｔｕｓを送信する。このＡＶ／Ｃコマンドを受信したＩＥＥＥ１３９４機器３２７は、Ｓ４１３にて、ＩＥＥＥ１３９４スタックを介し、自身がサポートしている転送プロトコルデータ、データフォーマットの情報を含むＡＶ／ＣレスポンスをＩＥＥＥ１３９４バス制御処理３２４に返信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／ＣレスポンスをＳ４１４にて、ＡＶ／Ｃコマンドの送信元であるＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃレスポンスとの対応表を用いＵＰｎＰのレスポンスメッセージに変換し、Ｓ４１５にてＵＰｎＰスタック３２１を介し、ＵＰｎＰコントロールポイント３１０に送信する。これにより、ＵＰｎＰコントロールポイント３１０は、ＩＥＥＥ１３９４機器３２７のサポートしている転送プロトコルデータ、データフォーマットの情報を認識する。

次に、サーバ、レンダラの準備Ｓ３１３におけるソフトウェアの動作について説明する。第３９図は、サーバ、レンダラの準備Ｓ３１３におけるソフトウェアの動作のシーケンスを示した図である。まず、ステップＳ４２０にて、ＵＰｎＰコントロールポイント３１０はＳＯＡＰを用いて、ＵＰｎＰエミュレーション処理３２５に対し、「ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ」アクションを含んだメッセージを送信する。ＩＥＥＥ１３９４機器に対応して既に起動されているＵＰｎＰエミュレーション処理３２５は、ＵＰｎＰスタック３２１を介し、送信されたメッセージを受信する。メッセージを受信したＵＰｎＰエミュレーション処理３２５は、Ｓ４２１にてＩＥＥＥ１３９４バス制御処理３２４に対しコネクション要求を行う。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ４２２にて、ＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４機器３２７に対し、ｌｏｃｋトランザクションによるプラグの設定要求を送信する。このｌｏｃｋトランザクションを受信したＩＥＥＥ１３９４機器３２７は、物理的なコネクションを生成する。コネクションの生成後、Ｓ４２３にてｌｏｃｋトランザクションによるプラグの設定結果を、ＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、コネクション完了回答をＳ４２４にて、ＡＶ／Ｃコマンドの送信元であるＵＰｎＰエミュレーション処理３２５に送信する。コネクション完了回答を受信したＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃコマンドとの対応表を用いＵＰｎＰのサービスである「ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ」アクションをＡＶ／Ｃコマンドの「ＣＯＮＮＥＣＴＡＶ」に変換し、ステップＳ４２５にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ４２６にて、ＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４機器３２７に「ＣＯＮＮＥＣＴＡＶ」を送信する。このＡＶ／Ｃコマンドを受信したＩＥＥＥ１３９４機器３２７は、実際に、自身と他のデバイスと間でデータの送受信が可能となるコネクション生成した後、ＩＥＥＥ１３９４スタックを介し、Ｓ４２７にて生成結果を含むＡＶ／ＣレスポンスをＩＥＥＥ１３９４バス制御処理３２４に返信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／ＣレスポンスをＳ４２８にて、ＡＶ／Ｃコマンドの送信元であるＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃレスポンスとの対応表を用いＵＰｎＰのレスポンスメッセージに変換し、Ｓ４２９にてＵＰｎＰスタック３２１を介し、ＵＰｎＰコントロールポイント３１０に送信する。これにより、ＩＥＥＥ１３９４機器３２７に対してコンテンツを送受信することが可能となる。

次に、コンテンツの選択Ｓ３１４におけるソフトウェアの動作について説明する。第４０図は、コンテンツの選択Ｓ３１４におけるソフトウェアの動作のシーケンスを示した図である。まず、次の再生Ｓ３１５にて再生するコンテンツをユーザが選択する。その後、ステップＳ４３０にて、ＵＰｎＰコントロールポイント３１０はＳＯＡＰを用いて、ＵＰｎＰエミュレーション処理３２５に対し、「ＳｅｔＴｒａｎｐｏｒｔＵＲＩ」アクション要求を含んだメッセージを送信する。ＩＥＥＥ１３９４機器に対応して既に起動されているＵＰｎＰエミュレーション処理３２５は、ＵＰｎＰスタック３２１を介し、送信されたメッセージを受信する。メッセージを受信したＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃコマンドとの対応表を用いＵＰｎＰのサービスである「ＳｅｔＴｒａｎｐｏｒｔＵＲＩ」アクションをＡＶ／Ｃコマンドの「ＳＥＴＰＬＵＧＡＳＳＯＣＩＡＴＩＯＮ」に変換し、ステップＳ４３１にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ４３２にて、ＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４機器３２７に「ＳＥＴＰＬＵＧＡＳＳＯＣＩＡＴＩＯＮ」を送信する。このＡＶ／Ｃコマンドを受信したＩＥＥＥ１３９４機器３２７は、Ｓ４３３にて、ＩＥＥＥ１３９４スタックを介し、選択されたコンテンツを含むＡＶ／ＣレスポンスをＩＥＥＥ１３９４バス制御処理３２４に返信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／ＣレスポンスをＳ４３４にて、ＡＶ／Ｃコマンドの送信元であるＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃレスポンスとの対応表を用いＵＰｎＰのレスポンスメッセージに変換し、Ｓ４３５にてＵＰｎＰスタック３２１を介し、ＵＰｎＰコントロールポイント３１０に送信する。これにより、ＵＰｎＰコントロールポイント３１０は、ユーザが選択したコンテンツを認識する。

次に、再生Ｓ３１５におけるソフトウェアの動作について説明する。第４１図は、再生Ｓ３１５におけるソフトウェアの動作のシーケンスを示した図である。まず、ステップＳ４４０にて、ＵＰｎＰコントロールポイント３１０はＳＯＡＰを用いて、ＵＰｎＰエミュレーション処理３２５に対し、「Ｐｌａｙ」アクション要求を含んだメッセージを送信する。ＩＥＥＥ１３９４機器３２７に対応して既に起動されているＵＰｎＰエミュレーション処理３２５は、ＵＰｎＰスタック３２１を介し、送信されたメッセージを受信する。メッセージを受信したＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃコマンドとの対応表を用いＵＰｎＰのサービスである「Ｐｌａｙ」アクションをＡＶ／Ｃコマンドの「ＰＬＡＹ」に変換し、ステップＳ４４１にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ４４２にて、ＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４機器３２７にＡＶ／Ｃコマンド「ＰＬＡＹ」を送信する。このＡＶ／Ｃコマンドを受信したＩＥＥＥ１３９４機器３２７は、コンテンツの再生を開始する。その後、Ｓ４４３にて、ＩＥＥＥ１３９４スタックを介し、コンテンツの再生を開始した情報を含んだＡＶ／ＣレスポンスをＩＥＥＥ１３９４バス制御処理３２４に返信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／ＣレスポンスをＳ４４４にて、ＡＶ／Ｃコマンドの送信元であるＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃレスポンスとの対応表を用いＵＰｎＰのレスポンスメッセージに変換し、Ｓ４４５にてＵＰｎＰスタック３２１を介し、ＵＰｎＰコントロールポイント３１０に送信する。これにより、ＵＰｎＰコントロールポイント３１０はＩＥＥＥ１３９４機器３２７において、コンテンツの再生が開始されたことを認識することが可能となる。

次に、音量・画質調整Ｓ３１６におけるソフトウェアの動作について説明する。第４２図は、音量・画質調整Ｓ３１６におけるソフトウェアの動作のシーケンスを示した図である。まず、ステップＳ４５０にて、ＵＰｎＰコントロールポイント３１０はＳＯＡＰを用いて、ＵＰｎＰエミュレーション処理３２５に対し、「ＳｅｔＶｏｌｕｍｅ」アクション要求を含んだメッセージを送信する。ＩＥＥＥ１３９４機器３２７に対応して既に起動されているＵＰｎＰエミュレーション処理３２５は、ＵＰｎＰスタック３２１を介し、送信されたメッセージを受信する。メッセージを受信したＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃコマンドとの対応表を用いＵＰｎＰのサービスである「ＳｅｔＶｏｌｕｍｅ」アクションをＡＶ／Ｃコマンドの「ＦＵＮＣＴＩＯＮＢＬＯＣＫ」に変換し、ステップＳ４５１にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ４５２にて、ＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４機器３２７にＡＶ／Ｃコマンド「ＦＵＮＣＴＩＯＮＢＬＯＣＫ」を送信する。このＡＶ／Ｃコマンドを受信したＩＥＥＥ１３９４機器３２７は、音量の調整を行う。その後、Ｓ４５３にて、ＩＥＥＥ１３９４スタックを介し、調整した音量に関する情報を含んだＡＶ／ＣレスポンスをＩＥＥＥ１３９４バス制御処理３２４に返信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／ＣレスポンスをＳ４５４にて、ＡＶ／Ｃコマンドの送信元であるＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃレスポンスとの対応表を用いＵＰｎＰのレスポンスメッセージに変換し、Ｓ４５５にてＵＰｎＰスタック３２１を介し、ＵＰｎＰコントロールポイント３１０に送信する。これにより、ＵＰｎＰコントロールポイント３１０はＩＥＥＥ１３９４機器３２７において、音量が調整されたことを認識することが可能となる。

最後に、転送完了Ｓ３１６におけるソフトウェアの動作について説明する。第４３図は、転送完了Ｓ３１６におけるソフトウェアの動作のシーケンスを示した図である。まず、ステップＳ４６０にて、ＵＰｎＰコントロールポイント３１０はＳＯＡＰを用いて、ＵＰｎＰエミュレーション処理３２５に対し、「ＴｒａｎｓｆｅｒＣｏｍｐｌｅｔｅ」アクション要求を含んだメッセージを送信する。ＩＥＥＥ１３９４機器３２７に対応して既に起動されているＵＰｎＰエミュレーション処理３２５は、ＵＰｎＰスタック３２１を介し、送信されたメッセージを受信する。メッセージを受信したＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃコマンドとの対応表を用いＵＰｎＰのサービスである「ＴｒａｎｓｆｅｒＣｏｍｐｌｅｔｅ」アクションをＡＶ／Ｃコマンドの「ＤＩＳＣＯＮＮＥＣＴＡＶ」に変換し、ステップＳ４６１にてＩＥＥＥ１３９４バス制御処理３２４に送信する。ＩＥＥＥ１３９４バス制御処理３２４は、ステップＳ４６２にて、ＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４機器３２７にＡＶ／Ｃコマンド「ＤＩＳＣＯＮＮＥＣＴＡＶ」を送信する。このＡＶ／Ｃコマンドを受信したＩＥＥＥ１３９４機器３２７は、自身のコネクションを解除する。その後、Ｓ４６３にて、ＩＥＥＥ１３９４スタックを介し、コネクションを解除した情報を含んだＡＶ／ＣレスポンスをＩＥＥＥ１３９４バス制御処理３２４に返信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／ＣレスポンスをＳ４６４にて、ＡＶ／Ｃコマンドの送信元であるＵＰｎＰエミュレーション処理３２５に送信する。コネクション解除回答を受信したＵＰｎＰエミュレーション処理３２５は、さらに物理的なコネクションを解除するため、コネクション終了要求をステップＳ４６５にてＩＥＥＥ１３９４バス制御処理３２４に送信する。コネクション終了要求を受信したＩＥＥＥ１３９４バス制御処理３２４は、Ｓ４６６にてＩＥＥＥ１３９４スタックを介し、ＩＥＥＥ１３９４機器３２７に対し、ｌｏｃｋトランザクションによるプラグの解除要求を送信する。このメッセージを受信したＩＥＥＥ１３９４機器３２７は、物理的なコネクションを解除する。その後、Ｓ４６７にて、ＩＥＥＥ１３９４スタックを介し、物理的なコネクションを解除した情報を含んだｌｏｃｋトランザクション応答をＩＥＥＥ１３９４バス制御処理３２４に返信する。ＩＥＥＥ１３９４バス制御処理３２４は、受信したＡＶ／ＣレスポンスをＳ４６８にて、ＡＶ／Ｃコマンドの送信元であるＵＰｎＰエミュレーション処理３２５に送信する。ＵＰｎＰエミュレーション処理３２５は、第３６図に示すＵＰｎＰのサービスとＡＶ／Ｃレスポンスとの対応表を用いＵＰｎＰのレスポンスメッセージに変換し、Ｓ４６９にてＵＰｎＰスタック３２１を介し、ＵＰｎＰコントロールポイント３１０に送信する。これにより、ＵＰｎＰコントロールポイント３１０は、ＩＥＥＥ１３９４機器３２７のコネクションが解除されたことを認識することが可能となる。

以上、説明した操作方法によれば、ＩＰネットワーク上のＵＰｎＰコントロールポイントが、ＩＥＥＥ１３９４ネットワーク上にあるＵＰｎＰの機能を有さないＩＥＥＥ１３９４機器を操作することが可能となる。すなわち、ＵＭＵ４２を用いることにより、ＩＥＥＥ１３９４ネットワーク上にあり、かつＵＰｎＰの機能を有さない映像情報装置４０ａ、４０ｂ等の装置を操作することが可能となる。また、本実施の形態で説明した操作方法によれば、ＵＰｎＰコントロールポイントが予めＩＥＥＥ１３９４ネットワークに接続されるＩＥＥＥ１３９４機器のユニット、サブユニットを認識しておく必要がないので、ＩＥＥＥ１３９４機器の追加、削除、及びＵＰｎＰコントロールポイントの追加、削除を容易に行うことができる。また、ＩＥＥＥ１３９４ネットワークがすでに構成されており、かつ、ＩＰネットワーク上にＵＰｎＰコントロールポイントが存在し、このＵＰｎＰコントロールポイントからＩＥＥＥ１３９４機器を操作したい場合、本実施の形態で説明したＵＭＵを用いれば、既存のＩＥＥＥ１３９４ネットワーク、ＩＰネットワークの構成を変更することなく操作が可能となる。すなわち、ＩＥＥＥ１３９４ネットワークで使用されるＡＶ／Ｃコマンドと、ＵＰｎＰのアクションの両者を理解、変換できるソフトウェアを搭載したＵＰｎＰコントロールポイントを用いる必要がない。

すなわち、本実施の形態で説明したＵＭＵを用いれば、新たなＬＳＩを搭載した機器を用いることなく、第１のネットワーク上にある機器から第２のネットワーク上にある機器を操作することが可能となる。つまり、互いの機器が、機器操作のためのコマンド体系がそれぞれ異なるネットワーク上にある場合でも、両者のコマンド体系を理解、変換可能なシステムＬＳＩを搭載した仲介機器を新たに設けることなく、互いのネットワーク上の機器を操作することが可能となる。

この発明は、以上説明したように構成されているので、以下に示すような効果を奏する。すなわち、機器に要求される仕様・機能が変わっても、仕様・機能変更の要求に対応したシステムＬＳＩを新たに開発する必要がなく、容易に機能の拡張・変更が可能な映像機器を提供することが可能となる。

第１図は、第１の実施の形態のユビキタス映像モジュールを用いた映像情報装置のネットワーク系統を示す図である。第２図は、第１の実施の形態のユビキタス映像モジュールのハードウェア構成を概念的に示す図である。第３図は、第１の実施の形態のユビキタス映像モジュールのソフトウェア構成を概念的に示す図である。第４図は、第１の実施の形態のユビキタス映像モジュールのバス型の接続図を示す図である。第５図は、第１の実施の形態のユビキタス映像モジュールのスター型の接続図を示す図である。第６図は、第１の実施の形態のユビキタス映像モジュールと映像情報装置とを組み合わせたシステムの構成例を示した図である。第７図は、第１の実施の形態の映像インターフェースを持つユビキタス映像モジュールと映像情報装置とを組み合わせたシステムの構成例を示した図である。第８図は、第１の実施の形態の外部ネットワーク接続端子を持つユビキタス映像モジュールと映像情報装置とを組み合わせたシステムの構成例を示した図である。第９図は、第１の実施の形態のユビキタス映像モジュールを監視レコーダシステムに使用した場合の構成例である。第１０図は、第１の実施の形態のユビキタス映像モジュールを監視レコーダシステムに使用した場合の他の構成例である。第１１図は、第１の実施の形態のユビキタス映像モジュールをＤＶＤ／ＨＤＤレコーダ７のシステムに適応した場合のソフトウエアブロックの構成を示す図である。第１２図は、第１の実施の形態のユビキタス映像モジュールのソフトウェアブロック構成を示す図である。第１３図は、第１の実施の形態のユビキタス映像モジュールを映像情報装置の機種ごとに適用する場合のソフトウェアブロック図である。第１４図は、第１の実施の形態のＩＰｖ６対応インターネット通信プロトコルミドルウェアのソフトウェアブロック構成を示す図である。第１５図は、第１の実施の形態のユニバーサルプラグアンドプレイミドルウェアを拡張した場合のソフトウェアブロック構成を示す図である。第１６図は、第１の実施の形態のユビキタス映像モジュールの撮像・表示部のソフトウェアブロック構成を示す図である。第１７図は、第１の実施の形態のユビキタス映像モジュールの映像配信蓄積ミドルウェアのソフトウェアブロック構成を示す図である。第１８図は、第１の実施の形態の映像情報装置のユビキタス映像モジュールのソフトウェアとソフトウェアとの関係を示した図である。第１９図は、第１の実施の形態のユビキタス映像モジュールと映像情報装置とがシステムレベルで透過的に接続されている状態を概念的に示す図である。第２０図は、第１の実施の形態のユビキタス映像モジュールと映像情報装置とがシステムレベルおよびＡＰＩレベルで透過的に接続されている状態を概念的に示す図である。第２１図は、第１の実施の形態のユビキタス映像モジュールを映像記録装置のシステムに適応した場合のソフトウエアブロックの構成を示す図である。第２２図は、第２の実施の形態のユビキタス映像モジュールとのモバイルアプリケーションユニットとを組み合わせたシステムの構成例を示す図である。第２３図は、第３の実施の形態の外部ネットワーク接続端子を持つユビキタス映像モジュールと映像情報装置とを組み合わせたシステムの構成例を示した図である。第２４図は、第３の実施の形態のユビキタス映像モジュールをＩＰネットワークに接続した接続形態を模式的に示した図である。第２５図は、ＵＰｎＰの規格に定められた一般的な動作ステップを示す図である。第２６図は、ＵＰｎＰのＡＶアーキテクチャを示す図である。第２７図は、ＵＰｎＰのＡＶアーキテクチャにおける、コンテンツの一般的な再生フローを示す図である。第２８図は、第３の実施の形態のユビキタス映像モジュール内のソフトウェア構成を示した図である。第２９図は、アドレッシングＳ３０１におけるソフトウェアの動作のシーケンスを示した図である。第３０図は、ディスカバリＳ３０２におけるシーケンスを示した図である。第３１図は、ディスカバリＳ３０２におけるシーケンスを示した図である。第３２図は、ディスクリプションＳ３０３におけるソフトウェアの動作のシーケンスを示した図である。第３３図は、コントロールＳ３０３におけるソフトウェアの動作のシーケンスを示した図である。第３４図は、イベンティングＳ３０５のソフトウェアの動作のシーケンスを示した図である。第３５図は、イベンティングＳ３０５のソフトウェアの動作のシーケンスを示した図である。第３６図は、ＵＰｎＰのサービスとＡＶ／Ｃコマンドとの対応表を示す図である。第３７図は、コンテンツの検索Ｓ３１１におけるソフトウェアの動作のシーケンスを示した図である。第３８図は、プロトコルデータ・フォーマットチェックＳ３１２におけるソフトウェアの動作のシーケンスを示した図である。第３９図は、サーバ、レンダラの準備Ｓ３１３におけるソフトウェアの動作のシーケンスを示した図である。第４０図は、コンテンツの選択Ｓ３１４におけるソフトウェアの動作のシーケンスを示した図である。第４１図は、再生Ｓ３１５におけるソフトウェアの動作のシーケンスを示した図である。第４２図は、音量・画質調整Ｓ３１６におけるソフトウェアの動作のシーケンスを示した図である。第４３図は、転送完了Ｓ３１６におけるソフトウェアの動作のシーケンスを示した図である。第４４図は、従来の映像情報装置の構成例を示す図である。第４５図は、従来の携帯電話装置の構成例を示す図である。

符号の説明

１：ネットワーク２：ＰＣ
３：データベース
４：ユビキタス映像モジュールユニット（ＵＭＵ）
５：ＵＭＵを用いたＤＴＶ６：デジタルＴＶ（ＤＴＶ）
７：ＤＶＤ／ＨＤＤレコーダ８：監視レコーダ
９：ＦＡ機器１０：携帯電話
１１：ＰＤＡ
１２：ユビキタス映像モジュール（ＭＵ）
１３ユビキタス映像モジュール用ＣＰＵ（ＵＭ−ＣＰＵ）
１４：内部バス１５：バス（ＢＵＳ）ブリッジ
１６：汎用バス（ＵＭ−ＢＵＳ１７：ハードウェアエンジン
１８：専用バス２１：グラフィックエンジン
２２：カメラエンジン２３：ＭＰＥＧ４エンジン
２４：コミュニケーションエンジン
２５：ミドルウェア
２６：ＪＡＶＡ（登録商標）仮想マシン
２７：組込みＬｉｎｕｘ３０：ターゲット
３１：システム側インターフェース（Ｓ−Ｉ／Ｆ）
３２：ユビキタス映像モジュール側インターフェース（Ｕ−Ｉ／Ｆ）
３３：ＬＡＮ３４：ネットワーク端末
３５：ＨＵＢ４０：映像情報装置
４２：ユビキタス映像モジュールユニット
４４：映像入力端子（ＵＶＩ）
４５：映像出力端子（ＵＶＯ）
４６：有線ＬＡＮ用の外部接続端子
４７：無線ＬＡＮ用の外部接続端子（アンテナ）
４８：外部接続用シリアルバス接続端子
５１：ＭｕｌｔｉｐｌｅＶｉｄｅｏＩ／Ｏ
５２：ＪＰＥＧ／ＪＰＥＧ２０００Ｃｏｄｅｃ
５３：ＭａｓｓＳｔｒａｇｅドライバ
５４：Ｃｏｒｅコントローラ
５５：組込みＬｉｎｕｘ
１００：ハードウェア層１０１：ＨＡＬ
１０２：組込みＬｉｎｕｘ１０３：Ｘ−Ｗｉｎｄｏｗ（登録商標）
１０４：ＩＰｖ６対応インターネット通信プロトコルミドウェア
１０５：ユニバーサルプラグ＆プレイミドルウェア
１０６：ＭＰＥＧｘ画像配信蓄積プロトコルミドルウェア
１０７：撮像＆表示(グラフィック)ミドルウェア
１０８：ＪＡＶＡ（登録商標）仮想マシン（ＶＭ）
１０９：ＵＩアプリケーションワークフレーム
１１０：機種別アプリケーション
１１１：ユビキタス映像モジュールハードウェア部
１１２：ユビキタス映像モジュールミドルウェア部
１２０：携帯ＨＡＬ１２１：カー携帯ＨＡＬ
１２２：カーナビＨＡＬ１２３：ＡＶ家電ＨＡＬ
１２４：監視ＨＡＬ１２５：携帯ＡＰＰ
１２６：カー携帯ＡＰＰ１２７：カーナビＡＰＰ
１２８ＡＶ家電ＡＰＰ１２９：監視ＡＰＰ
１３０：組込みＯＳＬｉｎｕｘ
１３１：Ｅｔｈｅｒｎｅｔ（登録商標）ドライバ
１３２：無線ＬＡＮドライバ１３３：１３９４ドライバ
１３４：ＰＡＬ１３５：１３９４トランザクション
１３６：ＡＶ系ミドルウェア１３７：ＩＰプロトコルスタック
１３８：ＴＣＰｏｒＵＤＰスタック
１３９：ＨＴＴＰスタック１４０：ＳＯＡＰ／ＸＭＬスタック
１４１：ＵＰｎＰスタック
１４２：統合ミドルウェア１４３：アプリケーション
１４４：Ｗｅｂサーバ１４５：ＷｅｂサービスＩ／Ｆ
１４６：Ｗｅｂサービスアプリケーション
１５０：Ｅｔｈｅｒｎｅｔ（登録商標）
１５１：無線ＬＡＮ１５２：ＩＥＥＥ１３９４
１５３：Ｂｌｕｅｔｏｏｔｈドライバ
１５４：特定小電力無線１５５：ＰＬＣ
１５６：ＩＰ１５７：ＴＣＰ＆ＵＰ
１５８：白物家電系ネットワークミドルウェア
１５９：ＴＣＰ＆ＵＤＰ１６０：ＡＶ系ミドルウェア
１６１：ＩＰ１６２：ＴＣＰ＆ＵＤＰ
１６３：ＵＰｎＰ１６４：統合ミドルウェア
１６５：アプリケーション１７１：カメラ
１７２：ＬＣＤ
１７３：２Ｄグラフィッスエンジン
１７４：３Ｄグラフィッスエンジン
１７５：組込みＬＩＮＵＸ１７６：３Ｄグラフィックサーバ
１７７：３Ｄライブラリ１７８：Ｘサーバ
１７９：Ｘライブラリ１８０：カメラドライバ
１８１：カメラライブラリ１８２：アプリケーション
１８３：ＪＡＶＡ（登録商標）ＶＭ
１８４：ＵＩアプリケーションフレームワーク
１８５：撮像・表示部ミドルウェア
１８６：カメラ入力された画像データ
１９０：ＴＳブロック１９１：通信ブロック
１９２：ＩＰブロック
１９３：ＰＳ（プログラム・ストリーム）ブロック
１９４：メディアゲートウェイ・レイヤ
１９５：トランスコーダ・レイヤ
１９６：メディア・プレゼンテーション・レイヤ
２０１：ＳＹＳ−ＣＰＵ２０２：映像信号処理（ＶＳＰ）
２０３：ＲＯＭ２０４：ＲＡＭ
２０５：映像入力信号２０６：映像情報装置
２０７：ＦＰ（前段処理部）２０８：システムＬＳＩ
２０９：ＢＰ（後段処理部）
２１０：ビデオインターフェース（Ｖ−Ｉ／Ｆ）
２１１：表示ユニット２１２：表示ドライバ
２１３：表示デバイス２２０：映像情報装置ハードウェア
２２１：映像情報装置オペレーティングシステムＬｉｎｕｘ
２２２：映像情報装置ミドルウェア
２２３：映像情報装置ＪＡＶＡ（登録商標）仮想マシン
２２４：映像情報装置ＵＩアプリケーションフレームワーク
２２５：映像情報装置アプリケーション
２２６：映像情報装置アプリケーション
２２７：映像情報装置アプリケーション
３１０：ＵＰｎＰＣｏｎｔｒｏｌＰｏｉｎｔ
３１１：ＭｅｄｉａＳｅｒｖｅｒ
３１２：ＭｅｄｉａＲｅｎｄｅｒｅｒ
３１３：ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ
３１４：ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒ
３１５：ＡＶＴｒａｎｓｐｏｒｔ
３１６：ＲｅｎｄｅｒｉｎｇＣｏｎｔｒｏｌ
３２０：ＯｐｅｒａｔｉｏｎＳｙｓｔｅｍ
３２１：ＵＰｎＰスタック３２２：ＩＥＥＥ１３９４スタック
３２３：ＩＰアドレスマネージャ３２４：ＩＥＥＥ１３９４バス制御処理
３２５：ＵＰｎＰエミュレーション処理
３２６：デリゲーションマネージャ
３２７：ＩＥＥＥ１３９４機器

Claims

第１のネットワークに接続され、前記第１のネットワークに接続される機器と通信を行う第一の通信手段と、
第２のネットワークに接続され、前記第２のネットワークに接続される機器と通信を行う第二の通信手段と、
前記第１のネットワークにおける識別子を出力する識別子管理手段と
を備え、
前記第２のネットワークに接続されている機器に対応するプログラムを起動し、前記プログラムと前記識別子とを対応付けること
を特徴とするネットワーク接続装置。
前記第一の通信手段は、前記第１のネットワークに接続される機器に対し、前記プログラムと対応付けられる前記識別子を送信すること
を特徴とする請求項１に記載のネットワーク接続装置。
前記第１のネットワークのコマンドと前記第２のネットワークのコマンドとの対応関係を取得する対応関係取得手段を備え、
前記第一の通信手段は、前記第１のネットワークに接続される機器から送信される前記識別子へのコマンドを受信し、
前記識別子に対応付けられた前記プログラムは、前記対応関係取得手段を用いて、前記コマンドを前記第２のネットワークにおけるコマンドに変換し、
前記第二の通信手段は、前記プログラムに対応する機器に、前記変換後のコマンドを送信すること
を特徴する請求項１又は２に記載のネットワーク接続装置。
前記第二の通信手段は、前記第２のネットワークに接続されている機器から送信されるコマンド実行の結果を受信し、
前記機器に対応する前記プログラムは、対応関係取得手段を用いて、前記コマンド実行の結果を前記第１のネットワークにおけるコマンド実行の結果に変換し、
前記第一の通信手段は、前記コマンドを送信した前記第１のネットワークに接続されている機器に対し、前記コマンド実行の結果を送信すること
を特徴する請求項３に記載のネットワーク接続装置。
第１のネットワークに接続され、前記第１のネットワークに接続される機器と通信を行う第一の通信手段と、
第２のネットワークに接続され、前記第２のネットワークに接続される機器と通信を行う第二の通信手段と
前記第１のネットワークにおける識別子を出力する識別子管理手段と
を備え、
前記第２のネットワークに接続される機器と、前記識別子とを対応付けること
を特徴とするネットワーク接続装置。
前記第１のネットワークは、ＵＰｎＰネットワークであり、
前記第２のネットワークは、ＩＥＥＥ１３９４ネットワークであること
を特徴する請求項１から５のいずれか１項に記載のネットワーク接続装置。
前記識別子は、ＤＨＣＰサーバから付与された識別子、または、ＡｕｔｏＩＰにて取得した識別子であること
を特徴とする請求項６に記載のネットワーク接続装置。
前記第２のネットワークに接続する接続手段を備え、
請求項１から７に記載のネットワーク接続装置と通信可能なこと
を特徴とする映像情報機器。
前記第１のネットワークに接続する接続手段を備え、
請求項１から７に記載のネットワーク接続装置と通信可能なこと
を特徴とする情報送受信機器。
第１のネットワークに接続する第一のネットワーク接続ステップと、
第２のネットワークに接続する第二のネットワーク接続ステップと、
前記第２のネットワークに接続されている機器に対応するプログラムを起動し、前記プログラムと前記識別子とを対応付ける識別子対応ステップと
を備えることを特徴とするネットワーク接続方法。
前記第１のネットワークに接続される機器に対し、前記識別子を送信する送信ステップを備えること
を特徴とする請求項１０に記載のネットワーク接続方法。
前記第１のネットワークに接続される機器から前記識別子へのコマンドを受信する第一の受信ステップと、
前記第１のネットワークのコマンドと前記第２のネットワークのコマンドとの対応関係を取得し、前記取得した関係を参照して、前記受信したコマンドを前記第２のネットワークにおけるコマンドに変換する第一のコマンド変換ステップと、
前記識別子に対応する前記第２のネットワークに接続されている機器に、前記変換後のコマンドを送信する第一の送信ステップと
を備えることを特徴とする請求項１０又は１１に記載のネットワーク接続方法。
前記第２のネットワークに接続されている機器から送信されるコマンド実行の結果を受信する第二の受信ステップと、
前記取得した関係を参照して前記コマンド実行の結果を前記第１のネットワークにおけるコマンド実行の結果に変換する第二のコマンド変換ステップと、
前記コマンドを送信した前記第１のネットワークに接続されている機器に対し、前記コマンド実行の結果を送信する第二の送信ステップと
を備えることを特徴する請求項１２に記載のネットワーク接続方法。
第１のネットワークに接続する第一のネットワーク接続ステップと、
第２のネットワークに接続する第二のネットワーク接続ステップと、
前記第２のネットワークに接続される機器と、前記第１のネットワークにおける識別子とを対応付ける識別子対応ステップと
を備えるネットワーク接続方法。
前記第１のネットワークは、ＵＰｎＰネットワークであり、
前記第２のネットワークは、ＩＥＥＥ１３９４ネットワークであること
を特徴する請求項１０から１４のいずれか１項に記載のネットワーク接続方法。
第１のネットワークに接続する第一のネットワーク接続ステップと、
第２のネットワークに接続する第二のネットワーク接続ステップと、
前記第２のネットワークに接続されている機器に対応するプログラムを起動し、前記プログラムと前記識別子とを対応付ける識別子対応ステップと
を備えることを特徴とするネットワーク接続プログラム。