JP2003008610A

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

Info

Publication number: JP2003008610A
Application number: JP2001186646A
Authority: JP
Inventors: Takuro Noda; 卓郎野田; Makoto Sato; 真佐藤; Yukihiko Aoki; 幸彦青木
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2001-06-20
Filing date: 2001-06-20
Publication date: 2003-01-10

Abstract

(57)【要約】【課題】 UPnPコントロールポイントから１３９４機器
を制御できるようにする。【解決手段】 IEEE８０２ネットワーク１１には、UPnP
コントロールポイント１が接続されており、IEEE１３９
４ネットワーク１２には、１３９４機器３，４が接続さ
れている。IEEE８０２ネットワーク１１とIEEE１３９４
ネットワーク１２は、ブリッジとして機能するUPnPデバ
イス２を介して接続されている。UPnPデバイス２は、UP
nPコントロールポイント１から送信されてきたパケット
を変換し、IEEE１３９４ネットワーク１２を介して１３
９４機器３に転送する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理装置およ
び方法、記録媒体、並びプログラムに関し、特に、IEEE
８０２に基づく第１のネットワークとIEEE１３９４に基
づく第２のネットワークの一方に接続されている機器
が、他方に接続されている機器を制御することができる
ようにした、情報処理装置および方法、記録媒体、並び
プログラムに関する。

【０００２】

【従来の技術】最近、IEEE（Institute of Electrical
and Electronics Engineers）１３９４高速シリアルバ
スを用いたネットワーク（以下、単にIEEE１３９４ネッ
トワークと称する）が普及してきた。オーディオ機器や
ビデオ機器を、このIEEE１３９４ネットワークに接続す
ることで、各機器は、AV/Cコマンドを用いて、他の機器
を制御することができる。

【０００３】一方、IEEE８０２ネットワークも普及して
いる。このIEEE８０２は、主にパーソナルコンピュータ
を相互に接続するためのネットワークであり、UPnP（Un
iversal Plag and Play）のプロトコルに基づいて、各
パーソナルコンピュータは、他のパーソナルコンピュー
タを制御することができる。

【０００４】

【発明が解決しようとする課題】しかしながら、このIE
EE１３９４ネットワークとIEEE８０２ネットワークと
は、それぞれ独立したものであり、IEEE８０２ネットワ
ークに接続されている機器（以下、UPnP機器と称する）
は、IEEE１３９４ネットワークに接続されている機器
（以下、１３９４機器と称する）を制御することができ
ない課題があった。

【０００５】本発明はこのような状況に鑑みてなされた
ものであり、UPnP機器が、１３９４機器を制御できるよ
うにするものである。

【０００６】

【課題を解決するための手段】本発明の情報処理装置
は、第１のネットワークからの第１のパケットを取り込
む取り込み手段と、取り込み手段により取り込まれた第
１のパケットを、第２のネットワークの第２のパケット
に変換する変換手段と、変換手段により変換された第２
のパケットを、第２のネットワークに送信する送信手段
とを備え、変換手段が、IEEE１３９４のバスの情報を管
理する第１のサービス手段と、IEEE１３９４のノードに
対するサービスを実行する第２のサービス手段とを備え
ることを特徴とする。

【０００７】前記変換手段は、第１のサービス手段と、
第２のサービス手段を、１つのルートデバイス内に有す
ることができる。

【０００８】前記変換手段は、第１のサービス手段を第
１のルートデバイス内に有するとともに、第２のサービ
ス手段を、デバイス毎に異なる第２のルートデバイス内
に有することができる。

【０００９】前記変換手段は、第１のサービス手段と、
デバイス毎に異なる第２のサービス手段を、１つのルー
トデバイス内に有することができる。

【００１０】前記変換手段は、第１のサービス手段を１
つのルートデバイス内に有するとともに、デバイス毎に
異なる第２のサービス手段を内蔵するエンベデッドデバ
イスを、１つのルートデバイス内に有することができ
る。

【００１１】本発明の情報処理方法は、第１のネットワ
ークからの第１のパケットを取り込む取り込みステップ
と、取り込みステップの処理により取り込まれた第１の
パケットを、第２のネットワークの第２のパケットに変
換する変換ステップと、変換ステップの処理により変換
された第２のパケットを、第２のネットワークに送信す
る送信ステップとを含み、変換ステップが、IEEE１３９
４のバスの情報を管理する第１のサービスステップと、
IEEE１３９４のノードに対するサービスを実行する第２
のサービスステップとを含むことを特徴とする。

【００１２】本発明の記録媒体のプログラムは、第１の
ネットワークからの第１のパケットを取り込む取り込み
ステップと、取り込みステップの処理により取り込まれ
た第１のパケットを、第２のネットワークの第２のパケ
ットに変換する変換ステップと、変換ステップの処理に
より変換された第２のパケットを、第２のネットワーク
に送信する送信ステップとを含み、変換ステップが、IE
EE１３９４のバスの情報を管理する第１のサービスステ
ップと、IEEE１３９４のノードに対するサービスを実行
する第２のサービスステップとを含むことを特徴とす
る。

【００１３】本発明のプログラムは、第１のネットワー
クからの第１のパケットを取り込む取り込みステップ
と、取り込みステップの処理により取り込まれた第１の
パケットを、第２のネットワークの第２のパケットに変
換する変換ステップと、変換ステップの処理により変換
された第２のパケットを、第２のネットワークに送信す
る送信ステップとを含み、変換ステップが、IEEE１３９
４のバスの情報を管理する第１のサービスステップと、
IEEE１３９４のノードに対するサービスを実行する第２
のサービスステップとを含む。

【００１４】本発明の情報処理装置および方法、記録媒
体、並びにプログラムにおいては、IEEE１３９４のバス
の情報を管理する第１サービスと、IEEE１３９４のノー
ドに対するサービスを実行する第２のサービスとが、第
１のネットワークと第２のネットワークとに接続された
情報処理装置において実行される。

【００１５】

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

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

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

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

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

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

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

【００２２】ディスカバリは、アドレシングの後に行わ
れ、これによりUPnPコントロールポイント１は、コント
ロールしたいターゲット機器を発見することができる。
ここで用いられるプロトコルは、SSDP（Simple Serivic
e 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デバイス（１３９４プロキシ）２は、
IEEE８０２ネットワーク１１とIEEE１３９４ネットワー
ク１２との間のブリッジとして機能し、内部に、図３に
示されるデバイスモデルを有する。この例のデバイスモ
デルは、１個のルートデバイス（root device）６１で
構成され、このルートデバイス６１は、IEEE１３９４プ
ロキシサービス（IEEE１３９４ proxy service）７１と
IEEE１３９４ノードサービス（IEEE１３９４nodes serv
ice）７２とを有している。

【００３６】IEEE１３９４プロキシサービス（以下、単
に、プロキシサービスと称する）７１は、IEEE１３９４
ネットワーク１２のバスリセット発生、バスID、ノード
の数、バスマネージャ、アイソクロナスリソースマネー
ジャのノードユニークID（NUID）、ギャップカウント
（Gap Count）、セルフIDパケット（Self IDパケット）
などを管理する。

【００３７】IEEE１３９４ノードサービス（以下、単に
ノードサービスと称する）７２は、Link-Onパケット、P
hy Configurationパケットを含むPhyパケットなど、並
びにasynchronousパケットの授受を行う。

【００３８】図４は、このasynchronousパケットの構成
を表している。

【００３９】Asynchronous通信は、非同期にデータの通
信をする際に用いられる。このAsynchronous通信では、
相手ノードに確実にパケットを送信することが保証さ
れ、送信の遅延時間は保証されない。送信ノードは、ヘ
ッダ情報と実データを指定先のノードに送信し、受信ノ
ードは、Acknowledgeパケットを返信することで、パケ
ットを受け取ったことを相手方に通知する。ただし、相
手先ノードを指定しないブロードキャストパケットが受
信された場合には、Acknowledgeパケットは返されな
い。

【００４０】１３９４パケットヘッダの先頭には、dest
ination_ID（Destination identifier）が配置されてい
る。これは、パケット送信先のnode_IDを表す。

【００４１】tl（Transaction label）は、requestパケ
ットとresponseパケットの一対のトランザクションの一
致を認識するためのラベルである。requestパケットのt
lがresponseパケットのtlとしても使われる。

【００４２】rt（Retry code）は、busyのAcknowledge
を受信した時のリトライ方法に関する情報を表す。

【００４３】tcode（Transaction code）は、トランザ
クションパケットの種別コードを表す。即ち、read/wri
te/lock、またはrequest/responseのいずれであるのか
が表される。

【００４４】pri（Priority）は、fair arbitrationで
はall０（cycle startを除く）とされる。

【００４５】source_ID（Source indentifier）は、パ
ケット送信元のnode_IDを表す。

【００４６】source_IDの次には、packet-type-specifi
c informationが配置され、さらに、必要に応じて、pac
ket-type-specific dataが配置される。１３９４パケッ
トヘッダの最後に、以上のヘッダ情報に対するCRCがhad
er_CRCとして挿入される。

【００４７】１３９４パケットヘッダに続いて、データ
ブロックが配置される。データブロックは、必要な数の
data block quadletと、データ情報に対するCRCとして
のdata_CRCにより構成される。

【００４８】次に、図５のフローチャートを参照して、
IEEE８０２ネットワーク１１に接続されているUPnPコン
トロールポイント１が、IEEE１３９４ネットワーク１２
に接続されている機器を制御する場合の処理について説
明する。

【００４９】ステップＳ１において、UPnPコントロール
ポイント１は、１３９４プロキシデバイス２を構成する
プロキシサービス７１に、IEEE１３９４ネットワーク１
２に変化があった場合、これを通知してくれるように、
サブスクライブ（SUBSCRIBE）する。ステップＳ１１に
おいて、プロキシサービス７１は、このサブスクライブ
を受け取ると、それに対応する処理を実行する。

【００５０】例えば、今、１３９４機器３がステップＳ
３１において、IEEE１３９４ネットワーク１２に接続さ
れたとすると、ステップＳ３２において、１３９４機器
３にバスリセットが発生し、同様に、ステップＳ２１に
おいて、ルートデバイス６１のノードサービス７２に、
バスリセットが発生する。このとき、ノードサービス７
２は、ステップＳ２２において、このバスリセットの発
生を、プロキシサービス７１に通知する。

【００５１】プロキシサービス７１は、ステップＳ１２
において、ノードサービス７２からの通知を検知する
と、ステップＳ１１において取り込んだUPnPコントロー
ルポイント１からのサブスクライブに基づいて、ステッ
プＳ１３において、UPnPコントロールポイント１に対し
て、１３９４機器３がIEEE１３９４ネットワーク１２に
接続されたことを通知（NOTIFY）する。

【００５２】ステップＳ２において、UPnPコントロール
ポイント１は、プロキシサービス７１からの通知を受け
取る。これにより、UPnPコントロールポイント１は、IE
EE１３９４ネットワーク１２に１３９４機器３が接続さ
れたことを知ることができる。

【００５３】そこで、ステップＳ３において、UPnPコン
トロールポイント１は、１３９４機器３のレジスタの所
定のアドレスに記録されている情報を読み出すためのas
ynchronous read request commandに対応するSOAPに基
づくActionのrequest packetをインボーク（Invoke）す
る。

【００５４】図６は、このときUPnPコントロールポイン
ト１からノードサービス７２に転送されるリクエストメ
ッセージの例を表している。UPnPコントロールポイント
１は、後述する図１４に示される１３９４Nodes Servic
e Descriptionを参照して、このリクエストメッセージ
を生成する。

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

【００５６】Bodyに含まれるnuidは、このメッセージの
送信相手のノードユニークID（NUID）を表す。今の例の
場合、１３９４機器３のNUIDを表す。このNUID「０８０
０４６００００００００００」は、ステップＳ２の処理
で、プロキシサービス７１から取得した通知に記述され
ていたものである。このNUIDは、ノードサービス７２が
有する対応表に基づいて、１３９４機器３のノードID
（図７の例の場合、「ffc０」に変換され、図７のパケ
ットのdestination_IDに格納される。

【００５７】asyncRequestは、UPnPコントロールポイン
ト１がノードサービス７２に対して発生を要求するコマ
ンドの種類を表している。すなわち、この例において
は、asynchronous read request commandの発生が要求
されている。

【００５８】asyncRequestに含まれるMSB側の「０００
００１４０００００」（１６進数）は、ノードサービス
７２が発生する図７に示されるread request for data
quadlet packetにおける図７のトランザクションラベル
tl、リトライコードrt、トランザクションコードtcod
e、およびプライオリティPriを表している。

【００５９】LSB側の「fffff００００４０４」は、図７
のdestination_offsetに対応する。すなわち、この値が
UPnPコントロールポイント１が読み出したい１３９４機
器３のレジスタのアドレスを表している。

【００６０】なお、図７のsource_IDフィールドには、
ノードサービス７２のノードID（図７の例の場合、「ff
c１」）が記述される。

【００６１】これらの値は全てテキストで表されている
ため、IEEE１３９４のどの種類のパケットも記述するこ
とが可能となる。

【００６２】図５に戻って、ノードサービス７２は、ス
テップＳ２３において、図６に示されるActionのインボ
ークを受け取ると、ステップＳ２４において、それに対
応して、図７に示されるようなaysnchronous read requ
estのパケットを生成し、IEEE１３９４ネットワーク１
２を介して１３９４機器３に送信する。このとき、ノー
ドサービス７２は、図６に示されるリクエストと、図７
に示されるリクエストパケットの対応関係を対応表に記
憶する。

【００６３】１３９４機器３は、ステップＳ３３におい
て、ノードデバイス７２より送信されてきたasynchrono
us read requestパケットを受信すると、そのリクエス
トに対応する処理（いまの場合、レジスタの読み出し）
を実行する。ステップＳ３４において、１３９４機器３
は、requestパケットに対応する図８に示されるようなr
esponseパケットを生成し、ノードサービス７２に送信
する。

【００６４】図８に示されるように、トランザクション
コードtcodeの値は、responoseを表す値「６」とされて
いる。

【００６５】destination_IDとsource_IDの値は、図７
のread request for data quadlet packetにおける値
が、そのまま使用されている。quadlet dataには、dest
ination_offsetのアドレスから読み出されたデータが配
置されている。

【００６６】ノードサービス７２は、ステップＳ２５に
おいて、１３９４機器３から送信されてきたresponseパ
ケットを受信すると、ステップＳ２６において、図９に
示されるようなSOAPプロトコルに基づくActionとしてRe
sponseを生成し、UPnPコントロールポイント１に送信す
る。

【００６７】対応表に基づいて図９に示されるTransact
ionに示される値「５」は、図６のActionと対をなすAct
ionであることを表すために、図６におけるTransaction
の値「５」に対応して「５」（同一の値）とされる。

【００６８】また、図９のBodyには、１３９４のasychr
onous read responseに対応するものであることを表す
ように「asyncResponse」が記述されている。そして、
そこには、「０００００１６００００００００００００
０００００３１３３３９３４」のデータが記述されてい
る。このデータは、図８のquadlet dataに記述されてい
た値であり、１３９４機器３のオフセットアドレスから
読み取られた値である。ステップＳ４において、UPnPコ
ントロールポイント１は、この値を読み取る。

【００６９】以上の処理を実行するために、図３に示さ
れる１３９４プロキシ２が有するデバイスモデルのルー
トデバイス６１は、図１０に示される１３９４Proxy De
viceDescriptionを有し、プロキシサービス７１は、図
１１と図１２に示される１３９４Proxy Service Descri
ptionを有し、ノードサービス７２は、図１３と図１４
に示される１３９４Nodes Service Descriptionを有す
る。

【００７０】図１０におけるdeviceType「urn:sony-cor
p:device:1394ProxyDevice:1」は、デバイスの型がProx
y Deviceであることを表している。FriendlyName「prox
y for IEEE1394」は、ルートデバイス６１のフレンドリ
ーネームを表している。

【００７１】UDN「nuid:upnp-1394proxy-root-08004600
00000000」は、ルートデバイス６１の固有の番号を表し
ている。

【００７２】このDevice Descriptionには、２つのserv
iceが記述されている。１つは、serviceTypeが「urn:so
ny-corp:service:1394ProxyService:1」であるサービス
であり、他の１つは、serviceTypeが「urn:sony-corp:s
ervice:1394NodeService:1」であるサービスである。す
なわち、前者は、図３のプロキシサービス７１に対応す
るサービスであり、後者は、図３のノードサービス７２
に対応するサービスである。

【００７３】前者のサービスのSCPDURL「./scpd/proxyS
cpd.xml」は、プロキシサービス７１が有するProxy Ser
vice DescriptionのURL（具体的には、図１１と図１２
に示されるProxy Service DescriptionのURL）を表して
いる。

【００７４】また、後者のサービスのSCPDURL「./scpd-
nodeScpd.xml」は、ノードサービス７２が有するNodes
Service Description（具体的には、図１３と図１４に
示される１３９４Nodes Service Description）のURLを
表している。

【００７５】図１１と図１２の１３９４Proxy Service
Descriptionにおけるactionは、各種のアクションを表
し、「busRest」の名称のactionは、バスリセットを起
こすアクションを表す。「getNodeNum」の名称のaction
は、１３９４バス上のノードの数を取得するアクション
を表す。「getIrmId」の名称のactionは、１３９４バス
上のIRM（Isochronous Resource Manger）のNUIDを取得
するアクションを表す。

【００７６】「getBmId」の名称のactionは、１３９４
バス上のバスマネージャのNUIDを取得するアクションを
表す。「getGapCount」の名称のactionは、１３９４バ
ス上のGap Countを取得するアクションを表す。

【００７７】「getSelfIdPacket」の名称のactionは、
１３９４バス上を流れたSelfIDパケットを取得するアク
ションを表す。

【００７８】「getNodeNume」の名称のactionには、「n
odeNum」の名称のdirectionが「out」の引数（他の機器
から出力され、転送されてくる引数）が規定されてい
る。そして、この引数「nodeNum」には、関連する規定
がserviceStateTableに記述されている。すなわち「nod
eNum」は、SUBSCRIBEしている機器に対して通知を行う
ことが記述されている。また、状態変数に変化があった
場合、「データの形が「i１」として出力される引数で
あることが記述されている。

【００７９】「getIrmId」のactionには、「nuid」の名
称の「direction」が「out」である引数が規定されてい
る。「getGapCount」のactionには、「gapCount」の名
称のdirectionが「out」の引数が規定され、「getSelfI
dPacket」の名称のactionには、「selfIdPacket」の名
称のdirectionが「out」の引数が規定されている。これ
らの引数は、状態変数に変化があった場合でもSUBCRIBE
している機器に対して通知を行わないことが記述されて
いる。また、データの形が「bin.hex」として、各機器
から出力されることが記述されている。

【００８０】図１３と図１４の１３９４Nodes Service
Descriptionには、「asyncReqSend」、「phyEPacketSen
d」、並びに「LinkOnPacketSend」のactionが規定され
ている。

【００８１】「asyncReqSend」の名称のactionは、asyn
chronousパケットを送信するアクションを表す。

【００８２】このアクションには、「nuid」の名称のdi
rectionが「in」の引数（他の機器に向けて出力され、
他の機器に入力される引数）が規定されている。そし
て、この引数「nuid」のデータタイプは、「bin.hex」
とされている。

【００８３】「asyncReqSend」のactionには、さらに、
「asyncReqest」のdirectionが「in」の引数、並びに
「asyncResponse」のdirectionが「out」の引数が、そ
れぞれ規定されている。

【００８４】同様に、「asyncRequest」の名称のdirect
ionが「in」の引数と、「asyncResponse」の名称のdire
ctionが「out」の引数は、データの形が「bin.hex」と
して規定されている。

【００８５】「phyPacketSend」の名称のactionは、Phy
パケットを送信するアクションを表す。このコマンド
は、「phyPacket」の名称のdirectionが「in」の引数
と、「phyPacketResp」の名称のdirectionが「out」の
引数が規定されて、これらの引数は関係する変数「phyP
acket」を有し、そのデータタイプは、「ui４」とされ
ている。

【００８６】「LinkOnPacketSend」の名称のactionは、
LinkOnパケットを送信するアクションを表す。このアク
ションは、「phyId」のdirectionが「in」の引数を有す
る。この引数のデータタイプは、「i１」とされる。

【００８７】図１５、図１６、および図１７は、１３９
４Proxy Device Description、１３９４ Proxy Service
Description、および１３９４ Nodes Service Descrip
tionの他の例を表している。

【００８８】図１５においては、プロキシサービス７１
に対応するserviceType「urn:sony-corp:service:1394P
roxyService:1」のserviceと、ノードサービス７２に対
応するserviceType「urn:sony-corp:service:1394NodeS
ervice:1」のserviceが規定されている。前者のサービ
スのSCPDURLには、図１６の１３９４ Proxy ServiceDes
criptionのURLが記述され、後者のSCPDURLには、図１７
の１３９４ Node Service DescriptionのURLが記述され
る。

【００８９】図１６においては、IEEE１３９４ネットワ
ーク１２上のノード数を得るactionである「getNodeNu
m」と、バスリセットを起こすactionである「busRest」
が記述されている。

【００９０】図１７においては、Async Transactionを
行う「asynchTr」の名称のactionが記述されている。こ
のアクションは「destinationNuid」、「requestPacke
t」、並びに「responsePacket」の３つの引数を有す
る。前２者のdirectionは「in」であり、最後の引数のd
irectionは「out」とされる。

【００９１】以上においては、図３に示されるように、
１個のルートデバイス６１に、１３９４プロキシサービ
ス７１とノードサービス７２を保持させるようにした
が、例えば、図１８に示されるように、プロキシサービ
ス７１をルートデバイス６１−１に保持させるととも
に、IEEE１３９４上の個々のノードに対するサービスを
各ルートデバイス毎に定義するようにすることもでき
る。図１８の例においては、ルートデバイス（root dev
ice）６１−２に、ノードサービス７２−１が保持さ
れ、root device６１−３に、ノードサービス７２−２
が保持される。

【００９２】図１９と図２０は、図１８のroot device
６１−１乃至６１−３が有する１３９４ Proxy Device
Descriptionの例を表し、図２１は、図１８のプロキシ
サービス７１が保持する１３９４ Proxy Service Descr
iptionの例を表し、図２２は、図１８のノードサービス
７２−１，７２−２が有する１３９４ Node ServiceDes
criptionの例を表す。

【００９３】図１９と図２０においては、root device
６１−１乃至６１−３に対応して、３つのdeviceType
「urn:schemas-upnp-org:device:1394ProxyDevice:
1」、「urn:sony-corp:device:1394NodeDevice:1」、お
よび「urn:sony-corp:device:1394NodeDevice:1」が記
述されている。

【００９４】最初の、deviceTypeのSCPDURLには、図２
１の１３９４ Proxy ServiceDescriptionのURLが記述さ
れ、後の２つのdeviceTypeのSCPDURLには、図２２の１
３９４node Service DescriptionのURLが記述される。

【００９５】図２１においては、状態に変化が起きた場
合に発生される変数「nodeNum」が規定されている。

【００９６】図２２においては、Async Transactionを
行う「asynchTr」の名称のactionが記述されている。こ
のアクションは、「requestPacket」と「responsePacke
t」の２つの引数を保持している。前者のdirectionは
「in」であり、後者のdirectionは「out」である。

【００９７】図２３は、デバイスモデルのさらに他の構
成例を表す。この例においては、１個のroot device６
１に、プロキシサービス７１と、ノードサービス７２−
１，７２−２が保持されている。すなわち、図３の例に
おいては、ノードサービスが複数のノードに共通に設け
られているのに対して、この例では、ノードサービスが
ノード毎に独立して設けられている。

【００９８】図２４は、図２３の例におけるroot devic
e６１が有する１３９４ Proxy Device Descriptionの構
成を表し、図２５は、図２３のプロキシサービス７１が
保持する１３９４ Proxy Service Descriptionの構成例
を表し、図２６は、図２３のノードサービス７２−１，
７２−２が有する１３９４ Node Service Description
の構成例を表す。

【００９９】図２４においては、３つのserviceType「u
rn:sony-corp:service:1394ProxyService:1」、「urn:s
ony-corp:service:1394NodeService:1」、「urn:sony-c
orp:service:1394NodeService:1」が記述されている。

【０１００】最初のserviceTypeのSCPDURLには、図２５
の１３９４ Proxy Service DescripitonのURLが記述さ
れ、後の２者のserviceTypeに対応するSCPDURLには、図
２６の１３９４ Node Service DescriptionのURLが記述
される。

【０１０１】図２５においては、「nodeNum」の変数が
規定されている。

【０１０２】図２６においては、async Transactionを
行う「asynchTr」のactionが規定されている。

【０１０３】図２７は、デバイスモデルのさらに他の構
成例を表している。この構成例においては、root devic
e６１にプロキシサービス７１が保持されている。ま
た、ノードサービス７２−１，７２−２は、それぞれノ
ード毎に設けられる他、root device６１に保持された
エンベデッドデバイス（embedded device）８１−１，
８１−２に、それぞれ保持される。

【０１０４】図２８と図２９は、図２７におけるroot d
evice６１が保持する１３９４ Proxy Device Descripti
onの構成例を表し、図３０は、図２７のプロキシサービ
ス７１が保持する１３９４ Proxy Service Description
の構成例を表し、図３１は、図２７のノードサービス７
２−１，７２−２が有する１３９４ Node Service Desc
riptionの構成例を表す。

【０１０５】図２８と図２９においては、プロキシサー
ビス７１、ノードサービス７２−１、ノードサービス７
２−２に、それぞれ対応するdeviceType「urn:sony-cor
p:device:1394ProxyDevice:1」、「urn:sony-corp:devi
ce:1394NodeDevice:1」、並びに「urn:sony-corp:devic
e:1394NodeDevice:1」が、それぞれ規定されている。最
初のserviceTypeに対応するSUPDURLには、図３０の１３
９４ Proxy ServiceDescriptionのURLが記述され、後の
２者のdeviceTypeに対応するSCPDURLには、図３１の１
３９４ Node Sevice DescriptionのURLが記述される。

【０１０６】図３０においては、「nodeNum」の変数が
規定されている。

【０１０７】図３１においては、async Transactionを
行う「asynchTr」のactionが記述されている。

【０１０８】次に、図３、図１８、図２３および図２７
に示すデバイスモデルを比較する。

【０１０９】図３の例においては、１つのroot device
６１に、プロキシサービス７１とノードデバイス７２
が、それぞれ１つずつ定義される。

【０１１０】図１８の例においては、プロキシサービス
７１が１つのroot device６１−１に定義されるととも
に、１３９４上の個々のノードに対するノードサービス
７２−１，７２−２が、root device６１−２，６１−
３毎に定義される。

【０１１１】図２３の例においては、プロキシサービス
７１が、１つのroot device６１に設けられる他、ノー
ドサービスが各ノード毎に対応して設けられ、それらの
ノードサービス７２−１，７２−２は、プロキシサービ
ス７１と同様に、１つのrootdevice６１に保持される。

【０１１２】図２７の例においては、１３９４上のノー
ドが全てroot device６１のembedded device８１−１，
８１−２として定義される。

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

【０１１４】タイプＡからタイプＤまでを比較すると、
SSDPのパケット量が大きく異なっていることがわかる。
すなわち、root deviceが１個のとき、SSDPの数は、３
＋２ｄ＋ｋとなる。ここで、ｄはembedded deviceの
数、ｋはサービスタイプの数を意味する。従って、１３
９４ネットワーク１２上のノードの数をＮとするとき、
SSDPのパケットの量は、タイプＡのとき５個、タイプＢ
のとき４＋４Ｎ個、タイプＣのとき４＋Ｎ個、タイプＤ
のとき４＋３Ｎ個となる。特に、タイプＢ（図１８）と
タイプＤ（図２７）の場合には、ノード数の数倍になる
数のパケットが流れることになる。そこで、ネットワー
クのトラフィックの観点から考えた場合、SSDPのパケッ
トの量が少ないタイプＡ（図３）の例が望ましい。

【０１１５】バスの構成の変更の通知は、タイプＡの場
合、GENAにより行われ、タイプＢ，Ｃ，Ｄの場合、SSDP
により行われる。

【０１１６】presentation URLの構成の単位は、タイプ
ＡとタイプＣがバス単位とされ、タイプＢとタイプＤが
ノード単位とされる。ノード毎にURLを持つことが可能
なタイプＢ（図１８）とタイプＤ（図２７）が分かりや
すいが、タイプＡ（図３）とタイプＣ（図２３）に関し
ても、プロキシサービス７１が、各ノードに対するリン
クページのようなものを用意すれば、実質的に対応する
機能は実現できると考えられる。

【０１１７】NOTIFYの通知の単位は、タイプＡの場合、
バス単位とされ、タイプＢ，Ｃ，Ｄの場合、ノード単位
とされる。

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

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

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

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

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

【０１２３】

【発明の効果】以上の如く本発明の情報処理装置および
方法、記録媒体、並びにプログラムによれば、１３９４
のバスの情報を管理する第１サービスと、ノードに対す
るサービスを実行する第２のサービスを、第１のパケッ
トを第２のパケットに変換する際に実行させるようにし
たので、簡単かつ確実に、第１のネットワークに接続さ
れている機器から、第２のネットワークに接続されてい
る機器を制御することが可能となる。

【図面の簡単な説明】

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

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

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

【図４】asynchronousパケットの構成を示す図である。

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

【図６】図５のステップＳ３において出力されるメッセ
ージの構成を示す図である。

【図７】図５のステップＳ２４の処理で出力されるパケ
ットの構成を示す図である。

【図８】図５のステップＳ３４の処理で出力されるパケ
ットの構成を示す図である。

【図９】図５のステップ２６の処理で出力されるメッセ
ージの例を示す図である。

【図１０】図３のroot deviceが有する１３９４ Proxy
Device Descriptionの構成を示す図である。

【図１１】図３の１３９４ proxy serviceが有する１３
９４ Proxy Service Descriptionの構成を示す図であ
る。

【図１２】図３の１３９４ proxy serviceが有する１３
９４ Proxy Service Descriptionの構成を示す図であ
る。

【図１３】図３の１３９４ nodes serviceが有する１３
９４ Nodes Service Descriptionの構成を示す図であ
る。

【図１４】図３の１３９４ nodes serviceが有する１３
９４ Nodes Service Descriptionの構成を示す図であ
る。

【図１５】図３のroot deviceが有する１３９４ Proxy
Device Descriptionの他の構成を示す図である。

【図１６】図３の１３９４ proxy serviceが有する１３
９４ Proxy Service Descriptionの構成を示す図であ
る。

【図１７】図３の１３９４ nodes serviceが有する１３
９４ Nodes Service Descriptionの構成を示す図であ
る。

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

【図１９】図１８のroot deviceが有する１３９４ Prox
y Device Descriptionの構成を示す図である。

【図２０】図１８のroot deviceが有する１３９４ Prox
y Device Descriptionの構成を示す図である。

【図２１】図１８の１３９４ proxy serviceが有する１
３９４ Proxy Service Descriptionの構成を示す図であ
る。

【図２２】図１８の１３９４ node serviceが有する１
３９４ Node Service Descriptionの構成を示す図であ
る。

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

【図２４】図２３のroot deviceが有する１３９４ Prox
y Device Descriptionの構成を示す図である。

【図２５】図２３の１３９４ proxy serviceが有する１
３９４ Proxy Service Descriptionの構成を示す図であ
る。

【図２６】図２３の１３９４ node serviceが有する１
３９４ Node Service Descriptionの構成を示す図であ
る。

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

【図２８】図２７のroot deviceが有する１３９４ Prox
y Device Descriptionの構成を示す図である。

【図２９】図２７のroot deviceが有する１３９４ Prox
y Device Descriptionの構成を示す図である。

【図３０】図２７の１３９４ proxy serviceが有する１
３９４ Proxy Service Descriptionの構成を示す図であ
る。

【図３１】図２７の１３９４ node serviceが有する１
３９４ Nodes Service Descriptionの構成を示す図であ
る。

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

【符号の説明】

１ UPnPコントロールポイント，２ UPnPデバイス，
３，４１３９４機器，１１ IEEE８０２ネットワ
ーク，１２ IEEE１３９４ネットワーク，６１ root
device，７１１３９４ proxy service，７２
１３９４ nodes service

───────────────────────────────────────────────────── フロントページの続き (72)発明者青木幸彦東京都品川区北品川６丁目７番35号ソニー株式会社内Ｆターム(参考） 5B089 GB01 HA06 HA18 JA35 KF05 5K033 AA09 CB02 CC01 DA05 DB19 5K034 AA20 DD03 FF12 HH61

Claims

【特許請求の範囲】

【請求項１】 IEEE８０２に基づくフォーマットの第１
のパケットで通信する第１のネットワークと、IEEE１３
９４に基づくフォーマットの第２のパケットで通信する
第２のネットワークとの間でデータを授受する情報処理
装置において、前記第１のネットワークからの前記第１のパケットを取
り込む取り込み手段と、前記取り込み手段により取り込まれた前記第１のパケッ
トを、前記第２のネットワークの前記第２のパケットに
変換する変換手段と、前記変換手段により変換された前記第２のパケットを、
前記第２のネットワークに送信する送信手段とを備え、前記変換手段は、前記IEEE１３９４のバスの情報を管理する第１のサービ
ス手段と、前記IEEE１３９４のノードに対するサービスを実行する
第２のサービス手段とを備えることを特徴とする情報処
理装置。
【請求項２】前記変換手段は、前記第１のサービス手
段と、前記第２のサービス手段を、１つのルートデバイ
ス内に有することを特徴とする請求項１に記載の情報処
理装置。
【請求項３】前記変換手段は、前記第１のサービス手
段を第１のルートデバイス内に有するとともに、前記第
２のサービス手段を、前記デバイス毎に異なる第２のル
ートデバイス内に有することを特徴とする請求項１に記
載の情報処理装置。
【請求項４】前記変換手段は、前記第１のサービス手
段と、前記デバイス毎に異なる前記第２のサービス手段
を、１つのルートデバイス内に有することを特徴とする
請求項１に記載の情報処理装置。
【請求項５】前記変換手段は、前記第１のサービス手
段を１つのルートデバイス内に有するとともに、前記デ
バイス毎に異なる前記第２のサービス手段を内蔵するエ
ンベデッドデバイスを、前記１つのルートデバイス内に
有することを特徴とする請求項１に記載の情報処理装
置。
【請求項６】 IEEE８０２に基づくフォーマットの第１
のパケットで通信する第１のネットワークと、IEEE１３
９４に基づくフォーマットの第２のパケットで通信する
第２のネットワークとの間でデータを授受する情報処理
装置の情報処理方法において、前記第１のネットワークからの前記第１のパケットを取
り込む取り込みステップと、前記取り込みステップの処理により取り込まれた前記第
１のパケットを、前記第２のネットワークの前記第２の
パケットに変換する変換ステップと、前記変換ステップの処理により変換された前記第２のパ
ケットを、前記第２のネットワークに送信する送信ステ
ップとを含み、前記変換ステップは、前記IEEE１３９４のバスの情報を管理する第１のサービ
スステップと、前記IEEE１３９４のノードに対するサービスを実行する
第２のサービスステップとを含むことを特徴とする情報
処理方法。
【請求項７】 IEEE８０２に基づくフォーマットの第１
のパケットで通信する第１のネットワークと、IEEE１３
９４に基づくフォーマットの第２のパケットで通信する
第２のネットワークとの間でデータを授受する情報処理
装置のプログラムであって、前記第１のネットワークからの前記第１のパケットを取
り込む取り込みステップと、前記取り込みステップの処理により取り込まれた前記第
１のパケットを、前記第２のネットワークの前記第２の
パケットに変換する変換ステップと、前記変換ステップの処理により変換された前記第２のパ
ケットを、前記第２のネットワークに送信する送信ステ
ップとを含み、前記変換ステップは、前記IEEE１３９４のバスの情報を管理する第１のサービ
スステップと、前記IEEE１３９４のノードに対するサービスを実行する
第２のサービスステップとを含むことを特徴とするコン
ピュータが読み取り可能なプログラムが記録されている
記録媒体。
【請求項８】 IEEE８０２に基づくフォーマットの第１
のパケットで通信する第１のネットワークと、IEEE１３
９４に基づくフォーマットの第２のパケットで通信する
第２のネットワークとの間でデータを授受する情報処理
装置を制御するコンピュータに実行させるプログラムで
あって、前記第１のネットワークからの前記第１のパケットを取
り込む取り込みステップと、前記取り込みステップの処理により取り込まれた前記第
１のパケットを、前記第２のネットワークの前記第２の
パケットに変換する変換ステップと、前記変換ステップの処理により変換された前記第２のパ
ケットを、前記第２のネットワークに送信する送信ステ
ップとを含み、前記変換ステップは、前記IEEE１３９４のバスの情報を管理する第１のサービ
スステップと、前記IEEE１３９４のノードに対するサービスを実行する
第２のサービスステップとを含むプログラム。