(57)【要約】【課題】サービスを動的に構成して機能拡張し、提供することができる情報処理装置を提供すること。【解決手段】ＵＰｎＰデバイス１は、バス４に接続された拡張装置５〜７から当該拡張装置のサービス記述を取得し、取得された該サービス記述に基づいて自装置のサービス記述を更新し、更新されたサービス記述をネットワーク３上に公開する。ＵＰｎＰデバイス１は、ＵＰｎＰコントロールポイント２からサービス要求を受けると、必要に応じて、該サービス要求に基づく制御要求を該当する拡張装置へ送信し、この拡張装置から制御要求に対する制御応答を受信し、受信した制御応答に基づいてサービス要求に対する応答を生成し、これをＵＰｎＰコントロールポイント２へ送信する。【選択図】      図１
2006202210.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上に第１のサービス記述を公開するとともに該第１のサービス記述が関連付けられた第１のサービスを提供する情報処理装置において、
第２のサービス記述が関連付けられた第２のサービスを提供する拡張装置を接続するための接続手段と、
前記接続手段により接続された前記拡張装置から前記第２のサービス記述を取得する取得手段と、
取得された前記第２のサービス記述に基づいて前記第１のサービス記述を更新する更新手段と、
更新された第１のサービスのサービス記述を前記ネットワーク上に公開する公開手段とを備えたことを特徴とする情報処理装置。
【請求項２】
前記ネットワーク上に公開された第１のサービスのサービス記述に基づくサービス要求を、前記ネットワークを介して受信する手段と、
受信した前記サービス要求が、前記拡張装置に対する制御を必要とするものである場合に、該サービス要求に基づく制御要求を前記拡張装置へ送信する手段と、
前記拡張装置から前記制御要求に対する制御応答を受信する手段と、
前記サービス要求に対する応答であって前記制御応答に基づくものを、前記ネットワークを介して送信する手段とを更に備えたことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記更新手段は、取得された前記第２のサービス記述を前記第１のサービス記述に追加するか、又は取得された前記第２のサービス記述で前記第１のサービス記述の対応する部分を置き換えることによって、前記更新を行うことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記更新手段は、前記第１のサービス記述と、取得された前記第２のサービス記述とに基づいて、新たな第３のサービスのための第３のサービス記述を生成し、該第３のサービス記述により前記第１のサービス記述を更新することを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記更新手段は、生成された前記第３のサービス記述を前記第１のサービス記述に追加するか、又は生成された前記第３のサービス記述で前記第１のサービス記述の対応する部分を置き換えることによって、前記更新を行うことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
取得された前記第２のサービス記述により前記第１のサービス記述を更新するか、前記第１のサービス記述と前記第２のサービス記述とに基づいて第３のサービス記述を生成し、これにより前記第１のサービス記述を更新するかを判断するための手段を更に備えたことを特徴とする請求項３ないし５のいずれか１項に記載の情報処理装置。
【請求項７】
前記接続手段に新たに接続された拡張装置を検出する検出手段を更に備え、
前記取得手段は、前記検出手段により前記接続手段に新たに接続された拡張装置が検出された場合に、当該検出された拡張装置から前記接続手段を介して当該検出された拡張装置に係る前記第２のサービス記述を取得することを特徴とする請求項１に記載の情報処理装置。
【請求項８】
前記検出手段により前記接続手段に新たに接続された拡張装置が検出された場合に、当該検出された拡張装置から前記接続手段を介して当該検出された拡張装置に係る前記第２のサービス記述を取得するための通信プロトコルを示す通信プロトコル情報を取得する手段を更に備え、
前記取得手段は、取得した前記通信プロトコル情報により示される通信プロトコルに従って前記拡張装置から前記前記第２のサービス記述を取得することを特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記公開手段は、更新後の前記第１のサービスのサービス記述を全て前記ネットワーク上に公開することを特徴とする請求項１に記載の情報処理装置。
【請求項１０】
前記公開手段は、前記第１のサービスのサービス記述の更新前後の差分を前記ネットワーク上に公開することを特徴とする請求項１に記載の情報処理装置。
【請求項１１】
ネットワーク上に第１のサービス記述を公開するとともに該第１のサービス記述が関連付けられた第１のサービスを提供する情報処理装置におけるサービス公開方法において、
第２のサービス記述が関連付けられた第２のサービスを提供する拡張装置を接続するための接続ステップと、
前記接続ステップにより接続された前記拡張装置から前記第２のサービス記述を取得する取得ステップと、
取得された前記第２のサービス記述に基づいて前記第１のサービス記述を更新する更新ステップと、
更新された第１のサービスのサービス記述を前記ネットワーク上に公開する公開ステップとを備えたことを特徴とするサービス公開方法。
【請求項１２】
ネットワーク上に第１のサービス記述を公開するとともに該第１のサービス記述が関連付けられた第１のサービスを提供する情報処理装置としてコンピュータを機能させるためのプログラムにおいて、
第２のサービス記述が関連付けられた第２のサービスを提供する拡張装置を接続するための接続ステップと、
前記接続ステップにより接続された前記拡張装置から前記第２のサービス記述を取得する取得ステップと、
取得された前記第２のサービス記述に基づいて前記第１のサービス記述を更新する更新ステップと、
更新された第１のサービスのサービス記述を前記ネットワーク上に公開する公開ステップとをコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上にサービス記述を公開し該サービス記述が関連付けられたサービスを提供する情報処理装置、サービス公開方法及びプログラムに関する。
【背景技術】
【０００２】
近年、家庭向けのデジタルＡＶ機器やエアコンなどの生活家電の一部には、ネットワークインタフェースを搭載し、無線ＬＡＮやイーサネット（登録商標）といった媒体によりネットワーク化された環境にて、ＴＣＰ／ＩＰなどの通信プロトコルを用いて相互に通信を行い、機器制御や連係動作を実現する機器が登場してきている。
【０００３】
こうした家電機器向けの代表的なネットワーク技術としては、ＵＰｎＰ(Universal Plug and Play, United States Patent Application 20020035621)が良く知られている。ＵＰｎＰは、既存のインターネット規格であるＡｕｔｏＩＰ(IPアドレスの自動割当て)、ＳＳＤＰ(Simple Service Discovery Protocol:相手機器の発見)、ＨＴＴＰ(Hyper Text Markup Language:ハイパーテキストの送受信)、ＸＭＬ(機器情報・サービスの記述)、ＳＯＡＰ(Simple Object Access Protocol:機器サービスの呼び出し)、ＧＥＮＡ(Generic Event Notification Architecture:機器状態のイベント通知)といった要素技術を集積して構成される（例えば特許文献１参照）。
【０００４】
ＵＰｎＰでは、ネットワーク上に接続された機器（ＵＰｎＰデバイス）に対して、ＰＣなどのコントローラ機器（ＵＰｎＰコントロールポイント）から、探索や制御、イベント通知処理などの各種操作を行うことができる。
【０００５】
ＵＰｎＰデバイスでは、機器に対して操作可能な機能を列挙したサービスリストを、ＸＭＬ形式のサービス・ディスクリプション・ドキュメントとして保持しており、これを制御する側となるＵＰｎＰコントロールポイントからネットワーク経由で参照できるように、必要な通信メソッドを提供している。実際のＵＰｎＰデバイスへの操作は、ＳＯＡＰ(Simple Object Access Protocol)と呼ぶリモートプロシージャコールを実行する拡張マークアップ言語であるＸＭＬとＨＴＴＰ通信により呼び出すことが出来る点などが特徴となっている。
【０００６】
ネットワーク上の機器の探索や、機器の提供サービスの取得、機器の操作メソッド呼び出し、イベント処理など、家電機器の操作に必要な要件を多く備えたＵＰｎＰフレームワークを採用する企業は、広がりをみせており、対応デバイスの種類や数は今後も増加することが見込まれている。こうした状況の中で、ＩＰ非対応のネットワークやバスにて接続される既存の機器を、ＩＰネットワーク上のＵＰｎＰデバイスとして見せかけるブリッジング技術が提案されている。このブリッジ技術により、本来ＵＰｎＰデバイスとして利用することのできない機器を、ＵＰｎＰネットワーク上に存在する機器として仮想的に存在させ、ＵＰｎＰコントロールポイントから、通常のＵＰｎＰデバイスと同等に扱うことを実現することができる。こうした、あるネットワークから他方のネットワーク上の機器ないしサービスの存在を可視化させる既存の技術は幾つか提案されており、特にＩＥＥＥ１３９４上の機器をＩＥＥＥ１３９４パケットないしＡＶ／ＣコマンドをＳＯＡＰアクションに変換することによって、ＵＰｎＰネットワーク上のコントローラ機器から制御可能にするブリッジには、特許文献２がある。
【０００７】
特許文献２では、ブリッジは、１３９４ＰｒｏｘｙＳｅｒｖｉｃｅと１３９４ＮｏｄｅＳｅｒｖｉｃｅまたは１３９４ＮｏｄｅｓＳｅｒｖｉｃｅを備えたＵＰｎＰデバイスとしてＵＰｎＰコントローラには見えるものとされている。ここで、１３９４ＰｒｏｘｙＳｅｒｖｉｃｅが１３９４ネットワークへの１３９４機器の着脱を監視して、ＩＥＥＥ８０２ネットワーク上のＵＰｎＰ機器への通知および１３９４機器の列挙機能を提供し、１３９４ＮｏｄｅＳｅｒｖｉｃｅは１３９４ネットワーク上の各１３９４機器の操作機能を提供する。１３９４ＮｏｄｅｓＳｅｒｖｉｃｅは、１３９４ネットワーク上の個別の１３９４機器の操作に割り当てられる１３９４ＮｏｄｅＳｅｒｖｉｃｅと異なり、１３９４ネットワーク上の複数の機器の操作を一つのサービスとして提供するものである。
【０００８】
また、ＵＰｎＰ以外の枠組みにて、こうした動的なサービス構成を目的とした研究開発も行われている。たとえば、ＳＴＯＮＥ（例えば非特許文献１参照）や、モバイルＡｇｅｎｔを用いた試みがある。これらの試みでは、各機能の依存関係をグラフとして表現し、各機能を提供する機器を検索し、動的に結合することを行っている。
【０００９】
しかしながら、STONEやモバイルAgentの実現には、機器間の連携用に仮想的なネットワークを新たに構築するために独自のプロトコルを導入している。すなわち、既存のプロトコルや機器を置き換えるアプローチを採用しており、現時点でＵＰｎＰ機器に適用可能とするには問題がある。
【特許文献１】米国特許出願公開第２００２／００３５６２１
【特許文献２】特開２００３−８６１０公報
【非特許文献１】「STONE: 環境適応型ネットワークサービスアーキテクチャ, 電子情報通信学会技術研究報告, IN2001-12, May 2001」
【発明の開示】
【発明が解決しようとする課題】
【００１０】
従来、ＵＰｎＰデバイスは、デバイス固有に提供可能なサービスリストを事前に保有しておき、ＵＰｎＰコントロールポイントからの要求に基づきこれを公開する形で実現されていることが多い。現在のUPｎPの仕様では、ＵＰｎＰデバイスの提供するサービスが動作中に動的に変化するケースについては想定されておらず、変更時にＵＰｎＰコントロールポイントに対してどのように提供サービスが変わったかを通知する手段なども提供されていない。この機能を実現するために、ＵＰｎＰデバイスにサービス情報が変化した際に動的に広告する手段を新たに追加したり、ＵＰｎＰコントロールポイントに定期的にＵＰｎＰデバイスのサービスディスクリプションドキュメントを再読み込みさせることで、ＵＰｎＰコントロールポイントが制御対象となるＵＰｎＰデバイスにおいて動的に変更されたサービス情報の差分について把握することでこれを実現する方式も考えられるが、そもそも、ＵＰｎＰデバイスに対して、バス経由で新たに拡張装置を追加するなどしてハードウェア構成を変更した場合に、その拡張装置に備わる制御機能に関するサービス情報をどのようにしてＵＰｎＰデバイスに取り込むかといった問題が存在する。また、拡張装置から取り込んだサービス情報を、ＵＰｎＰデバイスがどのように自身が保持するサービス情報に取り込み、これと共存させることができるかを解決する必要がある。
【００１１】
本発明は、上記事情を考慮してなされたもので、サービスを動的に構成して機能拡張し、提供することができる情報処理装置、サービス公開方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、ネットワーク上に第１のサービス記述を公開するとともに該第１のサービス記述が関連付けられた第１のサービスを提供する情報処理装置において、第２のサービス記述が関連付けられた第２のサービスを提供する拡張装置を接続するための接続手段と、前記接続手段により接続された前記拡張装置から前記第２のサービス記述を取得する取得手段と、取得された前記第２のサービス記述に基づいて前記第１のサービス記述を更新する更新手段と、更新された第１のサービスのサービス記述を前記ネットワーク上に公開する公開手段とを備えたことを特徴とする。
【００１３】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。  
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読み取り可能な記録媒体としても成立する。
【発明の効果】
【００１４】
本発明によれば、サービスを動的に構成して機能拡張し、提供することができる
【発明を実施するための最良の形態】
【００１５】
以下、図面を参照しながら本発明の実施形態について説明する。
【００１６】
図１に、本発明の一実施形態に係る情報処理装置を含むネットワークシステムの構成例を示す。
【００１７】
図１において、１はＵＰｎＰデバイスとして動作する機能を有する情報処理装置（以下、ＵＰｎＰデバイス１とも表す）、２はＵＰｎＰデバイス１の制御装置であるＵＰｎＰコントロールポイント、３は例えばイーサネット（登録商標）や無線ＬＡＮなどを利用したＩＰネットワークをそれぞれ示している。また、４は例えばＰＣＩバスなどの拡張バスを示しており、５〜７は拡張バス４によりＵＰｎＰデバイス１に接続される拡張装置をそれぞれ示している。
【００１８】
図１に示されるように、ＵＰｎＰデバイス１と、ＵＰｎＰコントロールポイント２とは、ＩＰネットワーク３上にて接続される。なお、図１では、ＩＰネットワーク３上に、１台のＵＰｎＰデバイスが示されているが、ＵＰｎＰデバイスが複数台存在しても構わない。ＵＰｎＰコントロールポイント２についても同様である。また、本実施形態に係るＵＰｎＰデバイス１と、既存のＵＰｎＰデバイスとが混在しても構わない。
【００１９】
本実施形態に係るＵＰｎＰデバイス１は、拡張バス４を介して接続される拡張装置によって機能の拡張が可能な装置である。
【００２０】
拡張装置の接続による機能の拡張には、例えば、カメラを備えないＵＰｎＰデバイス１に、拡張装置としてカメラを接続するような拡張（新設）や、カメラを備えるＵＰｎＰデバイス１に、拡張装置として、カメラ（例えば、同種同性能のカメラ、同種のより高性能なカメラあるいは異なる種類のカメラなど）を接続し、元々備えるカメラと併用するような拡張（増設）又は元々備えるカメラに替えて使用するような拡張（交換）など、種々の形態がある。
【００２１】
また、本実施形態に係るＵＰｎＰデバイス１は、拡張装置から、そのサービス記述を取得し、拡張装置のサービス記述の自装置のサービス記述への反映を行う。この反映のさせ方にも、種々の形態がある。例えば、拡張装置のサービス記述を、自装置のサービス記述に追加する形態、拡張装置のサービス記述で、自装置のサービス記述の該当する部分を置き換える形態や、さらには、拡張装置のサービス記述と自装置のサービス記述に基づいて、新たなサービスのためのサービス記述を生成し、生成された新たなサービス記述を、自装置のサービス記述に追加する形態、生成された新たなサービス記述で、自装置のサービス記述の該当する部分を置き換える形態など、種々の形態が可能である。
【００２２】
ＵＰｎＰデバイス１は、例えば、パーソナルコンピュータ装置などを利用して構成することもできるし、特定の機能を持った専用の装置（例えば、家庭内やオフィス内で使用される種々の電気機器や事務機器、ロボット装置等）として構成することもできる。あるＵＰｎＰデバイス１に接続可能な拡張装置の上限数は任意に決めて構わない。図１は、ＵＰｎＰデバイス１に３台の拡張装置５〜７が接続されている様子を例示したものである。
【００２３】
なお、本実施形態に係るＵＰｎＰデバイス１の機能をプログラムで実現する場合には、当該プログラムがＵＰｎＰデバイス１の図示しないプログラム記憶装置に格納される。プログラム記憶装置は、例えば、磁気ディスク装置や光ディスク装置等からなる。上記プログラムがＣＰＵからの制御でランダムアクセスメモリ（ＲＡＭ）に読み込まれ、同ＣＰＵにより実行されることにより、コンピュータを本実施形態に係るUPnPデバイス１として機能させることができる。
【００２４】
ＵＰｎＰコントロールポイント２は、ＵＰｎＰデバイス（本実施形態に係るＵＰｎＰデバイス１や既存のＵＰｎＰデバイス）の制御を行う機能を有する機器に相当する。なお、ＵＰｎＰコントロールポイント２は、基本的には、あるＵＰｎＰデバイスが、本実施形態に係るＵＰｎＰデバイス１であるか、既存のＵＰｎＰデバイスであるかについて認識しなくて構わない。ＵＰｎＰコントロールポイント２は、例えば、パーソナルコンピュータ装置などを利用して構成することもできるし、専用の制御装置（例えば、ＴＶ等のネットワーク家電や、リモコン装置等）として構成することもできる。ＵＰｎＰコントロールポイント２は、既存のもので構わない。ＵＰｎＰコントロールポイント２は、例えば、制御などの演算処理を行うための中央処理ユニット（ＣＰＵ）と、表示のための処理ブロックと、操作入力のための処理ブロックと、処理内容の記憶ブロックと、他機器との通信処理ブロックとが、内部バスで結合される構成を有する。
【００２５】
次に、図２を参照しながら、ＵＰｎＰデバイス１（又は既存のＵＰｎＰデバイス）とＵＰｎＰコントロールポイント２との間の動作を概略的に説明する。
【００２６】
図２に示すように、ＵＰｎＰデバイス１は、ＳＳＤＰ(Simple Service Discovery Protocol)（図中、１０１参照）に従ってＵＰｎＰコントロールポイント２に向けて自デバイス（自機器）の存在を広告し、ＸＭＬ形式で記述されたデバイス記述・サービス記述（１１）を公開する。ＵＰｎＰコントロールポイント２は、ＵＰｎＰデバイス１およびサービス（図２の例では、第１のサービス１２１と第２のサービス１２２）をＳＳＤＰ（図中、１０１参照）に従って発見し、各サービスのアクションをＳＯＡＰに基づく呼び出し（図中、１０２参照）により制御する。ＵＰｎＰサービスの状態変化は、ＧＥＮＡに基づくイベント通知（図中、１０３参照）を購読するＵＰｎＰコントロールポイント２に対して通知される。
【００２７】
このような基本的な動作は、既存のＵＰｎＰデバイスとＵＰｎＰコントロールポイント２との間についても同様である。
【００２８】
図３に、既存のＵＰｎＰデバイス８の構成例を示す。該既存のＵＰｎＰデバイスが公開する機能の一覧は、デバイス記述・サービス記述８１として静的に用意されており、ＳＳＤＰ処理部８２を通じて、ＵＰｎＰデバイスタイプ、デバイスＩＤ、およびサービスタイプ等が広告される。広告された情報に基づいて、ＵＰｎＰコントロールポイント２は、必要なサービスまたはデバイスを選択し、ＨＴＴＰによって、デバイス記述・サービス記述８１の取得要求を行う。記述取得処理部８３は、この取得要求に応じ、ＸＭＬ形式で記述されたデバイス記述・サービス記述８１をＵＰｎＰコントロールポイント２に送信する。
【００２９】
各サービスの機能は、各ＵＰｎＰサービスのアクションとして、ＳＯＡＰを介して利用可能である。ＵＰｎＰコントロールポイント２からのアクション要求は、ＳＯＡＰ処理部８４からＳＯＡＰハンドラ８５を通じて、各アクションのハンドラ８６，８７に渡される。これらアクションハンドラ８６，８７は、ＵＰｎＰ状態変数を参照しながら、実際の処理を行い、処理結果に応じてレスポンスを返すとともに、ＵＰｎＰ状態変数を更新する。ＵＰｎＰ状態変数を管理する状態変数管理部８８は、更新された状態変数がイベント通知の対象であれば、購読元のＵＰｎＰコントロールポイント２に対して、ＧＥＮＡ処理部８９を通じて、イベント通知を行う。
【００３０】
図４に、本実施形態の情報処理装置１（ＵＰｎＰデバイス１）の構成例を示す。
【００３１】
図４に示されるように、本ＵＰｎＰデバイス１は、デバイス記述・サービス記述１１、ＳＳＤＰ処理部１２、記述取得処理部１３、ＳＯＡＰ処理部１４、ＳＯＡＰハンドラ１５、ハンドラ１６，１７、状態変数管理部１８、ＧＥＮＡ処理部１９、拡張装置用デバイス記述サービス記述取得処理部（以下、記述取得処理部）２０と記述マージ形式判定処理部（以下、判定処理部）２１を備えている。なお、図４では、アクションハンドラは、２つ示しているが、２以外の個数でも構わない（図３も同様である）。
【００３２】
図４のデバイス記述・サービス記述１１からＧＥＮＡ処理部１９までは、図３の既存のＵＰｎＰデバイス８の構成例におけるデバイス記述・サービス記述８１からＧＥＮＡ処理部８９までと基本的には同様のものである。すなわち、図４のＵＰｎＰデバイス１は、図３の構成に、記述取得処理部２０と判定処理部２１を付加したものである。
【００３３】
記述取得処理部２０は、バス接続４される拡張装置（図１の例では、拡張装置５，６または７）から、当該拡張装置が保持するデバイス記述・サービス記述をバス４経由で取得する処理を行うものである。このデバイス記述・サービス記述の取得は、バス４上で規定された通信メソッドを利用して行うことができる。
【００３４】
判定処理部２１は、記述取得処理部２０によりバス４経由で当該拡張装置から取得したデバイス記述・サービス記述に基づいて、自装置内に保持するデバイス記述・サービス記述１１に対してどのように反映させればよいか（例えば、取得したデバイス記述・サービス記述を、デバイス記述・サービス記述１１に対して、どのように追記すればよいか、あるいは、サービスの組み合わせにより新しいサービス記述が生成できるかどうかなど）を判定し、必要に応じてデバイス記述・サービス記述１１を更新する。これに伴い、記述マージ形式判定処理部２１は、必要に応じて、当該拡張装置のデバイス記述・サービス記述に対応する（バス４を介して当該拡張装置を制御するための）アクションハンドラをセットする（あるいは、対応するアクションハンドラが既に存在し且つ非アクティブの状態である場合には、これをアクティブにする）。
【００３５】
なお、デバイス記述・サービス記述１１が更新されると、更新されたデバイス記述・サービス記述１１は、周囲のＵＰｎＰコントロールポイント２に対して広告される。
【００３６】
以下、本実施形態について具体例を用いながら詳しく説明する。
【００３７】
ここでは、図５に示されるように、ＵＰｎＰデバイス１本体を、車輪などを具備した移動式ロボットとし、拡張バス４にＩＥＥＥ１３９４を使用し、拡張装置９としてデジタルカメラを用いた場合を具体例として説明する。
【００３８】
図６（ａ）に、本具体例で用いるＩＥＥＥ１３９４のコンフィグレーションＲＯＭ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ＲＯＭ）内に保持されるデータのフォーマットを示し、同図（ｂ）に、コンフィグレーションＲＯＭ内に保持される「ｕｎｉｔ＿ｄｉｒｅｃｔｏｒｙ」情報の内容の詳細を示す。図６に示されるように、「ｕｎｉｔ＿ｄｉｒｅｃｔｏｒｙ」情報内の「Ｕｎｉｔ＿Ｓｐｅｃ＿ＩＤ」情報や「Ｕｎｉｔ＿Ｓｗ＿Ｖｅｒｓｉｏｎ」情報から、バス４上の通信プロトコルを特定することができる。例えば、１３９４ベースのデジタルカメラ仕様に従った機器の場合、「Ｕｎｉｔ＿Ｓｐｅｃ＿ＩＤ」情報には“０ｘ００Ａ０２Ｄ”という値が規定されている。
【００３９】
図７に、ＩＥＥＥ１３９４バス４によりＵＰｎＰデバイス１に拡張装置９が接続されてから、実際に該ＵＰｎＰデバイス１内にデバイス記述・サービス記述（デバイス／サービス・ディスクリプション・ドキュメント）を生成し、ネットワーク３上へ公開し、ＵＰｎＰコントロールポイント２からの操作を処理するまでのシーケンスの一例を示す。
【００４０】
なお、ここでは、拡張装置９の接続のみが行われたものとして拡張装置９のみに着目して説明する。
【００４１】
図７のシーケンスにおいては、まず、拡張装置であるデジタルカメラ９を、ＵＰｎＰデバイス１の移動式ロボットに対して、ＩＥＥＥ１３９４バス４経由で接続する。この時点で発生するバス・リセット（ｂｕｓ  ｒｅｓｅｔ）を契機として、ツリー・アイデンティファイ（ｔｒｅｅ−ｉｄｅｎｔｉｆｙ）やセルフ・アイデンティファイ（ｓｅｌｆ−ｉｄｅｎｔｉｆｙ）を行い、トポロジー構成の初期化を行い、サイクルマスタやバスマネージャなどの決定を行う（ステップＳ１）。
【００４２】
続いて、ＵＰｎＰデバイス１は、新たに接続された拡張装置９のｕｎｉｔ＿ｄｉｒｅｃｔｏｒｙ情報（図６参照）を読み込み（ステップＳ２）、これを参照して、対象となる拡張装置９への通信プロトコルを調査する。
【００４３】
次に、ＵＰｎＰデバイス１は、記述取得処理部２０により、拡張装置９のデバイス記述・サービス記述９１を、調査した通信プロトコルに従い（例えば、ＲＥＡＤトランザクションにて）読み込む（ステップＳ３）。
【００４４】
図８に、拡張装置９のデバイス記述・サービス記述９１の形式の一例を示す。ここでは、このデバイス記述・サービス記述９１は、ＩＥＥＥ１３９４バス上のメモリにマップされているものとする。
【００４５】
デバイス記述に関しては、図８（ａ）に示すように、デバイス・ディスクリプション・ドキュメント本体のサイズ（ｄｅｖ＿ｄｅｓｃ＿ｌｅｎｇｔｈ）と、サービス・ディスクリプション・ドキュメントが配置されるメモリ位置へのオフセット値（ｓｒｖ＿ｄｅｓｃ＿ｏｆｆｓｅｔ）、および、デバイス・ディスクリプション・ドキュメント本体（ｄｅｖｉｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｄｏｃｕｍｅｎｔ）が格納される構造を想定する。また、サービス記述に関しては、図８（ｂ）に示すように、サービス・ディスクリプション・ドキュメント本体のサイズ（ｓｒｖ＿ｄｅｓｃ＿ｌｅｎｇｔｈ）と、サービス記述が更に存在する場合における、次のサービス・ディスクリプション・ドキュメントが配置されるメモリ位置へのオフセット値（ｓｒｖ＿ｄｅｓｃ＿ｏｆｆｓｅｔ）、および、サービス・ディスクリプション・ドキュメント本体（ｓｒｅｖｉｃｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｄｏｃｕｍｅｎｔ）が格納される構造を想定する。
【００４６】
この記述の読み込みは、サービス記述のｓｒｖ＿ｄｅｓｃ＿ｏｆｆｓｅｔ値がｎｕｌｌになるまで、行われる。
【００４７】
なお、デバイス記述用の構造に関して、ＩＥＥＥ１３９４上に配置されるメモリ位置は常に固定しておく必要があり、ＵＰｎＰデバイスが最初のデバイス記述を読み込む際に利用することになる。
【００４８】
上記では、拡張装置９のデバイス記述・サービス記述９１は、拡張装置であるデジタルカメラ９側のＩＥＥＥ１３９４メモリ上にマップすることで取得可能としたが、他の方法によることも可能である。例えば、ＵＰｎＰデバイス１側にて拡張装置９から取得したｕｎｉｔ＿ｄｉｒｅｃｔｏｒｙ情報に基づき、同一ネットワークもしくはインターネット等のネットワーク上に配置される「ｕｎｉｔ＿ｄｉｒｅｃｔｏｒｙ情報をキーとするデバイス記述・サービス記述の蓄積サーバ」を用意し、ＵＰｎＰデバイス１からこのサーバへ問い合わせを行うことで、所望するデバイス記述・サービス記述を取得するように構成することも可能である。
【００４９】
続いて、拡張装置９のデバイス記述・サービス記述の取得が完了すると、ＵＰｎＰデバイス１は、判定処理部２１において、記述取得処理部２０により取得した記述を、自装置が保持するサービス記述と、どのようにして、追加、あるいは、組み合わせて、新規サービスを生成するかについて判定する（ステップＳ４）。
【００５０】
この判定には種々の方法が可能であるが、ここでは、一例として、ＵＰｎＰデバイス１が、予め用意しておいたヒント情報を利用する方法について説明する。
【００５１】
図９に、このヒント情報の構成例を示す。
【００５２】
図９に例示したヒント情報は、ｕｎｉｔ＿ｄｉｒｅｃｔｏｒｙ情報によって取得できる機器のタイプに従って（図９の例では、Ｕｎｉｔ＿Ｓｐｅｃ＿ＩＤ毎、Ｕｎｉｔ＿Ｓｗ＿Ｖｅｒｓｉｏｎ毎に）、どのようなサービス記述の更新を行うべきかを記載したテーブル形式となっている。
【００５３】
「ｄｅｆａｕｌｔ＿ｏｐ」情報は、拡張装置のサービス記述を、ＵＰｎＰデバイスに対して基本的にどのように追加するのかについて示すものである。本具体例では、“ｍｅｒｇｅ”、“ｒｅｐｌａｃｅ”、“ｎｏｎｅ”から選択することができる。“ｍｅｒｇｅ”であれば、ＵＰｎＰデバイス１のサービス記述への単純追加、“ｒｅｐｌａｃｅ”であれば、ＵＰｎＰデバイス１のサービス記述を、当該拡張装置が接続されている間、一時的に無効化し、当該拡張装置のサービス記述に置き換える。“ｎｏｎｅ”であれば、拡張装置のサービス記述は、ＵＰｎＰデバイス１のサービス記述に影響を与えない。なお、“ｍｅｒｇｅ”、“ｒｅｐｌａｃｅ”、“ｎｏｎｅ”の値は実際には、整数値に置き換えられてもよい。
【００５４】
「ｃｏｎｆｌｉｃｔ＿ｕｎｉｔｓ」情報は、「Ｕｎｉｔ＿Ｓｐｅｃ＿ＩＤ＿Ａ」情報で指定された拡張装置以外の拡張装置が接続された場合に、競合を発生する可能性のあるものの個数ｎと、そのＵｎｉｔ＿Ｓｐｅｃ＿ＩＤのリストを保持する。ｃｏｎｆｌｉｃｔ＿ｕｎｉｔｓに記載された拡張装置が既にＵＰｎＰデバイスに接続されている場合は、該拡張装置のサービス記述は、ＵＰｎＰデバイスのサービス記述に影響を与えない。
【００５５】
「ｃｏｌｌａｂｏ＿ｕｎｉｔｓ」情報は、「Ｕｎｉｔ＿Ｓｐｅｃ＿ＩＤ＿Ａ」で識別される拡張装置が、ＵＰｎＰデバイス１を含む他の拡張装置との間で、連携サービスの提供が可能なものの個数ｍを保持している。これ以降、連携可能対象となる他の拡張装置の「Ｕｎｉｔ＿Ｓｐｅｃ＿ＩＤ」と、対応するサービス記述文章の名前（もしくはＵＲＩ(Uniform Resource Identifier)）の組がｍ個連なる。
【００５６】
なお、図９の例では、Ｕｎｉｔ＿Ｓｗ＿ＶｅｒｓｉｏｎにかかわらずにＵｎｉｔ＿Ｓｐｅｃ＿ＩＤで指定する方法を採ったが、Ｕｎｉｔ＿Ｓｐｅｃ＿ＩＤ＿ＡとＵｎｉｔ＿Ｓｗ＿Ｖｅｒｓｉｏｎの両方で指定する方法も可能である。
【００５７】
なお、図９のヒント情報は一例であり、他にも種々の構成が可能である。
【００５８】
また、ヒント情報を利用する方法以外にも、判定処理部２１における判定には種々の方法が可能である。
【００５９】
さて、図７のシーケンスにおいて、判定処理部２１は、拡張装置ごとに用意されたこのヒント情報テーブルをもとに、ＵＰｎＰデバイス１として外部に公開するサービス記述の更新を行う（ステップＳ５）。
【００６０】
更新されたデバイス記述・サービス記述１１は、ＵＰｎＰコントロールポイント２に対して広告される（ステップＳ６）。
【００６１】
ここでは、更新後のデバイス記述・サービス記述１１を全て公開する（更新後のデバイス記述・サービス記述１１を持つＵＰｎＰデバイスとして新たに公開する）ものとする。なお、デバイス記述・サービス記述１１の更新前後の差分のみ公開する方法も可能である。
【００６２】
ＵＰｎＰコントロールポイント２は、ＵＰｎＰデバイス１からデバイス記述・サービス記述を取得する（ステップＳ７）。
【００６３】
この後、ＵＰｎＰコントロールポイント２は、必要に応じて、制御命令をＵＰｎＰデバイス１に対して送信する（ステップＳ８）。
【００６４】
ＵＰｎＰデバイス１は、この制御命令要求（ＳＯＡＰアクション）を受けると（ステップＳ８）、これが拡張装置に対する操作であるかどうか判断する（ステップＳ９）。ここでは、拡張装置に対する操作であるとする。
【００６５】
拡張装置に対する操作である場合、ＵＰｎＰデバイス１は、必要に応じて、該当する拡張装置への制御要求を作成して、これを送信することで（ステップＳ１０）、実際の制御を行う。
【００６６】
例えば、接続される機器がＩＥＥＥ１３９４ベースのデジタルカメラ仕様であれば、当該仕様書により制御コマンドのセットは予め入手することが可能であるため、ＵＰｎＰデバイス側で事前に制御コマンドのセットを含むバス通信メソッドは、ライブラリ化するなどして準備されており、これを利用した制御要求送信が行われるようにしてもよい。
【００６７】
なお、拡張装置に対する操作でない場合、ＵＰｎＰデバイス１は、自装置内において必要な制御を行う。
【００６８】
ＵＰｎＰデバイス１から制御要求を受信し、必要な処理を行った拡張装置９は、制御応答を作成して、これをUPｎPデバイス１へ返す。
【００６９】
ＵＰｎＰデバイス１は、拡張装置９からの制御応答を受信すると（ステップＳ１１）、これをＳＯＡＰレスポンスの形に変換し（ステップＳ１２）、ＵＰｎＰコントロールポイント２へ返信することで（ステップＳ１３）、制御した結果について回答を行い、一連の処理を完了する。
【００７０】
以上説明したように、本実施形態によれば、拡張装置をＵＰｎＰデバイスに接続した際に、拡張装置の保持するサービス記述をＵＰｎＰデバイスのサービス記述に加えるのみならず、例えばヒント情報テーブルによるなどして、新たなサービスを動的に構成し、ネットワーク上に公開することが可能になる。
【００７１】
ここで、従来のＵＰｎＰ仕様では、ＵＰｎＰデバイスが動作中に公開するサービスが動的に変化することを想定しておらず、公開された新たなサービスをその公開時に通知する枠組みが提供されていない。この場合、次に示すようにＵＰｎＰデバイスとしての動作をいったん終了し、再開する方法を採ることが前提となっている。  
（１）ＵＰｎＰデバイスとしての動作を停止する。公開するデバイスＩＤ，デバイスタイプ，サービスタイプ，サービスＩＤの各々についてｓｓｄｐ：ｂｙｅｂｙｅを周囲にマルチキャストし、サービスの停止を通知する。  
（２）公開するサービスに関するデバイス記述およびサービス記述を変更する。  
（３）ＵＰｎＰデバイスとしての動作を再開する。ここで、公開するデバイスＩＤ，デバイスタイプ，サービスタイプ，サービスＩＤの各々についてｓｓｄｐ：ａｌｉｖｅを周囲にマルチキャストし、新たなサービスが稼働中であることを通知する。
【００７２】
本実施形態に係るＵＰｎＰデバイス１では、例えば次の手順を採ることができる。  
（１）公開する内容に変更が生じたサービスのサービス記述を変更する。  
（２）上記サービスのｓｓｄｐ：ａｌｉｖｅを周囲にマルチキャストする。ここで、ＣＡＣＨＥ−ＣＯＮＴＲＯＬヘッダの値をｍａｘ−ａｇｅ＝０とする。
【００７３】
マルチキャストに応答するＵＰｎＰコントロールポイント２においては、通常、ＣＡＣＨＥ−ＣＯＮＴＲＯＬ：  ｍａｘ−ａｇｅ＝６００など非０な値のヘッダが付与されたｓｓｄｐ：ａｌｉｖｅパケットを受け取ると、所定の時間（この場合は６００秒）は、ｓｓｄｐ：ａｌｉｖｅが広告する内容をキャッシュする。キャッシュ期限が到来する前に、次のｓｓｄｐ：ａｌｉｖｅパケットが広告されるか、ＵＰｎＰコントロールポイント２側からｓｓｄｐ：ｄｉｓｃｏｖｅｒパケットによる探索を行う必要がある。本実施形態に従う場合、ｓｓｄｐ：ａｌｉｖｅ  ＣＡＣＨＥ−ＣＯＮＴＲＯＬ：  ｍａｘ−ａｇｅ＝０を受け取ると、該サービスに対して有する内部キャッシュがクリアされる。このため、該サービスのサービス記述を再取得する必要に迫られ、取得したサービス記述のタイムスタンプである、ＨＴＴＰ−ＧＥＴのレスポンスに含まれるＬａｓｔ−Ｍｏｄｉｆｉｅｄヘッダが示す時刻が、従来得たものと異なるから、サービス記述が従来から変化したと判断できる。
【００７４】
この方法では、ＣＡＨＣＨＥ−ＣＯＮＴＲＯＬに基づくＵＰｎＰコントロールポイント２の挙動を協調的なものであると仮定している。よりＵＰｎＰ仕様に忠実なＵＰｎＰコントロールポイントの収容を考慮すると、次の手順を実行して、変更が生じたサービスのみの一時停止と変更、再開を行うことが好ましい。  
（１）公開する内容に変更が生じたサービスのｓｓｄｐ：ｂｙｅｂｙｅ（停止）を周囲にマルチキャストする。  
（２）上記サービスのサービス記述を変更する。  
（３）上記サービスのｓｓｄｐ：ａｌｉｖｅ（開始）を周囲にマルチキャストする。
【００７５】
先ほどの方法と比較してパケット数は増えるものの、より確実にサービス変更を広告できることが期待される。このとき、ＵＰｎＰコントロールポイント２は、利用中のサービスがいったん終了したので、呼び出し中の手続きは失敗し、イベント通知の購読は解除されたものと判断できる。その後、サービスが再開したのでサービス記述を再取得することが要求され、取得したサービス記述のタイムスタンプである、ＨＴＴＰ−ＧＥＴのレスポンスに含まれるＬａｓｔ−Ｍｏｄｉｆｉｅｄヘッダが示す時刻が、従来得たものと異なることから、サービス記述が従来から変化したと判断できる。
【００７６】
この方法の場合、従来のようにＵＰｎＰデバイスとして全サービスを終了する場合と比べて、影響がないサービスをそのまま継続できる。これは、単純にサービスの通知用マルチキャストパケットの個数のみならず、イベント通知の再購読手続きの実行に必要なパケットをも減らすことができる。
【００７７】
なお、サービスの増減がある場合には、デバイス記述を変更する必要があるので、上記と同様の手順でデバイスの更新通知を行う。ただし、後者の方法を採る場合、従来と同様にデバイスと全サービスを一時停止し、再開することになる。これは、従来方法から拡張したことによる、従来方法との互換性に基づくものである。
【００７８】
本実施形態に従いＵＰｎＰデバイスのサービスが機能拡張された場合、デバイス記述およびサービス記述を更新する必要があるが、拡張に必要な拡張バス上の拡張装置またはそのサービスが停止した場合、再度、デバイス記述およびサービス記述を更新し、広告する必要がある。
【００７９】
ここで、拡張装置の接続と離脱が頻繁であって、それに伴ってＵＰｎＰデバイス記述とサービス記述の更新と広告が頻繁になる場合を考慮すると、ＵＰｎＰデバイス記述とサービス記述の更新への対応をＵＰｎＰコントロールポイントが常に行う必要がある。これは、ＵＰｎＰコントロールポイントに高い負荷をかけてしまうし、デバイス記述・サービス記述の変化に応じてアクション呼び出しの内容を調整する必要も生じてしまうことから、ＵＰｎＰコントロールポイントによるＵＰｎＰデバイス記述とサービス記述の更新の頻度、ならびに広告の頻度は、できるだけ抑えることが好ましい。
【００８０】
例えば、次のような手順を採ることができる。  
（手順１）拡張装置の離脱が検出される。  
（手順２）離脱の検出から一定時間が経過するまで、ＵＰｎＰデバイス・サービスの更新と広告を保留する。この間に、当該拡張装置へ制御要求を出すべき制御命令要求（ＳＯＡＰアクション）を受けた場合には、この制御命令要求はエラーとなる。
【００８１】
（手順３）離脱の検出から一定時間が経過した場合には、ＵＰｎＰデバイス・サービスの更新と広告を行う。一定時間が経過する前に、当該拡張装置が再接続すれば、ＵＰｎＰデバイス・サービスの更新と広告は不要になる。
【００８２】
上記では、離脱の検出から一定時間が経過するまでの保留を行ったが、離脱が検出された後、当該拡張装置へ制御要求を出すべき制御命令要求がエラーになってから、一定時間が経過するまでの保留を行う方法なども可能である。
【００８３】
なお、ＵＰｎＰデバイス１がいったん動作停止している間に拡張装置が離脱し、その後、当該拡張装置が再接続する前に当該ＵＰｎＰデバイス１が動作再開する場合も、上記と同様の手順を採ることができる。
【００８４】
以上説明してきたように、本実施形態によれば、ネットワークに接続可能なある単体機器に対して、バス接続され得る拡張装置の着脱によって、単体機器自体のサービス機能の増減を動的に実現することができる。さらに、１個以上の拡張装置との組み合わせによって、各々の機器が提供するサービス同士を連携させることにより、新たなサービスあるいは複数のサービスを組み合わせたより高度なサービスの導出を可能にすることができる。すなわち、拡張装置をバス経由で接続した際に、当該単体機器自身が有するサービス情報を自動的に拡張し、拡張装置を利用可能にする新たな制御能力を加えたサービス情報を生成し、これをネットワーク側へ公開し、ネットワーク接続されたコントローラ機器から制御できるようにすることができる。
【００８５】
例えば、ＵＰｎＰネットワークに無線通信手段などにより接続された移動ロボットに適用した場合、モニタカメラを追加しただけで、移動ロボットが巡視ロボットとして外部コントローラから利用可能となる他、単腕つきロボットに適用した場合、さらに一本の腕を追加しただけで、新たに両腕で抱える操作を具備するロボットとして利用することが出来るようになり、より高度なサービスを提供することが可能となる。
【００８６】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。  
また、本実施形態は、コンピュータに所定の手順を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【００８７】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００８８】
【図１】本発明の一実施形態に係るＵＰｎＰネットワークの構成例を示す図
【図２】ＵＰｎＰデバイスとＵＰｎＰコントロールポイントとの間の動作を概略的に説明するための図
【図３】既存のＵＰｎＰデバイスの構成例を示す図
【図４】同実施形態に係る情報処理装置の構成例を示す図
【図５】同実施形態に係る情報処理装置の具体例について説明するための図
【図６】コンフィグレーションＲＯＭ及びｕｎｉｔ＿ｄｉｒｅｃｔｏｒｙ情報について説明するための図
【図７】同実施形態に係る情報処理装置とＵＰｎＰコントロールポイントと拡張装置との動作シーケンスの一例を示す図
【図８】同実施形態における拡張装置が保持するデバイス記述及びサービス記述の構成例を示す図
【図９】同実施形態におけるヒント情報テーブルの一例を示す図
【符号の説明】
【００８９】
１…ＵＰｎＰデバイス、２…ＵＰｎＰコントロールポイント、３…ＩＰネットワーク４…バス、５〜７…拡張装置、１１…デバイス記述・サービス記述、１２…ＳＳＤＰ処理部、１３…記述取得処理部、１４…ＳＯＡＰ処理部、１５…ＳＯＡＰハンドラ、１６，１７…ハンドラ、１８…状態変数管理部、１９…ＧＥＮＡ処理部、２０…拡張装置用デバイス記述サービス記述取得処理部、２１…記述マージ形式判定処理部
【図１】
2006202210.tif 000003
【図２】
2006202210.tif 000004
【図３】
2006202210.tif 000005
【図４】
2006202210.tif 000006
【図５】
2006202210.tif 000007
【図６】
2006202210.tif 000008
【図７】
2006202210.tif 000009
【図８】
2006202210.tif 000010
【図９】
2006202210.tif 000011