JP3661936B2 - 情報処理装置および方法、記録媒体、並びにプログラム - Google Patents
情報処理装置および方法、記録媒体、並びにプログラム Download PDFInfo
- Publication number
- JP3661936B2 JP3661936B2 JP2001226390A JP2001226390A JP3661936B2 JP 3661936 B2 JP3661936 B2 JP 3661936B2 JP 2001226390 A JP2001226390 A JP 2001226390A JP 2001226390 A JP2001226390 A JP 2001226390A JP 3661936 B2 JP3661936 B2 JP 3661936B2
- Authority
- JP
- Japan
- Prior art keywords
- network
- command
- soap
- format
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40091—Bus bridging
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
- H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
Description
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置および方法、記録媒体、並びプログラムに関し、特に、IEEE８０２に基づく第１のネットワークに接続されている機器が、IEEE１３９４に基づく第２のネットワークに接続されている機器を制御することができるようにした、情報処理装置および方法、記録媒体、並びプログラムに関する。
【０００２】
【従来の技術】
最近、IEEE（Institute of Electrical and Electronics Engineers）１３９４高速シリアルバスを用いたネットワーク（以下、単にIEEE１３９４ネットワークと称する）が普及してきた。オーディオ機器やビデオ機器を、このIEEE１３９４ネットワークに接続することで、各機器は、AV/Cコマンドを用いて、他の機器を制御することができる。
【０００３】
一方、IEEE８０２ネットワークも普及している。このIEEE８０２は、主にパーソナルコンピュータを相互に接続するためのネットワークであり、UPnP（Universal Plag and Play）のプロトコルに基づいて、各パーソナルコンピュータは、他のパーソナルコンピュータを制御することができる。
【０００４】
【発明が解決しようとする課題】
しかしながら、このIEEE１３９４ネットワークとIEEE８０２ネットワークとは、それぞれ独立したものであり、IEEE８０２ネットワークに接続されている機器（以下、UPnP機器と称する）は、IEEE１３９４ネットワークに接続されている機器（以下、AV/C機器と称する）を制御することができない課題があった。
【０００５】
本発明はこのような状況に鑑みてなされたものであり、UPnP機器が、AV/C機器を制御できるようにするものである。
【０００６】
【課題を解決するための手段】
本発明の情報処理装置は、第１のネットワークから第１のフォーマットのデータを取り込む取り込み手段と、取り込み手段により取り込まれた第１のフォーマットのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換して第２のフォーマットに格納するとともに、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID を、対応表に基づいてノード ID に変換する変換手段と、変換手段により変換された第２のフォーマットを、第２のネットワークに送信する送信手段とを備えることを特徴とする
【０００８】
前記変換手段は、SOAPに基づくコマンドと、それに基づいて第２のネットワークに送信されるコマンドとの対応表を有し、第２のネットワークを介して受信したレスポンスに対応するSOAPに基づくコマンドを、対応表に基づいて検索し、SOAPに基づくコマンドに対応するレスポンスを第１のネットワークに送信することができる。
【０００９】
前記変換手段は、SOAPに基づくコマンドに含まれるトランザクションラベルに基づいて、SOAPに基づくコマンドとレスポンスを対応させることができる。
【００１０】
前記変換手段は、第１のネットワークに接続されている機器からのリクエストに対応するファイナルレスポンスが、予め定められている時間内に、第２のネットワークに接続されている機器から受信されないとき、第１のネットワークに接続されている機器に対して処理中であることを表すレスポンスを送信することができる。
【００１１】
前記SOAPに基づくコマンドが、第２のネットワークのバスリセット時に再送を要求するコマンドである場合、第２のネットワークのバスリセットを検知し、第２のネットワークにバスリセットが発生したとき、コマンドを送信する検知手段をさらに備えるようにすることができる。
【００１２】
前記変換手段は、さらに第２のネットワークのAV/Cコマンドを、第１のフォーマットのSOAPに基づくコマンドに変換して第１のフォーマットに格納し、送信手段は、さらに変換手段により変換された第１のフォーマットのSOAPに基づくコマンドを、第１のネットワークに送信することができる。
【００１３】
本発明の情報処理方法は、第１のネットワークからの第１のフォーマットのデータを取り込む取り込みステップと、取り込みステップの処理により取り込まれた第１のフォーマットのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換して第２のフォーマットに格納するとともに、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID を、対応表に基づいてノード ID に変換する変換ステップと、変換ステップの処理により変換された第２のフォーマットを、第２のネットワークに送信する送信ステップとを含むことを特徴とする。
【００１４】
本発明の記録媒体のプログラムは、第１のネットワークからの第１のフォーマットのデータを取り込む取り込みステップと、取り込みステップの処理により取り込まれた第１のフォーマットのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換して第２のフォーマットに格納するとともに、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID を、対応表に基づいてノード ID に変換する変換ステップと、変換ステップの処理により変換された第２のフォーマットを、第２のネットワークに送信する送信ステップとを含むことを特徴とする。
【００１５】
本発明のプログラムは、第１のネットワークからの第１のフォーマットのデータを取り込む取り込みステップと、取り込みステップの処理により取り込まれた第１のフォーマットのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換して第２のフォーマットに格納するとともに、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID を、対応表に基づいてノード ID に変換する変換ステップと、変換ステップの処理により変換された第２のフォーマットを、第２のネットワークに送信する送信ステップとを実行させることを特徴とする。
【００１６】
本発明の情報処理装置および方法、記録媒体、並びにプログラムにおいては、IEEE８０２に基づく第１のネットワークからのSOAPに基づくコマンドが、第２のネットワークのAV/Cコマンドに変換される。
【００１７】
【発明の実施の形態】
図１は、本発明を適用したネットワークシステムの構成を表している。この構成においては、IEEE８０２ネットワーク１１に、UPnPコントロールポイント１が接続されている。IEEE１３９４ネットワーク１２には、AV/C機器３，４が接続されている。IEEE８０２ネットワーク１１と、IEEE１３９４ネットワーク１２は、UPnPデバイス（UPnP-AV/Cプロキシ）２にそれぞれ接続されている。
【００１８】
図２は、UPnPデバイス２の構成例を表している。図２において、CPU（Central Processing Unit）２１は、ROM（Read Only Memory）２２に記憶されているプログラム、または記憶部２８からRAM（Random Access Memory）２３にロードされたプログラムに従って各種の処理を実行する。RAM２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００１９】
CPU２１、ROM２２、およびRAM２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インタフェース２５も接続されている。
【００２０】
入出力インタフェース２５には、キーボード、マウスなどよりなる入力部２６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部２７、ハードディスクなどより構成される記憶部２８、モデム、ターミナルアダプタなどより構成される通信部２９が接続されている。通信部２９は、IEEE８０２ネットワーク１１またはIEEE１３９４ネットワーク１２を介しての通信処理を行う。
【００２１】
入出力インタフェース２５にはまた、必要に応じてドライブ３０が接続され、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２８にインストールされる。
【００２２】
UPnP機器（図１の例の場合、UPnPコントロールポイント１およびUPnPデバイス２）は、主に、アドレシング（Addressing）、ディスカバリ（Discovery）、ディスクリプション（Decription）、コントロール（Control）、イベンティング（Eventing）、プレゼンテーション（Presentation）の６つの機能を有している。
【００２３】
アドレシングは、各UPnP機器が、IEEE８０２ネットワーク１１上でアドレスを取得するための機能であり、DHCP（Dynamic Host Configuration Protocol）またはAutoIPが用いられる。
【００２４】
ディスカバリは、アドレシングの後に行われ、これによりUPnPコントロールポイント１は、コントロールしたいターゲット機器を発見することができる。ここで用いられるプロトコルは、SSDP（Simple Service Discovery Protocol）である。各機器は、IEEE８０２ネットワーク１１に接続されたとき、自分自身の中に有するデバイスやサービスを通知するメッセージをIEEE８０２ネットワーク１１上にマルチキャストする（特に、相手を指定しないでパケットを送信する）。UPnPコントロールポイント１は、このマルチキャストされたメッセージを受信することで、IEEE８０２ネットワーク１１に、どのような機器が接続されたのかを知ることができる。
【００２５】
逆に、UPnPコントロールポイント１の方から、現在IEEE８０２ネットワーク１１に接続されている機器を調べることもできる。このとき、UPnPコントロールポイント１は、発見したいデバイスやサービスをキーワードとして、検索コマンドをIEEE８０２ネットワーク１１上にマルチキャストする。IEEE８０２ネットワーク１１に接続されている各機器は、マルチキャストされた検索コマンドに規定されている条件に自分自身が適合する場合、その検索コマンドに対してレスポンスをユニキャストする（相手側を指定して、パケットを送信する）。これにより、UPnPコントロールポイント１は、IEEE８０２ネットワーク１１に接続されている機器を検知することができる。
【００２６】
また、各機器は、IEEE８０２ネットワーク１１から外れるときも、事前にその旨をブロードキャストする。
【００２７】
ディスカバリによりUPnPコントロールポイント１が発見したコントロール対象の機器が出力したSSDPパケットには、デバイスディスクリプション（Device Description）のURL（Uniform Resource Locator）が記述されている。UPnPコントロールポイント１は、そのURLにアクセスすることにより、その機器のさらに詳しいデバイス情報をデバイスディスクリプションから得ることができる。このデバイス情報には、アイコン情報、モデル名、生産者名、商品名などが含まれている。
【００２８】
また、このデバイス情報には、そのデバイスが有するサービス情報が記述されており、そのサービスの詳しい情報が記述されているサービスディスクリプション（Service Description）も、サービス情報に記述されているURLから辿ることができる。
【００２９】
UPnPコントロールポイント１は、これらのデバイス情報（Device Description）やサービス情報（Service Description）から、ターゲットに対するアクセスの方法を知ることができる。
【００３０】
また、デバイスディスクリプションには、後述するPresentation URLも記述されている。
【００３１】
Device DescriptionおよびService Descriptionは、XML（Extensible Markup Language）で表現されている。
【００３２】
Controlは、アクション（Action）とクエリー（Query）の２つに大きく分類される。Actionは、Service Descriptionのアクション情報に規定された方法で行われ、ActionをInvokeすることにより、UPnPコントロールポイント１は、ターゲットを操作することができる。
【００３３】
一方、Queryは、Service DescriptionのstateVariableの値を取り出すために用いられる。stateVariableの値は、機器の状態を表している。
【００３４】
Controlでは、SOAP（Simple Object Access Protocol）というトランスポートプロトコルが利用される。その表現言語としては、XMLが用いられる。
【００３５】
イベンティング（Eventing）は、stateVariableの値が変更されたとき、そのことをターゲットから、UPnPコントロールポイント１に通知させるために用いられる。UPnPコントロールポイント１は、Service Description を解析することにより、stateVariableからターゲットの保持する変数を知ることができる。UPnPコントロールポイント１はターゲットに対して、Subscriptionを出力しておくことにより、その変数のうち、sendEventsがyesになっている変数に関して、変数の変更があったとき、ターゲットから通知を受け取ることができる。Eventingでは、GENA（General Event Notification Architecture）というトランスポートプロトコルが利用される。その表現言語としては、XMLが用いられる。
【００３６】
プレゼンテーション（Presentation）は、ユーザにユーザインタフェース（UI）を用いたコントロール手段を提供するために用いられる。Device Descriptionに記述されたPresentation URLにアクセスすることで、HTML（Hyper Text Markup Language）によって記述されたPresentation Pageを得ることができる。その機能により、ターゲットでアプリケーションを用意することができる。
【００３７】
UPnPデバイス（UPnP-AV/Cプロキシ）２は、IEEE８０２ネットワーク１１とIEEE１３９４ネットワーク１２との間のブリッジとして機能し、内部に、図３に示されるデバイスモデルを有する。この例のデバイスモデルは、１個のルートデバイス（root device）６１で構成され、このルートデバイス６１は、AV/Cプロキシサービス（AV/C proxy service）７１とAV/Cノードサービス（AV/C nodes service）７２とを有している。
【００３８】
AV/Cプロキシサービス（以下、単に、プロキシサービスと称する）７１は、IEEE１３９４ネットワーク１２のバスリセット発生、バスID、ノードの数、バスマネージャ、アイソクロナスリソースマネージャのノードユニークID（NUID）、ギャップカウント（Gap Count）、セルフIDパケット（Self IDパケット）などを管理する。
【００３９】
AV/Cノードサービス（以下、単にノードサービスと称する）７２は、SOAPに基づくコマンドと、AV/Cに基づくコマンドの変換処理を行う。
【００４０】
図４は、このAV/Cコマンドフレームのフォーマットを表している。
【００４１】
CTSフィールドには、コマンドセットの種類が記述される。その値の「００００」は、そのコマンドセットがAV/Cコマンドセットであることを表す。
【００４２】
ctypeフィールドには、そのパケットがコマンドであるのか、レスポンスであるのか、コマンドである場合にはコマンドの機能分類、レスポンスである場合にはコマンドの処理結果の分類が記述される。
【００４３】
図５は、このようなコマンドとレスポンスの例を表している。同図に示されるように、コマンドとしては、大きく分けて４種類のコマンドが用意されている。
【００４４】
CONTROL（ctype＝００００）は、機能を外部から制御するコマンドである。
【００４５】
STATUS（ctype＝０００１）は、外部から状態を問い合わせるコマンドである。
【００４６】
さらに、制御コマンドのサポートの有無を外部から問い合わせるコマンドとして、GENERAL INQUIRY（ctype＝０１００）とSPECIFIC INQUIRY（ctype＝００１０）がある。前者は、opcodeサポートの有無を問い合わせるコマンドであり、後者は、opcodeとoperandsのサポートの有無を問い合わせるコマンドである。
【００４７】
NOTIFY（ctype＝００１１）は、状態の変化を外部に知らせるように要求するコマンドである。
【００４８】
レスポンスは、コマンドの種別に応じて返される。
【００４９】
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とNOT IMPLEMENTEDがある。IMPLEMENTED（ctype＝１１００）は、コマンドが実装されていることを通知する。
【００５５】
NOTIFYコマンドに対するレスポンスとしては、NOT IMPLEMENTED，REJECTED，INTERIM，CHANGEDがある。
【００５６】
INTERIMは、NOTIFYが受け付けられたことをまず通知する。CHANGED（ctype＝１１０１）は、その後、ターゲットの状態が変化したことを通知する。
【００５７】
図４のAV/Cコマンドフレームにおけるsubunit_typeは、コマンドの宛先を表す。その具体的な例が、図６に示されている。
【００５８】
すなわち、subunit_typeの値の「０００００」は、このAV/Cコマンドの宛先（サブユニット）が、Video Monitorであることを表す。また、その値の「００１０１」は、その宛先がTunerであることを表す。
【００５９】
subunit_typeの値の「１１１１１」は、そのコマンドはユニット宛であることを表す。これにより、例えば、装置の電源のオンオフなどが制御される。
【００６０】
図４のsubunit_typeの次には、subunit_IDが配置される。このsubunit_IDは、ユニット内に、同じ種類のサブユニットが複数個存在する場合の判別を行うために、判別番号として用いられる。従って、結局、subunit_typeとsubunit_IDの２つにより、コマンドの宛先が特定されることになる。
【００６１】
opcodeは命令動作を表し、operandは命令の付加的条件を表す。
【００６２】
図６には、scbunit_typeがTunerである場合におけるopcodeの例が表されている。Tunerのopcodeの場合、その値のＣ８ｈは、DIRECT SELECT INFORMATION TYPEを表し、その値のＣＢｈは、DIRECT SERECT DATAを表す。
【００６３】
このように、各subunit毎に、opcodeのテーブルが用意される。また、各opcode毎に、operandが定義される。
【００６４】
例えば、チューナの選局が行われる場合、opcodeは、DIRECT SELECT INFORMATION TYPEとされ、operandで周波数やチャンネル番号などのパラメータが指定される。
【００６５】
次に、図７のフローチャートを参照して、IEEE８０２ネットワーク１１に接続されているUPnPコントロールポイント１が、IEEE１３９４ネットワーク１２に接続されている機器を制御する処理について、AV/C機器３の電源をオンさせる場合を例として説明する。
【００６６】
ステップＳ１において、UPnPコントロールポイント１は、UPnP-AV/Cプロキシ２を構成するルートデバイス６１のプロキシサービス７１に、IEEE１３９４ネットワーク１２に変化があった場合、これを通知してくれるように、サブスクライブ（SUBSCRIBE）する。ステップＳ１１において、プロキシサービス７１は、このサブスクライブを受け取ると、それに対応する処理を実行する。
【００６７】
例えば、今、AV/C機器３がステップＳ３１において、IEEE１３９４ネットワーク１２に接続されたとすると、ステップＳ３２において、AV/C機器３にバスリセットが発生し、同様に、ステップＳ２１において、ルートデバイス６１のノードサービス７２に、バスリセットが発生する。このとき、ノードサービス７２は、ステップＳ２２において、このバスリセットの発生を、プロキシサービス７１に通知する。
【００６８】
プロキシサービス７１は、ステップＳ１２において、ノードサービス７２からの通知を検知すると、ステップＳ１１において取り込んだUPnPコントロールポイント１からのサブスクライブに基づいて、ステップＳ１３において、UPnPコントロールポイント１に対して、AV/C機器３がIEEE１３９４ネットワーク１２に接続されたことを通知（NOTIFY）する。
【００６９】
ステップＳ２において、UPnPコントロールポイント１は、プロキシサービス７１からの通知を受け取る。これにより、UPnPコントロールポイント１は、IEEE１３９４ネットワーク１２にAV/C機器３が接続されたことを知ることができる。
【００７０】
そこで、ステップＳ３において、UPnPコントロールポイント１は、AV/C機器３の所定の動作を制御する（いまの場合、AV/C機器３の電源をオンする）ためのコマンドを記述した、SOAPに基づくActionのrequest packetをインボーク（Invoke）する。
【００７１】
図８は、このときUPnPコントロールポイント１からノードサービス７２に転送されるメッセージの例を表している。UPnPコントロールポイント１は、ノードサービス７２が有する、後述する図１４と図１５に示されるAV/C Nodes Service Descriptionを参照して、このメッセージを作成する。
【００７２】
Transactionに含まれる数字「５」は、コマンドに対応してレスポンスが返送されてくるので、そのレスポンスがどのコマンドに対応するものであるのかを認識させるためのラベルとしてのトランザクションラベルを表している。
【００７３】
Bodyに含まれるnuidは、このメッセージの送信相手のノードユニークID（NUID）を表す。今の例の場合、AV/C機器３のNUID「０８００４６００００００００００」を表す。このNUIDは、ステップＳ２の処理で、プロキシサービス７１から取得した通知に記述されていたものである。
【００７４】
command「００ＦＦＢ２７０」は、UPnPコントロールポイント１がノードサービス７２に対して発生を要求するAV/Cコマンドの内容を表している。
【００７５】
commandに含まれるMSB側の「００ＦＦ」（１６進数）は、ノードサービス７２が発生する図９に示されるAV/C POWER control command（２進数）におけるCTS「００００」、ctype「００００」、subunit_type「１１１１１」、並びにsubunit_ID「１１１」に対応している。すなわち、１６進数の「００ＦＦ」を２進数で表すと、「００００００００１１１１１１１１」になる。
【００７６】
次の「Ｂ２」はopcodeに対応し、「７０」は、operandに対応する。
【００７７】
resume「１」は、AV/C機器３が接続されている機器にバスリセットが発生した場合、このコマンドに対応するレスポンスの再送を、AV/Cノードサービス７２に要求するものである。ノードサービス７２は、この要求を受けた場合、バスリセットを検知したとき、このコマンドに対応するレスポンスを再送する処理を行う。
【００７８】
avcCommandSendは、このようなコマンドを、AV/CコマンドとしてIEEE１３９４ネットワーク１２に出力することをノードサービス７２に要求するものである。
【００７９】
これらのコマンドの内容を表す値は全てテキストで表されているため、どの種類のAV/Cコマンドも記述することが可能となる。
【００８０】
図７に戻って、ノードサービス７２は、ステップＳ２３において、図８に示されるActionのインボークを受け取ると、ステップＳ２４において、それに対応して、図９に示されるようなAV/Cコマンド（AV/C POWER control command）を生成し、IEEE１３９４ネットワーク１２を介してAV/C機器３に送信する。
【００８１】
AV/Cノードサービス７２は、NUIDとノードIDの対応表を生成、保持しており、バスリセット発生の度にそれを更新する。NUIDは、この対応表に基づいてノードIDに変換され、IEEE１３９４ネットワーク１２に転送される。
【００８２】
AV/C機器３は、ステップＳ３３において、ノードデバイス７２より送信されてきたAV/C POWER control commandを受信すると、そのコマンドの内容に対応して、装置の電源をオンする。その後、ステップＳ３４において、AV/C機器３は、それに対応する図１０に示されるようなAV/Cレスポンス（AV/C POWER response）を生成し、ノードサービス７２に送信する。
【００８３】
図１０に示されるように、CTSは、図９のAV/C POWER control commandと同様に「００００」とされる。responseは、図５に示されるように、ACCEPTEDを表す値「９」（１００１）とされる。
【００８４】
subunit_typeとsubunit_IDは、図９のAV/C POWER control commandと同一の値とされる。すなわち、この場合、この値は、送信元を表すことになる。
【００８５】
opcodeとoperandも、図９のAV/C POWER control commandと同一の値とされる。
【００８６】
ノードサービス７２は、ステップＳ２５において、AV/C機器３から送信されてきたAV/C POWER responseを受信すると、ステップＳ２６において、図１１に示されるようなSOAPプロトコルに基づくActionとしてResponseを生成し、UPnPコントロールポイント１に送信する。
【００８７】
図１１に示されるTransactionに示される値「５」は、図８のAction（Command）と対をなすAction（Responce）であることを表すために、図８におけるTransactionの値「５」に対応して「５」（同一の値）とされている。
【００８８】
AV/C機器３は、このコマンドを受信すると、それに対応して、装置の電源をオンし、ステップＳ３４で、図１０に示されるようなAV/C POWER responseを生成し、ノードサービス７２に送信する。
【００８９】
ノードサービス７２は、Transactionの対応関係を保持するためのテーブル（対応表）を生成し、保持している。すなわち、ステップＳ２３において、図８に示されるAV/C POWER control commandを受信し、ステップＳ２４において、図９に示されるようなAV/C POWER control commandを出力するとき、両者が対応するものであることをテーブルに記憶する。従って、このテーブルを参照することで、ノードサービス７２は、AV/C機器３から図１０に示されるAV/C POWER responseが送信されてきたとき、それが、図８に示されるAV/C POWER control commandに対応するレスポンスであることを認識することができる。
【００９０】
そして、ノードサービス７２は、ステップＳ２５でAV/C POWER responseを受信すると、ステップＳ２６で、図１１に示されるようなSOAPに基づくactionのresponseを生成し、UPnPコントロール１に送信する。
【００９１】
そのresponse「０９FFB２７０」は、図１０のAV/C POWER responseに記述されている２進数の値「００００１００１１１１１１１１１１０１０００１００１１１００００」に対応している。
【００９２】
UPnPコントロールポイント１は、ステップＳ４において、このレスポンスを受信する。これにより、UPnPコントロールポイント１は、AV/C機器３が装置の電源をオンしたことを知ることができる。
【００９３】
AV/Cの規定によれば、AV/C機器は、受信したリクエストに対応する処理を直ちに実行できないとき、INTERIMをレスポンスとして返すことが規定されている。そのAV/C機器は、その後、そのリクエストに対応する処理が完了したとき、その時点において、ファイナルレスポンスをリクエストの送信者に返すことになる。
【００９４】
しかしながら、リクエストを受信してから、ファイナルレスポンスが返されるまでの時間は規定されていない。そこで、ノードサービス７２は、ステップＳ２４の処理でAV/C機器３に対してAV/Cコマンドを出力した後、ステップＳ２５の処理で、AV/C機器３からAV/Cレスポンスを受けるまでの時間を管理する。予め設定されている所定の時間（例えば、３０秒間）以内にレスポンスが受信された場合、そのレスポンスがINTERIMでなければ（ファイナルレスポンスである場合）、AV/Cノードサービス７２は、受信したレスポンスに対応するレスポンスをUPnPコントロールポイント１に直ちに転送する。
【００９５】
これに対して、受信したレスポンスが、INTERIMである場合、AV/Cノードサービス７２は、AV/Cコマンドを送信してから３０秒間が経過するまで待機する。そして、３０秒間が経過する前に、INTERIM以外のレスポンス（ファイナルレスポンス）が受信されたとき、そのファイナルレスポンスに対応するレスポンスを出力する。３０秒以内にファイナルレスポンスが受信されない場合、AV/Cノードサービス７２は、INTERIMをレスポンスとして出力する。これにより、UPnPコントロールポイント１は、少なくとも３０秒間以内に要求した処理が完了できるか否かを知ることができる。
【００９６】
以上の処理を実行するために、図３に示されるUPnP-AV/Cプロキシ２が有するデバイスモデルのルートデバイス６１は、図１２に示されるAV/C Proxy Device Descriptionを有し、プロキシサービス７１は、図１３に示されるAV/C Proxy Service Descriptionを有し、ノードサービス７２は、図１４と図１５に示されるAV/C Nodes Service Descriptionを有する。
【００９７】
これらのDescriptionは、その機器が有する機能を実行するとき必要とするパラメータ、その他の条件を記述したものであり、他の機器は、その機器に、その機能の実行を要求するとき、そのDescriptionを参照することで、そこに記述されている条件を付加して、その機器にコマンドを送ることになる。
【００９８】
図１２におけるdeviceType「urn:sony-corp:device:1394ProxyDevice:1」は、ルートデバイス６１の型を表している。FriendlyName「proxy for IEEE1394」は、ルートデバイス６１のフレンドリーネームを表している。
【００９９】
UDN「nuid:upnp-1394proxy-root-0800460000000000」は、ルートデバイス６１の固有の番号を表している。
【０１００】
この例においては、プロキシサービス７１とノードサービス７２の２つのserviceが規定されている。
【０１０１】
一方のserviceにおいて、ServiceType「urn:sony-corp:service:1394ProxyService:1」は、プロキシサービス７１のサービスの型が、Proxy Serviceであることを表し、serviceID「urn:sony-corp:ServiceId:1394ProxyService1」は、プロキシサービス７１の固有名を表している。
【０１０２】
SCPDURL「./scpd/proxyScpd.xml」は、プロキシサービス７１が有するAV/C Proxy Service DescriptionのURL（具体的には、図１３に示されるAV/C Proxy Service DescriptionのURL）を表している。
【０１０３】
また、他方のServiceType「urn:sony-corp:service:1394NodeService:1」は、ノードサービス７２のサービスの型が、NodeServiceであることを表す。このserviceのSCPDURL「./scpd/nodeScpd.xml」は、ノードサービス７２が有するAV/C Nodes Service Description（具体的には、図１４と図１５に示されるAV/C Nodes
Service Description）のURLを表している。
【０１０４】
図１３のAV/C Proxy Service Descriptionにおけるactionは、プロキシサービス７１が実行する各種のアクションを表す。name「getNodeNum」は、アクションの名称を表す。このactionは、IEEE１３９４ネットワーク１２上のノードの数を取得するアクションである。
【０１０５】
この「getNodeNum」のactionは、「nodeNum」の名称のdirectionが「out」の引数（その引数に、他の機器が値を入れて、プロクシサービス７１に出力してくる引数）を有している。
【０１０６】
そして、この「nodeNum」の引数に格納される変数は、serviceStateTableに関連付けが規定されている。すなわち、この変数は、stateVariable sendEventsがyesである場合（状態変数に変化があった場合）に送られる変数であり、その型は、「ui１」とされる。
【０１０７】
図１４と図１５のAV/C Nodes Service Descriptionには、AV/Cコマンドを送るアクションである「avcCommandSend」が規定されている。このコマンドは、「nuid」、「avcCommand」、「resume」、「inlineNuidPosition」、「inlineNuid」、および「avcResponse」の引数を有している。最後の「avcResponse」は、directionが「out」なので、他の機器から出力され、ノードサービス７２に送られてくる。これに対して、「avcResponse」を除く５個の引数は、そのdirectionが「in」とされているので、そこに値がセットされ、ノードサービス７２から発行され、他の機器に入力される。
【０１０８】
これらの６個の引数には、全て関連付けがserviceStatTableに記述されている。
【０１０９】
これらの引数は、stateVariable sendEventesがnoである場合（変数に変化がない場合）に発生され、「nuid」、「avcCommand」、「inlineNuid」、および「avcResponce」は、いずれもその変数の形が「bin.hex」とされる。「resume」は、変数の形が「boolean」とされ、「inlineNuidPosition」は、変数の形が「ui１」とされる。
【０１１０】
図１４における「inilineNuid」（挿入されたNUID）と、「inlineNuidPosition」（NUIDの挿入位置）は、宛先機器のNUID以外のNUIDを指定する場合に利用される（そのコマンドが他のAV/C機器のNUIDを必要とする場合に用いられる）。
【０１１１】
UPnPコントロールポイント１は、このDescriptionに従って、リクエストを送ってくる。そこで、リクエストを受信したAV/C機器は、そのDescriptionの規定に基づいて、リクエストを解釈化することで、NUIDを検出することができる。
【０１１２】
図１６は、root device６１が有するAV/C Proxy Device Descriptionの他の例を表している。この例においても、プロキシサービス７１のServiceType「urn:sony-corp:service:1394Proxy Service:1」と、ノードサービス７２のServiceType「urn:sony-corp:1394Node Service:1」が記述されている。
【０１１３】
図１６において、図示は省略されているが、serviceId「urn:sony-corp:serviceId:1394ProxyService1」のSCPDURLには、図１７のAV/C Proxy Service DescriptionのURLが記述される。また、serviceId「urn:sony-corp:serviceId:1394NodeService1」のSCPDURLには、図１８のAV/C NodesServiceDescripitonのURLが記述される。
【０１１４】
図１７は、プロキシサービス７１が有するAV/C Proxy Service Descriptionの他の例を表している。
【０１１５】
図１７の例においては、ノードの数を取得する「getNodeNum」の名称のアクションが記述されている。
【０１１６】
同様に、図１８は、ノードサービス７２が有するAV/C Nodes Service Descriptionの他の例を表している。
【０１１７】
図１８の例においては、AV/Cコマンドを送る「avcCommandSend」のアクションが３つの引数「nuid」、「command」、「response」を有するように規定されている。
【０１１８】
以上においては、図３に示されるように、１個のルートデバイス６１に、プロキシサービス７１とノードサービス７２を保持させるようにしたが、例えば、図１９に示されるように、プロキシサービス７１をルートデバイス６１−１に保持させるとともに、IEEE１３９４ネットワーク１２上の個々のノードに対するサービスを各ルートデバイス毎に定義するようにすることもできる。図１９の例においては、ルートデバイス（root device）６１−２に、ノードサービス７２−１が保持され、root device６１−３に、ノードサービス７２−２が保持される。
【０１１９】
図２０と図２１は、図１９のroot device６１−１乃至６１−３が有するAV/C Proxy Device Descriptionの例を表し、図２２は、図１９のプロキシサービス７１が保持するAV/C Proxy Service Descriptionの例を表し、図２３は、図１９のノードサービス７２−１，７２−２が有するAV/C Node Service Descriptionの例を表す。
【０１２０】
図２０と図２１の例においては、deviceType「urn:schemas-upnp-org:device:1394ProxyDevice:1」が、root device６１−１に対応して記述され、deviceType「urn:sony-corp:device:1394NodeDevice:1」が、root device６１−２に対応して記述され、deviceType「urn:sony-corp:device:1394NodeDevice:1」が、root device６１−３に対応して記述されている。
【０１２１】
図示は省略されているが、deviceType「urn:schemas-upnp-org:device:1394ProxyDevice:1」のSCPDURLには、図２２のAV/C Proxy Service DescriptionのURLが記述され、deviceType「urn:sony-corp:device:1394ProxyDevice:1」とdeviceType「urn:sony-corp:device:1394NodeDevice:1」のSCPDURLには、それぞれ図２３のAV/C Nodes Service DescriptionのURLが記述される。
【０１２２】
図２２においては、serviceStateTableに「nodeNum」の変数の定義がなされている。この変数の定義は、Queryにより調べることができる。
【０１２３】
図２３においては、AV/Cコマンドを送るアクションである「avcCommandSend」が記述されている。
【０１２４】
図２４は、デバイスモデルのさらに他の構成例を表す。この例においては、図１９の例と同様に、ノードサービス７２−１，７２−２が、ノード毎に設けられているが、図１９の例と異なり、これらのサービスは、全て、プロキシサービス７１とともに、１個のroot device６１に保持されている。
【０１２５】
図２５は、図２４の例におけるroot device６１が有するAV/C Proxy Device Descriptionの構成を表し、図２６は、図２４のプロキシサービス７１が保持するAV/C Proxy service Descriptionの構成例を表し、図２７は、図２４のノードサービス７２−１，７２−２が有するAV/C Node Service Descriptionの構成例を表す。
【０１２６】
図２５の例においては、３つのサービスが規定されているserviceId「urn:sony-corp:serviceId:1394ProxyService1」のSCPDURLには、図２６のAV/C Proxy Service DescriptionのURLが記述され、serviceId「urn:sony-corp:serviceId:1394NodeService1」と「urn:sony-corp:serviceId:1394NodeService2」のSPCDURLには、図２７のAV/C Node Service DescriptionのURLが記述される。
【０１２７】
図２６の例においては、「nodeNum」の変数が規定されている。
【０１２８】
図２７の例においては、AV/Cコマンドを送るアクションが規定されている。
【０１２９】
図２８は、デバイスモデルのさらに他の構成例を表している。この構成例においては、root device６１にプロキシサービス７１が保持されている。また、ノードサービス７２−１，７２−２は、それぞれノード毎に設けられる他、root device６１の内部に形成されたエンベデッドデバイス（embedded device）８１−１，８１−２に、それぞれ保持される。
【０１３０】
図２９と図３０は、図２８におけるroot device６１が保持するAV/C Proxy Device Descriptionの構成例を表し、図３１は、図２８のプロキシサービス７１が保持するAV/C Proxy Service Descriptionの構成例を表し、図３２は、図２８のノードサービス７２−１，７２−２が有するAV/C Node Service Descriptionの構成例を表す。
【０１３１】
図２９と図３０の例において、serviceId「urn:sony-corp:serviceId:1394ProxyService1」は、図２８のプロキシサービス７１に対応し、そのSCPDURLには、図３１のAV/C Proxy Service DescriptionのURLが記述される。
【０１３２】
serviceId「urn:sony-corp:serviceId:1394NodeService1」は、図２８のAV/C node service７２−１に対応し、「urn:sony-corp:serviceId:1394NodeService2」は、AV/C node service７２−２に対応し、それぞれのSCPDURLには、図３２のAV/C node Service DescriptionのURLが記述される。
【０１３３】
図３１の例においては、「NODE Num」の変数が定義されている。
【０１３４】
図３２の例においては、AV/Cコマンドを送るアクション「avcCommandSend」が規定されている。
【０１３５】
次に、図３、図１９、図２４および図２８に示すデバイスモデルを比較する。
【０１３６】
図３の例においては、１つのroot device６１に、プロキシサービス７１とノードデバイス７２が、それぞれ１つずつ定義される。
【０１３７】
図１９の例においては、プロキシサービス７１が１つのroot device６１−１に定義されるとともに、１３９４上の個々のノードに対するノードサービス７２−１，７２−２が、root device６１−２，６１−３毎に定義される。
【０１３８】
図２４の例においては、プロキシサービス７１が、１つのroot device６１に設けられる他、ノードサービスが各ノード毎に対応して設けられ、それらのノードサービス７２−１，７２−２は、プロキシサービス７１と同様に、１つのroot device６１に保持される。
【０１３９】
図２８の例においては、１３９４上のノードが全てroot device６１のembedded device８１−１，８１−２として定義される。
【０１４０】
図３３は、図３、図１９、図２４、および図２８のデバイスモデルの特徴の比較結果を表している。なお、図３３において、タイプＡ、タイプＢ、タイプＣ、およびタイプＤは、それぞれ図３、図１９、図２４、または図２８のデバイスモデルに対応している。
【０１４１】
タイプＡからタイプＤまでを比較すると、SSDPのパケット量が大きく異なっていることがわかる。すなわち、root deviceが１個のとき、SSDPの数は、３＋２ｄ＋ｋとなる。ここで、ｄはembedded deviceの数、kはサービスタイプの数を意味する。従って、１３９４ネットワーク１２上のノードの数をＮとするとき、SSDPのパケットの量は、タイプＡのとき５個、タイプＢのとき４＋４Ｎ個、タイプＣのとき４＋Ｎ個、タイプＤのとき４＋３Ｎ個となる。特に、タイプＢ（図１９）とタイプＤ（図２８）の場合には、ノード数の数倍になる数のパケットが流れることになる。そこで、ネットワークのトラフィックの観点から考えた場合、SSDPのパケットの量が少ないタイプＡ（図３）の例が望ましい。
【０１４２】
バスの構成の変更の通知は、タイプＡの場合、GENAにより行われ、タイプＢ，Ｃ，Ｄの場合、SSDPにより行われる。
【０１４３】
presentation URLの構成の単位は、タイプＡとタイプＣがバス単位とされ、タイプＢとタイプＤがノード単位とされる。ノード毎にURLを持つことが可能なタイプＢ（図１９）とタイプＤ（図２８）が分かりやすいが、タイプＡ（図３）とタイプＣ（図２４）に関しても、プロキシサービス７１が、各ノードに対するリンクページのようなものを用意すれば、実質的に対応する機能は実現できると考えられる。
【０１４４】
NOTIFYの通知の単位は、タイプＡの場合、バス単位とされ、タイプＢ，Ｃ，Ｄの場合、ノード単位とされる。
【０１４５】
以上を総合すると、タイプＡ（図３）の例が最適と考えられる。
【０１４６】
以上においては、IEEE８０２ネットワーク１１に接続されている機器から、IEEE１３９４ネットワーク１２に接続されている機器を制御するようにしたが、後者から前者を制御することも可能である。
【０１４７】
上述した一連の処理は、ハードウエアにより実行させることもできるが、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０１４８】
この記録媒体は、図２に示すように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フロッピディスクを含む）、光ディスク４２（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２２や、記憶部２８に含まれるハードディスクなどで構成される。
【０１４９】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１５０】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１５１】
【発明の効果】
以上の如く本発明の情報処理装置および方法、記録媒体、並びにプログラムによれば、IEEE８０２に基づく第１のネットワークからのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換するようにしたので、簡単かつ確実に、第１のネットワークに接続されている機器から、第２のネットワークに接続されている機器を制御することが可能となる。
【図面の簡単な説明】
【図１】本発明が適用されるネットワークシステムの構成を示す図である。
【図２】図１のUPnPデバイス２の構成を示すブロック図である。
【図３】図１のUPnPデバイス２が有するデバイスモデルの構成を示す図である。
【図４】 AV/Cコマンドフレームの構成を示す図である。
【図５】 ctypeを説明する図である。
【図６】 subunit_typeを説明する図である。
【図７】図１のネットワークシステムの処理を説明するフローチャートである。
【図８】図７のステップＳ３において出力されるコマンドの構成を示す図である。
【図９】図７のステップＳ２４の処理で出力されるコマンドの構成を示す図である。
【図１０】図７のステップＳ３４の処理で出力されるレスポンスの構成を示す図である。
【図１１】図７のステップ２６の処理で出力されるレスポンスの例を示す図である。
【図１２】図３のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図１３】図３の１３９４ proxy serviceが有するAV/C Proxy Service Descriptionの構成を示す図である。
【図１４】図３の１３９４ nodes serviceが有するAV/C Nodes Service Descriptionの構成を示す図である。
【図１５】図３の１３９４ nodes serviceが有するAV/C Nodes Service Descriptionの構成を示す図である。
【図１６】図３のroot deviceが有するAV/C Proxy Device Descriptionの他の構成を示す図である。
【図１７】図３の１３９４ proxy serviceが有するAV/C Proxy Service Descriptionの他の構成を示す図である。
【図１８】図３の１３９４ nodes serviceが有するAV/C Nodes Service Descriptionの他の構成を示す図である。
【図１９】デバイスモデルの他の構成を示す図である。
【図２０】図１９のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図２１】図１９のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図２２】図１９の１３９４ proxy serviceが有するAV/C Proxy Service Descriptionの構成を示す図である。
【図２３】図１９のAV/C node serviceが有するAV/C Node Service Descriptionの構成を示す図である。
【図２４】デバイスモデルのさらに他の構成を示す図である。
【図２５】図２４のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図２６】図２４のAV/C proxy serviceが有するAV/C Proxy Service Descriptionの構成を示す図である。
【図２７】図２４のAV/C node serviceが有するAV/C Node Service Descriptionの構成を示す図である。
【図２８】デバイスモデルの他の構成を示す図である。
【図２９】図２８のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図３０】図２８のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図３１】図２８のAV/C proxy serviceが有するAV/C Proxy Service Descriptionの構成を示す図である。
【図３２】図２８のAV/C node serviceが有するAV/C Node Service Descriptionの構成を示す図である。
【図３３】デバイスモデルの比較を示す図である。
【符号の説明】
１ UPnPコントロールポイント， ２ UPnPデバイス， ３，４ AV/C機器，１１ IEEE８０２ネットワーク， １２ IEEE１３９４ネットワーク， ６１
root device， ７１ AV/C proxy service， ７２ AV/C nodes service
【発明の属する技術分野】
本発明は、情報処理装置および方法、記録媒体、並びプログラムに関し、特に、IEEE８０２に基づく第１のネットワークに接続されている機器が、IEEE１３９４に基づく第２のネットワークに接続されている機器を制御することができるようにした、情報処理装置および方法、記録媒体、並びプログラムに関する。
【０００２】
【従来の技術】
最近、IEEE（Institute of Electrical and Electronics Engineers）１３９４高速シリアルバスを用いたネットワーク（以下、単にIEEE１３９４ネットワークと称する）が普及してきた。オーディオ機器やビデオ機器を、このIEEE１３９４ネットワークに接続することで、各機器は、AV/Cコマンドを用いて、他の機器を制御することができる。
【０００３】
一方、IEEE８０２ネットワークも普及している。このIEEE８０２は、主にパーソナルコンピュータを相互に接続するためのネットワークであり、UPnP（Universal Plag and Play）のプロトコルに基づいて、各パーソナルコンピュータは、他のパーソナルコンピュータを制御することができる。
【０００４】
【発明が解決しようとする課題】
しかしながら、このIEEE１３９４ネットワークとIEEE８０２ネットワークとは、それぞれ独立したものであり、IEEE８０２ネットワークに接続されている機器（以下、UPnP機器と称する）は、IEEE１３９４ネットワークに接続されている機器（以下、AV/C機器と称する）を制御することができない課題があった。
【０００５】
本発明はこのような状況に鑑みてなされたものであり、UPnP機器が、AV/C機器を制御できるようにするものである。
【０００６】
【課題を解決するための手段】
本発明の情報処理装置は、第１のネットワークから第１のフォーマットのデータを取り込む取り込み手段と、取り込み手段により取り込まれた第１のフォーマットのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換して第２のフォーマットに格納するとともに、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID を、対応表に基づいてノード ID に変換する変換手段と、変換手段により変換された第２のフォーマットを、第２のネットワークに送信する送信手段とを備えることを特徴とする
【０００８】
前記変換手段は、SOAPに基づくコマンドと、それに基づいて第２のネットワークに送信されるコマンドとの対応表を有し、第２のネットワークを介して受信したレスポンスに対応するSOAPに基づくコマンドを、対応表に基づいて検索し、SOAPに基づくコマンドに対応するレスポンスを第１のネットワークに送信することができる。
【０００９】
前記変換手段は、SOAPに基づくコマンドに含まれるトランザクションラベルに基づいて、SOAPに基づくコマンドとレスポンスを対応させることができる。
【００１０】
前記変換手段は、第１のネットワークに接続されている機器からのリクエストに対応するファイナルレスポンスが、予め定められている時間内に、第２のネットワークに接続されている機器から受信されないとき、第１のネットワークに接続されている機器に対して処理中であることを表すレスポンスを送信することができる。
【００１１】
前記SOAPに基づくコマンドが、第２のネットワークのバスリセット時に再送を要求するコマンドである場合、第２のネットワークのバスリセットを検知し、第２のネットワークにバスリセットが発生したとき、コマンドを送信する検知手段をさらに備えるようにすることができる。
【００１２】
前記変換手段は、さらに第２のネットワークのAV/Cコマンドを、第１のフォーマットのSOAPに基づくコマンドに変換して第１のフォーマットに格納し、送信手段は、さらに変換手段により変換された第１のフォーマットのSOAPに基づくコマンドを、第１のネットワークに送信することができる。
【００１３】
本発明の情報処理方法は、第１のネットワークからの第１のフォーマットのデータを取り込む取り込みステップと、取り込みステップの処理により取り込まれた第１のフォーマットのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換して第２のフォーマットに格納するとともに、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID を、対応表に基づいてノード ID に変換する変換ステップと、変換ステップの処理により変換された第２のフォーマットを、第２のネットワークに送信する送信ステップとを含むことを特徴とする。
【００１４】
本発明の記録媒体のプログラムは、第１のネットワークからの第１のフォーマットのデータを取り込む取り込みステップと、取り込みステップの処理により取り込まれた第１のフォーマットのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換して第２のフォーマットに格納するとともに、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID を、対応表に基づいてノード ID に変換する変換ステップと、変換ステップの処理により変換された第２のフォーマットを、第２のネットワークに送信する送信ステップとを含むことを特徴とする。
【００１５】
本発明のプログラムは、第１のネットワークからの第１のフォーマットのデータを取り込む取り込みステップと、取り込みステップの処理により取り込まれた第１のフォーマットのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換して第２のフォーマットに格納するとともに、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、 SOAP に基づくコマンドに記述されている第２のネットワークに接続されている機器を指定するノードユニーク ID を、対応表に基づいてノード ID に変換する変換ステップと、変換ステップの処理により変換された第２のフォーマットを、第２のネットワークに送信する送信ステップとを実行させることを特徴とする。
【００１６】
本発明の情報処理装置および方法、記録媒体、並びにプログラムにおいては、IEEE８０２に基づく第１のネットワークからのSOAPに基づくコマンドが、第２のネットワークのAV/Cコマンドに変換される。
【００１７】
【発明の実施の形態】
図１は、本発明を適用したネットワークシステムの構成を表している。この構成においては、IEEE８０２ネットワーク１１に、UPnPコントロールポイント１が接続されている。IEEE１３９４ネットワーク１２には、AV/C機器３，４が接続されている。IEEE８０２ネットワーク１１と、IEEE１３９４ネットワーク１２は、UPnPデバイス（UPnP-AV/Cプロキシ）２にそれぞれ接続されている。
【００１８】
図２は、UPnPデバイス２の構成例を表している。図２において、CPU（Central Processing Unit）２１は、ROM（Read Only Memory）２２に記憶されているプログラム、または記憶部２８からRAM（Random Access Memory）２３にロードされたプログラムに従って各種の処理を実行する。RAM２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００１９】
CPU２１、ROM２２、およびRAM２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インタフェース２５も接続されている。
【００２０】
入出力インタフェース２５には、キーボード、マウスなどよりなる入力部２６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部２７、ハードディスクなどより構成される記憶部２８、モデム、ターミナルアダプタなどより構成される通信部２９が接続されている。通信部２９は、IEEE８０２ネットワーク１１またはIEEE１３９４ネットワーク１２を介しての通信処理を行う。
【００２１】
入出力インタフェース２５にはまた、必要に応じてドライブ３０が接続され、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２８にインストールされる。
【００２２】
UPnP機器（図１の例の場合、UPnPコントロールポイント１およびUPnPデバイス２）は、主に、アドレシング（Addressing）、ディスカバリ（Discovery）、ディスクリプション（Decription）、コントロール（Control）、イベンティング（Eventing）、プレゼンテーション（Presentation）の６つの機能を有している。
【００２３】
アドレシングは、各UPnP機器が、IEEE８０２ネットワーク１１上でアドレスを取得するための機能であり、DHCP（Dynamic Host Configuration Protocol）またはAutoIPが用いられる。
【００２４】
ディスカバリは、アドレシングの後に行われ、これによりUPnPコントロールポイント１は、コントロールしたいターゲット機器を発見することができる。ここで用いられるプロトコルは、SSDP（Simple Service Discovery Protocol）である。各機器は、IEEE８０２ネットワーク１１に接続されたとき、自分自身の中に有するデバイスやサービスを通知するメッセージをIEEE８０２ネットワーク１１上にマルチキャストする（特に、相手を指定しないでパケットを送信する）。UPnPコントロールポイント１は、このマルチキャストされたメッセージを受信することで、IEEE８０２ネットワーク１１に、どのような機器が接続されたのかを知ることができる。
【００２５】
逆に、UPnPコントロールポイント１の方から、現在IEEE８０２ネットワーク１１に接続されている機器を調べることもできる。このとき、UPnPコントロールポイント１は、発見したいデバイスやサービスをキーワードとして、検索コマンドをIEEE８０２ネットワーク１１上にマルチキャストする。IEEE８０２ネットワーク１１に接続されている各機器は、マルチキャストされた検索コマンドに規定されている条件に自分自身が適合する場合、その検索コマンドに対してレスポンスをユニキャストする（相手側を指定して、パケットを送信する）。これにより、UPnPコントロールポイント１は、IEEE８０２ネットワーク１１に接続されている機器を検知することができる。
【００２６】
また、各機器は、IEEE８０２ネットワーク１１から外れるときも、事前にその旨をブロードキャストする。
【００２７】
ディスカバリによりUPnPコントロールポイント１が発見したコントロール対象の機器が出力したSSDPパケットには、デバイスディスクリプション（Device Description）のURL（Uniform Resource Locator）が記述されている。UPnPコントロールポイント１は、そのURLにアクセスすることにより、その機器のさらに詳しいデバイス情報をデバイスディスクリプションから得ることができる。このデバイス情報には、アイコン情報、モデル名、生産者名、商品名などが含まれている。
【００２８】
また、このデバイス情報には、そのデバイスが有するサービス情報が記述されており、そのサービスの詳しい情報が記述されているサービスディスクリプション（Service Description）も、サービス情報に記述されているURLから辿ることができる。
【００２９】
UPnPコントロールポイント１は、これらのデバイス情報（Device Description）やサービス情報（Service Description）から、ターゲットに対するアクセスの方法を知ることができる。
【００３０】
また、デバイスディスクリプションには、後述するPresentation URLも記述されている。
【００３１】
Device DescriptionおよびService Descriptionは、XML（Extensible Markup Language）で表現されている。
【００３２】
Controlは、アクション（Action）とクエリー（Query）の２つに大きく分類される。Actionは、Service Descriptionのアクション情報に規定された方法で行われ、ActionをInvokeすることにより、UPnPコントロールポイント１は、ターゲットを操作することができる。
【００３３】
一方、Queryは、Service DescriptionのstateVariableの値を取り出すために用いられる。stateVariableの値は、機器の状態を表している。
【００３４】
Controlでは、SOAP（Simple Object Access Protocol）というトランスポートプロトコルが利用される。その表現言語としては、XMLが用いられる。
【００３５】
イベンティング（Eventing）は、stateVariableの値が変更されたとき、そのことをターゲットから、UPnPコントロールポイント１に通知させるために用いられる。UPnPコントロールポイント１は、Service Description を解析することにより、stateVariableからターゲットの保持する変数を知ることができる。UPnPコントロールポイント１はターゲットに対して、Subscriptionを出力しておくことにより、その変数のうち、sendEventsがyesになっている変数に関して、変数の変更があったとき、ターゲットから通知を受け取ることができる。Eventingでは、GENA（General Event Notification Architecture）というトランスポートプロトコルが利用される。その表現言語としては、XMLが用いられる。
【００３６】
プレゼンテーション（Presentation）は、ユーザにユーザインタフェース（UI）を用いたコントロール手段を提供するために用いられる。Device Descriptionに記述されたPresentation URLにアクセスすることで、HTML（Hyper Text Markup Language）によって記述されたPresentation Pageを得ることができる。その機能により、ターゲットでアプリケーションを用意することができる。
【００３７】
UPnPデバイス（UPnP-AV/Cプロキシ）２は、IEEE８０２ネットワーク１１とIEEE１３９４ネットワーク１２との間のブリッジとして機能し、内部に、図３に示されるデバイスモデルを有する。この例のデバイスモデルは、１個のルートデバイス（root device）６１で構成され、このルートデバイス６１は、AV/Cプロキシサービス（AV/C proxy service）７１とAV/Cノードサービス（AV/C nodes service）７２とを有している。
【００３８】
AV/Cプロキシサービス（以下、単に、プロキシサービスと称する）７１は、IEEE１３９４ネットワーク１２のバスリセット発生、バスID、ノードの数、バスマネージャ、アイソクロナスリソースマネージャのノードユニークID（NUID）、ギャップカウント（Gap Count）、セルフIDパケット（Self IDパケット）などを管理する。
【００３９】
AV/Cノードサービス（以下、単にノードサービスと称する）７２は、SOAPに基づくコマンドと、AV/Cに基づくコマンドの変換処理を行う。
【００４０】
図４は、このAV/Cコマンドフレームのフォーマットを表している。
【００４１】
CTSフィールドには、コマンドセットの種類が記述される。その値の「００００」は、そのコマンドセットがAV/Cコマンドセットであることを表す。
【００４２】
ctypeフィールドには、そのパケットがコマンドであるのか、レスポンスであるのか、コマンドである場合にはコマンドの機能分類、レスポンスである場合にはコマンドの処理結果の分類が記述される。
【００４３】
図５は、このようなコマンドとレスポンスの例を表している。同図に示されるように、コマンドとしては、大きく分けて４種類のコマンドが用意されている。
【００４４】
CONTROL（ctype＝００００）は、機能を外部から制御するコマンドである。
【００４５】
STATUS（ctype＝０００１）は、外部から状態を問い合わせるコマンドである。
【００４６】
さらに、制御コマンドのサポートの有無を外部から問い合わせるコマンドとして、GENERAL INQUIRY（ctype＝０１００）とSPECIFIC INQUIRY（ctype＝００１０）がある。前者は、opcodeサポートの有無を問い合わせるコマンドであり、後者は、opcodeとoperandsのサポートの有無を問い合わせるコマンドである。
【００４７】
NOTIFY（ctype＝００１１）は、状態の変化を外部に知らせるように要求するコマンドである。
【００４８】
レスポンスは、コマンドの種別に応じて返される。
【００４９】
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とNOT IMPLEMENTEDがある。IMPLEMENTED（ctype＝１１００）は、コマンドが実装されていることを通知する。
【００５５】
NOTIFYコマンドに対するレスポンスとしては、NOT IMPLEMENTED，REJECTED，INTERIM，CHANGEDがある。
【００５６】
INTERIMは、NOTIFYが受け付けられたことをまず通知する。CHANGED（ctype＝１１０１）は、その後、ターゲットの状態が変化したことを通知する。
【００５７】
図４のAV/Cコマンドフレームにおけるsubunit_typeは、コマンドの宛先を表す。その具体的な例が、図６に示されている。
【００５８】
すなわち、subunit_typeの値の「０００００」は、このAV/Cコマンドの宛先（サブユニット）が、Video Monitorであることを表す。また、その値の「００１０１」は、その宛先がTunerであることを表す。
【００５９】
subunit_typeの値の「１１１１１」は、そのコマンドはユニット宛であることを表す。これにより、例えば、装置の電源のオンオフなどが制御される。
【００６０】
図４のsubunit_typeの次には、subunit_IDが配置される。このsubunit_IDは、ユニット内に、同じ種類のサブユニットが複数個存在する場合の判別を行うために、判別番号として用いられる。従って、結局、subunit_typeとsubunit_IDの２つにより、コマンドの宛先が特定されることになる。
【００６１】
opcodeは命令動作を表し、operandは命令の付加的条件を表す。
【００６２】
図６には、scbunit_typeがTunerである場合におけるopcodeの例が表されている。Tunerのopcodeの場合、その値のＣ８ｈは、DIRECT SELECT INFORMATION TYPEを表し、その値のＣＢｈは、DIRECT SERECT DATAを表す。
【００６３】
このように、各subunit毎に、opcodeのテーブルが用意される。また、各opcode毎に、operandが定義される。
【００６４】
例えば、チューナの選局が行われる場合、opcodeは、DIRECT SELECT INFORMATION TYPEとされ、operandで周波数やチャンネル番号などのパラメータが指定される。
【００６５】
次に、図７のフローチャートを参照して、IEEE８０２ネットワーク１１に接続されているUPnPコントロールポイント１が、IEEE１３９４ネットワーク１２に接続されている機器を制御する処理について、AV/C機器３の電源をオンさせる場合を例として説明する。
【００６６】
ステップＳ１において、UPnPコントロールポイント１は、UPnP-AV/Cプロキシ２を構成するルートデバイス６１のプロキシサービス７１に、IEEE１３９４ネットワーク１２に変化があった場合、これを通知してくれるように、サブスクライブ（SUBSCRIBE）する。ステップＳ１１において、プロキシサービス７１は、このサブスクライブを受け取ると、それに対応する処理を実行する。
【００６７】
例えば、今、AV/C機器３がステップＳ３１において、IEEE１３９４ネットワーク１２に接続されたとすると、ステップＳ３２において、AV/C機器３にバスリセットが発生し、同様に、ステップＳ２１において、ルートデバイス６１のノードサービス７２に、バスリセットが発生する。このとき、ノードサービス７２は、ステップＳ２２において、このバスリセットの発生を、プロキシサービス７１に通知する。
【００６８】
プロキシサービス７１は、ステップＳ１２において、ノードサービス７２からの通知を検知すると、ステップＳ１１において取り込んだUPnPコントロールポイント１からのサブスクライブに基づいて、ステップＳ１３において、UPnPコントロールポイント１に対して、AV/C機器３がIEEE１３９４ネットワーク１２に接続されたことを通知（NOTIFY）する。
【００６９】
ステップＳ２において、UPnPコントロールポイント１は、プロキシサービス７１からの通知を受け取る。これにより、UPnPコントロールポイント１は、IEEE１３９４ネットワーク１２にAV/C機器３が接続されたことを知ることができる。
【００７０】
そこで、ステップＳ３において、UPnPコントロールポイント１は、AV/C機器３の所定の動作を制御する（いまの場合、AV/C機器３の電源をオンする）ためのコマンドを記述した、SOAPに基づくActionのrequest packetをインボーク（Invoke）する。
【００７１】
図８は、このときUPnPコントロールポイント１からノードサービス７２に転送されるメッセージの例を表している。UPnPコントロールポイント１は、ノードサービス７２が有する、後述する図１４と図１５に示されるAV/C Nodes Service Descriptionを参照して、このメッセージを作成する。
【００７２】
Transactionに含まれる数字「５」は、コマンドに対応してレスポンスが返送されてくるので、そのレスポンスがどのコマンドに対応するものであるのかを認識させるためのラベルとしてのトランザクションラベルを表している。
【００７３】
Bodyに含まれるnuidは、このメッセージの送信相手のノードユニークID（NUID）を表す。今の例の場合、AV/C機器３のNUID「０８００４６００００００００００」を表す。このNUIDは、ステップＳ２の処理で、プロキシサービス７１から取得した通知に記述されていたものである。
【００７４】
command「００ＦＦＢ２７０」は、UPnPコントロールポイント１がノードサービス７２に対して発生を要求するAV/Cコマンドの内容を表している。
【００７５】
commandに含まれるMSB側の「００ＦＦ」（１６進数）は、ノードサービス７２が発生する図９に示されるAV/C POWER control command（２進数）におけるCTS「００００」、ctype「００００」、subunit_type「１１１１１」、並びにsubunit_ID「１１１」に対応している。すなわち、１６進数の「００ＦＦ」を２進数で表すと、「００００００００１１１１１１１１」になる。
【００７６】
次の「Ｂ２」はopcodeに対応し、「７０」は、operandに対応する。
【００７７】
resume「１」は、AV/C機器３が接続されている機器にバスリセットが発生した場合、このコマンドに対応するレスポンスの再送を、AV/Cノードサービス７２に要求するものである。ノードサービス７２は、この要求を受けた場合、バスリセットを検知したとき、このコマンドに対応するレスポンスを再送する処理を行う。
【００７８】
avcCommandSendは、このようなコマンドを、AV/CコマンドとしてIEEE１３９４ネットワーク１２に出力することをノードサービス７２に要求するものである。
【００７９】
これらのコマンドの内容を表す値は全てテキストで表されているため、どの種類のAV/Cコマンドも記述することが可能となる。
【００８０】
図７に戻って、ノードサービス７２は、ステップＳ２３において、図８に示されるActionのインボークを受け取ると、ステップＳ２４において、それに対応して、図９に示されるようなAV/Cコマンド（AV/C POWER control command）を生成し、IEEE１３９４ネットワーク１２を介してAV/C機器３に送信する。
【００８１】
AV/Cノードサービス７２は、NUIDとノードIDの対応表を生成、保持しており、バスリセット発生の度にそれを更新する。NUIDは、この対応表に基づいてノードIDに変換され、IEEE１３９４ネットワーク１２に転送される。
【００８２】
AV/C機器３は、ステップＳ３３において、ノードデバイス７２より送信されてきたAV/C POWER control commandを受信すると、そのコマンドの内容に対応して、装置の電源をオンする。その後、ステップＳ３４において、AV/C機器３は、それに対応する図１０に示されるようなAV/Cレスポンス（AV/C POWER response）を生成し、ノードサービス７２に送信する。
【００８３】
図１０に示されるように、CTSは、図９のAV/C POWER control commandと同様に「００００」とされる。responseは、図５に示されるように、ACCEPTEDを表す値「９」（１００１）とされる。
【００８４】
subunit_typeとsubunit_IDは、図９のAV/C POWER control commandと同一の値とされる。すなわち、この場合、この値は、送信元を表すことになる。
【００８５】
opcodeとoperandも、図９のAV/C POWER control commandと同一の値とされる。
【００８６】
ノードサービス７２は、ステップＳ２５において、AV/C機器３から送信されてきたAV/C POWER responseを受信すると、ステップＳ２６において、図１１に示されるようなSOAPプロトコルに基づくActionとしてResponseを生成し、UPnPコントロールポイント１に送信する。
【００８７】
図１１に示されるTransactionに示される値「５」は、図８のAction（Command）と対をなすAction（Responce）であることを表すために、図８におけるTransactionの値「５」に対応して「５」（同一の値）とされている。
【００８８】
AV/C機器３は、このコマンドを受信すると、それに対応して、装置の電源をオンし、ステップＳ３４で、図１０に示されるようなAV/C POWER responseを生成し、ノードサービス７２に送信する。
【００８９】
ノードサービス７２は、Transactionの対応関係を保持するためのテーブル（対応表）を生成し、保持している。すなわち、ステップＳ２３において、図８に示されるAV/C POWER control commandを受信し、ステップＳ２４において、図９に示されるようなAV/C POWER control commandを出力するとき、両者が対応するものであることをテーブルに記憶する。従って、このテーブルを参照することで、ノードサービス７２は、AV/C機器３から図１０に示されるAV/C POWER responseが送信されてきたとき、それが、図８に示されるAV/C POWER control commandに対応するレスポンスであることを認識することができる。
【００９０】
そして、ノードサービス７２は、ステップＳ２５でAV/C POWER responseを受信すると、ステップＳ２６で、図１１に示されるようなSOAPに基づくactionのresponseを生成し、UPnPコントロール１に送信する。
【００９１】
そのresponse「０９FFB２７０」は、図１０のAV/C POWER responseに記述されている２進数の値「００００１００１１１１１１１１１１０１０００１００１１１００００」に対応している。
【００９２】
UPnPコントロールポイント１は、ステップＳ４において、このレスポンスを受信する。これにより、UPnPコントロールポイント１は、AV/C機器３が装置の電源をオンしたことを知ることができる。
【００９３】
AV/Cの規定によれば、AV/C機器は、受信したリクエストに対応する処理を直ちに実行できないとき、INTERIMをレスポンスとして返すことが規定されている。そのAV/C機器は、その後、そのリクエストに対応する処理が完了したとき、その時点において、ファイナルレスポンスをリクエストの送信者に返すことになる。
【００９４】
しかしながら、リクエストを受信してから、ファイナルレスポンスが返されるまでの時間は規定されていない。そこで、ノードサービス７２は、ステップＳ２４の処理でAV/C機器３に対してAV/Cコマンドを出力した後、ステップＳ２５の処理で、AV/C機器３からAV/Cレスポンスを受けるまでの時間を管理する。予め設定されている所定の時間（例えば、３０秒間）以内にレスポンスが受信された場合、そのレスポンスがINTERIMでなければ（ファイナルレスポンスである場合）、AV/Cノードサービス７２は、受信したレスポンスに対応するレスポンスをUPnPコントロールポイント１に直ちに転送する。
【００９５】
これに対して、受信したレスポンスが、INTERIMである場合、AV/Cノードサービス７２は、AV/Cコマンドを送信してから３０秒間が経過するまで待機する。そして、３０秒間が経過する前に、INTERIM以外のレスポンス（ファイナルレスポンス）が受信されたとき、そのファイナルレスポンスに対応するレスポンスを出力する。３０秒以内にファイナルレスポンスが受信されない場合、AV/Cノードサービス７２は、INTERIMをレスポンスとして出力する。これにより、UPnPコントロールポイント１は、少なくとも３０秒間以内に要求した処理が完了できるか否かを知ることができる。
【００９６】
以上の処理を実行するために、図３に示されるUPnP-AV/Cプロキシ２が有するデバイスモデルのルートデバイス６１は、図１２に示されるAV/C Proxy Device Descriptionを有し、プロキシサービス７１は、図１３に示されるAV/C Proxy Service Descriptionを有し、ノードサービス７２は、図１４と図１５に示されるAV/C Nodes Service Descriptionを有する。
【００９７】
これらのDescriptionは、その機器が有する機能を実行するとき必要とするパラメータ、その他の条件を記述したものであり、他の機器は、その機器に、その機能の実行を要求するとき、そのDescriptionを参照することで、そこに記述されている条件を付加して、その機器にコマンドを送ることになる。
【００９８】
図１２におけるdeviceType「urn:sony-corp:device:1394ProxyDevice:1」は、ルートデバイス６１の型を表している。FriendlyName「proxy for IEEE1394」は、ルートデバイス６１のフレンドリーネームを表している。
【００９９】
UDN「nuid:upnp-1394proxy-root-0800460000000000」は、ルートデバイス６１の固有の番号を表している。
【０１００】
この例においては、プロキシサービス７１とノードサービス７２の２つのserviceが規定されている。
【０１０１】
一方のserviceにおいて、ServiceType「urn:sony-corp:service:1394ProxyService:1」は、プロキシサービス７１のサービスの型が、Proxy Serviceであることを表し、serviceID「urn:sony-corp:ServiceId:1394ProxyService1」は、プロキシサービス７１の固有名を表している。
【０１０２】
SCPDURL「./scpd/proxyScpd.xml」は、プロキシサービス７１が有するAV/C Proxy Service DescriptionのURL（具体的には、図１３に示されるAV/C Proxy Service DescriptionのURL）を表している。
【０１０３】
また、他方のServiceType「urn:sony-corp:service:1394NodeService:1」は、ノードサービス７２のサービスの型が、NodeServiceであることを表す。このserviceのSCPDURL「./scpd/nodeScpd.xml」は、ノードサービス７２が有するAV/C Nodes Service Description（具体的には、図１４と図１５に示されるAV/C Nodes
Service Description）のURLを表している。
【０１０４】
図１３のAV/C Proxy Service Descriptionにおけるactionは、プロキシサービス７１が実行する各種のアクションを表す。name「getNodeNum」は、アクションの名称を表す。このactionは、IEEE１３９４ネットワーク１２上のノードの数を取得するアクションである。
【０１０５】
この「getNodeNum」のactionは、「nodeNum」の名称のdirectionが「out」の引数（その引数に、他の機器が値を入れて、プロクシサービス７１に出力してくる引数）を有している。
【０１０６】
そして、この「nodeNum」の引数に格納される変数は、serviceStateTableに関連付けが規定されている。すなわち、この変数は、stateVariable sendEventsがyesである場合（状態変数に変化があった場合）に送られる変数であり、その型は、「ui１」とされる。
【０１０７】
図１４と図１５のAV/C Nodes Service Descriptionには、AV/Cコマンドを送るアクションである「avcCommandSend」が規定されている。このコマンドは、「nuid」、「avcCommand」、「resume」、「inlineNuidPosition」、「inlineNuid」、および「avcResponse」の引数を有している。最後の「avcResponse」は、directionが「out」なので、他の機器から出力され、ノードサービス７２に送られてくる。これに対して、「avcResponse」を除く５個の引数は、そのdirectionが「in」とされているので、そこに値がセットされ、ノードサービス７２から発行され、他の機器に入力される。
【０１０８】
これらの６個の引数には、全て関連付けがserviceStatTableに記述されている。
【０１０９】
これらの引数は、stateVariable sendEventesがnoである場合（変数に変化がない場合）に発生され、「nuid」、「avcCommand」、「inlineNuid」、および「avcResponce」は、いずれもその変数の形が「bin.hex」とされる。「resume」は、変数の形が「boolean」とされ、「inlineNuidPosition」は、変数の形が「ui１」とされる。
【０１１０】
図１４における「inilineNuid」（挿入されたNUID）と、「inlineNuidPosition」（NUIDの挿入位置）は、宛先機器のNUID以外のNUIDを指定する場合に利用される（そのコマンドが他のAV/C機器のNUIDを必要とする場合に用いられる）。
【０１１１】
UPnPコントロールポイント１は、このDescriptionに従って、リクエストを送ってくる。そこで、リクエストを受信したAV/C機器は、そのDescriptionの規定に基づいて、リクエストを解釈化することで、NUIDを検出することができる。
【０１１２】
図１６は、root device６１が有するAV/C Proxy Device Descriptionの他の例を表している。この例においても、プロキシサービス７１のServiceType「urn:sony-corp:service:1394Proxy Service:1」と、ノードサービス７２のServiceType「urn:sony-corp:1394Node Service:1」が記述されている。
【０１１３】
図１６において、図示は省略されているが、serviceId「urn:sony-corp:serviceId:1394ProxyService1」のSCPDURLには、図１７のAV/C Proxy Service DescriptionのURLが記述される。また、serviceId「urn:sony-corp:serviceId:1394NodeService1」のSCPDURLには、図１８のAV/C NodesServiceDescripitonのURLが記述される。
【０１１４】
図１７は、プロキシサービス７１が有するAV/C Proxy Service Descriptionの他の例を表している。
【０１１５】
図１７の例においては、ノードの数を取得する「getNodeNum」の名称のアクションが記述されている。
【０１１６】
同様に、図１８は、ノードサービス７２が有するAV/C Nodes Service Descriptionの他の例を表している。
【０１１７】
図１８の例においては、AV/Cコマンドを送る「avcCommandSend」のアクションが３つの引数「nuid」、「command」、「response」を有するように規定されている。
【０１１８】
以上においては、図３に示されるように、１個のルートデバイス６１に、プロキシサービス７１とノードサービス７２を保持させるようにしたが、例えば、図１９に示されるように、プロキシサービス７１をルートデバイス６１−１に保持させるとともに、IEEE１３９４ネットワーク１２上の個々のノードに対するサービスを各ルートデバイス毎に定義するようにすることもできる。図１９の例においては、ルートデバイス（root device）６１−２に、ノードサービス７２−１が保持され、root device６１−３に、ノードサービス７２−２が保持される。
【０１１９】
図２０と図２１は、図１９のroot device６１−１乃至６１−３が有するAV/C Proxy Device Descriptionの例を表し、図２２は、図１９のプロキシサービス７１が保持するAV/C Proxy Service Descriptionの例を表し、図２３は、図１９のノードサービス７２−１，７２−２が有するAV/C Node Service Descriptionの例を表す。
【０１２０】
図２０と図２１の例においては、deviceType「urn:schemas-upnp-org:device:1394ProxyDevice:1」が、root device６１−１に対応して記述され、deviceType「urn:sony-corp:device:1394NodeDevice:1」が、root device６１−２に対応して記述され、deviceType「urn:sony-corp:device:1394NodeDevice:1」が、root device６１−３に対応して記述されている。
【０１２１】
図示は省略されているが、deviceType「urn:schemas-upnp-org:device:1394ProxyDevice:1」のSCPDURLには、図２２のAV/C Proxy Service DescriptionのURLが記述され、deviceType「urn:sony-corp:device:1394ProxyDevice:1」とdeviceType「urn:sony-corp:device:1394NodeDevice:1」のSCPDURLには、それぞれ図２３のAV/C Nodes Service DescriptionのURLが記述される。
【０１２２】
図２２においては、serviceStateTableに「nodeNum」の変数の定義がなされている。この変数の定義は、Queryにより調べることができる。
【０１２３】
図２３においては、AV/Cコマンドを送るアクションである「avcCommandSend」が記述されている。
【０１２４】
図２４は、デバイスモデルのさらに他の構成例を表す。この例においては、図１９の例と同様に、ノードサービス７２−１，７２−２が、ノード毎に設けられているが、図１９の例と異なり、これらのサービスは、全て、プロキシサービス７１とともに、１個のroot device６１に保持されている。
【０１２５】
図２５は、図２４の例におけるroot device６１が有するAV/C Proxy Device Descriptionの構成を表し、図２６は、図２４のプロキシサービス７１が保持するAV/C Proxy service Descriptionの構成例を表し、図２７は、図２４のノードサービス７２−１，７２−２が有するAV/C Node Service Descriptionの構成例を表す。
【０１２６】
図２５の例においては、３つのサービスが規定されているserviceId「urn:sony-corp:serviceId:1394ProxyService1」のSCPDURLには、図２６のAV/C Proxy Service DescriptionのURLが記述され、serviceId「urn:sony-corp:serviceId:1394NodeService1」と「urn:sony-corp:serviceId:1394NodeService2」のSPCDURLには、図２７のAV/C Node Service DescriptionのURLが記述される。
【０１２７】
図２６の例においては、「nodeNum」の変数が規定されている。
【０１２８】
図２７の例においては、AV/Cコマンドを送るアクションが規定されている。
【０１２９】
図２８は、デバイスモデルのさらに他の構成例を表している。この構成例においては、root device６１にプロキシサービス７１が保持されている。また、ノードサービス７２−１，７２−２は、それぞれノード毎に設けられる他、root device６１の内部に形成されたエンベデッドデバイス（embedded device）８１−１，８１−２に、それぞれ保持される。
【０１３０】
図２９と図３０は、図２８におけるroot device６１が保持するAV/C Proxy Device Descriptionの構成例を表し、図３１は、図２８のプロキシサービス７１が保持するAV/C Proxy Service Descriptionの構成例を表し、図３２は、図２８のノードサービス７２−１，７２−２が有するAV/C Node Service Descriptionの構成例を表す。
【０１３１】
図２９と図３０の例において、serviceId「urn:sony-corp:serviceId:1394ProxyService1」は、図２８のプロキシサービス７１に対応し、そのSCPDURLには、図３１のAV/C Proxy Service DescriptionのURLが記述される。
【０１３２】
serviceId「urn:sony-corp:serviceId:1394NodeService1」は、図２８のAV/C node service７２−１に対応し、「urn:sony-corp:serviceId:1394NodeService2」は、AV/C node service７２−２に対応し、それぞれのSCPDURLには、図３２のAV/C node Service DescriptionのURLが記述される。
【０１３３】
図３１の例においては、「NODE Num」の変数が定義されている。
【０１３４】
図３２の例においては、AV/Cコマンドを送るアクション「avcCommandSend」が規定されている。
【０１３５】
次に、図３、図１９、図２４および図２８に示すデバイスモデルを比較する。
【０１３６】
図３の例においては、１つのroot device６１に、プロキシサービス７１とノードデバイス７２が、それぞれ１つずつ定義される。
【０１３７】
図１９の例においては、プロキシサービス７１が１つのroot device６１−１に定義されるとともに、１３９４上の個々のノードに対するノードサービス７２−１，７２−２が、root device６１−２，６１−３毎に定義される。
【０１３８】
図２４の例においては、プロキシサービス７１が、１つのroot device６１に設けられる他、ノードサービスが各ノード毎に対応して設けられ、それらのノードサービス７２−１，７２−２は、プロキシサービス７１と同様に、１つのroot device６１に保持される。
【０１３９】
図２８の例においては、１３９４上のノードが全てroot device６１のembedded device８１−１，８１−２として定義される。
【０１４０】
図３３は、図３、図１９、図２４、および図２８のデバイスモデルの特徴の比較結果を表している。なお、図３３において、タイプＡ、タイプＢ、タイプＣ、およびタイプＤは、それぞれ図３、図１９、図２４、または図２８のデバイスモデルに対応している。
【０１４１】
タイプＡからタイプＤまでを比較すると、SSDPのパケット量が大きく異なっていることがわかる。すなわち、root deviceが１個のとき、SSDPの数は、３＋２ｄ＋ｋとなる。ここで、ｄはembedded deviceの数、kはサービスタイプの数を意味する。従って、１３９４ネットワーク１２上のノードの数をＮとするとき、SSDPのパケットの量は、タイプＡのとき５個、タイプＢのとき４＋４Ｎ個、タイプＣのとき４＋Ｎ個、タイプＤのとき４＋３Ｎ個となる。特に、タイプＢ（図１９）とタイプＤ（図２８）の場合には、ノード数の数倍になる数のパケットが流れることになる。そこで、ネットワークのトラフィックの観点から考えた場合、SSDPのパケットの量が少ないタイプＡ（図３）の例が望ましい。
【０１４２】
バスの構成の変更の通知は、タイプＡの場合、GENAにより行われ、タイプＢ，Ｃ，Ｄの場合、SSDPにより行われる。
【０１４３】
presentation URLの構成の単位は、タイプＡとタイプＣがバス単位とされ、タイプＢとタイプＤがノード単位とされる。ノード毎にURLを持つことが可能なタイプＢ（図１９）とタイプＤ（図２８）が分かりやすいが、タイプＡ（図３）とタイプＣ（図２４）に関しても、プロキシサービス７１が、各ノードに対するリンクページのようなものを用意すれば、実質的に対応する機能は実現できると考えられる。
【０１４４】
NOTIFYの通知の単位は、タイプＡの場合、バス単位とされ、タイプＢ，Ｃ，Ｄの場合、ノード単位とされる。
【０１４５】
以上を総合すると、タイプＡ（図３）の例が最適と考えられる。
【０１４６】
以上においては、IEEE８０２ネットワーク１１に接続されている機器から、IEEE１３９４ネットワーク１２に接続されている機器を制御するようにしたが、後者から前者を制御することも可能である。
【０１４７】
上述した一連の処理は、ハードウエアにより実行させることもできるが、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０１４８】
この記録媒体は、図２に示すように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フロッピディスクを含む）、光ディスク４２（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２２や、記憶部２８に含まれるハードディスクなどで構成される。
【０１４９】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１５０】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１５１】
【発明の効果】
以上の如く本発明の情報処理装置および方法、記録媒体、並びにプログラムによれば、IEEE８０２に基づく第１のネットワークからのSOAPに基づくコマンドを、第２のネットワークのAV/Cコマンドに変換するようにしたので、簡単かつ確実に、第１のネットワークに接続されている機器から、第２のネットワークに接続されている機器を制御することが可能となる。
【図面の簡単な説明】
【図１】本発明が適用されるネットワークシステムの構成を示す図である。
【図２】図１のUPnPデバイス２の構成を示すブロック図である。
【図３】図１のUPnPデバイス２が有するデバイスモデルの構成を示す図である。
【図４】 AV/Cコマンドフレームの構成を示す図である。
【図５】 ctypeを説明する図である。
【図６】 subunit_typeを説明する図である。
【図７】図１のネットワークシステムの処理を説明するフローチャートである。
【図８】図７のステップＳ３において出力されるコマンドの構成を示す図である。
【図９】図７のステップＳ２４の処理で出力されるコマンドの構成を示す図である。
【図１０】図７のステップＳ３４の処理で出力されるレスポンスの構成を示す図である。
【図１１】図７のステップ２６の処理で出力されるレスポンスの例を示す図である。
【図１２】図３のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図１３】図３の１３９４ proxy serviceが有するAV/C Proxy Service Descriptionの構成を示す図である。
【図１４】図３の１３９４ nodes serviceが有するAV/C Nodes Service Descriptionの構成を示す図である。
【図１５】図３の１３９４ nodes serviceが有するAV/C Nodes Service Descriptionの構成を示す図である。
【図１６】図３のroot deviceが有するAV/C Proxy Device Descriptionの他の構成を示す図である。
【図１７】図３の１３９４ proxy serviceが有するAV/C Proxy Service Descriptionの他の構成を示す図である。
【図１８】図３の１３９４ nodes serviceが有するAV/C Nodes Service Descriptionの他の構成を示す図である。
【図１９】デバイスモデルの他の構成を示す図である。
【図２０】図１９のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図２１】図１９のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図２２】図１９の１３９４ proxy serviceが有するAV/C Proxy Service Descriptionの構成を示す図である。
【図２３】図１９のAV/C node serviceが有するAV/C Node Service Descriptionの構成を示す図である。
【図２４】デバイスモデルのさらに他の構成を示す図である。
【図２５】図２４のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図２６】図２４のAV/C proxy serviceが有するAV/C Proxy Service Descriptionの構成を示す図である。
【図２７】図２４のAV/C node serviceが有するAV/C Node Service Descriptionの構成を示す図である。
【図２８】デバイスモデルの他の構成を示す図である。
【図２９】図２８のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図３０】図２８のroot deviceが有するAV/C Proxy Device Descriptionの構成を示す図である。
【図３１】図２８のAV/C proxy serviceが有するAV/C Proxy Service Descriptionの構成を示す図である。
【図３２】図２８のAV/C node serviceが有するAV/C Node Service Descriptionの構成を示す図である。
【図３３】デバイスモデルの比較を示す図である。
【符号の説明】
１ UPnPコントロールポイント， ２ UPnPデバイス， ３，４ AV/C機器，１１ IEEE８０２ネットワーク， １２ IEEE１３９４ネットワーク， ６１
root device， ７１ AV/C proxy service， ７２ AV/C nodes service
Claims (9)
- IEEE802のSOAPに基づく第１のフォーマットで通信する第１のネットワークと、IEEE1394のAV/Cコマンドに基づく第２のフォーマットで通信する第２のネットワークとの間でデータを授受する情報処置装置において、
前記第１のネットワークから前記第１のフォーマットのデータを取り込む取り込み手段と、
前記取り込み手段により取り込まれた前記第１のフォーマットの前記SOAPに基づくコマンドを、前記第２のネットワークの前記AV/Cコマンドに変換して前記第２のフォーマットに格納するとともに、前記 SOAP に基づくコマンドに記述されている前記第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、前記 SOAP に基づくコマンドに記述されている前記第２のネットワークに接続されている機器を指定するノードユニーク ID を、前記対応表に基づいてノード ID に変換する変換手段と、
前記変換手段により変換された前記第２のフォーマットを、前記第２のネットワークに送信する送信手段と
を備えることを特徴とする情報処理装置。 - 前記変換手段は、前記SOAPに基づくコマンドと、それに基づいて前記第２のネットワークに送信されるコマンドとの対応表を有し、前記第２のネットワークを介して受信したレスポンスに対応する前記SOAPに基づくコマンドを、前記対応表に基づいて検索し、前記SOAPに基づくコマンドに対応するレスポンスを前記第１のネットワークに送信する
ことを特徴とする請求項１に記載の情報処理装置。 - 前記変換手段は、前記SOAPに基づくコマンドに含まれるトランザクションラベルに基づいて、前記SOAPに基づくコマンドとレスポンスを対応させる
ことを特徴とする請求項２に記載の情報処理装置。 - 前記変換手段は、前記第１のネットワークに接続されている機器からのリクエストに対応するファイナルレスポンスが、予め定められている時間内に、前記第２のネットワークに接続されている機器から受信されないとき、前記第１のネットワークに接続されている機器に対して処理中であることを表すレスポンスを送信する
ことを特徴とする請求項１に記載の情報処理装置。 - 前記SOAPに基づくコマンドが、前記第２のネットワークのバスリセット時に再送を要求するコマンドである場合、前記第２のネットワークのバスリセットを検知し、前記第２のネットワークにバスリセットが発生したとき、前記コマンドを送信する検知手段を
さらに備えることを特徴とする請求項１に記載の情報処理装置。 - 前記変換手段は、さらに前記第２のネットワークの前記AV/Cコマンドを、前記第１のフォーマットの前記SOAPに基づくコマンドに変換して前記第１のフォーマットに格納し、
前記送信手段は、さらに前記変換手段により変換された前記第１のフォーマットの前記SOAPに基づくコマンドを、前記第１のネットワークに送信する
ことを特徴とする請求項１に記載の情報処理装置。 - IEEE８０２のSOAPに基づく第１のフォーマットで通信する第１のネットワークと、IEEE１３９４のAV/Cコマンドに基づく第２のフォーマットで通信する第２のネットワークとの間でデータを授受する情報処理装置の情報処理方法において、
前記第１のネットワークからの前記第１のフォーマットのデータを取り込む取り込みステップと、
前記取り込みステップの処理により取り込まれた前記第１のフォーマットの前記SOAPに基づくコマンドを、前記第２のネットワークの前記AV/Cコマンドに変換して前記第２のフォーマットに格納するとともに、前記 SOAP に基づくコマンドに記述されている前記第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、前記 SOAP に基づくコマンドに記述されている前記第２のネットワークに接続されている機器を指定するノードユニーク ID を、前記対応表に基づいてノード ID に変換する変換ステップと、
前記変換ステップの処理により変換された前記第２のフォーマットを、前記第２のネットワークに送信する送信ステップと
を含むことを特徴とする情報処理方法。 - IEEE８０２のSOAPに基づく第１のフォーマットで通信する第１のネットワークと、IEEE１３９４のAV/Cコマンドに基づく第２のフォーマットで通信する第２のネットワークとの間でデータを授受する情報処理装置のプログラムであって、
前記第１のネットワークからの前記第１のフォーマットのデータを取り込む取り込みステップと、
前記取り込みステップの処理により取り込まれた前記第１のフォーマットの前記SOAPに基づくコマンドを、前記第２のネットワークの前記AV/Cコマンドに変換して前記第２のフォーマットに格納するとともに、前記 SOAP に基づくコマンドに記述されている前記第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、前記 SOAP に基づくコマンドに記述されている前記第２のネットワークに接続されている機器を指定するノードユニーク ID を、前記対応表に基づいてノード ID に変換する変換ステップと、
前記変換ステップの処理により変換された前記第２のフォーマットを、前記第２のネットワークに送信する送信ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - IEEE８０２のSOAPに基づく第１のフォーマットで通信する第１のネットワークと、IEEE１３９４のAV/Cコマンドに基づく第２のフォーマットで通信する第２のネットワークとの間でデータを授受する情報処理装置を制御するコンピュータに、
前記第１のネットワークからの前記第１のフォーマットのデータを取り込む取り込みステップと、
前記取り込みステップの処理により取り込まれた前記第１のフォーマットの前記SOAPに基づくコマンドを、前記第２のネットワークの前記AV/Cコマンドに変換して前記第２のフォーマットに格納するとともに、前記 SOAP に基づくコマンドに記述されている前記第２のネットワークに接続されている機器を指定するノードユニーク ID とノード ID の対応表を有し、前記 SOAP に基づくコマンドに記述されて いる前記第２のネットワークに接続されている機器を指定するノードユニーク ID を、前記対応表に基づいてノード ID に変換する変換ステップと、
前記変換ステップの処理により変換された前記第２のフォーマットを、前記第２のネットワークに送信する送信ステップと
を実行させるプログラム。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001226390A JP3661936B2 (ja) | 2001-05-24 | 2001-07-26 | 情報処理装置および方法、記録媒体、並びにプログラム |
| CN02801817A CN1463521A (zh) | 2001-05-24 | 2002-05-20 | 信息处理设备 |
| EP02726442A EP1300989A1 (en) | 2001-05-24 | 2002-05-20 | Information processing apparatus |
| US10/333,708 US20030177270A1 (en) | 2001-05-24 | 2002-05-20 | Information processing apparatus |
| KR10-2003-7001005A KR20030024806A (ko) | 2001-05-24 | 2002-05-20 | 정보 처리 장치 |
| PCT/JP2002/004835 WO2002096037A1 (fr) | 2001-05-24 | 2002-05-20 | Appareil de traitement d'informations |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001-154751 | 2001-05-24 | ||
| JP2001154751 | 2001-05-24 | ||
| JP2001226390A JP3661936B2 (ja) | 2001-05-24 | 2001-07-26 | 情報処理装置および方法、記録媒体、並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003046535A JP2003046535A (ja) | 2003-02-14 |
| JP3661936B2 true JP3661936B2 (ja) | 2005-06-22 |
Family
ID=26615608
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001226390A Expired - Fee Related JP3661936B2 (ja) | 2001-05-24 | 2001-07-26 | 情報処理装置および方法、記録媒体、並びにプログラム |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20030177270A1 (ja) |
| EP (1) | EP1300989A1 (ja) |
| JP (1) | JP3661936B2 (ja) |
| KR (1) | KR20030024806A (ja) |
| CN (1) | CN1463521A (ja) |
| WO (1) | WO2002096037A1 (ja) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10302477A1 (de) * | 2003-01-23 | 2005-02-24 | Deutsche Thomson-Brandt Gmbh | Verfahren zur Verfügbarmachung eines Eingabeparameters einer Netzwerkstation eines Netzwerks eines ersten Typs in einem Netzwerk eines zweiten Typs sowie Verbindungseinheit zur Verbindung der Netzwerke des ersten und zweiten Typs |
| JP2004272632A (ja) * | 2003-03-10 | 2004-09-30 | Sony Corp | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム |
| KR100565060B1 (ko) * | 2003-03-14 | 2006-03-30 | 삼성전자주식회사 | 언어 정보에 따라 적응적으로 재생가능한 데이터 구조로기록된 정보저장매체, 그 재생 방법 및 장치 |
| WO2004088522A1 (ja) | 2003-03-31 | 2004-10-14 | Fujitsu Limited | バスブリッジ装置、バスブリッジ方法および入出力制御装置 |
| KR100493896B1 (ko) | 2003-04-18 | 2005-06-10 | 삼성전자주식회사 | 디지털 콘텐트 메타데이터 변환 방법 및 장치, 그리고이를 이용한 네트워크 시스템 |
| JPWO2004095293A1 (ja) * | 2003-04-24 | 2006-07-13 | 三菱電機株式会社 | 映像情報システム、およびモジュールユニット |
| US10560278B2 (en) | 2003-06-30 | 2020-02-11 | Koninklijke Philips N.V. | Embedding a UPnP AV MediaServer object ID in a URI |
| KR101015811B1 (ko) * | 2003-09-23 | 2011-02-22 | 엘지전자 주식회사 | UPnP 기반의 미디어 콘텐츠 재생을 제어하는 전자기기 및 그 방법 |
| CN1620060B (zh) * | 2003-11-17 | 2010-04-28 | 国际商业机器公司 | 把浏览器不兼容的信息整合在网络内容中以及显示该信息的方法和设备 |
| US20050144137A1 (en) * | 2003-12-24 | 2005-06-30 | Kumar B. V. | Protocol processing device and method |
| EP1569418B1 (en) * | 2004-02-26 | 2009-10-14 | Research In Motion Limited | An apparatus and method for aggregating web services |
| JP4337591B2 (ja) | 2004-03-19 | 2009-09-30 | 株式会社日立製作所 | 情報処理装置、ネットワークシステムおよびネットワークシステムの制御方法 |
| JP4645165B2 (ja) * | 2004-11-12 | 2011-03-09 | セイコーエプソン株式会社 | ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御 |
| KR100639970B1 (ko) | 2004-12-16 | 2006-11-01 | 한국전자통신연구원 | ＵＰｎＰ ＡＶ 시스템 및 미디어 렌더러와 재생 모듈간의통신 수행 방법 |
| JP4164490B2 (ja) * | 2004-12-17 | 2008-10-15 | キヤノン株式会社 | 通信装置、プロファイル情報取得方法、及び、プログラム |
| WO2006080026A1 (en) * | 2005-01-27 | 2006-08-03 | Infosys Technologies Limited | Protocol processing device and method |
| KR100643296B1 (ko) * | 2005-05-11 | 2006-11-10 | 삼성전자주식회사 | 웹 서비스 기술을 지원하는 ａ/ｖ 네트워크에서 컨텐츠서비스 제공 방법 및 장치 |
| KR100739743B1 (ko) * | 2005-10-19 | 2007-07-13 | 삼성전자주식회사 | 홈 네트워크에서 디바이스를 독점적으로 제어하기 위한방법 및 장치 |
| US7788409B2 (en) * | 2005-10-28 | 2010-08-31 | Sony Corporation | System and method for achieving interoperability in home network with IEEE 1394 and UPnP devices |
| JP2007150853A (ja) * | 2005-11-29 | 2007-06-14 | Toshiba Corp | 供給装置と処理装置及び指示方法 |
| JP2007156691A (ja) * | 2005-12-02 | 2007-06-21 | Seiko Epson Corp | ネットワーク型プラグアンドプレイに対応したネットワーク中継制御 |
| KR100714708B1 (ko) * | 2006-01-12 | 2007-05-04 | 삼성전자주식회사 | 홈 네트워크에서 디바이스 간 호환성을 지원하는 미들웨어장치 및 그 방법 |
| US7813823B2 (en) * | 2006-01-17 | 2010-10-12 | Sigmatel, Inc. | Computer audio system and method |
| KR100772865B1 (ko) * | 2006-01-31 | 2007-11-02 | 삼성전자주식회사 | Ａｖ 세션 복원 방법 및 이를 위한 컨트롤 포인트 |
| EP1990956A4 (en) * | 2006-03-01 | 2013-07-17 | Mitsubishi Electric Corp | GATEWAY DEVICE |
| US20100063970A1 (en) * | 2006-05-19 | 2010-03-11 | Chang Hyun Kim | Method for managing and processing information of an object for presentation of multiple sources and apparatus for conducting said method |
| CN101325530B (zh) * | 2008-07-04 | 2011-11-30 | 海信集团有限公司 | 一种二级网络及其通信方法 |
| KR101669672B1 (ko) * | 2009-08-17 | 2016-11-10 | 삼성전자주식회사 | 단말의 원격 관리 방법 및 장치 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10145420A (ja) * | 1996-11-12 | 1998-05-29 | Sony Corp | 異なるシステムに接続された機器の制御方法及び変換機器 |
| JP3688464B2 (ja) * | 1997-05-06 | 2005-08-31 | 株式会社東芝 | 端末装置、サーバ装置、通信装置および制御方法 |
| JP3576019B2 (ja) * | 1998-12-28 | 2004-10-13 | 株式会社東芝 | 通信ノード |
| US6813651B1 (en) * | 2000-02-18 | 2004-11-02 | Controlnet, Inc. | Interface device for ethernet transceiver and 1394 controller |
| US20020174236A1 (en) * | 2001-03-26 | 2002-11-21 | Sanjay Mathur | Methods and apparatus for processing data in a content network |
-
2001
- 2001-07-26 JP JP2001226390A patent/JP3661936B2/ja not_active Expired - Fee Related
-
2002
- 2002-05-20 KR KR10-2003-7001005A patent/KR20030024806A/ko not_active Application Discontinuation
- 2002-05-20 US US10/333,708 patent/US20030177270A1/en not_active Abandoned
- 2002-05-20 WO PCT/JP2002/004835 patent/WO2002096037A1/ja not_active Application Discontinuation
- 2002-05-20 EP EP02726442A patent/EP1300989A1/en not_active Withdrawn
- 2002-05-20 CN CN02801817A patent/CN1463521A/zh active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP1300989A1 (en) | 2003-04-09 |
| CN1463521A (zh) | 2003-12-24 |
| KR20030024806A (ko) | 2003-03-26 |
| US20030177270A1 (en) | 2003-09-18 |
| WO2002096037A1 (fr) | 2002-11-28 |
| JP2003046535A (ja) | 2003-02-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3661936B2 (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| JP4456095B2 (ja) | ホームネットワークで第３の装置のイベントを処理する方法及び装置 | |
| JP3805725B2 (ja) | 相異なるミドルウェアを使用するホームネットワーク上のデバイス間のメッセージの受け渡しを可能にするゲートウェイ、ホームネットワークシステム及びメッセージ受け渡し方法 | |
| KR100984810B1 (ko) | ＵＰｎＰ 디바이스가 ＰＬＣ 디바이스를 컨트롤할 수있도록 브릿징하는 장치 및 방법 | |
| KR100440969B1 (ko) | 네트워킹 방법 및 그 장치 | |
| US8423671B2 (en) | Middleware device and method of supporting compatibility of devices in home network | |
| US7130925B2 (en) | Information processing apparatus and method for receiving/transmitting data between an IEEE802-based format and an IEEE1394-based format | |
| US7844738B2 (en) | Method of and apparatus for bridging a UPnP network and a rendezvous network | |
| EP1058422A1 (en) | Methods for bridging a HAVi sub-network and a UPnP sub-network and device for implementing said methods | |
| US20040120344A1 (en) | Device discovery application interface | |
| JP3661935B2 (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| US20040133896A1 (en) | Network device application interface | |
| JP2012138949A (ja) | ＵＰｎＰネットワークで非正常的に終了した被制御装置の終了メッセージを伝送するための方法及び装置 | |
| JP2003008610A (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| KR20050078541A (ko) | 홈네트워크 디바이스 모니터링 및 제어 방법 | |
| US9338022B2 (en) | Method of processing action, method of controlling controlled device, controlled device, and control point | |
| JP2004104839A (ja) | 情報処理装置および方法、並びに通信システム | |
| EP2168305B1 (en) | Method of receiving/transmitting event message, controlled device, and control point | |
| KR100952280B1 (ko) | 댁내에 설치되는 주거 게이트웨이의 재부팅을 원격으로제어하는 방법 | |
| KR20050055134A (ko) | 망관리 정보를 이용한 바이바이 메시지의 대체 전송 장치,시스템 및 그 방법 | |
| KR20040039043A (ko) | ＵＰｎＰ 네트워크 시스템의 제어 메시지 전송 방법 | |
| Siebörger | Multiprotocol Control of Networked Home Entertainment Devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050304 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050317 |
|
| LAPS | Cancellation because of no payment of annual fees |