通信装置および通信制御方法
【課題】コンテンツ再生機の例えばファイル操作といった既存の機能を利用することで汎用性を確保しつつ「ネットワーク機器連動コンテンツ」を実現する
【解決手段】所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との両方と通信を行う通信装置において、前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供するファイル構成提供手段と、前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段と、前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段と、を備える。
【解決手段】所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との両方と通信を行う通信装置において、前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供するファイル構成提供手段と、前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段と、前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との通信を制御する通信装置および通信制御方法に関する。
【背景技術】
【０００２】
近年のコンテンツの多様化により、映像や音声などのメディアを単に再生するだけでなく、アプリケーション的な処理コードを含むようなコンテンツが登場してきている。例えばWebコンテンツや放送コンテンツには、従来の映像や音声などのメディアデータに加えて、ページ記述言語やスクリプト言語などによるアプリケーション処理記述が含まれていることがある。
【０００３】
従来のアプリケーション処理記述としては例えば、その処理を実行するコンテンツ再生機に取り付けられた記憶装置へのファイルの書き込みや読み出しといったものがあった。
【０００４】
一方、コンテンツに付随するこのようなアプリケーション処理記述で、近年発展しているホームネットワーク機器（例えば白物家電や、AV機器、おもちゃなどでネットワークインタフェースを備えるもの）を制御したいというニーズが現れ始めている。これは例えば、コンテンツとしては冬の場面を映像として表示し、同時にネットワーク対応エアコンに部屋の温度を下げさせるなどといったかたちである。
【０００５】
このような「ネットワーク機器連動コンテンツ」を実現させるための仕組みがいくつか提案されている。
【０００６】
例えば特許文献１では、SMIL（Synchronized Multimedia Integration Language）と呼ばれる記述言語を一部拡張し、映像などのメディアとネットワーク機器との連携動作を記述し、コンテンツ再生機にてその記述に従って機器を制御する機構が提案されている。
【特許文献１】特開２００４−３４１７３６公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
特許文献１では、制御対象となる全てのネットワーク機器およびコンテンツ再生機が、Jini（登録商標、以下同様）やRendezvous（登録商標、以下同様）などの共通の制御プロトコルによる通信機能を備えているとしている。
【０００８】
しかしながら制御プロトコルと対象製品は、例えばUPnP（登録商標、以下同様）対応AV機器、ECHONET（登録商標、以下同様）対応白物家電、独自プロトコルにより制御されるおもちゃなど、様々である。また、今後も新たな制御プロトコルが現れることも十分考えられる。
【０００９】
つまり、特許文献１の技術は汎用性に欠けている。
【００１０】
本発明は、コンテンツ再生機の例えばファイル操作といった既存の機能を利用することで汎用性を確保しつつ「ネットワーク機器連動コンテンツ」を実現することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との両方と通信を行う通信装置において、前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供するファイル構成提供手段と、前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段と、前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段と、
を備えることを特徴とする通信装置を提供する。
【発明の効果】
【００１２】
コンテンツ再生機が一般に備えているストレージ操作機能を用いてネットワーク機器の様々な機能を制御することができる。その結果、「ネットワーク機器連動コンテンツ」を実現することができる。
【発明を実施するための最良の形態】
【００１３】
（第１の実施の形態）
図１は、本実施の形態のシステム構成の概念図である。
【００１４】
コンテンツ再生機１００は、例えば放送波アンテナに接続する放送デコーダや、インターネットに接続する有線ネットワークIF（インタフェース）１０９、無線ネットワークに接続する無線ネットワークIF１０８などを備える。それらを通じて、例えば放送波を通じて提供される放送コンテンツや、インターネットを通じて提供されるWebコンテンツなどといった、後述するコンテンツ情報を取得する。
【００１５】
コンテンツ再生機１００はさらに、DVDドライブ１０４やメモリカードスロット１０５などのメディアドライブや、USBIF１０６などの外部装置IFを備える。それぞれ、対応する各種リムーバブルメディアからコンテンツを取得する。
【００１６】
コンテンツ再生機１００は、取得したコンテンツを、コントロールパネル１０７から入力されるユーザの指示に従って再生する。またユーザは例えば、どのコンテンツソース（放送デコーダ、有線／無線ネットワークIF、メディアドライブや外部装置IF）から、再生すべきコンテンツを取得するかを、コントロールパネル１０７で選択する。
【００１７】
再生したコンテンツは例えばディスプレイ１０２やヘッドホン１０３といった再生デバイスへ送出され、ユーザへ提供される。
【００１８】
USBIF１０６には制御デバイスとしてのUSB通信機１０００が接続される。
【００１９】
USB通信機１０００はコンテンツ再生機１００からはリムーバブルメディアとして認識され、例えば書き込みや読み出しといった、ストレージデバイスへの命令を受け付ける。USB通信機１０００は人形２０００と、IrDA規格に則った赤外線通信を行う。USB通信機１０００は、コンテンツ再生機１００から受け付けたストレージデバイスへの命令を、人形２０００の制御命令に変換して人形２０００へ送信する。またUSB通信機１０００は、人形２０００から送信されたデータを受信して、コンテンツ再生機１００に対してリムーバブルディスク内のファイルとして提供する。
【００２０】
ネットワーク機器としての人形２０００は、USB通信機１０００と赤外線通信を行う。人形２０００はUSB通信機１０００から受信する動作要求に応じて動き、状態取得要求に応じて自らの状態を返答する。
【００２１】
本実施の形態におけるコンテンツ情報とは、従来一般に言われてきた映像や音声を表すメディアデータのみを指すものではない。本実施の形態におけるコンテンツ情報は、メディアデータに加えて、後述するアプリケーション処理記述データをも含むものである。
【００２２】
アプリケーション処理記述データは例えばMacromedia Flash（登録商標、以下同様）形式（SWF形式）、JavaScript（登録商標、以下同様）形式、ECMAScript形式などといったスクリプト言語で記述される。近年のWebコンテンツや放送コンテンツに見られるように，これらはHTML（Hyper Text Markup Language）やBML（Broadcast Markup Language）形式のマークアップ言語で記述したファイルに埋め込まれて提供される
アプリケーション処理記述データのなかには、人形２０００の状態を取得することを意図した命令が、例えばストレージデバイスからデータ読み出し命令として含まれる。また、人形２０００への動作要求を意図した命令が、例えばストレージデバイスへのデータ書き込み命令として含まれる。
【００２３】
図２はコンテンツ再生機１００のブロック図である。
【００２４】
コンテンツ再生機１００は、DVDドライブ１０４、メモリカードスロット１０５、USBIF１０６、コントロールパネル１０７、無線ネットワークIF１０８、有線ネットワークIF１０９、放送デコーダ１１０、外部入出力管理部１１１、アプリケーション処理記述解釈部１１２、コンテンツ再生部１１３、グラフィックIF１１４、サウンドIF１１５、HDD（ハード ディスク ドライブ）１１６を備える。
【００２５】
DVDドライブ１０４は、DVDからコンテンツ情報を取得する。
【００２６】
メモリカードスロット１０５は、挿入されるメモリカードからコンテンツ情報を取得する。
【００２７】
USBIF１０６は、USBホスト機能を有し、USBペリフェラル機能を有する他の機器と接続するIFである。USBIF１０６は例えば、USBマスストレージクラスに対応するストレージペリフェラルと接続してコンテンツ情報を取得する。（なお、USB2.0で規定されたUSB On-The-Go機能によれば、USBIF１０６がホストに限るものではない）
無線ネットワークIF１０８は例えば、ＩＥＥＥ８０２．１１で規定される無線ＬＡＮ仕様に準拠するIFである。無線ネットワークIF１０８は、無線ネットワークを通じてコンテンツ情報を取得する。
【００２８】
有線ネットワークIF１０９は例えば、ＩＥＥＥ８０２．３で規定される有線ＬＡＮ仕様に準拠するIFである。有線ネットワークIF１０９は、有線ネットワークを通じてコンテンツ情報を取得する。
【００２９】
放送デコーダ１１０は例えば、ARIB STDで規定されるデジタル放送規格に準拠する受信デバイスである。放送デコーダ１１０は、放送波をデコードしてコンテンツ情報を取得する。
【００３０】
HDD１１６は、コンテンツ再生機１００に固定される記憶装置で、アプリケーション処理記述解釈部１１２やコンテンツ再生部１１３の処理で用いる情報の一部を記憶する。
【００３１】
コントロールパネル１０７は、ユーザのコンテンツソース選択指示が入力される。
【００３２】
外部入出力管理部１１１は、DVDドライブ１０４、メモリカードスロット１０５、USBIF１０６、コントロールパネル１０７、無線ネットワークIF１０８、有線ネットワークIF１０９、放送デコーダ１１０、HDD１１６らに対して、それぞれに対応したデータの読み込みおよび書き出しの動作の制御を行う。
【００３３】
アプリケーション処理記述解釈部１１２は、コンテンツ情報からアプリケーション処理記述データを抽出して解釈する。このようなアプリケーション処理記述解釈部１１２の機能は、例えばスクリプト言語がJavaScriptである場合は、オペレーティングシステム（OS）やそれに対応したJavaScriptインタプリタなどで実現することができる。
【００３４】
アプリケーション処理記述解釈部１１２のOSはUSBをサポートしており、そのOSのファイルシステムに則ってUSB通信機１０００のファイルにアクセスする。
【００３５】
コンテンツ情報に記述されるファイルアクセスコマンドは例えば、ドライブ識別子と、そのドライブに記憶されているファイルの識別子とを含む。また、そのファイルに書き込むべき内容を含んでもよい。アプリケーション処理記述解釈部１１２はファイルアクセスコマンドに従って、外部入出力管理部１１１およびUSBIF１０６を介して、USBIF１０６に接続するUSBマスストレージクラス対応のデバイスに記憶されているように見えているデータファイルへのアクセスを行う。また、アプリケーション処理記述解釈部１１２は、コンテンツ情報からメディアデータを抽出してコンテンツ再生部１１３へ提供する。
【００３６】
コンテンツ再生部１１３は、メディアデータをデコードして、映像信号を生成してグラフィックIF１１４を介してディスプレイ１０２へ出力する。またコンテンツ再生部１１３は、メディアデータをデコードして、音声信号を生成してサウンドIF１１５を介してヘッドホン１０３へ出力する。
【００３７】
図３はUSB通信機１０００のブロック図である。
【００３８】
USB通信機１０００は、USBIF１００１、プロトコル変換部１００２、通信部１００３、記憶部１００４を備える。
【００３９】
USBIF１００１は、USBマスストレージクラスに対応するストレージペリフェラルとして、外部USBホスト装置とデータの通信を行う（本実施の形態では外部USBホスト装置はコンテンツ再生機１０００である）。USBIF１００１は、この通信で受信したデータを、記憶装置と通信するためのプロトコル（例えばＡＴＡ方式やＳＣＳＩ方式など）で出力する。また、外部USBホスト装置との通信において送信するデータを、記憶装置と通信するためのプロトコルで取得する。すなわち、USBIF１００１は、従来のUSBマスストレージクラス対応IFを流用してもよい。
【００４０】
プロトコル変換部１００２はUSBIF１００１に対して記憶装置と通信するためのプロトコルで通信を行う。本実施の形態のプロトコル変換部１００２は例えば、その動作をハードウェア（例えばASIC（Application SpecIFic Integrated Circuit）やFPGA（Field Programmable Gate Array））で実現してもよい。
【００４１】
プロトコル変換部１００３は、この通信で受信したデータを、記憶部１００４へ書き込む。またプロトコル変換部１００２は、この通信で受信したデータを、人形２０００の動作を制御する動作制御データに変換して通信部１００３へ渡す。さらに、プロトコル変換部１００２は、通信部１００３から受け取ったデータを変換し、記憶装置と通信するためのプロトコルでUSBIF１００１へ送り、かつ記憶部１００４へ書き込む。
【００４２】
本実施の形態のプロトコル変換部１００２は、USBIF１００１からは、コンテンツ再生機１００のOSがサポートするファイルシステムフォーマットであり、読み取り専用属性のstatus.txtと、書き込み可能属性のcontrol.txtとの２つのテキストファイルが記憶されている記憶装置であるよう認識される。つまり、OSのファイルシステムがドライブ内のフォルダ／ファイル構成を取得するためにアクセスするアドレスの値として、固定的に返り値を返す。これは例えばLUT（ルックアップテーブル）等で実現することができる。プロトコル変換部１００２は、これら２つのファイル以外に新たなファイルを書き込む命令は拒否する。またプロトコル変換部１００２は、これら２つのファイルの属性変更を拒否する。
【００４３】
通信部１００３は、人形２０００と、例えばIrDA（登録商標、以下同様）規格に則った赤外線通信を行う。
【００４４】
図４は人形２０００のブロック図である。
【００４５】
人形２０００は、通信部２００１、人形動作制御部２００２、踊り用アクチュエータ２００３、話し用アクチュエータ２００４を備える。
【００４６】
通信部２００１は、USB通信機１０００の通信部１００３と、例えばIrDA規格に則った赤外線通信を行う。通信部２００１は、受信するデータを人形動作制御部２００２へ渡す。また、人形動作制御部２００２から受け取るデータをUSB通信機１０００へ送信する。
【００４７】
踊り用アクチュエータ２００３および話し用アクチュエータ２００４は人形動作制御部２００２にその動作を制御される。踊り用アクチュエータ２００３は、人形２０００が踊っているように見えるように動くよう、人形２０００に取り付けられている。話し用アクチュエータ２００４は、人形２０００が話しているように見えるように動くよう、人形２０００に取り付けられている。
【００４８】
人形動作制御部２００２は、通信部２００１から渡されたデータに基づいて踊り用アクチュエータ２００３および話し用アクチュエータ２００４の状態を返したり動作を制御したりする。
【００４９】
具体的には、通信部２００１から渡されたデータが、状態取得要求を示すデータであれば踊り用アクチュエータ２００３および話し用アクチュエータ２００４が動作中であるか停止中であるかを示す状態返答を返す。
【００５０】
また、通信部２００１から渡されたデータが、踊り用アクチュエータ２００３の動作要求を示すデータであれば踊り用アクチュエータ２００３の動作を開始する。
【００５１】
また、通信部２００１から渡されたデータが、話し用アクチュエータ２００４の動作要求を示すデータであれば話し用アクチュエータ２００４の動作を開始する。
【００５２】
また、通信部２００１から渡されたデータが、停止要求を示すデータであれば踊り用アクチュエータ２００３および話し用アクチュエータ２００４の動作を停止する。
【００５３】
以上の構成の本実施の形態のシステムの、アプリケーション処理記述データの一例について図５および図６を用いて説明する。
【００５４】
図５は、アプリケーション処理記述データを、HTMLとJavaScriptとで記述した例である。また図６は、アプリケーション処理記述データを、BMLとECMAScriptとで記述した例である。
【００５５】
JavaScriptやECMAScriptには、関数名や引数などの細かな違いはあるものの，コンテンツ再生機１００のファイルシステムアクセスのための関数が用意されている。また既存のDVDでも、DVD再生によりチャプター選択メニューや再生言語設定メニューなどが表示されることから、画面表示と連動したアプリケーション処理記述機構が用意されていると思われる。
【００５６】
例えば図５におけるDriveExists()はコンテンツ再生機１００のファイルシステムにおける記憶装置を検出する関数である。ReadLine()は読み出し目的でOpenされたファイルから１行のテキストを読み出して左辺の変数に代入する関数である。WriteLine()は書き込み目的でOpenされたファイルに（）内のデータを書き込む関数である。
【００５７】
また例えば図６におけるreadPersistentString()は、（）内に書かれた名前のファイルから読み出したデータを左辺の変数に代入する関数である。また、writePersistentString()は、（）内に記述した名前のファイルに、一緒に記載したデータを書き込む関数である。
【００５８】
図７は、図５における、アプリケーション処理記述データと、各装置がやりとりする命令および値の関係を表す図である。ここではUSB通信機１０００がアプリケーション処理記述解釈部１１２に最も若い順番のドライブとして認識されている場合を例にとって説明する。
【００５９】
図５では、（１）から（４）の行で、人形２０００の動作状態の取得を試みている。
【００６０】
（１）の行で検出し変数fsoで表されたドライブに記憶されている、ファイル“status.txt”を、（２）の行で読み出し属性で開いている。開いたファイルを変数rsoで表しており、そのファイルから（３）の行で１行読み出した値を変数dataに格納している。
【００６１】
変数ｒｓｏで表されるファイルへの読み出し要求としての（３）の行の「var data=rso.ReadLine()」は、JavaScriptインタプリタやOSによってUSB通信機１０００への読み出し要求に変換される。USB通信機１０００への読み出し要求は、いわゆるUSBマスストレージクラスでのホストからペリフェラルへの読み出し要求（READコマンド）である。
【００６２】
USBマスストレージクラスのREADコマンドを受け取ったUSB通信機１０００のプロトコル変換部１００２は、READコマンドを、人形２０００の人形動作制御部２００２に対する状態取得要求に変換する。
【００６３】
状態取得要求を受け取った人形２０００の人形動作制御部２００２は、状態取得要求に対して、踊り用アクチュエータ２００３が動作中であるとか、話し用アクチュエータ２００４が動作中であるとか、どちらのアクチュエータも停止しているとか、といった状態返答を返す。
【００６４】
状態返答は、USB通信機１０００のプロトコル変換部１００２によって、READコマンドの返り値に変換される。この返り値はファイル“status.txt”から読み出された値としての、1行のテキストデータである。状態返答が踊り用アクチュエータ２００３動作中を示す値であれば、READコマンドの返り値として“dance”というテキストを返す。また、話し用アクチュエータ２００４動作中を示す値であれば、READコマンドの返り値として“talk”というテキストを返す。また、どちらのアクチュエータも停止していることを示す値であれば“stop”というテキストを返す。
【００６５】
READコマンドの返り値としての1行のテキストデータは変数dataに格納される。
【００６６】
（４）の行で、ファイル”status.txt”を閉じる動作として、変数rsoで表されるドライブを閉じている。
【００６７】
その下の（５）から（７）の行では、人形２０００を動作させる命令を記述している。
【００６８】
変数fsoで表されたドライブに記憶されている、ファイル“control.txt”を、（５）の行で書き込み属性で開いている。開いたファイルを変数wsoで表しており、そのファイルに（６）の行で“dance”という、人形２０００にさせる動作内容に対応するテキスト１行を書き込んでいる。書き込みの成否を変数ｎに格納している。
【００６９】
変数ｗｓｏで表されるドライブへの書き込み要求としての（６）の行の「var n=wso.WriteLine(“dance”)」は、JavaScriptインタプリタやOSによってUSB通信機１０００への書き込み要求に変換される。USB通信機１０００への書き込み要求は、いわゆるUSBマスストレージクラスでのホストからペリフェラルへの書き込み要求（WRITEコマンド）と、その後に送る、”dance”を表す論理ブロックである。
【００７０】
USBマスストレージクラスのWRITEコマンドと“dance”のテキストを受け取ったUSB通信機１０００のプロトコル変換部１００２は、WRITEコマンドと“dance” のテキストとを、人形２０００の人形動作制御部２００２に対する踊り用アクチュエータ動作要求に変換する。
【００７１】
この変換が正常に行われればUSB通信機１０００のプロトコル変換部１００２は、USBマスストレージクラスとして書き込みが正常に行われたことを示す値（すなわちSENSE KEYの値として０）を、コンテンツ再生機１００へ返す。
【００７２】
踊り用アクチュエータ動作要求を受け取った人形２０００の人形動作制御部２００２は、踊り用アクチュエータ２００３の動作を開始する。
【００７３】
ここで、（６）の行でWriteLine（）で書き込むテキストが“talk”であれば、USBマスストレージクラスのWRITEコマンドと“talk”のテキストを受け取ったUSB通信機１０００のプロトコル変換部１００２は、WRITEコマンドと“talk” のテキストとを、人形２０００の人形動作制御部２００２に対する話し用アクチュエータ動作要求コマンドに変換する。
【００７４】
また、（６）の行でWriteLine（）で書き込むテキストが“stop”であれば、USBマスストレージクラスのWRITEコマンドと“stop”のテキストを受け取ったUSB通信機１０００のプロトコル変換部１００２は、WRITEコマンドと“stop” のテキストとを、人形２０００の人形動作制御部２００２に対するアクチュエータ停止要求コマンドに変換する。
【００７５】
図８は、USB通信機１０００のプロトコル変換部１００２の変換規則を示す表である。
【００７６】
表の左欄がUSBIF１００１との入出力データを表す。また表の右欄が通信部１００３との入出力データを表す。
【００７７】
USBIF１００１から入力されるREADコマンドは、通信部１００３から出力する状態取得要求に変換される。USBIF１００１から入力されるWRITEコマンドは、その後に続く書き込みデータによって、異なるデータに変換される。すなわち、WRITEコマンドの後に続く書き込みデータが“dance”であれば、踊り用アクチュエータ動作要求として変換される。WRITEコマンドの後に続く書き込みデータが“talk”であれば、話し用アクチュエータ動作要求として変換される。WRITEコマンドの後に続く書き込みデータが“stop”であれば、アクチュエータ停止要求として変換される。
【００７８】
通信部１００３から入力される状態応答が、踊り用アクチュエータ動作中であることを示す値であれば、USBIF１００１でコンテンツ再生機１００に返すデータが"dance"となる。状態応答が話し用アクチュエータ動作中であることを示す値であれば、USBIF１００１でコンテンツ再生機１００に返すデータが"talk"となる。状態応答が
両アクチュエータ停止中であることを示す値であれば、USBIF１００１でコンテンツ再生機１００に返すデータが"stop"となる。
【００７９】
このような変換規則が、例えば変換テーブルといった形でプロトコル変換部１００２に記憶されている。
【００８０】
この変換規則にない入力がUSBIF１００１からされた場合は、その入力が却下されたことを表す値（すなわちSENSE KEYの値として８）を、USBIF１００１へ返す。
【００８１】
以上の構成の本実施の形態のシステムの動作について、図９、図１０、図１１、図１２を用いて説明する。
【００８２】
図９は、コンテンツ再生機１００の、図５および図７における読み出し動作に対応するフローチャートである。
【００８３】
アプリケーション処理記述解釈部１１２は、コンテンツソースからコンテンツ情報を取得すると、そこからアプリケーション処理記述データを抽出する（ステップ１）。
【００８４】
次に、アプリケーション処理記述解釈部１１２は、抽出したアプリケーション処理記述データに記述されたReadLine()を解釈して、USB通信機１０００への読み出し要求をUSB通信機１０００へ渡して（ステップ２）、返り値を待つ（ステップ３）。
【００８５】
図５のコードにはここまでの記述の例を示してあるが、更に返り値を文字グラフィックデータに変換してコンテンツ再生部に渡してディスプレイ１０２に表示させるようなコードを追加してもよい。
【００８６】
図１０は、図９におけるコンテンツ再生機１００に対応する、USB通信機１００の動作に係るフローチャートである。
【００８７】
USB通信機１００のプロトコル変換部１００２は、コンテンツ再生機１００から読み出し要求を受け取ると、それを、人形２０００の人形動作制御部２００２に対する状態取得要求に変換する（ステップ１０１）。
【００８８】
次に、USB通信機１０００の通信部１００３は、状態取得要求を送信し（ステップ１０２）、状態返答を待つ（ステップ１０３）。
【００８９】
通信部１００３が受け取った状態返答を、プロトコル変換部１００２はファイル“status.txt”から読み出したREADコマンドの返り値として1行のテキストデータに変換する（ステップ１０４）。
【００９０】
状態返答が話し用アクチュエータ２００４動作中を示す値であれば、READコマンドの返り値として“dance”というテキストをコンテンツ再生機１００へ返す。また、話し用アクチュエータ２００４動作中を示す値であれば、READコマンドの返り値として“talk”というテキストを返す。また、どちらのアクチュエータも停止していることを示す値であれば“stop”というテキストを返す（ステップ１０５）。
【００９１】
テキストを返した後、USB通信機１０００のプロトコル変換部１００２は、USBマスストレージクラスとして書き込みが正常に行われたことを示す値（すなわちSENSE KEYの値として０）を、コンテンツ再生機１００へ返す（ステップ１０６）。
【００９２】
図１１は、コンテンツ再生機１００の、図５および図７における書き込み動作に対応するフローチャートである。
【００９３】
コンテンツ再生機１００は、コンテンツソースからコンテンツ情報を取得すると、そこからアプリケーション処理記述データを抽出する（ステップ２０１）。
【００９４】
次に、コンテンツ再生機１００のアプリケーション処理記述解釈部１１２は、抽出したアプリケーション処理記述データに記述されたWriteLine()を解釈して、USB通信機１０００へのテキスト“dance”の書き込み要求をUSB通信機１０００へ渡して（ステップ２０２）、返り値を待つ（ステップ２０３）。
【００９５】
図１２は、図１１におけるコンテンツ再生機１００に対応する、USB通信機１００の動作に係るフローチャートである。
【００９６】
USB通信機１０００のプロトコル変換部１００２は、コンテンツ再生機１００からテキスト“dance”の書き込み要求を受け取ると、それを、人形２０００の人形動作制御部２００２に対する踊り用アクチュエータ動作要求に変換する（ステップ３０１）。
【００９７】
変換が正常に行われればプロトコル変換部１００２は、USBマスストレージクラスとして書き込みが正常に行われたことを示す値（すなわちSENSE KEYの値として０）を、コンテンツ再生機１００へ返す（ステップ３０２）。
【００９８】
次に、USB通信機１０００の通信部１００３は、踊り用アクチュエータ動作要求を送信する（ステップ３０３）。
【００９９】
なお、control.txtの属性を（読み出しおよび書き込み）可能属性とし、control.txtの読み出しに対する返り値としてstatus.txtの内容を返すように構成してもよい。
【０１００】
また、ファイルを開く際に人形２０００の電源をONにするコマンドを人形２０００に送り、それに応じて人形２０００の電源をONにするよう構成してもよい。また、ファイルを閉じる際に人形２０００の電源をOFFにするコマンドを人形２０００に送り、それに応じて人形２０００の電源をOFFにするよう構成してもよい。
【０１０１】
プロトコル変換部１００２は、ソフトウェアで実現してもよい。その場合、ハードウェアとしては、USBIF１００１や通信部１００３を外部通信IFとして備えることが可能なPCボードやそれと同等のもので、このソフトウェアを実行することができるものであればよい。USBIF１００１での通信を、SMB（Server Message Block）やNFS（Network File System）といったファイルサービスプロトコルを介して、上述のプロトコル変換部１００２の動作を実現するアプリケーションに渡せば、コンテンツ再生機１００のファイルシステムに制限されることなく設計することができる。
【０１０２】
（第2の実施の形態）
図１３は本実施の形態のシステム構成の概念図である。図１と同様の構成は説明を省略する。
【０１０３】
USB通信機３０００はコンテンツ再生機１００からはリムーバブルメディアとして認識され、例えば書き込みや読み出しといった、ストレージデバイスへの命令を受け付ける。USB通信機３０００はエアコン４０００と、例えばBluetooth（登録商標、以下同様）規格に基づいた無線通信を行う。USB通信機３０００は、コンテンツ再生機１００から受け付けたストレージデバイスへの命令を、エアコン４０００の制御命令に変換してエアコン４０００へ送信する。またUSB通信機３０００は、エアコン４０００から送信されたデータを受信して、コンテンツ再生機１００に対してリムーバブルディスク内のファイルとして提供する。
【０１０４】
エアコン４０００はECHONET（登録商標）に対応しており、運転のＯＮあるいはＯＦＦを、Bluetooth通信を介してコントローラからの命令によって切り替えられる。また、運転状況などをコントローラへ通知すべく送信することができる。本実施の形態では、コントローラは、コンテンツ再生機１００とUSB通信機３０００とで構成されているかたちとなる。
【０１０５】
本実施の形態におけるコンテンツ情報のアプリケーション処理記述データには、ECHONETアプリケーションへの命令が含まれる。ECHONETアプリケーションの命令は、EOJ（ECHONETオブジェクト：制御対象機器の識別子）、EPC（ECHONETプロパティ：制御対象機器の制御対象機能を表す識別子）、EDT（ECHONETデータ：制御対象機能に対してセットする値）を含むものとして説明する。
【０１０６】
図１４はUSB通信機３０００のブロック図である。
【０１０７】
USB通信機３０００は、USBIF３００１、プロトコル変換部３００２、通信部３００３、記憶部３００４を備える。
【０１０８】
USBIF３００１は、USBマスストレージクラスに対応するストレージペリフェラルとして、外部USBホスト装置とデータの通信を行う（本実施の形態では外部USBホスト装置はコンテンツ再生機１０００である）。
【０１０９】
プロトコル変換部３００２はECHONETの通信ミドルウェアおよびサービスミドルウェアと、さらに上位のアプリケーションソフトウェアを実行する。プロトコル変換部３００２は、その動作によって生成される情報を記憶する記憶部３０１２を備える。
【０１１０】
通信部３００３は、エアコン４０００と、Bluetooth通信を行う。
【０１１１】
以下、本実施の形態のUSB通信機３０００の動作を、USB接続フェーズと、イベント監視フェーズと、命令実行フェーズに分けて説明する。
【０１１２】
図１５はUSB接続フェーズのUSB通信機３０００の動作を表すフローチャートである。
【０１１３】
プロトコル変換部３００２は、USBIF３００１がUSBホスト機器と接続されたことを認識すると、通信部３００３を介して通信できるBluetooth対応機器を探索する（ステップ４０１）。
【０１１４】
次に、見つかったBluetooth対応機器がさらにECHONETにも対応していれば（ステップ４０２のYes）、Bluetoothコネクションを確立して、通信部３００３を介してプロパティマップ要求をBluetooth通信相手へと送信して（ステップ４０３）、返答を待つ（ステップ４０４）。見つかったBluetooth対応機器がECHONETに対応していなければ（ステップ４０２のNo）、その通信相手とのコネクションを確立せずにフェーズを終了する。
【０１１５】
プロパティマップを受け取ると、プロトコル変換部３００２はそのプロパティマップに含まれるEOJ、EPC、アクセスルールをもとにした名前であって、アクセスルールをもとにした属性のテキストファイルを生成して記憶部３０１２へ記憶する（ステップ４０５）。
【０１１６】
本実施の形態ではこのファイルの名前を、"/(EOJ)/(EPC)/(アクセスルール).txt"のようにしている。ただしここで、"/"はフォルダの階層を表す。つまりこれらのファイルは、EOJ、EPC、アクセスルール毎にフォルダに分けられて管理される。エアコン４０００のEOJが0x03b701で、その運転のEPCが0x80で、そのアクセスルールが制御（set）および参照(get)可能であれば、書き込み可能属性の"/0x03b701/0x80/set.txt"と読み込み可能属性の"/0x03b701/0x80/get.txt"とを生成して記憶部３０１２へ記憶する。
【０１１７】
なお、複数のECHONETおよびBluetooth対応の機器が発見された場合、それぞれとコネクションを確立してそれぞれのプロパティマップを取得してそれら各々についてのファイル生成を行ってもよい。
【０１１８】
図１６はイベント監視フェーズのUSB通信機３０００の動作を表すフローチャートである。
【０１１９】
プロトコル変換部３００２は、通信部３００３がエアコン４０００からのアナウンスを受信すると、そのアナウンスの内容を解析する（ステップ５０１）。アナウンスにはEOJとEPCと、そのEPCが示すプロパティの値とが含まれている。
【０１２０】
プロトコル変換部３００２は、そのアナウンスに含まれるEOJとEPCと、参照可能を示すsetと、を含む名前のファイルに、そのEPCが示すプロパティの値であるEDTの値を書き込む（ステップ５０２）。
【０１２１】
このようにして、ECHONET対応機器からのアナウンスを、EOJおよびEPC毎に記憶していく。
【０１２２】
図１７は命令実行フェーズで各装置がやりとりする命令および値の関係を表す図である。
【０１２３】
コンテンツ再生機１００はまず、USB通信機３０００から、フォルダ構成やファイル名の一覧といった、フォルダ／ファイル構成を取得する。EOJがフォルダ名であることから、コンテンツ再生機１００は、取得したフォルダ／ファイル構成を解析して、USB通信機３０００がプロパティマップを取得したECHONET対応機器が何であるかをEOJに含まれるクラスコードなどから判別することができる。
【０１２４】
アプリケーション処理記述データには例えば、エアコンであるオブジェクトの運転をＯＮにする、といった命令が記述されている。アプリケーション処理記述解釈部１１２はその命令を解釈して、エアコン４０００のEOJである0x03b701のフォルダの、運転プロパティを表すEPCである0x80のフォルダの、書き込み可能属性であるset.txtへの、運転をONとするデータであるEDTの値である0x30の書き込み要求コマンドをUSBIF１０６を介して無線通信機３０００へ送る。
【０１２５】
USB通信機３０００はこの書き込み要求を受け取ると、EOJ=0x03b701、EPC=0x80、EDT=0x30のECHONETパケットを生成して、通信部３００３を介してエアコン４０００へ送信する（本実施の形態ではこのECHONETパケットが動作要求のひとつに相当する）。
【０１２６】
このパケットによってエアコン４０００はその運転をONにする。
【０１２７】
なお、USB通信機３０００は、書き込み要求を受け取りその書き込み先ファイル（set.txt）と同じフォルダ内のget.txtに記述されている値が0x30であった場合には、エアコン４０００は既に運転ONの状態であるということなので、上述のECHONETパケットを生成しないようにしてもよい。
【０１２８】
またエアコン４０００を、運転がONの状態あるいはOFFの状態から他方の状態へ変化した際に、イベントとしてUSB通信機３０００に運転プロパティの状態変化を通知してもよい。
【０１２９】
図１７ではさらに、エアコン４０００の運転がＯＮになった後に、コンテンツ再生機１００がUSB通信機３０００へ、"/0x03b701/0x80/get.txt"の読み出し要求を送っている。これに応じてUSB通信機３０００のプロトコル変換部３００２は、記憶部３０１２から"/0x03b701/0x80/get.txt"の内容を読み出し、コンテンツ再生機１００へ読み出した値を返している。このような読み出し要求は繰り返し連続して行ってもよく、例えば"/0x03b701/0x80/get.txt"の最終更新日時が前に読み出したときに比べて更新されていればそこで繰り返しを止める、といった制御としてもよい。
【０１３０】
なお、"/0x03b701/0x80/get.txt"の読み出し要求を受け取ったUSB通信機３０００に、EOJ=0x03b701、EPC=0x80のEDTを取得させるECHONETパケットをエアコン４０００に送信させてもよい（本実施の形態ではこのECHONETパケットが状態取得要求のひとつに相当する）。
【０１３１】
図１８は図１７におけるコンテンツ再生機１００の書き込み要求に係る動作を表すフローチャートである。
【０１３２】
アプリケーション処理記述解釈部１１２は、コンテンツソースからコンテンツ情報を取得すると、そこからアプリケーション処理記述データを抽出する（ステップ６０１）。
【０１３３】
次にアプリケーション処理記述解釈部１１２は、USB通信機３０００からフォルダ／ファイル構成を取得する（ステップ６０２）。フォルダ／ファイル構成から、USB通信機３０００がプロパティマップを取得したECHONET対応機器のクラスを知る。
【０１３４】
次に、アプリケーション処理記述解釈部１１２は、抽出したアプリケーション処理記述データを解釈して、アプリケーション処理記述データの命令の対象オブジェクトのクラスコードを含む名前のフォルダがあるドライブへの、EDTの値とそれを書き込むべきファイル名とを含む書き込み要求を行い（ステップ６０３）、返り値を待つ（ステップ６０４）。ここではアプリケーション処理記述データが、エアコンであるオブジェクトに対する命令なので、エアコンのEOJが名前としてつけられたフォルダを有する、USB通信機３０００を表すドライブへの書き込み要求となる。
【０１３５】
図１９は図１８に対応するUSB通信機３０００の動作を表すフローチャートである。
【０１３６】
USB通信機３０００のプロトコル変換部３００２は、コンテンツ再生機１００から書き込み要求を受け取ると、書き込み先のファイルおよびその上位フォルダの名前からEOJとEPCとを抽出する（ステップ７０１）。
【０１３７】
次にプロトコル変換部３００２は、抽出したEOJとEPCと、書き込み要求に含まれる書き込み値であるEDTと、からECHONETパケットを生成する。（ステップ７０２）。
【０１３８】
次にプロトコル変換部３００２は、生成したECHONETパケットを通信部３００３に渡して、エアコン４０００へと送信させ（ステップ７０３）、SENSE KEYの値として０をコンテンツ再生機１００へ返す（ステップ７０４）。
【０１３９】
本実施の形態では制御対象機器としてECHONET対応エアコンを挙げたが、他のネットワーク機器制御プロトコルであるUPnPなどによって制御する場合であっても発明を適宜応用することができることはいうまでもない。
【０１４０】
ECHONETでは、あるECHONET機器がどのような制御が可能であるかを調べるためにプロパティマップを用いるが、UPnP機器を制御対象とする場合はその代わりにDeviceDescriptionやServiceDescriptionと呼ばれる機器情報を用いる。ECHONETでは制御のために生成するファイルを"/(EOJ)/(EPC)/(アクセスルール).txt"としたが，UPnPではファイルとして例えば，/upnp/foo/barなどといったcontrolURLと呼ばれる制御先を特定するURLをファイル名として利用すればよい。またECHONETではそのファイルに書き込む情報をEDTとしたが、UPnPでは例えばUPnPの制御に使われるSOAPメッセージと呼ばれるXML形式の文字列を書き込むとすればよい。
【０１４１】
USB通信機１０００あるいは３０００を通じて制御する機器はECHONET対応機器のみであるとしたが、例えばECHONET機器とUPnP機器の両方を制御できるように構成することも可能であることはいうまでもない。その場合、ECHONET機器が制御デバイスに接続された際はプロパティマップに基づいた/0x03b701/0x80/get.txtなどといった制御用ファイルを生成し、UPnP機器が制御デバイスに接続された際はDeviceDescriptionに基づいた制御用ファイルを生成する、といったように、制御用の特定ファイルを，接続機器の特性に合わせて動的に生成する。
【０１４２】
さらに、USB通信機のコンテンツ再生機１００とのIFは、各実施の形態においてUSBであるとして説明したが、例えばBluetoothのFile Transfer Profileを用いる場合のようにコンテンツ再生機１００に対して自らが１つの記憶装置であるように振舞い、コンテンツ再生機１００の書き込み要求や読み出し要求を扱えるIFであればよいことはいうまでもない。
【０１４３】
以上のような構成の各実施の形態のシステムによれば、コンテンツ再生機が一般的に備えているストレージ操作機能を用いてネットワーク機器の様々な機能を制御することができる。その結果、「ネットワーク機器連動コンテンツ」を実現することができる。
【０１４４】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
【０１４５】
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
【０１４６】
また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
【０１４７】
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【０１４８】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【図面の簡単な説明】
【０１４９】
【図１】第１の実施の形態のシステム構成の概念図。
【図２】第１の実施の形態のコンテンツ再生機のブロック図。
【図３】第１の実施の形態のUSB通信機のブロック図。
【図４】第１の実施の形態の人形のブロック図。
【図５】第１の実施の形態のアプリケーション処理記述データをHTMLとJavaScriptとで記述した例。
【図６】第１の実施の形態のアプリケーション処理記述データをBMLとECMAScriptとで記述した例。
【図７】第１の実施の形態のアプリケーション処理記述データと、各装置がやりとりする命令および値の関係を表す図。
【図８】第１の実施の形態のUSB通信機のプロトコル変換部の変換規則を示す表。
【図９】第１の実施の形態のコンテンツ再生機の読み出し動作に係るフローチャート。
【図１０】第１の実施の形態のUSB通信機の動作に係るフローチャート。
【図１１】第１の実施の形態のコンテンツ再生機の、書き込み動作に係るフローチャートである。
【図１２】第１の実施の形態のUSB通信機の動作に係るフローチャート。
【図１３】第２の実施の形態の本実施の形態のシステム構成の概念図。
【図１４】第２の実施の形態のUSB通信機３０００のブロック図。
【図１５】第２の実施の形態のUSB接続フェーズのUSB通信機３０００の動作を表すフローチャート。
【図１６】第２の実施の形態のイベント監視フェーズのUSB通信機３０００の動作を表すフローチャート。
【図１７】第２の実施の形態の命令実行フェーズで各装置がやりとりする命令および値の関係を表す図。
【図１８】第２の実施の形態のコンテンツ再生機の書き込み要求に係るフローチャート。
【図１９】第２の実施の形態のUSB通信機の動作を表すフローチャート。
【符号の説明】
【０１５０】
１００・・・コンテンツ再生機、１０００，３０００・・・ＵＳＢ通信機、２０００・・・人形、４０００・・・エアコン。
【技術分野】
【０００１】
本発明は、所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との通信を制御する通信装置および通信制御方法に関する。
【背景技術】
【０００２】
近年のコンテンツの多様化により、映像や音声などのメディアを単に再生するだけでなく、アプリケーション的な処理コードを含むようなコンテンツが登場してきている。例えばWebコンテンツや放送コンテンツには、従来の映像や音声などのメディアデータに加えて、ページ記述言語やスクリプト言語などによるアプリケーション処理記述が含まれていることがある。
【０００３】
従来のアプリケーション処理記述としては例えば、その処理を実行するコンテンツ再生機に取り付けられた記憶装置へのファイルの書き込みや読み出しといったものがあった。
【０００４】
一方、コンテンツに付随するこのようなアプリケーション処理記述で、近年発展しているホームネットワーク機器（例えば白物家電や、AV機器、おもちゃなどでネットワークインタフェースを備えるもの）を制御したいというニーズが現れ始めている。これは例えば、コンテンツとしては冬の場面を映像として表示し、同時にネットワーク対応エアコンに部屋の温度を下げさせるなどといったかたちである。
【０００５】
このような「ネットワーク機器連動コンテンツ」を実現させるための仕組みがいくつか提案されている。
【０００６】
例えば特許文献１では、SMIL（Synchronized Multimedia Integration Language）と呼ばれる記述言語を一部拡張し、映像などのメディアとネットワーク機器との連携動作を記述し、コンテンツ再生機にてその記述に従って機器を制御する機構が提案されている。
【特許文献１】特開２００４−３４１７３６公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
特許文献１では、制御対象となる全てのネットワーク機器およびコンテンツ再生機が、Jini（登録商標、以下同様）やRendezvous（登録商標、以下同様）などの共通の制御プロトコルによる通信機能を備えているとしている。
【０００８】
しかしながら制御プロトコルと対象製品は、例えばUPnP（登録商標、以下同様）対応AV機器、ECHONET（登録商標、以下同様）対応白物家電、独自プロトコルにより制御されるおもちゃなど、様々である。また、今後も新たな制御プロトコルが現れることも十分考えられる。
【０００９】
つまり、特許文献１の技術は汎用性に欠けている。
【００１０】
本発明は、コンテンツ再生機の例えばファイル操作といった既存の機能を利用することで汎用性を確保しつつ「ネットワーク機器連動コンテンツ」を実現することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との両方と通信を行う通信装置において、前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供するファイル構成提供手段と、前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段と、前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段と、
を備えることを特徴とする通信装置を提供する。
【発明の効果】
【００１２】
コンテンツ再生機が一般に備えているストレージ操作機能を用いてネットワーク機器の様々な機能を制御することができる。その結果、「ネットワーク機器連動コンテンツ」を実現することができる。
【発明を実施するための最良の形態】
【００１３】
（第１の実施の形態）
図１は、本実施の形態のシステム構成の概念図である。
【００１４】
コンテンツ再生機１００は、例えば放送波アンテナに接続する放送デコーダや、インターネットに接続する有線ネットワークIF（インタフェース）１０９、無線ネットワークに接続する無線ネットワークIF１０８などを備える。それらを通じて、例えば放送波を通じて提供される放送コンテンツや、インターネットを通じて提供されるWebコンテンツなどといった、後述するコンテンツ情報を取得する。
【００１５】
コンテンツ再生機１００はさらに、DVDドライブ１０４やメモリカードスロット１０５などのメディアドライブや、USBIF１０６などの外部装置IFを備える。それぞれ、対応する各種リムーバブルメディアからコンテンツを取得する。
【００１６】
コンテンツ再生機１００は、取得したコンテンツを、コントロールパネル１０７から入力されるユーザの指示に従って再生する。またユーザは例えば、どのコンテンツソース（放送デコーダ、有線／無線ネットワークIF、メディアドライブや外部装置IF）から、再生すべきコンテンツを取得するかを、コントロールパネル１０７で選択する。
【００１７】
再生したコンテンツは例えばディスプレイ１０２やヘッドホン１０３といった再生デバイスへ送出され、ユーザへ提供される。
【００１８】
USBIF１０６には制御デバイスとしてのUSB通信機１０００が接続される。
【００１９】
USB通信機１０００はコンテンツ再生機１００からはリムーバブルメディアとして認識され、例えば書き込みや読み出しといった、ストレージデバイスへの命令を受け付ける。USB通信機１０００は人形２０００と、IrDA規格に則った赤外線通信を行う。USB通信機１０００は、コンテンツ再生機１００から受け付けたストレージデバイスへの命令を、人形２０００の制御命令に変換して人形２０００へ送信する。またUSB通信機１０００は、人形２０００から送信されたデータを受信して、コンテンツ再生機１００に対してリムーバブルディスク内のファイルとして提供する。
【００２０】
ネットワーク機器としての人形２０００は、USB通信機１０００と赤外線通信を行う。人形２０００はUSB通信機１０００から受信する動作要求に応じて動き、状態取得要求に応じて自らの状態を返答する。
【００２１】
本実施の形態におけるコンテンツ情報とは、従来一般に言われてきた映像や音声を表すメディアデータのみを指すものではない。本実施の形態におけるコンテンツ情報は、メディアデータに加えて、後述するアプリケーション処理記述データをも含むものである。
【００２２】
アプリケーション処理記述データは例えばMacromedia Flash（登録商標、以下同様）形式（SWF形式）、JavaScript（登録商標、以下同様）形式、ECMAScript形式などといったスクリプト言語で記述される。近年のWebコンテンツや放送コンテンツに見られるように，これらはHTML（Hyper Text Markup Language）やBML（Broadcast Markup Language）形式のマークアップ言語で記述したファイルに埋め込まれて提供される
アプリケーション処理記述データのなかには、人形２０００の状態を取得することを意図した命令が、例えばストレージデバイスからデータ読み出し命令として含まれる。また、人形２０００への動作要求を意図した命令が、例えばストレージデバイスへのデータ書き込み命令として含まれる。
【００２３】
図２はコンテンツ再生機１００のブロック図である。
【００２４】
コンテンツ再生機１００は、DVDドライブ１０４、メモリカードスロット１０５、USBIF１０６、コントロールパネル１０７、無線ネットワークIF１０８、有線ネットワークIF１０９、放送デコーダ１１０、外部入出力管理部１１１、アプリケーション処理記述解釈部１１２、コンテンツ再生部１１３、グラフィックIF１１４、サウンドIF１１５、HDD（ハード ディスク ドライブ）１１６を備える。
【００２５】
DVDドライブ１０４は、DVDからコンテンツ情報を取得する。
【００２６】
メモリカードスロット１０５は、挿入されるメモリカードからコンテンツ情報を取得する。
【００２７】
USBIF１０６は、USBホスト機能を有し、USBペリフェラル機能を有する他の機器と接続するIFである。USBIF１０６は例えば、USBマスストレージクラスに対応するストレージペリフェラルと接続してコンテンツ情報を取得する。（なお、USB2.0で規定されたUSB On-The-Go機能によれば、USBIF１０６がホストに限るものではない）
無線ネットワークIF１０８は例えば、ＩＥＥＥ８０２．１１で規定される無線ＬＡＮ仕様に準拠するIFである。無線ネットワークIF１０８は、無線ネットワークを通じてコンテンツ情報を取得する。
【００２８】
有線ネットワークIF１０９は例えば、ＩＥＥＥ８０２．３で規定される有線ＬＡＮ仕様に準拠するIFである。有線ネットワークIF１０９は、有線ネットワークを通じてコンテンツ情報を取得する。
【００２９】
放送デコーダ１１０は例えば、ARIB STDで規定されるデジタル放送規格に準拠する受信デバイスである。放送デコーダ１１０は、放送波をデコードしてコンテンツ情報を取得する。
【００３０】
HDD１１６は、コンテンツ再生機１００に固定される記憶装置で、アプリケーション処理記述解釈部１１２やコンテンツ再生部１１３の処理で用いる情報の一部を記憶する。
【００３１】
コントロールパネル１０７は、ユーザのコンテンツソース選択指示が入力される。
【００３２】
外部入出力管理部１１１は、DVDドライブ１０４、メモリカードスロット１０５、USBIF１０６、コントロールパネル１０７、無線ネットワークIF１０８、有線ネットワークIF１０９、放送デコーダ１１０、HDD１１６らに対して、それぞれに対応したデータの読み込みおよび書き出しの動作の制御を行う。
【００３３】
アプリケーション処理記述解釈部１１２は、コンテンツ情報からアプリケーション処理記述データを抽出して解釈する。このようなアプリケーション処理記述解釈部１１２の機能は、例えばスクリプト言語がJavaScriptである場合は、オペレーティングシステム（OS）やそれに対応したJavaScriptインタプリタなどで実現することができる。
【００３４】
アプリケーション処理記述解釈部１１２のOSはUSBをサポートしており、そのOSのファイルシステムに則ってUSB通信機１０００のファイルにアクセスする。
【００３５】
コンテンツ情報に記述されるファイルアクセスコマンドは例えば、ドライブ識別子と、そのドライブに記憶されているファイルの識別子とを含む。また、そのファイルに書き込むべき内容を含んでもよい。アプリケーション処理記述解釈部１１２はファイルアクセスコマンドに従って、外部入出力管理部１１１およびUSBIF１０６を介して、USBIF１０６に接続するUSBマスストレージクラス対応のデバイスに記憶されているように見えているデータファイルへのアクセスを行う。また、アプリケーション処理記述解釈部１１２は、コンテンツ情報からメディアデータを抽出してコンテンツ再生部１１３へ提供する。
【００３６】
コンテンツ再生部１１３は、メディアデータをデコードして、映像信号を生成してグラフィックIF１１４を介してディスプレイ１０２へ出力する。またコンテンツ再生部１１３は、メディアデータをデコードして、音声信号を生成してサウンドIF１１５を介してヘッドホン１０３へ出力する。
【００３７】
図３はUSB通信機１０００のブロック図である。
【００３８】
USB通信機１０００は、USBIF１００１、プロトコル変換部１００２、通信部１００３、記憶部１００４を備える。
【００３９】
USBIF１００１は、USBマスストレージクラスに対応するストレージペリフェラルとして、外部USBホスト装置とデータの通信を行う（本実施の形態では外部USBホスト装置はコンテンツ再生機１０００である）。USBIF１００１は、この通信で受信したデータを、記憶装置と通信するためのプロトコル（例えばＡＴＡ方式やＳＣＳＩ方式など）で出力する。また、外部USBホスト装置との通信において送信するデータを、記憶装置と通信するためのプロトコルで取得する。すなわち、USBIF１００１は、従来のUSBマスストレージクラス対応IFを流用してもよい。
【００４０】
プロトコル変換部１００２はUSBIF１００１に対して記憶装置と通信するためのプロトコルで通信を行う。本実施の形態のプロトコル変換部１００２は例えば、その動作をハードウェア（例えばASIC（Application SpecIFic Integrated Circuit）やFPGA（Field Programmable Gate Array））で実現してもよい。
【００４１】
プロトコル変換部１００３は、この通信で受信したデータを、記憶部１００４へ書き込む。またプロトコル変換部１００２は、この通信で受信したデータを、人形２０００の動作を制御する動作制御データに変換して通信部１００３へ渡す。さらに、プロトコル変換部１００２は、通信部１００３から受け取ったデータを変換し、記憶装置と通信するためのプロトコルでUSBIF１００１へ送り、かつ記憶部１００４へ書き込む。
【００４２】
本実施の形態のプロトコル変換部１００２は、USBIF１００１からは、コンテンツ再生機１００のOSがサポートするファイルシステムフォーマットであり、読み取り専用属性のstatus.txtと、書き込み可能属性のcontrol.txtとの２つのテキストファイルが記憶されている記憶装置であるよう認識される。つまり、OSのファイルシステムがドライブ内のフォルダ／ファイル構成を取得するためにアクセスするアドレスの値として、固定的に返り値を返す。これは例えばLUT（ルックアップテーブル）等で実現することができる。プロトコル変換部１００２は、これら２つのファイル以外に新たなファイルを書き込む命令は拒否する。またプロトコル変換部１００２は、これら２つのファイルの属性変更を拒否する。
【００４３】
通信部１００３は、人形２０００と、例えばIrDA（登録商標、以下同様）規格に則った赤外線通信を行う。
【００４４】
図４は人形２０００のブロック図である。
【００４５】
人形２０００は、通信部２００１、人形動作制御部２００２、踊り用アクチュエータ２００３、話し用アクチュエータ２００４を備える。
【００４６】
通信部２００１は、USB通信機１０００の通信部１００３と、例えばIrDA規格に則った赤外線通信を行う。通信部２００１は、受信するデータを人形動作制御部２００２へ渡す。また、人形動作制御部２００２から受け取るデータをUSB通信機１０００へ送信する。
【００４７】
踊り用アクチュエータ２００３および話し用アクチュエータ２００４は人形動作制御部２００２にその動作を制御される。踊り用アクチュエータ２００３は、人形２０００が踊っているように見えるように動くよう、人形２０００に取り付けられている。話し用アクチュエータ２００４は、人形２０００が話しているように見えるように動くよう、人形２０００に取り付けられている。
【００４８】
人形動作制御部２００２は、通信部２００１から渡されたデータに基づいて踊り用アクチュエータ２００３および話し用アクチュエータ２００４の状態を返したり動作を制御したりする。
【００４９】
具体的には、通信部２００１から渡されたデータが、状態取得要求を示すデータであれば踊り用アクチュエータ２００３および話し用アクチュエータ２００４が動作中であるか停止中であるかを示す状態返答を返す。
【００５０】
また、通信部２００１から渡されたデータが、踊り用アクチュエータ２００３の動作要求を示すデータであれば踊り用アクチュエータ２００３の動作を開始する。
【００５１】
また、通信部２００１から渡されたデータが、話し用アクチュエータ２００４の動作要求を示すデータであれば話し用アクチュエータ２００４の動作を開始する。
【００５２】
また、通信部２００１から渡されたデータが、停止要求を示すデータであれば踊り用アクチュエータ２００３および話し用アクチュエータ２００４の動作を停止する。
【００５３】
以上の構成の本実施の形態のシステムの、アプリケーション処理記述データの一例について図５および図６を用いて説明する。
【００５４】
図５は、アプリケーション処理記述データを、HTMLとJavaScriptとで記述した例である。また図６は、アプリケーション処理記述データを、BMLとECMAScriptとで記述した例である。
【００５５】
JavaScriptやECMAScriptには、関数名や引数などの細かな違いはあるものの，コンテンツ再生機１００のファイルシステムアクセスのための関数が用意されている。また既存のDVDでも、DVD再生によりチャプター選択メニューや再生言語設定メニューなどが表示されることから、画面表示と連動したアプリケーション処理記述機構が用意されていると思われる。
【００５６】
例えば図５におけるDriveExists()はコンテンツ再生機１００のファイルシステムにおける記憶装置を検出する関数である。ReadLine()は読み出し目的でOpenされたファイルから１行のテキストを読み出して左辺の変数に代入する関数である。WriteLine()は書き込み目的でOpenされたファイルに（）内のデータを書き込む関数である。
【００５７】
また例えば図６におけるreadPersistentString()は、（）内に書かれた名前のファイルから読み出したデータを左辺の変数に代入する関数である。また、writePersistentString()は、（）内に記述した名前のファイルに、一緒に記載したデータを書き込む関数である。
【００５８】
図７は、図５における、アプリケーション処理記述データと、各装置がやりとりする命令および値の関係を表す図である。ここではUSB通信機１０００がアプリケーション処理記述解釈部１１２に最も若い順番のドライブとして認識されている場合を例にとって説明する。
【００５９】
図５では、（１）から（４）の行で、人形２０００の動作状態の取得を試みている。
【００６０】
（１）の行で検出し変数fsoで表されたドライブに記憶されている、ファイル“status.txt”を、（２）の行で読み出し属性で開いている。開いたファイルを変数rsoで表しており、そのファイルから（３）の行で１行読み出した値を変数dataに格納している。
【００６１】
変数ｒｓｏで表されるファイルへの読み出し要求としての（３）の行の「var data=rso.ReadLine()」は、JavaScriptインタプリタやOSによってUSB通信機１０００への読み出し要求に変換される。USB通信機１０００への読み出し要求は、いわゆるUSBマスストレージクラスでのホストからペリフェラルへの読み出し要求（READコマンド）である。
【００６２】
USBマスストレージクラスのREADコマンドを受け取ったUSB通信機１０００のプロトコル変換部１００２は、READコマンドを、人形２０００の人形動作制御部２００２に対する状態取得要求に変換する。
【００６３】
状態取得要求を受け取った人形２０００の人形動作制御部２００２は、状態取得要求に対して、踊り用アクチュエータ２００３が動作中であるとか、話し用アクチュエータ２００４が動作中であるとか、どちらのアクチュエータも停止しているとか、といった状態返答を返す。
【００６４】
状態返答は、USB通信機１０００のプロトコル変換部１００２によって、READコマンドの返り値に変換される。この返り値はファイル“status.txt”から読み出された値としての、1行のテキストデータである。状態返答が踊り用アクチュエータ２００３動作中を示す値であれば、READコマンドの返り値として“dance”というテキストを返す。また、話し用アクチュエータ２００４動作中を示す値であれば、READコマンドの返り値として“talk”というテキストを返す。また、どちらのアクチュエータも停止していることを示す値であれば“stop”というテキストを返す。
【００６５】
READコマンドの返り値としての1行のテキストデータは変数dataに格納される。
【００６６】
（４）の行で、ファイル”status.txt”を閉じる動作として、変数rsoで表されるドライブを閉じている。
【００６７】
その下の（５）から（７）の行では、人形２０００を動作させる命令を記述している。
【００６８】
変数fsoで表されたドライブに記憶されている、ファイル“control.txt”を、（５）の行で書き込み属性で開いている。開いたファイルを変数wsoで表しており、そのファイルに（６）の行で“dance”という、人形２０００にさせる動作内容に対応するテキスト１行を書き込んでいる。書き込みの成否を変数ｎに格納している。
【００６９】
変数ｗｓｏで表されるドライブへの書き込み要求としての（６）の行の「var n=wso.WriteLine(“dance”)」は、JavaScriptインタプリタやOSによってUSB通信機１０００への書き込み要求に変換される。USB通信機１０００への書き込み要求は、いわゆるUSBマスストレージクラスでのホストからペリフェラルへの書き込み要求（WRITEコマンド）と、その後に送る、”dance”を表す論理ブロックである。
【００７０】
USBマスストレージクラスのWRITEコマンドと“dance”のテキストを受け取ったUSB通信機１０００のプロトコル変換部１００２は、WRITEコマンドと“dance” のテキストとを、人形２０００の人形動作制御部２００２に対する踊り用アクチュエータ動作要求に変換する。
【００７１】
この変換が正常に行われればUSB通信機１０００のプロトコル変換部１００２は、USBマスストレージクラスとして書き込みが正常に行われたことを示す値（すなわちSENSE KEYの値として０）を、コンテンツ再生機１００へ返す。
【００７２】
踊り用アクチュエータ動作要求を受け取った人形２０００の人形動作制御部２００２は、踊り用アクチュエータ２００３の動作を開始する。
【００７３】
ここで、（６）の行でWriteLine（）で書き込むテキストが“talk”であれば、USBマスストレージクラスのWRITEコマンドと“talk”のテキストを受け取ったUSB通信機１０００のプロトコル変換部１００２は、WRITEコマンドと“talk” のテキストとを、人形２０００の人形動作制御部２００２に対する話し用アクチュエータ動作要求コマンドに変換する。
【００７４】
また、（６）の行でWriteLine（）で書き込むテキストが“stop”であれば、USBマスストレージクラスのWRITEコマンドと“stop”のテキストを受け取ったUSB通信機１０００のプロトコル変換部１００２は、WRITEコマンドと“stop” のテキストとを、人形２０００の人形動作制御部２００２に対するアクチュエータ停止要求コマンドに変換する。
【００７５】
図８は、USB通信機１０００のプロトコル変換部１００２の変換規則を示す表である。
【００７６】
表の左欄がUSBIF１００１との入出力データを表す。また表の右欄が通信部１００３との入出力データを表す。
【００７７】
USBIF１００１から入力されるREADコマンドは、通信部１００３から出力する状態取得要求に変換される。USBIF１００１から入力されるWRITEコマンドは、その後に続く書き込みデータによって、異なるデータに変換される。すなわち、WRITEコマンドの後に続く書き込みデータが“dance”であれば、踊り用アクチュエータ動作要求として変換される。WRITEコマンドの後に続く書き込みデータが“talk”であれば、話し用アクチュエータ動作要求として変換される。WRITEコマンドの後に続く書き込みデータが“stop”であれば、アクチュエータ停止要求として変換される。
【００７８】
通信部１００３から入力される状態応答が、踊り用アクチュエータ動作中であることを示す値であれば、USBIF１００１でコンテンツ再生機１００に返すデータが"dance"となる。状態応答が話し用アクチュエータ動作中であることを示す値であれば、USBIF１００１でコンテンツ再生機１００に返すデータが"talk"となる。状態応答が
両アクチュエータ停止中であることを示す値であれば、USBIF１００１でコンテンツ再生機１００に返すデータが"stop"となる。
【００７９】
このような変換規則が、例えば変換テーブルといった形でプロトコル変換部１００２に記憶されている。
【００８０】
この変換規則にない入力がUSBIF１００１からされた場合は、その入力が却下されたことを表す値（すなわちSENSE KEYの値として８）を、USBIF１００１へ返す。
【００８１】
以上の構成の本実施の形態のシステムの動作について、図９、図１０、図１１、図１２を用いて説明する。
【００８２】
図９は、コンテンツ再生機１００の、図５および図７における読み出し動作に対応するフローチャートである。
【００８３】
アプリケーション処理記述解釈部１１２は、コンテンツソースからコンテンツ情報を取得すると、そこからアプリケーション処理記述データを抽出する（ステップ１）。
【００８４】
次に、アプリケーション処理記述解釈部１１２は、抽出したアプリケーション処理記述データに記述されたReadLine()を解釈して、USB通信機１０００への読み出し要求をUSB通信機１０００へ渡して（ステップ２）、返り値を待つ（ステップ３）。
【００８５】
図５のコードにはここまでの記述の例を示してあるが、更に返り値を文字グラフィックデータに変換してコンテンツ再生部に渡してディスプレイ１０２に表示させるようなコードを追加してもよい。
【００８６】
図１０は、図９におけるコンテンツ再生機１００に対応する、USB通信機１００の動作に係るフローチャートである。
【００８７】
USB通信機１００のプロトコル変換部１００２は、コンテンツ再生機１００から読み出し要求を受け取ると、それを、人形２０００の人形動作制御部２００２に対する状態取得要求に変換する（ステップ１０１）。
【００８８】
次に、USB通信機１０００の通信部１００３は、状態取得要求を送信し（ステップ１０２）、状態返答を待つ（ステップ１０３）。
【００８９】
通信部１００３が受け取った状態返答を、プロトコル変換部１００２はファイル“status.txt”から読み出したREADコマンドの返り値として1行のテキストデータに変換する（ステップ１０４）。
【００９０】
状態返答が話し用アクチュエータ２００４動作中を示す値であれば、READコマンドの返り値として“dance”というテキストをコンテンツ再生機１００へ返す。また、話し用アクチュエータ２００４動作中を示す値であれば、READコマンドの返り値として“talk”というテキストを返す。また、どちらのアクチュエータも停止していることを示す値であれば“stop”というテキストを返す（ステップ１０５）。
【００９１】
テキストを返した後、USB通信機１０００のプロトコル変換部１００２は、USBマスストレージクラスとして書き込みが正常に行われたことを示す値（すなわちSENSE KEYの値として０）を、コンテンツ再生機１００へ返す（ステップ１０６）。
【００９２】
図１１は、コンテンツ再生機１００の、図５および図７における書き込み動作に対応するフローチャートである。
【００９３】
コンテンツ再生機１００は、コンテンツソースからコンテンツ情報を取得すると、そこからアプリケーション処理記述データを抽出する（ステップ２０１）。
【００９４】
次に、コンテンツ再生機１００のアプリケーション処理記述解釈部１１２は、抽出したアプリケーション処理記述データに記述されたWriteLine()を解釈して、USB通信機１０００へのテキスト“dance”の書き込み要求をUSB通信機１０００へ渡して（ステップ２０２）、返り値を待つ（ステップ２０３）。
【００９５】
図１２は、図１１におけるコンテンツ再生機１００に対応する、USB通信機１００の動作に係るフローチャートである。
【００９６】
USB通信機１０００のプロトコル変換部１００２は、コンテンツ再生機１００からテキスト“dance”の書き込み要求を受け取ると、それを、人形２０００の人形動作制御部２００２に対する踊り用アクチュエータ動作要求に変換する（ステップ３０１）。
【００９７】
変換が正常に行われればプロトコル変換部１００２は、USBマスストレージクラスとして書き込みが正常に行われたことを示す値（すなわちSENSE KEYの値として０）を、コンテンツ再生機１００へ返す（ステップ３０２）。
【００９８】
次に、USB通信機１０００の通信部１００３は、踊り用アクチュエータ動作要求を送信する（ステップ３０３）。
【００９９】
なお、control.txtの属性を（読み出しおよび書き込み）可能属性とし、control.txtの読み出しに対する返り値としてstatus.txtの内容を返すように構成してもよい。
【０１００】
また、ファイルを開く際に人形２０００の電源をONにするコマンドを人形２０００に送り、それに応じて人形２０００の電源をONにするよう構成してもよい。また、ファイルを閉じる際に人形２０００の電源をOFFにするコマンドを人形２０００に送り、それに応じて人形２０００の電源をOFFにするよう構成してもよい。
【０１０１】
プロトコル変換部１００２は、ソフトウェアで実現してもよい。その場合、ハードウェアとしては、USBIF１００１や通信部１００３を外部通信IFとして備えることが可能なPCボードやそれと同等のもので、このソフトウェアを実行することができるものであればよい。USBIF１００１での通信を、SMB（Server Message Block）やNFS（Network File System）といったファイルサービスプロトコルを介して、上述のプロトコル変換部１００２の動作を実現するアプリケーションに渡せば、コンテンツ再生機１００のファイルシステムに制限されることなく設計することができる。
【０１０２】
（第2の実施の形態）
図１３は本実施の形態のシステム構成の概念図である。図１と同様の構成は説明を省略する。
【０１０３】
USB通信機３０００はコンテンツ再生機１００からはリムーバブルメディアとして認識され、例えば書き込みや読み出しといった、ストレージデバイスへの命令を受け付ける。USB通信機３０００はエアコン４０００と、例えばBluetooth（登録商標、以下同様）規格に基づいた無線通信を行う。USB通信機３０００は、コンテンツ再生機１００から受け付けたストレージデバイスへの命令を、エアコン４０００の制御命令に変換してエアコン４０００へ送信する。またUSB通信機３０００は、エアコン４０００から送信されたデータを受信して、コンテンツ再生機１００に対してリムーバブルディスク内のファイルとして提供する。
【０１０４】
エアコン４０００はECHONET（登録商標）に対応しており、運転のＯＮあるいはＯＦＦを、Bluetooth通信を介してコントローラからの命令によって切り替えられる。また、運転状況などをコントローラへ通知すべく送信することができる。本実施の形態では、コントローラは、コンテンツ再生機１００とUSB通信機３０００とで構成されているかたちとなる。
【０１０５】
本実施の形態におけるコンテンツ情報のアプリケーション処理記述データには、ECHONETアプリケーションへの命令が含まれる。ECHONETアプリケーションの命令は、EOJ（ECHONETオブジェクト：制御対象機器の識別子）、EPC（ECHONETプロパティ：制御対象機器の制御対象機能を表す識別子）、EDT（ECHONETデータ：制御対象機能に対してセットする値）を含むものとして説明する。
【０１０６】
図１４はUSB通信機３０００のブロック図である。
【０１０７】
USB通信機３０００は、USBIF３００１、プロトコル変換部３００２、通信部３００３、記憶部３００４を備える。
【０１０８】
USBIF３００１は、USBマスストレージクラスに対応するストレージペリフェラルとして、外部USBホスト装置とデータの通信を行う（本実施の形態では外部USBホスト装置はコンテンツ再生機１０００である）。
【０１０９】
プロトコル変換部３００２はECHONETの通信ミドルウェアおよびサービスミドルウェアと、さらに上位のアプリケーションソフトウェアを実行する。プロトコル変換部３００２は、その動作によって生成される情報を記憶する記憶部３０１２を備える。
【０１１０】
通信部３００３は、エアコン４０００と、Bluetooth通信を行う。
【０１１１】
以下、本実施の形態のUSB通信機３０００の動作を、USB接続フェーズと、イベント監視フェーズと、命令実行フェーズに分けて説明する。
【０１１２】
図１５はUSB接続フェーズのUSB通信機３０００の動作を表すフローチャートである。
【０１１３】
プロトコル変換部３００２は、USBIF３００１がUSBホスト機器と接続されたことを認識すると、通信部３００３を介して通信できるBluetooth対応機器を探索する（ステップ４０１）。
【０１１４】
次に、見つかったBluetooth対応機器がさらにECHONETにも対応していれば（ステップ４０２のYes）、Bluetoothコネクションを確立して、通信部３００３を介してプロパティマップ要求をBluetooth通信相手へと送信して（ステップ４０３）、返答を待つ（ステップ４０４）。見つかったBluetooth対応機器がECHONETに対応していなければ（ステップ４０２のNo）、その通信相手とのコネクションを確立せずにフェーズを終了する。
【０１１５】
プロパティマップを受け取ると、プロトコル変換部３００２はそのプロパティマップに含まれるEOJ、EPC、アクセスルールをもとにした名前であって、アクセスルールをもとにした属性のテキストファイルを生成して記憶部３０１２へ記憶する（ステップ４０５）。
【０１１６】
本実施の形態ではこのファイルの名前を、"/(EOJ)/(EPC)/(アクセスルール).txt"のようにしている。ただしここで、"/"はフォルダの階層を表す。つまりこれらのファイルは、EOJ、EPC、アクセスルール毎にフォルダに分けられて管理される。エアコン４０００のEOJが0x03b701で、その運転のEPCが0x80で、そのアクセスルールが制御（set）および参照(get)可能であれば、書き込み可能属性の"/0x03b701/0x80/set.txt"と読み込み可能属性の"/0x03b701/0x80/get.txt"とを生成して記憶部３０１２へ記憶する。
【０１１７】
なお、複数のECHONETおよびBluetooth対応の機器が発見された場合、それぞれとコネクションを確立してそれぞれのプロパティマップを取得してそれら各々についてのファイル生成を行ってもよい。
【０１１８】
図１６はイベント監視フェーズのUSB通信機３０００の動作を表すフローチャートである。
【０１１９】
プロトコル変換部３００２は、通信部３００３がエアコン４０００からのアナウンスを受信すると、そのアナウンスの内容を解析する（ステップ５０１）。アナウンスにはEOJとEPCと、そのEPCが示すプロパティの値とが含まれている。
【０１２０】
プロトコル変換部３００２は、そのアナウンスに含まれるEOJとEPCと、参照可能を示すsetと、を含む名前のファイルに、そのEPCが示すプロパティの値であるEDTの値を書き込む（ステップ５０２）。
【０１２１】
このようにして、ECHONET対応機器からのアナウンスを、EOJおよびEPC毎に記憶していく。
【０１２２】
図１７は命令実行フェーズで各装置がやりとりする命令および値の関係を表す図である。
【０１２３】
コンテンツ再生機１００はまず、USB通信機３０００から、フォルダ構成やファイル名の一覧といった、フォルダ／ファイル構成を取得する。EOJがフォルダ名であることから、コンテンツ再生機１００は、取得したフォルダ／ファイル構成を解析して、USB通信機３０００がプロパティマップを取得したECHONET対応機器が何であるかをEOJに含まれるクラスコードなどから判別することができる。
【０１２４】
アプリケーション処理記述データには例えば、エアコンであるオブジェクトの運転をＯＮにする、といった命令が記述されている。アプリケーション処理記述解釈部１１２はその命令を解釈して、エアコン４０００のEOJである0x03b701のフォルダの、運転プロパティを表すEPCである0x80のフォルダの、書き込み可能属性であるset.txtへの、運転をONとするデータであるEDTの値である0x30の書き込み要求コマンドをUSBIF１０６を介して無線通信機３０００へ送る。
【０１２５】
USB通信機３０００はこの書き込み要求を受け取ると、EOJ=0x03b701、EPC=0x80、EDT=0x30のECHONETパケットを生成して、通信部３００３を介してエアコン４０００へ送信する（本実施の形態ではこのECHONETパケットが動作要求のひとつに相当する）。
【０１２６】
このパケットによってエアコン４０００はその運転をONにする。
【０１２７】
なお、USB通信機３０００は、書き込み要求を受け取りその書き込み先ファイル（set.txt）と同じフォルダ内のget.txtに記述されている値が0x30であった場合には、エアコン４０００は既に運転ONの状態であるということなので、上述のECHONETパケットを生成しないようにしてもよい。
【０１２８】
またエアコン４０００を、運転がONの状態あるいはOFFの状態から他方の状態へ変化した際に、イベントとしてUSB通信機３０００に運転プロパティの状態変化を通知してもよい。
【０１２９】
図１７ではさらに、エアコン４０００の運転がＯＮになった後に、コンテンツ再生機１００がUSB通信機３０００へ、"/0x03b701/0x80/get.txt"の読み出し要求を送っている。これに応じてUSB通信機３０００のプロトコル変換部３００２は、記憶部３０１２から"/0x03b701/0x80/get.txt"の内容を読み出し、コンテンツ再生機１００へ読み出した値を返している。このような読み出し要求は繰り返し連続して行ってもよく、例えば"/0x03b701/0x80/get.txt"の最終更新日時が前に読み出したときに比べて更新されていればそこで繰り返しを止める、といった制御としてもよい。
【０１３０】
なお、"/0x03b701/0x80/get.txt"の読み出し要求を受け取ったUSB通信機３０００に、EOJ=0x03b701、EPC=0x80のEDTを取得させるECHONETパケットをエアコン４０００に送信させてもよい（本実施の形態ではこのECHONETパケットが状態取得要求のひとつに相当する）。
【０１３１】
図１８は図１７におけるコンテンツ再生機１００の書き込み要求に係る動作を表すフローチャートである。
【０１３２】
アプリケーション処理記述解釈部１１２は、コンテンツソースからコンテンツ情報を取得すると、そこからアプリケーション処理記述データを抽出する（ステップ６０１）。
【０１３３】
次にアプリケーション処理記述解釈部１１２は、USB通信機３０００からフォルダ／ファイル構成を取得する（ステップ６０２）。フォルダ／ファイル構成から、USB通信機３０００がプロパティマップを取得したECHONET対応機器のクラスを知る。
【０１３４】
次に、アプリケーション処理記述解釈部１１２は、抽出したアプリケーション処理記述データを解釈して、アプリケーション処理記述データの命令の対象オブジェクトのクラスコードを含む名前のフォルダがあるドライブへの、EDTの値とそれを書き込むべきファイル名とを含む書き込み要求を行い（ステップ６０３）、返り値を待つ（ステップ６０４）。ここではアプリケーション処理記述データが、エアコンであるオブジェクトに対する命令なので、エアコンのEOJが名前としてつけられたフォルダを有する、USB通信機３０００を表すドライブへの書き込み要求となる。
【０１３５】
図１９は図１８に対応するUSB通信機３０００の動作を表すフローチャートである。
【０１３６】
USB通信機３０００のプロトコル変換部３００２は、コンテンツ再生機１００から書き込み要求を受け取ると、書き込み先のファイルおよびその上位フォルダの名前からEOJとEPCとを抽出する（ステップ７０１）。
【０１３７】
次にプロトコル変換部３００２は、抽出したEOJとEPCと、書き込み要求に含まれる書き込み値であるEDTと、からECHONETパケットを生成する。（ステップ７０２）。
【０１３８】
次にプロトコル変換部３００２は、生成したECHONETパケットを通信部３００３に渡して、エアコン４０００へと送信させ（ステップ７０３）、SENSE KEYの値として０をコンテンツ再生機１００へ返す（ステップ７０４）。
【０１３９】
本実施の形態では制御対象機器としてECHONET対応エアコンを挙げたが、他のネットワーク機器制御プロトコルであるUPnPなどによって制御する場合であっても発明を適宜応用することができることはいうまでもない。
【０１４０】
ECHONETでは、あるECHONET機器がどのような制御が可能であるかを調べるためにプロパティマップを用いるが、UPnP機器を制御対象とする場合はその代わりにDeviceDescriptionやServiceDescriptionと呼ばれる機器情報を用いる。ECHONETでは制御のために生成するファイルを"/(EOJ)/(EPC)/(アクセスルール).txt"としたが，UPnPではファイルとして例えば，/upnp/foo/barなどといったcontrolURLと呼ばれる制御先を特定するURLをファイル名として利用すればよい。またECHONETではそのファイルに書き込む情報をEDTとしたが、UPnPでは例えばUPnPの制御に使われるSOAPメッセージと呼ばれるXML形式の文字列を書き込むとすればよい。
【０１４１】
USB通信機１０００あるいは３０００を通じて制御する機器はECHONET対応機器のみであるとしたが、例えばECHONET機器とUPnP機器の両方を制御できるように構成することも可能であることはいうまでもない。その場合、ECHONET機器が制御デバイスに接続された際はプロパティマップに基づいた/0x03b701/0x80/get.txtなどといった制御用ファイルを生成し、UPnP機器が制御デバイスに接続された際はDeviceDescriptionに基づいた制御用ファイルを生成する、といったように、制御用の特定ファイルを，接続機器の特性に合わせて動的に生成する。
【０１４２】
さらに、USB通信機のコンテンツ再生機１００とのIFは、各実施の形態においてUSBであるとして説明したが、例えばBluetoothのFile Transfer Profileを用いる場合のようにコンテンツ再生機１００に対して自らが１つの記憶装置であるように振舞い、コンテンツ再生機１００の書き込み要求や読み出し要求を扱えるIFであればよいことはいうまでもない。
【０１４３】
以上のような構成の各実施の形態のシステムによれば、コンテンツ再生機が一般的に備えているストレージ操作機能を用いてネットワーク機器の様々な機能を制御することができる。その結果、「ネットワーク機器連動コンテンツ」を実現することができる。
【０１４４】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
【０１４５】
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
【０１４６】
また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
【０１４７】
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【０１４８】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【図面の簡単な説明】
【０１４９】
【図１】第１の実施の形態のシステム構成の概念図。
【図２】第１の実施の形態のコンテンツ再生機のブロック図。
【図３】第１の実施の形態のUSB通信機のブロック図。
【図４】第１の実施の形態の人形のブロック図。
【図５】第１の実施の形態のアプリケーション処理記述データをHTMLとJavaScriptとで記述した例。
【図６】第１の実施の形態のアプリケーション処理記述データをBMLとECMAScriptとで記述した例。
【図７】第１の実施の形態のアプリケーション処理記述データと、各装置がやりとりする命令および値の関係を表す図。
【図８】第１の実施の形態のUSB通信機のプロトコル変換部の変換規則を示す表。
【図９】第１の実施の形態のコンテンツ再生機の読み出し動作に係るフローチャート。
【図１０】第１の実施の形態のUSB通信機の動作に係るフローチャート。
【図１１】第１の実施の形態のコンテンツ再生機の、書き込み動作に係るフローチャートである。
【図１２】第１の実施の形態のUSB通信機の動作に係るフローチャート。
【図１３】第２の実施の形態の本実施の形態のシステム構成の概念図。
【図１４】第２の実施の形態のUSB通信機３０００のブロック図。
【図１５】第２の実施の形態のUSB接続フェーズのUSB通信機３０００の動作を表すフローチャート。
【図１６】第２の実施の形態のイベント監視フェーズのUSB通信機３０００の動作を表すフローチャート。
【図１７】第２の実施の形態の命令実行フェーズで各装置がやりとりする命令および値の関係を表す図。
【図１８】第２の実施の形態のコンテンツ再生機の書き込み要求に係るフローチャート。
【図１９】第２の実施の形態のUSB通信機の動作を表すフローチャート。
【符号の説明】
【０１５０】
１００・・・コンテンツ再生機、１０００，３０００・・・ＵＳＢ通信機、２０００・・・人形、４０００・・・エアコン。
【特許請求の範囲】
【請求項１】
所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との両方と通信を行う通信装置において、
前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供するファイル構成提供手段と、
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段と、
前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段と、
を備えることを特徴とする通信装置。
【請求項２】
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスは、書き込み要求であり
前記プロトコル変換手段は、前記書き込み要求に含まれる書き込み内容によって、前記動作要求で要求する動作の種類が異なることを特徴とする請求項１記載の通信装置。
【請求項３】
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスは、書き込み要求および読み出し要求であり
前記プロトコル変換手段は、前記書き込み要求を前記被制御装置への動作要求に変換し、前記読み出し要求を前記被制御装置への状態取得要求に変換することを特徴とする請求項１記載の通信装置。
【請求項４】
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスは、前記ファイルの名前を含み、
前記プロトコル変換手段は、前記ファイルの名前に応じて、生成する前記制御命令情報を変えることを特徴とする請求項１記載の通信装置。
【請求項５】
前記ファイルシステムフォーマットは、ファイルとそれを配下とするフォルダとで表され、
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスは、前記フォルダの名前と前記ファイルの名前とを含み、
前記プロトコル変換手段は、前記フォルダの名前および前記ファイルの名前に応じて、生成する前記制御命令情報を変えることを特徴とする請求項１記載の通信装置。
【請求項６】
前記プロトコル変換手段は、前記フォルダの名前および前記ファイルの名前のうち、少なくとも一方に基づいて前記被制御側装置への状態取得要求を生成するか動作要求を生成するかを判断することを特徴とする請求項５記載の通信装置。
【請求項７】
所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との通信を制御する通信制御方法において、
前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供し、
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換し、
前記制御命令情報を前記被制御側装置へ提供する
ことを特徴とする通信制御方法。
【請求項１】
所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との両方と通信を行う通信装置において、
前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供するファイル構成提供手段と、
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換するプロトコル変換手段と、
前記制御命令情報を前記被制御側装置へ提供する制御命令提供手段と、
を備えることを特徴とする通信装置。
【請求項２】
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスは、書き込み要求であり
前記プロトコル変換手段は、前記書き込み要求に含まれる書き込み内容によって、前記動作要求で要求する動作の種類が異なることを特徴とする請求項１記載の通信装置。
【請求項３】
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスは、書き込み要求および読み出し要求であり
前記プロトコル変換手段は、前記書き込み要求を前記被制御装置への動作要求に変換し、前記読み出し要求を前記被制御装置への状態取得要求に変換することを特徴とする請求項１記載の通信装置。
【請求項４】
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスは、前記ファイルの名前を含み、
前記プロトコル変換手段は、前記ファイルの名前に応じて、生成する前記制御命令情報を変えることを特徴とする請求項１記載の通信装置。
【請求項５】
前記ファイルシステムフォーマットは、ファイルとそれを配下とするフォルダとで表され、
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスは、前記フォルダの名前と前記ファイルの名前とを含み、
前記プロトコル変換手段は、前記フォルダの名前および前記ファイルの名前に応じて、生成する前記制御命令情報を変えることを特徴とする請求項１記載の通信装置。
【請求項６】
前記プロトコル変換手段は、前記フォルダの名前および前記ファイルの名前のうち、少なくとも一方に基づいて前記被制御側装置への状態取得要求を生成するか動作要求を生成するかを判断することを特徴とする請求項５記載の通信装置。
【請求項７】
所定のファイルシステムフォーマットで記憶装置へのアクセスを行う制御側装置と所定の制御プロトコルで機能が外部から制御されることが可能である被制御側装置との通信を制御する通信制御方法において、
前記制御側装置へ前記ファイルシステムフォーマットに準拠したファイル構成情報を提供し、
前記制御側装置からの前記ファイル構成情報に含まれるファイルへのアクセスを、前記制御プロトコルに準拠し前記被制御側装置の前記機能を制御する制御命令情報に変換し、
前記制御命令情報を前記被制御側装置へ提供する
ことを特徴とする通信制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２００７−１７９２５５（Ｐ２００７−１７９２５５Ａ）
【公開日】平成１９年７月１２日（２００７．７．１２）
【国際特許分類】
【出願番号】特願２００５−３７６２５５（Ｐ２００５−３７６２５５）
【出願日】平成１７年１２月２７日（２００５．１２．２７）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成１９年７月１２日（２００７．７．１２）
【国際特許分類】
【出願日】平成１７年１２月２７日（２００５．１２．２７）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]