JP2003008583A

JP2003008583A - 情報処理装置および方法、記録媒体、並びにプログラム

Info

Publication number: JP2003008583A
Application number: JP2001186645A
Authority: JP
Inventors: Takuro Noda; 卓郎野田; Makoto Sato; 真佐藤; Yukihiko Aoki; 幸彦青木; Hisato Shima; 久登嶋
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2001-06-20
Filing date: 2001-06-20
Publication date: 2003-01-10
Anticipated expiration: 2021-06-20
Also published as: JP3661935B2; CN1465164A; EP1398911A1; WO2003001744A1; KR20030028574A; US20040030793A1

Abstract

(57)【要約】【課題】 IEEE８０２ネットワークに接続されている機
器が、相互に通信することが可能な安価なシステムを実
現できるようにする。【解決手段】 IEEE８０２ネットワーク１１には、UPnP
コントロールポイント１とUPnPデバイス２が接続されて
いる。UPnPコントロールポイント１は、UPnPデバイス２
を制御するとき、制御内容を、IEEE１３９４ネットワー
クにおいて用いられるAV/Cコマンドに基づいて記述す
る。そして、UPnPコントロールポイント１は、そのAV/C
コマンドを、IEEE８０２ネットワーク１１において用い
られるSOAPに基づくコマンドに格納する。このSOAPに基
づくコマンドが、IEEE８０２ネットワーク１１を介して
UPnPデバイス２に転送される。UPnPデバイス２は、SOAP
に基づくコマンドからAV/Cコマンドを抽出し、対応する
処理を実行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理装置およ
び方法、記録媒体、並びプログラムに関し、特に、IEEE
８０２に基づくネットワークに接続されている機器が、
簡単、かつ確実に、相互に通信し、制御することができ
る安価なシステムを実現できるようにした、情報処理装
置および方法、記録媒体、並びプログラムに関する。

【０００２】

【従来の技術】最近、IEEE（Institute of Electrical
and Electronics Engineers）８０２ネットワークが普
及してきた。このIEEE８０２は、主にパーソナルコンピ
ュータを相互に接続するためのネットワークであり、UP
nP（Universal Plag and Play）のプロトコルに基づい
て、各パーソナルコンピュータは、他のパーソナルコン
ピュータを制御することができる。

【０００３】

【発明が解決しようとする課題】UPnPの規定には、Devi
ce Descripitionに機器情報を記述することや、SOAP（S
imple Object Access Protocol）や、GENA（General Ev
ent Notification Architecture）というトロランスポ
ートプロトコルが規定されている。

【０００４】しかしながら、この規定には、機器のモデ
ルや命令体系が規定されておらず、機器同士が、相互に
一方が他方を制御するなどのために通信することができ
ない課題があった。

【０００５】このような通信を可能にするには、共通の
新たなプロトコルを構築する必要があるが、そのために
は、膨大な時間とコストがかかる課題があった。

【０００６】本発明はこのような状況に鑑みてなされた
ものであり、簡単かつ確実に、低コストで通信が可能と
なるようにするものである。

【０００７】

【課題を解決するための手段】本発明の情報処理装置
は、ネットワークから、IEEE１３９４のAV/Cコマンドが
格納されたSOAPに基づくコマンドを取り込む取り込み手
段と、取り込み手段により取り込まれたSOAPに基づくコ
マンドから、格納されているAV/Cコマンドを抽出する抽
出手段と、抽出手段により抽出されたAV/Cコマンドに基
づいて、対応する処理を実行する実行手段とを備えるこ
とを特徴とする。

【０００８】前記AV/Cコマンドを生成する生成手段と、
生成手段により生成されたAV/Cコマンドを、SOAPに基づ
くコマンドに格納する格納手段と、格納手段によりAV/C
コマンドが格納されたSOAPに基づくコマンドを、ネット
ワークに送信する送信手段とをさらに備えるようにする
ことができる。

【０００９】前記実行手段は、AV/Cコマンドに対応し
て、ファイナルレスポンスを送信することができる。

【００１０】前記実行手段は、AV/Cコマンドを受け取っ
てから、所定の時間内にファイナルレスポンスを送信す
ることができない場合、INTERIMを送信することができ
る。

【００１１】前記実行手段は、デバイスモデルを有し、
デバイスモデルは、root deviceを有し、root device
は、所定のactionを実行するAV/C サービスを有するこ
とができる。

【００１２】前記実行手段は、デバイスモデルを有し、
デバイスモデルは、IEEE１３９４のユニットとサブユニ
ットにそれぞれ対応するroot deviceとembedded device
を有し、root deviceとembedded deviceは、それぞれ所
定のactionを実行するAV/Cサービスを保持することがで
きる。

【００１３】前記実行手段は、デバイスモデルを有し、
デバイスモデルは、IEEE１３９４のユニットとサブユニ
ットにそれぞれ対応するroot deviceとembedded device
を有し、root deviceとembedded deviceは、それぞれAV
/Cコマンドのopcode毎に、所定のactionを実行するAV/C
サービスを保持することができる。

【００１４】本発明の情報処理方法は、ネットワークか
ら、IEEE１３９４のAV/Cコマンドが格納されたSOAPに基
づくコマンドを取り込む取り込みステップと、取り込み
ステップの処理により取り込まれたSOAPに基づくコマン
ドから、格納されているAV/Cコマンドを抽出する抽出ス
テップと、抽出ステップの処理により抽出されたAV/Cコ
マンドに基づいて、対応する処理を実行する実行ステッ
プとを含むことを特徴とする。

【００１５】本発明の記録媒体のプログラムは、ネット
ワークから、IEEE１３９４のAV/Cコマンドが格納された
SOAPに基づくコマンドを取り込む取り込みステップと、
取り込みステップの処理により取り込まれたSOAPに基づ
くコマンドから、格納されているAV/Cコマンドを抽出す
る抽出ステップと、抽出ステップの処理により抽出され
たAV/Cコマンドに基づいて、対応する処理を実行する実
行ステップとを含むことを特徴とする。

【００１６】本発明のプログラムは、ネットワークか
ら、IEEE１３９４のAV/Cコマンドが格納されたSOAPに基
づくコマンドを取り込む取り込みステップと、取り込み
ステップの処理により取り込まれたSOAPに基づくコマン
ドから、格納されているAV/Cコマンドを抽出する抽出ス
テップと、抽出ステップの処理により抽出されたAV/Cコ
マンドに基づいて、対応する処理を実行する実行ステッ
プとを実行させる。

【００１７】本発明の情報処理装置および方法、記録媒
体、並びにプログラムにおいては、SOAPに基づくコマン
ドに格納されているAV/Cコマンドが抽出され、処理され
る。

【００１８】

【発明の実施の形態】図１は、本発明を適用したネット
ワークシステムの構成を表している。この構成において
は、IEEE８０２ネットワーク１１に、UPnPコントロール
ポイント１とUPnPデバイス２が接続されている。

【００１９】図２は、UPnPデバイス２の構成例を表して
いる。図２において、CPU（CentralProcessing Unit）
２１は、ROM（Read Only Memory）２２に記憶されてい
るプログラム、または記憶部２８からRAM（Random Acce
ss Memory）２３にロードされたプログラムに従って各
種の処理を実行する。RAM２３にはまた、CPU２１が各種
の処理を実行する上において必要なデータなども適宜記
憶される。

【００２０】CPU２１、ROM２２、およびRAM２３は、バ
ス２４を介して相互に接続されている。このバス２４に
はまた、入出力インタフェース２５も接続されている。

【００２１】入出力インタフェース２５には、キーボー
ド、マウスなどよりなる入力部２６、CRT、LCDなどより
なるディスプレイ、並びにスピーカなどよりなる出力部
２７、ハードディスクなどより構成される記憶部２８、
モデム、ターミナルアダプタなどより構成される通信部
２９が接続されている。通信部２９は、IEEE８０２ネッ
トワーク１１を介しての通信処理を行う。

【００２２】入出力インタフェース２５にはまた、必要
に応じてドライブ３０が接続され、磁気ディスク４１、
光ディスク４２、光磁気ディスク４３、或いは半導体メ
モリ４４などが適宜装着され、それらから読み出された
コンピュータプログラムが、必要に応じて記憶部２８に
インストールされる。

【００２３】UPnP機器（図１の例の場合、UPnPコントロ
ールポイント１およびUPnPデバイス２）は、主に、アド
レシング（Addressing）、ディスカバリ（Discover
y）、ディスクリプション（Decription）、コントロー
ル（Control）、イベンティング（Eventing）、プレゼ
ンテーション（Presentation）の６つの機能を有してい
る。

【００２４】アドレシングは、各UPnP機器が、IEEE８０
２ネットワーク１１上でアドレスを取得するための機能
であり、DHCP（Dynamic Host Configuration Protoco
l）またはAutoIPが用いられる。

【００２５】ディスカバリは、アドレシングの後に行わ
れ、これによりUPnPコントロールポイント１は、コント
ロールしたいターゲット機器を発見することができる。
ここで用いられるプロトコルは、SSDP（Simple Service
Discovery Protocol）である。各機器は、IEEE８０２
ネットワーク１１に接続されたとき、自分自身の中に有
するデバイスやサービスを通知するメッセージをIEEE８
０２ネットワーク１１上にマルチキャストする（特に、
相手を指定しないでパケットを送信する）。UPnPコント
ロールポイント１は、このマルチキャストされたメッセ
ージを受信することで、IEEE８０２ネットワーク１１
に、どのような機器が接続されたのかを知ることができ
る。

【００２６】逆に、UPnPコントロールポイント１の方か
ら、現在IEEE８０２ネットワーク１１に接続されている
機器を調べることもできる。このとき、UPnPコントロー
ルポイント１は、発見したいデバイスやサービスをキー
ワードとして、検索コマンドをIEEE８０２ネットワーク
１１上にマルチキャストする。IEEE８０２ネットワーク
１１に接続されている各機器は、マルチキャストされた
検索コマンドに規定されている条件に自分自身が適合す
る場合、その検索コマンドに対してレスポンスをユニキ
ャストする（相手側を指定して、パケットを送信す
る）。これにより、UPnPコントロールポイント１は、IE
EE８０２ネットワーク１１に接続されている機器を検知
することができる。

【００２７】また、各機器は、IEEE８０２ネットワーク
１１から外れるときも、事前にその旨をブロードキャス
トする。

【００２８】ディスカバリによりUPnPコントロールポイ
ント１が発見したコントロール対象の機器が出力したSS
DPパケットには、デバイスディスクリプション（Device
Description）のURL（Uniform Resource Locator）が
記述されている。UPnPコントロールポイント１は、その
URLにアクセスすることにより、その機器のさらに詳し
いデバイス情報をデバイスディスクリプションから得る
ことができる。このデバイス情報には、アイコン情報、
モデル名、生産者名、商品名などが含まれている。

【００２９】また、このデバイス情報には、そのデバイ
スが有するサービス情報が記述されており、そのサービ
スの詳しい情報が記述されているサービスディスクリプ
ション（Service Discription）も、サービス情報に記
述されているURLから辿ることができる。

【００３０】UPnPコントロールポイント１は、これらの
デバイス情報（Device Description）やサービス情報
（Service Description）から、ターゲットに対するア
クセスの方法を知ることができる。

【００３１】また、デバイスディスクリプションには、
後述するPresentation URLも記述されている。

【００３２】Device DescriptionおよびService Descri
ptionは、XML（Extensible MarkupLanguage）で表現さ
れている。

【００３３】Controlは、アクション（Action）とクエ
リー（Query）の２つに大きく分類される。Actionは、S
ervice Descriptionのアクション情報に規定された方法
で行われ、ActionをInvokeすることにより、UPnPコント
ロールポイント１は、ターゲットを操作することができ
る。

【００３４】一方、Queryは、Service Descriptionのst
ateVariableの値を取り出すために用いられる。stateVa
riableの値は、機器の状態を表している。

【００３５】Controlでは、SOAP（Simple Object Acces
s Protocol）というトランスポートプロトコルが利用さ
れる。その表現言語としては、XMLが用いられる。

【００３６】イベンティング（Eventing）は、stateVar
iableの値が変更されたとき、そのことをターゲットか
ら、UPnPコントロールポイント１に通知させるために用
いられる。UPnPコントロールポイント１は、Service De
scription を解析することにより、stateVariableから
ターゲットの保持する変数を知ることができる。UPnPコ
ントロールポイント１はターゲットに対して、Subscrip
tionを出力しておくことにより、その変数のうち、send
Eventsがyesになっている変数に関して、変数の変更が
あったとき、ターゲットから通知を受け取ることができ
る。Eventingでは、GENA（General Event Notification
Architecture）というトランスポートプロトコルが利
用される。その表現言語としては、XMLが用いられる。

【００３７】プレゼンテーション（Presentation）は、
ユーザにユーザインタフェース（UI）を用いたコントロ
ール手段を提供するために用いられる。Device Descrip
tionに記述されたPresentation URLにアクセスすること
で、HTML（Hyper Text Markup Language）によって記述
されたPresentation Pageを得ることができる。その機
能により、ターゲットでアプリケーションを用意するこ
とができる。

【００３８】UPnPデバイス２は、内部に、図３に示され
るデバイスモデルを有する。この例のデバイスモデル
は、１個のルートデバイス（root device）６１で構成
され、このルートデバイス６１は、AV/Cサービス（AV/C
service）７１を有している。

【００３９】AV/Cサービス７１は、UPnPコントロールポ
イント１から送られてきたSOAPに基づくコマンドからAV
/Cコマンドを抽出し、処理する。また、AV/Cサービス７
１は、SOAPに基づくコマンドに、IEEE１３９４のAV/Cコ
マンドに基づく制御内容を生成、格納し、送信する処理
を行う。

【００４０】図４は、このAV/Cコマンドフレームのフォ
ーマットを表している。

【００４１】CTSフィールドには、コマンドセットの種
類が記述される。その値の「０」（１６進数）（２進数
だと「００００」）は、そのコマンドセットがAV/Cコマ
ンドセットであることを表す。

【００４２】ctypeフィールドには、そのパケットがコ
マンドであるのか、レスポンスであるのか、コマンドで
ある場合にはコマンドの機能分類、レスポンスである場
合にはコマンドの処理結果の分類が記述される。

【００４３】図５は、このようなコマンドとレスポンス
の例を表している。同図に示されるように、コマンドと
しては、大きく分けて４種類のコマンドが用意されてい
る。

【００４４】CONTROL（ctype＝００００）は、機能を外
部から制御するコマンドである。

【００４５】STATUS（ctype＝０００１）は、外部から
状態を問い合わせるコマンドである。

【００４６】さらに、制御コマンドのサポートの有無を
外部から問い合わせるコマンドとして、GENERAL INQUIR
Y（ctype＝００１０）とSPECIFIC INQUIRY（ctype＝０
０１０）がある。前者は、opcodeサポートの有無を問い
合わせるコマンドであり、後者は、opcodeとoperandsの
サポートの有無を問い合わせるコマンドである。

【００４７】NOTIFY（ctype＝００１１）は、状態の変
化を外部に知らせるように要求するコマンドである。但
し、本発明では、このNOTIFYは使用されない。

【００４８】レスポンスは、コマンドの種別に応じて返
される。

【００４９】CONTROLコマンドに対するレスポンスとし
ては、以下のようなものがある。

【００５０】NOT IMPLEMENTED（ctype＝１０００）は、
コマンドが実装されていないことを通知する。ACCEPTED
（ctype＝１００１）は、コマンドが実行されたことを
通知する。REJECTED（ctype＝１０１０）は、コマンド
が実行できなかったことを通知する。

【００５１】INTERIM（ctype＝１１１１）は、コマンド
が処理中であることを通知する。

【００５２】STATUSコマンドに対するレスポンスとして
は、NOT IMPLEMENTEDとREJECTEDの他、IN TRANSITIONと
STABLEがある。

【００５３】IN TRANSITION（ctype＝１０１１）は、ス
テータスが遷移中であることを通知する。STABLEはステ
ータスが遷移中でなく、安定していることを通知する。

【００５４】GENERAL INQUIRYおよびSPECIFIC INQUIRY
コマンドに対するレスポンスとしては、IMPLEMENTEDとN
OT IMPLEMENTEDがある。IMPLEMENTED（ctype＝１１０
０）は、コマンドが実装されていることを通知する。

【００５５】NOTIFYコマンドに対するレスポンスとして
は、NOT IMPLEMENTED，REJECTED，INTERIM，CHANGEDが
ある。

【００５６】INTERIMは、NOTIFYが受け付けられたこと
をまず通知する。CHANGED（ctype＝１１０１）は、その
後、ターゲットの状態が変化したことを通知する。但
し、本発明においては、AV/Cコマンド受信後、一定の時
間（例えば、３０秒間）が経過していてもファイナルレ
スポンスを出力することが困難な場合にも、INTERIMが
出力される。

【００５７】図４のAV/Cコマンドフレームにおけるsubu
nit_typeは、コマンドの宛先を表す。その具体的な例
が、図６に示されている。

【００５８】すなわち、subunit_typeの値の「００００
０」は、このAV/Cコマンドの宛先（サブユニット）が、
Video Monitorであることを表す。また、その値の「０
０１０１」は、その宛先がTunerであることを表す。

【００５９】subunit_typeの値の「１１１１１」は、そ
のコマンドはユニット（unit）宛であることを表す。こ
れにより、例えば、装置の電源のオンオフなどが制御さ
れる。

【００６０】図４のsubunit_typeの次には、subunit_ID
が配置される。このsubunit_IDは、ユニット（unit）内
に、同じ種類のサブユニット（subunit）が複数個存在
する場合の判別を行うために、判別番号として用いられ
る。従って、結局、subunit_typeとsubunit_IDの２つに
より、コマンドの宛先が特定されることになる。

【００６１】opcodeは命令動作を表し、operandは命令
の付加的条件を表す。

【００６２】図６には、scbunit_typeがTunerである場
合におけるopcodeの例が表されている。Tunerのopcode
の場合、その値のＣ８ｈは、DIRECT SELECT INFORMATIO
N TYPEを表し、その値のＣＢｈは、DIRECT SERECT DATA
を表す。

【００６３】このように、各subunit毎に、opcodeのテ
ーブルが用意される。また、各opcode毎に、operandが
定義される。

【００６４】例えば、チューナの選局が行われる場合、
opcodeは、DIRECT SELECT INFORMATION TYPEとされ、op
erandで周波数やチャンネル番号などのパラメータが指
定される。

【００６５】次に、図７のフローチャートを参照して、
UPnPコントロールポイント１が、UPnPデバイス２を制御
する処理について、UPnPデバイス２の電源をオンさせる
場合を例として説明する。

【００６６】ステップＳ１において、UPnPコントロール
ポイント１は、UPnPデバイス２の所定の動作を制御する
（いまの場合、UPnPデバイス２の電源をオンする）ため
のAV/Cコマンドを生成し、それをSOAPに基づくActionの
request packetに格納し、インボーク（Invoke）する。

【００６７】図８は、このときUPnPコントロールポイン
ト１からUPnPデバイス２に転送されるSOAPに基づくコマ
ンドのメッセージの例を表している。UPnPコントロール
ポイント１は、UPnPデバイス２が有する、後述する図１
２と図１３に示されるUPnP Device DescriptionとUPnP
Service Descriptionを参照して、このメッセージを作
成する。

【００６８】Transactionに含まれる数字「５」は、コ
マンドに対応してレスポンスが返送されてくるので、そ
のレスポンスがどのコマンドに対応するものであるのか
を認識させるためのラベルとしてのトランザクションラ
ベルを表している。

【００６９】command「００ＦＦＢ２７０」は、UPnPコ
ントロールポイント１がUPnPデバイス２に対して要求す
るAV/Cコマンドで記述された制御の内容を表している。

【００７０】commandに含まれるMSB側の「００ＦＦ」
（１６進数）は、図９に示されるAV/CPOWER control co
mmand（２進数）におけるCTS「００００」、ctype「０
０００」、subunit_type「１１１１１」、並びにsubuni
t_ID「１１１」に対応している。すなわち、１６進数の
「００ＦＦ」を２進数で表すと、「００００００００１
１１１１１１１」になる。

【００７１】次の「Ｂ２」はopcodeに対応し、「７０」
は、operandに対応する。

【００７２】これらのコマンドの内容を表す値は全てテ
キストで表されているため、どの種類のAV/Cコマンドも
記述することが可能となる。

【００７３】図７に戻って、UPnPデバイス２は、ステッ
プＳ１１において、図８に示されるActionのインボーク
を受け取ると、そのコマンドの内容に対応して、装置の
電源をオンする。

【００７４】その後、ステップＳ１２において、UPnPデ
バイス２のAV/Cサービス７１は、その処理に対応する図
１０に示されるようなAV/Cレスポンス（AV/C POWER res
ponse）を生成し、図１１に示されるようなSOAPプロト
コルに基づくActionとしてResponseに格納し、UPnPコン
トロールポイント１に送信する。

【００７５】図１１に示されるTransactionに示される
値「５」は、図８のAction（Command）と対をなすActio
n（Responce）であることを表すために、図８におけるT
ransactionの値「５」に対応して「５」（同一の値）と
されている。

【００７６】そのresponse「０９FFB２７０」（１６進
数）は、図１０のAV/C POWER responseに記述されてい
る２進数の値「００００１００１１１１１１１１１１０
１０００１００１１１００００」に対応している。

【００７７】UPnPコントロールポイント１は、ステップ
Ｓ２において、このレスポンスを受信する。これによ
り、UPnPコントロールポイント１は、UPnPデバイス２が
装置の電源をオンしたことを知ることができる。

【００７８】AV/Cの規則の規定によれば、AV/C機器は、
受信したリクエストに対応する処理を直ちに実行できな
いとき、INTERIMをレスポンスとして返すことが規定さ
れている。そのAV/C機器は、その後、そのリクエストに
対応する処理が完了したとき、その時点において、ファ
イナルレスポンスをリクエストの送信者に返すことにな
る。しかしながら、リクエストを受信してから、ファイ
ナルレスポンスが返されるまでの時間は規定されていな
い。

【００７９】本発明では、AV/Cサービス７１は、ステッ
プＳ１１の処理でUPnPコントロールポイント１に対して
AV/Cコマンドを出力した後、ステップＳ２５の処理で、
UPnPコントロールポイント１からコマンドを受けてか
ら、ステップＳ１２の処理で、ファイナルレスポンスを
送信するまでの時間を予測する。予め設定されている所
定の時間（例えば、３０秒間）以内にファイナルレスポ
ンスが送信可能である場合、AV/Cサービス７１は、INTE
RIMをUPnPコントロールポイント１に直ちに転送せず、
コマンドに対応する処理が完了するまで待機し、３０秒
以内に処理を完了したとき、ファイナルレスポンスをUP
nPコントロールポイント１に出力する。

【００８０】これに対して、３０秒以内にコマンドに対
応する処理が完了しない場合、AV/Cサービス７１は、IN
TERIMをUPnPコントロールポイント１に出力する。そし
て、処理が完了したとき、ファイナルレスポンスが送送
信される。これにより、UPnPコントロールポイント１
は、少なくとも３０秒間以内に要求した処理が完了でき
るか否かを知ることができる。

【００８１】以上の処理を実行するために、図３に示さ
れるUPnPデバイス２（UPnPコントロールポイント１も同
様）が有するデバイスモデルのルートデバイス６１は、
図１２に示されるUPnP Device Descriptionを有し、AV/
Cサービス７１は、図１３に示されるUPnP Service Desc
riptionを有する。

【００８２】これらのDescriptionは、その機器が有す
る機能を実行するとき必要とするパラメータ、その他の
条件を記述したものであり、他の機器は、その機器に、
その機能の実行を要求するとき、そのDescriptionを参
照することで、そこに記述されている条件を付加して、
その機器にコマンドを送ることになる。

【００８３】図１２におけるdeviceType「urn:schemas-
upnp-org:device:unitDevice:1」は、ルートデバイス６
１の型が、unit Deviceであることを表している。Frien
dlyName「AV/C on UPnP Device」は、ルートデバイス６
１のフレンドリーネームを表している。

【００８４】UDN「nuid:upnp-avcupnp-root-0800460000
000000」は、ルートデバイス６１の固有の番号を表して
いる。

【００８５】このUPnP Device Descriptionにおいて
は、サービスの型であるServiceTypeが「urn:schemas-u
pnp-org:service:avcService:1」であり、serviceIdが
「urn:sony-corp:serviceId:avcService0」であるservi
ceが規定されている。

【００８６】SCPDURL「./scpd/scpd.xml」は、AV/Cサー
ビス７１が有するUPnP Service DescriptionのURL（具
体的には、図１３に示されるUPnP Service Description
のURL）を表している。

【００８７】図１３のUPnP Service Descriptionには、
AV/Cサービス７１が実行するアクションが記述されてい
る。「avcCommandSend」は、AV/Cコマンドを送信するア
クションを表す。このアクションには、argumentとし
て、「avcCommand」や「avcResponese」のパラメータが
付加されている。これらのパラメータのデータの形は、
serviceStateTableに「bin.hex」であることが規定され
ている。

【００８８】図１４、並びに図１５と図１６には、UPnP
Device Descriptionと、UPnP Service Descriptionの
他の例が、それぞれ示されている。

【００８９】図１４の例においては、serviceIdが「ur
n:sony-corp:serviceId:avcService0」のserviceが記述
されている。このSCPDURLの「./scpd/scpd.xml」は、図
１５と図１６に示されるUPnP Service DescriptionのUR
Lを表している。

【００９０】図１５と図１６には、AV/Cコマンドを送る
アクションである「avcCommandSend」が記述されてい
る。このactionには、「avcCommand」、「InTrLabe
l」、「avcResponse」、「outTrLabel」の４つのパラメ
ータが規定されている。これらには、関連する状態変数
として、「avcCommand」、「trLabel」、「avcRespons
e」、「trLabel」がそれぞれ規定されており、それぞれ
は、「serviceStateTable」に、データの形が「bin.he
x」であることが規定されている。

【００９１】なお、diriectionの「in」は、そのパラメ
ータが、このDescriptionを有する機器から、他の機器
に入力されるものであることを表し、「out」は、他の
機器から出力され、このDescriptionを有する機器に送
信されてくるパラメータであることを表す。

【００９２】stateVariable sendEvents=noは、その変
数の状態が変化したときでもSUBSCRIBEしている機器に
対して通知をしないものであることを表す。

【００９３】以上においては、図３に示されるように、
１個のルートデバイス６１に、１個のAV/Cサービス７１
を保持させるようにしたが、例えば、図１７に示される
ように、root deviceをunitに対応させるとともに、emb
edded deviceをsubunitに対応させることができる。そ
して、この例の場合、各deviceが、AV/C serviceを１つ
だけ有する。

【００９４】具体的には、図１７の例においては、root
device６１が、AV/C service７１−１を有し、root de
vice６１が有するembedded device８１−１と８１−２
が、それぞれAV/C service７１−２と７１−３を有す
る。

【００９５】図１８と図１９は、図１７のroot device
６１が有するUPnP Device Descriptionと、AV/C servic
e７１−１が有するUPnP Device Descriptionの構成例を
表している。

【００９６】図１８の例においては、deviceTypeが「ur
n:sony-corp:device:unitDevice:1」であるdeviceが設
けられ、このdeviceは、serviceIdが「urn:sony-corp:s
erviceId:avcService0」であるserviceTypeが「urn:son
y-corp:service:avcService:1」のserviceを有してい
る。そのSCPDURL「./scpd/root/scpd.xml」には、例え
ば、図１９のUPnP Service DescriptionのURLが記述さ
れる。

【００９７】また、このdeviceには、さらにdeviceType
が「urn:sony-corp:device:discDevice:1」であるdevic
e（embdded device８１−１に対応する）が記述されて
いる。このdeviceは、serviceTypeが「urn:sony-corp:s
ervice:avcService:1」のserviceが記述されている。そ
のSCPDURLの「./scpd/disc0/scpd.xml」は、例えば、AV
/C sevice７１−２が有するservice DescriptionのURL
を表している。

【００９８】図１９においては、AV/Cコマンドを送るア
クション「avcCommandSend」が記述されている。このア
クションは、「avcCommand」と「avcResponce」の２つ
の引数を有している。これらの引数のデータの形は、se
rviceStatTableに「bin.hex」として規定されている。

【００９９】図２０は、デバイスモデルのさらに他の構
成例を表す。この例においては、図１７の例と同様に、
root deviceがunitに対応され、embedded deviceがsupu
nitに対応される。ただし、この例においては、図１７
の例と異なり、それぞれのdeviceにおいて対応するAV/C
コマンドのopcode毎に、serviceが１つづつ定義され
る。

【０１００】具体的には、図２０の例においては、root
device６１がpower service９１−１の他、他のopcode
に対応するservice９１−２を有する。

【０１０１】また、embedded device８１−１は、play
service９２−１を有する他、他のAV/Cコマンドのopcod
eに対応するservice９２−２を有する。

【０１０２】さらに、embedded device８１−２も、pla
y service９２−３を有する他、他のopcpdeに対応するs
ervice２２−４を有する。

【０１０３】各serviceにおいて、Controlは、actionに
より実現され、Statusは、Queryにより実現され、Notif
yは、GENAにより実現される。General Inquiryは、Devi
ceDescriptionにより代用することが可能である。

【０１０４】図２１と図２２は、図２０の例におけるro
ot device６１が有するUPnP DeviceDescriptionの構成
を表し、図２３は、図２０のpower service９１−１が
保持するUPnP service Descriptionの構成例を表してい
る。

【０１０５】図２１のdeviceType「urn:sony-corp:devi
ce:rootDevice:1」は、図２０のroot device６１に対応
し、そのserviceType「urn:sony-corp:service:avcPowe
rService:1」は、図２０のpower service９１−１に対
応する。

【０１０６】deviceType「urn:sony-corp:device:discD
evice:1」は、図２０のembedded device８１−１に対応
し、そのserviceType「urn:sony-corp:service:avcPray
Service:1」は、play service９２−１に対応し、そのs
erviceType「urn:sony-corp:service:avcStopService:
1」は、embedded device８１−１が有する他のservice
９２−２に対応する。

【０１０７】power service９１−１に対応するservice
のSCPDULの「./scpd/root/power/scpd.xml」には、例え
ば、図２３のUPnP Service DescriptionのURLが記述さ
れる。

【０１０８】serviceTypeが、「urn:sony-corp:servic
e:avcPlayService:1」のSCPDURL「./scpd/disc0/play/s
cpd.xml」は、play service９２−１が援用するService
DescriptionのURLが記述される。同様に、serviceType
が「urn:sony-corp:service:avcStopService:1」のSCPD
URL「./scpd/disc0/stop/scpd.xml」は、service９２−
３が援用するservice Descriptionが記述される。

【０１０９】図２３の例においては、AV/Cコマンドを送
る「avcCommandSend」のactionが記述されている。これ
らには、「avcCommand」と「avcResponse」の２つの引
数が付加されており、それぞれのデータの形は、servic
eStateTableに「bin.hex」として規定されている。

【０１１０】図２４は、図３、図１７、および図２０の
デバイスモデルの特徴の比較結果を表している。なお、
図２４において、タイプＡ、タイプＢ、およびタイプＣ
は、それぞれ図３、図１７、または図２０のデバイスモ
デルに対応している。

【０１１１】タイプＡからタイプＣまでを比較すると、
SSDPのパケット量が大きく異なっていることがわかる。
すなわち、root deviceが１個のとき、SSDPの数は、３
＋２ｄ＋ｋとなる。ここで、ｄはembedded deviceの
数、kはサービスタイプの数を意味する。従って、subun
itの数をＮとするとき、SSDPのパケットの量は、タイプ
Ａのとき４個、タイプＢのとき４＋３Ｎ個、タイプＣの
とき３＋２Ｎ＋Ｃ個となる。なお、Ｃは、対応している
opcodeの延べの数を表している。

【０１１２】特に、タイプＢ（図１７）の場合には、su
bunit数の数倍になる数のパケットが流れることにな
る。そこで、ネットワークのトラフィックの観点から考
えた場合、SSDPのパケットの量が少ないタイプＡ（図
３）の例が望ましい。

【０１１３】NOTIFYの通知の単位は、タイプＡとタイプ
Ｂの場合、全コマンド単位とされ、タイプＣの場合、各
コマンド単位とされる。

【０１１４】以上を総合すると、タイプＡ（図３）の例
が最適と考えられる。

【０１１５】以上においては、UPnPコントロールポイン
ト１から、UPnPデバイス２を制御する場合を例とした
が、UPnPデバイス２から、UPnPコントロールポイント１
を制御することも可能である。ただし、この場合、UPnP
デバイス２が、上述したUPnPコントロールポイントとな
り、UPnPコントロールポイントが、UPnPデバイスとなる
ので、結局は、上述した場合と同様となる。

【０１１６】上述した一連の処理は、ハードウエアによ
り実行させることもできるが、ソフトウエアにより実行
させることもできる。一連の処理をソフトウエアにより
実行させる場合には、そのソフトウエアを構成するプロ
グラムが、専用のハードウエアに組み込まれているコン
ピュータ、または、各種のプログラムをインストールす
ることで、各種の機能を実行することが可能な、例えば
汎用のパーソナルコンピュータなどに、ネットワークや
記録媒体からインストールされる。

【０１１７】この記録媒体は、図２に示すように、装置
本体とは別に、ユーザにプログラムを提供するために配
布される、プログラムが記録されている磁気ディスク４
１（フロッピディスクを含む）、光ディスク４２（CD-R
OM(Compact Disk-Read OnlyMemory),DVD(Digital Versa
tile Disk)を含む）、光磁気ディスク４３（ＭＤ（Mini
-Disk）を含む）、もしくは半導体メモリ４４などより
なるパッケージメディアにより構成されるだけでなく、
装置本体に予め組み込まれた状態でユーザに提供され
る、プログラムが記録されているROM２２や、記憶部２
８に含まれるハードディスクなどで構成される。

【０１１８】なお、本明細書において、記録媒体に記録
されるプログラムを記述するステップは、記載された順
序に沿って時系列的に行われる処理はもちろん、必ずし
も時系列的に処理されなくとも、並列的あるいは個別に
実行される処理をも含むものである。

【０１１９】また、本明細書において、システムとは、
複数の装置により構成される装置全体を表すものであ
る。

【０１２０】

【発明の効果】以上の如く本発明の情報処理装置および
方法、記録媒体、並びにプログラムによれば、SOAPに基
づくコマンドに格納されたAV/Cコマンドを抽出し、処理
するようにしたので、新たなコマンド体系を構築する必
要がなく、簡単かつ確実に、ネットワークに接続されて
いる機器を制御することができる安価なシステムを実現
することが可能となる。

【図面の簡単な説明】

【図１】本発明が適用されるネットワークシステムの構
成を示す図である。

【図２】図１のUpnPデバイス２の構成を示すブロック図
である。

【図３】図１のUPnPデバイス２が有するデバイスモデル
の構成を示す図である。

【図４】AV/Cコマンドフレームの構成を示す図である。

【図５】ctypeを説明する図である。

【図６】subunit_typeを説明する図である。

【図７】図１のネットワークシステムの処理を説明する
フローチャートである。

【図８】図７のステップＳ１において出力されるコマン
ドの構成を示す図である。

【図９】図８のコマンドに格納されるAV/Cコマンドの構
成を示す図である。

【図１０】図１１のコマンドに格納されるAV/Cレスポン
スの構成を示す図である。

【図１１】図７のステップ１２の処理で出力されるレス
ポンスの例を示す図である。

【図１２】図３のroot deviceが有するUPnP Device Des
criptionの構成を示す図である。

【図１３】図３のAV/C serviceが有するUPnP Service D
escriptionの構成を示す図である。

【図１４】図３のroot serviceが有するUPnP Device De
scriptionの他の構成を示す図である。

【図１５】図３のAV/C serviceが有するUPnP Service D
escriptionの他の構成を示す図である。

【図１６】図３のAV/C serviceが有するUPnP Service D
escriptionの他の構成を示す図である。

【図１７】デバイスモデルの他の構成を示す図である。

【図１８】図１７のroot deviceが有するUPnP Device D
escriptionの構成を示す図である。

【図１９】図１７のAV/C serviceが有するUPnP Service
Descriptionの構成を示す図である。

【図２０】デバイスモデルのさらに他の構成を示す図で
ある。

【図２１】図２０のroot deviceが有するUPnP Device D
escriptionの構成を示す図である。

【図２２】図２０のroot deviceが有するUPnP Device D
escriptionの構成を示す図である。

【図２３】図２０のAV/C serviceが有するUPnP Service
Descriptionの構成を示す図である。

【図２４】デバイスモデルの比較を示す図である。

【符号の説明】

１ UPnPコントロールポイント，２ UPnPデバイス，
１１ IEEE８０２ネットワーク，６１ root devic
e，７１ AV/C service

───────────────────────────────────────────────────── フロントページの続き (72)発明者青木幸彦東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者嶋久登東京都品川区北品川６丁目７番35号ソニー株式会社内Ｆターム(参考） 5K033 BA04 CB14 DA13 DB12 DB14

Claims

【特許請求の範囲】

【請求項１】 IEEE８０２のSOAPに基づくフォーマット
のネットワークに接続され、他の情報処理装置と通信す
る情報処理装置において、前記ネットワークから、IEEE１３９４のAV/Cコマンドが
格納された前記SOAPに基づくコマンドを取り込む取り込
み手段と、前記取り込み手段により取り込まれた前記SOAPに基づく
コマンドから、格納されている前記AV/Cコマンドを抽出
する抽出手段と、前記抽出手段により抽出された前記前記AV/Cコマンドに
基づいて、対応する処理を実行する実行手段とを備える
ことを特徴とする情報処理装置。
【請求項２】前記AV/Cコマンドを生成する生成手段
と、前記生成手段により生成された前記AV/Cコマンドを、前
記SOAPに基づくコマンドに格納する格納手段と、前記格納手段により前記AV/Cコマンドが格納された前記
SOAPに基づくコマンドを、前記ネットワークに送信する
送信手段とをさらに備えることを特徴とする請求項１に
記載の情報処理装置。
【請求項３】前記実行手段は、前記AV/Cコマンドに対
応して、ファイナルレスポンスを送信することを特徴と
する請求項１に記載の情報処理装置。
【請求項４】前記実行手段は、前記AV/Cコマンドを受
け取ってから、所定の時間内に前記ファイナルレスポン
スを送信することができない場合、INTERIMを送信する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】前記実行手段は、デバイスモデルを有
し、前記デバイスモデルは、root deviceを有し、前記r
oot deviceは、所定のactionを実行するAV/Cサービスを
有することを特徴とする請求項１に記載の情報処理装
置。
【請求項６】前記実行手段は、デバイスモデルを有
し、前記デバイスモデルは、IEEE１３９４のユニットと
サブユニットにそれぞれ対応するroot deviceとembedde
d deviceを有し、前記root deviceとembedded device
は、それぞれ所定のactionを実行するAV/C サービスを
保持することを特徴とする請求項１に記載の情報処理装
置。
【請求項７】前記実行手段は、デバイスモデルを有
し、前記デバイスモデルは、IEEE１３９４のユニットと
サブユニットにそれぞれ対応するroot deviceとembedde
d deviceを有し、前記root deviceとembedded device
は、それぞれAV/Cコマンドのopcode毎に、所定のaction
を実行するAV/C サービスを保持することを特徴とする
請求項１に記載の情報処理装置。
【請求項８】 IEEE８０２のSOAPに基づくフォーマット
のネットワークに接続され、他の情報処理装置と通信す
る情報処理装置の情報処理方法において、前記ネットワークから、IEEE１３９４のAV/Cコマンドが
格納された前記SOAPに基づくコマンドを取り込む取り込
みステップと、前記取り込みステップの処理により取り込まれた前記SO
APに基づくコマンドから、格納されている前記AV/Cコマ
ンドを抽出する抽出ステップと、前記抽出ステップの処理により抽出された前記前記AV/C
コマンドに基づいて、対応する処理を実行する実行ステ
ップとを含むことを特徴とする情報処理方法。
【請求項９】 IEEE８０２のSOAPに基づくフォーマット
のネットワークに接続され、他の情報処理装置と通信す
る情報処理装置のプログラムであって、前記ネットワークから、IEEE１３９４のAV/Cコマンドが
格納された前記SOAPに基づくコマンドを取り込む取り込
みステップと、前記取り込みステップの処理により取り込まれた前記SO
APに基づくコマンドから、格納されている前記AV/Cコマ
ンドを抽出する抽出ステップと、前記抽出ステップの処理により抽出された前記前記AV/C
コマンドに基づいて、対応する処理を実行する実行ステ
ップとを含むことを特徴とするコンピュータが読み取り
可能なプログラムが記録されている記録媒体。
【請求項１０】 IEEE８０２のSOAPに基づくフォーマッ
トのネットワークに接続され、他の情報処理装置と通信
する情報処理装置を制御するコンピュータに、前記ネットワークから、IEEE１３９４のAV/Cコマンドが
格納された前記SOAPに基づくコマンドを取り込む取り込
みステップと、前記取り込みステップの処理により取り込まれた前記SO
APに基づくコマンドから、格納されている前記AV/Cコマ
ンドを抽出する抽出ステップと、前記抽出ステップの処理により抽出された前記前記AV/C
コマンドに基づいて、対応する処理を実行する実行ステ
ップとを実行させるプログラム。