JP3661935B2 - 情報処理装置および方法、記録媒体、並びにプログラム - Google Patents
情報処理装置および方法、記録媒体、並びにプログラム Download PDFInfo
- Publication number
- JP3661935B2 JP3661935B2 JP2001186645A JP2001186645A JP3661935B2 JP 3661935 B2 JP3661935 B2 JP 3661935B2 JP 2001186645 A JP2001186645 A JP 2001186645A JP 2001186645 A JP2001186645 A JP 2001186645A JP 3661935 B2 JP3661935 B2 JP 3661935B2
- Authority
- JP
- Japan
- Prior art keywords
- command
- information processing
- soap
- processing apparatus
- ieee
- 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 OR CALCULATING; 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/2803—Home automation networks
-
- 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/2803—Home automation networks
- H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
- H04L12/282—Controlling appliance services of a home automation network by calling their functionalities based on user interaction within the home
-
- 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/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Automation & Control Theory (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Selective Calling Equipment (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置および方法、記録媒体、並びプログラムに関し、特に、IEEE８０２に基づくネットワークに接続されている機器が、簡単、かつ確実に、相互に通信し、制御することができる安価なシステムを実現できるようにした、情報処理装置および方法、記録媒体、並びプログラムに関する。
【０００２】
【従来の技術】
最近、IEEE（Institute of Electrical and Electronics Engineers）８０２ネットワークが普及してきた。このIEEE８０２は、主にパーソナルコンピュータを相互に接続するためのネットワークであり、UPnP（Universal Plag and Play）のプロトコルに基づいて、各パーソナルコンピュータは、他のパーソナルコンピュータを制御することができる。
【０００３】
【発明が解決しようとする課題】
UPnPの規定には、Device Descripitionに機器情報を記述することや、SOAP（Simple Object Access Protocol）や、GENA（General Event 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（Central Processing Unit）２１は、ROM（Read Only Memory）２２に記憶されているプログラム、または記憶部２８からRAM（Random Access Memory）２３にロードされたプログラムに従って各種の処理を実行する。RAM２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００２０】
CPU２１、ROM２２、およびRAM２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インタフェース２５も接続されている。
【００２１】
入出力インタフェース２５には、キーボード、マウスなどよりなる入力部２６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部２７、ハードディスクなどより構成される記憶部２８、モデム、ターミナルアダプタなどより構成される通信部２９が接続されている。通信部２９は、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 Discription）も、サービス情報に記述されている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デバイス２は、内部に、図３に示されるデバイスモデルを有する。この例のデバイスモデルは、１個のルートデバイス（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 INQUIRY（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とNOT IMPLEMENTEDがある。IMPLEMENTED（ctype＝１１００）は、コマンドが実装されていることを通知する。
【００５５】
NOTIFYコマンドに対するレスポンスとしては、NOT IMPLEMENTED，REJECTED，INTERIM，CHANGEDがある。
【００５６】
INTERIMは、NOTIFYが受け付けられたことをまず通知する。CHANGED（ctype＝１１０１）は、その後、ターゲットの状態が変化したことを通知する。但し、本発明においては、AV/Cコマンド受信後、一定の時間（例えば、３０秒間）が経過していてもファイナルレスポンスを出力することが困難な場合にも、INTERIMが出力される。
【００５７】
図４のAV/Cコマンドフレームにおけるsubunit_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 INFORMATION TYPEを表し、その値のＣＢｈは、DIRECT SERECT DATAを表す。
【００６３】
このように、各subunit毎に、opcodeのテーブルが用意される。また、各opcode毎に、operandが定義される。
【００６４】
例えば、チューナの選局が行われる場合、opcodeは、DIRECT SELECT INFORMATION TYPEとされ、operandで周波数やチャンネル番号などのパラメータが指定される。
【００６５】
次に、図７のフローチャートを参照して、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/C POWER control command（２進数）におけるCTS「００００」、ctype「００００」、subunit_type「１１１１１」、並びにsubunit_ID「１１１」に対応している。すなわち、１６進数の「００ＦＦ」を２進数で表すと、「００００００００１１１１１１１１」になる。
【００７１】
次の「Ｂ２」はopcodeに対応し、「７０」は、operandに対応する。
【００７２】
これらのコマンドの内容を表す値は全てテキストで表されているため、どの種類のAV/Cコマンドも記述することが可能となる。
【００７３】
図７に戻って、UPnPデバイス２は、ステップＳ１１において、図８に示されるActionのインボークを受け取ると、そのコマンドの内容に対応して、装置の電源をオンする。
【００７４】
その後、ステップＳ１２において、UPnPデバイス２のAV/Cサービス７１は、その処理に対応する図１０に示されるようなAV/Cレスポンス（AV/C POWER response）を生成し、図１１に示されるようなSOAPプロトコルに基づくActionとしてResponseに格納し、UPnPコントロールポイント１に送信する。
【００７５】
図１１に示されるTransactionに示される値「５」は、図８のAction（Command）と対をなすAction（Responce）であることを表すために、図８におけるTransactionの値「５」に対応して「５」（同一の値）とされている。
【００７６】
そのresponse「０９FFB２７０」（１６進数）は、図１０のAV/C POWER responseに記述されている２進数の値「００００１００１１１１１１１１１１０１０００１００１１１００００」に対応している。
【００７７】
UPnPコントロールポイント１は、ステップＳ２において、このレスポンスを受信する。これにより、UPnPコントロールポイント１は、UPnPデバイス２が装置の電源をオンしたことを知ることができる。
【００７８】
AV/Cの規則の規定によれば、AV/C機器は、受信したリクエストに対応する処理を直ちに実行できないとき、INTERIMをレスポンスとして返すことが規定されている。そのAV/C機器は、その後、そのリクエストに対応する処理が完了したとき、その時点において、ファイナルレスポンスをリクエストの送信者に返すことになる。しかしながら、リクエストを受信してから、ファイナルレスポンスが返されるまでの時間は規定されていない。
【００７９】
本発明では、AV/Cサービス７１は、ステップＳ１１の処理でUPnPコントロールポイント１に対してAV/Cコマンドを出力した後、ステップＳ２５の処理で、UPnPコントロールポイント１からコマンドを受けてから、ステップＳ１２の処理で、ファイナルレスポンスを送信するまでの時間を予測する。予め設定されている所定の時間（例えば、３０秒間）以内にファイナルレスポンスが送信可能である場合、AV/Cサービス７１は、INTERIMをUPnPコントロールポイント１に直ちに転送せず、コマンドに対応する処理が完了するまで待機し、３０秒以内に処理を完了したとき、ファイナルレスポンスをUPnPコントロールポイント１に出力する。
【００８０】
これに対して、３０秒以内にコマンドに対応する処理が完了しない場合、AV/Cサービス７１は、INTERIMをUPnPコントロールポイント１に出力する。そして、処理が完了したとき、ファイナルレスポンスが送送信される。これにより、UPnPコントロールポイント１は、少なくとも３０秒間以内に要求した処理が完了できるか否かを知ることができる。
【００８１】
以上の処理を実行するために、図３に示されるUPnPデバイス２（UPnPコントロールポイント１も同様）が有するデバイスモデルのルートデバイス６１は、図１２に示されるUPnP Device Descriptionを有し、AV/Cサービス７１は、図１３に示されるUPnP Service Descriptionを有する。
【００８２】
これらのDescriptionは、その機器が有する機能を実行するとき必要とするパラメータ、その他の条件を記述したものであり、他の機器は、その機器に、その機能の実行を要求するとき、そのDescriptionを参照することで、そこに記述されている条件を付加して、その機器にコマンドを送ることになる。
【００８３】
図１２におけるdeviceType「urn:schemas-upnp-org:device:unitDevice:1」は、ルートデバイス６１の型が、unit Deviceであることを表している。FriendlyName「AV/C on UPnP Device」は、ルートデバイス６１のフレンドリーネームを表している。
【００８４】
UDN「nuid:upnp-avcupnp-root-0800460000000000」は、ルートデバイス６１の固有の番号を表している。
【００８５】
このUPnP Device Descriptionにおいては、サービスの型であるServiceTypeが「urn:schemas-upnp-org:service:avcService:1」であり、serviceIdが「urn:sony-corp:serviceId:avcService0」であるserviceが規定されている。
【００８６】
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が「urn:sony-corp:serviceId:avcService0」のserviceが記述されている。このSCPDURLの「./scpd/scpd.xml」は、図１５と図１６に示されるUPnP Service DescriptionのURLを表している。
【００９０】
図１５と図１６には、AV/Cコマンドを送るアクションである「avcCommandSend」が記述されている。このactionには、「avcCommand」、「InTrLabel」、「avcResponse」、「outTrLabel」の４つのパラメータが規定されている。これらには、関連する状態変数として、「avcCommand」、「trLabel」、「avcResponse」、「trLabel」がそれぞれ規定されており、それぞれは、「serviceStateTable」に、データの形が「bin.hex」であることが規定されている。
【００９１】
なお、diriectionの「in」は、そのパラメータが、このDescriptionを有する機器から、他の機器に入力されるものであることを表し、「out」は、他の機器から出力され、このDescriptionを有する機器に送信されてくるパラメータであることを表す。
【００９２】
stateVariable sendEvents=noは、その変数の状態が変化したときでもSUBSCRIBEしている機器に対して通知をしないものであることを表す。
【００９３】
以上においては、図３に示されるように、１個のルートデバイス６１に、１個のAV/Cサービス７１を保持させるようにしたが、例えば、図１７に示されるように、root deviceをunitに対応させるとともに、embedded deviceをsubunitに対応させることができる。そして、この例の場合、各deviceが、AV/C serviceを１つだけ有する。
【００９４】
具体的には、図１７の例においては、root device６１が、AV/C service７１−１を有し、root device６１が有するembedded device８１−１と８１−２が、それぞれAV/C service７１−２と７１−３を有する。
【００９５】
図１８と図１９は、図１７のroot device６１が有するUPnP Device Descriptionと、AV/C service７１−１が有するUPnP Device Descriptionの構成例を表している。
【００９６】
図１８の例においては、deviceTypeが「urn:sony-corp:device:unitDevice:1」であるdeviceが設けられ、このdeviceは、serviceIdが「urn:sony-corp:serviceId:avcService0」であるserviceTypeが「urn:sony-corp:service:avcService:1」のserviceを有している。そのSCPDURL「./scpd/root/scpd.xml」には、例えば、図１９のUPnP Service DescriptionのURLが記述される。
【００９７】
また、このdeviceには、さらにdeviceTypeが「urn:sony-corp:device:discDevice:1」であるdevice（embdded device８１−１に対応する）が記述されている。このdeviceは、serviceTypeが「urn:sony-corp:service:avcService:1」のserviceが記述されている。そのSCPDURLの「./scpd/disc0/scpd.xml」は、例えば、AV/C sevice７１−２が有するservice DescriptionのURLを表している。
【００９８】
図１９においては、AV/Cコマンドを送るアクション「avcCommandSend」が記述されている。このアクションは、「avcCommand」と「avcResponce」の２つの引数を有している。これらの引数のデータの形は、serviceStatTableに「bin.hex」として規定されている。
【００９９】
図２０は、デバイスモデルのさらに他の構成例を表す。この例においては、図１７の例と同様に、root deviceがunitに対応され、embedded deviceがsupunitに対応される。ただし、この例においては、図１７の例と異なり、それぞれのdeviceにおいて対応するAV/Cコマンドのopcode毎に、serviceが１つづつ定義される。
【０１００】
具体的には、図２０の例においては、root device６１がpower service９１−１の他、他のopcodeに対応するservice９１−２を有する。
【０１０１】
また、embedded device８１−１は、play service９２−１を有する他、他のAV/Cコマンドのopcodeに対応するservice９２−２を有する。
【０１０２】
さらに、embedded device８１−２も、play service９２−３を有する他、他のopcpdeに対応するservice２２−４を有する。
【０１０３】
各serviceにおいて、Controlは、actionにより実現され、Statusは、Queryにより実現され、Notifyは、GENAにより実現される。General Inquiryは、Device Descriptionにより代用することが可能である。
【０１０４】
図２１と図２２は、図２０の例におけるroot device６１が有するUPnP Device Descriptionの構成を表し、図２３は、図２０のpower service９１−１が保持するUPnP service Descriptionの構成例を表している。
【０１０５】
図２１のdeviceType「urn:sony-corp:device:rootDevice:1」は、図２０のroot device６１に対応し、そのserviceType「urn:sony-corp:service:avcPowerService:1」は、図２０のpower service９１−１に対応する。
【０１０６】
deviceType「urn:sony-corp:device:discDevice:1」は、図２０のembedded device８１−１に対応し、そのserviceType「urn:sony-corp:service:avcPrayService:1」は、play service９２−１に対応し、そのserviceType「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:service:avcPlayService:1」のSCPDURL「./scpd/disc0/play/scpd.xml」は、play service９２−１が援用するService DescriptionのURLが記述される。同様に、serviceTypeが「urn:sony-corp:service:avcStopService:1」のSCPDURL「./scpd/disc0/stop/scpd.xml」は、service９２−３が援用するservice Descriptionが記述される。
【０１０９】
図２３の例においては、AV/Cコマンドを送る「avcCommandSend」のactionが記述されている。これらには、「avcCommand」と「avcResponse」の２つの引数が付加されており、それぞれのデータの形は、serviceStateTableに「bin.hex」として規定されている。
【０１１０】
図２４は、図３、図１７、および図２０のデバイスモデルの特徴の比較結果を表している。なお、図２４において、タイプＡ、タイプＢ、およびタイプＣは、それぞれ図３、図１７、または図２０のデバイスモデルに対応している。
【０１１１】
タイプＡからタイプＣまでを比較すると、SSDPのパケット量が大きく異なっていることがわかる。すなわち、root deviceが１個のとき、SSDPの数は、３＋２ｄ＋ｋとなる。ここで、ｄはembedded deviceの数、kはサービスタイプの数を意味する。従って、subunitの数をＮとするとき、SSDPのパケットの量は、タイプＡのとき４個、タイプＢのとき４＋３Ｎ個、タイプＣのとき３＋２Ｎ＋Ｃ個となる。なお、Ｃは、対応しているopcodeの延べの数を表している。
【０１１２】
特に、タイプＢ（図１７）の場合には、subunit数の数倍になる数のパケットが流れることになる。そこで、ネットワークのトラフィックの観点から考えた場合、SSDPのパケットの量が少ないタイプＡ（図３）の例が望ましい。
【０１１３】
NOTIFYの通知の単位は、タイプＡとタイプＢの場合、全コマンド単位とされ、タイプＣの場合、各コマンド単位とされる。
【０１１４】
以上を総合すると、タイプＡ（図３）の例が最適と考えられる。
【０１１５】
以上においては、UPnPコントロールポイント１から、UPnPデバイス２を制御する場合を例としたが、UPnPデバイス２から、UPnPコントロールポイント１を制御することも可能である。ただし、この場合、UPnPデバイス２が、上述したUPnPコントロールポイントとなり、UPnPコントロールポイントが、UPnPデバイスとなるので、結局は、上述した場合と同様となる。
【０１１６】
上述した一連の処理は、ハードウエアにより実行させることもできるが、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０１１７】
この記録媒体は、図２に示すように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フロッピディスクを含む）、光ディスク４２（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２２や、記憶部２８に含まれるハードディスクなどで構成される。
【０１１８】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１１９】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１２０】
【発明の効果】
以上の如く本発明の情報処理装置および方法、記録媒体、並びにプログラムによれば、SOAPに基づくコマンドに格納されたAV/Cコマンドを抽出し、処理するようにしたので、新たなコマンド体系を構築する必要がなく、簡単かつ確実に、ネットワークに接続されている機器を制御することができる安価なシステムを実現することが可能となる。
【図面の簡単な説明】
【図１】本発明が適用されるネットワークシステムの構成を示す図である。
【図２】図１のUpnPデバイス２の構成を示すブロック図である。
【図３】図１のUPnPデバイス２が有するデバイスモデルの構成を示す図である。
【図４】 AV/Cコマンドフレームの構成を示す図である。
【図５】 ctypeを説明する図である。
【図６】 subunit_typeを説明する図である。
【図７】図１のネットワークシステムの処理を説明するフローチャートである。
【図８】図７のステップＳ１において出力されるコマンドの構成を示す図である。
【図９】図８のコマンドに格納されるAV/Cコマンドの構成を示す図である。
【図１０】図１１のコマンドに格納されるAV/Cレスポンスの構成を示す図である。
【図１１】図７のステップ１２の処理で出力されるレスポンスの例を示す図である。
【図１２】図３のroot deviceが有するUPnP Device Descriptionの構成を示す図である。
【図１３】図３のAV/C serviceが有するUPnP Service Descriptionの構成を示す図である。
【図１４】図３のroot serviceが有するUPnP Device Descriptionの他の構成を示す図である。
【図１５】図３のAV/C serviceが有するUPnP Service Descriptionの他の構成を示す図である。
【図１６】図３のAV/C serviceが有するUPnP Service Descriptionの他の構成を示す図である。
【図１７】デバイスモデルの他の構成を示す図である。
【図１８】図１７のroot deviceが有するUPnP Device Descriptionの構成を示す図である。
【図１９】図１７のAV/C serviceが有するUPnP Service Descriptionの構成を示す図である。
【図２０】デバイスモデルのさらに他の構成を示す図である。
【図２１】図２０のroot deviceが有するUPnP Device Descriptionの構成を示す図である。
【図２２】図２０のroot deviceが有するUPnP Device Descriptionの構成を示す図である。
【図２３】図２０のAV/C serviceが有するUPnP Service Descriptionの構成を示す図である。
【図２４】デバイスモデルの比較を示す図である。
【符号の説明】
１ UPnPコントロールポイント， ２ UPnPデバイス， １１ IEEE８０２ネットワーク， ６１ root device， ７１ AV/C service
【発明の属する技術分野】
本発明は、情報処理装置および方法、記録媒体、並びプログラムに関し、特に、IEEE８０２に基づくネットワークに接続されている機器が、簡単、かつ確実に、相互に通信し、制御することができる安価なシステムを実現できるようにした、情報処理装置および方法、記録媒体、並びプログラムに関する。
【０００２】
【従来の技術】
最近、IEEE（Institute of Electrical and Electronics Engineers）８０２ネットワークが普及してきた。このIEEE８０２は、主にパーソナルコンピュータを相互に接続するためのネットワークであり、UPnP（Universal Plag and Play）のプロトコルに基づいて、各パーソナルコンピュータは、他のパーソナルコンピュータを制御することができる。
【０００３】
【発明が解決しようとする課題】
UPnPの規定には、Device Descripitionに機器情報を記述することや、SOAP（Simple Object Access Protocol）や、GENA（General Event 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（Central Processing Unit）２１は、ROM（Read Only Memory）２２に記憶されているプログラム、または記憶部２８からRAM（Random Access Memory）２３にロードされたプログラムに従って各種の処理を実行する。RAM２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００２０】
CPU２１、ROM２２、およびRAM２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インタフェース２５も接続されている。
【００２１】
入出力インタフェース２５には、キーボード、マウスなどよりなる入力部２６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部２７、ハードディスクなどより構成される記憶部２８、モデム、ターミナルアダプタなどより構成される通信部２９が接続されている。通信部２９は、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 Discription）も、サービス情報に記述されている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デバイス２は、内部に、図３に示されるデバイスモデルを有する。この例のデバイスモデルは、１個のルートデバイス（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 INQUIRY（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とNOT IMPLEMENTEDがある。IMPLEMENTED（ctype＝１１００）は、コマンドが実装されていることを通知する。
【００５５】
NOTIFYコマンドに対するレスポンスとしては、NOT IMPLEMENTED，REJECTED，INTERIM，CHANGEDがある。
【００５６】
INTERIMは、NOTIFYが受け付けられたことをまず通知する。CHANGED（ctype＝１１０１）は、その後、ターゲットの状態が変化したことを通知する。但し、本発明においては、AV/Cコマンド受信後、一定の時間（例えば、３０秒間）が経過していてもファイナルレスポンスを出力することが困難な場合にも、INTERIMが出力される。
【００５７】
図４のAV/Cコマンドフレームにおけるsubunit_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 INFORMATION TYPEを表し、その値のＣＢｈは、DIRECT SERECT DATAを表す。
【００６３】
このように、各subunit毎に、opcodeのテーブルが用意される。また、各opcode毎に、operandが定義される。
【００６４】
例えば、チューナの選局が行われる場合、opcodeは、DIRECT SELECT INFORMATION TYPEとされ、operandで周波数やチャンネル番号などのパラメータが指定される。
【００６５】
次に、図７のフローチャートを参照して、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/C POWER control command（２進数）におけるCTS「００００」、ctype「００００」、subunit_type「１１１１１」、並びにsubunit_ID「１１１」に対応している。すなわち、１６進数の「００ＦＦ」を２進数で表すと、「００００００００１１１１１１１１」になる。
【００７１】
次の「Ｂ２」はopcodeに対応し、「７０」は、operandに対応する。
【００７２】
これらのコマンドの内容を表す値は全てテキストで表されているため、どの種類のAV/Cコマンドも記述することが可能となる。
【００７３】
図７に戻って、UPnPデバイス２は、ステップＳ１１において、図８に示されるActionのインボークを受け取ると、そのコマンドの内容に対応して、装置の電源をオンする。
【００７４】
その後、ステップＳ１２において、UPnPデバイス２のAV/Cサービス７１は、その処理に対応する図１０に示されるようなAV/Cレスポンス（AV/C POWER response）を生成し、図１１に示されるようなSOAPプロトコルに基づくActionとしてResponseに格納し、UPnPコントロールポイント１に送信する。
【００７５】
図１１に示されるTransactionに示される値「５」は、図８のAction（Command）と対をなすAction（Responce）であることを表すために、図８におけるTransactionの値「５」に対応して「５」（同一の値）とされている。
【００７６】
そのresponse「０９FFB２７０」（１６進数）は、図１０のAV/C POWER responseに記述されている２進数の値「００００１００１１１１１１１１１１０１０００１００１１１００００」に対応している。
【００７７】
UPnPコントロールポイント１は、ステップＳ２において、このレスポンスを受信する。これにより、UPnPコントロールポイント１は、UPnPデバイス２が装置の電源をオンしたことを知ることができる。
【００７８】
AV/Cの規則の規定によれば、AV/C機器は、受信したリクエストに対応する処理を直ちに実行できないとき、INTERIMをレスポンスとして返すことが規定されている。そのAV/C機器は、その後、そのリクエストに対応する処理が完了したとき、その時点において、ファイナルレスポンスをリクエストの送信者に返すことになる。しかしながら、リクエストを受信してから、ファイナルレスポンスが返されるまでの時間は規定されていない。
【００７９】
本発明では、AV/Cサービス７１は、ステップＳ１１の処理でUPnPコントロールポイント１に対してAV/Cコマンドを出力した後、ステップＳ２５の処理で、UPnPコントロールポイント１からコマンドを受けてから、ステップＳ１２の処理で、ファイナルレスポンスを送信するまでの時間を予測する。予め設定されている所定の時間（例えば、３０秒間）以内にファイナルレスポンスが送信可能である場合、AV/Cサービス７１は、INTERIMをUPnPコントロールポイント１に直ちに転送せず、コマンドに対応する処理が完了するまで待機し、３０秒以内に処理を完了したとき、ファイナルレスポンスをUPnPコントロールポイント１に出力する。
【００８０】
これに対して、３０秒以内にコマンドに対応する処理が完了しない場合、AV/Cサービス７１は、INTERIMをUPnPコントロールポイント１に出力する。そして、処理が完了したとき、ファイナルレスポンスが送送信される。これにより、UPnPコントロールポイント１は、少なくとも３０秒間以内に要求した処理が完了できるか否かを知ることができる。
【００８１】
以上の処理を実行するために、図３に示されるUPnPデバイス２（UPnPコントロールポイント１も同様）が有するデバイスモデルのルートデバイス６１は、図１２に示されるUPnP Device Descriptionを有し、AV/Cサービス７１は、図１３に示されるUPnP Service Descriptionを有する。
【００８２】
これらのDescriptionは、その機器が有する機能を実行するとき必要とするパラメータ、その他の条件を記述したものであり、他の機器は、その機器に、その機能の実行を要求するとき、そのDescriptionを参照することで、そこに記述されている条件を付加して、その機器にコマンドを送ることになる。
【００８３】
図１２におけるdeviceType「urn:schemas-upnp-org:device:unitDevice:1」は、ルートデバイス６１の型が、unit Deviceであることを表している。FriendlyName「AV/C on UPnP Device」は、ルートデバイス６１のフレンドリーネームを表している。
【００８４】
UDN「nuid:upnp-avcupnp-root-0800460000000000」は、ルートデバイス６１の固有の番号を表している。
【００８５】
このUPnP Device Descriptionにおいては、サービスの型であるServiceTypeが「urn:schemas-upnp-org:service:avcService:1」であり、serviceIdが「urn:sony-corp:serviceId:avcService0」であるserviceが規定されている。
【００８６】
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が「urn:sony-corp:serviceId:avcService0」のserviceが記述されている。このSCPDURLの「./scpd/scpd.xml」は、図１５と図１６に示されるUPnP Service DescriptionのURLを表している。
【００９０】
図１５と図１６には、AV/Cコマンドを送るアクションである「avcCommandSend」が記述されている。このactionには、「avcCommand」、「InTrLabel」、「avcResponse」、「outTrLabel」の４つのパラメータが規定されている。これらには、関連する状態変数として、「avcCommand」、「trLabel」、「avcResponse」、「trLabel」がそれぞれ規定されており、それぞれは、「serviceStateTable」に、データの形が「bin.hex」であることが規定されている。
【００９１】
なお、diriectionの「in」は、そのパラメータが、このDescriptionを有する機器から、他の機器に入力されるものであることを表し、「out」は、他の機器から出力され、このDescriptionを有する機器に送信されてくるパラメータであることを表す。
【００９２】
stateVariable sendEvents=noは、その変数の状態が変化したときでもSUBSCRIBEしている機器に対して通知をしないものであることを表す。
【００９３】
以上においては、図３に示されるように、１個のルートデバイス６１に、１個のAV/Cサービス７１を保持させるようにしたが、例えば、図１７に示されるように、root deviceをunitに対応させるとともに、embedded deviceをsubunitに対応させることができる。そして、この例の場合、各deviceが、AV/C serviceを１つだけ有する。
【００９４】
具体的には、図１７の例においては、root device６１が、AV/C service７１−１を有し、root device６１が有するembedded device８１−１と８１−２が、それぞれAV/C service７１−２と７１−３を有する。
【００９５】
図１８と図１９は、図１７のroot device６１が有するUPnP Device Descriptionと、AV/C service７１−１が有するUPnP Device Descriptionの構成例を表している。
【００９６】
図１８の例においては、deviceTypeが「urn:sony-corp:device:unitDevice:1」であるdeviceが設けられ、このdeviceは、serviceIdが「urn:sony-corp:serviceId:avcService0」であるserviceTypeが「urn:sony-corp:service:avcService:1」のserviceを有している。そのSCPDURL「./scpd/root/scpd.xml」には、例えば、図１９のUPnP Service DescriptionのURLが記述される。
【００９７】
また、このdeviceには、さらにdeviceTypeが「urn:sony-corp:device:discDevice:1」であるdevice（embdded device８１−１に対応する）が記述されている。このdeviceは、serviceTypeが「urn:sony-corp:service:avcService:1」のserviceが記述されている。そのSCPDURLの「./scpd/disc0/scpd.xml」は、例えば、AV/C sevice７１−２が有するservice DescriptionのURLを表している。
【００９８】
図１９においては、AV/Cコマンドを送るアクション「avcCommandSend」が記述されている。このアクションは、「avcCommand」と「avcResponce」の２つの引数を有している。これらの引数のデータの形は、serviceStatTableに「bin.hex」として規定されている。
【００９９】
図２０は、デバイスモデルのさらに他の構成例を表す。この例においては、図１７の例と同様に、root deviceがunitに対応され、embedded deviceがsupunitに対応される。ただし、この例においては、図１７の例と異なり、それぞれのdeviceにおいて対応するAV/Cコマンドのopcode毎に、serviceが１つづつ定義される。
【０１００】
具体的には、図２０の例においては、root device６１がpower service９１−１の他、他のopcodeに対応するservice９１−２を有する。
【０１０１】
また、embedded device８１−１は、play service９２−１を有する他、他のAV/Cコマンドのopcodeに対応するservice９２−２を有する。
【０１０２】
さらに、embedded device８１−２も、play service９２−３を有する他、他のopcpdeに対応するservice２２−４を有する。
【０１０３】
各serviceにおいて、Controlは、actionにより実現され、Statusは、Queryにより実現され、Notifyは、GENAにより実現される。General Inquiryは、Device Descriptionにより代用することが可能である。
【０１０４】
図２１と図２２は、図２０の例におけるroot device６１が有するUPnP Device Descriptionの構成を表し、図２３は、図２０のpower service９１−１が保持するUPnP service Descriptionの構成例を表している。
【０１０５】
図２１のdeviceType「urn:sony-corp:device:rootDevice:1」は、図２０のroot device６１に対応し、そのserviceType「urn:sony-corp:service:avcPowerService:1」は、図２０のpower service９１−１に対応する。
【０１０６】
deviceType「urn:sony-corp:device:discDevice:1」は、図２０のembedded device８１−１に対応し、そのserviceType「urn:sony-corp:service:avcPrayService:1」は、play service９２−１に対応し、そのserviceType「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:service:avcPlayService:1」のSCPDURL「./scpd/disc0/play/scpd.xml」は、play service９２−１が援用するService DescriptionのURLが記述される。同様に、serviceTypeが「urn:sony-corp:service:avcStopService:1」のSCPDURL「./scpd/disc0/stop/scpd.xml」は、service９２−３が援用するservice Descriptionが記述される。
【０１０９】
図２３の例においては、AV/Cコマンドを送る「avcCommandSend」のactionが記述されている。これらには、「avcCommand」と「avcResponse」の２つの引数が付加されており、それぞれのデータの形は、serviceStateTableに「bin.hex」として規定されている。
【０１１０】
図２４は、図３、図１７、および図２０のデバイスモデルの特徴の比較結果を表している。なお、図２４において、タイプＡ、タイプＢ、およびタイプＣは、それぞれ図３、図１７、または図２０のデバイスモデルに対応している。
【０１１１】
タイプＡからタイプＣまでを比較すると、SSDPのパケット量が大きく異なっていることがわかる。すなわち、root deviceが１個のとき、SSDPの数は、３＋２ｄ＋ｋとなる。ここで、ｄはembedded deviceの数、kはサービスタイプの数を意味する。従って、subunitの数をＮとするとき、SSDPのパケットの量は、タイプＡのとき４個、タイプＢのとき４＋３Ｎ個、タイプＣのとき３＋２Ｎ＋Ｃ個となる。なお、Ｃは、対応しているopcodeの延べの数を表している。
【０１１２】
特に、タイプＢ（図１７）の場合には、subunit数の数倍になる数のパケットが流れることになる。そこで、ネットワークのトラフィックの観点から考えた場合、SSDPのパケットの量が少ないタイプＡ（図３）の例が望ましい。
【０１１３】
NOTIFYの通知の単位は、タイプＡとタイプＢの場合、全コマンド単位とされ、タイプＣの場合、各コマンド単位とされる。
【０１１４】
以上を総合すると、タイプＡ（図３）の例が最適と考えられる。
【０１１５】
以上においては、UPnPコントロールポイント１から、UPnPデバイス２を制御する場合を例としたが、UPnPデバイス２から、UPnPコントロールポイント１を制御することも可能である。ただし、この場合、UPnPデバイス２が、上述したUPnPコントロールポイントとなり、UPnPコントロールポイントが、UPnPデバイスとなるので、結局は、上述した場合と同様となる。
【０１１６】
上述した一連の処理は、ハードウエアにより実行させることもできるが、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０１１７】
この記録媒体は、図２に示すように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フロッピディスクを含む）、光ディスク４２（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２２や、記憶部２８に含まれるハードディスクなどで構成される。
【０１１８】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１１９】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１２０】
【発明の効果】
以上の如く本発明の情報処理装置および方法、記録媒体、並びにプログラムによれば、SOAPに基づくコマンドに格納されたAV/Cコマンドを抽出し、処理するようにしたので、新たなコマンド体系を構築する必要がなく、簡単かつ確実に、ネットワークに接続されている機器を制御することができる安価なシステムを実現することが可能となる。
【図面の簡単な説明】
【図１】本発明が適用されるネットワークシステムの構成を示す図である。
【図２】図１のUpnPデバイス２の構成を示すブロック図である。
【図３】図１のUPnPデバイス２が有するデバイスモデルの構成を示す図である。
【図４】 AV/Cコマンドフレームの構成を示す図である。
【図５】 ctypeを説明する図である。
【図６】 subunit_typeを説明する図である。
【図７】図１のネットワークシステムの処理を説明するフローチャートである。
【図８】図７のステップＳ１において出力されるコマンドの構成を示す図である。
【図９】図８のコマンドに格納されるAV/Cコマンドの構成を示す図である。
【図１０】図１１のコマンドに格納されるAV/Cレスポンスの構成を示す図である。
【図１１】図７のステップ１２の処理で出力されるレスポンスの例を示す図である。
【図１２】図３のroot deviceが有するUPnP Device Descriptionの構成を示す図である。
【図１３】図３のAV/C serviceが有するUPnP Service Descriptionの構成を示す図である。
【図１４】図３のroot serviceが有するUPnP Device Descriptionの他の構成を示す図である。
【図１５】図３のAV/C serviceが有するUPnP Service Descriptionの他の構成を示す図である。
【図１６】図３のAV/C serviceが有するUPnP Service Descriptionの他の構成を示す図である。
【図１７】デバイスモデルの他の構成を示す図である。
【図１８】図１７のroot deviceが有するUPnP Device Descriptionの構成を示す図である。
【図１９】図１７のAV/C serviceが有するUPnP Service Descriptionの構成を示す図である。
【図２０】デバイスモデルのさらに他の構成を示す図である。
【図２１】図２０のroot deviceが有するUPnP Device Descriptionの構成を示す図である。
【図２２】図２０のroot deviceが有するUPnP Device Descriptionの構成を示す図である。
【図２３】図２０のAV/C serviceが有するUPnP Service Descriptionの構成を示す図である。
【図２４】デバイスモデルの比較を示す図である。
【符号の説明】
１ UPnPコントロールポイント， ２ UPnPデバイス， １１ IEEE８０２ネットワーク， ６１ root device， ７１ AV/C service
Claims (10)
- 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を有し、前記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８０２のSOAPに基づくフォーマットのネットワークに接続され、他の情報処理装置と通信する情報処理装置の情報処理方法において、
前記ネットワークから、IEEE１３９４のAV/Cコマンドが格納された前記SOAPに基づくコマンドを取り込む取り込みステップと、
前記取り込みステップの処理により取り込まれた前記SOAPに基づくコマンドから、格納されている前記AV/Cコマンドを抽出する抽出ステップと、
前記抽出ステップの処理により抽出された前記前記AV/Cコマンドに基づいて、対応する処理を実行する実行ステップと
を含むことを特徴とする情報処理方法。 - IEEE８０２のSOAPに基づくフォーマットのネットワークに接続され、他の情報処理装置と通信する情報処理装置のプログラムであって、
前記ネットワークから、IEEE１３９４のAV/Cコマンドが格納された前記SOAPに基づくコマンドを取り込む取り込みステップと、
前記取り込みステップの処理により取り込まれた前記SOAPに基づくコマンドから、格納されている前記AV/Cコマンドを抽出する抽出ステップと、
前記抽出ステップの処理により抽出された前記前記AV/Cコマンドに基づいて、対応する処理を実行する実行ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - IEEE８０２のSOAPに基づくフォーマットのネットワークに接続され、他の情報処理装置と通信する情報処理装置を制御するコンピュータに、
前記ネットワークから、IEEE１３９４のAV/Cコマンドが格納された前記SOAPに基づくコマンドを取り込む取り込みステップと、
前記取り込みステップの処理により取り込まれた前記SOAPに基づくコマンドから、格納されている前記AV/Cコマンドを抽出する抽出ステップと、
前記抽出ステップの処理により抽出された前記前記AV/Cコマンドに基づいて、対応する処理を実行する実行ステップと
を実行させるプログラム。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001186645A JP3661935B2 (ja) | 2001-06-20 | 2001-06-20 | 情報処理装置および方法、記録媒体、並びにプログラム |
| PCT/JP2002/006177 WO2003001744A1 (en) | 2001-06-20 | 2002-06-20 | Information processing apparatus and method |
| CN02802545A CN1465164A (zh) | 2001-06-20 | 2002-06-20 | 信息处理装置和方法 |
| US10/344,954 US20040030793A1 (en) | 2001-06-20 | 2002-06-20 | Information processing apparatus and method |
| KR10-2003-7002408A KR20030028574A (ko) | 2001-06-20 | 2002-06-20 | 정보 처리 장치 및 방법 |
| EP02741221A EP1398911A1 (en) | 2001-06-20 | 2002-06-20 | Information processing apparatus and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001186645A JP3661935B2 (ja) | 2001-06-20 | 2001-06-20 | 情報処理装置および方法、記録媒体、並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003008583A JP2003008583A (ja) | 2003-01-10 |
| JP3661935B2 true JP3661935B2 (ja) | 2005-06-22 |
Family
ID=19026060
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001186645A Expired - Fee Related JP3661935B2 (ja) | 2001-06-20 | 2001-06-20 | 情報処理装置および方法、記録媒体、並びにプログラム |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20040030793A1 (ja) |
| EP (1) | EP1398911A1 (ja) |
| JP (1) | JP3661935B2 (ja) |
| KR (1) | KR20030028574A (ja) |
| CN (1) | CN1465164A (ja) |
| WO (1) | WO2003001744A1 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6800287B2 (en) | 1998-09-25 | 2004-10-05 | Yeda Research And Development Co., Ltd. | Copolymer 1 related polypeptides for use as molecular weight markers and for therapeutic use |
| KR20040005503A (ko) * | 2002-07-10 | 2004-01-16 | 엘지전자 주식회사 | 홈 네트워크의 유피엔피 기능 분산 시스템 |
| DE602004011517T2 (de) * | 2003-06-30 | 2009-02-05 | Koninklijke Philips Electronics N.V. | Einbetten einer upnp av mediaserverobjektidentifikation in einem uri |
| JP3935459B2 (ja) * | 2003-08-28 | 2007-06-20 | 株式会社東芝 | コンテンツ管理装置、コンテンツ管理システム及びコンテンツ管理プログラム |
| KR100608590B1 (ko) | 2003-09-16 | 2006-08-03 | 삼성전자주식회사 | 서비스 품질에 따른 서비스 지원이 가능한 네트워크 장치,이를 이용한 네트워크 시스템 및 그 방법 |
| WO2005055521A1 (en) * | 2003-12-01 | 2005-06-16 | Samsung Electronics Co., Ltd. | Home network system and method therefor |
| KR101044937B1 (ko) | 2003-12-01 | 2011-06-28 | 삼성전자주식회사 | 홈 네트워크 시스템 및 그 관리 방법 |
| CN1902936B (zh) * | 2004-01-13 | 2011-04-20 | 皇家飞利浦电子股份有限公司 | 用于过滤家庭网络内容的方法和系统 |
| JP4500592B2 (ja) * | 2004-06-11 | 2010-07-14 | キヤノン株式会社 | サービス提供システム及びサービス提供方法 |
| PT2361924E (pt) | 2004-09-09 | 2014-03-13 | Teva Pharma | Processo para a preparação de misturas de acetato de glatirâmero trifluoroacetiílico utilizando ácido bromídrico purificado |
| JP4265658B2 (ja) | 2007-01-25 | 2009-05-20 | セイコーエプソン株式会社 | 処理応答装置、処理要求装置およびそれらの方法 |
| US8584206B2 (en) * | 2007-02-16 | 2013-11-12 | Lg Electronics Inc. | Method for managing domain using multi domain manager and domain system |
| KR101486771B1 (ko) * | 2007-06-22 | 2015-01-29 | 삼성전자주식회사 | 제어 포인트의 연결 상태에 기초하여 ＵＰｎＰ 디바이스의자원을 관리하는 방법 및 장치 |
| JP4725644B2 (ja) * | 2008-12-25 | 2011-07-13 | セイコーエプソン株式会社 | 処理応答装置、処理要求装置およびそれらの方法 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2601525B1 (fr) * | 1986-07-11 | 1988-10-21 | Bull Cp8 | Dispositif de securite interdisant le fonctionnement d'un ensemble electronique apres une premiere coupure de son alimentation electrique |
| CA2010591C (en) * | 1989-10-20 | 1999-01-26 | Phillip M. Adams | Kernels, description tables and device drivers |
| US6633981B1 (en) * | 1999-06-18 | 2003-10-14 | Intel Corporation | Electronic system and method for controlling access through user authentication |
| JP2001148344A (ja) * | 1999-09-09 | 2001-05-29 | Nikon Corp | 露光装置、エネルギ源の出力制御方法、該方法を用いるレーザ装置、及びデバイス製造方法 |
| JP3583667B2 (ja) * | 1999-09-30 | 2004-11-04 | 株式会社東芝 | 無線端末装置並びにデータ転送方法及び制御情報通知方法 |
| 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-06-20 JP JP2001186645A patent/JP3661935B2/ja not_active Expired - Fee Related
-
2002
- 2002-06-20 CN CN02802545A patent/CN1465164A/zh active Pending
- 2002-06-20 WO PCT/JP2002/006177 patent/WO2003001744A1/ja not_active Ceased
- 2002-06-20 US US10/344,954 patent/US20040030793A1/en not_active Abandoned
- 2002-06-20 EP EP02741221A patent/EP1398911A1/en not_active Withdrawn
- 2002-06-20 KR KR10-2003-7002408A patent/KR20030028574A/ko not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| EP1398911A1 (en) | 2004-03-17 |
| US20040030793A1 (en) | 2004-02-12 |
| KR20030028574A (ko) | 2003-04-08 |
| CN1465164A (zh) | 2003-12-31 |
| JP2003008583A (ja) | 2003-01-10 |
| WO2003001744A1 (en) | 2003-01-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3661936B2 (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| US8423671B2 (en) | Middleware device and method of supporting compatibility of devices in home network | |
| JP3661935B2 (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| US7130925B2 (en) | Information processing apparatus and method for receiving/transmitting data between an IEEE802-based format and an IEEE1394-based format | |
| EP1058422A1 (en) | Methods for bridging a HAVi sub-network and a UPnP sub-network and device for implementing said methods | |
| US7958272B2 (en) | Method and apparatus for outputting a user interface (UI) event of 3rd party device in home network | |
| EP2840741B1 (en) | Method and apparatus for using service of home network device based on remote access | |
| US20130031236A1 (en) | Method and System for Platform Level Data Model for Indications Based Event Control and Data Transfer | |
| US20040133896A1 (en) | Network device application interface | |
| KR20050078541A (ko) | 홈네트워크 디바이스 모니터링 및 제어 방법 | |
| JP2003008610A (ja) | 情報処理装置および方法、記録媒体、並びにプログラム | |
| KR20120008401A (ko) | 홈 네트워크에서 멀티캐스트 메시지를 이용하여 복수 개의 원격 사용자 인터페이스 서버들을 제어하기 위한 장치 및 방법 | |
| US9948748B2 (en) | Method of receiving/transmitting event message, controlled device, and control point | |
| EP1693990B1 (en) | Service framework for a home network | |
| CN104079422A (zh) | 管理网络设备的方法 | |
| EP1968245A2 (en) | Apparatus and method for device control | |
| CN101785246B (zh) | 接收/发送事件消息的方法、受控设备和控制点 | |
| KR100952280B1 (ko) | 댁내에 설치되는 주거 게이트웨이의 재부팅을 원격으로제어하는 방법 | |
| JP2004104839A (ja) | 情報処理装置および方法、並びに通信システム | |
| KR100632399B1 (ko) | 고속 직렬 디바이스를 범용 플러그앤플레이 디바이스와연동시키기 위한 브리지 장치 및 그 방법 | |
| JP2005122619A (ja) | クライアント装置 |
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 |