(57)【特許請求の範囲】
【請求項１】
指定されたＵＰｎＰ（Universal Plug and Play）のサービスを提供するためのプログラムをインストールするための、ＵＰｎＰの特定のサービスを、端末が探索し、
前記特定のサービスを提供するデバイスが、前記端末に応答を返し、
前記端末が、前記応答により検出される前記特定のサービスに対して、ＵＰｎＰの新規サービスを提供するための新規プログラムの前記デバイスへのインストールに関わる通知であって、前記新規プログラムを受信するための準備を行うよう、前記デバイスに促す当該通知であるインストール関連通知を送信し、
特定の環境に前記デバイスが存在しているとき、検出装置が、前記デバイスが前記特定の環境下にあることを示す検出通知を送信し、
前記新規サービスを指定するサービス指定情報および前記特定の環境と対応づけて前記新規プログラムを格納する管理部が、前記検出通知の受信に応じて、前記新規プログラムを前記デバイスに送信し、
前記デバイスが、前記特定のサービスを提供するための特定のプログラムにしたがって動作することによって、前記インストール関連通知の受信の後に前記管理部から前記新規プログラムを受信して取得するとともに取得した前記新規プログラムを前記デバイスにインストールし、
前記デバイスが、インストールした前記新規プログラムにしたがって動作することにより、前記新規サービスを前記端末に提供する
ことを含むことを特徴とするサービス提供方法。
【請求項２】
端末が、デバイスの提供するＵＰｎＰのサービスを検出し、
前記端末が、前記デバイスに含まれるかまたは他のコンピュータに含まれる管理部に対して、前記サービスを識別するサービス識別情報を通知し、
特定の環境に前記端末が存在しているときに、検出装置が、前記端末が前記特定の環境下にあることを示す検出通知を、前記管理部に送信し、
前記管理部は、前記サービスを含む複数のサービスそれぞれについて、当該サービスを識別するサービス識別情報および当該サービスが利用される環境と対応づけて、当該サービスを利用するためのＵＰｎＰのコントローラのプログラムを格納しており、前記検出通知を受信すると、
前記サービスを利用するためのＵＰｎＰの特定のコントローラを実現するプログラムである特定のコントローラプログラムであって、前記端末から通知された前記サービス識別情報と前記特定の環境とに対応づけて格納している前記特定のコントローラプログラムを検索し、
検索により見つけた前記特定のコントローラプログラムを前記端末に送信し、
前記端末が、前記特定のコントローラプログラムを受信し、
前記端末が、受信した前記特定のコントローラプログラムを前記端末にインストールし、
前記端末が、インストールした前記特定のコントローラプログラムにしたがって動作することにより、検出した前記サービスを利用するための制御メッセージを、検出した前記サービスに対して与える
ことを特徴とするサービス利用方法。
【請求項３】
第１の端末と第２の端末と管理装置を含むシステムで実行される方法であって、
ＵＰｎＰ（Universal Plug and Play）のサービスを提供するためのサービスプログラムと、ＵＰｎＰの何らかのサービスを利用するためのＵＰｎＰのコントローラを実現するためのコントローラプログラムのいずれが指定されても、指定されたプログラムをインストールするためのＵＰｎＰのサービスである更新サービスを、前記第１の端末と前記第２の端末がともに提供しており、
前記第１の端末と前記第２の端末が特定の環境に入ると、前記第１の端末と前記第２の端末が前記特定の環境下にあることを示す検出通知を、検出装置が送信し、
１つ以上のＵＰｎＰのサービスのそれぞれについて、当該サービスと、当該サービスのインストール先の端末であるサービス提供端末の種類と、当該サービスを利用するためのコントローラと、当該コントローラのインストール先の端末であるコントローラ端末の種類と、当該サービスが利用される環境とを、互いに対応づける条件情報を、前記管理装置が格納しており、
前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第１の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第２の端末の前記種類と一致する第１の場合には、
前記検出通知の受信に応じて、前記管理装置が、前記条件情報により前記特定の環境と対応づけられている特定のサービスを提供するための特定のサービスプログラムを前記第１の端末に送信するとともに、前記条件情報により前記特定の環境と対応づけられている特定のコントローラを実現するための特定のコントローラプログラムを前記第２の端末に送信し、
前記第１の端末が、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第１の端末へのインストールを実行し、
前記第２の端末が、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第２の端末へのインストールを実行し、
前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第２の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第１の端末の前記種類と一致する第２の場合には、
前記検出通知の受信に応じて、前記管理装置が、前記特定のサービスプログラムを前記第２の端末に送信するとともに、前記特定のコントローラプログラムを前記第１の端末に送信し、
前記第１の端末が、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第１の端末へのインストールを実行し、
前記第２の端末が、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第２の端末へのインストールを実行する
ことを特徴とする方法。
【請求項４】
指定されたＵＰｎＰ（Universal Plug and Play）のサービスを提供するためのプログラムをインストールするための、ＵＰｎＰの特定のサービスを提供するデバイスと、
前記特定のサービスの探索を行うと共に、前記探索により検出された前記特定のサービスに対して、ＵＰｎＰの新規サービスを提供するための新規プログラムの前記デバイスへのインストールに関わる通知であって、前記新規プログラムを受信するための準備を行うよう、前記デバイスに促す当該通知であるインストール関連通知を送信する端末と、
特定の環境に前記デバイスが存在しているとき、前記デバイスが前記特定の環境下にあることを示す検出通知を送信する検出装置と、
前記新規サービスを指定するサービス指定情報および前記特定の環境と対応づけて前記新規プログラムを格納しており、前記検出通知の受信に応じて、前記新規プログラムを前記デバイスに送信する管理部と、
を備え、
前記デバイスは、前記特定のサービスを提供するための特定のプログラムにしたがって動作することによって、前記インストール関連通知の受信の後に前記管理部から前記新規プログラムを受信して取得するとともに取得した前記新規プログラムを前記デバイスにインストールし、インストールした前記新規プログラムにしたがって動作することにより、前記新規サービスを前記端末に提供する、
ことを特徴とするシステム。
【請求項５】
デバイスの提供するＵＰｎＰのサービスを検出し、検出した前記サービスを利用するための制御メッセージを、検出した前記サービスに対して与える端末と、
特定の環境に前記端末が存在しているときに、前記端末が前記特定の環境下にあることを示す検出通知を送信する検出装置と、
前記サービスを含む複数のサービスそれぞれについて、当該サービスを識別するサービス識別情報および当該サービスが利用される環境と対応づけて、当該サービスを利用するためのＵＰｎＰのコントローラのプログラムを格納しており、前記デバイスに含まれるかまたは他のコンピュータに含まれている管理部と、
を備え、
前記端末は、前記管理部に対して、検出した前記ＵＰｎＰのサービスを識別するサービス識別情報を通知し、
前記管理部は、前記検出通知の受信を行い、前記検出通知を受信すると、前記サービスを利用するためのＵＰｎＰの特定のコントローラを実現するプログラムである特定のコントローラプログラムであって、前記端末から通知された前記サービス識別情報と前記特定の環境とに対応付けて格納している前記特定のコントローラプログラムを検索し、前記検索により見つけた前記特定のコントローラプログラムを前記端末に送信し、
前記端末は、前記特定のコントローラプログラムを受信し、受信した前記特定のコントローラプログラムを前記端末にインストールし、インストールした前記特定のコントローラプログラムにしたがって動作することにより、検出した前記サービスを利用するための制御メッセージを、検出した前記サービスに対して与える、
ことを特徴とするシステム。
【請求項６】
ＵＰｎＰ（Universal Plug and Play）のサービスを提供するためのサービスプログラムと、ＵＰｎＰの何らかのサービスを利用するためのＵＰｎＰのコントローラを実現するためのコントローラプログラムのいずれが指定されても、指定されたプログラムをインストールするためのＵＰｎＰのサービスである更新サービスをともに提供する第１の端末及び第２の端末と、
前記第１の端末と前記第２の端末が特定の環境に入ると、前記第１の端末と前記第２の端末が前記特定の環境下にあることを示す検出通知を送信する検出装置と、
１つ以上のＵＰｎＰのサービスのそれぞれについて、当該サービスと、当該サービスのインストール先の端末であるサービス提供端末の種類と、当該サービスを利用するためのコントローラと、当該コントローラのインストール先の端末であるコントローラ端末の種類と、当該サービスが利用される環境とを、互いに対応づける条件情報を格納している管理装置と、
を備え、
前記管理装置は、前記検出通知の受信を行い、前記検出通知を受信したときに、前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第１の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第２の端末の前記種類と一致する第１の場合と、前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第２の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第１の端末の前記種類と一致する第２の場合とのどちらであるかの判定を行い、
前記判定により前記第１の場合であると判定された場合には、
前記管理装置は、前記条件情報により前記特定の環境と対応づけられている特定のサービスを提供するための特定のサービスプログラムを前記第１の端末に送信するとともに、前記条件情報により前記特定の環境と対応づけられている特定のコントローラを実現するための特定のコントローラプログラムを前記第２の端末に送信し、
前記第１の端末は、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第１の端末へのインストールを実行し、
前記第２の端末は、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第２の端末へのインストールを実行し、
前記判定により前記第２の場合であると判定された場合には、
前記管理装置は、前記特定のサービスプログラムを前記第２の端末に送信するとともに、前記特定のコントローラプログラムを前記第１の端末に送信し、
前記第１の端末は、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第１の端末へのインストールを実行し、
前記第２の端末は、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第２の端末へのインストールを実行する
ことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＰｎＰ（Universal Plug and Play）に関する。
【背景技術】
【０００２】
状況に応じて適切なソフトウェアを追加または更新する技術は、ユーザの利便性を高める上で有益である。例えば、自律的なシステム構成を支援するための、次のような状況認知基盤システムが提案されている。
【０００３】
当該システムは、システムソフトウェアとプラットホームソフトウェアとを提供する少なくとも一つのサーバと連動して動作する、状況認知型のユーザシステムである。当該システムは、プラットホームマネジャとプロファイルキャッシュを有する。
【０００４】
プラットホームマネジャは、センサが提供する周辺状況情報に基づいた状況プロファイルによって、ユーザシステムの運用に必要な少なくとも一つのソフトウェアをサーバからダウンロードして管理する。プロファイルキャッシュは、プラットホームマネジャが管理する少なくとも一つのプロファイルを保存する。上記ユーザシステムによれば、一つのユーザシステムを利用して多様な状況に対応できるように、システムのソフトウェア的な構造が自律的に変更・再構成可能であり、ユーザの便利性が高まる。
【０００５】
また、近年ではＵＰｎＰの利用も広まりつつあり、ＵＰｎＰのサービスやコントローラ（「コントロールポイント」ともいう）に関する様々な研究が行われている。
例えば、ＵＰｎＰコントロールポイント装置によって制御されるウェブインタフェースを介して、ローカルエリアネットワーク（例えば、ホームネットワーク）内に位置するサービスおよびメディアコンテンツへのアクセスを提供するためのソリューションが提案されている。当該ソリューションにおいて、ＵＰｎＰ装置は、無許可のアクセスからコンテンツおよびサービスを保護するために、ユーザを認証するように構成されてもよい。
【０００６】
また、サービスを動的に構成して機能拡張し、提供することができるようにするための技術も、いくつか提案されている。
例えば、ある方法によれば、ネットワーク上に第１のサービス記述を広告するとともに、第１のサービス記述が関連づけられた第１のサービスを提供するサービス提供装置において、定義テーブルが準備される。定義テーブルは、具体的には、第２のサービス記述が関連づけられた第２のサービスを利用して第１のサービスを機能拡張するための、条件および呼び出し方法を定義する。
【０００７】
サービス提供装置は、定義テーブルを参照して、条件を満たす第２のサービスを探索する。そして、サービス提供装置は、探索された第２のサービスに関連づけられている第２のサービス記述に基づいて、第１のサービス記述を更新するとともに、ネットワーク上に広告する。さらに、サービス提供装置は、広告された第１のサービスのサービス記述に基づくサービス要求に応答し、第２のサービスを呼び出し、第２のサービスからの応答を受信する。そして、サービス提供装置は、受信された第２のサービスからの応答に基づいて、サービス要求に対する応答を生成する。
【０００８】
また、別の方法によれば、ＵＰｎＰデバイスは、バスに接続された拡張装置から当該拡張装置のサービス記述を取得し、取得されたサービス記述に基づいて自装置のサービス記述を更新し、更新されたサービス記述をネットワーク上に公開する。そして、ＵＰｎＰデバイスは、ＵＰｎＰコントロールポイントからサービス要求を受けると、必要に応じて、サービス要求に基づく制御要求を、該当する拡張装置へ送信し、この拡張装置から制御要求に対する制御応答を受信し、受信した制御応答に基づいてサービス要求に対する応答を生成し、生成した応答をＵＰｎＰコントロールポイントへ送信する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００７−１５７１６５号公報
【特許文献２】特表２０１０−５２５４８３号公報
【特許文献３】特開２００６−９９６７５号公報
【特許文献４】特開２００６−２０２２１０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
近年、様々な電子機器においてソフトウェア制御が採用されており、ソフトウェアのインストールによる機能拡張が実現可能な電子機器の種類も増えてきた。また、ＵＰｎＰの普及も進みつつあり、ＵＰｎＰの多くのサービスは、ソフトウェアを用いて実現される。しかしながら、ＵＰｎＰの分野においては、ソフトウェア制御の柔軟性を活かしてＵＰｎＰのサービスを動的に導入する技術は、まだまだ未発達である。
【００１１】
本発明は、１つの側面では、ＵＰｎＰのサービスの動的な導入を可能とすることを目的とする。
【課題を解決するための手段】
【００１２】
一態様によるサービス提供方法では、指定されたＵＰｎＰのサービスを提供するためのプログラムをインストールするための、ＵＰｎＰの特定のサービスを、端末が探索する。そして、前記特定のサービスを提供するデバイスが、前記端末に応答を返す。また、前記端末が、前記応答により検出される前記特定のサービスに対して、ＵＰｎＰの新規サービスを提供するための新規プログラムの前記デバイスへのインストールに関わる通知であって、前記新規プログラムを受信するための準備を行うよう、前記デバイスに促す当該通知であるインストール関連通知を送信する。さらに、特定の環境に前記デバイスが存在しているとき、検出装置が、前記デバイスが前記特定の環境下にあることを示す検出通知を送信する。そして、前記新規サービスを指定するサービス指定情報および前記特定の環境と対応づけて前記新規プログラムを格納する管理部が、前記検出通知の受信に応じて、前記新規プログラムを前記デバイスに送信する。また、前記デバイスが、前記特定のサービスを提供するための特定のプログラムにしたがって動作することによって、前記インストール関連通知の受信の後に前記管理部から前記新規プログラムを受信して取得するとともに取得した前記新規プログラムを前記デバイスにインストールする。そして、前記デバイスが、インストールした前記新規プログラムにしたがって動作することにより、前記新規サービスを前記端末に提供する。
【発明の効果】
【００１３】
上記サービス提供方法によれば、デバイスは、端末による探索に応じて、ＵＰｎＰの新規サービスを端末に提供することができる。すなわち、上記サービス提供方法によれば、ＵＰｎＰのサービスが動的にデバイスに導入される。
【図面の簡単な説明】
【００１４】
【図１】第１実施形態の動作シーケンス図である。
【図２】第１実施形態のシステム構成図である。
【図３】サービス更新サービスのインストールされたデバイスに関するデバイス定義ファイルの例である。
【図４】サービス更新サービスのサービス定義ファイルの例である。
【図５】端末とデバイスの間で送受信されるメッセージの例である。
【図６】サービス追加・更新コマンドの受信に応じて第１実施形態のデバイスが行う処理のフローチャートである。
【図７】第２実施形態の動作シーケンス図である。
【図８】第２実施形態のシステム構成図である。
【図９】第２実施形態の条件テーブルの例である。
【図１０】コントローラ更新サービスのインストールされた端末に関するデバイス定義ファイルの例である。
【図１１】コントローラ更新サービスのサービス定義ファイルの例である。
【図１２】第２実施形態の端末が行う処理のフローチャートである。
【図１３】第３実施形態の動作シーケンス図である。
【図１４】第３実施形態のシステム構成図である。
【図１５】第３実施形態の条件テーブルの例である。
【図１６】第３実施形態のデバイステーブルの例である。
【図１７】デバイスまたは端末からの受信開始通知に応じて第３実施形態のサーバが行う処理のフローチャートである。
【図１８】センサからの通知に応じて第３実施形態のサーバが行う処理のフローチャートである。
【図１９】受信準備コマンドに応じて第３実施形態のデバイスが行う処理のフローチャートである。
【図２０】第４実施形態の動作シーケンス図である。
【図２１】第４実施形態のシステム構成図である。
【図２２】第４実施形態の条件テーブルの例である。
【図２３】第４実施形態の端末テーブルの例である。
【図２４】端末からの受信開始通知に応じて第４実施形態のサーバが行う処理のフローチャートである。
【図２５】センサからの通知に応じて第４実施形態のサーバが行う処理のフローチャートである。
【図２６】第４実施形態の端末が行う処理のフローチャートである。
【図２７】第５実施形態の動作シーケンス図である。
【図２８】第５実施形態のシステム構成図である。
【図２９】第５実施形態の条件テーブルの例である。
【図３０】第５実施形態の端末テーブルの例である。
【図３１】サービスとコントローラ双方の更新機能を持つ更新サービスがインストールされた端末に関するデバイス定義ファイルの例である。
【図３２】サービスとコントローラ双方の更新機能を有する更新サービスについてのサービス定義ファイルの例である。
【図３３】端末からの受信開始通知に応じて第５実施形態のサーバが行う処理のフローチャート（１／３）である。
【図３４】端末からの受信開始通知に応じて第５実施形態のサーバが行う処理のフローチャート（２／３）である。
【図３５】端末からの受信開始通知に応じて第５実施形態のサーバが行う処理のフローチャート（３／３）である。
【図３６】センサからの通知に応じて第５実施形態のサーバが行う処理のフローチャート（１／２）である。
【図３７】センサからの通知に応じて第５実施形態のサーバが行う処理のフローチャート（２／２）である。
【図３８】第５実施形態の端末が事前に行う処理のフローチャートである。
【図３９】第５実施形態の端末がサーバからのデータの受信に応じて行う処理のフローチャートである。
【図４０】情報処理装置の構成図である。
【発明を実施するための形態】
【００１５】
以下、第１〜第５実施形態について、図面を参照しながら詳細に説明する。第１および第３実施形態は、ＵＰｎＰのサービスの動的な更新に関連し、第２および第４実施形態は、ＵＰｎＰのコントローラ（すなわちコントロールポイント）の動的な更新に関連する。また、第５実施形態は、ＵＰｎＰのサービスとコントローラ双方の動的な更新に関連する。以下に説明するとおり、第１〜第５実施形態のいずれによっても、ＵＰｎＰの一層柔軟な利用が可能となる。
【００１６】
なお、説明の便宜上、第１〜第４実施形態に関しては、サービスを提供する装置を「デバイス」といい、コントローラとして動作する装置を「端末」という。また、詳しくは後述するとおり、第５実施形態では、２台の装置のどちらにサービスがインストールされどちらにコントローラがインストールされるかは環境に応じて動的に決まる。そのため、第５実施形態に関しては、２台の装置をともに「端末」という。しかし、これらの「デバイス」および「端末」という名称は、説明の便宜上のものにすぎない。
【００１７】
さて、図１は、第１実施形態の動作シーケンス図である。また、図２は、第１実施形態のシステム構成図である。図２に示すように、第１実施形態のシステム１００は、端末１１０とデバイス１２０とサービス管理装置１３０を含む。システム１００内には、端末１１０以外の端末がさらにあってもよい。図１は、図２の端末１１０、デバイス１２０、およびサービス管理装置１３０、ならびに図２には不図示の端末１４０による動作シーケンスの例を示す。
【００１８】
端末１１０は、通信機能とＵＰｎＰのコントローラ機能を有する端末であれば、どのような種類の端末であってもよい。例えば、端末１１０は、携帯電話、スマートフォン、タブレット端末、ＰＤＡ（Personal Digital Assistant）、ノートＰＣ（Personal Computer）のような携帯端末であってもよいし、デスクトップＰＣであってもよい。端末１４０も端末１１０と同様である。
【００１９】
デバイス１２０は、通信機能とＵＰｎＰのサービス提供機能を有する装置であり、製造工場からの出荷後にソフトウェアをインストールすることの可能な装置である。例えば、携帯電話、スマートフォン、タブレット端末、ＰＤＡ、ノートＰＣ、デスクトップＰＣなどがデバイス１２０として使われることもある。あるいは、組み込み型コンピュータを有するその他の種類の装置（例えば、プリンタ、プロジェクタ、テレビ、録画装置、照明装置など）がデバイス１２０として使われてもよい。
【００２０】
端末１１０とデバイス１２０は、ネットワークを介して互いに通信することができる。同様に、端末１４０とデバイス１２０も、ネットワークを介して互いに通信することができる。
【００２１】
サービス管理装置１３０は、例えば、ネットワークを介してデバイス１２０と通信可能なコンピュータであってもよい。あるいは、端末１１０がサービス管理装置１３０を含んでいてもよい。
【００２２】
端末１１０とデバイス１２０とサービス管理装置１３０のさらなる詳細は、後ほど図２を参照して説明することにして、先に図１の動作シーケンスについて説明する。図１の動作シーケンスは、例えば、「端末１１０が何らかのＵＰｎＰのサービスを利用しようとしたのに、当該サービスを提供するデバイスが見つからなかった」という場合などに実行される。
【００２３】
例えば、端末１１０のユーザは、ドキュメント表示サービスを利用したいかもしれない。すると、ユーザは、ドキュメント表示サービスを提供するデバイスを探索するよう端末１１０に指示するための入力を端末１１０に与える。端末１１０は、ユーザからの入力にしたがって、ドキュメント表示サービスを提供するデバイスを探索する。
【００２４】
しかし、端末１１０の周囲には、ドキュメント表示サービスを提供するデバイスが存在しなかったとする。すると、端末１１０は、図１のステップＳ１０１の探索を実行する。以下のステップＳ１０１〜Ｓ１１２の説明から明らかなとおり、図１の処理により、端末１１０は、「プログラムをインストールすることによって、新たにドキュメント表示サービスを提供することが可能になるデバイスが周囲に存在するか否か」を確認する。そして、もしそのようなデバイスが見つかれば、端末１１０は、見つかったデバイスに対して、「ドキュメント表示サービスのプログラムをインストールして、ドキュメント表示サービスを提供せよ」と命令する。その結果、端末１１０は、ドキュメント表示サービスを利用することが可能となる。
【００２５】
図１の処理は、以上のようにして所望のサービスを端末１１０で利用可能とするために、行われてもよい。もちろん、上記の「端末１１０が何らかのＵＰｎＰのサービスを利用しようとしたのに、当該サービスを提供するデバイスが見つからなかった」という場合以外の場合に、図１の処理が行われてもよい。つまり、図１の処理が開始されるトリガは、特に限定されない。
【００２６】
具体的には、まずステップＳ１０１で、端末１１０がＵＰｎＰの特定のサービスを探索する。以下では説明の便宜上、この「特定のサービス」を「サービス更新サービス」という。サービス更新サービスは、指定されたＵＰｎＰのサービスを提供するためのプログラムをインストールするための、ＵＰｎＰのサービスである。
【００２７】
サービス更新サービスに対してインストール対象として指定されるサービスは、今まで存在しなかった全く新たなサービスであってもよいし、既存のサービスをアップグレードした新たなバージョンのサービスであってもよい。つまり、サービス更新サービスは、全く新たなサービスを追加するために使われることもあるし、既存のサービス更新するために使われることもある。なお、既存のサービスを更新することは、換言すれば、既存のサービスを新規サービスで上書きすることである。つまり、既存のサービスの更新も、広い意味では新規サービスの導入と見なせる。よって、以下では、追加と更新を特に区別しないことがある。
【００２８】
また、サービス更新サービスは、指定されたＵＰｎＰのサービスを提供するためのプログラムをアンインストールするための機能を、さらに有していてもよい。つまり、サービス更新サービスは、既存のサービスの削除するための機能を有していてもよい。
【００２９】
ステップＳ１０１における探索は、ＵＰｎＰのディスカバリプロトコルであるＳＳＤＰ（Simple Service Discovery Protocol）にしたがって行われる。具体的には、ステップＳ１０１で端末１１０は、M-searchメッセージを送信する。M-searchメッセージの送信は、具体的には、ネットワーク内へのマルチキャストである。
【００３０】
図１の例では、デバイス１２０がサービス更新サービスを提供しているものとする。したがって、ステップＳ１０２で、デバイス１２０が端末１１０に応答を返す。ステップＳ１０２の応答は、具体的には、ＨＴＴＰ（Hypertext Transfer Protocol）応答である。ステップＳ１０２でのＨＴＴＰ応答は、「ＯＫ」という意味を示す「２００」というステータスコードを含む。ステップＳ１０２の応答の具体例は、後述の図５に示す。
【００３１】
端末１１０は、ステップＳ１０２の応答を受信すると、次に、ステップＳ１０３〜Ｓ１０６に示すとおり、ＵＰｎＰのディスクリプションプロトコルにしたがって、デバイス１２０の詳細な情報を取得する。
【００３２】
具体的には、ステップＳ１０３で端末１１０が、デバイス１２０のデバイス定義（device description）を要求する。ステップＳ１０３での要求は、具体的には、ＧＥＴメソッドが指定されたＨＴＴＰ要求である。
【００３３】
デバイス１２０は、ステップＳ１０３の要求を受信すると、ステップＳ１０４で、デバイス定義ファイルを端末１１０に送信する。デバイス定義ファイルは、ＸＭＬ（Extensible Markup Language）形式で記述されており、デバイス１２０が提供するサービスについての情報を含む。上記のとおりデバイス１２０はサービス更新サービスを提供しているので、ステップＳ１０４で送信されるデバイス定義ファイルは、サービス更新サービスにアクセスするための情報を含む。
【００３４】
したがって、端末１１０は、デバイス定義ファイルを受信すると、サービス更新サービスにアクセスするための情報を得ることができる。そこで、端末１１０は、次のステップＳ１０５で、サービス更新サービスのサービス定義（service description）を要求する。ステップＳ１０５での要求も、具体的には、ＧＥＴメソッドが指定されたＨＴＴＰ要求である。
【００３５】
デバイス１２０は、ステップＳ１０５の要求を受信すると、ステップＳ１０６で、サービス更新サービスのサービス定義ファイルを端末１１０に送信する。サービス定義ファイルもＸＭＬ形式で記述されている。また、サービス更新サービスのサービス定義ファイルでは、サービス更新サービスを利用するために使われる制御メッセージ（「アクション」ともいう）の、名前や引数などが定義されている。
【００３６】
以上のようにして、端末１１０は、デバイス１２０により提供されるサービス更新サービスを検出することができる。そして、端末１１０は、検出したサービス更新サービスに対して、ステップＳ１０７でコマンドを送信する。
【００３７】
具体的には、ステップＳ１０７においてコマンドは、ＵＰｎＰのコントロールプロトコルであるＳＯＡＰ（もとはSimple Object Access Protocolの略だが今は何かの略語ではない）によって送信される。ステップＳ１０７のコマンドは、端末１１０が利用しようとしたものの見つけられなかった新規サービス（上記の例ではドキュメント表示サービス）のインストールをデバイス１２０に命じるためのコマンドである。ステップＳ１０７のＳＯＡＰコマンドの具体例は、後述の図５に示す。
【００３８】
ところで、上記のように、新規サービスのインストールは、既存の古いサービスの置き換えによる更新のために行われることもあるし、全く新規のサービスの追加のために行われることもある。よって、図１のステップＳ１０７には「サービス追加・更新コマンド」と書いてあるが、上記のとおり、更新の処理と追加の処理は同様である。
【００３９】
デバイス１２０は、ステップＳ１０７のコマンドを受信すると、次のステップＳ１０８で端末１１０に応答を返す。ステップＳ１０８での応答は、具体的には、「ＯＫ」という意味を示す「２００」というステータスコードを含むＨＴＴＰ応答である。
【００４０】
デバイス１２０は、さらにステップＳ１０９で、サービス管理装置１３０にサービスを要求する。より具体的には、デバイス１２０は、ＳＯＡＰコマンドにおいて端末１１０により指定された新規サービスを提供するためのプログラムの送信を、サービス管理装置１３０に要求する。
【００４１】
ステップＳ１０７のＳＯＡＰコマンドには、端末１１０が利用しようとする新規サービスを指定するサービス指定情報が含まれている。よって、デバイス１２０は、ステップＳ１０９で当該サービス指定情報をサービス管理装置１３０に通知することができる。つまり、デバイス１２０は、サービス指定情報の通知により、上記サービス指定情報で識別される新規サービスのプログラムの送信をサービス管理装置１３０に要求する。
【００４２】
すると、次のステップＳ１１０でサービス管理装置１３０は、ステップＳ１０９で要求されたサービス（より具体的には、当該サービスを提供するためのプログラムを含むデータ）を、デバイス１２０に送信する。デバイス１２０は、こうしてサービス管理装置１３０からプログラムを受信することにより、インストール対象のプログラムを取得する。
【００４３】
そして、ステップＳ１１１でデバイス１２０は、取得したプログラムをデバイス１２０自身にインストールする。その結果、デバイス１２０は、新規サービスを提供することができるようになる。
【００４４】
また、プログラムのインストールにより、デバイス１２０が提供するサービスが追加または更新されるので、デバイス１２０は、デバイス定義ファイルを書き換える。デバイス１２０は、追加または更新されたサービスのサービス定義ファイルも保存する。
【００４５】
また、ステップＳ１１２でデバイス１２０は、新規サービスの提供が可能になったこと（すなわちサービス追加・更新イベントの発生）を通知する。ステップＳ１１２での通知は、ＵＰｎＰのイベント通知プロトコルであるＧＥＮＡ（General Event Notification Architecture）にしたがって行われる。もしくは、ステップＳ１１２での通知は、ＵＰｎＰ１．１より導入されたプロトコルであるMulticast Eventingを用いてもよい。ＧＥＮＡを用いてイベントを通知する場合は、後述するように、予め所定のプロトコルにしたがい、端末がデバイスに対して購読要求（subscription request）を通知しておく必要がある。Multicast Eventingを用いる場合は、事前に端末によるデバイスへの購読要求通知を行う必要はない。以下の例でＧＥＮＡにより行っているイベント通知は、ＵＰｎＰ１．１以降では、Multicast Eventingに置き換えてもよい。
【００４６】
図１の例では、ステップＳ１１２でデバイス１２０がサービス追加・更新イベントの通知をＧＥＮＡのプロトコルにしたがって通知する。よって、端末１１０だけでなく端末１４０も、デバイス１２０が新規サービスの提供を開始したことを認識することができる。
【００４７】
また、図１には示されていないが、上記のようにしてデバイス１２０が新規サービスの提供を開始した後、端末１１０は、ステップＳ１０３〜Ｓ１０４と同様にしてデバイス１２０のデバイス定義ファイルを再度取得する。こうして取得されるデバイス定義ファイルは、ステップＳ１１１で更新されたものであり、インストールされた新規サービスにアクセスするための情報を含む。
【００４８】
したがって、端末１１０は、ステップＳ１０５〜Ｓ１０６と同様にして、新規サービスについてのサービス定義ファイルを取得することができる。そして、端末１１０は、取得したサービス定義ファイルに定義されている制御メッセージを、適宜ステップＳ１０７と同様にしてＳＯＡＰによりデバイス１２０に送信することで、新規サービスを利用することができる。もちろん、端末１４０も同様にして、デバイス１２０の新規サービスを利用することができる。
【００４９】
続いて、図２を参照して、端末１１０とデバイス１２０とサービス管理装置１３０の詳細について説明する。
図２に示すように、端末１１０には、ＵＰｎＰコントローラ１１１が実装されている。ＵＰｎＰコントローラ１１１は、サービス更新サービスに対して制御メッセージ（つまりコマンド）を与える機能を有する、ＵＰｎＰのコントローラである。図１に示した端末１１０の動作は、具体的にはＵＰｎＰコントローラ１１１により実行される。
【００５０】
また、デバイス１２０は、ＵＰｎＰサービス提供部１２１を含む。ＵＰｎＰサービス提供部１２１は、サービス更新サービス１２２を提供する。図１のステップＳ１０９の要求、ステップＳ１１０の受信、ステップＳ１１１のインストール、およびステップＳ１１２の通知は、具体的には、サービス更新サービス１２２により行われる。つまり、デバイス１２０は、サービス更新サービス１２２を提供するためのプログラムを実行することにより、ステップＳ１０９〜Ｓ１１２の処理を行う。
【００５１】
なお、図２には、図１のステップＳ１１１でインストールされる新規サービス１２３が破線で示されている。新規サービス１２３のプログラムのインストール後には、ＵＰｎＰサービス提供部１２１は、新規サービス１２３も提供することが可能である。また、ＵＰｎＰコントローラ１１１は、サービス更新サービス１２２に対して制御メッセージを与える機能だけでなく、新規サービス１２３に対して制御メッセージを与える機能を有していてもよい。
【００５２】
さて、サービス管理装置１３０は格納部１３１を有する。格納部１３１には、新規サービス１２３を提供するためのプログラムである新規サービスプログラム１３２が、新規サービス１２３を識別する情報と対応づけられて、格納されている。新規サービスプログラム１３２は、図１のステップＳ１１０でデバイス１２０に送信され、ステップＳ１１１でデバイス１２０にインストールされる。そして、インストールの結果として、デバイス１２０は新規サービス１２３の提供を開始する。
【００５３】
なお、簡単化のため、図１には１つの新規サービスプログラム１３２のみが示されている。しかし、格納部１３１は、複数のサービスそれぞれのプログラムを、当該サービスを識別する情報と対応づけて格納していてもよい。つまり、格納部１３１は、様々なサービスを提供するための各種プログラムのレポジトリであってもよい。
【００５４】
続いて、図３〜５を参照して、第１実施形態で使われるファイルとメッセージの例について説明する。図３は、サービス更新サービス１２２のインストールされたデバイス１２０に関するデバイス定義ファイルの例である。図４は、サービス更新サービス１２２のサービス定義ファイルの例である。また、図５は、端末１１０とデバイス１２０の間で送受信されるメッセージの例である。
【００５５】
図３のデバイス定義ファイル１５０は、新規サービス１２３を提供するための新規サービスプログラム１３２が図１のステップＳ１１１でインストールされるのにともなって更新された、デバイス定義ファイルの具体例である。なお、図３には参照の便宜のため、左側に行番号が示してある。図４などの他のいくつかの図においても、同様の行番号が示してある。
【００５６】
ＵＰｎＰのデバイス定義ファイルの一般的な形式は公知である。よって、デバイス定義ファイル１５０のうちサービス更新サービス１２２と直接関係しない部分については、適宜、説明を省略または簡略化する。
【００５７】
５〜９行目には、デバイス１２０全体に関する情報（例えば、９行目のＵＤＮ（Unique Device Name）など）が記載されている。そして、１０〜２５行目には、デバイス１２０が提供するサービスのリストが記載されている。
【００５８】
デバイス定義ファイル１５０の例では、１０〜２５行目のリストには、２つのサービスの情報が記載されている。具体的には、１１〜１７行目には、サービス更新サービス１２２の情報が記載されている。そして、１８〜２４行目には、サービス更新サービス１２２によってデバイス１２０にインストールされたドキュメント表示サービス（つまり、図２の新規サービス１２３の具体例）の情報が記載されている。
【００５９】
１１〜１７行目に記載されているサービス更新サービス１２２に関する情報は、具体的には以下の情報を含む。
１２行目には、サービス更新サービス１２２の種類が記載されている。また、１３行目には、サービス更新サービス１２２のＩＤ（identifier）が記載されている。
【００６０】
１４行目には、サービス更新サービス１２２のサービス定義ファイル（例えば図４のサービス定義ファイル１５１）のある場所のＵＲＩ（Uniform Resource Identifier）が記載されている。例えば図１のステップＳ１０４で端末１１０は、デバイス定義ファイル１５０を取得することで、１４行目から、サービス更新サービス１２２のサービス定義ファイル１５１のＵＲＩを認識することができる。端末１１０は、デバイス定義ファイル１５０の１４行目のＵＲＩを指定してステップＳ１０５の要求を送信することで、ステップＳ１０６でサービス定義ファイル１５１を取得することができる。
【００６１】
また、例えば図１のステップＳ１０７のＳＯＡＰコマンドのように、何らかの制御メッセージがサービス更新サービス１２２に送信されることがある。１５行目には、このようなサービス更新サービス１２２に対する制御メッセージの宛先のＵＲＩが記載されている。つまり、端末１１０は、デバイス定義ファイル１５０から、ステップＳ１０７のＳＯＡＰコマンドをどこに宛てて送信すればよいかを認識することができる。
【００６２】
また、端末１１０は、サービス更新サービス１２２の状態変数（state variable）が変化したときにＧＥＮＡによるイベント通知を受け取れるようにするために、購読要求（subscription request）をサービス更新サービス１２２に送信してもよい。もちろん、端末１４０も同様に、購読要求を送信してもよい。１６行目には、購読要求の宛先のＵＲＩが記載されている。
【００６３】
例えば、図１の例では、サービス更新サービス１２２は、ステップＳ１０７のコマンドを送信した端末１１０を、サービス更新サービス１２２の特定の状態変数（具体的には、後述の状態変数UpdateTime）の購読を要求したものと見なす。また、図１の例では、端末１４０も、予めデバイス１２０に対して、状態変数UpdateTimeの購読を要求していたものと仮定する。そのため、図１の例では、ステップＳ１１２で、ＧＥＮＡによる通知が端末１１０と端末１４０に送信されている。
【００６４】
デバイス定義ファイル１５０においては、以上説明した１２〜１６行目の情報が、１１行目と１７行目のタグにはさまれている。したがって、端末１１０は、デバイス定義ファイル１５０の１１〜１７行目から、サービス更新サービス１２２にアクセスしてサービス更新サービス１２２を利用するための情報を得ることができる。
【００６５】
なお、１８〜２４行目に記載された、ドキュメント表示サービスに関する情報も、１１〜１７行目の情報と同様の形式である。よって、１８〜２４行目についての詳細な説明は省略する。
【００６６】
また、以上の説明から明らかなように、図１のステップＳ１０４で送信される更新前のデバイス定義ファイルは、図３のデバイス定義ファイル１５０の１８〜２４行目がない状態のものである。換言すれば、ステップＳ１１１でのインストールにともなって、図３の１８〜２４行が追加される。
【００６７】
さて、次に図４を参照して、図１のステップＳ１０６で送信される、サービス更新サービス１２２のサービス定義ファイルの詳細について説明する。
なお、説明の都合上、図４には、第１実施形態では使われないアクションや状態変数についての定義も含むサービス定義ファイル１５１が例示されており、これらのアクションや状態変数は、後述の第３実施形態で使われる。具体的には、１９〜２６行目の「Listen」という名前のアクションと、３９〜４２行目の「ServerUri」および「Listening」という状態変数は、第１実施形態では使われず、第３実施形態で使われる。よって、ここでは１９〜２６行目と３９〜４２行目の説明は省略する。また、特に混乱のおそれはないので、以下の第１実施形態の説明における「サービス定義ファイル１５１」という用語は、１９〜２６行目と３９〜４２行目のない状態のサービス定義ファイルを指すものとする。
【００６８】
また、ＵＰｎＰのサービス定義の一般的な形式は公知である。そこで、以下ではサービス定義ファイル１５１の形式についての説明は省略し、サービス定義ファイル１５１の内容について主に説明する。
【００６９】
さて、サービス定義ファイル１５１は、図３のデバイス定義ファイル１５０の１４行目に記載されたＵＲＩで識別される場所（具体的にはデバイス１２０内の記憶装置）に記憶されており、図１のステップＳ１０６で送信される。
【００７０】
４〜３３行目には、サービス更新サービス１２２に関して定義されているアクションのリストが記載されている。
具体的には、５〜１２行目では、サービスの追加および更新用の、「UpdateService」という名前のアクションが定義されている。このアクションは２つの入力引数をとる。
【００７１】
１番目の引数は、「argServiceName」という名前であり、追加または更新の対象のサービスを識別するためのサービス識別情報（例えばＵＲＮ（Uniform Resource Name）などの名前でもよいし、何らかのＩＤでもよい）を表す。また、この「argServiceName」という引数は、後述の「ServiceName」という状態変数と関係しており、具体的には、サービス更新サービス１２２は、「argServiceName」という引数に指定された値を「ServiceName」という状態変数に代入する。
【００７２】
２番目の引数は、「argServiceUri」という名前であり、追加または更新の対象のサービスのデータ（つまりサービスのプログラムを含むデータ）が記憶されている場所を示す。具体的には、ＵＲＩが「argServiceUri」という引数として指定される。例えば、図１のステップＳ１０７のＳＯＡＰコマンドは、具体的には「UpdateService」というアクションを指定する制御メッセージである。そして、ステップＳ１０７では、図２のサービス管理装置１３０の格納部１３１内の新規サービスプログラム１３２が記憶されている場所のＵＲＩが、「argServiceUri」という引数として指定される。
【００７３】
なお、端末１１０にとっては、以上の２つの引数として指定する２つの値は、既知である。
また、１３〜１８行目では、サービスの削除用の、「DeleteService」という名前のアクションが定義されている。なお、「DeleteService」というアクションは省略可能であり、実施形態によっては、サービス更新サービス１２２がサービスの削除機能を持たなくてもよい。
【００７４】
図４の例では、「DeleteService」というアクションは、「argServiceName」という名前の１つの入力引数をとる。この引数は、削除対象のサービスを識別するためのサービス識別情報（例えばサービスの名前）を表す。また、この引数も、後述の「ServiceName」という状態変数と関係しており、具体的には、サービス更新サービス１２２は、「argServiceName」という引数に指定された値を「ServiceName」という状態変数に代入する。
【００７５】
１９〜２６行目の「Listen」という名前のアクションについては、第３実施形態とともに後述する。
２７〜３２行目では、サービス更新サービス１２２によってサービスの追加または更新が行われた最終日時を、端末（例えば端末１１０）が取得するための、「GetUpdateTime」という名前のアクションが定義されている。なお、「GetUpdateTime」というアクションは省略可能である。
【００７６】
図４の例では、「GetUpdateTime」というアクションは、入力引数をとらず、「ResultUpdateTime」という名前の返り値を返す。「ResultUpdateTime」という返り値は、具体的には、後述の「UpdateTime」という状態変数の値である。
【００７７】
また、３４〜４５行目には、サービス更新サービス１２２に関して定義されている状態変数のリストが記載されている。
具体的には、３５〜３６行目には、「ServiceName」という名前の文字列型の状態変数が定義されている。「ServiceName」という状態変数は、サービス更新サービス１２２が最後に追加、更新、または削除したサービスの識別情報（例えばサービスの名前）を示す。
【００７８】
そして、３７〜３８行目には、「ServiceUri」という名前のＵＲＩ型の状態変数が定義されている。「ServiceUri」という状態変数は、サービス更新サービス１２２が最後に追加または更新したサービスのプログラムがどこから取得されたのかを示す。
【００７９】
３９〜４２行目については、第３実施形態とともに後述する。
また、４３〜４４行目には、「UpdateTime」という名前の日付・時刻型の状態変数が定義されている。「UpdateTime」という状態変数は、サービス更新サービス１２２によってサービスの追加または更新が行われた最終日時（以下、追加と更新を区別せず、単に「最終更新日時」という）を示す。
【００８０】
次に、図５を参照して、端末１１０とデバイス１２０の間で送受信されるメッセージの例を説明する。図５の応答１５２は、図１のステップＳ１０２で送信されるＨＴＴＰ応答の具体例であり、図５のＳＯＡＰコマンド１５３は、図１のステップＳ１０７で送信されるＳＯＡＰコマンドの具体例である。
【００８１】
応答１５２の１行目は、ＨＴＴＰのステータスラインである。２行目は、探索対象（ＳＴ：search target）がルートデバイスであることを示す。３行目は、ＵＳＮ（Unique Service Name）を示す。４行目には、応答１５２を返すデバイス１２０のデバイス定義ファイル（具体的には図３のデバイス定義ファイル１５０）のある場所を示すＵＲＩが記載されている。５行目は、応答１５２がＨＴＴＰヘッダのみを含む（つまり、エンティティボディを含まない）ことを示す。
【００８２】
例えば、図１の端末１１０は、ステップＳ１０２で応答１５２を受信すると、応答１５２の４行目のＵＲＩを宛先としてステップＳ１０３でＨＴＴＰ要求を送信する。すると、端末１１０は、ステップＳ１０４で図３のデバイス定義ファイル１５０を取得することができる。
【００８３】
さて、図５に示すように、図１のステップＳ１０７で送信されるＳＯＡＰコマンド１５３は、具体的にはＰＯＳＴメソッドのＨＴＴＰ要求である。
ＳＯＡＰコマンド１５３の１行目は、ＨＴＴＰのリクエストラインである。１行目には、図３のデバイス定義ファイル１５０の１５行目に記載されたＵＲＩが、ＨＴＴＰ要求の宛先として指定されている。
【００８４】
２行目のリクエストヘッダフィールドには、ＳＯＡＰコマンド１５３の宛先のホストであるデバイス１２０の、アドレスとポート番号が指定されている。
３行目は、図３の１１〜１７行目のように定義されるサービス更新サービス１２２に対して、ＳＯＡＰコマンド１５３の送信元の端末１１０が、図４の５〜１２行目のように定義される「UpdateService」というアクションの実行を命令することを示す。
【００８５】
４〜５行目は一般的なＨＴＴＰヘッダフィールドである。７〜１６行目はＨＴＴＰ要求のエンティティボディであり、７〜１６行目に具体的な制御メッセージが記載されている。具体的には、１１〜１４行目において、「UpdateService」というアクションに与える２つの入力引数が指定されている。
【００８６】
図４の５〜１２行目に示すように、「UpdateService」というアクションは、「argServiceName」と「argServiceUri」という２つの引数をとる。ＳＯＡＰコマンド１５３の１２行目では、「argServiceName」という引数の値として、ドキュメント表示サービス（つまり、インストール対象の新規サービス１２３）の名前である「DocViewSrv」という文字列が指定されている。また、１３行目では、「argServiceUri」という引数の値として、ドキュメント表示サービスのデータ（つまり、新規サービスプログラム１３２を含むデータ）が格納された場所のＵＲＩが指定されている。
【００８７】
したがって、図１のステップＳ１０７でＳＯＡＰコマンド１５３を受信したデバイス１２０（より具体的には、デバイス１２０内のサービス更新サービス１２２）は、ＳＯＡＰコマンド１５３の１２〜１３行目から、インストール対象を認識することができる。すなわち、デバイス１２０は、ＳＯＡＰコマンド１５３の１３行目のＵＲＩを宛先として、図１のステップＳ１０９の要求を送信することができる。また、デバイス１２０は、当該要求の中に、インストール対象のサービスを識別するサービス名として、ＳＯＡＰコマンド１５３の１２行目に記載された名前を含めることができる。
【００８８】
ところで、図１のステップＳ１０７でのコマンドの受信から、ステップＳ１１２でのイベント通知までの処理は、デバイス１２０が図６のフローチャートにしたがって動作することにより、実現される。図６は、サービス追加・更新コマンドの受信に応じてデバイス１２０が行う処理のフローチャートである。
【００８９】
まず、ステップＳ２０１で、デバイス１２０のＵＰｎＰサービス提供部１２１が、端末１１０（より具体的には、端末１１０内のＵＰｎＰコントローラ１１１）から、図１のステップＳ１０７のサービス追加・更新コマンドを受信する。図５のＳＯＡＰコマンド１５３の１２〜１３行目に示すように、ステップＳ２０１で受信されるコマンドは、追加または更新の対象であるサービスの名前とＵＲＩを引数とする。ＵＰｎＰサービス提供部１２１は、コマンドを受信すると、図１のステップＳ１０８のとおり、ＨＴＴＰ応答を返す。
【００９０】
また、ＵＰｎＰサービス提供部１２１は、受信されたＳＯＡＰコマンド１５３がサービス更新サービス１２２に対するコマンドであることを、ＳＯＡＰコマンド１５３の１行目から認識することができる。よって、ＵＰｎＰサービス提供部１２１はサービス更新サービス１２２を呼び出す。
【００９１】
すると、次のステップＳ２０２でサービス更新サービス１２２が、通知されたＵＲＩにあるサービス管理装置１３０に対して、通知された名前のサービスを要求する。より具体的には、サービス更新サービス１２２は、ＳＯＡＰコマンド１５３の１３行目に記載されたＵＲＩ（つまり新規サービスプログラム１３２のＵＲＩ）を宛先として、１２行目の名前で識別されるサービスを要求する。ステップＳ２０２の要求は、図１のステップＳ１０９に相当する。なお、ステップＳ２０２の要求は、任意の形式の要求でよく、例えばＨＴＴＰ要求であってもよいし、その他の形式の要求であってもよい。
【００９２】
また、図１のステップＳ１１０に示すように、サービス更新サービス１２２は、要求したサービスのデータを、サービス管理装置１３０から受信する。なお、こうしてステップＳ２０２で受信されるデータは、具体的には、例えば、新規サービスプログラム１３２と、新規サービス１２３のサービス定義ファイルとを含むデータでもよい。
【００９３】
受信後、ステップＳ２０３においてサービス更新サービス１２２は、受信したサービスのデータに基づいて、以下の３つの処理を行う。
第１に、サービス更新サービス１２２は、デバイス１２０のデバイス定義ファイルを更新する。具体的には、例えば、サービス更新サービス１２２は、図３の１８〜２４行目をデバイス定義ファイル１５０に追加し、更新後のデバイス定義ファイル１５０をデバイス１２０の記憶装置に記憶する。
【００９４】
第２に、サービス更新サービス１２２は、受信したサービスのサービス定義ファイルを追加または更新する。全く新規のサービスがデバイス１２０にインストールされる場合は、インストールするサービスのサービス定義ファイルはデバイス１２０内にない。そこで、この場合、サービス更新サービス１２２は、サービス管理装置１３０から受信したデータに基づき、新たなサービス定義ファイルを作成して保存する。また、デバイス１２０にインストール済みの既存のサービスの新規バージョンがデバイス１２０にインストールされる場合（つまり既存のサービスが更新される場合）は、当該既存のサービスのサービス定義ファイルはデバイス１２０内に既にある。そこで、この場合、サービス更新サービス１２２は、サービス管理装置１３０から受信したデータに基づき、既存のサービス定義ファイルを更新する。
【００９５】
第３に、サービス更新サービス１２２は、受信したサービスのプログラム（つまり新規サービスプログラム１３２）をデバイス１２０にインストールする。
サービス更新サービス１２２は、以上の３つの処理をステップＳ２０３で行った後、ステップＳ２０４で、図４の４３行目に示す「UpdateTime」という状態変数の値を現在時刻に更新する。ステップＳ２０３〜Ｓ２０４は、図１のステップＳ１１１に対応する。
【００９６】
そして、次のステップＳ２０５でサービス更新サービス１２２は、ＧＥＮＡにより、デバイス１２０の周辺の端末（例えば、図１では端末１１０と端末１４０）に対して、ステップＳ２０４で更新した「UpdateTime」という状態変数の値を通知する。ステップＳ２０５は図１のステップＳ１１２に対応する。
【００９７】
以上説明した第１実施形態によれば、端末１１０は、たとえ所望のサービスを既に提供しているデバイスを見つけられなくても、所望のサービスをサービス更新サービス１２２に通知することで、所望のサービスを受けられるようになる。なぜなら、サービス更新サービス１２２が、通知されたサービスのプログラム（つまり新規サービスプログラム１３２）をデバイス１２０にインストールし、デバイス１２０が上記所望のサービス（つまり新規サービス１２３）の提供を開始するからである。
【００９８】
このように、第１実施形態によれば、ＵＰｎＰの新規サービスプログラム１３２が動的にデバイス１２０に導入されるので、ユーザの利便性が高まる。以上のような第１実施形態の利点についてさらに詳しく説明すれば、以下のとおりである。
【００９９】
例えば、比較例として、第１のサービスを提供する第１のデバイスが、第２のデバイスが提供する第２のサービスを利用して第１のサービスを拡張し、拡張したサービスを提供する技術を想定する。この比較例では、第１のデバイスはいかようにでもサービスを拡張することができるわけではない。つまり、この比較例において実現可能な機能拡張は、第１のデバイスからアクセス可能な既存の第２のデバイスがどのようなサービスを提供するかによって、限定されてしまう。
【０１００】
また、この比較例における機能拡張では、ユーザが今どのサービスの利用を望んでいるかという、ユーザの要望に柔軟に対応することができない。つまり、この比較例では、第１のデバイスの外部から、ユーザの要望に応じた機能拡張を行うように第１のデバイスに命令することができない。あるいは、たとえユーザの所望するサービスを第１のデバイスに通知することができたとしても、この比較例では、実現可能な機能拡張が限定的なので、ユーザの要望に対処不能なことが多い。
【０１０１】
つまり、この比較例によれば、ＵＰｎＰのサービスの動的な導入あるいは更新が可能ではあるが、非常に限定的である。
他方、あるデバイス（例えばデバイス１２０）が発売された時点では予想されていなかったような、新たなサービスが、新たに生まれることがあり得る。つまり、ユーザが将来どのようなサービスの利用を望むようになるかを、予め知ることはできない。
【０１０２】
また、既存のサービスに関しても、もちろん、世の中のあらゆるデバイスが当該既存のサービスを提供しているわけではない。そして、当該既存のサービスを提供しているデバイスが近くにない状況下で、ユーザが当該既存のサービスを利用したくなることもあり得る。
【０１０３】
したがって、「ユーザがあるサービスを利用したいと思ったときに、当該サービスを既に提供しているデバイスがユーザの近くに存在していない」という状況は、ユーザが望むサービスが全く新規であるか既存のものであるかを問わず、起こり得る。そのような状況下でユーザが所望のサービスを受けられるようにするための、動的なサービスの導入は、ユーザの利便性を高めるうえで非常に有益である。
【０１０４】
ここで、ユーザが、ある任意のサービスの利用を望んだと仮定する。また、ユーザが望んだ当該サービスは、ユーザの近くに存在する既存のデバイス（例えばデバイス１２０）のハードウェア以外の新たなハードウェアを、必要としないものとする。つまり、もし当該既存のデバイスが、ソフトウェアのインストールが可能な種類のものであれば、当該既存のデバイスは、ユーザが望むサービスを提供する潜在的可能性を持っている。
【０１０５】
そして、近年では、汎用的なＰＣのみならず、携帯電話、スマートフォン、タブレット端末、ＰＤＡなどの携帯端末も、製造工場からの出荷後のソフトウェアのインストールが可能である。また、プリンタ、プロジェクタ、テレビ、録画装置、照明装置などの種々の装置も、製造工場からの出荷後のソフトウェアのインストールが可能な種類のものが増えてきた。
【０１０６】
つまり、ソフトウェアのインストールによる機能拡張が可能なデバイスの普及が進んできている。そして、そのようなデバイスの普及により、デバイスが任意のサービスを新たに提供するための基盤は、整いつつある。しかし、そのような基盤は、十分に活用されているとはまだ言い難く、ＵＰｎＰの機能拡張も、上記の比較例のように限定的なレベルにとどまっている。
【０１０７】
それに対し、第１実施形態によれば、予めサービス管理装置１３０に新規サービスプログラム１３２が格納されており、デバイス１２０がサービス更新サービス１２２を提供してさえいれば、ユーザは、端末１１０を介して任意の新規サービス１２３を受けられる。より正確には、ユーザが望む新規サービス１２３が、デバイス１２０の既存のハードウェア以外のハードウェアを必要とせず、ソフトウェアにより実現可能なものであれば、ユーザは端末１１０を介してデバイス１２０から任意の新規サービス１２３を受けられる。
【０１０８】
このように、第１実施形態によれば、非常に柔軟に、ＵＰｎＰのサービスの動的な更新を行うことが可能となる。したがって、第１実施形態は、ユーザの利便性向上に資するところが大きい。
【０１０９】
また、第１実施形態のサービス更新サービス１２２は、ＵＰｎＰのサービスの１種である。サービス更新サービス１２２がＵＰｎＰのサービスであることは、以下のような２つの利点をもたらす。
【０１１０】
第１に、図１のステップＳ１０１〜Ｓ１０８に示すように、端末１１０は、ＵＰｎＰのプロトコルにしたがって、サービス更新サービス１２２に対して新規サービス１２３のインストールを命じることができる。つまり、端末１１０は、新規の特殊なプロトコルを使用する必要がない。
【０１１１】
第２に、サービス更新サービス１２２を多くのデバイス１２０に組み込むことが容易であり、利便性向上に有益なサービス更新サービス１２２の普及が促進される。理由は次のとおりである。
【０１１２】
種々のＯＳ（Operating System）用にＵＰｎＰに関するライブラリが開発されている。そして、ＵＰｎＰに関する機能は、ライブラリを用いて実装されることが多い。ここで、サービス更新サービス１２２はＵＰｎＰのサービスの１種なので、ＵＰｎＰ用のライブラリの中に、サービス更新サービス１２２を実現するためのプログラムモジュール（例えばライブラリ関数）を組み込むことが可能である。
【０１１３】
すると、広く使われるライブラリを介して、多くのデバイス１２０にサービス更新サービス１２２を実装することが可能となる。多くのデバイス１２０においてサービス更新サービス１２２が実装されていれば、図１のステップＳ１０１の探索に対して、サービス更新サービス１２２を提供するデバイス１２０が少なくとも１台は見つかる蓋然性も高まる。その結果、ユーザの利便性も向上する。
【０１１４】
続いて、第２実施形態について説明する。第２実施形態は、コントローラの動的な更新に関する。サービスだけでなくコントローラも動的に更新することが可能であれば、ユーザの利便性が大きく向上する。
【０１１５】
例えば、あるサービスを提供するデバイスが存在する環境において、ユーザは当該サービスを利用したいかもしれないし、または、ユーザの端末で動作するアプリケーションが、当該サービスを利用しようとするかもしれない。しかし、ユーザの端末には、当該サービスに対応するコントローラがインストールされていないかもしれない。この場合、もし端末に動的にコントローラをインストールすることができれば、ユーザは所望のサービスを受けられるようになり、利便性が向上する。
【０１１６】
あるいは、ユーザの周囲には１つまたは複数のデバイスがあり、ユーザはそれらのデバイスがそれぞれどのようなサービスを提供するのかを知らないかもしれない。そこで、ユーザは、周囲のデバイスがどのようなサービスを提供するのかを調べるよう、端末に指示を与えるかもしれない。その結果、ユーザは使いたいサービスを見つけるかもしれないが、見つけたサービスを利用するためのコントローラは、ユーザの端末にはインストールされていないかもしれない。この場合も、もし端末に動的にコントローラをインストールすることができれば、ユーザは所望のサービスを受けられるようになり、利便性が向上する。
【０１１７】
そこで、第２実施形態では、コントローラの動的な更新が行われる。以下、図７〜１２を参照して第２実施形態について詳しく説明する。
図７は、第２実施形態の動作シーケンス図である。また、図８は、第２実施形態のシステム構成図である。図８に示すように、第２実施形態のシステム２００は、端末２１０とデバイス２２０とコントローラ管理装置２３０を含む。システム２００内には端末２１０以外の端末がさらにあってもよい。図７は、以上の端末２１０とデバイス２２０とコントローラ管理装置２３０による動作シーケンスの例を示す。
【０１１８】
端末２１０は、通信機能とＵＰｎＰのコントローラ機能を有し、かつ、ソフトウェアをインストールすることが可能であれば、どのような種類の端末であってもよい。例えば、端末２１０は、携帯電話、スマートフォン、タブレット端末、ＰＤＡ、ノートＰＣのような携帯端末であってもよいし、デスクトップＰＣであってもよい。
【０１１９】
デバイス２２０は、通信機能とＵＰｎＰのサービス提供機能を有していれば、どのようなデバイスでもよい。第１実施形態のデバイス１２０とは異なり、第２実施形態のデバイス２２０は、ソフトウェアのインストールが不可能なものであってもよい。例えば、携帯電話、スマートフォン、タブレット端末、ＰＤＡ、ノートＰＣ、デスクトップＰＣ、プリンタ、プロジェクタ、テレビ、録画装置、照明装置など、様々な装置がデバイス２２０として利用される可能性がある。なお、端末２１０とデバイス２２０は、ネットワークを介して互いに通信することができる。
【０１２０】
コントローラ管理装置２３０は、例えば、ネットワークを介して端末２１０と通信可能なコンピュータであってもよい。あるいは、デバイス２２０がコントローラ管理装置２３０を含んでいてもよい。
【０１２１】
端末２１０とデバイス２２０とコントローラ管理装置２３０のさらなる詳細は、後ほど図８を参照して説明することにして、先に図７の動作シーケンスについて説明する。なお、先に例示したとおり、端末２１０に動的にコントローラをインストールすることができれば好ましい状況はいくつかある。しかし、以下では説明の簡単化のため、次の２つの仮定が成り立つ状況における動作シーケンスについて説明する。
【０１２２】
・ユーザが、ある１つのＵＰｎＰサービスを利用したい旨を示す入力を、端末２１０に与えた。または、端末２１０上で動作するアプリケーションが、ある１つのＵＰｎＰサービスを利用しようとした。
・しかし、上記の「ある１つのＵＰｎＰサービス」（以下では便宜上、「対象サービス」ともいう）に対して制御メッセージを送る機能を持つコントローラは、端末２１０にはインストールされていない。
【０１２３】
さて、図７のステップＳ３０１では、端末２１０が、M-searchメッセージをマルチキャストすることにより、対象サービスを探索する。
図７の例では、デバイス２２０が対象サービスを提供しているものとする。したがって、ステップＳ３０２で、デバイス２２０が端末２１０に応答（具体的には、「ＯＫ」という意味を示す「２００」というステータスコードを含むＨＴＴＰ応答）を返す。
【０１２４】
端末２１０は、ステップＳ３０２の応答を受信すると、次に、ステップＳ３０３でデバイス２２０のデバイス定義を要求する。すると、デバイス２２０は、ステップＳ３０４でデバイス定義ファイルを端末２１０に送信する。
【０１２５】
端末２１０は、デバイス定義ファイルを受信すると、対象サービスにアクセスするための情報を得ることができる。そこで、端末２１０は、次のステップＳ３０５で、対象サービスのサービス定義を要求する。すると、デバイス２２０は、ステップＳ３０６で対象サービスのサービス定義ファイルを送信する。
【０１２６】
なお、ステップＳ３０１〜Ｓ３０６は、図１のステップＳ１０１〜Ｓ１０６と類似なので、上記の説明では詳細を割愛した。また、端末２１０は以上のようにして、デバイス２２０の提供する対象サービスを検出し、対象サービスに関する情報を取得することができる。
【０１２７】
そして、端末２１０は、次のステップＳ３０７で、コントローラ管理装置２３０に対して、対象サービスに対応するコントローラを要求する。ステップＳ３０７の要求は、対象サービスを識別するサービス識別情報（例えばサービスのＩＤまたは名前）を含む。つまり、ステップＳ３０７の要求は、サービス識別情報の通知でもある。また、対象サービスに対応するコントローラとは、具体的には、対象サービスを利用するために対象サービスに対して制御メッセージを送る機能を持つＵＰｎＰのコントローラである。
【０１２８】
ところで、コントローラ管理装置２３０は、１つ以上のサービスのそれぞれに対応するコントローラを実現するプログラムを、当該サービスを識別するサービス識別情報と対応づけて格納している。よって、コントローラ管理装置２３０は、ステップＳ３０７の要求を受信すると、通知されたサービス識別情報を用いて、対象サービスに対応するコントローラを実現するプログラムを検索する。そして、コントローラ管理装置２３０は、検索により見つけたプログラムを、ステップＳ３０８で端末２１０に送信する。
【０１２９】
すると、端末２１０は、対象サービスに対応するコントローラのプログラムを受信する。そして、端末２１０は、ステップＳ３０９で、受信したプログラムを端末２１０自身にインストールする。
【０１３０】
以上のようにして、端末２１０には、所望の対象サービスに対応するコントローラのプログラムが、動的にインストールされる。よって、図７には示されていないが、端末２１０は、今後、インストールされたコントローラから制御メッセージ（具体的にはＳＯＡＰコマンド）を送信することにより、対象サービスを利用することができる。
【０１３１】
続いて、図８を参照して、端末２１０とデバイス２２０とコントローラ管理装置２３０の詳細について説明する。
図８に示すように、端末２１０にはＵＰｎＰ制御部２１１が含まれる。ＵＰｎＰ制御部２１１は、１つ以上のコントローラを含むことができるが、例えば図７のステップＳ３０１の時点では、ＵＰｎＰ制御部２１１は１つもコントローラを含んでいなくてもよい。
【０１３２】
また、端末２１０は、指定されたＵＰｎＰのサービスに対応するコントローラを追加または更新するための、コントローラ更新サービス２１２を提供する。なお、全く新たなコントローラを追加することも、既存のコントローラを新たなバージョンのコントローラに更新することも、コントローラのプログラムのインストールにより同様に実現される。したがって、以下ではコントローラの追加と更新を区別しないことがある。
【０１３３】
また、第２実施形態では、コントローラ更新サービス２１２がＵＰｎＰのサービスとして実装されている。したがって、コントローラ更新サービス２１２は、図８には不図示の他の端末のコントローラから、対象サービスを指定する制御メッセージを受け取ることで、対象サービスを決めてもよい。あるいは、端末２１０のＵＰｎＰ制御部２１１の中に、コントローラ更新サービス２１２を利用するための不図示のコントローラがさらに実装されていてもよい。そして、当該不図示のコントローラが、コントローラ更新サービス２１２に対して、対象サービスを指定する制御メッセージを与えてもよい。
【０１３４】
しかし、実施形態によっては、「コントローラ更新サービス２１２と同様の機能を持つものの、ＵＰｎＰのサービスではない」といったプログラムモジュールが、コントローラ更新サービス２１２の代わりに使われてもよい。
【０１３５】
ところで、図７のステップＳ３０１の探索、ステップＳ３０２の応答の受信、ステップＳ３０３の要求、ステップＳ３０４の受信、ステップＳ３０５の要求、およびステップＳ３０６の受信は、具体的には、コントローラ更新サービス２１２により実行される。また、ステップＳ３０７の要求、ステップＳ３０８の受信、およびステップＳ３０９のインストールも、コントローラ更新サービス２１２により実行される。
【０１３６】
そして、ステップＳ３０９のインストールの結果として、ＵＰｎＰ制御部２１１には、対象サービスに対応する新規コントローラ２１３がインストールされる。図８には、新規コントローラ２１３が破線で示されている。
【０１３７】
また、デバイス２２０は、ＵＰｎＰサービス提供部２２１を含む。ＵＰｎＰサービス提供部２２１は、上記の対象サービスであるサービス２２２を提供する。
さて、コントローラ管理装置２３０は格納部２３１を有する。格納部２３１には、サービス２２２に対応する新規コントローラ２１３を実現するためのプログラムである新規コントローラプログラム２３２が、サービス２２２を識別する情報と対応づけられて、格納されている。
【０１３８】
新規コントローラプログラム２３２は、図７のステップＳ３０８で送信され、ステップＳ３０９で端末２１０にインストールされる。そして、インストールの結果として、端末２１０は、新規コントローラ２１３を介してサービス２２２を利用することができるようになる。
【０１３９】
なお、簡単化のため、図８には１つの新規コントローラプログラム２３２のみが示されている。しかし、格納部２３１は、複数のサービスに対応する複数のコントローラそれぞれのプログラムを格納していてもよい。つまり、格納部２３１は、様々なコントローラのプログラムのレポジトリであってもよい。
【０１４０】
また、コントローラ管理装置２３０は、指定されたサービスに対応するコントローラを決定するコントローラ決定部２３３を含む。コントローラ決定部２３３は、具体的には、条件テーブル２３４を参照することで、指定されたサービスに対応するコントローラを決定する。
【０１４１】
図９に、条件テーブル２３４の具体例を示す。図９に示すように、条件テーブル２３４は、サービスとコントローラを対応づけるテーブルである。なお、図９では、理解を容易にするために、サービスとコントローラがそれぞれ名前で表現されている。しかし、条件テーブル２３４は、例えば、サービスのＩＤとコントローラのＩＤとを対応づけるテーブルであってもよい。ＩＤとしては、例えば、ＵＵＩＤ（Universally Unique Identifier）が利用されてもよい。
【０１４２】
図９の例では、ドキュメント表示サービスにドキュメントページめくりコントローラが対応づけられている。また、照明ＯＮ／ＯＦＦサービスに、照明ＯＮ／ＯＦＦリモコンコントローラが対応づけられている。そして、ビデオ録画サービスに、ビデオリモコンコントローラが対応づけられている。
【０１４３】
したがって、例えば、対象サービス（すなわち図８のサービス２２２）がビデオ録画サービスの場合、図７のステップＳ３０７の要求では、ビデオ録画サービスの識別情報（例えば、名前またはＩＤ）が指定される。すると、コントローラ決定部２３３は、条件テーブル２３４を参照し、指定されたビデオ録画サービスに対応づけられているコントローラを検索する。
【０１４４】
検索の結果、コントローラ決定部２３３は、「端末２１０に送信する対象のプログラムは、ビデオリモコンコントローラのプログラムである」と決定する。コントローラ決定部２３３による決定にしたがって、コントローラ管理装置２３０は、図７のステップＳ３０８で、格納部２３１に格納されているビデオリモコンコントローラのプログラムを送信する。
【０１４５】
以上のように、コントローラ管理装置２３０では、条件テーブル２３４により、各コントローラのプログラムが、対応するサービスの識別情報と対応づけられている。しかし、実施形態によっては、例えば、対応するサービスの識別情報を含むパスで示されるフォルダにコントローラのプログラムを格納するなどの、他の方法による対応づけが採用されてもよい。
【０１４６】
さて、上記のとおり第２実施形態では、図８のコントローラ更新サービス２１２は、ＵＰｎＰのサービスの１種である。よって、コントローラ更新サービス２１２のインストールされた端末２１０に関するデバイス定義ファイルには、コントローラ更新サービス２１２に関する情報が含まれる。また、端末２１０は、デバイス定義ファイルだけでなく、コントローラ更新サービス２１２に関するサービス定義ファイルも格納している。以下、図１０〜１１を参照して、これらのデバイス定義ファイルとサービス定義ファイルの具体例について説明する。
【０１４７】
図１０は、端末２１０に関するデバイス定義ファイルの例である。図１０のデバイス定義ファイル２４０において、５〜９行目には、デバイス２２０全体に関する情報が記載されている。そして、１０〜１８行目には、デバイス２２０が提供するサービスのリストが記載されている。
【０１４８】
デバイス定義ファイル２４０の例では、１０〜１８行目のリストには、１つのサービス（すなわちコントローラ更新サービス２１２）の情報のみが記載されている。具体的には、１２行目に、コントローラ更新サービス２１２の種類が記載されており、１３行目に、コントローラ更新サービス２１２のＩＤが記載されている。また、１４行目には、コントローラ更新サービス２１２のサービス定義ファイルのある場所のＵＲＩが記載されている。
【０１４９】
そして、コントローラ更新サービス２１２は、外部から制御メッセージ（具体的にはＳＯＡＰコマンド）を受け取ることもできる。１５行目には、このようなコントローラ更新サービス２１２に対する制御メッセージの宛先のＵＲＩが記載されている。さらに、１６行目には、コントローラ更新サービス２１２の状態変数についての購読要求の宛先のＵＲＩが記載されている。
【０１５０】
次に、図１１を参照して、コントローラ更新サービス２１２のサービス定義ファイルの詳細について説明する。なお、説明の都合上、図１１には、第２実施形態では使われない状態変数についての定義も含むサービス定義ファイル２４１が例示されている。具体的には、２５〜２６行目の「Listening」という状態変数は、第２実施形態では使われず、第４実施形態で使われる。よって、ここでは２５〜２６行目の説明は省略する。また、特に混乱のおそれはないので、以下の第２実施形態の説明における「サービス定義ファイル２４１」という用語は、２５〜２６行目のない状態のサービス定義ファイルを指すものとする。
【０１５１】
さて、サービス定義ファイル２４１は、図１０のデバイス定義ファイル２４０の１４行目に記載されたＵＲＩで識別される場所（具体的には端末２１０内の記憶装置）に記憶されている。
【０１５２】
４〜１９行目には、コントローラ更新サービス２１２に関して定義されているアクションのリストが記載されている。
具体的には、５〜１２行目では、コントローラの追加および更新用の、「UpdateController」という名前のアクションが定義されている。このアクションは２つの入力引数をとる。
【０１５３】
１番目の引数は、「argServiceName」という名前であり、追加または更新の対象のコントローラに対応するサービスを識別するための識別情報（例えばサービスの名前）を表す。また、この「argServiceName」という引数は、後述の「ServiceName」という状態変数と関係しており、具体的には、コントローラ更新サービス２１２は、「argServiceName」という引数に指定された値を「ServiceName」という状態変数に代入する。
【０１５４】
２番目の引数は、「argServerUri」という名前であり、追加または更新の対象のコントローラのデータ（つまりコントローラのプログラムを含むデータ）が記憶されている場所を示す。具体的には、コントローラ管理装置２３０のＵＲＩが、「argServerUri」という引数として指定される。なお、端末２１０にとって当該ＵＲＩは既知である。
【０１５５】
また、１３〜１８行目では、コントローラ削除用の、「DeleteController」という名前のアクションが定義されている。なお、「DeleteController」というアクションは省略可能であり、実施形態によっては、コントローラ更新サービス２１２がコントローラの削除機能を持たなくてもよい。
【０１５６】
図１１の例では、「DeleteController」というアクションは、「argServiceName」という名前の１つの入力引数をとる。この引数は、削除対象のコントローラに対応するサービスを識別するための識別情報（例えばサービスの名前）を表す。また、この引数も、「ServiceName」という状態変数と関係しており、具体的には、コントローラ更新サービス２１２は、「argServiceName」という引数に指定された値を「ServiceName」という状態変数に代入する。
【０１５７】
また、２０〜２７行目には、コントローラ更新サービス２１２に関して定義されている状態変数のリストが記載されている。
具体的には、２１〜２２行目には、「ServiceName」という名前の文字列型の状態変数が定義されている。「ServiceName」という状態変数は、コントローラ更新サービス２１２が最後に追加、更新、または削除したコントローラに対応するサービスの識別情報（例えばサービスの名前）を示す。
【０１５８】
そして、２３〜２４行目には、「ServerUri」という名前のＵＲＩ型の状態変数が定義されている。「ServerUri」という状態変数は、コントローラ更新サービス２１２が最後に追加、更新、または削除したコントローラのプログラムがどこから取得されたのかを示す。
【０１５９】
２５〜２６行目については、第４実施形態とともに後述する。
ところで、図７のステップＳ３０１〜Ｓ３０９までの処理は、端末２１０が図１２のフローチャートにしたがって動作することにより、実現される。
【０１６０】
まず、ステップＳ４０１で、コントローラ更新サービス２１２が、図７のステップＳ３０１のようなM-searchメッセージのマルチキャストにより、端末２１０の周辺にあるデバイスのＵＰｎＰサービス（つまり、上記の対象サービス）を検索する。上記のとおり、対象サービスは、何らかの方法により決められているものとする。
【０１６１】
もし、例えばデバイス２２０のように、対象サービスを提供するデバイスがあれば、コントローラ更新サービス２１２は図７のステップＳ３０２のような応答を受信する。この場合、コントローラ更新サービス２１２はさらに、図７のステップＳ３０３〜Ｓ３０６のようにして、対象サービスを提供するデバイスのデバイス定義ファイルと、対象サービスのサービス定義ファイルを取得する。
【０１６２】
次に、ステップＳ４０２でコントローラ更新サービス２１２は、ステップＳ４０１で検索したＵＰｎＰサービス（つまり対象サービス）を提供するデバイスが発見されたか否かを判断する。
【０１６３】
ステップＳ４０１でのM-searchメッセージの送信から所定の時間が経過しても、ステップＳ３０２のような応答が１つも受信されない場合、コントローラ更新サービス２１２は、「対象サービスを提供するデバイスは発見されなかった」と判断する。そして、対象サービスを提供するデバイスが発見されなかった場合、図１２の処理は終了する。つまり、この場合は新規コントローラ２１３のインストールは行われない。
【０１６４】
逆に、ステップＳ３０２のような応答が得られて、デバイス定義ファイルとサービス定義ファイルが取得されていれば、対象サービスを提供するデバイスが存在する。よって、この場合、コントローラ更新サービス２１２は、「対象サービスを提供するデバイスが発見された」と判断する。そして、図１２の処理はステップＳ４０３へと移行する。
【０１６５】
ステップＳ４０３でコントローラ更新サービス２１２は、コントローラ管理装置２３０に対して、発見したＵＰｎＰサービス（つまり対象サービス）の情報（例えば名前やＩＤなどの識別情報）を通知して、対象サービスに対応するコントローラを要求する。ステップＳ４０３での要求は、図７のステップＳ３０７に対応する。そして、図７のステップＳ３０８に示すように、コントローラ更新サービス２１２は、コントローラ管理装置２３０から、対象サービスに対応するコントローラのデータ（具体的には、図８の新規コントローラプログラム２３２を含むデータ）を受信する。
【０１６６】
最後に、ステップＳ４０４でコントローラ更新サービス２１２は、受信したコントローラのプログラムを端末２１０にインストールする。その結果、ＵＰｎＰ制御部２１１は、サービス２２２を利用するための新規コントローラ２１３が存在する状態となる。したがって、端末２１０のユーザは、端末２１０から所望のサービス２２２を利用することが可能となる。
【０１６７】
以上説明した第２実施形態によれば、端末２１０には、必要に応じてコントローラがインストールされる。したがって、対応するコントローラが端末２１０にプレインストールされていないようなサービスであっても、端末２１０から利用可能である。つまり、第２実施形態には、端末２１０のユーザが使えるサービスを増やすことで、ユーザの利便性を向上させる効果がある。
【０１６８】
また、第２実施形態のコントローラ更新サービス２１２はＵＰｎＰのサービスなので、ＵＰｎＰ用のライブラリの中に、コントローラ更新サービス２１２を実現するためのプログラムモジュール（例えばライブラリ関数）を組み込むことが可能である。すると、広く使われるライブラリを介して、多くの端末２１０にコントローラ更新サービス２１２を実装することが可能となる。すなわち、コントローラ更新サービス２１２がＵＰｎＰのサービスであることは、利便性の向上に有益なコントローラ更新サービス２１２の普及を促進する効果がある。
【０１６９】
続いて、第３実施形態について説明する。第３実施形態は、サービスの更新に関する点において第１実施形態と共通である。しかし、第１実施形態では、端末１１０からのサービス追加・更新コマンドが、デバイス１２０におけるサービスのインストールのトリガであるのに対して、第３実施形態では、デバイスが特定の環境に入ることがインストールのトリガである。
【０１７０】
すなわち、第３実施形態によれば、デバイスが存在する環境に応じて、当該環境で使われるサービス（あるいは当該環境に適したサービス）が、デバイスにインストールされる。以下、図１３〜１９を参照して第３実施形態について詳しく説明する。
【０１７１】
図１３は、第３実施形態の動作シーケンス図である。また、図１４は、第３実施形態のシステム構成図である。図１４に示すように、第３実施形態のシステム３００は、端末３１０とデバイス３２０とサーバ３３０とセンサ３４０を含む。システム３００内には、端末３１０以外の端末がさらにあってもよく、センサ３４０以外のセンサがさらにあってもよい。図１３は、図１４の端末３１０、デバイス３２０、サーバ３３０、およびセンサ３４０、ならびに図１４には不図示の端末３５０による動作シーケンスの例を示す。
【０１７２】
端末３１０は、通信機能とＵＰｎＰのコントローラ機能を有する端末であれば、どのような種類の端末であってもよい。例えば、端末３１０は、携帯電話、スマートフォン、タブレット端末、ＰＤＡ、ノートＰＣのような携帯端末であってもよいし、デスクトップＰＣであってもよい。端末３５０も端末３１０と同様である。
【０１７３】
デバイス３２０は、通信機能とＵＰｎＰのサービス提供機能を有する装置であり、製造工場からの出荷後にソフトウェアをインストールすることの可能な装置である。より具体的には、デバイス３２０は、第１実施形態と類似のサービス更新サービス３２２を提供する。また、例えば、携帯電話、スマートフォン、タブレット端末、ＰＤＡ、ノートＰＣ、デスクトップＰＣ、プリンタ、プロジェクタ、テレビ、録画装置、照明装置などの様々な装置が、デバイス３２０として利用される可能性がある。なお、端末３１０とデバイス３２０は、ネットワークを介して互いに通信することができる。
【０１７４】
サーバ３３０は、ネットワークを介した通信が可能なコンピュータである。後述するとおり、第３実施形態では、ある種の通知が、デバイス３２０からサーバ３３０に送信されてもよいし、端末３１０からサーバ３３０に送信されてもよい。また、別の通知が、センサ３４０からサーバ３３０に送信されてもよいし、端末３１０からサーバ３３０に送信されてもよい。サーバ３３０は、ネットワーク（例えばインターネット）を介して各種通知を適宜受信することができるものとする。
【０１７５】
また、センサ３４０は、１種の検出装置である。具体的には、デバイス３２０が特定の環境に存在する場合に、センサ３４０は、デバイス３２０が特定の環境に存在することを示す検出通知を送信する。
【０１７６】
センサ３４０は、特定の環境に予め設置されていてもよい。例えば、上記「特定の環境」が、特定の建物の特定の部屋である場合、当該特定の部屋に予め設置された、無線ＬＡＮ（Local Area Network）アクセスポイントやＲＦＩＤ（Radio Frequency Identification）リーダなどの装置が、センサ３４０として使われてもよい。
【０１７７】
例えば、デバイス３２０は、無線ＬＡＮの通信インタフェイスを有していてもよい。その場合、デバイス３２０が特定の環境にあるか否かは、当該特定の環境に設置された無線ＬＡＮアクセスポイントを介して検出可能である。
【０１７８】
同様に、デバイス３２０はＲＦＩＤ回路を含んでいてもよい。その場合、デバイス３２０が特定の環境にあるか否かは、当該特定の環境に設置されたＲＦＩＤリーダを介して検出可能である。
【０１７９】
あるいは、センサ３４０は、端末３１０に内蔵されていてもよい。例えば、端末３１０にＧＰＳ（Global Positioning System）センサ内蔵されている場合、当該ＧＰＳセンサがセンサ３４０として使われてもよい。ＧＰＳセンサのほかにも、高度センサなど他の種類のセンサが使われてもよい。
【０１８０】
例えば、近傍のデバイス３２０を端末３１０が検出したときに、端末３１０に内蔵されたＧＰＳセンサが、端末３１０の緯度と経度を検出してもよい。検出された緯度と経度は、デバイス３２０の緯度と経度でもある、と見なせる。よって、上記の「特定の環境」が緯度と経度の所定の範囲で表される場合、端末３１０が近傍にデバイス３２０を検出したときにＧＰＳセンサが検出した緯度と経度は、デバイス３２０が特定の環境にあるか否かを示す。
【０１８１】
または、センサ３４０は、デバイス３２０に内蔵されていてもよい。例えば、センサ３４０は、デバイス３２０に内蔵されているＧＰＳセンサであってもよい。デバイス３２０に内蔵されているＧＰＳセンサが検出する緯度と経度は、デバイス３２０が特定の環境にあるか否かを示すことが可能な情報の例である。
【０１８２】
なお、以下ではデバイス３２０が存在する環境を「コンテキスト」ともいう。
さて、端末３１０とデバイス３２０とサーバ３３０のさらなる詳細は、後ほど図１４を参照して説明することにして、先に図１３の動作シーケンスについて説明する。
【０１８３】
図１３のステップＳ５０１〜Ｓ５０６は、図１のステップＳ１０１〜Ｓ１０６と同様である。よって、詳しい説明は省略するが、ステップＳ５０１〜Ｓ５０６の結果として、端末３１０は、デバイス３２０により提供されるサービス更新サービス３２２を発見し、デバイス３２０からデバイス定義ファイルとサービス定義ファイルを取得する。
【０１８４】
その後、ステップＳ５０７で端末３１０は、検出したサービス更新サービス３２２に対してコマンド（以下では説明の便宜上「受信準備コマンド」という）を送信する。受信準備コマンドも、具体的にはＳＯＡＰコマンドの形式で送信される。受信準備コマンドは、「サービスのデータがサーバ３３０から将来送信されてくるのに備えて、データを受信する準備を行うように」とデバイス３２０に促すコマンドである。また、受信準備コマンドはサーバ３３０のアドレスを含み、デバイス３２０に対してサーバ３３０のアドレスを通知する役目も果たす。
【０１８５】
デバイス３２０は、受信準備コマンドを受信すると、次にステップＳ５０８で端末３１０に応答を返す。ステップＳ５０８での応答は、具体的には、「ＯＫ」という意味を示す「２００」というステータスコードを含むＨＴＴＰ応答である。
【０１８６】
デバイス３２０は、さらにステップＳ５０９で、サーバ３３０からサービスのデータを受信するための準備を行う。例えば、デバイス３２０がサービスのデータを所定のＴＣＰ（Transmission Control Protocol）ポートで受信する場合は、ステップＳ５０９の受信準備は、上記の所定のＴＣＰポートを開放する（すなわち上記の所定のＴＣＰポートを「LISTEN」状態に設定する）処理を含んでもよい。
【０１８７】
デバイス３２０は、受信の準備を終えると、次に、ステップＳ５１０ａに示すように、サーバ３３０に通知を送る。以下では説明の便宜上、ステップＳ５１０ａの通知を「受信開始通知」という。受信開始通知は、デバイス３２０がサービスのデータを受信可能なことをサーバ３３０に知らせるための通知である。
【０１８８】
受信開始通知は、サービスのインストール先であるデバイス３２０のアドレスを明示的にペイロードに含んでもよい。または、サーバ３３０は、受信開始通知の送信元アドレスを、デバイス３２０のアドレスとして認識してもよい。
【０１８９】
以下では、サービスのインストール先を示す情報として、受信開始通知には、デバイス３２０のＩＰアドレスとデバイス３２０のＵＵＩＤが含まれるものとする。また、複数のＯＳに応じて、同じサービスを提供するためであっても複数の異なるプログラムが使われる場合がある。よって、以下では、受信開始通知には、デバイス３２０のＯＳを示す情報（例えばＯＳの名称とバージョン番号を表す文字列）が含まれるものとする。
【０１９０】
ところで、ステップＳ５１０ａの代わりに、ステップＳ５１０ｂのように端末３１０が受信開始通知をサーバ３３０に送信してもよい。つまり、端末３１０は、ステップＳ５０８の応答を受信すると、応答の受信を契機として、ステップＳ５１０ｂでサーバ３３０に対して受信開始通知を送信してもよい。
【０１９１】
ステップＳ５１０ｂの受信開始通知は、ステップＳ５１０ａの受信開始通知と同様に、デバイス３２０のＩＰアドレスとデバイス３２０のＵＵＩＤを含む。例えば、ステップＳ５０８の応答のメッセージボディにデバイス３２０のＵＵＩＤが含まれていてもよい。すると、端末３１０は、応答からデバイス３２０のＵＵＩＤを抽出して、受信開始通知に含めることが可能である。
【０１９２】
第３実施形態では、ステップＳ５１０ａまたはＳ５１０ｂで受信開始通知が送信された後、サービスのデータがすぐにデバイス３２０に送信されるとは限らない。サーバ３３０は、ステップＳ５１１ａまたはＳ５１１ｂのようなトリガを検出してはじめて、ステップＳ５１２のようにサービスのデータをデバイス３２０に送信する。
【０１９３】
具体的には、センサ３４０がデバイス３２０を検出した場合、ステップＳ５１１ａのように、センサ３４０は、センサ値とデバイス３２０のデバイスＩＤをサーバ３３０に通知する。なおここで、センサ値とは、デバイス３２０が検出された環境を判別するための情報である。また、デバイスＩＤとは、デバイス３２０を識別する識別情報である。
【０１９４】
例えば、センサ３４０が所定の場所に固定的に設置されている場合、サーバ３３０は、センサ３４０の識別情報とセンサ３４０の設置場所を対応づけるデータベースを有していてもよい。すると、センサ３４０の識別情報から、サーバ３３０は、デバイス３２０が検出された環境（すなわちセンサ３４０の固定的な設置場所）を判別することができる。したがって、センサ値としてセンサ３４０の識別情報が利用可能である。
【０１９５】
あるいは、センサ３４０が端末３１０またはデバイス３２０に内蔵されているＧＰＳセンサである場合、ＧＰＳセンサの出力する緯度と経度が、センサ値として利用可能である。
【０１９６】
また、デバイスＩＤは、例えば、デバイス３２０のＩＰ（Internet Protocol）アドレスであってもよいし、デバイス３２０のＵＵＩＤであってもよいし、両者の組み合わせであってもよい。
【０１９７】
以上のステップＳ５１１ａのようにセンサ３４０がセンサ値とデバイスＩＤをサーバ３３０に通知する代わりに、ステップＳ５１１ｂのように、端末３１０がサーバ３３０に対して、デバイス３２０へサービスのデータを送信するよう要求してもよい。
【０１９８】
例えば、場合によっては、実際のセンサ値が得られない環境もあるかもしれない。また、ユーザは、「実際のセンサ値と関係なく、デバイス３２０が特定の環境にあるものと見なして、当該特定の環境に適したサービスをデバイス３２０から受けたい」と思うかもしれない。
【０１９９】
よって、端末３１０は、ステップＳ５１１ｂのようにサーバ３３０に要求を送信してもよい。また、ステップＳ５１１ｂの要求には、特定の環境を指定する情報（後述のコンテキスト情報）と、インストール先のデバイス３２０を識別する識別情報が含まれる。例えば、端末３１０は、いくつかの環境を選択肢として含むリストをユーザに提示してもよく、端末３１０は、ユーザからの入力に基づいて、ユーザの選択した環境を指定する情報を要求に含めてもよい。
【０２００】
そして、ステップＳ５１１ａの通知またはステップＳ５１１ｂの要求の受信に応じて、ステップＳ５１２でサーバ３３０は、サービス（より具体的には、当該サービスを提供するためのプログラムを含むデータ）をデバイス３２０に送信する。具体的には、ステップＳ５１１ａの通知を受信した場合、サーバ３３０は、センサ値に基づいてデバイス３２０のコンテキストを判別する。また、ステップＳ５１１ｂの要求を受信した場合、サーバ３３０は、要求からコンテキスト情報を抽出する。そして、サーバ３３０は、コンテキストに応じた適宜のサービスを選択し、選択したサービスのデータをステップＳ５１２で送信する。
【０２０１】
すると、デバイス３２０はサービスのデータを受信する。サービスのデータは、具体的には、サービスのプログラムとサービス定義ファイルのデータを含む。よって、デバイス３２０は、ステップＳ５１３で、受信により取得したプログラムをデバイス３２０自身にインストールする。インストールの結果、デバイス３２０は、新規サービスを提供することができるようになる。また、デバイス３２０は、デバイス定義ファイルを更新し、サービス定義ファイルを更新または追加する。
【０２０２】
さらに、次のステップＳ５１４でデバイス３２０は、図１のステップＳ１１２と同様にして、ＧＥＮＡにより、サービス追加・更新イベントの発生を通知する。
また、図１３には示されていないが、上記のようにしてデバイス３２０が新規サービスの提供を開始した後、端末３１０および端末３５０は、新規サービスを利用することができる。インストールされた新規サービスを利用するための方法は、第１実施形態と同様である。
【０２０３】
ところで、第３実施形態においても、第１実施形態と同様のデバイス定義ファイル（例えば図３のデバイス定義ファイル１５０のようなデバイス定義ファイル）が使われる。
また、第１実施形態に関して図４を参照して説明したとおり、図４には、説明の都合上、第１実施形態では使われず第３実施形態で使われるアクションや状態変数についての定義も含むサービス定義ファイル１５１が例示されている。具体的には、図４の１９〜２６行目で定義されているアクションと、図４の３９〜４２行目で定義されている状態変数は、上記のとおり、第１実施形態では使われず、第３実施形態で使われる。そこで、以下に図４の１９〜２６行目と３９〜４２行目について説明する。
【０２０４】
図４に示したサービス更新サービスのサービス定義ファイル１５１の１９〜２６行目には、図１３のステップＳ５０７の受信準備コマンドに相当する、「Listen」という名前のアクションが定義されている。このアクションは２つの入力引数をとる。
【０２０５】
１番目の引数は、「argServerUri」という名前であり、サービスのデータの送信元（すなわちサーバ３３０）のＵＲＩを表す。また、この「argServerUri」という引数は、後述の「ServerUri」という状態変数と関係しており、具体的には、デバイス３２０におけるサービス更新サービス３２２は、「argServerUri」という引数に指定された値を「ServerUri」という状態変数に代入する。
【０２０６】
２番目の引数は、「setListeningFlag」という名前であり、サーバ３３０からのサービスのデータの受信が可能な状態にデバイス３２０を設定するか否かを表す。また、この「setListeningFlag」という引数は、後述の「Listening」という状態変数と関係しており、具体的には、デバイス３２０におけるサービス更新サービス３２２は、「setListeningFlag」という引数に指定された値を「Listening」という状態変数に代入する。
【０２０７】
さて、３９〜４０行目には、「ServerUri」という名前のＵＲＩ型の状態変数が定義されている。「ServerUri」という状態変数は、デバイス３２０が受信しようとする（あるいは既に受信した）データの送信元のサーバ３３０を示す。
【０２０８】
また、４１〜４２行目には、「Listening」という名前のブール型の状態変数が定義されている。「Listening」という状態変数の値が真（true）の場合、デバイス３２０は、受信準備が完了した状態（つまりサーバ３３０からの受信が可能な状態）である。逆に、「Listening」という状態変数の値が偽（false）の場合、デバイス３２０は、サーバ３３０からの受信が不可能な状態（例えば、所定のＴＣＰポートが閉じている状態）である。
【０２０９】
続いて、図１４を参照して、端末３１０とデバイス３２０とサーバ３３０の詳細について説明する。
図１４に示すように、端末３１０には、ＵＰｎＰコントローラ３１１が実装されている。ＵＰｎＰコントローラ３１１は、サービス更新サービスに対して制御メッセージ（つまりコマンド）を与える機能を有する、ＵＰｎＰのコントローラである。図１３に示した端末３１０の動作（ただしステップＳ５１１ｂの要求の送信を除く）は、具体的にはＵＰｎＰコントローラ３１１により実行される。
【０２１０】
また、端末３１０はステップＳ５１１ｂのような要求を送信する要求部３１２をさらに有していてもよい。要求部３１２は、ステップＳ５１１ｂの要求で指定する環境をユーザに指定させるための処理も行う。しかし、要求部３１２は省略されていてもよい。
【０２１１】
また、デバイス３２０は、ＵＰｎＰサービス提供部３２１を含む。ＵＰｎＰサービス提供部３２１は、サービス更新サービス３２２を提供する。図１３のステップＳ５１３は、具体的にはサービス更新サービス３２２により行われる。
【０２１２】
なお、図１４には、ステップＳ５１３でインストールされる新規サービス３２３が破線で示されている。新規サービス３２３のプログラムのインストール後には、ＵＰｎＰサービス提供部３２１は、新規サービス３２３も提供することが可能である。また、ＵＰｎＰコントローラ３１１は、サービス更新サービス３２２に対して制御メッセージを与える機能だけでなく、新規サービス３２３に対して制御メッセージを与える機能を有していてもよい。
【０２１３】
デバイス３２０はさらに受信部３２４を含む。受信部３２４は、サーバ３３０から新規サービス３２３のデータを受信するのを待ち、データを受信すると、サービス更新サービス３２２に受信を通知する。
【０２１４】
具体的には、図１３のステップＳ５０７の受信準備コマンドに応じて、サービス更新サービス３２２が受信部３２４を起動し、ステップＳ３０９で受信部３２４が受信準備を行ってもよい。そして、ステップＳ５１２で新規サービス３２３のデータが受信されると、受信部３２４がサービス更新サービス３２２に受信を通知してもよい。サービス更新サービス３２２は、受信部３２４からの通知に応じて、受信部３２４が受信したデータを使ってステップＳ５１３でインストールを実行してもよい。
【０２１５】
さて、サーバ３３０は、格納部３３１を有する。格納部３３１には、新規サービス３２３を提供するためのプログラムである新規サービスプログラム３３２が、新規サービス３２３を識別する情報と対応づけられて、格納されている。新規サービスプログラム３３２は、図１３のステップＳ５１２で送信され、ステップＳ５１３でデバイス３２０にインストールされる。
【０２１６】
なお、簡単化のため、図１４には１つの新規サービスプログラム３３２のみが示されているが、格納部３３１は、複数のサービスそれぞれのプログラムを、当該サービスを識別する情報と対応づけて格納していてもよい。つまり、格納部３３１は、様々なサービスを提供するための各種プログラムのレポジトリであってもよい。
【０２１７】
また、あるＯＳにしたがって動作するデバイスが新規サービス３２３を提供するためのプログラムと、別のＯＳにしたがって動作する別のデバイスが、同じ新規サービス３２３を提供するためのプログラムは、異なる場合がある。そのため、格納部３３１は、新規サービス３２３を識別する情報だけでなく、ＯＳを表す情報とも対応づけて、新規サービスプログラム３３２を格納しているものとする。
【０２１８】
さて、サーバ３３０は、図１３のステップＳ５１１ａでセンサ３４０から送信されるセンサ値から、デバイス３２０のコンテキスト（すなわちデバイス３２０の存在する環境）を抽出するコンテキスト抽出部３３３をさらに有する。コンテキスト抽出部３３３は、例えば、所定の場所に設置されたセンサ３４０（例えば無線ＬＡＮアクセスポイントやＲＦＩＤリーダなど）の識別情報と、センサ３４０の設置場所を対応づけるデータベースを使って、センサ値からコンテキストを抽出してもよい。また、コンテキスト抽出部３３３は、地図データを使って、センサ値としての緯度と経度から、コンテキストを抽出してもよい。
【０２１９】
なお、コンテキストの粒度は実施形態に応じて任意である。例えば、「Ｘビルの３階にある第１会議室」や「Ｙ氏の自宅」のような非常に細かな粒度のコンテキストが利用されてもよいし、「会議室」や「自宅」のようにある程度一般化されたコンテキストが利用されてもよい。コンテキスト抽出部３３３は、実施形態に応じた粒度のコンテキストをセンサ値から抽出するための適宜のルールデータベースを有していてもよい。また、所定の場所に設置されたセンサ３４０の識別情報と、センサ３４０の設置場所を対応づける上記データベースにおいて、設置場所がコンテキストの粒度に応じて表現されていてもよい。
【０２２０】
サーバ３３０はさらに、デバイス３２０に送信する対象のサービスを決定するサービス決定部３３４を含む。
なお、図１３のステップＳ５１１ｂのように要求部３１２から要求が送信される場合、サービス決定部３３４が要求を受信する。そして、サービス決定部３３４は、受信した要求から、コンテキスト情報を抽出する。逆に、図１３のステップＳ５１１ａのようにセンサ値が送信される場合、サービス決定部３３４は、コンテキスト抽出部３３３から、コンテキスト情報を取得する。
【０２２１】
いずれにせよ、サービス決定部３３４は、コンテキストに基づいてサービスを決定する。その際、サービス決定部３３４は、条件テーブル３３５を参照することで、コンテキストに対応するサービスを決定する。
【０２２２】
図１５に、条件テーブル３３５の具体例を示す。図１５に示すように、条件テーブル３３５は、コンテキストとサービスを対応づけるテーブルである。なお、図１５では、理解を容易にするために、コンテキストとサービスがそれぞれ名前で表現されている。しかし、条件テーブル３３５は、例えば、コンテキストを示すコード番号と、サービスのＩＤとを対応づけるテーブルであってもよい。
【０２２３】
図１５の例では、「会議室」というコンテキストに、ドキュメント表示サービスが対応づけられている。また、「事務所」というコンテキストに、照明ＯＮ／ＯＦＦサービスが対応づけられている。そして、「自宅」というコンテキストに、ビデオ録画サービスが対応づけられている。したがって、コンテキスト抽出部３３３によって例えば「会議室」というコンテキストが抽出された場合、サービス決定部３３４は、ドキュメント表示サービスのデータをデバイス３２０に送信することを決定する。
【０２２４】
ここで、再度図１４の説明に戻ると、サーバ３３０はさらに、受信準備の整ったデバイス３２０についての情報を管理するデバイス管理部３３６を有する。デバイス管理部３３６は、具体的には、デバイステーブル３３７を用いて、デバイス３２０についての情報を管理する。
【０２２５】
図１６に、デバイステーブル３３７の具体例を示す。デバイステーブル３３７の各エントリは、１台のデバイス３２０に対応する。図１６には、２台のデバイス３２０にそれぞれ対応する２つのエントリが例示されている。図１６に示すように、デバイステーブル３３７は、デバイス３２０のＩＰアドレスと、デバイス３２０のＵＵＩＤと、デバイス３２０のＯＳとを対応づけるテーブルである。
【０２２６】
図１４には１台の端末３１０と１台のデバイス３２０しか図示されていないが、システム３００は、複数の端末３１０と複数のデバイス３２０を含んでいてもよい。よって、デバイス管理部３３６は、ある１台のデバイス３２０（より具体的には受信部３２４）から図１３のステップＳ５１０ａのように受信開始通知を受信するたびに、デバイステーブル３３７にエントリを追加するか、または既存のエントリを更新する。また、デバイス管理部３３６は、ある１台の端末３１０（より具体的にはＵＰｎＰコントローラ３１１）から図１３のステップＳ５１０ｂのように受信開始通知を受信するたびに、デバイステーブル３３７にエントリを追加するか、または既存のエントリを更新する。
【０２２７】
ここで、再度図１４の説明に戻ると、サーバ３３０はさらに送信部３３８を有する。送信部３３８は、サービス決定部３３４の決定にしたがって、格納部３３１から適宜の新規サービスプログラム３３２を読み出して、新規サービスプログラム３３２をデバイス３２０に送信する。
【０２２８】
ところで、図１３のステップＳ５０７〜Ｓ５１４までの処理は、サーバ３３０が図１７と図１８のフローチャートにしたがって動作し、デバイス３２０が図１９のフローチャートにしたがって動作することにより、実現される。具体的には以下のとおりである。
【０２２９】
図１７は、デバイス３２０または端末３１０からの受信開始通知に応じて、サーバ３３０が行う処理のフローチャートである。
ステップＳ６０１でサーバ３３０のデバイス管理部３３６は、デバイス３２０または端末３１０から、受信開始通知を受信する。より具体的には、図１３のステップＳ５１０ａのように、デバイス管理部３３６は、デバイス３２０の受信部３２４から受信開始通知を受信することもある。あるいは、図１３のステップＳ５１０ｂのように、デバイス管理部３３６は、端末３１０のＵＰｎＰコントローラ３１１から受信開始通知を受信することもある。
【０２３０】
いずれにしても、受信開始通知は、ステップＳ５１０ａとＳ５１０ｂに関して説明したとおり、サービスのインストール先であるデバイス３２０の、ＩＰアドレスとＵＵＩＤを含む。
【０２３１】
なお、デバイス３２０のＩＰアドレスが変化する場合もあり得る。例えば、ＤＨＣＰ（Dynamic Host Configuration Protocol）によってＩＰアドレスが割り当てられているデバイス３２０が再起動すると、再起動の前後でデバイス３２０のＩＰアドレスは変化するかもしれない。再起動したデバイス３２０は、サーバ３３０に新たなＩＰアドレスを通知するために受信開始通知を再び送信してもよい。
【０２３２】
また、ある１台のデバイス３２０が、複数台の端末３１０から、何らかの間隔を置いて、受信準備コマンドを受信することもあり得る。その場合、複数の受信準備コマンドに対応して、同じデバイス３２０から、複数の受信開始通知をサーバ３３０が受信することになる。
【０２３３】
そこで、デバイス管理部３３６は、端末３１０またはデバイス３２０から受信開始通知を受信すると、次のステップＳ６０２で、受信開始通知によって通知されたＵＵＩＤと同じＵＵＩＤが格納されたエントリがデバイステーブル３３７に存在するか否かを判断する。もしそのようなエントリがデバイステーブル３３７にあれば、処理はステップＳ６０３に移行する。逆に、そのようなエントリがデバイステーブル３３７になければ、処理はステップＳ６０４に移行する。
【０２３４】
ステップＳ６０３でデバイス管理部３３６は、ステップＳ６０２で見つけた当該エントリのＩＰアドレスとＯＳのフィールドを、受信開始通知により通知されたＩＰアドレスとＯＳの値で上書きする。そして、図１７の処理は終了する。
【０２３５】
また、ステップＳ６０４でデバイス管理部３３６は、受信開始通知により通知されたＩＰアドレスとＵＵＩＤとＯＳの値を格納する新規エントリを、デバイステーブル３３７に追加する。そして、図１７の処理は終了する。
【０２３６】
図１８は、図１３のステップＳ５１１ａのようなセンサ３４０からの通知に応じて、サーバ３３０が行う処理のフローチャートである。なお、ステップＳ５１１ｂのような要求に応じてサーバ３３０が新規サービスプログラム３３２を送信する場合については、上記の図１３〜１４についての説明から明らかなので、フローチャートを省略する。
【０２３７】
さて、ステップＳ７０１でコンテキスト抽出部３３３が、センサ３４０から、図１３のステップＳ５１１ａのように、センサ値とデバイスＩＤを受信する。デバイスＩＤは、具体的には、ＩＰアドレスまたはＵＵＩＤである。
【０２３８】
次に、ステップＳ７０２でコンテキスト抽出部３３３が、通知されたセンサ値からコンテキスト情報を生成する。なお、コンテキスト情報とは、コンテキストを表す情報である。例えば、コンテキストが「会議室」のような文字列で表される場合は、コンテキスト情報は文字列であるが、もちろん、コンテキスト情報の形式は任意であり、コード番号などが使われてもよい。図１４に関して説明したように、例えば、センサ３４０の識別情報とセンサ３４０の設置位置を対応づけるデータベース、地図データ、ルールデータベースなどの適宜の情報を利用することで、コンテキスト抽出部３３３はコンテキスト情報を生成することができる。そして、コンテキスト抽出部３３３は、生成したコンテキスト情報をサービス決定部３３４に通知する。
【０２３９】
また、ステップＳ７０３でコンテキスト抽出部３３３は、センサ３４０から通知されたデバイスＩＤをデバイス管理部３３６に通知する。そして、デバイス管理部３３６は、通知されたデバイスＩＤがＵＵＩＤとＩＰアドレスのどちらなのかを判断する。
【０２４０】
通知されたデバイスＩＤがＵＵＩＤの場合、処理はステップＳ７０４に移行する。逆に、通知されたデバイスＩＤがＩＰアドレスの場合、処理はステップＳ７０５に移行する。
ステップＳ７０４でデバイス管理部３３６は、通知されたＵＵＩＤがＵＵＩＤのフィールドに記憶されているエントリが、デバイステーブル３３７にあるか否かを判断する。もしそのようなエントリがなければ、図１８の処理は終了する。逆に、通知されたＵＵＩＤがＵＵＩＤのフィールドに記憶されているエントリが見つかれば、デバイス管理部３３６は、見つけたエントリをサービス決定部３３４に通知し、処理はステップＳ７０６に移行する。
【０２４１】
また、ステップＳ７０５でデバイス管理部３３６は、通知されたＩＰアドレスがＩＰアドレスのフィールドに記憶されているエントリが、デバイステーブル３３７にあるか否かを判断する。もしそのようなエントリがなければ、図１８の処理は終了する。逆に、通知されたＩＰアドレスがＩＰアドレスのフィールドに記憶されているエントリが見つかれば、デバイス管理部３３６は、見つけたエントリをサービス決定部３３４に通知し、処理はステップＳ７０６に移行する。
【０２４２】
ステップＳ７０６でサービス決定部３３４は、ステップＳ７０２でコンテキスト抽出部３３３から通知されたコンテキスト情報と合致するエントリが条件テーブル３３５にあるか否かを判断する。例えば、コンテキスト抽出部３３３が「事務所」というコンテキスト情報をサービス決定部３３４に通知した場合、サービス決定部３３４は、コンテキストのフィールドに「事務所」と記憶されているエントリを条件テーブル３３５において探す。
【０２４３】
もし、通知されたコンテキスト情報と合致するエントリが条件テーブル３３５にあれば、処理はステップＳ７０７に移行する。逆に、そのようなエントリが見つからなければ、図１８の処理は終了する。
【０２４４】
ステップＳ７０７でサービス決定部３３４は、ステップＳ７０４またはＳ７０５でデバイステーブル３３７において見つかったエントリから、ＩＰアドレスとＵＵＩＤとＯＳの値を取得する。そして、サービス決定部３３４は、取得したこれらの値と、ステップＳ７０６で条件テーブル３３５において見つけたエントリにおける「サービス」フィールドの値とを、送信部３３８に通知する。
【０２４５】
最後に、ステップＳ７０８で送信部３３８は、サービス決定部３３４から宛先として通知されたデバイス３２０に対し、サービス決定部３３４から通知されたサービスのデータを送信する。より具体的には、送信部３３８は、サービス決定部３３４から通知されたサービスとＯＳに基づいて、格納部３３１から送信対象のデータ（つまり新規サービスプログラム３３２と、新規サービス３２３のサービス定義ファイルを含むデータ）を読み出す。そして、送信部３３８は、通知されたＩＰアドレスを宛先として、読み出したデータを送信する。ステップＳ７０８の送信は、図１３のステップＳ５１２の送信に対応する。
【０２４６】
なお、ステップＳ７０４、Ｓ７０５、またはＳ７０６で、検索条件に合致するエントリが見つからない場合は、何らかのエラーがある場合である。よって、これらの場合、上記のとおり図１８の処理は終了し、ステップＳ７０８のような送信は行われない。
【０２４７】
さて、図１９は、図１３のステップＳ５０７のような受信準備コマンドに応じて、デバイス３２０が行う処理のフローチャートである。図１９は、図１３のステップＳ５０７〜Ｓ５１４に対応する。なお、図１３には、ステップＳ５１０ａが行われる場合とステップＳ５１０ｂが行われる場合の双方が例示されているが、図１９には、ステップＳ５１０ａが行われる場合の処理手順を例示した。
【０２４８】
さて、ステップＳ８０１でデバイス３２０のサービス更新サービス３２２は、端末３１０（より具体的にはＵＰｎＰコントローラ３１１）から、図１３のステップＳ５０７の受信準備コマンドを受信する。図示は省略したが、ステップＳ８０１で受信される受信準備コマンドは、具体的にはＳＯＡＰコマンドである。
【０２４９】
図４のサービス定義ファイル１５１の１９〜２６行目に定義されているように、受信準備コマンドは、具体的には「Listen」というアクションであり、「srgSrverUri」と「setListeningFlag」という２つの引数が与えられる。「srgSrverUri」という引数には、サーバ３３０のＵＲＩが指定される。また、受信準備をデバイス３２０に行わせるために、「setListeningFlag」という引数は真に設定される。
【０２５０】
サービス更新サービス３２２は、受信準備コマンドを受信すると、図１３のステップＳ５０８のとおり、ＨＴＴＰ応答を返す。なお、サービス更新サービス３２２は、サービス更新サービス３２２の「Listening」という状態変数の値を、「setListeningFlag」という引数に指定された値（すなわち真）に更新する。
【０２５１】
そして、ステップＳ８０２でサービス更新サービス３２２は、受信部３２４を起動する。その際、サービス更新サービス３２２は、受信部３２４に対して、デバイス３２０自身のＵＵＩＤと、サーバ３３０のアドレス（つまり、受信準備コマンドで引数に指定されていたサーバ３３０のＵＲＩ）を通知する。起動された受信部３２４は、サーバ３３０からデータを受信するための適宜の処理を行う。例えば、受信部３２４は、所定のＴＣＰポートを開放してもよい。ステップＳ８０２は図１３のステップＳ５０９の受信準備に対応する。
【０２５２】
また、ステップＳ８０３で受信部３２４は、デバイス３２０のＩＰアドレスと、デバイス３２０のＵＵＩＤと、デバイス３２０のＯＳを、サーバ３３０のデバイス管理部３３６に通知する。ステップＳ８０３の通知は、図１３のステップＳ５１０ａの受信開始通知である。
【０２５３】
そして、ステップＳ８０３での受信開始通知の送信後、デバイス３２０は、ステップＳ８０４に示すように、受信部３２４がサーバ３３０からサービスのデータ（つまり新規サービスプログラム３３２を含むデータ）を受信するまで待つ。ステップＳ８０４での待機は、図１３において、デバイス３２０がステップＳ５１０ａの送信の後、ステップＳ５１２での受信まで待つことに対応する。
【０２５４】
そして、受信部３２４がサーバ３３０からサービスのデータを受信すると、ステップＳ８０５で受信部３２４は、受信したデータをサービス更新サービス３２２に通知する。
すると、ステップＳ８０６でサービス更新サービス３２２は、受信部３２４から通知されたデータに基づいて、以下の３つの処理を行う。
【０２５５】
第１に、サービス更新サービス３２２は、デバイス３２０のデバイス定義ファイルを更新する。
第２に、サービス更新サービス３２２は、新規サービス３２３のサービス定義ファイルを追加または更新する。つまり、新規サービス３２３が今までデバイス３２０に存在していなかった全く新しいサービスである場合は、サービス更新サービス３２２は、新たなサービス定義ファイルを作成して保存する。また、新規サービス３２３が、デバイス３２０にインストール済みの既存のサービスの新規バージョンである場合は、サービス更新サービス３２２は、当該既存のサービスのサービス定義ファイルを更新する。
第３に、サービス更新サービス３２２は、受信した新規サービスプログラム３３２をデバイス３２０にインストールする。
【０２５６】
そして、次のステップＳ８０７で、サービス更新サービス３２２は、図４の４３行目に示す「UpdateTime」という状態変数の値を現在時刻に更新する。ステップＳ８０６〜Ｓ８０７は、図１３のステップＳ５１３に対応する。
【０２５７】
最後に、ステップＳ８０８でサービス更新サービス３２２は、ＧＥＮＡにより、デバイス３２０の周辺の端末（例えば、図１３では端末３１０と端末３５０）に対して、ステップＳ８０７で更新した「UpdateTime」という状態変数の値を通知する。ステップＳ８０８は図１３のステップＳ５１４に対応する。
【０２５８】
以上説明した第３実施形態には、第１実施形態と同様に、動的なサービスの更新による利便性向上という効果がある。また、サービス更新サービス３２２がＵＰｎＰのサービスであるため、第１実施形態と同様に、端末３１０が新規の特殊なプロトコルを使用する必要がなく、かつ、ライブラリを介してサービス更新サービス３２２の普及が促進される、という効果もある。
【０２５９】
さらに、第３実施形態によれば、デバイス３２０は、コンテキストに応じて、コンテキストに適したサービスを提供することができる。よって、端末３１０（または端末３５０）は、デバイス３２０がコンテキストに応じて提供することが可能となったサービスを利用することができる。
【０２６０】
続いて、第４実施形態について説明する。第４実施形態は、コントローラの更新に関する点において第２実施形態と共通である。しかし、第４実施形態は、端末が特定の環境に入ることがインストールのトリガである点において、第２実施形態と異なる。
【０２６１】
すなわち、第４実施形態によれば、端末が存在する環境に応じて、当該環境で使われるサービス（あるいは当該環境に適したサービス）を利用するためのコントローラが、端末にインストールされる。以下、図２０〜２６を参照して第４実施形態について詳しく説明する。
【０２６２】
図２０は、第４実施形態の動作シーケンス図である。また、図２１は、第４実施形態のシステム構成図である。図２１に示すように、第４実施形態のシステム４００は、端末４１０とデバイス４２０とサーバ４３０とセンサ４４０を含む。システム４００内には、端末４１０以外の端末がさらにあってもよく、センサ４４０以外のセンサがさらにあってもよい。図２０は、図２１の端末４１０、デバイス４２０、サーバ４３０、およびセンサ４４０による動作シーケンスの例を示す。
【０２６３】
端末４１０は、通信機能とＵＰｎＰのコントローラ機能を有し、かつ、ソフトウェアをインストールすることが可能であれば、どのような種類の端末であってもよい。例えば、端末４１０は、携帯電話、スマートフォン、タブレット端末、ＰＤＡ、ノートＰＣのような携帯端末であってもよいし、デスクトップＰＣであってもよい。
【０２６４】
デバイス４２０は、通信機能とＵＰｎＰのサービス提供機能を有していれば、どのようなデバイスでもよい。デバイス４２０は、ソフトウェアのインストールが不可能なものであってもよい。例えば、携帯電話、スマートフォン、タブレット端末、ＰＤＡ、ノートＰＣ、デスクトップＰＣ、プリンタ、プロジェクタ、テレビ、録画装置、照明装置など、様々な装置がデバイス４２０として利用される可能性がある。なお、端末４１０とデバイス４２０は、ネットワークを介して互いに通信することができる。
【０２６５】
サーバ４３０は、ネットワーク（例えばインターネット）を介した通信が可能なコンピュータである。サーバ４３０は、少なくとも端末４１０と通信可能である。また、後述するとおり、第４実施形態では、ある種の通知が、センサ４４０からサーバ４３０に送信されてもよく、端末４１０からサーバ４３０に送信されてもよい。センサ４４０が通知を送信する場合は、サーバ４３０は、センサ４４０とも通信可能なように構成される。
【０２６６】
センサ４４０は、１種の検出装置である。具体的には、端末４１０が特定の環境に存在する場合に、センサ４４０は、端末４１０が特定の環境に存在することを示す検出通知を送信する。なお、第３実施形態に関する説明と同様に、第４実施形態に関する説明においても、環境のことを「コンテキスト」ともいう。
【０２６７】
例えば、センサ４４０は、特定の環境に予め設置された無線ＬＡＮアクセスポイントやＲＦＩＤリーダなどの装置であってもよい。あるいは、センサ４４０は、端末４１０に内蔵されたＧＰＳセンサなどのセンサであってもよい。
【０２６８】
さて、端末４１０とデバイス４２０とサーバ４３０のさらなる詳細は、後ほど図２１を参照して説明することにして、先に図２０の動作シーケンスについて説明する。
図２０のステップＳ９０１〜Ｓ９０６は、図７のステップＳ３０１〜Ｓ３０６と同様である。よって、詳しい説明は省略するが、ステップＳ９０１〜Ｓ９０６の結果として、端末４１０は、デバイス４２０の提供するサービス（例えば、後述する図２１のサービス４２２）を発見し、デバイス４２０からデバイス定義ファイルとサービス定義ファイルを取得する。
その後、ステップＳ９０７で端末４１０は、発見したサービスを利用するためのコントローラのデータをサーバ４３０から受信するための準備を行う。例えば、ステップＳ９０７の受信準備は、所定のＴＣＰポートを開放する処理を含んでもよい。
【０２６９】
端末４１０は、受信の準備を終えると、次のステップＳ９０８で、サーバ４３０に通知を送る。以下では説明の便宜上、ステップＳ９０８の通知のことも「受信開始通知」という。第４実施形態における受信開始通知は、端末４１０がコントローラのデータを受信可能なことをサーバ４３０に知らせるための通知である。
【０２７０】
受信開始通知は、コントローラのインストール先である端末４１０のアドレスを明示的にペイロードに含んでもよい。または、サーバ４３０は、受信開始通知の送信元アドレスを、端末４１０のアドレスとして認識してもよい。
【０２７１】
以下では、コントローラのインストール先を示す情報として、受信開始通知には、端末４１０のＩＰアドレスと端末４１０のＵＵＩＤが含まれるものとする。また、複数のＯＳに応じて、同じサービスを利用するためであっても複数の異なるコントローラプログラムが使われる場合がある。よって、以下では、受信開始通知には、端末４１０のＯＳを示す情報（例えばＯＳの名称とバージョン番号を表す文字列）が含まれるものとする。さらに、受信開始通知には、端末４１０が利用しようとするサービス（つまりステップＳ９０１〜Ｓ９０６で検出されたサービス）を識別する識別情報（例えばサービスＩＤ）も含まれる。
【０２７２】
さて、第４実施形態では、ステップＳ９０８で受信開始通知が送信された後、コントローラのデータがすぐに端末４１０に送信されるとは限らない。サーバ４３０は、ステップＳ９０９ａまたはＳ９０９ｂのようなトリガを検出してはじめて、ステップＳ９１０のようにコントローラのデータを端末４１０に送信する。
【０２７３】
例えば、センサ４４０が所定の場所に固定的に設置されている場合、センサ４４０は、端末４１０を検出すると、ステップＳ９０９ａのように、センサ値と端末４１０の端末ＩＤをサーバ４３０に送信する。この場合、センサ値は、センサ４４０の識別情報であってもよい。サーバ４３０は、センサ４４０の識別情報とセンサ４４０の設置場所を対応づけるデータベースを参照することで、端末４１０が検出された環境（すなわちセンサ４４０の固定的な設置場所）を判別することができる。
【０２７４】
あるいは、センサ４４０が端末４１０に内蔵されている場合、センサ４４０は、定期的に、または不定期に、ステップＳ９０９ａのように、センサ値と端末４１０の端末ＩＤをサーバ４３０に送信する。この場合、センサ値は、例えば、緯度と経度の組み合わせである。サーバ４３０は、地図データを参照することで、端末４１０の存在する環境を判別することができる。図２０の例では、ステップＳ９０９ａで通知されたセンサ値が、「端末４１０は特定の環境に存在している」と示す値であったものとする。
【０２７５】
なお、端末ＩＤは、例えば、端末４１０のＩＰアドレスであってもよいし、端末４１０のＵＵＩＤであってもよいし、両者の組み合わせであってもよい。
ところで、ステップＳ９０９ａのようにセンサ４４０が通知を送信する代わりに、ステップＳ９０９ｂのように、端末４１０がサーバ４３０に対して、ステップＳ９０１〜Ｓ９０６で検出したサービスを利用するためのコントローラのデータを要求してもよい。
【０２７６】
例えば、場合によっては、実際のセンサ値が得られない環境もあるかもしれない。また、ユーザは、「実際のセンサ値と関係なく、端末４１０が特定の環境にあるものと見なして、当該特定の環境に適したサービスを、端末４１０を介してデバイス４２０から受けたい」と思うかもしれない。
【０２７７】
よって、端末４１０は、ステップＳ９０９ｂのように要求を送信してもよい。また、ステップＳ９０９ｂの要求には、特定の環境を指定する情報（つまりコンテキスト情報）と、端末４１０（すなわち、所望のサービスを利用するためのコントローラのインストール先）を識別する端末ＩＤが含まれる。例えば、端末４１０は、いくつかの環境を選択肢として含むリストをユーザに提示してもよい。そして、端末４１０は、ユーザからの入力に基づいて、ユーザの選択した環境を指定する情報を要求に含めてもよい。
【０２７８】
そして、ステップＳ９０９ａの通知またはステップＳ９０９ｂの要求の受信に応じて、ステップＳ９１０でサーバ４３０は、適宜のコントローラ（より具体的には、当該コントローラを実現するためのプログラムを含むデータ）を端末４１０に送信する。
【０２７９】
具体的には、ステップＳ９０９ａの通知を受信した場合、サーバ４３０は、センサ値に基づいて端末４１０のコンテキストを判別する。あるいは、ステップＳ９０９ｂの要求を受信した場合、サーバ４３０は、コンテキストを指定する情報を要求から抽出する。いずれにせよ、サーバ４３０は、コンテキストを表す情報を取得する。
【０２８０】
また、サーバ４３０は、ステップＳ９０８の受信開始通知の内容を記憶している。よって、サーバ４３０は、ステップＳ９０９ａで通知されたデバイスＩＤを用いて、記憶している受信開始通知の内容を検索することにより、当該デバイスＩＤで識別される端末４１０からかつて受信開始通知により通知されたサービスの識別情報を取得する。そして、サーバ４３０は、コンテキストと、サービスの識別情報に基づいて、端末４１０に送信する対象の適宜のコントローラを選択し、選択したコントローラのプログラムをステップＳ９１０で送信する。
【０２８１】
すると、端末４１０は、ステップＳ９１０で送信されたコントローラのプログラムを受信し、次のステップＳ９１１で、受信したプログラムを端末４１０自身にインストールする。
【０２８２】
以上のようにして、端末４１０には、動的にコントローラのプログラムがインストールされる。よって、図２０には示されていないが、端末４１０は、今後、インストールされたコントローラから制御メッセージ（具体的にはＳＯＡＰコマンド）を送信することにより、デバイス４２０により提供されるサービスを利用することができる。
【０２８３】
ところで、第４実施形態においても、第２実施形態と同様に、コントローラ更新サービス４１２がＵＰｎＰのサービスとして実装されるので、端末４１０はデバイス定義ファイルとサービス定義ファイルを記憶している。第４実施形態の端末４１０のデバイス定義ファイルは、例えば、図１０のデバイス定義ファイル２４０と同様であってもよい。
【０２８４】
また、第２実施形態に関して図１１を参照して説明したとおり、図１１には、説明の都合上、第２実施形態では使われず第４実施形態で使われる状態変数についての定義も含むサービス定義ファイル２４１が例示されている。具体的には、図１１の２５〜２６行目で定義されている「Listening」という状態変数は、上記のとおり、第２実施形態では使われず第４実施形態で使われる。
【０２８５】
この「Listening」という状態変数は、ブール型の状態変数である。「Listening」という状態変数の値が真の場合は、端末４１０は受信準備が完了した状態（つまりサーバ４３０からの受信が可能な状態）である。逆に、「Listening」という状態変数の値が偽の場合、端末４１０は、サーバ４３０からの受信が不可能な状態（例えば、所定のＴＣＰポートが閉じている状態）である。
【０２８６】
続いて、図２１を参照して、端末４１０とデバイス４２０とサーバ４３０の詳細について説明する。
図２１に示すように、端末４１０にはＵＰｎＰ制御部４１１が含まれる。ＵＰｎＰ制御部４１１は、１つ以上のコントローラを含むことができるが、例えば図２０のステップＳ９０１の時点では、ＵＰｎＰ制御部４１１は、１つもコントローラを含んでいなくてもよい。
【０２８７】
また、端末４１０は、ＵＰｎＰのサービスを利用するためのコントローラを動的に追加または更新するための、コントローラ更新サービス４１２を提供する。図２０のステップＳ９０１の探索、ステップＳ９０２の応答の受信、ステップＳ９０３の要求、ステップＳ９０４の受信、ステップＳ９０５の要求、およびステップＳ９０６の受信は、具体的には、コントローラ更新サービス４１２により実行される。また、ステップＳ９１１のインストールも、コントローラ更新サービス４１２により実行される。
【０２８８】
なお、全く新たなコントローラを追加することも、既存のコントローラを新たなバージョンのコントローラに更新することも、コントローラのプログラムのインストールにより同様に実現される。したがって、以下ではコントローラの追加と更新を区別しないことがある。
【０２８９】
また、第２実施形態と同様に第４実施形態でも、コントローラ更新サービス４１２がＵＰｎＰのサービスとして実装されている。しかし、実施形態によっては、「コントローラ更新サービス４１２同様の機能を持つものの、ＵＰｎＰのサービスではない」というプログラムモジュールが、コントローラ更新サービス４１２の代わりに使われてもよい。
【０２９０】
端末４１０はさらに受信部４１３を含む。受信部４１３は、サーバ４３０からのデータ受信を待ち、データを受信すると、コントローラ更新サービス４１２に受信を通知する。
具体的には、図２０のステップＳ９０６の後、コントローラ更新サービス４１２が受信部４１３を起動し、ステップＳ９０７で受信部４１３が受信準備を行ってもよい。また、ステップＳ９０８の受信開始通知は、受信部４１３から送信されてもよい。受信部４１３は、ステップＳ９１０でコントローラのプログラムを受信すると、コントローラ更新サービス４１２に受信を通知する。すると、コントローラ更新サービス４１２がステップＳ９１１でコントローラのプログラムを端末４１０にインストールする。
【０２９１】
端末４１０は、さらに、図２０のステップＳ９０９ｂのような要求を送信する要求部４１４を有していてもよい。要求部４１４は、ステップＳ９０９ｂの要求で指定する環境をユーザに指定させるための処理も行う。しかし、要求部４１４は省略されてもよい。
【０２９２】
なお、図２１には、ステップＳ９１１でインストールされる新規コントローラ４１５が破線で示されている。
また、デバイス４２０は、ＵＰｎＰサービス提供部４２１を含む。ＵＰｎＰサービス提供部４２１は、サービス２２２を提供する。サービス２２２は、具体的には、新規コントローラ４１５を介して利用されるサービスである。換言すれば、サービス２２２と対応づけられた特定の環境に端末４１０が入ることをきっかけとして、端末４１０には新規コントローラ４１５がインストールされる。
【０２９３】
さて、サーバ４３０は格納部４３１を有する。格納部４３１には、サービス４２２に対応する新規コントローラ４１５を実現するためのプログラムである新規コントローラプログラム４３２が格納されている。新規コントローラプログラム４３２は、図２０のステップＳ９１０で送信され、ステップＳ９１１で端末４１０にインストールされる。インストールの結果として、端末４１０は、新規コントローラ４１５を介してサービス２２２を利用することができるようになる。
【０２９４】
なお、簡単化のため図２１には１つの新規コントローラプログラム４３２のみが示されている。しかし、格納部４３１は、複数のサービスに対応する複数のコントローラそれぞれのプログラムを格納していてもよい。
【０２９５】
また、あるＯＳにしたがって動作する端末が新規コントローラ４１５を実現するためのプログラムと、別のＯＳにしたがって動作する別の端末が、同じ新規コントローラ４１５を実現するためのプログラムは、異なる場合がある。そのため、格納部４３１は、具体的には、サービス４２２を識別する情報とＯＳを表す情報の双方と対応づけて、新規コントローラプログラム４３２を格納しているものとする。
【０２９６】
さて、サーバ４３０は、図２０のステップＳ９０９ａで送信されるセンサ値から、端末４１０のコンテキスト（すなわち端末４１０の存在する環境）を抽出するコンテキスト抽出部４３３をさらに有する。コンテキスト抽出部４３３の詳細は、第３実施形態のコンテキスト抽出部３３３と同様なので、詳しい説明は省略する。第４実施形態のコンテキスト抽出部４３３も、実施形態に応じた適宜の粒度のコンテキストを抽出することができる。
【０２９７】
サーバ４３０はさらに、端末４１０に送信する対象のコントローラを決定するコントローラ決定部４３４を含む。
なお、図２０のステップＳ９０９ｂのように要求部４１４から要求が送信される場合、コントローラ決定部４３４が要求を受信する。そして、コントローラ決定部４３４は、受信した要求から、コンテキスト情報を抽出する。逆に、図２０のステップＳ９０９ａのようにセンサ値が送信される場合、コントローラ決定部４３４は、コンテキスト抽出部４３３から、コンテキスト情報を取得する。
【０２９８】
いずれにせよ、コントローラ決定部４３４は、コンテキストに基づいてコントローラを決定する。その際、コントローラ決定部４３４は、条件テーブル４３５を参照することで、コンテキストと指定されたサービスの組み合わせに対応するコントローラを決定する。
【０２９９】
図２２に、条件テーブル４３５の具体例を示す。図２２に示すように、条件テーブル４３５は、コンテキストとサービスとコントローラを対応づけるテーブルである。なお、図２２では、理解を容易にするために、コンテキストとサービスとコントローラがそれぞれ名前で表現されている。しかし、例えば、条件テーブル４３５は、コンテキストを示すコード番号と、サービスＩＤとコントローラＩＤとを対応づけるテーブルであってもよい。
【０３００】
図２２の例では、「会議室」というコンテキストと、ドキュメント表示サービスと、ドキュメントページめくりコントローラが対応づけられている。そして、「事務所」というコンテキストと、照明ＯＮ／ＯＦＦサービスと、照明ＯＮ／ＯＦＦリモコンコントローラが対応づけられている。また、「自宅」というコンテキストと、ビデオ録画サービスと、ビデオリモコンコントローラが対応づけられている。
【０３０１】
例えば、図２０のステップＳ９０８で端末４１０の受信部４１３から送信される受信開始通知において指定されているサービスが、ドキュメント表示サービスであったとする。この場合、コンテキスト抽出部４３３による「会議室」というコンテキストの抽出に応じて、コントローラ決定部４３４は、ドキュメントページめくりコントローラのプログラムを端末４１０に送信することを決定する。
【０３０２】
ここで、再度図２１の説明に戻ると、サーバ４３０はさらに、受信準備の整った端末４１０についての情報を管理する端末管理部４３６を有する。端末管理部４３６は、具体的には、端末テーブル４３７を用いて、端末４１０についての情報を管理する。
【０３０３】
図２３に、端末テーブル４３７の具体例を示す。端末テーブル４３７の各エントリは、１台の端末４１０に対応する。図２３には、２台の端末４１０にそれぞれ対応する２つのエントリが例示されている。図２３に示すように、端末テーブル４３７は、端末４１０のＩＰアドレスと、端末４１０のＵＵＩＤと、端末４１０のＯＳと、端末４１０が受信を待っている対象のコントローラに対応するサービスとを対応づけるテーブルである。
【０３０４】
図２１には１台の端末４１０と１台のデバイス４２０しか図示されていないが、システム４００は複数の端末４１０と複数のデバイス４２０を含んでいてもよい。よって、端末管理部４３６は、ある１台の端末４１０（より具体的には受信部４１３）から図２０のステップＳ９０８のように受信開始通知を受信するたびに、端末テーブル４３７にエントリを追加するか、または既存のエントリを更新する。
【０３０５】
ここで、再度図２１の説明に戻ると、サーバ４３０はさらに送信部４３８を有する。送信部４３８は、コントローラ決定部４３４の決定にしたがって、格納部４３１から適宜の新規コントローラプログラム４３２を読み出して、新規コントローラプログラム４３２を端末４１０に送信する。
【０３０６】
ところで、図２０のステップＳ９０１〜Ｓ９１１までの処理は、サーバ４３０が図２４と図２５のフローチャートにしたがって動作し、端末４１０が図２６のフローチャートにしたがって動作することにより、実現される。具体的には以下のとおりである。
【０３０７】
図２４は、端末４１０からの受信開始通知に応じて、サーバ４３０が行う処理のフローチャートである。
ステップＳ１００１でサーバ４３０の端末管理部４３６は、端末４１０から、受信開始通知を受信する。より具体的には、図２０のステップＳ９０８のように、端末管理部４３６は、端末４１０の受信部４１３から受信開始通知を受信する。
【０３０８】
なお、受信開始通知は、ステップＳ９０８に関して説明したとおり、コントローラのインストール先である端末４１０の、ＩＰアドレスとＵＵＩＤを含む。また、受信開始通知は、端末４１０のＯＳを示す情報も含み、端末４１０が受信を待っている対象のコントローラに対応するサービスを識別する識別情報も含む。
【０３０９】
そして、第３実施形態において同じデバイス３２０から複数回サーバ３３０が受信開始通知を受信する場合があり得るのと類似の理由から、第４実施形態においてもサーバ４３０は、同じ端末３１０から複数回受信開始通知を受信する場合があり得る。
【０３１０】
そこで、端末管理部４３６は、端末４１０から受信開始通知を受信すると、次のステップＳ１００２で、受信開始通知によって通知されたＵＵＩＤと同じＵＵＩＤが格納されたエントリが端末テーブル４３７に存在するか否かを判断する。もしそのようなエントリが端末テーブル４３７にあれば、処理はステップＳ１００３に移行する。逆に、そのようなエントリが端末テーブル４３７になければ、処理はステップＳ１００４に移行する。
【０３１１】
ステップＳ１００３で端末管理部４３６は、ステップＳ１００２で見つけた当該エントリのＩＰアドレスとＯＳとサービスのフィールドを、受信開始通知により通知されたＩＰアドレスとＯＳとサービスの値で上書きする。そして、図２４の処理は終了する。
【０３１２】
また、ステップＳ１００４で端末管理部４３６は、受信開始通知により通知されたＩＰアドレスとＵＵＩＤとＯＳとサービスの値を格納する新規エントリを、端末テーブル４３７に追加する。そして、図２４の処理は終了する。
【０３１３】
図２５は、図２０のステップＳ９０９ａのようなセンサ４４０からの通知に応じて、サーバ４３０が行う処理のフローチャートである。なお、ステップＳ９０９ｂのような要求に応じてサーバ４３０が新規コントローラプログラム４３２を送信する場合については、上記の図２０〜２１についての説明から明らかなので、フローチャートを省略する。
【０３１４】
さて、ステップＳ１１０１でコンテキスト抽出部４３３が、センサ４４０から、図２０のステップＳ９０９ａのように、センサ値と端末ＩＤを受信する。端末ＩＤは、具体的には、ＩＰアドレスまたはＵＵＩＤである。
【０３１５】
次に、ステップＳ１００２でコンテキスト抽出部４３３が、通知されたセンサ値からコンテキスト情報を生成する。ステップＳ１００２におけるコンテキスト情報の生成方法の詳細は、図１８のステップＳ７０２と同様である。そして、コンテキスト抽出部４３３は、生成したコンテキスト情報をコントローラ決定部４３４に通知する。
【０３１６】
また、ステップＳ１１０３でコンテキスト抽出部４３３は、センサ４４０から通知された端末ＩＤを端末管理部４３６に通知する。そして、端末管理部４３６は、通知された端末ＩＤがＵＵＩＤとＩＰアドレスのどちらなのかを判断する。
【０３１７】
通知された端末ＩＤがＵＵＩＤの場合、処理はステップＳ１１０４に移行する。逆に、通知された端末ＩＤがＩＰアドレスの場合、処理はステップＳ１１０５に移行する。
ステップＳ１１０４で端末管理部４３６は、通知されたＵＵＩＤがＵＵＩＤのフィールドに記憶されているエントリが、端末テーブル４３７にあるか否かを判断する。もしそのようなエントリがなければ、図２５の処理は終了する。逆に、通知されたＵＵＩＤがＵＵＩＤのフィールドに記憶されているエントリが見つかれば、端末管理部４３６は、見つけたエントリをコントローラ決定部４３４に通知し、処理はステップＳ１１０６に移行する。
【０３１８】
また、ステップＳ１１０５で端末管理部４３６は、通知されたＩＰアドレスがＩＰアドレスのフィールドに記憶されているエントリが、端末テーブル４３７にあるか否かを判断する。もしそのようなエントリがなければ、図２５の処理は終了する。逆に、通知されたＩＰアドレスがＩＰアドレスのフィールドに記憶されているエントリが見つかれば、端末管理部４３６は、見つけたエントリをコントローラ決定部４３４に通知し、処理はステップＳ１１０６に移行する。
【０３１９】
ステップＳ１１０６でコントローラ決定部４３４は、下記２つの情報の組み合わせと合致するエントリが条件テーブル４３５にあるか否かを判断する。
【０３２０】
・ステップＳ１１０２でコンテキスト抽出部４３３から通知されたコンテキスト情報。
・ステップＳ１１０４またはＳ１１０５で見つかったエントリ（つまり端末管理部４３６から通知されたエントリ）のサービス。
【０３２１】
例えば、センサ４４０から通知された端末ＩＤが、１９２．１６８．０．７というＩＰアドレスだったとする。この場合、図２３の端末テーブル４３７の２番目のエントリがステップＳ１１０５で見つかる。２番目のエントリのサービスのフィールドには、「ドキュメント表示サービス」を示す値が格納されている。また、ステップＳ１１０２では、コンテキスト抽出部４３３が「会議室」というコンテキスト情報をコントローラ決定部４３４に通知したものとする。すると、ステップＳ１１０６でコントローラ決定部４３４は、図２２の条件テーブル４３５において、会議室とドキュメント表示サービスの組み合わせと合致する１番目のエントリを見つける。
【０３２２】
例えば以上のようにして、ステップＳ１１０６においてエントリが見つかった場合、処理はステップＳ１１０７に移行する。逆に、エントリが見つからなければ、図２５の処理は終了する。
【０３２３】
ステップＳ１１０７でコントローラ決定部４３４は、ステップＳ１１０４またはＳ１１０５で端末テーブル４３７において見つかったエントリから、ＩＰアドレスとＵＵＩＤとＯＳの値を取得する。そして、コントローラ決定部４３４は、取得したこれらの値と、ステップＳ１１０６で条件テーブル４３５において見つけたエントリにおける「コントローラ」フィールドの値とを、送信部４３８に通知する。
【０３２４】
最後に、ステップＳ１１０８で送信部４３８は、コントローラ決定部４３４から宛先として通知された端末４１０に対し、コントローラ決定部４３４から通知されたコントローラのデータを送信する。より具体的には、送信部４３８は、コントローラ決定部４３４から通知されたコントローラとＯＳに基づいて、格納部４３１から送信対象のデータ（つまり新規コントローラプログラム４３２を含むデータ）を読み出す。そして、送信部４３８は、通知されたＩＰアドレスを宛先として、読み出したデータを送信する。ステップＳ１１０８の送信は、図２０のステップＳ９１０の送信に対応する。
【０３２５】
なお、ステップＳ１１０４、Ｓ１１０５、またはＳ１１０６で、検索条件に合致するエントリが見つからない場合は、何らかのエラーがある場合である。よって、これらの場合、上記のとおり図２５の処理は終了し、ステップＳ１１０８のような送信は行われない。
【０３２６】
さて、図２６は、端末４１０が行う処理のフローチャートである。図２６は図２０のステップ９０１〜Ｓ９１１に対応する。なお、図２０には、ステップＳ９０９ａが行われる場合とＳ９０９ｂが行われる場合の双方が例示されているが、図２６には、ステップＳ９０９ａが行われる場合の処理手順を例示した。
【０３２７】
さて、ステップＳ１２０１でコントローラ更新サービス４１２が、図２０のステップＳ９０１のようなM-searchメッセージのマルチキャストにより、端末４１０の周辺にあるデバイスのＵＰｎＰサービスを検索する。第２実施形態に関して「対象サービス」が何らかの方法により決められているものと仮定したのと同様に、第４実施形態でも、ステップＳ１２０１で検索する対象のサービスが何らかの方法により決められているものとする。
【０３２８】
もし、例えばデバイス４２０のように、対象サービスを提供するデバイスがあれば、コントローラ更新サービス４１２は図２０のステップＳ９０２のような応答を受信する。この場合、コントローラ更新サービス４１２はさらに、図２０のステップＳ９０３〜Ｓ９０６のようにして、対象サービスを提供するデバイスのデバイス定義ファイルと、対象サービスのサービス定義ファイルを取得する。
【０３２９】
次に、ステップＳ１２０２でコントローラ更新サービス４１２は、ステップＳ１２０１で検索したＵＰｎＰサービスを提供するデバイスが発見されたか否かを判断する。
ステップＳ１２０１でのM-searchメッセージの送信から所定の時間が経過しても、ステップＳ９０２のような応答が１つも受信されない場合、コントローラ更新サービス４１２は、「対象サービスを提供するデバイスは発見されなかった」と判断する。そして、図２６の処理も終了する。
【０３３０】
逆に、ステップＳ９０２のような応答が得られて、デバイス定義ファイルとサービス定義ファイルが取得されていれば、対象サービスを提供するデバイスが存在する。よって、この場合、コントローラ更新サービス４１２は、「対象サービスを提供するデバイスが発見された」と判断し、処理はステップＳ１２０３へと移行する。
【０３３１】
ステップＳ１２０３でコントローラ更新サービス４１２は、受信部４１３を起動する。その際、コントローラ更新サービス４１２は受信部４１３に対して、端末４１０自身のＵＵＩＤと、ステップＳ１２０１で発見したサービスと、サーバ４３０のアドレス（例えばＵＲＩ）を通知する。起動された受信部４１３は、サーバ４３０からデータを受信するための適宜の処理を行う。例えば、受信部４１３は、所定のＴＣＰポートを開放してもよい。ステップＳ１２０３は図２０のステップＳ９０７の受信準備に対応する。
【０３３２】
また、ステップＳ１２０４で受信部４１３は、端末４１０のＩＰアドレスと、端末４１０のＵＵＩＤと、端末４１０のＯＳと、ステップＳ１２０１で発見されたサービスを、サーバ４３０の端末管理部４３６に通知する。ステップＳ１２０４の通知は、図２０のステップＳ９０８の受信開始通知である。
【０３３３】
そして、ステップＳ１２０４での受信開始通知の送信後、端末４１０は、ステップＳ１２０５に示すように、受信部４１３がサーバ４３０からコントローラのプログラム（つまり図２１の新規コントローラプログラム４３２）を受信するまで待つ。ステップＳ１２０４での待機は、図２０において、端末４１０がステップＳ９０８の送信の後、ステップＳ９１０での受信まで待つことに対応する。
【０３３４】
そして、受信部４１３がサーバ４３０から新規コントローラプログラム４３２を受信すると、ステップＳ１２０６で受信部４１３は、受信した新規コントローラプログラム４３２をコントローラ更新サービス４１２に通知する。
【０３３５】
すると、ステップＳ１２０７でコントローラ更新サービス４１２は、受信部４１３から通知された新規コントローラプログラム４３２を端末４１０にインストールする。その結果、ＵＰｎＰ制御部４１１は、サービス４２２を利用するための新規コントローラ４１５が存在する状態となる。したがって、端末４１０のユーザは、端末４１０からサービス４２２を利用することが可能となる。
【０３３６】
以上説明した第４実施形態には、第２実施形態と同様に、動的なコントローラの更新による利便性向上という効果がある。また、コントローラ更新サービス４１２がＵＰｎＰのサービスであるため、第２実施形態と同様に、ＵＰｎＰ用のライブラリを介してコントローラ更新サービス４１２の普及が促進される、という効果もある。さらに、第４実施形態によれば、端末４１０は、コンテキストに応じて、コンテキストに適したサービスを利用するためのコントローラを取得することができ、取得したコントローラを介して、サービスを享受することができる。
【０３３７】
続いて、第５実施形態について説明する。第５実施形態は、第３実施形態と第４実施形態の組み合わせに似ており、具体的には、２台の端末の一方にサービスが動的にインストールされ、他方にコントローラが動的にインストールされる。ただし、第５実施形態では、インストールのタイミングがコンテキストに依存するだけでなく、ある端末にサービスとコントローラのいずれがインストールされるのかという選択も、コンテキストに依存する。以下、図２７〜３９を参照して第５実施形態について詳しく説明する。
【０３３８】
図２７は、第５実施形態の動作シーケンス図である。また、図２８は、第５実施形態のシステム構成図である。図２８に示すように、第５実施形態のシステム５００は、端末５１０と端末５２０とサーバ５３０とセンサ５４０を含む。システム５００内には、端末５１０と端末５２０以外の端末がさらにあってもよく、センサ５４０以外のセンサがさらにあってもよい。図２７は、図２８の端末５１０、端末５２０、サーバ５３０、およびセンサ５４０、ならびに図２８には不図示の端末５５０による動作シーケンスの例を示す。
【０３３９】
端末５１０と端末５２０は、通信機能と、ＵＰｎＰのサービス提供機能と、ＵＰｎＰのコントローラ機能を有し、製造工場からの出荷後にソフトウェアをインストールすることが可能な端末であれば、どのような種類の端末であってもよい。また、端末５５０は、通信機能と、ＵＰｎＰのコントローラ機能を有する端末であれば、どのような種類の端末であってもよい。
【０３４０】
端末５１０と端末５２０と端末５５０のいずれも、例えば、携帯電話、スマートフォン、タブレット端末、ＰＤＡ、ノートＰＣのような携帯端末であってもよいし、デスクトップＰＣであってもよい。また、端末５１０と端末５２０と端末５５０は、ネットワークを介して互いに通信することができる。
【０３４１】
また、以下では、端末５１０と端末５２０が一緒に移動するものとする。例えば、「端末５１０は、あるユーザが携帯するスマートフォンであり、端末５２０は、当該ユーザが携帯するタブレット端末である」という場合、ユーザの移動にともなって端末５１０と端末５２０は一緒に移動する。
【０３４２】
サーバ５３０は、ネットワークを介して、端末５１０、端末５２０、およびセンサ５４０と通信が可能なコンピュータである。
また、センサ５４０は、１種の検出装置である。上記のように一緒に移動する端末５１０と端末５２０が特定の環境に存在する場合に、センサ５４０は、端末５１０と端末５２０が特定の環境に存在することを示す検出通知を送信する。なお、第３〜４実施形態に関する説明と同様に、第５実施形態に関する説明においても、環境のことを「コンテキスト」ともいう。
【０３４３】
センサ５４０は、特定の環境に予め設置された、無線ＬＡＮアクセスポイントやＲＦＩＤリーダなどの装置であってもよい。この場合、センサ５４０は、一緒に移動する端末５１０と端末５２０の少なくとも一方を検出したときに、上記の検出通知を送信してもよい。
【０３４４】
あるいは、センサ５４０は、端末５１０と端末５２０のどちらかに内蔵されたＧＰＳセンサであってもよい。また、端末５１０と端末５２０の双方に内蔵されたＧＰＳセンサが、それぞれセンサ５４０として利用されてもよい。例えば、ＧＰＳセンサは、定期的に、または不定期に、緯度と経度を送信してもよい。端末５１０と端末５２０が特定の環境に存在する場合、緯度と経度は特定の値を持つので、上記のようにしてＧＰＳセンサが送信する緯度と経度は、検出通知の１種として利用可能である。
【０３４５】
さて、端末５１０と端末５２０とサーバ５３０のさらなる詳細は、後ほど図２８を参照して説明することにして、先に図２７の動作シーケンス図について説明する。
第５実施形態の端末５１０と端末５２０は、サービスをインストールする機能とコントローラをインストールする機能を有する、ＵＰｎＰのサービス（以下、「更新サービス」という）を提供する。図２７の動作シーケンスは、更新サービスを提供する１台の端末が、更新サービスを提供する他の端末を探索する処理から始まる。図２７の例では、端末５１０がステップＳ１３０１で探索を行うが、端末５１０と端末５２０は対称的なので、場合によっては、端末５２０が探索を行うこともあり得る。
【０３４６】
具体的には、ステップＳ１３０１で端末５１０が、M-searchメッセージをマルチキャストすることにより、更新サービスを探索する。上記のとおり端末５２０も更新サービスを提供しているので、ステップＳ１３０２では、端末５２０が端末５１０に応答を返す。ステップＳ１３０２の応答は、具体的には、「ＯＫ」という意味を示す「２００」というステータスコードを含むＨＴＴＰ応答である。
【０３４７】
端末５１０は、ステップＳ１３０２の応答を受信すると、次に、ステップＳ１３０３で端末５２０のデバイス定義を要求する。すると、デバイス５２０は、ステップＳ１３０４でデバイス定義ファイルを端末５１０に送信する。
【０３４８】
端末５１０は、デバイス定義ファイルを受信すると、更新サービスにアクセスするための情報を得ることができる。そこで、次のステップＳ１３０５で端末５１０は、端末５２０の提供する更新サービスに関するサービス定義ファイルを、端末５２０に要求する。すると、端末５２０は、ステップＳ１３０６でサービス定義ファイルを端末５１０に送信する。
【０３４９】
なお、ステップＳ１３０１〜Ｓ１３０６は、図１のステップＳ１０１〜Ｓ１０６と類似なので、上記の説明では詳細を割愛した。
さて、次のステップＳ１３０７で端末５１０は、検出した更新サービスに対してコマンドを送信する。ステップＳ１３０７で送信されるコマンドは、「サービスまたはコントローラのデータがサーバ５３０から将来送信されてくるのに備えて、データを受信する準備を行うように」と端末５２０に促すためのコマンドである。よって、ステップＳ１３０７のコマンドを、以下では、第３〜４実施形態と同様に「受信準備コマンド」という。
【０３５０】
受信準備コマンドは、サーバ５３０のアドレスを含み、端末５２０に対してサーバ５３０のアドレスを通知する役目も果たす。また、第５実施形態における受信準備コマンドも、具体的にはＳＯＡＰコマンドの形式で送信される。
【０３５１】
端末５２０は、受信準備コマンドを受信すると、次にステップＳ１３０８で端末５１０に応答を返す。ステップＳ１３０８での応答は、具体的には、「ＯＫ」という意味を示す「２００」というステータスコードを含むＨＴＴＰ応答である。
【０３５２】
このＨＴＴＰ応答のメッセージボディには、端末５２０に関する情報が含まれる。具体的には、端末５２０のＩＰアドレスと、端末５２０のＵＵＩＤと、端末５２０の種別と、端末５２０のＯＳを表す情報が、ＨＴＴＰ応答のメッセージボディに含まれる。なお、「端末５２０の種別」とは、例えば、携帯電話、スマートフォン、タブレット端末、ノートＰＣなどの種別である。
【０３５３】
さらに、ステップＳ１３０９で端末５２０は、サーバ５３０からサービスまたはコントローラのデータを受信するための準備を行う。例えば、ステップＳ１３０９の受信準備は、所定のＴＣＰポートを開放する処理を含んでもよい。また、端末５１０も同様に、ステップＳ１３１０で受信準備を行う。
【０３５４】
さらに、端末５１０は、ステップＳ１３０８の応答を受信した後、ステップＳ１３１１で、サーバ５３０に通知を送る。以下では説明の便宜上、ステップＳ１３１１の通知のことも「受信開始通知」という。第５実施形態における受信開始通知は、端末５１０に関する情報（具体的には、端末５１０のＩＰアドレス、ＵＵＩＤ、ＯＳ、および種別）と、端末５２０に関する情報（具体的には、端末５１０のＩＰアドレス、ＵＵＩＤ、ＯＳ、および種別）を含む。そして、以上の情報を含む受信開始通知は、端末５１０と端末５２０がペアを組んでいることを表してもいるし、また、端末５１０と端末５２０がサーバ５３０からのデータの受信に備えていることを表してもいる。
【０３５５】
なお、以下のステップＳ１３１２ａ〜Ｓ１３１７ｂに例示するように、ペアを組んだ端末５１０と端末５２０の一方にやがてサービスがインストールされ、他方にコントローラがインストールされる。
【０３５６】
また、ペアを組んだ端末５１０と端末５２０の双方から重複して受信開始通知を送る必要はないため、第５実施形態では、ステップＳ１３０１の探索を行った方の端末５１０が、サーバ５３０に受信開始通知を送信する。しかし、実施形態によっては、探索に応答する方の端末５２０が、サーバ５３０に受信開始通知を送信してもよい。あるいは、端末５１０と端末５２０のそれぞれが受信開始通知を送信する実施形態も可能である。
【０３５７】
さて、第５実施形態では、第３〜第４実施形態と同様に、ステップＳ１３１１で受信開始通知が送信された後、サービスとコントローラのデータがすぐにサーバ５３０から送信されるとは限らない。サーバ５３０は、ステップＳ１３１２ａまたはＳ１３１２ｂのようなトリガを検出してはじめて、サービスとコントローラのデータを送信する。
【０３５８】
例えば、センサ５４０が所定の場所に固定的に設置されている場合、センサ５４０は、端末５１０または端末５２０を検出すると、ステップＳ１３１２ａのように、センサ値と、検出した端末の端末ＩＤとをサーバ５３０に送信する。この場合、センサ値は、センサ５４０の識別情報であってもよい。サーバ５３０は、センサ５４０の識別情報とセンサ５４０の設置場所を対応づけるデータベースを参照することで、端末５１０または端末５２０が検出された環境（すなわちセンサ５４０の固定的な設置場所）を判別することができる。
【０３５９】
あるいは、センサ５４０が端末５１０に内蔵されている場合、センサ５４０は、定期的に、または不定期に、ステップＳ１３１２ａのように、センサ値と端末５１０の端末ＩＤをサーバ５３０に送信する。同様に、センサ５４０が端末５２０に内蔵されている場合、センサ５４０は、定期的に、または不定期に、ステップＳ１３１２ａのように、センサ値と端末５２０の端末ＩＤをサーバ５３０に送信する。
【０３６０】
例えばセンサ値が緯度と経度の組み合わせである場合、サーバ５３０は、地図データを参照することにより、センサ５４０を内蔵する端末の存在する環境を判別することができる。なお、上記のとおり、第５実施形態では端末５１０と端末５２０が一緒に移動するものとする。つまり端末５１０と端末５２０は同じ環境にあるものとする。
【０３６１】
センサ５４０の種類が何であれ、図２７の例では、ステップＳ１３１２ａで通知されたセンサ値が、「端末５１０と端末５２０が特定の環境に存在している」と示す値であったものとする。また、端末ＩＤは、端末のＩＰアドレスでもよいし、端末のＵＵＩＤでもよいし、両者の組み合わせでもよい。
【０３６２】
なお、ステップＳ１３１２ａのようにセンサ５４０が通知を送信する代わりに、ステップＳ１３１２ｂのように、端末５１０がセンサ５４０に対して、「端末５１０と端末５２０の一方にサービスのデータを送信し、他方にコントローラを送信せよ」と要求してもよい。
【０３６３】
例えば、場合によっては、実際のセンサ値が得られない環境もあるかもしれない。また、ユーザは、「実際のセンサ値と関係なく、端末５１０と端末５２０が特定の環境にあるものと見なして、当該特定の環境に適したサービスを受けたい」と思うかもしれない。
【０３６４】
よって、端末５１０は、ステップＳ１３１２ｂのように要求を送信してもよい。また、ステップＳ１３１２ｂの要求には、特定の環境を指定する情報（つまりコンテキスト情報）と、端末５１０の端末ＩＤと、端末５２０の端末ＩＤが含まれる。例えば、端末５１０は、いくつかの環境を選択肢として含むリストをユーザに提示してもよい。そして、端末５１０は、ユーザからの入力に基づいて、ユーザの選択した環境を指定する情報を要求に含めてもよい。
【０３６５】
そして、ステップＳ１３１２ａの通知またはステップＳ１３１２ｂの要求の受信に応じて、サーバ５３０は、どちらの端末にサービスのデータを送信し、どちらの端末にコントローラのデータを送信するかを決定する。サーバ５３０による決定は、センサ値またはステップＳ１３１２ｂの要求から得られるコンテキスト情報と、端末５１０に関する情報（具体的には種別）と、端末５２０に関する情報（具体的には種別）とに基づく。
【０３６６】
なお、図２７におけるステップＳ１３１３ａ〜Ｓ１３１７ａは、サーバ５３０が「端末５１０にコントローラのデータを送信し、端末５２０にサービスのデータを送信する」と決定した場合のシーケンスを示す。逆に、サーバ５３０が「端末５１０にサービスのデータを送信し、端末５２０にコントローラのデータを送信する」と決定した場合のシーケンスは、ステップＳ１３１３ｂ〜Ｓ１３１７ｂとして例示されている。
【０３６７】
具体的には、ステップＳ１３１３ａでサーバ５３０は、コンテキストに応じたコントローラのデータ（具体的にはコントローラのプログラムを含むデータ）を端末５１０に送信する。すると、次のステップＳ１３１４ａで端末５１０は、コントローラを端末５１０自身にインストールする。
【０３６８】
また、ステップＳ１３１５ａでサーバ５３０は、上記コントローラに対応するサービスのデータ（具体的にはサービスのプログラムとサービス定義ファイルを含むデータ）を端末５２０に送信する。すると、次のステップＳ１３１６ａで端末５２０は、サービスを端末５２０自身にインストールする。さらに、ステップＳ１３１７ａで端末５２０は、図１のステップＳ１１２と同様にして、ＧＥＮＡにより、サービス追加・更新イベントを通知する。図２７の例では、端末５１０と端末５５０にサービス追加・更新イベントが通知される。
【０３６９】
なお、ステップＳ１３１３ａとＳ１３１５ａの送信の順序は逆でもよく、端末５１０における処理と端末５２０における処理は独立して行われる。また、以上のステップＳ１３１３ａ〜Ｓ１３１７ａの結果として、ユーザは、端末５２０にインストールされたサービスを、端末５１０のコントローラを介して利用することができるようになる。
【０３７０】
以上のステップＳ１３１３ａ〜Ｓ１３１７ａとは逆に、ステップＳ１３１３ｂ〜Ｓ１３１７ｂでは、次のような処理が行われる。
まず、ステップＳ１３１３ｂでサーバ５３０は、コンテキストに応じたサービスのデータを端末５１０に送信する。すると、次のステップＳ１３１４ｂで端末５１０は、サービスを端末５１０自身にインストールする。さらに、ステップＳ１３１５ｂで端末５１０は、ＧＥＮＡにより、サービス追加・更新イベントを通知する。図２７の例では、端末５２０と端末５５０にサービス追加・更新イベントが通知される。
【０３７１】
また、ステップＳ１３１６ｂでサーバ５３０は、上記サービスに対応するコントローラのデータを端末５２０に送信する。すると、次のステップＳ１３１７ｂで端末５２０は、コントローラを端末５２０自身にインストールする。
【０３７２】
なお、ステップＳ１３１３ｂとＳ１３１６ｂの送信の順序は逆でもよく、端末５１０における処理と端末５２０における処理は独立して行われる。また、以上のステップＳ１３１３ｂ〜Ｓ１３１７ｂの結果として、ユーザは、端末５１０にインストールされたサービスを、端末５２０のコントローラを介して利用することができるようになる。
【０３７３】
続いて、図２８を参照して、端末５１０と端末５２０とサーバ５３０の詳細について説明する。
図２８に示すように、端末５１０はＵＰｎＰ制御部５１１を有し、端末５２０はＵＰｎＰ制御部５２１を有する。ＵＰｎＰ制御部５１１には既存コントローラ５１２があってもよく、なくてもよい。同様に、ＵＰｎＰ制御部５２１には既存コントローラ５２２があってもよく、なくてもよい。
【０３７４】
また、端末５１０はＵＰｎＰサービス提供部５１３を有し、端末５２０はＵＰｎＰサービス提供部５２３を有する。ＵＰｎＰサービス提供部５１３は、既存サービス５１４を提供していてもよく、提供していなくてもよい。同様に、ＵＰｎＰサービス提供部５２３は、既存サービス５２４を提供していてもよく、提供していなくてもよい。
【０３７５】
また、ＵＰｎＰサービス提供部５１３は更新サービス５１５を提供し、ＵＰｎＰサービス提供部５２３は更新サービス５２５を提供する。更新サービス５１５と５２５は、ＵＰｎＰのサービスとコントローラのどちらのプログラムが指定された場合にも、指定されたプログラムをインストールすることのできる、ＵＰｎＰのサービスである。また、更新サービス５１５と５２５は、さらに、指定されたサービスまたはコントローラをアンインストールする機能を備えていてもよい。
【０３７６】
さらに、端末５１０は受信部５１６を有する。受信部５１６は、サーバ５３０から新規サービス５１８のデータまたは新規コントローラ５１９のデータを受信するのを待ち、データを受信すると、更新サービス５１５に受信を通知する。
【０３７７】
同様に、端末５２０は受信部５２６を有する。受信部５２６は、サーバ５３０から新規サービス５２８のデータまたは新規コントローラ５２９のデータを受信するのを待ち、データを受信すると、更新サービス５２５に受信を通知する。
【０３７８】
なお、端末５１０は、図２７のステップＳ１３１２ｂのような要求を送信する要求部５１７を有していてもよい。要求部５１７は、ステップＳ１３１２ｂの要求に指定する環境をユーザに指定させるための処理も行う。端末５２０も、要求部５１７と同様の要求部５２７を有していてもよい。しかし、要求部５１７と要求部５２７はなくてもよい。
【０３７９】
図２８に示す端末５１０と端末５２０の各部と図２７との関係は次のとおりである。
例えば、更新サービス５１５は、図２７のステップＳ１３０１の探索、ステップＳ１３０２の応答の受信、ステップＳ１３０３の要求、ステップＳ１３０４の受信、ステップＳ１３０５の要求、およびステップＳ１３０６の受信を行う。実施形態によっては、以上のステップＳ１３０１〜Ｓ１３０６の更新サービス５１５の動作を、既存コントローラ５１２が代わりに行ってもよい。
【０３８０】
そして、ステップＳ１３０２の応答、ステップＳ１３０３の要求の受信、ステップＳ１３０４の送信、ステップＳ１３０５の要求の受信、およびステップＳ１３０６の送信は、ＵＰｎＰサービス提供部５２３が行う。その後のステップＳ１３０７では、更新サービス５１５が受信準備コマンドを送信し、更新サービス５２５が受信準備コマンドを受信する。
【０３８１】
さらに、更新サービス５２５は、ステップＳ１３０８で応答を送信し、受信部５２６を起動する。そして、受信部５２６がステップＳ１３０９の受信準備を行う。
また、ステップＳ１３０８の応答は更新サービス５１５により受信される。そして、更新サービス５１５は受信部５１６を起動し、受信部５１６がステップＳ１３１０の受信準備を行う。また、受信部５１６は、ステップＳ１３１１で受信開始通知を送信する。
【０３８２】
なお、上記のように、ステップＳ１３１２ｂで要求部５１７が要求を送信してもよい。
その後は、状況に応じて、ステップＳ１３１３ａで受信部５１６が新規コントローラ５１９のデータを受信し、ステップＳ１３１４ａで更新サービス５１５が新規コントローラ５１９のインストールを実行する場合もある。または、ステップＳ１３１３ｂで受信部５１６が新規サービス５１８のデータを受信し、ステップＳ１３１４ｂで更新サービス５１５が新規サービス５１８のインストールを実行し、ステップＳ１３１５ｂで更新サービス５１５が通知を送信する場合もある。
【０３８３】
端末５２０に関しても同様に、状況に応じた動作が行われる。具体的には、ステップＳ１３１５ａで受信部５２６が新規サービス５２８のデータを受信し、ステップＳ１３１６ａで更新サービス５２５が新規サービス５２８のインストールを実行し、ステップＳ１３１７ａで更新サービス５２５が通知を送信する場合もある。または、ステップＳ１３１６ｂで受信部５２６が新規コントローラ５２９のデータを受信し、ステップＳ１３１７ｂで更新サービス５２５が新規コントローラ５２９のインストールを実行する場合もある。
【０３８４】
さて、サーバ５３０は、格納部５３１を有する。格納部５３１には、新規サービス５１８または５２８を提供するためのプログラムである新規サービスプログラム５３２と、新規コントローラ５１９または５２９を提供するためのプログラムである新規コントローラプログラム５３３が、格納されている。
【０３８５】
なお、簡単化のため、図２８には１つの新規サービスプログラム５３２と１つの新規コントローラプログラム５３３のみが図示されている。しかし、格納部５３１は、複数のサービスそれぞれのプログラムと、それら複数のサービスに対応する複数のコントローラそれぞれのプログラムを格納していてもよい。格納部５３１は、例えば、サービスを識別する情報と対応づけて、当該サービスのプログラムと、当該サービスを利用するためのコントローラのプログラムとを格納していてもよい。
【０３８６】
また、プログラムはＯＳに依存することがある。そのため、格納部５３１は、サービスを識別する情報だけでなく、ＯＳを表す情報とも対応づけて、新規サービスプログラム５３２および新規コントローラプログラム５３３を格納していてもよい。
【０３８７】
さて、サーバ５３０は、図２７のステップＳ１３１２ａでセンサ５４０から送信されるセンサ値から、コンテキストを抽出するコンテキスト抽出部５３４をさらに有する。コンテキスト抽出部５３４の詳細は、第３実施形態のコンテキスト抽出部３３３と同様なので、詳しい説明は省略する。第５実施形態のコンテキスト抽出部５３４も、実施形態に応じた適宜の粒度のコンテキストを抽出することができる。
【０３８８】
サーバ５３０はさらに決定部５３５を有する。決定部５３５は、送信対象のサービスと送信対象のコントローラを決定する。また、決定部５３５は、端末５１０と端末５２０のどちらにサービスを送信するか（換言すれば、端末５１０と端末５２０のどちらにコントローラを送信するか）も決定する。決定部５３５は、具体的には、条件テーブル５３６を参照することで、決定を下す。
【０３８９】
図２９に、条件テーブル５３６の具体例を示す。図２９に示すように、条件テーブル５３６は、以下の５つの項目を対応づけるテーブルである。
【０３９０】
・コンテキスト
・サービスのインストール先の端末（以下「サービス提供端末」ともいう）の種別
・コントローラのインストール先の端末（以下「コントローラ端末」ともいう）の種別
・コンテキストに応じたサービス（つまりサービス提供端末にインストールする対象のサービス）
・上記サービスを利用するためのコントローラ（つまりコントローラ端末にインストールする対象のコントローラ）
【０３９１】
なお、図２９では、理解を容易にするために、上記５つの項目がいずれも名前で表現されているが、適宜のコード番号やＩＤが代わりに使われてもよい。
【０３９２】
図２９には、条件テーブル５３６の２つのエントリが例示されている。１番目のエントリでは、「会議室」というコンテキストと、タブレット端末と、スマートフォンと、ドキュメント表示サービスと、ドキュメントページめくりコントローラが対応づけられている。２番目のエントリでは、「自宅」というコンテキストと、デスクトップＰＣと、スマートフォンと、ビデオ録画サービスと、ビデオリモコンコントローラが対応づけられている。
【０３９３】
例えば、図２７のステップＳ１３１２ａで通知された端末ＩＤで識別される端末５１０の種別、および、端末５１０とペアを組んでいる端末５２０の種別は、ステップＳ１３１１で既にサーバ５３０に通知されている。通知された種別が、例えば、スマートフォンとタブレット端末だとする。また、ステップＳ１３１２ａでは、端末５１０または端末５２０のうち、センサ５４０により検出された方の端末ＩＤが通知されるものとする。そして、ステップＳ１３１２ａで通知されたセンサ値から、コンテキスト抽出部５３４が「会議室」というコンテキストを抽出したとする。
【０３９４】
すると、決定部５３５は、センサ５４０からサーバ５３０に通知された端末ＩＤから、端末５１０と端末５２０のペアを認識し、端末５１０と端末５２０の種別を認識する。そして、決定部５３５は、「会議室」というコンテキストと、「スマートフォン」という種別と、「タブレット端末」という種別の組み合わせに合致するエントリを条件テーブル５３６において検索する。なお、端末５１０の種別がサービス提供端末の種別に合致し、端末５２０の種別がコントローラ端末の種別に合致する場合と、逆に、端末５１０の種別がコントローラ端末の種別に合致し、端末５２０の種別がサービス提供端末の種別に合致する場合があり得る。検索の結果、図２９の例では、１番目のエントリが見つかる。したがって、決定部５３５は、見つかった１番目のエントリに基づいて、次のように決定する。
【０３９５】
・端末５１０と端末５２０のうち、種別がタブレット端末である方が、サービスのデータの送信先である。
・端末５１０と端末５２０のうち、種別がスマートフォンである方が、コントローラのデータの送信先である。
・送信対象のサービスは、ドキュメント表示サービスである。
・送信対象のコントローラは、ドキュメントページめくりコントローラである。
【０３９６】
ここで、再度図２８の説明に戻ると、サーバ５３０はさらに、受信準備の整った端末（図２７の例では端末５１０と端末５２０）の情報を管理する端末管理部５３７を有する。端末管理部５３７は、具体的には、端末テーブル５３８を用いて、端末についての情報を管理する。
【０３９７】
図３０に、端末テーブル５３８の具体例を示す。端末テーブル５３８の各エントリは、１台の端末に対応する。図３０には、４台の端末にそれぞれ対応する４つのエントリが例示されている。各エントリは、「ＩＰアドレス」、「ＵＵＩＤ」、「ＯＳ」、「種別」、および「子端末ＵＵＩＤ」という５つのフィールドを含む。
【０３９８】
以下では説明の便宜上、図２７のステップＳ１３０１〜Ｓ１３０８のような処理によりペアを組んだ２台の端末のうち、ステップＳ１３１１で受信開始通知を送信する方の端末を「親端末」または「親」といい、他方の端末を「子端末」または「子」という。なお、親子関係は、端末管理部５３７による管理の便宜上の関係にすぎない。つまり、親端末にサービスがインストールされて子端末にコントローラがインストールされる場合もあるし、逆に、親端末にコントローラがインストールされて子端末にサービスがインストールされる場合もある。
【０３９９】
端末テーブル５３８のあるエントリが、ある端末Ｘに関するエントリであるとする。この場合、ＩＰアドレス、ＵＵＩＤ、ＯＳ、および種別の各フィールドには、端末ＸのＩＰアドレス、端末ＸのＵＵＩＤ、端末ＸのＯＳ、および端末Ｘの種別が記録される。また、子端末ＵＵＩＤのフィールドには、端末Ｘが他の端末Ｙの親である場合は、端末ＹのＵＵＩＤが記録される。逆に、端末Ｘが他の端末Ｚの子である場合は、端末Ｘ自身は子を持たないので、端末Ｘに関するエントリにおける子端末ＵＵＩＤの値は、ＮＵＬＬである。
【０４００】
図３０の端末テーブル５３８の例では、１番目のエントリの子端末ＵＵＩＤの値が２番目のエントリのＵＵＩＤとして記録されている。そして、２番目のエントリの子端末ＵＵＩＤの値はＮＵＬＬである。つまり、１番目のエントリで表される端末と２番目のエントリで表される端末はペアを組んでおり、前者が親端末、後者が子端末である。
【０４０１】
また、３番目のエントリの子端末ＵＵＩＤの値が４番目のエントリのＵＵＩＤとして記録されており、４番目のエントリの子端末ＵＵＩＤの値はＮＵＬＬである。つまり、３番目のエントリで表される端末と４番目のエントリで表される端末はペアを組んでおり、前者が親端末、後者が子端末である。
【０４０２】
ここで、再度図２８の説明に戻ると、サーバ５３０はさらに送信部５３９を有する。送信部５３９は、決定部５３５の決定にしたがって、格納部５３１から適宜の新規サービスプログラム５３２を読み出して、新規サービスプログラム５３２とサービス定義ファイルを含むデータを、サービス提供端末に送信する。また、送信部５３９は、決定部５３５の決定にしたがって、格納部５３１から適宜の新規コントローラプログラム５３３を読み出して、新規コントローラプログラム５３３を含むデータを、コントローラ端末に送信する。
【０４０３】
さて次に、図３１を参照して、サービスとコントローラ双方の更新機能を持つ更新サービス５２５がインストールされた端末５２０に関するデバイス定義ファイルの例について説明する。
【０４０４】
図３１のデバイス定義ファイル５６０は、新規サービス５２８のインストールにともなって更新されたデバイス定義ファイルの例である。より具体的には、図３１の例においては、新規サービス５２８は、ドキュメント表示サービスである。
【０４０５】
図３１のデバイス定義ファイル５６０は、図３のデバイス定義ファイル１５０と類似である。具体的には、デバイス定義ファイル５６０の５〜９行目には、端末５２０全体に関する情報が記載されており、１０〜２５行目には、端末５２０が提供するサービスのリストが記載されている。
【０４０６】
図３１の例では、１０〜２５行目のリストは、１１〜１７行目の更新サービス５２５に関する情報と、１８〜２４行目のドキュメント表示サービスに関する情報を含む。図３１の１１〜１７行目の内容は、図３のデバイス定義ファイル１５０の１１〜１７行目のサービス更新サービス１２２に関する情報の内容とは異なるが、形式は同じである。よって、図３１については、詳しい説明を省略する。
【０４０７】
以上のようなデバイス定義ファイル５６０が、図２７のステップＳ１３０４で端末５２０から端末５１０に送信される。また、図示は省略するが、更新サービス５１５がインストールされた端末５１０のデバイス定義ファイルも、図３１のデバイス定義ファイル５６０と同様である。
【０４０８】
次に、図３２を参照して、更新サービス５２５のサービス定義ファイルについて説明する。更新サービス５２５のサービス定義ファイルは、例えば、図３２のサービス定義ファイル５６１のようなファイルであってもよい。サービス定義ファイル５６１は、以下のような定義を含む。
【０４０９】
・サービス更新サービス１２２についての図４のサービス定義ファイル１５１と同様の、「UpdateService」というアクションの定義。
・サービス定義ファイル１５１と同様の、「DeleteService」というアクションの定義。
・サービス定義ファイル１５１と同様の、「Listen」というアクションの定義。
・コントローラ更新サービス２１２についての図１１のサービス定義ファイル２４１と同様の、「UpdateController」というアクションの定義。
・サービス定義ファイル２４１と同様の、「DeleteController」というアクションの定義。
・サービス定義ファイル１５１と同様の、「GetUpdateTime」というアクションの定義。
・サービス定義ファイル１５１および２４１と同様の、「ServiceName」、「ServerUri」、および「Listening」という状態変数の定義。
・サービス定義ファイル１５１と同様の、「ServiceUri」および「UpdateTime」という状態変数の定義。
【０４１０】
もちろん、実施形態によっては別のサービス定義ファイルが使われてもよい。また、端末５１０の更新サービス５１５についてのサービス定義ファイルも、更新サービス５２５のサービス定義ファイルと同様である。なお、図２７のステップＳ１３０７の受信準備コマンドは、具体的には「Listen」というアクションが指定されたＳＯＡＰコマンドである。
【０４１１】
ところで、図２７の処理は、サーバ５３０が図３３〜３７のフローチャートにしたがって動作し、端末５１０が図３８〜３９のフローチャートにしたがって動作し、端末５２０が図３９のフローチャートにしたがって動作することにより、実現される。具体的には以下のとおりである。
【０４１２】
図３３〜３５は、端末からの受信開始通知に応じてサーバ５３０が行う処理のフローチャートである。なお、サーバ５３０は、図２７のステップＳ１３１１のように親端末からの受信開始通知を受信することがあるだけでなく、親端末または子端末の受信部から、受信開始通知と同様の形式の通知（以下では、当該通知も「受信開始通知」という）を受信することもある。
【０４１３】
例えば、ＤＨＣＰによってＩＰアドレスが割り当てられている端末は、再起動後にＩＰアドレスが変化する可能性がある。そこで、端末は、再起動後に、ＩＰアドレスをサーバ５３０に通知するために、受信開始通知を送信してもよい。また、ＯＳがアップグレードされた後に、端末は、新しいＯＳをサーバ５３０に通知するために、受信開始通知を送信してもよい。
【０４１４】
ここで、ある端末Ｘからの受信開始通知は、以下の８つの項目を含む。
・端末ＸのＩＰアドレスを示す「端末ＩＰアドレス」。
・端末ＸのＵＵＩＤを示す「端末ＵＵＩＤ」。
・端末ＸのＯＳを示す「端末ＯＳ」。
・端末Ｘの種別を示す「端末種別」。
・端末Ｘが他の端末Ｙの親である場合は端末ＹのＩＰアドレスを示し、端末Ｘが他の端末Ｚの子である場合はＮＵＬＬである「子端末ＩＰアドレス」。
・端末Ｘが他の端末Ｙの親である場合は端末ＹのＵＵＩＤを示し、端末Ｘが他の端末Ｚの子である場合はＮＵＬＬである「子端末ＵＵＩＤ」。
・端末Ｘが他の端末Ｙの親である場合は端末ＹのＯＳを示し、端末Ｘが他の端末Ｚの子である場合はＮＵＬＬである「子端末ＯＳ」。
・端末Ｘが他の端末Ｙの親である場合は端末Ｙの種別を示し、端末Ｘが他の端末Ｚの子である場合はＮＵＬＬである「子端末種別」。
【０４１５】
また、上記のように受信開始通知は、図２７のステップＳ１３１１で送信される場合があるだけでなく、任意のタイミングで送信され得るし、子端末からも送信され得る。しかも、例えば、第１と第２の端末がペアを組んだ後、第２の端末が、第３の端末からの更新サービスの探索に応えて、第３の端末とペアを組みなおすかもしれない。同様に、第１の端末が第３の端末とペアを組みなおすこともあり得る。新たなペアが組まれるたびに、ステップＳ１３１１と同様の受信開始通知がサーバ５３０において受信される。
【０４１６】
そこで、第５実施形態では、新たなペアが組まれた場合、サーバ５３０の端末管理部５３７は、古いペアの情報（すなわち端末テーブル５３８上の既存エントリ）を適宜更新または削除し、必要に応じて新規エントリを追加することで、情報の整合性を保つ。図３３〜３５の処理は、情報の整合性を保つための処理である。
【０４１７】
具体的には、ある端末Ｘからの受信開始通知をサーバ５３０の端末管理部５３７が受信する場合としては、以下の１２通りの場合（便宜上、「ケースＡ」〜「ケースＬ」という）があり得る。図３３〜３５の概要を明らかにするため、まず、ケースＡ〜Ｌについて説明する。なお以下のケースＡ〜Ｌの説明における「登録」とは、具体的には、端末テーブル５３８への登録である。
【０４１８】
ケースＡは次のような場合である。
・端末Ｘは、現在、端末Ｃ０の親として登録されている。
・現在、端末Ｐ１が端末Ｃ１の親として登録されている。
・しかし、今回、端末Ｘは端末Ｐ１を端末Ｘの子として通知してきた。
【０４１９】
ケースＡで端末管理部５３７は、端末Ｃ０と端末Ｃ１の登録を削除し、端末Ｘと端末Ｐ１を対応づけ、端末Ｘと端末Ｐ１についての登録済みの情報を通知にしたがって更新する。
【０４２０】
ケースＢは次のような場合である。
・端末Ｘは、現在、端末Ｃ０の親として登録されている。
・今回、端末Ｘは端末Ｃ０を端末Ｘの子として通知してきた。
【０４２１】
ケースＢで端末管理部５３７は、単純に、端末Ｘと端末Ｃ０についての登録済みの情報を通知にしたがって更新する。
【０４２２】
ケースＣは次のような場合である。
・端末Ｘは、現在、端末Ｃ０の親として登録されている。
・現在、端末Ｃ１が端末Ｐ１の子として登録されている。
・しかし、今回、端末Ｘは端末Ｃ１を端末Ｘの子として通知してきた。
【０４２３】
ケースＣで端末管理部５３７は、端末Ｃ０と端末Ｐ１の登録を削除し、端末Ｘと端末Ｃ１を対応づけ、端末Ｘと端末Ｃ１についての登録済みの情報を通知にしたがって更新する。
【０４２４】
ケースＤは次のような場合である。
・端末Ｘは、現在、端末Ｃ０の親として登録されている。
・端末Ｕは未登録の端末である。
・今回、端末Ｘは端末Ｕを端末Ｘの子として通知してきた。
【０４２５】
ケースＤで端末管理部５３７は、端末Ｃ０の登録を削除し、端末Ｕを新たに登録し、端末Ｘと端末Ｕを対応づけ、端末Ｘについての登録済みの情報を通知にしたがって更新する。
【０４２６】
ケースＥは次のような場合である。
・端末Ｘは、現在、端末Ｃ０の親として登録されている。
・今回、端末Ｘは、端末Ｘ自身がいずれかの端末の子であるものとして、端末Ｘ自身の情報を通知してきた。
【０４２７】
ケースＥで端末管理部５３７は、端末Ｃ０の登録を削除し、端末Ｘについての情報を通知にしたがって更新する。
【０４２８】
ケースＦは次のような場合である。
・端末Ｘは、現在、端末Ｐ０の子として登録されている。
・現在、端末Ｐ１が端末Ｃ１の親として登録されている。
・しかし、今回、端末Ｘは端末Ｐ１を端末Ｘの子として通知してきた。
【０４２９】
ケースＦで端末管理部５３７は、端末Ｐ０と端末Ｃ１の登録を削除し、端末Ｘと端末Ｐ１を対応づけ、端末Ｘと端末Ｐ１についての登録済みの情報を通知にしたがって更新する。
【０４３０】
ケースＧは次のような場合である。
・端末Ｘは、現在、端末Ｐ０の子として登録されている。
・現在、端末Ｃ１が端末Ｐ１の子として登録されている。
・しかし、今回、端末Ｘは端末Ｃ１を端末Ｘの子として通知してきた。
【０４３１】
ケースＧで端末管理部５３７は、端末Ｐ０と端末Ｐ１の登録を削除し、端末Ｘと端末Ｃ１を対応づけ、端末Ｘと端末Ｃ１についての登録済みの情報を通知にしたがって更新する。
【０４３２】
ケースＨは次のような場合である。
・端末Ｘは、現在、端末Ｐ０の子として登録されている。
・端末Ｕは未登録の端末である。
・今回、端末Ｘは端末Ｕを端末Ｘの子として通知してきた。
【０４３３】
ケースＨで端末管理部５３７は、端末Ｐ０の登録を削除し、端末Ｕを新たに登録し、端末Ｘと端末Ｕを対応づけ、端末Ｘについての登録済みの情報を通知にしたがって更新する。
【０４３４】
ケースＩは次のような場合である。
・端末Ｘは、現在、端末Ｐ０の子として登録されている。
・今回、端末Ｘは、端末Ｘ自身の情報を通知してきた。
【０４３５】
ケースＩで端末管理部５３７は、単純に、端末Ｘについての登録済みの情報を通知にしたがって更新する。
【０４３６】
ケースＪは次のような場合である。
・端末Ｘは未登録である。
・現在、端末Ｐ１が端末Ｃ１の親として登録されている。
・しかし、今回、端末Ｘは端末Ｐ１を端末Ｘの子として通知してきた。
【０４３７】
ケースＪで端末管理部５３７は、端末Ｃ１の登録を削除し、端末Ｘを新たに登録し、端末Ｘと端末Ｐ１を対応づけ、端末Ｐ１についての登録済みの情報を通知にしたがって更新する。
【０４３８】
ケースＫは次のような場合である。
・端末Ｘは未登録である。
・現在、端末Ｃ１が端末Ｐ１の子として登録されている。
・しかし、今回、端末Ｘは端末Ｃ１を端末Ｘの子として通知してきた。
【０４３９】
ケースＫで端末管理部５３７は、端末Ｐ１の登録を削除し、端末Ｘを新たに登録し、端末Ｘと端末Ｃ１を対応づけ、端末Ｃ１についての登録済みの情報を通知にしたがって更新する。
【０４４０】
ケースＬは次のような場合である。
・端末Ｘは未登録である。
・端末Ｕも未登録である。
・今回、端末Ｘは端末Ｕを端末Ｘの子として通知してきた。
【０４４１】
ケースＬで端末管理部５３７は、端末Ｘを新たに登録し、端末Ｕも新たに登録し、端末Ｘと端末Ｕを対応づける。
【０４４２】
以上のように端末管理部５３７は、ケースＡ〜Ｌに応じて、端末テーブル５３８を適宜書き換えることで、情報の整合性を保つ。具体的な処理手順は、以下のとおりである。
端末管理部５３７は、ステップＳ１４０１において、いずれかの端末（以下「端末Ｘ」とする）から受信開始通知を受信する。
【０４４３】
すると、次にステップＳ１４０２で端末管理部５３７は、受信開始通知で通知された端末ＵＵＩＤが「ＵＵＩＤ」フィールドに格納されたエントリ（つまり端末Ｘに対応するエントリ）が端末テーブル５３８に存在するか否かを判断する。そして、エントリが見つかった場合（すなわちケースＡ〜Ｉのいずれか）、処理はステップＳ１４０３に移行する。逆に、エントリが見つからなかった場合（すなわちケースＪ〜Ｌのいずれか）、処理は図３５のステップＳ１４１９に移行する。
【０４４４】
ステップＳ１４０３で端末管理部５３７は、ステップＳ１４０２で見つかったエントリの「子端末ＵＵＩＤ」フィールドと、受信開始通知により通知された子端末ＵＵＩＤが同じか否かを判断する。両者の値が等しい場合（すなわちケースＢまたはＩ）、処理はステップＳ１４０４に移行する。逆に、両者の値が異なる場合（すなわちケースＡおよびＣ〜Ｈのうちのいずれか）、処理はステップＳ１４０７に移行する。
【０４４５】
ステップＳ１４０４で端末管理部５３７は、受信開始通知により通知された子端末ＵＵＩＤがＮＵＬＬか否かを判断する。通知された子端末ＵＵＩＤがＮＵＬＬの場合（すなわちケースＩ）、処理はステップＳ１４０５に移行する。逆に、通知された子端末ＵＵＩＤが非ＮＵＬＬの場合（すなわちケースＢ）、処理はステップＳ１４０６に移行する。
【０４４６】
ところで、ステップＳ１４０５は、図３３に示すように、ステップＳ１４０４の判断結果によらず、実行される。つまり、ステップＳ１４０５は、ケースＢでも実行され、ケースＩでも実行される。
【０４４７】
ステップＳ１４０５で端末管理部５３７は、ステップＳ１４０２で見つかったエントリ（つまり端末Ｘ自身に対応するエントリ）を更新する。具体的には、端末管理部５３７は、当該エントリの「ＩＰアドレス」、「ＯＳ」、および「種別」の各フィールドを、受信開始通知により通知された端末ＩＰアドレス、端末ＯＳ、および端末種別の値で上書きする。そして、図３３〜３５の処理は終了する。
【０４４８】
また、ステップＳ１４０６はケースＢにおいて実行される。ステップＳ１４０６で端末管理部５３７は、端末テーブル５３８において、受信開始通知により通知された子端末ＵＵＩＤが「ＵＵＩＤ」フィールドに格納されているエントリを更新する。つまり、端末管理部５３７は、端末Ｘにとっての子端末Ｃ０に対応するエントリを更新する。
【０４４９】
具体的には、端末管理部５３７は、当該エントリの「ＩＰアドレス」、「ＯＳ」、および「種別」の各フィールドを、受信開始通知により通知された子端末ＩＰアドレス、子端末ＯＳ、および子端末種別の値で上書きする。そして、処理はステップＳ１４０５へと移行する。
【０４５０】
また、ステップＳ１４０７で端末管理部５３７は、ステップＳ１４０２で見つかったエントリ（つまり端末Ｘ自身に対応するエントリ）の「子端末ＵＵＩＤ」フィールドがＮＵＬＬか否かを判断する。「子端末ＵＵＩＤ」フィールドがＮＵＬＬの場合（すなわちケースＦ〜Ｈのいずれか）、処理はステップＳ１４０８に移行する。逆に、「子端末ＵＵＩＤ」フィールドがＮＵＬＬでない場合（すなわちケースＡおよびＣ〜Ｅのうちのいずれか）、処理は図３４のステップＳ１４０９に移行する。
【０４５１】
ステップＳ１４０８で端末管理部５３７は、ステップＳ１４０２で見つかったエントリ（つまり端末Ｘ自身に対応するエントリ）の「ＵＵＩＤ」フィールドと同じ値が「子端末ＵＵＩＤ」フィールドに格納されているエントリを削除する。つまり、端末Ｘにとって今まで親として登録されていた端末Ｐ０に対応するエントリを、端末管理部５３７は削除する。そして、処理は図３４のステップＳ１４１３に移行する。
【０４５２】
さて、図３４のステップＳ１４０９は、ケースＡおよびＣ〜Ｅのうちのいずれかであるとき、実行される。ステップＳ１４０９で端末管理部５３７は、ステップＳ１４０２で見つかったエントリ（つまり端末Ｘ自身に対応するエントリ）の「子端末ＵＵＩＤ」フィールドと同じ値が「ＵＵＩＤ」フィールドに格納されているエントリを削除する。つまり、端末Ｘにとって今まで子として登録されていた端末Ｃ０に対応するエントリを、端末管理部５３７は削除する。
【０４５３】
そして、次のステップＳ１４１０で端末管理部５３７は、受信開始通知により通知された子端末ＵＵＩＤがＮＵＬＬか否かを判断する。通知された子端末ＵＵＩＤがＮＵＬＬの場合（すなわちケースＥ）、処理はステップＳ１４１１に移行する。逆に、通知された子端末ＵＵＩＤがＮＵＬＬでない場合（すなわちケースＡ、Ｃ、またはＤ）、処理はステップＳ１４１３に移行する。
【０４５４】
ステップＳ１４１１で端末管理部５３７は、ステップＳ１４０２で見つかったエントリ（つまり端末Ｘ自身に対応するエントリ）の「子端末ＵＵＩＤ」フィールドをＮＵＬＬに書き換える。すなわち、端末管理部５３７は、端末Ｘが子を持たないという最新情報を記録する。
【０４５５】
そして、次のステップＳ１４１２で端末管理部５３７は、ステップＳ１４０２で見つかったエントリ（つまり端末Ｘ自身に対応するエントリ）を更新する。具体的には、端末管理部５３７は、当該エントリの「ＩＰアドレス」、「ＯＳ」、および「種別」の各フィールドを、受信開始通知により通知された端末ＩＰアドレス、端末ＯＳ、および端末種別の値で上書きする。そして、図３３〜３５の処理は終了する。
【０４５６】
さて、ステップＳ１４１３は、ケースＡ、Ｃ、Ｄ、Ｆ、Ｇ、またはＨにおいて実行される。ステップＳ１４１３で端末管理部５３７は、ステップＳ１４０２で見つかったエントリ（つまり端末Ｘ自身に対応するエントリ）を更新する。具体的には、端末管理部５３７は、当該エントリの「ＩＰアドレス」、「ＯＳ」、「種別」、および「子端末ＵＵＩＤ」の各フィールドを、受信開始通知により通知された端末ＩＰアドレス、端末ＯＳ、端末種別、および子端末ＵＵＩＤの値で上書きする。なお、「子端末ＵＵＩＤ」フィールドの上書きにより、「端末Ｘが今までのペアを解消して別の端末と新たなペアを組んだ」ということが端末テーブル５３８に反映される。
【０４５７】
そして、次のステップＳ１４１４で端末管理部５３７は、受信開始通知により通知された子端末ＵＵＩＤが「ＵＵＩＤ」フィールドに格納されたエントリが端末テーブル５３８に存在するか否かを判断する。つまり、端末管理部５３７は、今回の端末Ｘからの受信開始通知により端末Ｘの子端末として通知された端末に対応するエントリが端末テーブル５３８に存在するか否かを判断する。
【０４５８】
そして、エントリが見つからない場合（すなわちケースＤまたはＨ）、処理はステップＳ１４１５に移行する。逆に、エントリが見つかった場合（すなわちケースＡ、Ｃ、Ｆ、またはＧ）、処理はステップＳ１４１６に移行する。
【０４５９】
ステップＳ１４１５で端末管理部５３７は、以下のような新規エントリを端末テーブル５３８に追加する。つまり、端末管理部５３７は、ケースＤまたはＨにおける未登録の端末Ｕについての新規エントリを作成する。
【０４６０】
・「ＩＰアドレス」フィールドの値は、受信開始通知により通知された子端末ＩＰアドレスである。
・「ＵＵＩＤ」フィールドの値は、受信開始通知により通知された子端末ＵＵＩＤである。
・「ＯＳ」フィールドの値は、受信開始通知により通知された子端末ＯＳである。
・「種別」フィールドの値は、受信開始通知により通知された子端末種別である。
・「子端末ＵＵＩＤ」フィールドは、ＮＵＬＬである。
【０４６１】
ステップＳ１４１５における以上のエントリの追加後、図３３〜３５の処理は終了する。
【０４６２】
さて、ステップＳ１４１６は、ケースＡ、Ｃ、Ｆ、またはＧのとき実行される。ステップＳ１４１６で端末管理部５３７は、ステップＳ１４１４で見つかったエントリ（つまり今回の受信開始通知により端末Ｘの子端末として通知された端末に対応するエントリ）の「子端末ＵＵＩＤ」フィールドがＮＵＬＬか否かを判断する。「子端末ＵＵＩＤ」フィールドがＮＵＬＬではない場合（つまりケースＡまたはＦ）、処理はステップＳ１４１７に移行する。逆に、「子端末ＵＵＩＤ」フィールドがＮＵＬＬの場合（つまりケースＣまたはＧ）、処理はステップＳ１４１８に移行する。
【０４６３】
ステップＳ１４１７で端末管理部５３７は、ステップＳ１４１４で見つかったエントリの「子端末ＵＵＩＤ」フィールドと同じ値が「ＵＵＩＤ」フィールドに格納されているエントリを削除する。つまり、ケースＡまたはＦにおいて、今回端末Ｘが新たにペアを組んだ端末Ｐ１が今までペアを組んでいた端末Ｃ１に関するエントリを、端末管理部５３７は削除する。そして、処理はステップＳ１４１８へ移行する。
【０４６４】
ところで、ステップＳ１４１８は、図３４に示すように、ステップＳ１４１６の判断結果によらず、実行される。つまり、ステップＳ１４１８は、ケースＡ、Ｃ、Ｆ、Ｇのいずれであっても、実行される。
【０４６５】
ステップＳ１４１８で端末管理部５３７は、ステップＳ１４１４で見つかったエントリ（つまり今回の受信開始通知により端末Ｘの子端末として通知された端末に対応するエントリ）を更新する。具体的には、端末管理部５３７は、当該エントリの「ＩＰアドレス」、「ＯＳ」、および「種別」の各フィールドを、受信開始通知により通知された子端末ＩＰアドレス、子端末ＯＳ、および子端末種別の値で上書きする。また、端末管理部５３７は、当該エントリの「子端末ＵＵＩＤ」フィールドをＮＵＬＬに上書きする。なお、「子端末ＵＵＩＤ」フィールドの上書きにより、「端末Ｘの新たな子端末が、今までのペアを解消して端末Ｘと新たにペアを組んだ」ということが端末テーブル５３８に反映される。ステップＳ１４１８での更新が済むと、図３３〜３５の処理も終了する。
【０４６６】
さて、図３５のステップＳ１４１９は、ケースＪ、Ｋ、またはＬのとき（つまり端末テーブル５３８に未登録の端末Ｘから受信開始通知を端末管理部５３７が受信した場合）に実行される。ステップＳ１４１９で端末管理部５３７は、受信開始通知により通知された子端末ＵＵＩＤが「ＵＵＩＤ」フィールドに格納されたエントリが端末テーブル５３８に存在するか否かを判断する。そして、エントリが見つかった場合（すなわちケースＪまたはＫ）、処理はステップＳ１４２０に移行する。逆に、エントリが見つからなかった場合（すなわちケースＬ）、処理はステップＳ１４２４に移行する。
【０４６７】
ステップＳ１４２０で端末管理部５３７は、ステップＳ１４１９で見つかったエントリ（つまりケースＪの場合は端末Ｐ１に対応するエントリであり、ケースＫの場合は端末Ｃ１に対応するエントリ）の「子端末ＵＵＩＤ」フィールドがＮＵＬＬか否かを判断する。そして、「子端末ＵＵＩＤ」フィールドがＮＵＬＬの場合（つまりケースＫ）、処理はステップＳ１４２１に移行する。逆に、「子端末ＵＵＩＤ」フィールドがＮＵＬＬでない場合（つまりケースＪ）、処理はステップＳ１４２２に移行する。
【０４６８】
ところで、ステップＳ１４２１は、図３５に示すように、ステップＳ１４２０の判断結果によらず、実行される。つまり、ステップＳ１４２１は、ケースＪでも実行され、ケースＫでも実行される。
【０４６９】
ステップＳ１４２１で端末管理部５３７は、ステップＳ１４１９で見つかったエントリを更新する。更新対象のエントリは、今までのペアを解消して端末Ｘと新たにペアを組む登録済みの端末に関するエントリであり、より具体的には、ケースＪの場合は端末Ｐ１に対応するエントリであり、ケースＫの場合は端末Ｃ１に対応するエントリである。ステップＳ１４１９において、端末管理部５３７は、具体的には、当該エントリの「ＩＰアドレス」、「ＯＳ」、および「種別」の各フィールドを、受信開始通知により通知された子端末ＩＰアドレス、子端末ＯＳ、および子端末種別の値で上書きする。ステップＳ１４２１での更新後、処理はステップＳ１４２５に移行する。
【０４７０】
さて、ステップＳ１４２２〜Ｓ１４２３はケースＪで実行される。具体的には、ステップＳ１４２２で端末管理部５３７は、ステップＳ１４１９で見つかったエントリ（つまり端末Ｐ１に対応するエントリ）の「子端末ＵＵＩＤ」フィールドと同じ値が「ＵＵＩＤ」フィールドに格納されているエントリを削除する。換言すれば、端末管理部５３７は、ケースＪにおける端末Ｃ１に対応するエントリを削除する。
【０４７１】
そして、次のステップＳ１４２３で端末管理部５３７は、ステップＳ１４１９で見つかったエントリの「子端末ＵＵＩＤ」フィールドをＮＵＬＬに更新する。換言すれば、端末管理部５３７は、ケースＪにおける端末Ｐ１を、親端末の立場から子端末の立場へと、いわば変身させる。そして、処理はステップＳ１４２１に移行する。
【０４７２】
さて、ステップＳ１４２４はケースＬのとき実行される。ステップＳ１４２４で端末管理部５３７は、以下のような新規エントリを端末テーブル５３８に追加する。つまり、端末管理部５３７は、ケースＬにおける未登録の端末Ｕについての新規エントリを作成する。
【０４７３】
・「ＩＰアドレス」フィールドの値は、受信開始通知により通知された子端末ＩＰアドレスである。
・「ＵＵＩＤ」フィールドの値は、受信開始通知により通知された子端末ＵＵＩＤである。
・「ＯＳ」フィールドの値は、受信開始通知により通知された子端末ＯＳである。
・「種別」フィールドの値は、受信開始通知により通知された子端末種別である。
・「子端末ＵＵＩＤ」フィールドは、ＮＵＬＬである。
【０４７４】
ステップＳ１４２４における以上のエントリの追加後、処理はステップＳ１４２５に移行する。
【０４７５】
ステップＳ１４２５は、ケースＪ、Ｋ、またはＬのとき（つまり端末テーブル５３８に未登録の端末Ｘから受信開始通知を端末管理部５３７が受信した場合）、実行される。ステップＳ１４２５で端末管理部５３７は、以下のような新規エントリを端末テーブル５３８に追加する。つまり、端末管理部５３７は、端末Ｘについての新規エントリを作成する。
【０４７６】
・「ＩＰアドレス」フィールドの値は、受信開始通知により通知された端末ＩＰアドレスである。
・「ＵＵＩＤ」フィールドの値は、受信開始通知により通知された端末ＵＵＩＤである。
・「ＯＳ」フィールドの値は、受信開始通知により通知された端末ＯＳである。
・「種別」フィールドの値は、受信開始通知により通知された端末種別である。
・「子端末ＵＵＩＤ」フィールドの値は、受信開始通知により通知された子端末ＵＵＩＤである。
【０４７７】
ステップＳ１４２５における以上のエントリの追加後、図３３〜３５の処理も終了する。
【０４７８】
次に、図３６〜３７のフローチャートを参照して、図２７のステップＳ１３１２ａのようなセンサ５４０からの通知に応じてサーバ５３０が行う処理について説明する。図３６〜３７のフローチャートにしたがって、図２７のステップＳ１３１２ａ、Ｓ１３１３ａ、およびＳ１３１５ａの処理シーケンスが実現されることもあるし、ステップＳ１３１２ａ、Ｓ１３１３ｂ、およびＳ１３１６ｂの処理シーケンスが実現されることもある。
【０４７９】
さて、ステップＳ１５０１でコンテキスト抽出部５３４が、センサ５４０から、図２７のステップＳ１３１２ａのように、センサ値と端末ＩＤを受信する。端末ＩＤは、具体的には、ＩＰアドレスまたはＵＵＩＤである。
【０４８０】
次に、ステップＳ１５０２でコンテキスト抽出部５３４が、通知されたセンサ値からコンテキスト情報を生成する。ステップＳ１５０２におけるコンテキスト情報の生成方法の詳細は、図１８のステップＳ７０２と同様である。そして、コンテキスト抽出部５３４は、生成したコンテキスト情報を決定部５３５に通知する。
【０４８１】
また、ステップＳ１５０３でコンテキスト抽出部５３４は、センサ５４０から通知された端末ＩＤを端末管理部５３７に通知する。そして、端末管理部５３７は、通知された端末ＩＤがＵＵＩＤとＩＰアドレスのどちらなのかを判断する。
【０４８２】
通知された端末ＩＤがＵＵＩＤの場合、処理はステップＳ１５０４に移行する。逆に、通知された端末ＩＤがＩＰアドレスの場合、処理はステップＳ１５０５に移行する。
ステップＳ１５０４で端末管理部５３７は、通知されたＵＵＩＤがＵＵＩＤのフィールドに記憶されているエントリが、端末テーブル５３８にあるか否かを判断する。もしそのようなエントリがなければ、図３６〜３７の処理は終了する。逆に、通知されたＵＵＩＤがＵＵＩＤのフィールドに記憶されているエントリが見つかれば、端末管理部５３７は、見つけたエントリを決定部５３５に通知し、処理はステップＳ１５０６に移行する。
【０４８３】
また、ステップＳ１５０５で端末管理部５３７は、通知されたＩＰアドレスがＩＰアドレスのフィールドに記憶されているエントリが端末テーブル５３８にあるか否かを判断する。もしそのようなエントリがなければ、図３６〜３７の処理は終了する。逆に、通知されたＵＵＩＤがＵＵＩＤのフィールドに記憶されているエントリが見つかれば、端末管理部５３７は、見つけたエントリを決定部５３５に通知し、処理はステップＳ１５０６に移行する。
【０４８４】
ステップＳ１５０６で端末管理部５３７は、ステップＳ１５０４またはＳ１５０５で見つかったエントリの子端末ＵＵＩＤのフィールドがＮＵＬＬか否かを判断する。子端末ＵＵＩＤのフィールドがＮＵＬＬの場合、処理はステップＳ１５０７に移行する。逆に、子端末ＵＵＩＤのフィールドがＮＵＬＬでない場合、処理はステップＳ１５０８に移行する。
【０４８５】
ステップＳ１５０７は、センサ５４０から通知された端末ＩＤが、ある端末の子端末のＩＤである場合に実行される。ステップＳ１５０７で端末管理部５３７は、当該子端末の種別と、当該子端末の親である上記「ある端末」の種別を取得する。
【０４８６】
具体的には、端末管理部５３７は、ステップＳ１５０４またはＳ１５０５で見つかったエントリの種別の値を取得する。また、端末管理部５３７は、ステップＳ１５０４またはＳ１５０５で見つかったエントリのＵＵＩＤのフィールドの値が、子端末ＵＵＩＤのフィールドに記憶されているエントリの、種別の値を取得する。
【０４８７】
そして、端末管理部５３７は、取得した２台の端末の種別の値を決定部５３５に通知する。また、端末管理部５３７は、２台の端末に対応する２つのエントリを決定部５３５に通知してもよい。そして、処理は図３７のステップＳ１５０９に移行する。
【０４８８】
他方、ステップＳ１５０８は、センサ５４０から通知された端末ＩＤが、ある端末の親端末のＩＤである場合に実行される。ステップＳ１５０８で端末管理部５３７は、当該親端末の種別と、当該親端末の子である上記「ある端末」の種別を取得する。
【０４８９】
具体的には、端末管理部５３７は、ステップＳ１５０４またはＳ１５０５で見つかったエントリの種別の値を取得する。また、端末管理部５３７は、ステップＳ１５０４またはＳ１５０５で見つかったエントリの子端末ＵＵＩＤのフィールドの値が、ＵＵＩＤのフィールドに記憶されているエントリの、種別の値を取得する。
【０４９０】
そして、端末管理部５３７は、取得した２台の端末の種別の値を決定部５３５に通知する。また、端末管理部５３７は、２台の端末に対応する２つのエントリを決定部５３５に通知してもよい。そして、処理は図３７のステップＳ１５０９に移行する。
【０４９１】
さて、図３７のステップＳ１５０９で決定部５３５は、下記の情報の組み合わせと合致するエントリが条件テーブル５３６にあるか否かを判断する。
【０４９２】
・ステップＳ１５０２でコンテキスト抽出部５３４から通知されたコンテキスト情報。
・ステップＳ１５０７またはＳ１５０８で端末管理部５３７から通知された、２台の端末それぞれの種別。
【０４９３】
例えば、センサ５４０から通知された端末ＩＤが、１０．８．９．１１というＩＰアドレスだったとする。この場合、図３０の端末テーブル５３８の２番目のエントリがステップＳ１５０５で見つかる。
【０４９４】
また、端末テーブル５３８の２番目のエントリの子端末ＵＵＩＤのフィールドは、ＮＵＬＬである。よって、ステップＳ１５０７で、２番目のエントリの種別が取得され、さらに、２番目のエントリが表す端末の親端末を表すエントリ（すなわち１番目のエントリ）の種別が取得される。すなわち、タブレット端末とスマートフォンという２つの種別の値が取得される。
【０４９５】
ここで、仮にステップＳ１５０２では「会議室」というコンテキストが抽出されたとする。すると、ステップＳ１５０９において、決定部５３５は、図２９の条件テーブル５３６において、会議室とタブレット端末とスマートフォンの組み合わせと合致する１番目のエントリを見つける。
【０４９６】
また、仮にセンサ５４０から通知された端末ＩＤが１０．８．９．１０というＩＰアドレスだった場合も、ステップＳ１５０７ではなくステップＳ１５０８で種別の値が取得される点以外は上記と同様にして、条件テーブル５３６の１番目のエントリが見つかる。
【０４９７】
例えば以上のようにして、ステップＳ１５０９において条件テーブル５３６のエントリが見つかった場合、処理はステップＳ１５１０に移行する。逆に、エントリが見つからなければ、図３６〜３７の処理は終了する。
【０４９８】
ステップＳ１５１０で決定部５３５は、ステップＳ１５０９において条件テーブル５３６で見つかったエントリの、サービス提供端末の種別のフィールドと種別の値が合致した方の端末を、サービスの宛先として決定する。そして、決定部５３５は、当該端末のＩＰアドレス、ＵＵＩＤ、およびＯＳの値を、端末テーブル５３８から取得し、取得した値を、サービスの宛先の端末に関する情報として送信部５３９に通知する。また、決定部５３５は、ステップＳ１５０９において条件テーブル５３６で見つかったエントリのサービスを、送信対象のサービスとして送信部５３９に通知する。
【０４９９】
さらに、ステップＳ１５１１で決定部５３５は、ステップＳ１５０９において条件テーブル５３６で見つかったエントリの、コントローラ端末の種別のフィールドと種別の値が合致した方の端末を、コントローラの宛先として決定する。そして、決定部５３５は、当該端末のＩＰアドレス、ＵＵＩＤ、およびＯＳの値を、端末テーブル５３８から取得し、取得した値を、コントローラの宛先の端末に関する情報として送信部５３９に通知する。また、決定部５３５は、ステップＳ１５０９において条件テーブル５３６で見つかったエントリのコントローラを、送信対象のコントローラとして送信部５３９に通知する。
【０５００】
なお、ステップＳ１５１０とＳ１５１１の順序は逆でもよい。例えば上記のようにセンサ５４０から１０．８．９．１１というＩＰアドレスが端末ＩＤとして通知された場合、ステップＳ１５０９では条件テーブル５３６の１番目のエントリが見つかる。よって、ステップＳ１５１０では、種別がタブレット端末である方の端末（つまり１０．８．９．１１というＩＰアドレスの端末）が、ドキュメント表示サービスの宛先として決定される。また、ステップＳ１５１１では、種別がスマートフォンである方の端末（つまり１０．８．９．１０というＩＰアドレスの端末）が、ドキュメントページめくりコントローラの宛先として決定される。
【０５０１】
最後に、ステップＳ１５１２で送信部５３９は、条件テーブル５３６からサービスとコントローラそれぞれの宛先として通知された端末に対し、サービスとコントローラそれぞれのデータを送信する。なお、送信部５３９は、決定部５３５から通知されたＯＳの値に応じて、適宜の新規サービスプログラム５３２と適宜の新規コントローラプログラム５３３を選んで送信する。ステップＳ１５１２の送信は、図２７のステップＳ１３１３ａとＳ１３１５ａの送信に対応する場合もあるし、ステップＳ１３１３ｂとＳ１３１６ｂの送信に対応する場合もある。
【０５０２】
なお、ステップＳ１５０４、Ｓ１５０５、またはＳ１５０９で、検索条件に合致するエントリが見つからない場合は、何らかのエラーがある場合である。よって、これらの場合、上記のとおり図３６〜３７の処理は終了し、ステップＳ１５１２のような送信は行われない。
【０５０３】
さて、図３８は、端末５１０が事前に行う処理のフローチャートである。図３８は、図２７のステップＳ１３０１〜Ｓ１３１１に対応する。なお、場合によっては端末５２０が図３８の処理を行ってもよい（すなわち図２７で端末５１０と端末５２０が入れ替わってもよい）。
【０５０４】
さて、ステップＳ１６０１で更新サービス５１５が、図２７のステップＳ１３０１のようなM-searchメッセージのマルチキャストにより、端末５１０の周辺にある端末の更新サービスを検索する。
【０５０５】
もし、端末５２０のように、更新サービスを提供する端末があれば、更新サービス５１５は図２７のステップＳ１３０２のような応答を受信する。この場合、更新サービス５１５はさらに、図２７のステップＳ１３０３〜Ｓ１３０６のようにして、発見した他の端末（例えば端末５２０）のデバイス定義ファイルと、発見した更新サービスのサービス定義ファイルを取得する。
【０５０６】
次に、ステップＳ１６０２で更新サービス５１５は、ステップＳ１６０１で更新サービスを提供する端末が発見されたか否かを判断する。
ステップＳ１６０１でのM-searchメッセージの送信から所定の時間が経過しても、ステップＳ１３０２のような応答が１つも受信されない場合、更新サービス５１５は、「更新サービスを提供する他の端末は発見されなかった」と判断する。そして、図３８の処理も終了する。
【０５０７】
逆に、ステップＳ１３０２のような応答が得られて、デバイス定義ファイルとサービス定義ファイルが取得されていれば、更新サービスを提供する他の端末（例えば端末５２０）が存在する。よって、この場合、更新サービス５１５は、「更新サービスを提供する他の端末が発見された」と判断し、処理はステップＳ１６０３へと移行する。
【０５０８】
さて、以下の説明では、ステップＳ１６０１の検索の結果、更新サービス５２５を提供する端末５２０が見つかったものとする。
ステップＳ１６０３で更新サービス５１５は、ステップＳ１６０１の検索の結果見つけた端末５２０に対して、図２７のステップＳ１３０７のように受信準備コマンドを送信する。そして、更新サービス５１５は、受信準備コマンドに対する、ステップＳ１３０８のような応答を、見つけた端末５２０から受信する。受信される応答は、更新サービス５１５が見つけた端末５２０の、ＩＰアドレス、ＵＵＩＤ、ＯＳ、および種別の値を含む。
【０５０９】
そして、次のステップＳ１６０４で更新サービス５１５は、受信部５１６を起動する。その際、更新サービス５１５は、受信部５１６に対して、以下の情報を通知する。
【０５１０】
・端末５１０自身のＵＵＩＤ。
・更新サービス５１５が見つけた端末５２０の、ＩＰアドレス、ＯＳ、および種別。
・サーバ５３０のアドレス（例えばＵＲＩ）。
【０５１１】
起動された受信部５１６は、サーバ５３０からデータを受信するための適宜の処理（例えば、所定のＴＣＰポートを開放する処理など）を行う。ステップＳ１６０４は図２７のステップＳ１３１０の受信準備に対応する。
【０５１２】
また、ステップＳ１６０５で受信部５１６は、サーバ５３０の端末管理部５３７に対して、以下の情報を通知する。
【０５１３】
・端末５１０自身の、ＩＰアドレス、ＯＳ、および種別。
・更新サービス５１５が見つけた端末５２０の、ＩＰアドレス、ＯＳ、および種別。
【０５１４】
ステップＳ１６０５の通知は、具体的には、図２７のステップＳ１３１１の受信開始通知である。
【０５１５】
さて、図３９は、端末５１０と端末５２０のそれぞれがサーバ５３０からのデータの受信に応じて行う処理のフローチャートである。以下では便宜上、端末５１０が図３９の処理を実行する場合を例にして説明を行う。
【０５１６】
まず、ステップＳ１７０１で受信部５１６が、サーバ５３０からデータを受信する。そして、ステップＳ１７０２で受信部５１６は、受信したデータがサービスのデータなのかコントローラのデータなのかを判断する。サービスのデータ（つまり新規サービスプログラム５３２とサービス定義ファイルを含むデータ）が受信された場合、処理はステップＳ１７０３に移行する。逆に、コントローラのデータ（つまり新規コントローラプログラム５３３を含むデータ）が受信された場合、処理はステップＳ１７０７に移行する。
【０５１７】
ステップＳ１７０３で受信部５１６は、受信したサービスのデータを更新サービス５１５に通知する。
すると、ステップＳ１７０４で更新サービス５１５は、受信部５１６から通知されたデータを使って、以下の３つの処理を行う。
【０５１８】
第１に、更新サービス５１５は、端末５１０のデバイス定義ファイルを更新する。
第２に、更新サービス５１５は、新規サービス５１８のサービス定義ファイルを追加または更新する。つまり、新規サービス５１８が今まで端末５１０に存在していなかった全く新しいサービスである場合は、更新サービス５１５は、新たなサービス定義ファイルを作成して保存する。また、新規サービス５１８が、端末５１０にインストール済みの既存のサービスの新規バージョンである場合は、更新サービス５１５は、当該既存のサービスのサービス定義ファイルを更新する。
第３に、更新サービス５１５は、受信した新規サービスプログラム５３２を端末５１０にインストールする。
【０５１９】
そして、次のステップＳ１７０５で更新サービス５１５は、図３２のサービス定義ファイル５６１で定義されている「UpdateTime」という状態変数の値を現在時刻に更新する。端末５１０が図３９の処理を実行する場合、ステップＳ１７０４〜Ｓ１７０５は、図２７のステップＳ１３１４ｂに対応する。
【０５２０】
最後に、ステップＳ１７０６で更新サービス５１５は、ＧＥＮＡにより、端末５１０の周辺の端末（例えば、図２７の例では、端末５２０と端末５５０）に対して、ステップＳ１７０５で更新した「UpdateTime」という状態変数の値を通知する。端末５１０が図３９の処理を実行する場合、ステップＳ１７０６は、図２７のステップＳ１３１５ｂに対応する。
【０５２１】
他方、コントローラのデータが受信された場合、ステップＳ１７０７〜Ｓ１７０８の処理が行われる。つまり、ステップＳ１７０７で受信部５１６が、受信した新規コントローラプログラム５３３を更新サービス５１５に通知する。すると、ステップＳ１７０８で更新サービス５１５が、通知された新規コントローラプログラム５３３を端末５１０にインストールする。端末５１０が図３９の処理を実行する場合、ステップＳ１７０８は図２７のステップＳ１３１４ａに対応する。
【０５２２】
以上説明した第５実施形態には、サービスとコントローラの更新による利便性向上という効果がある。また、更新サービス５１５と５２５はＵＰｎＰのサービスであるため、ＵＰｎＰ用のライブラリを介して更新サービス５１５と５２５の普及が促進される。さらに、第５実施形態では、コンテキストに応じた動的なサービスの利用が可能となる。
【０５２３】
ところで、以上説明した第１〜第５実施形態における種々の装置は、どれも１種の情報処理装置である。図４０に情報処理装置の構成図を示す。
図４０の情報処理装置６００は、ＣＰＵ（Central Processing Unit）６０１、ＲＯＭ（Read Only Memory）６０２、ＲＡＭ（Random Access Memory）６０３、および通信インタフェイス６０４を有する。また、情報処理装置６００はさらに、入力装置６０５、出力装置６０６、記憶装置６０７、および記憶媒体６１０の駆動装置６０８を有していてもよい。そして、情報処理装置６００内の上記コンポーネントは、バス６０９により互いに接続されている。また、情報処理装置６００は、通信インタフェイス６０４を介してネットワーク６１１に接続されている。ネットワーク６１１は、例えば、ＬＡＮでもよいし、ＬＡＮとインターネットの組み合わせでもよい。
【０５２４】
ＣＰＵ６０１は、プログラムをＲＡＭ６０３にロードし、ＲＡＭ６０３をワーキングエリアとしても使用しながら、プログラムを実行する。プログラムは、予めＲＯＭ６０２または記憶装置６０７に記憶されていてもよい。記憶装置６０７は、例えばハードディスク装置であってもよい。
【０５２５】
あるいは、プログラムは、プログラム提供者６１２により提供され、ネットワーク６１１と通信インタフェイス６０４を介して情報処理装置６００にダウンロードされ、記憶装置６０７に記憶されてもよい。プログラム提供者６１２は、例えば、情報処理装置６００以外の他の情報処理装置である。
【０５２６】
また、プログラムは、コンピュータ読み取り可能な可搬型の記憶媒体６１０に記憶されて提供されてもよい。プログラムは、駆動装置６０８にセットされた記憶媒体６１０から、駆動装置６０８により読み取られる。読み取られたプログラムは、その後、一旦記憶装置６０７にコピーされてからＲＡＭ６０３にロードされてもよいし、直接ＲＡＭ６０３にロードされてもよい。記憶媒体６１０としては、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、光磁気ディスク、磁気ディスク、不揮発性の半導体メモリカードなどが利用可能である。
【０５２７】
なお、図４０には１つの通信インタフェイス６０４のみが図示されているが、情報処理装置６００は、異なる複数の種類の通信インタフェイス６０４を有していてもよい。例えば、以下のようなものが通信インタフェイス６０４として利用可能である。
【０５２８】
・有線ＬＡＮ用のネットワークインタフェイス装置
・無線ＬＡＮ用のネットワークインタフェイス装置
・無線ＰＡＮ（Personal Area Network）用のネットワークインタフェイス装置
・３ＧＰＰ（Third Generation Partnership Project）、ＬＴＥ（Long Term Evolution）、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）などの、携帯電話やスマートフォンなどで使われる通信規格にしたがった通信回路
【０５２９】
入力装置６０５は、例えば、入力ボタン、キーボード、マウスやタッチスクリーンなどのポインティングデバイス、マイク、またはそれらの組み合わせである。出力装置６０６は、例えば、ディスプレイ、スピーカ、ＬＥＤ（Light Emitting Diode）ランプなどのインジケータ、またはそれらの組み合わせである。ディスプレイは、タッチスクリーンであってもよい。
【０５３０】
また、ＲＯＭ６０２、ＲＡＭ６０３、記憶装置６０７、および記憶媒体６１０は、いずれも、コンピュータ読み取り可能な記憶媒体の例である。これらのコンピュータ読み取り可能な記憶媒体は、有形の（tangible）記憶媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。
【０５３１】
ところで、第１実施形態と図４０の関係は次のとおりである。図１〜２の端末１１０、デバイス１２０、サービス管理装置１３０、および端末１４０のいずれも、情報処理装置６００のように構成されていてもよい。図１のシーケンス図に示すような各種の通信は、通信インタフェイス６０４とネットワーク６１１を介して行われる。
【０５３２】
端末１１０のＵＰｎＰコントローラ１１１は、プログラムを実行するＣＰＵ６０１と、ＣＰＵ６０１からの指示にしたがって通信を行う通信インタフェイス６０４により実現される。デバイス１２０のＵＰｎＰサービス提供部１２１も同様に、ＣＰＵ６０１と通信インタフェイス６０４より実現される。
【０５３３】
サービス管理装置１３０の格納部１３１は、サービス管理装置１３０の記憶装置６０７により実現される。なお、図２の格納部１３１の中には、簡単化のため、新規サービス１２３についてのデータとして、新規サービスプログラム１３２しか図示されていない。しかし、新規サービス１２３のサービス定義ファイルなども、格納部１３１には格納されている。他の実施形態に関する図でも同様に、格納部の中にはプログラムしか図示されていないが、格納部には、定義ファイルなどの他の情報も含むデータが格納されている。
【０５３４】
図３のデバイス定義ファイル１５０や図４のサービス定義ファイル１５１は、デバイス１２０の記憶装置６０７に格納されており、必要に応じてＲＡＭ６０３上に読み出される。端末１１０は、取得したデバイス定義ファイル１５０やサービス定義ファイル１５１を、ＲＡＭ６０３上に保持してもよいし、必要に応じて記憶装置６０７に格納してもよい。
【０５３５】
また、第２実施形態と図４０の関係は次のとおりである。図７〜８の端末２１０、デバイス２２０、およびコントローラ管理装置２３０のいずれも、情報処理装置６００のように構成されていてもよい。図７のシーケンス図に示すような各種の通信は、通信インタフェイス６０４とネットワーク６１１を介して行われる。
【０５３６】
端末２１０のＵＰｎＰ制御部２１１とコントローラ更新サービス２１２は、いずれも、プログラムを実行するＣＰＵ６０１と、ＣＰＵ６０１からの指示にしたがって通信を行う通信インタフェイス６０４により実現される。デバイス２２０のＵＰｎＰサービス提供部２２１も同様に、ＣＰＵ６０１と通信インタフェイス６０４より実現される。また、コントローラ管理装置２３０のコントローラ決定部２３３も同様に、ＣＰＵ６０１と通信インタフェイス６０４より実現される。
【０５３７】
そして、コントローラ管理装置２３０の格納部２３１は、コントローラ管理装置２３０の記憶装置６０７により実現される。条件テーブル２３４は、コントローラ管理装置２３０の記憶装置６０７に予め格納されており、必要に応じてＲＡＭ６０３上に読み出される。図１０のデバイス定義ファイル２４０や図１１のサービス定義ファイル２４１は、端末２１０の記憶装置６０７に格納されており、必要に応じてＲＡＭ６０３上に読み出される。
【０５３８】
また、第３実施形態と図４０の関係は次のとおりである。図１３〜１４の端末３１０、デバイス３２０、サーバ３３０、および端末３５０のいずれも、情報処理装置６００のように構成されていてもよい。図１３のシーケンス図に示すような各種の通信は、通信インタフェイス６０４とネットワーク６１１を介して行われる。
【０５３９】
端末３１０のＵＰｎＰコントローラ３１１と要求部３１２は、いずれも、プログラムを実行するＣＰＵ６０１と、ＣＰＵ６０１からの指示にしたがって通信を行う通信インタフェイス６０４により実現される。デバイス３２０のＵＰｎＰサービス提供部３２１と受信部３２４のそれぞれも、同様に、ＣＰＵ６０１と通信インタフェイス６０４より実現される。サーバ３３０のコンテキスト抽出部３３３とサービス決定部３３４とデバイス管理部３３６と送信部３３８のそれぞれも、同様に、ＣＰＵ６０１と通信インタフェイス６０４より実現される。
【０５４０】
また、サーバ３３０の格納部３３１は、サーバ３３０の記憶装置６０７により実現される。条件テーブル３３５は、サーバ３３０の記憶装置６０７に予め格納されており、必要に応じてＲＡＭ６０３上に読み出される。デバイステーブル３３７は、ＲＡＭ６０３上に作成され、記憶されていてもよい。
【０５４１】
そして、図３のデバイス定義ファイル１５０や図４のサービス定義ファイル１５１は、デバイス３２０の記憶装置６０７に格納されており、必要に応じてＲＡＭ６０３上に読み出される。端末３１０は、取得したデバイス定義ファイル１５０やサービス定義ファイル１５１を、ＲＡＭ６０３上に保持してもよいし、必要に応じて記憶装置６０７に格納してもよい。
【０５４２】
また、第４実施形態と図４０の関係は次のとおりである。図２０〜２１の端末４１０、デバイス４２０、およびサーバ４３０のいずれも、情報処理装置６００のように構成されていてもよい。図２０のシーケンス図に示すような各種の通信は、通信インタフェイス６０４とネットワーク６１１を介して行われる。
【０５４３】
端末４１０のＵＰｎＰ制御部４１１とコントローラ更新サービス４１２と受信部４１３と要求部４１４は、いずれも、プログラムを実行するＣＰＵ６０１と、ＣＰＵ６０１からの指示にしたがって通信を行う通信インタフェイス６０４により実現される。デバイス４２０のＵＰｎＰサービス提供部４２１も同様に、ＣＰＵ６０１と通信インタフェイス６０４より実現される。サーバ４３０のコンテキスト抽出部４３３とコントローラ決定部４３４と端末管理部４３６と送信部４３８のそれぞれも、同様に、ＣＰＵ６０１と通信インタフェイス６０４より実現される。
【０５４４】
また、サーバ４３０の格納部４３１は、サーバ４３０の記憶装置６０７により実現される。条件テーブル４３５は、サーバ４３０の記憶装置６０７に予め格納されており、必要に応じてＲＡＭ６０３上に読み出される。端末テーブル４３７は、ＲＡＭ６０３上に作成され、記憶されていてもよい。
【０５４５】
そして、図１０のデバイス定義ファイル２４０や図１１のサービス定義ファイル２４１は、端末４１０の記憶装置６０７に格納されており、必要に応じてＲＡＭ６０３上に読み出される。
【０５４６】
また、第５実施形態と図４０の関係は次のとおりである。図２７〜２８の端末５１０、端末５２０、およびサーバ５３０のいずれも、情報処理装置６００のように構成されていてもよい。図２７のシーケンス図に示すような各種の通信は、通信インタフェイス６０４とネットワーク６１１を介して行われる。
【０５４７】
端末５１０のＵＰｎＰ制御部５１１とＵＰｎＰサービス提供部５１３と受信部５１６と要求部５１７は、いずれも、プログラムを実行するＣＰＵ６０１と、ＣＰＵ６０１からの指示にしたがって通信を行う通信インタフェイス６０４により実現される。同様に、端末５２０のＵＰｎＰ制御部５２１とＵＰｎＰサービス提供部５２３と受信部５２６と要求部５２７は、いずれも、プログラムを実行するＣＰＵ６０１と、ＣＰＵ６０１からの指示にしたがって通信を行う通信インタフェイス６０４により実現される。サーバ５３０のコンテキスト抽出部５３４と決定部５３５と端末管理部５３７と送信部５３９のそれぞれも、同様に、ＣＰＵ６０１と通信インタフェイス６０４より実現される。
【０５４８】
また、サーバ５３０の格納部５３１は、サーバ５３０の記憶装置６０７により実現される。条件テーブル５３６は、サーバ５３０の記憶装置６０７に予め格納されており、必要に応じてＲＡＭ６０３上に読み出される。端末テーブル５３８は、ＲＡＭ６０３上に作成され、記憶されていてもよい。
【０５４９】
そして、端末５２０に関する図３１のデバイス定義ファイル５５０や図３２のサービス定義ファイル５５１は、端末５２０の記憶装置６０７に格納されており、必要に応じてＲＡＭ６０３上に読み出される。端末５１０は、端末５２０からデバイス定義ファイル５５０やサービス定義ファイル５５１を取得した場合、取得したこれらのファイルを、ＲＡＭ６０３上に保持してもよいし、必要に応じて記憶装置６０７に格納してもよい。
【０５５０】
同様に、端末５１０に関するデバイス定義ファイルやサービス定義ファイルは、端末５１０の記憶装置６０７に格納されており、必要に応じてＲＡＭ６０３上に読み出される。端末５２０は、端末５１０からデバイス定義ファイルやサービス定義ファイルを取得した場合、取得したこれらのファイルを、ＲＡＭ６０３上に保持してもよいし、必要に応じて記憶装置６０７に格納してもよい。
【０５５１】
ところで、本発明は上記の第１〜第５実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、第１〜第５実施形態は、さらに下記の観点から変形することもできる。そして、上記の各実施形態および下記の各種変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
【０５５２】
例えば、上記の説明においては、様々なシーケンス図とフローチャートを用いて、様々な処理を説明したが、いくつかのステップの順番は入れ替え可能である。例えば、図１のステップＳ１０８とＳ１０９の順序は逆でもよい。また、図２７において、ステップＳ１３１０がステップＳ１３０７の前に行われてもよい。他にも、順序を入れ替えても矛盾が生じないステップ同士は、逆の順序で実行されてもよいし、並行して実行されてもよい。
【０５５３】
デバイス定義ファイルやサービス定義ファイルの具体的な内容も、実施形態に応じて様々であってよい。例えば、サービス更新サービスのサービス定義ファイルにおける各アクションの定義は、図示した定義とは異なる定義であってもよい。
【０５５４】
また、いくつかの図ではデータをテーブル形式で例示した。しかし、テーブル形式以外の形式が使われてもよい。例えば、ＸＭＬ形式のデータが使われてもよいし、連想配列が使われてもよい。
【０５５５】
なお、上記では説明の簡単化のため、第１実施形態と第２実施形態に関しては、ＯＳ依存性について説明を省略した。
【０５５６】
しかし、例えば第１実施形態において、サービス管理装置１３０は、同じ新規サービス１２３に対応する、複数のＯＳ用の複数の新規サービスプログラム１３２を、格納部１３１に格納していてもよい。そして、図１のステップＳ１０９の要求は、デバイス１２０のＯＳに関する情報を含んでいてもよい。サービス管理装置１３０は、通知されたＯＳ用の新規サービスプログラム１３２をステップＳ１１０で送信してもよい。
【０５５７】
第２実施形態も同様に変形されてよい。例えば、コントローラ管理装置２３０は、同じ新規コントローラ２１３に対応する、複数のＯＳ用の複数の新規コントローラプログラム２３２を、格納部２３１に格納していてもよい。そして、図７のステップＳ３０７の要求は、端末２１０のＯＳに関する情報を含んでいてもよい。コントローラ管理装置２３０は、通知されたＯＳ用の新規コントローラプログラム２３２をステップＳ３０８で送信してもよい。
【０５５８】
また、いくつかの実施形態を組み合わせることも可能である。例えば、第１実施形態のサービス更新サービス１２２と、第３実施形態のサービス更新サービス３２２の機能を兼ね備えたサービス更新サービスが、デバイスに実装されてもよい。同様に、第２実施形態のコントローラ更新サービス２１２と、第４実施形態のコントローラ更新サービス４１２の機能を兼ね備えたコントローラ更新サービスが、端末に実装されてもよい。
【０５５９】
あるいは、第５実施形態の更新サービス５１５や５２５が、第１実施形態のサービス更新サービス１２２のようにコンテキストに依存せずにサービスを更新する機能をさらに有していてもよい。同様に、更新サービス５１５や５２５が、第２実施形態のコントローラ更新サービス２１２のようにコンテキストに依存せずにコントローラを更新する機能をさらに有していてもよい。
【０５６０】
また、第５実施形態の説明から明らかなように、１台の端末が、場合に応じて、ＵＰｎＰコントローラとして動作し得るだけでなく、ＵＰｎＰサービスを提供することもできる。そこで、以下のような第１実施形態と第２実施形態の組み合わせも可能である。すなわち、１台の端末の中に、第１実施形態のサービス更新サービス１２２と第２実施形態のコントローラ更新サービス２１２の双方があってもよい。
【０５６１】
ところで、図１のステップＳ１０１、図７のステップＳ３０１、図１３のステップＳ５０１、図２０のステップＳ９０１、および図２７のステップＳ１３０１には、M-searchメッセージの送信による探索が例示されている。そして、これらのステップの探索に対して、図１、７、１３、２０、および２７には、１つの応答が返される場合が例示されている。しかし、状況によっては、２つ以上の応答が返される場合があり得る。
【０５６２】
例えば、図１のステップＳ１０１のM-searchメッセージに対して、それぞれサービス更新サービス１２２を提供する複数のデバイスデバイス１２０が、ステップＳ１０２と同様に応答を返すことがあり得る。その場合、端末１１０は、複数のデバイス１２０のそれぞれに対して、ステップＳ１０３以降の処理を実行してもよい。
【０５６３】
逆に、端末１１０は、複数のデバイス１２０のうちの１台を選んでから、選んだ１台のデバイス１２０に対してステップＳ１０３以降の処理を実行してもよい。端末１１０は、例えば、発見された複数のデバイス１２０のリストを画面に表示し、ユーザからの入力に応じて１台のデバイス１２０を選択してもよい。あるいは、端末１１０は、発見された複数のデバイス１２０のうちの任意の１台（例えば最も早く応答を返したデバイス１２０）を自動的に選択してもよい。
【０５６４】
図７の場合も同様に、ステップＳ３０２のような応答が２つ以上返された場合は、端末２１０は、１台のデバイス２２０を選択してもよいし、複数のデバイス２２０それぞれに対してステップＳ３０３以降の処理を実行してもよい。図１３と図２０の場合も上記の図１や図７と同様である。
【０５６５】
なお、第５実施形態では、サーバ５３０の端末管理部５３７が２台の端末をペアとして管理する。よって、図２７のステップＳ１３０２のような応答が複数得られた場合、端末５１０は、複数の端末５２０の中から１台を選択してステップＳ１３０３以降の処理を実行することが好ましい。
【０５６６】
しかし、端末管理部５３７による端末の管理の仕方が変形された実施形態においては、端末５１０は、ステップＳ１３０２のような応答を返した複数の端末５２０のそれぞれに対してステップＳ１３０３以降の処理を実行してもよい。例えば、端末管理部５３７は、２台以上の端末を含む端末グループを管理してもよい。
【０５６７】
例えば、ステップＳ１３０２のような応答が２台の端末５２０から返された場合、端末５１０は、２台の端末５２０それぞれに対してステップＳ１３０３〜Ｓ１３０８の処理を行ってもよい。そして、ステップＳ１３１１では、３台の端末（つまり端末５１０自身と、発見された２台の端末５２０）についての情報を含む受信開始通知を、端末５１０が送信してもよい。
【０５６８】
端末管理部５３７は、３台の端末を１つのグループとして管理してもよい。そして、決定部５３５は、ステップＳ１３１２ａまたはＳ１３１２ｂの通知に応じて、同じグループに属する任意の２台の端末のペアのうち、通知されたコンテキストとの組み合わせが条件テーブル５３６のエントリと合致するペアを選んでもよい。
【０５６９】
また、各実施形態において、サービスまたはコントローラのインストール前に、ユーザにインストールを承認してもらうための処理が行われてもよい。例えば、第１実施形態において、端末１１０の持ち主とデバイス１２０の持ち主は違うかもしれない。そこで、例えばステップＳ１０７のサービス追加・更新コマンドを受信すると、デバイス１２０は、指定されたサービスのインストールを許可するか否かをデバイス１２０のユーザに尋ねるダイアログを表示してもよい。ユーザがインストールを許可した場合のみ、図１のステップＳ１０８以降の処理が行われてもよい。他の実施形態においても、適宜のタイミングで、プログラムのインストールを許可するか否かをユーザに確認させるための処理が行われてもよい。
【０５７０】
また、上記の説明では、簡単化のため、エラー処理については省略したが、適宜のエラー処理がさらに行われてもよい。例えば、要求されたサービスまたはコントローラのデータがない場合にエラーメッセージを送信するなどの処理が行われてもよい。
【０５７１】
ところで、上記の説明においては、サービスまたはコントローラの削除についての説明を簡略化したが、以下のようにして削除が行われてもよい。
例えば、第１実施形態の端末１１０は、図１のステップＳ１１１でデバイス１２０にインストールされた新規サービス１２３を使い終わったら、デバイス１２０に対して、新規サービス１２３の削除を命じてもよい。具体的には、端末１１０のＵＰｎＰコントローラ１１１は、図４のサービス定義ファイル１５１で定義された「DeleteService」アクションを指定したＳＯＡＰコマンドをサービス更新サービス１２２に対して送信してもよい。
【０５７２】
そして、サービス更新サービス１２２は、受信したコマンドに応じて、削除対象として指定された新規サービス１２３をアンインストールしてもよい。あるいは、サービス更新サービス１２２は、デバイス定義ファイル１５０から、指定された新規サービス１２３に関する定義（例えば図３の１８〜２４行）を単に削除することで、新規サービス１２３を外部のコントローラから使用不能な状態にしてもよい。なお、サービス管理装置１３０が新規サービス１２３用のアンインストーラを格納していてもよく、サービス更新サービス１２２は、アンインストーラをサービス管理装置１３０に要求してもよい。
【０５７３】
もちろん、削除対象のサービスは、図２の新規サービス１２３に限らず、任意のサービスでよい。また、端末１１０が削除を命じるタイミングも任意である。
また、第２実施形態の端末２１０は、図７のステップＳ３０９でインストールされた新規コントローラ２１３を使ってサービス２２２を利用し終わったら、新規コントローラ２１３を削除してもよい。具体的には、コントローラ更新サービス２１２が、新規コントローラ２１３を削除してもよい。なお、コントローラ管理装置２３０が新規コントローラ２１３用のアンインストーラを格納していてもよく、コントローラ更新サービス２１２は、アンインストーラをコントローラ管理装置２３０に要求してもよい。
【０５７４】
もちろん、削除対象のコントローラは、図８の新規コントローラ２１３に限らず、任意のコントローラでよい。また、削除のタイミングも任意である。
第３〜第５実施形態に関しても、同様に、明示的な命令に基づく、任意のタイミングでの、サービスまたはコントローラの削除が可能である。さらに、第３〜第５実施形態では、センサからの出力に基づく削除も可能である。
【０５７５】
例えば、サーバのコンテキスト抽出部は、センサ値からコンテキストの変化を検出することもできる。あるコンテキストの検出に応じてサーバの送信部がサービスまたはコントローラのデータを送信した後、コンテキスト抽出部がコンテキストの変化を検出したら、サーバは、送信済みのサービスまたはコントローラの削除を、端末またはデバイスに命じてもよい。
【０５７６】
例えば、ある会議室にデバイス３２０が入るのにともなって、「会議室」というコンテキストが検出され、「会議室」というコンテキストに応じてサービスがデバイス３２０にインストールされることがある。当該会議室からデバイス３２０が出るときも、センサ３４０によるセンサ値の送信が行われてもよい。そして、コンテキスト抽出部３３３が、コンテキストの変化を検出してもよい。サーバ３３０は、コンテキストの変化に応じて、上記サービスの削除をデバイス３２０に命じてもよい。
【０５７７】
なお、コンテキスト抽出部３３３による別の新たなコンテキスト（例えば「自宅」というコンテキスト）の検出は、暗黙的には「かつて検出されたコンテキスト（例えば「会議室」というコンテキスト）の環境から、デバイス３２０が出た」ということを示す。よって、このような新たなコンテキストの検出にともなって、サーバ３３０がサービスの削除をデバイス３２０に命じてもよい。
【０５７８】
同様に、第４実施形態でも、例えば端末４１０が会議室から出るのにともなって、センサ４４０がセンサ値を送信してもよく、コンテキスト抽出部４３３がコンテキストの変化を検出してもよい。そして、コンテキストの変化に応じて、サーバ４３０は、コントローラの削除を端末４１０に命じてもよい。同様に、第５実施形態でも、コンテキストの変化にともなって、サーバ５３０が端末５１０と端末５２０にサービスとコントローラの削除を命じてもよい。
【０５７９】
以上のようなコンテキストの変化に応じた削除により、不要なプログラムが削除される。よって、端末やデバイスの記憶容量の無駄な使用が防止可能である。また、ある特定のコンテキスト以外では利用を禁止することが望ましいサービスが、他のコンテキストで利用されることを防ぐことも可能となる。
【０５８０】
ところで、第１実施形態と第３実施形態の共通点は色々あるが、例えば以下の２点が挙げられる。
【０５８１】
・新規サービスプログラムのデバイスへのインストールに関わる通知（便宜上、「インストール関連通知」という）を、端末が送信する。
・デバイスが、インストール関連通知の受信の後に、新規サービスプログラムを取得する。
【０５８２】
つまり、第１実施形態におけるインストール関連通知は、図１のステップＳ１０７のサービス追加・更新コマンドであり、第３実施形態におけるインストール関連通知は、図１３のステップＳ５０７の受信準備コマンドである。そして、以上の共通点から理解されるように、第１実施形態の端末１１０のＵＰｎＰコントローラ１１１も、第３実施形態の端末３１０のＵＰｎＰコントローラ３１１も、以下の探索部および通知部として動作する。
【０５８３】
・サービス更新サービスをＵＰｎＰのディスカバリプロトコルおよびディスクリプションプロトコルにしたがって探索する探索部。
・探索部がサービス更新サービスを検出すると、サービス更新サービスに対して、インストール関連通知を送信する通知部。
【０５８４】
また、第１実施形態と第３実施形態のいずれにおいても、端末は、デバイスが新規サービスプログラムをインストールすると新規サービスに対してＵＰｎＰのコントロールプロトコルにしたがって制御メッセージを与える制御部を有する。例えば、図２のＵＰｎＰコントローラ１１１や図１４のＵＰｎＰコントローラ３１１が、当該制御部として動作してもよいし、不図示の他のＵＰｎＰコントローラが当該制御部として動作してもよい。
【０５８５】
また、第５実施形態の更新サービスも、サービス更新サービスの１種と見なせる。そして、例えば図２８の既存コントローラ５１２が更新サービス５２５を探索する場合、既存コントローラ５１２を上記の探索部と見なすこともでき、受信準備コマンドを送信する更新サービス５１５を上記の通知部と見なすこともできる。また、ＵＰｎＰ制御部５１１を上記の制御部と見なすこともできる。
【０５８６】
また、第２実施形態と第４実施形態の共通点も色々あるが、例えば、以下のような共通点が挙げられる。
【０５８７】
・デバイスの提供するサービスを検出するための検出部として、コントローラ更新サービスが動作する。
・検出したサービスを識別するサービス識別情報を、管理部（具体的にはコントローラ管理装置２３０またはサーバ４３０）に通知する通知部に相当するコンポーネントを、端末が有している。例えば、端末２１０においては、コントローラ更新サービス２１２が上記通知部として動作する。また、端末４１０においては、受信部４１３または要求部４１４が上記通知部として動作する。
・通知部からの通知に応じて管理部が新規コントローラプログラムを送信すると、新規コントローラプログラムを端末にインストールするインストール部として、コントローラ更新サービスが動作する。
・インストールされた新規コントローラプログラムにしたがって動作することにより、検出されたサービスを利用するための制御メッセージを当該サービスに対して与える制御部として、ＵＰｎＰ制御部内の新規コントローラが動作する。
【０５８８】
以上、様々な実施形態について説明したが、上記に例示した以外の適宜の変形が行われてもよい。いずれの実施形態によっても、ＵＰｎＰのサービスとコントローラの一方または双方が動的に更新されるので、利便性が向上する。
【０５８９】
最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
指定されたＵＰｎＰ（Universal Plug and Play）のサービスを提供するためのプログラムをインストールするための、ＵＰｎＰの特定のサービスを、端末が探索し、
前記特定のサービスを提供するデバイスが、前記端末に応答を返し、
前記端末が、前記応答により検出される前記特定のサービスに対して、ＵＰｎＰの新規サービスを提供するための新規プログラムの前記デバイスへのインストールに関わるインストール関連通知を送信し、
前記デバイスが、前記特定のサービスを提供するための特定のプログラムにしたがって動作することによって、前記インストール関連通知の受信の後に前記新規プログラムを取得するとともに取得した前記新規プログラムを前記デバイスにインストールし、
前記デバイスが、インストールした前記新規プログラムにしたがって動作することにより、前記新規サービスを前記端末に提供する
ことを特徴とするサービス提供方法。
（付記２）
前記インストール関連通知は、前記新規サービスを指定するサービス指定情報を含み、
前記サービス提供方法は、さらに、
前記サービス指定情報と対応づけて前記新規プログラムを格納しており、前記端末に含まれるかまたは他のコンピュータに含まれる管理部に対して、前記デバイスが、前記端末からの前記インストール関連通知に含まれる前記サービス指定情報を通知し、
前記管理部が、前記サービス指定情報の通知に応じて、前記新規プログラムを前記デバイスに送信する
ことを含み、
前記デバイスは、前記管理部から前記新規プログラムを受信することにより、前記新規プログラムを取得する
ことを特徴とする付記１に記載のサービス提供方法。
（付記３）
前記インストール関連通知は、前記新規プログラムを受信するための準備を行うよう、前記デバイスに促す通知であり、
前記サービス提供方法は、さらに、
特定の環境に前記デバイスが存在しているとき、検出装置が、前記デバイスが前記特定の環境下にあることを示す検出通知を送信し、
前記新規サービスを指定するサービス指定情報および前記特定の環境と対応づけて前記新規プログラムを格納する管理部が、前記検出通知の受信に応じて、前記新規プログラムを前記デバイスに送信する
ことを含み、
前記デバイスは、前記管理部から前記新規プログラムを受信することにより、前記新規プログラムを取得する
ことを特徴とする付記１に記載のサービス提供方法。
（付記４）
前記インストール関連通知は、前記新規プログラムを受信するための準備を行うよう、前記デバイスに促す通知であり、
前記サービス提供方法は、さらに、
前記新規プログラムを格納する管理部に対して、前記端末が、前記デバイスへの前記新規プログラムの送信を要求し、
前記端末からの要求に応じて、前記管理部が前記新規プログラムを前記デバイスに送信する
ことを含み、
前記デバイスは、前記管理部から前記新規プログラムを受信することにより、前記新規プログラムを取得する
ことを特徴とする付記１に記載のサービス提供方法。
（付記５）
前記デバイスが、前記新規サービスのインストール後、前記新規サービスが前記デバイスにインストールされたことを示す通知を送信する
ことをさらに含むことを特徴とする付記１から４のいずれか１項に記載のサービス提供方法。
（付記６）
端末が、デバイスの提供するＵＰｎＰのサービスを検出し、
前記端末が、前記デバイスに含まれるかまたは他のコンピュータに含まれる管理部に対して、前記サービスを識別するサービス識別情報を通知し、
前記サービスを利用するためのＵＰｎＰの特定のコントローラを実現するプログラムであって、通知された前記サービス識別情報と対応づけられて前記管理部に格納されている特定のコントローラプログラムを、前記管理部が前記端末に送信し、
前記端末が、前記特定のコントローラプログラムを受信し、
前記端末が、受信した前記特定のコントローラプログラムを前記端末にインストールし、
前記端末が、インストールした前記特定のコントローラプログラムにしたがって動作することにより、検出した前記サービスを利用するための制御メッセージを、検出した前記サービスに対して与える
ことを特徴とするサービス利用方法。
（付記７）
前記管理部は、通知された前記サービス識別情報を用いて前記特定のコントローラプログラムを検索し、検索により見つけた前記特定のコントローラプログラムを前記端末に送信する
ことを特徴とする付記６に記載のサービス利用方法。
（付記８）
前記管理部は、前記サービスを含む複数のサービスそれぞれについて、当該サービスを識別するサービス識別情報および当該サービスが利用される環境と対応づけて、当該サービスを利用するためのＵＰｎＰのコントローラのプログラムを格納しており、
前記サービス利用方法は、さらに、特定の環境に前記端末が存在しているときに、検出装置が、前記端末が前記特定の環境下にあることを示す検出通知を前記管理部に送信することを含み、
前記管理部は、前記検出通知を受信すると、
前記端末から通知された前記サービス識別情報と前記特定の環境とに対応づけて格納している前記特定のコントローラプログラムを検索し、
検索により見つけた前記特定のコントローラプログラムを前記端末に送信する
ことを特徴とする付記６に記載のサービス利用方法。
（付記９）
前記端末には、ＵＰｎＰの特定のサービスのプログラムがインストールされており、
前記端末は、前記特定のサービスの前記プログラムにしたがって動作することにより、前記管理部への通知および前記特定のコントローラプログラムのインストールを実行する
ことを特徴とする付記６から８のいずれか１項に記載のサービス利用方法。
（付記１０）
第１の端末と第２の端末と管理装置を含むシステムで実行される方法であって、
ＵＰｎＰ（Universal Plug and Play）のサービスを提供するためのサービスプログラムと、ＵＰｎＰの何らかのサービスを利用するためのＵＰｎＰのコントローラを実現するためのコントローラプログラムのいずれが指定されても、指定されたプログラムをインストールするためのＵＰｎＰのサービスである更新サービスを、前記第１の端末と前記第２の端末がともに提供しており、
前記第１の端末と前記第２の端末が特定の環境に入ると、前記第１の端末と前記第２の端末が前記特定の環境下にあることを示す検出通知を、検出装置が送信し、
１つ以上のＵＰｎＰのサービスのそれぞれについて、当該サービスと、当該サービスのインストール先の端末であるサービス提供端末の種類と、当該サービスを利用するためのコントローラと、当該コントローラのインストール先の端末であるコントローラ端末の種類と、当該サービスが利用される環境とを、互いに対応づける条件情報を、前記管理装置が格納しており、
前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第１の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第２の端末の前記種類と一致する第１の場合には、
前記検出通知の受信に応じて、前記管理装置が、前記条件情報により前記特定の環境と対応づけられている特定のサービスを提供するための特定のサービスプログラムを前記第１の端末に送信するとともに、前記条件情報により前記特定の環境と対応づけられている特定のコントローラを実現するための特定のコントローラプログラムを前記第２の端末に送信し、
前記第１の端末が、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第１の端末へのインストールを実行し、
前記第２の端末が、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第２の端末へのインストールを実行し、
前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第２の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第１の端末の前記種類と一致する第２の場合には、
前記検出通知の受信に応じて、前記管理装置が、前記特定のサービスプログラムを前記第２の端末に送信するとともに、前記特定のコントローラプログラムを前記第１の端末に送信し、
前記第１の端末が、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第１の端末へのインストールを実行し、
前記第２の端末が、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第２の端末へのインストールを実行する
ことを特徴とする方法。
（付記１１）
前記検出装置が、前記第１の端末に含まれるか、前記第２の端末に含まれるか、または、前記特定の環境に予め設置されていることを特徴とする付記１０に記載の方法。
（付記１２）
前記第１の端末が、前記更新サービスを提供する第２の端末を探索し、
前記第２の端末が、前記第１の端末に応答を返し、
前記第１の端末が、前記管理装置から送信されるプログラムを受信するための準備を行うよう、前記応答により検出される前記第２の端末に命令し、
前記第１の端末が、前記管理装置から送信されるプログラムを受信するための準備を行い、
前記第１の端末と前記第２の端末の一方または双方からの通知により、前記管理装置が、前記第１の端末と前記第２の端末それぞれの前記種類を認識する
ことをさらに含むことを特徴とする付記１０または１１に記載の方法。
（付記１３）
ＵＰｎＰ（Universal Plug and Play）の新規サービスを提供するための新規プログラムを、外部から与えられる通知の受信の後に取得してインストールするための、ＵＰｎＰの特定のサービスを提供するデバイスと、
端末であって、
前記特定のサービスをＵＰｎＰのディスカバリプロトコルおよびディスクリプションプロトコルにしたがって探索する探索部と、
前記探索部が前記特定のサービスを検出すると、前記特定のサービスに対して、前記新規プログラムの前記デバイスへのインストールに関わるインストール関連通知を送信する第１の通知部と、
前記デバイスが前記インストール関連通知の受信の後に前記デバイスに前記新規プログラムをインストールすると、前記新規サービスに対してＵＰｎＰのコントロールプロトコルにしたがって制御メッセージを与える第１の制御部と、
を備えることを特徴とする端末と、
を備えることを特徴とするシステム。
（付記１４）
前記デバイスまたは他のデバイスにより提供される、前記特定のサービス以外かつ前記新規サービス以外の、ＵＰｎＰの別のサービスを利用するための、ＵＰｎＰのコントローラを実現するコントローラプログラムを、前記別のサービスと対応づけて格納する管理部を、前記システムはさらに備え、
前記端末はさらに、
前記別のサービスを検出する検出部と、
前記検出部が検出した前記別のサービスを識別するサービス識別情報を前記管理部に通知する第２の通知部と、
前記通知部からの通知に応じて前記管理部が前記コントローラプログラムを送信すると、前記コントローラプログラムを前記端末にインストールするインストール部と、
前記インストール部がインストールした前記コントローラプログラムにしたがって動作することにより、前記別のサービスを利用するための制御メッセージを、前記別のサービスに対して与える第２の制御部と
を備える
ことを特徴とする付記１３に記載のシステム。
【符号の説明】
【０５９０】
１００、２００、３００、４００、５００  システム
１１０、１４０、２１０、３１０、３５０、４１０、５１０、５２０、５５０  端末
１１１、３１１  ＵＰｎＰコントローラ
１２０、２２０、３２０、４２０  デバイス
１２１、２２１、３２１、４２１、５１３、５２３  ＵＰｎＰサービス提供部
１２２、３２２  サービス更新サービス
１２３、３２３、５１８、５２８  新規サービス
１３０  サービス管理装置
１３１、２３１、３３１、４３１、５３１  格納部
１３２、３３２、５３２  新規サービスプログラム
１５０、２４０、５６０  デバイス定義ファイル
１５１、２４１、５６１  サービス定義ファイル
１５２  応答
１５３  ＳＯＡＰコマンド
２１１、４１１、５１１、５２１  ＵＰｎＰ制御部
２１２、４１２  コントローラ更新サービス
２１３、４１５、５１９、５２９  新規コントローラ
２２２、４２２  サービス
２３０  コントローラ管理装置
２３２、４３２、５３３  新規コントローラプログラム
２３３  コントローラ決定部
２３４、３３５、４３５、５３６  条件テーブル
３１２、４１４、５１７、５２７  要求部
３２４、４１３、５１６、５２６  受信部
３３０、４３０、５３０  サーバ
３３３、４３３、５３４  コンテキスト抽出部
３３４  サービス決定部
３３６  デバイス管理部
３３７  デバイステーブル
３３８、４３８、５３９  送信部
３４０、４４０、５４０  センサ
４３４  コントローラ決定部
４３６、５３７  端末管理部
４３７、５３８  端末テーブル
５１２、５２２  既存コントローラ
５１４、５２４  既存サービス
５１５、５２５  更新サービス
５３５  決定部
６００  情報処理装置
６０１  ＣＰＵ
６０２  ＲＯＭ
６０３  ＲＡＭ
６０４  通信インタフェイス
６０５  入力装置
６０６  出力装置
６０７  記憶装置
６０８  駆動装置
６０９  バス
６１０  記憶媒体
６１１  ネットワーク
６１２  プログラム提供者
【図１】
0005821627.tif 000002
【図２】
0005821627.tif 000003
【図３】
0005821627.tif 000004
【図４】
0005821627.tif 000005
【図５】
0005821627.tif 000006
【図６】
0005821627.tif 000007
【図７】
0005821627.tif 000008
【図８】
0005821627.tif 000009
【図９】
0005821627.tif 000010
【図１０】
0005821627.tif 000011
【図１１】
0005821627.tif 000012
【図１２】
0005821627.tif 000013
【図１３】
0005821627.tif 000014
【図１４】
0005821627.tif 000015
【図１５】
0005821627.tif 000016
【図１６】
0005821627.tif 000017
【図１７】
0005821627.tif 000018
【図１８】
0005821627.tif 000019
【図１９】
0005821627.tif 000020
【図２０】
0005821627.tif 000021
【図２１】
0005821627.tif 000022
【図２２】
0005821627.tif 000023
【図２３】
0005821627.tif 000024
【図２４】
0005821627.tif 000025
【図２５】
0005821627.tif 000026
【図２６】
0005821627.tif 000027
【図２７】
0005821627.tif 000028
【図２８】
0005821627.tif 000029
【図２９】
0005821627.tif 000030
【図３０】
0005821627.tif 000031
【図３１】
0005821627.tif 000032
【図３２】
0005821627.tif 000033
【図３３】
0005821627.tif 000034
【図３４】
0005821627.tif 000035
【図３５】
0005821627.tif 000036
【図３６】
0005821627.tif 000037
【図３７】
0005821627.tif 000038
【図３８】
0005821627.tif 000039
【図３９】
0005821627.tif 000040
【図４０】
0005821627.tif 000041