(57)【要約】【課題】サービスを動的に構成して機能拡張し、提供することができるサービス提供装置、方法、およびプログラムを提供する。【解決手段】ネットワーク上に第１のサービス記述を広告すると共に第１のサービス記述が関連付けられた第１のサービスを提供するサービス提供装置において、第２のサービス記述が関連付けられた第２のサービスを利用して第１のサービスを機能拡張するための条件及び呼び出し方法を定義する定義テーブルを準備しておく。該定義テーブルを参照して条件を満たす第２のサービスを探索し、探索された第２のサービスに関連付けられている第２のサービス記述に基づいて第１のサービス記述を更新すると共にネットワーク上に広告する。広告された第１のサービスのサービス記述に基づくサービス要求に応答し、第２のサービスを呼び出し、該第２のサービスからの応答を受信する。受信された第２のサービスからの応答に基づいてサービス要求に対する応答を生成する。【選択図】図４
2006099675.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上に第１のサービス記述を広告すると共に該第１のサービス記述が関連付けられた第１のサービスを提供するサービス提供装置において、
第２のサービス記述が関連付けられた第２のサービスを利用して前記第１のサービスを機能拡張するための条件および該第２のサービスの呼び出し方法を定義する定義テーブルと、
前記定義テーブルを参照して前記条件を満たす第２のサービスを前記ネットワークから探索する探索手段と、
探索された第２のサービスに関連付けられている第２のサービス記述に基づいて前記第１のサービス記述を更新する更新手段と、
更新された第１のサービスのサービス記述を前記ネットワーク上に広告する広告手段と、
広告された第１のサービスのサービス記述に基づくサービス要求に応答し、前記定義テーブルを参照して前記第２のサービスを前記呼び出し方法により呼び出す手段と、
呼び出された第２のサービスからの応答を受信する手段と、
受信された第２のサービスからの応答に基づいて前記サービス要求に対する応答を生成する手段とを具備するサービス提供装置。
【請求項２】
前記広告手段は、前記第１のサービスの停止を前記ネットワーク上にマルチキャストした後、前記更新手段により更新された第１のサービスのサービス記述を前記ネットワーク上にマルチキャストする請求項１に記載のサービス提供装置。
【請求項３】
前記第２のサービスの前記ネットワーク上からの消失を検知する手段と、
第２のサービスの消失から一定時間が経過するまで、前記第１のサービスのサービス記述の更新を保留する手段とを具備し、
前記探索手段は、第２のサービスの消失から一定時間が経過するまで、前記第２のサービス又は代替サービスの探索を繰り返す請求項１に記載のサービス提供装置。
【請求項４】
前記更新手段により更新された第１のサービスのサービス記述を記憶する記憶手段を具備し、
前記広告手段は、前記記憶手段に記憶されたサービス記述を次回稼働時に読み出して前記ネットワークに広告する請求項１に記載のサービス提供装置。
【請求項５】
必須のサービスが前記探索手段により全て探索されない限り、前記広告手段によるサービス記述の広告を抑制する請求項１に記載のサービス提供装置。
【請求項６】
ネットワーク上に第１のサービス記述を広告すると共に該第１のサービス記述が関連付けられた第１のサービスを提供するサービス提供方法において、
第２のサービス記述が関連付けられた第２のサービスを利用して前記第１のサービスを機能拡張するための条件および該第２のサービスの呼び出し方法を定義する定義テーブルを準備するステップと、
前記定義テーブルを参照して前記条件を満たす第２のサービスを前記ネットワークから探索する探索ステップと、
探索された第２のサービスに関連付けられている第２のサービス記述に基づいて前記第１のサービス記述を更新する更新ステップと、
更新された第１のサービスのサービス記述を前記ネットワーク上に広告する広告ステップと、
広告された第１のサービスのサービス記述に基づくサービス要求に応答し、前記定義テーブルを参照して前記第２のサービスを前記呼び出し方法により呼び出すステップと、
呼び出された第２のサービスからの応答を受信するステップと、
受信された第２のサービスからの応答に基づいて前記サービス要求に対する応答を生成するステップとを具備するサービス提供方法。
【請求項７】
前記広告ステップにおいて、前記第１のサービスの停止を前記ネットワーク上にマルチキャストした後、前記更新ステップにより更新された第１のサービスのサービス記述を前記ネットワーク上にマルチキャストする請求項６に記載のサービス提供方法。
【請求項８】
前記第２のサービスの前記ネットワーク上からの消失を検知するステップと、
第２のサービスの消失から一定時間が経過するまで、前記第１のサービスのサービス記述の更新を保留するステップとを具備し、
前記第２のサービスの消失から一定時間が経過するまで、前記第２のサービス又は代替サービスの探索を繰り返す請求項６に記載のサービス提供方法。
【請求項９】
前記更新ステップにより更新された第１のサービスのサービス記述を記憶手段に記憶するステップと、
前記記憶手段に記憶されたサービス記述を次回稼働時に読み出して前記ネットワークに広告するステップとを具備する請求項６に記載のサービス提供方法。
【請求項１０】
必須のサービスが全て探索されない限り、前記広告ステップにおけるサービス記述の広告を抑制する請求項６に記載のサービス提供方法。
【請求項１１】
ネットワーク上に第１のサービス記述を広告すると共に該第１のサービス記述が関連付けられた第１のサービスを提供するプログラムにおいて、
第２のサービス記述が関連付けられた第２のサービスを利用して前記第１のサービスを機能拡張するための条件および該第２のサービスの呼び出し方法を定義する定義テーブルを準備する手順と、
前記定義テーブルを参照して前記条件を満たす第２のサービスを前記ネットワークから探索する探索手順と、
探索された第２のサービスに関連付けられている第２のサービス記述に基づいて前記第１のサービス記述を更新する更新手順と、
更新された第１のサービスのサービス記述を前記ネットワーク上に広告する広告手順と、
広告された第１のサービスのサービス記述に基づくサービス要求に応答し、前記定義テーブルを参照して前記第２のサービスを前記呼び出し方法により呼び出す手順と、
呼び出された第２のサービスからの応答を受信する手順と、
受信された第２のサービスからの応答に基づいて前記サービス要求に対する応答を生成する手順とをコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク技術に係わり、UPnP(Universal Plug and Play)においてサービスを動的に構成して提供するサービス提供装置、サービス提供方法およびプログラムに関する。
【背景技術】
【０００２】
オーディオ機器やビデオ機器ならびに他の家電機器をネットワークに接続して相互に利用するための技術が急速に進歩している。ネットワークを構成するある機器が、ネットワークを介して別の機器を操作できるためには、これら機器間で何らかの共通した通信手順が必要である。その一つとして、UPnP(Universal Plug and Play)プロトコルが知られている。UPnPは、既存のインターネット規格であるAutoIP(IPアドレスの自動割当て)、SSDP(Simple Service Discovery Protocol:相手機器の発見)、HTTP(Hyper Text Markup Language:ハイパーテキストの送受信)、XML(機器情報・サービスの記述)、SOAP(Simple Object Access Protocol:機器サービスの呼び出し)、GENA(Generic Event Notification Architecture:機器状態のイベント通知)といった要素技術を集積して構成される（下記特許文献１参照）。
【０００３】
UPnPコア上には、応用対象向けに特化したUPnPデバイスおよびUPnPサービスが定義される。UPnPに従うある機器は、１つ以上のUPnPサービスを持つUPnPデバイスとして動作し、UPnPサービスが他の機器向けに公開される。UPnPに従う別の機器は、UPnPコントロールポイントとして動作し、UPnPデバイスを発見する。UPnPコントロールポイントは、発見したUPnPデバイスが公開するUPnPサービスのいずれかの機能を呼び出し、該UPnPデバイスからのイベント通知を受信する。
【０００４】
UPnPデバイスとUPnPコントロールポイントの各々の役割は、事前の想定に基づいて静的に割り当てられる。したがって、UPnPデバイスが公開するUPnPサービスの機能は、UPnPデバイスとしての機器自体が持つ能力あるいはUPnPサービスが動作する機器自体が持つ能力に制約され、機器の動作中に変化することは想定されていない。また、機器の動作中にUPnPデバイスおよびサービスの変更、ならびに変更の通知を行う枠組みも用意されていない。
【０００５】
UPnPでは、このように動的な機能拡張の枠組みがないという問題があるが、UPnP以外の枠組みでは、動的なサービス構成を可能にしたものがある（例えば下記非特許文献１参照）。下記非特許文献１に記載の技術では、各機能の依存関係をグラフとして表現し、各機能を提供する機器を検索し、動的に結合することを行っている。しかしながら、上記非特許文献１に記載の技術は、大規模なコンピュータネットワーク上で動作することを前提とするし、機器間の連携用に仮想的なネットワークを構築するための独自のプロトコルを導入するなど、既存のプロトコルや機器を置き換えるものである。
【特許文献１】米国特許出願公開第２００２／００３５６２１
【非特許文献１】「STONE: 環境適応型ネットワークサービスアーキテクチャ, 電子情報通信学会技術研究報告, IN2001-12, May 2001」
【発明の開示】
【発明が解決しようとする課題】
【０００６】
UPnPの枠組みにおける既存のプロトコルを置き換えることなく、新たに、動的なサービス構成を可能とする仕組みを提供するには幾つかの課題がある。その一つは、いかにして機能の組み合わせを発見して新たなサービスを構築するかであり、もう一つは、いかにしてそのサービスを公開するかである。さらには、いかにしてそのサービスを安定したものとして維持するかという課題もある。
【０００７】
サービスを構築して公開する方法について、UPnPデバイス自体は他のUPnPデバイスを探索し、UPnPサービスを呼び出す能力を持たないため、他UPnPデバイスの存在または不存在に関係なく、該UPnPデバイスの提供機能を拡張する枠組みがない。
【０００８】
また、動的に変化するサービス内容の更新通知について、UPnPでは明示的に定めていない。いったんはUPnPデバイスとして終了させ、再起動させることで、周囲にssdp:byebyeを通知し、それに基づいて該デバイスの再認識とイベント購読登録のクリアが可能となる。しかし、ssdp:byebyeを以て終了することは、該UPnPデバイスが提供する機能を全て終了することであり、更新されたサービスに影響しない機能を利用している機器にとっては、処理途中で中断・失敗させられることになる。したがって、関係ない機能を用いている機器にとっては、従来どおり継続して利用可能であることが好ましい。
【０００９】
本発明は上記課題を解決し、サービスを動的に構成して機能拡張し、提供することができるサービス提供装置、方法、およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一観点に係るサービス提供装置は、ネットワーク上に第１のサービス記述を広告すると共に該第１のサービス記述が関連付けられた第１のサービスを提供するサービス提供装置において、第２のサービス記述が関連付けられた第２のサービスを利用して前記第１のサービスを機能拡張するための条件および該第２のサービスの呼び出し方法を定義する定義テーブルと、前記定義テーブルを参照して前記条件を満たす第２のサービスを前記ネットワークから探索する探索手段と、探索された第２のサービスに関連付けられている第２のサービス記述に基づいて前記第１のサービス記述を更新する更新手段と、更新された第１のサービスのサービス記述を前記ネットワーク上に広告する広告手段と、広告された第１のサービスのサービス記述に基づくサービス要求に応答し、前記定義テーブルを参照して前記第２のサービスを前記呼び出し方法により呼び出す手段と、呼び出された第２のサービスからの応答を受信する手段と、受信された第２のサービスからの応答に基づいて前記サービス要求に対する応答を生成する手段とを具備する。
【発明の効果】
【００１１】
UPnPデバイスが、UPnPコントロールポイントとして他UPnPデバイスおよびUPnPサービスを探索可能とすることにより、UPnPデバイスおよびサービスが提供する機能ないしその一部を、他UPnPデバイスおよびサービスを呼び出すことによって拡張する仕組みを実現できる。
【００１２】
また、一連のUPnPデバイスとUPnPコントロールとの間の通信はUPnPプロトコルに基づいたものであって、なんら拡張したり新たなプロトコルを導入するものではなく、あらかじめ連携して用いられることを想定して設計されていないUPnPデバイスをも連携対象に含めることができる。
【００１３】
また、提供機能が変化したサービスについてのみ、UPnPサービス広告をやり直すことにより、UPnPデバイスおよびサービス全てのUPnPサービス広告をやり直す場合と比較して、広告に要するパケット数、サービス中断時間を軽減できる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照しながら本発明の実施形態を説明する。
【００１５】
図１に本発明の一実施形態に係るUPnPネットワークの一例を示すブロック図である。本ネットワークは、UPnPデバイス１と、対応するUPnPコントロールポイント２と、複数のUPnPデバイス１０，１１，１２とを具備する。UPnPデバイス１は本発明が適用されたサービス公開装置に相当し、UPnPコントロールポイント２、ならびにUPnPデバイス１０，１１，１２は既存のものである。なお、本実施形態は、サービスを「提供」することと、サービスを「公開」することとが同じ意味であるものとして説明を行う。
【００１６】
UPnPコントロールポイント２は、UPnPデバイスを制御するクライアント機器に相当し、例えばパーソナルコンピュータなどを利用して実現され、図示しないが制御などの演算処理を行うための中央処理ユニット（ＣＰＵ）、表示のための処理ブロック、操作入力のための処理ブロック、処理内容の記憶ブロック、および他機器との通信処理ブロックが内部バスで結合された構成を有する。
【００１７】
UPnPデバイス１は、UPnPコントロールポイントからの制御を受けるサーバ機器に相当し、UPnPコントロールポイントと同様にコンピュータを利用して実現できる。また、本発明に係る機能を実現するためのプログラムが図示しないプログラム記憶装置に格納される。プログラム記憶装置は、例えば、磁気ディスク装置や光ディスク装置等からなる。上記プログラムがＣＰＵからの制御でランダムアクセスメモリ（ＲＡＭ）に読み込まれ、同ＣＰＵにより実行されることにより、コンピュータを本発明に係るUPnPデバイス（サービス公開装置）として機能させることができる。なお、UPnPデバイス１には、各種コンピュータ資源を管理し、ファイルシステムやネットワーク通信機能、ならびにグラフィカルユーザインタフェース（ＧＵＩ）等を提供するオペレーティングシステムも導入されている。
【００１８】
図２を参照し、UPnPデバイスとUPnPコントロールポイントとの間の動作を概略的に説明すると、UPnPデバイス１は、SSDP３に従ってUPnPコントロールポイント２に向けて自機器の存在を広告し、XML形式で記述されたデバイス記述・サービス記述４も広告する。UPnPコントロールポイント２は、UPnPデバイス１およびサービス１，２をSSDP３に従って発見し、各サービス１，２のアクションをSOAPに基づく呼び出し５により制御する。UPnPサービスの状態変化は、GENAに基づくイベント通知６を購読するUPnPコントロールポイント２に対して通知される。このような基本的な動作は、既存のUPnPデバイス１０〜１２についても同様である。
【００１９】
図３は既存のUPnPデバイスのソフトウェア構成を示す図である。例えば既存のUPnPデバイス１０が公開する機能の一覧はデバイス記述・サービス記述７として静的に用意されており、SSDP処理部８を通じて、UPnPデバイスタイプ、デバイスID、およびサービスタイプ等が広告される。広告された情報に基づいて、UPnPコントロールポイント２は必要なサービスまたはデバイスを選択し、HTTPによって、デバイス記述・サービス記述７の取得要求を行う。記述取得処理部９は、この取得要求に応じ、XML形式で記述されたデバイス記述・サービス記述７をUPnPコントロールポイント２に送信する。
【００２０】
各サービスの機能は、各UPnPサービスのアクションとして、SOAPを介して利用可能である。UPnPコントロールポイント２からのアクション要求は、SOAP処理部１３からSOAPハンドラ１４を通じて、各アクションのハンドラ１５，１６に渡される。これらアクションハンドラ１５，１６は、UPnP状態変数を参照しながら、実際の処理を行い、処理結果に応じてレスポンスを返すとともに、UPnP状態変数を更新する。UPnP状態変数を管理する状態変数管理部１７は、更新された状態変数がイベント通知の対象であれば、購読元のUPnPコントロールポイント２に対して、GENA処理部１８を通じて、イベント通知を行う。
【００２１】
一方、図４は本発明の実施形態に係るサービス公開装置としてのUPnPデバイスのソフトウェア構成を示しており、図３と比較すると、サービス依存関係管理部１９と、サービス依存関係定義テーブル２０と、サービス依存関係テーブル２１と、依存アクションハンドラ２２とが追加されている。なお、SSDP処理部２３、記述取得処理部２４、SOAP処理部２５、GENA処理部２６の各々は、UPnPデバイスとしての動作に加えて、UPnPコントロールポイントとしての動作も行う。
【００２２】
サービス依存関係管理部１９は、サービス依存関係定義テーブル２０が示す条件に適合する周囲のUPnPサービスをSSDP処理部２３を通じて列挙する。また、記述取得処理部２４を通じて、周囲UPnPデバイスのデバイス記述・サービス記述を取得し、サービス依存関係テーブル２１を更新する。これに応じて、対応するデバイス記述・サービス記述２８も更新する。更新されたデバイス記述・サービス記述２８は、周囲のUPnPコントロールポイント２に対して広告される。
【００２３】
依存アクションハンドラ２２は、サービス依存関係管理部１９と連携し、周囲UPnPサービスのアクションを選択して呼び出す。
【００２４】
各アクションハンドラ３０，３１は、各々が内蔵するサービスに加え、依存アクションハンドラ２２を通じて周囲UPnPサービスのアクションを呼び出し可能である。実際にどの周囲UPnPサービスのアクションを呼び出すか、あるいは呼び出さないかは、サービス依存関係定義テーブル２０と、サービス依存関係テーブル２１に格納されている、呼び出し可能な周囲UPnPサービスのアクションの一覧とから決定される。
【００２５】
つまり、各サービスの機能は、UPnPサービスの各アクションとして呼び出され、該アクションに対応するハンドラ関数が内部で呼び出される。ハンドラ関数内では、依存アクションハンドラ２２を通じ、周囲の別のUPnPデバイス・サービスが公開するアクションを呼び出せるので、UPnPデバイス間で連携が実現できる。これをUPnPコントロールポイント２側から見た場合、一つのサービスとして公開されるので、UPnPコントロールポイント２の負担を増大させることなく、高機能なサービスを組み合わせた利用が可能になる。
【００２６】
図５は、UPnPデバイス、UPnPサービス、UPnPコントロールポイントをそれぞれの役割の面から示したものである。UPnPデバイス１は、コントロールポイントモジュール３２により、周囲のUPnPデバイス１０、１１に対してUPnPコントロールポイントとして振る舞う。コントロールポイントモジュール３２は、周囲のUPnPサービス３３，３４の列挙と選択、アクションの呼び出しを行うことにより、もともとのUPnPコントロールポイント２から要求されたアクションの一部をこれらUPnPサービス３３，３４に実行させる。これにより、UPnPサービス３５を周囲のUPnPサービス３３，３４が提供する能力によって強化することが可能になる。
【００２７】
図６は、本発明の一実施形態に係るUPnPネットワークにおいてサービスが実行される手順を示すシーケンス図である。
【００２８】
当初、UPnPデバイス１は、既存のUPnPデバイスおよびUPnPサービスとして、UPnPコントロールポイントからの要求に応答する（ステップＳ１）。これと並行して、定期的又は周囲UPnPデバイスの広告に基づいて、以下のステップを実行する。UPnPデバイス１は、周囲のUPnPデバイスをSSDPによって探索(ssdp:discover)する（ステップＳ２）。ここで、UPnPデバイス１の周囲のUPnPデバイスとして、UPnPデバイス１０，１１，１２が全て発見されるとするが、UPnPデバイス１１，１２についてはシーケンス図上では「他の周囲UPnPデバイス」としてまとめて示してある。
【００２９】
UPnPデバイス１は、周囲のUPnPデバイスからデバイス記述・サービス記述を得る。そして、サービス依存関係定義テーブル２０が示す条件に適合する、周囲のUPnPデバイスのデバイス記述・サービス記述を取得し、サービス依存関係テーブル２１を更新する（ステップＳ３）。これに応じて、対応するデバイス記述・サービス記述２８も更新する（ステップＳ４）。更新されたデバイス記述・サービス記述２８は、UPnPコントロールポイント２に対して広告される（ステップＳ５）。同図に示す参照符号３５は、周囲のUPnPデバイスおよびUPnPサービスに基づき、本発明に従って合成され、公開された新たなUPnPサービスの生存線を示している。
【００３０】
この後、UPnPデバイス１は、UPnPコントロールポイント２からSOAPに基づくアクションの実行を要求されると（ステップＳ６）、該アクションをUPnPデバイス１のみの単独で実行可能であるか、それとも発見済の周囲UPnPサービスを必要とするかを判断する（ステップＳ７）。ここでは、要求されたアクションは周囲のUPnPデバイスのUPnPサービスの呼び出しが必要であると判定する。
【００３１】
周囲UPnPサービスのアクション実行が必要な場合、UPnPデバイス１は、UPnPコントロールポイントとして周囲のUPnPサービスのアクション（SOAPアクション）を実行し（ステップＳ８，Ｓ１０）、該当する周囲のUPnPデバイスから応答（SOAPレスポンス）を得る（ステップＳ９，Ｓ１１）。UPnPデバイス１は、受け取ったこれらの応答に基づいてUPnPコントロールポイント２に返す値を生成し（ステップＳ１２）、最終的なSOAPレスポンスを返す（ステップＳ１３）。
【００３２】
図７は、サービス依存関係定義テーブルのデータフォーマットの一例を示している。サービス依存関係定義テーブル２０は、別のサービス（のアクション）の呼び出しを利用して機能拡張を行うための条件およびと該別のサービス（のアクション）のサービスの呼び出し方法を少なくとも定義する。具体的には、サービス依存関係定義テーブル２０の一要素（レコード）は、サービスタイプ(serviceType)２００と、サービスID(serviceId)２０１と、アクション名(actionName)２０２とからなるフィールド組について、当該サービスに接続（組み合わせること）が可能な周囲のUPnPサービスアクションの条件を表す周囲サービスタイプ条件(external serviceType condition)２０３と、当該サービスの呼び出し方法を規定するサービススクリプト(service script)２０４とを定義する。サービス依存関係定義テーブル２０の要素の具体例を図８，図９，図１０に示す。
【００３３】
図８に示される具体例によると、urn:schemas-upnp-org:TranslateService:1.0サービスのTranslateアクションに接続可能な周囲UPnPサービス（アクション）の条件は次の通りである。すなわち、urn:schemas-upnp-org:TranalateService:1.0サービスを持っており、そのサービスがTranslateアクションを持っており、そのTranslateActionのoutputLanguage引数が取り得る値に"Chinese"が含まれていることを条件としている。この条件を満足する場合のサービスの呼び出し方法は、次の通りである。すなわち、UPnPコントロールポイントからのTranslateアクションの呼び出しに対して、outputLanguage引数に"Chienese"が指定されている場合は、該当する周囲UPnPサービスのTranslateアクションを、さもなければ内蔵のTranslateアクションを呼び出し、その戻り値をTranslateアクションのレスポンスとする。
【００３４】
図９に示される具体例は、必要とする周囲UPnPサービスのサービスタイプが、当初に呼び出されるアクションのサービスタイプとは異なる例である。urn:schemas-upnp-org:ContentDirectory:1.0サービスのBrowseアクションに接続可能な周囲UPnPサービスの条件は次の通りである。すなわち、urn:schemas-upnp-org:TranalateService:1.0サービスを持っており、そのサービスがTranslateアクションを持っており、そのTranslateActionのoutputLanguage引数が取り得る値に"Chinese"が含まれていることである。この条件を満たす場合のサービスの呼び出し方法は、次の通りである。すなわち、先ずは、Browseアクションを実行する。次に、もしもUPnPコントロールポイントからのBrowseアクションを運ぶHTTPヘッダのAccept-Languageが"Chinese"であれば、Translateアクションを実行してその出力であるoutStrを、新たなresultとする。例えば、Translate(defulat, "Chinese", inStr, outStr)が、inStrで示される原文を中国語に翻訳しoutStrに書き込むアクションであるとするならば、UPnPコントロールポイントによるBrowseアクションのレスポンスに含まれるresultは中国語に翻訳された内容で得られることになる。
【００３５】
図１０に示された具体例によると、urn:schemas-upnp-org:DiskManageService:1.0のGetFreeSizeアクションに接続可能なサービスの条件は次の通りである。すなわち、urn:schemas-upnp-org:DiskManageService:1.0を持っており、そのサービスがGetFreeSizeアクションを持っていることである。そのとき、UPnPコントロールポイントからのGetFreeSizeアクションの呼び出しに対して、自機器のGetFreeSizeアクション(local.GetFreeSize())による戻り値と、該当する各UPnPサービスのGetFreeSizeアクション(s.GetFreeSize())の戻り値との合計sumをGetFreeSizeアクションのレスポンスとする。
【００３６】
図１１は、図８のサービス依存関係定義テーブルに基づいて探索された周囲UPnPサービス一覧の一例を示す図である。探索された周囲UPnPサービスをアクション毎に並べたものがサービス依存関係テーブル２１に相当する。ここでは、図８に示した周囲サービスタイプ条件(external serviceType condition)を満足する２つのサービスが発見されており、各UPnPサービスを提供するUPnPデバイスのUDNは、それぞれ「uuid:C422BC28-117F-4d30-B443-59CA09130305」と、「uuid:11546136-2956-4d4f-BFF7-AC3B11AECAAA」である。当然ながら、これは周囲UPnPサービスの稼動開始・停止に応じて変化する。
【００３７】
以上説明したように、周囲のUPnPデバイスが公開するUPnPサービスの少なくとも一部を取り込むことによって、UPnPデバイス１が公開するUPnPサービスを機能拡張できる。この際、UPnPデバイス１が公開するサービスの変更を周囲のUPnPデバイスに通知する必要がある。
【００３８】
ここで、従来のUPnP仕様では、UPnPデバイスが動作中に公開するサービスが動的に変化することを想定しておらず、公開された新たなサービスをその公開時に通知する枠組みが提供されていない。この場合、次に示すようにUPnPデバイスとしての動作をいったん終了し、再開する方法を採ることが前提となっている。
【００３９】
（１）UPnPデバイスとしての動作を停止する。公開するデバイスID，デバイスタイプ，サービスタイプ，サービスIDの各々についてssdp:byebyeを周囲にマルチキャストし、サービスの停止を通知する。
【００４０】
（２）公開するサービスに関するデバイス記述およびサービス記述を変更する。
【００４１】
（３）UPnPデバイスとしての動作を再開する。ここで、公開するデバイスID，デバイスタイプ，サービスタイプ，サービスIDの各々についてssdp:aliveを周囲にマルチキャストし、新たなサービスが稼働中であることを通知する。
【００４２】
本発明に従う場合は次の手順を採る（UPnPデバイス１）。
【００４３】
（１）公開する内容に変更が生じたサービスのサービス記述を変更する。
【００４４】
（２）上記サービスのssdp:aliveを周囲にマルチキャストする。ここで、CACHE-CONTROLヘッダの値をmax-age=0とする。
【００４５】
マルチキャストに応答するUPnPコントロールポイント２においては、通常、CACHE−CONTROL: max-age=600など非0な値のヘッダが付与されたssdp:aliveパケットを受け取ると、所定の時間（この場合は６００秒）は、ssdp:aliveが広告する内容をキャッシュする。キャッシュ期限が到来する前に、次のssdp:aliveパケットが広告されるか、UPnPコントロールポイント２側からssdp:discoverパケットによる探索を行う必要がある。本発明に従う場合、ssdp:alive CACHE-CONTROL: max-age=0を受け取ると、該サービスに対して有する内部キャッシュがクリアされる。このため、該サービスのサービス記述を再取得する必要に迫られ、取得したサービス記述のタイムスタンプである、HTTP-GETのレスポンスに含まれるLast-Modifiedヘッダが示す時刻が、従来得たものと異なるから、サービス記述が従来から変化したと判断できる。
【００４６】
この方法では、CAHCHE-CONTROLに基づくUPnPコントロールポイント２の挙動を協調的なものであると仮定している。よりUPnP仕様に忠実なUPnPコントロールポイントの収容を考慮すると、次の手順を実行して、変更が生じたサービスのみの一時停止と変更、再開を行うことが好ましい。
【００４７】
（１）公開する内容に変更が生じたサービスのssdp:byebye（停止）を周囲にマルチキャストする。
【００４８】
（２）上記サービスのサービス記述を変更する。
【００４９】
（３）上記サービスのssdp:alive（開始）を周囲にマルチキャストする。
【００５０】
先ほどの方法と比較してパケット数は増えるものの、より確実にサービス変更を広告できることが期待される。このとき、UPnPコントロールポイント２は、利用中のサービスがいったん終了したので、呼び出し中の手続きは失敗し、イベント通知の購読は解除されたものと判断できる。その後、サービスが再開したのでサービス記述を再取得することが要求され、取得したサービス記述のタイムスタンプである、HTTP-GETのレスポンスに含まれるLast-Modifiedヘッダが示す時刻が、従来得たものと異なるから、サービス記述が従来から変化したと判断できる。
【００５１】
この方法の場合、従来のようにUPnPデバイスとして全サービスを終了する場合と比べて、影響がないサービスをそのまま継続できる。これは、単純にサービスの通知用マルチキャストパケットの個数のみならず、イベント通知の再購読手続きの実行に必要なパケットをも減らすことができる。
【００５２】
例えば１つのデバイスがｍ個のサービスを有しており、各サービスについてｎ個のコントロールポイントからイベント通知購読が行われているとする。この場合、ssdpアナウンスをUPnPデバイス１個について３個（UPnPルートデバイス、UPnPデバイスタイプ、UPnPデバイスID）行い、UPnPサービス１個について１個（UPnPサービスタイプ）行う必要がある。
【００５３】
この場合、UPnPの仕様に基づくと、一連のパケットの個数は(3+m)+(3+m)+(1+m)×n×2+m×n×2となる。ここで、第１項はssdp:byebyeの送信、第2項はssdp:aliveの送信、第3項はデバイス記述及びサービス記述の取得、第4項はイベント通知購読の各々に要するパケット個数である。１個のサービスのみ更新されるものとして、本発明に従う場合の同様のパケット個数は、1+1+N×2+N×2となる。ここで、第1項から第4項までの意味するところは、前述のものと同じである。よって、その差、4+2×m+2×n×(2×m-1)個のパケットを省略できる。
【００５４】
なお、サービスの増減がある場合には、デバイス記述を変更する必要があるので、上記と同様の手順でデバイスの更新通知を行う。ただし、後者の方法を採る場合、従来と同様にデバイスと全サービスを一時停止し、再開することになる。これは、従来方法から拡張したことによる、従来方法との互換性に基づくものである。
【００５５】
本発明に従いUPnPデバイスのサービスが機能拡張された場合、デバイス記述およびサービス記述を更新する必要があるが、拡張に必要な周囲UPnPデバイスまたは周囲UPnPサービスが停止した場合、再度、デバイス記述およびサービス記述を更新し、広告する必要がある。
【００５６】
ここで、周囲UPnPデバイスの出現と離脱が頻繁であって、それに伴ってUPnPデバイス記述とサービス記述の更新と広告が頻繁になる場合を考慮すると、UPnPデバイス記述とサービス記述の更新への対応をUPnPコントロールポイントが常に行う必要がある。これは、UPnPコントロールポイントに高い負荷をかけてしまうし、デバイス記述・サービス記述の変化に応じてアクション呼び出しの内容を調整する必要も生じてしまうことから、UPnPコントロールポイントによるUPnPデバイス記述とサービス記述の更新の頻度、ならびに広告の頻度は、できるだけ抑えることが好ましい。
【００５７】
そこで、本実施形態では、次のような手順を並行して実行し、広告する機能は拡張したままで、実際の機能呼び出しが行われた際に、必要となる周囲UPnPデバイスが公開するサービスを探索し、呼び出すようにする。
【００５８】
（手順１）周囲UPnPデバイス・サービスのssdp:byebye通知を受け取る。
【００５９】
（手順２）対応するサービスタイプを有するUPnPデバイス・サービスを見つける。ここで、既にssdp:alive広告したUPnPデバイス・サービスから検索する。また、ssdp:discoverによる周囲UPnPデバイス・サービス発見手順を実行する。
【００６０】
（手順３）対応するサービスが見つかった場合、呼び出し先を該サービスに切り替える。
【００６１】
（手順４）対応するサービスが見つからなかった場合（すなわちサービスの消失）、一定時間が経過し、あるいは所定の条件が満たされるまで、UPnPデバイス・サービスの更新と広告を保留する。ここで、該当する周囲UPnPデバイス・サービスの呼び出しは失敗させる。
【００６２】
なお、上記手順２において、対応するサービスないしアクションを完全にカバーできない場合（全てのアクションを代替できない場合や、アクションの引数が取り得る値範囲が小さい場合など）には、これらが見つからないものとして上記手順４を実行してもよい。あるいは、上記手順４でのサービス更新と広告が実行されるまで、アクションが代替可能である限り、上記手順３を繰り返してもよい。
【００６３】
上記実施形態では、UPnPデバイス１（サービス公開装置）の動作中における周囲UPnPデバイスおよびサービスの出現・離脱に対応した動作を説明したが、該UPnPデバイス１がいったん動作停止し、再開する場合においても、拡張したUPnPサービスを広告してもよい。この場合、上記と同様に拡張したUPnPサービスのアクション呼び出しに必要となる周囲UPnPデバイスまたはサービスが見つからない場合が考えられるが、上記と同様の手順によって、UPnPコントロールポイント２からの要求があって初めて周囲UPnPデバイスまたはサービスを探索し、見つかったUPnPデバイスまたはサービスを呼び出し、また所定の時間経過または所定の条件が満足されると、実際に現在の内容にあわせたデバイス記述・サービス記述に更新し、再広告することによって、稼動開始直後から高機能なサービスを提供するものとUPnPコントロールポイント２に対して公開することができる。
【００６４】
また、上記所定の条件は、「実際にUPnPコントロールポイントによる機能呼び出し（すなわちアクション呼び出し）があったか否か」を含めることができる。すなわちUPnPコントロールポイント２が実際に、拡張されたUPnPサービスの機能、つまりアクションを呼び出したか否か、またはその頻度や最後に呼び出した時間に基づいて、たとえ必要となる周囲UPnPデバイスまたはサービスが見つからない場合でも、自UPnPサービス記述をそのまま維持するか、本来の自UPnPサービスの内容に変更して再広告するかを判断し、実行する。これによって、実際に拡張された機能の必要性に基づいて、サービス記述を適切に変更し広告することができる。
【００６５】
上記実施形態と関連して、UPnPコントロールポイント２が実際に、拡張されたUPnPサービスの機能、つまりアクションを呼び出したか否か、またはその頻度や最後に呼び出した時間に基づいて、周囲UPnPサービスの呼び出しを行うか否か、デバイス記述・サービス記述を更新し再広告するか否かを判断し、例えば呼び出し頻度が所定の回数に達しない場合には、今後は該当するサービスタイプの周囲UPnPサービスを発見しても、該サービスの機能拡張を行わないよう判断のためのフラグを設定してもよい。
【００６６】
また上記実施形態は、既に存在し、稼動しているUPnPデバイスおよびUPnPサービスの機能を拡張するものであったが、既に稼動しているUPnPデバイスおよびサービスの拡張のみならず、必須とする周囲UPnPデバイスおよびサービスが全て存在する場合に限って公開されるような、UPnPデバイスおよびUPnPサービスとして動作するものとしてもよい。すなわち、必須の周囲UPnPデバイスおよびサービスが全て探索されない限り、サービス公開（サービス記述の広告）を抑制するようにしてもよい。このように、本発明の実施形態によれば、既存のサービスの機能拡張のみならず、既存サービスの組み合わせに基づく全く新たなサービスを動的に構成して公開することが可能になる。
【００６７】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００６８】
【図１】本発明の一実施形態に係るUPnPネットワークの一例を示すブロック図
【図２】UPnPデバイスとUPnPコントロールポイントとの間の動作を概略的に説明するための図
【図３】既存のUPnPデバイスのソフトウェア構成を示す図
【図４】本発明の実施形態に係るサービス公開装置としてのUPnPデバイスのソフトウェア構成を示す図
【図５】UPnPデバイス、UPnPサービス、UPnPコントロールポイントをそれぞれの役割の面から示した図
【図６】本発明の一実施形態に係るUPnPネットワークにおいてサービスが実行される手順を示すシーケンス図
【図７】サービス依存関係定義テーブルのデータフォーマットの一例を示す図
【図８】サービス依存関係定義テーブルの要素の具体例を示す図
【図９】サービス依存関係定義テーブルの要素の具体例を示す図
【図１０】サービス依存関係定義テーブルの要素の具体例を示す図
【図１１】サービス依存関係テーブルの一例を示す図
【符号の説明】
【００６９】
１，１０，１１，１２…UPnPデバイス、２…UPnPコントロールポイント
【図１】
2006099675.tif 000003
【図２】
2006099675.tif 000004
【図３】
2006099675.tif 000005
【図４】
2006099675.tif 000006
【図５】
2006099675.tif 000007
【図６】
2006099675.tif 000008
【図７】
2006099675.tif 000009
【図８】
2006099675.tif 000010
【図９】
2006099675.tif 000011
【図１０】
2006099675.tif 000012
【図１１】
2006099675.tif 000013